Nach der langen Zeit der Feldbusse läutet Time Sensitive Networking (TSN) eine neue Phase der industriellen Kommunikation ein. Dabei kommen Fragen auf: Wird sich TSN auf lange Sicht durchsetzen? Lassen sich frühere Investitionen sichern und vorhandene Systemkomponenten und Applikationen weiternutzen? Wird es die Möglichkeit geben, zukünftige innovative Technologien zu kombinieren und steigende Anforderungen zu erfüllen? Wann muss man sich entscheiden – und was, wenn man sich zu früh oder falsch entscheidet?

Systemarchitekten und Entwickler halten sich gerne alle Optionen offen, wenn sie die TSN-Standards mit dem datenzentrischen Data-Distribution-Service-Standard (DDS) kombinieren.

Internetanwendungen werden heutzutage mithilfe übergeordneter Middleware- (Layer 5 und 6) sowie Connectivity-Framework-Technologien wie MQTT, DDS, OPC UA, HTTP/REST integriert. Diese Middleware-Technologien isolieren die Anwendungen von den Details der Vernetzung und ermöglichen es, verteilte Systeme zu erstellen, die robust sind und sich im Laufe der Zeit weiterentwickeln können. Sie erleichtern das Erstellen und Freigeben von Datenmodellen und unterstützen Kommunikationsmuster wie Publish-Subscribe und Remote-Service-Aufrufe, welche die Anwendungsentwicklung vereinfachen.
Viele harte Echtzeit-Systeme konnten diese Fortschritte jedoch nicht nutzen. Denn die Middleware- und Netzwerk-Technologien konnten nicht das Leistungsniveau oder den Determinismus – wie begrenzte Latenz und Jitter – bieten, was die Anwendung benötigte. Daher mussten dedizierte Lösungen Verwendung finden, darunter spezielle Industrieprotokolle und benutzerdefinierte Netzwerk-Hardware.
Die Kombination von DDS und TSN kann dieses Bild jedoch verändern und das Beste aus beiden Welten bereitstellen. 

Das Beste aus beiden Welten

TSN bietet eine einmalige Technologie, mit der Echtzeit-Verkehr über Ethernet bereitgestellt werden kann. Es ermöglicht die Definition der Timing-Anforderungen für jeden Flow und die Konfiguration der Netzwerkpfade einschließlich Switches, um sicherzustellen, dass die Anforderungen erfüllt werden. Zudem bietet es eine Isolation für verschiedene Flüsse, sodass der Echtzeit-Verkehr nicht durch andere Kommunikation im selben Netzwerk gestört wird. Da sich die Technologie jedoch auf einer niedrigen Ebene im Konfigurationsstack befindet, müssen Anwendungen die Flüsse, Paketgrößen, Frequenzen, Prioritäten und Netzwerk-Endpunkte konfigurieren. Während dies für einfache Anwendungen für einige Knoten und Flüsse möglich ist, wird es für komplexere Systeme extrem aufwendig und unübersichtlich.

DDS stellt eine ideale Technologie zur Integration von Anwendungen bereit, die aus separaten Komponenten bestehen. Es befindet sich näher an der Anwendung und bietet eine übergeordnete Schnittstelle in Bezug auf Themen, Anwendungsdatentypen und anwendungsrelevante QoS, zum Beispiel Zuverlässigkeit, Haltbarkeit, Priorität und Fristen. Zudem kümmert es sich um Details auf niedrigerer Ebene, wie das Erkennen der Endpunkte und das Einrichten der Kommunikationswege. Während DDS effiziente Binärprotokolle verwendet, kann es kein deterministisches Verhalten garantieren, da es die untergeordneten Netzwerk-Schichten nicht kontrolliert. Es muss also mit dem leben, was das zugrundeliegende Netzwerk, beispielsweise UDP/IP, bereitstellen kann.
 

Wie funktioniert DDS?

In einer datenzentrierten Architektur kommunizieren Anwendungen nicht miteinander. Ein Datenbus implementiert eine datenzentrierte Freigabe, die durch Filtern die richtigen zukünftigen Daten findet, wie der RTI Connext Databus.

© RTI

DDS ist ein von der Object Management Group (OMG) verwalteter offener und internationaler Standard, der sich direkt mit datenzentrischer Publish-Subscribe-Middle- ware für Echtzeit-Systeme befasst. DDS bietet eine umfassende Feinsteuerung der Echtzeit-Qualität von Service-(QoS)-Parametern, einschließlich Zuverlässigkeit, Bandbreitenkontrolle, Lieferfristen und Ressourcenlimits. 

Grundsätzlich ist DDS darauf ausgelegt, die Herausforderungen der Echtzeit-
Kommunikation anzugehen. Das datenzentrierte DDS-Publish-Subscribe-Modell (DCPS) verbindet anonyme Informationsproduzenten (Publisher) mit Informationskonsumenten (Subscriber). DDS definiert eine Kommunikationsbeziehung zwischen Publishern und Subscribern. Die Kommunikation ist im Raum (Knoten können überall sein), in der Zeit (Knoten und Themen) und im Datenfluss entkoppelt. DDS verwaltet explizit die Kommunikations-Datenmodelle oder Typen, die für die Kommunikation zwischen Endpunkten verwendet werden. 
Es handelt sich also um eine datenzentrierte Technologie, die wie eine Datenbank einen datenzentrierten Speicher bietet und den Inhalt der verwalteten Informationen versteht. Bei DDS dreht sich alles um die Daten. Deshalb wird es auch häufig als Datenbus bezeichnet, wie der Datenbus der RTI Connext DDS Software (siehe Bild oben).
Im Kern implementiert DDS ein verbindungsloses Datenmodell mit der Fähigkeit, Daten mit dem gewünschten QoS zu veröffentlichen und zu abonnieren. Der Datenbus erkennt automatisch und verbindet Publisher- und Subscriber-Anwendungen. Es sind keine Konfigurationsänderungen erforderlich, um eine neue intelligente Maschine zum Netzwerk hinzuzufügen (siehe Bild unten).

Wie arbeitet TSN?

Sowohl Datenbus als auch Datenbank erleichtern die Systemintegration erheblich und unterstützen eine größere Skalierbarkeit, höhere Zuverlässigkeit und Interoperabilität der Anwendungen.

© RTI

Time Sensitive Network bezeichnet eine Reihe von Standards der Time-Sensitive-Networking-IEEE-802.1-Arbeitsgruppe. Die Standards definieren Mechanismen für die zeitsensible Übertragung von definierten Daten über Ethernet-Netzwerke. Jede Standardspezifikation kann alleine verwendet werden und ist meist autark. Bei koordinierter Verwendung wird TSN als Kommunikationssystem sein volles Potenzial entfalten können. 
Die drei Grundkomponenten umfassen:

1.    Zeitsynchronisation: Alle teilnehmenden Geräte in der Echtzeit-Kommunikation haben ein gemeinsames, synchronisiertes Zeitverständnis.
2.    Zeitplanung und Traffic Shaping: Alle an der Echtzeit-Kommunikation teilnehmenden Geräte halten die gleichen Regeln bei der Auswahl von Kommunikationswegen und bei der Reservierung von Bandbreite und Zeitfenstern ein, möglicherweise mit mehr als einem simultanen Pfad, um Fehlertoleranz zu erreichen.
3.    Auswahl von Kommunikationspfaden, Pfadreservierungen und Fehlertoleranz: Zeitverständnis

Vorteile der Kombination von DDS und TSN

Reiner Duwe ist Sales Manager EMEA bei Real-Time Innovations (RTI).

© RTI

Es gibt mehrere Gründe, warum DDS und TSN gut zusammenspielen. Grundsätzlich bieten beide Technologien eine ‚One-to-many‘-Kommunikation, die unterschiedliche Zuverlässigkeitsstufen für die unterschiedlichen Datenströme unterstützt. DDS ist explizit als Standard für Echtzeit-Systeme definiert worden und hat sich in zahlreichen kritischen Anwendungen bewährt. DDS und TSN eignen sich, die hohen Anforderungen in der industriellen Automatisierung und im Automobilbereich zu erfüllen.
Warum lohnt sich eine Kombination von DDS und TSN? Warum können DDS-Nutzer davon profitieren, TSN als zugrundeliegendes Netzwerk zu nutzen und wie kann DDS dabei helfen, das volle Potenzial von TSN zu realisieren? 
Während die Interaktionsmodelle für DDS und TSN durchaus ähnlich sind – beide sind grundsätzlich One-to-many-Publish/Subscribe-Technologien – resultiert die Verwendung von DDS zusätzlich zu TSN in einem Programmiermodell auf einer höheren Abstraktionsebene. 

Höhere Abstraktionsebene

DDS-Nutzer entwickeln ihre Systeme durch das Produzieren oder Konsumieren stark typisierter, vordefinierter Datenelemente. Die Daten-Modellierungskonstrukte, die dafür unterstützt werden, sind vielfältig und modern.
Anwendungsentwickler sehen ihre Daten in den Konstrukten der nativen Programmiersprachen, während die Middleware alle untergeordneten Mechanismen wie De-/Serialisierung oder Netzwerk-Interaktionen abhandelt.

Einheitlicher Ansatz

TSN-Systemkonfiguration: Zu den wichtigsten DDS-Schnittstellen gehören das CUC-CNC-Nutzer-/Netzwerk-Protokoll und die CUC-TSN-Endpunktschnittstelle.

© RTI

Viele Systeme bestehen aus einer Kombination von Subsystemen mit unterschiedlichen Anforderungen und Fähigkeiten. Nicht alle Subsysteme erfordern ein hartes Echtzeit-Verhalten, wie es von TSN gewährleistet wird. DDS ermöglicht es, die Infrastruktur in verschiedenen Subsystemen wiederzuverwenden und eine nahtlose Verbindung durch Gateways unter Beibehaltung eines einheitlichen Datenmodells zu ermöglichen.
DDS agiert unabhängig von Betriebssystem und Programmiersprache und lässt sich als solche in verschiedenen Umgebungen nutzen (siehe Bild). 
Hier ist das verbindende Element zwischen den Subsystemen das Datenmodell und das vielfältige Ökosystem von DDS. Das vereinfacht die Aufgabe, TSN in ein bestehendes System oder Design einzuführen oder TSN-basierte Systeme um zusätzliche Subsysteme mit unterschiedlichen nicht-funktionalen Anforderungen zu erweitern.

DDS-TSN-Standardisierung

Die OMG hat die Notwendigkeit eines standardisierten Ansatzes für die Kombination von DDS und TSN erkannt – eine entsprechende Standarddefinition ist in Arbeit. Mit einbezogen werden hier Aspekte wie die Definition von Standardmechanismen zum Ausführen einer DDS-Laufzeit-Infrastruktur über ein TSN-Netzwerk oder die Beschreibung eines standardisierten Prozesses zum Ableiten von TSN-Netzwerk-Planungsinformationen aus DDS-Systembeschreibungen.
Solche offenen, allen zur Verfügung stehenden Standards werden es DDS- und TSN-Anbietern ermöglichen, ihre Integrationslösungen portierbar, interoperabel und herstellerunabhängig zu entwickeln.