Die Code-Menge allein sagt nichts darüber aus, wie viel Programmieraufwand in einer Applikation steckt, sagt Martin Schleicher von der Elektrobit Automotive GmbH (Bild: Elektrobit)
Herr Schleicher, Experten gehen davon aus, dass in den nächsten zehn Jahren der Softwareanteil im Auto durch neue Funktionen um den Faktor zehn klettern soll. Ist das ein realistischer Wert?
Die Einschätzungen variieren. Manche Szenarien gehen davon aus, dass wir 2030 bis zu einer Milliarde Programmzeilen im Auto haben werden – insbesondere dann, wenn autonome Fahrfunktionen auf Level 4 und 5 dazu kommen. Wie viele Lines of Code es am Ende tatsächlich sein werden, wird auch stark davon abhängen, wie viel Funktionalität direkt an Bord läuft und wie viel im Backend berechnet wird. Fest steht aber: Wir werden einen deutliche Zunahme von Software im Fahrzeug sehen.
Nicht nur der Anteil von Software im Fahrzeug wächst, sondern auch die Größe der Entwicklungsteams. Lässt sich diese Korrelation entkoppeln?
Mal grundsätzlich: Aus meiner Sicht sollte die Anzahl der Lines of Code nicht der alleinige Gradmesser für die Komplexität eines Softwaresystems sein. Einzelne Programmzeilen zu duplizieren, ist nämlich nicht schwierig. Hochoptimierte Algorithmen zu erstellen, die von ihrem Umfang her weniger stark ins Gewicht fallen, dagegen schon. Allein die Code-Menge sagt also nichts darüber aus, wie viel Aufwand und Leistung in einer Applikation stecken. Aber Sie haben Recht: Auch wir bei Elektrobit müssen uns Gedanken darüber machen, wie wir große Entwicklungsprojekte effizient managen. Die Produktivität in den einzelnen Teams muss durch agile Arbeitsmethoden und neue Tools steigen. Der Mangel an gut ausgebildeten und erfahrenen Entwicklern macht diese Aufgabe auch unter wirtschaftlichen Gesichtspunkten nicht eben leichter. Die Zeiten, in denen man Probleme in der Softwareentwicklung durch eine personelle Aufstockung des Teams lösen konnte, sind vorbei.
Oft erfüllen unterschiedliche Anwendungsvarianten dieselbe Funktion. Wie kann man solche „Doppelarbeit“ vermeiden?
Das ist ein wunder Punkt für die Automobilindustrie. Eigentlich haben wir mit Autosar eine offene und standardisierte Softwarearchitektur für elektronische Steuergeräte. Trotzdem kommt es durch herstellerspezifische Anpassungen und Erweiterungen immer wieder zu unterschiedlichen Ausprägungen dieses Betriebssystems. Manches davon mag notwendig sein, aber sicher nicht alles. Diese Vielfalt führt automatisch zu einem erhöhten Aufwand – nicht nur in der Entwicklung selbst, sondern in der Folge auch beim Testen, der Integration und der Software-Pflege. Dieses Problem haben einige OEMs durchaus erkannt: 90 Prozent ihrer eigenen Entwicklungskapazität stecken sie in das Testen und die Integration von Software. Dabei bräuchten sie diese Manpower viel dringender, um neue Funktionen zu entwickeln, die einen Mehrwert für die Kunden bringen.
Bis zu welchem Grad lässt sich Steuerungssoftware wiederverwenden?
Das hängt von der jeweiligen Anwendung ab: Sprechen wir über eine Steuerungsfunktion für ein einzelnes ECU oder ein Update für das komplette Betriebssystem? Ich kenne Fälle, in denen ein Hersteller lediglich 40 Prozent der Software von einer Steuergerätegeneration auf die nächste übernehmen konnte. Der Rest musste angepasst oder gar neu entwickelt werden. Dieser Aufwand liegt deutlich zu hoch. Man sollte erwarten, dass 80 Prozent einer bestehenden Software-Komponente wieder zum Einsatz kommen kann. Dafür muss die Architektur modular konzipiert und von Beginn darauf ausgelegt sein, Hardware-Abhängigkeiten und funktionale Unterschiede zu kapseln und zu abstrahieren.
Was ist Stand heute schwieriger: das Beherrschen einzelner Funktionen oder das orchestrierte Zusammenspiel verschiedener Software im Fahrzeug?
Die große Herausforderung ist heute das reibungslose Zusammenspiel der vielen Softwarefunktionen im Fahrzeug. Flexibilität hat Nebenwirkungen. Je mehr Signale über den CAN-Bus verschickt werden, desto größer ist die Gefahr, dass es an irgendeiner Stelle zu Abhängigkeiten kommt, die nicht gewünscht sind.
Welche Voraussetzungen müssen im Backend und im Fahrzeug selbst erfüllt sein, um Software-Varianten aktiv managen zu können?
Nicht nur deutsche OEMs nutzen das Baukastenprinzip, um Fahrzeuge aus einer Vielzahl einzelner Komponenten und Bauteile zusammen zu setzen und unterschiedliche Varianten zu gestalten. Das hat auf die Software abgefärbt: Sie können heute bestimmte Funktionalitäten softwareseitig konfigurieren und Ausstattungsanpassungen vornehmen. Der Modulare Infotainment-Baukasten ist dafür ein Paradebeispiel – gut durchdacht und extrem flexibel, um verschiedene technische Ausbaustufen mit regionalen Features über alle Marken hinweg anbieten zu können. Eine zweite wesentliche Voraussetzung ist, dass unterschiedliche Software-Varianten und Release-Stände in der Entwicklung korrekt verwaltet werden, natürlich auch dann, wenn die Fahrzeuge verkauft und auf der Straße unterwegs sind. Die Software-Entwicklung geht ja kontinuierlich weiter. Viele Hersteller halten ihre Fahrzeugflotte systematisch immer mit dem aktuellsten Softwarestand auf dem Laufenden. Kommt ein Auto in die Werkstatt, werden einfach alle Komponenten aktualisiert. Die Zukunft aber gehört Updates over the Air, die selbst zur Aktualisierung kritischer Fahrzeugfunktionen genutzt werden können.
Haben Autohersteller und Zulieferer die Stückkosten für gute Software als ernstzunehmenden Kostenfaktor bereits auf dem Schirm?
Die Bedeutung von Software, um sich am Markt zu differenzieren und über den gesamten Produktlebenszyklus neue Funktionen zur Verfügung zu stellen, haben Hersteller und Zulieferer erkannt. Dass die Car.Software-Organisation von Volkswagen unter Leitung von Christian Senger seit Anfang dieses Jahres als eigenständige Geschäftseinheit agiert, ist dafür sicher ein klarer Beweis. Trotzdem kann die Branche insgesamt noch aufholen: Die Kosten für die Entwicklung guter Software und ihre Pflege fließen noch längst nicht in gleichem Maße in die Gesamtkostenkalkulation ein wie das bei den Bauteilestückkosten der Fall ist. Natürlich werden Navigationssoftware oder eine Spracherkennung bereits als Produkte lizenziert. Aber im Vergleich zur Gesamtmenge an In-Car-Software, die heute bereits an Bord mitfährt, ist das nur ein Bruchteil.
