Alles anzeigen...
Die MEB Platform setzt weitgehend auf langsame CAN Busse und eine dezentrale Architektur. D.h. in den verschiedenen Steuergeräten ist sehr viel Fahrzeugintelligenz, sprich komplexe Software.
Da das Sourcing komponentenbasiert ist, wird diese Software vom Zulieferer mit der Komponente "mitgekauft". Um den Wettbewerb bei den Zulieferern und die Versorgungssicherheit zu erhalten, werden zudem Komponenten von unterschiedlichen Zulieferern für die selbe Funktion in einer Fahrzeugbaureihe verbaut.
...
Die Lösung ist eine dezentrale (elektronische) Fahrzeugarchitektur mit schnellen Bussen, z.B. Ethernet und "dummen" Controllern in den Komponenten. Die "dummen" Controller haben standardisierte Funktionen, die für große Teile der Fahrzeugvarianten gleich sind und nicht verändert werden müssen.
Es sind dann aber sehr leistungsstarke Zentralrechner erforderlich, deren Software dann vom OEM selber entwickelt werden muss.
Also eine deutliche Vertikalisierung in der Software Entwicklung und eine komplett neue Fahrzeugarchitektur.
Das ist eine sehr tiefgreifende Änderung in der Technik, aber auch in der gesamten Organisation des OEMs. Dazu kommt natürlich noch ein erheblicher Kompetenzaufbau. Denn die Kompetenz Software auf Steuergerätebene selber zu entwickeln, haben die traditionellen OEMs weitgehend in den letzten Jahrzehnten verloren.
VW hat bei diesem Übergang einen zeitlichen Nachteil von ca. 10 Jahren gegenüber Tesla und Xiaomi. Das war m.M. auch der eigentliche Grund für die Investition in Rivian. Diese Fahrzeugarchitektur beeinflusst letztlich auch die Art und Weise wie das Auto hergestellt wird. Stichwort "unboxed manufacturing" bei Tesla.
Die Frage wäre also gewesen, wann und ob, so eine Änderung bei dem VW Konzern umgesetzt sein wird. Ohne diese Änderung werden die Fahrzeuge nie substanzielle Software Updates erhalten können und das "software defined vehicle" bleibt für immer ein Wunschtraum.
Naja, einiges leider nicht ganz richtig.
Die MEB Plattform hat durchaus so tolle Wunderwerke wie interne Ethernet Kommunikation und "zentrale" Komponenten. Der Großteil aller Funktionen läuft ja über die ICAS.
Problematisch ist in den MEB eher das einige alte Steuergeräte (Ja, die braucht es trotzdem. Selbst Tesla kommt nicht ohne aus) vom MQB recycled wurden um schnell zu sein und Kosten zu sparen.
Deine Schlussfolgerung das bei einer Zentraleinheit die SW vom OEM selber entwickelt werden muss, ist nicht zutreffend.
Ebenfalls hat die Fahrzeug(Elektronik)Architektur auch so gar nichts mit der Fertigung der Fahrzeuge zu tun wie es die tollen "unboxed manufacturing" Werbevideos von Tesla beschreiben. Neue Elektronikarchitekturen ermöglichen diverse neue Prozesse wie mehr Datenhaltung im Auto während der Produktion (Buzzwörter wie digitaler Zwilling etc. spielen dann da mit rein), bessere Fehlerdiagnosen, schnellere Fehlerbehebungen, alle OEMs hoffen eigentlich auf die perfekte autonome Fahrt im Werk etc. Aber das halt alles nichts mit "unboxed manufacturing" zu tun.
Naja, mit Buzzwörtern zu hantieren ist immer schwierig. Wann ist ein SDV denn ein SDV? Reicht es dazu schon neue Funktionen nachreichen zu können, braucht es dazu eine zentrale OTA fähige Architektur für das Gesamtfahrzeug oder ist ein SDV erst dann ein SDV wenn z.B. ein Flottenmanager Zugriff von extern auf alle Funktionen hat? All das und noch einiges mehr geben die schwammigen Definitionen von SDV her. Wenn letzteres integraler Bestandteil eines SDV ist, will ich das gar nicht haben.
Alles nicht so einfach...