OPC UA - Wir schauen genau hin!

OPC UA etabliert sich immer weiter auf dem Markt und wird unter anderem bei Firmen wie BMW, Miele und Samsung eingesetzt. Das ist auch nicht verwunderlich, denn es gibt zahlreiche Vorteile. Im Gegensatz zu anderen industriellen Kommunikationsprotokollen definiert das von der OPC Foundation beaufsichtigte OPC UA nicht nur die Kommunikationsschicht, sondern schlägt auch ein umfassendes Informationsmodell vor. Damit kann eine höhere Interoperabilität gewährleistet werden. Erweitert wird die mehrteilige Kernspezifikation von OPC UA durch sogenannte Companion Specifications (CS), welche von Branchenverbänden herausgegeben werden. So entsteht eine sehr flexible und erweiterbare Architektur, die sich in vielen verschiedenen Kontexten einsetzen lässt.

Gemeinsam mit der textuellen Beschreibung der Spezifikation wird für jede CS eine spezielle XML-Datei (Node-Set2.xml) veröffentlicht, welche das Informationsmodell maschinenlesbar beschreibt. Wie in der Grafik zu sehen, kann diese in der OPC UA Anwendung verwendet werden. Eine genauere Beschreibung von OPC UA und weiteren Transportkontrollen im IoT findest du hier.

Da ich mich während meiner Masterarbeit eingehend mit OPC UA beschäftigt habe, sind mir auch ein paar Unstimmigkeiten aufgefallen. Im industriellen Einsatz ist OPC UA schon heute ein etablierter Standard, bei der Verwendung neuer Companion Spezifikationen können jedoch Schwierigkeiten auftreten. Da ich denke, dass hinter OPC UA großes Potenzial steckt, möchte ich meine Kritik gerne mit euch teilen und freue mich zu hören was ihr darüber denkt. Sind euch auch schon ähnliche Schwierigkeiten aufgefallen oder habt ihr noch weitere Kritik?

Fangen wir mit den Node-Set2.xml-Dateien an, welche die einzelnen Spezifikationen maschinenlesbar machen. Beim Umgang mit diesen begegneten mir oft schlecht oder gar nicht dokumentierte Probleme. Die verschiedenen SDKs beinhalten meist Beispiele welche zeigen, wie eine NodeSet2.xml verwendet werden kann. Leider heißt das nicht, dass andere NodeSet2.xml-Dateien dann problemlos funktionieren. Dabei habe ich bemerkt, dass die Dateien mit unterschiedlichen Tools erstellt werden, z.B. UaModeler (Unified Automation) bei der Machine Vision CS oder der UA-ModelCompiler (OPC Foundation) bei der Device CS. Ich vermutete, dass dies ein Grund für die Inkonsistenzen ist. Auf Nachfrage hieß es bei der OPC Foundation von Technical Director Karl-Heinz Deiretsbacher, dass alle NodeSet2.xml-Dateien mit einem Validierungstool geprüft werden. Dies führt wiederum zu dem Schluss, dass das Problem bei den jeweiligen SDKs liegt, welche nicht für alle verfügbaren NodeSet2.xml Dateien der CSs optimiert sind.

SDKs

Das leitet auch direkt zum nächsten Punkt über, denn meiner Meinung nach fällt der Vergleich von SDKs oft schwer, da sie sich nicht an die Beschreibung ihres Umfangs mit den Profilen und Facetten halten. Oft fehlen auch Implementierungen. Hier ist aber die Prämisse der OPC Foundation, dass nur ein sehr kleiner Teil von OPC UA von jeder Anwendung erfüllt werden muss. Alles weitere ist optional, sodass auch leichtgewichtige SDKs und Anwendungen existieren können. Das hat zum einen den Vorteil, dass ein breites Angebot geschaffen wird, birgt aber zum anderen auch die Gefahr das durch die ungenaue Beschreibung der SDKs ohne Nennung von Profilen nicht das für den Anwendungsfall passende SDK ausgewählt werden kann. Problematisch finde ich, dass es zu manchen Datenmodellen der Kernspezifikation keine korrespondierenden Profile gibt. Somit ist es leider bisher nicht möglich eine zentrale Übersicht aller Profile zu erhalten. Auf der Profile Reporting-Webseite der OPC Foundation findet sich zum Beispiel kein einziges Profil einer Companion Spezifikation. Das erschwert die Verwendung dieser für die SDK-Hersteller. Doch gibt es hier gute Neuigkeiten von Seiten der OPC Foundation, denn die Datenbank wird derzeit überarbeitet: „Mit dieser Neuentwicklung – verfügbar ab etwa Mitte 2021 – werden auch die Profile der Companion Specs erfasst“, so Karl-Heinz Deiretsbacher.

Companion Specifications

Ähnlich zu den SDKs sind auch die Companion Specifications teils sehr unterschiedlich gestaltet, was einem als Außenstehenden den Durchblick erschwert. Grund hierfür ist wohl die große Anzahl verschiedener Beteiligter. Das kann dazu führen, dass Datenstrukturen in verschiedenen CS entworfen werden, die sich funktionell ähneln, aber nicht dieselben Basisklassen verwenden. Um dieser Entwicklung entgegen zu wirken setzt die OPC Foundation Harmonisierungsgruppen ein, welche Datenmodelle in die Kernspezifikation überführt. Ein anderer Punkt sind Datenstrukturen, welche in den CS implementiert sein müssen,  jedoch komplexe Funktionalitäten erfordern, wie der TemporaryFileTransferType oder FiniteStateMachineType. Damit werden prinzipiell SDKs von der Verwendung dieser CS ausgeschlossen, da sie diese Funktionalität nicht beinhalten, ohne dass es klar erkennbar ist (zumindest wenn keine Profile zur Beschreibung verwendet werden). Lösungsansätze sind hierbei wie bereits erwähnt zum einen die Harmonisierungsgruppen und zum anderen werden doppelte Datenstrukturen aus den CS entfernt und in die Kernspezifikation übernommen.

Was kann OPC UA wirklich?

OPC UA bietet ohne Frage zahlreiche Vorteile und ein enormes Potenzial. Der Kommunikationsstandard ermöglicht es OT und IT zu verbinden, ist einfach zu konfigurieren und zu betreiben und zudem dank offenem Schnittstellenstandard herstellerunabhängig. Gegen die aufgeführten Probleme wurden bereits Maßnahmen ergriffen und die OPC Foudation arbeitet kontinuierlich daran alle Schwachstellen auszumerzen. Da zur Zeit viele neue Companion Specifications veröffentlicht werden, ist es nicht (oder nur sehr schwer) zu verhindern, dass die genannten Probleme auftreten. Mit der Zeit und dem zunehmenden Einsatz der CS in produktiven Systemen werden Probleme und Schwierigkeiten schneller identifiziert und Lösungen gefunden. Und gerade durch die derzeit aktive Arbeit an OPC UA von verschiedenen Seiten bin ich mir sicher, dass sich OPC UA weiter durchsetzen wird. Ich bin gespannt, welche Herausforderungen und vor allem Lösungsmöglichkeiten alle Beteiligten hierbei finden werden.