Flexnavet › WikiWiki ›OpenADR
Flexnavet
BläddraBrowse

OpenADR

Concept Updated 2026-10-04

A voluntary industry choice, not a legal mandate — Energiföretagen picked OpenADR (specifically version 3.0.1) after evaluating four candidate protocols in 2023, and Swedish adoption still depends on individual DSOs choosing to implement it.

An EU Implementing Act under EMD Art. 24, expected in 2026 and running in parallel to but separate from NC DR, will mandate specific technical protocols for demand-response signals — it's still an open question whether it will name OpenADR specifically or stay technology-neutral, which matters because Sweden has already built its villkorade avtal infrastructure around this one particular choice.

IEC standard — IEC 62746-10-1Adopted by Energiföretagen Sverige — October 2023Recommended version for Sweden — 3.0.1 (REST/JSON)

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))

A 2026 Norwegian SINTEF study of TMV (Norway’s conditional-connection equivalent) for EV charging infrastructure describes this Swedish approach, drawing on Energiföretagen’s own account, and singles out the reason it worked: Energiföretagen deliberately kept protocol choice separate from contract-terms negotiation, which its own account credits with making industry consensus achievable — a scoping lesson the study recommends Norway’s own standardization effort adopt. (Source - SINTEF PN26-00117 Tilknytning Ladestasjoner Med Vilkar (2026))

Core architecture

OpenADR defines a server–client communication model:

RoleDescriptionSwedish context
VTN (Virtual Top Node)Server — publishes events, receives reportsDSO (e.g., SWITCH or Ellevio platform)
VEN (Virtual End Node)Client — receives events, executes, reportsCPO / customer energy management system
Business Logic (BL)DSO application layer driving VTNGrid monitoring, threshold detection, event creation
Customer Logic (CL)Customer application layer driving VENResource control (EV charger, battery, HVAC)
OpenADR message flow — VTN to VEN Business Logic VTN DSO platform (e.g. SWITCH) Event Report VEN Customer energy management system Customer Logic Business/Customer Logic sit outside the protocol layer — VTN/VEN stays generic

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

Property2.0b3.0 / 3.0.1
API styleSOAP/XMLREST/JSON
AuthenticationCentrally authorized client certificatesAdaptable to application security level
Registration flowStricter, more predictableLooser, more flexible
Specification rigidityStricterLooser — more implementation variation possible
Standard formIEC 62746-10-1IEC 62746-10-1 (updated)
Swedish recommendationLegacy (PoC only)Recommended for new implementations

Recommended version for Sweden: 3.0.1 — most future-proof, REST/JSON-based, easiest to implement and maintain. (API style, authentication and standard-form rows: Source - Energiföretagen Branschrekommendation Conditional Grid Connections (2023); registration-flow/rigidity comparison and the 3.0.1 recommendation itself: Source - Energiföretagen Supplement Conditional Grid Connections (2025))

Currency note: the OpenADR Alliance’s own latest release has since moved to 3.1 (September 2025) — a further-modernized profile adding webhook/MQTT delivery options. A June 2026 IEA 4E EDNA comparison of demand-flexibility protocols for residential appliances names OpenADR 3 as one of three credible, actively-developed candidates internationally (alongside Matter and EEBUS, explicitly not a winner-takes-all framing), citing its established alliance and certification programme and its strength for Layer 1–2 signalling and forward schedules. Whether Energiföretagen has revisited its 3.0.1 recommendation against 3.1 is an open question — see Data gaps. (Source - EDNA Demand Flexibility Protocols (2026))

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_LIMIT or PRODUCTION_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)) The supplement was produced by an ad-hoc industry working group with DSO and CPO representation, formed in Q1 2024, targeting DSO IT project managers and developers (Source - Energiföretagen Supplement Conditional Grid Connections (2025)); Ellevio and E.ON Energidistribution are named as the two DSOs engaged in the effort. (Source - Energiföretagen Branschrekommendation Web (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:

  1. More international adoption — used by more actors globally
  2. Broader use case support — covers forecasting, real-time control, reporting, multiple flexibility types (not just EV charging)
  3. IEC standardization — recognized standard, internationally viable
  4. 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.

Data gaps

  • OpenADR adoption status beyond E.ON and Ellevio — other Swedish DSOs?
  • Whether non-CPO customers (batteries, industrial loads) use OpenADR or proprietary interfaces

Sources

Närliggande sidorNearby pages 11

KonceptConcept EntitetEntity SyntesSynthesis

Klicka på en nod för att gå dit. Dra för att panorera, rulla för att zooma. Click a node to go there. Drag to pan, scroll to zoom.