3ème année électroniques Option : Systèmes Embarqués

PROJET AVANCE SE :

RESEAU DE CAPTEURS SANS FILS

PROFESSEUR :

Mr. Patrice KADIONIK

REALISATEURS :

Héni JMEL - Maxime CAUDRON

Aurélien BRISSET - Pierre Marc GUITARD

2

INTRODUCTION Dans la vie courante, l’utilisation des capteurs sans fil est de plus en plus demandée pour la supervision et la sécurité. Les industries proposent alors des capteurs sans fil qui peuvent renseigner l’utilisateur sur plusieurs données. Ces capteurs peuvent aussi être reliés ensemble pour former un réseau sans fil se basant sur des protocoles pour se communiquer et proposant des programmes et des réseaux embarqués. Notre projet traitait de la découverte d’applications portées sur un réseau de capteurs sans fils. Lors de ce projet nous avons ainsi découvert les caractéristiques essentielles d’un tel réseau. Le premier point est que la communication entre les différents capteurs se fait par ondes radios. Ici, les composants de communication liés aux capteurs utilisent le protocole Zigbee. Un autre point important est le protocole réseau utilisé par les capteurs. Le protocole vu lors de ce projet est le réseau Mesh développé sur le matériel du kit Crossbow. De plus les capteurs doivent avoir une forte autonomie pour que ces réseaux soient intéressants. Les capteurs fonctionnent donc à basse tension et ceci est géré par un système d’exploitation spécialisé : TinyOS. Enfin, il doit exister un environnement de développement logiciel afin d’importer des applications sur les capteurs. Le langage utilisé pour ce développement est le nesC.

I - LES RESEAUX DE CAPTEURS SANS FIL

1) Réseau Mesh Les réseaux de capteurs sans fil ont attiré l’intérêt d’entreprises par la diversité de leurs applications. Ce qui a crée cette convoitise est l’utilisation d’un réseau multi-sauts Mesh qui permet une grande couverture surfacique avec un aspect sécuritaire. Un réseau Mesh est le nom des systèmes en réseau embarqués qui partagent plusieurs caractéristiques telles que : • Multi-Hop —La possibilité d’envoyer des messages de capteur en capteur jusqu’à une station de

base, ceci permettant l’extension du réseau en escalade.

• Self-Configuring—Capacité à créer le réseau sans intervention humaine.

• Self-Healing—Capacité d’ajouter et de supprimer des noeuds du réseau automatiquement sans

avoir à reconfigurer le réseau.

• Dynamic Routing—Capacité à déterminer de manière adaptative le chemin vers la base

dynamiquement en fonction des conditions du réseau.

Ces caractéristiques associées à une gestion de la consommation d’énergie permettent aux réseaux de capteurs une grande autonomie, un déploiement facile et une réactivité face à un problème au sein du réseau.

3

2) Protocole de communication : Zigbee

ZigBee est un protocole de haut niveau permettant la communication de petites radios, à consommation réduite, basée sur le standard IEEE 802.15.4 pour les réseaux à dimension personnelle (Wireless Personal Area Networks : WPANs). Cette technologie a pour but la communication de courte distance telle que le propose déjà la technologie Bluetooth, tout en étant moins chère et plus simple. À titre d’exemple, les nœuds ZigBee classiques nécessitent environ 10 % du code nécessaire à la mise en œuvre de nœuds Bluetooth ou de réseaux sans fil, et les nœuds ZigBee les plus élémentaires peuvent ainsi descendre jusqu’à 2 % ! Comparaison des protocoles : Zigbee, Bluetooth et Wifi Protocole Zigbee Bluetooth Wifi IEEE 802.15.4 802.15.1 802.11a/b/g Besoin mémoire 4-32 Kb 250 Kb + 1 Mb + Autonomie avec pile Années Jours Heures Nombre de nœuds 65 000+ 7 32 Vitesse de transfert 250 Kb/s 1 Mb/s 11-54-108 Mb/s Portée 100 m 10-100 m 300 m Routage niveau réseau : La spécification initiale de ZigBee propose un protocole lent dont le rayon d’action est relativement faible, mais dont la fiabilité est assez élevée, le prix de revient faible et la consommation considérablement réduite.

4

On retrouve donc ce protocole dans des environnements embarqués où la consommation est un critère de sélection. Ainsi, la domotique et les nombreux capteurs qu’elle implémente apprécient particulièrement ce protocole en plein essor et dont la configuration du réseau maillée se fait automatiquement en fonction de l’ajout ou de la suppression de nœuds. On retrouve aussi ZigBee dans les contrôles industriels, les applications médicales, les détecteurs de fumée et d’intrusion. Les nœuds sont conçus pour fonctionner plusieurs mois (jusqu’à deux ans pour les moins consommant) en autonomie complète grâce à une simple pile alcaline de 1,5V. Rootage niveau applicatif : Le routage au niveau applicatif se fait grâce à la table de liaison, contenu dans le coordinateur ou un routeur. Les liaisons permettent de créer des liens logiques entre des dispositifs d'application complémentaires et des éléments de fins (capteurs). La table de liaison permet aussi d'associer à un attribut d'un dispositif en entrée plusieurs attributs de dispositifs en sortie ou l'inverse. La table de liaison est implémentée dans le coordinateur ZigBee. Le choix de ce dispositif vient du fait que le coordinateur ZigBee est nécessaire au réseau. Le second intérêt est, vu que le coordinateur est indispensable au réseau, il doit être (en général) alimenté par le secteur. Ces deux raisons font que la table de liaison sera toujours accessible. La table de liaison repose sur trois critères normalisés par la ZigBee Alliance :

• le profile Un profile permet de créer une application interopérable et distribuée. Il s'agit donc de définir des formats de messages et le traitement des actions pour permettre à des dispositifs de demander, transmettre des données et savoir les interpréter. Les profiles sont développés par les entreprises pour permettre de répondre à des besoins spécifiques. Par exemple, le premier profile existant est fait pour gérer les lampes et des interrupteurs (home control lighting). Ce profile permet six types d'échanges de messages de contrôle. Les profiles permettent de créer aussi une norme autour de chaque application pour permettre l'interopérabilité des systèmes.

• le cluster Les clusters sont associés avec des flots de données entrant ou sortant. Les identificateurs de clusters sont uniques dans un profile. Les clusters permettent de lier deux dispositifs par l'association d'un cluster en entrée et d'un cluster en sortie en supposant qu'ils appartiennent au même profile. En fait deux dispositifs sont liés s'ils partagent le même besoin (côté récepteur) et la même ressource (côté émetteur). La table de liaison (binding table) contient pour chaque cluster un identifiant pour le définir (sur 8 bits) et l'adresse des deux dispositifs (source et destination).

• l'attribut Un attribut définit un capteur ou un actionneur. C’est l’élément qui décrit de façon la plus précise l’utilisation du dispositif (par exemple un capteur de mouvement, un buzzer, une lampe, etc.).

5

La table de liaison est la couche applicative qui permet de gérer la table de routage et la table de découverte de routes. C'est elle qui va permettre d'associer le relevé d'un capteur sur un dispositif à une action spécifique sur un autre dispositif à travers toutes les couches du protocole ZigBee. C'est une façon de simplifier l'accès lorsque le réseau contient beaucoup de connexions et de dispositifs : la reconnaissance entre les dispositifs qui dialoguent se fait par rapport à leurs « familles » (les profiles et clusters) et leurs qualités (les attributs) communes.

3) Le kit CrossBow

Dans un système traditionnel de capteurs, la puissance d'émission et l'antenne de chacun des capteurs doivent être adaptées en fonction de la distance entre le capteur et la station de base, ce qui restreint la couverture globale.

Les réseaux de capteurs Crossbow utilisés sont préprogrammés et adoptent la logique « multi hop » de routage dynamique. Ainsi chaque capteur peut jouer le rôle de relais pour les autres capteurs, permettant d'étendre facilement la couverture et d'adapter celle-ci aux déplacements des capteurs ou aux variations des bilans de liaisons.

Le réseau repose sur plusieurs modules : - Le composant de communication du capteur est appelé « mote » et utilise ici un protocole propriétaire Crossbow et un signal modulé à une fréquence de 433Mhz. D'autres modèles utilisent IEEE ZigBee 802.15.4 dans la bande ISM à 2.4 Ghz. - Le capteur en lui-même ou « sensor » est couplé au « mote ». Chaque capteur mesure plusieurs données différentes telles que la température, la luminosité, l’accélération, l’humidité... - Une passerelle reliée à un ordinateur par ethernet ou port série permet de récupérer les mesures issues des différents capteurs. Cette passerelle est équipée d'un « mote » afin de s'insérer dans le réseau. Le réseau mis en oeuvre dans l'expérimentation repose sur une passerelle et deux motes équipés d'un capteur. Si les motes sont livrés préprogrammés pour fonctionner en mode « multi hop », il est possible d'adapter leur comportement aux besoins d'expérimentations plus poussées.

II - TINYOS ET LE NESC

1) TinyOS

TinyOS est un système d’exploitation open-source conçu pour des réseaux de capteurs sans-fil. Il respecte une architecture basée sur une association de composants, réduisant la taille du code nécessaire à sa mise en place. Cela s’inscrit dans le respect des contraintes de mémoires qu’observent les réseaux de capteurs. Pour autant, la bibliothèque de composant de TinyOS est particulièrement complète puisqu’on y retrouve des protocoles réseaux, des pilotes de capteurs et des outils d’acquisition de données. L’ensemble de ces composants peut être utilisé tel quel, il peut aussi être adapté à une application précise.

6

En s’appuyant sur un fonctionnement événementiel, TinyOS propose à l’utilisateur 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 interfaces physiques. Disponibilité et sources : TinyOS est un système principalement développé et soutenu par l’université américaine de Berkeley, qui le propose en téléchargement sous la licence BSD et en assure le suivi. Ainsi, l’ensemble des sources sont disponibles pour de nombreuses cibles matérielles. Event-driven : Le fonctionnement d’un système basé sur TinyOS s’appuie sur la gestion des évènements se produisant. Ainsi, l’activation de 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 (event-driven) s’oppose au fonctionnement dit temporel (time-driven) où les actions du système sont gérées par une horloge donnée. Langage : Comme nous l’avons évoqué plus haut, TinyOS a été programmé en langage NesC que nous allons détailler plus loin. Préemptif : 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. Temps réel : Lorsqu’un système est dit « temps réel » celui-ci gère des niveaux de priorité dans ses tâches permettant de respecter des échéances données par son environnement. Dans le cas d’un système strict, aucune échéance ne tolère de dépassement 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. Consommation : 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. Cibles de TinyOS : Il existe de nombreuses cibles possibles pour ce système d’exploitation embarqué. Malgré leurs différences, elles respectent toutes globalement la même architecture basée sur un noyau central autour duquel s’articulent les différentes interfaces d’entrée-sortie, de communication et d’alimentation. Voici un schéma représentant cette architecture :

7

- Mote, processeur, RAM et Flash : On appelle généralement Mote la carte physique utilisant TinyOS pour fonctionner. Celle-ci a pour cœur le bloc constitué du processeur et des mémoires RAM et Flash. Cet ensemble est à la base du calcul binaire et du stockage, à la fois temporaire pour les données et définitif pour le système TinyOS. - Radio et antenne : TinyOS est prévu pour mettre en place des réseaux sans fils, les équipements étudiés sont donc généralement équipés d’une radio ainsi que d’une antenne afin de se connecter à la couche physique que constitue les émissions hertziennes. - LED, interface, capteur : TinyOS est prévu pour mettre en place des réseaux de capteurs, on retrouve donc des équipement bardés de différents types de détecteurs et autres entrées. - Batterie : Comme tout dispositif embarqué, ceux utilisant TinyOS sont pourvus d’une alimentation autonome telle qu’une batterie.

2) Le langage nesC Le nesC est un prolongement du langage C. Il est conçu pour gérer les concepts et le modèle d'exécution de TinyOS. Les concepts de base du nesC sont :

• Séparation de construction et de composition : les programmes sont construits à partir de composants, qui sont assemblés ("câblés") pour former des programmes complets. Les composants sont divisés en 2 blocs, un pour leur spécification (contenant les instances des interfaces), et un pour leur implémentation. Les composants sont en concurrence interne sous la forme de taches. Les threads de commande peuvent passer d’un composant à un autre au travers des interfaces. Ces threads peuvent être appelés soit dans une tache soit par interruption matérielle.

• Spécifications du comportement du composant en terme de groupe d'interfaces. Il

existe 2 groupes d’interfaces : les interfaces fournies ou les interfaces utilisées par le

8

composant. Les interfaces fournies sont prévues pour représenter la fonctionnalité que le composant fournit à son utilisateur, les interfaces utilisées représentent la fonctionnalité que le composant a besoin pour réaliser son travail.

• Les interfaces sont bidirectionnelles : les interfaces spécifient un ensemble de

fonctions à implémenter par le fournisseur de l’interface (commandes) et un ensemble à implémenter par l'utilisateur de l'interface (événements). Ceci permet à une simple interface de représenter une interaction complexe entre les composants. C'est crucial car toutes les très longues commandes dans TinyOS sont non bloquantes ; leur accomplissement est signalé par un événement. Donc un composant qui fait appel à une commande doit implémenter une interface qui recoit l’événement d’accomplissement de la commande appelée. Typiquement les commandes appellent vers les niveaux bas, c.-à-d., depuis des composants d'application vers ceux plus près du matériel, alors que les événements appellent vers les couches supérieures. Certains événements proviennent d’interruptions matérielles.

• Des composants sont statiquement liés entre eux par l'intermédiaire de leurs interfaces.

Ceci augmente la vitesse d'exécution, encourage une conception robuste, et tient compte d'une meilleure analyse statique des programmes.

• le nesC est conçu dans l’optique que le code sera produit par des compilateurs de

programme complet. Ceci tient compte d'une meilleure génération et analyse du code.

L'image ci-dessous montre la structure (les composants et leur câblage) d'une application simple qui allume une LED chaque seconde :

9

III - LES OUTILS UTILISES

1) MoteView

L’outil Motewiew fourni avec le kit Crossbow nous fournit en temps réel les

informations nécessaires suivant une topologie du réseau des capteurs reprogrammables.

On peut récupérer des différents capteurs les informations transférées à la station base, qui envoie les données à travers le port série du PC connecté. On récupère alors la température, la luminosité, la position, l’humidité, les accélérations (suivant l’axe des abscisses x et des ordonnées y) ainsi que l’état de la batterie. Chaque capteur est repéré par un numéro de « Node » et on peut sélectionner différents capteurs pour avoir les informations et le mode de travail de chaque capteur connecté.

Moteview : Données temps réel de 4 capteurs branchés avec la station

Une signalétique de couleur permet d’afficher le signal de vie d’un capteur. En fonction du temps auquel la dernière information a été transmise au client, le capteur apparaît d’une certaine couleur à l’affichage. Il y a 6 couleurs différentes et les délais peuvent être configurés dans la fenêtre suivante :

10

On peut tracer des courbes pour étudier en temps réel les différentes informations reçues des capteurs sélectionnés :

Ces informations peuvent être représentées par un histogramme comme dans la figure suivante :

11

On peut aussi définir une topologie du réseau de capteurs pour étudier en temps réel et définir une application suivant les données qu’on reçoit des capteurs. L’exemple suivant est issu de l’étude de l’humidité d’un espace. Les résultats captés permettent de visualiser le niveau d’humidité de l’espace total à partir de l’emplacement des « Motes ».

3) MoteWorks Moteworks possède comme environnement de développement pour le nesC une version simplifiée de Programmer’s Notepad. Cet environnement permet de créer, compiler et charger des applications en nesC sur les motes. Cet environnement utilise une interface Cygwin comme console de commande. La compilation et le chargement d’applications se font par des commandes standardisées simples. Pour toutes les applications on utilise les mêmes commandes.

Pour la compilation, en fonction de la plateforme processeur/radio que l’on on a à disposition, il suffit de sélectionner dans la barre d’outils make <platform>. Dans notre cas :

make micaz

Lors du chargement d’une application sous l’environnement MoteWorks, après avoir lancé un shell, on utilise une commande simplifiée dans laquelle on précise la plateforme processeur/radio, la carte d’interface de programmation du mote et le port de communication. Dans notre cas cela donne :

make micaz install mib520,com7 Cette simplicité des commandes de compilation et de chargement permet un accès facile pour des personnes peu habituées à la programmation. Ceci est intéressant car un grand nombre d’applications est fourni par CrossBow. Il suffit de sélectionner l’application souhaitée et de la traiter comme vu précédemment.

12

Par contre, cette simplicité des commandes nécessite un format pour les applications strict. A savoir, chaque application possède un répertoire composé de 4 fichiers nécessaires :

1. Makefile

2. Makefile.component

3. Un fichier de configuration de l’application

4. Un fichier contenant le module de l’application

Makefile est le fichier qui est compilé lors de la commande make, il fait appel à d’autres fichiers :

include Makefile.component

include $(TOSROOT)/apps/MakeXbowlocal

include $(MAKERULES)

Le fichier MakeXbowlocal contient les options de la carte de programmation, l’identifiant de groupe permettant de différencier des motes appartenant à des réseaux différents, la sélection de la bande radio et des canaux ainsi que la puissance d’émission. Makefile.component décrit à haut niveau le composant de l’application et le nom de la carte de capture. Ceci permet simplement d’annoncer au compilateur que l’on va utiliser les composants nesC précompilés de la carte afin d’initialiser ses capteurs.

COMPONENT=Nom_application

SENSORBOARD=mts310

Le fichier contenant la configuration de l’application est le fichier Nom_application.nc. Dans ce fichier sont implémentés les composants qui interagissent entre eux dans l’application, puis on définit comment ces composants sont liés :

configuration Nom_application {

}

implementation {

components Main, Nom_applicationM;

Main.StdControl -> Nom_applicationM.StdControl;

}

Chaque application doit au moins contenir le composant Main et son module Nom_applicationM. Le composant Main est le premier à être exécuté et c’est lui qui contrôle les autres via les méthodes init(), start(), stop() communes à chaque composant. Enfin on crée le module dans le fichier Nom_application.nc. Ce dernier contient le code de l’application.

13

4) XSniffer Xsniffer est un outil développé par Crossbow qui permet aux utilisateurs de superviser la communication multi-sauts sous Xmesh. Ce programme s’exécute sur un PC et utilise un MICAz pour la surveillance du trafic des paquets radio. Xsniffer peut être utilisé pour observer le comportement du réseau. Il affichera tous les messages radio transmis au sein du réseau. Xsniffer peut être utilisé pour : Vérifier si un mote a rejoint le réseau. Quand ceci arrive les paquets de vie et de données modifieront leur adresse de broadcast pour l’adresse de la station de base ou celle d’un autre élément du réseau. Observer les séquences des paquets d’un mote particulier et trouver des messages spéciaux comme les messages de mise à jour et de synchronisation.

IV - APPLICATIONS DEVELOPPEES

1) Tutoriaux

Pour prendre en main le logiciel MoteWorks, le langage nesC et TinyOS, nous avons suivi les tutoriaux fournis par Crossbow. Ces tutoriaux vont d’applications simples tels que le clignotement de leds jusqu’à l’utilisation d’échanges complexes entre mopes par multi hops. Nous allons détailler la première application du tutorial afin de mieux comprendre le fonctionnement du nesC. A partir de ce que nous avons appris au travers de ces différents tutoriaux, nous avons ensuite tenté de développer notre propre application.

Première application : led déclenchée par un timer

Le nesC est basé sur le développement de composants et la réutilisation de ceux-ci. Une grande bibliothèque de composants est fournie par Crossbow. L’application que l’on veut développer ici utilise comme matériel une led et un timer. Pour se servir de ce matériel, nous nous servons donc des composants LED et Timer de la bibliothèque Crossbow.

Pour créer cette application, on crée les différents fichiers nécessaires (Makefile, Makefile.component,…). Ici on va seulement s’attarder sur les fichiers MyApp.nc et MyAppM.nc.

Dans le fichier MyApp on définit les composants qui interviennent dans l’application et on les relie entre eux.

configuration MyApp { }

implementation {

components Main, MyAppM, TimerC, LedsC;

Main.StdControl -> TimerC.StdControl;

Main.StdControl -> MyAppM.StdControl;

MyAppM.Timer -> TimerC.Timer[unique("Timer")];

MyAppM.Leds -> LedsC.Leds;

}

14

Les composants utilisés ici sont Main, MyAppM, TimerC, LedsC. Le composant Main contrôle les composants MyappM et TimerC : il les initialise et les lance. Notre composant doit utiliser les composants TimerC et LedsC pour l’application souhaitée. Ensuite on crée notre module MyAppM dans le fichier MyAppM.nc. On définit dans la première partie du fichier comment le module est interconnecté avec les autres composants : s’il utilise des méthodes d’autres composants ou s’il en fournit.

module MyAppM {

provides {

interface StdControl;

}

uses {

interface Timer;

interface Leds;

}

}

Puis on implémente les méthodes, en définissant leurs conditions d’appel (command result_t si c’est un composant à qui on fournit des méthodes ou event result_t si c’est un comopsant que l’on utilise).

implementation {

command result_t StdControl.init() {

call Leds.init();

return SUCCESS;

}

Lorsque la commande init() est lance depuis l’interface StdControl en provenance du composant Main, on appelle la fonction d’init() du composant Led par la commande call et grace à l’interface Leds. Les mêmes opérations sont ainsi faites pour les fonctions start() et stop().

command result_t StdControl.start() {

// Start a repeating timer that fires every 1000ms

return call Timer.start(TIMER_REPEAT, 1000);

}

command result_t StdControl.stop() {

return call Timer.stop();

}

15

Apres avoir géré les actions liées à la commande de notre composant. Par le composant Main, nous allons définir les actions à réaliser en réaction au travail fait par les composants utilisés par notre composant. L’achèvement d’une fonction par un composant provoque un événement event.

event result_t Timer.fired()

{

call Leds.redToggle();

return SUCCESS;

}

}

Cette application est très simple, en fait on ne fait que initialiser les différents composants utilisés Led et Timer. On lance le timer. Et on réagit aux événements du timer en allumant une led. Cet exemple nous a permis de découvrir la méthode de programmation nesC. Le principe est basé sur l’assemblage de composants ; L’application réalisée ne fait que lier ces différents composants et les faire interagir entre eux. Le schéma de base est toujours le même : notre composant sert d’interface entre le composant Main qui contrôle l’application par ses fonctions init() start() et stop() (toujours présentes) et d’autres composants utiles à l’application (par exemple un Timer). Notre composant active les composants qu’il uitlise et réagit aux événements provoqués par ces derniers en lançant d’autres actions. Les actions qu’il lance peuvent être définies dans des fonctions de composants en aval ou même être définies à l’intérieur du programme de notre composant. Les mots clé pour lancer ces fonctions sont différents selon les 2 cas : Call pour des fonctions extérieures au composant. Post pour les fonctions définies en interne.

Au cours de ces différents tutoriaux nous avons appris les bases du nesC et à se servir des outils CrossBow : Xserver, Xsniffer, MoteView. A partir de ces notions de base, nous avons donc décidé de réaliser notre propre application.

2) Notre propre application

Dans ce projet, notre but essentiel était de découvrir les nouvelles fonctionnalités adaptées pour gérer les réseaux de capteurs sans fils, on a pu avoir une idée sur le langage NesC, le protocole de communication et les différentes phases pour construire un projet et une application utilisant ce genre de réseaux. A travers la compréhension des différents tutoriaux proposés par MoteConfig, on a pu aboutir à la programmation des capteurs et de la base par des programmes simples. Le programme consiste à recevoir un signal radiaux d’une ou de plusieurs capteurs pour les transmettre par la liaison série. (Code fourni en annexe) La compilation et l’exécution se base sur la plateforme micaz. D’une autre part, on a aussi travaillé sur l’envoie de l’information avec le clignotement de l’une des LEDs lorsque l’information est envoyé ou reçue par un des capteurs.

16

CONCLUSION Ce projet était une occasion de découvrir un nouveau monde de l’embarqué avec de la télécommunication car on a pu comprendre les différentes étapes pour construire un réseau de capteurs sans fils. Le langage NesC est utilisé pour le Système d’Exploitation TinyOS approprié à ce genre de réseaux, c’est un langage intéressant mais trop complexe et assez long à comprendre, c’est pour cela que la grande partie de la réalisation de ce projet était la compréhension de l’environnement et la prise en main. De nombreuses applications peuvent être implémentées sur le kit Crossbow et on peut adapter notre besoin pour le développement de notre application, comme pour détecter à distance un incendie dans le foyer ou prévoir les activités sismique martines. Mais reste à exploiter et comprendre parfaitement le milieu de programmation et de configuration de ce genre de réseaux sans fils.

17

ANNEXE : Code de reception de message Mote.nc #include "appFeatures.h" includes sensorboardApp; /** * This configuration shows how to use the Timer, LED, ADC and XMesh components. * Sensor messages are sent multi-hop over the RF radio * This application also accepts commands from the base for changing the reporting * rate and to toggle the LED states * **/ configuration EssaiMote { } implementation { components Main,LedsC, GenericCommPromiscuous as Comm, MULTIHOPROUTER, EssaiMoteM, TimerC, XCommandC; Main.StdControl -> TimerC.StdControl; Main.StdControl -> EssaiMoteM.StdControl; Main.StdControl -> Comm.Control; //Main.StdControl -> MULTIHOPROUTER.StdControl; EssaiMoteM.Timer -> TimerC.Timer[unique("Timer")]; EssaiMoteM.RouteControl -> MULTIHOPROUTER; EssaiMoteM.Send -> MULTIHOPROUTER.MhopSend[AM_XMULTIHOP_MSG]; EssaiMoteM.XCommand -> XCommandC; EssaiMoteM.Leds -> LedsC.Leds; MULTIHOPROUTER.ReceiveMsg[AM_XMULTIHOP_MSG] ->Comm.ReceiveMsg[AM_XMULTIHOP_MSG]; EssaiMoteM.SendMsg -> Comm.SendMsg[AM_XSXMSG]; // UART }

18

MoteM.nc module EssaiMoteM { provides { interface StdControl; } uses { interface Timer; //interface MhopSend as Send; interface RouteControl; interface XCommand; interface Leds; interface MhopSend as Send; // radio msg } } implementation { bool sending_packet = FALSE; TOS_Msg msg_buffer; XDataMsg *pack; /** * Initialize the component. * * @return Always returns <code>SUCCESS</code> **/ command result_t StdControl.init() { uint16_t len; call Leds.init(); /** // Initialize the message packet with default values atomic { pack = (XDataMsg*)call Send.getBuffer(&msg_buffer, &len); pack->board_id = SENSOR_BOARD_ID; pack->packet_id = 6; } **/ //// atomic { pack = (XDataMsg*)call Send.getBuffer(&msg_buffer, &len); //pack = (XDataMsg *)&(msg_buffer.data); pack->board_id = SENSOR_BOARD_ID; pack->packet_id = 2; pack->node_id = TOS_LOCAL_ADDRESS; pack->rsvd = 0; } ///// return SUCCESS;

19

} /** * Start things up. This just sets the rate for the clock component. * * @return Always returns <code>SUCCESS</code> **/ command result_t StdControl.start() { // Start a repeating timer that fires every 1000ms return call Timer.start(TIMER_REPEAT, 1000); } /** * Halt execution of the application. * This just disables the clock component. * * @return Always returns <code>SUCCESS</code> **/ command result_t StdControl.stop() { return call Timer.stop(); } void task SendData() { if (sending_packet) return; atomic sending_packet = TRUE; // send message to radio msg_buffer.data[5]=1111; pack->parent = call RouteControl.getParent(); if (call Send.send(BASE_STATION_ADDRESS,MODE_UPSTREAM,&msg_buffer,sizeof(XDataMsg)) != SUCCESS){ sending_packet = FALSE; } else call Leds.redToggle(); return; } event result_t Timer.fired() { post SendData(); call Leds.greenToggle(); /*if (call SendMsg.send(TOS_UART_ADDR,sizeof(XDataMsg),&msg_buffer) != SUCCESS) sending_packet = FALSE;*/ return SUCCESS; } event result_t Send.sendDone(TOS_MsgPtr msg, result_t success) { // event result_t SendMsg.sendDone(TOS_MsgPtr msg, result_t success) { atomic sending_packet = FALSE;

20

return SUCCESS; } /** * Handles all broadcast command messages sent over network. * * NOTE: Bcast messages will not be received if seq_no is not properly * set in first two bytes of data payload. Also, payload is * the remaining data after the required seq_no. * @return Always returns <code>SUCCESS</code> **/ event result_t XCommand.received(XCommandOp *opcode) { uint16_t timer = 0; switch (opcode->cmd) { case XCOMMAND_SET_RATE: // Change the data collection rate. timer = opcode->param.newrate; call Timer.stop(); call Timer.start(TIMER_REPEAT,timer); break; default: break; } return SUCCESS; } }