Gérôme Bovet
email: gerome.bovet@telecom-paristech.fr

Jean Hennebert
email: jean.hennebert@unifr.ch

Ltci

Distributed Semantic Discovery for Web-of-Things Enabled Smart Buildings

Keywords: Smart buildings, Discovery, Semantics, Ontologies

Nowadays, our surrounding environment is more and more scattered with various types of sensors. Due to their intrinsic properties and representation formats, they form small islands isolated from each other. In order to increase interoperability and release their full capabilities, we propose to represent devices descriptions including data and service invocation with a common model allowing to compose mashups of heterogeneous sensors. Pushing this paradigm further, we also propose to augment service descriptions with a discovery protocol easing automatic assimilation of knowledge. In this work, we describe the architecture supporting what can be called a Semantic Sensor Web-of-Things. As proof of concept, we apply our proposal to the domain of smart buildings, composing a novel ontology covering heterogeneous sensing, actuation and service invocation. Our architecture also emphasizes on the energetic aspect and is optimized for constrained environments.

I. INTRODUCTION

With the evolution achieved in pervasive computing during the last years, sensors, actuators, mobile devices and smart appliances have become ubiquitous. We are nowadays able to find them in many application scenarios, ranging from small wireless sensor networks like weather monitoring up to big-sized networks like smart buildings and even smart cities composed of ten thousands of such devices. Due to their dynamics, devices can appear and disappear in a short period of time, move to another location and even be reassigned to other purposes. In this context, composing physical-centred applications represents a quite huge challenge as developers must first gather knowledge about what the physical world can offer to them. This problematic also applies to machine-tomachine communications where physical mashups are realized by devices themselves with no prior knowledge or human intervention. For example, a motion sensor could discover some eligible partners to form a specific use case as someone enters a room by switching lights, moving the blinds and activating the heating. Such a behaviour not only increases the human comfort but also participates to the ecological and economical trends of saving energy in buildings. To attain such a strategy, This paper has been accepted for publication in the proceedings of SmartCity'2014 Workshop that had been held in conjunction with NTMS'2014. a service and discovery infrastructure is needed, connecting sensors and actuators to form an homogeneous overlay where they will communicate their capabilities and intentions in well-understood machine-processable formats. Reaching such an interaction style thus allows an interconnection between various manufacturers and different device types.

Up to now, the worlds of the Web and sensor networks, especially building automation systems (BAS) were isolated from each other. As a consequence of this segregation, automatic discovery is difficult to achieve, and requires a human in the loop to find, aggregate, and use information from both worlds. The HTML language and HTTP protocol appear as key-enablers of an homogeneous application layer relying on different hardware platforms and software components. Augmenting sensors and BAS with Web capabilities in form of lightweight Web services ensuring interoperability has already been proposed for the well-spread KNX and Enocean building automation standards [START_REF] Bovet | Offering web-of-things connectivity to building networks[END_REF]. However, those technologies, while relying on Web service standards, do not cover the automation of discovery, composition and invocation of Web services [START_REF] Sapkota | Peer-topeer technology usage in web service discovery and matchmaking[END_REF]. To solve those shortcomings, the Semantic Web [START_REF] Bermers-Lee | The Semantic Web[END_REF] pushes open technologies for enabling operations with as less human intervention as possible. Although this concept paved the way for semantic augmented things, some issues relative to the dynamic aspect of sensor networks and to their energy efficiency remain open.

In this paper, we propose a fully distributed Web service discovery architecture that is designed to be robust, reliable and energy efficient. It relies on the paradigm of the Web-of-Things (WoT) where every device capability including discovery is represented as a Web resource [START_REF] Guinard | A web of things application architecture -integrating the real-world into the web[END_REF]. Following this approach makes our discovery architecture loosely-coupled, providing primitives for publishing and discovering Web services. From a scalability and adaptability point of view, our proposed architecture can be adapted to any kind of ontologies and even description languages. In order to improve interoperability between devices, we developed an ontology not only describing device capabilities but also method invocation mechanisms. The descriptions are presented by following the RDF best practices [START_REF] Klyne | Resource description framework (rdf): Concepts and abstract syntax[END_REF]. We argue this choice by leveraging on its semantic richness allowing an automatic composition of Web services in M2M applications. Working in the context of smart buildings where the final aim is to save energy, a particular attention is given to the energetic impact of our discovery architecture.

This paper is organized as follows. The next section refers and summarizes related works. In Section III, we provide a list of requirements that a discovery architecture for smart buildings must fulfil. Section IV introduces the ontology we composed for improving interoperability. The distributed Web service discovery architecture is described in Section V. A reference implementation is provided in Section VI. Finally, Section VII concludes our paper and provides insights on further research.

II. RELATED WORK

Many XML schemas and other data models were developed trying to describe processes and physical environments [START_REF] Group | Review of sensor and observation ontologies[END_REF]. The Semantic Sensor Network Ontology (SSN) is based around concepts of systems, processes and observations [START_REF]Semantic sensor network ontology[END_REF]. It supports the description of the physical and processing structure of sensors. However notions of units and locations are not part of it but can be completed by including other ontologies like the DOLCE Ultra Lite (DUL) [START_REF]Dolce ultralite ontology[END_REF]. A concrete application of semantics to building automation systems has been proposed in [START_REF] Jung | A transparent ipv6 multi-protocol gateway to integrate building automation systems in the internet of things[END_REF].

Augmenting simple Web semantics with discovery capabilities has already been explored in several projects. The notion of shared space centralizing RDF descriptions of a logical entity was introduced in [START_REF] Sapkota | Distributed web service architecture[END_REF]. Queries are performed by the client providing RDF triples in a HTTP request following the REST architectural style that will be applied to the RDF descriptions of the Web services. Pushing this concept further, SPITFIRE takes advantages of SPARQL, a language especially conceived for querying RDF descriptions [START_REF] Pfisterer | Spitfire: toward a semantic web of things[END_REF] [START_REF] Prud | Sparql query language for rdf[END_REF]. Unicast CoAP discovery requests are sent to a repository where RDF descriptions are stored [START_REF] Shelby | Constrained application protocol (coap)[END_REF]. This approach requires a service announcement mechanism by service providers. It also offers a possibility to look up for devices that are in a particular state. In this approach, dynamic properties like state values are probabilistically inferred from past data. Although it provides a way for filtering Web services according to dynamic properties, uncertainty remains about the real state so that the query could respond with false positives. Our work is based on the concepts introduced by SPITFIRE. We enhance it with a new ontology describing services invocations. We also complete it with a new architecture taking account of real state values instead of predictions. Finally, we propose best practices for limiting the number of network packets and thus reduce the overall energy consumption.

III. REQUIREMENTS FOR SMART BUILDINGS

For building automation systems an extension from simple discovery to query is required. We can list a minimal set of requirements for a discovery architecture in the context of smart buildings:

(1) Optimized for constrained devices -Smart buildings are composed of IP-enabled sensors and actuators relying on electronics offering only few computational power. Other equipments based on KNX, BACnet or EnOcean technologies are typically not IP and will require light gateways to expose the services in the IP world.

(2) Plug-and-play installation of devices -Devices should be integrated in the existing architecture with no human interaction.

(3) Discovery of the entire network -For management purposes, an overview of the entire network should be retrievable in a simple manner. (4) Selection of devices according to some contextual parameters -Contrarily to classic pervasive environments where only static parameters are needed for looking up specific services, a more dynamic approach is necessary in the context of smart buildings. This aspect is further explained in this section.

(5) Scalability and fault tolerance in energy efficient context -A scalable architecture is required as networks in smart buildings will evolve over time, including new devices, themselves running under new technologies. Fault tolerance is also required considering the applications in buildings such as access, lighting, heating, etc. Such requirements are further discussed in the context of having an energy efficient technology.

A. Web Service Discovery Models

Several discovery models already exist and can be applied to our scenario. We here depict the most widespread ones and argue which one should be used for smart buildings.

Static service discovery is available since the beginning of the Web. In this scenario, descriptions are stored locally on the endpoints and do not change over time. In the centralized discovery approach, discovery repositories store descriptions announced and published by endpoints. Discovery requests are sent to the repositories instead of the service endpoints. The model where a distributed approach is used rather than central repositories is called dynamic. Infrastructures following this approach are usually leveraging on P2P, data federation or are agent-based [START_REF] Zhu | Service discovery in pervasive computing environments[END_REF]. In order to fulfil requirement 5, we opted for a decentralized model in our infrastructure. This choice is argued by the various features that are provided by this model, such as scalability, reliability, and no single point of failure.

Regarding the filtering stage, it can be performed at two different locations. A first naive manner is to empower clients with this responsibility. Any device present on the network will respond with its description to the client, that will in a second step process all responses to find matches. The second approach can be considered as more optimized in terms of network traffic, as query processing is delegated to the service endpoints. Only Web services having a description matching with the query parameters will respond to the client. In our architecture, we decided to follow the latter option as it is compliant with requirement 5 concerning the energetic impact.

B. Concept of a Sensor's Context

The context of a device or a Web service is decisive during discovery. Many building management systems have to look for devices being in a certain state or context for regulation or alarming purposes. For example a building management system (BMS) could search for temperature sensors on the ground floor having measured in the last five minutes a value above 25 • C. This request must also consider devices that have not yet reported and are not known by the system. Relying on a plug-and-play approach allows to have highly dynamic systems requiring no previous knowledge of the available resources. We introduce here the concept of static and dynamic resources properties as illustrated in Fig. 1, which allows us to comply with requirement 4. Static properties will not or rarely vary over time, while dynamic ones are subject to frequent changes. Although the ontology includes many aspects for describing intrinsic sensor properties, the related Web services for interacting with devices capabilities are not covered. This situation leads to incompatibilities between devices as a client has no clue about how to consume a Web service. Let us illustrate this with a switch that has to bind with a relay for controlling lighting in a room. Following the proposed discovering principle in SPITFIRE, it will be able to know that there is a light relay in the specific room. However this is not enough when composing mashups as the client should also have knowledge about the Web service's properties (e.g. transport protocol, allowed parameters and their range, return value, etc.). Based on this observation, we can argue that an ontology should also include knowledge for describing properties of Web services and how to consume them. We therefore propose a new ontology that we motivate in the remainder of this section. An example of our proposal is given in Fig. 2.

A. Device Properties

The device properties that are responding to the question "what does the resource offer?" are split into three different categories as follows: (1) Sensor types are expressed using the SSN ontology and extended to include any device type that can be present in a building automation system (represented in blue). (2) The location information is indicated by relying on the DUL ontology that provides a vocabulary for expressing components of a building (i.e. room, floor, building, etc.) (represented in orange). (3) The value types and formats are described by selecting the appropriate datapoint (represented in pink). In BAS, datapoints represents endpoints for a specific value.

B. Gates

The description of the procedure to consume a Web service is given through gates (represented in green). We here rely on the concept of RESTdec proposing a semantic facilitating service consumption between devices [START_REF] Verborgh | Efficient runtime service discovery and consumption with hyperlinked restdec[END_REF]. Each service owns a description of which protocols it supports (e.g. HTTP, CoAP, FTP, etc.), allowing a client to select the most appropriate one. The method that has to be used for consuming the service is also given by the ontology. The URI for accessing the service is decomposed in multiple parts especially regarding the parameters. Their name and location inside the URI are specified. Finally, the media type of the payload and response are defined by the ontology which allows a client to have knowledge about how to parse a response. Those properties are sufficient for a client to automatically compose a requests and thus allows an inter-compatibility between various technologies.

V. SEMANTIC WOT DISCOVERY AND COMPOSITION

Following the paradigm of the Web-of-Things, each device represents its capabilities in terms of Web resources that are accessible though a RESTful API. As this approach comes with many advantages like being loosely-coupled and compatible with current Web standards, there is only a small footstep from enhancing the WoT with semantic discovery. In this Section we describe the main three components necessary for building a semantic WoT, which are (1) augmenting sensors with semantic descriptions, (2) providing a querying mechanism for retrieving knowledge, and finally (3) automatically building mashups between different device types.

A. Sensor Semantics

In a vision of a semantic Web, each resource has to be described with semantics in order to achieve interoperability. As previously explained, this is realized by forming RDF descriptions using a vocabulary provided in a shared ontology. Listing 1 shows a RDF description excerpt (only the device property part) of a temperature sensor. When considering a resource providing only static properties, the RDF description can be built at resource creation and will remain valid until the resource stops existing. Regarding resources that involve dynamic properties like it is the case for most sensors, the RDF description has to be up-to-date with the actual status of the resource. Instead of holding internally a RDF document that has to be updated each time a dynamic property changes, we propose to build this document upon request when a client retrieves the description. This way of functioning lessens the required memory space and computing power. Assuming a client already knows the existence of a Web resource or has just discovered it, it needs to retrieve the RDF description in order to be able to understand what it provides and how to communicate with it. Different scenarios can be conceived depending on the application protocol used. A first approach consists of using a special code in the request indicating one wants to access the description of the mentioned resource. We can illustrate this principle when using HTTP by setting the method to OPTION, as proposed by [START_REF] Verborgh | Efficient runtime service discovery and consumption with hyperlinked restdec[END_REF]. Unfortunately the CoAP protocol does not provide the OPTION method. Additionally, CoAP having a very tightened header, there is no possibility to set a specific flag inside a request. To cope with this problematic, we consider RDF documents as a sub-resources that can be accessed with a GET request. By putting a special placeholder at the end of the URL pointing to the Web resource, one indicates its intention to retrieve the related description.

B. Querying for Resources

Having linked Web resources with RDF semantic description, discovery agents are now able to query resources. To comply with requirements 2, 3 and 5, we opted for a decentralized architecture leveraging on multicast queries. Using multicast for sending queries through the network allows, with no prior knowledge of the infrastructure, to reach any device providing descriptions. Furthermore, multicast reduces the energy impact as only one packet is sent by the discovery agent, whereas other discovery architectures based on unicast will have much more impact on the energetic aspect. Only sensors having resources matching the query will respond to the request, which also limits the network traffic.

As every WoT device embeds a Web server, we enhance it with a new service that will be responsible for responding to discovery queries. Any device offering discovery capabilities will thus expand its API (e.g. coap://233.67.1.26/discover) with a new service bond to the multicast group which is either preconfigured or obtained from an auto-configuration system.

Finally, the discovery agent will express the query using the SPARQL language that will be placed as payload inside the request. Queries can range from very simple ones resulting in the discovery of the entire network or contain restraining properties which will limit the scope of results. A major advantage of combining RDF documents and SPARQL is that a client can specify what kind of property it wants as result (e.g. the URL to the resource, the actual value, the device model, etc.). This allows a new interaction style where, using only one request, different kind of return values can be expected. For example, a building management system could look for rooms where the temperature is above a certain value by specifying in the SPARQL that it wants to have only the location of the sensor as result and does not care about the URL for accessing the resource or other properties. Listing 2 provides an example of a query seeking for temperature sensors located in the kitchen.

Listing 2. Example of a SPARQL query to look after temperature sensors with a value higher than 25

C. Automatic Composition of Mashups

The ultimate aim of semantics is to automate interaction and composition between various applications. In the same perspective, sensors can benefit from semantics by being able to discover potential partners and to build mashups automatically with no human in the loop. Since our proposed ontology not only describes resources properties but also so-called gates, we open the path for a new self-composing sensor network. In classical approaches, administrators or developers are required to manually link devices with each other following a preconfigured and non-scalable interaction mechanism (i.e. chose between HTTP or CoAP, available parameters, their position and meaning). From now on, scenarios where a new sensors can integrate itself in an existing environment by discovering neighbours are possible. For example, an illumination sensor being responsible for the whole lighting will send a query to discover potential partners in the same room. Since each device describes its gates, the illumination sensor will know how to register for presence notifications on the presence sensor and how to turn the light on or off and also to drive the blinds.

VI. IMPLEMENTATION

In order to demonstrate the feasibility of our proposed architecture, we developed a prototype implementation based on Java technologies running on several Raspberry Pi. The scenario introduced in Section V-C served for validating our approach of automatic mashup composition. The architecture of our reference implementation that is further depicted in this Section is illustrated in Fig. 3.

We opted for jcoap as base implementation for CoAP [START_REF]jcoap[END_REF]. As at the time of writing this paper no implementation offered multicast support (CoAP group communication), we enhanced jcoap with this new functionality for the server and client Going one level down in the server, the discovery and query engine is responsible for evaluating requests and finding corresponding matches. It starts with a SPARQL request extractor that will take out the query from the CoAP messages and perform some validations regarding the format. Once the request is considered as well-formed, it is passed to the querier. This module will gather the RDF representations of all the resources present and available on the device. Once the collection complete, the SPARQL query is applied to each RDF representation of the collection. Each match is then stored in a collection of results. If the collection of results is empty after querying, the process can stop at this step. Otherwise, the collection is forwarded up to the JSON formatter. This module iterates through the results collection and formats SPARQL responses to JSON. The last step consists of responding to the client over the CoAP interface with the results. All this part is handled by using the OpenRDF Sesame framework providing a Java API for processing SPARQL queries [START_REF]Openrdf sesame[END_REF].

Finally, the Web resource has to provide its entire description in form of a RDF document. Each time the description is retrieved by either a remote client or internally by the query engine, this module will collect the actual state of dynamic properties and place them inside the RDF document. According to a format parameter value, the description can either be returned in standard XML, JSON or Turtle N3.

VII. CONCLUSION AND FUTURE WORKS

It is likely that the combination of ontologies and semantics will play a key role in the field of sensor networks. They indeed pave the way to a homogeneous global intercompatible network whereas current installations form small islands isolated from each other. The main advantage of semantic descriptions resides in being resource oriented which fits with the concept of the Web-of-Things where every device capability is represented as a Web resource accessible over a RESTful API. Semantically augmenting things not only exposes their properties to the rest of the world but also allows a new query mechanism facilitating mashup composition. The need for a human in the loop is greatly reduced, converging to totally autonomous networks.

In this paper we showed our vision of semantics applied to sensor networks with a particular emphasis on smart buildings. Unlike the approach taken in SPITFIRE where dynamic properties are inferred from statistical data, our system considers the real state of a property avoiding false positives. Our enhanced ontology adds the vocabulary for describing gates and thus enables an automatic consumption of services. Future developments intends to make the architecture compatible with very constrained devices that can not run a Java application and also to even more reduce the energy impact. The security aspect is also an important concern that has to be solved in the near future.

!Fig. 1 .

 1 Fig. 1. Static and dynamic properties of a resource

Fig. 2 .

 2 Fig. 2. Excerpt of the proposed ontology dedicated to building automation systems

Fig. 3 .

 3 Fig. 3. Modules composing the client and server discovery architecture

  • Celsius located in the kitchen @prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn> .

	SELECT ?node WHERE {
	?node a ssn:Sensor ;
	ssn:observes <http://purl.oclc.org/NET/muo/ucum/physical-
	quality/temperature> .
	dul:hasLocation "kitchen" ; rdf:value ?lv ; FILTER (?lv > 25) .
	}

ACKNOWLEDGMENT

The authors are grateful to the Swiss Hasler Foundation and to the RCSO grants from the HES-SO financing our research in this exciting area of smart buildings.


Gérôme Bovet

Antonio Ridi

Jean Hennebert

Toward Web Enhanced Building Automation Systems

The emerging concept of Smart Building relies on an intensive use of sensors and actuators and therefore appears, at first glance, to be a domain of predilection for the IoT. However, technology providers of building automation systems have been functioning, for a long time, with dedicated networks, communication protocols and APIs. Eventually, a mix of different technologies can even be present in a given building. IoT principles are now appearing in buildings as a way to simplify and standardise application development. Nevertheless, many issues remain due to this heterogeneity between existing installations and native IP devices that induces complexity and maintenance efforts of building management systems.

A key success factor for the IoT adoption in Smart Buildings is to provide a loosely-coupled Web protocol stack allowing interoperation between all devices present in a building. We review in this Chapter different strategies that are going in this direction. More specifically, we emphasise on several aspects issued from pervasive and ubiquitous computing like service discovery.

Finally, making the assumption of seamless access to sensor data through IoT paradigms, we provide an overview of some of the most exciting enabling applications that rely on intelligent data analysis and machine learning for energy saving in buildings.

Introduction

In the last decade, we have become more and more concerned by the environmental dimension resulting from our behaviours. Further than the ecological trend, the interests are also economics-centred due to the raising cost of the energy. Representing 20% to 40% of the global energy bill in Europe and USA, buildings are a major source of energy consumption, actually more important than industry and transportation [START_REF] Perez-Lombard | A review on buildings energy consumption information[END_REF]. In a building, half of the energy consumption comes from the Heating, Ventilation and Air Conditioning systems (HVAC), followed by lighting and other electrically operated devices. In offices, HVAC, lighting and electrical appliances together reach about 85% of the total energy consumption.

For these reasons, the reduction of building energy consumption has become an important objective. Many works are currently undertaken towards renovation and improvement of building insulation. The other facet is to leverage on energy efficiency that involves better usage of HVAC equipment taking into account local production and storage capacity as well as temporal occupation of the rooms. In simplified terms, the aim is to optimize the ratio between the energy savings and user comfort.

This objective requires a clear move from state-of-the-art conventional building automation systems to advanced information systems leveraging on (1) a variety of interconnected sensors and actuators, (2) a unified management of heating, lighting, local energy production or storage and (3) data modelling capacities to model room usage and predict user comfort perception.

Most automated buildings are currently working with dedicated building networks like KNX [START_REF]Knx association[END_REF] or EnOcean [START_REF] Enocean | [END_REF]. These networks are specifically conceived for the purpose of building automation, including all layers of the OSI model starting from the physical to the application one. In such settings, a central Building Management System (BMS) is typically connected to the network and manages the equipments by implementing the operation rules of the building.

In many buildings, we observe the coexistence of different network technologies, often caused by the installation of new equipments answering specific physical constraints, for example wiring or power supply. The protocols are often relying on proprietary layers and this heterogeneity actually leads to two situations. In the first one, several BMS are coexisting and share the management of independent equipments, making difficult any global optimisation. In the second one, a unique but more complex and costly BMS is used where bridges to the different protocols are integrated. Without prejudging on the strategies of technology providers, we can reasonably converge to the fact that there is a lack of standardisation in building automation systems, at the network level and, probably more importantly at the application level. BMS could largely benefit of a common protocol stack compatible with any device.

Thanks to the miniaturization of electronics and increasing computing power, devices offering native IP connectivity are appearing. Sensor networks based on 6LoWPAN or Wi-Fi are nowadays in competition with classical building networks. Everyday objects are now able to connect to IPv4 and IPv6 networks, offering new functionalities like machine-to-machine communications. This has led to the emergence of Internet-of-Things paradigms (IoT), a research field trying to find answers in how to connect objects to the Internet from the network point of view, i.e. covering the first four layers of the OSI model.

Going up to the application layer, the heterogeneity problem is even worse as there are currently no strong standards defining the semantic of the building resources, i.e. an expression of device and service capabilities. The paradigms of the Web-of-Things (WoT), which can be viewed as the natural extension on top of the Internet-of-Things, are here proposing to rely on web application standards. Arguably, these standards are more like a set of best practices than real standards. In the vision of IoT and WoT, any device embeds a Web server offering lightweight Web services for interaction. The Application Programming Interfaces (APIs) of the services often rely on RESTful principles, providing natural ways to embed the semantics in the communication protocol.

In this Chapter we will present the actual state-of-the-art in the field of IoT in smart buildings, putting into evidence remaining ongoing challenges. Some propositions overcoming open problematic will be discussed, especially regarding the integration of existing building automation systems in the core IoT and their respective discovery. Finally, making the assumption of a building where IoT paradigms are fully integrated, we will provide an overview of some enabling applications that rely on data analysis and self-learning algorithms for energy saving in buildings.

Integrating Building Automation Systems in the IoT

Many new or renovated buildings are nowadays equipped with automation networks. We can here mention office buildings, factories and even private households. The relative high investment costs have an impact on the payback period which is rather high, often around ten years. A sudden change of technology is therefore not conceivable. We envision here the IoT as adapting itself to existing installations and thus encouraging a smooth transition until building automation systems natively support it. Meanwhile, a mix of different technologies will probably coexist in buildings.

In this section, after reviewing existing building automation systems and technologies, we propose a Web-oriented protocol stack able to solve the heterogeneity problem between sub-systems. Concrete application scenarios will serve as basis of discussion.

Related Work

Historically, buildings are equipped with networks especially designed for automation purposes and offering services tailored to buildings. We can here mention sev-eral technologies like BACnet, LonWorks, KNX and EnOcean. The physical mediums are typically not restricted to certain types, like KNX can support twisted pair, RF, power line and even Ethernet. Because of the custom protocols used for the transport and networks layers, it is not conceivable to shift the application layer to a more common network like IPv6. Some works have proposed to rely on multiprotocol devices [START_REF] Granzer | Gateway-free integration of bacnet and knx using multi-protocol devices[END_REF]. The drawback of this approach resides in the integration cost of such devices that are, anyway, quite non-existent on the market. Another solution consists of providing gateways. As illustrated in Fig. 1, gateways can operate according to two modes, a N-to-N protocol mapping or a N-to-1* approach mapping all sub-systems to only one central protocol. The 1* refers to a new protocol stack suited for IoT interactions. In the N-to-N case, gateways between BAS translate telegrams from the originating network to its destination. Those gateways have knowledge about each protocols composing the stacks of each network. Although this approach solves the heterogeneity across networks, it induces some limitations. First, it is possible that not all capabilities of a BAS can be mapped to another one, thus restricting functionalities. Secondly, this approach requires n * (n-1) 2 mappings between BAS, representing a considerable effort. In contrast to the N-to-N approach, the N-to-1* one considerably simplifies the number of gateways needed to n by introducing a common technology. The key challenge resides in the 1* technology where no standard is currently defined. Its components have still to be identified, according to Internet-of-Things constraints. A remaining decision has to be taken when integrating BAS into the IoT regarding the gateway position in the network. There are two extremes, either centralizing the services on a single node, or migrating them as close as possible to field devices. Centralizing the access at a backbone server brings some advantages in terms of maintenance, even if scalability problems may arise. Putting the services at the field level requires devices with more computational power but allows a direct native interaction between sensors and actuators with Web services over IP. More specifically, we can describe four different integrations styles, as illustrated in Fig. 2. 1. On a centralized server: this approach is currently the most used one where a server at the IP backbone handles all the interaction with the BAS. It allows an integration into enterprise systems. 2. On a bridge: by encapsulating field telegrams into IP packets one can interact with the BAS. Although being a more decentralized approach, the same problem regarding the application level remains open. 3. On field devices: IP enabled devices offering Web services for intercommunication with other participants of the network. 4. Multi-stack bridges: allow a more decentralized approach. By implementing the field stack and the IoT stack, mappings between Web services and endpoints are possible. By proceeding this way remote devices acting as clients are not aware that the final device resides on another type of network even having no IP connectivity.

IP backbone

Management

A few research and proofs of concepts have already been proposed for IoT gateways. We can here cite the Universal Device Gateway developed in 2008 for enabling interoperability among heterogeneous communication protocols like Zig-Bee, X10 and KNX with an IPv6 compliant architecture [START_REF]The universal device gateway[END_REF]. More recently, a mapping from KNX endpoints, also known as datapoints, to oBIX objects has been proposed [START_REF]oBIX 1.1 draft committe specification. The universal device gateway[END_REF] [START_REF] Neugschwandtner | Web services in building automation: Mapping knx to obix[END_REF]. The oBIX framework was developed for facilitating data interchange with BAS, relying on a XML object model representing devices. Those endpoints are accessible over Web services. The oBIX approach is quite similar to the WS-* stack of classical SOAP Web services. The oBIX HTTP server waits for requests and then translates them to KNX telegrams. Here, depending on the type of request (GET or POST), the action performed will be either a query for an endpoint status, or an update of a state. Although providing a common mapping, the proposed approach leaves certain issues open as for example the integration in existing installations.

In another work, the full paradigm of the Web-of-Things for smart buildings has been investigated in the context of KNX and EnOcean gateways in [7][6]. This work shows that Web resources can be mapped to Building Automation System (BAS) endpoints using RESTful APIs, which are lightweight Web services based on loosecoupling. In addition to this, a semantic for URLs pointing to resources is proposed by including the location of the device inside the DNS name of the resource, thus providing a clear way for identifying them.

Devices becoming more and more IoT aware, the question regarding the standardization of the application layer and semantics remains open. A concrete proposition of an application layer compatible with IoT's paradigms was proposed in [20] [19]. The main contribution resides on the proposition of IoTSyS, an entire protocol stack for integrating BAS in the Internet-of-Things. IoTSyS relies on technologies such as Constrained Application Protocol (CoAP), oBIX and EXI, as illustrated in Fig. 3. CoAP, which is a lightweight version of HTTP pursuing the RESTful concept, is used as application transport protocol. The advantage of CoAP over HTTP is to be optimized for constrained devices by having much less overhead. Then, at the application layer, the oBIX XML schema is used to describe endpoints and to define contracts according to device functionalities, such as, for example, push button, relay or temperature sensor. The contracts can be annotated by using some data models as sensorML or domoML allowing a better processing by machines. As XML payload is not suited for small devices or constrained devices, the EXI compressor is used, which allows to reduce the size of the exchanged data. In order to perform the best possible compression, a schema describing the contracts is used on both the server and the client.

Although the IoTSyS solution fulfils some requirements of the IoT, it induces one major drawback, which is being not loosely-coupled. Indeed, every client must have knowledge about the IoT contracts schema in order to be able to decompress the XML. This approach restricts the possible evolution of the protocol stack because of the difficulty to update the schema on existing devices. This situation would lead in multiple versions of contracts distributed across networks, resulting in incompatibilities. In addition, using a lightweight protocol (CoAP) while adding some complexity by relying on oBIX could be seen as a contradiction. Additionally, many applications are nowadays built upon Web technologies like HTML and AJAX following the Web 2.0 concept. Integrating specific technologies like oBIX and EXI is actually adding more complexity to those applications and require special knowledge from developers. Despite the fact that some semantics are needed at least for describing resources, we believe that existing Web technologies have to play a more important role. Fig. 3 Protocol stack for IoT building automation systems as proposed by [START_REF] Jung | A transparent ipv6 multi-protocol gateway to integrate building automation systems in the internet of things[END_REF]. Blocks that are introduced in this proposition or requiring some adaptations relative to their traditional use are presented in pink. Existing blocks requiring no adjustment are presented in blue. New bindings between blocks are shown with pink arrows.

A Web-Oriented Protocol Stack

The device accessibility can be decomposed into four sub-layers, which are resource identification, linking, resource description and operation on resources [START_REF] Guinard | A Web of Things Application Architecture -Integrating the Real World into the Web[END_REF].

Resource identification -The location of a device, which is often an important information in BAS can be included in the DNS name describing the resource. For example coap://temp.office05.00.c.company.org would represent the temperature sensor in room 05, on the ground floor of building C of a company. The final endpoint can then be further accessed by specifying the resource or even a sub-resource. We can here illustrate this with a temperature sensor offering two contracts, one in Celsius ../temp/celsius and the second one in Fahrenheit ../temp/fahrenheit. We here reuse the concept of Web resource and URI for identifying unique device endpoints. In this approach, a traditional DNS architecture can be used. However we recommend to rely on the distributed approach of DNS, namely mDNS that is also compatible with classical DNS clients. The difference lies in the queries that are sent over multicast instead of unicast. This approach is more scalable and fault-tolerant as the knowledge about the DNS is distributed across nodes.

Linking -In the concept of WoT and Resource Oriented Architecture (ROA), an important aspect is the ability to discover resources by following links. A resource should provide links back to its parent and forward to its children. This allows to crawl knowledge about resource hierarchy. When applying this concept to the field of building automation, it comes out that devices should be linked to their location and endpoints. To achieve this, we propose to use an implicit and an explicit way. By decomposing the host part of the URI and discarding the first part, one can go back in the building location hierarchy (e.g. coap://kitchen.ground.home.com -> coap://ground.home.com). This way is especially thought for humans. Machine-tomachine interaction could prefer the explicit way. There, each resource description, i.e. location, device or endpoint, must provide absolute URLs to its parent or children. Nonetheless, linking is closely related to resource description as the format and semantic used will influence how linking is provided.

Resource description -Discovering the capabilities of a resource is also a very important aspect in machine-to-machine communications. Not only the semantic but also the format is decisive to increase the chance of self-understanding. Regarding the format, a frequent suggestion is to use JSON instead of XML. First, JSON is more lightweight than XML, and that in terms of message size and parsing time [START_REF] Nurseitov | Comparison of json and xml data interchange formats: A case study[END_REF], therefore better suited for devices with limited capabilities. Moreover, it can directly be parsed in JavaScript, allowing a faster integration into Web application and supporting the concept of mashups. Concerning the semantics, we here propose to rely on the concept of RDF and ontologies forming together the semantic Web. Further details about semantics and ontologies are given in Section 2.3.

Operation on resources -The last step is the execution of an operation on the resource. For devices with limited resources, the CoAP protocol is probably one of the best candidate. CoAP is a simplified version of HTTP, aiming at reducing the overhead size. Gateways translating HTTP to CoAP, and vice-versa, are available, exposing CoAP devices over the HTTP protocol. In a similar way as for HTTP, CoAP offers GET, POST, PUT and DELETE operations that have a standard semantic according to REST services, as for example:

• GET is used for retrieving the current state of a resource, e.g read the actual temperature. • PUT is used to update the state of a resource, e.g. switch a power outlet.

• POST is used to create a new resource, e.g. register for event notification.

• DELETE is used to delete a resource, e.g. delete a threshold on a device. Figure 4 summarizes the protocol stack for building automation systems relying on the Web-of-Things paradigm. The strengths of our WoTBAS (Web-of-Things Building Automation Stack) proposition reside in taking part of the best practices of the Web, being lightweight and loosely-coupled.

Semantics and Ontologies

Still a topic of research, semantics and ontologies are potential technologies to define common languages and representations facilitating machine exchange. The Web Service Description Language (WSDL) is currently the most used language for describing Web Services. WSDL is often combined with the Simple Object Access Protocol (SOAP) allowing the exchange of structured information about Web services. Although WSDL brings some standardization in terms of method prototyping by describing the attributes and return value, it is not intended for describing the semantic of Web resources. For this reason, many XML schemas and other data models were developed trying to describe processes and physical environments [START_REF]W3C Semantic Sensor Network Incubator Group. Review of sensor and observation ontologies[END_REF]. Nowadays the RDF language is used together with ontologies [START_REF]W3C. Resource description framework[END_REF]. Ontologies represent a vocabulary and association of definitions, while RDF is the common language to express the meta-data. Statements are expressed with triples composed of subject-predicate-object. For example the notion "The sensor is of type temperature" in RDF is represented with the following triple: a subject denoting "The sensor", a predicate "is of type" and an object denoting "temperature". In order to have standardized triples, the use of ontologies is strongly recommended. One can find various ontologies developed for specific contexts. The Semantic Sensor Network Ontology (SSN) is based around concepts of systems, processes and observations [START_REF]W3C Semantic Sensor Network Incubator Group[END_REF]. It supports the description of the physical and processing structure of sensors. However notions of units and locations are not part of it. One can include other ontologies like DOLCE Ultra Lite (DUL) [START_REF]Dolce ultralite ontology[END_REF]. Before defining the SSN ontology, the working group of the W3C performed an analysis of all existing data models representing sensors. The best practices of each data model were included in the specification of the SSN ontology. Even if the ontology is quite complete and allows to express a lot of properties, there is always the possibility to expand it with new classes and definitions. For example one could extend the sensor class in order to define a concrete sensor type with its own specific properties as for example temperature or presence. When further pushing this concept, one could imagine to create sub-classes of concrete sensor type representing a sensor model. This leads to an important question: should the ontology implement a low or a high level of abstraction? Having a low level of abstraction by defining sensor models in the ontology seems here not a good choice as it would result in a heavy-coupling between devices. Also, the ontology would be huge considering all types of sensors existing on the market. Addition-ally the evolution of the ontology would be extremely limited, or requiring frequent updates. Such an approach would result in incompatibilities across devices of different versions. Keeping a high level of abstraction certainly barely complicates the machine intercommunication but allows much more scalability in terms of evolution. One strength of RDF is that one can expand the RDF description with its own properties that are not present in the followed ontology. Clients who do not know the non-standard triples will simply ignore them. The listing 1 shows an example of what could be the RDF description in Turtle format of a humidity endpoint on a temperature sensor using the SSN ontology. Another important concept of RDF is its associated query language SPARQL recognized as a key technology of the Semantic Web [START_REF]W3C. Sparql query language for rdf[END_REF]. With SPARQL one can crawl over resources for retrieving only the interesting ones meeting some criteria. Queries are expressed with a dedicated language also expressing triple composed of conjunctions-disjunctions-patterns. The query can filter results according to literal, numeric data type properties, which makes it very similar to SQL. SPARQL offers four types of queries: LIKE for extracting raw values, CONSTRUCT for obtaining valid RDF, ASK for obtaining a simple true/false response on an endpoint, and finally the DESCRIBE for obtaining an RDF graph. In our context we will only use the SELECT type of query to return the URL of the resource. This information alone is sufficient as the client can then ask for the whole description by accessing the resource directly. However the client can also specify other attributes than the URL in the SELECT section of the query if needed. To illustrate what a SPARQL query for discovering devices could look like, we rely on a practical example as follows: what are the resources of type temperature with a value higher than 25 • Celsius located in the kitchen? Listing 2 shows the resulting SPARQL query.

Listing 2 Example of a SPARQL query to look after temperature sensors with a value higher than 25 • Celsius located in the kitchen @prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn> . SELECT ?node WHERE { ?node a ssn:Sensor ; ssn:observes <http://purl.oclc.org/NET/muo/ucum/physical-quality/temperature> . dul:hasLocation "kitchen" ; rdf:value ?lv ; FILTER (?lv > 25) . }

Discovery

Discovery of device and service is crucial in the IoT approach that rely on participating objects distributed all over the network. This case is also true for building automation. For example, we want the overall system able to discover if a temperature sensor located in a certain room is available. We can here distinguish two discovery strategies. Either by following links across resources, or by asking clients to provide their capabilities through requests. As the first one has already been discussed in the previous Sections, we will here focus on the latter.

Related Work

A key concept for Web-of-Things discovery is defined with CoAP through the use of the ./well-known/core resource which will respond with all accessible services on the device [START_REF] Jung | A transparent ipv6 multi-protocol gateway to integrate building automation systems in the internet of things[END_REF][START_REF] Jung | Integrating building automation systems and ipv6 in the internet of things[END_REF]. One major drawback of this concept is in the fact that previous knowledge about the device's DNS or IP address is required. Furthermore the response is limited to few predefined attributes giving little information about the services themselves. Regarding service discovery, well-spread protocols like UPnP's SSDP [START_REF] Goland | Simple service discovery protocol/1.0 operating without an arbiter[END_REF], SLP [START_REF] Guttman | Service location protocol, version 2[END_REF] or DNS-SD [START_REF] Cheshire | Dns-based service discovery[END_REF] have emerged in the last years. They are mostly implemented in operating systems and computer peripherals like printers or PDAs. They are based on a multicast approach allowing to discover the existence of devices according to user role and network scopes. DNS-SD, for example, extends the classical DNS or mDNS naming by recording services as DNS entries which can then be discovered by DNS query messages. Service discovery protocols that are specifically conceived for very constrained devices have also been proposed [START_REF] Kovacevic | Nanosd: A flexible service discovery protocol for dynamic and heterogeneous wireless sensor networks[END_REF][START_REF] Butt | Trendy : An adaptive and context-aware service discovery protocol for 6lowpans[END_REF]. Many of these protocols only consider static service attributes that are provided during service registration. In an ideal case, services should be discovered according to dynamic and contextual properties [START_REF] Mayer | An extensible discovery service for smart things[END_REF].

Building Automation System Requirements

From the perspective of discovery, building automation systems are significantly different to classical pervasive devices for which location services are most of the time sufficient. Actually, an extension from simple discovery to query is here required. Indeed the context of a device or, in our case, a resource is decisive during discovery. Many building management systems have to look for devices being in a certain state or context for regulation or alarming purposes. For example one BMS could search for temperature sensors on the ground floor having measured in the last five minutes a value higher than 25 • C. This request must also consider devices that have not yet reported and are not known by the system. Relying on a plug-and-play approach allows to have highly dynamic systems requiring no previous knowledge of the available resources. We introduce here the concept of static and dynamic resources properties as illustrated in Fig. 5. If one wants to discover all the available devices in a given installation, a simple query specifying no properties would be sufficient. The next step would consist of retrieving the description for resources of interest. Working with constrained devices and low-power networks, the energy efficiency of the new layer is also key factor that has to be optimized in order to not affect life span of battery-operated devices.

Architecture

In order to fulfil the above mentioned requirements, we have to make several choices regarding architecture and technologies. A potential answer can be proposed by dividing the problem into four sub-problems: infrastructure, application layer, data format and query engine.

Infrastructure -A first question is about the use of central or distributed directories of resources descriptions. Using repositories is more suitable for environments with thousands of services, where queries can be processed more efficiently. However a centralized approach has some drawbacks. The first one is about fault tolerance (see requirement 5 above). A central directory failure would result in the inability for clients to discover services. Further to this, the repository has to be frequently updated with context and device availability that would generate a lot of traffic. For these reasons, a de-centralized approach is probably recommendable, where every device will be a discovery endpoint, and thus guarantee a reliable availability. In addition, the traffic of messages is kept very low by using multicast techniques. Only one message is sent by the client, receiving unicast response from matching endpoints.

Application layer -For the application layer, we suggest to rely on CoAP for transporting the requests and responses. CoAP is indeed already present on devices implementing Web-of-Things stacks and more specifically building automation stacks. Additionally, CoAP provides a multicast communication in the Groupcomm draft, which can be used to address the entire network with only one packet [START_REF] Rahman | Group communication for coap[END_REF]. With this method, devices offering discovery capability expand their interface with a new service responding to multicast requests. Leveraging on CoAP allows already to satisfy requirements 1 and 3 listed above. The use of multicast requests allows limiting the number of packets transiting over the network. The number of packets sent for discovering a resource with multicast can actually be computed with N p = n + 1, with n representing the number of devices matching the query.

Query engine -The query engine is at the heart of the discovery process. It finds matches according to the properties specified by the client. Many systems for querying structured data exist. As explained in Section 2.3, SPARQL and RDF comes out to be a promising alternative. In this context, when receiving a discovery request, the SPARQL engine retrieves the current up-to-date description of each resource containing the static and dynamic property values. The next step consists of applying the query to the RDF document. In the case of matching results, they will be piggybacked within the response packet. If no resource meets the criteria, no response will be sent to the client. From a conceptual point of view, the coupling of the resource context with RDF and SPARQL makes the discovery process closer to a distributed query engine, which meets requirement number 4.

Data format -Following the same principle as for the building automation stack presented earlier, a reasonable proposition is to rely on JSON as exchange data format to minimise the network traffic. However, translating the SPARQL query expressions to JSON would add complexity and overhead as SPARQL is already free of tags and rather compact. Therefore, the original SPARQL format could be per-fectly used for expressing the queries. On the other side, query responses are usually provided in XML format for which a translation to JSON could be recommended. Using SPARQL for queries and JSON for responses would allow minimizing the exchanged data and therefore comply with the requirement 1 stated earlier. An implementation based on the proposed architecture for discovery is depicted in Fig. 6. The different modules can be grouped in interface, discovery and query engine, and finally the resource.

In more details, the flow of operations is the following. The CoAP server listens on a multicast socket with preconfigured port and IP address. Its role is to dispatch incoming discovery requests to the discovery and query engine. If matches are found, it will respond to the source of the request with the according payload data. Going one level down in the server, the discovery and query engine is responsible for evaluating requests and finding corresponding matches. It starts with a SPARQL request extractor that will take out the query from the CoAP messages and perform some validations regarding the format. Once the request is considered as well-formed, it is passed to the querier. This module will gather the RDF representations of all the resources present and available on the device. Once the collection complete, the SPARQL query is applied to each RDF representation of the collection. Each match is then stored in a collection of results. If the collection of results is empty after querying, the process can stop at this step. Otherwise, the collection is forwarded up to the JSON formatter. This module iterates through the results collection and formats SPARQL responses to JSON. The last step consists of responding to the client over the CoAP interface with the results.

We believe that having a modular approach as described above reduces the complexity of the discovery architecture and allows for future evolutions. Additionally, the different modules can rely on existing libraries offering the desired functionalities therefore reducing the implementation time.

Bridging Automation and Adaptation

So called building automation systems will perform more and more complex tasks, going way further than simple HVAC automation and light actuation. Future applications will rely on holistic optimisation leveraging on the access to data from the entire set of sensors. Applications will also use external data coming, for example, from weather web services, or even from neighbouring smart buildings, leading to the concept of smart neighbourhood or smart city. Regarding algorithmic, systems will have to incorporate more advanced data analytics technologies. Threshold based rules, often a priori set, will be replaced by complex parametric models implementing self-learning capacities and allowing for dynamic rules as a function of the context of use of the building. In this Section, we take a side step to analyse the system architectures that will, at the same time, leverage on the strengths of Internet and Web technologies, and on new emerging intelligent services, enabling to move from building automation systems to building intelligence systems.

Related Work

Classical building automation systems are composed of three tiers, as depicted on the left part of Fig. 7 [START_REF]2004 building automation and control systems (bacs)[END_REF]. At the bottom we find the field level consisting of the network topology and the attached sensors and actuators providing for measurements and actuations. The automation layer provides control logic for driving actuators, providing some kind of intelligence to the building. The purpose of the automation layer is to optimize the comfort inside the building by using rules of actuation typically based on predefined threshold values. At the top, the management level offers applications for configuration and data visualization. With this architecture, regulation algorithms are mostly centralized on a single node and rely on few historical data. In the case of large buildings, multiple computers are used with a repartition of the logic corresponding to parts of the building to avoid dependencies between the sub-systems.

Nowadays, an evolution of the automation can be observed such as the inclusion of genetic algorithms [START_REF] Huang | Using genetic algorithms to optimize controller using genetic algorithms to optimize controller parameters for hvac systems[END_REF], artificial neural networks [START_REF] Kanarachos | Multivariable control of single zone hydronic heating systems with neural networks[END_REF] and empirical models [START_REF] Yao | Optimal operation of a large cooling system based on an empirical model[END_REF], among many others. Such models have the ability to capture through historical sensor data information about the physics of the building and therefore to elaborate automation rules that are more precise. New approaches are also attempting to optimize the energy consumption according to a modelling of the user behaviour (see Section 5).

Despite a lack of literature related to system architecture in buildings, we can reasonably argue that the classical three-tiers architecture currently proposed by industries is not well suited for future developments. Indeed, the arrival of IoT, inherently relying on distributed nodes, as well as the emergence of these new modeling strategies are advocating for new architectures that we present in the next Sections.

Evolution of Building System Architecture

We illustrate on the right part of Fig. 7 the perceived evolution of building system architectures. We first introduce an adaptation level that will dynamically feed the automation level with control logic, i.e. rules. In the IoT approach, the management level has also to be made available transversally as configuration, discovery and monitoring services must be made accessible to all levels.

Adaptation Layer

The current trend is to use intelligent data analysis technologies such as machine learning. Such algorithms need historical data from sensors to generate dynamic rules. Following IoT and WoT concepts, the data storage, as well as the automation and adaptation layers should be decentralized across the network and become ubiquitous. Consequently, historical data will be spread over the network and stored close to the devices. Algorithms and rules have also to be considered as Web resources in a similar way as for sensors and actuators. Figure 8 compares the repartition of roles for a classical building automation system (left) to the new WoTenabled architecture (right). In this context, future works will have to be carried on to find solutions to minimize the transfer of data and the distribution of algorithms.

Automation Layer

The automation layer sends messages to the actuators to control the building equipments. The control is done according to rules which, in the classical approach, are most of the time static and a priori defined. In the new approach, rules will be generated by the adaptation layer, potentially evolving with time. A WoT compatible approach will be to distribute the rules over the network on devices with computational capabilities. We can already distinguish two types of automation rules that will probably be handled differently: event based and data oriented. In the first category, the rules will only be triggered as answers of building events. The second category of rules will require access to historical data such as, for example control loops. In the similar way as for the adaptation layer, future work will have to define strategies in order to reduce the traffic of data and to optimise the overall efficiency of the distributed system. Although the adaptation and automation layers are quite similar from a WoT perspective, their purpose is not the same. For instance, buildings may not implement an adaptation layer and take part only of the automation one. This is actually a reasonable argument in favour of a separation of both layers.

Intelligent Data Analysis for Smart Environments

In this Section, we focus on providing further discussion on the Adaptation Level as described in Fig. 7. One could qualify an environment as being smart whenever it is able to make the right decision at the right moment and with a satisfying rate of success regarding the outcome of the decision. A recent trend to build smart systems is to rely on so-called Intelligent Data Analysis approaches. Such approaches are often based on machine learning techniques able to infer prediction or classification models from large set of observation data. Different machine learning techniques can be employed depending on the application purpose, the computational capability and the desired accuracy rate. The main advantage of Machine Learning is to be found in the ability to discover the complex and sometimes unexpected correlations in heterogeneous input data. In this regards, the arrival of IoT and WoT is of course a key enabler for the use of Intelligent Data Analysis in Smart Buildings. A common application of machine learning in smart environment is the recognition of human activity. This application also encompass presence verification, intrusion detection and, to a larger extent, abnormal behaviour detection.

Evolution of Control Algorithms

Many algorithm strategies have been applied to smart buildings. A classification from the simplest algorithm with no or few adaptation, to the most complex approaches mostly relying on machine learning can be given as follows.

• Fixed threshold based algorithms. Such algorithms implement simple rules typically using fixed thresholds to control the equipments. These rules are often set without considering the real needs and dynamics of the users. HVAC systems are typically controlled depending on target temperature values conditioning the air by injecting heat or cold. The rules are sometimes using a schedule of predefined values to comply with known cyclic energy needs, typically day/night or seasonal cycles. • Physics based algorithms. Such control algorithms are using mathematical models of the physics of the building. For example, the thermal inertia is computed and used to avoid undershoot or overshoot of temperatures. More sophisticated models will take into consideration the building orientation, its geometry, size of windows, among others for computing optimal blind control. Such models, while improving significantly the energy usage, are nevertheless targeting a comfort level for an "average user", disregarding the dynamics of the real use of the building. Furthermore, such systems are typically costly in terms of setup and need careful tunings at the commissioning phase. • Self adapting algorithms. Machine learning technologies are typically used here to compute data-driven models for prediction of variables and classification of events. Such algorithms have the possibility to adapt continuously to building characteristics, building use, and environmental conditions.

We are here specifically interested into the third category of self adapting algorithms that have the most potential regarding smart applications. The arrival of IoT/WoT architectures are also enabling the use of more complex algorithms having to deal with heterogeneous and asynchronous data. In the scientific literature, many models can be found such as predictive models, artificial neural networks, fuzzy logic and many others. Recently, stochastic state based data-driven models have also been proposed to capture the spatial and temporal statistics of building usages.

Self adapting algorithms present several advantages. First, they are independent of the physic of the building or, more precisely, the building characteristics are learned intrinsically from the observation data. Second, the optimization has the potential to become global instead of local, especially in the case of unified IoT/WoT architectures where all sensors and actuators are exposed from the sub-systems. Third, time-varying usage of buildings will be tracked as self-learning algorithms have the ability to incrementally adapt their parameters with new observation data. Such approaches allow an adaptation to real user, and not just an average user, thus minimizing the risk of rejection. Finally, new building configurations can be automatically learned, hence reducing setup costs. This last point has actually to be weighted by the fact that self adapting algorithms need some time to converge, creating potential loss of comfort during learning.

We have to point out that these advantages are still theoretical for smart buildings. Indeed, at the time of writing this text, we did not yet observe a smart buildings implementation relying fully on IoT/WoT and self-adapting algorithms. The vision is actually to go for a system where, typically, the installation of a new sensor would be automatically known from the rest of the system and incorporated into the algorithms as new piece of information for a better global settings of the equipments.

Adaptation Level Architecture

In this Section, we propose a global and unified architecture for data modeling in the context of smart building. In many configurations, physics based algorithms or self adapting algorithms can usually be considered as extensions of threshold based systems, where the threshold values are continuously set from the models. Actually, the fixed threshold based algorithms could be seen as rules being processed in the automation level as described in Fig. 7. Physic or self adapting algorithms would be dynamically creating the rules in the adaptation level and feeding them into the automation level. The algorithms of the adaptation level can operate either continuously or at predifined periods of time, for example everyday at midnight. The frequency depends on the needs of the application and on system capabilities in terms of memory and computing power. In this sense, the adaptation level can actually be seen as decoupled from the automation level implementing the on-line working system.

Figure 9 illustrates the generic life-cycle of intelligent data analysis. At the field level, the sensor nodes provide information captured from the environment. The raw observations are communicated to the adaptation level. The adaptation level then performs a feature extraction. The purpose of this operation is to compute useful characteristics from the raw observations. Typically, features consist of normalized or filtered raw values. More complex feature extraction can also be applied such as frequency analysis with Fourier transform or computation of relevant features with Principal Component Analysis. The next step is to model the features for a specific objective such as prediction of future values or classification of events. At this point a specific machine learning technique is applied to compute the models. From a general perspective, the parameters of a mathematical model are computed or updated from exemplary feature data, i.e. data for which the expected output of the model is known. These data are refered to as training data or ground truth. Once the models are ready, they are used to compute on-line rules that are fed into the automation level. The execution of a rule in the automation level will finally send commands to the actuators of the field level.

Adaptation Level and State Modelling

In the case of smart buildings, the signals to be modelled are often time series representing the evolution of some observations measured at the level of a sensor, or at the level of a combination of sensors located in a room, or even, at the most general level, the whole set of sensors in a given building. These multi-level and time dimensions are suggesting that the signals can be modelled using state-based models such as Hidden Markov Models. Figure 10 illustrates this approach. Such modelling usually implies that a state is tied to a stability of the statistical properties of the signal. Typically, the task will be to discover the most probable state in which the sytem currently is. The state label will be used to generate rules then fed into the automation level as explained before. As depicted in this Figure , the discovered state at one given layer can be fed to the above layer as an extra input signal. For sake of simplicity, only three layers are shown, but more or less layers could be present depending on the context of the application. The generic principle is to include the information coming from the more granular to the less granular levels, from sensor information, to room information and up to floor and building knowledge.

Examples of Application

We describe here three applications that were implemented according to the architecture proposed in the previous section. Hidden Markov Models (HMMs) were used as modelling tool.

The first application is linked to single system modelling, i.e. the lowest level as illustrated in Fig. 10. A single system consisting of a smart plug is used to measure the electricity consumption of appliances at the frequency of 10 -1 Hz. The target application is the automatic identification of electric appliances so that building residents can have detailed information on their electricity bill. The HMMs are trained using a publicly available database of electric signatures called ACS-F1 for Appliance Consumption Signature Fribourg 1 [START_REF] Gisler | Appliance consumption signature database and recognition test protocols[END_REF]. The database consists of two acquisition sessions of one hour for 100 appliances spread uniformly into 10 categories. Two evaluation protocols are proposed with the database distribution. The first intersession protocol consists in attempting to recognize signatures from appliances already seen in the training phase [START_REF] Ridi | Automatic identification of electrical appliances using smart plugs[END_REF]. The second protocol, called unseen instance, aims at recognizing signatures coming from appliances never seen in the training phase. In this more difficult case, the system has to be able to generalize to new brands or models [START_REF] Ridi | Unseen appliances identification[END_REF].

The second application aims at automatically recognizing activities at the level of a full floor in a residence. A set of presence and door sensors is spread in the residence and provides asynchronuous signals in case of movement and passage. The feature extraction consist here of a simple shifted window processing in order to reconstruct time synchronized observation vectors. HMMs are built with a topology where the states are related to the zones of the floor where the activities are expected. Seven HMMs are trained using the data, each one of them corresponding to a given activity to be recognized. The Viterbi algorithm is used for the training and testing phases. We evaluated the proposed models using the WSU CASAS dataset [START_REF] Cook | Learning setting-generalized activity models for smart spaces[END_REF], achieving an accuracy of 98,9% using the leave-one-out technique on seven activities recorded for 8 months [START_REF] Ridi | Towards reliable stochastic datadriven models applied to the energy saving in buildings[END_REF].

The third application aims at discovering a better definition of seasonal HVAC controls at the level of a building, i.e. the upper level as illustrated in Fig. 10. More specifically, the model is built to predict the change of seasons using the information coming from window openings, window blinds, external and internal temperatures and solar irradiation. The model is based on a HMM defined with three states, representing the heating, cooling and intermediate seasons. In this experiment, the training data is provided through past data of the activation of the HVAC system of the LESO-PB building in EPFL, Lausanne. For example, when the system is in heating mode, the associated state is known and the parameters of the models can be trained with the input data. In the testing phase, the Viterbi algorithm is used to determined the state label at a given time and compared to the ground truth. The results are showing a correct season identification with an accuracy up to 91% for the heating and cooling seasons, while the most difficult intermediate season shows a rate of 69% correct detection [START_REF] Ridi | Towards reliable stochastic datadriven models applied to the energy saving in buildings[END_REF]. While this experiment is still a bit theoretical, it shows that a machine learning based modelling can capture the actual controls of a well-tuned HVAC system. It can be reasonably expected that the learned model can be re-used in a similar building configuration.

The three preceding applications show the feasibility of the proposed state-based modelling as algorithmic approach to implement the adaptation level of Fig. 10. A missing step which is not explored in this work, is the inference of relevant rules to be injected in the automation level.

Conclusion

Buildings automation systems have in the last years not followed the trend of modernization and are always relying on isolated networks. The emerging technologies of sensors and especially the Internet-of-Things can provide many advantages to those buildings. In this chapter we investigated the main issues that have to be solved for augmenting traditional building automation systems with IoT capabilities. The main challenge lies in the natural heterogeneity of building networks working on different protocols. A successful homogenization of BAS can only be achieved by implementing a standard and open protocol stack. Multi-protocol gateways hiding the complexity of BAS by mapping devices capabilities to Web services highly simply the integration of existing networks. The emergence of IPv6 solves the address limitation of IPv4 and allows nowadays any device to be directly connected to IP networks. Trendy Web technologies like CoAP following the REST architectural style already contribute to the standardization process with their lightweight Web services. A key role in homogenisation is played by the acceptance of the application layer. Some propositions have already been done in this area converging to the use of data models for sensor properties. Until today none of them managed imposing itself as the de-facto standard. We can explain this by the heavy-coupling they impose using XML schemas that have to be known by every device. In our point of view only a loosely-coupled solution offering enough flexibility has a chance of being accepted by the scientific community and especially the industry. Here the contributions of the World Wide Web Consortium with RDF and ontologies have all their importance. Working in pervasive and ubiquitous environments requires approaching discovery of devices with another point of view. The need of a solution allowing to crawl devices with no prior knowledge appears inevitable. Distributing SPARQL queries over the network via multicast appears to be a clear response to this constraint. Building automation systems can benefit from advances made in the field of machine learning techniques. A new dimension of energy saving opens to IoT-enabled building management systems. Anticipating the users behaviour and actuating HVAC systems according to the buildings use has a real potential reducing the overall energy consumption. This target is only achievable by introducing a new level to the classical three-tiers decomposition of BAS.

IoT and WoT are expected to be key enablers for advanced building controls based on intelligent data analysis. In this direction, different machine learning techniques can potentially be used for managing a smart environment. The life-cycle of machine learning applications starts with an acquisition of raw data from the sensors distributed in the building, continues with an extraction of relevant features, follows with the identification or prediction of some events that are then, in turns used to modify the rules of the automation level of the building management system. The modification of the rules can take place continuously or off-line, at regular interval. A potential powerful modelling scheme can be found in state-based modelling such as Hidden Markov Models where the statistic of the features are captured according to states representing the piece-wise evolution of the building context. In the description of the adaptation level provided in this Chapter, we have left apart important practical considerations, for example the ones regarding the computing power, data storage and the energy consumption of the adaptation layer itself. The limitation of resources and lack of energetic availability in IoT installations limits de facto the complexity of the machine learning techniques that may be used.

Although building automation being quite a recent research field, certain directions still emerge. The near future will give us more insights about the practical feasibility and the acceptance of Web technologies in buildings. Moreover we can already distinguish two imminent key points that will limit the spreading of IoT building automation systems. The first concern is about the energetic impact of such installations. The overall IoT approach should not consume more energy than traditional BAS and therefore counter the efforts done optimizing the building. Secondly, the very restricting open issue that has not been tackled is about security. One can easily imagine the consequences resulting in a misuse of the automation system. Cybercrime has become a major problem of today's information systems. Solutions limiting mashups between devices explicitly authorized and ensuring the privacy of historical data are essential before deploying IoT systems in buildings.

Fig. 1 N

 1 Fig. 1 N-to-N (left) and N-to-1* (right) approaches for protocol mapping in buildings.

Fig. 2

 2 Fig. 2 Building automation systems integration styles

Fig. 4

 4 Fig. 4 Protocol stack for WoT building automation. Blocks that are introduced in this proposition or requiring some adaptations relative to their traditional use are presented in pink. Existing blocks requiring no adjustment are presented in blue. New bindings between blocks are shown with pink arrows.

Fig. 5 1 .

 51 Fig. 5 Static and dynamic properties of a resource

Fig. 6

 6 Fig. 6 Client and server discovery architecture

Fig. 7

 7 Fig. 7 Level based architecture of building automation systems. The left part shows the classic state-of-the-art decomposition. The right part shows the potential evolution of the architecture needed for future building applications.

Fig. 8

 8 Fig. 8 Role distribution for a classical building automation system (right) and for a Web-of-Things architecture (right).

Fig. 9

 9 Fig.9Life-cycle of data processing with intelligent data analysis.

Fig. 10

 10 Fig. 10 Example of adaptation layer based on state modelling.

  Listing 1 Example of a humidity endpoint on a temperature sensor description using RDF with the Semantic Sensor Network Ontology @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn> .

<coap://temp.kitchen.home> rdf:type ssn:SensingDevice ; ssn:observes <http://purl.oclc.org/NET/muo/ucum/physical-quality/humidity> ; ssn:hasMeasurementCapability <coap://temp.kitchen.home/hum> . <coap://temp.kitchen.home/hum> rdf:type ssn:MeasurementCapability ; ssn:hasMeasurementProperty <coap://temp.kitchen.home/hum/accuracy> ; ssn:hasMeasurementProperty <coap://temp.kitchen.home/hum/sensivity> . <coap://temp.kitchen.home/hum/accuracy> rdf:type ssn:Accuracy ; rdf:value 1 . <coap://temp.kitchen.home/hum/sensivity> rdf:type ssn:sensivity ; rdf:value 0.1 .