Infrastructure de domotique (sujet réservé) - IICT

Travail de bachelor 2010Infrastructure de domotiqueRésuméCe sujet se propose d'étudier une infrastructure de domotique sécurisée,permettant la définition flexible de règles de sécurité diversifiées, et aussi le contrôle ducomportement global de la maison par une entreprise tierce spécialisée, afin de libérerle propriétaire ou le locataire des problèmes techniques associés à la maison.AuteurMarkus Jaton, heig-vdCandidatCe sujet est réservé par MM. Criniti et Pimpao, filière TRmarkus.jaton@heig-vd.ch, 17/11/2009

MotivationLa notion de domotique souffre de nombre de définitions floues et approximatives,certaines orientées vers le contrôle des médias, d'autres vers l'économie de ressources(souvent énergétiques) d'autres encore orientées vers la sécurité et la télésurveillance. Ainsi,selon les acteurs du marché, on trouve de nombreuses solutions « clés en main », quicorrespondent à un certain sous-ensemble de fonctionnalités domotique. Sortis de ce sousensemble,on se retrouve le plus souvent livré à soi-même, et la solution la plus simpleconsiste le plus souvent à redéfinir les nouvelles fonctionnalités dont on aurait besoin enrepartant à zéro.Cette situation est une conséquence de la très grande diversité des tâches et desfonctions que l'on peut rencontrer dans le monde de la domotique :• Contrôle des médias• Contrôle énergétique• Contrôle d'accès et sécurité• Surveillance des enfants, ou de personnes âgées (télésurveillance)• et on en oublie...Chaque acteur tend à résoudre le sous-ensemble de problèmes pour lesquels il disposede produits qu'il pourra vendre, mais n'est pas interessé à pousser la réflexion au-delà. On sepropose dans ce projet d'adresser deux problèmes bien distincts mais complémentaires, àsavoir :1. L'identification de l'habitant et la gestion de ses autorisations2. L'infrastructure de contrôle de l'habitation, indépendemment des fonctionseffectivement contrôlées.Divêrses infrastructures ont été proposées par le passé, certaines adressent desproblématiques de bas niveau, comme la connectique des dispositifs (UpNp, par exemple),d'autres ambitionnent la résolution du problème général de l'interconnexion des services dansun cadre domotique (JINI, OSGI).Nous aimerions dans le cadre présent présenter une approche quelque peu différente,incarnée par une approche Top-Down, qui consiste à commencer à définir un modèle degouvernance de la maison, avant que de se préoccuper du contrôle des appareils et dessenseurs. En principe, une fois ce modèle de gouvernance défini, il devrait être possible de luiajouter des fonctionnalités (un peu à la manière d'un driver dans un ordinateur) qui pourraient,le cas échéant, s'appuyer sur UpNp ou sur d'autres infrastructures. Même les divers types debus de connexion imaginables devraient être adaptables assez aisément.2/6

IdentificationLe problème de l'identification de l'habitant est récurrent dans la domotique; dans unappartement « normal », il peut être arbitrairement simple, avec des rôles très clairementdéfinis (par exemple « parents » et « enfants », pour contrôler l'accès aux médias et àInternet). Dans un chalet de vacances, il peut se compliquer de la notion de locataire,propriétaire, concierge. Une villa peut comprendre aussi des personnes à mobilité réduite,requérant certainjs services de la part de la maison.Identifier une personne n'est pas chose aisée. On a longtemps tablé sur l'identificationbiométrique, mais elle est souvent lente et pas forcément très sûre. On tend actuellementplutôt à favoiriser l'identification par RFID actif à basse énergie, en utilisant desinfrastructures facilement déployables comme Bluetooth dans sa version Low Energy.Un utilisateur qui veut interagir avec un dispositif de domotique devra tout d'abord êtreidentifié; il doit pour cela être en possession d'un badge (qui peut se dissimuler dans un porteclés,par exemple) alimenté par pile, qui servira d'identificateur. Au niveau le plus basique, lasimple adresse Bluetooth (normalement unique) devrait suffire; mais il peut être intéressantd'explorer des possibilités d'authentification plus sophistiquées, comme l'échange dechallenge-response, éventuellement en interaction avec un serveur distant.L'utilisateur ayant été identifié par le dispositif de domotique (ou un ordinateurcontrôlant le dispositif de domotique), ce dernier peut questionner un serveur (ou sa proprebase de données) de manière à savoir quelles opérations cette personne est en droit d'effectuersur le dispositif dans le contexte présent. La notion de contexte peut être une notion très large,et recouvrir aussi bien l'heure du jour que le temps qu'il fait.3/6

Superviseur de domotiqueLa domotique est censée faciliter la vie des usagers. Or on constate souvent que lesinfrastructures proposées sont si complexes qu'il vaut mieux être un ingénieur pour installer etutiliser ce genre d'infrastructure. Or, si la domotique doit devenir un jour un business rentableet facilement utilisable, il faut :• Qu'elle soit facile à déployer• Qu'elle puisse être confiée à une société de services de confiance qui en gérera lescomplexités éventuelles• Que les mises à jour inévitables soient automatiques• Que l'utilisateur puisse configurer les services domotique de sa résidence de manièreconfortable.Ceci implique un accès Web, ce que de nombreux implémentateurs ont d'embléecompris. Mais généralement, cet accès est réalisé en utilisant un serveur Web dans l'enceintede la maison à gérer, ce qui multiplie les inconvénients :• Il faut une adresse publique; ceci rend l'accès au serveur de domotique possible depuisl'extérieur: il faut de ce fait le protéger contre les attaques malveillantes. Toutes chosesqui ne sont pas forcément faciles à configurer par un utilisateur lambda.• En cas de non-disponibilité d'une adresse publique, il faut une fonction de « reverseproxy », autre fonctionnalité relativement complexe à configurer pour un utilisateurnon averti.• Les mises à jour sur un serveur ne sont pas forcément évidentes : il se peut qu'il failleredémarrer le serveur. En cas d'absence des habitants, l'accès au serveur peut êtredifficile.• Un serveur doit tourner 24 heures sur 24; ceci ne paraît pas trèps raisonnable entermes de consommation. Un client, à l'inverse, pourrait être « réveillé » au besoin àdistance par des fonctionnalités de type « wake-on-lan ».Pour ces diverses raisons, il paraît plus simple d'installer un client riche sur le site àgérer. La configuration résultante est la suivante :4/6

Une telle configuration a été testée avec succès dans le cadre de IICT, ceci au cours duprojet JHEDU 1 , ou une infrastructure de gestion de laboratoires à distance a été ainsi mise surpied pour la Haute Ecole Cantonale Vaudoise de la Santé.Le client riche interroge périodiquement le serveur par polling, étant entendu que laconfiguration de paramètres sur le client par le serveur ne nécessite généralement pasd'intervention urgente. A l'inverse, la transmission d'alarmes par le client vers le serveur peutse faire de manière parfaitement asynchrone dans ce modèle.Les périphériques de domotique se connectent au client riche qui télécharge au besoinles différents pilotes dont il peut avoir besoin, ainsi que les règles de sécurité qui régissent lamaison sous contrôle.1Ce projet ( http://useraware.iict.ch/fr/sante/jhedu/index.html ) a été mené à bien par l'institut IICT en2009. S'adresser à l'auteur de ce texte ou à son collaborateur scientifique, M. Christophe Greppin, pour de plusamples précisions.5/6

ConclusionLes deux projets sont complémentaires, mais peuvent être entrepris de façon largementindépendante. Après une phase de définition commune, permettant de définir comment seraconstituée et communiquée la matrice des autorisations (action / périphérique / Identité del'utilisateur), les services respectifs peuvent être simulés de part et d'autre par du code adéquat(dummy code), ce qui permet à chacun des candidats de progresser indépendemment.Néanmoins, il paraît intéressant de conserver une certaine interactivité entre les deux partiesdu problème.Le modèle basé sur le client riche et sur un badge d'authentification pour la sécuritéd'accès semble à priori offrir de bons gages de flexibilité. Par ailleurs, le badge RFID peutavoir de nombreuses autres utilisations (voir par exemplehttp://useraware.iict.ch/fr/mobilite/osmosys/index.html ), et pourrait éventuellement s'inscriredans un contexte de déploiement plus large, comme une infrastructure touristique d'unegrande station qui propose la getsion intégrée des maisons de vacances et des forfaits deremontées mécaniques / bains thermaux et autres à ses vacanciers.En pratique, les deux projets devront probablement simuler dans une large mesurel'environnement domotique contrôlé. On peut imaginer, pour la démonstration, intégrer lecontrôle de médias ou de contacts de portes dans une maison par ailleurs virtuelle. Leproblème de description informatique de la maison devra de toutes façons être résolu,indépendemment du fait que la maison elle-même soit réelle ou virtuelle !6/6