Zuverlässige Datenkommunikation im (Industrial) Internet of Things mit DDS
Bei der Auswahl eines Kommunikationsprotokolls für seine IoT-Anwendung hat der System- und Softwarearchitekt mittlerweile die Qual der Wahl: MQTT, CoAP, XMPP, OPC UA und einige Protokolle mehr stehen zur Auswahl. Dabei ist es auch bei dieser Aufgabe wichtig, dass der Architekt seine Entscheidung für ein Protokoll nicht einfach aus dem Bauch heraus trifft. Wie immer in der Architekturarbeit gilt es, vor allem die nicht-funktionalen Qualitätsanforderungen an die zu entwickelnde IoT-Lösung zu berücksichtigen. Mit Data Distribution Service for Real-Time Systems (DDS) steht ein weiterer Kandidat zur Verfügung, der vor allem für das Einsatzfeld hochdynamischer, verteilter und skalierbarer Systeme und anspruchsvoller Anwendungen im Industrial Internet of Things (IIoT) geeignet ist. Dieser Artikel gibt einen Überblick über diesen Standard.
Was ist DDS?
Die Abkürzung DDS steht für Data Distribution Service for Real-Time Systems. Zunächst einmal handelt es sich dabei um einen Standard der Object Management Group® (OMG®), also des Industriekonsortiums, welches u. a. auch für die Spezifikation der populären Modellierungssprachen UML, SysML und BPMN verantwortlich ist. In der Spezifikation wird der Zweck von DDS wie folgt beschrieben: "The purpose of the DDS specification can be summarized as enabling the Efficient and Robust Delivery of the Right Information to the Right Place at the Right Time" [1].
Damit wird einerseits deutlich, dass es bei diesem Standard vor allem um eine effiziente, zuverlässige und robuste Zustellung von Daten geht. Des Weiteren wird die Echtzeitfähigkeit von DDS herausgestellt. Das Protokoll ist somit insbesondere für solche Einsatzzwecke prädestiniert, bei denen eine Überschreitung einer definierten Antwortzeit u. U. als ein Versagen gewertet und dementsprechend gesondert behandelt werden muss. Im darauf folgenden Text der Spezifikation wird DDS zudem auch als "Data-Centric Publish/Subscribe Middleware" beschrieben. In diesem Begriff stecken dreierlei Aspekte, die diesen Standard zu etwas besonderen machen:
- Publish/Subscribe (kurz: Pub/Sub): Dabei handelt es sich um ein spezielles Muster für die Nachrichtenübertragung, bei der sogenannte Publisher Daten kontinuierlich im Netzwerk veröffentlichen, sobald diese Daten vorliegen. Diese Daten können bei Bedarf von den Subscribern abonniert werden. Der Vorteil von Pub/Sub ist, dass die Subscriber und Publisher sehr lose gekoppelt sind. Der Publisher braucht nicht einmal von der Existenz der Subscriber zu wissen. Auch das sehr populäre und leichtgewichtige M2M-Protokoll Message Queue Telemetry Transport (MQTT) arbeitet nach diesem Prinzip.
- Data-Centric: Hinter diesem Begriff steckt so etwas wie ein Paradigmenwechsel. Bei DDS stehen die Daten im Mittelpunkt. Mit DDS stelle man keinen Dienst (Service) bereit, sondern Daten einer bestimmten Art und in einer bestimmten Qualität. Daher verbindet man sich bei DDS beispielsweise auch nicht mit einem spezifischen Server unter Zuhilfenahme einer URL, sondern der Subscriber bekundet quasi sein Interesse an einer bestimmten Kategorie oder Art von Daten und abonniert diese. Statt also auf einer sehr technischen Ebene zu spezifizieren, dass man sich über ein Netzwerk mit einem anderen physischen Gerät verbinden möchte, proklamiert bei DDS ein Subscriber quasi so etwas wie: "Ich bin an den Innentemperaturen der Flüssiggastanks interessiert!". Der Subscriber abonniert also die Daten zu einem bestimmtem Thema – einem Topic, wie es bei DDS genannt wird.
- Middleware: In einem verteilten System – und bei IoT-Anwendungen handelt es sich ja typischerweise um solche Systeme – ist die sogenannte Middleware die vermittelnde Software-Schicht, die zwischen dem Betriebssystem und den Anwendungen liegt. Damit kann die Komplexität dieser Applikationen und ihre Infrastruktur verborgen werden. Im Fall von DDS bedeutet dies zudem auch, dass nicht nur das Kommunikationsprotokoll standardisiert ist, sondern auch die Programmierschnittstelle (API) für die Anwendungen.
Wie funktioniert DDS?
Abb.1 zeigt beispielhaft eine, von einem konkreten Anwendungsfall abstrahierende, Systemkonfiguration, in der alle relevanten DDS-Entitäten vertreten sind.
Das wolkenartige Gebilde in der Mitte ist der sogenannte Global Data Space (GDS). Dabei handelt es sich um einen virtuellen Bereich im System (präziser: im Netzwerk), über den die einzelnen Anwendungen Daten austauschen können. Diesen GDS teilen sich diverse Anwendungen, die in der Abbildung als Domain Participants bezeichnet sind. Ein Domain Participant repräsentiert einen konkreten Teilnehmer in einer sogenannten DDS-Domäne, wobei es sich bei einer Domäne um eine logische Gliederung ("Universum") des GDS handelt. Eine DDS-Domäne wird durch eine eindeutige Zahl (unique ID) identifiziert. Ein Domain Participant kann nun entweder Publisher, also Objekte zur Veröffentlichung von Daten, oder Subscriber, also Objekte zum Abonnieren von Daten, besitzen.
Im GDS sehen wir zudem auch vier sogenannte Topics. Bei einem Topic handelt es sich um die Daten, die im GDS verfügbar sind. Ein Topic wird durch einen eindeutigen Namen – einen Datentyp – identifiziert und durch eine Sammlung von Quality of Service (QoS)-Richtlinien. Diese Topics werden durch den in einem Publisher enthaltenen Data Writer veröffentlicht (d. h. geschrieben) und können mit Hilfe der in diversen Subscribern enthaltenen Data Reader empfangen werden. Auf Grund der losen Kopplung des Pub/Sub-Modells ist es auch legitim, dass die veröffentlichten Daten eines Publishers auch gar nicht von irgendwelchen Subscribern abonniert werden, z. B. weil Letztere eventuell zur Zeit (noch) nicht existieren, wie man es beispielhaft beim Topic B sehen kann.
Die einzelnen DDS-Entitäten – wie Publisher, Subscriber, Data Writer, Data Reader, etc. – müssen übrigens nicht von den Entwicklern selbst entwickelt werden. Die Struktur der Daten eines Topics werden mit Hilfe einer Programmiersprachen-unabhängigen IDL (Interface Description Language) definiert, aus der mit Hilfe eines Code-Generators alle für die Applikation notwendigen Software-Artefakte in unterschiedlichen Programmiersprachen erzeugt werden können (s. Abb.2). Diese Software-Bausteine, z.B. C++- oder Java-Klassen, können dann in die eigene Softwareanwendung integriert werden.
Eine weitere interessante Frage ist sicherlich die, wie denn nun bei DDS die Subscriber und die Publisher, die miteinander Daten austauschen sollen, zueinander finden? Für diesen Zweck ist das sogenannte Discovery zuständig. Die DDS Middleware entdeckt dynamisch Publisher und Subscriber, sowie die von ihnen veröffentlichten bzw. eingeforderten Topics bzw. Datentypen, und etabliert bei entsprechender Übereinstimmung einen Datenaustauschkanal zwischen den Beteiligten. Das besondere bei DDS gegenüber anderen Pub/Sub-Lösungen ist, dass dafür kein zentraler Broker [2] notwendig ist, also keine zentrale Komponente oder Instanz (z. B. Server), die für das Management der Kommunikation verantwortlich ist.
Als datenzentrierte Lösung kann DDS das Schema der gemeinsam genutzten Daten auswerten. Dadurch kann die Middleware die Daten nach ihrem Inhalt, nach ihrem Alter oder ihrem Lebenszyklus (Sind die Daten überhaupt noch gültig?) filtern. Somit ist DDS in der Lage, Subscriber nur mit den Daten zu versorgen, die diese auch wirklich benötigen – alles andere wird von den Publishern gar nicht erst über das Netzwerk übertragen! Zum Beispiel kann mit Hilfe von sog. content-filtered Topics definiert werden, dass nur Flüssiggastank-Temperaturen über 75°C und diese mit höchstens zehn Updates pro Sekunde (Rate), gesendet werden. Durch diesen effizienten Ansatz kann in vielen Systemen bis zu 90 Prozent des Datenkommunikationsaufwands gespart werden.
Ausgefeilte Konfigurationsmöglichkeiten der Dienstgüte (QoS)
Wohl eines der hervorstechendsten Features von DDS sind die mannigfaltigen Konfigurationsmöglichkeiten der Dienstgüte, der sog. Quality of Service (QoS). Unter einer Dienstgüte versteht man die Qualität eines Kommunikationsdienstes aus der Sicht seiner Anwender, das heißt, wie stark die Güte des Dienstes mit den an ihn gestellten Qualitätsanforderungen übereinstimmt. DDS bietet ein sehr breites Spektrum von nicht-funktionalen Eigenschaften, die von den Entwicklern parametriert werden können, wie beispielsweise die Datenverfügbarkeit, Datenbereitstellung, Datenaktualität oder Ressourcennutzung. Die nachfolgende Abb.3 gibt einen Überblick über die sogenannten DDS QoS Policies.
Alle QoS Policies im Detail zu besprechen würde den Rahmen dieses Artikels sprengen, daher möchte ich hier nur eine sehr kleine Auswahl kurz vorstellen:
- Durability: Die Durability-QoS legt fest, ob und wie bereits veröffentlichte Daten durch die publizierende Anwendung gespeichert werden, um diese Daten gegebenenfalls auch für sog. Late Joiners bereitstellen zu können, d. h. für Data Reader, die erst später nach dem Schreiben der Daten instanziiert werden.
- Lifespan: Die Lifespan-Policy definiert, wie lange Daten nach dem Veröffentlichen durch einen Data Writer gültig sind. Mit Hilfe dieser QoS Policy kann verhindert werden, dass veraltete Daten an die Subscriber ausgeliefert werden.
- Time-Based Filter: Data Writer können unter Umständen Daten häufiger schreiben, als sie von den Anwendungen mit einem zugehörigen Data Reader verarbeitet werden können. Mit dieser QoS-Policy kann definiert werden, dass ein Reader nicht öfter als z. B. alle 0,5 Sekunden einen Datensatz zu einem bestimmten Topic bekommen möchte.
- Reliability: Die Reliability-QoS definiert, ob alle geschriebenen Datensätze (irgendwann) bei allen Readern angekommen sein müssen. Bei zuverlässiger (reliable) Kommunikation werden geschriebene Datensätze eines Topics, die aus irgendwelchen Gründen auf dem Netzwerk verloren gehen, von der Middleware wiederhergestellt, um diese Daten verlässlich den Data Readern zustellen zu können.
- Resource Limits: Diese QoS Policy steuert die Allokation physischen Speichers durch DDS-Entitäten, wenn dynamische Speicherallokation erlaubt ist. So kann über die Resource Limity QoS Policy u. a. festgelegt werden, wie viele Dateninstanzen die Middleware für jeden existierenden Data Writer bzw. Data Reader speichern kann.
Welche Implementierungen gibt es?
Da die Implementation einer derart ausgefeilten und anspruchsvollen Kommunikationslösung für Echtzeitanwendungen natürlich nicht trivial ist, und DDS auch nicht zum Mainstream gehört, ist die Zahl der derzeit am Markt verfügbaren Implementierungen des DDS-Standards noch recht übersichtlich. Es gibt einige kommerzielle Anbieter, aber auch Open Source-Implementationen. Eine Auflistung findet man auf dem DDS-Portal [3].
Kurze Gegenüberstellung zu anderen IoT-Protokollen
Gleich vorweg: Alle IoT-Protokolle haben ihre Daseinsberechtigung. Wie so oft gilt auch hier: "One size doesn't fit all needs". Wie bereits angedeutet, ist es primäre Aufgabe des System- und Softwarearchitekten, die für den jeweiligen Einsatzkontext am besten passende Lösung auszuwählen. Daher beschränkt sich diese kurze Gegenüberstellung auf die wichtigsten Unterschiede und Merkmale von DDS zu anderen populären Protokollen.
Der Platzhirsch unter den IoT-Protokollen dürfte wohl MQTT [4] sein. Beide, sowohl MQTT als auch DDS, folgen dem Pub/Sub-Muster. Während allerdings DDS auf hohen Datendurchsatz optimiert ist, äußerst geringe Latenz im Bereich weniger Milli- oder Microsekunden, Echtzeitanwendungen und massiv skalierbare Systeme (viele Kommunikationspartner), ist MQTT auf Geräte mit sehr limitierten Ressourcen (geringer memory footprint, geringe Netzwerkbandbreite) optimiert und für eher sporadische Mess- und Steueraufgaben. Da MQTT datenagnostisch ist, ist es möglich, Daten in jedem beliebigen Format zu übertragen ("Blobs"). Bei DDS als datenzentrische Lösung hingegen stehen die Daten im Mittelpunkt der Betrachtung und ermöglichen dadurch erst ausgefeilte QoS-Einstellungen und eine elaborierte Steuerung des Datenverkehrs mit Hilfe der content-filtered Topics. Auch MQTT bietet QoS-Features, doch im Gegensatz zu den lediglich drei verschiedenen MQTT Quality of Service Levels für den Nachrichtenversand bietet DDS um Größenordnungen mehr Möglichkeiten, um die Dienstgüte zu konfigurieren.
CoAP (Constrained Application Protocol) [5], als ein auf HTTP basierendes Protokoll, unterscheidet sich schon erheblich von DDS. Wie auch HTTP, basiert CoAP auf dem weit verbreiteten REST-Modell (Representational State Transfer). Das heißt: Server stellen Ressourcen unter einer URL zur Verfügung und Klienten erhalten Zugriff auf diese Ressourcen unter Verwendung der bekannten Methoden GET, PUT, POST und DELETE. Das bedeutet auch, dass das Kommunikationsparadigma bzw. -muster bei CoAP nicht Pub/Sub wie bei DDS, sondern Request/Response ist. Daraus folgt auch, dass CoAP ein auf UDP basierendes Transportprotokoll und kein Datenformat definiert. Darüber hinaus ist CoAP zustandslos und nicht für Echtzeitanwendungen geeignet. QoS-Einstellungen gibt es keine. CoAP hat allerdings gegenüber dem rein textbasierten HTTP den Vorteil, dass es deutlich effizienter ist, da sowohl die Nutzdaten als auch alle Header in einem Binärformat verschickt werden.
OPC Unified Architecture (OPC UA) [6] fällt in diesem Vergleich ein wenig aus dem Rahmen. Es handelt sich dabei nicht nur um ein Protokoll (genaugenommen gibt es sogar zwei Protokolle). Vielmehr spezifiziert OPC UA ein plattform- und herstellerunabhängiges, service-orientiertes Architekturframework, zu dem auch ein industrielles M2M-Kommunikationsprotokoll gehört. Die OPC Foundation positioniert OPC UA als eine Schlüsseltechnologie und als einen Standard für Daten- und Informationsaustausch für das Projekt Industrie 4.0, bei dem die Interoperabilität im Vordergrund steht. Im Unterschied zu DDS und auch anderen Protokollen definiert OPC UA daher auch ein domänenspezifisches Datenmodell. Als Protokolle existieren bei OPC UA zum einen ein effizientes und ressourcenschonendes Binärprotokoll, welches vor allem für Embedded Devices gut geeignet ist, sowie ein HTTP-Protokoll für die Webservices (SOA). Im Gegensatz zu DDS ist OPC UA daher auch dienstorientiert (Client/Server) und nicht datenorientiert. OPC UA unterstützt keine Konfiguration der Dienstgüte mit Hilfe von QoS. Im April 2016 haben die OMG und die OPC Foundation eine Kooperation angekündigt, mit dem Ziel, gemeinsam an einer Integration beider Kommunikationsstandards zu arbeiten [7].
Fazit
Data Distribution Service for Real-Time Systems ist eine datenzentrierte Pub/Sub-Middleware für Echtzeit-Anwendungen, die vor allem für sehr hohen Durchsatz, geringe Latenzen, viele verteilte Kommunikationspartner, harte Echtzeitanforderungen und für Einsatzgebiete optimiert ist, bei denen Anforderungen an die funktionale Sicherheit (functional safety) eine signifikante Rolle spielen. Damit ist diese Lösung auch geradezu prädestiniert für IoT-Anwendungen im industriellen Kontext (IIoT), also dort, wo die nicht-funktionalen Eigenschaften Effizienz/Performanz, Zuverlässigkeit, Robustheit (Resilienz) und Ausfallsicherheit eine große Rolle spielen. Da DDS-Implementierungen von verschiedenen Herstellern bereits seit vielen Jahren in zum Teil hochkritischen und stark verteilten Anwendungen im Einsatz sind, u. a. im Verteidigungssektor, Air Traffic Control (Flugsicherung) oder Smart Grid (intelligente Stromnetze), sind die Features und Möglichkeiten dieser Middleware nicht im "Clean Room" – also: am Reißbrett – entstanden, sondern an den "schmutzigen" Detailproblemen echter Projekte gewachsen. Dies wird vor allem an den durchaus sehr komplexen Möglichkeiten der QoS-Policies deutlich.
Es ist Aufgabe der System- und Softwarearchitektur, eine adäquate Kommunikationslösung auszuwählen, die die Qualitätsanforderungen an die zu entwickelnde IIoT-Applikation bestmöglich erfüllt. Stehen Daten und ihre Qualität im Zentrum der Betrachtung, sind die nicht-funktionalen Anforderungen an Latenz und Durchsatz sehr hoch und sollen zudem die beteiligten Applikationen (Sensoren, Aktuatoren, etc.) auch noch sehr lose gekoppelt sein, so kann DDS gegenüber anderen Standards die bessere Wahl sein. Da bei DDS auch kein zentraler Broker/Server erforderlich ist, fällt zudem ein potenzieller Single Point of Failure weg. Allerdings ist es erforderlich, sich mit den umfangreichen und durchaus komplexen Parametrisierungsmöglichkeiten der Dienstgüte (QoS) auseinanderzusetzen, was eine gute Detailkenntnis der Problemdomäne, der Wechselwirkungen zwischen den einzelnen QoS-Parametern und ein umfassendes Verständnis über die zu erfüllenden nicht-funktionalen Anforderungen voraussetzt.
- OMG Data Distribution Service™, V1.4 (April 2015)
- Enterprise Architecture Pattern: Message Broker
- DDS-Portal: Where can I get DDS?
- Informatik Aktuell – Dominik Obermaier: Internet der Dinge: Leichtgewichtiges Messaging
- CoAP - RFC 7252 Constrained Application Protocol
- OPC Foundation
- Object Management Group and OPC Foundation Announce Collaborative Strategy for the DDS and OPC UA Connectivity Standards
