OPC UA-Standard Einer für alles

Viele verschiedene Standards in der Automatisierung lassen sich mit dem OPC UA-Standard einfacher anwenden.
Viele verschiedene Standards in der Automatisierung lassen sich mit dem OPC UA-Standard einfacher anwenden.

Für Anwendungen in der Automatisierung gibt es viele verschiedene Standards. Entwickler von Geräten müssen oft mühsam mehrere Codes zusammenführen. Mit einer neuen Version des OPC UA-Standards soll das einfacher werden.

Bei OPC DI (Open Platform Communications Device Integration) handelt es sich um ein Informationsmodell, das meist im Automatisierungsumfeld zum Einsatz kommt und oft unterschätzt wird. Mit der im April 2019 freigegebenen Version 1.02 lassen sich verschiedene, parallele Funktionen auf einem Gerät modellieren. Das hat sowohl für den Gerätehersteller als auch den Endanwender Vorteile. Als übergreifender Softwarestandard in der Automatisierungstechnik liefert OPC UA mit den Spezifikationen DA (Data Access) und HA (Historical Access) alle digitalen Informationen der Daten. Das geschieht über ein objektorientiertes Schema. Gleiches gilt für A&C (Alarm & Conditions)- sowie weitere Spezifikationen. Das DI-Informationsmodell gehört zu den Companion-Standards, baut auf dem DA- und HA-Standard auf und wird direkt von der OPC Foundation gepflegt. Für andere Companion-Standards bildet es die Basis zum Modellieren von Geräten. Um einfacher Hardware in den OPC UA-Server zu integrieren, gibt es ab der Version 1.02 neue Funktionen.

In der Industrie kommen immer mehr intelligente Geräte mit einem OPC UA-Server zum Einsatz. In der Feldbus-Ebene wurden Themen wie das Adressieren, das Identifizieren und die Pflege der Geräte spezifisch gelöst. Bei einer Anwendung auf OPC-Basis sollen die Geräte jedoch unabhängig von ihrer Funktion mit einem eindeutigen Namen adressierbar und die Anschlusspunkte identifizierbar sein. An diesem Punkt setzt die DI-Spezifikation an (Bild 1).

Verwaltung von multifunktionalen Geräte aufwendig

Das vorletzte Update der DI-Spezifikation war 2014 die Version 1.01. Inhalt des Updates war das Einbringen von Anforderungen aus dem FDI (Field Device Integration)-Standard. Über das DI-Informationsmodell waren damit neben den Geräteeigenschaften auch logische Kommunikationsstrukturen abbildbar, zum Beispiel zwischen Profinet Controller und Profinet Device. Weitere Companion-Standards – wie das PLCopen- und ADI (Analyzer Device Integration)-Informationsmodell – beziehen sich ebenfalls auf die DI-Spezifikation 1.01. Eine Herausforderung der Version war es, wenn mehrere Standards in einem Gerät vereint sind. Als Beispiel dient eine Eingabe/Ausgabe-Box mit einer Input/Output (I/O)-Link-Schnittstelle in Schutzart IP67, die gleichzeitig als Profinet Device fungiert. Die Schwierigkeit: Der Anwender musste zwei unterschiedliche Geräte in einer Geräteliste verwalten (Bild 1).

2017 hat die OPC Foundation daher beschlossen, die DI-Spezifikation zu erweitern. Die Mitglieder erarbeiteten »Use Cases«, also Anwendungsfälle, und definierten die Ziele dafür. Bereits 2018 wurden erste Ergebnisse präsentiert: Verschiedene Ergänzungen wurden spezifiziert sowie Teile der Anwendungsfälle auf andere Arbeitsgruppen verlagert. So wurde die sichere Inbetriebnahme eines Geräts mit dem erstmaligen Rollout von Zertifikaten an die Security-Gruppe übergeben.

Verschiedene Interfaces nötig

Im ersten Schritt beschäftigte sich die DI-Arbeitsgruppe mit dem Adressieren der Geräte sowie einem Konzept zum Modellieren von unterschiedlichen parallelen Funktionen auf einem Gerät. Statt eines »Device Types« wurde ein »Component Type« definiert, der sich mit einem Interface vom Typ »BaseInterfaceType« ausbauen lässt. Als Beispiel für ein Interface in der Spezifikation seien die Informationen zum Gerätehersteller oder -namen angeführt.

Die Daten wurden in vier verschiedenen Interfaces zusammengefasst: herstellerbezogene Informationen, anwenderspezifische Informationen, Statusinformationen und erweiterte Support-Dokumentation. Das Interface zum »VendorNameplate« enthält sämtliche klassische Informationen, die der Hersteller seinem Gerät mitgibt. Mit dem Interface »TagNameplate« lassen sich anlagenbezogene Gerätenamen als String ablegen. Ähnlich einer Sammelfehlermeldung gibt das Interface »DeviceHealth« aus, ob das Gerät fehlerfrei arbeitet oder eine bestimmte Fehler klasse meldet (Bild 2).

Im April 2019 wurde das DI-Informationsmodell in der Fassung 1.02. schließlich veröffentlicht, da andere Standards darauf aufbauen wollten (Bild 3).

 

Offen blieben die Anwendungsfälle zur Netzwerkbeschreibung, die jedes Ethernet-basierte Gerät besitzt. Hierbei wurde der Entschluss gefasst, die Basis-Spezifikation im Teil 5 der OPC-Spezifikation zu ergänzen, in dem ebenfalls der UA-Server beschrieben ist. Der Teil befindet sich derzeit noch in der Spezifikationsphase. Außerdem wurden Funktionen für den Anwendungsfall eines übergreifenden Device Managements auf eine kommende DI-Spezifikationsversion verschoben. Dazu gehören Funktionen, die auf einen einheitlichen Update-Prozess für Software und Firmware abzielen. Aktuell steht die Erweiterung in der Review-Phase und ist ebenfalls in Kürze verfügbar.

Einheitliches Asset Management

Nun gilt es, möglichst viele Informationsmodelle direkt auf DI aufzusetzen sowie bestehende Modelle entsprechend umzustellen. Je mehr Informationsmodelle DI nutzen, desto größer wird dessen Stellenwert. Das hat den Vorteil, dass die Hersteller lediglich eine Abbildungsvorschrift in ihre Geräte einbauen müssen. Endanwender können beispielsweise Geräte aus unterschiedlichen Systemen in einem einheitlichen Asset Management zusammenfassen. Ein aktuelles Beispiel ist die Fieldlevel Communication Initiative (FLC) der OPC Foundation. Darin erarbeiten mehr als 20 Hersteller einen einheitlichen, deterministischen Kommunikationsstandard. Er basiert auf dem Publisher-/Subscriber-Modell von OPC UA und den IEEE-802-Funktionen zu Time Sensitive Networking (TSN). Es werden Anforderungen von Motion-Control- bis zu prozesstechnischen Anwendungen berücksichtigt. In Zukunft sollen mithilfe von FLC die Gerätehersteller nur noch ein OPC-Gerätemodell unterstützen. Außerdem sollen sie lediglich einen Security-Ansatz pflegen sowie ein Safety-Protokoll einbinden. Endanwender können mit sämtlichen Teilnehmern selbst über Netzwerkgrenzen hinweg – bis in die Cloud – Daten austauschen.

Da die FLC-Initiative bestehende Standards nutzen möchte, ist die DI-Spezifikation einer der favorisierten Ansätze. Eine weitere Aktivität der Mitglieder der FLC-Initiative fokussiert sich auf die Offline-Gerätebeschreibung für Devices und ihre Funktionen. Heutige Feldbussysteme stellen das bereits zur Verfügung. In der Engineering- und Projektierungsphase verknüpfen Anwender Variablen aus den Programmen und Visualisierungen direkt mit den Datenobjekten der Geräte und füllen Geräteparameter. Je näher der Vorgang am DI-Modell passiert, desto mehr wird es aufgewertet und die Rolle einnehmen, die es schon immer anvisiert hatte: Die technikübergreifende und Hardware-orientierte Sicht in einem OPC-Server auf alle Geräte in der Automatisierungstechnik zu übertragen.

 

Der Autor

Robert Wilmes

studierte Maschinenbau an der RWTH Aachen und begann 1994 seine berufliche Laufbahn als freiberuflicher Programmierer. Seit 1996 ist er bei Phoenix Contact, hier war Wilmes zunächst im Produktmarketing als Produktmanager tätig. Seit 2004 ist er im Systemmarketing in der Business Unit Automation Systems schwerpunktmäßig für die Themen Profinet und OPC UA zuständig.