Irgendwas müssen die mal gehabt haben, dass ich deren App installiert hatte.. Nur was - ich erinnere mich nicht mehr.
Plugsurfing ist/war oft günstig beim AC-Laden an vielen kleinen Säulen.
DC-Laden war damit schon immer zu teuer.
Beiträge von DerEWolf
-
-
Alles anzeigen
Ich habe da mal eine Frage--- ich lese ja schon eine ganze Weile über dieses LWR Thema..
Was mir aber entgangen zu sein scheint: Ist dieser defekt nun Modelljahrabhängig, SW abhängig (3.x usw.) oder Betriebsdauerabhängig (wie lange das Auto aktiv gefahren wurde)?
Das ist mir nicht ganz klar bis jetzt.
Bisher habe ich keine Probleme bemerkt. KM stand 12.xxx km... version usw. siehe meine Datenkarte
Der Fehler kam bei mir immer nach 3-4 Monaten (bisher 2 mal Software-Reset und 2 mal Steuergerät getauscht, 45000 km in 20 Monaten).
-
fahre aus dreißiger zone, ende geschlossene ortschaft, im mäuse kino sehe ich 100 , der wagen beschleunigt aber nicht.
bei einfahrt in eine dreißiger zone, im mäusekino sehe ich 30 , der wagen bremst aber nicht.
auslesen des fehlerspeichers brachte keine lösung. sowas hat der meister noch nie gehabt
Bei mir gibt es an der B6 eine Ampelkreuzung, da warnt er regelmäßig mit "50 km/h" und einem optischen Tritt aufs Pedal im Mäusekino ... auf dem Schild steht aber 70.
Auch an einigen anderen Stellen stimmt die Anzeige nie. Die Daten kommen sicher aus einer veralteten Datenbank.
-
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 anzeigen
Nur 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.
