The Handshake: Deep Dive into BMS-EVSE Communication Protocols for High-Power Charging
Quick Answer
Before a DC fast charger can close its contactors and deliver hundreds of kilowatts, the vehicle’s battery management system (BMS) and the charging station (EVSE) must complete a digital handshake that negotiates voltage limits, current limits, and charging parameters while verifying electrical safety. On CCS systems this handshake runs over powerline communication (PLC) on the control pilot wire, using DIN 70121 for basic sessions and ISO 15118-2 or ISO 15118-20 for advanced sessions with Plug & Charge; CHAdeMO and GB/T use CAN-based protocols instead. The handshake is a state machine — session setup, service discovery, charge parameter discovery, cable check, power delivery, and session termination — where every transition is guarded by timeouts and safety interlocks. Most “charger will not start” incidents trace back to this layer, not to power hardware, which is why protocol compatibility is a first-order procurement criterion for 2026 fleets.

Key Takeaways
- The BMS-EVSE handshake is simultaneously a safety interlock and a negotiation protocol: it prevents overvoltage, overcurrent, and incompatible charging profiles before any current flows.
- CCS high-power charging communicates over PLC on the control pilot pin, using DIN 70121 (basic) or ISO 15118-2/-20 (advanced, with Plug & Charge support).
- The handshake follows defined states — session setup, service discovery, charge parameter discovery, cable check, power delivery — each with its own timeouts and failure handling.
- Protocol mismatches and firmware drift between the vehicle stack and the EVSE stack are the leading cause of interoperability failures at high-power chargers.
- Procuring stations with wide protocol and connector support (CCS2, GB/T, ISO 15118-20 readiness) materially reduces interoperability risk for mixed fleets.
Why the Handshake Matters: Safety Before Power
DC fast charging is the electrical equivalent of a handshake between two systems that have never met. The vehicle does not know the station’s output limits, and the station does not know the battery’s voltage window, state of charge, or maximum accept current. Closing the contactors without agreeing on those parameters first can deliver current outside the battery’s safe envelope — a risk of overvoltage, overcurrent, or thermal damage that no manufacturer is willing to accept. The handshake exists to make the exchange safe, deterministic, and auditable.
The physical safety layer runs on the control pilot (CP) and proximity pilot (PP) pins. The CP signal cycles through defined voltage levels telling both sides whether a cable is connected, the connector latched, the vehicle ready, and the station allowed to energize. The PP pin encodes the cable’s current-carrying capability through a resistor value, so a thin cable can never silently become the bottleneck in a high-power session. Only after this analog layer confirms a valid connection does the digital layer begin — and only after it agrees on parameters does the station close its DC contactors and ramp power.
The Physical Layer: Control Pilot, Proximity Pilot, and PLC
For CCS (Combined Charging System) connectors — CCS1 in North America, CCS2 in Europe and most of Asia-Pacific — the digital handshake shares the CP wire with the analog state signaling, using powerline communication at a carrier frequency in the 2–30 MHz band. This means the same pair of pins carries both the safety states and the high-speed digital messages between vehicle and station, with no additional connector pins required. The PLC modem inside each side modulates and demodulates the ISO 15118 protocol frames.
Other standards took a different path. CHAdeMO, the Japanese fast-charging standard, dedicates CAN bus pins in its connector for BMS-EVSE messaging, using a plain, highly deterministic transport. GB/T similarly uses CAN-based messaging defined in GB/T 27930, carrying battery status, charging parameters, and termination commands in a fixed periodic exchange. Each transport has strengths: PLC avoids extra pins but has stricter signal-quality requirements; CAN is simple and robust but carries less bandwidth for advanced functions. The practical consequence is that protocol and connector choice are coupled — a station’s connector hardware dictates which handshake it can perform.
The Protocol Stack: DIN 70121, ISO 15118-2, and ISO 15118-20
On the CCS side, the digital handshake is defined by a family of standards that share a common architecture but differ in capability. DIN 70121 was the first deployed CCS communication standard, designed for the narrow job of DC charging session control without payment or advanced features. ISO 15118-2 generalized the architecture, added TLS security, and introduced Plug & Charge, in which the vehicle’s own certificates authorize the session. ISO 15118-20, the current-generation standard, adds bidirectional charging (V2G), improved smart charging with energy and cost profiles, and cleaner certificate handling, while maintaining backward compatibility with the -2 session flow.
From the operator’s perspective, the meaningful difference is forward compatibility. DIN 70121 vehicles still exist in older fleets, and a station that drops DIN support will strand them; ISO 15118-2 vehicles are the current majority; ISO 15118-20 capability is the safest future-proofing investment, because it carries the features — Plug & Charge, V2G, smart charging — that regulators and fleet customers increasingly demand. Dual-gun wall-mounted DC charging stations in the 40–80kW class illustrate the hardware that must carry this protocol flexibility in mixed fleets, since the wide voltage window only helps if the handshake can also negotiate it correctly.
Comparing the Handshake Standards
| Attribute | DIN 70121 | ISO 15118-2 | ISO 15118-20 | CHAdeMO | GB/T 27930 |
|---|---|---|---|---|---|
| Region / ecosystem | CCS (legacy) | CCS (current) | CCS (next-gen) | Japan / Asia | China |
| Physical transport | PLC over CP | PLC over CP | PLC over CP | CAN | CAN |
| Plug & Charge | No | Yes (certificate-based) | Yes, hardened | No (token-based) | No (mostly RFID/APP) |
| Bidirectional (V2G) | No | Limited | Yes, native | Yes (V2H/V2G profiles) | Emerging (GB/T V2G) |
| Smart charging | Minimal | Charging profiles | Energy & cost profiles | Charging profiles | Fixed schedule exchange |
| Security | None / plaintext | TLS + certificates | TLS 1.3-era, PKI hardened | None native | None native |
| Typical deployment | Older CCS chargers | Most 2019–2025 CCS EVs | New 2024+ premium EVs | Legacy CHAdeMO stations | Chinese-market stations |
Anatomy of a High-Power Charging Session
Walking through a CCS session at a high-power charger makes the state machine concrete. The sequence below is the ISO 15118 flow; DIN 70121 is a subset of the same stages.
Session Setup
After the CP signal transitions to state indicating a vehicle is connected and ready, both sides initialize their PLC modems and establish a communication session. The vehicle sends a SessionSetupReq with its identifier, and the station responds with a session ID and a timeout for the negotiation phase. This stage also determines which protocol version the pair will use, since vehicles may announce multiple supported versions.
Service Discovery
The vehicle asks which services the station offers — DC charging, AC charging, or (in newer versions) bidirectional power transfer. The station replies with its service list and, critically, the payment options it supports: external payment (card, RFID, APP) versus contract-based Plug & Charge. This is where a station’s payment configuration is surfaced to the vehicle before any current flows.
Charge Parameter Discovery
The vehicle now transmits its battery envelope: minimum and maximum voltage, maximum current, and the energy request. The station compares this against its own output capability and, if the envelopes intersect, proposes a charging schedule — the current-vs-time curve it will follow. If the envelopes do not intersect — for example, an 800V vehicle at a station whose maximum output voltage is 500V — the session terminates here with a clear protocol-level reason, which is exactly the kind of data that should flow into the operator’s diagnostics.
Cable Check and Pre-Charge
Before closing the contactors, the station performs an insulation check and applies a low-voltage pre-charge to equalize the voltage across the DC link, confirming that the cable and connector are intact and the vehicle is truly ready. The cable check verifies that the DC link can hold voltage without leakage current — a direct safety gate that prevents arcing at connector contact.
Power Delivery
The station closes its DC contactors and begins delivering power along the agreed charging schedule, while the vehicle continuously reports its actual battery state and limits. The station adjusts current in real time within the negotiated envelope; the vehicle can request reductions at any moment, and either side can terminate the session with a defined reason code. For high-power charging above 150kW, this stage is also where thermal limits on the cable and connector are actively managed by both sides.
Session Termination
Either side may end the session — target state of charge reached, driver unplug request, fault condition, or scheduled limit. The closing exchange confirms the final meter values and reason codes, after which the station opens its contactors and the CP returns to the idle state. Every termination is logged, and those logs are the forensic record for interoperability troubleshooting.
High-Power Charging: Where the Handshake Gets Stressed
Above 150kW, the handshake becomes more than a negotiation; it becomes a real-time power management contract. The vehicle negotiates a maximum current that the station must deliver with tight regulation, and both sides must handle thermal derating without breaking the session. A station whose handshake stack is mature handles a vehicle mid-session request to reduce current by smoothly renegotiating the schedule; an immature stack may terminate the session, forcing the driver to restart from zero. Similarly, ISO 15118-20 energy and cost profiles let the station propose tariffs inside the handshake, enabling Plug & Charge billing without any separate payment step.
Interoperability testing is the only reliable insurance. Conformance to the standard does not guarantee interoperation with every vehicle, because vehicles implement protocol subsets and handle edge cases differently. Mature vendors test their stacks against a broad vehicle library and publish compatibility lists. For buyers, the heavy-duty dual-gun DC charging piles with CCS2 and GBT connectors and the CCS2/GBT Type 2 dual-gun wall-mounted DC charging stations represent the dual-standard hardware class that covers both European CCS2 vehicles and Chinese GB/T fleets from a single unit — a pragmatic answer to mixed-ecosystem interoperability.
Interoperability Failure Modes and How to Avoid Them
The failure modes at the handshake layer are well understood, and most are preventable. The most common is protocol version mismatch: a station firmware that only supports DIN 70121 will not complete an ISO 15118-2 session, and a vehicle that only speaks ISO 15118-20 may fail against a station frozen at -2. Firmware drift is the second pattern: an updated vehicle stack interacting with an unpatched station stack exposes bugs that neither conformance suite caught independently. The third is physical-layer marginality — poor CP wiring, damaged connector contacts, or noisy PLC environments that corrupt frames and cause the negotiation to time out silently.
Mitigations follow directly. Keep station firmware current, because protocol fixes arrive continuously. Demand vendor compatibility matrices that are tested against current vehicle models, and prefer vendors that can remote-diagnose a failed handshake through OCPP alarm and log access. Specify dual-connector or multi-standard configurations where the fleet is mixed, and — for high-power sites — confirm the station’s PLC modem and thermal design are rated for sustained negotiation and delivery. The mini dual-gun DC fast charging stations and the OCPP smart EVSE fast charging stations for parking lots in the commercial range ship with the OCPP telemetry hooks that let operators observe handshake outcomes remotely, turning interoperability problems from driver complaints into dashboard items.
What Fleet and Network Buyers Should Specify in 2026
The handshake layer deserves the same procurement rigor as power rating and compliance. The following specification items convert this technical analysis into tender language:
- Protocol coverage: ISO 15118-2 and ISO 15118-20 support with documented backward compatibility to DIN 70121 for legacy vehicles.
- Connector strategy: CCS2, or CCS2 plus GB/T where the fleet includes Chinese-market vehicles; confirm GB/T 27930 compliance in writing.
- Plug & Charge: ISO 15118 certificate handling on the station, validated against a major charge point management system.
- Real-time renegotiation: demonstrated mid-session current reduction without session termination, tested with at least two vehicle models.
- Interoperability evidence: a published vehicle compatibility list and a commitment to protocol bug-fix firmware within a defined window.
- Remote observability: OCPP alarm and log access covering handshake failures, including reason codes and the protocol stage that failed.
- Wide voltage envelope: output range covering 400V and 800V battery architectures, since the handshake is where envelope mismatches are discovered.
The commercial-grade dual-gun wallbox DC fast chargers with wide voltage range are a reference point for the last item: a 150–1000V envelope with dual connectors is precisely the configuration that lets a single station complete successful handshakes with the widest spread of vehicles, from 400V delivery vans to 800V passenger platforms. The handshake will never be visible to drivers — its job is to make power delivery look effortless — but getting it right is the difference between a charging network that works with the fleet it has and one that works only with the fleet it hoped for.

Frequently Asked Questions
Q1. What exactly happens during the BMS-EVSE handshake?
The vehicle and station exchange a sequence of digital messages — session setup, service discovery, charging parameter negotiation, cable check, and power delivery confirmation — that agree on voltage and current limits and verify electrical safety before the station closes its DC contactors.
Q2. Why does my vehicle sometimes fail to start charging on a CCS station?
Most failures occur at the handshake layer: protocol version mismatch (DIN 70121 vs ISO 15118-2/-20), firmware drift on either side, or marginal PLC signal quality. Station logs and OCPP alarms usually capture the failing stage and reason code.
Q3. What is the difference between DIN 70121 and ISO 15118?
DIN 70121 is the earlier CCS communication standard covering basic DC session control without payment or security features. ISO 15118-2 adds TLS security and Plug & Charge; ISO 15118-20 adds bidirectional charging, smart charging, and hardened certificate handling.
Q4. Is the handshake different for CHAdeMO and GB/T charging?
Yes. CHAdeMO and GB/T use CAN bus messaging between BMS and EVSE rather than PLC, with their own message sequences and parameters. The safety purpose is identical, but the transport and protocol stacks are incompatible with CCS.
Q5. Does the handshake limit charging power?
The handshake sets the negotiated limits — the vehicle’s maximum accept current and the station’s output capability define the envelope. Actual power during the session is managed in real time by both sides within that envelope, including thermal derating.
Q6. What is Plug & Charge, and why does it matter for fleets?
Plug & Charge lets the vehicle authenticate and authorize payment using its own certificates during the handshake, eliminating cards and APP steps. For fleets it removes driver friction and simplifies billing reconciliation across vehicles and stations.
Q7. Can firmware updates fix handshake interoperability problems?
Frequently, yes. Protocol implementation bugs and version gaps are routinely resolved in station firmware, which is why OTA-capable hardware and a vendor firmware commitment are important procurement criteria.
Post time: Sep-01-2026