> 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-process-modeling/responsibilities-in-the-selmo-process.md).

# ⚖️ Responsibilities in the Selmo process

### **1st Principle**

Selmo is a **formal method for defining and implementing machine behavior** –\
comparable to the technical drawing in mechanical engineering and the circuit diagram in electrical engineering.

Selmo describes, **how a process should run technically and logically correctly**,\
not, **which process** is sensible in content or which hardware works physically.

> **Selmo is a language, not an engineer.**
>
> Responsibility for content, execution and outcome remains with the subject-matter disciplines and the economic operator.

***

### **2. Roles and responsibilities in the project**

| Discipline / Role                                  | Area of responsibility                                                      | Responsibility according to Selmo                                                                               |
| -------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Requirement issuer / Customer**                  | Definition of the desired process, function and objective                   | Provides complete and verifiable requirements (PTF-REQ). Must authorize changes to the process or the function. |
| **Process owner (Industrial Engineering)**         | Process description, cycle time, parameters, states, functional requirement | Has the process knowledge. Must ensure that the described process is actually executable.                       |
| **Mechanics / Mechanical Engineering**             | Mechanical implementation, assemblies, kinematics, end positions            | Responsible for functionality and safety of the physical components.                                            |
| **Electrical / Control (E-Plan)**                  | Electrical planning, I/O structure, protective circuits, safety engineering | Responsible for power supply, signal availability and standards-compliant wiring.                               |
| **Automation / Software (Selmo modeler)**          | Implementation of the PTF requirements into the Selmo process model         | Responsible for formal correctness, completeness and determinism of the control logic.                          |
| **PTF lead / Project management**                  | Overall coordination, documentation, quality, interfaces                    | Responsible for completeness, approvals and project conformance (PTF ↔ model).                                  |
| **Quality / Safety / CE**                          | Review of standards conformity, risk assessment, approval                   | Responsible for CE conformity, safety evidence and risk documentation.                                          |
| **Economic operator (machine/plant manufacturer)** | Bringing together all disciplines into a functioning machine                | Bears the overall responsibility for meeting customer requirements, safety and intended operation.              |

***

### **3. Principle of responsibility according to Selmo**

Selmo brings **responsibility and traceability** into a clear sequence:

1. **PTF describes the responsibility of the definition**\
   → The process is described, reviewed and approved.\
   → Any uncertainty must be clarified here, not later in the code.
2. **Process model describes the responsibility of the implementation**\
   → The logic is modeled so that it is deterministic and formally correct.\
   → Errors in the logic or deviations from the specification are immediately visible.
3. **Code and control describe the responsibility of the execution**\
   → If the code deviates from the model, this is a violation of the approval.\
   → Changes must be traceably entered in the model and in the PTF.
4. **Operation and service describe the responsibility of the use**\
   → The operator uses a formally documented, reviewed system.\
   → Any change to behavior must be documented via change management.

***

### **4. Exemplary analogy**

| Comparison         | Mechanical engineering                 | Electrical engineering                 | Automation (Selmo)                   |
| ------------------ | -------------------------------------- | -------------------------------------- | ------------------------------------ |
| **Formal basis**   | Technical drawing                      | Circuit diagram                        | Process model                        |
| **Tool**           | CAD system                             | EPLAN                                  | Selmo Studio                         |
| **Description**    | Geometry, tolerances, movement         | Circuit, wiring diagram, I/O           | States, logic, signals, safety       |
| **Test equipment** | Dimensional inspection, CAD validation | Continuity test                        | Logic validator, simulation          |
| **Deviation**      | Part does not fit → check drawing      | Signal missing → check circuit diagram | Behavior wrong → check process model |
| **Reaction**       | Adjust the drawing or rework           | Adjust the circuit diagram or wiring   | Adjust the process model or PTF      |

> **Selmo follows the same principle as design:**\
> A deviation in reality does not lead to a “workaround in the field”,\
> but to an adjustment of the formal description.

***

### **5. Handling deviations**

#### **Case A – Deviation in the code**

* If it is found during commissioning or testing that the code **does not correspond to the process model**,\
  → the code must **not be manually** corrected,\
  → but the **Process model** adjusted and regenerated.
* Every change is documented and versioned (audit trail).

#### **Case B – Hardware deviation from the specification**

* If sensors, actuators or interfaces **do not correspond to the PTF definition**,\
  → the **technology description (PTF-TECH)** is adjusted.\
  → Only after this adjustment may the model be updated.

#### **Case C – Non‑Selmo‑compliant implementation**

* If the machine builder **implements parts of the plant not in Selmo-compliant manner**,\
  e.g. incomplete logic, missing CMZ or manual “special functions”,\
  → this is marked in the PTF as **“Non‑Selmo‑compliant”** marked.\
  → These functions are **not formally verifiable**,\
  → they are considered **documented risk**,\
  → and the **responsibility** lies with the **Marketing authorization holder** or with the **customer**.

***

### **6. Responsibility for the process**

The **process owner** defines, **what** what is to be achieved.\
Selmo ensures that **how** it is implemented deterministically, safely and documented.\
The **Marketing authorization holder** bears the responsibility that the machine as a whole –\
mechanics, electrics, control and process –\
**executes the defined behavior safely and in compliance with standards.**

> **Selmo cannot compensate for faulty engineering.**
>
> However, it can **make it visible** –\
> and thereby turn uncertainty into a documented responsibility.

***

### **7. Limits of the method**

Selmo guarantees:

* formal correctness of the process model,
* deterministic execution,
* automatic traceability,
* safety through CMZ / MXIC / interlock logic,
* complete documentation.

Selmo **does not guarantee**:

* the technical functionality of the hardware,
* the physical feasibility of a process,
* the completeness or logic of the customer-side requirements,
* the quality of the installation or commissioning,
* the responsibility of the economic operator for safety and liability.

***

### **8. Responsibility in case of error**

| Situation                                          | Assessment                                         | Responsible                                |
| -------------------------------------------------- | -------------------------------------------------- | ------------------------------------------ |
| **Logic error in the model**                       | formal error, visible in the validator             | Selmo modeler / Automation                 |
| **Function deviates from the PTF**                 | Deviation from the specification, to be documented | Process owner / PTF lead                   |
| **Hardware does not function as specified**        | fault in execution / integration                   | Mechanics / Electrical / Economic operator |
| **Non‑Selmo‑compliant logic or bypass**            | documented risk, not verifiable                    | Economic operator / Customer               |
| **Deviation discovered only during commissioning** | Failure in PTF or model review                     | Project management / PTF lead              |

***

### **9. Conclusion**

> Selmo does not replace **the responsibility of the engineers**,\
> but gives them **a tool to carry it out demonstrably.**

Selmo makes visible,

* **where a process was correctly described**,
* **where an implementation was carried out correctly**,
* and **where deviations or risks exist**.

Thus a **engineering system is created that structures responsibility** –\
from the customer to the economic operator.

**Selmo stands for:**

* formal language, not interpretation,
* traceability instead of assumption,
* correction in the model instead of improvisation in the code,
* and documented responsibility instead of scapegoating.

***

**In short:**

> Selmo is the CAD system for logic.
>
> It draws, checks, documents and proves the behavior –\
> but it does not replace the designer.
>
> Responsibility remains human –\
> Selmo only makes it finally **visible and traceable.**


---

# 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-process-modeling/responsibilities-in-the-selmo-process.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.
