How Plug & Charge Works End-to-End

Plug & Charge — abbreviated PnC — is the EV charging experience that should feel like magic: you plug in, the car identifies itself, billing starts, and energy flows. No card. No app. No interaction beyond plugging in.

Behind that simple experience is one of the most sophisticated certificate and protocol orchestrations in modern infrastructure. Multiple parties, multiple PKIs, multiple network hops, all happening in seconds.

This article walks through a complete PnC session step by step. By the end you’ll understand what’s actually happening when you plug in.

The cast of characters

Several parties are involved.

The vehicle. Has hardware and firmware that speaks ISO 15118 ^{(coming soon)}. Has a contract certificate installed in its secure storage.

The charger (CPO-operated). Speaks ISO 15118 to the vehicle. Speaks OCPP to its CSMS. Has its own certificate and trust roots.

The CSMS (CPO-operated). Receives OCPP messages from the charger. Knows how to validate certificates by querying its CA infrastructure or via OCPI to the eMSP.

The eMSP. The user’s mobility service provider. Operates the back-end that issued and tracks the contract certificate. Receives the Authorize/CDR flow via OCPI from the CPO.

The PKI roots and CAs. The root certificate authorities that issued the various certificates. Multiple parties operate parts of the PKI ecosystem.

A PnC session involves all of these, with messages and verifications flowing between them. At the authorization moment, the request fans out across three protocols:

sequenceDiagram
    participant EV as Vehicle
    participant CP as Charger
    participant CS as CSMS
    participant MS as eMSP
    EV->>CP: PaymentDetailsReq<br/>contract cert
    CP->>CP: Validate cert chain
    CP->>CS: OCPP Authorize
    CS->>MS: OCPI token authorize
    MS-->>CS: Authorized
    CS-->>CP: Accepted
    CP-->>EV: PaymentDetailsRes<br/>you can charge

Each hop uses a different protocol: ISO 15118 between vehicle and charger, OCPP between charger and CSMS, OCPI between CSMS and eMSP.

Step 1: The user plugs in

The simplest step from the user’s perspective. The cable goes from the charger into the vehicle’s inlet.

Physically, this engages:

• The DC power pins (for DC fast charging).
• The pilot pin (for low-level signaling per IEC 61851).
• The CP / PP pins for signaling and connector presence detection.

The pilot pin is the conduit for all subsequent ISO 15118 communication. The vehicle and charger now have a physical communication channel.

Step 2: Low-level handshake (IEC 61851)

Before any ISO 15118 traffic, the vehicle and charger do a low-level handshake on the pilot pin:

• The charger sends a PWM signal indicating its max current capability.
• The vehicle responds by changing the pilot pin state to indicate “I am present and ready.”
• Both sides agree they’re ready to communicate.

This step happens in milliseconds and works the same way it does for non-PnC sessions.

Step 3: SLAC and powerline-communication setup

For DC charging (and PnC over DC), the charger and vehicle establish a powerline communication channel over the pilot pin using HomePlug GreenPHY.

This is called SLAC (Signal Level Attenuation Characterization) — a protocol for selecting the right HomePlug channel and authenticating the link.

A few seconds. Sets up the higher-bandwidth channel that ISO 15118 will use.

Step 4: ISO 15118 session setup (SessionSetupReq / SessionSetupRes)

Now the real ISO 15118 conversation begins.

The vehicle sends SessionSetupReq with its own session ID. The charger responds with SessionSetupRes containing the EVSE’s ID and a server-side session ID.

The two sides now have a logical ISO 15118 session.

Step 5: Service Discovery (ServiceDiscoveryReq / ServiceDiscoveryRes)

The vehicle asks what services the charger offers. The charger responds with a list:

• Charging (always).
• ContractCertificate management (for installing/updating certificates).
• Various optional services (depending on charger capabilities).

The vehicle then selects the services it wants to use.

Step 6: Payment Selection (PaymentServiceSelectionReq / PaymentServiceSelectionRes)

The vehicle tells the charger which authentication method it wants to use:

• ExternalPayment — the user will authorize via some external mechanism (card, app, etc.).
• Contract — the vehicle will use its contract certificate (Plug & Charge).

If the vehicle picks Contract, the PnC flow continues. If ExternalPayment, the session falls back to traditional authentication.

Step 7: Authorize (PaymentDetailsReq / PaymentDetailsRes)

The vehicle sends PaymentDetailsReq containing:

• The contract certificate.
• A signature proving possession of the private key.

The charger now has the user’s contract certificate and a proof of possession. Next step: verify it.

Step 8: The charger validates the contract certificate

The charger:

1. Checks the certificate’s signature chain. Does the contract certificate trace back to a trusted root via valid intermediate CAs? (See contract certificates and the PKI ^{(coming soon)} for how these chains are structured.)
2. Checks revocation status. Is the certificate revoked? Via OCSP, CRL, or an out-of-band check.
3. Checks the signature on the proof of possession. Did the vehicle actually sign with the certificate’s private key?

If all checks pass, the certificate is technically valid. But the charger still needs to confirm the user is currently authorized to charge — the certificate’s existence doesn’t mean the contract is still active.

Step 9: The charger asks its CSMS via OCPP

The charger sends OCPP Authorize to its CSMS:

{
  "idToken": {
    "idToken": "ABC12345-EMA-EU-DEV-12345",
    "type": "ISO15118EmaId"
  },
  "certificate": "...the contract certificate..."
}

The CSMS receives this and proceeds to verify the user’s authorization status.

Step 10: The CSMS validates with the eMSP via OCPI

The CSMS doesn’t necessarily know the user — the user is the eMSP’s customer, not the CPO’s. The CSMS uses OCPI to ask the eMSP, via the Tokens module:

GET /tokens/{country_code}/{party_id}/{token_uid}
or
POST /tokens/{country_code}/{party_id}/{token_uid}/authorize

The token_uid here is the EMAID (eMobility Account ID) embedded in the contract certificate. The eMSP responds with whether this user is authorized.

If yes, the CSMS authorizes the session. If no, rejects.

Step 11: The CSMS responds to the charger via OCPP

OCPP AuthorizeResponse:

{
  "idTokenInfo": {
    "status": "Accepted",
    "personalMessage": null,
    "evseId": null
  }
}

The charger now knows the user is authorized.

Step 12: The charger responds to the vehicle (PaymentDetailsRes)

The charger tells the vehicle: authorization succeeded, you can charge.

Step 13: Charging parameter negotiation (ChargeParameterDiscoveryReq / ChargeParameterDiscoveryRes)

Now the technical setup for the actual charging:

The vehicle tells the charger:

• Its battery voltage range.
• Maximum current it can accept.
• Target state of charge.
• Departure time (if known).
• Energy requested.

The charger responds with:

• Its maximum voltage and current capability.
• Its maximum power.
• Charging schedule (if applicable).

Both sides now agree on the bounds.

Step 14: Pre-charge (CableCheckReq / CableCheckRes, PreChargeReq / PreChargeRes)

For DC, the charger does a safety check:

• CableCheck: verifies cable insulation is OK at low voltage.
• PreCharge: ramps the DC voltage to match the vehicle’s battery voltage before closing the main contactor (prevents inrush current that would damage components).

A few seconds. Important for safety and equipment longevity.

Step 15: Charging begins (PowerDeliveryReq with ChargeProgress=Start, ChargingStatusReq)

The vehicle tells the charger: start charging. The charger closes the contactor and DC current begins to flow.

The vehicle then enters a loop of ChargingStatusReq messages where it tells the charger its current demand:

• Present voltage and current.
• State of charge.
• Battery temperature.
• Power demand for the next interval.

The charger adjusts the actual delivery to match (within its own capability limits).

Step 16: The OCPP layer reports the transaction

Meanwhile, the charger has sent OCPP messages to the CSMS:

• StatusNotification (or equivalent) reflecting the new state.
• TransactionEvent (Started) with the transaction’s start meter reading.

The CSMS records the session start.

Step 17: During charging — meter values and updates

As charging proceeds, the charger:

• Continues the ChargingStatusReq loop with the vehicle (ISO 15118).
• Sends periodic MeterValues or TransactionEvent (Updated) to the CSMS (OCPP).

The CSMS may also push the session update to the user’s eMSP via OCPI Session updates so the eMSP can display the in-progress session in the user’s app.

Step 18: User unplugs (or session otherwise ends)

When the user unplugs (or the vehicle reaches target SOC, or any other end condition):

• ISO 15118: PowerDeliveryReq with ChargeProgress=Stop, then SessionStopReq.
• OCPP: TransactionEvent (Ended) with the final meter reading.
• OCPI: Session update to ACTIVE → COMPLETED, then CDR generation and delivery to the eMSP.
• OCPI from eMSP: confirmation of receipt; the eMSP can now bill the user.

The contactor opens. The pilot pin signal resets. The user removes the cable. The session is complete.

Total elapsed time

A typical PnC session:

• Plug-in to start of power flow: 15-45 seconds (ISO 15118-2) or 10-20 seconds (15118-20 with EXI).
• Session duration: whatever the user needs.
• Stop to bill: typically the bill posts to the user within minutes to a few hours, depending on the eMSP.

From the user’s perspective: “I plugged in, waited about half a minute, the charger was delivering power.” That’s all they see.

What can go wrong

A short list of where this can fail.

Certificate expired. The user’s contract certificate is past its expiration date. The charger rejects. Fallback to manual auth.

Certificate revoked. The certificate was revoked (user left the contract). Rejected.

Trust root mismatch. The contract certificate’s root isn’t trusted by the charger. Rejected.

Vehicle hardware issue. The vehicle can’t sign the proof of possession (HSM failure). PnC fails; fallback if available.

Charger hardware issue. Charger’s HSM is faulted. Authentication fails on charger side.

Network failure to eMSP. CSMS can’t reach the eMSP via OCPI. Times out. Falls back if local-auth-list has the user, else rejects.

eMSP says no. The eMSP rejects (e.g. account suspended). Rejected.

Vehicle/charger version mismatch. Vehicle speaks 15118-20 V2G, charger only speaks 15118-2. Fall back to common subset (one-direction charging). The practical differences are covered in ISO 15118-2 vs 15118-20 ^{(coming soon)}.

Wrong service selection. Vehicle picks Contract but isn’t certificate-equipped. Confusing error.

Each of these has different mitigation strategies, but the pattern is the same: PnC has many places to fail; fallback to user-initiated authentication (RFID, app) is the safety net.

Why PnC is worth it

After all that complexity, the user experience benefit is real:

• Zero friction at the charger. Plug in, walk away.
• Faster sessions. No fumbling with cards.
• Better accessibility. Drivers with mobility issues don’t need to interact with the charger.
• Stronger security. Certificate-based identity beats RFID by every measure.
• Foundation for advanced features. V2G, scheduling, autonomous-vehicle charging — all easier with the PnC trust framework.

The user doesn’t see the complexity; they see the cleanness. That’s the goal.

The honest summary

Plug & Charge is one of the more sophisticated workflows in EV charging. Multiple parties, multiple PKIs, multiple network hops, all orchestrated to produce a “just plug in” experience. When it works, it’s the best EV charging UX. When it doesn’t, the failure modes are subtle and require deep understanding of the certificate world to diagnose. As the technology matures and adoption grows, PnC will become the default expectation rather than the premium feature.