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: