Es gibt kaum ein schlimmeres Gefühl, als zuzusehen, wie Ihr Dashboard einen Netzwerkzustand von 100 % anzeigt, während Ihre Kundendienst-Hotline mit hilflosen Fahrern überlastet ist. Sie haben für eine „Plug-and-Play“-Zukunft bezahlt, sitzen aber stattdessen um Mitternacht da und müssen JSON-Protokolle durchforsten.

Man hat Ihnen versprochen, dass der OCPP-Standard dieses Problem beheben würde. Doch Probleme bei der Interoperabilität von Ladestandards für Elektrofahrzeuge lassen sich selten mit einem Aufkleber mit der Aufschrift„Wir sind konform!“ lösen.

Dieser Leitfaden geht über die Marketingbroschüren hinaus und beleuchtet die technischen Aspekte der Implementierung einer OCPP-Plattform:‍

• Der Compliance-Mythos: Warum „OCPP-zertifizierte“ Hardware immer noch nicht mit „OCPP-konformer“ Software kommunizieren kann.
• Das Dialekt-Dilemma: Wie subtile Abweichungen bei der JSON-Kommunikation zu unbemerkten Netzwerkausfällen führen.‍
• Die Versionsfalle: Warum ein Umstieg auf OCPP 2.0.1 Ihr EV-Ladenetzwerk tatsächlich auf den „kleinsten gemeinsamen Nenner“ herabstufen könnte.‍
• Kampfspuren: Fallstudien aus der Praxis zu „Ghost Sessions“, durchgebrannten Sicherungen und dem gefürchteten „Brick“ der Firmware.‍
• Die Beschaffungsprüfung: Die vier „Warnsignal“-Fragen, die Sie Anbietern stellen sollten, bevor Sie einen Fünfjahresvertrag unterzeichnen.

1. Wie OCPP eigentlich funktioniert (und warum es zu Fehlern kommt)

Um den Fehler zu verstehen, muss man das Tool verstehen. Was ist OCPP?

Das Open Charge Point Protocol ist der weltweite Standard, der es Elektroautoladegeräten (Hardware) ermöglicht, mit dem Backend einer Ladestation (Software) zu kommunizieren. Es wurde von der Open Charge Alliance entwickelt, um Interoperabilität zu gewährleisten und sicherzustellen, dass Sie nicht an einen bestimmten Hardwarehersteller gebunden sind.

Aber hier ist der Haken: OCPP ist kein universeller USB-Anschluss, sondern eine Sprache mit verschiedenen Dialekten.

„OCPP-konform“ bedeutet lediglich, dass dein Ladegerät und deine Software dieselbe Sprache sprechen. Das garantiert jedoch nicht, dass sie sich auch verstehen. So wie ein Texaner und ein Glasgower zwar beide Englisch sprechen, es aber alles andere als einfach ist, sie dazu zu bringen, einander zu verstehen.

Wenn Ihre teure neue Hardware „OCPP 1.6 Dialect A“ unterstützt und Ihr CPMS „Dialect B“ erwartet, bricht Ihr Netzwerk nicht einfach zusammen – es bricht stillschweigend zusammen.

Die technische Realität von OCPP

Auf technischer Ebene kommunizieren moderne OCPP-Server-Implementierungen (insbesondere OCPP 1.6J und 2.0.1) über WebSockets. Dies ermöglicht eine dauerhafte, bidirektionale Verbindung zwischen der Ladestation und der Cloud. Die Kommunikation umfasst drei Hauptschritte:

1. Der Handshake: Das OCPP-konforme Ladegerät stellt eine Verbindung zur Backend-URL her.
2. Der Herzschlag: Das Ladegerät sendet alle X Sekunden einen Impuls, um zu signalisieren: „Ich lebe.“
3. Der Vorgang: Das Ladegerät übermittelt Daten zum Start, zum Ende und zu den Zählerständen einer Ladesitzung.

Nachdem wir nun über dieses praktische Wissen zur Implementierung des OCPP-Protokolls verfügen, wollen wir uns damit befassen, wie unterschiedliche Dialekte zu konkreten Herausforderungen bei der Software für OCPP-Ladestationen führen.

‍

‍

2. Das „Dialekt“-Dilemma

Der größte Irrglaube hinsichtlich der OCPP-Konformitätsanforderungen für EV-Ladestationen ist, dass der Standard starr sei. Das ist er nicht. Die OCPP-Spezifikation ist „flexibel“.

Das Protokoll legt zwar fest, wie eine Nachricht aussieht, lässt jedoch Spielraum für Interpretationen hinsichtlich des Zeitpunkts und des Grundes für deren Versand.

• Hersteller A sendet möglicherweise unmittelbar nach dem Anschließen eine Statusbenachrichtigung.
• Hersteller B könnte abwarten, bis die Genehmigung erteilt ist.

Beide sind technisch gesehen „konform“. Wenn das Backend Ihrer Ladestation jedoch erwartet, dass die Benachrichtigung in Schritt eins eine Änderung der Benutzeroberfläche in Ihrer App auslöst, werden die Ladegeräte von Hersteller B für Ihre Kunden als defekt erscheinen.

Sie kaufen nicht nur Software; oft erwerben Sie damit auch ein kostspieliges Integrationsprojekt, um diese Hardware-Dialekte zu übersetzen.

Die mangelnde OCPP-Konformität wird noch deutlicher, wenn man sich die verschiedenen OCPP-Versionen ansieht, die derzeit von den Anbietern unterstützt werden.

3. Der Versionsstreit: OCPP 1.6 vs. 2.0.1

Wenn man sich die aktuellen OCPP-Nachrichten ansieht, scheint die Branche geradezu besessen von der Umstellung auf 2.0.1 zu sein. Für einen Ladestationsbetreiber (CPO) ist diese Umstellung jedoch ein Minenfeld. Um zu verstehen, wo die Umstellung scheitert, wollen wir uns die praktischen Unterschiede zwischen OCPP 1.6 und 2.0.1 genauer ansehen.

Was ist OCPP 1.6?

OCPP 1.6 (JSON) ist derzeit das Standardprotokoll der Branche. Es wird breit unterstützt, hat sich in der Praxis bewährt und ist stabil. Und das aus gutem Grund: Das Protokoll bewältigt die Grundlagen des Lademanagements für Elektrofahrzeuge zuverlässig und in großem Maßstab.

Allerdings wurde es für eine Zeit konzipiert, in der die Ladeinfrastruktur noch einfacher war.

In der Standardausführung verfügt OCPP 1.6 nicht über native Sicherheitsfunktionen, sodass in der Regel VPNs oder zusätzliche TLS-Ebenen erforderlich sind, um moderne Netzwerkstandards zu erfüllen. Zudem bietet es nur begrenzte Unterstützung für komplexe Tarifstrukturen – ein Aspekt, der angesichts immer ausgefeilterer Preismodelle zunehmend an Bedeutung gewinnt.

Was ist mit „Plug & Charge“ nach ISO 15118?

„Plug & Charge“ ist zwar nicht Teil der Kernspezifikation von OCPP 1.6, lässt sich aber bereits heute realisieren. Die Open Charge Alliance hat einen offiziellen Anwendungshinweis veröffentlicht, in dem detailliert beschrieben wird, wie diese Funktion über den in das Protokoll integrierten „DataTransfer“-Mechanismus implementiert werden kann. Das bedeutet, dass Betreiber nicht auf ein vollständiges Plattform-Upgrade warten müssen, um diese Funktion nutzen zu können.

Was ist OCPP 2.0.1?

OCPP 2.0.1 stellt die nächste Generation des Standards dar und führt native TLS- und Zertifikatsverwaltung, deutlich verbesserte Ferndiagnose- und Geräteverwaltung sowie vollständige Unterstützung für ISO 15118 Plug & Charge ein, die fest in die Kernspezifikation integriert ist, einschließlich intelligenter Ladefunktionen, die über die Möglichkeiten der DataTransfer-Umgehungslösung hinausgehen.

Die Falle der „Versionsfragmentierung“

Die Suchanfragen nach Neuigkeiten zu OCPP 2.0.1 nehmen rasant zu, und das ist auch kein Wunder! Jeder möchte die Version mit den meisten Funktionen. Doch bevor Sie sich auf die Suche nach neuen Funktionen begeben, sollten Sie vorsichtig sein. Es gibt eine Falle, die Sie kennen sollten: Nicht alle „2.0.1-kompatiblen“ Plattformen sind gleich.

Viele Anbieter von Ladepunkt-Managementsystemen (CPMS) geben an, beide Versionen zu unterstützen. In der Praxis betreiben sie jedoch häufig einen stabilen 1.6-Stack parallel zu einer noch unausgereiften 2.0.1-Implementierung.

Wenn Ladegeräte der Versionen 1.6 und 2.0.1 dasselbe Netzwerk nutzen, greift die Plattform oft auf den kleinsten gemeinsamen Nenner zurück, sodass Ihre hochwertige 2.0.1-Hardware letztendlich wie ein einfaches 1.6-Gerät verwaltet wird.

Das Ergebnis: Sie haben in eine moderne Ladeinfrastruktur investiert, aber Ihre Software kann deren Potenzial nicht voll ausschöpfen.

Die Versionsnummer auf einem Datenblatt ist nur ein Teil der Geschichte. Der wahre Maßstab für jede OCPP-Implementierung ist ihre Leistung unter realen Bedingungen – wenn die Verbindung abbricht, die Hardware Fehlfunktionen zeigt und Randfälle auftreten, die kein Labortest vorhersagen kann. Schauen wir uns einmal an, wie das in der Praxis aussieht.

‍

4. Fallstudien aus der Praxis (Erfahrungen aus der Praxis)

Um die Praxis der OCPP-Integration in Lademanagementsysteme für Elektrofahrzeuge zu veranschaulichen, finden Sie hier anonymisierte Szenarien, die wir für Kunden umgesetzt haben. Diese verdeutlichen den Unterschied zwischen einem „Standard“-CPMS und einem „betriebsbereiten“ CPMS.

Fallstudie Nr. 1: Versagen des Lastmanagements bei der „sicheren Grenze“

• Das Szenario: Ein Standort mit begrenzter Netzkapazität nutzte OCPP-Profile für intelligentes Laden, um die Stromaufnahme dynamisch zu begrenzen.
• Der Ausfall: Während eines Unwetters brach die Internetverbindung der Website ab.‍
• Das Ergebnis: Das „Standard“-CPMS sendete keine Profile mehr. Da die Ladegeräte keine Anweisungen erhielten, kehrten sie zu ihrer maximalen Hardware-Leistung (32 A) zurück.‍
• Die Folgen: Auf der Baustelle ist die Hauptsicherung durchgebrannt, was den Einsatz eines Notfall-Elektrikers erforderlich machte und das Netzwerk für 24 Stunden lahmlegte.‍
• Die operative Lösung: Eine ausgereifte OCPP-Plattform nutzt eine „Safe-Limit“-Logik. Sie konfiguriert die internen Ausweich-Einstellungen des Ladegeräts über OCPP-Schlüssel, bevor die Internetverbindung unterbrochen wird. Bei einem Verbindungsausfall schaltet das Ladegerät automatisch auf einen sicheren Wert von 6 A um, sodass der Standort weiterhin betriebsbereit bleibt. Genau für solche Szenarien ist eine ausgereifte Lastmanagement-Logik ausgelegt.

Fallstudie Nr. 2: Der Umsatzverlust durch „Ghost-Sessions“

• Das Szenario: Ein CPO stellte eine Diskrepanz zwischen der gelieferten Energie und den ausgestellten Rechnungen fest.
• Der Fehler: Ein Fahrer schloss das Ladegerät an, doch die Autorisierung schlug aufgrund einer Mobilfunkstörung fehl. Das Ladegerät sendete einen „StartTransaction“-Befehl, doch der Server empfing diesen nie. Da das Ladegerät davon ausging, online zu sein, gab es Strom ab.‍
• Das Ergebnis: Eine „Zombie“- oder „Geister“-Sitzung, bei der zwar Energie fließt, aber kein Abrechnungsdatensatz vorliegt.‍
• Die operative Lösung: Das System sucht nach Ladestationen mit dem Status „Belegt“, für die in der Datenbank keine aktiven Transaktions-IDs vorhanden sind. Anschließend wird eine TriggerMessage ausgelöst, um den Status der Ladestation mit der Cloud abzugleichen und die fehlenden Abrechnungsdaten nachträglich wiederherzustellen.

Fallstudie Nr. 3: Der „Firmware-Brick“

• Das Szenario: Ein Fuhrparkmanager hat ein vom Hersteller empfohlenes Firmware-Update auf 200 OCPP -Ladegeräte für Elektrofahrzeuge installiert.
• Der Fehler: Durch das Update wurde das Zeitstempelformat in der MeterValues-Nachricht geringfügig verändert (ein häufiger Fehler bei der Protokollimplementierung).‍
• Das Ergebnis: Die OCPP-Backend-Software wies die Nachrichten als „malformedJSON“ zurück. Die Ladegeräte funktionierten zwar, es wurden jedoch keine Daten aufgezeichnet.‍
• Die operative Lösung: Hierfür ist ein CPMS mit einer „toleranten“ Erfassungsschicht erforderlich, die bei fehlerhaften Daten zwar eine Warnung ausgibt, diese aber dennoch erfasst, anstatt sie sofort zurückzuweisen und damit den Umsatzdatensatz zu verlieren.

All diese Probleme lassen sich vermeiden, wenn man weiß, wie man OCPP-konforme Software richtig implementiert.

5. Bewährte Verfahren für die OCPP-Implementierung

Wenn Sie nach bewährten Verfahren für die Implementierung einer OCPP-Ladeinfrastruktur für Elektrofahrzeuge suchen, sollten Sie über die Softwarefunktionen hinausblicken und sich mit den Steuerungsmechanismen befassen.

Um Probleme bei der CPMS-Integration zu vermeiden, sollten Sie Ihren Beschaffungsprozess wie ein technisches Audit behandeln. Folgende Fragen sollten Sie einem Anbieter stellen, bevor Sie einen Fünfjahresvertrag abschließen:

Die Warnsignale

Verlassen Sie sich nicht auf die Spalten „Ja“ oder „Nein“ in einer Ausschreibung. Stellen Sie diese Fragen, um den tatsächlichen Reifegrad zu ermitteln:

1. „Zeig mir deine ‚Ghost Session‘-Logik.“
   Worauf du achten solltest: Verfügen sieüber automatisierte Skripte, um zu erkennen, wenn ein Ladegerät Energie abgibt, ohne dass eine gültige Abrechnungssitzung vorliegt?

2. „Wie gehen Sie mit ‚Dialekten‘ um?“
   Worauf Sie achten sollten: Wenn sie sagen: „Wir halten uns strikt an den Standard“, laufen Sie weg. Sie sollten sagen: „Wir verfügen über eine Anpassungsschicht für verschiedene Hardware-Marken.“

3. „Demonstrieren Sie ein Massen-Firmware-Update in einer gemischten Flotte.“
   Worauf Sie achten sollten: Fragen Sie , wie sie Updates nach OCPP 1.6 und 2.0.1 gleichzeitig durchführen, ohne dass das Netzwerk abstürzt.

4. „Wie sieht Ihr ‚Safe Limit‘-Protokoll aus?“
   Worauf Sie achten sollten: Wenn während einer Lastmanagement-Maßnahme die Internetverbindung unterbrochen wird, löst das Ladegerät dann die Sicherung aus oder schaltet auf ein sicheres Mindestniveau herunter?

6. Fazit: Willkommen im Zeitalter der operativen Umsetzung

Wir schreiben das nicht, um Ihnen Angst zu machen. Wir schreiben das, weil die Ära des „Landgrabs“ beim Laden von Elektroautos vorbei ist. Wir befinden uns nun in der Ära der Betriebsreife.

Die Spielregeln haben sich geändert. Die Rentabilität hängt nicht mehr von der Anzahl der installierten Ladestationen ab, sondern von der Systemverfügbarkeit, der Umsatzintegrität und den Betriebskosten. Die Herausforderungen bei der OCPP-Implementierung sind der größte Feind dieser Rentabilität.

Wir bei Ocean geben nicht vor, dass unsere Software Wunder bewirkt. Wir verstehen uns als Partner mit Kampferfahrung. Wir haben Jahre damit verbracht, unsere OCPP-Software so zu optimieren, dass sie mit der chaotischen, fragmentierten Realität des Hardwaremarktes zurechtkommt – damit Sie das nicht tun müssen.

Wenn Sie von „Plug and Play“ zu „Plug and Partner“ wechseln möchten, sind Sie hier genau richtig.

Sind Sie bereit, Ihren Lieferanten zu prüfen?

Laden Sie das Leitfaden „Strategische CPMS-Beschaffung“ herunter

Holen Sie sich den umfassenden Leitfaden mit technischen Spezifikationen, Vertragsstrafen und den entscheidenden Fragen, die Sie benötigen, um eine Plattform auf Versorgungsniveau zu sichern.

Sprechen Sie mit unserem Team über die praktische Umsetzung von OCPP

Wir zeigen euch unsere Narben aus dem Kampf. Und wie wir sie überwunden haben.