Electrical engineering has the circuit diagram, process engineering the P&ID. For behavior there is no comparable reference artifact — in practice it only comes into being in the code. Selmo makes behavior a standalone engineering object: defined before the code, verifiable against a reference and transferable, owned by the operator.
Even when the target is correct:
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 — by test, simulation, vFAT, commissioning. And observation has two limits.
"A passed acceptance test is a snapshot of a sample. That is the gap Selmo closes."
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.
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.
Not because too little was documented — but because behavior lacks the reference artifact that every other discipline takes for granted.
Spread across the functional description, the HMI specification, parameter tables — and complete only in the code. Not one of these documents carries behavior normatively. There is no artifact against which one could show how the machine is meant to behave.
A Behavior Interpreted Machine binds operation-critical knowledge to people and to a point of inspection. A Behavior Defined Machine (BDM) binds it to an object the company can own, check and hand over.
Without a defined expectation for the current state, only the symptom is detectable — after the expectation has already been violated. Downtime, scrap, lost overall equipment effectiveness (OEE).
"Which document do you check against to decide whether the machine behaves correctly?"
Six levels describe how far behavior is defined today. The turning point is not visibility but decidability: from L3 the question "does the real behavior match the reference?" can be decided rather than judged. That is what WhiteBox means.
L0–L2 = BlackBox zone. L3 = turning point · L4–L5 = Behavior Defined Machine (BDM). L0–L5 refers solely to the maturity of the behavior model of one plant.
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.
"How many of the possible plant states were actually run through at your last acceptance test?"
The Behavior Reference (BR) is the result of engineering: the normative target reference for behavior. Method, tool and standard are the preconditions under which it comes into being — not its components.
For each requirement it clarifies which technical reaction allows a statement: directly, indirectly, conditionally or not decidable. A requirement whose fulfilment is not decidable is not a requirement — it is an intention.
Model behavior, derive code, HMI, documentation and data structure from it. The defined behavior semantics are carried over without loss of interpretation.
The open ruleset securing structure, naming and derivability — with PLCOpen XML as the exchange format.
The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code. This turns a translation into a derivation: the room for interpretation does not disappear through better checking — the interpretation step disappears. Changes are described in the Behavior Reference (BR) and derived again — never directly in the code.
The digital twin remains a virtual technical reaction environment; the Behavior Reference (BR) remains the behavior authority. If the software runs there in conformity with the Behavior Reference (BR), a verified virtual baseline is established. If the real machine later shows different behavior, the cause most likely lies in the difference between virtual and real technical reality: hardware, wiring, mechanics, process engineering, sensors, interfaces or a model assumption. That difference is exactly the diagnostic lever — it does not make commissioning superfluous, it makes it more focused.
Without a reference, "verified" is an opinion.
This is how you get there step by step: a clear, modular path as a retrofit — from orientation to safe operation. You choose the stages you need.
Clarify position and goal: where does your plant stand, where is the value and where the risk?Strategy Workshop · WhiteBox Assessment
Capture behavior and define it bindingly as the Behavior Reference (BR).PTF & Behavior Reference Pilot
Build the Behavior Reference (BR), derive code and HMI from it and check the runtime behavior against the Behavior Reference (BR) — with test and acceptance logic derived from it.Behavior Defined Machine (BDM) Engineering Project · Enterprise Transformation
Maintain behavioral integrity, enable your team, reduce the dependency on individuals.Lifecycle Services · Certification & Training
Verification asks: was it built right? Validation asks: was the right thing built? Selmo answers the first question against the Behavior Reference (BR) — and keeps the second traceable back to the original intent.
One product core and services tuned to it. You combine what your path to the Behavior Defined Machine (BDM) needs.
Target picture, use case and roadmap for your path to the Behavior Defined Machine (BDM).
Determine where conformity is decidable today and where behavior lacks a reference. Result: maturity L0–L5 of the behavior model, every rating backed by evidence and therefore repeatable. The Behavior Reference (BR) itself is built in the PTF & Behavior Reference Pilot.
One released Behavior Reference (BR) for a defined unit module — built and realized as a running prototype.
Implementation derived from the Behavior Reference (BR) and verified against it: integration and focused commissioning with a reduced cause space.
Behavior-Centric Engineering (BCE) as the standard across several plants.
Behavioral integrity across the lifecycle, changes as change verification.
Enable your team — Selmo qualifications, not an accredited certification.
The economic benefit follows from the engineering structure, not from a single software feature.
The actual effect is project-specific and is measured in the assessment on your machine.
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.
The Behavior Reference (BR) is not a concept — it runs in production today.
References and partners (with consent): on request.
The first step out of the BlackBox
15–30 minutes, focused on your most critical machine. We show you the path to the WhiteBox. Free and without obligation.