Jan Becker im Interview: "Zulieferer geraten unter Druck"

Software-Experte Jan Becker im Interview
„Wer den richtigen Zeitpunkt verschläft, ist raus“

ArtikeldatumVeröffentlicht am 21.11.2024
Als Favorit speichern
Jan Becker
Foto: Apex.AI
Das Software Defined Vehicle ist in der Automobilindustrie gerade eines der wichtigsten Schlagworte. Was bringt das dem Autofahrer?

Für den Kunden wird das Auto zum digitalen Erlebnis. Software Defined Vehicles (SDV) sind Fahrzeuge, deren Funktionen und Eigenschaften primär durch Software gesteuert und weiterentwickelt werden können. Beim bisherigen Ansatz bleibt das Auto größtenteils auf dem Stand, mit dem man es gekauft hat. Das SDV hingegen hat den Vorteil, dass regelmäßige Updates kontinuierliche Verbesserungen ermöglichen – sei es in Bezug auf Infotainment, Sicherheit, Komfort oder Leistung. Neue Features, etwa für Assistenzsysteme oder die Fahrzeug-Personalisierung, können nachträglich installiert werden, ohne dass man Hardware-Modifikationen oder Werkstattaufenthalte braucht.

Seit wann hat die Branche das Software SDV als Entwicklungsziel erkannt?

Ein einheitliches Datum gab es hier nicht. In Deutschland ist erst in ein bis zwei Jahren mit SDVs zu rechnen. Tesla hingegen hat den Wandel zum Beispiel schon sehr früh initiiert, als sie vor rund zehn Jahren begannen, bei Zulieferern eine Trennung von Hardware und Software für das Model S zu fordern. Dort stieß man auf wenig Begeisterung. Logisch – das normale Supplier-Business besteht ja darin, die Komponente als Einheit zu verkaufen. Beispielsweise Radar-, Kamera-, Lenk- und Bremssysteme – jeweils mit integrierter Software. Dass Tesla den SDV-Ansatz dann eigenständig vorangetrieben hat, verschaffte dem Unternehmen eine Vorreiterrolle. Inzwischen erkennen aber immer mehr Hersteller das Potenzial.

Wieso ist der konventionelle Ansatz in Bezug aufs SDV überhaupt so suboptimal?

Er führt dazu, dass man als Autohersteller im Fahrzeug verteilt mehrere hundert verschiedene Komponenten verbaut – ohne Zugriff auf die jeweils implementierten Software-Funktionen zu haben. Wenn man enge Vernetzungen oder Updates für eine höherwertige Funktionalität umsetzen möchte, müsste jeder Zulieferer einzeln angesprochen werden – ein langwieriges und daher unrealistisches Szenario. Beim SDV laufen die Programme der verschiedenen Systeme in der Regel über eine zentrale Rechenarchitektur, anstatt über zahlreiche individuelle elektronische Steuergeräte. Das spart Ressourcen, und reduziert zudem die Innovationszeiten für den Rollout neuer Features von Jahren oder Jahrzehnten auf Tage, Wochen, allerhöchstens Monate. Nehmen wir zum Beispiel mal den Hundemodus von Tesla. Der hält die Innenraumtemperatur des Fahrzeugs konstant, wenn Haustiere allein im Auto bleiben, und informiert Passanten über den Bildschirm, dass die Klimaanlage aktiv ist. Derartige Features können beim SDV innerhalb von circa zwei Wochen implementiert werden. Beim konventionellen Ansatz kann so eine Änderung zwei Jahre in Anspruch nehmen.

Sollten die Hersteller ihre Software fürs SDV künftig dann komplett im eigenen Hause entwickeln, um da mitzuhalten?

Nein. Nur zum Teil. Komplette Eigenentwicklungen sind nicht zu bewältigen, die Software-Menge wäre viel zu groß und zu komplex – die Aufgabe ist für die meisten nicht lösbar. Deshalb bieten wir als Firma eine standardisierte Plattform – sozusagen ein flexibles Software-Grundgerüst – und stellen den Quellcode zur Verfügung. So erhalten die Hersteller vollen Zugriff auf die Software. Auf dieser Basis können OEM das Framework entsprechend ihren Bedürfnissen nutzen und fürs jeweilige Fahrzeug selbst anpassen. So müssen sie nicht die komplette Software selbst schreiben, behalten aber dennoch die Kontrolle und bekommen die nötige Flexibilität für die individuelle Gestaltung ihrer Modelle.

Wieso sollten OEM den übergeordneten Software-Part Firmen wie Apex.AI überlassen – warum tun sich Autohersteller da schwerer?

Für die Software-Entwicklung benötigt man dezidierte kleine Expertenteams, die mit den richtigen Leuten effizient zusammenarbeiten und von vornherein eine saubere funktionierende Architektur bauen. Silo-Denken ist fehl am Platz. Eine Extra-Software für den Antriebsstrang zu entwickeln, eine für die Assistenzsysteme, eine fürs Infotainment, eine für die Karosseriesteuerungseinheit – das macht keinen Sinn. Am Ende gibt es an den Schnittstellen Probleme, und die Systeme arbeiten gegeneinander. Einige OEM haben sich daran versucht, ihr eigenes Software-Süppchen zu kochen. Und bei manchen ist es exakt so ungünstig gelaufen wie eben beschrieben.

Klingt nach einem immensen Paradigmenwechsel, den die OEM da vor der Brust haben.

Absolut, und ich kann gar nicht genug betonen, wie groß dieser ist. Hersteller, die in Sachen SDV schon weiter sind als andere, preschen zügig auf den Markt mit neuen Features und Funktionsverbesserungen, dazu die schnelle Implementierung. Das ist eben nur möglich, wenn man die Entwicklung von Hardware und Software entkoppelt.

Warum ist diese Entkopplung denn dermaßen entscheidend?

Für ein besseres Verständnis hilft ein Blick in die Welt der Smartphones. Wenn beispielsweise Apple ein neues iPhone rausbringt, würde niemand auf die Idee kommen, die komplette Software noch einmal von Grund auf zu entwerfen. Zudem kommt mit jeder neuen Generation mehr Funktionalität hinzu. Somit würde sich der Software-Entwicklungsaufwand stetig vergrößern. Und an diesem Punkt ist die Autoindustrie jetzt angekommen – so einen Aufwand können die Hersteller nicht mehr stemmen. Bis auf wenige Ausnahmen fand der Großteil der Funktionsentwicklung bisher bei den Zulieferern statt. Hier ist die Industrie jedoch an einer Grenze angelangt, weil sich in diesem Modell schlichtweg nicht mehr Funktionalität abbilden lässt.

Müssen OEM ihre Entwicklungs- und Fertigungsprozesse also ganz neu aufstellen?

Ja. Ein SDV bündelt die unterschiedlichen Funktionen und Steuerungen schließlich auf einer leistungsstarken Recheneinheit. Man kann die Programme über eine gemeinsame Plattform verwalten und steuern. Das erfordert nur noch eine kleine Menge an leistungsfähigen Hardware-Komponenten, die von wenigen spezialisierten Zulieferern bereitgestellt werden. Dadurch reduziert sich die Anzahl der notwendigen Hardware-Zulieferer stark, und der OEM kann mit ausgewählten Partnern neue strategische Kooperationen eingehen.

Sorgen sich die großen Zulieferer entsprechend, dass Software-Unternehmen ihnen in Zukunft den Schneid abkaufen?

Die Sorge ist weit verbreitet. Etablierte Zulieferer geraten aus allen Richtungen unter Druck. Von oben kommen die OEM, die die Software-Entwicklung zunehmend selbst übernehmen. Von unten kommen Chiphersteller wie Nvidia oder Qualcomm, die sich immer weiter spezialisieren und inzwischen auch Software-Bibliotheken anbieten. Seitlich nähern sich spezialisierte Unternehmen wie wir, die in bestimmten Bereichen schneller, besser und flexibler Softwarelösungen in den Markt bringen – angepasst an die Bedürfnisse der OEMs.

Warum konnten Tesla oder auch chinesische Hersteller beim Thema SDV im Gegensatz zu anderen so ein Tempo vorlegen?

Weil deren Historie eine ganz andere ist. Diese Hersteller konnten komplett bei null anfangen und haben sich von Beginn an aufs SDV konzentriert. Konventionelle Hersteller hingegen müssen ihre Unternehmensstrukturen nach und nach anpassen. Am besten wäre natürlich ein harter Cut. Aber sich von einer über Jahrzehnte lang gelebten Legacy zu lösen, ist schwierig. Man darf den richtigen Zeitpunkt jedoch nicht verpassen, sonst ist man raus. Hierzu nochmal das Smartphone-Beispiel: Apple preschte anfangs mit dem iPhone vor. Dann gab es ein Zeitfenster, in dem sich auch Konkurrenten beweisen konnten. Einige haben es genutzt. Aber wir wissen alle, was beispielsweise aus dem einst weltweit führenden Handyhersteller Nokia geworden ist.

Vita

Jan Becker beim auto motor und sport KONGRESS 2024 mit Chefredakteurin Birgit Priemer und Multimedia-Ressortleiter Patrick Lang
Dino Eisele

Jan Becker (1970) ist CEO und Gründer der Softwarefirma Apex.AI, mit Hauptsitz im Silicon Valley. Zuvor leitete er bei Faraday Future den Bereich autonomes Fahren und bei Robert Bosch LLC das automatisierte Fahren in Nordamerika. Seit 2010 ist er Lehrbeauftragter in den Fachgebieten autonome Fahrzeuge und Fahrerassistenz an der Stanford University. Zudem war er dort Gastwissenschaftler am AI-Lab sowie Mitglied des Stanford Racing Teams.