> 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-documentation/2-selmo-big-picture/from-process-to-code/from-the-process-to-the-runnable-system.md). # From the process to the runnable system This chapter describes, **how a conceptual model becomes a real running system** –\ and why this path in Selmo **directed, consistent and traceable** is. It is not about implementation details,\ but about the **logical chain of cause and effect**. *** ### The basic idea In classic projects many artifacts arise in parallel: * Code * HMI * diagnosis * Documentation These artifacts: * have different sources * develop at different speeds * lose their consistency over time Selmo follows a different approach: > **There is one source of truth: the model.** Everything else is **a derivation** from it. *** ### From the model to the PLC The **Selmo model** describes: * States * Expectations * monitoring * Reactions This model is: * complete * deterministically * formally described From this model the **PLC code is derived**: * not as a creative translation * but as a consistent implementation * without additional logical assumptions The code contains: * no implicit states * no hidden transitions * no unmodeled special cases > **The code implements the model –**\ > **it does not extend it.** *** ### From the model to the HMI The HMI is created in Selmo **not as an independent concept**. It is a **visualization of the model**: * active sequences * current states * relevant zones * expectations and deviations The HMI: * decides nothing * interprets nothing * does not compensate for logic It shows: > **What the model currently says.** Thus the HMI is: * consistent with the process * understandable across projects * independent of individual design *** ### From the model to diagnostics Because behavior is explicitly modeled, diagnostics arise **automatically**. A diagnosis results from: * active state * associated zone * expected condition * actual signal state There are: * no manually maintained error messages * no aggregate faults * no interpretation by the programmer > **Diagnosis is the formal deviation from the model.** *** ### From the model to documentation The model already contains: * Process description * State definitions * Safety assumptions * Monitoring logic * Reaction behavior From this one can derive: * technical documentation * process descriptions * safety arguments * audit evidence Documentation is therefore: * always up to date * consistent with the system * not maintained by hand > **The model is the documentation.** Model\ ↓\ PLC\ ↓\ HMI\ ↓\ Diagnostics\ ↓\ Documentation This chain is: * directed * lossless * traceable There is **no feedback**,\ where logic is created in the code or in the HMI. *** ### Meaning for operation and responsibility Because of this structure it is always clear: * why the machine behaves that way * where a message comes from * which assumptions apply * which response is intended This is crucial for: * Commissioning * Operation * Changes * Safety * liability > **What is produced from a model,**\ > **can also be traced back to the model.** *** ### Classification This chapter describes the **flow**,\ not the details of the individual steps. The following chapters explain: * how the model is structured * how behavior is described * how operation and safety work > **Selmo does not replace systems –**\ > **it organizes them.** *** ### The end-to-end chain In summary, a clear chain emerges: --- # 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-documentation/2-selmo-big-picture/from-process-to-code/from-the-process-to-the-runnable-system.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.