Function
It runs
Everyone is satisfied — as long as it runs.
Losses · Performance · Risk
What if your line told you itself
where it loses performance?
Today, the behavior of your machines sits in a BlackBox. Losses, performance and risk are estimated — with MES, data projects and interpretation. In a WhiteBox, the target behavior exists as a reference, and this information is produced directly.
01 — Sound familiar?
Sound familiar?
The data is there. The answer is not.
You invest in MES, data acquisition and analytics. Yet the most important question stays open: what happened at the machine — and what does it cost?
Losses
The machine stops — and nobody knows why. People talk about motors, sensors and the programmer, not about the cause.
Performance
The line runs, but slower than planned. Which step costs cycle time remains a guess.
Additional investment
The data sits in the MES, but nobody can say what it means. Every analysis needs IT, specialists and someone to interpret.
Risk
Commissioning takes longer because the behavior is only created on site. The surprise comes when the business case has already been calculated.
02 — The cause
The cause
Everything you put on top of the machine is built on a BlackBox.
What gets described is what the machine should do — not how you can tell that it does it. A functional description knows two outcomes: it runs, or there is a fault. Only what someone thought of gets reported.
Acceptance does not close this gap either. 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. And a later change can alter what the evidence says.
In between lies a zone that is neither function nor fault. That is where downtime, underperformance and disputes arise.
Non-function
Fault
What gets reported is what someone foresaw.
Undefined
Neither
The machine stops without a message or runs slower without anyone noticing.
This undefined part is the BlackBox of your machine.03 — What is possible
Today · BlackBox
Fault 4711
Station 30 · timeout. Duration 18 minutes, cause unknown. Maintenance searches, the programmer gets a call. Management sees an OEE figure without an explanation.
Signal → Fault message → Search → Interpretation
With WhiteBox
Deviation
Station 30 · Clamping · step “Confirm clamping”. Expected: clamping position confirmed within the defined time. Result: not met. Consequence: feed blocked, as specified in the Behavior Reference (BR). Loss: 18 minutes, 42 parts.
Target → Actual → Decision → Loss in time and parts
WhiteBox does not mean you can see the code. WhiteBox means conformity is decidable rather than a matter of judgment.
Loss Pareto · availability · example
Station 30 · Clamping · clamping not confirmed96 min · 210 parts
Station 50 · Feeding · part not detected63 min · 140 parts
Station 20 · manual mode selected without fault39 min · 85 parts
Station 70 · Interlock21 min · 46 parts
Illustrative example with fictitious values. No additional MES project: the meaning of every state is defined in the Behavior Reference (BR), the cockpit displays it. It does not intervene in the control system — you decide the measures.
OEE Cockpit · two examples to tryExample 1 · Loss overview
Where does the time go? Availability, performance, bottleneck and waiting time at a glance, with evidence for each loss source. Open example
Example 2 · Pareto 80/20
Which few positions explain most of the loss? Every position in plain language from the Behavior Reference (BR). Open example
04 — How it works
The reference is present at runtime.
The deviation is determined, not searched for.
An operator screen shows what is happening. Whether what is happening matches what should happen can only be decided against a reference. The Behavior Reference (BR) is not after-the-fact documentation of the code. It exists before the code — just like a wiring diagram exists before installation.
01
The target
The target is fixed
States, transitions, times and reactions are defined in the Behavior Reference (BR) before programming starts.
02
The comparison
Deviations are decided
Every situation is decided against the target: conforms, deviates, or cannot currently be assessed. No message no longer means “all good”. What is detected is the deviation from the defined behavior; what is not modeled is not covered.
03
The information
One language for all machines
The information is standardized — structured the same way across machines, suppliers and control vendors.
Every BlackBox can become a WhiteBox — including your existing line.
Verification asks: was it built right? Validation asks: was the right thing built? Selmo addresses verification against the released Behavior Reference (BR). Validation against the original intent remains separately required.
05 — The impact
A loss figure
becomes a gain figure.
The benefit does not come from a single software feature, but from deciding instead of interpreting. The causality is clear; the size is project-specific.
01
See losses02
See performance potential03
Lower risk04
Raise productivitySee losses
Downtime in time and parts, with station, step and reason — as a Pareto, not as a guess.
See performance potential
Step times against target show the bottleneck. You know where a cycle time increase starts.
Lower risk
Fewer unplanned stops, reliable economics and deviations you can evidence — including towards suppliers.
−50 to −80 %commissioning time
−40 to −70 %unplanned downtime
+3 to +10 %OEE
−25 to −50 %maintenance
+5 to +20 %output
Ranges from delivered customer projects. The actual value is project-specific and is measured in the assessment on your machine.
06 — Take a look
Not a technical question.
The question is: where do things stand right now?
Only those who look can compare. Nobody needs to read a program for that. Five criteria show where your line stands today. Every no is not a verdict but a finding.
The key question
“Against which document do you check whether your machine behaves correctly?”
Defined
Is there a separate document for the behavior — like the wiring diagram?
Decidable
Can you check the behavior without reading the program?
Diagnosable
Does the machine show which expectation was not met?
Changeable under control
Is a change made in the target behavior first?
Transferable
Does the knowledge stay when the person or the supplier leaves?
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 survives changes.
L5
Architecture
fully derived from the Behavior Reference (BR).
The maturity level is assigned by the WhiteBox Assessment, with evidence at the line. The self-check gives a first impression.
07 — The path to a decision
Two steps
to a clear decision.
Both steps work with your people and your documents. They require no upfront work and no changeover — and both may conclude that now is not the right time.
Step
What happens
What you receive
Strategy Workshop
two days on site
two days on site
Day 1: target picture and use case. Day 2: scope, boundaries and sequence. Notes are written during the discussion, not afterwards.
Target picture · use case with rationale · scope and boundaries · roadmap · open assumptions
WhiteBox Assessment
one to three days on site
one to three days on site
Documents, conversations with the people who know the line, observation at the line. Every requirement is classified: directly decidable, indirect, limited or not decidable.
Classification report · maturity profile L0–L5 · gap list by impact · action path
Your decision
Is the goal clear enough for engineering to start without unstated assumptions?
A classification, not a purchase recommendation. The documents belong to you.
08 — Effort and savings
Your effort does not increase.
It moves to the front.
The questions about behavior get answered anyway — today just too late: in commissioning, in downtime, in disputes. With Selmo they are answered before programming starts.
In implementationLess rework and focused commissioning with a reduced space of possible causes.
In operationShorter time to cause, because the machine shows which expectation was not met.
On add-on toolsNo more tools that have to interpret afterwards what the machine meant.
The biggest saving: deciding instead of judging, interpreting and trying.
Every situation that can be decided no longer needs anyone to judge it. That saves time in every meeting, every fault and every acceptance — over the entire lifetime of the line. Warranty replaces the repair, not the downtime: the outage stays with the operator.
09 — The machine behavior study
We are looking at 100 lines.
Will yours be one of them?
Every Strategy Workshop and every WhiteBox Assessment answers the same question: where do things stand right now? With your consent, the results flow anonymously into a study of machine behavior in production.
Never again without a Behavior Reference (BR). Just as never again without a drawing or a wiring diagram.
10 — For machine builders and automation
Your responsibility stays.
Your programming performance becomes provable.
When your customers require the target behavior, market requirements shift. Those who can prove what they delivered stand out. Those who cannot come under competitive pressure.
How do you engineer your programming today?
Is the behavior created in engineering — or only during commissioning?
Against what is your programming verified?
Against a released target — or against whatever runs in the end?
What is your result from engineering?
Apart from the code: is there an object your customer can check?
Step
What it requires
Basis
01 Define the effect
Which action, which expected reaction?
Process
02 Design instead of trial and error
Is the effect realizable, measurable and decidable? Risks are identified and assessed before the code — possible even before the hardware, as part of the risk assessment.
Technology
03 Release the target behavior
States and transitions go into the Behavior Reference (BR) — released before programming starts.
Function · Behavior Gate
04 Verify against the target
The implementation preserves the structure and sequence logic of the Behavior Reference (BR).
Verification Gate
05 Prove the effect
Commissioning, FAT and SAT check against the released target — not against an as-built.
Acceptance
06 Change the target first
Every change starts in the Behavior Reference (BR); the evidence is renewed in a targeted way.
Change Verification
Worked out through PTF (Process · Technology · Function) according to Behavior-Centric Engineering (BCE).
11 — Machinery Regulation
Regulation (EU) 2023/1230
From 20 January 2027, “it runs” becomes a question of evidence.
The regulation does not prescribe a method. But it does require that what was assessed and designed can be evidenced.
A Behavior Reference (BR) structures evidence and contributes to the documentation. Safety functions still need their own design and validation; the conformity assessment remains with the machine manufacturer.
Annex III · General principles
Risk assessment
across the entire lifecycle, as the basis of the design.
Annex III · 1.2.1
Control systems
Hardware and software faults as well as logic errors must not lead to hazardous situations.
Annex III · 1.2.1
Traceability
Interventions and uploaded versions of safety-related software must remain traceable.
Summary, not legal advice. The wording of the regulation is authoritative.
12 — Engineering on the table
Take a look
at how your programs are created today.
Show us your design, translation and evidence of effect. We will show you where your engineering stands today.
Commissioning
Is the behavior created in engineering — or only discovered during commissioning?
Performance
Is your programming performance provable — or merely functional?
Risk assessment
Could you evidence that the risk assessment took place before programming?
And what does that mean for your responsibility?
Responsibility does not change. What is new is that you can evidence what was required, what was delivered and where a deviation lies.
13 — Who builds this
Why we can talk
about behavior.
Selmo grew out of commissioning, not out of consulting. The method was developed on real lines and corrected where a deviation means downtime. What we claim about behavior, we checked against a reference ourselves first.
What the method does not do
Selmo replaces neither commissioning nor experience — it reduces the space of possible causes. And what is checked is always the defined behavioral space: what is not modeled is not covered.
The decisive question
If your machine stops tomorrow — how much of it could you prove?
Take a look — book an intro call15–30 minutes, specific to your most critical machine. Free of charge and without obligation.