Die Taktstraße in Kombination mit dem OPC UA Server wurde in vorherigen Blogposts schon beschrieben. Dabei werden die Daten von der Steuerung Siemens SIMATIC S7-1500 zur Verfügung gestellt und vom OPC UA Server bezogen, um diese Daten dann wiederum nach IoT Central in der Cloud zu liefern.
In diesem Blogpost soll es darum gehen, wie ein Client die Daten konsumieren kann und woher er die Informationen bekommt welche Daten auf dem OPC UA Server zur Verfügung stehen. Diese Informationen werden über die sogenannte Companion Specification definiert.
Die Companion Specification definiert, wie der Adressraum des OPC UA Servers dargestellt wird und ist für einen OPC UA Client essentiell wichtig. In der Companion Specification werden die Knoten, die dazugehörigen Typen, Methoden und Events definiert, welche nach Außen für die Clients zur Verfügung stehen.
Dabei handelt es sich in der Regel nicht nur um eine einfache Beschreibung des Adressraums, sondern um einen allgemeingültigen Standard in der Industrie, auf den sich die unterschiedlichen Hersteller geeinigt haben. Als Beispiel sei hierbei die EUROMAP 77 genannt, welche ein verbindliches Dokument für alle teilnehmenden Hersteller von Spritzgussmaschinen ist und genau definiert, welche Daten jede Maschine zur Verfügung stellen muss und welche Daten optional sind.
Die Definition einer Companion Specification basiert dabei auf der OPC UA Specification und ist kein zu unterschätzender Prozess, denn dabei geht es darum, die Interessen unterschiedlichster Hersteller in einem Dokument zu vereinen und gleichzeitig einen möglichst großen Nutzen für den Konsumenten der Daten zu erzielen. Besonders die Fälle, wenn eine Maschine bestimmte Informationen zur Verfügung stellen muss, aber dies zum momentanen Zeitpunkt nicht möglich ist oder wenn Konkurrenten versuchen ihre eigenen Interessen zu vertreten, führen zu Problemen beim Festlegen einer Companion Specification.
Abbildung 1 Zusammenarbeit und Kommunikation
Meistens besteht der Adressraum eines OPC UA Servers dabei nicht nur aus einer, sondern mehreren Companion Specifications, welche sich gegenseitig referenzieren und in unterschiedliche Namespaces im OPC UA Server definiert werden. Die Namespaces stellen dabei sicher das die Knoten im Server eindeutig zuzuordnen sind und bei identischen Knoten von unterschiedlichen Companion Specifications unterschieden werden können.
Das Dokument der Companion Specification definiert zwar wie der Adressraum auszusehen hat, jedoch fehlt dazu dann noch der technische Gegenpart auf Seite des OPC UA Servers. Diese Umsetzung wird zwangsläufig für den Server gebraucht damit er weiß wie er sich darstellen muss und gleichzeitig für die Clients, da sie sich die Companion Specification vom Server holen und somit wissen welche Informationen zur Verfügung stehen.
Die Wege zum Umsetzen der Companion Specification sind dabei vielseitig und lassen sich meistens durch vorhandene Software vereinfachen. Ein Beispiel für die Umsetzung beim OPC UA Server der OPCFoundation wäre z.B. der UA-ModelCompiler, welcher anhand einer definierten Designfile auf Basis der Companion Specification die technischen Komponenten für den Server automatisch erzeugt. Diese Umsetzung geschieht dabei meistens Hersteller unabhängig, während es natürlich notwendig ist das die gemeinsam definierte Companion Specification eingehalten wird.
Wer sich genauer für das Thema OPC UA Interessiert, kann dieses in einem vorherigen Blogpost „IoT Zum Anfassen – OPC UA“ und im Artikel „OPC UA In Der Praxis – Die Lücke Schließen“ aus der dotnetpro 05-2018 nachlesen.
Sprechen Sie uns an, wenn auch Sie Hilfe bei der Planung, Einführung oder Umsetzung von IoT und Industrie 4.0 in Ihrem Unternehmen benötigen. Wir führen Sie gerne ans Ziel.
Sie möchten mehr zum Thema IoT erfahren? Besuchen Sie doch unseren kostenlosen Workshop „IoT in a day – Von Null auf Cloud in einem Tag“ oder buchen Sie unseren zweitägigen IoT Proof of Concept-Workshop.