Sicherheitssteuerungen – hardwareunabhängig und virtuell

Zum Schutz des Menschen schreiben Verordnungen und Gesetze vor, dass Maschinen mit Gefährdungspotenzial aller Art für den gesamten Lebenszyklus abgesichert sein müssen. Das kann durch konstruktive Maßnahmen, zertifizierte Komponenten oder spezielle Sicherheitssteuerungen erfolgen. Letztere müssen zum Schutz vor Systemfehlern ab einer bestimmten Gefährdungsklasse zwingend über zwei unabhängige Abarbeitungskanäle verfügen – gemäß dem Stand der Technik, wie er unter anderem in der IEC 61508 (DIN EN 61508, VDE 0803) definiert ist [1]. Die in dieser Norm beschriebenen Sicherheitsanforderungsstufen (SIL, Safety Integrity Level) 1 bis 4 werden anhand von Risikobetrachtungen ermittelt. Aufgrund der Gesetzeslage sind alle Hersteller von Maschinen oder Anlagen mit Gefährdungspotenzial verpflichtet, ihre Systeme von akkreditierten Instituten freigeben zu lassen – inklusive eingesetzter Komponenten sowie der implementierten Steuerungsapplikation. Bislang waren immer zwei unabhängige Abarbeitungskanäle in Hardware ausgeführt. Und nur spezielle zweikanalige Hardwaresysteme konnten als zertifizierte Komponenten eingesetzt werden. Was aber, wenn man die Hardware abstrahiert? Für viele war es bislang undenkbar, reine Softwaresysteme hardwareunabhängig zu zertifizieren. Gibt es dennoch einen Weg dahin?

Zweikanaligkeit per Software: Diversified Encoding

Abstrahiert man die Hardware, so muss man die Zweikanaligkeit per Software erreichen. Entsprechende Verfahren gibt es bereits seit mehr als 30 Jahren, bekannt als Coded Processing (Bild 2). Die Idee ist, die Abarbeitung der sicheren SPS-Applikation über eine spezielle Datentransformation mit dem sogenannten Diversified Encoding in zwei Kanäle aufzuteilen und unabhängig voneinander abzuarbeiten. Durch eine redundante Betrachtung der Steuerungsinformationen lassen sich Fehler im Daten- und Kontrollfluss von Programmen erkennen. Dabei führt der erste Kanal die realisierte Sicherheitsapplikation im Original aus, während der zweite Kanal dieselbe Applikation mit den Algorithmen des Coded Processing ausführt. Damit lassen sich bereits potenzielle Fehler erkennen. Beide Kanäle laufen sequenziell in einem Prozess auf einem CPU-Kern. Sie werden permanent verglichen, wie das auch bei Hardwarelösungen zur funktionalen Sicherheit erfolgt. Durch Diversified Encoding werden die sicheren Eingaben auf dieselbe Weise an beide Kanäle verteilt. Die Ausgaben beider Kanäle werden wiederum zu sicheren Ausgaben zusammengeführt. Eingeschlossen  sind Daten ströme, die durch sichere Netzwerk- beziehungsweise Feldbusprotokolle erzeugt wurden. Ein weiteres Sicherheitskriterium ist die zur Laufzeit der Sicherheitsapplikation durchgeführte feingranulare Überwachung des Kontrollflusses im codierten Kanal. Mit einem derart gestalteten Konzept lässt sich das gleiche Sicherheitsniveau erreichen wie durch zweikanalige Hardware.

Obwohl die ersten Produkte mit Coded Processing bereits Anfang der 2 000er-Jahre erschienen sind, haben sie sich nicht auf breiter Front durchgesetzt. Aufgrund der rechenintensiven Algorithmen war die Laufzeit der Abarbeitung damals bis zu 1 000-mal langsamer. In Kombination mit den zu dieser Zeit aktuellen CPUs waren solche Systeme für reale Anwendungen schlicht unbrauchbar. Mittlerweile sind nicht nur die Prozessoren um ein Vielfaches leistungsfähiger, auch die Software-Algorithmen hinter dem Coded Processing wurden grundlegend optimiert. So ist transformierter Applikationscode zusammen mit den erforderlichen Diagnosefunktionen mittlerweile nur noch um den Faktor 5 bis 15 langsamer als nicht transformierter Code. Gleichzeitig entfallen die bei diskreten Sicherheitssteuerungen erforderlichen Synchronisationspunkte sowie CPU- und Speichertests, was für eine erhebliche Entlastung des Prozessors sorgt. Angesichts der Performance moderner Prozessoren steht der Nutzung von softwarebasierten Safety-Lösungen in Industrieapplikationen nun nichts mehr im Weg.