Skip to content
kevinferron.com

The control chain

From the grid operator through an aggregator and the charging network’s back office to the charger and the car: who sends what to whom, and the interconnection rules at the end.

  • OCPP 2.1
  • IEEE 2030.5
  • OpenADR
  • IEEE 1547

Utility or grid operator

Sends grid-code settings, power limits, prices and events

Utility to back office

Aggregator or charging operator’s back office

Builds a timeline from the utility’s events and sends OCPP messages

Back office to charger

Charger

Holds the limits; in DC it holds the inverter

Charger to car

Car

Linked to the charger by ISO 15118-20 or CHAdeMO

Interconnection layer

Under the whole chain sits the rule set for anything that can feed power into the grid. It attaches to the inverter, which is in the charger for DC and in the car for AC.OCPP 2.1 Part 2: Part R, chapter 1 and sections 2.2 to 2.3, pp. 540-542

  • IEEE 1547 and 1547.1

    The interconnection and interoperability standard for distributed energy resources, and the tests that show equipment conforms. The 2018 edition is active, with a revision project open on interoperability and information exchange.

    IEEE 1547-2018: Catalogue page; IEEE 1547.1-2020 catalogue page

  • UL 1741

    The certification standard for inverters, converters and interconnection equipment. For interactive equipment it is used with IEEE 1547 and 1547.1.

    UL 1741: Scope, sections 1.1 and 1.2

  • SAE J3072

    Secondary sources: the SAE catalogue could not be opened.

    For the car’s own inverter in US AC V2G. The CPUC describes it as the AC standard for the car, equivalent to IEEE 1547-2018 and UL 1741 SB, and says a revised edition was published on 10 June 2024.

    CPUC VGI forum, 2025: Slide 5
What each party does
  • Utility or grid operator. A grid operator, a distribution or transmission utility, sends distributed-resource controls (grid-code curves, trip settings, power limits).OCPP 2.1 Part 2: Part R, chapter 1 and section 2.1, pp. 540-541OpenADR standardises the messages for automated demand response and distributed-resource management, so that price and reliability signals pass in a uniform way among utilities, system operators and energy management systems.OpenADR overview: Overview
  • Aggregator or charging operator’s back office. In OCPP’s model the charging station operator acts as the aggregator. Its back office turns the prioritised utility events into a timeline and sends the matching OCPP messages.OCPP 2.1 Part 2: Part R, chapter 1 and section 2.1, pp. 540-541
  • Charger. The charger caps a setpoint at the charge and discharge limits and can run some modes on its own. In DC it holds the inverter, so it is the resource to configure.OCPP 2.1 Part 2: Part Q, section 2.5, p. 506; Part R, section 2.2, pp. 541-542
  • Car. OCPP’s bidirectional block covers charger-to-car links using either CHAdeMO or ISO 15118-20. In AC the inverter is in the car, and Amendment 1 of ISO 15118-20 can carry grid-code settings on to it.OCPP 2.1 Part 2: Part Q, chapter 1, p. 499; Part R, sections 2.3 to 2.5, pp. 542-543

OCPP 2.1: The back office to charger link, now with discharge

Back office to charger

OCPP 2.1: The back office to charger link, now with discharge

The specification, a free download, was read where cited.

Edition 2, 2025-12-03 (Edition 1 released 2025-01-23). Approved as IEC 63584-210.

Who talks to whom

OCPP is the open protocol between a charging station and its charging station management system.OCA: OCPP: Introduction

From the spec

  • Each schedule period carries three fields in watts or amps. The setpoint is the target and is signed: positive charges, negative discharges. The limit is the maximum charge and is positive only. The discharge limit is the maximum discharge and is negative only.setpointlimitdischargeLimitOCPP 2.1 Part 2: Part Q, section 2.1, p. 500
  • The charger caps a positive setpoint at the limit and a negative one at the discharge limit. It rejects a profile whose setpoint lies outside the range from the discharge limit to the limit.RejectedInvalidScheduleOCPP 2.1 Part 2: Part Q, section 2.5, p. 506 (requirements V2X.03 to V2X.05)
  • The bidirectional block has use cases Q01 to Q12: authorising V2X, charging only before V2X starts, central control with a schedule or a dynamic setpoint, external control, frequency support (central and local), local load balancing, idle, and going offline and resuming. The DER block has R01 to R05: starting a V2X session with DER control in the charger, in the car or hybrid across both, configuring DER settings at the charger, and reporting a DER event. Part 0 labels the same five U01 to U05 in its overview; the use-case table says R.OCPP 2.1 Part 0: Section 3.3, pp. 13-14; chapter 2, p. 7
  • DER settings travel in messages to set, get and clear a control and to notify an alarm, with control types that include volt-var, frequency droop and ride-through trips. Combined charger and car capabilities are known only after ISO 15118-20 charge-parameter discovery.SetDERControlGetDERControlClearDERControlNotifyDERAlarmNotifyEVChargingNeedsRequestOCPP 2.1 Part 2: Part R, section 2.6, p. 543; section 3.33, pp. 689-690
  • Release 2.1 adds a functional block for bidirectional power transfer and one for controlling stations and cars as distributed energy resources.OCA: OCPP 2.1 released: Release news

The operation modes

Central setpointCentralSetpointThe back office sets it

The back office sets the setpoint. With a dynamic profile it can change the setpoint in the middle of a period with an update message, without sending a new profile.

UpdateDynamicScheduleRequestOCPP 2.1 Part 2: Part Q, section 2.2, p. 501

The mode is set per schedule period, so different hours can run different modes; an unplanned change needs a new profile. Bidirectional operation requires a transaction or default transaction profile.TxProfileTxDefaultProfileOCPP 2.1 Part 2: Part Q, section 2.3, p. 505; use case Q05 prerequisites, p. 520

One quantity is written two ways in two links of the chain. OCPP 2.1 signs it: each schedule period has a setpoint that is positive to charge and negative to discharge, held within a limit that is positive only and a discharge limit that is negative only. ISO 15118-20, one link down, does not use a sign: direction is a named choice between Charge and Discharge in the power delivery request, and the limits come as separate maximum charge and maximum discharge fields. Its schema allows a negative number but does not say what one means. The sources describe no translation rule between the two; the one sign convention they show is Josev’s, an open-source implementation, which reads a negative last entry in the car’s power profile as Discharge.

The chain above that is longer than it looks, and the key fact is who is missing from it. OCPP 2.1 assumes the utility does not talk to stations or cars directly. The charging operator acts as the aggregator: it takes the utility’s controls, schedules them and passes them to the stations over OCPP. The IEA says commercial aggregators mostly run those back offices as a packaged service. The diagram therefore has no line from the utility to the car, and a chip on each link opens what that protocol carries.

On the utility side OCPP prescribes nothing. It names IEC 61850, mostly in Europe and Asia, and IEEE 2030.5, mostly in the USA, and notes that DNP3 and SunSpec Modbus are also listed. In California the IEEE 2030.5 profile is CSIP, which requires a defined set of grid functions of a smart inverter, from ride-through to volt-var, but says nothing about electric vehicles. OpenADR sits a layer above: it sends programme objectives, prices and events to systems that decide for themselves how to respond, and an aggregator can be a client of the utility and a server for its own fleet.

The link between the back office and the charger is where OCPP 2.1 differs most from 2.0.1. The earlier release has smart charging only: a text search of its specification finds no discharge or bidirectional use beyond a single parenthetical. The new one adds an operation mode to each schedule period, and the eight modes decide who sets the number: the back office, an outside system such as a site energy management system, or the charger itself from the grid frequency or the building’s meter. A mode can change from one period to the next.

At the last link a car speaks ISO 15118-20 or CHAdeMO. For CHAdeMO the page shows what one open-source charger-side implementation reads: a discharge-compatible bit in a status frame from each side, and four further frames for discharge limits, capability and estimates. That is a reading of code, not of the specification, and which CHAdeMO version first added discharge is not stated. In AC the inverter is in the car, which OCPP cannot reach directly. ISO 15118-20 Amendment 1 adds a service with two architectures to carry grid-code settings to it.

Under the whole chain sit the interconnection rules, which attach to the inverter wherever it is. IEEE 1547 and its test standard 1547.1 are the base, UL 1741 is how inverters are certified against them, and SAE J3072 is the US standard for a car’s own inverter, described here from the CPUC’s account because SAE’s catalogue could not be opened.

Sources

  1. OCPP 2.1 Part 2 OCPP 2.1 Part 2: Specification, 803 pages. Edition 2, 2025-12-03; CC BY-ND 4.0 (in the free download set).

    • Part Q, sections 2.1 and 2.5, pp. 500 and 506
    • Part R, chapter 1, p. 540
    • Part R, section 2.1, p. 541
    • Part Q, sections 2.2 and 2.3, pp. 500-505
    • Part R, sections 2.3 to 2.5, pp. 542-543
    • Part R, chapter 1 and section 2.1, pp. 540-541
    • Part Q, section 2.5, p. 506; Part R, section 2.2, pp. 541-542
    • Part Q, chapter 1, p. 499; Part R, sections 2.3 to 2.5, pp. 542-543
    • Part Q, section 2.3, p. 505; use case Q05 prerequisites, p. 520
    • Part R, chapter 1 and sections 2.2 to 2.3, pp. 540-542
    • Part Q, section 2.1, p. 500
    • Part Q, section 2.5, p. 506 (requirements V2X.03 to V2X.05)
    • Part R, section 2.6, p. 543; section 3.33, pp. 689-690
    • Part Q, chapter 1, p. 499
    • Part Q, section 2.2, p. 501; field table, p. 505
    • Part Q, section 2.2, p. 501
    • Part Q, section 2.2, p. 501; use case Q05, p. 520
    • Part Q, section 2.2, p. 502
    • Part Q, section 2.2, pp. 501-502
    • Part Q, section 2.2, pp. 502-503
    • Part Q, section 2.2, p. 505

  2. 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.

    • Power delivery request and channel selection type

  3. 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.

    • Rational number type

  4. 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, lines 851-859 and 1094-1103

  5. IEA: vehicle-to-grid technology IEA, “Vehicle-to-grid technology” (part of Global EV Outlook 2026). 2026-05-20, CC BY 4.0.

    • The charging station management system paragraph

  6. CSIP 2.1 Common Smart Inverter Profile: IEEE 2030.5 Implementation Guide for Smart Inverters (CSIP Working Group). Version 2.1, March 2018.

    • Table 1, pp. 8-9; text search of the whole guide
    • Section 1; section 2 principles 7-8; sections 3.1 and 3.2, pp. 1-4
    • Table 1, pp. 8-9
    • Sections 4.4.1, 4.5 and 5.2, pp. 8-20
    • Text search of the whole guide

  7. OpenADR on DER and V2G OpenADR Alliance, “DER, V2G, and how it relates to OpenADR”. As fetched 2026-10-24; mentions a February 2026 white paper.

    The Alliance describing its own role.

    • DER, V2G and how it relates to OpenADR

  8. OpenADR FAQ OpenADR Alliance, FAQ. As fetched 2026-10-24.

    • Questions 17 to 19

  9. OCPP 2.0.1 Part 2 OCPP 2.0.1 Part 2: Specification, 491 pages. Edition 4, 2025-12-03; CC BY-ND 4.0 (in the free download set).

    • Part K, chapter 1, p. 238 (text search)
    • Part K, chapters 1 and 2, pp. 238-240
    • Part K, section 2.4, p. 240; table of contents, pp. 278-283

  10. Battery-Emulator Open-source battery emulator, CHAdeMO “V2X mode” (CHADEMO-BATTERY.h and .cpp). Commit 7d03ad5d07a5, 2026-10-23.

    One project’s reading of the protocol, not the specification.

    • CHADEMO-BATTERY.h and .cpp, the discharge frames
    • CHADEMO-BATTERY.h lines 132 and 166; .cpp lines 118 and 468
    • CHADEMO-BATTERY.h lines 196-232 and 361-372

  11. CHAdeMO protocol CHAdeMO Association, protocol development page. As fetched 2026-10-24; version numbers read from the image file names.

    The Association describing its own protocol.

    • Overview of CHAdeMO protocol versions

  12. IEEE 1547-2018 IEEE 1547-2018, Interconnection and Interoperability of Distributed Energy Resources with Associated Electric Power Systems Interfaces (catalogue page). Approved 2018-02-15, published 2018-04-06, active; amendment 1547a-2020; revision project P1547 open.

    • Catalogue page
    • Catalogue page; IEEE 1547.1-2020 catalogue page

  13. IEEE 1547.1-2020 IEEE 1547.1-2020, the test procedures that confirm equipment conforms to IEEE 1547 (catalogue page). Approved 2020-03-05, published 2020-05-21, active; amendment P1547.1a proposed.

    • Catalogue page

  14. UL 1741 UL Standards & Engagement catalogue entry for UL 1741. Edition 3, published 2021-09-28, last revised 2026-08-14.

    Scope text only; the catalogue page does not show the text of the supplements.

    • Scope, sections 1.1 and 1.2

  15. CPUC VGI forum, 2025 CPUC Energy Division, “Vehicle-Grid Integration Forum: Interconnection”, 8 slides. 2025-04-16.

    A regulator’s slide deck; it calls its own dates approximate. It is also where the SAE J3072 facts on this page come from, since the SAE catalogue could not be opened.

    • Slide 5

  16. OpenADR 3 OpenADR Alliance, OpenADR 3 Introduction and Certification Program. As fetched 2026-10-24.

    The OpenADR 3 specification itself sits behind an email form and was not read.

    • Sections 1 and 2

  17. OCA: OCPP Open Charge Alliance, Open Charge Point Protocol page. As fetched 2026-10-24.

    • Introduction

  18. OCPP 2.1 Part 0 OCPP 2.1 Part 0: Introduction. Edition 2, 2025-12-03; CC BY-ND 4.0 (in the free download set).

    • Section 3.3, pp. 13-14; chapter 2, p. 7
    • Section 1.1, p. 3
    • Chapter 2, p. 6

  19. OCA: OCPP 2.1 released Open Charge Alliance news, “OCPP 2.1 is now available!”. 2025-01-23.

    • Release news

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

    • Abstract

  21. 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, with discharge variants

  22. furdog/chademo Open-source CHAdeMO charger implementation (furdog/chademo). Commit d3c33bf83c7825e19cd856f40bededfb1da9ab24, 2026-05-25.

    One project’s code, searched for discharge; not the specification. It is the second open-source project in the dossier’s chademoOpen reading.

    • Repository, searched at the pinned commit

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.