Warum wird das 30 Jahre alte Verfahren erst jetzt genutzt?
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 1000-fachen Laufzeitverlängerung aufgrund der rechen intensiven Algorithmen ausgeführt auf den damals aktuellen CPU 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 5 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 Performance moderner Prozessoren steht der Nutzung von Soft-Safety-Lösungen in Industrieapplikationen nun nichts mehr im Weg.
Coded Processing kombiniert mit virtuellen Steuerungen – ein großer Nutzen für Anwender Anstatt wie bisher die Zweikanaligkeit durch redundante Hardware zu erzeugen, bieten sich jetzt die Möglichkeiten der Virtualisierung an: Beide Kanäle laufen jetzt nicht mehr parallel auf getrennten physischen Systemen, sondern sequenziell in einer virtualisierten Maschine, beispielsweise 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 – jetzt aber mit dem Vorteil, dass er nicht mehr an eine dedizierte Hardware gebunden ist. Er kann sogar funktional sichere Steuerungen beliebig oft oder feingranular aufsetzen und auf den Plattformen abarbeiten lassen, die ihm zur Verfügung stehen sei es Industriehardware im Schaltschrank oder IT-Hardware im Serverraum. E/A lassen sich über virtualisierte LANPorts in Echtzeit ansprechen. Das gilt in gleicher Weise für Industrial-Ethernet-Protokolle mit Zulassung für sicherheitskritische Anwendungen, wie FSoE (Fail Safe over Ethercat) oder Profisafe (F-Host/F-Client).
Codesys-Anwender [2] deployen beziehungsweise orchestrieren ihre Steuerung auf der verfügbaren Hardware und entscheiden dabei, ob funktional sichere Applikationen ablaufen sollen. Ist das der Fall, so 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 funktionaler und sicherer Applikationen verwendet der Anwender das Codesys Development System (Bild 2). Die sichere Applikation projektiert er mit dem zertifizierten Add-on-Modul, das den rein funktionalen Teil erweitert. Im sicheren IEC61131-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 (Bild 3). 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.
Ob virtuelle Steuerung für funktionale oder Sicherheitsapplikationen – die Orchestrierung ist für beide Varianten identisch. Unterschiede gibt es nur noch bei den Lizenzkosten. 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 patentierten Verfahren von Silistra Systems in der virtuellen Sicherheitssteuerung „Codesys Virtual Safe Control SL“ erfolgt eine Freigabe des Gesamtsystems nach der Maschinenrichtlinie wie immer, wobei dafür jetzt keine zertifizierte Safety Hardware mehr erforderlich ist. Die Abstraktion der Sicherheitssteuerung ist somit der konsequente nächste Schritt.
Auch Gerätehersteller profitieren von der neuen Abstraktionsmöglichkeit. Denn 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 eine geeignete Rechnerarchitektur mit industriellen Eigenschaften sowie die Hardware-Abstraktion per Container und optional darunter liegendem Hypervisor bereitstellen. Die soerzielten Aufwandsund Kosteneinsparungen kommen allen zugute. Natürlich werden solche virtualisierten Steuerungen nicht alle bisherigen Steuerungsarchitekturen ersetzen. Aber Codesys Virtual Control SL bietet Maschinen- und Anlagenbauern sowie vor allem den Betreibern solcher Systeme zusätzliche Freiheit – auch für sicherheitskritische Anwendungen.
Literatur
- Wagner, Roland: Der Weg zur Industriesteuerung 5.0. open automation 24 (2022), H. 6, S. 44
- Codesys GmbH, Kempten: de.codesys.com