OCPP 2.0.1 and ISO 15118: How Plug & Charge Works End to End

Plug & Charge (PnC) lets a driver plug in and charge with no card or app: the vehicle proves the driver's contract with a certificate over ISO 15118, and the CSMS authorizes and bills against it. OCPP 2.0.1 is what connects the station's ISO 15118 stack to the CSMS and the PKI behind it. This part covers the OCPP side; the EV-to-station protocol itself is ISO 15118 territory. For where PnC sits among other payment methods, see EV charging payment options.

The flow at a glance

1. Before any EV arrives: the station has V2G root certificates installed and a valid SECC certificate obtained through the CSMS.
2. EV plugs in: the EV and station set up ISO 15118 communication over TLS, with the station presenting its SECC certificate (and, if needed, OCSP status fetched via the CSMS).
3. Contract presented: the EV sends its contract certificate chain; the station authorizes the eMAID with Authorize, locally or via the CSMS.
4. Charging: the transaction runs as normal, reported with TransactionEvent, and smart charging can use the EV's stated needs.
5. Occasionally: the EV asks for a contract certificate to be installed or updated, proxied through Get15118EVCertificate.

The certificates involved

• V2G root certificate: anchor of the charging-side PKI. Installed on the station with InstallCertificate and certificateType V2GRootCertificate.
• SECC (V2G charging station) certificate: the station's TLS server certificate towards the EV. Obtained with SignCertificate using certificateType V2GCertificate, signed by a sub-CA under the V2G root, delivered with CertificateSigned.
• Contract certificate: lives in the vehicle, identifies the driver's contract (its eMAID) with a mobility operator.
• MO root certificate: mobility operator root, installed with MORootCertificate if the station validates contracts locally.

Which PKI ecosystem issues these (a commercial PnC ecosystem operator, an OEM PKI, or a national one) is a business decision outside OCPP. What matters for your CSMS is that it can request V2G certificates for stations, install the right roots, and validate contract certificates or forward them to whoever can.

Station configuration

PnC behaviour is controlled by ISO15118Ctrlr variables in the device model, including PnCEnabled, CentralContractValidationAllowed (station may send the contract chain to the CSMS for validation), ContractValidationOffline (station may validate locally while offline), V2GCertificateInstallationEnabled and ContractCertificateInstallationEnabled. Variables on the same component also supply the subject fields the station uses when generating its V2G CSR. Read these first when debugging; a surprising number of PnC failures in the field are a disabled flag.

Step 1: getting the SECC certificate

[2, "tm-v2g", "TriggerMessage", {
  "requestedMessage": "SignV2GCertificate"
}]

[2, "sc-v2g", "SignCertificate", {
  "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIIBSzCB8gIBADBhMQswCQYDVQQGEwJERTEXMBUGA1UECgwORXhhbXBsZSBDUE8g...\n-----END CERTIFICATE REQUEST-----",
  "certificateType": "V2GCertificate"
}]

The CSMS forwards the CSR to the PKI provider, receives the SECC certificate and its sub-CA chain, and returns it with CertificateSigned (certificateType V2GCertificate). This is the same A02/A03 mechanism as the TLS client certificate in part 7, with a different CA behind it. SECC certificates are typically short-lived, so automate renewal from day one.

OCSP for the station's own chain

During the ISO 15118 handshake the station may need to provide revocation status for its certificate chain. Many stations cannot reach OCSP responders directly, so they ask the CSMS with GetCertificateStatus (M06), and the CSMS performs the OCSP request and returns the DER-encoded, base64 response:

[2, "gcs-ocsp-1", "GetCertificateStatus", {
  "ocspRequestData": {
    "hashAlgorithm": "SHA256",
    "issuerNameHash": "6f1a0c9b8e7d6c5b4a39281706f5e4d3c2b1a0998877665544332211aabbccdd",
    "issuerKeyHash": "0b1c2d3e4f5061728394a5b6c7d8e9f00b1c2d3e4f5061728394a5b6c7d8e9f0",
    "serialNumber": "3a7c19",
    "responderURL": "http://ocsp.pki.example.com"
  }
}]

[3, "gcs-ocsp-1", {
  "status": "Accepted",
  "ocspResult": "MIIB1woBAKCCAdAwggHMBgkrBgEFBQcwAQEEggG9MIIBuTCBoqIWBBQ..."
}]

Step 2: authorizing with the contract certificate

When a PnC-capable EV connects, it sends its contract certificate chain to the station over ISO 15118. The station then authorizes the contract with the CSMS using Authorize (use case C07). The idToken is the eMAID with type eMAID. The station either includes the full contract chain in certificate (PEM), or, if it cannot, includes iso15118CertificateHashData (OCSP request data for the chain) so the CSMS can check revocation:

[2, "au-pnc-1", "Authorize", {
  "idToken": {
    "idToken": "DEABCC1234567X",
    "type": "eMAID"
  },
  "certificate": "-----BEGIN CERTIFICATE-----\nMIICLTCCAdOgAwIBAgIQ...\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIICDjCCAbOgAwIBAgIQ...\n-----END CERTIFICATE-----"
}]

[3, "au-pnc-1", {
  "idTokenInfo": {
    "status": "Accepted"
  },
  "certificateStatus": "Accepted"
}]

The CSMS validates the chain against the MO roots it trusts, checks revocation, and checks that the eMAID corresponds to a contract it (or a roaming partner) accepts. certificateStatus is one of Accepted, SignatureError, CertificateExpired, CertificateRevoked, NoCertificateAvailable, CertChainError or ContractCancelled. Keep the two statuses separate in your logic: a valid certificate for a contract you don't accept is certificateStatus Accepted with an idTokenInfo.status that is not.

For roaming drivers, the eMAID belongs to another eMSP, and authorization goes out over your roaming connection; see OCPI tokens and real-time authorization. From there, the session continues as an ordinary TransactionEvent flow with the eMAID token, as in part 4.

Step 3: installing or updating a contract in the car

ISO 15118-2 lets the EV request installation or update of a contract certificate via the station. The station cannot process this itself; it wraps the EV's EXI-encoded request in base64 and forwards it with Get15118EVCertificate (use cases M01 and M02). The CSMS passes it to the contract provisioning service and returns the EXI response unchanged.

[2, "g15-1", "Get15118EVCertificate", {
  "iso15118SchemaVersion": "urn:iso:15118:2:2013:MsgDef",
  "action": "Install",
  "exiRequest": "gAQBAh5nNqx8Q2s...base64-exi..."
}]

[3, "g15-1", {
  "status": "Accepted",
  "exiResponse": "gAQCAh5nNqx9R7t...base64-exi..."
}]

action is Install or Update; status is Accepted or Failed. Treat the EXI payload as opaque: do not decode and re-encode it, just proxy it. The ISO 15118 side has tight timeouts, so this is one of the few OCPP calls where CSMS latency directly causes a user-visible failure. Keep the path to the provisioning service short and fail fast.

Common failure points

• Expired SECC certificate. The EV falls back to EIM (card/app) or refuses PnC. Alert well before expiry.
• Missing V2G root. Stations with the wrong or missing V2GRootCertificate cannot build their chain.
• Large frames. Certificate chains and EXI payloads make Authorize and Get15118EVCertificate frames large. Check WebSocket frame size limits in proxies and load balancers.
• Slow OCSP. If your CSMS calls OCSP responders synchronously with no cache, PnC authorization becomes slow. Cache OCSP responses within their validity.
• Mixed flows. The same EVSE must still support EIM. Test that a PnC failure falls back cleanly rather than leaving the EVSE stuck.

Next

Next: display messages and cost information. For a broader view of where ISO 15118 sits among protocols, see EV charging protocols explained.