a distributed intelligent automated demand response building...

A DISTRIBUTED INTELLIGENT AUTOMATED DEMAND RESPONSE

BUILDING MANAGEMENT SYSTEM

System Architecture: Deliverable 1, October 27, 2010

1 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.

DIADR: System Architecture

of 16

Figure 1.Sutardja Dai Hall: Exploded View


of 16

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.


of 16

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


of 16

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


of 16

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


of 16

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 air-

handling 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


of 16

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 -1000 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


of 16

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/ft2) 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


of 16

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.


of 16

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.


of 16

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.


of 16

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


of 16

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,


of 16

• 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 (http://www.osgi.org/Main/HomePage), 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 price-

based 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 1st and October

31st, 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.


of 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.

a distributed intelligent automated demand response building...

Documents