Softwarestand - Neue Software Skoda Enyaq - Softwareversion - Release Daten System.

Da es mE. keine Ausreißer nach oben oder unten gibt (Firma A ist toll und Firma B bei gleichem Preis-/Leistungsverhältnis schlecht),

gleicht sich die Anzahl von abgehenden und hinzukommenden Kunden wohl aus.

Zitat von nitech

... wird das nie etwas mit dem SDV,

MEB-Fahrzeuge werden nie auch nur ansatzweise SDVs werden. Das gibt eine Plattform, die von der Grundidee her ein abgewandelter MQB ist, nicht her.

Zitat von DerEWolf

...

Steuergeräte am CAN-Bus erzwingen eine Struktur mit lokal agierender Software und einer einzigen schlanken Schnittstelle (der CAN-Bus).

Das hat Vorteile beim Entwickeln und Testen, und Fehler sind schneller (auf das verursachende Steuergerät) einzukreisen. Und dann dem Zulieferer Druck machen ...

Eine solche Architektur kann man mit viel Disziplin auch auf zentralen Computern haben, das hängt dann aber von den Vorlieben und der Qualität und Kompetenz der Software-Architekten ab.

Habe in meinen 40 Jahren als Software-Ingenieur oft genug erlebt, was eine monolithische Architektur anrichten kann. Wenn alles funktioniert,

kein Problem. Aber wehe, es funktioniert nicht alles richtig ... dann beginnt eine oft elende Suche nach Ursachen, Verantwortungen, Lösungen, bei der dann mehr Parteien

beteiligt sind.

Die reine Software-Entwicklung ist da nur ein relativ kleiner Anteil am Gesamtaufwand. Das sehen wir ja bei vielen Nicklichkeiten beim Enyaq, wo viele Wünsche

"mit ein paar Zeilen Code" erfüllt werden könnten ... ich erinnere nur an den OK-Button.

Alles anzeigen

Ich würde dir erstmal im wesentlichen zustimmen, wenn es immer so wäre das in einem Steuergerät nur Software von einer Firma stecken würde. Das ist aber schon eine ganze Weile nicht mehr zwingend so.

Damit man was vergleichbares wie 100 Steuergeräte die 100 Spezialaufgaben erfüllen hat, gibt es ja so öfter falsch verstandene Ideen wie Microservices, seit Ewigkeiten Virtualisierungen oder länger Container (Auch gern alles in Kombination). Zentrale Computer sind ja schon lange nicht mehr der Verursacher von Monolithen. Wobei die so schlecht gar nicht sein müssen. Lieber ein architektonisch vernünftiger Monolith mit entsprechender Testautomatisierung und vernünftigen Entwicklungs/Supportstrukturen als ein Netzwerk des Wahnsinns aus X Services die entweder viel zu kleinteilig sind oder doch halbe Monolithen nur das sich niemand ernsthaft mit deren Betrieb beschäftigt hat (Weil sind ja Services).

Gefühlt sind die Hälfte der Inbetriebnahme Probleme von heterogenen Landschaften (Nicht nur im Autoumfeld) immer noch Probleme mit fehlender/falscher/falsch verstandener Spezifikation. Viele der Sachen könnte man weit vorher klären, aber dazu müsste man dann mal entsprechende Entwicklungsmodelle oder Zusammenarbeitsmodelle nutzen - Was zugegebenermaßen über mehrere Firmen dank ANÜ manchmal nicht so trivial ist.