OCPP, OCPI, and ISO 15118: What EV Charging Interoperability Means

The three names describe different communication boundaries. OCPP connects charging stations to charging-management software; OCPI commonly exchanges information between charging-network businesses; ISO 15118 covers high-level communication between an electric vehicle and charging equipment. A building may need one, several, or none of these interfaces. A standard’s existence does not show that a particular car, charger, network, meter, or payment service will work with another.

The protocols serve different connections

Protocol	Main communication boundary	What it may help a building do	What the name alone does not prove
OCPP, the Open Charge Point Protocol	Charging station to its charge station management system (CSMS)	Report status and transactions, receive management commands, and use supported smart-charging or security functions.	That the exact charger and CSMS implement the same version, optional features, certificate scope, or building workflow.
OCPI, the Open Charge Point Interface	Commonly charge point operators and e-mobility service providers	Exchange roaming-related location, tariff, token, session, and charge-detail information when the parties implement the needed modules.	That a residents-only building needs roaming, or that its billing, payment, or network partners support the desired exchange.
ISO 15118	Vehicle and EV supply equipment communication controllers	Support selected vehicle-to-equipment functions such as digital identification, Plug & Charge, or bidirectional use when the vehicle, charger, and service are designed for them.	That a specific vehicle, station, certificate service, or building system supports those functions or has been approved for power export.

Think of these as links between parts of a wider system rather than as three competing charger features. For example, Plug & Charge may depend on a vehicle and station exchanging credentials, an authorization service trusting them, and the charging network correctly recording the session. OCPP, OCPI, and ISO 15118 may each play a part, but they do not collapse those parties into one guaranteed connection.

Ask for an implementation, not a label

Ask the seller to state, in writing:

• the exact protocol version and edition for each station and software service;
• which required profiles and features are implemented, and which are optional or unavailable;
• the firmware and backend versions covered by any certificate or test report;
• whether the exact station-to-CSMS pairing has been tested by an independent lab and again in the proposed configuration;
• which party operates each identity, roaming, tariff, session, meter, and payment interface;
• what data moves across the interface and which party can export it.

OCPP’s versions are not interchangeable by name. The Open Charge Alliance says OCPP 1.6 and 2.0.1 are not compatible, while 2.1 builds on 2.0.1 and retains its application logic. Its current download index lists OCPP 2.1 Edition 2 and OCPP 2.0.1 Edition 4, each with June 2026 errata. Ask which edition and errata the vendor used rather than assuming that “supports OCPP 2” is enough.

Certification is useful evidence with a boundary. As of 25 September 2026, OCA’s certification program covers OCPP 1.6 and 2.0.1; its FAQ says 2.1 certification details are still to be announced. A certificate can show that an implementation was tested against specified requirements and profiles. It does not certify the whole apartment system or automatically demonstrate every optional feature, EV-to-charger journey, payment path, or supplier migration.

Test the whole resident journey

A contract should name the actual system behavior that matters. Ask for a witnessed acceptance test using the selected station model, firmware, CSMS, network connection, and resident access method. Include:

1. A resident starts and ends a session and receives the expected status and receipt.
2. A second compatible account or vehicle is authorized using the intended method.
3. A station reports its state and an agreed session record to the right building or network system.
4. A load limit or scheduled control request reaches the equipment and its effect is logged.
5. A loss of internet or backend service produces the agreed local behavior, safe stop, or fallback.
6. A software restart or certificate change leaves the approved resident journey usable.
7. If roaming or Plug & Charge is required, the test follows authorization through the vehicle, station, backend, service provider, and final session record.
8. If a supplier change is likely, a test station connects to the proposed replacement CSMS and returns usable records.

ISO 15118-21:2025 defines conformance tests for communication controllers implementing ISO 15118-20. ISO currently lists the published edition as “to be revised.” The tests cover protocol capabilities and behavior, but not performance, robustness, reliability, physical implementation, or power flow. Confirm the current edition and the exact controller tested when reviewing a supplier’s report.

CharIN’s 2025 Testival reports describe composed EV, charging-station, backend, Plug & Charge, and roaming tests, including session authorization and charge-detail-record reporting. Use these as examples when designing a building’s own test; they are not an apartment-specific requirement, a universal test suite, or product certification.

Choose by the service promise

A building that needs residents to identify themselves and see their session history may not need public roaming. A site that deliberately serves visitors or the public may need additional access, payment, data, and regulatory checks. A project considering managed charging needs a defined control interface and collaboration with its electrical and energy teams. A project considering bidirectional charging needs separate vehicle, EVSE, building, grid-interconnection, and safety review.

Use the network requirements checklist to define the system, and the privacy checklist and vendor exit guide for cross-system duties. A standard is a starting specification; compatibility is a result to demonstrate.

Checked: 25 September 2026. Published protocol versions, certification scopes, and errata change; verify current documents and exact product evidence before procurement.