OpenADR Overview

A basic overview OpenADR: how it works and what it is used for

7 minute read ∙ Apr 6th, 2020

Automated grid flexibility is critical to a renewable energy powered grid by ensuring electricity is used when it is cleanest and cheapest. Automating via Open Standards reduces implementation costs and improves interoperability of programs, which means more money can go towards incentivizing the participation and innovation necessary to support the clean energy transition.

Top open standards for load shifting include OpenADR, DNP3, IEEE 2030.5, and a number of others that are used in specialized scenarios. A deep dive comparison of these standards would require its own full post, but OpenADR is the most mature and typical go-to option for demand response / load shifting programs.

As a device manufacturer or aggregator, implementing OpenADR unlocks participation in load shifting programs and a way to monetize your load flexibility. California has also mandated implementation for certain device types through its title 24 building codes, and other states are following suit. Check out our growing list of programs that use or require OpenADR to see where it is being used, incentivized and/or required.

As a utility, using OpenADR avoids vendor lock-in, since the end device connections can be transferred to a different OpenADR server. In fact, OpenADR has been around long enough that we have seen this in action: utilities such as PG&E, Hawaiian Electric and Austin Energy have transferred over their device controls server (their VTN, in OpenADR-lingo) without having to re-engineer device connections. This is a big win for utilities and for program interoperability.

For all companies providing grid flexibility, standardization around OpenADR leads to lower implementation costs and hassle, so we can focus more on increasing customer participation, device controls logic, and, ultimately, enabling load flexibility to be an integral part of the clean energy transition.

The goal of this post is to give the reader an overview of the OpenADR protocol and how it is implemented. It is meant for those who understand the concept of demand response but are new to OpenADR or still learning the basics.

If you are new to the utility industry or demand response, we recommend you check out some introductory posts before continuing on:

• Utilities 101
• Who's who on the power grid
• Demand Response 101

Why Standards are Helpful

As we saw in Demand Response 101, load shifting is valuable and, the more flexible and responsive it is, the more valuable it is. Automating load shifting is necessary to provide that flexibility, and this requires automated communication.

Historically, manual integrations between device companies and utility platforms have been necessary to provide automated controls. Now that load shifting programs are in the mainstream, this must change. There are dozens of device categories, hundreds of product manufacturers, and thousands of utilities. Creating manual integrations between all of those is wasteful, and creates lock-in: if the utility wants to change their DRMS / DERMS software provider, they'll need to pay for the integration all over again.

This increases the cost and friction associated with load shifting, which ultimately means smaller and less effective programs. If everyone is speaking the same language, integration becomes a lot more seamless and therefore more cost effective, and load shifting can flourish.

Enter OpenADR: load shifting standard

OpenADR is currently the go-to standard for load shifting on the grid. OpenADR was conceived in 2002, funded by the California Energy Commission to facilitate more seamless demand response programs, and the OpenADR 1.0 standard followed soon after. The original focus was on Automated Demand Response (ADR) for Commercial & Industrial (C&I) facilities.

Afterwards, OpenADR was given to the Organization of Structured Information Standards (OASIS) to create a national standard for load shifting. The result of that was Energy Interoperation 1.0, which became the basis for OpenADR 2.0. OpenADR 2.0 is a subset of EI (this is why many OpenADR payload names start with EI). OpenADR 2.0 expanded beyond just C&I demand response to more flexible distributed energy resource controls and load shifting, expanding both the devices that are available to control as well as the load shifting capabilities.

OpenADR is first and foremost a message exchanging model. It does not directly control end devices, but rather "informs and motivates". Product manufacturers rightly want to control their user experience to respond appropriately to grid needs, and typically don't want to give direct control to utilities. Utilities know what they need to operate the grid, but aren't experts on end load control. Therefore, OpenADR is limited to providing information about the load shifting need, and the device manufacturer or owner takes that information to determine how best to respond and participate, based on their own logic.

OpenADR operations

The key components of an OpenADR enabled program are a Virtual Top Node (VTN) and Virtual End Node (VEN). The VTN is the server, it resides on the load aggregator / utility side and is responsible for registering devices and communicating to them. The VEN is the client, it works on the device side and receives the communication from the VTN. It communicates that message through to the devices that it represents, and responds to the server with any relevant information, such as device participation details, opt-outs, reporting and more. This relationship is one to many - one VTN connects with many VENs, and each VEN only connects to one VTN.

The two most common implementation models for VENs are in the cloud or on-site.

Cloud VENs are most common in the residential and commercial sectors, where there are large numbers of relatively small loads controlled by smart devices. In this model, the VEN is hosted on the device company or load aggregator's existing device controls platform. Product companies create one VEN per VTN, and register all the participating devices in the VTN's program territory to that VEN. The logic to control devices in response to the OpenADR signals can all be handled by the existing device controls infrastructure. This is the most practical model at this scale, since the utility then doesn't have to deal with the technical complexity of managing each individual device.

An on-site VEN is more common in large commercial & industrial (C&I) sites. Here, a VEN may be integrated into the on-site energy management system hardware, or as separate hardware device installed to act as the VEN pass signals directly through to end devices or to the building controls system. This is a manual process with some cost associated with it, but is easier to justify because of the higher amount of load controlled per device and per site, and there is already an on-site professional energy manager to help. As C&I energy management platforms move their intelligence from on-premise into the cloud, we expect to see C&I VENs follow.

Whether in the cloud or on premise, the operations of the VEN are the same: it is a logical endpoint to receive OpenADR signals from a VTN and pass it through to some system that will determine how best to respond.

Easy as A B (C)

Currently OpenADR comes in two flavors - 2.0a and 2.0b.

OpenADR 2.0a is essentially OpenADR-lite. It only requires device registration and simplified Event service - which refers to the signalling of load shifting events.

OpenADR 2.0b is the full specification, the most noteworthy augmentations include

• Enhanced event messaging
• Enhanced device grouping and targeting capability
• Opt-out communications

OpenADR 2.0a is often fine for getting started and for simple events, but it is blunt. As programs get larger and more complex, and utilities want to fine-tune their programs and create more complex load shifting logic, we expect the majority of programs will ultimately require OpenADR 2.0b.

OpenADR 2.0b contains an extensive list of commands. In order to be OpenADR certified, a VEN and VTN need to be able to fulfill all of them. The vast majority of programs will only use a subset of them, depending on that program's specific needs. Therefore, the logic required to participate in any individual OpenADR program at both the client side and server side will be smaller than the full OpenADR specification implementation. But, certification is usually required to participate in programs, and rightly so - we have repeatedly seen that implementing with an uncertified VEN and VTN can lead to a lot of frustrating bugs, since the certification process catches implementation errors.

OpenADR continues to evolve with market needs, with additional specifications in the works for enhanced DER controls and Transactive Energy. Rather than create an official "C" profile, these will be extensions to the 2.0b profile.

OpenADR in action

As of 2020, OpenADR is gaining momentum with many new and existing programs switching over to use OpenADR. Most OpenADR implementations are in North America, but significant demand is materializing internationally in Europe, Japan, Australia and more. We are populating a list of programs that use or require OpenADR to track where it is being used and/or required. Many programs do not have publicly available information, so not included on this list, but we will add to the list as we are allowed. If you would like to include your program on the list, please contact us.

To learn more

• The OpenADR Alliance website is the most complete source of information on the OpenADR protocol.
• QualityLogic has been heavily involved in OpenADR protocol development, training and testing for 10 years. They offer both in person and online training courses.
• You can also check out our introductory slide deck on OpenADR for more information on how the protocol works.

If you have any questions, feel free to reach out to us!