Sicherheitsgerichtete Software muss nachweisbar richtig reagieren – auch im Fehlerfall. Hardware-in-the-Loop (HIL) prüft Ihre Geräte-Firmware automatisiert gegen eine simulierte Umgebung: reproduzierbar, mit gezielt provozierten Fehlern und mit belastbaren Nachweisen für die Verifikation nach IEC 61508. Unsere kompakte HIL-Testplattform LoopCheck schneiden wir dafür gezielt auf Ihr sicherheitsgerichtetes Gerät zu.
Ihre Position im 61508-Raum
Wir prüfen das echte Gerät – und liefern den SIL-Nachweis
Werkzeuge auf Code-Ebene prüfen den Quellcode, Beratung prüft die Dokumentation. Dazwischen bleibt eine Lücke: die Verifikation am echten Gerät und der Nachweis dazu. Genau die schließen wir – mit reproduzierbaren Tests am Gerät und einer Nachweiskette, die im Audit nach IEC 61508 trägt.
Warum HIL
Warum HIL für funktionale Sicherheit?
Fehlerfälle sicher provozieren
Das Sicherheitsverhalten zeigt sich erst im Fehlerfall. HIL speist Sensor-, Bus- und Timing-Fehler gezielt ein – ohne ein reales Gerät zu gefährden.
Reproduzierbare Verifikation
Jeder Testlauf ist bit-genau wiederholbar – die Grundlage für belastbare, prüfbare Nachweise.
Diagnose und Reaktionszeit
Sicherheitsfunktion, Fehlererkennung und Reaktionszeit gegen die geforderten Grenzen prüfen – automatisiert und wiederholbar.
Nachweise für IEC 61508
Anforderungen, Testfälle und Ergebnisse durchgängig verknüpft – als Evidenz für die Verifikation je Sicherheitsniveau (SIL).
Fallstudie: SIL-3-Sicherheitssensor
Für einen SIL-3-Sicherheitssensor haben wir mit LoopCheck Modul- und Systemtests aufgebaut – inklusive Code-Coverage-Nachweis über den Trace-Port. Fehlerfälle wurden gezielt injiziert, jeder Lauf reproduzierbar und mit belastbarem Nachweis für die Verifikation.
Norm
IEC 61508 in der Praxis
IEC 61508 ist die Basisnorm der funktionalen Sicherheit und verlangt – je nach Sicherheitsniveau (SIL 1 bis SIL 4) – dokumentierte Verifikation auf Modul-, Integrations- und Systemebene. Automatisierte HIL-Tests liefern genau diese Nachweise: reproduzierbar, prüfbar und in Ihren V-Modell-Prozess eingebettet. Die konkrete Sicherheitsstufe und der Nachweisumfang werden pro Projekt festgelegt – bis SIL 3 haben wir das in echten Projekten umgesetzt.
Die abgeleiteten Normen – etwa ISO 26262 (Automotive), EN 50128 / EN 50657 (Bahn) oder IEC 62304 (Medizin) – bauen auf denselben Prinzipien auf und berücksichtigen wir projektabhängig.
Systemtest am echten Gerät
Und der dokumentierte Test am fertigen Gerät
HIL verifiziert die Firmware. Am fertigen Gerät kommt der dokumentierte Systemtest dazu: Seriennummer, Firmware-Stand, gemessener Wert gegen Grenzwert, verwendetes Messmittel samt Kalibrierstand und der Prüfer. Beides greift ineinander – dieselbe Anforderung, zwei Nachweisebenen. Dafür gibt es XPressRT.
Häufige Fragen zu IEC 61508
Wie hilft HIL beim SIL-Nachweis nach IEC 61508?
Automatisierte, reproduzierbare HIL-Tests liefern die Verifikationsnachweise, die IEC 61508 je nach Sicherheitsniveau (SIL 1 bis SIL 4) auf Modul-, Integrations- und Systemebene verlangt – mit durchgängiger Verknüpfung von Anforderung, Testfall und Ergebnis.
Bis zu welchem SIL habt ihr Erfahrung?
Bis SIL 3 in echten Projekten – unter anderem ein SIL-3-Sicherheitssensor mit Modul- und Systemtests und Code-Coverage-Nachweis über den Trace-Port.
Wie prüft ihr das Fehler- und Sicherheitsverhalten?
Über gezielte Fehlerinjektion: Sensor-, Bus- und Timing-Fehler werden bewusst eingespeist, um Fehlererkennung, Sicherheitsreaktion und Reaktionszeit gegen die geforderten Grenzen zu prüfen – reproduzierbar und ohne reales Gerät.
Gilt das auch für ISO 26262 oder EN 50128?
Ja. Diese Normen leiten sich aus IEC 61508 ab und folgen denselben Prinzipien. Die relevante Norm und das Sicherheitsniveau werden pro Projekt vereinbart.
HIL für Ihr sicherheitsgerichtetes Gerät – von uns zugeschnitten
Alle technischen Details – Hardware-Konfigurationen, die Python-API, Architektur und ein vollständiges Beispiel – finden Sie auf der LoopCheck-Plattform.
- Verifikationsnachweise für IEC 61508 (SIL 1–3)
- Modultests bis Blackbox-Systemtests, automatisiert in CI/CD
- Gezielte Fehlerinjektion für Fehlererkennung und Reaktionszeit
- Tests in C, C++ oder Python – kein proprietäres Ökosystem
