Process engineering
P&IDprocess structure
The missing technical object
The plan for
behavior.
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.
01 — The finding
Everything has a plan.
Except behavior.
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.
Electrical engineering
Wiring diagramintended electrical structureMechanics
Drawinggeometry and assemblyInstrumentation
Instrument listmeasurement structureBehavior
— missing —no artifact carries behavior normativelyThis is not a criticism of engineering. What is missing is an object, not a capability.
02 — The three reductions
Three answers.
None of them is behavior.
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.
Reduction 01 — Representation
It describes behavior
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.
Reduction 02 — Realization
It produces behavior
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.
Reduction 03 — Observation
It shows behavior
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.
The classification
"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.
03 — The missing object
The plan for behavior
is the Behavior Reference (BR).
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.
01
Precondition · PTF (Process · Technology · Function)
Can the expectation be decided at all?
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.
02
Behavior Reference (BR)
The intended structure of behavior
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.
03
Behavior Gate
The decision before implementation
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.
04
Engineering Behavior Reference
The released reference
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.
What the Behavior Reference (BR) is NOT
Not code
Code is derived from the Behavior Reference (BR), not the other way round. It contains no programming syntax.
Not after-the-fact documentation
It does not describe an existing program; it defines the intended behavior that is checked against.
Not a device list
It describes behavior: states, actions, expected reactions, conditions and transitions — not devices.
Not a vendor model
It is technology-independent; PLCOpen XML as the exchange format.
04 — The translation
Four translations.
Four interpretations.
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.
Codeinterpreted from requirements. It may compile and appear functional — that proves nothing.
HMIan independently interpreted view of states, operation and messages.
Documentationa third reading of the same intended behavior, often written later.
Data structurenaming and structure follow the interpretation, not the definition.
The core of this stage
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.
05 — The actual gap
Even if the target is correct:
Even a passed acceptance test proves less than it promises.
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."
Two separate proofs
Proof
Question
Status today
ProofVerification of the Behavior Reference (BR)
QuestionIs the Behavior Reference (BR) complete and free of contradictions?
Status todaysolvable with a Behavior Reference (BR)
ProofVerification of the translation
QuestionDo code, HMI, documentation and data structure realize the Behavior Reference (BR) correctly?
Status todayopen
Limit 01 — State space
It checks a sample
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.
Limit 02 — Point in time
It holds for one moment
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.
06 — Verification and validation
Two questions.
Not one.
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.
01
Verification
Runtime behavior against the Behavior Reference (BR)
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.
02
Validation
The verified system against the intent
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.
A gate is a decision
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?
07 — From BlackBox to WhiteBox
Behavior Interpreted Machine
BlackBox
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.
Engineering→interpretation→code→observed behavior
Behavior Defined Machine (BDM)
WhiteBox
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.
Engineering→Behavior Reference (BR)→implementation→provable behavior
WhiteBox does not mean you can see the code. WhiteBox means conformity becomes decidable instead of a matter of judgment.
L0
BlackBox
behavior only in the code.
L1
Described
in prose, not formally checkable.
L2
Explicit states
structured, without normative authority.
L3
Decidable
turning point WhiteBox.
L4
Lifecycle
decidability is maintained across changes.
L5
Architecture
fully derived from the Behavior Reference (BR).
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).
08 — Preserving semantics instead of translating
A translation
becomes a derivation.
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.
01
Against the state space limit
Conformant, not merely occurred
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.
02
Against the point-in-time limit
The comparison does not end with acceptance
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.
03
For diagnostics
Deviation instead of symptom
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.
What this means across the lifecycle
Phase
Classical
Behavior Defined
PhaseImplementation
Classicalbehavior is interpreted
Behavior Definedbehavior is derived
PhaseCommissioning
Classicalcause space open
Behavior Definedcause space reduced to hardware, interface, process assumption
PhaseVerification
Classicaltest logic reconstructed from code
Behavior Definedtest logic derived from the Behavior Reference (BR)
PhaseValidation
Classicaltraceability to the intent is fragile
Behavior Definedtraceability preserved
PhaseOperation
Classicalsymptom diagnostics
Behavior Definedcontinuous target/actual comparison
PhaseChange
Classicalunderstand software backwards
Behavior Definedchange the Behavior Reference (BR), derive again
Behavior-Centric Engineering (BCE) is the approach. The Behavior Reference (BR) is the engineering object it produces. A Behavior Defined Machine (BDM) is a machine whose code, HMI, documentation and data structure are derived from it.
The model leads: changes are described in the Behavior Reference (BR) and derived again — never directly in the code.
What the method does not do
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
Where in the project does it first become visible that someone understood behavior differently than intended?
Look at the answer together15–30 minutes, concretely on your most critical machine. Free and without obligation.