Defined on the left, derived at the bottom,
checked against the definition on the right.
Every stage on the right is checked against the stage on the left at the same level. What is new: at the level of implementation there is an object you can check against.
Specification · intent
What should the line deliver — and under which conditions?
Gate 0Behavior Defined Machine (BDM)
The Behavior Reference (BR) is present at runtime. The OEE Cockpit shows deviations in plain language.
PTF
Process · Technology · Function: define the effect, design for measurability and decidability — as part of the risk assessment, before the hardware.
Commissioning · acceptance
Real effect against the target: FAT and SAT check against the released reference, not against an as-built.
Validation GateBehavior Reference (BR)
States, transitions, times and reactions as a normative reference. It exists before the code.
Behavior GateCode · HMI · documentation · data architecture
Derived from the same reference, PLCopen XML as the exchange format.
Verification GateSelmo Studio
Method · Selmo Standard · algorithm. The behavioral semantics are derived in a semantics-preserving way — rule-based, without AI, without an interpretation step.
Verification asks: was it built right? Validation asks: was the right thing built? A passed acceptance test is a snapshot of a sample: what was never observed has not been tested — it simply did not come up. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code. Phase 1 and phase 3 are method-neutral requirements; anyone who takes a different path in phase 2 must provide equivalent evidence.
Method, standard, algorithm.
One channel instead of many.
Code, HMI, documentation and data structure are derived from the reference. Many manually maintained channels become one — and that one can itself be checked.
Behavior Reference (BR)
Released at the Behavior Gate. Documents the target behavior of the machine.
Hardware engineering
Stations, sequences, zones and I/O from the PTF (Process · Technology · Function).
Method
Behavior-Centric Engineering (BCE): behavior is defined and released before implementation.
Selmo Standard
The open rule set for structure, naming and derivability — the architecture is specified, not negotiated.
Algorithm
Rule-based, deterministic derivation. Patented — granted internationally. Without AI.
Code
IEC 61131-3, PLCopen XML as the exchange format.
HMI
Sequence Control: operation and display in the plain language of the reference.
Documentation
From the same source, and therefore congruent with the code.
Data architecture
Standardized states and losses — the basis for the OEE Cockpit.
The room for interpretation does not disappear through better checking, but because the interpretation step is eliminated. The derivation rule is checkable, not infallible: if the reference is factually wrong, it is realized correctly wrong. Hardware, interfaces and process physics lie outside this path.
AI speeds up translating —
not checking.
Whether written by hand or with AI: wherever there is an interpretation step between the released reference and the code, the evidence depends on observation. The bottom of the V decides how much still has to be checked on the right.
| At the bottom of the V | Programmed by hand | Created with AI | Selmo Studio · derived |
|---|---|---|---|
| Interpretation step | Yes — the person interprets. | Yes — the model interprets, not necessarily the same way for the same input. | Eliminated. Same reference, same result. |
| Architecture according to the standard | Depends on the person, the guideline and the review. | Not ensured by the procedure. | Specified by the Selmo Standard. |
| Evidence that the code matches the reference | Through observation: test, simulation, commissioning. | Through observation — for every newly created version. | Checkable derivation rule plus verification against the Behavior Reference (BR). |
| Checking and review effort | Again for every change. | Grows with the amount of code created. | Targeted: change in the reference, derived again. |
The evidence depends on observation, and observation does not scale with computing power but with real time on a real line.
A path that can deliver a different result for the same input increases the checking and review effort — instead of reducing it.
Information instead of data.
Freely evaluable, unambiguous in meaning.
If the target behavior is present at runtime, the deviation is determined, not observed — and not at one point in time, but continuously.
The meaning of every value
Station, sequence, step and zone in plain language from the Behavior Reference (BR), loss reasons according to the Selmo Standard. Nobody has to interpret what a signal means.
View, period, action
Losses in time and parts, separated by availability and performance, as a Pareto 80/20. The cockpit displays and does not intervene in the control system — you decide the actions.
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.
What, how and who —
in short answers.
For the conversation with procurement, engineering and management.
01What is the Behavior Reference (BR)?
The documentation of the target behavior as a separate, checkable object: states, transitions, times, reactions and permissible deviations. Just as the wiring diagram specifies the electrical target structure, the Behavior Reference (BR) specifies the behavior — before programming starts.
02Who creates it — do we need Selmo for that?
Anyone who finds the relationships documented can model it: programmers, process engineers, electrical or mechanical designers. Phase 1 is a method-neutral requirement. Selmo supports with PTF (Process · Technology · Function), Selmo Studio and Certification & Training.
03What exactly does Selmo Studio do?
It provides the method, the Selmo Standard and the algorithm. Code, HMI, documentation and data architecture are derived rule-based from the released Behavior Reference (BR) — with PLCopen XML as the exchange format into existing development environments.
04Why no AI in the derivation?
Because the step at the bottom of the V must be provable. A procedure that can deliver different results for the same input ensures neither the architecture according to the standard nor conformity with the reference — both would have to be evidenced again through observation. That increases the checking and review effort instead of reducing it.
AI has its place — in wording, structuring and evaluating. Not where the evidence is created.
05What changes in the V-model?
The structure stays. The left side ends with a released Behavior Reference (BR) instead of a functional description. At the bottom, things are derived instead of interpreted. The right side checks against an object instead of against experience or an as-built.
06What do I get in operation?
A Behavior Defined Machine (BDM): the reference is present at runtime, deviations are determined in plain language. The OEE Cockpit shows losses in time and parts, without an additional data project that first has to establish the meaning.
07Is the derivation error-free?
It is checkable, not infallible. If the reference is factually wrong, it is realized correctly wrong — which is why validation against the intent remains separately required. Hardware, interfaces and process physics lie outside the derivation path.
08What applies to safety functions and the Machinery Regulation?
The Behavior Reference (BR) structures evidence and contributes to the documentation. Safety functions still need their own design and validation; the conformity assessment under Regulation (EU) 2023/1230 remains with the machine manufacturer.
The derivation is checkable, not infallible: if the reference is factually wrong, it is realized correctly wrong. Validation against the original intent therefore remains separately required.