Soutenance mémoire
LES RÉSEAUX DE CAPTEURS SANS FIL
Agrégation de données dans les réseaux de capteurs
Dans les capteurs, la problématique principale concerne la consommation d’énergie : en effet, ces derniers doivent rester opérationnels le plus longtemps possibles, comme il n’est pas possible de recharger leur énergie ni changer les piles il est nécessaire d’économiser au maximum l’énergie consommée par ces derniers. On estime que la transmission des données d’un capteur représente environ 70% de sa consommation d’énergie. De plus, les réseaux de capteurs étant assez denses en général, cela signifie que des noeuds assez proches en terme de distance (voisins) peuvent capter les mêmes données et donc il apparaît nécessaire d’introduire le mécanisme d’agrégation de données afin d’éviter la duplication d’information au sein du réseau de capteurs et donc de préserver leur énergie et d’augmenter la durée de vie du réseau. L’agrégation est une technique utilisée pour réduire la transmission d’informations redondantes et consiste à remplacer les lectures individuelles de chaque capteur par une vue globale, collaborative sur une zone donnée (clustering), et Avec cette technique, les noeuds intermédiaires agrègent l’information reçue de plusieurs sources. Cette technique est connue aussi sous le nom de fusion de données.
Présentation de TinyOS
L’objectif des environnements exécutifs est de fournir une couche d’abstraction au moment du développement, avec la possibilité d’écrire un code portable et réutilisable, sans perdre de performance au moment de l’exécution puisque l’application monolithique exploite au mieux les ressources disponibles en étant statique [GG10]. TinyOS est un système principalement développé et soutenu par l’université américaine de Berkeley en Californie et est devenu le standard de facto lequel le propose en téléchargement sous la licence BSD, une licence libre utilisée pour la distribution de logiciels en assurant le suivi. Ainsi, l’ensemble des sources sont disponibles pour de nombreuses cibles matérielles [SA10].
TinyOS est un système d’exploitation open source spécialement conçu pour les applications embarquées et plus précisément les réseaux de capteurs sans-fil. Sa conception a été entièrement réalisée en NesC, langage orienté composant syntaxiquement proche du C [UC04]. La particularité principale de cet OS est sa taille extrêmement réduite en termes de mémoire (quelques kilo-octets seulement), grâce à une architecture basée sur une association de composants, réduisant ainsi la taille du code nécessaire à sa mise en place. Ceci permet le respect des contraintes de mémoire qu’observent les réseaux de capteurs. La bibliothèque des composants de TinyOS est particulièrement complète puisqu’on y retrouve des protocoles de réseaux, des pilotes de capteurs et des outils d’acquisition de données. L’ensemble des composants peut être utilisé tel quel ou adapté à une application précise. De plus, en s’appuyant sur une fonction événementielle, TinyOS propose à l’utilisateur un modèle de programmation orienté évènement ainsi qu’une gestion très précise de la consommation du capteur et permet de mieux s’adapter à la nature aléatoire de la communication sans fil entre les interfaces physiques [KP09]. Un programme s’exécutant sur TinyOS est constitué d’une sélection de composants systèmes et de composants développés spécifiquement pour l’application à laquelle il sera destiné (mesure de température et du taux d’humidité comme c’est le cas de notre application…etc.) [TA08].
Propriétés de TinyOS
Le fonctionnement d’un système basé sur TinyOS s’appuie sur la gestion des évènements. Ainsi, l’activation des tâches, leur interruption ou encore la mise en veille du capteur s’effectue à l’apparition d’évènements, ceux-ci ayant la plus forte priorité. Ce fonctionnement évènementiel s’oppose au fonctionnement dit temporel où les actions du système sont gérées par une horloge donnée [YM08]. TinyOS a été programmé en langage NesC, le caractère préemptif d’un système d’exploitation précise si celui-ci permet l’interruption d’une tâche en cours. TinyOS ne gère pas ce mécanisme de préemption entre les tâches mais donne la priorité aux interruptions matérielles. Ainsi, les tâches entre-elles ne s’interrompent pas mais une interruption peut stopper l’exécution d’une tâche. Lorsqu’un système est dit « temps réel » celui-ci gère des tâches caractérisées par des priorités et par des échéances à respecter dictées par l’environnement externe. Dans le cas d’un système strict, aucune échéance ne tolère des dépassements contrairement à un système temps réel mou. TinyOS se situe au-delà de ce second type car il n’est pas prévu pour avoir un fonctionnement temps réel. TinyOS a été conçu pour réduire au maximum la consommation en énergie du capteur. Ainsi, lorsqu’aucune tâche n’est active, il se met automatiquement en veille.
TOSSIM
TOSSIM permet de simuler le comportement d’un capteur au sein d’un réseau de capteurs, il est un simulateur discret basé sur la programmation par événement, de même qu’il est conçu et désigné pour simuler les réseaux de capteurs qui utilisent la plateforme TinyOS. Le principal but de TOSSIM est de créer une simulation très proche de ce qui ce passe dans ces réseaux dans le monde réel. TOSSIM simule le comportement des applications de TinyOS à un niveau très bas. Le réseau est simulé au niveau des bits et chaque interruption dans le système est capturée. TOSSIM fourni deux modèles de radios pour la communication : Le modèle par défaut « simple » où les paquets sont transmis dans le réseau sans aucune erreur et ils sont reçus par chaque noeud. Avec ce modèle il est ainsi possible que deux noeuds différents peuvent envoyer un paquet en même temps avec la conséquence que ces deux paquets seront alors détruit à cause du chevauchement des signaux. Le deuxième modèle est le modèle « lossy », dans ce modèle les noeuds sont placés dans un graphe direct formé d’un couple (a, b) ce qui signifie qu’un paquet envoyé par le noeud a peut être été reçu par le noeud b [WZ06]. TOSSIM est équipé aussi d’un simulateur graphique TinyViz. Cette application est équipée par plusieurs API plugins qui permet d’ajouter plusieurs fonctions à notre simulateur comme par exemple contrôler les entrées de notre radio ou bien suivre la dépense d’énergie en utilisant un autre simulateur qui s’appelle PowerTOSSIM [BA11].
Commentaires sur NesC et TinyOS Plusieurs remarques peuvent être faites sur TinyOS et le langage NesC au coeur de ce système événementiel. Tout d’abord on ne constate que la conception d’un code séquentiel simple qui nécessite l’emploi d’une structure rigide et complexe. Certes, la modularité est forte ce qui favorise l’abstraction et la réutilisabilité du code. La programmation modulaire laisse entendre une réutilisabilité forte des modules pour concevoir des applications rapidement, cela est effectivement très simple dans le cas d’une réutilisation des plates-formes développées par les concepteurs de TinyOS (plate-forme Mica2, MicaZ, etc.). Dans le cas d’un portage de TinyOS vers d’autres plates-formes, cela devient alors plus difficile parce que la programmation en NesC événementielle est particulièrement ardue. Les traitements doivent le plus souvent être décrits sous forme de machines d’états ce qui n’est pas naturel. Pour illustrer cela, un code de modules par exemple, qui ne fait qu’invoquer de façon séquentielle trois sous-procédures, nécessite une machine d’état complète et le code résultant est très lourd. De plus, une application relativement simple nécessite tout de même un grand nombre de composants simples et le nombre d’interfaces reliant ces composants est rapidement très grand. NesC est un langage de programmation qui présente de grands avantages pour le développement d’applications pour des systèmes embarqués, et particulièrement pour les réseaux de capteurs sans fil. Celui-ci apporte des outils pour une bonne programmation d’applications, d’abord en abstrayant les caractéristiques de modularité que présentent les réseaux de capteurs, et en suite en facilitant la mise en oeuvre de programmes pour ces systèmes.
Le compilateur qui génère un code exécutable à partir de ce langage de description NesC effectue des opérations automatiques qui ne peuvent permettre d’explorer des optimisations mémoire les plus fines. C’est la seconde approche qu’on peut faire à TinyOS : une sous-optimalité qui est due à l’utilisation d’un langage de description intermédiaire transformé de façon automatique par un compilateur. Nous considérons que TinyOS est fortement lié aux plateformes de la société Crossbow ce qui leur permet d’offrir un package matériel et logiciel flexible pour l’étude de mécanismes de haut-niveau, mais nous pensons que la rigidité de la programmation et le fait de se reposer sur la qualité du compilateur pour l’obtention de codes performants n’est pas le meilleur point de départ pour la conception d’un système extrêmement contraint en mémoire et en particulier en mémoire RAM.
|
Table des matières
INTRODUCTION GÉNÉRALE
CHAPITRE I :GÉNÉRALITÉS SUR LES RÉSEAUX DE CAPTEURS SANS FIL
1.INTRODUCTION
2.HISTOIRE DES RÉSEAUX DE CAPTEURS
3.PRÉSENTATION DES RÉSEAUX DE CAPTEURS
3.1 DÉFINITION D’UN CAPTEUR
3.2 DÉFINITION D’UN RCSF OU WSN (WIRELESS SENSOR NETWORK)
3.3 LES SOUS-SYSTÈMES D’UN NOEUD
3.3.1 Sous système de calcul
3.3.2 Sous système de communication
3.3.3 Sous système de capteurs
3.3.4 Sous système de génération de courant
4.ARCHITECTURE DE COMMUNICATION DANS LES RÉSEAUX DE CAPTEURS
5.TYPES DE RÉSEAUX DE CAPTEURS SANS FIL
5.1 RÉSEAUX DE POURSUITE
5.2 RÉSEAUX DE COLLECTION DES DONNÉES D’ENVIRONNEMENT
5.3 RÉSEAUX DE SURVEILLANCE ET SÉCURITÉ
6.FONCTIONNEMENT D’UN RÉSEAU DE CAPTEURS
7.TOPOLOGIES DES RÉSEAUX DE CAPTEURS
7.1 TOPOLOGIE EN ÉTOILE
7.2 TOPOLOGIE EN TOILE (MESH NETWORK)
7.3 TOPOLOGIE HYBRIDE
8.LES SYSTÈMES D’EXPLOITATION POUR LES RÉSEAUX DE CAPTEURS
8.1 TINYOS
8.2 MOS
8.3 SOS
9.TECHNOLOGIES UTILISÉS
9.1 BLUETOOTH / IEEE 802.15.4
9.2 ZIGBEE
9.3 ALGORITHMES DE ROUTAGE
9.4 DASH 7 / ISO/IEC 18000-7
10.EXEMPLES SUR LES CAPTEURS
11.APPLICATIONS
12.AGRÉGATION DE DONNÉES DANS LES RÉSEAUX DE CAPTEURS
13.LES ATTAQUES SUR LES RÉSEAUX DE CAPTEURS :
14.CARACTÉRISTIQUES ET LIMITES DES RÉSEAUX DE CAPTEURS
14.1 CARACTÉRISTIQUES
14.2 LIMITES
CONCLUSION
CHAPITRE II :MISE EN PLACE DE LA PLATEFORME TINYOS
1.PROBLÉMATIQUE
2.INTRODUCTION
3.LE SYSTÈME D’EXPLOITATION POUR LES RCSF : TINYOS
3.1 HISTORIQUE DE TINYOS
3.2 PRÉSENTATION DE TINYOS
3.3 ARCHITECTURE GÉNÉRALE DES CIBLES UTILISANT TINYOS
3.4 PROPRIÉTÉS DE TINYOS
3.5 ALLOCATION DE LA MÉMOIRE
3.6 ALLOCATION DE RESSOURCES
3.6.1 L’ordonnanceur
3.6.2 Package TinyOS
3.7 STRUCTURE LOGICIELLE
4.LES OUTILS DE SIMULATION
4.1 TOSSIM
4.2 POWERTOSSIM
4.3 TINYVIZ
5.LANGAGE DE PROGRAMMATION NESC
5.1 PRÉSENTATION
5.2 CONCEPTS ET DÉFINITIONS
5.3 DÉVELOPPEMENT
5.3.1 L’interface
5.3.2 Module
5.3.3 La configuration
5.3.4 Types de données
5.3.5 Types de fonctions en NesC
5.4 CONSTRUCTION D’UNE APPLICATION EN NESC
5.5 COMPILATION ET EXÉCUTION D’UNE APPLICATION EN NESC
6.COMMENTAIRES SUR NESC ET TINYOS
CONCLUSION
CHAPITRE III:L’IRRIGATION INTELLIGENTE POUR ÉCONOMISER L’EAU
1.INTRODUCTION
2.VUE D’ENSEMBLE: LA CRISE MONDIALE DE L’EAU
3.ECONOMIE D’EAU DES MÉNAGES: UN ÉLÉMENT DE SOLUTION
4.LE LIVRE BLANC « L’IRRIGATION POUR UN MONDE EN CROISSANCE »
5.L’EAU DANS LE SOL
6.BESOIN D’EAU SELON LES SOLS
7.ANALYSE DES ESPACES VERTS
8.SYSTÈMES D’IRRIGATION AUTOMATIQUES
9.EXEMPLE D’UN SYSTÈME UTILISÉ POUR L’IRRIGATION AUTOMATIQUE
10.STATISTIQUES DES SUPERFICIES IRRIGUÉES PAR LA DIRECTION DES SERVICES D’AGRICULTURE DANS LA WILAYA DE TLEMCEN EN 2011
CONCLUSION
CHAPITRE IV:IMPLÉMENTATION ET ÉVALUATION DE L’APPLICATION
1.INTRODUCTION
2.ENVIRONNEMENT DE TRAVAIL
2.1 INSTALLATION DE TINYOS
2.2 COMMANDES DE BASE UTILISÉES DANS CYGWIN POUR LANCER LE SIMULATEUR
3.SIMULATION DES RÉSEAUX DE CAPTEURS
3.1 CHOIX DU SIMULATEUR
3.1.1 Description de TinyViz
3.2 PROPRIÉTÉS DE TOSSIM
3.3 OBJECTIFS DE LA SIMULATION
4.LES FICHIERS DE L’APPLICATION
5.TOPOLOGIE DU RÉSEAU
6.LES ÉTAPES D’EXÉCUTION DE NOTRE APPLICATION
7.LES MÉTRIQUES D’ÉVALUATION DE L’APPLICATION
7.1 PREMIÈRE ÉTUDE (SI TOUS LES CAPTEURS FONCTIONNENT BIEN)
7.1.1 Estimation entre moyenne et médiane
7.1.2 Discussion sur les résultats
7.1.3 Décision de la discussion
7.2 IMPACT DE LA DENSITÉ DE LA ZONE
7.3 LES PARAMÈTRES À AJOUTER POUR UNE MEILLEURE DÉTECTION
7.3.1 Description du type de sol utilisé
7.3.2 Méthode de modélisation utilisée
7.3.3 Bornes de chaque paramètre
7.3.4 Mesures effectuées et prise de décision
8.DEUXIÈME ÉTUDE (EN CAS DE PANNE DES CAPTEURS)
8.1 PANNES CRASH
8.1.1 Cas 1 : le message n’est pas diffusé grâce à un défaut d’énergie
8.1.2 Cas 2 : le capteur peut émettre un message vide
8.2 PANNES DE COMMUNICATION
8.2.1 Le capteur envoi une haute valeur qui est normalement une valeur moyenne ou basse
8.2.2 Le capteur envoi une basse valeur qui est normalement valeur haute ou moyenne
8.2.3 Le capteur envoi une valeur moyenne qui est normalement valeur haute ou basse
CONCLUSION
CONCLUSION GÉNÉRALE
Bibliographie
Télécharger le rapport complet
