Source - Energiföretagen Supplement Conditional Grid Connections (2025)

Type: Supplement to industry recommendation (PDF, 12 pages) Publisher: Energiföretagen Sverige Date: 2025-04-22 Version: 1.0 Language: English Raw file: raw/supplement-conditional-grid-connections-extracted.txt URL: https://www.energiforetagen.se/498a45/globalassets/dokument/elnat/supplement-to-industry-recommendation-conditional-grid-connections-ver-1.0.pdf

Summary

An operational supplement to the 2023 industry recommendation (Source - Energiföretagen Branschrekommendation Conditional Grid Connections (2023)). Produced by an ad-hoc working group (Q1 2024) with DSO and CPO representation, this document provides detailed implementation guidance: OpenADR version recommendations, information flow architecture, proposed program and event parameters, two documented production variants (E.ON and Ellevio), and heartbeat monitoring patterns.

Context and motivation

After the 2023 recommendation, DSOs that began implementing OpenADR found that the specification’s looseness (especially in 3.0) created divergence in versioning, naming, formatting, and event structures. A joint DSO/CPO ad-hoc working group formed in Q1 2024 to find common ground. This supplement collects findings from that work.

Target audience: IT project managers and IT developers implementing OpenADR at DSOs and their customers.

OpenADR version recommendation

Recommended version: 3.0.1 (current at time of writing, available at OpenADR Alliance website).

Comparison table highlights (2.0b vs 3.0):

• 2.0b: stricter, centrally authorized client certificates, more predictable registration flows, SOAP/XML
• 3.0: looser specification, JSON/REST, adaptable security, more modern — but looser = more variation between implementations
• Conclusion: 3.0’s flexibility makes DSO-level harmonization more important, not less

Separation of business logic from the core VTN/VEN is emphasized: most infrastructure on the DSO side; the VTN itself should be as close as possible to a generalized solution.

Information flow architecture (OpenADR 3)

Roles in the official OpenADR 3 reference architecture:

VEN can receive events by polling or webhooks. Webhooks recommended (reduced overhead) but require additional security and robustness work.

Proposed program parameters

A VTN can have multiple programs; one should suffice for conditional connections. Minimal valid program structure:

{
  "id": "1",
  "objectType": "PROGRAM",
  "programName": "Conditional agreements",
  "timeZoneOffset": "PT0S",
  "programDescriptions": [],
  "bindingEvents": false,
  "localPrice": false,
  "payloadDescriptors": [],
  "targets": []
}

payloadDescriptors can specify default event properties or be assigned per-event.

Proposed control event flow (generalized)

1. DSO system detects a grid problem
2. BL + VTN create an event to limit one or more resources for a specified duration
3. VEN sends a report to VTN to acknowledge the limit
4. Additional events created while grid problem persists

Two production variants

E.ON variant

• Start time: next hourly-aligned 15-minute period (e.g., 13:00, 13:15, 13:30, 13:45)
• Duration: always PT15M (ISO 8601)
• Payload type: CONSUMPTION_POWER_LIMIT or PRODUCTION_POWER_LIMIT
• Unit: always KW; value = maximum allowed power during the event period
• Report: POWER_LIMIT_ACKNOWLEDGEMENT, sent immediately by VEN
• Real-time metering: required — VEN resources must report real-time power meter readings
• Grid issue persistence: additional limit events sent as needed

Ellevio variant

• Start time: real-time and immediate — represented as "0000-00-00T00:00:00.000Z"
• Duration: typically PT20M (ISO 8601)
• Payload type: SIMPLE; values: "Curtail" or "Restore"
• Limit: pre-agreed, known by VEN — not included in event payload
• Sequence: Curtail event → 15 minutes → Restore event; if issue persists → new Curtail after 15 min
• Report: SIMPLE, sent immediately; values: "Executed" or "Not executed"
• Real-time metering: not required

Key difference

E.ON requires real-time power meter readings and includes dynamic limit values in events — enabling precise, dynamic load-splitting across multiple resources. Ellevio uses pre-agreed static limits with binary curtail/restore — simpler but less flexible for dynamic congestion management. Both support the generalized use case.

Heartbeat monitoring

To detect communication failures before they become compliance issues, the VTN can send regular heartbeat events. VENs respond with reports indicating resource status.

Recommendations:

• Use a separate program for heartbeat events (enables independent data retention/pruning)
• Two targeting modes:
  • Specific resource: RESOURCE_NAME with resource ID
  • All VEN resources: RESOURCE_NAME with value "VEN_REPORT"
• Heartbeat event intervalPeriod: {"start": "0000-00-00", "duration": "PT0S"}
• Interval payload: REQUIRED_BUT_NOT_USED (required by spec but semantically empty for heartbeats)
• Report payload type: HEARTBEAT; value: "OK" or "NOT_OK"

See source document appendix (pages 9–12) for complete JSON examples of heartbeat events and corresponding reports for both specific-resource and VEN-level targeting.

Key claims

1. OpenADR 3.0.1 is the recommended version for new Swedish implementations
2. Two DSOs have live production implementations with fundamentally different event structures — full convergence has not been achieved
3. The key technical divergence: E.ON uses absolute power limits + real-time metering; Ellevio uses binary signals with pre-agreed limits
4. VEN can use polling or webhooks; webhooks recommended but require security investment
5. Heartbeat monitoring is recommended as a standard operational pattern
6. Program and event parameter proposals are documented but most are not mandatory

Relevance to wiki

• Villkorade Avtal: detailed protocol-level documentation of how activation signals are structured in practice; both variants now documented
• OpenADR: primary reference for Swedish implementation parameters and the two-variant landscape
• SWITCH: E.ON’s variant in this supplement directly corresponds to the SWITCH VTN implementation described elsewhere
• Energiföretagen Sverige: confirms continued role in coordinating DSO standardization after 2023 recommendation