Sep 4th, 2019
Sep 4th, 2019
The goal of this post is to give the reader an overview of the OpenADR standard. It is meant for those who understand the concept of load shifting but are new to OpenADR or still learning the basics.
Why Standards are Helpful
Power grid operators gain a lot of value if their customers shift load from peak to off peak times, so they are interested in getting permission to directly control end devices, such as thermostats, water heaters, and more. Direct control requires automated communication. When load shifting was in early days, it made sense for the device companies to integrate directly with the utility. They were both still figuring out what they needed from each other, so a lot of manual integration was always necessary.
Now that load shifting programs are hitting the mainstream, this must change. There are dozens of device categories, hundreds of product manufacturers, and thousands of utilities. Without standards, if a utility has a successful load shifting program and they want to open it up to all devices to participate, they would have to integrate individually with every one. Or, if the utility standardizes their API and asks device companies to integrate with them, then each device company would have to do new manual work at every new utility.
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 provide what they think is best, and typically don't want to give direct control to utilities. Therefore, OpenADR is limited to providing information about the load shifting need, and the product manufacturer takes that information to determine how best to respond and participate based on their own logic.
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.
A VEN typically sits on top of the product company's existing device controls platform. A company would therefore need one VEN per load shifting program, so it can register with that program's VTN, and would register all the participating devices in the territory through that VEN. The logic for which devices to turn off and on in response to the OpenADR signals can all be handled by the existing device controls infrastructure. This is the cloud VEN model, which is typically a relationship of one VEN that aggregates many devices behind it.
An alternate, less used configuration is to put the VEN on each individual device. The main downside to this is complexity - the VTN would then need to register and communicate to many VENs. OpenADR can be a data-rich protocol, so this would lead to a lot of network chatter, which often will not work for IoT devices as they are bandwidth-constrained. The benefit to this configuration would be increased visibility and granularity for the utility side, though that can be a double-edged sword.
A B (C)s
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 OpenADR certified, a VEN and VTN need to be able to fulfill all of them. However, 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 is usually significantly smaller than the full OpenADR specification implementation.
OpenADR continues to evolve with market needs, currently working on additional specifications for enhanced DER controls and Transactive Energy.
OpenADR in action
As of 2019, 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.
A few examples of OpenADR implementations:
- PG&E Commercial Demand Response program
- Hawaiian Electric Company
- SMUD PowerDirect program
- National Grid Gas DR program
- SCE Charge Ready program
To learn more
The most complete source of information is the OpenADR Alliance website. If you have any questions, feel free to reach out to us!