IIoT & Energietechnik
Ein Sicherheits-Teilsystem für Antriebe, ausgelegt bis SIL 3 und PL e
Ein zweikanaliges Sicherheits-Teilsystem mit eigenem FSoE-Stack, geprüft im Hardware-in-the-Loop-System und mit qualifizierter Werkzeugkette. Der Auftraggeber ist Inverkehrbringer und verantwortet Zulassungstests und Baumusterprüfung.
Die Aufgabe
Sicherheitsfunktionen wandern in den Antrieb: Maschinenbauer erwarten, dass er selbst sicher abschaltet, stillsetzt und die Bremse ansteuert, wahlweise über sichere Eingänge oder über den Feldbus. Der Auftraggeber wollte dafür ein eigenes Teilsystem, einsetzbar in mehreren seiner Produkte, mit Safe Torque Off, Safe Stop 1 und Safe Brake Control, angesteuert über sichere Eingänge mit Testpulsen oder über Fail Safe over EtherCAT, kurz FSoE.
Die Rollen waren klar verteilt. Der Auftraggeber ist Inverkehrbringer und verantwortet, was daran hängt, darunter Zulassungstests und Baumusterprüfung. Unsere Aufgabe war das Teilsystem mit den Nachweisen, die der Prüfer sehen will, unter anderem Hardwarearchitektur, Firmware, FSoE-Stack, Prüfumgebung und Serienprüfung.
Die Lösung
Das Teilsystem ist zweikanalig gebaut. Zwei Mikrocontroller führen dieselbe Sicherheitslogik aus und tauschen zyklisch Steuer- und Statusworte aus, die jeder Kanal bitgenau mit seinen eigenen vergleicht. Bleibt ein Telegramm länger als das Diagnosefenster aus oder weichen die Daten ab, geht der Kanal in den sicheren Zustand; ein verriegelter sicherer Zustand lässt keinen Neustart zu, bis der Fehler quittiert ist.
Den FSoE-Stack haben wir auf beiden Seiten selbst geschrieben: den Slave im Gerät über einen Black Channel, den Master als Linux-Bibliothek für die Prüfung. Sie kann Fehler absichtlich einbauen, etwa einen falschen Sequenzzähler oder ein ausbleibendes Telegramm, und ist damit die Gegenstelle im Hardware-in-the-Loop-System. Jede Firmware-Änderung läuft in der Pipeline gegen echte Hardware, vom Watchdog-Ablauf bis zum Temperaturfehler.
Für SIL 3 muss auch das Werkzeug nachweisbar sein. Compiler, Coverage-Werkzeug, Testframework und statische Analyse laufen als qualifizierte Kette in der CI, Abweichungen stehen mit Begründung in einem Register. Die Firmware baut auf semf, unserer Softwarearchitektur; die Serienprüfung läuft auf qdTest. Was wir dem Auftraggeber geliefert haben, ist ein Teilsystem, dessen Nachweiskette von der Anforderung bis zum Testfall in seiner Hand liegt.