OpenADR 3.0 for Charge Point Operators
💡 OpenADR 3.0 for CPOs: Key Highlights
- OpenADR 3.0 turned a protocol project into an API project. 2.0b’s SOAP/XML became a REST/JSON API with OAuth 2.0 tokens and server-side TLS — the mutual-TLS PKI work is gone.
- OpenADR does not control chargers. Your CSMS does. A grid event only slows a session once your backend turns it into an OCPP
SetChargingProfile. - Aggregated beats direct for almost every multi-site operator. One VEN for a 400-connector network instead of 400 cuts the enrolment surface 400:1.
- 2027 is the practical European deadline. ACER sent its proposed EU network code on demand response to the Commission on 7 March 2025; national implementation follows around 2027.
- Urgency is set by your market, not the standard. India has price signals but no interface mandate; California mandates IEEE 2030.5 with the CSIP profile, not OpenADR.
If you run a charging network in Europe, OpenADR 3.0 is moving from the interesting-standards-news pile onto your integration roadmap. This is written for CPO and eMSP technical decision-makers — and the utility-partnership leads beside them — who already accept demand response as a revenue line and now need to know how a grid signal physically reaches a connector. We are not re-litigating the basics: our FAQ covers what OpenADR is and how it evolved, and an earlier post covers why OpenADR matters in EV charging. What follows is the layer underneath both.
Two sentences of definition, then we move on. OpenADR is an open, IEC-standardised protocol that lets a utility, aggregator or market operator publish demand response and pricing signals to assets that can act on them. Version 3.0, launched at Enlit Europe in Paris on 28 November 2023, redesigned how those signals travel and changed nothing about what they mean — which is precisely why a 3.0 integration costs less than a 2.0b one did.
Two Protocols, Two Jobs: Where OpenADR Sits Next to OCPP
The most common misconception in CPO procurement is that OpenADR and OCPP are alternatives. They are not — they sit at opposite ends of the same wire. OpenADR is the grid-to-operator layer: programs, events, prices and reports between a market party and whoever is responsible for a fleet of flexible assets, with no concept of a connector, a session or a state of charge. OCPP is the operator-to-charger layer: authorisation, transactions, meter values and charging profiles between your backend and each charge point, with no concept of a wholesale price or a settlement baseline.
Nothing in either protocol bridges the gap. Your platform is the bridge — which is why the OpenADR Alliance publishes a dedicated note on pairing the two. If your estate already runs on OCPP-compliant charging software, you have half the chain, and the weaker half sets your ceiling: a perfect OpenADR 3.0 VEN in front of an OCPP 1.6 estate achieves little, because 1.6’s profile control is too coarse for a utility asking for 500 kW of reduction. A 2.0.1 estate with no grid interface can follow your own tariff logic but cannot be dispatched — so it cannot be prequalified or paid in a flexibility market.
The VTN/VEN Model in Plain Operational Terms
The Virtual Top Node (VTN) is the server. It publishes programs (a named scheme with its rules) and events (an interval with a target or price), and collects reports. In practice it is run by a DSO, a TSO-facing aggregator, a retailer or a flexibility-market platform. VTNs must implement the full feature set — they are the interoperability anchor.
The Virtual End Node (VEN) is the client. It registers against a program, receives events, opts in or out, acts, and reports back. Critically, the specification never says what a VEN physically is: one charger, one site, or your entire back office representing thousands of connectors. That is the architecture decision in the next section.
3.0 changed one thing about the roles. Under 2.0b the complex message structure forced business logic inside the VTN; 3.0 separates them, so the VTN serves data while whatever decides what that data should be sits elsewhere — meaning the party owning the dispatch logic and the party owning the API endpoint need not be the same organisation.
One honest caveat on certification
There is no EV-specific OpenADR certification profile yet. The defined VEN profiles are Continuous Pricing and Baseline; EVSE Management and Inverter Management are prospective, not published. So when a vendor says “OpenADR 3.0 certified,” ask against which profile — it will not be an EVSE one, and your implementation has to close the gap.
Direct vs Aggregated: The One Architecture Decision That Matters
The OpenADR Alliance’s own guidance on pairing OpenADR with OCPP describes exactly two methods for bringing charging stations into a DR program. Every real deployment is one of them, and the choice sets your integration cost and your commercial leverage.
- Enrolment surface: one registration and credential cycle per charger.
- Granularity: asset-level visibility — attractive to a DSO managing one feeder.
- Optimisation logic: at a charger that knows nothing about your other sites.
- Commercial control: weakest — the utility talks past you to your hardware, and a certificate or firmware lapse silently drops assets.
- Enrolment surface: one registration for the whole estate, at any size.
- Granularity: you report an aggregate and decide internally how to deliver it.
- Optimisation logic: where portfolio state lives — SoC, deadlines, capacity, tariffs.
- Commercial control: strongest — you are the market’s counterparty, at the cost of one integration being a single point of failure.
Why the numbers settle this quickly
Take an operator with 400 connectors across 60 sites. Direct topology means 400 VEN registrations, 400 credential sets to rotate and 400 places for a firmware update to break compliance. Aggregated means one.
The stronger argument is about who gets to be clever. Say the VTN issues a 60-minute event asking for 500 kW of reduction. In the aggregated model your backend can protect the 12 sessions already above 80% state of charge, exempt depot vehicles with an 06:00 departure commitment, and take the whole reduction from 40 sessions where a slower ramp costs the driver nothing. No single charger can make that trade, because no single charger knows the portfolio exists. It is the same calculation dynamic load balancing across sites already runs against your own connection limits — a grid interface just adds an external constraint to the same solver. Which is why a charging management platform like YoCharge is the natural home for the VEN: it holds every input the decision needs.
What Changed in OpenADR 3.0 — and Why It Lowers Integration Cost
- REST/JSON replaces SOAP/XML. 2.0b was a SOAP web service with XML payloads and a push/pull model. 3.0 is a RESTful API with JSON bodies and webhook-style subscriptions — the shape every backend team already builds.
- OAuth 2.0 tokens replace mandatory mutual TLS. 2.0b’s mutual-TLS requirement meant a certificate-management project, often the longest pole in the tent. 3.0 uses server-side certificates plus bearer tokens.
- The normative spec is an OpenAPI (Swagger) YAML document, so your team can generate a typed client instead of hand-rolling message handling against prose.
- Opt-in and opt-out fold into event definitions, removing the separate participation mechanism 2.0b needed — and a class of state-synchronisation bugs with it.
- OpenADR 3.1.0 (September 2025) added the
programconstruct, simplifying enrolment of one portfolio in multiple markets — relevant if you operate across DSO areas or countries.
3.0 does not obsolete 2.0b — and certification is young
This matters in procurement. 3.0 is an additional, simplified path, not a replacement for 2.0a/b, which remains widely deployed by utilities; commercial VTNs get six months from publication of the initial certification profiles before they must support both. Ask which version the VTN you will connect to actually speaks — a 3.0-only VEN talking to a 2.0b-only VTN is a stalled project, not an integration.
The first certified 3.0 products were announced on 24 March 2025 at DISTRIBUTECH: E.ON Energy Networks’ SWITCH platform as the first certified VTN, alongside EVoke Systems’ Energy Services Exchange and an open-source VEN from Universal Devices. Testing runs through ten approved facilities, with 50-plus products certified across all versions. A functioning ecosystem, but a young one — treat vendor claims as checkable facts, not adjectives.
From Grid Event to Charging Profile: The Signal Chain
This is the part most standards explainers skip, and the part that decides whether a DR integration earns money. The full chain, in the aggregated topology:
The program carries the scheme’s rules; the event carries an interval, a target and a signal type — a price, a capacity limit, or a reduction against a baseline.
The event arrives over the subscription and your backend opts in or out inside the response window — a decision, not a formality: opting in creates an obligation with a penalty attached.
Sites in scope, active sessions, state of charge, departure commitments, and headroom against each site’s contracted capacity. This step has no protocol — it is your product.
Your CSMS issues SetChargingProfile to the selected connectors for the event window, or a TxDefaultProfile for a standing limit. OCPP 2.0.1 and later give per-connector, time-scheduled control; 1.6 is coarser and limits what you can promise a market.
Chargers apply the limit and power tapers. Whether this costs you a complaint depends entirely on how well step 3 chose its targets.
Meter values and transaction records come back over OCPP, your platform aggregates them against the event baseline, and reports go to the VTN. Most projects underestimate this step: without per-session interval data at measurement-and-verification quality, you delivered the reduction, cannot prove it, and do not get paid.
Two dependencies fall out of the chain. First, your demand-responsive charging capability has to be real before a grid interface is worth building — steps 3 to 5 are the same machinery whether the trigger is external or your own tariff. Second, step 4 is version-sensitive; our breakdown of OCPP 2.1 versus 2.0.1 covers what each can express. OCPP 2.1, released in January 2025 and published as IEC 63584-210:2025, adds a dedicated DER control functional block and bidirectional (V2X) support — where this conversation heads next.
The 2027 Regulatory Driver: Why This Stops Being Optional
A grid-facing interface has so far been a commercial choice: build it if a flexibility revenue line pencils out. In Europe that is changing, and the timeline is public.
- May 2024 — the EU DSO Entity and ENTSO-E submitted their joint draft network code on demand response, plus amendments to three related electricity regulations, to ACER.
- Autumn 2024 — ACER revised the draft and ran a public consultation.
- 7 March 2025 — ACER submitted its proposal to the European Commission, which then begins establishing the Demand Response Regulation and amending the three related regulations.
- Around 2027 — national implementation. Once adopted, the code is legally binding across the EU.
The code covers market access for smaller players, service-provider prequalification, transparent procurement of system-operator services, and TSO/DSO coordination. Read carefully, it names no protocol — it is market-participation law, not a technical specification. That is exactly where operators get complacent. If flexibility must be prequalified, dispatched and verified to be sold, somebody’s machine has to talk to your machine over a standardised interface — and across European member states the two answers in practice are OpenADR and EEBUS. A network with no grid-facing interface is not non-compliant in 2027; it is ineligible, which is commercially worse.
Where AFIR fits
European CPOs have already absorbed one compliance wave: the Alternative Fuels Infrastructure Regulation set the floor on deployment density, ad-hoc payment, price transparency and data access — covered separately in AFIR’s requirements for European charge points. The demand response code adds the dimension AFIR left untouched: not how drivers reach your chargers, but how the grid reaches them. Same estate, same platform, different counterparty. And the arithmetic is unforgiving — a VEN integration plus M&V-grade metering plus the dispatch logic in step 3 is a two-to-three-quarter programme, so counting backwards from 2027 puts the scoping conversation in the next few quarters.
Do You Need OpenADR 3.0 Yet? A Decision Aid by Market
For most operators outside Europe the honest answer is: not this year. Urgency is set by your market’s regulatory posture and by which interface its programs actually procure against.
| Market | Interface reality today | Urgency |
|---|---|---|
| EU / EEA | Demand response network code in progress (ACER proposal, 7 March 2025); OpenADR or EEBUS depending on the member state; AFIR already binding. | High — scope a VEN in the next two to three quarters. |
| United Kingdom | DSO and DNO flexibility tenders already procure from aggregators and asset owners; participation is contractual, not protocol-mandated. | Medium-high — usually reached via an aggregator’s VEN before your own. |
| India | Time-of-Day tariffs mandated by the Electricity (Rights of Consumers) Amendment Rules, 2023 — solar-hour tariff at least 20% below normal, eight solar hours set by the state commission, public charging supply at 0.8× average cost of supply in solar hours versus 1.2× outside. No DR interface mandate. | Low for OpenADR — the money is in tariff-aware scheduling first. |
| US — California | Rule 21 has required DERs interconnecting with PG&E, SCE and SDG&E to use IEEE 2030.5 with the CSIP profile (18 of 30-plus function sets) since June 2020; OpenADR handles DR signalling alongside it. | Medium — expect to implement both, not one. |
| US — other ISO/RTOs | Program-specific. PJM and similar markets are usually reached through an aggregator, and the interface is set by the program, not the region. | Medium — follow the program spec, not the standard. |
Market posture as of September 2026. Verify against your specific DSO, utility or market operator before committing engineering.
What to ask your platform vendor before you commit
- Does the CSMS act as a VEN itself, or need a gateway? A gateway is another box, another failure domain and another licence.
- Which OpenADR version, certified against which profile? “OpenADR-ready” is marketing; a certification record is a fact.
- Can charging profiles be targeted by attribute, not just by group? Protecting near-complete sessions requires selecting on session state, not a static site list.
- Can it export per-session interval data at M&V quality? Ask for the format and resolution, then show it to whoever settles your payments.
- What happens to an accepted event when a charger drops offline mid-window? Under-delivery carries a penalty, so this is a commercial term, not a technical detail.
None of this answers whether a DR program is worth joining — that is a revenue, risk and contract question, treated separately in the business case for joining a demand response programme. Read that one to decide whether; this is the technical companion that tells you how.
Frequently Asked Questions
Practical answers on OpenADR 3.0, VEN topology and what CPOs actually have to build.
Sources: OpenADR Alliance — OpenADR 3.0 | OpenADR Alliance — Using OpenADR with OCPP | ACER — New network code on demand response | ENTSO-E — Joint network code submission | Open Charge Alliance — OCPP 2.1 | Ministry of Power — ToD tariff rules
Grid-ready charging operations
Build the grid-facing layer once, on a platform that already owns the charger side
Aggregated VEN topology, attribute-level charging profiles over OCPP, and per-session interval data your settlement counterparty will accept. Walk us through your estate and your target market, and we will map what a demand response integration actually takes.
Talk to Sales