Prozesstechnik
P&IDprozesstechnische Struktur
Behavior Defined Machines
Für alles gibt es einen Plan.
Nur nicht für Verhalten.
01 — Der Befund
Vier Disziplinen haben ihre Sollstruktur.
Die fünfte hat nur den Code.
P&ID, Stromlaufplan, Zeichnung und Messstellenliste sind nicht bloß Dokumentation. Sie definieren normativ. Verhalten dagegen liegt verteilt in Funktionsbeschreibung, HMI-Spezifikation und Parametertabellen — und vollständig nur im Code.
Elektrotechnik
Stromlaufplanelektrische SollstrukturMechanik
ZeichnungGeometrie und AufbauInstrumentierung
MessstellenlisteMessstrukturVerhalten
— fehlt —kein Artefakt trägt Verhalten normativDas ist kein Vorwurf an das Engineering. Es fehlt ein Objekt, nicht eine Fähigkeit.
02 — Die eigentliche Lücke
Die eigentliche Lücke
Auch eine bestandene Abnahme beweist weniger, als sie verspricht.
Nehmen wir den besten Fall an: Das Sollverhalten ist vollständig beschrieben, widerspruchsfrei, abgestimmt und freigegeben. Alles richtig gemacht.
Selbst dann ist über die Realisierung nichts bewiesen. Denn die Übersetzung dieses Solls in Code, HMI, Dokumentation und Datenstruktur ist heute nur durch Beobachtung prüfbar — durch Test, Simulation, virtuelle Abnahme, Inbetriebnahme. Und Beobachtung hat zwei Grenzen.
Eine bestandene Abnahme ist eine Momentaufnahme einer Stichprobe. Genau diese Lücke schließt Selmo.
Grenze 01 · Zustandsraum
Sie prüft eine Stichprobe
Getestet wird, was im Test auftrat: der Normalablauf, die geplanten Störfälle, die Kombinationen, an die jemand gedacht hat. Der reale Zustandsraum — Betriebsarten mal Rezepturen mal Störungslagen mal Wiederanlaufsituationen — ist um Größenordnungen größer.
Was nie beobachtet wurde, ist nicht geprüft. Es ist nur nicht aufgefallen.Grenze 02 · Zeitpunkt
Sie gilt für einen Zeitpunkt
Ein Beobachtungsnachweis beschreibt einen Systemzustand, keine Systemeigenschaft. Eine Codeanpassung, ein verstellter Parameter, ein getauschter Sensor, ein neues Rezept — jede Änderung setzt ihn außer Kraft.
Und niemand bemerkt, wann er verfallen ist.
03 — Das fehlende Objekt
Ein Objekt schließt die Lücke.
Nicht mehr Beobachtung.
Beobachtung lässt sich verfeinern, aber ihre beiden Grenzen bleiben. Was fehlt, ist kein besseres Prüfverfahren, sondern ein Artefakt, gegen das geprüft werden kann.
01
Das Objekt
Behavior Reference (BR)
So wie ein Stromlaufplan die elektrische Sollstruktur definiert, definiert die Behavior Reference (BR) die Sollstruktur des Verhaltens: Zustände und Situationen, Aktionen, erwartete Reaktionen, aufrechtzuerhaltende Bedingungen, Transitionen, Verriegelungen, Berechtigungen, Parameter, Zeiten, Schnittstellen sowie Restart- und Recovery-Verhalten. Die Behavior Reference (BR) ist keine nachträgliche Dokumentation des Codes. Sie entsteht vor dem Code.
02
Das Vorgehen
Behavior-Centric Engineering (BCE)
Verhalten wird vor der Implementierung definiert und freigegeben. Am Behavior Gate lautet die Frage nicht, ob ein Programmierer beginnen kann, sondern ob das erwartete Verhalten so vollständig definiert ist, dass die Implementierung kein eigenes Verhalten erfinden muss. Ein Gate ist eine Entscheidung — kein Termin und kein Review.
03
Die Maschine
Behavior Defined Machine (BDM)
Code, HMI, Dokumentation und Datenstruktur werden aus derselben freigegebenen Referenz abgeleitet, ohne Interpretationsverlust. Damit wird aus einer Übersetzung eine Ableitung: Der Interpretationsspielraum verschwindet nicht durch bessere Prüfung, sondern durch den Wegfall des Interpretationsschritts.
Verifikation fragt: Wurde richtig gebaut? Validierung fragt: Wurde das Richtige gebaut?
Selmo beantwortet die erste Frage — gegen die freigegebene Behavior Reference (BR), mit daraus abgeleiteter Test- und Abnahmelogik. Die zweite bleibt die Prüfung gegen Ihren Intent, und sie bleibt notwendig.
04 — BlackBox → WhiteBox
Heute
BlackBox
Verhalten wird erst durch die Implementierung vollständig sichtbar — damit wird faktisch der Code zum führenden Artefakt. Im Betrieb wird Verhalten aus Symptomen rekonstruiert: Signale untersuchen, Code lesen, Annahmen erschließen. Das Verhalten ist vorhanden, aber seine Bedeutung muss interpretiert werden.
Engineering → Interpretation → Code → beobachtetes Verhalten
Ab L3
WhiteBox
Ein explizites, kontrolliertes Referenzmodell des Verhaltens, verbunden mit Engineering, Implementierung, Laufzeit, Verifikation und Änderung. Verhalten wird damit erklärbar, nachvollziehbar, messbar, testbar, diagnostizierbar und kontrolliert veränderbar.
Engineering → Behavior Reference (BR) → Implementierung → nachweisbares Verhalten
WhiteBox heißt nicht, dass man den Code sieht. WhiteBox heißt, dass Konformität entscheidbar ist statt beurteilbar.
05 — Die Wirkung
Der Nutzen ist eine Folge
der Engineering-Struktur.
Er entsteht nicht durch eine einzelne Softwarefunktion, sondern durch reduzierte Interpretationsarbeit. Die Kausalität ist klar; die Höhe ist es nicht — sie ist projektspezifisch.
01
Weniger Interpretation02
Weniger Unsicherheit03
Weniger Suchaufwand04
Kürzere Engineering-, Inbetriebnahme- und Diagnosezyklen−50 bis −80 %Inbetriebnahmezeit
−40 bis −70 %ungeplanter Stillstand
+3 bis +10 %OEE
−25 bis −50 %Instandhaltung
+5 bis +20 %Output
Bandbreiten aus umgesetzten Kundenprojekten. Der tatsächliche Wert ist projektspezifisch und wird im Assessment an Ihrer Anlage gemessen.
06 — Der Weg
Sieben Leistungen.
Jede mit einem Ergebnis.
Die Reihenfolge entspricht dem Weg, nicht dem Umsatz. Sie kombinieren die Stufen, die Ihr Weg zur Behavior Defined Machine (BDM) braucht.
01
02
03
04
05
06
07
Strategy Workshop
Zielbild, Anwendungsfall und Roadmap.
WhiteBox Assessment
Wo Konformität heute entscheidbar ist und wo für Verhalten eine Referenz fehlt.
PTF- & Behavior-Reference-Pilot
Eine freigegebene Behavior Reference (BR) für ein abgegrenztes Einheitsmodul.
Behavior Defined Machine (BDM) Engineering Project
Aus der Behavior Reference (BR) abgeleitete und gegen sie verifizierte Umsetzung.
Enterprise Transformation
Behavior-Centric Engineering (BCE) als Standard über mehrere Werke.
Lifecycle Services
Verhaltensintegrität über den Lebenszyklus, Änderungen als Change Verification.
Certification & Training
Befähigung des Teams, Selmo-eigene Qualifikationen.
07 — Wer das baut
Wer das baut
Warum wir über Verhalten sprechen können.
Selmo ist aus der Inbetriebnahme entstanden, nicht aus der Beratung. Die Methode wurde an realen Anlagen entwickelt und dort korrigiert, wo eine Abweichung Stillstand bedeutet. Was wir über Verhalten behaupten, haben wir vorher selbst gegen eine Referenz geprüft.
Über Selmo
Was die Methode nicht leistet
Selmo ersetzt weder Inbetriebnahme noch Erfahrung — es reduziert den Ursachenraum. Und geprüft ist immer der definierte Verhaltensraum: Was nicht modelliert ist, ist nicht abgedeckt.
Die entscheidende Frage
Wenn sich Ihre Anlage morgen anders verhält als gestern — woran würden Sie es merken?
Antwort gemeinsam prüfen15–30 Minuten Erstgespräch, konkret an Ihrer kritischsten Maschine. Kostenlos und unverbindlich.