Anzeige

Virtuelle Steuerungen ermöglichen funktionale oder sicherheitsgerichtete Anwendungen

Zweikanaligkeit per Software

Virtuelle Steuerung

Mit der konsequenten Abstraktion der Steuerungstechnik können Maschinen- und Anlagenbauer sowie Betreiber solcher Systeme ganz erhebliche Einsparungen erzielen: Von der Anschaffung über Inbetriebnahme, Erweiterung, Wartung bis hin zur Außerbetriebnahme. 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? 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. Das kann durch konstruktive Maßnahmen erfolgen. Aber auch sichere Steuerungstechnik kann dies leisten, wenn sie dem Stand der Technik nach IEC 61508 in allen Grundbegriffen, Gestaltungsleitsätzen und allgemeinen Aspekten für den Einsatz von elektronischen Steuerungen in Maschinen und Anlagen entspricht. Diese Norm beschreibt auch Sicherheitsanforderungsstufen Safety Integrity Level - „SIL“ 1 bis 4, ausgehend von der Gefährdungslage in der Schwere und Expositionshäufigkeit. Die Gesetzeslage verpflichtet Hersteller jeder Maschine oder Anlage mit Gefährdungspotenzial zu einer Freigabe durch ein akkreditiertes Institut. Hier sind auch alle eingesetzten Komponenten für die Erreichung der Anforderungsstufe sowie der implementierten Steuerungsapplikation inkludiert.

Die Mehrkanaligkeit von eingesetzten Steuerungen zum Schutz vor Systemfehlern ist bereits ab SIL2 zwingend vorgeschrieben. Für SIL3, der in der Industrie in vielen Applikationen gefordert wird, muss zumindest eine Instanz die korrekte Abarbeitung der Sicherheitsfunktion überwachen. Für diesen Anwendungsfall haben CPU-Hersteller spezielle Prozessoren mit unterschiedlichen Architekturen entwickelt. Das sind beispielsweise Lock-Step-CPU oder „Safety-Island“ als Überwachungsschicht. Sie realisieren die Zweikanaligkeit direkt im Silizium und reduzieren damit den Hardware-Aufwand. Gleichzeitig wird die Abhängigkeit von bestimmten Bauelementen massiv erhöht. Gerade in der bestehenden Situation mit gestörten Lieferketten und Bauteilemangel kann solch eine Abhängigkeit zu ernsthaften Problemen führen. Prozessoren können für die erforderliche Zertifizierung nicht ohne weiteres ersetzt werden. Setzt man virtuelle Steuerungen ein, so entfällt aufgrund der Hardware-Abstraktion die Möglichkeit, sich zum Erreichen der Zweikanaligkeit auf weitere Hardware abzustützen.

Safety Projekt Online

Diversified Encoding erzeugt Zweikanaligkeit per Software

Stattdessen lässt sich mit dem sogenannten „Diversified Encoding“ eine Zweikanaligkeit per Software erzeugen. Die Technologie basiert auf dem „Coded Processing“. Durch eine redundante Betrachtung der Steuerungsinformationen kann dieses Verfahren Fehler im Daten- und Kontrollfluss von Programmen erkennen. Es teilt die Abarbeitung der Applikationssoftware in zwei logische Softwarekanäle auf, ohne besondere Anforderungen an die darunterliegende Hardware. Der erste Kanal führt die realisierte Sicherheitsapplikation im Original aus. Der zweite Kanal nutzt dieselbe Applikation. Er 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 aufgetretene 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- bzw. Feldbusprotokolle erzeugt wurden. Ein weiteres Sicherheitskriterium ist eine zur Laufzeit der Sicherheitsapplikation durchgeführte zusätzliche feingranulare Überwachung des Kontrollflusses im kodierten Kanal. Das derart gestaltete Sicherheitskonzept von Silistra Systems wurde vom Tüv Süd abgenommen, erste Produktzertifizierungen bis hin zu SIL3 sind erfolgt.

Silistra Safety-Transformer

Coded Processing Verfahren seit 30 Jahre im Einsatz

Die ersten Produkte mit Coded Processing wurden zwar bereits Anfang der 2000er Jahre freigegeben, haben sich allerdings nicht auf breiter Front durchgesetzt. Mit einer bis zu tausendfachen Laufzeitverlängerung aufgrund der rechenintensiven Algorithmen, ausgeführt auf den damals aktuellen CPUs, war so erzeugter Code für reale Anwendungen schlicht unbrauchbar. Mittlerweile sind nicht nur die Prozessoren erheblich leistungsfähiger. Auch die Software-Algorithmen hinter dem Coded Processing wurden grundlegend optimiert. Der per Coded Processing erzeugte Applikationscode zusammen mit den erforderlichen Diagnosefunktionen ist mittlerweile nur noch um den Faktor fünf bis 15 langsamer als der rein funktionale Code. Gleichzeitig entfallen die bei diskreten Sicherheitssteuerungen erforderlichen Synchronisationspunkte sowie CPU- und Speichertests, die für eine nicht unerhebliche Entlastung der CPU sorgen. Angesichts der Leistung moderner Prozessoren steht der Nutzung von Soft-Safety-Lösungen in Industrieapplikationen nun nichts mehr im Weg.

Virtuelle Steuerungen kombiniert mit Coded Processing

Anstatt wie bisher die Zweikanaligkeit durch redundante Hardware zu erzeugen, bieten sich jetzt die Möglichkeiten der Virtualisierung an: Beide Kanäle laufen nicht mehr parallel auf getrennten physischen Systemen, sondern sequenziell in einer virtualisierten Maschine, zum Beispiel im Container oder Hypervisor. 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, ohne an eine dedizierte Hardware gebunden zu sein. Er kann sogar funktional sichere Steuerungen beliebig oft oder feingranular aufsetzen und auf Plattformen wie Industrie-Hardware im Schaltschrank oder IT-Hardware im Serverraum abarbeiten lassen.

Deployed-Tool Konfiguration

E/As lassen sich über virtualisierte Lan-Ports in Echtzeit ansprechen. Das gilt in gleicher Weise für Industrial-Ethernet-Protokolle mit Zulassung für sicherheitskritische Anwendungen, wie beispielsweise Fail Safe over Ethercat oder Profisafe. Codesys-Anwender deployen bzw. orchestrieren ihre Steuerung auf der verfügbaren Hardware. Sollen funktional sichere Applikationen ablaufen, 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. Die codierte und die originale Applikation überwachen sich im Betrieb gegenseitig und nehmen bei erkannten Fehlern sofort den sicheren Zustand ein. 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 abgenommenen 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.

 

 

Effiziente Orchestrierung ohne hardwareseitige Einschränkungen

Ob virtuelle Steuerung für funktionale oder sicherheitsgerichtete Anwendungen, die Orchestrierung ist für beide Varianten identisch. Unterschiede gibt es nur bei den Lizenzkosten. Für die Sicherheitsabnahme bereitet sich der Hersteller einer Maschine oder Anlage mit einer virtualisierten Safety-SPS genauso vor, wie er es mit dedizierten Geräten getan hätte. Mit dem patentierten Verfahren von Silistra Systems in der virtuellen Sicherheitssteuerung „Codesys Virtual Safe Control SL“ erfolgt die Abnahme des Gesamtsystems nach Maschinenrichtlinie wie gewohnt, wobei jetzt keine zertifizierte Safety-Hardware mehr erforderlich ist. Die Abstraktion der Sicherheitssteuerung ist damit der konsequente nächste Schritt. Auch Gerätehersteller profitieren von der neuen Abstraktionsmöglichkeit: Durch die Integration der Technologie können sie nun Sicherheitssteuerungen ohne zweikanaligen Hardware-Aufbau realisieren. Um eine Safety-SPS zu implementieren, müssen Gerätehersteller eine geeignete Rechnerarchitektur mit industriellen Eigenschaften sowie die Hardware-Abstraktion mittels Container und optional darunterliegendem Hypervisor bereitstellen. Die damit verbundenen 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 Freiheitsgrade auch für sicherheitskritische Anwendungen. Die Freigabe der virtuellen Sicherheitssteuerung erfolgt im Sommer 2024.

Mehr über virtuelle Steuerungen für funktionale oder sicherheitsgerichtete Anwendungen erfahren Sie hier.
 

Stichwörter
Codesys