Every channel has noise: ambiguity, added behavior, loss of meaning. A channel without checking is a bet. A channel is not at fault, it is noisy — the noise is not a property of the people operating it but a property of transmission. So the question is not who works carefully, but what the result is checked against.
It holds for the section that was checked and for the moment it was checked. Where no reference exists, commissioning checks against experience — and experience says nothing about what never occurred.
The noise remains — the transmission can be checked.When code, HMI, documentation and data structure are derived from the same released source, many hand-guided transmissions are replaced by a single one — and that one is itself checkable.
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.The project presupposes a released Behavior Reference (BR). Without it there would be nothing to decide the result against — then it would be an implementation project like any other.
Control code, HMI, documentation and data structure are derived from the released reference. Not maintained in parallel but taken from the same source — which is why they cannot drift apart unnoticed.
Drives, interfaces, field level, connection to higher-level systems. That is craft and stays craft. What changes is only what it is checked against at the end.
The running behavior is checked against the Behavior Reference (BR) — with test and acceptance logic derived from it. Every deviation is a named deviation, not an observation someone has to classify.
At the end comes the second question, and it is a different one: whether what was verified is also what the plant wanted. Nobody answers that but you.
What is handed over is not only a running line but the means to trace later why it behaves the way it does.
Derived from the reference, runnable in your target environment, readable in the PLCOpen XML exchange format.
Derived from the same source. What is on the screen is also in the reference — and the other way round.
Derived from the reference, not written separately. That is why it checks against the determination and not against a second opinion.
What was checked, with what result, and which deviations remained open.
Reference, derivations and records are owned by the operator and are transferable.
A gate is a decision, not a date. This project leads to two — one about the state of the system, one about its purpose.
Code, HMI, documentation and data structure from the released reference. Alignment with your target environment.
—
Hardware, interfaces, connections. Virtual commissioning where a model of the line exists.
—
Checking runtime behavior against the Behavior Reference (BR) with derived test and acceptance logic.
Verification Gate
Does the verified system meet the intent from Gate 0. Handover in conversation, not by file.
Validation Gate
An offer does not become stronger by covering everything. It becomes stronger when its edge is known.
Code, HMI, documentation, data structure, test and acceptance logic, checking runtime behavior against the reference.
With a reduced space of causes: where a reference exists, a deviation is known to deviate from something.
Your specialists work with us. Whoever is to change the line later has to be able to read the reference — not to call us.
Creating and releasing the Behavior Reference (BR) is the PTF- & Behavior-Reference-Pilot and has to be completed beforehand.
Electrical design, cabinet building and mechanical construction remain trades of their own.
Changes after handover and their Change Verification belong to Lifecycle Services.
The project provides material for the evidence trail. Conformity assessment remains with the machine builder.
The order is the path, not the revenue. The project is the fourth step: it implements. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code — which is why this project cannot start before the pilot is finished. Verification asks: was it built right? Validation asks: was the right thing built? This project answers both, in that order. On the role of artificial intelligence: it accelerates translation — not verification. The evidence that software realizes the defined behavior still depends on observation, and observation scales with real time on a real machine.
Target picture, use case and roadmap.
Where conformity is decidable today and where behavior has no reference.
One released Behavior Reference (BR) for a bounded unit module.
Implementation derived from the Behavior Reference (BR) and verified against it.
Behavior-Centric Engineering (BCE) as the standard across several plants.
Behavioral integrity across the lifecycle, changes as change verification.
Enabling the team, Selmo-owned qualifications.
Checking happens against the released reference. What is not modeled is not covered — verification makes that edge visible, it does not remove it.
The question every implementation project starts from
15–30 minutes. We bring the answer, not the presentation.