INTRODUCTION
California utilities have been exploring the use of critical peak pricing (CPP) and other DR pricing and program strategies to help reduce peak day summer time electric loads. Recent experience with demand response (DR) has shown that customers have limited knowledge of how to operate their facilities to reduce their electricity costs under CPP or in a DR Program. While the lack of knowledge about how to develop and implement DR control strategies is a barrier to participation in DR programs like Critical Peak Pricing (CPP), another barrier is the lack of full automation of DR systems. Most DR activities are manual and require building operations staff to first receive emails, phone calls, and pager signals, and second, to act on these signals to execute DR strategies.

[an error occurred while processing this directive]

Fully-Automated DR does not involve human intervention, but is initiated at a home, building, or facility through receipt of an external communications signal. The receipt of the external signal initiates pre-programmed DR strategies. The authors refer to this as AutoDR. One important concept in AutoDR is that a homeowner or facility manager should be able to “opt out” or “override” a DR event if the event comes at time when the reduction in end-use services is not acceptable.

From the customer side, modifications to the site’s electric load shape can be achieved by modifying end-use loads. Examples of DR strategies include reducing electric loads by dimming or turning off non-critical lights, changing comfort thermostat set points, or turning off non-critical equipment. These DR activities are triggered by specific actions set by the electricity service provider, such as dynamic pricing or demand bidding. Many electricity customers have suggested that automation will help them institutionalize their DR. Lawrence Berkeley National Laboratory (LBNL) research has found that many building energy management and controls systems (EMCS) and related lighting and other controls can be pre-programmed to initiate and manage electric DR.

This article provides an overview of the AutoDR field tests and implementation activities from 2003-2007 and focuses on the concept for and lessons from the development and field-testing of an open, interoperable communications infrastructure to support automating DR.

1. TECHNOLOGY HISTORY
The automated DR project began in 2002 following California’s electricity market crisis with the goal of addressing three key research questions. First, is it possible using today’s technology to develop a low-cost, fully automated infrastructure to improve DR capability in California? Second, how “ready” are commercial buildings to receive common signals? Third, once a building receives a signal, what type of strategies are available that can be readily automated?

Research planning began in 2002 with a series of field tests and it is now in use with over 100 facilities in California.

1.1. 2003: Initial Development and Tests
The 2003 technology development began with the design of a fictitious price signal and automation server that could be represented in XML (Extensible Markup Language) to support interoperable signaling. The automation uses client/server architecture and has been tested with both pull and push communications designs. Five facilities were recruited And the criteria for recruitment included evaluating different types of facilities, multiple vendor Energy Information Systems, multiple vendor Energy Management and Control systems, multiple technology gateways, different types of ownership, and a variety of end-use load reduction strategies.

All of these sites had participated in DR and had been equipped with new communications and monitoring systems as part of California’s Enhanced Automation program. Preparations for the test involved the development of an automation server and the XML software client installations at each of the client sites. The client listens to the signal continuously and replies with the price level. The test resulted in fully automated shedding during two three-hour events with an average peak reduction of about 10%.

1.2. 2004: Scaled Up Tests with Relay
The design of the 2004 tests began with the consideration that many facilities did not have EIS and EMCS that could support XML. We reviewed existing technologies and modified the DR automation price server to interoperate with a low-cost Internet relay. The Internet relay is a device with relay contacts that can be actuated remotely over a local or wide area network or the Internet using Internet Protocols (IP). Eighteen sites were recruited to participate in a series of tests. To help in recruiting, the facility managers were offered the assessment of how “ready” their automation systems were to receive common signals for the future’s dynamic tariffs and DR program opportunities.

Figure 1 shows the geographic distribution of the participant sites along with the development sites and price-server clients. Many development sites for the XML software client were located outside of California. The price clients listening to the signals could be implemented outside California, as the figure shows.

Figure 1. Geographic location of Auto DR facilities, automation clients, and server.

The average demand reduction for these 15 sites was 0.53 W/ft2 or about 14% of the whole building electric-peak demand. Table 1 shows an example of how a building would pre-program a response to general DR mode information. A facility manager can decide how to translate the general DR modes into whatever response strategy they choose.

Table 1. Sample DR building control strategies by mode (Note: HVAC – Heating, ventilation, and air conditioning)

1.3. 2005: Critical Peak Pricing
In 2005 we began our initial collaboration with the Pacific Gas and Electric Company to offer AutoDR as part of the Critical Peak Pricing (CPP) Program. To participate, a site had to be willing to go onto PG&E’s CPP tariff. The tariff offers a rate discount during most summer days, but prices increase on CPP days as shown in Figure 2. Fifteen facilities participated in the Automated CPP tests. CPP usually is called 12 times in each summer but because the automation systems took time to install, the tests were not conducted until late in the summer. For the eight sites participated in the fully automated CPP event on September 29th, 2005, the average DR ranged from 0 to 24% per site for the medium price period and 4 to 28% per site during the high price period, with an average of 9% and 14% overall for the two price periods.

Figure 2. Critical peak price tariff compared with TOU

The 2005 automated CPP test used a new automation server renamed as the DRAS – DR Automation Server.

1.4. 2006: Scaled Up Automated CPP
Following the pilot automated CPP test in 2004 we began a more formal partnership with PG&E’s Emerging Technologies Program. In addition to recruiting new sites into the program, we had about eleven sites that had fully automated CPP response for the entire summer with 12 events. More importantly, we provided this automation system through a severe heat wave in July 2006. Each site continued to reduce their loads over many days during this 1.5-week event. None of the sites opted out or overrode the automation capability, although that option was available. Figure 3 shows an automated DR shed at an office building in Martinez California. The shed shows a classic response with the first level of response based on resetting the zone temperatures up a few degrees, and second level additional temperature reset response during the three-hour high price period. Over 100 kW was shed during the high price period with no rebound when the building went into unoccupied mode after 6 pm.

Among the Auto-CPP sites, site responses to 125 events were fully automated and evaluated in this study. The average peak demand reduction was 14% of the whole-facility load based on the three-hour high-price period.

As we brought the technology out to a large customer base we found that the Internet relay had some communications security issues for some customers. A hole in the corporate firewall was some times needed to allow the relay to communicate with the server. As a result of that finding, a new client was developed. This technology, known as the Client and Logic with Integrated Relay, or CLIR, was developed as an IT friendly “plug and play” automation client. It is typically installed inside of the secure enterprise network and “polls” for CPP event information using 128 bit secure socket layer (SSL) encryption and authentication using HTTPS protocol. HTTPS is also used for most online financial transactions. No modification to corporate enterprise firewalls is required.

Figure 3. Example of load shape change with AutoDR

[an error occurred while processing this directive] 1.5. 2007: Commercialization and Program Expansion
Following the hot summer of 2006 the California Public Utilities Commission requested the three California Investor Owned Utilities to partner with the Demand Response Research Center to begin using AutoDR technologies. As part of that effort we developed a more formal definition of AutoDR to outline the principles for the automation system design. Automated DR for commercial and industrial facilities can be defined as fully automated DR initiated by a signal from a utility or other appropriate entity and provide full-automated connectivity to customer end-use control strategies.

Signaling - AutoDR technology should provide continuous, secure, reliable, two-way communication with end-use customers to allow end-use sites to be identified as listening and acknowledging receipt of DR signals.

Industry Standards - AutoDR consists of open, interoperable industry standard control and communications technologies designed to integrate with both common energy management and control systems and other end-use devices that can receive a dry contact relay or similar signals (such as internet based XML).

Timing of Notification - Day ahead and day of signals are provided by AutoDR technologies to facilitate a diverse set of end-use strategies such as pre-cooling for "day ahead“ notification, or near real-time communications to automation "day of" control strategies. Timing of DR automation server (DRAS) communications must consider day-ahead events that include weekends and holidays.

1. The AutoDR architecture has five steps (Figure 4). The steps are as follows:

2. The Utility or ISO defines DR event and price signals that are sent to the DRAS.

3. DR event and price information are published on the DRAS.

4. DRAS Clients (CLIR/Web Service) request latest event information or price from the DRAS every minute.

5. Customized pre-programmed DR strategies determine action based on price.

6. Facility EMCS carries out pre-programmed shed strategies.

Figure 4. Automated Demand Response Architecture

The Pacific Gas & Electric Company AutoDR program was expanded to include both CPP and demand bidding. Over 22 MW have been recruited into the DR programs.

2. NEXT STEPS AND FUTURE DIRECTIONS
This paper has presented the history and status of automated DR research and initial commercialization activities in California. The research began with advanced control and energy information systems that could host XML-based signals. Recent work has included automating relay signals with Internet based communications in secure, open web services architecture. Research on commercial buildings control strategies has also shown good potential for wide spread DR. Future efforts include standardization of the communications and signaling systems, and efforts to move the technology into future building codes and standards. This technology is also described in other DRRC papers, available here – http://drrc.lbl.gov.

3. ACKNOWLEDGEMENTS
The work was sponsored by the Research Center (http://drrc.lbl.gov) which is funded by the California Energy Commission (CEC), Public Interest Energy Research (PIER) Program, under Work for Others Contract No.500-03-026, Am #1 and by the U.S. Department of Energy under Contract No. DE-AC03-76SF00098. The authors are grateful for the extensive support from numerous individuals who assisted in this project.

[an error occurred while processing this directive]
[Click Banner To Learn More]

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