Energy flexibility is becoming a standard way of operating an electricity grid. Some DERs have the capability to discharge power to the grid such as solar PV installations and home batteries. Others are able to reduce consumption to maintain grid stability. By orchestrating1 these resources effectively, the grid can become more efficient and greener through reducing the need for fossil fuel electricity generation.
If this is a common way of operating a grid, it makes sense to define open standards so that software and devices are interoperable across any grid.
As a VPP provider/aggregator, I want to be able to deploy my software to support other grids without needing to interface with a whole different set of protocols or APIs. As a grid operator, I don’t want to have multiple demand response implementations for multiple VPPs/aggregators. If a VPP/aggregator goes out of business, I want another provider to be able to easily take over its program. As a citizen, I want a fast roll-out of energy flexibility solutions to reduce fossil fuel usage and keep costs low. Open standards facilitate all of these requirements.
Open Automated Demand Response (OpenADR)2 is one such standard.
OpenADR Overview
As implied by its name, this standard focuses on device load shifting. It describes how an entity should publish demand response (DR) events and how participants should respond on receipt.
The OpenADR Alliance has over 220 members worldwide and over 319 certified products. California, the UK, Germany and the Netherlands all mandate OpenADR for use cases such as device connectivity in buildings, energy networks and EV charging3.
Technical Rundown
In OpenADR a Virtual Top Node (VTN) is a server that defines DR programs and events. A Virtual End Node (VEN) is a server that represents a DER or set of DERs. It receives programs and events from the VTN and then decides how to execute the action using the DERs it represents. Many VENs can connect to one VTN but one VEN cannot connect to another VEN. A very basic setup would be a grid operator-owned VTN and a VPP-owned VEN that represents a set of heat pumps. The VTN can request the heat pumps lower their consumption through events that are processed by the VEN.
OpenADR allows a VEN to also be a VTN. This enables hierarchical relationships within a system. For example, an aggregator may control DERs within multiple buildings. Each building could be a VTN and also a VEN that connects to a grid-wide VTN. Groups of DERs are represented as VENs within the buildings. When the grid-wide VTN publishes an event, the building VENs can delegate to its VTN to plan a course of action. This results in another event that is processed by the DER VENs.
OpenADR is an API-based standard. It describes a set of HTTP REST endpoints that must be implemented by a VTN so that VENs can be made aware of demand response events, and enable them to report the performance or status of the DERs under their control.
The standard has a number of different versions. OpenADR 3 is the latest version with the specification being finalised in 20244. OpenADR 2 was finalised in 2015 and has more widespread adoption. v3 incorporates more modern software development methodologies and data exchange formats including5:
JSON instead of XML
REST API instead of SOAP
Oauth2 security model
The rest of this post focuses on OpenADR 3.
Understanding OpenADR 3: Core Components
The key concepts in OpenADR 3 are:
Programs
Events
Reports
Subscriptions
Programs
A program represents a demand response offering from an energy provider, where the provider can run multiple programs simultaneously (such as dynamic pricing and load shedding). Each program can specify particular events and reporting requirements needed to achieve its business goals. A VTN provides a /programs
HTTP endpoint so that VENs can understand what programs are available.
Events
An event indicates a DR scenario is available to VENs. It contains a start time, duration and a payload to indicate the type of demand response. This could be a very simple DR such as setting a DER’s electricity consumption to a certain level, or day-ahead electricity prices so DERs can adjust their usage when prices are low or high. Events can also contain intervals to indicate different DR levels at specific times during the event. In the day-ahead electricity price example, this could mean 24 intervals to indicate the price of electricity at each hour of the day. Events can also target specific DERs represented by the VEN.
OpenADR defines a set of event types that address common DR scenarios including price indicators, load shedding, dispatching and alerts. The /events
HTTP endpoint of a VTN enables VENs to discover DR events available.
Reports
Programs and events can require VENs to submit reports. The VTN owner may want to know DERs’ electricity usage during an event or their status. This is especially important for correct billing or for a VEN to indicate its capacity for load shedding. The /reports
HTTP endpoint of the VTN is available for VENs to send their reports.
Subscriptions
VENs can subscribe to changes in programs or new events by making a request to the VTN with a callback URL. The VTN will call this URL when the conditions of the subscription have been met. Typically VENs will only subscribe to infrequent events such as alerts and poll for things that change more often such as new events. VTNs offer a /subscriptions
HTTP endpoint so VENs can subscribe to different operations.
Use Cases
I’ve already described simpler use cases of OpenADR for DR scenarios such as load shedding and dynamic pricing. OpenADR 3 also enables more advanced use cases including dynamic operating envelopes and dynamic capacity management.
Dynamic Operating Envelopes
Popularised in Australia due to its widespread deployments of solar and batteries, dynamic operating envelopes enable grid operators to set upper and lower bounds for the import and export of electricity6. The growth of DERs means the grid is having to cope with bidirectional flows of energy. Dynamic operating envelopes improve system stability through constraint setting. The limits can be varied in short time intervals to help respond to customer usage patterns and the weather. They also provide better visibility into how the network operates in real-time.
OpenADR supports dynamic operating envelopes through its IMPORT_CAPACITY_LIMIT
and EXPORT_CAPACITY_LIMIT
event types. VTNs can set these limits on a minute, hourly, daily or monthly basis. There are also IMPORT/EXPORT_CAPACITY_SUBSCRIPTION
event types typically with a years-long interval. If there is an extended communications interruption between the VTN and VEN such that the event schedule has been exhausted, VENs can use these event values as the default limits.
Dynamic Capacity Management
A DER may have a capacity level for importing or exporting electricity that it typically never exceeds. When it needs more it can request the amount required and the fee it’s willing to pay. OpenADR supports this dynamic capacity management through a number of event and report types.
A VEN will know its capacity level through the IMPORT_CAPACITY_SUBSCRIPTION
and EXPORT_CAPACITY_SUBSCRIPTION
event types. VENs can submit reports to request more capacity with IMPORT/EXPORT_CAPACITY_RESERVATION
and IMPORT/EXPORT_CAPACITY_RESERVATION_FEE
and the time periods for which the extra capacity is needed. The request is accepted when the VTN creates equivalent events. VTNs can also indicate what additional capacity is available through the IMPORT/EXPORT_CAPACITY_AVAILABLE
event types.
Enabling Tomorrow's Smart Grid
With OpenADR 3, the standard has evolved to incorporate modern software development practices while addressing increasingly complex energy management scenarios. The hierarchical VTN/VEN model provides the flexibility needed to accommodate various stakeholders, from grid operators to individual DER owners, within a single interoperable framework.
The future of energy flexibility depends on open standards that allow seamless communication between diverse systems and devices. OpenADR's continued development and adoption will be essential in creating more resilient, efficient, and sustainable electrical grids capable of meeting the challenges of the energy transition.
The full specification can be downloaded from https://www.openadr.org/specification