OCPP Middleware ist ein unscharfer Begriff – die Abgrenzung beginnt bei der Verantwortung.
Wer nach OCPP Middleware sucht, findet alles von Protokollbibliotheken bis zu kompletten Abrechnungsplattformen. In der Praxis meinen die meisten Projekte damit eine Schicht zwischen Ladepunkten und Backends, die Verbindungen, Zustände und Nachrichtenflüsse beherrschbar macht. Genau hier beginnt die Verwechslung: Ein OCPP Broker und ein CPMS lösen unterschiedliche Probleme, auch wenn beide OCPP sprechen.
Der Broker ist eine Entkopplungsschicht. Er terminiert OCPP-Verbindungen, hält den Zustand der Ladepunkte, normalisiert Herstellerunterschiede und routet Nachrichten an ein oder mehrere Zielsysteme. Er entscheidet nicht, was eine Kilowattstunde kostet, wer laden darf oder wie eine Rechnung aussieht.
Das CPMS ist die Geschäftsschicht. Es kennt Nutzer, Verträge, Tarife, Autorisierungslisten, Roaming-Beziehungen und Abrechnungsprozesse. In Projekten sehen wir häufig, dass beide Rollen in einer Plattform vermengt werden. Genau daraus entstehen später Migrations-, Test- und Skalierungsprobleme.
Was ein OCPP Broker technisch leistet.
Kernaufgabe des Brokers ist es, die Eigenheiten des Feldes an einer Stelle zu behandeln. Ladepunkte unterscheiden sich in Firmware, Timing, Wiederverbindungsverhalten und der Interpretation einzelner OCPP-Nachrichten. Der Broker fängt diese Unterschiede ab, bevor sie in nachgelagerte Systeme durchschlagen.
Dazu kommt der State Cache: Der Broker weiß jederzeit, welche Ladepunkte verbunden sind, welche Sessions laufen und welche Nachrichten offen sind. StatusNotification, MeterValues und Transaktionsereignisse werden gepuffert, wenn ein Zielsystem kurzzeitig nicht erreichbar ist. Nachgelagerte Systeme bekommen dadurch ein konsistentes Modell statt einer lückenhaften Rohdatenspur.
Wichtig ist auch die Protokollebene. OCPP 1.6 und 2.0.1 sind nicht kompatibel untereinander, OCPP 2.1 ist dagegen abwärtskompatibel zu 2.0.1. Ein Broker kann gemischte Bestände sauber trennen, pro Ladepunkt versionieren und schrittweise migrieren, ohne dass jedes Backend jede Variante beherrschen muss.
- Routing: eine Ladepunkt-Verbindung, mehrere Zielsysteme wie CPMS, Monitoring und Analyse.
- State Cache: aktueller Zustand von Connectoren, Sessions und offenen Nachrichten.
- Normalisierung hersteller-spezifischer OCPP-Interpretationen und Firmware-Eigenheiten.
- Queueing und Replay von Ereignissen bei Backend-Ausfällen.
- Versions-Handling für gemischte Bestände aus OCPP 1.6 und OCPP 2.x.
Was ein CPMS leistet – und warum das eine andere Disziplin ist.
Das CPMS beantwortet die Frage, was ein Ladevorgang geschäftlich bedeutet. Es verwaltet Nutzer und Vertragskonten, prüft Autorisierungen, berechnet Tarife und erzeugt Belege. Dazu kommen Roaming über OCPI 2.2 oder 2.3, etwa in Richtung Hubject, sowie Reporting und Betreibersichten.
Regulatorik gehört ebenfalls in diese Schicht. Eichrechtskonforme Abrechnung verlangt MID-konforme Zähler und OCMF-signierte Messwerte, die sich mit Transparenzsoftware prüfen lassen. Für B2B-Rechnungen kommen Formate wie XRechnung oder ZUGFeRD dazu, und die AFIR verlangt seit 2024 unter anderem Ad-hoc-Zahlung und Datenbereitstellung an öffentlichen Ladepunkten.
Nichts davon ist Aufgabe eines Brokers. Ein Broker, der Tarife rechnet, ist kein Broker mehr, sondern ein zweites CPMS mit unklarer Verantwortung. Die saubere Trennung hält beide Schichten austauschbar, testbar und einzeln migrierbar.
Wann ein Broker reicht – und wann beides gebraucht wird.
Nur ein Broker genügt, wenn die Geschäftslogik bereits existiert und das eigentliche Problem in der Feldanbindung liegt. Typisch sind Migrationen zwischen CPMS-Systemen, Multi-Vendor-Bestände mit abweichendem OCPP-Verhalten, Testumgebungen für Hersteller oder das Spiegeln des Datenstroms in Monitoring und Analyse. Der Broker löst diese Fälle, ohne dass Tarife oder Nutzerverwaltung angefasst werden müssen.
Beides wird gebraucht, sobald eine Organisation selbst abrechnet oder Roaming betreibt und gleichzeitig eine heterogene, wachsende Infrastruktur verantwortet. Dann trägt das CPMS Nutzer, Tarife, Belege und Roaming-Beziehungen, während der Broker die Feldkomplexität kapselt. Die Schnittstelle zwischen beiden bleibt schmal und stabil, weil das CPMS nur noch einen normalisierten Nachrichtenstrom sieht.
In Projekten sehen wir ein einfaches Entscheidungsmuster. Je häufiger sich Backends, Mandanten oder OCPP-Versionen ändern und je gemischter der Bestand ist, desto mehr lohnt sich die Entkopplungsschicht. Bleibt die Landschaft klein und homogen, ist der direkte CPMS-Anschluss oft die pragmatischere Wahl.
- Nur Broker: CPMS vorhanden, aber Migration, Parallelbetrieb oder Multi-Vendor-Probleme im Feld.
- Nur CPMS: kleiner, homogener Bestand mit einem einzigen stabilen Backend.
- Beides: eigene Abrechnung und Roaming plus heterogenes, wachsendes Feld.
- Klares Broker-Signal: Jedes neue Zielsystem erfordert Änderungen an den Ladepunkten selbst.
Kombinationsarchitekturen: Broker vor, neben oder zwischen CPMS.
Die häufigste Architektur ist der Broker vor einem CPMS. Alle Ladepunkte verbinden sich mit dem Broker, der einen normalisierten Nachrichtenstrom an das Backend liefert. Migrationen werden damit zu Routing-Änderungen statt zu Feld-Rollouts, weil die Ladepunkte ihre Verbindung nie wechseln müssen.
Daneben etabliert sich der Broker als Verteiler: Produktion, Staging, Monitoring und Analyse hängen als getrennte Zielsysteme am gleichen Datenstrom. Für Betreiber mit mehreren Mandanten oder mehreren CPMS kann der Broker Nachrichten regelbasiert pro Standort, Hersteller oder Vertrag routen. Auch neue Anforderungen wie ISO 15118 – seit Januar 2026 für neue öffentliche AC-Ladepunkte in der EU verpflichtend – oder Plug&Charge nach ISO 15118-20 lassen sich so schrittweise einführen, ohne den gesamten Bestand gleichzeitig umzustellen.
Ein sauberer Schnitt sieht genau so aus: Der OCPP Broker übernimmt Entkopplung, State Cache und Normalisierung, CPMS-Module ergänzen Tarife, Abrechnung und Roaming dort, wo sie tatsächlich gebraucht werden. Entscheidend bleibt die Abgrenzung: OCPP Middleware ist keine abgespeckte Version eines CPMS, sondern eine eigene Architekturschicht mit eigener Verantwortung.