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.

Zitat von vt1816

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.

Hoffentlich langweilt es die Leser nicht ...

Das Problem ist wirklich Theorie und Praxis, ein Softwareentwickler kann relativ einfach die Requirements erfüllen und mit das mit automatisierten Tests beweisen.

Aber die Requirements/Spezifikationen sind fast nie vollständig. Bleiben wir beim Enyaq (ME 3.7) ...

Wenn ich nach Hause komme, Parkbremse ein, Fuß vom Bremspedal, sitzen bleiben. Wenn ich dann im Lademenü etwas einstellen möchte, habe ich zwei Möglichkeiten:

a) das Steckersymbol (Laden) bei den Favoriten (habe ich dahin gelegt)

b) im Menü ebenfalls das Steckersymbol "Laden".

Bei a) passiert aber nichts, ich muss zusätzlich das Bremspedal treten, damit ich auf diese Weise ins Lademenü komme.

Bei b) komme ich wie erwartet sofort in das Lademenü.

Dieses unterschiedliche Verhalten ist sicher nicht in einem Requirement so definiert worden, sondern "beim Machen so geworden".