Architektur · Zielbild
Ein gemeinsamer Kern ist ein Produktvertrag – nicht nur ein Diagramm.
Das Ziel ist eine versionierte Broker- und Server-Basis, die in allen drei Produkten aus denselben Quellen gebaut wird. Oberflächen, APIs und Betriebsmodelle dürfen sich unterscheiden; Protokollverhalten und Kernverträge nicht.
Diese Seite dokumentiert die verbindliche Entwicklungsrichtung. Die Produktseiten benennen den jeweils aktuellen Angleichungsstand.
Systemfluss
OCPP zuerst. Produkte darüber.
Der Kern terminiert Stationsverbindungen, routet Nachrichten, normalisiert Zustände und stellt kontrollierte Kommandos bereit. Die Produkte setzen ihre jeweiligen Benutzer- und Integrationsflächen darauf.
Gemeinsamer Vertrag
Vier Dinge müssen in allen Auslieferungen zusammenbleiben.
Protokollverhalten
OCPP-Nachrichten, Zustandsübergänge, Fehler und Timeouts folgen denselben getesteten Regeln.
Routingmodell
Charge Point IDs, Zielsysteme, Beobachter und Regeln verwenden einen gemeinsamen Konfigurationsvertrag.
Ereignis- und Datenmodell
Stationen, Sessions, Messwerte und Kommandos behalten stabile Identitäten über die Produktschichten hinweg.
Release-Artefakte
Tests, OpenAPI-Spezifikationen und Kompatibilitätsnachweise entstehen aus demselben versionierten Build.
Migrationsstand
Heute getrennt, im Ziel gemeinsam.
Die Tabelle verhindert, dass Zielarchitektur als bereits ausgelieferte Parität gelesen wird.
| Produkt | Heute | Ziel |
|---|---|---|
| OCPP Broker | Eigenständige Implementierung · OCPP 1.6J und 2.0.1 | Gemeinsamer Broker-/Server-Build mit schlanker Oberfläche |
| Community Server | Eigene Komponenten · OCPP 1.6J, 2.0.1 und 2.1 | Gemeinsamer Kern plus offene Ein-Organisations-Schicht |
| Enterprise Server | Enterprise-Dienste · OCPP 1.6J, 2.0.1 je nach Release optional, heute kein 2.1-Runtime-Support | Gemeinsamer Kern plus mandantenfähige Betriebs- und Integrationsschicht |
Produktgrenzen