IST SmartOffice

Rodolfo Andre Henriques dos SantosInstituto Superior Tecnico

rodolfo.santos@tecnico.ulisboa.pt

November 2014

Keywords: Service Oriented Architecture, Building Automation, Energy Management, Modular Programming

Abstract: Building automation and energy management systems increase the value of buildings by making them morecomfortable, productive, and energy efficient. However, the hardware and software technologies underlyingactual systems are largely monolithic and incompatible with each other, hampering extensibility and favoringconsumer lock-in. In order to overcome this problem, we propose to create a middleware that abstract theheterogeneity of automation systems and provide sophisticated functionality to applications for intelligentcontrol and energy management. Our solution also exposes services that allows to abstract the numerousprotocols and technical requirements associated with each manufacturer to applications, allowing developersto apply all their effort designing algorithms and innovative techniques that maximize the energy efficiency anduser comfort, without worrying about the technical details of each existing system. The concept is validatedwith the implementation of a service-oriented architecture prototype that enables energy management andintelligent control of IST office rooms.

1 INTRODUCTION

This document addresses the topic of creating anappropriate architecture for intelligent control andenergy management of building offices. Given thecurrent economic and social situation, it is of utmostimportance to focus on systems and technologies thatenable energy efficiency, particularly in large build-ings. In Europe, buildings account for 40% of totalenergy use and 36% of total CO2 emission (EuropeanParliament and Council, 2010), and these values areexpected to grow in the coming years. This aspectresults in a major concern for more energy conser-vation. Large buildings require technologies withsophisticated applications, such as automatic controlof lighting and temperature set-points, as well theneed for the system to learn with the activity of usersinside the building. In addition, these environmentsmust be energy efficient and must simultaneouslyensure the comfort and well being of the occupantsin order to enable them to become more productive.The main hindrance in developing this vision arethe lack of interoperability that automation systemsoffer. Each manufacturer keeps developing theirproprietary specifications and has little motivation toevolve their systems to the emerging trends of com-munication standards (Litvinov and Vuorimaa, 2011).

As well, there is still no solution for the de-velopment of applications for intelligent control andenergy management in a modular way, based onService-Oriented Architecture (SOA), where it is pos-sible to reuse and compose services with the aim ofimplement new functionality. The current solutionsof Building Automation (BA) and Energy Manage-ment (EM) are vertically integrated and do not al-low communication with devices in a standard way,and poorly support their heterogeneity. Re-designingand re-programming BA and EM systems, in orderto change and extend features to support new devicesand functionalities are still too expensive and too slowto achieve. Web Services (WS) and SOA has allowedit, more precisely in Information Technology (IT) sys-tems (Lee et al., 2010), due to several business needs,but not embarked on the automation and energy man-agement domain yet. What really happens is that bothservices and the programmer has to know the detailsand characteristics of the Building Automation Sys-tem (BAS), which causes a massive consumer lockin. Increasingly it is necessary that the IT systemand BAS are integrated in the architecture that sup-ports the business, since the optimization of the en-ergy and the business processes is something that hasto be done in an integrated way.

To illustrate the addressed issue take into accountthe following scenarios:

Scenario 1 consider a daylight-harvesting system,which aims to use daylight to control the amount ofelectric illuminance needed to properly light a space,in order to reduce energy consumption. These sys-tems uses a set of sensors and actuators inside theroom to measure luminance and adjust the lighting ofthe lamps, respectively. In this scenario, it is neces-sary to deal with interoperability of diverse devices,their functionality and technical features, since manyare from different manufacturers and communicationprotocols.

Scenario 2 consider a scheduling system, whichexecute some tasks periodically. This tasks are trig-gered after an event or set of events have occurred.Events can be a time value or a specific event fromthe users activity. In this scenario, it is necessary tounderstand how the scheduling system of each devicetechnology works and map the logic of schedulingwith the operation logic of each device.

Existing solutions to address the requirements ofscenarios 1 and 2 consist of monolithic applicationsthat do not provide modular services, and also donot allow interoperability with other automation tech-nologies used. In addition, most existing solutionsare proprietary and not expose their insights, whichdon’t allow the reusing and extension of its function-ality. This situation is illustrated in Figure 1, whichcompares a monolithic system with a layered archi-tecture (Bastide et al., 2006).

Solutions to this problem are quite complex as isnecessary to realize the systems architecture and ser-vices that the middleware service layer has to offer.Typically, architectures for these systems include ser-vices for energy consumption and services for com-manding devices. Indeed, these service componentsare needed. It is necessary to integrate all context in-formation (e.g. retrieve the state of electrical devices,the energy consumption data, and the user presencedata), to derive control decisions that meet the userpreferences and needs while ensuring the best valuesof energy consumption in the building. Solutions, asdetailed in Related Work, are trying to solve this issueusing service-oriented architectures to provide someinteroperability between different systems. However,they only expose devices as service calls along withthe idiosyncrasies associated with each device. Thereis no semantics on top of these services, such as log-ical services to reuse and extend. The characteristicsof different devices, the different protocols and differ-ent drivers continue to exist, but now at the servicelevel, maintaining the lack of interoperability.

(a)

(b)

Layered System (SOA approach)

System 1

Daylightharvesting

Devices

Building/UsersDataBuilding

Data

System 2

Scheduling

Devices

Users Data

System 3

Automatic Control

Devices

Daylightharvesting Scheduling Automatic

Control

Devices Building/UsersData

Building/Users Data

History

History

Service Layer Middleware

Figure 1: Actual systems vs. SOA approach. (a) Monolithicarchitecture where high level applications are highly depen-dent on the original software design. (b) Layered horizontalsolution that enables technology abstraction, interoperabil-ity, and extensibility.

Herein, we propose a way to build BA applica-tions atop of a modular service layer middleware thatalso abstracts the heterogeneity of BAS. The mid-dleware abstract all systems and low level devicesto BA applications, making less complex to developthese software. This novel approach enables takingadvantage of systems that already exist, orchestratingand reusing the services they offer to implement newfeatures that take into account the needs of the busi-ness. Conceivably in the near future, BAS will enableadding new features without having to redesign theoriginal architecture of the system.

This work analyses the various existing func-tionalities in Building Energy Management System(BEMS) and propose a reference architecture with aset of services collections required in order to createmodular intelligent energy management and automa-tion control applications on top of these services. Atthe end, IST SmartOffice prototype is integrated withthe existing BAS available in IST Taguspark Build-ing.

2 BACKGROUND

This section gives a brief description of some ofthe key terms and technologies addressed, in order toprovide a better reader understanding.

2.1 Building Energy ManagementSystem

A BEMS is a computer-controlled system, whichwhen installed in a building, controls its power sys-tems, including lighting, heating, ventilating andair-conditioning. The basic functions of a BEMSare: monitoring, controlling, and optimizing (Lever-more, 2002) all electrical devices in building. Thefunctional aim of BEMS is to manage the environ-ment within a building, so that energy consumptionperfectly balances with the way of building utilizationand its normal activities. BEMS functionalities ad-dressed in ISO 16484-3 and EN 15232 standards (In-ternational Standard, 2007; European Standard, 2006)are: grouping/zoning; event notification; alarm noti-fication; historical data access; scheduling; and sce-narios. Also according to ISO 16484-7 standard (In-ternational Standard, 2013), a BEMS shall providethe following control features to enable energy per-formance in buildings: heating and cooling control;ventilation and air conditioning control; lighting con-trol; and blind control.

BEMS are dependent on the other two systems:BAS and Energy Management System (EMS) (Bloomand Gohn, 2013).

2.2 Service-Oriented Architecture

The idea of a service-oriented architecture (SOA)refers to a paradigm for the construction and integra-tion of software systems where the primary structur-ing element is the service. In SOA, any subsystem isdescribed by the services it offers (Open Group Stan-dard, 2011). Web Services (WS) are the most com-mon implementation of SOAs. WS consist of mod-ular and independent software applications that canbe executed over the web. These applications usuallyuse XML and SOAP over standard network proto-cols, to implement the communication channels. Or-ganizations that focus their development effort aroundthe creation of services, will realize many benefits,such as, code mobility and reusability, scalability andavailability, and better testing.

2.3 OSGi

Open Services Gateway initiative (OSGi) is a com-ponent framework specification that aims at bringingmodularity to the Java platform. It enables the cre-ation of highly modular and dynamic systems. Thesesystems are highly modular in the sense that OSGi-based applications are composed by multiple inde-pendent modules or components, and the develop-ment, testing, deployment, updating, and manage-ment on each module have minimal or no impacton the overall system. This means that bundles canbe safely added and removed from the frameworkwithout restarting the application process (Hall et al.,2010).

3 RELATED WORK

Smart buildings require integration of variousbuilding automation systems that are usually madeby different manufacturers (International Standard,2013). Most of the manufacturers tend to focus ona specific domain, while others try to comprise all do-mains in one application. The need to integrate sev-eral network technologies and communication proto-cols into applications has forced developers and re-searchers to create service-oriented frameworks oruse existing to accomplish that objective.

Our literature review addressed several technolo-gies that focus on trying to solve different domain is-sues, such as automation field-bus heterogeneity ab-straction, BA services exposition, BAS technology in-dependent integration, and energy management andautomation functionalities providing.

Most of solutions are supported by SOA, thus pro-viding greater extensibility and interoperability withother technologies in an easier way. Systems thatstand out for a higher extensibility and interoperabil-ity are: OPC UA (Leitner and Mahnke, 2006), Home-SOA (Bottaro and France, 2008), LinkSmart (Eisen-hauer et al., 2011), SOCRADES (Cannata et al.,2008), aWESoMe (Stavropoulos et al., 2013) andSEEMPubS (Osello, 2013). These solutions solvesome issues, because they can help development ofBEMS, supporting BA technology integration and ab-straction. As they are based on SOA, it is possi-ble to implement EM and BA functional application-level services over this systems, using a modular ser-vice composition, being that the focus of our architec-ture. The aWESoME and SEEMPubS middleware arethe most similar approaches regarding the architec-ture objectives, as it integrates different layers: hard-ware, services, integration between services and de-

vices layer in order to achieve their interoperability,and application layer to provide the users of the sys-tem a form to manage the devices and the energyconsumption of the building rooms within an user-friendly interface.

Despite all solutions support BA and EM func-tionality, majority have a lack to supporting BEMSfunctionality, which causes a need to implement anew system that integrates all the standard features.Application-level services providing is an importantfeature, that enables extension and development ofBAS applications easily. No solution fulfills all thecharacteristics surveyed. However, they all comple-ment each other, increasingly motivating the creationof a new reference architecture. One aspect that lacksenough, are the system ability to provide BA and EMapplication-level services in order to help the devel-opers to build easily and quickly BEMS sophisticatedapplications.

4 ARCHITECTURE BLUEPRINT

The architecture main goal is to develop a newmiddleware architecture with the purpose of over-come the identified issues, such as interoperabilityand extensibility of BEMS. It is presented a middle-ware architecture vision and its software layers, anda collection of different services that the middlewaremust provide.

To achieve the middleware goals, existing build-ing automation and energy management softwarestandards must be refactored into a modular archi-tecture. OSGi framework can be used to implementsuch architecture, since it has mechanisms that pro-mote modularity and also can afford all requirementsof BEMS. The first step to modularize the application,is to identify its essential structure. This will helpto understand the dependencies and identify interac-tions. From there its possible to define the buildingblocks that constitute the middleware. Finally, witha fully modular and functional middleware it is pos-sible to implement a sophisticated BEMS fully basedon SOA, being also highly functional and extensiblesystem.

4.1 Architecture Overview

This section proposes an architecture for the servicelayer middleware, aiming at flexibility and scalabil-ity, enabling easy development of new applicationsin a modular way. As opposed to other solutions,this architecture is based on the BA and EM stan-dards (International Standard, 2007; European Stan-

dard, 2006), regarding also to the latter paradigmsof software architectures. This platform will cen-tralize all the building control functions, in order toreduce the installation, commissioning, maintenanceand hardware costs. The proposed layered architec-ture is composed by several extensible blocks withwell-defined interfaces that abstract its implementa-tions.

Service Middleware

Applications

Serv

ice

Bus

Management Services

Autonomous Actuation Services

Intelligent Actuation Services

Direct Actuation and Data Access Services

Resources Connectivity

DevicesHistory Data

Building/UsersData

Building/UsersData

ServiceEnabledSystems

Figure 2: Proposed Service Architecture. The Middle-ware consists of several service modules which deal andabstract the specifications of each different BAS technologyand provide functional services for high-level applications,starting from the field level, then building automation, en-ergy management, and intelligent control.

This novel architecture will be very useful, to theextent that at the end we will take advantage of severalkey benefits:

• Abstraction - modular service components will al-low multiple levels of abstraction;

• Fast prototyping - creation and utilization ofexisting services;

• Heterogeneity handling - services will enable in-tegration of devices diversity;

• IT integration - will be possible to create servicesthat integrate automation systems with the IT sys-tems present in the building;

• Lower operational and maintenance costs -there is no more maintenance dependence withsuppliers and manufacturers of equipment andsystems.

As depicted in Figure 2, this architecture is able tomanage and interoperate with several fieldbus tech-nologies and their devices, thus solving the problemof heterogeneity. The system also implements energy

management and intelligent control functionalities onservice layer middleware instead on expensive hard-ware controllers. High-level services, will provide allthe necessary functionality to the fast development ofBEMS applications. The various services presentedare divided into four layers, corresponding to differ-ent types of features. Each layer is a different level ofabstraction, where the lower layer offers services toupper layer, which simultaneously uses the servicesof layer below. Service Bus, will enable interoperabil-ity between service layers, promoting communicationbetween service providers and service consumers.

4.2 Resources Connectivity

Resources connectivity is the service layer respon-sible for manage and communicate with the variousBAS protocols. It also allows the access multipledata models manipulation, such as history databases,building models and users data preferences. In or-der to internal model interact with different proto-cols and BAS technologies, it is necessary to definea common API (Application User Interface) and cre-ate adapters that cope with various and heterogeneousprotocol implementations and adapt them to a specificcommon protocol - the Datapoint Connectivity API,as depicted in Figure 3.

The Resources Connectivity Layer is essential todecouple the internal service API from specific BASprotocols and specifications (like KNX, X10, iLight,Modbus, etc.). The BEMS services contact to a spe-cific BAS technology within the Resources Connec-tivity layer. The clearly defined interface between ourinternal services and the device driver services allowscontrol of different devices via different adapters.Adapters will take care for translation and presenta-tion of specific protocol details to Connectivity APIservice. Protocol Integration can access the differ-ent adapters implementations via OSGi services thatguarantees a clear datapoint abstraction. Then, thedecoupling and generic access to various devices viaOSGi service interfaces is provided.

Datapoint API defines a general design rule tominimize implementation effort in Resources Con-nectivity Layer to be able to flexibly provide and sup-port new adapters on customer/vendor request with-out (or with minimal) changes in internal services.

Resources Connectivity

Protocol 1

Protocol Integration

Protocol 2 Protocol 3 Protocol 4 Protocol N

Adapter 1 Adapter 2 Adapter 3 Adapter 4 Adapter N

Devices Devices History Data

Building/UsersData

External Resources

Datapoint Connectivity API

Figure 3: Resources Connectivity Layer. Figures aboveshow the basic separation of different protocol implementa-tions and the common and unified protocol – the DatapointConnectivity API. The different adapters provide a clear in-terface of devices from different protocols, while ProtocolIntegration layer is intended to join the various adapters ina common communication protocol.

4.3 Service Collections

In Figure 4 are shown the set of services that will pro-vide sophisticated functionality to Applications layer.These services were divided into multiple logical lev-els, taking into account the type of BA and EM func-tionality and the energy-efficient control techniquesaccording to standards (International Standard, 2007;European Standard, 2006).

The Direct Actuation and Data Access ServicesCollection intends to deal with BAS devices com-munication and its abstraction. It is also responsi-ble for the devices history data storage, data query-ing functions, and data fusion and analytics tech-niques. The Autonomous Actuation Services Collec-tion aims to provide some basic functionality actu-ally present in BAS, such as alarms, events, schedul-ing and scenarios. The Management Services Col-lection aims to achieve a better way to manage thebuilding and the BEMS functions, based on availabledata models of information. Finally, Intelligent Actu-ation Services Collection provides energy-efficiencycontrol techniques robustly, given the higher serviceabstraction. These techniques are occupancy-basedcontrol, daylight-harvesting, automated blinds con-trol, Heating, Ventilation, and Air Conditioning sys-tem (HVAC) control, and some learning techniques inorder to take into consideration the users behavior andactivities.

Service Middleware

Applications

Management

Autonomous Actuation

Intelligent Actuation

Direct Actuation and Data Access

OccupancyBasedControl

DaylightHarvesting

AutomaticBlind Control

HVACControl Learning

User ModelManagement

OccupancyFeedback

Management

Building Model

Management

Energy Model

Management

Alarms and Events

Scenarios Management Scheduling

Remote Sensing & Actuation

Meter & Sensor Data Acquisition

History Data Storage

Data Querying

Data Fusion & Analytics

Figure 4: Service collections. The services were divided into multiple logical levels, according to the level of abstraction andalso taking into account the type of BA and EM functionality.

5 IMPLEMENTATON

During the middleware implementation phases wedeveloped an ecosystem of building automation andenergy management services contained in the OSGiFramework. Then we specified the Datapoint Con-nectivity API, that enabled an unified way of commu-nication between different services implementations,and also an abstraction layer to communicate with theheterogeneous environment of automation technolo-gies. Later, we implemented techniques for servicesorchestration and management inside OSGi, and alsothe OSGi services exposition to the Web via ServiceWrappers.

To give an overview of the implemented softwarecomponents, the Figure 5 shows some of the devel-oped bundles inside the OSGi platform, which corre-sponds to the different services and functionalities de-veloped. The software components are grouped into3 types:

1. Core Bundles corresponds to essential softwarethat allows the proper operation mode of theglobal system

2. Adapter Bundles are software components thatadds the communication support with new proto-cols and technologies

3. Service Bundles allow the addition of new func-tionality over services extensibility and composi-tion

The implemented architecture was conceived hav-ing in mind that all the services are exposed usingthe same interface, the Datapoint Connectivity API.Lower level components are service providers and ofhigher level components that are service consumers.

The end-user applications are only service consumersusing the Datapoint Connectivity REST API.

Operating*System

Java*VM

Felix*OSGi

Core%Bundles Adapter%Bundles Service%BundlesDatap

oint*API

RES

T*Wrapp

er

PubS

ub*W

rapp

er

Logg

ing

Prot

ocol*In

teg.

KNX

X10

iLight

Rem

.*Sen

sing

Data*Aqu

isition

Scen

arios

…

Conf.*Files

DB

Figure 5: OSGi Level SW Components Overview. SWcomponents follows the concept of modularity, where eachpiece of software is contained in an OSGi bundle.

6 EVALUATION

In this work, we designed and developed aservice-oriented architecture for BEMS. Since thereis no reference model of a SOA for BEMS, it is notpossible to compare the results of our solution withanother one. Therefore, our evaluation is based onan early software architecture evaluation that consistsin a Scenario-based Software Architecture Evaluationcomplemented by two case-studies:(i) Case-study 1: An empirical evaluation of the im-

plemented prototype: the IST SmartOffice(ii) Case-study 2: The development and evaluation of

energy consumption prediction Services for ISTTaguspark building

6.1 Scenario-based SoftwareArchitecture Evaluation

The analyses of ATAM (Architecture-based Trade-off Analysis Method) (Kazman et al., 2000) architec-tural approaches by applying scenarios and the ensu-ing discussions, surfaced a set of risks, sensitivities,and trade-offs:

Collected Risks1. We are dependent on a component framework

(OSGi). Exists the possibility of the frameworkstop being supported and a lot of functionalitybecome legacy given the new trends and marketneeds

2. Many manufacturers of BAS may not accept thisnew architecture, and may difficult the provisionand support of new features

3. Some specific technologies may have some limi-tations, which can not completely validate the re-quirements. E.g. the X10 protocol does not guar-antee delivery of messages, which the state of de-vice may be inconsistent with the state of the sys-tem

4. Perform the analysis of historical datam in or-der to detect malfunction situations can generatea high rate of false positives.

Collected Sensitivities1. The service performance and scalability depends

on BAS hardware performance2. We are depending on the quality of sensors data,

because may be there are associated rates of errorsand failures.

Collected Trade-offs1. Using the same Datapoint Connectivity API to

implement all system services can simplify the us-ability of the overall system, but also a greatereffort is needed to all services meets all the APIspecification

2. Using more than one API for the different serviceswill simplify the implementation of each service,but it will reduce drastically the usability of thesystem. The user has to know all the APIs speci-fication to interact with the available services.

6.2 Case-study 1: IST SmartOfficePrototype Evaluation

In order to evaluate the solution extensibility and het-erogeneity handling, it was required to develop sev-eral fieldbus adapters to promote different technolo-gies integration in a heterogeneity environment. Thisprotocol integration is supported by the middleware,

through the Protocol Integration Adapter. The BASequipment installed in Taguspark Building enabledthe development of device drivers that interact withmajor automation devices of the building. The mid-dleware usability and functionality towards the devicedrivers implementation could be assessed through thedevelopment of such drivers.

In Figure 6, the infrastructure diagram of ISTbuilding describes all fieldbus technologies evolved,such as KNX, iLight, X10, LIFX, and INOV Meters.

KNX Energy Lab

KNXGateway

TCP/IP

Weather Station

VLAN

KNX N14 Offices

KNXGateway

TCP/IP

Modbus Energy Meters

INOVGateway

TCP/IP

iLight Gateway (EG2)

TCP/IP iLight/CAN Amphitheater

Library

RS232X10 Devices

TCP/IP - RS232Interface

TCP/IP

X10Gateway

X10

WLAN

TCP/IP LIFX Lamps802.11

Figure 6: Fieldbus Infrastructure diagram.

Protocol KNX iLight INOV X10 LIFXFunctionality

Coverage100% 67% 100% 67% 67%

Complexity High High Medium Medium LowNotifications Yes No No No NoIntegration Dificulty

Higher Medium Lower Lower Lower

Table 1: Summary of integrated technologies results. Thetable shows the functionality coverage in the final solu-tion after the integration process, the technology complexityover the developed adapter, the support of notifications andthe difficulty encountered in the integration process.

From the analyses of the functionality cover-age with the various fieldbus technologies integrationwith existing services and we can conclude that our

solution successfully addresses the SOA design prin-ciples of modularity, extensibility and interoperabil-ity. As depicted in Table 1, the majority of the func-tionalities were supported technologies after the inte-gration process, even when some of them have limi-tations and do not support some functionalities by de-fault. The technology complexity and the integrationdifficulty are also compared in order to evaluate thetechnology ability to integrate with others.

Finally, we can prove that existent technologiesand standards needs to be improved in order to copewith SOA requirements by default, easing the integra-tion process with other existing technologies.

6.3 Case-study 2: Energy ConsumptionPrediction Service

This case-study describes the construction and eval-uation of energy consumption prediction services forintelligent buildings based on their heterogeneous oc-cupancy. The IST Taguspark facility is used, wherebuilding occupation based on WiFi network connec-tions are compared with the aim of better predictenergy consumption of the building. We developedthree services using these prediction models: linearregressions, fuzzy systems and neural networks. Withthese new prediction services, becomes possible toperform sensor data queries for future periods.

Prediction models are developed from a historydataset acquired from INOV Energy Meters readings,and also from occupancy estimation data stored in ourHistory Data Storage Service.

Wifi usage information is available from SNMPMIB Agents of the 54 Access Points across the build-ing. For that, we had to develop an additional adapterto integrate SNMP Protocol, using the SNMP4J JavaLibrary, which acquires data periodically from allbuilding network equipment via SNMP protocol. TheFigure 7 shows the relation between Wifi connections(occupancy) and the overall energy consumption ofthe building.

The prediction models and services were devel-oped using MATLAB Software from MathWorks.After the development, we integrated Matlab mod-els into Java using the MATLAB Library Compiler.For linear regressions we used the Multiple LinearRegression. The fuzzy system was developed usingSugeno-type Fuzzy Inference System (FIS) with Sub-tractive Clustering (SC) algorithms. Regarding neuralnetworks, a feedforward backpropagation model wasapplied.

Then, we presents the models simulations and re-spective results, using the following prediction mod-els: linear regressions, fuzzy systems and neural net-

0 500 1000 150020

30

40

50

60

70

80

90

100

110

Occupancy (WiFi connections)

En

erg

y C

on

su

mp

tio

n (

kW

h)

(a)

Figure 7: Scattered plots between building occupancy indi-cators and energy consumption, showing the WiFi connec-tions and energy consumption relation.

works. We used 80% train and 20% test data, theequivalent to 676 samples of 15-min test data, corre-sponding to ≈ 7 days (week-long) energy consump-tion prediction.

The performance of all models is assessed forprecision and recall by computing the Variance Ac-counted For (VAF) and Mean Absolute Error (MAE)indexes over a testing set. The VAF measures the per-centage of variance between the two signals and canbe expressed as:

Definition of consumption baseline – Case-study in a Portuguese University campus

Henrique R. M. L. Pombeiro Intelligent Decision and Control 11

automatically generated. With this, FCM clustering is then applied for the development of a fuzzy model with low variations of the predefined number of clusters from the number that was obtained from the previous SC fuzzy models.

Regarding neural networks, a feedforward backpropagation model was applied in this work. Few parameters were varied: the number of hidden layers (1 to 3), the number of neurons in each and the number of epochs. For each parameterization, the output may differ because several parameters like the neurons weight change in the development of the model and so 20 loops cycles were performed for each parameterization and the resulting performance was weighted. After that, the parameterizations with the highest performance are carefully addressed.

Finally, in both fuzzy and neural networks models, the stopping criterion that was defined was the mean squared error (MSE). The performance of all models is assessed with the values of Variance Accounted For (VAF), Mean Squared Error (MSE) and Mean Absolute Error (MAE), evaluating mostly the testing set. They can be expressed as:

𝑉𝐴𝐹 = 1 −𝑣𝑎𝑟(𝑦 − 𝑦 )𝑣𝑎𝑟(𝑦 ) × 100% (Eq. 3)

𝑀𝑆𝐸 =1𝑛 (𝑦 − 𝑦 ) (Eq. 4)

𝑀𝐴𝐸 =1𝑛

|𝑦 − 𝑦 | (Eq. 5)

Results and Discussion This section presents the discussion of the results from the developed models for:

x The amphitheater. x The library, dividing in the warm and in the cold season.

Amphitheater As already mentioned, the selected consumption data for this space is from25-02-2013 to 24-05-2013, totalizing 62 entries. The evolution of the addressed variables and electricity consumption for this space are displayed in Figure 6. This generally complements Figure 4.

(1)

The MAE measures the mean of absolute error values,and are expressed as:

Definition of consumption baseline – Case-study in a Portuguese University campus

Henrique R. M. L. Pombeiro Intelligent Decision and Control 11

automatically generated. With this, FCM clustering is then applied for the development of a fuzzy model with low variations of the predefined number of clusters from the number that was obtained from the previous SC fuzzy models.

Regarding neural networks, a feedforward backpropagation model was applied in this work. Few parameters were varied: the number of hidden layers (1 to 3), the number of neurons in each and the number of epochs. For each parameterization, the output may differ because several parameters like the neurons weight change in the development of the model and so 20 loops cycles were performed for each parameterization and the resulting performance was weighted. After that, the parameterizations with the highest performance are carefully addressed.

Finally, in both fuzzy and neural networks models, the stopping criterion that was defined was the mean squared error (MSE). The performance of all models is assessed with the values of Variance Accounted For (VAF), Mean Squared Error (MSE) and Mean Absolute Error (MAE), evaluating mostly the testing set. They can be expressed as:

𝑉𝐴𝐹 = 1 −𝑣𝑎𝑟(𝑦 − 𝑦 )𝑣𝑎𝑟(𝑦 ) × 100% (Eq. 3)

𝑀𝑆𝐸 =1𝑛 (𝑦 − 𝑦 ) (Eq. 4)

𝑀𝐴𝐸 =1𝑛

|𝑦 − 𝑦 | (Eq. 5)

Results and Discussion This section presents the discussion of the results from the developed models for:

x The amphitheater. x The library, dividing in the warm and in the cold season.

Amphitheater As already mentioned, the selected consumption data for this space is from25-02-2013 to 24-05-2013, totalizing 62 entries. The evolution of the addressed variables and electricity consumption for this space are displayed in Figure 6. This generally complements Figure 4.

(2)

Figure 8 shows the VAF and MAE values for eachtype of model, comparing the best performance andthe lowest error. The model that stands out for thebest VAF and lower MAE index is the Fuzzy System.The Neural Network model has identical performanceand error values.

In summary, fuzzy systems and neural networks,shows the most suitable models in order to easily pre-dict a week-long energy consumption of an intelligentbuilding based on occupancy variables, given theirperformance indexes.

VAF (%) MAE (kWh)0

10

20

30

40

50

60

70

80

Linear Regression

Fuzzy System

Neural Network

Figure 8: VAF comparison (higher is better) and MAE(lower is better) values for distinct used methods, summa-rizes the final performance of each energy consumption pre-diction service.

7 Discussion

During the evaluation phase, we defined somerisks and trade-offs of this architecture, that helpedto redefine some requirements in order to deploy animproved system architecture.

Then, during the Case-Study 1 phase that con-sisted in an integration process, the flexibility hasbeen evaluated through the implementation of severaltechnology adapters through a common protocol in-terface, the Datapoint Connectivity API. Our architec-ture proved to be quite capable to dealing with hetero-geneous environment of automation devices and tech-nologies present in the building. Nevertheless, not allfeatures have been integrated, given there are somelimitations of the technologies, being a risk factor thatcan make all the requirements is not fulfilled, as indi-cated in ATAM results.

Finally, in Case-Study 2, the energy predictionservices development allowed us to prove the exten-sibility of the global system, where the capacity ofintegration with different sources of information, candeliver intelligent behavior functionalities using somedata-mining techniques, such as the capacity of pre-dict future data based on the analysis of indirect fac-tors obtained from different data sources.

At the end, we can conclude that our solution suc-cessfully addresses SOA for BEMS requirements andprinciples of flexibility, usability and extensibility.

8 CONCLUSIONS

Developing software for Building Automation isnot an easy task. With the proliferation of BAS be-came almost impossible to integrate several differentsystems made by different manufacturers. In the doc-ument we made a review of existing BEMS technolo-gies and their main functions. We discovered somelacks in existing systems and we found that the bestsolution to this problem was to provide a modular lay-ered architecture middleware, with the aim of enablethe ability to integrate and extend new BA and EMfunctionality easily. Thus we defined a set of servicescollections that we believe to be common in all build-ing automation domains, according to existent stan-dards. With this study, we expect to ascertain thebest way to define a software architecture for BEMS,in order to the development of their functionalities ismade easier. The chosen technology for solution de-velopment was OSGi since it provides mechanismsthat enforce modular design.

The results achieved in the evaluation of the im-plemented solution proves that IST SmartOffice pro-totype can fulfill all the defined requirements of SOAfor BEMS. The interoperability goals were achievedand different protocols and services have been inte-grated in a software solution.

In the future, we hope that IST SmartOffice sys-tem will be extended to more ambient intelligent ca-pabilities, introducing more energy-related benefitsto the large buildings and their environment condi-tions, such as: comfort, productivity, energy-efficient.Comfort, by allowing users to adjust their personalneeds. This is achieved by intelligent control of de-vices from a set of sophisticated applications built ontop of intelligent services. Productivity, by optimiz-ing the work environment for whatever tasks at hand.The building will deliver automatic and transparentbehavior to the users in order to bring a better user sat-isfaction, since his comfort will be optimum, whichallows workers to concentrate better for a longer peri-ods of time, resulting in a higher level of productivity.Energy efficient, by reducing the overall energy con-sumption, not only from services with intelligent con-trol which keep some devices off when they are notneeded, but also by User Behaviour Transformation(UBT) services, that advise the occupants to meetsthe best practices related to the usage of electrical de-vices.

REFERENCES

Bastide, G., Seriai, A., and Oussalah, M. (2006). Adap-tation of Monolithic Software Components by TheirTransformation into Composite Configurations Basedon Refactoring Example of Experimentation : AShared-Diary System. pages 368–375.

Bloom, E. and Gohn, B. (2013). Building Energy Manage-ment Systems IT-Based Monitoring and Control Sys-tems for Smart Buildings : Global Market Analysisand Forecasts.

Bottaro, A. and France, M. (2008). Home SOA – FacingProtocol Heterogeneity in Pervasive Application Gen-eral Terms :. pages 73–80.

Cannata, a., Gerosa, M., and Taisch, M. (2008).SOCRADES: A framework for developing intelligentsystems in manufacturing. 2008 IEEE InternationalConference on Industrial Engineering and Engineer-ing Management, pages 1904–1908.

Eisenhauer, M., Pramudianto, F., Researcher, M. S., andKostelnik, P. (2011). Towards a generic middle-ware for developing ambient intelligence applications.pages 26–28.

European Parliament and Council (2010). Directive2010/31/EU of the European Parliament and of theCouncil of 19 May 2010 on the energy performanceof buildings. Official Journal of the European Union,L153:13–35.

European Standard (2006). Energy performance of build-ings - Impact of Building Automation Control andBuilding Management - EN 15232. 00247046:1–63.

Hall, R., Pauls, K., and McCulloch, S. (2010). Osgi in Ac-tion: Creating Modular Applications in Java. Man-ning Pubs Co Series. Manning Publications.

International Standard (2007). Building automation andcontrol systems (BACS) - Part 3, ISO 16484-3.

International Standard (2013). Building automation andcontrol systems - Part 7: BACS contribution on theenergy efficiency of buildings.

Kazman, R., Klein, M., and Clements, P. (2000). ATAM :Method for Architecture Evaluation. (August).

Lee, J. H., Shim, H.-J., and Kim, K. K. (2010). Critical Suc-cess Factors in SOA Implementation: An ExploratoryStudy. Information Systems Management, 27(2):123–145.

Leitner, S.-h. and Mahnke, W. (2006). OPC UA – Service-oriented Architecture for Industrial Applications.

Levermore, G. (2002). Building Energy Management Sys-tems: An Application to Heating, Natural Ventilation,Lighting and Occupant Satisfaction. Taylor & Fran-cis.

Litvinov, A. and Vuorimaa, P. (2011). Integration Plat-form for Home and Building Automation Systems.(PerNets):292–296.

Open Group Standard (2011). SOA Reference Architecture.Osello, Anna Acquaviva, A. A. (2013). Energy saving in

existing buildings by an intelligent use of interopera-ble icts. Energy Efficiency, 6(4):707–723.

Stavropoulos, T. G., Gottis, K., Vrakas, D., and Vlahavas,I. (2013). aWESoME: A web service middleware forambient intelligence. Expert Systems with Applica-tions, 40(11):4380–4392.