Coconode

Interface Coconode

Git us !

COCONODE on Git

Contexte

Ce projet se place dans la continuité du travail de Malisa VUCINIC - thésard à l'équipe DRAKKA (LIG). Durant son projet de fin d'études, il a écrit un programme permettant de simuler le comportement de capteurs disposés dans une salle/un bâtiment. Le comportement étant basé sur deux protocoles de routage de données (RPL ou LOADng). Cependant, ce programme ne permet pas d'automatiser l'exécution d'un grand nombre de simulation, ce qui est nécessaire pour faire des statistiques. De plus, les données obtenues ne sont pas interprétées mais seulement regroupées de manière cohérente par un parseur. L’utilisateur est obligé de traiter lui-même ces données via un logiciel tiers d’analyse.

Motivations

Industrie, sécurité, transport, santé... Les capteurs sont de plus en plus utilisés dans notre quotidien. Organisé en réseau, ces capteurs permettent de récolter une multitude de données de toutes sortes. La majorité des applications impliquent le déploiement d'un grand nombre de nœuds (capteurs) dans une zone donnée. Cela implique un minimum de traitement pour communiquer entre eux et/ou avec une entité capable de les traiter. Cependant, une grande partie de ces équipements ne seront pas reliés à un réseau électrique ni à un réseau informatique à cause du coût d’installation et de raccordement. C’est pourquoi ils seront alimentés grâce à une batterie et devront communiquer via des transmissions radio. Le coût faible du déploiement et la durée de vie très longue des capteurs impliquent des contraintes matérielles liées à la mémoire, aux traitements et à la consommation d’énergie. La communication en est impactée car il faut consommer le moins possible tout en communiquant avec les autres. Il faut donc utiliser des protocoles de communications optimisés pour lui permettre d’être autonome tout en restant joignable via Internet. En effet, IPv6 est performant pour délivrer les données et router celle-ci, quel que soit le réseau, d’un émetteur vers un récepteur. De plus, au vu du nombre de capteurs déployés, il est nécessaire d’avoir une grande plage d’adresses disponible. Cependant, IP a été conçu pour des réseaux très puissants et possède, par exemple, des entêtes de tailles trop grandes pour un capteur. C’est pourquoi l’IETF a créé un standard nommé 6LowPAN qui définit des mécanismes d’encapsulation et de compression d’en-têtes permettant d’envoyer des paquets IPv6. Afin de pouvoir tester et expérimenter de tels protocoles, plusieurs méthodes sont possibles : théorie, simulation, modélisation. La théorie permet d’avoir un résultat rapidement par rapport aux autres méthodes. La modélisation est la meilleure solution par rapport à la précision des résultats. Cependant, la première n’est pas assez représentative par rapport à des évènements censés être aléatoires sur les nœuds et la deuxième coûte cher et ne supporte pas les changements. La simulation est un bon compromis car il est possible de la reproduire dans le temps en modifiant les paramètres facilement tout en contrôlant les dépenses liées au coût de développement. Un des désavantages de la simulation est que certains phénomènes physiques sont très difficiles (voire impossible) à définir.

Aujourd'hui, plusieurs systèmes d'exploitation sont utilisés sur ces capteurs pour pouvoir faire des opérations liées aux communications, aux récupérations de données et aux agrégations de celles-ci. Contiki est l'un des plus utilisés. C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé Cooja pour simuler le comportement d’un réseau de capteurs par rapport aux algorithmes de routages des paquets, de la disposition des capteurs dans le réseau, les propriétés de l’environnement… Ce simulateur est fourni par l'organisation qui développe Contiki pour pouvoir émuler cet OS au niveau hardware et ainsi pouvoir réutiliser les codes simulés sur des capteurs réels.

Utilisateurs cibles

Les utilisateurs cibles sont principalement des chercheurs, stagiaires utilisant le simulateur Cooja. Ensuite, les autres utilisateurs seront les personnes lambda voulant utiliser ce logiciel car il sera diffusé avec une licence libre.

Description

L'objectif est faire un logiciel permettant de configurer et de répéter une expérience, de suivre les différentes étapes de l'expérience lors de la simulation et d'interpréter les résultats obtenus. Le logiciel doit être « user friendly », avec une interface graphique. De plus, dans la mesure du possible, on essayera de le rendre générique, c'est à dire utilisable pour d'autres protocoles que les deux testés dans le cadre de ce projet. Il sera ainsi susceptible d'être réutilisé pour d'autres études.

Le travail à réaliser peut être présenté en trois modules :

• Partie configuration : Saisir des paramètres voulus pour la simulation, le nombre de simulations voulues pour pouvoir faire des statistiques associées, construction de fichier de configuration .xml (scénario). Cette partie pourra aussi afficher la configuration/répartition des capteurs dans la salle/du bâtiment : une carte de la salle affiche leur position.
• Partie suivi de la simulation (qui peut durer très longtemps, des semaines) : donne le statut de la simulation. Par exemple : Simulation avec COOJA à partir du scénario (répéter plusieurs fois pour augmenter la confiance)
• Partie résultat : elle peut être décomposée en 2 sous parties :
  • Choisir les données que l'on veut afficher (choix des différents graphes avec différents paramètres, choix de l'échelle, observation d'une simulation particulière ou application d'une fonction statistique aux données particulière)
  • Afficher les graphes et les données de sortie. Résultat + script pour analyser le résultat.

L'outil actuel se fait en plusieurs étapes séparées par des lignes de commande tapées manuellement. Ceci n'est pas automatisé et est destiné principalement à l'utilisateur expérimenté.  Le but de notre projet est de développer un outil qui automatise le processus de simulation comprenant la configuration, l'exécution et l'analyse de résultat sous forme d'une interface utilisateur interactive. Il sera important de concevoir une architecture flexible, modulable et facile à étendre pour le développement ultérieur.

Fonctionnalités à développer

Product Backlog

Product Backlog

Nom	Description	Complexité	Priorité
Configuration	L'utilisateur veut choisir la configuration qu'il veut pour l'expérience (protocole, nombre de simulations, loi de probabilité des événements...)	12	30
Monitoring	L'utilisateur surveille l'état de l'exécution de la simulation en temps réel.	10	5
Interruption	L'utilisateur interrompt l’expérience.	3	20
Répétitions	L'utilisateur détermine le nombre de fois qu'une simulation est répétée durant une expérience (pour augmenter l'intervalle de confiance).	2	30
Topologie	L'utilisateur voit la topologie du réseau (répartition des capteurs dans la salle / le bâtiment)	4	15
Résultat	L'utilisateur observe en temps réel (unité de temps=une simulation) les graphes qu'il voulait lors de la configuration.	18	35
Scheduler	L'utilisateur peut programmer des périodes d'exécution pour son expérience (le simulateur n'exécute l'expérience que la nuit, le PC a plus de ressources le journée)	30	20
Format	Les fichiers d'entrées / sorties doivent être génériques	20	25

Aspects Techniques

• Langage C et bibliothèque graphique GTK (et gestion des threads)
• Bibliothèques dynamiques
• Compilation du code utilisateur pour la topologie
• Basé sur le noyau Cooja avec Java Native Interface (JNI)
• Gnuplot
• Json-glib

L'équipe

Ce projet s'inscrit dans un cadre pédagogique précis. Un encadrant joue le rôle de client, un autre de tuteur. Le projet s'effectue en groupe et met en place des méthodes de gestion de projet.

Encadrants

Clients

• Bernard Tourancheau
• Mališa Vučinić

Tuteur

• Didier Donsez

Etudiants

• Chef de projet : Noé-Jean Caramelli
• Minh Quan Ho
• Florian Lévêque

Répartitions des tâches

Répartition des tâches

Le produit

Architecture logicielle

Architecture Coconode

Coconode est composé de 4 parties différentes :

• Interface Graphique
• Architecture interne
  • Configuration
  • Exécution
  • Statistique

L'architecture se base sur des modules existants (Générateur de topologie et noyau de simulation Cooja) utilisés dans l'outil existant. Ces modules ont du être intégré dans l'architecture pour pouvoir les réutiliser dans le nouvel outil. La séparation des différentes parties a été faite pour isoler chaque partie réalisant les mêmes tâches. Cela facilite le développement et les modification future. Cela permet aussi l'utilisation de threads pour paralléliser les différents traitement, pour ne pas bloquer la GUI lors d'un gros traitement dans l'exécution ou dans la partie statistique par exemple.

La GUI est liée à chaque partie car elle est utilisée en entrée pour que l'utilisateur puisse définir les données de simulation (voir partie Configuration) et en sortie pour que le contrôleur et l'affichage statistique puisse afficher des retours (voir Partie Exécution et Statistique).

Interface Graphique

Cette interface basée sur la librairie GTK permet à l'utilisateur d'interagir avec le noyau de simulation Cooja.

Architecture interne

L'architecture interne de Coconode comprend trois parties :

Partie Configuration

Configuration

• Personnalisation de la simulation :

1. Durée de simulation
2. Planification
3. Nombre de simulations
4. Choix du protocole de routage (Ici c'est load, un protocole de routage français)

Cette partie est lié au module Jsonner qui permet d'exporter ou importer ces paramètres au format JSON.

Générateur de topologie

• Génération et visualisation de la topologie :

1. Sélectionner les paramètres de la topologie :
   1. Nombre de noeuds
   2. Pourcentage de capteurs (qui récupèrent une donnée physique)
   3. Pourcentage d'actuateurs (qui réalisent une action)
   4. Sélectionner les fichiers utilisateurs qui génèrent une topologie selon un modèle précis (représentation d'une maison ...)
2. Générer la topologie et visualiser le résultat

Après avoir entré toutes les informations précédentes et généré une topologie de réseaux de capteurs, ces informations seront passées au module d'exécution qui va la prendre en charge et l'exécuter en temps voulu.

Partie Exécution

Scheduler

L'exécution des simulations doit se faire dans un ordre précis défini grâce à l'interface. Cet ordre mélange un ordre temporel et un ordre de définition, en effet, l'utilisateur peut définir un délai de début de simulation en plus de l'ordre de définition de celle-ci. Il faut donc avoir une file d'attente des simulations. La file d'attente est une file asynchrone accessible par l'interface et par le contrôleur. Le contrôleur va l'utiliser pour ordonnancer les simulations et gérer l'ordre de départ de chaque simulation.

Ensuite, le contrôle doit être fait en temps réel. L'interface doit être toujours disponible pour l'utilisateurs afin qu'il puisse contrôler les simulations. Comme Cooja est un outil Java, il a fallu utiliser une bibliothèque nommé Java Native Interface qui permet de faire l'interfaçage entre du code C et du code Java. Cela permet de créer une JVM personnalisée pour exécuter le noyau Cooja. Il est donc possible d'avoir un contrôle total de Cooja en accédant aux différentes classes présentes.

Monitor

L'utilisateur aura un retour d'avancement de la simulation en cours ainsi qu'une liste des simulations à venir dans l'ordre de départ.

Partie Statistique

Scheduler

Méthodes de gestion de projet

Nous utilisons d'une part une méthode de gestion de projets classique avec un Chef de projet, mais d'autre part, nous utilisons la méthode Agile/Scrum pour le développement du logiciel.

Scrum Master

Nous choisissions un scrum master fixe. En effet, nous avons un chef de projet qui a pour rôle d'être le point central de communication avec l'équipe. Or le scrum master est censé isoler l'équipe de l'extérieur. Si on prend un scrum master tournant, on aura un chef de projet, qui ne sera pas isolé de l'extérieur à cause de son rôle et qui ne sera pas scrum master. Ce n'est pas logique. Nous choisissons donc un scrum master fixe qui sera le chef de projet par soucis de cohérence.

Points avec les clients

Nous feront un point par semaine avec Bernard Tourancheau et Malisa Vucinic. Le rendez-vous hebdomadaire est fixé tous les jeudis à 15h. Ces rendez-vous serviront à faire le point sur l'avancement et à régler les éventuels problèmes qui pourraient nous bloquer. Un rendez-vous tous les 15 jours serait trop espacé en cas de problème.

Durée du stage

Le projet commence le 4 février et termine le 15 mars. Nous avons en réalité eu deux réunions avant le 4 février, mais nous n'avions que très peu de temps libre pour le projet la semaine d'avant. La semaine du 18 mars est celle de la soutenance du projet. Nous ne savons pas la date exacte de soutenance, nous ne plaçons donc pas de tâche

Sprints

Nous choisissons de faire des sprints de deux semaines. Cela nous semble un bon compromis entre un sprint trop long pendant lequel les tâches serait trop complexes et les problèmes s'accumuleraient, et un sprint trop court où nous n'aurions pas assez avancé pour que le sprint soit profitable, malgré le temps qu'il nous prend.

Sprint 3 :11 Mars au 22 Mars

Sprint Backlog

Product Backlog

Nom	Valeurs/Importance	Estimation initiale
Scheduler	20	15
Monitoring	5	3
Interruption d'une simulation	20	10
Observation des résultats	35	8
Contrôle d'une simulation	35	17
Validation du logiciel	30	15
Portabilité de l'outil	20	15

Sprint retrospective

• Plus:
  • Point de vue de conception et de technique avancé
  • Connaissances de JNI
  • Développement boosté
  • Reprise de motivation

• A améliorer:
  • Documentation
  • Test de validation

• Moins:
  • Bugs technique complexe
  • Manque de réactivité aux bugs
  • Deadline approché

Burndown Chart

Burndown Chart Sprint 2

Sprint 2 :18 Février au 8 Mars

Sprint Backlog

Product Backlog

Nom	Valeurs/Importance	Estimation initiale
Générateur de topologie	15	15
Configuration des simulations	30	10
Importer/Exporter données	25	20
Contrôle d'une simulation	35	25
Observation des résultats	35	25

Sprint retrospective

• Plus:
  • Entraide lors de bugs
  • Séparation des modules facilitant le développement

• A améliorer
  • Compréhension de la hiérarchie et fonctionnement de Cooja

• Moins:
  • Répartition du temps
  • Bugs techniques et complexe.
  • Perturbation du rythme de travail lié à:
    • Problème de santé
    • Manque de motivation
    • Problème de l'ordinateur

Burndown Chart

Burndown Chart Sprint 2

Sprint 1 : 29 Janvier au 15 Février

Sprint Backlog

Product Backlog

Nom	Valeurs/Importance	Estimation initiale
Cahier des charges	13	15
Architecture	13	25
Prototype de l'IHM	8	25
Prise en main de l'outil	10	10

Sprint retrospective

• Plus:
  • Rédaction du cahier des charges
  • Utilisation de GIT

• A améliorer
  • Répartition des tâches
  • Mise à jours de Trello

• Moins:
  • Prise en main de l'outil laborieuse
  • Daily stand up oubliée

Burndown Chart

Burndown Chart Sprint 1

Outils de suivi

Pour permettre de suivre l'avancement d'un sprint du projet, nous utilisons des outils de Scrum :

• Todo-List ;
• Burn down chart.

Tests et validation

Comme nous utilisons la méthode Scrum pour la gestion de projet, chaque développeur fera des tests « unitaires » sur les stories qu'il développera. Ils vont permettre d'assurer de l’intégrité du code pour certaines fonctionnalités, la bonne qualité du code. Ils ne permettent pas de vérifier si le code répond aux besoins du client. Les tests permettant de garantir au product owner la fiabilité et le respect des spécifications sont les tests d'acceptation. Chaque test sera développé ou défini grâce aux conditions de satisfaction données par celui-ci.

Choix non fonctionnels

Licence

Le code sera placé sous la licence libre GNU GPL afin de permettre au projet d'être réutilisé et amélioré. La documentation et autres ressources éventuellement créées pour le projet seront placées sous licence Creative Commons CC-BY-NC-SA afin de permettre également une réutilisation et une évolution libres.

Gestionnaire de version

Nous choisissons GIT, un gestionnaire de version récent, évolué et de plus en plus répandu. C'est le gestionnaire de version déjà utilisé pour le projet.

Documentation

Nous prévoyons différents éléments de documentation pour permettre une bonne continuité du projet.

Documents de conception

• La documentation sera séparée en plusieurs fichiers :
  • Conception IHM ;
  • Conception système (architecture, librairies, technologies).

Manuels

• Manuel développeur ;
• Manuel utilisateur.

Génération automatique de documentation sur le code

Nous utiliserons un générateur de documentation capable de produire une documentation logicielle à partir du code source du programme, comme Doxygen.

Convention de codage

• Indentation obligatoire (utilisation du caractère tabulation) ;
• L'accolade ouvrante doit être placée à la ligne suivante ;
• Les commentaires doivent être écrits en anglais ;
• Tous les fichiers doivent être codés au format UTF-8 ;
• Les lignes ne doivent (dans la mesure du possible) pas dépassées 80 caractères ;
• Le nom des fonctions seront plutôt des verbes, les variables seront des noms (en anglais) ;

Exemples :

• • Procédure : draw_something ;
  • Variable : a_variable ;
  • Constante : A_CONSTANT.
• Chaque fonction doit être commenté selon deux règles :
  • Une explication détaillée de l'utilité de la fonction doit être placé au dessus du corps de la fonction ;
  • Chaque ligne de code complexe doit être commentée .
• Chaque fonction ne doit (dans la mesure du possible) n'implémenter qu'une seule tâche.

TODO

• Script to parse COOJA log in to GNUplot format.
• Validation test
• Integrate Statistic module into Coconode (or add callback to launch Statistic module from Coconode)