Der Companion-Standard von OPC UA in der Automation

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

ISH Ingenieursozietät GmbH

Beta LAYOUT GmbH

Phoenix Contact GmbH & Co. KG

Informationsmodelle bilden die Gesamtheit aller Geräte bzw. Anlagenteile ab. Das aber kann zu vielen Modellen pro Gerät oder Anlagenteil führen. Wie diese Komplexität beherrschbar wird, zeigt der Artikel.

Der Datenaustausch-Standard OPC UA ist in vielen Bereichen der Automatisierungstechnik fester Bestandteil. Dabei wird stets das Beispiel der gemeinsamen Sprache propagiert. Bei genauerer Betrachtung definiert OPC UA die Übertragungswege und die Buchstaben in der Kommunikation. Wie die Buchstaben zu sinnvollen Wörtern oder ganzen Sätzen zusammengesetzt werden, das ist jedoch in den sogenannten Companion-Standards respektive Informationsmodellen beschrieben.

Als Pendant bei den etablierten Feldbussystemen fungieren die Profile. Diese sind hauptsächlich entstanden, um eine bessere Auswechselbarkeit der Geräte sicherzustellen. In der OPC-UA-Welt geht es hingegen um mehr: Der Datenaustausch-Standard zielt darauf ab, die Gesamtheit aller Geräte und Anlagen mit Hilfe der Informationsmodelle abzubilden. Ein Gerät oder Anlagenteil kann auch mehrere Informationsmodelle beinhalten. Auf diese Weise lässt sich ein Informationsmodell mit einer spezifischen Sicht auf ein Gerät oder eine Anlagenfunktion vergleichen. Im Laufe der Jahre sind zahlreiche unterschiedliche Informationsmodelle erarbeitet worden. Als Beispiel seien Metamodelle genannt, die lediglich Regeln aufstellen, wie etwas festgelegt wird. Andere Modelle stellen dar, wie Maschinen- und Anlagentypen, beispielsweise Verpackungs- oder Spritzgießmaschinen, abgebildet werden. Weitere Modelle beschäftigen sich mit der Beschreibung von Bussystemen, Branchen und Applikationen über OPC UA.

Bildergalerie

Das DI-Informationsmodell (OPC UA for Devices 10000-100) der OPC Foundation bietet eine wichtige Sicht auf Geräte oder Assets. Es beschreibt einzelne Geräte in ihren Eigenschaften, egal welchen Typs diese sind – zum Beispiel Antrieb oder Encoder. Das DI-Informationsmodell fokussiert sich dabei auf Asset-Informationen sowie allgemeine Diagnose-, Software-Update- oder Parametrier-Funktionen. Deshalb wird es von vielen anderen Informationsmodellen referenziert. Die vor kurzem freigegebene Spezifikation OPC UA Safety (OPC 10000-15) legt dar, wie sich sicherheitsgerichtete Informationen mit bis zu 1500 Byte Nutzdaten gemäß Consumer/Producer-Prinzip als Black-Channel-Ansatz via OPC UA übertragen lassen. Dieses Informationsmodell, das nur die eigentliche Safety-Kommunikation umfasst, wird in Zukunft ebenfalls von weiteren Informationsmodellen oder Companion-Standards referenziert werden. Letztendlich können die Endanwender eigene private Informationsmodelle zusammenstellen, in denen ihre zu überwachenden Geräte und Anlagen abgebildet sind. An dieser Stelle wird bereits deutlich, wie komplex sich die Sammlung von Informationsmodellen in einer Anlage gestalten kann (Bild 1).

Flexibilität der Steuerung auf OPC UA übertragen

Bei den Companion-Standards, die in verschiedenen Organisationen entstehen, ist schnell klargeworden, dass nicht jedes Modell das Rad neu erfinden darf. Dementsprechend wurde in der OPC Foundation eine eigene Arbeitsgruppe gegründet, die übergreifende Gemeinsamkeiten oder Best-Practice-Anwendungen herausarbeitet. Als Beispiel seien die Aktivitäten der Base- Model-Sub-Gruppe angeführt, die Informationen rund um das Ethernet-Interface standardisiert. Außerdem hat der VDMA, der an zahlreichen Standards arbeitet oder diese schon freigegeben hat, unter anderem ein allgemeineres Maschinenmodell definiert, das auf andere Maschinentypen übertragen werden kann.

Aufgrund der vielfältigen, kaum noch überblickbaren Aktivitäten der vielen Arbeitsgruppen kommt eine besondere Herausforderung auf frei programmierbare Steuerungen zu. Die SPS weiß im ersten Schritt nicht, welche Steuerungsfunktion sie zukünftig in der jeweiligen Applikation übernehmen soll. Ferner ist ihr nicht bekannt, welche Informationsmodelle abzubilden sind. Zudem legt ein Informationsmodell lediglich die Typen fest. Die Instanzen entstehen erst bei der Nutzung des Modells. Daher muss die Flexibilität der SPS auf das für die externe Kommunikation vorgesehene Interface, also OPC UA, transformiert werden. Das bedeutet, dass ein in die Steuerung integrierter OPC UA-Server vom Applikationsprogrammierer um zusätzliche Informationsmodelle zu erweitern ist. Neben dem typbasierten Informationsmodell müssen aus Sicht der SPS darüber hinaus die Instanzen generiert, die optionalen Anteile des Modells ausgewählt sowie die Verknüpfung zum realen Prozess hergestellt werden. Hier kommt das Offline-Beschreibungsformat eines OPC-Servers, die sogenannte Nodeset-Datei, zum Einsatz. Das standardisierte und XML-basierte Format lässt sich in einen OPC-Server importieren, und der Server übernimmt dann die Objekte in seinen Namensraum (Bild 2).

Server-Funktionen in internen Informationsmodellen

Das beschriebene Verfahren soll an einer PLCnext-basierten Steuerung verdeutlicht werden. Der in die PLCnext Control eingebaute OPC UA-Server beinhaltet erstmals alle wichtigen Grundfunktionen eines Servers. Er fungiert als abgesicherte Kommunikationsschnittstelle zu anderen externen Prozessen. Zu diesem Zweck ist der Server tief in das Security-Konzept der PLCnext-Steuerung integriert, welches von Anfang an auf die Einhaltung der internationalen Security-Norm IEC 62443 ausgerichtet wurde.

Der Server unterstützt die wesentlichen Datentypen inklusive mehrdimensionaler Arrays. Funktional können Objektinformationen gelesen, geschrieben sowie subscribed werden, also bei einer Änderung abonniert werden. Der OPC UA-Server supportet Methoden, mit denen sich ganze Parametersätze konsistent übergeben lassen. Im Rahmen der A&C-Spezifikation (OPC UA Alarm and Conditions) können Alarme direkt über Alarmbausteine aus dem Steuerungszyklus ausgelöst werden. Außerdem umfasst die PLCnext-Steuerung eine Datalogger-Funktion, auf deren Daten der Anwender über OPC UA via HDA (Historical Data Access) zugreifen kann. Ferner ist die Möglichkeit der Dateizugriffe auf einen Teil des Steuerungsspeichers über OPC UA File Access implementiert worden. Sämtliche angeführten Server-Funktionen stehen in automatisch eingebauten internen Informationsmodellen zur Verfügung. Sie werden über das Programmierwerkzeug PLCnext Engineer und die OPC-Konfiguration von Variablen gefüllt.

Projekt und Instanz-Nodeset-Datei bei Änderungen

Für ihre Erweiterung um Informationsmodelle muss die Steuerung somit die zusätzlich zu unterstützenden externen Informationsmodelle kennen. Bei einer PLCnext Control werden dazu einfach die neuen Nodeset-Dateien der Companion-Standards in ein spezifisches Verzeichnis auf der Steuerung kopiert. Der in die SPS integrierte OPC UA-Server liest dieses Verzeichnis beim Neustart ein und stellt zudem alle neuen Typen und Instanzen im vorhandenen Namensraum dar. Auf diese Weise sind nach der Initialisierung des Servers automatisch sämtliche Informationsmodelle in das Name Space Array übernommen.

Zur Erstellung der Instanzen im Namensraum des Servers hat es sich bewährt, einen OPC UA Nodeset-Editor zu verwenden, der mit den unterschiedlichen Modellen und Referenzen umgehen kann. In dieser Instanz-Nodeset-Datei erfolgt die Auswahl der optionalen Anteile des Modells sowie die Verknüpfung mit einer Variablen, Datei oder Funktion in der Steuerung. Die Referenzen bestehen aus sogenannten XML-Extensions in der Nodeset-Datei, die eine direkte Verknüpfung auf die Variable oder Funktion in der Steuerung beinhalten. Um ein externes Informationsmodell mit Leben zu füllen, muss sich der Programmierer folglich mit dem Companion-Standard, seiner konkreten Applikation sowie dem Lesen und Schreiben von Nodeset-Dateien auseinandersetzen. Als größte Herausforderung erweist sich heute, sowohl das Projekt als auch die Instanz-Nodeset-Datei bei Änderungen konsistent zu halten.

Informationsmodelle vereinheitlichen

Die OPC-UA-Basismechanismen werden ständig weiterentwickelt. Auf deren Funktion setzen immer mehr Companion-Spezifikationen oder applikationsspezifische Informationsmodelle auf. Dabei gilt es die Generierung von verschiedenen Informationsmodellen für ähnliche Funktionen zu verhindern, damit sich die Projektierung ebenso auf Seiten der OPC UA Clients vereinfacht. Die Vereinheitlichung von Informationsmodellen zeigt sich also als wichtiges Ziel für die Zukunft. Unabhängig von diesen Standardisierungsansätzen muss eine frei programmierbare Steuerung jedes externe Informationsmodell nachladen können – und das ergänzend zu den eingebauten internen Modellen. Bilden sich bei der Standardisierung von Informationsmodellen Standards heraus, reduziert das die projektspezifischen Aufwände in der Steuerung und, nicht zu vergessen, damit automatisch auch auf der Client-Seite.

* * Robert Wilmes ... ist Mitarbeiter im PLCnext Systemmarketing der Business Unit Automation Systems bei Phoenix Contact Electronics, Bad Pyrmont.

(ID:47603219)