OCPP: talking to charging stations

OCPP (Open Charge Point Protocol), from the Open Charge Alliance, is the open standard between a charging station and the back office that manages it. It is what lets an operator run charging stations from many manufacturers with one system. In modern use it runs as JSON messages over a WebSocket that the station opens to the back office, so commands flow both ways over one long-lived connection.

The relationship

One side is the charging station, the other is the central management system. The names changed between versions, but the shape did not: the station connects out to the back office, reports what it is doing, and accepts instructions.

Versions

  • 1.6J. The workhorse, deployed almost everywhere. Roles are Charge Point and Central System. Its device model is a charging station with one or more connectors, numbered from 1, where connector 0 means the whole unit. There is no separate EVSE concept. Around 28 messages, grouped into feature profiles (Core, Smart Charging, Firmware, Local Auth List, Reservation, Remote Trigger). The J means the JSON-over-WebSocket variant.
  • 2.0.1. A larger redesign. Roles are Charging Station and CSMS (Charging Station Management System). It introduces a three-level device model, station to EVSE to connector, where evseId=0 addresses the whole station. Transactions are reported through a single richer TransactionEvent message. It adds a real security profile, a queryable device model, and support for ISO 15118 Plug & Charge. Around 64 messages, grouped into functional blocks.
  • 2.1. Same roles and device model as 2.0.1, with about 27 new messages on top for where the grid is heading: DER control (managing distributed energy resources), V2X / bidirectional charging (energy flowing back out of the car), richer tariff and cost, battery swap, periodic event streams, and dynamic charging.

If you see StartTransaction and idTag, that is 1.6. If you see TransactionEvent and evseId, that is 2.x.

The message flows that matter

  • Boot and heartbeat. On connect the station sends BootNotification (who am I, what firmware), then periodic heartbeats so the back office knows it is alive.
  • Status. The station reports connector or EVSE state (available, occupied, faulted) as it changes.
  • Authorisation. Before or as a charge starts, the station checks a presented token with the back office (Authorize).
  • Transaction and metering. A transaction opens, meter values stream during the charge, and the transaction closes with final readings. In 1.6 this is StartTransaction / MeterValues / StopTransaction; in 2.x it is TransactionEvent plus meter values.
  • Remote control. The back office can start, stop or unlock a charge remotely (RemoteStartTransaction in 1.6, RequestStartTransaction in 2.x).
  • Smart charging. The back office sends charging profiles that cap or shape power over time (SetChargingProfile), to respect grid limits or a site's capacity.
  • Firmware and diagnostics. The back office can push firmware updates and pull logs and diagnostics.
  • Security. 2.x adds authenticated, certificate-based connections and secure firmware, rather than relying on the network alone.

At Road

Road runs the back-office side of OCPP at scale: an OCPP gateway and CSMS that terminate these connections, authorise charges, record transactions and apply smart-charging limits, across a large fleet of stations and manufacturers. The protocol details above are the standard; how Road implements them is covered in the platform and stack docs.