IIoT & Energy
A safety subsystem for drives, designed up to SIL 3 and PL e
A two-channel safety subsystem with its own FSoE stack, tested in a hardware-in-the-loop system with a qualified toolchain. The client is the manufacturer placing the product on the market and is responsible for approval tests and type examination.
The task
Safety functions are moving into the drive: machine builders expect it to switch off, stop and control the brake safely on its own, commanded either through safe inputs or over the fieldbus. The client wanted a subsystem of its own for this, usable in several of its products, with Safe Torque Off, Safe Stop 1 and Safe Brake Control, driven through safe inputs with test pulses or through Fail Safe over EtherCAT, FSoE for short.
The roles were clearly split. The client is the manufacturer placing the product on the market and is responsible for everything that comes with it, including approval tests and type examination. Our part was the subsystem with the evidence an assessor wants to see, among it hardware architecture, firmware, FSoE stack, test environment and end-of-line testing.
The solution
The subsystem is built with two channels. Two microcontrollers run the same safety logic and cyclically exchange control and status words, which each channel compares bit for bit against its own. If a frame stays away for longer than the diagnostic window or the data differ, the channel enters the safe state; a locked safe state allows no restart until the fault is acknowledged.
We wrote the FSoE stack ourselves on both sides: the slave in the device over a black channel, the master as a Linux library for testing. It can inject faults deliberately, such as a wrong sequence counter or a missing frame, which makes it the counterpart in the hardware-in-the-loop system. Every firmware change runs in the pipeline against real hardware, from watchdog expiry to a temperature fault.
For SIL 3 the tools must be demonstrable too. Compiler, coverage tool, test framework and static analysis run as a qualified chain in CI, and deviations are recorded in a register with their rationale. The firmware is built on semf, our software architecture; end-of-line testing runs on qdTest. What we delivered to the client is a subsystem whose chain of evidence, from requirement to test case, is in its own hands.