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 places the product on the market and is responsible for regulatory approval tests and type examination.
The task
Safety functions are moving into the drive: machine builders expect the drive itself to switch off, stop and control the brake safely, commanded either through safe inputs or over the fieldbus. The client wanted its own subsystem for this, usable in several of its products, with Safe Torque Off, Safe Stop 1 and Safe Brake Control, commanded through safe inputs with test pulses or through Fail Safe over EtherCAT, FSoE for short.
The roles were clearly divided. The client places the product on the market and is responsible for everything that comes with it, including regulatory approval tests and type examination. Our task was the subsystem with the evidence the assessor wants to see, including hardware architecture, firmware, FSoE stack, test environment and end-of-line testing.
The solution
The subsystem has two channels. Two microcontrollers run the same safety logic and cyclically exchange control and status words, which each channel compares bit for bit with its own. If a frame fails to arrive within the diagnostic window or the data differ, the channel enters the safe state; a latched safe state allows no restart until the fault has been acknowledged.
We wrote the FSoE stack ourselves, on both sides: the slave in the device, over a black channel, and the master as a Linux library for testing. The master can inject faults deliberately, such as a wrong sequence counter or a missing frame, and so acts as the counterpart in the hardware-in-the-loop system. Every firmware change runs through the pipeline against real hardware, from watchdog expiry to a temperature fault.
For SIL 3, the tools need evidence as well. Compiler, coverage tool, test framework and static analysis run as a qualified toolchain in CI, and deviations are recorded in a register with their justification. 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 the client's own hands.