6.3 Modèle architectural de sensibilité au contexte
6.3.1 Le Module de collecte de données
Ce module est considéré comme une sonde, car, c’est lui qui est responsable de collecter les données de diverses sources et de les rendre disponibles. Il est divisé en deux parties. La partie contexte de l’environnement et la partie Contexte de l’utili- sateur comme le montre la Figure 6.2. Il est facilement extensible il suffit, pour cela
d’ajouter une nouvelle source de données et de la connecter au module de niveau supérieur.
Le Contexte de l’environnement
Spécialisé dans la collecte des informations sur l’habitat intelligent, il surveille les capteurs et les dispositifs électroniques tels que les téléphones, les téléviseurs, bref toutes les sources de données disponibles et possibles.
Pour faciliter sa montée en charge, sa réutilisation et son entrelacement, nous l’avons organisé en trois couches. La couche d’acquisition de contexte, la couche de filtrage des données de contexte et la couche d’abstraction.
La couche d’acquisition de contexte
Elle collecte toutes les valeurs physiques de l’environnement. Elle est donc par ailleurs sensible aux différents stimulus créés dans l’environnement. Ces valeurs phy- siques sont soit une information collectée directement dans l’environnement via un capteur soit les résultats d’un traitement algorithmique.
Le processus de collecte des informations est un processus qui se fait en continu, nous conseillons donc d’avoir un contexte d’acquisition permanent. Grâce aux infor- mations collectées, on doit pouvoir en tout temps être capable de localiser la personne, de savoir ce qu’elle fait, mais pas comment elle le fait ?
Ainsi dans notre exemple avec Georges, le contexte d’acquisition était constitué : — Des capteurs de mouvement pour suivre en tout temps ses déplacements ; — Des capteurs de pression pour savoir quand il quitte le lit ou y retourne ; — Des capteurs d’eau pour la salle de bain ;
— Des capteurs électriques pour allumer certaines lumières et lampes de chevet ; — Des capteurs de contact pour les ouvertures et les fermetures de porte ;
— Des capteurs de traversée de porte ; — Un capteur porté sous forme de montre.
Tous les capteurs fonctionnent sous forme d’événements. Chaque fois qu’un chan- gement survient, un événement est propagé à une unité de traitement que l’on appelle le contrôleur.
Figure 6.3 – Environnements d’acquisition de contexte dans un habitat intelligent
La Figure 6.3 montre un exemple de disposition de capteurs pour construire le contexte d’acquisition dans l’habitat du laboratoire DOMUS.
La couche de filtrage du contexte
Les données collectées par les sources hétérogènes sont envoyées via différents pro- tocoles de communication aux contrôleurs. Ils sont chargés de la maintenance et des opérations de gestion de groupe dans le réseau. Puis, chaque donnée est étiquetée et acheminée à un intergiciel. Pour une meilleure gestion de l’hétérogénéité des données, l’intergiciel agrège toutes les informations, les étiquettes, les dates et les met à la disposition d’une autre couche pour des traitements ultérieurs.
Dans le cadre de l’assistance à Georges, nous avons mis en place les contrôleurs suivants :
a) Un contrôleur Vera 3 pour la gestion du réseau Z-wave.
b) Un contrôleur Philips Hue pour la gestion du réseau Philips utilisant le protocole ZigBee.
c) Un contrôleur Arduino pour le transport et la lecture des informations des capteurs ne supportant pas les protocoles sans fils.
Figure 6.4 – Architecture physique du modèle de sensibilité au contexte
fil.
L’ensemble des contrôleurs étaient rattachés à OpenHab, un logiciel libre et gratuit permettant de gérer l’hétérogénéité des différentes sources de données. La Figure 6.4 montre une partie de l’interconnexion physique des contrôleurs et de l’intergiciel. Cet ensemble constitue donc le contexte de filtrage des données, en ce sens qu’il élimine toutes les informations de gestion et de synchronisation du réseau de capteurs.
La couche d’abstraction du contexte
La couche d’abstraction offre une visualisation simplifiée et compréhensible des informations issues de l’environnement. Elle fournit des outils permettant de diffuser ou de propager de manière spécifique les informations vers d’autres sources d’infor-
mation. Il s’agit spécifiquement de la mise en place d’un patron de type observer. En effet, plusieurs sujets peuvent vouloir être tenus informés instantanément des change- ments survenus sans pour autant être en mode demande active. Le rôle de ce module est de diffuser vers toutes les entités l’ayant sollicitée, les informations spécifiques de changement via les canaux réservés à cet effet.
Dans le cadre de notre exemple, nous avons utilisé le serveur et le protocole de communication MQTT (Message Queuing Telemetry Transport). Il utilise les notions de canal et de souscription pour tenir informés les sujets sur des changements. La Figure6.4 montre comment se fait l’interconnexion entre MQTT et l’intergiciel.
Le Contexte de l’utilisateur
Il permet de renseigner l’application au complet sur le profil utilisateur, sur son état de santé, sur ses habitudes et sur ses préférences éventuelles. Cette source d’ac- quisition des données est justifiée par le fait que les personnes atteintes de la maladie d’Alzheimer vivent leur maladie de manière très différente, de sorte qu’une modéli- sation cas par cas est généralement recommandée. La connaissance du profil et des habitudes de vie de la personne est une information contextuelle importante voir capi- tale, car, elle permet de mieux répondre à la question comment et pourquoi. Une fois de plus pour faciliter la réutilisation, nous avons opté pour un découpage en couche. Ainsi, trois couches permettent d’exprimer les informations de ce module. La couche de modélisation des scénarios, la couche de modélisation du contexte utilisateur et la couche de filtrage de contexte utilisateur.
La couche de modélisation des scénarios
Cette couche décrit l’histoire de la personne ayant besoin d’assistance. Elle décrit de manière formelle le scénario ou comment la personne accomplie ses activités et où. L’approche de conception basée sur les scénarios est utilisée généralement dans ce cas et il a été longuement explicité dans les sections précédentes.
Dans notre exemple, Georges était à la fois co-créateur du scénario et co-concepteur de l’assistance, tout cela sous le contrôle des parties prenantes. Il nous a montré com- ment il réalise toutes les activités du scénario. Nous avons évalué avec les différents experts de chaque domaine comment, où et à quel moment nous jugions opportun d’assister Georges.
La couche de modélisation du contexte utilisateur
Ce processus itératif permet d’enrichir la base de connaissances avec de la connais- sance sur l’évolution de la maladie de la personne. Elle prend aussi en compte le com- portement de la personne face au système. Plusieurs informations sur le profil de la personne sont aussi prises en compte. Nous pouvons citer entre autres : les habitudes de vies de la personne, comment réagit la personne à un scénario ou une partie d’un scénario, à quel stade est sa maladie. . .
En ce qui concerne Georges, les tests cognitifs réalisés montrent qu’il est atteint d’Alzheimer à un stade modéré. Il ne fait jamais la cuisine et se couche tous les soirs à la même heure. Il pense qu’il se lève toutes les nuits ou presque pour aller aux toilettes. Il préfère souvent s’endormir sur son divan au salon. En plus nous savons qu’il aime jouer au solitaire et qu’il n’est pas à risque de chute.
La couche de filtrage de contexte utilisateur
L’objectif de cette couche est d’adapter la sortie des informations du module pour qu’elles correspondent aux capacités réelles de la personne. La couche de filtrage prend en entrée le profil, les habitudes, les contraintes et les préférences de la personne et retourne les contraintes nécessaires pour permettre à la personne de réaliser son besoin.
Georges a eu besoin d’indicateur lumineux et parfois d’instructions vocales pour l’accompagner durant ses épisodes d’errances nocturnes.