Cette Thèse

Philippe Roose

M Laurent Reveillere

Je Remercie Également

Mme M Olivier Boissier

Parisa Ghodous

M Jean-

Yves Tigli

Gilles Privat

M Stéphane

M Bernard Tourancheau

Adrian Clear

Romain Ayala

Nhat Mengxuan Zhao

Hai Nguyen

Mickaël Nicolaccini

avec la profondeur de leur expérience dans leurs rapports respectifs

Keywords:

qui furent pour moi trois encadrants de thèse attentifs et disponibles malgré leurs nombreuses charges. Leur

Résumé

Les entités physiques prises en compte par les applications dites M2M dans les télécoms sont aujourd'hui de plus en plus hétérogènes. Ceci Cette thèse présente un cadre théorique général et des mécanismes de base pour l'identification de modèles de telles entités physiques dans les systèmes d'information embarqués répartis, en englobant dans une même approche les équipements et les sous-ensembles de l'espace, faisant se rejoindre les points de vue "internet des objets" et "environnement interactif" dans une nouvelle vision unifiée de l'intelligence ambiante. Ce travail, motivé initialement par les applications à la gestion d'énergie domestique, cherche àintégrer au réseau local de la maison des entités physiques (par exemple équipements électroménagers et pièces de la maison) qui ont un impact énergétique mais ne sont dotés d'aucune connexion réseau, ce qui correspond à une extension qualitative du périmètre de l'Internet des Objets. Cette intégration se fait de manière tout à fait similaire à ce qui est fait classiquement pour des équipements numériques état de l'art, c'est-à-dire par des mécanismes de découverte et configuration spontanés. Ces mécanismes comportent les étapes suivantes :

• Détection de la présence d'une entité physique par analyse de la coïncidence d'événements significatifs reçus de capteurs;

• Sélection d'un premier modèle générique représentatif de l'entité physique détectée depuis une ontologie de référence en analysant des données reçues les capteurs;

• Création d'un composant logiciel représentant l'entitép h y s i q u e détectée, àpartirdumodèle sélectionné, et associant les capteurs et actionneurs utiles;

• Supervision et contrôle de l'entité cible par l'intermédiaire de ce composant logiciel;

• Mise à jour incrémentale du modèle de l'entité identifée par analyse des données issues des capteurs associés;

Ce travail est parti d'applications dans l'environnement de la maison, pour lesquelles il a été validé et mis en oeuvre. Mais notre approache av oc a t i o nàêtre généralisée et étendue à des environnements comme les bâtiments ou la ville, en offrant suivant le même principle une infrastructure partagée pour toutes les applications M2M dans ces environnements.

Abstract

The physical entities which are taken into account by Machine to Machine (M2M) telecom applications are more and more heterogeneous. This is due to the increased turnover and multiplication of digital connected devices, and also to the need to integrate non-networked or even non-digital "legacy" equipment in these applications. In addition, space entities such as rooms may also be taken into account in the same environments. The challenge addressed by our research is the automatic integration and configuration of all these types of physical entities in M2M systems, with a homogeneous solution that generalizes self-configuration approaches used for networked digital devices.

This thesis presents a general theoretical framework and basic mechanisms for the identification and configuration of such physical entity models in distributed embedded information systems. Our approach deals jointly with equipment and space entities encompassing the "Internet of Things" (IoT) and "interactive environment" viewpoints in a renewed interpretation of ambient intelligence. This work has been motivated initially by home energy management applications, trying to integrate into the Home Area Network all home entities (e.g. domestic appliances and rooms) that play a role in energy management, but do not have a networked interface of their own. This corresponds to a qualitative extension of the perimeter of the Home Area Network. This integration is achieved in a way similar to what is done for state of the art digital devices, through a spontaneous discovery and configuration mechanism, with the following stages:

• Detection of the presence of a physical entity by analyzing the coincidence of significant events detected by sensors;

• Selection of the first generic model corresponding to the detected physical entity from a reference ontology, on the basis of received sensors data;

• Creation of a software component representing the detected physical entity, based on the selected model, associated with relevant sensors and actuators;

• Provision of application interface for monitoring and control of the target entity through this intermediate software component;

• Iterative update of the identified entity model on the basis of data from associated sensors.

The proposed approach has been validated and implemented in home environments, but it is intended to be generalized and expanded to environments such as buildings or cities, offering a similarly shared infrastructure for all M2M applications in these environments.

1 Introduction

Problem statement

The classical vision of the "Internet of Things"(IoT) aims to extend the range of devices that can be connected to Information & Communication Technology systems (ICT systems), moving from WiFi/cellular-connected devices to RFID, Zigbee or their equivalents. Obviously there are trillions of such low-end devices waiting to get connected. But this "things-to-things" vision misses the more fundamental aspect of the IoT, which is not only an extension of existing personto-person networks. By connecting "things" that are deeply embedded in the physical environment, ICT systems become strongly coupled with all kinds of physical systems, opening up all kinds of new possibilities for the operation of these physical systems.

IoT/Smart Space applications grounded in a shared physical environment, still fail to use a fully shared software, hardware and network infrastructure. This is not only a waste of resources, but also a waste of opportunities. The prevalent integration of these applications may be due to regulatory, safety or security constraints.

A shared Smart Space/IoT infrastructure may involve, at least, a local area network and its "capillary" connections to sensors and actuators in the target environment. However it can and should extend to lower-level sensor and actuator layers, in order to provide a physical interface to the environment. Also, it should

INTRODUCTION

extend to upper-level service layers that mediate the data from the sensors to the actuators.

So far, most of the solutions of infrastructure proposed for IoT/Smart Space mediation are data-centric. They attempt to provide a pool of common sensor data to be shared between different applications in a given environment. To make this possible, raw sensor data should be at least associated with sensorcentered metadata and semantics, so that applications may use this data for self-configuration. Higher level context-management frameworks [5] attempt to aggregate data as context information.

These data-centric (or sensor-centric) approaches still fall short of sharing the infrastructure to the highest possible level and fail to associate sensors and actuators. IoT/smart space applications are not interested in the sensors and actuators themselves, but in the physical entities being sensed by sensors, and acted upon to actuators. The relevant level of abstraction for IoT/Smart Space infrastructure sharing should thus not be centered on individual sensors and the data they generate or use, even if the data are aggregated into contextual abstractions. The relevant common denominator to all these applications should be these physical entities, whose models properly take into account the joint role of sensors and actuators, which serves as a bidirectional interface. These entities should be generic and intrinsic to the environment and not tied to any specific IoT/smart space application in this environment.

The problem addressed in this thesis is as follows: in a given environment, an ICT infrastructure is set up to monitor and control this environment. A set of physical entities are defined as targets to be individually monitored and controlled. From the point of view of smart space, they are typically subsets of space such as rooms. From the point of view of IoT, they are typically physical things such as home appliances, pieces of industrial equipment, or completely passive items. Merging the two viewpoints, these two categories of "space" and "things" entities should both be integrated in the ICT infrastructure and interfaced in a unified way. It should occur as if these entities were networked devices, even though none of them need actually be directly connected through a regular network interface. They need not even be identified through a universal identification scheme such as RFID/EPC global or their numerous equivalents. In the concept

Objective of thesis

and mechanisms we propose, these entities are "connected" to the network indirectly, and bi-directionally, by means of available shared sensors and actuators, distributed in the target environment. The sensors and actuators that are associated to entities in this way are regular networked devices, and are generally not target entities themselves. They are just used as transparent intermediaries to connect and interface these entities to the network.

Objective of thesis

The objective of this thesis is to enable the integration of "entities" that do not have their own network connection, for example legacy home appliances as well as spaces like rooms. This integration should make it possible to monitor and partially control them through the network.

Thesis outline

This thesis manuscript is organized in seven main chapters:

• Chapter 2 presents the general background of the thesis from three points, project, technology and application. Firstly we present the two projects in which this work has been involved. Then, in the technological background, we describe related technologies of IoT/Smart Space, especially those pertaining to home area. For the application background, we outline the current applications for IoT/Smart Space.

• Chapter 3 describes in detail the related work for the thesis. State of the art research work will be presented in two aspects: the referential architecture on different scales of environment ranging from home to city; and the different levels of information management from the collection of raw sensor data to entity behavior abstraction. Finally, existing self-configuration protocols for the home area network are given.

INTRODUCTION

• Chapter 4 starts with a presentation of our contributions. In this chapter, we give a global vision of our proposition as well as several definition of terms, use cases. The proposed approach is also briefly presented.

• Chapter 5 details the three main propositions described in chapter 4.

The referential architecture is illustrated in several diagrams. The concept of our proposed model and its iterative identification and reconfiguration mechanism are described as well.

• Chapter 6 presents specifications concerning the implementation process.

In this chapter, the prototype system implementation is described. Then the validation work describes the different test environments as well as the home appliance and rooms self-configuration demonstration. The evaluation results are given in the end.

• Chapter 7 extends our proposition in the related area of Smart Grid .

We will give some perspectives on the adaption of our proposition for this domain.

• Chapter 8 concludes the thesis and presents some outlook.

General Background

In this chapter, the background and context of the thesis is detailed from three aspects. First, we present the research projects in which our research work was involved. Second, related technologies are detailed, in order to point out the main technologies in our research work scope and discuss our main ideas. Smart environment and IoT applications in the home domain are presented in the third part.

Project background

During the thesis work, we have participated in two collaborative research projects:

"Reactivhome" and "FINSENY". Our task in each project was to investigate the feasibility of our proposition in the context scope of the project, and to propose a functional architecture of reference for the auto-configuration, monitoring and control layers of the ICT system. We also provided several deliverables and demonstrations in order to validate our proposition in the context of project.

Thanks to the two projects, we had the opportunity to exchange with our project collaborators, who shared their expertise in the related domains of smart environment and IoT that include notions such as home automation, home and building energy management, and Smart Grids. Also the two projects provided the different platforms that allow us to implement our prototype system, in order to validate our propositions.

Reactivhome

Reactivhome is a French research project, funded by Agence National de la Recherche (ANR) 1 . The main objective of this project aims to create an ICT system in order to optimize production, storage and use of energy in homes, taking into account all the domestic appliances, the state of its occupants, as well as locally available energy sources.

The integration of these appliances, especially non-networked appliances, into the Reactivhome ICT system is intended to occur in a spontaneous and dynamic way, meaning no manual configuration will be required. Software infrastructure is designed to enable this dynamic integration based on Service Oriented Architecture (SOA), and also provides monitoring and control for the appliances. For appliances that connect with the system by using the Reactivhome smart plug, power consumption is also monitored and controled by the system. In addition,

the Reactivhome system takes into account the thermal model of the building and the appliances as well as environmental parameters for energy optimization (weather, temperature, presence or activities of the occupants, etc.).

Based on a previous ANR project, Multisol [6], Reactivhome develops the missing brick of technologies for the realization of products adaptable to any habitat context. It contains the four following research themes:

• Automatic Recognition of appliances to achieve a "plug&play" mechanism;

• Integration to a general home-automation service and M2M oriented architecture;

• Human Machine Interface and social acceptability;

• Learning the behavior of the user.

Our contribution for Reactivhome has focused on how to provide an infrastructure and a referential architecture to support the "plug&play" mechanism of the ICT system. FINSENY consists of 9 work packages and we were in charge of the WP4.

This work package addressed energy optimization by managing all energy consumption, generation and storage components at the building scale in a comprehensive, semi-autonomous supervision and control system. This system would have to interface with existing building management systems as well as with the distribution grid, local microgrids or any other larger scale energy management systems.

In this sense, building-scale energy optimization is not 100% subordinate to optimization at broader scales. This could result from its integration in a smart grid and can mediate these constraints (peak levelling/load shifting, smoother demand-response pattern, adaptation to (near) real-time pricing, etc) through an intermediate level of control.

The emphasis is placed on energy consumption efficiency, as the minimization of the energy input for a given level of energy-based services to the building users,

GENERAL BACKGROUND

yet taking into account external constraints originating from the grid at large. Among all energy efficiency measures, ICT-based efficiency requires the least amount of upfront material investment and can draw most easily upon a shared, non-rival infrastructure, comprising actuators/sensors, networks, software and the corresponding know-how. ICT-based efficiency complements the application of classical more costly measures such as upgrading appliances, weatherization, insulation, etc but does not replace or require these measures.

Technological background

In this section, we present the context for three key technologies: identification technology in IoT, sensor and actuator networks in home/building domains and smart objects/spaces applications. By analyzing the three backgrounds, we answer the following major questions for thesis:

• What is the problem: the identification and configuration of "things";

• How is the preliminary condition defined: shared WSANs and shareable interface to infrastructure;

• What is the major objective: propose a solution which provides a possible way to identify and configure "things".

Identification is our research projects main problem, and providing an identification solution for the self-configuration system is one of the objectives of this thesis. By analyzing the mainstream identification technologies, we found that digital identification was a constraint as it is difficult to deploy for everyday objects, lacks a standard protocol, and the identification mechanism is absolute.

These arguments determine our research direction. We aim to provide a solution compatible for legacy object, no-protocol requirement and with an iterative identification mechanism.

Our research work is based on complete sensor and actuator networks. The current WSANs technological background is described in the second subsection.

We have listed some typical research and industrial projects, that confirm the development and deployment of the WSANs for IoT. We especially elaborate on the trend shared WSANs development and their shareable interface in this domain.

The current research situation for two disparate domains are: the smart object and smart space. Both are the major objects our proposition deals with. We discuss four application examples and the alternatives in these two domains in order to draw analogies between them. There are two main analogies: both of them can be considered as a "thing" in IoT framework and in order to make them intelligent, we need shared WSANs for monitoring and control. With these analogies, we can prove that our work can achieve one solution compatible with both of them.

Digital Identification and Configuration

Identification

Most solutions rely either on the principle of giving a unique tag to "things"

as their ID, or on the MAC address for the classical network device. The first solution is the Barcode which was invented in 1948, to resolve the automatic product information capture problem. Today, in the scope of Internet Of Things, new digital "ID" technologies have been developed. They can be divided into two classes, as shown in figure 2.1, explicit and implicit identification.

The explicit identification means that the identification phase requires an explicit action. In order to identify a target, the user has to put the target in close proximity to a specific device. The smart card such as SIM card and Java card are two main example technologies used in systems whose communication is ensured by electrical contacts. The memory integrated circuit includes embedded memory functions on modules with different forms and sizes. Contactless technologies, such as RFID 1 and NFC 2 , require close proximity between user and the recognition device. Indeed, some technologies like the barcode or 2D codes such as PDF417 3 and QR Code 4 require that the "things" be in the reader's line of sight. These systems require direct visibility, explicit action from user, no matter if the communication needs contact or not. The RFID has recently attracted extensive attention worldwide as a contactless identification technology.

The identification is not an aim but a means. Its purpose is to declare an information interface for the target object, in order to integrate it into the ICT system. This process, which we have called "Configuration", enables the ICT system to monitor and control "things" through the provided interface. Since the term Internet Of Things was invented by the founders of the Auto-ID Center of MIT [7], it has been used by researchers to describe the combination of the real world and the virtual world of information technology [START_REF] Atzori | The Internet of Things: A survey[END_REF] by means of automatic identification technologies. Thanks to advances in RFID technology and its falling cost, the Internet Of Things has suddenly become relevant for industry and end-users. On the other hand, the experience of building the IoT [START_REF] Welbourne | Building the Internet of Things Using RFID: The RFID Ecosystem Experience[END_REF] revealed some issues concerning its construction with RFID. Firstly the Tag Read Events (TREs) provide only low-level information and the metadata associated with tags must be personalized and carefully controlled in order to create a safe, meaningful user experience. Also RFID being a unique kind of identification, IoT applications must wait until the auto-identification is complete. Further IoT projects [START_REF] Wang | RFID Application in Hospitals: A Case Study on a Demonstration RFID Project in a Taiwan Hospital.I n System Sciences[END_REF][11] [START_REF] Ting | Critical Elements and Lessons Learnt from the Implementation of an RFID-enabled Healthcare Management System in a Medical Organization[END_REF] expose the RFID is inability to connect all "Things" automatically for IoT and their relevant applications.

Nowadays, implicit identification is the preferred research direction of IoT identification technology. Implicit identification integrates the identification target into the environment so that the system can "find" it automatically.

Configuration

Facing those requirements, many plug&play protocols have been developed. The following table 2.1 gives a list of the state-of-the-art plug&play technologies used in the home area. In order to describe the classic discovery and identification mechanism, we will focus on UPnP. and so on. Today, UPnP is intended primarily for home area network (HAN) [START_REF] Jeronimo | It Just Works : UPnP in the Digital Home[END_REF].

UPnP is built upon existing protocols such as HTTP, XML, SOAP, the Document Object Model and IP multicast. As shown in figure 2.2, based on these protocols, UPnP technology defines a framework to enable identification, integration and control of network devices. The UPnP device Architecture document [14] details the UPnP device operation as follows :

• Addressing : IP addressing is the basis of UPnP. Each device implements a DHCP client to acquire a unique IP address so that it may join the network;

• Discovery: Once a device has an IP address, it needs to be discovered. In (SSDP), which allows a device to advertise its services to the control point of the network;

• Description: After the networkhas been discovered, the control point does not have the details concerning the device. The description step describes the device information and its capabilities. By using XML, a UPnP device can express its vendor-specific manufacturer information such as the model name and number, serial number, manufacturer name, URLs to vendorspecific web sites etc. The UPnP device has to be identified as a unique device by the control point before monitoring and control can occur;

• Eventing: This operation allows the control point to monitor the UPnP device in active. This means that the UPnP device has to notify its current runtime state. The state notification protocol is defined as General Event Notification Architecture (GENA). These messages are also expressed in XML;

• Control : Once the device description obtained, the control point can send an action to UPnP service. This control action is described in XML using the Simple Object Access Protocol (SOAP);

• Presentation: The final step of the UPnP protocol is presentation. Thanks to the initiative of HTML, the control point can load the UPnP device presentation page into a web browser, where an end-user can view and control the device remotely.

UPnP technology is the foundation for higher levels of automation and new usage models in the residential area. But there are some problems with it such as the lack of authentication.

From exact and unique identification to approximate and contextual identification

The crucial issue of digital identification is its limit in identifying only connected digital "things", whereas the IoT should also have access to non-connected "things". By using the Home SOA standard [START_REF] Bottaro | Home SOA Controlling Home Pervasive Devices[END_REF] technique which can mask the protocol details of each supported technology mentioned above, the selfconfiguration problem for those plug&play-technology-embedded appliances in a target environment such as the home area may be resolved. Our thesis aims to resolve this issue but for non-digital appliances. They must be integrated into the network using a similar process but without the exact and unique identification.

For extending the IoT [16], "things" that are connected to the extended IoT do not need an explicit, pre-assigned and pre-registered universally unique identification attached to them. This is normally a prerequisite for "things" using the classical technologies we mentioned above such as RFID. In fact, it is sufficient for most applications to assume that things are identified in an approximate way.

They can be identified on a relative, non-universal basis in a given context or scope. It is the knowledge of the context, combined with the local identification, which can make the identification of things universally unique if needed. The representations of these things in the network will maintain contextual identification in a way that can be used by applications.

Approximate and Contextual identification does not require prior standardization nor the shared knowledge of a set of protocols in order to exchange this type of identification. A physical entity can be identified on the basis of its physical features, as these are sensed by the available sensors, associated with required context data as a complement. The "recognition" of the entity and its association with a known category relies on generic, publicly available knowledge and not on a matching with some proprietary databases. If it is not unique in a particular category, context (such as location) comes in to complement the category-based identification.

Wireless Sensor and Actuator Networks

A research report [START_REF] Yick | Wireless sensor network survey[END_REF] gives a full survey of another element of the IoT ecosystem the Wireless Sensor and Actuator Networks (WSANs). As mentioned in this report, the WSANs have gained worldwide attention in recent years and have significantly progressed due to the development of Micro-Electro-Mechanical Systems (MEMS) technology which has facilitated the development of smart sensors. In WSANs, the sensors are normally small, with reduced processing and computing resources, and inexpensive compared to traditional sensors. These sensor nodes are capable of sensing, measuring and collecting data, which can be raw and pre-processed, from the environment.

From the point of view of protocols, ZigBee1 is the mainstream technology in this area. It is for a suite of high level communication protocols using small, low-power digital radios based on an IEEE 802 standard. Thanks to these characteristics, ZigBee is applied by sensors to setup the WSANs.

Typically, a WSAN has little to no infrastructure, and consists of a number of sensors working together to monitor a region and to obtain data about the environment. There are two types of WSANs: structured and unstructured. In a structured WSAN, the sensor nodes are deployed in a pre-planned manner.

An unstructured WSAN on the other hand contains a dense collection of sensor nodes,which are deployed in an ad hoc manner into the field. Once deployed, the network is left unattached so that it can perform monitoring functions. The advantage of a structured network is that fewer nodes need to be deployed, lowering network maintenance and management costs. Fewer nodes are needed now since nodes can be placed in specific locations to provide coverage and ad hoc deployment can have uncovered regions. However, in order to ensure flexibility of sensor node deployment, IoT applications ofen require unstructured WSANs.

An analogue mechanism also exists in which, a set of actuators in a target environment constitutes an actuator network. These actuators perform actions that change the situation of the environment. Normally these actuators are wireless devices, that can receive data via a single electrical signal or high-level descriptive information as the order instruction. Based on the description in the previous section of current identification technologies in IoT, the easiest way to connect non-digital "Things" would be to create for each "Thing" a digital interface adopting one of these identification technologies. However, this is obviously infeasible, as it represents such a huge amount of work. Can you imagine attaching a RFID tag for everything? This is also an unfavorable solution from a cost point of view. Would any lamp manufacturer invest triple the amount to obtain an UPnP bulb? Even for digital "Things", this solution is not optimal as their interface cannot provide all their information. For instance, how we can know a kettle's power consumption information through an RFID tag? Thus using sensors to detect information from "things" is the preferred solution which we found for this thesis.

However, this does not mean attaching sensors to each "Thing". We present in this thesis a solution that provides an infrastructure for shared WSANs. The recent industrial program HOMES1 confirms the necessity of providing a shared sensing system in the building area. In this system, a Zigbee-based sensor and actuator network prototype has been proposed. Even at the city level, we can find research projects [START_REF] Lelah | SensCity: a new project opening the way for sustainable services in the city based on a mutualised M2M infrastructure[END_REF] that confirm the deployment of the shared WSANs. shared WSANs and their standardized interface, the home and the building as well as their components become sensed and actuated. We can easily develop our own application without physically changing the infrastructures of the home and the building.

Smart Objects and Smart Environments

In this section, we present the current development situation of Smart Objects and Smart Environments. As the background of our research work, this section explains the necessity of fusing both domains in order to match the term of "Thing" under the IoT framework.

Smart Object

According to the definition in "The Design of Future Things" by D. Norman [START_REF] Norman | The Design of Future Things[END_REF],

a Smart Object is an object that can have its own interaction with the user. With advanced electronic and information technology, computers and communication hardware have become small and inexpensive. We can thus consider embedding them in everyday objects. In this case, making an object smart involves giving it an interface, in order to transform it into a networked object. In 2008, CISCO and a group of leading technology vendors launched a consortium for Smart Objects: IPSO Alliance 1 . They define the sensor-actuator-equipped object as the "Smart Object". We can easily understand that with the help of embedded devices, the smart object's purpose is to transmit information about its condition or the environment to locations where the information can be analyzed, correlated with other data and acted upon.

Recent research [START_REF] Lpez | Taxonomy, technology and applications of smart objects[END_REF] provides a set of examples and potential applications of smart objects, in industrial areas such as retail, logistics, manufacturing control 1. Most applications are RFID-based, especially in the industrial area. They only provide low-level identification information and do not have the bidirectional interface allowing them to perform action.

2. There are a lot of "legacy" appliances, such as white goods in homes, that should become smart in a comprehensive way. Unfortunately home automation has mostly been focused on the improvement of a single appliance, such as the roomba1 or a single function with dedicated equipment such as heating or lighting. However these appliances or equipment should be considered in a global system as they may influence the global behavior in unpredicted ways. This means that making one specific device smart cannot stimulate the intelligence of a system.

3. The smart device cannot provide all the information. For instance, a UPnP washing-machine does not trace its power consumption, as it lacks an electrical power sensor. In other words, in order for a smart object to its full potential in terms of intelligence ability, it should be covered by common WSANs.

Smart Environment Smart Environment refers to digital environments that are sensitive and responsive to the actions of people and objects. It was originally developed in the late 1990s for the time frame 2010-2020. The term "Ambient intelligence" was presented for the first time in 2001 via the report "Scenario for Ambient Intelligence in 2010" [START_REF] Ducatel | Scenarios for Ambient Intelligence in[END_REF] published by the Information Society Technology Advisory Group (ISTAG) of the European Commission.

Streitz and Privat [START_REF] Streitz | Ambient Intelligence.I n C.Stephanidis[END_REF] identify and describe seven alternatives that are characteristic of the current situation on ambient intelligence. Among these alternatives, one concerns our research work. They point out that the only requirement in ambient intelligence is that the users must be identified and that an implicit contextual pseudo-identification is sufficient for less security-critical applications. Beyond the ambient intelligence, the first requirement should be that the environment identifies itself for the ambient intelligence. Approximate and contextual identification become a necessary approach. WSANs that are deployed in the environment take on such a role. They identify objects and control the ambient intelligence, so that the environment can be considered as a "Thing". A smart object itself can also serve as a special sensor or actuator for monitoring and control purposes when placed in the environment.

As mentioned in the introduction, conjoining the internet of things/M2M and "smart space" is in fact the fusion of identification, monitoring and control for the smart object and ambient intelligence. These two categories of "space" and "things" entities should both be integrated in a common infrastructure and interfaced through it in a unified way.

Application background

The application background focuses on four IoT applications present in the home environment: home energy management, personal care in home, home security and home automation. For each application, we begin by explaining why and how the IoT enables them as well as their architecture. We then lay out some ongoing research and commercial products as examples before explaining what they could be by our proposition. We limited the application background to the home area because of the three following reasons:

1. The shared WSAN infrastructure and interface should be deployed in an identical environment; 2. From a technological point of view, there is no standard model in this domain;

3. Our modeling and implementation work for both projects in which we were involved has been achieved in this domain.

Home Energy management

The two following quotes about efficient energy serve as a good starting point for this subsection : "This may sound too good to be true, but there exists a renewable-energy resource that is perfectly clean, remarkably cheap, surprisingly abundant and immediately available." Michel Grunewald, Time, dec 2008. "Efficient end-use of energy is the largest, fastest, cheapest, most benign, least understood, and least harnessed energy resource available", Amory Lovins, 2004.

In order to understand the current situation on energy in buildings a few key numbers have been listed below. Buildings account for approximately 25% of GHG 1 emissions, 40% of overall energy consumption, and more than 60% of electricity consumption in developed countries. Among these, residential buildings account for approximately 50%(tertiary buildings for 42% and industrial sites for 8%). Within this energy consumption by buildings, space and water heating accounts for 70%, specific usages of electricity (appliances and lighting) account for around 25% and cooking for the rest. The share of appliances of all categories (white and brown goods & ICT) has been increasing steadily. The European Action Plan for Energy Efficiency has estimated that the largest cost-effective energy savings potentially lies in the building sector, both residential (around 27%) and tertiary (around 30%). Here we are addressing the "low-hanging fruits" for efficiency gains.

With this requirements for energy-saving and emission reduction (especially in Europe), the home energy management application development is stimulated.

It is enabled by the IoT concept by using the ICT system and service. An overall architecture as well as components of ICT-based energy efficiency in homes and its functionality are listed as follows. A descriptive view is provided in the figure 2.4

1. The core of the energy management system, which consists of an optimization engine operating upon its input data from the monitored system as well as the inside and outside environment, uses a model of the building as a thermodynamic system and a model of the relevant criteria as objective functions to be optimized; 2. The home LAN that encompasses the whole building and provides data connectivity to sensors, actuators, sources and loads in various modes (wireless, powerline, wireline). The LAN is comprised of a main residential gateway that connects it to access and wide-area networks and secondary gateways that serve as bridges to capillary networks (e.g. Zigbee); 3. The set of electrical loads (appliances and all mains-connected equipments) monitored and controlled by the system; 4. The set of electrical sources (batteries, generators, PV modules) monitored and controlled by the system; 5. A set of networked sensors that monitor the state of the building environment, its equipments and its occupants; 6. A set of networked actuators that act upon the equipments and the environment in required ways (e.g. by turning on or off equipments, opening or closing blinds, etc.) using the output of the core system; 7. Interfaces between the building-scale energy management system, viewed as a home grid, and the wide-area smart grid of which it is a part: it applies the same principles but as an informational system superimposed on a physical system that is monitored and controlled at a larger scale; 8. User interfaces that may be local (for people inside the home/building), remote (for third parties) or mobile; 9. The wide area network that connects the home system to remote systems and interfaces (the core of the energy management system may actually be distributed remotely through the WAN). Our thesis focuses on the HAN level components, and aims to allow the ICT system to monitor and control the home legacy loads and sources (3&4) through the sensor and actuator network (5&6). Note that, as illustrated in the two figures above, the core home ICT system is capable of integrating and managing the WSANs through the provided and shared interface.

We list in table 2.3 ongoing European research projects on home energy management.

Homecare

Another important IoT application is that of healthcare information monitoring.

Different to energy management, healthcare is an active demand from both the public and private sector, especially for the elderly people and patients. Under the IoT concept, this application has two main functionalities:

• It automatically monitors a user's healthcare information by using sensors, and then analyses the information by using the ICT system. For example, an ICT-enabled blood-pressure meter can measure blood-pressure in realtime and analyze the user's state of health in a given period. It can then automatically report the measurements to the doctor;

• It automatically monitors the activities of elderly people and patients. This functionality is part of Ambient Assisted Living(AAL) of AmI. For instance, by using a presence sensor, we can monitor the time spent by an elderly person in the bathroom. In case of an abnormal situation, the healthcare ICT system can alert a medical team for emergency treatment.

Homecare information monitoring requires dedicated ICT-enabled sensors, like the "WIN Human Recoder"1 sensor. We need to design and fabricate the sensors according to the demands of consumers. This monitoring system is passive active, meaning it depends on the initiative of the end-user. If the user forgets or does not want to wear the sensor, the ICT system will not be able to collect the healthcare information.

Our background study focuses on the second functionality mentioned above, because we can achieve this by using WSANs with low-level sensors/actuators. These sensors and actuators are certainly shareable.

We find that the architecture described in figure 2.4 can be totally applied to the homecare system, especially in regards to elderly people monitoring. On an infrastructure level, we can simply change the logic part in order to transform a home energy management system to an elderly people monitoring system. As early as 1998, T. Tamura et al. [START_REF] Tamura | Fully automated health monitoring system in the home[END_REF] have provided health monitoring systems for elderly and disabled people at home by using fully automated signal measurements with personal identification in order to support daily health care and improve quality of life. The research work focuses on home activity recognition and prediction [START_REF] Tapia | Activity Recognition in the Home Using Simple and Ubiquitous Sensors[END_REF][27] using the recognition and prediction algorithm, but they hammer in the fact that the smart home infrastructure should be simple and shareable.

To conclude this section on homecare, we have listed research projects on healthcare information management in table 2.4. Note that all projects or works are based on simple and shareable sensor networks in the home area.

Project

In Brief TAFETA [START_REF] Arcelus | Integration of Smart Home Technologies in a Health Monitoring System for the Elderly.I nAdvanced Information Networking and Applications Workshops[END_REF] A smart home system for the elderly, developed by the Technology Assisted Friendly Environment for the Third Age (TAFETA) group. The sensor networks only include simple and shareable sensors such as thermistors, accelerometers, infrared motion sensors, microphone arrays etc. North Wales Telecare Project [START_REF] Think | Investigation of the potential for the joint procurement of telecare equipement and maintenance[END_REF] This project, led by North Wales Social Services Improvement Collaborative, is taking a collaborative approach to the development of Telecare services in the region. They identify simple and shareable sensors such as smoke detector, PIR motion sensor, temperature sensor and so on.

continued on next page I-stay@home ICT SoluTions for an Ageing societY involves housing providers as well as technical partners from North West Europe and aims to identify, select and test a range of affordable ICT solutions that can help elderly people continue living independently in their homes.

Home Security

The home protection system is also an interesting example of home IoT applications. As opposed to the home energy management and homecare sections, worldwide market demands confirm the importance of this application. In this section, we analyze only one commercial project, that a home video protection of high-level sensor and processing systems, as an example. Through this project, we will discuss how the home security application will be integrated into our area of research.

"Video2protect"1 is a home security innovation project. The principle of using video for home security is simple, one or multiple cameras film the home in real-time and stream to a remote server. The end user can access the remote server from a third-party terminal, for instance a mobile smart phone in order to supervise their home. "Video2protect" is equipped with simple PIR sensor that can detect an abnormal presence, in which case it triggers the camera to film or take a picture of the scene. The user is then alerted automatically so that they can confirm the intrusion. The end-user can then call the police immediately and use the recorded video or picture as proof.

In this scenario, simple PIR sensors transform the classical video supervision systems into an intelligent system. Furthermore, this approach is low-cost and easy-install. The "video2protect" application can also be integrated seamless to the architecture illustrated in figure 2.4. It is possible for the camera to be the only sensor in the home WSANs, serving the homecare application as well as the security application.

Home Automation

Home automation (Domotics) has now existed for more than 20 years2 .H o wever despite so many years of development and research, big advances promised initially, are still missing in this area. Although many reasons can be listed3 for this missed appointment, important changes still need to occur.

Over time, home automation has mostly focused either on the improvement of single appliances such as the vacuum cleaner or the TV set, or a single function with dedicated equipment such as heating. Our feeling is that equipment should be considered in a global system and may influence this global behavior in unpredicted ways. For instance, heating is mostly regulated by radiators. However, many other types of equipment can also influence the current temperature such as ovens, lights, computers and people. Energy consumption awareness is also a global on which all electric equipments have an impact. The ReactivHome project aims to manage sets of various equipments in order to optimize global parameters such as temperature, room luminosity or energy waste. In this project, home appliances are managed by a gateway that handles their statuses and triggers actions on them.

One main issue in a global management system is how legacy appliances are handled. The ReactivHome dedicates an important part of its activity to improving this issue without waiting for a 10 year appliance renewal model. The main challenge of this thesis is designing, in sensor and actuator-based environments, a appliance management architecture handling legacy home appliances, that is to say appliances that are neither build with a numeric interface nor with a numeric remote control. For each scale of environment a concrete example of smart ICT management system is investigated; 2. The information management section discusses related work at three distinct levels of information extraction, data aggregation on physical sensor system, entity state information identification of the intermediate level and high level information abstraction. This will cover the basic knowledge and current research work on sensor-actuator system networks, discrete event systems modeling and ontology.

Related Work

Smart Environments and IoT

As mentioned at the end of the chapter "general background", our approach reunites two strands of research that had been pursued separately under a broader ambient intelligence agenda [START_REF] Streitz | Ambient Intelligence.I n C.Stephanidis[END_REF], smart devices and IoT on the one hand, smart spaces/smart environments on the other.

At the home and building scales, context-aware services for energy saving have been proposed [START_REF] Byun | Development of a self-adapting intelligent system for building energy saving and context-aware smart services[END_REF] under a mixed smart space/smart device approach. Chen et al. [START_REF] Chen | Towards smart city: M2M communications with software agent intelligence[END_REF] deal with the city scale as a smart space, showing that smart spaces are receiving new and broader applications.

Home

Today, we can find a variety of research efforts concerning the home domain:

1. Home Area Network (HAN) infrastructure research starts with using power line LANs [START_REF] Lin | A power line communication network infrastructure for the smart home[END_REF] as a basic infrastructure for building integrated smart homes and state of the art HAN based on wireless networks[33].

2. From the point of view of software infrastructure, OSGi [START_REF]OSGi Servcie Plateform Core Specification Release 4 Version 4[END_REF] is indisputably the most important technology in the home area for enabling smart spaces and IoT. There is a lot of ongoing research on the OSGi-based infrastructure and architecture [START_REF] Gu | Toward an OSGibased infrastructure for context-aware applications[END_REF] [36].

3. Another research branch of the home ICT system is home gateway architecture. In contrast to the earlier areas of focus, particularly home gateway architecture for networked equipment [START_REF] Saito | Home gateway architecture and its implementation[END_REF] or multimedia devices [START_REF] Shlomo | Home gateway for video and data distribution from various types of headend facilities and including digital video recording functions[END_REF], current research on this subject concentrates on integrating the heterogeneous protocols into the home area network under the SOA-based architecture [START_REF] Bourcier | A dynamic-SOA home control gateway.I nServices Computing[END_REF][40] [START_REF] Chao-Lin | Service-oriented smart-home architecture based on OSGi and mobile-agent technology[END_REF] in order to provide the pervasive service [42][43].

4. Smart Home applications such as home energy management [START_REF] Chetty | Getting to green: understanding resource consumption in the home[END_REF] and its network infrastructure [START_REF] Han | Design and implementation of smart home energy management systems based on zigbee[END_REF], healthcare monitoring [START_REF] Chan | A review of smart homesPresent state and future challenges[END_REF], security monitoring [START_REF] Noury | Monitoring behavior in home using a smart fall sensor and position sensors[END_REF] and home automation [START_REF] Miori | An open standard solution for domotic interoperability[END_REF].

5. Algorithms for Home sensor data processing are also a wide area of research interest. In this domain, most studies focus on home context-aware services [START_REF] Yamazaki | Ubiquitous home: real-life testbed for home context-aware service.I nTestbeds and Research Infrastructures for the Development of Networks and Communities[END_REF] that recognize and detect the user's behavior [START_REF] Lühr | Recognition of emergent human behaviour in a smart home: A data mining approach[END_REF] or predict events based on observed temporal relations in a smart home environment [51].

Among these research studies on smart home ICT system architecture, a representative one aims to create an intelligent Versatile Home (MavHome). This work began in 2003, by Dian J. Cook et al. [START_REF] Cook | MavHome: an agentbased smart home.I nPervasive Computing and Communications[END_REF]. The initial goal of MavHome is to create a home that acts as an intelligent agent. The MavHome architecture [START_REF] Michael Youngblood | The mavhome architecture[END_REF] was finished in 2004, as shown in Figure 3.2, and consists of four essential layers from bottom to top :

2. The communication layer is available to all layers to facilitate communication, process mobility, and service discovery between components from the other layer. The communication layer includes the operating system, device drivers, low-level component interfaces, device proxies, and middleware.

3. The information layer gathers, stores and generates useful information for decision making. The information layer contains prediction components, databases, user interfaces, datamining components, voice synthesis and recognition components, and high-level aggregators of low-level interfaces (e.g., combined sensor or actuator interfaces).

4. The decision layer takes input information, learns from stored information, makes decisions on actions to apply in the environment, develops policies while checking for safety and security and selects actions to be executed based on information supplied from the other layers through the information layer.

With this architecture, a bottom-up perception process occurs. Sensors monitor the environment and make information available to information layer components via the communication layer. The database stores this information while other information components process the raw information into more useful knowledge. New information is presented to the decision layer components upon request or arrangement. The decision layer uses learned experience, observations, and derived knowledge to select an action. The decision is checked for safety and security and, if allowed, reports the beginning of action execution. Action execution flows top-down. The decision action is communicated to the information layer which records the action and communicates it to the physical layer. The physical layer performs the action, thus changing the state of the system and triggering a new perception.

In their physical system, they use X10-based [START_REF] Charles | X10: an objectoriented approach to non-uniform cluster computing[END_REF] devices in the form of lamp and appliance modules to control all lights and appliances. A key element in perception is inhabitant localization via a passive infrared motion sensor network.

Base on the MavHome architecture and the implementation of their physical system, a predictive framework [START_REF] Roy | A predictive framework for location-aware resource management in smart homes[END_REF] for location-aware resource management has

Buildings

From an ICT point of view, the situation in buildings is less mature than in the home domain. Over the past decade, most research efforts on smart buildings [56] have focused on cutting costs by streamlining building operations such as air conditioning and light. Recent research is setting out to develop an intelligent energy management system [START_REF] Doukas | Intelligent building energy management system using rule sets[END_REF] [58].

The ICT system is an important element for smart buildings. W. Kastner et al. [START_REF] Kastner | Communication systems for building automation and control[END_REF] introduces the notion that communication standards in buildings,

including BACnet [START_REF] Steven | BACnet¡ sup¿ TM¡/sup¿: a standard communication infrastructure for intelligent buildings[END_REF], LonWorks [START_REF] Loy | Open control networks: LonWorks/EIA 709 technology[END_REF] and EIB/KNX [START_REF] Ruta | Semantic-based enhancement of ISO/IEC 14543-3 EIB/KNX standard for building automation[END_REF] are of key significance in the building automation domain. D. Dietrich et al. [START_REF] Dietrich | Communication and computation in buildings: A short introduction and overview[END_REF] gives recent overview of communication and computation in buildings. According to this survey, smart buildings today have not only a huge economic potential but also a significant academic value.

In this subsection, we detail a referential smart building ICT system architecture by discussing the design and implementation of a smart building control system [START_REF] Han Chen | The Design and Implementation of a Smart Building Control System.I ne-Business Engineering[END_REF]. This work provides a software system perspective for improving energy efficiency in buildings. It proposes an architecture that allows phased investments in technologies in order to capture the returns from energy savings in various use cases.

As shown in Figure 3.3, the high-level system architecture consists of four layers:

1. The physical system layer contains the interface services for various building systems, such as the Heating Ventilation Air Conditioning (HAVC) system, the lighting control system, the building's fire and security system, and real time localizing system for personnel and equipment tracking; 2. The system integration layer interacts with the interface adapters via physical systems serving as the communication function to higher level systems.

The information flowing in this domain takes the form of events. They can be signals, measures, and commands to and from the subsystems;

3. The process integration layer aims to provide process orchestration and automation. It is built around an enterprise service bus that connects various software components throughout the smart building control system together. Service oriented architecture, an industry-proven software engineering approach, allows the integrated system components, such as correlated events, abstract building services, and historical data, to be choreographed to create reusable building management processes;

4. The business integration layer is the end-user-facing layer. The targets are the business users who are interested in knowing how the building is performing, how its performance can be optimized, and furthermore what policies or directives are needed in order to make an improvement.

On the software architecture of their prototype system, we can identify the three layers which are described above in Figure 3.1. The sensor and actuator layer aggregates the physical information. The sensor event processing layer identifies the entity state information and the business event processing layer is for the information abstraction.

In addition, they present an external input domain. It allows a smart building to be integrated into bigger systems, such as a campus building, or smart grids, smart cities, etc. Like the physical system domain, this domain contains interface adapter services that connect to various external data sources or information feeds. This domain is also connected to the enterprise service bus in order to allow the external information to be used by the process integration domain and the business integration domain. This extends the smart building control system scope. For example, energy price information and weather information allow the business to make informed energy consumption policies, which affects the building management processes. This scenario confirms the possibility of having a common approach for the smart space and IoT.

City scale

Compared to smart buildings, ICT infrastructures for smart cities are even less advanced, and verticalization of applications is even more prevalent. The work of defining and conceptualizing it is in progress [65][66]. Little academic research has found a solution at this level. To close the gap in the literature and the use of the concept, H. Chourabi et al. [START_REF] Chourabi | Understanding smart cities: An integrative framework[END_REF] proposes a framework to understand the concept of smart cities. They identified eight critical factors for the smart cities initiative, including the availability and quality of the ICT infrastructure. Indeed, smart object networks play a crucial role in making smart cities a reality.

According to IBM's proposition1 , the smart city covers three areas (Planning/management, Infrastructure and Human) and nine applications (Public safety, Smart buildings and urban planning, Government and agency administration for Planning/management; Energy and water, Environmental, Transportation for Infrastructure. Social programs, Healthcare, Education for Human). On a city level, the ICT architecture is built for each specific application rather than giving a common ICT to cover all areas. There are a few referential ICT architectures for smart cities but they are still limited to the utility networks [START_REF] Al-Hader | Smart city components architicture.I nComputational Intelligence, Modelling and Simulation[END_REF] or to a common M2M communication infrastructure [START_REF] Lelah | SensCity: a new project opening the way for sustainable services in the city based on a mutualised M2M infrastructure[END_REF].

Facing this situation, it is difficult to have a common architecture that covers all the applications in a city environment. The ICT system architecture presented in this section is concerned with the IoT environment, considered the largest scale in the city domain. In the book "Architecting the internet of things", one chapter [START_REF] Roelands | The DiY Smart Experiences Project.I n Dieter Uckelmann[END_REF] discusses the wide range of challenges encountered in user-generated internet of things applications, as is being worked in DiY Smart Experiences (DiYSE) project. The technical outline of DiYSE architecture, as shown in Figure 3.4, proves again that in the largest domain, the basis of architecture for the internet of things is also composed of similar layers to those pertaining to the home and building levels, referenced above. out the possibilities offered by homes that become active peers in smart electricity networks. D. Niyato et al. [START_REF] Warmer | Web services for integration of smart houses in the smart grid[END_REF] show how the smart grid connects with the smart home appliances via M2M technologies. An investigation led by S. Rohjans et al. [START_REF] Rohjans | OPC UA and CIM: Semantics for the smart grid[END_REF] provides an approach for integrating smart homes into the smart grid by using Web services.

Information Management

Sensor data aggregation

As mentioned in the background chapter, Wireless Sensors-Actuators Networks (WSANs) are an important element in the IoT ecosystem. The first level of information management is raw data acquisition and diffusion from the physical system via WSAN, as described in "Wireless Sensor Networks" [START_REF] Franck | Wireless sensor networks. Smart environments: technologies, protocols, and applications[END_REF]. As a smart environment relies on sensory data from the real world, it needs information about its surroundings, which is provided by distributed WSAN responsible for sensing and for the first stages of the processing. Rather than discussing the technologies of sensors or actuators themselves, this section will study the development and application of physical sensor data aggregation via WSAN in different smart environments as well as state of the art protocols.

The design of easy-use and portability characterizing wireless sensor kit is the foundation for this level's information management. In the work done by E.

Emmanuel et al. [START_REF] Tapia | The design of a portable kit of wireless sensors for naturalistic data collection[END_REF], sensors are used simultaneously with a single receiver used for raw data aggregation. Based on these sensors and the raw data aggregation system, the activity recognition application, more commonly used in contextaware home areas, has been developed [START_REF] Tapia | Activity Recognition in the Home Using Simple and Ubiquitous Sensors[END_REF]. Service-oriented middleware [START_REF] Gurgen | SStreaMWare: a service oriented middleware for heterogeneous sensor data management.I nProceedings of the 5th international conference on Pervasive services[END_REF] is also in progress in terms of heterogeneous sensor data aggregation and management.

The work done by M. Paksuniemi et al. [START_REF] Paksuniemi | Wireless sensor and data transmission needs and technologies for patient monitoring in the operating room and intensive care unit[END_REF] solves the patient monitoring problem caused by legacy sensors. Its result suggests the application of WSNenabled automated health monitoring. Many research studies and their respective prototypes have been listed in a survey paper [START_REF] Alemdar | Wireless sensor networks for healthcare: A survey[END_REF]. Baby Glove [START_REF] Baker | Wireless sensor networks for home health care.I nAdvanced Information Networking and Applications Workshops[END_REF], for example, consists of two integrated sensor plates placed on an infant's upper torso, containing a temperature sensor and electrodes that monitor the infant's pulse rate and hydration status. The device comprises of two motes, one is connected to the infant's clothing and collects vital information coming from the sensors and transmits them wirelessly to the second mote which is connected to the base station computer where it is processed. Another example is an activity recognition approach with location-awareness [START_REF] Lu | Robust location-aware activity recognition using wireless sensor network in an attentive home[END_REF]. They use a variety of multi-modal and unobtrusive wireless sensors seamlessly integrated into ambient-intelligence compliant objects(AICOs),which are ordinary household objects overlaid by a virtual layer. In the simple scenario for healthcare provided in Figure 3.5, we observe that the architecture is similar to our bibliographical framework(figure Context-awareness in smart environments achieved through the use of multisensors [START_REF] Hans W Gellersen | Multi-sensor context-awareness in mobile devices and smart artifacts[END_REF] has received attention in ubiquitous computing research for more than ten years. According to another approach for context-awareness [START_REF] Hong | An infrastructure approach to context-aware computing[END_REF], the benefit of the infrastructure is that smart devices and applications will be easier to develop and deploy. By sharing sensor data, individual devices will not need to carry every type of conceivable sensor in order to acquire the needed information. Recently, a vast body of research has addressed middleware for context management [5][81] [START_REF] Sakurai | Toward sensor-based context aware systems[END_REF]. As stated before, these context middleware infrastructures are merely a first step towards a joint "horizontalization" of smart environment and smart things applications, as their abstractions tend to be sensordata-centric and do not take into account the coupling of sensors and actuators through target entities, as proposed by this thesis.

Physical entity Information models

On the upper layer of information management architecture, collected raw data is consolidated in order to extract the useful knowledge for the decision layers.

According to the definition given by D.J. Cook et al. [START_REF] Cook | How smart are our environments? An updated look at the state of the art[END_REF], automation in a smart environment can be viewed as a cycle of perceiving the state of the environment, reasoning about the state together with task goals and outcomes of possible actions, and acting upon the environment to change the state. Therefore the useful knowledge is matched to a set of pre-defined models according to which we can represent the state of the physical "things"/"spaces" in real time. In this section, we take a look at the state-of-the-art in smart environments and IoT by providing a summary of research studies on information models of physical entities.

Discrete Event System Models

Before digging into the related work survey, we would like to introduce "Discrete Event Systems"(DES). From the point of view of physical entity information, smart environment and IoT are purely event-driven dynamic systems. With the DES model, the detected raw sensor data of a physical entity can be modeled as the discrete event information in order to represent a set of discrete states of the physical entities in the DES. This indicates a direction on the identification and monitoring of the physical "things" for our research. In addition, the DES model makes it possible to reunite smart environments and IoT as both of them can be considered as discrete event-driven systems.

As described in "Introduction to discrete event systems" [START_REF] Cassandras | Introduction to discrete event systems[END_REF], the motivation to model with "discrete event systems" is directly linked to the evolution of computing, communication, and especially sensor technologies. Some examples of discrete event systems are advanced monitoring and control systems in automobiles or large buildings; highly integrated command, control, communication, and information systems; distributed software systems, and so on. A significant portion of the "activity" in these systems, and sometimes all of it, is governed by operational rules designed by humans; their dynamics are therefore characterized by asynchronous occurrences of discrete events, some controlled, such as turning a piece of equipment "ON", and some not such as a spontaneous equipment failure. Some are sensed by sensors and some not. These features lend themselves to "discrete event systems" model. Taking this theory as the basis for our thesis, "things" or "environment" can be considered as a "system" and the raw information detected by sensors can be considered as a "state" to represent their real time status.

According to the first chapter in "discrete event system"[85], a "system" consists of interacting "components", and it is associated with a "function" it is presumably intended to perform. The "state" of a "system" at a time instant t should describe its behavior at that instant in some measurable way1 . In system theory [START_REF] Lotfi | Linear System Theory:{The} State Space Approach[END_REF], the term "state" has a much more precise meaning and constitutes the cornerstone of the modeling process and many analytical techniques.

Finite-State Automata

Another crucial theory for our research is the Finite State Automata [START_REF] Cassandras | Introduction to discrete event systems[END_REF], as it is the formal way to study the logical behavior of DES. An automaton is a device that is capable of representing a language according to well-defined rules. Figure 3.6 shows an example of a simple automaton. In the event set E = {a,b,g},t h e node represents the "state" and the labeled arcs represent "transitions" between these states. This directed graph provides a description of the dynamics of an automaton. The set of nodes is the state set of the automation. X = {x,y,z}.

The labels of the transitions are elements of the event set (alphabet) E of the automaton. The arcs in the graph provide a graphical representation of the automaton transition function, which we denote as f : X × E → X:

f(x,a)=x, f(x,g)=z f(y,a)=x, f(y,b)=y f(z,b)=z, f(z,a)=f(z,g)=y
The notation f(y,a)=x means that if the automaton is in state y, then upon the "occurrence" of event a, the automaton will make an instantaneous transition to state x. The cause of the occurrence of event a is irrelevant. The event could be an external input to the system by the automaton, or it could be an event spontaneously "generated" by the system modeled by the automaton. If we go further in automata theory, a summary of the finite-state automata can confirm the choice of our modeling work: The class of regular languages is the class of languages that can be represented by finite-state automata. Observer and diagnosis automata of finite-state automata also have a finite state space. Finally, with the theory study, we can prove that observer finite-state automata are used to solve state estimation problems for Discrete Event Systems.

Two concrete research studies relating to the home and building domains are discussed here. The first example is in the home area, provided by Juan C. Augusto et al. [START_REF] Carlos | The use of temporal reasoning and management of complex events in smart homes[END_REF]. Their concept of Event-Condition-Action (ECA) is trying to resolve a common problem, that of managing complex events in Smart Homes. It should be noted that the events can be considered as state information. ECA rule follows the form: ON event IF condition THEN action. This may cause the system to change its own perception about the state the home is in, for example from a normal context to a potentially hazardous context. The home being monitored is conceived as a dynamic system that goes through a sequence of states. Each state is defined by the place the person is in, where devices and alarms are activated, the temperature of the room, etc. Each of these parameters are discrete values, either boolean on/off or within ranges like those used for temperatures. Each particular combination of possible values defines a potential state the system can be in. The initial state is that the person is in the reception area and all detectors are off. Other parameters such as temperature of the room depend on the environment and have to be set accordingly. From the perspective of knowledge representation, the evaluation of the system will go through a cycle of state sequences Si which are provoked by event occurrences Ei registered as: S0; E1; S1; E2; S2; All the constituent parts of the theory (home, sensors, ECA rules, possible events, possible states and time spanning since the initial state until the current time of use) can be defined as discrete finite state.

In buildings, the finite state is applied for safety monitoring [START_REF] Snidaro | Video security for ambient intelligence. Systems, Man and Cybernetics, Part A: Systems and Humans[END_REF]. A video security application is implemented for detection of people, tracking and counting in a building environment. This system is based on a network of smart sensors that cooperatively aim to understand the movements and activities inside a monitored building. Simple events are represented by states of a finite automata, corresponding to simple actions such as walking, taking the stairs, taking the lift, etc. By matching these pre-defined finite automata, the system can determine and estimate the building's security situation.

Information abstraction

In our thesis research, information abstraction is about representing a set of physical entity state information via a higher-level description. For example, an energy management system would like to understand a high-level description rather than the low-level raw data. For instance, there is a pre-defined rule that authorizes the usage of high power electrical device from 8:00PM to 12:00PM. This allows the system to abstract raw electrical data into two different classes: high power and low power. The system can then just monitor the state of the high power device in order to save the energy. In this section, current research on the topic of information abstraction will be introduced.

Today, the mainstream approach to this domain is "Ontology". The word Ontology is composed of two ancient Greek terms, "onto" and "logia", meaning the philosophical study of being, becoming, existence or reality, and the basic categories of being and their relations respectively. In computer science, ontologies are the structural frameworks for organizing information and are used in domains, such as artificial intelligence, the semantic Web, systems engineering, software engineering, as a form of knowledge representation of the word or some part of it. According to T.R. Gruber et al. [START_REF] Thomas R Gruber | A translation approach to portable ontology specifications[END_REF], an ontology is a "formal, explicit specification of a shared conceptualization". Gasevic et al. [START_REF] Gašević | Model driven architecture and ontology development[END_REF] defines ontology as language which can be used to manipulate entities of a domain.

The first related study, an extreme example in this domain, is trying to build an ontology for a very specific term: sensors [START_REF] David J Russomanno | Building a sensor ontology: A practical approach leveraging ISO and OGC models[END_REF]. This work describes an approach to building sensor knowledge repository prototype compatible with evolving semantic web infrastructures. It is proposed that this ontology may serve as a component in comprehensive applications that include more advanced inference mechanisms. Such comprehensive applications will be used for synergistic fusion of heterogeneous data in a network-centric environment.

Another study on this topic has been led in the home area, by I.Joo et al. [START_REF] Joo | Developing ontology for intelligent home service framework.I nConsumer Electronics[END_REF], as shown in Figure 3.7. They determined the ontology in the home environment, and defined classes to conceptualize everything in the home, the playground of home services. Through the developed ontology, they classified services into several categories and described requirements for service execution. Then, they adopted the ontology for the intelligent home service framework called iHSF. The ontology for the iHSF has the form of Resource Description Framework (RDF) [START_REF] Beckett | RDF/XML syntax specification (revised)[END_REF] and Web Ontology Language(OWL) [START_REF] Mcguinness | OWL web ontology language overview[END_REF] in order to be interpreted by devices. Finally, the ontology can mirror the constantly varying environment of the home dynamically. iHSF using well-designed ontology reacts to the constantly varying context on a real time basis. Also in the buildings area, the DogOnt [START_REF] Bonino | Dogont-ontology modeling for intelligent domotic environments[END_REF] ontology supports device/network independent descriptions of homes, including both "controllable" and architectural elements. States and functionalities are automatically associated to the modeled elements through proper inheritance mechanisms and by means of properly defined Semantic Web Rule Language(SWRL) auto-completion rules which ease the modeling process, while automatic device recognition is achieved through classification reasoning. A section of DogOnt and a model sample in DogOnt is given in Figure 3.8. Thanks to ontology modeling, a framework for automatically generating and deploying state chart device simulators and emulators [4] from ontology descriptions of domotic environments has been developed. The proposed approach provides domotic system designers with both a powerful validation tool and an easy-to-deploy, incremental development framework.

Semantic-level models have been applied in both smart devices and smart environment research, relying on supposedly shared ontologies for knowledge representation and semantic interoperability. Many other ontology modeling studies that we have investigated [START_REF] Sommaruga | DomoML-env: an ontology for Human Home Interaction.I nProceedings of SWAP[END_REF][96] [START_REF] David J Russomanno | Building a sensor ontology: A practical approach leveraging ISO and OGC models[END_REF][97] [START_REF] Preuveneers | Towards an extensible context ontology for ambient intelligence[END_REF][99] narrow down the problem to manageable domains, such as the two detailed examples above in homes, or other domains such as ubiquitous computing devices or sensors. Mapping these domain ontologies to a universal or at least cross-domain ontology is still a long-term research objective. The primary goal of the Cyc [START_REF] Matuszek | An introduction to the syntax and content of Cyc[END_REF] project is to build a large knowledge base containing formalized background knowledge that can be used for research in a variety of domains. The OpenCyc1 platform provides a gateway to the full power of Cyc. The current release of OpenCyc 4.0 includes the core Cyc ontology whose domain consists of all human consensus reality2 .

The OpenCyc architecture consists of various elements all of which form the basis for knowledge acquisition and the reasoning process associated with it.

Knowledge acquisition using OpenCyc [START_REF] Kiran | Knowledge Acquisition using Opencyc[END_REF]allows the user to interact with Opencyc without any knowledge of its ontologies. Another example of OpenCyc usage is the COSE Ontology [START_REF] Wemlinger | The cose ontology: Bringing the semantic web to smart environments[END_REF] in which they defined a map from a concept in COSE also present in the OpenCyc ontology. This map is made available in a separate ontology because it uses the owl:sameAs construct. Our proposed approach also In their architecture, they integrate home appliances using the Echonet communication protocol. Joo et al. [START_REF] Joo | Developing ontology for intelligent home service framework.I nConsumer Electronics[END_REF] propose an Intelligent Home Service Framework (iHSF). In the iHSF architecture, a device handler is used so that the system can manage all existing devices in the home. They assume that a preexisting mechanism brings together and configures the handler and the corresponding physical device. DomoNet [START_REF] Miori | An open standard solution for domotic interoperability[END_REF] is an approach that helps integrate conventional home automation systems according to the service oriented computing paradigm.

The DomoNet architecture describes a SOA model which essentially consists of a network connecting application gateway called TechManagers(TMs). Each TM handles one home automation subnet such as UPnP and X10.

All of these solutions require not only that the target devices be endowed with the proper network interfaces, but also that these interfaces comply with corresponding standards at all appropriate levels, up to the semantic level. They also require that devices be identified according to a highly specific and previously known type, in order for their physical instances to be discovered. The proposed approach differs radically from previous work as it broadens the perimeter to integrate all non-networked legacy home appliances. It does not require prior equipment of these devices with standard network interfaces. Nor does it require that they be known on the basis of a specific type or make them belong to. They are identified only by approximation to a generic or semi-generic model.

Concerning the specific zero-configuration protocol, another very important domain of research and development has addressed a similar goal, that of network integration of physical entities, previously described in the "general background" chapter, with a focus on the low-end of the device spectrum. This is what the Internet of Things is all about, at least in its most widely received sense. RFID [START_REF] Welbourne | Building the Internet of Things Using RFID: The RFID Ecosystem Experience[END_REF] is, under all its variants and guises, the most widespread technology for this.

But the Internet of Things should not be limited to one individual technology.

The broader conceptual underpinnings of the present work have been laid out in "Phenotropic and stigmergic webs: the new reach of networks"[105] under the definition of "phenotropic interfaces" that make it possible to extend the reach of networks beyond sensors, so as to include in the network all kinds of physical items that have neither an interface in a digital networking protocol, nor a universal digital identification scheme such as RFID. In the approach presented here, the entities to be enrolled in the target ICT infrastructure are identified by iterative approximation to a model instance. Phenotropic interfaces, i.e. interfaces that operate through pattern recognition from multidimensional and multimodal sensor data, are just the intermediaries that support this identification process.

Proposed mechanisms for tag-based network re-source discovery and integration (e.g.. [START_REF] Mora | A unified architecture for supporting direct tag-based and indirect network-based resource discovery[END_REF]) could bring together the SOA/zeroconf and IoT/RFID approaches. However, they still require the preliminary association of entities with both tags and SOA types.

Towards self-configurable ICT architectures

From the existing self-configuration protocols, the current ICT infrastructure in the smart environment and IoT is not capable of automatically integrating the "things" that do not have the networked interface. Many projects and related research studies are based on this architecture, as shown in Figure 3.9. It summarizes the common layers present in homes, buildings, cities and the IoT domain, the basis of infrastructure for "communicating" with "physical things", and collecting "information" on their state in order to make "decision". The aim of our research is to propose a referential architecture, that is capable of self-configuring the physical system, as illustrated below in Figure 3.9, adding some functionality layers into the common infrastructure of smart environments and IoT, in order to identify and automatically integrate all the "things", especially the legacy ones into the ICT system.

Overall proposition

In this chapter,we first provide a global vision of our proposed framework. Then the definitions of important terms are given. In order to understand our concept, some concrete use cases are described in the second part. Finally, we give an overall illustration of our proposed approach.

Proposed framework

In Figure 4.1 we describe a conceptual model for a generic IoT/smart space infrastructure that consists of two layers, the upper most and lowermost layers being represented for reference only as they are not part of the infrastructure itself :

• Physical environment

• Devices (Sensors and actuators)

• Entity Abstraction

• Entity Group Representation • Applications
The Device layer is the interface between the ICT system and the physical environment. The Entity Abstraction layer corresponds to one-to-one mapping of physical entities with relevant informational models maintained within the infrastructure. By contrast, the Entity group representation layer is in a one-tomany many-to-one mapping with physical entities : it is capable of regrouping entities on the basis of common functionalities or properties. The Application layer is outside the scope of this thesis' research : it is the non-shareable part of the overall ICT system, including the dedicated applicative functionalities that use the information relayed by the lower layers, potentially sending back control orders that also get relayed by these layers to the physical environment. Note that each application in the application layer could bypass the upper layers of the infrastructure to interface directly with the Entity Abstraction layer or the Device layer.

The investigated environment is based on the home area. A home area is divided into two different types of systems. Similar to a computer system, there are physicals systems that are akin to the "Hardware" and the ICT systems that can be considered as the "Software". Some definitions of specific terms are described below in order to define the target scope and functionality of our proposed framework.

Entity

According to the definition of the word from the online Oxford dictionary1 , an entity is "a thing with distinct and independent existence". In the context of the IoT-i2 project, the word "entity" if preferred to "things" where internet of things is concerned. The "entity" could be a pallet, a truck, any consumer item, or also animate things such as a person or a cow. Dr. Stephane Haller3 takes a cow as an example to make the distinction between entities and devices, because the latter is something that cannot be connected directly to the communications network. The IoA-A [START_REF] De | Service modelling for the Internet of Things.I nComputer Science and Information Systems (FedCSIS)[END_REF] project gives a even more wide vision. An "entity" in the internet of things could be a human, animal, car, store or logistic chain item, electronic appliance or a closed or open environment.

Devices

A device, is a hardware component that is part of a target "entity"(e.g. a temperature sensor installed in a room) or attached to an "entity"(e.g. a smart plug connected to a kettle). Each "device" equips the hardware components for monitoring and controlling the target "entity". The communication with the ICT system is established through the embedded wireless network interface such as ZigBee. The interaction between the ICT system and target "entity" is achieved indirectly through these "devices". "Devices" that monitor are called "sensor", and those that perform the action are called "actuator".

A sensor can be:

• An actual physical sensor in the classical sense,i.e measurement device that digitalizes physical variables;

• A virtual sensor, i.e. a relevant source of information obtained through the network (e.g. information about the weather);

• An entity that can interact with other entities to provide indirect information;

• A human agent who can provide information about the target entity.

Aa c t u a t o rc a nbe :

• A separate stand-alone actuator (e.g. remote-controlled mains plug that can switch on/off an appliance connected to it);

• An actuator embedded in the target entity that can be controlled individually;

• A human being or robotic device that can perform a relevant action on the target entity.

A set of sensors and actuators are supposed to be available, connected and configured as part of a network of Wireless Sensor and Actuators (WSANs).

This network provides us with a unified interface to all connected sensors and actuators.

Self-configuration/reconfiguration

Under the concept of our proposed framework, self-configuration is a procedure that makes it possible to spontaneously and automatically integrate a physical entity into the supervisory ICT system. It concerns associating the sensors and actuators via WSANs and dynamically creating an information model in the information system matching the physical entity.

The term reconfiguration refers to the continually ongoing adjustments of the system to account for changes in the environment, such as removing or adding a new sensor/actuator.

Monitoring and control

Monitoring is concerned with the identification and tracking of instantaneous states of the physical entity by using sensors, on the basis of relevant sensor data. Controlling refers to change the state of the physical entity by actuators.

Use Cases

In order to identify the key research issue for self-configuration in the home domain, we analyze a home area use case in this section, taking energy management application as an example. In this context, target systems consists of all parts of the home and all pieces of home equipment that have a direct or indirect impact on the energy input and output of the home. This includes all appliances/rooms that consume, generate or store energy such as home components, that regulate the exchange of energy between the inside and the outdoors, walls and windows for example, but also, in a more indirect way, subsets of the home such as rooms that make sense as separate units in terms of energy management. Note that human users of the home are included either as actors or as part of the internal environment and never as part of home system itself depending on their role. The Environment of the home comprises, in a comprehensive definition, everything that has an influence on the state of the home excluding all specific actors listed in figure 4.2 and everything that is part of the system as defined above.

It can be specified into external and internal environments. The internal environment is composed of internal factors that are directly under the control of the home systems and are not within the perimeter of the home itself as defined above. The external environment includes two actors:

1. Neighboring homes that may have a direct physical influence on the target building (e.g.through heat exchange); 2. Weather (this actually encompasses several factors such as heat exchange from the atmosphere and solar radiation, as they have an influence on the energy functions of the home).

Home dwellers represent all categories of people who live in a home permanently, irrespective of their gender and status as owners, tenants, family members, etc. Distinctions can be made for more specialized actors. A few home dwellers are particularly aware of energy issues. These are the types of home dwellers who may wish to monitor their energy use in order to pro-actively change their behavior and conserve energy (i.e. voluntarily restrict their use of energy). Presenting this as a specialized role is meant to emphasize that it should not be expected that the majority of home dwellers will be doing this. By contrast, generic home dwellers could benefit from energy efficiency services that would optimize the use of primary energy while keeping the same level of energy service (or even improving the energy service). Technicians who may wish to control energy consumption could also benefit from this. An even more "special" category of home dwellers engage in pro-actively controlling their energy use in order to optimize the cost (e.g. shifting uses of appliances to take advantage of variable prices.) Again, pointing them out as a specialized type of user is meant to emphasize that the majority of users will not be doing this routinely and will instead expect the system to control energy use on their behalf, manual control being only an option.

As mentioned above, Monitoring provides not only the user with an instantaneous vision on the state of the individual entities, but also a global vision in order to draw a system operation trace(e.g. the consumption and production sources for the energy management application). In our proposed use case mentioned in figure 4.3, monitoring by the user can be performed locally or remotely.

The use case "notify user" refers to the system that warns the user automatically in case of abnormal operation or emergency.

Control manually use case takes data into account from explicit user commands so as to distinguish implicit orders resulting from activities not directed at the system and analyze them as elements of the context. These commands cause a consequential amendment of optimization. This is an extension of the optimize use case that will not be specified in our problem statement.

Configure use case corresponding to the self-configuration definition above, refers to both levels of configuration for entities and devices in the home area. Furthermore, it also concerns the manual configuration.

Use Cases

Integrate new sensors

«extends»

Integrate new actuators

«extends»

Integrate new appliances

Proposed approach

The problematic addressed by our proposed approach can be stated as follows (Figure 4.4): a generic extension of a home ICT system is set up to monitor and control individual physical entities. They are self-contained sub-systems of the home itself and fully-fledged physical systems in their own right. They can be, at their most relevant level of granularity, individual rooms of the home or regular home appliances (possibly including non-electrical appliances and energy generation or storage devices). Sensors and actuators are distributed as monitoring and control intermediaries throughout the home. Without any native ICT interface on these appliances, sensors and actuators are supposed to be the only means of monitoring and controling the target physical entities, providing an indirect coupling between the home ICT system and the home as a physical system.

The target entities of the home are defined as the components of the home.

They can be controlled and monitored by an application such as energy management, home security or home automation, all of which use the ICT system that is being setup in this way as a generic supporting layer.

The ICT system "shadows" or mirrors these physical entities individually by matching self-contained ICT entities that will in turn be the primary building blocks of its own architecture.

The ICT system should have the capability to create and configure these entities automatically, both for the initial configuration stage and when reconfiguration is needed due to a change in the environment. This implies the need to automatically associate the subset of sensors and actuators that are used as intermediaries that monitor and control a given entity, and to update the model of the entity accordingly.

The proposed approach is capable of dynamically creating a "shadow" ICT component for each individual target entity in the home. We define this logical component as the Entity Identification, Monitoring & Control component (EIMC). It connects to the physical entity through a dynamically configured set of potentially shared sensor and actuators, chosen among those available in the relevant environment. The sensors detect events and changes of state concerning a physical entity as their inputs and the EIMC sends the control commands to the actuators that execute the required actions on the physical entity. The system comprising the EIMC together with the physical entity and the sensors and actuators makes up a closed-loop control system.

ICT System Home physical entities

Detailed proposition

In this chapter, we specify our three propositions. The proposed architecture is detailed in three parts. We first introduce the functional architecture of the core component EIMC, followed by the architectures and their modules of the proposed layers. In a second section, we give an example of a proposed model in order to explain our contribution to entity discrete state modeling. Then we discuss the process of the configuration and identification of our modeling. The final section is dedicated to a home domain ontology model for home appliances and home spaces.

Referential Architecture

EIMC

The proposed solution dynamically creates an ICT component "shadow" or proxy for each individual target entity of the physical system. As shown in figure 5.1, the EIMC connects to the physical entity through a dynamically configured set of potentially shared sensors and actuators, chosen among those available in the relevant environment. The sensors detect events and changes of state from a physical entity as their inputs and the EIMC sends controls to the actuators who carry out the required actions on the physical entity. The system comprising the EIMC along with the physical entity, the sensors and the actuators forms a closed-loop control system.

To elaborate on the solution described above, a more detailed mapping on an actual information system is shown in 5.2. The overall information system consists of an application layer supported by a more generic EIMC layer, itself comprised of a set of EIMC instances coupled to physical entities. This layer is the abstraction layer (figure 4.1). The application layer contains applications that can use the data and functionalities provided by the EIMC layer in order to monitor and control the target entity. The abstraction layer acquires and generates useful information for the application layer through each EIMC. The architecture is one EIMC instance within the abstraction layer. The key role of the EIMC, as mentioned above, is to represent an abstraction of a physical entity such as a home appliance in the information system. We can deal directly with the EIMC in order to retain up-to-date information on the state that the physical entity is in. We can also transmit control information to actuators associated to the EIMC in order to perform actions on the target physical entity.

Target Physical Entity

As a closed-loop system, EIMC can also act as an autonomous control system in order to locally adjust the physical entity without intervention from the external application layer.

EIMC

Entity state identification and estimation (Monitoring)

• Sensor Interface Module: This module encapsulates the interfaces of the sensors for compatibility purposes and is implemented in the EIMC layer as a static component. It is capable of covering all of the sensors' communication protocols and transferring the different data formats to a unique defined data format which can be read by the Classification module. According to the notification on Classification modules, the Sensor Module can dynamically collect the data packet sent by sensors, send them to the classification module that then classifies the current state of the target entity.

• Classification module: This module is a pattern recognition-based classification engine that uses a recognition algorithm matched to the specific model of target entity. When a new entity is installed and discovered, a "generic" EIMC is created, and it identifies the corresponding states by using a "generic" recognition algorithm. • Actuator Interface Module: The actuator module can translate each task scheduled in a defined data format and send it to each associated actuator through its interfaces, which include the actuator network protocols.

EIMC lifecycle manager

The EIMC lifecycle manager(Figure 5.3) reflects the identified states of the target entity via a Runtime State Automaton (RSA). As present in related work, RSA is a pre-defined discrete event state automaton model which describes the behavior of an entity. For instance, an electrical appliance has a RSA with two discrete event states ON/OFF. The ON state switch to the OFF state under some transition conditions. Additionally, the EIMC provides an interface with the application layer and triggers the reconfiguration stage by detecting state inconsistencies. From the physical entity point of view, this component is its abstraction. For the rest of system, it plays the role of a "proxy" for the target entity. This component comprises the following elements: and can transfer commands from the application layer as the destination state information to the abstraction layer for its own EIMC;

• Structural interface: This interface provides the entity's structural properties to the application layer. The structural property describes the absolute physical parameters of entities such as the room surface or the appliance weight. It also represents the relative parameters, for example the location of an appliance entity in a room entity.

• State persistency: This module receives the classified state information and the associated attributes, and stores this data as a current state. If the query is made by the application layer, this module can also send back device information such as the current state, instantaneous data describing the current state. This information is persistent allowing the EIMC to make a decision by comparing the current and destination state.

• Model verifier. This module verifies the coherence between the loaded RSA and the identified state. If the identified state cannot be matched, it will trigger a reconfiguration at the model identification stage. When a given state in the loaded RSA cannot be reached after several cycles of monitoring, it will trigger a reconfiguration of the model parameterization.

• Control loop switch: To achieve the closed-loop, the EIMC can generate a system switch between a closed-loop and an open-loop thanks to a switch mechanism. This mechanism is capable of making the system more flexible, because the choice depends on the result of the RSA. For example, if no update is received from RSA for a long time, the system assumes that there may be an issue with the sensor. In that case, EIMC can ask the "controlling" module to ask an actuator to perform some action on the entity, in order to verify the status of the sensor. This move can not only ensure that the sensor is working normally, but can also guarantee the execution of commands by the application layer. Indeed there are some commands that need a feedback so as to asses whether or not the action has been achieved. The EIMC thus asks the sensor to verify the result of the action. The switch can make the decision by checking the output of the "RSA" and the input of the "Controlling" module.

The two proposed Layers

Our framework, as described in the overall proposition chapter, revolves around two layers of the smart environment and the IoT architecture: the Abstraction Layer (AL) and the Entity Group Layer (EGL). This section specifies the architecture for both of them. In brief, the Abstraction Layer holds a set of EIMCs that represent the physical layer, and the Entity Group Layer dynamically groups EIMCs. The architecture can be drawn simply, as illustrated in figure 5.4.

Abstraction Layer

AL has three main functionalities: Dynamically creating EIMCs to connect entities to the physical system, providing services and publishing entity information and integrate both of them. These pieces of information are published as a view of configuration via front-end. The instantaneous state information as well as the commands will be "put" in and "gotten" from the published view in the AL front-end by each EIMC. The functionalities of each main block component are listed below.

• Sensor and Actuator interface module: the two modules have the same communication functionality with the device in physical layer. Different from the sensor module in the EIMC, the sensor module in the AL collects all data from the different sensor devices and aligns them so that they may be sent to the global context monitor. The sensor module in EIMC is only used for communicating with the associated sensor devices. Similarly, the actuator interface module in the AL collects all scheduled action data from different actuator modules of the EIMC and sends it to all actuator devices in physical layer.

• Global Context Monitor: this module determines the context of the physical environment. It is capable of discovering the presence of an entity by analyzing single or aligned sensor data. For example, upon the detection of power consumption, which can be considered as a significant event by an electrical sensor, the context monitor creates an EIMC that represents the discovered entity. In addition, this module communicates with the WSAN in order to dispatch the associated sensor data to the corresponding EIMC and sends commands to the actuator.

• Identification and Estimation module: this module is an identification engine container, where the different identification applications are implemented. In the AL layer, this module provides identification service API for each EIMC. In our concept, the identification application is set up as a black box, which can be not only a local component but also a remote component in cloud. For example, a powerful home electrical appliance identification engine is implemented on a application server. This module can abstract the identification web service interface to each EIMC in the AL with the API.

• Ontology manager: this module implements the Ontology parser for matching and loading the pre-defined entity model from the online shared ontology repository.

Entity Group Layer

This layer dynamically and automatically create one or several ICT components that group configured EIMCs. It is called the Entity Group Coordinator (EGC).

There are two mains functionalities of this layer: communication with the upperlayer to get requests from, the application layer for example; and to find the group entity model for the EIMC in the lower layer using the shared ontology between the AL and the EGL. This layer can publish entity group information through the front-end. The Information publisher and Ontology manager modules have the same mechanism as the one in the Abstraction Layer, but they use it for different purposes. In the AL, the ontology manager resolves the individual entity model, but in the Entity Group Layer, the ontology manager aims to regroup the individual entity model by matching identical parameters. For instance, it can regroup all entities that have high power consumption or regroup the entities responsible for heat distribution.

Application Request Communicator: it is used to communicate directly with an application in order to get the requirements so that the ontology manager can load the corresponding group model from the ontology. Note that the selfconfiguration of this layer can also be performed without a request issued by the upper layer. In this case, it can provide the most generic entity group information depending on the configured Abstraction Layer.

EIMC information publication

• Front-end: it is a communication layer. Such as a "REST"-based lightweight web server. This layer handles the entity configuration view. Once the view is created, each EIMC is represented as a node of information, such as an URI in the case of a web server, in order for the external application to access the AL through specific protocols, for instance the HTTP.

• EGL and AL View: it publishes the entity configuration information in the external layer. The two views can generate a predefined file such as XML or JSON and provide web service to "POST" them in the Front-end.

Entity Discrete State Modeling

Physical entity state

Theoretically, consider the target entity to be a full-fledged system. Its state vector S(T), a function of time T, can be defined theoretically as encapsulating the necessary and sufficient information to predict the future states and outputs of the system given its future inputs. This comprehensive definition has to be restricted for practical reasons to state dimensions that are actually relevant for the target application. For energy management application in the home domain, for instance, the energy-relevant entity should comprehend their state as a thermodynamic state, which may comprise the amount of energy they are actually consuming, storing and generating. For a home automation application the mechanical state of these entities is more relevant.

Being continuous as they normally are in a physical system, these states may, for simplicity, be lumped into "discrete state categories" (e.g. a mode of operation for an appliance) that could correspond to the states of a simpler discrete-state model. This finite-state model can be made richer by complementing discrete state variables with continuous variables (attributes) that capture relevant properties related to the state (e.g., time spent in that mode, temperature, percentage filled, etc.). These digitized states along with the relevant attributes are then stored as the shadow ICT subsystem's state.

Monitoring is involved with the identification and tracking of these instantaneous states of the physical entity, on the basis of relevant sensor data. Controlling refers to changes to the state of the physical entity via actuators.

We chose to model the physical entity with discrete finite-state, discrete-time models, in which state information is possibly complemented with continuous attributes. These states and the relevant attributes are then stored as the state of the shadow ICT entity. These models represent a trade-off between impressibility and ease of identification. The full description of a physical system such as the target physical entity would normally require a continuous state & continuoustime model, but automatic identification of the parameters of such models would be nearly impossible. Examples of such models are given below for a generic washing machine.

A generic washing-machine contains 7 discrete states as illustrated in figure 5.5. The transition between two states defines the possibility of a changing state.

For each state, one/several continuous variables can be detected by the associated sensing devices. By matching this model, an EIMC washing machine entity can be instanced. Then, in the upper layer, a group entity coordinator can also be instanced by grouping all of the EIMCs that are in "Standby" state. this allows the electrical appliance to turn off when in standby state for energy efficiency.

Processes

Incremental identification, model matching in real-time from the ontology and Closed-loop operation with actuators are the three key features describing the process. The details are specified in this section in diagram 5.6.

EIMC Initialization

Global

EIMC initialization

The initialization process spawns a generic EIMC whenever a new relevant physical entity is detected. As shown in figure 5.6, a global context monitoring module discovers a new physical entity by monitoring the environment to detect significant events. The discovery of a new physical entity occurs through the detection of signals, marking the presence and/or activity of such an entity through relevant sensor events. By sensors in their broader sense. For legacy entities devoid of data network interfaces, this is done by using sensors in the classical sense. When such a new physical entity appears in the monitored environment, its activity or mere presence may trigger some significant sensor events or tell-tale patterns. Those events or patterns can be captured by several sensors available in this environment and subsequently analyzed to trigger the discovery mechanism. For example, a vibration sensor can detect the presence of a fridge when the compressor of the fridge kicks off. The process may also take into account explicit notifications by human agents or announcements in relevant network protocol for entities that have a network interface. Both correspond to "sensors" in a virtual sense.

EIMC configuration

• Association of the sensor and actuators. Once the presence of a new physical entity is detected, the system associates at least one sensor and one actuator to this entity. This means the corresponding sensors and actuators are used as nonexclusive intermediaries used to monitor and control entities. New sensors and actuators can later be associated to an entity whenever a meaningful correlation is detected between the entity state and events or patterns detected by these sensors, or when commands are sent to the actuator. The association processes leads to the integration of the sensors/actuators interface provided by WSANs into the AL.

• Identification of discovered or previously-configured entities. This is the matching of an entity to an individual category in the target domain-specific ontology. This category may be very broad or very specific, depending on how much sensor data the system has in order to perform the identification.

The chosen category is associated with a default model of the target entity.

The model is a simple finite state model of the corresponding system, complete with relevant state attributes and default values for these attributes. • Dynamic update of EIMC parameters. Once a given model has been identified, parameters for the corresponding model may be updated incrementally from new sensor data and the model may be modified so as to better fit the observations. This may correspond to either changing continuous-valued state attributes, invalidating state transitions, or removing states from the state diagram. An example of this mechanism is shown in figure 5 The configuration step described here is not a one-off sequential process. After detecting the presence of a new physical entity and having gone through the initialization stage once, configuration goes on cyclically.

EIMC runtime

• State identification and estimation is the monitoring process in real-time.

During the actual runtime, the EIMC identifies the instantaneous states of the target entity and estimates the relevant dynamic attributes of this state (e.g. temperature, time spent in this state).

At runtime, the EIMC aggregates and analyzes the data that are sensed by associated sensors in order to identify the state. The identified state is then "shadowed", that is to say, maintained as an internal state of the EIMC in the system. An identification engine is used to map the patterns detected from combined sensor observations to a target state of the model system.

• Controlling changes the state of the identified entity to a desired reference state. From the point of view of state changes, a high-level command is a reference (destination) state in which the entity will be. This command consists of associated state attributes. This command may come from an external application or from the lifecycle manager itself in a closed-loop control mechanism. If the current internal state requires it, the EIMC orders the associated actuators to change the actual state of the entity.

The changed state has to be confirmed by the monitoring system, or, the closed-loop control mechanism.

• The EIMC life-cycle manager is the core of the EIMC which orchestrates both the EIMC runtime and the EIMC configuration in two nested combined cycles. During EIMC runtime, the EIMC lifecycle manager reflects the current states of the corresponding system as illustrated in figure 5.7.

At any time during the monitoring stage, the EIMC may go into a reconfiguration stage.

Classification and identification engine

The EIMC classification engine is a fundamental element of the system. It selects the best prototype from a multidimensional dataset of sensor readings. Various algorithms from the machine-learning domain may be used for this. Based on this principle, it has three uses: identification of the best approximating model of the target physical entity; identification of the instantaneous state of the entity according to this model, and state sequence consistency checking. For instance, at the beginning, the recognition engine identifies the type of the detected washing machine and spawn a generic washing machine model. Then, the newly captured data is used to find which state the washing machine is in, matching one of the defined automaton states.

Closed-loop control

In the proposed set-up, the EIMC coupled with its associated sensors and actuators, operates according to a target entity's closed-loop control mechanism.

Normally, closed-loop control uses monitoring to verify and correct the result of the action performed on the entity. For example, if we use an actuator to turn the heating up, the monitoring will confirm the effect by checking the temperature, while taking into account the appropriated delays. If the actual effect differs from the desired state, a correcting command is sent that is proportional to the difference between the desired state and the actual state, thus completing a stabilizing feedback mechanism.

In a reciprocal way, monitoring can also use the control and actuators as auxiliaries. For example, to avoid false positives, the EIMC can require an associated actuator to turn off an electrical device and check the associated sensor's status to ensure the sensor is working properly.

There is also a mechanism in the EIMC that is able to switch the system between a closed-loop and open-loop. The purpose is to make the system more flexible.

This closed-loop control principle can also be used for the configuration process: stimulating the entity with actuators can help match known properties of a given model(e.g. how it behaves when stopped and restarted).

Home Domain-specific ontology modeling

The characteristics described in the annex as a complementary criteria are used for selecting the legacy appliances that are handled by our system. These criteria may not be selected in a real system today. However they are considered as the predictable criteria for legacy appliances handled by smart home management systems such as the one we propose today. ICT appliances are overrepresented with respect to their energy consumption, but this can be justified by the following reasons :

• They represent a category in augmentation.

• One report in 2008 1 shows that the obtained efficiency gain in the domestic appliances domain has been absorbed by the consumption of the ICT appliance.

• They can have a networked-interface that the system could control as finely as possible.

• They are the most visible element to the end-user, who interact with them for not only utility purposes but also emotional ones.

The classification of the entities provides an extended specification of the maximum perimeters for a domain-specific system such as a home. This not only the defines the scope of the modelling work but also defines the perimeter of domain-specific implementation. The figure 5.9 shows a view on the different categories of appliances that can be found in the home area.

Discrete state ontology for home appliance

Our approach is based on a pre-defined ontology that captures generic knowledge about the devices, appliances and rooms of the home domain through a multicriteria hierarchical categorization and the definition of generic discrete finite state models for each of the target entities. Initiating and configuring the EIMC for a given entity involves identifying, loading and iteratively adapting the most appropriate entity model from this model repository.

Examples of such models are given below for a category of appliance, a generic washing machine, and a category of room, a living room modelled by its different states. This ontology subsumes several relevant categorizations of the appliance or room. As illustrated in figure 5.10, it can be structured as a directed acyclic graph that makes it possible to follow a path from the most generic parent models, closer to the root of the graph, to the more specific models, closer to the leaves. At the root is the main class entity, which in the scope of this thesis specializes into two descendant classes: appliances and rooms. Appliances and rooms can in turn be specialized and classified according to several different criteria that are either intrinsic to their main usage or relative to the application, such as energy management or energy efficiency. Examples of these criteria are illustrated below, each of them corresponding to intermediate nodes in the graph. Models are associated not only to the terminal nodes of the graph corresponding to the most specific categories, but also to the intermediate nodes. This full hierarchy of models provides a mechanism to identify an entity in an incremental way on the basis of observation data. It starts from the most generic model if the observed sensor data is inconclusive and refines this first match to more specific models down the graph when further observation data become available.

Discrete state ontology for rooms

As constructed above, subsets of the space can also be considered as relevant target entities that can be included in the ICT system perimeter. In the home domain, a single room can be modelled, as shown in Figure 5.10, in a way similar to what is done with appliances. At larger spatial scales, in a city-district domain, an equipment entity could be a bus stop for instance and a corresponding space entity could be a street or block of buildings.

DETAILED PROPOSITION

Duration

6

Implementation in Homes

Prototyping

As a proof of concept, we developed a prototype whose goal is to show how to handle sensor data, build an EIMC and notify client applications when the corresponding state changes. The prototype performs state identification on simple home appliances.

Overall prototyping system architecture

The EIMC management system is hosted on a dedicated home server called the Home Automation Box (HAB) in order to build the Home Abstraction Layer (HAL) and it is connected to a wireless network of sensors and actuators (WSN).

As shown in Figure 6.1, the system hosted on the HAB maintains a virtual representation of each physical entity as a distinct EIMC instance. Those representations communicate with the application layer via the managed physical subsystems. At the bottom of the HAB architecture, a sensor/actuator layer provides an abstraction of the various types of connected sensors [START_REF] Gurgen | SStreaMWare: a service oriented middleware for heterogeneous sensor data management.I nProceedings of the 5th international conference on Pervasive services[END_REF]. EIMC. Note that the "root" EIMC, the "Generic" EIMC and the "specific" EIMC have the same architecture, in order to keep the same recognition mechanism.

Management System

Home Abstraction Layer

EIMC root EIMC A Specific EIMC A Generic SIMC B Specific

EIMC B Generic

Sensors/Actuators adaptive layer

Sensed Data Control

OSGi-based system

The OSGi specifications [START_REF]OSGi Servcie Plateform Core Specification Release 4 Version 4[END_REF] define a standardized, component-oriented computing environment for networked services that is the foundation of enhanced service oriented architectures. Using the OSGi framework for HAB adds the capability to manage the lifecycle of software components. They can be installed, updated, or removed on the fly without ever having to disrupt the operation of the HAB. 91

IMPLEMENTATION IN HOMES

Core features of OSGi are based on an original Java class loader architecture that allows code sharing and isolation between modules called bundles [START_REF] Bottaro | Dynamic web services on a home service platform[END_REF]. A bundle contains Java classes that implement zero or more services. Bundles are deployed in an OSGi service platform to provide application functions to other bundles or users [START_REF] Lee | Enabling smart spaces with OSGi[END_REF].

Our purpose in choosing OSGi is enabling HAB application reconfiguration at runtime. Therefore, each EIMC functional module is modeled as a bundle and its application functions are packaged in the bundle as services.

To achieve the full functionality described in section 4, we model the architecture of the EIMC management system as shown in Figure 6. The Sensor Module bundle communicates with all the sensors in the HAL

Home Automation Box

Our prototype system is implemented on a plug computer, which acts as a HAB, in order to host the HAL prototype. Figure 6.4 shows a sketch of the HAB hardware environment and software architecture. The sheevaplug1 is the plug computer that we use, it contains

• A 1.
2 GHz microprocessor and 512MB of memory;

• AC l e od e2 wireless current sensor as the specific sensor setup;

• Linux Debian operating system;

• Java JDK 1.6 with the Apache Felix OSGi framework, implemented for the software system;

• The HDM3 sensor data acquisition system, which acts as the sensor's adaptive layer to communicate with the Cleode sensor kit via the ZigBee network.

To validate our prototype, the system streams the maximum amount of data from the sensor mote or sensor mote simulator to the Sensor Module (HDM) in order to give it the best chance of arriving at a precise result. The system loads the pre-defined models needed to identify and monitor an appliance such as a kettle with these detected data.

Below is an illustration of how the HAB functions in order to identify a kettle.

When we plug the Cloede current sensor to a kettle and turn the kettle on, the active HDM discovers this event via the electrical data stream coming from the current sensor. Once the event is detected, the life-cycle service loads the identification service so that the type can be recognized. During this step, the identification service associates this sensor with the kettle in the Sensor Module in order to obtain further data. In the meantime, the life-cycle service also loads a RSM which represent the HAB state as identifying the type of "discovered entity". A generic EIMC is created by the identification service and the system state RSM service. Once the generic EIMC recognizes the kettle, the life-cycle service loads the kettle state predefined model from the ontology repository. This kettle state recognition service then associates with another sensor in the HDM and a kettle RSM service is also instantiated. The kettle EIMC management system consists of the kettle state recognition service and the kettle RSM service as well as the associated sensors. The kettle state change is communicated in realtime to an external application, a GUI for example. This HAB proves that our concept of EIMC management system is feasible for home appliance identification and monitoring.

Ontology implementation

The ontology implementation concerns two aspects of our work: the creation of an entity classification model as well as an entity state model and the implementation of an OntologyManager, which is in the prototype architecture shown in figure 6.3. Note that we are not trying to propose a general ontology for smart environments and IoT domains. The implemented ontology and the ontology management module validate our prototyping work, as explained in the proposition chapter. We assume that there should and will be a large commonsense knowledge base [START_REF] Matuszek | An introduction to the syntax and content of Cyc[END_REF], which our domain-specific ontology can be mapped into [START_REF] Stephen L Reed | Mapping ontologies into Cyc[END_REF].

Appliance Ontology Implementation

Creation of the ontology model consists in fact of the OWL [START_REF] Mcguinness | OWL web ontology language overview[END_REF] model, created by an ontology modeling tool called "Protégé"1 . W eusetheProt égé-OWL editor to build our ontologies. Our model is to be used for the Semantic Web, since the web of things [START_REF] Guinard | From the internet of things to the web of things: Resource-oriented architecture and best practices.I nArchitecting the Internet of Things[END_REF] is actually the trend for development of smart environments and IoT. A significant article [START_REF] Noy | Creating semantic web contents with protege-2000[END_REF] presents in detail how to create the OWL with aProtégé-OWL editor, we would like to showcase two pieces of our ontology. The first simulates a general classification of the knowledge concerning appliances in the home area and the other shows how we model the state of a home appliance, with a kettle taken as an example.

As shown in figure 6.5, the home appliance ontology is modeled as a directed acyclic graph (DAG). This graph describes a piece of our domain-specific ontology proposition for the home area. The concept of this model is that the ontology root describes the domain, in this example, the appliance. A final node aims to describe a concrete appliance such as a radiator, a kettle or a water heater. Between the final node and the root node, there are different levels of classes that describe the appliance categories according to the appliance characters. For instance, an appliance that uses electricity is categorized into the ElectricalAppliance node.

By matching events that are detected by single or multiple sensors, the monitored appliance in our prototyping system can iteratively reach the appliance model.

Entity State Ontology Implementation

A complete chain is proposed in order to detail how the prototyping system identifies a kettle with this ontology using a water sensor and an electrical sensor.

The water sensor detects a water event in the home environment. This tells the system that there is a WaterAppliance present. Then, the system is told that this appliance consumes electricity thanks to the electrical sensor. Hence, it identifies this as a UsingWaterElectricalAppliance. Then, the system determines that this is a kettle, as there is just one node that is a UsingWaterElectricalAppliance in our ontology example. The appliance ontology is a non-instance ontology, meaning it ontology describes a taxonomy or classification for system identification purposes.

For each node found by the system, there is an associated state representation ontology.

A runtime state model is attached to each node of this appliance ontology.

Once the system reaches a node, it can also figure out and represent the state of the identified appliance by matching and monitoring this state model. This model is modeled in the same way as a sub-ontology in order to describe the appliance's state. The concept is quite simple, with one class : state and a property : transition. We create the state instance to describe its different statuses, and the transition between the states to describe the relationship. Figure 6.6 shows the kettle state ontology: there are 5 states and for each, the transition defines the next possible state. For instance, in the FILLING WATER state, the kettle can switch to OFF, HEATING and HEATING MAXPOWER, but it can not go to STOPPING HEATING. With this model, the system can monitor the kettle in real-time and determine the possible action to be perform next. In order to implement the Ontology Manager module in the prototyping system, we use a Java framework developed under the Apache project Jena1 .W e then modified it by "bundlizing" Jena in order to integrate it into the OSGi framework2 .

Appliance Identification/Monitoring approaches

The goal of identification is to categorize the entities and to monitor their states of operation. As we mentioned in chapter "proposition", this identification engine is considered as a black box. In our prototyping system, three identification approaches have been integrated.

Yes

Yes No Table 6.1 summarizes these three approaches. The CEA approach [START_REF] Ha Sylvain Guillemin | Fuzzy and Parametric Method for Self-configuration of Home Energy Manager System[END_REF] is based on a single current sensor, using a fuzzy logic algorithm for appliance identification. The other two are both based on a multi-sensor approach. By using different algorithms, they can identify the type and state of appliance in real-time. In the following subsection, the technical details of these approaches are detailed. The interface implementation of the prototyping system is then described.

CEA INES

CEA INES solution is to identify of electrical appliances by comparing the shape of the electrical power curve. As shown in table 6.1, a specific monitoring box is inserted between the appliance and the wall outlet. A power meter and a minicomputer are embedded in the box in order to store the measurements performed. An example of a washing machine's active power measurement is shown in figure 6.7. A general washing machine model can be defined using a set of measurement data. As a partner of Reactivhome (See chapter 2, Reactivhome project background), measurement data obtained on appliances defined in the project are stored in a general electrical appliance type model database.

Otherwise, CEA INES also provides a module that matches pre-defined models by using fuzzy logic algorithms. Without delving any deeper in the technical details, figure 6.8 briefly illustrates the identification and modelling processes.

This approach yields good results on the limited measurement data that have been collected. We integrated this module for appliance type identification since the current sensor is included in our prototyping work. However the issue of this solution is the need to aggregate a set of data over at least one cycle of the appliance's operation period. In some cases, this needs to be repeated several times.

From a demonstration performance point of view , we have to integrate the other two approaches in order to identify the type and state in real time.

Orange Labs Grenoble

This approach is initially designed for simple event detection. It aims to provide an easy-to-use and low-cost sensing device. We believe that the sensing system should be easy to install, and should not require a skilled technician. This means that there should not be detailed, lengthy instructions on the placement of sensors, nor should the system need manual device identification and calibration. Furthermore, the system should not require an initial phase of supervision whereby the user must train the system to recognize certain devices and states.

The approach that we take to identify and monitor is illustrated in figure 6.9. A sensor-equipped appliance begins in a non-categorized state. In this state, sensor data is streamed to the system core where the identification process occurs.

The system tries to place the device into one of the categories in the ontology.

Over a short period of time, it may be possible to categorize the appliance into an abstract category at the top level of the category hierarchy. Further data may then allow us to place the appliance into one of the leaf categories. As described in the example of appliance ontology, each category corresponds to a pre-defined node in the classification ontology. It is possible to monitor the state of the appliance using the pre-defined state model in each node, where the state is relevant to the category. When the appliance is placed in a leaf category, the system's mode of operation will change to one where the sensors will stop streaming data in order to preserve power. They will engage in an event detection process and only send data to the system core when a potentially significant event has been sensed. In this case, a window of multi-modal data containing the event will be sent, which will then be used in a state classification process.

The constraints mentioned above lead us to take an approach whereby a sensor mote can be simply stuck to an appliance that the end-user wishes to monitor.

Like in "ViridiScope" [START_REF] Kim | ViridiScope: design and implementation of a fine grained power monitoring system for homes[END_REF], this leads us to exclude sensors that require difficult installation procedures, such as tampering with the power cord of the appliance.

Furthermore, we do not want to exclude non-electrical appliances such as gas or oil burners since they are also very important in the overall energy-consumption statistics of a home. Thus, we need a set of sensors that extends beyond electrical current sensing. This also leads us to exclude placing multiple sensors at different, very specific places on an appliance. The sensors should be easy-to-install and unobtrusive. For this reason, we are provisionally excluding the use of audiovisual sensors such as surveillance cameras. However, they could be added as complementary sources of data at a later stage. Finally, we will use wireless technologies for sensor communication, meaning the sensors will wirelessly connect to the system core.

The general characteristics that can be sensed from most of the home's energyconsuming appliances are sound, vibration and temperature. Other operation-based events like doors opening can also characterize them. For these reasons we designed a sensor suite comprising a microphone, a 2-axis accelerometer (for vibration and operation-based events), a temperature sensor and a light sensor (for operation-based events). The specific setup that we use is a MEMSIC1

MICAz wireless sensor mote and an MTS310 sensor board.

We explore the data acquired from our sensor platform while it is operating with some common home appliances. We use this analysis to gain insight into a concrete approach for identification and monitoring. For the appliance identification phase in our system, the approach aims to stream the maximum amount of data from the sensor mote to the core system. This gives us the best chance for a precise categorization of the appliance. In our setup, this means streaming each of the sensor modalities at 40Hz. In order to gain insight into the data, we recorded the data produced by these power-consuming appliances. Then we annotated the significant state of each appliance.

An illustration of the data produced during a washing machine cycle is shown in figure 6.10. In this case, the sensor mote was attached to the door of the machine. The diagram shows the loading state, which consists of opening and closing the door, as well as putting the clothes in. This shows clear correlations between the light and accelerometer readings. Furthermore, strong correlations can be observed between the accelerometer and the microphone during the washing and drying cycles. Also significant are the changes that appear in the temperature readings. From this, we derived an approach for appliance identification and monitoring, as well as insights about what features would be useful for classification in these respects.

Orange Labs Poland

This work was achieved with our colleagues from the orange-labs in Poland. It aims to create an approach for appliance identification and state identification.

This approach is different from the previous section's wireless CrossBow as the target system uses wired sensor kits. We describe in this section the measurement is noteworthy that the sensor data is not scaled to correspond to proper physical quantity units, but rather depicts the registered sensor voltage amplitude within a range 0 to 1000. The exception to this rule is the accelerometer data, which is properly scaled to express the measured quantity in the gravitational unit, for each of the axes individually. This is why the corresponding data is not visible The figure 6.12 shows the architecture and process of this identification approach. It is decomposed into two independent subsystems: the initialization subsystem, which is responsible for the initialization phase, and the appliance identification. The operation subsystem is responsible for the operational phase and state identification. Both of them can share the same data cache, the raw data cache and the vectors feature cache.

The module that identifies an appliance's type is responsible for executing the initialization phase of the data fusion process. We performed tests on 5 appli-Figure 6.12: OLP approach architecture and process.

ances: A dishwasher, a coffee machine, a kettle, a oven and a washing machine.

For each of them, we take two different vendor models. The classification algorithm is based on the Gaussian Mixture Model (GMM) technique. This is a widely used model for data with an unknown probability distribution. The GMMs are pervasively exploited in the speaker recognition domain. This domain closely resembles the undertaken appliance identification problem. A set of multi-dimensional data is modelled as a mixture of Gaussian components, each of which is described by a weight scalar, a mean vector and a covariance matrix.

In this approach, a GMM model is constructed for a set of feature vectors that belongs to every appliance instance of one appliance type. The classifier is thus a collection of five distinct Gaussian Mixture Models, each of them corresponding to one specific appliance type. The model encompasses all the possible operation states of a particular appliance, including the off and standby states, in which no appliance characteristic feature is present. In the classification phase, a set of unlabeled feature vectors is passed as an input to the algorithm. The algorithm selects the model that best describes the input data, in terms of the maximum log-likelihood function. This model uniquely indicates the appliance which the largest probability on the testing data. The choice of GMM models as a primary classification technique for appliance identification is justified by the fact that a vast quantity of appliance types will have to be recognized within the EIMC.

The state recognition module executes the operational phase of the data fusion process. The identification of the operational states of a particular appliance is similar to the appliance identification problem, as both share the same feature extraction mechanism and can exploit the same classification techniques. Yet, the set of states for each home appliance is, a priori, defined by the elaborated appliance ontology. This set is usually limited to a few labels and need not be extended. Three discriminative classifiers are exploited in the state recognition modules: decision trees, the MLP neural network and the SVM neural network.

The state recognition module verifies the validity of the adopted concept. Therefore, the experiments have been conducted on only one appliance, the washing machine, for which most instance measurement data have been acquired. Five distinct vendor models have been used to train the classification model and one is used to verify the generalization capabilities.

Space Identification/Monitoring approach

For the space identification and the monitoring solution, we propose a simple environment simulator. It has been included in the FINSENY project [START_REF] Loewel | ICT-2011-285135 FINSENY : Selected domain specific enablers specification[END_REF], as a smart building domain enabler called Multi-Level Smart Environment Simulator(MiLeSEns). The initial purpose of this simulator is to provide an environment that validates the space identification and the monitoring functions in the prototype. This simulator was then developed for the FINSENY project in order to validate the smart building proposition in all layers. Figure 6.13 illustrates the simulator architecture.

Though a complete simulation starts from the bottom layer (Physical Model) and finished at the top(Entity Model), the simulation doesn't need to include all of the layers. With the interfaces between every two layers, every simulation layer is independent from one another and can work alone. For example, one can simulate only the Entity Model level by directly taking entity information from an external abstraction layer service and generating and pushing actuator data as the output value.

Layers and Components

• The physical model is the software representation of physical entities in the real world. They are simplified "toy" physical models with just the necessary information. For example models do not use differential equations but perform according to the input and provide output in a very similar way. The simulator can provide a library of ready-to-use physical models if needed and relevant.

• The device Layer is the location where networked entities exist, including sensors and actuators. Sensors and actuators are intermediates between the legacy or non-networked entities and their abstract model which can be integrated into the system. Simulated sensors and actuators are independent instances of functions representing the behavior of real sensors and actuators. Some of them act only as interfaces between physical models.

Others have their own behavior functions which generate contextual data only. Results of this layer are shared by all the entities in the upper layer.

• The entity Model Layer contains two essential components:

-The Entity Model (Entity in the figure 6.13) is the basic model for building identified physical entities. It is modeled as an automaton that only contains the intrinsic states of the entity. It can also contain an entity's continuous variables. The simulator can provide a library of basic entity models with specified input/output value types, continuous variable types and state and transition events.

-The Classification Layer is part of the functionality of the service that is charged with the entities' identification and their current states.

According to available data from sensors, it identifies events in the context and makes the necessary state changes on target entities.

6.1.6.2 Interfaces and communication protocols

• The interface device/classification Layer is the output for sensors and the input for actuators. As the entry interface to the abstraction layer service is already defined, the output of simulated sensors should respect this format.

At present, as a RESTful service, it accepts an HTTP POST request to receive sensor data. It can also read periodically from XML file in a specific output sensor's data.

• The interface classification Layer/entity Model is the output for the Classification Layer. It contains information about the identified entity, such as its type, its current state, its attribute values, in an XML format exposed as a REST interface.

• The interface entity Model/service is the top interface of the simulator which will be used directly by the services that need validating. The both basic entity model and the derived entity model are available here as well as some environment variables provided to services. Services will need to know the automata in detail such as their input/output variable types, states and transitions. They should be able to give input to entity models and trigger transition events.

• The communication protocols are built for the RESTFul Web Service. We choose the REST style for our web service because it is based on the universally understood protocol HTTP and imposes few constraints in terms of design and development. By using the basic HTTP verbs, there is no need for developing other specific interfaces. This saves a lot of time and makes it easy to access through the web. Other components of the simulator can ask to get or input data. A Publish-Subscribe style may also be appropriate to simulate the system/environment which is usually event-driven.

• 6.2 Validation

Experimental validations

With the prototype described previously, we demonstrated the following scenarios that indicating the applicability and effectiveness of our approach and our prototype.

Scenario 1 : Discovery and initial self-configuration of nondigital appliances

The first scenario depicts the initial configuration mechanism of HAL. We plug a kettle to the Cleode current sensor and turn it on. The electrical signal launches the initialization stage for discovery. The HAL creates an ElectricalAppliance EIMC in the beginning in order to abstract the kettle. The Cleode current sensor is associated as the primary device. Then, we turn off the kettle and launch the water flow sensor to simulate the water filling stage. Then, we turn it on again so that the water heats. After several repetitions of the same stage, HAL recognizes that it is a water-based electrical appliance. Hence the ElectricalAppliance EIMC will be updated by matching the UsingWaterElectricalAppliance and associate the water flow sensor as its secondary sensor. Finally, the recognition engine determines that this appliance is a kettle and the EIMC updates its model by loading a generic kettle model from our pre-defined ontology.

Scenario 2 : Discovery and initial self-configuration of digital appliances

In this scenario, we repeat the first scenario but this time using an appliance that has a digital ID such as RFID. In this case, the EIMC will be created by matching an accurate model. Then the EIMC tries to associate the Cleode current sensor with this appliance in order to provide an energy consumption interface (that its own digital interface cannot provide). state. Then, we move the person into the toilet. Immediately, the EIMC toilet state changes to "occupied". However, the EIMC living room state changes to "occupied" only when the person has been inside for more than 5 minutes. The aim of this scenario is to prove that our approach is feasible for smart spaces.

Scenario 4 : On the fly reconfiguration for 2 non-digital entities

The reconfiguration demonstration is achieved by using two non-digital appliances. We plug a kettle and a radiator to two individual Cleode current sensors.

HAL performs the same stages seen in scenario 1 in order to initialize an EIMC kettle and an EIMC radiator. In the EIMC runtime, we exchange the two Cleode current sensors. Each EIMC, recognizing that it cannot match its state by using the electrical signal, exits from its model and reloads a generic model such as

ElectricalAppliance. They will also associate with the new Cleode current sensors and repeat the model matching and update stage for the EIMC re-configuration.

6.2.1.5 Scenario 5 : Dynamic configuration of entity groups with same parent model.

This scenario refers to the EGC dynamic creation of EIMC from the entity group representation layer of the HAL's initial configuration. We take the initial configuration from the scenario above. Meaning there are two EIMCs, kettle and radiators in HAL. The two EIMCs have the same ElectricalAppliance parent model, so that an EGC ElectricalAppliance will be instanced in the entity group

Validation in the Reactivhome project

In the chapter "General Background" we presented, the main project we were involved in during the thesis, "Reactivhome". Figure 6.15 gives an illustration of the overall architecture. It details the different infrastructure platforms and service platforms of the Reactivhome system.

The ReactivHome system is hosted in two different environments. Our contribution, lying at the heart of the system, connects the two physical platforms, called Domus and ArmadilloBox, to the service platform.

• Home environment: The infrastructure platforms are hosted within the home area network(typically, on a home gateway or "home box" or on an embedded server).

• Service platform: they are "in the cloud", which means they are hosted on a remote server on the network.

In the home network, two software hosts are implemented.

• The "Energy Box", a dedicated embedded server, for hosting our prototyping system, the HAL layer.

• Light weight Web Server for hosting the sensor and actuator data adaptation/alignment module. The physical system (Domus and ArmadilloBox) can publish their data and HAL can withdraw them through the http interface.

In the remote environment, there are three parts on:

• HAL Front-end: It is mentioned in the chapter "proposition". It is also a light-weight server which has REST architecture for exchanging Reac-tivHome sytem information between HAL, GHome Tech and HMI. It is achieved by our partner G-Scop1 .

• The Home Machine Interface is implemented by LIG Multicom2 .

• GHome Tech: The anticipation and optimization layer which is developed by G-scop.

The DOMUS platform is designed and set up by the Multicom team of the Laboratory of Informatics of Grenoble (LIG)in order to observe users' activities and appliance power consumption interaction in a smart environment. Figure 6.16 illustrates Domus. It is a forty square meter flat including a bathroom, a kitchen, a bedroom and a study room. All rooms are equipped with sensors and actuators as well as some RFID targets on specific devices. All appliance are connected via a KNX bus. It is possible to act on the ambiance, depending on the context and the user's habits. Our prototyping system plugs into this platform via a lightweight web server that exchanges sensor and actuator data. By using this platform dataset [START_REF] Gallissot | Using the Multicom Domus Dataset[END_REF], we can achieve auto-configuration. We validate the control by using a smart plug provided by Schneider-Electric. The scenario is that HAL creates an EIMC for a radiator in Domus, it observes the state of the radiator in order to provide consumption information both for the optimization engine and for the HMI of Reactivhome. It performs the action sent by the optimization engine and by end-users via the HMI. ArmadilloBox is another smart home platform used in Reactivhome. It was initially designed for the Solar Decathlon Europe 20101 by CEA-INES2 .I tn o w serves as an experimental platform. With this platform, we prove that the EIMC can be used not only for consumption but also for observing the energy production in an auto-powered smart home. We achieved the auto-identification of electrical appliances in this platform. Figure 6.17 is a photo of this smart home platform.

Evaluation

The Home Abstraction layer was validated. Its implementation on a resourceconstrained embedded platform (HAB: adapted to the home environment) has been evaluated to determine how many devices and entities can be handled.

The evaluation result confirms that the physical entity self-configuration and monitoring of our proposed system is more than sufficient in the home area. For CPU requirement and Memory performance evaluations, we created and launched 100 EIMCs at once on HAL. Figure 6.18(a) shows 100 EIMCs using 6 percent of CPU time on the target embedded platform. Figure 6.18(b) gives the amount of memory for one single EIMC. It is around 44 Kbytes.

Throughput evaluation

In order to evaluate the transmission capacity, we recorded data produced by a real kettle and we manually annotated the significant kettle ON/OFF states.

Based on these recorded data, we used the INM recognition module for the type identification. We ran a small piece of code for the kettle state identification related to the current sensor.

The validated implementation has been evaluated in terms of the number of waiting buffers in HDM, for different configurations of the acquisition sampling frequency. This provides a way to estimate the number of sensors that affects the performance of the EIMC.

The simulator connects to the HAB via an Ethernet LAN. The communication between the sensor simulator and HDM is established using sockets. The sensor simulator simulates one MTS310 mote sending a 32 Bytes data packet with different sampling frequencies (f). For each sampling frequency, we check in HDM if data packets that cannot be analyzed by the EIMC. These data packets are stored in a waiting buffer. We consider the moment when the waiting buffer is no longer empty as the saturation point for the EIMC.

Application in Smart Grid

In this chapter, we present the application of our proposed framework at a large scale: the Smart Grid. We start with a general presentation of the smart grid context and state of the art research efforts. Then, we describe and illustrate how the proposed framework was applied in this domain. An example of a scenario is given in the end to show how the smart grid works with the proposed framework.

What we have in Smart Grid

We zoom in on the smaller scales of the smart grid. This can involve the decentralized management of semi-autonomous units such as homes, buildings and district microgrids, where all kinds of energy-relevant physical entities can be integrated in a local energy management system. These entities can thus be considered directly or indirectly connected to the perimeter of the grid that is extended to these districts, buildings and home sub-grids. This conceptual extension upholds a proper "separation of concerns" between the grid at large and the nested sub-grids, wherein a local energy management system serves as a single interface between the nested scales. This interface serves to hide the individual entities connected in a sub-grid from the upper level of hierarchy. The risk of complexity explosion being thus adverted, there is no limit to the number of entities that can be "connected", directly or indirectly, to a grid that is extended in this way. Such entities from the home and building domains are much more numerous and heterogeneous than the classical type of power equipment that is normally 123 directly connected to the distribution network. Furthermore, their attachment to home, building and district microgrids involves not only an electrical connection, but also their integration in an overlay data network that, together with a local data management and control center, makes up the ICT part of the smart grid at these scales. It is essential to the viability of this "extended decentralized smart grid" approach that the integration of these entities does not require manual configuration. We investigate in this paper what the self-configuration and representation of these entities in the ICT network coupled to the grid at relevant scales may involve and propose a novel approach to address it. Today a number of projects have addressed ICT-based energy optimization at scales ranging from the home to district microgrids. Many of these projects restrict the scope of entities that are managed by these systems, or the scope of energy management use cases they address, such as monitoring or demand management. The articulation between smart homes and smart grids has also been addressed by several other projects. K. Kok et al. [START_REF] Kok | Smart houses for a smart grid.I nElectricity Distribution -Part 1[END_REF] lay out the possibilities offered by homes that become active peers in smart electricity networks while providing an approach for integrating a smart home into the smart grid by using Web services [START_REF] Warmer | Web services for integration of smart houses in the smart grid[END_REF]. D. Niyato et al. [START_REF] Niyato | Machine-to-machine communications for home energy management system in smart grid[END_REF] show how the smart grid connects with smart home appliances via M2M technologies.

Well ahead of the rollout of smart grids, the power engineering community has standardized the semantic-level Common Information Model [START_REF] Mcmorran | An Introduction to IEC[END_REF] (CIM). This is a set of models for electrical "entities" in the same sense, with the aim to support semantically-based self-configuration and interoperability of these entities when they are connected to the smart grid. These models are thus far limited to classical EE entities and do not extend, as we propose here, to the home or building domains. Preliminary research work [START_REF] King | Information services for smart grids.InPower and Energy Society General Meeting -Conversion and Delivery of Electrical Energy in the 21st Century[END_REF][72] [START_REF] Lendak | Restful web services and the common information model (cim)[END_REF] has also investigated the use of the semantic web for the smart grid.

What we add in the Smart Grid

Extending the domain/zone distinction set out by the Smart Grid Architecture Model[126], we focus on the microgrid and "customer premises". The application of our proposed framework can be stated in the most general way possible as In the absence of any native ICT network interface on most of these entities, sensor and actuator devices are available as intermediaries to execute this remote monitoring and control of target physical entities. This provides an indirect distributed coupling between the ICT system and the target smart grid domain.

The most obvious type of such a sensor-actuator device is, for the home domain at least, a "smart receptacle-plug" inserted in the main connection of the entity.

If the entity is a regular electrical appliance, this device monitors its electrical consumption as a sensor and may also be used to turn it on or off as an actuator.

Yet, relevant sensors and actuators are by no means limited to this all too obvious example and any sensor available in the target environment may be used for monitoring entities, at least as a source of contextual information.

In these different domain scales, the ICT system "shadows" these physical entities individually thanks to the Abstraction Layer through the matching with self-contained ICT subsystems. They will, in turn, be the primary building blocks for their own architecture. The ICT system should have the capability to create and configure these entities automatically, both for the initial configuration stage and when reconfiguration is needed because of a change in the environment. This implies the need to automatically associate the subset of sensors and actuators that are used as intermediaries for the monitoring and control of a given entity, and to update the model of the subsystem accordingly.

Our proposed architecture is applied to dynamically create the EIMC for each individual target physical entity in each target domain scale. It connects to the physical subsystem through a dynamically configured set of potentially shared sensors and actuators, chosen among those available in the relevant environment. The sensors detect events and changes of state from the physical entity as their inputs and the EIMC sends the controls to the actuators to execute required actions on the physical entity. The system comprising the EIMC along with the physical entity and the sensors and actuators makes up a closed-loop control system.

Example scenario

We assume a smart grid end-user connects an energy-relevant entity(e.g. Photovoltaic panels or batteries) to the grid through a "smart receptacle-plug". Through this sensor association, the entity is first identified as a mains-connected electrical appliance and integrated with a minimal electrical state model (ON/OFF) in the xAL, making it available to an energy management application so that it can be controlled or monitored. As more data is gathered from the use of this appliance, the system can identify it as a functional machine with a more accurate model. By using this model, the system can provide richer energy consumption information associated with the different states, and makes it possible to control the appliance according to the state it is in at any given time.

Once all energy-relevant entities are configured and represented in the local energy management system in this way, their information can be updated in realtime. Compared to smart metering [START_REF] Shekara | Smart meters for power grid: Challenges, issues, advantages and status[END_REF], the information available will be much richer and finer. Not only can the aggregate energy consumption information be collected, but also the detailed energy-related behavior of each individual energy-relevant physical entity as well. These can be separately maintained in the energy management system domain. It makes it possible for this system to act as an intermediary between the local domain and the grid in order to control the individual physical entities through their proxy representation(EIMC). This allow the implementation of the demand management by responding to grid-originating signals or local optimization and source-load balancing.

Conclusion and Perspectives

Conclusion

The objective of this thesis was the integration of non-networked physical entities in ICT systems in an automatic and dynamic way. Focalizing on this objective, the following contributions have been achieved.

A framework for the identification and self-configuration of entities through a shared sensor and actuator network infrastructure has been defined. This enables the entities to be integrated and linked through a software proxy as if they were networked entities, thus extending the range of the network and the associated "middleware" towards all kinds of physical entities.

Generic models for these entities are supposed to be described beforehand through a domain-specific ontology, available in a model repository. The matching of the entities being discovered in the home/building environment to these known models is the result of an iterative approximation process, instead of requiring an exact match as would be the case with a standard digital network protocol.

Our prototype system has been implemented in the home area, as presented in the "Implementation" chapter, within two smart home platforms (Domus and ArmadilloBox). Four concrete contributions were added to the home are.

1. Zero-configuration for the association of sensor and actuators. Our system can communicate automatically using the configured WSAN which has been deployed in the home environment. Once a home appliance is discovered, the system can attach automatically to the necessary sensors and actuators, without the intervention of the user.

2. No-delay plug&play system for non-networked home appliances. Thanks to this iterative approximate identification mechanism, the home appliance can be assigned to a general model as soon as it is discovered. Our system can go on with the iterative configuration after this initial step, while already monitoring the entity. Compared to the digital plug&play mechanism, integration of new entities is not conditioned on the exact matching with a specific model.

3.

Greater possibility for state of the art networked appliances. Our system is compatible with appliances that have a digital identification and networking interface. In addition to the matching of our proposed model, we can provide a richer interface for these appliances. For example, the system can give an energy consumption interface to an UPnP appliance for which this kind of data is not provided by the UPnP interface.

4. Richer information for end-users. Our proposed model captures the essential features of the target physical entity behavior. Once the model has been matched, the system can provide richer information associated with the different states and make it possible to control the appliance according to the state it is in at any given time.

Perspectives

Sensor data aggregation

The iterative approximate identification approach implemented revealed the complexity of the corresponding data fusion, aggregation and classification process.

The number of data features used to resolve to the problem has a significant influence on the accuracy and reliability of the classification process. An extensive amount of measurement data would have to be acquired in order to enable a classification. This would be a robust task with regards to the variability of appliance instances and their operational characteristics, as well as variability of sensors, environmental conditions, noise and side effects from other devices. Only a tiny scope of the total sensor data space has been investigated. This required a lot of measurements, which were nonetheless still insufficient in order to achieve accurate classification results.

As far as the state recognition problem is concerned, the labels of states in the training of the recognition algorithm have be assigned by an expert in the device operation domain and based on the ontology model provided, in order to avoid severe misclassification errors caused by wrong labeling of the training data.

It is also worth considering that we should avoid constructing dedicated feature extraction methods and apply dedicated classification algorithms for each device type recognized.

Sensor data disaggregation

Under our proposed framework, individual sensors are the key elements that provide the input of our system. In this thesis' research, they are all simple and low-level sensors such as temperature sensors, electrical sensors and vibration sensors. Both the initial model identification and the runtime state matching of our system are based on analyzing the aggregation of these raw sensor data.

Handling only individual sensors that are separately associated with entities is one of the limitations of our system. Sensing coupled with disaggregation is today another direction of research in the IoT&Smart environments, where a single sensor simultaneously provides data relevant to different entities which the system has to separate (disaggregate). For example, in the smart grid domain, Non-Intrusive Load Monitoring (NILM) [START_REF] Froehlich | Disaggregated enduse energy sensing for the smart grid[END_REF] is applied to analyze changes in the voltage and current recorded by the home meter and deduce which individual appliances are used in the house at any given time as well as their individual energy consumption. For our system, this kind of identification and monitoring relies on the different electrical sensors that are attached to the different appliances. This is a simpler problem, but this choice is also dictated by the need to be able to control individual appliances, not only monitor them.

Future research work will focus on associating complex and richer sensors such as vision systems and shared sensors such as water or electricity meters.

The integration of state of the art disaggregation processing together with the aggregation of data from multiple sensors based on temporal coincidence into our proposed architecture is also a further research direction.

Entity model matching

The potential ambiguity of physical entity identification is another limitation revealed during this thesis. Again, our system is based on shared simple sensors.

Thus the abstraction layer might create duplicates of the EIMC modules for entities that may get recognized separately by different sensors, without temporal coincidence. For example, in an energy management ICT system, a water-heater is associated with a water-flow sensor and an electrical sensor. Both sensors may transmit an event to the entity abstraction layer in order to trigger the creation of a new EIMC corresponding to either a water-or electricity-using appliance. If there is no temporal coincidence between the two events, the abstraction layer could create two separate EIMCs. Entity matching would be needed in a postprocessing stage in order to uncover the identity of the two entities and merge their EIMCs. This is similar to the kind of entity matching that is performed in open-linked data systems on entities such as people that have been identified separately from different data sources.

This limitation may not impact the reliability of the system in small scale environments like homes. However at larger scales such as buildings or cities, it becomes an important defect because of the larger amount of sensors in the This is a criterion characterizing the use of an appliance for the vivacious or essential or superfluous needs they meet, according to the four categories. It is obvious that this is an illogical classification, which we define a category is more priority than other.

In particular, we have to put the communication-based appliance in the security category and the audiovisual-based appliance in entertainment. Note that the boundary is indefinable since, for example, a home Internet gateway can be made available for the entertainment category while it is now a universal medium for the home security.

Comfort

Food & hygiene Safety Average energy consumption

KWh/year

The total electrical energy consumption per year in kWh. Impacting the energy balance of the home. It should be the premier criterion for the home energy management system. Power(Max) Kw This criterion corresponds to the maximum power called by the appliance from the home grid during its normal operation. Although less important than the criterion above since some appliance can have a very high nominal power but lightly impact for the energy balance (e.g. a kettle), this criterion is important for the suitable appliance, means for which should be no call at an unfavourable moment (e.g. peak load).

continued on next page 169 9. ANNEX

Controllability by system

Dimmer It is a very important criterion to determine the control degree that our system can potentially performances on the appliance. Dimmer is for the resistive appliance which can be controlled by changing the input current through an actuator such as a smart plug.

Modes

This is refers to those appliances has to operate phases distinguishing the separate steps during their complete function cycle. Those modes are supposed to be universal and can be identified for their type whatever the vendor model. These modes can be accessible through their own physical interface or a stateof-the-art network interface. ON/OFF This is for which the appliance can just be controlled for turning on or off.

ON/OFF/Standby

Relative to the ON/OFF, there is a mode standby for this category appliance. This is not a operating mode as mentioned above.

Type of energy source

Mains

This is for which connect to the grid through the electrical outlet including those appliances connect directly to the grid without an electrical outlet. So that the appliance can be detected and control by using plug actuator device. Battery This category is refers to the sensor and actuator in smart home environment, so it is not considered as the entity but the device in our scope.

continued on next page

ANNEX

Auto

They work in a way totally autonomous such as a water heater or a roomba. They are the most interesting for management system because they are deferrable and incorruptible.

Conservation of status long

Conservation of status is evaluated as the maximum duration that the appliance can be off for now causing the damage or degradation of content or themselves. For instance, a freezer cannot be off long time for that its content keeps the same status. This criterion should be taken account for the possibility of load shedding. A complementary way to consider this criterion is to determine the difference between the energy saved by leaving the appliance off and energy to make it back in its singular condition. Some appliance will also be considered non-interruptible for reasons not directly related to the conservation of the status, but because they are used in manual mode directly by a user.

short very short

No-Interruptible continued on next page

ANNEX

Localisation

Fixture

It is concern the possibility to move an appliance in the normal way (portable) or a non-customary, but achievable without the use of extraordinary means (movable). Other appliances are assumed to be fixed (fixture). For the management system, portable appliance and movable appliance have to be reconsidered dynamically by the system, which must recognize spontaneously the change of their location.

Movable

Portable Predictability(Usage)

Periodic

This criterion pattern the regularities the use of appliance, which may correspond to some quasi-periodicities (bi-daily utilize for kitchen equipment, daily, weekly, etc.)., Or at least one of their stationary distribution probabilities if these patterns have a more statistical. There are two extreme cases: used permanently or a completely random without exploitable statistical regularity.

Permanent

Semi-random

Duration of use h/year

We can try to evaluate the gains that the easiest to use in appliance controlling by system, which corresponds to the proportion of time during which the equipment is supplied and "on" state when its use provides no actual service. A typical case is provided by the audio-visual equipment with an operating mode of "user-directed", for instance, their use is oriented towards a user and has no meaning outside the presence of the user.

continued on next page

  est dû, d'une part au renouvellement constant et à la multiplication des objets physiques communicants numériques, et d'autre part àl a nécessité d'y intégrer des objets physiques "hérités" éventuellement non connectés ou même non-numériques. Des éléments d'espace pourraient être considérés comme les entités à prendre en compte dans les mêmes environnements. Le défi adressé par ce travail est donc l'intégration, et la configuration automatiques de toutes ces différentes variétés d'entités physiques d'une façon homogène dans les systèmes M2M, en généralisant les approches de configuration automatique déjà connues et utilisées pour les objets communicants numériques.

1 6 2 2 FINSENY

 62 http://www.agence-nationale-recherche.fr/ Future Internet for Smart ENergY (FINSENY) is the second project in which we were involved during our research work. Future Internet technologies will play a critical role in the development of Smart Energy infrastructures, enabling new functionalities while reducing costs. In the FINSENY project, key actors from the ICT and energy sectors teamed up to identify the ICT requirements of Smart Energy Systems. This has lead to the definition of new solutions and standards, verified in a large scale pan-European Smart Energy trial. Project results were intended to contribute to the emergence of a sustainable Smart Energy infrastructure, based on new products and services, for the benefit of all European citizens and the environment. As part of the FI-PPP program, FINSENY together with the other FI-PPP projects has intensively analyzed energy-specific requirements, developed solutions to address these requirements, and prepared for a Smart Energy trial in phase two of the program. The FINSENY Smart Grid Stakeholder Group has publicized the on-going project in the energy community, enhancing the acceptability of the project results and facilitating the development of the smart energy market.

Figure 2 . 2 :

 22 Figure 2.2: UPnP protocol architecture.

Furthermore, a lot

  of start-up companies are concentrating on developing sensors and actuators based on very low-cost communication technologies. They prove the development and deployment of WSANs.

Figure 2 .

 2 Figure 2.3 illustrates two use cases in the home and building areas. With

Figure 2 . 3 :

 23 Figure 2.3: Sensed-actuated home and building.

Figure 2 . 4 :

 24 Figure 2.4: Architecture and coarse-gain components of a home energy management system.

Figure 3 .

 3 Figure 3.1 depicts the framework for our bibliographical studies. As shown on the graph, state of the art research work in smart environment and IoT is presented via two axes. Different environments are presented horizontally ranging from the home area to a city level. On the vertical axis, the architecture of the information management is described. In our bibliography research work, as shown with the gray rectangle, we focus on the home area, which we have investigated across all layers. The structure of this chapter is as follows:

Figure 3 . 1 :

 31 Figure 3.1: Thesis bibliography framework.

  been developed since context awareness is one key element to the development of IoT. In this framework, the successful predictions help in several ways, such as automated device control and proactive reservation of resources. For instance, electrical energy and other utilities or scarce wireless bandwidth for mobile multimedia application, along with the inhabitant's most probable locations and routes. The experimental result shows potential for unifying the smart space and IoT.

Figure 3 . 2 :

 32 Figure 3.2: MavHome high-level architecture.

Figure 3 . 3 :

 33 Figure 3.3: High-level system and software architecture for smart building control system.

On a similar scaleFigure 3 . 4 :

 34 Figure 3.4: DiYSE Overall Architecture View.

3. 1 )

 1 as there are three levels of information management. The results from these works show a strong potential for WSAN, opening new research perspectives for low-cost, energy-efficient ad hoc deployment of multi-modal sensors. Our thesis work relied on this.

Figure 3 . 5 :

 35 Figure 3.5: Overview of a simple WSN aggregation application scenario for healthcare[1].

Figure 3 . 6 :

 36 Figure 3.6: State transition diagram[2].

Figure 3 . 7 :

 37 Figure 3.7: General Concepts of the Ontology for iHSF[3].

Figure 3 . 8 :

 38 Figure 3.8: DogOnt ontology example and a sample dimmer lamp model in DogOnt[4].

3. 3

 3 Auto-configuration 3.3.1 Existing networked device self-configuration protocols With a narrower focus on devices themselves rather than on the smart space, SOA-like distributed software infrastructures[103] for homes with spontaneous configuration capabilities have been widely addressed and are an obvious inspiration for the solution presented here. Aside from the efforts of standardization bodies to elaborate complete solutions such as UPnP and DPWS, Kushiro et al.[104] propose a Residential Gateway Controller with Plug & Play capabilities.

Figure 3 . 9 :

 39 Figure 3.9: A common ICT architecture for smart environment and IoT.

Figure 4 . 1 :

 41 Figure 4.1: The two layers proposed for ICT infrastructure.

diagram 4 .

 4 2 gives a simple vision of the use case for smart homes. It points out the main actor and functionality of the ICT system. The configuration monitoring and control use case are detailed in figure 4.3.

Figure 4 . 2 :

 42 Figure 4.2: High-level use cases for home domain(simple version).

Figure 4 . 3 :

 43 Figure 4.3: High-level use cases for home domain detail on configuration, monitoring and controlling.

Figure 4 . 4 :

 44 Figure 4.4: Principle of the proposed approach.

Figure 5 . 1 :

 51 Figure 5.1: EIMC for the target physical entity.

Figure 5 . 2 :

 52 Figure 5.2: Overall EIMC functional architecture.

5. 1 . 1 . 2

 112 Entity control • Entity Controller: The EIMC lifecycle manager receives the command from the application layer and sends it to the entity Controller with the current state. A command indicates the destination state for the target entity. The entity Controller can verify the feasibility of this command according to the current state of the entity and the availability of associated actuators. Moreover, any high-level command can be performed by different actuators or different combinations of actuators. To increase brightness in a room, for example, we can turn on the lights or open the curtains or do both at the same time. The entity Controller sets a schedule according to the priority and the availability of the actuators. All necessary steps for command execution, the execution time, execution data as well as the actuator ID are listed.

Figure 5 . 3 :

 53 Figure 5.3: Detailed architecture of EIMC lifecycle manager module.

Figure 5 . 4 :

 54 Figure 5.4: Architecture of Abstraction layer and Entity Group Layer.

Figure 5 . 5 :

 55 Figure 5.5: Discrete State modeling example for a Washing machine.

Figure 5 . 6 :

 56 Figure 5.6: Overall EIMC process and mechanism.

Figure 5 .Figure 5 . 7 :

 557 Figure 5.7 shows the functioning for a washing machine.

Figure 5 . 8 :

 58 Figure 5.8: Example of Washing-Machine Model update.

Figure 5 . 9 :

 59 Figure 5.9: Appliance categories in home domain.

Figure 5 . 10 :

 510 Figure 5.10: Home entity ontology and corresponding discrete state model example for home appliances and rooms.

Figure 6 .Figure 6 . 1 :

 661 Figure 6.2 shows how the EIMC management system handles subsystems. A "root" EIMC contains a recognition engine and a runtime state machine (RSM).It monitors the global context. When new appliances are installed, the "root" EIMC tries to identify them and creates a new "Generic" EIMC type. These "Generic" EIMCs have their own life-cycle and each can finally reach a "specific"

Figure 6 . 2 :

 62 Figure 6.2: EIMC mechanism illustration.

Figure 6 . 3 :

 63 Figure 6.3: HAL and EIMC architecture based upon the OSGi framework.

Figure 6 . 4 :

 64 Figure 6.4: Prototype architecture on a plug computer : Home Automation Box.

Figure 6 . 5 :

 65 Figure 6.5: An example of implemented domestic appliance ontology by OWL.

Figure 6 . 6 :

 66 Figure 6.6: Exemple runtime state ontology for a kettle.

Figure 6 . 7 :

 67 Figure 6.7: Washing machine active power measurement example.

Figure 6 . 8 :

 68 Figure 6.8: INM identification and modelling process.

Figure 6 . 9 :

 69 Figure 6.9: Crossbow identification and monitoring modes.

Figure 6 .

 6 Figure 6.10: A 40Hz recording of a full washing machine cycle. The loading, washing and drying states have been annotated.

Figure 6 .Figure 6 .

 66  shows an example of the raw data collected from a kettle instance. From the chart we can easily determine the appliance's complete cycle of operation from the on/off state to the long term process of water cooling. It

  on the figure. This fact, however, does not affect by any means the appliance and state classification processes. The extraction preprossessing phase precedes the actual induction of the discriminative model. Naturally, data collected from the accelerometer sensor is strongly correlated with the vibration sensor data. This redundancy, however, occurs in order to have a positive influence on the classification accuracy due to the considerable vulnerability of the vibration sensor regarding the quality of its attachment to the tested appliances. The corresponding figure for a washing machine instance is presented in figure 6.11-(b).

Figure 6 . 13 :

 613 Figure 6.13: MileSEns Architecture.

  The GUI of MileSENS is based on an open source context simulator called SIAFU[START_REF] Martin | A generic large scale simulator for ubiquitous computing.I nMobile and Ubiquitous Systems: Networking & Services[END_REF]. It mainly provides animation of physical entities such as people, or a room. Knowing the position of a moving person on the graphical background, it generates output sensor data simulating the presence of a person in a given space. It also provides a function for people's itinerary planning during the simulation. This is done via user interactions, such as a mouse click on the room's layout or by programming. Physical models are presented in MileSENS via the interface shown in figure6.14.

Figure 6 . 14 :

 614 Figure 6.14: MileSEns GUI example : A home environment interface.

6. 2 . 1 . 3 Scenario 3 :

 2133 Monitoring of entitiesThis monitoring scenario occurs during the self-configuration stage. However, in this case, we add the monitoring stage for the rooms by using a home environment simulator(MileSEns). The toilet and living room EIMCs are created by loading directly from the ontology model repository the two corresponding models without the identification step. The home simulator simulates one low-level presence sensor in each room to detect the presence of a person also simulated by the home simulator. At the beginning, the two rooms are in the "empty"

Figure 6 . 15 :

 615 Figure 6.15: Overall components mapping and architecture of Reactivhome System.

Figure 6 . 16 :

 616 Figure 6.16: Domus Smart Home Platform.

Figure 6 . 17 :

 617 Figure 6.17: ArmadilloBox Smart Home Platform.

Figure 6 .

 6 Figure 6.18: (a)CPU loading on a 1 GHz machine; (b) memory usage on a 512MB machine.

Figure 6 .

 6 Figure 6.19 shows the number of waiting packets in our test system. On the x axis f until 1000Hz, f = 200Hz is a saturation point. After that, the EIMC starts to have waiting buffers in the HDM. Comparing this result to the state-of-the-art home automation infrastructure[START_REF] Zhang | Home M2M networks: architectures, standards, and QoS improvement[END_REF],we estimate that EIMC concepts can easily support ZigBee-based sensor networks for energy management applications in a real home.

Figure 6 .

 6 Figure 6.19: EIMC transmission capacity evaluation with different acquisition sampling frequency.

124

 124

7. 2

 2 What we add in the Smart Grid shown in Fig. 7.1: Similar to the home domain, an ICT-based energy management or microgrid control system is set up for each targeted domain that comprehensively monitors and controls all energy-relevant physical entities within this domain. The proposed Abstraction Layer(AL) becomes a Domain Abstraction Layer (xAL), with the domain being a Home (HAL), a Building (BAL) or a District (DAL). As an analogue of Hardware Abstraction Layers used by operating systems, it hides the specifics of the domain hardware beneath a set of generic models and interfaces. It acts as a generic informational interface to the physical system.

Figure 7 . 1 :

 71 Figure 7.1: Architecture and principles of our approach for nested grid domains.

Table 2 . 1 :

 21 Different technologies for plug&play devices.

	Technology protocols communication
	UPnP/DLNA TCP/IP	Internet/Ethernet/Wireless
		UDP
		HTTP
	DPWS	HTTP	Internet/Ethernet
		SOAP
		WSDL
	Bonjour	Zeroconf	Ethernet
	ZigBee	ZigBee	Wireless
	Bluetooth	Bluetooth Wireless
	EnOcean	EnOcean	Wireless

Universal Plug and Play (UPnP) technology has been promoted by the UPnP Forum 1 since 1999, standardizing a set of networking protocols. This technology allows for networked devices to seamlessly sense each other's presence on the network and establish services such as data sharing, communications, entertainment

  They are similar to sensors but function in an opposite way. A completed network consists of a set of sensors and actuators in the same environment. Such networks are called WSANs.

WSANs normally depend on the application, which means the WSANs are dedicated to a specific application. For instance, a fire alarm application requires one smoke detector to be installed in each room. Detectors use a CO2 sensor to sense the smoke. If this little smoke sensor network is a WSAN and its protocols can be shared, it can easily be used for an application to detect the presence of people. Work done by Accettura et al.

[START_REF] Accettura | Standardized power-efficient & internet-enabled communication stack for capillary M2M networks[END_REF]

among others provides a communication stack for the capillary M2M networks

[19]

. It is composed of the latest IEEE and IETF protocols, IEEE 802.15.4e MAC and IETF 6LoWPAN, allowing for shared WSANs and a standard interface for the shared WSANs. This is important background for our thesis work.

Table 2

 2

		.2: Smart Object application in different areas
	Area	Application	Examples
	Home/building Home automation	Smart Lighting
		Health care	Elderly care
		Energy management	Building global energy efficiency
		Security	Video Protection
		Entertainment	Smart Toy for child
	Industrial	Retail	Smart shelves that monitor their
			own contents
		Logistic	Luggage routing and monitoring
			at airports
		Manufacturing control	Automatically assembled product
		System health management Retrofitting old machines or vehi-
			cles with advanced functionality
	Public	Smart city	Smart Parking Service
		Traffic management	Communicating Train
	etc.. Table 2.2 gives some concrete smart object application examples in different
	areas. Using the listed examples, we can make three points concerning the current
	situation on smart object development:

Table 2 . 3 :

 23 Research project and work on home energy management

	Project	In Brief
	REED	Federate companies with an interest in ICT for energy
		efficiency in buildings, collate current best practices and
		propose roadmaps for future research in this area.
	AIM	Fostering a harmonised techonolgy for profiling and
		managing the energy consumption of appliances at
		home.
	DEHEMS	Improving the current monitoring approach to levels of
		energy being used by households, with an overall goal of
		reducing CO2 emissions across Europe.
	Beaware	Contributing to the reduction of energy consumption, a
		societal challenge of first order that requires a combina-
		tion of technical, economical, and social means.
	Beywatch	Designing, developing and evaluating an innovative,
		energy-aware, flexible and user-centric solution able to
		provide interactive energy monitoring, intelligent con-
		trol and power demand balancing at a home, block and
		neighborhood level.
	AMI-MOSES Developing an ambient intelligent monitoring system for
		energy consumption, dedicated to manufacturing SMEs.
		Providing comprehensive information about energy use
		and knowledge-based improvements in energy efficiency.
		continued on next page

Table 2 . 4 :

 24 Research project and work on homecare information management

Table 6 . 1 :

 61 Appliance Identification approaches.

	Solution		Orange	Labs	Orange	Labs	CEA
	provider		Grenoble		Poland		INES[115]
	Sensor Kit
	Approach		multi-sensor		multi-sensor		mono-sensor
	Connectivity	wireless		wired		wired
			microphone		sound
			vibration		vibration
	Modality		temperature		humidity/temperature	current
			light		accelerometer
			magnetometer		current
	Algorithm	HMM		GMM/Decision		fuzzy logic
					Trees/MLP NN/SVM
					NN
	Implementation WEKA[116]		Matlab		Java
	Real	time
	state identifi-
	cation

  Publications Conférences • Z.Hu, G. Privat, S. Frénot & B. Tourancheau, Representation and Self-Configuration of Physical Entities in Extended Smart Grid Perimeter, IEEE PES Innovative Smart Grid Technologies (ISGT) Europe Conference. 14-17 octobre 2012, Berlin. • Z. Hu, G. Privat, S. Frénot & B. Tourancheau, Self-configuration of "Home Abstraction Layer" via Sensor-Actuator Network. In proceedings of the 2nd International Joint Conference, AmI 2011, November 16-18 2011 Amsterdam the Netherlands. • Z. Hu, G. Privat, S. Frénot & B. Tourancheau, Iterative Model-based Identification of Building Components and Appliances by Means of Sensor-Actuator Networks., In proceedings of the 2nd Workshop organized by the EEB Data models Community CIB Conference W078-W102, 26-28 October 2011 Sophia Antipolis France. Brevet • Z. Hu & G. Privat (2011). Configuration automatique d'entités physiques dans un système de supervision et de contrôle, WO 08093, Brevet France N. 1155907 du 30 Juin 2011.

	FI-PPP Future Internet Public Private Partnership LIG Laboratory of Information of Grenoble
	FINSENY Future Internet for Smart ENergY M2M Machine to Machine
	GENA General Event Notification Architecture MAC Media Access Control
	Glossary GMM Gaussian Mixture Models MLP Multilayer perceptrons
	HAB	Home Automation Box MileSEns Multi-Level Smart Environment Simulator
	HAL	AAL Home Abstraction Layer Ambient Assisted Living NFC Near field communication
	AL HAN Home Area Networks Abstraction Layer OLP Orange Labs Poland
	ANN Artificial Neural Network HDM Home Device Manager OSGi Open Source Gateway initiative
	HMI	ANR Agence nationale de la recherche Human Machine Interface OWL Web Ontology Language
	BAL HMM Hidden Markov model Building Abstraction Layer PV Photovoltaic
	CEA RDF HOMES Homes and buildings for Optimized Management of Energy and Ser-Resource Description Framework Commissariat àl ' énergie atomique et aux énergies alternatives vices REST Representational State Transfer
	DAG HTML HyperText Markup Language Directed Acyclic Graph RFID Radio-frequency identification
	DAL HTTP Hypertext Transfer Protocol District Abstraction Layer SOA Service-oriented architecture
	ICT	DDR Direct-to-Disk Recording Information and Communication Technology SOAP Simple Object Access Protocol
	DES IEEE Institute of Electrical and Electronics Engineers Discrete Event Systems SVM Support Vector Machine
	DLNA Digital Living Network Alliance IETF Internet Engineering Task Force SWRL Semantic Web Rule Language
	DPWS Devices Profile for Web Services INES Institut national de l'énergie solaire TCP/IP Transmission Control Protocol/Internet Protocol
	EGC ISTAG Information Society Technology Advisory Group Entity Group Coordinator TM TechManager
	IoT	EGL Internet Of Things Entity Group Layer UPnP Universql Plug qnd Play
	JVM	EIB Java Virtual Machine European Installation Bus WEKA Waikato Environment for Knowledge Analysis
	LAN	EIMC Entity Identification Monitoring and Control Local Area Networks WP Work Package

Table 9 . 1 :

 91 Home appliances entities list. Microwave, Freezer, Electric Kitchen stove, Espresso Machine, Fryers, Toaster, Kettle, Mini Oven, Gas kitchen stove, Washing machine, Dryer, Canister Vacuum cleaner Home Automation Appliance(Domotic appliance):This category refers to those appliances which can serve as the actuator for home automation Electric shutters, Motorized windows, Electric curtain HVAC equipment :This category refers to those appliances which are used for the indoor environmental comfort. Air conditioner(portable), Electric Water heater, Electric radiator(fixed), Heat recovery ventilation, Mechanical ventilation, Air conditioner(fixed), Fan heater, Gas Water heater, Heat pump, Gas stove/boiler, Condensing gas boiler, Gas or oil boiler, Oil-fill radiator, Solar water heater Electrical generation equipment Photovoltaic panels, Fuel cell, Microwind turbine Electricity storage equipment Home battery system, EV batteries, Flywheels ICT Appliances: This category refers to those appliances which can be integrated directly into home area network through their digital interface Internet radio, Set-top box, PC, Laptop, Energy-box, Gateway, LCD Display, Audio speaker set, Audio amplifiers, NAS/Home media server, Scanner, Printer, Mobile Phone, Videophone , Electronic Photo frame, Plasma Display, CRT Display, DVD player, Video projector, Game Console, Home automation panel, IP Telephone, Cordless Telephone(DECT)

	categories	Appliances
	Kitchen & Cleaning Appliances : This	Fridge with Freezer, Dishwasher,
	category refers to those appliances	Oven,
	which are used for food & hygiene ser-
	vices.

http://www.upnp.org

http://www.zigbee.org

http://www.homesprogramme.com/

http://www.ipso-alliance.org/

http://www.irobot.com

This corresponds to the energy consumption for the operation of the building. The figure would be 15 to

% higher by taking into account the production of materials, construction and renovation of buildings

http://www.winhr.co.jp

https://www.orange-innovation.tv/en/alerte-video-en

A Timeline for Home Automation: http://www.eddriscoll.com/timeline.html

History of Home Automation: Some Things Never Change:http://tinyurl.com/68jzkmf

The physical layer contains the hardware within the environment. This includes all physical components such as sensors, actuators, network equipment, and computers. It is necessary for handling the hardware within the environment including individual devices, transducers and network hardware.

http://www.ibm.com/smarterplanet/us/en/smarter cities/overview/?lnk=fkt-scit-usen

Definition. The state of a system at time t 0 is the information required at t 0 such that the output y(t), for all t ≥ t 0 , is uniquely determined from this information and from u(t),t ≥ t 0 .

http://www.cyc.com/platform/opencyc

239,000 terms, 2,092,000 triples,69,000 owl:sameAs links to external semantic data namespaces: DPedia: 47,000 links; UMBEL: 21,000 links;WordNet: 11,000 links ;Wikicompany 1028 links.

http://www.oxforddictionaries.com/definition/english/entity?q=entity

http://www.iot-i.eu/public

IoT-i Interview: The entity of interest is a cow

http://www.enertech.fr/docs/Remodece rapport final.pdf

www.ionics-ems.com

http://www.cleode.fr

http://www.prosyst.fr/

http://protege.stanford.edu/overview/

jena.apache.org

http://jena.apache.org/download/osgi.html

The former Crossbow/Berkeley sensor motes and acquisition boards were bought to MEM-SIC: http://www.memsic.com

http://www.phidgets.com

http://www.g-scop.grenoble-inp.fr

HTTP://multicom.imag.fr/

http://www.solardecathlon.fr/solardecathlon/

http://www.ines-solaire.org/france/DT1309170462/page/Armadillo-Box.html

Remerciements

environment. Each piece of sensor data is transferred by the sensor module which achieves the following tasks:

1. Physical interface for heterogeneous sensor management [START_REF] Gurgen | SStreaMWare: a service oriented middleware for heterogeneous sensor data management.I nProceedings of the 5th international conference on Pervasive services[END_REF];

2. Identification and authentication of data source; 3. Cartography of the observed environment; 4. Dynamic integration of sensors according to their own protocol, for which we mostly (but not exclusively)use Zigbee [START_REF] Ha | Dynamic integration of zigbee home networks into home gateways using OSGI service registry[END_REF].

The Actuator Module, counterpart of the Sensor Module, takes in high-level commands expressed as state changes of target physical entities and fans them out as specific controls to the associated actuators.

The StartUp bundle waits for the activation of the Sensor Module and Actuator Module in order to start the first "root" EIMC. EIMC is made up of the following operating services:

1. The Life-cycle service is the core of EIMC. It is capable of starting or stopping EIMCs. It is invoked by the "root" EIMC, and requests the creation of a predefined type of device corresponding to a set of sensed data; 2. Classification is based on a model which produces a unique output from various sensor inputs of sensed data in a single classifier. This output can be transferred to the RSM; 3. The RSM service maintains the current state by receiving notifications from the recognition engine. It can communicate with the application layer in order to provide the physical entity information as well as to receive commands for the physical entity. environment. For space entity matching, even in a small scale environment, this limitation induces failure of the auto-configuration, because the inside-shared sensors can detect many events without the temporal coincidence from one space entity.

Even with the model matching reconciled from different ontologies [START_REF] Hameed | Ontology reconciliation.I n Handbook on ontologies[END_REF], the problem is still present. To resolve this problematic, enabling the active learning ability may be a noteworthy line of inquiry.

Use of actuators for active learning

Actuators are essential elements for our system, just like sensors. In the implementation work, we implemented the use of actuators in order to perform the high-level commands from the application layer. Unfortunately, we did not have the time for further research on how to make the identification more powerful and reliable by jointly using sensors and actuators. However we proposed a mechanism for this in the "Proposition description" chapter, the closed-loop control. Currently, our prototype system is capable of passive learning. This means the system can receive pieces of data from the sensors and try to analyze them in order to understand the real world. However with increases in the data volume, the system becomes unreliable, due to the noise in these pieces of information.

Time is also another fatal defect. To identify an entity with the most accurate model possible, our prototype system needs more data. This means it needs to collect the data from the target entity used repeatedly. If we use it once a day, the system may need one week or even more to recognize the entity. However we use the actuator to perform the same manipulation on this entity, the system can recognize it in a very short amount of time, the procedure having been accelerated. This can be called active learning.

The research work done by P. OUDEYER et al. [START_REF] Oudeyer | Developmental active learning with intrinsic motivation[END_REF] can orient us in this direction. In their work, a robot is trained via active learning. In the framework of our thesis, we can train our entity matching system in a similar way by using actuators.

List of Figures

List of Tables

Home area entities

The table 9.1 provides representation of the variety of appliances that would have to be addressed for a comprehensive home system. They are classified below according to a "main use criterion", and a list of complementary criteria that have to be taken for managing them in the framework of the home energy management system.

Rooms are another category of home parts that have to be integrated as such in a home management system. The following table provides typical rooms which are found in the domiciliary home. The criterion of classification is depending on the "duration of occupancy". The complementary of criteria list will be provided below.

Categories Character Description

Energy function type load

This criterion is used for classifying the appliance for the energy management system according to the three broad types. Load for appliances which consume electrical energy, source for which generates the electrical energy and the storage for that stores the energy.

Source

Storage

Energy type

Air/water This distinction applied for the appliance in category "load" above, the appliance "source" is distinguished by the input and output form of energy. Our system is not limited on electrical appliances, it also for those appliances which used the other energy source. Auto-charge Normally this kind of appliance is portable and is with the battery which can be charged through "mains". There is a typical example that is the laptop, today this is a growing category of appliance and it is interesting to integrate into our system, because of their flexibility on the energy management even if their nominal consumption is low.

Sunlight

Operating mode

User-directed These appliances can work without the intervention of the user, but there is no need that they work by themselves without the presence of the user. For example, the screen takes that case. This category allows this system to detect a presence of the user and also to obtain the gain of energy efficiency.

Manuel

Appliances should be operated by the user and cannot work without them such as a vacuum cleaner. For our system, this category is less interesting since they cannot provide more possibility on control by system.

Semi-auto

This kind of appliance needs an intervention of the user for starting to work. They are more interesting for management system because they are deferrable and incorruptible during their operating phase.