Subscribe & get the latest news in your email
By
Joachim Lohse
August 1, 2026
Ein Betreiber kauft Ladestationen von drei verschiedenen Anbietern, weil der Einkauf bei der zweiten Tranche einen besseren Preis erzielt hat und ein dritter Lieferant schneller liefern konnte. Alle drei sind OCPP 1.6J-zertifiziert. Auf dem Papier ist das Depot standardisiert.
Dann kommen die Details zum Vorschein. MeterValues treffen in unterschiedlichen Intervallen und mit verschiedenen Messgrößen ein. Ein Anbieter setzt die Transaktions-ID nach einem Neustart zurück, wodurch Ladevorgänge doppelt gezählt werden. Ein Lastmanagement, das bei Anbieter A perfekt funktioniert, liefert bei Anbieter B unbemerkt zu wenig Leistung. Niemand bemerkt es, bis ein Lkw mit nur 40 % Ladestand vom Hof fährt und der Disponent die Route mitten in der Schicht neu planen muss.
Dies ist keine Geschichte über schlechte Hardware. Es ist eine Geschichte über die Lücke zwischen Konformität und Interoperabilität. Ein Zertifikat besagt lediglich, dass eine Ladestation in einem Labor eine definierte Reihe von Nachrichtenaustauschen durchführen kann. Es garantiert nicht, dass sich die Ladestation genauso verhält wie das Gerät daneben – unter realer Last, in einem ausgelasteten Netzwerk und mit mehreren übereinander gelagerten Ladeprofilen.
Dieser Artikel ist ein Leitfaden für die Bereiche, in denen OCPP Interpretationsspielraum lässt, was dadurch schiefgehen kann und wie man dies bereits bei der Inbetriebnahme testet, anstatt es erst im laufenden Betrieb zu entdecken.
Eine Zertifizierung durch Dritte validiert eine Momentaufnahme: einen spezifischen Firmware-Stand, geprüft gegen eine bestimmte Testsuite in einer kontrollierten Umgebung. Drei Faktoren begrenzen den Wert dieser Momentaufnahme für den Praxiseinsatz.
Optionale Funktionen bleiben optional. Große Teile von OCPP sind optional. Eine Ladestation kann vollständig zertifiziert sein, obwohl sie nur einen Teil der Smart-Charging-Funktionen implementiert hat. Die Zertifizierung bestätigt lediglich, dass die vorhandenen Teile funktionieren. Sie sagt jedoch nichts darüber aus, welche Funktionen tatsächlich implementiert sind.
Firmware entwickelt sich schneller als Audits. Bis ein Gerät installiert wird, hat es in der Regel bereits mehrere Firmware-Revisionen hinter sich, die über die zertifizierte Version hinausgehen. Regressionen im Smart-Charging-Verhalten sind häufig und werden in den Release-Notes selten dokumentiert.
Konformität ist ein zweiseitiges Problem. Das Backend kann bei der Spezifikation genauso nachlässig sein wie die Ladestation. Wenn beide Seiten die Vorgaben auf unterschiedliche Weise nur annähernd erfüllen, wird die Fehlersuche zu einer Diskussion statt zu einer Diagnose. Falls Sie sich erst noch ein grundlegendes Verständnis des Protokolls erarbeiten, unser Leitfaden zur Einrichtung und Fehlerbehebung von OCPP-Ladestationen deckt die Grundlagen ab, auf denen dieser Artikel aufbaut.
Eine Korrektur zu einer weit verbreiteten Annahme: Chinesische Hersteller sind nicht systematisch schlechter als europäische oder nordamerikanische. In unseren eigenen Tests treten unvollständige Smart-Charging-Implementierungen in jeder Preisklasse und in jeder Region auf, auch bei namhaften Tier-1-OEMs.
Dies sind die Fehlerquellen, die wir in herstellerübergreifenden Depots am häufigsten beobachten. Deren Bewältigung ist die Aufgabe Ihrer OCPP-konforme Ladelösungen und der OCPP-Server dahinter – das lässt sich nicht allein durch den Einkauf lösen.
Die häufigste Schwachstelle. Viele Ladestationen implementieren zwar TxProfile und TxDefaultProfile, aber nicht ChargingStationMaxProfile (bzw. ChargePointMaxProfile in 1.6). Limits auf Sitzungsebene funktionieren, standortweite Limits hingegen nicht. Als Faustregel gilt: Gehen Sie davon aus, dass etwa die Hälfte der Smart-Charging-Funktionen bei einem Gerät fehlt, bis Sie das Gegenteil bewiesen haben.
OCPP definiert, wie Profile auf verschiedenen Stack-Ebenen kombiniert werden und welches Vorrang hat. Die Firmware setzt dies oft falsch um: Sie wendet das zuletzt empfangene Profil anstatt des Profils mit der höchsten Priorität an, ignoriert Stack-Ebenen komplett oder verwirft ein untergeordnetes Profil, wenn ein übergeordnetes abläuft. In einem Depot, das ein Basis-Standortlimit und dynamische Sitzungslimits nutzt, entscheidet dies darüber, ob die Last kontrolliert geregelt wird oder der Schutzschalter auslöst.
Der Fehler, der am meisten Zeit kostet. Ein CSMS sendet SetChargingProfile. Die Ladestation antwortet mit Accepted. Die interne Steuerung ignoriert das Limit dann jedoch, rundet den Sollwert auf willkürliche Schritte oder wendet ihn nicht an, weil der Wert in Watt statt in Ampere angegeben wurde. Aus Sicht des Backends war alles erfolgreich. Aus Sicht des Transformators ist nichts passiert.
ChargingStationMaxProfile erfordert connectorId = 0 (oder evseId = 0), um ein stationsweites Limit festzulegen. Fehlerhafte Firmware akzeptiert dasselbe Profil jedoch für connectorId = 1 – und wendet dann das gesamte Stationslimit auf diesen einen Ladepunkt an, während die anderen unbegrenzt bleiben. Das Ergebnis ist ein gedrosseltes Fahrzeug und eine unkontrollierte Gesamtlast am Standort.
Das Abtastintervall, das ausgerichtete Intervall und die konfigurierten Messgrößen variieren je nach Hersteller und setzen sich nach Firmware-Updates oft zurück. Wenn Ihre Energiemanagement-Logik von einem 30-Sekunden-Wert für Power.Active.Import ausgeht, ein Hersteller aber nur alle 300 Sekunden Energy.Active.Import.Register liefert, arbeitet Ihr Regelkreis mit veralteten Daten und Ihre Abrechnungsdaten sind inkonsistent.
Was passiert, wenn die WebSocket-Verbindung während einer Sitzung abbricht, ist der Punkt, an dem die Implementierungen am stärksten voneinander abweichen. Manche Ladestationen setzen die Transaktion mit derselben ID und gepufferten Zählerwerten fort. Andere starten eine neue Transaktion. Manche setzen den Transaktionszähler nach einem Neustart zurück und erzeugen Kollisionen mit IDs, die bereits im Backend existieren. Manche setzen den Ladevorgang mit voller Leistung fort und verwerfen das Profil, das vor dem Verbindungsabbruch aktiv war.
Hersteller unterstützen unterschiedliche Schlüsselsätze, verwenden verschiedene Namen für identische Funktionen und geben Accepted für Schlüssel zurück, die sie gar nicht implementieren. Konfigurationen, von denen Sie glauben, sie an die Flotte gesendet zu haben, sind möglicherweise nur auf einem Teil der Geräte aktiv. Genau das zu vereinheitlichen, ist der Zweck unserer Hardware-Konfiguration für OCPP-Ladestationen – eine Konfigurationsvorgabe, die modellabhängig übersetzt und durch Rücklesen verifiziert wird, anstatt sich blind auf den Antwortcode zu verlassen.
Veraltete TLS-Versionen, abgelaufene oder selbstsignierte Zertifikate sowie Fallbacks auf Klartext sind nach wie vor weit verbreitet. In einem Multi-Tenant-Hub bedeutet das, dass Sitzungs- und Identifikationsdaten im lokalen Netzwerk abgegriffen werden können. Sicherheit ist selten Teil der Interoperabilitätsdiskussion, sollte es aber sein.
Die Qualität von OCPP 1.6J hat sich von Jahr zu Jahr messbar verbessert. OCPP 2.0.1 hat hier noch nicht aufgeschlossen, und 2.1 legt die Messlatte noch höher.
Während 1.6 von einem Ladegerät nur einen überschaubaren Nachrichtensatz verlangte, führt 2.0.1 ein hierarchisches Gerätemodell und weit über 60 Nachrichtentypen ein. OCPP 2.1 erweitert dies durch bidirektionales Laden und V2X, dynamische Tarifstrukturen und eine reichhaltigere Semantik für intelligentes Laden. Jede zusätzliche Abstraktion ist eine weitere Stelle, an der die Firmware abweichen kann.
Rechnen Sie mit einer Lernphase, die mit der von 1.6J vergleichbar ist. Betrachten Sie jede Behauptung zur Konformität mit OCPP 2.0.1 oder 2.1 als Ausgangspunkt für Tests, nicht als Spezifikation, auf deren Basis Sie einen Zeitplan für die Inbetriebnahme erstellen können.
Sowohl die AFIR in Europa als auch NEVI in den Vereinigten Staaten fordern eine offene, intelligente Infrastruktur mit Echtzeit-Datentransparenz und setzen dafür Fristen. Die Richtung stimmt, und die Branche bewegt sich weitgehend in diese Richtung. Das bedeutet jedoch auch, dass ein Großteil der Protokollentwicklung unter dem Druck fester Termine stattfindet, anstatt sich an einem Zeitplan zu orientieren, der durch die technische Arbeit bestimmt wird.
Eine Zertifizierung bis zu einem Stichtag ist ein engeres Ziel als Robustheit in jedem Einsatzszenario. Konformitätstests prüfen definierte Nachrichtenaustausche unter kontrollierten Bedingungen. Ein Depot mit 40 Lkw, einem 1,2-MW-Netzanschluss und Sollwerten, die sich alle paar Minuten ändern, beansprucht Pfade, für die diese Testsuiten nie ausgelegt waren. Eine Firmware kann die erste Anforderung erfüllen und Sie bei der zweiten dennoch überraschen – nicht, weil jemand geschlampt hat, sondern weil die Validierungsumgebung und die Betriebsumgebung grundlegend unterschiedliche Herausforderungen darstellen.
Für einen Käufer ist die praktische Konsequenz dieselbe: Betrachten Sie die Einhaltung gesetzlicher Vorschriften und die Zuverlässigkeit im Feldeinsatz als zwei getrennte Fragen und überprüfen Sie Letzteres selbst.
Verzögerungen bei der Inbetriebnahme. Die häufigste Folge. Der Software-Go-Live verschiebt sich, während Sie auf ein Firmware-Update des Herstellers warten, was Tage oder Wochen dauern kann – und manchmal mit einer neuen Regression einhergeht.
Funktionen, für die Sie bezahlt haben, die Sie aber nicht nutzen können. Lastmanagement und Energiemanagement hängen davon ab, dass Ladegeräte die Sollwerte tatsächlich einhalten. Wenn ein Gerät nicht auf Befehle reagiert oder ein Profil nur sporadisch befolgt, verkommen Lastspitzenkappung und Depotplanung zu einer statischen Zuweisung. Die Wirtschaftlichkeit des Standorts ändert sich damit ebenfalls.
Wochenlange Fehlersuche. Die Ursache ist selten offensichtlich. Zeit fließt in den Nachweis, wo der Fehler liegt, und dann in die Überzeugungsarbeit bei der verantwortlichen Partei. Beides dauert lange.
Zertifizierungen und Audits können dieses Problem nicht lösen, da sich Firmware- und Softwareversionen ständig ändern. Die dauerhafte Lösung ist architektonischer Natur: Kritische Systeme – EMS, Energiemanagement, Zahlung – müssen unter der Annahme entwickelt werden, dass OCPP nicht korrekt befolgt wird.
In der Praxis bedeutet das für das Backend:
Dies hat zwei positive Nebeneffekte: Die Standorte bleiben trotz fehlerhafter Hardware stabil, und OEMs erhalten konkrete, reproduzierbare Nachweise darüber, wo ihre Firmware vom Standard abweicht – der einzige Hebel, der die Standardisierung zuverlässig vorantreibt.
Die Erkennung muss automatisch erfolgen, da der Fehler konzeptbedingt unsichtbar ist. Hardware-Diagnose überwacht den Befehl-Wirkungs-Zusammenhang: Profil gesendet, Sollwert erwartet, tatsächlich gelieferte Leistung, Abweichung markiert. Protokollierung und Audit der Ladestation bewahrt den vollständigen Nachrichtenverlauf auf. Wenn Sie ein Ticket eröffnen, senden Sie dem OEM einen zeitgestempelten Austausch, der eine Bestätigung (Accepted) zeigt, gefolgt von keiner Änderung der gelieferten Leistung – statt nur einer Problembeschreibung.
Dieser Unterschied ist wichtiger, als es klingt. Eine automatisierte Eskalation mit einem reproduzierbaren Protokoll macht aus einer dreiwöchigen Diskussion einen einfachen Fehlerbericht.
Führen Sie dies bei der Inbetriebnahme durch, für jedes Modell und jede Firmware-Version, nicht nur stichprobenartig.
Unser Service zur Inbetriebnahme von Ladestationen führt diese Abläufe als Teil der Standortabnahme durch, und der Leitfaden zur Inbetriebnahme und Prüfung von Ladehubs erläutert den umfassenderen Prozess, in den dies eingebettet ist.
Interoperabilität ist im Einkauf günstiger als bei der Fehlerbehebung.
Ampcontrol hat mehr als 45 Ladestationsmarken und rund 100 Modelle getestet. Zwei Schlussfolgerungen lassen sich konsistent ziehen.
Die Qualität von OCPP 1.6J verbessert sich von Jahr zu Jahr spürbar. Die Unterstützung für intelligentes Laden ist breiter und zuverlässiger als noch vor drei Jahren, und die gravierendsten Lücken sind kleiner geworden.
OCPP 2.0.1 befindet sich bei den meisten Herstellern dort, wo 1.6J vor einigen Jahren stand, und 2.1 wird diese Entwicklung fortsetzen. Planen Sie eine Lernphase ein.
Das praktische Fazit bleibt unverändert: „OCPP-konform“ ist der Ausgangspunkt für ein Gespräch, keine Garantie für Interoperabilität. Testen Sie bei der Inbetriebnahme, bestehen Sie auf verhaltensbasierten SLAs und betreiben Sie ein Backend, das davon ausgeht, dass das Protokoll fehlerhaft ist, und den Standort dennoch am Laufen hält.
Planen Sie ein Depot mit mehreren Anbietern oder haben Sie Probleme mit einem System, das nicht die von Ihnen spezifizierte Laststeuerung liefert? Sprechen Sie mit dem Ampcontrol-Team.
Ampcontrol ist eine Cloud-basierte Software, die sich nahtlos mit Ladenetzwerken, Fahrzeugen, Flottensystemen und anderen Softwaresystemen verbindet. Keine Hardware erforderlich, nur eine einmalige Integration.
