> For the complete documentation index, see [llms.txt](https://infosys.selmotech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://infosys.selmotech.com/selmo-solution/selmo-solution-en/selmo-as-a-process/selmo-ptf/3.-sipoc-structure-of-the-ptf.md).

# 3. SIPOC structure of the PTF

##

<details>

<summary>Supplier</summary>

</details>

## Supplier

**Definition:**\
Suppliers are the responsible parties who feed input data, documents, or knowledge into the PTF.\
They provide verified information that serves as the basis for process, technology, and function.

**Quality criteria:**

* Unambiguous, verifiable, deterministic
* Versioned, released, documented
* Standards-compliant (ISO, CE, MVO 2027)

<details>

<summary>SIPOC – “Supplier” in the Selmo-PTF</summary>

### 1) Definition

**Supplier** is **the responsible role/organization**, the **provides binding inputs** to the PTF process. These inputs are technically correct, complete, verifiable and versioned – and form the basis for **process, technology and function definition** as well as the later formal verification in the Selmo model.

**Mnemonic:** Supplier ≠ “who shouts the loudest”, but **who is content-responsible**, **who owns data sources** and **who can bear the consequences technically**.

### 2) Principles for identifying a Supplier

A stakeholder is a supplier if they…

* …**Original source** are the original source for an input (e.g. process knowledge, standard requirements, I/O data, interfaces).
* …**Change authority** has authority over this input (may decide technically).
* …**Delivery obligation** commits regarding format, timing, maturity.
* …**, follow the same basic principles:** ensures (limits, tolerances, measurement points, test cases).
* …**Traceability** ensures (version, reason for change, responsible party).

### 3) Typical Supplier roles in the PTF (with delivered inputs)

* **Process owner / Industrial Engineering**\
  Delivers: process target & takt, value stream, state/process description, stop criteria, **process parameters** (times, tolerances), quality characteristics.
* **Process engineer (technologist)**\
  Delivers: detailed work sequences, resources, auxiliary materials, inspection plans, measurement points, safety assumptions (PLr/SIL need).
* **Mechanical design**\
  Delivers: kinematics/layouts, bill of materials, media (compressed air, vacuum), safety distances, end positions; **mechanical interfaces**.
* **Electrical/control (E-Plan/hardware)**\
  Delivers: wiring diagram, **I/O list**, protection circuits, safety architecture, terminal diagrams, terminal labels.
* **Automation/Selmo modeling (software)** *(as supplier for F-inputs)*\
  Delivers: **Function sheets** (e.g. adders), triggers/feedback, limits, error reactions, CMZ/MXIC requirements.
* **IT/OT & data systems (MES/ERP/SCADA/Cloud)**\
  Delivers: **Interface description** (protocol, topics/tags, payload, QoS), data fields, latency/availability, security requirements.
* **External technology suppliers (robotics, vision, drives, sensors)**\
  Delivers: data sheets, **interface/command set**, cycle times, accuracy, diagnostics/alarms.
* **Safety/CE/standards**\
  Delivers: applicable standards, risk assessment, PLr/SIL evidence, protective measures.
* **Quality**\
  Delivers: test concept, SPC rules, release criteria, traceability requirements.
* **Operations/maintenance**\
  Delivers: maintenance requirements, HMI operation concept, response times, spare part standards.
* **Utilities/facility**\
  Delivers: media availability (power, air, cooling), limits, connection points.

### 4) Artifacts/deliverables per Supplier (PTF labeling proposal)

* **PTF-PROC** – Process description (SIPOC, state logic, parameter list)
* **PTF-TECH** – Technology matrix (sensors/actuators, manufacturer, lifecycle data)
* **PTF-IO** – I/O list (address, signal name, zone, CMZ level)
* **PTF-IF** – Interface specification (protocol, topics/tags, field definitions)
* **PTF-FUNC** – Function sheet (e.g. *adder*): inputs/outputs, domains, limits, error cases, test cases
* **PTF-SAFE** – Safety evidence (PLr/SIL, protective circuits, MXIC/interlocks)
* **PTF-HMI** – HMI texts, operation concept, diagnostic messages
* **PTF-Q** – Quality/acceptance plan (DoE, SPC, limit patterns)

### 5) Quality & maturity criteria for supplier inputs (Definition of Ready)

Each input must:

* **Be unambiguous & deterministic** (no interpretation gaps, clear states/transitions).
* **Define domains/limits** (min/max, tolerances, units, default values).
* **Describe error & diagnostic behavior** (detection, reaction, return conditions).
* **Be verifiable** (measurement points, test cases, acceptance criteria).
* **Be versioned & traceable** (ID, date, responsible party, reason for change).
* **Be formally correct** (presented using templates/structure as above).

### 6) RACI framework (typical)

* **Responsible (R):** the respective supplier role per input
* **Accountable (A):** PTF lead / Project management
* **Consulted (C):** adjacent disciplines (e.g. safety, quality)
* **Informed (I):** stakeholders (operations, purchasing, PMO)

### 7) Supplier checklist (for quick assignment)

1. Who is **Original source** the information?
2. Who **decides** in case of conflicting goals?
3. Who **signs** the input (technical release)?
4. In which **Format** is it delivered (PTF artifact)?
5. By when (**due date/milestone**)?
6. How is the **, follow the same basic principles:** proven (test cases, measurement points)?

### 8) Entry template (for your process document)

```
Supplier record
Role/organization: ______________________________
Responsible (name/contact): ___________________
Delivers (artifacts): _____________________________
PTF IDs: ________________________________________
Format/standards: ________________________________
Maturity (draft/review/released): _______________
Due date/milestone: ____________________________
Dependencies: _________________________________
Acceptance criteria/tests: _____________________________
Released by (A): ______________________________
```

### 9) Mini-examples

* **Supplier: process engineer (R)**\
  Delivers **PTF-PROC** with takt 18 s, state chain, parameters (press time, temperature), stop criteria; test cases for setpoint/actual comparison.\
  **A:** PTF lead; **C:** quality, safety.
* **Supplier: IT/MES (R)**\
  Delivers **PTF-IF** (REST/MQTT, field list “OrderId, Variant, Result, TraceId”, retry/timeout), data quality rules.\
  **A:** PTF lead; **C:** Automation.

</details>

## **Input**

**Definition:**\
Inputs are the formal information provided by the suppliers. They describe what is analyzed, checked and transferred into the Selmo structure in the PTF process.

<details>

<summary>SIPOC – “Input” in the Selmo-PTF</summary>

### 1) Definition

**Input** denotes all **binding information, documents, data or models**, that are delivered by the identified *suppliers* to execute the **PTF process (process – technology – function)** These inputs form the basis for:

* the **modeling** in the Selmo Studio,
* the **formal verification** (determinism, completeness, traceability),
* the **automated documentation** and
* the **risk and quality assessment**.

An input is only **valid**when it:

* is complete, unambiguous and consistent,
* is in the correct format,
* is assigned a version and source,
* and has been **released by the PTF lead or project manager** .

***

### 2) Goal of the input step

* **Availability of all technically verified information** before the start of modeling
* **Reduction of interpretation leeway**
* **Formal handover** between disciplines (mechanical, electrical, software, IT)
* **Standardized formats** for easy integration into the Selmo system

***

### 3) Main categories of inputs in the PTF

Each input belongs to one of the three PTF levels:

| Level              | Input type              | Description                                          | Example                                          |
| ------------------ | ----------------------- | ---------------------------------------------------- | ------------------------------------------------ |
| **P – Process**    | process description     | Describes the logical and physical sequence.         | Process diagram, sequence of steps, state matrix |
|                    | Parameter list          | Process parameters, limits, time specifications      | Cycle time, temperature, pressure, positions     |
|                    | Quality characteristics | Measured values, acceptance criteria, limit patterns | Test pressure, dimensional tolerances            |
| **T – Technology** | Technology matrix       | Overview of all used technologies, devices, systems  | Sensors, actuators, robots, PLCs, buses          |
|                    | I/O list                | Assignment of signals to zones, addresses, CMZ level | Inputs/outputs, symbolism, signal names          |
|                    | Interface description   | Definition of communication paths to subsystems      | MES, ERP, SCADA, robotics, safety                |
| **F – Function**   | Function sheets         | Documentation of logical functions                   | Adders, PID controller, HMI message              |
|                    | Diagnosis/error logic   | Description of monitoring and reactions              | Limit violation → stop + alarm                   |
|                    | Test/verification cases | Test steps, expected outputs                         | Input A+B=Result, timeout test, interlock check  |

***

### 4) Standardized formats & templates (Selmo proposal)

| PTF input                                     | Recommended format                     | Description / purpose                                                | Comment                                    |
| --------------------------------------------- | -------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------ |
| **PTF-PROC** (process description)            | MS Excel or Selmo template (CSV/XML)   | Contains process steps, states, conditions, parameters               | Standard template with SIPOC header        |
| **PTF-PARAM** (parameter list)                | Excel / CSV                            | Key parameters (name, unit, min/max, default, description)           | Automatically importable into Selmo Studio |
| **PTF-TECH** (technology matrix)              | Excel / Selmo template                 | Listing of all system components (type, ID, interface, manufacturer) | Basis for zone structure                   |
| **PTF-IO** (I/O list)                         | Excel / EPLAN export (CSV/XML)         | Signal name, address, zone type, CMZ level                           | Import into Selmo zone structure           |
| **PTF-IF** (interface description)            | PDF / JSON / YAML                      | Communication interfaces (protocol, tags, data types, direction)     | For MES, robotics, cloud etc.              |
| **PTF-FUNC** (function sheet)                 | Selmo function document (Word/PDF/XML) | Inputs, outputs, triggers, monitors, test cases                      | Function standardization                   |
| **PTF-SAFE** (safety description)             | PDF / Excel                            | Interlock, CMZ, PLr/SIL, shutdown matrix                             | Basis for risk assessment                  |
| **PTF-HMI** (HMI texts and operation concept) | Excel / JSON                           | Texts, colors, states, diagnostics                                   | Automatically generable                    |
| **PTF-Q** (quality plan)                      | PDF / Excel                            | Inspection plans, limit values, SPC rules, measurement cycles        | Traceability and audit evidence            |

***

### 5) Requirements for form and quality (Definition of Ready)

An input is **ready for PTF use**when it:

| Criterion         | Description                                         | Example                                         |
| ----------------- | --------------------------------------------------- | ----------------------------------------------- |
| **Unambiguous**   | No ambiguity in terms or states                     | "Cylinder extends" instead of "cylinder active" |
| **Complete**      | All relevant parameters, states, interfaces defined | All process steps mapped                        |
| **Be verifiable** | Measurable, verifiable, testable                    | Test case “A+B=Result” with limit values        |
| **Deterministic** | No undefined transitions or states                  | No "waiting for an undefined signal"            |
| **Traceable**     | Clear assignment to source, version, date           | "PTF-PROC v1.2, created by M. Müller"           |
| **Released**      | Formally confirmed by the responsible party         | "Released" status in the PTF register           |

***

### 6) Version and data management

* All inputs receive a unique **PTF ID** (e.g. PTF-PROC-001).
* Changes are made according to the **change process (change log)** with release.
* Format specification:
  * **Textual data:** `.docx`, `.pdf`, `.md`
  * **Tabular data:** `.xlsx`, `.csv`
  * **Structured data:** `.xml`, `.json`
* All data are stored versioned in the **project directory "/PTF/Input"** .

***

### 7) Temporal classification

Inputs must **before the start of modeling** be complete.\
Recommended milestones:

| Phase                                            | Input focus                                    | Deliverable                  |
| ------------------------------------------------ | ---------------------------------------------- | ---------------------------- |
| **Kick-off → Design freeze (0–20%)**             | Process description (PTF-PROC), parameter list | Process basis clear          |
| **Design freeze → technology planning (20–40%)** | Technology matrix, I/O, safety                 | Hardware aligned             |
| **Before commissioning (40–70%)**                | Functions, interfaces                          | Software definition complete |
| **Before release (70–100%)**                     | HMI, quality plan, tests                       | Complete verification        |

***

### 8) Example of a complete input dataset

```
Input record
Designation: PTF-FUNC-002 “Adder”
Supplier: Automation
Version: 1.0
Format: Selmo function sheet (XML)
Short description: Adds two real values, monitors value range
Input: ValueA, ValueB (REAL)
Output: Sum (REAL)
Limits: -100.0 ... 100.0
Monitoring: Out of range → error code 101
Verification: Test case A=2.0, B=3.0 → Sum=5.0
Released by: Lead software engineering
Status: Released
```

***

### 9) Responsibilities (RACI for inputs)

| Role                   | R | A | C               | I                  |
| ---------------------- | - | - | --------------- | ------------------ |
| Process engineer       | X |   | Quality, safety | Project management |
| Mechanics / Electrical | X |   | Automation      | Project management |
| Software / automation  | X |   | process         | Project management |
| PTF lead               |   | X | all             | PMO                |
| Quality / Safety       |   |   | X               | all                |

***

### 10) Conclusion

One **Input** in the PTF process it is not “a document”, but a **technically verified data state**, which describes the behavior, the technology and the function of a machine.\
Only through clear **formats, releases and verifiability** is the basis created for:

* deterministic modeling,
* error-free implementation,
* and formal traceability throughout the lifecycle.

</details>

## **Process**

**Definition:**\
The PTF process describes the sequence from requirement to release.

**Phases:**

1. Initiation & scope
2. Process description (P)
3. Technology analysis (T)
4. Function definition (F)
5. Review & risk
6. Release & handover

Customer → provides requirements\
PTF lead → structures process, technology, function\
Mechanical / electrical → define systems and interfaces\
Software → models the behavior in the Selmo Studio\
Quality / safety → checks standards and risks\
Management → approves and manages budget

→ Result: A complete, deterministic project flow without interpretation gaps.

**Objective:**\
A Selmo-compliant, deterministic machine model with documented risks, deviations and releases.

<details>

<summary>SIPOC – Process in the Selmo-PTF</summary>

### 1) Definition

The **PTF process** describes the formal sequence from capturing requirements to the release of the complete, Selmo-compliant process model.\
It is **binding** for all projects that are built according to the **Selmo Method** and ensures that **each machine is deterministic, verifiable and documented** is created.

The process follows the three PTF dimensions:

* **P – Process** → What happens?
* **T – Technology** → With what does it happen?
* **F – Function** → How does it work?

***

### 2) Goal of the process

* **Produce a complete, Selmo-compliant process definition**
* **Separation of process, technology and function responsibility**
* **Create the basis for the Selmo process model (sequence, zones, bit control)**
* **Detect, document and assess non-conformities or risks**
* **Formal traceability and risk transparency** throughout the lifecycle

> **Guiding principle:**\
> Anything that is not described, documented and assessed in the PTF must not be implemented in the Selmo model.

***

### 3) Process overview (top-level)

The PTF process is divided into **six phases** with clearly defined handover points and responsibilities.

| Phase                                    | Goal                                                     | Main deliverable               |
| ---------------------------------------- | -------------------------------------------------------- | ------------------------------ |
| **1. Initiation & scope**                | Define project scope and system boundaries               | PTF scope document             |
| **2. Process capture & description (P)** | Define physical and logical sequence                     | PTF-PROC, parameter list       |
| **3. Technology analysis (T)**           | Determine technologies, interfaces and system components | PTF-TECH, PTF-IO, PTF-IF       |
| **4. Function definition (F)**           | Specify and document functions                           | PTF-FUNC, PTF-SAFE             |
| **5. Review & risk assessment**          | Check Selmo compliance, assess deviations                | PTF-RISK, review protocol      |
| **6. Release & handover**                | Formally release PTF, create basis for modeling          | PTF release, handover protocol |

***

### 4) Detailed procedure

#### **Phase 1 – Initiation & scope**

**Objective:** Define project and system boundaries clearly.\
**Responsibility:** Project management / PTF lead\
**Steps:**

1. Description of the machine/plant to be modeled
2. Define the scope of consideration (plant, hardware zones, sequences)
3. Define delivery boundaries between disciplines
4. Set up the PTF artifact structure (directories, templates)
5. Name the suppliers and responsible parties

**Result:**

* PTF scope document
* Roles & responsibility matrix
* PTF directory structure (input/process/output)

***

#### **Phase 2 – Process capture & description (P)**

**Objective:** Describe the complete process flow – physical and logical.\
**Responsibility:** Process owner / Industrial Engineering

**Steps:**

1. Survey the real or planned process flow (value stream, steps, transitions)
2. Define states, triggers, conditions and stop criteria
3. Identify all process parameters (times, temperatures, forces, paths etc.)
4. Documentation in the **PTF-PROC** (process description)
5. Creation of a **parameter list (PTF-PARAM)**

**Dependencies:**

* Requires input from mechanical and electrical (layout, sensors)
* Provides the basis for technology and function definition

**Result:**

* Complete process description (states, transitions, goals)
* Parameter and quality definition

***

#### **Phase 3 – Technology analysis (T)**

**Objective:** Describe all technologies, devices and interfaces and check for Selmo compliance.\
**Responsibility:** Technology responsible (electrical/mechanical/automation)

**Steps:**

1. Creation of the **technology matrix (PTF-TECH)**\
   – sensors, actuators, interfaces, media, controls
2. Creation of the **I/O list (PTF-IO)**\
   – assignment to zones, signal types, CMZ level
3. Definition of the **System and data interfaces (PTF-IF)**\
   – MES, robots, safety, cloud, etc.
4. Assessment of **Selmo compliance:**
   * deterministic signals?
   * unique states?
   * feedback available?
   * synchronizable?
5. Documentation of **non-conformities** in the **PTF-RISK**

**Result:**

* Complete technology matrix
* Interface overview
* Assessment of Selmo suitability

***

#### **Phase 4 – Function definition (F)**

**Objective:** Document, standardize and verify all functions used in the process.\
**Responsibility:** Function owner (Software / Automation)

**Steps:**

1. Creation of **function sheets (PTF-FUNC)** for all logical functions
2. Definition of inputs, outputs, triggers, limits, monitors
3. Assignment to process and technology elements
4. Creation of the **Safety and monitoring functions (PTF-SAFE)**
5. Definition of **test cases / verification points**

**Dependencies:**

* Requires complete process (Phase 2) and technology (Phase 3)
* Results flow into Selmo standard functions (e.g., adder, interlock, timer)

**Result:**

* Documented, verifiable function library
* Defined monitors (CMZ, MXIC, pair-check etc.)

***

#### **Phase 5 – Review & risk assessment**

**Objective:** Assess PTF completeness, Selmo compliance and risks.\
**Responsibility:** PTF lead / quality / safety

**Steps:**

1. Review of all PTF artifacts (PROC, TECH, FUNC)
2. Identification of non-Selmo-compliant requirements
3. Assessment of these items in **Risk management (PTF-RISK)**\
   – Classification: critical / moderate / acceptable\
   – Measures: adaptation, simplification, standardization
4. Release recommendation or revision

**Result:**

* PTF review protocol
* Risk list with responsibilities and measures

> **Note:**\
> Risks from non-Selmo conformity are **not ignored**Non-conforming requirements or technologies are **documented transparently**.\
> This keeps the model consistent, and all deviations are **conscious, traceable and actionable**.

***

#### **Phase 6 – Release & handover**

**Objective:** Officially release PTF and hand over as the basis for Selmo modeling.\
**Responsibility:** Project management / PTF lead

**Steps:**

1. Final review with all disciplines
2. Formal release of all PTF artifacts (release status)
3. Handover to Selmo modeling (Sequence, Zone, Bit Control)
4. Archiving the PTF status
5. Start of Selmo modeling

**Result:**

* Released PTF
* Official basis for the Selmo model
* Traceability down to code level ensured

***

### 5) Process responsibility (RACI)

| Phase                   | R                  | A                  | C                   | I                  |
| ----------------------- | ------------------ | ------------------ | ------------------- | ------------------ |
| Initiation              | Project management | Project management | PTF lead            | all stakeholders   |
| Process capture (P)     | Process owner      | PTF lead           | Technology, quality | Project management |
| Technology analysis (T) | Technology owner   | PTF lead           | Process, Safety     | Project management |
| Function definition (F) | Software owner     | PTF lead           | Technology, process | Project management |
| Review & risk           | PTF lead, quality  | Project management | all                 | Management         |
| Release & handover      | Project management | Project management | PTF lead            | Team, customer     |

***

### 6) Interfaces & dependencies

* **Process data (P)** → basis for technology and function definition
* **Technology (T)** → defines physical feasibility and signal structure
* **Function (F)** → describes logical behavior and monitoring
* **Risk management (RISK)** → evaluates all deviations and feeds them back

Each phase may **only be released**, when its upstream phase is **completed and validated** is.\
→ This ensures that no model is based on uncertain assumptions.

***

### 7) Quality and review criteria

A PTF is considered **process-wise complete**, when:

* All PTF artifacts are available, consistent and released
* All supplier inputs are validated
* All interfaces are defined
* All risks are documented and assessed
* The deterministic sequence can be modeled in a traceable way
* Implementation in Selmo is technically feasible

***

### 8) Result and significance

The PTF process provides the **fully verified, formal foundation** for modeling in the Selmo Studio.\
It separates:

* **What** (Process)
* **With what** (Technology)
* **How** (Function)

… and brings them together in a verifiable, deterministic framework.

Thus, the PTF becomes the **bridge between engineering and automation** –\
and makes every machine created according to Selmo **transparent, traceable and safe**.

***

### 9) Core message for the kick-off

> The PTF process is not an add-on, but the foundation.\
> It defines what is built before anything is programmed.\
> When all requirements, technologies and functions are clearly described, verified and released,\
> the PTF automatically yields a **Selmo-compliant process model** – deterministic, documented and verifiable.\
> And if something is *not* Selmo-compliant, we know it, document it, assess it and can work on it in a targeted manner.

</details>

## Output

**Definition:**\
The output is the released, documented result of the PTF process – technically, organizationally and normatively.

**Technical outputs:**

* Structured Selmo hierarchy: Plant → HWZ → Sequence → Zones
* Bit control matrix, parameters, CMZ, MXIC
* Function sheets and test cases
* PTF model file (XML / PLCopen)

**Organizational outputs:**

* Risk assessment (PTF-RISK)
* Deviation list
* Standards and CE evidence
* Commercial assessment

**Completion criterion:** “The system is PTF-complete, Selmo-compatible and released.”

<details>

<summary>SIPOC – Output in the Selmo PTF</summary>

### 1) Definition

The **Output** of the PTF process is the **fully verified, released and documented overall model** of a machine or plant in the **Selmo structure**.\
It forms the **binding basis for programming, control code, HMI, diagnostics and safety logic.**

The output includes both:

* **Technical results** (models, documents, data),
* as well as **non-technical assessments** (risks, deviations, standards compliance, commercial assessment).

***

### 2) Objective of the output

* Provision of a **fully definable process model**, which can be implemented in the Selmo Studio
* Ensuring that **every function is deterministic, verifiable and compliant with standards** is
* Documentation of **Deviations, residual risks and evaluation results**
* Provision of a **formal handover** between engineering and software development

> **Target state:**\
> The output of the PTF is so complete that **a Selmo model can be generated automatically**, without room for interpretation.

***

### 3) Technical outputs in detail

#### **3.1. Structured machine setup (Selmo structure)**

The PTF is mapped in the **hierarchical Selmo structure** Each level is documented in the PTF and can be transferred to the Selmo Studio:

| Level                                  | Description                                                                  | Typical PTF data                                              |
| -------------------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------- |
| **PLANT**                              | Entire machine or plant                                                      | Plant data sheet, interface overview, safety zones, total CMZ |
| **Hardware zones (HWZ)**               | Function blocks within the plant (e.g., stations, line segments)             | HWZ description, operating modes, safety logic, power supply  |
| **Sequences (SEQ)**                    | Logical sequence modules within the HWZ (e.g., clamping, testing, machining) | Flowcharts, states, transition conditions                     |
| **Zones (Input, Output, In-Out, Mem)** | Assignment of physical signals to logical states                             | Signal definition, CMZ level, HMI texts, interlocks           |
| **Bit control (system layer)**         | Link between state and zone behavior (0, i, S)                               | Bit control matrix, status definition                         |
| **CMZ (Constantly Monitoring Zone)**   | Permanent safety monitoring (sequence, HWZ, plant level)                     | CMZ table, error reactions                                    |
| **MXIC (Manual Cross Interlock)**      | Manual operation conditions and release behavior                             | MXIC matrix, diagnostic conditions                            |
| **parameter layer**                    | Process parameters and adjustable values                                     | Parameter table with units, limits, default values            |

This turns the PTF output into **a complete digital machine image**, which directly serves as the basis for:

* the **Selmo Sequence Editor**,
* the **Zone logic**,
* the **HMI generation**,
* and the **PLC generation** serves.

***

#### **3.2. Documented function library**

All defined functions (e.g., “adder,” “move to position,” “move cylinder,” “open valve”) are provided in a **standardized form** provided:

| element                   | Description                                |
| ------------------------- | ------------------------------------------ |
| Function name and purpose | Unique identification and description      |
| Inputs / outputs          | Data types, units, limits                  |
| Trigger conditions        | Triggers, start/stop logic                 |
| Monitors                  | Error detection, feedback, limit violation |
| Test cases                | Verification, target/actual comparison     |
| HMI integration           | Display, message, diagnostics              |
| Safety behavior           | CMZ, interlock, MXIC conditions            |

This makes every function **verifiable, reusable and documented**.\
These function sheets are **PTF-FUNC** stored in the PTF and form the standard toolbox of software development.

***

#### **3.3. Standards and regulatory evidence**

In the PTF documentation, the **consideration of relevant standards and regulations** is explicitly included:

| Domain                           | Example standards / guidelines                                    |
| -------------------------------- | ----------------------------------------------------------------- |
| **Machine safety**               | 2006/42/EC (Machinery Directive), ISO 12100, ISO 13849, IEC 62061 |
| **Software quality**             | IEC 61131-3, ISO 9001, ISO/IEC 25010                              |
| **Risk management**              | ISO 31000, ISO 14971 (for risk analysis and assessment)           |
| **Traceability & documentation** | EN 82079, ISO/IEC/IEEE 15288                                      |
| **Data & communication**         | OPC UA, MQTT, REST, IEC 62443 (IT security)                       |

**Objective:**\
Every technology, function or software component used meets or addresses the applicable standard requirements.\
Deviations are documented and transferred to the **risk management section (PTF-RISK)** included.

***

### 4) Evaluation and risk management as part of the output

The PTF output mandatorily contains the following assessments and evidence:

| Category                            | Content                                                                      | Goal                                                        |
| ----------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------- |
| **Technical risk assessment**       | Assessment of process, technology and function risks                         | Traceable decision on which risks are accepted or mitigated |
| **Deviation list**                  | Documentation of all items that are not Selmo-compliant or not deterministic | Transparent basis for later improvements                    |
| **Non-technical risk assessment**   | Organizational, economic, scheduling or communication risks                  | Holistic view, no “technical tunnel vision”                 |
| **Commercial assessment**           | Effort, benefit, complexity, cost-effectiveness                              | Justified prioritization for measures and changes           |
| **Standards compliance assessment** | Degree of fulfillment of relevant standards                                  | Evidence for audits, CE documentation, quality management   |

These assessments are **not optional** – they constitute the documented state of responsibility.\
The result is not a “perfect” state, but a **consciously assessed and controllable**.

***

### 5) Form of outputs (deliverables & formats)

| Deliverable     | Format          | Description / purpose                                              |
| --------------- | --------------- | ------------------------------------------------------------------ |
| **PTF report**  | PDF / DOCX      | Overall report with process, technology and function overview      |
| **PTF-RISK**    | Excel / JSON    | Risk list with assessment and measures                             |
| **PTF-MODEL**   | XML / PLCopen   | Structured machine definition (Plant, HWZ, SEQ, zones, parameters) |
| **PTF-FUNC**    | XML / PDF       | Function sheets and test records                                   |
| **PTF-NORM**    | PDF             | Standards and regulatory evidence                                  |
| **PTF-RELEASE** | Signed document | Official release for modeling                                      |
| **PTF-HMI**     | JSON / CSV      | Texts, messages, colors, operating procedures                      |
| **PTF-Q**       | Excel / PDF     | Quality plan, checkpoints, SPC limits                              |

***

### 6) Responsibilities (RACI)

| Output               | R                     | A                  | C                             | I                  |
| -------------------- | --------------------- | ------------------ | ----------------------------- | ------------------ |
| Technical PTF report | PTF lead              | Project management | Process, technology, software | Quality            |
| Function library     | Software / automation | PTF lead           | technology                    | Project management |
| Risk assessment      | PTF lead, quality     | Project management | all                           | Management         |
| Deviation list       | PTF lead              | Project management | Process, technology           | Quality            |
| Standards assessment | Safety / quality      | Project management | technology                    | Management         |
| Approval / release   | Project management    | Management         | PTF lead                      | all                |

***

### 7) Handover to Selmo modeling

After release, the PTF output is:

* **handed over as a package to the Selmo Studio**,
* **imported into the modeling structure** (Plant → HWZ → SEQ → zones),
* **automatically implemented in bit control and HMI**,
* and **linked to the PTF version** (traceability).

→ Each zone, each signal, each CMZ or MXIC condition can later be traced directly back to the associated PTF entry.

***

### 8) Quality and completion criteria

A PTF output is considered **complete and released**, when:

1. All technical artifacts are created, reviewed and released
2. All risks and deviations are documented and assessed
3. The Selmo structure can be fully mapped
4. Evidence of standards and guidelines is included
5. The commercial assessment is completed
6. The release document is signed

> **Closing formula:**\
> “The system is PTF-complete, Selmo-compatible and released for modeling.”

***

### 9) Benefits and significance

The PTF output is the **binding, verifiable bridge** between engineering and software.\
It ensures:

* **Determinism in behavior and control**,
* **Transparency in responsibility and risk**,
* **Reusability through standardization**,
* **Traceability over the entire lifecycle**.

This makes the PTF not only the **technical specification**, but the **organizational safety line** in the project.

***

### 10) Short form for presentations / kick-off

> **The output of the PTF is the digital twin of the machine – before it is built.**
>
> It contains all the information to generate the Selmo process model,\
> all functions to control deterministically,\
> and all assessments to manage risks consciously.
>
> → What is not Selmo-compliant becomes visible.\
> → What is documented becomes verifiable.\
> → What is released becomes deterministic.

</details>

## Customer

**Definition:**\
Customers are all roles that actively use the PTF output to fulfill their tasks.

**Main groups & benefits:**

* **Project Management:** Planning, release, transparency
* **Process owner:** Traceable sequence
* **Mechanical / electrical:** Safe signal definition, interfaces
* **Software / automation:** Basis for Selmo modeling
* **Quality / safety:** Evidence & risk assessment
* **Management:** Economic decision basis
* **Customer / Operator:** Documentation, trust, CE evidence

**Core benefit:**\
Every stakeholder receives verifiable, traceable information for their responsibility.

<details>

<summary>SIPOC – Customer in the Selmo PTF</summary>

### 1) Definition

**Customer** in the PTF context are **all roles or organizational units**,\
that use the released PTF **use**, to

* carry out their own tasks,
* reduce risks,
* make decisions, or
* safely manage the lifecycle of a machine.

The PTF is therefore **not only input for software development**,\
but **a central management and evidence document** for the entire project team – from engineering to management.

***

### 2) Objective

* **Create clarity**, who gains what benefit from the PTF
* **Responsibilities** and **Dependencies** define
* **Establish transparency over risks, interfaces and releases** establish
* **Ensure traceability over the entire machine lifecycle** ensure

> The PTF makes every role visible – and gives each role a tool to exercise its responsibility based on facts.

***

### 3) Overview: All stakeholders of a Selmo project

| Category                     | Role / function                    | Typical designation          | Responsibility in the project                  |
| ---------------------------- | ---------------------------------- | ---------------------------- | ---------------------------------------------- |
| **Project control**          | Project management, PTF lead       | PM, PTF manager              | Coordination, schedule, quality, release       |
| **Process & product**        | Process owner, industrial engineer | Process owner                | Process definition, target states, parameters  |
| **Engineering (mechanical)** | Designer, plant planner            | ME / head of design          | Mechanical implementation, safety, layout      |
| **Engineering (electrical)** | Hardware planner, E-plan           | EE / electrical planning     | I/O, sensors, actuators, wiring                |
| **Automation**               | Software developer, Selmo modeler  | Automation engineer          | Implementation in sequence, zones, bit control |
| **Quality & safety**         | CE, safety, QM                     | Safety officer / QMB         | Standards review, risk assessment, evidence    |
| **IT / OT / data**           | MES, ERP, SCADA, cloud             | Data engineer / OT architect | Interfaces, data flow, IT security             |
| **Operation / Maintenance**  | Production, service                | Operator / maintenance       | Operation, diagnostics, maintenance            |
| **Management & controlling** | Executive management, purchasing   | Management, controller       | Cost-effectiveness, traceability               |
| **Customer / end user**      | Operator, auditor                  | OEM / end customer           | Availability, evidence, safety                 |

***

### 4) Customer groups and benefits from the PTF

#### **4.1 Project management / PTF lead**

**Why they need the PTF:**\
To control the project *methodically, risk-based and transparently* .

**What they get:**

* Complete overview of process, technology, function and risk
* Clear release points and milestones
* Documented interfaces and responsibilities
* Assessed risks and residual risks

**Benefit:**

* Planability, quality assurance, reduction of rework
* Evidence of engineering processes (audit capability)
* Project responsibility secured legally and organizationally

***

#### **4.2 Process owner / industrial engineering**

**Why:**\
They are responsible for the actual process flow and its efficiency.

**What they get:**

* Transparent description of all process steps and states
* Parameter lists with tolerances and limits
* Traceable linkage between physical process and control logic

**Benefit:**

* Clear handover to technology and automation
* Early risk detection for process changes
* Evidence of process quality and stability

***

#### **4.3 Mechanical and electrical design**

**Why:**\
Their designs must be integrated deterministically into the control process.

**What they get:**

* Link between physical component (e.g., cylinder, sensor) and logical state
* I/O list with zone and CMZ assignment
* Feedback on non-Selmo-compliant signals

**Benefit:**

* Early detection of inconsistencies between mechanics, electrical and software
* Ensuring feasibility and compliance
* Evidence of safety-related functions

***

#### **4.4 Automation / Software Development**

**Why:**\
You generate the Selmo model and thus the code from the PTF.

**What they get:**

* Complete, released process definition
* Structured Selmo architecture (Plant, HWZ, SEQ, zones, parameters, bit control)
* Function sheets and test cases

**Benefit:**

* Unambiguous, interpretation-free implementation
* Formally verifiable code
* Minimized implementation and debugging time
* Direct traceability between model and PTF

***

#### **4.5 Quality / Safety / CE**

**Why:**\
You must demonstrate compliance with standards, functional safety and risk minimization.

**What they get:**

* PTF risk assessment (PTF-RISK)
* Documentation of protective measures, CMZ, MXIC, interlocks
* Deviation list (technical & organizational)

**Benefit:**

* Complete audit evidence
* Clear assignment of risks and responsibilities
* Minimization of legal liability risks
* CE documentation derivable directly from the PTF

***

#### **4.6 IT / OT / Data Systems**

**Why:**\
Because they provide interfaces and data flows that must be secure and deterministic.

**What they get:**

* Interface description (PTF-IF)
* Communication definitions (protocols, topics, payloads)
* Requirements for data quality and security

**Benefit:**

* Reproducible data flows
* Traceable coupling between production and IT
* Standards compliance according to IEC 62443

***

#### **4.7 Operations / Maintenance**

**Why:**\
You use the system in everyday life and are responsible for safety and availability.

**What they get:**

* HMI structure with states, colors, messages (PTF-HMI)
* Diagnostics and manual operation logic (MXIC, CMZ, interlocks)
* Documented process and error responses

**Benefit:**

* Transparent operation and troubleshooting
* Reduction of downtime
* Proof of safe operation

***

#### **4.8 Management / Controlling**

**Why:**\
Because they must assess investment security, process maturity and reusability.

**What they get:**

* Overall overview of project status and maturity level
* Cost/benefit consideration from PTF assessments
* Transparent risk situation

**Benefit:**

* Predictability and economic efficiency
* Reduction of hidden efforts
* Evidence for governance, compliance and quality

***

#### **4.9 Customer / Operator / End User**

**Why:**\
Because they will operate, audit or accept the machine later.

**What they get:**

* Documented, traceable process description
* Proof of deterministic and safe control
* Complete traceability from requirements to code
* PTF as part of the CE documentation

**Benefit:**

* Confidence in function, safety and quality
* Clear traceability for changes and service
* Simplified maintenance and training

***

### 5) Summary: Who uses the PTF for what?

| Role                   | Uses the PTF for …                  | Goal / Benefit                |
| ---------------------- | ----------------------------------- | ----------------------------- |
| Project management     | Control, release, proof             | Control, transparency         |
| process                | Definition, parameters, efficiency  | Process quality               |
| Mechanics / Electrical | Integration, signal definition      | technical feasibility         |
| Software / automation  | Modeling, code                      | deterministic control         |
| Quality / Safety       | Assessment, evidence                | Risk and standards compliance |
| IT / OT                | Interfaces, data exchange           | secure communication          |
| Maintenance            | Operation, diagnostics              | Operational safety            |
| Management             | Economic efficiency, responsibility | Basis for decisions           |
| Customer / Operator    | Operation, audit                    | Trust and transparency        |

***

### 6) Impact on the overall project

The PTF creates for all stakeholders:

* **trust** through traceability,
* **Efficiency** through clear handovers,
* **safety** through documented risks,
* **Standardization** through reusability,
* **Economic efficiency** through avoidance of frictional losses,
* **Compliance** through formal conformity to standards and guidelines.

***

### 7) Conclusion for the kick-off

> Every stakeholder benefits from the PTF –\
> the process engineer through clarity,\
> the programmer through structure,\
> the quality manager through evidence,\
> management through security.
>
> The PTF is therefore not just a technical document,\
> but the **responsibility model of a project.**\
> It translates process knowledge into deterministic control –\
> and makes every machine safe, verifiable and explainable.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://infosys.selmotech.com/selmo-solution/selmo-solution-en/selmo-as-a-process/selmo-ptf/3.-sipoc-structure-of-the-ptf.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.