> 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-documentation/2-selmo-big-picture/vom-prozess-zum-code/vom-prozess-zum-lauffahigen-system.md). # Vom Prozess zum lauffähigen System Dieses Kapitel beschreibt, **wie aus einem gedanklichen Modell ein real laufendes System wird** –\ und warum dieser Weg in Selmo **gerichtet, konsistent und nachvollziehbar** ist. Es geht nicht um Implementierungsdetails,\ sondern um die **logische Kette von Ursache und Wirkung**. *** ### Der grundlegende Gedanke In klassischen Projekten entstehen viele Artefakte parallel: * Code * HMI * Diagnose * Dokumentation Diese Artefakte: * haben unterschiedliche Quellen * entwickeln sich unterschiedlich schnell * verlieren mit der Zeit ihre Konsistenz Selmo verfolgt einen anderen Ansatz: > **Es gibt eine Quelle der Wahrheit: das Modell.** Alles Weitere ist **eine Ableitung** daraus. *** ### Vom Modell zur SPS Das **Selmo-Modell** beschreibt: * Zustände * Erwartungen * Überwachung * Reaktionen Dieses Modell ist: * vollständig * deterministisch * formal beschrieben Aus diesem Modell wird der **SPS-Code abgeleitet**: * nicht als kreative Übersetzung * sondern als konsequente Umsetzung * ohne zusätzliche Logikannahmen Der Code enthält: * keine impliziten Zustände * keine versteckten Übergänge * keine nicht modellierten Sonderfälle > **Der Code implementiert das Modell –**\ > **er erweitert es nicht.** *** ### Vom Modell zum HMI Das HMI entsteht in Selmo **nicht als eigenständiges Konzept**. Es ist eine **Visualisierung des Modells**: * aktive Sequences * aktuelle Zustände * relevante Zonen * Erwartungen und Abweichungen Das HMI: * entscheidet nichts * interpretiert nichts * kompensiert keine Logik Es zeigt: > **Was das Modell aktuell sagt.** Damit ist das HMI: * konsistent zum Ablauf * projektübergreifend verständlich * unabhängig von individueller Gestaltung *** ### Vom Modell zur Diagnose Weil Verhalten explizit modelliert ist, entsteht Diagnose **automatisch**. Eine Diagnose ergibt sich aus: * aktivem Zustand * zugehöriger Zone * erwarteter Bedingung * tatsächlichem Signalzustand Es gibt: * keine manuell gepflegten Fehlermeldungen * keine Sammelstörungen * keine Interpretation durch den Programmierer > **Diagnose ist die formale Abweichung vom Modell.** *** ### Vom Modell zur Dokumentation Das Modell enthält bereits: * Ablaufbeschreibung * Zustandsdefinitionen * Sicherheitsannahmen * Überwachungslogik * Reaktionsverhalten Daraus lassen sich ableiten: * technische Dokumentation * Ablaufbeschreibungen * Sicherheitsargumentationen * Audit-Nachweise Dokumentation ist damit: * immer aktuell * konsistent zum System * nicht von Hand gepflegt > **Das Modell ist die Dokumentation.** Modell\ ↓\ SPS\ ↓\ HMI\ ↓\ Diagnose\ ↓\ Dokumentation Diese Kette ist: * gerichtet * verlustfrei * nachvollziehbar Es gibt **keine Rückkopplung**,\ bei der Logik im Code oder im HMI entsteht. *** ### Bedeutung für Betrieb und Verantwortung Durch diese Struktur ist jederzeit klar: * warum sich die Maschine so verhält * woher eine Meldung stammt * welche Annahmen gelten * welche Reaktion vorgesehen ist Das ist entscheidend für: * Inbetriebnahme * Betrieb * Änderungen * Sicherheit * Haftung > **Was aus einem Modell entsteht,**\ > **kann auch auf das Modell zurückgeführt werden.** *** ### Einordnung Dieses Kapitel beschreibt den **Fluss**,\ nicht die Details der einzelnen Schritte. Die folgenden Kapitel erklären: * wie das Modell aufgebaut ist * wie Verhalten beschrieben wird * wie Betrieb und Sicherheit wirken > **Selmo ersetzt keine Systeme –**\ > **es ordnet sie.** *** ### Die durchgängige Kette Zusammengefasst ergibt sich eine klare Kette: --- # 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-documentation/2-selmo-big-picture/vom-prozess-zum-code/vom-prozess-zum-lauffahigen-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.