Open Automated Demand Response (OpenADR)

History and development

OpenADR is a royalty free and open standard for automated demand side response. It was originally developed by the Lawrence Berkeley National Laboratory, partly in response to the California electricity crisis in 2000/2001, where there was a need for greater system flexibility to improve grid resilience (amongst other measures).

The standard has since been taken over by the OpenADR Alliance who have overseen the development of OpenADR 2. The OpenADR 2b standard is also now an IEC PAS with a view to it being developed into a full IEC standard in the near future.

OpenADR 2 is aligned with the Energy Interoperation and Energy Market Information Exchange OASIS standards, which are likely to see wide adoption amongst US Energy utilities. A significant recent development has seen OpenADR 2b mandated as the de-facto standard for automated demand response of HVAC and lighting appliances in statewide California Building Energy Efficiency Standards.

General Features

OpenADR provides a data model, control sequencing, and a method of data exchange for demand side response systems. It describes the different parties in such a system as actors within a service oriented architecture (SOA), as is typically found in modern internet connected systems.

The primary actors in OpenADR are Virtual Top Nodes and Virtual End Nodes. There can be an arbitrary number of exchanges between VTN and VEN, and a VTN can also act as a VEN (or vice versa).

Data transfer uses an XML format over HTTPS (or XMPP). These core IP-based technologies benefit from almost universal support in internet-connected devices. This makes implementing OpenADR on a wide variety of devices straightforward, including on low-power microcontrollers and the SoCs which are increasingly used in domestic appliances.

The primary technological benefit of adopting an open standard like OpenADR is the use of an existing well developed data model, control flow and sequencing which supports a wide range of use cases and DER device types based on real-world experience.

OpenADR 2 is specified as a series of profiles of the total available functionality (named ‘a’, ‘b’, and ‘c’). The ‘a’ profile is the simplest, intended for low power devices, and contains only a limited subset of the OpenADR command set. It is comparable to the demand side response functions found in Zigbee SE 1.x. The ‘b’ profile then contains a wider array of functionality, and ‘c’ contains everything.

Security

Security has been a key consideration in the development of OpenADR, which has been targeting US NIST standards in its development. The primary method of encryption and authentication is using mutual TLS (X509 client/server certificate pairs). Partly by coincidence this has emerged as the industry standard for IoT message encryption and authentication. Message payloads can also be signed by both VTN and VEN devices for increased security. The specification also covers some aspects of authorisation although this is largely left as an implementation detail.

What OpenADR is not

OpenADR describes the data and sequencing of demand response control as well as prescribing the application layer protocols which are used and (to a lesser extent) how they are used.

In this respect it differs from smart grid standards like SGAM and USEF, which are higher level and broader (and largely compatible pending current harmonisation efforts). It also takes a different approach to low-level hardware-based standards like Zigbee Smart Energy, which go further in specifying other network layers as well as the physical hardware on which applications run.