Grundbegriffe und Konzepte von OPC UA

OPC UA Server lassen sich erkunden mit graphischen OPC UA Clients. Die interne Struktur stellt dar, wie der Server aufgebaut ist, was direkt Irritationen auslösen kann. Der untenstehende Screenshot zeigt einen beispielhaften OPC UA Server.

Der Anwender sieht immer auf oberster Ebene drei unterschiedliche Ordner: Objects, Types und Views. Diese sind jeweils aufklappbar und bergen eine hierarchische Struktur unter sich, die extrahiert wird aus der unterliegenden Graphstruktur, die OPC UA zueigen ist.

Dass bereits hier mit Views ein de facto nicht genutztes Konzept auftritt, das Fertigungsingenieure und Data Scientists nicht interessieren muss, nährt eine Vermutung, die sich schnell aufdrängt: OPC UA ist mächtig, aber überkomplex. Das Design des Standards erzwingt, dass viel Information über den inneren Zustand des Servers mit dem Client geteilt wird und wenig Fokus auf dem zuerst Wesentlichen, also den Felddaten, liegt. Außerdem ist es die Strategie der OPC Foundation, keine Elemente des Standards abzukündigen, sondern höchstens von der Nutzung abzuraten.

Aufgrund dieser Komplexität bedarf ein Gespräch oder eine Blogserie zum Thema unbedingt klaren Definitionen. Diese sind in der Serie von Spezifikationsdokumenten festgelegt, allerdings fehlt hier ein Glossar, ein Nachschlagewerk für die Grundbegriffe von OPC UA. Um diese zu verstehen, bedarf es eines rudimentären Verständnisses vom OPC UA Datenmodell, das in aller Kürze hier skizziert werden soll:

1. OPC UA modelliert die Welt in Knoten und Beziehungen zwischen den Knoten.
2. Jeder Knoten gehört einer von acht NodeClasses an (Variable, VariableType, Object, ObjectType, DataType, ReferenceType, Method, View).
3. Beziehungen sind beschrieben durch Quellknoten, Art der Beziehung (ReferenceType) und Zielknoten.

OPC UA Glossar

Die stetige Erweiterung bei gleichzeitig garantierter Rückwärtskompatibilität hat den Standard nicht nur auf diverse hundert Seiten anwachsen lassen. Es hat beispielsweise auch dafür gesorgt, dass scheinbar synonyme Begriffe vollständig unterschiedliche Bedeutungen haben. Es folgt deshalb ein Überblick, der zum Nachschlagen dienen soll – inklusive hoch subjektiv eingeschätzter Relevanz. Die Liste wird künftig bei Bedarf noch wachsen. Außerdem dient sie auch als Gedankenstütze für den Autor.

Eigenschaften

Beginnen soll eine Diskussion, wie Eigenschaften von Objekten in OPC UA beschrieben werden können:

• Attributes: Bezeichnen die Eigenschaften von Nodes und sind Teil selbiger. Alle Nodes teilen die Attributes des BaseNodes (die NodeId bspw.). Manche Attributes erben sie von ihrer NodeClass (wie das Value einer Variable bspw.).
• Property: Wird genutzt, um Variables oder Objects flexibel Eigenschaften zuzuschreiben, die nicht in den Attributes abgedeckt sind und eher administrativen Zwecken dienen. Im Gegensatz zu Attributes sind sie Variables (damit auch selbstständige Nodes), die eine eingehende Kante vom ReferenceType hasProperty und eine ausgehende Kante vom ReferenceType hasTypeDefinition haben, die auf den VariableType PropertyType zeigt. Sie sind die Blätter der Hierarchie von OPC UA NodeSets.
• DataVariable: Beschreibt alle Variables, die vom Typ BaseDataVariableType (oder einem seiner Subtypen) sind. Das sollten alle Variables sein, die keine Properties sind. Sie können selbst Properties oder weitere DataVariables unter sich organisieren und hängen in der Regel direkt unter Objects. DataVariables halten die Nutzdaten, die in einem OPC UA Server am meisten von Interesse sind, wie Prozessparameter oder Messdaten innerhalb der Anlage.
• Field: Beschreibt gewisse Eigenschaften von manuell angelegten Structured DataTypes in ihren DataTypeDefinitions oder DataTypeDictionaries. Diese DataTypes haben eigene Key-Value-Pairs, von denen die Keys in OPC UA Field heißen. Genaueres zu Structured DataTypes steht in diesem Blogbeitrag.

Aktion

Verwirrung stiftet auch die semantische Nähe zwischen mehreren Begriffen, die darauf abzielen, dass “sich etwas tut”, im Sinne einer Aktion.

• Method: Eine der acht NodeClasses. Methods sind Nodes, die Aktionen modellieren, welche der Client (bspw. Leitstand) auf dem Server (bspw. Feldgerät) auslösen kann. Die Server müssen natürlich die Logik der Aktion implementieren, kann aber so Komplexität vor dem Client verstecken. Obwohl noch wenig Methods auf Servern im Feld zu finden sind, sind sie ein sehr mächtiges Tool für Realisierung von Industrie 4.0.
• Program: OPC UA definiert Programs im Kontext von Zustandsautomaten. Transitionen des Zustandsautomaten sind durch Methods modelliert. Der Autor hat im Feld noch keinen OPC UA Server gesehen, der Programs implementiert. Dieser Teil der Spezifikation ist “Technical Debt” – also ein Konzept, das weiterhin rudimentär von der Specification unterstützt, aber nicht breit eingesetzt wird. Ein Hauptgrund dafür dürfte sein, dass Programs theoretisch Rückwärtskompatibilität mit OPC Classic schaffen.
• Service: Überbegriff für die kommunikativen Schnittstellen eines OPC UA Servers. Hier werden Aufbau einer Client-Server-Verbindung, Datentransfer etc. spezifiziert. Idealerweise sollte ein End User oder Modellierer die Services fertig implementiert in einem SDK (Software Development Kit) finden und nutzen können, ohne selbst Kenntnis von ihnen zu haben. Einige Services, wie beispielsweise EventHistoryWrite haben sich nicht durchgesetzt und sind in einzelnen SDKs auch nur durch Platzhalter implementiert.

Diese Begriffe sind inkonsistent mit anderen Standards. Ein OPC UA Service bezeichnet ein gänzlich anderes Konzept als Services im Sinne der Fähigkeitsmodellierung oder Services im Sinne des Module Type Package. Da diese Dokumente allerdings miteinander zusammenhängen und aufeinander verweisen, kann schnell Verwirrung entstehen, welche durch die genaue Bezeichnung, WELCHE Definition gemeint ist vermieden werden kann.

Titelbild + Beitragsbild:  © Fraunhofer IWU