ISO 15118 and OCPP are two protocols that exist at different layers but cooperate to deliver real EV charging experiences. ISO 15118 handles vehicle-to-charger communication. OCPP handles charger-to-back-end communication. The charger sits between them, translating and coordinating.
For experiences like Plug & Charge, smart charging, and contract certificate management, the two protocols must work together. This article explains how they integrate, what the charger’s bridging role looks like, and how OCPP 1.6 and 2.0.1 differ in their ISO 15118 support. If you need the fundamentals first, see what is ISO 15118 (coming soon) and what is OCPP.
The layers
A quick reminder of where each protocol lives:
[ Vehicle ] <--- ISO 15118 ---> [ Charger ] <--- OCPP ---> [ CSMS ] <--- OCPI ---> [ eMSP ]- ISO 15118: vehicle to charger.
- OCPP: charger to CSMS.
- OCPI: CSMS to eMSP.
The charger is the bridge between ISO 15118 (the local vehicle conversation) and OCPP (the back-end conversation). For Plug & Charge to work, the charger has to coordinate both sides.
The PnC integration flow
A simplified flow showing the OCPP/ISO 15118 cooperation during a PnC session:
- Vehicle plugs in. ISO 15118 communication starts on the pilot pin.
- Vehicle initiates PnC. Sends PaymentDetailsReq with its contract certificate.
- Charger validates certificate locally (signature, chain, revocation).
- Charger sends OCPP Authorize to CSMS with the certificate’s EMAID and optionally the certificate itself.
- CSMS validates with the eMSP via OCPI Token query.
- CSMS returns OCPP AuthorizeResponse to the charger with Accepted or Rejected.
- Charger responds to vehicle via ISO 15118 PaymentDetailsRes.
- Charging negotiation continues between vehicle and charger via ISO 15118.
- Charger sends OCPP TransactionEvent (Started) to CSMS when session begins.
- During session: OCPP MeterValues / TransactionEvent (Updated) flow to CSMS; ISO 15118 ChargingStatus flows between vehicle and charger.
- Session ends. OCPP TransactionEvent (Ended); ISO 15118 SessionStop.
The charger is constantly translating between the two protocols. ISO 15118 messages don’t go directly to the CSMS; they’re processed by the charger and the relevant information is conveyed via OCPP. For the vehicle-side view of these same steps, see the Plug & Charge end-to-end walkthrough (coming soon).
The same cooperation, shown as who talks to whom during authorization:
sequenceDiagram
participant V as Vehicle
participant C as Charger
participant S as CSMS
participant E as eMSP
V->>C: PaymentDetailsReq (ISO 15118)
C->>C: Validate cert locally
C->>S: Authorize + EMAID (OCPP)
S->>E: Token query (OCPI)
E-->>S: Accepted / Rejected
S-->>C: AuthorizeResponse (OCPP)
C-->>V: PaymentDetailsRes (ISO 15118)OCPP 1.6 ISO 15118 integration: workable but awkward
OCPP 1.6 has limited ISO 15118 support. The Security extension (Edition 2, 2018) added some PnC-related features, but the integration is uneven.
What works in 1.6:
- Charger can include certificate-based authentication in Authorize messages.
- CSMS can recognize ISO 15118 contract IDs (EMAIDs) and validate them via eMSPs.
- Basic PnC flows are possible.
What’s awkward in 1.6:
- No standard way for CSMS to install contract certificates on the vehicle via OCPP. Workarounds exist but are vendor-specific.
- The data model for certificates is bolted onto existing messages rather than designed-in.
- Limited support for ISO 15118-specific events (certificate near-expiry warnings, contract renewals).
- The charger has to handle most ISO 15118 complexity locally with minimal CSMS visibility.
In practice, OCPP 1.6 PnC deployments require:
- Tight vendor-CSMS coordination on the bolted-on extensions.
- Bilateral agreements on certificate flows.
- Acceptance that some operations (certificate install, renewal) are not OCPP-mediated.
It works, but it’s clunky. Modern PnC deployments increasingly target OCPP 2.0.1 specifically because of the cleaner integration. For the wider back-office picture, the OCPI Tokens module is where the EMAID ultimately gets resolved to an eMSP account.
OCPP 2.0.1 ISO 15118 integration: native
OCPP 2.0.1 was designed with ISO 15118 in mind. The integration is much cleaner.
Native features:
Certificate management messages.
- InstallCertificate / DeleteCertificate / GetInstalledCertificateIds for managing certificates on the charger.
- The CSMS can push contract certificates to chargers, and the charger handles installation on the vehicle via ISO 15118.
Contract certificate flows.
- Get15118EVCertificate — the charger can request a contract certificate from the CSMS during a session.
- The CSMS can mediate certificate issuance between the eMSP, the CA, and the vehicle.
EMAID handling.
- The idToken type “ISO15118EmaId” tells the CSMS that this identifier is from a contract certificate. The CSMS routes to the appropriate eMSP.
Authorize semantics.
- AuthorizeRequest can include the full certificate chain, allowing the CSMS to do its own validation rather than relying on the charger.
- AuthorizeResponse includes detailed status (cert valid, cert revoked, cert expired, contract invalid).
Cert revocation handling.
- The CSMS can push revocation information to chargers.
ISO 15118 events.
- The charger can notify the CSMS of ISO 15118-related events (certificate near expiration, contract renewal needed, etc.).
This makes PnC deployment much more manageable in OCPP 2.0.1 than in 1.6. The CSMS has visibility into the certificate lifecycle and can orchestrate cleanly.
Contract certificate installation via OCPP 2.0.1
A concrete example of OCPP 2.0.1 native integration.
A user signs up with an eMSP. The eMSP creates a contract certificate but the vehicle doesn’t have it yet. Next time the user visits a PnC-capable charger:
- Vehicle plugs in. ISO 15118 starts.
- Vehicle indicates it doesn’t have a contract certificate for this trust root but is willing to receive one.
- Charger sends OCPP Get15118EVCertificate to CSMS, asking for a contract certificate for this vehicle.
- CSMS contacts the eMSP via OCPI (or internally if same operator), retrieves the contract certificate.
- CSMS returns the certificate via OCPP response.
- Charger pushes the certificate to the vehicle via ISO 15118 CertificateInstallation messages.
- Vehicle stores the certificate.
- Subsequent sessions can use PnC with this certificate.
The entire flow is orchestrated through OCPP/OCPI back-ends with the charger as the ISO 15118 translator. Clean and well-defined.
In OCPP 1.6, this same operation requires vendor-specific extensions or out-of-band processes.
Smart charging integration
ISO 15118 supports charging schedule negotiation. OCPP supports SetChargingProfile. The two need to align.
A typical smart-charging session:
- CSMS pushes a ChargingProfile to the charger via OCPP SetChargingProfile.
- Vehicle plugs in.
- During ISO 15118 ChargeParameterDiscoveryReq, vehicle indicates its energy needs.
- Charger computes a charging schedule based on the OCPP profile and the vehicle’s constraints.
- Charger sends the schedule to vehicle via ISO 15118 ChargeParameterDiscoveryRes.
- Vehicle accepts (or counter-proposes).
- Charging proceeds within the schedule.
The OCPP profile is the higher-level instruction. The ISO 15118 schedule is the detailed schedule sent to the vehicle. The charger translates between them.
For complex smart charging (V2G, dynamic rate adjustment, demand response), the integration gets richer. OCPP 2.0.1 + ISO 15118-20 are designed to handle this together.
The charger’s role as bridge
A few specifics about what the charger does as the bridge.
Certificate validation. The charger validates ISO 15118 contract certificates locally — chain validity, expiration, etc. It optionally forwards to the CSMS for additional validation. The trust hierarchy behind this is covered in contract certificates and PKI (coming soon).
EMAID extraction. The charger pulls the EMAID from the contract certificate and uses it as the idToken in OCPP Authorize.
Schedule translation. The charger receives OCPP ChargingProfile and translates the limits/schedule into ISO 15118 schedule format for the vehicle.
Event correlation. When the vehicle reports a state change via ISO 15118 (e.g. SuspendedEV), the charger reports it via OCPP StatusNotification or TransactionEvent.
Error reporting. When ISO 15118 communication fails, the charger reports via OCPP (possibly with vendor-specific error codes for the specific failure).
The charger needs implementations of both protocols and a coordinator between them. This is non-trivial firmware. Quality varies across OEMs.
What can go wrong at the integration boundary
A list of things that fail in the OCPP/ISO 15118 integration.
Certificate validation differences. The charger validates a certificate; the CSMS revalidates and finds something different. Which is authoritative?
Schedule mismatch. OCPP profile says one thing; charger translates to ISO 15118 schedule that says something subtly different. Vehicle delivers different power than CSMS expected.
Event ordering. ISO 15118 events arrive at the charger; the charger forwards via OCPP. Delays mean the CSMS sees events out of order.
Vendor-specific extensions. Vendor A’s PnC implementation works; vendor B’s has subtle bugs. Same OCPP and ISO 15118 spec, different real behavior.
Version negotiation. Charger speaks OCPP 2.0.1 + ISO 15118-2. Vehicle speaks ISO 15118-20. Some features available, some not. CSMS may not know exactly what’s negotiated.
Best practices
For builders and operators.
For charger firmware engineers: make the OCPP/ISO 15118 bridge a first-class concern, not an afterthought. Test extensively with multiple CSMS partners and multiple vehicle brands. Different combinations expose different bugs.
For CSMS engineers: support the full OCPP 2.0.1 ISO 15118 integration features. Don’t treat PnC as a special case bolted onto your authentication flow.
For operators: verify PnC actually works at each site as part of commissioning. The protocols are complex; “we configured everything per spec” doesn’t guarantee operation.
For eMSP integrations: the EMAID handling in your Token system needs to be solid. Mismatches between certificate EMAID and your account database are a frequent failure source.
The honest summary
ISO 15118 and OCPP cooperate to deliver Plug & Charge and other advanced features. The charger is the bridge that translates between the two protocols. OCPP 1.6’s integration is workable but awkward; OCPP 2.0.1 has clean native support for certificate management, smart charging coordination, and ISO 15118 event reporting. Building solid PnC infrastructure requires both protocols to be well-implemented and the bridge between them to be carefully tested.