PNNL-22169
Prepared for the U.S. Department of Energy under Contract DE-AC05-76RL01830
Small- and Medium-Sized Commercial Building Monitoring and Controls Needs: A Scoping Study S Katipamula MA Piette T Kuruganti RM Underhill J Granderson JK Goddard R Brown D Taasevigen S Lanzisera October 2012
PNNL-22169
Small- and Medium-Sized Commercial Building Monitoring and Controls Needs: A Scoping Study S Katipamula MA Piette1 T Kuruganti2 RM Underhill J Granderson1 JK Goddard R Brown D Taasevigen S Lanzisera October 2012 Prepared for U.S. Department of Energy under Contract DE-AC05-76RL01830 Pacific Northwest National Laboratory Richland, Washington 99352 1 Lawrence Berkeley National Laboratory 2 Oak Ridge National Laboratory
iii
Abstract
The U.S. Department of Energy’s (DOE’s) Building Technologies Program asked Lawrence Berkeley National Laboratory (LBNL), Oak Ridge National Laboratory (ORNL) and Pacific Northwest National Laboratory (PNNL) to identify monitoring and control needs for small- and medium-sized commercial buildings, and to recommend possible solutions. The scope of this study is to characterize the monitoring and controls needs for the various end uses (for both efficiency and demand response), determine requirements to develop control packages, and calculate the target cost of doing so. Section 1.0 introduces the study scope and analysis approaches used. Discussions regarding the number of buildings in the U.S that comprise “small-size” and “medium-size” buildings, their lack of building automation systems (BAS) and potential energy improvements, as well as challenges, are detailed in this section.
Section 2.0 covers the characterization of both small- and medium-sized buildings. Drawing upon Energy Information Administration’s Commercial Building Energy Consumption Survey data from various surveys, detailed discussions of energy end-use and electrical end-use consumption values are provided. This section spring boards into further discussions for the various end-use loads and the present penetration of “intelligent” controls in the existing market. Discussions of existing and possible future control methods, strategies and concepts that are applicable (including heating, ventilation and air conditioning (HVAC); lighting and miscellaneous end-use loads) complete this section.
Section 3.0 discusses the different communication architectures that might be found in a small- or medium-sized building BAS, as it relates to the communication networks needed to support them. This discussion covers the different technologies that have been in place (older) or are becoming more prevalent (newer), and how they work. This includes wired solutions, wireless solutions or a combination of both (hybrid wired-wireless) networks and industry standards, open and proprietary protocols. For each solution, the limitations of each technology are detailed (speed, bandwidth, reliability, etc.). Cost factors are also discussed because this relates to how these systems are being pushed to the market, and their acceptance (or lack of).
Section 4.0 describes the BAS, as has historically been seen and known in large building applications and the small- or medium-sized building applications. This section describes the history of BASs and how they have evolved and improved over time, and summarizes their core functions. This description proceeds to discuss the major architectural requirements needed by new BASs to allow for greater penetration in the existing building stock in the U.S. This section concludes by providing three different options of what a future BAS configuration might look like for either a small-sized building (two different options) or for a medium-sized building (one option).
Section 5.0 presents the requirements and capabilities of various devices used to monitor and control different end-use loads found in small- and medium-sized buildings. This includes a robust presentation of the different requirements for the gateway, master controller, communicating thermostats, general purpose controller and the lighting controller. Typical requirements include schedule configuration capabilities, alarm configuration capabilities, set point configuration capabilities, security, communications capabilities and a whole host of other capabilities – many of which are unique to each different device and designed function(s). The expectation is that these different devices will also have “demand response” capabilities. Those capabilities are presented as well and vary from device to device.
iv
This section concludes by discussing data collection, archiving requirements and grid integration requirements. Potential models and strategies that could be implemented (at the device controller, at the master/gateway controller or external from the building) are also discussed.
Section 6.0 presents potential installed costs of a BAS for small- and medium-sized buildings. This discussion estimates annual energy and cost savings for different energy saving rates and different energy costs (therefore, what a proposed BAS project would cost for simple payback rates).
Section 7.0 covers a case study of a controls retrofit upgrade of an actual 20,000 sf medium-sized commercial building in Richland, WA. The case study details the existing controls and their capabilities and what was done to the existing controls to provide a BAS with many of the capabilities previously described (including wired/wireless technologies, capabilities used that did not exist before, costs to upgrade, and the energy and cost savings after the upgrade was completed.
Section 8.0 provides a brief summary of the report, discussion of what is needed and recommendations on what to do next. The report also contains seven appendices (Appendix A – Appendix G) that provide more details on many of the same topics covered in the main report, including three use cases for BASs in small- and medium-sized buildings.
v
Executive Summary
Buildings consume over 40% of the total energy consumption in the U.S. A significant portion of the energy consumed in buildings is wasted because of the lack of controls or the inability to use existing building automation systems (BASs) properly. Much of the waste occurs because of our inability to manage and control buildings efficiently. Over 90% of the buildings are either small-sized (<5,000 sf) or medium-sized (between 5,000 sf and 50,000 sf); these buildings currently do not use BASs to monitor and control their building systems from a central location. According to Commercial Building Energy Consumption Survey (CBECS), about 10% of the buildings in the U.S. use BASs or central controls to manage their building system operations. Buildings that use BASs are typically large (>100,000 sf). Lawrence Berkeley National Laboratory (LBNL), Oak Ridge National Laboratory (ORNL) and Pacific Northwest National Laboratory (PNNL) were asked by the U.S. Department of Energy’s (DOE’s) Building Technologies Program (BTP) to identify monitoring and control needs for small- and medium-sized commercial buildings and recommend possible solutions. This study documents the needs and solutions for small- and medium-sized buildings. The scope of this study is to characterize the monitoring and controls (for both energy efficiency and demand response) needs for the various end uses, development of requirements to develop control packages and the target cost of doing so. The focus areas of the study are:
1) characterize the small- and medium-sized building population
2) identify the building automation system needs (end uses and systems to be controlled) for small- and medium-sized buildings
3) identify basic control capabilities to address the needs identified above
4) characterize existing industry trends and control standards that could enable the development of an open controls platform
5) identify the architectural needs for next-generation control systems to assist buildings to (1) save energy by “optimal” control of building sub-systems, and (2) manage and control building sub-systems to provide seamless integration of buildings to the electric grid
6) identify optimal control schemes applicable for small- and medium- sized buildings including model-predictive controls, cooperative control, and optimal distributed controls
7) characterize existing building to grid research, emerging smart grid standards related to buildings and demand response automation
8) characterize trends and emerging technologies related to underlying data collection and storage to facilitate remote monitoring and “optimal” control to ensure proper and persistent operations
9) develop a case study to show that building controls for small- and medium- sized buildings can be cost effective
10) estimate target installed cost of monitoring and controls infrastructure.
vi
Characterization of Small- and Medium-Sized Commercial Buildings CBECS data shows there is significant diversity in the end uses in buildings that are less than 50,000 sf. Therefore, it was necessary to see which building types have similar end-uses patterns. Based on the review of consumption patterns of the 20 different building types, only the following building types were considered for more detailed characterization analysis: office, education, retail (includes strip mall, enclosed malls, retail other than mall), outpatient, religious worship and services. The primary reason for limiting the analysis to these buildings types is because the energy consumption in these building types is mostly from heating, ventilation and air conditioning (HVAC); lighting; and miscellaneous plug loads. The subset of building types selected also use similar HVAC equipment (air conditioner or heat pumps for cooling and heat pumps or furnaces for heating), which are typically controlled by a thermostat. Some of the other building types that were excluded use a significant refrigeration load (food sales, food service and refrigerated warehouses). A detailed characterization of disaggregated end-use consumption in the subset of the commercial buildings for two different sizes (small and medium) of interest indicated no significant difference. Although there are some minor differences, heating consumption is the dominant end use, followed by lighting, plug loads and cooling. Over half (55%) of the energy consumption in buildings less than 50,000 sf is from HVAC equipment. HVAC, lighting and plug loads account for almost 90% of all consumption for this category of buildings. HVAC and lighting consume over 71% of the electricity consumption for this category of buildings, while the rest of the electricity consumption is from plug loads, water heating and refrigeration. Therefore, the monitoring and control needs for these buildings will be primarily focused for HVAC, lighting and miscellaneous plug loads. The objectives of HVAC controls are to provide thermal conditioning and ventilation services, while minimizing maintenance and operating costs. On one end of the spectrum are simple thermostats that are similar to many home HVAC controls. On the other end, there are more sophisticated systems that can offer a range of functionality to minimize energy costs, provide energy cost feedback, and provide remote monitoring for control and security. Many new Internet-protocol-based controls provide the ability to integrate the building with the grid to make the building more demand responsive (DR). Although BASs are the preferred way to implement many energy efficiency and DR strategies in buildings because they allow for automatic programming strategies, the penetration rate of these systems into small commercial buildings is low because they are perceived as expensive and because the building owners are not fully aware of the benefits. A large portion of the current controls in small- and medium-sized buildings are set point based or rule-based controls. Typically there is a programmable logic controller with a predefined control scheme that is executed based on the sensor data. This class of control system is designed around the difference between a reference input (i.e., temperature, pressure, etc.) and some function of the controlled variable (typically a set point value) used to calculate an error of the controlled variable from set point, which results in supplying an actuating signal to the control elements and controlled system. Recently there is a great deal of activity related to communicating and learning thermostats. For example, there are commercially available thermostats that are compatible with most packaged and use industry-standard connections to facilitate the control of these HVAC systems. Some thermostats are programmable with learning algorithms to optimize the start and stop times of the HVAC system in a building. Many of the recent advanced thermostats can be connected to the Internet, allowing for remote control, energy usage histories and schedules. These advance features also allow for some advanced control concepts like model-predictive and optimal control and agent-based or learning-based controls. However, even the most sophisticated thermostats are very rarely integrated into a single network allowing for managing and monitoring from a central location. Therefore, most of the advanced features of these devices are rarely used in practice.
vii
Automated lighting control systems range from simple scheduling, to sensor-based systems that actuate electric lights according to occupancy or ambient light levels; they may incorporate a variety of occupant personal control options. Dimmable ballasts, lumen maintenance, daylighting, and set point tuning, are also possible. Networked control solutions may be capable of providing grid-integrated demand response, “optimize” HVAC controls and remote monitoring and control. Although there are no published sources, anecdotal evidence shows that lights in small buildings are generally not automatically controlled. Therefore, increasing the penetration of lighting controls in small- and medium-sized commercial buildings presents great energy saving opportunities. Commercial miscellaneous and electronic loads (CMELs) are a large and growing end use, but few data exist to identify which specific devices consume most of the energy and which control/savings strategies would be most effective. CMELs are diverse and vary by building type, but research shows that some CMELs are more amenable to controls both for energy efficiency and/or demand response. Strategies for controls should include scheduling, occupancy-based controls, and grid responsiveness, including: control of Personal computers (PCs) in office environments and occupancy-based control of non-essential loads in office and non-office environments.
Communication Architectures Traditionally BASs have relied on wired communication networks to monitor and control various end-use devices and loads. However, in the past decade, wireless solutions have gained popularity, especially for retrofit or existing building market. Some buildings, including new buildings, are deploying hybrid solutions that include wired and wireless control networks in a building. Each option has its own benefits; while the wired networks are considered reliable, deployment cost could be high, especially in existing buildings. There is wide variety of wireless networks that can be used to deploy wireless controls in small- and medium-sized buildings. The key metrics to identify the proper wireless networks for building monitoring and control applications include: low-data rate, long battery life, low-cost of deployment and operation, unlicensed frequency of operation, co-existence with existing building wireless networks, interference resistant and secure network operation. Standards exist for current deployment of wireless sensors in the buildings. IEEE 802.11 (Institute of Electrical and Electronics Engineers), IEEE 802.15 and ISA 100 (International Society of Automation) are the two major families of ANSI (American National Standards Institute) standards. These standards are currently available and/or are under development. Corresponding to industry standards, best practice methodologies have evolved along with the ISA and IEEE standards. All of the standards utilize unlicensed bands in the spectrum. The standards are designed to be scalable for 5 to 30 years with a backward compatibility with previous standards. A building deployment might include multiple standards; for example, sensors will communicate using low-power (battery-powered), low-cost (maximum number of sensor points), and low-data rate. A building-wide backbone network might include a high data rate (to transfer 100s or 1000s of sensor data), over a plug powered network.
Building Automation System BASs are used in large commercial buildings to monitor and control various building systems, including, heating, ventilation and air condition (HVAC) and lighting, primarily in large buildings. BASs are sometimes also referred to as energy management systems (EMS) or energy management and control systems (EMCS) or direct digital control (DDC) systems. BAS consists of a set of hardware and software
viii
integrated into a single architecture to monitor and control buildings’ HVAC systems. BAS may also include control or monitoring of lighting, security, and fire systems in the building. Although BASs have been around for over 3 decades, only 10% of the commercial building stock has those. Buildings that use BASs are typically large (>100,000 sf), while the rest of the building stock uses rudimentary controls. The rudimentary controls are mostly manual, with limited scheduling capability, no monitoring or failure management. Therefore, most of these buildings are operated inefficiently and waste energy. There are a number of reasons why these buildings do not deploy BASs: 1) lack of awareness, 2) lack of inexpensive packaged solutions and 3) sometimes the owner is not the tenant, so has no incentive to invest in a BAS. The key architectural requirement for the BASs are: 1) interoperability, 2) scalability, 3) deployment, 4) open, 5) plug-n-play and 6) enable local or remote monitoring. A single configuration of BAS many not serve the needs of the diverse small- and medium-sized buildings. Therefore, you need a different package of solutions. However, each of these solutions must be based on open protocols and standards-based controls that can be scaled. For small-sized buildings, HVAC and lighting energy constitute over 50% of the energy consumption and also over 50% of the electricity consumption. In many small buildings, it may not be possible to cost effectively control the lighting loads using a central controller. Therefore, a simple control solution for small buildings could consist primarily of programmable thermostats that are connected to HVAC devices (primarily rooftop units) and may also include controllers for small miscellaneous loads (plug loads, small exhaust fans). This configuration also should have a central coordinating device (supervisory) or gateway controller. The communication between the controller and gateway can either be wired or wireless. Again, in most existing buildings, a wired solution may not be cost effective, so a wireless solution is needed. For new construction, a wired option may be a cost effective solution. While improving the energy efficiency of the building, this controls solution can also be leveraged to make the building and its systems more grid responsive. The control of lighting loads may be achieved with local independent occupancy sensors; less commonly in small buildings, standalone contactor timer systems or lighting automation panels may be used for schedule-based on-off control. Control functions are distributed primarily amongst the programmable controllers (thermostats and small load controllers). There may be some “global” functions embedded in a central coordinating device/gateway. These functions may include (but are not necessarily limited to) things like alarm management (alarm monitoring and alarm notification), data management (trending, storage and retrieval), and communication with external sources. An alternate BAS option for small buildings is one that supports distributed local controls at the device level and Cloud-based remote monitoring and configuration. This approach will allow for “simple” remote configuration and consists primarily of general purpose controllers that are located at and connected to the HVAC devices (primarily rooftop units) and possibly lighting devices or end-use loads. This configuration also allows for communicating programmable thermostats to control the HVAC devices instead of the general purpose controllers. The configuration can also include controllers for small miscellaneous loads (plug loads and exhaust fans). Temperature sensors connected to the general purpose controllers are located in designated occupied spaces in the building (office or open area). The small load controller may be connected to plug load devices. These plug loads may be located in the spaces (outlets or electrical distribution panels) that are primarily for lighting or special process loads (like hot water tanks, hot water pumps or lighting loads), or they may be up in ceiling spaces or on roofs (primarily for exhaust fans or lighting fixtures). As in the previous option, the control of lighting loads may be achieved with local independent occupancy sensors; less commonly in small buildings, standalone contactor timer systems or lighting automation panels may be used for schedule-based on-off control. While improving the energy efficiency of the building, this solution can also be leveraged to make the building and its systems more grid responsive.
ix
The total energy consumption of a medium-sized commercial building is typically higher than a small commercial building. So, the BAS solution for these buildings can be a slightly more sophisticated and higher cost solution than the small building solution. However, the building automation solutions discussed previously for small-sized buildings can also be scaled to work with medium-sized buildings. The proposed solution for the medium-sized building will work in both existing and new buildings. While improving the energy efficiency of the building, this solution can also be leveraged to make the building and its systems more grid responsive. In this configuration, the building will have a central master controller that coordinates a number of specific device controllers in the building. The medium-sized building configuration consists primarily of general purpose controllers that are located at and connected to the HVAC and lighting systems. They can also include controllers for small miscellaneous loads (plug loads, small exhaust fans, hot water tanks, pumps, etc.). Temperature sensors connected to the general purpose controllers are located in designated occupied spaces in the building (office or open area). The lighting controller may be the same general purpose controller or a dedicated lighting controller (or a hybrid). The small load controller may be connected to plug load devices. These plug loads may be located in the spaces (outlets or electrical distribution panels) that are primarily for special process loads (like domestic hot water tanks, domestic hot water pumps or lighting loads), or they may be up in ceiling spaces or on roofs (primarily for exhaust fans or lighting fixtures). The communication between individual controllers and the master controller and between sensors and controllers can be wired or wireless. Individual controllers do not need to communicate with the Cloud service directly. Access to external information in the controllers is primarily through the master controller. Monitoring can either be via local or remote monitoring (web page, Internet connection – wired or wirelessly). Local monitoring, configuration and analysis (data and alarm management) is the recommended option for medium-sized buildings. Monitoring capabilities greatly assist in ensuring persistence and sustainability of energy savings and proper, efficient equipment operations. This assurance comes primarily from reliable alarm, data management and actionable intelligence creation capabilities.
Requirements of the Devices Used to Monitor and Control It is important to identify the requirements and capabilities of various devices used to monitor and control different end-use loads described previously for small- and medium-sized buildings. This includes different requirements for the gateway, master controller, communicating thermostats, general purpose controller and the lighting controller. Typical requirements include schedule configuration capabilities, alarm configuration capabilities, set point configuration capabilities, security, communications capabilities and a whole host of other capabilities – many of which are unique to the different device and designed function(s). The expectation is that these different devices will also have “grid response” capabilities, which include requirements for demand response, ancillary services and regulation service for HVAC loads, lighting load and other end uses. To ensure persistence of operation, the controls infrastructure should provide easy access to the sensor data. In addition to easy access to the data, there is also a need to standardize data collection, analysis and archiving of the data. There are number of ways the data can be aggregated and presented to the user. The most basic approach is to simply combine multiple measurements into a summary format and present it to the user. In this approach the user is then responsible to create actionable information from the data. This approach is probably not ideal because many users generally do not have the time or expertize to create actionable information. The ideal solution would be to aggregate the data from various sensors and have applications create actionable information that is presented to the user.
x
The requirements to make the building more grid responsive will require that the buildings to be capable of receiving a signal from the utility indicating a DR event automatically; able to characterize the magnitude of change in demand as a result of responding to the DR signal; reliable, with a means of verifying operation through low cost, non-intrusive means, capable of delivering significant load reductions; cost effective (economical); and non-disruptive during operation and minimally disruptive during installation.
Installed Cost of the Control Systems for Small- and Medium- Sized Buildings Because much of the buildings industry is driven by first cost, an estimate of the installed cost of building controls and the annual cost saving benefits associated with them will be needed to convince building owners and operators. However, estimating the installed cost of the control system on a typical building would require making a number of assumptions on the size and type of building, number of HVAC systems and other controllable loads, etc. An alternate approach is to assume the annual energy savings attributed to building controls and then estimate the annual cost savings. Using the annual cost savings and assuming a typical simple payback (e.g., 3 years), the total installed cost of building controls that the building owner can afford can be estimated. Because the cost of controls varies by the size of the building, the estimated installed cost can be normalized by area. Also, because the energy (electricity and natural gas) cost varies by region, the estimated cost of controls is for a range of energy costs. For example, if EUI (energy use index) of a building is 100 kBtu/sf/yr, the electricity price is 0.1 $/kWh, natural gas price is $5/MMBtu and the anticipated savings for use of building controls is 10%, the annual normalized energy cost savings are approximately 0.2 $/sf. Under these assumptions, for a 10,000-sf building, the total annual savings will be approximately $2,000. If the building owner is looking for a 3-year simple payback, the owner could afford to invest $6,000 to install controls without any utility incentives. If the utilities provide incentives through their demand side management programs, the installed cost can be higher and still have a 3-year payback. Likewise on the high end, if EUI of a building is 100 kBtu/sf/yr, the electricity price is 0.2 $/kWh, natural gas price is $10/MMBtu and the anticipated savings for use of building controls is 30%, the annual normalized energy cost savings are approximately 1.09 $/sf. Under these assumptions, for a 20,000-sf building, the total annual savings will be approximately $21,800. If the building owner is looking for a 5-year simple payback, the owner could afford to invest $109,000 to install controls without utility incentives.
Control Retrofit of a Medium-Sized Commercial Building: Case Study In many cases, retrofitting an existing building or implementing building controls in small- and medium-sized commercial buildings will be a cost-effective solution. However, many building owners, managers and operators are not aware of the economics and benefits of such an implementation. A case study of a building’s control retrofit completed in 2010 provides some insights into the costs and benefits of installing building controls in a 20,500-sf medium-sized building. Before the controls where upgraded in the building, it had 11 rooftop units controlled by programmable thermostats with limited remote hardwire temperature sensor averaging, no holiday scheduling or optimal start sequencing, no networking capabilities, no remote diagnostic, alarming or trending capabilities. Schedules for each rooftop unit in the thermostat were generally set to start too early (between 3 a.m. and 5 a.m.) and were generally shutting off too late (between 7 p.m. and 9 p.m.). Weekend scheduling was configured for 4 to 8 hours. The building was retrofitted with a building automation system in 2010. The major features of the upgrade include: the thermostats on all rooftop units (RTUs) were replaced with new programmable thermostats that communicated with a BAS head-end; a wireless temperature sensor monitoring network
xi
was created and installed throughout the building to cover 50% of the office spaces; a communications network was established to share common data points like outside air temperature, occupancy and holiday scheduling, data analysis of the different RTU’s performance via trend logs, historical data and alarming; and a whole building electrical meter was installed and integrated with BAS for data collection. The network controller (master controller) was programmed to enable the following features: holiday scheduling added (Eight holidays/year); optimal start capability added; schedules for the RTUs were tightened, the RTUs were completely off on weekends; during early morning start-up, the heat pumps serving perimeter zones were activated first to attempt to hold the core of the building at temperature thresholds to mitigate excessive heating or cooling loads on all heat pumps; automatic night low and high limits maintain spaces no lower than 64oF and no higher than 82oF; automatic outside air low temperature override added; when the outdoor-air temperature falls below 25oF, the rooftop units run continuously; removed the weekend scheduling with the above noted improvements; and remote push button thermostat occupancy override input allows for after-hours occupancy (night/weekends) if required. This alleviates adding or modifying schedules (“just in case” or for one time or unplanned events); the override feature also provided a means to obtain occupancy if the BAS network controller fails or experiences a communication failure; and created 4oF range between heating and cooling (previously the range was 2oF), driven by a master set point. The cost of the controls upgrades for both hardware and labor cost is: new
• communicating thermostats ($250 each x 10 thermostats) = $3K; • new wireless sensors ($50 each x 60 sensors) = $3K; • new wireless sensor integrator with repeater (1) = $1K; • network infrastructure (hub/switch, network controller, network integration, cabling) = $6K; • labor (design/engineering, install new thermostats, network infrastructure) = $7K.
The total installed cost for the controls upgrade for the building is approximately $20K. Using the electricity interval data, energy use between the pre- and post-upgrade periods was compared and savings estimated. Modeling included development of segmented linear regression models (five parameter models) for two periods: weekdays and weekends. Using the 2009 data, pre-BAS upgrade models were developed; similarly using 2011 data, post-BAS upgrade models were developed. Using the models, savings estimates were for the entire year using historical typical meteorological year (TMY) data. The energy savings is roughly 22%. As can be seen, the normalized cost savings per year is approximately $5,000/yr, which leads to a 4-year simple payback. Even when the utility rates are low (less than 0.05 $/kWh), compared to the most of the U.S., the paybacks appear to be reasonable (less than 5 years). So, for other locations where the utility rates are significantly higher ($0.15/kWh to $.20/kWh), the payback periods are going to significantly lower as well (less than 3 years). The management team that deals with occupant complaints saw a dramatic decline in comfort-related complaints, after the upgrades were completed. This fact (improved occupant comfort) is a testimony to the benefit of upgrading a building to a BAS with the capabilities noted. More small building owners should be looking at the long-term benefits of a BAS upgrade that includes existing technologies such as wireless sensing, remote accessibility and programmable thermostats or controllers at the rooftop unit equipment that can take advantage of global functions that include creative scheduling of occupancy and holiday events and integrating other data such as outdoor temperature sensor values and wireless temperature sensor values and power meter data/demand response data.
xii
Discussion and Recommendations
The fundamental building blocks necessary to develop a cost-effective controls solution for small- and medium-sized commercial buildings exist. These building blocks have to be packaged in such a way that it is cost-effective, open and standard, and truly “plug-n-play.” If the solutions is not cost effective, i.e., reasonable payback (less than 3 years), it may not find widespread acceptance. Initially, utilities can provide incentives to create a market for these solutions and over time, as the size of market increases, the cost of the solutions will drop. One way to lower the cost of the solution is to develop a controls architecture that is truly open, standard and plug-n-play. This approach will allow a number of vendors to develop components, products or services to compete for the same end goal.
Ideally, as noted above, the controls architecture or solutions for small- and medium-sized commercial buildings should be open, standard and truly plug-n-play. However, “plug-n-play” is a loosely used, catchy phrase that means different things to different people. This phrase is commonly used to describe components or devices that work as soon as they are connected to the personal computer system. The user does not have to manually install device drivers or indicate that a new device has been connected. For example, if a plug-n-play external USB (universal serial bus) hard drive is connected to the computer, the device will begin to work within a few seconds of being plugged. A non-plug-n-play device, on the other hand, will require going through several steps of installing drivers and setting up other configuration parameters manually before it can be used. Much of the building control devices are non-plug-n-play. For controllers or control components to be truly plug-n-play, an open industry standard is needed. Many of the building control components or unitary controllers used to control building systems that are designed to do a specific job can be made truly plug-n-play.
Although there are two standard building control protocols (BACnet and LonMark), neither of these protocols is truly “plug-n-play.” Every controller has to be configured manually to some extent to be able to seamlessly integrate with the rest of the enterprise-wide controls. These protocols only guarantee that certain minimum compliance specifications, as required by the respective standards, are met. In the case of BACnet, these specifications are developed openly through the ASHRAE standards process, which sometimes can take a long time to reach consensus. The LonMark products also have a standard, but it is developed by the members of the LonMark association. Lack of truly open, standard and plug-n-play controls leads to:
• Higher consumer costs are incurred by the customer along with higher consumer frustrations
• Sustainability and good stewardship is no longer achievable
• Consumers are driven to be “locked-in” to one vendor solution
• Control vendors have no incentive to change for fear of losing market share
• Many control vendors have found the service market to be more lucrative
Even if the building has central controls, without the ability to monitor both the controls and end-use consumption, the persistence of the efficient operations is not ensured. So, the control solution should provide ways to enable easy access of sensor values and control parameters to third party software solutions. In addition, the controls solution should also have the ability to integrate the information from
xiii
the so-called “smart” utility meters. Because energy accounts for a significant portion of the operating cost in many facilities, facility managers, energy service providers, and owners alike will benefit from software tools that track energy end-use. In addition to the ability to track and forecast energy use at the building and end-use level, interoperable access to control system and facility energy data is necessary to a) support more pervasive use of advanced energy-focused analytics in small-to-medium buildings, and therefore, b) enable next generation of energy- and price- aware grid-integrated buildings. When accommodated within a cost-effective plug-n-play controls infrastructure, continuous diagnostics, determination and execution of optimal control strategies, and transactive responsiveness become possible, even for small- and medium-sized buildings.
A significant percentage of the small- and medium-sized buildings lack centralized controls and monitoring, leading to significant waste of energy and higher energy cost. It is not because of availability of technology that these buildings lack proper infrastructure. The lack of awareness, lack of cost-effective packaged solutions that are easy to implement and lack of open, standard and plug-n-play controls are the primary causes for the current state of these buildings. There are other policy issues that will need to be addressed to change the status quo, including split incentives, where the owner is not paying for the energy consumed in the building and therefore, has no incentive to upgrade the controls infrastructure. One policy recommendation for DOE to consider is mandating certain minimum controls infrastructure for all commercial buildings by updating the current codes. Even though in most cases upgrading the monitoring and controls infrastructure will payback in less than 3 years, many building owners will have difficulty raising the capital required for such an upgrade. Another policy recommendation would be to create easy financing options for these retrofit projects.
On the technology front, it is recommend that DOE encourage controls vendors to develop open, standard and plug-n-play controls suitable for small- and medium-sized buildings. These technology solutions must be suitable for easy implementation in existing buildings as well as new buildings. A single solution may not be suitable for all building types and sizes, so DOE should encourage vendors to develop open, standard and plug-n-play solutions that can scale and that meet minimum common functionality in the small- and medium-sized buildings portfolio. Because many of the small- and medium-sized buildings have rooftop units, the initial focus should be to develop plug-n-play controls infrastructure for connectivity between the rooftop equipment and controllers.
xv
Acknowledgments
The authors would like to acknowledge the Buildings Technologies Program of the U.S. Department of Energy, Office of Energy Efficiency and Renewable Energy for supporting the research and development effort. This work was supported by the Assistant Secretary for Energy Efficiency and Renewable Energy, Office of Building Technology, of the U.S. Department of Energy under Contract No. DE-AC02-05CH11231 (LBNL), DE-AC05-00OR22725 (ORNL) and DE-AC05-7RL01830 (PNNL)
The authors would also like to thank Alexis Abramson, Technology Development Manager, and George Hernandez for providing technical guidance, Sue Arey for editorial support and Lorena Ruiz for help in preparing this document.
xvii
Acronyms and Abbreviations
ADR Automatic demand response AHU Air handling unit ASHRAE American Society of Heating, Refrigeration and Air Conditioning
Engineers BAN Building automation network BAS Building automation system CAISO California independent system operator CBECS Commercial building energy consumption survey CDMA Code division multiple access CLIR Client logic with integrated relay CMEL Commercial miscellaneous and electronic loads CPUC California public utilities commission CSMA Carrier sense multiple access DCV Demand controlled ventilation DDC Direct digital control DRRC Demand Response Research Center DR Demand response DRAS Demand response automation server DSL Digital subscriber lines DSOM Decision Support of Operations and Maintenance ECAM Energy charting and metrics EE Energy efficiency EIA Energy information administration EIS Energy information system EMCS Energy management and control systems EMS Energy management systems EPA Environmental Protection Agency EUI Energy use intensity FDD Fault detection diagnosis FDMA Frequency division multiple access FLC Fuzzy logic controller GA Genetic algorithms HART Highway addressable remote transducer IP Internet protocol ISA International Society for Automation ISO Independent system operator
xviii
LAN Local area network LBNL Lawrence Berkeley National Laboratory LMS Least mean square LQR Linear quadratic regulator M&V Measurement and verification MAC Medium access control MIMO Multiple input multiple output MODBUS A serial communication protocol developed by Modicon MPC Model-based predictive control NC Network controller NRE Non-recurring engineering OpenADR Open automated demand response OS Operating system OSI Open systems interconnection PG&E Pacific Gas and Electric PI Proportional integral PID Proportional integral derivative PL Participating loads PLC Power line carrier PLP Participating load pilot REHVA Federation of European Heating, Ventilation and Air Conditioning
Associations RTU Roof top units SISO Single input single output TDMA Time division multiple access TMY Typical meteorological year USB Universal serial bus VFD Variable frequency drive WSN Wireless sensor networks
xix
Contents
Abstract ............................................................................................................................................. iii Executive Summary ............................................................................................................................ v
Characterization of Small- and Medium-Sized Commercial Buildings .................................... vi Communication Architectures ..................................................................................................vii Building Automation System ...................................................................................................vii Requirements of the Devices Used to Monitor and Control ...................................................... ix Installed Cost of the Control Systems for Small- and Medium- Sized Buildings ...................... x Control Retrofit of a Medium-Sized Commercial Building: Case Study ................................... x Discussion and Recommendations ...........................................................................................xii
Acknowledgments ............................................................................................................................. xv Acronyms and Abbreviations .........................................................................................................xvii 1.0 Introduction ................................................................................................................................ 1
1.1 Study Scope and Approach ................................................................................................ 2 1.2 Report Organization ........................................................................................................... 3
2.0 Characterization of Small- and Medium-Sized Commercial Buildings ..................................... 4 2.1 Selection of Building Types and Sizes ............................................................................... 4 2.2 Summary of Building Characterization .............................................................................. 4 2.3 HVAC End-Use Controls Characterization ....................................................................... 6
2.3.1 Set Point and Rule-Based Control ........................................................................... 7 2.4 Lighting End-Use Controls Characterization ..................................................................... 8 2.5 Miscellaneous End-Use Load Controls Characterization................................................... 9 2.6 Advanced HVAC Control Concepts ................................................................................ 12
2.6.1 Model-Predictive and Optimal Control ................................................................. 15 2.6.2 Agent-Based or Learning-based Controls ............................................................. 16
2.7 Control and Load Variability – Optimization, Electric Load ........................................... 16 3.0 Communication Architectures .................................................................................................. 19
3.1 Wired Network ................................................................................................................. 19 3.2 Wireless Network ............................................................................................................. 21 3.3 Hybrid Wired-Wireless Networks .................................................................................... 24
4.0 Building Automation Systems .................................................................................................. 26 4.1 Architectural Needs for BASs .......................................................................................... 26 4.2 BASs for a Small Commercial Building .......................................................................... 28
4.2.1 Small building, simple local configuration option #1 ........................................... 28 4.2.2 Small building, simple remote configuration option #2 ........................................ 31
4.3 BASs for Medium-Sized Commercial Building .............................................................. 33 5.0 Requirements of the Devices Used to Monitor and Control Small-and Medium-Sized
Commercial Buildings .............................................................................................................. 36
xx
5.1 Gateway Requirements .................................................................................................... 36 5.2 Master Controller Requirements ...................................................................................... 36 5.3 Communication Thermostat Requirements ...................................................................... 37 5.4 Lighting Controller Requirements ................................................................................... 39 5.5 General Purpose Controller Requirements ....................................................................... 40 5.6 DR and Ancillary Service Requirements of HVAC Loads .............................................. 40 5.7 DR and Ancillary Service Requirements of Lighting Loads ............................................ 41 5.8 DR and Ancillary Service Requirements of Other End-Uses .......................................... 41 5.9 Data Collection and Archiving Requirements .................................................................. 41 5.10 Grid Integration Requirements ......................................................................................... 44
6.0 Installed Cost of the Control Systems for Small- and Medium- Sized Commercial Buildings 48 7.0 Control Retrofit of a Medium-Sized Commercial Building: Case Study ................................. 50
7.1 Summary of the Building Description.............................................................................. 50 7.2 Cost of Controls Upgrade ................................................................................................. 52 7.3 Energy and Cost Savings from Controls Upgrade ........................................................... 53 7.4 Case Study Conclusions ................................................................................................... 54
8.0 Summary Discussion and Recommendations ........................................................................... 55 8.1 Summary .......................................................................................................................... 55 8.2 Discussion ........................................................................................................................ 56 8.3 Recommendations ............................................................................................................ 61
9.0 References ................................................................................................................................ 63 Appendix A .....................................................................................................................................A-1 Appendix B ..................................................................................................................................... B-1 Appendix C ..................................................................................................................................... C-1 Appendix D .....................................................................................................................................D-1 Appendix E ..................................................................................................................................... E-1 Appendix F...................................................................................................................................... F-1 Appendix G .....................................................................................................................................G-1
xxi
Figures
Figure 1: Distribution of U.S Electricity, Energy, and Green House Gases (ASHRAE 2012) .......... 1 Figure 2: Disaggregation of Energy End-Use Consumption in the Subset of Commercial
Buildings that are 50,000 sf or less ............................................................................................. 5 Figure 3: Disaggregation of Electricity End-Use Consumption in the Subset of Commercial
Buildings 50,000 sf or less .......................................................................................................... 6 Figure 4: PID Controller ..................................................................................................................... 8 Figure 5: Annual Energy Use of Commercial Building Types Showing Fraction that is CMELs
Energy Use (adapted from McKenny et al. 2010) .................................................................... 10 Figure 6: Breakdown of CMELs Energy Use by Category for all Commercial Building Types
(Building Energy Data Book 2011). ......................................................................................... 11 Figure 7: Model-Predictive Control of Building HVAC System ...................................................... 16 Figure 8: PLP Architecture ............................................................................................................... 18 Figure 9: Typical architecture of a BAN .......................................................................................... 19 Figure 10: Example of Cascaded Devices using N2 Serial Bus ....................................................... 20 Figure 11: Wireless Landscape ......................................................................................................... 21 Figure 12: Wireless Interconnection Topologies: (A) Star, (B) Partial Mesh, (C) Another Partial
Mesh (D) Fully Connected Mesh .............................................................................................. 22 Figure 13: Demonstration of Link-Level Interoperability ................................................................ 24 Figure 14: Demonstration of a Link- and Application-Level Interoperability .................................. 25 Figure 15: Simple BASs with Local Configuration Option for Small Buildings ............................. 29 Figure 16: Simple BASs with Local Controls but Remote Configuration Option for Small
Buildings ................................................................................................................................... 32 Figure 17: BASs with Local Control and Configuration and Local or Remote Monitoring for
Medium-Sized Buildings .......................................................................................................... 34 Figure 18: Examples of Data Aggregation ....................................................................................... 42 Figure 19: Architecture for a Full Data Aggregator System ............................................................. 43 Figure 20: DR Strategy in Load Controller ...................................................................................... 45 Figure 21: DR Strategy in BAS (or EMCS) ..................................................................................... 45 Figure 22: DR Strategy External to the Facility................................................................................ 45 Figure 23: Annual Normalized Cost Savings as a Function of EUIs for Various Electricity Prices
Assuming 10% Reduction in Energy and $5/MMBtu .............................................................. 49 Figure 24: Annual Normalized Cost Savings as a Function of EUIs for Various Electricity Prices
Assuming 30% Reduction in Energy and $10/MMBtu ............................................................ 49 Figure A - 1: Disaggregation of Energy End-Use Consumption in the Subset of Commercial
Buildings 5,000 sf or Less ......................................................................................................A-2 Figure A - 2: Disaggregation of Electricity End-Use Consumption in the Subset of Commercial
Buildings 5,000 sf or Less ......................................................................................................A-2
xxii
Figure A - 3: Disaggregation of Energy End-Use Consumption in the Subset of Commercial Buildings in the Size range Between 5,001 sf and 50,000 sf ..................................................A-3
Figure A - 4: : Disaggregation of Electricity End-Use Consumption in the Subset of Commercial Buildings in the Size range Between 5,001 sf and 50,000 sf ..................................................A-3
Figure B - 1: General Architecture of a Contractor-Timer System for Scheduled Lighting Control
Lighting automation panels, lighting control panels, relay panels.......................................... B-2 Figure B - 2: General Architecture of a Lighting Automation Panel for Scheduled Lighting
Control .................................................................................................................................... B-3 Figure B - 3: General Architecture of a Lighting Control System, Capable of Direct Ballast
Control for Advanced Strategies, and Panel-based Control ................................................... B-4 Figure C - 1: OSI model for a network stack, showing the name and number of each layer along
with information about what happens at each layer7 [ISO/IEC 1994] .................................... C-8 Figure D - 1: The Picture shows Building 4 the other 3 Buildings surround this Building ............D-3 Figure D - 2: Photograph of Old and New Thermostats in Building 4 Before and After They Were
Replaced..................................................................................................................................D-5 Figure D - 3: 4-Year Performance Chart for Building 4 .................................................................D-9 Figure D - 4: Weekday Load Profiles for Building 4 Before, During, and After BAS Upgrades D-10 Figure D - 5: Weekend/Holiday Load Profiles for Building 4 Before, During, and After BAS
Upgrades ............................................................................................................................... D-10 Figure D - 6: Whole Building Electricity Consumption vs. Outdoor Air Temperature for
Occupied and Unoccupied Periods (a) 2009 (pre) and (b) 2011 (post) for Building 4 ......... D-12 Figure D - 7: Boxplot for Average Load Profile for Weekdays (a) and Weekends (b) Pre-
Upgrade, as Compared to Weekdays (c) and Weekends (d) Post-Upgrade for Building 4 .. D-13 Figure D - 8: Segmented Linear Regression Models for Building 4 for Weekdays and Weekends
Pre- and Post-BAS Upgrades: (a) Weekday Pre-Upgrades (b) Weekday Post-Upgrades (c) Weekends Pre-Upgrades (d) Weekends Post-Upgrades ....................................................... D-14
Figure E - 1: Schematic of a Typical Small Commercial Building with Various End-Use Loads . E-2 Figure E - 2: Simple BASs with Local Configuration Option for Small Buildings ........................ E-3 Figure F - 1: Schematic of a Typical Small Building with Various End-Use Loads ...................... F-2 Figure F - 2: Simple BAS with Local Controls but Remote Configuration Option for Small
Buildings ................................................................................................................................. F-3 Figure G - 1: Schematic of a Typical Medium-Size Commercial Building with Various End-Use
Loads .......................................................................................................................................G-2 Figure G - 2: Building Automation System with Local Control and Configuration and Local or
Remote Monitoring for Medium-Sized Buildings ..................................................................G-3
xxiii
Tables
Table 1: Controls for Single Zone Packaged Air Units (Source: Itron 2006) ..................................... 7 Table 2: Energy Saving and Grid Responsive Lighting Control Strategies ........................................ 9 Table 3: Key CMELs for Target Building Types of Interest (adapted from McKenny et al. 2010). 10 Table 4: Energy Savings for Building 4 from Pre- and Post-BAS Upgrades ................................... 53 Table 5: Energy Cost Savings for Building 4 from Pre- and Post-BAS Upgrades ........................... 53 Table A - 1: Distribution of Commercial Buildings by Principle Building Activity (<=5,000-sf) .A-1 Table C - 1: Summary of Communication Means for DR .............................................................. C-3 Table D - 1: Electricity Savings Analysis for Building 4 from Pre- and Post-BAS Upgrades ..... D-11 Table D - 2: Electricity Cost Savings for Building 4 from Pre- and Post-BAS Upgrades ............ D-11
1
1.0 Introduction
Buildings consume over 40% of the total energy consumption in the U.S1. A significant portion of the energy consumed in buildings is wasted because of the lack of controls or the inability to use building automation systems (BASs) properly. Green House Gas Emissions
Energy Consumption
Electricity Consumption
Figure 1: Distribution of U.S Electricity, Energy, and Green House Gases (ASHRAE 2012)
Much of the waste occurs because of our inability to manage and controls buildings efficiently. Over 90% of the buildings are either small-size (<5,000 sf) or medium-size (between 5,000 sf and 50,000 sf); these buildings currently do not use BASs to monitor and control their building systems from a central location. According to 2009 Commercial Building Energy Consumption Survey (EIA 2009), about 10% of the buildings in the U.S. use BASs or central controls to manage their building system operations. Buildings that use BASs are typically large (>100,000 sf). Although most small- and medium-size commercial buildings lack building automation systems, some end-uses (for example, packaged rooftop units) have dedicated thermostats that control the unit. However, if the building has multiple thermostats, they are not generally coordinated, and the set points may not be “optimal” and the schedules configured in each thermostat are often not synchronized with each other or the overall building occupancy patterns. In most cases, even if the buildings have programmable thermostats, they are not likely to be programmed correctly. In addition, other major end-uses, like interior and exterior lighting and exhaust fans, are not generally controlled in an automated way. Therefore, significant energy is wasted in these buildings. Development of cost-effective BASs for small- and medium-sized buildings will make these buildings more energy efficient. A BAS for small/medium-sized buildings should be able to monitor and control major end-uses (such as, heating, ventilation and air conditioning systems (HVAC); exhaust fans and interior and exterior lighting systems) from anywhere in coordinated way (web, smart phones or desktop computers). Some of the control capabilities of the BAS include: scheduling major end-use loads (such as, air conditioners, heat pumps, furnaces, interior and exterior lights and exhaust fans); resetting heating and cooling set points during unoccupied periods; enabling “optimal” start and stop times for HVAC systems; and making major equipment demand responsive. Monitoring capability of the BAS will ensure proper and persistent operations.
1 http://buildingsdatabook.eren.doe.gov/ChapterIntro1.aspx?1#4 – November 1, 2012
2
While there are a number of reasons why the small- and medium-sized buildings lack the proper control infrastructure, the main reason is cost. For many buildings energy cost reductions from operational improvement may be sufficient justification to add proper controls. However, if the same control infrastructure is leveraged to provide additional services beyond improving energy efficiency and cost reduction, the owners/tenants of small- and medium-sized buildings may find it more compelling. Because commercial and residential buildings consume over 70% of the electricity, they can provide additional services to grid. The grid with increased penetration of distributed generations, much of which is variable renewable generation, needs smart/intelligent buildings to mitigate the variability of the distributed generation.
1.1 Study Scope and Approach As stated previously, small- and medium-sized commercial buildings, which constitute over 90% of commercial building stock, lack proper monitoring and controls of the major end-uses. So, the objective of this study is to identify the monitoring and control needs and develop a set of requirements to develop cost-effective control packages for small and medium-sized commercial buildings. Therefore, the scope of this study is to characterize the monitoring and controls (for both efficiency and demand response) needs for the various end-uses, development of requirements to develop control packages and the target cost of doing so. The focus areas of the study are:
1) characterize the small- and medium-sized building population
2) identify the building automation system needs (end-uses and systems to be controlled) for small/medium-sized buildings
3) identify basic control capabilities to address the needs identified in item above
4) characterize existing industry trends and control standards that could enable the development of an open controls platform
5) identify the architectural needs for next-generation control systems to assist buildings to (1) save energy by “optimal” control of building sub-systems, and (2) manage and control building sub-systems to provide seamless integration of buildings to the electric grid
6) identify optimal control schemes applicable for small/medium-sized buildings including model-predictive controls, cooperative control, and optimal distributed controls
7) characterize existing building to grid research, emerging smart grid standards related to buildings and demand response automation
8) characterize trends and emerging technologies related to underlying data collection and storage to facilitate remote monitoring and “optimal” control to ensure proper and persistent operations
9) develop a case study to show that building controls for small- and medium-sized buildings can be cost-effective
10) estimate target installed cost of monitoring and controls infrastructure
The characterization of the small- and medium-sized building population is be done by analyzing the 2003 Commercial Buildings End-Use Survey data (EIA 2003). CBECS data is also be used to estimate
3
the energy use intensities (EUI) for major end-uses. Development of the monitoring and control capabilities are based on review of existing literature, experience of the authors and based on recent experience of retrofitting small and medium-sized buildings with monitoring and controls. The characterization of the industry trends and standards is based on review of literature and also leveraging the previous work conducted by the authors. Some parts of the U.S. are experimenting with time-of-use and critical peak pricing. These regions are also experimenting with demand response programs. The report will document these programs and also document additional innovative approaches to make buildings more demand responsive. In addition, National Institute of Standards and Technology (NIST) with the help of a number of organizations is developing standards for Smart Grid. To ensure persistence of “optimal” controls, the controls infrastructure will also need to support monitoring. The report summarizes the monitoring needs and infrastructure (storage, data collection, etc.) needed for monitoring is also highlighted in the report.
1.2 Report Organization Following the introduction, the small- and medium-sized commercial building type, size, HVAC controls, lighting controls, plug load controls and advanced HVAC control concepts are characterized. In Section 3, potential wired, wireless and hybrid network communication architectures are presented. Followed by architectural needs of BAS, 2 potential BAS configuration for small buildings and 1 potential BAS configuration for medium-sized building are presented in Section 4. In Section 5, the requirements of various devices used to monitoring, control and to make the buildings grid responsive for small-/medium-sized commercial buildings are described. In Section 6, an estimate of what the installed cost of the control system should be is summarized, followed by a case study of a medium-sized building controls retrofit in Section 7. The recommendations from the study are provided in Section 8 and a list of references in Section 9. The report also includes as set of Appendices: A) more details on characterization of commercial buildings of interest, B) additional details on lighting controls, C) demand response signal and communication media D) more details on the controls retrofit case study and E) three use cases for use of BASs in small-/medium-sized commercial buildings.
4
2.0 Characterization of Small- and Medium-Sized Commercial Buildings
The characterization is primarily through the Commercial Building Energy Consumption Survey (CBECS). CBECS survey is conducted roughly every 4 years by Energy Information Administration (EIA). Although the last survey conducted by EIA was in 2007, EIA did not release the detailed micro-data from the survey because of issues with the quality of the survey. So, micro-data from the 2003 survey is used to characterize the small- and medium-size commercial building stock (EIA 2003).
The CBECS 2003 data set was the primary data source used in this analysis. The data was compiled by the EIA from a periodic national survey of commercial buildings and their energy suppliers (utilities). The data from the surveys are available as downloadable reports and micro-data (electronic) files from the EIA website2.
2.1 Selection of Building Types and Sizes
In the CBECS 2003 survey, 5,215 total buildings were surveyed, and the sampled buildings were given base weights that relate the sampled buildings to the entire stock of commercial buildings in the United States. The data set is classified into 20 major principal building activities or building types. Several of the building types are not relevant to the current study because their end uses are significantly different from of the rest. For a detailed explanation of building types, please refer to the EIA web site3.
Although there are 20 different building types, only the following building types were considered for the characterization analysis: office, education, retail (includes strip mall, enclosed malls, retail other than mall), outpatient, religious worship and services. The primary reason of limiting the analysis to these buildings types is because the energy consumption in these building types is mostly from heating, ventilation and air conditioning (HVAC), lighting, and plug loads and therefore where advanced controls will have the most impact. Some of the other building types that were excluded use a significant refrigeration load (food sales, food service and refrigerated warehouses). The subset of building types selected also exhibit similar heating and cooling equipment (air conditioner or heat pumps for cooling and heat pumps or furnaces for heating), which are typically controlled by a thermostat.
For this study, a building has been classified as “small”, if it is 5,000 square feet (sf) or less. Buildings that are between 5,000 sf and 50,000 sf have been classified as “medium-size.” Therefore, the characterization of the buildings was broken down into three different sizes of buildings: 1) 0 to 5,000 sf, 2) 5,001 to 50,000 sf and 3) 0 – 50,000 sf. The last one (0 – 50,000 sf) is to see if there is significant difference between that and the other size categories.
2.2 Summary of Building Characterization
A detailed characterization of commercial buildings for two different sizes (small and medium) of interest is included in Appendix A. Because the difference in disaggregated end-use consumption between the two size categories (less than equal to 5,000 sf and 5,001 sf to 50,000 sf) is not significantly
2 http://www.eia.gov/emeu/cbecs/cbecs2003/public_use_2003/cbecs_pudata2003.html 3 http://www.eia.gov/emeu/cbecs/building_types.html
5
different, to estimate energy savings from controls and demand response strategies the disaggregated end-use consumption for building less than 50,000 sf will be used.
Figure 2 shows the disaggregation of energy end-use consumption in the subset of commercial buildings that are 50,000 sf or less. Although there are some minor differences in the disaggregation of the energy consumption compared in the two size categories (discussed in Appendix A), heating consumption is still the dominant end-use, followed by lighting, plug loads and cooling. Over half (55%) the consumption in buildings less than 50,000 sf is from HVAC consumption. HVAC, lighting and plug loads account for almost 90% of all consumption for this category of buildings. Figure 3 shows the disaggregation of electricity end-use consumption in the subset of commercial buildings sized 50,000 sf or less. HVAC and lighting consume over 71% of the electricity consumption for this category of buildings, while the rest of the consumption is from plug loads, water heating and refrigeration.
Figure 2: Disaggregation of Energy End-Use Consumption in the Subset of Commercial Buildings that are 50,000 sf or less
42%
8%5%4%
21%
1% 5%
2% 3%
9% Heating
Cooling
Ventilation
Service Hot Water
Lighting
Cooking
Refrigeration
Office Equipment
Computer
Miscellaneous
6
Figure 3: Disaggregation of Electricity End-Use Consumption in the Subset of Commercial Buildings 50,000 sf or less
2.3 HVAC End-Use Controls Characterization
The objectives of HVAC controls are to provide thermal conditioning and ventilation services while minimizing maintenance and operating costs. On one end of the spectrum are simple thermostats that are manually controlled, similar to many home HVAC controls. On the other end, more complex systems can offer a range of functionality to minimize energy costs, provide energy cost feedback, and provide remote monitoring for control and security. Many new Internet-protocol-based controls can now provide grid integration systems for participation in demand response.
To implement energy efficiency and grid integration or demand response (DR) strategies, it is useful to understand the kind of controls commonly used in small commercial buildings. Table 1 shows the type of controls in buildings less than 25,000-sf (Itron 2006). BASs (building automation system) are the preferred way to implement many energy efficiency and DR strategies in buildings because they allow for programming strategies, either manually or automatically. The penetration rate of these systems into small commercial buildings is low because they are expensive. As mentioned, most buildings have manual control. Manual control consists of adjusting thermostat settings manually. Programmable thermostats are the second most widely used controls, with a penetration rate of 28%.
5%
17%
13%
3%
36%
0%
5%
3%
6%
12%
Heating
Cooling
Ventilation
Service Hot Water
Lighting
Cooking
Refrigeration
Office Equipment
Computer
Miscellaneous
7
Table 1: Controls for Single Zone Packaged Air Units (Source: Itron 2006)
Type Total by Count % by Count Total by Ton % by Ton Manual 609,736 61.3 338,609 47.5 Always on Constant Temperature 29,527 3.0 28,352 4.0 Time Clock 59,925 6.0 62,324 8.8 Energy Management System 16,628 1.7 29,127 4.1 Programmable Thermostat 279,473 28.1 254,094 35.7
2.3.1 Set Point and Rule-Based Control
A large portion of the current controls in small- and medium-sized buildings are set point based or rule-based controls. Typically there is a programmable logic controller (e.g. thermostat) with a predefined control scheme that is executed based on the sensor data. This class of control system is designed around the difference between a reference input (i.e., temperature, pressure, etc.) and some function of the controlled variable (typically a set point value) is used to calculate an error of the controlled variable from set point, which results in supplying an actuating signal to the control elements and controlled system. The goal of this system design is to zero the difference between the reference input and the controlled variable. Typically thermostats used in small- and medium-sized buildings measure temperature in the room to compute the control error (difference between the measured value and the set point) and drive the fans, compressors, electric or gas heating stages and economizer dampers to achieve the set point as a measured value. An advanced form of this control includes rule-based or heuristic control systems that allow the user to set schedules of set points over time so the building is controlled based on an expected occupancy. For example, programmable thermostats that allow weekly schedules for set points allow for different temperature set points for different times of the day and week.
Typical set point based controllers are proportional integral derivative (PID) controllers, as shown in Figure 4. This class of controller uses algorithms that are based upon the current, past, and future errors. These calculations are used simultaneously to generate an optimal actuation signal to the control elements. While this class of control is very common in buildings, these controls are only as effective as the location of the sensor measuring the output of the control system. This control system also does not provide efficient ways to dynamically change energy usage based on real usage of buildings as opposed to estimated usage of buildings. There are several variations of this control scheme to accommodate additional sensing points and use of various data-based estimators of the building’s energy usage.
8
Figure 4: PID Controller
2.4 Lighting End-Use Controls Characterization
Similar to HVAC systems, the simplest lighting controls are manual, and consist of on/off or dimmer switches. Automated control systems range from simple scheduling to sensor-based systems that actuate electric lights according to occupancy or ambient light levels; they may incorporate a variety of occupant personal control options. With dimmable ballasts, lumen maintenance, daylighting, and set point tuning are also possible. Networked control solutions may be capable of providing grid-integrated DR. “optimize” HVAC controls and remote monitoring and control. Electrical lighting in buildings is responsible for between 30% and 33% of the commercial sector peak load (Rubinstein and Kiliccote 2007), and 20% of the total energy use in the commercial sector (EIA 2003).
Recent analysis of California End Use Survey (CEUS) data shows that fluorescent lamps dominate small commercial buildings with 76% penetration, followed by 11% penetration of incandescent light sources. Ballast types in small commercial buildings are magnetic ballasts, electronic ballasts and high efficiency magnetic ballasts, 41%, 31% and 27%, respectively. There is little penetration of advanced (dimmable or controllable) electronic ballasts in small commercial buildings.
Lighting controls are implemented in about 30% of the commercial lighting stock, and lighting is used an average of 11.2 hours per day (Navigant 2012). Although the Navigant study did not separate the lighting controls into small and large buildings, anecdotal evidence shows that lights in the small buildings are generally not automatically controlled. CEUS data show that nearly 95% of small commercial buildings feature no automated controls (manual on/off or bi-level switches only). Where automation is implemented, energy management systems and time clocks for scheduling are most prevalent. Therefore, increasing the prevalence of lighting controls in small- and medium-sized commercial buildings presents great energy saving opportunities.
In spite of their low penetration rate in existing buildings, automated lighting control strategies can be used to realize more energy-efficient operations, and to increase responsiveness during times of grid stress, or peak demand. Table 2 contains a summary of four lighting control strategies – photo sensor-based daylighting harvesting occupancy detection, institutional set point tuning, and occupant personal controls - and how they can be implemented for efficiency, as well as load reduction. In the future, building lighting control systems should also be designed and architected to accommodate intermittent
9
renewable supplies, dynamic prices, or energy/demand-based transactions with other buildings or building systems.
Table 2: Energy Saving and Grid Responsive Lighting Control Strategies
CCT: Correlated Color Temperature
Detailed lighting control system architectures are presented in Appendix B.
2.5 Miscellaneous End-Use Load Controls Characterization
Commercial miscellaneous and electronic loads (CMELs) are a large and growing end use, according to data from EIA Annual Energy Outlook (EIA 2012), but few data exist to identify which specific devices consume most of the CMELs energy and which savings strategies would be most effective. CMELs are diverse and vary by building type (see Table 3 for key CMELs by building type), but research shows that some CMELs are more amenable to controls both for energy efficiency and/or DR. Note that some of the CMELs identified are in fact process loads (i.e., loads critical to performing the business function), and these include refrigeration and cooking in food service and computers in offices. Figure 5 shows the aggregate site energy used by different commercial building types with the CMELs fraction of use identified. Note that CMELs are a significant fraction of energy use, and the EIA’s Annual Energy Outlook (AEO) projects growth in absolute energy use as well as fraction of building energy use over time. Figure 6 shows a breakdown of annual energy use by some general CMELs categories. Information technology (IT) equipment (e.g., computers, printers, and network equipment) are the largest category, with computers being the largest contributor. Refrigeration and “Other” CMEL make up the next largest categories.
10
Table 3: Key CMELs for Target Building Types of Interest (adapted from McKenny et al. 2010)
Office Retail/Service (Non-
Food) Education
Public Assembly, Public Order and Religious
Worship Personal Computer (PC) Cooking PC Cooking
Monitor PC Monitor PC
Office Equipment Walk-in Refrigeration Office Equipment Landscape Irrigation
Cooking Vending Machine Cooking Walk-in Refrigeration
Residential Refrigeration Monitor Walk-in Refrigeration Fitness Equipment
Distribution Transformer Distribution Transformer Vending Machine Arcade
Vending Machine Laundry Distribution Transformer Vending Machine
Vertical Transport Unit Cooler Ice Machines Monitor
Unit Cooler TV Unit Cooler Non-road Vehicles
Automated Teller Machine (ATM)
Vertical Transport Unit Cooler
Residential Refrigeration
TWh/yr: Trillion watt-hours per year
Figure 5: Annual Energy Use of Commercial Building Types Showing Fraction that is CMELs Energy Use (adapted from McKenny et al. 2010)
0 50 100 150 200 250 300
Retail/Service (non-food)
Office
Education
Public AO&R
Annual Energy Consumption (TWh/yr)
Main Loads
Key CMELS
11
Figure 6: Breakdown of CMELs Energy Use by Category for all Commercial Building Types
(Building Energy Data Book 20114).
Strategies for controls should include scheduling, occupancy controls, and grid responsiveness.
• control of PCs in office environments,
• occupancy control of non-essential loads in office and non-office environments,
• schedule control,
• grid responsive behavior.
The single largest category of CMELs energy use is IT equipment. Controls can be effective for these devices, and because most IT equipment already has significant computing and communication capabilities, retrofit of control strategies into existing equipment through software updates is often possible. Even though power management controls have been built into most IT equipment for nearly 20 years, these capabilities are often not enabled for a variety of reasons having to do with loss of network connectivity when devices go to sleep (which in turn prevents data backups, remote network access, etc.). Network proxying is a potential control strategy to solve this problem. It enables computers and printers to sleep and maintain network connectivity, something that is not currently possible with today’s computer sleep modes. This is similar to existing Wake-On-LAN (local area network) (WOL) technology, but it enables computers to respond to a wide range of network traffic without the remote applications being aware the PC is asleep. Current WOL requires the backup and update servers be aware of the client computer’s power state and use specialized “magic packets” to wake computers, which has limited the use of this technology. Proxying is one of the largest CMELs savings opportunities, but it still requires final development and demonstration to help speed adoption. Proxying has wide application in small commercial buildings, where centralized IT management is less common, and WOL technology is even less effective than in large commercial buildings. A back-of-the-envelope savings estimate is that proxying applied to PCs in commercial buildings can save in excess of 60 TWh annually (>1% of commercial primary energy). Network proxying can include remote sleep commands issued by an energy management system and then autonomous operation thereafter. Remote wake-up commands can also be issued to ensure computers are running when staff arrive for normal operating hours.
4 http://buildingsdatabook.eren.doe.gov/ChapterIntro3.aspx last accessed September 2012.
0
50
100
150
200
250
Refrigeration IT Loads Cooking Other
Annu
al E
nerg
y U
se (T
Wh)
End Use
12
The energy use of a wide variety of CMELs devices (water coolers, task lighting, non-road vehicles, vending machines, etc.) can be reduced through a combination of timer or occupancy-based controls. These strategies generally take advantage of the fact that demand for energy services, such as task lighting or chilled water, is greatly reduced or eliminated when the building is not occupied. For buildings with regular operating hours, timer-based controls can be a cost-effective option; but in many situations occupancy controls are needed to better match device operation with demand. Ultimately, integrating device-level controls with a building-wide energy management system may provide the best balance between energy savings and provision of energy services. A key aspect of these device-level control systems is that control should be integrated into the device itself so that a management system can provide control signals to the device for “native” control using its internal control mechanisms. This is much preferable to “relay-in-outlet” based control, which simply cuts the power to a device based on a timer or occupancy sensor. The native controls that are built into devices allow more detailed modulation of energy services, which in turn allows energy savings with less inconvenience for occupants. For instance, refrigerated vending machines can be controlled to turn off display lights and increase the refrigerator set point during times when the building is unoccupied, which is a much more acceptable option than simply turning the device off entirely. Navigant (Goetzler et al. 2009) estimates that these types of energy management systems can save between 20 and 35% of annual energy use in beverage merchandisers and refrigerated vending machines. Similar types of control strategies can be applied to a wide variety of CMELs devices. To take full advantage of this savings potential in the CMELs end use, individual devices should be integrated with building-wide energy management systems, which in turn will require standard communication protocols and control semantics to allow broad interoperability of equipment.
Applying controls to CMELs devices will also enable grid responsive behavior, allowing power demand to be curtailed when the grid is under stress. This can most easily be achieved, with little impact on occupant amenity, using devices with significant thermal storage, such as commercial freezers and ice makers. Freezers can “deep freeze” (similar to pre-cooling) before a grid event and let their set point drift (within a safe range) during an event. In off hours, freezers and refrigerators can participate in demand side ancillary services for spinning reserve by controlling compressor activity according to grid needs. Currently few, if any, refrigerators and freezers include this capability, but the opportunity appears significant given the annual energy use of these devices in small buildings. Ice makers can similarly provide a DR service by generating ice during off-peak or low energy price times and allowing the storage bin to be drawn down (without replenishment) during high-demand times. Similarly, devices with internal electricity storage, such as laptop computers (Murthy et al. 2012) or forklifts, can also provide grid support by avoiding or curtailing battery charging during DR events. In situations where building occupants can tolerate some reduction of services, further load reductions are possible using devices’ internal control mechanisms. For instance, task lighting can be dimmed to reduce loads, and computers can use voltage and frequency scaling (which is present in all modern computer processors) to slow their processors and reduce power draw. As mentioned earlier, to enable these control strategies in commercial buildings will require standard protocols and semantics so that individual devices can be notified of the need for load reductions and take appropriate action.
2.6 Advanced HVAC Control Concepts
During the last year (2011), there has been a great deal of development related to communicating and learning thermostats. For example, there are commercially available thermostats that are compatible with
13
most packaged HVAC systems and use industry standard connections to facilitate the control of these HVAC systems. Some thermostats are programmable with learning algorithms to optimize the heating and cooling in a building. Many of the recent advanced thermostats can be connected to the Internet, allowing for remote control, energy usage histories and schedules.
Research focused on next-generation controller architectures for BAS primarily developed advanced computational modeling, building plans, building usage behavior and wireless networks to optimize energy consumption in buildings. By taking advantage of extensive work done over the past few decades on observer design for finite dimensional systems, there has been a progression toward algorithms, which apply finite dimensional systems to a class of infinite dimensional systems governed by transport processes. Ultimately, problem formulation and theory application for HVAC systems has led to the most effective results in saving energy (including applications to DR methods). The ongoing research in optimizing the controller of the constant air volume/variable air volume (CAV/VAV), sensor locations, and energy models of BAS has resulted in the reduction of energy consumption in buildings.
Another motivation and challenge within a BAS is optimizing the sensor and control network so that the data reliability from the utilized network is not an issue. Wireless sensor networks (WSN) are becoming an integral part of next-generation BAS by which they operate and transmit data. WSN have their own constraints, which must be considered. Data reliability is a wireless communication robust control problem, but because it is an integral component of BAS, there exists common dynamics, which affect the overall performance of the system. Data reliability and traffic congestion in a building automation network (BAN) caused by limited network bandwidth are control problems where research has implemented genetic algorithms, linear and nonlinear network coding schemes to monitor and control traffic within channels. This includes the physical environment, noise and interference to which the system is subjected. Discrete control schemes that are typically latency-tolerant are applicable for wireless control; however, continuous controls with nonlinear dynamics for presence of latency and jitter require robust network provisioning. Optimizing sensor location and the number of sensors may also correlate in the reduction of the amount of unreliable data and possibly the number of sensors needed for HVAC/BAS systems.
HVAC systems are composed of a large number of subsystems, each of which may exhibit time varying and/or nonlinear characteristics and monitor the temperature, power consumption, weather, and building occupancy. The quantitative indices of comfort in the room are temperature, humidity ratio, and CO2 concentration, all which affect the work efficiency of people. Commercial HVAC controllers typically utilize multiple PI/PID controllers to regulate these indices by individual single input single output (SISO) control loops (Anderson et al. 2005). Early investigations into HVAC control focused on distributed SISO proportional integral (PI) controllers. The dynamics of a multi-zone HVAC system are too complex for a PI/PID control to be a sufficient controller for an HVAC system. The choice of this design method is limited in that SISO controllers cannot implement the multivariable dynamics of an HVAC system and the low gains and inaccurate tuning of PI-based HVAC controllers contribute to poor performance (Anderson et al. 2005). This scheme, which implemented only three (SISO) PI controllers to control the commanded water heater temperature, commanded return (external) air damper position, and commanded valve position, yielded tolerable performance at best.
The control of these indices has also been implemented in a design of an adaptive controller for a nonlinear multiple input multiple output (MIMO) HVAC system. Included in this model was the CO2 in a room including the CO2 concentration of inlet air, the CO2 concentration of air leaving the room and the
14
air exchange rate. This model assumed that the air in the room is well-mixed and then propose a hybrid system model for the HVAC system from the mass balance equation, the average CO2 concentration dependent upon the number of people in the room.
Another design in this area of research utilized feedback linearization via dynamic extension and hybrid model for the HVAC system. The hybrid system for the HVAC system applied the feedback linearization technique with dynamic extension to design the continuous adaptive control for the nonlinear MIMO system. This design reduced the nonlinear system to an aggregate of independent single input, single output channels and modeled the dynamics of the environment. The motivation of this design resulted from system perturbations, load changes, and thermal loads, which may be time varying or unknown. Therefore, an adaptive controller was shown to be effective by the computer simulations in comparison to the non-adaptive controller (Anderson et al. 2005).
Recently, there have also been approaches to mitigating the limitations of traditional PID control with the development of optimization algorithms to tune online the parameters of PID controller. In one scheme, algorithms that applied adaptive control as a solution for stability and optimum control performance while implementing a least mean square (LMS) learning algorithm were used to enhance the performance and control of HVAC system (Bai et al. 2008).
Other research has shown that even a simple algorithm based on a small set of typical HVAC parameters implemented by an intelligent-based PID controller is much better than a standard PID controller on HVAC systems with large inertia, lag, and other disturbances (Salami et al. 2011). These designs along with MIMO control schemes and improved algorithms utilized by PID controllers can in the future be a part of BAS improving the overall energy efficiency of the building
However, an optimal controller’s sensitivity to discrepancies between the model used in designing the controller and that of the physical plant (model uncertainty) poses a major problem in HVAC systems, where accurate models are not readily available. Furthermore, the characteristics of an HVAC plant change (deteriorate) over time (Anderson et al. 2005). Thus, the design of the model itself, as well as optimizing the number of actuator/sensors, is extremely important. The optimal design and control of these systems are very challenging problems and are often done by first developing a reduced order model and then basing the design on the simplified model. These schemes as they were developed typically implement Ricatti’s equation, the Navier-Stokes equation, and the energy equation to model the thermal dynamics to track the dynamics of a room. These equations are implemented in the optimization of a system linearized about the steady flow of the system that describes the room dynamics by a linearized equation that can be governed by its corresponding linear quadratic regulator (LQR).
Thus, in further research, enhancing the mathematical modeling of the physics of the problem and deriving approximations at the last stage of the design is a logical procedure to follow. Optimizing sensor location and the number of sensors via estimation is also a problem to consider because this will also be a cost factor for consumers implementing BAS.
There has been considerable development of building modeling and simulation. These algorithms contain numerical solvers that may iterate until a convergence criterion is met, resulting in the energy function being discontinuous with respect to the input parameters or may result in discovering which algorithm performs best on a selected family of problems for optimizing energy use. Some research has implemented genetic algorithms (GAs), covariance matrix adaptation evolution strategy and hybrid
15
differential evolution (CMA-ES/HDE) and hybrid particle swarm optimization and Hooke-Jeeves (PSO/HJ) to look for optimized design solutions in terms of thermal and lighting performance in a building. The hybrid PSO/HJ was ranked one of the best in their comparison to the optimization algorithms tested with EnergyPlus (DOE 2010).
The design of the model itself and optimizing the number of actuator/sensors needed in a BAS is extremely important. Applying reduced order models and controllers to sensor placement has not been fully developed and applied to a wide variety of distributed parameter control problems. The controls used in the small- and medium-sized buildings can be classified into three categories: set point and rule-based control, model-predictive and optimal control, and learning-based control.
2.6.1 Model-Predictive and Optimal Control
The key issue for the purpose of reducing building energy cost is the performance of building service systems. To operate buildings more energy and cost effectively, predictive integrated room automation can be used instead of conventional room automation. For instance, the predictive integrated room automation controllers can operate the buildings’ passive thermal storage based on predicted future disturbances (e.g., weather forecast) by making use of low-cost energy sources (Gwerder and Todtli 2005). The goal is thus to optimally design a controller, which can realize the temperature requirement and minimize energy consumptions. This class of controller uses a dynamic model of the building and subsystems driven by the state information provided by various sensors to generate an optimal control scheme. Often the model-based controls are equipped with a cost function and optimization scheme for a particular objective.
Ma et al. (2009) studied the application of a model-based predictive control (MPC) of thermal energy storage in building cooling systems. The cooling systems are modeled as a nonlinear state-space model, and the cost function is quadratic in both energy price and control variables. Borggaard et al. (2009) considers the estimation and control for a distributed parameter model of a multi-room building. The goal there is to design the room by using the distributed parameter control theory. The system is governed by Navier-Stokes equation and linear quadratic regulator (LQR) controller is designed. Moreover, Olderwurtel et al. (2010) employed stochastic MPC technique to compute the control strategy for a cost function, which was linear in the control variable for the thermal dynamics in a linear state-space model, which described thermal energy and temperatures. Rule-based control and performance bound methods are also used in Olderwurtel et al. (2010), as benchmarks to MPC schemes. Gondhalekar et al. (2010) simplified building climate plant proposed by Gwerder et al. (2005), is used and periodic MPC control law design is employed. Additionally, Olderwurtel et al. (2008) proposed a tractable approximation method for the problem. Both schemes in Olderwurtel et al. (2008) and Olderwurtel et al. (2010) considered chance constraints and solved them by using affine disturbance feedback.
Figure 7 shows the architecture of a model-predictive control scheme driven by sensor data for optimal whole building control. Because buildings and equipment degrade over time, significant energy efficiency gains can be obtained by early detection of faults in the buildings. It has been estimated that the average commercial air conditioning unit has an evaporator flow between 15 and 25% less than optimal, 35% of commercial rooftop units’ dampers fail with in several years of installation, and between 50 and 67% of air conditioners are improperly charged or have airflow issues. Just adjusting the suction pressure based on the ambient temperature for multi-stage refrigeration systems can improve the energy efficiency
16
by between 8 and 15%. Models of building and subsystems driven by real-time sensor data can be used to develop advanced controllers to optimize buildings performance over time. The key research topic in this area is a reusable set of reduced order models for small- and medium- sized buildings’ that are representative of the equipment and buildings thermal conditions. MPC algorithms are typically computationally intensive and require significant sensor data for online calibration. A combination of optimal sensor placement algorithms coupled with reduced order models can generate a new class of algorithms that can be run on embedded computer nodes for ease of deployment.
Figure 7: Model-Predictive Control of Building HVAC System
2.6.2 Agent-Based or Learning-based Controls
This class of controls uses a data-based learning mechanism of the behavior of the building usage and subsystems to perform control reconfiguration of dynamic systems. Typical learning modalities used in this control scheme are neural networks, machine learning, and statistical data mining. Recent studies have shown the use of fuzzy logic controllers (Mirinejad et al. 2012) using novel computing models to control HVAC systems where classical control systems do not achieve comparable results. The learning-based controllers typically do not require physics-based mathematical models of the building subsystems but depend on a knowledge base and learning algorithms to understand the behavior of the energy usage. The key challenge is automated construction of the rule-base, knowledge-base, and the membership functions based on the human expert or self-learning algorithms. Precedence of such systems exists in other domains, and key contributions are needed for tailoring this work for HVAC systems and complex interactions of the building subsystems and occupants.
2.7 Control and Load Variability – Optimization, Electric Load
This section outlines several areas of advanced controls strategies that have been applied in small commercial buildings. Throughout the U.S. small commercial buildings are beginning to be exposed to time of use charges, with dynamic pricing coming in several areas. We cover two general areas on this topic
• pre-cooling
17
• fast DR with ancillary services.
Pre-cooling generally works as follows: the building is pre-cooled at night or early morning at moderately low zone temperature set points (68°F-70°F) and then the zone temperature set points are allowed to float within the comfort zone (below 78°F) during peak electricity demand periods. The cooled building thermal mass and higher zone temperature set points lead to the reduction of on-peak cooling loads for the HVAC systems.
The potential for using building thermal mass for load shifting and peak demand reduction has been demonstrated in a number of simulation, laboratory and field studies. Optimal dynamic building control strategies were studied in a representative room in a large office building; the peak cooling load was reduced by as much as 40%. Keeney and Braun (1997) developed a building control strategy and conducted an experiment in an office building. It was found that the pre-cooling strategy could limit the peak cooling load to 75% of the cooling capacity. Xu et al. (2004) demonstrated the potential for reducing peak electricity demand in moderate-mass commercial buildings by modifying the control of the HVAC systems. The field test results showed the chiller power was reduced between 80% and 100% during the peak period without causing thermal discomfort. A series of field tests in two commercial buildings in Northern California were conducted to investigate the effects of various pre-cooling and demand shed strategies. The cooling loads were reduced between 25% and 50% in peak hours for various control strategies. Xu et al. (2006) conducted a series of simulations and strategy analyses by using Energy Plus to evaluate various DR strategies. The initial models were revised, and the parameters were adjusted to ensure the hourly simulation profiles matched the measured data.
While pre-cooling emphasizes time scales of hours, there are new grid integration projects exploring fast DR to help include more renewables on the electric grid. The Participating Load Pilot (PLP) was authorized by the California Public Utilities Commission (CPUC) as a first step towards allowing DR programs to participate in the California Independent System Operator (CAISO) ancillary services markets as participating loads (PL). The objective of these pilots was to assess the technical and financial feasibility of using retail loads for PL. Various retail load classes and technologies participated in the pilots. The key requirements under the PLP is that the PL resources have to meet the non-spinning reserve requirements, which means the resources have to deliver energy within 10 minutes, be available for 2 hours, and provide real-time telemetry to the CAISO. All three investor-owned utilities in California conducted PLPs with various customer segments. Southern California Edison utilized small aggregated loads, leveraging real-time telemetry at the feeder with two way communicating switches and air conditioning loads. San Diego Gas and Electric Company worked with aggregators with small commercial and industrial customers. CPUC allowed a portion of the PL to be dispatched manually, granted it still met the dispatch criteria.
CAISO uses the telemetry data to have visibility to the operating reserves on the grid and to ensure that it is meeting its minimum operating reliability criteria at all times. PG&E (Pacific Gas and Electric) stored these data in a secure shared folder for access by the team. Itron used the data for the load and shed forecasting. Akuacom used the 4-second data for real-time feedback to dispatch various pre-programmed control strategies at the government office building to sustain the shed amount dispatched by the CAISO. Figure 8 displays the architecture of the PLP. The dashed arrows represent meter data communications, while solid arrows represent communication of the resource request parameters. In Figure 8, the entities to the left grouped with dashed lines are involved in pre- and post-analysis. Others to the right, including PG&E, are involved in the actual resource request and/or delivery.
18
Figure 8: PLP Architecture
Sites that participated in PG&E’s AutoDR programs in previous years were considered for this pilot. Selection criteria were as follows:
• Low load variability – enhances load forecasting accuracy
• Ability to deliver resource in 10 minutes
• Low shed variability – enhances shed forecasting accuracy
• Minimum of 10 kW of load shed, which is possible in many small commercial building.
19
3.0 Communication Architectures
Small and medium-sized buildings typically are not served by a sophisticated BAS. BAS is comprised of controllers (supervisory or local), sensors, actuators and relays. The sensors provide the state information of the system under control. The controllers take the sensor data and compute the control actions required for a given comfort level and operating requirements and send signals to the actuators or relays. The actuators and relays effect the operation of the physical systems. There is typically a network that connects the sensors, actuators/relays, and controllers, typically called a building automation network (BAN). Figure 9 shows a typical BAN with a primary bus where the human machine interface, data archival, and other application, which the building operators interact with, reside. The secondary bus typically has the sensors and actuators/relays that interact with the physical systems (conditioned space, and building HVAC and lighting equipment).
Figure 9: Typical architecture of a BAN
Most BANs serving small or medium-sized buildings can be classified into three different kinds – wired, wireless, and hybrid.
3.1 Wired Network
A significant portion of the current BASs relies on wired communication networks. While wired networks are considered reliable, deployment cost is significant. In the secondary bus, the location of the sensors typically is dictated by the location of the controllers and access limitations (usually distance, obstructions and first costs) rendering sub-optimal control of the thermal environment. Typical wired medium includes Serial link, Ethernet, Optical, and power line communications.
20
Serial links are typically point-to-point communication links used in BAN with limits on the length up to 50m per link. There are several different implementations of the serial link and associated protocols used by the BANs. Electronic Industries Association (EIA) standardized the electrical characteristics and physical layer requirements in EIA-485 standard. The link can be established as two-wire-twisted pair (half duplex), three-wire-twisted pair (half duplex with differential signaling), and four-wire-twisted pair (full duplex). Proprietary implementations of this protocol exist; for example, N2 bus is a technology developed using EIA-485 by Johnson Controls (JCI 1999) to connect various controllers to a master/supervisory controller (Figure 10). Typical serial links operate at a maximum rate of 115 kbps. However, recently optical layers are being used for the serial links necessitating optical modems on either end of the bus for specific applications.
Figure 10: Example of Cascaded Devices using N2 Serial Bus
Ethernet is a popular option for BAN because of its ubiquitous use in buildings and ease of network management. The ease of installation and configuration of Ethernet is making it an increasingly accepted choice among vendors and buildings managers. The use of Ethernet enables the use of Internet protocol (IP) on the devices connected within buildings and provides unique addressing and access (remote) schemes for sensors, actuators, and controllers. LonWorks, which provide a data link layer and physical signaling for BANs, has adapters to connect between serial links and Ethernet communications. Similarly BACnet protocol provides interface to IP communications for managing devices on BAN.
Power line carrier (PLC) is based on converting digital data to radio frequencies and sending the signals down the electric power lines. The technology is similar to broadband cable except the power lines are used instead of a coaxial cable. The technology is convenient in that the service is available
21
anywhere there are power lines without running additional cables. However, there are huge drawbacks using this mode of communication for BAN. Power lines are typically noisy with effective communication bandwidth limited to 10 kbps. Routing data through existing circuits requires careful planning and installation to eliminate network disconnections. In addition, provision for transformers in the electrical system must be made, or the signals will stop at the transformer. This provision usually is some type of “bypass” around the transformer. Because of increased safety constraints related to worker safety when exposed to power, this mode of communications is becoming less popular.
3.2 Wireless Network
Wireless sensor network (WSN) provides an attractive retro-commissioning opportunity in existing buildings. Wide variety of wireless networks exist that can be used to instrument buildings. Figure 11 shows the options in wireless networks. The x-axis represents the data rate and the y-axis represents the power consumption and cost/complexity.
Figure 11: Wireless Landscape
The key metrics to identify the wireless networks for building monitoring applications include:
1. low-data rate
2. long battery life
3. low-cost of deployment and operation
4. unlicensed frequency of operation
5. co-existence with existing building wireless networks
6. interference resistant
7. secure network operation.
22
Standards exist for current deployment of wireless sensors in the buildings. Institute of Electrical and Electronics Engineers (IEEE) 802.11, IEEE 802.15 and International Society for Automation (ISA) 100 are the two major families of American National Standards Institute (ANSI) standards. These standards are currently available and/or are under development. Corresponding industry standards and best practice methodologies have evolved along with the ISA and IEEE standards.
All of the standards utilize unlicensed bands in the spectrum. The standards are designed to be scalable for between 5 and 30 years with a backward compatibility with previous standards. A building deployment might include multiple standards; for example, sensors will communicate using low power (battery powered), low-cost (maximum number of sensor points), and low-data rate. A building-wide backbone network might include a high data rate (to transfer 100s or 1000s of sensor data), over a plug-powered network.
Several key technological developments have made WSN viable in building environments. Figure 12 shows several topologies of the interconnection within the wireless network. Two main topologies are star and mesh. In a star network, all the nodes are connected to a central node usually called a gateway (GW), as shown Figure 12. A mesh network is a host less architecture with each node connected to each other node, and messages are routed to the destination through several links called hops. The combination of star and mesh topology is commonly called as hybrid network. In hybrid networks, nodes may use neighboring nodes to reach the gateway. While a star network is quick and easy to form with robust connectivity, it is not scalable and has single point of failure. Mesh networking allows the flexibility to scale with no central or critical single point of failure because messages can re-route through an alternative route if a single node fails. However, mesh networking requires careful design of the network and the message latencies can vary depending on the path taken.
(A) (B) (C) (D)
Figure 12: Wireless Interconnection Topologies: (A) Star, (B) Partial Mesh, (C) Another Partial Mesh (D) Fully Connected Mesh
WSN can provide distributed computational platforms facilitating distributed intelligence. For example, a temperature sensor only transmits temperature when there is a change in the reading conserving battery life and reducing network traffic. Studies have suggested that the power required to transmit 1 bit is same as the power required to compute 100,000 bits in a microprocessor. Integration of sensing, computation, and communication is the key for wireless sensor development and deployment.
Powering the wireless sensor network and optimizing the power consumption is the key, as discussed earlier. State-of-the-art IEEE 802.15.4 devices can sustain sensors for between 2 and 3 years on two AA batteries, depending on duty cycle. Low power microcontrollers, low-data rate communications, and low power sensors facilitate such extended life times. Power scavenging or power harvesting is another option, particularly in buildings, to extract power from a variety of sources like vibration, solar, and thermal. The most popular energy harvesting technique used in wireless sensors is vibration. Large
23
electrical machinery like motors, pumps, etc. can generate resonant frequencies that can be converted to power using piezoelectric sensors or moving coils. Several companies have devices to power wireless sensor nodes using vibration, eliminating the use of batteries.
The four fundamental performance parameters for building WSN are:
• latency,
• throughput,
• security, and
• reliability.
Latency is defined as the time between when a data enters the network (source) and when that data is actually delivered (sink). Latency is usually measured in units of time (seconds, milli seconds, nano seconds). Throughput is the rate at which data is communicated across the network. Security is the confidentiality, availability, and integrity of the information transmitted. Reliability is defined as the mean time between failures. All the four parameters are dependent on each other. An increase in security can increase the number of bits required to send useful data increasing the latency and decreasing the throughput. Optimizations of the network should be carefully done considering the application requirements and network capability. Determinism is important in process control networks. Jitter, defined as the variation in latency of the messages over a network, plays an important role in disrupting closed-loop systems. Multi-hop networks (mesh) tend to have large variations in latency.
Understanding the sensor application requirements in the buildings’ control system is essential for the efficient design of the WSN particular to that industry. The “Nyquist” sampling criterion dictates that the sampling frequency should be at least twice the frequency of the fastest time constants in physical systems. In the context of low-cost, low-data rate sensors, sensor bandwidth should be matched with network bandwidth for the data to be really effective for building decision-making. Under-sampled or over-sampled data will not necessarily provide the correct state of the system to the operator, possibly causing an operator (controller) induced error.
There are two different data handling architectures used primarily for information dissemination in wireless sensor network:
• event-driven (push) and
• polling (pull).
Event-driven architectures are those in which the nodes only send data when an event (physical change) occurs. These architectures conserve energy but the network latencies are non-deterministic because traffic is non-deterministic. Network capacity needs to be carefully designed for such networks to avoid nodes from flooding the network during an event. Polling architectures are deterministic and depend on polling the nodes periodically for data. The polling rate can be varied for energy optimization but must accommodate the Nyquist sampling criteria described above.
24
3.3 Hybrid Wired-Wireless Networks
While wireless sensors provide clear advantages over wireless networks for building automation, there are several buildings with limited wired infrastructure for sensing and actuation of building subsystems. One attractive approach is to utilize the existing network and use wireless sensors and actuators to provide additional monitoring and control of building subsystems. Interoperability of wired and wireless networks can be achieved in several ways. Two significant implementations are: (1) application-level interoperability, and (2) link-level interoperability. Application-level interoperability includes a central server that can communicate with both the networks and exchanges data (via a database) to different applications for building management. Link-level interoperability includes a gateway that can communicate with the wireless network and translates the data to the existing buildings automation protocol (BACnet, LonWorks), as shown in Figure 13 and Figure 14. Using the gateway the wireless network points can be seen as, for example, LonWorks points providing an easy way to manage a network of wireless sensors. Hybrid networks have the potential to exploit the existing buildings for retrofit opportunities, with a potential of significant energy savings.
Figure 13: Demonstration of Link-Level Interoperability
25
Figure 14: Demonstration of a Link- and Application-Level Interoperability
26
4.0 Building Automation Systems
Building automation systems (BASs) are used to monitor and control various building systems, including, HVAC and lighting. BASs are sometimes also referred to as energy management systems (EMS) or energy management and control systems (EMCS) or direct digital control (DDC) systems. BAS consists of a set of hardware and software integrated into a single architecture to monitor and control buildings’ HVAC systems. BAS may also include control or monitoring of lighting, security, and fire systems in the building (ASHRAE Guideline 13 2007).
BAS technology has evolved over the past 3 decades from pneumatic and mechanical devices to direct digital controls (DDC) or computer-based controllers and systems. Today's BASs consist of electronic devices with microprocessors and wired and wireless communication capabilities. Widespread use of powerful, low-cost microprocessors, use of standard cabling and wireless standards, and the adoption of standard communication protocols (such as BACnet, LonWorks, and MODBUS) have led to today's improved BASs. Most modern BASs have powerful microprocessors in the field panels and controllers that are being embedded in sensors and actuators as well. Therefore, in addition to providing better functionality at a lower cost, these BASs also allow for distributing the processing and control functions to the field panels and controllers without having to rely on a central supervisory controller for all functions. Although true interoperability is still myth rather than a reality, most new BAS installations use standard protocols (such as BACnet, LonWorks, and MODBUS, etc.), web-based or web-enabled controllers, and control networks that can be integrated with the Internet and intranets.
The core functionality of the BAS is to keep the building occupants comfortable, monitor and trend the performance of various systems and provide notification of device failures and system alarms via local alarming, remote text messaging or email to the maintenance staff. The control hardware in a BAS generally consists of either building level (supervisory) controllers (or field panels), application specific controllers (or unitary controllers) and custom controllers. The building level controller generally preforms global controls such as scheduling, alarming, trending, and sharing global information with other controllers on the network. The communication between the various controllers and building systems, in most buildings, is wired; although some existing buildings are deploying wireless communications.
Although BASs have been around for over 3 decades, less than 10% of the commercial building stock has those (EIA 2009). Buildings that use BASs are typically large (>100,000 sf), while the rest of the building stock uses rudimentary controls. These controls are mostly manual, with limited scheduling capability, no monitoring and failure management. Therefore, most of these buildings are operated inefficiently and waste energy. There are a number of reasons why these buildings do not deploy BASs: 1) lack of awareness, 2) lack of inexpensive packaged solutions and 3) sometimes the owner is not the tenant, so has no incentive to invest in a BAS.
4.1 Architectural Needs for BASs
The major architectural requirements for the BASs are: 1) interoperability, 2) scalability, 3) deployment, 4) open, 5) plug-n-play play and 6) enable local or remote monitoring.
27
Interoperability - Networks and protocols in typical BAS are comprised of ANSI approved and proprietary standards. Interoperability among various devices and networks is a barrier to implementing multi-vendor solutions within a single network. True interoperability can be achieved at the device-level or gateway/router-level. Precedence in interoperability exists in other domains for sensors and controls. Open standards-based sensing and control integration to existing buildings will drive down costs by inviting “non-traditional suppliers” into the market by increasing size of the market and potentially improving competition and rate of innovation. This requires end-users to support and early adoption of standards-based approaches.
Scalability - Ubiquitous sensing improves observability and controllability of building systems. Technologies used for deploying BASs should support a scalable approach for increasing the network size for improved observability. Wired networks typically have uniform cost per additional node while wireless networks, once the backbone infrastructure is in place, have decreasing cost per additional node. One key consideration for scalability is the power required to make the nodes operational.
Deployment - Significant life-cycle costs and return on investments of a given deployment depends on the cost of deployment. Two kinds of deployments are (1) installation of new control system in buildings not served by advanced control system. This is typical in small- and medium- sized buildings; and (2) installation of a retrofit control system that interacts with parts or all of the existing control systems. Energy savings can be achieved in both the installations; however, deployment has to consider the labor cost, maintenance cost and deployment costs involved in retrofits to generate optimal return on investment. Reliability of the control systems is also an important consideration because an unreliable system may cost less but may have higher life-cycle cost.
Open Standards – While ubiquitous deployment is needed to exploit the energy savings discussed in literature, this can only be achieved if there are common open standards that address the technical, functional, and operational requirements of the small- and medium- sized buildings.
Plug-N-Play - Much of the building control devices are non-plug-n-play. For controllers or control components to be truly plug-n-play, an open industry standard is needed. Many of the building control components or unitary controllers used to control building systems that are designed to do a specific job can be made truly plug-n-play.
Monitoring - Even if the building has central controls, without the ability to monitor both the controls and end-use consumption, the persistence of the efficient operations is not ensured. So, the control solution should provide ways to enable easy access of sensor values and control parameters to third party software solutions. In addition, the controls solution should also have the ability to integrate the information from the so-called “smart” utility meters. Because energy accounts for a significant portion of the operating cost in many facilities, facility managers, energy service providers, and owners alike will benefit from software tools that track energy end-use. In addition to the ability to track and forecast energy use at the building and end-use level, interoperable access to control system and facility energy data is necessary to a) support more pervasive use of advanced energy-focused analytics in small-to-medium buildings, and therefore, b) enable next generation of energy- and price- aware grid-integrated buildings.
28
It is possible to deploy cost-effective BAS in small- and medium-sized buildings. In this section, a BAS solution for both small- and medium-sized buildings is presented. In addition to defining the functionality of the BAS, the functionality of various end-use control devices is also presented.
4.2 BASs for a Small Commercial Building
As noted in the previous section, the total energy consumption of a small building is significantly lower than a medium-sized building. So, the BAS solution for a small building has to cost less than the medium-sized building. However, as described in the next subsection, the solution presented for medium-sized buildings can also be scaled to work with smaller buildings. The proposed solution will work in both existing and new buildings and will not only improve the energy efficiency of the building, but can also be leveraged to make the building more demand responsive.
4.2.1 Small building, simple local configuration option #1
For small-sized buildings, HVAC and lighting energy constitute over one-half of the energy consumption and also over one-half of the electricity consumption. The small building “simple” local configuration option consists primarily of programmable thermostats that are connected to HVAC devices (primarily rooftop units), as shown in Figure 15. They can also include controllers for small miscellaneous loads (plug loads, small exhaust fans). The control of lighting loads may be achieved with local independent occupancy sensors; less commonly in small buildings, standalone contactor timer systems or lighting automation panels may be used for schedule-based on-off control, as described in Appendix B. This configuration also will have a central coordinating device (supervisory) or gateway controller. The dashed lines in Figure 15 indicate that the communication between thermostat/controller and the gateway device can either be hardwired or wireless. In most existing buildings a hardwired solution may not be cost-effective, so a wireless solution is needed. For new construction, a wired solution may be a cost-effective solution. While improving the energy efficiency of the building, this solution can also be leveraged to make the building and its systems more grid responsive.
29
Figure 15: Simple BASs with Local Configuration Option for Small Buildings
This configuration is a preferred choice when there are only a few HVAC systems (three or less) and these are assumed to be primarily HVAC rooftop configurations (multi-stage heating and cooling) that may also include economizer functions (integrated or standalone). This configuration may include a few small load controllers. All of these control devices shall be connected to a common communications bus (wired or wireless or both), inside the building. Communications to all controllers shall be an open standard. When specifying such a system, it is always important to fully document the installation and startup of all hardware/software functions so it will be easy to implement and troubleshoot for correct operations (startup and persistence).
In this option, the thermostats are located in designated occupied spaces in the building (office or open area). The small load controller may be connected to plug load devices. These plug loads may be located in the spaces (outlets or electrical distribution panels) that are primarily for special process loads (like hot water tanks, hot water pumps or lighting loads) or they may be up in ceiling spaces or on roofs (primarily for exhaust fans or lighting fixtures).
In existing buildings, installing lighting controls can be expensive because of re-wiring costs, high costs of controllable ballasts, and potential need to upgrade fixtures. For example, dimming or bi-level controls require specific types of ballasts. Therefore, for most existing small commercial buildings local occupancy-based lighting control is probably the most cost-effective approach. It is also possible to add a simple “ON/OFF” lighting controller for common area lighting using an “ON/OFF” controller. For new construction or when lighting fixtures in an existing building are upgraded, more sophisticated lighting controls with dimming capabilities can be deployed. In addition to scheduling of lights, these types of lighting controls will also allow reduction of lighting levels in response to a signal from an external source to conserve electricity.
30
For small buildings, remote monitoring or control (via web page, Internet connection – wired or wirelessly) is not a requirement, but is recommended for assuring persistence and sustainability of energy savings and proper, efficient equipment operations. In situations where local operation and maintenance is not implemented efficiently or where failure to have remote monitoring and/or control could compromise the building owner’s enterprise, careful consideration for this capability should be encouraged. This assurance comes primarily from reliable alarm and data management capabilities.
Control functions are distributed primarily amongst the programmable controllers (thermostats and small load controllers). There may be some “global” functions embedded in a central coordinating device/gateway. These functions may include (but are not necessarily limited to) things like alarm management (alarm monitoring and alarm notification), data management (trending, storage and retrieval), and communication with external sources.
More details on the specific capabilities of programmable thermostats and lighting controls is discussed later in this section, but thermostats that support multiple configurations (heat pump, multi-stage heating and cooling, with or without economizer integration) shall be preferred over multiple product offerings that are designed for only one type of HVAC system or subsets of HVAC systems. This alleviates future problems that arise from multiple HVAC rooftop unit vendor configurations at the building or from replacement of one type of HVAC system with a different one (different vendor or switch from multi-stage to heat pump or vice versa).
Configuration of all thermostat control parameters shall be configured from the local programmable thermostat display screen. The thermostats should also allow for configuration of the thermostats and monitoring from the central device, so the building owner or operator can manage all thermostats from a single location. Different levels of program access shall be required for each programmable thermostat. Basic access shall be provided to allow for local occupant overrides and other non-critical functions. Higher level access (via proper password access) shall be provided for service/maintenance personnel or other designated staff. This higher level access shall include access for schedule changes and equipment protection parameters (minimum on/off short cycle parameters and/or similar functions).
Data and alarm management functions at the local devices (programmable thermostats, etc.) are preferred. This includes tracking HVAC equipment performance issues such as dirty filters, hours of heating and cooling operation with local notification for maintenance inspections and can include storage of a minimum number of time-stamped alarms (high/low temperatures, etc.). The recommended number of alarms held in memory is between 10 and 20. Having more than 20 alarms per device is not really going to provide any value for the service provider or the owner, if not addressed in a timely manner. Data and alarm management functions will also allow for optional local/remote monitoring of the control devices. The access to the controller information is primarily through a central coordinating device/gateway. The central device can also be used to receive an external signal (for DR) and communicate it with the controllers, so the controllers can perform a predetermined DR operation.
In summary, the gateway is a passive device with no control capabilities, the requirements for the gateway devices are:
• ability to communicate with the thermostats and other controllers in the building
• ability to make changes to the control parameter; for example, changing thermostat set point or schedule
31
• ability to access control settings, values of various sensors connected to thermostats and controllers and alarms from various devices and provide such information to local/remote monitoring devices (computer/server)
• ability to receive external signals from utility, independent system operator or third party and communicate that to the various devices in the building.
4.2.2 Small building, simple remote configuration option #2
An alternate BAS option for small buildings that supports distributed local controls at the device-level and Cloud-based remote monitoring and configuration is shown in Figure 16. This approach will allow for “simple” remote configuration and consists primarily of general purpose controllers that are located at and connected to the HVAC devices (primarily rooftop units) and possibly lighting loads. This configuration also allows for communicating programmable thermostats to control the HVAC devices instead of the general purpose controllers (shown connected to the RTUs). The configuration can also include controllers for small miscellaneous loads (plug loads and exhaust fans). Temperature sensors connected to the general purpose controllers are located in designated occupied spaces in the building (office or open area). The small load controller may be connected to plug load devices. These plug loads may be located in the spaces (outlets or electrical distribution panels), which are primarily for lighting or special process loads (like hot water tanks, hot water pumps or lighting loads), or they may be up in ceiling spaces or on roofs (primarily for exhaust fans or lighting fixtures). As in option #1, the control of lighting loads may be achieved with local independent occupancy sensors; less commonly in small buildings, standalone contactor timer systems or lighting automation panels may be used for schedule-based on-off control, as described in Appendix B. While improving the energy efficiency of the building, this solution can also be leveraged to make the building and its systems more grid responsive.
Control functions are distributed primarily amongst the programmable general purpose controllers. There may be some “global” functions that come from the web service. These functions may include (but are not necessarily limited to) things like alarm management (alarm monitoring and alarm notification), data management (trending, storage and retrieval), equipment scheduling, holiday scheduling and time synchronization actions.
This configuration may include a few HVAC systems (five or less). These systems are assumed to be primarily HVAC rooftop configurations (multi-stage heating and cooling) that may also include economizer functions (integrated or standalone). The configuration may be dealing with a few small load controllers. All of these control devices are connected to a common communications bus (wired or wireless or both), inside the building. As previously described, the dashed lines in Figure 16 indicate that the communications between the controller and the Cloud service can either be wired or wireless.
32
Figure 16: Simple BASs with Local Controls but Remote Configuration Option for Small Buildings
Communications to all controllers should be based on an open standard. The schematic shows that the devices leverage existing Internet connection in the small building. If the controllers cannot use existing Internet connection, an additional Internet gateway with broadband wired or wireless will be needed. When specifying such a system, it is always important to fully document the installation and startup of all hardware/software functions so it will be easy to implement and troubleshoot for correct operations (startup and persistence).
Programmable general purpose controllers that support multiple configurations (heat pump, multi-stage heating and cooling, with or without economizer integration) shall be preferred over multiple product offerings that are designed for only one type of HVAC system or subset of HVAC systems. This alleviates future problems that arise from multiple HVAC rooftop unit vendor configurations at the building or from replacement of one type of HVAC system with a different one (different vendor or switch from multi-stage to heat pump or vice versa). More detailed requirements of these general purpose controllers are provided in the next section.
Configuration of all general purpose control parameters shall be configured from either a laptop computer connection to the general purpose controller or remotely via web access/web page service into the local controller. Different levels of program access shall be required for each general purpose controller. Basic access shall be provided to allow for local occupant overrides and other non-critical functions. Higher level access (via proper password access) shall be provided for service/maintenance personnel or other designated staff. This higher level access shall include access for schedule changes and equipment protection parameters (minimum on-off short-cycle parameters and/or similar functions). In lieu of web services access or laptop computer access, the controller may have a manual bypass capability that provides the service provider with the means of testing basic HVAC equipment functions (1 to 2 stages of heating/cooling and economizer actuator function).
Remote configuration and monitoring shall be provided for all controllers. This includes tracking HVAC equipment performance issues (such as dirty filters, hours of heating and cooling operations with
33
local notification for maintenance inspections) and can include storage of time-stamped alarms (high/low temperatures, etc.).
Remote monitoring or control (via web page, Internet connection – wired or wirelessly) is required and greatly assists in ensuring persistence and sustainability of energy savings and proper, efficient equipment operations. This assurance comes primarily from reliable alarm and data management capabilities.
4.3 BASs for Medium-Sized Commercial Building
As noted in the previous section, the total energy consumption of a medium-sized commercial building is higher than a small commercial building. So, the BAS solution for a medium-sized building can be a slightly higher cost than the small building. However, the building automation solutions presented for small-sized buildings can also be scaled to work with medium-sized buildings. The proposed solution for the medium-sized building, shown in Figure 17, will work in both existing and new buildings. While improving the energy efficiency of the building, this solution can also be leveraged to make the building and its systems more grid responsive. In this configuration, the building will have a central master controller that coordinates a number of specific device controllers in the building.
Like small buildings, the energy consumption in the medium-sized buildings is dominated by HVAC and lighting loads, which consume over 50% of the total energy consumption and over 70% of electricity consumption. The medium-sized building configuration consists primarily of general purpose controllers that are located at and connected to the HVAC and lighting systems. They can also include controllers for small miscellaneous loads (plug loads, small exhaust fans, hot water tanks, pumps, etc.). Temperature sensors connected to the general purpose controllers are located in designated occupied spaces in the building (office or open area). The lighting controller may be the same general purpose controller or a dedicated lighting controller (or a hybrid). The small load controller may be connected to plug load devices. These plug loads may be located in the spaces (outlets or electrical distribution panels) that are primarily for special process loads (like domestic hot water tanks, domestic hot water pumps or lighting loads), or they may be up in ceiling spaces or on roofs (primarily for exhaust fans or lighting fixtures).
34
Figure 17: BASs with Local Control and Configuration and Local or Remote Monitoring for
Medium-Sized Buildings
The communication between individual controllers and the master controller and between sensors and controllers can be wired or wireless. Individual controllers do not need to communicate to the Cloud service directly. Access to external information in the controllers is primarily through the master controller. Monitoring can either be via local or remote monitoring (web page, Internet connection – wired or wirelessly). Local monitoring, configuration and analysis (data and alarm management) is the recommended option for medium-sized buildings. Monitoring capabilities greatly assist in ensuring persistence and sustainability of energy savings and proper, efficient equipment operations. This assurance comes primarily from reliable alarm, data management and actionable intelligence creation capabilities.
Control functions are distributed primarily amongst the programmable general purpose controllers, but there will (of necessity) be some “global” functions that come from a local, on-site master controller. This type of control may be viewed as a “master/slave” or “supervisory” management service that includes site configuration of individual controllers, as well as alarm and data management (local data storage, etc.). Global functions may also include (but are not necessarily limited to) alarm management (alarm monitoring and alarm notification), data management (trending, storage and retrieval), equipment scheduling, holiday scheduling and time synchronization actions. All of these control devices shall be connected to a common communications network (wired or wireless or both) inside the building. Communications to all controllers should be based on an open standard. When specifying such a system,
35
it is always important to fully document the installation and startup of all hardware/software functions so it will be easy to implement and troubleshoot (startup and persistence).
This configuration will generally be dealing with a significant number of HVAC systems (more than five), a number of lighting controllers and other special purpose load controllers. In existing medium-sized commercial buildings, when lighting control is implemented, lighting automation panels, also called lighting relay panels or lighting control panels are a common means of implementing schedules. Panel-based controls may also support the integration of occupancy and photo-sensors for sensor-based on-off control. Panel-based controllers may be integrated with BASs (e.g., via BACnet) or may be networked with one another using proprietary protocols. Common lighting control architectures are detailed in Appendix B, including schematic diagrams.
The HVAC systems can include rooftop configurations (multi-stage heating and cooling) that may also include economizer functions (integrated or standalone), split systems (indoor fan unit with outdoor condenser), larger air handling units (primarily packaged), zone terminal boxes or zone HVAC systems (like fan coils or induction boxes, etc.) and potentially small chillers and hot water boilers with dedicated pumping systems. The configuration may be dealing with a few small load controllers.
Programmable general purpose controllers that support multiple configurations (heat pump, multi-stage heating and cooling, with or without economizer integration, terminal boxes, air handlers, etc.) over multiple product offerings that are designed for only one type of HVAC system are probably not realistic for the size and potential complexity of medium buildings, especially when designed with multiple and varying HVAC systems. Determination of giving preference to controllers that support multiple configurations over multiple product offerings (because of varied HVAC systems that are not conducive to one controller option) will be market and building system driven.
Configuration of all general purpose control parameters shall be configured from a local workstation or a local laptop computer connection to the general purpose controller. Remote access via web access/web page service into the local controller is also encouraged, to provide for remote service and troubleshooting.
Different levels of program access shall be required for each general purpose controller. Basic access shall be provided to allow for local occupant overrides and other non-critical functions. Higher level access (via proper password access) shall be provided for service/maintenance personnel or other designated staff. This higher level access shall include access for schedule changes and equipment protection parameters (minimum on-off short-cycle parameters and/or similar functions).
Remote configuration and monitoring may be provided for all controllers. The programmable controller may have a bypass/override feature that enables testing basic HVAC equipment functions. Analytics and actionable intelligence can be created, either locally or remotely or both. This includes tracking HVAC equipment performance issues such as dirty filters, hours of heating and cooling operations with local notification for maintenance inspections and can include storage of time-stamped alarms (high/low temperatures, etc.). The detailed capabilities of the general purpose HVAC controller, load controller and lighting controller are given in the next section.
36
5.0 Requirements of the Devices Used to Monitor and Control Small-and Medium-Sized Commercial Buildings
In this section the requirements/capabilities of various devices used to monitor and control small-medium-sized commercial buildings are described.
5.1 Gateway Requirements
The first example described previously (small building, simple local configuration option #1) uses a gateway device to integrate the various end-use controls, provides access to external data from the Internet and provides a means to monitor operations to ensure persistence. In addition, this gateway device also will provide and enable communications between various controllers (thermostats, lighting controller, general purpose controller, etc.) installed in a small commercial building. The gateway should have the following capabilities:
• In the near-term (less than 3 years), most buildings will use off-the-self components, so the gateway devices should ensure connectivity of different controllers with different protocols (BACnet, LON, MODBUS, etc.). In the long-term (greater than 5 years), with concerted effort by DOE and others, a new open standard and plug-n-play type controls are possible, then the gateway will need to support the new control paradigm.
• Because control functions are distributed primarily amongst the end-use controllers. However, there may be some “global” functions that come from the web service. These functions may include equipment scheduling, holiday scheduling and time synchronization actions.
• Ability to make changes to the control parameter; for example, changing thermostat set point or schedule.
• Ability to access control settings, values of various sensors connected to thermostats and controllers and alarms from various devices and provide such information to local/remote monitoring devices (computer/server).
• Manage all communications (bandwidth, speed, wired/wireless, etc.).
• Manage data routing from external sources to the end-use controller; for example, DR, price, reliability or ancillary service signals from the utilities, independent system operators or third parties; and weather data from weather services, etc.
• Manage data routing (servers, Cloud, etc.).
• Manage alarm routing (email, text messaging, etc.).
• Security via password authorization (recommend three levels for basic, advanced and administrative functions).
5.2 Master Controller Requirements
The third example described previously (Building Automation System) uses a master controller to control various end uses, integrate end-use controls that are independently controlled, provides access to external data from the Internet and provides a means to monitor operations to ensure persistence. In
37
addition, the master controller will provide global management functions with all building controllers. These building controllers could potentially include thermostats, lighting controllers, RTU controllers and general purpose controllers, etc. The master controller should have the following capabilities:
• In the near term (less than 3 years), most buildings will use off-the-self master controller, so the master controller should ensure connectivity with different controllers with different protocols (BACnet, LON, MODBUS, etc.). In the long-term (greater than 5 years), with concerted effort by DOE and others, a new open standard and plug-n-play type controls are possible, then the master controller will need to support the new control paradigm.
• Designed to have IP communications capabilities (wired/wireless, support of both preferred).
• Program/configuration capability of all parameters shall be in the master controller from the local display with keypad, touchscreen or laptop (for standalone mode).
• Manage alarm setting/determination for equipment and related outcomes (temperatures, humidity, filters, runtime, cycling, etc.).
• Manage date/time synchronization to connected controllers (including daylight saving time changes, etc.).
• Manage equipment (connected load) schedules for “on-off” scheduling.
• Designed to access all building controllers (thermostats, lighting controllers, general purpose controllers, etc.) to allow remote configuration of most (if not all) controller configuration parameters (set points, schedules, limits, timer values, etc.). Remote configuration can be direct access or via “pass-through” mode from a laptop or desktop computers.
• Designed to provide limited data (trend and alarm) storage for retrieval; provide the ability to retrieve stored data as well as any other information available in the master controller (to external servers or Cloud services, etc.).
• Ability to do limited algorithms (math, side loop, PID functions, etc.).
• Ability to perform limited fault detection diagnosis (FDD) via embedded algorithms.
• Ability to receive signals from external sources and act on them; for example, DR, price, reliability or ancillary service signals from the utilities, independent system operators or third parties; and weather data from weather services, etc.
• Security via password authorization (recommend three levels for basic, advanced and administrative functions).
5.3 Communication Thermostat Requirements
The example control configuration described previously uses communicating thermostats to control HVAC units. Communicating thermostats will provide direct control of the HVAC systems (RTUs, heat pumps and similar type HVAC systems) that are installed in the buildings. These thermostats should have the following capabilities:
• The thermostat support wired and/or wireless communication capability (preferably both).
38
• The thermostat will be designed to use an industry-recognized communication protocol (BACnet, LON, MODBUS for wired; ZigBee, EnOcean for wireless, IP etc.).
• Program/configuration capability of all parameters shall be in the thermostat from the local display with keypad, touchscreen or laptop computer (for standalone mode).
• Must be capable of accepting set point changes, schedule changes and time synchronization commands from gateway/master controller, if connected to them.
• Preferably also support web services.
• Occupancy scheduling capability with the ability to make changes locally at the thermostat.
• Holiday scheduling capability with the ability to make changes locally at the thermostat.
• Occupied and unoccupied set points capability with the ability to make changes locally at the thermostat.
• Occupancy sensor capability with the ability to make changes locally at the thermostat.
• Occupancy override capability (push button and/or web service) with the ability to make changes locally at the thermostat.
• Optimal start, adaptive recovery, efficient setback recovery or similar capability with the ability to make changes locally at the thermostat.
• Programmable alarm (temperature and/or equipment) capability with local alarming and the ability to make changes locally at the thermostat.
• For configuration where the thermostat is not connected to either the gateway device or master controller, it should have the ability to receive signals from external sources and act on them; for example, DR, price, reliability or ancillary service signals from the utilities, independent system operators or third parties, etc.
• Multiple zone temperature sensor input (average, high or low) capability (wired/wireless).
• Economizer capability (with demand controlled ventilation capability) with the ability to make changes locally at the thermostat.
• Spare digital and analog inputs (two each) for monitoring/diagnostics capability.
• Outdoor air temperature input capability (wired, wireless or web fed).
• Alarm parameters for temperatures (low/high).
• Alarm parameters for equipment runtime hours (filter check, compressors, etc.) or equipment performance issues (low Delta T, excessively low or high discharge temperatures, etc.).
• For configuration where the thermostat is not connected to either the gateway device or master controller, it should have the ability to send email or text upon alarm activation via communication service.
• Security via password authorization (recommend three levels for basic, advanced and administrative functions).
39
5.4 Lighting Controller Requirements
Lighting controllers will provide direct control of building lighting systems, including hallway lighting, office lighting, common space lighting, outside lighting and other designated lighting loads that are installed in a building. These lighting controllers should have the following capabilities:
• The lighting controller will be a communicating controller with wired/wireless capability (preferably both).
• The lighting controller will be designed to use an industry-recognized communication protocol (BACnet, LON, MODBUS for wired, ZigBee, EnOcean for wireless, etc.).
• Program/configuration capability of all parameters shall be in the thermostat from the local display with keypad, touchscreen or laptop computer (for standalone mode).
• Preferably also support web services.
• Occupancy scheduling capability with adjustable parameters (at least 2 “on” and 2 “off” schedules/day).
• Holiday scheduling capability with the ability to make changes locally at the controller
• Occupied and unoccupied set points capability with the ability to make changes locally at the controller.
• Occupancy sensor capability with the ability to make changes locally at the controller.
• Occupancy override capability (push button and/or web service) with the ability to make changes locally at the controller with automatic “sweep” off when this capability is provided.
• Day lighting control capability for perimeter spaces with window/natural day lighting (but could include interior spaces with atriums, skylights, etc.) with the ability to make changes locally at the controller.
• Control outside lighting via astrological clock and photocell with the ability to make changes locally at the controller.
• For configuration where the lighting controller is not connected to either the gateway device or master controller, it should have the ability to receive signals from external sources and act on them; for example, DR, price, reliability or ancillary service signals from the utilities, independent system operators or third parties, etc.
• Alarm parameters for equipment runtime hours (excessive light circuit “on” hours, etc.) or equipment performance issues (reduced light levels or increased output for dimming systems with light level sensors).
• For configuration where the lighting controller is not connected to either the gateway device or master controller, it should have the ability to send email or text upon alarm activation via communication service.
• Security via password authorization (recommend three levels for basic, advanced and administrative functions).
40
5.5 General Purpose Controller Requirements
The general purpose controller will provide direct control of selected end uses in a building including designated lighting loads, general purpose exhaust fans (bathrooms, etc.), domestic hot water systems, rain gutter heaters and other small loads. These general purpose controllers should provide the following capabilities:
• The general purpose controller will be a communicating controller with wired and/or wireless capability.
• The general purpose controller will be designed to use an industry-recognized communication protocol (BACnet, LON, MODBUS for wired, ZigBee, EnOcean for wireless, etc.).
• Program/configuration capability of all parameters shall be in the general purpose controller from the local display with keypad, touchscreen or laptop (for standalone mode).
• Preferably also support web services.
• Occupancy scheduling capability with adjustable parameters (at least 2 “on” and 2 “off” schedules/day).
• Holiday scheduling capability with the ability to make changes locally at the controller.
• Occupied and unoccupied set points capability with the ability to make changes locally at the controller.
• Occupancy sensor capability with the ability to make changes locally at the controller.
• For configuration where the general purpose controller is not connected to either the gateway device or master controller, it should have the ability to receive signals from external sources and act on them; for example, DR, price, reliability or ancillary service signals from the utilities, independent system operators or third parties, etc.
• Security via password authorization (recommend three levels for basic, advanced and administrative functions).
5.6 DR and Ancillary Service Requirements of HVAC Loads
The gateway/master controller should facilitate the following features to support DR and ancillary services:
• Widen thermostat dead bands per user/occupant definition for up to 2 hours (or as defined).
• Switch from “continuous run” mode to “auto” mode (residential mode).
• Limit two-stage HVAC equipment to one stage for up to 2 hours (or as defined).
• Shut down HVAC units for up to 1 hour in alternating (rolling) fashion (or as defined).
• Define “non-essential” HVAC units that can be shut off for extended periods of time (until temperature reaches set back threshold values). Suggest consideration be given to units serving hallways, storage areas, bathrooms (or as defined by building owner).
41
In cases where the thermostat is not connected to the gateway/master controller, it will support some but not all of the DR features noted above.
5.7 DR and Ancillary Service Requirements of Lighting Loads
The gateway/master controller should facilitate the following features to support DR and ancillary services:
• Turn off hallway lights (emergency lights remain on).
• Turn off all interior lights (emergency lights remain on, occupants use task lighting, etc).
• Turn off selected lighting circuits for up to 1 hour in alternating (rolling) fashion (or as defined).
• Reduce light levels where dimming capability exist.
In cases where the lighting controller is not connected to the gateway/master controller, it will support some but not all of the DR features noted above.
5.8 DR and Ancillary Service Requirements of Other End-Uses
The gateway/master controller should facilitate the following features to support DR and ancillary services:
• Turn off small loads (bathroom exhaust fans, rain gutter electric heaters, buried parking lot/sidewalk electric heaters, electric hot water tanks, etc.).
All devices/controllers that are supporting DR and ancillary services should send out email, text or phone message to building occupants (request that they turn off office lighting and/or plug loads, etc.) at the start and end of the event. When event ends, determine recovery actions (quick recovery may negate demand reduction actions).
5.9 Data Collection and Archiving Requirements
One key issue in advance control systems is the need to have many sensing and actuation elements (i.e., transducers) that are tied into a single system in a variety of ways (Fraden 2010). The device that connects to many different devices and combines that information is called a data aggregator.
The term data aggregator is not a standard industry term, and the functionality encompassed by the term actually corresponds to functionality beyond that of a typical physical box. In this document, the functions described above are generally called data aggregators, and the specific functionality being discussed will be identified. In conversation with other practitioners in research or industry, the particular functionality and form factor (software on a general server versus a physical box) should be discerned from the context or specifically defined, to ensure all parties understand the terms in use.
Common data aggregation scenarios showing network-based and legacy aggregation to a primary data aggregator as well as a case where a local aggregator makes control decisions for a lighting system
42
and provides summary data to the primary aggregator. The external network interface connects the data aggregator with applications and systems accessible over the traditional IT network.
Figure 18 illustrates two data aggregator functional examples:
1. Multiple sensors and actuators are connected to a single unit (possibly for local control) (left side of the figure).
2. Many data streams (in any format—analog, digital, etc.) are collected, stored, summarized, and perhaps even displayed to users (right side of the figure).
In the most basic sense, data aggregation simply means combining multiple measurements into a summary form. This can be as simple as tabulating data and storing it in a file or database, or as complex as taking many measurements from different sensing domains, data formats, and locations and calculating summary statistics. The typical data aggregator installed at a site is a box containing hardware and software components. Some of the software may also reside on a server on site or in the Cloud. Elements of the two types of aggregation shown in Figure 17 overlap with other sensor system characteristics. The overlap areas are in the general areas of “signal conversion to data” and “communications and networking.”
RDBMS: Relational database management system; TSDB: Time series database
Figure 18: Examples of Data Aggregation
An example of the first case above is a sensor unit that has inputs for low-voltage, occupant controls, light levels, and occupancy sensors while also having a lighting control unit. This system receives signals from the three sensors and locally makes decisions regarding the appropriate light state and level, while relaying summary information over a network interface (e.g., BacNET, Ethernet). Although this type of aggregation is present in some digital control systems, it is simple and relatively uncommon.
Systems fulfilling the second functional example, which will generically be called data aggregation from this point forward, combine many data streams from different sensors or sensor and control systems into a single, common data format. Some of these streams may be carried over legacy and new network connections, and others are analog or binary valued variables measured at the aggregator. The data
43
aggregator may include data storage and generate summary statistics, or it may simply pass the combined, reformatted data on to another system for storage and analysis.
A common example of data aggregation is one that connects different building subsystems that use different standard and proprietary protocols so that all of these subsystems can be managed as a single system. This type of aggregator consists of many components, including the boxes with the physical interfaces, the software and network architecture for managing these boxes, and a centralized system with data storage, analysis, visualization, and control features.
The data storage component typically does not reside on the individual aggregator box but on a server. Figure 18 shows the full architecture for a data aggregator system. Many types of data (e.g., power, temperature, humidity, occupancy) from many different locations are brought together at relatively high rates and stored. The data aggregator may, for example, pre-compute hourly summaries of power data or zone average air temperature, to ensure that the user or energy information system (EIS) can access the desired summary data rapidly.
Figure 19: Architecture for a Full Data Aggregator System
All of the capabilities discussed above require computation, and most of the devices providing these functions use an embedded processor for this function. Embedded processors, sometimes called microcontrollers, are general purpose processors with peripherals that provide specific functionality useful in embedded systems (Ganssle 2008). Examples of peripherals include analog-to-digital converters, various wire line transceivers (e.g., RS-232), encryption accelerators, digital-to-analog converters, comparators, and amplifiers. Unlike other processor types, embedded processors often contain all of their memory on-chip or provide easy access to simple external memory peripherals. The processors are also optimized for performance under strict energy constraints and typically operate with limited memory compared to their standard counterparts.
The interfaces to the physical systems need to be located at the site, but the archive (storage) can be located at the site or in the Cloud. The services and applications shown on the right (of Figure 17) are not strictly part of a data aggregator and are not discussed in depth in this section. However, the link to these services is discussed5.
5 Dawson-Haggerty, "sMAP 2.0: Integrating and Managing Physical Data," LoCal Retreat, Jan 2012. http://local.cs.berkeley.edu/wiki2/index.php/File:Local-winter-smap-2012.pptx
44
5.10 Grid Integration Requirements
This section provides a short description of previous research on controls to provide demand response and grid integration systems in small commercial buildings. The majority of small commercial facilities in these studies are small offices, restaurants, and retail buildings with single-zone packaged units servicing most of their HVAC needs. These buildings typically have single- or multi-zone rooftop units with manually controlled magnetic ballast fluorescent tube lighting (Kiliccote et al. 2009). Previous work by Lockheed (2006) noted that DR technology for small commercial buildings should be:
• capable of automatically receiving a signal from the utility indicating a DR event
• able to characterize the magnitude of change in demand as a result of responding to the DR signal
• reliable, with a means of verifying operation through low-cost, non-intrusive means
• capable of delivering significant load reductions
• cost-effective (economical)
• non-disruptive during operation and minimally disruptive during installation.
The work reported by Lockheed (2006) emphasized direct load control instead of the approach outlined in this report, where sites receiving a DR signal default into a previously defined strategy unless the occupants choose to opt out via a local interface.
Herter et al. (2009) showed that incentives such as rebates or special time-of-use pricing, coupled with energy efficiency consultation (specific to a small commercial site in advance of a summer DR program) could be beneficial. Herter’s work (2009) showed that incentives and appropriate equipment can yield 20% or greater energy savings, with the potential for an additional 14 to 20% demand savings during DR events. This held true for all site types except restaurants. Herter (2009) also found that HVAC units that are inherently undersized for the facility could not be expected to provide demand savings during DR events.
In a study sponsored by the Pacific Gas and Electric Company (PG&E), the open automated demand response communications technology (OpenADR) was used to deliver DR event signals to devices that initiate pre-programmed DR strategies (Piette et al. 2009). Essentially, the OpenADR implements Auto-DR (automated DR) through continuous, secure, standardized, open communication signals published to the Internet, where various bridge devices can acquire and act on them. OpenADR has been proven as an effective way to communicate price and reliability information to large commercial buildings because of the ability to use existing BASs to automate the DR control strategies. A DR signal is published from the demand response automation server (DRAS) to sites using OpenADR by the utility or independent system operator (ISO). These signals are received by the site-based client. Clients then trigger pre-programmed DR strategies. The client’s user interface provides the end user a way to opt out of responding to an event when needed. OpenADR version 2.0 is being formalized through the U.S.
45
national smart grid standards process of a national consensus standard for DR automation, and compliance testing will be conducted through the OpenADR Alliance (OpenADR Alliance 2012)
For small commercial buildings, there are three basic models for implementing DR (Page et al. 2011):
• Shed strategy is implemented completely within the load controllers themselves (i.e. within the lighting or HVAC controls) (see Figure 20).
Figure 20: DR Strategy in Load Controller
• Use of a centralized controller within the facility (BAS lite) to program and control the shed
strategies for the entire facility (see Figure 21).
Figure 21: DR Strategy in BAS (or EMCS)
• Shed strategy is implemented completely outside the facility. This is the model used for direct
load control programs by utilities and managing load reductions for customer groups by aggregators (see Figure 22).
Figure 22: DR Strategy External to the Facility
The difference between the three methods is the location where the price signals (DR signals) are converted into DR strategies (controls signals or commands). There are variations in implementation for each of the three methods that make up the framework for technology evaluation. This section describes each model, implementation variations and describes the pros and cons of each implementation. At its
Facility
LoadBridge Device or Gateway
(may be located inside or outside of a facility)
DR Strategy
DR SignalsPrIce and ReliabilitySignals
Facility
Load
EMCS Lite
DR Strategy
PrIce and ReliabilitySignals
Load Control
Commands
Facility
LoadGatewayDR
strategy
LoadControl
Commands
Load Control
Commands
46
core, there is a DR automation server that publishes prices and reliability signals. At each facility, there are software or hardware clients that poll the information and bring it into the buildings. There are three types of clients: smart, simple and bridge. A smart client is any hardware or software client that can take the entire information model, parse and use it to call the necessary programs and strategies to activate DR strategies. A simple client is any hardware or software client that listens to a portion of the information model where the information is presented in simpler (or mapped) manner. A bridge client translates OpenADR information into device-specific and/or communication-specific information. The bridge client is conceived to be used to send information via broadcast to thermostats and to allow third party entities (e.g., aggregators) to map information to proprietary networks.
Figure 20, Figure 21 and Figure 22 show that the nature of the signals sent to the facility is related to where the DR strategy is implemented. In cases where the DR strategy is in a BAS lite device or in the load controllers, a DR signal containing business level information (i.e., prices or shed levels) may be sent to the facility. In the case where the DR strategy is implemented outside of the facility, load control commands are sent. For the purposes of this report, the first two methods are considered equivalent because they both involve the same type of DR signal being sent to the facility.
In the first model (Figure 20), standalone communicating load controllers contain the DR strategy, which is implemented at the facility, and the controllers are able to receive OpenADR signals. This method may or may not require a bridge client that requires some level of configuration to distribute messages. If a bridge client is not required, then it needs enough intelligence at the standalone load controllers to accept DR event information from the DRAS. An example of a device that fits in with this framework is a programmable communicating thermostat (PCT). In this model, each load controller has to be pre-programmed. While the DR strategy implemented at the standalone load controllers grant increase granularity of controls, it is difficult if not impossible, to implement system-wide shed strategies unless they are centralized. In 2006, Lawrence Berkeley National Laboratory (LBNL) collaborated with two Whole Foods Market stores and installed client logic with integrated relay (CLIR) boxes to control lighting in the buildings. One installation issue was the spacing of loads. When the loads to be controlled are further away from each other, the installation may require more than one client device for each facility, thus possibly increasing the cost of implementation.
In the second model (Figure 21), BAS lite provides centralization of controls. It is defined as a type of BAS controller that is designed specifically for the type of loads and logic that are used for DR applications in small commercial buildings. Thus, by definition it should be easy to program and not necessarily rely on a computer to display a user interface and pre-program control strategies. It should also be able to receive standard DR event information such as OpenADR signals. The existence of a BAS Lite at a small commercial building enables the customer to design and implement shed strategies for their own buildings thus being able to make decisions about the site’s control strategies including opting out of an event.
For the last model (Figure 22), where the DR strategy is completely implemented outside of the facility (e.g., in the Cloud), the facility does not receive any price or reliability signals, just control and set point signals. Signal conversion from prices to DR strategies takes place somewhere between when the utility sends the price signals and the site receives commands. One way to do this is that all site specific DR strategies are implemented in an external server. This requires that the external server have generic device models (a description of inputs and outputs) for each load controller. Depending upon the DR strategy, it may require that certain state, or systems status, information from the facility to be fed back
47
into the external server. In the case of retail or fast food chains, a cookie cutter approach may simplify DR strategy implementation and lower the cost of installations. While this model allows for minimum installations at each site, the price paid for such a system is that control of a facility is relinquished to an external server and DR strategy decisions are no longer made at each site and that opting out of an event may be problematic. This is a model closely followed by aggregators participating in DR programs in California. However, instead of using open communications with the end-use, they send command and control signals out to the facilities that participate in DR programs.
48
6.0 Installed Cost of the Control Systems for Small- and Medium- Sized Commercial Buildings
Many commercial buildings lack proper controls because building owners either perceive them to be costly or are not aware of the benefits of installing controls. Properly implemented building controls can save energy and improve comfort as seen from the case study, which showed 30% reduction in annual energy consumption. There are a number of studies that attribute energy savings from buildings controls to be in the range of 10% to 30% (Ardehali and Smith 2002).
Because much of the buildings industry is driven by first cost, an estimate of the installed cost of building controls will be needed to convince building owners and operators. However, estimating the installed cost of the control system on a typical building would require making a number of assumptions on the size and type of building, number of HVAC systems and other controllable loads, etc. An alternate approach is to assume the annual energy savings attributed to building controls and then estimate the annual cost savings. Using the annual cost savings and assuming a typical simple payback (e.g. 3 years), the total installed cost of building controls that the building owner can afford can be estimated. Because the cost of controls varies by the size of the building, the estimated installed cost can be normalized by area. Also, because the energy (electricity and natural gas) cost varies by region, the estimated cost of controls is for a range of energy costs.
In this section, normalized installed cost of building controls the building owner could pay is presented. The normalized installed cost of building controls is estimated for a range of EUIs (energy use intensity) (50 kBtu/sf/hr to 150 kBtu/sf/yr), range of percent energy savings (10% to 30%) and range energy cost (0.05 $/kWh to 0.20 $/kWh electricity and 5 $/MMBtu to 20 $/MMBtu natural gas). Across these scenarios, the smallest cost annual savings are approximately 4 to 5 cents per square foot, and the largest are approximately $1.62 per square foot.
The total EUIs of a typical small- or medium-sized commercial building is approximately 80 kBtu/sf/yr; 44 kBtu/sf/yr and is derived from electricity consumption and the remaining is mostly natural gas (it also includes other miscellaneous fuels other than electricity). So, in estimating the energy cost, it was assumed that 55% of the consumption is from electricity use (ratio of 44 to 80), and the rest is from natural gas. The electricity cost is assumed to be a blended cost, which included the cost of energy and peak charges.
Appendix E includes a series of graphs that show the annual normalized energy cost savings as a function of EUIs for a range of electricity prices, natural gas prices and a range of expected savings. Two representative graphs are used in this section to illustrate their use. For example, if the EUI of a buildings is 100 kBtu/sf/yr, the electricity price is 0.1 $/kWh, natural gas price is $5/MMBtu and the anticipated savings for use of building controls is 10%, from Figure 23, the annual normalized energy cost savings are approximately 0.2 $/sf. Under these assumptions, for a 10,000-sf building, the total annual savings will be approximately $2,000. If the building owner is looking for a 3-year simple payback, he could afford to invest $6,000 to install controls without any utility incentives. If the utilities provide incentives through their demand side management programs, the installed cost can be higher and still have a 3-year payback. Likewise on the high end, if the EUI of a building is 100 kBtu/sf/yr, the electricity price is 0.2 $/kWh, natural gas price is $10/MMBtu and the anticipated savings for use of building controls is 30%, from Figure 23, the annual normalized energy cost savings are approximately 1.09 $/sf. Under these
49
assumptions, for a 20,000-sf building, the total annual savings will be approximately $21,800. If the building owner is looking for a 5-year simple payback, he could afford to invest $109,000 to install controls without utility incentives. For other EUIs, electricity rates, natural gas rates and energy savings scenarios, refer to the graphs in Appendix E.
Figure 23: Annual Normalized Cost Savings as a Function of EUIs for Various Electricity Prices Assuming 10% Reduction in Energy and $5/MMBtu
Figure 24: Annual Normalized Cost Savings as a Function of EUIs for Various Electricity Prices Assuming 30% Reduction in Energy and $10/MMBtu
0.00
0.20
0.40
0.60
0.80
1.00
1.20
1.40
1.60
1.80
2.00
0 50 100 150 200
Annu
al N
orm
alize
d Co
st S
avin
gs ($
/sf)
EUI (kBtu/sf)
At 10% Energy Savings and $5/MMBtu Heating Cost
Savings at ElectricityCost $0.05/kWh
Savings at ElectricityCost $0.10/kWh
Savings at ElectricityCost $0.15/kWh
Savings at ElectricityCost $0.20/kWh
0.00
0.20
0.40
0.60
0.80
1.00
1.20
1.40
1.60
1.80
2.00
0 50 100 150 200Annu
al N
orm
alize
d Co
st S
avin
gs ($
/sf)
EUI (kBtu/sf)
At 30% Energy Savings and $10/MMBtu Heating Cost
Savings at ElectricityCost $0.05/kWh
Savings at ElectricityCost $0.10/kWh
Savings at ElectricityCost $0.15/kWh
Savings at ElectricityCost $0.20/kWh
50
7.0 Control Retrofit of a Medium-Sized Commercial Building: Case Study
In many cases, retrofitting an existing buildings or implementing building controls in small- and medium-sized commercial buildings will be a cost-effective solution. However, many building owners, managers and operators are not aware of the economics of such an implementation. In this section, a case study of a controls retrofit is described. The case study includes the implementation details and installed costs as well as savings based on whole building energy measurements before and after the retrofits were made.
Three identical medium-sized leased office buildings were upgraded from standalone thermostat control design, to a building automation system (BAS) control design (similar to the configuration defined in the section titled, Building Automation System for Medium-Sized Commercial Building). These office buildings (all approximately 20,000 sf each) are geographically located adjacent to each other in a business park located at the north end of the City of Richland, Washington. The three buildings are part of a four-building complex, and they include Building 2, Building 3 and Building 4. The fourth office building (Building 1) which is also part of this complex (located on the same city block), was not included in the controls upgrade.
The details of the case study including the reasons for performing the BAS controls upgrade, the energy performance of pre- and post-upgrade and the impacts (both energy and comfort) of upgrade are discussed in more detail in Appendix D.
Why was this BAS upgrade performed? Prior to the BAS upgrade, the primary problem encountered by the operational staff was numerous occupant complaints related to comfort (too hot or too cold). The second problem was high energy consumption and cost. BAS control updates were pursued as a solution to address both of these problems. As will be shown, by integrating the building’s HVAC control into a BAS infrastructure, both occupant comfort problems and high energy costs were significantly reduced.
7.1 Summary of the Building Description
The details of the building description are described in Appendix D and summarized in this section. The major building characteristics for Building 4 are:
• 20,530 sf., single story on concrete slab office building (designed for between 80 and 90
occupants), 11 rooftop units (all electric, all but one is heat pump).
• 36 perimeter offices, 44 interior offices, 3 conference rooms, 1 lunch room, 1 lobby, 4 bathrooms, 2 local area network (LAN) rooms and one mechanical/electrical room.
• The window/wall ratio is approximately 17%, and the wall perimeter is 680 linear feet.
Pre-upgrade HVAC systems and controls description:
• 11 rooftop units (most heat pump design, with second stage electric heat).
• Programmable thermostats with limited remote hardwire temperature sensor averaging.
51
• No holiday scheduling or optimal start sequencing.
• No networking capabilities (to share outdoor air temperature value between thermostats, scheduling, etc.)
• No remote diagnostic, alarming or trending capabilities.
• Schedules for each rooftop unit in the thermostat were generally set too early (between 3 a.m. and 5 a.m.) and were generally shutting off too late (between 7 p.m. and 9 p.m.). This was done as a “just in case” action when weather was more severe, or units were not being maintained properly.
• Weekend scheduling configured for 4 to 8 hours (another “just in case” action if it was too warm or too cold outside).
BASs was installed in 2010. Building 4 HVAC controls BAS upgrade description:
• All rooftop units were heat pumps (except for one). There was a dedicated rooftop “DX (direct expansion) cooling only” unit installed to serve a high heat generation space (primarily computer equipment and LAN closet space).
• A new thermostat that communicates with a BAS head-end was installed at each of the existing thermostat locations, to allow for networking and communications with the BAS “network controller” (NC), which functioned as a master controller (similar to the one shown in Figure 17).
• A wireless temperature sensor monitoring network was created and installed throughout the building. This network is truly “wireless” and consists of temperature sensors located in more than 50% of the office spaces and also includes wireless sensors in most of the rooftop units so temperatures in the mixed air, discharge air and return-air spaces can be monitored. This provides for additional trending, alarming and diagnostic capabilities (such as calculated outdoor air fraction to help determine if economizers are working properly, etc.).
• The communications network allows for sharing and configuration of common data points like outside air temperature, occupancy and holiday scheduling, data analysis of the different rooftop unit’s system performance via trend logs, historical data and alarming.
• Whole building electrical metering was installed as part of the BAS upgrade scope. The electrical meter was integrated into the BAS and provides real-time and historical data analysis of the building.
• In most cases, each of the existing rooftop units has a built-in economizer section with integrated economizer controller and actuator. The new thermostats do not directly control the economizer section on any of the rooftop units. This means that when a call for cooling from the thermostat occurs, the existing rooftop unit economizer controller will pre-empt the mechanical cooling and open the outside air dampers – when outside conditions are favorable for cooling. Otherwise, mechanical cooling will be allowed to activate.
In addition to the hardware, the NC was programmed to enable the following features:
• Holiday scheduling added (eight holidays/year).
52
• Optimal start capability added.
• Schedules for the rooftop units were tightened (the new schedules staggered start times between 5 a.m. and 6 a.m.) and (all units turn off at 6 p.m.); these schedules apply Monday through Friday. The units are completely off on weekends.
• Heat pumps serving perimeter zones activate first to attempt to hold the core of the building at temperature thresholds to mitigate excessive heating or cooling loads on all heat pumps.
• Automatic night low and high limits maintain spaces no lower than 64oF and no higher than 82oF. Widening these set points will save more energy at night and on weekends, but may impact morning warm up demand issues. If the building had gas heat, it would allow for lower setback temperatures.
• Automatic outside air low temperature override added to keep from adding “just in case” scheduling on weekends and to keep from widening schedules during the weekday periods. When the outdoor air temperature falls below 25oF, the rooftop units run continuously.
• Removed the weekend scheduling with the above noted improvements.
• New thermostats accept global outdoor temperature sensor input (which supports heating/cooling lockouts at the rooftop unit). The thermostats can have their own individual outdoor temperature sensor (more cost for sensors and wiring) or they can have a global outdoor temperature value “pushed” into the thermostat, via the communications BUS. This saves cost and eliminates complexity.
• Remote push button thermostat occupancy override input allows for after-hours occupancy (night/weekends) if required. This alleviates adding or modifying schedules (“just in case” or for one-time or unplanned events). This also provides a means to obtain occupancy if the BAS NC fails or experiences a communication failure. When schedules are added for “unplanned events”, the schedules often remain in place long afterwards and are not removed in a timely manner. Keeping schedules and overrides to a minimum is one of the keys to successfully reducing energy cost and consumption.
• Created 4oF dead band between heating and cooling (previously the dead band was 2oF), driven by master set point. Wider dead bands can cause comfort issues, but with wireless zone temperature monitoring and averaging, most of the occupant complaints have gone away. Wide dead bands simply would not be possible without having additional sensor/monitoring capabilities.
7.2 Cost of Controls Upgrade
The cost of the controls upgrades for both hardware and labor cost is summarized in this section for Building 4 (the costs are similar for the other two buildings):
• New thermostats ($250 each x 10 thermostats) = $3K
• New wireless sensors ($50 each x 60 sensors) = $3K
53
• New wireless sensor integrator with repeater (1) = $1K
• Network infrastructure (hub/switch, computer, network integration, cabling) = $6K
• Labor (design/engineering, install new thermostats, network infrastructure) = $7K
The total installed cost for the controls upgrade for Building 4 is approximately $20K.
7.3 Energy and Cost Savings from Controls Upgrade
As indicated previously, the installation of controls was performed in 2010. Using the electricity interval data, energy use between the pre- and post-upgrade periods was compared and savings estimated. More detailed description of the analysis comparison and energy savings analysis is provided in Appendix D. As described in the Appendix D, empirical models were developed to estimate the actual savings and normalized savings energy for Building 4. Modeling included development of segmented linear regression models (five parameter models) for two periods: weekdays and weekends. Using the 2009 data, pre-BAS upgrade models were developed; similarly using 2011 data, post-BAS upgrade models were developed (Figure D - 8). After generating the models, savings estimates can be generated for the post period (i.e., after BAS upgrades) for the entire year. This can be done for the actual post-period weather data, or for historical typical meteorological year (TMY) data as shown in Table 4. The energy savings (utilizing actual or historical weather data) is roughly 22%.
The cost savings from the BAS upgrades are shown in Table 5. The annual energy cost for this all-electric building is shown in column 2; the average blended electricity rate paid for each of the three years is reported in column 3; the electricity cost normalized to 2011 utility rate is shown in column 4; the last column shows the percent difference in energy cost compared to 2009 (pre-upgrade). As can be seen, the normalized cost savings per year is approximately $5,000/yr, which leads to a 4-year simple payback. Even when the utility rates are low, compared to the most of the US, the paybacks appear to be reasonable (less than 5 years). So, for other locations where the utility rates are significantly higher ($0.15/kWh to $0.20/kWh), the payback periods are going to significantly lower as well (less than 3 years).
Table 4: Energy Savings for Building 4 from Pre- and Post-BAS Upgrades
Weather Data Actual TMY Projected Baseline Energy Consumption (kWh) 361,135 346,562
Projected Post Energy Consumption (kWh) 283,470 269,498 Energy Savings (kWh) 77,666 77,064
Percentage Savings from Baseline (%) 21.5 22.2
Table 5: Energy Cost Savings for Building 4 from Pre- and Post-BAS Upgrades
Year Electricity Cost ($/yr)
Average Electricity Rate ($/kWh)
Normalized Electricity Cost
($/yr)
Percent Difference Compared to 2009
2009 $17,120.92 $0.05 $20,242 0 2010 $13,315.00 $0.05 $14,890 26 2011 $15,122.91 $0.06 $15,123 25
54
7.4 Case Study Conclusions
One of the biggest challenges in upgrading these three buildings to BAS is that they are leased buildings. They are owned by (two) different entities and have different road blocks for participating in this type of upgrade. As leased buildings go, the challenges presented here may be even more typical than other buildings, which may be owned and managed differently.
After 2 years of consistently low energy consumption (reduced EUI), all three buildings were accepted by Environmental protection Agency’s (EPA’s) Energy Star program and recognized for their conservation efforts.
The management team that deals with occupant complaints saw a dramatic decline in comfort-related complaints after the upgrades were completed. This fact (improved occupant comfort) is a testimony to the benefit of upgrading a building to a BAS with the capabilities noted.
More small-building owners should be looking at the long-term benefits of a BAS upgrade that includes existing technologies such as wireless sensing, remote accessibility and thermostats or controllers at the rooftop unit equipment that can take advantage of global functions that include creative scheduling of occupancy and holiday events and integrating other data such as outdoor temperature sensor values and wireless temperature sensor values and power meter data/DR data.
55
8.0 Summary Discussion and Recommendations
The section provides a brief summary of the report, discussion of what is needed and recommendations on what to do next.
8.1 Summary
Section 1.0 introduced the study scope and analysis approaches used. Discussions regarding the number of buildings in the U.S that comprise “small-size” and “medium-size” buildings, their lack of BAS and the potential energy improvements, as well as challenges are detailed in this section.
Section 2.0 covers the characterization of both small- and medium-sized buildings. Drawing upon CBECS data from various surveys, detailed discussions of energy end-use and electrical end-use consumption values are provided. This section spring boards into further discussions for the various end-use loads and the present penetration of “intelligent” controls in the existing market. Discussions of the existing and possible future control methods, strategies and concepts that are applicable (including HVAC, lighting and miscellaneous end-use loads) complete this section.
Section 3.0 discusses the different communication architectures that might be found in a small- or medium-sized building BAS, as it relates to the communication networks needed to support them. This discussion covers the different technologies that have been in place (older) or are becoming more prevalent (newer), and how they work. This includes wired solutions, wireless solutions or a combination of both (hybrid wired-wireless) networks and industry standards, open and proprietary protocols. For each solution, the limitations of each technology are detailed (speed, bandwidth, reliability, etc.). Cost factors are also discussed because this relates to how these systems are being pushed to the market, and their acceptance (or lack of).
Section 4.0 describes the BAS, as has historically been seen and known in large building applications and the small- or medium-sized building applications. This section describes the history of BASs and how they have evolved and improved over time and summarizes their core functions. This description proceeds to discuss the major architectural requirements needed by new BASs to allow for greater penetration in the existing building stock in the U.S. This section concludes by providing three different options of what a future BAS configuration might look like for either a small-sized building (two different options) and for a medium-sized building (one option).
Section 5.0 presents the requirements and capabilities of various devices used to monitor and control different end-use loads found in small- and medium-sized buildings. This includes a robust presentation of the different requirements for the gateway, master controller, communicating thermostats, general purpose controller and the lighting controller. Typical requirements include schedule configuration capabilities, alarm configuration capabilities, set point configuration capabilities, security, communications capabilities and a whole host of other capabilities – many of which are unique to each different device and designed function(s). The expectation is that these different devices will also have “demand response” capabilities. Those capabilities are presented as well and vary from device to device. This section concludes by discussing data collection, archiving requirements and grid integration requirements. Potential models and strategies that could be implemented (at the device controller, at the master/gateway controller or external from the building) are also discussed.
56
Section 6.0 presents potential installed costs of a BAS for small- and medium-sized buildings. This discussion estimates annual energy and cost savings for different energy saving rates and different energy costs (therefore, what a proposed BAS project would cost for simple payback rates).
Section 7.0 covers a case study of a controls retrofit upgrade of an actual 20,000 sf medium-sized commercial building in Richland, WA. The case study details the existing controls and their capabilities and what was done to the existing controls to provide a BAS with many of the capabilities previously described (including wired/wireless technologies, capabilities used that did not exist before, costs to upgrade, and the energy and cost savings after the upgrade was completed.
The report also contains seven appendices (Appendix A – Appendix F) that provide more details on many of the same topics covered in the main report, including three use cases for BASs in small- and medium-sized buildings.
8.2 Discussion
As shown from the case study (Section 7.0), significant savings are possible if the buildings are retrofitted with advanced controls that can be centrally managed and capable of supporting intelligent scheduling based on the building needs and occupancy patterns. Furthermore, it was also shown that installation of the controls can be cost-effective even in low utility rate locations. However, to make a significant impact on the existing commercial building stock, a number of hurdles need to be overcome. Some of these hurdles are technology-related and others are policy-related. Because this work is focused on control solutions for small- and medium-sized buildings, the discussion in this section is limited to issues related to technology.
First, the fundamental building blocks necessary to develop a cost-effective controls solution for small- and medium-sized commercial buildings exist. These building blocks have to be packaged in such a way that it is cost-effective, open and standard, and truly “plug-n-play.” If the solution is not cost effective, i.e., reasonable payback (less than 3 years), it may not find widespread acceptance. Initially, utilities can provide incentives to create a market for these solutions and over time, as the size of market increases, the cost of the solutions will drop. One way to lower the cost of the solution is to “mandate” or “standardize” a controls architecture that is truly open, standard and plug-n-play. This approach will allow a number of vendors to develop components, products or services to compete for the same end goal.
Ideally, as noted above, the controls architecture or solutions for small- and medium-sized commercial buildings should be open, standard and truly plug-n-play. However, “plug-n-play” is a loosely used, catchy phrase that means different things to different people. This phrase is commonly used to describe components or devices that work as soon as they are connected to the personal computer system. The user does not have to manually install device drivers or indicate that a new device has been connected. For example, if a plug-n-play external USB (universal serial bus) hard drive is connected to the computer, the device will begin to work within a few seconds of being plugged. A non-plug-n-play device, on the other hand, will require going through several steps of installing drivers and setting up other configuration parameters manually before it can be used. Much of the building control devices are non-plug-n-play. For controllers or control components to be truly plug-n-play, an open industry standard is needed. Many of the building control components or unitary controllers used to control building systems that are designed to do a specific job can be made to be truly plug-n-play.
57
Is there a need for a truly open and standard controls architecture/solution for buildings?
In the past, most BASs used proprietary architectures, leaving building owners and controls designers with no choice but to specify BAS field devices and controllers from a single vendor for compatibility. The customers did not have the flexibility to choose the best products, controls, and services at optimum prices for the desired performance from different vendors. With the advent of BACnet, which is an open, standard protocol (ASHRAE/ANSI standard), owners and designers now have a choice. Also, customers have a choice of an alternate standard protocol from the LonMark Association, which is based on LonWorks from the Echelon Corp. Both protocols support integration of the control networks with the Internet.
Although both of these commonly used protocols are standard, they are not truly open or truly “plug-n-play.” For example, if a facility uses a BACnet-based controller from vendor A, in theory when the controller fails, it is possible to replace that controller with a similar controller from vendor B. In practice, however, this may or may not be possible for a number of reasons. Even though the controllers from both vendors are BACnet-based, they need different software tools to configure them. Even if one succeeds in configuring the new controller, it may be a challenge integrating that with the rest of the enterprise controls infrastructure.
Furthermore, neither of these protocols is truly “plug-n-play.” Every controller has to be configured manually to some extent to be able to seamlessly integrate with the rest of the enterprise-wide controls. These protocols only guarantee that certain minimum compliance specifications, as required by the respective standards, are met. In the case of BACnet, these specifications are developed openly through the ASHRAE standards process, which sometimes can take a long time to reach consensus. The LonMark products also have a standard, but it is developed by the members of the LonMark association. What happens to consumers when they no longer have the same expectation for market performance when it comes to building controls and their ability to “plug-n-play”?
1. Higher consumer costs are incurred by the customer along with higher consumer frustrations: a. Without a multi-vendor solution (the consumer is committed to a one vendor solution)
that is not truly open and standard, the consumer has no control over costs or vendor equipment performance
i. lack of competitive market drives consumer costs up b. Vendors are not concerned about product reliability or longevity
i. consumers are held hostage to poor product designs c. Vendors are not concerned about product support or consumer training
i. consumers suffer through lack of quality assurance and product improvements that are slow to market
d. Vendor product quality assurance (hardware and software) is no longer a driver or focus for the vendor
2. Sustainability and good stewardship is no longer achievable: a. Because of reliability issues, potential vendor product termination and similar issues,
many consumers often buy “excess” parts (just in case), and these end up being warehoused or stored for long periods of time.
i. This becomes part of the consumer’s “hidden” cost, besides the add-on service provider costs
58
ii. Many of these parts have embedded electronic components that are not environmentally friendly for the landfills, but eventually end up there as a result of obsolescence
iii. Many of these parts have embedded chips or firmware that may be obsolete or in need of upgrades because of “issues”, but since they are on shelves and not in operation, they may not get replaced or updated and if used, “create” new problems
b. The same problems can occur when vendors go out of business, further exacerbating consumers. In many cases, automation control solutions are abandoned in place, or placed into some type of overridden condition.
3. Consumers are driven to be “locked-in” to one vendor solution: a. Vendor a’s product solution may have a different design (communications protocol,
control routines, drivers, interface, etc.) that makes consideration of Vendor b’s product solution unlikely, when considered by the consumer, based upon first cost.
i. Switching to a new vendor may require significant infrastructure investment (different wiring solution, new controllers, new sensors, new power supplies, etc). This type of cost investment is extremely hard to justify by most building owners.
ii. Most consumers are ignorant when it comes to building solutions and rely upon service and technical support contracts to keep their building automation systems and controls “working”. Switching to another vendor brings added costs (now two service contracts, not one).
b. When it comes to automobiles, most consumers want their vehicles maintenance performed by the same mechanic or service organization. However, this may not be the case as vehicles become more complicated. As building controls continue to change and building owners install multiple solutions, this is often true as well.
4. Control vendors have no incentive to change for fear of losing market share: a. Historically, control vendors have maintained their profitability from two areas of the
building HVAC market. i. Installation of new controls and service of existing controls. Given the tight
margins in the installation arena (new construction or retrofits), this often results (in many cases) in vendors losing money. What to do?
ii. Either become more proficient in the construction arena or expand into the service sector, but configure your product so that no one else can configure or service it and no one else can “plug-n-play” with your system without your support.
5. Many control vendors have found the service market to be more lucrative: a. There is no competition, when the consumer feels “locked in”
i. “Locked-in” service contracts are common ii. Charge-out rates are significant profit centers for control vendors
b. Warranty-related issues may or may not be enforced by consumers, and they may unwittingly pay for “improvements” in product performance that were really requirements (but not understood at the technical level)
c. Switching vendors (even if “locked-in”) may not be as easy for a building controls solution, when compared to mobile communications (cell phone service providers) or cable or satellite providers.
59
What areas of building controls should have the ability to “plug-n-play” and what would that look like?
1. Hardware interface: a. In the automotive industry, a multi-vendor solution for tires would not exist without
standards. This includes dimensional requirements related to diameter, tread width and other related aspects. What sets tires apart for consumers are their performance and other safety-related aspects (number of layers, weather, etc.)
i. A standards body mandates minimum requirements related to size and performance
b. Controllers should have common power and interface requirements to the most common equipment (HVAC) systems in the industry.
i. AC power (24 VAC/120 VAC, self-powered or equipment-powered with battery or other backup power capabilities (where required). Controllers with non-volatile memory that safeguard system configuration and other important settings are preferred over volatile memory designs.
c. Controllers should have common connection interface requirements for all wiring (power, sensors and equipment inputs/outputs) to allow for quick disconnect/re-connect of similar vendor or other vendor controllers.
i. The computer and electronic industry has standardized on several hardware configurations. This includes connections for phones (RJ-11), Ethernet (RJ-45), USB and other equipment connections.
ii. This allows for the physical aspects of “plug-n-play” in the computer and electronics equipment industries. USB connectors allow external devices to be connected to a computer, usually without having to power down the device. This “plug-n-play” capability requires all devices to conform to physical connectivity requirements, as defined by the USB connector design.
iii. Similar requirements would allow for quick connect/disconnect of different vendor controllers, reducing labor and setup costs. Otherwise, significant costs can be incurred to de-terminate and re-terminate controllers and their associated sensors.
d. Currently, the only standard that seems to be (loosely) in place is for thermostat wiring and rooftop unit (RTU) terminal connections and their designations. How equipment and controllers might interface is still not consistently enforced to comply with prescribed standard conventions.
i. Most RTU equipment and thermostat terminal designations include R (24 VAC power), G (fan command), Y1 (cooling stage 1 command), Y2, cooling stage 2 command), W1 (heating stage 1 command & W2 heating stage 2 command). Beyond these, there are variations depending upon whether the RTU is a heat pump, whether the reversing valve for the heat pump requires a separate signal (or is internally commanded) and a few other miscellaneous configurations that are beyond standard design convention.
ii. The standard hardware terminal connections for different vendor RTU equipment usually is a screw terminal design. In some cases, the vendor may have created a special connection. As control vendors create new control solutions (thermostats, controllers, wired or wireless), it is important that connections and terminal designations remain consistent (similar to USB and RJ connections) to allow for multiple vendor solutions to be implemented in a “plug-n-play” environment. Having a standard connector reduces labor for replacement, less chance of a wiring error (which could lead to additional parts failing) and allows worker not trained in HVAC to replace parts, thus making it possible for companies to lower
60
the cost.
2. Software interface a. In the computer industry, a multi-vendor solution for different devices (printers, mice,
monitors, etc.) would not exist without standards and drivers that control the device interface (including what each wire in the cabling supports). This is true for both wired and wireless solutions.
b. In computing, a device driver or software driver is a computer program that operates or controls a particular type of device that is attached to a computer.
i. In a new controls solution, drivers or similar software would allow for different controllers to be connected to an RTU.
ii. This may require the RTU to also have intelligence (similar to a computer) that communicates with the controls solution (wired or wirelessly).
iii. RTU intelligence may be provided by the RTU vendor or by the controls solution vendor. The logical outcome is for this to be provided by the RTU vendor, but this may not always be the case.
c. In computing, when a calling program invokes a routine in the driver, the driver issues commands to the device. Once the device sends data back to the driver, the driver may invoke routines in the original calling program. Drivers are hardware-dependent and operating-system-specific
i. If the same convention is followed in the control vendor solutions, this means that control solutions will be hardware design dependent and not truly “plug-n-play”.
ii. Should there be one solution for different RTU configurations, or should there be multiple solutions (i.e., one thermostat that can be configured to connect to any type of RTU – conventional, heat pump, 1 stage, 2 stage, electric, gas, de-humidification, etc.) or should there be many thermostats? If the existing computing industry is the example for “plug-n-play”, then there would be many solutions (not one thermostat that can be configured for many different RTU configurations). This is because of the complexity in different vendor equipment and control solutions.
iii. Operating-system (OS) specific means a solution is bound to some high level protocol for communications of event-oriented tasks. In the computing industry, there are several OS platforms. Different vendor solutions can still be networked together to create a network solution.
Second, even if the building has central controls, without the ability to monitor both the controls and end-use consumption, the persistence of the efficient operations is not ensured. So, the control solution should provide ways to enable easy access of sensor values and control parameters to third party software solutions. In addition, the controls solution should also have the ability to integrate the information from the so-called “smart” utility meters. Because energy accounts for a significant portion of the operating cost in many facilities, facility managers, energy service providers, and owners alike will benefit from software tools that track energy end-use. For example, the benefits for an owner of a retail chain or a facility manager of a large campus with distributed facilities include the ability to:
• generate reports in several different formats (e.g., by region, building type or location),
• benchmark historical, normalized (i.e., with respect to weather, size) end-use consumption between similar buildings/facilities. Comparison with benchmarks can help identify operational
61
inefficiencies and improvement opportunities (what is different about the better performing building compared to the poorly performing building – design, operations, maintenance, etc.) that could be implemented, especially if the improvements are no/low cost.
• forecast energy consumption patterns that can be used in preparing energy purchasing plans. An energy service provider who has signed a guaranteed savings (i.e., performance) contract with a facility can reduce his risk and increase his reliability by tracking end-use consumption and calculating savings continuously. From a central location, the energy service provider or facilities personnel can also identify problems associated with unscheduled operation of equipment (such as lights and HVAC equipment) as a result of control malfunctions, errant programming or manual overrides.
In addition to the ability to track and forecast energy use at the building and end-use level, interoperable access to control system and facility energy data is necessary to a) support more pervasive use of advanced energy-focused analytics in small-to-medium buildings, and therefore, b) enable next generation of energy- and price- aware grid-integrated buildings. When accommodated within a cost-effective plug-n-play controls infrastructure, continuous diagnostics, determination and execution of optimal control strategies, and transactive responsiveness become possible, even for small- and medium-sized buildings.
8.3 Recommendations
As reported previously, a significant percentage of the small- and medium-sized buildings lack centralized controls and monitoring, leading to significant waste of energy and higher energy cost. It is not because of availability of technology that these buildings lack proper infrastructure. The lack of awareness, lack of cost-effective packaged solutions that are easy to implement and lack of open, standard and plug-n-play controls are the primary causes for the current state of these buildings. There are other policy issues that will need to be addressed to change the status quo, including split incentives, where the owner is not paying for the energy consumed in the building and therefore, has no incentive to upgrade the controls infrastructure. One policy recommendation for DOE to consider is mandating certain minimum controls infrastructure for all commercial buildings by updating the current codes. Even though in most cases upgrading the monitoring and controls infrastructure will payback in less than 3 years, many building owners will have difficulty raising the capital required for such an upgrade. Another policy recommendation would be to create easy financing options for these retrofit projects.
On the technology front, it is recommended that DOE encourage controls vendors to develop open, standard and plug-n-play controls suitable for small- and medium-sized buildings. These technology solutions must be suitable for easy implementation in existing buildings as well as new buildings. A single solution may not be suitable for all building types and sizes, so DOE should encourage vendors to develop open, standard and plug-n-play solutions that can scale and that meet minimum common functionality in the small- and medium-sized buildings portfolio. Because many of the small- and medium-sized buildings have rooftop units, the initial focus should be to develop plug-n-play controls infrastructure for connectivity between the rooftop equipment and controllers. Some of the features for standardization should include:
1. Minimum hardware design requirements
62
a. common power source(s) b. common physical platform(s) – one device for all RTU configurations or one device per
RTU configuration c. common physical connections (screw terminals, connectors, etc.) d. minimum sensor inputs e. minimum control & command outputs f. common physical communication layers/standards (e.g. KNX, BACnet, OPC) g. common wireless communication standards (e.g. Zwave, Zigbee, WIFI, Power Line
Carrier systems) h. common Grid response standards (e.g. EMIX, Energy Interop, OpenADR and Smart
Energy Profile, OpenADR – Automate Data Exchange, Green Button).
2. Minimum software requirements a. common control sequences for selected RTU(s) or all RTU combinations (DX with
electric, DX with gas, heat pump with electric, heat pump with gas, other) b. common set points (exposed, use-adjustable) c. common standard point naming convention, which will allow of consistent data analytics d. common, standard control language (similar to standard adopted by programmable logic
controllers IEC 61131-3[1]) e. logic, math, alarming, totalizing, trending, history capabilities f. data storage capabilities g. security capabilities h. remote notification and remote access capabilities i. analytics j. fault detection and diagnostics1 k. model predictive controls l. Consider IEEE 1451 - a set of smart transducer interface standards developed by the
Institute of Electrical and Electronics Engineers (IEEE) Instrumentation and Measurement Society’s Sensor Technology Technical Committee that describe a set of open, common, network-independent communication interfaces for connecting transducers (sensors or actuators) to microprocessors, instrumentation systems, and control/field networks.
[1] International standard for programmable controller programming languages 1 State of California (2013 Title 24 - http://www.energy.ca.gov/title24/2013standards/supporting_docs.html) is requiring a select set of economizer diagnostics for all rooftop units manufactured and sold in California starting January 2014. For more information refer to the document at the following URL http://www.energy.ca.gov/title24/2013standards/prerulemaking/documents/current/Reports/Nonresidential/HVAC/2013_CASE_NR_Light_Commercial_Unitary_UPDATED_Nov_2011.pdf
63
9.0 References
Anderson, M., M. Buehner, P. Young, D. Hittle, C. Anderson, J. Tu and D. Hodgson. 2005. “MIMO Robust Control for HVAC Systems,” IEEE Transactions on Control Systems Technology, Vol. 16, issue 3, pp. 477-483, New York, New York. Ardehali, M.M., and T.F. Smith. 2002. Literature Review to Identify Existing Case Studies of Controls-Related Energy-Inefficiencies in Buildings. Technical Report: ME-TFS-01-007. Department of Mechanical and Industrial Engineering, The University of Iowa, Iowa City, Iowa. ASHRAE, “HVAC&R: Market Trends & The Influence of ASHRAE Members,” 2012, ASHRAE, Atlanta, Georgia. ASHRAE. 1999. ASHRAE Guideline 13-2007: Specifying Direct Digital Control Systems. American Society of Heating, Refrigerating and Air-Conditioning Engineers Inc., Atlanta, GA. Azar, E. and C. Menassa. 2010. “A Conceptual Framework to Energy Estimation in Buildings Using Agent Based Modeling,” Proceedings of the 2010 Winter Simulation Conference, 2010. Bai, J., H. Xiao, T. Zhu, W. Liu, X. Yang and G. Zhang. 2008. “Design of an Improved Single Neuron-Based PI Controller for an HVAC System in a Test Room,” IEEE International Workshop on ETT and GRS 2008, pp. 701-705, December 2008 Borggaard, J., J. A. Burns, A. Surana, and L. Zietsman. 2009. “Control, Estimation and Optimization of Energy Efficient Buildings,” Proccedings of the American Control Conference, St. Louis, MO, USA June 10-12, 2009, pp. 837-841. DOE. Department of Energy. 2010. EnergyPlus Energy Simulation Software, (version 7.1), US Department of Energy, Washington, DC. EIA. Energy Information Administration. 2003. Commercial Buildings Energy Consumption Survey 2003. U.S. Department of Energy, Washington, D.C. Last accessed in July 2011 at http://www.eia.doe.gov/emeu/cbecs/contents.html. EIA. Energy Information Administration. 2009. Commercial Buildings Energy Consumption Survey 2009. U.S. Department of Energy, Washington, D.C. Last accessed in July 2011 at http://www.eia.doe.gov/emeu/cbecs/contents.html. Fraden, J. Handbook of Modern Sensors: Physics, Designs, and Applications, 4th Edition, Springer 2010. Kiliccote, S., J. H. Dudley, M. A. Piette, E. Koch, and D. Hennage. Open Automated DR for Small Commercial Buildings. LBNL 2195e, Lawrence Berkeley National Laboratory, Berkeley, California. Ganssle, J. 2008. The Art of Designing Embedded Systems, 2nd Edition." Elsevier, Burlington, Massachusetts. Goetzler, W., G. Shalom, S. Jasinski, R. Legett, H. Lisle, A. Marantan, M. Millard, D. Pinault, D. Westphalen, and R. Zogg. 2009. Energy Savings Potential and R&D Opportunities for Commercial Refrigeration: Final Report. Washington, DC: Navigant Consulting, Inc. September 23. http://apps1.eere.energy.gov/buildings/publications/pdfs/corporate/commercial_refrig_report_10-09.pdf.
64
Gondhalekar, R. F., Oldewurtel, and C.N. Jones. 2010. “Least-Restrictive Robust MPC of Periodic Affine Systems with Application to Building Climate Control,” Proceeings of the 49th IEEE Conference on Decision and Control, pp. 5257-5263, December 15-17, 2010. Gwerder, M. and J. Todtli. 2005. “Predictive Control for Integrated Room Automation,” 8th REHVA World Congress for Building Technologies CLIMA, Switzerland, 2005 Herter, K., S. Wayland, and J. Rasin. 2009. "A Successful Case Study of Small Business Energy Efficiency and DR with Communicating Thermostats." International Energy Program Evaluation Conference 2009, Portland, Oregon. Itron. 2006. "California End-Use Survey." Prepared for the California Energy Commission, Report CEC-400-2006-005, 339 pp., California Energy Commission, Folsom, California. JCI. 1999. Metasys Network Technical Manual, Network Communications Section, Johnson Controls, Milwaukee, Wisconsin. Keeney, K., and J. Braun, 1997. "Application of Building Precooling to Reduce Peak Cooling Requirements." ASHRAE Transactions, vol. 103, issue 1, pp. 463-469. Lockheed Martin Aspen. 2006. Demand Response Enabling Technologies for Small‐Medium Businesses – A report prepared with the 2005 California Statewide Pricing Pilot. April 12, 2006, Publisher, city, state. Ma, Y., F. Borrelli, B. Hencey, A. Packard, and S. Bortoff. 2009. “Model-Predictive Control of Thermal Energy Storage in Building Cooling Systems,” Proceedings of the Joint 48th Conference on Decision and Control and 28th Chinese Control Conference, Shanghai, P.R. China, December 16-18, 2009, pp. 392-397. McKenney K., M. Guernsey, R. Ponoum and J. Rosenfeld. 2010. Commercial Miscellaneous Electric Loads: Energy Consumption Characterization and Savings Potential in 2008 by Building Type. TIAX LLC, Cambridge, Massachusetts. Download at: http://zeroenergycbc.org/pdf/2010-05-26%20TIAX%20CMELs%20Final%20Report.pdf. Mirinejad, H., K. C. Welch and L. Spicer 2012. “A Review of Intelligent Control Techniques in HVAC Systems,” IEEE EnergyTech 2012, Vol. 1, pp. 1-5, May 2012. Murthy, N., J. Taneja, K. Bojanczyk, D. Auslander, and D. Culler. 2012. Energy-Agile Laptops: Demand Response of Mobile Plug Loads Using Sensor/Actuator Networks. Proceedings of the Third IEEE International Conference on Smart Grid Communications (SmartGridComm'12) in November. Navigant. 2012 US Lighting Market Characterization. Report prepared for Solid State Lighting Program, Building Technology Program, Energy Efficiency and Renewable Energy, US Department of Energy, Washington, D.C., July 2012. Oldewurtel, F., C. Jones, and M. Morari. 2008. “A Tractable Approximation of Chance Constrained Stochastic MPC based on Affine Disturbance Feedback,” 47th Conference on Decision and Control, pp. 4731 - 4736, 2008 Oldewurtel, F., A. Parisio, C.N. Jones, M. Morari, D. Gyalistras, M. Gwerder, V. Stauch, B. Lehmann, and K. Wirth. 2010. “Energy Efficient Building Climate Control using Stochastic Model-Predictive
65
Control and Weather Predictions,” Proceedings of the American Control Conference, Baltimore, MD, USA June 30-July 02, 2010, pp. 5100-5105. OpenADR Alliance., 2012. http://www.openadr.org/ viewed on October 15, 2012. Page, J., S. Kiliccote, , J.H. Dudley, M.A. Piette, A.K. Chiu, B. Kellow and E. Koch. 2011. Automated DR Technology Demonstration for Small and Medium Commercial Buildings. LBNL 4982E, Lawrence Berkeley, California. Piette, M.A. G. Ghatikar, S. Kiliccote, E. Koch, D. Hennage, P. Palensky, and C. McParland. 2009. Open Automated DR Communications Specification (Version 1.0). California Energy Commission, PIER Program. CEC-500-2009-063 and LBNL-1779E, Folson, California. Rubinstein, F.M., and S. Kiliccote. 2007. Demand Responsive Lighting: A Scoping Study. Lawrence Berkeley National Laboratory. LBNL‐62226. January 2007, Lawrence Berkeley National Laboratory, Berkeley, California. Salami, M.E., M.M Rashid, N. Mohammad. 2011. “Design and Implementation of an Intelligent Fuzzy Logic Controller (FLC) for Air Handling Unit (AHU) for Smart House,” Australian Journal of Basic and Applied Sciences, 5(3): 641-652, 2011 US EIA. 2003. Commercial Buildings End-Use Consumption Survey. Available from: http://www.eia.gov/consumption/commercial/index.cfm, accessed October 2012, US Department of Energy, Washington, D.C. Xu, P., P. Haves, M. A. Piette, and J. Braun. 2004. "Peak Demand Reduction from Pre-Cooling with Zone Temperature Reset in an Office Building." 2004 ACEEE Summer Study on EE in Buildings, Pacific Grove, CA. Xu, P. 2006. "Evaluation of Demand Shifting Strategies with Thermal Mass in Two Large Commercial Buildings", SimBuild 2006, Cambridge, MA, MIT.
A-1
Appendix A
A. Characterization of Commercial Buildings of Interest and End Use Controls
A-1
Table A - 1 shows the distribution of the commercial buildings subset of interest that are no more than 5,000 sf. The percent of the subset (col. 3) is the ratio of number of buildings in each building activity to that of total buildings in the subset, while percent of the total stock is the ratio of number of buildings in each building activity to that of the total building stock less than or equal to 5,000 sf. The office building type has most buildings, followed by service, retail and education. The service category includes buildings where services are provided (excluding food service and retail sales), such as, vehicle repair shop, car wash, copy center, beauty parlor, barber shop, etc.
Table A - 1: Distribution of Commercial Buildings by Principle Building Activity (<=5,000-sf)
Figure A - 1 shows the disaggregation of energy end-use consumption in the subset of commercial buildings that are 5,000 sf or less. Heating consumption is the dominant end use, followed by lighting, plug loads and cooling. Over half (54%) of the energy consumption in small buildings is from HVAC. HVAC, lighting and plug loads account for 89% of all energy consumption in small buildings. Figure A - 2 shows the disaggregation of electricity end-use consumption in the subset of commercial buildings that are less than 5,000 sf. For electricity, HVAC and lighting consume over 58% of the electricity consumption in small buildings, while the rest of the consumption is from plug loads, water heating and refrigeration.
Figure A - 3 shows the disaggregation of energy end-use consumption in the subset of commercial buildings that are sized between 5,001 sf and 50,000 sf. Although there are some minor differences in the disaggregation of the energy consumption compared to small buildings, heating consumption is still dominant, followed by lighting, plug loads and cooling for medium-sized commercial buildings. Over half (57%) of the consumption in medium-sized buildings is from HVAC. HVAC, lighting and plug loads account for over 90% of all consumption in medium-sized buildings. Figure A - 4 shows the disaggregation of electricity end-use consumption in the subset of commercial buildings sized between 5,001 sf and 50,000 sf. HVAC and lighting consume over 71% of the electricity consumption in medium-sized buildings, while the rest of the consumption is from plug loads, water heating and refrigeration.
Principal Building Activity
Total Buildings
Percent of Subset
Percent of Total Stock
Office 503,488 31.8 % 19.5 %Outpatient health care 55,877 3.5 % 2.2 %Religious worship 151,695 9.6 % 5.9 %Education 162,497 10.3 % 6.3 %Strip shopping mall 33,925 2.1 % 1.3 %Retail other than mall 241,085 15.2 % 9.3 %Service 434,258 27.4 % 16.8 %
A-2
Figure A - 1: Disaggregation of Energy End-Use Consumption in the Subset of Commercial
Buildings 5,000 sf or Less
Figure A - 2: Disaggregation of Electricity End-Use Consumption in the Subset of Commercial
Buildings 5,000 sf or Less
44%
7%3%3%
18%
0%
8%
2% 3%
12% Heating
Cooling
Ventilation
Service Hot Water
Lighting
Cooking
Refrigeration
Office Equipment
Computer
Miscellaneous
5%
14%
5%
2%
34%0%
16%
3%
6%
15%
Heating
Cooling
Ventilation
Service Hot Water
Lighting
Cooking
Refrigeration
Office Equipment
Computer
Miscellaneous
A-3
Figure A - 3: Disaggregation of Energy End-Use Consumption in the Subset of Commercial
Buildings in the Size range Between 5,001 sf and 50,000 sf
Figure A - 4: : Disaggregation of Electricity End-Use Consumption in the Subset of Commercial
Buildings in the Size range Between 5,001 sf and 50,000 sf
44%
8%5%4%
21%
1% 4%
1%3%
9% Heating
Cooling
Ventilation
Service Hot Water
Lighting
Cooking
Refrigeration
Office Equipment
Computer
Miscellaneous
6%
14%
10%
3%
39%
0%
7%
2%
5%
14%
Heating
Cooling
Ventilation
Service Hot Water
Lighting
Cooking
Refrigeration
Office Equipment
Computer
Miscellaneous
B-1
Appendix B
B. Lighting Control System Architectures
B-2
As indicated in Section 2.4, there are a diverse number lighting control types and associated system architectures. Although the terminology used in the technical literature is not standardized, this document distinguishes between lighting control systems, which are capable of interfacing with controllable ballasts, and lighting automation panels that provide control solely by interfacing with the circuitry that powers the lights. Simple contactor/timer systems, are the least sophisticated, but may be found in small commercial buildings. These system control types are distinguished by: a) extent of control; b) control input options; and c) connectivity. Contactor/Timer systems
1. Extent: shut power on/off to an area or group.
2. Input options: schedules, override switches possible, but rarely implemented, occupancy sensors, photosensors, override switches.
3. Connectivity: standalone, isolated, no data outputs. Contactors are essentially high-current relays, or electrical switches for controlling a power circuit. The contractor is operated with a lower power control circuit. Contactor timer systems range from basic, using only a time clock, to more rarely implemented complex designs that include photosensors, occupancy sensors, and override switches. Figure B - 1 shows the general architecture of a contactor timer system.
Figure B - 1: General Architecture of a Contractor-Timer System for Scheduled Lighting Control Lighting automation panels, lighting control panels, relay panels
1. Extent: shut power on/off to an area or group.
2. Input options: schedules, override switches, occupancy sensors, photosensors.
3. Connectivity options: networked with one another, or with building automation system (BAS).
Lighting automation panels are packaged solutions that contain a set of embedded programmable relays, where schedules are often programmed manually with an on-board keypad and display, or using PC software applications. Lighting automation panels may accommodate sensor inputs and override
B-3
switches, and may be networked to one another, or to a central BAS. Figure B - 2 shows the general architecture of a lighting automation panel, with associated options for networking, BAS-integration, and sensor and switch inputs. Lighting control system
1. Extent: area or group, and whole building lighting.
2. Capable of direct ballast control for dimming, or other strategies as well as on/off scheduling.
3. Input options: schedules, occupancy and photosensors, personal controls.
4. Connectivity options: Sometimes can link to BAS. Lighting control systems offer a number of control strategies in addition to scheduling, including continuous dimming, set point tuning, and occupancy sensing. In some cases they may offer the option to integrate with a BAS. Figure B - 3 shows the general architecture of a lighting control system with associated options for networking, BAS-integration, and sensor and switch inputs.
Figure B - 2: General Architecture of a Lighting Automation Panel for Scheduled Lighting Control
B-4
Figure B - 3: General Architecture of a Lighting Control System, Capable of Direct Ballast Control for Advanced Strategies, and Panel-based Control
Next-generation building and lighting control systems for small buildings should be capable of both direct ballast control, and panel-based control. Panel-based control is most common in the existing commercial and small building stock, but as costs decrease, controllable ballasts, which afford the most flexibility, should be accommodated. Occupancy and daylight sensing, as well as appropriate occupant personal controls, are also critical components. In addition, embedded automated fault detection and diagnostic algorithms should be included to support continuous performance assurance, and ‘push’ reporting of problems to operators.
C-1
Appendix C
C. DR Signal Communication Media
C-2
For any small commercial facility to participate in automated DR, it needs to receive price and reliability signals over a communication media (Table C - 1). For large commercial and industrial facilities that participated in Auto-DR programs in California, their local area network (LAN) or digital subscriber lines (DSL) has been utilized. However, not every small commercial facility may have a LAN or dedicated DSL lines. Therefore, this section outlines other media that may be used to communicate DR signals to small commercial customers and compares the various choices. In general, the following are the desired characteristics of any communications means for the purposes of automated DR:
• Reliable • Two-way • Secure • Reasonable latency. This requirement depends upon the type of DR program that is being
implemented. For most types of DR, keeping the latency less than one minute is adequate, but there may be requirements of seconds if doing DR for the purposes of grid reliability.
• Support for open and widely adopted protocols, such as IP • Cost effective to design into automation equipment. This means that the equipment should be
cheap enough to keep the overall equipment manufacturing cost down, and it should be simple enough to keep the development costs within reason.
• Cost effective to operate. This means that there should not be high operational costs associated with using the communications means.
IP Infrastructures
Communications infrastructures that support IP communications and can utilize the Internet as the
main means for communicating are as follows:
• T-Carrier • Digital subscriber lines (DSL) • Cable Internet • Integrated service digital network (ISDN) • Satellite • Optical fiber to building • WiMAX • Mobile cellular • Broadband power line • Plain old telephone service (POTS)
C-3
Table C - 1: Summary of Communication Means for DR
Technical Details The primary technical issues with data aggregators and signal form conversion are related to the large number of physical interfaces required. In most cases, the physical interfaces are (digital) network connections that may include RS-485 (TIA/EIA-485 2001) or similar on twisted pair, various wireless connections, data on optical fiber, or any other communication media. The most common network interfaces will be included in the section on local network interfaces. Some data aggregators include legacy interfaces to individual sensors that are low-voltage analog or digital. This section considers common available interfaces on low-cost hardware and the limitations thereof. This section covers specific signal form types, issues associated with sensor cabling, analog versus digital transmission, and data tagging. Sensor Cabling Advantages and Disadvantages Sensors are connected to data aggregators almost exclusively using electrical wiring. There are wireless sensors and optically wired sensors, but these are in the very small minority today. Cabling enables the sensor or actuator to be placed away from the aggregator or controller. In addition, cabling brings several other advantages and limitations to sensor systems, including accuracy issues, fault detection, installation cost, and exposure to single point failures Fraden (2010).
TypeMust be
dedicated to DR devices
Two Way Installation costs Monthly costsCosts to
implement in devices
T-carrier No Yes High if dedicated
High if dedicated
Low (Ethernet)
DSL No Yes Medium if dedicated
Medium if dedicated
Low (Ethernet)
Cable No Yes Medium if dedicated
Medium if dedicated
Low (Ethernet)
ISDN No Yes Medium if dedicated
Medium if dedicated
Low (Ethernet)
Fiber No Yes High if dedicated
High if dedicated
Low (Ethernet)
Satellite No Maybe High if dedicated
Medium if dedicated
Low (Ethernet)
WiMax No Yes Medium if dedicated
Medium if dedicated
Low (Ethernet)
Mobile Yes Yes Low Medium HighPOTS No Yes Low Medium Low if not
dedicatedBPL No Yes Medium if
dedicatedMedium if dedicated
Low (Ethernet)
Paging Yes Both Low Medium MediumRDS Yes No None None LowDirect Band
Yes No None None Low
C-4
Cabling and Sensor Accuracy Using a cable (set of wires) to transfer analog signals is a solution that provides high or poor accuracy depending on the implementation. Connecting a highly precise and accurate sensor via a well-engineered cable to a highly precise and accurate aggregator can work very well. However, there are significant costs associated with the engineering, the shielded cables, and other factors. Typical installations utilize systems where a voltage is applied to a wire and some current flows. The resistance in the wire results in a voltage drop, caused by the current and a reduction in accuracy. The resistance in the wire is dependent on many things, including the diameter of the conductors, the materials used, the condition (e.g., bends or other stress) of the wires, and the length of the wires. Given all of these factors, and that some change over time; they contribute error to the measurement. Digital Transmission The primary alternative to analog signals over wires is to digitize the signal close to the source and send it over a cable or wireless connection. Digital data in well-designed systems are either received error-free (no loss in accuracy) or are received in a way where they are detectably corrupt (resulting from features conceptually related to checksums). Digital transmission provides a significant advantage compared to analog transmission in that the signal can then be sent over arbitrary distances and is uncorrupted by noise, interference, or time. The primary disadvantage is that users must provide reasonable quality interface circuitry (including analog-to- digital converters) at many places close to the sensor instead of potentially just a single location at the aggregator. Depending on the precision needed, the circuitry may be expensive or power hungry. With advances in electronics over the last several decades, high precision can often be had for low-cost and little power, mitigating this concern to some extent. Another disadvantage is that although digital transmissions are received error-free in most cases, digital signals do not gracefully decrease in quality with increasing noise or attenuation. The signal is either received successfully or not, and no conclusion can be made from unsuccessful data. In an analog system, some decrease in accuracy may still be acceptable in some cases. Data Tagging with Metadata Metadata is information about data. In the case of time-series data of interest in sensor systems, data consist of a series of time and value pairs. The metadata can describe the units of the values, the location of the sensor both physically and in the system, manufacturer data, model number, and many other pieces of information useful for understanding the data. With traditional analog interfaces, this tagging must be done in the aggregator, and any changes outside the aggregator, such as the replacement of one sensor with another, must be recorded and manually entered into the aggregator. This prevents “plug-n-play”-type systems because the sensors cannot provide any information about themselves. The generation of the data at the conversion step is critical, but the metadata are just as critical for a system that can be used, modified, and repaired. Digital systems often include some metadata, either with the measurements or in reply to requests. These metadata can be highly valuable for understanding, expanding, and improving an existing sensor system. Characteristic Interdependencies This section discusses the legacy interfaces and related functions of a data aggregator and how those interfaces either provide or limit the functionality of the aggregator. The aggregator may include multiple input and output types, including analog and binary valued signals along with different devices connected over a variety of network interfaces. All of these must be converted to a single format and stored and/or transmitted along another network link. This identifies a significant need that is not included in this
C-5
scoping study: embedded processing capability. All of the functions related to the aggregator require some sort of processing capability, and the solution used in virtually all applications today is an embedded general purpose processor. Two classes of processors are common for these systems: microcontrollers and embedded versions of standard processors. Microcontrollers tend to be simpler, cheaper, and lower power than other processors, while also integrating analog and other peripherals on-chip. Embedded versions of standard processors are more powerful, can run more standard operating systems (like embedded Linux), but still integrate memory and other peripherals on chips for small size and lower cost Ganssle (2008). The processor is used to control the analog and digital interfaces, to process the data, and to manage network connections. Controlling analog and digital interfaces includes control of external interface circuits (e.g., amplifiers or level shifters) and the on-chip subsystems, which include analog-to-digital and digital-to-analog converters. This control typically uses time information to determine when to measure a signal, but it can use measurements of other sensors or other information to trigger a sample. Any of these options requires a processor to make decisions, control peripherals, and manage the resulting data. Managing a network connection also requires a processor, because of the networking stack (even if it is a simple, peer-to-peer serial protocol). Processors do not operate “out of the box” because they require specialized software to operate. On the lowest power and cost systems, this software is often called firmware because it is difficult to change the software once the system is deployed in the field. Larger systems often use an embedded version of Linux, and some even run a version of MS Windows. Developing software on the larger systems is far easier because standard software development skills can be used. The smaller systems have higher development costs, generally for a similar amount of functionality. The hardware costs for the smaller systems, however, can be significantly lower. Fundamentally, all hardware technology subsystems of a data aggregator are available at low-cost today, but the software that is needed is only available at relatively high cost. Therefore, no particular hardware advance is needed to enable data aggregators. Software advances will provide value, but there are specific changes needed to enable truly low-cost aggregators. Typical Applications There are three common applications of data aggregators today: (1) to tie together multiple systems in a building when some systems are upgraded and others are left with legacy components; (2) for an operator who simultaneously manages several facilities that have disparate control systems that may not be connected, and (3) to use sensors to make local decisions7. In the first case, upgrading a building controls system, the data aggregator serves to join together new and legacy systems to provide better whole-building visibility and control. These systems could not be connected together into a single system normally (because of different vendors, incompatible versions, and other factors) but a data aggregator can provide the interfaces to achieve integration. Often the non-network connection (i.e., the connections discussed in this section) are used to connect to legacy systems because network connectivity, if it exists, may be using a proprietary Bus or protocol that is not supported by other systems or documented sufficiently for an interface to be created. The simple legacy input and output options are critical for this functionality because older systems often support these options and can be easily configured to “listen” to such signals or provide data using them. This type of deployment requires an aggregator box to be deployed on site, to physically interface to the legacy building systems.
7 www.digikey.com - viewed on August 1, 2012
C-6
The major issue with this use case is that these input/output options must be configured to operate on the various control systems. Although this is often possible and even relatively easy, it can be challenging, requires some site specific engineering, and the labor can lead to high costs. The second case, operation of multiple facilities, often occurs on campuses of multi-location corporate sites, where buildings, built over many years, have many different vintages or vendors of controls. Some companies provide solutions entirely based on getting data out of these buildings into a common web database for archiving and viewing by operators. This functionality goes beyond that of a simple data aggregator, but the data aggregator function is included in the service provided. An aggregator box is deployed, sometimes at each building. In other cases, existing legacy links can be translated in the Cloud to a new format and stored in the aggregation system. Every new building (or control system) requires some amount of engineering to connect with an aggregator. An engineer must identify the existing systems, the system’s software version, and available input and output options. They must then configure the aggregator to interface to those systems. Often, metadata must be manually tagged as well. A third case, a box that receives sensing information to make local decisions is common. A lighting system is a common example, where switch inputs, occupancy, and light level sensors are all used to make lighting control decisions. Relative Cost Impacts The cost of a data aggregation system is dictated by three items: hardware cost, non-recurring engineering (NRE) for setup, and license or service fees. The NRE and license fees tend to dominate the overall costs because data aggregation is primarily a software issue rather than a hardware issue. Each of these cost areas will be addressed as it pertains to signal form conversion, and a speculative discussion about lower cost future is included. Current Cost Impacts Hardware costs are relatively low, but these costs could be reduced. The lowest-cost data aggregator boxes are in the range of a few hundred dollars to a few thousand dollars, depending on capability and vendor. Server costs are comparable to any database server (typically thousands of dollars but less than $10,000). Servers are commoditized at this level, and costs are likely to follow market trends. The aggregator boxes, however, are highly specialized hardware that are priced higher than they would be in a high-volume, competitive market. Innovation is not required to reduce cost in any particular way, because volume manufacturing will drive design optimization and cost reduction. Breaking the hardware costs down into components shows that no single component is a cost issue. An embedded processor that is easy to use, widely supported in embedded Linux, and reasonably powerful (capable of running an embedded web server along with interfacing with multiple network links and many simple I/O options) is less than $10 in small volume8,9. Storage is becoming increasingly inexpensive. Hard disk drives have become very inexpensive on a per-gigabyte (GB) level (less than $0.10/GB retail), and solid-state storage has also become very low cost (less than $1/GB retail). For reference, 1GB of storage is roughly enough for 1 million readings. Depending on many variables, 1 GB can provide several days, to many months of
8 Tridium Sedona Framework, http://www.sedonadev.org/ accessed on August 1, 2012 9 The processor considered here is an ARM11, a popular embedded processor capable of running many embedded Linux distributions. The ARM11 has been widely used in applications ranging from the Apple iPad to the automation of large industrial systems.
C-7
data buffering. All other components are typically less expensive than the processor and storage components. The NRE for hardware design can be large. Small volumes are common, resulting in high per-unit costs because the NRE is amortized over the small volume. NRE costs for installing and commissioning these systems tend to be large. In many cases, there is little to no documentation on the meaning of various signals. This information must be extracted from paper documents, current system setup, technician knowledge, and, if needed, through trial-and-error efforts. When the systems are well documented, this process is relatively quick. Standard efforts to solve this problem take a week or more of engineering effort. Although the cost to integrate legacy connections with a data aggregator can be large, they are typically less than integrating building network interfaces (e.g., BACnet) that connect to building systems. Due to the closed nature of building controls systems and the high NRE costs of installing an aggregator at a site, vendors tend to charge high on-time or moderate ongoing fees for their services. Some products have a per-instance fee (typically thousands of dollars but can be as low as a few hundred dollars) as well as ongoing fees (tens to hundreds of dollars a month). This cost, sometimes partially buried in hardware costs, can dominate the overall cost. There are limited examples of open source solutions to the data aggregator problem8,10, and these efforts are not well supported in industry. System management is the final cost area. Hosting a local server appears relatively inexpensive, but there are ongoing costs associated with keeping a system patched and functioning. An employee or contractor must either be responsible for the system or the organization may experience downtime, service interruptions, and data loss, and this responsibility or reliability issue translates to a soft cost. Using a Cloud services for storage minimizes management and improves some aspects of reliability, but there are ongoing, hard costs associated with using this system as well. In addition, loss of Internet connectivity can result in service interruptions, depending on how the system is setup. All of these factors influence system management costs. Future Low-cost Possibilities A lack of documentation and poor standardization of controls limits cost reduction for integration into a new site. The integration problem is primarily a software problem rather than one of designing new chips and complex hardware. Reducing the labor required to bring a system up in a new site is the critical issue for making data aggregators cost effective in the market. Standardized control interfaces, improved documentation, and, eventually, plug-n-play building systems are required for low-cost. To enable plug-n-play systems, two key things must happen related to data aggregators. First, devices need to be able to identify themselves and provide significant metadata on customizations to the system. Second, a flexible, portable driver library needs to be widely available, so that a system can use the identification information to select and configure an appropriate driver from an existing library. Legacy building interfaces on data aggregators provide a critical function: they enable the relatively simple connection of new, IT-connected systems to legacy systems with limited capability. There are many types of legacy interfaces that are analog or digital, and each has a place where it performs well. A key limiting factor to the use of these legacy interfaces is that the metadata, information about how to interpret or adjust the information on the legacy interface is frequently poorly documented or unknown. As a result, drivers must be created on an individual interface basis to enable integration with data aggregation systems.
10 sMAP 2.0, http://code.google.com/p/smap-data/ viewed on August 1, 2012
C-8
Building Network Interfaces Networks, as discussed in this document refer specifically to computer networks11. Although the computers on the network may be quite simple (just an inexpensive processor with limited software and capability), the network provides data connectivity and the ability to share resources (e.g., storage, computation). Conceptually, networks are simple interconnections between devices to share information. In practice networks are complex software and physical systems with many opportunities for both confusion and failure. The software and hardware architecture of a network is called the network stack. Ideally, the stack consists of segmented layers with well-defined interfaces at the top and bottom to ensure interoperability and the option to replace any single layer with another compatible layer without the user noticing any particular changes in behavior. Figure C - 1 shows the open systems interconnection (OSI) model for a network stack11 [ISO/IEC 1994].
Figure C - 1: OSI model for a network stack, showing the name and number of each layer along with information about what happens at each layer11 [ISO/IEC 1994]
Layer 1 (the bottom layer) is called the physical layer (PHY) and includes the definition of how bits are encoded on the wire, over the air or encoded on other media. The most basic data processing aspects of the system, which include how the data is verified as valid in the most basic way, are included as well. Layer 2 is the data link layer—more commonly called the medium access control (MAC) layer12 because this layer controls how and when the devices decides to listen for a signal to receive or transmit a signal for others to receive. This layer also includes physical addressing (the MAC address to your computer, for example), and link layer (single hop) reliability. Layer 3 is the network layer, which plans a path for data to get from one location to another. Layer 4 is the transport layer, and it provides end-to-end reliability as well as flow control (how much data can be packed onto the link before it becomes unreliable or unusable to other users). Layers 5 and 6 are the session and presentation layers, respectively. These layers include management of ongoing communication sessions and end-to-end encryption among other things. Layer 7 is the application layer, and, as the name suggests, it handles the communication between applications on the devices at each end of the network.
11 Cisco, Internetworking Basics, http://docwiki.cisco.com/wiki/Internetworking_Basics 12 Technically, the MAC layer is a subset of Layer 2, with the remainder of Layer 2 being made up of the logical link control sublayer. This distinction is rarely made in most discussions.
C-9
An example application layer protocol is HTTP (Fielding et al. 1996). HTTP is the application layer protocol used by the web server on one end and the web browser on the other. Note this is different than HTML (Berners-Lee and Connolly 2005), which is the language used to encode the web page itself. This distinction is important because HTTP can be used to transfer any content, whether it is one of many versions of HTML or just some proprietary binary data. Just because two devices both have compatible stacks and are using the same application layer protocol, it does not mean that they can actually communicate. If the language of communication is different (e.g., HTMLv4 on the browser and HTMLv5 on the server), the browser will not be able to display the webpage correctly or respond to the server appropriately. In the networks of interest for this work, not all of these layers have equal relevance. Application, transport, network, link/MAC, and physical layers all play a role and will be used in the following discussion. This is not a section about networking in the direct sense, but it is critical to understand some networking basics in a discussion on network interfaces being used with data aggregators. The primary technical issues with data aggregators and building network interfaces are related to the large number of interfaces used and the wide variety of languages carried over these communication links. In most cases, the physical interfaces are (digital) network connections that may include RS-485 or similar on twisted pairs of wires, various wireless connections, digital communication over legacy analog links, among others and these are the interfaces of particular interest in this section. Common Network Interfaces This section will introduce many of the common network interfaces used but will not provide in-depth information about the specifics of the protocols themselves. The common network interfaces will be used primarily to introduce the variety of connection types across the network stack and set up discussion on the advantages, disadvantages, and challenges of particular network interface decisions. The most common network interfaces are over a single twisted pair of wires and include the most common BACnet13, MODBUS14, and LonTalk15 implementations, as well as countless proprietary network links. The primary advantage of this type of wiring is that the cabling is inexpensive (single-line telephone wire is often used) but sufficient for the low-bandwidth communication required in this application. The primary disadvantage is that running cable of any kind is expensive, and most network installers are unfamiliar with its use and awkward termination strategy. The limited bandwidth makes aggregation challenging because less bandwidth means fewer devices on the single network for a given communication latency and throughput per device. The physical interface in this case is often a set of screw terminals where stripped wire must be screwed into a connection point. RS485 links16, the most common Layer 1 used on this media, also needs “termination” resistors added to the end of the link to enhance reliability, and the addition of termination resistors is widely seen as a non-issue despite the obvious (and common) errors and faults that occur with their use. Many of these links use a token passing- or polling-based MAC method rather than a more modern MAC architecture. Legacy analog links can also provide digital data connectivity over a single twisted pair as well. The most common example is using a 4-20mA analog loop to carry network traffic. The highway addressable 13 ASHRAE SSPC 135, www.bacnet.org 14 http://www.modbus.org/ 15 Echelon Corp. "LonTalk Protocol Specification," http://www.enerlon.com/JobAids/Lontalk%20Protocol%20Spec.pdf 16 Guidelines for Proper Wiring of an RS-485 (TIA/EIA-485-A) Network, TUTORIAL 763, Nov 19, 2001m http://www.maxim-ic.com/app-notes/index.mvp/id/763
C-10
remote transducer (HART) protocol is the most common standardized version of this system17. In HART, both the legacy 4-20mA analog signal and a new digital signal riding on top of the analog signal can be used simultaneously for communication between a single device and a single endpoint. Alternatively, multiple devices can communicate with a single endpoint using the digital-only signal. This twisted pair link typically connects using screw terminals but does not require a load resistor simplifying installation. However, a link of 4-20mA loop also tends to be lower throughput than an RS-485-based link. HART links use a polling-based MAC. Ethernet- and TCP/IP-based communications provide the other most common methods of communication18. Ethernet consists of a specific set of physical layers, the most common of which are over four twisted pairs with a standard RJ-45 connector. So-called Ethernet cable is extremely cheap (comparable with telephone cable), includes standard and robust connectors, and is widely understood by installers. Ethernet also includes the ability to provide power over Ethernet using a standard mechanism widely used in the computer network industry. Using Ethernet and TCP/IP provides proven reliability, lower cost software development, and, in theory, communication on existing IT networks. MODBUS, BACnet, and LonTalk all provide a way to communicate over Ethernet. More important, the relatively high data rate (commonly 100 Mb/s) means that many devices can be included on a bus, and these devices can communicate a great deal of data without issue. However, the infrastructure required is far greater than for an RS-485 link because network switches are commonly used to connect devices. Ethernet uses carrier sense multiple access (CSMA)19 as its MAC method, and this provides advantages in both simplicity and performance compared to token passing or polling-based MACs. The last increasingly common network connection is a wireless connection. These span the use of IEEE 802.11 based Wi-Fi networks20 using TCP/IP to IEEE 802.15.421 based ZigBee22 or 6LoWPAN-based networks (Montenegro et al. 2007). Cellular data connections using SMS (short message service), IP-based, or other connections are also possible and popular in some situations. The MAC choices here are almost universally CSMA for LANs and a combination of time, frequency, and code division multiple access (TDMA, FDMA, and CDMA, respectively) for cellular networks. Some LANs like IEEE 802.15.4e (based on technology from Dust Networks)23do use TDMA and FDMA to provide higher reliability and network performance. Constraints Set by the Network Stack The network selected by the vendor of the systems installed in a building can limit the performance of the aggregator. In many cases, these links were included as either an afterthought or never intended to provide real-time access to the full set of variables available in the system. Because many systems share the same link, it can quickly become the case that although information can be extracted from the entire network, it comes at the price of significant restrictions on the sample rate and latency of the information. This section will particularly focus on decisions at Layers 1 and 2, as well as the top layer (application layer), rather than focusing on any specific network issues. 17 http://www.hartcomm.org/ 18 IEEE 802.3, http://www.ieee802.org/3/ 19 CSMA means that the device listens to see if someone is already transmitting on the media before it starts to transmit its message. Typically if the channel is in use, a “backoff” strategy is implemented, where the device checks the channel periodically to see if it is available to find a time to send its information. 20 IEEE 802.11 WIRELESS LOCAL AREA NETWORKS, http://www.ieee802.org/11/ 21 IEEE 802.15 WPAN Task Group 4, http://www.ieee802.org/15/pub/TG4.html 22 Zigbee Alliance, http://www.zigbee.org/ 23 IEEE 802.15 WPAN Low Rate Alternative PHY Task Group 4a, http://www.ieee802.org/15/pub/TG4a.html
C-11
In Layer 1, the data rate and resilience to interference or noise are directly related to the throughput and latency available for communication. These parameters are critical when considering how many devices can be supported on the network, and how much data can be reliably passed over the link. The encoding can affect reliability as well if error correction and/or error detection are included in the PHY (physical layer for OSI) specification. Timing of bits and synchronization signals must be precisely controlled, or no communication can take place. Data aggregators must implement multiple PHY protocols with the flexibility to adjust to slight variations in implementation from vendor to vendor. Even standards like RS-485 and RS-232 can take on a variety of bit rates, data setups, and checksum formats. The data aggregator not only has to deal with a network provisioned for a purpose other than providing aggregation services, it must also provide great flexibility. Layer 2 decisions can have a significant impact on throughput and latency as well, and the number of variations available for a particular MAC is very large. First, the MAC method impact is primarily on latency and reliability. In a token passing network, a device must receive permission from the network to transmit anything. The token (i.e., the permission) is passed serially around the network so each device has a chance to transmit. If the network is large, a device with much to say must wait to get the key and then may only have a specified amount it can transmit before it must pass the token on. Although this provides a degree of fairness, it makes networking less deterministic than methods where devices are allocated specific intervals for transmission.24 A CSMA MAC on wired links tends to be very high performance as long as only a few devices are trying to use the link at any one-time. TDMA links are very similar to token passing links in that a schedule determines when a device can transmit, but the amount of bandwidth allocated to any particular device can be increased or decreased according to need. Layer 2 implementation decisions regarding backoff, methods of access control (e.g., CSMA, TDMA) can make communication impossible between two devices with similar but slightly different MAC structures. Some MACs are implemented in hardware, and others are completely implemented in software. Hardware MACs tend to be highly deterministic (consistent transmission to transmission) but cannot be changed to match other systems. Software MACs often do not provide the same level of timing accuracy sometimes critical for operation but are flexible enough to accommodate a variety of systems. As a result, as much of the MAC as possible is implemented in software in most data aggregators. The low-cost of high-speed electronics and efficient software design strategies have enabled software MAC layers to be highly effective. It is not uncommon, however, for systems with different MAC implementations to be sold under the same nominal interface type, with the most common example of this being ZigBee. These systems can be completely incompatible at Layer 2 because of small variations in implementation. The interior layers of the stack must also be implemented in a compatible way or communication is not possible. This information is covered in the other networking sections, but the general issues are similar to those discussed in Layer 1 and Layer 2. For most of the non-wireless links discussed here, the interior layers are very simple and implemented in software, resulting in a high degree of flexibility being possible. The data aggregator must be aware of the selections in these interior layers to ensure interoperability. The application layers supported by the data aggregator must be broad enough to enable integration with a wide variety of systems. There are a large set of application layers, and this layer is the most common to be implemented as fully proprietary or as some proprietary variant of common application layer. Application layers include the top layers of MODBUS, BACnet, LonTalk, the Smart Energy Profile (and other ZigBee profiles), as well as Internet standards like HTTP, SNMP, and others. An important point is that implementing the application layer correctly is critical, but the determination of what 24 No method of communication is deterministic, in that errors are always possible because of a variety of factors. Some networks are more predictable than others.
C-12
information is communicated using the application layer is still left to the developer, with a great degree of flexibility. Bidirectional Versus Unidirectional Data Transfer Data aggregators and commissioning agents often must be able to interrogate the devices of interest to determine variables, gather metadata, participate in control, change set points, etc. Some links are only unidirectional (the device can talk but cannot listen). The key limitations of unidirectional data transfer are:
• A link can only support a single transmitting device because there is no MAC.
• There is no way to request information about the contents of its data packets from the transmitting device.
• Data are often asynchronous (not synchronized in time with other data sources), making analysis more challenging.
The addition of digital data on 4-20mA loops, in part, was done to alleviate these problems, and other methods have appeared over time as well. The end device must support these methods, however, for the data aggregator to be able to take advantage of them. The data aggregator must be robust to the issues with unidirectional data. Understanding Received Data The largest challenge for data aggregators is in understanding what to send and how to interpret what it receives. Despite all of the challenges identified thus far, the greatest complexity comes from the place where standards are least prevalent and system implementors take the greatest liberties. We will use BACnet as a key example because it has a standard set of objects and the ability to extract metadata (if it was programmed into the device) over the available network link. BACnet defines objects such as analog output, binary value, etc., and each of these objects come with a variety of properties. Examples include a name, identifier, type, description, flags, units, current value, and many others. Only the first three properties are required, however, and there are no standards as to how the other properties are filled in (or even if they are provided). Therefore, to commission a data aggregator it is common to come across BACnet objects where the properties useful for understanding the system are either cryptic or missing altogether. Unfortunately, BACnet is considered the easiest of existing protocols to integrate because vendors usually put some information into the objects and properties. In many other cases, there is no mechanism defined for extracting information about the data format from the system, and the data aggregator installation requires significant effort just to understand the data that is available over a link. Device Drivers for Data Aggregators A data aggregator system must have a driver for each connected device over a particular network link. That driver will specify not only how the network link itself is configured but also how to interpret the data that is received and how to format data to transmit it to the device of interest. Today drivers tend to be developed as needed by system integrators around the country and placed into that integrator’s local library of drivers. Customers pay for the NRE to develop a driver from their system from scratch in many cases. Some systems come with a library of drivers, but it is common for systems in the field to vary
C-13
somewhat from the design specifications, because of slight version changes in software, customizations to the facility in the field, or any number of other reasons. Therefore, even existing drivers often are edited or tuned to meet the needs of a particular application. These drivers form the backbone of the data aggregator and provide the largest value to the overall system. The commercial system with what is believed to the largest semi-portable driver set is the Tridium Niagra Framework25. Integrators around the country have developed drivers to a large number of systems, and there are some reports of sharing between integrators and Honeywell/Tridium and between Tridium and the integrators. This driver-based model is critical to the cost reduction and increased use of data aggregators in sensor systems. Open source alternatives to the relatively high cost Tridium Niagra Framework include the Sedona Framework26 and sMAP27. Sedona, owned by Tridium, is an open source implementation of Tridium Niagra without the licensing fees, but it has greatly reduced capability and driver support at this time. The sMAP system, developed by the University of California, Berkeley, is another open source project looking at developing drivers to interface to devices in buildings. Both Sedona and sMAP are software projects and the hardware to run these tools so they can interface to the physical network links is outside the scope of the projects. Characteristic Interdependencies Network interfaces in data aggregators have significant overlap with other areas of advanced control systems. There are many types of connections on data aggregators. The data aggregator’s network capabilities are the key reason that it provides so much value. Data aggregators typically provide two or more types of network connections:
• The connections to the devices of interest in the building. These connections are discussed in this section.
• The connection to a BAS, data archiver, or other tool. This connection is discussed in the data format conversion section on aggregators.
The missing components of highly successful and low-cost data aggregators are all associated with software libraries, standardization, and interoperability. The hardware, as discussed in the legacy interfaces section, is available and low cost. There are too many poorly specified or followed networking standards used by many poorly documented devices to enable a universal and low-cost aggregator solution. There are two potential solutions:
• A dramatic change in the way building systems are built and documented, to ensure that all systems are easy to interface with one another using a minimal amount of labor.
• A large and growing open library of device drivers that is easy to modify to new situations and apply to an open aggregator platform.
The first option is an important step toward an improved future because it enables low-cost and efficient buildings in a way that other solutions do not. This is a plug-n-play vision for building controls,
25 http://www.tridium.com/ 26 Tridium Sedona Framework, http://www.sedonadev.org/ 27 sMAP 2.0, http://code.google.com/p/smap-data/
C-14
where devices can provide enough information to the aggregator so that the aggregator can configure a skeleton driver to achieve full operation. However, this option is not particularly relevant in most retrofit situations, where only the monitoring (and perhaps controls) systems are to be replaced. If the legacy devices remain, they will not support the high levels of interoperability, automation, and documentation. This first option requires only limited technology advancement but significant changes in policy and/or implementer and customer decisions. Control systems currently are built with a reasonable model of the building physical systems either explicitly in the control system or implicitly through the design of the sequence of operations (e.g., the programmer knew there was a chilled water loop powered by a certain pump and cooling tower and built controls accordingly). It is very important to include a flexible controls description language that enables abstract control functionality to be applied to varying hardware configurations, to increase data aggregator usefulness and reduce costs. The second option is the intermediate solution that, if pursued, could reduce costs and increase market uptake in the relative near term. The library of drivers would need to be supported by a lively community of both developers and integrators to be successful. The key to the success of this model is that the aggregator and drivers are just part of the overall service. Tied in with the open aggregator would have to be features that create real value for the customer, such as fault detection and diagnosis and continuous commissioning, among others. Summary/Conclusions Building network interfaces on data aggregators provide a critical function: they connect BANs inside the building to new, IT-connected systems. There are many types of building network interfaces, and all of these networks strive to connect more devices together to pass more data between those devices. A key limiting factor to the use of a data aggregator with building network interfaces is that the links and the data carried on the links are often not well documented. It is time consuming and expensive to build drivers to interface to the many unique systems in existence, and this lack of documentation and drivers limits the use of data aggregators more than any single other factor. References ISO/IEC. 1994. "Information technology -- OSI -- Basic Reference Model: The Basic Model," ISO/IEC 7498-1:1994. TIA/EIA-485-A. 2001. Guidelines for Proper Wiring of an RS-485 Network, TUTORIAL 763, Nov 19, 2001, http://www.maxim-ic.com/app-notes/index.mvp/id/763 Ganssle, J. 2008. Embedded Systems, Elsevier, 2008. Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. 1999, Rfc 2616 – hypertext transfer protocol – http/1.1. Technical report. Berners-Lee, T. and D. Connolly. 2005. Rfc 1866, Hypertext Markup Language - 2.0. Montenegro, G., N. Kushalnagar, J. Hui, , and D. Culler. 2007, Rfc 4944 – transmission of ipv6 packets over ieee 802.15.4 networks. Technical report.
D-1
Appendix D
D. Control Retrofit of a Medium-Sized Commercial Building: Case Study
D-2
As previously stated in the main body of the report, three identical medium-sized office buildings were upgraded from standalone thermostat control design, to a building automation system (BAS) control design (similar to the configuration defined in the section titled, Building Automation System for Medium-Sized Commercial Building). These office buildings (all approximately 20,000 sf each) are geographically located adjacent to each other in a business park located at the north end of the City of Richland, Washington. The three buildings are part of a four-building complex, and they include Building 2, Building 3 and Building 4. The fourth office building (Building 1) which is also part of this complex (located on the same city block), was not included in the controls upgrade.
This case study will discuss the reasons for performing this BAS controls upgrade to Building 4, the energy performance of Building 4 before/after the BAS controls upgrade and the positive/negative impacts to building occupants before/after the BAS controls upgrade. This case study will highlight installation details, the “before” and “after” energy patterns of Building 4 and what efforts were undertaken to improve energy efficiency (consumption, demand and overall energy costs). Finally, this case study will look at the design and installation costs to upgrade the office buildings to new HVAC BAS controls, the features embedded in the new HVAC BAS controls and what the estimated paybacks are for the upgraded controls. Similar conclusions can be made for the other two buildings (Building 2 and Building 3). Building Description Each office building was built approximately at the same time in the late 1970s, and each is approximately 20,000 sf and has a similar foot print. The use of the space inside each office building (number and size of individual offices, number and size of conference rooms, number and size of special use spaces and information technology closet spaces) differ only slightly. The geographical orientation of each building is slightly different, the number of HVAC systems serving each building (their size, age and efficiency) is slightly different, and the HVAC maintenance service for each building is from a different service provider. In spite of these subtle differences, prior to the HVAC controls upgrade to a BAS in Building 2, Building 3 and Building 4 (Figure D - 1), the annual energy consumption and EUI in Btu/sf/yr for each building were very close. The results discussed are a comparison for 3 years (2009 through 2011). This allows for before (2009), during (2010) and after (2011) comparisons in regards to energy savings and performance. With most BAS upgrades, there is a period of “optimization” and learning (re-tuning) that must occur.
D-3
Figure D - 1: The Picture shows Building 4 the other 3 Buildings surround this Building
The major building characteristics for Building 4 include:
• 20,530 sf., single story on concrete slab office building (designed for between 80 and 90 occupants), 11 rooftop units (all electric, all but one is heat pump).
• 36 perimeter offices, 44 interior offices, 3 conference rooms, 1 lunch room, 1 lobby, 4 bathrooms, 2 LAN rooms and one mechanical/electrical room.
• The window/wall ratio is approximately 17% and the wall perimeter is 680 linear feet.
Existing HVAC systems and controls description:
• 11 rooftop units (most heat pump design, with second stage electric heat)
• Programmable thermostats with limited remote hardwire temperature sensor averaging.
• No holiday scheduling or optimal start sequencing.
• No networking capabilities (to share outdoor air temperature value between thermostats, scheduling, etc.)
• No remote diagnostic, alarming or trending capabilities.
• Schedules for each rooftop unit in the thermostat were generally set too early (between 3 a.m. and 5 a.m.) and were generally shutting off too late (between 7 p.m. and 9 p.m.). This was done as a “just in case” action when weather was more severe, or units were not being maintained properly.
D-4
• Weekend scheduling configured for 4 to 8 hours (another “just in case” action if it was too warm
or too cold outside).
BASs was installed in 2010. Building 4 HVAC controls BAS upgrade description:
• All rooftop units were heat pumps (except for one). There was a dedicated rooftop “DX cooling only” unit installed to serve a high heat generation space (primarily computer equipment and LAN closet space).
• A new programmable thermostat that communicates with a BAS head-end was installed at each of the existing thermostat locations. A hardwired (three-wire) communication BUS was routed from thermostat to thermostat location in the building, to allow for networking and communications with the BAS “network controller” (NC), which functioned as a master controller (similar to the one shown in Figure 17).
• A wireless temperature sensor monitoring network was created and installed throughout the building. This network is truly “wire-less” and consists of temperature sensors located in more than 50% of the office spaces and also includes wireless sensors in most of the roof top units so temperatures in the mixed air, discharge air and return-air spaces can be monitored. This provides for additional trending, alarming and diagnostic capabilities (such as calculated outdoor air fraction to help determine if economizers are working properly, etc.).
• The communications network allows for sharing and configuration of common data points like outside air temperature, occupancy and holiday scheduling, data analysis of the different rooftop unit’s system performance via trend logs, historical data and alarming.
• Whole building electrical metering was provided as part of the BAS upgrade scope. The electrical meter was integrated into the BAS and provides real-time and historical data analysis of the building.
• In most cases, each of the existing rooftop units has a built-in economizer section with integrated economizer controller and actuator. The new programmable thermostats do not directly control the economizer section on any of the rooftop units. The new programmable thermostats are simply “integrated” to the economizer via the internal rooftop unit wiring. This means that when a call for cooling from the thermostat occurs, the existing rooftop unit economizer controller will pre-empt the mechanical cooling and open the outside air dampers – when outside conditions are favorable for cooling. Otherwise, mechanical cooling will be allowed to activate.
Thermostat and NC Capability Descriptions In this section thermostat and NC capability is summarized. New Programmable Thermostat Capabilities The major focus for the BAS upgrade in Building 4 was on upgrading the existing programmable thermostats. Figure D - 2 shows typical existing thermostats that were found in Building 4.
D-5
(A)
(B)
Figure D - 2: Photograph of Old and New Thermostats in Building 4 Before and After They Were Replaced
While these thermostats provide for scheduling a setback period, they are not intelligent enough to provide for the following capabilities (which the newer thermostat shown above, provides):
• Integrate an outside air dry-bulb temperature reading, to allow for disabling (lockout) of heating or cooling.
• Integrate an outside air dry-bulb temperature reading, to disable the auxiliary electric heating, when heat pump vapor compression heating cycle should be adequate (heat pump only feature)
• Provide for automatic push button override (push button is remote from the thermostat to obtain after-hours occupancy for up to 2 hours). This alleviates extending the existing schedules or adding more schedules.
• Local display of outside temperature, local zone (averaged) temperature, fan status, heating or cooling mode and equipment maintenance status (dirty filter, compressor failure, etc.).
• Local adjustment of thermostat parameters (heating/cooling occupied and unoccupied set points, dead bands, outside temperature lockout set points, equipment cycles/hour settings, minimum on/off timers, etc.).
New NC Capabilities The new network controller (master controller) that was added as part of the controls upgrade and its capabilities include:
• Holiday scheduling (up to 8 to10 holidays/year).
• Integration of new wireless temperature sensors (up to six per heat pump) to provide for average temperature response from the spaces served by the heat pump. The existing thermostats allowed for remote “hard wired” temperature sensors (only up to four) to provide the same function but at greater cost and less flexibility (hardwired versus wireless).
D-6
• Optimal start sequences to account for warmer or colder weather, which allows schedules to remain tight (rather than pushing the schedules out to earlier start times and delayed shut down times – “just in case”).
• Individual rooftop unit scheduling adjustments for occupancy and vacancy.
• Development of “master” set point for each rooftop unit that automatically creates the desired dead band (typically 4oF) and tells the thermostat what the local heating and cooling set points should be.
• Automatic high-low temperature override of the heat pump to occupied mode, in response to extreme outside temperature conditions (beyond design conditions to allow for adequate recovery). This helps eliminate operator overrides that occur when HVAC systems do not adequately recover office space temperatures.
• Alarm reporting, trend logging and network interface to programmable thermostats and building management staff from inside (dedicated workstation) and outside (web access) the building.
• Synchronization of network global time functions (real-time clock synchronization and daylight savings time changes).
• Global functionality, including data sharing between heat pumps of common data such as outside temperature, time, calculated optimal start times (individual times for each heat pump), network access security (passwords) and DR functions related to electrical power (demand limiting, load rolling).
• Totalizing of equipment runtime (in hours) for indoor fans, compressors and other connected end-use loads allows for use in maintenance actions and capital equipment replacement discussions.
Control Upgrade for Building 4 In this section the controls upgrade for Building 4 are summarized. The hardware installation included adding new networked thermostats for each of the existing rooftop units, six wireless temperature sensors for each of the existing rooftop units and a networked controller (master controller). The addition of six wireless temperature sensors provides additional temperature information that is averaged with the thermostat temperature and used to control the rooftop unit. Before the BAS upgrade, only the thermostat controlled the rooftop unit leading to some hot and cold rooms. Access to the new control (BAS) network can be via web-based access or via dedicated workstation access. Building edge metering was added as part of the BAS upgrade scope. The metering interface to the BAS provides real-time and historical data analysis, which can be used to detect problems with the building’s HVAC performance or other electrical end-use loads (lighting, plug loads, etc.). In addition to the hardware, the NC was programmed to enable the following features:
• Holiday scheduling added (eight holidays/year).
• Optimal start capability added.
D-7
• Schedules for the rooftop units were tightened (the new schedules staggered start times between 5 a.m. and 6 a.m.) and (all units turn off at 6 p.m.); these schedules apply Monday through Friday. The units are completely off on weekends.
• Heat pumps serving perimeter zones activate first to attempt to hold the core of the building at temperature thresholds to mitigate excessive heating or cooling loads on all heat pumps.
• Automatic night low and high limits maintain spaces no lower than 64oF and no higher than 82oF. Widening these set points will save more energy at night and on weekends, but may impact morning warm up demand issues. If the building had gas heat, it would allow for lower setback temperatures.
• Automatic outside air low temperature override added to keep from adding “just in case” scheduling on weekends and to keep from widening schedules during the weekday periods. When the outdoor air temperature falls below 25oF, the rooftop units run continuously.
• Removed the weekend scheduling with the above noted improvements.
• New thermostats accept global outdoor temperature sensor input (which supports heating/cooling lockouts at the rooftop unit). The thermostats can have their own individual outdoor temperature sensor (more cost for sensors and wiring) or they can have a global outdoor temperature value “pushed” into the thermostat, via the communications BUS. This saves cost and eliminates complexity.
• Remote push button thermostat occupancy override input allows for after-hours occupancy (night/weekends) if required. This alleviates adding or modifying schedules (“just in case” or for one-time or unplanned events). This also provides a means to obtain occupancy if the BAS NC fails or experiences a communication failure. When schedules are added for “unplanned events”, the schedules often remain in place long afterwards and are not removed in a timely manner. Keeping schedules and overrides to a minimum is one of the keys to successfully reducing energy cost and consumption.
• Created 4oF dead band between heating and cooling (previously the dead band was 2oF), driven by master set point. Wider dead bands can cause comfort issues, but with wireless zone temperature monitoring and averaging, most of the occupant complaints have gone away. Wide dead bands simply would not be possible without having additional sensor/monitoring capabilities.
Scheduling Improvements Scheduling of building HVAC units (heat pumps) was improved. The new control sequence alternates the start timing for all perimeter units and uses an optimal start routine that is based upon the outdoor-air temperature to pre-start during warmer (>65oF) or cooler (<45 oF) outside-air temperature conditions. The original programmable thermostat schedules use to start as early as 3 a.m. to 4 a.m.and run as late as 7 p .m. -9 p.m. This also included Saturdays and some Sundays. The new schedules are configured for no earlier than 5 a.m. occupancy 6 p.m. vacancy, weekdays only. If the optimal start routine determines the need for an earlier start time for the perimeter units, the earlier start time will be no earlier than 3 a.m. Holiday scheduling was non-existent in the original programmable thermostats. With the new networked thermostats, holiday scheduling (up to 8 holidays/year) have been added.
D-8
Night Set Back Improvements Night set back set points for heating and cooling were created to mitigate excessive warm up and cool down issues (as well as peak demand issues in the winter when electric heating is often required). The original programmable thermostats were often not configured properly for setback operations. This would result in complaints that resulted in widening the schedules to start earlier in the morning and run later at night (minimize occupant complaints). The new controls allow for temperatures to drop down to 64oF or 65oF at night for heating and rise up to 81oF or 82oF at night for cooling. If the outside-air temperature drops below 25oF, the perimeter heat pumps are all indexed back to their occupied mode to maintain the building during cold weather conditions. This was done to mitigate problems related to the building age, envelop issues and equipment designs. This also helps avoid comfort complaints, which result in operator overrides to the HVAC schedules. Overrides to programmable thermostats or BAS set points are one of the main reasons for energy waste. In addition, each thermostat has push-button override that provides occupants with the capability to remotely activate the heat pump serving the zone back to occupied mode for a fixed (default = 2 hours) time. This also helps mitigate problems from operators setting up temporary schedules or widening existing schedules. Thermostat Management Set points originally were configured to have dead bands between heating and cooling of 2 degree F. This was widened to be 4oF, so if the set point is a value of 72oF, the heating would not activate until the space temperature drops below 70oF F and the cooling would not activate until the space temperature rises above 74oF. Normally, this could create challenges so a wireless temperature sensing network was also integrated to provide wireless temperature sensing for 4 to 6 office spaces per heat pump zone. These temperature sensor values are averaged together with the thermostat’s temperature sensor value and this becomes the “sensed” space temperature for the heat pump. This has a favorable response with fewer complaints from the occupants, as the heat pump is controlling to the average temperature. Typical office environments may have the thermostat in a locked office. When the occupant is gone (vacation, business travel, sick, etc.), and the door is closed, the thermostat often is not “seeing” the temperatures of occupied spaces and this can produce unintended heating or cooling that wastes energy and results in occupant complaints.
The NC provides easy access to control parameters and sensor values (including wireless sensors) allowing for remote diagnostics, alarming and data trending capability, which supports long-term sustainable operations and persistence of energy savings. This building also has six, roof-mounted exhaust fans. These exhaust fans serve bathrooms, conference and lunch rooms. The exhaust fans serving conference rooms and lunch rooms are connected to wall-mounted electric switches and these exhaust fans operate when the switches are turned on. The conference room exhaust fans are a legacy to the past, when smoking was allowed in public buildings (conference rooms primarily). As part of the BAS upgrade, the exhaust fans in the conference rooms were removed because they were no longer used (public building smoking ban) and to prevent cold/hot air infiltration into the building (no backdraft or isolation dampers). The exhaust fans serving the bathrooms in this building run 24/7. Although these fans could be controlled with the BAS, they were not connected to the BAS during this retrofit. They should be connected to the BAS in the future. Cost of Controls Upgrade The cost of the controls upgrades for both hardware and labor cost is summarized in this section for Building 4 (the costs are similar for the other two buildings):
• New programmable thermostats ($250 each x 10 thermostats) = $3K
D-9
• New wireless sensors ($50 each x 60 sensors) = $3K • New wireless sensor integrator with repeater (1) = $1K • Network infrastructure (hub/switch, network controller, network integration, cabling) = $6K • Labor (design/engineering, install new thermostats, network infrastructure) = $7K
The total installed cost for the controls upgrade for Building 4 is approximately $20K. Before and After Energy Consumption Comparisons As indicated previously, the installation of controls was performed in year 2010. Using the Energy Charting and Metrics (ECAM) tool, the interval data from the buildings was used to generate a series of charts and analyzed (ECAM ref.). Figure D - 3 compares the average whole building electricity load profiles from year to year for Building 4. As seen, the performance of the building over the 4-year period has improved or consumption reduced, both during occupied period (6:00 a.m. – 6:00 p.m.) and during unoccupied period (6:00 p.m. and 6:00 a.m.). The electricity consumption both during retrofit (2010) and after retrofit (2011 and 2012) decreased significantly compared to pre-retrofit period (2009). In 2012, more aggressive nighttime setback was used, which caused an increase in early morning peak. Because this building is an all-electric building with heat pumps and backup strip heating, the backup strip heating was being called to make the building meet the occupied set point. The reductions during the occupied period are from increasing the dead band between heating and cooling set points. The reductions during the unoccupied period are from use of more aggressive setbacks (heating) and setups (cooling) and also tightening the schedules.
Figure D - 3: 4-Year Performance Chart for Building 4
Figure D - 4 and Figure D - 5 compare the before and after retrofit weekday and weekend average whole-building load profiles. The trends are similar to the load profiles described previously. For weekday, the average reduction during occupied period is 15% and during unoccupied period, it is closer to 30%. On weekends, there is almost a 30% reduction through the day.
D-10
Figure D - 4: Weekday Load Profiles for Building 4 Before, During, and After BAS Upgrades
Figure D - 5: Weekend/Holiday Load Profiles for Building 4 Before, During, and After BAS Upgrades
Figure D - 6 compares pre- and post-hourly whole-building electricity consumption as a function of outdoor dry-bulb temperature for Building 4. Temperature-dependent consumption during unoccupied
D-11
hours can be attributed to heating during the winter season when the outdoor air conditions become very cold; thus, the building must be heated to maintain the setback temperature. However, the temperature dependent portion of the load during unoccupied periods is significantly lower in the post-period compared to the pre-period. This is consistent with the lower setback temperatures and tighter schedules during the post-period. Figure D - 7 shows box plots for Building 4 before and after BAS upgrades ((a) and (c) for weekdays, (b) and (d) for weekends/holidays). When comparing the weekdays before and after BAS upgrades, the total consumption, on average, is slightly lower. However, the control of the building is much tighter, i.e., the spread of the data around the mean is much smaller after the BAS upgrades were implemented. This is also true of weekend/holiday box plots. Energy Savings Finally, empirical models were developed to estimate the actual energy savings and normalized energy savings energy for Building 4. Modeling included development of segmented linear regression models (five parameter models) for two periods: weekdays and weekends. Using the 2009 data, pre-BAS upgrade models were developed; similarly using 2011 data, post-BAS upgrade models were developed (Figure D - 8). After generating the models, savings estimates can be generated for the post-period (i.e., after BAS upgrades) for the entire year. This can be done for the actual post-period weather data, or for historical TMY data, as shown in Table D - 1. The energy savings (utilizing actual or historical weather data) is roughly 22%.
Table D - 1: Electricity Savings Analysis for Building 4 from Pre- and Post-BAS Upgrades
Weather Data Actual TMY Projected Baseline Energy Consumption (kWh) 361,135 346,562 Projected Post Energy Consumption (kWh) 283,470 269,498 Energy Savings (kWh) 77,666 77,064 Percentage Savings from Baseline (%) 21.5 22.2
Table D - 2: Electricity Cost Savings for Building 4 from Pre- and Post-BAS Upgrades
Year Electricity Cost ($/yr)
Average Electricity Rate ($/kWh)
Normalized Electricity Cost ($/yr)
Percent Difference Compared to 2009
2009 $17,120.92 $0.05 $20,241.86 0 2010 $13,315.00 $0.05 $14,889.31 26 2011 $15,122.91 $0.06 $15,122.91 25
D-12
(a)
(b)
Figure D - 6: Whole Building Electricity Consumption vs. Outdoor Air Temperature for Occupied and Unoccupied Periods (a) 2009 (pre) and (b) 2011 (post) for Building 4
D-13
(a)
(b)
(c)
(d)
Figure D - 7: Boxplot for Average Load Profile for Weekdays (a) and Weekends (b) Pre-Upgrade, as Compared to Weekdays (c) and Weekends (d) Post-Upgrade for Building 4
D-14
(a)
(b)
(c)
(d)
Figure D - 8: Segmented Linear Regression Models for Building 4 for Weekdays and Weekends Pre- and Post-BAS Upgrades: (a) Weekday Pre-Upgrades (b) Weekday Post-Upgrades (c) Weekends Pre-Upgrades (d) Weekends Post-Upgrades
D-15
Potential Future HVAC BAS Control Improvements
• Automate miscellaneous loads such as bathroom exhaust fans, domestic hot water pump and interior hallway lights and exterior parking lot lights. Building 3 has partial automation already in place for the bathroom exhaust fans.
• Install/integrate hardwired push-buttons to each programmable thermostat, for 2-hour scheduled override for nights, weekends or any unplanned event that might occur “after-hours”.
• Fix economizers (sensors and controls) and possibly integrate to the BAS/rooftop controls or leave as standalone with diagnostic capability in the BAS (wireless sensors).
• Upgrade existing constant volume control to variable frequency drive (VFD) control.
• Use capabilities in existing BAS that are currently not used, but lying dormant. This includes DR, load rolling, etc.
• Integrate occupancy sensors for lighting (not many spaces have them currently) to the BAS to more “intelligently” control the roof top units. This might include placing the rooftop units into unoccupied mode earlier (based upon the “calculated” occupancy rate) or widen the dead bands when most spaces served are vacant (or something similar).
• Link/synchronize the conference room scheduled occupancy (in Microsoft Outlook®) with roof top unit’s schedule, so the rooftop unit only runs when the space has a scheduled meeting (if the meeting was not scheduled or Outlook and the link fails, the override button will still allow for occupancy activation).
Potential Future Technology Improvements
• Small building BAS controls with web access could include linking spaces like conference rooms to Microsoft Outlook calendar scheduling, so the dedicated conference room heat pumps remain unoccupied until 15 minutes prior to the scheduled meeting. A push button override (as described earlier) would provide the means to activate the HVAC when an unplanned use of the space is required.
• Small building controls with web access could include linking office spaces to the occupant’s Outlook calendar, to know if they are on travel or out of the office for an extended period of time. This would allow for the BAS control system to “ignore” their space temperature, if the deviation was causing an excessive energy response.
• Small buildings with web access could allow for individuals to “volunteer” their office space to be part of a load shed scheme. This could include signing up for warmer/colder temperatures (depending upon the season), wider zone temperature dead bands and/or total HVAC reductions (no ventilation, no air tempering) for up to a maximum period of time. This could include a tiered preference for times of the day that the occupant is willing to participate. This would most likely be some type of social application interface through the web access interface and/or the BAS and would allow for automatic demand response (ADR) actions.
D-16
Case Study Conclusions One of the biggest challenges in upgrading these three buildings to BAS is that they are leased buildings. They are owned by (two) different entities and have different road blocks for participating in this type of upgrade. As leased buildings, the challenges presented here may be even more typical than other buildings that may be owned and managed differently. After 2 years of consistently low energy consumption (reduced EUI), all three buildings were accepted by EPA’s Energy Star program and recognized with awards. The management team that deals with occupant complaints saw a dramatic decline in comfort-related complaints, after the upgrades were completed. This fact (improved occupant comfort) is a testimony to the benefit of upgrading a building to a BAS with the capabilities noted. More small building owners should be looking at the long-term benefits of a BAS upgrade that includes existing technologies such as wireless sensing, remote accessibility and programmable thermostats or controllers at the rooftop unit equipment that can take advantage of global functions that include creative scheduling of occupancy and holiday events and integrating other data such as outdoor temperature sensor values and wireless temperature sensor values and power meter data/DR data.
E-1
Appendix E
E. Use Case #1: BASs for Small Buildings
E-2
Description A service provider company wants to offer small building owners a building automation system (BAS) installation service (upgrade existing or install new). In small commercial buildings, typical end use loads to control include heating, ventilation and air conditioning (HVAC) systems, lighting and a few “general purpose” loads (up to 5,000 sf, as shown in Figure E - 1). Most buildings of this size are not served by a BAS and often have “standalone” services (thermostats, time clocks, manual light switches, etc.). These standalone controls have limited intelligence and do not communicate with each other and/or with outside services (web-accessible via wired and/or wireless Internet or similar infrastructure).
Figure E - 1: Schematic of a Typical Small Commercial Building with Various End-Use Loads
A building of this size has two to three packaged rooftop units or split systems for comfort cooling and heating; these systems are controlled via standalone thermostats. The lighting fixtures in the offices or occupied spaces are typically controlled by manual switches and in some cases, interior exterior lights are controlled by time clocks and exterior lights are typically controller by photocells. The other end use loads like the bathroom exhaust fans, domestic hot water system and miscellaneous plug loads are either not controlled or manually turned on/off by building occupants. A small building owner wants to install a “simple” locally configurable BAS option. The owner is not interested in outsourcing the monitoring of the building systems. Also, the building owner is not interested in replacing the existing lighting fixtures or ballast. A simple scalable BAS consists of a set of communicating programmable thermostats, a gateway device and software to monitor the building system, as shown in Figure E - 2. For the purpose of complete systems integration, a gateway/supervisory controller is provided to allow for disparate systems to be connected and integrated together, creating a fully functional, fully interoperable and intelligent BAS. The dashed lines in Figure E - 2 indicate that the communication between thermostat/controller and the gateway device can either be
E-3
hardwired or wireless. While improving the energy efficiency of the building, this solution can also be leveraged to make the building and its system more grid responsive.
Figure E - 2: Simple BASs with Local Configuration Option for Small Buildings
The thermostats communicate with each other and with outside services through the gateway controller. This option could also have some general purpose controllers to control exterior lighting or miscellaneous end-use loads. The connection of the various hardware components may be through a wired, wireless or combination (hybrid) of both, using an open, industry standard to enable reliable communications to all components. In most existing buildings, a hardwired solution may not be cost effective so a wireless solution is needed. For new construction, a wired solution may be cost effective. The core functionality of the BAS is to keep the building occupants comfortable, monitor and trend the performance of various systems (including whole-building energy consumption and demand) and provide notification of device failures via local alarming or remote text messaging or email of alarms to the maintenance staff. The gateway device at the building level coordinates global functions such as scheduling, alarming, trending, and sharing global information with all controllers on the network. For a typical building of this size and anticipated lighting systems in use in the buildings, it is not generally cost-effective to install lighting controllers that can be managed and controlled from a central location. So, the interior lighting fixtures should be controlled with individual light switches with occupancy sensor that would turn the lights off when the space is not occupied, unless a cost-effective lighting solution can be found. This configuration also allows other BAS functions that that empower the owner/user for more efficient building operations to occur. These functions include: 1) alarm notification of equipment failures, comfort problems or other related problems that need immediate attention; 2) trending and storage of data pertaining to equipment operations and occupant environment; 3) energy saving strategies; 4) web-access for remote notification and configuration/interaction to the building; 5) linkage to other web-enabled services including dashboards, analytical services, intelligent (smart) grid responsive for automatic load shedding, whole-building metered energy performance, etc.
E-4
Scope Design and install (or upgrade) an existing small commercial building with a new (or upgraded) BAS that is affordable and capable of achieving between 15% and 30% energy reductions with simple paybacks of no more than 5 years. Stakeholders
1. Utility – sells either electricity or gas to the building owners and also provides incentives to the building owners to increase energy efficiency by upgrading older BAS or installing new BAS in their buildings (including allowing for automatic demand response capability).
2. BAS service provider or controls vendor – sells BAS upgrade services.
3. Building owner – owns and manages the building, may not be responsible for the energy bills.
4. Building tenant – does not own the building, but pays the energy bills for the building.
5. Facility manager – manages the operations of the building that is being upgraded.
Actors
1. Building owner.
2. BAS service provider or controls vendor.
3. Building operator/engineer/custodial staff.
4. Facility manager.
5. Building technician and mechanic – maintain and operate the building systems within a building.
6. Building tenant/occupants.
7. Control consultant (vendor or integrator).
Usage Scenarios
1. BAS service provider identifies basic building information
a. BAS service provider collects location, gross floor area, number of floors from the facility manager/owner/operator.
b. BAS service provider collects gas and electric utility bills (minimum 12 months), rates from the building owner/facility manager.
E-5
c. BAS service provider collects occupancy schedules for the building from the building operator/facility manager.
d. BAS service provider collects HVAC systems, lighting systems and miscellaneous buildings systems information from building operator/facility manager
i. Number and type of rooftop units (RTUs) or split systems and sizes; and zones they serve. This determines the type of smart thermostat or smart RTU controller interface, as well as potential control improvements that might be considered (beyond smart thermostat control). Potential control improvements might include integrated economizer controls, demand controlled ventilation (DCV) controls and variable frequency drive (VFD) controls.
ii. Number of bathroom and general exhaust fans and their control access location (wall switch or distribution panel).
iii. Number of common space lighting circuits and their control access location (wall switch or distribution panel).
iv. Number of hard-walled office spaces and lighting circuits per office.
v. Location of other miscellaneous loads and their control access location(s). This can include (but not be limited to) domestic hot water systems, IT/LAN spaces and their dedicated cooling/ventilation systems, etc.
vi. Determination of the gateway/supervisory controller to fully integrate various controllers dedicated to RTUs, lighting, general purpose end-use loads and wireless infrastructure capabilities (sensors, communications, etc.).
vii. Other – determine monitoring and control hardware requirements for the various building systems. This includes a determination of the requirements to monitor status of fan and compressor, but could also include monitoring filters (pressure drop) other related equipment. This also includes the number of sensors for temperature (indoor offices), the number of smart thermostats or smart controllers, and additional temperature sensors for RTU performance (mixed air, return air, discharge air) as well as outdoor condition monitoring (temperature/humidity). If additional control features (DCV, differential economizer, etc) are required, this will mandate additional sensors for humidity, CO2, etc. Wired versus wireless or both (hybrid) are also determined during this phase.
e. BAS service provider collects current (or recommended) HVAC equipment control sequencing, schedules and set point requirements from the building operator/control consultant as well as lighting systems and miscellaneous equipment control sequencing, schedules and set point requirements:
i. HVAC system occupied/unoccupied schedule configuration requirements including set points during each mode and RTU fan operations during each mode (continuous run, cycling on call heating/cooling, etc.).
E-6
ii. HVAC system optimum start/stop configuration requirements including target temperatures and times.
iii. HVAC morning warm up/night setback configuration requirements including methods to implement temporary override and length of override (push button, web access, etc.).
iv. HVAC night purge configuration requirements – related to scheduling of ventilation dampers and general exhaust fans, etc., prior to occupancy.
v. HVAC economizer (type of control – dry-bulb, enthalpy, differential enthalpy) and configuration requirements (set points, dead bands, integrated with mechanical cooling, etc.) as well as sensor/instrumentation needs to enable control requirements (dry-bulb, humidity, CO2, etc.).
vi. HVAC economizer feature improvements (DCV, etc.) requirements, if any.
vii. Lighting schedules for interior/exterior lighting.
viii. Lighting set points for dimming and daylight control applications (if applicable).
ix. Schedules for general purpose equipment (exhaust fans, domestic hot water, etc.).
x. Specialized building sequences (motion sensor interlocks for lighting and/or HVAC systems, rollup door interlocks to disable HVAC systems serving loading dock areas, hardwired push buttons or web access for night/weekend overrides of end-use loads, free cooling/night over-cooling based upon weather forecasts, etc.).
xi. Automated demand response control sequences for the various systems that can be coordinated from the central location.
f. Infrastructure requirements to meter whole-building electricity (consumption and demand) and gas consumption and integrate them with the BAS (including any sub-metered electric loads in the building) as directed by the consultant or owner.
g. BAS service provider determines if the building has “special process end-use” spaces (IT server rooms, auditorium, conference rooms, food prep spaces, etc.).
i. Determine the number of rooms.
ii. Determine the number of cooling/heating systems serving each room and equipment types/capacities.
iii. Determine the control and/or monitoring upgrades of the rooms and their dedicated HVAC systems.
2. BAS service provider determines the infrastructure requirements (Cloud, web, remote or site-located server, etc.) to support the new BAS requirement for trend logging of at least 50% of the BAS point count at a minimum trend interval of 15 minutes.
E-7
3. BAS service provider determines the infrastructure requirements (Cloud, web, remote or site-located server, etc.) to support the new BAS requirement for trending data, alarm monitoring and notification as well as storage of historical data for retrieval and analysis at a later time.
a. BAS service provider determines infrastructure to support long-term data storage and retrieval of alarm data and trended data. Energy-related data (whole-building energy metering and sub-metered data) shall be stored for up to 5 years, if not longer.
b. BAS service provider designs the infrastructure to ensure the successful alarm monitoring and trending of all major building systems and end-uses identified in Step 1:
i. The frequency of data collection should be between 5-minutes and 15-minutes.
ii. Data shall be collected and stored in such a way that the building performance can be characterized during occupied and unoccupied periods and also during weekdays and weekends, over any period of time in the last 12 consecutive months (summer, winter and shoulder months).
4. BAS service provider provides a suggested design with total control and monitoring list of various HVAC, lighting and miscellaneous systems, along with suggested control sequences, based upon 1-3 above. BAS service provider also identifies control sequences that will make major buildings systems to be grid responsive. The control sequences used for operations and to make the systems grid responsive must be standard sequences that are industry approved. Any omissions by the BAS service provider or any requested deletions by the building owner should be documented for future reference and resolution prior to or during the installation phase.
5. BAS service provider determines the total cost of design, installation and startup/warranty, training and any required measurement and verification (M&V) actions as directed by the control consultant or building owner. BAS service provider also works with the control consultant or building owner to identify utility rebates and incentives to reduce total cost and/or features to comply with 5 years (or less) payback period.
6. BAS service provider installs new BAS (or upgrades existing BAS) after reaching agreement with owner/utility/others on funding and is authorized to proceed by the owner or the owners representative (consultant).
7. Control consultant along with building owner, building engineer, building operator oversee installation and startup of BAS service provider’s new/upgraded BAS. Any problems or concerns are developed and documented during this phase.
8. BAS service provider, control consultant and building owner, building engineer and building operator consolidate the list of problems (steps 4-7) and plan corrective action plans.
9. BAS service provider, control consultant and building operator implement corrective actions identified in step 8:
a. For each problem listed in step 8, provide a solution to correct the problem (for example: BAS service provider, building technician or controls consultant implements the corrections).
b. BAS service provider and building owner/engineer/operator prepare a solution for each problem identified in the consolidated list that cannot be resolved in (a) above.
E-8
c. BAS service provider and control consultant provide date of “beneficial operations” to owner that the owner agrees is correct.
10. BAS service provider and controls consultant prepares documentation including:
a. BAS startup/warranty/performance summary document list goes here and should include BAS description, sequence descriptions, training provided, technical information, software licensing, warranty and service contact information, other related information.
b. Punch list items not resolved yet.
c. Warranty startup issues impacting building operation and energy efficiency (comfort and equipment operations).
11. BAS service provider estimates energy savings:
a. BAS service provider collects post-retrofit data from building owner/facility manager.
b. BAS service provider develops a baseline model using the past 12-month utility billing data (12 months prior to BAS installation and beneficial operations date) and corresponding average monthly dry-bulb temperature.
c. BAS service provider applies the baseline model in the post-BAS installation period (period after the BAS installation/startup is completed and beneficial operations is agreed to begin) using the average monthly dry-bulb temperature to estimate the building energy consumption, if the building were not upgraded.
d. BAS service provider estimates the savings, which is the difference between the building energy consumption estimated in the previous step and actual building energy consumption.
12. The BAS service provider works with the building owner, building engineer and building operator to ensure the following:
a. Set up the trends to monitor the following points in a RTU (as applicable):
i. Outside air temperature, mixed air temperature, return-air temperature, discharge-air temperature, outside air damper position (optionally mixed and relief air damper position), supply fan status, fan VFD speed command (if applicable), cooling command (compressor stage), heating command (heat pump compressor stage, electric stage) and occupancy mode of the RTU. Where applicable, the following should also be configured: C02, relative humidity (outside-/return-air) and filter pressure drop.
b. If lighting systems are controlled and monitored with the BAS, set up the trends to monitor the lighting systems:
i. Lighting system on and off times.
ii. Light levels (if monitored).
E-9
c. If the BAS monitors the whole-building electricity and gas consumption, set up trends to monitor the electric/gas consumption and electric demand.
d. If building exhaust fans are controlled and monitored using the BAS, set up trends to monitor the exhaust fans.
i. Exhaust fans on and off times.
e. If the server rooms are served by dedicated packaged units, set up trends to monitor the units:
i. Outside air temperature, mixed air temperature, return-air temperature, discharge-air temperature, outdoor air damper position, fan status, fan VFD speed and cooling command (compressor stage).
f. If other special end-use spaces (conference rooms, auditoriums, loading docks, etc.) served by dedicated packaged units are monitored and controlled, set up trends to monitor the units:
i. Outside air temperature, mixed air temperature, return-air temperature, discharge-air temperature, outdoor air damper position, fan status, fan VFD speed and cooling command (compressor stage).
g. Monitor any other end use loads of significant size.
13. Periodically/continuously repeat step 12:
a. Building owner and operator determine whether to repeat analytical processes using in-house staff or hire BAS service provider.
b. Repeat step 12 or validate its accuracy and value.
c. Train building owner or suggest methods to integrate historical data to other analytic tools that can help the building owner “optimize” building operations.
F-1
Appendix F
F. Use Case #2: BASs for Small Buildings
F-2
Description A service provider company wants to offer small building owners a BAS installation (upgrade existing or install new) service. In small commercial buildings, typical end use loads to control include heating, ventilating and air conditioning (HVAC) systems, lighting and a few “general purpose” loads (up to 5,000 sf, as shown in Figure F - 1). Most buildings of this size are not served by a BAS and often have “standalone” services (thermostats, time clocks, manual light switches, etc.). These standalone controls have limited intelligence and do not communicate with each other and/or with outside services (web-accessible via wired and/or wireless Internet or similar infrastructure).
Figure F - 1: Schematic of a Typical Small Building with Various End-Use Loads
A building of this size has two to three packaged rooftop units or split systems for comfort cooling and heating, these systems are controlled via standalone thermostats. The lighting fixtures in the offices or occupied spaces are typically controlled by manual switches and in some cases, interior lights are controlled by time clocks and exterior lights are controlled by photocells. The other end-uses/loads like the bathroom exhaust fans, domestic hot water system and miscellaneous plug loads are either not controlled or manually turned on/off by building occupants. A small building owner wants a BAS that supports distributed local controls at the device level and Cloud-based remote monitoring and configuration, as shown Figure F - 2. The owner is willing to outsource the configuration and monitoring of the building systems to ensure persistence of efficient operations to a third party. Also, the building owner is not interested in replacing the existing lighting fixtures or ballast. A simple scalable BAS consists of a set of communicating programmable thermostats that are connected to HVAC devices (primarily rooftop units) or RTU controllers that are located at and connected to the HVAC device, as shown in Figure F - 2. They can also include controllers for small miscellaneous loads (plug loads, small exhaust fans). The dashed lines in Figure F - 2 indicate that the communication between thermostat/controller and the Cloud can either be hardwired or wireless. While
F-3
improving the energy efficiency of the building, this solution can also be leveraged to make the building and its systems more grid responsive.
Figure F - 2: Simple BAS with Local Controls but Remote Configuration Option for Small
Buildings
The thermostats or the RTU controllers communicate with each other and with outside services through the Cloud-service. This option could also have some general purpose controllers to control exterior lighting or miscellaneous end-use loads. The connection of the various hardware components may be through a wired, wireless or combination (hybrid) of both, using an open, industry standard to enable reliable communications to all components. In most existing buildings a hardwired solution may not be cost effective, so a wireless solution is needed. For new construction, a wired solution may be a cost-effective solution. The core functionality of the BAS is to keep the building occupants comfortable, monitor and trend the performance of various systems (including whole-building energy consumption and demand) and provide notification of device failures via local alarming or remote text messaging or email of alarms to the maintenance staff. The Cloud service coordinates the building level global functions such as scheduling, alarming, trending, and sharing global information with all controllers on the network. If any of the controllers in this configuration lose connection to the Cloud, they can operate autonomously using default configuration. For a typical building of this size and anticipated lighting systems in use in the buildings, it is not generally cost effective to install lighting controllers that can be managed and controlled from a central location. So, the interior lighting fixtures should be controlled with individual light switches with occupancy sensors that would turn the lights off when the space is not occupied, unless a cost-effective lighting control solution can be found. This configuration also allows for other BAS functions that empower the owner/user for more efficient building operations. These functions are supported from the Cloud and include: 1) alarm notification of equipment failures, comfort problems or other related problems that need immediate attention; 2) trending and storage of data pertaining to equipment operations and occupant environment; 3) energy saving strategies; 4) web-access for remote notification and configuration/interaction to the
F-4
building; 5) linkage to other web-enabled services including dashboards, analytical services, intelligent (smart) grid responsive for automatic load shedding, whole-building metered energy performance, etc.
F-5
Scope Design and install (or upgrade) an existing small commercial building with a new (or upgraded) BAS that is affordable and capable of achieving between 15% and 30% energy reductions with simple paybacks of no more than 5 years. Stakeholders
1. Utility – sells either electricity or gas to the building owners and also provides incentives to the building owners to increase energy efficiency by upgrading older BAS or installing new BAS in their buildings (especially to allow for automatic demand response capability).
2. BAS service provider or controls vendor – sells BAS upgrade services.
3. Building owner – owns and manages the building, may not be responsible for the energy bills.
4. Building tenant – does not own the building but pays the energy bills for the building.
5. Facility Manager – manages the operations of the building that is being upgraded.
Actors
1. Building owner.
2. BAS service provider or controls vendor.
3. Building operator/engineer/custodial staff.
4. Facility manager.
5. Building technician and mechanic – maintain and operate the building systems within a building.
6. Building tenant/occupants.
7. Control consultant (vendor or integrator).
Usage Scenarios
1. BAS service provider identifies basic building information
a. BAS service provider collects location, gross floor area, number of floors from the facility manager/owner/operator.
b. BAS service provider collects gas and electric utility bills (minimum 12 months), rates from the building owner/facility manager.
c. BAS service provider collects occupancy schedules for the building from the building operator/facility manager.
F-6
d. BAS service provider collects heating, ventilation, and air conditioning (HVAC) systems, lighting systems and miscellaneous buildings systems information from building operator/facility manager:
i. Number and type of rooftop units (RTUs) or split systems and sizes; and zones they serve. This determines the type of smart thermostat or smart RTU controller interface, as well as potential control improvements that might be considered (beyond smart thermostat control). Potential control improvements might include integrated economizer controls, DCV controls and VFD controls.
ii. Number of bathroom and general exhaust fans and their control access location (wall switch or distribution panel).
iii. Number of common space lighting circuits and their control access location (wall switch or distribution panel).
iv. Number of hard-walled office spaces and lighting circuits per office.
v. Location of other miscellaneous loads and their control access location(s). This can include (but not be limited to) domestic hot water systems, IT/LAN spaces and their dedicated cooling/ventilation systems, etc.
vi. Other – determine monitoring and control hardware requirements for the various building systems. This includes a determination of the requirements to monitor status of fan and compressor, but could also include monitoring filters (pressure drop) other related equipment. This also includes the number of sensors for temperature (indoor offices), the number of smart thermostats or smart controllers, and additional temperature sensors for RTU performance (mixed air, return air, discharge air) as well as outdoor condition monitoring (temperature/humidity). If additional control features (DCV, differential economizer, etc) are required, this will mandate additional sensors for humidity, CO2, etc. Wired versus wireless or both (hybrid) are also determined during this phase.
e. BAS service provider collects current (or recommended) HVAC equipment control sequencing, schedules and set point requirements from the building operator/control consultant as well as lighting systems and miscellaneous equipment control sequencing, schedules and set point requirements:
i. HVAC system occupied/unoccupied schedule configuration requirements including set points during each mode and RTU fan operations during each mode (continuous run, cycling on call heating/cooling, etc.).
ii. HVAC system optimum start/stop configuration requirements including target temperatures and times.
F-7
iii. HVAC morning warm up/night setback configuration requirements including methods to implement temporary override and length of override (push button, web access, etc.).
iv. HVAC night purge configuration requirements – related to scheduling of ventilation dampers and general exhaust fans, etc., prior to occupancy.
v. HVAC economizer (type of control – dry bulb, enthalpy, differential enthalpy) and configuration requirements (set points, dead bands, integrated with mechanical cooling, etc.) as well as sensor/instrumentation needs to enable control requirements (dry bulb, humidity, CO2, etc.).
vi. HVAC economizer feature improvements (DCV, etc.) requirements, if any.
vii. Lighting schedules for interior/exterior lighting.
viii. Lighting set points for dimming and daylight control applications (if applicable).
ix. Schedules for general purpose equipment (exhaust fans, domestic hot water, etc.).
x. Specialized building sequences (motion sensor interlocks for lighting and/or HVAC systems, rollup door interlocks to disable HVAC systems serving loading dock areas, hardwired push buttons or web access for night/weekend overrides of end use loads, free cooling/night over-cooling based upon weather forecasts, etc.).
f. Infrastructure requirements to meter whole-building electricity (consumption and demand) and gas consumption and integrate them with the BAS (including any sub-metered electric loads in the building) as directed by the consultant or owner.
g. BAS service provider determines if the building has “special process end-use” spaces (IT server rooms, auditorium, conference rooms, food prep spaces, etc.).
i. Determine the number of rooms.
ii. Determine the number of cooling/heating systems serving each room and equipment types/capacities.
iii. Determine the control and/or monitoring upgrades of the rooms and their dedicated HVAC systems.
2. BAS service provider determines the infrastructure requirements (Cloud, web, remote or site-located server, etc.) to support the new BAS requirement for trend logging of at least 50% of the BAS point count at a minimum trend interval of 15 minutes.
3. BAS service provider determines the infrastructure requirements (Cloud, web, remote or site-located server, etc.) to support the new BAS requirement for trending data, alarm monitoring and notification as well as storage of historical data for retrieval and analysis at a later time.
F-8
a. BAS service provider determines infrastructure to support long-term data storage and retrieval of alarm data and trended data. Energy-related data (whole-building energy metering and sub-metered data) shall be stored for up to 5 years, if not longer.
b. BAS service provider designs the infrastructure to ensure the successful alarm monitoring and trending of all major building systems and end uses identified in Step 1:
i. The frequency of data collection should be between 5-minutes and 15-minutes.
ii. Data shall be collected and stored in such a way that the building performance can be characterized during occupied and unoccupied periods and also during weekdays and weekends, over any period of time in the last 12 consecutive months (summer, winter and shoulder months).
4. BAS service provider provides a suggested design with total control and monitoring list of various HVAC, lighting and miscellaneous systems, along with suggested control sequences, based upon 1-3 above. BAS service provider also identifies control sequences that will make major buildings systems to be grid responsive. The control sequences used for operations and to make the systems grid responsive must be standard sequences that are industry approved. Any omissions by the BAS service provider or any requested deletions by the building owner should be documented for future reference and resolution prior to or during the installation phase.
5. BAS service provider determines the total cost of design, installation and startup/warranty, training and any required measurement and verification (M&V) actions as directed by the control consultant or building owner. BAS service provider also works with the control consultant or building owner to identify utility rebates and incentives to reduce total cost and/or features to comply with 5 years (or less) payback period.
6. BAS service provider installs new BAS (or upgrades existing BAS) after reaching agreement with owner/utility/others on funding and is authorized to proceed by the owner or the owners representative (consultant).
7. Control consultant along with building owner, building engineer, building operator oversee installation and startup of BAS service provider’s new/upgraded BAS. Any problems or concerns are developed and documented during this phase.
8. BAS service provider, control consultant and building owner, building engineer and building operator consolidate the list of problems (steps 4-7) and plan corrective action plans.
9. BAS service provider, control consultant and building operator implement corrective actions identified in step 8:
a. For each problem listed in step 8, provide a solution to correct the problem (for example: BAS service provider, building technician or controls consultant implements the corrections).
b. BAS service provider and building owner/engineer/operator prepare a solution for each problem identified in the consolidated list that cannot be resolved in (a) above.
F-9
c. BAS service provider and control consultant provide date of “beneficial operations” to owner that the owner agrees is correct.
10. BAS service provider and controls consultant prepares documentation including:
a. BAS startup/warranty/performance summary document list goes here and should include BAS description, sequence descriptions, training provided, technical information, software licensing, warranty and service contact information, other related information.
b. Punch list items not resolved yet.
c. Warranty startup issues impacting building operation and energy efficiency (comfort and equipment operations).
11. BAS service provider estimates energy savings:
a. BAS service provider collects post-retrofit data from building owner/facility manager
b. BAS service provider develops a baseline model using the past 12-month utility billing data (12 months prior to BAS installation and beneficial operations date) and corresponding average monthly dry-bulb temperature.
c. BAS service provider applies the baseline model in the post-BAS installation period (period after the BAS installation/startup is completed and beneficial operations is agreed to begin) using the average monthly dry-bulb temperature to estimate the building energy consumption, if the building were not upgraded.
d. BAS service provider estimates the savings, which is the difference between the building energy consumption estimated in the previous step and actual building energy consumption.
12. The BAS service provider works with the building owner, building engineer and building operator to ensure the following:
a. Set up the trends to monitor the following points in a RTU (as applicable):
i. Outside-air temperature, mixed-air temperature, return-air temperature, discharge-air temperature, outside-air damper position (optionally mixed and relief air damper position), supply fan status, fan VFD speed command (if applicable), cooling command (compressor stage), heating command (heat pump compressor stage, electric stage) and occupancy mode of the RTU. Where applicable, the following should also be configured: C02, relative humidity (outside-/return-air) and filter pressure drop.
b. If lighting systems are controlled and monitored with the BAS, set up the trends to monitor the lighting systems:
i. Lighting system on and off times.
F-10
ii. Light levels (if monitored).
c. If the BAS monitors the whole-building electricity and gas consumption, set up trends to monitor the electric/gas consumption and electric demand.
d. If building exhaust fans are controlled and monitored using the BAS, set up trends to monitor the exhaust fans.
i. Exhaust fans on and off times.
e. If the server rooms are served by dedicated packaged units, set up trends to monitor the units:
i. Outside-air temperature, mixed-air temperature, return-air temperature, discharge-air temperature, outdoor-air damper position, fan status, fan VFD speed and cooling command (compressor stage).
f. If other special end-use spaces (conference rooms, auditoriums, loading docks, etc.) served by dedicated packaged units are monitored and controlled, set up trends to monitor the units:
i. Outside-air temperature, mixed-air temperature, return-air temperature, discharge-air temperature, outdoor-air damper position, fan status, fan VFD speed and cooling command (compressor stage).
g. Monitor any other end-use loads of significant size.
13. Periodically/continuously repeat step 12:
a. Building owner and operator determine whether to repeat analytical processes using in-house staff or hire BAS service provider.
b. Repeat step 12 or validate its accuracy and value.
c. Train building owner or suggest methods to integrate historical data to other analytic tools that can help the building owner “optimize” building operations.
G-1
Appendix G
G. Use Case #3: BASs for Small Buildings
G-2
Description A service provider company wants to offer medium-sized building owners a BAS installation service (upgrade existing or install new). In medium-sized commercial buildings, typical end-uses/loads to control include HVAC, lighting and a few “general purpose” loads (> 5,000 sf to < 50,000 sf, as shown in Figure G - 1). Some buildings of this size may have a BAS, but most buildings are not served by a BAS; they often have “standalone” services (thermostats, time clocks, manual light switches, etc.). The standalone controls have limited intelligence and do not communicate with each other and/or with outside services (web-accessible via wired and/or wireless Internet or similar infrastructure).
Figure G - 1: Schematic of a Typical Medium-Size Commercial Building with Various End-Use
Loads
A building of this size has 5 to 15 packaged rooftop units for comfort cooling and heating; these systems are controlled via standalone thermostats. The lighting fixtures in the offices or occupied spaces are typically controlled by manual switches and in some cases, interior lights are controlled by time clocks and exterior lights are controlled by photocells. The other end uses loads like the bathroom exhaust fans, domestic hot water system and miscellaneous plug loads are either not controlled or manually turned on/off by building occupants. A few buildings in this size range may have BAS to coordinate and control the HVAC and lighting systems. An owner of a medium-sized commercial building wants to install a locally/remotely configurable BAS option. The proposed solution for the medium-sized building, shown in Figure G - 2, will work in both existing and new buildings. While improving the energy efficiency of the building, this solution can also be leveraged to make the building and its systems more grid responsive. In this configuration, the building will have a central master controller that coordinates a number of specific device controllers in
G-3
the building. Like small buildings, the energy consumption in the medium-sized buildings is dominated by HVAC and lighting loads, which consume over half the total energy consumption and over 70% of electricity consumption.
Figure G - 2: Building Automation System with Local Control and Configuration and Local or
Remote Monitoring for Medium-Sized Buildings
The medium-sized building configuration consists primarily of general purpose controllers that are located at and connected to the HVAC and lighting systems. They can also include controllers for small miscellaneous loads (plug loads, small exhaust fans, hot water tanks, pumps, etc.). Temperature sensors connected to the general purpose controllers are located in designated occupied spaces in the building (office or open area). The lighting controller may be the same general purpose controller or a dedicated lighting controller (or a hybrid). The small load controller may be connected to plug load devices. These plug loads may be located in the spaces (outlets or electrical distribution panels), that are primarily for special process loads (like domestic hot water tanks, domestic hot water pumps or lighting loads), or they may be up in ceiling spaces or on roofs (primarily for exhaust fans or lighting fixtures). For the purposes of complete systems integration, a master/supervisory controller is provided to allow for disparate systems to be connected and integrated together, creating a fully functional, fully interoperable and intelligent BAS. The dashed lines in Figure G - 2 indicate that the communication between various devices the master controller can either be hardwired or wireless. Individual controllers do not need to communicate to the Cloud service directly. Access to external information in the controllers is primarily through the master controller. Monitoring can either be via
G-4
local or remote monitoring (web page, Internet connection – wired or wirelessly). Local monitoring, configuration and analysis (data and alarm management) is the recommended option for medium-sized buildings because these buildings may have dedicated building management staff. If the building does not have dedicated building management staff, this configuration allows for outsourcing that function to a third party. Monitoring capabilities (including whole-building energy consumption and demand) greatly assist in ensuring persistence and sustainability of energy savings and proper, efficient equipment operations. This assurance comes primarily from reliable alarm, data management and actionable intelligence creation capabilities. Control functions are distributed primarily amongst the programmable general purpose controllers, but there will (of necessity) be some “global” functions that come from a local, on-site master controller. This type of controls may be viewed as a “master/slave” or “supervisory” management service that includes site configuration of individual controllers, as well as alarm and data management (local data storage, etc.). Global functions may also include (but are not necessarily limited to) things like alarm management (alarm monitoring and alarm notification), data management (trending, storage and retrieval), equipment scheduling, holiday scheduling and time synchronization actions. All of these control devices shall be connected to a common communications network (wired or wireless or both), inside the building. Communications to all controllers shall be through an open industry standard. When specifying such a system, it is always important to fully document the installation and startup of all hardware/software functions so it will be easy to implement and troubleshoot for correct operation (startup and persistence). This configuration will generally be dealing with a significant number of HVAC systems (more than five), a number of lighting controllers and other special purpose load controllers. The HVAC systems can include rooftop configurations (multi-stage heating and cooling) that may also include economizer functions (integrated or standalone), split systems (indoor fan unit with outdoor condenser), larger air handling units (primarily packaged), zone terminal boxes or zone HVAC systems (like fan coils or induction boxes, etc.) and potentially small chillers and hot water boilers with dedicated pumping systems. The configuration may be dealing with a few small load controllers. Programmable general purpose controllers that support multiple configurations (heat pump, multi-stage heating and cooling, with or without economizer integration, terminal boxes, air handlers, etc.) over multiple product offerings that are designed for only one type of HVAC system are probably not realistic for the size and potential complexity of medium buildings, especially when designed with multiple and varying HVAC systems. Because of controllers that support multiple configurations over multiple product offerings (due to varied HVAC systems that are not conducive to one controller option) will be market and building system driven. Configuration of all general purpose control parameters shall be configured from a local workstation or a local laptop connection to the general purpose controller. Remote access via web access/web page service into the local controller is also encouraged, to provide for remote service and troubleshooting. Different levels of program access shall be required for each general purpose controller. Basic access shall be provided to allow for local occupant overrides and other non-critical functions. Higher level access (via proper password access) shall be provided for service/maintenance personnel or other designated staff. This higher level access shall include access for schedule changes and equipment protection parameters (minimum on/off short cycle parameters and/or similar functions). Remote configuration and monitoring may be provided for all controllers. The programmable controller may have a bypass/override feature that enables testing basic HVAC equipment functions. Analytics and actionable intelligence can be created, either locally or remotely or both. This includes tracking HVAC equipment performance issues such as dirty filters, hours of heating and cooling
G-5
operations with local notification for maintenance inspections and can include storage of time-stamped alarms (high/low temperatures, etc.). This configuration also allows for other BAS functions will often include multiple capabilities to the user that empower more efficient building operations to occur. This can include things like the following: 1) alarm notification of equipment failures, comfort problems or other related problems that need immediate attention; 2) trending and storage of data pertaining to equipment operations and occupant environment; 3) energy saving strategies; 4) web-access for remote notification and configuration/interaction to the building; 5) linkage to other web-enabled services including dashboards, analytical services, intelligent (smart) grid responsive for automatic load shedding, whole-building metered energy performance, etc. Scope Design and install (or upgrade) an existing medium-sized commercial building with a new (or upgraded) BAS that is affordable and capable of achieving between 15% and 30% energy reductions with simple paybacks of no more than 5 years. Stakeholders
1. Utility – sells either electricity or gas to the building owners and also provides incentives to the building owners to increase energy efficiency by upgrading older BAS or installing new BAS in their buildings (including allowing for automatic demand response capability).
2. BAS service provider or controls vendor – sells BAS upgrade services.
3. Building owner – owns and manages the building, may not be responsible for the energy bills.
4. Building tenant – does not own the building, but pays the energy bills for the building.
5. Facility manager – manages the operations of the building that is being upgraded.
Actors
1. Building owner.
2. BAS service provider or controls vendor.
3. Building operator/engineer/custodial staff.
4. Facility manager.
5. Building technician and mechanic – maintain and operate the building systems within a building.
6. Building tenant/occupants.
7. Control consultant (vendor or integrator).
Usage Scenarios
G-6
1. BAS service provider identifies basic building information
a. BAS service provider collects location, gross floor area, number of floors from the facility manager/owner/operator.
b. BAS service provider collects gas and electric utility bills (minimum 12 months), rates from the building owner/facility manager.
c. BAS service provider collects occupancy schedules for the building from the building operator/facility manager.
d. BAS service provider collects heating, ventilation, and air conditioning (HVAC) systems, lighting systems and miscellaneous buildings systems information from building operator/facility manager:
i. Number and type of roof top units (RTUs) or split systems and sizes; and zones they serve. This determines the type of smart thermostat or smart RTU controller interface, as well as potential control improvements that might be considered (beyond smart thermostat control). Potential control improvements might include integrated economizer controls, DCV controls and VFD controls.
ii. Number of bathroom and general exhaust fans and their control access location (wall switch or distribution panel).
iii. Number of common space lighting circuits and their control access location (wall switch or distribution panel).
iv. Number of hard-walled office spaces and lighting circuits per office.
v. Location of other miscellaneous loads and their control access location(s). This can include (but not be limited to) domestic hot water systems, IT/LAN spaces and their dedicated cooling/ventilation systems, etc.
vi. Determination of the gateway/supervisory controller to fully integrate various controllers dedicated to RTUs, lighting, general purpose end-use loads and wireless infrastructure capabilities (sensors, communications, etc.).
vii. Other – determine monitoring and control hardware requirements for the various building systems. This includes a determination of the requirements to monitor status of fan and compressor, but could also include monitoring filters (pressure drop) other related equipment. This also includes the number of sensors for temperature (indoor offices), the number of smart thermostats or smart controllers, and additional temperature sensors for RTU performance (mixed air, return air, discharge air) as well as outdoor condition monitoring (temperature/humidity). If additional control features (DCV, differential economizer, etc) are required, this will mandate additional sensors for humidity,
G-7
CO2, etc. Determination of wired versus wireless or both (hybrid) are also determined during this phase.
e. BAS service provider collects current (or recommended) HVAC equipment control sequencing, schedules and set point requirements from the building operator/control consultant as well as lighting systems and miscellaneous equipment control sequencing, schedules and set point requirements:
i. HVAC system occupied/unoccupied schedule configuration requirements including set points during each mode and RTU fan operations during each mode (continuous run, cycling on call heating/cooling, etc.).
ii. HVAC system optimum start/stop configuration requirements including target temperatures and times.
iii. HVAC morning warm up/night setback configuration requirements including methods to implement temporary override and length of override (push button, web access, etc.).
iv. HVAC night purge configuration requirements – related to scheduling of ventilation dampers and general exhaust fans, etc., prior to occupancy.
v. HVAC economizer (type of control – dry bulb, enthalpy, differential enthalpy) and configuration requirements (set points, dead bands, integrated with mechanical cooling, etc.) as well as sensor/instrumentation needs to enable control requirements (dry bulb, humidity, CO2, etc.).
vi. HVAC economizer feature improvements (DCV, etc.) requirements, if any.
vii. Lighting schedules for interior/exterior lighting.
viii. Lighting set points for dimming and daylight control applications.
ix. Schedules for general purpose equipment (exhaust fans, domestic hot water, etc.).
x. Specialized building sequences (motion sensor interlocks for lighting and/or HVAC systems, rollup door interlocks to disable HVAC systems serving loading dock areas, hardwired push buttons or web access for night/weekend overrides of end-use loads, free cooling/night over-cooling based upon weather forecasts, etc.)
xi. Automatic demand response control sequences for the various systems that can be coordinated from the central location.
f. Infrastructure requirements to meter whole-building electricity (consumption and demand) and gas consumption and integrate them with the BAS (including any sub-metered electric loads in the building) as directed by the consultant or owner.
g. BAS service provider determines if the building has “special process end-use” spaces (IT server rooms, auditorium, conference rooms, food prep spaces, etc.).
G-8
i. Determine the number of rooms.
ii. Determine the number of cooling/heating systems serving each room and equipment types/capacities.
iii. Determine the control and/or monitoring upgrades of the rooms and their dedicated HVAC systems.
2. BAS service provider determines the infrastructure requirements (Cloud, web, remote or site-located server, etc.) to support the new BAS requirement for trend logging of at least 50% of the BAS point count at a minimum trend interval of 15 minutes.
3. BAS service provider determines the infrastructure requirements (Cloud, web, remote or site-located server, etc.) to support the new BAS requirement for trending data, alarm monitoring and notification as well as storage of historical data for retrieval and analysis at a later time.
a. BAS service provider determines infrastructure to support long-term data storage and retrieval of alarm data and trended data. Energy-related data (whole-building energy metering and sub-metered data) shall be stored for up to 5 years, if not longer.
b. BAS service provider designs the infrastructure to ensure the successful alarm monitoring and trending of all major building systems and end uses identified in Step 1:
i. The frequency of data collection should be between 5-minutes and 15-minutes.
ii. Data shall be collected and stored in such a way that the building performance can be characterized during occupied and unoccupied periods and also during weekdays and weekends, over any period of time in the last 12 consecutive months (summer, winter and shoulder months).
4. BAS service provider provides a suggested design with total control and monitoring list of various HVAC, lighting and miscellaneous systems, along with suggested control sequences, based upon 1-3 above. BAS service provider also identifies control sequences that will make major buildings systems to be grid responsive. The control sequences used for operations and to make the systems grid responsive must be standard sequences that are industry approved. Any omissions by the BAS service provider or any requested deletions by the building owner should be documented for future reference and resolution prior to or during the installation phase.
5. BAS service provider determines the total cost of design, installation and startup/warranty, training and any required measurement and verification (M&V) actions as directed by the control consultant or building owner. BAS service provider also works with the control consultant or building owner to identify utility rebates and incentives to reduce total cost and/or features to comply with 5 years (or less) payback period.
6. BAS service provider installs new BAS (or upgrades existing BAS) after reaching agreement with owner/utility/others on funding and is authorized to proceed by the owner or the owners representative (consultant).
G-9
7. Control consultant along with building owner, building engineer, building operator oversee installation and startup of BAS service provider’s new/upgraded BAS. Any problems or concerns are developed and documented during this phase.
8. BAS service provider, control consultant and building owner, building engineer and building operator consolidate the list of problems (steps 4-7) and plan corrective action plans.
9. BAS service provider, control consultant and building operator implement corrective actions identified in step 8:
a. For each problem listed in step 8, provide a solution to correct the problem (for example: BAS service provider, building technician or controls consultant implements the corrections).
b. BAS service provider and building owner/engineer/operator prepare a solution for each problem identified in the consolidated list that cannot be resolved in (a) above.
c. BAS service provider and control consultant provide date of “beneficial operations” to owner that the owner agrees is correct.
10. BAS service provider and controls consultant prepares documentation including:
a. BAS startup/warranty/performance summary document list goes here and should include BAS description, sequence descriptions, training provided, technical information, software licensing, warranty and service contact information, other related information.
b. Punch list items not resolved yet.
c. Warranty startup issues impacting building operation and energy efficiency (comfort and equipment operations).
11. BAS service provider estimates energy savings:
a. BAS service provider collects post-retrofit data from building owner/facility manager.
b. BAS service provider develops a baseline model using the past 12-month utility billing data (12 months prior to BAS installation and beneficial operations date) and corresponding average monthly dry-bulb temperature.
c. BAS service provider applies the baseline model in the post-BAS installation period (period after the BAS installation/startup is completed and beneficial operations is agreed to begin) using the average monthly dry-bulb temperature to estimate the building energy consumption, if the building were not upgraded.
d. BAS service provider estimates the savings, which is the difference between the building energy consumption estimated in the previous step and actual building energy consumption.
G-10
12. The BAS service provider works with the building owner, building engineer and building operator to ensure the following:
a. Set up the trends to monitor the following points in a RTU (as applicable):
i. Outside-air temperature, mixed-air temperature, return-air temperature, discharge-air temperature, outside-air damper position (optionally mixed and relief air damper position), supply fan status, fan VFD speed command (if applicable), cooling command (compressor stage), heating command (heat pump compressor stage, electric stage) and occupancy mode of the RTU. Where applicable, the following should also be configured: C02, relative humidity (outside-/return-air) and filter pressure drop.
b. If lighting systems are controlled and monitored with the BAS, set up the trends to monitor the lighting systems:
i. Lighting system on and off times.
ii. Light levels (if monitored).
c. If the BAS monitors the whole building electricity and gas consumption, set up trends to monitor the electric/gas consumption and electric demand.
d. If building exhaust fans are controlled and monitored using the BAS, set up trends to monitor the exhaust fans:
i. Exhaust fans on and off times.
e. If the server rooms are served by dedicated packaged units, set up trends to monitor the units:
i. Outside-air temperature, mixed-air temperature, return-air temperature, discharge-air temperature, outdoor-air damper position, fan status, fan VFD speed and cooling command (compressor stage).
f. If other special end-use spaces (conference rooms, auditoriums, loading docks, etc.) served by dedicated packaged units are monitored and controlled, set up trends to monitor the units:
i. Outside-air temperature, mixed-air temperature, return-air temperature, discharge-air temperature, outdoor-air damper position, fan status, fan VFD speed and cooling command (compressor stage).
g. Monitor any other end-use loads of significant size.
13. Periodically/continuously repeat step 12:
a. Building owner and operator determine whether to repeat analytical processes using in-house staff or hire BAS service provider.
G-11
b. Repeat step 12 or validate its accuracy and value.
c. Train building owner or suggest methods to integrate historical data to other analytic tools that can help the building owner “optimize” building operations.
