L’habitat intelligent
Bien que toutes les technologies et méthodes nécessaires au développement d’un habitat intelligent soient accessibles aujourd’hui, leur intégration et la construction d’un réel habitat intelligent ne sont pas triviales. En effet, les maisons déjà équipées de tels systèmes ne sont pas toujours source de satisfaction. Les systèmes reposant sur du tout automatique et des règles sont souvent mis en échec. Les exceptions peuvent être nombreuses dans l’habitat : partir au/rentrer du travail à des heures différentes, se coucher plus ou moins tard, etc . La sensibilité au contexte est donc nécessaire pour permettre au système de s’adapter en temps réel aux activités des habitants. Malheureusement, la reconnaissance de contexte n’est pas une tâche facile. Elle repose souvent sur des instrumentations coûteuses et qui peuvent être contraignantes.
Analyse d’un exemple de service : l’éclairage automatique
En analysant quelques projets typiques de la recherche dans le domaine des habitats intelligents, nous avons pu mettre en avant des éléments matériels qui en limitent la diffusion et l’acceptabilité. De plus, chacun des travaux présentés traite d’un type de données contextuelles différent. Ainsi, nous avons décrit un système permettant de détecter des activités quotidiennes, un système permettant de localiser les personnes dans un appartement et enfin un système permettant de détecter la posture d’une personne. On constate donc que l’habitat intelligent peut reposer sur un large panel de données contextuelles. Cette diversité est nécessaire si l’on souhaite mettre au point des services complexes.
Nous souhaitons analyser ici cette « diversité » de données contextuelles peuvent être nécessaires au travers d’un service simple a priori : l’éclairage automatique. Ce dernier est un des services les plus communément retrouvés dans les habitats intelligents. Malheureusement, il repose le plus souvent sur un ensemble de règles simples peu adaptées aux réels besoins des habitants. De fait, ce service est souvent source de frustration. Cette frustration laisse à penser que ce service est plus complexe qu’il n’y paraît.
Définitions des couches pour un service d’éclairage
Dans les situations décrites précédemment, on peut constater une imbrication des données contextuelles nécessaires à leur reconnaissance. Un capteur de mouvement peut-être utile pour allumer la lumière immédiatement lorsque que quelqu’un entre dans la pièce. Malheureusement, cela n’est pas suffisant pour offrir un service adapté à une personne lisant tranquillement assise sur un fauteuil. Pour cette personne, la détection de la présence est nécessaire. La détection de la présence peut s’appuyer en partie, mais pas uniquement, sur la détection de mouvement. Enfin, le fait qu’une personne soit en train de dormir peut aussi être déterminant pour savoir s’il faut allumer ou pas la lumière. La détection d’une personne endormie peut s’appuyer en partie, mais pas uniquement, sur la détection de la présence.
Avec toutes ces données, on constate donc qu’un service d’éclairage automatique doit reposer sur différents niveaux d’abstraction de données contextuelles comme suggéré par l’architecture en couches pour la construction de service sensibles au contexte.
Modèle de contexte
Le modèle des Context Spaces permet de définir simplement des contextes à partir de données brutes capturées dans l’environnement. Plus précisément, la modélisation des Context Spaces repose sur trois niveaux : les capteurs, les contextes et les situations. Ainsi, les données issues de capteurs sont transformées puis interprétées afin d’obtenir une représentation factuelle du contexte mais aussi des suppositions et des prédictions . Un moteur de raisonnement permet ensuite de répondre à la question « telle situation est-elle en cours ? » avec un certain degré de confiance. Ce moteur de raisonnement repose sur des heuristiques qui lui sont propres mais aussi de la logique floue mais peut en réalité reposer sur n’importe quelle théorie de fusion de données.
La modélisation des Context Spaces repose sur une métaphore géométrique. Chaque capteur et chaque donnée obtenue via une fusion est appelée attribut de contexte (en anglais context attributes). Ces attributs de contexte peuvent chacun prendre un ensemble de valeurs et servent ainsi à définir les dimensions de l’espace dans lequel sont définies les situations . L’état courant du monde est donné par le context state qui correspond à un point dans l’espace défini par tous les attributs de contexte. Si cet état se trouve dans un ou plusieurs solides, alors les situations correspondantes ont toutes les chances d’être observées. Cette représentation des situations et de l’état permet donc au système de ne pas toujours savoir ce qui se passe. En effet, l’état peut ne correspondre à aucune des situations modélisées. Il est donc possible de ne modéliser que les situations pertinentes et/ou qu’il est possible de réellement identifier. L’exhaustivité n’est pas nécessaire pour appliquer cette identification de situations.
Reconnaissance de plan
Reconnaître des activités domestiques, par exemple cuisiner, peut être considéré comme étant le plus haut niveau de données contextuelles qu’il est possible d’obtenir. Pour reconnaître ces activités, il peut être intéressant de comprendre les buts des habitants et ainsi pouvoir prévoir une suite d’actions ou de situations à venir. Pour faire cela, il est possible d’utiliser des algorithmes de reconnaissance de plan. Il en existe de nombreux. Nous en avons retenu un : PHATT . PHATT repose sur un problème de planification d’un réseau hiérarchique de tâches (en anglais hierarchical task network ou HTN) qu’il doit inverser afin d’identifier les plans en cours. Ce problème de plannification consiste à générer automatiquement un plan à partir d’un ensemble de tâches à exécuter et de contraintes .
Le but est de définir une bibliothèque de plans possibles. Chacun de ces plans est divisé en tâches. Ces tâches sont primitives si elles ne requièrent pas de plannification et peuvent donc être exécutées directement, ouvertes sinon. Des méthodes sont aussi définies afin de décrire comment les tâches peuvent être décomposées en un ensemble ordonné ou partiellement ordonné de sous-tâches (chaque tâche peut être décomposée de plusieurs manières différentes). Un algorithme de planification décompose alors récursivement l’ensemble des tâches jusqu’à n’obtenir que des tâches primitives.
Table des matières
Introduction
I Informatique ubiquitaire et sensibilité au contexte
1 Services sensibles au contexte dans l’habitat intelligent
1.1 L’habitat intelligent : analyse des contraintes
1.1.1 Présentation de quelques exemples
1.1.2 Analyse
1.2 Analyse d’un exemple de service : l’éclairage automatique
1.2.1 Approche contextuelle du service
1.2.2 Architecture en couches
1.2.3 Définitions des couches pour un service d’éclairage
1.3 Conclusion
2 Fusion de données pour la reconnaissance de contexte
2.1 Problématique générale
2.1.1 Imperfection des données
2.1.2 Contraintes théoriques
2.1.3 Niveaux d’abstractions
2.2 Méthodes et théories
2.2.1 Reconnaissance de plan
2.2.2 Modèle de contexte
2.2.3 Logique floue
2.2.4 Fonctions de croyance
2.3 Fusion de données et architecture en couches
2.4 Conclusion
II Théorie des fonctions de croyance : applications et stabilité
3 Théorie des fonctions de croyance : application aux capteurs
3.1 Modéliser des croyances
3.1.1 Cadre de discernement
3.1.2 Fonction de masse
3.1.3 Cas particuliers
3.2 Construire des fonctions de masse
3.2.1 Projection simple
3.2.2 Affaiblissement
3.2.3 Ensemble de fonctions de masse
3.2.4 Classification
3.2.5 Analyse
3.3 Accumuler des preuves
3.3.1 Règle de Dempster
3.3.2 Conflit
3.4 Prendre une décision
3.4.1 Critères classiques
3.4.2 Sélection d’un état
3.5 Exemple d’application : détection de la présence
3.5.1 Modèles
3.5.2 Résultats
3.6 Conclusion
4 Temporisation des croyances : vers des attributs de contexte stables
4.1 Temporisation avec discrimination
4.1.1 Propagation dans le temps
4.1.2 Spécificité et discrimination
4.1.3 Analyse du comportement de l’algorithme
4.1.4 Analyse d’un exemple : détection de présence
4.2 Temporisation avec fusion
4.2.1 Combinaison temporelle
4.2.2 Analyse du comportement de l’algorithme
4.2.3 Analyse d’un exemple : mouvement et présence
4.3 Mise à l’épreuve des algorithmes : détection de la présence
4.4 Conclusion
III Construction d’un prototype
5 Prototype : matériels et outils
5.1 Technologies, matériels et équipements
5.1.1 Capteurs
5.1.2 Nœuds communicants
5.1.3 Calculateurs
5.1.4 Equipements augmentés
5.2 Outils logiciels
5.2.1 Implémentation des Context Spaces : ECSTRA
5.2.2 Exploitation d’un moteur publish/subscribe
5.3 Conclusion
6 Prototype : implémentation et expérimentations
6.1 THE GAME : exploiter les fonctions de croyance dans un contexte embarqué
6.1.1 Principales caractéristiques
6.1.2 Optimisations
6.1.3 Performances
6.2 Définition d’une architecture modulaire
6.2.1 Partage des tâches
6.2.2 Répartition de la fusion
6.2.3 Ajout de composants
6.2.4 Analyse des limites de l’architecture
6.3 Mise en œuvre des capteurs virtuels
6.3.1 Instabilité des modèles
6.3.2 Indépendance des capteurs
6.3.3 Rétroaction
6.3.4 Capteurs contextuels
6.4 Démonstration du prototype
6.4.1 Installation
6.4.2 Contextes et scénarii
6.4.3 Services déployés
6.5 Conclusion
Conclusion et discussion
Publications personnelles
Bibliographie
