Prozesstechnik
P&IDprozesstechnische Struktur
Das fehlende technische Objekt
Der Plan für
Verhalten.
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.
01 — Der Befund
Für alles gibt es einen Plan.
Nur nicht für Verhalten.
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.
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 drei Reduktionen
Drei Antworten.
Keine davon ist Verhalten.
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.
Reduktion 01 — Repräsentation
Sie beschreibt Verhalten
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.
Reduktion 02 — Realisierung
Sie erzeugt Verhalten
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.
Reduktion 03 — Beobachtung
Sie zeigt Verhalten
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.
Die Einordnung
„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.
03 — Das fehlende Objekt
Der Plan für Verhalten
heißt Behavior Reference (BR).
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.
01
Voraussetzung · PTF (Prozess · Technologie · Funktion)
Ist die Erwartung überhaupt entscheidbar?
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.
02
Behavior Reference (BR)
Die Sollstruktur des Verhaltens
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.
03
Behavior Gate
Die Entscheidung vor der Implementierung
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.
04
Engineering Behavior Reference
Die freigegebene Referenz
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.
Was die Behavior Reference (BR) NICHT ist
Kein Code
Code wird aus der Behavior Reference (BR) abgeleitet, nicht umgekehrt. Sie enthält keine Programmiersyntax.
Keine nachträgliche Dokumentation
Sie beschreibt kein bestehendes Programm, sondern legt das Sollverhalten fest, gegen das geprüft wird.
Keine Geräteliste
Sie beschreibt Verhalten: Zustände, Aktionen, erwartete Reaktionen, Bedingungen und Transitionen — nicht Geräte.
Kein Hersteller-Modell
Sie ist technologieunabhängig; PLCOpen XML als Austauschformat.
04 — Die Übersetzung
Vier Übersetzungen.
Vier Interpretationen.
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.
Codeaus Requirements interpretiert. Er kann kompilieren und funktional erscheinen — bewiesen ist damit nichts.
HMIeine eigenständig interpretierte Sicht auf Zustände, Bedienung und Meldungen.
Dokumentationeine dritte Lesart desselben Sollverhaltens, häufig später erstellt.
DatenstrukturBenennung und Struktur folgen der Interpretation, nicht der Definition.
Der Kern dieser Stufe
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.
05 — Die eigentliche Lücke
Selbst wenn das Soll korrekt ist:
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."
Zwei getrennte Nachweise
Nachweis
Frage
Status heute
NachweisVerifikation der Behavior Reference (BR)
FrageIst die Behavior Reference (BR) vollständig und widerspruchsfrei?
Status heutemit einer Behavior Reference (BR) lösbar
NachweisVerifikation der Übersetzung
FrageRealisieren Code, HMI, Dokumentation und Datenstruktur die Behavior Reference (BR) korrekt?
Status heuteoffen
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.
06 — Verifikation und Validierung
Zwei Fragen.
Nicht eine.
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.
01
Verifikation
Runtime Behavior gegen die Behavior Reference (BR)
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.
02
Validierung
Das verifizierte System gegen den Intent
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.
Gate heißt Entscheidung
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?
07 — Von der BlackBox zur WhiteBox
Behavior Interpreted Machine
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
Behavior Defined Machine (BDM)
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.
L0
BlackBox
Verhalten nur im Code.
L1
Beschrieben
in Prosa, nicht formal prüfbar.
L2
Explizite Zustände
strukturiert, ohne normative Autorität.
L3
Entscheidbar
Wendepunkt WhiteBox.
L4
Lebenszyklus
Entscheidbarkeit bleibt über Änderungen erhalten.
L5
Architektur
vollständig aus der Behavior Reference (BR) abgeleitet.
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.
08 — Semantik erhalten statt übersetzen
Aus einer Übersetzung
wird eine Ableitung.
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.
01
Gegen die Zustandsraum-Grenze
Konform statt aufgetreten
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.
02
Gegen die Zeitpunkt-Grenze
Der Vergleich endet nicht mit der Abnahme
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.
03
Für die Diagnose
Abweichung statt Symptom
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.
Was das über den Lebenszyklus bedeutet
Phase
Klassisch
Behavior Defined
PhaseImplementierung
KlassischVerhalten wird interpretiert
Behavior DefinedVerhalten wird abgeleitet
PhaseInbetriebnahme
KlassischUrsachenraum offen
Behavior DefinedUrsachenraum reduziert auf Hardware, Schnittstelle, Prozessannahme
PhaseVerifikation
KlassischTestlogik aus Code rekonstruiert
Behavior DefinedTestlogik aus der Behavior Reference (BR) abgeleitet
PhaseValidierung
KlassischRückverfolgung zum Intent brüchig
Behavior DefinedRückverfolgung erhalten
PhaseBetrieb
KlassischSymptomdiagnose
Behavior Definedkontinuierlicher Soll-Ist-Vergleich
PhaseÄnderung
KlassischSoftware rückwärts verstehen
Behavior DefinedBehavior Reference (BR) ändern, neu ableiten
Behavior-Centric Engineering (BCE) ist das Vorgehen. Die Behavior Reference (BR) ist das Engineering-Objekt, das dabei entsteht. Eine Behavior Defined Machine (BDM) ist die Maschine, deren Code, HMI, Dokumentation und Datenstruktur daraus abgeleitet sind.
Das Modell hat Vorrang: Änderungen werden in der Behavior Reference (BR) beschrieben und neu abgeleitet — nie direkt im Code.
Was die Methode nicht leistet
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
Wo im Projekt wird zum ersten Mal sichtbar, dass jemand Verhalten anders verstanden hat als gemeint?
Antwort gemeinsam prüfen15–30 Minuten, konkret an Ihrer kritischsten Maschine. Kostenlos und unverbindlich.