Herr Kehrer, in Kürze erhält die Codesys Virtual Safe Control SL die Zertifizierung für FSoE (EtherCAT Safety). Welche konkreten Anforderungen müssen dafür erfüllt sein und wie genau wird FSoE in der vSafePLC realisiert?

Die Anforderungen für die FSoE-Zertifizierung sind im Grunde die gleichen wie bei traditionellen sicheren Steuerungen. Im Mai 2025 haben wir mit unserer virtuellen sicheren Steuerung am FSoE Plug Fest bei uns im Haus teilgenommen und auch die offiziellen Konformitätstests der ETG bereits erfolgreich bestanden. Damit sind die Interoperabilität mit anderen Geräten und die Erfüllung sicherheitsrelevanter Normen sichergestellt. Die Freigabe der Version mit FSoE-Master ist für Anfang 2026 geplant.

Aus funktionaler Sicht haben wir ‚Codesys Virtual Safe Control SL‘ schon von Grund auf offen gestaltet und eine Schnittstelle zur Integration weiterer sicherer Protokolle vorgesehen. Diese Schnittstelle erlaubt es uns, weitere Funktionsblöcke dynamisch und flexibel nachzuladen, zum Beispiel zur Bewegungsüberwachung oder für sichere Protokolle wie Profisafe Host und jetzt auch FSoE Master. Perspektivisch planen wir, weitere sichere Protokolle wie ‚CIP Safety‘ oder ‚OPC UA Safety‘ umzusetzen; diese stehen aber noch nicht final auf der Roadmap. 

Wie funktioniert das Zusammenspiel zwischen einer virtuell sicheren Steuerung und physischen EtherCAT-Safety-I/O-Modulen? 

Die virtuell sichere Steuerung stellt zunächst per se keine speziellen Anforderungen an die Hardware; es kann letztlich eine beliebige IPC-Hardware im Markt verwendet werden. Ebenso werden gängige FSoE-I/O-Module unterstützt, die man im CODESYS Development System über ihre Gerätebeschreibungen bekannt macht und konfiguriert.

Zur Übertragung der FSoE-Protokolldaten benötigt man einen EtherCAT-Master, der in CODESYS als Teil der funktionalen IEC-61131-3-Applikation in der Standardsteuerung läuft – in diesem Fall auf der funktionalen virtuellen CODESYS-Steuerung. Sie betreibt den EtherCAT-Master und überträgt die EtherCAT-Daten in Echtzeit über den Bus. Die sicheren EtherCAT/FSoE-Module empfangen die Daten und können diese dann verarbeiten. Für diese sicheren I/O-Module ist es völlig transparent, ob die sichere Steuerung virtualisiert ist oder nicht. 

Welche spezifischen Herausforderungen ergeben sich beim Einsatz von ARM-Architekturen gegenüber x86 bei einer vSafePLC?

Bei der Zertifizierung der Codesys Virtual Safe Control SL konnten alle Fehlermodelle auf dem ANSI-C-Code des Laufzeitsystems abgebildet werden – der Compiler selbst entfällt daher aus der Betrachtung. Das bedeutet: Weil die funktionale virtuelle Steuerung von Anfang an auf ARM-Architekturen läuft, ist die Abnahme der virtuellen Sicherheitssteuerung durch den TÜV Süd aus technischer Sicht schnell möglich. Es bleibt der Aufwand, den formalen Prozess mit allen Nachweisen zu durchlaufen.

Eine große Frage blieb bisher jedoch offen: Ist die Leistung gängiger ARM-basierter Plattformen und SoCs ausreichend, um den rechenintensiven transformierten Code der Virtual Safe Control SL für reale Applikationen auszuführen?

Die kurze Antwort ist: Ja – absolut. Bereits erste Tests zeigten, dass auf einem gängigen ARM-basierten System – wir haben auf einem Raspberry Pi getestet – bis zu 64 Profisafe-Verbindungen innerhalb von 4 Millisekunden betrieben werden können. Dieses Ergebnis belegt, dass ARM-basierte Systeme für den praktischen Einsatz tauglich sind. 

Wie wird im System sichergestellt, dass automatische Updates oder Änderungen am funktionalen Teil der Steuerung nicht die Safety-Applikation oder FSoE-Konfiguration unbeabsichtigt beeinflussen?

Aus sicherheitstechnischer Sicht gibt es keine Bedenken: Sämtliche Daten werden restlos abgesichert verarbeitet, und jedwede Änderung auch nur eines Datums wird direkt im Zyklus erkannt. Die Folge wäre, dass das System sofort in den sicheren Zustand gebracht wird.

Bemerkenswert ist hier aber nicht, dass Fehler erkannt werden, sondern dass automatische Updates mit allen gängigen Tools der IT-Welt möglich sind. Die Codesys Virtual Safe Control SL ist nach innen komplett abgesichert und garantiert mit ihrer diversitären Ausführung der Applikation einen Safety Integrity Level 3 (SIL 3). Nach außen aber verhält sich die virtuell sichere Steuerung wie ein Standard-Workload, der nahezu beliebig mit nicht nach IEC 61508 qualifizierten Tools verwaltet, aktualisiert oder gar orchestriert werden kann. Gerade im Hinblick auf das Ausrollen von Security-Bugfixes birgt das einen unschätzbaren Vorteil.