OpenADR 2.0 and EV Charging: How Grid Operators and Charge Networks Can Coordinate Load

EV charging loads are not like traditional commercial loads. They're discrete, bursty, and increasingly dense — a depot with 40 DC fast chargers pulling 150 kW each represents 6 MW of potential simultaneous demand on a distribution transformer that was likely sized for nothing close to that figure. Utilities are increasingly aware of this, and an expanding cohort of grid operators is moving from awareness to requirement: large charging deployments in their territory must be able to respond to demand signals, or they face interconnection delays, curtailment orders, or simply can't get the load approval needed to proceed.

OpenADR 2.0b is the mechanism that makes coordinated demand response between grid operators and charge networks technically feasible. This post explains what the protocol actually does, how it maps to EV charging control logic, and why most CPO software platforms are not yet positioned to support it without custom integration work.

What OpenADR 2.0b Is and What It Isn't

OpenADR (Open Automated Demand Response) is a standardized protocol for communication between utilities or grid operators (called Virtual Top Nodes, or VTNs) and demand response participants (Virtual End Nodes, or VENs). The 2.0b profile is the current widely-deployed version, defined by the OpenADR Alliance under IEC 62746-10-1.

At the protocol level, OpenADR 2.0b handles event signaling and report acknowledgment. The utility VTN sends an oadrDistributeEvent payload to the CPO VEN endpoint describing an event: its type (SIMPLE for level-based signals, ELECTRICITY_PRICE for real-time tariff signals, LOAD_DISPATCH for explicit curtailment), its duration, and its signal level (typically 0–3, where 0 is normal and 3 is maximum curtailment). The VEN acknowledges receipt and, optionally, sends back telemetry reports on actual load consumption.

What OpenADR does not do is tell your chargers what to do. That's your job. The protocol delivers the signal; your platform has to translate that signal into OCPP charging profiles, schedule adjustments, or session priority rules.

The Translation Layer: From OpenADR Signal to OCPP Charging Profile

This is where the real engineering work lives. Consider a practical scenario: a CPO operating a 20-charger DC fast charging site at a distribution-level load point. The serving utility issues a LOAD_DISPATCH event with signal level 2 (moderate curtailment) lasting 45 minutes, effective in 10 minutes. What happens?

On the utility side, the event is sent to the registered VEN endpoint at the CPO's operations platform. On the CPO side, the platform needs to:

1. Parse and validate the incoming OpenADR event envelope — including the oadrSignalPayload with its duration and signal value.
2. Map signal level 2 to a curtailment percentage — this is typically defined by a bilateral agreement with the utility, or by a default curtailment table the CPO configures. For a 3 MW site, level 2 might mean 40% reduction, targeting 1.8 MW.
3. Distribute the curtailment across active sessions. The simplest approach is proportional: reduce all active charging profiles by 40%. The operationally smarter approach is priority-based: protect sessions flagged as high-priority (fleet vehicles with departure windows) and curtail lower-priority or idle-buffer sessions first.
4. Issue SetChargingProfile commands via OCPP 1.6J or 2.0.1 to each affected charge point, updating the active charging schedule.
5. Send telemetry back to the VTN via an OpenADR report payload confirming the load reduction.

The translation from step 2 to step 4 is not standardized — it's CPO business logic. And it needs to execute within the OpenADR event lead time, which is commonly 10–15 minutes for day-ahead economic events and as short as 2 minutes for emergency curtailment events. That timeline puts real requirements on your control loop latency.

Why Most CPO Platforms Aren't Ready

The challenge isn't awareness of OpenADR. Most CPO software vendors know it exists. The challenge is that implementing a production-ready VEN endpoint that handles the full OpenADR 2.0b message set — event polling via push and pull modes, dynamic registration, event opt-out, report payloads — is non-trivial, and it's not something that comes bundled with a standard OCPP gateway.

A common pattern is CPO platforms that implement OpenADR superficially: they can receive a simple curtailment event and reduce maximum charge power across the site, but they can't handle the reporting side (which utilities often require for program verification), can't do priority-based session management, and can't process the ELECTRICITY_PRICE signal type needed for time-of-use optimization. This partial implementation may satisfy initial utility requirements for program enrollment but creates gaps when the utility audits actual demand response performance.

We're not saying every CPO needs full OpenADR 2.0b compliance on day one. For an operator with a small deployment below the demand response threshold in their service territory, OpenADR is not an immediate operational requirement. But for deployments above the 1 MW threshold that many utilities now treat as the starting point for demand response program participation, it becomes a precondition for site permitting in some markets.

The Reporting Obligation Is Often Underestimated

Utilities running demand response programs don't just want signal acceptance — they want performance verification. The OpenADR report mechanism (oadrCreateReport / oadrUpdateReport) is how this happens. The VEN is expected to register reporting capabilities and then send metered or estimated load data back to the VTN during and after each demand response event.

For a CPO, this means the platform needs to aggregate actual metered energy consumption data from each charge point — typically via OCPP MeterValues — reconcile it to the site-level load, and transmit it in the OpenADR report format on the interval the utility specifies (commonly every 5 or 15 minutes during an event). If your charge point hardware has inconsistent meter reporting fidelity, or if your OCPP gateway doesn't persist high-frequency MeterValues data, the reporting chain breaks.

Some utilities also require baselining: they want to see what load the site would have consumed in the absence of the demand response event, so they can quantify the actual curtailment. This baseline calculation — often done via a similar-day comparison or a regression model — adds another data processing requirement to the CPO platform.

Implementation Priorities for CPOs Evaluating Demand Response Programs

If you're evaluating participation in a utility demand response program for a new or existing charging deployment, the sequence of questions to work through with your platform provider is: Does the platform implement a conformant OpenADR 2.0b VEN? What event types are supported (SIMPLE, ELECTRICITY_PRICE, LOAD_DISPATCH)? How does the curtailment-to-charging-profile translation work, and is it configurable? What telemetry reporting cadence can the platform sustain? And — importantly — has the integration been tested against the specific utility VTN, or only against reference implementations?

Reference implementation compatibility doesn't guarantee production compatibility with a specific utility's VTN. Grid operators often deploy customized OpenADR configurations. Testing the full round-trip — event delivery, acknowledgment, control action, and reporting — against the actual VTN in a pilot environment before program enrollment saves considerable post-deployment pain.

The grid integration pathway for EV charging is becoming a regulatory requirement in more markets, not just an optimization opportunity. CPOs who build the OpenADR integration capability now are better positioned for interconnection approval, utility incentive programs, and the longer-term V2G landscape where bidirectional grid participation becomes the norm rather than the exception.