Jeder Kanal hat eine Störgröße: Mehrdeutigkeit, zusätzliches Verhalten, Bedeutungsverlust. Ein Kanal ohne Prüfung ist eine Wette. Ein Kanal ist nicht schuldig, er rauscht — die Störgröße ist keine Eigenschaft der Menschen, die ihn bedienen, sondern eine Eigenschaft von Übertragung. Deshalb ist die Frage nicht, wer sorgfältig arbeitet, sondern wogegen das Ergebnis geprüft wird.
Sie gilt für den geprüften Ausschnitt und für den Prüfzeitpunkt. Wo keine Referenz existiert, prüft die Inbetriebnahme gegen Erfahrung — und Erfahrung sagt nichts über das, was nie aufgetreten ist.
Die Störgröße bleibt — die Übertragung lässt sich prüfen.Werden Code, HMI, Dokumentation und Datenstruktur aus derselben freigegebenen Quelle abgeleitet, tritt an die Stelle vieler handgeführter Übertragungen eine einzige — und diese eine ist selbst prüfbar.
WhiteBox heißt nicht, dass man den Code sieht. WhiteBox heißt, dass Konformität entscheidbar ist statt beurteilbar.Das Projekt setzt eine freigegebene Behavior Reference (BR) voraus. Ohne sie gäbe es nichts, wogegen sich das Ergebnis entscheiden ließe — dann wäre es ein Umsetzungsprojekt wie jedes andere.
Aus der freigegebenen Referenz werden Steuerungscode, HMI, Dokumentation und Datenstruktur abgeleitet. Nicht parallel gepflegt, sondern aus derselben Quelle — deshalb können sie nicht auseinanderlaufen, ohne dass es auffällt.
Antriebe, Schnittstellen, Feldebene, Anbindung an übergeordnete Systeme. Das ist Handwerk und bleibt es. Was sich ändert, ist nur, wogegen am Ende geprüft wird.
Das laufende Verhalten wird gegen die Behavior Reference (BR) geprüft — mit daraus abgeleiteter Test- und Abnahmelogik. Jede Abweichung ist eine benannte Abweichung, keine Beobachtung, die jemand einordnen muss.
Am Ende steht die zweite Frage, und sie ist eine andere: ob das, was verifiziert wurde, auch das ist, was das Haus wollte. Diese Frage beantwortet niemand außer Ihnen.
Übergeben wird nicht nur eine laufende Anlage, sondern das, womit sich später nachvollziehen lässt, warum sie sich so verhält.
Aus der Referenz abgeleitet, in Ihrer Zielumgebung lauffähig, im Austauschformat PLCOpen XML lesbar.
Aus derselben Quelle abgeleitet. Was auf dem Bildschirm steht, steht auch in der Referenz — und umgekehrt.
Aus der Referenz abgeleitet, nicht separat geschrieben. Deshalb prüft sie gegen die Festlegung und nicht gegen eine zweite Meinung.
Was geprüft wurde, mit welchem Ergebnis, und welche Abweichungen offen geblieben sind.
Referenz, Ableitungen und Protokolle liegen im Eigentum des Betreibers und sind übergebbar.
Ein Gate ist eine Entscheidung, kein Termin. Dieses Projekt führt auf zwei zu — eine über den Zustand des Systems, eine über den Zweck.
Code, HMI, Dokumentation und Datenstruktur aus der freigegebenen Referenz. Abgleich mit Ihrer Zielumgebung.
—
Hardware, Schnittstellen, Anbindung. Virtuelle Inbetriebnahme, wo ein Modell der Anlage vorliegt.
—
Prüfung des Runtime Behavior gegen die Behavior Reference (BR) mit abgeleiteter Test- und Abnahmelogik.
Verifikations-Gate
Erfüllt das verifizierte System den Intent aus Gate 0. Übergabe im Gespräch, nicht per Datei.
Validierungs-Gate
Ein Angebot wird nicht dadurch stärker, dass es alles umfasst. Es wird dadurch stärker, dass sein Rand bekannt ist.
Code, HMI, Dokumentation, Datenstruktur, Test- und Abnahmelogik, Prüfung des Runtime Behavior gegen die Referenz.
Mit reduziertem Ursachenraum: Wo eine Referenz vorliegt, ist bei einer Abweichung bekannt, wogegen sie abweicht.
Ihre Fachleute arbeiten mit. Wer die Anlage später ändern soll, muss die Referenz lesen können — nicht uns anrufen.
Das Erstellen und Freigeben der Behavior Reference (BR) ist der PTF- & Behavior-Reference-Pilot und muss vorher abgeschlossen sein.
Elektroplanung, Schaltschrankbau und mechanische Konstruktion bleiben eigene Gewerke.
Änderungen nach der Übergabe und deren Change Verification liegen bei Lifecycle Services.
Das Projekt liefert Material für die Nachweisführung. Die Konformitätsbewertung bleibt beim Maschinenhersteller.
Die Reihenfolge ist der Weg, nicht der Umsatz. Das Projekt ist der vierte Schritt: Es setzt um. Die Behavior Reference (BR) ist keine nachträgliche Dokumentation des Codes. Sie entsteht vor dem Code — deshalb kann dieses Projekt nicht beginnen, bevor der Pilot abgeschlossen ist. Verifikation fragt: Wurde richtig gebaut? Validierung fragt: Wurde das Richtige gebaut? Dieses Projekt beantwortet beide, und zwar in dieser Reihenfolge. Zur Rolle von künstlicher Intelligenz: Sie beschleunigt das Übersetzen — nicht das Prüfen. Der Nachweis, dass Software das definierte Verhalten realisiert, hängt weiterhin an Beobachtung, und Beobachtung skaliert mit realer Zeit an realer Anlage.
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.
Geprüft wird gegen die freigegebene Referenz. Was nicht modelliert ist, ist nicht abgedeckt — die Verifikation macht diese Grenze sichtbar, sie hebt sie nicht auf.
Die Frage, mit der jedes Umsetzungsprojekt beginnt
15–30 Minuten. Wir bringen die Antwort mit, nicht die Präsentation.