Zum Thema Software und Steuergeräte - Komplexität am Beispiel VW

  • Hi zusammen,


    das hier habe ich bei Heise in einem Kommentar gefunden und fand es sehr interessant, da ich selbst Hard- und Software entwickelt habe, allerdings nicht in solch einer komplexen Umgebung. Zum Vergleich, der MG4 hat angeblich 50 Steuergeräte. Nur damit man sich mal eine Vorstellung machen kann, wie komplex das Thema wirklich ist und welchen Vorteil z.B. Tesla hatte, alles auf der grünen Wiese aufbauen zu können.


    Cariad: VW-Tochter stellt eigene Software-Entwicklung weitgehend ein


    Ich habe mich selbst aus anderen Gründen mit dem Thema E/E (also Elektrik & Elektronik) befasst, und dadurch den ein oder anderen Hintergrund erfahren - auch in Zusammenarbeit mit dem VW Konzern. (Die nachfolgenden Informationen sind im Übrigen frei zugänglich)


    Die Crux fing historisch an mit dem Einsatz von Steuergeräten. Was im VW Bus mit der Bosch K-Jetronic 1968 als Analogrechner für das Motormanagement begann, zog sich dann sukzessive durch die Abteilungen. Der VW Golf3 hatte "nur" 3 Steuergeräte, der Golf4 schon 45.


    Die IMHO absurdeste Komplexität kam im VW Phaeton zum Einsatz: 3 verschiedene Bus Systeme, 1 optischer Bus, verschiedene Sub Bus Systeme, 61 Steuergeräte, über 250 CAN Bus Messages, 2.500 unterschiedliche Signale, 3.8km Kabel in 2110 Zuschnitten.

    Will heissen: jede EE-Funktion/-Abteilung entwickelt ihr eigenes ECU Ensemble, bietet ein oder mehrere APIs, aber interessiert sich nicht für den Rest - und die TCU ist im Wesentlichen nur noch Bitpipe.


    Ein paar haben versucht, sich über die Zeit zu etablieren. Die frühere Nokia in Bochum wurde zur VW Infotainment, kam aber - übertrieben gesprochen - nicht über ein besseres Autoradio hinaus, sondern hat eher noch zur Komplexität beigetragen.


    Dann kam "JayJay". Johann Jungwirth. Begnadeter Denker, Visionär, mit einem 30+ Mann Team direkt unterm Vorstand. Super Ideen - ich hatte ab und an mit ihm einen interessanten Brainstorming-Austausch. Aber letztendlich: no grip in die Orga. Praktisch Null Weisungsbefugnis, Konzernstrukturen umzubauen. Heute ist er woanders, ich glaube (und wünsche es ihm) dort, wo man ihn endlich umsetzen läßt, was im VW Konzern nicht ging.


    Dann kam CARIAD. Die waren die "Bodybuilder". Statt 30 nun das hundertfache. Und mit Unterstützung des Vorstands, Teil der breiteren "NEW AUTO"-Strategie. CARIAD arbeitete an einer einheitlichen Softwareplattform, die für alle Fahrzeugmarken des Konzerns gelten soll. Diese Plattform umfasste verschiedene Technologien, einschließlich einer zentralen Cloud-Anbindung, End-to-End-Elektronikarchitekturen und neuen Mobilitätsdiensten. Die Einführung der neuen E³ 1.2-Architektur, die eine Harmonisierung von Hardware und Software ermöglicht, war hier zentrales Projekt.


    Und dann aber mit einem Problem: eine eigene legal entity. Die Experten, die seit Jahren und Jahrzehnten in den EE-Abteilungen arbeiteten, mussten nun per verordnetem Betriebsübergang in die legal entity CARIAD all ihre Konzern-Annehmlichkeiten hinter sich lassen, oder den Laden verlassen. Begrenzte Jobgarantie etc. - man kann sich leicht vorstellen, daß die meisten da sich nach hinten gelehnt haben und auf die "Bodybuilder" gewartet haben, die nun mit neuen Strategien alles besser machen würden. Oder sie haben nun vergeblich versucht, all die einzelnen "Verticals", die ganzen Sonderlocken der ECU / Zulieferer / Bus Systeme / Protokolle / ... irgendwie zu einem deutlich verbesserten Ensemble zusammenzubringen.


    Was aber die nicht hinbekommen haben, waren standardisierte Schnittstellen und Reduzierung der ECU Komplexität. Welche Fachabteilung will oder kann auf seine Experten verzichten, um statt Dutzenden von ECUs nur noch ein Dutzend Steuergeräte für alle Funktionen zu verwenden, statt sie selber zu entwickeln? (es ähnelt hier im Übrigen an den chinesischen OEM Dschungel: jeder will Automobilhersteller sein und die anderen übertrumpfen oder zum Lizensieren zu bringen - aber das ist eine andere Story).


    Was dann nämlich dahinter steht ist ein fast undurchschaubarer Dschungel an Zulieferern, deren Nachunternehmern, Nach-Nach-...Unternehmern etc. - schon bei den 61 ECUs im Phaeton kann man sich ausrechnen, daß da jeder seine eigene Welt mitbringt, neue Features ausschreibt, neue Komponenten integriert etc. - am Ende des Tages ist das SW-Paket, das in jeden Wagen im Werk eingespielt werden muss, jeden Produktionstag eine neue Permutation - und davon mal ganz abgesehen, daß dann auch noch die meisten ECUs nicht OTA-bespielt werden können, sondern nur über OBD2 bedatet werden können...


    Es gab also nur eine Möglichkeit - den radikalen Cut. Rivian hat eine ganz andere Architektur. Modernes zonal E/E + zentrale Hochleistungs-Compute-Domänen (zB ADAS/Infotainment/BMS), und damit einhergehend eine drastische Reduktion von ECUs und Kabelbaum durch wenige Zonal-ECUs, lokal angeschlossene Sensoren/Aktoren und High-Speed-Backbone (Automotive Ethernet, 100 Base T1). Damit ist das Joint Venture (JV) noch am ehesten der Dealmaker - wenn man den Radikal-Cut machen möchte. (Und eigentlich muss). Ich hab schon im letzten Jahr in einem Rivian in Kalifornien gesessen und gefahren - es fühlt sich an wie aus einem Guss.


    Jetzt kommen aber wesentliche Probleme ins Spiel:

    Rivian hat darauf abgestimmt seine eigenen Zulieferer, der VW Konzern aber ganz andere. Hier prallen 2 Welten aufeinander: Innovation trifft auf Legacy. Was kann man nun realisieren? Machen wir ein paar Annahmen.


    Annahme 1 könnte also sein: "Port & Run" – Rivian-SW (oder JV-SW) läuft nativ auf SSP-HW. Aber: eine Portierung zu anderen SoCs der Zulieferer ist aufwändig. (Und vielleicht wollen die das auch nicht - wer will schon sein Asset (SW-Entwicklung eigener Komponenten) durch eine Bitpipe, und damit quasi reduced Preis & Marge, ersetzt sehen wollen? )

    Noch eine Challenge: Safety/Cyber Anforderungen der VW-Plattform müssen erfüllt werden. Und ein Thema für die Anwälte: Lizenz-/IP-Konditionen müssen Portierung erlauben.


    Annahme 2: Man baut einen Dual-Stack, also Rivian neben SSP, und baut das mit Gateway/Adapter – beide Plattformen koexistieren, verbindende Schicht übersetzt Dienste. Also: Rivian-Zonal-ECUs / Rivian-Compute bleiben in ihren Domänen; SSP-Domänen nutzen ihre Dienste; eine standardisierte Gateway-Ebene (physisch oder virtuell) übersetzt Nachrichten, synchronisiert Zustände und regelt Authority-Handover. Hmmh. Da kommen nämlich einige Nachteile/Technik-Risiken: Latenz (wird kritisch für Safety-Funktionen/ADAS). Oder Konflikt der „Actuator Authority“: wer darf den Aktuator auslösen? Und Fingerpointing Komplexe Fehler-Propagation & Diagnostik (welches System hat den Fehler verursacht?).


    Bliebe noch Annahme 3: Standardisierung – das VW Rivian JV definiert gemeinsame Middleware & Data model. Das ist aber langfristig (und IMHO wird dann daraus binnen kürzester Zeit wieder ein Legacy System, sprich zu unflexibel).


    IMHO könnte Option2 die beste sein, erst mal, und dann letztendlich die Zulieferer dazu bringen, die Rivian-Schnittstellen bei sich einzubauen. Das dauert aber, mal von der Willingness ganz abgesehen. Und es gibt existierende Langfrist-Zulieferer-Verträge, die zwar Kündigungsklauseln drin haben, aber dann wirds a) teuer, und b) hat man nicht automatisch einen Nachfolger.


    Aus meiner Sicht gäbe es daher plausibel nur einen Weg, der uns/mir eigentlich nicht gefällt: die Rivian-Architektur wird samt deren Zulieferer aus den USA nach DE gebracht. Also entweder bauen die existierenden "EU-Zulieferer" sich ruck-zuck um auf "US-JV-Standards", oder werden schlichtweg durch US-Unternehmen ersetzt, die sich freuen werden, den Markt hierzulande zu erobern. Auf Kosten von Arbeitsplätzen, versteht sich.


    Oder es gibt einen zweiten, getrieben durch Don Trump: es wird in den USA produziert, ggf. nach DE verschifft, als Komponenten, und hier nur noch endmontiert. Zoll-Strategie "sei Dank"...


    Klar - die, die nicht bei Rivian bzw. im JV arbeiten, reiben sich jetzt hämisch die Hände. Aber das löst das Problem nicht. Man muss schon nach vorn laufen. Ein Ansatz wie damals bei Carl F. Borgward - "wir haben was, reicht doch, müssen nicht in die Zukunft investieren" - wird nicht mehr gut genug sein, dank Globalisierung und Investment chinesischer Automobilmarken auch in europ. Produktionsstätten.

    MG4 Standard, EZ 6/2025, 4500km, Produziert in China 12.9.2024