OCPP vs ISO 15118: Two Conversations, Two Links, One Charger

The question comes up in almost every technical review: "OCPP is the newer, bigger protocol — won't it eventually replace ISO 15118?"

It will not, and the reason is simple enough to settle the argument in one sentence:

ISO 15118 is the conversation between the vehicle and the charger. OCPP is the conversation between the charger and the cloud.

They do not compete. They do not overlap. They are two different links in one chain — and a commercial charger needs both, the same way a building needs both an internal telephone system and an internet connection.

The two links, precisely

Link 1 — Vehicle to charger: ISO 15118

ISO 15118 defines how an electric vehicle and charging equipment talk to each other over the charging cable itself, using power line communication (PLC). The session follows a defined sequence:

• SLAC — signal level attenuation characterisation, so the two ends find each other on the same cable

• SDP — SECC discovery, so the vehicle locates the charger's communication endpoint

• Session setup and authentication — EIM (card, app, backend token) or PnC (certificate-based)

• Parameter negotiation — how much power, in which direction, under which schedule

• Charge or discharge sequence — including, in the second generation, bidirectional power transfer

The two endpoints have names worth knowing:

• EVCC — the Electric Vehicle Communication Controller, inside the car

• SECC — the Supply Equipment Communication Controller, inside the charger

What ISO 15118 decides: can this vehicle charge here, at what power, authenticated how, and can it send power back?

What it does not decide: pricing policy, roaming, site-level load limits, firmware rollout, or who gets billed.

Link 2 — Charger to cloud: OCPP

OCPP is an application protocol between the charger (or its controller) and a charging station management system (CSMS) — normally JSON over a WebSocket connection. Its message set covers the operating life of the asset:

• BootNotification — the charger announces itself and its capabilities

• Authorize / StartTransaction / StopTransaction — session control and identity

• MeterValues — metering data at defined intervals

• SmartCharging — charging profiles and load limits pushed from the backend

• RemoteStart / RemoteStop — operator intervention

• Firmware and diagnostics — update status, log retrieval, fault reporting

• Reservation, availability, and status notifications — station management

What OCPP decides: who is allowed to charge, how much it costs, how the site's power is shared, and how the operator sees and controls the asset remotely.

What it never decides: how the car and charger negotiate a session. That happens on the cable, before OCPP is involved.

Side by side

Why neither can replace the other

Three scenarios make the separation concrete.

Scenario 1 — a charger with OCPP but no ISO 15118.

It can be billed, monitored and remotely controlled. It cannot do Plug & Charge, cannot read the vehicle's charging parameters digitally, and cannot support bidirectional power transfer. Operationally complete, commercially limited.

Scenario 2 — a charger with ISO 15118 but no OCPP.

The car charges correctly and securely. But nobody can bill it automatically, apply a tariff, cap site load from a central system, or diagnose it remotely. A working charger that cannot be operated as a business.

Scenario 3 — a charger claiming Plug & Charge without the backend side.

PnC needs certificates, and certificates need lifecycle management. On the vehicle-charger link, ISO 15118 handles the exchange. On the charger-cloud link, the certificate plumbing is handled through OCPP 2.0.1's certificate management messages. Missing that second half is why some "PnC-ready" chargers still require a card at the site.

The nuance most comparisons miss: OCPP 2.0.1 and Plug & Charge

Here is where the confusion usually starts. OCPP 2.0.1 does contain functionality tied to Plug & Charge — certificate installation, certificate status, contract-related data. Read quickly, that looks like "OCPP now does ISO 15118."

It does not. What OCPP 2.0.1 provides is the backend management of the certificates that ISO 15118 uses on the cable. One protocol provisions and maintains the credential; the other uses it to authenticate a charging session. Different layers of the same mechanism.

Practical consequence for a specification: if Plug & Charge is in scope, you need both an ISO 15118 PnC-capable charger and a CSMS with certificate management — usually OCPP 2.0.1. Older OCPP 1.6J deployments can still bill and manage a charger perfectly well, but they cannot carry the certificate workflow that PnC depends on.

Where the boundary sits in the hardware

Inside a commercial AC charger, the two links terminate in different components:

• The SECC implements the ISO 15118 stack and the PLC communication with the vehicle.

• The host controller runs the charging logic and typically the OCPP client that talks to the CSMS.

That is why "does your charger support ISO 15118?" and "does your charger support OCPP?" are two separate questions with two separate answers — and why an embedded communication module can add the first without touching the second.

AUPINS supplies that first layer as a component: the AP-SE-B core board is an embedded SECC module for IEC/SAE AC charging equipment, supporting ISO 15118-2 EIM/PnC and ISO 15118-20 EIM/PnC/BPT (V2X). It measures 50mm × 10mm × 30mm, mounts on the AC main control board through a 2.0mm-pitch 18-pin single-row header, provides two UART interfaces plus USB, operates from -40°C to +85°C, and supports OTA firmware upgrade with log storage and retrieval. OCPP remains the charger controller's job — the two layers stay cleanly separated, which is exactly how they should be.

What to write into a specification

Whether you are buying chargers or building them, these five lines close most of the ambiguity:

1. Which ISO 15118 generation and which functions — ISO 15118-2 EIM, ISO 15118-2 PnC, ISO 15118-20 EIM, ISO 15118-20 PnC, ISO 15118-20 BPT (V2X). Name them individually; "ISO 15118 support" is not a specification.

2. Which OCPP version — 1.6J or 2.0.1, and which profiles are implemented (core, smart charging, firmware management, certificate management).

3. Where the SECC sits — integrated into the controller, or a replaceable module. This decides whether the charger can be upgraded later without a platform change.

4. How certificates are provisioned and rotated — the PnC question that most datasheets skip.

5. What diagnostics are retrievable — session logs, error history, and whether they can be exported remotely.

Five myths, briefly

• "OCPP replaces ISO 15118." Different links. Not possible.

• "ISO 15118 is only for DC fast charging." It applies to AC as well — AC chargers are where PnC and V2H deployments are growing fastest.

• "ISO 15118 means Plug & Charge." Not automatically. PnC is one function within the framework, alongside EIM and BPT.

• "OCPP 2.0.1 does Plug & Charge." It manages the certificates. The session authentication happens on the cable, under ISO 15118.

• "A charger with both protocols is automatically V2G-ready." Only if the ISO 15118 generation supports BPT and the power electronics are bidirectional.

FAQ

Does OCPP replace ISO 15118?

No. OCPP connects the charger to the cloud; ISO 15118 connects the vehicle to the charger. They operate on different links and cannot substitute for each other.

Can a charger work with only one of the two?

It can operate, but not as a commercial product. Without OCPP there is no billing or remote management; without ISO 15118 there is no Plug & Charge, no digital negotiation, and no V2G path.

Which OCPP version do I need for Plug & Charge?

The certificate management functionality associated with PnC is part of OCPP 2.0.1. A charger may support PnC on the ISO 15118 side, but the full workflow needs backend certificate handling.

Is OCPP 1.6J obsolete?

No. OCPP 1.6J remains widely deployed and sufficient for many billing and management use cases. The limitation appears when PnC certificate workflows or advanced smart charging features are required.

How do I verify both protocols rather than trusting a datasheet?

Request the protocol matrix in writing (ISO 15118 version and functions, OCPP version and profiles), then test a real session — a PnC session if in scope — and confirm the event appears correctly in the CSMS.

Conclusion

The confusion between OCPP and ISO 15118 survives because both are described as "the charging protocol." They are not the same kind of thing. One is a conversation on a cable; the other is a conversation with a platform.

A charger that speaks only one of them is, quite literally, half a product. Specify both — and specify which version of each — and most of the interoperability surprises disappear before the first unit ships.

CTA：Building or sourcing an AC charger with Plug & Charge or V2G in scope? Request the AP-SE-B specification and integration documentation from AUPINS, and use the five specification lines above to compare suppliers on equal terms.