Datenverteilungsdienst

Der Data Distribution Service ( DDS ) für Echtzeitsysteme ist ein von der Object Management Group (OMG) entwickelter Standard für die maschinelle Kommunikation (manchmal auch Middleware oder Konnektivitätsframework genannt), der darauf abzielt , zuverlässige , leistungsstarke , interoperable , skalierbare Echtzeit - Datenaustausche mithilfe eines Publish-Subscribe-Musters zu ermöglichen .

DDS erfüllt die Anforderungen an den Echtzeit-Datenaustausch von Anwendungen in den Bereichen Luft- und Raumfahrt, Verteidigung, Flugsicherung , autonome Fahrzeuge , Medizintechnik, Robotik, Energieerzeugung, Simulation und Test, Smart-Grid- Management, Transportsysteme und anderen Anwendungsgebieten.

DDS ist eine Netzwerk- Middleware , die die komplexe Netzwerkprogrammierung vereinfacht . Sie implementiert ein Publish-Subscribe-Muster zum Senden und Empfangen von Daten, Ereignissen und Befehlen zwischen den Knoten . Knoten, die Informationen erzeugen (Publisher), erstellen „Topics“ (z. B. Temperatur, Standort, Druck) und veröffentlichen „Samples“. DDS liefert die Samples an Subscriber, die Interesse an diesem Topic bekunden.

DDS übernimmt Übertragungsaufgaben: Nachrichtenadressierung, Daten-Marshalling und -De-Marshalling (sodass sich Abonnenten auf anderen Plattformen als der Herausgeber befinden können), Zustellung, Flusssteuerung, Wiederholungsversuche usw. Jeder Knoten kann Herausgeber, Abonnent oder beides gleichzeitig sein.

Das DDS Publish-Subscribe-Modell macht komplexe Netzwerkprogrammierung für verteilte Anwendungen praktisch überflüssig.

DDS unterstützt Mechanismen, die über das grundlegende Publish-Subscribe-Modell hinausgehen. Der Hauptvorteil besteht darin, dass Anwendungen, die DDS für ihre Kommunikation nutzen, entkoppelt sind. Der Entwicklungsaufwand für die Handhabung ihrer Interaktionen ist minimal. Insbesondere benötigen die Anwendungen keinerlei Informationen über die anderen beteiligten Anwendungen, weder über deren Existenz noch über deren Standorte. DDS übernimmt die Nachrichtenübermittlung transparent und ohne Eingriff der Benutzeranwendungen.

• festlegen, wer die Nachrichten erhalten soll
• wo sich die Empfänger befinden
• Was passiert, wenn Nachrichten nicht zugestellt werden können?

DDS ermöglicht es dem Benutzer, QoS-Parameter ( Quality of Service ) festzulegen , um Erkennungs- und Verhaltensmechanismen im Voraus zu konfigurieren. Durch den anonymen Nachrichtenaustausch vereinfacht DDS verteilte Anwendungen und fördert modulare, gut strukturierte Programme. DDS übernimmt außerdem automatisch den Hot-Swap von redundanten Publishern, falls der primäre Publisher ausfällt. Abonnenten erhalten stets die Nachricht mit der höchsten Priorität, deren Daten noch gültig sind (d. h. deren vom Publisher festgelegte Gültigkeitsdauer noch nicht abgelaufen ist). Nach der Wiederherstellung des primären Publishers wird dieser automatisch wieder aktiviert.

Es sind sowohl proprietäre als auch Open-Source-Software- Implementierungen von DDS verfügbar. Dazu gehören Anwendungsprogrammierschnittstellen (APIs) und Bibliotheken mit Implementierungen in Ada , C , C++ , C# , Java , Python , Scala , Lua , Pharo , Ruby und Rust .

DDS-Anbieter beteiligten sich von 2009 bis 2013 an Interoperabilitätsdemonstrationen auf den technischen Frühjahrstagungen der OMG. ^{[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]}

Während der Demos veröffentlichten und abonnierten die Anbieter die Themen der anderen mithilfe einer Testsuite namens „Shapes-Demo“. Beispielsweise veröffentlichte ein Anbieter Informationen zu einer Form, und die anderen Anbieter konnten das Thema abonnieren und die Ergebnisse auf ihren eigenen Formenanzeigen darstellen. Die Anbieter veröffentlichten die Informationen abwechselnd, und die anderen abonnierten sie. Zwei Dinge ermöglichten die Demos: das DDS-I- oder Real-Time Publish-Subscribe (RTPS)-Protokoll ^{[ 7 ]} und die Vereinbarung zur Verwendung eines gemeinsamen Modells.

Im März 2009 demonstrierten drei Anbieter die Interoperabilität zwischen ihren einzelnen, unabhängigen Produkten, die das OMG-Echtzeit-Publish-Subscribe-Protokoll Version 2.1 ab Januar 2009 implementierten. Die Demonstration umfasste die Erkennung der jeweiligen Publisher und Subscriber auf verschiedenen Betriebssystemplattformen ( Microsoft Windows und Linux ) und unterstützte Multicast- und Unicast -Netzwerkkommunikation. ^{[ 1 ]}

Die DDS-Interoperabilitätsdemonstration nutzte Szenarien wie:

• Grundlegende Netzwerkverbindung über das Internetprotokoll (IP).
• Entdeckung von Verlagen und Abonnenten
• Dienstgüte (QoS) Kompatibilität zwischen Anfragendem und Anbieten
• Verzögerungstolerante Netzwerke
• Mehrere Themen und Instanzen von Themen
• Exklusive Eigentumsrechte an Themen
• Inhaltsfilterung von Themendaten einschließlich Zeit und geografischer Merkmale

Die Entwicklung der DDS-Spezifikation begann im Jahr 2001. Im Jahr 2004 veröffentlichte die Object Management Group (OMG) die DDS-Version 1.0. ^{[ 8 ]} Version 1.1 wurde im Dezember 2005 veröffentlicht, ^{[ 9 ]} 1.2 im Januar 2007 ^{[ 10 ]} und 1.4 im April 2015. ^{[ 11 ]} DDS ist unter anderem durch mehrere US-Patente geschützt, ^{[ 12 ] [ 13 ] [ 14 ] [ 15 ]} .

Die DDS-Spezifikation beschreibt zwei Schnittstellenebenen:

• Ein niedrigeres datenzentriertes Publish-Subscribe-Level (DCPS), das auf die effiziente Zustellung der richtigen Informationen an die richtigen Empfänger abzielt.
• Eine optionale höhere Datenlokalrekonstruktionsschicht (DLRL), die eine einfache Integration von DDS in die Anwendungsschicht ermöglicht .

Weitere verwandte Standards folgten dem ursprünglichen Kerndokument. Die Spezifikation zur Interoperabilität des Echtzeit-Publish-Subscribe-Wire-Protokolls (DDS) stellte sicher, dass Informationen, die zu einem Thema mit der DDS-Implementierung eines Anbieters veröffentlicht wurden, von einem oder mehreren Abonnenten mit DDS-Implementierungen desselben oder verschiedener Anbieter genutzt werden konnten. Obwohl die Spezifikation primär für die DDS-Community gedacht ist, ist ihre Anwendung nicht beschränkt. Version 2.0 wurde im April 2008, Version 2.1 im November 2010, 2.2 im September 2014 und 2.3 im Mai 2019 veröffentlicht. ^{[ 7 ]}

DDS für Lightweight CCM (dds4ccm) bietet ein Architekturmuster, das die Geschäftslogik von den nicht-funktionalen Eigenschaften trennt. Eine Erweiterung aus dem Jahr 2012 fügte Unterstützung für Datenströme hinzu. ^{[ 16 ]} Ein Java-5-Sprach-PSM für DDS definierte eine Java-5-Sprachbindung, das sogenannte plattformspezifische Modell (PSM) für DDS. Es spezifizierte ausschließlich den datenzentrierten Publish-Subscribe-Teil (DCPS) der DDS-Spezifikation und umfasste darüber hinaus die von DDS-XTypes und DDS-CCM eingeführten DDS-APIs. DDS-PSM-Cxx definiert die ISO/IEC-C++- PSM-Sprachbindung ^{[ 17 ]} , ebenfalls ein plattformspezifisches Modell (PSM) für DDS. Es bietet eine neue, für C++-Programmierer intuitivere C++-API für die DDS-Programmierung. ^{[ 18 ]} Die Spezifikation stellt Zuordnungen für die in DDS-XTypes spezifizierte Anwendungsprogrammierschnittstelle (API) und den Zugriff auf die in DDS-CCM spezifizierten QoS-Profile ( Quality of Service ) bereit.

Extensible and Dynamic Topic Types for DDS (DDS-XTypes) boten Unterstützung für datenzentrierte Publish-Subscribe-Kommunikation, bei der Themen mit spezifischen Datenstrukturen definiert werden. Um erweiterbar zu sein , verwenden DDS-Themen Datentypen, die vor der Kompilierzeit definiert und im gesamten globalen Datenraum von DDS verwendet werden. Dieses Modell ist vorteilhaft, wenn statische Typüberprüfung sinnvoll ist. ^{[ 19 ]} Ein UML-Profil ( Unified Modeling Language ) spezifizierte DDS-Domänen und -Themen als Teil der Analyse- und Entwurfsmodellierung. ^{[ 20 ]} Diese Spezifikation definierte auch, wie Objekte veröffentlicht und abonniert werden können, ohne die Typen zuvor in einer anderen Sprache wie XML oder OMG IDL zu beschreiben. ^{[ 21 ]} Eine Interface Definition Language (IDL) wurde 2014 unabhängig von Kapitel 3 der CORBA-Spezifikation ( Common Object Request Broker Architecture ) spezifiziert. Diese IDL 3.5 war mit der CORBA-3-Spezifikation kompatibel, wurde aber als eigenständige Spezifikation ausgelagert, um ihre unabhängige Weiterentwicklung zu ermöglichen. ^{[ 22 ]}

Weitere erwähnenswerte Protokolle sind: DDS-XRCE (DDS für extrem ressourcenbeschränkte Umgebungen). Dieses Protokoll ermöglicht die Kommunikation zwischen ressourcenbeschränkten Geräten, wie beispielsweise Mikrocontrollern, und einem DDS-Netzwerk. Es ermöglicht das Veröffentlichen und Abonnieren von Themen über einen Zwischendienst in einer DDS-Domäne ^{[ 23 ].} DDS-RPC (RPC über DDS) definiert Remote Procedure Calls (RPC). Diese ermöglichen eine bidirektionale Anfrage-/Antwort-Kommunikation, bestimmen verteilte Dienste und werden über eine Dienstschnittstelle detailliert beschrieben. Sie unterstützen sowohl synchrone als auch asynchrone Methodenaufrufe ^{[ 24 ] .}

Ab DDS Version 1.4 im Jahr 2015 wurde die optionale DLRL-Schicht in eine separate Spezifikation ausgelagert. ^{[ 25 ]}

• Middleware
• Offene Architektur-Rechenumgebung
• Object Management Group (OMG), die Normungsorganisation, die die Spezifikation entwickelt hat