Rapport de projet Contrôle et transmission d'images dans un réseau de capteurs autonomes en énergie Du 06/01/2014 au 24/01/2014 Equipe CHABERT Audric CHIARAMELLO Julien GERMAIN Edouard TEFFAHA Morthada AUGUIN Michel Encadreurs AFFES Hend PEGATOQUET Alain 1/13
Sommaire Présentation du projet 1) Le sujet 2) Historique rapide 3) L implémentation Présentation du réseau de capteurs L application back-end 2) Fonctionnalités 3) Implémentation Le webservice 2) Fonctionnalités 3) Implémentation Affichage - Le site Web 2) Langages utilisées 3) Page HTML 4) Design CSS 5) Vérification de l intégrité via XSD 6) Transformation XSL Affichage : L application Android 2) Fonctionnalités 3) Implémentation Bilan du projet 1) Diagrammes de Gantt 2) Problèmes rencontrés 3) Erreurs commises 4) Améliorations possibles Glossaire 2/13
Présentation du projet 1) Le sujet Le laboratoire LEAT (Laboratoire d'electronique, Antennes et Télécommunications) est un laboratoire de l Université Nice-Sophia Antipolis disposant d un réseau de capteurs pouvant mesurer et transmettre des informations. Ces capteurs ont été conçus pour fonctionner avec un minimum d énergie et sont reliés à des sources d énergie renouvelables (Panneau solaire, éolienne, etc). Ces capteurs doivent remplir le critère d autonomie, il doit gérer au mieux son énergie en fonction des variations de l énergie disponible. Il dispose pour cela d un algorithme qui vise au plus juste l équilibre énergétique. L objectif du projet est dans un premier temps d étendre la portée de ces données afin d être accessible de l extérieur, notamment depuis un portable ou une tablette tournant sous Android. La deuxième partie consistait à tout d abord étudier l ajout d une caméra sur un des capteurs, puis si possible (Selon les résultats de l étude théorique) de l implémenter et de récupérer les résultats. Enfin, une gestion du power management sera envisagée. 2) Historique rapide Ce projet reprend la suite des travaux de thèse de Trong Nhan Le. Son projet consistait a faire communiquer les noeuds du réseau de capteurs pour obtenir les données reçues sur une interface en C#. Son cahier des charges imposait de répondre aux contraintes d équilibre énergétique des noeuds, de sorte à ce que ceux-çi puissent envoyer le plus régulièrement et efficacement leurs données. Cet étudiant à par ailleurs simulé le comportement du protocole MAC particulier utilisé ici, RICER, dans le framework omnet. Le développement de cette application répond au besoin des tuteurs d avoir une plateforme stable pour effectuer ces mesures en continu. Certaines de ces données serviront à améliorer la façon dont le réseau fonctionne, en repérant les variations de comportement au cours de la journée. Les données capturés par les capteurs serviront eux à créer des profils de variation journaliers, pour permettre une simulation plus fine du réseau dans le simulateur. 3/13
Figure 1 : schéma explicatif de l architecture des capteurs autonomes 3) L implémentation Afin de mener ce projet à bien, nous avons séparé le travail en quatre applications distinctes : L application Android écrite en Java chargée de récupérer les informations d afficher les informations en utilisant une interface intuitive et agissant comme un tableau de bord Le webservice écrit en PHP qui est chargé de recevoir et stocker dans une base de données les données transitant entre les capteurs et de les transmettre aux smartphones et tablettes connectés Le site Web écrit en HTML et utilisant du XSL agissant comme une interface à l instar de l application Android L application back-end écrite en C# qui a pour objectif d afficher en temps réel les informations récupérées des capteurs puis de les transmettre au webservice. Présentation du réseau de capteurs Les capteurs (L un d entre eux est représenté ci contre) sont des entités pouvant mesurer des données puis les envoyer via antenne. Ils sont alimentés par un petit condensateur se chargeant grâce à une source d énergie branchée au capteur - panneau solaire, éolienne, etc. L envoi est cependant extrêmement gourmand en énergie, c est pourquoi un capteur ne peut envoyer en continu. Les capteurs ont donc une stratégie d envoi : Dès qu ils ont assez d énergie, ils se réveillent. Afin de se synchroniser, ils 4/13
n envoient pas immédiatement leur données - ils se mettent en attente. La station de base envoie régulièrement un signal appelé beacon - 20 par seconde par défaut. A la réception de ce signal, le capteur envoie ses informations puis se rendort. Le protocole est défini pour limiter au maximum le temps d écoute du support, pour diminuer le plus possible la consommation énergétique Afin de réguler leurs envois, les capteurs possèdent chacun une période de réveil de 1 à 10 secondes. Cette période est dynamique : Si un capteur n a pas assez d énergie pour envoyer des informations à chaque période, celle ci s allongera; A l inverse, si le capteur dispose d une quantité importante d énergie, il programmera sa prochaine période de réveil un peu plus tôt. De cette manière on obtient un algorithme qui s adapte en permanence aux changements de l environnement. L application back-end Cette application sera la partie qui fera le pont entre le réseau de capteurs et le reste de l architecture logicielle. L ordinateur qui la fera tourner sera connecté au noeud central qui initie et prend en charge la réception des trames provenant des autres noeuds. Cette application doit écouter le port COM, émulé ici en USB, qui relie ce noeud central. 2) Fonctionnalités Cette application importante car elle constitue le point d entrée des informations provenant du système autonome. Elle doit dans un premier temps se connecter correctement avec le noeud central et réceptionner les informations arrivant à elle. Avant de transmettre au service web, elle doit convertir et surtout vérifier les informations qu elle traite, le réseau n offrant aucune qualité de service à ce sujet. Pour simplifier le développement et l utilisation de l architecture, elle permettra aussi d afficher les informations reçues. Un dernier point est que c est cette application qui va vérifier les données en provenance du réseau de capteurs, agissant comme un vérificateur. 3) Implémentation Nous avons dans un premier temps repris l application codée par l ancien étudiant, pour comprendre ce qui avait été fait précédemment. Il nous a fallu une période d adaptation pour se familiariser avec l environnement de développement. Ensuite, nous avons entièrement recodé l application dans cet environnement. Certaines fonctionnalités ont étés ajoutés, entre autres la différenciation des données provenant de capteurs différents. La plus importante est la prise en compte des trames corrompues, qui permet d avoir un bon ordre d idée sur le nombre d erreurs qui surviennent pendant les transmissions. 5/13
L application back-end doit pouvoir communiquer avec le reste de l architecture pour envoyer ses données. Elle est donc le point d entrée de toute l architecture définie par notre équipe. Une contrainte est d être suffisamment modulaire pour que plusieurs applications puissent fonctionner en parallèle, innovation majeure comparée au projet précédent. Un travail conséquent a été réaliser pour simplifier au maximum l ajout de nouveaux sites, lieux qui font fonctionner un réseau de capteurs. Le résultat est une plateforme souple, qui permettrai dans l avenir d avoir un nombre de sites important. Le webservice Le webservice a été conçu comme le point central de l application. Toutes les données en provenance de l application back-end passent par celui-çi. C est aussi celui-çi qui transfert l application vers tous les services dits clients, le site web et l application mobile. Son bon fonctionnement est crucial, et un soin tout particulier a été apporté à sa modularité. 2) Fonctionnalités Ce service doit recevoir correctement les informations capteurs provenant d un ou de plusieurs sites. Ces donnés sont ensuite stockés dans sa base de données, qui sera donc centralisée, pour faciliter l ajout de futures fonctionnalités. Le webservice sers de passerelle unique pour tous les programmes qui vont consommer les données, Il possède une interface vers le site web ainsi qu une interface pour la communication android. Cette application doit pouvoir être mise à l échelle facilement, en utilisant des technologies largement répendues, comme PHP 3) Implémentation L implémentation du web service s est fait en utilisant une méthode REST, en utilisant la technologie PHP. Le service web a comme contraintes qu il doit forcément être hébergé pour fonctionner. Il permet néanmoins d offrir une plateforme stable pour l utilisation en continu Affichage - Le site Web 6/13
L objectif du site web est double : il sert à la fois à présenter le projet dans une page dédiée et à afficher les données des différents sites connectés ainsi qu une démonstration permettant d avoir un visuel même en l absence de station qui fonctionne. 2) Langages utilisées Le site web a été réalisé grâce à deux langages dans un premier temps, pour pouvoir définir tous les éléments à visualiser et créer un prototype : - HTML : ce langage sert à concevoir une page web de manière rustique - CSS : celui-ci permet de mettre en page, faire des améliorations graphiques, ajouter des effets aux différentes pages web en définissant des règles pour chaque balise. Dans un soucis de lisibilité, nous avons utilisé des balises <div> avec un attribut classe explicite pour faire plus facilement le lien entre le CSS et le HTML. Le site web est divisé en deux parties majeures : le menu et le corps de la page. Le premier est un élément dynamique qui ne diffère pas selon les pages mais qui comportent des données fluctuantes selon les sites connectés ou non. Le corps du message, mis à part pour la présentation du projet, est une partie qui ne comporte que des valeurs évoluant selon les informations réceptionnées par les capteurs. Cette contrainte nous impose de concevoir un site qui ne soit pas statique. Pour satisfaire cela, nous avons de générer de la partie HTML de manière dynamique à l aide des langages suivants : - XML : permet d enregistrer des données d une façon structurée - XSD : vérifie l intégrité du fichier XML - XSLT : contient des règles pour un fichier XML, permettant de transformer ce dernier en fichier HTML. Le web service enregistre donc périodiquement les données sous la forme de fichier XML, puis elles sont validées et transformées grâce aux documents XSD et XSLT prédéfinis. 3) Page HTML Cette partie contient le contenu, le fond de la page web. Il faut, en effet définir ici : les menus, les liens, les tableaux, les graphiques. Cela ne sera pas mis en forme. Pour effectuer la mise en page, il faut faire appel à notre feuille de style CSS. 4) Design CSS Conformément aux proportions que nous avons choisis dans le CSS, les éléments du site sont répartis de la manière suivante : 7/13
Figure 3 : disposition des éléments du site web Le menu est dynamique. En premier lieu, il n affiche que les liens vers les différentes pages du site à savoir la présentation du projet, une démonstration et trois «sites». Puis, la définition d une propriété dans le CSS (hover) nous offre la possibilité de consulter les informations générales de la page ciblée par le lien survolé par la souris de l utilisateur. Cette utilisation du CSS permet de ne pas surcharger le site d informations qui ne sont pas toujours utiles. Force du signal d un capteur : pour visualiser la force du signal, nous avons utilisé une barre qui se remplit en fonction de la-dite force. Concrêtement, ce sont deux rectangles dont l un est un peu plus petit et qui varie selon la valeur à afficher. Nous affichons également un historique des valeurs de température prise par les capteurs sur un graphique. 5) Vérification de l intégrité via XSD Le fichier XML généré par le web service doit être vérifié par un schéma XSD. Celui-ci est une description de document de type XML qui permet de définir la structure attendue. Si ledit fichier respecte les règles définies, il est alors déclaré comme valide. Cette étape n a pas d impact sur le rendu visuel, c est seulement une vérification. 6) Transformation XSL Le fichier XML est transformé grâce à un fichier XSL et le logiciel XSLApplyer qui comme son nom l indique permet d appliquer une feuille de style XSL au fichier de donnée concerné. 8/13
Dans ce fichier, on va récupérer les informations d un noeud XML et les traiter. Par, exemple pour le menu, on parcourt l ensemble du fichier et on affiche tous les sites en supprimant les doublons. On calcule également la température moyenne en faisant la somme de la dernière valeur de tous les capteurs en la divisant par le nombre de capteur. Toutes les informations affichées sur le site web sont en fait sélectionnées/traitées à partir du XML grâce aux différents fichiers XSL (un fichier XSL par page HTML). Affichage : L application Android L application android est la fonctionnalité la plus attendue du point de vue client. Son aspect et la facilité d utilisation sont un point crucial pour une bonne expérience utilisateur. 2) Fonctionnalités L accès aux différents menu se fait de manière intuitive, en utilisant un menu (Navigation Drawer) l utilisateur selectionne le site ainsi que le station concerné. une fois la station selectionner l'utilisateur se voit présenté les capteur existant avec deux gauge circulaire, une pour la temperature et une autre pour la charge. 3) Implémentation L implémentation de cette application s est fait avec la SDK Android 4.4 (API 19 ou kit kat) avec un support antérieur à partir de la version de l api 10 (Gingerbread). l application est majoritairement codé en fragment ce qui la rend plus modulaire et sur tout bien adapté à une utilisation en tablet. 9/13
Bilan du projet 1) Diagrammes de Gantt Ci-dessous le diagramme de Gantt prévisionnel Figure 4 : Diagramme de gantt prévisionnel Voici ensuite le diagramme effectif Figure 5 : Diagramme de gantt effectif 2) Problèmes rencontrés La caméra, qui était censée être le fer de lance de notre projet, n a au final pas pu être implémentée. Les caméras compatibles avec les capteurs étaient en effet en rupture de stock, ce qui nous a pris de court. Nous avons donc décidé d utiliser ce temps pour peaufiner le projet en ajoutant des fonctions non prévues à la base, comme par exemple un historique des informations des capteurs. Cependant, l étude énergétique théorique a été conduite, ce qui facilitera la tâche pour nos éventuels successeurs. Notre premier rendez-vous avec les encadreurs n a eu lieu que le vendredi de la première semaine, ce qui nous a empêché de profiter pleinement cette semaine puisque les éléments contenus dans le sujet originaux ne nous permettaient pas de commencer à travailler sur le projet en lui même. Notre temps n a pas été perdu pour autant, il nous 10/13
a permis de nous initier à la programmation sous android dans de bonnes conditions. Il ne faut pas oublier la gestion de projet, comme la rédaction du diagramme de Gantt prévisionnel, qui nous a permis de planifier plus efficacement la répartition du travail dans la durée du projet. Plusieurs problèmes d ordre logiciel ont eu lieu durant le projet, notamment liés à git et au certificat invalide de Stash, ainsi que des crashes sur certaines machines. L utilisation de certains GUI pour git et une modification de la répartition des tâches a pallié au problème. 3) Points négatifs concernant le déroulement du projet La communication demeure le point sur lequel nous avons le plus péché. En effet, la structure du projet est telle que certains services dépendent d autres - par exemple, l application Android n est qu une maquette sans le webservice. Nos moyens de communication ayant souvent des problèmes (Téléphone capricieux, réseau encombré, etc), cela a retardé l implémentation de certaines fonctionnalités qui nécessitaient une base. Notre utilisation du JIRA et de Stash n a pas été des plus exemplaires, notamment avec Kanban : Beaucoup de tickets ont été dans En cours trop longtemps ou pas assez (Voir jamais pour certains). Elle est entre autre dûe a la trop grande spécialisation des membres dans un domaine du projet. 4) Améliorations possibles de l architecture logicielle L implémentation de la caméra reste en suspens, cependant le code a été conçu de façon modulaire ce qui devrait permettre de l ajout aux applications sans trop de difficultés (Le point le plus difficile restera l ajout de la caméra sur les cartes, puisqu elle pose des contraintes importantes en termes de consommation d énergie) A l instar du wi-fi, des corruptions de paquet sont possibles. De plus, aucune correction ni détection d erreur n est prévue. Puisque la force du signal est calculée par la station de base, on peut récupérer un paquet corrompu et y accoler la distance du capteur. Il serait ainsi intéressant d étudier la relation entre la distance et le taux de paquets corrompus afin d établir des distances capteur/station conseillées par exemple, ou de vérifier qu un paquet corrompu correspond à un signal de faible intensité. Les paquets envoyés par la station de base sont actuellement incroyablement lourds pour les informations qu elles contiennent.: Toutes les informations sont envoyées sur 4 octets alors qu un seul suffirait pour la plupart (La température par exemple). Du point de vue power management, cela apporterai un gain non négligeable sur la puissance utilisée lors des transmissions. Supprimer les bits inutiles permettraient aussi de libérer de la place pour d autres informations. Cela permettrait par d implémenter la caméra sans dépasser la taille des paquets conseillée (voir étude théorique énergétique ) - uniquement le protocole - ce qui est très intéressant. 11/13
La station de base n envoie pour l instant que des paquets quand elle en reçoit, elle ne fait que répéter, comme le ferai un hub en réseau, les informations reçues. Il serait intéressant qu elle envoie en continu des informations utiles qui permettraient, par exemple, de vérifier son bon fonctionnement.il serait ainsi plus simple de différencier un silence radio dû à une activité réduite des capteurs d un dû à une connexion rompue. Il serait alors possible de tester les capteurs indépendament du reste. 12/13
Glossaire XML : extensible Markup language - Langage de document utilisant un système de balises, considéré comme universel. HTML : HyperText Markup Language - Langage de document proche du XML utilisé pour la création de sites web. CSS : Cascading StyleSheets - Langage de règles permettant de mettre en forme un document XML ou HTML. XSD : XML Schema Definition - Langage de règles permettant une validation de formats selon des règles définies. XSL : extensible Stylesheet Language - Langage de règles permettant de transformer un document XML en autre document quelconque. RICER : Receiver Initiated CyclEd Receiver - Nom de la stratégie de synchronisation utilisée par les capteurs GUI : Graphical User Interface - Une application offrant une interface pour un logiciel existant souvent en ligne de commandes afin de gagner en efficacité et en esthétique JIRA : Système de tickets permettant de traquer les tâches, bugs, fonctionnalités du programme à implémenter. Stash : Distribution git en ligne contenant le code courant ainsi que son histoire 13/13