Die Protokoll-Elemente

OPC UA vernetzt vertikal und horizontal und dank guter Skalierbarkeit über alle Unternehmensebenen.

© inIT

Das Paradigma REST (Representational State Transfer) bedeutet, dass Mehrfachauf­rufe an die gleiche Web-Adresse immer dieselbe Information liefern und dass keine Methoden-Information im Aufruf transportiert wird. Es bietet dabei zwei Vorteile: Zum einen erfüllen HTTP-fähige Server und Clients REST per se die Anforderungen, zum anderen handelt es sich um ein zustandsloses Verfahren. Damit wird der Server um die Aufgabe der Sitzungsverwaltung entlastet, was der Einfachheit dient, jedoch das Sicherheitsmerkmal der Nutzer-Authentifizierung während des Sitzungsaufbaus ausschließt. Aus dem Portfolio der HTTP-Anfragemethoden wird ausschließlich die Methode GET verwendet. GET dient der Informationsbeschaffung ohne jegliche Nebeneffekte. Dadurch wird die Einfachheit und Effizienz des Datentransports zusätzlich erhöht. Die mittels GET angeforderten Anwendungsdaten des Agents werden bei MTConnect vollständig im XML-Format übertragen.

Die IEC 62541-6 wiederum definiert Technologie-Mappings der protokollunabhängigen Beschreibungselemente von OPC UA. Dazu gehören das Sicherheits-Modell, Service-Definitionen und zu-gehörige Datenstrukturen auf aktuelle Sicherheits- und Transportprotokolle. In der aktuellen Fassung sind die Transportprotokolle TCP/IP, SOAP-HTTP und HTTPS spezifiziert. Die direkt auf der Transportschicht und somit auf TCP/IP des ISO/OSI-Referenzmodells aufsetzende Variante ermöglicht die Kommunikation über den im UA-Stack definierten SecureChannel (UA Secure Conversation). SOAP beschreibt eine XML-basierte Syntax und ermöglicht einen HTTP-basierten Nachrichtenaustausch nach dem Request-Response-Pattern.

Einordnung der Technologien in das OSI Referenz­modell.

© inIT

Die eigentlichen OPC-UA-Nachrichten werden nach dem OPC UA Binary Encoding (Base64 Data, RFC 3548) via WS-Secure-Conversation und SOAP übertragen. Base64 stellt hierbei eine Codepage-unabhän­gige Codierung mittels ASCII-Zeichen dar, was letztlich Effizienzeinbußen gegenüber einer Binärcodierung bedeutet, jedoch effizienter als reines XML genutzt werden kann. WS-Secure-Conversation ist Teil der WS-Spezifikations­reihe, welche eine Klasse von Spezifikationen im Kontext von Webservices mit SOAP/WSDL bereitstellen. Letztlich ermöglicht HTTPS die Übertragung von OPC UA Binary und XML über eine gesicherte Verbindung via SSL/TLS. OPC UA bietet demnach viele Transportvarianten mit unterschiedlichen Codierungs- und Sicherheitsoptionen. Die passende Protokollvariante für einen konkreten Anwendungszweck auszuwählen, erfordert nicht nur entsprechendes Know-how im Bereich der Netzwerktechnik, sondern gerade auch bezüglich IT-Security. Im Sinne der Protokolleffizienz bietet die Übertragung der UA-Binary-Codierung mittels TCP/IP die größten Vorteile. Optimierungspotenzial bietet sich hier zum Beispiel noch bei der Implementierung der UA Secure Conversation. Im Vergleich zu MTConnect bietet OPC UA nicht zuletzt eine Anzahl von Diensten, die weit über die Möglichkeit des Auslesens von Daten hinausgehen. Da-zu zählen unter anderem Methodenaufrufe, Subscriptions mit Deadband und Aggregaten, Bearbeitung historischer Daten und die Gewährung der Typ-­Sicherheit.

Die Datenmodelle

Der Standard MTConnect stellt ein sehr detailliertes Datenmodell für den Bereich der Werkzeugmaschinen dar. Die Struktur des Modells ist in XML-Schemata umfassend beschrieben, ist übersichtlich und eindeutig durch die Verwendung eines einheitlichen Begriffskataloges. Ein Nachteil ist jedoch die Starrheit dieser Vorgehensweise. Eine Erweiterung oder Änderung des Modells kann nur über eine Änderung oder Erweiterung des Standards erfolgen. Austauschbare Einzelteile und Werkzeuge sind unabhängig von den sie aufnehmenden Maschinen beschrieben. So weit wie möglich ist auch das Datenmodell auf bestehende Standards aufgesetzt, wie zum Beispiel auf der ISO 13399 (Werkzeugdatendarstellung und -austausch), womit Doppelnormung vermieden wird.

Mitgliedernutzen der Organisationen

© inIT

Die IEC 62541-3 beschreibt das auf Objekten basierende Address Space Model von OPC UA, welches jeglichem Informationsmodell zugrundeliegt. Die einzelnen Elemente der Objekte werden durch Nodes repräsentiert, bei denen es sich um Variable, Methoden und Referenzen zu weiteren Objekten handeln kann. Dies ermöglicht eine objektorientierte Modellierung von eigenen, komplexen Datentypen und Strukturen. In der IEC 62541-5 standardisierte Nodes dienen zu diagnostischen Zwecken sowie als Einstiegspunkte für Browse Operationen innerhalb des Server-spezifischen AddressSpace. Somit wird durch die IEC 62541-5 das Informationsmodell eines ‚leeren‘ OPC-UA-Servers spezifiziert. Folglich erhält der Anwender bei OPC UA maximale Freiheit bei der Definition des applikationsspezifischen Modells. Dieses kann zum ­Beispiel auf den in den Teilen IEC 62541-8  (Data Access), IEC 62541-9 (Alarme), IEC 62541-10 (Programme) und  IEC 62541-11 (Historische Daten) vordefinierten Modellen aufbauen. Außerdem lässt sich das Informationsmodell zur Laufzeit des Servers ändern (Nodes hinzufügen und löschen), was Vorteile bezüglich der dynamischen Konfiguration von Maschinen und Anlagen bietet.

Kurzum: Prinzipiell lässt sich jedes Datenmodell mit OPC UA abbilden. Das Implementieren eines eigenen Datenmodells auf einem Server bedeutet jedoch einigen Aufwand. Dieser Prozess wird durch die OPC Foundation durch das Angebot von implementierten Beispielen und von Companion Standards für verschiedene Bereiche beschleunigt.

Datenlokalisierung und -zugriff

Für das Auffinden von MTConnect-fähigen Devices durch eine Client-Applikation wird der Einsatz eines LDAP-Servers (Lightweight Directory Access Protocol) und damit ebenfalls ein Standardverfahren empfohlen, bei dem die Agents alle bei ihnen angeschlossenen Devices anmelden. MTConnect definiert den Aufruftyp ‚probe‘ zum Aus­lesen der Struktur der Komponenten und Datenpunkte innerhalb eines Device, wodurch eine Art Browsen des Device unterstützt wird. Weitere Aufruftypen dienen dem Auslesen von Momentanwerten, einschließlich Ereignissen und Zuständen, sowie dem Auslesen verschiedener Historien. Ein Agent speichert die gesammelten Daten in einem Ringpuffer, wobei Überschreiben sowie ein damit verbundener Datenverlust möglich ist und die Anwendung auf der Seite des Clients die Verantwortung für ein rechtzeitiges Auslesen trägt.

Grundsätzlich besitzt jeder OPC-UA-Server einen Discovery Endpoint, welcher von Clients genutzt werden kann, ohne eine komplette Verbindung zu dem Server aufbauen zu müssen. Über diesen Endpoint können Clients die Konfiguration des Servers erfahren – zum Beispiel bezüglich genutzter Sicherheitsoptionen. Existieren mehrere OPC-UA-Server auf einem Gerät, so kommt der Local Discovery Server (LDS) zum Einsatz, bei dem OPC-UA-Server ihre Endpoints registrieren. Das Auffinden von OPC-UA-Servern in einem Subnetz kann außerdem mittels Multicast-DNS (mDNS, RFC 6762) erfolgen. Hierzu ist etwa ein LDS mit Multicast-Erweiterung (LDS-ME) verwendbar, der die bei dem LDS regis­trierten OPC-UA-Server im Netzwerk bekannt macht. Eingebettete Server – zum Beispiel in SPSen oder direkt in der Sensorik – nutzen unter Umständen auch direkt mDNS, um ihre Dienste im Subnetz anzubieten.

Zusätzlich definiert OPC UA einen Global Directory Service (GDS) als zentralen, eigenständigen OPC-UA-Server mit Methoden zur Verzeichnisverwaltung. OPC-UA-Server registrieren sich bei diesem Service und OPC-UA-Clients können Listen von Servern abrufen und durchsuchen. Der GDS kann wiederum mittels mDNS im Subnetz bekannt gemacht werden oder ist mit global verfügbarer und bekannter URL zu erreichen. Ein GDS ermöglicht das netzwerkweite Auffinden von OPC-UA-Servern, während mittels mDNS schnell ein Ad-Hoc-Discovery-Konzept in einem lokalen Subnetz realisierbar ist.

Die Sicherheitskonzepte

Im Umfeld von MTConnect wird das Thema IT-Security mit einer geringeren Priorität betrachtet. Das dabei hervorgebrachte Argument, es würden nur Daten aus der Anlage geliefert und durch dieses Read-only-Paradigma sei Schaden ausgeschlossen, greift etwas kurz. So ist der Schutzbedarf bezüglich der Datenintegrität durchaus angemessen zu betrachten, damit die datenkonsumierenden Instanzen wie MES nutzbringend agieren können. Zum Erhalt der Vertraulichkeit von Daten als weiterem Schutzziel wird bei MTConnect die Verschlüsselung des Datentransports und der Datenspeicher durch Standardverfahren empfohlen, zum Beispiel SSL/TLS für den Transport und AES oder RSA für die Speicherung.

Bei OPC UA ist IT-Security hingegen integraler Bestandteil der Spezifikation und damit auch der Kommunikations-Stacks. Die Definition erfolgt im Part 2 ‚Security Model‘ des Standards. OPC UA stellt sich damit den Herausforderungen an den Schutz von Industrieanlagen, die aus zufälligen Fehlerzuständen oder aus zielgerichteten Attacken entstehen können. Auf verschiedenen Ebenen sind dementsprechend Security-Funktionen definiert; und zwar nicht als optionale Erweiterung, sondern als fest vorgeschriebener Bestandteil des Protokolls. Die Sicherheitsfunktionen adressieren dabei alle IT-Security-Aspekte wie Authentizität, Autorisierung, Integrität sowie Vertraulichkeit.

Auf der Anwendungsebene findet bei OPC UA ein Austausch von ­Zer­tifikaten zur Identifizierung von Applikationsinstanzen statt, um die Glaubwürdigkeit anhand einer ein­deutigen Identität sicherzustellen. ­Einzelnen Datenpunkten können granular Zugriffsrechte zugewiesen werden. Daten werden zudem vertraulich, das heißt  verschlüsselt, übertragen. Hier können sowohl  SSL/TLS, die WS Secure ­Conversation (für UA XML) oder die eigene UA Secure Conver­sation (für UA Binary) zum Einsatz kommen.

Die Zusammenarbeit ­Companion Standards

Bereits kurz nach Inkrafttreten der beiden Spezifikationen erfolgte eine gemeinsame Initiative des MTConnect Institute und der OPC Foundation. Im Ergebnis gab es nicht nur ein ­Memorandum of Understanding, sondern mit der MTConnect-OPC UA Companion Specification auch ein ­Dokument zur Verknüpfbarkeit der beiden Standards. Darin wird ins­besondere das Zusammenführen der Datenmodelle beschrieben, indem Root-Elemente der Datenmodelle aufeinander abgebildet werden. Zu den Transportmechanismen enthält diese Spezifikation keine Vorgaben, da OPC-UA-Companion-Standards nur das Informationsmodell beschreiben, welches über OPC-UA-Protokolle transportiert wird. In praktischen ­Anwendungen kann es dann durchaus ein über Gateways gekoppeltes Nebeneinander der Protokolle von OPC UA und MTConnect geben. Das ­Prinzip der Companion-Standards zur Definition von OPC-UA-Informationsmodellen verfolgt die OPC Foun­dation im Übrigen auch mit anderen Organisationen wie PLCOpen und ­AutomationML.

Auf den Punkt gebracht: Wer eine Lösung für die unidirektionale, vertikale Konnektivität im Bereich der Werkzeugmaschinen sucht, kann MTConnect verwenden. Verlässt man die Domäne der Werkzeugmaschinen oder wird mit Kommunikationsanforderungen wie Wechselseitigkeit oder Ereig­nisorientiertheit konfrontiert, dann kommen die Vorteile des universellen Ansatzes von OPC UA schnell zum Tragen. Der Preis für die Flexibilität ist eine steigende Komplexität. Daraus ergibt sich die Anforderung an Technologie-Anbieter, dem Anwender trotz hoher Komplexität eine einfache Bedienbarkeit zu ermöglichen.
Da die Systeme äußerst verschieden sind – auf der einen Seite ein Protokoll für eine Gruppe von Maschinentypen, auf der anderen Seite eine  Architektur zum Daten- und Informationsaustausch –, ist ein direkter Vergleich mit quantifizierbaren Mess-Ergebnissen jedenfalls nicht sinnvoll.

Autoren: Prof. Dr. Jürgen Jasperneite ist Leiter des inIT der Hochschule Ostwestfalen-Lippe und Leiter des Fraunhofer IOSB-INA,  Arne Neumann ist wissenschaftlicher Mitarbeiter am Institut für industrielle Informationstechnik (inIT) der Hochschule Ostwestfalen-Lippe in Lemgo und Florian Pethig ist wissenschaftlicher Mitarbeiter am Fraunhofer-Anwendungszentrum Industrial Automation (IOSB-INA) in Lemgo.