Meiner ist einer der letzten mit der 3.7, Autohold ist immer an. In die Garage fahre ich rückwärts bis auf wenige cm an die Wand mit leicht getretenener Bremse. Da scheint das Autohold/ Notbremsassi nicht zu greifen.
Ich meine auch eher das Rucken beim Anfahren. Fühlt sich an, als ob erst ein Widerstand überwunden werden muss, und dann springt er los ... habe ein ungutes Gefühl, wenn es auf Zentimeter ankommt.
Hast du AutoHold dauerhaft deaktiviert bei dir?
Habe die Parkbremse noch nie betätigt;)
Und dann klappt's auch mit den Favoriten
Stimmt, ich benutze Auto Hold nur bei Bedarf, ich mag das Rucken beim Rangieren nicht.
Anforderungsmanagement - Mein Lieblingsthema.
Das hat aber nichts mit Theorie und Praxis zu tun, sondern mit der Ignoranz über sinnvolles Anforderungsmanagement und der Meinung das Agilität ein AM ersetzen könnte.
... vor allem ein übergreifendes AM in Verbindung mit einem vernünftigen QM wenn man Anforderungen über mehrere Teams umsetzt.
Aber vieles würde trotzdem rechtzeitig abgefangen werden, wenn die Anforderungen denn gleich mal vernünftige Testideen und Abnahmekriterien beeinhalten würde.
Aber das ist dann ein anderes Thema.
Auch mein Lieblingsthema ... abschließend noch ein Fun Fact aus dem Konzern, bei dem ich zuletzt gearbeitet habe:
Die QS testet nicht mehr das Ergebnis, sondern überprüft nur noch, ob die Prozesse eingehalten werden. Wenn ja,
muss das Ergebnis ja zwangsläufig in Ordnung sein ...
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".
Alles anzeigenNur weil es zentrale Computer gibt, heißt das ja noch lange nicht das es keinen CAN Bus mehr gibt, keine intelligenten Steuergeräte...
Android Automotive kann wunderbar mit Containern umgehen in die wir nach wie vor Software "deployen" können, die über Schnittstellen mit dem Supervisior oder anderen Modulen kommuniziert.
Selbst die VW ICAS basieren auf virtuellen Maschinen, in die SW installiert wird die nicht ausschließlich von VW stammen muss.
Warum stellst du es dir so anders vor Libraries statt "Programmen" zu liefern? Im Endeffekt steht und fällt beides mit der Beschreibung der Kommunikationslayer und Testcases.
Ich hoffe mal nicht das es irgendwelche SW Lieferanten gibt, die interne Libraries anders handhaben als das für externe nötig ist. Die Zeiten wo "Ist intern, muss also nicht so getestet/dokumentiert werden" an der Tagesordnung waren, sind doch hoffentlich lange vorbei.
Ich wollte dieses Thema eigentlich nicht vertiefen, aber da Du eine Frage gestellt hast, gibt es natürlich auch eine Antwort.
Aus Sicht eines Programmierers hast Du Recht, auf dieser Ebene sind die Unterschiede nicht groß.
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.
Einfachere Architektur ermöglicht mehr Vielfalt, da Änderungen/Anpassungen einfacher umzusetzen sind. Wenn man von A bis Z alles kontrollieren kann, dann lässt sich auch vieles parametrieren. Das sieht bei MEB und den hundert Steuergeräten ganz anders aus.
Meiner Meinung nach ein Problem der Schnittstellen zwischen Autohersteller und Zulieferer.
Bisher hat jeder Zulieferer sein eigenes Steuergerät mitgebracht (Fenster, Licht, Entertainment, Fernbedienung, Motorsteuerung + 100 weitere).
Das konnte dann z.B. am CAN-Bus mitreden. Alt und bewährt ...
Zentrale Computer bedeuten aber auch, dass die Zulieferer ihre Software-Funktionen jetzt als Library liefern müssen,
die der Autohersteller in seine Software integriert (deployed, wie man heute so schön sagt). Und das bedeutet Schnittstellen
auf einer ganz anderen Ebene. Es wird wohl eine Weile dauern, bis alle Beteiligten ihre Prozesse dahingehend umgestellt haben,
gerade für die Zulieferer ist das eine ganz andere Weltsicht ... und bedeutet nicht zuletzt andere Qualifikationen der Mitarbeiter.
Darauf habe ich gewartet ... endlich, 10 Wochen vor Ablauf der Gewährleistung!
Gerade mal am OBD2 nachgeschaut, habe im Januar auch ein neues STG 09 mit Version 3.11 bekommen.
Gerade angeschaut und wieder verworfen: Die Daten stammen aus keiner "offiziellen" Quelle sondern kommen von GoE oder Open Street Map. Also gesammelte Community-Daten. Von dem Modell halte ich nicht viel.
Theorie und Praxis ...
War gerade mal (von Bremen aus) in Frankfurt. Abendessen in angesagter Kneipe in Sachsenhausen ... und...
die App "EVMap" hat mich erfreulicherweise zu einer Ladesäule ganz in der Nähe der Kneipe geführt, die das "offizielle" System von Skoda gar nicht kannte.
Und ich kenne keine besseren Karten (z.B. zum Geocachen) als Open Street Map.
Aber ich weiß, dass die Meinungen zu "Open ... irgendetwas" sehr weit auseinandergehen. Ich möchte mein Geld jedenfalls nicht mit
MS-Windows verdienen, da bekomme ich Magenschmerzen. Mir persönlich geht es mit Linux einfach besser ... sorry, off topic.
Wie hast du das Kabel gelegt? Durch die Heckklappe nach draußen? Vielleicht geht Skoda davon aus, dass man die "Abkürzung" durch den Innenraum nimmt?
Bei meinem war das Kabel lang genug. Und die Anzeige des Kompressors ist erstaunlich genau, habe direkt mal mit der Anzeige an der Tankstelle verglichen.
Keine Abweichung sichtbar (weniger als 0.1 Bar).
Deshalb rutscht sie immer wieder hoch/vom Sockel weg (und weil das PTFE Schmiermittel das ganze natürlich noch rutschiger macht).
Hatte ich evtl. nicht erwähnt (nur die gemessenen mm geben das her), weil es für mich so selbstverständlich war:
ich drücke den Stift natürlich vorher mit dem Daumen rein. Und hinterher auch wieder raus 
Kleiner Tipp dazu: bei Ladeende als erstes Kappe ab und den Stift wieder raus, dann ggf. mit Schlüssel und Kabel weitermachen.
In anderer Reihenfolge muss man sonst oft mit Schlüssel nochmal öffnen, sonst kommt der Stift nicht heraus
(bei mir jedenfalls, ohne KESSY).
