ISO 15118-20 and Bidirectional Charging

IoTEV ChargingISO 15118V2G
Share on LinkedIn

Fleet operators want chargers that pull power from vehicles during peak tariff windows — but only if the car, charger, and grid operator agree on discharge limits in milliseconds, not via a phone app. ISO 15118-20 is the updated vehicle-to-charger communication stack that adds bidirectional power transfer (BPT) messaging, refined certificate flows for plug-and-charge, and modular documents separating AC from DC semantics. If you are building SECC firmware on a charge point or integrating EVCC on a TCU, 15118-20 is the path from "dumb Level 2 socket" to grid-aware energy asset.

Protocol stack overview

Application (15118-20 EXI messages: SessionSetup, ChargeLoop, BPT...)
        │
   TLS 1.2/1.3 + mutual cert auth (Plug & Charge)
        │
      TCP/IP (typically IPv6 on PLC per ISO 15118-8)
        │
   ISO 15118-3 / DIN 70121 (PLC physical layer)

Session flow (simplified):

  1. SDP — SECC IP discovery
  2. SupportedAppProtocol — negotiate 15118-2 vs -20
  3. SessionSetup / ServiceDiscovery
  4. Authorization — EIM (external) or PnC (certificate)
  5. PowerDelivery / ChargeLoop — dynamic limits, BPT schedules
  6. SessionStop

Bidirectional power transfer (BPT)

15118-20 defines BPT variants for AC and DC:

Key message concepts:

<!-- conceptual EXI element names, not literal schema -->
<BPT_ScheduledMode>
  <DepartureTime>2026-01-15T17:00:00Z</DepartureTime>
  <EVTargetEnergyRequest>-5.0 kWh</EVTargetEnergyRequest> <!-- negative = export -->
  <EVMaximumDischargePower>7.4 kW</EVMaximumDischargePower>
</BPT_ScheduledMode>

EV sends discharge capabilities; SECC merges grid operator limits from EMS; both sides enforce ramp rates.

Implement state machines carefully — mode transitions mid-session require renegotiation without unsafe power steps.

Plug and Charge certificates

PnC uses V2G PKI:

15118-20 refines CertificateInstallation and CertificateUpdate flows for contract cert rotation without dealer visit. Misconfigured trust stores cause the silent fallback to RFID — test cross-OEM chains in interoperability plugs.

SECC implementation notes

Embedded Linux SECC stack typical components:

// pseudocode session state
typedef enum {
    SECC_IDLE,
    SECC_TLS_HANDSHAKE,
    SECC_SESSION_ACTIVE,
    SECC_BPT_DISCHARGE,
    SECC_ERROR_STOP
} secc_state_t;

void on_charge_loop(BPT_ChargeLoopReq *req) {
    grid_limit_w_t grid_cap = ems_get_export_limit();
    res->EVSEMaxDischargePower = min(req->EVMaxDischargePower, grid_cap);
    res->EVSEProcessing = Ongoing;
}

Integrate with ISO 15118-3 PLC modem driver; latency jitter on HomePlug affects TLS timeout tuning.

Log EXI messages hashed for audit — full payload logs may contain contract identifiers (GDPR).

Differences from 15118-2 deployments

Topic 15118-2 15118-20
Structure Monolithic Modular (-2, -4 DC, -5 AC, -8 PLC...)
BPT Limited / external Native BPT modes
WPT Not focus Reference modules
SAP negotiation Required Extended protocol set

Field chargers often support dual stack — detect vehicle capability and branch.

Testing and certification

Certification paths vary by market — UL 9741, CE grid codes — protocol compliance is necessary not sufficient.

EMS integration for V2G

ISO 15118-20 handles vehicle-to-charger communication. Grid integration requires an Energy Management System (EMS) layer:

Grid operator ←→ EMS ←→ SECC ←→ EVCC ←→ Vehicle BMS
                  ↑
            IEEE 1547 / EN 50549 limits
            Tariff signals (OpenADR, EEBUS)
            Fleet scheduler API

The SECC must merge three constraint sets in real-time:

  1. Vehicle limits — max discharge power from BMS via EVCC
  2. Charger limits — hardware capability of the power module
  3. Grid limits — export cap from EMS based on grid code and tariff
void compute_discharge_limit(BPT_ChargeLoopReq *ev_req) {
    float ev_max = ev_req->EVMaximumDischargePower;
    float evse_max = hardware_get_max_discharge();
    float grid_max = ems_get_export_limit();  // from IEEE 1547 ride-through

    res->EVSEMaxDischargePower = min(ev_max, evse_max, grid_max);
    res->EVSEMaxDischargeCurrent = res->EVSEMaxDischargePower / voltage;
}

If EMS communication fails, default to zero export — never discharge without grid authorization.

Open source SECC stacks

Building SECC from scratch is years of work. Open source stacks accelerate development:

Use simulators for regression testing before hardware-in-loop:

# EVerest: start SECC with simulated EVCC
everest start --config configs/15118-20-ac-bpt.yaml
everest trigger --module evse_manager --action start_charging

Interoperability testing

Cross-OEM interoperability is the hard part — Tesla, VW, Hyundai, and Ford each implement 15118-20 with vendor variations:

Maintain a compatibility matrix: vehicle model × firmware version × test result. Update after every firmware release on either side.

Failure modes

Production checklist

Resources

Frequently asked questions

What does ISO 15118-20 add over ISO 15118-2?

ISO 15118-20 extends the vehicle-to-grid communication standard with modular documents for AC and DC charging, bidirectional power transfer (BPT), wireless power transfer references, and improved certificate provisioning flows. It supports dynamic modes needed for V2G and fleet depot scheduling while maintaining backward compatibility paths with 15118-2 deployments.

Is ISO 15118-20 required for vehicle-to-grid?

V2G requires standardized communication of power limits, grid codes, and discharge authorization between EV, EVSE, and energy management. ISO 15118-20 BPT modules define message sets for bidirectional sessions; regional grid integrations (IEEE 1547, EN 50549) still apply at the energy layer.

Who implements the SECC versus the EVCC?

EVCC (EV Communication Controller) runs in the vehicle; SECC (Supply Equipment Communication Controller) runs in the charger. Both must implement matching ISO 15118 editions, TLS with plug-and-charge certificates, and SAP (Supported App Protocol) negotiation to agree on protocol version and energy transfer mode.

Hiring a senior Android / Flutter engineer?

I architect and ship production mobile software — Kotlin, Jetpack Compose, Flutter — for robotics, EV infrastructure, fintech, and real-time systems. Open to remote roles in Europe and the US.

Get in touch →