Sie nennt zwei Grenzen: den geprüften Ausschnitt und den Prüfzeitpunkt. Die erste schließt die Behavior Reference (BR), weil geprüft wird, was definiert ist, statt was zufällig auftrat. Die zweite bleibt offen, solange der Vergleich einmal stattfindet statt mitzulaufen.
Ein geänderter Parameter, ein getauschter Sensor, eine angepasste Rezeptur. Der Nachweis, der davor galt, gilt danach nicht mehr — aber er verschwindet nicht, sondern bleibt im Ordner liegen und wird weiter zitiert.
WhiteBox heißt nicht, dass man den Code sieht. WhiteBox heißt, dass Konformität entscheidbar ist statt beurteilbar.Die Behavior Reference (BR) liegt zur Laufzeit auf der Maschine vor. Im Betrieb wird jede Abweichung vom definierten Verhalten gegen sie erkannt. Ändert sich das Sollverhalten, wird die geänderte Referenz erneut übertragen — Referenz und Laufzeitreferenz bleiben dieselbe Aussage.
Die Referenz schließt die Stichprobe. Die Laufzeitreferenz schließt den Zeitpunkt.Lifecycle Services sind kein Wartungsvertrag für Software. Sie halten die Aussage aufrecht, die am Ende des Projekts galt — über Änderungen, Personalwechsel und Jahre hinweg.
Eine Änderung beginnt in der Behavior Reference (BR), nicht im Code. Aus der geänderten Referenz werden die betroffenen Ableitungen erneuert und dagegen geprüft. Der Nachweis wird damit erneuert und nicht überschrieben.
Erkannt wird die Abweichung vom definierten Verhalten. Der definierte Verhaltensraum ist der geprüfte Raum: Was nicht modelliert ist, ist nicht abgedeckt. Diese Grenze gehört zur Aussage dazu, sonst wäre sie ein Versprechen.
Neue Betriebsarten, geänderte Produkte, erweiterte Module. Was in der Anlage dazukommt, kommt in der Referenz dazu — sonst wächst der nicht abgedeckte Raum, ohne dass es auffällt.
Je Änderung ein Eintrag: was geändert wurde, in welcher Referenzversion, wer freigegeben hat, was erneut geprüft wurde, mit welchem Ergebnis und was offen blieb. Damit ist die Nachweiskette auch nach Jahren lesbar.
Das Ergebnis ist keine Verfügbarkeitszusage, sondern die Fähigkeit, zu jedem Zeitpunkt zu sagen, wogegen die Anlage gerade geprüft ist — und seit wann.
Je Änderung: geänderte Referenzversion, betroffene Ableitungen, erneut geprüfter Umfang, Ergebnis.
Die fortgeschriebene Kette aller Änderungen mit sechs Angaben je Eintrag — lesbar ohne uns und ohne den, der die Änderung gemacht hat.
Was im Betrieb gegen die Laufzeitreferenz aufgefallen ist, mit der Angabe, ob es innerhalb oder außerhalb des modellierten Raums lag.
Die aktuelle Behavior Reference (BR) im Austauschformat, mit Versionsstand und Freigabevermerk.
Alles, was aus Zeit- oder Zugriffsgründen nicht geprüft werden konnte, steht markiert im Protokoll — nicht stillschweigend darin.
Ein Gate ist eine Entscheidung, kein Termin. Im Betrieb wiederholt sich dieselbe: ob nach der Änderung wieder ein integriertes, betriebsfähiges, prüfbares System vorliegt.
Das Sollverhalten wird in der Behavior Reference (BR) geändert und freigegeben — bevor jemand den Code anfasst.
Behavior Gate
Die betroffenen Ableitungen werden erneuert, die Prüfung läuft gegen die geänderte Referenz. Wo ein digitaler Zwilling vorliegt, zuerst dort.
Verifikations-Gate
Die geänderte Referenz wird erneut übertragen. Eintrag im Nachweisheft, damit der Stand ohne Rückfrage feststellbar bleibt.
—
Ein Angebot wird nicht dadurch stärker, dass es alles umfasst. Es wird dadurch stärker, dass sein Rand bekannt ist.
Änderung in der Referenz, Erneuerung der betroffenen Ableitungen, Prüfung gegen die geänderte Referenz, Protokoll.
Fortschreibung des Modells und der Nachweiskette, damit beide zusammen den aktuellen Stand tragen.
Reaktionszeiten werden im Vertrag festgelegt. Support setzt eine laufende Zusammenarbeit voraus.
Mechanik, Elektrik und Instandhaltung bleiben eigene Gewerke und liegen bei Ihren Partnern.
Existiert für einen Anlagenteil noch keine Behavior Reference (BR), ist das der PTF- & Behavior-Reference-Pilot.
Ein neuer Anlagenteil ist ein Behavior Defined Machine (BDM) Engineering Project, keine Änderung.
Die Leistung liefert Material für die Nachweisführung. Die Konformitätsbewertung bleibt beim Maschinenhersteller.
Die Reihenfolge ist der Weg, nicht der Umsatz. Lifecycle Services sind der sechste Schritt und der einzige ohne Ende. Die Behavior Reference (BR) ist keine nachträgliche Dokumentation des Codes. Sie entsteht vor dem Code — im Betrieb heißt das: Eine Änderung beginnt in der Referenz, nicht in der Steuerung. Verifikation fragt: Wurde richtig gebaut? Validierung fragt: Wurde das Richtige gebaut? Nach jeder Änderung ist die erste Frage wieder offen — und genau deshalb heißt es Change Verification und nicht Change Management.
Zielbild, Anwendungsfall und Roadmap.
Wo Konformität heute entscheidbar ist und wo für Verhalten eine Referenz fehlt.
Eine freigegebene Behavior Reference (BR) für ein abgegrenztes Einheitsmodul.
Aus der Behavior Reference (BR) abgeleitete und gegen sie verifizierte Umsetzung.
Behavior-Centric Engineering (BCE) als Standard über mehrere Werke.
Verhaltensintegrität über den Lebenszyklus, Änderungen als Change Verification.
Befähigung des Teams, Selmo-eigene Qualifikationen.
Erkannt wird die Abweichung vom definierten Verhalten. Der definierte Verhaltensraum ist der geprüfte Raum: Was nicht modelliert ist, ist nicht abgedeckt.
Die Frage, mit der jeder Lebenszyklus beginnt
15–30 Minuten. Wir bringen die Antwort mit, nicht die Präsentation.