Der DDS-Standard der Object Management Group (OMG) ist von Grund auf darauf ausgelegt, die Herausforderungen der Echtzeit-Kommunikation anzugehen. Time-Sensitive Networking (TSN) umfasst eine Reihe von Standards der IEEE-Arbeitsgruppe 802.1 der Time-Sensitive Networking Task Group. Die Standards definieren Mechanismen zur Übertragung zeitsensibler Daten über Ethernet-Netzwerke. Dass DDS und TSN gut zusammenarbeiten können, erklärt sich aus mehreren Gründen. Ganz grundsätzlich stellen beide Techniken eine One-to-Many-Kommunikation zur Verfügung, die für unterschiedliche Datenströme verschiedene Zuverlässigkeits-Niveaus unterstützt. 

DDS-Datenflüsse und TSN-Streams

Bei DDS dreht sich alles um ein weitreichend typisiertes Publish/Subscribe-Modell, in dem DataWriter für das Aktualisieren bestimmter Datentypen zuständig sind, während DataReader diese Aktualisierungen beobachten. Ein Topic ist hierbei ein anwendungsspezifischer Datentyp, der festlegt, welche Informationen ein DDS-Paket enthält. Typische DDS-Systeme bestehen aus einem bis zu Hunderten von Topics. Die Kombination aus einem DataWriter und seinem Topic-Namen lässt sich als ID einer DDS-Datenfluss-Quelle bezeichnen. Alle passenden DataReader (One-to-Many) fungieren als Senken für diesen Datenfluss. 

Ähnlich wie hier gibt es in TSN Talker. Diese aktualisieren einen oder mehrere Streams, die Daten an die angeschlossenen Listener liefern. Solche Streams werden durch ihre ‚VLAN Tag ID‘ identifiziert. Die Kombination aus einem Talker und seiner VLAN Tag ID lässt sich als ID der Quelle eines TSN-Streams bezeichnen. 

Aus dieser Beschreibung geht hervor, wie sich DDS-Datenflüsse direkt auf TSN-Streams abbilden lassen. Die meisten DDS-Systeme machen heutzutage bereits Gebrauch vom IP-Multicasting, sodass der Ersatz dieses Mechanismus durch die Kommunikation über TSN-Streams ein folgerichtiger Schritt ist. Auf der Applikationsebene wären die Auswirkungen minimal, da die Details des zugrundeliegenden Transports den DDS-Anwendern verborgen bleiben. 

QoS in DDS und Traffic-Klassen in TSN

Zusätzlich kennzeichnen DDS verschiedenste Quality-of-Service-Einstellungen. Deren Aufgabe besteht darin, die Middleware unter anderem über die Wichtigkeit und Dringlichkeit der Informationen in den verschiedenen DDS-Datenflüssen zu instruieren. Im Sinne des datenzentrischen Ansatzes – Anwendungen kommunizieren mit der Dateninfrastruktur, nicht miteinander – erfolgen die QoS-Einstellungen für jeden Datenfluss einzeln. Einige davon haben Ähnlichkeit mit den Mechanismen, welche die Traffic-Klassen in TSN definieren. Beispiele hierfür sind die QoS-Einstellungen ‚Deadline‘, ‚LatencyBudget‘ und ‚TransportPriority‘. Weitere QoS-Einstellungen auf DDS-Ebene eignen sich für intelligente Entscheidungen bei der Auswahl des passenden zugrundeliegenden TSN-Streams. Indem Systemdesigner also auf DDS-Ebene die richtigen QoS-Einstellungen wählen, können sie sich auf das End-to-end Daten-Distributions-Verhalten verlassen – also von der produzierenden Applikation bis hin zum Netzwerk-Stack, durch das Netzwerk und zurück zur konsumierenden Applikation.

Auf Basis des ‚Data Distribution Service for Real-Time System‘ wurden DDS-Produkte von Anfang an für die Implementierung solcher Systeme konzipiert und eingesetzt.

Bestehende DDS-Ökosysteme eignen sich deshalb für den Einsatz in Anwendungsbereichen, die auch von TSN-Techniken adressiert werden, etwa in der industriellen Automation und bei Automotive-Anwendungen.

Vorteile durch die Kombi DDS + TSN

Was steuert nun DDS zusätzlich zu TSN bei, wodurch sich die Kombination beider Techniken lohnt? Was macht es umgekehrt für DDS-Anwender interessant, TSN als zugrundeliegendes Netzwerk zu nutzen? 

Die Interaktions-Modelle von DDS und TSN sind recht ähnlich: In beiden Fällen handelt es sich grundsätzlich um Techniken nach dem One-to-Many- und Publish/Subscribe-Konzept. Setzt man DDS auf TSN auf, so resultiert daraus ein Programmiermodell mit einem höheren Abstraktionsgrad. DDS-Anwender entwickeln ihre Systeme durch das Produzieren oder Konsumieren weitreichend typisierter und vorab definierter Datenelemente. Die hierfür unterstützten Datenmodellierungs-Konstrukte sind zudem umfangreich und modern. Applikationsentwickler sehen ihre Daten als Konstrukte systemeigener Programmiersprachen, während alle untergeordneten Mechanismen wie Serialisierung und Deserialisierung sowie Netzwerk-Interaktionen von der DDS-Middleware übernommen werden.

DDS besteht aus einer Reihe offener Standards mit der Object Management Group als Standardisierungs-Instanz. So lassen sich die Standards über die OMG-Website frei herunterladen. Zusätzlich zur Funktionsbeschreibung von DDS umfasst die Spezifikation ein standardisiertes API, das Applikationsentwickler nutzen können. Bei einer Integration von DDS und TSN lässt sich das API für eine einfachere Einarbeitung, zur Senkung der Wartungskosten und als Unterstützung durch ein Off-the-Shelf-Ökosystem verwenden.

Da DDS aus großen missionskritischen Systemen hervorgegangen ist, bleiben die erforderlichen Eigenschaften für zuverlässige, betriebssichere Systeme erhalten, wenn ein TSN-Netzwerk durch DDS ergänzt wird.

Viele Systeme bestehen aus verschiedenen Subsystemen mit unterschiedlichen Anforderungen und Fähigkeiten. Nicht alle dieser Subsysteme erfordern jedoch das von TSN gebotene strikte Echtzeit-Verhalten. DDS ermöglicht es, die gleiche Infrastruktur in verschiedenen Subsystemen wiederzuverwenden und sie mit Gateways zu verbinden, während ein einheitliches Datenmodell beibehalten wird. Da DDS nicht an bestimmte Betriebssysteme oder Programmiersprachen gebunden ist, eignet es sich für unterschiedliche Umgebungen. In solchen Fällen bleiben das Datenmodell und das reichhaltige Ökosystem von DDS als gemeinsames Thema erhalten. Dies vereinfacht wiederum das Einbringen von TSN in ein bestehendes System oder Design sowie den Ausbau eines vorhandenen, TSN-basierten Systems durch zusätzliche Subsysteme mit unterschiedlichen nichtfunktionsbezogenen Anforderungen.