OCPP and fleet charging: a lock-in question

It sits between two things: the charging station in your yard, and the management system in a data centre that monitors it, sets its charging profile, records its sessions and updates its firmware. Before OCPP that link was proprietary, which meant the hardware and the software were sold as one inseparable product. OCPP makes the link an open specification, so that in principle a charger from one manufacturer can be managed by software from another. The Open Charge Alliance publishes the specification and runs a certification program against it. Note what OCPP does not cover: it is not the protocol between the vehicle and the charger — that is ISO 15118 and the connector standards — and it is not the protocol between two charging networks, which is a separate specification again. A depot cares about exactly one of these links, and it is this one.

Three matter in practice. Version 1.6 is the workhorse and remains very widely deployed, generally in the JSON-over-WebSocket variant usually written 1.6J. It introduced smart charging profiles, which is why load management over OCPP is possible at all on 1.6 equipment. Version 2.0.1 is the substantial rewrite: better device management and diagnostics, security built into the specification rather than bolted on, support for ISO 15118 and Plug and Charge, and a more capable smart-charging model. The Alliance has since published version 2.1, which extends smart charging further and adds bidirectional power transfer for vehicle-to-grid and vehicle-to-building use. Versions are not interchangeable — a management system that speaks 2.0.1 does not automatically speak 1.6 and vice versa, though many support both.

Specify 2.0.1 or later if you want Plug and Charge, in-specification security, or the more capable smart-charging model, and if the products that suit your yard support it. Accept 1.6J without embarrassment if the equipment that fits your requirement runs it — a very large amount of working, well-managed depot charging runs on 1.6J and its smart-charging model is sufficient for holding a site under a power limit and shifting load into a tariff window. What you should not do is specify a version and stop there, because the version tells you nothing about how much of it the product implements. Ask instead for the specific messages and functions you depend on: setting a charging profile, remote start and stop, remote reset, firmware update, and the metering values you need at the interval you need them.

Marketing language in this space is unusually slippery, and the difference between these three phrases is the difference between a portable asset and a stranded one.

Here is the mechanism, because it is not obvious. OCPP defines how a charger talks to a management system, and part of the charger's configuration is the address of the management system it talks to. If you cannot change that address, an open protocol has bought you nothing — the charger speaks a standard language to exactly one listener. Locking happens in ordinary, unremarkable ways: the configuration is behind a vendor-only service account, the change requires a firmware image the vendor controls, the procedure exists but carries a per-charger fee, the certificates needed for a secure connection are provisioned only for the original operator, or the network agreement simply prohibits it during the term. None of that is a protocol failure. All of it is contractible, which means you can fix it in advance and cannot fix it afterwards.

Write it into the purchase agreement, not the network agreement, because the network vendor is the counterparty you may one day be leaving. Five elements. One: the equipment is certified to a named OCPP version and profile, evidenced at delivery. Two: the buyer receives an administrative credential capable of changing the management-system endpoint, and the documented procedure for doing so, at acceptance. Three: no per-charger, per-site or transaction fee applies to a change of management system, during or after the term. Four: any certificates, keys or configuration files needed to establish a connection to a different management system are supplied on request. Five: on termination for any reason, the vendor will not remotely disable, degrade or de-provision equipment you own. Ask for all five. A vendor genuinely selling open hardware agrees quickly, and one that hesitates has told you what the product is.

The value of the clause equals the cost of the alternative, which is replacing hardware to change software. Depot Level 2 runs roughly $3,500 to $15,000 per port installed nationally, and while a swap of existing units for new ones on existing infrastructure sits toward the bottom of that spread, a twenty-four port yard is still a substantial unplanned capital event to escape a subscription you no longer want. Against that, the clause costs a paragraph. The other half of the arithmetic is the subscription itself: ten years of a per-port fee is real money on a yard of any size, and your ability to negotiate the renewal depends entirely on whether leaving is possible. Portability is not mainly about switching. It is about what you can say at the renewal meeting.

Three limits worth knowing. It does not standardise the management system's own user interface, reports or APIs, so moving between platforms still means retraining people and rebuilding any integration you built against the old platform's API. It does not guarantee feature parity — a function your current platform offers may have no equivalent elsewhere, whatever the protocol says. And it is not a substitute for local load management: if your site depends on a cloud service to stay inside its electrical limits, then a network outage is an electrical problem, which is a reason to prefer a local energy-management controller for the hard limit and use the cloud for optimisation on top of it. OCPP is a good answer to one specific question. Make sure it is the question you are asking.