Skip to content
← Blog

OCPP joins OT Fabric: go-ocpp, ocppctl and five reference stacks

OCPP is the protocol between EV charging stations and the systems that run them. go-ocpp implements 1.6J, 2.0.1 and 2.1 in both roles, ocppctl puts it on the command line, and ocpp-interop tests both against five independent implementations.

go-ocpp in the middle, connected to the reference stations of The Mobility House, ChargeTimeEU, ocpp-go and EVerest libocpp on the left and the reference CSMSs of The Mobility House, ChargeTimeEU, ocpp-go and CitrineOS on the right. 1458 scenarios pass, none fails.

Plug in at a public charger in Europe or North America, and the station very likely checks with a server over OCPP, the Open Charge Point Protocol, before any power flows. Published by the Open Charge Alliance, it is the protocol between a charging station and the CSMS, the management system of a charge point operator: how a station boots and authorizes a card, how a session is metered and billed, how firmware is updated, and how power is limited when a site reaches its grid connection limit. Chargers are among the largest flexible loads on the low-voltage grid, so OCPP is where EV charging meets energy management.

Today OCPP becomes the ninth protocol in OT Fabric, with the same three pieces as every other: a library, a command-line tool and an interoperability suite.

Why OCPP, and why now

OT Fabric is about connecting the devices that run energy and infrastructure, and the charger is fast becoming one of the most important of them:

  • Charging is energy management. A depot, a car park or an office with twenty chargers rarely has the grid capacity for twenty full-power sessions. OCPP’s smart charging profiles let the CSMS share that capacity, follow a tariff or the solar production on site, and respond when the utility asks for less. That is the chain OT Fabric is built for: OpenADR from the utility or aggregator, OCPP to the chargers, and SunSpec or Modbus to the meter, battery and inverter on the same site.
  • Three versions in the field at once. OCPP 1.6J runs on most installed chargers. 2.0.1 is a redesign that is not backward-compatible with it, adding a device model, security profiles and ISO 15118 certificate handling, and it is also published as IEC 63584. 2.1 extends 2.0.1 with bidirectional charging, DER control and local cost calculation. A CSMS has to serve all three, and a station vendor moving to 2.x still has a 1.6 fleet to support.
  • From preference to requirement. Funding programmes now write OCPP into their rules: the US NEVI standards for federally funded chargers, for example, require OCPP 2.0.1.

The open-source field is broad, and our research for the ecosystem map found more than twenty implementations. Few of them cover both the station and the CSMS side across all three versions, fewer do that under a permissive licence, and several well-known projects are archived. go-ocpp adds an MIT-licensed library for both roles and all three versions, with every message validated, tested against five of the established stacks.

go-ocpp

go-ocpp implements OCPP-J, OCPP over WebSocket with JSON, for both ends of the connection: the charging station and the CSMS, on one RPC engine, with CALLs from either side.

  • Three versions: OCPP 1.6J with the Security Whitepaper extensions (39 actions), 2.0.1 (64) and 2.1 (91), including the SEND and CALLRESULTERROR message types that 2.1 adds. One CSMS endpoint can serve all three.
  • Every message typed and validated. The packages are generated from the Open Charge Alliance’s JSON schemas, and validation is always on: every request before it is sent, every response when it arrives, every incoming request before a handler sees it.
  • Security profiles 1 to 3, with authentication before the WebSocket upgrade and TLS verification that cannot be turned off.
  • Built to run in production: reconnection with the OCPP back-off, keepalive, limits on stations, message size, queues and rate, graceful shutdown, slog logging, metrics hooks and tracing interceptors.
  • One dependency, a WebSocket library.

It is a protocol library, not a charging management system. Charging behaviour, authorization policy and billing stay in your handlers, and nine example programs show how: a small CSMS for all three versions, a station simulator, smart charging, a device model, remote management and all three security profiles.

ocppctl

ocppctl puts go-ocpp on the command line, for the people who build and run charging infrastructure.

Terminal window
# Which version does this CSMS pick, over which TLS, with which certificate?
ocppctl client probe --url wss://csms.example.com/ocpp/CS001 --password-file pw.txt
# A hundred simulated stations for fifteen minutes, as JSON Lines
ocppctl client run --url 'wss://csms.example.com/ocpp/LOAD{001..100}' --stagger 50ms --duration 15m --format json
# A CSMS on your laptop for station and firmware development
ocppctl server start --insecure-transport --no-auth

It sends any message with schema validation in both directions, runs YAML scenarios with expectations in CI, serves a CSMS that answers stations from a model, and validates payloads and decodes frames offline. Output is text, a table or JSON, with stable exit codes. The ocppctl guide walks through it.

Tested against five independent stacks

ocpp-interop packages five independent OCPP implementations as containers behind one contract: The Mobility House ocpp (Python), ChargeTimeEU Java-OCA-OCPP (Java), lorenzodonini/ocpp-go (Go), EVerest libocpp (C++, a charging station) and CitrineOS (TypeScript, a CSMS). Its fixtures have a sample of every action of every version.

go-ocpp is tested in both roles against all five: 1458 scenarios pass and none fails, with TLS and compression, and OCPP 2.1 against three independent implementations. ocppctl runs the same references and passes 1154 of 1218 exchanges; every other result is explained in its known issues. The references were also tested against each other, and the defects that turned up in them are recorded with the line of upstream code that causes each one. The details are in Testing and interop.

Built with AI agents

Like the rest of OT Fabric, the OCPP projects are built by people and AI agents together, and each repository’s AGENTS.md holds both to the same rules: never invent protocol behaviour, never mark an action implemented because its types compile, never skip or weaken a failing test, and never report an unsupported interop scenario as passed. The tests, the interop results and the list of known issues are public, so you can judge the result yourself.

Who else implements OCPP

The ecosystem map now covers OCPP: the stacks we interop test against, and the other open-source and commercial implementations, with language, licence, roles and latest release.

157 implementations · 11 protocolsExplore OCPP on the ecosystem mapFilter by language, licence and activity, then jump straight to the source.

Start with the OCPP overview, or go get github.com/otfabric/go-ocpp.