Evolutionäre Fahrzeugarchitektur und Devops

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: 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.

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.

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.

Dienste flexibel skalierbar und ausfallsicher machen

In Rechenzentren hat sich auf diesem Gebiet in den letzten Jahren die Open-Source-Software Docker etabliert. Docker ist das Ergebnis der Zusammenarbeit von IT-Größen wie Cisco, Google, Huawei, IBM, Microsoft und Red Hat, die gemeinsam das Ziel verfolgen, ein einheitliches Container-Format zu konstituieren, das plattformunabhängig einsetzbar ist. Zudem bietet Docker die Möglichkeit, mehrere Rechner in einem Rechnerverbund, auch Schwarm genannt, zu vereinen. In diesem sind Dienste flexibel skalierbar und werden beim Ausfall eines Rechners vom verbleibenden Schwarm übernommen. Zur automatisierten Bereitstellung, Skalierung und Verwaltung von Container-Diensten für einen Schwarm stehen Orchestrierungs-Tools wie beispielsweise Kubernetes zur Verfügung.

Bild 3: Bei einem idealen Devops-Prozess gehen Entwicklung (Development) und Betrieb (Operations) Hand in Hand. IAV

Im Zuge der Container-Virtualisierung erhielt der Prozessverbesserungsansatz Devops (Bild 3) einen höheren Stellenwert. Er ermöglicht es Managern, Entwicklern, Testern und Administratoren eng verzahnt zusammenzuarbeiten und stellt dem Kunden kontinuierlich die aktuellste Software zur Verfügung. Die Methoden Continuous Integration (CI) und Continuous Delivery (CD) können einen hohen Grad an Automatisierung sicherstellen. Mit dem Verschicken des aktuellen Quellcodes aktiviert der Entwickler automatisch eine vordefinierte Ereignis- und Aufgabenkette (Erstellung der Software, Test der Software, Verschicken der Software an die Fahrzeugflotte), nach der der Kunde ohne das Eingreifen einer weiteren Person eine neue Softwareversion nutzen kann. Die Fahrzeuge melden Telemetrie-Daten zurück, die in die Entwicklung der nächsten Softwareversion einfließen.

Quellcode-Management, CI und CD

Damit die beschriebene Ereigniskette automatisiert ablaufen kann, bedarf es neben Docker weiterer Software. Bild 4 zeigt eine bei der IAV erfolgreich getestete Umsetzung. Auf einer extern erreichbaren Infrastruktur (IT-Backend), welche später die Aufgabe der Neuinstallation von Software oder deren Aktualisierung in der Fahrzeugflotte übernimmt, wird Docker in der Community Edition (CE) installiert (Bild 4). Will der Entwickler Quellcode in die Ereigniskette einspeisen, braucht er eine neue Schnittstelle. Zu diesem Zweck wird die vorhandene virtuelle Umgebung durch die Docker-Container von Gitlab CE und Gitlab Runner erweitert. Gitlab ist ein webbasiertes Repository, das neben einer Versionsverwaltung, einem Code-Review und einem Issue-Management auch die CI und CD steuern kann. Die einzelnen Phasen der CI und CD lassen sich in Skripten definieren und automatisieren. Auf diese Weise kann aus dem eingestellten Quellcode ein Docker-Image (ein noch nicht ausgeführter Docker-Container) automatisiert erstellt und getestet werden. Ist der abschließende Test erfolgreich, bietet Gitlab weiterhin eine integrierte Docker-Registry, in der das neu erstellte Docker-Image für ein Release zur Verfügung steht.

Bild 4: Diese vereinfachte Architektur nutzt die IAV für eine kontinuierliche Integration von Funktionen ins Fahrzeug. Links: Fahrzeugseite. Rechts: IT-Backendseite mit Anbindung an die Entwicklung. IAV

Beim Erstellen eines Docker-Images kommt mit dessen Schichtaufbau (Bild 5) eine weitere Stärke von Docker zum Vorschein. Docker-Images haben als Ausgangspunkt (Basisschicht) typischerweise ein leeres oder ein allgemein bekanntes Image. Jede Änderung führt von hier an zu einer neuen Schicht, die die Differenz zur vorigen Schicht enthält. Die Summe aller Schichten ergibt das aktuelle Docker-Image. Im Praxisbetrieb existieren typischerweise viele solcher Images nebeneinander. Durch intelligentes Aufbauen der Docker-Images ist es möglich, Schichten wiederzuverwenden. So sind einerseits insgesamt weniger Daten zu speichern, andererseits reduziert das die Menge an zu übertragenen Daten zwischen IT-Backend und Fahrzeug. Damit nur berechtigte Docker-Images in das Fahrzeug gelangen, bietet Docker eine Signierung mittels des asymmetrischen kryptographischen Verfahrens RSA an.

Daten sicher ins Fahrzeug übertragen

Für einen automatisierten Ablauf ist neben dem IT-Backend auch das Fahrzeug aufzurüsten. Die Erweiterung umfasst zunächst einen Car-PC oder eine ARM-Plattform, auf denen ein Linux und Docker CE installiert werden. Das Fahrzeug kann über ein im Rechner integriertes LTE-Modul eine Internetverbindung mit einem externen Server (IT-Backend) aufbauen.

Bild 5: Exemplarischer Schichtenaufbau von Docker-Images. Soll Service 2 zum vorhandenen Service 1 ins Fahrzeug nachgeladen werden, muss nur die Schicht Anwendung 2 vom IT-Backend übertragen werden, da Service 2 die unteren 3 Schichten von Service 1 mitbenutzen kann. IAV

Um ein Docker-Image im Fahrzeug als Container zu starten, reicht die alleinige Kombination aus Docker und Gitlab jedoch noch nicht aus. Die mobile Breitbandverbindung stellt keine feste IP-Adresse zur Verfügung, unter welcher das Fahrzeug erreichbar ist. zudem verhindert die Firewall der Provider zusätzlich initiale Verbindungen zum Fahrzeug. Abhilfe schafft hier beispielsweise das Orchestrierungs-Tool Rancher. Zu diesem Zweck wird auf dem IT-Backend ein Rancher-Server, auf dem Fahrzeug-Rechner ein Rancher-Client installiert – beide als Docker-Container. Die Konfiguration für den Client übernimmt die Rancher-Software. Es muss lediglich ein generiertes Stück Code ausgeführt werden. Der Client verbindet sich anschließend über HTTPS mit dem Server, was eine Verwaltung von Containern auf dem Fahrzeugrechner vom IT-Backend aus ermöglicht.

Rancher unterstützt eine Vielzahl von Orchestrierungsumgebungen, wie etwa Cattle, Docker Swarm oder Kubernetes. Darüber hinaus bietet Rancher eine REST-konforme Webschnittstelle an, über die sich alle im Umlauf befindlichen Container automatisch verwalten lassen. Über diese Schnittstelle kann beispielsweise die CPU-, Speicher- und Netzwerklast pro Container beobachtet werden.

Umdenken in der Fahrzeugentwicklung

Um aktuelle Entwicklungen beim autonomen Fahren und die Integration des Fahrzeugs in das digitale Ökosystem des Besitzers zu ermöglichen, ist ein Umdenken in der Fahrzeugentwicklung notwendig. Das vorgestellte Proof of Concept verwendet etablierte Open-Source-Komponenten aus dem Cloud Computing und ist in laufende Entwicklungsprojekte der IAV eingebunden. Der Übergang zu einer zentralisierten Mehrebenen-Architektur und der Betrieb einer Fahrzeugflotte sowie eines modernen IT-Backends erlauben eine kontinuierliche Integration von Funktionen ins Fahrzeug. Dabei findet eine enge Kopplung zwischen Entwicklung und Betrieb statt (Devops).

(jwa)