Inferensys

Glossary

OpenADR

An open, standardized communication data model and protocol (IEC 62746-10) used to exchange demand response and price signals between utilities and end-user energy management systems.
Data scientist building training data pipeline on laptop, data preprocessing visible, technical workspace.
AUTOMATED DEMAND RESPONSE PROTOCOL

What is OpenADR?

OpenADR is a standardized communication data model and protocol (IEC 62746-10) used to exchange demand response and price signals between utilities and end-user energy management systems.

OpenADR (Open Automated Demand Response) is an open, non-proprietary communication standard that defines a common language for exchanging demand response signals and dynamic pricing information between electricity service providers and customer energy management systems. It enables fully automated, machine-to-machine coordination of load flexibility without manual intervention.

The protocol standardizes the information exchange between a Virtual Top Node (VTN)—typically a utility or aggregator server—and Virtual End Nodes (VENs)—the client systems controlling loads like HVAC, lighting, or battery storage. By providing a uniform interface, OpenADR decouples demand response program logic from the underlying hardware, ensuring interoperability across diverse vendor equipment and enabling scalable load shifting and peak shaving strategies.

OpenADR Protocol

Frequently Asked Questions

Clear, technically precise answers to the most common questions about the OpenADR standard, its architecture, and its role in automated demand response ecosystems.

OpenADR (Open Automated Demand Response) is an open, standardized communication data model and protocol (IEC 62746-10) used to exchange demand response and price signals between utilities and end-user energy management systems. It works through a client-server architecture where a Virtual Top Node (VTN) —typically operated by a utility or aggregator—publishes event signals, and Virtual End Nodes (VENs) —located at customer sites—subscribe to and execute those signals. The protocol defines a RESTful web service using XML payloads transported over HTTP or XMPP, enabling secure, bi-directional communication. Key message types include oadrDistributeEvent for load reduction requests, oadrCreateReport for telemetry feedback, and oadrRegisterParty for enrollment. Unlike proprietary systems, OpenADR standardizes the semantics of grid signals, allowing heterogeneous devices—from smart thermostats to industrial battery management systems—to interoperate seamlessly within a single demand response program.

PROTOCOL ARCHITECTURE

Key Features of OpenADR

OpenADR (IEC 62746-10) standardizes the communication of price and reliability signals between utilities and customer energy management systems, enabling interoperable demand response automation.

01

Event-Driven Signal Architecture

OpenADR uses a client-server architecture where the Virtual Top Node (VTN) publishes event signals to Virtual End Nodes (VENs). Signals contain:

  • Event priority and duration
  • Signal type (price, load control, or reliability)
  • Ramp rates and recovery periods This decoupled pub-sub model allows utilities to broadcast a single signal to millions of endpoints simultaneously.
IEC 62746-10
International Standard
02

Standardized Signal Types

The protocol defines three core signal categories to cover all grid service needs:

  • Price signals: Real-time, day-ahead, or tiered tariff information
  • Grid reliability signals: Emergency load shed requests with defined severity levels
  • Load control signals: Direct commands for specific device-level actions Each signal carries metadata including validity periods, override permissions, and acknowledgment requirements.
03

Opt-In and Opt-Out Flexibility

OpenADR supports multiple participation models to balance grid needs with customer autonomy:

  • Mandatory events: Customer must respond or face penalties
  • Voluntary events: Customer chooses whether to participate
  • Opt-out windows: Customers can decline specific events without penalty This flexibility is critical for commercial and industrial customers who need to maintain operational control over production processes.
04

Transport Layer Independence

The OpenADR data model is transport-agnostic, operating over multiple communication channels:

  • HTTP/HTTPS with RESTful APIs for cloud-based integrations
  • XMPP for persistent, low-latency connections
  • MQTT for lightweight IoT device communication This abstraction allows the same signal semantics to flow from a utility data center to a smart thermostat or a building management system without protocol translation.
05

Measurement and Verification (M&V)

OpenADR includes built-in telemetry reporting that enables automated performance verification:

  • VENs report actual load reduction data back to the VTN
  • Supports baseline calculation using pre-defined methodologies
  • Enables real-time settlement in wholesale markets This closed-loop feedback ensures that demand response resources are accurately compensated based on verified delivery, not estimated potential.
06

Cybersecurity and Authentication

The protocol mandates transport-layer security and supports multiple authentication mechanisms:

  • X.509 certificates for mutual authentication between VTN and VEN
  • XML digital signatures for signal integrity verification
  • Role-based access control for multi-tenant environments These security features are essential for critical infrastructure protection and compliance with NERC CIP standards in North American markets.
PROTOCOL ARCHITECTURE

How OpenADR Works

OpenADR establishes a standardized client-server communication framework where a Virtual Top Node (VTN) issues event signals to Virtual End Nodes (VENs) for automated load management.

The protocol operates on a publish-subscribe pattern using XML-based payloads transported over HTTP or XMPP. A utility or aggregator's Virtual Top Node (VTN) creates demand response event objects containing timing, price, and load reduction targets, then pushes these to subscribed Virtual End Nodes (VENs) at customer sites. VENs parse the signal and execute pre-programmed control strategies on connected loads without human intervention.

OpenADR defines three core service types: EiEvent for dispatching load reduction events, EiReport for retrieving historical metering data, and EiOpt for communicating complex price signals. The protocol supports both simple binary on/off commands and graduated load shed levels, enabling precise load flexibility orchestration across heterogeneous asset fleets while maintaining audit trails for measurement and verification.

PROTOCOL IN PRACTICE

Real-World OpenADR Deployments

OpenADR (IEC 62746-10) is not merely a specification; it is the operational backbone for automated demand response across millions of endpoints globally. These deployments demonstrate the protocol's scalability from residential thermostats to industrial refrigeration.

01

California's DRAM Auction Mechanism

The Demand Response Auction Mechanism (DRAM) is a landmark regulatory framework requiring California's investor-owned utilities to procure demand response capacity from third-party aggregators. OpenADR 2.0b is the mandated communication protocol for all DRAM resources.

  • Scale: Procures hundreds of megawatts annually from aggregated behind-the-meter assets.
  • Mechanism: Aggregators bid load reduction into a day-ahead market, receiving dispatch signals via OpenADR.
  • Impact: Opened the market to non-utility aggregators, driving innovation in residential smart thermostat and commercial HVAC control.
500+ MW
Annual Procurement Target
02

Pacific Northwest Smart Grid Demonstration

A $178 million ARRA-funded project spanning five states, this was one of the largest transactive energy field tests. It used a distributed architecture where OpenADR signals communicated 5-minute transactive prices to 60,000 metered customers.

  • Key Finding: Demonstrated that price-responsive loads can provide reliable peak reduction without compromising consumer comfort.
  • Architecture: A distributed control hierarchy where wholesale price signals were decomposed and forwarded to end-use devices via OpenADR.
  • Legacy: Proved the viability of using economic signals rather than direct load control commands for grid stabilization.
60,000
Participating Customers
03

Japanese Virtual Power Plant Aggregation

Following the Fukushima Daiichi incident, Japan's Ministry of Economy, Trade and Industry (METI) funded large-scale VPP demonstrations. OpenADR 2.0b was selected as the standard interface between aggregators and commercial/industrial customers.

  • Asset Types: Aggregated emergency generators, battery storage, and industrial HVAC across thousands of facilities.
  • Grid Service: Provided tertiary reserve capacity to balance the grid under high renewable penetration.
  • Standardization: The Japanese Smart Community Alliance formally adopted OpenADR as the national demand response protocol, ensuring interoperability across diverse hardware vendors.
10,000+
Aggregated Facilities
04

Australian Emergency Reserve Trader

The Australian Energy Market Operator (AEMO) operates the Reliability and Emergency Reserve Trader (RERT) mechanism to secure load reduction during extreme peak events. Aggregators leverage OpenADR to dispatch emergency curtailment signals to enrolled industrial loads.

  • Use Case: Rapidly shedding large industrial pumping and refrigeration loads during summer heatwaves to prevent blackouts.
  • Protocol Role: OpenADR provides the secure, acknowledged messaging required for emergency reserve activation, ensuring the signal is received and acted upon within seconds.
  • Market Context: This is a last-resort mechanism, distinct from economic day-ahead markets, highlighting OpenADR's utility in both economic and reliability dispatch.
< 1 sec
Signal Latency Requirement
05

European FLEXGRID Interoperability

The Horizon 2020 FLEXGRID project unified distribution system operators (DSOs) and aggregators under a common flexibility marketplace. OpenADR served as the southbound protocol translating market bids into device-level commands.

  • Integration: Bridged the gap between wholesale market platforms and proprietary building management systems (BMS) and EV charging stations.
  • Multi-Service Stacking: Enabled a single battery asset to provide frequency containment reserve to the TSO while simultaneously managing local distribution congestion for the DSO.
  • Outcome: Validated OpenADR as a universal adapter in a layered flexibility market architecture, preventing vendor lock-in.
4
Participating EU Countries
06

Commercial Refrigeration Load Shedding

Major grocery chains deploy OpenADR to modulate thermal energy storage in refrigeration cases without compromising food safety. This represents a critical non-residential load flexibility resource.

  • Technical Mechanism: An OpenADR signal triggers a slight upward drift in freezer temperature setpoints (e.g., from -20°F to -18°F) for a 2-hour event window, leveraging the thermal mass of stored goods.
  • Measurement: Performance is verified against a Customer Baseline Load (CBL) calculated from recent non-event days.
  • Scale: A single national chain can aggregate over 100 MW of flexible refrigeration load across its portfolio, bidding this capacity into wholesale ancillary service markets.
100+ MW
Single Chain Portfolio
PROTOCOL COMPARISON

OpenADR vs. Other Demand Response Protocols

Technical comparison of OpenADR 2.0b against IEEE 2030.5, proprietary vendor APIs, and legacy direct load control protocols for automated demand response signaling.

FeatureOpenADR 2.0bIEEE 2030.5Proprietary Vendor APIDirect Load Control

Standardization Body

IEC 62746-10

IEEE 2030.5 (CSIP)

Vendor-specific

Utility-specific

Communication Model

Client-server (VTN/VEN)

Client-server (Aggregator/End Device)

API-defined

One-way relay

Transport Protocol

HTTP/TLS 1.2

HTTP/TLS 1.2

Varies (MQTT, HTTP, WebSocket)

Radio frequency or ripple control

Payload Format

XML (oadrPayload)

XML/EXI (SEP 2.0)

JSON or Protobuf

Binary on/off signal

Signal Types Supported

Price, load dispatch, grid event

Price, DER control, flow reservation

Custom event types

Load shed only

Bi-directional Communication

Opt-Out Capability

Baseline Reporting (EiReport)

DER Control Support

Cybersecurity Framework

TLS 1.2 + XML Signature

TLS 1.2 + certificate-based

API key or OAuth 2.0

None

Interoperability Certification

OpenADR Alliance certified

IEEE/UL 2030.5 certified

None

None

Typical Latency

< 5 sec

< 10 sec

< 1 sec

< 30 sec

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.