Auf dem Weg zum softwaredefinierten Fahrzeug

In heutigen Luxusfahrzeugen finden sich bis zu 100 verschiedene Steuergeräte (Electronic Control Units, ECUs), die über etliche unterschiedliche Bussysteme kommunizieren, die wiederum über Gateways und Zentralrechner untereinander verbunden sind. Nun beginnen Automobilhersteller, die Vielzahl einzelner ECUs durch wenige, dafür leistungsfähigere Steuereinheiten zu ersetzen, Bild 1. Damit ergibt sich in Zukunft eine zentralisiertere E/E-Architektur, die aus wenigen sogenannten Hochleistungsrechnern (High Performance Computers, HPCs) bestehen, die von kleineren ECUs für die Peripherie umgeben sind.

Da diese kleineren ECUs verschiedenen Zonen im Fahrzeug zugeordnet sind, hat sich auch der Begriff "zonale Architektur" etabliert [1]. Die HPCs erlauben es nun, bewährte Informationstechnik aus der IT-Branche wie Virtualisierung und Software-Container auch ins Fahrzeug zu bringen. Dazu benötigen HPCs aber auch ein leistungsstarkes Betriebssystem, wie zum Beispiel Linux.

Schon seit Längerem nutzen Ingenieure das Prinzip der Virtualisierung im Pkw. Nun beginnen erste Unternehmen, Software-Container ins Fahrzeug zu bringen. Auch Linux gewinnt an Bedeutung. Das Betriebssystem Linux ist nicht nur die beste technische Basis für eine "Containerisierung" der Software - Automobilhersteller schätzen besonders die Quellenoffenheit des Codes, die ihnen Flexibilität in der Nutzung sichert und eine Anbietersperre (Vendor Lock-in) vermeidet.

Ein einheitliches Betriebssystem kann gut auf Linux basieren, es läuft im Fahrzeug und auch in der fahrzeugnahen Infrastruktur wie zum Beispiel in Ladesäulen und Ampelsystemen. Zudem ist Linux in der Cloud und den Rechenzentren der Automobilhersteller etabliert, sodass eine flexible Verteilung von Software in Containern vom Backend über das Fahrzeug bis hin zu Systemen seiner direkten Umgebung erlaubt wäre. Bild 2 zeigt diesen Ansatz einer einheitlichen Linux-basierten Plattform, die vom Fahrzeug über ein Edge-Computing-System bis in die Cloud reicht und den Slogan "Build once, deploy anywhere" in die Realität umsetzt. Dies verspricht volle Flexibilität bei höherer Standardisierung, aber auch eine bessere Wartbarkeit und Portierbarkeit von Software. Zudem erlaubt es die Abstraktion der Anwendungssoftware von der darunterliegenden Hardware.

Doch diese Vorteile ergeben sich nicht einfach so, sie müssen erarbeitet werden: Die bekannten Linux-Distributionen sind nur bedingt für den Einsatz im Fahrzeug geeignet. Sie müssen an die besonderen Anforderungen im Automobil und im Straßenverkehr angepasst werden. Beispielsweise müssen Boot-Zeiten verkürzt und die Echtzeitfähigkeiten verbessert werden.

Damit Linux auch für sicherheitskritische Anwendungen genutzt werden kann, muss es gemäß der Norm ISO 26262 [2] qualifiziert werden. Dies ist mit Linux auch nur bis zu einer mittleren Sicherheitskritikalität möglich. Der Automotive Safety Integrity Level (ASIL), ein Schema für die Risikoklassifikation, ist unterteilt in die vier Stufen A bis D und umfasst eine unterschiedliche Anzahl an Maßnahmen, die zum Erreichen einer bestimmten Stufe eingehalten werden müssen, wobei ASIL D das höchste Risiko darstellt und damit die meisten Maßnahmen fordert. Sicherheitsexperten gehen davon aus, dass mit Linux maximal ASIL B eingehalten werden kann. Der Linux-Marktführer Red Hat gab kürzlich bekannt, ein ASIL B-zertifiziertes Linux zu entwickeln [3].

Warum nur ASIL B? Auch hier gilt der bekannte Satz, dass - allgemein ausgedrückt - Qualität sich nicht nachträglich in ein Softwareprodukt hineintesten lässt. Funktionale Sicherheit kann nicht durch nachträgliche Testmaßnahmen allein sichergestellt werden. Vielmehr müssen architektonisch bereits im Softwareentwurf Vorkehrungen dafür getroffen werden. Linux wurde aber nicht mit dem Anspruch entwickelt, in sicherheitskritischen Bereichen eingesetzt zu werden.

Experten erwarten, dass die neuen Softwaretechnik dabei hilft, die hohen Aufwände für die Integration der Bordsoftware in das Fahrzeug zu verbessern: In der "alten" E/E-Architektur war eine der wichtigsten Entwicklungsaufgaben, die vielen ECUs einzubinden. Es handelte sich also um eine Integration von verschiedenen Hardwareboxen, die miteinander kommunizierten. Die Softwareintegration der ECUs war, vom Aufwand her betrachtet, vergleichsweise moderat. Die Hauptarbeit bestand darin, die unterschiedliche Hardware zu einem einheitlichen, fehlerlos funktionierenden System zu verschmelzen. Doch dieses Verhältnis ändert sich jetzt: Technik, Prozesse, Methoden und Werkzeuge, die die Softwareintegration bestmöglich unterstützen, werden der Schlüssel zum Erfolg [4].

Auch in der Domäne Prozesse, Methoden, Werkzeuge müssen Automobilhersteller und ihre -zulieferer noch einiges leisten: Agile Entwicklungsansätze haben sich weitgehend etabliert, auch Kfz-Software wird so entwickelt. Dennoch finden sich nach wie vor in Unternehmen traditionelle, V-Modell-orientierte Entwicklungsprozesse. Denn damit lassen sich die Anforderungen von Standards wie der genannten ISO 26262 [2] erfüllen. Diese beiden Welten müssen in Einklang gebracht werden.

Darüber hinaus gewinnt ein weiteres Thema eine zentrale Rolle, nämlich die Entwicklung der künstlichen Intelligenz (KI). Auch die KI-Entwicklung folgt einem eigenen Vorgehensmodell, mit eigenen Werkzeuge, Methoden und Prozessen, bei denen die Datenaufbereitung und das Datenmanagement für das maschinelle Lernen ein wesentlicher Schwerpunkt sind.

Betrachtet man die Entwicklung der KI für Fahrerassistenzsysteme und für das automatisierte Fahren, so kommen die dafür benötigten Testdaten aus drei verschiedenen Quellen:

Die Aufbereitung all dieser Daten ist aufwendig. Für den Fall, dass die Daten aus Testfahrzeugen kommen: Synchron aufgezeichnete CAN-Bus-, Kamera-, Lidar- und Radardaten, abgespeichert auf Solid-State-Drive(SSD)-Systemen, werden aus den Fahrzeugen entnommen und zu Kopierstationen gebracht, die breitbandig mit der Cloud oder direkt über WAN/LAN mit der eigenen IT verbunden sind. Dorthin werden die vielen Terabytes übertragen und dann für das sogenannte Labeling an anderen Standorten in Niedriglohnländern kopiert. Dort werden Labels in das Material eingezeichnet, die für das maschinelle Lernen benötigt werden. Experten gehen davon aus, dass für 1 h Videomaterial mehr als 200 h manuelles Labeling vonnöten sind. Dieses gelabelte Material wird dann für die KI-Entwicklung, für die Verifikation und die Validierung genutzt. Vielfach passiert all dies in der Cloud. Spätestens wenn die Hardware des Fahrzeugs ins Spiel kommt, verlagern sich Entwicklungs- und Testaktivitäten zurück ins F+E-Labor, wie zum Beispiel für das Hardware-in-the-Loop(HiL)-Testing. HiL-Prüfstände sind komplex und an spezielle Hardware angepasst. Um solche HiL-Stationen ausreichend schnell mit Daten zu versorgen, hält man die notwendigen Daten dafür lokal bereit.

Hier ist nun vor allem die Engineering-IT gefordert, mittels hybriden und KI-basierten Lösungen für das Datenmanagement für eine hohe Produktivität der Entwicklungsteams zu sorgen: "hybrid", um dynamisch eine Skalierung von Rechenleistung und Datenspeicherung vom lokalen Rechenzentrum bis zu privaten und öffentlichen-Cloudlösungen zu ermöglichen und den Ingenieuren einen einfachen Zugriff auf ihre Daten zu erlauben - unabhängig davon, wo diese Daten liegen. "KI-basiert", um das Labeling weitgehend zu automatisieren und um die unstrukturierten Daten effizient zu klassifizieren.

Ein Software Defined Vehicle ist hochgradig vernetzt und kommuniziert ständig mit anderen Fahrzeugen, der umgebenden Infrastruktur und der Cloud beziehungsweise den Backend-Systemen der OEMs. Der Ausbau der 5G-Technik gestattet es nun, immer mehr Daten auszutauschen. Dafür muss nicht nur der Empfang im 5G- Funknetz möglich sein, auch in der Fahrzeug-zu-Backend-Kommunikation sollte das Backendsystem entsprechend performant ausgelegt sein.

Das Backend muss nicht nur mit Tausenden von Fahrzeugen parallel kommunizieren, es muss auch schnell reagieren. Eine geringe Latenzzeit ist bei Anwendungen im Bereich des autonomen Fahrens unumgänglich. Pkw-Hersteller bauen solche Backendsysteme in verschiedenen geografischen Regionen auf, um zum einen lokal unterschiedliche regulatorische Anforderungen zu erfüllen, aber auch um eine gute Abdeckung und geringe Latenzen zu ermöglichen.

Die zunehmende Konnektivität erlaubt heute im größeren Maß neue Softwareversionen drahtlos, also over the Air, ins Fahrzeug zu laden. So können Automobilhersteller ihre Fahrzeuge auch nach dem Verkauf aktuell halten. Die technischen Voraussetzungen für Softwareupdates im Fahrzeug zu schaffen, ist aber auch aufgrund neuer regulatorischer Vorgaben notwendig: OEMs müssen in der Lage sein, Sicherheitslücken mit Softwareupdates zu schließen. Dies basiert auf der UNECE-Regelung R156 [6], die die Anforderungen für die Fahrzeugtypprüfung zusammenstellt. Die technischen Anforderungen für die Erfüllung der R156 definiert der Standard ISO 24089 [7], der sich noch im Entwurfsstatus befindet.

Das Software Defined Vehicle muss gegen Hackerangriffe abgesichert werden. Dass Attacken von außen auf die Fahrzeugelektronik denkbar sind, ist schon seit weit mehr als zehn Jahren bekannt. Die Zahl der technischen Möglichkeiten dafür, der Angriffspunkte und der Angriffsarten hat sich aber in den letzten Jahren erhöht. Daher rüsten auch die Pkw-Hersteller auf, um ihre Fahrzeuge zu schützen, was aber ein vielschichtiges und komplexes Unterfangen ist. Es beginnt mit Schutzmaßnahmen in der Fahrzeugelektronik und reicht bis zur kompletten Echtzeitüberwachung der Fahrzeugnutzung durch sogenannte Vehicle Security Operation Centers (V-SOCs). Die Sicherheitsexperten in den V-SOCs können dann eingreifen, wenn sie einen Angriff erkennen. Sie leiten entsprechende Gegenmaßnahmen ein.

Eine der Hauptforderungen der für jeden Automobilhersteller geltenden UNECE-Regelung R155 [8] ist der Aufbau und der Betrieb eines Cyber Security Management System. Betrachtet werden muss dazu nicht nur die Entwicklung, sondern auch die Fertigung und der Betrieb eines Fahrzeugs bis hin zu seiner Verschrottung. Die technischen Anforderungen für die Erfüllung der R155 sind in der ISO 21434 [9] definiert, die im August 2021 veröffentlicht wurde.

Dies sollte ein Einblick in die Welt des Software Defined Vehicle sein. Die Entwicklung und der Betrieb dieser Automobile ist eine große Aufgabe, für die viele verschiedene Herausforderungen gelöst werden müssen. Dies kann kein Automobilhersteller und keiner seiner Zulieferer allein leisten. Es braucht eine Vielzahl an hochspezialisierten Unternehmen, die in geeigneter Form zusammenarbeiten, um die Aufgabenstellungen zu meistern. Bei IBM wird dafür mit der gesamten Industrie sowie mit namhaften Technologieunternehmen eng zusammengearbeitet.

Als Vorzeigeprojekt sei hier die Zusammenarbeit zwischen IBM und Continental erwähnt, bei dem nach einer modernen Lösung für die Entwicklung von autonomen Fahrzeugen in einer Co-Location gesucht wurde [10]. Hierbei sollte die Leistungsfähigkeit von Nvidia-DGX-Systemen für das KI-Training erhöht werden, indem mehr Daten schneller den Systemen zur Verfügung gestellt und dann von der KI verarbeitet werden. Gemeinsam mit mehreren Partnern zur Implementierung und zum Hosting schaffte es Continental über den Cluster-Dateispeicher Spectrum Scale von IBM, die Systeme so aufzubauen, dass nun 14-mal mehr KI-Experimente in der gleichen Zeit möglich sind. Dies zeigt, wie wichtig eine übergreifende Zusammenarbeit für die Effizienz in diesem Bereich ist.