Software-Defined Vehicle
Gar nicht so einfach!
Die Idee eines Software-definierten Fahrzeugs hat durchaus ihre Reize, die Umsetzung ist nur deutlich schwieriger als gedacht – Cariad ist ein prominentes Beispiel dafür, wie schwierig die Umsetzung ist.
Im Jahr 2022 häuften sich die Meldungen, dass massive Software-Probleme beispielsweise beim ID.3 und Golf aufgetreten sind. Es hieß außerdem, dass der Audi Q6 e-tron und der Porsche Macan E aufgrund von Software-Problemen ein Jahr später als geplant auf den Markt gebracht werden. Im Juli 2022 veröffentlichte Volkswagen dann folgende Meldung: »Der Aufsichtsrat der Volkswagen AG hat in seiner heutigen Sitzung Oliver Blume zum neuen Vorstandsvorsitzenden des Konzerns ernannt. Er wird diese Position mit Wirkung zum 1. September 2022 in Personalunion zu seiner Tätigkeit als Vorstandsvorsitzender der Dr. Ing. h. c. F. Porsche AG übernehmen und wird diese auch nach einem möglichen IPO weiter ausüben. Herbert Diess scheidet im gegenseitigen Einvernehmen zum selben Zeitpunkt als Vorstandsvorsitzender aus.«
In der Presse wurde diese Meldung etwas provokanter formuliert. Da hieß es beispielsweise, dass Diess wegen der Probleme bei Cariad gefeuert wurde oder dass die Schwierigkeiten bei Cariad Diess das Amt an der VW-Spitze kosteten. So oder so bleibt festzuhalten: Viele sind überzeugt, dass Diess seinen Hut nehmen musste, weil Entwicklungsverzögerungen auf der Softwareseite die Marktstarts von Porsche und Audi blockierten. Durchlaufen also die Vorstellungen von einem Software-defined Vehicle einen Realitätstest und wird sich damit die Zielrichtung bei dem einen oder anderen OEM verändern?
»Software-defined« ist nicht neu
Die Idee, die hinter »Software-defined« steckt, erklärt Stefan Singer, Fellow & Senior Director bei NXP Semiconductors, mit einem Vergleich aus dem Bereich der Datenzentren. Anfänglich waren die 19-Zoll-Racks der Datenzentren mit hunderten Einzelsystemen für die verschiedenen Funktionen aufgebaut. Dann hat man sich überlegt, dass es viel schlauer wäre, wenn es ein General-Purpose-System gebe, bei dem per Software entschieden werden kann, welche Funktion es ausführen soll.
Damit sollte das Problem überwunden werden, dass Systeme mit festgelegter Funktion zwar eingebaut waren, aber nicht benötigt wurden. »Daraus ist das Software-defined Networking entstanden. Und diese Idee spielt auch beim Software-defined Vehicle mit: Ich nutze eine generische Computing-Source und kann dann entscheiden, wozu ich diese Recheneinheit nutze«, so Singer weiter. Beispielsweise wird bei 200 km/h auf der Autobahn niemand den Sitz verstellen, also kann die Rechenleistung für etwas anderes genutzt werden.
Aus der Sicht von Singer soll mit dem Software-defined Vehicle aber auch noch ein anderes Problem gelöst werden: Die Anzahl der Steuergeräte musste reduziert werden. Singer weiter: »Heute gilt die goldene Regel bei den OEMs: Beim SOP dürfen nicht mehr als 70 Prozent der Ressourcen verbraucht werden. Wenn ich für jedes einzelne Steuergerät Spielraum bei der Rechenleistung einkaufen muss, wird das Auto doppelt so teuer. Wenn ein Fahrzeug aber nur noch zehn, fünf oder nur noch drei Rechner aufweist, kann ein doppelter Headroom vorgesehen werden, das ist dann finanziell machbar.«
Es gibt keine Alternative zum Software-defined Vehicle
Auch wenn die Umsetzung des Software-definierten Fahrzeugs doch schwieriger ist, als man sich das anfänglich vorgestellt hat: Philippe Prats, Head of Automotive Marketing & Application EMEA bei STMicroelectronics, ist überzeugt, dass es dazu keine Alternative gibt. Er erklärt: »Ich glaube, dass ein OEM, wenn er überleben und profitabel bleiben will, diesen Weg gehen muss. Die Alternative, ‚nichts zu tun‘ oder ‚nicht diesen Weg zu gehen‘ gibt es nicht.« Denn mit diesem Ansatz kann der OEM dem Fahrer über die gesamte Laufzeit des Fahrzeugs hinweg immer wieder neue Funktionen anbieten und sich damit neue Umsatzwege eröffnen.
Dementsprechend ist Prats überzeugt, dass die OEMs lernen werden, das Problem in den Begriff zu bekommen. Für ihn stellt sich vielmehr die Frage, wie schnell ein OEM in der Lage ist, diese Komplexität zu meistern. Prats: »Das Auto auf vier Rädern ist das komplexeste System, das es gibt. Es geht nicht nur um Infotainment und Connectivity, sondern zum Beispiel auch um funktionale Sicherheit für ein Fahrzeug, das zehn Jahre und mehr auf der Straße fährt. Das ist für mich die höchste Komplexität, und diese Komplexität kann nur über OTA-Updates in den Griff bekommen werden. Nur so können Probleme behoben werden, und das ist notwendig. Denn wenn heute ein Auto auf den Markt gebracht wird, kann man nicht sicher sein, dass alles hundertprozentig funktioniert.«
- Gar nicht so einfach!
- Leidige Diskussionen wiederholen sich
Das könnte Sie auch interessieren
Softwaredefinierte Fahrzeuge
Neue Plattform von NXP unterstützt Entwickler
ST optimiert Elektromobilität
Mikrocontroller für softwaredefinierte…
