Assume the best case: the intended behavior is fully described, free of contradictions, agreed and released. Even then nothing is proven about the realization — because translating that intent into code, HMI, documentation and data structure can only be checked by observation today. And observation has two limits.
What gets tested is what came up in testing: the normal sequence, the planned faults, the combinations someone thought of. The real state space — operating modes times recipes times fault situations times restart conditions — is orders of magnitude larger.
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.The Behavior Reference (BR) is to behavior what the P&ID is to process engineering and the wiring diagram is to electrical engineering: a target structure with normative authority over implementation and runtime.
It does not start with the model but with clarification: what the line is meant to achieve, with which technology, in which functions. Without that, you model assumptions.
Behavior is described as a finite state space: which states exist, which transitions are permitted, which conditions trigger them, which interlocks apply. What is not in it is not allowed — and that is exactly what makes checking decidable.
The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code. It is released, versioned and stays owned by the operator — handed over even to someone not called Selmo.
From the released Behavior Reference (BR) everything is derived — not invented and not described afterwards. If a result deviates, the deviation is detectable, because there is one source to detect it against. Code is the channel through which the defined behavior reaches the machine — and every channel has noise: ambiguity, added behavior, loss of meaning. That is not a property of the people operating it, it is a property of transmission.
By analogy to Claude Shannon's communication model: sender, message, channel, noise, receiver. The noise remains — the transmission can be checked. That is exactly what verification is: comparing what arrived with what was sent.
What is derivedThe sequence logic follows the state model. The Selmo Standard sets structure and naming rules, so that every line can be read the same way.
What is derivedOperation and diagnostics show the same states as the model. The operator does not see an interpretation of the behavior but the behavior itself.
What is derivedThe description comes from the same source as the implementation and therefore does not age independently of it.
What is derivedSignals, messages and key figures carry the same structure. PLCOpen XML is the exchange format — the reference stays readable outside our tools.
Four decisions structure the work. Each has a question answered with yes or no — not with a status.
The questionIs the intent determined well enough for engineering to start without silent assumptions?
The questionIs the expected behavior defined completely enough that the implementation does not have to invent behavior of its own?
The questionIs there an integrated, operable, checkable system?
The questionDoes the verified system fulfill the intent?
Confusing the two is the most common silent error in acceptance — and the reason a passed test sometimes says nothing about correctness.
Verification asks: was it built right? Validation asks: was the right thing built? The first question becomes decidable as soon as a reference exists: runtime behavior is checked against the Behavior Reference (BR), with test and acceptance logic derived from it.
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.Whether the defined target behavior is the right one is decided by no one but the operator. This check stays with you — the method does not take it off your hands, it only makes visible what exactly is being decided.
A correctly realized wrong reference is correctly wrong.The Behavior Reference (BR) is present on the machine at runtime. In operation, every deviation from the defined behavior is detected against it. When the target behavior changes, the changed reference is transmitted again — reference and runtime reference remain one and the same statement. What is detected is the deviation from the defined behavior: the defined behavioral space is the checked space, what is not modeled is not covered.
The reference closes the sample. The runtime reference closes the moment.Scientifically, little here is new — state machines, verification and validation have been described for decades. What is new is that behavior in machine building gets its own released artifact. So this section does not list what we researched; it lists what someone can verify without asking us.
Technical anchors the method can be measured against: finite state machines as the form of description, the distinction between verification and validation from systems engineering, and the requirements for systems with self-evolving behavior in Machinery Regulation (EU) 2023/1230.
A product name is only an answer once it is clear what is missing. That is why it appears here and not at the start.
Structure and naming rules, model levels, operating and diagnostics concept. Openly documented, so the reference stays applicable without us.
The environment in which you model and derive. Selmo Studio is a license, not an entry point: without qualification and without a released Behavior Reference (BR) it only models faster into the approximate.
Product overviewThe method checks conformity against the reference. If the reference is factually wrong, it will be correctly realized as wrong. Only validation against the intent helps there — and that stays with the operator.
The question this page starts from
15–30 minutes. We bring the answer, not the presentation.