An dem E-Auto führt kein Weg mehr vorbei, und damit führt auch an öffentlicher Ladeinfrastruktur gerade im Mieter*innen-Land Deutschland kein Weg mehr vorbei. Unter dem Schlagwort Smart City entsteht gleichzeitig die Idee einer digital vernetzten Stadt, in der Mobilität und damit auch Autos und ihre Ladestationen mit Live-Daten optimal eingesetzt werden können.

Doch in der Realität scheitert dies in der Fläche kläglich an der Datenverfügbarkeit, insbesondere an der Verfügbarkeit von Live-Daten. Dies ist um so tragischer, da der Ladestationsmarkt a) massiv gefördert und b) gezeichnet ist von tief in den Markt eingreifenden staatlichen Verordnungen: die Chance wäre also da, nur fehlt die Umsetzung.

Daher möchte ich in diesem Artikel darauf eingehen, wie die Ladestationswelt eigentlich funktioniert, wo welche Daten herkommen, in welchen Standards diese vorliegen und am Ende einige Vorschläge machen, wie wir das besser machen können.

In diesem Artikel wird der Fokus auf die grundlegende technische Funktionsweise und die Verfügbarkeit von (Live-)Status-Daten liegen. Weitere Themen wie Eichrecht, Kreditkartenzahlungen oder RFIDs werden kurz erwähnt, sind aber in sich noch eigene Artikel.

Viele Akteure auf dem Markt

Um zu verstehen, warum es so schwierig ist, an die Daten zu kommen, müssen wir uns zunächst anschauen, wer Ladeinfrastruktur eigentlich „macht“.

Zunächst eine kurze Erklärung der Marktrollen:

eMobility (Service) Provider (eMSP oder EMP)

Ein eMSP stellt dem Endkunden eine App bereit oder gibt dem Endkunden RFID-Karten heraus, damit dieser an Ladestationen laden kann. Er ist der einzige Akteur, der einen direkten Kontakt zum Endkunden hat. In den meisten Fällen zahlt der Endkunde einen einheitlichen Preis für alle Ladestationen. Es gibt etliche eMSPs in Deutschland. Der Markt ist neben einigen lang existierenden Marktgrößen oft unübersichtlich, da gerade bei eMSPs von Risikokapital gepushte Anbieter kurzzeitig extrem gute Konditionen anbieten, jedoch aber auch schnell aufgekauft werden oder insolvent gehen.

Chargepoint Operator (CPO)

Der CPO betreibt die Ladesäule und bietet eMSPs die Nutzung der Säule zu vom CPO definierten Konditionen an. Dies können Stadtwerke genauso wie Einzelhandel oder Vermieter sein. Während sich CPOs typischerweise selbst um die Hardware vor Ort kümmern, kaufen sie die Verwaltungssoftware als SaaS zu. Es gibt eine drei- bis vierstellige Anzahl an CPOs in Deutschland. Damit ein*e Endkund*in an einer vom CPO betriebenen Ladesäule laden kann, muss der CPO einen Vertag mit dem vom Endkunden ausgewählten eMSP haben.

Technisches Backend

Das technische Backend verbindet die Ladesäule mit dem Rest der Welt und ist typischerweise ein SaaS. Pro Ladesäule kann es immer nur ein technisches Backend geben. Das technische Backend hat oft auch eine starke organisatorische Rolle, da es innerhalb seines Backends oft viele CPOs hat und dort dann typischerweise auch die Vertragsverwaltung organisiert – es ist also nicht nur ein Verwaltungssystem, sondern oft auch ein eine Art lokales Daten- und Vertragshub.

Zentrales Datenhub

Statt dezentral Vertrags- und Datenverbindungen zwischen der Vielzahl an eMSPs und CPOs zu pflegen gibt es auf dem Markt zudem Akteure, die die Vertrags- und Datenaushandlung durch eine zentrale Plattform vereinfachen wollen. Es gibt zwei in Deutschland relevante Plattformen: eClearing und intercharge. Darüber hinaus gibt es einige technische Backends, die als Zusatzfunktion in die Richtung von Datenhubs gehen: durch die Größe der Anbieter werden die Übergänge fließend.

Navigation Service Provider (NSP)

Der NSP ist meist eine Art „eMSP light“, da er nur die (Live-)Statusdaten der CPOs einsammeln möchte. Beispiele hierfür sind Stadtnavi oder Google Maps, also Dienste, die Ladesäulen-Live-Daten als Teil der Wegekettenutzen wollen. Aber auch er muss mit jedem CPO einzeln Verträge schließen, sei es über ein Zentrales Datenhub oder sei es direkt. Dies wird teilweise auf Ebene des technischen Backends oder auf Ebene des zentralen Datenhubs gelöst, so dass Daten von vielen CPOs auf einmal freigegeben werden können.

Was passiert nun bei einem Ladevorgang?

Der folgende Ablauf stellt den Roaming-Fall dar, welches der Standard-Fall ist. Es gibt vereinzelte Anbieter von Ad Hoc Laden, also dem Laden ohne Registrierung und ohne Konto (Disclaimer: ich bin an einem beteiligt), aber diese sind heute nicht der Normalfall. Ad-Hoc-Ladedienstleister können technisch als eine Art spezialisierter eMSP eingeordnet werden: im Gegensatz zu Roaming-eMSPs geben Ad-Hoc-Ladedienstleister keine eigenen Apps oder Ladekarten aus, sondern nutzen bestehende Infrastruktur wie z.B. Girocard / Kreditkarten. Ad-Hoc-Laden wird allerdings wichtiger werden, ab Mitte 2023 ist die Unterstützung gängiger Debit- und Kreditkarten an Ladesäulen Pflicht. Aber zunächst zum Roaming:

1. Die Nutzer*in informiert sich bei einem Navigation Service Provider
2. Die Nutzer*in authentifiziert sich …
   1. … mit einer RFID-Karte. Diese wird an die Säule gehalten, welche dann das Technische Backend anfragt. Das technische Backend hat eine Liste aller RFID-Karten aller angebundener eMSPs und prüft, ob zwischen dem eMSP und dem CPO der Säule eine Vertragsbeziehung existiert und ob die RFID valide ist. Wenn ja, gibt das Technische Backend den Vorgang frei.
   2. … mit einer App des eMSP. Diese sendet dann einen Befehl an das Technische Backend, das technische Backend prüft, ob es eine Vertragsbeziehung mit dem CPO gibt und sendet dann die Ladefreigabe weiter an die Ladesäule
3. Die Nutzer*in steckt ihr Auto an und lädt.
4. Ist der Ladevorgang abgeschlossen, meldet die Ladestation alle relevanten Daten (Zeit, Energie, signierte Messdaten für das Eichrecht) an das Technische Backend.
5. Das Technische Backend sendet den Lade-Datensatz (Charge Detail Record, kurz CDR) an den eMSP.
6. Der eMSP stellt den Datensatz inkl. signierte Messdaten für das Eichrecht der Endnutzer*in zur Verfügung und berechnet die Leistung nach den vereinbarten Konditionen.
7. Der CPO berechnet den Vorgang mit den Konditionen, welche zwischen CPO und eMSP vereinbart wurden (welche andere sind als die zwischen eMSP und Endkund*in, und sie sind oft geheim).

Zwei Anmerkungen dazu:

• Durch die große Anzahl eMSPs und CPOs gibt es eine große Menge zu schließender Verträge und aufzubauender Datenverbindungen in verschiedenen Konzepten (dezentral vs. zentral) und verschiedenen Protokolle (s.u.). Es gibt zwar auf den zentralen Datenhubs die Empfehlung, Verträge automatisch anzunehmen, da es aber zwei große Datenhubs in Deutschland sowie den dezentralen Ansatz gibt ist eine Vertragsbeziehung nicht automatisch gegeben. Dies gilt auch für die NSPs und damit die Infrastrukturdaten: dort ist der Weg zur Freigabe zwar meistens leichter, aber selten automatisch, und man muss in jedem Fall mit jedem technischen Backend und den großen Datenhubs verhandeln.
• Die Konditionen von CPO an eMSP sind unabhängig von den Konditionen von eMSP an Endkund*in. Die CPOs sind sehr frei in der Preisgestaltung, und es gibt auch weniger Druck von Endkund*innen, weil diese keine Vertragsbeziehung mit dem CPO haben. Das kann dazu führen, dass der eMSP mehr an den CPO abführen muss als er von dem*r Endkund*in wieder einnimmt. Dies führt zeitweise dazu, dass eMSPs aktiv auf eine Bereitstellung von Säulen bestimmter CPOs verzichten, ein prominentes Beispiel hierfür ist die Ionity Schnellladeinfrastruktur.

Ein weiterer Kostentreiber für CPOs sind die verschiedenen Protokolle, welche im nächsten Kapitel behandelt werden:

Der Ladesäulen-Protokoll-Dschungel

Im Folgenden sollen die im europäischen Umfeld wichtigsten Protokolle vorgestellt werden. Open ist hier übrigens weder im Sinne freier Lizenzen noch im Sinne offener Daten zu verstehen: die ersten drei Protokolle haben gar keine freie Dokumentationslizenz, und OICP steht zwar unter CC BY-SA, funktioniert aber nur mit einer einzigen zentralisierten Plattform.

Die Protokolle sind recht verschiedenartig:

• OCPP beschreibt die Kommunikation zwischen Ladepunkt und CPO
• OCPI, OCHP und OICP beschreibt die Kommunikation zwischen CPO und eMSP inkl. Status-Daten, Remote-Kommandos und ChargeDetailRecords (CDRs, also Ladedatensätze, die der eMSP dann gegenüber dem*r Endkunden*in abrechnet)
• DATEX II und die Bundesnetzagentur-Daten beschreiben nur die vom CPO bereitgestellten statischen Daten der Ladestationen ohne Remote-Starts.

Interessant ist im Übrigen auch die Herkunft der Protokolle: OCPP und OCPI sind niederländisch, OCHP stark niederländisch orientiert. Nur falls sich jemand Fragen stellen möchte, was mit den in eMobility gesteckten Fördergeldern passiert ist: offene gut nutzbare Standards offensichtlich nicht.

Open Charge Point Protocol (OCPP)

Dieses Protokoll beschreibt die Verbindung zwischen Ladepunkt und technischem Backend. In aktuellen Versionen (2.0 und das extrem weit verbreitete 1.6) handelt es sich um eine Websocket-Verbindung mit JSON-basierten Nachrichten, in frühen Versionen um ein aus normalen http-Requests bestehendes XML-basiertes Protokoll. OCPP ist auf dem europäischen Markt weitestgehend konkurrenzlos. Es erlaubt mit einem generischen DataTransfer individuelle Erweiterungen, was in Normen genauso genutzt wird wie z.B. bei individuellen Erweiterungen wie z.B. Girocard- und Kreditkartenzahlung. OCPP spielt in dieser Liste eine Sonderrolle, weil darüber gar keine Statusdaten gegenüber Dritten abgebildet werden können, es gehört zur vollständigen Betrachtung von Ladesäulen-Protokollen aber dazu.

Open Charge Point Interface (OCPI)

Das Protokoll OCPI stellt einen dezentralen Ansatz der Kommunikation zwischen CPO und eMSP bereit. Es basiert auf JSON-Requests zwischen zwei öffentlich erreichbaren Servern und realisiert so den Austausch von Informationen und Aktionen mit einem Push- und Pull-Modell. In der aktuellen Version 2.2 werden auch Hubs, also Datenaggregatoren und Datenweiterleitungen unterstützt, die Version ist aber noch nicht sehr verbreitet. Ebenso werden in 2.2 signierte Datensätze unterstützt, was die Bedingung für einen eichrechtlich sauberen Betrieb ist.

Das Protokoll ist recht komplex, und gleichzeitig fehlen auch gerade im Pricing einige Aspekte: Die Abrechnung zwischen eMSP und CPO ist nicht Teil des Protokolls, es werden jedoch Preise zwischen CPO und eMSP umgesetzt, während Endkunden-Preise nur durch individuelle Erweiterungen umsetzbar sind. Es können auch andere individuelle Erweiterungen wie z.B. Girocard- oder Kreditkarten-Zahlungen umgesetzt werden.

Open Clearing House Protocol (OCHP)

Das Protokoll OCHP beschreibt die Kommunikation zwischen CPO und eMSP und vermischt einen zentralen Ansatz für die Vertragsabschlüsse, aggregierte Ladepunktdaten und Ladevorgangs-Datensätzen (CDRs) mit einem dezentralen Ansatz für einige Funktionen wie Remote-Steuerung von Ladepunkten. Es wird von der Plattform eClearing eingesetzt. In der Version bis 1.4 handelte es sich um ein XML-basiertes Protokoll, bei der neuen noch nicht besonders verbreiteten 1.5 um ein JSON-basiertes Protokoll.

Open InterCharge Protocol (OICP)

Das JSON-basierte Protokoll OICP beschreibt die Kommunikation mit der Intercharge-Plattform von Hubject, welche die Kommunikation zwischen eMSP und CPO zentral vereinheitlicht. Intercharge übernimmt dabei wie bei OCHP eClearing auch die Rolle des Vertragsvermittlers und zentralen Informationsaggregation, darüber hinaus werden aber auch alle anderen Funktionen wie Remote-Starts individuell abgewickelt.

DATEX II

Das XML-basierte Protokoll DATEX2 ist kein Ladesäulen-spezifisches Protokoll, sondern ein recht generisch gehaltener XML-Container, welcher als EU-weites Austauschformat in einigen Bereichen eingesetzt wird. Es gibt Überlegungen, DATEX2 auch für Ladesäulen einzusetzen und dafür ein XML-Modell zu definieren, allerdings wird DATEX2 lediglich Informationen über Ladestationen enthalten können.

Durch die Vielzahl der Datenstruktur-Variationen innerhalb von DATEX2, die zum Teil aus heutiger Sicht absurden Datenstrukturen (z.B. ALERT-C mit der unfreien Location Code List LCL) und die fehlende Optimierung auf E-Mobilitäts-Usecases wie der schnellen Aktualisierung der E-Mobilitäts-spezifischen Datenstrukturen (z.B. fehlendes Patching von Subobjekten) ist der DATEX2 für Ladesäulen-Daten aus meiner Sicht unbrauchbar. Nicht desto trotz gibt es Bemühungen, DATEX2 für Ladesäulen zu etablieren.

Daten der Bundesnetzagentur (BNetzA)

Ladesäulen-Betreiber sind nach der Ladesäulenverordnung verpflichtet, öffentliche Ladesäulen der Bundesnetzagentur zu melden. Diese veröffentlicht diese Daten als XLSX unter einer freien Lizenz und könnten als eine Art statische Basis-Daten fungieren – aber leider sind die Daten aus zwei Gründen schwer nutzbar:

• Der zentrale Identifier für öffentliche Ladestationen, die Electric Vehicle Supply Equipment ID, kurz EVSEID, fehlt in dem BNetzA-Datensatz. Damit können die Daten nicht mit anderen Datenquellen verschnitten werden.
• Die Public Keys sind in vielen Fällen fehlerhaft oder unvollständig, so dass eine Validierung von Lade-Datensätzen zu einem Glücksspiel wird.

Außerdem fehlen natürlich Live-Daten: es ist eben doch nur eine Excel-Liste. Die Daten der BNetzA werden auf dem offiziellen Ladesäulen-Planungs-Tool des Bundes verwendet, mit dem auch Förderquoten bestimmt werden: Regionen mit wenig Ladeinfrastruktur haben in der Vergangenheit höhere Förderungen bekommen.

Daten des Bundesverbandes der Energie- und Wasserwirtschaft e.V. (BDEW)

Da Energie Codes und Services GmbH als Tochter der BDEW die für öffentliche Ladeinfrastruktur verpflichtende Electric Vehicle Supply Equipment ID, kurz EVSE oder EVSEID, vergibt, hat die BDEW auch eine Datenbank für Ladesäulen entwickelt. Leider stehen die Daten nicht über eine öffentliche Schnittstelle zur Verfügung, ebensowenig wie das Datenmodell öffentlich dokumentiert ist.

Die EVSEs sind die zentralen IDs von Ladepunkten und sind kostenpflichtig und verpflichtend, und man bekommt einen zweistelligen Landes- und einen dreistelligen Organisations-Prefix für seine Säulen, z.B. DE GLS oder DE SNH. Kleine Betreiber schließen sich dabei oft großen Betreibern mit ihren Prefixen an, so dass die Organisationskennung eher eine grobe Herkunft darstellt.

Individual-Protokolle

Über die Standard-Protokolle hinaus gibt es eine Vielzahl an individuellen proprietären Protokollen – teils historisch gewachsen, teils weil die großen Protokolle bestimmte Features (noch) nicht konnten (Eichrecht, end2end-Kryptografie, …). Da keine dieser Protokolle einen Vollständigkeits-Anspruch hat und sie nicht öffentlich dokumentiert sind können diese hier nicht weiter betrachtet werden.

Protokoll: Feature-Übersicht

In Folge werden die verschiedenen Protokolle und Datenquellen nach Features ausgewertet. Hierbei liegt der Fokus auf Datenzugriff von außen, so dass OCPP nicht betrachtet wird: OCPP ist ein rein internes Protokoll zwischen Ladesäule und technischem Backend und erlaubt daher keinen Zugriff auf Infrastrukturdaten.

Feature	OCPI	OCHP	OICP	DATEX II	BNetzA	BDEW
Statische Daten	✔	✔	✔	✔	✔	✔
Inkrementelle Daten-Updates	✔	✔	✔	?	X	X
Dynamische Status-Daten	✔	✔	✔	?	X	X
Roaming-Endkunden-Preise	X	X	X	X	X	X
Ad-Hoc-Endkunden-Preise	✔	X	?	X	X	X
CPO-eMSP-Relationen: „kann ich als Kunde von eMSP X bei CPO Y laden“	X	X	?	X	X	X
RFID-Karten-Autorisierung	✔	✔	✔	X	X	X
Remote-Start via App	✔	✔	✔	X	X	X
Public Keys für Verifizierung	✔ ab 2.2	✔ ab 1.5	✔ ab 2.3	?	✔	X
Signierte Datensätze für Eichrecht	✔ ab 2.2	✔ ab 1.5	✔ ab 2.3	X	X	X
Erweiterungsfähig	✔	X	X	?	X	X
Öffentliche Dokumentation	✔	✔	✔	?	✔	X
Freie Dokumentations-Lizenz	X	X	✔	?	X	X
Dezentraler Einsatz möglich	✔	X	X	?	X	X

Wo kann ich laden und was kostet es?

Denkt man aus Sicht der Nutzer*innen, dann sollten all diese technischen Details nicht interessieren. Als Nutzer*in möchte man einfach nur wissen, wohin man fahren kann, um zu laden, und ein Preis wäre ebenfalls wichtig zu wissen, und es sollte sicher sein. Der letzte Aspekt ist einen eigenen Blogpost wert, denn sichere Ladekarten werden bis heute nicht großflächig eingesetzt, und die eichrechtlichen Aspekte sind quasi unbedienbar. Aber auch der Weg und Zugang zum Laden ist ausgesprochend kompliziert, und die Lösung dort können nur offene Daten in offenen Standards auf einer staatlichen Plattform sein. Möglich ist das: der Kraftstoffmarkt hat es in Form der MTS-K vorgemacht.

Was zu tun ist

Ladesäulen sind Teil der öffentlichen Verkehrsinfrastruktur der Zukunft. Dies bedeutet nicht nur Infrastruktur im Sinne von Beton und Metall, sondern auch digitale Infrastruktur: Ladesäulen funktionieren nur digital. Dies betrifft nicht nur das reine Starten eines Ladevorgangs, sondern darüber hinaus auch jegliche Integrationen in weitere Systeme. Smarte Energienetze zur Integration eines hohen Anteils regenerativer Energien und smarte Städte können nur dann umgesetzt werden, wenn Infrastruktur-Daten verfügbar sind und nicht willkürlich hinter Barrieren versteckt werden.

Offene Standards

Zunächst braucht es einen wirklich offenen Standard, der möglichst nah an existierenden Daten ist und die großen Datenmengen inkl. inkrementeller Updates gut abbilden kann. Die bestehenden Standards bieten eine gute Diskussionsgrundlage, aber wie der von mir geleitete Standardisierungsprozess von OParl gezeigt hat wird ein Datenstandard nur dann wirklich gut nutzbar, wenn er mit realen Daten getestet wird. Im Gegensatz zu OParl ist die reine Informationsweitergabe kein Mammutsprojekt, es handelt sich im Kern um drei Hauptdatenobjekte (Location mit 1:n EVSEs und den dazugehörigen Preisen), so dass dies in einem gut vorbereiteten Workshop gut machbar wäre. Dies könnte ein erster großer Aufschlag für das von der neuen Bundesregierung geplante OpenData-Engagement sein.

Insbesondere sollte bei dem Standard aber auch auf Vollständigkeit geachtet werden. Sinnvoll für eine verbraucher*innenfreundliche automatische Validierung von Ladevorgängen vor der Abrechnung wäre beispielsweise der Public Key der Säule. Ebenso sollte ein Rückmeldekanal für Datenfehler definiert werden, da die Datenbanken der Betreiber oft Fehler enthalten. Und natürlich sollte eine der größten Transparenz-Probleme der Ladeinfrastruktur abgedeckt werden: neben Ad-Hoc-Preisen für Endkund*innen sollten auch Preise von eMSPs angegeben werden – inkl. der überhaupt zur Verfügung stehenden Säulen, denn auch das ist ein Problem: man kann nicht mit jedem eMSP überall laden, und welche Konstellation zu welchem Preis funktioniert ist bislang eine ausgesprochen mühsame Aufgabe.

Freie Lizenz

Um Daten dann vielfältig weiterzuverwenden und Teil von digitaler Infrastruktur zu werden müssen die Daten als CC0 freigegeben werden. Es handelt sich bei den Daten um Daten ohne Schöpfungshöhe: dass an Säule X ein Typ2-Stecker bereitsteht, 22 kW geboten werden und die Säule gerade belegt ist ist einfach ein Faktum, und eine Datenbank aus Fakten sollten als frei verfügbare digitale Infrastruktur betrachtet werden.

Zudem löst CC0 elegant das Problem, dass es in der Vergangenheit vielfach Streit um die Urheberschaft gab. Denn: wer ist denn eigentlich „Urheber“ der Daten? Der technische Betreiber, wo die Datenbank liegt? Der Besitzer der Ladesäule? Die Stadtwerke, die als Vertragspartner für beide agieren? Man kann keine Smart City mit intelligenten Energienetzen bauen, wenn jedes noch so triviale Informationsfragment trotz fehlender Schöpfungshöhe als urheberrechtlich schützbar angesehen wird und jede smarte Komponente Urheberrechts-Diskussionen auslöst, also ist CC0 die einzig sinnvolle Option.

Offene Plattform

Um Daten nicht von den vielen vielen Hundert (oder Tausend) Betreibern einzusammeln sollte der Bund eine Plattform anbieten, welche genau diese Aufgabe des Aggregators bereitstellt. Der aktuell für eine derartige Plattform diskutierte Mobilitätsdatenmarktplatz MDM ist grundsätzlich eine gute Idee, jedoch müsste sich der MDM an mehreren Stellen modernisieren, um die Aufgabe gut auszufüllen. Folgende Punkte müssten erfüllt werden:

• die Daten müssten in einem freien Standard unter CC0-Lizenz bereitgestellt werden
• die Daten müssten auch ohne Login verfügbar gemacht werden
• der MDM müsste für die CPOs eine moderne REST-API mit PATCH-Funktion anbieten
• es muss eine standardisierte Rückmeldefunktion für Fehler in den Daten geben. Daran krankt der aktuelle MDM (und viele andere Datenplattformen) besonders, wie man beispielsweise an den reihenweise invaliden Park-Daten sieht.

Die Umsetzung wäre die Chance für die neue Bundesregierung zu zeigen, dass sie OpenData ernst meint und endlich offene digitale Infrastruktur schaffen möchte. Außerdem sollte eine solche Plattform den Verwaltungsoverhead für Einrichtung und Betrieb der Daten deutlich reduzieren und so den Betrieb von Ladeinfrastruktur günstiger machen: statt dass man als CPO manuell Daten an Bundesnetzagentur und BDEW melden muss wäre es viel effizienter, wenn ein automatisierter Datenabgleich zum MDM möglich wäre, welche dann als Datenquelle auch für die Verwaltung selbst dient.

Für das Stadtnavi und andere OpenTripPlanner-Instanzen haben wir mit einem Community-Projekt die Aufgabe bereits weitestgehend umgesetzt: unter dem Namen OpenChargePointDatabase (OCPDB) aggregieren wir möglichst viele Daten von verschiedenen Anbietern und stellen sie als in beliebige Kartenanwendungen integrierbaren Vector-Tile-Layer auf api.ocpdb.de bereit. Das Projekt ist OpenSource, und die gemachten Erfahrungen steuern wir gerne ebenso bei wie den Code.

Pflicht

Leider hat der Markt die Freigabe von für die digitale Stadt wichtigen Infrastrukturinformationen nicht selbst regeln können, so dass es aus meiner Sicht nur einen einzigen Weg gibt: die Pflicht zur Veröffentlichung. Es ist ein geradezu absurder Zustand, dass Ladeinfrastruktur zwar massiv öffentlich gefördert wird, ebenso wie die Betreiber oft öffentliche Unternehmen sind – aber die Infrastrukturdaten trotz des öffentlichen Geldes nicht öffentlich verfügbar sind. Das muss sich ändern.

Abschluss & Ergänzungen

Habt Ihr noch weiterführende Informationen, Anmerkungen oder Ergänzungen? Ich freue mich auf Eure Kommentare!

Lasst uns Ladeinfrastruktur besser und offener machen! Dies soll nicht der letzte Artikel sein, denn es gibt noch viel zu dokumentieren: zu (un)sicheren RFID-Karten, zu Eichrecht, zu Plug’n’Charge, zu … und alles davon ist digital.