OFFTOPIC, aber interessant wäre es ...

Am 9.10.2026 um 10:29 schrieb borg:

Wir müssen bei vielen Autos eine CP-Trennung durchführen damit sie nach der ISO 15118-Kommunikation eine AC-Ladung starten.

könntet ihr vielleicht mal (gerne auch in einem extra Thread oder im Wiki) darstellen, was ihr bei verschiedenen Autos machen müsst und auch, ob das die Norm (ISO....) so vorgibt oder ob das schlichtweg falsch bzw. schlecht implementierte Varianten der Auto-SW sind (zumindest aus eurer Sicht)?

Habt ihr Hoffnung, dass sich dieser Zustand irgendwann auflöst? Dass keine Sonderbehandlung für einzelne Autos mehr erforderlich ist?

bearbeitet October 9, 2026 at 12:509. Okt 2026 von autolader

On 10/9/2026 at 2:49 PM, autolader said:

Dass keine Sonderbehandlung für einzelne Autos mehr erforderlich ist?

Aus Erfahrung kann ich dir als IT-ler sagen, dass das nie der Fall sein wird.
Ich verweise hierzu auf XKCD 927 :)

Am 9.10.2026 um 15:11 schrieb gameshack_:

Aus Erfahrung kann ich dir als IT-ler sagen, dass das nie der Fall sein wird.
Ich verweise hierzu auf XKCD 927 :)

ich bin auch IT'ler und ich habe Jahrzehnte in der Fahrzeugentwicklung verbracht. Ich saß in ISO-Gremien und beim DIN. Ich kenne diese Situationen. Aber es gibt tatsächlich Fälle, da hat man es geschafft ohne Sonderbehandlung auszukommen. Vielleicht nicht auf Anhieb, aber so nach und nach. Und ja, es blieben eine handvoll Varianten übrig. Aber das ist besser wie "bei vielen Autos ...".
Das geht aber nur, wenn man die Kosten für eine "andere Interpretation" in die Höhe treibt, z.B. durch eine Zertifizierung anhand einer Referenzimplementierung und -tester. Und eine Norm für das Laden von E-Autos wäre dieses Vorgehen wert. Das gilt für beide Seiten: E-Auto und Charger!

Aber dieses Thema sollten wir, wenn überhaupt, dann in extra Thread behandeln.

bearbeitet October 9, 2026 at 13:289. Okt 2026 von autolader

Das Problem ist nicht unbedingt die schlechte Implementierung in den Autos (da gibt es Probleme, aber nichts katastrophales wo wir keinen fix für finden könnten). Das Problem ist dass die Standards (IEC 61851 und ISO 15118-2) keine Lösung für die Anforderungen/Bedürfnisse von euch haben.

Was ihr gerne hättet:

• PV-Überschussladen und dafür laden unter 6A

• Plug&Charge / Autocharge

• Laden zu einem bestimmten SoC und SoC anzeigen

• Wallbox soll ohne Cloud funktionieren undLaden ohne Internetzugang möglich

Probleme bei PV-Überschussladen:

• Bei einigen Herstellern (bei den meisten sogar) ist es so dass das Auto einschläft wenn es nicht innerhalb der ersten ~10 Minuten nach dem Einstecken Strom bekommt und danach nicht wieder aufwacht (auch nicht mit CP-Trennung) -> Lösung: Eine Willkommensladung beim Einstecken, auch wenn in dem Moment kein PV-überschuss übrig ist

• Bei einigen Herstellern ist es so, dass diese (auch nach einer Willkommensladung) nicht mehr auf eine Änderung des PWMs reagieren wenn sie lange keinen Strom bekommen haben. Dafür gibt es die CP-Trennung, die greift wenn ein Auto nicht reagiert. Bei der IEC 61851 gibt es tatsächlich ein Appendix für genau diesen Fall der später hinzugefügt wurde. Dieser gibt vor dass die Wallbox den Fehlerzustand E/F erzeugen soll zum Aufwecken. Um dort alle Fahrzeugverhalten die wir kennen abzudecken machen wir vier unterschiedliche Aufweckversuche (CP-Trennung für 4s und für 30s sowie Fehlerzustand E/F für 4s und 30s). Wir machen zuerst die CP-Trennung, da der Fehlerzustand oft dazu führt dass der Nutzer vom Auto eine Notification bekommt das etwas mit der Ladestation nicht stimmt (auch wenn danach alles korrekt weiter läuft).

Problem unter 6A laden:

• Die IEC 61851 sieht das einfach nicht vor. Daher fahren wir den Hack zwischen 1-Phasig und 3-Phasig zu wechseln um geringere Leistungen zu unterstützen. Um das zu bewerkstelligen beenden wir die Ladung, Schalten die Schütze, trennen CP, verbinden CP wieder und starten eine neue Ladung. Sowas sieht der Standard nicht direkt vor, daher gibt es dort auch unterschiedlichstes Verhalten. Wir brauchen da z.B. mindestens 45s CP-Trennung bei BMWs, während bei anderen weniger reicht. Bei Polestar ist es so, dass sie nicht innerhalb der vom Standard vorgeschriebenen 3s die Ladung beenden (wenn wir das PWM auf 100% fahren). Das erkennen wir und wir erhöhen in dem Fall die CP-Trennzeit (das überschreibt dann auch die Nutzerkonfiguration), damit auch ein Polestar die Trennung wirklich mitbekommt.

Probleme bei Plug&Charge / Autocharge:

• Plug&Charge bedingt die Verwendung eines im Auto hinterlegten Zahlungsdienstleisters für eine Ladung, was für private Wallboxen zuhause kein Sinn macht

• Bei Autocharge liest man einfach die MAC-Adresse aus und nimmt diese zur Authentifizierung -> Problem: Autos in der MEB-Plattform rotieren ihre MAC-Adressen durch. Ob das standardkonform ist oder nicht lässt sich vermutlich drüber streiten, VW argumentiert dort mit Datenschutz (d.h. die wollen explizit das man ein Auto nicht identifizieren kann).

Probleme beim SoC auslesen:

• ISO 15118-2 sieht zwei komplett unterschiedliche Pfade vor, ganz am Anfang der Kommunikation wird ausgehandelt ob die Ladestation AC oder DC kann. Wenn wir dort AC wählen können wir den SoC nicht auslesen. Das sieht der Standard bei einer AC-Ladung einfach gar nicht vor.

• Also wählen wir DC, lesen den SoC und brechen die Ladung dann ab. Der Standard sieht das Beenden einer Ladung vor, allerdings unterstützen dass die meisten Hersteller nicht. Daher gehen wir dort unterschiedlichste Methoden Stück für Stück durch. Wir probieren da erst StatusCode=EVSE_Shutdown und dann ProcessingType=Finished und dann irgendwann ResponseCode=Failed und wenn das alles nicht hilft hören wir einfach auf dem Auto zu antworten, welches dann in ein Timeout läuft. Letzteres versuchen wir zu verhindern weil das oft dazu führt dass der Nutzer vom Auto eine Notification bekommt das etwas mit der Ladestation nicht stimmt (auch wenn danach alles korrekt weiter läuft).

• Nachdem die DC-Ladung dann beendet wurde starten wir eine AC-Ladung über IEC 61851. Ab der Stelle ist dann oft eine CP-Trennung notwendig damit das Auto auch darauf reagiert, das passiert dort mit dem gleichen Weckruf wie beim PV-Überschussladen.

Neuerdings gibt es die ISO 15118-20, diese löst auf dem Papier alle Probleme: Man kann über die ISO 15118-20 per AC laden und gleichzeitig den SoC auslesen und man kann dem Auto Ströme unter 6A vorgeben. Mit der ISO 15118-20:AMD1 ist sogar AC-bidirektionales Laden möglich. Sie kommt aber mit neuen Problemen.

Problem Wallbox soll ohne Cloud/Internet funktionieren:

• Bei der ISO 15118-20 ist TLS 1.3 mit "mutual authentication" vorgeschrieben. Das funktioniert indem eine verschlüsselte Verbindung aufgebaut wird und die Zertifikate gegenseitig geprüft werden.

• Damit das Auto das Zertifikat einer WARP4 prüfen kann, muss dieses von einer Instanz ausgestellt werden dem das Auto vertraut (z.B. von Hubject).

• Dafür müssen wir CPO (Charge Point Operator) werden und einige Auflagen erfüllen und unseren ISO 15118-20 Stack abnehmen lassen.

• Wenn das alles soweit erfüllt ist müssen diese Zertifikate alle drei Monate erneuert werden, was defakto bedeutet dass eine WARP4 die ISO 15118-20 sprechen möchte zumindest einmal alle drei Monate mit dem Internet verbunden sein muss...

Edit: Zur Frage ob sich das auflöst: Ich denke die ISO 15118-20 wird es langfristig tatsächlich lösen und besser/robuster machen. Allerdings werden nicht alle Autos ein Software-Update dafür bekommen und wir werden die ganzen Hacks entsprechend für eine lange Zeit noch mitführen müssen.