Case study
What was at stake
Consider a saw on a factory line. If an operator puts a hand into the blade area, the outcome is not a bad log line. It is a serious injury. Machines like this need to notice that something has gone wrong and put themselves into a safe state before anyone gets hurt.
Solcept was developing a safety framework for exactly this class of problem. My work over six months in Zürich was to build the demonstrator that proved it out: a physical rig standing in for a hazardous machine, wired so that its failure modes could be triggered deliberately and observed.
A demonstrator has an unusual requirement. It has to be correct, but it also has to be legible: someone who did not build it needs to watch it break and immediately understand why it did the safe thing. That audience, and the engineers who would carry the framework forward, shaped the design as much as the standard did.
The constraint that shapes everything
A controller that has failed does not know it has failed. That single sentence drives the entire architecture.
You cannot ask a microcontroller to report its own death. So the system needs a second unit whose job is to watch the first, and if the primary stops behaving, the backup halts everything. This is fault tolerance. The system stays safe not because its parts do not break, but because a broken part cannot go unnoticed.
The safety target came from ISO 13849, which frames risk along three axes:
- Severity: S1 (normally reversible injury) through S2 (irreversible injury or death)
- Frequency / exposure: F1 (seldom, short exposure) through F2 (frequent or continuous)
- Possibility of avoidance: P1 (possible under specific conditions) through P2 (scarcely possible)
Those inputs put the demonstrator at Performance Level C–D, which is what the design had to satisfy.
What I built
The rig models a closed room containing fictional machines. Two CO₂ sensors watch the air; if concentration crosses a threshold, operations stop. Two fans on the sides of the enclosure ventilate to clear it.
Everything that matters is doubled: two boards, two fans, two sensors, two displays, two failure injectors.
Two controllers watching each other
The compute is a pair of NXP S32K142 automotive microcontrollers, talking over UART.
Because a lost or corrupted message between them could produce exactly the silent misbehaviour the system exists to prevent, the inter-controller protocol enforces strict validation on every message rather than trusting the link.
Handling events in bounded time
Safety logic cannot afford unpredictable pauses. Events are handled through a circular buffer, a fixed-size ring, so memory is allocated once and the cost of an enqueue or dequeue is constant and known ahead of time. In a real-time context, predictable beats fast.
Sensing and display
CO₂ comes from Sensirion SEK-SCD41 sensors on I²C.
LCD displays surface the current measurements, the system state and, when something trips, the cause of the failure, so the rig explains itself instead of just stopping.
The I²C buses tying the controllers, sensors and displays together were built out by hand.
The first fans could not move enough air to clear the CO₂, so they were replaced with larger ones, then fitted to the enclosure with a certain amount of improvisation.
Proving it actually fails safely
A safety claim you cannot test is a belief. The rig has failure-injection buttons wired in, so each fault condition can be triggered on demand and the system’s reaction watched directly.
Restart behaviour is modelled with an SPDT switch standing in for a door being open or closed. An SPDT switch always completes one of its two circuits, so there is no ambiguous middle position to misread, which is why it suits a safety input. The machine may only restart once the door reads closed and the operator has acknowledged the stop.
What came of it
The finished demonstrator does what it was built to do: it detects the hazard, halts the machine, states why, and refuses to restart until a human confirms the situation is safe. It keeps doing that when you deliberately break one of its halves.
The demonstrator was documented and presented internally, so it could serve as groundwork for the customer-facing safety systems the framework was meant to support. A proof of concept nobody can pick up afterwards has not really proved anything.
Working under ISO 13849 changed how I think about systems well beyond embedded work. Most software I had written until then assumed components fail loudly. Safety engineering starts from the opposite premise, that the dangerous failure is the quiet one, and designs so that nothing important depends on a single component being honest about its own health. I reach for that instinct constantly now in backend and ML infrastructure.
© All rights reserved to Solcept AG.