Automotive: Wie sich die Variantenvielfalt der Software kontrollieren lässt

Software im Automobil wird wichtiger und komplexer. Dies ist Trends wie Connected Car, dem autonomen Fahren, dem Einsatz von Assistenzsystemen und neuen Formen von Human Machine Interfaces geschuldet. Davon profitieren Käufer von Fahrzeugen. Denn ihnen stehen zusätzliche Komfort- und Sicherheitsfunktionen zur Verfügung wie beispielsweise Sprachsteuerungen, die Sprachassistenten von Anbietern wie Amazon (Alexa), Google und Apple nutzen. Zudem sind immer mehr Fahrzeuge permanent („Always-on“) mit einer Cloud verbunden. Über Cloud-Plattformen kann der Nutzer individuelle Services buchen, etwa einen Car-Sharing-Dienst oder einen

Platz an einer Ladesäule. Auch Software-Updates lassen sich künftig „Over the Air“ (OTA) via Cloud aufspielen. Das gilt auch für aktualisierte Sicherheitsfunktionen, die ein Fahrzeug vor Hacker-Angriffen schützt. Wohin die Reise geht, zeigt beispielsweise der ID.3 von Volkswagen. Das Elektro-Fahrzeug lässt sich je nach Version mit 2D- und 3D-Human-Machine-Interfaces ausstatten.

Doch diese Entwicklung bringt für Hersteller und OEMs auch Herausforderungen mit sich:

• Der Aufwand für das Entwickeln neuer und das Anpassen vorhandener Software-Funktionen steigt und wird zu einem ernstzunehmenden Kostenfaktor für die Automobilindustrie.
• Die Zahl und Komplexität der Fahrzeugmodelle sowie Ausstattungsoptionen, und damit auch der Steuergeräte, Prozessorderivate und Software-Architekturen nimmt zu. Das führt zu vielen Software-Varianten, die es zu verwalten gilt.
• Zahlreiche Software-Funktionen wurden über Jahre hinweg weiterentwickelt und gepflegt. Der Pflegeaufwand steigt dadurch kontinuierlich.

Diese Faktoren verdeutlichen, dass der Anteil der Software- und E/E-Komponenten (Electrical and Electronics) in Fahrzeugen erheblich steigt. Laut der Studie „Automotive Software and Electronics 2030“ des Beratungsunternehmens McKinsey von 2019 wird der Wertanteil von Lösungen aus beiden Bereichen von 238 Milliarden Dollar im Jahr 2020 bis 2030 auf rund 470 Milliarden Dollar steigen. Der Bereich Software (Funktionen, Betriebssysteme und Middleware) legt in den kommenden zehn Jahren um durchschnittlich 9 Prozent pro Jahr zu. Die Aufwendungen für Services wie Integration, Verifizierung und Validierung steigen um zehn Prozent.

Die zunehmende Komplexität der Software hat weitere Effekte: McKinsey zufolge ergibt sich eine immer größere Lücke zwischen der Produktivität der Software-Fachleute und der Anforderung, immer reichhaltigere Programme möglichst schnell verfügbar zu machen. Der Ansatz Software-Projekte mit immer größeren Teams durchzuführen wird auf Dauer nicht mehr umsetzbar sein. Ein Infotainment-System zu entwickeln, dauert beispielsweise drei Jahre und bindet Hunderte von Entwicklern. An die 30 bis 50 Prozent der Zeit und damit des Aufwandes müssen diese darauf verwenden, die Komponenten der diversen Zulieferunternehmen in die Lösung einzubinden und zu testen.

Problempunkt: Vielfalt von Software-Varianten

Ein weiterer Problempunkt ist die große Zahl von funktionalen und Anwendungsvarianten von Software-Komponenten, die eigentlich dieselbe Funktion erfüllen. Ein Beispiel sind Navigations- und Infotainment-Systeme. Die

Bild 1: Die Evolution der Electrical-and-Electronic-Architektur (E/E) in Fahrzeugen: Die Entwicklung geht in Richtung einer serviceorientierten Software-Architektur (SOA). Elektrobit

Bild 2: Zur höheren Komplexität von Software im Automobilbereich tragen mehrere Faktoren bei: der wachsende Funktionsumfang, die System- und Konfigurationsvarianten und die Zahl der Marken und der individuellen Fahrzeugversionen für spezielle Märkte. Elektrobit

Anforderungen vieler Automobilhersteller an diese Lösungen sind ähnlich, doch die Umsetzung der Funktionen in Software unterscheidet sich häufig im Detail, etwa aufgrund des Einsatzes unterschiedlicher Schnittstellen oder individueller Anforderungen der Hersteller. Selbst bei nicht differenzierenden Software-Komponenten wie AUTOSAR gibt es eine Vielzahl OEM-spezifischer Interpretationen des Standards sowie OEM-spezifische Erweiterungen. Dadurch müssen vorhandene Software-Module an die individuellen Anforderungen jedes Automobilherstellers angepasst werden. Eine unveränderte Wiederverwendung von vielen Modulen ist praktisch ausgeschlossen. Das erhöht den Aufwand und die Kosten bei der Entwicklung beziehungsweise Anpassung und der langfristigen Pflege.

Hinzu kommt der Aufwand, den das Anpassen von Software beim Wechsel von einer Fahrzeuggeneration zur nächsten erfordert. Während man davon ausgeht, dass der Löwenanteil des Aufwandes in die Entwicklung neuer Funktionen fließen sollte, zeigen Auswertungen von Elektrobit, dass nur etwa 40 Prozent des Entwicklungsbudgets für neue Funktionen aufgewendet werden, aber 60 Prozent für die Pflege bestehender Funktionen.

Doch ein Reduzieren der Software-Versionen wird durch die hohe Zahl der Hardware- und Plattformvarianten bei den einzelnen Automobilherstellern erschwert. Durch die Einführung flexibler Plattformkonzepte haben die Autobauer in den letzten Jahren erreicht, dass sie vergleichsweise einfach neue Fahrzeugmodelle ableiten können. Vor 40 Jahren hatte Daimler circa zehn Fahrzeugmodelle, in den 2000er Jahren waren es bereits 20 und für das Jahr 2020 sind bis zu 40 Modelle vorgesehen. Dies bedeutet, dass auch die eingesetzte Software diese Vielfalt „abbilden“ muss. Das erfolgt durch die Anpassung der Programme, die in den Steuergeräten in einem Fahrzeug eingesetzt werden.

Dieser Faktor erhöht den Aufwand, der mit der Entwicklung von Software verbunden ist. Gleiches gilt für die Integration und den Test der Software-Varianten. Während Fahrzeughersteller eine ausgefeilte Logistik für die Handhabung von unterschiedlichen Fahrzeugteilen besitzen, fehlen häufig Konzepte für den Umgang mit Software-Varianten.

Ansätze zur Reduzierung der Komplexität von Plattformen

Abhilfe kann eine stärkere Standardisierung der Software in Automobilen schaffen, etwa im Rahmen von Gremien wie AUTOSAR. AUTOSAR ist als Standard etabliert und hat zu einer erheblichen Kosteneinsparung und Qualitätssteigerung bei Standardsoftware geführt. Durch die immer noch große Variantenvielfalt ist das Potenzial jedoch noch nicht ausgeschöpft. Ein Beispiel ist AUTOSAR 4.x. Obwohl damit bereits eine weitgehende Vereinheitlichung definiert wurde, gibt es immer noch eine Vielzahl von OEM-spezifischen Varianten und Erweiterungen. Das führt dazu, dass Software nur eingeschränkt wiederverwendet werden kann. Die Qualität von Standardsoftware lässt sich so nur schrittweise verbessern. Es gilt also, zusätzlich neue Ansätze hinzuziehen.

Ein Vorbild für schnelle und effiziente „Entwicklung“ von Standards können dabei Ansätze von Open Source sein. Open Source erlaubt eine vergleichsweise einfache Evaluation und Weiterentwicklung neuer Software-Lösungen, da sich nur wenige Standards flächendeckend durchsetzen. Lösungen, die nicht praktikabel sind, finden keine weitere Verwendung.

Aktive Verwaltung von Software-Varianten

Eine weitere Option ist ein aktives Management von Software-Varianten. Dies muss in der Software-Architektur angelegt sein. Eine Möglichkeit ist, Varianten an möglichst wenigen Stellen in der Software „anzulegen“, etwa in Abstraktionsschichten (Layern). Dadurch ist es einfacher, standardisierte Software-Bausteine auf unterschiedlichen Systemen zu verwenden.

Die Wiederverwendung von Software ist kein Selbstzweck. Wiederverwendung macht dann Sinn, wenn sie zu Kostensenkungen und Qualitätssteigerung führt. Dies muss in der Architektur angelegt sein. In vielen Projekten wird die Priorität jedoch auf eine individuelle Optimierung von Software gelegt, bezogen auf das Steuergerät sowie die OEM-Architektur und Funktion. Dies geht zu Lasten der langfristigen Qualität und Stabilität der Software und führt zu einem höheren Aufwand.

Agile Entwicklungsmethoden einsetzen

Eine andere Möglichkeit ist die Einführung agiler Entwicklungsmethoden wie Lean Development, Scrum, Kanban und DevOps. Durch sie lassen sich Ergebnisse schnell auf Nutzbarkeit praktisch untersuchen. Während bei Lean Development die kontinuierliche Verbesserung der Arbeitsabläufe sowie die Stärkung der Eigenverantwortung der Entwicklerteams im Vordergrund stehen, setzt sich agile Entwicklung insbesondere mit der Risikominimierung auseinander, um dank höherer Transparenz im Entwicklungsprozess Produkte schneller zur Serienreife zu bringen.

Bei Scrum handelt es sich um eine Umsetzung dieser beiden Konzepte für die Steuerung von Software-Projekten. Dabei werden die anstehenden Aufgaben in kleinere und überschaubare Abschnitte strukturiert, um ihre Komplexität zu reduzieren. Kanban schließlich reduziert die Zahl paralleler Arbeiten durch eine Visualisierung der bestehenden Arbeitsabläufe. Dadurch werden sowohl der Projektfortschritt als auch Engpässe schneller sichtbar. Ergänzend lassen sich Verfahren wie DevOps (Development – IT Operations) einsetzen. DevOps zielt darauf ab, das Zusammenspiel zwischen Software-Entwicklung und der IT-Infrastruktur zu verbessern.

Bild 3: Die steigende Software-Komplexität im Fahrzeug erfordert ein Umdenken in der Automobilindustrie. Elektrobit

Total Cost of Ownership für Software

Unabhängig von solchen Optimierungsmaßnahmen gilt es jedoch, das Bewusstsein von Herstellern und Zulieferern für den „Kostenfaktor Software“ zu schärfen. Wichtig ist beispielsweise, dass bereits bei der Projektplanung geprüft wird, wie viele neue Software-Varianten tatsächlich benötigt werden und wie sich der Aufwand für Varianten und Anpassungen bestehender Komponenten reduzieren lässt.

Dazu ist es sinnvoll, Software-Kosten ganzheitlich zu betrachten („Total Cost of Ownership“). Das ist heute häufig noch nicht der Fall. In einem Beispiel bei Elektrobit hätte der Austausch eines Mikro-Controllers zu einer Einsparung von ca. einem Euro pro Steuergerät geführt. In diesem Fall würde das bei geplanten acht Millionen Fahrzeugen zu einer erheblichen Kosteneinsparung führen. Andererseits erfordert der Austausch des Controllers eine Requalifizierung des Betriebssystems und dazugehörige kontinuierliche Integrationsarbeiten sowie Tests über die Projektlaufzeit hinweg. Für Anpassungen, Test und Integration kann sich das zu einem Projektteam von 30 Mitarbeitern über drei Jahre summieren. Die so erforderliche Anpassung der Software verschlingt damit etwa zehn Millionen Euro. Dadurch würde der Einspareffekt in der Hardware ad absurdum geführt.

Gemeinsam Software-Komplexität reduzieren

Letztlich bedeutet dies, dass die Industrie beim Einsatz von Software umdenken muss: Es sollten nicht nur die Kosten von Bauteilen und mechanischen Komponenten von Steuerungssystemen berücksichtigt werden, sondern auch die Aufwendungen für die Entwicklung und Anpassung der Software. Das heißt: Die Industrie muss eine neue Sichtweise für Software-Entwicklung erlangen und gemeinsam die Komplexität und Vielfalt von Software aktiv reduzieren. Software-Unternehmen aus der IT-Industrie arbeiten aktiv daran, die Anzahl von gepflegten Produktversionen gering zu halten. Neue Funktionen werden nur in der letzten Software-Version entwickelt; für ältere Software-Versionen werden lediglich Bugfixes angeboten. Diese Software-Unternehmen versuchen auch die Abhängigkeit ihrer Software von Hardware oder Systemen zu isolieren, um Anpassungsaufwände möglichst gering zu halten.

Ein gemeinsames Umdenken ist unabdingbar. Denn die Komplexität der Software entwickelt sich zunehmend zu einem Problem für das gesamte Ökosystem Auto: Hersteller und Zulieferer sehen sich mit wachsenden Kosten durch die Implementierung und Wartung von Software konfrontiert. Dieser Trend ist angesichts des immer härteren Wettbewerbs im Automobilsektor nicht akzeptabel.

(wi)