June 2008
  
AutomatedBuildings.com

Innovations in Comfort, Efficiency, and Safety Solutions.
Belimo

(Click Message to Learn More)


Open Automated Demand Response Communication Standards
Six years of research, development, and demonstration have led to these standards.

Girish Ghatikar, Mary Ann Piette, Sila Kiliccote
Demand Response Research Center (DRRC), Lawrence Berkeley National Lab (LBNL)
http://drrc.lbl.gov/ 

Abstract:

The development of the Open Automated Demand Response (Open Auto-DR or OpenADR) Communication Standards began in 2002 following the California electricity crisis. Many utilities, governments, electric independent systems operators (ISOs) have been pursuing demand response to manage growth in peak electric demands and to provide more economic and reliable energy. Demand Response (DR) has been defined as “…action taken to reduce electricity demand in response to price, monetary incentives, or utility directives so as to maintain reliable electric service or avoid high electricity prices1 .” The research that led to this communications standard was funded by the California Energy Commission’s Public Interest Energy Research Program and is the first of its kind.

Articles
Interviews
Releases
New Products
Reviews
Blogs
Sponsors
Archives
Past Issues
AutomatedBuildings.com

Control Solutions, Inc

The work has been carried out by the Demand Response Research Center which is managed by Lawrence Berkeley National Laboratory. The initial goal of the research was to explore the feasibility of developing a low cost communications infrastructure to improve the reliability, repeatability, robustness, and cost-effectiveness of demand response in commercial buildings. One key research question was: could today’s information, communications, and controls technologies be integrated to automate the response of commercial buildings to standardized electricity price signals? Six years of research, development, and demonstration have led to these standards. Open Auto-DR outlines communications standards using secure web service or service architecture (SOA) to send demand response signals to end-use customer systems. Open Auto-DR defines a “data model”. Open Auto-DR does not specify a particular technology. The DRRC has collaborated with Akuacom Inc in the development of the standard.

Definition of OpenADR Communications

Open Automated-DR Communications have the following defining features:

Continuous and Reliable - Provides continuous, secure, and reliable two-way communications infrastructure in which the clients at the end-use site receive and returns acknowledgement to the DR automation sever upon receiving the DR event-based signals.

Translation - Translates DR event information to continuous internet signals to facilitate automation of DR. These signals are designed to interoperate with Energy Management and Control Systems (EMCS), lighting controls, or other end-use control devices.

Automation - Receipt of the external signal is design to initiate automation through the use of pre-programmed demand response strategies determined and controlled by the end-use customer. .

Opt-Out - Provides opt-out or override function to consumers to DR event if the event comes at a time when reduction in end-use services is not desirable.

Complete Data Model - Describes a rich data model and architecture to communicate price, reliability, and other DR activation signals.

Scalable - Provides and communications architecture scalable to different forms of DR programs and tariffs.

Open Standards - Open standards-based technology such as Simple Object Access Protocol (SOAP) and web services form the basis of the communication standard.

The intention of OpenADR standardized signaling is to allow building and industrial control systems to be pre-programmed, enabling a demand response event to be fully automated with no human in the loop. The standards are comprehensive and incorporates flexible infrastructure design to facilitate common information exchange between utility or ISO, and end-use customers. The concept of an open standard is intended to allow anyone to implement the signaling systems, providing the automation server or the automation clients. The automation system is being formalized in these standards, which present a series of DR uses cases, functional requirements and an open data model for OpenADR.

Standards for Generalized Use Cases for DR Programs

The figure 1 below shows the various demand response functions (actions) as they exist across the various use cases of these standards and is useful for identifying actions which are common across all DR programs.

Figure 1: Various Demand Response Functions and Actions Proposed by OpenADR

Figure 1: Various Demand Response Functions and Actions Proposed by OpenADR

In analyzing the DR programs so far one can see that there are two general classes of functions using Generic Event-Based Program (GEP) as shown in figure 2 below:

1. Actions related to the automation of DR event notification.

2. Actions related to the automation of the DR bidding process.

Figure 2: Automated DR Event Notification Using OpenADR

Figure 2: Automated DR Event Notification Using OpenADR

Automated Demand Response Architecture

Figure 3 below show the architecture of the components that interface to the DRAS to manage actual automated DR events. The standards also specify architecture of the components that interface to the DRAS to automate the submissions of bids by participants in a DR program that requires bidding by the participants.

The look and feel of the user interface used to perform various functions on the DRAS is outside the scope of this standard. Thus the DRAS UI Web Server and the Web Client are shown outside the realm of the DRAS. What is standardized is the exchange of information with the DRAS that allows a user interface to be built that can be used to view and manipulate the information exchanged with the DRAS. By using the standardized information exchange specified in this standard it will be possible for third parties to build a user interface with their own look and feel and still interact with the DRAS in a standard fashion.

The “Third party Notification System” is a sub-system is responsible for notifications to operators using various existing technologies such as phone, pages, email, fax, etc. The systems may be part of the Utility infrastructure, but since the most general case is that they are a stand alone service that is what is depicted in the diagrams. In the architecture the DRAS itself is depicted as a stand alone service from both the Utility and Participant’s IT infrastructure. This is the most general case and is what is used as the main use case in this standard. In fact specific incarnations of the DRAS may be integrated within either the Utility or Participant’s IT infrastructure.

Figure 3: General Automated DR Events Architecture with Standalone DRAS
Figure 3: General Automated DR Events Architecture with Standalone DRAS

Benefits of OpenADR

The OpenADR standards offer following potential benefits to the stakeholders:

OpenADR Public Review Process

The OpenADR draft was officially released in conjunction with Connectivity Week on Monday, May 19 in Santa Clara, CA. The OpenADR Communication Standards and supporting documents for its first public review and comment process along with contact information are posted on http://drrc.lbl.gov/openadr/. Please review and send your comments and also, encourage the stakeholders to do the same.


[1] [1] U.S. Federal Energy Regulatory Commission (FERC), 2007 Assessment of Demand Response and Advanced Metering, Staff Report, available: http://www.ferc.gov/legal/staff-reports/09-07-demand-response.pdf

footer


[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources