Was ist ein Software Defined Vehicle?

Der Begriff "Software Defined Vehicle" beschreibt den Trend, immer mehr Fahrzeugfunktionen durch Software zu realisieren. Mit diesem Schlagwort verbindet die Automobilbranche aber auch eine Reihe von Merkmalen, die bestimmend für die nächsten Fahrzeuggenerationen des "Software Defined Vehicle" sein werden. Eines der hervorstechendsten Merkmale des "Software Defined Vehicle" ist die geänderte E/E-(Elektrik/Elektronik-)Architektur.

Neue E/E-Architekturen halten im Software Defined Vehicle Einzug

In den heutigen Luxusfahrzeugen finden sich bis zu 100 verschiedene ECUs (Electronic Control Units), die in etlichen unterschiedlichen Bussystemen angeordnet sind. Diese sind wiederum über Gateways und Zentralrechner untereinander verbunden. Nun beginnen Hersteller damit, die Vielzahl einzelner ECUs durch wenige, aber dafür leistungsfähigere Units zu ersetzen. Damit ergibt sich in Zukunft eine zentralisiertere Architektur, die aus sogenannten High-Performance Compute Units (HPCs) besteht, die von kleineren ECUs für die Peripherie umgeben sind. Diese HPCs erlauben es nun, bewährte IT-Technologien auf Linux-Basis wie Virtualisierung und Software-Container, ins Fahrzeug zu bringen.

Linux und Container im Auto

Schon seit längerem nutzen Ingenieure das Prinzip der Virtualisierung im Auto. Nun beginnen erste Unternehmen, Software-Container ins Fahrzeug zu bringen. Auch Linux als Betriebssystem im Fahrzeug wird immer mehr eingesetzt, da Linux unter anderem die beste technologische Basis für eine "Containerisierung" der Software ist. Ganz zu schweigen von der Quelloffenheit des Codes und der sicheren Systemarchitektur, die der Automobilindustrie eine Anpassung an die eigenen Bedürfnisse ermöglicht.

Ein einheitliches Betriebssystem auf Basis von Linux, das im Fahrzeug und auch in der fahrzeugnahen Infrastruktur wie etwa in Ladesäulen und Ampelsystemen läuft, und das in der Cloud und den Rechenzentren der Automobilhersteller etabliert ist, würde die flexible Verteilung von Software in Containern vom Backend bis zum Fahrzeug und seine direkte Umgebung erlauben.

Flexibilität durch Standardisierung

Dies verspricht eine hohe Flexibilität bei höherer Standardisierung, aber auch eine bessere Wartbarkeit und Portierbarkeit von Software. Zudem erlaubt es die Abstraktion der Anwendungssoftware von darunterliegender Hardware, Betriebssystem und Middleware-Schichten.

Doch diese Vorteile ergeben sich nicht eben so, sondern müssen erarbeitet werden: Die bekannten Linux-Distributionen sind nicht für den Einsatz im Fahrzeug geeignet. Sie müssen auf die besonderen Anforderungen im Auto und im Straßenverkehr angepasst werden.

Linux und Safety im Auto

Damit Linux auch für sicherheitskritische Anwendungen genutzt werden kann, muss es gemäß dem Standard ISO 26262 qualifiziert werden. Dies ist schwierig und mit Linux auch nur bis zu einer mittleren Kritikalität möglich. Das sogenannte "Automotive Safety Integrity Model" (ASIL), mit dem die Sicherheit im Automotive-Bereich eingestuft wird, ist unterteilt in vier Stufen (ASIL-A, -B, -C und -D) und umfasst immer eine unterschiedliche Anzahl an Maßnahmen, die zum Erreichen eines bestimmten Levels eingehalten werden müssen. Dabei stellt ASIL-D die sicherste Ebene dar. Sicherheitsexperten gehen davon aus, dass mit Linux maximal ASIL-B eingehalten werden kann. Linux-Marktführer Red Hat hat kürzlich bekannt gegeben, sich der Erreichung eines ASIL-B Levels für sein Vehicle OS zu widmen.

Software- statt Hardware-Integration

Experten erwarten, dass diese neuen Technologien im Fahrzeug dabei helfen, den hohen Aufwand für die Integration der On-Board-Software zu reduzieren: In der "alten" E/E-Architektur war es eine der wichtigsten Aufgaben, die vielen ECUs zu integrieren. 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 nun: Technologien, Prozesse, Methoden und Tools, die die Software-Integration bestmöglich unterstützen, werden der Schlüssel zum Erfolg.

Prozesse, Methoden, Tools

Auch in der Domäne "Prozesse, Methoden, Tools" müssen Unternehmen - Hersteller und 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 erfüllen. Diese beiden Welten müssen in Einklang gebracht werden.

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

Big Data treibt das Fahrzeug an

Bei der Entwicklung der KI für Fahrerassistenzsysteme und für das Autonome Fahren kommen die dafür benötigten Daten aus drei verschiedenen Quellen:

• Daten aus dem normalen Betrieb bereits verkaufter Fahrzeuge werden vom OEM gesammelt, anonymisiert und für die Verbesserung bereits entwickelter Systeme genutzt;

• Daten aus Simulationsumgebungen werden aufbereitet und meist für den Test der KI-Systeme verwendet;

• Speziell ausgestattete Testfahrzeuge sind weltweit im Einsatz und sammeln Daten. Ein solches Fahrzeug kann pro Tag bis zu 70 Terabyte aufzeichnen, die dann sortiert und aufbereitet werden.

Hier ist 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. Nur so können mit den vorhandenen, knappen Entwicklungsressourcen die Menge an Software entwickelt und die Datenmengen bewältigt werden, die das "Software Defined Vehicle" benötigt.

Vernetzt und kommunikativ

Ein "Software Defined Vehicle" ist hochgradig vernetzt und kommuniziert ständig mit anderen Fahrzeugen, mit der umgebenden Infrastruktur und mit der Cloud, beziehungsweise mit den Backend-Systemen der Hersteller. Der Ausbau von 5G ermöglicht es nun, immer mehr Daten auszutauschen. Dafür muss nicht nur das 5G-Netz vorhanden sein, auch in der Fahrzeug-zu-Backend-Kommunikation sollte das Backend-System 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. Hersteller bauen solche Backend-Systeme in verschiedenen geographischen Regionen auf, um zum einen lokal unterschiedliche regulatorische Anforderungen zu erfüllen, aber auch um eine gute Abdeckung und geringe Latenzen zu ermöglichen.

Over-the-air-Updates

Die zunehmende Konnektivität erlaubt nun auch im größeren Maß neue Softwareversionen "over the air" ins Fahrzeug zu laden und zu installieren. So können Hersteller ihre Fahrzeuge über den Lebenszyklus hinweg aktualisieren.

Die technischen Voraussetzungen für Software-Updates im Fahrzeug zu schaffen, ist aber auch aufgrund neuer regulatorischer Vorgaben notwendig: Hersteller müssen in der Lage sein, Sicherheitslücken mit Software-Updates zu schließen. Dies sieht die UNECE-Regelung R156 "Software Update and Software Update Management System" vor. Dies führt zu einem weiteren wichtigen Aspekt des "Software Defined Vehicle", der Absicherung gegen Cyber-Attacken.

Abwehr von Cyber-Attacken

Das "Software Defined Vehicle" muss gegen Hackerangriffe abgesichert werden. Dass Attacken von außen auf die Fahrzeugelektronik möglich sind, ist schon seit weit mehr als zehn Jahren bekannt. Die technischen Möglichkeiten dafür, die Angriffspunkte und Angriffsarten, haben sich aber in den letzten Jahren erhöht.

Daher rüsten auch die Hersteller auf, um ihre Fahrzeuge zu schützen, was aber ein vielschichtiges und komplexes Unterfangen ist. Es beginnt mit Schutzmaßnahmen in der Fahrzeugelektronik bis hin zur kompletten Echtzeitüberwachung der Fahrzeugnutzung durch sogenannte "Vehicle Security Operation Center" (V-SOC). Die Sicherheitsexperten in den V-SOCs können dann eingreifen, wenn sie einen Angriff erkennen und Gegenmaßnahmen einleiten.

Eine der Hauptforderungen der für jeden Hersteller geltenden UNECE-Regelung R155 ist der Aufbau und der Betrieb eines "Cyber Security Management Systems", ähnlich den Qualitätsmanagement-Systemen nach ISO 9000. Dazu muss nicht nur die Entwicklung, sondern auch die Fertigung und der Betrieb des Fahrzeugs bis hin zur Verschrottung betrachtet werden.

Sicherheit durch Kooperation

Letztlich sind die Entwicklung und der Betrieb von "Software Defined Vehicles" eine große Aufgabe, Bei der viele verschiedene Herausforderungen zu lösen sind. Dies kann kein Hersteller und kein Zulieferer allein leisten. Es braucht eine Vielzahl an hochspezialisierten Unternehmen, die in geeigneter Form zusammenarbeiten, um die Aufgabenstellungen zu meistern.

Ein Beispiel dafür ist unsere Zusammenarbeit mit Continental, bei der nach einer modernen Lösung für die ADAS/AD-Entwicklung in einer Co-Location gesucht wurde. Hierbei sollte die Leistungsfähigkeit von NVIDIA-DGX-Systemen für das KI-Training erhöht werden, indem mehr Daten schneller den Systemen zu Verfügung gestellt und dann von der KI verarbeitet werden können. In Zusammenarbeit mit mehreren Partnern zur Implementierung und zum Hosting schaffte es Continental, über IBM Spectrum Scale das gesamte System 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.