# 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:
