Vendor-Lock-in
Der Backend-Wechsel gilt intern als Projektrisiko: Tausende Ladepunkte hängen direkt am Altsystem, jede Umstellung bedeutet Rekonfiguration im Feld – also bleibt alles, wie es ist.
NeLeSo OCPP Broker
Ein Broker. Beliebige Backends. Null Downtime.
Der NeLeSo OCPP Broker entkoppelt Ladepunkte von Backends. Migration, Parallelbetrieb und Rollback werden pro Ladepunkt planbar – ohne Big Bang und ohne Rekonfiguration im Feld.
Ein Baustein aus unserem Software-Baukasten – einzeln einsetzbar oder als Teil einer Lösung, die wir mit Ihnen bauen und testen.
Das Problem
Ihr Backend ist zur Sackgasse geworden?
Ladepunkte sind fest an ein Zielsystem verdrahtet, das Protokoll-Niveau im Feld ist gemischt, und jede Störung landet ungefiltert im Support. Drei Muster, die wir seit Jahren in Ladeparks sehen.
Protokoll-Mix
OCPP-1.6-Bestand trifft auf 2.0.1-Anforderungen: Neue Backends, Zertifizierungen und Ausschreibungen verlangen Funktionen, die Ihre Bestandsgeräte von sich aus nie liefern werden.
Blindflug im Support
Jedes Zielsystem muss jede Charger-Eigenheit kennen: Firmware-Macken, Hersteller-Dialekte und Verbindungsabbrüche schlagen ungefiltert im Backend auf – und im Support-Ticket.
Funktionen
Eine Middleware, die mehr kann als weiterleiten.
Sechs Kernfunktionen, ein Ziel: Ladepunkte und Backends unabhängig voneinander betreiben – bei Betreibern im produktiven Betrieb erprobt.
Multi-Backend-Routing
Nachrichten werden regelbasiert geroutet – pro Charger, pro Gruppe oder pro Standort. Mehrere Backends laufen parallel, ohne dass ein Ladepunkt davon etwas mitbekommt.
Digital Twin State-Cache
Der Broker hält den vollständigen Stationszustand vor: Konfiguration, Status, letzte Messwerte. Abfragen beantwortet er direkt aus dem Cache – ohne Hardware-Roundtrip.
Protokoll-Normalisierung
OCPP 1.6 ↔ 2.0.1 in beide Richtungen: Bestandsgeräte sprechen mit modernen Backends, ohne dass Firmware oder Zielsystem angepasst werden müssen.
Session-Stabilisierung
Reconnect-Logik, Message-Queue und Auto-Resync fangen instabile Verbindungen ab. Laufende Ladevorgänge überstehen Backend-Neustarts und kurze Netzunterbrechungen.
KI-Diagnose
Logs, Events und MeterValues werden zu verständlichen Ursachenketten: Statt Rohdaten sieht Ihr Support, was passiert ist – und was zu tun ist.
Skalierung
Ausgelegt auf hohe Session-Zahlen pro Node und im Dauerbetrieb erprobt – horizontal skalierbar und im Betrieb mit 24/7-Monitoring überwacht.
Zero-Downtime-Migration
Migration ist bei uns Regelbetrieb, kein Projektrisiko.
Der Broker hält die Verbindung zu jedem Ladepunkt, während das Zielsystem dahinter wechselt. Jeder Schritt ist beobachtbar, jeder Schritt ist umkehrbar – und Ihre Sessions laufen durchgehend weiter.
- Schatten-Anbindung: Backend B hört mit, bevor es übernimmt
- Vergleichsbetrieb: beide Systeme erhalten denselben Datenstrom
- Gruppenweise Umschaltung im laufenden Betrieb
- Rollback bleibt pro Ladepunkt jederzeit offen
Migrationspfad
Vier Schritte von Backend A nach Backend B.
Analyse & Schatten-Routing Bestand erfassen, Backend B parallel anbinden – ohne Eingriff am Ladepunkt.
Vergleichsbetrieb Beide Backends erhalten denselben Datenstrom; Abweichungen werden sichtbar, bevor sie zählen.
Gruppenweise Umschaltung Standorte und Gruppen wechseln nacheinander – Sessions laufen ununterbrochen weiter.
Betrieb auf Backend B Altsystem abmelden, Ereignisjournal behalten, Rollback-Pfad dokumentiert.
Betriebsmodelle
SaaS, On-Premises oder Appliance – Sie entscheiden, wo der Broker läuft.
Identischer Funktionsumfang in allen drei Modellen. Source Code inklusive.
SaaS
Betrieb in unserer Cloud: der schnellste Start, mit Updates, Betrieb und 24/7-Monitoring durch das Team, das den Broker gebaut hat.
On-Premises
In Ihrem Rechenzentrum oder Ihrer Cloud-Umgebung: volle Datenhoheit, Anbindung an bestehende Systeme, betrieben von Ihrem Team – mit unserem Support.
Appliance
Als Edge-Appliance direkt am Standort: für Umgebungen ohne dauerhafte Cloud-Anbindung, vorkonfiguriert und im Test-Lab geprüft.
NELESO EDGE APPLIANCE · TEST-LAB
Appliance
Der Broker läuft auch dort, wo keine Cloud hindarf.
Die Edge-Appliance bringt den vollen Broker an den Standort: dieselbe Software, dieselben Routing-Regeln, derselbe Digital Twin – geprüft in unserem Test-Lab, bevor sie ins Feld geht.
- Air-gap-fähiger Betrieb ohne dauerhafte Cloud-Anbindung
- Lokale Message-Queue überbrückt WAN-Ausfälle
- Brownfield-tauglich: Bestandsgeräte bleiben, wie sie sind
FAQ
Häufige Fragen zum OCPP Broker.
Was ist ein OCPP Broker?
Ein OCPP Broker ist eine Middleware zwischen Ladepunkten und OCPP-Backends. Er terminiert die Verbindung jedes Ladepunkts, hält dessen Zustand in einem Digital Twin und routet Nachrichten regelbasiert an ein oder mehrere Zielsysteme. Dadurch lassen sich Backends wechseln, parallel betreiben oder testen, ohne dass am Ladepunkt etwas umkonfiguriert werden muss.
Broker oder komplettes CPMS – was brauche ich?
Den Broker, wenn Sie Ihr bestehendes oder künftiges Backend behalten und unabhängig davon werden wollen – für Migration, Multi-Backend-Betrieb oder Protokoll-Normalisierung. Ein komplettes CPMS, wenn Sie zusätzlich Betriebsoberfläche, Tarife und Abrechnung brauchen. Beides lässt sich kombinieren: Der Broker bildet den Unterbau, Module aus dem CPMS-Baukasten kommen nach Bedarf dazu.
Wie lange dauert eine Backend-Migration?
Typischerweise Wochen statt Monate – abhängig von der Zahl der Standorte und dem Zustand des Bestands. Weil die Umschaltung pro Ladepunkt, Gruppe oder Standort erfolgt, ist die Migration pro Standort planbar und es gibt keinen Big Bang: Schatten-Anbindung und Vergleichsbetrieb laufen vorab, der Rollback bleibt jederzeit offen.
Welche OCPP-Versionen werden unterstützt?
OCPP 1.6 und OCPP 2.0.1 laufen produktiv, OCPP 2.1 ist vorbereitet. Der Broker normalisiert zwischen den Versionen, sodass Bestandsgeräte mit OCPP 1.6 auch an Backends betrieben werden können, die OCPP 2.0.1 erwarten.
Nächster Schritt