• Aucun résultat trouvé

5 Principales plateformes existantes de sensibilite au contexte dans les systemes d’informations pervasifs

Le développement et l’exécution des applications sensibles au contexte peuvent être effectués à l’aide des intergi-ciels sensibles au contexte [BB06] en intégrant dans leurs architectures des entités qui se chargent de gérer le contexte et l’adaptation de l’application. Des premiers prototypes dont le deploiment est resté confiné aux laboratoires, datant des années 90, les premiers travaux en ubiqiuté proposent principalement des services liés à la localisation, Nous nous intéressons spécifiquement aux prototypes suivants :

5.1 ActiveBadge

Le projet ActiveBadge [WHFG92] developpe par la firme Olivetti a permis la realisation d’une application per-mettant l’acheminement des appels telephoniques à une personne selon sa localisation au telephone le plus proche de d’elle. Dans ce type d’organisation, souvent un réceptionniste est charger de transmettre les appels télépho-niques vers les postes internes, dans les bureaux des employés. Il dispose habituellement d’un plan avec les codes des téléphones associés aux utilisateurs. Expérimenté en 1990 au laboratoire de recherche Olivetti en Angleterre, ce projet est généralement considéré comme le premier exemple d’application sensible au contexte. Le projet vise à une meilleure localisation et coordination d’un large groupe de personnes dans une entreprise. Le système utilise des badges émettant des signaux infrarouges (à une fréquence bien déterminée). Ces badges sont portés par le personnel d’une entreprise et chaque badge contient l’identification du porteur, Figure 2.8.

Figure II.8ActiveBadge.

5.2 ParcTab

Le projet ParcTab de Xerox, [WSA+95] est une infrastructure qui favorise le développement des applications sensibles au contexte de localisation (localisation d’une personne, matériel, etc.). Le ParcTab est un assistant personnel digital (PDA) porté par l’usager et fonctionne comme un terminal graphique. Il est en communication infrarouge avec des émetteurs-récepteurs, Figure 2.9. Ces émetteurs-récepteurs communiquent à leur tour (en infrarouge) avec des passerelles. Ces passerelles sont connectées à un réseau local de postes de travail au moyen d’une connexion RS-232. À chaque ParcTab correspond un agent logiciel qui contrôle la communication avec des applications qui s’exécutent sur les postes de travail du réseau local. Cela décharge les ParcTabs des opérations de traitement qui épuisent leurs ressources limitées. Le système de communication est basé sur le mécanisme d’appel de procédure à distance (RPC) entre les ParcTabs et les applications sur les postes de travail du réseau local. Il transmis la notification des courries pour un utilisateur selon sa localisation et les personnes avoisinants par un texte qui s’affiche par le ParcTab ou une simple notification par un signal sonore (le cas échéant de filtrer les courriels urgents lorsque l’utilisateur se trouve en conférence ou réunion).

Figure II.9ParcTab.

5.3 Stick-e-notes

Le projet stick-e-notes, [Pas98] consiste en un cadre de travail pour le développement des applications sensibles au contexte principalement de localisation. Il est basé sur l’utilisation d’un ensemble de PDAs connectés à un capteur de localisation (GPS ou ActiveBadge). Ces PDAs peuvent être en communication ou non selon l’application. L’idée de base est inspirée des bouts de papiers collant (stick notes) qu’on met généralement sur les portes, tables, équipements, etc. Pour se rappeler de quelque chose ou attirer l’attention de quelqu’un. Ces notes seront électroniques et écrites par l’utilisateur et attachées à des contextes bien précis (exemple : localisation) et sauvegardées dans son PDA, Figure

2.10. Ces notes sont déclenchées (affichées ou signalées) plus tard lorsque le même contexte apparaît de nouveau (exemple : l’utilisateur attache une note descriptive d’un musée lorsqu’il se trouve dans ce dernier. Chaque fois que l’utilisateur entre dans cette zone géographique, la note descriptive du musée est affichée). Les notes peuvent être de différents formats : texte, pages HTML, son, vidéo, programme à exécuter.

Figure II.10Stick-e-notes.

5.4 CyberGuide

L’idée du projet cyberguide, [AAH+97] est d’équiper l’utilisateur d’un guide touristique électronique sensible à son contexte (localisation, orientation). L’infrastructure matérielle est composée d’un ensemble d’assistants personnels digitaux (PDAs) connectés à des GPS pour détecter la position du touriste. Ces assistants personnels peuvent communiquer entre eux ou avec un réseau local par infrarouge, Figure 2.11. L’objectif est de guider un touriste dans sa visite touristique en lui offrant les sites intéressants à visiter selon la localisation et les chemins à suivre ainsi que des informations utiles selon sa position.

5.5 Classroom 2000

Dans le domaine de l’education, le projet eClass, [AAF+96] (connu initialement sous le nom Classroom 2000) est une salle de classe augmentée mise en place à l’universite, Figure 2.12. Son role est de capturer les interactions presentes lors d’un cours. La salle possede un systeme d’enregistrement audio et video, un tableau blanc electronique ainsi que des systemes de prises de notes individuels. L’objectif de cet environnement est de capturer les echanges d’information qui ont lieu lors d’un cours et de permettre d’y acceder ulterieurement facilement a l’aide d’une interface Web. On peut egalement citer le projet Smart Classroom ([XSXX01] ; [SXX+03]) de l’Universite de Tsinghua. Ce projet propose egalement d’augmenter une salle de classe traditionnelle (video-projecteurs, tableau tactile, microphones et cameras) afin de permettre une integration naturelle du tele-enseignement au sein d’une classe traditionnelle.

Figure II.12Classroom 2000.

Les architectures proposées sont la plupart spécifiques à un domaine d’application (systèmes de localisationet demandent des efforts supplémentaires pour l’analyse et l’adaptation. Les architectures fondées sur un serveur de contexte souffrent du problème principal d’un système centralisé : lorsque le serveur tombe en panne, tous les autres composants seront affectés. Cela contredit la nature de l’information contextuelle dans un environnement pervasif qui est en général distribuée.

5.6 Tableau Récapitulatif

Le Tableau 2.2 résume les caractéristiques des architectures étudiées :

Tableau II.2Caractéristiques des architectures sensibles au contexte étudiées

Type Architecture Modèle capture interprétation ActiveBadge Client/Serveur Attribut-Valeur Emetteur infrarouge –

ParcTab Client/Serveur Attribut-Valeur IR –

Cyberguide Hybride – GPS, IR –

Stick-e-notes Client/Serveur – GPS –

6 Principales plateformes de gestion du contexte dans les systemes