> 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.md).
# Selmo process modeling
The **process modeling** is the central implementation step between the **PTF (Process – Technology – Function)**\
and the **technical realization** in code, HMI and documentation.
It forms the **formal, deterministic machine behavior** —\
visible, testable and traceable.
The aim of this chapter is to present the entire process of modeling, the associated roles, inputs, procedures, outputs and responsibilities\
in a **uniform, SIPOC-based structure** representation.
**Goal:**\
Clear separation of roles and responsibility in definition, implementation, verification and operation.
**Main statements:**
* Selmo is a method, not a decision-making authority.
* Process content and physical execution lie with the customer, mechanics, electrical engineering.
* Selmo ensures formal, verifiable implementation of the approved requirements.
* Deviations between model and reality are immediately visible.
* Changes are made **not in the code**, but in the model or PTF.
* Non-Selmo-compliant areas are documented and assessed as a risk.
* **Marketing authorization holder** bears overall responsibility for the machine and process.
## Stakeholder benefit matrix
**Goal:**\
Overview of who gains which benefit from the modeling.
**Key points:**
* Process engineer: sees that the process has been implemented.
* Automation: works with a formal, structured language.
* CE / Quality: has auditability.
* Service: benefits from clear diagnostics.
* Customer: receives a verifiable, trustworthy result.
* Management: gains predictability and traceability.
**Example matrix:**
```
Stakeholder | Output | Benefit
-------------|---------|--------
Process | Documentation | Validation of process logic
Automation | Model / Code | Error-free implementation
Quality | Safety report | Compliance with standards
Service | HMI / Diagnostics | Maintenance friendliness
Customer | Process model | Transparency, trust
```
Stakeholder benefit matrix – Process modeling according to Selmo
#### **1. Overview matrix**
| **Stakeholder / Role** | **Relevant outputs from the modeling** | **Project phase** | **Benefit / Added value** |
| ----------------------------------------- | -------------------------------------------------------------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Project management / PTF lead** | PTF model documentation, review report, approval protocol | *Engineering / Review* | Evidence of successful, PTF-compliant implementation; transparency about quality and status |
| **Process owner (IE)** | Logic and system documentation, parameter tables | *Engineering / Validation* | Ensuring that the real process has been represented technically correctly, deterministically and traceably |
| **Mechanics / Design** | Model structure (Plant → HWZ → SEQ → Zones), technology report | *Engineering / Coordination* | Control whether the mechanical structure is correctly linked in the process model; easier error analysis |
| **Electrical / Control (E-Plan)** | I/O mapping, bit control, CMZ/MXIC documentation | *Engineering / Commissioning* | Unambiguous signal and address linking, synchronization of circuit diagram and logic |
| **Software / Automation (Selmo modeler)** | Selmo model file (.XML/.SEL), function library, PLC code | *Modeling / code generation* | Efficient, standardized development; error-free, deterministic code |
| **Quality / Safety / CE** | Safety report, CMZ/MXIC matrix, risk assessment | *Review / Audit / CE evidence* | Formal verifiability, auditability, CE conformity; no safety-related risk without evidence |
| **IT / OT / MES / ERP** | Interface description, communication model | *Integration / Test / SoftFAT* | Unified, documented data and communication points; secure connection to higher-level systems |
| **Operation / Maintenance / Service** | HMI project, diagnostic lists, parameter data | *Commissioning / Operation* | Transparent operation, clear fault diagnosis, reduced downtime |
| **Management / Controlling** | Project reports, function library, risk reports | *Project controlling / Reporting* | Reliable planning and cost certainty, standardized implementation, reduction of engineering risks |
| **Customer / Operator / End user** | Complete process documentation, safety evidence, HMI | *Acceptance / Operation / Audit* | No black box: formal, traceable process description; trust, safety and transparency |
***
#### **2. Benefits by perspective (cluster)**
| **Perspective** | **Main benefits through Selmo process model** |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Technical / Engineering** | Complete transparency about logic, states and signal behavior; reproducible implementation without interpretation gaps |
| **Quality / Safety** | Formal verifiability, documented safety logic, CE evidence directly from the model |
| **Organizational / Management** | Standardized procedures, less rework, clearly defined responsibilities |
| **Operation / Service** | Clear diagnostics, structured HMI, easy training and maintenance |
| **Customer / Operator** | Traceability and trust – the process is visible, verifiable and compliant with the standard |
***
#### **3. Assignment of stakeholders to phases**
```
╔════════════════════════════════════════════════════════════════════════╗
║ PROJECT PHASES OF MODELING AND USE OF OUTPUTS ║
╚════════════════════════════════════════════════════════════════════════╝
PTF approval → modeling → validation → code generation → SoftFAT → commissioning → operation / audit
────────────────┬────────────────┬────────────────┬─────────────────┬───────────┬────────┬───────────────
│ │ │ │ │ │
Project management │■■■■ Approval │ Control report │ │ │ │
Process owner │■■■■ Definition │■■ Validation │■■ Audit approval │ │ │
Automation │■■ Modeling │■■ Code Gen. │■■ Test │ │ │
Electrical/Mech. │■■ Data reconciliation│ │■■ FAT │■■ Commissioning│ │
Quality/CE │ │■■ Risk review │■■ Compliance │ │■■ Audit│
IT/OT │ │■■ Integration │■■ SoftFAT │■■ MES test│ │
Operation/Service │ │ │ │■■ Commissioning│■■ Operation│
Customer/Operator │ │ │ │■■ FAT │■■ Operation / CE │
```
*Legend:*\
■ = Phase with direct involvement or benefit for the respective role.
***
#### **4. Overall summary**
**Who benefits most from the process model:**
* **Process owners & customers:**\
do not get black box code, but a **formal, documented machine behavior**,\
that exactly matches their requirements and is verifiable at any time.
* **Software and automation engineers:**\
benefit from **clear structures**, **automated code generation** and **reduced error rate**.
* **Safety and quality managers:**\
can **reconstruct every state and every interlock condition** and prove it to audits.
* **Operation & Service:**\
receive **a logical, standardized operation and diagnostics**,\
that greatly simplifies maintenance, training and troubleshooting.
* **Management and customer:**\
gain **transparency, safety and trust** – the machine is not an unknown code block,\
but a **digitally defined, standards-compliant process**.
***
#### **5. Conclusion**
> The customer of the Selmo process model receives **not software, but knowledge.**
>
> Knowledge about the behavior, logic and safety of the machine —\
> visible, testable and documented.
>
> Each stakeholder receives **exactly the information they need**,\
> in the language they understand – technical, formal, operation-oriented.
Conclusion
* Process modeling is the **link** between requirement and implementation.
* It provides **transparent, traceable machine logic** instead of untestable code.
* It creates the **same structure and traceability** as mechanics and electrical engineering.
* Changes are made **always in the formal description**, never in the running code.
* Non-Selmo-compliant areas are **deliberately documented risks**.
* Thus Selmo is the **formal language of automation** —\
a tool for quality, responsibility and trust.
---
# 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.md?ask=&goal=
```
`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.