Für Elektrik gibt es den Stromlaufplan, für Prozesstechnik das P&ID. Für Verhalten gibt es kein vergleichbares Referenzartefakt — es entsteht faktisch erst im Code. Diese Seite erklärt die drei Begriffe, mit denen sich das ändert: präzise, in der Reihenfolge der Argumentation.
Die Referenzartefakte der Disziplinen sind nicht bloß Dokumentation — sie definieren normativ. Verhalten verteilt sich dagegen über Funktionsbeschreibung, HMI-Spezifikation, Parametertabellen — und vollständig nur über den Code. Kein einziges dieser Dokumente trägt Verhalten normativ.
Das ist kein Vorwurf an das Engineering. Es fehlt ein Objekt, nicht eine Fähigkeit.
Auf die Frage, wo Verhalten definiert ist, fällt jede Antwort in genau eine von drei Klassen. Jede leistet etwas — und keine schließt die Lücke.
Funktionsbeschreibung, Functional Design Specification, Lastenheft, Spezifikation. Sie beschreibt Verhalten in natürlicher Sprache. Sie ist nicht formal prüfbar, hat keine Autorität über die Laufzeit und geht bei jeder Änderung als Erste verloren.Beschreibung ist nicht Definition.
SPS-Code, Konfiguration, Parametrierung. Sie erzeugt Verhalten. Aber sie kann nicht gleichzeitig das Soll und das Ist sein.Code gegen Code zu prüfen ist keine Verifikation.
Test, Simulation, virtuelle Abnahme, Inbetriebnahme, Diagnose, Digital Twin. Sie zeigt Verhalten. Aber immer nur das eingetretene, immer nur zum Prüfzeitpunkt.Beobachtung zeigt, sie beweist nicht.
„Wo ist bei Ihnen das Verhalten definiert?"
Jeder Einwand lässt sich zuordnen: „Das steht in unserer Funktionsbeschreibung" ist Repräsentation. „Das ist im Code sauber gelöst" ist Realisierung. „Unsere virtuelle Abnahme und die Inbetriebnahme decken das ab" ist Beobachtung. Die Aufgabe ist nicht, den Einwand zu entkräften, sondern ihn einzuordnen.
Behavior-Centric Engineering (BCE) setzt genau hier an. Sein Ergebnis ist ein Engineering-Objekt, das Verhalten normativ trägt: technologieunabhängig, mit Autorität über Implementierung und Laufzeit.
Vor dem Verhalten steht die Frage, ob eine Anforderung gegen eine technische Reaktion geprüft werden kann. Der Ausgang ist keine Note und keine Ampel, sondern eine Einstufung der Entscheidbarkeit in vier Klassen: direkt, indirekt, eingeschränkt oder nicht entscheidbar. Eine Anforderung, deren Erfüllung nicht entscheidbar ist, ist keine Anforderung — sie ist eine Absicht.
So wie ein Stromlaufplan die elektrische Sollstruktur definiert, definiert die Behavior Reference (BR) die Sollstruktur des Verhaltens: relevante Zustände und Situationen, Aktionen, erwartete Reaktionen, aufrechtzuerhaltende Bedingungen, Transitionen, Verriegelungen, Berechtigungen, Parameter, Zeiten, Schnittstellen, Abweichungen sowie Restart- und Recovery-Verhalten. Sie beschreibt nicht, wie ein Programmierer Code schreiben soll. Die Behavior Reference (BR) ist keine nachträgliche Dokumentation des Codes. Sie entsteht vor dem Code.
Die Frage am Behavior Gate lautet nicht „Kann ein Programmierer damit beginnen?", sondern: Ist das erwartete Verhalten so vollständig definiert, dass die Implementierung kein eigenes Verhalten erfinden muss? Ein Gate ist eine Entscheidung — kein Termin und kein Review.
Mit der Freigabe entsteht die führende Referenz für alle nachfolgenden Phasen. Verifikation setzt eine Referenz voraus. Fehlt sie, bleibt nur ein Ist-Stand, über den Konsens herrscht: Ohne Referenz ist „verifiziert" eine Meinung.
Code wird aus der Behavior Reference (BR) abgeleitet, nicht umgekehrt. Sie enthält keine Programmiersyntax.
Sie beschreibt kein bestehendes Programm, sondern legt das Sollverhalten fest, gegen das geprüft wird.
Sie beschreibt Verhalten: Zustände, Aktionen, erwartete Reaktionen, Bedingungen und Transitionen — nicht Geräte.
Sie ist technologieunabhängig; PLCOpen XML als Austauschformat.
Im klassischen Vorgehen liest die Implementierung Requirements, Funktionsbeschreibungen und Pläne — und interpretiert daraus die Software. Dieselbe Übersetzung findet parallel viermal statt, durch verschiedene Personen zu verschiedenen Zeitpunkten.
Zwischen Engineering und Code liegt eine Übersetzung. Jede Übersetzung besitzt Interpretationsspielraum — das gilt für den Menschen wie für die KI. Das ist kein Versäumnis der Beteiligten, sondern eine Eigenschaft dieses Schritts.
Selbst wenn das Soll korrekt ist:
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."
FrageIst die Behavior Reference (BR) vollständig und widerspruchsfrei?
FrageRealisieren Code, HMI, Dokumentation und Datenstruktur die Behavior Reference (BR) korrekt?
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.
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.
Verifikation entwickelt nichts mehr. Sie vergleicht: die reale Implementierung gegen die freigegebenen Engineering-Ergebnisse. Für Verhalten ist die Behavior Reference (BR) die maßgebliche Referenz.
Wurde eine Aktion ausgelöst? Ist die erwartete Reaktion eingetreten? Blieben die geforderten Bedingungen erhalten? Wurde nur die zulässige Transition ausgeführt? Wurde eine Abweichung korrekt erkannt? Funktionieren Restart und Recovery wie definiert? Entscheidend ist das Verhalten des integrierten Systems: Ein bestandener SPS-Test allein genügt dafür nicht, eine erfolgreiche Simulation ist kein vollständiger Nachweis. Das Ergebnis lautet dann nicht „die Maschine läuft", sondern: Die gebaute technische Realität entspricht dem freigegebenen Engineering.
Validierung prüft nicht gegen das Engineering, sondern gegen den Intent: Erfüllt das reale, verifizierte System die ursprüngliche Erwartung? Eine Anlage kann exakt entsprechend dem Engineering arbeiten und trotzdem die gewünschte Produktqualität nicht erreichen. Dann liegt kein Implementierungsfehler vor, sondern ein Engineering- oder Intent-Gap. Genau darin liegt der Wert der Trennung.
Das Verifikations-Gate fragt: Liegt ein integriertes, betriebsfähiges, prüfbares System vor? Das Validierungs-Gate fragt: Erfüllt das verifizierte System den Intent? Beide sind Entscheidungen — kein Termin und kein Review.
Verifikation fragt: Wurde richtig gebaut? Validierung fragt: Wurde das Richtige gebaut?
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.
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.
WhiteBox heißt nicht, dass man den Code sieht. WhiteBox heißt, dass Konformität entscheidbar ist statt beurteilbar.
Sechs Stufen beschreiben, wie weit Verhalten heute definiert ist. Der Wendepunkt ist nicht Sichtbarkeit, sondern Entscheidbarkeit: Ab L3 lässt sich die Frage „entspricht das reale Verhalten der Referenz?" entscheiden statt beurteilen. Genau das heißt WhiteBox. L0–L5 bezeichnet dabei ausschließlich den Reifegrad des Verhaltensmodells einer Anlage — die Entscheidbarkeit einzelner Anforderungen wird über PTF (Prozess · Technologie · Funktion) eingestuft.
Die Behavior Reference (BR) wird nicht als Dokument erstellt und anschließend interpretiert. Die definierte Verhaltenssemantik wird ohne Interpretationsverlust in Code, HMI, Datenstruktur und Dokumentation überführt. Der Interpretationsspielraum verschwindet nicht durch bessere Prüfung, sondern durch den Wegfall des Interpretationsschritts.
Weil zwischen Behavior Reference (BR) und Laufzeit eine direkte semantische Beziehung besteht, ist im aktiven Zustand jederzeit bekannt, welche Aktionen, Reaktionen, Bedingungen und Transitionen erwartet werden. Geprüft wird deshalb nicht, ob ein Zustand aufgetreten ist, sondern ob jeder aufgetretene Zustand konform war — im gesamten definierten Verhaltensraum, nicht in einer Teststichprobe.
Er läuft im Betrieb weiter. Und bei einer Änderung wird nicht bestehende Software rückwärts verstanden — die Behavior Reference (BR) wird kontrolliert geändert und die Implementierung daraus erneut abgeleitet.
In klassischen Systemen wird ein Fehler erkannt, nachdem eine Erwartung bereits verletzt wurde — danach beginnt die Interpretation. Ist die Erwartung im aktuellen Zustand bekannt, ist unmittelbar bestimmbar: Was soll passieren? Was passiert tatsächlich? Was fehlt? Welche Bedingung ist verletzt? Welche Transition ist blockiert? Ein Fehler ist ein Symptom. Eine Behavior Deviation ist eine Differenz.
KlassischVerhalten wird interpretiert
KlassischUrsachenraum offen
KlassischTestlogik aus Code rekonstruiert
KlassischRückverfolgung zum Intent brüchig
KlassischSymptomdiagnose
KlassischSoftware rückwärts verstehen
Die Methode prüft Konformität gegen die Referenz. Ist die Referenz sachlich falsch, wird sie korrekt falsch realisiert. Dagegen hilft nur Validierung gegen den Intent.
Die Frage, an der sich alles entscheidet
15–30 Minuten, konkret an Ihrer kritischsten Maschine. Kostenlos und unverbindlich.