A DISTRIBUTED INTELLIGENT AUTOMATED DEMAND RESPONSE BUILDING MANAGEMENT SYSTEM 1
DOE Award Number & Name of Recipient
1.1
DOE Award Number:
DE-EE0003847
1.2
Recipient:
Regents of the University of California, (UC Berkeley campus), with Lawrence Berkeley National Lab and Siemens Corp as sub-awardees.
2
Project Title and Principal Investigators
2.1
Project Title:
A DISTRIBUTED INTELLIGENT AUTOMATED DEMAND RESPONSE BUILDING MANAGEMENT SYSTEM
2.2
Task Title:
“Task 5: Demand Response Algorithm Development”
2.3
Date of Report:
20 April 2011
2.4
Principal Investigators:
Professor David Auslander, Department of Mechanical Engineering, U.C. Berkeley (UCB) Professor David Culler, Department of Electrical Engineering, U.C. Berkeley (UCB) Professor Paul K. Wright, Director, Center for Information Technology Research in the Interest of Society (CITRIS) and the Department of Mechanical Engineering, U.C. Berkeley (UCB) Dr. Yan Lu, Siemens Corporate Research Inc (SCR) Mary Ann Piette, Lawrence Berkeley National Laboratory (LBNL)
2.5
Key personnel:
Thomas Gruenewald, Siemens Corporate Research Inc (SCR) Prasad Mukka, Siemens Corporate Research Inc (SCR) SilaKiliccote, Lawrence Berkeley National Laboratory (LBNL) Dr. Therese Peffer, Project Manager, U.C. Berkeley and CIEE (UCB)
1
2.6
Authors:
Daniel Arnold, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Kevin Ding, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Tyler Jones, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Dr. Yan Lu, Siemens Nathan Murthy, Student Researcher, UC Berkeley, Applied Mathematics Michael Sankur, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Jay Taneja, Graduate Student Researcher, UC Berkeley, Computer Science Jason Trager, Graduate Student Researcher, UC Berkeley, Mechanical Engineering Rongxin Yin, Graduate Student Researcher, Lawrence Berkeley National Laboratory Siyuan Zhou, Siemens
2
Table of Contents 3
Executive Summary ............................................................................................................................... 4
4
Comparison of Project Accomplishments and Project Goals ............................................................... 5
5
Project Summary................................................................................................................................... 5 5.1 Introduction ..................................................................................................................................... 5 5.2 Baseline Development ..................................................................................................................... 6 5.3 Central Load Management Framework ......................................................................................... 10 5.3.1
FIPA Contract Net Protocol ................................................................................................... 13
5.3.2 Scenario1: Receiving a Goal-- the negotiation protocol developed for cooperative optimization ........................................................................................................................................ 14 5.3.3
Scenario2: Dynamic Response --in the presence of real-time events/ decommitting. ........ 16
5.4 Distributed Load Management ...................................................................................................... 17 5.4.1
Plugload Audit of Sutardja Dai Hall ....................................................................................... 17
5.4.2
Commercial Energy Gateway (CEG) in Distributed Demand Response ................................ 21
5.4.3
Distributed Control Algorithm............................................................................................... 24
5.4.4
Web User Interface ............................................................................................................... 25
5.4.5
Laptop/Desktop power management ................................................................................... 29
5.4.6
Printer Control....................................................................................................................... 34
5.5 Control Architecture ...................................................................................................................... 38 5.5.1
JADE ....................................................................................................................................... 38
5.6 Simulation Based Demonstration .................................................................................................. 40 5.6.1 6
Energy Plus Model................................................................................................................. 40
Products of the Project ....................................................................................................................... 47 6.1 Website or other Internet sites with results of this project. ........................................................... 47 6.1 Networks or collaborations fostered. ............................................................................................ 48 6.2 Technologies/Techniques. ............................................................................................................. 48 6.2.1
Commercial Energy Gateway ................................................................................................ 48
6.3 Databases ....................................................................................................................................... 55 6.3.1 7
Plugload Audit assumptions .................................................................................................. 55
Appendix ............................................................................................................................................. 58 7.1 Energy Plus Model ......................................................................................................................... 58
3
3
Executive Summary
The Distributed Intelligent Automated Demand Response (DIADR) project endeavors to develop an energy management system with intelligent optimization and control algorithms to achieve 30% peak load reduction while still maintaining the building as a healthy, productive, and comfortable environment for the building occupants. The selected building site is Sutardja Dai Hall at UC Berkeley. Two earlier reports outlined the System Architecture and the Building Management System integration with the OpenADR protocol that administers the demand response signals. This report describes the development of central and distributed load control algorithms. The report begins with a discussion of establishing an energy baseline, with which to compare any energy savings. The next section describes the algorithms that manage central loads, such as Heating, Ventilation, and Air Conditioning (HVAC) systems as well as lighting systems. Many factors, such as weather and occupancy patterns and a model of the building enter into the algorithms; the architecture is multi-agent and distributed rather than central and top-down, requiring a negotiation protocol. The following section outlines the development of the distributed load algorithms. This process started with an innovative plugload audit of the building to automate the process of logging and accessing information about each appliance in the building. Fundamental to the distributed load management was the development of a commercial gateway. Multiple gateways can be distributed throughout the building, each controlling a number of plugload devices typical of an office, such as computers, printers, task lamps, portable heaters or fans, and refrigerators. A user interface was instrumental to the gateway to engage occupants and provide choice of appliance curtailment during DR events. Laptop/computer power management and printer management are outlined in detail. The control architecture is discussed in the next section, including discussion of agent-based control. Finally, an Energy-Plus model was developed for the algorithm simulation; the details are in the Appendix. This research will add to the body of demand response research by pushing the boundaries of typical DR goals. While typical DR goals for commercial buildings is on the order of 10%, this project plans to triple that energy reduction by expanding the role of control to distributed nodes. Reliance upon centralized pre‐programmed controllers to take action based on a demand response signal can result in a loss in the system responsiveness to the dynamic changes of energy price, occupancy patterns, load requirements as well as weather conditions. The distributed approach embeds as much autonomy as possible in local sections of the network to enable distributed optimization and control functions. The techniques involved in this work mostly rely on software; this implies that applying this process to other buildings is relatively inexpensive. Intelligent algorithms rely on distributed sensors (hardware) to provide information. However, a goal of this project is to optimize economic feasibility, by balancing information points with cost to provide the best control strategies with the fewest sensing points. Demand Response in general aims to reduce peak electricity consumption, which can benefit the public by slowing the pace of creating new power plants and reducing air pollution created by older peaking power plants. This project not only deepens a building’s demand response, but also actively engages occupants in order to maintain a productive work environment.
4
4
Comparison of Project Accomplishments and Project Goals
The Demand Response Algorithm Development (Task 5) includes six subtasks: DR optimization and control architecture design, central load management optimization algorithm development, distributed load management (Agent-based) development, DR optimization with onsite DG, simulation-based demonstration of DR optimization and control, and documentation (this report). All subtasks but one were accomplished according to plan. Regarding subtask 4, since the building selected for this project did not currently have any distributed generation (DG), we decided to focus on energy storage instead. The simulation of the DR algorithms will be demonstrated to DOE on April 27, 2011. Tyler Jones of UC Berkeley developed a program using MATLAB to determine a baseline value to be used for centralized control. Yan Lu and others at Siemens Corporate Research developed centralized load management optimization algorithms, which include the HVAC system and many of the lighting controls of Sutardja Dai Hall. Michael Sankur and other students from UC Berkeley created an agent-based distributed load management system (Commercial Energy Gateway), with which plug loads in the building will be controlled directly. Jason Trager and other students from UC Berkeley conducted a plugload audit of Sutardja Dai Hall in support of the algorithm development. In addition, a user-interface for the gateway collects local parameters for the HVAC system and lighting control and submits them to the central control system for further strategy implementation. Jay Taneja and Nathan Murthy of UC Berkeley developed strategies for curtailing plug load such as desktops, laptops, and printers during Demand Response events. Kevin Ding and Nathan Murthy of UC Berkeley developed a User Interface for the Gateway. Siemens introduced the UC Berkeley team to JADE as the control architecture for the interaction between the central load management system and distributed load management system, setting up the protocol for communication between the two acting agents. SilaKiliccote and Rongxin Yin of Lawrence Berkeley National Laboratory developed an Energy Plus model of Sutardja Dai Hall for use on the Distributed Intelligent Automated Demand Response Project. The Energy Plus model is being used to simulate the building HVAC, plug load, and lighting parameters to estimate the distributed load by control zone. The model will be used to estimate and predict the building energy consumption and temperature for various HVAC and lighting control scenarios in the interest of optimizing demand response control strategies.
5
Project Summary
5.1
Introduction
Sutardja Dai Hall is a 141,000 square foot building on the UC Berkeley campus that houses the Center for Information Technology Research in the Interest of Society (CITRIS). Much of the building occupancy is dedicated to offices, with a few classrooms, an auditorium, café and a nanofabrication lab that is not included in the project’s energy reduction goals. The whole building demand load is approximately 940kW. The diagram below describes the basic system architecture: a demand response signal is sent by the Demand Response Automated Service (DRAS) and is received by the Siemens Smart Energy Box (SEB) 5
installed in Sutardja Dai Hall at UC Berkeley. The SEB then generates a load shedding goalsent to the Building Automation System for the HVAC system, the WattStopper lighting system, and to the distributed load gateways that control appliances.
Figure 1: Overall DIADR control management system.
Siemens met with the facilities manager to determine which elements of the building could be subject to demand response control and which were not allowed. (The building houses an energy-intensive nanofabrication laboratory that is not included in the energy reduction goals of the project, but shares chilled water with the whole building). Initial control strategies include: expand the allowable building zone setpoints(minimum to 69F and maximum to 78F), precooling to 69F before occupied, can change duct static pressure and supply air speed, and can turn off some air handling units, supply fans, and exhaust fans. For lighting, some overhead lighting can be dimmed (stepped dimming). UC Berkeley conducted a plugload audit of the building to determine gateway controllable loads, such as computers, monitors, printers, coffee/tea pots, task lamps, and portable heaters and fans.
5.2
Baseline Development
In order to determine an appropriate goal for DR load shed, a proper baseline load for a normal day must be demonstrated and defined as a reference for gauging how effective the control strategies are with the project goals of 30% load shed during a DR event. UC Berkeley has worked on a program to predict a baseline for Sutardja Dai Hall for a day in which a DR event is to occur. This baseline can be used for feedback control as a reference to engage further DR strategies in cases where the commercial DR goal is not met.
6
The baseline prediction program uses a series of inputs including Outside Dry Bulb temperatures, power data from the past ten days, power data from the morning of at 10 AM and 11 AM, as well as power data from a year ago and HVAC data if available. The baseline prediction program first draws data from the sMAP1 server, a server developed by students at UC Berkeley containing weather and energy data from numerous sites on campus. On the day of a DR event, the program will be run after 11 AM to generate a baseline load profile for the day. The program generates a discrete profile with a sampling time of 5 minutesdue to the limit of the Siemens BMS Apogee points set to 5 minutes for the data. The program is based on a LBNL’s Best Method that uses data from the morning of the DR event to create a first correction factor for the DR Day. Data from the ten previous days is also accessed with the hottest 3 days selected for use. The submeterdata from 10 AM until 6 PM of the hottest three days is averaged for each time step. A correction factor was created using the actual loads at 10 AM and 11 AM of the morning of the DR event. The correction factor is described as:
Where: al(d,h) – the actual load for the day and the hour pl(d,h) –the average of the 3 highest actual loads at this hour over the 10 previous days. The baseline prediction was tested for 5 days. Figure 2 shows two of the days tested in which data was available to run the program with sufficient data.
11
Simple Monitoring and Actuation Profile (sMAP) defines a data schema and API to allow multiple disparate interfaces to communicate data. Details regarding the sMap server can be found at http://www.openbms.org/smap/plot
7
Figure 2: Baseline Prediction tested for October 14 and 15, 20102
The prediction requires increased robustness of accuracy with respect to weather fluctuation. There may be problems if the prior ten days have been cold and the DR day is the first day that is classified as a DR day. This calls for the use of a second correction factor using data from the past year with a correction factor accounting for HVAC efficiency, as well as occupancy. Both of these parameters are not currently dynamically measurable due to current limitations with submetering and actuation. However, a static occupancy estimation can be used based on total building employee numbers for various time periods. This assumes that with significantly larger numbers of employees assigned to a work station, there is a strong correlation with the number of people that are expected to be at work on 2
Note: Dates for testing were limited due to submetering implementation. Many of the days that could be tested as DR days lacked the data.
8
any given day. Employment numbers from previous years were gathered and used to create a second correction factor. The HVAC parameters currently are not accessible due to the lack of equipment to measure HVAC process flows in the building. The program factored occupancy manually for these calculations until more data is available. The second correction factor is dependent on the HVAC efficiency parameters, which can be calculated with parameters of the mass flow rate of the chilled water, and the inlet and outlet temperatures of the chilled water, as well as the actual power measured for the compressor in compression chiller. The equations guiding these calculations are shown below.
Where: m : mass flow rate of chilled water, kg/hr Cp : Specific heat, kcal/kg °C Tin : Chilled water temperature at evaporator inlet, °C Tout: Chilled water temperature at evaporator outlet, °C kW/ton rating =
The COP from last year is compared to the COP this year based on measurements and the ratio is used as the correction factor.
This correction factor will be very crucial in developing a baseline for DR events. It will be implemented once the submetering is available. There is also possibility for occupancy data to be collected. These methods have not yet been decided on but once implemented can provide information to increase the accuracy of the baseline profile model. A test using the static occupancy data for a given day proved to provide small improvements in the accuracy of the prediction.
9
Figure 3: Comparison of Prediction without and with Occupancy Correction Factor
Figure 4: Error of Prediction without and with Occupancy Correction Factor
Further development of the baseline will be possible with the future installation of submetering equipment in Sutardja Dai Hall, including HVAC submetering dealing with flows as well as improved occupancy data.
5.3
Central Load Management Framework
Siemens Corporate Research (SCR)has worked on the control architecture for DIADR system, defining the distributed Demand Response (DR) control framework based on multi-agent and market-based control approach.
10
For centralized DR control, only one top-tier DR Manager works as the decision maker to control building load shedding/shift/shaping and the local DR Manager only needs to execute the commands from the central DR Manager. To generate control commands in response to the DR event centrally, all of the local system (HVAC, lighting, distributed zone/offices) observations and states have to be fed to the central DR Manager. As the local status changes from zone to zone, the central DR Manager must reconfigure the DR strategy. Figure 5 shows the architecture of centralized DR management, where there is a central DR Manager making a decision on the load shaping strategy to respond to DR events. The central DR Manager sends direct control commands to each subsystem and distributed load controller, which implement the desired strategy for each load in the building. The control commands include but are not limited to set points for individual zone temperature, Air Handling Unit (AHU) supply air pressure, fan speed and dimmable light settings, as well as on/off switching of distributed loads, power generation and energy storage. To make a reasonable and optimal decision, defined as achievingmaximal demand reduction,while still maintaining the building as a healthy, productive, and comfortable environment for the building occupants, the central manager should keep all the static and dynamic information about the sub-systems and local distributed load control systems. The static information is stored in a global database and the dynamic data is updated in the Run-time Data Repository. The static information includes the whole building information model, as well as the operation schedules. The dynamic data reflects the real-time subsystem and local control system states, temporary occupancy changes, space mission changes and meter data. In addition, a user interface is also included for the building operator to change the DR configurations. Online connection to weather service is needed by the central manager to create DR strategy based on load prediction. Usually, the larger loads will be assigned more load shedding during the peak period.
Figure 5: Centralized DR control architecture.
11
For centralized DR control, the subsystems and local controllers are completely passive, acting as an executor without intelligence. The centralized control is not flexible and robust. Whenever there is a real-time event happening, either from User Interface or from subsystems, the central manager has to reconfigure the whole system again, which could takes several minutes and makes fast DR impossible. On the contrary, if distributed DR is implemented, the task of decision-making is distributed to local control and gateways. The top-tier DR Manager only needs to pass DR signals or generate goals to pass on to the second/third tier DR Managers. For example, agents could react to DR events using market mechanisms by bidding either for energy service or load shedding if an economic incentive is given. The controlling agent can be hosted at the subsystem level as well as in the central device (e.g. for HVAC and lighting control, the Smart Energy Box (SEB) can host agents for HVAC load and light load DR control). The agent can sense, derive, plan and execute autonomously. This architecture also allows local agent aggregation to respond to a local event without making overall system configuration. A multi-agent architecture has been proposed for distributed demand response. Each building control subsystem, local distributed load controller, distributed generation and energy storage is represented by an agent, including HVAC agents (HVACA), the lighting control agent (LCA), the Gateway agent (GA), distributed generation agent (DGA), energy storage agent (ESA). In addition, there is an SEB Agent (SA) which acts as a task agent which also receives DR signals. The SEB generates the load shedding/shifting/shaping goals after receiving DR signals. The load agents(HVACA, LCA, GA), the energy generation agents (DGAs) and energy storage agents (ESAs)perform load shedding/shifting/shaping to achieve the DR goal. Figure 6 shows the potential control architecture for distributed DR management.
Figure 6: Distributed DR control architecture In order for the agents to find a feasible global DR strategy, the agents must cooperate and coordinate their local actions. The most widely used cooperation and coordination method is the Contract-Net Protocol (CNP). The CNP is a high level protocol for achieving efficient cooperation,and is based on a market-like protocol. The CNP has been extensively used for inter-agent cooperation in dynamic resource management; it also was standardized by many international organizations and implemented 12
based on multiple open-source agent platforms. The FIPA Contract Net Interaction Protocol (IP) is one of such protocols, which defines a minor modification of the original contract net IP pattern in that it adds rejection and confirmation communicative acts. Using Contract Net can be advantageous when compared with other coordination strategies for the following reasons outlined below. 1. Tasks are assigned (contracts awarded) dynamically, resulting in the better deals for the parties (agents) involved. 2. Agents can enter and leave the system at will. 3. The tasks will be naturally balanced among all the agents since agents that already have contract(s) don’t have to bid on new ones. If an agent is already using all its resources, it will be unable to bid on new contracts until the current ones are completed. 4. A reliable strategy for distributed applications with agents that can recover from failures (to be discussed more in the following paragraphs). 5.3.1
FIPA Contract Net Protocol
In the contract net IP, one agent (the Initiator) takes the role of a manager that wishes to have some task performed by one or more other agents (the Participants) and further wishes to optimize a function that characterizes the task. This characteristic is commonly expressed as the price, in some domain specific way, but could also be the soonest time to completion, fair distribution of tasks, etc. For a given task, any number of the Participants may respond with a proposal; the rest must refuse. Negotiations then continue with the Participants with proposals. In FIPA Contract Net Protocol we basically have two different actors, an Initiator and a Responder (Participant in the picture). The Initiator asks for m proposals from different Responders by sending a call for proposal (known as CFP). The CFP specifies the task the Initiator wants the Responder to achieve as well as any kind of conditions the Initiator is placing upon the execution of the task. Within these conditions, we define a deadline for Responders. Once the deadline passes, the Initiator will evaluate two kinds of responders, the ones who will PROPOSE and the ones who will REFUSE. Within the Responders who will PROPOSE, the Initiator will selects agents to perform the task: one, several or no agents may be chosen. The Initiator will send an ACCEPT-PROPOSAL message to selected agents, and a REJECT-PROPOSAL message to others. Once the task is performed by the Responder, it will send an INFORM-done- result message to let the Initiator know that the task was successfully performed or a FAILURE message if the message was unsuccessfully performed. Figure 7 shows the typical FIPA bidding-negotiation sequence.
13
Figure 7: FIPA Contract Net Protocol 5.3.2
Scenario1: Receiving a Goal-- the negotiation protocol developed for cooperative optimization
Figure 8: SEB Agent as buyer, Load Control Agent as seller
14
Upon receiving the DR signal, the SEB Agent (SA) analyzes the announcement and generates a load shedding goal for the requested DR period. Negotiation starts with identifying the load, generation and storage agents to generate the schedule for load shedding. The SEB Agent sends the DR-announcement message to the load/generation/storage to request the shedding of energy usage. The DRannouncement message describes the following information: Sender: SEB Agent, Receiver: HVAC Agent, Lighting Control Agent, Gateway Agent, Distributed Generation Agent and Energy Storage Agent Type: Load shedding task announcement, Task specification: the load shedding requested by the BDRA with the description of duration of the DR event, maximal cost and penalty for de-commitment. Bid-reception deadline: the time by which HVAC Agent, Lighting Control Agent, Gateway Agent, Distributed Generation Agent and Energy Storage Agent must respond with a bid.
The bidding process starts after the HVAC Agent, Lighting Control Agent, Gateway Agent, Distributed Generation Agent and Energy Storage Agent receive the load shedding task announcement. A bid represents an offer to execute the task specified in the DR-announcement concerning the production of the load-shedding required by SA. Each HVAC Agent, Lighting Control Agent, Gateway Agent, Distributed Generation Agent and Energy Storage Agent will inspect the DR-announcement message and will decide whether or not it should respond with a bid, considering its own operation schedule and status of the equipment. To respond, it will develop its locally optimized scheduling and sends an LS (Load Shedding)bid message to the BDRA. The LS-bid message describes the following information: Sender: HVAC Agent, Lighting Control Agent, Gateway Agent, Distributed Generation Agent and Energy Storage Agent, Receiver: SEB Agent, Type: bid, Bid specification: the load shedding to produce with the proposed production time Bid-acceptance deadline: the time by which the SEB Agent must respond with a contract.
After receiving the bids before the bid-reception deadline, the SEB Agent evaluates the LS-bids and selects the best bid based on the cost.
15
Contracting starts after the SEB Agent accepts/rejects the bids. SEB Agent can respond before the bidacceptance deadline with the following alternatives: • Accept the bid and send the award message to the appropriate load/generation/storage agents. • Accept the load shedding in the bid and renegotiates the production of load shedding with increased maximal cost. The SEB Agent restarts a re-negotiation session with a new announcement message, which specifies the part of load shedding with higher cost and an additional allowance of lower penalty. The renegotiation process iterates cyclically until the SEB Agent states that the solution matches the requirements of its schedule within acceptable tolerances. A failure to send a contract message before the bid-accept deadline means the SEB Agent is rejecting the bid.
5.3.3
Scenario2: Dynamic Response --in the presence of real-time events/ decommitting.
Figure 9: Load Control Agent as seller and buyer. The task agent and the SEB Agent negotiate the operations of the task with the resourceagents (HVAC Agent, Lighting Control Agent, Gateway Agent, Distributed Generation Agent and Energy Storage Agent) using the CNP. When a resource agent, for example, the Lighting Control Agent, detects a light-sensitive use case such as for a lab experiment, it can senda fault message to the SEB Agentthat has contracted its operations. The SEB Agent will renegotiate the operations with other resource agents capableof
16
performing the operations. Other resource agents can make decisions based on their status to respond for a bid or not. Hence, not every resource will be impacted. A more flexible reconfiguration can happen if we treat each agent as both task and resource agents. When the Lighting Control Agent finds it cannot commit the task, it can send a CFP (call for proposal) to its peer agent and request for load shedding. In the same way, the LCFnegotiates using the CNP with the peer agents in its database that can cover the load shedding task. InFigure 9 shown above, it turns to distributed generation for task rescheduling.
5.4
Distributed Load Management
Management of distributed loadsis a major goal for the DIADR project and has been led by the UC Berkeley team.The first step was conducting a plugload audit of the building to determine how many and what type of appliances were in the building, as well as how much power each consumed. To implement the individual strategies for control required a gateway; the Commercial Energy Gateway (CEG) was developed for this project to communicate with the Smart Energy Box and negotiate control of devices. Each device, whether smart or “dumb” will have power characteristics that are accessible to the Gateway and allow the Gateway to make intelligent decisions as to how the devices in the given sphere of influence are to be controlled.The power is measured instantaneously on all devices and their states are relayed back to the Gateway, either independently or with the use of a switchable power strip (SPS). The Gateway, after gathering the states of all machines, the user preferences, and receiving the shed goal from SEB, categorizes and orders the control tasks to be submitted for implementation in the office spacebased on the preferences set by the user and the possible savings that can be harnessed. Finally, UC Berkeley has explored individual strategies for computers with energy storage capabilities such as laptops and desktops connected to uninterruptable power supply (UPS) devices, and printers. 5.4.1
Plugload Audit of Sutardja Dai Hall
Plugload auditing of Sutardja Dai Hall has been completed as an assessment of the static base load of the building. The next step is to understand the dynamic behavior of distributed loads in the building through limited but increasing sensor deployment. The Rapid Auditing Protocol (RAP) allows researchers to energy audit the building in a continuous fashion, and will lead to effective demand response through improved user involvement and awareness of energy usage throughout the building. The protocol involves the following steps: Record Device Information: o Power usage o Local coordinates (relative to room origin [west,north] o Device power draw or amperage rating o Device make and model number o Device type (place in taxonomy) o Extra information
17
Scan device QR code (unique for each device) Take picture of device Enter device in database This energy auditing protocol can place each device into the database in approximately one minute, and is very useful for assessing the energy usage of the building on a room by room, floor by floor basis.
Figure 10: Example of unique QR Codes Used for Rapid Auditing Protocol The current auditing procedure involves the use of an Android smart phone application to conduct the audit and database entry in one combined system. In order to enter an object into the database, an auditor enters the room, locates the South-West corner, and begins to document devices in the room using certain assumptions3. This information is fed into a datastore capable of publishing data to a report. A MATLAB code developed by UC Berkeley is used to produce a static power usage map of any room. An example of the data in a Power Usage Colormap is shown for room 464 in Sutardja Dai Hall in Figure 11. This power map will eventually be animated using data provided by the Simple Measurement and Actuation Profile (sMAP). The sMAP server pulls data at various time intervals from live feeds on campus and stores them in a database that can be accessed for the Power Map as well as other applications within the project. This active animation allows for the integration of time and space into the feedback of power use in the building. It is through these mechanisms that human users may acquire an interest in and actively participate in the feedback loop of energy conservation. Figure11 below show the energy map of the room while a refrigerator is running, and when it is not. Axes are measurements in feet.
3
The assumptions for the Rapid Auditing Protocol are listed in Section 7 Appendix Table
18
Refrigerator on Energy Map
Figure 11:Energy plan of room showing refrigerator currently running (Left) and off (Right).
Figure 12 shows the refrigerator duty cycle that is being monitored over a 6 hour period using sMAP. During the peaks on the graph, the refrigerator is on and will show up on the Energy map. When the refrigerator is off, it will change color on the Energy map. This energy map may be developed for large scale use in which building occupants can understand their energy use better and may offer a social solution to problems of unnecessary energy use.
19
Figure 12: Time plot of refrigerator duty cycles.
The plugloaddata is shown below in Figure 13, a total of 730 devices with total faceplate power draw of 65.8 kilowatts. Note that nearly 60% of the appliances are computers and printers, which draw less than 50% of the load. On the other hand, while there are relatively few electric tea kettles and coffee makers, these draw lots of power. The water heaters also have high power consumption.
20
100% 104
90%
7 2 14 51 29
80% 70%
5434.9 5352
Microwaves 12000
49 22 54
50% 40% 30%
214
Water Heaters Elec kettle/coffee maker
94 60%
Other
12149 76.24 1600 216.2 558 2700 2564.65 11066.4
20%
Phones Lamps/Plug Lights Electronic Desks Laser Printers Imac Notebook Computers
10%
90
12089
Computers
0% Number of devices
LCD monitors
Cumulative Power (W)
Figure 13: Device count and power breakdown for Sutardja Dai Hall
5.4.2 5.4.2.1
Commercial Energy Gateway (CEG) in Distributed Demand Response Introduction
The Commercial Energy Gateway4 (CEG) is a communication and control software package, developed to be an open-source and open-standard architecture for use in commercial applications. The essential functionality of the CEG originates from the Energy Information Gateway (EIG or Gateway for short) originally developed for residences and converted for commercial applications. The primary purpose of the EIG is to empower users to manage their energy usage more effectively. In a commercial setting such as for the commercial demand response, this amounts to establishing communication and control between appliances in the CEG’s sphere of influence and communicating energy and control information to the user in a practical manner. The sphere of influence may include lighting, smart appliances that can be controlled directly as well as “dumb” appliances, which can be controlled through the use of load switches or switchable power strips (SPS) that can be directly controlled by the Commercial Energy Gateway. Central to the operation and success of this project is enabling widespread connectivity over several communications media (e.g. WiFi, ZigBee, Zwave, LAN, etc), which make up the current marketplace of smart communicating energy products. The Gateway also relies on a Web User Interface (UI) that is in the process of being developed.
4
Additional technical Information for the Commercial Energy Gateway can be found in Section 6.3.1 of the Task 5 report
21
5.4.2.2
Functionality of the CEG
The CEG is designed as a communication and control system that aggregates appliance and device power consumption data and presents it to the building management system for automated control based on a set of goals determined for a given DR event period. It is also designed to automatically exert control on appliances and devices within its sphere of influence during a DR event. Currently this is done on a priority based model, in which appliances/devices with low priority settings are turned off or their power use is altered before ones with higher priority settings. The CEG goes through its list of connected and controllable appliances and devices exerting control when needed to meet a goal of power reduction. The user is still allowed supervisory control over the EIG operation during these events. For example, suppose a user is running intense computation when a DR event starts. The user can override control of their computer to continue the computation instead of having the CEG set the computer to a standby or sleep mode. There are two types of appliances, dumb or legacy appliances and smart appliances. For the sake of simplicity, appliances will refer to actual appliances, such as any electrical power load such as a lamp, fan or computer. Dumb appliances are what the majority of household and commercial spaces currently employ. These do not monitor their power usage and do not have connectivity capability. Therefore external monitoring and control is needed.
Figure 14: Current EIG configuration for testing What is envisioned is that dumb appliances will have a switch and sensor package between its plug and the wall socket that reports its load data and can turn the appliance on and off. Within the DIADR project, two packages are in use: Raritan Dominion PX switchable power strips (SPS) and ACME meters, produced at UC Berkeley. The SPS is an Ethernet enabled power strip that houses eight controllable outlets. For example a dumb appliance is plugged into an outlet on the SPS. When the EIG is running it regularly polls the SPS for outlet power use data. When a DR event occurs, the EIG selects the appropriate appliances to turn off and send a command to the SPS to cut power to the appropriate outlet.
22
In the future smart appliances will become more ubiquitous. These are appliances that can have connectivity capability, can monitor and control their own power use, and are envisioned to have more power states than on and off. The EIG looks to the future and proposes an open standard for communication and control of smart appliances, by using a widely used language, XML, to send and receive control and data respectively. Students at UC Berkeley are also developing computer simulations of smart appliances that can run on a variety of platforms to demonstrate the versatility of the EIG’s open-standard. These smart appliance simulations are also used in simulating DR events and their projects. The CEG is designed to enable the communication of multiple CEGs and a building management system working in conjunction to reduce power use in a large commercial building. The EIG is built on the concept of open-standard connectivity so that it can connect to any appliance that can utilize XML. This connectivity will help multiple EIGs communicate and jointly develop a strategy to meet a power reduction goal during a DR event. 5.4.2.3 A Lab Plan for Distributed Load DR Control Demonstration Figure 15 shows an SCR lab demonstration plan for distributed load control using the same gateway as previously described. The red lines indicate the connections with AC power, the blue solid lines represent wired connections, the blue dash lines represents wireless connections, and the blue dash dot lines indicate the connection can be either wired or wireless. The plug load appliances are divided into four groups: task lights, portable heaters and humidifiers, printers and other smart appliances, and the office kitchen appliances. The sensors will provide environmental status so that Gateway can decide which appliance to control based on the related factors. The different group of appliances will also have corresponding priorities.
23
Controller Controller
Occupancy/ Light Detector Power Meter
Power Meter
Office Kitchen Appliances
Printers and other Office Electronic Devices
Power Connection Communication Conncetion – Wireless Communication Conncetion – Wire
Distributed Load Controller
Controller
Communication Conncetion – Wireless/Wire
Controller
Portable Heater and Humidifier
Power Meter
Temperature/ Humidity Sensor
Power Meter
Task Lights
Figure 15: Local DR control scenario Figure 15 shows the logical plan instead of the physical relationship. For example, the Power Meter might be physically inside a controller, or all sensors can be in a same box. The physical picture is subject to change with the specific devices to use.
5.4.3
Distributed Control Algorithm
The Gateway functions as the main actor and makes decisions for distributed control. The Gateway has access to the current power data and to environment parameters. The Gateway also has user preferences that can be entered using a Web User Interface. The Commercial Energy Gateway houses the specified algorithms for laptops/desktops, printers and other devices. It will measure their power instantaneously and then prioritize the tasks for implementation during a DR event. Objects that have the potential to shed the most load and have no restrictions are listed first as possible solutions. The Gateway will then make suggestions to the SEB for further confirmation. Once the suggestion is accepted, the Gateway will implement the change. The distributed algorithm relies heavily on the user input from the User Interface which will be discussed in the next section.
24
5.4.4
Web User Interface
Providing an easily accessible, user-friendly and intuitive interface for client access to the Energy Gateway has been a crucial piece of the project. The user interface can be used by occupants of the building to enter his or her personal appliances within his or her own control, such as computers, coffee makers, and/or task lamps. The occupant could then prioritize these devices with respect to DR curtailment. For example, the user could choose to dim or turn off the task lamp and not use the coffee maker during a demand response event, but always have the computer functional; these preferences would be used by the gateway in deciding which loads to switch off during a DR event. The user could also indicate preferences for heating, cooling, ventilation, and lighting levels, which would be relayed to the Smart Energy Box. The interface would allow the occupant to override prior set priorities to provide greater flexibility. The following will provide a brief and comprehensive guide into the architecture of the website, some insights into the decisions that were made, problems faced and solutions used to achieve our goal in providing the UI. 5.4.4.1 Architecture The interface originally began as a very simple webpage written in HTML, designed with CSS and filled with static fields and variables serving as placeholders in an empty mold. For simplicity, the visuals were designed with three main components in mind: the configuration page, operation page and event page. The configuration page was built to serve to allow the user to add appliances and select curtailment priorities during DR events. A user can navigate through the configuration page to change appliance priorities and energy states with respect to the current DR event. The pages below represent Engineering screens with all the possible data; the user screen for the lay person will be simpler with just basic information.
25
Figure 16: Configuration Page On the operation page, the occupant would find out about current appliance state and energy consumption.
Figure 17: Operation Page
26
Figure 18:Operation Page: After selecting one of the devices for in-depth examination The Events tab provides the occupant information about the actual DR events, such as a timeline of past, current and future DR events along with their durations and severity levels.
Figure 19: Events Page Overall, these three main tabs of the user interface were built with the goal of being easily accessed from any computer or computing device on the local network, traversed in any order that the user
27
chooses and most importantly, provide the user with the necessary tools and information to control and optimize the enclose environment. Once the physical layouts of the pages were finalized the dynamic aspects of the webpage were developed. Javascript was at this time adopted as the official client-side scripting language of this project with future standardization in mind. At the beginning, Javascript provided very basic tools to transform and update the webpage depending on the users’ action, but the interface was still lacking the connectivity that would allow the UI to communicate with the Energy Gateway. The solution to this problem first began with the installation of an Apache webserver on the same device that the UI resided. Because Javascript only provided front-end functionality, PHP was then realized as the standard server-scripting language and a potential candidate to do most of the backend communication transactions between the Energy Gateway and the web UI. Naturally AJAX was also taken on and used as the primary communication medium between Javascript and PHP. The only problem remaining was to bridge the gap between the server and the Energy Gateway and this was done through the use of sockets. This decision was made based upon the conclusion that the Energy Gateway would probably sit on the same machine as the web UI and sockets would provide a fast prototyping method to demonstrate the capabilities of the Gateway system. Though there were some problems with the socket communication, it was quickly resolved in constructing a clean and well-defined format in transferring data from UI to Gateway and vice versa.
Figures 20 and 21 are simple flow charts of how the web UI communicates with the Gateway as well as with itself with full bi-communication functionality.
Javascript picks up action from user, updates current page and sends changes to PHP via AJAX
PHP handles request by passing it as a xml string based on a control schema to Energy Gateway via socket
Energy Gateway accepts update and sends back acknowledgement
Figure 20: Downstream Data Flow Diagram
28
Javascript processes updated data and displays it out onto the screen.
PHP recives data, sends acknowledgement to Energy Gateway, updates current perferences and forwards changes to Javascript
Energy Gateway reacts to ADR or installation of new device and sends data to web UI
Figure 21: Upstream Data Flow Diagram
5.4.4.2 Conclusion At the present, a fully functioning web UI has been created to handle updates and send requests to the Energy Gateway to change preferences. Basic override functionality and control over appliances have been developed and most if not all communication issues have been resolved. More work still needs to be done on the UI to provide users with a greater sense of comfortable and intuitive experience, which will be the main focus for the remainder of the project. There is already work underway to shift platforms from pure HTML and CSS to the Drupal platform and some investigation into java swing, flash and other GUI development software to develop more aesthetically pleasing apps and features on the web page.
5.4.5
Laptop/Desktop power management
Students at UC Berkeley have developed a general theory for developing distributed algorithms for plug load management of devices with energy storage capabilities (e.g. laptops with batteries, desktops with UPSes, etc.). The following describes the definitions of the algorithm, the algorithm itself, and simulations of the algorithm. UCB has made use of the notion of a control gateway in the architectural sense of the telecommunications layer that sends a demand response signal from an ISO/RTO or utility/aggregator to a DRAS from which a “smart energy box” takes this signal and passes it to a control gateway: Definition 0.1 A control gateway administers load control algorithms. Definition 0.2A zone, denoted by Z(k,t), is a collection of loads/devices under the purview of a control gateway where k represents the specific control gateway acting on that zone at the discrete time t. Definition 0.3 We say a device belongs to a zone Z(k,t) if that device is under the purview of a control gateway k at the discrete time t.
29
Definition 0.4 All devices belong to a null zone, denoted by Z(0,t), if they have never been under the purview of any control gateway up until discrete time t. Definition 0.5 Suppose a device d that belonged to Z(k,t1) at time t1 now belongs to Z(k’,t2) at time t2 for control gateways k and k’. We say that a device leavesZ(k) and arrives to or enters Z(k’). Definition 0.6 We say that a load or device is stationary on [t1,t2] if that device belongs to Z(k,t1) and does not leave until discrete time t2. A load or device is said to be strictly-stationary if that load/device belongs to Z(k, t) for any discrete time t over an entire time series. We say that a device is non-stationary on [t1,t2] if a device that belonged to Z(k,t1) up until t1 leaves at or after that time and enters Z(k’,t2) at or before t2. Given N electric devices, for each ith device we define: Definition1.1 The positionv(i,t) = of the ithdevice at a discrete time step t is a row vector whose elements represent information (denoted by *) about a power-consuming load at the particular time step t. Definition 1.2 A trace matrix of N positions at the discrete time t is a matrix representation, which we will denote by M(N,t) where N refers to the number of rows in the matrix and t refers to the current time step, of information about particular devices at time step t whereby the position of the ith device corresponds to the ith row of the matrix at time t. Definition 1.3 A power traceT(i,x) is a function that maps an element x of the position of a device to a real number that represents the expected power consumption of a load OR is the empirical/measured power (typically in watts) of the device at the discrete time t. Definition 1.4The capacity, denoted by Chi(i,t), of a device represents information about the amount of energy the ith device has stored at a particular time t. The capacity of a device can be an element of the device’s position if information about a device’s stored energy capacity is pertinent to the energy management objectives of the algorithm. Definition 1.5The connection statey(i,t) of the ithdevice is a Boolean element of a device’s position that indicates whether a device is connected or disconnected from an electric outlet: true/1 if it is connected, false/0 if it is disconnected at the discrete time t. Definition 1.6 The operation state of a device is a Boolean element of a device’s position that indicates weather a device is on or not: true/1 if it is on, false/0 if it is off. We assume, for the time being, that all loads are strictly stationary, their operation state is always ON, and N is fixed throughout all time steps. It is important to distinguish between the connection state and the operation state of a device since a load could be off but still drawing power.
30
Sort and Assign Method (for loads with energy storage) Suppose we have N strictly stationary loads. Let the position of the ith device v(i,t) = fori= 1, 2, …, N, and so we have a trace matrix M(N,t_0) at the initial time t_0 whose rows are [[1 M(N,t) =
t_0 [2 *… [i *… [N
chi(1,t_0) T(1,chi(1,t_0)) y(1,t_0) ] t_0 chi(2,t_0) T(2,chi(2,t_0)) y(2,t_0 ) ] … … … … ] t_0 chi(i,t_0) T(i, chi(i,t_0)) y(i,t_0) ] … … … … ] t_0 chi(N,t_0) T(N, chi(N,t_0)) y(N,t_0) ] ]
We assume that chi(i,t_0) for i= 1, 2, …, N are Gaussian distributed over all N devices. Suppose each device is a laptop. So each laptop battery has a capacity selected at random and the distribution of all battery capacities is normal. Furthermore, at the initial time t_0 we assume y(i,t_0) = 1 for each ith laptop; and so every laptop is connected, drawing power, and has a random capacity. Since the power trace is a function of capacity, the power trace of each laptop is random also. Our objective is to minimize the sum of the traces over every time step (in the context of demand response) so that no laptop battery ever reaches chi(i,t) = 0. We attempt to do this by setting some load curtailment objective that is determined either by some control gateway k or is computed on the basis of optimizing for minimized curtailment of devices in a zone Z(k,t) over all t during the demand response event. We formulate our curtailment objective numerically and iterate over every time step taking note of the fact that power traces over a complete battery charging cycle exhibit exponentially decaying curves that approach some steady-state operation power. This can be seen empirically in the relationship between battery capacity and power trace shown in Figures 22 and 23:
Figure 22: Battery Capacity over time 31
Figure 23: Power trace as a function of capacity Since we would like to minimize power delivery to all of the laptops during a DR event, we want to stay as close to full battery capacity as possible all while disconnecting and reconnecting laptops from a power source when necessary. In our initial model, we did not have any notion about the relationship between capacity and discharge rates. So for our simulation we assume that a battery takes an equal amount of time to completely charge as it does to completely discharge. So we set out to achieve load curtailment as follows: Objective: Subject to:
min T(i,x) Chi(i,t) > 0 (i.e. no laptop runs out of battery)
Input : M(N,t1) Output: M(N,t2) 1. 2.
At each time step, sort rows of trace matrix in descending order of power traces Determine load curtailment coefficient “c” - If c is already given let T(j,chi(j,t1))
