Electrical engineering has the wiring diagram, process engineering has the P&ID. For behavior there is no comparable reference artifact — it effectively comes into existence in the code. This page explains the three terms that change this: precisely, in the order of the argument.
The reference artifacts of the disciplines are not merely documentation — they define normatively. Behavior, by contrast, is spread across functional description, HMI specification, parameter tables — and complete only in the code. Not one of these documents carries behavior normatively.
This is not a criticism of engineering. What is missing is an object, not a capability.
Asked where behavior is defined, every answer falls into exactly one of three classes. Each one does something — and none of them closes the gap.
Functional description, functional design specification, requirements document, specification. It describes behavior in natural language. It is not formally checkable, has no authority over runtime and is the first thing lost with every change.Description is not definition.
PLC code, configuration, parameter settings. It produces behavior. But it cannot be the target and the actual state at the same time.Checking code against code is not verification.
Test, simulation, virtual acceptance, commissioning, diagnostics, digital twin. It shows behavior. But always only what occurred, and always only at the moment of checking.Observation shows; it does not prove.
"Where is behavior defined in your organization?"
Every objection can be classified: "It is all in our functional description" is representation. "It is solved cleanly in the code" is realization. "Our virtual acceptance test and commissioning cover that" is observation. The task is not to refute the objection, but to classify it.
This is exactly where Behavior-Centric Engineering (BCE) starts. Its result is an engineering object that carries behavior normatively: technology-independent, with authority over implementation and runtime.
Before behavior comes the question of whether a requirement can be checked against a technical reaction. The outcome is not a grade and not a traffic light, but a rating of decidability in four classes: directly, indirectly, conditionally or not decidable. A requirement whose fulfilment cannot be decided is not a requirement — it is an intention.
Just as a wiring diagram defines the intended electrical structure, the Behavior Reference (BR) defines the intended structure of behavior: relevant states and situations, actions, expected reactions, conditions to be maintained, transitions, interlocks, permissions, parameters, times, interfaces, deviations as well as restart and recovery behavior. It does not describe how a programmer should write code. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code.
At the Behavior Gate the question is not "can a programmer start with this?" but: is the expected behavior 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.
With the release, the leading reference for all subsequent phases comes into existence. Verification presupposes a reference. Without one, all that remains is an actual state that everyone agrees on: without a reference, "verified" is an opinion.
Code is derived from the Behavior Reference (BR), not the other way round. It contains no programming syntax.
It does not describe an existing program; it defines the intended behavior that is checked against.
It describes behavior: states, actions, expected reactions, conditions and transitions — not devices.
It is technology-independent; PLCOpen XML as the exchange format.
In the classical approach, implementation reads requirements, functional descriptions and plans — and interprets the software from them. The same translation happens four times in parallel, by different people at different points in time.
Between engineering and code lies a translation. Every translation carries room for interpretation — that applies to humans as much as to AI. This is not a failing of the people involved; it is a property of this step.
Even if 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, virtual acceptance, commissioning. And observation has two limits.
"A passed acceptance test is a snapshot of a sample. That is the gap Selmo closes."
QuestionIs the Behavior Reference (BR) complete and free of contradictions?
QuestionDo code, HMI, documentation and data structure realize the Behavior Reference (BR) correctly?
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.
Verification develops nothing any more. It compares: the real implementation against the released engineering results. For behavior, the Behavior Reference (BR) is the authoritative reference.
Was an action triggered? Did the expected reaction occur? Were the required conditions maintained? Was only the permitted transition executed? Was a deviation detected correctly? Do restart and recovery work as defined? What matters is the behavior of the integrated system: a passed PLC test alone is not enough, and a successful simulation is not complete evidence. The result is then not "the machine runs", but: the technical reality that was built matches the released engineering.
Validation does not check against the engineering but against the intent: does the real, verified system meet the original expectation? A plant can work exactly according to the engineering and still fail to reach the desired product quality. In that case there is no implementation error but an engineering or intent gap. That is precisely the value of keeping the two apart.
The Verification Gate asks: is there an integrated, operational, verifiable system? The Validation Gate asks: does the verified system fulfil the intent? Both are decisions — not a date and not a review.
Verification asks: was it built right? Validation asks: was the right thing built?
Behavior only becomes fully visible 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 there, but its meaning has to be interpreted.
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.
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.
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–L5 refers exclusively to the maturity of a machine's behavior model — the decidability of individual requirements is rated via PTF (Process · Technology · Function).
The Behavior Reference (BR) is not written as a document and then interpreted. The defined behavior semantics are carried into code, HMI, data structure and documentation without loss of interpretation. The room for interpretation does not disappear through better checking — the interpretation step disappears.
Because there is a direct semantic relationship between the Behavior Reference (BR) and runtime, it is known at any moment in the active state which actions, reactions, conditions and transitions are expected. What is checked is therefore not whether a state occurred, but whether every state that occurred was conformant — across the entire defined behavior space, not in a test sample.
It continues in operation. And with a change, existing software is not understood backwards — the Behavior Reference (BR) is changed under control and the implementation is derived from it again.
In classical systems a fault is detected after an expectation has already been violated — and only then does interpretation begin. If the expectation in the current state is known, the following can be determined immediately: what should happen? What actually happens? What is missing? Which condition is violated? Which transition is blocked? A fault is a symptom. A Behavior Deviation is a difference.
Classicalbehavior is interpreted
Classicalcause space open
Classicaltest logic reconstructed from code
Classicaltraceability to the intent is fragile
Classicalsymptom diagnostics
Classicalunderstand software backwards
The method checks conformity against the reference. If the reference is factually wrong, it will be realized correctly wrong. Only validation against the intent helps there.
The question everything turns on
15–30 minutes, concretely on your most critical machine. Free and without obligation.