Hardware-Realisierung einer dezentralen Safety-Slave-Antriebslösung: Der Datenengpass entsteht in der Regel bei der Übertragung von Prozess-, Sicherheits- und Servicedaten auf die Applikations-CPU und Weiterleitung auf die Safety-Controller.

© LTi Drives

Da im Sinne der Maschinenrichtlinie die Gefahr von den beweglichen Teilen einer Maschine ausgeht, scheint es nahe liegend, an der Stelle für die Sicherheit der Personen zu sorgen, von der die gefahrbringende Bewegung ausgeht - und zwar im Antriebsregler selbst. Selten werden allerdings einzelne Antriebsregler für sich alleine verbaut. Vielmehr ist es die Vernetzung von Antriebsreglern, die die eigentliche Bewegung der Maschine bestimmt. Der hierbei notwendige Datenaustausch spricht demnach für einen zentralen Lösungsansatz. Um aber Safe-Motion-Lösungen zentral zu realisieren, müssen antriebsnahe, sichere Informationen entweder direkt in der übergeordneten Sicherheitssteuerung ausgewertet oder im Antrieb sicher erfasst und über Sicherheitsprotokolle zur Steuerung übertragen werden.

Bei der direkten Auswertung bedeutet das für den Maschinenhersteller, dass er sich mit zusätzlichen externen Komponenten wie Sicherheitssteuerung, Sicherheits-Feldbus- Protokoll sowie der Auswertung zusätzlicher Sensorik befassen muss. Gerade die zentrale Erfassung und Auswertung der Sensorik - insbesondere die Auswertung von Gebern und Analoginformationen - stellen hohe Anforderungen an die Performance der Sicherheitssteuerung. Nicht zu vernachlässigen sind massive Kostensteigerungen durch die zusätzlich notwendige Hardware, den erhöhten Verdrahtungsaufwand sowie die Programmierung und Inbetriebnahme weiterer Komponenten.

All das steht im Widerspruch zu Kosteneffizienz und Reduktion der Inbetriebnahmezeiten und entfällt somit als Alternative. Bleibt bei dem zentralen Ansatz also nur die Überlegung, die antriebsnahen Daten im Antrieb sicher zu erfassen und über ein Sicherheitsprotokoll an die übergeordnete Steuerung zu übertragen. Für diese Zwecke bieten viele auf Ethernet basierende Echtzeit-Kommunikationslösungen bereits zertifizierte Sicherheitslayer an. So zum Beispiel das von der Ethercat Technology Group spezifizierte Safety-over-Ethercat oder das von Sercos International favorisierte CIPSafety-Protokoll.

Bei beiden Protokollen werden die sicherheitsrelevanten Daten in Form eines Containers in den Echtzeit-Gerätekanal der Standard-Kommunikationsschicht eingebettet. Sichere Kommunikation ist dabei zwischen allen Netzwerkebenen möglich, selbst bei direkter Querkommunikation und netzwerkübergreifender Kommunikation. Der Master muss dabei nicht zwangsläufig eine Sicherheitssteuerung sein, sondern kann die Daten auch routen, ohne sie selbst zu interpretieren.

Engpass synchrone Datenübernahme

Den sich daraus ergebenden Vorteilen bei der Umsetzung eines durchgängigen Maschinenkonzeptes stehen jedoch auch Nachteile gegenüber: So ist etwa das notwendige Datenaufkommen allein für die Sicherheitsdaten außerordentlich hoch. Für Safety-over-Ethercat ist beispielsweise pro 2 Byte Sicherheitsdaten eine 2-Byte-Prüfsumme im Telegramm zu hinterlegen. Im CIP-Safety-Protokoll werden die Daten redundant übertragen, zuzüglich der notwendigen Safety-Telegramm-Header. Die Nettodatenrate für die sicherheitsrelevanten Daten liegt damit zwangsläufig unter 50 %. Zu den Safety-Daten hinzu kommen die bisherigen Prozess- und Servicedaten.

Was dies im Detail bedeutet, lässt sich am Beispiel einer sicheren Achsbewegung erläutern: Bei der Realisierung von sicheren Bewegungslösungen ergeben sich für ein antriebstechnisches Slave-Device jeweils Datenmengen von etwa 44 Bytes je Master-Daten-Telegramm (MDT - Telegramm vom Master zur Steuerung) und Antriebs-Telegramm (AT - Telegramm vom Antrieb zum Master).

Automatisierungslösung mit integrierter Safety-SPS und zusätzlicher externer Safety-SPS – auf diese Weise lassen sich beliebige, weitere E/AModule in die antriebsintegrierte Saftey-Lösung einbinden.

© LTi Drives

Diese setzen sich zusammen aus den Standardprozessdaten (14 Bytes) zuzüglich der gleichen Anzahl sicherheitsrelevanter Daten, die wegen der Redundanz beziehungsweise der Prüfsummen mit dem Faktor 2 in die Berechnung eingehen (28 Bytes), und nicht zuletzt aus dem Telegramm-Overhead im Safetydaten- Container (2 Bytes). Hinzu kommen die asynchronen Servicedaten, die in der weiteren Betrachtung allerdings außer Acht gelassen werden, für eine reibungslose Bedienung jedoch eine gewisse Bandbreite voraussetzen. Die größte Herausforderung bei der Entwicklung der Sicherheitslayer besteht darin, die Eigenschaften und die Flexibilität des darunter liegenden Kommunikationssystems nicht einzuschränken.

Der zu erwartende Engpass ist daher nicht unbedingt die Übertragung des Telegramms selbst, da mit 100 Mbit/s selbst bei dynamischen Prozessen mit Zykluszeiten von 125 μs noch hinreichend Bandbreite für die gängigsten Anwendungen - etwa eine Werkzeugmaschine mit bis zu sechs Achsen - zur Verfügung stehen sollte. Der Engpass ist vielmehr die synchrone Datenübernahme über den Feldbus-Slave-Controller auf die eigentlichen Applikations- und Safety-Controller (CPU) der Antriebsgeräte. Die damit verbundenen Zugriffszeiten, die beispielsweise an einem Parallelbus auf der Slave-Hardware verlorengehen, um die Datenmengen überhaupt übertragen zu können, beeinflussen zwangsläufig die Gesamtperformance des Systems. Messungen mit realer Hardware haben ergeben, dass für eine erforderliche Prozessdatenmenge von etwa 100 Bytes, mit denen bei einer typischen Bewegungslösung zu rechnen ist, die Zeiten für den rein physikalischen Datentransfer von und zum Feldbus-Slave-Controller im Idealfall im zweistelligen μs-Bereich liegen.

Abhängig von der eingesetzten Embedded-CPU und den angestrebten Lageregler-Zykluszeiten (beispielsweise 125 μs) kann allein der Netto-Datentransfer einen unverhältnismäßig großen Teil der Prozessorperformance beanspruchen. Zwar gibt es hier noch Optimierungspotenzial, am Kern des Problems ändert sich jedoch nichts: Einerseits müssen die für Antriebsgeräte verhältnismäßig großen Datenmengen bewältigt werden, andererseits stehen die Antriebsgeräte selbst unter massivem Kostendruck, so dass nicht alle technisch möglichen Konzepte zum Einsatz kommen können.

Anschließend müssen die Safety-Daten von der Applikations-CPU an die Safety-CPUs weitergereicht werden. Auch sind hier je nach verwendeter Schnittstelle (zum Beispiel SPI oder UART) zusätzliche Zeiten für den Datentransfer zu berücksichtigen, welche die Reaktionszeiten der Safety-Applikation weiter erhöhen.

Welche Daten wie auswerten?

Damit nicht genug: Neben dem Datentransfer sind Überlegungen anzustellen, welche Safety-Daten überhaupt zur Übertragung vorgesehen und wie diese in der überlagerten Sicherheitssteuerung auszuwerten sind - etwa die bereits sicher im Antrieb berechneten Positionen und Drehzahlen oder allein die Rohdaten der Drehgeber-Auswertung. Safety-over-Ethercat oder auch CIP-Safety beschreiben lediglich den Aufbau der Sicherheitslayer, nicht jedoch deren Inhalt. Sicherheits-SPS und Antrieb müssen daher bezüglich des Inhalts aufeinander abgestimmt sein. Safety-Antriebsprofile befinden sich zwar in der Diskussion, stehen aktuell jedoch noch nicht zur Verfügung.

Für Maschinenhersteller, die auf andere Feldbus-Anschaltungen oder gar auf Eigenentwicklungen setzen, hat das zur Folge, dass Erweiterungen oder Neuentwicklungen ihrer Steuerungen notwendig werden, um die zusätzlichen sicherheitsrelevanten Informationen im Protokoll handhaben zu können. Neben Safety-over-Ethercat oder CIP-Safety gibt es eine Vielzahl weiterer Sicherheitslayer, die jedoch im Wesentlichen ähnlich arbeiten. Bis hier lässt sich also festhalten: Diese zentralen Konzepte werden in Zukunft unbestritten an Bedeutung gewinnen. Es bleibt jedoch abzuwarten, wie viel dezentrale Intelligenz dazu im Antrieb verbleiben muss, um geeignete Reaktionszeiten mit angemessener Wirtschaftlichkeit zu erreichen.

Auch wird der Erfolg davon bestimmt sein, wie schnell eine Zertifizierung von Safety-Antriebsprofilen zu erreichen ist und wie gut die Steuerungs- und Antriebshersteller ihrerseits die großen Datenmengen in den Griff bekommen. Derzeit im Markt befindliche, zentrale Safety- Anschaltungen beschränken sich in der jetzigen Phase fast ausschließlich auf den Austausch sicherer E/AInformationen.

Der hybride Ansatz

Aus den geschilderten Überlegungen leitet sich aktuell also nur ein Lösungsansatz ab - und zwar die antriebsnahe, dezentrale Sensor-Erfassung und -Auswertung mit der Möglichkeit einer zentralen, achsübergreifenden Koordination. Mit anderen Worten: den zentralen und dezentralen Ansatz miteinander zu kombinieren und die Safety-Steuerung direkt in den Antrieb zu integrieren.