Understanding OpenADR
OpenADR has revolutionized demand response communication by standardizing how energy providers and consumers exchange critical grid signals. Originally developed to simplify and automate load management, the protocol has evolved considerably since its inception.
OpenADR Main Components:
VTN (Virtual Top Node):
The VTN is the central server that schedules and manages DR events.
In most deployments, there is typically one VTN coordinating the event signals.
VEN (Virtual End Node):
The VENs are the client devices that poll the VTN periodically for events, provided they have the proper security credentials.
VENs can be configured to respond to all events or selectively participate in specific programs defined by the VTN, referred to as “Market Context”.
OpenADR 1.0
OpenADR 1.0 laid the groundwork for a unified demand response communication framework. Introduced in 2010, it enabled utilities to send automated signals—Pending, Moderate, and High—to participating customers, curtailing loads during peak Demand periods.
Pending Signal
The Pending signal serves as a pre-event notification, giving facilities time to prepare. Its interpretation, however, varies by utility. Some utilities issue Pending signals minutes before the event as in Fast DR, while others may send them a day in advance as a courtesy warning. The Pending signal is often used to trigger preemptive actions, such as shutting down in a sequence or pre-cooling HVAC systems.
OpenADR 2.0a
An OpenADR 2.0a signal from the VTN contains six main elements:
Start Time (UTC): The scheduled time when the event begins, expressed in Coordinated Universal Time.
Duration (minutes): The length of the event.
Market Context ID: A unique identifier that specifies the program or market rules associated with the signal.
Signal Name: Typically set to “Simple”, indicating a basic DR event.
Signal Type: Defined as “Level”, representing the event’s intensity.
Payload Value: Represents the event severity:
1 = Moderate
2 = High
3 = Special*
This is commonly referred to as a Simple-Level Signal or 2.0a Signal.
* Special payloads do not correspond to standard relay operations and require custom definitions. See Special Signals for more details.
OpenADR 2.0a, introduced in 2012, brought several key improvements over OpenADR 1.0, making the protocol more flexible, secure, and scalable. Here are the main enhancements:
Standardized XML Messaging:
OpenADR 2.0a adopted a standardized XML schema for communication, improving interoperability between different vendors and systems.
Enhanced Security:
Introduced TLS encryption for secure communication, addressing the security limitations of OpenADR 1.0.
Improved authentication mechanisms, making it harder for unauthorized systems to interact with the grid.
Flexible Signal Types:
Expanded beyond the basic Pending, Moderate, and High signals by adding more detailed event signals and attributes, making DR event communication more precise.
Included simple price signals, enhancing the protocol’s ability to support dynamic pricing programs.
Two-Way Communication:
Enabled bi-directional communication between the Virtual Top Node (VTN) and Virtual End Node (VEN), allowing VENs to confirm event receipt and report telemetry data back to the VTN.
Event Scheduling and Modifications:
Added support for event scheduling, including recurring and multi-day DR events.
Allowed real-time modifications to ongoing events, making the system more responsive and adaptive.
Improved Scalability:
Designed to support a larger number of VENs, making the protocol suitable for broader deployment across commercial and industrial facilities.
OpenADR 2.0a, introduced in 2012, brought several key improvements over OpenADR 1.0, making the protocol more flexible, secure, and scalable. Here are the main enhancements:
Standardized XML Messaging:
OpenADR 2.0a adopted a standardized XML schema for communication, improving interoperability between different vendors and systems.
This made it easier to integrate with third-party energy management and control platforms.
Enhanced Security:
Introduced TLS encryption for secure communication, addressing the security limitations of OpenADR 1.0.
Improved authentication mechanisms, making it harder for unauthorized systems to interact with the grid.
Flexible Signal Types:
Expanded beyond the basic Pending, Moderate, and High signals by adding more detailed event signals and attributes, making DR event communication more precise.
Included simple price signals, enhancing the protocol’s ability to support dynamic pricing programs.
Two-Way Communication:
Enabled bi-directional communication between the Virtual Top Node (VTN) and Virtual End Node (VEN), allowing VENs to confirm event receipt and report telemetry data back to the VTN.
Event Scheduling and Modifications:
Added support for event scheduling, including recurring and multi-day DR events.
Allowed real-time modifications to ongoing events, making the system more responsive and adaptive.
Improved Scalability:
Designed to support a larger number of VENs, making the protocol suitable for broader deployment across commercial and industrial facilities.
OpenADR 2.0b
OpenADR 2.0b, released in 2015, introduced several significant improvements over OpenADR 2.0a, making the protocol more robust, flexible, and capable of supporting complex demand response (DR) programs. Here are the key enhancements:
Expanded Event Signals and Granularity
Added support for more complex event signals, including:
Price signals: Real-time and day-ahead pricing information.
Energy usage signals: Consumption thresholds and energy limits.
Load reduction requests: More detailed load control instructions.
Temperature offsets: Ideal for HVAC load management.
OpenADR 2.0b Profile Specification
Table 1 Signals
Signal Name
SIMPLE
ELECTRICITY_PRICE
ENERGY_PRICE
DEMAND_CHARGE
BID_PRICE
BID_LOAD
BID_ENERGY
CHARGE_STATE
LOAD_DISPATCH
LOAD_CONTROL
Signal Type
delta
level
multiplier
price
price Multiplier
price Relative
product
setpoint
x-LoadControlCapacity
x-LoadControlOffset
x-LoadControlSetpoint
x-LoadControlPercentOffset
Payload Value
Some signals in OpenADR 2.0b are restricted to specific integer values or percentage ranges, depending on the signal type. However, in most cases, arbitrary values can be sent, allowing for flexible, custom event definitions.
The OpenADR 2.0b specification also allows for custom signal types, enabling utilities and aggregators to define proprietary signals for specialized applications.
For more details on specialized payloads, refer to:
Special Event Signals (for non-standard signal handling)
The OpenADR 2.0b Profile Specification for the full list of supported signal types, payload ranges, and custom signal definitions.