Thought Leadership
Die Umfänge an Software in modernen Fahrzeugen wachsen exponentiell. Da immer mehr Software in immer kürzeren Innovationszyklen in die Fahrzeuge kommt, versuchen Autobauer die eigenen Fähigkeiten bezüglich der Softwareentwicklung deutlich zu erweitern.
Dies geht einher mit einer Veränderung der Elektronik und Elektrik (E/E) Architektur im Fahrzeug: Bislang finden wir in Luxusfahrzeugen bis zu 100 verschiedene Steuergeräte, sogenannte „Electronic Control Units“ (ECUs), die über verschiedene Bussysteme miteinander verbunden sind und Daten austauschen. Die hohe Anzahl von Steuergeräten ist historisch bedingt: Hat man eine neue Funktion statt durch Mechanik durch Mechatronik realisiert, so hat man früher dafür ein dediziertes Steuergerät, dedizierte Sensorik und Aktuatoren eingebaut. Später erst begann man Sensordaten und Aktuatoren steuergeräte-übergreifend zu nutzen.
Hersteller ersetzen nun viele einzelne ECUs durch wenige, dafür aber sehr leistungsfähige Rechnereinheiten – die High-Performance Compute Units (HPC). Sie sind immer noch von einigen ECUs umgeben, die in der Peripherie Datenvorverarbeitung und weniger aufwendige Steueraufgaben wahrnehmen. Diese ECUs sind in Zonen angeordnet, so dass man auch von einer „zonalen Architektur“ spricht.
HPCs brauchen ein leistungsstarkes Betriebssystem, das nicht nur die klassischen Betriebssystem-Funktionen zur Verfügung stellt, sondern auch neuere, aus der IT-Welt bekannte Möglichkeiten der Virtualisierung und Containerisierung von Software bietet. So findet die Automobilbranche mehr und mehr Interesse an der Nutzung von Linux.
Linux im Fahrzeug?
Ein Erfolgsfaktor von Linux ist, dass es sich um Open Source handelt. Vorteile hiervon gegenüber proprietären Produkten sind meist geringere Kosten, weniger Fehler und höhere Qualität. Das Fehlen von Vendor Lock-in, eine größere Anzahl von Anwendern und darin ausgebildeten Programmierern sowie schnellere Innovationszyklen machen Open Source interessant.
Linux als Fahrzeugbetriebssystem ist keine Neuerung. Bereits seit geraumer Zeit wird es im Infotainment-Bereich genutzt. Beispiele sind die GENIVI Initiative, nun als Connected Vehicle Systems Alliance (COVESA) bekannt, sowie Google Android, das oft im Infotainment-Bereich Verwendung findet und auf Linux basiert. Abseits des Infotainment-Bereichs erwägt die Branche den Einsatz von Linux auch in anderen Bereichen, wie etwa dem sicherheitsrelevanten Autonomen Fahren.
Was getan werden muss
Gängige Linux-Distributionen sind kaum für den Fahrzeugeinsatz geeignet, da sie nicht den speziellen Anforderungen genügen. Funktionale und nicht-funktionale Verbesserungen sind notwendig, wie umfassende „roll-back“ Funktionalität und sicheres „logging“ von Nachrichten mit Verschlüsselung. Die Hauptbemühung liegt in der Qualifizierung des Linux-Systems gemäß den automobilen Vorschriften, besonders den Anforderungen der ISO 26262. Diese Norm reguliert die Entwicklung sicherheitsrelevanter E/E Systeme in Fahrzeugen, um das Risiko von Fehlern zu minimieren. Verschiedene Risikoklassen, durch ASIL (Automotive Safety Integrity Level) A, B, C und D definiert, repräsentieren unterschiedliche Grade an Risiko und Gefährdung.
Red Hat bekundete im April 2021 die Absicht, ein ASIL-B zertifiziertes Betriebssystem für Fahrzeuge zu entwickeln. Die Firma exida unterstützt dieses Vorhaben. Gemeinsam soll ein Verfahren implementiert werden, das eine kontinuierliche Zertifizierung sicherstellt. Damit wird nicht nur eine bestimmte Version, sondern es werden auch alle späteren Updates zertifiziert.
Dass nur der ASIL-B Level angestrebt wird, hat einen Grund: Funktionale Sicherheit erfordert architektonische Vorkehrungen im Softwareentwurf, da nachträgliche Tests allein nicht ausreichen. Ein Beispiel ist die ISO 26262-Anforderung der „freedom from interference (FFI)“, die kaskadierende Fehler zwischen Komponenten verhindern soll. Aufgrund mangelnder Sicherheitsabsicht bei der Entwicklung enthält Linux oft verschachtelte, rekursive Strukturen mit Zugriff auf gemeinsame Hardware-Ressourcen. In solchen Designs sind kaskadierende Fehler unvermeidlich und eine Rückwirkungsfreiheit ist unsicher.
Software Container im Fahrzeug
Software Container stellen ein bewährtes Mittel dar, Software zu paketieren, um diese unabhängig von der Umgebung ausführbar zu machen. Die Software im Container hat ihre eigene Konfiguration und Umgebung. Sie ist erstaunlich schlank und schneller als vollständige virtuelle Maschinen mit eigenen Betriebssystemen. Linux als Betriebssystem bietet die Möglichkeit, Software Container auszuführen. Dies kann beispielsweise mit dem Programm „podman“ erfolgen.
Ein Unternehmen muss jedoch im Laufe der Zeit viele Software-Container in verschiedenen Fahrzeugtypen und Märkten auf dem neuesten Stand halten, einschließlich Versionsupdates und der Integration neuer Container. Neben der Frage, wie eine Übertragung in das Fahrzeug technisch realisiert wird, muss auch ein Weg gefunden werden, möglichst autonom Software-Container als IT-Objekte sicher an die Fahrzeuge zu verteilen und in Betrieb zu nehmen.
Das Open-Source Projekt „Open Horizon“ bietet eine Lösung: Es ist eine Plattform zur Verwaltung von containerisierten Workloads, die seit 2020 Teil der Linux Foundation Edge („LF Edge“) ist, die alle Open-Source-Projekte im Zusammenhang mit Linux Edge-Computing hostet.
IBM hat aufbauend auf Open Horizon den IBM Edge Application Manager (IEAM) entwickelt. Dieser verfügt über eine Backend-Komponente, die zentral die Steuerung und Verbindung zu allen Fahrzeugen und den darin befindlichen IEAM Agenten übernimmt. Das „Onboarding“, ist vollständig automatisiert. Über die Backend-Komponente werden mit Agenten die Software Container auf die HPCs der Fahrzeuge verteilt, gemanagt, betrieben und überwacht. Die Verteilung und Inbetriebnahme von Containern mit bestimmten Versionen wird über „Policies“ als Regelwerk gesteuert. Falls danach die Agenten auf den HPCs die Verbindung zum Backend verlieren sollten, laufen sie autonom weiter.
Build Once, Deploy Anywhere
Ein einheitliches Linux-Betriebssystem ermöglicht die Ausführung von Software-Containern. Diese Fähigkeit erstreckt sich auf das Fahrzeug selbst, die umgebende Infrastruktur und die Backend-Systeme. Wir können Software im Backend entwickeln und testen, um sie dann im Fahrzeug einzusetzen. Zur Fahrzeug-zu-Infrastruktur Kommunikation lässt sich Software aus dem Backend in Road-Side Units oder in Mobile Edge Computing (MEC) Einheiten der Telekommunikationsausrüstung verschieben.
Dies stellt eine bislang nicht gekannte Flexibilität dar. Die Trennung der Anwendungssoftware von Hardware, Betriebssystem und Middleware durch Abstraktion führt zu hoch standardisierter und einfacher wartbarer Software, die leichter übertragen werden kann.
Erfolg durch Zusammenarbeit
IBM und Red Hat arbeiten eng mit der Industrie zusammen, um die erfolgreiche Entwicklung und Implementierung von „Software Defined Vehicles“ zu fördern. Die Entwicklung eines ASIL-B-zertifizierten Linux-Betriebssystems ist, wie beschrieben, bereits im Gange. General Motors und Red Hat sind aktiv in die Zusammenarbeit eingebunden, und auch Red Hat und ETAS planen, eine vorintegrierte und vorab getestete Basisplattform für die moderne Softwareentwicklung von fahrzeuginternen Anwendungsfällen bereitzustellen.
Die Arbeit in verschiedenen Konsortien nimmt ebenfalls Fahrt auf, wie im „Scalable Open Architecture for Embedded Edge (SOAFEE)“ Projekt. Ähnliche Ziele verfolgt die Eclipse Software Defined Vehicle Initiative. Auch frühere Projekte machen Fortschritte, zum Beispiel ELISA, ein Linux-Projekt für sicherheitskritische Systeme. Damit ist der Weg zu einer stärkeren Rolle von Linux im Automobilsektor bereitet.
