Phoenix Contact unterstützt einheitliches Gerätemodell zur übergreifenden Nutzung

DI-Informationsmodell im OPC-UA-Standard

Anzeige
Bei OPC DI (Device Integration) handelt es sich um ein oft im Automatisierungsumfeld genanntes Informationsmodell, das potenziell unterschätzt wird. Mit der im April 2019 freigegebenen Version 1.02 lassen sich nun auch verschiedene parallele Funktionalitäten auf einem Gerät modellieren. Das eröffnet Vorteile sowohl für die Gerätehersteller als auch Endanwender.

Robert Wilmes, PLCnext-Systemmarketing, Automation Systems, Phoenix Contact Electronics, Bad Pyrmont

Inhaltsverzeichnis

1. Mehrere Standards sind Herausforderung
2. Definition eines ausbaubaren ComponentTypes
3. Offline-Gerätebeschreibung für Devices und deren Funktionalitäten
4. Automatisierungsweltder Zukunft

Als übergreifender Softwarestandard in der Automatisierungstechnik liefert OPC UA mit den Spezifikationen DA (Data Access) und HA (Historical Access) alle digitalen Informationen der Daten über ein objektorientiertes Schema. Gleiches gilt für die A&C (Alarm & Conditions) sowie weitere Spezifikationen. Das DI-Informationsmodell gehört zu den darauf aufbauenden Companion-Standards und wird direkt von der OPC Foundation gepflegt. Es soll die Basis für andere Companion-Standards bilden, wenn diese Geräte modellieren wollen. Zur Integration der realen Hardware in den Namensraum des OPC-UA-Servers wurden mit dem Release der Version 1.02 der OPC-UA-DI-Spezifikation im laufenden Jahr Funktionen ergänzt, die unter anderem die übergreifende Nutzung dieses Standards vereinfachen.

Überall dort, wo die digitale auf die reale Welt trifft, sind Geräte erforderlich, deren Zahl ständig steigt. Zudem werden die Geräte stetig intelligenter und umfassen immer häufiger einen OPC-UA-Server. Viele Anwender haben diese Aussage schon oftmals vernommen. In der Feldbuswelt wurden Themen wie die Adressierung, Identifizierung und Pflege der Geräte feldbusspezifisch gelöst. Bei einer OPC-basierten Lösung sollen die Geräte jedoch unabhängig von ihrer Funktionalität mit einem eindeutigen Namen adressiert und die Anschlusspunkte identifiziert werden können. Hier setzt die DI-Spezifikation an.

Mehrere Standards sind Herausforderung

Die DI-Spezifikation wurde das letzte Mal im Jahr 2014 in der Version 1.01 erweitert. Seinerzeit sind insbesondere Anforderungen aus dem FDI-Standard (Field Device Integration) eingebracht worden. Über das DI-Informationsmodell waren auf diese Weise neben den Geräteeigenschaften auch logische Kommunikationsstrukturen – zum Beispiel zwischen Profinet-Controller und Profinet-Device – abbildbar. Einzelne weitere Companion-Standards – wie das PLCopen- und ADI-Informationsmodell (Analyzer Device Integration) – referenzieren ebenfalls auf die DI-Spezifikation 1.01. In dieser Version stellte es allerdings eine Herausforderung dar, wenn Geräte die Funktionalitäten mehrerer Standards in sich vereinen. Als Beispiel sei eine E/A-Box mit IO-Link-Schnittstelle in Schutzart IP67 angeführt, die gleichzeitig als Profinet-Device fungiert. Hier musste der Anwender zwei unterschiedliche Geräte in einer Geräteliste verwalten.

2017 hat sich die OPC Foundation daher entschlossen, eine Erweiterung der DI-Spezifikation anzugehen. Die Mitglieder haben in großer Runde Use Cases erarbeitet und deren Ziele definiert. 2018 wurden dann verschiedene Ergänzungen spezifiziert sowie Teile der Use Cases auf andere Arbeitsgruppen verlagert. So ist die sichere Inbetriebnahme eines Geräts mit dem erstmaligen Rollout von Zertifikaten an die Security-Gruppe übergeben worden.

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

www.phoenixcontact.de

Weitere Details

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

https://t1p.de/j777

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


PLUS

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.

Anzeige

Festo: Digitalisierung

Smartenance

Die Digitalstrategie von Festo im Überblick

Schlagzeilen

Video aktuell

Oliver Vogel, Team Leader Commercial Engineering bei Rockwell Automation GmbH erläutert das Besondere an Engineeringtools und welchen Vorteil Maschinenbauer davon haben

Aktuelle Ausgabe

Titelbild elektro AUTOMATION 11
Ausgabe
11.2019
LESEN
ARCHIV
ABO

Newsletter

Jetzt unseren Newsletter abonnieren

Webinare & Webcasts

Technisches Wissen aus erster Hand

Automation Award

Automation Award 2019
Die Besucher der SPS wählen während der Messe Ihre Favoriten! Nominierte Produkte…

Videos

Hier finden Sie alle aktuellen Videos

Whitepaper

Hier finden Sie aktuelle Whitepaper

Anzeige
Anzeige

Industrie.de Infoservice

Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de