Echtzeit Flexible Echtzeit-Konnektivität für verteilte Systeme in großem Maßstab

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Real-Time Innovations International - Zweigniederlassung Deutschland

Bei groß angelegten verteilten Systemen kann es eine Herausforderung sein, eine große Anzahl von zugrunde liegenden Technologien, Plattformen, und Protokollen zu integrieren.

Man denke dabei an Systeme wie Unterwasserdrohnen, ferngesteuerte medizinische Geräte, Raumfahrtsysteme oder Bau- und Bergbauroboter. Zu diesen Systemen gehören oft ressourcenbeschränkte Geräte mit strengen Anforderungen an den Strom- und Speicherbedarf, was ihre Fähigkeit zu fortgeschrittenem Verhalten wie Entscheidungsfindung oder Teilnahme an datenzentrierter Kommunikation stark einschränkt. Diese Kommunikation kann über LAN (local area network) oder WAN (wide area network) mit unterschiedlichen Konfigurationen stattfinden. Somit könnte eine geschichtete Datenbus-Architektur dazu beitragen, Echtzeit-Konnektivität von Edge-to-Edge und Edge-to-Cloud für große und weit verteilte Systeme herzustellen.

Treffen Sie die Experten der Branche in Sindelfingen

Europas Leitkongress für Embedded Software Professionals

Jedes Jahr im Dezember treffen sich über 1.200 Professionals, um sich über aktuelle Technologien und Methoden zu informieren, Trends zu diskutieren sowie die Weichen für die Zukunft zu stellen.

In 14 Seminaren, 95 Vorträgen und 3 Keynotes warten fachlich fundierte und praxisnahe Inhalte auf die Teilnehmer des ESE Kongress. Der Kongress ist die ideale Plattform, um sich über moderne Methoden des Software Engineering und den Stand der Technik zu informieren. Melden Sie sich an und werden Teil der Embedded-Software-Community.

Jetzt informieren

Eine der größten Herausforderungen bei der Implementierung eines weltweit verteilten Echtzeit-Systems ist die flexible und zuverlässige Kommunikation über das Internet.

Wegen der begrenzten Verfügbarkeit von IP4-Adressen laufen die meisten Geräte hinter einer NAT/Firewall, von denen viele keine feste öffentliche IP Adresse haben. Das macht eine direkte Punkt-zu-Punkt-Kommunikation schwierig, denn die Zuweisung fester IP Adressen und die Aufrechterhaltung permanenter (manueller) Port-Zuordnungen in diesen NATs/Firewalls ist umständlich, fehleranfällig und nicht gut skalierbar. Um eine zuverlässige Kommunikation zwischen den Geräten, die sich hinter den verschiedenen NATs befinden, zu ermöglichen, umfassen die derzeitigen Lösungen in der Regel das Hinzufügen von Relais in der Cloud und/oder die Verwendung von TCP (Transmission Control Protocol).

Allerdings ermöglichen diese Lösungen keine skalierbare Echtzeitkommunikation, weil Relais unnötige Latenzen verursachen und TCP ein unberechenbares Zeitverhalten aufweist. Zudem werden sie in der Regel nicht der IP-Mobilität oder andere dynamischen Aspekten von großen verteilten Systemen gerecht.

Systeme mit (extrem) ressourcenbeschränkten Umgebungen (XRCE Xtremely Resource Constrained Environments) verschärfen diese Herausforderung noch weiter. Dabei handelt es sich um Geräte, die aufgrund ihrer sehr begrenzten Ressourcen normalerweise nicht die Implementierung eines vollwertigen Netzkommunikations-Stucks erlauben. Das macht ihre Integration in ein System-of-Systems oft zu einer mühsamen Aufgabe voll proprietärer und unflexibler Behelfslösungen.

Zwei neuere Entwicklungen tragen nun dazu bei, diese Herausforderungen zu bewältigen. Erstens das DDS-XRCE Protokoll, das 2020 als offener Standard adaptiert wurde und die Vorteile des Data Distribution ServiceTM (DDS) Standards für die Kommunikation mit kleinen, embedded Devices nutzt.

Zweitens hat RTI eine Echtzeit-WAN-Transportfunktion eingeführt, die die sicheren, skalierbaren und leistungsstarken Kommunikationsfähigkeiten von Connext DDS auf Weitverkehrsnetze, einschließlich des öffentlichen Internets, ausweitet, um Hochleistungskonnektivität über heterogene Netzwerke zu unterstützen. Zusammen mit dem Cloud Discovery Service (CDS) ermöglicht diese Transportfunktion eine sofort einsatzbereite Echtzeitkommunikation über WANs und LANs.

Um zu veranschaulichen, wie diese beiden Entwicklungen in einer Layered Datenbus-Architektur kombiniert werden können, behandelt dieser Beitrag das Konzept des Layered Datenbus inklusive Definition, Verbindung und Zerlegung von Schichten.

Er beschreibt einen PoC (Proof of Concept), der einen Adafruit Huzzah Feather ESP8266 über die DDS-XRCE mit einer Überwachungs- und Steuerungsanwendung über das öffentliche Internet verbindet.

Anmerkung: Oft werden bei der Beschreibung der Layered Databus Architecture die Begriffe "Layer" und "Domain" synonym genutzt. Speziell in diesem Dokument wird (und in der DDS-Norm) der Begriff "Domänenteilnehmer" verwendet, um alle Arten von miteinander verbundenen "Dingen" wie Sensoren, Geräte, Anwendungen, Endpunkte, Benutzer, Systeme usw. zu erfassen.

Der DDS Datenbus

Die standardisierte DDS Kommunikationsschicht basiert auf einem Software Datenbus, der über ein Publish/Subscribe Modell läuft. Somit ist der Datenbus im Wesentlichen ein gemeinsam genutzter, globaler Raum, in dem kontinuierlich Daten von und zu autorisierten Empfängern fließen. Zu den Schlüsseleigenschaften von DDS zählen:

• Datenbewusstheit, das beispielsweise ein intelligentes Filtern von Daten und das Bereitstellen von Daten an der richtigen Stelle zur richtigen Zeit ermöglicht.

• Eingebaute Servicequalität (QoS): Parameter, die die Gestaltung der gesendeten oder empfangenen Daten bestimmen, z. B. die Geschwindigkeit, mit der die Daten neu veröffentlicht werden, die Zuverlässigkeit der Zustellung und die Sicherheitsanforderungen für jeden Datenfluss.

• Punkt-zu-Punkt-Verbindung: Eliminiert Datenserver oder Zwischenhändler und ermöglicht Skalierbarkeit und Erweiterbarkeit in mehrschichtigen Datenbussen. Anwendungen können Datenwerte direkt lesen und schreiben, was Engpässe beseitigt und zu einer schnellen, effizienten Kommunikation beiträgt.

• Gemeinsames Datenmodell: Entwickler können alle Datenflüsse in ihren Systemen definieren, ohne dass sie Codes schreiben müssen; sie können das von ihnen bevorzugte Datenmodell verwenden; Datenmodelle sind über alle Schichten und den Lebenszyklus der Anwendung hinweg konsistent.

• Automatische dynamische Erkennung von Anwendungen auf dem Datenbus/im gleichen Netzwerk: Eine neue Anwendung oder ein neues Gerät, das dem Datenbus beitritt, wird zeitnah erkannt und kann mit zuvor veröffentlichten Zustandsdaten versorgt werden.

• Integriertes System: Alle Anwendungen, Geräte, Module und Subsysteme arbeiten als ein integriertes System zusammen.

• Sicherheit: Der DDS-Standard umfasst eine Plug-in-Sicherheitsarchitektur, die bietet Mechanismen bietet wie Authentifizierung, datenzentrierte Zugriffskontrolle, Kryptographie, Datenkennzeichnung und -protokollierung und gesicherte Multicast Kommunikation.

Der geschichtete DDS-Datenbus

Wenn mehr als ein DDS-Datenbus innerhalb eines Entwurfes existieren und zwischen diesen Datenbussen Informationen ausgetauscht werden müssen, kommt der Layered Datenbus ins Spiel. Darunter versteht man eine Multi-Domain-Datenbus-Architektur, bei der verschiedene Subsysteme von ihren eigenen Datenbusse bedient werden, wobei die Möglichkeit besteht, sie miteinander zu verbinden.

Die zwischen den Datenbussen ausgetauschten Informationen können konfigurativ ausgetauscht werden. Ein mehrschichtiger Datenbus kann die Komplexität einer Softwarearchitektur erheblich vereinfachen, indem er eine einheitliche Kommunikationsarchitektur für verteilte und/oder ungleiche Systeme bereitstellt und dabei buchstäblich eine unbegrenzte Skalierung ermöglicht. Diese Architektur bietet eine sichere Punkt-zu-Punkt-Datenkommunikation mit niedriger Latenz über logische Schichten des Systems hinweg. Zudem bieten Layered Datenbusse noch weitere Vorteile:

• Eine schnelle Gerät-zu-Gerät Integration mit Übertragungszeiten innerhalb von Milli- oder Mikrosekunden,

• eine automatische Erkennung von Daten und Anwendungen mit und zwischen Datenbussen,

• eine skalierbare Integration von Hunderten oder sogar Tausenden von Domain-Teilnehmern,

• eine natürliche Redundanz, die eine extreme Verfügbarkeit und Ausfallsicherheit ermöglicht,

• eine hierarchische Isolierung von Subsystemen, die die Entwicklung komplexer Systemdesigns ermöglicht, und

• Sicherheit, die über jede Standard-API anpassbar ist und über jede Art von Transport läuft.

Üblicherweise implementiert man Datenbusse am Rand eines Systems, wo Daten von Sensoren oder Geräten gesammelt werden, die in intelligenten Maschinen oder Subsystemen Verwendung finden, und die ihrerseits wiederum Teil eines komplexen Systems sind (z. B. Auto, Ö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 des übergeordneten Kontrollzentrums oder der Backend-Systeme erleichtern. Die Leitstellen- oder Backendebene könnte der höchste Datenbus der höchsten Ebene im System sein, wobei es weit mehr als nur die drei hier beschriebenen Ebenen geben kann.

(-> siehe hierzu Abbildung.1)

Sicherheit ist auf allen Ebenen wichtig. Da die DDS-Sicherheit in einem separaten Modul implementiert und so von der Anwendungslogik unabhängig 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, ohne dass sie sich gegenseitig oder die Architektur des Systems beeinflussen. In einem mehrschichtigen Datenbus können sowohl sichere als auch unsichere Domänen interagieren, wobei Brückenkomponenten wie der RTI Routing Service zur Integration verschiedener Sicherheitsrichtlinien und -konfigurationen eingesetzt werden.

Das Verbinden des Layered Datenbus über WAN

Der Echtzeit-WAN-Transport ist in der Lage, die Layered Datenbus Architektur so zu erweitern, dass die zusätzlichen Anforderungen von WANs, wie das Überwinden von Firewalls und NATs, bedient werden. Der Echtzeit WAN Transport besteht aus zwei Komponenten:

• Auf der Anwendungsseite ermöglichen QoS-Einstellungen es der Anwendung, andere Systeme über ein festes IP/Port-Paar zu verbinden.

• Wenn keine feste öffentliche IP für das individuelle Netzwerk zur Verfügung steht, ermöglicht der Cloud Discovery Service (CDS) die Erkennung und Initiierung der direkten Punkt-zu-Punkt Kommunikation, wenn es technisch möglich ist.

In beiden Fällen gewährleistet der Echtzeit-WAN-Transport volle Flexibilität, um den individuellen Anforderungen der Datenströme gerecht zu werden. Ist etwa eine feste öffentliche IP-Adresse verfügbar, kann er die direkte DDS-Erkennung und den Datenaustausch entweder durch direkte Anbindung der Anwendung an diese Adresse oder durch Port-Weiterleitung an der NAT/Firewall herstellen. Das feste öffentliche IP/Port-Paar muss dafür nur auf einer Seite einer Teilnehmerpaarung vorhanden sein, die andere Seite kann anhand der von ihr gesendeten UDP-Pakete ermittelt werden.

Steht keine feste öffentliche IP zur Verfügung, oder macht die Systemgröße eine Konfiguration mit einer festen öffentlichen IP unpraktisch, ermöglicht der Cloud Discovery Service (CDS) eine sofort einsatzbereite WAN-Kommunikation. Durch die Zuordnung privater Adressen zu öffentlichen Adressen und deren Bereitstellung für andere Teilnehmer, können diese sich gegenseitig „sehen“, als befänden sie sich im selben LAN.

Der CDS wird an einem Ort installiert, an dem eine feste öffentliche IP verfügbar ist (nicht unbedingt ein Cloud Server), so dass Anwendungen hinter NATs und Firewalls eine Verbindung zu dieser IP-Adresse herstellen können. CDS leitet dann den Discovery-Verkehr an die anderen angeschlossenen Teilnehmer weiter, so dass diese die Datenproben direkt von Punkt-zu-Punkt transportieren können. In beiden Fällen kann DDS Secure verwendet werden, um den Datenverkehr über das WAN zu sichern.

Anschluss von ressourcenbeschränkten Geräten an den Datenbus

Zur leichteren Integration von ressourcenbeschränkten Devices in den Datenbus hat die OMG den DDS-XRCE-Standard eingeführt. Wegen begrenzter Ressourcen (Speicher, Rechenleistung, Kommunikationsbandbreite) waren viele kleine Geräte mit niedrigem Stromverbrauch in der Regel nicht für die DDS-basierte Kommunikation geeignet. Ihre Einbindung in den Datenbus ist jedoch seit Langem eine Anforderung, die die Entwickler dazu zwingt, auf proprietäre Lösungen zurückgreifen. DDS-XRCE bietet eine Lösung für dieses Problem: Das auf Standards basierende Client-Server-Protokoll ist für Implementierungen mit minimalen Ressourcen optimiert und ermöglicht Architekten die nahtlose Einbindung von Embedded-Geräten in eine DDS-basierte geschichtete Datenbus-Schichtarchitektur .

Proof of Concept (PoC) Anwendung

Zur Darstellung, wie man ressourcenbeschränkte Geräte ganz einfach in eine reale DDS-Anwendung integrieren kann, entwickelte RTI ein Proof-of-Concept. Beschrieben wird ein Anwendungsfall für die Patientenüberwachung, weil die Vorzüge eines platzsparenden Geräts in diesem Zusammenhang auf der Hand liegen: Überwachungsgeräte, die am Körper getragen werden, erhöhen den Komfort der Patienten durch die erlangte Bewegungsfreiheit deutlich, da sie sich frei bewegen können.

Ein reales System kann aus mehreren Schichten bestehen, und die sensiblen Patientendaten, die zwischen diesen Ebenen fließen, werden durch Anwendung der DDS- Sicherheit² vor unbefugten Zugriffen geschützt. Dieses PoC beschreibt ein vereinfachtes Beispiel für das Erfassen von Patientendaten und deren sichere Übertragung an eine Fernüberwachungs- und Steuerungsanwendung über das öffentliche Internet. Aufgrund der großen Verfügbarkeit und der guten Dokumentation erhielt ein Adafruit Huzzah Feather ESP8266-Board den Zuschlag, das WiFi-Konnektivität bietet und geringen Stromverbrauch hat.

Die vorgefertigten Stubs von RTI ermöglichten es, die für diesen PoC benötigten funktionalen Änderungen mit einem nur 10 Zeilen umfassenden Code zu realisieren. Das Programm wurde auf einem normalen PC ausgeführt, läuft aber auch auf kleineren Boards, wie einem Raspberry Pi. Sobald die Daten auf dem Datenbus waren, kam der RTI-Routing Service zum Einsatz, um die Daten an eine in der Cloud laufende Webanwendung weiterzuleiten. Zur Authentifizierung von Fernteilnehmern und zur Verschlüsselung der Teilmenge von Daten, die den Patienten identifizieren, wurden Sicherheitsrichtlinien eingeführt. Die XRCE-Kommunikation war nicht gesichert.

Eine schematische Übersicht zeigt Abbildung 2.

Eine Layered Datenbus-Architektur schafft eine virtuelle Plug-and-Play-Kommunikationsplattform zur Modernisierung und Erweiterung von Legacy-Anwendungen und -Systemen. Dadurch entfällt die Notwendigkeit, proprietäre monolithische Systeme neu zu kompilieren, neu zu erstellen, neu zu validieren und zurückzusetzen, wenn ein neues System angeschlossen werden muss.

Layered DDS-Datenbusse lösen komplexe Probleme der Erweiterung und Skalierbarkeit, ohne die feinkörnige Kontrolle zu opfern, die komplexe, vernetzte Designs voraussetzen.

Eine solche Architektur ermöglicht relativ einfach die Interaktion von proprietären Systemen mit neuen Systemen. Die Schichten sind transparent und arbeiten automatisch: Sie trennen und teilen sich je nach den Anforderungen der Betreiber und Teilnehmer des Anwendungsbereichs. Der DDS-XRCE-Standard erweitert diese flexible Integration, indem er die DDS-basierte Kommunikation mit Embedded-Geräten mit eingeschränkten Ressourcen erleichtert. Der Real-Time-WAN-Transport dehnt diese Flexibilität der Integration auf Wide Area Networks aus.

Die Layered Databus Architecture bewahrt die Integrität von Legacy-Systemen und öffnet gleichzeitig die Designs für eine unbegrenzte Anzahl neuer Teilnehmer. Entwickler sind gerüstet für die Zukunft: Sie können damit eine nachhaltige Architektur schaffen, die eine Brücke von ihren Altsystemen zu modernen Systemen schlägt und gleichzeitig zukünftige Flexibilität und Anforderungen berücksichtigt.

 (mbf)

* Thijs Brouwer, Field Application Engineer, RTI: tbrower@rti.com: Thijs hat über mehr als 15 Jahre Erfahrung als Entwickler von C/C++-Software für Projekte, die von Electronic Design Automation über Embedded-Projekte für Automobilkunden bis hin zur Entwicklung eines Linux-Kernel-Moduls für VoIP-Anwendungen reichen. Seit 20202 unterstützt er RTI als Field Application Engineer in der EMEA-Region bei der Integration von RTI Connext DDS in die Systeme seiner Kunden. Thijs hat die Universität von Amsterdam mit einem MSc-Abschluss in Mathematik abgeschlossen.

* Maxx Becker, Anwendungsingenieur, RTI: maxx@rti.com: Maxx verfügt über Erfahrungen in der Softwareentwicklung für komplexe verteilte Steuerungssysteme, die er zuvor bei der National Ignition Facility am Lawrence Livermore National Laboratory und zuletzt bei Virgin Hyperloop gesammelt hat, wo er mit Connext DDS den weltweit ersten Hyperloop-Prototypen in Originalgröße gebaut hat. Als Field Application Engineer in Mitteleuropa hilft er nun Softwareentwicklern und Architekten, die Vorteile von Connext DDS zu verstehen. Maxx hat einen BSc in Informatik und Technik von der University of California, Davis.

(ID:48691279)