Kognitive Produktion

Grundbegriffe und Konzepte von OPC UA

Da schon die ersten Verbindungen mit einem OPC UA Server Irritationen auslösen können, werden im folgenden Artikel wichtige Grundbegriffe vorgestellt und voneinander abgegrenzt.

Schon die erste erfolgreiche Verbindung mit einem OPC UA Server wird Irritationen auslösen.

In der Regel zeigen sich dem Anwender drei Ordner: ObjectsTypes und Views. Sie sind jeweils aufklappbar und bergen eine hierarchische Struktur unter sich. 

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.  

Aufgrund dieser Komplexität bedarf ein Gespräch oder eine Blogserie zum Thema unbedingt klaren Definitionen. Diese sind in der Spec 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. Sie dient auch als Gedankenstütze für den Autor.

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.). Relevanz: hoch – jeder Node hat Attributes.
  • 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 ein Node), der eine eingehende Kante vom ReferenceType hasProperty und eine ausgehende Kante vom ReferenceType hasTypeDefinition, die auf den VariableType PropertyType zeigt. Sie sind die Blätter der Hierarchie von OPC UA NodeSets. Relevanz: hoch – die allermeisten Nodes haben Properties.
  • DataVariable: Beschreibt alle Variables, die vom Typ BaseDataVariableType sind. Das sollten alle Variables sein, die keine Properties sind. Sie können selbst Properties oder weitere Variables unter sich organisieren und hängen in der Regel direkt unter Objects. Relevanz: hoch – 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 DataTypes in ihren DataTypeDefinitions. Relevanz: nichtig – taucht praktisch nur auf bei der Erstellung eigener Informationsmodelle auf.

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

  • Method: Eine der acht NodeClasses. Methods modellieren Aktionen, die der Client (Leitstand) auf dem Server (Feldgerät) auslösen kann. Der Server müssen natürlich die Logik der Aktion implementieren, kann aber so Komplexität vor dem Client verstecken. Relevanz: hoch – obwohl noch wenig Methods auf Servern im Feld zu finden sind, sind sie ein unglaublich mächtiges Tool für Realisierung von Industrie 4.0.
  • Program: Konzept, das OPC UA für Zustandsautomaten nutzt. Transitionen sind durch Methods modelliert. Relevanz: gering – ich hab persönlich noch nie einen OPC UA Server gesehen, der Programs implementiert und angeblich sei dieser Teil der Spezifikation “Technical Debt” – also aus Gründen der Rückwärtskompatibilität mit OPC Classic (deprecated seit 2006) – im Standard belassen worden.
  • Service: Überbegriff für die kommunikativen Schnittstellen eines OPC UA Servers. Hier werden Aufbau einer Client-Server-Verbindung, Datentransfer etc. spezifiziert. Relevanz: gering – idealerweise sollte ein End User oder Modellierer die Services fertig implementiert in einem SDK (Software Development Kit) finden.
  • Function: Kein Begriff des OPC UA Standards selbst, wird aber genutzt, um eine Aktion im Feld zu beschreiben. Beispielsweise ausgelöst durch eine Method oder ein Program. Relevanz: nichtig.

Titelbild + Beitragsbild:  © Fraunhofer IWU

Arno Weiß

Arno Weiß, M.Sc.
Wissenschaftlicher Mitarbeiter
Abteilung "Digitalisierung in der Produktion"

Fraunhofer IWU
Reichenhainer Str. 88
09126 Chemnitz

Telefon: +49 371 5397-1377
E-Mail: arno.weiss@iwu.fraunhofer.de

Kommentar hinzufügen

Arno Weiß

Arno Weiß, M.Sc.
Wissenschaftlicher Mitarbeiter
Abteilung "Digitalisierung in der Produktion"

Fraunhofer IWU
Reichenhainer Str. 88
09126 Chemnitz

Telefon: +49 371 5397-1377
E-Mail: arno.weiss@iwu.fraunhofer.de

Alle Beiträge