Four acronyms in EV charging keep getting tangled in conversations: OCPI, OCPP, OICP, and ISO 15118. Three of them start with “OC”, and all four describe interfaces between computer systems, so people conflate them constantly.
They sit at different layers of the charging stack and solve different problems. Confusing them is like confusing TCP/IP with HTTP: related, but each does its own job, and neither substitutes for the other.
The four-layer model
A complete EV charging session involves communication at four distinct layers:
- Vehicle ↔ Station (the physical and protocol negotiation between the car and the charging point)
- Station ↔ CPO backend (the station reports up to its operator’s servers)
- CPO ↔ eMSP (the CPO and the customer’s service provider exchange business-level info)
- eMSP ↔ Driver (the app, the receipt, the customer experience)
Each layer has its own protocol. The four acronyms map cleanly:
| Layer | Protocol(s) | Example use |
|---|---|---|
| 1. Vehicle ↔ Station | ISO 15118, plus IEC 61851 basic signaling | Plug & Charge, V2G negotiation |
| 2. Station ↔ CPO backend | OCPP | Station boot, transaction reporting, remote start |
| 3. CPO ↔ eMSP | OCPI or OICP | Sharing locations, tariffs, sessions, CDRs |
| 4. eMSP ↔ Driver | App, web, email | App displays, payment receipts |
The four acronyms each live at one of the first three layers. Confusing them collapses the layers.
OCPP: station to backend
What it is: Open Charge Point Protocol. Defines how a charging station talks to its operator’s central management system.
Managed by: Open Charge Alliance (OCA), an industry consortium.
Versions: 1.6 predates the 2.x rewrite and uses a different message set, so a 1.6 station and a 2.x management system cannot talk without a translation layer sitting between them. 2.0.1 restructured the protocol around a device model, security profiles, and Smart Charging. 2.1, published in January 2025, adds bidirectional power flow for V2G, DER coordination, and refined ISO 15118 integration, and it is backward compatible with 2.0.1. The version comparison walks through what actually changed between them.
What flows:
- Boot notifications (“I’m a station with these capabilities”)
- Heartbeat messages (“still alive, still connected”)
- Transaction start/stop events (per-session reporting)
- Status notifications (available, occupied, faulted)
- Remote start/stop commands (CPO triggers a session)
- Smart charging schedules (CPO tells station to limit power)
- Firmware update commands
Where it sits: Between the charging station and the cloud. Always station-to-server. It does not cross between companies.
Common confusion: “Is OCPP what makes roaming work?” No. OCPP is between a station and its own operator. Roaming, meaning CPO to eMSP, is OCPI.
OCPI: CPO to eMSP, peer-to-peer
What it is: Open Charge Point Interface. Defines how a CPO and an eMSP exchange business data.
Managed by: EVRoaming Foundation, an independent nonprofit.
Versions: 2.1.1 predates the formal Hub role. 2.2, published in March 2020, introduced that Hub role along with a Smart Charging module. 2.2.1, published in June 2020, is a bugfix release on top of 2.2, and the two are genuinely distinct versions rather than two names for the same thing, which matters when a partner tells you which one they speak. 2.3.0, published in February 2025, adds AFIR data duties and an extensibility framework. The full OCPI version history covers what changed and when.
What flows (by module):
- Locations: CPO publishes station info; eMSP consumes it to show in the app
- Tariffs: CPO publishes pricing; eMSP consumes it for transparency and billing
- Sessions: live session data from CPO to eMSP
- CDRs: final billing records from CPO to eMSP
- Tokens: eMSP publishes customer identities; CPO validates at session start
- Commands: eMSP triggers actions (start, stop, reserve) via the CPO
Where it sits: Between business backends, either direct (CPO ↔ eMSP) or via a roaming hub.
Common confusion: “Is OCPI just for roaming hubs?” No. OCPI is the protocol whether or not a hub is involved. A hub does not replace OCPI; it terminates an OCPI connection on each side and forwards between them, which is why the hub versus peer-to-peer decision is a commercial and operational one rather than a protocol one.
OICP: CPO to eMSP, hub-centered
What it is: Open InterCharge Protocol. An alternative to OCPI for CPO-to-eMSP exchange, built on a different architectural assumption.
Managed by: Hubject, a commercial company rather than a standards body. Hubject is German-founded and operates in North America as well as Europe, so OICP is not a Europe-only choice.
Versions: Versioned by Hubject rather than by a public standards process, so the specification and its release cadence come from the vendor.
Architecture: OICP assumes a central hub. CPOs and eMSPs connect to the hub, and the hub mediates transactions between them. Where OCPI treats the hub as optional, OICP treats it as structural.
What flows: Conceptually similar to OCPI, covering locations, sessions, billing records, and customer identity. The wire format and the governance are what differ.
Where it sits: The same layer as OCPI, between business backends. The distinguishing factors are the hub-centered architecture and the vendor-led governance.
Common confusion: “Should I implement OCPI or OICP?” That is a partner question, not a technical one. Ask each partner you intend to connect to which protocol and version their integration team publishes, then count how many connections each choice buys you. Supporting both is possible, because they are two separate integrations rather than conflicting ones.
ISO 15118: vehicle to station
What it is: An ISO international standard for vehicle-to-grid communication. Defines the protocol the car and the charging station use to talk to each other over the control pilot line.
Managed by: ISO (International Organization for Standardization).
Versions:
- ISO 15118-2 (2014): the original, supports Plug & Charge
- ISO 15118-20 (2022): adds bidirectional charging (V2G) support and expanded protocol features
The side-by-side on the two editions (coming soon) covers the differences in detail.
What flows:
- Vehicle identification and authentication (Plug & Charge)
- Charging session negotiation (target voltage, current, state of charge)
- Smart charging schedules (vehicle and station agree on a plan)
- V2G bidirectional power flow direction
Encoding: ISO 15118-2 mandates EXI, Efficient XML Interchange (coming soon), rather than plain XML or JSON. The messages are defined as XML schemas but travel as compressed binary, which is why this layer needs a decoder before a packet capture tells you anything.
Where it sits: The lowest layer, between the EV and the station. Below OCPP. It does not involve any backend or business systems.
Common confusion: “Is ISO 15118 a replacement for OCPP?” No. They sit at different layers and solve different problems. ISO 15118 is car-to-station. OCPP is station-to-CPO-backend. Both run inside the same charging session, doing different jobs.
The full session, mapped to protocols
Walk through a charging session and all three appear in order. OICP is interchangeable with OCPI at the relevant step.
sequenceDiagram
participant EV
participant Station
participant CPO as CPO backend
participant eMSP
EV->>Station: ISO 15118: authenticate
Station->>CPO: OCPP: starting, token X
CPO->>eMSP: OCPI Tokens: valid token X?
eMSP-->>CPO: OCPI: authorized
CPO->>Station: OCPP: begin session
Station->>CPO: OCPP: delivering power
CPO->>eMSP: OCPI Sessions: progress
Note over eMSP: App shows driver
Station->>CPO: OCPP: ended, total kWh
CPO->>eMSP: OCPI CDRs: billing record
Note over eMSP: Charges payment methodReading that sequence layer by layer:
- ISO 15118 handles the EV-to-station handshake, and Plug & Charge if both ends support it
- OCPP handles every station-to-CPO message: start, progress updates, end
- OCPI handles every CPO-to-eMSP message: token validation, live session push, final CDR
Each is the right tool for its layer. Trying to do roaming with OCPP, or station control with OCPI, does not work.
When to use which
If you are trying to figure out which protocol applies to a given engineering or business problem:
| Your problem | Protocol |
|---|---|
| Station hardware reports to my CPO platform | OCPP |
| My charging station needs firmware updates | OCPP |
| I need to roam my customers onto another network’s stations | OCPI (or OICP) |
| I want the car to authenticate itself with no app tap and no RFID card | ISO 15118 (Plug & Charge) |
| I want bidirectional charging (vehicle-to-home or vehicle-to-grid) | ISO 15118-20 |
| I want to connect to many partners through one integration | OCPI or OICP via a roaming hub |
| I need to publish current charging station status to many parties | OCPI Locations module |
| I need to send a billing record to another network | OCPI CDRs module (or OICP equivalent) |
A note on OCPI vs OICP
These two are the closest competitors, and the only pair on this list that genuinely overlaps. Both solve the same layer-3 problem, so it is worth being explicit about how they differ:
- OCPI is governance-neutral, managed by an independent nonprofit. Peer-to-peer by default, with hubs optional.
- OICP is governed by Hubject, a commercial entity. Hub-centered by design, with the hub sitting in the middle of every transaction.
Nothing stops one company from running both stacks. The exclusivity is per connection rather than per company: a given partner link speaks one protocol or the other, but the backend behind it can hold integrations for both. If you want to know which protocols a specific network actually exposes, its developer or partner documentation is the source to check, and the answer changes as partnerships change.
What this means in practice
The layer model is not filing-cabinet trivia. It is a triage tool. When a session fails, the useful first question is not “what broke” but “which layer produced the last successful message”, because that single answer narrows the search from four systems to one.
Two of the layers make this easy. OCPP is JSON over WebSocket, and OCPI is JSON over REST, so both are readable in any proxy or log viewer you already run. The vehicle-to-station layer is the exception: ISO 15118-2 mandates EXI, so the traffic that decides whether Plug & Charge worked is compressed binary riding the control pilot line, not an IP link you can tap with the tooling you already have. That inverts the usual instinct. When authentication fails, the roaming interface is the layer you can read, so it is the layer you blame, while the layer that actually decided the outcome is the one you have no log for. Build the decoder before you need it.