Architecture · target
A shared core is a product contract – not just a diagram.
The target is one versioned broker and server foundation built from the same sources for all three products. Surfaces, APIs and operating models may differ; protocol behaviour and core contracts may not.
This page documents the binding development direction. Each product page states its current alignment status.
System flow
OCPP first. Products above it.
The core terminates station connections, routes messages, normalises state and exposes controlled commands. Each product places its own user and integration surfaces on top.
Shared contract
Four things must stay aligned across every distribution.
Protocol behaviour
OCPP messages, state transitions, errors and timeouts follow the same tested rules.
Routing model
Charge Point IDs, targets, observers and rules use one shared configuration contract.
Event and data model
Stations, sessions, meter values and commands retain stable identities across product layers.
Release artefacts
Tests, OpenAPI specifications and compatibility evidence come from the same versioned build.
Migration status
Separate today, shared in the target.
This table prevents the target architecture from being mistaken for parity that has already shipped.
| Product | Today | Target |
|---|---|---|
| OCPP Broker | Independent implementation · OCPP 1.6J and 2.0.1 | Shared broker/server build with a lean surface |
| Community Server | Dedicated components · OCPP 1.6J, 2.0.1 and 2.1 | Shared core plus open single-organisation layer |
| Enterprise Server | Enterprise services · OCPP 1.6J, optional 2.0.1 depending on release, no 2.1 runtime support today | Shared core plus tenant-aware operations and integration layer |
Product boundaries