NeLeSo OCPP Gateway · Funktionsübersicht
Ihre Ladeinfrastruktur bleibt. Backend und Datennutzung werden flexibel.
Der OCPP Broker verbindet Ihre Ladepunkte mit dem Betriebsbackend und zusätzlichen Systemen. Sie steuern Datenzugriff und Routing, leiten Ereignisse an eigene Anwendungen weiter und untersuchen Störungen in einer gemeinsamen Oberfläche.
OCPP & Routing
Bestehende Backend-Landschaften anbinden und neue Zielsysteme schrittweise erproben.
Routing je Charge Point ID über WS/WSS. Station und Ziel sprechen dieselbe Protokollversion; eine automatische Versionsübersetzung findet nicht statt.
Neben einem Primärbackend können je Station bis zu acht zusätzliche Backends angebunden werden. Ein passiver Beobachter erhält freigegebene Ereignisse. Eine virtuelle Verbindung bildet eine eigene OCPP-Sicht für das zusätzliche Backend ab.
Ziele, Datenfilter und Zuordnungen prüfen, bevor eine Route umgestellt wird. Der Wechsel wird passend zu Stationen, Verbindungen und Betriebsabläufen geplant.
Standorte & Rechte
Standorte und Flotten gemeinsam verwalten und Zuständigkeiten gezielt abgrenzen.
Stationen zuordnen, Bestände filtern und Routing-Profile mit einer Vorschau auf mehrere Stationen anwenden.
Partner, Benutzerkonten und API-Schlüssel erhalten einen festgelegten Stationsumfang. Rollen bestimmen, welche Funktionen innerhalb dieses Umfangs verfügbar sind.
Der Zugriff auf Daten erlaubt noch keine Stationsbefehle. Für zusätzliche OCPP-Backends werden Stationsumfang, erlaubte Datenaktionen und Steueraktionen getrennt festgelegt.
HTTPS & MQTT
Messwerte, Sessionereignisse und Betriebsdaten für Analyse, Speicherung oder weitere Anwendungen nutzen.
Daten an konfigurierte HTTPS-Ziele oder MQTT-Broker senden. MQTT 3.1.1 und MQTT 5 sind mit TLS und QoS 1 verfügbar; Nachrichten werden ohne Retain-Flag gesendet. Der Broker veröffentlicht Daten; er abonniert keine Steuerkanäle.
Eine in PostgreSQL gespeicherte Outbox hält ausstehende Zustellungen über Neustarts hinweg vor. Begrenzte Warteschlangen, Wiederholungsversuche und eine geordnete Zustellung je Station und Ziel machen Rückstände nachvollziehbar.
Die Ereignis-ID verbindet alle Ausgaben mit ihrer Quelle. Jede Ausgabe erhält zusätzlich eine Zustell-ID, die bei Wiederholungen gleich bleibt. So erkennen Empfänger Duplikate, auch wenn ein Workflow mehrere Ausgaben erzeugt. Zustellstatus, Fehler und Rückstände sind sichtbar.
NATS JetStream
Optionale Ausleitung an Ihre NATS-Instanz, mit gezielter Nachrichtenauswahl und sichtbarem Empfang im Web-Testclient. Verfügbar nach installiertem Release und vereinbartem Umfang.
CALL, CALLRESULT und CALLERROR nach OCPP-Aktion, Charge Point ID und Richtung auswählen. Antworten werden ihrem Aufruf zugeordnet, soweit die Korrelation verfügbar ist.
Zielverbindung und Filter verwalten, den Laufzeitstatus prüfen und eine gekennzeichnete Testnachricht mit JetStream-Speicherbestätigung senden.
Angenommene Nachrichten werden nach der konfigurierten JetStream-Aufbewahrung gespeichert. Ein eigener Web-Client zeigt Subject, Zeitpunkt und Inhalt. Erneute Zustellungen sind möglich; Consumer müssen Duplikate berücksichtigen.
Die NATS-Ausleitung im Gateway arbeitet mit einer begrenzten Warteschlange im jeweiligen Prozess. Ein Neustart kann noch nicht veröffentlichte Nachrichten verwerfen. Queue-Überläufe und Veröffentlichungsfehler sind im Laufzeitstatus sichtbar.
Visuelle Workflows
Abläufe direkt im Browser zusammenstellen und vor dem Aktivieren ohne Nebenwirkungen testen.
Ereignis- und Zeittrigger, Filter, Bedingungen, Verzweigungen, Feldzuordnung und Wartezeiten mit Alarm-, HTTPS- oder MQTT-Ausgaben verbinden. Die Abläufe sind gerichtete Graphen ohne Schleifen.
Änderungen als Entwurf speichern, eine Version veröffentlichen, frühere Versionen wiederherstellen und Abläufe deaktivieren. Ein Testlauf zeigt den Pfad und geplante Ausgaben, ohne Nachrichten zu senden oder Alarme anzulegen.
Wartende Schritte werden nach einem Neustart fortgesetzt. Ein Warteknoten verwendet die ursprünglichen Ereignisdaten. Freie Skripte und physische Stationsbefehle sind keine Workflow-Bausteine.
Das MQTT-Ausgabeziel wird vor der Veröffentlichung ausdrücklich ausgewählt.
Diagnose & Alarme
Aktuelle Zustände mit der Historie verbinden und Auffälligkeiten gezielt bearbeiten.
Ereignisverläufe und Auswertungen für Tage, Wochen oder Monate öffnen. Nach Station, Standort, Gruppe und Zeitraum eingrenzen, um Verbindungsprobleme und wiederkehrende Fehler zu untersuchen.
Stations- und Backend-Ausfälle, wiederholte Fehler oder Zustellrückstände mit Mindestdauer, Wiederholung und Eskalation überwachen. Meldungen können je Station oder für einen ausgewählten Bestand zusammengefasst werden.
Alarme quittieren und eine stabile Erholung abwarten. Fehlende oder veraltete Telemetrie gilt als unbekannt; sie wird nicht als Beleg für einen wieder störungsfreien Betrieb gewertet.
Stationszustände und Ladehistorie in der Oberfläche nachvollziehen. Der digitale Zwilling hält beobachtete Stationszustände und Transaktionen am externen Primärbackend fest. Datenlücken bleiben erkennbar.
MCP & KI-Abfragen
Der MCP-Server verbindet freigeschaltete Installationen mit ChatGPT oder Claude. Fragen Sie in natürlicher Sprache nach Stationen, Ladesessions, Routing und ausgewählten Chargerparametern.
Verbindungszustände prüfen, Ladesessions durchsuchen und zusammenfassen oder die zugeordneten Backends einer Station abfragen.
Mini-CPMS-Historie und beobachtete Broker-Historie bleiben getrennt. Antworten enthalten Quelle, Zeitstand und bekannte Datenlücken; fehlende oder veraltete Werte bleiben als unbekannt erkennbar.
Freigegebene Konfigurationswerte über OCPP 1.6 GetConfiguration oder OCPP 2.0.1 GetVariables abfragen. Der MCP-Zugang bleibt lesend: Konfigurationsänderungen, Start/Stop und Reset gehören nicht dazu.
Administratoren schalten persönliche Broker-Konten ausdrücklich frei. Freigeschaltete Konten können die gesamte Installation lesen. Verbindungen sind einzeln widerrufbar; Werkzeugaufrufe werden protokolliert.
Befehlsprioritäten
Freigegebene Anfragen verschiedener Quellen koordinieren, bevor sie die Station erreichen.
Primärbackend, lokale Bedienung/API und zusätzliche virtuelle Backends erhalten konfigurierbare Prioritäten. Gleiche Prioritäten werden in Eingangsreihenfolge bedient.
Die Priorität gilt für noch nicht gesendete Anfragen. Anzahl, Datenmenge und Wartezeit sind begrenzt; pro Station bleibt höchstens ein physischer Befehl unbeantwortet.
Rechte und Verbindung werden vor dem Versand erneut geprüft. Ein gesendeter Befehl wird weder unterbrochen noch nach einem unklaren Ergebnis automatisch erneut gesendet.
Eigener Betrieb
Auf kundeneigenem Linux mit Docker Compose und PostgreSQL betreiben – im Rechenzentrum, Cloud-Tenant oder am Standort.
Ein schlankes Mini-CPMS steht als lokales Primärziel für Stationsstatus, Ladesessions und RFID-Freigaben bereit. Externe Primärbackends können weiterhin je Station verwendet werden.
Verschlüsselte Verbindungen, geschützte Zugangsdaten und nachvollziehbare Änderungen unterstützen den Betrieb. Ihre IT verwaltet Netzwerk, Zertifikate, Backups und Wiederherstellung.
Bestände und Betriebsinformationen über eine dokumentierte REST API in eigene Anwendungen einbinden. API-Schlüssel, Rollen und Stationsfreigaben begrenzen den Zugriff.
Standardmäßig 30 Tage für Ereignisjournal und abgeschlossene Workflow-Läufe sowie 365 Tage für erledigte Alarme. Wartende Zustellungen bleiben erhalten; die Fristen lassen sich an Ihren Betrieb anpassen.
Betriebsgrenzen
Bestätigungen im OCPP-Dialog mit der physischen Station und Ladefreigaben bleiben Aufgabe des primären Betriebsbackends. Dieses kann ein externes System oder der integrierte CoreCPMS sein. Ein Zusatzbackend übernimmt diese Rolle bei einem Ausfall nicht automatisch.
Dauerhafte Pufferung gibt es für HTTPS-/MQTT-Datenexporte und freigegebene virtuelle Zusatzverbindungen. Sie beginnt mit der erfolgreichen Speicherung in der Datenbank. Daraus folgt keine lokale Bestätigung von Primärnachrichten und keine automatische Ladesteuerung bei fehlendem Cloud-Backend. Ein passiver Beobachter ist kein dauerhaftes Replay-Ziel.
Ihr Einsatzfall
Wir prüfen vorhandene Backends, Datenziele und Partnerzugriffe mit Ihnen und legen den passenden Betriebsumfang fest.