Projet de fin d études

Transcription

1 INSA de Lyon Département Télécommunications services & usages / LIRIS Projet de fin d études Gestion de données dans des environnements pervasifs 21/12/2007 Version 1 : 28/11/2007 Version 2 : 11/12/2007 Version 3: 17/12/2007 Version 4 : 19/12/2007

2 Remerciement Je voudrais remercier : Frédérique Laforest, ma tutrice de PFE, pour m avoir proposé ce travail très intéressant et pour son soutien technique et matériel. Yann Gripay, mon collaborateur et développeur du projet SoCQ, pour ses compétences et son soutien technique. Jean-Marc Petit, responsable du projet SoCQ, pour ses conseils techniques et ses conseils d orientation. Enfin, je vous remercie pour les conseils et les remarques sur ce mémoire. 2

3 Sommaire 1. Présentation du contexte du projet Système pervasif Projet SoCQ Cahier des charges initial Analyse du cahier des charges et solutions techniques envisagées Analyse du cahier des charges Choix de la technologie et Architecture La technologie UPnP L architecture Choix des outils de développement OSGi &Felix Maven Eclipse (dernière version: Europa) Solutions techniques envisagées Détails du premier scénario Détails du deuxième scénario Réalisation technique Structure une application UPnP Développement des devices UPnP Capteurs de température Devices virtuels Camera IP WebCam Développement des points de contrôle Point de contrôle mode push Point de contrôle mode pull Client du point de contrôle mode pull Tests Tests de la performance Test du scénario complet Retour d'expérience sur la réalisation La prise en main Différentes architectures physiques Etudes de l impact d ajout/suppression/modification de devices sur l architecture Remarques sur Felix Annexe Annexe I : Installation et configuration des outils de développement Installation de Maven Installation et configuration de Felix Installation de capteur de température Dallas Les variables d'environnement Annexe II : Diagramme de classes du device virtuel Annexe III : Diagrammes de classes du point de contrôle mode push Annexe IV : Diagrammes de classes du point de contrôle mode pull Annexe V : Contenue de l archive finale

4 1. Présentation du contexte du projet Ce PFE s'intègre dans le projet SoCQ de l'équipe systèmes d'information pervasifs du laboratoire LIRIS. Il concerne la gestion des données dans les environnements pervasifs. En effet, ces derniers incluent souvent des bases de données classiques et distribuées, mais aussi des capteurs fournissant des flux de données et des services répartis permettant d'effectuer des appels de méthodes pour récupérer et traiter des données ou d'agir sur l'environnement (actionneurs). 1.1 Système pervasif La notion de système pervasif est introduite par Mark Weiser dans son article «The computer for the 21st century». Les systèmes d'information pervasifs ont pour objectif d'intégrer le traitement de l'information dans tous les objets des activités journalières. Ils s intègrent dans l environnement jusqu à devenir invisible. Quelqu'un "qui utilise" des systèmes pervasifs engage beaucoup de dispositifs et de systèmes informatiques simultanément, au cours de ses activités ordinaires, et n'est pas nécessairement averti qu'il en est ainsi. Les systèmes pervasifs sont qualifiés par quatre critères : - Ubiquitaire : accessible de n importe où - Mobile : comporte des terminaux mobile - Sensible au contexte : prend en compte le contexte d exécution - Ambiant : intègre des objets quotidiens 1.2 Projet SoCQ Le projet SoCQ (Service-oriented Continous Queries) a pour but de développer un cadre (framework) permettant de faciliter le développement d'applications dans des environnements pervasifs: ces applications pervasives sont définies de manière déclarative sous forme de requêtes continues orientées service. Le cadre (framework) SoCQ offre une représentation homogène des relations standards, des flux de données et des services, et permet de définir des requêtes continues combinant ces sources de données non-conventionnelles. Les sources de données sont représentées sous forme de tables comportant des attributs réels (des attributs classiques dans des tables des bases relationnelles), ainsi que des attributs virtuels, qui représentent les paramètres d'entrée/sortie des services. La valeur de ces attributs virtuels ne sont pas enregistrées dans les tables, mais sont obtenues de manière dynamique en invoquant les services correspondants pendant l'exécution des requêtes continues. Les requêtes SoCQ, exprimées dans un langage à la SQL, permettent ainsi de définir une partie du comportement des applications pervasives combinant les données des relations classiques et les flux de données en provenance de capteurs, et invoquant des services (capteurs ou actionneurs) de l'environnement. Un prototype d'un moteur de requêtes SoCQ a été développé et permet d'exécuter de manière continue ce type de requête. 4

5 2. Cahier des charges initial Ce PFE a pour objectif de fournir un exemple de système pervasif incluant divers types de sources de données. Il faudra : - définir un environnement pervasif intégrant les dispositifs physiques disponibles au laboratoire LIRIS et au département TC, - y associer différents scénarios, - concevoir l'architecture et les sources de données correspondantes, - implanter et tester cette architecture (prototype SoCQ développé en langage C++ au laboratoire LIRIS). L'environnement et les scénarios qui seront prototypés serviront de support aux tests et à l'évaluation de l'outil SoCQ. 5

6 3. Analyse du cahier des charges et solutions techniques envisagées 3.1 Analyse du cahier des charges Le travail consiste à définir un exemple d'environnement pervasif avec différentes sources de données. Nous avons un serveur dédié aux traitements des requêtes continues (SoCQ), et l'environnement pervasif inclut des caméras, des capteurs... Quel est le lien entre eux? Fig. 1 Problématique Les sources de données sont des dispositifs tels que des capteurs. Les matériels mis à ma disposition sont : - Cinq capteurs de température Dallas de type Thermochron ibutton DS1921 ( qui se branchent sur des ports USB - Une webcam de marque Logitech qui se branche sur un port USB - Une caméra IP Axis 221 Network Camera, il contient un serveur web et se branche directement sur le réseau Ces dispositifs doivent fournir des données au moteur de requêtes SoCQ. Mais par quel moyen? Comment les faire communiquer? Comment prendre en compte le réseau de tous ces capteurs? Qu'est-ce qui se passe si un dispositif rejoint ou quitte ce réseau? A côté des sources de données, je dispose également d'un actionneur qui agit sur l'environnement un serveur de messagerie instantanée Jabber. Jabber utilise le protocole XMPP (Extensible Messaging and Presence Protocol), c est un protocole 6

7 standardisé open-source qui utilise la technologie XML pour les échanges de messages instantanés développé par Jabber Software Foundation ( Jabber fonctionne en mode client/serveur. Un réseau de Jabber est décentralisé, composé de plusieurs servers reliés entre eux, le fonctionnement ressemble à celui du . Les messages instantanés sont transférés d'un utilisateur à l'autre de serveur en serveur. Chaque utilisateur a un «Jabber ID» qui est composé d'un nom d'utilisateur et un nom de serveur, les deux champs sont séparés par un «@». De nombreux serveurs Jabber possède un service de transport qui permet aux utilisateurs de communiquer avec d'autres systèmes de messagerie instantanée, tel que MSN Messenger ou Yahoo! Messenger. Comment intégrer cet actionneur dans ce projet? Comment interagit-il avec des sources de données et le moteur de requête SoCQ? Afin d'intégrer tous ces différents composants et montrer un exemple des systèmes pervasifs, deux scénarios d'utilisation sont envisagés: - Le premier scénario envisagé est de déployer des capteurs de températures dans différentes salles du laboratoire LIRIS, un seuil de température est fixé par le moteur SoCQ pour chaque pièce, si un dépassement de seuil a lieu, un message instantané sera envoyé à un responsable pour lui informer (et ces informations seront également écrites dans un fichier log). - Le deuxième scénario consiste à faire de la surveillance par caméra en plus de la surveillance des températures. Si un dépassement de température a lieu, le responsable de la surveillance peut obtenir une photo de cette pièce. Dans le projet SoCQ, le moteur de requêtes génère différents type de requêtes pour interroger des bases de données qui contiennent des tables avec attributs réels et virtuels. Ces requêtes continues travaillent avec des flux de données (un flux de températures dans notre application) et font des appels de services. En effet, les requêtes continues utilisent le flux de températures pour faire des moyennes des températures reçus pendant les 15 dernières secondes, ces moyennes sont comparées avec des seuils dans les tables de SoCQ. Si un dépassement de seuil a lieu, les requêtes continues appellent les services (envoi de messages et prise de photos). 7

8 3.2 Choix de la technologie et Architecture La technologie UPnP Afin de répondre aux questions concernant les sources de données posées précédemment, la technologie adoptée est UPnP. UPnP (Universal plug and play) est un protocole réseau qui a pour objectif de permettre à différents périphériques à se connecter facilement et sans configuration. Ce protocole s'adapte parfaitement à l'environnement pervasif grâce a ses principales caractéristiques qui sont : Zéro configuration Indépendant du système d'exploitation Auto-découverte Indépendant du langage de programmation Adressage IP, un agent DHCP sur chaque device. Un réseau UPnP est composé des devices UPnP, des services et un point de contrôle. Un device UPnP est un conteneur de services associés à un dispositif physique ou logiciel qui offre des services. Chaque device UPnP peut contenir plusieurs services. La description d un device est encapsulée dans un fichier XML. Un service contient plusieurs actions et des variables d états pour représenter ses états. Sur un device UPnP, un service est composé d une table de variables d états, un serveur de contrôle et un serveur d événements. Le serveur de contrôle reçoit les requêtes pour exécuter les actions, met à jour les variables d état associées et retourne les résultats. Le serveur d événements informe les abonnés des changements d état des services qu ils écoutent. Le point de contrôle dans un réseau UPnP a plusieurs rôles: découverte dynamique des devices enregistrement des services fournis par chaque device invocation des actions des devices selon les besoins abonnement auprès des sources d événement des services, pour être notifié du chaque changement d état des services L architecture Le point de contrôle doit interagir avec le moteur de requête SoCQ en lui fournissant des flux de données et/ou des paramètres d'entrées/sorties pour des requêtes, et également traiter les commandes provenant du moteur. Ainsi deux types de point de contrôle sont nécessaires : - Un en mode push qui se comporte en tant qu un client TCP pour fournir les flux de données en continue - Un autre en mode pull qui se comporte en tant qu un serveur TCP et qui attend les commandes du moteur de requêtes SoCQ. Le moteur SoCQ se comporte donc comme un serveur TCP dans le premier cas et comme des clients TCP dans le seconde. Les clients TCP sont lancés à l aide des scripts (scripts SHELL sous Linux). 8

9 Voici l architecture globale envisagée : SoCQ Script pour lancer un client Serveur TCP Commandes du SoCQ Control point en attente des commandes du SoCQ (Pull) Client TCP UPnP TCP/IP UPnP Capteurs, webcam,caméra Flux de données Control point fournir des données (Push) Fig.2 Architecture globale 9

10 3.3 Choix des outils de développement OSGi &Felix OSGi ( est un ensemble de spécifications qui est applicable aux passerelles installées entre un réseau extérieur tel qu'internet et un réseau local tel qu'un réseau domestique. C'est une plateforme de déploiement et d exécution pour les applications JAVA. Les applications s exécutent sous forme de bundles (archives JAVA). Les bundles peuvent interagir entre eux à travers des services qui sont spécifiés par des interfaces JAVA fournies par OSGi. Dans ce projet nous avons utilisé Felix ( qui est une implémentation d OSGi. Nous avons choisi OSGi car il propose un ensemble des API JAVA qui permet de transformer les dispositifs physiques en device UPnP, et offre également des facilités pour développer et exécuter des applications UPnP Maven Maven(maven.apache.org) est un outil de build open-source pour des projets JAVA, qui est basé sur le principe de Project Object Model (POM). Un POM contient une description détaillée du projet, avec en particulier des informations concernant les versions, la gestion des configurations, les dépendances, les ressources de l'application, les tests, les membres de l'équipe, la structure et bien plus encore. Le POM prend la forme d'un fichier XML (pom.xml) qui est placé dans le répertoire de base du projet. Maven permet de fabriquer facilement des bundles pour Felix, c'est la raison pour laquelle nous l'avons adopté Eclipse (dernière version: Europa) Eclipse IDE est un environnement de développement intégré pour JAVA. Ses nombreuses fonctionnalités facilitent l'édition du code et la gestion de projets; elles permettent un développement plus rapide. Grâce à son architecture complètement développée autour de la notion de plug-in, Maven peut y être intégré. De plus, Felix peut être lancé dans Eclipse également, ainsi facilite le débogage des bundles. 10

11 3.4 Solutions techniques envisagées La communication entre le moteur de requête SoCQ et les deux points de contrôle se fait par Socket TCP. Dans le mode pull, les clients lancés par SoCQ créent les connexions clientes vers le point de contrôle, envoient les commandes, reçoivent ensuite les résultats et ferment les connexions. Ces commandes sont : - GetTemp : pour récupérer les températures de toutes les pièces - texte : pour envoyer un message d alerte text à - GetImage : pour obtenir des photos prises par la caméra et la webcam Les points de contrôle communiquent avec des devices UPnP en utilisant le protocole UPnP. Felix fournie un bundle «UPnP Base Driver» qui a 2 rôles: - exporter les services locaux org.osgi.service.upnp.upnpdevice à l'extérieur de la passerelle. - instancier un service en local org.osgi.service.upnp.upnpdevice pour chaque device distant découvert sur le réseau UPnP. Grâce à ce bundle, les points de contrôle peuvent découvrir tous les autres devices enregistrés dans le cadre (framework) Felix et ainsi les contrôler Détails du premier scénario Description des requêtes SoCQ Trois tables dans le moteur SoCQ sont utilisées dans ce scénario, voici leurs schémas: STREAM Temperatures (Area CHAR, Temperature REAL) RELATION Surveillance (Area CHAR, Manager STRING(20), Threshold REAL, AlertMessage STRING(20)) RELATION Employees (Name STRING(20), Address STRING(50), Messenger SERVICE, Message STRING(20) VIRTUAL, Sent CHAR VIRTUAL) Les explications : - «Temperature» : C est une table de type «Stream», qui représente le flux de températures. Elle contient les localisations des capteurs (type caractère) et les valeurs des températures (type réel) ; - «Surveillance» : C est une table de type «Relation», elle contient les identifiants des zones des capteurs (type caractère), les noms des responsables de la zone de surveillance (type chaîne de caractère), les seuils de températures (type réel) et des messages d alerte à envoyer (type chaîne de caractère) ; - «Employees» : C est une table de type «Relation», elle contient les noms des employées (type chaîne de caractère), leurs adresses de messagerie (type chaîne de caractère), le type de services (type «Service»), des messages à envoyer (type chaîne de caractère virtuelle) (explication dans 3.4.2), et le statu des envois de messages (type 11

12 caractère virtuel). Dans cette table, les messages et les status sont des attributs virtuels, c est-à-dire qu ils sont obtenus dynamiquement en appelant des services. Pour obtenir une moyenne de températures, SoCQ utilise la requête suivante : CREAT RELATION MeanTemp (Area CHAR, MeanTemperature REAL) AS SELECT Area, AVG (Temperature) FROM Temperature [15s] GROUP BY Area Cette requête crée une nouvelle table «MeanTemp» pour stocker les moyennes de température en utilisant les données des 15 dernières secondes des «Temperature». Pour déclencher l appel du service de messagerie en cas de dépassement de seuils, SoCQ fait une jointure entre les tables «MeanTemp», «Surveillance» et «Employees», avec les moyennes de température calculées dans «MeanTemp», SoCQ les compare avec les seuils dans «Surveillance», si les moyennes sont supérieures aux seuils, la jointure des trois tables permet de savoir où ces dépassements ont lieux et à qui envoie les messages. Ensuite SoCQ envoie une commande au point de contrôle pour qu il invoque l action d envoi de messages. La requête est la suivante : SELECT Area,Manager,Threshold,MeanTemperature,Sent STREAMING ON INSERTION FROM MeanTemp T, Surveillance S, Employees E WHERE S.Manager = E.Name AND S.Area=T.Area AND S.Threshold<T.MeanTemperature AND E.Message=S.AlertMessage Détail du scenario 1 Dans le premier scénario, le format du flux de température est défini par SoCQ: +:0:id:location temperature, («+» : insertion d un tuple ; «0» : réservé par SoCQ ; «id» : numéro de tuple ; «location» : localisation du capteur ; «temperature» : température mesurée par un capteur), elle est encapsulée dans une chaîne de caractère (String). SoCQ peut ensuite extraire chaque partie dont il a besoin et remplir la table correspondante dans sa base. Les capteurs de température fournissent périodiquement au point de contrôle mode push les températures qu'ils mesurent, puis ce point de contrôle forme un flux pour les envoyer en continue à SoCQ. L'autre point de contrôle mode pull attend les commandes d envoi de messages de SoCQ en cas de dépassement de seuil de température, ensuite il transmet l'adresse destinataire et le contenu du message au device UPnP qui offre ce service de messagerie, puis les messages sont envoyés par ce device aux utilisateurs et au fichier de log. Voici le schéma du fonctionnement du premier scénario : 12

13 GetTemp action performed: Temperature Invoke the UPnP action GetTemp «SendMessage» action performed Invoke «SendMessage» action with input «Too hot!!!» Fig.3. Scénario I- Surveillance de température Détails du deuxième scénario Description de la requête SoCQ Une table de plus est utilisée dans ce scénario : «Cameras» (Son schéma : RELATION Cameras (Camera SERVICE, UrlPhoto STRING(100) VIRTUAL)) qui contient un service camera (type Service) et des URLs (type chaîne de caractère virtuelle), sa valeur est obtenue après les appels de l action qui récupère des photos. La table «Employees» a un attribut de plus «UrlPhoto» de type chaîne de caractère virtuelle, sa valeur est obtenue avec les requêtes continues (jointure entres «Camera» et «Employees»). SoCQ concatène «UrlPhoto» et «Message» de la table «Employee» pour former le contenue du message (Ex : «Un peu chaud! puis il utilise la requête montrée précédemment pour déclencher l envoi de ce message aux utilisateurs Détail du scenario 2 Dans le deuxième scénario, le client SoCQ peut envoyer une commande à point de contrôle mode 13

14 pull pour lui demander une image prise en temps réel. A la réception de cette commande, le point de contrôle cherche des images sur la webcam et la caméra, et les stocke en mémoire, puis retourne des adresses URL (un String) à SoCQ. Les utilisateurs peuvent ensuite visualiser les images dans un navigateur Web grâce aux Servlet générés par le point de contrôle. Chaque demande de client retourne des URL différentes, les images sont conservées pendant 10 minutes. La raison pour laquelle la réponse au client est une adresse URL au lieu d une image est que SoCQ ne traite pour l'instant dans ses tables que des données textes. Voici le schéma du fonctionnement du deuxième scénario : Requête continues: Too hot? - true, goto step 4 - false: do nothing Serveur TCP Flux de température 3 SoCQ Script qui lancer deux clients: - send message - get image Client TCP GetImage 4 GetImage action performed: Return a URL to SoCQ 7 TCP/IP Control Point (pull mode) Control Point (push mode) 1 Invoke the UPnP action GetTemp GetTemp action performed: Temperature 2 8 UPnP «Un peu chaud! URL» 11 to get image Presente the image by servlet 12 5 GetImage action performed: send the image to control point Invoke «GetImage» action 6 UPnP Invoke «SendMessage» action with input «Un peu chaud! URL» 9 SendMessage action performed: Send message to users: «Un peu chaud! URL» 10 Capteurs, webcam,caméra SendMessage action performed: Write to the file 10 Log File Fig.4. Scénario II- Surveillance de température + caméra 14

15 4. Réalisation technique 4.1 Structure une application UPnP Avant de commencer le développement, j ai d abord étudié l architecture générale d une application UPnP. Nous pouvons distinguer deux types d application : - device UPnP qui représente un dispositif physique (ou virtuel) - point de contrôle qui coordonne des devices et contrôle le réseau Selon les spécifications d OSGi, différentes interfaces doivent être implémentées selon l application développée. Ci-dessous un diagramme illustrant les relations entre ces différentes interfaces. Fig.5 Architecture d une application UPnP - L interface «UPnPDevice» représente un device UPnP, les classes d implémentation contiennent les descriptions des devices, des méthodes pour récupérer les services et les actions associées. - Un device peut offrir un ou plusieurs services «UPnPService», chaque service contient une ou plusieurs actions «UPnPAction». Chaque action prend comme argument d entrée un dictionnaire (Dictionary) et retourne un dictionnaire (argument de sortie) comme résultat d exécution. - A chaque action est associée une ou plusieurs «UPnPStateVariable», ces variables d état sont associées aux arguments d entrée/sortie d une action, elles spécifient leur types, contiennent leur valeurs et leur noms. Ces variables sont également associées aux services qui offrent les actions correspondantes. Elles peuvent être utilisées comme des sources d'événement. - Avec OSGi, «UPnP Event» sont délivrés aux applications qui implémentent l interface «UPnPEventListener». Un UPnP Event peut être un changement de température dans notre cas. - Un device peut avoir une icône «UPnPIcon» qui permet de visualiser son état dans un navigateur web grâce au «HttpServlet». Pour développer un device UPnP, les interfaces «UPnPDevice», «UPnPAction», «UPnPService» 15

16 et «UPnPStateVariable» sont à implémenter obligatoirement, les autres cités ci-dessus sont optionnelles selon les besoins. Après avoir créé des devices, ils peuvent être lancés dans Felix : - L interface «BundleActivator» est le point d entrée de chaque application, il crée le contexte d exécution pour chaque bundle, crée des devices UPnP et enregistre/désenregistre ces devices(sous forme de services dans OSGi) auprès du cadre(framework). Du côté de point de contrôle, il n a pas besoins de toutes ces interfaces qu un device UPnP implémente, il implémente que «BundleActivator» et «ServiceListener». - L interface «ServiceListener» représente un listener, elle contient des méthodes de gestion de cycle de vie d un bundle. Lorsqu un «ServiceEvent» est déclenché, le bundle est informé et exécute les actions correspondantes. Un «ServiceEvent» est un événement de changement de cycle de vie d un bundle (enregistré, modifié ou désenregistré auprès du cadre (framework)). Le point de contrôle met des arguments d entrées dans les dictionnaires pour invoquer des actions. 4.2 Développement des devices UPnP Capteurs de température Un programme exemple qui transforme un capteur de température en device UPnP est utilisé puis modifié et amélioré. Ce device UPnP ne contient qu un service - «GetTemperatureLocationService» dans lequel il y a deux actions : «GetTemperature» et «GetLocaton». La classe d'implémentation de l'interface «UPnPDevice» crée un objet «SensorModel» qui représente un capteur physique. Cette classe «SensorModel» utilise des API du fournisseur Dallas pour piloter le capteur physique. Le résultat de l'action «GetTemperature» est un dictionnaire qui contient des températures mesurées. La variable d état associée-«temperature» est un «EventSource». Le changement de température est un «UPnPEvent». Le bundle est informé à chaque déclenchement d un tel événement. Comme décrit précédemment, le flux de données envoyé contient deux informations : la température et la localisation. Un attribut «user-defined» est donc ajouté dans la description de device - «Localisation» pour représenter la localisation du device. Cette information est configurable dans un fichier et est lu par le bundle activator de chaque device. L action «GetLocaton» a pour but de récupérer cet attribut, car pour les devices distants, le protocole UPnP ne peut récupérer à travers le bundle UPnP Base Driver que des attributs standards que le protocole UPnP a définis. Voici le diagramme de classe d un capteur de température : 16

17 Fig.6 Diagramme de classe d un capteur de température Devices virtuels Les devices virtuels sont créés pour plusieurs raisons : - Former un réseau UPnP plus réaliste avec plusieurs devices UPnP en fournissant des températures aléatoires, mais sans se soucier d'installer des dizaines voir des centaines de vrais dispositifs UPnP - Offrir la fonction de messagerie - Faciliter les tests Ce device virtuel a un service «VirtualService» dans lequel il y a trois actions: «GetLocation» (récupérer l'attribut «Localisation»), «GetVirtualTemperatureAction» et «SendMessage». La génération de température aléatoire est réalisée par l action «GetVirtualTemperatureAction». Les valeurs de température que peut générer un device virtuel sont fixées entre 23 C et 28 C avec un pas de variation de 0.5 C. En fonction de la valeur aléatoire généré par Math.random(), nous faisons augmenter ou baisser la température. La fonction d envoi de message d alarme est réalisée par une action «SendMessage». Cette action aura deux arguments d entrée : l adresse à qui envoyer le message et le contenu du message. Ces deux informations sont transmises par le point de contrôle mode pull. Si l invocation réussie, le client SoCQ reçoit le caractère «t» (pour «true») comme confirmation. Dans notre application, le device qui offre ce service de messagerie est un client Jabber, c'est-à-dire 17

18 qu un utilisateur virtuel qui possède un Jabber ID. Pour développer un client Jabber, Smack qui est une librairie du client Jabber est utilisé. Il fournit un ensemble d'api JAVA pour développer un client Jabber complet. Grâce à Jabber, des messages peuvent être envoyés aux utilisateurs réels qui utilisent des services de messageries, ce qui rend notre scénario plus réaliste. Le digramme de classe est fourni en Annexe II Camera IP Le device UPnP qui représente la camera ne pilote pas directement la caméra physique, car sur la caméra il n y a pas d action (Il n y a pas une classe comme «SensorModel» qui représente la caméra physique). Cette caméra a une adresse IP et fournit un serveur Web. Ce device UPnP contient un service «GetImage» qui offre deux actions: «GetLocation» et «GetImage». L'action «GetImage» ne fait que de demander à la caméra de lui fournir une image en temps réel par un flux de tableau de bytes qui est le résultat d exécution de cette action. Ce tableau est récupéré par le point de contrôle mode pull (section 4.3.2). La communication entre ce device UPnP et la caméra physique est basée sur HTTP WebCam Le cadre (framework) JMF (Java Media Framework) est nécessaire pour piloter la webcam. C est un ensemble d API cross-platform permettant de créer des applets et des applications qui représentent, capturent, manipulent et stockent des données multimédia temporelles. Un programme exemple est utilisé pour représenter et piloter la webcam Logitech. Ce programme implémente «JFrame», «WindowListener» et «ComponentListener», il possède une méthode qui prend une image en temps réel lorsque l utilisateur clique le bouton «Capture» dans le menu, puis enregistre cette image dans un fichier.jpg. Ci-dessous une capture d'écran de l'interface de la webcam: Fig. 7 Menu du programme exemple de la webcam 18

19 Le device UPnP qui représente notre webcam possède la structure identique qu un capteur de température. Il offre un service «GetImage» qui a deux actions : «GetLocation» et «GetImage». L action «GetImage» appelle la webcam physique pour prendre une image en temps réelle. L image récupérée est de type «Image» (java.awt.image), cette image est ensuite représentée par un «BufferedImage» (java.awt.image.bufferedimage), puis transformée en tableaux de byte pour être stockée dans un dictionnaire qui est retourné comme paramètre de sortie de l action. 4.3 Développement des points de contrôle Les deux modes de point de contrôle ont des points communs : - Découverte dynamique des devices UpnP - Stockage des différents devices découverts selon le type de leurs services - Invocation des actions La classe «UpnPDevServ» s en charge de créer un couple device-service pour répondre au besoin de stockage des devices cité ci-dessus. Le fonctionnement est ainsi : 1. Pour chaque device(service) récupéré par le point de contrôle, le constructor cette classe le prend en paramètre d entrée pour crée le device de ce couple. 2. La méthode «setservice(string servid)» défini le service, parmi tous ceux que ce device offre, celui qu on souhaite stocker pour ce couple device-service. La découverte dynamique est réalisée en implémentant l interface «ServiceListener» qui écoute les «ServiceEvent». Lors qu un nouveau device (service pour le cadre (framework) Felix) s est enregistré auprès de Felix, le couple device-service est créé et ajouté dans le tableau de device ; si ce service est modifié, le couple serait mis à jour dans la table ; s il est désenregistré, le couple serait supprimé de la table Point de contrôle mode push Ce point de contrôle stocke dans sa table de device que les devices qui récupèrent les températuresles capteurs de température Dallas et les devices virtuels. Il se comporte comme un client TCP, une fois lancé, il se connecte à SoCQ, lui fournit périodiquement tous les températures viennent de tous les devices UpnP. La période d invocations des méthodes «GetTemp» est configurable dans un fichier sous le nom de «sleeptime». En effet, au démarrage du point de contrôle, l activator de ce bundle cherche et récupère tous les devices dans le réseau, lit le «sleeptime» depuis le fichier, puis crée et lance un Thread, toutes les fonctionnalités du point de contrôle est géré par ce Thread. Il y a une boucle infinie dans ce Thread, après chaque invocation de «GetTemperautre» de tous les device et envoi de flux, ce Thread s endort pendant ce «sleeptime» puis se réveille et effectue de nouveau l invocation et l envoi. Son diagramme de classe est fourni en Annexe III Point de contrôle mode pull Ce point de contrôle répond aux trois commandes de SoCQ décrit précédemment. Il se comporte 19

20 comme un server TCP pour SoCQ. Au démarrage du point de contrôle, l activator du bundle cherche et récupère tous les devices dans le réseau, crée et enregistre un Servlet («PresentationImageServlet», explication dans le paragraphe suivant), puis crée un pool de connections en utilisant «ExecutorService». Le pool de connexion permet d accepter 10 connexions clientes en parallèle. Le «PresentationImageServlet» s occupe du stockage et présentation d image. Le point de contrôle a une Hashtable «imagestore» pour stocker les images récupérées, ce «imagestore» est passé en argument d entrée au constructeur du Servlet. Ce Servlet a une méthode «addimage» pour remplir cette Hashtable et retourne un String qui est le nom de l image stocké. Les images sont numérotées, leurs noms sont de format «ImageId.jpg», «Id» est un static int qui s incrémente de 1 chaque fois qu une image est stockée dans «imagestore». Le point de contrôle utilise les noms des images pour former des URL. Ainsi, l utilisateur peut revoir des images qu il a demandées précédemment et qui ne sont pas périmées en tapant les différentes URL correspondantes. Pour savoir si une image est dans «imagestore» pendant plus de 10min qui doit être supprimée, il faut lui associé un temps. Un «Calendar» est utilisé pour obtenir le temps actuel. Une classe «Image» est créé pour représenter ce couple image-temps, il utilise le même principe que la classe «UpnPDevServ» décrit précédemment. Lorsque le client demande une image, s il existe des images dans «imagestore» qui possèdent un temps plus vieux que le temps de cette nouvelle image, elles seront enlevées de la table. La taille de «imagestore» ne dépend pas seulement de l intervalle de temps, mais plutôt du nombre de requêtes. Toutes les images ne sont stockées que dans la mémoire, l arrêt du point de contrôle entraine la perte de toutes les images. Son diagramme de classe est fourni en Annexe IV Client du point de contrôle mode pull Les clients sont lancés par SoCQ à l aide des scripts. La commande pour lancer un client à la main est : java ClientSoCQ hostname_du_pull_mode_control_point 6790 nom_de_la_commande (6790 est le numéro de port sur lequel le point de contrôle accepte les connexions, nom_de_la_commande est «GetTemp» ou «GetImage» ou Text»). Ce client récupères les commandes et ajoute le symbole a partir du nom_de_la_commande pour séparer le nom_de_la_commande et les paramètres de la commande, puis il transmet «nom_de_la_commande param_1 param_2 param_n» au point de control mode pull, ce point de control transmet ensuite que la partie «param_1 param_2 param_n»au SoCQ, SoCQ peut ainsi effectuer des traitements. 20

21 4.4 Tests Tests de la performance : Les tests de performance sont uniquement effectués pour le point de contrôle mode pull. Le critère de performance est le temps pour effectuer une invocation d action sur un device UPnP. Ceci ne concerne pas le point de contrôle mode push, sa période d envoi de flux de température est fixée par l utilisateur. Quatre scénarios de tests ont été effectués pour comparer le temps d un appel pour les trois actions (GetTemperature, GetImage et SendMessage). Voici les quatre scénarios de tests, le point de contrôle, le clientsocq et le device UPnP sont installés sur un ou deux ou trois PC, les PC sont dans un même LAN avec liaisons TCP/IP. Fig. 8 Quatre scénarios de tests Pour mesurer le temps d appel, chaque action est invoquée 10 fois de suite (le ClientSoCQ est lancé 10 fois par un script), le temps d exécution d un appel est donc le temps total divisé par 10. Cette opération est effectuée 3 fois afin d obtenir la moyenne pour chaque action et chaque scénario. Pour l action «GetTemperature», les tests sont effectués respectivement sur un capteur de température et un device virtuel, il n y a pas de différence de temps; pour l action «SendMessage», le message envoyé est «Hello, il fait trop chaud». Nous avons comparé le temps d écriture dans un fichier et un vrai envoi de messages, dans les deux cas, la différence de temps est négligeable. Pour l action «GetImage», les tests sont effectués sur la webcam. Voici les résultats des tests, l unité de temps est en seconde. GetTemperature GetImage SendMessage Test Test Test Test Tableau 1 : résultat des tests de performance 21

22 Dans le Test 1, le point de contrôle, le clientsocq et le device UPnP sont sur un même PC, le temps d une invocation est beaucoup plus petit que dans les trois autres cas, car la transmission réseau nécessite du temps (0.2 à 0.3 seconde). Nous avons remarqué que dans le Test 4, le temps d invocation pour «GetTemperature» est plus petit que dans le Test 2 et 3, la raison probable est que le capteur est sur le même PC que le point de contrôle. Pour l action «SendMessage», le temps d invocation est d environ 0.5 seconde, cependant, le client reçoit les messages 2 ou 3 secondes plus tard, car bien que l action soit effectuée et terminée, les messages ne sont pas encore arrivés jusqu au client à cause de la transmission réseau et du protocole de communication XMPP. Après le démarrage des devices UPnP et le point de contrôle, la première invocation nécessite plus de temps (2 seconde environ), puis le temps d appel devient stable. Les architectures des Test 1et 4 ne sont pas réalistes, car dans la réalité, les devices UPnP sont répartis sur de nombreux PC. Le facteur sur lequel on peut agir est la position du point de contrôle, il peut être sur un même PC que SoCQ ou non, il n y a pas de différences significatives au niveau de performance, donc nous pouvons choisir une des deux structures en fonction des contraintes matérielles. Nous avons aussi testé le temps de la découverte dynamique des devices. Lorsqu un device distant (qui n est pas sur le même PC que le point de contrôle) rejoint le réseau, il faut environs 45 à 50 secondes pour que le point de contrôle le détecte et l ajoute dans sa table. Nous ne pouvons pas améliorer ce temps, car cela dépend du protocole UPnP et le bundle UPnP BaseDriver. Nous avons aussi remarqué des erreurs de réseau dans Felix avant l ajout de nouveaux devices Test du scénario complet Les tests sont effectués avec le moteur de requête SoCQ. Les deux points de contrôle (mode pull et mode push) sont lancés sur un seul PC, les devices (deux capteurs de température, une caméra IP, une webcam, trois devices virtuels) sont répartis sur plusieurs PC afin de rendre les tests plus réalistes. Le temps pour qu une image soit périmée est fixé à 30 secondes pour les tests. Voici un schéma pour illustrer la structure logique du test: Requêtes continues Push-mode Control point Flux de température SoCQ Données / Résultats des requêtes Visualizer Appels des actions Pull mode Control point Fig.9 Structure du test 22

23 Le point de contrôle mode push fournit à SoCQ un flux périodique de températures. Grâce aux requêtes continues, SoCQ peut appeler les différentes actions. Le visualizer est une interface de visualisation des tables de SoCQ, il se connecte à SoCQ pour récupérer et afficher le contenu des différentes tables Tests du scénario 1 : Voici les résultats obtenus : - Démarrage du point de contrôle mode pull: Fig.10 Démarrage du point de contrôle mode pull - Découverte/suppression dynamique des devices Fig. 11 L ajout de la caméra IP Fig.12 L ajout d un device virtuel Fig. 13 Suppression d un device virtuel 23

24 - Démarrage du point de contrôle mode push /Création et Envoi du flux de température: Seul les devices qui fournissent la température (Deux capteurs de températures et trois devices virtuels) sont ajoutés. Fig. 14 Démarrage du point de contrôle mode push - Affichage du flux de données: Le visualizer affiche dynamiquement le contenu de la table «t6_temperatures» au fur et à mesure que SoCQ reçoit les données. Cette copie d'écran représente la table «t6_temperatures» (table de température): la première colonne est le numéro de tuple, la deuxième la localisation, la troisième des températures. «c» est pour le type caractère (character); «r» pour le type réel. Fig. 15 Visualizer : table «t6_temperature» - création/envoi du flux de températures - Invocation de l action «SendMessage» : Ci-dessous la copie d écran d envoi de messages du côté de point de contrôle mode pull: 24

25 Fig. 16 Envoi de message en cas de dépassement de seuil La copie d'écran ci-dessous du visualizer représente la table «qt6» ( table des résultats de la requête continue d'envoi de messages): la première colonne est le numéro de tuple, la deuxième la localisation, la suivante le nom du responsable, puis le seuil de la salle, la moyenne des températures mesurées de la salle et le résultat d'envoi de messages.«c» est pour le type caractère (character); «s10» est pour une chaine de caractère de longueur 10; «r» est pour le type réel. Fig.17 Visualizer : table «qt6» Les messages sont bien reçus par le responsable de surveillance de la zone «D» qui utilise MSN 25

26 Messenger avec le message «Pfiou». Avec la requête continue que SoCQ a définie, un message est envoyé chaque seconde tant que le seuil de température est dépassé. Fig. 18 Fenêtre MSN : messages reçus pour la responsable de la zone D Les messages sont également écrits dans un fichier de log : Fig. 19 Messages écrits dans le fichier de log 26

27 Tests du scénario 2 - Invocation de l action «GetImage» Ci-dessous la copie d écran du côté de point de contrôle mode pull. Il y a eu deux dépassements de seuil, deux photos (Webcam-1_image308.jpg et Camera-1_image309.jpg) sont ajoutées dans «imagestore», puis deux messages d alerte avec les URL pour visualiser ces deux images sont envoyés à l adresse «szlycn@hotmail.com» : Fig.20 Invocation du «GetImage» du côté de point de contrôle mode pull La copie d écran ci-dessous montre la table «qt7» (résultat de la requête d envoi de message avec URL) dans SoCQ. Cette table possède une colonne de plus, qui contient des URL des images stockées dans «imagestore». Les messages sont bien envoyés avec la confirmation «t» (dernière colonne). Fig. 21 Visualizer : table «qt7» Ci-dessous la copie d écran de la fenêtre de conversation MSN du responsable de la surveillance, les 27

28 messages sont bien reçus. En cliquant sur les URL, le responsable peut visualiser les images tant qu elles ne sont pas périmées: Fig. 22 Fenêtre MSN : messages reçu Fig.23 Visualisation d une image 28

29 5. Retour d'expérience sur la réalisation 5.1 La prise en main L architecture d une application UPnP est un point clé, c est-à-dire les relations entre différentes interfaces que propose OSGi, et les interactions entre les bundles du Felix. Une fois cette étape franchie, la suite du développement devient plus fluide. Un bon niveau en JAVA favorise la compréhension des fonctionnements. Dans ce PFE, deux librairies supplémentaires sont utilisés : JMF et Smack. Grâce aux programmes exemples trouvés sur Internet, la compréhension est assez rapide. 5.2 Différentes architectures physiques L architecture logique est celui défini dans la partie «Analyse de cahier des charges», cependant, l implémentation physique peut être différente. Le moteur SoCQ et le point de contrôle peuvent être sur une même machine ou deux machines différentes. L impact est sur le temps de transmission réseau. S ils sont sur une seule machine, l exécution est plus rapide. 5.3 Etudes de l impact d ajout/suppression/modification de devices sur l architecture Dans le mode push qui fournit les sources de données, lorqu un nouveau type de device est ajouté, un nouveau type de flux de données est fournit. Pour transmettre ce flux au SoCQ, il faut créer un nouveau point de contrôle correspondant au nouveau type de source de données. Pour le point de contrôle mode pull, lorsqu une nouvelle source de données est créée, il faut le modifier pour qu il puisse accepter de nouvelles commandes, et invoquer les actions correspondantes. Du côté des devices, la création d'un device UPnP peut être généralisée, car l'architecture d'un device UPnP est fixe, il suffit de modifier les propriétés et les actions pour s'adapter à chaque dispositif physique, le développement est rapide. 5.4 Remarques sur Felix Felix a quelques problèmes de stabilité, notamment avec le bundle UPnP BaseDriver. Quelques fois, lorsqu un device quitte le réseau, tous les devices sont supprimés des tables de point de contrôle (problème identique avec une application de test qui a le même rôle qu un point de contrôle mais avec une interface graphique). Si on redémarre le point de contrôle, Felix indique «bundle activator start error». Il faut redémarrer Felix pour retrouver le fonctionnement normal. Felix indique des exceptions réseaux lors de l ajout des devices distants, de plus, le temps pour que les devices soient détectés par le control point est assez important, comme présenté dans la partie de test. 29

30 Annexe Annexe I : Installation et configuration des outils de développement (Pour redéfinir le prompt de l'invite de commande: Démarrer>Exécuter>regidit>HKEY_CURRENT_USER>Software>Microsoft>Command Processor Dans la fenêtre à droit, cliquer droit n'import d'où, Nouveau>Valeur chaîne, donner lui un nom comme autorun par exemple, double cliquer dessus, dans «Donnée de la valeur», taper cd chemin_du_rep_où_on_souhaite_commencer_par_défaut.) 1. Installation de Maven Maven est un outil pour compiler et fabriquer des bundles pour Felix. Décompresser le maven bin.zip. Maven a besoin un repository local, qui est un dossier.m2, il faut décompresser m2.zip dans C:\Documents and Settings\rep-du-user. Pour créer un bundle, il faut écrire les classes java, ensuite écrire le fichier pom.xml (équivalent de build.xml) pour lui donner des dépendances pour la compilation. Pour exécuter la compilation, se placer dans le dossier racine de l'application Java, et taper: mvn compile Une fois réussi, pour fabriquer le bundle, se placer dans le dossier racine de l'application Java, et taper: mvn install 3. Installation et configuration de Felix Felix est une implémentation de OSGi, qui offre un cadre(framework) OSGi et les services. Pour lancer Felix, nous pouvons mettre des commande ci-dessous dans un fichier «runfelix.bat»: set FELIX=chemin_vers_dossier d'installation_felix cd FELIX\main java -jar bin/felix.jar cd.. 30

31 Il faut placer ce fichier au-dessus du dossier d'installation de Felix. Une fois lancé, Felix demande d'entrer un nom pour crée un profile, et installer des bundles pour ce profile. Dans notre projet, les bundles nécessaires qui doivent être installé sont: javax.servlet incubator-snapshot.jar org.apache.felix.upnp.basedriver incubator-snapshot.jar org.apache.felix.upnp.extra incubator-snapshot.jar org.osgi.compendium incubator-snapshot.jar org.apache.felix.log incubator-snapshot.jar com.dalsemi.onewire-1.10.jar org.apache.felix.http.jetty incubator-snapshot.jar org.osgi.core incubator-snapshot.jar org.osgi.foundation incubator-snapshot.jar smackbundle.jar (seulement installé mais non lancé) Après avoir créé un profile, la commande pour installer des bundles est: install file:chemin_absolu_où_se_trouve_le_bundle Une fois installation terminé, la commande ps permet de lister tous les bundle installés pour ce profile. Chaque bundle est identifié par un numéro. Pour les activer, il faut taper: - start N de bundle Pour mettre à jour un bundle après une modification, il faut taper update N de bundle. Pour les stopper, stop N de bundle Pour avoir de l'information sur un bundle, taper: headers N de bundle Note: Pour pouvoir utiliser les librairies supplémentaires JMF, il faut ajouter les packages dans le fichier de configuration qui se trouve dans felix\main\conf. Attention à la version de JRE du système, il faut les ajouter dans la bonne section qui correspond au JRE installé. 31

32 3. Installation de capteur de température Dallas Décompresser le Dallas Semiconductor.zip dans C:\ Programme Files. Brancher le capteur sur un port USB valide, installer le driver install_1_wire_drivers_v400.msi, laisser installateur détecter automatiquement le capteur. Décompresser le owapi_1_10.zip, il contient des API pour java. 4. Les variables d'environnement Une fois que nous avons installé tous les outils, il faut modifier et créer quelques variables d'environnement. (Propriétés du poste de travail, onglet Avancé > Variables d'environnement> Variables système) Ajouter le chemin vers l'installation de Maven (ex:..\maven-2.0.5\bin) dans la variable path. Créer la variable JAVA_HOME si elle n'existe pas, avec la valeur C:\Programme Files\Java\jdk1.5.0_06 Créer la variable FELIX, lui donner le chemin où se trouve le dossier d'installation de Felix. Créer la variable JMFHOME, lui donner le chemin vers le dossier JMF Ajouter les chemins vers Smack et JMF dans CLASSPATH Redémarrer la machine... Notes sur la création des devices UpnP: Ajouter tous les librairies supplémentaires Java (ex: smack, JMF) dans la section<import- Package> </Import-Package> du fichier pom.xml, sinon, erreurs de compilation. Pour installer les librairies supplémentaires dans Maven, utiliser la commande: mvn install:install-file -DgroupeId= nom_du_groupid -DartifactId=nom_du_artifactId - Dversion=version_du_jar -Dpackaging=jar -Dfile=/path/to/file 32

33 Annexe II : Diagramme de classes du device virtuel 33

34 Annexe III : Diagrammes de classes du point de contrôle mode push 34

35 Annexe IV : Diagrammes de classes du point de contrôle mode pull 35

36 Annexe V : Contenue de l archive finale L archive finale du projet contient huit applications JAVA, un répertoire qui contient des fichiers de propriétés des devices et un répertoire qui contient tous les outils nécessaires pour développer et lancer des applications UPnP. - TemperatureSensor: le device UPnP qui représente le capteur de température Dallas Onewire DS Camera: le device UPnP qui représente la camera IP. - WebCam: le device UPnP qui représente la webcam Logitech. - VirtualDevice_v1: le device virtual qui génère que la température aléatoire, il simule un capteur de température. - VirtualDevice_v2: le device virtuel qui offre l action «SendMessage» en plus de la génération de température aléatoire, il écrit dans un fichier de log l adresse du destinataire et le contenue du message. - VirtualDevice_v3: le device virtuel qui offre l action «SendMessage» en plus de la génération de température aléatoire, il envoie un message au destinataire. - controlpoint_pull_mode: point de contrôle mode pull. Il découvre/supprime les devices UPnP dynamiquement, accepte multi-connexions clientes simultanément, et invoque différentes actions selon les commandes reçues. - controlpoint_push_mode: point de contrôle mode push. Il découvre/supprime les devices UPnP dynamiquement, crée et envoie un flux de données au SoCQ. - tools: répertoire contient tous les outils nécessaires pour développer et lancer des applications UPnP, ainsi qu une documentation pour les installer et configurer. - deviceproperties: un répertoire contient des fichiers de propriétés des devices. 36