By RIOD Engineering · April 10, 2026
OCPP 1.6J and 2.0.1 Backend Development
The OCPP central system is the WebSocket-facing service inside a Charging Management System. It accepts charger connections, handles the message flow that opens and closes sessions, and pushes remote commands back down. Building one that survives real networks is a very different exercise from building one that passes a demo.
This is a practical guide to what an OCPP backend actually needs beyond the specification, and how the choices between 1.6J and 2.0.1 play out in production.
What an OCPP central system does
A central system holds a persistent WebSocket connection to every charger in the network. It receives BootNotification on charger startup, responds with heartbeat interval and configuration, and thereafter processes every StatusNotification, MeterValues, StartTransaction and StopTransaction message the charger sends. It also initiates messages, RemoteStartTransaction from a driver app, ChangeConfiguration for tariff pushes, Reset for recovery, UpdateFirmware for OTA campaigns.
The trick is scale: production networks routinely have 5,000+ concurrent WebSocket connections per node. Message rates during peak charging hours run to millions per day. Every one of them has to be persisted, correlated to a session, billed correctly and made available to operations dashboards in near-real-time.
1.6J vs 2.0.1: what actually matters
1.6J is JSON over WebSocket with optional profiles (Smart Charging, Remote Trigger, Firmware Management). It is the dominant installed base. 2.0.1 adds a formal device model (variables and components), richer security profiles including TLS with certificate management, ISO 15118 support and improved smart charging.
Practically: build for both. Detect the OCPP version during WebSocket subprotocol negotiation (the version is agreed at connection setup, before OCPP messages start flowing), route to the appropriate handler chain, and preserve message-level compatibility so a single operator dashboard works across generations. Every RIOD-built CMS supports 1.6J and 2.0.1 side-by-side.
Common implementation mistakes
Treating the OCPP server as stateless. It isn't. Session state, meter values, offline-queued transactions and firmware update campaigns are all long-lived states that break under naive load balancing. Sticky sessions per charger are the minimum; cohort-based sharding is the answer at scale.
Ignoring MeterValues timestamps from offline queues. When a charger comes back online after a network drop and replays its journal, timestamps are in the past. Naive CSMS reject them; correct CSMS accept and reconcile at billing time.
Compliance testing only against OCTT and not real chargers. OCTT is necessary but not sufficient. Real chargers do surprising things, RCD self-tests during a session, mid-session firmware announcements, timestamps in different timezones. Interop testing in a lab against real EVSE catches what OCTT cannot.
Key takeaways
- OCPP version negotiation happens during WebSocket subprotocol negotiation, before OCPP messages start flowing.
- Backend reliability depends on connection state handling, message queueing on drops, and billing reconciliation on replay.
- Interoperability testing against real chargers and real CMS platforms catches what OCTT cannot.
Production checklist
- WebSocket scaling with per-charger sticky routing or cohort sharding
- Persistent, replay-safe message journaling
- Idempotent transaction handling at the CMS
- Charger clock correction on BootNotification and Heartbeat responses
- Firmware update campaign state machine with automatic rollback
Read Our Next Article
Custom CMS vs Off-the-Shelf: The Honest Break-Even Math
How to Migrate Your Charging Network to a New CMS
OCPP Firmware Stack for AC and DC Chargers
OCPI and Roaming Integration for CMS Platforms
White-Label CMS for Charger OEMs and CPOs
UPI vs RFID vs App: Charging Payment Methods Compared
Deploying EV charging?
Talk to our team about your project. We design, supply, and manage EV charging infrastructure across India.