DDS-XRCE
Databus-Architektur für schlanke Embedded-Systeme
Der Standard DDS-XRCE ermöglicht es, ressourcenbeschränkte Embedded-Systeme so zu behandeln, als wären sie normale DDS-Teilnehmer. Durch die Kombination von DDS-XRCE mit einer mehrschichtigen Datenbusarchitektur können Embedded-Systeme leicht in verteilte, echtzeitfähige Systeme integriert werden.
Die Integration von ressourcenbeschränkten Geräten in ein verteiltes, echtzeitfähiges System kann erhebliche Herausforderungen an die Entwickler stellen. Um die Stromaufnahme und die Größe zu reduzieren, werden die Geräte in der Regel mit minimalen Ressourcen für die Kommunikationssoftware gebaut.
Ein Software-Framework, das alte und moderne Systeme miteinander verbindet, ist der datenzentrierte Datenbus, der auf dem DDS-Standard (Data Distribution Service) [1] basiert. Der DDS-Standard stellt eine flexible und skalierbare Infrastruktur bereit, die sich bereits in Tausenden von Systemen bewährt hat. Ingenieure können damit mehrere – sogar Hunderte – von DDS-basierten Schichten (Datenbusse) erstellen, um die Kommunikation zu entkoppeln oder zu integrieren und gemeinsam zu nutzen. Um den unterschiedlichen Anforderungen dieser Systeme gerecht zu werden, bietet DDS eine Vielzahl von Mechanismen, insbesondere Quality of Service (QoS), Filterung, dynamische Erkennung und Sicherheit.
Um eine Interoperabilität mit (extrem) ressourcenbeschränkten Geräten zu erleichtern, hat die Object Management Group (OMG) kürzlich den DDS-XRCE-Standard (eXtremely Resource Constrained Environments) [2] verabschiedet. Dieser offene Standard ermöglicht die Integration eingebetteter Geräte in einen DDS-Datenbus mit minimalen Anforderungen an Speicherplatz und mit minimaler Stromaufnahme.
Zur Veranschaulichung hat RTI ein »Proof of Concept« entwickelt. Es verbindet das Mikrocontrollermodul Feather HUZZAH ESP8266 von Adafruit über DDS-XRCE mit einem optischen Pulssensor und mit einem mehrschichtigen Datenbus bis hin zu einer Cloud-basierten Webschnittstelle.
Datenbank versus Datenbus
Eine Datenbank und ein Datenbus verarbeiten beide strukturierte Daten, die entweder geschrieben oder gelesen werden, allerdings gibt es wichtige Unterschiede. Die Daten in einer Datenbank sind in »ruhendem Zustand« bzw. gespeichert; werden sie nicht gerade abgelegt oder abgerufen, bewegen sie sich nirgendwo hin.
Im Gegensatz dazu sind Daten, die von einem Datenbus verarbeitet werden, immer im Fluss. Darum eignet sich der Datenbus besser für Systeme, die Skalierbarkeit und Informationen in Echtzeit benötigen. Ein Datenbus ist keine konkurrierende Technik zu einer Datenbank, vielmehr spielen beide eine ergänzende Rolle bei der Verarbeitung von Daten (Tabelle).
Merkmale des DDS-Datenbus
Die Object Management Group veröffentlicht und pflegt die auf dem DDS basierenden Spezifikationen [1]. Die DDS-Kommunikationsschicht basiert auf einem Software-Datenbus mit einem Publish/Subscribe-Modell. Dieser Datenbus ist im Wesentlichen ein gemeinsam genutzter globaler Raum, in dem Daten kontinuierlich zu und von ihren beabsichtigten und autorisierten Empfängern fließen. Zu den Hauptmerkmalen von DDS gehören:
- Datenzentriertheit
- Eingebaute QoS (Quality of Service)
- Punkt-zu-Punkt-Verbindung
- Gemeinsames Datenmodell
- Automatische dynamische Erkennung von Applikationen auf dem Datenbus und im gleichen Netzwerk
- Sicherheit
Der Layered-DDS-Datenbus
Gibt es in einem Entwurf mehr als einen DDS-Datenbus und müssen Informationen zwischen diesen Datenbussen ausgetauscht werden, kommt der Layered-Datenbus ins Spiel. Ein mehrschichtiger (layered) Datenbus ist eine Multi-Domain-Datenbusarchitektur, bei der verschiedene Subsysteme von ihren eigenen Datenbussen bedient werden, wobei die Möglichkeit besteht, sie miteinander zu verbinden. Die Informationen, die zwischen den Datenbussen ausgetauscht werden, sind selektiv und basieren auf der DDS-Publish/Subscribe-Methode. Ein mehrschichtiger Datenbus kann die Komplexität einer Softwarearchitektur erheblich vereinfachen und so das Hinzufügen von Tausenden von Geräten ermöglichen. Diese Architektur bietet eine sichere Punkt-zu-Punkt-Datenkommunikation mit niedriger Latenz über logische Schichten des Systems hinweg.
Das Industrial Internet Consortium (IIC) empfiehlt in seiner Industrial Internet Reference Architecture (IIRA) [3] den Layered Databus als eine Kommunikationsarchitektur für industrielle IoT-Anwendungen (IIoT). Bei der IIRA handelt es sich um eine auf Standards basierende Architekturrichtlinie für die Entwicklung von IIoT-Systemen auf der Grundlage eines gemeinsamen Rahmens und eines gemeinsamen Architekturmusters. In der Regel werden Datenbusse am Rande eines Systems implementiert, wo Sensoren oder Geräte Daten in Maschinen oder untergeordneten Subsystemen sammeln und Teil eines komplexen Systems sind, z.B. Fahrzeug, Ölplattform oder Krankenhaus.
Auf einer anderen Hierarchieebene kann es einen oder mehrere Datenbusse geben, die zusätzliche Maschinen oder Systeme einbinden und die Datenkommunikation zwischen und innerhalb der übergeordneten Leitstellen- oder Backend-Systeme erleichtern. Die Backend- oder Leitstellenebene könnte der Datenbus der höchsten Ebene im System sein. Zu beachten ist, dass es viel mehr als die drei hier beschriebenen Datenbusse geben kann, wie das Beispiel der Überwachung am Patientenbett zeigt (siehe Bild 1).
Definition der Schichten
Ein Layered-Datenbus ermöglicht die Trennung und Sicherung verschiedener Domänen. Die Datenisolierung ist eine entscheidende Komponente einer schichtweisen Datenbusarchitektur, die sicherstellt, dass nur die relevanten Informationen über die Schichten hinweg ausgetauscht werden. Vorteilhaft ist die Konsistenz bei der Skalierung: Weil jede Schicht die gleiche Struktur und die gleichen Funktionen des DDS-Datenbus hat, entfällt die Notwendigkeit, für jede Schicht eine neue Datenarchitektur von Grund auf neu zu erstellen. Der erste Schritt besteht in der Definition der Schichten. Diese Entscheidungen können auf folgender Grundlage getroffen werden:
- Unterschiedliche zeitliche Anforderungen, Isolierung zeitkritischer Systeme von anderen
- Unterschiedliche Datenanforderungen, alle Daten oder eine Teilmenge
- Bestehende, nicht veränderbare Systeme
- Standort, um die Vorteile eines optimierten Transports, wie der eines gemeinsamen Speichers zu nutzen
- Funktion oder Zweck, z. B. eine Überwachungsschicht oder eine Analyseschicht
- Interessenbereich, der einschränkt, wer auf die Daten zugreifen kann.
Verbindung der Schichten
Jede Schicht muss eine logische Verbindung mit der/den anderen haben, manchmal auch als Brücke oder Gateway bezeichnet, wie etwa das RTI-Gateway (RTI Routing Service), das auf DDS-Konzepten basiert und umfangreiche Dienste bereitstellt – und den Entwicklern mehr Flexibilität bei der Anwendung dieser Dienste gibt. Hier einige Beispiele:
- Die Datenflusskontrolle innerhalb und zwischen den Schichten wird über QoS-Einstellungen konfiguriert, die festlegen, wie die Daten geliefert werden.
- Filtern, welche Daten ein bestimmtes Kriterium erfüllen, z. B. über oder unter einem bestimmten Wert, wie Temperatur oder Dichte. Daten, die den Parametern nicht entsprechen, werden nicht freigegeben. Das erlaubt eine hochgranulare Auflösung der Datentrennung, wobei einzelne Daten auf der Grundlage bestimmter Werte – entweder an der Quelle oder am Ziel – getrennt werden.
- Das dynamische Erkennen erfolgt automatisch, aber auch kontrolliert. Zum Beispiel können Entwickler die automatische Erkennung zwischen Schicht 1 und Schicht 2 festlegen, aber mit Teilnehmern in Schicht 3 unterbinden.
Interoperabilität der Schichten
Mit dem DDS-Datenbusstandard haben die Entwickler mehr als eine Möglichkeit, Interoperabilität zu schaffen:
- Übersetzung zum Ändern von Informationen, z. B. Übersetzung der Temperatur von Fahrenheit in Celsius
- Gateways, um verschiedene Techniken zu verbinden, z. B. DDS mit MQTT oder ➔ Distributed Interactive Simulation Protocol (DIS) [4]
- Ergänzungen zur Unterstützung einer alten API in einer neuen Umgebung oder umgekehrt einer neuen API in einer älteren Umgebung.
Aufteilung der Schichten
Wie viele Schichten werden für einen Entwurf benötigt? Gibt es eine Mindest- oder Höchstzahl?
Es ist sinnvoll, diese Frage bereits zu Beginn des Entwurfsprozesses zu erörtern und während des Entwurfs und der Erstellung erneut aufzugreifen. Der Prozess des Zerlegens eines großen Systems in eine Sammlung von Subsystemen (oder Schichten) wird als Dekomposition bezeichnet. Dazu gibt es viele Möglichkeiten. Bei jedem Entwurf ist es wichtig zu entscheiden, wann die Architektur genügend Schichten hat, um die Aufgabe zu erfüllen, aber nicht so viele, dass unnötige Komplexität hinzukommt.
Es hat sich bewährt, eine Schicht hinzuzufügen und dann den logischen Dekompositionstest anzuwenden. Entspricht sie den Anforderungen oder ist die Leistung nicht so gut, wie sie sein müsste, ist der nächste Schritt das Hinzufügen eines weiteren Kriteriums. Zu den drei am häufigsten verwendeten Metriken zur Bewertung der Sinnhaftigkeit einer Schicht in einer Multi-Layer-Architektur gehören die Startzeit (Discovery Time), die Verfügbarkeit von Ressourcen und die Latenzzeit.
Sicherheit
Der DDS-Datenbus erfüllt die gängigen Sicherheitsanforderungen, indem er Authentifizierungs-, Zugriffskontroll-, Kryptographie- und Protokollierungsfunktionen für eine sichere Datenverteilung bietet. Weil die DDS-Sicherheit in einem separaten Modul implementiert und damit unabhängig von der Anwendungslogik ist, kann sie separat konfiguriert werden, ohne dass der Programmcode angepasst werden muss. Diese Trennung ermöglicht es, dass sich das Datenmodell, die Logik und die Sicherheitsanforderungen der Anwendung unabhängig voneinander entwickeln können.
- Databus-Architektur für schlanke Embedded-Systeme
- Anschluss ressourcenbeschränkter Geräte an den Datenbus
