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

# 🧭 Selmo process modeling in the overall project timeline

#### **1. Starting point: The problem in classical projects**

In conventional machine projects a central problem arises:

* The process is understood – but not described formally.
* The requirements are documented – but not implemented unambiguously.
* The code works – but is not explainable or verifiable.

This leads to:

* **Deviations between process and software**,
* **Increases in time and costs** during commissioning,
* **Black-box code**, which no one can trace,
* **missing evidence** for standards, safety and quality.

**Selmo solves exactly this problem**,\
by generating from the process description a **formal, deterministic and documented process model** – visible, verifiable and automatically executable.

***

#### **2. Role of process modeling in the project flow**

**Process modeling is the bridge between definition (PTF) and implementation (software & commissioning).**\
It translates requirements into an executable, traceable and documented machine behavior.

```
Customer requirement (problem)
   ↓
PTF – Process, Technology, Function (What is needed?)
   ↓
Selmo process modeling (How does it work?)
   ↓
Code / HMI / Documentation (How is it executed?)
   ↓
Digital twin / Commissioning (How is it tested?)
   ↓
Operation / Service (How does it remain traceable?)
```

**Central statement:**

> The PTF describes *what* what the machine should do.\
> Process modeling shows *how* that it does so deterministically.\
> And the code executes it formally correctly.

***

#### **3. Why process modeling is necessary**

| Problem statement                                  | Selmo solution                                             | Benefit                        |
| -------------------------------------------------- | ---------------------------------------------------------- | ------------------------------ |
| Unclear translation of requirements into software  | Formal model as an intermediate layer between PTF and code | No interpretation errors       |
| Individually written logic, not verifiable         | Model generates deterministic, verifiable code             | Traceability and verifiability |
| Missing structure / dependencies between processes | Structure model: Plant → HWZ → SEQ → Zone                  | Transparency and reusability   |
| Lack of safety / standard compliance               | CMZ and MXIC rules as part of the model                    | Safety formally guaranteed     |
| No documentation of the code                       | Automatic documentation (system, logic, safety layer)      | CE- and audit-capability       |
| Late error detection                               | SoftFAT / Digital Twin integration                         | Early validation, time savings |
| Dependence on individual programmers               | Standardized, formally defined modeling                    | Company-wide reusability       |

***

#### **4. What happens in the process modeling?**

The **process modeling** builds on the results of the **PTF** and systematically translates them into a formal machine model:

| Phase                    | Activity                                         | Result                              |
| ------------------------ | ------------------------------------------------ | ----------------------------------- |
| **1. Structuring**       | Create plant, zones (HWZ, SEQ, Zone)             | Logical machine structure           |
| **2. System layer**      | Define signal behavior (bit control: 0, i, S, M) | Automatic behavior documented       |
| **3. Logic layer**       | Model states and transitions                     | Process logic visible and traceable |
| **4. Parameter layer**   | Define values, times, tolerances                 | Flexibility through configurability |
| **5. CMZ / MXIC**        | Define safety and manual operation behavior      | CE-compliant safety                 |
| **6. SEQCross**          | Synchronize processes between sequences          | Modular, scalable structure         |
| **7. Validation / Test** | Run simulation or SoftFAT                        | Error-free, tested logic            |
| **8. Generate output**   | Code, HMI, documentation, safety reports         | Complete, verifiable machine output |

***

#### **5. Why process modeling is placed at this point in the project**

| Time                            | Task                                    | Result / Goal                                     |
| ------------------------------- | --------------------------------------- | ------------------------------------------------- |
| **After PTF approval**          | Transfer all PTF data into the model    | Ensure complete, verified requirements            |
| **Before PLC programming**      | Create the formal process model         | Deterministic code can be generated automatically |
| **Before SoftFAT / Simulation** | Connect the model with the digital twin | Virtual commissioning possible                    |
| **Before commissioning (IBN)**  | Check code, HMI, safety                 | Time gain, risk minimization                      |
| **In operation / service**      | Use the documentation, HMI, parameters  | Transparent maintenance, training, optimization   |

**Central importance:**

> Process modeling replaces the unstructured programming process\
> with a **formal, documented and traceable modeling process.**

***

#### **6. Benefits in the overall project (from problem to added value)**

| Perspective                | Before Selmo (problem)                           | With Selmo process modeling (solution) | Direct benefit                          |
| -------------------------- | ------------------------------------------------ | -------------------------------------- | --------------------------------------- |
| **Project management**     | Lack of transparency, hardly verifiable software | Complete, documented model             | Predictability, safety, demonstrability |
| **Process owner**          | Process is not implemented exactly               | Logic and behavior visibly modeled     | Traceable implementation                |
| **Mechanics / Electrical** | Poor coordination with controls                  | Structure reflects real machine        | Better coordination                     |
| **Software / automation**  | Individual codebase, unclear status              | Standardized modeling, automated code  | Quality, reusability                    |
| **Quality / CE**           | No evidence of behavior                          | Formal documentation, safety layer     | CE- and audit-capability                |
| **Operations / Service**   | Black-box behavior, no clear diagnosis           | HMI & logic are congruent              | Fast fault localization                 |
| **Customer / Operator**    | No traceability of behavior                      | Documented, tested machine model       | Trust, transparency, safety             |

***

#### **7. The “why” at the core – the benefit from the customer’s perspective**

* **Why model instead of program?**\
  Because models **are verifiable, explainable and reusable** – programs alone are not.
* **Why now, after the PTF?**\
  Because here all requirements are validated before they are implemented technically –\
  changes are still inexpensive, errors still reversible.
* **Why relevant for all participants?**\
  Because the model connects all disciplines:\
  mechanical, electrical, process, software, quality and operations.

> Process modeling turns isolated specialist departments into a consistent system understanding.\
> Everyone sees the same thing – in a formal, unambiguous language.

***

#### **8. Result in the overall context**

**Process modeling = formal implementation of the PTF results**\
→ It generates the “digital twin of the behavior” of a machine –\
even before the hardware actually exists.

This creates:

* **A model instead of an interpretation**,
* **Documented code instead of individual logic**,
* **Visible behavior instead of a black box**,
* **Reproducible engineering instead of one-off knowledge.**

***

#### **9. Conclusion – Why & What**

**Why:**\
Because every project needs clear, formal and verifiable logic.\
Selmo ensures technical and normative correctness from definition to execution.

**What:**\
A complete, formal, documented machine behavior –\
logical, safe, deterministic and verifiable.

**How:**\
Through the standardized process of Selmo modeling –\
from the PTF through logic, system, parameters, safety and HMI to the code.

***

> **With the PTF knowledge is collected –**\
> **with the process modeling knowledge is applied.**
>
> It is the moment when requirements become reality –\
> precise, safe and traceable.
>
> This aligns the entire Selmo engineering process\
> **thought from the problem** and\
> **toward documented technical excellence.**


---

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