So lässt sich der OPC-UA-Standard standardisieren

Modelle formen die Maschinensprache

Der Datenaustausch-Standard OPC UA ist aus vielen Bereichen der Automatisierungstechnik nicht mehr wegzudenken. 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 Wörtern oder ganzen Sätzen zusammengesetzt werden, ist jedoch in den sogenannten Companion-Standards respektive Informationsmodellen beschrieben.
Bild: ©funtap/shutterstock.com

Als Pendant bei den Feldbussystemen fungieren die Profile. Sie sind hauptsächlich entstanden, um eine Auswechselbarkeit der Geräte sicherzustellen. In der OP-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 mehrere Informationsmodelle beinhalten. So lässt sich ein Informationsmodell mit einer spezifischen Sicht auf ein Gerät oder eine Anlagenfunktion vergleichen. Im Laufe der Jahre sind zahlreiche Informationsmodelle erarbeitet worden. Als Beispiel seien Metamodelle genannt, die nur Regeln aufstellen, wie etwas festgelegt wird. Andere Modelle stellen dar, wie Maschinen- und Anlagentypen abgebildet werden. Weitere Modelle beschäftigen sich mit der Beschreibung von Bussystemen, Branchen und Applikationen über OPC UA.

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 mit ihren Eigenschaften, egal von welchem Typ (z.B. Antrieb oder Encoder) diese sind. Das DI-Informationsmodell fokussiert sich dabei auf Asset-Informationen sowie allgemeine Diagnose-, Software-Update- oder Parametrierfunktionen. 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 1.500 Byte Nutzdaten gemäß dem 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.

 OPC-UA-Server-Informationsmodelle liefern oftmals spezifische 
Sichten für die verschiedenen Client-Applikationen.
OPC-UA-Server-Informationsmodelle liefern oftmals spezifische Sichten für die verschiedenen Client-Applikationen.Bild: Phoenix Contact Deutschland GmbH

Herausforderung für die Steuerungen

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, u.a. 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, XML-basierte Format lässt sich in einen OPC-Server importieren, und der Server übernimmt dann die Objekte in seinen Namensraum.

 Im OPC-UA-Server instanziierte Objekte aus den verschiedenen Sichten werden mit den realen anwendungs- oder gerätespezifischen Werten verknüpft.
Im OPC-UA-Server instanziierte Objekte aus den verschiedenen Sichten werden mit den realen anwendungs- oder gerätespezifischen Werten verknüpft.Bild: Phoenix Contact Deutschland GmbH

Server-Funktionen dank interner Informationsmodelle

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 IEC62443 ausgerichtet wurde.

Der Server unterstützt die wesentlichen Datentypen inklusive mehrdimensionaler Arrays. Funktional können Objektinformationen gelesen, geschrieben sowie subscribed – 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.

 Die links an die PLCnext Control anreihbare Baugruppe AXC F XT SPLC 1000 erweitert die Lösung um einen dezentralen Sicherheitskreis.
Die links an die PLCnext Control anreihbare Baugruppe AXC F XT SPLC 1000 erweitert die Lösung um einen dezentralen Sicherheitskreis.Bild: Phoenix Contact Deutschland GmbH

Nodeset-Editor erstellt Instanzen

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 Namespace-Array übernommen.

Seiten: 1 2Auf einer Seite lesen

Phoenix Contact Deutschland GmbH

Das könnte Sie auch Interessieren