Advancing automated demand-response technology.

INTRODUCTION

Buildings are the largest energy end use sector in the United States, accounting for 40% of total energy consumption and 72% of electricity consumption (DOE 2007). In recent years as the electric utility industry has grappled with ways to meet the nation's needs for a reliable electricity supply delivered through a robust distribution grid, it has been widely recognized that cooperative management of building energy loads is an important factor.

Utilities throughout the country have implemented a wide variety of programs to curtail load in times of stress on the electricity distribution grid or on generating capacity (DOE 2007; FERC 2007). Although these programs have shared a common goal of reducing peak electricity demand, there has been little commonality in the details of the programs or the methods for communicating with customers. There have been some successes in these programs, but none of them has emerged as a clear "winner" in the sense that the utility industry has embraced it as a model for how the industry should operate in the future. The time may be right for breakthrough improvements in the ways in which buildings interact with utility providers and electrical loads are managed. Recent events in three different areas offer the potential for a combined impact that could result in a significant advancement.

First, in December 2007, the Energy Independence and Security Act was signed into law (U.S. House of Representatives 2007). This law established national goals for a dramatic reduction in energy consumption in buildings and also mandates specific actions to be taken to develop a "smart grid" electrical generation and distribution system. This legislation is expected to spur efforts in both the private sector and in government to help achieve these goals.

Second, ASHRAE has published recent additions to the Building Automation and Control Networks (BACnet[R]) communication protocol standard that provide a mechanism for shedding building energy loads and a basis for establishing building-utility communication (ASHRAE 2006, 2007). BACnet has been adopted by the European Committee for European Normalization (CEN), the International Organization for Standardization (ISO), and as a national standard in over 30 countries. Perhaps more importantly, it has become well established in the world marketplace. As BACnet technology becomes more prevalent in commercial buildings around the world, it provides a powerful building block upon which to base building-utility interactions.

The third significant development is the establishment of a research/demonstration project funded by the California Energy Commission called the Demand Response Automation Server. This project had a very modest beginning, but interest has grown over time, and today there is a broad interest and involvement from a diverse set of industry stakeholders. It has the potential to build on the successes of past utility programs in combination with the adoption of new technology in such a way that it could result in significant breakthrough improvements. It has the potential to become a model for utilities nationwide and drive the development of new industry standards for demand-response applications.

This paper discusses the potentially synergistic interaction of these three activities and how, in combination, they can change the way in which building electricity use is priced and managed.

THE ENERGY INDEPENDENCE AND SECURITY ACT OF 2007

The Energy Independence and Security Act of 2007 (EISA) established broad energy policy goals for the United States, as well as specific responsibilities for various federal government agencies. Three sections of that act have implications for building electricity consumption and building-utility interactions.

Title IV Energy Savings in Buildings and Industry establishes national goals leading to "zero net energy commercial buildings," buildings that produce as much energy as they consume. One goal is to achieve net zero energy for new commercial buildings built after 2025. A further goal is to retrofit all pre-2025 buildings to net zero energy by the year 2050. Achieving these targets will require a combination of strong energy conservation measures, on-site generation of energy from renewable sources, and possibly complex interactions with the electricity grid. Also included in this section are requirements for the federal government to take steps to implement new technologies and meet energy reduction targets in federal buildings in order to lead the way to achieving the broad national goals.

Title V Energy Savings in Government and Public Institutions includes a directive to the Federal Energy Regulatory Commission (FERC) to conduct a national assessment of demand response (DR), including an estimate of nationwide DR out to a ten year horizon. FERC is also directed to prepare a National Action Plan on Demand Response in cooperation with the industry. Utilities are directed to modify their rates to align their incentives with the delivery of cost-effective energy efficiency and to promote energy-efficiency investments.

Title XIII Smart Grid establishes a national policy to modernize the electricity grid in a number of dramatic ways. The act specifically calls for the development and implementation of demand-response systems and provision to consumers of "timely information and control options." The term smart grid refers to a distribution system that allows for the flow of information from a customer's meter in two directions: to appliances and energy-consuming devices inside the building, and from the building to the electric utility. It also establishes a structure for coordinating standards and technology development efforts. The National Institute of Standards and Technology is assigned the task of establishing protocols and standards to increase the flexibility of use for smart grid equipment and systems. The U.S. DOE is assigned several tasks related to development and deployment of the new technology.

EISA assigns specific responsibilities to federal agencies and authorizes significant federal expenditures to carry out these responsibilities. However, it does not appropriate any funds. The impact of the law will depend in part upon funding decisions yet to be made by Congress. No matter what level of funding is eventually provided, it is expected that EISA will influence decisions made by federal agencies. It will also indirectly impact the actions of state and local governments and private organizations. It is a clear signal of a strong national interest in this area.

BACNET--A TOOL FOR IMPLEMENTING LOAD MANAGEMENT AND UTILITY COMMUNICATION

As previously noted, building automation and control systems implementing the BACnet communication protocol have become well established in the marketplace. BACnet makes an excellent platform for providing building-utility communication. This potential has been recognized for several years, and some recent additions to the BACnet standard are steps toward realizing that goal.

Addendum e to the current version of BACnet introduced the concept of a load control object (ASHRAE 2007). The load control object provides an abstract, high-level interface used to implement arbitrarily complex load shedding strategies. The load control object accepts commands that specify how much and when load reduction is required. Upon receipt of a load shed request, a series of predetermined actions are triggered in an attempt to meet the load shedding requirement. These actions are customized for the facility and include things such as temperature setpoint changes, reduced lighting levels, and cycling equipment off.

The Load Control object also provides a network visible view of the progress on meeting the desired load level. Load control objects can be linked in a distributed, hierarchical fashion for controlling arbitrarily complex combinations of electrical loads found throughout a facility. The load control object provides a way to implement and monitor building energy load control, but it plays no role in communication with the utility provider. A different BACnet extension that defines a Web services interface has the potential to play that role (ASHRAE 2006; Tom 2004).

BACnet Web services were designed to make it easy to develop business applications that make use of data from a building automation system and potentially interact with the building control functions. Web services communicate via messages that are created with the Extensible Markup Language (XML) (W3C 2006). These messages are encapsulated using the Simple Object Access Protocol (SOAP) (W3C 2007) for transmission over computer networks. The appeal of a Web service interface is that a rich set of widely used tools are available to application developers that facilitate the efficient development of custom application interfaces. An application developer using Web services does not need to understand the building automation system design, control algorithms, or communication protocol details. This makes Web services well suited for linking building system data to business applications such as accounting systems, scheduling tools, and utility load management.

The BACnet Web services data model was intentionally designed to be generic, allowing the Web services client to read and write simple data values (integers, real numbers, strings, dates, etc.) and to retrieve trend data. This is important for utility integration for two reasons. A BACnet Web services interface can be created even for legacy building automation systems that do not use BACnet, thus expanding the pool of buildings that can be reached (Figure 1). The second important feature is that it allows for rapid prototyping and testing of variations in the way in which building-utility interactions can be implemented. This creates an opportunity for real world testing and refinement in a system such as the California-Energy-Commission-sponsored Demand Response Automation Server.

[FIGURE 1 OMITTED]

When an industry consensus emerges about the details of effective building-utility communication, specific BACnet Web services that are customized for that purpose, with clear mappings to the underlying BACnet control system, can be added to the standard making widespread adoption faster and easier. Adding such a capability to a BACnet control system would involve adding or modifying the BACnet Web server, but not the underlying control system.

THE DEMAND-RESPONSE AUTOMATION SERVER

Demand-response (DR) activity has been defined as "an 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 prices" (FERC 2007). These actions may be in the form of load shedding, intelligent demand management, use of energy storage, fuel-switching, or backup generation. DR programs provide incentives to curtail demand and reduce load during system reliability events (grid component failure) or during peak periods (high demand and high price).

There is a wide variation in utility DR programs, but with some general classes. Most programs involve commitments to cut load in response to a utility directive. A different approach is the real-time pricing programs that require no customer commitment to shed load, but rather expose the customer to market electric prices and allow the customer to shed load or not in response to those. The Pacific Gas and Electric Company (PG&E) Critical Peak Pricing (CPP) program follows the first model with a utility directive to shed load on a limited number of peak days, and customers see increased electric rates during the peak event time interval. A completely different approach for customer DR is for the customer to offer shed load as "generation" that is bid into the electricity market.

In 2002, Lawrence Berkeley National Laboratory (LBNL) began an automated DR project with funding from the California Public Interest Energy Research (PIER) program. The long-term goal of this project is to understand the opportunities for automating DR and to remove technical and market impediments to large-scale implementation of automated DR in buildings and industry. A second goal is to understand and identify best practices for DR strategies and opportunities (Piette et al. 2006).

Project tests began in 2003 using simulated price signals and XML Web services distribution to evaluate automated load shedding. In 2005, the project was expanded in collaboration with PG&E to support the PG&E CPP program. The CPP tests used a new automation server called the DR Automation Server (DRAS). More recently, the system architecture that includes the DRAS, in addition to the open standards used in system communications, has been called Open Automated DR, or OpenADR. OpenADR specifies automated communication of DR signals from utility (or independent system operator, ISO) to a customer facility combined with preprogrammed automated facility response. This fully automated communication and control is accomplished securely and reliably using industry standard open protocols.

The DRAS conceptual architecture is shown in Figure 2. The DRAS acts as an interface between utilities and customers to allow communications with any utility implementing that same interface. Each customer facility (or aggregator) hosts a DRAS client that is responsible for bridging communications between the DRAS and the EMCS. The DRAS client may be a client and logic with integrated relay (CLIR) box (Piette et al. 2007), or a software Web services (WS) client embedded in more sophisticated EMCS. The CLIR was introduced in 2006 and accomplishes two main purposes: it handles Internet communications securely as a Web client polling the automation server for CPP event notices, and it communicates these event signals via relay connections to simple building energy management and control systems (EMCS). This in turn allows more facilities to participate in the DRAS CPP program with lower configuration costs. More sophisticated EMCS with Internet connectivity do not need the CLIR.

[FIGURE 2 OMITTED]

DR event notifications are communicated and acted upon according to the following steps, indicated in Figure 2:

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

2. DR event and price services are then published on the DRAS.

3. DRAS clients, whether CLIR box or embedded WS client, request the latest event information or price from the DRAS every minute.

4. The EMCS then determines load shed action based on preprogrammed custom strategies.

5. The EMCS then carries out shed actions by commanding changes to electric loads on the control network.

At present, three DR program types are included in the DRAS: CPP event notifications, real-time pricing (RTP) price signals, and demand bidding (DB) (Koch and Piette 2007). The system is designed to allow utility and customer configuration of the DRAS, and DRAS event feedback, in addition to event notifications. The system is slated for testing in 2008 with three California utilities in addition to several aggregators and serving over 100 facilities.

In 2007, LBNL began working more closely with experts nationwide with the goals of moving DRAS use beyond California, connecting with stakeholders in the standards arena, and an eventual goal of a standard automated DR architecture that ties to buildings via standard protocols including BACnet. Effective, automated, and standard communications between utilities and facility energy management systems will be a critical component of realizing the potential of DR.

THE PATH FORWARD

The newly adopted BACnet load control object provides a standard, network visible interface for configuring and managing facility load shedding operations. This fulfills the role shown in Step 4 of Figure 2. BACnet Web services provides a standard way for business applications to interact with BACnet control systems, including the new Load Control object. A BACnet Web server can provide the building side of a standard building-utility interface. Both of these features are beginning to emerge in BACnet product offerings. The missing piece is standard Web service messages that are customized to the particular needs of DR.

The BACnet Utility Integration Working Group (UIWG) has partnered with LBNL and the DRAS development team to define and implement BACnet Web services as the communications link between the DRAS server and DRAS client using the generic capabilities that are already part of BACnet Web services. A demonstration of the DRAS event notification messaging using BACnet Web services was implemented at Connectivity Week in May 2008. The DRAS, incorporating BACnet Web services communications, will be tested with PG&E in summer 2008, and a full specification of the DRAS is planned to be published independently for the summer of 2008.

Concurrent to the development and testing of the DRAS, the ASHRAE BACnet Committee will use the DRAS application testing results to help drive extensions and development of the BACnet standard itself. BACnet Web services will be extended to support complex data types (such as the DRAS event notification message) that prove to be useful in the DRAS testing. In addition, the UIWG will continue to work on extending BACnet to support additional load shedding capabilities, including a standard interface to meters and standard support for linking distributed generation capabilities with the electrical grid.

Moving forward, the national emphasis on the smart grid and energy efficiency, the EISA impetus to coordinate standards, and the efforts of the BACnet committee in cooperation with the DRAS team and utilities will allow for more rapid development and utilization of automated DR tools and standards as part of the developing smart grid.

CONCLUSION

A clear path is being laid out for the success of automated DR. The determination of the country to save and manage energy for the health of the electric grid is shown clearly in the 2007 Energy Independence and Security Act, as well as in state-funded research efforts (such as DRAS) and state mandates that push DR technology forward. Given that most electricity is used in buildings, we cannot support DR efforts without the foundational BACnet building communications building blocks that allow for standardized approaches to energy management and utility communications. And we cannot effectively connect the utilities and customers without standards for communications between them. So, all together, the three elements of national will, developments of standard DR communications between utilities and customers, and standard tools to implement demand reduction within buildings portend a bright future for the growth of automated DR.

REFERENCES

ASHRAE. 2006. Addendum c to ANSI/ASHRAE Standard 135-2004, BACnet[R]: A Data Communication Protocol for Building Automation and Control Networks. Available at www.BACnet.org/Addenda/index.html. Atlanta: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ASHRAE. 2007. Addendum e to ANSI/ASHRAE Standard 135-2004, BACnet[R]: A Data Communication Protocol for Building Automation and Control Networks. Available at www.BACnet.org/Addenda/index.html. Atlanta: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

DOE. 2007. DOE Buildings Energy Data Book. Available at http://buildingsdatabook.eren.doe.gov/. U.S. Department of Energy.

FERC. 2007. 2007 Assessment of demand response and advanced metering, Staff report. Available at www.ferc.gov/legal/staff-reports/09-07-demand-response.pdf. U.S. Federal Energy Regulatory Commission.

Koch, E., and M.A. Piette. 2007. Architecture concepts and technical issues for an open, interoperable automated demand response infrastructure, LBNL-63664.

Piette, M.A., D. Watson, N. Motegi, S. Kiliccote, and P. Xu. 2006. Automated critical peak pricing field tests: Program description and results, LBNL-59351.

Piette, M.A., S. Kiliccote, and G. Ghatikar. 2007. Design and implementation of an open, interoperable automated demand response infrastructure, LBNL-63665.

Tom, S. 2004. Web services--A new BACnet standard. Automated Buildings. Available at www.automatedbuildings.com/, December 2004 archives.

U.S. House of Representatives. 2007. Energy Independence and Security Act, H.R. 6 (P.L. 110-140). Available at http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=110_cong_bills&docid=f:h6enr.txt.pdf. December 19, 2007.

W3C. 2006. Extensible Markup Language (XML) 1.0 (Fourth Edition). Available at www.w3.org/TR/xml/. World Wide Web Consortium.

W3C. 2007. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). Available at www.w3.org/TR/soap12-part1/. World Wide Web Consortium.

Steven T. Bushby

Fellow ASHRAE

David G. Holmberg, PhD

Member ASHRAE

Steven T. Bushby is Mechanical Systems and Controls Group Leader in the Building Environment Division and David G. Holmberg is a mechanical engineer in the Mechanical Systems and Controls Group, NIST Building and Fire Research Laboratory, Gaithersburg, MD.