Four acronyms in EV charging keep getting tangled in conversations: OCPI, OCPP, OICP, and ISO 15118. They sound similar (three start with “OC”), they all relate to “open” charging, and they all involve interfaces between computer systems. People conflate them constantly.
But they sit at different layers of the EV charging stack and solve different problems. Confusing them is like confusing TCP/IP with HTTP with REST — they’re related, but each does its own job.
This article is the side-by-side comparison.
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(s). The four acronyms map cleanly:
| Layer | Protocol(s) | Example use |
|---|---|---|
| 1. Vehicle ↔ Station | ISO 15118, basic ISO 15118-2/-20 | 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 (still widely deployed across legacy fleets), 2.0.1 (production mainstream — security profiles + Smart Charging), 2.1 (released June 2024 — adds enhanced device model and ISO 15118 integration; adoption growing through 2025-2026).
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. Doesn’t cross between companies.
Common confusion: “Is OCPP what makes roaming work?” No — OCPP is between a station and its own operator. Roaming (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 (legacy, still deployed), 2.2 (Mar 2020 — first version with formal Hub role + Smart Charging module; some implementations still on this), 2.2.1 (Jun 2020 — bugfix on 2.2; current mainstream), 2.3.0 (Feb 2025 — AFIR + extensibility framework). See the full OCPI version history for what changed and when.
What flows (by module):
- Locations — CPO publishes station info; eMSP consumes to show in app
- Tariffs — CPO publishes pricing; eMSP consumes 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 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 you use a hub or not. A hub like Hubject also speaks OCPI to its connected partners.
OICP — CPO to eMSP (hub-centered)
What it is: Open InterCharge Protocol. An alternative to OCPI for CPO-eMSP exchange, with a different architectural assumption.
Managed by: Hubject (a German company that operates the largest commercial roaming hub in Europe).
Versions: Various (proprietary versioning).
Architecture: OICP assumes a central hub. CPOs and eMSPs connect to the hub; the hub mediates all transactions. Unlike OCPI’s peer-to-peer flexibility, OICP is hub-centered by design.
What flows: Conceptually similar to OCPI — locations, sessions, billing records, customer identity. Different wire format and different governance.
Where it sits: Same layer as OCPI — between business backends. The distinguishing factor is the hub-centered architecture and the proprietary governance.
Common confusion: “Should I implement OCPI or OICP?” Depends on your roaming partners. Many production networks support both. OCPI has broader adoption in 2026; OICP retains significant market share in Europe through Hubject.
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.
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, expanded protocol features
What flows:
- Vehicle identification and authentication (Plug & Charge)
- Charging session negotiation (target voltage, current, SOC)
- Smart charging schedules (vehicle and station agree on a plan)
- V2G bidirectional power flow direction
Where it sits: The lowest layer — between the EV and the station. Below OCPP. Doesn’t involve any backend or business systems.
Common confusion: “Is ISO 15118 a replacement for OCPP?” No — they’re at different layers and solve different problems. ISO 15118 is car-to-station. OCPP is station-to-CPO-backend. Both exist in the same charging session, doing different jobs.
The full session, mapped to protocols
Walk through a real charging session and see all three in action (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: identify + authenticate
Station->>CPO: OCPP: session starting, token X
CPO->>eMSP: OCPI Tokens: validate token X?
eMSP-->>CPO: OCPI: authorized
CPO->>Station: OCPP: begin session
Station->>CPO: OCPP: delivering 47 kW
CPO->>eMSP: OCPI Sessions: live progress
Note over eMSP: App shows driver
Station->>CPO: OCPP: session ended, 32.4 kWh
CPO->>eMSP: OCPI CDRs: final billing record
Note over eMSP: Charges payment methodThree protocols, four layers, one seamless experience for the driver:
- ISO 15118 handles the EV-to-station handshake (and Plug & Charge if supported)
- 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, doesn’t work.
When to use which
If you’re 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 my customer to scan a QR code and start charging without an app | ISO 15118 (Plug & Charge) |
| I want bidirectional charging (vehicle-to-home or vehicle-to-grid) | ISO 15118-20 |
| I want to connect to dozens of partners with 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. Both solve the same layer-3 problem. Worth being explicit:
- OCPI is governance-neutral (managed by an independent nonprofit). Peer-to-peer by default; hubs are optional.
- OICP is governed by Hubject, a commercial entity. Hub-centered by design; Hubject sits in the middle of every transaction.
Different networks have made different choices. Many large CPOs support both — implementing OCPI for some partners and OICP for connections through Hubject. The protocols aren’t mutually exclusive at the company level, just at the connection level.
In 2026 the trend is OCPI’s share growing relative to OICP’s, but OICP retains substantial European market presence.
Three things to take from this
-
Different protocols at different layers. OCPP = station to backend. OCPI/OICP = backend to backend. ISO 15118 = vehicle to station.
-
They’re not in competition with each other at most layers. They’re complementary. A single charging session uses three of them simultaneously.
-
The “OCPI vs OICP” choice is real — and the only place where two protocols genuinely overlap. Most other “which protocol” questions resolve cleanly to one answer.
If you’re building anything in EV charging, knowing which protocol handles which layer is the foundation. Once that clicks, the rest of the standards landscape becomes navigable.