520 likes | 740 Views
Conception d’un prototype de plateforme pour l’étude d’aspects haut niveau dans un réseau de capteurs. Mickaël Cartron, Olivier Sentieys, Olivier Berder IRISA / R2D2 ENSSAT Lannion cartron@irisa.fr , sentieys@irisa.fr , berder@enssat.fr. Plateforme MICA2. Plateforme Aphycare.
E N D
Conception d’un prototype de plateforme pour l’étude d’aspects haut niveau dans un réseau de capteurs Mickaël Cartron, Olivier Sentieys, Olivier Berder IRISA / R2D2 ENSSAT Lannion cartron@irisa.fr, sentieys@irisa.fr, berder@enssat.fr
Plateforme MICA2 Plateforme Aphycare Introduction (1/5) • Les réseaux de capteurs • Objets communicants • Intégrés dans une zone d’intérêt • But : surveillance de zones • Caractéristiques • Ad hoc • Multi sauts • Débit faible • Très forte autonomie Notre objectif : maximisation de la durée de vie
Introduction (2/5) • Augmenter l’autonomie : sur quels paramètres est-il possible d’agir ? • Point de vue « traitement » Algorithmes distribués efficaces Application Algorithmes de routage énergétiquement efficaces Réseau Système de détection/correction d’erreurs, Système de répétition automatique, Taille des paquets Liaison Modulation, Puissance d’émission, Débit binaire par canal, Nombre de canaux disponibles, Largeur de bande utilisée Accès au média / Physique
Introduction (3/5) • Augmenter l’autonomie : sur quels paramètres est-il possible d’agir ? • Point de vue « circuit » Générateur Batterie DC/DC conv. DVS (f, Vdd) RAM Flash Capteur A/D Processeur Coprocesseur Radio
Introduction (4/5) • Interdépendance des paramètres est un casse-tête pour réaliser une optimisation (en se limitant à bas niveau) • Si on augmente le taux de transmission • La probabilité de collision diminue • Le taux d’erreur augmente • La consommation augmente • Si on augmente la puissance de la correction d’erreur • Le taux d’erreur diminue • La probabilité de collision augmente • La consommation augmente • Si on augmente la puissance d’émission • Le taux d’erreur diminue • La probabilité de collision augmente • La consommation augmente
Introduction (5/5) • On a énormément de paramètres qui ne sont pas « orthogonaux » • Optimisation difficile • Classification des paramètres • Paramètres liés au scénario applicatif • Paramètres liés aux choix technologiques • Paramètres non définis a priori • Il est nécessaire de faire des conjectures sur certaines valeurs de paramètres qui doivent être les plus réalistes possibles • Pour faire des conjectures correctes, il faut bien connaître les applications • Information échangée • Débits réellement nécessaires • Etc…
PLAN DE LA PRÉSENTATION • I - Étude de scénarios applicatifs • II - Plateforme Aphycare • III - Architecture logicielle du prototype • Nœud quelconque du réseau • Station de base • IV - Application à un problème concret • V - Conclusion et perspectives
Étude de scénarios applicatifs (1/7) • 2 scénarios précis • « Mesures sur une zone d’intérêt » • « Détection et positionnement d’une cible active » • Évaluation des besoins • Quantité d’informations échangées • Puissance de calcul nécessaire • Quantité de mémoire nécessaire au traitement
Étude de scénarios applicatifs (2/7) • Exemple de réseau de capteurs (1,8) (8,8) (5,6) (1,5) Simple répéteur (8,4) (11,3) (4,2) Capteur/Répéteur (source de données) (0,0) Station de base (puits de données) Type de nœuds Identifiants des nœuds = position géographique
(8,8) (7,7) (7,7) (7,7) (7,7) (5,6) (5,6) (1,5) (1,5) ?(7,7) Étude de scénarios applicatifs (3/7) • Application 1 : "Mesures sur une zone d'intérêt" • La station de base (0,0) veut connaître la température en (7,7) • Le point (7,7) n'est pas à portée radio de la station de base • La station de base émet "temp(7,7)?" • Le répéteur (1,5) reçoit la requête • (1,5) n'est pas à proximité de (7,7) • (1,5) ré-émet "temp(7,7)?" dans la "bonne direction", vers (5,6) • Le capteur (5,6) reçoit la requête • Le capteur (5,6) va participer au calcul de la température, car il est près de (7,7) • (5,6) fait également participer (8,8) au calcul en lui envoyant la requête • (8,8) reçoit la requête
(8,8) (7,7) (7,7) (7,7) (5,6) (5,6) (1,5) (4,2) (4,2) (0,0) Étude de scénarios applicatifs (4/7) • Application 1 : "Mesures sur une zone d'intérêt" • (8,8) va participer au calcul de la température, car il est près de (7,7) • (8,8) transmet sa valeur locale de température à (5,6) • (5,6) reçoit la valeur de (8,8) • (5,6) calcule la valeur en (7,7) en faisant une moyenne pondérée • (5,6) génère une réponse et l'envoie à (4,2) pour ne pas épuiser (1,5) • (4,2) reçoit la requête • (4,2) ré-émet le résultat à (0,0) • (0,0) reçoit le résultat
Cible Étude de scénarios applicatifs (5/7) • Application 2 : "Positionnement d'une cible active" • On cherche à connaître la position instantanée d'une cible mobile active • La cible émet une trame en mode « diffusion locale » • infos : cohérence temporelle, numéro de cible, puissance d'émission • Les nœuds du voisinage estiment la distance avec la cible • Ils émettent chacun une trame en mode direct vers la cible • infos : cohérence temporelle, numéro de cible, distance, coordonnées locales • Dans un deuxième temps, les mêmes nœuds routent ces mêmes infos vers la station de base
Mise en évidence de 5 modes de transmission (6/7) • « Multi-sauts (acquitté) » • « Inondation »
Mise en évidence de 5 modes de transmission (7/7) • « Saut unique acquitté » • « Saut unique non acquitté » • « Diffusion locale »
PLAN • I - Étude de scénarios applicatifs • II - Plateforme Aphycare • III - Architecture logicielle du prototype • Nœud quelconque du réseau • Station de base • IV - Application à un problème concret • V - Conclusion et perspectives
La plateforme Aphycare (1/2) • Microcontrôleur 16 bits Texas Instrument MSP430 • Faible consommation / faible coût • 2 Ko de RAM, 60 Ko de flash • Tête de communication Deltadore ou Chipcon CC1020 • Half duplex • Modulations FSK / GFSK / OOK, 860 Mhz • Taux de transmission bit maximum 3,6 Ko/s • Broche RSSI • Contrôle de la puissance (uniquement sur la version CC1020)
Architecture du réseau (2/2) N nœuds : Cartes Aphycare 1 station de base : Carte Aphycare + Carte Ethernut
PLAN • I - Étude de scénarios applicatifs • II - Plateforme Aphycare • III - Architecture logicielle du prototype • Nœud quelconque du réseau • Station de base • IV - Application à un problème concret • V - Conclusion et perspectives
Architecture logicielle d’un capteur (1/14) Gestion des timers Tâche applicative 1 Tâche applicative 2 Auto- position- nement Connaissance du voisinage Niveau application Routage géographique Routage par inondation Niveau réseau Dispatch Contrôle d'erreurs Niveau liaison Driver du composant de communication Niveau physique
Architecture logicielle d’un capteur (version simulation) (2/14) Simulation d'une horloge interne Tâche applicative 1 Tâche applicative 2 Auto- position- nement Connaissance du voisinage Niveau application Routage géographique Routage par inondation Niveau réseau Dispatch Contrôle d'erreurs Niveau liaison Canal de communication par file de messages Unix Niveau physique
Structure des trames (3/14) mode_transmission type Trame générique
Structure des trames (4/14) • Multi-sauts (acquitté) • Inondation mode_transmission type Num ack Destinataire Source Suivant Mode multi saut mode_transmission type ID_trame source Mode inondation
Structure des trames (5/14) • Saut unique acquitté • Saut unique non acquitté mode_transmission type Num ack Destinataire Source Mode saut unique acqu. mode_transmission type Destinataire Source Mode saut unique non acqu.
Structure des trames (6/14) • Diffusion locale mode_transmission type Source Mode diffusion locale
Structure des trames (7/14) • Les différents types de trames sont reliées par une union, ce qui permet de supprimer les recopies inutiles dans les buffers. • Les trames sont interprétées différemment en fonction du champ Type. typedef union { info_ACK Ack ; info_Cible Cible ; info_REQvois REQvois ; info_REPvois REPvois ; info_Signal Signal ; info_Distance_base Distance_base ; info_Distance_cible Distance_cible ; info_Vague Vague ; } u_info ;
Gestion des buffers (8/14) Gestion des timers Tâche applicative 1 Tâche applicative 2 Auto- position- nement Connaissance du voisinage Niveau application Routage géographique Routage par inondation Niveau réseau Dispatch Contrôle d'erreurs Niveau liaison Niveau physique Driver du composant de communication
Trame brute deadline historique Nombre d'envois mode type destinataire source autre données crc ETAPE1 ETAPE2 ETAPE3 PRET Trame brute distance mode type destinataire source autre données crc Gestion des buffers (9/14) Indique le nombre de tentatives d'envoi max. restant à réaliser Historique de fabrication du message Heure limite pour recevoir un acquittement Buffer d’émission Distance estimée de l'émetteur Buffer de réception
Buffer Émission Buffer Réception Gestion optimisée des buffers (10/14) Gestion des timers Tâche applicative 1 Tâche applicative 2 Auto- position- nement Connaissance du voisinage Routage géographique Routage par inondation Dispatch Contrôle d'erreurs Driver du composant de communication
Utilisation d’un ordonnanceur (11/14) • Utilisation d'un ordonnanceur • ordonnancement fixe • non préemptif • très portable Tache 1 main(){ initialisations(); while(1){ PT_planificateur_d’accès(); PT_réception(); PT_émission(); PT_liaison(); PT_réseau(); PT_appli(); PT_gestion_timers(); } } Tache 2 Tache 3 etc. [Dunkels, Schmidt, Voigt, “Using Protothreads for Sensor Nodes Programming”, 2005]
Code AVR (taille en octets) 1044 - 678 90 226 1934 5218 Optimisation de la mémoire (12/14) Module Kernel Program loader Multi-threading library Timer library Memory manager Event log replicator µIP TCP/IP stack Code MSP430 (taille en octets) 810 658 582 60 170 1656 4146 RAM (taille en octets) 10 + 2*e + 2*p 8 8 + s 0 0 200 18+b • e : nombre d'évènements • p : nombre de protothreads
Driver du composant de communication (13/14) • Basé sur une amélioration du modèle MAPLAP • TX: Transmit • RX: Receive • AQ: Acquire • MN: Monitor • IL: Idle • [Lin, Rabaey, Power-Efficient Rendez-vous Schemes for Dense Wireless Sensor Networks, ICC, 2004] TX AQ MN IL RX Diagramme d'état du modèle MAPLAP Émetteur Récepteur MN/AQ/RX TX Réactivation IL
Buffer Émission Buffer Réception Driver du composant de communication (14/14) • Contrôleur bas niveau • Prend en charge une procédure de réception ou d'émission • Contrôle l'activation et la désactivation du composant • Sa cohérence est contrôlée par la machine d’état décrite précédemment • Planificateur d'accès au média • Analyse le buffer d'émission et les horloges • Planifie les réveils de réception et d'émission • Simule la diffusion Planificateur d'accès au média Contrôleur bas niveau
PLAN • I - Étude de scénarios applicatifs • II - Plateforme Aphycare • III - Architecture logicielle du prototype • Nœud quelconque du réseau • Station de base • IV - Application à un problème concret • V - Conclusion et perspectives
Station de base (1/2) Tâche interface Serveur web dynamique IEEE 802.3 Réseau local Carte Ethernut Liaison Ethernet Liaison série Gestion des timers Tâche interface Tâche applicative 2 Auto- position- nement Connaissance du voisinage Routage géographique Routage par inondation Plateforme AphyCare Dispatch Contrôle d'erreurs Driver du composant de communication
Liaison série carte Ethernut / plateforme Aphycare Serveur web dynamique Possibilité d’interroger le réseau Possibilité de récupérer les réponses Station de base (2/2)
PLAN • I - Étude de scénarios applicatifs • II - Plateforme Aphycare • III - Architecture logicielle du prototype • Nœud quelconque du réseau • Station de base • IV - Application à un problème concret • V - Conclusion et perspectives
Exemples d’utilisation du prototype (1/12) • Étude de contraintes à bas niveau • La modélisation réaliste des contraintes haut niveau est difficile. • La précision des paramètres doit être aussi grande que possible, car l’optimisation des paramètres à bas niveau les présuppose connus. • Paramètres clés • Nombre de messages échangés • Probabilité de collisions • Etc…
Exemple : évaluation d’un gain en performance (2/12) • Considérons l’ensemble constitué des niveaux liaison, MAC et physique d’un système de communication • Modèle de l’énergie par bit transmis avec succès • BPSK, canal AWGN, codage canal Hamming ou convolutif • retransmission SACK, longueur de paquets lp
Exemple : évaluation d’un gain en performance (3/12) • Mise en évidence d'un point optimal de fonctionnement • D=10 m, Pbruit=-90 dBm, Paquets de 53 octets, ré-émission automatique : SACK, correction d'erreurs (viterbi, hamming) • couche physique adaptée • amplificateurs efficaces • modulation BPSK • fort intérêt à se situer à la puissance d’émission optimale • QUESTION : Quel gain de durée de vie gagne t’on réellement à être au point optimal ?
Évaluation d’un gain en performance (4/12) • Considérons un exemple de réseau formé de 27 nœuds disposés régulièrement, et d'une station de base • Simulation réalisée à l'aide de notre prototype de réseau de capteurs (version simulation) • Pas du réseau : 7 mètres
Évaluation d’un gain en performance (5/12) • Protocole d'exemple : mise à jour d'un réseau de capteurs • Phase 1 : inondation pour lancer la phase d'initialisation • Phase 2 : requête pour la connaissance du voisinage • Phase 3 : réponse à la requête • Phase 3 bis : acquittements de cette réponse • Phase 4 : enregistrement de chaque nœud auprès de la station de base • Phase 4 bis : acquittements du mode multi-hop
Évaluation d’un gain en performance (6/12) • Phase 1 : inondation initiale 3 5 5 5 5 5 3 5 8 8 8 8 8 5 5 8 8 8 8 8 5 3 5 5 5 5 5 3 Sommes cumulées d’émissions de paquets
Évaluation d’un gain en performance (7/12) • Phase 2 : requête pour la connaissance du voisinage 6 10 10 10 10 10 6 10 16 16 16 16 16 10 10 16 16 16 16 16 10 6 10 10 10 10 10 6
Évaluation d’un gain en performance (8/12) • Phases 3 et 3 bis : réponse à la requête sur le voisinage 12 20 20 20 20 20 12 20 32 32 32 32 32 20 20 32 32 32 32 32 20 12 20 20 20 20 20 12
Évaluation d’un gain en performance (9/12) • Phases 4 et 4 bis : enregistrement de chaque nœud auprès de la station de base 13 21 21 21 21 21 13 21 35 39 35 35 35 21 21 39 59 55 47 39 21 13 21 21 21 21 21 13
Évaluation d’un gain en performance (10/12) • Phases 4 et 4 bis : enregistrement de chaque nœud auprès de la station de base 13 21 21 21 21 21 13 21 35 39 35 35 35 21 21 39 59 55 47 39 21 13 21 21 21 21 21 13 Capteur le plus sollicité
Max. 55 Moy. 26,1 Évaluation d’un gain en performance (11/12) Nombre de nœuds en fonction du nombre d’émissions
Évaluation d’un gain en performance (12/12) • Énergie dépensée par trame 5.2 mJ 2.048 mJ 1.6 mJ 5.2 mJ 2.048 mJ 2.048 mJ Méthode indexée sur la puissance d'émission de 0 dBm Méthode indexée sur le pire cas 406 % de temps en plus avant l'épuisement du premier nœud Méthode d'optimisation globale adaptative 475 % de temps en plus avant l'épuisement du premier nœud
PLAN • I - Étude de scénarios applicatifs • II - Plateforme Aphycare • III - Architecture logicielle du prototype • Nœud quelconque du réseau • Station de base • IV - Application à un problème concret • V - Conclusion et perspectives
Conclusion et perspectives • Analyse fine des besoins applicatifs • Meilleure évaluation des contraintes qu’exercent les niveaux supérieurs sur les couches basses de la pile de protocole réseau • Bases pour une architecture adaptée à des réseaux de capteurs • Coprocesseur • Architecture mémoire intelligente