Conceptual Overview - OpenADR and Plaid

This section provides a basic overview of how OpenADR works and how Plaid implements it. For more generalized discussion and information, see our various information on the topics covered in our blog.

OpenADR

OpenADR is a protocol built to facilitate demand response and load shifting communication on the power grid. It is a server/client protocol, meant to facilitate communications between one central hub and many nodes. The simplest way to understand it the server side represents utilities and the client side represents end device owners or operators. Examples of end devices could be:

• Thermostats
• Water Heaters
• EV Chargers
• Solar / Storage / Inverters
• Building Management Systems
• Lighting Controls Systems
• Industrial Controls Systems

OpenADR defines the communication between the utility and the end devices. Within OpenADR, the nomenclature for the server side is Virtual Top Nodes, or VTN, and Virtual End Node, or VEN, for the client side. VTNs and VENs are connected in a one to many relationship.

OpenADR is used to describe market conditions and events (e.g. there is an event on Tuesday between 4-6pm), and does not have specific commands for controlling devices (e.g. telling thermostats to increase set points). Think, inform and motivate, rather than command and control.

The general philosophy behind this is that device manufacturers and/or owners are best placed to decide how their devices should operate in different conditions and therefore should be the ones making those decisions. All they need from utilities is information about market conditions so that they may respond appropriately.

This means that the device manufacturers and owners are active participants in load shifting programs and making this work, and there is a lot of logic and processes that still needs to be implemented outside of OpenADR. The following diagram shows a high level overview of a typical program.

4 key things that OpenADR handles are:

• Registration: registers a VEN to a VTN, (for security, this also requires a step outside of OpenADR to communicate the secure certificate fingerprint)
• Events: VTN communicates information about upcoming load shifting requirements and market conditions
• Opts: VEN communicates whether it will be participating in a given event
• Reports: reporting of ongoing metrics such as device status or power usage

It is up to the companies that control load consuming devices to define how they want to respond to the various OpenADR signals. This requires:

1. A business understanding of the various incentives available for participating in these programs and how best to control their devices to capture the value.
2. Facilitating the owner of the device (e.g. a commercial building manager or residential homeowner) to give permission to the utility to control their load.
3. Technical capability to integrate OpenADR into their device controls system.

Plaid provides item #3. It can be thought of as the translation layer between OpenADR and existing device controls systems. OpenADR is a protocol with a lot of power and flexibility to execute different types of programs, and flexibility by necessity means complexity. Rather than implement the whole protocol themselves, Plaid users get a full implementation of OpenADR from Plaid, and expose only the parts required to execute specific utility programs. This means they get to tap into the full power of OpenADR without the complexity.

How Plaid implements OpenADR for our customers

Plaid is implemented as a microservice and can run in either Windows or Linux operating systems. This means that it runs as a standalone executable, and exposes interfaces to connect to external systems. For Plaid, those systems are the utility VTN and the customer's device management systems.

While our customers get the source code and can explore as they see fit, the full OpenADR implementation can be thought of as a black box that does not need to be touched. Plaid exposes a plugin that provides an interface for passing through OpenADR messages into our customers existing platform and managing the VEN.

Each instance of Plaid is a single OpenADR VEN. As we covered in the last section, VTN <> VEN relationship is one to many, therefore if customers are connecting to, for exampele, 5 different VTNs, they will need to run 5 instances of Plaid.

Plaid and OpenADR certification

The OpenADR alliance maintains a product certification process, and a publicly available list of certified products. Certification provides a stamp of approval that the VEN will integrate into OpenADR VTNs easily, so most load shifting programs require certification.

Plaid itself is a full implementation of OpenADR 2.0b, certified by the alliance. After installation, Plaid customers get their own fully certified OpenADR 2.0b VEN, meaning they get listed on the Alliance list of products as though they had built it from scratch. As part of the Plaid implementation we walk our customers through the certification process and guarantee certification.

The primary concern of the OpenADR certification process is that the VEN is capable of responding to all of the various types of VTN requests in a manner consistent with the protocol. Therefore the requirements for the actual end device control are relatively light. In order to become certified, customer's implementations need to be able to do at minimum the following:

• Start control when an event starts
• End control when an event ends
• Query report data
• Asynchronous opt in/out of an event

That is all that's required for certification, and that's all we recommend our customers do to start with. As they integrate into different utility programs and see different requirements and ways utilities are using OpenADR, they will need to update their integration to comply with them, so the default stance should be to wait to invest in grouping, reporting, different signal types, etc., through to the end device level until facing an explicit program requirement. Anything they may encounter through OpenADR is available in Plaid, it just needs to be exposed through the plugin and processed accordingly in their system.

Typical Plaid implementation model

The most common implementation model is to host instances of Plaid in the existing cloud platform. This is the preferred implementation for any customers that already have a cloud-based controls system.

There is one VEN per VTN. Through the plugin, the VENs would pass the OpenADR communications to the device control system, which would then determine a) how best to respond to the VTN, and propogate that back through Plaid, and b) how to control the end devices, and propogate that to the end devices.

Other implementations are possible, for example:

• Multiple VENs per VTN, if the utility wants to have control over specific subgroups such as geographic areas (although this also can be handled through groupIDs and resource IDs, which is a more advanced topic).
• On device VEN, if required by the program, VENs can be hosted on device. While this has been proposed many times and executed in pilots, in practice we have not seen it required in production programs as it would get unwieldy at scale. It can be practical for large commercial and industrial buildings and campuses, and in those situations they also have an opportunity to buy a physical device that implements a VEN, such as the one sold by Universal Devices.

Summary

Plaid is a licensed software solution that fully implements OpenADR 2.0b, which is an important enabling technology for device companies to participate in load shifting programs. Device companies get their own OpenADR VEN certified by the alliance as though they had built it from scratch, and Plaid covers any of their future requirements or potential issues with OpenADR.

If you have any questions or clarifications on these topics, please refer to our blog, look through the FAQs or reach out through contact@gridfabric.io.

Next, look at the Plaid conceptual overview for an overview what it takes to implement Plaid in your stack.