EV Charging Protocols Explained: OCPP, OCPI, OICP, OpenADR, ISO 15118

EV charging has an alphabet-soup problem. OCPP, OCPI, OICP, OpenADR, ISO 15118, IEC 61851, DIN 70121: they all show up in RFPs and regulations, often in the same sentence, and they are regularly confused with each other. The confusion goes away once you stop thinking of them as competing standards and start thinking of them as answers to different questions. Each protocol covers one link between two parties. Draw the parties, draw the links, and the protocols fall into place.

The five parties

• The vehicle (EV): has a battery management system and, for DC charging, a communication controller that negotiates power with the charger.
• The charging station: the physical hardware with one or more EVSEs and connectors. It meters energy and enforces whatever limits it is given.
• The CSMS (charging station management system, sometimes still called the central system or backend): the charge point operator's software that manages the fleet. See what a CSMS does.
• Other networks: eMSPs (the apps and card issuers drivers use), other CPOs, and roaming hubs.
• The grid side: utilities, aggregators and energy management systems that want to shape when and how much power is drawn.

Link by link

Vehicle to charger: IEC 61851, DIN 70121, ISO 15118

At the lowest level, AC charging in most of the world uses the control pilot defined in IEC 61851-1 (and SAE J1772 in North America): the charger signals the maximum current it can supply by the duty cycle of a PWM signal, and the vehicle signals its state by changing the resistance on the pilot line. That is all basic AC charging needs. There is no identity, no data exchange beyond a current limit.

DC charging needs a real conversation, because the charger is controlling voltage and current into the battery directly. CCS chargers carry that conversation over power-line communication on the pilot wire, using DIN SPEC 70121 (the early protocol most CCS vehicles still support) or ISO 15118-2. ISO 15118-20, the newer edition, adds bidirectional power transfer and a revised security model. ISO 15118 is also where Plug & Charge lives: the vehicle presents a contract certificate, and the charger can authorize the session without a card or app. CHAdeMO and China's GB/T use CAN bus for the equivalent exchange.

The CSMS never speaks ISO 15118 directly. The charger terminates it and relays the parts the CSMS needs over OCPP, which is why OCPP 2.0.1 has messages such as Get15118EVCertificate, GetCertificateStatus and NotifyEVChargingNeeds. The ISO 15118 and Plug & Charge part of our 2.0.1 tutorial walks through that relay in detail.

Charger to CSMS: OCPP

OCPP, published by the Open Charge Alliance, is the protocol between a charging station and its management system. The charger opens a WebSocket to the CSMS and both sides exchange JSON-encoded RPC frames. A CALL from a 1.6-J charger looks like this:

[2, "19223201", "BootNotification", {
  "chargePointVendor": "VendorX",
  "chargePointModel": "DC-150",
  "firmwareVersion": "1.4.2"
}]

OCPP 1.6-J is still the version on most installed hardware; 2.0.1 adds a structured device model, a unified TransactionEvent message and stronger security; 2.1 extends 2.0.1 with bidirectional charging, DER control and payment terminal support. Our OCPP 1.6 vs 2.0 comparison covers the trade-off, and the OCPP 1.6 tutorial and OCPP 2.0.1 tutorial go message by message.

CSMS to other networks: OCPI, OICP and friends

Once a driver with one company's app wants to charge on another company's charger, two backends have to talk. That is roaming, and the protocols here are backend-to-backend REST APIs. OCPI (Open Charge Point Interface), maintained by the EVRoaming Foundation, is the open, peer-to-peer-capable option and the one most new integrations use; version 2.2.1 is the widely deployed release. OICP is Hubject's protocol for its roaming hub. eMIP is used by the GIREVE platform, and OCHP is an older open protocol. They overlap heavily in concept (locations, tokens, sessions, charge detail records) but are not wire-compatible.

GET /ocpi/2.2.1/locations?offset=0&limit=50 HTTP/1.1
Authorization: Token ZXhhbXBsZS10b2tlbi1j
OCPI-from-country-code: US
OCPI-from-party-id: EMS

A common source of confusion: OCPI does not replace OCPP. A CPO runs OCPP to its chargers and OCPI to its roaming partners, and its CSMS translates between the two. See how OCPP events map to OCPI objects and the OCPI tutorial.

Site and grid: OpenADR and IEEE 2030.5

Utilities and aggregators want to reduce or shift charging load when the grid is constrained. OpenADR is the demand-response protocol most often used for that in commercial programs: a utility server publishes events (shed load, price changes) and the CSMS or a site energy manager acts on them. IEEE 2030.5 plays a similar role in some US utility programs, particularly around distributed energy resources. Neither talks to the charger directly. The CSMS receives the signal, decides what it means for each site, and pushes OCPP charging profiles down to the stations. That translation step is where smart charging and load management earns its keep.

One session, every protocol

Follow a roaming DC session through the stack and you touch almost everything above:

1. The driver plugs in. The car and charger negotiate over DIN 70121 or ISO 15118. If both support Plug & Charge, the car presents its contract certificate.
2. The charger sends Authorize (or, in 2.0.1, a TransactionEvent with an idToken) to the CSMS over OCPP.
3. The CSMS does not recognize the token as one of its own, so it checks its cached OCPI token list from the driver's eMSP, or asks the eMSP in real time via the OCPI Tokens module.
4. Charging starts. The charger streams meter values over OCPP; the CSMS pushes session updates to the eMSP over OCPI so the driver's app shows progress.
5. Mid-session, an OpenADR event arrives asking the site to reduce load. The CSMS lowers the limit with an OCPP SetChargingProfile, and the charger renegotiates power with the car over ISO 15118 or DIN 70121.
6. The session ends. The CSMS prices it and sends an OCPI CDR to the eMSP, which bills the driver.

Common misconceptions

• OCPP 2.0.1 does not make Plug & Charge work by itself. It provides the certificate plumbing between charger and CSMS. You also need ISO 15118 support in the charger and car, and a PKI arrangement for contract certificates.
• OCPI is not only for hubs. It works peer-to-peer and through hubs; OICP is tied to Hubject's hub.
• Smart charging is not one protocol. It is a chain: grid signal (OpenADR or similar) to CSMS, CSMS to charger (OCPP charging profiles), charger to car (pilot duty cycle or ISO 15118 limits).
• Supporting a protocol version is not the same as supporting every feature in it. OCPP and OCPI both have optional modules. Ask which ones.

Key takeaways

• Map the parties first, then the links. Each protocol covers one link.
• Vehicle to charger is IEC 61851, DIN 70121, ISO 15118 or CHAdeMO; charger to CSMS is OCPP; CSMS to roaming partners is OCPI or a hub protocol; grid to CSMS is OpenADR or a similar interface.
• The CSMS is the translator in the middle, so most interoperability bugs surface there.

HashTech builds CSMS platforms that speak OCPP 1.6-J and 2.0.1 to chargers and OCPI to roaming partners; more on that here.