The Design and Implementation of a Smart Building Control System

Han Chen, Paul Chou, Sastry Duri, Hui Lei, Johnathan ReasonIBM Thomas J. Watson Research Center, 19 Skyline Dr, Hawthorne, NY 10532

{chenhan, pchou, sastry, hlei, reason}@us.ibm.com

Abstract—A significant proportion of total worldwide energy is consumed by buildings. For example, buildings in the US account for about 40 percent of total energy consumption and greenhouse gas emission. Making buildings more energy-efficient is an important step to reduce our energy consumption and carbon emission in the combat with global climate change. Broad participation by consumers, business owners, and gov-ernments is required to continuously improve on energy effi-ciency for new and existing buildings and to achieve the global greenhouse gas emission reduction objectives.

This paper provides a software system perspective of improv-ing energy efficiency for buildings. It proposes an architecture that allows for phased investments in technologies to capture the returns from energy savings in various use cases. In addi-tion, it addresses the needs and objectives of different stake-holders, including owners, operators, users, and utility provid-ers. A proof-of-concept implementation of the architecture is used to demonstrate the support for building-wide energy con-servation policies using real-time energy pricing and individual occupants’ locations and preferences. It shows that the proposed architecture enables fine-grained building control and reduces energy consumption while maximizing its occupants’ comfort.

Keywords—smart building; sensor and actuator; sense and respond

I. INTRODUCTION AND MOTIVATION

Buildings account for 30–40% of total energy consump-tion and carbon dioxide emissions in most countries [1]. To ensure the sustainability of the environment and to address the rising cost of energy, reducing energy consumption in new and existing buildings has become a focus of all stake-holders including governments, building developers, owners, operators, tenants and users. Investments in energy efficient building materials and appliances have been shown to result in significant energy reductions with good return on invest-ment. For example, much of the energy consumption by commercial buildings is spent on lighting (26%), followed by heating and cooling (13% and 14% respectively) [2]. In-vesting in energy efficient light bulbs and insulation materi-als can expect short payback periods. Furthermore, simple automation and control such as automated shading have been demonstrated to reduce the energy demands on cooling and lighting [3]. However, the incremental reductions by imple-menting individual energy efficient technologies alone would not be sufficient to achieve the challenging objective of re-ducing energy-related carbon footprint called by IPCC [4]. We believe that significant additional energy efficiency gains could be accomplished by adopting holistic, integrated ap-proaches that encourage shared responsibility among the stakeholders and motivate behavioral changes by the build-ing users. Information technologies need to play a central role here, specifically with regard to the following.

• Enforcement of building energy codes, policies and guidelines. Already many governments have mandated

extended building energy codes and provided financial incentives that help break the first-cost barrier to encour-age investments in energy efficiency. The effectiveness of the mandates and incentives depends on continuous moni-toring and auditing of the energy performance and compli-ance. Building owners/operators may also impose policies and guidelines regarding energy use to reduce overall cost. IT needs to support and enforce such codes, policies and guidelines as business rules.• Visibility to building professionals and users about energy saving opportunities. Building operators can ana-lyze energy performance trends and exceptions to reduce building energy waste and inefficiency. Fine-grained, user-level metering promotes better awareness and accountabil-ity. Consistent feedback on energy usage can lead to be-havioral changes by energy users and result in sustained demand reduction [5].• Integration with the power grid via demand re-sponse. This allows the system to manage consumption in response to supply conditions by, for example, selectively turning off appliances or reducing non-essential or non-time-critical services. Demand response helps equalize the load of the grid by lowering the peak load and allowing increased use when production exceeds demand. Energy suppliers could avoid costly capital investments for gen-eration capacity; and consumers would benefit from shar-ing the savings resulted from the lower operational cost of energy production. • Autonomous building operations through continuous sense and respond. This enables the system to manage building energy consumption holistically. It integrates the dynamic information of users’ activities (e.g. location), ambient conditions (e.g. weather, light), and energy supply conditions (e.g. cost, load). It also takes into account the perspectives of various stakeholders (e.g. business mis-sion, cost, preferences, safety, comfort, convenience). The result is optimized building operation with the greatest energy efficiency.The investments on IT systems for energy-smart buildings

will need to be recouped from realizable financial returns. From this perspective, a key system design principle is to be able to accommodate incremental adoption of technologies and new features into existing systems over the life time of a building. This helps ease the first-cost barrier and allow building owners and planners to prioritize the investments and potentially reinvest the realized returns over time.

The overall lifecycle cost of IT systems is a determining factor of the rate of return on investments. As smart building systems become more sophisticated, it would be financially and technically difficult for building operators to manage the IT systems by themselves. The emerging cloud computing technologies provide a viable model for delivering common building services through a shared, dynamic infrastructure. By sharing the infrastructure and management costs among a

2009 IEEE International Conference on e-Business Engineering

978-0-7695-3842-6/09 $26.00 © 2009 IEEE

DOI 10.1109/ICEBE.2009.42

255

2009 IEEE International Conference on e-Business Engineering

978-0-7695-3842-6/09 $26.00 © 2009 IEEE

DOI 10.1109/ICEBE.2009.42

255

2009 IEEE International Conference on e-Business Engineering

978-0-7695-3842-6/09 $26.00 © 2009 IEEE

DOI 10.1109/ICEBE.2009.42

255

2009 IEEE International Conference on e-Business Engineering

978-0-7695-3842-6/09 $26.00 © 2009 IEEE

DOI 10.1109/ICEBE.2009.42

255

2009 IEEE International Conference on e-Business Engineering

978-0-7695-3842-6/09 $26.00 © 2009 IEEE

DOI 10.1109/ICEBE.2009.42

255

large group of buildings, significant reduction on capital and operating expenses can be achieved.

This paper proposes a system architecture for smart build-ing control and energy management. Built on the principles of hierarchical composition and domain separation, it allows the system to evolve and captures the savings from improved energy efficiency over the life cycle of a building, while ad-dressing stakeholders’ needs and goals. Section 2 reviews related work and technologies. Section 3 introduces the pro-posed architecture with example use cases. Section 4 de-scribes a prototype implemented with off-the-shelf middle-ware. It also describes a simulation environment that helps demonstrate the effectiveness of the prototype system. Sec-tion 5 summarizes our observations.

II. RELATED WORK AND TECHNOLOGIESOver the past decade numerous systems have been pro-

posed for smart building control. Many of these prior efforts have focused on using a multi-agent approach to achieve the goal of balancing energy consumption and user or occupant comfort [6–13]. The authors in [6] use a combination of dis-tributed artificial intelligence (DAI) and fuzzy-genetic logic to create a behavior-based, multi-agent architecture. In es-sence, they use a machine learning approach to infer occu-pant preferences by tracking user actions such as manually adjusting a thermostat. This research was refined and ex-tended to a deployment of their multi-agent architecture for an intelligent dormitory environment [7] called iDorm. Ex-periments were conducted in iDorm to evaluate the efficacy of learning user preferences for lighting, heating, and cooling using their DAI/fuzzy-genetic embedded agents. We view this work as mainly complementary to our work, since their architecture does not specifically address how to apply the learned occupant preferences to help conserve energy or manage other objectives for the building.

Another multi-agent system for intelligent building control is presented in [8]. In this work, the multi-agent system seeks to satisfy the preferences for an occupant’s room only when the occupant is present in the building. The system attempts to conserve energy by automatically reducing the tempera-ture for an occupant’s room when the occupant is not in the building. This system improves upon iDorm in that it pro-vides some mechanism of energy conservation when there are multiple users and multiple rooms. However, the archi-tecture does not include any mechanism to manage the build-ing’s business objectives or policies. Additionally, this archi-tecture only supports coarse-grained localization (i.e., a building-level, instead of an office-level, localization).

At the conceptual level, the multi-agent research presented in [9–12] draws some similarities to our work. In particular, the authors include in their architecture two key design fea-tures: hierarchical localization via zones and negotiation of stakeholder requirements/preferences on a per zone basis. A zone is any of the shared (hallway), private (office), or logi-cally aggregated (floor) spaces within a building. How-ever, the authors do not propose an actual approach to modeling their zone abstraction, nor do they cite or evaluate any spe-cific business objectives requiring stakeholder negotiation.

We view some aspects of the aforementioned multi-agent architectures complementary to our work, such as automatic learning of user preferences [6–7, 13]. However, we found all the multi-agent architectures we reviewed could benefit from a uniform approach to hierarchical modeling and man-agement of data, policies, and the IT infrastructure. By doing so, value can be realized by all stakeholders, not just the oc-

cupants and/or building owners. In the absence of such a model, multi-agent systems can be very difficult to build and manage, especially for large buildings that can potentially have thousands of concurrent, autonomous agents represent-ing all the occupants and all the building’s objects (rooms, hallways, lights, HVACs, etc.). In addition, most of these projects make the implicit assumption that user preferences and business objectives can always be satisfied simultane-ously. No mechanism is proposed to gracefully degrade oc-cupant comfort when satisfying all of the occupants’ prefer-ences would mean violating the building’s business objec-tives. In addition, while we certainly would like to acknowl-edge many of the early efforts related to intelligent environ-ments and context-aware computing, we point out that these efforts focused on the enabling technologies to provide building automation, occupant productivity, and environment usability [14–20]. In contrast, the focus of our work is on designing an architecture that provides hierarchical composi-tion and domain separation, with the goal of enabling the building control and energy management system to improve energy efficiency, while considering all stakeholders’ objec-tives.

Many of the technologies envisioned for enabling more advanced capabilities within intelligent buildings have ma-tured in recent years. For example passive radio frequency identification (RFID), which can be used for asset tracking and coarse-grain localization, is no longer a highly special-ized embedded technology. The current generation of RFID readers can be used as general purpose computing and con-trol platforms, which support PC-class features, including multiple network, I/O, and application programming inter-faces [21]. Similarly, the programming tools and platform features for wireless sensor network (WSN) technology have improved, and now WSN technology is being evaluated for intelligent light and HVAC control [22–24], as well as for large scale commercial applications [25]. Another important emerging technology is the intelligent meter, which was first introduced as a method to reduce billing cost for service pro-viders by providing an electronic means to read meters, in lieu of the manual approach. Since their first introduction, intelligent meters have evolved and are now being used for supporting responsiveness to demand by providing real-time pricing to customers, thereby allowing customers to receive price incentives to shift loads in response to service provider needs. Several approaches to demand response (DR) using intelligent meters have been proposed recently [26–28] and commercial vendors have begun pilots to test intelligent me-ter technology in the field [29–33].

III. DESIGN OF A SMART BUILDING CONTROL SYSTEMIn this section, we describe several typical use cases a

smart building deployment may encounter. We outline the design principles for a high-level system architecture for smart building control system before presenting its details.

A. Use CasesAs with the adoption of any new technology, the deploy-

ment and rollout of smart building control system is likely to be progressive in nature with the business imperative that return on investment be realized at intermediate checkpoints. Here we outline several use cases that are representative of the distinct phases that a deployment of a smart building system may involve.

256256256256256

• Energy consumption visibilityThis is the simplest use case of a smart building system.

Without any automation and closed-loop control, a lot of savings can be achieved simply by making visible the con-sumption patterns, both current and historical, to various stakeholders involved.

This typically involves instrumenting various systems in a building with sensors or meters. Important information such as the operational status, current energy consumption, current emission, historical trends, etc, can be gleaned and visualized on dashboards. When applied at a coarse level, such informa-tion gives building owners and operators the ability to make informed decision about how to optimize the building opera-tion in terms of energy efficiency. When applied at a fine grain of, for example, individual offices in a commercial building, the energy usage patterns of office occupants can be presented through a portal interface to promote awareness among users and to encourage energy efficient practices.

• Integrated building operationIn this stage, various building systems are integrated so

that information can be exchanged and closed loop controls can be implemented. For example, in a commercial building, the security system uses badge-in and badge-out information to calculate the current occupancy level of the building. In an integrated building system, this occupancy information is then used by the HVAC control system to determine the op-timal amount of cooling or heating that is needed at the building level. It can also be used by the elevator control system to adjust the number of active elevators to balance the wait time and energy consumption.

• Demand responseEnergy consumption on the grid peaks and troughs in

daily, weekly, and seasonal cycles. As transmission facilities must be built to handle the peak load of demand, much of their capacity is wasted during non-peak hours. An important aspect of the intelligent grid is its ability to smooth out the peak of energy consumption and thus improve the overall capacity utilization. This effectively prolongs the useful life-span of existing transmission lines and reduces the need for costly new infrastructure. It also allows the grid to better exploit renewable energy sources that are intermittent in na-ture, such as wind and solar.

One common mechanism is to elicit demand elasticity using economic means such as dynamical pricing. By adjust-ing the price of energy dynamically according to current load and making the information available to consumers such as building operators, utilities can reduce the peak demand of energy by incentivizing customers to shift non-essential en-ergy consuming activities into low-demand time periods.

In order to participate in this system, a smart building con-trol system needs to be able to receive real-time energy pric-ing information. Online analytics use the price information along with the current statuses of various building systems to institute and adjust building-wide energy usage policies. For example, when the total energy cost (energy consumption times unit price) is higher than a certain threshold, lighting level in the corridors may be reduced.

• Occupant-aware building control While reducing energy consumption and improving over-

all efficiency are important aspects of realizing the return on investment of a smart building control system, one should not lose track of a building’s business objective, for example, the occupants’ productivity for commercial buildings. It is known that ambient temperature has an effect on productiv-

ity: higher temperature tends to help improve performance on tasks that require hand-eye coordination, and lower tem-perature tends to favor tasks performed by knowledge work-ers [19].

A highly advanced smart building control system consid-ers users as part of the system. It uses the occupants’ per-sonal environmental preferences, such as lighting level, tem-perature, etc, and other information, such as presence and real-time location, to perform fine-grained control and actua-tion of building systems so that energy saving can be accom-plished with the minimal adverse impact on workers’ produc-tivity and satisfaction.

B. Architectural Design PrinciplesWe have designed a high-level architecture for smart

building control to accommodate the different deployment stages and related use cases described above. The architec-ture supports the following three main design principles.

• Hierarchical sense and respondHierarchical sense and respond allows for building man-

agement and optimization at different level of space aggre-gates (e.g. room, floor, building, grid, etc.), each with differ-ent usage patterns and governing policies. The hierarchical nature of the system architecture also allow complex behav-iors to be created through composition from simpler ones, making the overall system more adaptive and affordable.

• Reference semantic modelA core component of the architecture is a reference seman-

tic model that facilitates the exchange of information among the various building subsystems. Reference Semantic Models (RSMs) have been deployed in production environments to connect a variety of functions throughout an enterprise, in-cluding measurements, planning/scheduling, and life cycle management. In the case of smart buildings, the RSM may provide a framework for developing and implementing smart-building related industry standards.

• Cloud delivery of common serviceAnother important aspect of the architecture is to mini-

mize the cost of IT over the lifecycle of a building. From that perspective, it makes sense to support delivering and con-suming common building management services based on a subscription/usage based model over the cloud. In addition to the data management related challenges associated with multi-tenancy support, it is important to assure essential building operations can function under network failures and without noticeable latency while allowing the services to be tailored for building-specific needs.C. High Level System Architecture

Based on the design principles, we present the system ar-chitecture in Figure 1. There are five major domains, each containing a related set of services or functions.

• Physical System DomainThis domain contains the interface services to various

building systems, for example, Heating Ventilation Air Con-ditioning (HVAC) system, lighting control system, building fire and security system, and real time location system for personnel and equipment tracking.

These interface services are typically data adapters or con-nectors. In order for these systems to be able to communicate to each other, it is important that they rely on a common in-formation and operational model. The reference semantic model plays an important role in achieving this goal. Related industry standards should be harmonized in the reference

257257257257257

semantic model and the adapters translate custom protocols/data formats/tags into RSM compliant ones.

These adapters are usually linked to a local high-speed connection and use industry standard protocols, such as, OLE for Process Control (OPC), Modbus, BACnet, Lon-Works, etc.

• System Integration Domain The system integration domain provides physical-level

integration among the different building systems and other related services. The system integration interacts with the interface adapters via local connections. Conforming to the RSM, data in this domain are in an interchangeable format. Some of the common services include data archiving, event correlation, integration and abstraction of multiple systems, etc.

The information flowing in this domain usually takes the form of events. They can be signals, measures, and com-mands to and from the subsystems. Software engineering techniques such as event-driven architecture and stream processing play a significant role in the domain. Coupled with the RSM, they provide a reusable framework for con-structing distributed sensor event processing application.

Time-dependent middleware, for example, Real-Time JMS, is used by this domain to provide low-latency connec-tivity among software components. This time-dependent middleware joins the enterprise service bus to provide the necessary inter-domain connectivity for information ex-change between the system integration domain and other higher-level domains.

• Process Integration DomainThe next level up in the stack is the process integration

domain. The main purpose of this domain is to provide proc-ess orchestration and automation. It is built around an enter-prise service bus that connects various software components throughout the smart building control system together. Serv-ice oriented architecture, an industry-proven software engi-neering approach, allows the integrated system components, such as, correlated events, abstract building services, and historical data, to be choreographed to create reusable build-ing management processes.

• Business Integration DomainThis is the highest-level domain in the architecture. It is

the end-user-facing layer. Here the target audience is the business users, who are interested in knowing how the build-ing is performing, how its performance can be optimized, and furthermore what policies or directives are needed in order to make the improvement.

Visualization techniques such as bulletin board, dash-board, and simulation, are used to present the current opera-tional status. Instead of programming tools, business intelli-gence tools, such as offline data analysis, online analytics, and business rules, are used to provide high-level abstrac-tions for business users.

• External Input DomainThe external input domain allows a smart building to be

integrated into bigger systems, for example, a campus of buildings, smart grids, smart cities, etc. Like the physical system domain, this domain mainly contains interface adapter services that connect to various external data sources or information feeds.

This domain is also connected to the enterprise service bus to allow the external information to be consumed by the process integration domain and the business integration do-main. It gives the smart building control system situational awareness of a much boarder scope. For example, the real-time energy price information and the weather information allow the business rules to make informed energy consump-tion policies, which affect the building management proc-esses.

IV. PROTOTYPE IMPLEMENTATIONWe have implemented a prototype system as a proof-of-

concept for the proposed smart building control system ar-chitecture.

A. Scenario DescriptionWe consider a hypothetical commercial building with mul-

tiple offices, which are occupied by employees of Company XYZ. Each office has a controller that controls the room’s lighting level and the cooling/heating set points. To accom-modate an increasingly mobile work force, Company XYZ has designated this building as one of several sites for use by its mobile workers. Mobile workers do not have pre-assigned offices. On a typically day, a mobile worker finds the closest work site based on the location of the client project he is

Smart Building Control System

System Integration

Process Integration

Business Integration

High speed Data Archiving

System Integration

Data Correlation

Resource Optimization

Presentation Services

User Services

Process Automation

Data Warehousing

DashboardBusiness

rulesDecision Support

Business Optimization

Local Connections

Time-dependent Middleware

Enterprise Service Bus

En

terp

rise S

erv

ice B

us

Physical Systems

HVAC Lighting SecurityLocation Service

External Inputs

Weather

GIS

City Control

Utilities

Figure 1. High-level System Architecture for Smart Building Control System

Business EventProcessing Layer

Sensor EventProcessing Layer

Sensor and Actuator Layer

Rule

Building Control System

Building Model

Location Service

Data Capture

Filter

RuleFilter

HVAC SystemReal Time

Location System

Preference Loading

Policy Enforcement

Consumption Calculation

Building Gateway

WBE

Sensor Event Server

RTLS Event Hub

Energy Pricing Information

Figure 2. Software Architecture of the Prototype Implementation of Smart Building Control System

258258258258258

working on. He signs in the building and reserves an avail-able office for the day.

To accommodate these mobile workers’ personal prefer-ences, a database is used to keep a profile for each worker, which contains his preferred lighting level and cooling/heating set points. The system uses a mobile worker’s RFID badge to register his presence in an office. To reduce waste, when there is no worker present in an office, its lighting level is automatically set to the lowest, the cooling set point is raised, and heating set point is lowered; all according to the building’s policy for energy conservation. When the presence of a worker is detected in an office, his personal preferences are automatically applied to the office’s controller, which adjusts the light and sets the cooling/heating to his desired levels.

The controllers send the current statuses of office rooms to an event processing application. The aggregated status in-formation is used to determine the current status of each floor and, in turn, the entire building. A dashboard presents the information to the building operator for situational awareness.

The building also receives real-time energy price informa-tion from the utility. Coupled with the current energy con-sumption rate, business analytics rules calculate the energy expense and determine if energy conservation is needed based on a budget policy. The result of the analytics is a di-rective that either restricts or relaxes the energy consump-tion. The directives are sent to the event processing applica-tion, which enforces them by overriding workers’ prefer-ences with hard limits if necessary.

B. System DescriptionThe prototype is designed according to the proposed sys-

tem architecture for smart building control system. Figure 2 shows the software architecture of the prototype system. A building model is used as the reference semantic model. Hi-erarchical sense and respond is implemented using a combi-nation of flow-based sensor event processing and rule-based business event processing. Due to physical constraints, we use software to simulate the actual sensors and actuators, such as, the building control system, the location system for user tracking. A mathematical model is used to simulate how the building reacts to changes in outdoor temperature and HVAC settings.1) Building model

The prototype system is built around a simple building model, shown in Figure 3. The Room, Floor, and Building classes form a hierarchy that represent the physical relation-ship among these entities. Each of these three classes has a “consumption” attribute that captures the current energy con-

sumption rate. In addition, a room has a “geometry” attribute that represents its shape in 3D space.

The Person class models an individual occupant and his preferences of lighting, cooling, and heating. A person is associated with an RFID tag, modeled as the Tag class, whose real-time position is stored in the “position” attribute.

The Controller class represents the room controller device. Its attributes capture the current lighting level, current set-tings and status of the HVAC, and the current indoor tem-perature. Each room is associated with a controller device.

Finally, the Policy class is used to denote the building-wide energy consumption directive and is associated with the Building class.

As we will describe in the following subsections, the sys-tem integration and business integration domains use the building model as a common reference to facilitate informa-tion exchange among the software components. 2) Sensor and actuator layer (simulated)

In the prototype, we use an interactive web-based applica-tion to simulate the building’s operation. Figure 4 shows the user interface of this simulator. On the central canvas, a building floor map is shown in the background. Colored per-son icons represent mobile workers. Each worker has an RFID badge attached. The lighting level of an office room is visualized as shades of black in the office’s background color. A blue-colored fan icon indicates that the cooling sys-tem is on, with a red one for the heating system.

To run the simulation, an operator uses the mouse pointer to drag the worker icons and move them in and out of the offices.

A separate simulator is used to model and simulate the building’s thermal behavior. Using the HVAC simulator (shown in the right side of Figure 5), a user can set the out-door temperature and switch the heating/cooling system on and off. For each room controller, a separate GUI window (shown in the left side of Figure 5) shows its current status.

Building

• Consumption

Floor

• Consumption

Room

• Consumption• Geometry

Policy

• MaxLighting• MinCooling• MaxHeating

Person

• LightingPref• CoolingPref• HeatingPref

Tag

• PositionController

• LightingLevel• CoolingPoint• HeatingPoint• HVACStatus• Temperature

*

*

1

11

1

*

**

Figure 3. Building Model in UML

Figure 4. Web-based Building Simulator Interface

Figure 5. Room Controller Simulator Interface

259259259259259

The lighting level is shown in the right-most gauge. The cur-rent indoor temperature is shown in the temperature gauge and the curve in the left window shows the temperature his-tory. The two triangles next to the temperature gauge indicate the cooling and heating set points respectively.

A thermal model governs how the room temperature (Ti ) changes in relation to the outdoor temperature (To ) and the cooling/heating status. Let’s consider the case of cooling. When cooling is off, the indoor temperature approaches the outdoor temperature according to an exponential law; the exponent is proportional to the temperature differential (To − Ti ). When Ti is higher than the cooling set point plus a hysteresis factor (set to 1℉ in the prototype), the cooling system is turned on (as indicated by a solid triangle and ver-tical bars in the history graph), which produces cool air (at temperature Tc ). This lowers the indoor temperature ac-cording to another exponential law, whose exponent depends on Ti , To , Tc , and the flow rate of cool air relative to the room size. Due to space limit, we will not discuss the details of the model in this paper. When the indoor temperature drops below the cooling set point minus the hysteresis factor, the cooling system is turned off, and the cycle starts again.

As the differential between outdoor temperature and the cooling set point increases, the duty cycle of the cooling sys-tem increases, resulting in elevated energy consumption. This behavior is accurately modeled by the simulator.3) Sensor event processing layer

The sensor event processing logic is implemented using WebSphere Sensor Events (WSE). WSE is a component-based, distributed event processing platform. It consists of a Java 2 Enterprise Edition (J2EE) based server platform with the ability to manage application logic running on a number of Open Services Gateway Initiative (OSGi) based embed-ded platforms. We model the event processing logic as com-ponents and flow diagrams using a research tool called Dis-tributed Responsive Infrastructure Virtualization Environ-ment (DRIVE) [34]. DRIVE generates runtime artifacts, such as code and configuration script, that are deployed and executed on the WSE and its managed OSGi platforms.

Figure 6 shows the main flow diagram of the sensor event processing logic. The functions of the components are de-scribed below:

• Location mapper. This component receives the raw RFID read events (tag id and position) from the location system and converts them into logically entities (person and room number) using the reference building model.• Preference loader. This component receives the pres-ence of a worker in an office and retrieves his personal preferences from the building model.• Policy enforcer. This component receives building en-ergy usage directives from the high-level analytics (de-

scribed in the following subsection) and applies them to the preferred room settings. The results are sent to the em-bedded controllers (not shown in this diagram).• Energy computer. This component receives status in-formation from the embedded room controllers (not shown in this diagram) and computes a moving average of energy consumption for each room.• Floor computer. This component aggregates the energy consumption at floor level using the building model.• Energy notifier. This component sends the current en-ergy consumption information to the analytics engine (see the following subsection).• UI connector. This component connects to a dashboard that shows the current energy consumption for the building operator (not shown here).

4) Business event processing layerWe use WebSphere Business Events (WBE) to implement

the high-level business rules that make building level energy directives. WBE allows business users to create rules to rec-ognize and react to complex event patterns using a simple natural-language-based UI (see Figure 7).

As described in the previous subsection, the current energy consumption rate is sent by the event processing logic to WBE. Coupled with the current price from utility, the current energy cost is calculated. In the prototype, we use a fixed limit as the budget policy—when the energy cost is over the limit, a cost overrun event is detected (as shown in Figure 7(a)). The cost overrun event triggers an interaction rule (as shown in Figure 7(c)), which issues a building-wide restric-tion directive that reduces the lighting level and raises the allowable cooling set point.

Conversely, when the energy cost is below a threshold, a relaxation directive is issued to increase the lighting level and to lower the allowable cooling set point.

To avoid oscillation, additional temporal filtering is per-formed on the cost event, as shown in Figure 7(b).

C. Exemplar simulationWe show a simulation run as an example of how this pro-

totype system operates. Three office rooms (101, 102, and 103) and three workers (1, 2, and 3) are involved in the simu-lation. Figure 8 shows plots of the following measures: 1) the outdoor temperature, 2) the indoor temperature of each room, 3) the lighting level of each room, 4) the cooling set point of

floorcomputer

floorcomputer

uiconnector

uiconnector

policyenforcer

policyenforcer

prefloader

prefloader

locationmapper

locationmapper

energycomputer

energycomputer

energynotifier

energynotifier

url

Figure 6. Implementation of Sensor Event Processing as Event Flow Dia-gram using DRIVE and WebSphere Sensor Events

(a) A simple condition

(b) A complex event pattern

(c) An interaction (rule)

Figure 7. Implementation of Rule-based Complex Event Processing Logic using WebSphere Business Events

260260260260260

each room, and 5) the total energy consumption. A series of events trigger changes in these values. Long sequences of intervening values between events are removed from the figure for succinctness; and they are indicated by the gray bars.

Here is a chronicle of the events of interest during the simulation, as labeled from A through K in the figure.

(A) The simulation is started with all offices unoccupied. Default settings are applied: lights are turned off and cooling set point is at 78℉. The outdoor temperature is 72℉.

(B) Worker 1 enters office 101. Notice that his preferences are applied there: lighting level is set to 75% and cooling set points is at 65℉.

(C) Worker 1 moves from office 101 to office 102. Notice that his presence is tracked and his preferences are now in effect in office 102.

(D) Worker 2 enters office 101 with preferences for light-ing at 50% and cooling set point at 68℉.

(E) Worker 3 enters office 103 with preferences for light-ing at 90% and cooling set point at 72℉.

(F) The outdoor temperature starts to rise. As a result, the duty cycle of the cooling system increases, and the total en-ergy consumption rises above the simulation energy budget, which is set at 1500W. Restriction directives are issued to lower the lighting levels and to raise the cooling set points.

(G) The outdoor temperature reaches 86℉. The restriction directives have brought the energy consumption back in line with the budget.

(H) The outdoor temperature starts to fall gradually. As a result the duty cycle of the cooling system decreases, and so does the total energy consumption. Relaxation directives are issued when consumption is within budget.

(I) The outdoor temperature reaches 80℉. Notices that the workers’ preferences are partially restored and the building’s total energy consumption is still in line with the budget.

(J) Worker 2 leaves office 101. The lights are turned off and cooling set point is raised to 78℉, thus lowering the energy consumption.

(K) Worker 3 leaves office 103, further lowering energy demand. As a result additional relaxation directives go into effect, further restoring Worker 1’s preferences.

V. CONCLUSION AND FUTURE WORKIn this paper, we have proposed a high-level architecture

for smart building control system. Based on the architecture, we have implemented a proof-of-concept prototype system. The prototype system and simulations have demonstrated that the proposed system architecture provides a holistic ap-proach to smart building control and enables the following key features:

• Layered integration. The system architecture clearly separates the overall smart building control system into different domains, each of which targets a specific audi-ence with appropriate programming model, tools, and run-time support.• Automated response. The system supports the hierar-chical sense and respond model. Control loops are de-ployed at multiple levels and they respond automatically to sensed changes in the lower level. • Policy-driven governance. At the highest-level, the architecture presents the business user a policy-based mechanism to govern the overall building operation. These policies are created using natural-language-like constructs and can be adapted dynamically to the changing operating conditions.• Occupant awareness. By integrating occupants into the overall model, the building’s management processes and policies can take users’ preference into account when ad-justing the system’s operation. This balances the need of energy efficiency and worker productivity.Due to physical limits and constraints, we have not tested

the prototype system on real buildings. The preferences and policies used in the simulation are also simplistic. In the fu-ture, we intend to perform thorough evaluations on the pro-posed system using real devices and quantify the benefits of the approach under more sophisticated control policies. Over a longer time horizon, we would like to investigate the im-plications of delivering building energy management capa-bilities from the cloud as a service. We are particularly inter-ested in the low-latency, event-driven, sense-and-respond nature of the system characteristics that have not been ade-quately addressed by the cloud computing community.

A B C DE F G H I J K

59

68

77

86

59

68

77

86

59

68

77

86

0

1500

3000

Room

102

Room

103

0

50

100

0

50

100

0

50

100

Tota

lE

nerg

yR

oom

101

Outdoor Temperature Room Temperature Cooling Set Point Lighting Level Total Energy Consumption

Figure 8. Example of a Typical Simulation Run: System States over Time

261261261261261

ACKNOWLEDGMENTThis paper is influenced by the findings and architecture

concepts resulted from studies by IBM’s Intelligent Building community. It has also benefited from the architecture pat-terns supported by IBM’s Industry Solution Frameworks including the Integrated Information Framework (IIF) and the Sensor and Actuator Solutions. We thank Maria Ebling and Steve De Gennaro for their continuous encouragement and support.

REFERENCES[1] Transforming the Market: Energy Efficiency in Buildings,

World Business Council for Sustainable Development (WBCSD), 2009.

[2] Buildings Energy Data Book 2007, U.S. Department of En-ergy.

[3] E.S. Lee, G.D. Hughes, R.D. Clear, L.L. Fernandes, S. Kilic-cote, M. Piette, F.M. Rubinstein, S.E. Selkowitz, Daylighting the New York Times Headquarters Building, Final Report: Commissioning Daylighting Systems and Estimation of De-mand Response. Lawrence Berkeley National Laboratory, Berkeley, CA.

[4] IPCC Fourth Assessment Report: Climate Change 2007: Miti-gation of Climate Change.

[5] S. Darby, The Effectiveness of Feedback on Energy Consump-tion, Environmental Change Institute, University of Oxford, 2006.

[6] V. Callaghan, G. Clarke, M. Colley, and H. Hagras, “A soft-computing distributed artificial intelligence architecture for intelligent buildings,” Journal of Studies in Fuzziness and Soft Computing on Soft Computing Agents, Physica-Verlag-Springer, July 2002.

[7] H. Hagras, V. Callaghan, M. Colley, G. Clarke, A. Pounds-Cornish, and H. Duman, “Creating an ambient intelligence environment using embedded agents,” Intelligent Systems, vol. 19, pp. 12–20, 2004.

[8] P. Davidssona and M. Boman, “Distributed Monitoring and Control of Office Buildings by Embedded Agents,” Informa-tion Sciences. Vol. 171, pp. 293-307, 2005.

[9] D. Booy, K. Liu, B. Qiao, and C. Guy, “A semiotic multi-agent system for intelligent building control,” In Proc. of the 1st International Conference on Ambient Media and Systems, Quebec, Canada, February, 2008.

[10] K. Liu, C. Lin, and B. Qiao, “A multi-agent system for intelli-gent pervasive spaces,” IEEE/SOLI International Conference on Service Operations and Logistics, and Informatics, Vol. 1, pp. 1005-1010, October, 2008.

[11] B. Qiao, K. Liu, C. Guy, “A Multi-Agent System for Building Control,” IAT '06: Proc. of the IEEE/WIC/ACM International Conference on Intelligent Agent Technology, pp. 653–659. December, 2006.

[12] C.Y. Yong, B. Qiao, D.J. Wilson, M. Wu, D. Clements-Croome, K. Liu, R. Egan, C.G. Guy, “Coordinated manage-ment of intelligent pervasive spaces,” 5th IEEE Int’l Confer-ence on Industrial Informatics. Vol 1, pp. 529–534. June, 2007.

[13] H. Hagras, I. Packharn, Y. Vanderstockt, N. McNulty, A. Vad-her, F. Doctor. An intelligent agent based approach for energy management in commercial buildings. IEEE 16th International Conference on Fuzzy Systems, pp. 156–62, 2008.

[14] M. Coen, “Design Principles for Intelligent Environments,” Proc. 15th Nat’l Conf. Artificial Intelligence (AAAI 98), AAAI Press, pp. 547–554, 1998.

[15] G. Abowd et al., “Context-Aware Computing,” IEEE Pervasive Computing, vol. 1, no. 3, pp. 22–23, July–Sept. 2002.

[16] J. Lai, A. Levas, P. Chou, C. Pinhanez, M. Viveros, “BlueSpace: Personalizing Workspace through Awareness and Adaptability,” ACM, International Journal of Human Com-puter Studies, 2002.

[17] S. Yoshihama, P. Chou, D. Wong, “Managing Behavior in In-telligent Environments,” Proc. of IEEE International Confer-ence on Pervasive Computing and Communications, 2003.

[18] A. Sherwin, Internet Home Offers a Life of Virtual Luxury, The Times, p. 10, 3 Nov. 1999.

[19] W.J. Fish, A. Rosendfeld, “Estimates of Improved Productivity and Health form Better Indoor Environments,” Indoor Air, 7: 158–172, 1997.

[20] H-Y. Huang, J-Y. Yen, S-L. Chen, and F-C. Ou, “Development of an intelligent energy management network for building automation,” IEEE Transactions on Automation Science and Engineering, Vol. 1, No. 1, July 2004.

[21] Intermec Inc, http://www.intermec.com.[22] V. Singhvi, A. Krause, C. Guestrin, J. H. Garrett, and H.S.

Matthews, “Intelligent light control using sensor networks,” In Proc. of the 3rd International Conference on Embedded Net-worked Sensor Systems, pp. 218–229, November 2005.

[23] M. Gauger, D. Minder, P. J. Marrón, A. Wacker, and A. Lachenmann, “Prototyping sensor-actuator networks for home automation,” In Proc. of the Workshop on Real-World Wireless Sensor Networks, pp. 56–60, April 2008.

[24] N. Ota, S. Ahrens, A. Redfern, P. Wright, X. Yang, “An application-driven architecture for residential energy manage-ment with wireless sensor networks,” In Proc. of IEEE Interna-tional Conference on Mobile Adhoc and Sensor Systems, pp. 639–644, October 2006.

[25] J. M. Reason and R. Crepaldi. “Ambient intelligence for freight railroads,” IBM Journal on Research and Development, Vol. 53 No. 3, Paper 6, 2009.

[26] S. Cherian and R. Ambrosio, “Towards realizing the GridWise Vision: Integrating the operations and behavior of dispersed energy devices, consumers, and market,” In Proc. of IEEE Power Systems Conference and Exposition, Vol. 1, pp. 1–6, October 2004.

[27] M. LeMay, R. Nelli, G. Gross, and C. A. Gunter, “An inte-grated architecture for demand response communications and control,” 41st Annual Hawaii International Conference on System Sciences, pp. 1407–16, 2008.

[28] Q.B. Dam, S. Mohagheghi, and J. Stoupis, “Intelligent demand response scheme for customer side load management,” IEEE Energy 2030 Conference, pp. 1–7, November, 2008.

[29] S. Borenstein, M. Jaske, and A. Rosenfeld, “Dynamic Pricing, Advanced Metering, and Demand Response in Electricity Markets,” Center for the Study of Energy Markets., http://repositories.cdlib.org/ucei/csem/CSEMWP-105 , Octo-ber 31, 2002.

[30] M L. Wild, “A Little Give and Take on Electricity,” New York Times, April 29, 2009.

[31] M. Levy, “U.S. electric companies offer 'smart' power meters,” New York Times, May 5, 2008.

[32] J. St. John, GE, “Silver Spring Land ComEd Smart Meter Pi-lot”, http://www.greentechmedia.com/articles/read/ge-silver-spring-land-comed-smart-meter-pilot, June 9, 2009.

[33] K. Fehrenbacher, “Baltimore Utility Rolling Out 2M Smart Meters, Could Save $2.6B,” http://earth2tech.com/2009/07/14/baltimore-utility-rolling-out-2m-smart-meters-could-save-2-6b, July 14, 2009.

[34] H. Chen, P. Chou, N. Cohen, S. Duri, C. Jung, “DRIVE: A tool for developing, deploying, and managing distributed sensor and actuator applications,” in IBM Systems Journal, Vol 47, No 2, 2008.

262262262262262