RTI verkündet OMG-Adoption des OPC UA/DDS Gateway Standards

Die Integration diverser Konnektivitätslösungen und Standards bleibt eine Top-Hürde für Systemdesigner und Integratoren, die komplexe Industrial-IoT-Ökosysteme bauen.

RTI treibt die Industrial-IoT-Revolution voran, indem es standardisierte Konnektivitäts-Gateways schafft, die DDS-Systeme nahtlos mit anderen Kern-Frameworks interoperabel machen. Dieses Jahr haben wir ein Standard OPC UA/DDS Gateway eingeführt – eine Brücke zwischen zwei der prominentesten Kommunikationsprotokolle der Branche – und freuen uns, dessen kürzliche Adoption durch die Object Management Group (OMG) bekanntzugeben.

OPC UA/DDS Gateway Spezifikation

In einer gemeinsamen Initiative zwischen OMG und OPC Foundation wurde die Kollaboration zu DDS- und OPC-UA-Konnektivitätsstandards letztes Jahr angekündigt. Daraufhin veröffentlichte die OMG ein RFP für ein Standard OPC UA/DDS Gateway, um transparente Interoperabilität zwischen DDS- und OPC-UA-Applikationen zu ermöglichen. RTI antwortete mit einem umfassenden 140-Seiten-Vorschlag, der Feedback von DDS- und OPC-UA-Nutzern und -Anbietern einbezog, der auf dem March OMG Technical Meeting genehmigt wurde. Dieser Artikel bietet einen knappen Überblick der Spezifikation und zeigt die Prototypen, die wir zur Validierung gebaut haben.

Spezifikations-Überblick

Die OPC UA/DDS Gateway Spezifikation zielt darauf ab, DDS- und OPC-UA-Applikationen nahtlos interoperabel zu machen, indem sie die nativen Mechanismen jedes Frameworks nutzt. Sie adressiert zwei Kernherausforderungen:

• Aufbau einer OPC-UA-zu-DDS-Brücke, die DDS-Applikationen erlaubt, innerhalb des AddressSpace eines OPC-UA-Servers zu operieren, باستخدام DDS Publish-Subscribe und RPC-Fähigkeiten.
• Aufbau einer DDS-zu-OPC-UA-Brücke, die OPC-UA-Client-Applikationen als First-Class-Citizens im DDS Global Data Space über Standard-OPC-UA-Services agieren lässt.

Abbildung 1: OPC UA/DDS Gateway Konzept

OPC UA zu DDS Bridge

Die OPC UA zu DDS Bridge erlaubt DDS-Applikationen, Daten innerhalb des AddressSpace eines OPC UA Servers zu lesen, zu schreiben und zu abonnieren. Diese Funktionalität ist kritisch für die Integration OPC-UA-fähiger Geräte in Systeme, die DDS-Skalierbarkeit und QoS-Features erfordern. Abbildung 2 illustriert ein typisches Deployment, wo DDS-Applikationen via DDS-RTPS Wire Protocol Informationen von OPC UA Servern abonnieren, die das OPC UA Binary Protocol nutzen.

Abbildung 2: OPC UA zu DDS Bridge

Der Brückenbetrieb ist unkompliziert: Auf der OPC-UA-Seite erstellt sie einen Client, der sich mit einem Server verbindet und Standard-OPC-UA-Services wie Read, Write und Subscription-Management ausführt. Auf der DDS-Seite instanziiert sie einen Satz von DataReaders und DataWriters, um mit DDS-Topics zu interagieren.

Die Spezifikation teilt die an DDS exponierten Daten in zwei Kategorien:

• Service Set Mappings – DDS-Services, die die meisten OPC-UA-Services emulieren, indem sie die OMG RPC over DDS Spezifikation nutzen, wodurch DDS-Requester Operationen wie Read, Write und Browse aufrufen können.
• Subscription Model Mapping – eine vereinfachte Abbildung des OPC UA Server, die Integratoren erlaubt, mehrere MonitoredItems in DDS-Topics zu kombinieren, was einen mächtigen Modellierungsansatz für DDS-Konsumenten bietet.

Zur Vereinfachung der Konfiguration haben wir ein XML-Schema definiert. Unten ist ein prägnantes Beispiel einer OPC UA/DDS Gateway Konfigurationsdatei für eine OPC UA zu DDS Bridge.

<dds> <types> <struct>...</struct> </types> <ddsopcua_gateway name="MyGateway"> <opcua_connection>...</opcua_connection> <domain_participant>...</domain_participant> <opcua_to_dds_bridge> <service_set>...</service_set> <subscription> <opcua_input>...</opcua_input> <dds_output>...</dds_output> <dds_output>...</dds_output> <dds_output>...</dds_output> <mapping>...</mapping> </subscription> </opcua_to_dds_bridge> </ddsopcua_gateway> </dds>

Listing 1: OPC UA/DDS Gateway Konfigurationsbeispiel (OPC UA zu DDS Bridge)

Die Konfigurationsdatei ist wie folgt strukturiert:

• Sie definiert DDS-Datentypen, die die von den Mappings erstellten Topics beschreiben.
• Sie deklariert eine Gateway-Instanz, die eine OPC UA zu DDS Bridge instanziiert, inklusive OPC UA Client-Verbindung und DDS DomainParticipant.
• Sie konfiguriert die Service Sets, die DDS-Applikationen exponiert werden, wie den Attribute Service Set für One-Shot Reads oder Writes.
• Sie spezifiziert OPC UA Inputs (Subscriptions zu MonitoredItems) und DDS Outputs (Topic-Publikationen), mit mapping Zuordnungen, die Inputs mit Output-Feldern verknüpfen.

DDS zu OPC UA Bridge

Die DDS zu OPC UA Bridge ermöglicht OPC UA Client-Applikationen, vollständig am DDS Global Data Space teilzunehmen. Diese Funktionalität erlaubt bestehenden OPC UA Clients und Tools, DDS-Topics, Instanzen und Datentypen über mehrere DDS-Domains zu browsen und maßgeschneiderte Subscriptions zu erstellen. Abbildung 3 demonstriert ein Deployment, wo OPC UA Clients das Binary Protocol nutzen, um auf Informationen zuzugreifen, die von DDS-Applikationen via nativem DDS-RTPS-Protokoll bereitgestellt werden.

Abbildung 3: DDS zu OPC UA Bridge

Im Wesentlichen modelliert die DDS zu OPC UA Bridge den DDS Global Data Space innerhalb des Address Space eines OPC UA Servers. Sie definiert Objects und Variable Nodes für DDS-Domains, Topics, Instanzen und Datentypen und exponiert sie via Standard-OPC-UA-Services. Ein XML-Konfigurationsschema erlaubt Integratoren, zu wählen, welche Teile des DDS-Raums im OPC UA Address Space repräsentiert werden.

<dds> <types> <struct>...</struct> </types> <ddsopcua_gateway name="MyOtherGateway"> <opcua_server>...</opcua_server> <domain_participant>...</domain_participant> <domain_participant>...</domain_participant> <dds_to_opcua_bridge> <domain> <topic_group>...</topic_group> <topic>...</topic> </domain> <domain> <topic_group>...</topic_group> </domain> </dds_to_opcua_bridge> </ddsopcua_gateway> </dds>

Listing 2: OPC UA/DDS Gateway Konfigurationsbeispiel (DDS zu OPC UA Bridge)

Die Konfigurationsdatei ist wie folgt organisiert:

• Sie definiert die DDS-Datentypen, die vom Gateway instanziiert werden.
• Sie deklariert eine Gateway-Instanz, die eine DDS zu OPC UA Bridge instanziiert, inklusive OPC UA Server und mehreren DDS DomainParticipants.
• Sie wählt DDS-Domains aus, die im OPC UA Address Space repräsentiert werden.
• Sie spezifiziert DDS-Topics – entweder explizit oder via Topic Groups, die reguläre Ausdrücke auf Topic-Namen, Typen etc. nutzen.

Prototypen und Demos

Zur Validierung der Spezifikation und Sammlung von Community-Feedback haben wir eine Reihe von Prototypen und Demos entwickelt, die auf großen Events präsentiert wurden. Letztes Jahr zeigten wir unseren ersten Prototyp auf Embedded World und Hannover Messe, gebaut auf RTI Routing Service, einer führenden Plattform für das Brücken von Konnektivitätstechnologien. Dieser Prototyp fokussierte auf das Mapping des OPC UA Subscription Models zu DDS und auf Konfigurationsmechanismen zur Vereinfachung der Integration.

Dieses Jahr werden wir die umgekehrte Seite des Gateways auf der Hannover Messe demonstrieren, mit einem leichtgewichtigen Prototyp, der den DDS Global Data Space durch einen eingebetteten OPC UA Server exponiert. Besucher können beobachten, wie ein generischer OPC UA Client DDS-Daten mittels nativer OPC UA Services abonnieren kann.

Falls Sie die Hannover Messe besuchen, finden Sie uns im IIC Pavillon (Halle 8 #C24) für eine Live-Demo. Falls nicht, veröffentlichen wir bald mehr Details – stay tuned!

OPC UA/DDS Gateway als Kern-Konnektivitäts-Gateway

Das OPC UA/DDS Gateway ist ein zentraler Bestandteil der Industrial-IoT-Revolution. Das Industrial Internet Connectivity Framework (IICF) des IIC identifiziert Kern-Konnektivitätsstandards – DDS, OPC UA, HTTP/Web Services und oneM2M –, um Integration über funktionale Domänen zu straffen. Das IICF Assessment Template evaluiert Lösungen nach Business-, Usage-, Funktionalitäts- und Implementierungskriterien. Kern-Konnektivitäts-Gateways, wie vom IICF definiert, bewahren Datensyntax, um transparente Interoperabilität über Domänen zu gewährleisten.

Abbildung 4: Ein Standard-Konnektivitäts-Gateway ermöglicht Interoperab

[1] [2]  >