Hier geht es um die Kommunikationstechnik der Ladesäulen und die Frage, warum sich ggf. andere Ladenetzbetreiber damit schwerer tun als Tesla, Fahrzeuge zu identifizieren und den Ladestrom abzurechnen (aka Plug & Charge).
Die Diskussion begann im Thread „Wie weit ist Tesla der Konkurrenz voraus“ und geht ab Beitrag #33 in diesem ausgelagerten eigenen Thread weiter.
Das denke ich nicht. Natürlich ist es ein Vorteil für die Fremdfahrer, auch SuC nutzen zu können. Die Vorteile sind aber nicht so umfangreich wie für Teslafahrer. Fremdfahrer haben weder die nicht immer optimierte, dafür aber immer sichere Planung mit SuCs in ihrem Auto, noch die Bequemlichkeit (Einstecken & sonst nix tun), und vermutlich auch nicht die Zuverlässigkeit.
Denn das Unzuverlässigste an Ladestationen ist der Authentifizierungsvorgang. Der ist rock steady, wenn man einen Tesla am SuC anschließt. Aber auch als Fremdlader bei Nutzung der App? Da hat man doch mindestens schon mal das Risiko, dass die Internetverbindung sowohl des Handys als auch des Chargers in dem Moment funktionieren muss. Vermutlich ein kleineres Problem, als die meisten Konkurrenten derzeit noch haben, aber doch ein Risiko. Und wenn ich mir anschaue, wie oft mein Tesla Probleme mit der Spracherkennung hat (die ja auch über das Internet läuft), ist das auf keinen Fall ein nur theoretisches Issue.
Wie @malamut korrekt identifiziert hat, genau dieser Standardisierte Authentifizierungsprozess ist exakt das Fehleranfällige. Da wurde - ohne Not - ein IT Hochhaus auf schwankendem Grund gebaut - mit PLC (power line communication) mittels eines von mehreren konkurrierenden Standards (HomeLink), auf dem muß ein voller IPv6 Stack mit dynamischen Adressen aufbauen (und diversen Protokolloptionen, die ähnliches bieten, aber eben alle auch implementriert sein müssen um volle Kompatibiltät zu bieten - NDP, SEND, SLAAC, DHCPv6 nur mal um die eigene, „richtige“ IPv6 Adresse zu beziehen, als Beispiel. Zusätzlich machen manche Hersteller dann noch MAC Privacy (wie ein Handy), dass „einfache“ unstandardisierte Verfahren wie AutoCharge nicht mehr klappen.
Dann brauchst du einen vollen HTTPS Client (also TCP Stack, TLS Stack, Web Client und Web Server) zw. Fahrzeug und Säule. Die Säule bruacht dann oben auf dem Web Stack noch OCPP für die Authentifikation mit dem Backend - welches „beliebig“ kompliziert ist, mit Roaming zwischen Bezahlanbietern, Säulenanbietern und IT-Infrastrukturanbietern.
Und in jedem dieser Bausteine kann was nicht klappen, was zur Verweigerung der Ladung führt.
Bei SuC gibts hingegen lokales Caching, und Fail-Open (also ohne Auth wird trotzdem geladen, auch wenn das Backend grad nicht verfügbar ist; dadurch das lokal gecached wird - was IMHO andere Ladesäulen prinzipbedingt nicht machen können, da eine Challenge-Response Authentifikation zw. Säule auf Ladekartenanbieter online gemacht werden muss, während die RFID vorgehalten wird - kann da auch noch nachverrechnet werden…
Und zusätzlich kommen dann einige Anbieter der IP (intellectual Property) Rechte her (VW) und wollen Lizenzgebühren für Plug&Charge haben, dass man dieses komplexe Monster rechtlich sicher implementieren darf (ungeachtet, ob es dann funktioniert oder nicht - weil die oben genannte Kompexität der Authentifizerung geht ja nicht weg, sondern wird nochmal erhöht).
Oh, es gibt ja Standards. Für Tesla-like laden wäre das ISO 15118 (‚Plug & Charge‘). Genauso wie man es auch von den Lastmanagement-Standards kennt (OCPP, EEBUS), ist der Standard aber derart überladen, aufwendig und unklar, dass die Hersteller sich echt schwertun, das im realen Leben zu implementieren. Teuer und fehleranfällig, so wie das meiste im Ladeumfeld, das nicht von Tesla kommt. Hart aber m.W. leider immer noch wahr. Deshalb ist einstweilen alles, was tatsächlich funktioniert, proprietär. Ein Trauerspiel.
Irgendwann wird es vermutlich mal etwas vernünftiges geben, was dann auch tatsächlich breit verfügbar und nutzbar ist. Leider sehe ich es aber weder kurz- noch mittelfristig.
Spannend zu lesen was da alles dahinter steckt dass man als Kunde gar nicht wahr nimmt!
Wenn Tesla hier dran bleibt könnte es hier sogar zu einer Monopolstellung kommen oder?
Und die Gewinne die Tesla durch Fremdmarkenladungen erhält wären natürlich auch enorm wenn mehrere SC öffentlich wären!
Ähnlich komplex funktionieren auch Streaming Dienste; Onlinebanking; Smart Metering etc.
Nur nicht verwirren lassen, wenn jmd Bullshit-Bingo spielen will 
Ja, wow, das kann jedes Linux.
Wen willst Du denn mit dieser Auflistung verarschen ?
Es mag ja durchaus problematische Dinge geben, aber für wen diese dazu gehören, sollte vielleicht lieber was anderes machen.
Das Problem an der Aufzählung von @rscheff sind nicht zwei oder drei Einzelkomponenten, sondern die volle Interoperabilität des Komplettsystems mit allen Partnern und die wirklich vielfältigen Vorschriften, die in den Standards dazu dann noch gemacht werden. Die Probleme mit https etwa fangen schon an, wenn einer der Kommunikationspartner beim Zertifikat seine Hausaufgaben nicht gemacht hat. Oder ein IPv6 mit Defekten laufen hat. Um nur mal zwei besonders populäre Fälle zu nennen.
Was die Standards selbst betrifft, schau Dir alleine ISO 15118 mal an. Dieser Standard unterteilt sich in 10 Sub-Standards. Die darf man für um die 150-200 Euro pro Stück kaufen. Man darf sich vorher über ein Preview einen Eindruck davon verschaffen, was da alles drin steht. Wahnsinn. Und das alles nur, damit die Säule weiß, welches vorher registrierte Fahrzeug angeschlossen wurde. Von OCPP habe ich mal wesentliche Teile ohne Geld, nur mit einer Registrierung bekommen. Und ich muss dazu leider sagen: der ist nicht besser.
Ein guter Standard hat einfach, kurz, zielgerichtet und offen zu sein. Das ist hier leider alles nicht der Fall.
Gemäss meinem Check bietet SwitchEV die 15118-Module als Open-Source an.
Auf Github kann zwar kostenlos zugegriffen werden, jedoch vermute ich, dass die PDFs trotzdem nötig sind.
Voraussetzung für die PDF-Lieferung ist die Buchung einer Tour. Wieviel dies effektiv kostet weiss ich nicht.
Du meinst RISE-V2G? Du kannst Dich ja mal ab dem Kommentar
The RISE V2G project is no longer supported.
im dortigen Readme weiter durchklicken. Viel Spaß! Kleiner Spoiler: eine der diversen Überschriften, die dann kommen, lautet
IPv6 WARNING
So ist das nun mal. Wenn man mit der Ladesäule ins Internet will, muss man nun mal IPv6 in allen Facetten können, und wenn man Kreditkartendaten übertragen will, sollte man HTTPS können. Und wenn man da ein Auto mit aufladen will, muss man eben ISO 15118 können. Und die paar Euro für den Standard hast Du schon verballert, wenn Du das erste Auto falsch angeschlossen hast. Wir reden ja hier nicht von einem Bastelprojekt. Wobei ich der erste bin, der hurra schreit, wenn man verpflichtende Stadards grundsätzlich öffentlich machen würde. Aber für eine professionelle sind diese Summen nicht mal Peanuts.
Und gerade das Problem mit der Interoperabilität führt doch zu den ausufernden Standards. Alles, was nicht haarklein beschrieben ist, führt zu Interoperabilitätsproblemen. Mir ist ein Standard lieber, der ausufernd alles beschreibt, als einer, bei dem ich permanent Meetings mit der Zertifizierungsstelle habe, um zu eruieren, wie das denn wohl gemeint gewesen sein könnte und was die anderen wohl so gemacht haben.
Tesla hat es da einfacher, die definieren den Standard einfach so, dass der Tesla mit der Tesla Ladesäule können muss. Zertifizieren die sich auch selbst.
Wobei es natürlich in der Entwicklung unglaublich hilfreich ist, wenn man sowieso beide Enden der Leitung fertigt. Was wohl der Grund ist, dass Tesla da relativ wenig Probleme hat. Die verstehen den Ladevorgang und die Standards von beiden Seiten.
Im Ernst? Gerade wenn der Standard ausufert, hat man doch die Debatten. Über jeden Satz, der zusätzlich aufgeschrieben wird, kann man zusätzlich debattieren.
Mir ist es am liebsten, wenn der Standard sehr kurz ist und sich im übrigen ohne weiteres Gedöns auf bestehende Standards bezieht. Für eine Anwendung wie Plug & Charge würden 10 DIN A4-Seiten reichen, die man dann bitte plain vanilla unter MIT-Lizenz veröffentlicht.
Es muss ja nur die direkte Kommunikation zwischen Auto und Säule standardisiert werden. Da braucht es die Wahl des physischen Protokolls, die Liste der als vertrauenswürdig eingestuften Root-Zertifikate, die Wahl des Verschlüsselungsverfahrens und vermutlich einen Mini-Rest-Endpunkt für die Übergabe der VIN. Und dann ein Beispiel-Kommunikationsablauf. Das war’s. Keine weiteren Details bitte zu den genannten Verfahren, deren Standardisierung geschieht anderswo. Keine Details dazu, wie irgendwelche weiteren Anbieter jenseits der physischen Säule angebunden werden. Das soll der Säulenbetreiber bitteschön machen, wie er will.
Tesla hat nicht nur den Vorteil, dass bei denen alles aus einer Hand kommt. Die achten auch konsequent auf Einfachheit, sieht man ja auch an den Autos und deren Herstellungsverfahren. Und, ganz wichtig: sie akzeptieren es zugunsten der Zuverlässigkeit, wenn sie für einmal Aufladen kein Geld gesehen haben, und sperren erst die zukünftigen Aufladungen. Und auch das nur, bis die vorherige bezahlt wurde. Auf diese Weise kann das Laden selbst immer offline funktionieren. Das Auto, die Säule, das Handy oder gar alle drei sind offline? Kein Problem, es wird trotzdem geladen. Probier sowas mal bei der Konkurrenz. Selbst wenn sie wollte, könnte sie sowas gar nicht implementieren, weil die viel zu ausführlichen Standards es nicht erlauben.
Deswegen scheitert ja Cariad und VW muß nach Continental/Bosch rufen… 
Und damit Linux läuft, kann man halt keine MicroChip PIC Prozessoren um 4,5 ct/Stück verwenden - da braucht es schon sowas wie RaspPie/ARM, und jemand der Constrained Environments ordentlich konfigurieren kann - die entsprechenden Compileroptionen versteht…
Nur einen RaspPie Prozessor (ARM SoC) ist halt für die klassischen OEM Accountants unfassbar teuer - und das „nur“ für die Kommunikation für Plug&Charge (klar, etwas übertrieben - da das so im Standard steht, muß man das halt machen. Auch wenn die Kosten den Accountants die Tränen in die Augen treibt…).
Das das technisch theoretisch kein Problem ist, ist ja unbestritten. Theoretisch gibts ja auch keinen Unterschied zwischen Theorie und Praxis. In der Praxis dann jedoch leider doch… 
wozu soll man HTTPS können, wenn Ladesäulen ins Internet sollen um Kreditkartenzahlungen vorzunehmen? Sind doch keine Websites. Für sowas gibts Heutzutage SSL und Co.
Bei HTTPS wird der HTTP Datenverkehr mit SSL verschlüsselt, dann ist es HTTPS.
Sarkasmus bitte explizit als solchen markieren.
SSL ist seit rund 23 (!) Jahren veraltet, aktuell ist TLS 1.3 mit Perfect Forward Secrecy und Nicht NIST Eliptic Curves, für den RSA Teil, sowie AES256 für den symetrischen Cipher.
Und wenn man zusätzlich Kreditkartenzahlungen an einer Ladesäule machen will, nicht nur profanes OCPP via HTTPS (http/tls1.3/tcp), müssen die Vorschriften der PCI-DSS auf allen Komponenten, über die die Zahlungsinfos ablaufen, eingehalten werden…
(Hinweis: Bei öffentlichen Ladestationen scheitert es schon am profanen OCPP (http/tls/tcp) häufig genug…)
Nein, seit 23 Jahren wird TLS genommen, seit 2019 wird vom BSI eigentlich nur noch TLS1.3 als zulässig empfohlen, und seit 1-2 Jahren wurden diverse Crypto-Ciphers im Bouquet von TLS1.3 als zu unsicher ausgesondert:
Und PCI-DSS ist dann nochmal einen Häuserblock stenger
Hab ja extra geschrieben SSL und Co. Das SSL Alt ist ist bekannt. Aber ging eben darum, dass HTTP, auch wenns SSL verschlüsselt (HTTPS) Nicht für Datenübertragung im Bereich der Kreditkarten zum Einsatz kommt. Die werden nämlich ohne das HTTP Protokoll übermittelt.
Schon mal was via online shop mit kreditkarte gekauft?
Wird ganz normal via HTTPS (nur heute eben mit TLS 1.3, und dann das komplette backend nach PCI-DSS zertifiziert) gemacht; Oder, falls man einen rezenten (<3 Jahre alten) Chromium-Browser nutzt, inzwischen mittels QUIC / http3.
PCI-DSS gibt einfach nur vor, welche Minimalsicherheitslevel eingehalten werden müssen, welche Daten in Cookies oder SSDs gespeichert werden dürfen, und welche nicht…
(Das S in HTTPS steht nicht mehr für SSL, sondern für Secure. SSL sollte man aus dem Wortschatz steichen…)
Ja das ja schön für deinen Onlineshop. Wenn aber Ladesäulen Kartendaten abrechnen, dann nicht via HTTPS. Die Visualisierungen sind kein Browser.
