What is Plug & Charge (ISO 15118)?

As the electric vehicle ecosystem matures, the focus is shifting from simple hardware availability to intelligent software integration. At the center of this evolution is ISO 15118.

Often referred to as the "Plug & Charge" standard, ISO 15118 is the international protocol that defines the communication interface between an Electric Vehicle (EV) and the Electric Vehicle Supply Equipment (EVSE). It replaces basic analog signaling with a sophisticated digital dialogue, serving as the technological backbone for a seamless, secure, and automated charging experience.

For the EV industry, ISO 15118 is not merely an optional upgrade; it is the prerequisite for mass adoption and grid integration.

Part 1: Understanding the Protocol and Its Value

At its core, ISO 15118 allows the vehicle and the charger to exchange high-level data. Unlike legacy charging protocols that simply manage the flow of electricity, ISO 15118 manages information: identity, billing data, grid constraints, and energy pricing.

This exchange enables three critical capabilities that define the modern charging landscape.

1. Plug & Charge (PnC): Automation and Security

The most immediate benefit of ISO 15118 for drivers and fleet operators is Plug & Charge. This feature eliminates the need for external authentication methods such as RFID cards, mobile apps, or QR codes.

  • The Process: When a driver plugs in the cable, the vehicle automatically identifies itself to the charging station using encrypted digital certificates.

  • The Authorization: The charger verifies the vehicle’s contract data against a central system. Once verified, the charging session begins immediately.

  • The Result: A streamlined user experience that mimics the simplicity of plugging in a smartphone, combined with banking-grade security that protects user data and payment information.

2. Smart Charging: Grid Optimization

As EV adoption scales, the demand on the electrical grid increases. ISO 15118 transforms charging from a passive load into an active, intelligent participant in the energy market.

Through Smart Charging, the vehicle and the charger can negotiate the charging schedule based on external variables:

  • Grid Capacity: If the local grid is under heavy load, the charger can instruct the vehicle to lower its power draw temporarily.

  • Energy Pricing: The vehicle can be programmed to charge only when electricity rates are lowest (e.g., off-peak overnight hours).

  • Renewable Availability: Charging speeds can dynamically adjust to align with peaks in solar or wind energy generation, maximizing the use of clean power.

3. Bidirectional Energy Transfer (V2G)

Perhaps the most transformative aspect of ISO 15118 is its support for bidirectional power transfer, commonly known as Vehicle-to-Grid (V2G).

This capability allows the energy stored in an EV battery to flow back into the grid, a building, or a home. This turns millions of EVs into a decentralized "virtual power plant," capable of stabilizing the grid during emergencies or selling excess energy back to utility companies during peak demand hours.

Learn more about EV charging basics on our Charging 101 page >>

Part 2: Technical Deep Dive and Architecture

The following section details the engineering principles, communication stack, and message sequences of ISO 15118. This information is intended for network architects, hardware engineers, and technical stakeholders.

ISO 15118 is a layered protocol that operates significantly differently than the older IEC 61851 standard (which relied on simple Pulse Width Modulation signaling). It establishes a full IP-based network connection between the EV and the EVSE.

The Communication Stack

To enable rich data exchange, ISO 15118 leverages a communication stack similar to standard internet protocols.

  • Physical Layer (PLC): Data is transmitted directly over the charging cable’s Control Pilot (CP) pin. The system uses Power Line Communication (PLC) based on the HomePlug Green PHY standard to modulate data signals over the copper wire.

  • Network Layer (TCP/IP): Once the physical link is established, the EV and EVSE assign IPv6 addresses to one another. This creates a secure, local network segment specifically for that charging session.

  • Application Layer: The data payload is exchanged using XML (Extensible Markup Language). To ensure low latency and minimal bandwidth usage, these messages are compressed using EXI (Efficient XML Interchange).

The "Handshake" Sequence

When an ISO 15118-compliant vehicle connects to a compliant charger, a specific state machine is triggered. This "handshake" occurs in seconds:

  1. Session Setup & Service Discovery:

    • The EV initiates communication (SessionSetupReq).

    • The EVSE responds with a list of supported services (e.g., AC charging, DC charging, Internet access, Certificate installation).

  2. Payment & Authorization (PnC):

    • If Plug & Charge is selected, the EV sends a PaymentDetailsReq containing its digital contract certificate.

    • The EVSE validates the certificate chain via the Public Key Infrastructure (PKI) to ensure the contract is active and valid.

  3. Charge Parameter Discovery:

    • The EV communicates its battery status: State of Charge (SoC), maximum voltage, and current limits.

    • The EVSE compares this with its own hardware limits and grid constraints to agree on a charging schedule.

  4. Cable Check & Pre-Charge (DC Only):

    • Cable Check: The EVSE tests the cable insulation integrity to ensure safety.

    • Pre-Charge: The EVSE adjusts its DC output voltage to match the EV battery voltage within <20V difference. This prevents dangerous current arcing when the vehicle's contactors close.

  5. Power Delivery Loop:

    • Once contactors are closed, the EV enters a control loop, sending a CurrentDemandReq roughly every 60 milliseconds to request specific amperage. This continues until the session is terminated.

Security Architecture: The Zero Trust Model

ISO 15118 adopts a "Zero Trust" security philosophy. It assumes the connection is insecure until proven otherwise.

  • Transport Layer Security (TLS): All communication is encrypted using TLS (specifically TLS 1.2 in ISO 15118-2 and TLS 1.3 in ISO 15118-20). This prevents "Man-in-the-Middle" attacks where a hacker might try to intercept payment data.

  • Digital Certificates: The ecosystem relies on a complex Public Key Infrastructure (PKI). This involves Root Certificate Authorities (V2G Root CA), Mobility Operators (MO), and Charge Point Operators (CPO).

  • Asymmetric Cryptography: The vehicle signs its messages with a private key, and the charger verifies them with a public key. This ensures that the car you are charging is actually the car associated with the billing account.

Part 3: Technical FAQ

Common engineering challenges and implementation details.

Q: How does the TLS handshake impact charging latency?
A: Implementing TLS adds overhead to the session startup. A full TLS handshake can add approximately 1.5 to 2 seconds to the connection time compared to unencrypted communication. While this is negligible for user experience, it must be accounted for in the timeout settings of the EVCC (EV Communication Controller).

Q: What are the timeout constraints for the handshake?
A: The standard defines strict timeout windows. For example, during the authorization phase, if the EVSE does not receive a valid response from the backend (OCSP check) within a set window (often 5 to 60 seconds depending on the specific state and version), the session will time out. Best practices suggest configuring the EVSE to allow up to 150 seconds for the complete authentication phase to account for poor cellular network latency on the charger’s side.

Q: What happens if the internet connection is lost and the CA cannot be reached?
A: This is the "Offline Case." If the charger cannot reach the Certificate Authority (CA) to check if a certificate is revoked (OCSP check), the behavior depends on the CPO's risk policy.

  • Fail Secure: The charger denies the session (safe but poor user experience).

  • Fail Safe: The charger relies on a cached CRL (Certificate Revocation List) or a "whitelist" of trusted contracts to authorize the session offline.

Q: Does ISO 15118 mandate a fallback if Plug & Charge fails?
A: The protocol itself does not strictly mandate a fallback, but EIM (External Identification Means) is the industry standard fallback. If the PnC handshake fails (e.g., expired certificate), the charger should ideally send a prompt to the user to swipe an RFID card or use an App. However, poorly implemented state machines can sometimes result in a "race condition" where the charger gets stuck trying to PnC instead of releasing the session for EIM.

Q: What is the difference between ISO 15118-2 and ISO 15118-20?
A: ISO 15118-20 is the "Generation 2" standard.

  • Security: Upgrades from TLS 1.2 to TLS 1.3 (mandatory).

  • Bidirectional: Adds native support for V2G (Vehicle-to-Grid), V2H, and V2B.

  • Wireless: Adds support for Wireless Power Transfer (WPT).

  • Pantographs: Adds support for automated bus charging (ACDP).

Ready to Future-Proof Your Charging Infrastructure?

At EV Range, we build software and hardware that is ready for the future of mobility. Whether you are looking to deploy ISO 15118-compliant chargers or manage a fleet with Plug & Charge capabilities, our team is here to guide you.

Contact Us Today to Learn More

Next
Next

Millions in Funding Available Now: Why Property Owners in Ca, Tx, Co, and AZ Should Act Fast on DC Fast Charging