Ein vollständig autonom fahrendes Fahrzeug verlässt die Garage, holt seinen Besitzer vor der Haustür ab und meistert auf dem Weg zum Ziel auch die schwierigsten Verkehrssituationen mit Leichtigkeit. Der Besitzer selbst entspannt während der Fahrt beim aktuellen Angebot von Audio- und Video-on-Demand-Diensten oder geht bereits seiner Arbeit nach. Sein Smartphone koppelt sich nach einem Sicherheitsupdate des Fahrzeugs automatisch. Damit dieser Blick in die Zukunft Wirklichkeit wird, ist ein tiefgreifender Umbruch in der Automobilentwicklung notwendig, und außerdem kommt Devops ins Spiel.

Bild 1: Mehrebene Architektur IAV mit Devops

Bild 1: Die zentralisierte Mehrebenen-Architektur verbindet über verschiedene Bussysteme die freie und die domänenspezifische Rechenebene (Betrieb von Diensten) sowie die Steuergeräteebene (Sensoren, Aktoren) miteinander. IAV

Mehrebenen-Architektur

Der Weg zum autonomen Fahren bringt immer komplexere und rechenintensivere Fahrzeugfunktionen mit sich. Dieser Trend macht seitens der E/E-Architektur einen Übergang zu einer zentralisierten Mehrebenen-Architektur unverzichtbar (Bild 1). Die untere Architekturebene ermöglicht die Entwicklung von vielfältig einsetzbaren Sensoren und Aktoren mit technisch robusten und echtzeitfähigen Regler- und Steuerfunktionen.

Die mittlere Ebene erlaubt die massive Parallelisierung von Diensten (Microservices), die zunächst voneinander unabhängig entwickelt und betrieben werden können, aber auch eine Kommunikation untereinander zulassen. Im Feld lassen sich vorhandene Dienste über eine Internetverbindung ständig aktualisieren oder neue Dienste nachladen. Die obere Ebene stellt die dafür notwendigen Rechen-, Speicher- und Netzwerkressourcen zur Verfügung. Die Trennung von den anderen Ebenen macht sie problemlos erweiterbar und skalierbar. Zudem reduziert ein redundanter Betrieb einzelner Dienste und Module die Ausfallwahrscheinlichkeit des Gesamtsystems deutlich.

Agile Entwicklung und Organisation

In der Fahrzeugwelt ist neben der Weiterentwicklung der E/E-Architektur auch ein Wandel in der Software- und Systementwicklung notwendig. Treibende Kraft ist der Wunsch nach einer nahtlosen Integration des Fahrzeugs in das bestehende digitale Ökosystem (Smartphone, Smart Home, Sprachassistenten). Um mit der Entwicklungsgeschwindigkeit des Internet of Things Schritt zu halten und entsprechende digitale Geschäftsmodelle zu ermöglichen, ist eine agile Entwicklung und Organisation unerlässlich. Ein weiterer Aspekt ist die Sicherheit, denn das Fahrzeug soll zu jedem Zeitpunkt möglichst maximalen Schutz vor unerlaubten Zugriffen bieten. Zudem müssen die persönlichen Daten der Insassen anonym bleiben. Die dafür notwendigen Sicherheitsprotokolle und Verschlüsselungsalgorithmen könnten Sicherheitslücken aufweisen und müssen daher im laufenden Fahrzeugbetrieb jederzeit anpassbar bleiben.

Eckdaten

Für die kontinuierliche Integration und Aktualisierung von Fahrzeugfunktionen bedarf es einer neuen mehrschichtigen Netzwerkarchitektur im Fahrzeug sowie einer sicheren Kommunikation zum IT-Backend. Hierfür eignet sich die ressourcensparende Container-Virtualisierung, ergänzt um ein Konfigurationsmanagement, die Qualitätssicherung der automatisierten Auslieferung von Software sowie die Durchführung von Software-Rollbacks. Der Devops-Ansatz definiert dabei  Methoden zur kontinuierlichen Datensammlung und -analyse, die dann wieder direkten Einfluss auf die Entwicklung nehmen.

Eine große Rolle spielen evolutionäre Funktionen für das automatisierte und autonome Fahren, welche mitunter eine unüberschaubare Komplexität aufweisen. Diese resultiert aus der Verarbeitung großer Datenmengen (Kamera, Radar), dem Einfluss zahlreicher Kommunikationspartner (IT-Backend, andere Autos, Ampeln, Sensoren in der Straße) und dem Einsatz mehrdimensionaler, nichtlinearer neuronaler Netze. Eine neue Herangehensweise spiegelt die gewonnenen Erkenntnisse aus dem ständig wachsenden Feld in die Entwicklung zurück und gibt optimierte Funktionen als Update an die Fahrzeuge aus.

Devops

Das gewährleistet ein hohes Maß an Funktionalität und Sicherheit, verdeutlicht aber auch, dass zukünftig das Zusammenspiel von Entwicklung und Betrieb der Fahrzeuge (Devops = Development + Operations) immer wichtiger wird. Doch wie sieht eine mögliche praktische Umsetzung aus? Das nachfolgende Architekturkonzept versteht eine Fahrzeugflotte und das zugehörige IT-Backend als virtuelles Rechenzentrum und nutzt etablierte Werkzeuge aus dem Cloud-Computing. Dieses Proof-of-Concept findet seinen Einsatz aktuell in Entwicklungsprojekten der IAV.

Unterschied VM-Docker IAV

Bild 2: Virtualisierungstechniken: (a) Container-Virtualisierung, (b) Typ-1-Hypervisor und (c) Typ-2-Hypervisor. IAV

Container-Virtualisierung spart Ressourcen

Um eine kontinuierliche Aktualisierung hunderter Dienste für eine Flotte mehrerer Millionen Fahrzeuge bereitstellen zu können, muss die zwischen IT-Backend und Fahrzeug ausgetauschte Datenmenge so gering wie möglich bleiben. Aufbauend auf der zentralisierten Mehrebenen-E/E-Architektur bietet es sich an, auf die ressourcensparende Virtualisierungstechnik der Container zu setzen (Bild 2a).

Das Grundprinzip ist recht einfach. Ein Container ist in der Lage, isoliert einen Dienst auszuführen. Neben der Software des Dienstes enthält der Container nur die absolut notwendigen Abhängigkeiten. Er läuft zusammen mit anderen Containern auf einem Host. Alle teilen sich einen Kernel. Gegenüber Virtualisierungstechniken mit Typ-1- und Typ-2-Hypervisoren (Bilder 2b, 2c), bei denen ein kompletter Rechner mit BIOS, Hardware und vollumfänglichem Betriebssystem simuliert wird, ist die Container-Virtualisierung ressourcensparend. Diese gekapselten Container lassen sich als Microservices einfach übertragen, installieren und starten. Zudem wird die Hardware pro Container oft nicht intensiv beansprucht, wodurch sich eine Vielzahl von Containern gleichzeitig auf einem Host betreiben lassen. Durch die Abgrenzung von Namespaces hat ein Container dabei keinen Zugriff auf die Prozesse und den Speicher anderer Container. Zudem ist der Ressourcenbedarf eines Containers beschränkbar.

Seite 1 von 212