Wir erleben es immer wieder: Ein neues Software-Update für den ENYAQ (oder ELROQ) erscheint, aber nicht alle Fahrzeuge erhalten es. Oder es kommt nur per Werkstattbesuch, obwohl Over-the-Air (OTA) längst möglich sein sollte. Das sorgt verständlicherweise für Frust. Aber das Problem liegt oft viel tiefer als es scheint: in der Grundarchitektur unserer Fahrzeuge. Und diese ist ein Erbe der letzten Jahrzehnte.
Das Prinzip: „Was nicht zum Kerngeschäft gehört, wird ausgelagert“
In der Automobilwelt und somit auch bei Skoda galt lange die Strategie: Fokus auf Karosserie, Motor und Zusammenbau, den Rest machen Zulieferer. Große Player wie Bosch, Continental oder ZF entwickelten und lieferten die Anbauteile inklusive der Steuergeräte („ECUs“) samt Software, z. B. für Licht, Bremse, Klima oder Batterie. Der OEM (z. B. Škoda) definierte dazu ein Pflichtenheft, also was die Funktion oder das Bauteil können muss, und der Zulieferer setzte es um.
Das funktionierte, solange sich die Software kaum änderte, Updates selten waren (z. B. nur für Rückrufe) und keine OTA-Mechanismen erwartet wurden. Die Fahrzeuge nutzten eine sogenannte funktionsorientierte, verteilte Steuergerätearchitektur („distributed ECU architecture“). Jedes Steuergerät stand für eine einzelne Funktion mit eigener Software, eigener Verantwortung, oft unterschiedlicher Updatefähigkeit. Entsprechend war die E/E (Elektrik/Elektronik) – Architektur im gesamten Fahrzeug aufgebaut.
MEB: Ein modernes E-Auto mit alter Architektur
Der 2020 eingeführte modulare E-Antriebsbaukasten (MEB) brachte moderne Elektroautos wie den Škoda ENYAQ und 2025 auch den ELROQ. Doch unter der Haube blieb vieles wie zuvor. Die gesamte Architektur basierte weiterhin auf dem bekannten Prinzip: viele ECUs, viele Zulieferer, viele Schnittstellen. So hat beispielsweise mein ENYAQ RS aus 2024 sage und schreibe 79 Steuergeräte.
Warum? Weil MEB schnell marktfähig sein sollte (Stichwort: Diess-Ära) und man nutzte, was man aus dem MQB-Baukasten (Verbrenner) kannte. Das reduzierte Kosten und Entwicklungszeit, aber auch die Zukunftsfähigkeit bei Softwareupdates.
Wenn Škoda demnach heute ein umfassendes Update liefern will, etwa für ein verbessertes Batteriemanagement oder eine neue Rekuperationsstrategie, betrifft das mehr als nur das Infotainment. Es braucht:
- neue Software von mehreren Zulieferern,
- Freigaben für jede betroffene ECU,
- Kompatibilität mit allen anderen Steuergeräten,
- funktionierende Update-Prozesse (z. B. OTA-Fähigkeit),
- Tests für jede Konfiguration (inkl. Hardware-Revisionen).
Denn: Steuergeräte unterscheiden sich sogar innerhalb eines Modelljahrs. Ein anderer Zulieferer? Eine leicht geänderte Hardware? Schon braucht es ein anderes Softwarepaket, selbst wenn die sichtbare Softwareversion im Auto dieselbe ist.
Beispiel: Beim Update von SW2 auf SW3.0 beim ENYAQ iV erhielten die Allrad-Fahrzeuge den Traction Mode nicht, weil die ABS-ECU nicht updatefähig war. Ab Werk ausgelieferte ENYAQ iV mit SW3.0 hatte den Traction Mode hingegen.
Beispiel: Akutelle ENYAQ mit Matrix-LED (und SW 5.2) können SW 5.4 OTA erhalten. Fahrzeuge mit Standard-LED müssen dafür in die Werkstatt. Unterschiedliche Hardware, unterschiedliche Pfade.
Warum nicht einfach alles OTA?
Skoda würde liebend gerne alle Update over the air ausliefern. Es ist viel günstiger für sie. Denn für ein Update in der Werkstatt, dass für den Kunden kostenfrei ist, muss Skoda dennoch die Werkstatt mit einer Pauschale vergüten.
Doch ein OTA-Update setzt voraus, dass:
- das Steuergerät genug Rechenleistung und Speicher bietet,
- die Kommunikation (z. B. über das Gateway) sicher und stabil ist,
- das Update freigegeben ist (auch vom Zulieferer),
- keine ungewollten Rückwirkungen auftreten (z. B. auf Bremse, Ladeverhalten, Sicherheitssysteme).
Und das ist selten der Fall bei älteren MEB-Fahrzeugen. Viele ECUs wurden nie für OTA konzipiert – nicht einmal für regelmäßige Updates. Wenn ein Update fehlschlägt, etwa durch einen „abgestürzten Flash einer ECU“, ist das Fahrzeug nicht mehr fahrtüchtig. OTA-Updates benötigen deshalb klare Sicherheitsmechanismen, Rollback-Möglichkeiten, stabile Energieversorgung, Freigabeketten. Das kostet Zeit, Geld, Manpower und ist für ein 3 Jahre altes Steuergerät oft nicht mehr lohnenswert. Hier greift dann der zweite Faktor: Die betriebswirtschaftliche Entscheidung über ein Update.
Wohin geht die Reise? Neue Architekturen für neue Anforderungen
Wer diese Probleme lösen möchte, der muss eine komplett neue Plattform entwickeln. So wie es andere Hersteller, die neu gestartet sind und nicht das Erbe der Vergangenheit mit sich trugen, getan haben z.B. Tesla, Rivian, XPENG oder NIO.
Das macht man jedoch nicht innerhalb des Lebenszyklus einer Plattform und somit auch nicht mit einer MEB+. Man kann hier während der Evolution einer Plattform viel verbessern und von den Zulieferern einfordern, damit mehr OTA Update möglich werden. Aber den Fluch dieser Architektur mit all den Abhängigkeiten wird nicht aus der Plattform fliehen. Erst mit einem Redesign der E/E-Architektur (Elektrik/Elektronik) geschieht dies. Das ist, was SSP als Plattform bringen soll.
Damit ist die Antwort auf diese Probleme klar: Weg von der verteilten ECU-Architektur und hin zur Zonenarchitektur. Die Domänenarchitektur kann man dabei auch überspringen, wie wir sie bereits in vielen anderen Autos finden. Gemeinsam mit Rivian wird daran aktiv gearbeitet.
Domänenarchitektur:
- Steuergeräte werden nach Funktionalitätsgruppen gebündelt (z. B. Antrieb, Karosserie, Infotainment).
- Jede Domäne hat einen eigenen leistungsfähigen Controller, der mehrere Funktionen vereint.
- Reduziert Komplexität, vereinfacht Updates, ermöglicht OTA (z. B. Infotainment, Fahrassistenz).
Zonenarchitektur (State of the Art):
- Das Fahrzeug wird in geografische Zonen aufgeteilt (z. B. vorne links, hinten rechts).
- Zentrale Hochleistungsrechner übernehmen die Intelligenz, die Zonen-Controller sind eher „dumme“ Verteiler.
- Weniger ECUs, weniger Kabel, mehr OTA, mehr Flexibilität.
Ein Beispiel ist hier Rivian. Hatte ihre erste E/E-Architektur noch 17 ECU, so basieren die Modelle der jetzt aktuellen zweiten Generation auf nur noch 7 ECU (im Vergleich noch einmal die 79 ECU meines ENYAQ). Zudem sind diese so verbaut, dass man sie einfach erreicht und austauschen kann bei Bedarf (z.B. um sie aufzurüsten). Hier kannst Du mehr darüber lesen https://www.popsci.com/technology/rivian-r2-electrical-architecture
Fazit
Das heutige Update-Chaos ist nicht Folge von Faulheit oder Inkompetenz, sondern Ergebnis historisch gewachsener Strukturen. Wer heute ein Auto auf verteilten ECUs entwickelt, verbaut sich die digitale Zukunft. Und wer OTA will, muss schon bei der Hardware und Architektur ansetzen. Das wird erst eine neue Plattform liefern.
