Herr Dr. Beckmann, was ist Hintergrund der neuen Safety-Initiative?

Dr. Beckmann: In Fabriken findet sich heute üblicherweise eine heterogene Struktur aus Maschinen beziehungsweise Maschinenmodulen, die von unterschiedlichen Herstellern stammen. Diese verwenden nicht notwendig das gleiche Kommunikationssystem und lösen die Sicherheit jeweils intern für sich. Trotzdem müssen sie miteinander interagieren. Somit ergeben sich für die Produktionsanlage als Ganzes übergeordnete Safety-Anforderungen. Mit anderen Worten: Für den sicheren Betrieb sind anlagenweite Not-Aus-Funktionen sowie sicherheitsrelevante Kopplungen der Maschinenteile notwendig.

Für diese Anforderung wollen wir eine Lösung bieten. Und zwar über Gateway-Funktionen, um an geeigneter Stelle – sprich an der Schnitstelle zwischen den Maschinenmodulen – die Verbindung zwischen den Technologien zu schließen. Hierfür erarbeiten wir innerhalb der ETG eine Profilspezifikation, die oberhalb des Safety-Protokolls ein Applikationsprofil definiert.

Warum propagiert die ETG nicht einfach ihr existierendes Safety-Protokoll für Ethercat, welches ja grundsätzlich busunabhängig ist, als übergreifende Safety-Lösung für heterogene Systeme – so wie es die EPSG mit OpenSafety vorgemacht hat?

Dr. Beckmann: Weil wir nicht glauben, dass man durch ein generisches Safety-Protokoll die nativen Safety-Protokolle der etablierten Kommunikations-Technologien ersetzen kann. Das ist technisch schwierig, da die Gerätehersteller für die Implementierung eines Safety-Protokolls Konformitäts-Nachweise und -Tools benötigen. Zudem erhöht es die Kosten jedes einzelnen Sicherheitsgerätes, da dann zwei Safety-Protokolle unterstützt werden müssen. Um es an einem Beispiel zu verdeutlichen: Ein Profinet-Gerät mit Sicherheitsfunktionen wird immer Profisafe sprechen, um es im Profinet-Markt erfolgreich zu platzieren. Ein zusätzliches generisches Protokoll bedeutet für dieses Gerät daher zusätzliche Kosten.

Im Gegensatz zu einem generischen Safety-Protokoll, das in alle Geräte zusätzlich integriert werden muss, ist die Gateway-Funktion nur einmal in einem Maschinenmodul zu realisieren. Dabei muss das Safety-Gateway nicht einmal als eigenständiges Gerät ausgeführt sein, sondern kann beispielsweise auch als Teilfunktion der Sicherheitssteuerung implementiert sein. Die Sicherheitssteuerung überwacht in der Regel viele Verbindungen zu sicheren Kommunikationspartnern innerhalb des Maschinenmoduls. Wenn diese Steuerung für eine oder mehrere dieser Verbindungen ein weiteres Safety-Protokoll unterstützt, haben Sie schon eine sichere Gateway-Funktion – und das an einer dezidierten Stelle. Und die Hersteller sicherer Geräte müssen nicht zusätzlich zum nativen Sicherheitsprotokoll ein weiteres implementieren, zertifizieren und pflegen.

Wollen Sie das zuvor genannte Applikationsprofil auch anderen Nutzerorganisationen zugänglich machen?

Dr. Beckmann: Auf jeden Fall. Da das angesprochene Safety-Profil unabhängig ist vom Safety- und vom Kommunikations-Protokoll, laden wir auch andere Nutzerorganisationen ein, sich an der Erstellung dieses Profils zu beteiligen beziehungsweise dieses Profil ebenfalls zu verwenden. Ähnliches haben wir bereits mit dem Safety-Drive-Profil gemacht, für dessen Verwendung sich beispielsweise auch die Organisation ‚CAN in Automation’ ausgesprochen hat.

Ethercat im Prozessor

Während der Hannover Messe 2011 hatte Texas Instruments die ersten Sitara-Mikropozessoren mit integrierter Ethercat-Slave-Schnittstelle angekündigt. Jetzt sind diese auch verfügbar. Passend zum Release hat Beckhoff die Slave-Protokollsoftware überarbeitet: Der Stack ist nun unabhängig vom verwendeten Ethercat-Slave-Controller. Dieser Slave Stack Code (SSC) gilt als die Referenz-Implementierung und ist als Quellcode kostenlos über den Mitgliederbereich der ETG-Website erhältlich.