A DISTRIBUTED INTELLIGENT AUTOMATED DEMAND RESPONSE BUILDING MANAGEMENT SYSTEM

Transcription

1 A DISTRIBUTED INTELLIGENT AUTOMATED DEMAND RESPONSE BUILDING MANAGEMENT SYSTEM System Architecture: Deliverable 1, October 27, Background: Sutardja Dai Hall Sutardja Dai Hall is a new building on the University of California, Berkeley campus. It opened in 2009 and is the home of the Center for Information Technology Research in the Interest of Society (CITRIS), the umbrella organization that this research project is part of. This building was selected as the experimental target for this project because it has a modern energy management system, with CITRIS housed in the building there is a very close rapport with the building operational staff, the energy management system is from Siemens Corp., a partner in this research. Sutardja Dai Hall actually has two major parts: an office building and the Marvell Nano Fabrication laboratory (the abbreviation SDH will refer to the whole building, SDH-office for the office portion and SDH-nano for the Marvell Nano Fabrication lab). Because the nano fabrication lab has characteristics that are more like an industrial than a commercial facility, this project will focus its efforts on the office building portion of Sutardja Dai Hall (SDH-office). This will complicate the work to some extent because the two parts of the building share some HVAC facilities. Over the course of the project another nearby building, considerably smaller and currently under construction, will also share the SDH HVAC system, using chilled water from SDH. SDH-office has seven floors, including a 150 seat auditorium on the third floor. The fourth, fifth and seventh levels have collaboratory space with open and cubicle based facilities for graduate students. There is a small data center in the building that is operated by the campus Office of Information Systems and Technology. Because it is not under the control of SDH building management it will not be included in this demand response project. The building also houses a dining facility (Qualcomm Café), a distance learning classroom, and a precision laser lab. An overview diagram of the building is shown in Figure 1. The SDH HVAC system uses a campus-wide steam supply for heating (the campus has a co-generation plant that produces steam for most campus buildings), and both compressor-based (expansion) and absorption chillers for cooling. Each of the cooling units is capable of providing the full cooling load for the building. The absorption unit is used when excess steam is available from the campus steam supply (mostly in summer); otherwise the compressor unit is used. Either one can be backup for the other.

2 Figure 1.Sutardja Dai Hall: Exploded View Page 2 of 16

3 Figure 2. Expanded Metering in SDH (part I) As preparation for this project, SDH has been equipped with extensive sub-metering. This will allow disaggregation of electricity usage in the building to make the design of building demand response more effective. It will also allow disaggregation of building power usage so that we can verify estimates of various types of electrical power consumption. The sub-metering diagrams are shown in Figure 2 and Figure 3.Each yellow box with bold outline represents a main breaker that will be metered. Explanations of the abbreviations are given below. Page 3 of 16

4 Figure 3. Expanded metering (part II) List of Abbreviations for Sub-Metering Diagrams: EX Exhaust Fan EF Exhaust Fan (FAB) ELEV - Elevator CHP Chilled Water Pump CWP Condenser Water Pump SCHWP Secondary Chilled Water Pump (FAB) PCWP Processed Chilled Water Pump (FAB) CDAC Dry Air Compressor (FAB) PVP Process Vacuum Pump (FAB) SF Supply Fan (FAB) RO/DI Reverse Osmosis Deionized Water (FAB) RHU Recirculating Air Handler Unit (FAB) HWP Hot Water Pump AHU Air Handler Unit Page 4 of 16

5 RF Recirculating Fan CP Condensate Pump SP Storm Water Pump SE - Sewer Ejector Pump CH1 Absorber Chiller CH2 Centrifugal Chiller CAC Central Air Conditioner CT Cooling Tower RTU Roof Top AC Unit MDC Main Distribution Frame BDF Building Distribution Frame IDF Intermediate Distribution Frame ATS Automatic Transfer Switch 2 The Apogee Building Energy Management System The Siemens energy management system is the central element in this project. In its basic form, as originally installed, it provides access and control over all of the primary elements in the building (except lighting, which is controlled by a Watt-Stopper unit). Figure 4 shows a general architecture of Siemens Apogee BMS. Explanations of the abbreviations in the diagram are given below. At the management level, Siemens Insight Workstation provides a graphical approach to manage and control a building from an easy-to-use interface. The Insight Workstation provides for facility-wide efficiencies, as well as cost-effective operation and information sharing. With the Insight Advanced Workstation, user can graphically monitor and control the building environment, schedule and modify mechanical equipment operation and troubleshoot and tune the system. In addition, with add-on BACnet option, Apogee can be integrated with other BACnet workstation or controllers Page 5 of 16

6 Figure 4. Apogee System As Installed Explanation of Abbreviations in Apogee Diagram: MEC - Modular Equipment Controller MBC - Modular Building Controller TEC - Terminal Equipment Controller VFD - Variable Frequency Drive Controller Trane Integ. Driver - Trane Integration Driver DR - Demand Response P2 - Siemens Communication Protocol at the Automation Level Network P1 - Siemens Communication Protocol at the Field Level Network At the automation level, there are programmable controllers MEC/MBC to provide high-performance, flexible Direct Digital Control of a typical building's end devices such as sensors, actuators and Page 6 of 16

7 equipment controllers. Although the network connection P2 shown in the figure is Siemens proprietary control network, a wide range of drivers exist today to integrate other systems including chiller, boiler, fire/life safety, security, lighting. Or these 3 rd party systems can be integrated directly to Insight workstation through open communication protocol like BACnet. At the Field level are the field level network devices which provide application-specific controls, for example, pump control, vent control, duct control, fan control, etc. Specifically, Terminal Equipment Controllers (TECs) shown in the figure provides Direct Digital Control for a variety of pressure independent applications, including Variable Air Volume cooling only, cooling or heating, with hot water reheat, with electric reheat, fan-powered VAV with hot water reheat, and fan-powered VAV with electric reheat, etc. The network connection P1 is Siemens proprietary control network. The as-installed SDH Apogee BMS is shown in Figure 5. Figure 5. CITRIS Apogee BMS At the CITRIS building, the APOGEE Building Management System controls the operation of all airhandling units, all variable air volume terminal boxes, fan coil units, exhaust fans, primary and secondary chilled water circuits, condenser water circuit, and heat exchanger system. The APOGEE system is also fully integrated with the Trane chillers to bring the chiller operating data directly to the APOGEE Insight workstation. Typical operation tasks carried out by the APOGEE control system include start-up operation mode, normal operation mode, alarm management (to inform an operator of off-normal condition), and interlocking operation with fire and smoke detector systems At the room level, the Page 7 of 16

8 APOGEE control system ensures that the room temperature is maintained at the desired setting to maintain the comfort and productivity of the occupants. In addition, the APOGEE system also carries out energy efficient operation tasks such as economizer controls, chilled water temperature reset, condenser water temperature reset, and chiller lead-lag operation. For Class-100 and Class clean room operations, the APOGEE control system maintains tight control of temperature, humidity, pressurization, and infiltration to ensure that the operating condition is conformed to the clean room requirements. Real time operating data from all HVAC systems can be trended and logged by the APOGEE building management system for performance measurement and verification. 3 Survey of Applicable Methods In this project, Automated PDP signals will be sent to the site using OpenADR v1.0 specification developed by Lawrence Berkeley National Laboratory. The signal will be normal during non-dr hours. When the PDP event notifications are sent a day ahead, a pending signal will be issued. During the DR event period between 2 pm to 6 pm, the signal will be high. Two types of baselines calculations will be used to estimate the demand savings from the DR strategies. For this study, the electricity consumption data will be collected from the two onsite meters. The actual metered electricity consumption will be subtracted from the baseline-modeled consumption to derive an estimate of demand savings for each 15-minute period. Previous research recommended a weather-sensitive baseline model with adjustments for morning load variations. Therefore, the adjusted outside air temperature (OAT) regression baseline model uses outside air temperature regression with a scalar adjustment for the morning load. To develop the baseline electric loads for the demand savings, LBNL will select 10 non-demand response days. These 10 baseline days will be non-weekend, non-holiday Monday through Friday work days. In LBNL s model, first the whole building power baseline is estimated using a regression model that assumes that whole building power is linearly correlated with OAT. The source of the OAT data will be the closest weather station. Input data are 15-minute interval whole building electric demand and 15- minute interval or hourly OAT. The baseline is computed as: Li = ai + bi Ti where Li is the predicted 15-minute interval electric demand for time i from the previous non-pdp work days. Depending on the frequency of the available weather data, Ti is the hourly or 15-minute interval OAT at time i. ai and bi are estimated parameters generated within the model from a linear regression of the demand data for time i. Individual regression equations are developed for each 15-minute interval, resulting in 96 regressions for the entire day (24 hours/day, with four 15-minute periods per hour; i is from 0:00 to 23:45). Second, the morning power load is used to adjust the regression model. The regression model is shifted up by the average difference between the actual demand and the predicted demand of the three-hour period immediately prior to the shed control. The adjusted load is computed as: L i = Li + P Page 8 of 16

9 P = Average (Li Mi) where Li is the adjusted load for time i, P is the calibration ratio, and Mi is the actual demand for time i. The three hours immediately prior to the shed control are used to calculate P. If pre-cooling strategies are tested in the building, then the morning load shape adjustment will not be used in baseline calculations because it will overestimate the afternoon loads. The team will also develop PG&E s baseline. PG&E uses 10/10 baseline with or without morning adjustment during their load impact evaluations. This baseline is the average hourly load shape of the last ten work days (excluding weekends and holidays). PDP event days are excluded from the 10 reference days. The evaluation will include quantifying the demand savings (kw) at each site, calculated by subtracting the actual whole building power from its calculated baseline demand. It will also include calculating the demand savings percentage, defined as the percentage of savings of whole building power, and estimating the demand-savings intensity (W/ft 2 ) as the saved demand normalized by the building s conditioned floor area. 4 Functional Requirements The functional requirements for this project are effectively driven by the automated in the project title. This decomposes into several specific requirements. Electrical usage measurement points must provide readings in an open standard representation that can be transported over conventional communication networks, stored in conventional repositories, associated with contextual information that enables accurate interpretation of the readings, and processed by third-party analytical tools. The electrical usage data needs to be correlated with building operational processes and usage data in order to build models, formulate demand response actions, and evaluate alternative actions. Thus, building infrastructure systems measurements points must provide readings in an open standard representation with the characteristics defined above for electrical readings. In addition, analytical tools must be able to operate on both forms of data. The sources of such electrical, operational, and usage measurements are typically quite varied, including BACNet, Modbus, or RS485, or direct web service objects, so it is highly desirable to have a means of express all in a self-describing, system independent form, such as XML or JSON with definitional schema documents. The mapping to such a canonical form may be performed at various levels of the overall architecture depending on the particular source of the readings. Such a physical information repository, combined with survey data, design data, and other sources permits the development of simulation models for building behavior and energy usage to formulate and evaluate a variety of responses to various DR events. The modified operating point of the building systems must be conveyed to effect the actual operating point. While conceptually this may produce a detailed distributed control plan, operationally it will be represented as a modified sequence of operations (SOP). The must be an interface to the BMS to select a modified suite of supervisory control points, which then affect the lower level direct control loop. The Page 9 of 16

10 minimal form of this is the select of one of several preconfigured SOPs at the BMS. Each such actions must be recorded essentially as an additional data source. The DR event signal is presented as an XML object under OpenADR. There must be an adapter to parse such objects, perform analysis utilizing the modeling capabilities described above or distillations of them as DR a DR rule set and establish a modified operating point accordingly. These DR actions must be treated as another data source and the measurement and analysis facilities described above must be applicable to determine the efficacy of the response with respect to the DR goal. The historical repository containing electrical usage, building system usage, operating points, DR events, and DR response actions must be used longitudinally to evaluate the overall efficacy of the DR as a system, overall achieved reduction, and achieved peak reduction relative to estimated baseline. 5 DIADR System Architecture 5.1 Central System Enhancements for DIADR The candidate integration platform for the CITRIS DIADR management system implementation is based on the Siemens Smart Energy Box. The Smart Energy Box (SEB) is a device developed by Siemens that can act as a gateway for building to grid and other connections. It receives DR signals from grid and sends out the actions to building automation systems to respond to the DR event. SEB is chosen as an integration platform for DIADR due to its open architecture. SEB implements an open architecture with a run-time data repository located at the center for data exchange. There is a generic interface defined for data reading and writing from/to the data repository, with XML based modeling tools to define the data schema. SEB comes with four basic function modules including an Open ADR Client, BMS Adaptor, Weather Data Adapter and Energy Simulation. The OpenADR Client module enables the building s connection with an OpenADR DRAS server. The BMS Adapter provides the connection to different building management systems (BMS). The Weather Data Adapter can retrieve weather information which is going to be used by Energy Simulation module for load forecast. Figure 6 shows the architecture for the CITRIS DIADR based on SEB. With OpenADR Client and BMS adapter, CITRIS can talk to the grid. For central load DR control, demand reduction strategy will be implemented on SEB and the resulted control actions will be sent to Apogee and Watt Stopper through the BACnet interface. CITRIS building energy simulation will be available during runtime for dynamic generation of DR strategy based on weather forecast. The distributed load controls will be integrated to SEB through to-be-defined interface. The specification of this interface includes both communication protocol and logic definition. Depending on the control interface, the data exchanged between SEB and distributed controllers can be as simple as DR signal passing, or as complicated as agent-based negotiation. Page 10 of 16

11 Figure 6. DIADR integration using Siemens Smart Energy Box Additional modules are required for 3rd party central load DR control integration shown as Integration Interface 1 and distributed load control system integration shown as Integration Interface 2 in Figure 6. Based on this open architecture, any control engine developed by our team members can be plugged in to SEB seamlessly. In addition, the SEB box also provides a web based interface for remote access and monitoring of the DR status, changing/overriding any settings. 5.2 Distributed DR Architecture To reach the distributed loads in the building the architecture consists of local gateways and low-power wireless communication with various local loads. The local gateways provide: Communication with and management of the loads (mostly plug loads), A variety of interfaces for occupants of the space (web browser, smart phone app, etc.), Communication and management of storage and source elements (if any), Communication with the central system for negotiation of DR event power targets, actual current usage, information on space occupancy, etc. The architecture for this was presented in the proposal as shown in Figure 7. Page 11 of 16

12 Figure 7. DIADR Distributed Architecture This is a generic structure, scalable to any size building and based on Siemens energy management systems. The structure refined for use in SDH, also showing roles of the participating organizations (UC Berkeley, Siemens, Lawrence Berkeley National Lab) is shown in Figure 8. This structure collapses some of the layers shown in Figure 7 for a simpler system overall. This is appropriate here because SDH office is a relatively simple building in the universe of commercial buildings. Page 12 of 16

13 Figure 8. System Architecture for Sutardja Dai Hall (SDH-office) This architecture leverages the partnership of UC Berkeley, LBNL, and Siemens. LBNL has experience in demand response in commercial and industrial buildings and is the originator of the OpenADR standard to facilitate transparent communication for automated demand response. They will provide key inputs in interfacing the Siemens Apogee system to an OpenADR server (DRAS). Their experience in building modeling will also be leveraged in understanding how DR can most effectively be applied is SDH-office. The Siemens team includes Siemens Corporate Research (SCR) and Siemens Building Technologies (SBT). Because SBT is responsible for the Apogee system they provide the tools and skills necessary to access Apogee functionality to implement automated DR as well as a complete understanding of the links to the system for connection of the distributed part of the DR system and the OpenADR interface. The UC Berkeley contribution builds on experience in residential demand response used as a model for distributed demand response in commercial buildings. 6 Service Oriented Architecture: Local Gateway The local gateway has many roles to play and requires a peculiarly flexible architecture. Because a building would have many of these, each connected to a different and changing set of devices, its maintenance, software updates and addition of new devices or removal of old ones, must be an efficient and transparent process. Rather than attempt to develop such a system from scratch, the architecture being developed in another UC Berkeley project for a residential energy gateway (Reference Design for a Page 13 of 16

14 Residential Energy Gateway, sponsored by the California Energy Commission via the California Institute for Energy and Environment). Figure 9. Residential Energy Gateway Design Figure 9 shows the overall design of the residential energy gateway. This design has many components in common with the local energy gateway needed for areas of commercial buildings. The main differences are that the outside world would be the building environment, largely mediated through the smart energy box of Figure 6, that there is no smart meter for local areas of a commercial building, and the local generation is more likely to be local storage. The major requirements for the residential gateway are nearly identical what is needed for the local gateway in the commercial context: Have all of the major components that a commercial gateway would need, Show that it operates and performs the energy management functions needed for "smart grid" concepts currently being developed, Run on a computationally modest enough platform to prove economic viability for a commercial product, Have strong modularity so various organizations can work independently, Demonstrate connectivity using several networking media, Page 14 of 16

15 Provide for secure operation, Be field upgradeable for core software upgrades as well as addition of new modules, Provide flexibility for various user interface options. The design of the gateway is based on the OSGi framework ( a modular system using Java to build component based software. The design presently supports communication with local devices ( appliances ) over WiFi, Zigbee, or wired Ethernet. Other communication protocols can be added easily. It communicates with the outside world using the Internet. The user interface is web based, using a web server hosted in the gateway itself. The major difference between the commercial building version of the gateway and the residential version is in the details of the user interface and the algorithms supporting it. For residential use, the demand response model is straightforward: the resident pays the utility bills so is interested in setting preferences that govern the trade-offs between comfort/convenience and cost. For the commercial building version that direct connection to the cost of power is lost. One of the goals of this project is to devise an appropriate business model for the commercial environment. Adaptation of the residential gateway is currently underway and should be ready for testing shortly. 7 Test Scenarios The utility in Northern California serving UC Berkeley s service territory is Pacific Gas and Electric Company (PG&E). PG&E offers a variety of automated DR programs. These are categorized as pricebased and reliability-based programs. As a part of California s goal to move towards dynamic pricing, PG&E defaulted all its large customers over 200 kw of peak demand into a default rate called Peak Day Pricing (PDP). PDP rate is a year round rate with an active summer period. Between May 1 st and October 31 st, the customers are given credits for their part-peak and peak energy consumption as well as credits for their demand charges. However, on nine to 15 peak days during this period, between 2 pm and 6 pm, $1.20 is added to their base rate to indicate grid constraints. The peak days are identified using the average weather forecasts for 5 different cities in Northern California. The DR events are notified a day ahead and entered into the utility s DR automation server (DRAS). At 9 pm the day before the actual DR event day, the DRAS issues a pending signal which indicates that the next day, between 2 pm and 6pm, a DR event will take place. If the site is using any pre-event strategies, such as pre-cooling, then this signal is used to trigger pre-cooling events. On the day of the DR event, at 2 pm, the sites receive a high signal indicating that the price of electricity is high. This triggers the pre-programmed DR strategies. At 6 pm, the DRAS issues a normal signal indicating that the prices are back to normal time-of-use rates. Figure 10 shows the operations. Page 15 of 16

16 Figure 10. DR Event Sequence The initial sequences of operations will be derived from Energy Plus simulations of the building and will be finalized after testing through the summer period. The goal of the DR strategies is to achieve 30% demand reduction and maintain the load shed over four hours of DR event period. Various master and distributed scenarios will be developed and combinations will be tested both using the physical model of the building and the actual building itself. The results of the various strategies will be reported. Page 16 of 16