Herr Duwe, ist die Verwendung von DDS mit Lizenzkosten verbunden oder handelt es sich um eine ebenso ­offene Technologie, wie es nun mit OPC UA angestrebt wird? Zur Erinnerung: Die OPC Foundation hat auf der Hannover Messe angekündigt, OPC UA als Open Source zur Ver­fügung zu stellen.

DDS war von Anfang an ein offener Standard. Die Spezifikationen sind frei verfügbar bei der Open ­Management Group (OMG), die den Standard auch managt. Es gibt mindestens 14 verschiedene Implementierungen des Standards, einige sind Open Source, andere sind kommerzielle ­Angebote. RTI beispielsweise bietet sowohl eine kostenlose Open-Community-Source-Lizenz wie auch kommerzielle Lizenzen an.

Aus welchen Gründen wird DDS vom Industrial Internet Consortium  (IIC) als Kommunikationsstandard ­favorisiert?

Die industrielle Internet-­Referenzarchitektur – kurz IIRA – des IIC beschreibt die Konnektivitätsmerkmale von industriellen Internet-Systemen (IIS). Diese beinhalten niedrige Latenzen und Schwankungen, einen hohen Durchsatz, Skalierbarkeit, Ausfallsicherheit, Datensicherheit und ‚Quality of Service’ (QoS). – DDS ist der einzige Standard, der alle diese identifizierten Anforderungen abdeckt!  Außerdem ist DDS in verteilten industriellen Systemen bereits zuverlässig etabliert. DDS ist ursprünglich für Steuerungs- und Kontrollaufgaben entwickelt worden und hat sich weiterentwickelt, um auch IT-Systeme abzudecken. Realisierte Anwendungen finden sich in weiten Bereichen der Industrie – in  Schiffssystemen, der Fahrzeugtechnik, der Medizintechnik, bei SCADA-Ablösungen und vielen anderen Industriesegmenten.

Die IIRA berücksichtigt auch, dass ­industrielle Internet-Systeme viele unterschiedliche Kommunikationsstandards beinhalten können. Die Archi­tektur beschreibt den Einsatz von Gateways zwischen anderen Standards und einem Kern-Standard wie DDS. Der Kern-Standard liefert das Rückgrat (back bone) für die Integration und ­routet Daten zwischen den Sub-­Systemen, die eventuell unterschiedliche Standards nutzen.

Die OPC Foundation führt ins Feld, das OPC UA mehr sei als ein Protokoll à la DDS. Mit OPC UA würde vielmehr an der nächsten Stufe, der semantischen und sicheren Interoperabilität gearbeitet. Protokolle wie DDS seien in der OPC-UA-Architektur eine austausch-bare Komponente, die keine Rückwirkungen auf die kommunizierten Informationen habe. – Kann man das so stehen lassen?

Ich stimme zu, dass sich DDS und OPC UA weitgehend ergänzen. DDS kann sich in die OPC-UA-Architektur einfügen und mit dem OPC-Informationsmodell genutzt werden. Tatsächlich hat RTI Kunden, die DDS mit OPC nutzen.

Ich möchte aber deutlich hervorheben, dass DDS viel mehr ist als ein ­Protokoll. DDS bietet ein umfassendes Konnektivitäts-Framework. Dies beinhaltet ein Kommunikationsparadigma basierend auf einem shared data model – genannt data-centric publish-subscribe –, einen Standard für die Definition domain-spezifischer Informationsmodelle, ein starkes Sicherheitsmodell, Discovery und reichhal­tige APIs.

Wo genau liegen dann die Unterschiede zwischen OPC UA und DDS, beziehungsweise die Vorteile von DDS?

OPC UA wurde entwickelt zur leichteren Integration von Geräten und Applikationen in der Fertigungssteuerung. Hierzu werden allgemeine und domain-spezifische Datenmodelle, Dienste und Protokolle für die Interoperabilität zwischen verschieden Anbietern definiert.

DDS wurde entwickelt für niedrigste Latenzzeiten, einen hohen Datendurchsatz sowie eine skalierbare, ­belastbare und sichere Datenver­teilung. Es beinhaltet Standardprotokolle und Möglichkeiten der Meta-­Modellierung. Andere Standardisierungsgremien oder Unternehmen können diese nutzen, um domain-spezifische Interoperabilitätsstandards zu spezifizieren. Aus DDS-Sicht könnte OPC UA ein solcher domain-spezifischer Standard sein.

Auf der technischen Ebene gibt es einige signifikante Unterschiede: OPC UA hat eine zentralisierte, server-basierte Topologie. Applikationen rufen typischerweise einen Service auf, der auf einem Server läuft: zum Beispiel, um einen Wert zu setzen oder zu erhalten. Wenn notwendig, interagiert dieser Service dann mit einer anderen Applikation oder einem Gerät, um etwa eine Einstellung zu ändern.

DDS hingegen hat eine komplett dezentralisierte Architektur. Datenpro­duzenten – Publisher – veröffentlichen ihre Daten direkt an Konsumenten – also an Subscriber. Es gibt keine ­zwischengeschalteten Server. Dies ­minimiert Latenzen, eliminiert Ausfall und ‚Single point of failure‘-Probleme. DDS kann Daten unter Nutzung der Multicast-Fähigkeiten moderner Netzwerk-Switches publizieren. Mit Multicast müssen Daten-Updates nur einmal gesendet werden, unabhängig von der Anzahl der Empfänger, sprich Subscriber. Vorteil ist: Dies hält ­Latenzzeiten auch in sehr großen Systemen niedrig.

DDS bietet auch umfassende Kontrolle durch ‚Quality of Service‘-Parameter. Applikationen können spezi­fizieren, welche Daten sie genau be­nötigen und mit welcher Frequenz. DDS wird die Daten automatisch zur benötigten Zeit am benötigten Ort zur Verfügung stellen, bei entsprechender Optimierung der Netzwerknut-zung und Ver­einfachung der Applika­tionslogik. Zusätzlich benachrichtigt DDS Applikationen, wenn Laufzeit­intervalle überschritten werden, so dass Korrekturen ermöglicht werden. Mit DDS können sie Daten über zu­verlässige Multicast-Verbindungen, über instabile Funk-/Satelliten-Ver­bindungen oder zwischen Echtzeit-Analyseapplikationen in Kontroll- und Datenzentren übermitteln.

Wie Einsatzreif ist DDS für das industrielle Umfeld und welche Weiterentwicklungen sind angedacht beziehungsweise noch notwendig?

Wie auch das IIC definiert RTI den Begriff ‚industriell’ sehr weit. Neben der Fertigungs- und Prozesskontrolle verstehen wir darunter auch die Energieerzeugung und -ver­teilung, die Medizintechnik im klinischen Umfeld, die Verkehrsinfra­struktur, autonome Fahrzeuge, Avionik und Verteidigungssysteme. DDS ist schon heute in tausenden dieser Sys­teme im Einsatz, wobei die meisten hohe sicherheitstechnische und Datenschutzanforderungen haben. DDS ist also zweifelsfrei für den Einsatz ge­eignet.

Viele der derzeitigen Aktivitäten fokussieren die Schaffung domain-spezifischer Interoperabilitätsstandards ergänzend zu DDS. Beispielsweise Standards zur Anwendung von DDS in Krankenhäusern, Microgrids, Avionik, UAVs oder der Fertigungssteuerung. Die meisten dieser Anwendungsstandards bein­halten die Abbildung etablierter In­for­mationsmodelle wie OPC UA und IEC 81850.