OCPP, the Open Charge Point Protocol, is an open application protocol for communication between electric vehicle charging stations and a central management system, used to authorize users, start and stop sessions, report energy readings, apply smart-charging limits and update firmware remotely. Among charging standards, it is the dominant vendor-neutral protocol on the operator side of a charger, in contrast to connector standards and vehicle-to-charger protocols.
OCPP is maintained by the Open Charge Alliance, an industry consortium. Its purpose is interoperability: an operator can combine charging hardware from different manufacturers with one back-office platform, and can switch software providers without replacing every charger.
How OCPP connects chargers and back offices
OCPP defines two roles. The charging station (called a charge point in older versions) is the client, and the charging station management system (CSMS), formerly the central system, is the server. In current versions the charger opens a persistent WebSocket connection to the CSMS and both sides exchange JSON messages over it, which works well behind mobile networks and firewalls because the charger initiates the link.
Each message is a call, result or error with a unique identifier, so either side can send requests and match responses. A charger announces itself at startup, sends periodic heartbeats, reports connector status changes and streams meter values during a session. The CSMS, in turn, can start or stop sessions remotely, change configuration, send charging limits and trigger diagnostics.
The table lists representative messages and their roles in normal operation.
| Message | Direction | Purpose |
|---|---|---|
| BootNotification | Charger to CSMS | Registers the charger and its model after startup |
| Heartbeat | Charger to CSMS | Confirms the connection is alive and syncs time |
| StatusNotification | Charger to CSMS | Reports connector states such as available or faulted |
| Authorize | Charger to CSMS | Checks an RFID card or other identifier |
| TransactionEvent | Charger to CSMS | Reports session start, updates and end in 2.0.1 |
| SetChargingProfile | CSMS to charger | Applies power or current limits over time |
| RequestStartTransaction | CSMS to charger | Starts a session remotely, for example from an app |
OCPP versions and their differences
Several OCPP versions are in service at the same time, and the version a charger supports determines what an operator can do with it. OCPP 1.6 remains extremely widespread, while OCPP 2.0.1 introduced a redesigned device model, stronger security and better smart charging; it has also been published as the international standard IEC 63584. OCPP 2.1 extends 2.0.1 with features such as bidirectional energy transfer and improved payment support.
| Version | Transport | Key additions | Practical status |
|---|---|---|---|
| OCPP 1.5 | SOAP over HTTP | Basic remote control and metering | Legacy, being retired |
| OCPP 1.6 | SOAP or JSON over WebSocket | Smart charging profiles, JSON transport | Very widely deployed |
| OCPP 2.0.1 | JSON over WebSocket | Device model, security profiles, ISO 15118 support | Standard choice for new hardware |
| OCPP 2.1 | JSON over WebSocket | Bidirectional charging, local cost calculation | Early adoption |
Versions are not backward compatible on the wire: a CSMS must implement each version it wants to support, and a charger negotiates one version when it connects. Many platforms therefore run 1.6 and 2.0.1 side by side during migration.
OCPP compared with related charging protocols
Charging involves several communication links, and OCPP covers only one of them. Confusing these layers is a frequent cause of misplaced expectations when buying hardware or software.
| Protocol | Link it covers | Main purpose |
|---|---|---|
| OCPP | Charger to operator back office | Control, monitoring, authorization, metering |
| ISO 15118 | Vehicle to charger | Plug and Charge, power negotiation, bidirectional control |
| IEC 61851 | Vehicle to charger, basic signaling | Pilot signal, current limit, safety states |
| OCPI | Operator to e-mobility service provider | Roaming, tariffs, session and billing data exchange |
| OpenADR | Utility or aggregator to operator | Demand response signals |
In practice, a public charging session may involve all of these at once: the car and charger negotiate through ISO 15118 or IEC 61851, the charger reports to the CSMS through OCPP, and the operator exchanges roaming data with the driver’s service provider through OCPI.
Security profiles and smart charging
OCPP defines three security profiles that specify how the charger and CSMS authenticate each other. Choosing a weak profile on a public network is one of the most serious configuration mistakes, because an attacker who controls a charger connection can manipulate sessions or load.
| Profile | Charger authentication | Transport protection | Suitable for |
|---|---|---|---|
| Profile 1 | Basic authentication with password | None | Closed test networks only |
| Profile 2 | Basic authentication with password | TLS with server certificate | Many production deployments |
| Profile 3 | Client certificate | Mutual TLS | Public and high-security networks |
Smart charging through OCPP uses charging profiles: schedules that limit power or current per connector or per site over time. A CSMS can use them for load balancing across chargers sharing one grid connection, for following a tariff, or for responding to grid signals received from an aggregator.
Practical pitfalls
- OCPP compliance is not the same as interoperability; vendors implement optional features differently, so integration testing remains necessary.
- Certification matters: the Open Charge Alliance offers certification programs, and certified products reduce integration surprises.
- Firmware updates can change behavior; operators should test new charger firmware against their CSMS before fleet-wide rollout.
- Unstable mobile connections cause missed messages; chargers should queue transaction data offline and resend it.
- Time synchronization errors distort billing records and should be monitored.
In simple terms
OCPP is the common language that chargers use to talk to their control center. It lets the operator see which chargers are free, start a session when a driver taps a card and record how much energy was delivered for billing.
Because the language is open, any charger that speaks it can be connected to any control software that speaks it too. This works much like a phone that can join any mobile network using the same standard. The result is more choice and less dependence on one supplier.
A practical example
A city parking company operates 120 charging points from two different hardware manufacturers. All chargers connect over mobile data to one CSMS using OCPP 2.0.1 with security profile 3, so each charger authenticates with its own client certificate.
In the evening, when many cars arrive at the same garage, the CSMS sends charging profiles that cap the garage at its 400 kW grid connection and share power between active sessions. When one manufacturer releases new firmware, the company tests it on five chargers first. Later, the company changes software providers without replacing a single charger, because the new platform also supports OCPP.