Sie gilt für den geprüften Ausschnitt und für den Prüfzeitpunkt — weil es kein Dokument gibt, gegen das man prüfen könnte. Der Code ist heute Plan und Ausführung zugleich. Solange das so ist, ist jede Abnahme ein Vergleich mit Erfahrung, nicht mit einer Festlegung.
Die BlackBox entsteht nicht durch schlechte Arbeit. Sie entsteht, weil Verhalten nirgends als eigenes Objekt existiert — es liegt verteilt in Code, HMI, Köpfen und Gewohnheiten. Der Pilot stellt dieses Objekt her.
Heute macht eine Person beides gleichzeitig — planen und ausführen — und trägt beides allein. Das ist keine Frage mangelnder Qualifikation, sondern fehlender Arbeitsteilung.PTF (Prozess · Technologie · Funktion) trennt, was in einer Funktionsbeschreibung üblicherweise vermischt ist: was ablaufen soll, womit es umgesetzt wird und was ein Baustein können muss. Erst getrennt wird jede der drei Fragen entscheidbar.
WhiteBox heißt nicht, dass man den Code sieht. WhiteBox heißt, dass Konformität entscheidbar ist statt beurteilbar.Der Pilot arbeitet an einem Modul, nicht an einer Linie. Das ist keine Sparmaßnahme, sondern die Bedingung dafür, dass am Ende eine Aussage steht und nicht ein Zwischenstand.
Vor der ersten Zeile Modell steht die Grenze: welche Aktoren, welche Sensoren, welche Schnittstellen zum Rest der Linie. Eine unscharfe Grenze erzeugt später genau die Annahmen, die der Pilot beseitigen soll.
Prozess: was in welcher Reihenfolge geschehen soll. Technologie: womit, mit welchen Grenzen und welcher erkennbaren Reaktion. Funktion: was ein Baustein können muss, damit der Prozess auf dieser Technologie läuft.
Das Verhalten wird als Modell festgelegt: welche Zustände es gibt, welche Übergänge zulässig sind und was sie sperrt. Was hier nicht steht, gilt später nicht — deshalb ist die Vollständigkeitsprüfung Teil der Arbeit, nicht ein Anhang.
Die Referenz wird von Ihnen freigegeben. Damit wird sie zur Grundlage, gegen die später geprüft wird — und zu einem Objekt, das dem Betreiber gehört und übergebbar ist.
Am Ende steht keine Präsentation, sondern eine Referenz im Austauschformat, eine Nachweisliste und die Aussage, was das Modell abdeckt und was nicht.
Das freigegebene Verhaltensmodell für das Einheitsmodul — Zustände, Übergänge, Verriegelungen, Betriebsarten.
Prozess, Technologie und Funktion getrennt dokumentiert, mit den Stellen, an denen die Trennung eine Annahme sichtbar gemacht hat.
Welcher Anteil des Modulverhaltens modelliert ist und welche Betriebsarten bewusst außerhalb liegen.
Die Referenz liegt als PLCOpen XML vor. Damit ist sie lesbar, ohne dass wir daneben stehen.
Alles, was im Pilotzeitraum nicht geklärt werden konnte, steht markiert in der Referenz — nicht stillschweigend darin.
Ein Gate ist eine Entscheidung, kein Termin. Der Pilot führt auf das Behavior Gate zu: ob das erwartete Verhalten so vollständig definiert ist, dass die Implementierung kein eigenes Verhalten erfinden muss.
Modulgrenze, Schnittstellen, vorhandene Unterlagen, Gespräche mit den Menschen, die das Modul kennen.
—
Trennung der drei Fragen und Aufbau der Behavior Reference (BR), im Wechsel mit Ihren Fachleuten — nicht im stillen Kämmerlein.
—
Vollständigkeit und Widerspruchsfreiheit der Referenz, Durchsprache, Freigabe durch Sie.
Behavior Gate
Ein Angebot wird nicht dadurch stärker, dass es alles umfasst. Es wird dadurch stärker, dass sein Rand bekannt ist.
Abgrenzung, Trennung der drei Fragen, Aufbau der Behavior Reference (BR), Vollständigkeits- und Widerspruchsprüfung.
Ihre Leute arbeiten mit, nicht zu. Wer die Referenz später ändern soll, muss beim Entstehen dabei gewesen sein.
Die Referenz liegt im Eigentum des Betreibers und ist als Objekt übergebbar — im Austauschformat, nicht als Bildschirmfoto.
Ableitung von Code, HMI und Dokumentation sowie die Verifikation gegen die Referenz sind das Behavior Defined Machine (BDM) Engineering Project.
Der Befund über mehrere Anlagen ist das WhiteBox Assessment.
Der Pilot bleibt beim Modul. Die Übertragung auf weitere Module ist eine eigene Entscheidung nach dem Gate.
Qualifikationen für Ihr Team liegen bei Certification & Training.
Die Reihenfolge ist der Weg, nicht der Umsatz. Der Pilot ist der dritte Schritt: Er stellt die Referenz her. Die Behavior Reference (BR) ist keine nachträgliche Dokumentation des Codes. Sie entsteht vor dem Code — das ist im Piloten keine Haltung, sondern die Arbeitsreihenfolge. Verifikation fragt: Wurde richtig gebaut? Validierung fragt: Wurde das Richtige gebaut? Der Pilot beantwortet die zweite Frage vorab, indem er festlegt, was das Richtige ist. Die erste wird erst danach beantwortbar.
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.
Modelliert wird der definierte Verhaltensraum. Was nicht modelliert ist, ist nicht abgedeckt — die Referenz macht die Grenze sichtbar, sie verschiebt sie nicht.
Die Frage, mit der jeder Pilot beginnt
15–30 Minuten. Wir bringen die Antwort mit, nicht die Präsentation.