Vier TCP-basierte Kommunikationsprotokolle als Schlüssel für das IIoT – Teil 2: OPC UA
Inhalt dieses Beitrags
Vier TCP-basierte Kommunikationsprotokolle als Schlüssel für das IIoT – Teil 2: OPC UA
Wenn es um die Zukunft der Automatisierung geht, den Aufbau von IIoT-Netzwerken und smarten Fabriken, spielt vor allem die Konnektivität eine wichtige Rolle: Große Netzwerkstrukturen, in denen einzelne Knotenpunkte miteinander verbunden sind und Daten untereinander austauschen, verdrängen zunehmend die starren, hierarchischen Automatisierungspyramiden mit trennenden Zwischenebenen.
Um diese intelligente Vernetzung zu realisieren, müssen die Geräte IIoT-fähig sein. Sie müssen also bestimmte Anforderungen erfüllen, wie Standardisierung, Skalierbarkeit, Kompatibilität mit IT- und OT-Systemen und die Fähigkeit zur Interoperabilität. Außerdem ist es von großer Bedeutung, dass sie eine sichere Kommunikation gewährleisten. Verschiedene Kommunikationsprotokolle, darunter MQTT, OPC UA, AMQP und REST API ermöglichen eine solche smarte Kommunikation bis in die Cloud. In unserer mehrteiligen Blogartikel-Reihe erfahren Sie mehr über die charakteristischen Merkmale dieser IIoT-Kommunikationsprotokolle und in welchen Anwendungsfällen sie besonders gut geeignet sind. Im Fokus des zweiten Teils dieser Artikelserie steht OPC UA.
Was ist OPC UA und wie funktioniert es?
OPC Unified Architecture (OPC UA) ist eine plattformunabhängige, serviceorientierte Architektur. Als Nachfolger von Classic OPC lag die Zielsetzung von OPC UA darin, die Defizite von Classic OPC zu beseitigen, allem voran die Abhängigkeiten von Microsoft und COM/DCOM. Die OPC Foundation, also dieselbe Organisation, die Classic OPC entwickelt hat, ist auch für die Entwicklung und Verwaltung von OPC UA verantwortlich. Die erste Spezifikationsfreigabe erfolgte im Jahr 2008 und wurde IEC-zertifiziert (IEC 62541). OPC UA, die als Architektur anstatt als Kommunikationsprotokoll bezeichnet wird, bietet ein vollständiges Ökosystem für Implementierungen. Dieses Ökosystem ist so flexibel aufgebaut, dass OPC UA beim Erscheinen künftiger neuer Technologien bereit ist, diese an das bestehende System zu binden und zu nutzen. So wurde beispielsweise 2018 OPC UA Pub/Sub freigegeben (bis dahin war OPC UA primär von Request/Response abhängig). Die größte Aufmerksamkeit erhalten derzeit die TSN-Standards (TSN = Time-Sensitive Network), die ein deterministisches Timing-Verhalten ermöglichen. Diese Motivation, Abläufe zeitlich zu optimieren, wird durch die kontinuierlichen Bemühungen der OPC Foundation in verschiedenen technischen und marketingrelevanten Aktivitäten umgesetzt. Ein wesentlicher Aspekt von OPC UA besteht darin, dass keine Gerätebeschreibungsdateien vorhanden sind. Jedes Gerät verfügt selbst über alle Informationen und ist für Kommunikation, Identifizierung oder Datenzugriff nicht von externen Dateien abhängig.
Doch das ist noch nicht einmal das Faszinierendste daran. Die wichtigsten Aspekte, die OPC UA der Industrie bietet, sind Datenmodellierung, Informationsmodelle und die Aktivität von Konsortien, etwa von technischen Arbeitsgruppen, die auf eine branchenübergreifende Harmonisierung und Kommunikation aller Geräte hinarbeiten.
Datenmodellierung
Die grundlegenden Elemente der OPC-UA-Datenmodellierung sind die Knoten und Referenzen. Jede Dateneinheit wird als Knoten bezeichnet und alle Knoten verbinden sich über Referenzen. Bei den Knoten und Referenzen gibt es verschiedene Typen. Ein Knoten kann beispielsweise den Typ „Object“, „Variable“, „Method“, „ObjectType“ oder „DataType“ haben. Die Referenzen haben ebenfalls Typen, sind jedoch auf einer höheren Ebene in hierarchischen und nichthierarchischen Gruppen zusammengefasst. Die Knoten und Referenzen befinden sich innerhalb eines Adressbereichs und auf alle Knoten kann über „Node-Ids“ (Knoten-Kennungen) zugegriffen werden. Die Node-Id entspricht einer Adresse, auf der der entsprechende Knoten (Dateninformation) vorhanden ist.
Informationsmodelle
Die Informationsmodelle sind Bausteine für die OPC-UA-Anwendung. Sie bieten Standardknotendefinitionen, die eine bessere Harmonisierung zwischen Geräten ermöglichen. Es gibt mehrere Informationsmodelle. Die OPC Foundation definiert grundlegende Modelle wie „Data Access (DA)“, „Historical Data Access (HDA)“, „Alarms and Conditions“ und „Programs“, die Informationen darüber bieten, welche Funktionen eine OPC-UA-Anwendung unterstützt. DA ist der standardmäßige Zugriff auf Prozess- und Parameterdaten. HDA ergänzt Funktionen zum Speichern mehrerer Messungen vom selben Knoten für statistische Zwecke. Alarms and Conditions bieten die Möglichkeit, im Fall von Notfallbenachrichtigungen Ereignisse zu senden, und Programs ermöglichen es, einfache Zustandsmaschinen zu definieren.
Dank der Skalierbarkeit von OPC UA ist es möglich, nur das Data-Access-Informationsmodell zu implementieren, das besonders für Geräte mit einem begrenzten Angebot an Speicher und Rechenleistung nützlich ist. Zusätzlich zu diesen vier Informationsmodellen hat die OPC Foundation ein weiteres Modell namens Device Integration (DI) Information Model erstellt, das die Grundlage für zahlreiche weitere Informationsmodelle von technischen Arbeitsgruppen wie FDI, PLCopen, AutoID oder OPC UA für IO-Link bildet. Diese Informationsmodelle tragen wesentlich zur Harmonisierung von Geräten bei, da sie dieselben Informationen auf denselben Access Points (NodeIds) implementieren. Das bedeutet, dass es sehr einfach ist, ein Gerät gegen ein anderes auszutauschen, selbst wenn es von einem anderen Anbieter stammt.
OPC UA Pub/Sub:
Die Pub/Sub-Erweiterung in OPC UA verfügt über ein eigenes Nachrichtenformat, die NetworkMessage, und verwendet andere Kommunikationsprotokolle als die Client/Server-Implementierung. Sie verwendet MQTT, AMQP, OPC UA UDP und OPC UA Ethernet. Besonders attraktiv daran ist, dass sich diese vier Protokolle auf drei verschiedenen TCP/IP-Modellebenen befinden: auf der Netzwerkschicht, der Transportschicht und der Anwendungsschicht.
Abbildung 1: Typische OPC-UA-Anwendung
Abbildung 1 stellt die beiden Muster „Request/Response“ und „Pub/Sub“ nebeneinander. Die OPC-UA-Anwendung enthält sowohl einen OPC-UA-Server als auch einen MQTT-Client und kommuniziert mit zwei parallelen TCP-Verbindungen. Sie veröffentlicht entweder Daten an den MQTT-Broker oder erhält eine Anfrage vom OPC-UA-Client. Die Anwendung kann nicht an der parallelen Kommunikation mit ihnen gehindert werden. Hierfür sind nur zwei TCP-Verbindungen erforderlich. Der Vorteil ist, dass die Daten nur einmal gespeichert, aber über zwei separate Kanäle übertragen werden.
Interoperabilität von OPC UA
OPC UA verfügt über viele syntaktische und semantische Interoperabilitätsfunktionen. Syntaktisch nutzen alle Geräte die gleichen Typen und Dienste für die Kommunikation. Darüber hinaus verwenden sie Informationsmodelle, die alle im gleichen Format gespeichert werden – in einer Nodeset-Datei. Die Nodeset-Datei enthält eine Sammlung aller Knoten und Referenzen, die zusätzlich zu den grundlegenden Modellierungsregeln in OPC UA definiert sind, und liefert die in einem Informationsmodell definierten Daten in einem maschinenverständlichen Format. Die Nodeset-Dateien bieten sowohl syntaktische als auch semantische Interoperabilität. Aus syntaktischer Sicht haben diese Dateien dieselbe Struktur und können aus jeder OPC UA- Anwendung geparst werden. Aus semantischer Sicht arbeiten zahlreiche Arbeitsgruppen an der Harmonisierung der Namen ihrer Parameter- und Prozessdaten, ihrer Methodenverfügbarkeit, ihrer Ereignisse usw., damit sich unterschiedliche Geräte ähneln und ähnlich verhalten. Ein Beispiel ist das AutoID-Informationsmodell, das darauf abzielt, alle Identifizierungsgeräte wie RFID-Lesegerät und Strichcodeleser zu vereinheitlichen. Darüber hinaus können sie über anbieterspezifische individuelle Parameter verfügen, sollten aber auf einer gemeinsamen Grundlage aufbauen. Dadurch wird die Implementierung des OPC-UA-Clients vereinfacht, da für die einzelnen Sondervarianten kein Verbindungsglied erforderlich ist. Kurz gesagt: OPC UA ist zu Maschine-Maschine-Interaktionen fähig. Durch die Verwendung von Visualisierungstools zur Darstellung des Informationsmodells ist es zudem von Mensch zu Maschine interoperabel.
Echtzeitverhalten von OPC UA
OPC UA hatte nach der Expansion in die Pub/Sub-Welt Chancen, im Echtzeitbereich zu konkurrieren. Mit seinem Request/Response-Muster hätte es kaum mit MQTT und AMQP Schritt halten können.
Sicherheit von OPC UA
OPC UA folgt den Web Service Security Specifications für seine WS Secure Conversation und erstellt daraus eine binäre Variante für den TCP-Binärpfad namens UA Secure Conversation. Darüber hinaus bietet es als Sicherheitsmechanismen Benutzername/ Kennwort, X.509-Zertifikate und ausgestellte Tokens sowie Funktionen zum Auditing von Nachrichten, um zu protokollieren, welcher Client welchen Wert zu welchem Zeitpunkt geändert hat.
Implementierung von OPC UA
Das einzige Protokoll, das aufgrund seiner vielen Funktionen erweitert werden kann, ist OPC UA. Abgesehen von der standardmäßigen Sicherheitsskalierung, die lediglich das Ausschalten der Sicherheit bedeutet (und weder für OPC UA noch für die übrigen Protokolle empfohlen wird), kann OPC UA auf mindestens zwei Arten skaliert werden: einerseits durch die Auswahl eines geeigneten OPC-UA-Profils für kleine eingebettete Geräte (Nano Embedded Device Server Profile), das die Anzahl der TCP-Verbindungen auf eins begrenzt, anderseits, indem die Anwendung auf die grundlegenden Informationsmodelle wie Data Access (DA) beschränkt wird.
Aufwand:
OPC UA ist ebenfalls vom Konzept her komplex, insbesondere wenn es um den Aufbau eines vollständigen Informationsmodells geht. Es wird daher empfohlen, bereits vorhandene Informationsmodelle zu verwenden, die zum Anwendungsfall passen. In der Protokoll- und Sicherheitsansicht empfiehlt es sich außerdem, eine bereits vorhandene Bibliothek zu verwenden und darauf aufzubauen.
Anwendung von OPC UA
OPC UA eignet sich besonders für Anwendungsbereiche, in denen gemeinsam genutzte Daten standardisiert und harmonisiert werden sollen, Geräte einfach austauschbar sein sollen, indem sie dieselben Informationsmodelle nutzen, Ereignisse, Alarme und historische Daten nützlich sind, und selbst dann, wenn eine Mischung zwischen Request/Response und Pub/ Sub-Kommunikation genutzt wird. Kein Wunder, dass OPC UA weltweit in Millionen von Maschinen und Fabriken installiert wurde, von der Logistikbranche über die Automobilindustrie bis hin zur Chemieindustrie usw.
Whitepaper: TCP-basierte Kommunikationsprotokolle
Möchten Sie mehr über die TCP-basierten Kommunikationsprotokolle OPC UA, MQTT, AMQP und REST API erfahren? Die vier Schlüsseltechnologien für das IIoT im detaillierten Vergleich: Laden Sie sich gleich unser kostenfreies Whitepaper herunter.
Abonnieren Sie unseren Newsletter und erhalten Sie regelmäßig Neuigkeiten und Wissenswertes aus der Welt der Automatisierung.