Bisher ist die funktional sichere Kommunikation über einen Feldbus oder Industrial Ethernet auf reine Master-Slave bzw. Controller-Device-Architekturen begrenzt. Für die sichere Übertragung zwischen Maschinen – und damit zwischen den in den Maschinen eingesetzten Steuerungen – gibt es aber heute keinen herstellerübergreifenden Standard. Controller verschiedener Hersteller können daher bisher nicht ohne weiteres sicher miteinander kommunizieren. Diese Situation ist in Hinblick auf die zunehmende Vernetzung in den Unternehmen unbefriedigend. So gibt es Branchen mit einer sehr heterogenen Automatisierungslandschaft, wie z.B. Food & Beverage, bei denen häufig Steuerungen unterschiedlicher Hersteller funktional sicher miteinander verbunden werden müssen. Gleichzeitig hat der Einsatz funktional sicherer Geräte in den vergangen Jahren rasant zugenommen. Eine funktional sichere Kommunikation zwischen Controllern wird immer dann benötigt, wenn verschiedene Maschinen untereinander sicher koordiniert werden müssen. Meist tritt dies im Zusammenspiel zwischen Bearbeitungsmaschinen und den zuführenden und abführenden Transporteinheiten auf. Typische Beispiele sind hier Transferstraßen, Elektrohängebahnen oder Werkzeugmaschinen mit ihren Be- und Entladesystemen. Wo heute für die Verarbeitung von funktional sicheren Signalen im Maschinenverbund spezielle Verkabelungen, Koppler oder auch Zusatzsensorik zur Kollisionserkennung installiert werden, können zukünftig mit der sicheren Kommunikation über das ohnehin vorhandene Netzwerk deutlich Aufwand eingespart, sowie flexiblere Konzepte umgesetzt werden. Weitere Einsatzbereiche lassen sich in Schleusen- und Brückenapplikationen finden, wo die Objekte von einer zentralen Leitwarte aus der Ferne zu überwachen und sicher zu steuern sind. Hier sind also größere Distanzen für Safety-Signale zu überbrücken. Interessant sind z.B. auch Krananwendungen: Bei großen Industriekränen werden über ein zentrales Steuerpult mehrere Kräne bedient. Die verantwortliche Person am Bedienpult muss in einer Gefahrensituation jederzeit in der Lage sein, den betreffenden Kran sicher abzuschalten. Außerdem gibt es Applikationen, bei denen mehrere ´Krankatzen´ koordiniert werden müssen, um schwere Lasten zu tragen. Auch diese Applikationen sind sicherheitsrelevant und erfordern einen nicht unerheblichen Datenaustausch zwischen den einzelnen Steuerungen.
Das Safety-over-OPC-UA-Konzept
Eine Lösung der Problematik bietet sich mit der derzeit im Review befindlichen Spezifikation ´Safety over OPC UA´ an. Da OPC UA für Verbindungen zwischen den Steuerungen unterschiedlicher Hersteller eine zunehmend wichtige Rolle spielt, sehen es die beiden kooperierenden Organisationen von PI und OPC Foundation für sinnvoll an, die Mechanismen von Profisafe auch auf OPC UA auszuweiten. Eine gemeinsame Working Group legt die Eckpunkte für funktionale Sicherheit und die Randbedingungen fest: Das Ergebnis steht allen Mitgliedern der OPC Foundation und PI zur Verfügung. Es ist konform zu der IEC61784-3 ´Functional Safety Fieldbuses´ und es nutzt bestehende Profisafe-Mechanismen. Die tragenden Prinzipien von Profisafe gelten also weiterhin: Ein einziges Kabel für die Standardkommunikation und die sicherheitsbezogene Kommunikation sowie das bewährte Black Channel Prinzip. Dieses lässt sich auch auf die Controller/Controller-Kommunikation übertragen, wobei dann das OPC-UA-Kommunikations-Protokoll die Rolle des Black Channel übernimmt. Auch die bewährten Protokoll-Sicherungsmechanismen, wie z.B. CRC-Prüfung, Codenames, Monitoring-Number, Watchdog-Überwachung und SIL-Monitor, werden übernommen. Das OPC-UA-Kommunikations-Protokoll und die Netzkomponenten, wie Gateways oder Router, müssen bei einer Zertifizierung nicht betrachtet werden, und lassen sich auch im Nachhinein jederzeit anpassen oder erweitern. Zertifizierungsrelevant ist lediglich die Korrektheit der Implementierung des OPC-UA-Safety-Protokolls auf einer funktional sicheren Plattform.
Das Konzept im Detail
Die neue Spezifikation adressiert zunächst die Client/Server-Kommunikationsmodelle von OPC UA. Eine Anbindung an Pub/Sub inklusive Pub/Sub über TSN ist bereits vorgesehen, sodass später auch sehr kurze Zykluszeiten in der Kommunikation realisierbar sind. Dabei sind unidirektionale, bidirektionale und Multicast-Verbindungen ebenso möglich wie beliebige Netzwerktopologien (Linie, Baum, Stern, Ring…). Auch bei den Datenmengen gibt es mit bis zu 1.500 Bytes genügend Reserven. Anpassungen waren in den Zustandsmaschinen, den Protokoll-Datagrammen und der Initialisierung notwendig, da jetzt gleichberechtigte Controller untereinander, statt ein Controller mit unterlagerten Devices, kommunizieren. Bei der Definition der Zustandsmaschine des Profisafe-Protokolls wird z.B. geklärt, wie ein Verbindungsaufbau läuft, wann Prozesswerte oder sichere Ersatzwerte auszugeben sind, oder wie ein Wiederanlauf zu quittieren ist. Ein weiterer Aspekt ist die Definition der zu übertragenden Datentypen und -strukturen sowie die sichere Prüfung, ob beide Kommunikationspartner überhaupt dasselbe Verständnis darüber haben, wie die übertragenen Daten zu interpretieren sind. Neu ist auch, dass die Diagnose vereinfacht ist. Gerade bei komplexen Sicherheitsfunktionen, in denen mehrere Steuerungen unterschiedlicher Hersteller involviert sind, ist es wichtig, Fehler schnell zu erkennen, zu lokalisieren, und die Ursache zu finden. Daher legt die Spezifikation auch die anzuzeigenden Diagnosedaten fest, um sicherzustellen, dass für jede Fehlerart (z.B. CRC-Fehler oder Time-Out) bei allen Steuerungen auch derselbe Fehlertext angezeigt wird. Eine Diagnose ist sowohl über die bereits bestehenden Mechanismen der einzelnen Hersteller möglich, als auch über OPC UA, was die Lokalisierung und Identifizierung möglicher Fehlerquellen beschleunigt.
Wechselnde Kommunikationspartner
Bei Safety over OPC UA können Verbindungen auch zur Laufzeit auf- und abgebaut werden. Ein gegebenes Interface lässt sich abwechselnd von verschiedenen Partnern nutzen, es wird also ein dynamischer Verbindungsaufbau möglich. Davon profitieren modulare Maschinen, Autonomous Guided Vehicles (AGVs), Autonomous Moving Robots (AMRs) und Werkzeugwechsler gleichermaßen. Anders als bei allen heutigen funktional sicheren Kommunikationsprotokollen müssen nicht mehr alle Teilnehmer schon bei der Projektierung gegenseitig bekannt gemacht werden. Dadurch ist es möglich, der Anlage etwa einen neuen mobilen Roboter hinzuzufügen, ohne alle feststehenden Maschinen neu zu parametrieren.
