06. Jan. 2023
Grundlagen und Funktionsweise verstehen
Standardisierter und sicherer Datenaustausch
In welchem Umfeld wird OPCUA eingesetzt?
Durch die zunehmende Digitalisierung in der Industrie spielen die globale Vernetzung und die Dienste des Internets eine zentrale Rolle, um den Herausforderungen von Industrie 4.0 gerecht zu werden. Der standardisierte und sichere Datenaustausch zwischen Feldgeräten und Diensten aus verschiedenen Branchen stellt eine zentrale Herausforderung dar. In diesem Zusammenhang spielt der M2M-Kommunikationsstandard Open Platform Communications Unified Architecture (OPC UA) eine zentrale Rolle. Der OPC UA-Standard ermöglicht einen sicheren, zuverlässigen und plattformunabhängige Datenaustausch. Das Ziel des OPC UA-Standards ist eine semantische Interoperabilität, damit die Semantik der Nachrichten für alle Anwendungen im OPC UA-Umfeld auf einer einheitlichen Ebene festgelegt ist [1].
Informationsmodell – Wie werden Informationen dargestellt?
Der OPC UA-Standard setzt auf dem Industrial Internet of Things (IIoT) auf, dadurch wird der Austausch von Informationen durch Endgeräte wie Maschinen ermöglicht [2]. Im Weiteren wurde OPC UA als eine serviceorientierte Architektur (SOA) konzipiert. Bei OPC UA ist der Transportmechanismus und die Datenmodellierung getrennt [3]. In den folgenden Abschnitten wird gezeigt, wie Informationen in OPC UA dargestellt werden können. Im Weiteren wird das Konzept des Informationsmodells von OPC UA dargestellt, d.h. die folgenden Ausführungen sind unabhängig von Kommunikationsprotokollen und Programmiersprachen. Das Informationsmodell bildet die Grundlage für den Adressraum eines OPC UA Servers, welches als voll vernetzter Graph angesehen werden kann [4]. Dieser Graph besteht aus Knoten mit Eigenschaften und Kanten zwischen den Knoten. An die einzelnen Knoten sind die OPC UA Funktionalitäten Data Access, Historical Data Access, Alarms & Events, Commands gekoppelt. Die Repräsentation der Daten bspw. von Sensoren oder von kompletten Produktionsanlagen wird durch das Informationsmodell und objektorientierter Modellierungsparadigmen ermöglicht. Es wird dabei zwischen Instanzdaten (Repräsentation einer Produktionsanlage) und Typendaten (Semantik) unterschieden. Aktuell werden Informationsmodelle meist auf herstellerspezifischen Vorgaben erstellt. Die Modellierung von eigenen Informationsmodellen ist mit dem Free OPC UA Modeler möglich, der eine graphische Oberfläche bietet.
Knoten
Das Informationsmodell besteht aus sogenannten Knoten, die in einer Knotenmenge (NodeSets) gruppiert sind. Jeder OPC UA Knoten gehört zu genau einem NodeSet. Im Weiteren gibt es einen grundlegenden NodeSet, welcher die Basis für alle anderen NodeSets bildet. Dieser Basis-NodeSet wurde von der OPC Foundation eindeutig definiert ([5], [6]). Die Identifizierung eines NodeSets findet über einen eindeutigen Namespace statt. Dieser Namespace ist eine URL, welche meist mit dem Namen der jeweiligen Firma oder des Projekts verbunden ist. Außerdem ist es immer wichtig zu wissen, welcher Knoten zu welchem NodeSet gehört, deshalb wird die Namespace URL immer in einem NamespaceArray abgespeichert. Die Referenzierung eines Knotens findet schließlich nur noch über den Namespace-Index statt. Ein vorbelegter Index ist der Namespace-Index = 0, dieser gehört immer zum Basis-NodeSet der OPC Foundation.
Jeder Knoten enthält verschiedene Attribute, diese sind:
Nodeld – Dieser Bezeichner ist innerhalb des gesamten Informationsmodells eindeutig. Die NodeId besteht aus dem Namespace-Index und einem innerhalb des NodeSets eindeutigen Bezeichners. Es gibt für den Bezeichner innerhalb eines NodeSets verschiedene Typen:
- Numeric (i): Ganzzahliger positiver Integer-Wert
- String (s): Maximal 4096 Bytes
- Guid (g): Format 00000000-0000-0000-0000-000000000000
- Opac: Freies Format vom Datentyp ByteString mit maximal 4096 Bytes
Ein Beispiel für eine NodeId ist in Abbildung 1 zu sehen.
(1) Namespace-Index: 3
(2) NodeId-Typ: String (s)
(3) ID: Bezeichnung des Sensors I3
Der Root-Knoten des Basis-NodeSets hat die Bezeichnung i=84, wobei der Namespace-Index 0 weggelassen werden kann.
BrowseName Dieses Attribut gibt einen sprachunabhängigen und menschenlesbaren Namen an. Der BrowseName ist durch den NamespaceIndex eindeutig einem NodeSet zugeordnet. BrowseNames sind eindeutig referenzierbar, indem über den BrowseName-Pfad auf einen Knoten referenziert werden kann.
DisplayName Dieses Attribut ist zur Visualisierung eines Knoten geeignet. Außerdem kann ein Knoten mehrere DisplayNames haben, welche sprachabhängig und frei gewählt werden können. Eine optionale Sprachangabe ermöglicht die Mehrsprachigkeit dieses Attributs.
(Optional) Description Dieses Attribut bietet ebenfalls eine sprachabhängige Verwendung und jeder Knoten kann mehrere Beschreibungen besitzen.
(Optional) WriteMask Dieses Attribut bietet die Möglichkeit Schreibrechte auf die anderen Attribute des Knotens zu konfigurieren.
UserWriteMask In diesem Attribut werden die aktuellen Schreibrechte in Bezug auf die Clients dargestellt. Es werden dabei die Schreibrechte angeboten, die der OPC UA Server anbietet.
RolePermissions In dieser Attribut wird ein Array von Zugriffsrechten modelliert. Es werden dabei Elemente vom Typ RolePermissionType verwendet. Diese Elemente bestehen aus einer RollenId und aus Berechtigungen. Diese Berechtigungen beziehen sich nicht auf Knotenattribute, sondern auf Dienste des Server wie bspw. das Browsen, Löschen oder Hinzufügen des Knotens oder das Schreiben und Lesen von historischen Daten.
Knotentypen
Das Informationsmodell von OPC UA beinhaltet acht verschiedene Typen (NodeClass) von Knoten. Diese Typen werden nun kurz erklärt.
Das Objekt (engl. object) ist ein Knoten, der ein physisches oder abstraktes Element eines Systems oder ein Teil eines Systems repräsentiert [3]. Beispiele für Objekte sind Produktionsanlagen oder IIoT-Geräte. Der Objekttyp (engl. ObjectType) ist ein Knoten, der die Typdefinition für ein Objekt darstellt. Diese NodeClass definiert das Objekt inklusive Unterstrukturen (Properties, DataVariables und Objekte der Unterstrukturen). In Abbildung 2 ist die graphische Notation der Knotentypen dargestellt.
Eine Methode (engl. Method) stellt eine aufrufbare Softwarefunktion eines Objekts oder Objekttyps dar. Eine Sicht (engl. View) ist eine Untermenge des Adressraums, welche den Zugang für bestimmte Clients vereinfachen kann. In Abbildung 5 sind die Knotentypen gezeigt.
Referenztypen
Zwei Knoten im Informationsmodell können miteinander verbunden werden, dies geschieht über eine gerichtete Kante (Referenz). Jeder Referenz ist genau ein Referenztyp zugeordnet. Es gibt einige Referenztypen, welche in [5] beschrieben werden. In diesem Artikel werden die vier wichtigsten Typen vorgestellt.
Der Referenztyp HasComponent dient zur Abbildung von Teil-von-Beziehungen. Im Weiteren wird dieser Referenztyp genutzt, um Objekte oder Objekttypen mit ihren untergeordneten / enthaltenen Objekten, Datenvariablen, Methoden und Variablen oder Variablentypen mit ihren Datenvariablen zu verbinden.
Der Referenztyp HasProperty dient zur Identifikation der Properties eines Knotens. In Abbildung 6 ist die graphische Darstellung dieser beiden Typen gezeigt.
Der Referenztyp HasSubType zeigt Vererbungsbeziehungen innerhalb von Typhierarchien an. In der Abbildung 7 sind die beiden Referenztypen in der graphischen Notation dargestellt.
Kommunikationsmodelle – Wie wird kommuniziert?
OPC UA ermöglicht neben dem Client/Server-Modell auch das Publisher/Subscriber Kommunikationsmodell zu verwenden. Im Folgenden werden die beiden Mechanismen kurz vorgestellt.
Client-Serverarchitektur: Beim Client-Server-Modell nutzen die OPC UA Clients einen dezidierten OPC UA Server, wobei dieser Peer-to-Peer-Kontext für einen sicheren und bestätigten Informationsaustausch dient [3]. In diesem Zusammenhang sendet der Client eine Anfrage an den Server, der die Anfrage bearbeitet und eine Antwort an den Client zurückschickt.
Publish-Subscribe-Architektur: Das Publisher/Subscriber Kommunikationsmodell ermöglicht die für OPC UA typische, standardisierte Datenrepräsentation. Außerdem wird durch dieses Modell eine echtzeitfähige und verschlüsselte 1:n Kommunikation ergänzt. Beim Pub/Sub-Modell agieren Publisher und Subscriber unabhängig voneinander. Der Publisher veröffentlicht eigenständig Nachrichten, welche schließlich vom Subscriber empfangen werden können. Die Verbindung zwischen Publisher und Subscriber wird durch eine nachrichtenorientierte Zwischenschicht (software- oder hardwareseitig) ermöglicht. Die UDP-Variante nutzt die Multicast-Funktionalität von UDP. Hierbei findet ein unbestätigter Informationsaustausch zwischen Publisher und Subscriber statt [3].
Ausblick
Im ersten Teil zu OPC UA haben wir mit dem Informationsmodell und dem Kommunikationsmodell den Grundstein gelegt. Die Kernaussage des ersten Teils ist, dass OPC UA der Standard in der industriellen Kommunikation ist. Die Informationsmodelle dienen zur Konfiguration von OPC UA Servern, sodass die Daten von komplexen Industrieanlagen abgegriffen werden können. Im Weiteren wurde deutlich, dass OPC UA sowohl als Client-Serverarchitektur als auch als Publish-Subscribe-Architektur betrieben werden kann.
Im nächsten Teil werden wir Open Source Implementierungen von OPC UA betrachten und diese in einer Analyse vergleichen. Wir freuen uns, wenn ihr beim nächsten Artikel wieder vorbeischaut.
Referenzen
[1] OPC UA Foundation. OPC Unified Architecture – Wegbereiter der 4. industriellen (R)Evolution
[2] T Bartnitzki. Opc Ua – Ein Kommunikationsstandard für Bergbau 4.0. 2016
[3] Henning Mersch, Jouni Aro, Heikki Tahvanainen, Daniel Pagnozzi, Tho- mas Usländer, Julius Pfrommer, Robert Henßen, Nadia Scandelli, Jan Bajorat, and Miriam Schleipen. Praxishandbuch OPC UA: Grundlagen- Implementierung-Nachrüstung-Praxisbeispiele. Vogel Buchverlag, 2020.
[4] Opc unified architecture – part 1: Overview and concepts, 2017.
[5] Opc unified architecture – part 3: Address space model
[6] Opc unified architecture – part 5: Information model.
[7] Opc unified architecture – part 14: Pubsub, 2018.