Process
P&IDprocess structure
Behavior Defined Machines
Behavior
you can prove.
01 — The finding
Everything has a plan.
Except behavior.
Process engineering has the P&ID. Electrical engineering has the wiring diagram. Mechanical engineering has the drawing. Behavior is spread across the functional description, the HMI specification, parameter tables — and completely only across the code.
Electrical
Wiring diagramelectrical target structureMechanical
Drawinggeometry and assemblyInstrumentation
Instrument listmeasurement structureBehavior
— missing —no artifact carries behavior normativelyThis is not a criticism of engineering. What is missing is an object, not a capability.
02 — The translation break
Even when the target is correct:
A verified Behavior Reference (BR) still guarantees no verified system.
Assume the best case: the intended behavior is fully described, free of contradictions, agreed and released. Everything done right. Even then, nothing is proven about the realization — because translating that target into code, HMI, documentation and data structure can today only be checked by observation.
"A passed acceptance test is a snapshot of a sample."
Limit 01 — State space
It checks a sample
What gets tested is what came up in the test: the normal sequence, the planned faults, the combinations someone thought of. The real state space — operating modes times recipes times fault conditions times restart situations — is larger by orders of magnitude.What was never observed has not been tested. It simply did not come up.
Limit 02 — Point in time
It holds for one moment
Evidence from observation describes a system state, not a system property. A code change, an adjusted parameter, a replaced sensor, a new recipe — any change voids it.And no one notices when it expired.
03 — The system
Three terms.
One consistent logic.
Not one more document, but a shift of technical authority: from the implemented code to the defined behavior reference.
01
Behavior Reference (BR)
The plan for behavior
Just as a wiring diagram defines the electrical target structure, the Behavior Reference (BR) defines the target structure of behavior: states, actions, expected reactions, conditions to be maintained, transitions, interlocks, restart and recovery. It is not after-the-fact documentation of the code — it exists before the code.
02
Behavior-Centric Engineering (BCE)
The shift of authority
The engineering logic that makes behavior the leading object. The defined behavior semantics are carried into code, HMI, data structure and documentation without loss of interpretation. This turns a translation into a derivation — the room for interpretation does not disappear through better checking; the interpretation step disappears.
03
Behavior Defined Machine (BDM)
The verifiable machine
The machine whose real behavior can be understood, checked and changed continuously against a controlled reference. Verification asks: was it built right? Validation asks: was the right thing built? The Behavior Defined Machine (BDM) answers the first question formally — and keeps the second traceable to the original goal.
04 — BlackBox → WhiteBox
Behavior Interpreted
BlackBox
Behavior has to be reconstructed from code and symptoms. The knowledge is bound to people, to one implementation and to one point in time.
Engineering→Interpretation→Code→observed behavior
Behavior Defined
WhiteBox
The Behavior Reference (BR) carries the meaning. Code, HMI, data structure and documentation are its controlled realization — continuously comparable, across the entire lifecycle.
Engineering→Behavior Reference (BR)→Implementation→provable behavior
WhiteBox does not mean visibility. WhiteBox means decidability.
L0
BlackBox
behavior only in the code.
L1
Described
in prose, not formally verifiable.
L2
Explicit states
structured, without normative authority.
L3
Decidable
turning point WhiteBox.
L4
Lifecycle
decidability survives changes.
L5
Architecture
fully derived from the Behavior Reference (BR).
Six levels describe how far behavior is defined today. From L3 the question "does the real behavior match the reference?" can be decided rather than judged. L0–L5 describes the maturity of one plant's behavior model.
05 — The effect
Less interpretation.
Less uncertainty.
The economic benefit is not an isolated product feature. It follows from a changed engineering structure — and has to be measured in each project.
01
Lessinterpretation
02
Lessuncertainty
03
Lesssearching
04
Shortercycles
−50 to −80 %commissioning of the programming
−40 to −70 %unplanned downtime from fault-finding
+3 to +10 %overall equipment effectiveness (OEE)
−25 to −50 %time spent on maintenance
+5 to +20 %output through better cycle time
Ranges from delivered customer projects. The actual value is project-specific and is measured in the assessment on your machine.
The deliberate limit
Selmo replaces neither commissioning nor experience — it reduces the space of possible causes. And what is verified is always the defined behavior space: what is not modeled is not covered.
06 — The path
Seven services.
Each with a result.
One product core — Selmo Studio, Selmo Standard, Selmo Activation Code — and services built around it. You choose where to start.
01
Strategy Workshop
Target picture, use case and roadmap for your path to the Behavior Defined Machine (BDM).
02
WhiteBox Assessment
Determine where conformity is decidable today and where behavior lacks a reference. Result: maturity L0–L5.
03
PTF & Behavior Reference Pilot
One released Behavior Reference (BR) for a defined unit module.
04
Behavior Defined Machine (BDM) Engineering Project
Implementation derived from the Behavior Reference (BR) and verified against it.
05
Enterprise Transformation
Behavior-Centric Engineering (BCE) as the standard across several plants.
06
Lifecycle Services
Behavioral integrity across the lifecycle, changes as change verification.
07
Certification & Training
Enable your team — Selmo qualifications, not an accredited certification.
07 — Proof
Patented.
In production.
The Behavior Reference (BR) is not a concept — it runs on demanding lines today.
Supported platforms and interfaces: Beckhoff · CODESYS · ctrlX · EPLAN · SAP · References and partners named on request, with consent.
The decisive question
Which document do you check against today to know whether your machine behaves correctly?
Find the answer together15–30 minutes, focused on your most critical machine. Free and without obligation.