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. Selmo macht Verhalten zum eigenständigen Engineering-Objekt: definiert vor dem Code, prüfbar gegen eine Referenz und im Eigentum des Betreibers, als Objekt übergebbar.
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, vFAT, Inbetriebnahme. Und Beobachtung hat zwei Grenzen.
„Eine bestandene Abnahme ist eine Momentaufnahme einer Stichprobe. Genau diese Lücke schließt Selmo."
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.
Nicht, weil zu wenig dokumentiert wurde — sondern weil für Verhalten das Referenzartefakt fehlt, das jede andere Disziplin selbstverständlich hat.
Verteilt über Funktionsbeschreibung, HMI-Spezifikation, Parametertabellen — und vollständig nur im Code. Kein einziges dieser Dokumente trägt Verhalten normativ. Es gibt kein Artefakt, gegen das sich zeigen ließe, wie sich die Maschine verhalten soll.
Eine Behavior Interpreted Machine bindet betriebskritisches Wissen an Personen und an einen Prüfzeitpunkt. Eine Behavior Defined Machine (BDM) bindet es an ein Objekt, das das Unternehmen besitzen, prüfen und übergeben kann.
Ohne definierte Erwartung im aktuellen Zustand ist nur das Symptom erkennbar — nachdem die Erwartung bereits verletzt wurde. Stillstand, Ausschuss, verlorene Gesamtanlageneffektivität (OEE).
„Gegen welches Dokument prüfen Sie ab, ob die Maschine sich richtig verhält?"
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–L2 = BlackBox-Zone. L3 = Wendepunkt · L4–L5 = Behavior Defined Machine (BDM). L0–L5 bezeichnet dabei ausschließlich den Reifegrad des Verhaltensmodells einer Anlage.
WhiteBox heißt nicht, dass man den Code sieht. WhiteBox heißt, dass Konformität entscheidbar ist statt beurteilbar.
„Wie viele der möglichen Anlagenzustände wurden bei der letzten Abnahme tatsächlich durchfahren?"
Die Behavior Reference (BR) ist das Ergebnis des Engineerings: die normative Sollreferenz für Verhalten. Methode, Werkzeug und Norm sind die Voraussetzungen, unter denen sie entsteht — nicht ihre Bestandteile.
Klärt je Anforderung, welche technische Reaktion eine Aussage erlaubt: direkt, indirekt, eingeschränkt oder nicht entscheidbar. Eine Anforderung, deren Erfüllung nicht entscheidbar ist, ist keine Anforderung — sie ist eine Absicht.
Verhalten modellieren, Code, HMI, Dokumentation und Datenstruktur daraus ableiten. Die definierte Verhaltenssemantik wird ohne Interpretationsverlust überführt.
Das offene Regelwerk, das Struktur, Benennung und Ableitbarkeit sichert — mit PLCOpen XML als Austauschformat.
Die Behavior Reference (BR) ist keine nachträgliche Dokumentation des Codes. Sie entsteht vor dem Code. Damit wird aus einer Übersetzung eine Ableitung: Der Interpretationsspielraum verschwindet nicht durch bessere Prüfung, sondern durch den Wegfall des Interpretationsschritts. Änderungen werden in der Behavior Reference (BR) beschrieben und neu abgeleitet — nie direkt im Code.
Der Digital Twin bleibt eine virtuelle technische Reaktionsumgebung; die Verhaltensautorität bleibt die Behavior Reference (BR). Läuft die Software dort konform zur Behavior Reference (BR), entsteht eine verifizierte virtuelle Baseline. Zeigt die reale Maschine später ein anderes Verhalten, liegt die Ursache mit hoher Wahrscheinlichkeit in der Differenz zwischen virtueller und realer technischer Realität: Hardware, Verdrahtung, Mechanik, Prozesstechnik, Sensorik, Schnittstelle oder Modellannahme. Genau diese Differenz ist der diagnostische Hebel — sie macht die Inbetriebnahme nicht überflüssig, sondern fokussierter.
Ohne Referenz ist „verifiziert" eine Meinung.
So kommen Sie Schritt für Schritt dorthin: ein klarer, modularer Pfad als Retrofit — von der Orientierung bis zum sicheren Betrieb. Sie wählen die Stufen, die Sie brauchen.
Standort und Ziel klären: Wo steht Ihre Anlage, wo entsteht Wert und wo Risiko?Strategy Workshop · WhiteBox Assessment
Verhalten erfassen und als Behavior Reference (BR) verbindlich festlegen.PTF- & Behavior-Reference-Pilot
Behavior Reference (BR) bauen, Code und HMI daraus ableiten und das Runtime Behavior gegen die Behavior Reference (BR) prüfen — mit daraus abgeleiteter Test- und Abnahmelogik.Behavior Defined Machine (BDM) Engineering Project · Enterprise Transformation
Verhaltensintegrität halten, Team befähigen, die Abhängigkeit von Einzelpersonen reduzieren.Lifecycle Services · Certification & Training
Verifikation fragt: Wurde richtig gebaut? Validierung fragt: Wurde das Richtige gebaut? Selmo beantwortet die erste Frage gegen die Behavior Reference (BR) — und hält die zweite rückverfolgbar zum ursprünglichen Intent.
Ein Produktkern und darauf abgestimmte Leistungen. Sie kombinieren, was Ihr Weg zur Behavior Defined Machine (BDM) braucht.
Zielbild, Anwendungsfall und Roadmap für Ihren Weg zur Behavior Defined Machine (BDM).
Bestimmen, wo Konformität heute entscheidbar ist und wo für Verhalten eine Referenz fehlt. Ergebnis: Reifegrad L0–L5 des Verhaltensmodells, jede Bewertung mit Evidenz belegt und damit wiederholbar. Die Behavior Reference (BR) selbst entsteht im PTF- & Behavior-Reference-Pilot.
Eine freigegebene Behavior Reference (BR) für ein abgegrenztes Einheitsmodul — gebaut und als lauffähiger Prototyp umgesetzt.
Aus der Behavior Reference (BR) abgeleitete und gegen sie verifizierte Umsetzung: Integration und fokussierte Inbetriebnahme mit reduziertem Ursachenraum.
Behavior-Centric Engineering (BCE) als Standard über mehrere Werke.
Verhaltensintegrität über den Lebenszyklus, Änderungen als Change Verification.
Ihr Team befähigen — Selmo-eigene Qualifikationen, keine akkreditierte Zertifizierung.
Der wirtschaftliche Nutzen ist eine Folge der Engineering-Struktur, nicht einer einzelnen Softwarefunktion.
Der tatsächliche Effekt ist projektspezifisch und wird im Assessment an Ihrer Anlage gemessen.
Selmo ersetzt weder Inbetriebnahme noch Erfahrung — es reduziert den Ursachenraum. Und geprüft ist immer der definierte Verhaltensraum: Was nicht modelliert ist, ist nicht abgedeckt.
Die Behavior Reference (BR) ist kein Konzept — sie läuft heute in der Produktion.
Referenzen und Partner (mit Freigabe): auf Anfrage.
Der erste Schritt aus der BlackBox
15–30 Minuten, konkret an Ihrer kritischsten Maschine. Wir zeigen Ihnen den Weg zur WhiteBox. Kostenlos und unverbindlich.