
What a car asks for in an ISO 15118-20 session: energy requests and a departure time, and how the Scheduled and Dynamic control modes divide the work between car and charger.
Both sliders move an illustration. They are not values from any source.
Battery energy over one plug-in session
IllustrationDrawing the requests as levels of battery energy is this page’s reading.
↑ Battery energy (relative; no unit is stated)
DepartureTimeTime from plug-in to the end of the axis (relative) →
In the illustration the path starts at plug-in, stays between the minimum and maximum lines and reaches the target at the departure time.
EVMaximumEnergyRequestrequiredEVTargetEnergyRequestrequiredEVMinimumEnergyRequestrequiredEVMaximumV2XEnergyRequestoptional, dynamic onlyEVMinimumV2XEnergyRequestoptional, dynamic onlyWhere the two V2X lines sit against the other three is this illustration’s choice. The schemas do not say.
The car asks
DepartureTime requiredWhen the car expects to leaveEVMinimumEnergyRequest requiredThe least energy the car asks forEVTargetEnergyRequest requiredThe energy the car aims forEVMaximumEnergyRequest requiredThe most energy the car asks forEVMinimumV2XEnergyRequest optionalV2XA minimum for vehicle-to-everything useEVMaximumV2XEnergyRequest optionalV2XA maximum for vehicle-to-everything useMinimumSOC optionalA state-of-charge floorTargetSOC optionalA state-of-charge targetThe charger answers
DepartureTime optionalA departure time in the answerMinimumSOC optionalA state-of-charge floor in the answerTargetSOC optionalA state-of-charge target in the answerNot in this mode
EVEnergyOfferScheduleTupleChargingScheduleDischargingSchedule
DepartureTimeEVMinimumV2XEnergyRequestEVMaximumV2XEnergyRequestDynamic_SEReqControlModeISO 15118-20 common messages (XSD): Dynamic schedule-exchange request and responseRationalNumberTypeISO 15118-20 common messages (XSD): Schedule-exchange types; no annotationsBefore power flows, the car tells the charger what it wants and when it is leaving, and the charger answers. In ISO 15118-20 that happens in the schedule exchange, which comes in two forms, the Dynamic and the Scheduled control mode, and a session uses one. In the Dynamic mode the car states its needs and the charger answers with only optional extras: a departure time, state-of-charge limits and a price schedule. In the Scheduled mode the charger answers with schedules to choose from.
In the Dynamic mode the car must give a departure time and three energy requests, a minimum, a target and a maximum, and it may add two V2X energy requests, a minimum and a maximum, along with state-of-charge limits. The V2X pair exists only in Dynamic contexts: the schedule exchange, and the bidirectional charge loops in both DC and AC. The charger’s answer carries no power schedule. The chart draws the three requests as three levels, with the V2X pair as optional extra lines; that drawing is this page’s reading, not something the schemas say.
In the Scheduled mode the charger offers one to three schedule tuples. Each holds a required charging schedule and an optional discharging schedule, and a schedule is a list of up to 1024 entries, each a duration and a power value. The car’s departure time and energy requests are optional here, and the V2X energy requests do not exist. The table shows which fields belong to which mode, read from the same data the chart uses.
Only in Dynamic
EVMinimumV2XEnergyRequestThe car asksEVMaximumV2XEnergyRequestThe car asksMinimumSOCThe car asksTargetSOCThe car asksDepartureTimeThe charger answersMinimumSOCThe charger answersTargetSOCThe charger answersOnly in Scheduled
EVEnergyOfferThe car asksScheduleTupleThe charger answersChargingScheduleThe charger answersDischargingScheduleThe charger answersIn both, but required only in Dynamic: DepartureTimeEVMinimumEnergyRequestEVTargetEnergyRequestEVMaximumEnergyRequest
The values on the chart are an illustration, and the page says so wherever they appear. What the sources give is the field names, which mode has which field, and whether it is required or optional. They state no unit for an energy request, a power value, a duration or the departure time, so the axes are relative. They also do not say how the V2X requests relate to the other three, or how a charger should turn a request into power: the path and the schedules are there to show the idea, not a rule.
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.
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.
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.
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.
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.