Skip to main content
Top
Published in: ATZelektronik 7-8/2022

Free Access 01-07-2022 | Entwicklung

Auf dem Weg zum softwaredefinierten Fahrzeug

Author: Hans Windpassinger

Published in: ATZelektronik | Issue 7-8/2022

Activate our intelligent search to find suitable subject content or patents.

search-config
loading …
Zunehmend werden in der Automobilentwicklung Fahrzeugfunktionen nicht mehr in der Hardware, sondern per Software abgebildet. IBM stellt die Herausforderungen des softwaredefinierten Pkw vor und zeigt, wie Hundert Steuergeräte durch zonale E/E-Architekturen, das Betriebssystem Linux und eine Handvoll Hochleistungsrechner ersetzt werden können.
Der Begriff "Software Defined Vehicle" ist heute vielfach in der Automobilindustrie zu hören. Mit diesem softwaredefinierten Pkw beschreibt man den Trend, dass immer mehr Fahrzeugfunktionen durch Software realisiert werden. Die Automobilbranche verbindet damit aber auch eine Reihe von Merkmalen, die bestimmend für die nächsten Pkw-Generationen sein werden. IBM will diese Merkmale hier genauer vorstellen und auf die damit verbundenen Herausforderungen in der Entwicklung und im Betrieb eingehen. Eines der hervorstechendsten Merkmale des Software Defined Vehicle ist die geänderte Elektrik/Elektronik- oder E/E-Architektur.

Neue E/E-Architekturen

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.

Linux und Container im Automobil

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.

Software- statt Hardwareintegration

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

Prozesse, Methoden, Werkzeuge

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.

Big Data treibt das Fahrzeug an

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:
  • Speziell ausgestattete Testfahrzeuge sind weltweit im Einsatz und sammeln Daten. Ein solches Fahrzeug kann pro Tag bis zu 100 TB Daten aufzeichnen, die dann selektiert und aufbereitet werden [5].
  • Daten aus dem normalen Betrieb bereits verkaufter Fahrzeuge werden vom OEM gesammelt, anonymisiert und für die Verbesserung bereits entwickelter und im Markt befindlicher Systeme genutzt.
  • Daten aus Simulationsumgebungen werden aufbereitet und meist für den Test der KI-Systeme verwendet.
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.

Vernetzt und kommunikativ

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.

Over-the-Air-Updates

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.

Abwehr digitaler Gefahren

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.

Zusammenarbeit und Vorzeigeprojekt Continental

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.

Literaturhinweise

[1]
Burkacky, O. et al.: McKinsey: Rewiring car electronics and software architecture for the 'Roaring 2020s'. Online: https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/rewiring-car-electronics-and-software-architecture -for-the-roaring-2020s, aufgerufen: 7. Dezember 2021
 
[2]
ISO 26262:2018: Road vehicles - Functional safety. Part 1 - Part 12. Online: https://www.iso.org/standard/68383.html, aufgerufen: 22. Dezember 2021
 
[3]
Red Hat, Inc. (Hrsg.): Red Hat Sets Sights on Delivering the First Continuously Certified Linux Platform for Road Vehicles. Online: https://www. redhat.com/de/about/press-releases/red-hat -sets-sights-delivering-first-continuously-certified-linux-platform-road-vehicles, aufgerufen: 8. Dezember 2021
 
[4]
ZVEI (Hrsg.): Best Practice Guideline - Software for Safety-Related Automotive Systems. 2016. Online: https://www.zvei.org/fileadmin/ user_upload/Presse_und_Medien/Publikationen/ 2016/August/Software_for_Safety-Related _Automotive_Systems__Best_Practice_Guideline_ /Software-for-Safety-Related-Automotive-Systems -Guideline-ZVEI-Stand-2016-12.pdf, aufgerufen: 10. Dezember 2021
 
[5]
Steele, P.; Hendel, D.: Wie digitale Ökosysteme vernetzte Fahrzeuge antreiben. Online: https://blog.equinix.com/blog/2021/03/02/wie-digitale-okosysteme-vernetzte-fahrzeuge-antreiben/, aufgerufen: 30. November 2021
 
[6]
United Nations: Addendum 155 - UN Regulation No. 156. Uniform provisions concerning the approval of vehicles with regards to software update and software updates management system. Januar 2021. Online: https://unece.org/sites/default/files/2021-03/R156e.pdf, aufgerufen: 22. November 2021
 
[7]
ISO/DIS 24089 Road vehicles - Software update engineering. Online: https://www.iso. org/standard/77796.html, aufgerufen: 27. November 2021
 
[8]
United Nations: Addendum 154 - UN Regulation No. 155. Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system. Januar 2021. Online: https://unece.org/sites/default/files/2021-03/R155e.pdf, aufgerufen: 4. Dezember 2021
 
[9]
ISO/SAE 21434:2021: Road vehicles - Cybersecurity engineering. Online: https://www.iso.org/standard/70918.html, aufgerufen: 22. Dezember 2021
 
[10]
Cotton, L.: International Business Machines: Accelerating insight into vehicle safety at Continental. Online: https://www.ibm.com/case-studies/continental-automotive/, aufgerufen: 9. Dezember 2021
 

Our product recommendations

ATZelektronik

Die Fachzeitschrift ATZelektronik bietet für Entwickler und Entscheider in der Automobil- und Zulieferindustrie qualitativ hochwertige und fundierte Informationen aus dem gesamten Spektrum der Pkw- und Nutzfahrzeug-Elektronik. 

Lassen Sie sich jetzt unverbindlich 2 kostenlose Ausgabe zusenden.

Metadata
Title
Auf dem Weg zum softwaredefinierten Fahrzeug
Author
Hans Windpassinger
Publication date
01-07-2022
Publisher
Springer Fachmedien Wiesbaden
Published in
ATZelektronik / Issue 7-8/2022
Print ISSN: 1862-1791
Electronic ISSN: 2192-8878
DOI
https://doi.org/10.1007/s35658-022-0781-5

Other articles of this Issue 7-8/2022

ATZelektronik 7-8/2022 Go to the issue

The Hansen Report

On Automotive Electronics

The Hansen Report

The Hansen Report

Premium Partner