Inhaltsverzeichnis
1. Sicherheit muss gegeben sein
2. Zweikanaligkeit per Software: Diversified Encoding
3. Konsequenzen der Zweikanaligkeit per Software
4. Anwendernutzen durch virtuelle Safety-Steuerungen
5. Umsetzung virtueller Safety-Steuerungen
6. Abnahme virtueller Safety-Steuerungen
Bei virtuellen Steuerungen auf Basis von Container- oder Hypervisor-Technologien bestimmt ausschließlich die Software die Funktion – die Hardware liefert den abstrahierten Unterbau dafür. So lassen sich moderne Steuerungsarchitekturen mit Security-by-Design und dynamischen Microservices einfach realisieren, weil die Abhängigkeit von bestimmten Geräten aufgebrochen ist. Aber wie sieht es mit funktional sicheren Anwendungen aus?
Sicherheit muss gegeben sein
Zum Schutz des Menschen schreiben EU-Verordnungen und nationale Gesetze vor, dass Maschinen mit Gefährdungspotenzial aller Art für den gesamten Lebenszyklus abgesichert sein müssen: durch konstruktive Maßnahmen oder sichere Steuerungstechnik. Letzteres gemäß dem Stand der Technik, wie er unter anderem in der IEC 61508 definiert ist – entsprechend der Sicherheitsanforderungsstufen SIL 1 bis 4 (Safety Integrity Level), gemäß der Gefährdungslage etwa durch Schwere und Expositionshäufigkeit. Hersteller von Maschinen oder Anlagen mit Gefährdungspotenzial benötigen in jedem Fall eine Freigabe durch ein akkreditiertes Institut.
In der Industrie wird SIL3 in vielen Applikationen gefordert. Zumindest eine Instanz muss dabei die korrekte Abarbeitung der Sicherheitsfunktion überwachen, in der Regel eine Hardware. Für diesen Anwendungsfall gibt es spezielle Prozessoren mit unterschiedlichen Architekturen, die die Zweikanaligkeit direkt im Silizium realisieren (etwa Lock-Step-CPU oder „Safety-Island“). Allerdings erhöht das massiv die Abhängigkeit von bestimmten, vorzertifizierten Bauelementen. Gerade vor dem Hintergrund gestörter Lieferketten und Bauteilemangel kann das sehr problematisch sein.
Zweikanaligkeit per Software: Diversified Encoding
Bei virtuellen und damit abstrahierten Steuerungen wird die Zweikanaligkeit nicht mit weiterer Hardware erreicht, sondern mit dem sogenannten „Diversified Encoding“, basierend auf „Coded Processing“. Die redundante Betrachtung der Steuerungsinformationen in diesem Verfahren ermöglicht die Erkennung von Fehlern im Daten- und Kontrollfluss von Programmen. Dazu wird die Abarbeitung der Applikationssoftware in zwei logische Softwarekanäle aufgeteilt. Der Vorteil dabei: An die darunterliegende Hardware werden keine besonderen Anforderungen gestellt.
Der erste Kanal führt die realisierte Sicherheitsapplikation im Original aus. Der zweite Kanal nutzt dieselbe Applikation, führt sie aber mit den Algorithmen des Coded Processing aus und kann so für sich bereits Fehler erkennen.
Beide Kanäle laufen in einem Prozess sequenziell hintereinander auf einem CPU-Kern. Sie werden permanent verglichen, wie das auch bei den Hardwarelösungen zur funktionalen Sicherheit gemacht wird. Dadurch werden auftretende Fehler deutlich häufiger erkannt.
Durch Diversified Encoding werden auf dieselbe Weise die sicheren Eingaben an beide Kanäle verteilt und umgekehrt die Ausgaben beider Kanäle zu sicheren Ausgaben zusammengeführt. Eingeschlossen sind Datenströme, die durch sichere Netzwerk- beziehungsweise Feldbusprotokolle erzeugt wurden. Eine zur Laufzeit der Sicherheitsapplikation durchgeführte zusätzliche feingranulare Überwachung des Kontrollflusses im kodierten Kanal bringt ein weiteres Sicherheitskriterium. Dieses Konzept der Firma SIListra Systems GmbH wurde vom TÜV SÜD abgenommen, erste Produktzertifizierungen bis hin zu SIL3 sind erfolgt.
Bild: SIListra Systems
Konsequenzen der Zweikanaligkeit per Software
Erste Produkte mit Coded Processing wurden zwar bereits Anfang der 2000er Jahre freigegeben, waren damals jedoch schlicht unbrauchbar: Sie führten auf den damals aktuellen CPUs zu einer Laufzeitverlängerung bis Faktor 1000! Die heute erheblich optimierten Software-Algorithmen zusammen mit den erforderlichen Diagnosefunktionen machen die Abarbeitung der kodierten Applikation zwar immer noch um den Faktor 5 bis 15 langsamer als die rein funktionale. Zusätzlich entfallen aber Synchronisationspunkte sowie CPU- und Speichertests, die bei diskreten Sicherheitssteuerungen erforderlich sind. In Kombination mit erheblich leistungsfähigeren CPUs ist deshalb die Nutzung von Soft-Safety-Lösungen in Industrieapplikationen jetzt möglich.
Anwendernutzen durch virtuelle Safety-Steuerungen
Bei virtuellen Steuerungen laufen beide Kanäle jetzt sequenziell in einer virtualisierten Maschine, zum Beispiel im Container. Einer der beiden Kanäle wird per Coded Processing transformiert und ausgeführt. Über Diversified Encoding werden die Ergebnisse vor und nach der Ausführung verglichen. Damit steht dem Anwender eine gleichwertige Lösung zur Verfügung, wie man sie von physischen Sicherheitssteuerungen kennt – aber eben ohne die Bindung an eine dedizierte Hardware.
Funktional sichere Steuerungen lassen sich sogar beliebig oft aufsetzen und auf verfügbaren Plattformen abarbeiten – Industriehardware im Schaltschrank oder IT-Hardware im Serverraum. Safety-E/As lassen sich zudem über virtualisierte LAN-Ports in Echtzeit ansprechen, wie etwa FSoE (Fail Safe over Ethercat) oder Profisafe (F-Host / F-Client).
Umsetzung virtueller Safety-Steuerungen
Codesys-Anwender entscheiden beim Deployen bzw. Orchestrieren ihrer Steuerung, ob funktional sichere Applikationen ablaufen sollen. Gegebenenfalls legt das Tool beim Deployment der virtuellen Steuerung einen zweiten parallelen Container an. Die Applikation im Safety-Container wird dabei zusätzlich per Coded Processing abgearbeitet und sorgt für die Überwachung der Sicherheit.
Bild: Codesys
Zur Programmierung von funktionaler und sicherer Applikation verwendet der Anwender das Codesys Development System. Die sichere Applikation projektiert er mit dem zertifizierten Add-on-Modul, das den rein funktionalen Teil erweitert. Im sicheren IEC-61131–3-Editor erstellt er den Code und lädt ihn mit abgenommenem Verfahren auf die virtuelle Sicherheitssteuerung. Dass es sich dabei um virtualisierte Geräte handelt, merkt er nur bei der Anbindung der Safety-E/A-Module in der Applikation. 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, Updates und weiteren Aspekten gibt es jedoch beträchtliche Unterschiede. Im Endeffekt unterscheiden sich die funktionale Lösung und die Sicherheitsapplikation aber nur noch bei den Lizenzkosten.
Abnahme virtueller Safety-Steuerungen
Für die Sicherheitsabnahme bereitet sich der Hersteller einer Maschine oder Anlage mit virtualisierter Safety-SPS genauso vor, wie er das mit dedizierten Geräten gemacht hätte. Mit dem Verfahren von SIListra Systems in der virtuellen Sicherheitssteuerung „Codesys Virtual Safe Control SL“ erfolgt eine Freigabe des Gesamtsystems nach der Maschinenrichtlinie beziehungsweise künftig Maschinenverordnung wie bisher – nur jetzt ohne zertifizierte Safety-Hardware.
Bild: Codesys
Die Abstraktion der Sicherheitssteuerung ist somit der konsequente nächste Schritt. Auch Gerätehersteller profitieren von der neuen Abstraktionsmöglichkeit: Durch die Integration der Technologie können sie jetzt Sicherheitssteuerungen ohne zweikanaligen Hardware-Aufbau realisieren. Um eine Safety-SPS zu implementieren, müssen Gerätehersteller nur noch eine geeignete Rechnerarchitektur mit industriellen Eigenschaften sowie die Hardware-Abstraktion per Container bereitstellen. Die so erzielten Aufwands- und Kosteneinsparungen kommen allen zugute.
Natürlich werden solche virtualisierten Steuerungen nicht alle bisherigen Steuerungsarchitekturen ersetzen. Aber Codesys Virtual Control SL bietet Maschinen- und Anlagenbauern und vor allem den Betreibern solcher Systeme zusätzliche Freiheit – jetzt sogar für sicherheitskritische Anwendungen. (co)
Weitere Infos zum Laufzeitsystem Codesys Virtual Control SL
Links zu den beiden ersten Teilen der Serie zu virtuellen Steuerungen:
Hier finden Sie mehr über:
