Process engineering
P&IDprocess structure
Behavior Defined Machines
Everything has a plan.
Except behavior.
01 — The finding
Four disciplines have their target structure.
The fifth has only the code.
P&ID, circuit diagram, drawing and instrument list are not merely documentation. They define normatively. Behavior, by contrast, lies scattered across functional descriptions, HMI specifications and parameter tables — and completely only in the code.
Electrical engineering
Circuit diagramelectrical target structureMechanics
Drawinggeometry and assemblyInstrumentation
Instrument listmeasurement structureBehavior
— missing —no artifact carries behavior normativelyThis is not a reproach to engineering. What is missing is an object, not a capability.
02 — The actual gap
The actual gap
Even a passed acceptance test proves less than it promises.
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.
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 missing object
An object closes the gap.
Not more observation.
Observation can be refined, but its two limits remain. What is missing is not a better checking procedure but an artifact to check against.
01
The object
Behavior Reference (BR)
Just as a circuit diagram defines the electrical target structure, the Behavior Reference (BR) defines the target structure of behavior: states and situations, actions, expected reactions, conditions to be maintained, transitions, interlocks, permissions, parameters, times, interfaces as well as restart and recovery behavior. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code.
02
The approach
Behavior-Centric Engineering (BCE)
Behavior is defined and released before implementation. At the Behavior Gate the question is not whether a programmer can start, but whether the expected behavior is defined completely enough that the implementation does not have to invent behavior of its own. A gate is a decision — not a date and not a review.
03
The machine
Behavior Defined Machine (BDM)
Code, HMI, documentation and data structure are derived from the same released reference, without loss of interpretation. A translation becomes a derivation: the room for interpretation does not disappear through better checking but through the removal of the interpretation step.
Verification asks: was it built right? Validation asks: was the right thing built?
Selmo answers the first question — against the released Behavior Reference (BR), with test and acceptance logic derived from it. The second remains the check against your intent, and it remains necessary.
04 — BlackBox → WhiteBox
Today
BlackBox
Behavior becomes fully visible only through the implementation — which effectively makes the code the leading artifact. In operation, behavior is reconstructed from symptoms: examine signals, read code, infer assumptions. The behavior is present, but its meaning has to be interpreted.
Engineering → Interpretation → Code → observed behavior
From L3
WhiteBox
An explicit, controlled reference model of behavior, connected to engineering, implementation, runtime, verification and change. Behavior becomes explainable, traceable, measurable, testable, diagnosable and controllably changeable.
Engineering → Behavior Reference (BR) → Implementation → evidenced behavior
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.
05 — The effect
The benefit is a consequence
of the engineering structure.
It does not come from a single software function but from reduced interpretation work. The causality is clear; the magnitude is not — it is project-specific.
01
Less interpretation02
Less uncertainty03
Less searching04
Shorter engineering, commissioning and diagnosis cycles−50 to −80 %commissioning time
−40 to −70 %unplanned downtime
+3 to +10 %OEE
−25 to −50 %maintenance
+5 to +20 %output
Ranges from delivered customer projects. The actual value is project-specific and is measured in the assessment on your machine.
06 — The path
Seven services.
Each with a result.
The order follows the path, not the revenue. You combine the steps your path to the Behavior Defined Machine (BDM) needs.
01
02
03
04
05
06
07
Strategy Workshop
Target picture, use case and roadmap.
WhiteBox Assessment
Where conformity is decidable today and where behavior lacks a reference.
PTF & Behavior Reference Pilot
A released Behavior Reference (BR) for one delimited unit module.
Behavior Defined Machine (BDM) Engineering Project
Implementation derived from the Behavior Reference (BR) and verified against it.
Enterprise Transformation
Behavior-Centric Engineering (BCE) as the standard across several plants.
Lifecycle Services
Behavioral integrity across the lifecycle, changes as Change Verification.
Certification & Training
Enabling the team, Selmo-issued qualifications.
07 — Who builds this
Who builds this
Why we can speak about behavior.
Selmo grew out of commissioning, not out of consulting. The method was developed on real lines and corrected where a deviation means downtime. What we claim about behavior, we checked against a reference ourselves first.
About Selmo
What the method does not do
Selmo replaces neither commissioning nor experience — it reduces the space of possible causes. And what is checked is always the defined behavioral space: what is not modeled is not covered.
The decisive question
If your line behaves differently tomorrow than it did yesterday — how would you notice?
Check the answer together15–30 minutes, concretely on your most critical machine. Free and without obligation.