Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
4 4 | w w w c o m p u t e r - a u t o m a t i o n d e · 0 9 -2 5 Ti m e -Se n s i t i v e Ne t w o r k i n g Updates beobachten Diese Interessensgranularität wird als ‚Topic‘ bezeichnet typische DDS-Systeme enthalten von einem bis zu mehreren hundert Topics Die Kombination eines DataWriters mit seinem Topic-Namen kann als Kennung der Quelle eines DDS-Datenflusses betrachtet werden Alle kompatiblen DataReader einzeln oder in Kombination stellen Senken für denselben Datenfluss dar Analog dazu gibt es bei TSN ‚Talker‘ die einen oder mehrere Streams aktualisieren und Daten an verbundene ‚Listener‘ liefern Solche TSN-Streams werden durch ihren VLAN-Tag-IDs identifiziert die Kombination eines Talkers mit einer VLAN-Tag-ID kann als Identifikator der Quelle eines TSN-Streams betrachtet werden Damit wird deutlich wie DDS-Datenflüsse direkt auf TSN-Streams abgebildet werden können Da die meisten DDS-Systeme bereits IP-Multicasting nutzen ist es naheliegend diesen Mechanismus durch die Kommunikation über TSN-Streams zu ersetzen Auf Anwendungsebene wären die Auswirkungen minimal da die Details des zugrunde liegenden Transports für DDS-Benutzer nicht sichtbar sind • Dienstgüte QoS und TSN-Traffic-Klassen Neben der Oneto-Many-Natur verfügt DDS über eine Vielzahl von QoS-Einstellungen die unter anderem die Wichtigkeit und Dringlichkeit der Informationen steuern Im Einklang mit der datenzentrierten Philosophie werden diese QoS-Einstellungen pro Datenfluss angewendet Einige dieser QoS-Einstellungen ähneln den Mechanismen der TSN-Traffic-Klassen zum Beispiel ‚Deadline‘ ‚LatencyBudget‘ und ‚TransportPriority‘ Andere QoS-Einstellungen auf DDS-Ebene lassen sich nutzen um den richtigen TSN-Stream auszuwählen Mit anderen Worten Durch korrekte QoS-Auswahl auf DDS-Ebene können Systementwickler das Datenverteilungsverhalten von der produzierenden Anwendung bis hin zur Netzwerkschicht und zurück zur konsumierenden Anwendung steuern • Vorhersagbarer Datenverkehr mit geringer Latenz Der DDS-Standard ‚Data Distribution Service for Real-Time Systems‘ wurde für die Implementierung von Echtzeitsystemen entwickelt und findet dort Verwendung Best Practices für Echtzeitverhalten sowie Hochleistungsmechanismen wurden berücksichtigt Tausende von Systemen basieren auf DDS-Infrastrukturen Dies zeigt dass bestehende DDS-Ökosysteme für Anwendungsbereiche geeignet sind die auch durch TSN-Technologien adressiert werden zum Beispiel Automobilindustrie oder industrielle Automatisierung Mit DDS das Potenzial von TSN entfalten Bisher ging es um die grundlegenden Gemeinsamkeiten zwischen DDS und TSN Doch was bietet DDS zusätzlich zu TSN sodass sich eine Kombination der beiden Technologien lohnt? • Höhere Abstraktionsebene Obwohl sich die Interaktionsmodelle von DDS und TSN ähneln führt die Anwendung von DDS auf TSN zu einem höheren Abstraktionsgrad DDS-Nutzer entwickeln ihre Systeme indem sie stark typisierte vordefinierte Datenelemente produzieren oder konsumieren Die dafür unterstützten Datenmodellierungskonstrukte sind umfangreich und modern Anwendungsentwickler sehen ihre Daten in Konstrukten der nativen Programmiersprachen während die Middleware alle untergeordneten Mechanismen De-Serialisierung oder Netzwerkinteraktionen abhandelt • Standardisierte Interaktionen DDS besteht aus einer Gruppe offener Standards Diese beinhalten eine standardisierte API für Anwendungsentwickler Durch die DDS-TSN-Integration werden die Einarbeitung vereinfacht die Wartungskosten gesenkt und das Ökosystem unterstützt • Skalierbarkeit für kritische Systeme DDS ist für großskalige missionkritische Systeme konzipiert Die Kombination mit TSN bewahrt diese Eigenschaften für zuverlässige sichere Systeme • Einheitlicher Ansatz Viele Systeme bestehen aus Subsystemen mit unterschiedlichen Anforderungen und Fähigkeiten Nicht alle Subsysteme benötigen das strenge Echtzeitverhalten das TSN bietet Mit DDS kann dieselbe Infrastruktur in verschiedenen Subsystemen wiederverwendet und diese Bild 2 Datenflüsse in einem typischen „intelligenten” System Bil d RT I 2025 sps 2025 Wir sind dabei computerautomation de sps euchner