Interview: "Software-for-Life-Strategie"

asp: Herr Gillen, was versteht man unter einem Software Defined Vehicle?

C. Gillen: In einem Software Defined Vehicle stehen nicht mehr die Hardware des Fahrzeugs, sondern die Software-Funktionen im Vordergrund. Ein Merkmal ist auch die Architektur: Es braucht nicht mehr jedes System ein eigenes Steuergerät, sondern es existiert eine mehr oder weniger einheitliche Hardware-Plattform, die durch Softwarefunktionen erweitert werden kann. So lässt sich auch die Variantenvielfalt von Fahrzeugen reduzieren, was beim Car Sharing oder auch beim Verkauf des Fahrzeugs wichtig sein kann. Der Einsatz von mehr Gleichteilen kann auch zu einer schnelleren Verfügbarkeit bei Fahrzeugen führen.

asp: Können Sie ein Beispiel für so eine Software-Funktion bringen?

C. Gillen: Nehmen wir als Beispiel die Seitenwelle eines Fahrzeugs. In einem Software Defined Vehicle ließe sich anhand des Fahrprofils mithilfe einer Software-Funktion erkennen, wenn dieses Bauteil Beschädigungen davongetragen hat und eventuell ausgetauscht werden muss. Man benötigt dafür nicht mal einen Sensor an der Seitenwelle. Allein durch die Drehzahl des Rades, die Drehzahl des Getriebes und über andere Daten ließen sich Rückschlüsse über den Zustand der Welle ableiten. Auch eine Predictive-Maintenance-Funktion könnte realisiert werden. So eine Software-Funktion kann auch fünf Jahre nach Verkauf des Fahrzeugs noch integriert werden. Das ist wie bei einem Smartphone, das durch Software-Funktionen erweitert wird.

asp: Sind Anwender auch bereit, für Software-Funktionen Geld zu bezahlen?

C. Gillen: Das ist eine Frage der Akzeptanz, man sieht aber eine steigende Bereitschaft von Kunden, für zusätzliche Komfort- und Performance-Funktionen im Auto zu bezahlen. Man spricht dann von "Functions on Demand", sprich, bestimmte Fahrzeugfunktionen sind bereits in der Hardware vorhanden und können per Software freigeschaltet werden. Beispiel: Der Kunde könnte sich für ein Wochenende auf der Rennstrecke eine Torque-Vectoring-Funktion seines Allradantriebs gegen Gebühr freischalten lassen. Das Fahrzeug ließe sich aber auch individualisieren. Beispielweise hat ein Vertriebsmitarbeiter andere Ansprüche als ein Familienvater.

asp: Wie lange müssen Software-Updates für Fahrzeuge bereitgestellt werden?

C. Gillen: Wir reden inzwischen von einer "Software-for-Life"-Strategie. Das heißt, wir müssen unsere Produkte so konzipieren, dass sie über das Produktionsende hinaus noch per Software unterstützt werden. Vor dem Hintergrund der Cyber-Sicherheit müssen unsere Produkte zehn bis 15 Jahre nach Produktionsende noch weiter mit Software unterstützt werden, beispielsweise mit Updates, Patches oder einem Sicherheitsfix.

asp: Wie können Sie einen Software-Support über einen so langen Zeitraum garantieren?

C. Gillen: Das ist eine Herausforderung für die Industrie. Denn man muss bedenken, dass der eigentliche Zeitraum noch viel länger ist und rund 25 Jahre betragen kann. Nehmen wir ein Beispiel: Wenn ein Fahrzeug seit 2010 nicht mehr produziert wird und 15 Jahre Support hat, müssten wir bis heute Support liefern. Die Produktion des Fahrzeugs fand aber eventuell über einen Zeitraum von sieben Jahren statt, also wurde die Produktion 2003 gestartet. Und die Entwicklung fand noch viel früher statt, vielleicht um die Jahrtausendwende, als es noch Disketten gab. Da kann man sich vorstellen, was man alles an alten Rechnersystemen am Leben erhalten muss, um noch Support liefern zu können. Man muss auch das Know-how bewahren, solche Systeme programmieren zu können. Hier muss viel dokumentiert werden, um dieses Wissen zu bewahren.

• Ausgabe 10/2025 Seite 020 (451.6 KB, PDF)

asp: Welchen Stellenwert hat das Thema Sicherheit in einem Software Defined Vehicle?

C. Gillen: Das Thema Sicherheit spielt natürlich eine große Rolle. Ich würde das Thema in zwei Bereiche unterteilen: In die Funktions- und Produktsicherheit (Safety) und in die Sicherheit gegen Angriffe von außen (Security), was den Bereich Cyber-Sicherheit meint. Letzterer Bereich ist in der Homologationsvorschrift UN ECE R155 und R156, das sogenannte Cybersecurity-Management-System, beschrieben. Es schreibt vor, dass Hersteller schon in der Entwicklung des Fahrzeugs bestimmte Sicherheitsmechanismen betrachten müssen ("Security by Design"). Und seit Juli 2024 ist das sogar Vorschrift, um ein Fahrzeug homologieren zu können. Das betrifft auch die Lieferanten, denn man kann das Fahrzeug nicht sicher machen, wenn die Bauteile nicht sicher sind. Unsere Bauteile können Ziel eines Angriffs sein oder das Fenster dafür, um den Angriff durchführen.

asp: Wie lässt sich die Sicherheit von Software umsetzen?

C. Gillen: Man muss verschiedene Sicherheitslagen in der Software haben, was wir als "Security in Depth" beschreiben. Am Beispiel eines Wohnhauses lässt sich das verdeutlichen: Wenn das Haus abgesperrt ist, aber die Fenster offen sind, kommt ein Dieb trotzdem hinein. Das Haus muss also komplett abgesichert sein. Dennoch gibt es wertvolle Dinge, die man nicht im Haus herumliegen lassen würde, sondern lieber in einem abgesperrten Raum unterbringt. Wenn man etwas besonders stark schützen will, sollte es zusätzlich in einem Safe liegen. Im Autobereich wäre das beispielsweise ein Authentifizierungsschlüssel. Die Kommunikation sollte nie ungesichert und offen zwischen den Steuergeräten stattfinden, sondern digital signiert oder sogar verschlüsselt sein. Das kann auf allen Bus-Systemen realisiert werden. Und das sowohl für die Schnittstellen nach außen wie WLAN oder Bluetooth als auch nach innen.

asp: Wird es im Zeitalter der Software Defined Vehicles noch möglich sein, eine Fahrzeugdiagnose durchzuführen?

C. Gillen: In Software Defined Vehicles lassen sich sogar noch detailliertere Diagnosefunktionen abrufen, die idealerweise nicht nur auf Basis von Sensorwerten Daten liefern. Die Software kann aufgrund der Fahrzeugfunktionen ableiten, wo der Fehler zu finden sein könnte. Ist beispielsweise nur ein Kabel kaputt, der Stecker oder der Kabelbaum? Oder ist ein komplettes Bauteil defekt? Hier ist es interessant, sich das Gesamtverhalten eines Systems anzuschauen, um bestimmte Fehler zu finden. Oder auch um festzustellen, ob ein Sensorwert im Vergleich zum Rest des Systems plausibel ist. Letztlich wird damit die Diagnosefähigkeit verbessert.