DI-Informationsmodell im OPC-UA-Standard

Definition eines ausbaubaren ComponentTypes

Im ersten Schritt beschäftigte sich die DI-Arbeitsgruppe schließlich mit der Adressierung der Geräte sowie einem Konzept, wie die unterschiedlichen parallelen Funktionalitäten auf einem Gerät modelliert werden können. Statt eines DeviceTypes wurde nun ein ComponentType definiert, der sich durch Interfaces vom Typ BaseInterfaceType ausbauen lässt. Als beispielhafte Interfaces in der Spezifikation seien die Informationen zum Gerätehersteller oder -namen genannt. Diese Daten sind in vier verschiedenen Interfaces zusammengefasst worden: herstellerbezogene Informationen, anwenderspezifische Informationen, Statusinformationen und erweiterte Support-Dokumentation. Das Interface zum VendorNameplate enthält sämtliche klassischen 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 Fehlerklasse meldet. Im April 2019 wurde das DI-Informationsmodell in der Fassung 1.02. schließlich releast, da andere Standards darauf aufbauen wollten.

Offene geblieben waren die Use Cases zur Netzwerkbeschreibung, die jedes Ethernet-basierte Gerät besitzt. Hier wurde der Entschluss gefasst, die Basis-Spezifikation im Part 5 der OPC-Spezifikation zu ergänzen, in dem auch der UA-Server beschrieben ist. Dieser Teil befindet sich derzeit über ein Amendment noch in der Spezifikationsphase. Darüber hinaus sind Funktionalitäten für den Use Case eines übergreifenden Device Managements auf eine kommende DI-Spezifikationsversion verschoben worden. Dazu gehören Funktionen, die auf einen einheitlichen Update-Prozess für Software und Firmware abzielen. Diese Erweiterung steht aktuell schon im Review und ist dann ebenfalls kurzfristig verfügbar.

Offline-Gerätebeschreibung für Devices und deren Funktionalitäten

Jetzt gilt es, dass möglichst viele Informationsmodelle direkt auf DI aufsetzen sowie bestehende Modelle entsprechend umgestellt werden. Je mehr Informationsmodelle DI nutzen, desto größer wird dessen Stellenwert. Dies hat den Vorteil, dass die Hersteller lediglich eine Abbildungsvorschrift in ihre Geräte implementieren. 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, in der momentan mehr als 20 Hersteller einen einheitlichen, deterministischen Kommunikationsstandard erarbeiten, der auf dem Publisher-/Subscriber-Modell von OPC UA und den IEEE 802-Funktionen zu Time-Sensitive-Networking (TSN) basiert. Dabei werden die Anforderungen von Motion-Control- bis zu prozesstechnischen Applikationen berücksichtigt. In Zukunft sollen mit Hilfe von LC die Gerätehersteller so nur noch ein OPC-Gerätemodell unterstützen, lediglich einen Security-Ansatz pflegen sowie allenfalls 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 auch hier einer der favorisierten Ansätze. Eine weitere Aktivität, welche die Mitglieder der FLC-Initiative angehen, fokussiert sich auf die Offline-Gerätebeschreibung für Devices und ihre Funktionalitäten, so wie es heutige Feldbussysteme bereits zur Verfügung stellen. In der Engineering- und Projektierungsphase verknüpfen Anwender also Variablen aus den Programmen und Visualisierungen direkt mit den Datenobjekten der Geräte und füllen Geräteparameter. Je näher dieser Vorgang am DI-Modell passiert, desto mehr wird das DI-Informationsmodell aufgewertet und die Rolle einnehmen, die es schon immer anvisiert hatte: die Technologie-übergreifende und Hardware-orientierte Sicht in einem OPC-Server auf alle Geräte in der Automatisierungslösung inklusive der Kommunikationsnetze und zentraler Einstiegspunkt für die integrierten Funktionalitäten. ge

Phoenix Contact beteiligt sich in OPC-UA-Initiative zur Standardisierung der industriellen Kommunikation

Phoenix Contact Deutschland GmbH Flachsmarktstraße 8 32825 Blomberg Deutschland Tel. +49 52 35/3-1 20 00 Fax. +49 52 35/3-1 29 99 info@phoenixcontact.de

Automatisierungsweltder Zukunft

Die Vision der grenzenlosen, aber auch echtzeitfähigen Kommunikation über alle Netzwerke wird lediglich dann wahr, wenn Geräte, Datenübertragung und die Funktion konsequent voneinander getrennt werden. Nur so lassen sich Kommunikationswege flexibel anpassen und Funktionen in die Cloud verlagern. Damit diese drei Einheiten trotzdem verlässlich in einem Netzwerk zusammenspielen, müssen in der heterogenen Automatisierungslandschaft viele Unternehmen bei den genutzten Geräte-, Kommunikations- und funktionalen Standards kooperieren, sodass die Komplexität des Gesamtsystems nicht überhandnimmt. Für einen mittelständisch geprägten Komponentenhersteller ist diese Standardisierung sehr wichtig. Deshalb engagiert sich Phoenix Contact in vielfältigen Arbeitsgruppen zu Kommunikationstechnologien – wie der OPC Foundation, 5G ACIA oder Profibus & Profinet International –, bei funktionalen Organisationen wie OPAF (Open Process Automation Forum), Namur und insbesondere der Field Level Initiative (FLC) in der OPC Foundation, um hier gemeinsame übergreifende Standards zu erarbeiten, die nicht nur den Anlagen-/Maschinen- und Gerätebauern eine klare Spezifikation geben, sondern dem Nutzer ebenfalls zahlreiche Vorteile bringen.