Abstract— This paper presents an architectural model that

can be used in an intelligent building to reduce the operating

and maintenance costs and to ensure a higher comfort for the

residents. The SOA framework was built during the FCINT

project [1] (Ontology-based Service Composition Framework

for Syndicating Building Intelligence). In this framework the

most important component is the SBC (Smart Building

Controller) which interact with physical devices through

software services and allows users to define schedules and

policies.

I. INTRODUCTION

The results presented in this paper were obtained in the FCINT project [1] (Ontology-based Service Composition Framework for Syndicating Building Intelligence), a project which aims to provide a service-oriented approach to control and manage building facilities via intelligent controllers.

Saving energy is one of the most important aspects when we discuss about intelligent building and the starting point for a large number of projects which tried to build a robust and reliable system. These projects addressed various aspects of home applications and control, involving different technologies and having different objectives, like learning from data to support consumption, building tiered architectures, leveraging a large number of devices, assuring computing processors to support smart home applications.

Siemens Smart Home Solution [2] addresses comfort, security, energy (HVAC and lighting), healthcare, communication, and entertainment, eDIANA [3] proposes for increasing energy efficiency an embedded technology, E3Soho project [4] aims to bring a significant reduction energy consumption by providing tenants with feedback on consumption and offering personalized advices for improving their energy efficiency, iSpace [5] proposes an intelligent dormitory, BeyWatch [6] aims to reduce energy consumption using a user-centered solutions, Hydra project [7] proposed a service-oriented network to support smart home applications, Microsoft (Microsoft Future Home) [8] uses a large number of technologies to enhance daily living, SOFIA project [9] proposed a smart home that outlines several generations of smart homes. Also a number of projects were developed by universities. Among them: Arizona State University [10], Duke University [11], Iowa State University [12] and Washington State University [13].

*Research supported by FCINT project (www.fcint.ro).

Chera C., is with the Computer Science Department, University

Politehnica of Bucharest, Splaiul Independentei 313, 060042, Bucharest (e-

mail: catalin.chera@cs.pub.ro).

Petrescu S., is with the Computer Science Department, University

Politehnica of Bucharest, Splaiul Independentei 313, 060042, Bucharest (e-

mail: bspetrescu@gmail.com).

This paper is structured as follows: Section II illustrates the system overview. Section III describes the main energy related components as schedules and policies. Section IV presents our first results and section V the conclusions.

II. SYSTEM OVERVIEW

Form the beginning the FCINT project has been thought to achieve a general framework for the development of specific applications, depending on user demands, for intelligent building management.

During the development phases the proposed architecture was designed based on the basic principles of Service Oriented Architectures and we managed to build a powerful architecture (Fig. 1) onto which new and interesting applications can be subsequently developed.

Figure 1. The FCINT architecture

The architecture is split into two main parts: one that is designed to take in account the client side and one that is designed for the portal side.

The client side will assure, through the device control web service layer, the connection of devices from the hardware layer to the system. Also, it offers to the users the possibility to configure the full system and to visualize the system parameters.

The portal side offers the dynamical part of the architecture, with the possibility to integrate other applications within the current application or to export some information that can be used in other types of software packages. It provides a simulation package that can be used directly into the application or can offer some valuable information during the testing phase. The portal, through the Environment Manager, gives the user a gateway to his application which can be anywhere on the Internet.

Saving Energy in Intelligent Buildings with a SOA Framework*

Chera Catalin and Petrescu Serban

2013 2nd International Conference on Systems and Computer Science (ICSCS)Villeneuve d'Ascq, France, August 26-27, 2013

978-1-4799-2022-8/13/$31.00 ©2013 IEEE 133

All these components provide to the user a powerful tool that can be used to obtain a significant reduction in the operating and maintenance costs of a building, or a part of it, while offering improved comfort for residents.

The FCINT system using Smart Building Controller (SBC) records and stores the values of all the parameters of devices that make up an environment. These values can then be used for various functions, such as billing or log displaying the operating status of the devices.

An analysis module allows comparative display of one or more parameters, aiming for monitoring their simultaneous evolution in time. In this way, you can for example check the correct functioning of some policies or, when the system monitors the atmospheric parameters, you can analyze the energy efficiency of the system.

III. ENERGY RELATED MAIN COMPONENTS

A. Schedules

One of the features of the web application is the ability to set operating timetables (schedules) for devices. A schedule can define actions, which will be performed at a specific time. They allow the definition of time slots (available dates between which the schedule is valid) and hours for automatic actions on devices. Each device can have an individual schedule associated to it, this schedule being saved in SBC and loaded into an editor. We can create, delete or edit a schedule. The schedules are charged at demand on the Environment Manager. When we choose to create a new schedule, the SBC loads a template (an empty schedule) that can be filled in with the desired information about the device behavior in time.

We can create schedules for each device, or we can create schedules for groups of devices. The schedule model is based on the BACnet Schedule Object [14].

Two types of schedules can be created:

• General schedule – a schedule containing only definitions for intervals, not for what actions they have attached.

• Applied schedule - is an extension of the General schedule, which contains definitions for extra slots defined actions.

Usage scenario: If a user wishes to create a schedule for two separate devices that cannot be grouped together but have the same opening hours, you will first need to create a general schedule with the desired time intervals. After being created, the general schedule will be saved as an applied schedule in the instance of each device. Then you will only need to edit the individual actions for the two schedules and save them to be executed by the SBC. The two devices will have the same operating timetables, but each will have a set of custom actions. In this way we avoid the slot time duplication for devices that must operate synchronously, but cannot be grouped.

Planning policies in the Web application can be achieved through the SBC and consists of attaching a functioning program to a policy.

B. Policies

The Policy Editor was designed in order to permit the editing and management of control policies for a Smart Building Controller. These policies can be applied to devices and services installed into the system (building, office, etc.). Generally, the Policy Editor is used after the system configuration is finished and possibly after some schedules have been implemented.

Although we can define schedules which can be seen as a simple form of temporal policy, when we speak about policies we refer to the broad notion that defines a set of rules for a building control. We can meet the situation where the user wants to act only at certain times on the devices, situation where the schedules are sufficient. But there are situations when the user wants to apply a more complex logic in the control system. The SBC provides all the mechanisms that can accomplish such type of desire.

In order to assure an easier and more flexible way to define, manage and execute the policies, some simplifications of the building control concept have been made:

• Starting from the premise that the user doesn’t have programming skills in order to implement the desired behavior, and that it is much easier to write a set of rules which SBC will execute in a sequence, a policy is built as a set of rules which form part of all the control program.

• Each policy can refer to a particular aspect of the building operation, providing system modularity. We can have a policy for air condition, lights, heating, ventilation etc.

• Each rule has a fixed set of fields. These fields will be filled in with a rule editor. The user can think to the work schedule in terms of rules.

• Every rule can contain a number of expressions. The main types of the expressions are: for reading values from devices and for reading values from web services (rules-expressions); to act directly on devices, group of devices, locations, web services (actions-expressions). These are defined by the FCINT convention call, but other types of expressions can be used to help in the construction of the main expressions.

This approach has an important advantage. Splitting the policy in rules allows the user to configure the frequency with which the SBC checks the condition, depending on the priority. Thus the performance of the whole system is increased by the reduction of the CPU occupancy and the SBC can give priority in the main loop to other tasks.

The policy execution mechanism was designed as an event-driven architecture (EDA). The events arrive to the SBC from the external entities and, based on the control

134

logic defined for each type of event by the user, policies and rules are triggered.

The execution of a rule can be isolated from another rule execution, but it is also possible to have communication between rules based on a “facts memory”. This communication gives the possibility to read, delete, write or question the existence of facts in the facts memory, which help the user to define more complex execution logic, allowing the implementation of finite state machines algorithms (FSM), if required.

Thus, the user can define two types of rules:

• Continuous rules that are executed in the form IF ... THEN ...ELSE periodically by the SBC (Fig.8).

• Rules triggered by a specific event type, which may target in IF ... THEN ... ELSE clause the event instance (Fig 9). This allows the composition of services running in the service oriented architecture of the SBC and which send events to the SBC based on policies and rules triggered by those events. In this case can be used the memory of facts, offering unlimited possibilities to define policies for a given scenario.

In policy “M001” defined in Fig. 2, we have one rule with the following clauses: Interval, On, If, Then, the Else clause being empty. Rules clauses: the field "Interval" indicates the time in milliseconds between two successive evaluations of the rule condition, the “On” tell us if the rule is triggered by an event or not (continuous in this last case), the “IF" describes the activation condition of the rule (e.g. for this rule the condition is activated when all 4 windows are closed); “Then” describes what happens when the condition is true: e.g. when all 4 windows are closed, check a new condition, which shows that policies can contain nested checks: the new condition is to check the outside temperature, the room temperature, and the state of air conditioning; if the outside temperature is below 17 degrees and the inside temperature is less than 22 degrees, and the air conditioning is off, then turns on the air conditioning with 30 degrees setpoint.

Figure 2. Policy example in the Environment Manager

The XML version of this policy is:

<?xml version="1.0"?>

<policy name="M001"> -<rule name="Rule00"

runEveryMs="30000">

<on><![CDATA[true]]></on>

<if><![CDATA[[[Windows.Window01]].bool==false &&

[[Windows.Window02]].bool==false &&

[[Windows.Window03]].bool==false &&

[[Windows.Window04]].bool==false]]></if>

<then><![CDATA[if(([[WiFI_outside.Temperature]].double

<=17) && ([[WIFInode1.Temperature]].double<22) &&

([[AC1.state]].double==0))

[[AC1.SetMultipleDeviceState("state,mode,temperature","1

~3~30")]]; ;]]></then>

<else><![CDATA[]]></else>

</rule>

</policy>

C. The billing system

The billing system was introduced in the FCINT project for better management and optimization of energy consumption and associated costs. Energy rating and billing are performed for each device or for a set of selected devices for a time period. The time periods can be defined even for the future (if there are schedules defined for devices running in the anticipated period). SBC generates bills which are accessible through the Web interface (Environment Manager)(see Fig. 3).

Figure 3. Environment Manager billing section

The invoices are saved on the disk in two formats: XML (Web View) (see Fig. 6) and PDF (see Fig. 7).

D. Evolution analysis of the related parameters

Graphical mode is the most intuitive tool through which you can quickly analyze the evolution of correlated time-varying quantities. Therefore, for an effective analysis of the parameters of the devices connected to the system, the FCINT was decided to implement a combined graphical view for the values of the parameters in the Environment Manager (see Fig. 4).

In the implemented correlated analysis, the device parameters are of two categories: primary and secondary. Primary parameters are those that can be represented in an analogous manner, such as temperature, power consumption, energy consumption, etc.. Secondary parameters are digital controls that can be represented in a digital manner, binary

135

type (1 and 0), where the value 1 represents the mask for ON, OPEN, TRUE, YES, and the value 0 represents the mask for OFF, CLOSE, FALSE, NO.

Figure 4. The parameters evolution graphical comparison

The main objective of the analysis is related to monitoring the evolution of one or maximum two main parameters for changes in status of one or more secondary parameters. Therefore, each principal parameter will be displayed on a separate chart and all secondary parameters will be represented on the same chart.

The developed tool proved useful in many cases such as tracking air conditioning that start with values different by the desired one, tracking energy consumption of air conditioning set by a policy, as to maintain the internal temperature in a range, temperature evolution in a given period of time and also often the evolution of energy consumption for controlling the room temperature.

IV. RESULTS

We present an operational scenario and we will pass it through 3 functional models to highlight the advantages of using the proposed system.

In an office (Fig. 10) there are: one computer (400W), one air conditioning device (1000W), one lamp (60W), one presence sensor, one light sensor, one temperature sensor and one window sensor.

In a regular day, the office owner has the following program: arrives at work at 9:00, at 12:00 goes to eat, at 13:00 comes back from lunch and at 19:00 leaves the office and goes home. Exceptions are: on Wednesday he leaves the office at 18:30 (without action on the devices inside the office) and on Thursday between 15:00 and 16:00 he goes to his lawyer.

For 3 weeks, during the summer, we monitored the energy consumption into the office, applying the following models:

• in the first week the system only recorded the consumptions based on the actions performed by the user;

• in the second week, the user defined some schedules for devices. He create a schedule for air conditioning to start at 9:00 and stop at 12:00 and again to start at 13:00 and stop at 19:00. For the light he create a schedule to switch on at 9:00 and off to 10:00 and then switch on at 18:00 and off at 19:00. Also for the computer he created a schedule to start at 9:00 and stop at 19:00.

• in the third week, the user also created policies. The lamp is automatically switched off if the light sensor detects a value higher than a threshold or the presence sensor doesn’t detect a person in the office. The lamp is switched on if someone enters in the office or the light inside the office is under a threshold. The air conditioning is started if the temperature into the office is higher than 25 degrees and stopped if it is under this value or when the window is open. The computer is stopped if the person leaves the office for more than 10 minutes. Between 19:00 and 9:00, if the office is empty, the lamp, the air conditioning and the computer are automatically stopped.

In the first week, Wednesday night the lamp, the air

conditioning and the computer remain open all the night

because there is no system to stop them.

TABLE I. FIRST WEEK ENERGY CONSUMPTION

Device Mon Tue Wed Thu Fri

AC 9.1kWh 9.2kWh 23.1kWh 7.9kWh 9.1kWh

Lamp 122Wh 121Wh 0.98kWh 122Wh 120Wh

Computer 3.9kWh 4.1kWh 9.7kWh 4.2kWh 4.1kWh

TABLE II. SECOND WEEK ENERGY CONSUMPTION

Device Mon Tue Wed Thu Fri

AC 9kWh 9kWh 9kWh 9kWh 9kWh

Lamp 120Wh 120Wh 120Wh 120Wh 120Wh

Computer 4kWh 4kWh 4kWh 4kWh 4kWh

TABLE III. THIRD WEEK ENERGY CONSUMPTION

Device Mon Tue Wed Thu Fri

AC 6.5kWh 6.3kWh 6kWh 5.5kWh 6.6kWh

Lamp 40Wh 41Wh 30Wh 40Wh 40Wh

Computer 3.6kWh 3.6kWh 3.4kWh 3.2kWh 3.6kWh

The total energy consumption in the first week was 85.86 kWh. In the second week the total energy consumption was 65.6 kWh, which means that we have a reduction of 23.59%. In the third week the total energy consumption was 48.49 kWh, which means that we have a reduction from the first week of 43.52% and a reduction of 26.08% from the second week.

136

Figure 5. The energy consumption variation

The results show the benefits of implementing such type of system if we want to reduce the costs of building operation. If we consider an entire building with a large number of offices we can see that over the time the costs reduction becomes very important.

V. CONCLUSION

This paper presents a model that can be used to save

energy in intelligent buildings using a SOA framework.

Based on the first results obtained by using this system, we

may conclude that the system fully demonstrates its

efficiency and that this type of model could be applied in

other intelligent buildings for operating cost reduction.

This model can be applied as well to a house, as to a small office or to an entire building,

ACKNOWLEDGMENT

The research presented in this paper was supported by the

EU POS-CCE project FCINT No. 181/18.06.2010.

REFERENCES

[1] FCINT project. Available at: www.fcint.ro

[2] Siemens. Online, available at:

http://www.siemens.com/innovation/en/publikationen/publications_p

of/pof_fall_2008/gebaeude/vernetzung.htm.

[3] eDIANA Project, Website: http://www.artemis-ediana.eu.

[4] E3Soho Project, Website: http://www.e3soho.eu/.

[5] iSpace Project, Website:

http://cswww.essex.ac.uk/iieg/idorm2/index.htm.

[6] BeyWatch Project, Website: http://www.beywatch.eu/.

[7] The EU HYDRA project, http://www.hydramiddleware.eu/news.php.

[8] Microsoft Future Home. Online, available at:

http://www.youtube.com/watch?v=ODpReoKQVXM

[9] Katasonov A. and Palviainen, M. “Towards Ontology-driven

Development of Applications for Smart Environments”. In: Proc. Intl.

Workshop on the Web of Things at PerCom'10, March 29 - April 2,

2010, Mannheim, Germany.

[10] J. Xu, Y.H. Lee ,W.T. Tsai, W. Li, Young-Sung Son Jun-Hee Park,

Kyung-Duk Moon. "Ontology-Based Smart Home Solution and

Service Composition", ICESS 2009.

[11] Duke University, Smart Home project,

http://smarthome.duke.edu/projects/list.

[12] Iowa State University, Smart Home project. Online, available at:

http://smarthome.cs.iastate.edu/index.html.

[13] Washington State University Smart Home project,

http://ailab.wsu.edu/casas/.

[14] The BacNET Standard specification. Online at: www.ashrae.org

137

Figure 6. Billing web view

Figure 7. PDF billing version

Figure 8 SBC main loops. Policies with continuous rules, executed with

predefined delay

Figure 9 Secondary threads for connected clients to the SBC event queue

Figure 10. The office structure

138