Der Wandel zu softwarebasierten Fahrzeugfunktionen

Der Siegeszug von softwarebasierten Funktionen in Fahrzeugen gegenüber hardwarebasierten, einschließlich klassischer Embedded Systems, ist unvermeidlich. Ständig steigende Anforderungen, etwa durch smartere Assistenzsysteme oder autonome Fahrfunktionen, stellen hohe Ansprüche an die Signalverarbeitung sowie an die daraus abgeleiteten Steuerungsmaßnahmen und die Interaktion mit den Fahrer:innen. Diese Anforderungen lassen sich mit herkömmlicher Architektur, die teils über hundert verteilte Steuergeräte im Fahrzeug umfasst, weder funktional noch wirtschaftlich erfüllen. Auch der Bedarf an Wartung und kontinuierlicher Weiterentwicklung von Fahrzeugen im laufenden Betrieb verstärkt den Trend weiter.

Herausforderungen für Entwicklungsabteilungen

Mit der Entwicklung von Fahrzeugen zu digitalisierten, softwarebasierten Produkten stehen die Entwicklungsabteilungen der Hersteller und Zulieferer vor der Herausforderung, bewährte Prozesse auf die speziellen Anforderungen von Software umzustellen. Während die Verantwortung bislang meist mit dem Beginn der Serienproduktion endete, begleitet sie softwaregesteuerte Fahrzeuge heute über den gesamten Lebenszyklus, von Sicherheits- und Funktionsupdates im laufenden Betrieb bis hin zur datenschutzkonformen Stilllegung oder Verschrottung am Ende der Nutzung. Diese lebenszyklusorientierte Denkweise ist nicht nur der Natur von Software geschuldet, die kontinuierliche Pflege und Weiterentwicklung erfordert (zum Beispiel zur Sicherstellung der Cyber Security), sie ist auch durch spezifische Regularien und Standards wie UN ECE R155-R156 und ISO 21434 vorgegeben.

Neue Möglichkeiten durch Software-Updates

Die Notwendigkeit, Software über den gesamten Lebenszyklus eines Fahrzeugs aktuell zu halten, eröffnet neue Möglichkeiten. Updates ermöglichen es, auch nach Auslieferung funktionale Erweiterungen und Verbesserungen bereitzustellen. Das schafft Raum für neue Geschäftsmodelle und hilft gleichzeitig, die funktionale Alterung von Fahrzeugen zu verlangsamen, was den Wertverlust von Gebrauchtfahrzeugen reduzieren kann.

Die Notwendigkeit einer zentralen Software-Plattform

Um zu vermeiden, dass unterschiedliche Softwarestände für verschiedene Fahrzeugtypen und -generationen parallel gepflegt werden müssen – was wirtschaftlich kaum sinnvoll wäre – ist der Aufbau einer Software-Plattform nötig, die weit über die klassische Plattformfähigkeit von Hardware hinausgeht.

Es ist z. B. ineffizient, für verschiedene Fahrzeugtypen eines Herstellers – etwa für Modelle im Einstiegs- oder Luxussegment – jeweils eigene Software-Stacks zu entwickeln. Die typenbezogene Anpassung der Software hat durch Einstellungen in der Software zu erfolgen. Auf diese Weise bleiben Updates über alle Fahrzeugtypen hinweg kompatibel, ohne typenspezifische oder kundenindividuelle Einstellungen zu überschreiben.

Ein solcher plattformbasierter Ansatz, der über Modell- und Generationengrenzen hinweg funktioniert, lässt sich nur realisieren, wenn ein zentraler Software-Stack Zugriff auf alle relevanten Informationen aus dem Fahrzeug hat (z.B. von Sensoren) und daraus Steuerbefehle für alle Steuergeräte ableitet.

Das bedeutet: Die bisher verteilte Intelligenz im Fahrzeug wird zentralisiert. Funktionalitäten, die bislang in einzelnen Steuergeräten lagen, werden in den zentralen Software-Stack überführt. Die Kommunikation zwischen dem zentralen Stack und den Steuergeräten erfolgt über softwaredefinierte Schnittstellen. So bleibt der zentrale Stack unabhängig von der konkreten Hardware, dieser kann mit unterschiedlichen Steuergerätetypen und -generationen kommunizieren, solange diese die notwendigen Schnittstellen unterstützen.

Strategische Planung über die Fahrzeuggeneration hinaus

Die bisherigen Punkte machen deutlich, dass der Einsatz und die Entwicklung von Software strategisch gedacht und geplant werden müssen und zwar über die nächste Fahrzeuggeneration hinaus.

Gleichzeitig erfordert der wachsende Stellenwert von Software eine klare Steuerung (Governance), die ihre besonderen Eigenschaften systematisch berücksichtigt. Dazu zählen:

• die Zentralisierung von Funktionalitäten,
• der Aufbau einer typen- und generationenübergreifenden Plattform,
• die Fehleranfälligkeit sowie steigende Anforderungen an Qualität und regulatorische Compliance,
• und die Notwendigkeit, Security als wesentliches Handlungsfeld neben Safety zu behandeln.

Diese Prinzipien müssen von Anfang an in den Entwurf der Fahrzeugarchitektur, in die Formulierung von Requirements sowie in die Definition und Prüfung von Qualitätsanforderungen einfließen.

Qualitätsanforderungen und -ziele

Eine zentrale Rolle spielt die Definition von klaren Qualitätsanforderungen und -zielen. Sie beeinflussen im Sinne des „Shift-Left“-Ansatzes nicht nur die Softwareentwicklung, sondern auch die stetige Verbesserung von Architektur und Requirements.

Dabei reicht die einfache Forderung, dass Software „funktionieren muss“, längst nicht aus.

Dabei stellt sich regelmäßig die Frage, ob neue Funktionen lediglich Ergänzungen im bestehenden Stack erfordern, ob zusätzliche Anpassungen an den dezentralen Steuergeräten notwendig sind oder ob Änderungen am zentralen Software-Stack selbst unvermeidbar sind. Letzteres hat direkte Auswirkungen: Jede Änderung am zentralen Stack führt zu höherem Pflegeaufwand durch parallele Software-Versionen. In diesem Rahmen ist auch stets zu überlegen, inwiefern neue Funktionalitäten auch für ältere Fahrzeuge verfügbar gemacht werden sollen.

All das zeigt: Qualitätsziele für Fahrzeugsoftware gehen weit über die reine Prüfung der korrekten Funktion hinaus. Im Zuge der Umstellung hin zu Software Defined Vehicles verändern sich Strategien, Fahrzeugarchitekturen, Entwicklungsprozesse, Toolchains und die Zusammenarbeit mit Lieferanten grundlegend. Diese Veränderungen und die spezifischen Eigenschaften von Software müssen in den Qualitätszielen abgebildet werden.

Messbarkeit von Qualitätszielen

Um Ziele setzen und den erreichten Qualitätsstand bewerten zu können, ob absolut oder im Vergleich, müssen Qualitätsziele messbar sein. Für Software in Fahrzeugen fehlt bislang diese Voraussetzung. Das ist einer der Hauptgründe, warum es heute so schwer ist, ein angemessenes Qualitätsniveau sicherzustellen: was sich nicht messen lässt, kann auch nicht zuverlässig bewertet werden. Solange keine klaren Messkriterien definiert sind, bleibt die Frage offen, wie viel getestet werden muss und ab wann die Software als ausreichend qualitätsgesichert gelten kann.

Das Software Quality Framework von Deloitte

Dieser Herausforderung widmet sich unser Paper auf Basis bewährter Ansätze aus der Praxis, unter anderem aus der Wirtschaftsprüfung. Dort geht es darum, dass der Jahresabschluss die wirtschaftliche Lage korrekt abbildet und trotz komplexer Systeme und vieler potenzieller Fehlerquellen eine ausreichende Sicherheit (Assurance) geschaffen wird. Absolute Fehlerfreiheit ist dabei weder realistisch noch das Ziel. Entscheidend ist, wesentliche Fehlerquellen zu erkennen und zu beseitigen.

Genau diese Denkweise lässt sich auf Software übertragen: Auch hier geht es darum, systematisch Fehlerquellen zu identifizieren, zu bewerten und zu minimieren, nicht um eine Garantie auf Fehlerfreiheit.

Im Vergleich zur Finanzbuchhaltung ist die Komplexität von Fahrzeugsoftware jedoch deutlich höher und die Folgen nicht entdeckter Fehler können im schlimmsten Fall Leib und Leben gefährden. Dieser Tatsache trägt Deloitte im Software Quality Framework Rechnung. Neben etablierten Standards wie ISO 25.000 fließen hier auch fahrzeugspezifische Anforderungen wie ISO 26262, 21434, 21448 etc. sowie homologationsrelevante gesetzliche Rahmen wie UNECE in die Bewertung ein.

Wichtig dabei: Unser Framework versteht sich nicht als starres Prüfschema, das heute schon vollständig umgesetzt werden muss und es unterstellt auch nicht, dass OEMs und Lieferanten derzeit keine Qualitätsmaßnahmen für ihre Software-Produkte ergriffen haben. Viele der ergriffenen Maßnahmen stammen jedoch noch aus einer hardware-zentrierten Zeit und stoßen in der zunehmend softwaregeprägten Fahrzeugentwicklung an ihre Grenzen: hoher Aufwand und nicht zufriedenstellende Qualität.

Ein systematischer Ansatz für Softwarequalität

Das Software Quality Framework bietet einen Rahmen, um Qualitätsmaßnahmen für Fahrzeugsoftware gezielt zu planen, abzustimmen und schrittweise umzusetzen. Ohne einen solchen systematischen und nachweisbaren Ansatz, steigt der Aufwand schnell in wirtschaftlich problematische Höhen. Gleichzeitig drohen Akzeptanzprobleme am Markt und Schwierigkeiten bei der Erfüllung regulatorischer Vorgaben, wenn Softwarequalität für Kund:innen spürbar mangelhaft bleibt.