The Ultimate Guide to OCPP (Open Charge Point Protocol)

What is OCPP?

The Open Charge Point Protocol (OCPP) is an open, royalty-free standard for communication between an EV charging station (the Charge Point) and a central management system (the CSMS, sometimes called a CPMS). It is maintained by the Open Charge Alliance, a global consortium of hardware and software vendors, and it is the de facto standard for the EV charging industry.

The point of OCPP is interoperability: any OCPP-compliant charger can talk to any OCPP-compliant management system. That decoupling is what lets a Charge Point Operator (CPO) buy hardware from one vendor and run it on software from another, instead of being locked into a single proprietary stack.

Where OCPP connects a charger to its backend, OCPI connects one backend to another for roaming. The two are complementary, and we cover the distinction in OCPI vs OCPP.

How does OCPP work?

OCPP uses a client–server model over a persistent WebSocket connection. The charging station is the client; the CSMS is the server. Because the connection stays open, communication is bidirectional and real time: the charger can report an event the moment it happens, and the backend can push a command without waiting for the charger to poll.

Day to day, that traffic is a set of standard messages, including:

• BootNotification — the charger announces itself and its firmware when it powers up.
• Heartbeat — a periodic "still alive" signal.
• Authorize — checks whether an RFID token or ID is allowed to charge.
• StatusNotification — reports connector state (available, occupied, faulted).
• MeterValues — streams energy and power readings during a session.
• Transaction messages — start, update, and stop a charging session. In 2.0.1 these are unified under TransactionEvent.
• RemoteStart / RemoteStop — let the backend start or stop a session.
• SetChargingProfile — pushes a smart-charging limit or schedule to the charger.

Older OCPP 1.6 deployments can also use a SOAP transport, but JSON over WebSocket (OCPP-J) is the variant everyone builds on today.

OCPP versions: 1.6, 2.0.1, and 2.1

OCPP has evolved through several Open Charge Alliance protocol releases, and three matter for planning today: 1.6, 2.0.1, and 2.1. In short, 1.6 is the deployed default, 2.0.1 is a structural redesign with a device model and security profiles, and 2.1 extends 2.0.1 toward energy coordination. The table below summarises how they differ.

OCPP 1.6

Published in 2015, OCPP 1.6 is still the most widely deployed version in the field. It covers the essentials: remote start/stop, basic smart charging, firmware updates, and local authorization lists. It is well understood and broadly supported, which is exactly why so much installed hardware still runs it — and why you should assume 1.6 chargers will be on your network for years.

OCPP 2.0.1

OCPP 2.0.1 (published in 2020) is not a cosmetic update. As set out in the OCPP protocol overview, it restructures several core ideas:

• Device model — chargers are described with a three-layer hierarchy of Charging Station → EVSE → Connector, which fits modern multi-outlet hardware far better than 1.6's flat connector list. See the OCPP 2.0.1 device model explained.
• Security — formal security profiles for TLS and authentication. See OCPP security profiles explained.
• Smart charging — richer charging profiles and clearer setpoint handling. See smart charging with OCPP and the breakdown of charging profile purposes 0–3.
• Plug & Charge — support for ISO 15118, so a car can authenticate over the cable without an RFID card.

Because the payload schemas and transaction logic changed, moving from 1.6 to 2.0.1 is a genuine migration. We cover what actually changed in the OCPP 2.0.1 deep dive, and how to sequence the move in the OCPP 1.6 to 2.0.1 migration guide.

OCPP 2.1

OCPP 2.1, the most recent release from the Open Charge Alliance, extends 2.0.1 rather than replacing it. Its headline additions are bidirectional power transfer (V2G), more advanced smart-charging and local energy management, and tighter alignment with ISO 15118-20. Most operators do not need to act on 2.1 yet, but it signals where the protocol is heading: energy coordination, not just session control.

What can you do with OCPP?

OCPP is what turns a charger from a standalone appliance into a managed, remotely operable asset. With it, an operator can:

• Monitor and control chargers remotely — see live status, start or stop sessions, reset a unit, or unlock a connector without a site visit.
• Apply smart charging — cap power, shape load across a site, and respond to grid or tariff signals instead of charging everything at full power at once.
• Update firmware and pull diagnostics — keep a fleet current and troubleshoot from the backend.
• Authenticate sessions — validate RFID tokens, app IDs, or, on 2.0.1, ISO 15118 contracts.
• Secure the connection — enforce TLS and authentication so the charger-to-backend link cannot be trivially spoofed.

Where OCPP fits in a charging stack

OCPP is one layer of an operator's architecture, not the whole thing. A charger speaks OCPP "south-bound" to a CSMS. The CSMS then handles users, billing, and — through OCPI — roaming with other networks.

Two architectural questions come up constantly:

• Gateway or full platform? You don't always have to replace your management system to modernise. An OCPP gateway can normalise charger connectivity in front of your existing backend, which is often the safer first step — see when to add an OCPP gateway before replacing your CPMS.
• One backend or several? Larger operators frequently run more than one CSMS across acquired or partner networks. Multi-CPMS orchestration covers running several backends on the same physical network, and the legacy CSMS migration plan covers moving off an old system without a risky charger-by-charger cutover.

If you are evaluating platforms against these realities, the practical buyer guide to OCPP platforms turns it into a scorecard.

Why does OCPP matter for CPOs?

OCPP matters because it keeps the EV charging market open. Without a shared protocol, every charger would only work with its maker's software, and operators would be locked into whatever roadmap, pricing, and support that single vendor offered.

With OCPP, the leverage shifts back to the operator:

• No vendor lock-in — choose hardware and software independently, and change one without ripping out the other.
• Interoperability — a mixed fleet of chargers from different manufacturers runs under one management system.
• A competitive market — new entrants can build compliant hardware or software and compete on merit, which keeps prices and innovation moving.

That freedom is the whole reason OCPP exists, and it is why "is it really OCPP-compliant, and how well?" is one of the most important questions to ask any charger or platform vendor before you commit.