Datenzentrischer Datenbus unterstützt zukunftssichere Architekturen

Die Automobilindustrie muss sich der möglicherweise größten Herausforderung im Bereich des autonomen Designs stellen: dem unkontrollierbaren und unvorhersehbaren Chaos auf öffentlichen Straßen. Beim Fahrzeugdesign für die Autonomie-Stufen 3 bis 5 (Bild 1) gibt es drei große Designherausforderungen, von denen jede einzeln weitgehend Neuland für OEMs bedeutet:

• 1. Sensorfusion aus zahlreichen Daten-Quellen zu ermöglichen, die gewaltige unstrukturierte Datenflüsse erzeugen.
• 2. Immer komplexere Systeme schneller und zu geringeren Entwicklungskosten zu erstellen.
• 3. Skalierbarkeit und Zukunftssicherheit sicherzustellen.

Der CAN-Bus ist ausgereizt

Bild 1: Um den Fortschritt in Richtung der Autonomie-Stufen 3 bis 5 zu beschleunigen und gleichzeitig kritische Anforderungen wie Sicherheit und Latenz zu erfüllen, ist ein standardbasiertes datenzentriertes Framework erforderlich. RTI

Die traditionelle Architektur von Fahrzeugen basiert auf dem Einsatz elektronischer Steuergeräte (ECUs) für verschiedene Subsysteme. Das Controller Area Network (CAN-Bus) stellt die Verbindung mit den Steuergeräten her, wo auch immer eine Kommunikationsschleife erforderlich ist. Ein durchschnittliches Fahrzeug verfügt heute über 100 bis 200 Steuergeräte – diese Zahl muss für die nächste Generation drastisch sinken. Das bedeutet, Wege zu finden, um einen Teil dieser Rechenleistung zu konsolidieren.

Schon um die Autonomie-Stufe 2 zu erreichen, reizen OEMs die Grenzen des CAN-Busses aus. Das Hinzufügen von Steuergeräten erhöht jedoch das Gewicht und die Kosten des Fahrzeugs und verringert die Kraftstoffeffizienz. Da es keine Möglichkeit gibt, Anwendungen über mehrere Steuergeräte hinweg gemeinsam zu nutzen ist es notwendig, einige Features und Funktionen zu duplizieren. Um Steuergeräte zu eliminieren oder zu konsolidieren, liegt eine Option in der Integration eines Domaincontrollers in das Fahrzeug, was einen Schritt näher an die Schaffung eines zentralisierten Verarbeitungssystems führt.

Echtzeitverbindungen zur Cloud entwickeln sich zum Standard. Dafür ist es erforderlich, hochauflösende Standortinformationen zu unterstützen, mit denen sich die Position des Fahrzeugs auf den Zentimeter genau lokalisieren lässt. Hochauflösende und in Echtzeit aktualisierte Karten, zentimetergenaue Lidar-Sensordaten und V2X-Daten anderer Autos, Personen und der Straßeninfrastruktur sind gute Beispiele für die dynamischen und Bandbreiten-intensiven Daten, die ein neues System im Griff haben muss. OEMs versuchen, Architekturen für die nächsten fünf bis zehn Jahre zu planen, die all das und noch mehr berücksichtigen. Das erfordert Flexibilität bei der Bereitstellung von Anwendungen.

Der CAN-Bus ist hardwareabhängig und funktioniert nur mit kabelgebundenen Komponenten im Fahrzeug, was seine Fähigkeit einschränkt, die Grundlage für die vielen erforderlichen Autonomie-Funktionen zu bilden. Bei autonomen Fahrzeugen ist der CAN-Bus völlig ausgereizt.

Bild 2: Der DDS-Datenbus verbindet primäre Autonomiefunktionen wie Sensorfusion und Pfadplanung. Zudem teilt er ein gemeinsames Datenmodell mit anderen Systemen und Standards (einschließlich Autosar Adaptive und ROS2). RTI

Neue Ethernet-basierte Kommunikationsprotokolle wie SOME/IP bieten mehr Funktionen, eignen sich jedoch besser für die Verteilung großer Datenmengen und hochdynamische Systeme. Um ihre Architekturen zukunftssicher zu machen, vermeiden Designer lieber die Erstellung einer Codebasis, die für ein bestimmtes Steuergerät entwickelt wurde. Stattdessen soll die Codegenerierung auf dem Steuergerät, dem Domaincontroller, dem zentralen Verarbeitungssystem oder über die Cloud ausführbar sein. Es gibt nur sehr wenige Technologien, die dieses Maß an Flexibilität unterstützen.

Der standardisierte datenzentrierte DDS-Datenbus

Um all dies zu berücksichtigen, ist ein standardbasiertes Framework erforderlich, das für besonders komplexe industrielle Systeme entwickelt wurde. Der von der Object Management Group (OMG) entworfene Data-Distribution-Service-Standard (DDS) definiert ein datenzentriertes Open-Integration-Framework für Softwareanwendungen.

DDS ist transportunabhängig, QoS-fähig und kann jedes Datenvolumen aus praktisch jeder Anzahl an Quellen verarbeiten. Wie in Bild 2 dargestellt, ermöglicht der DDS-Datenbus

• Interoperabilität zwischen Anwendungen, die auf verschiedenen Implementierungen ausgeführt werden
• Interoperabilität zwischen Quellen, die für verschiedene Anbieter geschrieben wurden.

Tabelle 1: Autonome Systeme erfordern eine Sensorfusion für große Datenmengen. RTI

Eine datenzentrierte Konnektivitätsarchitektur basiert auf einem Softwaredatenbus. Der Datenbus ist für extrem komplexe Systeme wie ein autonomes Fahrzeug ausgelegt. Er fungiert als gemeinsam genutzter Anwendungsbereich, in dem alle Daten gespeichert sind. So können Applikationen und Geräte als ein integriertes System zusammenarbeiten. Zudem verteilt der Datenbus bewegliche Daten im Gegensatz zu einer Datenbank, die Daten in Ruhe verwaltet. Die Daten dienen als Schnittstelle zwischen den Geräten, werden jedoch nicht zwingend abgespeichert. Es ist nicht notwendig, Nachrichten über Broker zu senden, um auf die Daten zugreifen oder sie verarbeiten zu können. Das ist eines der Schlüsselattribute, das eine Echtzeitantwort (oder extrem niedrige Latenz) mit einem hohen Datenvolumen aus mehreren Quellen ermöglicht.

Sensorfusion aus zahlreichen Quellen ermöglichen

Das Datenvolumen steigt mit jeder Autonomieebene (Tabelle 1). Für die Verarbeitung eines größeren Datenvolumens ist es nötig, mehr Rechenleistung und Speicher hinzuzufügen, was Kosten verursacht. Der DDS-Datenbus vereinfacht die Handhabung unstrukturierter Umgebungen erheblich und ist für große und vielfältige Datenflüsse ausgelegt. Ohne datenzentriertes Framework benötigen Designer zwei oder drei verschiedene Protokolle, um all diese Variablen zu bewältigen. Beispielsweise würden sie ein Protokoll für das Streaming und ein anderes für die Steuerfunktionen benötigen.

DDS stellt eine einzige Standard- und Anwendungsprogrammierschnittstelle (API) dar, die alle diese Datentypen verarbeiten kann. Alle Daten sind überall verfügbar und erscheinen für eine Anwendung wie ein lokaler Speicher. Architekten können Regeln festlegen, wie Daten im Datenbus gemeinsam genutzt und verwaltet werden, einschließlich Anforderungen wie Latenz und Bandbreite. Die Verbindung zwischen Lesern und Schreibern (ein „Vertrag“ zwischen Publisher und Subscriber) bestimmt, was an welches Ziel und mit welcher Priorität übertragen werden soll, und wie mit Kollisionen oder Ausfällen im Netzwerk umzugehen ist.

Komplexe Systeme schneller und kostengünstiger entwickeln

Die meisten OEMs möchten nicht im Middleware-Geschäft tätig sein, insbesondere im Zeitalter der Autonomie, zumal die interne Softwareentwicklung teure interne Ressourcen erfordert. Der DDS-Datenbus ist nicht nur ein Framework für die gemeinsame Nutzung großer Datenmengen, sondern bietet auch die Möglichkeit, bestimmte Datenströme zu identifizieren, zu priorisieren und Werte zuzuweisen. Dies geschieht auf äußerst effiziente Weise und reduziert sowohl Komplexität als auch Kosten.

Ein Beispiel ist die Security, eine entscheidende Anforderung für autonome Fahrzeuge. Das autonome Fahrzeug benötigt viele Verbindungen zur Außenwelt, die alle anfällig für Störungen und Manipulationen sind. Allerdings ist es schlichtweg zu teuer, jede Software und jeden Datenfluss zu sichern. Ein DDS-Datenbus bietet die Möglichkeit, maßgeschneiderte Sicherheitsrichtlinien anzuwenden, die für jede Anwendung im Fahrzeug spezifisch sind. Security besitzt viele Dimensionen und mit dem DDS-Datenbus können Entwickler die Security-Funktionen selektiv anwenden, anstatt allgemeingültige Sicherheitsrichtlinien zu integrieren.

DDS Security ist eine standardbasierte Sicherheitsarchitektur, die sich optional anwenden lässt, ohne die Applikationsentwicklung zu beeinträchtigen. Die Sicherheit wird nach den API-Aufrufen, jedoch vor der Veröffentlichung im Netzwerk angewendet. Damit ist sie vom Anwendungscode und vom Netzwerktransportprotokoll unabhängig. Im DDS-Standard wird jedes Datenteil als Topic bezeichnet, das sich individuell anpassen lässt. Nicht jeder Datenfluss benötigt die gleich Intensität an Sicherheit. Mit einer Security auf Topic-Ebene lässt sich spezifizieren, welche Authentifizierungsstufe für jedes Datenthema erforderlich ist, zudem lassen sich die Wurzeln der Zugriffskontrolle und die erforderliche Verschlüsselung für diese Daten festlegen. Das bietet erhebliche Vorteile für die Reduzierung von Kosten und Komplexität bei gleichzeitiger Erhöhung der Sicherheit.

Skalierbar und zukunftssicher

Für autonome Fahrzeuge stellt Skalierbarkeit eine vielseitige Anforderung dar, die einiges umfasst:

• Die Flexibilität, neue Software auf den Steuergeräten, dem Domaincontroller oder in der Cloud auszuführen.
• Die Fähigkeit, verschiedene Geräte, Systeme und Netzwerke zu unterstützen. Dies erfordert es, neue Quellen einfach anzuschließen und unterschiedliche Richtlinien (zum Beispiel QoS und Security) für die neuen Daten je nach Topic anzuwenden.
• Die Möglichkeit, Daten aus mehreren sich schnell bewegenden internen und externen Quellen zu extrahieren.
• Die Möglichkeit, Standard- oder allgemeine Komponenten zu integrieren, um die Kosten für die Entwicklung und Wartung von kundenspezifischer Software und Hardware zu senken.
• Die Flexibilität, Komponenten auszutauschen und die CPU zu aktualisieren oder einen leistungsstärkeren Sensor zu installieren, ohne die Kernfunktionalität der Komponente zu ändern.

Bild 3: Unterschiedliche Anwendungsfälle haben unterschiedliche Hardware- und Software-Designs. Während das Elektrofahrzeug für die Autonomie einen völlig anderen Anwendungsfall als das Rideshare-Fahrzeug darzustellen scheint, verwendet ein optimales Design dennoch viel IP wieder. RTI

Der DDS-Datenbus skaliert sowohl horizontal als auch vertikal. Designer müssen das System nicht vorkonfigurieren, um sehen zu können, wie sich die Daten einmal gemeinsam nutzen lassen. DDS integriert diesen Aspekt der Skalierbarkeit in die Architektur selbst. Ein weiterer Aspekt ist die Notwendigkeit, die Designanforderungen zusätzlicher Automodelle mit unterschiedlichen Anforderungen an autonome Funktionen zu erfüllen. Die Entwicklung von Applikationen für Single-Use-Instanzen ist sehr teuer. OEMs müssen in der Lage sein, Anwendungen und Funktionen für Fahrzeuge der Luxusklasse zu entwerfen und dieselben an einfachere Fahrzeuge anzupassen. Darüber hinaus möchten Designer die IP bei der Entwicklung autonomer Fahrzeuge für andere Anwendungsfälle wiederverwenden können. Wie in Bild 3 kann der DDS-Datenbus die Anforderungen für ein Elektrofahrzeug der Autonomie-Stufe 2 ebenso wie für ein Mitfahr-/Rideshare-Fahrzeug der Autonomie-Stufe 4 unterstützen.

Im Idealfall gibt es Plattformen, die sich so nahtlos wie möglich von Level 2 und 3 bis Level 5 skalieren lassen, aber auch die Anforderung erfüllen, schrittweise oder sprunghaft zu einem höheren Maß an Autonomie zu gelangen. Schließlich müssen OEMs für eine zukünftige Skalierbarkeit über Teams und Anwendungen hinweg planen. Soll ein Auto zunächst in einer Stadt und dann dank weiterer Funktionen auch überall auf dem Land oder weltweit selbst fahren, bedeutet das nicht nur mehr Softwareanwendungen, sondern auch mehr Personen und Teams, die daran arbeiten. Folglich müssen Daten unabhängig vom Transport ausgetauscht werden und davon, ob die Daten von Back-End-Servern oder eingebetteten Systemen stammen.

Es ist nahezu unmöglich vorherzusagen, welche Architekturen in den nächsten fünf bis zehn Jahren dominieren werden. Das Design für eine Zukunft mit so vielen Unbekannten stellt eine enorme Herausforderung dar, die den DDS-Datenbus wertvoll macht. RTI Connext DDS spart Zeit und entlastet Ingenieurteams, die bereits unter enormem Druck stehen, und vereinfacht, wo Komplexität Probleme oder Projektfehler verursachen kann. Als vollständigstes verfügbares Framework bietet er die Flexibilität, Entscheidungen zu treffen und zu revidieren, Sackgassen zu vermeiden und neue Anforderungen zu erfüllen.

(na)