kevinferron.comKevin Ferron

A bidirectional session, step by step

An ISO 15118-20 bidirectional power transfer session in the order one open-source implementation runs it, with the messages that carry the discharge limits and the charge or discharge flag.

  • ISO 15118-20
  • BPT

The starting point

  • ISO 15118-2 is charge-only. A search of all five of its schemas for discharge, bidirectional, V2X and reverse finds nothing, its energy-transfer modes have no bidirectional entry, and its abstract says the bidirectional use cases wait in Part 1 and would need enhancements to its messages.ISO 15118-2 schemas: All five schema files; energy transfer mode type
  • Bidirectional power transfer needs ISO 15118-20, which defines the messages and sequence requirements for it.ISO 15118-20: Abstract
Session
Control mode

The control mode changes what a few steps carry, marked below; the rest are the same in both.

  • In Josev’s simulator charger the control mode is one of the parameters offered in service detail.Josev: iso15118/secc/controller/simulator.py, parameter sets
  • The car selects it in service selection, which picks one energy-transfer service by its number and a parameter set.ServiceSelectionReqISO 15118-20 common messages (XSD): Service selection request
BPT shows up here The control mode matters here Josev can repeat it

No message pair is BPT-only. The marked steps are where BPT shows up, or, for the three service steps, where the bidirectional service is offered and chosen, which is this page’s reading. The unmarked steps are the same messages a charge-only session uses.ISO 15118-20 common messages (XSD): Message pairs; the DC, AC and common-types files hold the variants

ISO’s schemas give no message order. This order is Josev’s, one open-source implementation’s, read from the state each state names next. Reading the order of the common messages in the schema file as the session order would be an inference.Josev: iso15118_20_states.py, next-state targets

Step 1: Session setup

1. Session setup

No BPT change

DC session, Dynamic mode.

The message pair

SessionSetupReqSessionSetupResISO 15118-20 common messages (XSD): Message pairs

What BPT changes

  • BPT does not change this message pair. It shows up in three ways: BPT variants inside charge-parameter discovery and the charge loop, one optional direction field in power delivery, and optional BPT fields in the meter record, a discharged-energy counter and an inductive reactive-energy reading. The schedule exchange also carries discharge content with no BPT prefix.ISO 15118-20 common types (XSD): Meter info type; the variants are in the DC, AC and common-messages files
Step 1 of 15

Across the session

  • The meter record keeps one counter per direction: charged energy is required and discharged energy is optional. Both are unsigned, so the meter is not one signed net figure. A second optional BPT field holds an inductive reactive-energy reading.MeterInfoTypeChargedEnergyReadingWhBPT_DischargedEnergyReadingWhBPT_InductiveEnergyReadingVARhISO 15118-20 common types (XSD): Meter info type
  • Units: not stated in what was read. The schemas carry no unit for any limit, energy request or time. A reading such as value times ten to the exponent is an inference from the field names.RationalNumberTypeISO 15118-20 common types (XSD): RationalNumberType; no annotations

ISO 15118-2, the first-generation protocol between charger and car, is charge-only. Its abstract says its messages support energy transfer from the charger to the car and that the bidirectional use cases sit in Part 1, where using them would need enhancements to the message set. A search of its five schemas for discharge, bidirectional, V2X and reverse finds nothing, and its list of energy-transfer modes has no bidirectional entry. Bidirectional power transfer therefore needs ISO 15118-20, which defines the messages and the sequence requirements for it.

What is striking about -20 is how little it adds. No message pair is bidirectional-only. Bidirectional transfer appears in three ways: variants that swap into the shared charge-parameter-discovery and charge-loop messages, one optional field in the power-delivery request that says whether the channel is charging or discharging, and optional bidirectional fields in the meter record, a discharged-energy counter and an inductive reactive-energy reading. The schedule exchange also carries discharge content with no such prefix. The service steps are marked too, as the place where the bidirectional service is offered and chosen, which is this page’s reading. Every unmarked step is the same message a charge-only session uses.

The order of the steps is not ISO’s. The schemas carry no sequencing, and reading the order of the common messages in the schema file as the order of a session would be an inference. The order shown is the one Josev, an open-source implementation, runs: for DC, from session setup through service selection, charge-parameter discovery, schedule exchange, cable check, pre-charge, power delivery, the repeating charge loop, power delivery again, welding detection and session stop. The AC session is the same up to schedule exchange, then goes to power delivery, the loop, power delivery and stop, because the AC set has no cable-check, pre-charge or welding messages.

Direction is carried by names rather than by a sign. A limit gets its direction from separate charge and discharge field names, the one direction flag is the optional channel selection in power delivery, and the meter keeps a charged counter and a separate, optional discharged counter, both unsigned, so there is no signed net figure. In DC, charge-parameter discovery gives each side four required discharge limits, and the loop drops the car’s minimum discharge current. In AC the limits are power only, with optional twins for the second and third phase. What a negative power value means is not stated in the schemas; Josev reads a negative last entry in the car’s power profile as discharge.

The service numbers and the bidirectional parameters are not in the schemas either. They come from two open-source implementations: Josev numbers the AC and DC bidirectional services 5 and 6, and EVerest agrees. Both name a channel setting and a generator mode, and both have a grid-code islanding-detection parameter, though they spell its name differently and the standard’s table was not read, so which spelling is right is not settled here. The schemas also state no units for any limit, energy request or time, so this page adds none.

Sources

  1. ISO 15118-2 ISO 15118-2:2014, Part 2: Network and application protocol requirements. Ed. 1, 2014-04 (catalogue abstract).

    • Abstract, first paragraph

  2. ISO 15118-2 schemas ISO’s openly published schema folder for ISO 15118-2 (five XSD files). Folder named ed-2; MsgBody last modified 2013-08-20.

    The catalogue lists the published -2 as Edition 1, 2014.

    • All five schema files; energy transfer mode type

  3. ISO 15118-20 ISO 15118-20:2022, Part 20: 2nd generation network layer and application layer requirements. Ed. 1, 2022-04 (catalogue abstract).

    • Abstract

  4. ISO 15118-20 common messages (XSD) V2G_CI_CommonMessages.xsd, ISO’s openly published schema. Ed. 1, last modified 2021-10-12.

    The schema carries no annotations: no units, no message order and no service numbers.

    • Message pairs; the DC, AC and common-types files hold the variants
    • Message pairs; no sequencing in the schema
    • PowerDeliveryReq and the channel selection type
    • Service discovery and service list types
    • Service detail response, parameter sets
    • Service selection request
    • Schedule exchange request and response; control-mode choice
    • Scheduled schedule-exchange request
    • Scheduled schedule-exchange response
    • Dynamic schedule-exchange request
    • Dynamic schedule-exchange response
    • EVPowerProfile, scheduled control mode
    • EVPowerProfile, dynamic control mode
    • Message pairs

  5. ISO 15118-20 DC messages (XSD) V2G_CI_DC.xsd, ISO’s openly published schema. Ed. 1, last modified 2021-08-23.

    The schema carries no annotations: no units, no message order and no service numbers.

    • Charge parameter discovery and charge loop variants
    • Charge parameter discovery, request and response variants
    • Charge parameter discovery variants
    • Charge loop variants, scheduled and dynamic
    • DC charge loop request and response
    • Scheduled charge loop variants
    • Charge loop variants against discovery
    • Message pairs
    • Dynamic charge loop variants

  6. ISO 15118-20 common types (XSD) V2G_CI_CommonTypes.xsd, ISO’s openly published schema. Ed. 1, last modified 2021-10-12.

    The schema carries no annotations: no units, no message order and no service numbers.

    • Meter info type
    • Meter info type; rational number type
    • RationalNumberType; no annotations
    • Meter info type; the variants are in the DC, AC and common-messages files
    • Dynamic charge loop base types

  7. Josev Open-source ISO 15118 implementation in Python (SwitchEV iso15118): the order of the messages in a session. Version 0.31.2, commit 1d29f53982d3, 2026-10-13.

    One implementation’s state machine, not ISO text.

    • iso15118_20_states.py, next-state targets
    • iso15118_20_states.py, channel selection
    • iso15118/shared/messages/enums.py, service IDs and BPT parameters
    • iso15118/secc/controller/simulator.py, parameter sets
    • iso15118_20_states.py, channel selection; CHANGELOG 0.23.2
    • iso15118_20_states.py, session stop
    • iso15118/shared/messages/enums.py, service IDs
    • iso15118/shared/messages/enums.py, BPT parameters

  8. ISO 15118-20 AC messages (XSD) V2G_CI_AC.xsd, ISO’s openly published schema. Ed. 1, last modified 2021-08-23.

    The schema carries no annotations: no units, no message order and no service numbers.

    • AC message pairs
    • AC variants
    • Charge parameter discovery variants
    • AC charge loop variants
    • Scheduled charge loop variants
    • Dynamic charge loop variants
    • Message pairs

  9. EVerest libiso15118 EVerest’s open-source ISO 15118 library in C++ (archived): service numbers and the parameters of the bidirectional services. Commit 5c81c928dada, 2025-11-25.

    One implementation’s code, not ISO text.

    • common_types.hpp and src/iso15118/message/service_detail.cpp
    • include/iso15118/message/common_types.hpp, service IDs
    • src/iso15118/message/service_detail.cpp, parameter names
    • common_types.hpp and d20/session.hpp, parameter lists

Everything here is paraphrased from the pinned sources, not quoted. The SAE entries rest on secondary sources, because SAE’s own catalogue could not be opened; an industry body’s reading is labelled as one. Anything illustrative is labelled as such. Where a source is silent the page says so instead of filling the gap.