A passed acceptance test is a snapshot of a sample: it holds for the section that was checked and for the moment it was checked. What was never observed has not been tested — it simply did not come up. On a customer line that statement can be asserted. On a model it can be demonstrated.
The model is here, it runs, and every step on it is repeatable. It needs no consent, hides no boundary condition and can be touched during a conversation. Its construction weaknesses stay visible too — they are part of the example, not a flaw in it.
An example nobody is allowed to retrace is not evidence.Times and effort on the model are times and effort on the model. They show that the path can be completed and where it becomes decidable — they say nothing about what it saves on your line.
Structure transfers. Effect is measured, not transferred.This picture holds for the model as it does for a real line. The difference is the size of the state space, not the approach.
From intent to evidence. The dashed return is where most evidence expires silently: every change is checked again against the changed reference.
Each step ends with something that did not exist before — and with a decision answered yes or no.
The model runs. There is code, there is an operator interface, there are people who know how it behaves. What there is not: a document to check against whether that behavior is correct. That is L0 — BlackBox. Not for lack of skill, but for lack of an object.
What is the transfer line meant to achieve, with which technology, in which functions. On the model that takes hours, on a line it takes days — the questions are the same. It ends at Gate 0: is the intent determined well enough for engineering to start without silent assumptions?
Now the Behavior Reference (BR) is created: which states exist, which transitions are permitted, what triggers them, what blocks them. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code. It ends at the Behavior Gate: is the expected behavior defined completely enough that the implementation does not have to invent behavior of its own?
From the released reference, code, HMI, documentation and data structure are derived — following the structure and naming rules of the Selmo Standard, in Selmo Studio. If a result deviates, the deviation is detectable, because there is one source to detect it against.
On the digital twin the derived behavior runs against the reference. Verification asks: was it built right? Validation asks: was the right thing built? Here the first question is answered — before anyone stands in front of the line. It ends at the Verification Gate: is there an integrated, operable, checkable system?
The model runs for real, the same check logic applies. WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment. It ends at the Validation Gate: does the verified system fulfill the intent? That question is answered by the operator, not by the tool.
These values were taken on the model and hold for the model. They are here because they show the path was completed in full — not to claim anything about your line.
Two machining stations in two sequences: infeed to the milling machine, then infeed to the drilling machine with outfeed.
Seventeen — nine in the first sequence, eight in the second.
About three days with practice, about five without. Roughly two of them to add kinematics to the STEP model with digifai twin. The control side came across via PLCOpen XML into TwinCAT 3 on a Beckhoff controller. The global variable lists are derived from the Behavior Reference (BR) — the variables are therefore directly addressable over ADS or OPC UA.
About four hours with practice, about one day without. Almost all of that effort sits on the hardware: checking whether light barriers and switches actually switch, and scanning in the system components — here the I/O cards.
Whatever the real hardware does differently than assumed is changed in the Behavior Reference (BR) and derived again — never directly in the code. The change runs on the digital twin first and only then goes to the line.
Measured on the transfer-line model with two sequences and seventeen states. The times separate practised from unpractised users because at this scope that difference is larger than any other variation. None of these numbers holds for your line — there it is measured in the assessment.
The ranges below do not come from the model but from projects on real lines. They are project-specific and therefore carry a condition.
Ranges from completed customer projects. The actual value is project-specific and is measured on your line during the assessment.
Both are in use on the model and are the same on a real line: the rule set sets the structure, the tool makes the derivation practicable.
Structure and naming rules, model levels, operating and diagnostics concept. Openly documented, PLCOpen XML as the exchange format — the reference stays readable without us.
See Selmo Standard
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.
See Selmo Studio
The defined behavioral space is the checked space. What is not modeled is not covered — the boundary moves, it does not disappear.
The question this example asks
15–30 minutes. We bring the answer, not the presentation.