Flexibility Communication Protocols
A cross-reference map, not a protocol spec — each layer (market/aggregation, DER control, building automation, grid/SCADA) already has its own standards body and its own page elsewhere in this wiki; this page shows which protocol operates at which layer, not what any one of them does in detail.
Even the closest thing to an industry standard doesn't guarantee interoperability — E.ON Energidistribution and Ellevio both use OpenADR for villkorade avtal, but implement it differently enough that Energiföretagen had to publish a supplement documenting the divergence, meaning "we both use OpenADR" still isn't a sufficient answer to "will this integrate."
A layered stack of communication protocols connects end-user devices (heat pumps, EV chargers, batteries) up through aggregators, DSOs, and TSOs. This protocol stack is one slice of the broader digital grid layer. No single protocol covers the whole chain — different layers use different standards, often with competing or overlapping proposals. This page maps the full landscape as documented by RISE in Energimyndigheten ER 2025:35. (Source - Energimyndigheten ER 2025-35 Förbättra Flexibiliteten (2025))
Why a protocol stack
The flexibility signal chain involves at least four distinct communication tasks:
- Market and aggregation: the market operator or DSO dispatches flexibility events to aggregators or directly to service providers
- DER control: aggregators or energy management systems communicate with physical devices (EV chargers, batteries, inverters)
- Local automation: devices within a building or premises coordinate with each other (home energy management systems, building automation)
- Grid/critical infrastructure: DSO and TSO control centres communicate with substations, field equipment, and SCADA
Each layer has its own set of protocols, standardization bodies, and maturity levels. A flexibility provider operating end-to-end must implement protocols at each layer, creating integration complexity.
Layer 1 — Market and aggregation protocols
These protocols carry flexibility dispatch signals from system operators or aggregators down to service providers or customer systems.
OpenADR
Standard: IEC 62746-10-1 (International Electrotechnical Commission) Swedish status: Industry standard since 2023 — adopted by Energiföretagen Sverige following a market-wide evaluation. Used by E.ON Energidistribution, Ellevio, and growing number of DSOs for Villkorade Avtal. Architecture: server–client (VTN/VEN); REST/JSON in version 3.0.1 (Energiföretagen’s 2025 recommendation for new Swedish implementations); programmatic event dispatch and report-back. The OpenADR Alliance’s own current release has since moved to 3.1 (September 2025) — a modernized, comparatively lightweight profile with webhook/MQTT delivery options — though nothing found so far indicates Energiföretagen has revisited its 3.0.1 recommendation against it. (Source - EDNA Demand Flexibility Protocols (2026)) Detail: see OpenADR for the full treatment, including Swedish production implementations.
S2
Standard: EN 50491-12-2 (European) Origin: FlexiblePower Alliance / TNO (Netherlands) Purpose: Semantic interoperability — defines common data semantics for flexible energy devices regardless of underlying transport protocol. Technology-agnostic. Swedish status: Limited use; evaluated in research projects (SLAV project, RISE); not yet in production. Positioning: S2 operates closer to the device side than OpenADR — it standardizes what a device can do and how to represent its flexibility, while OpenADR standardizes how the signal is dispatched.
IEEE 2030.5 (Smart Energy Profile)
Standard: IEEE 2030.5 Purpose: Two-way communication between DERs, aggregators, and DSOs; designed to handle large volumes of devices. Also called “Smart Energy Profile 2.0.” Swedish status: Limited use; evaluated in research projects. Positioning: Competes with OpenADR in the aggregation layer; stronger in North American markets.
Layer 2 — DER protocols
These protocols communicate between energy management systems and specific device categories (EV chargers, inverters, batteries).
OCPP (Open Charge Point Protocol)
Standard: Open Charge Alliance; Swedish national standard SS-EN IEC 63110 Purpose: Communication between EV charging infrastructure (charge points) and back-office systems (charge point operators) Swedish status: Extensive use — the dominant EV charging protocol in Sweden and globally Versions: OCPP 2.x introduces smart charging and bidirectional (V2G) support V2G service lifecycle role: OCPP operates at two distinct stages in V2G service delivery: (1) Installation/Configuration — remote EVSE setup and configuration by the Aggregator after physical installation; (2) Usage — ongoing delivery of V2G schedules from the Aggregator’s Central Management System to the charger, meter value reporting, firmware updates. This dual role distinguishes OCPP from ISO 15118, which is a Usage-only protocol. (Source - Malakhatka et al V2G Service Blueprint Sweden (2026)) Cross-reference: Villkorade Avtal — CPOs are the primary users of conditional connections; OCPP is the protocol stack on which OpenADR sits for EV-side implementations
ISO 15118
Standard: ISO/IEC Purpose: Communication between EV and charging station (vehicle-side); enables Plug & Charge (automatic authentication) and Vehicle-to-Grid (V2G) bidirectional power flows Swedish status: Expected to grow with V2G deployments; not yet widespread Regulatory driver: EU alternative fuels regulation and V2G policy are pushing ISO 15118 adoption V2G service lifecycle role: operates exclusively during the Usage phase — covers EV connection, authentication, and negotiation of charging/discharging parameters (power, energy, duration) directly between the EV and the smart charger. Not involved in the Installation/Configuration phase (that is OCPP’s domain). (Source - Malakhatka et al V2G Service Blueprint Sweden (2026)) Cross-reference: Vehicle-to-Grid — ISO 15118-20 is the enabling standard for V2G at the charging interface
SunSpec Modbus
Standard: SunSpec Alliance; based on Modbus Purpose: Communication with solar inverters, batteries, and DER monitoring/control systems Swedish status: Used in solar, battery, and DER monitoring in Sweden; integrated in IEEE 1547-2018 (the US standard for DER interconnection) Maturity: Established, widely deployed
Matter (versions 1.3 / 1.4)
Standard: Connectivity Standards Alliance (CSA); backed by Apple, Google, Amazon, and major device manufacturers Purpose: Originally a smart home interoperability standard; versions 1.3 and 1.4 (2024) added energy management — solar, batteries, heat pumps, and EV charging are now in scope Swedish status: Emerging — smart home devices with Matter support are entering the Swedish market; energy management capabilities are new as of 2024 Significance: If Matter achieves the smart home market penetration its backers intend, it could become a de facto DER standard for residential devices, potentially displacing device-specific protocols at the consumer end
V2G communication stack across the service lifecycle
Service blueprinting of Swedish V2G (Malakhatka et al. 2026, Vinnova project) maps each protocol to the specific phase of V2G service delivery where it operates: (Source - Malakhatka et al V2G Service Blueprint Sweden (2026))
| Protocol | Layer | V2G phase |
|---|---|---|
| ISO 15118 | EV↔EVSE | Usage: connection, authentication, power parameter negotiation |
| OCPP | EVSE↔CMS | Installation: remote charger config; Usage: schedule delivery, meter values |
| IEEE 2030.5 | Aggregator↔devices | Usage: demand response signals, DER status, pricing |
| OpenADR | Aggregator/Utility↔VEN | Usage: dynamic pricing and DR event dispatch |
| IEC 61850 | Aggregator↔DSO/TSO systems | Backstage: grid monitoring, dispatch coordination |
Key insight from this mapping: the V2G stack requires five distinct protocols (ISO 15118, OCPP, IEEE 2030.5, OpenADR, IEC 61850) touching only 3 of this page’s own 4 defined communication layers (Local automation plays no role in V2G) — none of the five protocols covers the full chain. An aggregator operating end-to-end must implement all five.
Layer 3 — Local automation protocols
These protocols coordinate devices within a building, home, or premises. They operate between the end device and a local energy management system (HEMS — Home Energy Management System) or building management system.
EEBus
Standard: EEBus Initiative (Germany) Devices: Heat pumps, EV chargers, white goods, HEMS Links: EN 50631, ETSI SAREF4ENER (semantic framework for smart energy) German status: Required under §14a EnWG since 2024 — German network operators must offer smart charging / demand flexibility contracts, and EEBus is the mandated interface. This has driven rapid adoption in Germany. Swedish status: Limited outside Germany — no Swedish regulatory mandate. May gain indirect relevance if heat pump or EV charger manufacturers standardize on EEBus for their German products and deploy the same hardware in Sweden.
SG Ready
Standard: Bundesverband Wärmepumpe (German Heat Pump Association) Purpose: Simple 2-bit signal to heat pumps (four modes: locked out / normal / boosted / compulsory-on) German status: Prerequisite for state subsidy for heat pumps in Germany (Bundesförderung für effiziente Gebäude) Swedish status: Limited — some heat pumps sold in Sweden include SG Ready ports, but no Swedish regulatory framework uses the signal
PowerMatcher
Origin: Netherlands (ECN/TNO) Purpose: Software framework for agent-based energy balancing within a local cluster Status: Minor; research/pilot use
Thread
Purpose: Low-power mesh networking protocol; underlying communication layer for Matter and IoT devices Status: Infrastructure, not directly relevant at the flexibility application layer
Layer 4 — Grid and critical infrastructure protocols
These protocols are used by DSOs and TSOs for substation automation, SCADA, and control centre communications. They are typically not relevant to aggregators or end-user devices.
IEC 61850
Standard: IEC Technical Committee 57 Purpose: Substation automation, protection relays, SCADA communication for DSO/TSO operations Scope expansion: IEC TC 57 is actively extending IEC 61850 data models to represent DERs (batteries, EV chargers) — bringing grid infrastructure communication standards into contact with the flexibility layers above Swedish status: Standard for DSO/TSO substation operations in Sweden and across Europe
DNP3
Purpose: Communication between control centres and field equipment (RTUs, IEDs); common in North American utilities Swedish relevance: Less common in Europe; IEC 60870-5-104 generally preferred
IEC 60870-5-104
Purpose: Control centre to substation communication over TCP/IP; essentially the European parallel to DNP3 Swedish status: Standard in Sweden and across European DSO/TSO operations
TSO–BSP interfaces for balancing markets (ECP/EDX, CIM documents, ICCP)
Purpose: the concrete messaging a balancing service provider uses toward Svk. In the Nordic aFRR energy activation market, bids are CIM-based XML documents (ReserveBid, BidAvailability, Acknowledgement) exchanged over the ENTSO-E Energy Communication Platform (ECP/EDX), while real-time activation runs over the ICCP protocol between Svk’s load frequency control system and an Agent that connects BSPs, with setpoints sent down and confirmation and capacity measurements sent back. (Source - Svk aFRR Energy Activation Market Implementation Guide (2026)) Swedish status: planned for the Q4 2027 PICASSO connection; already in operation in Denmark and Finland.
EU regulatory pipeline — the two-pillar structure
The regulatory framework for flexibility communication has two separate pillars, often confused:
Pillar 1 — Network Code on Demand Response (NC DR): defines the market rules for flexibility — how resources register, qualify, and participate in markets. NC DR explicitly does NOT mandate technical protocols or data formats. This is a deliberate separation.
Pillar 2 — Implementing Act under EMD Art. 24: a separate EU implementing regulation specifically for demand response protocols and data formats. The Commission’s Citizens’ Energy Package (COM(2026)115, Actions 5 and 6) sets the timeline as 2027 — both the energy sharing data interoperability regulation and the flexibility retail contract interoperability regulation are expected as a single Implementing Regulation on interoperability requirements. Earlier estimates had put this at 2026; the 2027 date is now the Commission’s stated plan. This is the instrument that will mandate which technical protocols are required for flexibility market participation and for energy sharing operationalization. (Source - Citizens Energy Package COM(2026)115)
A first Implementing Act under EMD Art. 24 (covering metering data access) was adopted in 2023. The DR/energy-sharing-specific Implementing Act is the next in the pipeline.
Implication for Sweden: OpenADR‘s position as the Swedish industry standard puts Sweden in a strong position for compliance with the Art. 24 Implementing Act — provided the final act aligns with OpenADR, which is the most likely outcome given its IEC standardization and EU-wide uptake. However, the outcome is not guaranteed until the Act is published.
Standardization bodies feeding into EU regulation:
- IEC TC 57: extending IEC 61850 for DER representation (feeding into grid infrastructure requirements)
- IEC TC 69: finalizing ISO 15118 series for V2G (feeding into EV-specific mandates)
- EDNA (IEA 4E program): its June 2026 report compares residential-appliance DF protocols across seven jurisdictions (UK, California, Australia, New Zealand, Germany, France, EU) using a Control Specificity × Temporal Horizon matrix; names OpenADR 3, Matter, and EEBUS as the only credible protocol candidates; contains no Sweden-specific finding (Sweden appears only as a listed 4E TCP member)
- CEN/CENELEC/ETSI COG SG (Coordination Group Smart Grid): coordinates EU smart grid standards across the three major European standards bodies
Swedish challenges
Sweden faces specific barriers to a coherent protocol landscape:
- 168 DSOs with heterogeneous legacy systems — fragmentation makes standardization harder than in countries with one or two large DSOs. Each DSO may implement the same standard differently, as the E.ON vs Ellevio OpenADR divergence illustrates (Source - Energiföretagen Supplement Conditional Grid Connections (2025)) — an independent international comparison reaches the same conclusion from the other direction: EDNA’s review of seven jurisdictions found that a shared nominal protocol doesn’t guarantee interoperability without centralized, physically-tested certification, citing Australia’s CSIP-AUS (certified inconsistently across individual network operators despite one nominal standard) as its own cautionary case. (Source - EDNA Demand Flexibility Protocols (2026))
- Cross-body regulatory conflict risk: EDNA’s review flags a general pattern worth watching for Sweden specifically — different regulatory bodies setting device-level requirements in isolation can create contradictory obligations (its example: Germany’s §14a mandating heat-pump curtailment compliance for DSO capacity management, while the EU’s own Network Code on Demand Response separately pushes heat pumps toward frequency-response participation, a power-quality-domain obligation). As Sweden’s NC DR implementation and Ei’s own protocol-related föreskrifter both develop, this is a concrete failure mode to check for rather than an abstract risk.
- Regulatory uncertainty: LFM-h/p/e (local flexibility market — heating/production/EVs) product specifications submitted to Ei in March 2025 — still pending as of late 2025. Protocol choices depend partly on regulatory product design
- Skills shortage: implementing and maintaining flexibility systems across 168 DSOs requires expertise that is scarce
- Proprietary lock-in: legacy investments in vendor-specific systems create switching costs and resist standardization
- Open protocols as a security measure: the cybersecurity risk from large numbers of connected DERs (§3.1 analysis) is reduced when open protocols are used — they distribute security responsibility and reduce single-vendor attack surfaces. Proprietary protocols concentrate vulnerability
- Effektavgift fragmentation as automation barrier: each DSO designs its effektavgift differently, making standardised automated control integration costly — a control service must implement different logic per DSO. Ei has officially confirmed this barrier: in the March 2026 government assignment on a new effektavgift model, Ei division head Tommy Johansson explicitly cited fragmented DSO models as an obstacle to automatic steering services development. This is one of several stated drivers for the forthcoming harmonized effektavgift framework — the source also cites transparency, non-discrimination, proportionality, correct consumption incentives, and reducing customer confusion over the current EIFS 2022:1 rollout, without ranking the automation-barrier point above these. (Source - Ei Effektavgifter Uppdrag (2026))
Cross-references
- OpenADR — the Swedish/EU DSO-side market layer standard in detail
- Villkorade Avtal — primary current use case for OpenADR in Sweden
- Network Code on Demand Response — market rules framework (Pillar 1); FIS data exchange requirements
- Energy Storage — DER protocols relevant to batteries (SunSpec Modbus, Matter, IEC 61850 extensions)
- Demand Response — synchronisation risks that protocol design needs to address (random startup delay)
- Ei — regulatory authority for the Swedish flexibility protocol landscape; developing föreskrifter for DSO–customer communication
- Distribution System Operator — 170 heterogeneous Swedish DSOs as the fragmentation problem
- Source - Svk EMDO BASE Ontologier (2026) — a different layer from the protocols above: Svk’s EMDO/BASE RDF ontologies are a semantic data-model for electricity-market data (reserve products, bidding zones, auction rounds…), defining what data means rather than how signals are dispatched; relevant to the DHV/FIS data model (Elmarknadshubb)
Data gaps
- Whether the Art. 24 EMD Implementing Act (DR-specific) will mandate OpenADR specifically or a technology-neutral performance standard
- EEBus adoption trajectory in Sweden — will German §14a EnWG drive cross-border harmonisation?
- S2 adoption outside the Netherlands — any Swedish production deployments?
- Whether Energiföretagen has evaluated moving its Swedish OpenADR recommendation from 3.0.1 to 3.1 (released Sept 2025)
- Whether Ei’s new föreskrifter for DSO–customer communication will create protocol mandates ahead of the Art. 24 IA
Sources
- Energimyndigheten ER 2025-35 Förbättra Flexibiliteten (2025)
- Energiföretagen Branschrekommendation Conditional Grid Connections (2023)
- Energiföretagen Supplement Conditional Grid Connections (2025)
- Ei Effektavgifter Uppdrag (2026)
- Citizens Energy Package COM(2026)115
- Malakhatka et al V2G Service Blueprint Sweden (2026)
- Svk EMDO BASE Ontologier (2026)
- EDNA Demand Flexibility Protocols (2026)
Linked from 20
- Beredskapsflexibilitet
- Digitalization and Smart Grid
- Energy Storage
- Grid Security & Resilience
- Network Code on Demand Response
- OpenADR
- Source - Citizens Energy Package COM(2026)115
- Source - Commission Recommendation C(2026)2850 Energy Communities
- Source - DHV Presentation 2026-04-27
- Source - EDNA Demand Flexibility Protocols (2026)
- Source - Ei Effektavgifter Uppdrag (2026)
- Source - Energiforsk 2022-895 DigiGrid (2022)
- Source - Energimyndigheten Cybersäkerhet Energisektorn (web, 2026)
- Source - Energimyndigheten ER 2025-35 Förbättra Flexibiliteten (2025)
- Source - Malakhatka et al V2G Service Blueprint Sweden (2026)
- Source - Svk aFRR Energy Activation Market Implementation Guide (2026)
- Source - Svk EMDO BASE Ontologier (2026)
- Source - Svk IA DR Webinar Part 1 (2025)
- Source - Svk Kompensationsmodell Delrapport 2 (2024)
- Submetering