Ein autonomes Fahrzeug zu entwickeln, ist mit hohen Risiken und Unsicherheiten verbunden. Die meisten traditionellen Autounternehmen verlagern ihren Fokus derzeit von der Hardware auf die Software und versuchen, eigene Lösungen zu entwickeln. Jedoch ist die Software in einem autonomen System ein komplexes Problem, das mit jeder Autonomiestufe wächst.
Das Auto hat sich mittlerweile zu einem Netzwerk miteinander verbundener Computer entwickelt. Jeder von ihnen verarbeitet Daten, trifft Entscheidungen und kämpft um Ressourcen. Zusammen mit Bild- und Lidar-Verarbeitung, Sensorfusion, Fahrsteuerung und Teleoperationen steigt die Anzahl der Interaktionen und damit die Komplexität des Systems. Die Technologien, die zur Lösung dieses wachsenden Problems erforderlich sind, müssen in der Lage sein, Daten in Echtzeit zu teilen und große Datenmengen mit unterschiedlichen Prioritäten, Quellen und Zielen zu verarbeiten.
Gleichzeitig bedarf es einer robusten Lösung, die niemals versagt und dadurch einen Unfall verursachen könnte. Dies betrifft einen weiteren wichtigen Aspekt von neuer Software – die Softwareentwicklung für eine sicherheitskritische Umgebung. Sie birgt eine Reihe von Herausforderungen, die nicht alle Softwarelösungen erfüllen können.
Konnektivität – vier Möglichkeiten
Um die genannten Risiken zu minimieren, muss sichergestellt werden, dass autonome Fahrzeugentwickler rasch Neuerungen einbringen und sich an wechselnde Marktbedingungen und technologische Fortschritte anpassen. Deshalb müssen Unternehmen darauf achten, die richtige Herangehensweise an die Softwareplattform zu wählen. Es gibt vier verschiedene Ansätze zur Auswahl einer solchen Technologie:
1. Cloud- und Unternehmenstechnologien nutzen, die für große Systeme entwickelt wurden und zu Lösungen wie Teleoperationen passen. Solche Lösungen sind jedoch nicht für autonome Systeme optimiert, die eine Echtzeitreaktion benötigen. Werden beispielsweise beim autonomen Fahren Hindernisse mithilfe von Lidar erkannt, muss die Latenz zwischen Lidar und der Applikation zur Hinderniserkennung minimiert werden. Kommt hier eine cloudbasierte Lösung zum Einsatz, erhöht das die Latenz für die Kommunikation, die möglicherweise auf demselben Steuergerät ausgeführt wird, unnötig. Ganz zu schweigen von der Menge der Daten, die über eine nach Datenvolumen berechnete Verbindung hin und her gesendet werden. Zudem verfügen die meisten von ihnen über eine Server- oder Broker-orientierte Architektur, die einen Single Point of Failure erzeugt und die Robustheit des Systems erheblich gefährden kann.
2. Eine Lösung von Grund auf neu erstellen. Autohersteller denken oftmals, ihre Anforderungen an den Datenaustausch wären so speziell, dass vorhandene Lösungen nicht passen. Sie benötigen mehrere spezifische Datenflüsse, darunter kleine Daten mit hoher Priorität wie zum Beispiel Bremsinformationen oder Alarme, große Streaming-Daten, die an mehreren Orten benötigt werden, Befehle und Antworten sowie Daten, die nur unter bestimmten Bedingungen benötigt werden und vieles mehr. Aber stimmt es, dass diese Szenarien so einzigartig sind, dass sie eine Ad-hoc-Implementierung benötigen? Solche Szenarien sind nicht nur in Automotive-Anwendungsfällen, sondern auch in vielen anderen autonomen Systemen wie Flugzeugen, Zügen, Luft- und Raumfahrt und Militärfahrzeugen geläufig. Um eine eigene Konnektivitätslösung zu erstellen und ein Problem zu lösen, das andere bereits gelöst haben, bedarf es meist vieler Ressourcen. In den meisten Fällen geht es beim Wertversprechen der Automobilunternehmen nicht darum, wie Software integriert oder eine Echtzeit-Netzwerkleistung erzielt werden kann. Vielmehr geht es um übergeordnete Algorithmen und Funktionen, und diese benötigen lediglich eine zugrunde liegende Infrastruktur, welche die erforderlichen Daten rechtzeitig bereitstellt.
3. Eine der neuen Automobilplattformen wie Autosar Adaptive, ROS2, Apollo und so weiter auswählen und ein System um diese herum aufbauen. Obwohl einige davon neu oder marktspezifisch sind, sind die Technologien bereits Teil des automobilen Ökosystems und können nützliche Ressourcen bieten, die bereits Tausende Menschen nutzen. In ROS beispielsweise finden sich praktische grafische Anwendungen zur Visualisierung von Video, Radar und Lidar. Hier taucht jedoch das Problem auf, welche am besten passt, denn es gibt viele Aspekte zu berücksichtigen: Integrationsvorteile (was nutzen meine Anbieter am häufigsten), beste Leistung und Robustheit, Weg zur Zertifizierung, Sicherheit und viele mehr. Und was passiert nach der Auswahl, wenn sich die Technologieanforderungen oder die eigenen Anforderungen ändern? Entscheidend ist, dass die gewählte Lösung allen künftigen Anwendungsfällen in einer Branche standhält, die sich ständig weiterentwickelt.
4. Eine grundlegende Technologie verwenden, die auf Standards basiert und sich in kritischen Systemen bewährt hat. Einige der genannten Automobil-Plattformen verwenden den Data Distribution Service (DDS) Standard. DDS ist seit Jahrzehnten in unternehmenskritischen Projekten in verschiedenen Märkten im Einsatz, von der Luft- und Raumfahrt bis hin zum Gesundheitswesen. Die Standard-Konnektivitätslösung liefert Echtzeit-Performance, präzise Datenkontrolle einschließlich Echtzeit-Filterung auf Publisher-Seite, Quality of Service (QoS), wie Zuverlässigkeit, Langlebigkeit, Termintreue und Verfügbarkeit, zudem Sicherheit, Vielseitigkeit und Interoperabilität zwischen Anbietern, die ein gemeinsames Real-Time Publish Subscribe Protocol (RTPS) verwenden.
Da DDS entwickelt wurde, um verschiedene Technologien einfach zu integrieren, gäbe es eine weitere Option: einen oder mehrere der oben genannten Ansätze zu integrieren und jeden davon genau dann zu verwenden, wann er am sinnvollsten erscheint, während alle zusammenarbeiten, um die kritischen Anforderungen eines Systems zu erfüllen.
Vorteile der geschichteten Datenbus-Architektur
Ein autonomes Fahrzeug ist kein isoliertes System, sondern ein System von Systemen, das verschiedene Hardware- und Softwarelösungen, Anwendungslogik, Märkte, Anbieter, Geschäftsmodelle und mehr miteinander kombiniert. Dafür benötigt es eine einzigartige Architektur, die Echtzeit-Performance am Edge ermöglicht und gleichzeitig verschiedene Betriebsdomänen integriert sowie Interoperabilität zwischen Komponenten erlaubt, die verschiedene Unternehmen oder sogar Wettbewerber gebaut haben.
Es bedarf einer sicheren Lösung, die nicht nur vor Angriffen, sondern auch die Anwendungslogik schützt. Zudem muss die Architektur mit einer großen Anzahl an Teilnehmern im System zurechtkommen. Sie muss also skalierbar und zumindest teilweise zertifizierbar sein, da viele Subsysteme Zertifizierungen wie ISO 26262 erfordern.
Eine geschichtete Datenbus-Architektur erfüllt alle diese Anforderungen und mehr. Dazu gilt es zunächst, verschiedene isolierte Betriebsdomänen zu schaffen. Jede dieser Domänen enthält einen DDS-Datenbus, der den Datenaustausch innerhalb dieser Domäne ermöglicht. Die Daten lassen sich so konfigurieren, dass nur die Komponenten, die auch Daten benötigen, diese empfangen und für die Verwendung von Multicast- oder Publisher-seitiger Filterung optimiert werden.
Das verringert die Verschwendung von Ressourcen durch unnötige Datenübertragung. Diese domäneninterne Kommunikation ist dank der über 20 verfügbaren QoS-Eigenschaften in hohem Maß konfigurierbar und ermöglicht verschiedene Anwendungen, wie große Datenmengen mit hohem Durchsatz, Daten mit geringer Latenz, zuverlässige oder bestmögliche Leistung, Fehlertoleranz und mehr.
Da DDS ein Standard ist, bietet er eine einfache Möglichkeit, Standard-Datenmodelle zu definieren, die von verschiedenen Wettbewerbern genutzt werden. Gleichzeitig lassen sich diese Datenmodelle mithilfe von Extensible Types erweitern, um bestimmte Details hinzuzufügen, die das Fahrzeug einzigartig machen. Und da DDS bereits von Automobil-Standards verwendet wird, können Fahrzeughersteller mit minimalen Änderungen alles von Autosar oder ROS nutzen, was sie benötigen.
Zudem werden Daten, die zwischen verschiedenen Domänen benötigt werden, automatisch und basierend auf ihrem Inhalt mithilfe eines Software-Gateways (DDS-basiertes Tool) weitergeleitet. In diesem Gateway lassen sich Transformationen und Anpassungen durchführen, damit die in einer Domäne enthaltenen Daten in anderen Schichten (Layers) verstanden werden können. Erfolgt die Datenübertragung beispielsweise außerhalb des Fahrzeugs, ist es möglich, eine eindeutige Kennung (zum Beispiel ein Autokennzeichen) hinzufügen oder die Geschwindigkeit in ein anderes metrisches System umzuwandeln. Das ermöglicht die Integration und Interoperabilität über operative Domänen hinweg.
Security-Optionen beachten
Die Authentifizierung, Zugriffssteuerung, Verschlüsselung und Kennzeichnung von Daten sowie die Protokollierung aller erfolglosen Interaktionen ermöglicht die im DDS-Standard festgelegte fein abgestimmte Security. Dies alles ist unabhängig von den Security-Optionen des Transports.
Entwicklern erlaubt das, unterschiedliche Sicherheitskonfigurationen für jede Betriebsdomäne anzuwenden. Einerseits können sie bei der Hochleistungskommunikation im Auto keine Ressourcen und Zeit verschwenden, um alle Daten zu verschlüsseln, sondern sollten die Diagnoseports kontrollieren. Beispielsweise wird beim Verbinden mit einer bekannten Anwendung (Authentifizierung) sichergestellt, dass diese nur zuvor festgelegte Informationen liest (Zugriffskontrolle), jedoch niemals unerwünschte Daten einspeisen kann.
Andererseits ist es beim Austausch einiger Daten über das Internet mit der Teleoperationseinheit wichtig, einen sicheren Transport zu verwenden und alles zu verschlüsseln. Diese Architektur schützt das System auf effiziente Weise vor Angriffen und verhindert, dass andere Anbieter oder externe Anwendungen nicht erlaubte Daten empfangen oder senden.
Schließlich isoliert die Architektur die Teile des Systems, die eine höhere Zertifizierungsstufe benötigen. Beispielsweise gibt es häufig Hybridsysteme, bei denen einige Teile wie die Fahrzeugsteuerung bis hin zu ASIL-D verwenden, während andere überhaupt nicht zertifiziert sind, wie die Teleoperationen. Hier ermöglicht die Architektur eine Verwendung der gleichen Konnektivitätslösung und des gleichen Entwurfsmusters für alle, ebenso wie die Bereitstellung unterschiedlicher Implementierungen in Abhängigkeit der Sicherheitsanforderungen. Gleichzeitig lassen sich Daten dank durchgängiger QoS-Einstellungen wie Frist, Aktualität und Zuverlässigkeit sicher über verschiedene Zertifizierungsstufen hinweg austauschen.
Das Auto der Zukunft
Weltweit führende Automobilunternehmen wählen diesen standardbasierten Weg, weil sie sich nicht nur an einen Ansatz binden wollen. Es ist wichtig, eine zukunftssichere Architektur zu wählen, die verschiedene Technologien und Standards integriert, eine sichere und zertifizierbare Lösung bietet, sich auf Hunderttausende von Datenpunkten skalieren lässt, in Echtzeit arbeitet und sich weiterentwickeln kann, um künftige, noch unbekannte Anforderungen zu erfüllen. So sieht das Auto der Zukunft aus.
