ICCU Defekt Statistik

[niho_de]

Auf Reddit soeben: Jemand, bei dem die ICCU seines "alten" I5 zweimal getauscht werden musste und der nun seit gut 1.000km ein MJ25 fährt... und die ICCU ist wieder kaputt. Ach, und: noch nie AC geladen.

--> https://www.reddit.com/r/Ioniq5/comment ... lly_has_a/

Ganz schön mutig!
Und hier im Forum trauen sich einige nicht einen neuen I5 zu kaufen, obwohl sie noch keinen ICCU-Defekt hatten.

[eddie1654]

Bei mir war es damals so: Auto stand schon einige Zeit an der Ladesäule und hat geladen. Kurz bevor ich dann los wollte, habe ich über Bluelink die Klimatisierung gestartet. Kurz darauf Fehlermeldung und App und der Defekt war da. Seitdem traue ich mir nicht mehr die Klimatisierung per App zu starten
Ich denke das deckt sich mit den bisherigen Erkenntnissen, dass etwaige Verbraucher die ICCU stärker belasten

1:1 identisch bei mir. Klimatisierung beim Laden gestartet und ca eine Minute danach kaputt..

[Tobiaskaminsky]

Wie Chris schon schreibt, ein einmaliges Ereignis kann es nicht sein.
Das würde jeder Entwickler sehen und testen.

Ich vermute auch, dass es um die gesamte Nutzzeit der 12v geht.
Je mehr Sitzheizung, bluelink, etc, desto früher der Ausfall.
Das würde halt sich erklären, warum es so schlecht in der Testumgebung nachszustellen ist.
Die Zeit kann man schlecht "vorspulen".

Die Frühausfälle würde ich als statisches Rauschen sehen. Montagsautos gab es schon immer.

[Danimal]

Ich nutze die Vorklimatisierung im Winter jeden Morgen, während der Fahrt auch Sitzheizung, Lenkradheizung und natürlich die Klimaanlage. Trotzdem hatte ich in bisher 3,5 Jahren und knapp 70tkm noch keinen ICCU-Ausfall. Das Ding ist einfach wackelig konstruiert und vermutlich führt eine undefinierbare Konstellation von Parametern zu den Ausfällen. Diese Konstellationen müssten in einem ordentlichen Design natürlich berücksichtigt und mit zusätzlichem Sicherheitspuffer versehen sein, was ganz offensichtlich nicht der Fall ist. Temperatur, 12V-Akku-SOC, Fahrakku-SOC, 12V-Verbraucher, Ladestrom, Software, Einschalt-/Ausschalt-Ströme... was weiß ich.
Ich kann mir auch nicht vorstellen, dass ein Team von Elektro-Ingenieuren nicht in der Lage sein soll, das Problem zu finden oder nach der Menge an Ausfällen einfach eine neue ICCU from scratch zu entwickeln. Das Thema wird ganz einfach stoisch ausgesessen, weil der Schmerz offenbar nicht groß genug ist.

[Ioniq1234]

Wie Chris schon schreibt, ein einmaliges Ereignis kann es nicht sein.
Das würde jeder Entwickler sehen und testen.

Ich vermute auch, dass es um die gesamte Nutzzeit der 12v geht.
Je mehr Sitzheizung, bluelink, etc, desto früher der Ausfall.
Das würde halt sich erklären, warum es so schlecht in der Testumgebung nachszustellen ist.
Die Zeit kann man schlecht "vorspulen".

Die Frühausfälle würde ich als statisches Rauschen sehen. Montagsautos gab es schon immer.

Naja man kann schon unter Laborbedingungen die Betriebszeit um den Faktor 10-20 ablaufen lassen, in dem man alle möglichen Belastungszustände, Ein-Ausschaltvorgänge und so weiter 24/7 ablaufen lässt. Und das nicht nur mit einem Exemplas sondern 10-20 Stück. Dann sollte man schon nach 2-3 Monaten ein Ergebnis bekommen.

[MiWi60]

Natürlich habe ich mich gefragt, wie wahrscheinlich viele andere auch, ob ein bestimmtes Verhalten den ICCU-Ausfall begünstigen kann. Zunächst liefen meine Überlegungen ins Leere, weil ich keine Veränderungen bei meiner Handhabung erkannt habe. Dann fiel mir doch etwas ein.

Wenn ich das Fahrzeug über die Wallbox geladen hatte, habe ich den Ladestecker anschließend immer entfernt. Sowohl die über Bluelink initiierte als auch die regelmäßig voreingestellte Klimatisierung vor Abfahrt fand bis dahin nie statt, solange das Ladekabel noch steckte. Am Tag des Ausfalls war das anders.

Tags zuvor habe ich das Ladekabel eingesteckt und nicht entfernt. Morgens sprang dann die regelmäßig voreingestellte Klimatisierung (mit eingestecktem Ladekabel) an. Dann trat wenige Minuten nach Abfahrt der Fehler auf.

Wäre es sehr abwegig, dass die Klimatisierung bei eingestecktem Ladekabel dann den Fehler auslöst, weil der Ladevorgang nicht durch das Entfernen des Ladekabels final beendet wurde?
Also HV-Batterie voll – Ladestecker noch angeschlossen – Klimatisierung springt an – 12V-Batterie wird belastet bzw. entleert – Nachladen wird wegen des noch angeschlossenen Ladekabels automatisch erneut gestartet und führt dabei zur Überlastung der ICCU? Passiert das ggf. auch ohne Klimatisierung beim Nachladen, wenn der Ladestecker nicht entfernt wurde?

Gruß MiWi60

[niho_de]

Wäre es sehr abwegig, dass die Klimatisierung bei eingestecktem Ladekabel dann den Fehler auslöst, weil der Ladevorgang nicht durch das Entfernen des Ladekabels final beendet wurde?
Also HV-Batterie voll – Ladestecker noch angeschlossen – Klimatisierung springt an – 12V-Batterie wird belastet bzw. entleert – Nachladen wird wegen des noch angeschlossenen Ladekabels automatisch erneut gestartet und führt dabei zur Überlastung der ICCU? Passiert das ggf. auch ohne Klimatisierung beim Nachladen, wenn der Ladestecker nicht entfernt wurde?

Gruß MiWi60

Ja, das wäre sehr abwegig, weil bei mir exakt dieses Szenario schon zigmal durchlaufen wurde und ich nach über 63.000 km immer noch mit der ersten ICCU unterwegs bin.
Ich habe bei mir noch nie das Kabel nach dem Laden abgezogen. Das mache ich immer erst vor Fahrtbeginn. Und gerade im Winter nutze ich – bei gesteckten Ladekabel – häufig die Vorklimatisierung. In meinem Openhab ist dann sehr schön zu sehen, dass kurz nach dem Start der Vorklimatisierung die Ladung wieder automatisch beginnt.
Ich erkenne es natürlich auch daran, dass dann der Stecker nicht ohne Beenden der Ladung gezogen werden kann.

Meine Theorie ist, dass die für den Fehler entscheidende Konstellation eher ein „zufälliger“ Zustand in der internen Steuerlogik der ICCU ist, der bei über 100 Tausend Schaltungen pro Sekunde nur sehr selten vorkommt.
Ich vergleiche das mit den Erfahrungen mit meinen ersten China-Billigwechselrichtern. Die sind mir reihenweise um die Ohren geflogen (zerschossene MOSFETs) völlig unabhängig von der Sonneneinstrahlung, der Temperatur und/oder der Leistungsabgabe.
Ich hatte dann schon 20er-Packs von MOSFETs zum Austauschen. Plötzlich gab es ein Software-Update und die Dinger liefen auf einmal stabil (bis heute) ohne Fehler bei unveränderter Leistung.

[chris_11]

Die ICCU Entwickler waren an ein paar Stellen beim 12V LVDC sehr mutig. z.B. haben sie den Clock Eingang des LTC3752-2 mit einem 100nF Kondensator mit dem von der (dual lock step) CPU erzeugten spread spectrum clock verbunden. So etwas ist sehr gefährlich, sobald die von der CPU erzeugten spread spectrum clock nicht beim Start des 12V LVDC zur Verfügung steht, hat der LTC3752 keine. Clock und alle Timings funktionieren nicht. So etwas macht man einfach nicht. Die eigene clock des LTC3752 kann man problemlos am Fußpunkt des RT Widerstandes mit spread spectrum einspeisen. Dann hat man immer eine clock, sobald der LTC3752 startet. Das könnte recht gut zu den beobachteten Merkwürdigkeiten passen, da man nun ganz von einem Softwaretiming abhängig ist.

[MiWi60]

Hallo niho_de,
gut zu wissen, dass ich mit meiner Spekulation falsch liege, denn zukünftig möchte ich das Ladekabel auch ständig angeschlossen lassen, weil ich mit meinem neuen Stromtarif zwischen 0 und 5 Uhr relativ günstig laden kann. Dann macht es Sinn, das Ladekabel erst vor Abfahrt zu ziehen. Bisher habe ich überwiegend tagsüber mit PV-Überschuss geladen. Aber auch da hätte ich das Ladekabel natürlich nicht ziehen müssen; hatte sich nur so eingespielt. Deine Erfahrung zeigt aber offensichtlich, dass es unschädlich ist, wenn das Fahrzeug dauerhaft angeschlossen bleibt. Unterschiedlich wären dann nur unsere Einstellungen bezüglich der Verriegelungsregeln des Ladesteckers. Bei mir war er immer verriegelt, weil ich den Diebstahl des Ladekabels an öffentlichen AC-Ladestationen verhindern wollte, wo ich mein eigenes Ladekabel einsetzen musste. Das werde ich aber auch neu überdenken, weil das so gut wie nicht mehr vorkommt.

[MiWi60]

Die ICCU Entwickler waren an ein paar Stellen beim 12V LVDC sehr mutig. z.B. haben sie den Clock Eingang des LTC3752-2 mit einem 100nF Kondensator mit dem von der (dual lock step) CPU erzeugten spread spectrum clock verbunden. So etwas ist sehr gefährlich, sobald die von der CPU erzeugten spread spectrum clock nicht beim Start des 12V LVDC zur Verfügung steht, hat der LTC3752 keine. Clock und alle Timings funktionieren nicht. So etwas macht man einfach nicht. Die eigene clock des LTC3752 kann man problemlos am Fußpunkt des RT Widerstandes mit spread spectrum einspeisen. Dann hat man immer eine clock, sobald der LTC3752 startet. Das könnte recht gut zu den beobachteten Merkwürdigkeiten passen, da man nun ganz von einem Softwaretiming abhängig ist.

ohne dass ich hier wirklich mitsprechen könnte, müsste man das Attribut „mutig“ in Anbetracht der Schäden besser „fahrlässig“ nennen. Wenn auch nur die geringste Möglichkeit bestünde, dass deshalb eine Fehlerkette ausgelöst werden könnte, sollte man das doch unbedingt vermeiden, zumal es sich so anhört, als wäre der Aufwand dafür kaum der Rede wert. Das setzt allerdings voraus, dass den Entwicklern ein solches Risiko auch bewusst wäre.