Safety-related software has to react demonstrably correctly – even in the fault case. Hardware-in-the-Loop (HIL) tests your device firmware automatically against a simulated environment: reproducibly, with deliberately provoked faults and with dependable evidence for verification under IEC 61508. We tailor our compact HIL test platform LoopCheck to your safety-related device.
Your position in the 61508 space
We test the real device – and deliver the SIL evidence
Code-level tools check the source code, consultants check the documentation. In between a gap remains: verification on the real device and the evidence for it. That is exactly what we close – with reproducible tests on the device and a chain of evidence that holds in an IEC 61508 audit.
Why HIL
Why HIL for functional safety?
Provoke fault cases safely
Safety behaviour only shows in the fault case. HIL injects sensor, bus and timing faults on purpose – without endangering a real device.
Reproducible verification
Every test run is bit-exact repeatable – the basis for dependable, auditable evidence.
Diagnostics and reaction time
Check the safety function, fault detection and reaction time against the required limits – automated and repeatable.
Evidence for IEC 61508
Requirements, test cases and results linked end to end – as evidence for verification at each safety integrity level (SIL).
Case study: SIL 3 safety sensor
For a SIL 3 safety sensor we built module and system tests with LoopCheck – including code-coverage evidence over the trace port. Fault cases were injected deliberately, every run reproducible and with dependable evidence for verification.
Standard
IEC 61508 in practice
IEC 61508 is the base standard for functional safety and requires – depending on the safety integrity level (SIL 1 to SIL 4) – documented verification at module, integration and system level. Automated HIL tests deliver exactly this evidence: reproducible, auditable and embedded in your V-model process. The specific safety level and the scope of evidence are agreed per project – up to SIL 3 we have delivered this in real projects.
The derived standards – such as ISO 26262 (automotive), EN 50128 / EN 50657 (rail) or IEC 62304 (medical) – build on the same principles and are addressed per project.
System test on the real device
And the documented test on the finished device
HIL verifies the firmware. On the finished device the documented system test is added: serial number, firmware state, measured value against limit, the instrument used with its calibration state, and the tester. The two mesh – the same requirement, two levels of evidence. That is what XPressRT is for.
Frequently asked questions about IEC 61508
How does HIL help with SIL evidence for IEC 61508?
Automated, reproducible HIL tests provide the verification evidence that IEC 61508 requires – depending on the safety integrity level (SIL 1 to SIL 4) – at module, integration and system level, with end-to-end links between requirement, test case and result.
Up to which SIL do you have experience?
Up to SIL 3 in real projects – including a SIL 3 safety sensor with module and system tests and code-coverage evidence over the trace port.
How do you test fault and safety behaviour?
Through deliberate fault injection: sensor, bus and timing faults are injected on purpose to check fault detection, safety reaction and reaction time against the required limits – reproducibly and without a real device.
Does this also apply to ISO 26262 or EN 50128?
Yes. These standards derive from IEC 61508 and follow the same principles. The relevant standard and safety level are agreed per project.
HIL for your safety-related device – tailored by us
All the technical detail – hardware configurations, the Python API, architecture and a complete worked example – is on the LoopCheck platform.
- Verification evidence for IEC 61508 (SIL 1–3)
- Module tests through to black-box system tests, automated in CI/CD
- Deliberate fault injection for fault detection and reaction time
- Tests in C, C++ or Python – no proprietary ecosystem
