Structured DataTypes in OPC UA

Die Grenzen technologischer Zumutbarkeit?

Im Meta-Modell von OPC UA sind DataTypes eine der acht NodeClasses. Instinktiv ist klar, was Datentypen sind: Jeder denkt dabei an die primitiven Datentypen der bekannten Programmiersprachen – Integer, String, Byte, Float. Großer Beliebtheit erfreuen sich auch die Datentypen für das Datenaustauschformat XML, die als Teil der bekannten Parser-Bibliotheken in die jeweilige Sprache übersetzt werden und sich deshalb vor allem für Schnittstellen gut eignen.

OPC UA legt Wert auf Erweiterbarkeit – sowohl für spätere Standardisierungsaktivität als auch für Anwender. Schließlich gibt es Anwendungsfälle, die mächtigere Datenstrukturen erfordern – komplexe Datentypen, OPC UA nennt sie Structures. Ein naheliegendes Beispiel ist die EUInformation (EU ≙ EngineeringUnit). VariableNodes mit diesem DataType hängen in der Regel als Property an anderen Variablenknoten, um anzuzeigen, in welchen Einheiten eine Mess- oder Stellgröße modelliert ist. Hier das Beispiel für den AnalogItemType:

Diese Informationen gehören zusammen und bekommen erst durch ihren Bezug aufeinander einen Sinn. Deshalb gibt es mit den strukturierten DataTypes eine Kopplung zwischen Werten, die noch enger ist als einem Objekt- oder Variablenknoten eine Menge einzelner Variable-Nodes anzuhängen, wie untenstehend dargestellt. Beides kann sinnvoll sein, die Use-Cases unterscheiden sich aber nur in Nuancen.

Obwohl die Modellierung mit Properties zunächst komplexer aussieht, kommt sie ohne eigens definierten Structured DataType aus. Welche “Overhead”-Knoten für dessen Verarbeitung notwendig wären, hat sich mit dem Release von v1.04 im Jahr 2018 geändert. Vorher wie hinterher brauchen Clients Informationen, wie sie die Nachricht dekodieren sollen, wenn ein Server einen eigenen Structured DataType nutzt. Diese Anleitung findet der Client in einem Zusammenspiel von anderen Nodes im AddressSpace.

Der SDK-Hersteller Unified Automation hat eine sehr gut verständliche Übersicht erarbeitet, was sich en detail technologisch verändert hat. Die Dekodierung über ein DataTypeDictionary (v1.03) war komplex und die Dekodierung über DataTypeDescriptions (v1.04) ist ein bisschen weniger komplex. Clients und Server können allerdings jeweils nicht damit rechnen, dass ihr Gegenüber bereits nach der neuen v1.04 arbeitet. Also implementieren sie beides. Es wird also sehr komplex. Folglich ist schon die Entscheidung zur Einführung von eigenen strukturierten DataTypes auf der Client-Seite keine Triviale und sollte gut abgewogen werden.

Dieser Beitrag ist ein Teil der Serie zu OPC UA auf dem Blog #kognitiveproduktion des Fraunhofer IWU.

Headerbild: Structure von matsuyuki ist lizensiert nach CC BY-SA 2.0