DAS FEHLENDE TECHNISCHE OBJEKT

BDM, BCE und die Behavior Reference — klar erklärt.

Drei Begriffe, ein Prinzip: Verhalten explizit machen, bevor es im Code verschwindet. Diese Seite macht sie in wenigen Minuten verständlich.

Erstgespräch anfragenZum SystemStartseite
In einem Satz

BCE (das Vorgehen) erzeugt eine Behavior Reference (das Artefakt), damit die Maschine zur Behavior-Defined Machine (dem Ergebnis) wird.

DIE DREI BEGRIFFE

Definitionen

Konzeptbegriffe bleiben englisch, auch im Deutschen — Kürzel nach erstmaliger Ausschreibung.

BDM

Behavior-Defined Machine

Verhaltensdefinierte Maschine

Eine Maschine, deren beabsichtigtes Verhalten formal definiert, geprüft und kontrolliert ist — bevor Code entsteht, unabhängig von Hersteller und Personal.

Das Ergebnis · WhiteBox statt BlackBox.
BCE

Behavior-Centric Engineering

Verhaltenszentriertes Engineering

Das Vorgehen, das Verhalten vor der Implementierung explizit definiert: Absicht → Verhalten → Code → Realität. Der Programmierer erfindet kein Verhalten mehr, er realisiert eine geprüfte Definition.

Der Weg dorthin.
BR

Behavior Reference

Verhaltensreferenz

Die autoritative, technologieunabhängige Repräsentation des beabsichtigten Verhaltens — die gemeinsame Sprache aller Disziplinen. Keine Syntax, kein Compiler. In der Selmo-Methode ist das Prozessmodell die BR.

Das Artefakt · zwischen Absicht und Code.
DIE KETTE

Von der Absicht zum Betrieb

Die Behavior Reference ist das führende Objekt — alles verweist auf sie oder leitet sich aus ihr ab.

Intent
die Absicht
→
Behavior Reference
das führende Objekt
→
Code
daraus generiert
→
Betrieb
beweisbar & überwacht

Kein Schritt wird übersprungen. Code, HMI, Dokumentation und Datenstruktur entstehen 1:1 aus derselben BR.

DER UNTERSCHIED

WhiteBox statt BlackBox

BlackBox

  • Verhalten steckt undokumentiert im Code
  • personen- und herstellerabhängig
  • nicht prüfbar, nicht übergebbar
  • Abweichung erst beim Ausfall sichtbar

WhiteBox

  • Verhalten explizit definiert
  • technologie- & herstellerunabhängig
  • prüfbar und beweisbar
  • im Eigentum des Betreibers
BR IN DER PRAXIS

Eine Behavior Reference — vier Ergebnisse

PTF klärt, das Prozessmodell wird zur Behavior Reference — Selmo Studio & Standard erzeugen daraus vier Ergebnisse.

PTF
Prozess · Technologie · Funktion
→
Prozessmodell = BR
Logic + System Layer
→
Selmo Studio + Standard
verifiziert & generiert

Code

SPS-Logik via PLCOpen XML, herstellerunabhängig, gegen die BR verifiziert.

HMI

Bedienung & Visualisierung: Zustände und Abweichungen sichtbar.

Dokumentation

Bedien-, Diagnose- & Verhaltensdoku, aus dem Modell abgeleitet.

Datenstruktur

Objektzentriertes Datenmodell, klar benannt, vier Datensichten.

Eine Quelle, vier Ergebnisse — widerspruchsfrei, ableitbar und beweisbar.

REIFEGRADE

Der Weg: L0 bis L5

Ab L3 wird das Verhaltensmodell zur WhiteBox — L4–L5 ist die Behavior-Defined Machine.

L0
BlackBox
Verhalten im Code.
L1
Dokumentiert
nicht formal.
L2
Explizite Zustände
sichtbar gemacht.
L3
Beherrschbar
Wendepunkt WhiteBox.
L4
Lebenszyklus
Integrität über Zeit.
L5
Architektur
voll modellgesteuert.
KLARSTELLUNG

Was die Behavior Reference NICHT ist

Damit keine Missverständnisse entstehen.

Kein Code — Code entsteht aus der BR, nicht umgekehrt; keine Programmiersyntax.
Keine nachträgliche Doku — die BR ist zugleich ausführbare Spezifikation.
Keine Geräteliste — sie beschreibt Verhalten (Veränderung), nicht Geräte.
Kein Hersteller-Modell — sie ist technologieunabhängig.

Verhalten verstehen — und beweisbar machen.

15–30 Minuten, konkret an einer Ihrer Maschinen. Kostenlos und unverbindlich.

Erstgespräch anfragen