Plötzliche Beschleunigung im Einparkvorgang

Zitat von Sori324

Das Kraftfahrtbundesamt hat eine Stellungnahme von VW angefordert, nachdem ich nochmal mit ihnen gesprochen habe.

Auf der Seite der amerikanischen Verkehrsbehörde sind ebenso weitere Fälle hinzugekommen. Ich habe sie hier auf meiner Seite gelistet und übersetzt: Fälle aus Amerika - myid3crash

Der ADAC ist generell zurückhaltend mit Informationen, aber er arbeitet an dem Fall.

Generell bin auch hier zurückhaltend Informationen zu posten, weil hier sicher VW Mitarbeiter mitlesen oder -schreiben.

---

Alles anzeigen

Wow, nachdem ich deine Seite gelesen habe kann ich nur sagen:

Es ist sehr plausibel, dass hier Fehlfunktionen von VW vertuscht werden und das KBA wie immer dem Lobbyismus frönt.

Ich habe selbst sehr oft erlebt, wie die Fehlerkultur bei VW eher den Messenger an die Wand nagelt, als ein Problem sachlich löst oder gar einräumt.

Ich wünsche dir viel Kraft, Nerven und Geduld auf diesem Weg. Bleib dran, es braucht Menschen, die dranbleiben und für korrektes Verhalten kämpfen.

VW hat bei seinen IDs und vor allen bei den ersten Modellen gezeigt, wie wenig loyal VW seinen Kunden gegenüber ist, und dass Moral oder Anstand in dieser Firma offensichtlich gar keine Rolle mehr spielen.

Ich habe für mich die Entscheidung getroffen, in diesem Leben keinen VW mehr zu kaufen und in der Firma jegliches Fahrzeug der VW Gruppe aus der Leasingliste der Firmenfahrzeuge zu streichen.

VW fordert von seinen Zulieferern übermenschliche Anstrengungen und die kostenfreie Entwicklung von speziellen Features und tritt dann die eigenen Kunden mit Füssen, wie es sich kaum ein anderer leisten kann.

Zitat von Sori324

Das Kraftfahrtbundesamt hat eine Stellungnahme von VW angefordert, nachdem ich nochmal mit ihnen gesprochen habe

Bitte halte uns am Laufenden.

Für mich klingen deine Ausführungen plausibel und auch die gemeldeten Fälle klingen verdächtig ähnlich, aber ein Restzweifel bleibt als Außenstehender trotzdem. Sollte sich das Ganze bewahrheiten, dann wäre das für mich ein Grund den ID.3 abzustoßen, sofern es nicht zeitnah eine zuverlässige Lösung gibt.

Leider verhält sich der ID. ein winziges etwas anders als ein VW-Verbrenner mit Doppelkupplungsgrtriebe: beim Rangieren mit Verbrenner muss man nicht erst mal ganz zart das „Gaspedal“ antippen, um an’s Kriechen zu gelangen, sondern man behält den Guß immer auf dem Bremspedal. Damit fand ich mich immer im sicheren Modus.

Zitat von karl-thedeling

Leider verhält sich der ID. ein winziges etwas anders als ein VW-Verbrenner mit Doppelkupplungsgrtriebe: beim Rangieren mit Verbrenner muss man nicht erst mal ganz zart das „Gaspedal“ antippen, um an’s Kriechen zu gelangen, sondern man behält den Guß immer auf dem Bremspedal. Damit fand ich mich immer im sicheren Modus.

Auch beim ID muss man nicht erst das Gaspedal antippen, damit das Kriechen anfängt. Er kriecht sofort los. Es sei denn, du hast vielleicht Autohold aktiv oder stehst an einer Steigung.

Zitat von exifdata

Auch beim ID muss man nicht erst das Gaspedal antippen, damit das Kriechen anfängt. Er kriecht sofort los. Es sei denn, du hast vielleicht Autohold aktiv oder stehst an einer Steigung.

Zitat von karl-thedeling

---

Was möchtest du genau wissen oder sagen? Das was ich beschrieben habe (automatisches Kriechen, wenn man kein Pedal beführt und Parkbremse gelöst ist), ist sogar genauso im Handbuch erklärt.

Zitat von Sori324

Es steht dir doch vollkommen frei, das selbst bei dir einzubauen. Ich vermute aber, dass VW das direkt als Manipulation des Wagens abtun wird. Das Risiko ist mir persönlich zu hoch.

aus unserem Telefonat solltest du eigentlich wissen, dass ich dauerhaft alle meine Fahrten logge..

Der Anschluss nach meinen Vorgaben ist völlig problemfrei, der entsprechende Kabelplan (Parallelabgriff ohne Stichleitung) liegt dir vor. Die notwendigen Einstellungen am CAN-Logger (Sniff-Mode, aknowledge = off) habe ich dir ausführlich erklärt.

Jeder, der bei einem solchen CAN-Sniffen eine Manipulation nachsagen will, beweist nur seine Inkompetenz bei der Arbeit an CAN-Bussen.

Da gibt es kein Risiko, wenn nach den Vorgaben gearbeitet wird.

Ein OBD-Logger ist ein grösseres "Manipulationsrisiko", da dieser aktiv Messwerte pollen muss, damit auf CAN schreibt und das angesprochene Steuergerät in den Diagnose-Modus versetzt.

Anderesherum:

Logs aus meinem Fahrzeug waren schon Auslöser von TPIs.

In meinen Fällen war der Hersteller sehr offen für die Messdaten und Fehleranalyse.

Im Sinne der Aufklärung ist es für mich unverständlich, dass man nicht alle möglichen Register zieht. Es wirkt mir für mich ein bisschen danach, dass man keine Logs erstellen möchte, die die eigene Auffassung der Sachverhalte ggf. nicht wirklich stützt.

Ist aber mein persönliches Bauchgefühl...

Zitat von Sori324

Kannst du das mit den Redundanzen im Fahrzeug und den sich gegenseitig überwachenden Systemen mal anhand dieser Architektur erklären?

was möchtest du da erklärt bekommen?

Frondkamera für Fahrerassistenz (R242) ist redundant im Fahrzeug angeschlossen. Die notwendigen Informationen werden auf FahrerassistenzCAN und auf Ethernet zur Verfügung gestellt.

Parallel dazu ist das Steuergerät für Abstandsregelung (J428) redundant über FahrerassistenzCAN und Ethernet im Fahrzeug verfügbar.

Die Umgebungserfassung passiert also auf zwei unabhängigen Steuergeräten und wird jeweils auf zwei unabhängigen Busssystemen "doppelt-redundant" zur Verfügung gestellt.

Die Signale und Vorgaben für die Fahrstrategie sind integer und werden mit einer E2E-Protection abgesichert.

Die Auswertung findet nicht auch dem ICAS1 statt, wenn du das meinst..

Allgemein ist die E1.1 der MEB keine E3-Architektur..

Auch wenn das ICAS1 und ICAS3 im Vergleich zu den klassischen CAN-Architekturen deutlich mehr "Intelligenz" und Funktionen bekommen haben, darf man nicht von einer Zentralrechner-Architektur sprechen...

Zitat von Jochen_145

Frondkamera für Fahrerassistenz (R242) ist redundant im Fahrzeug angeschlossen. Die notwendigen Informationen werden auf FahrerassistenzCAN und auf Ethernet zur Verfügung gestellt.

Parallel dazu ist das Steuergerät für Abstandsregelung (J428) redundant über FahrerassistenzCAN und Ethernet im Fahrzeug verfügbar.

Die Umgebungserfassung passiert also auf zwei unabhängigen Steuergeräten und wird jeweils auf zwei unabhängigen Busssystemen "doppelt-redundant" zur Verfügung gestellt.

Hallo zusammen,

danke für die spannenden Details.

Redundanz hilft aber nur dann, wenn beide Systeme üblicherweise arbeiten.

Meine Werkstatt ignoriert DTCs wie
"Ethernet keine Kommunikation" bei Kamera, Bremskraftverstärkung, CAN Gateway. Es geht ja noch keine Warnlampe an.

Leider kann man dann nichtmehr von Redundanz sprechen, da jetzt ein einfacher CAN Fehler zum Totalausfall führen kann.

Korrekt geschlussfolgert?

Grüße

Felix

Zitat von fefe

Redundanz hilft aber nur dann, wenn beide Systeme üblicherweise arbeiten.

Nein..

Redundanz wird eingeführt, wenn sicherheitsrelevante Funktionen eine gewisse "Fail-Save-Funktion" gebrauchen und der Wegfall eines Kommunikationsweges oder eines Sensor-System nicht zu sofortigem Funktions-Ausfall führen darf.

Also fällt eines der beiden Systeme aus, kann mit dem zweiten System (z.T. eingeschränkt) weiter gearbeitet und eine Funktion aufrecht erhalten werden.

Zitat von fefe

Leider kann man dann nichtmehr von Redundanz sprechen, da jetzt ein einfacher CAN Fehler zum Totalausfall führen kann.

Korrekt geschlussfolgert?

ja, aber ein schlechtes Beispiel, um Redundanz zu erklären, da du ja schon im Fehlerfall unterwegs bist:

Bei einem CAN-Ausfall, wird im o.g. Fall über Ethernet die Vernetzung weiterhinn gewährleistet, bzw. in deinem Fall andersherum.

Die Rendundanz fällt dann aber weg und ein weiterer Fehler im Ethernet/CAN führt zum Totalausfall des Systems (also in deinem Fall jetzt richtig). Das ist dann aber ein Doppelfehler.

Dass die Werkstatt sich nicht um dem DTC kümmert und dein System derzeit im "Fall-back" aggiert, ist iMA indiskutabel...

Zitat von fefe

Meine Werkstatt ignoriert DTCs wie
"Ethernet keine Kommunikation" bei Kamera, Bremskraftverstärkung, CAN Gateway. Es geht ja noch keine Warnlampe an.

Diese Fehler basieren ja in 99% der Fälle auch auf Szenarien wie Hoch- oder Runterfahren von den Systemen. Wenn das länger oder während der Fahrt passiert gibt es entsprechend Warnlampen/Meldungen usw.

Das lässt sich auch aus den Fehlermeldungen schließen.

Zitat von Bjoernie

hatte ich noch keines, das wegen der Anfrage eines MWB in einen speziellen Diagnose-Modus versetzt worden wäre.

Messwertblöcke gibt es schon lange nicht mehr. Läuft jetzt fast viel über Requests/Response.

Klar, schnapp dir ODIS etc. und ruf mal 0x0003 auf und achte auf dein Fahrerdisplay. Und wenn du testen kannst, mach dann mal von 30 kmh eine Vollbremsung Da bist du dann wieder in den guten alten "Kein ABS" Zeiten mit Blockieren den Reifen.

Und ein anderer Punkt ist auch der "Mehraufwand" bzgl. Rechenleistung, wenn der OBD Dongle Daten abruft. Da werden teilweise eigene Prozeduren aufgerufen. Wenn das System jetzt auf 95% Last ist in einigen Fahrsituationen und die Diagnoseanfragen 10% aufschlagen - kannst dir ja denken was passiert.

Das wird vermutlich erneut in 99% der Fälle wohl nicht passieren - sonst würde es ja mehr Fälle geben von den bekannten Youtubern oder Hobby-Hampelmännern wie mir

Aber die Systeme werden nicht darauf ausgelegt, dass während der Fahrt eine OBD Diagnosesession läuft.

Zitat von Jochen_145

Anderesherum:

Logs aus meinem Fahrzeug waren schon Auslöser von TPIs.

In meinen Fällen war der Hersteller sehr offen für die Messdaten und Fehleranalyse.

Cool, das ist doch toll. Dann erzähl doch bitte mal, welche TPIs aufgrund deiner Logs zustande kamen und warum diese mit der normalen Diagnose nicht gefunden werden konnten.

Generell wäre es sinnvoll, wenn du die Anleitung zum Datenlogging einfach mal ins Netz stellst, dann können sich das einfach alle einbauen. Wichtig wäre dann auch eine Betreuung der Leute, die kannst du mit deinem Wissen dann am besten leisten.

Zitat von Sori324

Generell wäre es sinnvoll, wenn du die Anleitung zum Datenlogging einfach mal ins Netz stellst, dann können sich das einfach alle einbauen. Wichtig wäre dann auch eine Betreuung der Leute, die kannst du mit deinem Wissen dann am besten leisten.

Warum eine Betreuung der Leute?
Das es cool wäre, wenn er seine Anleitung ins Netz stellt, vielleicht ja sogar als Eintrag im Wiki, da gehe ich mit. Dann kann man sich das ansehen und sich überlegen, ob man sich das zutraut umzusetzen.
Das er persönlich dann irgendwen zu betreuen hätte sehe ich nicht. Er könnte, wenn er Lust hat Rückfragen beantworten. Aber das man darauf irgend einan Anspruch hätte erschließt sich mir nicht.

Zitat von Bjoernie

Aber in meinen knapp 30 Jahren und diversen Steuergeräten, hatte ich noch keines, das wegen der Anfrage eines MWB in einen speziellen Diagnose-Modus versetzt worden wäre

doch, allein schon, dass "Tester presend" (0x2 0x3E) gesendet wird, aktivert auf einem UDS Steuergerät schon einen Diagonse Modus, der dafür sorgt, dass das Steuergeräte z.B. nicht in den Bus-Sleep fallen..

Das erhöht tatsächlich die Prozesserlast, wie siduenho ja bereits beschrieben hat

Im Normalfall aber so minimal, dass es halt nicht wirklich ins Gewicht fällt. Daher habe ich ja dieses Beispiel gewählt.

Pollst du aber mit (sehr) hoher Frequenz, ist die zusätzliche Prozessorlast durch das entsprechend hochfrequente zusätzliche Senden der Responce-ID und die zusätzllichen Funktionen (z.B. CAN-Senden, DAQ-Liste auswerten, Messignale "sammeln" und clustern, etc. ) sogar messbar.

Zumal man ja kaum von "Manipulation" sprechen sollte, wenn vordeffinierte IDs zusätzlich auf dem CAN gesendet werden

Zitat von Hochvoltbatterie

Warum eine Betreuung der Leute?
Das es cool wäre, wenn er seine Anleitung ins Netz stellt, vielleicht ja sogar als Eintrag im Wiki, da gehe ich mit. Dann kann man sich das ansehen und sich überlegen, ob man sich das zutraut umzusetzen.
Das er persönlich dann irgendwen zu betreuen hätte sehe ich nicht. Er könnte, wenn er Lust hat Rückfragen beantworten. Aber das man darauf irgend einan Anspruch hätte erschließt sich mir nicht.

Du musst ja sicherstellen, dass die Leute alles richtig zusammen bauen, dass der Logger zuverlässig bei jeder Fahrt mit läuft, regelmäßig ausgelesen wird und dann wenn was ist, brauchst du wen zur Analyse. Da können überall Fehler passieren.

Ich bin auch für den Eintrag im Wiki.