Software übernimmt heute zunehmend Aufgaben, die bislang von dedizierter Hardware mit eingebetteter Software ausgeführt wurden. Hersteller sowie Betreiber von Maschinen und Anlagen können durch Abstraktion, sprich Virtualisierung der Steuerungstechnik ganz erhebliche Einsparungen erzielen: Anschaffung, Inbetriebnahme, Erweiterung, Wartung bis hin zur Außerbetriebnahme können kostengünstiger und einfacher im Handling umgesetzt werden. Software-Container oder alternativ Hypervisor-Systeme als Schlüsseltechnologien abstrahieren und vereinheitlichen die unterliegende Hardware. Durch Segmentierung und dynamische Microservices werden in der IT wichtige Systemeigenschaften wie Security-by-Design realisiert. Diese Eigenschaften lassen sich mit virtuellen Steuerungen jetzt auch in der Automatisierungstechnik nutzen, etwa um Steuerungen flexibel aufsetzen, aktualisieren und verwalten zu können. Aber wie sieht es mit funktional sicheren Anwendungen aus?
Softwaresysteme statt Hardwarekanäle?
Maschinen mit Gefärdungspotenzial aller Art müssen zum Schutz des Menschen gemäß Verordnungen und Gesetzen für den gesamten Lebenszyklus abgesichert und von akkreditierten Instituten abgenommen werden – inklusive eingesetzter Hardware und Software. Neben konstruktiven Maßnahmen können zertifizierte Komponenten und spezielle Sicherheitssteuerungen zur Einhaltung der Anforderungen genutzt werden. Die Anforderungen selbst sind gemäß Stand der Technik u.a. in der IEC61508 beschrieben. Anhand von Risikobetrachtungen ermittelt der Hersteller dazu die in dieser Norm beschriebenen Sicherheitsanforderungsstufen ‚SIL‘ (Safety Integrity Level) 1 bis 4. Ab SIL3 müssen Sicherheitssteuerungen zum Schutz vor Systemfehlern zwingend über zwei unabhängige Abarbeitungskanäle verfügen – bislang immer Hardwarekanäle mit aufwendiger Zertifizierung. 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 über Coded Processing
Bei abstrahierter Hardware muss die Zweikanaligkeit per Software erreicht werden. Ein Verfahren dafür, das sogenannte ‚Coded Processing‘ gibt es bereits seit mehr als 30 Jahren. Dazu wird die sichere SPS-Applikation über eine spezielle Datentransformation mit dem sogenannten ‚Diversified Encoding‘ in zwei Kanäle aufgeteilt, die unabhängig voneinander abgearbeitet werden. Fehler im Daten- und Kontrollfluss von Programmen lassen sich durch eine redundante Betrachtung der Steuerungsinformationen erkennen. Dabei wird die originale Sicherheitsapplikation auf dem ersten Kanal ausgeführt, die mit den Algorithmen des Coded Processing transformierte Applikation im zweiten Kanal. So lassen sich bereits potenzielle Fehler erkennen. Beide Kanäle laufen sequenziell in einem Container. Sie werden permanent verglichen, wie das auch bei Hardwaresystemen zur funktionalen Sicherheit der Fall ist. Auch die sicheren Eingaben werden durch Diversified Encoding an beide Kanäle verteilt. Die Ausgaben beider Kanäle werden wiederum zu sicheren Ausgaben zusammengeführt. Eingeschlossen sind Datenströme, die durch sichere Netzwerk- bzw. Feldbusprotokolle erzeugt wurden. Ein weiteres Sicherheitskriterium ist die zur Laufzeit der Sicherheitsapplikation durchgeführte feingranulare Überwachung des Kontrollflusses im kodierten Kanal. Der TÜV Süd bestätigt: Mit diesem Konzept lässt sich das gleiche Sicherheitsniveau erreichen wie durch zweikanalige Hardware.
Technische Voraussetzungen zunehmend erfüllt
Erste Produkte mit Coded Processing haben sich Anfang der 2000er-Jahre nicht auf breiter Front durchgesetzt. Die rechenintensiven Algorithmen bei gleichzeitig langsameren CPUs machten damals einen vernünftigen Einsatz praktisch unmöglich. Heute sind die Prozessoren um ein Vielfaches leistungsfähiger und die optimierten Software-Algorithmen hinter dem Coded Processing erheblich schneller. Transformierter Applikationscode zusammen mit den erforderlichen Diagnosefunktionen ist mittlerweile nur noch um den Faktor 5 bis 15 langsamer als der originale Code. Gleichzeitig entfallen die bei diskreten Sicherheitssteuerungen erforderlichen Synchronisationspunkte sowie CPU- und Speichertests. Das sorgt für eine erhebliche Entlastung des Prozessors. Somit ist die Nutzung von softwarebasierten Safety-Systemen in Industrieapplikationen nun tatsächlich möglich.
Virtuelle Sicherheitssteuerung von Codesys
Die virtuelle Steuerung Codesys Virtual Control SL kann bei ausreichender Leistungsfähigkeit der darunter liegenden Hardware nahezu beliebig oft instanziiert und parallel betrieben werden.Damit ist ein neues Maß an Flexibilität gegeben. Zum Erreichen der Zweikanaligkeit nutzt die Software Coded Processing von SIL-istra Systems. Damit können die funktionale und die sichere virtuelle Steuerung hardwareunabhängig im Container laufen. Ob es sich dabei um Industriehardware im Schaltschrank, IT-Hardware im Serverraum oder Edge-Geräte irgendwo dazwischen handelt, spielt dafür keine Rolle. Der E/A-Zugriff erfolgt über physikalische oder per VLAN virtualisierte Ethernet-Ports in Echtzeit. Das gilt in gleicher Weise für Industrial-Ethernet-Protokolle mit Zulassung für sicherheitskritische Anwendungen, wie Profisafe (F-Host/F-Client) oder zukünftig FSoE (Fail Safe over EtherCAT).
Sicherheit als Container
Bei der Anwendung deployen bzw. orchestrieren Codesys-User ihre Steuerung auf der verfügbaren Hardware und entscheiden dabei, ob sichere Applikationen ablaufen sollen. Ist dies der Fall, so wird beim Deployment der virtuellen Steuerung ein zusätzlicher Container angelegt und so konfiguriert, dass er abhängig von einer funktionalen Steuerung ist. Wie beschrieben, wird die Applikation im Safety-Container dabei zusätzlich per Coded Processing abgearbeitet – das geschieht automatisch im Hintergrund. Die codierte und die originale Applikation überwachen sich im Betrieb gegenseitig und nehmen bei erkannten Fehlern sofort den sicheren Zustand ein. Die Programmierung funktionaler und sicherer Applikationen erfolgt im Codesys Development System. Für die sichere Applikation steht dazu ein zertifiziertes Add-on-Modul mit einem sicheren IEC61131-3-Editor zur Verfügung, das den rein funktionalen Teil erweitert. Mit einem vom TÜV Süd abgenommenen Verfahren wird der erzeugte Code auf die virtuelle Sicherheitssteuerung heruntergeladen. Prinzipbedingt ist die Projektierung einer Safety-Applikation aufwendiger als der rein funktionale Teil – diesbezüglich unterscheiden sich physikalische und virtuelle Safety-Steuerungen nicht. Bei Installation, Wartung und Updates kann die virtuelle Sicherheitssteuerung dann ihre Vorteile ausspielen.
Abnahme nach IEC61508 SIL3 ist möglich
Die Orchestrierung und Konfiguration von funktionaler und sicherer Steuerung erfolgt in beiden Varianten auf ähnliche Weise, und zwar in einem weiteren Add-on des Codesys Development Systems. Unterschiede gibt es lediglich bei den Lizenzkosten. Und natürlich erfordert eine Sicherheitsapplikation auch eine Abnahme bei einem akkreditierten Institut. Dafür bereiten sich Hersteller von Maschinen oder Anlagen mit virtualisierter Safety-SPS genauso vor wie mit dedizierten Geräten – nur jetzt ohne zertifizierte Safety-Hardware. Die spannende Frage von Skeptikern: Ist die Abnahme nach IEC61508 SIL3 überhaupt möglich? Antwort: Ja, der TÜV Süd hat im Januar die Zertifizierung für die Basissoftware von Codesys Virtual Safe Control SL erteilt. Die Sicherheitsabnahme für Maschinen und Anlagen kann jetzt also tatsächlich geräteunabhängig erfolgen. In der ersten Version ist dies für Hardware-Plattformen auf Basis von x86-CPUs mit Profinet/ProfiSafe als Feldbus möglich. Eine Erweiterung auf ARM-basierte Rechnerarchitekturen sowie FSoE (EtherCAT Safety) ist für die nächsten Monate geplant. Somit bietet Codesys Virtual Safe Control SL Herstellern und vor allem Betreibern von Maschinen und Anlagen zusätzliche Freiheit – jetzt sogar für sicherheitskritische Anwendungen. Der erste Einsatz der Software ist in KFZ-Produktionslinien der Audi AG vorgesehen.
