Safety over EtherCAT, kurz FSoE, ermöglicht den Transport sicherheitsgerichteter Informationen über dasselbe Kommunikationssystem wie normale Prozessdaten. Das spart separate Verdrahtung und unterstützt flexible Roboterzellen. Das Protokoll macht eine Anwendung jedoch nicht automatisch sicher: Risikobeurteilung, geeignete Geräte, korrekte Parameter und Validierung bleiben unverzichtbar.

In diesem Artikel

Was FSoE ist – und was nicht

FSoE ist ein sicherheitsgerichtetes Kommunikationsprotokoll für EtherCAT. Es ist in IEC 61784-3 standardisiert und laut EtherCAT Technology Group für Anwendungen bis SIL 3 geeignet. Sichere Telegramme werden innerhalb der normalen EtherCAT-Kommunikation übertragen. Die darunterliegende Übertragungsstrecke wird dabei nach dem Black-Channel-Prinzip nicht als sicher vorausgesetzt.

FSoE ist keine einzelne Sicherheitsfunktion. Es übermittelt die Daten, mit denen eine Sicherheitssteuerung und ein sicherer Antrieb beispielsweise STO, SS1 oder SLS anfordern und überwachen können. Welche Funktion erforderlich ist, ergibt sich aus der Risikobeurteilung der Maschine.

Wie der Black Channel abgesichert wird

Mechanismus Erkannte Fehlerart Praktische Bedeutung
CRC-Prüfung veränderte oder beschädigte Nutzdaten Telegrammmanipulationen und Übertragungsfehler werden erkannt
laufende Nummer/Sequenz Wiederholung, Verlust oder falsche Reihenfolge veraltete Befehle werden nicht still akzeptiert
eindeutige Verbindungskennung Verwechslung von Sender und Empfänger sichere Zuordnung zwischen Master und Slave
Watchdog-Zeit verspätete oder ausgebliebene Nachricht System wechselt bei Kommunikationsverlust in definierten sicheren Zustand
Zustandsautomat unerwartete Kommunikationszustände Start, Datenaustausch und Fehlerreaktion bleiben kontrolliert

Typische sichere Antriebsfunktionen

  • STO – Safe Torque Off: verhindert drehmomenterzeugende Energie im Antrieb
  • SS1 – Safe Stop 1: kontrolliertes Abbremsen mit anschließendem STO
  • SLS – Safely Limited Speed: überwacht eine festgelegte Geschwindigkeitsgrenze
  • SOS – Safe Operating Stop: hält die Position bei aktiv geregeltem Antrieb
  • SDI – Safe Direction: überwacht eine zulässige Bewegungsrichtung

Die genaue Wirkung hängt von Antrieb und Maschinenkonzept ab. Ein sicher begrenztes Signal ersetzt weder mechanische Grenzen noch die Beurteilung von Nachlaufweg, Werkzeug, Last und möglichem Versagen weiterer Komponenten.

Beispiel einer Roboterzelle

Eine Bedienperson öffnet eine überwachte Schutztür. Der sichere Eingang meldet den Zustand an die Sicherheitssteuerung. Diese fordert über FSoE eine geeignete sichere Antriebsfunktion an. Die sicheren Antriebe bestätigen ihren Zustand; erst danach darf der Prozesszugang gemäß Sicherheitskonzept erfolgen. Beim Schließen reicht das Türsignal allein nicht: Quittierung, freie Gefahrenzone und kontrollierter Wiederanlauf müssen ebenfalls berücksichtigt werden.

Engineering-Fragen vor der Implementierung

  • Welcher Performance Level oder SIL ist aus der Risikobeurteilung erforderlich?
  • Welche Reaktionszeit hat die gesamte Sicherheitskette vom Sensor bis zum Antrieb?
  • Welche FSoE-Master- und Slave-Geräte sind für die Zielarchitektur geeignet und zertifiziert?
  • Wie werden Verbindungskennungen, Watchdogs und sichere Parameter verwaltet?
  • Welche sichere Reaktion folgt auf Leitungsbruch, Gerätetausch oder Neustart?
  • Wie werden Änderungen versioniert, geprüft und gegen unbefugten Zugriff geschützt?

Reaktionszeit ist eine Systemeigenschaft

Für Schutzabstände zählt nicht nur die Buszykluszeit. Sensorreaktion, sichere Logik, Kommunikations-Watchdog, Antriebsreaktion und mechanischer Nachlauf addieren sich. Konservative Grenzwerte müssen dokumentiert und am realen System verifiziert werden. Eine schnelle Standardkommunikation garantiert keine ausreichend kurze sichere Gesamtreaktion.

Inbetriebnahme und Validierung

Prüfung Testidee Nachweis
Zuordnung Verbindung oder Gerät gezielt falsch konfigurieren Fehler wird erkannt und sicherer Zustand erreicht
Kommunikationsverlust Leitung oder Teilnehmer kontrolliert unterbrechen Watchdog-Reaktion entspricht Spezifikation
Sicherheitsfunktion STO, SS1 oder SLS unter Grenzbedingungen auslösen Reaktionszeit und Endzustand gemessen
Wiederanlauf Spannungs- und Kommunikationsrückkehr simulieren kein unerwarteter automatischer Start
Änderungsmanagement Gerätetausch oder Parameteränderung durchführen Autorisierung, Version und erneute Prüfung nachvollziehbar

Häufige Missverständnisse

  • Ein FSoE-zertifiziertes Gerät zertifiziert nicht die gesamte Maschine.
  • Standard- und Safety-Daten auf einem Kabel bedeuten nicht, dass Standardkomponenten sicherheitsgerichtet werden.
  • Funktionale Sicherheit und Cybersecurity sind verschieden, müssen bei vernetzten Anlagen aber gemeinsam gestaltet werden.
  • Eine erfolgreiche Kommunikation beweist noch nicht die richtige Sicherheitsfunktion oder den ausreichenden Schutzabstand.

Häufige Fragen

Braucht FSoE ein separates Safety-Kabel?

Nein. Sichere Telegramme können über die normale EtherCAT-Infrastruktur transportiert werden. Die Sicherheitsintegrität entsteht durch das Protokoll und die sicheren Endgeräte.

Ist FSoE bis SIL 3 geeignet?

Die EtherCAT Technology Group beschreibt FSoE als für Anwendungen bis SIL 3 geeignet. Ob eine konkrete Maschine das Ziel erreicht, hängt von der gesamten Sicherheitsfunktion ab.

Was passiert bei Kommunikationsausfall?

Der konfigurierte Watchdog und die sichere Logik müssen innerhalb der festgelegten Zeit einen definierten sicheren Zustand auslösen.

Wer darf FSoE-Parameter ändern?

Nur autorisierte, fachkundige Personen im geregelten Änderungsprozess. Nach sicherheitsrelevanten Änderungen ist eine angemessene Revalidierung erforderlich.

Quellen

Bewerte den Beitrag hier!
[Total: 1 Average: 5]
Nico Nuss [Bildinhalt mit KI erstellt]
Website

Autor Nico Nuss beschäftigt sich seit 2001 mit Mobile Computing und Automatisierungssoftware. Seine langjährige Erfahrung und sein ausgeprägtes Interesse an Zukunftstechnologien bilden die Grundlage seiner Arbeit zu Robotik und künstlicher Intelligenz.

Passend zum Thema