OpenADR
Open Automated Demand Response — a standardized communication protocol for automating Demand Response signal exchange between utilities, system operators, and customer energy management systems. Standardized as IEC 62746-10-1 and maintained by the OpenADR Alliance (www.openadr.org).
In Sweden, OpenADR is the industry-recommended protocol for communication between DSOs and customers with conditional grid connections — adopted as a voluntary standard by Energiföretagen Sverige in October 2023 following a market-wide evaluation. (Source - Energiföretagen Branschrekommendation Conditional Grid Connections (2023))
Core architecture
OpenADR defines a server–client communication model:
| Role | Description | Swedish context |
|---|---|---|
| VTN (Virtual Top Node) | Server — publishes events, receives reports | DSO (e.g., SWITCH or Ellevio platform) |
| VEN (Virtual End Node) | Client — receives events, executes, reports | CPO / customer energy management system |
| Business Logic (BL) | DSO application layer driving VTN | Grid monitoring, threshold detection, event creation |
| Customer Logic (CL) | Customer application layer driving VEN | Resource control (EV charger, battery, HVAC) |
The BL/CL layers are explicitly separated from the VTN/VEN in OpenADR 3 — the protocol layer should be a generalized interface; business-specific logic lives outside it.
A VEN can receive events by polling (HTTP pull) or webhooks (server push). Webhooks are recommended for reduced overhead but require additional security and robustness investment.
Version comparison
| Property | 2.0b | 3.0 / 3.0.1 |
|---|---|---|
| API style | SOAP/XML | REST/JSON |
| Authentication | Centrally authorized client certificates | Adaptable to application security level |
| Registration flow | Stricter, more predictable | Looser, more flexible |
| Specification rigidity | Stricter | Looser — more implementation variation possible |
| Standard form | IEC 62746-10-1 | IEC 62746-10-1 (updated) |
| Swedish recommendation | Legacy (PoC only) | Recommended for new implementations |
Recommended version for Sweden: 3.0.1 — most future-proof, REST/JSON-based, easiest to implement and maintain. (Source - Energiföretagen Supplement Conditional Grid Connections (2025))
Key entities in a conditional agreements implementation
Program
A VTN may have multiple programs; one typically suffices for conditional connections. Programs communicate metadata to VENs and can contain default payload descriptors.
Event
The core entity. An event specifies:
- Target (resource ID or VEN-level)
- Interval period (start time and duration)
- Payload (type and value — e.g., power limit in KW)
- Report request (what acknowledgement/data to send back)
Report
Sent by the VEN in response to an event. Contains resource name, interval, and payload (e.g., acknowledgement, metered value, heartbeat status).
Swedish production implementations
As of April 2025, two Swedish DSOs have live production OpenADR 3 implementations for Villkorade Avtal:
E.ON variant
- Start: next hourly-aligned 15-minute period (13:00, 13:15, 13:30, 13:45)
- Duration:
PT15M - Payload type:
CONSUMPTION_POWER_LIMITorPRODUCTION_POWER_LIMIT - Unit:
KW(maximum allowed power) - Report:
POWER_LIMIT_ACKNOWLEDGEMENT(sent immediately) - Real-time metering: required (VEN must report power readings)
- Advantages: dynamic limits, enables real-time delivery validation, supports load-splitting
Ellevio variant
- Start: immediate (
"0000-00-00T00:00:00.000Z") - Duration:
PT20M - Payload type:
SIMPLE— values"Curtail"or"Restore" - Limit: pre-agreed and known by VEN; not in event payload
- Sequence: Curtail → 15 min → Restore; if issue persists → new Curtail
- Report:
SIMPLE— values"Executed"or"Not executed" - Real-time metering: not required
- Advantages: simpler integration, no metering dependency
Full convergence between DSOs has not been achieved as of the supplement’s publication. (Source - Energiföretagen Supplement Conditional Grid Connections (2025))
Heartbeat monitoring
A standard operational pattern: the VTN sends regular heartbeat events; the VEN responds with reports indicating resource status ("OK" or "NOT_OK"). Recommended:
- Use a separate OpenADR program for heartbeats (enables independent pruning of historic events)
- Two targeting modes: specific resource (by
RESOURCE_NAME) or all VEN resources ("VEN_REPORT") - Interval duration:
PT0S(zero-length — the heartbeat is a check, not a delivery period)
Protocol selection rationale (2023 evaluation)
Energiföretagen’s 2023 working group evaluated four protocols: OpenADR, OSCP (Open Smart Charging Protocol), IEEE 2030.5-2018, and IEC 61850-7-420. IEEE and IEC 61850-7-420 were eliminated early. OpenADR was preferred over OSCP because:
- More international adoption — used by more actors globally
- Broader use case support — covers forecasting, real-time control, reporting, multiple flexibility types (not just EV charging)
- IEC standardization — recognized standard, internationally viable
- Future-proofing — OpenADR 3.0 in development at evaluation time; active evolution
The evaluation was based on OpenADR 2.0b; the Proof-of-Concept used 2.0b (E.ON SWITCH VTN + Vattenfall VEN/OpenLEADR) to validate the concept before 3.0 was available. The tested E.ON VTN implementation established the 15-minute delivery period that persists in the 3.0 variant. (Source - Energiföretagen Branschrekommendation Conditional Grid Connections (2023))
CPOs as primary adopters
The primary customer segment for Swedish conditional connections is CPO (Charge Point Operator) — operators of EV charging infrastructure who want to connect large loads in areas with grid constraints. CPOs are the actors most affected by DSO fragmentation: a CPO with installations in multiple grid territories would need to support multiple protocols if no industry standard existed.
Aggregators and payment service providers can act as agents for CPOs in the activation flow.
Implementation practicalities
- VTN development: more complex; primarily a challenge for DSOs. Smaller DSOs may use third-party solutions
- VEN development: less complex; multiple open-source options (OpenLEADR in Python is most referenced)
- Development time (VEN): typically less than one week; potentially a few hours
- Certificates (2.0b): third-party SSL certificates ~140 SEK/year; some organizations have internal procurement constraints
- SWITCH migration: E.ON removed proprietary SWITCH API endpoints for conditional connections by Q2 2024; OpenADR is now the only integration path
Protocol landscape context
OpenADR is one layer in a broader protocol stack. Energimyndigheten ER 2025:35 (RISE analysis) maps the full landscape: (Source - Energimyndigheten ER 2025-35 Förbättra Flexibiliteten (2025))
- Market/aggregation layer (this page): OpenADR (IEC 62746-10-1), S2 (EN 50491-12-2), IEEE 2030.5
- DER layer: OCPP (EV charging; Swedish national standard SS-EN IEC 63110), ISO 15118 (EV-charger V2G), SunSpec Modbus (solar/batteries), Matter 1.3/1.4 (smart home energy)
- Local automation layer: EEBus (Germany-driven), SG Ready (heat pumps)
- Grid infrastructure layer: IEC 61850, IEC 60870-5-104
The market-layer mandate will come from an Implementing Act under EMD Art. 24 (Electricity Market Directive Art. 24) — a separate implementing regulation for demand response protocols and data formats, distinct from and running in parallel to the Network Code on Demand Response. The NC DR defines market rules; the Art. 24 Implementing Act will define mandatory technical protocols. Expected 2026. A first Implementing Act (metering data) was adopted in 2023; the DR-specific one is next.
See Flexibility Communication Protocols for the full protocol landscape.
Related pages
- Villkorade Avtal — primary use case in Sweden
- SWITCH — E.ON’s VTN implementation
- Demand Response — broader context
- Aggregation — aggregators as CPO agents
- Energiföretagen Sverige — industry standardization coordinator
- Flexibility Communication Protocols — full protocol stack: all four layers and EU regulatory pipeline
Data gaps
- Ellevio’s VTN platform (is it in-house or a third-party product?)
- OpenADR adoption status beyond E.ON and Ellevio — other Swedish DSOs?
- Whether non-CPO customers (batteries, industrial loads) use OpenADR or proprietary interfaces
- Testing and certification procedures referenced in the supplement (not detailed)
- Whether Art. 24 EMD Implementing Act will mandate OpenADR specifically or a technology-neutral standard