Gestionnaire de contexte

Le module de gestion de contexte est l’élément de l’architecture responsable de la gestion des informations contextuelles de l’utilisateur (dispositifs), Figure 6.13. Autrement dit, il se charge de collecter et de modéliser les informations contextuelles courantes des utilisateurs (dispositifs) qui interagissent dans le SIP. Le rôle principal de ce module est de cacher la complexité de la gestion de contexte en proposant une manière uniforme d’accéder aux informations contextuelles.

1. L’acquisition des informations contextuelles.

2. Le traitement et la modélisation de ces informations.

3. L’interprétation.

4. Le stockage.

En s’inspirant de ces travaux [DAS01], notre module de gestion de contexte est conçu pour recevoir, du composant responsable de l’acquisition de contexte à partir des capteurs physiques et logiques, les informations contextuelles brutes relatives à chaque utilisateur. Ces informations sont par la suite modélisées et interprétées en respectant le modèle de contexte représenté par l’ontologie multi-niveaux de contexte [KB14b].

– Capture du contexte :La fonction principale assurée par cette couche est la capture du contexte. Le contexte peut parvenir de plusieurs sources comme les capteurs physiques, les capteurs logiques ou les capteurs virtuels

Figure VI.13– Gestionnaire de contexte.

comme présenté dans l’état de l’art de ce mémoire (chapitre 2). Ensuite, les données contextuelles capturées sont stockées dans un registre contextuel sous le format XML.

– Conception de l’ontologie du contexte :Dans le chapitre 2, nous avons justifié le choix de l’ontologie pour modéliser le contexte. Les ontologies de haut niveau (Upper ontologies) sont celles qui sont le plus souvent utilisées puisqu’elles offrent des concepts universels, indépendants du domaine et qui sont flexibles à une adaptation pour différentes applications qui ne réalisent pas forcément les mêmes traitements et n’appartiennent pas au même domaine. Nous étendrons cette ontologie avec les concepts du protocole UPnP (service et device). Cette approche est représentée dans la Figure 6.14. Nous partons alors de l’ontologie de haut niveau comme point de départ qui represente les concepts fondamentaux (Space, User Preferences, Network), Ces concepts sont reliés entre eux par des relations. On y ajoute les concepts du protocol UPnP afin d’obtenir notre modèle de contexte [KB14b]. Ce modèle permet la déduction du contexte au moyen des règles d’inférences, Figure 6.15. Basé sur la sémantique formelle des logiques de description, l’ontologie permet de représenter les concepts ainsi que la nature des liens entre ces concepts. OWL (Ontology Web Language) est le langage utilisé pour représenter notre ontologie. La définition de ces règles nécessite le choix d’un langage de règles, d’un outil d’édition des règles et d’un raisonneur. Pour définir ces règles, nous avons utilisé le langage SWRL. Une combinaison du langage OWL avec celui du Rule Markup Language.

Les concepts généraux de l’ontologie contiennent des sous entités ou sous classes qui présentent des extensions de plus haute spécificité et facilitent l’intégration des concepts propres au domaine. OWL permet la structuration

Figure VI.14– Ontologie du gestionnaire du contexte

des éléments de manière hiérarchique par la notion subClasseOf Ainsi, la localisation est divisée en espace intérieur (lndoor) et extérieur (Outdoor). Exemple, lorsque le nombre de personnes présentes dans une pièce est supérieure à trois et que l’application Powerpoint est active, le système déduit que l’activité de cette pièce est une présentation : People (Room2401 ; >= ; 3) and Application (PowerPoint ; Running)) RoomActivity (2401 ; Présentation). Notre modèle sépare en deux parties la modélisation du contexte : la première s’intéresse aux concepts décrivant le système à un haut niveau d’abstraction alors que la deuxième reprend les concepts spécifiques à un domaine. Le concept générique "Indoor" se décline par exemple en concepts "Building", "Room", dans le domaine de la Domotique.

Prenons l’exemple de la propriété isLocatedIn, définie comme transitive, Figure 6.15. Le moteur d’inférences, sachant que Amine, isLocatedIn, Bedroom et que Bedroom, isLocatedIn, House, peut inférer que Amine, isLocatedIn, House. Les inférences logiques réalisées par un moteur d’inférences permettent de déduire des connaissances implicites à partir de l’ontologie (modèle explicite) et de règles s’y appliquant.

– Résonner sur les ontologies : Le rôle du gestionnaire de contexte est d’identifier la situation courante pour l’ensemble des contextes, Figure 6.16. Pour ce faire, il interroge la base de connaissances de manière à vérifier les différents prédicats issus de la modélisation des différents contextes. Une fois qu’une situation d’un contexte donné est identifiée, le Gestionnaire de Contexte transmet au gestionnaire services le context courant de la situation. Les environnements pervasifs sont dynamiques par nature. Les dispositifs entrent et sortent de l’environnement ce qui entraine une disponibilité dynamique des services, Lorsqu’un service annonce sa présence a l’infrastructure par le biais d’un protocole de découverts de service (UPnP dans notre cas). L’infrastructure intègre le nouveau service dans le modèle de contexte. Le modèle de contexte doit refléter cet état et en particulier la disponibilité des services pertinents.

– La base de connaissances : La base de connaissances est à l’écoute de l’environnement. Elle est avertie de l’ensemble des évènements issus de l’infrastructure logicielle comme, par exemple, l’apparition ou la dispari-tion de services UPnP. Le Gesdispari-tionnaire de Contexte n’évalue pas en permanence l’ensemble des prédicats des contextes qu’il gère. L’évaluation des prédicats est en fait conditionnée à la réception d’un ou plusieurs évène-ments en provenance de la base de connaissances. On parlera des évèneévène-ments en provenance de l’infrastructure

Figure VI.15– Concepts et relations de l’Ontologie du gestionnaire du contexte

logicielle UPnP issues de :

1. La base de connaissances ne fait que transférer les évènements (la dynamique de l’environnement) qu’elle reçoit au Gestionnaire de Contexte.

2. Traitement du moteur d’inférences qui permet d’inférer de nouvelles connaissances.

– Le moteur d’inference :Le moteur d’inference applique des règles logiques aux faits (connaissances) contenu dans la base de connaissances. Cette base contient le modèle de contexte. Le moteur d’inference accepte en entré un ensemble de règle et de faits prévenant de la base de connaissance. Le mécanisme de résonnement permet au moteur d’inférer de nouveaux faits à partir des faits qui sont stockés dans la base. les nouveaux faits sont à leur tour utilisés pour exécuter de nouvelles règles de plus haut niveaux, prenant l’exemple suivant : sonore ( ?lieu, ?niveau>70 db) and IsLocatedIn( ?lieu, ?visiteur). On peut définir une nouvelle classe conférence comme l’ensemble des lieux contenants des visiteurs grâce à la réglé suivante :

sonore ( ?lieu, ?niveau>70 db) and IsLocatedIn( ?lieu, ?visiteur) == Conference( ?lieu)