Réalisation d'un système de supervision de réseaux de capteurs sans fil.

Transcription

1 Institut Supérieur d'informatique de Modélisation et de leurs Applications Cemagref Clermont-Ferrand Unité Technologies et Systèmes d'information pour les Agrosystèmes Complexe des Cézeaux BP Aubière Cedex Complexe des Cézeaux 24,avenue des Landais BP Aubière Cedex ème stage de 2 Rapport d'ingénieur année Filière Réseaux et Télécommunications Réalisation d'un système de supervision de réseaux de capteurs sans fil. Présenté par : Responsable ISIMA : Christophe Tilmant Responsable entreprise : Aurélien Jacquot Date : 6 avril 2009 Durée du stage : 5 mois

2 Remerciements Je tiens tout d'abord à remercier l'ensemble du personnel du Cemagref pour sa convivialité et l'accueil au sein de l'établissement. Je remercie aussi mes encadrants Aurélien Jacquot et Jean-Pierre Chanet pour avoir permis la réalisation de ce projet et plus particulièrement Aurélien Jacquot pour son soutien et sa disponibilité tout au long de ce projet..

3 Table des figures et illustrations Illustration 1: Plateforme LiveNode...3 Illustration 2: Architecture du système LiveNCM...4 Illustration 3: Schéma simplifié de l'organisation de la MIB...7 Illustration 4: Exemple de déclaration d'un nœud de la MIB en ASN1...9 Illustration 5: Principe de fonctionnement d'un estimateur...10 Illustration 6: Principe du fonctionnement de PHP/HTML...11 Illustration 7: Exemple d'objet au format JSON...12 Illustration 8: Utilisation de Google Maps dans l'ancienne interface...13 Illustration 9: Exemple de traitement de l'interface [GARNIER et SABALSKI 2008]...14 Illustration 10: Interface de géo localisation des LiveNodes [GARNIER et SABALSKI 2008]...15 Illustration 11: Schéma de principe de l'utilisation d'une table dans la MIB...16 Illustration 12: Schéma simplifié de la structure adoptée pour la MIB...17 Illustration 13: Diagramme de classes UML du module row_container...19 Illustration 14: Création d'un nouveau réseau...22 Illustration 15: Notification de nouveau nœud...23 Illustration 16: Exemple de document XML...26 Illustration 17: première version de l'algorithme de sauvegarde...27 Illustration 18: Organisation de l'interface...32 Illustration 19: Panel de l'historique des capteurs...34 Illustration 20: Extrait d'un fichier de tests...36 Illustration 21: Résultat de l'exécution du scénario précédent (voir illustration 20)...36

4 Résumé Dans le cadre de ses projets, le Cemagref travaille à la conception d'un système de réseau de capteurs sans fil. C'est au sein de ce projet qu'est développé le système LiveNCM sur lequel j'ai fait mon stage. Ce système a pour but de superviser à distance les différents éléments des réseaux de capteurs sans fil, de permettre de visualiser et modifier leurs configurations ainsi que d'accéder aux différentes valeurs des capteurs. Dans cette optique, j'ai conçu un sous-agent SNMP dont le but est de centraliser les données des différents éléments de ces réseaux de capteurs sans fil. Ce programme est capable de gérer l'ensemble des requêtes nécessaire à la supervision de ces éléments ainsi qu'à l'accès aux différents paramètres et données du système. En complément à ce système, une interface web a été ajoutée permettant à l'utilisateur d'exploiter les réseaux de capteurs sans fil plus simplement via les requêtes du sous-agent. Mots clefs : SNMP, C, Supervision réseau, technologies web, réseaux sans fil. Abstract As a part of its projects, the Cemagref is working on Wireless Sensor Networks. In this project was developed the LiveNCM system on which I have done my placement. The goal of this system is to provide remote supervision for all items of a Wireless Sensor Network and to allow configurations lookup and modification. It also needs to provide access for all various sensor values. In this way, I have designed an SNMP sub-agent used to centralize data for all items inside of these WSNs. This software is able to manage all requests used for the supervision of theses items and for the access to all system's parameters. As a second part of this project, a web interface was added in order to provide an easier use of Wireless Sensor Network with the sub-agent requests. Key-words : SNMP, C, Network Supervision, web technologies, wireless network

5 Table des matières Remerciements Résumé Abstract I Introduction...1 II Sujet de l'étude...2 II.1 Cadre du projet Le Cemagref Le système LiveNCM...2 II.2 Le but du stage...4 II.3 L'existant...5 III Analyse du problème...6 III.1 Le protocole SNMP...6 MIB...6 Agent...8 Capacités d'extension...8 III.2 Les spécificités de LiveNCM [JACQUOT, et al.2008]...9 III.3 L'interface Les technologies de l'interface...10 PHP/HTML...11 JavaScript et AJAX...11 JSON...12 L'API Google Maps Architecture de l'interface [GARNIER et SABALSKI 2008]...13 IV Étude d'une solution...16 IV.1 Étude du système de contrôle Définition de la MIB Gestion des données de l'agent[net SNMP]...18 Structure de données Communication avec l'agent...20 Manipulation des données...20 Protocole de communication...21 Type de connexions Persistance des données...25 Sauvegarde au format XML...26 Optimisation du code du module sauvegarde...27 IV.2 Conception de l'interface Adaptation au modèle...29 Communication...29 Historique...30 Importation des données Extension de l'interface...31 Gestion des informations...31

6 Filtrage des données...33 Gestion de l'historique...33 IV.3 Protocole de test Tests des modules Test de l'application...37 V Discussion Déroulement du projet Résultats...38 VI Conclusion...40 Glossaire/Lexique Références Bibliographiques Annexes

7 I Introduction Dans le cadre de ses projets, le Cemagref développe en collaboration avec le LIMOS un système de supervision destiné aux réseaux de capteurs sans fil (RCSF) appelé LiveNCM. Ce système est basé sur le protocole SNMP utilisé couramment sur les réseau filaires. Le développement d'un tel outil doit faire face à de nombreuses contraintes. Ces difficultés sont principalement dues à l'adaptation du protocole à un milieu ayant des ressources limitées et subissant des contraintes de communication importantes. C'est dans ce contexte qu'il m a été demandé de réaliser une partie d'un système de supervision, capable d'accéder et de modifier différents paramètres d'un nœud à travers le protocole SNMP. Cette partie va principalement passer par la réalisation d'un programme centralisant les données et les commandes de l'ensemble des RCSFs. En parallèle, j'ai travaillé sur une interface capable de contrôler ce système de supervision à distance. Cette interface se basera sur un système de géo-localisation existant développé par des élevés de l'isima. Ce stage a tout d'abord nécessité l'assimilation des concepts utilisés au sein du système LiveNCM afin de pouvoir repérer les différentes contraintes de ce modèle. Cette phase d'analyse des contraintes doit se prolonger ensuite afin de comprendre les modifications à apporter à l'interface pour atteindre le nouveau cahier des charges. Une fois les spécificités du problème connues, j'ai étudié et conçu les divers modules nécessaires à la réalisation du système de supervision et de l'interface. L'ensemble de ces parties est accompagné de tests du système afin de garantir le meilleur fonctionnement possible du programme. Page 1/40

8 II Sujet de l'étude II.1 Cadre du projet 1 Le Cemagref Le Cemagref est un organisme publique de recherche créé dans les années 60 pour des thématiques orientées vers le machinisme agricole, le génie rural et les eaux et forets. Ces sujets ont peu à peu évoluées vers la gestion des ressources naturelles, l'aménagement du territoire et la gestion des risques environnementaux. On retrouve notamment des thématiques autour de l'eau et des systèmes écologiques. Le Cemagref est composé d'une dizaine de centres répartis à travers toute la France. C'est au sein du groupement de Clermont-Ferrand que j'ai effectué mon stage. Ce groupement est implanté sur le campus des Cézeaux et dispose d'une exploitation agricole à Montoldre (03) utilisée pour les expérimentations. J'ai plus particulièrement travaillé au sein de l'unité «Technologies et Systèmes d'information pour les agrosystèmes de Clermont-Ferrand» (TSCF). Cette unité regroupe des chercheurs de disciplines variées tels que l'automatique, l'électronique, le génie des procédés et l'informatique. Les sujets de recherches au sein de TSCF sont orientés vers la mobilité pour la sécurité et la qualité du travail des machines, les technologies d épandage de matériaux organiques ou minéraux, les technologies pour la perception et la caractérisation du sol ainsi que les systèmes d information et de communication partagés. C'est dans cette dernière thématique que j'ai travaillé au sein de l'équipe COPAIN chargée de traiter les données depuis la collecte des mesures jusqu'au stockage dans les bases de données en passant par le développement de systèmes d'informations. Durant la totalité de mon stage, j'ai plus particulièrement travaillé en collaboration avec Aurélien Jacquot à la mise au point du système nommé LiveNCM («Livenode Non invasive Context aware and Modular management»). 2 Le système LiveNCM L'unité TSCF travaille actuellement en collaboration avec le Laboratoire d 'Informatique de Modélisation et d'optimisation des Systèmes (LIMOS) de Clermont-Ferrand à la conception d'un système d'administration de réseau de Page 2/40

9 capteurs sans fil. Un réseau de capteurs sans fil est composé d'un ensemble de nœuds, répartis sur un même site, sur lesquels sont embarqués des capteurs. Ces nœuds sont reliés entre eux grâce à des protocoles de communication sans fil du type Zigbee, WiFi, ou GSM. Chaque réseau contient une passerelle vers l'extérieur, par laquelle il est possible d'accéder à toutes les valeurs des capteurs et d'avoir ainsi un ensemble de données représentatives du site à un moment donné. Dans le cadre du projet du Cemagref, les nœuds seront des modules LiveNode qui ont été développés par le LIMOS (illustration 1). Afin d'avoir la meilleure autonomie possible, ces Livenodes sont composés des équipements minimums nécessaires à la remonté des informations issues des capteurs. On retrouve principalement un processeur, des modules de communication sans fil ainsi que des interfaces pour les capteurs. Illustration 1: Plateforme LiveNode Lors de l'utilisation de ces plateformes, les nœuds seront généralement éloignés de plusieurs dizaines voir centaines de mètres afin de pouvoir couvrir une zone de mesure importante. Dans le but de valider ce fonctionnement, le système sera testé avec des capteurs d'humidité répartis sur la surface d'un champ. C'est dans le cadre de ce projet que le Cemagref développe un système d'administration permettant de diminuer le trafic réseau et d'augmenter l'autonomie des LiveNodes. Ce système, appelé «LiveNode Non invasive Contextaware, and modular Management» (LiveNCM) est basé sur le protocole SNMP et demande, entre autres, un système de contrôle centralisé pour les réseaux de capteurs sans fil (illustration 2). Le système LiveNCM doit permettre à terme de consulter les données capteurs, de surveiller les équipements (LiveNodes/Capteurs/passerelle) à travers Page 3/40

10 divers indices (Batterie, Puissance d'émission...) mais aussi d'intervenir sur certains paramètres (Fréquence d'acquisition, Canal d'émission ). L'ensemble de ces opérations doit pouvoir être réalisé sans forcément se trouver sur le site du réseau concerné. Interface D'administration à Distance Commandes d'administration Données Capteurs / État du système Système de contrôle Passerelle Passerelle LiveNode LiveNode LiveNode LiveNode Capteur Capteurs LiveNode LiveNode Capteur Capteurs Illustration 2: Architecture du système LiveNCM Le développement de ce projet doit en plus répondre à des contraintes fortes en matière d'utilisation des ressources (Batterie, processeur, mémoire). Ces contraintes sont principalement dues à l'utilisation de matériel embarqué avec des puissances de calcul et des ressources limitées. II.2 Le but du stage C'est au niveau de ce système LiveNCM que s'effectue mon stage. Il m'a tout d'abord été demandé de réaliser la partie du système de supervision chargée de communiquer avec les passerelles et avec l'utilisateur. Cela passe principalement par la conception d'un gestionnaire qui centralisera les données issues des passerelles et transmettra les requêtes d'administration aux différents nœuds des Page 4/40

11 RCSFs. La seconde partie du projet correspond à la réalisation d'une interface de visualisation des données issues du système de supervision. L'interface doit permettre en particulier de récupérer des données sur l'état des nœuds et de pouvoir observer les variations des valeurs des capteurs à travers un système d'historiques. Cet outil doit aussi intégrer les commandes d'administration qui devront permettre en particulier le changement de la configuration des capteurs. L'ensemble des opérations de consultation des données et de modification de la configuration doit aussi pouvoir être réalisé à distance le plus simplement possible. II.3 L'existant Lors de mon arrivé, il existait déjà une ébauche de programme de supervision des RCSFs centralisant les données des différents nœuds. Cependant, ce programme a été réalisé dans le but de tester certains concepts liés au modèle LiveNCM. Le cahier des charges de cette première version était ainsi assez éloigné du but recherché, il n'y avait qu'un seul réseau avec un seul capteur par nœud, ce qui le rendait peu flexible. Néanmoins, cette version servira de base à la réalisation du projet en fournissant une première maquette de conception de la solution finale. Par contre, la refonte du programme pour atteindre le cahier des charges, tant au niveau des données que du système lui même, demanderait plus de temps que sa réécriture totale. Par ailleurs, le Cemagref disposait aussi d'une interface web de géolocalisation des LiveNodes développée lors d'un projet de 3éme année ISIMA [GARNIERet SABALSKI 2008]. Cette interface était destinée à repérer sur une carte les différents LiveNodes ainsi qu'à visualiser une donnée issue d'un capteur d'humidité branché sur le nœud. Ce projet a été conçu avec un cahier des charges proche de notre projet (accès à distance, fonctionnalités communes ) ce qui rend sa réutilisation intéressante. Il convient cependant de noter que dans le cadre de l'ancienne interface, on considère que les capteurs sont tous de même type et qu'un nœud embarque un unique capteur. Page 5/40

12 III Analyse du problème La première tâche à accomplir consiste à analyser l'architecture du système recherché et les différentes technologies à utiliser afin d'en comprendre leurs fonctionnements, leurs contraintes et leurs spécificités. Le système LiveNCM développé au Cemagref et au LIMOS propose une nouvelle solution d'administration à distance des nœuds d'un RCSF en se basant sur le protocole SNMP. III.1 Le protocole SNMP Le protocole SNMP («Simple Network Management Protocol») est un protocole de supervision très couramment utilisé dans les réseaux informatiques filaires. Ce protocole a pour but la surveillance et l'administration à distance des équipements réseaux. La liste des périphériques gérés par SNMP est particulièrement importante et permet l'administration d'équipements tels que des imprimantes, des routeurs ou des ordinateurs de bureau. La première version de SNMP apparue en 1990, pose de nombreux problèmes de sécurité qui ont conduit au développement d'une deuxième version en Malgré les améliorations apportées, cette deuxième version du protocole (nommée V2C) présente encore un certain nombre de lacunes qui ont nécessité la mise au point d'une troisième version, plus sure mais toutefois plus complexe à mettre en place. En dépit des risques, les applications utilisant SNMPv1 et SNMPV2c sont encore populaires, notamment grâce à la présence de nombreux outils existants. Le but de ce projet étant principalement de valider les principes de l'architecture LiveNCM à travers une «maquette», j'ai préféré utiliser SNMPv2c afin de simplifier le travail tout en possédant une application plus sure qu'avec la version un. MIB Chacun des paramètres d'un équipement est stocké dans une instance d'une structure de données arborescente appelée Management Information Base (MIB). Chaque branche de l'arborescence possède un identifiant numérique qui correspond à une catégorie particulière de matériel. Ces branches vont pouvoir se diviser en autant de sous-catégories qu'il peut être nécessaire pour un type d'équipement (par Page 6/40

13 exemple dans le cas d'un ordinateur, on peut trouver des catégories sur la mémoire, la carte réseau, le processeur ). Chacune de ces branches vont posséder à leurs extrémités des «feuilles» qui correspondent à des données décrivant l'équipement appelés ressources SNMP. Chacune de ces ressources est identifiée par un «Object IDentifier» (OID) qui est construit selon la séquence des numéros associés aux branches empruntées (voir illustration 3) Pc (1) Disque Dur (1) Capacité en Go (1) Utilisation en % (2) Carte Réseau (2) Adresse IP (1) Vitesse (2) Activé O/N (3) Imprimante(2) Exemple d' OID : Adresse Ip de la carte Réseau Pc(1).Carte Réseau(2).Adresse IP(1) => OID=1.2.1 Encre(1) Papier(2) Routeur (3) Illustration 3: Schéma simplifié de l'organisation de la MIB L'organisation de la MIB a fait l'objet de plusieurs RFC dans le but de la standardiser. On peut principalement citer les RFC 1066 en 1988 décrivant une première structure de la MIB [McCloghrie et Rose 1988] et la RFC 1213 en 1991 définissant la structure de l'arborescence de la MIB-II encore utilisée actuellement [McCloghrie et Rose 1991]. Les différentes ressources de la MIB seront accessibles via les requêtes suivantes : Get(OID) : retourne la valeur contenue dans l'oid correspondant (utilisable via la commande SNMPGET) Ex: SNMPGET(1.1.2) => 1.1.2:: 10% Page 7/40

14 Set(OID) valeur : met le contenu de l'oid à la valeur choisie (utilisable via la commande SNMPSET) Ex: SNMPGET(1.2.1) => 1.2.1:: SNMPSET(1.2.1, ) => 1.2.1:: SNMPGET(1.2.1) => 1.2.1:: Walk(OID): Affiche les valeurs des données d'une branche de la MIB (utilisable via la commande SNMPWALK) en réalisant plusieurs requêtes Get successives. Ex: SNMPWALK(1.1) => 1.1.1:: 300 GO 1.1.2:: 42% Agent La gestion de cette MIB est confiée à un programme de type démon appelé agent SNMP. A chaque agent sera associé une instance de la MIB qui contiendra les données de l'équipement managé. Cet agent va jouer un rôle central dans le protocole : - lorsqu'un utilisateur recherchera une information avec une requête Get, il s'adressera à l'agent qui retournera l'entrée de la MIB qui correspond à la requête. - en cas de modification de la configuration ou du statut d'un élément, l'agent détectera ce changement et modifiera la MIB afin qu'elle reflète le nouvel état de l'équipement managé. - enfin lorsque l'utilisateur décide de modifier un paramètre, il transmettra sa requête à l'agent qui modifiera la MIB et répercutera le changement sur l'équipement concerné. Capacités d'extension L'un des points forts de SNMP est qu'il est possible d'étendre les types équipements supervisés afin de pouvoir manager n'importe quel équipement possédant une carte réseau. Pour cela, il faut tout d'abord décrire la nouvelle branche de la MIB correspondant au nouveau matériel. Cette description va être faite au moyen d'un fichier utilisant la syntaxe ASN1 (voir exemple 4 ci dessous). Page 8/40

15 Nom de L' OID nodesdescid OBJECT TYPE SYNTAX INTEGER( ) MAX ACCESS read only STATUS current "node unique ID" ::= { nodesdesctableentry 1 } Type de données Accessibilité (lecture seule, lecture écriture... ) Champ Obsolète / champ obligatoire ou facultatif Descriptions / notes sur l' OID Branche mére + position dans cette branche Illustration 4: Exemple de déclaration d'un nœud de la MIB en ASN1 En plus de représenter la structure de la nouvelle branche de la MIB, le fichier indiquera aussi à quelle branche de la MIB-II «standard», on devra la greffer. Cette greffe se fait théoriquement dans la branche «private.enterprise» prévue à cet effet. Enfin, pour que cette extension de la MIB soit gérée correctement, on ajoutera un nouveau programme appelé sous-agent contenant les traitements à réaliser pour cette branche. Lorsque l'agent recevra une requête sur un OID qu'il ne sait pas gérer, il s'adressera au sous agent concerné pour la traiter. Les ressources limitées des RCSFs ne permettant pas d'embarquer un agent SNMP, il sera nécessaire de développer un sous agent adapté et une nouvelle branche de la MIB pour gérer les différents paramètres d'un nœud. III.2 Les spécificités de LiveNCM [JACQUOT, et al.2008] La nature des réseaux de LiveNodes présente un certain nombre de spécificités qui ont fortement influencé le modèle. La contrainte principale vient de l'utilisation des technologies employées sur les nœuds : les ressources disponibles étant limitées (en particulier les batteries), il faut diminuer au maximum les temps de calcul et d'envoi de données. L'utilisation d'un démon (qui fonctionne donc en permanence) sur un équipement implique l'utilisation de mémoire constante et des calculs réguliers. Ce type de programme ne peut donc pas être intégré sur des systèmes embarqués à cause de cette contrainte. Afin de résoudre ce problème, l'agent SNMP doit être déporté hors du LiveNode. Dans le modèle choisi, il n'existera qu'un seul agent gérant l'intégralité des RCSFs. Dans le but de décharger une partie du travail de l'agent, ce dernier s'adressera uniquement à des passerelles qui se chargeront de transmettre les requêtes aux LiveNodes et capteurs correspondants. Toujours afin d'économiser l'utilisation de ressources, les communications Page 9/40

16 seront limitées au strict minimum. Un système d'estimateurs a été mis en place pour n'émettre des données que lorsque celles-ci s'éloignent de la valeur estimée (voir illustration 5). Dans la même optique, les paramètres des éléments ne seront envoyés que lors de leurs initialisation ou suite à un changement. Illustration 5: Principe de fonctionnement d'un estimateur Avec ce système, les données des messages émis sont alors très courtes ce qui permet de profiter de place «libre» dans les trames pour ajouter quelques informations critiques (Niveau de batterie du nœud par exemple), permettant ainsi d'éviter quelques envois. III.3 L'interface Une contrainte importante à prendre en compte lors de la conception de l'interface est la possibilité d'utilisation à distance. L'adaptation de l'ancienne interface, réalisée avec des fonctionnalités proches des objectifs du projet, est particulièrement intéressante. 1 Les technologies de l'interface Ce précédent projet se base sur une interface web créée avec les technologies PHP/HTML, JavaScript et AJAX ainsi que l'api Google-Maps. Elle se présente sous la forme d'un site web hébergé par un serveur apache relié à Page 10/40

17 Internet. Grâce à cela, il est notamment possible d'utiliser l'interface à partir de tout ordinateur ayant accès à ce serveur. Le poste client peut fonctionner sous n'importe quel système d'exploitation et doit uniquement disposer d'un navigateur web «moderne» qui acceptera l'exécution de scripts JavaScript. PHP/HTML Le langage HTML est la base de nombreuses technologies Web. Il est composé de balises qui permettent de décrire l'affichage d'une page. Dans le cas le plus simple, un serveur Web (Apache, IIS, ) hébergera des fichiers HTML qui seront envoyés au navigateur web du client qui interprétera les balises afin de reconstruire la page. En complément à HTML, l'utilisation du langage PHP permet à un serveur de générer du code HTML dynamiquement en réponse à une requête d'un client (voir schéma 6). Ce langage est principalement utilisé pour gérer des formulaires ou interfacer des informations issues d'une base de donnée. Poste Client Poste serveur Internet / Réseau Local Navigateur Web Demande de page Web Serveur Web Transition de la requête Recherche de la page Exécution du script PHP (génération d'un flux HTML) Interprétation du HTML (génération de la page à l'écran) Réponse serveur Envoi du HTML Illustration 6: Principe du fonctionnement de PHP/HTML Le principal problème de ce système est que le navigateur se contente de restituer les pages via un flux HTML sans aucune possibilité de traitements dynamiques supplémentaires. La modification d'une page demande alors un autre flux HTML et nécessite donc l'envoi d'une nouvelle requête au serveur. JavaScript et AJAX C'est pour répondre à ce problème qu'est apparu le langage JavaScript. Le Page 11/40

18 principe de cette technologie est d'ajouter au code HTML, un certain nombre de fonctionnalités qui pourront être interprétées par le navigateur en réponse à certains événements (clic de l'utilisateur, survol d'une zone etc...). De plus pour améliorer l'interactivité des pages avec l'utilisateur, le langage AJAX («Asynchronous JavaScript And Xml») a été développé afin de compléter ce système. Le fonctionnement d'ajax s'articule autour de l'objet JavaScript «HttpRequest» qui permet de définir une requête à envoyer au serveur ainsi que la fonction JavaScript qui sera appelée automatiquement à la réception de la réponse. Il est ainsi possible de recharger une partie de la page web plutôt que la totalité et gagner en interactivité. Cela permet indirectement de limiter la taille et le nombre des messages échangés avec le serveur ainsi que de décharger ce dernier d'une partie du travail. Dans le cas de l'interface existante, le langage JavaScript est utilisé via le framework «prototype» qui permet au programmeur d'avoir accès à un ensemble de classes et de fonctions pour faciliter le développement d'applications. Ce framework permet notamment la création d'un objet «Ajax.Request» permettant de définir simplement une requête AJAX. JSON Afin de simplifier le travail du client et du serveur, ainsi que de gagner en maintenance les données transmises via AJAX sont faites grâce au format JSON («JavaScript Object Notation»). Ce format normalisé sert pour le transfert d'informations entre divers langages et systèmes d'exploitation. Un objet JSON correspond à une suite de champs contenue entre deux accolades (illustration 7). Chaque champ est en fait composé du nom de la variable et de la valeur séparés par un caractère ':'. Il est aussi possible de stocker des données sous forme plus complexe comme par exemple des tableaux. Nom attribut { "IdNode" : "3", Valeur attribut "Name" : "exemple", "Sensors" : [ { "IdSensor" : "3", "value" : "4" }, { "IdSensor" : "9", "value" : "4" }, ], Attribut Tableau } Illustration 7: Exemple d'objet au format JSON Un des principaux intérêts de ce format est qu'il correspond à la même notation qu'un objet en JavaScript. Il est ainsi possible de travailler directement en Page 12/40

19 Javascript avec les données JSON. L'API Google-Maps Cette API a été développée par l'entreprise Google afin de rendre possible l'utilisation de cartes, plans et vues satellites à des échelles variées à l'intérieur d'une page web. Cette bibliothèque de fonctions permet, en plus de l'affichage, d'ajouter diverses informations sur les cartes. Il est par exemple possible de signaler un lieu sous la forme d'un picot et d'y associer une description au moyen d'une bulle d'information (infobulle) comme dans l'illustration suivante(illustation 8). Illustration 8: Utilisation de Google Maps dans l'ancienne interface L'API Google-Maps utilise AJAX et JavaScript afin de pouvoir être intégrée dans la plupart des développements web. 2 Architecture de l'interface [GARNIER et SABALSKI 2008] Les technologies utilisées par l'interface doivent exploiter des données venant de diverses sources. Les informations affichées sont à la base issues des LiveNodes que l'on souhaite contrôler. Afin de les récupérer, le serveur web va entrer en Page 13/40

20 communication avec les différents LiveNodes par l'intermédiaire d'une liaison série. Afin d'avoir le maximum d'interactivité, ces liaisons sont réalisées dans un script PHP appelé par le client via une requête AJAX (Illustration 9). Illustration 9: Exemple de traitement de l'interface [GARNIER et SABALSKI 2008] Cette communication série devra toutefois disparaître dans le nouveau système de contrôle. A la place, on s'adressera au démon SNMP afin de limiter les interlocuteurs. Il faut aussi prévoir que l'agent SNMP n'est pas forcement sur le même serveur que l'interface ce qui peut impliquer des temps de traitements plus longs. Certaines informations sont stockées dans deux tables d'une base de donnée MySQL. On retrouve dans la première, la description des nœuds que l'on souhaite gérer, leur identifiant, leur adresse IP, leur position GPS ainsi que la précision des données GPS. La deuxième table associe l'identifiant du LiveNode avec une valeur capteur et une date de relevé afin de constituer un historique. Ce système de base de données présente l'avantage d'être facilement associé à un serveur web à travers de nombreuses fonctions PHP et d'offrir un stockage persistant. L'organisation des données à l'intérieur de cette base devra cependant être repensée pour intégrer la notion de réseau ainsi que la multiplicité des capteurs sur un LiveNode. Page 14/40

21 L'organisation des pages web de ce projet (Illustration 10) se fait via 3 grandes parties : un menu d'ajout/surpression de nœuds une liste des différents LiveNodes répertoriés dans l'interface et un carte permettant de localiser les nœuds. Il est aussi possible d'accéder à une description d'un nœud dans une infobulle en cliquant sur le picot correspondant sur la carte. Illustration 10: Interface de géo localisation des LiveNodes [GARNIER et SABALSKI 2008] L'organisation des informations sur la page web est assez proche de ce que l'on recherche et ne demandera que peu de changements. On devra cependant transformer la liste des LiveNodes en un menu de sélection permettant d'afficher la liste des réseaux, des capteurs ou des nœuds en fonction des besoins de l'utilisateur. Ces listes permettront ensuite de sélectionner le ou les éléments à afficher. On devra aussi ajouter un panel permettant de visualiser les données associées à l'élément sélectionné dans le menu précédent. Page 15/40

22 IV Étude d'une solution IV.1 Étude du système de contrôle La première tache a été de définir et concevoir la structure de la MIB. 1 Définition de la MIB Comme une version «standard» (un agent par Nœud ou réseau, managé avec une MIB de même structure) n'est pas possible à cause des contraintes de ressources, il nous faut centraliser la MIB dans un seul et même agent. L'utilisation d'un unique démon pour gérer un nombre multiple d'instances d'un même type d'équipement n'est cependant pas prévu dans le protocole. La solution consiste alors à voir l'ensemble des réseaux comme un seul équipement, ce qui nécessitera l'utilisation d'un seul agent. Les réseaux sont alors considérés comme des éléments de notre «super-entité». Ils seront alors inscrits dans la MIB par une entrée dans un index SNMP. Il correspond à une branche de la MIB dans laquelle vont être stockées plusieurs sous-branches de structure identique. Chacune des sous-branches est indexée selon une clef numérique unique (illustration 11). Dans le cas de notre application, cette clef servira d'identifiant SNMP de l'élément. LiveNCM LiveNCM Nombre de réseaux (1) Nombre de réseaux (1) Table Réseaux (2) Index:=Id_Réseau Table Réseaux (2) Index:=Id_Réseau Table Réseaux[1] (1) Id_Réseau (1) Id_Réseau (1) Adresse_IP_Passerelle (2) Adresse_IP_Passerelle (2) Table Réseaux[2] (1) Id_Réseau (1) Adresse_IP_Passerelle (2) Illustration 11: Schéma de principe de l'utilisation d'une table dans la MIB Cette solution n'est cependant pas réutilisable telle quelle pour ajouter des objets LiveNodes et capteurs au sein d'un objet réseau. En effet, il est impossible d'utiliser un index à l'intérieur d'un autre. Ce problème est du à une limitation de la MIB qui Page 16/40

23 n'autorise que des données textes ou numériques au sein d'un index (pas de sousbranches ni d'index). La solution consiste alors à «aplatir» la MIB. Dans ce cas, on va devoir créer un index pour chaque «étage» d'un réseau de capteurs. Ces indexes seront greffés à la base de l'arborescence. En ajoutant un attribut parent dans les index LiveNodes et capteurs, les liens de composition de nos réseaux seront conservés. Afin de gagner en flexibilité et en maintenance il peut aussi être utile de décomposer nos index en sous parties. Chaque «étage» n'aura donc plus une unique table mais plusieurs tables définies par catégorie (Description, État, Communication...). Il sera ensuite possible de rajouter différents types de ressources dans chaque niveau, sans changer la totalité de la numérotation des OIDs, en ajoutant un nouvel index. Pour pouvoir utiliser correctement ce principe, il est cependant nécessaire que chaque instance de données utilise la même clef au sein d'un même niveau. Pour ce projet, cette clef sera l'identifiant SNMP de l'élément. Cette contrainte permet de retrouver toutes les données d'une même instance uniquement à partir de son identifiant. En suivant ces principes, la MIB s'articulera autour de 3 branches (Réseaux, LiveNodes et Capteurs) contenant plusieurs indexes correspondant à leurs sous catégories de données (voir illustration 12). LiveNCM Réseaux De capteurs (1) Nombre de réseaux (1) Table Description Réseaux (2) Index:=Id_Description Réseau Id_Description Réseau (1) LiveNodes (2) Nombre de LiveNodes (1) Table Description LiveNodes (2) Index:=Id_description_LiveNode =IdSNMP Id_LiveNode (1) Id_Réseau_Père(2) Table Communication LiveNodes (3) Index:=Id_Communication_LiveNode =IdSNMP Table Statut LiveNodes (2) Index:=Id_Statut_LiveNode =IdSNMP Les index sont les mêmes pour les sous tables d 'un même objet Capteurs (1) Nombre de Capteurs (1) Table Capteurs (2) Index:=Id_Capteur Id_Capteur (1) Id_LiveNode_Père(2) Illustration 12: Schéma simplifié de la structure adoptée pour la MIB Page 17/40

24 2 Gestion des données de l'agent[net-snmp] Une fois la structure de la MIB définie, il faut étudier le programme qui va se charger de sa gestion. La réalisation de l'extension d'un démon SNMP se base sur une bibliothèque C appelée NET-SNMP. Ce choix s'explique par le fait qu'il s'agisse de l'implémentation la plus complète et la plus utilisée pour ce protocole et qu'elle présente l'avantage d'être utilisable tant sous des systèmes UNIX que Windows. NET-SNMP contient aussi un certain nombre d'outils tel que l'utilitaire MIB2C permettant de générer automatiquement une partie du code du sous-agent à partir du fichier de description de la MIB. Ces fichiers contiennent un certain nombre de «blancs» où le développeur devra ajouter le code spécifique à sa MIB. Le code généré par l'outil MIB2C, ainsi que celui de la première version de l'agent du Cemagref, m'ont permis de saisir la logique de traitement d'une requête au sein de l'agent. Cependant, les spécificités du programme à réaliser (décentralisation, multiplicité des éléments managés, hiérarchisation des données) ont demandées une refonte de certaines parties générées. Structure de données Bien que cette librairie dispose de structures de données avancées, je n'ai pas réussi à trouver un système permettant de recréer facilement de lien hiérarchique entre les tables (Lien Réseau/LiveNode et lien LiveNode/Capteur). Ce lien doit pourtant être facilement récupérable dans certains cas comme la suppression d'un réseau. Cette suppression va détruire l'entrée du réseau mais aussi tous les LiveNodes et Capteurs qu'il contient. Il faut donc être capable de récupérer les structures qui dépendent de l'élément supprimé en vue de leur dés-allocation. J'ai donc pour cela conçu un système de conteneurs «génériques» permettant de retrouver les différents niveaux de composants d'un réseau. Les données de la MIB étant principalement stockées dans des indexes, j'ai utilisé une structure net_snmp_tdata (issue de NET-SNMP) conçue à cet effet. Cette structure correspond à une table stockant un conteneur générique tdata_row pour chaque entrée de l'index. Ces tdata_row sont des conteneurs possédant entre autres une structure contenant les données de l'entrée. Le type de la structure contenue dépend des données contenues dans l'index SNMP. Il va donc falloir créer une structure par index, et chaque structure portera un nom correspondant à celui utilisé pour l'index associé. C'est donc les tdata_row qu'il faut être capable de récupérer pour manipuler les données de la MIB. J'ai pour cela créé des structures row_container Page 18/40

25 «encapsulant» les différents tdata_row d'un même niveau hiérarchique (réseau, LiveNode ou capteur). On complétera le row_container par un lien vers le conteneur père, et une liste vers l'ensemble des fils afin de retrouver les relations «père/fils» entre les éléments de la MIB. Enfin, il faut ajouter un lien vers ces row_container dans chaque structure stockée par les tdata_row. De cette manière, lorsque l'on récupère une des structures de NET_SNMP, on accède au row_container associé via les données qu'elle contient. Il est ensuite possible via le conteneur obtenu de récupérer les autres éléments associés. L'ensemble des structures précédentes sont présentées dans l'illustration ci dessous (illustration 13) Illustration 13: Diagramme de classes UML du module row_container Afin de gagner en possibilités d'extensions, il existe aussi un conteneur fictif nommé TopRow, au dessus de tous les réseaux qui peut permettre l'ajout éventuel d'un niveau supérieur (Notion d'ensemble de réseaux par exemple). Lors de l'implémentation de ce système, j'ai essayé de simplifier le travail d'un éventuel développeur reprenant mon programme. Pour cela, j'ai créé une Page 19/40

26 petite API contenant toutes les fonctions nécessaires à la gestion de mes structures de données inspirées du modèle objet. On déchargera au maximum l'utilisateur de la gestion mémoire en lui fournissant un «constructeur» permettant d'allouer de façon transparente les structures de données et un «destructeur» à appeler lorsque le travail est terminé, libérant ces mêmes ressources. L'accès aux données des conteneurs et des structures «entry» est aussi inspiré du modèle objet avec l'utilisation de «getters»(fonction de lecture) et de «setters»(fonction d'écriture) associées à chaque champ. Ces fonctions permettent notamment d'effectuer un contrôle personnalisé pour chaque accès aux champs. J'ai par la suite gardé ce système pour toutes les autres structures de données afin de maintenir une logique dans mon programme. 3 Communication avec l'agent Manipulation des données Cette partie consiste à identifier quels sont les interrogations possibles au sein de l'agent. On en distingue alors deux types : _ tout d'abord, les commandes utilisateur réalisées au moyen de requêtes Get et Set ensuite la communication entre l'agent et les différentes passerelles. La première partie consiste principalement à recopier les données de la MIB dans une trame pour une requête Get ou bien l'inverse dans le cas d'un Set. Ce code ne présente pas de spécificités par rapport à l'agent et est en grande partie généré par l'utilitaire MIB2C. La seconde partie, par contre doit être réalisée par le développeur car elle dépend directement du matériel à contrôler. Dans notre cas, ces interrogations se feront à travers un réseau ce qui demandera de définir les messages que l'on échangera entre ses différentes entités. Il est possible d'imaginer un système simple dans lequel les passerelles envoient des notifications de mise à jour de la MIB via des requêtes Set. La modification des configurations suite à une requête venant de l'utilisateur se gère de la même manière : La passerelle lit la MIB via une requête Get et envoie une notification à l'élément concerné. Cela simplifierait l'implémentation en évitant de coder une partie spécifique pour ce type de communication, mais demanderait que tous les attributs soient mis en lecture écriture. L'utilisateur aurait donc le pourvoir de modifier certaines informations qui devraient lui être inaccessible en écriture (Typiquement la valeur d'un capteur ou le niveau de batterie). Une autre solution consiste à concevoir un protocole de communication entre l'agent et les passerelles via des sockets TCP ou UDP. Cette solution quoi que plus Page 20/40

27 lourde permet de maintenir une séparation entre les commandes utilisateur et celles venant des réseaux de capteurs. J'ai choisi d'utiliser la seconde solution qui permettra une meilleure sécurité pour les données de la MIB en protégeant certains OID des modifications par l'utilisateur. Protocole de communication Afin de garder une unicité au sein du système, le protocole pour la communication entre l'agent et les passerelles va être le même que celui développé par le Cemagref pour la communication au sein des réseaux. Un certain nombre des requêtes qui sont nécessaires à la communication agent/passerelle est déjà défini dans ce protocole car elles circulent aussi au sein des réseaux de capteurs. Pour les interrogations qui n'existent pas, le travail consiste à définir la séquence de messages et les numéros de commande qui y sont associés. Dans les requêtes de mise à jour et de notification d'un changement dans le réseau, ce message est le plus souvent une unique trame définissant la ressource concernée et contenant la nouvelle valeur. Il reste ensuite à définir les messages associés à l'ajout et à la suppression d'éléments. L'ajout d'un nouveau réseau est fait par l'utilisateur qui va indiquer à l'agent, la passerelle associée au réseau à travers une adresse IP et un port réseau. La requête d'ajout d'une passerelle demande cependant de mettre à jour deux attributs (adresse IP et port) ce qui va demander deux requêtes successives car les commandes Set ne supportent qu'un seul argument. Afin de laisser la possibilité à plusieurs utilisateurs de faire un ajout simultanément, il faut être capable de reconstituer les couples IP/port même si les requêtes arrivent dans le désordre exemple : utilisateur_1 setport utilisateur_2 setport utilisateur_2 setip utilisateur_1 setip Il existe deux solutions sures et faciles à mettre en œuvre pour ce problème: Il est envisageable de regrouper les requêtes setip et setport en une seule au moyen d'une chaine de caractères formatée regroupant les deux arguments. Avec cette solution, l'utilisation d'une seule requête est possible mais peu «élégante» car il sera nécessaire de garder les OIDs capables de récupérer le port et l'adresse séparément pour autoriser une consultation par l'utilisateur d'un de ces paramètres. La deuxième solution consiste à donner un numéro à chaque couple de commandes. Il faut pour cela trouver une méthode permettant à l'utilisateur de réserver un identifiant unique avant d'effectuer sa Page 21/40

28 transaction. Cela peut être facilement réalisé en ajoutant un OID renvoyant un identifiant SNMP libre pour le réseau. J'ai choisi d'utiliser la deuxième solution malgré le fait qu'elle soit plus complexe car elle répond mieux au modèle prévu par SNMP (Une requête = un paramètre). Pour améliorer ce système, on demandera à l'utilisateur de confirmer sa réservation. Tant que cela n'a pas été fait l'identifiant retourné par l'oid de réservation sera le même. Cela permet d'éviter qu'une requête Get ou Walk ne réserve définitivement un OID pour rien. La séquence des messages précédemment cités est présentée par le diagramme suivant (illustration 14). Illustration 14: Création d'un nouveau réseau La confirmation va se faire par une requête Set sur l'oid de réservation. Cet OID ne correspondant pas à des données, il est judicieux de le séparer des autres dans la MIB. J'ai donc pour cela ajouter une branche commande qui contiendra les OIDs ne correspondant pas réellement à des ressources mais plutôt utilisés pour maintenir la MIB. Afin de simplifier le travail de l'utilisateur, les LiveNodes et les Capteurs seront détectés automatiquement par les passerelles (voir illustration 15). Cette détection sera notifiée à l'agent par un message de la passerelle qui déclenchera l'allocation Page 22/40

29 des structures de données adaptées. La passerelle recevra ensuite un message en retour indiquant quel est l'identifiant du nouvel élément. Une fois l'élément créé, celui ci peut envoyer une trame pour annoncer sa configuration initiale. Illustration 15: Notification de nouveau nœud Dans le cas d'un nouveau LiveNode, une adresse IP sera automatiquement attribuée en fonction de son identifiant et de celui de son réseau. L'unicité de l'adresse au sein des réseaux de capteurs est garantie grâce à un formatage spécial : On va tout d'abord prendre la plus grande plage d'adresse IP utilisable en réseau local ( classe A => de à soit 232 adresses) Afin que l'agent puisse envoyer les messages pour un LiveNode vers le bon réseau de capteurs, on placera l'identifiant du réseau (de 1 à 255) dans la partie haute de l'adresse. Exemple: plage d'adresse du réseau N 20 => de à Le reste de l'adresse sera constituée par l'identifiant du nœud (de 1 à 65534) Exemple : LiveNode N 200 dans le réseau 241 => La suppression d'éléments du réseau, par contre, ne peut pas être automatique. En effet, il est impossible de distinguer un LiveNode qui n'a plus de batterie, un réseau perdant temporairement sa connectivité ou un élément qui a été supprimé réellement (dans tous ces cas, on va uniquement détecter une absence Page 23/40

30 de communication). Il faut donc laisser la responsabilité de la suppression d'un élément à l'utilisateur. La suppression d'un élément reviendra à effectuer un SET sur un OID prévu à cet effet avec en paramètre l'identifiant de l'élément à libérer. L'agent devra ensuite notifier la commande à la passerelle qui effectuera les traitements qui s'imposent. Les OIDs de suppression seront ensuite insérés dans la branche commande de la MIB précédemment crée. Type de connexions Après la définition de ce protocole, il nous faut choisir le type de sockets à utiliser pour la communication. Avant de choisir le type de communication, il faut remarquer qu'il existe deux types de trafic réseau entre les passerelles et l'agent. des commandes émises par l'agent dont le message contient au plus un unique paramètre (nouvelle valeur de l'attribut à modifier). Elles seront suivies d'un accusé de réception venant de la passerelle concernée. des données de capteurs et des configurations modifiées en provenance des passerelles et à destination de l'agent. Les trames seront la aussi courtes. La perte de trames non détectée peut avoir des conséquences importantes notamment à cause de l'estimateur. On peut, par exemple, avoir un envoi suite à une variation importante des données capteurs exigeant de recalculer la courbe d'estimation. Si ce paquet se perd, l'agent continuera à tort d'utiliser les mêmes estimations et faussera toutes les demandes de valeurs suivantes. Les traitements à effectuer lors de la réception de données sont totalement différents, ce qui impose logiquement de créer deux fonctions distinctes. Dans le cas de notre agent, ces fonctions seront déclenchées par l'arrivée de données sur une socket. Il devient alors nécessaire de séparer ces deux types de trafic sur deux sockets différentes. Pour la réalisation d'une application utilisant le réseau pour transmettre des données via un réseau local ou internet, il existe principalement deux protocoles utilisables au niveau des sockets. Il est possible d'utiliser une transmission synchrone via le protocole «Transmission Control Protocol» (TCP) ou asynchrone via «User Datagram Protocol» (UDP). L'utilisation de TCP permet d'avoir un transport fiable car il intègre un accusé de réception, et les trames arrivent dans l'ordre et sans duplication. Son utilisation se fait en mode connecté ce qui va demander une socket par connexion. L'exploitation de cette solution demande donc de gérer les connexions avec les Page 24/40

31 différentes passerelles (soit en ouvrant les connexions au besoin et en les refermant ensuite, soit avec un tableau de correspondance passerelle/socket) De son coté, le protocole UDP permet une transmission non connectée : le transport est non fiable, c'est à dire, pas d'accusé de réception, et les paquets peuvent arriver dans le désordre ou être dupliqués. Il devient alors plus difficile de reconstituer un message fragmenté en plusieurs trames. Son utilisation est plus courante pour un «flot» de données où la perte de paquets est moins déterminante que la vitesse de transmission. Ce protocole permet de fixer le destinataire à l'envoi et non à la connexion. On a donc la possibilité de n'utiliser qu'une socket pour l'ensemble des passerelles et d'effectuer des messages multicasts et broadcast (envoi à un groupe ou à tous les postes d'un réseau local). J'ai choisi l'utilisation de l'udp pour le trafic de commandes issues de l'agent. En effet, les principaux avantages de TCP ne sont pas déterminants dans ce cas: l'arrivée de trames dans le désordre est surtout problématique dans le cas de messages fragmentés ce qui n'est pas le cas ici. Les commandes envoyées par l'agent aux passerelles consistant uniquement à des modifications de paramètres ou des suppressions d'éléments, un deuxième appel de la commande suite à une duplication de paquets n'aura aucun impact sur le résultat. Seul le système d'accusés de réception est un avantage. Les commandes issues de l'agent sont cependant envoyées de façon séquentielles ce qui rend l'ajout de cette fonctionnalité facile dans notre cas (attente de réception d'un message en retour ou nouvel essai dans le cas contraire). De plus, l'utilisation d'une socket UDP unique est beaucoup plus facile à gérer et l'utilisation du multicast pour les commandes peut ouvrir des perspectives intéressantes (envoi d'une commande «mise en veille» à l'ensemble des réseaux par exemple) Le choix du protocole dans le cas des données issues des passerelles sera différent. La duplication de trames ou la perte de paquets de la passerelle vers l'agent peut avoir des conséquences plus graves. On pourrait par exemple avoir une perte d'une mesure issue d'un estimateur : l'agent considérerait que les valeurs suivent toujours ses estimations alors que la courbe peut avoir pris une évolution complètement différente. De plus, l'agent n'est pas en permanence à l'écoute des passerelle, ce qui rend la réalisation d'un accusé de réception plus complexe à réaliser. L'utilisation de TCP semble donc plus adaptée dans ce cas. 4 Persistance des données La partie suivante de l'étude concerne la persistance des données de l'agent. Les agents SNMP sont conçus pour stocker leurs structures de données dans leurs mémoire (libérée en cas d'arrêt) plutôt que sur le disque. Dans un agent «classique», cela ne pose pas de problèmes particuliers, car en cas de reprise après un arrêt, l'agent rechargera les données dans l'élément qu'il administre. Page 25/40

32 Dans notre agent, ce rechargement est difficilement possible, car ce dernier aura «oublié» l'architecture des réseaux (IP des passerelles, LiveNodes composant un réseau etc...). Il sera donc incapable de savoir à qui s'adresser pour récupérer ces informations. Afin d'assurer la conservation des données après un arrêt (volontaire ou non) de l'agent, il faut mettre en place une méthode de sauvegarde pour les données sur le disque. Stocker les structures de données de l'agent sur disque plutôt que dans la mémoire est possible mais cependant lourd à gérer avec NET-SNMP. Une solution plus simple consiste à créer des sauvegardes persistantes lors de l'arrêt. Il est alors possible de charger la dernière sauvegarde créée au démarrage de l'agent. Cette solution permet aussi de pouvoir revenir à une date ultérieure suite par exemple à une erreur de manipulation. Afin d'avoir une possibilité de reprise après un arrêt inopiné (coupure de courant, défaillance du programme) il est aussi envisageable de sauvegarder régulièrement l'état de la MIB grâce à une routine périodique de sauvegarde. Sauvegarde au format XML J'ai choisi d'utiliser des fichiers XML classiques car ce type de stockage est très répandu avec de nombreuses bibliothèques permettant cette gestion. De plus, il sera possible pour l'utilisateur d'exploiter ces fichiers avec un autre outil. Ce standard a été défini afin de créer un système de stockage portable, facilement utilisable pour de nombreuses applications [W3C 2004]. <mon_element> <donnée_texte_de_mon_element> Ceci est un test </donnee_texte_de_mon_element> <liste_contenu> <donnee_du_contenu> 42 </donnee_du_contenu> <donnee_du_contenu> 43 </donnee_du_contenu> </liste_contenu> <mon_élément> Illustration 16: Exemple de document XML Ce langage définit une classe d'objet de données appelée document XML. Ils sont construits autour d'un modèle arborescent organisé à travers un ensemble de balises et se manipulent à travers un programme nommé processeur XML. Chaque jeu de deux balises (début <...> et fin </...>) délimite un élément XML qui peut être des données brutes (texte, numérique, image ) ou bien d'autres éléments délimités par deux autres balises (voir illustration 16). Le standard défini aussi l'utilisation d'une grammaire, permettant la description du format d'un type de document, appelée «Document Type Page 26/40

33 Declaration» (DTD). Il est ainsi possible de tester si un document est valide, c'est à dire s'il possède la structure attendue pour ce type de document. J'ai cherché parmi les bibliothèques de gestion XML celles utilisables en langage C afin de garder une homogénéité dans mon programme. J'ai choisi d'utiliser la libxml2 qui est la plus utilisée dans ce langage et est inspirée du modèle objet. La manipulation de données à travers cette bibliothèque se fait grâce à un objet XmlDocument. L'écriture d'un document se fait facilement à l'aide de trois fonctions permettant d'ouvrir et fermer des balises à la position courante ou d'ajouter des données dans la dernière balise ouverte. On obtient une première version de la fonction de sauvegarde semblable à celle présenté par l'illustration 17. creerdocumentxml ouvrirbalise MIB pour tout réseau ouvrirbalise réseau ouvrirbalise id_réseau ecriredonnéenumerique id_réseau fermerbalise id_réseau ouvrirbalise nom_réseau ecriredonnéetexte nom_réseau fermerbalise adresse_réseau... ouvrirbalise noeudréseau pour tout noeud du réseau fin pour fermerbalise réseau fin pour fermerbalise enregistrer Document Illustration 17: première version de l'algorithme de sauvegarde Optimisation du code du module sauvegarde Les versions des d'algorithmes de sauvegarde et de chargement présentées ne sont cependant pas optimales car elles utilisent de façon redondante des blocs très semblables composés de trois fonctions (ouverture_balise, traitement, fermeture_balise). Avec ce système, on aboutit à des fonctions très longues et Page 27/40

34 répétitives qu'il est possible de raccourcir. De plus, ces fonctions sont peu flexibles car un changement de la structure des données demande de modifier une certaine quantité de code associée. Néanmoins, il est possible de créer à la place de ces blocs une unique fonction qui réalise ces trois opérations. Ces fonctions seraient définies comme suit : écrire_donnée_mib_dans_xml_(document, balise, donnée) écrire_donnée_xml_dans_mib(document, Ces fonctions devront se décliner en deux versions, car la gestion d'attributs textes demande un paramètre de plus, pour la longueur chaine de caractères, que les attributs numériques. L'utilisation d'une programmation «orientée objet» pour les données de la MIB m'a permis d'imaginer une autre modification. On peut noter que ces fonctions utilisent des données sans effectuer de contrôles spécifiques sur leur validité (Bornes, format d'une adresse IP ). Ces traitements sont par contre réalisés dans les fonctions getters/setters implémentées pour la MIB. Les getters (et les setters) sur des données d'un même type ont des prototypes identiques. Il devient alors facile de transformer les fonctions précédentes afin qu'elles prennent comme paramètres la fonction d'accès à élément (à travers un pointeur de fonction) qui sera utilisée pour écrire les données avec contrôles ou lire la ressource. Afin d'améliorer encore le module, j'ai créé un système permettant de ne pas changer le code des fonctions de sauvegarde lors d'une modification de la structure de la MIB. L'idée de ce système est d'avoir une structure de description de la MIB. Chaque OID va être décrit par son getter, son setter son type et le nom de la balise XML associée. La sauvegarde (ou le chargement) reviendra à parcourir la structure et d'appeler le getter (réciproquement le setter) avec les arguments correspondant en fonction du type d'objet. Le documents XML et la MIB ayant tout les deux une structure arborescente, le parcours de la structure peut se faire de la même manière. La fonction de parcours doit donc être capable de parcourir n'importe quelle arborescence pour satisfaire tous les cas d'organisation possibles dans le cadre du projet LiveNCM. Grâce à ces améliorations, le travail d'un programmeur modifiant la structure des sauvegardes XML revient à écrire cette description dans un fichier prévu à cet effet (voir annexes). Cette description se fait simplement grâce à 5 fonctions : XML_NEW_TABLE_DESC => début de la description d'une table XML_TABLE_ADD_TABLE => ajout d'une sous table dans la table en cours de description XML_TABLE_ADD_SEQ => ajout d'une sous table index dans la table en cours de description Page 28/40

35 XML_TABLE_ADD_INTEGER => ajout d'un attribut de type numérique XML_TABLE_ADD_STRING => ajout d'un attribut chaine de caractères IV.2 -Conception de l'interface La conception de l'interface se déroulera en trois parties principales : _ Il va tout d'abord être nécessaire de convertir l'ancien projet afin qu'il corresponde au nouveau modèle. _ La deuxième partie consistera en l'ajout des fonctionnalités permettant de gérer les configurations des nœuds. _ Enfin, on s'occupera de la gestion des valeurs capteurs et de la présentation de l'historique. 1 Adaptation au modèle Communication Contrairement à l'ancienne version du projet qui utilisait une liaison série vers les LiveNodes, l'interface doit récupérer les données en s'adressant à l'agent via SNMP. L'utilisation des fonctions SNMP est gérée par PHP grâce à une extension du langage. Une fois cette extension installée, il suffit de remplacer la communication série par des fonctions SNMP. La principale différence entre ces deux méthodes est qu'une requête SNMP est associée à une ressource alors que la communication série renvoie une trame contenant un ensemble d'informations associées à un nœud. Le nombre de requêtes pour un affichage va donc être plus important et peut causer un plus long temps de traitement. Ce temps peut être particulièrement important lorsque l'on demande l'affichage de tous les nœuds sur la carte par exemple. Afin de remédier à cela on cherchera à mémoriser les informations qui n'ont pas de raisons de changer et qui sont utilisées régulièrement. Ces informations sont de deux 2 types : l'architecture des réseaux (liste des nœuds d'un réseau et liste des capteurs connectés sur un nœud) et les positions GPS qui seront utilisées par Google-Maps. Pour stocker ces données, on réutilisera l'ancienne base de données du projet grâce à trois nouvelles tables réseau, nœuds et capteurs. En plus de répondre au problème, ce système permet aussi de simplifier certaines requêtes nécessitant de filtrer les données. En effet, il est beaucoup plus simple et plus rapide de faire un filtre avec une requête sur la base de données plutôt que de récupérer l'ensemble des données SNMP et de ne garder que celles qui correspondent. Page 29/40

36 Les différents accès aux données seront ensuite réalisés selon le modèle suivant : Le client appellera un script JavaScript pour préparer une requête AJAX vers le serveur contenant le nom de la fonction à exécuter avec une liste de paramètres préalablement formée. Ensuite, du coté serveur, on récupérera les identifiants des ressources à interroger, soit à partir des paramètres du script, soit à travers une requête à la base de donnée. On va ensuite boucler sur chacun de ces identifiants et récupérer les données en réalisant une commande SNMP par ressources concernées. Une fois l'ensemble des ressources récupérées, on construit une trame JSON selon un format spécifique au script. Ce JSON sera retourné au client et exploité par la fonction JavaScript prévue pour la réception. Historique L'historique de l'ancienne interface reposait sur la base de données. Elle supposait cependant qu'il n'existait qu'un capteur par nœud sans faire de distinction de type ni d'unité. L'historique doit forcement se faire hors de l'agent car les démons SNMP sont conçus pour être l'image d'un équipement à un instant donné sans avoir de «mémoire». Il est ainsi impossible d'accéder à d'anciennes valeurs par le biais de l'agent. Cet historique va donc rester dans la base de donnée qui devra être réorganisée. Pour cela, la table historique contiendra l'identifiant du capteur, une date de prise, sa valeur ainsi que son type, son facteur et son unité de mesure. Importation des données Dans le système existant, les LiveNodes qui étaient gérés dans l'interface, étaient ajoutés et supprimés manuellement puis mis à jour dans la base. Il est possible de reproduire ce comportement au niveau de l'ajout de réseaux et de la suppression d'éléments, mais pas au niveau des nœuds et des capteurs. En effet, ces derniers sont détectés automatiquement par l'agent qui doit pouvoir fonctionner indépendamment de l'interface et ne peut donc ajouter les identifiants dans la base de données. Il est donc nécessaire de trouver un moyen de mettre à jour régulièrement la structure des réseaux dans la base. Pour cela,j'ai conçu un script PHP qui permet de détecter les différences entre les données de la MIB et celle de la base. La première partie du script recherchera les identifiants SNMP des éléments Page 30/40

37 des réseaux de capteurs à l'intérieur de la MIB au moyen de la commande SNMPWALK appelée via l'extension de PHP. Ensuite, on récupère l'ensemble des identifiants réseaux, LiveNodes et capteurs et on les compare avec ceux de SNMP. Tous les nouveaux éléments détectés feront l'objet d'une fonction récupérant les données nécessaires à leur insertion dans la base de données. Ce script devra ensuite être appelé périodiquement afin de s'assurer que l'utilisateur puisse consulter des données à jour. Pour cela, on peut utiliser un démon présent sur la majorité des systèmes UNIX : l'ordonnanceur de taches périodiques nommé «Cron». Ce démon a pour but de gérer les taches répétitives en lançant des scripts à des horaires précis. Il suffit donc d'indiquer le script PHP à l'ordonnanceur pour qu'il exécute la synchronisation à la fréquence définie par l'utilisateur dans son fichier de configuration. 2 Extension de l'interface A la suite de ces modifications, pour transposer l'interface dans la nouvelle architecture, il est maintenant nécessaire d'ajouter les fonctionnalités propres au nouveau projet. Gestion des informations La partie la plus importante consiste à ajouter la possibilité de consulter et modifier les configurations des éléments du réseau. La première tache consiste tout d'abord à identifier les différentes informations utilisables issues de la MIB. Parmi ces informations toutes ne possèdent pas la même pertinence. On va donc classer ces informations en 3 types : tout d'abord, les données essentielles (Identifiant, niveaux de batterie, valeur capteur...) qui vont être affichées en priorité. Ces données vont notamment se retrouver dans le menu de sélection afin de donner un rapide aperçu de l'ensemble des éléments. Les données de fonctionnement (nombre de LiveNodes d'un réseau, puissance du signal reçu, type de capteur ) qui donnent des informations sur l'équipement sélectionné mais qui ne peuvent pas être modifiées par l'utilisateur. Ces données seront affichés dans un menu décrivant les valeurs de l'élément sélectionné. Enfin, on retrouvera les données de configuration. Il s'agit d'informations sur lesquels l'utilisateur a la possibilité d'agir. Ces données feront l'objet d'une sous partie dans le menu informations. Cette sous partie pourra être passée en mode lecture ou bien modification grâce à un bouton. Page 31/40

38 Chacune de ces types d'informations fera l'objet d'un traitement différent via une requête AJAX. Jusqu'à présent les données sur un élément du réseau étaient affichées au sein d'une infobulle sur la carte. Les informations à gérer dans la nouvelle version sont beaucoup plus nombreuses et ne pourront être traitées de cette façon. Il a donc été nécessaire d'ajouter un nouveau panel à l'interface. Ce panel sera rempli à chaque choix d'un élément à visualiser dans le menu sélection. Il sera divisé en 3 parties (illustration 18) consultation des informations gestion des configurations affichage de la liste des éléments fils (liste des capteurs du nœud / liste des LiveNodes d'un Réseau). Menu d'ajout des Réseaux de capteurs Menu Informations (données en consultation uniquement) Numéro de la commande 0_4_4_initContainer_ 11_5_5_getChildVide_ 12_0_0_getFirstChildVide_ 13_0_0_removeFirstChildVide_ 9_5_5_removeChildVide_ 10_5_5_ajoutUnique_ Paramètres de la commande Description de la ligne Menu configuration (données modifiables par l'utilisateur) Liste des éléments (informations essentielles) Illustration 18: Organisation de l'interface Page 32/40

39 Filtrage des données Malgré les améliorations pour limiter le trafic et augmenter la vitesse de l'interface, un grand nombre de réseaux visualisés peut demander un temps de traitement très important. De plus, il est rarement utile de visualiser l'intégralité des données en même temps. Afin de remédier à cela, on va donc chercher à limiter l'affichage aux données demandées par l'utilisateur. Ce filtrage peut intervenir à deux principaux niveaux : tout d'abord, il peut être utile de limiter les données à certains critères (Pas de réseaux vides, filtrage sur un ou plusieurs attributs...) l'utilisateur peut aussi choisir manuellement de ne pas afficher certains éléments. Pour le premier type de requêtes, on prévoit pour chaque script PHP qui sera appelé via AJAX des paramètres facultatifs permettant de gérer les filtres. Ces filtres seront pris en compte par les script PHP lors de la phase de sélection des identifiants SNMP à récupérer. Ces différents filtres seront configurables par l'utilisateur via un menu prévu à cet effet. Dans le second cas, il s'agit d'ajouter dans la liste des éléments sélectionnés, une possibilité pour cacher un élément que l'on a défini par une case à cocher symbolisant ce choix. Les éléments cachés resteront uniquement visibles au niveau de la liste de sélection mais n'apparaitront plus au niveau du reste de l'interface. La liste des éléments cachés est mémorisée dans trois tableaux JavaScript (un par niveau) afin de pouvoir s'en souvenir lors d'un nouvel affichage (après un changement de filtre par exemple). Pour compléter, on cachera aussi les fils d'un élément caché. Pour cela, on a ajouté trois autres tableaux JavaScript contenant les identifiants affichés actuellement dans chaque niveau. Ces tableaux seront reremplis après chaque changement de filtre au moyen du flux de données envoyé par le serveur. Ces tableaux seront ensuite passés à tous les scripts PHP sur des niveaux inférieurs. Les scripts PHP limiteront leurs recherches aux identifiants qui sont associés à des descendants des éléments inscrits dans le tableau. Gestion de l'historique Jusqu'à présent, les données des capteurs étaient mémorisées dans une base de données mais n'étaient jamais réellement exploitées par l'interface. Afin de présenter l'évolution des données d'un capteur, j'ai choisi d'intégrer un graphique à la description de chaque capteur. Pour cela, j'ai cherché une librairie permettant de réaliser des graphes, utilisable avec les technologies web. Mon choix s'est alors porté sur une librairie basée sur le framework prototype et sur AJAX nommée FLOTR. Cette API est particulièrement complète (zoom, courbes multiples, gestion d'événements ) et présente une syntaxe facilement utilisable [SOLUTOIRE]. Le choix de cette librairie est aussi du au fait qu'elle n'utilise que des technologies qui Page 33/40

40 étaient déjà utilisées dans l'interface, et n'allonge pas la liste des bibliothèques dont on dépend. Au moyen des événements de cette API, un panel (illustration 19) a été conçu pour permettre à l'utilisateur de spécifier une période de recherche d'historiques, de gérer différents niveaux de zoom et de se déplacer facilement dans le temps. Ce panel a ensuite été intégré au niveau du menu d'information pour les objets capteurs. Illustration 19: Panel de l'historique des capteurs L'historique hérité de l'ancienne interface présente un autre point perfectible : la base de données n'est remplie que lorsqu'un utilisateur déclenche une capture. Ce système a pour conséquences d'avoir généralement peu de valeurs pour un même capteur sur une longue durée. L'automatisation des mesures va permettre d'avoir une meilleure vision de l'évolution des données capteurs à travers le temps. Comme dans le cas de la synchronisation base / MIB, on s'appuiera sur le démon Cron pour alimenter la base de données à l'aide du même script que celui qu'exécute l'utilisateur lorsqu'il décide de faire une capture manuelle. IV.3 Protocole de test Tout programme nécessite un certain degré de tests afin de garantir une bonne fiabilité. Cela est d'autant plus important dans le cas de l'agent SNMP créé. En effet, comme tous les démons et les serveurs réseau, le programme doit fonctionner en permanence. Un arrêt du programme s'accompagne alors d'un arrêt du service qui peut laisser passer un certain nombre d'informations importantes. Page 34/40

41 Une longue période de fonctionnement implique une plus grande vulnérabilité à d'éventuels erreurs pouvant aboutir à des données corrompues, un fonctionnement erroné, ou à la terminaison inopinée du programme. Ces erreurs peuvent être dues à des erreurs de conception (oubli de cas d'erreurs, mauvais algorithme...), ou des problèmes de ressources (accès à une mauvaise zone mémoire, allocation impossible, fuite de mémoire ) qui sont autant de causes possible de pannes. Dans ce but, j'ai réalisé un certain nombre de tests visant à réduire les risques au niveau de l'agent. J'ai pour cela essayé d'identifier le maximum de cas d'utilisation que j'ai ensuite testé pour détecter les erreurs de conception. Ces tests doivent prendre en compte non seulement les cas d'utilisation normaux mais aussi la réaction face à un cas d'erreur (donnée invalide ou non allouée, coupure de connexion ). Les jeux de tests devront exécuter ces différents scénarios pour observer que les réactions soient bien conformes à celles attendues. Malheureusement, ce genre de tests n'est généralement pas suffisant. Il existe en effet des problèmes qui peuvent ne pas se manifester lors d'une simple exécution. C'est le cas par exemple des fuites de mémoire : le programme va allouer de la mémoire qui dans certains cas ne sera pas libérée et sera donc inaccessible jusqu'au prochain redémarrage de l'application voir du système d'exploitation. Dans le cas d'une seule exécution, il peut y avoir la perte de quelques octets ce qui ne perturbera pas le programme. Cependant dans le cas d'une exécution prolongée, toute la mémoire sera peu à peu consommée inutilement jusqu'à la saturation du système. Afin de surveiller ce genre de problèmes, il existe des outils de diagnostique qui recensent les allocations et contrôlent tous les accès mémoire. La mémoire non libérée au moment de l'arrêt est alors signalée à l'utilisateur. Pour les tests, j'ai utilisé un de ces programme nommé Valgrind afin de m'assurer de la bonne gestion des dés-allocations. 1 Tests des modules La première partie des tests consiste à valider les différents modules indépendamment des autres. Il faut préalablement à cela définir les dépendances entre les modules afin de pouvoir réaliser la suite de nos tests. En effet, avant de contrôler un module, il faut valider l'ensemble de ses dépendances. Cela permet de ne pas avoir à chercher une éventuelle erreur dans l'ensemble des sous modules mais uniquement dans la partie en cours de tests. On pourra ensuite tester l'intégralité des fonctions du module à travers plusieurs jeux de test. Ne connaissant pas de bibliothèque de test en langage C, j'ai créé un système simple pour réaliser cette tâche. Chaque test de module va se faire par l'appel d'une fonction principale chargée de lire un fichier texte formaté. Le premier champ Page 35/40

42 correspondra au code associé à une fonction qui devra être exécutée. Ce champ sera suivi d'un certain nombre d'autres correspondant aux paramètres à utiliser lors de l'appel (illustration 20). On déroule alors séquentiellement les fonctions jusqu'à la fin du fichier. Chaque appel de fonction est encadré, avant et après, par des affichages décrivant l'état des structures de données de manière à voir l'effet de la fonction (illustration 21). Numéro de la commande 4_5_ErrFreeSurVide_ 0_ 1_ErrParamNeg_ 0_0_ErrParamNul_ 0_1_BonParam_ 0_1_doubleInit_ 4_4_Free_ 4_5_DoubleFree_ Description de la ligne Paramètres de la commande Illustration 20: Extrait d'un fichier de tests fichier test 1: testinit.test test : ErrFreeSurVIde_ delete_freespace: lst: 0 => lst=> 0 printlist: vide/noninit test : ErrParamNeg_ initfreespace: lst:0 arg:-1 => lst:0 printlist: vide/noninit test : ErrParamNul_ initfreespace: lst:0 arg:0 => lst:0 printlist: vide/noninit test : BonParam_ initfreespace: lst:0 arg:1 => lst: printlist: begin cell: [next= 0, start= 1, long= 1 ] printlist: end test : doubleinit_ initfreespace: lst: arg:1 => lst: printlist: begin cell: [next= 0, start= 1, long= 1 ] printlist: end test : Free_ delete_freespace: lst: => lst=> 0 printlist: vide/noninit test : DoubleFree_ delete_freespace: lst: 0 => lst=> 0 printlist: vide/noninit Illustration 21: Résultat de l'exécution du scénario précédent (voir illustration 20) Page 36/40

43 Durant tout le traitement du fichier, certaines données sont gardées telles quelles afin de tester des suites d'opérations sur un même objet (par exemple tester la création d'une structure, sa dés-allocation suivi d'une tentative de lecture de données). L'ensemble des résultats des tests est ensuite regroupé dans un fichier permettant de résumer les tests déjà effectués avec succès. Dans le cas où un problème est constaté, le code défaillant est modifié puis les tests sont relancés dans tous les modules qui en dépendent. L'avantage de réaliser des fichiers est qu'ils est possible de modifier le code du programme et de ré-exécuter les mêmes tests facilement. 2 Test de l'application Certains modules ne sont pas testables grâce à la technique présentée précédemment. Il s'agit par exemple du cœur du programme chargé de traiter les requêtes SNMP arrivant dans l'agent. Pour pouvoir valider ces fonctions, il est alors nécessaire de procéder à des tests sur l'ensemble de l'application. Afin de pouvoir réaliser cette partie, il est nécessaire de communiquer avec les passerelles qui n'étaient pas encore terminées au moment des tests. J'ai donc du développer un programme capable de générer des trames en réponse aux requêtes de l'agent. Ce programme permet aussi l'envoi de trames pour simuler une remontée d'informations en provenance des réseaux de capteurs. Avec cette passerelle simulée, j'ai procédé de façon similaire aux jeux de tests précédemment décrits : j'ai créé des scripts shells de scénarios composés d'une succession de commandes SNMPGET et SMPSET. Ces scripts comportent régulièrement des commandes SNMPWALK sur l'ensemble de mon extension de MIB afin de pouvoir évaluer les effets des commandes précédentes. Page 37/40

44 V Discussion 1 Déroulement du projet Durant ce projet, j'ai travaillé selon une méthode itérative, par ajout successif de fonctionnalités. Chacune de ces itérations suit ensuite le cycle de développement traditionnel en 3 phases : analyse / conception / réalisation. Ce choix de méthode de travail vient principalement du fait qu'il s'agisse d'un projet de recherche sur lequel un certain nombre de points sont susceptibles de changements en fonction des avancées du projet. Ces changements ont demandé d'avoir un système particulièrement flexible et modulaire. Malgré cela, certaines parties ont dues être réécrites après leur mise au point. Ces réécritures ont cependant permis de mettre en place un certain nombre d'optimisations qui n'avaient pas été envisagées lors d'une première version. Les principaux problèmes rencontrés viennent essentiellement du fait que la réalisation de l'agent demande l'adaptation du protocole SNMP à des usages qui n'avaient pas été prévu au départ. Cela demande notamment la recherche de documentations plus approfondies et donc plus difficilement compréhensibles. 2 Résultats Lors de la rédaction de ce rapport, les deux parties du projet sont en phase de finition. Afin de pouvoir disposer d'un système relativement fiable lors de mon départ, j'ai choisi de ne pas ajouter de nouvelles fonctionnalités qu'il serait difficile de valider sur une aussi courte période. La conception des différentes parties et le développement des modules principaux de la solution est terminés. Il reste cependant un certain nombre de détails qui n'ont pas été implémentés. De même en absence de passerelles fonctionnelles, il n'y a pas encore eu de tests «grandeur nature» et un certain nombre de fonctions n'ont pas été validées en conditions réelles d'utilisation. Le projet ne sera pas fonctionnel pour une exploitation normale à la fin du stage. En effet, le sujet étant très vaste l'analyse a due être tournée vers certains aspects prioritaires afin d'avoir une version de «démonstration» du système. Ce système doit donc rester en version «recherche» tant que certains points n'auront pas été réglés. On peut notamment citer les besoins d'une étude approfondie au niveau de la sécurité, une mise à niveau de l'agent vers la dernière version du protocole SNMP et un système de cryptage des trames envoyées entre l'agent et les passerelles. Afin que ce projet puisse être correctement repris, j'ai accordé de l'importance à mes commentaires de fonctions ainsi qu'aux documentations associées. A cela Page 38/40

45 s'ajoute la volonté d'avoir un système relativement souple et la mise place un certain nombre de mécanismes, facilitant le codage à réaliser en cas de modifications de l'agent. La modularité de l'ensemble agent/mib/interface a été mon principal objectif afin de proposer une solution facilement réutilisable et modifiable. De plus, j'ai développé un script d'installation pour permettre le déploiement et la configuration de l'agent sur un nouveau serveur de façon interactive. Page 39/40

46 VI Conclusion Afin de pouvoir administrer efficacement l'ensemble des réseaux de capteurs sans fil, le Cemagref travaille à la conception d'un système nommé LiveNCM. Mon stage a consisté en la réalisation d'un sous-agent SNMP capable de remplir ce rôle de superviseur ainsi que l'interface utilisateur associée. Au terme de ce projet, il existe une version d'essai du système de supervision mettant en application les principaux aspects du système LiveNCM. Le sous agent a été testé au moyen de passerelles virtuelles simulées mais devra être validé par la suite sur des réseaux réels. La conception d'un tel système étant un sujet très vaste, il existe encore des aspects qui devront être approfondis. Ce système de supervision doit donc pour l'instant être considéré comme une version de démonstration des différents concepts. L'interface du système, quant à elle, est opérationnelle même si des modifications futures du système de supervision peuvent impliquer quelques changements. Les principales difficultés de se stage ont été de s'adapter aux contraintes d'un projet de recherche dont les objectifs et les différentes étapes sont susceptibles de changer en fonction de l'évolution des travaux. A cela s'ajoutent les difficultés à trouver des documentations lorsque l'on utilise certaines technologies de façon peu habituelles. Ce projet a aussi été l'occasion de m'intéresser à certaines parties du projet dont je n'étais pas en charge, et d'apporter mon point de vue lors de la conception des passerelles utilisées au sein des réseaux de capteurs. Grâce à ce stage, il a été possible de mettre en application certains points du système LiveNCM afin de valider une partie de ce dernier. Afin d'être exploitable pour des utilisations réelles, ce projet va toutefois nécessiter des études supplémentaires sur divers points tels que la sécurité ou une gestion plus avancée des messages échangés à travers un protocole de routage efficace par exemple. Page 40/40

47 Glossaire/Lexique Processus démon : Programme exécuté automatiquement en tache de fond sans contrôle par l'utilisateur. Ces processus sont typiquement utilisés pour répondre à des taches du système (détection de nouveaux périphériques, taches répétitives...), ou pour servir de serveur réseau (mail, pages internet). API : (Application Programming Interface) Ensemble de fonctions regroupées au sein d'un bibliothèque Framework : Ensemble de «briques» logicielles (bibliothèques et outils) utilisables pour le développement d'application. SNMP : (Simple Network Management Protocol) Protocole réseau de supervision permettant la surveillance et l'administration d'équipements réseaux à distance LiveNode : Plateforme embarquée développée par le LIMOS destinée aux réseaux de capteurs sans fil. MIB : (Management Information Base) Structure de données arborescente normalisée et utilisée par le protocole SNMP. OID : (Object IDentifier) Identifiant associé à une ressource utilisé dans le protocole SNMP RFC : (Request For Comments) Document décrivant les détails techniques d'une technologie utilisée sur Internet. Ces documents sont enregistrés par un organisme nommé IETF

48 Références Bibliographiques Références internet [ McCloghrie et Rose 1988] : McCloghrie K. et Rose M. «RFC Management Information Base for network management of TCP/IP-based internets» ( [ McCloghrie et Rose 1991] : McCloghrie K. et Rose M. «RFC Management Information Base for Network Management of TCP/IP-based internets: MIB-II» ( [NET-SNMP] : Site officiel de la librairie Net-SNMP ( [SOLUTOIRE] : Présentation de la librairie FLOTR ( [W3C 2004] : W3C Recommendation : Extensible Markup Language (XML) 1.0 (Fifth Edition) Recommandation du W3C sur le langage XML (

49 Livres et articles [GARNIER et SABALSKI 2008] : J.C Garnier et M. Sabalski, : «Étude et conception d'un outil de visualisation et d'administration des données issues d'un réseau de capteurs sans fils» (Rapport de projet d'école d'ingénieur ISIMA ème année) [JACQUOT, et al.2008] : A. Jacquot, J. P. Chanet, K. M. Hou, X. Diao, and J. J. Li, : "A new approach for Wireless Sensor Network management: LiveNCM," (Article présenté pour la «Second IFIP international conference on New Technologies, Mobility and Security NTMS'08, Wireless Sensor Network workshop», Tanger, Maroc, 2008)

50 Annexes Table des Annexes Annexes...I Fichier de description de la MIB...II Description de la structure de sauvegarde...xiii Structure de la base de données...xvi Captures d'écran de l'interface...xvi I

51 Fichier de description de la MIB LNCMv3 DEFINITIONS ::= BEGIN TESTDEVMIB lncmv3 $Date: 2008/05/28 12:30 UTC IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, enterprises, Integer32, TimeTicks, IpAddress FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, DateAndTime, TimeInterval FROM SNMPv2-TC; lncm3 MODULE-IDENTITY LAST-UPDATED " Z" ORGANIZATION "Cemagref Thesis" CONTACT-INFO "Aurelien JACQUOT -- 30/09/2009 Phone: Fax: [email protected] Antoine Monier [email protected] "The MIB module for managing a WSN" REVISION " Z" "The version 0.2 of this MIB." ::= { enterprises } wsn nodes sensors OBJECT IDENTIFIER ::= { lncm3 1 } OBJECT IDENTIFIER ::= { lncm3 2 } OBJECT IDENTIFIER ::= { lncm3 3 } wsn group wsnnumber OBJECT-TYPE SYNTAX INTEGER (0..255) read-only "number of WSN" ::= { wsn 1 } wsncmd OBJECT IDENTIFIER ::= { wsn 2 } group of command for the wsn group wsncmdadd OBJECT-TYPE SYNTAX INTEGER (0..255) read-write STATUS obsolete "add a WSN" ::= { wsncmd 1 } II

52 wsncmddel OBJECT-TYPE SYNTAX INTEGER (0..255) read-write "delete a WSN" ::= { wsncmd 2 } wsncmdreserve OBJECT-TYPE SYNTAX INTEGER (0..255) read-write "Get=> return a free WSN index Reserve a WSN number " ::= { wsncmd 3 } -----wsntable ---wsntable OBJECT-TYPE SYNTAX SEQUENCE OF WsnTableEntry not-accessible "A list of WSN" ::= { wsn 3 } wsntableentry OBJECT-TYPE SYNTAX WsnTableEntry not-accessible "..." INDEX {wsnid} ::= { wsntable 1 } WsnTableEntry ::= SEQUENCE { wsnid INTEGER, wsnlocation OCTET STRING, wsnname OCTET STRING, wsngateway IpAddress, wsnport INTEGER, wsnnbnodes INTEGER, wsnreservenode INTEGER } wsnid OBJECT-TYPE SYNTAX INTEGER (0..255) read-only "WSN unique Id" ::= { wsntableentry 1 } wsnlocation OBJECT-TYPE SYNTAX OCTET STRING read-write "the location of our WSN" III

53 ::= { wsntableentry 2 } wsnname OBJECT-TYPE SYNTAX OCTET STRING read-write "the name of our WSN" ::= { wsntableentry 3 } wsngateway OBJECT-TYPE SYNTAX IpAddress read-write "the gateway of the network" ::= { wsntableentry 4 } wsnport OBJECT-TYPE SYNTAX INTEGER read-write "Port numbre used to communicate with the Gw" ::= { wsntableentry 5 } wsnnbnodes OBJECT-TYPE SYNTAX INTEGER read-only "number of nodes in the network" ::= { wsntableentry 6 } wsnreservenode OBJECT-TYPE SYNTAX INTEGER read-write STATUS obsolete "reserve a node Id" ::= { wsntableentry 7 } node group nodesnumber OBJECT-TYPE SYNTAX INTEGER read-only "number of nodes" ::= { nodes 1 } nodescmd OBJECT IDENTIFIER ::= { nodes 2 } node cmd group nodescmdadd OBJECT-TYPE SYNTAX INTEGER ( ) read-write STATUS obsolete "add a livenode to the given WSN" ::= { nodescmd 1 } nodescmddel OBJECT-TYPE SYNTAX INTEGER ( ) read-write IV

54 "delete the given livenode" ::= { nodescmd 2 } nodesdesc table nodesdesctable OBJECT-TYPE SYNTAX SEQUENCE OF NodesDescTableEntry not-accessible "A list of nodes description" ::= { nodes 3 } nodesdesctableentry OBJECT-TYPE SYNTAX NodesDescTableEntry not-accessible "..." INDEX {nodedescid} ::= { nodesdesctable 1 } NodesDescTableEntry ::= SEQUENCE { nodesdescid INTEGER, nodesdescname DisplayString, nodesdesclocation DisplayString, nodesdescwsnid INTEGER, nodesdescnbsensors INTEGER, nodesdesclatitude INTEGER, nodesdesclongitude INTEGER, nodesdescaltitude INTEGER, nodesdescreservesensor INTEGER } nodesdescid OBJECT-TYPE SYNTAX INTEGER ( ) read-only "the node unique ID" ::= { nodesdesctableentry 1 } nodesdescname OBJECT-TYPE SYNTAX DisplayString read-write "name of the node" ::= { nodesdesctableentry 2 } nodesdesclocation OBJECT-TYPE SYNTAX DisplayString read-write "location of the node" ::= { nodesdesctableentry 3 } V

55 nodesdescwsnid OBJECT-TYPE SYNTAX INTEGER read-write "unique id od the WSN write new Id = try to change WSN" ::= { nodesdesctableentry 4 } nodesdescnbsensors OBJECT-TYPE SYNTAX INTEGER read-only "number of sensor in this node" ::= { nodesdesctableentry 5 } nodesdesclatitude OBJECT-TYPE SYNTAX INTEGER read-write "Latitude (integer => Float value *10000 )" ::= { nodesdesctableentry 6 } nodesdesclongitude OBJECT-TYPE SYNTAX INTEGER read-write "Longitude (integer => Float value *10000 )" ::= { nodesdesctableentry 7 } nodesdescaltitude OBJECT-TYPE SYNTAX INTEGER read-write "Altitude" ::= { nodesdesctableentry 8 } nodesdescreservesensor OBJECT-TYPE SYNTAX INTEGER read-write STATUS obsolete "reserve a sensor Id" ::= { nodesdesctableentry 9 } nodesconfigtable nodesconfigtable OBJECT-TYPE SYNTAX SEQUENCE OF NodeConfigTableEntry not-accessible "A list of nodes configurations" ::= { nodes 4 } nodesconfigentry OBJECT-TYPE SYNTAX NodesConfigTableEntry not-accessible "..." INDEX {nodesconfigid} ::= { nodesconfigtable 1 } NodesConfigTableEntry ::= SEQUENCE { nodesconfigid INTEGER, VI

56 nodesconfigstatus INTEGER, nodesconfigrole INTEGER, nodesconfigfuncmode INTEGER } nodesconfigid OBJECT-TYPE SYNTAX INTEGER ( ) read-only "Unique ID" ::= { nodesconfigentry 1 } nodesconfigstatus OBJECT-TYPE SYNTAX INTEGER{ idle (1), delay (2), main (3), sleep (4), process (5), unknown (6) } read-only "Node status : IDLE mode = no configuration, DELAY mode = the clock has a delay, MAIN mode = no response of a node during the synchronization process or battery level is critical, SLEEP mode = no response but synchronisation is ok, PROCESS mode = the node takes and treats a measure, UNKNOWN mode = no information about node (default value)" ::= { nodesconfigentry 2 } nodesconfigrole OBJECT-TYPE SYNTAX INTEGER{ master (1), bridge (2), slave (3), lost (4), unknown (6) } read-only "Self - Configuration mode active : MASTER nodes collect all slave and bridge nodes, SLAVE nodes perform and transmit data, BRIDGE node relays data between masters and performs data, LOST nodes don't have a master node, UNKNOWN nodes have no role by default" ::= { nodesconfigentry 3 } nodesconfigfuncmode OBJECT-TYPE SYNTAX INTEGER{ normal (1), battery (2), security (3), unknown (0) } read-only "Functionning mode : NORMAL mode = battery are good, BATTERY mode = the battery level is low, SECURITY mode = the battery level is critical, the node passes in FAILURE mode, stops all scheduled process, and needs a battery replacement, UNKNOWN mode = default value of a node or no information received" ::= { nodesconfigentry 4 } nodesstatetable VII

57 nodesstatetable OBJECT-TYPE SYNTAX SEQUENCE OF NodeStateTableEntry not-accessible "A list of nodes configurations" ::= { nodes 5 } nodesstateentry OBJECT-TYPE SYNTAX NodesStateTableEntry not-accessible "..." INDEX {nodesstateid} ::= { nodesstatetable 1 } NodesStateTableEntry ::= SEQUENCE { nodesstateid INTEGER, nodeslastupdate TimeTicks, nodesbattery INTEGER, nodesbatteryrate INTEGER, nodessignal INTEGER, nodessignalrate INTEGER } nodesstateid OBJECT-TYPE SYNTAX INTEGER ( ) read-only "Unique ID" ::= { nodesstateentry 1 } nodeslastupdate OBJECT-TYPE SYNTAX TimeTicks read-only "date of last change by user" ::= { nodesstateentry 2 } nodesbattery OBJECT-TYPE SYNTAX INTEGER read-only "battery level" ::= { nodesstateentry 3 } nodesbatteryrate OBJECT-TYPE SYNTAX INTEGER read-write "time between 2 battery check" ::= { nodesstateentry 4 } nodessignal OBJECT-TYPE SYNTAX INTEGER read-only VIII

58 "signal level" ::= { nodesstateentry 5 } nodessignalrate OBJECT-TYPE SYNTAX INTEGER read-write "time between 2 signal check" ::= { nodesstateentry 6 } Table of nodes transmission data nodescomtable OBJECT-TYPE SYNTAX SEQUENCE OF NodesComEntry not-accessible "A list of nodes manged by this WSN" ::= { nodes 6 } nodescomentry OBJECT-TYPE SYNTAX NodesComEntry not-accessible "" INDEX {nodescomid} ::= { nodescomtable 1 } NodesComEntry ::= SEQUENCE { nodescomid INTEGER, nodescomip IpAddress, nodescomprotocol INTEGER, nodescomchannel INTEGER, nodescompower INTEGER, nodescomtx Integer32, nodescomrx Integer32, nodescomrxerrors Integer32 } nodescomid OBJECT-TYPE SYNTAX INTEGER ( ) read-only "Unique ID" ::= { nodescomentry 1 } nodescomip OBJECT-TYPE SYNTAX IpAddress read-only "IP Address" ::= { nodescomentry 2 } IX

59 nodescomprotocol OBJECT-TYPE SYNTAX INTEGER{ zigbee (1), wifi (2), bluetooth (3), gsm (4), other (5) } read-write "comunication protocol used " ::= { nodescomentry 3 } nodescomchannel OBJECT-TYPE SYNTAX INTEGER read-write "Transmission channel" ::= { nodescomentry 4 } nodescompower OBJECT-TYPE SYNTAX INTEGER{ lowest (0), low (1), medium (2), high (3), highest (4), unknown (6) } read-write "Transmission power : Depends of the transmission device" ::= { nodescomentry 5 } nodescomtx OBJECT-TYPE SYNTAX Integer32 ( ) read-only STATUS current "..." ::= { nodescomentry 6 } nodescomrx OBJECT-TYPE SYNTAX Integer32 ( ) read-only STATUS current "..." ::= { nodescomentry 7 } nodescomrxerrors OBJECT-TYPE SYNTAX Integer32 ( ) read-only STATUS current "..." ::= { nodescomentry 8 } Update table nodesupdatetable OBJECT-TYPE SYNTAX SEQUENCE OF NodesUpdateEntry not-accessible "A list of nodes manged by this WSN" X

60 ::= { nodes 7 } nodesupdateentry OBJECT-TYPE SYNTAX NodesUpdateEntry not-accessible "" INDEX {nodesupdateid} ::= { nodesupdatetable 1 } NodesUpdateEntry ::= SEQUENCE { nodesupdateid INTEGER, nodesupdatelastupdate TimeTicks } nodesupdateid OBJECT-TYPE SYNTAX INTEGER ( ) read-only "Unique ID" ::= { nodesupdateentry 1 } nodesupdatelastupdate OBJECT-TYPE SYNTAX TimeTicks read-write "the date of the last update" ::= { nodesupdateentry 2 } Sensor group sensorsnb OBJECT-TYPE SYNTAX INTEGER read-only "number of sensors in the table" ::= { sensors 1 } sensor cmd group sensorscmd OBJECT IDENTIFIER ::= { sensors 2 } sensorscmdadd OBJECT-TYPE SYNTAX INTEGER read-write STATUS obsolete "add a sensor to the given node " ::= { sensorscmd 1 } sensorscmddel OBJECT-TYPE SYNTAX INTEGER read-write "delete the given sensor " ::= { sensorscmd 2 } XI

61 sensorstable sensorstable OBJECT-TYPE SYNTAX SEQUENCE OF SensorsEntry not-accessible "A list of nodes manged by this WSN" ::= { sensors 3 } sensorsdescentry OBJECT-TYPE SYNTAX SensorsDescEntry not-accessible "" INDEX {sensorsid} ::= { sensorstable 1 } SensorsDescEntry ::= SEQUENCE { sensorsdescid INTEGER, sensorsdescnodeid INTEGER, sensorsdesctype INTEGER, sensorsdescunit DisplayString, sensorsdescunitfactor INTEGER, sensorsdescvalue INTEGER, sensorsdescvaluerate INTEGER, sensorsdescstatus INTEGER } sensorsdescid OBJECT-TYPE SYNTAX INTEGER ( ) read-only "sensor Unique ID" ::= { sensorsdescentry 1 } sensordescnodeid OBJECT-TYPE SYNTAX INTEGER ( ) read-only "node Unique ID" ::= { sensorsdescentry 2 } sensorsdesctype OBJECT-TYPE SYNTAX INTEGER{ temperature (0), humidity (1), pressure (2), light (3), wind (4), other (6) } read-write XII

62 "type of mesure given by the sensor ::= { sensorsdescentry 3} " sensorsdescunit OBJECT-TYPE SYNTAX DisplayString read-write "sensor unit " ::= { sensorsdescentry 4} sensorsdescunitfactor OBJECT-TYPE SYNTAX INTEGER read-write "you need to multiply the sensorvalue by this number in order to have the good value " ::= { sensorsdescentry 5} sensorsdescvalue OBJECT-TYPE SYNTAX INTEGER read-only "the value given by the sensor " ::= { sensorsdescentry 6} sensorsdescvaluerate OBJECT-TYPE SYNTAX INTEGER read-write "time between 2 mesures ::= { sensorsdescentry 7} " sensorsdescstatus OBJECT-TYPE SYNTAX INTEGER { ok (1), sensorfailure (2), nodefailure(3), unknown(4) } read-only "status of the sensor: ok: normal mode Sensor failure : the sensor isn t working nodefailure: the node batteries are too low or the agent can't reach the node unknown: (default value) no information " ::= { sensorsdescentry 8} END Description de la structure de sauvegarde //TODO creer ici une xml_table par table utilisee dans le fichier XML/ agent snmp //l'argument de new_xml_table correspond aux nombre de champs a l'interieur de la XMLTable xml_table *lstwsntable=new_xml_table(1); xml_table *wsntable=new_xml_table(2); xml_table *wsndesctable=new_xml_table(5); xml_table *wsnnodetable=new_xml_table(1); xml_table *nodetable=new_xml_table(6); XIII

63 xml_table xml_table xml_table xml_table xml_table xml_table xml_table xml_table * * * * * * * * nodessensorstable=new_xml_table(1); nodeupdatetable=new_xml_table(1); nodecomtable=new_xml_table(7); nodestatetable=new_xml_table(5); nodeconfigtable=new_xml_table(3); nodedesctable=new_xml_table(6); sensortable=new_xml_table(1); sensordesctable=new_xml_table(6); //TODO ajouter chaque xml_table dans ce test if(lstwsntable!=null && wsntable!=null &&wsndesctable!=null && wsnnodetable!=null && nodetable! =NULL&& nodestatetable!=null && nodeconfigtable!=null &&nodedesctable!=null && sensortable!=null && sensordesctable!=null) { //list wsn XML_NEW_TABLE_DESC(lstWsnTable); XML_TABLE_ADD_SEQ("WSN",wsnTable,xml_init_wsn,2); //description d un wsn XML_NEW_TABLE_DESC(wsnTable); XML_TABLE_ADD_TABLE("WSNDesc",wsnDescTable,5); XML_TABLE_ADD_TABLE("WSNNodes",wsnNodeTable,1); //table wsndesc XML_NEW_TABLE_DESC(wsnDescTable); XML_TABLE_ADD_STRING("WSNDescLocation",wsn_container_set_desc_location,wsn_container_get_desc_loca tion); XML_TABLE_ADD_STRING("WSNDescName",wsn_container_set_desc_name,wsn_container_get_desc_name); XML_TABLE_ADD_STRING("WSNDescGw",wsn_container_set_desc_gw,wsn_container_get_desc_gw); XML_TABLE_ADD_INTEGER("WSNDescPort",wsn_container_set_desc_port,wsn_container_get_desc_port); XML_TABLE_ADD_INTEGER("WSNDescNbNodes",wsn_container_set_desc_nbNodes,wsn_container_get_desc_n bnodes); //table contenant la liste des noeuds d'un WSN XML_NEW_TABLE_DESC(wsnNodeTable); XML_TABLE_ADD_SEQ("node",nodeTable,xml_init_node,6); //nodetable XML_NEW_TABLE_DESC(nodeTable); XML_TABLE_ADD_TABLE("nodeDesc",nodeDescTable,6); XML_TABLE_ADD_TABLE("nodeConfig",nodeConfigTable,3); XML_TABLE_ADD_TABLE("nodeState",nodeStateTable,5); XML_TABLE_ADD_TABLE("nodeCom",nodeComTable,7); XML_TABLE_ADD_TABLE("nodeUpdate",nodeUpdateTable,1); XML_TABLE_ADD_TABLE("nodeSensors",nodesSensorsTable,1); //nodedesctable XML_NEW_TABLE_DESC(nodeDescTable); XML_TABLE_ADD_STRING("nodeDescLocation",nodes_container_set_desc_location,nodes_container_get_desc_ location); XML_TABLE_ADD_STRING("nodeDescName",nodes_container_set_desc_name,nodes_container_get_desc_nam e); XML_TABLE_ADD_INTEGER("nodeDescLatitude",nodes_container_set_desc_latitude,nodes_container_get_desc _latitude); XML_TABLE_ADD_INTEGER("nodeDescLongitude",nodes_container_set_desc_longitude,nodes_container_get_d esc_longitude); XML_TABLE_ADD_INTEGER("nodeDescAltitude",nodes_container_set_desc_altitude,nodes_container_get_desc _altitude); XML_TABLE_ADD_INTEGER("nodeDescNbSensors",nodes_container_set_desc_nbSensors,nodes_container_get _desc_nbsensors); XIV

64 //nodeconfigtable XML_NEW_TABLE_DESC(nodeConfigTable); XML_TABLE_ADD_INTEGER("nodeConfigStatus",nodes_container_set_config_status,nodes_container_get_confi g_status); XML_TABLE_ADD_INTEGER("nodeConfigRole",nodes_container_set_config_role,nodes_container_get_config_rol e); XML_TABLE_ADD_INTEGER("nodeConfigMode",nodes_container_set_config_mode,nodes_container_get_config _mode); //nodestatetable XML_NEW_TABLE_DESC(nodeStateTable); XML_TABLE_ADD_INTEGER("nodeStateLastUpdate",nodes_container_set_state_last_update,nodes_container_g et_state_last_update); XML_TABLE_ADD_INTEGER("nodeStateBattery",nodes_container_set_state_battery,nodes_container_get_state _battery); XML_TABLE_ADD_INTEGER("nodeStateBatteryRate",nodes_container_set_state_batteryRate,nodes_container_ get_state_batteryrate); XML_TABLE_ADD_INTEGER("nodeStateSignal",nodes_container_set_state_signal,nodes_container_get_state_si gnal); XML_TABLE_ADD_INTEGER("nodeStateSignalRate",nodes_container_set_state_signalRate,nodes_container_get _state_signalrate); //nodecomtable XML_NEW_TABLE_DESC(nodeComTable); XML_TABLE_ADD_STRING("nodeComAddr",nodes_container_set_addr,nodes_container_get_addr); XML_TABLE_ADD_INTEGER("nodeComProtocol",nodes_container_set_protocol,nodes_container_get_protocol); XML_TABLE_ADD_INTEGER("nodeComChannel",nodes_container_set_power,nodes_container_get_power); XML_TABLE_ADD_INTEGER("nodeComPower",nodes_container_set_channel,nodes_container_get_channel); XML_TABLE_ADD_INTEGER("nodeComTx",nodes_container_set_tx,nodes_container_get_tx); XML_TABLE_ADD_INTEGER("nodeComRx",nodes_container_set_rx,nodes_container_get_rx); XML_TABLE_ADD_INTEGER("nodeComRxErrors",nodes_container_set_rx_errors,nodes_container_set_rx_errors) ; //nodeupdate XML_NEW_TABLE_DESC(nodeUpdateTable); XML_TABLE_ADD_INTEGER("nodeUpdateLastUpdate",nodes_container_set_update_last_update,nodes_contain er_get_update_last_update); //nodessensorstable XML_NEW_TABLE_DESC(nodesSensorsTable); XML_TABLE_ADD_SEQ("sensor",sensorTable,xml_init_sensor,1); //sensor table XML_NEW_TABLE_DESC(sensorTable); XML_TABLE_ADD_TABLE("sensorDesc",sensorDescTable,6); XML_NEW_TABLE_DESC(sensorDescTable); XML_TABLE_ADD_INTEGER("sensorType",sensor_container_set_desc_type,sensor_container_get_desc_type); XML_TABLE_ADD_STRING("sensorUnit",sensor_container_set_desc_unit,sensor_container_get_desc_unit); XML_TABLE_ADD_INTEGER("sensorUnitFactor",sensor_container_set_desc_factor,sensor_container_get_desc_f actor); XML_TABLE_ADD_INTEGER("sensorValue",sensor_container_set_desc_value,sensor_container_get_desc_value) ; XML_TABLE_ADD_INTEGER("sensorValueRate",sensor_container_set_desc_valueRate,sensor_container_get_de sc_valuerate); XML_TABLE_ADD_INTEGER("sensorStatus",sensor_container_set_desc_status,sensor_container_get_desc_stat us); //fin de la description des tables } XV

65 Structure de la base de données Wsn WsnId Sensor 0,N SensorId Contient 0,N 1,1 Mesure Valeur Facteur 1,1 1,N LiveNode Contient NodeId Latitude Longitude Altitude Variance Historique Date 0,N Captures d'écran de l'interface Affichage d'un réseau de capteurs XVI

66 Affichage d'un LiveNode Affichage d'un capteur XVII