Associate Professor, Anna Osello
email: anna.osello@polito.it@303351800784

Assistant Professor, Andrea Acquaviva

Chiara Aghemo

PhD Laura Blaso

PhD Daniele Dalmasso

David Erba

Vincenzo Giovanni

Damien Fracastoro

Marco Gondre

Enrico Jahn

Macii

Giovanni Vincenzo Fracastoro

Marco Jahn

Full Professor, Enrico Macii

PhD Edoardo Patti

Anna Pellegrino

Paolo Piumatti

Maurizio A Spirito

Riccardo Tomasi

Joseph Virgone

energy saving in existing buildings by an intelligent use of interoperable ICTs

Keywords: Interoperability, Middleware, Wireless Sensor and Actuator Networks, Building Management System, Building Information Modelling, Energy Awareness and Efficiency

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The new era of smart Information and Communication Technology (ICT), providing real-time access to monitoring information, is bringing a new concept of energy management. Pervasive devices also enable effective control strategies allowing reduction in energy usage and CO 2 footprint in existing public buildings without significant construction work. In particular, special attention must be paid to historical buildings where damage by extensive retrofitting must be avoided.

The aim of SEEMPubS research

The goals of the SEEMPubS [1] project are several and fully integrated with each other as described below:

• To develop an integrated electronic system to monitor different buildings, building services, electronic devices and operations in order to optimize and integrate all maintenance functions. • To implement an interoperable web-based software solution for real-time energy performance monitoring and control of lighting and HVAC services through Wireless Sensor and Actuator Networks (WSAN) . This is done through an integrated approach based on the LinkSmart energy-aware middleware platform [3.3]. In this way, the project is able to deploy the new solution in buildings by reusing already existing structures (e.g. proprietary sensor networks or management systems) and by integrating them into an intelligent energy management system, supported by a Graphical User Interface (GUI).

• To provide multi-dimensional visualization of parameters of building operations and data sharing from technical systems. Real-time information is collected by sensor networks detecting environmental and maintenance-oriented parameters of performance from lighting and HVAC services. The primary purpose of such a performance monitoring system is to provide facility managers and operators with the means to easily assess the current and historical performance of the building as a whole, and of its significant energy consuming systems and components. The performance monitoring system includes not only the needed sensors, wiring and data acquisition devices, but also means to calculate, display and archive resultant parameters.

• To raise people's awareness for energy efficiency in public spaces: this is a key aspect and the first step in the process of fostering sustainable and responsible behaviour with respect to energy consumption. This includes the construction of a user community portal to enable communication and information exchange among users. Such communities, consisting of users with different levels of knowledge of the energy domain, combined with ambient awareness features, have the ability to create a new energy consciousness of citizens into public spaces. All elements are validated through an iterative methodology to ensure the gradual approximation to SEEMPubS with simultaneous consideration of all stakeholder needs. The validation phase of the project is conducted utilizing the most significant buildings in the Politecnico di Torino Campus, selected as demonstrator.

The case studies

The construction period of the Politecnico di Torino's campus ranges from the XVI century to the XXI century, thus including buildings very different in dimension, shell, construction characteristics and performance. The short description below helps to understand the reason of its representativeness as an example of a wide range of similar buildings in Europe. The Valentino Castle on the river Po, seat of the Schools of Architecture is a historical site. Its origins date back to the beginning of the XVI century. A non-insulated and highly massive shell characterizes the building, and the systems have been realized taking into account the building's conservation requirements. The Main Campus on Corso Duca degli Abruzzi, dedicated mainly to Engineering was inaugurated in November 1958. The building envelope was built with very poor thermal insulation criteria and several retrofits are being planned to increase the building's energy performance. The Cittadella Politecnica, recently built next to the Main Campus in a former industrial area, is the Politecnico's research centre. The plan, started in 1994 and at present under completion, includes recovery of the most interesting industrial buildings, and new buildings. This campus was built adopting energy efficiency-oriented construction techniques, according to the Italian Law 10/91. Based on the description above, it is clear that each building has specific energy needs and limitations concerning control systems which should be installed; a major challenge for the SEEMPubS project is to deal this specific deployment's details, providing a generic framework, which is able to actually impact on energy efficiency.

The architecture of SEEMPubS Building Energy Management System

As described previously, one of the main goals of SEEMPubS is to develop a middleware for holistic Building Energy Management Systems (BEMS). With regards to system architecture design two major requirements were identified. First, such middleware needs to support the integration of heterogeneous technologies, such as WSAN, building management systems, or smart meters. Second, the middleware must provide unified access to these technologies to support the implementation of applications that use these technologies in an interoperable way (e.g. implementation of building control strategies). A further requirement from the middleware perspective is that the developed components should be extensible and reusable in similar settings. In order to cope with these requirements, the SEEMPubS consortium has decided to limit custom developments and instead employ and extend an already existing and proven technology, namely the LinkSmart Middleware. The LinkSmart Middleware is a generic middleware for developing Ambient Intelligence (AmI) applications [START_REF] Eisenhauer | A Development Platform for Integrating Wireless Devices and Sensors into Ambient Intelligence Systems[END_REF][START_REF] Eisenhauer | Towards a generic Middleware for developing Ambient Intelligence Applications[END_REF]. It is the result of the FP6 European Project HYDRA [START_REF]HYDRA Project[END_REF] and it is currently employed in a large number of other EU and international research initiatives, e.g. [START_REF]SEAM4US Project -Sustainable Energy mAnageMent for Underground Stations[END_REF][START_REF]Adapt4EE Project[END_REF][START_REF]ebbits Project-Business-Based Internet of Things and Services[END_REF]. AmI is characterized by making use of various different technologies and devices, which together perform ambient and intelligent computing tasks. Typical examples of AmI are smart homes or ambient assisted living projects. LinkSmart provides a framework and software development tool for integrating heterogeneous networked devices into AmI applications. Further, LinkSmart comes with software components that provide functionality typically for AmI applications (e.g. message encryption, event management, or device discovery). The LinkSmart Middleware is applied and extended to develop a dedicated middleware for the energy efficient buildings domain -under consideration of the aforementioned requirements. In the following we describe the SEEMPubS architecture and explain to which extent LinkSmart technology is reused and extended with new functionality. Figure 1 shows the layered architecture of the SEEMPubS system including its main components.. On the LinkSmart Proxy Layer different kinds of technologies (WSAN, BMS or smart meters) are integrated into an interoperable system. We employ the Proxy approach defined by the LinkSmart Middleware. This approach allows to use the different technologies in a unified way (cf. 4.1). A LinkSmart Proxy is a component that acts as bridge from a specific technology to the LinkSmart middleware by providing a defined service interface. In this way, proxies allow unified access to the different technologies through LinkSmart. On the SEEMPubS Middleware Layer reside components that process data provided from the Integration Layer and provide further functionality to the Application Layer (e.g. components to execute building control strategies reside on this layer) (cf. 4.3). The Middleware Layer is conceptually separated into two parts: the LinkSmart infrastructure components and the Context Framework. The infrastructure components, namely Network Manager and Event Manager provide the core communication functionality for all LinkSmart components. The Network Manager enables network communication among devices inside a LinkSmart network. It creates an overlay P2P network that implements SOAP Tunneling as transport mechanism for web service calls [25], allowing direct communication among all devices inside a LinkSmart network, no matter if they appear behind a firewall or NAT (Network Address Translator). The Event Manager allows developers to build event-based systems, which in the case of systems dealing with sensors, is a core requirement. In SEEMPubS, the Event Manager is used to publish events at the Proxy Layer and to listen to events wherever needed, for instance at Context Framework, for further processing. The Context Framework is an extension to LinkSmart which is specifically designed for energy-efficiency applications aiming at achieving semantic interoperability. While syntactic interoperability is achieved by the Proxy Layer (by homogenizing the different standards and protocols of different technologies), semantic interoperability in SEEMPubS means to abstract from the Proxy Layer to a layer that deals with domain objects like buildings, rooms, windows, appliances, sensors, etc. Such domain information can then be used by the system for (i) end-user applications, (e.g. for visualization) and (ii) for implementing building management control strategies that work seamlessly across heterogeneous technologies. The Context Framework is described in detail in Section 4.3.2. The Application Layer comprises end-user applications for different kinds of users (e.g. an integrated monitoring and control application for the building energy manager would be part of the Application Layer as well as applications for building occupants) (cf. 4.3). With the help of the Middleware Layer, information should be easy accessible by any kind of application.

Related Work

Several research projects are dealing with increasing energy efficiency in buildings. The FIEMSER [26] project aims at developing an energy management system (BEMS) for existing and new residential buildings. FIEMSER tries to achieve that goal by optimizing the balance between energy generated locally, energy needed from external providers and energy demanded by the building. Technically FIEMSER employs a combination of sensors and actuators from traditional PLCbased BEMS systems, connected via an OSGi+SOA REST architecture. While the goals of FIEMSER and SEEMPubS are to some extent comparable, they both aim for different domains. Another similar project but with a different domain is 3e-House which deals with the integration of established ICT technologies in social housing in order to provide an innovative service for energy efficiency. Other projects such as SaveEnergy [27] focus on changing people's behavior through the use ICT -real time information and serious games in the case of SaveEnergy. A similar approach is implemented by the BeAware [28] project, which also aims at increasing people's energy awareness in private households. Many other research initiatives and projects aiming at increasing energy efficient in different kinds of buildings exist, each focusing on different specific topics.. SEEMPubS tries to produce a result which can be generalizrd -namely the middleware -that can be applied in other projects dealing with energy efficiency in buildings and the aforementioned issues of interoperability. While many different projects develop custom middleware solutions, we will provide an open software that can be applied for energy efficiency applications in buildings in a general way. Using the existing LinkSmart infrastructure is supposed to support this goal.

Methodology

SEEMPubS is committed to an iterative approach following the principles of the common standard ISO 13407. The goal of this procedure is focused not only on the evolution of the applications and services, but also on the refinement of scenarios, requirements, specifications of the SEEMPubS platform and its implementation. This iterative process ensures the gradual approximation to all multidisciplinary activities involved in SEEMPubS with simultaneous consideration of all stakeholders needs as described following.

Integration of devices

The strategy for smart building management and control leverages upon an ICT infrastructure made of heterogeneous monitoring and actuation devices, such as WSAN. Moreover, in order to improve backwards compatibility, the infrastructure supports wired devices work with different protocols, such as BACnet, LogWork, etc. An innovative web service oriented software infrastructure has been developed to manage heterogeneous and commercial devices. As introduced before, the LinkSmart middleware [START_REF] Eisenhauer | A Development Platform for Integrating Wireless Devices and Sensors into Ambient Intelligence Systems[END_REF][START_REF] Eisenhauer | Towards a generic Middleware for developing Ambient Intelligence Applications[END_REF][START_REF]HYDRA Project[END_REF] has been adopted to provide interoperability between heterogeneous devices and networks, both existing and to be deployed. Moreover, the proposed infrastructure allows easy extension to other networks, thus representing a contribution to the opening of a market for ICT-based customized solutions integrating numerous products from different vendors. The system manages energy efficiently and WSANs are preferred to simplify the integration of new sensors into the system and also to avoid overloading of cables in historical buildings. The software infrastructure provides the following main functionalities:

• It enables the interfacing to the application layer by means of web services, through which the sensor data is read and can be used for visualization or to feed energy management policies;

• It collects environmental data coming from the sensor nodes into the local database and this data can be accessed in an asynchronous way and preserved from network failures; • It allows the remote reconfiguration of sensor node parameters such as the sampling rates of physical quantities which are to be monitored; • It allows the remote control of actuator devices;

• It enables interoperability among heterogeneous networks, characterized by different communication protocols, microcontrollers and sensors. As shown in Figure 2, the software runs in a PC-Gateway (GW) and communicates directly with the heterogeneous networks. The dedicated Interface represents the lowest layer of our proposed stack, and receives information coming from various devices, regardless of the adopted communication protocols, hardware or the network topology. Hence, each network needs a specific software interface, which interprets the environmental information (e.g. temperature, humidity, etc.) and stores them in an integrated database (DB), in order to make the whole infrastructure flexible and reliable with respect to backbone network problems, since data are locally stored. The web-service layer, implemented using LinkSmart, interfaces the device networks to the web, making the remote management and control easier. Moreover it exports to the application client layer, the last in our stack, all the environmental data that was stored in the DB. At this layer, the information is available to the end-user and ready to be post-processed or to be shown via computers, tablets or smart phones. Particular emphasis was given to the possibility to reconfigure each node, changing, for instance, some parameters about power management. In this scenario, the end-user sends the new configuration via web-services to the GW and stores it in the DB. Then, the new settings will be automatically sent to the receiver mote, when it wakes up from the sleeping period, through the specific network software Interface. The configurable parameters change depending on the hardware and the Operating System running on the end node. However, using this software infrastructure, the user can choose only the right settings ignoring the real physical hardware related to the virtual device. About power management, it is worth noting that there is no standard that indicates how controls and configuration settings are to be sent to the mote via the protocol packet payload. Hence, the proposed network software Interface is hardware dependent only for the way in which these parameters are formatted. However, from the communication point of view, it is protocol standards compliant. The proposal and development of a standard for power management would be desirable but is not the subject of this project. The goal of this research, from ICT side, is to enable the communication between heterogeneous and commercial devices; this implies a certain dependence on hardware. Particularly in this case study, we have developed different interfaces to manage respectively five commercial WSAN based on:

• Crossbow Telos rev.B [8] open source end node to monitor air temperature, relative humidity and illuminance, which exploits IEEE 802.15.4 communication protocol;

• Our customized end node built on Texas Instruments' cc2530 system on chip [START_REF]Texas Instruments' CC2530 Datasheet[END_REF] to monitor air temperature and illuminance leveraging the ZigBee protocol;

• ST Microelectronics Smart Plug [START_REF]ST[END_REF] commercial end node to monitor power energy consumption and to switch on/off the lighting plants, exploiting the ZigBee protocol;

• Plugwise Smart Plug [START_REF]Plugwise: Smart wireless solutions for energy saving, energy monitoring and switching[END_REF] commercial end node to monitor power energy consumption and to switch on/off the appliances connected to the mains exploiting the ZigBee protocol;

• EnOcean protocol stack [12] commercial end nodes to monitor air temperature, relative humidity, illuminance, occupancy and to actuate heating and lighting plant respectively. Moreover, an interface has been developed to enable the remote communication with the Siemens Desigo BMS that exploits the BACnet protocol [START_REF]BACnet protocol[END_REF] in order to monitor and actuate Desigo wired devices. In a nutshell, the proposed web-based infrastructure is a software that makes transparent to the end-user the underlying devices, abstracting all the information about hardware, communication protocol stack and embedded operating systems. Furthermore, the use of web-services makes the interoperability with third-party software easy.

BIM and Interoperability

To optimize the data exchange among architecture, Mechanical Electrical and Plumbing (MEP), energy simulations and Facility Management (FM), at the beginning of the project a BIM methodology was used. For this reason, the interoperability testing described in this paragraph is an important issue of SEEMPubS, both for processing and for data visualization [START_REF] Osello | The future of drawing with BIM for Engineers and Architects[END_REF]. The BIM approach started with the creation of 3D models of each case study through Autodesk applications as shown in Figure 3. In particular Revit Architecture was used for architectural modelling and Revit MEP for the modelling of heating/cooling and lighting systems [15]. To test the interoperability between architectural modelling and lighting simulations it was necessary to realize the 3D models of the real rooms and their external environment. The 3D models were used to run energy simulations, which were validated through the monitored data and then used to estimate the building energy demand. In particular, Radiance [START_REF] Larson | Rendering with Radiance[END_REF] was used to validate the models, comparing the simulated illuminance distribution to the illuminance values measured in the corresponding rooms, while Daysim [START_REF] Reinhart | Daylight Availability and Manual Lighting Control in Office Buildings[END_REF] was used to estimate the lighting energy demand and the savings obtained with the specific control strategies proposed for each case-study, as it allows running annual simulation for a site, accounting for the specific dynamic climate conditions. In order to run the lighting simulations, it was not possible to import the parametric model from Revit into Radiance/Daysim directly. The software Ecotect Analysis [START_REF]Ecotect Analysis official[END_REF] was hence used as interface to launch Radiance/Daysim. As a result, Revit was imported into Ecotect using different procedures, with the aim of finding the most appropriate. The first trial adopted the traditional approach based on the exporting in IFC (Industry Foundation Classes) format, but it did not succeed because some elements, such as the window frames, were not exported or were displaced. The second trial was based on the exporting from Revit by a gbXML file, but some geometrical discrepancies in the surfaces generated from the solid elements made the model unsuitable for the lighting simulation. In fact, this type of exporting involved some model simplifications that turned out to be incorrect for lighting simulations, even if the model was correctly generated and all the elements had maintained their reciprocal positions. The third procedure was the most appropriate, both concerning modelling in Revit Architecture environment and for the analyses with Radiance and Daysim (thanks to Ecotect as a software interface), through the use of 3DStudioMax as an intermediate software (to convert the .fbx file exported from Revit in a .3ds file imported into Ecotect) which gave good results in terms of geometrical consistency of the exported model. Nevertheless, also with this procedure it was necessary to check the 3D models imported in Ecotect before starting the lighting simulations in Radiance and Daysim, to prevent some trivial mistakes connected to an oversight or elimination by the operator (for instance the disappearance of some parametric elements). Once the 3D models were successfully imported into Ecotect, it was possible to proceed with the lighting simulations in Radiance and Daysim. The numerical data obtained from the simulations were graphically processed by using the Ecotect Analysis application, through the import of .dat format (coming from Radiance) or .da (coming from Daysim) and therefore shown in 3D visualization. In a similar way it was possible to work between architectural (Revit Architecture) and thermic (Trnsys 17) models using SketchUp as additional software. Compared to the classic method, the use of the 3D model in Trnsys 17 required attention in some critical points (north orientation, window frame and wall thickness). Therefore, before starting the simulation phase, we fixed the critical points. In detail:

• The model was optimized after the importation in SketchUp, before drawing the Thermal Zones;

• The window area was adjusted. In fact, since in Revit Architecture objects are parametric, it is possible to calculate the exact area of the frame and of the glass surface for each window; this value was put in Trnsys to improve the accuracy of the simulation results;

• The problem of the wall thickness between adjacent Zones was fixed by moving the wall surface of one of the two rooms. This had as a consequence a volume increase of one or both rooms; but this does not have significant consequences on the results due to the little impact of air volume in the heat balance.

Context awareness

The Context Framework is part of the energy efficient middleware. From a software architecture perspective it resides between the proxy layer (as described in 3.3) and the application layer. The aim of this Context Framework is to interpret data provided by sensors and devices into semantically interoperable information that can be used by the system for (i) enduser applications (e.g. for visualization) and (ii) implementing building management control strategies that work seamlessly across heterogeneous technologies. Context-aware optimization is a generic and "complex" task, since its main goal is to adapt the building behaviour to detect and act upon a very broad and extensible set of situations. For this reason, the SEEMPubS Context Framework must provide flexible means to describe generic "situations" which are significant for energy consumption monitoring, optimization and awareness. As an example for such a situation we define the energy-wasting situation. An energy wasting state is defined as a situation where energy is being spent without benefit for the users. An example of energy wasting state might be represented, for instance, by a room where the window is open and the HVAC is running or a PC left idle without any use. Such information could be used to provide feedback to end-users and motivate energy-saving behaviour. Another use-case showing the advantages of semantic interoperability is the technology-independent definition of control strategies in an integrated system. In the following we describe how the SEEMPubS Context Framework supports these concepts

4.3.1

From sensor data to building information The term semantic interoperability in our system characterizes the ability to access different kinds of devices, sensors, actuators, or systems through a unified vocabulary (cf. Ontology Manager) regardless of vendor-or technology-specific implementations, data formats, APIs, etc. Figure 4 shows how data is transformed from the actual sensor to the Context Framework. The Proxy layer is responsible for processing raw sensor data and adding some basic meta-information and forwarding it to an Event Manager. The Context Framework is responsible for associating the incoming data with a meaning.

4.3.2

The Context Framework In this paragraph we present the implementation of the Context Framework that uses an Ontology-based knowledge repository and rule-based context recognition system that allows defining actions that should be performed upon recognition. The Ontology models the abstraction from concrete devices, sensor etc. to domain specific entities such as buildings, rooms, HVAC appliances, etc.

Ontology

The Ontology provides a taxonomy for the energy efficient buildings domain, describing a model that is used to support the development of energy efficiency applications. This model describes the (semi-) static environment of the building independently from the type of implementation or platform used in development of such applications. It models devices, sensors, actuators, rooms, and observable properties such as temperature, humidity and so on. To map from the domain to the implementation it also models software proxies, services, and events.

Context Manager -Rule Engine and Entity Manager

The Context Manager consists of two major components, (i) an Entity Manager to manage the current and past context of all entities and (ii) a Rule Engine to store and evaluate context reasoning rules. The Rule Engine has two main roles: (i) rules are defined to recognize a situation based on the state of entities in the system and (ii) rules can also be used to define an action that should be performed upon recognition of a situation. We use the Drools [19] rule engine -a well-known rule engine for business applications -and modified the rule language allowing it to define triggers that will be used by the Context Manager to subscribe to specific sensor event which monitor the context of the entities. When a sensor event comes, the Context Manager will update the context of all entities that are associated with that event. The correlation between the sensor event and the entities is done with the help of Ontology reasoning. The drools engine will then evaluate any rules that are associated with that entity and execute the actions defined in the rules. Such action could be the invocation of an actuator. The Entity Manager is responsible for keeping track of entities and their context attributes (e.g. temperature in Room1, humidity in Room1). An entity and its context attributes are monitored automatically once they are defined in a rule and their current state is saved. This approach enables the Entity Manager to only store the current state of the system as needed.

By moving the storage of ever-changing context data from the Ontology to a dedicated Entity Manager we avoid performance problems in the semantic store. In the following we provide an example that explains how the Context Framework can be used to recognize situations and perform actions accordingly. This information is stored in the Ontology and will be reasoned by the Ontology Manager. Figure 5 shows (in a simplified way, leaving out sub-classes) how the relevant information is modelled in the Ontology. Besides notification of situation changes the rule-based approach also allows for implementing control strategies, such as: Every time the presence property of Room1 changes and it is false, switch off the light in that room. Beyond this simple example it is worth observing that presence detection, or more in general occupancy detection [12] is a complex process and can thus give more complex types of outputs rather than "true/false" presence information. Therefore, occupancy values might have been evaluated beforehand by other rules or by dedicated components, for instance an Occupancy Proxy that takes care of optimizing occupancy recognition by using multiple input sources and adding probabilities to occupancy states. As for recognition the Context Framework also handles the invocation of an actuator for switching the light. Therefore, the Context Manager consults the Ontology to find the respective actuator. A standardized Proxy interface allows executing the correct service via the proxy that communicates with this actuator.

Control rules, control strategies (middleware)

Since the project aims at controlling HVAC and lighting systems using temperature, luminance and occupancy sensors, new control rules must be designed and tested in order to properly balance energy savings and comfort issues [START_REF] Fracastoro | Energy efficiency in public buildings through ICT based control and monitoring system[END_REF]. The thermal inertia of buildings leads to a low responsiveness of the HVAC system, which requires an anticipation of possible future use of a room in order to meet comfort requirement within a reasonable time when occupancy is detected. The test cases have been modelled in Daysim (lighting simulations) and Trnsys (thermal simulations) and several control rules have been implemented and tested. According to the information on the rooms features, achieved during the first phase of the project, some lighting control strategies were initially proposed. In particular, for spaces with high daylight availability and medium/high users absence probability, a combination of daylight harvesting and occupancy detection was proposed as lighting control strategies, while, for spaces with low daylight penetration, only occupancy detection was supposed to be used. In any case users are allowed to override the system with manual control. Thermal control strategies are guided by the maintenance or improvement of user comfort combined to the best energy savings. As the uncertainty in occupancy schedules is detrimental to savings and/or comfort, a difference has been made between personal offices where presence detection is the only available information, and common rooms (meeting rooms or classrooms for instance) where users have to book the room, which allows strategies based on anticipation.

Another difficulty is to evaluate the time necessary to reach the set point temperature when preheating is planned. It depends on the inertia of the building but also on the weather conditions and the indoor temperature. A precise calculation of this "recovery time" would lead to the best compromise in terms of energy savings and user comfort. Figure 6 below displays the main control rules considered for both lighting and HVAC systems.

Results

SEEMPubS is still under way but first simulation results are already available. Simulations are part of a preliminary work that aims at optimizing energy conservation strategies that are implemented in the demonstrator. It is already planned to compare numerical results with experimental results as soon as results are available. The following paragraphs presents some simulation results of the ongoing work on energy saving in the HVAC and lighting systems.

Estimated energy savings, heating and cooling

This paragraphs aims at presenting detailed results for one of the six case studies. The test office is part of the Valentino Castle, the historical building made of heavy walls without thermal insulation. Its energy consumption is high and its thermal responsiveness is very low. As savings strategies are based on an optimization of vacancy periods, results heavily depend on occupancy hypothesis used in the simulations. Two different kind of occupation profiles are used in the simulation. The "theoretical occupancy" starts at 8 AM and ends at 6 PM (ten hours a day, five days a week, which means fifty hours a week) and corresponds to the time range when occupancy probability is high. In the presence detection algorithm, the theoretical occupation profile does not provide a lot of details since it is hard to forecast the actual occupancy, while in the presence anticipation algorithm, the theoretical occupancy profile is detailed as much as possible since it is used for classrooms and meeting rooms where it is easy to know in advance what the future occupation should be. The "real occupancy" is directly linked to the occupancy detection sensor but in the simulation it is set as fixed ranges which include two full occupancy days (on Mondays and Fridays) with a one-hour lunch break and two half occupancy days (on Tuesdays and Wednesdays) with a five-hour occupancy divided into three periods (8 AM -10 AM, 1PM -2 PM, 4 PM -6 PM). No occupancy at all is considered on Thursdays. For instance, it may represent a day off, a seminar day or a day out of office. With regards to this simulation hypothesis, the real occupancy profile used in the simulation represents 56% of the theoretical occupancy. As the presence anticipation algorithm was originally designed for common rooms such as classrooms or meeting rooms, results discussed later will mainly focus on a the presence detection algorithm. In order to optimize the restarting time of the HVAC system in the early morning or after a period of vacancy, a study was carried out in order to characterize the building inertia. The idea was to find the best correlation between the time ∆τ necessary to reach the set point temperature (referred to as recovery time later in the text) and the ambient conditions such as the outdoor temperature, the indoor temperature T in and the setpoint temperature T sp . Restarting curves have been analysed for 154 mornings of a yearly simulation. Monday mornings were analysed separately since the thermal behaviour of the building is different after two unheated days.

Figure 7. Recovery time as a function of the temperature difference ∆t = T sp -T in (i) during the heating period

The best correlations linked the recovery time to the temperature difference between set point and indoor temperature at the restarting time. As this very simple linear equation (lines 1 on Figure7 and Table 1 below) is not sufficient to properly describe the building behaviour, its direct use leads to good energy savings but also leads to discrepancy of user comfort (see Figure 8 below), due to the underestimation of the recovery time for about half of the time. In order to optimize the balance between energy savings and user comfort, two updated correlations are used (lines 2 in Figure7 and Table 1). As it is not sufficient to improve comfort as much as expected, a second set of updated correlations is used (lines 3 in Figure 7 and Table 1). Energy savings values are given in percentage of savings compared to simulation results of the actual control rules used in the case study (reference room). The main differences with the test room lie in the absence of presence detection and in the use of only two set-point temperatures (one at night, and another one during working hours). As indoor temperatures may be higher in the reference room than in the test room (especially during working hours when occupancy is not "detected"), non-negligible heat transfers occur from the reference room to the test room. This leads to an over-estimation of the reference room consumption and an under-estimation of the test room consumption. Results can then be flattering and ...false! In order to calculate the consumption that would actually be observed if the whole building was equipped with the same control system, two simulations are run separately: one with the actual conservation strategy (reference), and another one with the proposed conservation strategy (test). Comfort analysis is based on the operative temperature distribution in the first hour of occupancy (8AM -9AM) when occupancy is "detected" (figure 8).Results are very close to the present situation in terms of comfort and this strategy allows a 14.6% reduction on the overall annual energy demand (Table 1). These first simulation results show that the estimation of the recovery time can be improved in the future. The more accurate the estimation of recovery time is, the less energy is needed in order to reach a given comfort level (and the more efficient are the control rules). Nevertheless the recovery time heavily depends on the building characteristics, but also on the HVAC system specifications (water and air flow rates and temperatures of the fan coils unit) that are difficult to know with precision. It then requires to fit simulation results with monitoring results in order to find the most likely HVAC specifications. These control rules will therefore require a lot of data and studies to be extended to new buildings with different characteristics. That is the reason why we are currently studying the feasibility of developing a self-learning system that would itself calculate an estimation of the recovery time, based on data collection of the past few days or months. It would avoid thermal inertia calculation (and associated data collection) since the system would calculate it itself. An algorithm based on presence anticipation also requires the recovery time calculation and also needs to be linked to a schedules DB. Simulation on the same office showed slightly better results in terms of comfort but higher energy consumption for presence anticipation strategy. It is probably due to the high inertia of the building, which leads to slow temperature variation when the HVAC system is turned off. For vacancy period shorter than a couple of hours, the presence detection strategy does not call for heating or cooling while the presence anticipation strategy restarts the HVAC systems in advance, which leads to higher power consumption. Presence anticipation strategy is then probably more relevant for low occupancy rooms in low inertia buildings. Results showed that it is possible to save up to 22.6 % (32.5 % on heating and 3.9 % on cooling) in the classrooms case study. The development of HVAC strategies will continue in two perspectives: extending detailed analysis of predictable energy savings to similar spaces (offices) of other types of buildings (Main Campus and Cittadella Politecnica), and analysing the results obtained from prototypes that will be installed in the six test rooms

Table 1. Correlations used in the three test cases for calculation of the HVAC restarting time and estimation of associated energy savings

Estimated energy savings, lighting

To assess the effectiveness of the new lighting control solutions the energy savings achievable with respect to the actual reference situation (manual lighting control), were calculated from the estimated total annual electric lighting energy consumptions. The total annual energy used for lighting depends on different aspects, mainly related to the indoor daylight availability, the building usage (occupancy profile and lighting requirements), the users' behaviour in terms of interaction

Non-comfort zone Comfort zone

with the lighting systems, and the lighting plant characteristics. The simulations carried out with Daysim are based on the annual weather data for Torino, on the actual offices occupancy profile (monitored during le previous phase of analysis) and lighting requirement (target illuminance of 500 lux), on the plant power consumption including electricity consumption associated to the control devices, and on stochastic user behaviour models implemented in Daysim to mimic how building occupants interact with manual controls of lighting plants or shading devices. In particular simulations were initially carried out considering a "mixed users' behaviour" that means users are partly active and partly passive with respect to the use of electric lighting and blinds. Active user is a user who operates the electric lighting in relation to ambient daylight condition, opens blinds in the morning, and partly closes them to avoid visual discomfort, while a passive user is a user who keeps the electric lighting switched on throughout the working day and keeps the blinds lowered throughout the year. Simulations and comparisons between energy demand with the existing control system (manual control) and the new proposed lighting control rules were carried out for all rooms selected as case studies for the SEEMPubS project. The calculated energy saving ranges between 5% and 16% for offices with manually controlled blinds, while it rises up to 30% when both electric lighting and blinds are automatically controlled. Energy savings are calculated as relative difference between the simulated consumption of existing reference control solution (manual control) and the new proposed lighting control rules.

Analysing the results achieved from the lighting simulations, whose goal was to verify the effectiveness, in terms of energy saving, of the proposed control strategies for each room, it was observed that, in most of the cases, obtained energy savings were below the expectations. The initially proposed control strategies were mainly based on switching lights on and off as a consequence of users presence detected by the occupancy sensors, and on the automatic dimming of lights as a consequence of daylight availability. To optimise the energy saving results it was decided to simulate a control rule which provided for users to turn the lights on when the luminous environment is perceived too dark and for occupancy sensors to switch them off automatically when users absence is detected. When switched on, in rooms with high daylight availability, lights are dimmed in order to maintain the target illuminance on the working plane. Figure 9 shows the new proposed control rules for lighting. The reduction of electric lighting consumption for the different rooms now ranges between 27% and 48% for rooms with high daylight availability and it reaches 13% for the open plan office where only switching off based on occupancy detection was considered. The last hypothesis that was checked was based on a different user behaviour: as it is supposed that the SEEMPubS platform should increase people's awareness by means of a web-based tool to directly interact and communicate information to users, the last set of simulations were carried out considering an "active user", that is a user who behaves consistently with the actual indoor and outdoor environmental conditions [START_REF] Reinhart | Lightswitch-2002: a model for manual and automated control of electric lighting and blinds[END_REF]. The energy savings obtained with the described assumptions rise to a maximum of approximately 70%. In this last case both savings due to optimised control of lighting and improvement of user behaviour are considered. A summary of the calculated electric energy savings for lighting is presented in Table 2. The technical architecture used for lighting control does not differ from previous commercial solutions. The type of sensors used in Seempubs project (photosensors and occupancy sensors) are commonly used to control lighting and the sensors layout as well does not differ from standard solutions. Control strategies instead, have been analysed in order to find the most effective solution by comparing possible alternative control logics for each room. In most existing buildings the same control logics are applied in rooms with very different features, in this way reducing the saving potentials of the automatic control system. This is clearly highlighted by the savings results obtained by comparing, through simulation, the lighting control solution typically proposed by many commercial products and adopted in many offices (auto on/off and dimming) with control logics, based on occupancy as well as daylighting availability, but with a different degree of manual and automatic control (eg. savings rising for a single room from 16% to 39%). Furthermore, the SEEMPubS middleware, unlike common commercial systems, allows the monitoring and recording of both lighting energy, environmental lighting conditions and plant status, thus allowing facility managers to check the system operation and in case of fault or ineffective operation to quickly intervene to recalibrate the system. It is in fact commonly known that a system behavior not meeting users' expectations is one of the main cause of automatic control systems rejection.

Results obtained with the simulation carried out in this phase of SEEMPubS project are consistent with in case of active user behaviour or grater than the savings achieved with automatic lighting control in other similar research activates [START_REF] Li | An analysis of energy-efficient light fittings and controls[END_REF] [23] [START_REF] Yun | Effects of occupancy and lighting use patterns on lighting energy consumption[END_REF].

Conclusion

In this study we tested how ICT makes it possible to integrate different processes, applications, systems and technologies in order to reduce energy consumption. First of all, to obtain a smart building management and control leverages, we defined an ICT infrastructure made of heterogeneous monitoring and actuation devices and we developed the LinkSmart middleware to collect environmental data coming from the sensor nodes in a local DB. Then we proposed a web-based infrastructure to make transparent to the end-user the underlying devices, abstracting all the information about hardware, communication protocol stack and embedded operating system. Moreover, we set a Context Framework that uses an Ontology-based knowledge repository and rule-based context recognition system to allow the definition of actions that should be performed upon recognition. Finally, we used BIM and interoperability to process and visualize all data essential for energy simulations and for FM. Our results concern control rules and test on HVAC and lighting systems using temperature, luminance and occupancy sensors, in order to properly balance energy savings and comfort issues. Future work should optimize the increase in people's awareness by a web-based tool to directly interact and communicate information to users.

Figure 1 .

 1 Figure 1. Layered System Architecture

Figure 2 .

 2 Figure 2. Software infrastructure scheme to handle heterogeneous devices

Figure 3 .

 3 Figure 3. BIM and Interoperability as method to optimize the process

Figure 4 .

 4 Figure 4. Abstraction of Data

  As stated before, the Context Framework allows us to deal with domain objects. This means, we can define rules like the following: Every time the state of Window1 or Radiator1 changes check if Window1 is in state open and Radiator1 is in state on. If they are, publish to any interested component that there is an Energy Waste situation in Room1, involving Window1 and Radiator1.The domain objects we are talking about here are Window1, Radiator1, and Room1. The advantage of this approach is that for the definition of such rules, no knowledge about underlying technologies is needed. It doesn't matter if the radiator is controlled by a BACNet or EnOcean device or what kind of contact sensor is attached to Window1

Figure 5 .

 5 Figure 5. Ontology instantiation

Figure 6 .

 6 Figure 6. Control rules considered for lighting and HVAC systems (Tsp: setpoint temperature, t rec : recovery time).

  Reference room (actual situation)Test room -presence detection -test case 1Test room -presence detection -test case 2 Test room -presence detection -test case

Figure 9 .

 9 Figure 9. Optimized control rules for lighting.

Table 2 .

 2 Summary of the energy savings obtained for different control rules and user behaviour

	Energy savings [%] [(

Energy reference control rules -Energy proposed control rules ) / Energy proposed control rules )]

		Auto on/off + dimm (mixed	Manual on + auto off +	Manual on + auto off +
		user behav.)	dimm	dimm
			(mixed user behav.)	(active user behav.)
	DAUIN single office	16%	39%	71%
	ADMINISTRATIVE office	6%	27%	70%
	DITER office	30%	48%	64%
		Auto on/off	Manual on + auto off	Manual on + auto off
		(mixed user behav.)	(mixed user behav.)	(active user behav.)
	DAUIN open plan office	5%	13%	14%

Acknowledgments

The research is funded by EU, FP7 Collaborative project -2010: Smart Energy Efficient Middleware for Public Spaces.


Edoardo Patti
email: edoardo.patti@polito.it

Andrea Acquaviva
email: andrea.acquaviva@polito.it

Marco Jahn
email: marco.jahn@fit.fraunhofer.de

Ferry Pramudianto
email: ferry.pramudianto@fit.fraunhofer.de

Riccardo Tomasi
email: tomasi@ismb.it

Damien Rabourdin
email: damien.rabourdin@insa-lyon.fr

Joseph Virgone
email: joseph.virgone@insa-lyon.fr

Enrico Macii
email: enrico.macii@polito.it

Event-Driven User-Centric Middleware for Energy Efficient Buildings and Public Spaces

Keywords: Internet of things, Ubiquitous Computing, Ambient Intelligent, Pervasive Computing, event-driven middleware, web services, smart buildings, user-centred development, energy efficiency 1I

In this work, the design of an event-driven user-centric middleware for monitoring and managing energy consumption in public buildings and spaces is presented. The main purpose is to increase the energy efficiency, reducing consumption, in buildings and public spaces. To reach it, the proposed service-oriented middleware has been designed to be event based exploiting also the user behaviours patterns of the people, which lives and works into the building. Furthermore, it allows an easy integration of heterogeneous technologies in order to enable a hardware independent interoperability between them. Moreover, a Heating Ventilation and Air Conditioning (HVAC) control strategy has been developed and the whole infrastructure has been deployed in a real-world case study consisting of a historical building. Finally the results will be presented and discussed.

ing Management System (BMS) to enable a coarse grain control of Heating Ventilation and Air Conditioning (HVAC) and lighting. However, a Smart Building has to react considering the real-time user behaviour in order to provide comfort and save energy as well. To achieve this objective, from one side a finer grain monitoring and control is needed. On the other side, to properly and effectively take user behaviour into account, a user-centric approach would be required.

Pervasive technologies such as Wireless Sensor and Actuator Networks (WSAN) are nowadays available to extend existing BMS to improve monitoring and control granularity. However, to make these technologies actually widespread in public buildings, major challenges remain concerning the development of a suitable middleware complex enough to allow the interoperability of heterogeneous technologies and providing at the same time an effective reaction to environmental events and user behaviour.

In this work we present the design and implementation of an event-driven service-oriented middleware for energy efficiency in buildings and public spaces. The design has its roots in the LinkSmart Middleware, whose basics are presented in [START_REF] Eisenhauer | A development platform for integrating wireless devices and sensors into ambient intelligence systems[END_REF]. LinkSmart design allows an easy integration of heterogeneous technologies and enables a hardware independent interoperability between them. Moreover, it provides software components for implementing building energy management systems on top of these technologies, also exploiting an event-based approach.

The solution proposed in this paper aims to provide a tool for developing user-centric applications. We present a complete and realistic application of the middleware in historical buildings. In the presented case study, particular emphasis has been given to the aggregation and exploitation of occupancy information coming from heterogeneous sources, both hardware and software. Finally, a HVAC control strategy has been developed and deployed in a real-world case study, which consists of a historical building.

The rest of the paper is organized as follows. Section 2 reviews some background literature. Section 3 presents the LinkSmart middleware, which is the basis of the proposed Energy Efficient Middleware described in Section 4. Then Section 5 exposes the HVAC control strategy deployed in the real-world case study described in Section 6. Finally, the obtained results are reported in Section 7.

2R ELATED WORK

Nowadays we are trying to promote a change, which aims to convert our cities into Smart Cities. In Smart Cities reduction of energy consumption and CO2 footprint as achieved by optimizing both the energy and electricity distribution network (Smart Grid) as well as single (smart) buildings and houses [START_REF] Warmer | Web services for integration of smart houses in the smart grid[END_REF].

Recent development of UbiComp, AmI and IoT technologies can help to address this challenge by providing means to seamlessly interact with distributed sensors and actuators. In this context, a key challenge remains to achieve true interoperability between heterogeneous devices. Service Oriented Architectures seems to be promising along this direction [START_REF] Karnouskos | The cooperative internet of things enabled smart grid[END_REF], [START_REF] Warmer | Web services for integration of smart houses in the smart grid[END_REF]. In this work we put this concept in operation by making an historical building a smart one.

In the domain of Home Automation, Corno et al. have developed a Dog home gateway [START_REF] Bonino | The dog gateway: Enabling ontology-based intelligent domotic environments[END_REF], build on the DogOnt v1.0.3 ontology model [START_REF] Corno | Interoperation modelling for intelligent domotic environments[END_REF], for the interoperation between various domotic devices. The ontology is designed to explicit representation of commands, accepted by domotic devices, and notifications, generated by suitable control devices.

Gezer and Buratti present a monitoring application for household or office appliances based on IEEE 802.15.4/Zigbee-compliant devices [START_REF] Gezer | A zigbee smart energy implementation for energy efficient buildings[END_REF]. Their aim is to exploit different kinds of information such as user behaviour, comfort level, utility prices, or energy profiling of appliances.

The AIM [START_REF] Capone | A newarchitecture for reduction of energy consumption of home appliances[END_REF] project focuses on the development of technologies for the monitoring and management of energy consumption in households in real time. Buildings habitants should be able to manage their home networks. For this purpose, selected system functionalities are exposed by means of services to external networks via a gateway. Policy management, device detection and configuration of the system are examples of such functionalities.

Two relevant projects developed with the LinkSmart middleware (earlier called Hydra) [START_REF] Eisenhauer | A development platform for integrating wireless devices and sensors into ambient intelligence systems[END_REF], that we exploited also in this work (see Section 3), are The Energy Aware Smart Home [START_REF] Jahn | The energy aware smart home[END_REF] and EnergyPULSE [START_REF] Jahn | Energypulse: tracking sustainable behavior in office environments[END_REF]. Both of them develop smart energy efficient applications in heterogeneous environments. The Energy Aware Smart Home includes smart metering and control of home appliances combined with novel user interaction applications. EnergyPULSE allows to monitor power consumption of devices and other values (e.g. temperature, presence) in office environments. It aims at providing a basis for new kinds of user-centric feedback systems in such environments.

All the presented solutions take into account limited spaces, such as houses and offices. However, to move towards more complex and large buildings, a broader view is needed. Middleware technologies should implement the abstraction layers required to achieve interoperability also with existing BMS, while effectively supporting adaptation to environmental conditions and user comfort requirements.

The service-oriented middlewares presented in [START_REF] Guinard | Interacting with the soa-based internet of things: Discovery, query, selection, and on-demand provisioning of web services[END_REF], [START_REF] Sleman | Micro soa model for managing and integrating wireless sensor network into ip-based networks[END_REF], [START_REF] Priyantha | Tiny web services: design and implementation of interoperable and evolvable sensor networks[END_REF] and [START_REF] Zamora-Izquierdo | An integral and networked home automation solution for indoor ambient intelligence[END_REF], have treated the interoperability issue. Moreover, Candido et al. [START_REF] Candido | Serviceoriented infrastructure to support the deployment of evolvable production systems[END_REF], [START_REF] Candido | Generic management services for dpws-enabled devices[END_REF], developed a modular, adaptive and open infrastructure forming a complete Service-oriented Architecture ecosystem that will make use of the embedded capabilities. The infrastructure components are specified and it is shown how they can interact and be combined to adapt to current system specificity and requirements. While most of these solutions focus on enabling Ubiquitous Computing and Internet of Things applications, this work targets smart energy efficient buildings and aims to provide re-usable distributed components for integrating Building Automation (BA) technologies with UbiComp.

In [START_REF] Stavropoulos | awesome: A web service middleware for ambient inteigence[END_REF], Stavropoulos et al. present a web service middleware for AmI environment. It allows the interoperability between heterogeneous devices again to provide a system that enables automation and energy savings in large buildings. Their purpose is comparable to our solution, but it differs in the approach. Indeed, our solution aims to provide event-driven and user-centric functionalities.

In addition to research projects, the industry provides a broad range of solutions for energy monitoring, and power measuring, such as Greenbox 1 or The PowerTab 2 . Typically, industrial solutions are proprietary and depend on the peculiar smart meters and sensors used. Some of these solutions are even able to monitor energy consumption at a single device level. All these smart applications are able to manage only the aspect of energy consumption, missing a wider vision about other parameters that can affect the efficiency of the building, i.e. air quality, temperature, etc. OPC Unified Architecture 3 should be noted as an example of an integration effort for typical BA technologies. However, following the vision of UbiComp and AmI, in large buildings it is not enough With respect to previous work, the proposed service-oriented Energy Efficient Middleware aims to enable interoperability between heterogeneous devices, both wireless and wired, in order to enlarge the existing Building Management Systems. Particular emphasis has been given to users that live and work into the building, so we believe that an user-centric fashion is needed. Hence user behaviour patterns must be taken into account to develop efficient control policies that lead to energy savings. To overcome these issue, we have combined occupancy detection with schedule-based control. The proposed middleware has been designed following an event-driven approach by means of the Rule Engine, which is a specific component of the middleware responsible to perform actions when an event is triggered. As a result, eventdriven energy management policies can be developed in an efficient and hardware independent way. The main contribution of this paper is a complete design of a novel smart building middleware and its working implementation of a complete building management system in a real historical building.

3T HE LINKSMART MIDDLEWARE

The coexistence of several Heterogeneous technologies and a lack of interoperability among them is a well-known problem in the worlds of Ubiquitous Computing, Ambient Intelligence, and the Internet of Things. While for classic Building Management Systems (BMS), efforts like OPC UA try to solve these problems by providing abstraction layers, we have to consider that other technologies find their way into the buildings as well. Future smart building systems will be UbiComp and AmI environments that have to deal with multiple, different kinds of devices, applications, and technologies. To cope with these issues of interoperability and be open to future developments, we employ a middleware approach. We start from the open source LinkSmart 4 middleware [START_REF] Eisenhauer | A development platform for integrating wireless devices and sensors into ambient intelligence systems[END_REF], which is a generic service-oriented middleware for Ubiquitous Computing, and further develop it into a middleware for smart energy efficient buildings. This middleware provides reusable and extensible components and concepts for re-occurring tasks and problems in future smart buildings.

LinkSmart provides the developers a set of components (called managers), designed in the fashion of service-oriented architecture. Each manager exposes certain functionality as a Web Service. LinkSmart applications and prototypes have been developed for different application scenarios such as energy efficient smart homes [START_REF] Jahn | The energy aware smart home[END_REF] and office environments [START_REF] Jahn | Energypulse: tracking sustainable behavior in office environments[END_REF]. For the smart energy efficient buildings middleware we 4. http://sourceforge.net/projects/linksmart/ mainly employ and extend the following LinkSmart features and concepts:

• Secure Communication. Web Service calls are routed through the LinkSmart Network Manager, which creates a SOAP tunnel to the requested service endpoint [START_REF] Milagro | SOAP tunnel through a P2P network of physical devices[END_REF]. This concept allows direct communication among all devices inside a LinkSmart network, no matter if they appear behind a firewall or NAT (Network Address Translator).

The LinkSmart addressing scheme allows devices to transparently publish and use services anytime anywhere regardless of network boundaries or fixed service endpoints. Furthermore, LinkSmart provides components for enabling message encryption and trust management [START_REF] Hoffmann | Towards semantic resolution of security in ambient environments[END_REF].

• Event-based Architecture. The LinkSmart Event Manager provides a publish/subscribe service for LinkSmart Web Services. This allows the development of loosely-coupled event-based systems. In smart buildings, where we deal a lot with sensor events, this mechanism is a key requirement to develop systems and applications.

• Proxy. The Proxy is a concept that describes the integration of a specific technology into a LinkSmart application. Simply put, it means abstracting a certain technology, device or subsystem to Web Services and registering it at a Network Manager. A proxy acts as a bridge between the LinkSmart network and the underlying technology. It translates whatever kind of language the low-level technology speaks into LinkSmart Web Services so the low-level technology can be used transparently by any other LinkSmart component. This concept allows us to use each low-level technology transparently inside the LinkSmart network. LinkSmart components can be deployed in centralized or distributed fashion. Thanks to the serviceoriented approach, we have a high degree of freedom when planning a deployment.

4M IDDLEWARE FOR ENERGY EFFICIENCY

The Energy Efficient Middleware, which is built on LinkSmart middleware, consists of three-layered architecture with an integration layer, middleware layer and application layer as shown in Figure 1.

The Integration Layer, which is the lowest layer, is responsible to enable the interoperability between different technologies. The Middleware Layer provides components specifically designed for energy efficient smart building applications, which should support the management of reoccurring tasks. The Application Layer provides a set of applications that make use of the integrated system and information that is available.

The rest of this section describes in more detail all the components for each layer.

Integration Layer

The proposed infrastructure leverages upon an ICT infrastructure made of heterogeneous monitoring and actuation devices, such as Wireless Sensor and Actuator Networks (WSAN). In order to improve backwards compatibility, the infrastructure supports also wired technologies that exploit different protocols, such as BACnet 5 , LonWorks 6 , etc.

The Proxies represents the lowest layer of the proposed Energy Efficient Middleware (Figure 1), which is in charge of enabling the interoperability between heterogeneous technologies exploiting a Web Services approach. Its main purpose is to allow the remote devices' control. Furthermore, it allows the remote reconfiguration of sensor node parameters, such as the sampling rates of monitored physical quantities. Starting from the concept of LinkSmart's Proxy, we extended its functionalities in order to provide flexibility and reliability to the whole infrastructure with respect to possible backbone network congestions or failures. Indeed all the environmental data, coming from the sensor nodes, are first collected into a local database and then pushed into the infrastructure via an event- based approach thanks to the Event-Manager. Figure 2 shows in detail how we develop them. The Proxy can be seen as a software consisting of three sub-layers: i) Device Interface; ii) Local Database and iii) Web Services Interface.

The Proxy runs in a PC and communicates directly with the heterogeneous networks receiving information from various devices, regardless of the adopted communication protocols, hardware or the network topology. Hence, each network needs a dedicated software interface, which is the key to ensure the communication. It interprets the environmental data (e.g. temperature, humidity, etc.) and stores them in the integrated database (DB), which represents the second layer of the Proxy's stack.

As shown in Figure 3, the local database consists of ten tables to store: i) environmental information; ii) end-node hardware and configuration settings; iii) information about the motes' position in the considered rooms. In detail, DataTable collects the environmental measurements coming from the devices. The Measures table lists the types of physical property measures carried by the end-nodes. MoteModels contains the list of deployed commercial devices used for monitoring and controlling. Networks saves the information to identify a device network, such as communication channel and Network name. InfoMotes table contains the list of the configuration settings for all the motes in the networks (eg. sampling time). SensorTypes stores the list of all the possible sensors wired on the adopted end-nodes, and SensorMotes reports exactly what kind of sensors are installed for each mote. The table SensorMeasure shows the association between the sensor and the physical property that it detects. Rooms saves the architectural rooms' features managed by a Proxy. Finally, Positions stores the coordinates, associated to a room, where each device is deployed.

The LinkSmart Web service layer interfaces the device networks to the rest of the infrastructure, making the remote management and control easier. At that layer, the real-time data, collected by devices, are immediately sent to the cloud thanks to the Event-Manager. Particular emphasis was given to the possibility to reconfigure each node, changing, for instance, some parameters about power management. In this scenario, the end-user sends the new configuration via the middleware to the Proxy and stores it in the DB. Then, the new settings will be automatically sent to the receiver device, when it wakes up from the sleeping period, through the specific network software Interface.

Particularly, we have developed different interfaces to manage respectively the following WSANs:

• Plugwise 7 and ST Microelectronics 8 Smart Plug commercial end-node to monitor power energy consumption and to switch on/off the appliances connected to the mains. Both of them exploit the ZigBee protocol;

• Our end-node prototype built on Texas Instruments CC2530 9 system on chip to monitor air temperature and illuminance leveraging the Zig-Bee protocol;

• Crossbow Telos rev. B 10 open source end-node to monitor air temperature, relative humidity and illuminance, which exploits IEEE 802.15.4 communication protocol;

• EnOcean protocol stack 11 commercial end-nodes to monitor air temperature, relative humidity, illuminance, occupancy and to actuate heating and lighting plant, respectively. In addiction, an interface has been developed to allow the interoperability with the OPC Unified Architecture, which incorporates all the functionalities provided by different standards, such as BACnet or LonWorks. Hence, the backwards compatibility with wired technologies is enabled and integrated into our middleware.

Thanks to its modularity based on the Proxies deployment, the proposed Energy Efficient Middleware is suitable for integration and extension of the already existing BMS with new commercial-off-the-shelf sensors and actuator networks.

Middleware Layer

Event-Based Communication

Building Automation systems typically need to react upon events happening in the building. Hence, sensors publish events leading to a certain reaction, such as switching on the light upon an incoming motion event. The LinkSmart Event Manager provides us with the basic functionality of a topic-based publish/subscribe mechanism for LinkSmart Web Services.

As described in the previous section each of our low-level technology proxies publishes sensor events to an Event Manager. These events are typically sensor measurements such as temperature, motion, brightness, power consumption, etc. Each event is published under a certain topic including the id of the sensor it belongs to and contains the measurement and a timestamp. Event topics are based on a hierarchical format providing basic semantic information about the type of event. For example, an event topic for publishing a simple temperature measurement would look like this:

MEASUREMENT/SENSOR/1234/T emperature where MEASUREMENT/SENSOR is an identifier for the type of event, 1234 is the sensor id and Temperature is the type of measurement.

Using this kind of event topic format, software components interested in certain events can subscribe for those. Wildcards can be used for event subscription to subscribe to groups of events. For example, an application that would be interested in all sensor events (like a central persistence application) could subscribe for the topic MEASUREMENT/SENSOR/. *

Occupancy Framework

Occupancy of rooms and spaces, both private and public, has a major impact on defining and assessing efficiency of HVAC and lighting systems in public spaces and building and thus represent a key factor for correct accounting of consumption and its optimization [START_REF] Erickson | Observe: Occupancy-based system for efficient reduction of hvac energy[END_REF]. While a wide number of heterogeneous technologies for measuring or estimating occupancy are available, aggregation and exploitation of occupancy information still remains a challenge. For this reason, the proposed framework includes an Occupancy Framework, as a part of the Context Framework, which is in charge of processing raw occupancy data monitored in the environment, performing processing and fusion tasks [START_REF] Llinas | Revisiting the jdl data fusion model ii[END_REF] and integrate the results with existing context information, so it can be finally used for energy assessment, optimization and forecast.

Occupancy can be observed in real-time using a very large number of heterogeneous sensors [START_REF] Teixeira | A survey of humansensing: Methods for detecting presence, count, location, track, and identity[END_REF] exploiting very diverse mechanisms. It can be observed that the choice of the optimal solution really depends on the specific domain and that more than one technology might be in place in a given environment. For such reason it is fundamental to adopt a single, consistent occupancy model. Within the proposed middleware, the occupancy model is used, on the one hand, to facilitate fusion among different occupancy sources and, on the other hand, to ease handling of occupancy information by applications using the Context Framework.

Fig. 4 provides an overview of the Occupancy model adopted in the proposed Energy Efficient Middleware.

Fig. 4. The occupancy model

The model proposed in [START_REF] Teixeira | A survey of humansensing: Methods for detecting presence, count, location, track, and identity[END_REF] including presence, count, location, track and identity has been initially considered and, based on the initial requirements, simplified to only include parameters which are relevant for energy optimization purposes. While only presence information has been considered sufficient, also the count and identity model has been kept to cope with specific use-cases such as the optimization of crowded rooms or the application of personalized energy set-points based on the identity of present people. To ease processing and fusion of occupancy data, a multi-modal model has been chosen [START_REF] Hofmann | Fusion of multi-modal sensors in a voxel occupancy grid for tracking and behaviour analysis[END_REF]. Presence can be described as P presence i.e. the probability of having at least one person in the selected area. Count C PMF is modelled as a Probability Mass Function (PMF) i.e. a statistical distribution including, for each unit i the probability C PMF (i) that at least i persons are present in the selected area. Identity I is modelled as plain array of all identities, which have been observed in the selected area, each with its presence probability.

Fig. 5 provides an overview of the process followed by the occupancy framework to synthesize occupancy information.

Occupancy-related events are collected from the field by means of proxies, which generate LinkSmart Events carrying raw occupancy readings. In current status support for the following physical sensors is available: PIR (Passive Infra-Red) sensors, US (Ultrasound) sensors, Hall Effect contact sensors. Moreover, occupancy information can be inferred from "Checkin" information (voluntarily provided by users declaring their presence in rooms) and internet-based Timetables configured to store known occupancy schedules of rooms i.e. any web-based calendar using the iCalendar standard [START_REF] Desruisseaux | Internet calendaring and scheduling core object specification (icalendar)[END_REF].

Raw occupancy-related events are processed by a set of Level 1 Occupancy Proxies hosting technology-specific moving-window algorithms suitable to process one or more type of sources and derive a homogeneous occupancy event in terms of (P presence ,C PMF ,I). Such pre-processed occupancy information is further fused on a per-room basis by Room-oriented Occupancy proxies.

Rule-Based Applications

Typical building management functions can be expressed in rules: On a certain event we perform some action. Such rule systems can be more or less complex, depending on granularity, accuracy, etc. Our rule engine provides a set reusable and extensible components and functions that allow a high degree of flexibility.

Figure 6 shows the components of the rule engine: a set of rules, a configuration, and a context. The configuration contains static information needed by the rules. This information is not modified during evaluation of the rules. Modifiable data is kept in a context object. The context is constantly updated during rule evaluation. The rules themselves implement the logic. On an incoming event, rules are processed in an ordered way and produce certain output or action events. Figure 6 shows an example: The EnOcean Proxy notices a motion event by a motion sensor and publishes it to the LinkSmart EventManager, which forwards it to an instance of RuleEngine. The RuleEngine does its processing and publishes an event to set the fan speed of a fan coil to 2 (depicted by fc1 speed=2). The LinkSmart EventManager notifies the EnOcean Proxy to activate the respective fan coil controller. Using this simple yet flexible rule engine we can develop building automation applications on top of whatsoever underlying technology or subsystem.

Application Layer

In the proposed distributed infrastructure (Figure 1), the Application Layer represents the highest layer. It is dedicated to development of distributed event-based user-centric applications in order to manage buildings and post process data coming from the lower layers. At that level the interoperability between different devices is enabled as well as between third-party software.

In order to manage buildings, deployed devices and to promote user power awareness we developed: i) the HVAC Control System ii) an Android App, iii) a WSAN Manager, and iv) a Web Portal.

The HVAC Control System implements the rules described in Section 5 to optimize thermal energy consumptions. First it receives real-time environmental information from the deployed sensors thanks to the Event-Manager, then it post processes them and finally sends the resulting control commands to the actuators.

The Android App is a mobile software suitable for Android Tablets. It has been developed to increase the building awareness and enhance any possible maintenance works providing building information exploiting both Augmented and Virtual Reality. It combines real-time environmental energy information with 3D building models (such as architectural, structural, HVAC and electrical systems).

The WSAN Manager (WMAN) is a Desktop computer software for building manager, which provides a full access to the deployed WSANs. At that layer the staff, thanks to a hardware independent access, can update the devices settings at runtime.

The purpose of the Web Portal is to make the end-user aware about energy consumption and to encourage energy saving by displaying statistics of the collected environmental data coming from the heterogeneous devices through graphs and tables. Furthermore, it allows the user to compare buildings, offices and public spaces. As an extension to the WEP, a mobile application can be used by the users to express their discomfort in a room by voting.

5C ONTROL SYSTEM

The presented middleware allows developing monitoring and event-driven control systems in a serviceoriented way, abstracting from heterogeneous technologies. On the integration layer, technology proxies publish sensor events through the LinkSmart Event Manager. Monitoring and control application subscribe for events, also via the LinkSmart Event Manager. Both, subscribing and publishing is done by Web Service calls to the Event Manager.

The HVAC control system only listens to certain sensor events, relevant for controlling the HVAC system. In the following we describe this HVAC control system. The control strategy is based on intermittent use of the HVAC systems. The economic advantage of intermittent use of HVAC systems in intermittentlyoccupied buildings (e.g. universities, office buildings) is no longer in doubt [START_REF] Fraisse | An analysis of the performance of different intermittent heating controllers and an evaluation of comfort and energy consumption[END_REF]. Our strategy combines schedule-based control with occupancy detection. Schedules are defined for each test room, typically modelling standard working hours, Monday to Friday from 9:00 AM to 6:00 PM with one hour lunch break. Table 1 shows the defined temperature set points for the different periods specified by scheduled and detected occupancy in a room. Depending on the difference between the temperature set point and the actual indoor temperature, the fan speed of the fan coil is selected. In our case studies, fan speed can range from 0 to 3.

To avoid turning on the fan coil in case of a very short period of presence (e.g. a person just entering and leaving an office very quickly) we have included a system of timers, implementing a Timer-based Occupancy Confirmation. After recognizing a positive occupancy event, the system waits for some time before starting up the HVAC. Vice versa, the system waits some time after a negative occupancy event has been recognized before switching off the HVAC.

Another important feature of the HVAC control system is a period of pre-heating after a long period of non-occupancy, e.g. in the morning. To guarantee a comfortable temperature in the morning, the system starts to heat up the room a certain time before the scheduled occupancy starts. The duration differs for each room, depending on its size, walls, exposition, etc. Figure 7 shows a flow chart of the HVAC control strategy for the winter period.

Note that pre-heating is only applied in winter. During summer it is assumed that buildings cool down to a comfortable temperature during the night.

The implementation of the HVAC control strategies is perfectly integrated with the Middleware, based on the Rule Engine as described in section 4.2.3. The HVAC control for each room is independent so that all configuration parameters (e.g. pre-heating period, temperature set points) can be set depending on the characteristics of the room. An implementation of the Rule Engine expects certain input events to act on. For the HVAC control these are occupancy, actual indoor temperature and time. Based on these input parameters and the configuration parameters the Rule Engine calculates the set point temperature and the according fan speed. Fan speed will be published as

6C ASE STUDY

The historical building, which was investigated in this research, dates back to the beginning of the 16th century. This site is approximately 20, 000m 2 . The presence of frescos and the tight walls require a careful placement of sensors and design of the network topology.

In order to verify the system effectiveness, an empirical test has been performed. We chose two rooms as Test Rooms, where the innovative proposed control strategy has been deployed. Simultaneously, we monitored two Reference Rooms, with the same structural characteristics of test rooms. The different rooms chosen cover a good diversity in insulation, thermal inertia, windows areas and internal gains or occupancy. In the reference rooms, fan coils are running from 5:00 a.m. to 8:00 p.m. during workdays and from 6:00 a.m. to 12:00 a.m. on Saturdays. On Sunday and during holidays they are off. Moreover, users are free to change the fan speed from 0 to 3 as they prefer. The rooms were selected to implement and extend the existing Building Management System with new Sensors and Actuators Network infrastructure. The rooms were chosen for case studies based on the following criteria: energy saving potential according to their architecture, services and occupancy characteristics.

The first couple of rooms consists of two Royal Rooms used as private offices. Every room has an area of about 62.40m 2 , a frescoed domed roof with the maximum height of 7.25m and the minimum of 5.70m, and a capacity of 3 working desks. The second couple of rooms consists of two private offices, each of them has an area of about 16.10m 2 , a pitched roof with the maximum height of 3.90m and the minimum of 2.68m, and a capacity of 2 working desks.

In order to enable a finer grain monitoring and management system for the selected environments, it has been installed the following devices:

• to detect the users presence • to monitor fan-coil internal air temperature;

• to control the fan-coil set points and fan speeds;

• to monitor the indoor air temperature and to control the fan-coil. While in the Reference Rooms the users can use it to change the fan speed autonomously as they prefer. Instead in the Test Rooms it acts only as temperature sensor and the control commands have been disabled; In order to extend the existing systems in the historical building, we adopted wireless devices mainly based on EnOcean technology, which are configured as mesh networks.

7R ESULTS

In this Section we discuss the results about the HVAC control system (see Section 5) deployment in the realworld case study, introduced in Section 6.

The deployment of the whole Energy Efficient Middleware and the new heterogeneous devices begun in December 2012. The first step consisted of a monitoring only phase to collect environmental data. Then, we gradually puts in the selected rooms more technologies in terms of sensors and actuators. In the historical building the first HVAC control experiments comes back to January 2013. Then, the deployment of control strategies, as described in Section 5, has been started on February 19th. Hence results about both heating and cooling are discussed.

During the test, particular emphasis has been given to user comfort. In fact the absolute value of the difference between indoor air temperature in reference and test rooms is lower than 1 • C, so discomfort is not perceived by users.

Energy Metrics

Before discussing results, we introduce here the metric adopted to evaluate relative energy savings between reference and test rooms.

The first parameter is Q v,i , which is the air flow of the fan coil for each speed i. It is obtained from the formula:

Q v,i = Q v • p i (1)
with Q v the maximum air flow of the fan coil in kg/s and p i the air flow in % in relation to fan speed (cf. Table 2) Furthermore knowing the following parameters: i) fan coil temperature, ii) fan speed, iii) fan coil air flow, iv) indoor temperature, and v) air heat capacity (i.e. a constant in our case), we can estimate the instantaneous power at each time step of the fan coil with the following formula:

P (t)=Q v,i • C p • (T f (t) -T i (t)) (2)
with P (t) power of fan coil in Watts, Q v,i the air flow at each time step in kg/s, C p the air heat capacity in J/kg/K, T f the fan coil temperature, and T i the indoor temperature at each time step. Hence, the energy consumption are calculated as:

Econs = day P (t)dt (3)
Finally, the relative energy savings are given by:

Esaved = Econs ref -Econs test Econs ref (4)

Runtime Observations

Figure 8 reports the results about the Royal Rooms (see Section 6) on 12th March 2013. It shows observations and differences between reference and test room. On this day, fan speed has been on 1 in the reference room all day long. From interviews with the occupants we know that they tend to keep the fan coil running almost all time and rarely change the speed. Figure 8(a) shows the fan speed and occupancy pattern. From the 7:00 AM to 8:00 AM, we can observe the pre-heating phase. It starts even if there is no presence detected in the room and switches on the fan-coil on fan speed to 2. Then, from 9:00 AM to 6:00 PM, the HVAC control system starts working taking into account the users' presence in the room. The occupancy data in Figure 8(a) shows post-processed data from the motion sensor deployed in that room. It shows the occupancy after applying the Timer-based Occupancy Confirmation. Moreover, we can observe that the control system turns off the fan-coil when the Indoor Temperature reaches the set point defined in Table 1. Finally Figure 8(c) shows the different patterns of fan-coil activity, expressed in fan coil temperature, in both rooms, reference and test. Instead, Figure 8(d) reports the energy consumption P (t) calculated following the formula 2 for both reference and test rooms. While the fan coil in the reference room stays at the same speed during the whole day, we can see the changes based on our control strategy in the test room. The comparison indicates the potential energy savings: i) during sunrise, between 5:00 AM and 7:00 PM; ii) in the evening, among 6:00 PM and 8:00 PM; iii) during non-occupied periods throughout the day, thanks to the combination of occupancy schedule and occupancy detection.

In conclusion, for the analysed working day the energy consumption in the reference rooms, Econs ref , was about 1.23 kWh, however the Econs test was approximately 0.84 kWh. Hence, ensuring the same comfort to the users, the relative saving was about 30%.

Energy Savings

Table 3 presents the results about Heating strategy performed in the private offices during one selected week, 4th -8th March. Both rooms were unoccupied from Monday to Wednesday. It worth emphasizing that in the reference room the users can change the fan speed autonomously as they prefer. Even if the results show that in the reference room users turn on the fan-coil responsibly, there are consumption, ranging between 0.01 kWh and 0.33 kWh, that are saved in the test room. On Thursday the test room was occupied all day long, while the reference was still unoccupied, wasting again 0.19 kWh. Finally on Friday both rooms were occupied and thanks to the HVAC control strategies it has been saved almost 0.548 kWh delivering the same comfort. Indeed the difference between indoor air temperature in reference and test rooms is lower than 1 • C. Table 4 reports the results about the Cooling strategy deployed in the same private offices. Specifically, it has been selected three days in July, the hottest, the cooler and a normal day. During the hottest day, in the reference we recorded 7.53 kWh and in the test 1.60 kWh, thus obtaining a savings of about 79%. However, during the cooler day, which was cloudy, the energy waste was reduced about 82%. Finally,

8C ONCLUDING REMARKS

In this work the Energy Efficient Middleware has been described, which aims at improving energy efficiency of public buildings and spaces exploiting both eventdriven and user-centric approaches. Moreover it allows interoperability among heterogeneous devices, both wireless and wired. Hence, exploiting the proposed middleware, the combination of different technologies, both existing and emerging, can be easily achieved.

The various middleware layers and the applications developed on top of it have been described. Moreover a HVAC control strategy has been implemented and the results about its real-world deployment have been discussed, which indicate that energy savings has been achieved.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Software Infrastructure

Fig. 3 .

 3 Fig. 3. Local Database scheme.

Fig. 5 .

 5 Fig. 5. Occupancy Framework overview

Fig. 7 .

 7 Fig. 7. HVAC Control Strategy an event to activate the respective fan coil controller.

Figure 8 (

 8 Figure8reports the results about the Royal Rooms (see Section 6) on 12th March 2013. It shows observations and differences between reference and test room. On this day, fan speed has been on 1 in the reference room all day long. From interviews with the occupants we know that they tend to keep the fan coil running almost all time and rarely change the speed.Figure8(a) shows the fan speed and occupancy pattern. From the 7:00 AM to 8:00 AM, we can observe the pre-heating phase. It starts even if there is no presence detected in the room and switches on the fan-coil on fan speed to 2. Then, from 9:00 AM to 6:00 PM, the HVAC control system starts working taking into account the users' presence in the room. The occupancy data in Figure8(a) shows post-processed data from the motion sensor deployed in that room. It shows the occupancy after applying the Timer-based Occupancy Confirmation. Moreover, we can observe that the control system turns off the fan-coil when the Indoor Temperature reaches the set point defined in Table1.Figure8(b) relates the Indoor Temperature with the Set Point, as defined in the HVAC control strategy (Table 1), and the office Occupancy. We can observe how the defined Set Points variation successfully affects the Indoor Temperature trend as required. Moreover, we can note how the Timer-based Occupancy Confirmation influences the Set Points variation. Indeed during the day, the office is unoccupied several times for short periods but the Set Point is constant at 23 • C. It changes from 23 • C to 20 • C from 2:00 PM to 2:30 PM because of lunchtime and then from almost 3:30 Pm to 3:55 PM.

Fig. 8 .

 8 Fig. 8. Royal Rooms runtime observationsduring a normal day, the average energy savings is around 50%. Even during these tests, it has been ensured the same comfort to the users in both rooms.

TABLE 1

 1

		Set Point Selection
	Scheduled	Occupancy	Set Point ( • C)
	Occupancy	Detected	Winter Period	Summer Period
	True	True	23	26
	True	False	20	29
	False	True	23	26
	False	False	6	35

TABLE 2 Air

 2 Flow per Fan Speed

	Fan Speed (i)	Air Flow (p i )
	3	100%
	2	80%
	1	60%
	0	0%

TABLE 3 Heating

 3 Savings on historical building private offices

	Day	Cons. on ref. Cons. on test	Savings
		room (kWh)	room (kWh)	(kWh)	(%)
	Monday	0.14	0.00	0.14	100%
	Tuesday	0.01	0.00	0.01	100%
	Wednesday	0.33	0.00	0.33	100%
	Thursday	0.19	1.20	-1.01	-518%
	Friday	0.98	0.432	0.548	57%

TABLE 4 Cooling

 4 Savings on historical building private offices

	Day	Cons. on ref.	Cons. on test	Savings
		room (kWh)	room (kWh)	(kWh)	(%)
	Hottest	7.53	1.60	5.93	79%
	Normal	2.38	1.14	1.24	52%
	Cooler	0.94	0.17	0.77	82%