DEPARTEMENT D`INFORMATIQUE MEMOIRE Présenté par

Transcription

DEPARTEMENT D'INFORMATIQUE
MEMOIRE
Présenté par
HOUACHE Noureddine
Pour obtenir
LE DIPLOME DE MAGISTER
Spécialité Informatique
Option : Analyse, commande et surveillance des systèmes industriels
Intitulé :
Conception et implémentation d’un système de surveillance des feux de forêts basé sur les
réseaux de capteurs sans fils.
Devant les membres du jury :
Président du jury :
K. BOUAMRANE,
MCA
Université d’ORAN.
Encadreur :
L. SEKHRI,
MCA
Co-Encadreur :
B. KECHAR,
MCA
Examinateur :
G. BELALEM,
MCA
Examinateur :
B. ATMANI,
MCA
Promotion 2011/2012
Remerciements
Remerciements
La rédaction de ce mémoire m’a permis de rencontrer des gens nouveaux, qu’ils m’ont apporté
beaucoup d’aide et de soutien dans mes travaux de recherche et que je souhaite aujourd’hui les remercier
vivement.
Tout d’abord, je tiens à remercier mes encadreurs Mr L. SEKHRI et Mr B. KECHAR, qui ont été en
grande partie à l’origine de mon intérêt et de mon engouement pour les réseaux de capteurs sans fil et
surtout pour tout ce qui est lié à la manipulation pratique des capteurs et à leur programmation.
Je remercie tout particulièrement Mr B. KECHAR pour son aide, ses orientations et ses conseils
rigoureux et surtout ses remarques constructives sur le plan théorique et pratique qui m’ont permis
largement de mener mes travaux de recherches sans grande difficulté, malgré que ce domaine de
recherche est tout à fait nouveau pour moi.
Je remercie vivement Mr K.BOUAMRANE pour avoir accepté de présider le jury de ce mémoire.
Mes remerciements s’adressent aussi à Mrs G. BELALEM, B. ATMANI, qui ont accepté de juger ce
modeste travail.
Les premiers cours que j’avais pu suivre avec eux ont immédiatement éveillé ma curiosité et m’ont
donné envie d’approfondir ce domaine au point de m’amener aujourd’hui à rédiger un mémoire de
Magister traitant ce sujet.
Au cours du cursus de Magister, d’autres personnes ont fortement influencé mes connaissances sur les
réseaux quant à l’orientation de mes recherches et la réalisation de ce travail. Je souhaite donc ici saluer
les gens du CERIST (Ben Aknoun, Alger) Mr Aoudjaout abdelraouf. Je remercie aussi les gens du
service de conservations des forêts et le service météorologique de la wilaya d’ORAN qui m’ont facilité
l’accès aux informations techniques dans le domaine des feux de forêts.
Je tiens à remercier aussi tous les enseignants du département d’informatique ainsi que les différents
responsables académiques et pédagogiques de l’université d’ORAN (IGMO) qui ont participé de prés ou
de loin à ma formation universitaire durant le cycle de poste-graduation.
ii
Dédicace
À mes parents qui se sont sacrifié pour que j’aille aussi loin que possible dans
mes études.
À ma femme et ma fille, et tous mes frères et sœur ainsi qu’à tous les membres
de ma famille.
Enfin, je n’oublie pas mes amis et collègues.
iii
Table des matières
Table des matières
TABLE DES MATIERES ...................................................................................................................................... IIV
LISTE DES TABLEAUX .................................................................................................................................. VVIII
LISTE DES FIGURES .............................................................................................................................................IX
LISTE DES ABREVIATIONS ................................................................................................................................XI
INTRODUCTION GENERALE ................................................................................................................................ 1
PARTIE I : ETAT DE L’ART
CHAPITRE1 : LES RESEAUX DE CAPTEURS SANS FIL : PRESENTATION ET APPLICATIONS ................ 5
1.1
INTRODUCTION .......................................................................................................................................... 5
1.2
ORIGINE, DEFINITION DES RCSF ............................................................................................................ 6
1.3
CAPTEURS SANS FIL ARCHITECTURE ET TOPOLOGIE ...................................................................... 8
1.3.1 ARCHITECTURE MATERIELLE ...................................................................................................................... 8
1.3.2 ARCHITECTURE PROTOCOLAIRE ............................................................................................................... 11
1.3.3 ARCHITECTURE LOGICIELLE ..................................................................................................................... 18
1.3.4 ARCHITECTURE DU RESEAU ...................................................................................................................... 20
1.4
LES RCSF .................................................................................................................................................... 23
1.4.1 PRESENTATION ......................................................................................................................................... 23
1.4.2 PROTOCOLE DE COMMUNICATION DES RCSF: ZIGBEE ............................................................................. 24
1.4.2.1
Routage niveau réseau ...................................................................................................................... 24
1.4.2.2
Routage niveau applicatif ................................................................................................................. 24
1.4.3 PROBLEMATIQUES DES RCSF ................................................................................................................... 26
1.5
1.4.3.1
La tolérance de fautes ....................................................................................................................... 26
1.4.3.2
L'échelle............................................................................................................................................ 26
1.4.3.3
Les coûts de production .................................................................................................................... 26
1.4.3.4
L'environnement ............................................................................................................................... 26
1.4.3.5
La topologie de réseau ...................................................................................................................... 26
1.4.3.6
Les contraintes matérielles ................................................................................................................ 26
1.4.3.7
Les médias de transmission .............................................................................................................. 27
1.4.3.8
La consommation d'énergie .............................................................................................................. 27
APPLICATION DES RESEAUX DE CAPTEURS ..................................................................................... 27
1.5.1 DECOUVERTES DE CATASTROPHES NATURELLES ...................................................................................... 27
1.5.2 DETECTION D'INTRUSIONS ........................................................................................................................ 27
1.5.3 APPLICATIONS METIER ............................................................................................................................. 27
iv
Table des matières
1.5.4 CONTROLE DE LA POLLUTION ................................................................................................................... 28
1.5.5 AGRICULTURE .......................................................................................................................................... 28
1.5.6 SURVEILLANCE MEDICALE........................................................................................................................ 28
1.5.7 CONTROLE D'EDIFICES .............................................................................................................................. 28
1.5.8 APPLICATIONS COMMERCIALES ................................................................................................................ 28
1.6
CONCLUSION ............................................................................................................................................ 29
CHAPITRE 2 : ROBLEMATIQUES DES FEUX DE FORETET APPROCHES DE DETECTION ..................... 30
2.1
INTRODUCTION ........................................................................................................................................ 30
2.2
PYROLOGIE FORESTIERE ....................................................................................................................... 30
2.3
DEFINITION DU FEU ................................................................................................................................ 31
2.4
FEUX DE FORETS ..................................................................................................................................... 31
2.5
LA COMBUSTION ..................................................................................................................................... 31
2.6
PRESENTATION DES FORETS DE LA VILLE D’ORAN – OUEST D’ALGERIE ................................. 31
2.7
ÉVOLUTION DES SYSTEMES FORESTIERS DE DETECTION D'INCENDIE ..................................... 32
2.8
FIRE_SENSOR_SOCK................................................................................................................................ 35
2.9
ÉTUDE DES PERFORMANCES DES RESEAUX DE CAPTEURS SANS FIL ....................................... 36
2.10
CONCEPTION DU SYSTEME DE DETECTION DES FEUX DE FORET............................................... 40
2.11
L’ETUDE COREENNE ............................................................................................................................... 40
2.12
L’ETUDE CANADIENNE .......................................................................................................................... 41
2.12.1
L’INDICE DU COMBUSTIBLE LEGER (ICL) [FFMC : FINE FUEL MOISTURE CODE] ................................ 43
2.12.2
L’INDICE DE L’HUMUS (IH) [DMC : DUFF MOISTURE CODE] ............................................................... 43
2.12.3
L’INDICE DE SECHERESSE (IS) [DC : DROUGHT CODE] ........................................................................ 43
2.12.4
L’INDICE DE PROPAGATION INITIALE (IPI) [ISI : INITIAL SPREAD INDEX] ............................................ 44
2.12.5
L’INDICE DU COMBUSTIBLE DISPONIBLE (ICD) [BUI : BUILD UP INDEX] ............................................. 44
2.12.6
L’INDICE FORÊT-MÉTÉO (IFM) [FWI : FIRE WEATHER INDEX] ........................................................... 44
2.13
ALGORITHME DE DETECTION CANADIEN ......................................................................................... 46
2.14
CONCLUSION ............................................................................................................................................ 47
PARTIE II : CONTRIBUTIONS
CHAPITRE 3 : CONCEPTION ET OUTILSD’IMPLEMENTATION ................................................................... 49
3.1
INTRODUCTION ........................................................................................................................................ 49
3.2
APPROCHE DE DETECTION DES FEUX DE FORETS ADOPTEE ....................................................... 49
3.2.1 MODULE DE COLLECTE DE DONNEES ........................................................................................................ 50
v
Table des matières
3.2.2 MODULE DE COMMUNICATION ................................................................................................................. 50
3.2.3 MODULE D’ANALYSE ................................................................................................................................ 50
3.3
AMELIORATION DE LA METHODE CANADIENNE ............................................................................ 50
3.3.1 LA VERSION ORIGINALE ............................................................................................................................ 50
3.3.2 MODIFICATIONS APPORTES A LA METHODE CANADIENNE ........................................................................ 50
3.3.2.1
3.4
Hypothèses ....................................................................................................................................... 51
AMELIORATIONS DE LA METHODE COREENNE ............................................................................... 51
3.4.1 LA VERSION ORIGINALE ............................................................................................................................ 51
3.4.2 MODIFICATIONS APPORTES A LA METHODE COREENNE............................................................................ 51
3.4.2.1
3.5
Hypothèses ....................................................................................................................................... 51
MODELISATION UML DE L’ENVIRONNEMENT D’EVALUATION ET DE TEST ............................ 52
3.5.1 DIAGRAMMES DE SEQUENCE .................................................................................................................... 52
3.5.1.1
Configuration et déploiement ........................................................................................................... 52
3.5.1.2
Récupération des données ................................................................................................................. 53
3.5.2 DIAGRAMME DE CAS D’UTILISATION ........................................................................................................ 54
3.6
L’ENVIRONNEMENT D’EVALUATION ET DE TEST ........................................................................... 55
3.6.1 LA MIB520 (SINK OU STATION DE BASE) ................................................................................................. 55
3.6.1.1
ISP (In System Processor) ................................................................................................................ 57
3.6.1.2
Programmation des capteurs par la MIB520 ..................................................................................... 57
3.6.1.3
Reset ................................................................................................................................................. 57
3.6.1.4
JTAG ................................................................................................................................................ 57
3.6.1.5
Alimentation ..................................................................................................................................... 57
3.6.1.6
La station de base ............................................................................................................................. 58
3.6.2 LA CARTE MPR2600 (MICAZ) ................................................................................................................. 58
3.6.2.1
Schéma et diagramme bloc du MPR2600 / MICAz .......................................................................... 59
3.6.2.2
Radio ................................................................................................................................................ 60
3.6.2.3
Flash Data Logger et Serial ID Chip ................................................................................................. 60
3.6.2.4
Atmega128 ....................................................................................................................................... 60
3.6.2.5
La batterie ......................................................................................................................................... 61
3.6.3 CARTE DE CAPTURE MTS400 ................................................................................................................... 62
3.6.3.1
3.7
Structure de paquet ........................................................................................................................... 63
PRESENTATION DES LOGICIELS UTILISES......................................................................................... 63
3.7.1 OUTILS DE VISUALISATION ....................................................................................................................... 63
3.7.1.1
Vérifier l'installation de PostgreSQL ................................................................................................ 64
3.7.1.2
Visualisation des onglets .................................................................................................................. 66
3.7.1.3
Processus d’obtention des données en live par les capteurs .............................................................. 68
vi
Table des matières
3.7.2 OUTILS DE RECUPERATION DES DONNEES ................................................................................................. 68
3.7.2.1
Sous l’environnement Windows ....................................................................................................... 68
3.7.2.2
Sous l’environnement Linux ............................................................................................................. 69
3.7.3 OUTILS DE PROGRAMMATION ................................................................................................................... 70
3.7.4 OUTILS DE SUPERVISION ........................................................................................................................... 72
3.7.5 OUTILS DE CONFIGURATION ..................................................................................................................... 73
3.7.6 OUTILS DE COMPILATION .......................................................................................................................... 75
3.7.7 OUTILS DE SIMULATION ............................................................................................................................ 76
3.8
PROGRAMMATION DES CAPTEURS ..................................................................................................... 77
3.9
CONCLUSION ............................................................................................................................................ 78
CHAPITRE 4 : MPLEMENTATION ET TESTS .................................................................................................... 79
4.1
INTRODUCTION ........................................................................................................................................ 79
4.2
IMPLEMENTATION DE LA METHODE CANADIENNE ....................................................................... 80
4.3
IMPLEMENTATION DE LA METHODE COREENNE ............................................................................ 80
4.4
ETUDE DETAILLEE ET CONCEPTION DES SYSTEMES ..................................................................... 81
4.4.1 LA METHODE CANADIENNE ...................................................................................................................... 81
4.4.1.1
Le cas pratique .................................................................................................................................. 82
4.4.1.2
Résultat de la simulation ................................................................................................................... 84
4.4.2 LA METHODE COREENNE .......................................................................................................................... 87
4.5
4.4.2.1
Le cas pratique .................................................................................................................................. 87
4.4.2.2
Résultats de simulation ..................................................................................................................... 88
COMPARAISON ENTRE LES DEUX SYSTEMES .................................................................................. 91
4.5.1 LE TEMPS CONSOMME ............................................................................................................................... 91
4.5.1.1
Par la cpu .......................................................................................................................................... 91
4.5.2 L’ENERGIE ................................................................................................................................................ 92
4.5.2.1
Par la cpu .......................................................................................................................................... 92
4.5.2.2
Par la radio ........................................................................................................................................ 93
4.5.2.3
Cas général ....................................................................................................................................... 93
4.5.3 LA PRECISION ........................................................................................................................................... 93
4.6
CONCLUSION ............................................................................................................................................ 94
ANNEXE A : TINYOS ET NESC ........................................................................................................................... 97
ANNEXE B : INDICES DE LA METHODE CANADIENNE .............................................................................. 102
BIBLIOGRAPHIE ................................................................................................................................................. 111
WEBOGRAPHIE ................................................................................................................................................... 114
vii
Liste des tableaux
Liste des Tableaux
Tableau 1
Comparaison des études d'un point de vue fonctionnel
2
Tableau 1.1
Comparaison de quelques plates-formes de nœuds capteurs
11
Tableau 1.2
Différentes technologies au niveau physique
14
Tableau 2.1
Mode de consommation énergétique
39
Tableau 2.2
Indice de danger de feu de forêt coréen
41
Tableau 2.3
Propriétés des trois indices d’humidité des combustibles
44
Tableau 2.4
Inflammation potentielle par rapport à la valeur ICL
45
Tableau 2.5
Le danger potentiel d’incendie d’après l’indice IFM
45
Tableau 3.1
Aspect technique de la MIB520
56
Tableau 3.2
Caractéristiques de quelques capteurs les plus courants
59
Tableau 3.3
Caractéristiques de MPR2600
60
Tableau 3.4
Alimentation du MPR2600
61
Tableau 3.5
Consommation d’énergie sur un MPR2600
61
Tableau 3.6
Caractéristiques du MTS400
62
Tableau 3.7
Structure du paquet MTS400
63
Tableau 3.8
Définition des champsd’un paquet MTS400
63
Tableau 4.1
Comparaison entre le temps de réponse des deux systèmes
92
Tableau 4.2
Comparaison entre la consommation d’énergie (CPU) des deux systèmes
92
Tableau 4.3
Comparaison entre la consommation d’énergie (radio) des deux systèmes
93
viii
Liste des figures
Liste des figures
Figure 1.1
Composants de base d’un nœud capteur (en trait plein) et composants optionnels
(en pointillé)
10
Figure 1.2
Vue protocolaire d’un nœud capteur
13
Figure 1.3
Classification des protocoles de routage
16
Figure 1.4
Architecture logiciel d’un nœud capteur
19
Figure 1.5
Interconnexion d’un RCSF avec Internet
20
Figure 1.6
Différentes architectures pour un réseau d’acquisition
21
Figure 1.7
Différents types de Sink dans un RCSF : (a) Un nœud capteur, (b) Système mobile
plus puissant, (c) Point d’accès relié à un autre réseau
22
Figure 1.8
Réseau de capteur sans fil
23
Figure 1.9
Applications des RCSF
29
Figure 2.1
Incendie de la forêt du lion en 2009
31
Figure 2.2
Schéma du National Fire Danger Rating System
34
Figure 2.3
Structure de D-FLER
35
Figure 2.4
Protection thermique d’un capteur
35
Figure 2.5
Exemple de protocole d'inondation ALARME-SET
37
Figure 2.6
Recherche d’un nœud capteur
38
Figure 2.7
Structure de l’IFM
42
Figure 2.8
Différentes formes de l’IFM
46
Figure 2.9
Algorithme Canadien de détection des feux de forêt
47
Figure 3
Schéma bloc de l’approche proposée
49
Figure 3.1
Structure de l’indice forêt météo adapté
51
Figure 3.2
Diagramme de séquence modélisant le déploiement et la configuration
52
Figure 3.3
Diagramme de séquence modélisant le déploiement/configuration des capteurs et
le relais via la radio
53
Figure 3.4
Diagramme de séquence modélisant la collecte des données en mode mono saut
53
Figure 3.5
Diagramme de séquence modélisant la collecte des données en mode multi saut
54
Figure 3.6
Diagramme de cas d’utilisation qui modélise le raisonnement suivie
54
Figure 3.7
Schéma simplifiée du banc d’essai
55
Figure 3.8
Architecture interne du MIB520CB
56
Figure 3.9
MIB520CB attaché avec le capteur
56
Figure 3.10
MPR2600 avec antenne standard
58
Figure 3.11
Schéma fonctionnelle de MPR2600
59
Figure 3.12
L’onglet Mode du MoteView
64
ix
Liste des figures
Figure 3.13
L’onglet Gateway du MoteView
65
Figure 3.14
L’onglet Sensor Board du MoteView
65
Figure 3.15
MoteView : Données temps réel de 4 capteurs branchés avec la station
66
Figure 3.16
Présentation des données sous forme de courbes
67
Figure 3.17
Présentation graphique des capteurs
67
Figure 3.18
Récupération des données par Cygwin
69
Figure 3.19
Réservation du port série pour l’écoute
69
Figure 3.20
Exemple de lectures brutes envoyées par les capteurs
70
Figure 3.21
Vue des paquets reçus d’un nœud capteur par Xsniffer
72
Figure 3.22
Le bouton program Mote
73
Figure 3.23
Fenêtre de programmation des capteurs
73
Figure 3.24
Le choix de la station de base
74
Figure 3.25
Vue de Programmer’s Notepad
75
Figure 3.26
Simulation d’énergie par Avrora
77
Figure 4.1
Schéma bloc résume la méthodologie suivi
79
Figure 4.2
Code source NesC pour mesurer l’humidité
80
Figure 4.3
Code source NesC pour mesurer la température
80
Figure 4.4
Code source NesC pour mesurer la luminosité
81
Figure 4.5
Commande de chargement d’un capteur
82
Figure 4.6
Réception des données brutes
83
Figure 4.7
Réception des données formatées en décimal
84
Figure 4.8
Calcul de l’indice IFM par une autre manière
84
Figure 4.9
Simulation de l’énergie par avrora
86
Figure 4.10
Mesure du nombre de cycle de cpu
86
Figure 4.11
Mesure du nombre de cycle de la radio
87
Figure 4.12
Réception des données brutes
87
Figure 4.13
Réception des données formatée en décimal
88
Figure 4.14
Calcul de l’indice coréen par une autre manière
88
Figure 4.15
Simulation de l’énergie
89
Figure 4.16
Mesure du nombre de cycle du cpu
90
Figure 4.17
Mesure du nombre de cycle de la radio
90
Figure 4.18
Méthodologie adopté pour l’étude comparative
91
Figure 4.19
Temps consommé par la cpu
91
Figure 4.20
Consommation d’énergie par les deux systèmes
93
x
Liste des abréviations
Liste des abréviations
ARQ
BS
CCA
CCD
CSMA
DARPA
DSN
FEC
FTDI
FWI / IFM
GPS
GSM
ICD / BUI
ICL / FFMC
IH / DMC
IP
IPI / ISI
IS / DC
Kbps
Ko
MAC
MANET
MODIS
NFDRS
NOAA
OS
PAN
PC
PDA
QoS
RAM
RCSF
RF
RTS/CTS
SenIT
SMEM
TDMA
USB
WLAN
WPAN
Automatic Repeat Request
Base Station
Clear Channel Assessment
Charge-Coupled Device
Carrier Sense Multiple Access
Defense Advanced Research Projects
Distributed Sensor Networks
Forward Error Correction
Future Technology Devices International
Fire Weather Index / Indice forêt météo
Global Positioning System
Global System for Mobile communications
Indice du Combustible Disponible / Build Up Index
Indice du Combustible Léger / Fine Fuel Moisture Code
Indice de l’Humus / Duff Moisture Code
Internet Protocol
Indice de Propagation Initiale / Initial Spread Index
Indice de Sécheresse / Drought Code
Kilo bits par seconde
Kilo octet
Medium Access Control
Mobile Ad hoc NETworks
Moderate Resolution Imaging Spectroradiometer
National Fire Danger Rating System
National Oceanic and Atmospheric Administration
Operating System
Personal Area Network
Personal Computer
Personal Digital Assistant
Quality of Service
Random Access Memory
Réseaux de Capteurs Sans Fil
Radio Frequency
Request To Send / Clear To Send
Sensor Information Technology
Systèmes Micro-Electro-Mécaniques
Time Division Multiple Access
Universal Serial Bus
Wireless Local Area Network
Wireless Personal Area Network
xi
Introduction générale
Le nombre de terminaux mobiles communicants a fortement progressé ces dernières années. Cette
croissance s’est accompagnée de l’intégration de technologies comme WiFi ou Bluetooth dans de
multiples appareils utilisés quotidiennement par une grande partie de la population. La connectivité
supportée par ses équipements offre la possibilité de constituer des réseaux de façon spontanée. Les
réseaux de capteurs sans fil (RCSF) sont destinés à collecter des informations dans des environnements
hostiles auxquels l'homme n'a pas toujours accès. Un capteur analyse son environnement et propage les
données collectées aux capteurs appartenant à sa portée radio. Chaque capteur du réseau doit relayer à son
tour l'information aux capteurs situés dans sa portée radio et ainsi de suite jusqu’à ce que cette
information arrive à un point de collecte appelé puis ou Sink. De tels réseaux, capables d'analyser et de
surveiller une zone définie, présentent des avantages indéniables dans les domaines aussi variés que
l'industrie, la recherche environnementale ou la domotique.
Un incendie est un phénomène qui échappe au contrôle de l’homme, tant en durée qu’en étendue. Le
feu est un des principaux ennemis de la forêt. Chaque année, le feu brûle une importante superficie de
forêts surtout pendant l'été. Un feu de forêt est par définition, un sinistre situé sur des massifs couverts de
bois dont les causes très diverses peuvent être naturelles, ou contrairement à cela, dues aux actes des êtres
humains.
Selon [web 02], environ 13 millions d’hectares de forêts sont détruits chaque année dans le monde,
c'est environ 200 km de forêts abattus par jour, l'équivalent de 36 terrains de football par minute, dont
60000 incendies par an en Europe. En se référant aux informations publiées par la FAO 1 [web 01], les
feux de forêt détruisent chaque année jusqu'à 700000 ha en région méditerranéenne. Souvent, plus de
100000 incendies éclatent durant la saison chaude. Dans certains pays, on enregistre plus de 20000 feux
de forêt par an. En Algérie, plus de 30600 ha ravagés par les feux en 2011, dont 2.304 ha2 détruits du 1er
juin au 20 août [web 03], et 30632 ha ont été ravagés en 2010, et 26183 ha en 2009 contre 26015 ha en
2008 selon un bilan présenté par la direction générale des forêts. La déforestation représente 20% des
émissions de gaz à effet de serre, principalement sous forme de CO2. En 2004, ces émissions ont atteint
8700 milliards de kilos d'équivalent CO2, soit la troisième source d'émissions de gaz à effet de serre au
monde.
Face à ces horribles chiffres, il devient très urgent de revoir les méthodes archaïques de lutte contre les
feux de forêts utilisées jusqu’à ce jour dans le contexte local, et d’introduire les nouvelles technologies de
l’information et de communication, comme par exemple la technologie des RCSF, pour mieux
appréhender ce domaine et améliorer la qualité de détection dans la perspective de diminuer les effets
1
2
Food and Agriculture Organization
Hectares
1
néfastes des feux de forêt. Il s’agit principalement de prévoir des techniques fiables de détection basées
sur les capteurs et d’assurer un cheminement fiable et sécurisé des alertes générées par les capteurs pour
pouvoir informer en temps réel les autorités compétentes du feu déclenché et la possibilité de le localiser.
En parle alors de protocoles de communications adaptés au niveau MAC(Medium Access Control),
routage, transport et application pour remonter l’information de détection via le réseau en un temps
opportun pour son exploitation immédiate par les services des feux de forêt.
L’objectif essentiel qui résulte de la gravité de la problématique des feux de forêt et de l’incapacité des
méthodes traditionnelles pour leur détection, est de concevoir un système de détection des feux de forêt
capable de s'adapter aux conditions climatiques locales en employant la technologie des réseaux de
capteurs sans fil. Ainsi, nos contributions dans ce mémoire s’articulent principalement autour de deux
points essentiels. Dans le premier, nous avons réalisé une étude approfondie sur les travaux de recherche
actuels et ceux qui ont été déjà réalisés dans ce domaine. Parmi les systèmes de détection de feux de forêt
étudiés, nous nous sommes intéressés plus particulièrement aux deux systèmes suivants : un système qui
est largement utilisé dans la pratique par plusieurs pays, à savoir le système Canadien, et l’autre concerne
le système Coréen. Nous avons mené une étude comparative basée sur des expérimentations réelles en
utilisant un banc d’essai de capteurs de type MICA-Z de la firme CrossbowTM. Cette étude constitue la
partie fondamentale de notre première contribution. Le deuxième point est la conséquence directe de la
première qui consiste à proposer une méthode adaptée et efficace de détection de feux de forêts parmi les
deux méthodes étudiées, au niveau des services compétents des feux de forêt de la région ouest du pays
en général et plus particulièrement la wilaya d’Oran.
Dans ce mémoire, environ 40% des efforts fournis sont consacrés à la recherche et à l’étude
bibliographique des différentes techniques de détection des feux de forêt fondées sur l’emploi et
l’intégration de la technologie des capteurs. Ces techniques peuvent être résumées en trois classes :
méthodes de détection, méthodes de détection et de transmission de l’alarme et méthodes de prévention.
Détection
Détection et transmission de
Prévention
l’alarme

Méthode Coréenne [01]
Méthode Canadien [02]



Méthode Américaine [03]
Méthode Turque[04]


Méthode Portugaise [05]
Méthode Libanaise [06]


Tableau 1: Comparaison des études d'un point de vue fonctionnel
2
Le tableau 1 résume les méthodes de détection des feux de forêt selon leurs rôles. La meilleure
approche à notre avis est celle qui assure les trois fonctions à la fois.
Les 60%
des efforts fournis dans ce mémoire sont dédiés à la conception de l’environnement
d’évaluation et de tests et à l’implémentation et l'évaluation des deux méthodes de détection précédentes
(méthodes Canadienne et Coréenne) dans un environnement de développement orienté capteur qui est
tout a fait nouveau pour nous. Nous tenons à souligner à ce niveau que contrairement aux méthodes de
conception et d’évaluations basées sur l'outil de simulation, qui est très répandue dans la pratique, nous
avons opté pour une étude plus réaliste en développant des implémentations et des tests dans un
environnement réel. Il s’agit principalement des tâches suivantes :
 Description de l’environnement d’évaluation et de tests à l’aide de certains diagrammes d’UML.
 Installation et configuration des outils logiciels nécessaires pour la conception et l'évaluation
(TinyOS, MoteView,..).
 Programmation en nesC des deux méthodes de détection.
 Déploiement du réseau de capteurs, tests et analyse des résultats.
Les résultats d'évaluation obtenus à l’issue de ce mémoire nous encouragent à proposer réellement
l'intégration de cette technologie des RCSF comme une première solution technologique efficace de lutte
contre les feux de forêt et la réaliser pratiquement à une échelle plus ou moins large en collaboration avec
les services des feux de forêt de la wilaya d’Oran. La comparaison effectuée entre les deux systèmes de
détection utilisée nous permet de réajuster les paramètres du système choisi pour qu’il soit plus adapté
aux conditions climatiques de la région ouest du pays. De ce fait, nous estimons avoir réalisé à travers ce
travail de recherche une transition qualitative en partant des méthodes archaïques utilisées à grande
échelle jusqu'à ce jour vers l'intégration des nouvelles technologies des RCSF dans le domaine de
détection des feux de forêts.
Ce mémoire est composé de deux parties: une première partie est consacrée à l'état de l'art (chapitre 1
et 2) tandis que la deuxième porte sur nos contributions (chapitres 3 et 4). L chapitre 1 présente un état de
l’art récent sur les réseaux de capteurs sans fil et leurs applications sociétales et industrielles. Le chapitre
2 est consacré au phénomène des feux de forêts : définitions, évolution des systèmes de détection des feux
de forêts et techniques de protection des capteurs contre la destruction par le feu. Un état de l'art sur les
deux méthodes de détection des feux de forêt est aussi présenté.
Le chapitre 3 traite des modifications apportées aux algorithmes de détectionet la conception de
certains aspects de l'environnement d'expérimentation. Le chapitre 4 abord l’implémentation, tests et
analyses. Enfin le mémoire se termine par une conclusion et quelques perspectives futures.
3
Partie 1 : Etat de l’art
PARTIE I : Etat de l’art
4
CHAPITRE1 : Les réseaux de capteurs sans fil, présentation et applications
1
Les réseaux de capteurs sans fil :
présentation et applications
1.1 Introduction
Depuis leur création, les réseaux de communication sans fil ont connu un succès croissant au sein des
communautés scientifiques et industrielles. Grâce à ces divers avantages, cette technologie a pu
s'instaurer comme acteur incontournable dans les architectures réseaux actuelles. Le média hertzien offre
en effet des propriétés uniques, qui peuvent être résumées en trois points : la facilité du déploiement,
l'ubiquité de l'information et le coût réduit d'installation. Au cours de son évolution, le paradigme sans fil
a vu naître diverses architectures dérivées, telles que : les réseaux cellulaires, les réseaux locaux sans fil et
autres. Durant cette dernière décennie, une architecture nouvelle a vu le jour : les réseaux de capteurs sans
fil (RCSF)[07][08][09][10].Ce type de réseaux résulte d'une fusion de deux pôles de l'informatique
moderne : les systèmes embarqués et les communications sans fil. Les RCSF, ou « Wireless Sensor
Network » sont souvent considérés comme étant les successeurs des réseaux ad hoc. En effet, les RCSF
partagent avec les MANET (Mobile Ad hoc NETworks) plusieurs propriétés en commun, tel que l'absence
d'infrastructure et les communications sans fil, mais l'une des différences clés entre ces deux architectures
est le domaine d'application ; contrairement aux réseaux MANET, qui n'ont pas pu connaître un vrai
succès, les RCSF ont su attirer un nombre croissant d'industriels, vu leur réalisme et leur apport concret.
Les processus industriels, les applications militaires de suivie de cibles (tracking), le monitoring
d'habitat, ainsi que l'agriculture de précision ne sont que quelques exemples d'une panoplie vaste et variée
d'applications possibles du suivi continu offerte par les RCSF. Grâce à ce potentiel riche en applications,
les RCSF ont su se démarquer de leur origine MANET et attirer de grandes firmes à travers le monde,
5
telles qu’IBM, Sun, Intel et Philips. Malheureusement, les RCSF ne sont pas parfaits ! À cause de leur
faible coût et leur déploiement dans des zones parfois hostiles, les nœuds capteurs sont assez fragiles et
vulnérables à diverses formes de défaillances : cassure, faible énergie... etc. Ces problèmes rendent les
RCSF des systèmes à fragilité innée, qui doivent être considérés comme une propriété normale du réseau.
1.2 Origine, définition des RCSF
Comme toute technologie nouvelle [10], les applications militaires, durant les années 80 ont été les
premières à bénéficier des efforts de recherche moderne et de développement dans le domaine des RCSF.
Deux programmes importants de l’agence américaine de la défense DARPA (Defense Advanced Research
Projects) ont marqué l’histoire des RCSF: le programme DSN (Distributed Sensor Networks) et le
programme SenIT (Sensor Information Technology). Le premier visa à développer de nouvelles
techniques spécifiques pour les réseaux de capteurs. Le second, considéré comme un programme
ambitieux, chercha fondamentalement à étudier la possibilité d’extension du réseau Arpanet (le
prédécesseur d’Internet) pour inclure les réseaux de capteurs.
Au début des années 90, la technologie sans fil était principalement stagnante. Mais, depuis 1996, elle
a subit une croissance exponentielle. La largeur de bande sans fil dans la plupart des offres industrielles a
augmenté, entre 1997 et 2002, par un facteur de 28. D'autre part, le progrès récent dans la fabrication des
circuits capteurs (technologie SMEM (Systèmes Micro-Electro-Mécaniques)) a ouvert de nouvelles
perspectives en termes de coût, fiabilité, exactitude et faible besoin en énergie électrique. Tandis que la
plupart des capteurs basés sur la technologie SMEM ont été en phase de recherche, un progrès étonnant
en matière d’investissement industriel et gouvernemental à l’échelle mondiale a été constaté dans ce
secteur. En effet, cet investissement passa de $2 millions en 1991 à $35 millions en 1995 et il fut estimé à
cette époque à $300 millions en 2001. Cet avancement spectaculaire a suscité le besoin grandiose de
méthodologies et de technologies qui permettront une utilisation plus efficace et effective des différentes
sortes d’applications des réseaux de capteurs sans fil. D’autres facteurs qui ont poussé vers cette
motivation incluent la mobilité de certains dispositifs de calcul informatique tels que les téléphones
cellulaires et les PDA ainsi que la capacité d’intégrer ces dispositifs dans le monde physique [12].
La technologie des RCSF est le résultat de convergence des technologies de fabrications de circuits
intégrés (ou nanotechnologie), de communications sans fil et des systèmes micro-électro-mécaniques. Il
existe plusieurs définitions pour un RCSF dont elles dépendent souvent de l’application considérée. Nous
avons retenue la définition suivante, inspirée de celle donnée par la DARPA, qui nous semble plus proche
de notre problématique traitée dans ce mémoire : « Un RCSF est un ensemble de petits nœuds capteurs
variant de quelque dizaines d’éléments à plusieurs centaines, voir des milliers déployés dans une zone
d’intérêt. Les nœuds capteurs sont capables de réaliser les fonctions de capture, de traitement et ne sont
pas intégrés à aucune architecture pré-existante de réseau, mais communiquent à l’aide d’un réseau
6
adhoc sans fil. L’alimentation électrique de chaque nœud capteur est assurée par une batterie
individuelle dont la consommation pour la communication et le calcul lié au traitement de l’information
doit être optimisée. »
Les RCSF partagent quelques caractéristiques importantes avec les réseaux adhocs, qui eux aussi ont
connu ces dernières années un intérêt de recherche intense. Comme exemple de ces caractéristiques on
trouve le besoin d’auto-organisation, l’opération multi-sauts sans fil et la variabilité temporelle de la
topologie ainsi que d’autres paramètres réseaux. Cependant, il y a plusieurs différences fondamentales
entre ces deux types de réseaux :
• La tâche principale d’un nœud capteur ne consiste pas seulement à servir directement un utilisateur
humain comme c’est le cas pour les réseaux adhocs, mais de collaborer avec d’autres nœuds capteurs
pour la collecte des données de l’environnement physique afin de satisfaire les besoins d’une
application spécifique.
• Dans les réseaux adhocs, les nœuds mobiles se déplacent typiquement avec leurs utilisateurs auxquels
ils sont attachés (donc possibilité offerte pour rechargement ou remplacement de la batterie), par
exemple des soldats dans une opération commando militaire ou des équipes d’intervention dans une
opération de recherche dans une zone désastreuse, alors que les nœuds capteurs sont dans la plupart
des cas stationnaires et placés dans des endroits désignés ou non de l’espace de déploiement. Un
changement de topologie peut avoir lieu dans un RCSF dans les cas suivants : certains nœuds
basculent en mode veille pour économiser de l’énergie, ou certains nœuds cessent de fonctionner par
manque d’énergie, ou à cause d’erreurs logiciels ou parfois par endommagement externe (passage d’un
animal ou d’un engin).
• Les RCSF sont souvent conçus pour servir une seule application ou un nombre très réduit
d’applications existantes. Ceci est exploité par ce qu’on appelle la conception centrée donnée (Data
driven) dans laquelle non seulement l’application, qui a une connaissance préalable des donnés
collectées, mais également les protocoles réseaux connaissent ces données qu’ils transportent. Ces
données peuvent ainsi influencer le comportement des protocoles. Un exemple typique est celui de
l’agrégation effectuée par certains nœuds relais : au lieu de relayer directement les paquets de données,
le nœud agrégateur effectue un calcul sur ces paquets (calcul de la moyenne par exemple) et transmet
seulement un seul paquet contenant la valeur agrégée. Ceci permettra d’économiser à la fois la bande
passante et l’énergie.
• Les réseaux adhocs sont déployés en un nombre relativement faible, de l’ordre de centaines de nœuds,
par contre pour les RCSF ce nombre peut atteindre des milliers voir des centaines de milliers de
nœuds. C’est la raison pour laquelle le passage à l’échelle dans toute étude scientifique relative aux
RCSF constitue un vrai défi à relever.
7
• Bien que les considérations de consommation d’énergie sont le point focal pour les deux types de
réseaux avec comme préoccupation beaucoup plus importante pour les RCSF, la durée de vie des
applications dans le cas des réseaux adhocs semble être plus courte que celle des applications des
RCSF. Par exemple, un réseau adhoc dédié aux communications dans une application d’intervention
d’urgence (séisme, accident, etc.) doit fonctionner pour une période très limitée (quelques heures ou
dans le pire des cas quelques jours), alors qu’un RCSF pour les applications de surveillance
environnementale est conçu pour fonctionner pour un certain nombre d’années.
• Dans un RCSF, il existe en général un seul Sink récepteur (approche mono Sink), ou dans certains cas
plusieurs Sink récepteurs (approche multi Sink), par contre dans un réseau adhoc tout nœud mobile
peut être à tout moment récepteur. De même, la direction du flux dans un RCSF est simple : soit il
s’agit de paquets de données générés par les nœuds capteurs et qu’il faut les transporter directement
vers le Sink, soit des paquets de contrôle (requêtes, paramètres de reconfiguration) envoyés par le Sink
au reste des nœuds du réseau en mode unicast (un à un), multicast (un à plusieurs) ou broadcast
(diffusion). Au contraire, les nœuds mobiles individuels dans un réseau adhoc peuvent initier des
communications avec n’importe quel autre nœud du réseau (mode pair à pair ou peer to peer) [13].
1.3 Capteurs sans fil architecture et topologie
Les éléments de base [10] qui forment un réseau de capteurs sans fil sont les nœuds capteurs, qui
possèdent en général une architecture matérielle, une architecture protocolaire et une architecture
logicielle.
1.3.1 Architecture matérielle
Celle-ci ressemble le plus souvent à l’architecture donnée par la figure 1.1. Un nœud capteur consiste
en un ensemble de sous-systèmes : sous-systèmes de capture, sous système de traitement, sous système de
communication et sous système de puissance électrique. La présence d’autres sous-systèmes additionnels
tels que le sous-système de localisation et le sous-système de mobilité ainsi qu’un module d’extraction
d’énergie, dépend de l’application et des contraintes économiques.
• Sous système de capture : composé essentiellement des circuits capteurs, d’actionneurs dans le cas où
l’intervention dans l’environnement est envisagée, et des convertisseurs de type analogique digital/
digital analogique. Comme exemples de capteurs, on trouve des capteurs de température, de tension,
d’humidité, de vitesse de vent, de lumière ou accéléromètres. Il est supposé que ces capteurs sans
capables de collecter des données à partir de l’environnement avec une dépense minimale d’énergie.
• Sous systèmes de traitement : il est considéré comme le cœur du nœud capteur et regroupe à la fois le
microcontrôleur et la mémoire. Le microcontrôleur exécute les logiciels d’application et la pile
protocolaire. Celui utilisé dans les nœuds capteurs est conçu en général pour consommer moins
d’énergie et non pas pour être plus performant. Dans plusieurs conceptions de nœuds capteurs, des
8
processeurs 8-bit et 16-bit, tels que le MSP430 de Texas Instruments ou ATmega 128 de Atmel avec
des vitesses d’horloge estimées à quelques dizaines de MHz, sont utilisés. La mémoire représente le
plus souvent seulement quelques Ko de RAM et quelques dizaines de Ko de Mémoire flash pour le
stockage du code et des données [Web 13].
• Sous système de communication : il s’agit d’un module radio ou transceiver sans fil équipé d’une
antenne omnidirectionnelle et responsable de la modulation en émission et de la démodulation en
réception des données digitales sur un canal sans fil. La plupart des conceptions de nœuds capteurs
prévoient la bande de fréquence radio sans licence, industrielle, scientifique et médicale ISM à 2.4
GHz, pour laquelle plusieurs circuits transceivers sont disponibles sur le marché. Les concepteurs de
ces transceivers dédiés aux nœuds capteurs privilégient l’optimisation de la consommation d’énergie
plutôt que le débit ou le taux d’erreur. Ceci peut être effectué par une conception à faible puissance et
un choix relativement petit des puissances de sortie. Les transceivers qu’on trouve aujourd’hui dans
les nœuds capteurs (comme par exemple RF Monolithics TR 1001 ou Chipcon CC 1000 et 2420) ont
une puissance de sortie de l’ordre de 1mW, alors que celle utilisée dans les réseaux locaux sans fil de
la norme 802.11 est plus de 100mW, ou celle des réseaux cellulaires de type GSM qui dépasse
largement cette valeur. Ainsi, le débit de transmission des données de ces transceivers varie entre des
dizaines et des centaines de Kbps.
• Sous système d’énergie : la batterie, en tant qu’alimentation électrique principale, fournit l’énergie
électrique aux différents sous-systèmes d’un nœud capteur. Les batteries utilisées dans ce cas ont une
quantité d’énergie très limitée, malgré que certains types de batteries arrivent à ce rechargé eux-mêmes
suite à certains processus chimiques sous certaines conditions. Il est impraticable ou souvent
impossible de remplacer ou de recharger les batteries des nœuds capteurs dans la plupart des
applications des RCSF. Ainsi, cette quantité très limitée d’énergie implique une durée de vie très
limitée des nœuds capteurs et par conséquent une durée de vie très limitée du réseau. Il est vrai que les
différentes techniques d’extraction de l’énergie à partir de l’environnement ambiant (solaire,
vibrationnelle, gradients de température, humaine, …) sont à l’heure actuelle très limitées, mais les
combiner aux différentes stratégies effectives de gestion de puissance au sein d’un nœud capteur
permet d’étendre d’une manière significative sa durée de vie.
9
Échange de données
Alimentation en énergie
Bits
transmis
Sous système
de localisation
Données brutes
collectées
Sous système
de capture
Sous système
de mobilité
Sous système
de traitement
Sous système
Radio
Antenne
Données brutes
/informations
μControleur
Mémoire
Sous système d’énergie
Environnement
Energie
extraite
Figure 1.1: Composants de base d’un nœud capteur (en trait plein) et composants optionnels
(en pointillé)
• Sous système de localisation : permet de localiser un nœud capteur dans son espace de déploiement,
qui peut être bidimensionnel ou tridimensionnel. Cette opération peut être accomplie soit à l’aide d’un
circuit GPS (Global Positioning System) ou à l’aide de certaines méthodes de triangulation radio.
L’installation d’un GPS au niveau de chaque nœud capteur offre une flexibilité et une précision pour le
calcul des coordonnées géographiques. Mais, ceci à pour conséquence l’augmentation du coût de la
production, la consommation énergétique et la complexité matérielle du nœud capteur. Comme les
nœuds capteurs d’un RCSF sont stationnaires, des solutions plus ou moins économiques sont souvent
utilisées. Elles consistent soit à estimer la localisation d’un nœud en se basant sur la longueur de l’onde
radio,soit à équiper certains nœuds capteurs par des circuits GPS (appelés nœuds balises ou beacons)
et prévoir des méthodes distribuées de calcul des coordonnées du reste des nœuds capteurs en se
référant à ces nœuds balises.
• Sous système de mobilité : permet à un nœud capteur de se déplacer librement dans l’espace de
capture. L’intégration de ce circuit au sein d’un nœud capteur est dictée en général par les exigences de
l’application et a aussi des conséquences en termes de coût, d’énergie et de complexité matérielle.
Cependant, ajouter un tel degré de liberté de mobilité à un nœud capteur peut concerner seulement un
sous ensemble restreint de nœuds capteurs et peut s’inscrire aussi dans une perspective d’économie
10
d’énergie, si on part du principe qu’un déplacement dans des conditions favorables coûte moins cher
qu’une transmission radio relativement à une certaine distance.
Type de Nœud
Telos
(Intel)
Mica2
(Berkeley)
SunSPOT
(Sun )
Imote2
(Crossbow)
Type de Micro
contrôleur
RAM
ROM
Bande passante
Capacité de la
batterie
Portée maximale
8 Mhz,
8 bits
2 Ko
256 Ko
250 Kbps
Coin cell
1000 mAh
100 m
Chipcon CC2420
2.4GHz 250
Kbps IEEE
802.15.4
7.37 MHz,
8 bits
4 Ko
512 Ko
38.4 Kbps
2xAA
5700 mAh
150-300 m
Chipcon CC1000
315/433/33/868/91
6 MHz 38.4
Kbauds
180 MHz,
32 bits
512 Ko
4 Mo
250 Kbps
Rechargeable
750 mAh
100 m
13-416 MHz,
16 bits
256 Ko
32 Mo
250 Kbps
3xAAA
3750 mAh
100 m
Chipcon CC2420
2.4GHz 250 Kbps
IEEE 802.15.4
Chipcon CC2420
2.4GHz 250 Kbps
IEEE 802.15.4
TinyOS
Interface USB
Radio
Système
d’exploitation
Connexion au
PC
TinyOS
TinyOS
Squawk
(Machine virtuelle
Java)
Port série
Carte de
programmation
Interface USB
Tableau 1.1 : Comparaison de quelques plates formes de nœuds capteurs
Le tableau 1.1 présente une comparaison entre quelques plates formes de nœuds capteurs
commerciales, d’autres architectures au stade de prototypage dédiés à la recherche existent, par exemple :
BTnode (Europe), EYES (Europe-Suisse), ZigbeX Mote (Corée du sud), T-Engine (Japon), LiveNode
(France), BEAN (Brazilian Energy-Efficient Architectural Node) (Brésil), Scatterweb (Allemagne).
1.3.2 Architecture protocolaire
L’architecture d’un nœud capteur peut être représentée par deux piles protocolaires : pile capteur et
pile réseau. La figure 1.2 montre bien que la première pile est liée au canal de capture et la seconde au
canal sans fil de communication. A ce niveau, il est à noter que l’architecture protocolaire du Sink
possède au moins une pile réseau mais pas de pile capteur.
Comme illustré par la figure 1.2, un nœud capteur, par le biais de sa couche physique, peut seulement
recevoir un stimulus ou un évènement à travers le canal capteur. Cependant, dû au fait que le signal peut
11
subir des atténuations au cours de sa propagation dans le canal capteur, un nœud capteur reçoit et détecte
un stimulus seulement si la puissance du signal reçu est au moins égale à un seuil prédéterminé. Le calcul
de la puissance du signal reçu au niveau de la couche capteur est déterminé par le modèle de propagation
utilisé (par exemple sismique, acoustique, …).
La coordination entre les deux piles protocolaires est réalisée à l’aide des couches application et
transport. Par exemple, après avoir reçu le résultat de la capture (i.e. les données brutes), le nœud capteur
a la possibilité soit de relayer directement les paquets de données en direction du Sink, soit de traiter
localement ces données en premier lieu (par exemple suite à une opération d’agrégation comme calcul de
moyenne), et transmettre ensuite les informations générées en second lieu vers le Sink. Tout traitement à
l’intérieur du réseau (in networking) s’effectue au niveau de la couche application d’un nœud capteur.
Dans les paragraphes qui suivent nous explicitons la pile réseau et les trois plans d’énergie, de mobilité
et celui des tâches, en se référent toujours à la figure 1.2 et en se basant essentiellement sur les travaux de
synthèse de B. Kechar [10].
La pile protocolaire réseau ou de communication, illustrée par la Figure 1.2, comprend cinq couches :
physique, liaison de données, réseau, transport et application et trois plans de gestion : plan de gestion de
l'énergie, plan de gestion de la mobilité et plan de gestion des tâches.
La couche physique satisfait les besoins d'une modulation simple mais robuste ainsi que les techniques
de transmission et de réception. Puisque l'environnement est en général non parfait (présence
d’interférence) et les nœuds peuvent être mobiles, le protocole MAC de la couche liaison de données doit
connaître l’état de consommation de l'énergie résiduelle et capable de réduire au minimum toute source
de perte d’énergie (par exemple les collisions). La couche réseau doit être capable de router les données
fournies par la couche transport durant leur cheminement de la source vers la destination (Sink). La
couche transport permet de maintenir le flux de données si le RCSF l'exige. La couche application
emploie différents types de logiciels d'application, selon les tâches de capture.
En outre, les plans de gestion de l'énergie, de la mobilité et des tâches surveillent respectivement la
puissance, le mouvement et la distribution des tâches entre les nœuds capteurs. Ces plans aident les
nœuds capteurs à coordonner leurs tâches de capture et diminuer la consommation globale de l'énergie.
12
Couche Physique
Pile capteur
Pile réseau
Couche Mac
Couche capteur
Plans de gestion des tâches
Couche Réseau
Plans de gestion de mobilité
Couche Transport
Plans de gestion d’énergie
Couche application
Couche physique capteur
Canal sans fil
Canal capteur
Figure 1.2 : Vue protocolaire d’un nœud capteur
 Couche physique: elle assure l’interfaçage entre la pile des protocoles et la partie matérielle de
communication réseau pour permettre la transmission et la réception des suites de bits ou de symboles
à un instant donné. Les fonctions principales de cette couche incluent la détection du signal (CCA :
Clear Channel Assessment), la synchronisation des trames de données et le chiffrement. Le mécanisme
CCA permet d’écouter le canal physique afin de déterminer si d’autres transmissions sont en cours au
même instant pour prévenir les collisions de communication. La synchronisation de la trame de
données aura lieu en transmettant une séquence de bits représentant le préambule et le délimiteur de
trame dans le but d’aligner la synchronisation par radio parmi les radios du réseau. Enfin, une fois les
radios synchronisées, la couche physique reçoit les symboles analogiques du médium et les convertit
en bits digitaux pour d’éventuels traitements au niveau des couches supérieures. Les plateformes radio
comme le standard IEEE 802.15.4 pour les RCSF offrent de nouvelles fonctionnalités à la couche
physique telle que le chiffrement et les messages d’auto-acquittement. Lors de la conception de la
couche physique pour les RCSF, la minimisation d'énergie prend une importance significative, au
dessus des effets de décomposition, de dispersion, d'ombrage, de réflexion, de diffraction, des
trajectoires multiples et d'affaiblissement. En général, la puissance minimale de sortie exigée pour
transmettre un signal au-delà d'une distance d est proportionnelle à dª, où 2 ≤ a ≤ 4.
13
Notons que la couche physique est un axe de recherche en grande partie encore inconnu dans les
RCSF. Les questions ouvertes à la recherche s'étendent de la conception d'émetteurs/récepteurs efficaces
en énergie aux méthodes de modulation. Le Tableau 1.2 résume les technologies possibles pour la couche
physique d’un RCSF.
IR
Protocole
RF433
868/915
802.11
802.15.1
Wireless
USB
802.15.4
UWB
NFC
Fréquence
800-900nm
433 MHZ
868/915 MHZ
2.4/5 GHz
2.4 GHz
2.4 GHz
868/915MHz
, 2.4GHz
3.1-10.6
GHz
Connexion
inductive
(13.56 MHz)
Débit des
données
20K-16Mbps
0.3Kbps
11-54 Mbps
1 Mbps et plus
110-480
Mbps
20-250 Kbps
100-500
Mbps
106-424
Kbps
Portée
1-9m (LOS)
10m
50-100m
10m
~50m
10-100m
<10m
~20cm
Topologie
Point à Point
Point à Point
Etoile
Etoile
Etoile
Complexité
simple
simple
Haute
Moyenne-haute
simple
Moyenne
Moyenne
simple
Consom.
Energie
Très basse
(10mW, dépend
de la distance)
Basse
~200mW
Haute ~1W
Moyenne
~300mW
Basse
~200mW
Basse
~100mW
Basse
~100mW
Basse
Contrôle à
distance,
Contrôle à
Applications Transmission de
distance
données de
rayon très court
Etoile, arbre,
Point à point Point à point
maillée
Transmissio
Transmission
Remplacement Périphériques Automation n du signal
LAN sans fil
du signal de
de câble
PC
et contrôle
de bande
bande large
large
Tableau 1.2: Différentes technologies au niveau physique
 Couche liaison de données : elle permet d’interfacer les couches physique et réseau et comprend deux
fonctions séparées : le contrôle d’erreur de transmission et le contrôle d’accès au médium (MAC).
Au niveau du contrôle d’erreur, deux modes de contrôle d’erreur sont employés : la correction
d’erreurs (FEC : Forward Error Correction) et la retransmission (ARQ : Automatique Repeat reQuest).
L'utilité d'ARQ dans les applications des RCSF est limitée par le coût additionnel de retransmission et des
messages de contrôle (overhead). D'autre part, la complexité de décodage est plus grande dans FEC,
puisque les capacités de correction d'erreurs doivent être intégrées dans la trame de donnée. Ainsi, les
codes de contrôle d'erreurs simples avec un codage et décodage de moindre complexité pourraient
présenter les meilleures solutions pour les RCSF. Dans la conception d'un tel protocole, il est important
d'avoir de bonnes connaissances des caractéristiques du canal et des techniques d'implémentation.
14
Le protocole MAC dans un réseau de capteurs sans fil multi-sauts à organisation autonome doit
réaliser deux objectifs. Le premier est la création de l'infrastructure du réseau. Comme des milliers de
nœuds de capteurs sont déployés en masse dans une zone, le protocole MAC doit établir des liaisons pour
le transfert des données. Ceci forme l'infrastructure de base requise pour la communication sans fil saut
par saut et donne au réseau des capacités d'auto-organisation. Le deuxième objectif est de partager
équitablement et efficacement les ressources de communication entre les nœuds capteurs. Les méthodes
MAC existantes pour les réseaux sans fil actuels (Bluetooth, cellulaire, adhoc) ne sont pas adaptées pour
les RCSF pour une raison principale liée à l’économie d’énergie.
Il est évident que le protocole MAC pour les RCSF doit intégrer des mécanismes de conservation
d'énergie, la gestion de la mobilité et les stratégies de récupération d'échec. La conception d'un protocole
MAC efficace pour les besoins des RCSF reste toujours un domaine de recherche. Les protocoles MAC à
la demande ne conviennent pas pour les RCSF à cause de leurs messages de contrôle et les délais
d'établissement des liaisons. La conservation d'énergie est réalisée par l'utilisation des modes d'opération
d'économie d'énergie et en préférant l'arrêt des accusés de réception, dans la mesure du possible.
Puisque les radios doivent être arrêtées pendant le mode veille pour le gain d’énergie, la couche MAC
devrait inclure une variante de TDMA (Time Division Multiple Access). De plus, l'accès au canal par
discussion est estimé peu convenable puisqu'il demande une surveillance permanente du canal. On doit
cependant noter que cet accès aléatoire au médium peut également contribuer à la conservation de
puissance, comme dans la norme IEEE 802.11 pour WLAN, par la permutation des radios veille/réveil
selon l'état du vecteur d'allocation du réseau. Les temps d'écoute constants et les méthodes de contrôle
d'adaptation du débit peuvent également aider à l'efficacité énergétique des protocoles d'accès aléatoire
pour les réseaux de capteurs.
 Couche réseau : elle traite le routage des données à travers le réseau entre un nœud capteur source et la
destination (Sink). Les protocoles de routage dans les RCSF diffèrent des autres protocoles de routage
traditionnels pour plusieurs raisons. Premièrement, les nœuds capteurs ne sont pas identifiés par des
adresses IP du protocole IP d’Internet. Ainsi, les protocoles de routage fondés sur le protocole IP ne
peuvent pas être utilisés pour les RCSF. Ensuite, la conception des protocoles réseau pour les RCSF
doit tenir compte du facteur d’échelle (scalabilité), ces protocoles doivent aisément gérer les
communications entre plusieurs nœuds capteurs et faire aboutir les données captées vers le Sink. En
plus, ces protocoles doivent prendre en considération les contraintes de ressources telles que l’énergie,
la bande passante, la mémoire et les capacités de calcul. Ceci favorise l’assurance de prolongation de
la durée de vie du réseau. Enfin, ces protocoles doivent également évoquer certains problèmes liés par
exemple à l’efficacité, tolérance aux fautes, équité et la sécurité.
15
En général, il existe plusieurs manières de classifier le routage dans les RCSF. Les chercheurs
proposent une classification selon la structure du réseau et le fonctionnement du protocole, et d’autres
décrivent les protocoles de routage pour les RCSF et pour les réseaux adhocs en général selon qu’il s’agit
de routage proactif (défini au préalable), réactif (défini à la demande) ou hybrides.
Protocoles de routage dans les RCSF
Structure du réseau
Routage
linéaire
Routage basé
Routage
sur
hiérarchique
lalocalisation
Fonctionnement du protocole
Par
négociation
Par
cohérence
Multi
trajectoires
Basé sur les
questions
Basé sur la
qualité de
service
Figure 1.3: Classification des protocoles de routage
D’autres auteurs proposent une classification proche de la première dans laquelle ils considèrent les
protocoles centrés-données, hiérarchique, basés sur la localisation et avec qualité de service.
La première classification nous semble plus adéquate comme le montre la figure 1.3. En effet, dans le
routage linéaire, tous les nœuds ont typiquement les mêmes rôles ou fonctionnalités. Dans le routage
hiérarchique, les nœuds joueront différents rôles dans le réseau. Dans le routage basé sur la localisation
qui caractérise les protocoles de routages géographiques, les positions ou localisations des nœuds de
capteurs sont exploitées pour router les données dans le réseau. Un protocole de routage est considéré
adaptatif si certains paramètres du système peuvent être contrôlés afin de s'adapter aux conditions
existantes du réseau et à l'énergie disponible.
Selon le fonctionnement du protocole, Le routage regroupe les protocoles de routage par négociation
ou par cohérence, les protocoles multi trajectoires, et ceux basés sur les requêtes ou la qualité de service.
Le routage géographique utilise le mécanisme de relayage de Greedy pour router un paquet d’un nœud
source à sa destination. Cette approche route les paquets en choisissant les voisins qui sont les plus
proches de la destination. Elle suppose que le réseau soit suffisamment dense, les nœuds connaissent leurs
positions géographiques et celles de leurs voisins et que le routage multi-sauts soit fiable.Parmi les
protocoles géographiques on peut citer : MFR (Most Forward within Radius), GEDIR (The Geographic
Distance Routing), MECN (Minimum Energy Communication Network), SMECN (Small MECN), GAF
(Geographic Adaptive Fidelity), GEAR (Geographic and Energy-Aware Routing).
16
 Couche transport : elle assure la fiabilité et la qualité des données au niveau de la source et au niveau
du Sink. Les protocoles de la couche transport pour les RCSF doivent supporter différentes
applications, une fiabilité variable et des mécanismes de récupération des paquets perdus et de contrôle
de congestion. Le développement d’un protocole pour la couche transport doit être générique et
indépendant de l’application. Il doit offrir une fiabilité variable des paquets pour différentes
applications. Chaque application d’un RCSF peut tolérer différents niveaux de perte de paquets. Cette
perte de paquet est due en général à une mauvaise communication radio, à la congestion, aux collisions
des paquets, aux dépassements de capacité des mémoires des nœuds et aux pannes des nœuds capteurs.
Toute perte de paquet provoque un gaspillage supplémentaire d’énergie et dégrade la qualité de service
pour la délivrance des données. La détection des paquets perdus et la récupération réussie des paquets
manquants peuvent améliorer considérablement le débit et la consommation d’énergie. Il existe deux
approches pour la récupération d’un paquet perdu : approche saut par saut et approche de bout en bout.
La première nécessite qu’un nœud capteur intermédiaire stocke dans sa mémoire cache les
informations sur le paquet. Cette méthode est plus économique en termes de consommation d’énergie
car la distance de retransmission est relativement faible. Pour la transmission de bout en bout, le nœud
source stocke dans sa mémoire tampon toutes les informations des paquets transmis et réalise la
retransmission en cas de perte de paquet. Un mécanisme de contrôle de congestion surveille et détecte
la congestion et permet ainsi de préserver de l’énergie. Avant que la congestion n’ait lieu, le nœud
source est notifié pour réduire le débit de transmission des données. Ainsi, le contrôle de congestion
aide énormément à réduire les retransmissions et à la prévision de la saturation des mémoires des
nœuds capteurs. Il existe aussi deux approches pour contrôler la congestion : saut par saut et de bout en
bout. La première exige que chaque nœud appartenant au chemin de routage surveille la saturation de
la mémoire. Lorsqu’une congestion est détectée par un nœud capteur, tous les nœuds le long du
chemin de routage change de comportement. Le mécanisme de bout en bout permet au nœud final
(Sink) de détecter la congestion. La congestion aura lieu lorsqu’un retard (time out) ou des
acquittements redondants sont reçus. Exemple de protocole de transport : CODA (Congestion
Detection and Avoidance).
 Couche application : Bien que plusieurs domaines d'application pour les RCSF soient définis et
proposés, les protocoles potentiels de la couche application demeurent un axe de recherche en grande
partie encore inconnu. Il existe trois protocoles peuvent être considérés dans cette couche : Sensor
Management Protocol (SMP), Task Assignment and Data Advertisement Protocol(TADAP) et Sensor
Query and Data Dissemination Protocol(SQDDP).
 Plan de gestion de l’énergie: permet de gérer la distribution et l’utilisation de l’énergie au niveau de
chaque nœud capteur afin de favoriser une meilleure dissipation d’énergie. Par exemple, lorsqu’un
nœud constate que son énergie résiduelle arrive à un certain seuil, il demande aux nœuds de son
17
voisinage de le priver de l’opération de routage et utilise cette énergie restante pour la capture et la
transmission.
 Plan de gestion de mobilité : permet de détecter et d’enregistrer les mouvements des nœuds capteurs
dans le champ de déploiement, ainsi, un chemin vers l’utilisateur final est toujours maintenu, et les
nœuds capteurs peuvent toujours savoir l’état de leurs voisins. En connaissant leurs voisins, les nœuds
capteurs peuvent assurer un équilibrage de charge au niveau de la consommation énergétique et la
gestion des tâches.
 Plan de gestion des tâches : planifie l’équilibrage et le traitement des tâches de capture relatives à une
région spécifique. Il n’est pas nécessaire de laisser simultanément tous les nœuds capteurs dans une
telle région pour effectuer la collecte des données, il suffit de désigner un sous ensemble de nœuds
pour assurer ces tâches selon les niveaux de capacité énergétique dont ils disposent.
1.3.3 Architecture logicielle
Elle est définie essentiellement, comme le montre la Figure 1.4, par deux modules : l’intergiciel
(middleware) et le système d’exploitation (OS : Operating System).
Middleware : Selon Miao-Miao Wang et al [14] une solution complète de Middleware pour les RCSF
doit inclure quatre composants principaux : les abstractions de programmation, les services système, un
support d'exécution et mécanismes de qualité de service (QoS). Les abstractions de programmation
définissent l'interface du middleware au programmeur d'application. Les services système fournissent les
implémentations pour réaliser les abstractions. Le support d'exécution sert d’extension au logiciel
d'exploitation embarqué pour supporter les services du middleware. Les mécanismes de QoS définissent
les contraintes de qualité de service du système.
L’objectif principal d’un middleware consiste à supporter le développement, la maintenance, le
déploiement et l’exécution des applications utilisant les RCSF. Ceci inclus entre autre des mécanismes
pour la formulation des tâches complexes de capture de haut niveau, la communication de ces tâches au
RCSF, la coordination des nœuds capteurs pour l’accomplissement d’une tâche et sa distribution aux
nœuds capteurs individuels, la fusion de données,…. Des abstractions et des mécanismes appropriés pour
traiter l'hétérogénéité des nœuds capteurs doivent également être fournis. Tous les mécanismes fournis
par un middleware doivent respecter les principes de conception et les caractéristiques des RCSF qui se
concentrent souvent autour de l’économie d’énergie, la robustesse et le passage à l’échelle. Un RCSF
traite des données du monde réel, ainsi les concepts de temps et de localisation jouent un rôle beaucoup
plus important que dans le cas des systèmes de calcul traditionnels. Par conséquent, la gestion du temps et
la localisation doit être impérativement intégrée dans toute infrastructure de middleware conçue pour les
RCSF. Comme exemples de middleware pour les RCSF on trouve TinyDB, Cougar et SensorWare.
18
Système d’exploitation (SE): la conception d’un système d’exploitation (SE) pour un nœud capteur
doit tenir compte de sa spécificité et les limitations des modules qui le composent (processeur, mémoire,
batterie, transceiver, circuits capteurs). Plusieurs SE ont été proposés ces dernières années, mais le plus
célèbre est celui développé par l’université de Berkeley : TinyOS. TinyOS est un SE configurable à base
de composants conçu pour des systèmes à contraintes très sévères de ressources tels que les nœuds
capteurs dans un RCSF typique. Il regroupe un ensemble de composants logiciels implémentant les
fonctionnalités de base qu’une application à besoin comme par exemple les entrées/sorties de base, les
timers, la communication sans fil, …etc.
Application
Middleware
Transport
Réseau
SE
MAC
Radio
Figure 1.4: Architecture logiciel d’un nœud capteur
Les composants peuvent à leur tour contenir d’autres composants d’une manière hiérarchique. Chaque
application consiste en un ensemble de composants spécifiques à l’application considérée développés par
le concepteur et un sous ensemble de composants de TinyOS. Une instance TinyOS spécifique à
l’application est crée pour chaque application offrant ainsi les seuls services dont l’application a besoin.
Ceci favorisera une conservation précieuse de ressources.
Quatre éléments ont motivé la conception de TinyOS:
•
Ressources limitées: en termes de capacités de traitements, de stockage et de communication.
•
Concurrence réactive : car un nœud capteur peut exécuter plusieurs tâches telles que le traitement
local des données, la transmission des données, le routage des données et peut participer à d’autres
tâches de traitement distribué (agrégation ou reconnaissance). La plupart de ces évènements, tels
que la gestion radio qui nécessite des réponses en temps réel. Ceci exige donc une approche de
19
gestion de concurrence qui permet de réduire des bugs potentiels tout en respectant les contraintes
de ressource et de temps.
•
Flexibilité : par rapport à la variation du matériel et des applications.
•
Faible puissance : le SE doit offrir une flexibilité au niveau de la gestion de la puissance et les
stratégies de gestion d’activité. Par exemple, si aucune tâche n’est active, il se met au mode veille.
1.3.4 Architecture du réseau
L’architecture d’un RCSF typique est représentée, comme le montre la figure 1.5, par deux types de
réseaux : réseau d’acquisition et réseau de transport. Ces deux réseaux permettent une communication
dans deux directions par rapport au RCSF. La première, appelée direction ascendante (Uplink direction),
a pour origine les nœuds capteurs et comme destinataire final le centre de traitement exploité par un
utilisateur final. La second direction, appelée direction descendante (Downlink direction), assure la
communication inverse c.-à-d. du centre de traitement vers les nœuds capteurs. Les communications dans
les deux directions utilisent un ou plusieurs nœuds Sink et un réseau de transport comme moyen de
communication intermédiaire.
Réseau de transport
Centre de
traitement
Internet
BS
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Zone de couverture
Nœuds capteur
Figure 1.5: Interconnexion d’un RCSF avec Internet
20
Réseau d’acquisition des données
BS
Le réseau d’acquisition : regroupe l’ensemble des nœuds capteurs déployés dans une zone d’intérêt
pour assurer des fonctions telles que la surveillance et le suivi, ainsi que le Sink. En général, le
déploiement établie une association des nœuds capteurs avec des objets, des créatures ou de simples
endroits pour les doter de capacités supplémentaires de traitement de l’information. Cette association peut
être établie par attachement directe ou à l’aide d’un largage à partir d’un avion par exemple. Les nœuds
capteurs déployés réalisent des opérations de capture et/ou de traitement des données brutes collectées à
partir de l’environnement physique pour les envoyer dans un premier temps au centre de collecte (Sink),
soit directement en employant une communication mono-saut ou indirectement en empruntant un chemin
de routage multi-sauts. Si le réseau est organisé en clusters et que chaque cluster est représenté par un
ensemble de nœuds capteurs appelés nœudsmembres du cluster et un nœud coordinateur par lequel passe
tout le traffic (voir figure 1.6), alors deux de cas de figures de communications peuvent se présenter. Une
communication directe entre chaque coordinateur et le Sink, dans ce cas on parle de clustering mono-saut
et une communication multi-sauts entre coordinateurs jusqu’à ce que le trafic atteigne le Sink. Ce dernier
cas caractérise le clustering multi-sauts.
Mono saut
S
S
S
S
S
Multi sauts
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
BS
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Clustering à un saut
S
S
S
Clustering Multi sauts
Figure 1.6: Différentes architectures pour un réseau d’acquisition
21
Le Sink dans un RCSF peut prendre plusieurs formes, comme le montre la figure 1.7. En effet, il peut
être un nœud parmi l’ensemble des nœuds capteurs (figure 1.7 (a)), mais dans ce cas le problème
d’énergie est sérieusement posé puisque tout le trafic passe par ce nœud (donc consommation d’énergie
considérable en réception notamment). Parmi les solutions envisagées pour traiter ce problème, il y a la
proposition de déploiement de plusieurs Sink dans un contexte purement distribué. Dans le cas où le Sink
est un Système particulier mobile plus puissant qu’un nœud capteur ordinaire (PDA ou ordinateur
portable) (figure 1.7 (b)), la collecte par le Sink des informations générées par les nœuds capteurs se fera
au fur et à mesure de son déplacement dans le champ de déploiement.
Par contre, dans le cas où le Sink est considéré comme une passerelle vers d’autres réseaux tels que
Internet (figure 1.7 (c)), la problématique de consommation d’énergie n’inclut pas en général le Sink dans
sa stratégie globale. Notons enfin que souvent on confond le Sink avec le centre de traitement de
l’utilisateur pour des raisons de simplification et de réduction de complexité due au facteur
d’hétérogénéité réseau qu’il faut à prendre en considération.
Sink
S
S
S
Source
S
Source
S
S
S
S
(a)
Source
S
Internet
Sink
Sink
(b)
(c)
Figure 1.7: Différents types de Sink dans un RCSF : (a) Un nœud capteur, (b) Système mobile plus
puissant, (c) Point d’accès relié à un autre réseau
Le réseau de transport : regroupe le réseau de transport proprement dit et le centre d’analyse et
d’exploitation des données collectées. Le réseau de transport permet d’assurer un acheminement sûr et
fiable des données générées par le RCSF à partir du Sink jusqu’à la station de travail de l’utilisateur final.
Il peut s’agir du réseau Internet, réseau de satellite, réseau cellulaire de type GSM ou autre.
22
A partir d’un centre de traitement et dans le cas d’une communication dans la direction descendante,
l’utilisateur peut formuler des requêtes d’extraction de données bien précises à partir du RCSF ou des
opérations de maintenance à distance telles que la reconfiguration de certains nœuds du réseau.
1.4 Les RCSF
1.4.1 Présentation
Un RCSF est composé d'un ensemble de nœuds capteurs. Ces nœuds capteurs sont organisés en
champs « sensor fields » (voir figure suivante). Chacun de ces nœuds a la capacité de collecter des
données et de les transférer au nœud passerelle par l'intermédiaire d'une architecture multi-sauts. Le sink
transmet ensuite ces données par Internet ou par satellite à l'ordinateur central «Gestionnaire de taches »
pour analyser ces données et prendre des décisions [15].
PC, Lan ou Internet
Gateway
(Utilisateur)
(sink)
Les capteurs
BS
BS
Figure 1.8: Réseau de capteur sans fil
Un RCSF est littéralement un réseau prés à l’emploi : des terminaux ou ce qu’on appelle des nœuds
capteurs (nœud capteurs) qui peuvent communiquer spontanément via des liaisons radio, sans
infrastructure fixe préalable. Le réseau devant fonctionner de façon autonome, sans intervention humaine.
Les nœuds sont généralement matériellement petits, construits à partir des composants pas chers pour
maintenir un coût de réseau maniable et placé généralement dans l’environnement prés des objets
auxquels ils s’intéressent, capables de mesurer une grandeur physique (au sens large) : température,
pression, pH, etc. Un RCSF est généralement composé entre 10 et 10000 nœuds qui communiquent
23
ensemble via les canaux radio, ou bien d’autres types de communications comme les canaux
acoustiques,…
La conception d’un RCSF est basée sur cette équation :
Détecteur/Capteur + CPU + Radio = des milliers d’applications
En plus, ces réseaux de capteurs peuvent être statiques ou bien dynamique, donc les nœuds de réseaux
sont en générales capables de s’auto configurer.
1.4.2 Protocole de communication des RCSF: ZigBee
ZigBee [16] [Web 10] 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 personnel
(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 % !
1.4.2.1 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.
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.
1.4.2.2 Routage 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
24
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.).
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.
25
1.4.3 Problématiques des RCSF
Les principaux facteurs [15] et contraintes influençant sur l'architecture des réseaux de capteurs
peuvent être résumés comme suit:
1.4.3.1 La tolérance de fautes
Certain nœuds peuvent générer des erreurs ou ne plus fonctionner à cause d'un manque d'énergie, un
problème physique ou une interférence. Ces problèmes n'affectent pas le reste du réseau, c'est le principe
de la tolérance de fautes. La tolérance de fautes est la capacité de maintenir les fonctionnalités du réseau
sans interruptions dues à une erreur intervenue sur un ou plusieurs capteurs.
1.4.3.2 L'échelle
Le nombre de nœuds déployés pour un projet peut atteindre le million. Un nombre aussi important de
nœuds engendre beaucoup de transmissions inter nodales et nécessite que le sink soit équipé de beaucoup
de mémoire pour stocker les informations reçues.
1.4.3.3 Les coûts de production
Souvent, les réseaux de capteurs sont composés d'un très grand nombre de nœuds. Le prix d'un nœud
est critique afin de pouvoir concurrencer un réseau de surveillance traditionnel. Actuellement un nœud ne
coûte souvent pas beaucoup plus que 1$. A titre de comparaison, un nœud Bluetooth, pourtant déjà connu
pour être un système low-cost, revient environ à 10$.
1.4.3.4 L'environnement
Les capteurs sont souvent déployés en masse dans des endroits tels que des champs de bataille au delà
des lignes ennemies, à l'intérieur de grandes machines, au fond d'un océan, dans des champs
biologiquement ou chimiquement souillés,... Par conséquent, ils doivent pouvoir fonctionner sans
surveillance dans des régions géographiques éloignées.
1.4.3.5 La topologie de réseau
Le déploiement d'un grand nombre de nœuds nécessite une maintenance de la topologie. Cette
maintenance consiste en trois phases : Déploiement, Post-déploiement (les capteurs peuvent bouger, ne
plus fonctionner,...), Redéploiement de nœuds additionnels.
1.4.3.6 Les contraintes matérielles
La principale contrainte matérielle est la taille du capteur. Les autres contraintes sont que la
consommation d'énergie doit être moindre pour que le réseau survive le plus longtemps possible, qu'il
s'adapte aux différents environnements (fortes chaleurs, eau,..), qu'il soit autonome et très résistant vu
qu'il est souvent déployé dans des environnements hostiles.
26
1.4.3.7 Les médias de transmission
Dans un réseau de capteurs, les nœuds sont reliés par une architecture sans-fil. Pour permettre des
opérations sur ces réseaux dans le monde entier, le média de transmission doit être normé. On utilise le
plus souvent l'infrarouge (qui est license-free, robuste aux interférences, et peu onéreux), le Bluetooth et
les communications radio ZigBee.
1.4.3.8 La consommation d'énergie
Un capteur, de par sa taille, est limité en énergie (< 1.2V). Dans la plupart des cas le remplacement de
la batterie est impossible. Ce qui veut dire que la durée de vie d'un capteur dépend grandement de la durée
de vie de la batterie. Dans un réseau de capteurs (multi-sauts) chaque nœuds collecte des données et
envoie/transmet des valeurs. Le dysfonctionnement de quelques nœuds nécessite un changement de la
topologie du réseau et un ré-routage des paquets. Toutes ces opérations sont gourmandes en énergie, c'est
pour cette raison que les recherches actuelles se concentrent principalement sur les moyens de réduire
cette consommation.
1.5
Application des réseaux de capteurs
Selon [15], les RCSF peuvent avoir plusieurs domaines d'applications (voir figure 1.9). Parmi elles,
nous citons :
1.5.1 Découvertes de catastrophes naturelles
On peut créer un réseau autonome en dispersant les nœuds dans la nature. Des capteurs peuvent ainsi
signaler des événements tels que feux de forêts, tempêtes ou inondations. Ceci permet une intervention
beaucoup plus rapide et efficace des secours.
1.5.2 Détection d'intrusions
En plaçant, à différents points stratégiques, des capteurs, on peut ainsi prévenir des cambriolages ou
des passages de gibier sur une voie de chemin de fer (par exemple) sans avoir à recourir à de coûteux
dispositifs de surveillance vidéo.
1.5.3 Applications métier
On pourrait imaginer devoir stocker des denrées nécessitant un certain taux d'humidité et une certaine
température (min ou max). Dans ces applications, le réseau doit pouvoir collecter ces différentes
informations et alerter en temps réel si les seuils critiques sont dépassés.
27
1.5.4 Contrôle de la pollution
On pourrait disperser des capteurs au-dessus d'un emplacement industriel pour détecter et contrôler des
fuites de gaz ou de produits chimiques. Ces applications permettraient de donner l'alerte en un temps
record et de pouvoir suivre l'évolution de la catastrophe.
1.5.5 Agriculture
Des nœuds peuvent être incorporés dans la terre. On peut ensuite questionner le réseau de capteurs sur
l'état du champ (déterminer par exemple les secteurs les plus secs afin de les arroser en priorité). On peut
aussi imaginer équiper des troupeaux de bétail de capteurs pour connaître en tout temps, leur position ce
qui éviterait aux éleveurs d'avoir recours à des chiens de berger.
1.5.6 Surveillance médicale
En implantant sous la peau de mini capteurs vidéo, on peut recevoir des images en temps réel d'une
partie du corps sans aucune chirurgie pendant environ 24h. On peut ainsi surveiller la progression d'une
maladie ou la reconstruction d'un muscle.
1.5.7 Contrôle d'édifices
On peut inclure sur les parois des barrages des capteurs qui permettent de calculer en temps réel la
pression exercée. Il est donc possible de réguler le niveau d'eau si les limites sont atteintes. On peut aussi
imaginer inclure des capteurs entre les sacs de sables formant une digue de fortune. La détection rapide
d'infiltration d'eau peut servir à renforcer le barrage en conséquence. Cette technique peut aussi être
utilisée pour d'autres constructions tels que ponts, voies de chemins de fer, routes de montagnes,
bâtiments et autres ouvrages d'art.
1.5.8 Applications commerciales
Il est possible d'intégrer[Web 12]des nœuds capteurs au processus de stockage et de livraison. Le
réseau ainsi formé, pourra être utilisé pour connaître la position, l'état et la direction d'un paquet ou d'une
cargaison. Il devient alors possible pour un client qui attend la réception d'un paquet, d'avoir un avis de
livraison en temps réel et de connaître la position actuelle du paquet. Pour les entreprises manufacturières,
les réseaux de capteurs permettront de suivre le procédé de production à partir des matières premières
jusqu'au produit final livré. Grâce aux réseaux de capteurs, les entreprises pourraient offrir une meilleure
qualité de service tout en réduisant leurs coûts. Dans les immeubles, le système de climatisation peut être
conçu en intégrant plusieurs micro-capteurs dans les tuiles du plancher et les meubles. Ainsi, La
climatisation pourra être déclenchée seulement aux endroits où il y a des personnes présentes et
seulement si c'est nécessaire. Le système distribué pourra aussi maintenir une température homogène dans
les pièces. Utilisée à grande échelle, une telle application permettrait de réduire la demande mondiale en
énergie réduisant du même coup les gaz à effet de serre. Rien que pour les États-Unis, on estime cette
28
économie à 55 milliards de dollars par an avec une diminution de 35 millions de tonnes des émissions de
carbone dans l'air. Ainsi, dans un contexte mondial où le réchauffement de la planète devient une
préoccupation grandissante, une telle conséquence environnementale serait un pas dans la bonne
direction.
Figure 1.9: Applications des RCSF [15]
1.6 Conclusion
Dans ce chapitre nous avons présenté un état de l’art détaillé sur les RCSF objet de notre étude. Nous
avons introduit dans un premier temps les différentes architectures d’un nœud capteur (matérielle,
protocolaire et logicielle) et l’architecture du réseau global. Nous avons aussi évoqué les protocoles
associés aux RCSF ainsi que les problématiques liés à ce type de réseaux. Nous avons montré que ce qui
fait la force de cette nouvelle technologie des RCSF à l'heure actuelle c'est son application dans plusieurs
domaines de la vie courante, que ce soit sur le plan environnemental et sociétal ou industriel. Ceci nous a
encouragé d'investiguer de près une des applications environnementales des RCSF les plus médiatisées de
nos jours, à savoir la pollution de l'environnement où les feux de forêts occupe une place dominante. Les
chapitres qui suivent abordent essentiellement cette problématique des feux de forêts et expliquent en
détail la manière avec laquelle nous avons mené nos travaux de recherche pour apporter quelques
éléments de réponse sur la nécessité d'intégrer cette technologie dans toute stratégie future de détection
des feux de forêts dans notre pays.
29
CHAPITRE 2 : Problématiques des feux de forêt et approches de détection
2
Problématiques des feux de forêt
et approches de détection
2.1 Introduction
Les feux de forêt sont parmi les catastrophes entraînant des menaces à l'humanité et aux écosystèmes
dans le monde entier. La probabilité d’inflammation des forêts est en nette augmentation due au
changement climatique et aux activités humaines. Les feux de forêt ont des effets négatifs sur des
personnes, des animaux, des forêts et de sol indépendamment des dommages économiques qui peuvent
résulter. L'effet négatif des feux de forêt sur les personnes est la pollution de l'air, qui pose des problèmes
de santé tels que le problème respiratoire et cardio-vasculaire en raison de la fumée. Les feux de forêt
réduisent la couverture d'arbres et mènent à une augmentation des émissions de gaz de notre planète, et
environ 20% d'émissions de CO2 dans l'atmosphère sont dus aux feux de forêt. On le sait également que
le sol devient plus susceptible de l'érosion puisqu'il est laissé nu. Afin de réduire au minimum des
dommages, la détection rapide des feux de forêt est un enjeu crucial. Sans accord clair et correct de la
distribution et de la dynamique des feux de forêt, il est pratiquement impossible de les contrôler
effectivement par les anciennes méthodes de surveillance.
2.2 Pyrologie forestière
La pyrologie forestière constitue une science dont l’objet principal est l’étude des feux de forêts et de
leurs propriétés. Elle explique, entre autre chose, le phénomène de la combustion, décrit les
caractéristiques propres aux incendies de forêts et étudie les facteurs qui influencent leur origine et leur
développement.
30
2.3 Définition du feu
Le feu d’après [Web 16] est la production d'une flamme par une réaction exothermique d'oxydation
appelée combustion.Cette réaction chimique dégage de la chaleur (exothermique) et de la lumière. Pour
brûler, tout feu à besoin d’un gaz appelé oxygène. Lorsque l’herbe et le bois sont secs, la moindre
étincelle peut générer un incendie. C’est ainsi que chaque été d’immenses étendues de forêts sont
détruites par les incendies. Ces derniers, sont le résultat de la combustion des matériaux ligneux qui
composent la plus grande partie de la végétation forestière.
2.4 Feux de forêts
On parle d’un incendie de forêt lorsque le feu concerne une surface minimale d’un hectare et qu’une
partie au moins des étages arbustifs et / ou arborés (parties hautes) est détruites.
2.5 La combustion
Par combustion, on entend l’ensemble des phénomènes qui accompagnent la combinaison chimique ou
l’union rapide de l’oxygène de l’air avec le carbone contenu dans les combustibles. Ces derniers sont
définis comme étant des corps ayant la propriété de brûler, c’est-à-dire des substances qui peuvent être
détruites par le feu comme le bois, la tourbe, le charbon, la paille, le papier, etc.
2.6 Présentation des forêts de la ville d’Oran – Ouest d’Algérie
En se référent à la source [17], la surface forestière de la wilaya d’Oran toutes formations confondues
est de 45.302 ha couvrant ainsi un taux de boisement de 21%.La majorité des forêts de la wilaya sont
localisées sur les monts littoraux (massifs côtiers de la wilaya) s’étendant sur une surface de 31.202 ha et
sur les plaines littorales et sub-littorales avec une superficie de 14.100ha.
Figure 2.1: Incendie de la forêt du lion en 2009.
31
La conservation des forêts de la wilaya d’Oran a enregistré 68 foyers d’incendie durant la campagne de
prévention et de lutte contre les feux de forêts en 2009. Ces foyers ont parcouru une superficie totale de
86 ha et 01 Are3 et 13 Ca4, répartie comme suite :
* Forêts: 77 ares 33 Ca;
* Maquis: 13 ha 36 Ares 50 Ca;
* Broussailles: 71 ha 87 Ares 30 Ca,
La moyenne calculée par incendie est de 01 ha 26 Ares et d’une fréquence d’un incendie tous les deux
jours. Les dispositifs de prévention et d’alerte existantes sont basés sur : les postes de vigies qui se
trouvent sur les hauts points des montagnes, brigades mobiles qui englobent les véhicules et les engins,
comités riverains (habitants, employé, passager de la forêt) qu’il la participe plusieurs agents comme les
gardiens des sites relais (mobilis, nedjma, djezzy) et d’autres intervenants. Pour diffuser une alerte de feu
sur l’espace vert, il est important de signaler que les brigades mobiles et les postes de vigies sont équipés
d’un réseau phonique (talkie-walkie) qui couvre 90% de la surface forestière. En conclusion ; la
compagne de prévention et de lutte contre les feux de forêts pour l’année 2009 s’est déroulée dans des
conditions assez difficiles en raison des situations caniculaires exceptionnelles enregistrées qui ont rendu
les multiples interventions plus contraignantes et nécessite la mobilisation d’importants moyens humains
et matériels. En fin il demeure bien entendu que toutes les mesures préconisées ne peuvent suffire sans
une implication effective de populations riveraines se trouvant à l’intérieur et à proximité des massifs
forestiers, nécessitant une meilleure prise en charge de leurs préoccupations à travers la mise en œuvre du
programme de projet de proximité et de développement rural.
2.7 Évolution des systèmes forestiers de détection d'incendie
Traditionnellement, les incendies de forêt ont été détectés à l'aide de tours de garde d'incendie situés
aux points hauts [02]. Le devoir d'une personne est de chercher des incendies au moyen d'appareils
spéciaux comme les jumelles, Osborne Fire Finder.
Osborne Fire Finder est constituée d'une carte topographique imprimée sur un disque avec une
bordure graduée. Un pointeur détermine l'emplacement l'incendie et sa direction. Une fois la zone de
l'incendie est déterminée, la vigie alerte l'équipage d'incendie de lutte contre l'incendie [18].
Tours de garde d'incendie sont encore en usage dans nombreux pays à travers le monde dont les USA,
l'Australie et Canada. Le manque de fiabilité des observations humaines en plus des conditions de vie
difficiles pour le personnel d'observation des incendies ont mené à l'élaboration de systèmes de vidéo
surveillance automatique. La plupart de ces systèmes utilisent des détecteurs CCD (Charge-Coupled
3
4
Acres
2
Centiare (1 centiare (ca) = 1 m )
32
Device) et l'infrarouge (IR) installés au sommet des tours. Les caméras CCD utilisent des capteurs
d'image qui contient un tableau des condensateurs de lumière sensibles ou des photodiodes. En cas
d’activité d'incendie ou de fumée, le système alerte les services d'incendie.
Les systèmes automatiques de vidéo surveillance utilisés en Allemagne, Canada et la Russie sont
capables de balayer un espace circulaire de 10 km en moins de 8 minutes. La précision de ces systèmes
est largement affectée par les conditions climatiques comme les nuages, réflexion de la lumière, et la
fumée provenant des activités industrielles.
Les avions sont aussi un moyen de surveillance qui survole les forêts, le pilote alerte la station de base
en cas d'activité d'un incendie ou de fumée.
En plus, les systèmes de détection des incendies de forêt avancés sont fondés sur l'imagerie par
satellite comme NOAA (National Oceanic and Atmospheric Administration) MODIS (Moderate
Resolution Imaging Spectroradiometer). La précision et la fiabilité des systèmes par satellite sont en
grande partie influencées par les conditions météorologiques, qui affectent par conséquent la précision de
détection, et par conséquent la détection en temps réel des incendies.
Pour résumer, la question la plus critique dans un système de détection des incendies de forêt est la
réponse immédiate au but de déclenchement des feux de forêt afin de minimiser les catastrophes. Cela
exige une surveillance constante de la superficie forestière.
Actuellement, les modules de détection des réseaux de capteurs sans fil (RCSF) sont capables de
détecter une variété de phénomènes, dont la température, l'humidité relative, et la fumée, gaz de Cox et
NOx, vitesse du vent, pression barométrique, intensité lumineuse… qui sont utile pour les systèmes de
détection d'incendie. Par exemple, le projet FireBug[04]de l'université de Californie Berkeley a expliqué
la praticabilité des réseaux de capteurs sans fil pour détecter l’intensité et l'évolution des feux de forêt en
utilisant la température, l'humidité relative et la pression barométrique collectées par les nœuds capteurs.
Dans ce mémoire nous soulignons l'importance de la détection des feux de forêts en utilisant la
technologie des réseaux de capteur sans fil.
L'information sensorielle peut fournir une approche plus globale de surveillance des incendies de
forêt. En outre, les nœuds capteurs peuvent être déployés dans les régions où les signaux satellites
peuvent ne pas être disponibles.
Indice Forêt-Météo(IFM), est l'une des avancées récentes dans la surveillance des forêts. La nature de
la technique multi-sensorielle augmente la possibilité de détecter le feu avec une précision plus élevée et
de diminuer les fausses alarmes.
33
Un autre système de surveillance des forêts est le National Fire Danger Rating System (NFDRS),
présenté dans la figure suivante [02].
Figure 2.2: Schéma du National Fire Danger Rating System
NFDRS accepte quatre informations sensorielles : l'humidité, la température, la fumée et la vitesse du
vent. Elle génère un indice de vraisemblance d’incendie. La contribution de cette étude consiste en
l'application d'un réseau de neurones de réaction pour l'agrégation des données et réduire les messages de
contrôle (overhead) de communication. Les indices NFDRS sont les suivants:
 Indice des événements: indique l’incidence potentielle du feu.
 Burning Index: précise le montant éventuel de l'effort nécessaire pour contrôler un incendie dans un
seul type de combustible déterminé dans une zone d’estimation.
 Indice de charge de feu: affiche le montant total des efforts nécessaires pour entourer tous les feux
probables dans la zone d'estimation pendant un temps donné.
D-FLER est un nœud capteur d'inférence floue distribuée dans les réseaux de capteurs sans fil pour la
détection d'événements. Il est étudié comme un événement en utilisant la fumée et la température pour la
détection des incendies résidentiels. D-FLER combine les entrées de chaque capteur avec l'observation de
34
quartier en utilisant un nœud capteur distribué de logique floue. Le prototype était mis en œuvre dans la
pratique en utilisant la plateforme Ambient μNode 2.0.
Figure 2.3: Structure de D-FLER
2.8 Fire_sensor_sock
Cette étude [19] [Web 04] développe une façon de protéger thermiquement les capteurs au cours des
expériences, visant à empêcher leur destruction et de les étendre au-delà de leur durée de vie en cas d'un
incendie. Grâce à cette isolation thermique, les réseaux de capteurs peuvent être réutilisés pour des faits
postérieurs. Le défi consiste principalement à fournir une protection capable de préserver les flux de
données provenant de capteurs embarqués continus dans un environnement thermique destructeur ; cette
protection, appelée Fire sensor sock, est présentée dans la figure 2.4. Il faut remarquer que, lorsque les
capteurs sont recouverts de Fire sensor sock, les deux grandeurs température et l'humidité mesurées au
cours des expériences d'incendie sont relatives à ceux au cœur de la protection. Cependant, la détection de
toute modification importante de données thermiques dans la protection en raison du changement de
milieu thermique par l'extérieur régi par le feu permet une détection d'incendie et de suivi.
Figure 2.4: Protection thermique d’un capteur
Le Fire_sensor_sock se compose de plusieurs couches de matériaux d'isolation thermique: une couche
de simples fibres Zetex, une couche céramique de laine et d'une couche finale fibre Zetex aluminée. Ces
couches sont fixées les unes aux autres avec fil Kevlar. Nous atteignons ainsi un niveau de protection qui
35
permet au capteur de soutenir le contact à un feu prolongé et aussi de communication sans fil sans
aucune perturbation.
La détection des données thermiques à l'intérieur de la chaussette qui varie en fonction d’un
fort environnement thermique, comme une flamme, conduit à la possibilité de détecter la présence d'un
incendie. Ce point est très important pour la gestion des alertes d'incendie, car il détermine la première
action des pompiers.
Il est important de remarquer que l'efficacité de l'ensemble de RCSF dépend fortement de temps de
réponse qui doit être plus rapide à l’échelle de l’incendie. Ce point doit être souligné, car le feu ne
transporte pas un phénomène linéaire et une large gamme de l'espace et des échelles de temps peuvent
coexister.
Dans ce cas, le suivi de la propagation du feu au cours de son évolution spatiale et temporelle
est possible avec une précision spatiale régie par le nombre de nœuds et une précision temporelle due à la
réponse à l’heure de RCSF. En résumé, on peut considérer que:
1) le RCSF protégé continue de transmettre les données au cours de l'incendie et permet une vision
intrusive du phénomène, le flux de données n'est pas interrompu et c’est une mise à jour fiable pour
les réseaux de capteurs.
2) le RCSF protégé permet de calculer le feu réparti, même si différents taux de propagation du feu
existent le long de la ligne de même feu, en scannant l'effet hétérogénéité du feu.
Enfin, une autre caractéristique du réseau qui devrait être à étudiée concerne la transmission. Dans les
réseaux multi-saut, le moment de la détection d'incendie par un nœud capteur et l'heure d'arrivée sur la
station de base est un paramètre important qui peut modifier la perception du phénomène dans le temps.
2.9 Étude des performances des réseaux de capteurs sans fil
Plusieurs études ont démontré quelques performances telles, l’efficacité énergétique (consommation),
temps de réponse des capteurs, délai d’acheminement des données, et la perte des données, etc. [02].
a/ L'une des applications utilise le mode asynchrone lorsqu’il n’y a pas d’alarme active pour optimiser
la consommation d'énergie, elle bascule au mode complet (sans sleep) pour minimiser le délai lors de
manipulation des situations d’incendie, et utilise le mode synchrone (avec bande passante réservée) lors
du transfert des enregistrements au sink, pour l'équilibrage de délai et les économies d'énergie.
L'application organise les nœuds capteurs dans un réseau en cluster virtuel superposés et exécute un
service de recherche Peer-to-Peer pour localiser les nœuds en dehors de la zone de danger, et pour
36
localiser les enregistrements d'alarmes. L’algorithme de déploiement d’alarme et de recherche du nœud
capteurs est présenté comme suite :
Le protocole de déploiement d'alarmes est illustré par la figure 2.5. Le nœud capteur(mote) proxy A
diffuse le paquet ALARM-SET, qui est retransmise par nœud capteurs B et C dans deux slots différents.
Ensuite, ils échangent des paquets NEIGHBOUR-TABLE, et le nœud capteur A choisi lui-même comme
cluster-chef (CH).
Figure 2.5: Exemple de protocole d'inondation ALARME-SET
La figure 2.5 illustre l'utilisation de l'algorithme de recherche. Après l'exécution de l'algorithme de
déploiement d'alarmes, les nœuds capteurs B, C et D sont choisis comme CH. Le nœud capteur A
commencé une recherche à deux sauts pour un CH en veille (dans la zone verte), en envoyant un paquet
QUERY vers son voisin CH (le nœud capteur B). Le paquet QUERY est transmis au CH C et D, et le
nœud capteur A reçoit un paquet HIT par les deux CH, enregistrant leurs état d'alarme et s’ils n'ont aucun
champ d'alarme stocké (pré chargement des caches pour les futures recherches). Les paquets HIT sont
reçus de toutes les CH stockées dans leur cache. Le CH D ajoute C à son tableau voisin actif, et CH C fait
la même chose pour le CH B.
37
Figure 2.6: Recherche d’un nœud capteur
Si le feu se propage et le nœud capteur C est détruit ou atteint le niveau d'alarme rouge (et B et D
restent actifs), alors les nœuds capteurs F et G change leurs rôles au CH. CH B efface de son cache les
paquets HIT reçu de C et D quand il détecte que le nœud capteur C est échouée.
b/ une autre étude vise à étudier quatre protocoles MAC en terme de consommation d'énergie, débit et
efficacité énergétique, les protocoles sont IEEE 802.11, TDMA, SMAC et IEEE 802.15.4.
Le standard IEEE 802.11 avec CSMA est conçu pour les réseaux sans fil conventionnels, tels que
l'Internet sans fil. En mode CSMA, avant d'envoyer son propre message, chaque nœud écoute d'abord le
canal pour voir s'il y a des transmissions. Ceci est fait pour éviter la collision. Cependant, ceci n'évite pas
complètement des collisions puisque les deux nœuds peuvent transmettre simultanément s'ils ne peuvent
pas se détecter des transmissions. Un mécanisme pour résoudre ce problème est le RTS/CTS.
TDMA divise l'utilisation du canal en tranches de temps fixes et programme la transmission des nœuds
actifs. TDMA exige un grand temps système afin de mettre à jour la synchronisation entre les nœuds et
pour permuter l'information locale, telle que la topologie du réseau et la configuration de transmission.
L'idée de base du SMAC est que chaque nœud produit un message local sleep-wake et diffuse
l'information aux capteurs voisins par l'échange des paquets de synchronisation. Si un capteur reçoit un
sleep-wake il programme d'autres capteurs avant qu'il diffuse ses propres, il fonctionnera sous le
programme reçu au lieu de celui produit localement. En conséquence, le réseau concevra les clusters
virtuels qui contiennent des nœuds capteur exécutant un programme commun sleep-wake. SMAC utilise
des mécanismes de CSMA et de RTS/CTS pour l'évitement anticollision.
Contrairement aux autres protocoles, IEEE 802.15.4 se concentre sur des capteurs de ressources
énergétiques limitées, les nœuds capteurs dans un réseau 802.15.4 fonctionnent en mode permis par
38
balise, où le coordonnateur de PAN diffuse périodiquement une balise pour des buts de synchronisation et
de gestion.
Le modèle de la consommation électrique installé dans chaque capteur, il est montré comme suite :
Mode de capteur
Ratio
Sleep Power
0.001
Idle Power
0.8
Receive Power
0.8
Transmit Power
1.0
Transition Power
0.2
Tableau 2.1: Mode de consommation énergétique
D’après les simulations de cette étude, ils ont remarqué que :
Premièrement, IEEE 802.11 n'est pas approprié pour les réseaux de capteur dus à l'inefficacité
d'énergie. C'est parce que les capteurs consomment l'énergie due au pourcentage élevé de temps passé en
mode idle-listening sans de recevoir aucune mesure.
Deuxièmement, TDMA a un avantage naturel de moyen d'accès par collision-libre, mais inclut des
problèmes de dérive d'horloge et le débit diminué dû aux slots idle. L'inconvénient majeur de TDMA est
la synchronisation des nœuds et l'adaptation au changement de topologie, où des modifications sont
provoquées par la mise en place de nouveaux nœuds, et l’énergie de batterie limitée et de messages sleep.
Par conséquent, les affectations de slot devraient être faites au sujet de telles possibilités et il n'est pas
facile de l'accomplir, puisque tous les nœuds doivent s'entendre sur elle.
Troisièmement, SMAC offre beaucoup d'avantages supportant son utilisation dans des réseaux de
capteur. Selon cette étude il lui affiche qu'est plus de rendement optimum que le protocole d'IEEE 802.11
et TDMA. La consommation d'énergie provoquée par idle-listening est réduite et le temps système de la
synchronisation est empêché par programmation des messages sleep. Localement la synchronisation des
nœuds capteur réduit au minimum le problème de coordonner des nœuds capteur pour la transmission et
peut fournir la synchronisation adéquate et le groupement pour d'autres protocoles. Par conséquent,
SMAC peut mesurer facilement puisque les nœuds capteur n'exigent aucune coordination répandue en
utilisant des messages balise, et par conséquent ne doit pas expédier ou partager des grands nombres
d'informations d'état. Cependant, SMAC a quelques inconvénients puisque la programmation de sleep et
écoute est prédéfinie et constante, qui diminue l'efficacité du protocole sous la charge de trafic variable.
Un autre inconvénient vient du coefficient d'utilisation statique de SMAC, car les nœuds capteur peuvent
39
changer leur coefficient d'utilisation basée sur des états du trafic ou de densité et ne pas consommer plus
d'énergie qu'exigée et affectent les performances de protocole.
Enfin, IEEE 802.15.4 est un protocole de rendement optimum favorisant de basses applications de
débit et de faible consommation d'énergie, qui est très désirable dans un RCSF avec les batteries non
accessibles.
Tandis que 802.15.4 se concentre sur des applications semblables aux réseaux de capteur, plusieurs
problèmes existent pour son usage dans des réseaux de capteur. La norme définit le fonctionnement des
dispositifs de réseau pour les topologies étoiles où les dispositifs peuvent communiquer directement
avec le coordinateur du PAN. La plupart des réseaux de capteurs feront réparties de nombreux dispositifs,
sur une trop grande zone géographique pour que tous les périphériques utilisent un seul coordinateur de
PAN. Ainsi, dans une grande échelle d’expériences des problèmes d’évolutivité des réseaux de
capteurs. D'ailleurs, il souffre de la raison de l'absence de problème du terminal cachée des messages
RTS/CTS.
2.10 Conception du système de détection des feux de forêt
D’après le service de météorologie de la wilaya d’ORAN, le système le plus proche (adapté) à notre
région c’est le système canadien de détection des feux de forêt, pour cela nous avons demandé au service
canadien de conservation des forêts de nous fournir des équations nécessaires pour l’élaboration de notre
propre système, la réponse de cette demande est validée par un document complet de leur système avec
ces limites, ensuite nous avons simplifié au maximum leur système pour produire un premier résultat
acceptable pour pouvoir l’améliorer par la suite.
Pour examiner les résultats obtenus par le système canadien de détection des feux de forêt – modifié –
nous avons mis en deuxième position un autre système de détection des feux de forêt afin de comparer
d’une part la validité de notre système, et de savoir quel système soit plus persistant contre les fausses
alertes et minimise le temps de détection de feux d’une autre part.
Le second système (système coréen) n’a pas une très haute correspondance météorologique par rapport
au climat de notre région, leur rôle essentiel c’est d’ajuster au maximum notre système contre les fautes et
les panne de mesures (il mesure l’humidité comme paramètre commun avec le système canadien).
2.11 L’étude Coréenne
Le protocole de routage [01] utilisé est semblable à un protocole de routage qui utilise le plus court
chemin (MCF). MCF trouve le plus court chemin de tous les nœuds capteur à la station de base et ne
requiert aucune table de routage explicite à l'entretien de chaque nœud. Le routage de toutes les données
40
le long d'un chemin plus court pourrait potentiellement vider toute l'énergie des nœuds en amont. La
conception de MCF a été pilotée par les trois buts suivants : optimalité, simplicité et évolutivité.
Le logiciel personnalisé reçoit et traite des paquets du transceiver et affiche ses résultats. Ces résultats
contiennent le niveau du risque des feux de forêt. Ce niveau est calculé par la formule définie par
l'équation (1). Ensuite, le logiciel enregistre les paquets reçus au serveur de base de données et génère des
alertes en cas d’urgence.
𝑌 = 6.87 + 0.64 ∗ 𝑃 + 0.15 ∗ 𝐸𝐹 +
1774.94
2.1
𝐶𝑆
Où : EF est l’humidité pertinente(%).
CS est le rayonnement solaire du jour (MJ/m²).
P : la précipitation (mm).
𝐸𝐹 = 1 − 𝑟 𝐻0 + 𝑟 ∗ 𝐻1 + 𝑟 2 ∗ 𝐻2 + 𝑟 3 ∗ 𝐻3 + 𝑟 4 ∗ 𝐻4 𝑂ù 𝑟 = 0.7
2.2
Hi : l’humidité relative du jour i.
Y
10
11
12
13
14
15
16
Indice de danger
100
90
80
70
60
50
40
Intervalle de danger du feu
État et couleur
81-100
Extrême (rouge)
61-80
Haute (jaune)
Moins de 60
Basse (Blue)
Tableau 2.2: Indice de danger de feu de forêt Coréen
2.12 L’étude Canadienne
Cette étude [20] [21] propose le calcul de l’indice du feu selon la méthode IFM indice forêt-météo
(FWI :Fire Weather Index). Cela supprime la nécessité de communiquer toutes les données du capteur au
sink, et seulement quelques indices agrégés sont signalés pour diminuer la consommation d'énergie.
La méthode IFM comporte six indices normalisés. Les trois premiers indiquent les variations
journalières de la teneur en eau de trois types de combustibles forestiers ayant différentes vitesses de
dessèchement. Les trois autres se rapportent au comportement du feu et sont représentatifs de la vitesse de
propagation, de la quantité de combustibles brûlés de même que de l'intensité du feu. La méthode repose
uniquement sur la détermination quotidienne, à midi (heure normale locale), des conditions
41
météorologiques: température, humidité relative, vitesse du vent et pluie durant les 24 dernières heures
(s'il y en a eu). Le mois doit également être précisé.
La méthode consiste essentiellement à résoudre une série d’équations (Van Wagner et Pickett, 1985)
qui peuvent être calculées rapidement par ordinateur; elle contraste en cela avec les méthodes précédentes
qui utilisaient une série de courbes qui étaient converties directement sous forme de tables. IFM peut
également être calculé à l’aide de la série publiée de neuf tables établies à partir de ces équations (Service
canadien des forêts, 1984).
Il est à remarquer que, même Si IFM est calculé à partir des mesures des conditions météorologiques à
midi, il est en réalité représentatif des conditions du milieu de l’après-midi quand le danger d’incendie est
au maximum, moment généralement établi à 16 h. En effet, au cours des premiers travaux, des
corrélations ont été établies entre les variables pour les conditions météorologiques à midi et les données
sur la teneur en eau du combustible léger et les feux expérimentaux, données qui ont été obtenues plus
tard dans l’après-midi. À cet égard, la méthode IFM est semblable à toutes les autres méthodes utilisées
au Canada depuis 1938.
Figure 2.7: Structure de l’IFM
Pour chacun des trois types de combustibles pris en considération, ils ont créé un indice com-prenant
deux phases, une phase pour le mouillage par la pluie et une autre pour le dessèchement. Ces sous-index,
appelés «indices du combustible», permettent de rendre compte de l’augmentation de la teneur en eau
après une pluie et de sa diminution sous l’effet du dessèchement journalier. Afin d’obtenir le meilleur
42
effet psychologique, ils ont établi ces indices de telle sorte que leur valeur numérique croît lorsque la
teneur en eau décroît. Les trois indices de la teneur en eau des combustibles sont :
2.12.1 L’indice du combustible léger (ICL) [FFMC : Fine Fuel Moisture Code]
Qui représente la teneur en eau d’une couche de litière (profondeur 1-2 cm5) et d’autres combustibles
légers séchés pesant environ 0,25 kg6 (masse anhydre) par mètre carré ; cette indice est utilisé pour
indiquer la facilité d’allumage (d’inflammation), ou la probabilité d’inflammation.
2.12.2 L’indice de l’humus (IH) [DMC : Duff Moisture Code]
Cet indice représente la teneur en eau d’une couche de matières organiques en décomposition et peu
compactes
pesant environ 5 kg (masse anhydre) par mètre carré ; IH détermine la probabilité de
l’allumage du feu due à la foudre et montre également le taux de consommation de combustible dans des
couches de profondeur modérées (profondeur 5-10 cm).
2.12.3 L’indice de sécheresse (IS) [DC : Drought Code]
Il est représentatif d’une couche profonde de matières organiques compactes pesant peut être 25 kg
(masse anhydre) par mètre carré. IS est un indicatif des états d’humidité à long terme, et détermine la
résistance d’éteindre le feu, et indique la consommation de combustible dans les couches profondes (1020 cm).
Ces définitions fournissent des éclaircissements utiles, mais pour la comparaison des indices, il vaut
mieux parler en termes de capacité de rétention d’eau et de vitesse de dessèchement. On considère que
chaque combustible sèche de façon exponentielle et que sa vitesse de dessèchement à un moment donné
est proportionnelle à sa teneur en eau libre. Un indice approprié de la vitesse de dessèchement est donc
fourni par le laps de temps (timelag) nécessaire pour réduire d’une quantité 1 - 1/e (d’environ 2/3) la
quantité d’eau libre dépassant la teneur à l’équilibre ou par la pente de la courbe exponentielle de la
teneur en eau libre en fonction du temps, pente appelée ici «vitesse de dessèchement logarithmique». Le
tableau 2.3 fait voir pour chacun des indices d’humidité ce laps de temps, exprimé en nombre de jours
normaux (température de 21,1 0C et humidité relative de 45 % à midi en juillet), ainsi que sa capacité de
rétention d’eau, ses caractéristiques et les paramètres météorologiques à mesurer chaque jour pour son
calcul.
Les deux indices d’humidité qui changent lentement, l’IH et l’IS répondent aux changements de la
longueur des jours au cours de la saison. En effet, la quantité d’eau perdue chaque jour par les
combustibles à desséchement lent dépend autant de la durée du jour que des conditions atmosphériques à
5
6
Centimètres.
Kilogrammes.
43
midi. Par contre, l’ICL, qui représente la teneur en eau des combustibles à dessèchement rapide au milieu
de l’après-midi, dépend moins de la longueur du jour.
Indice Laps de temps
Capacité de
Paramètres
Profondeur
considéré
rétention d’eau
requis
théorique du
(jours)
(mm)
combustible (cm)
ICL
2/3
0.6
T, H, W, r
1.2
IH
12
15
T, H, r, mo
7
IS
52
100
T, r, mo
18
Où T : température, H : humidité ; W : vent, r : pluie, mo : mois.
Quantité théorique
du combustible
(kg/m2)
0.25
5
25
Tableau 2.3: Propriétés des trois indices d’humidité des combustibles
En combinant deux à deux les trois indices d’humidité et le vent, on obtient deux indices
intermédiaires qui, combinés, donnent l’indice final, I’IFM (figure 2.7). Ces trois derniers indices sont :
2.12.4 L’indice de propagation initiale (IPI) [ISI : Initial Spread Index]
Cet indice résulte de la combinaison du vent et de l’ICL et qui représente uniquement la vitesse de
propagation sans tenir compte de l’effet des quantités variables de combustibles ; autrement dit IPI
indique le taux de propagation du feu immédiatement après l’allumage.
2.12.5 L’indice du combustible disponible (ICD) [BUI : Build Up Index]
Cet indice résulte de la combinaison de l’IH et de l’IS et qui représente la quantité totale de matières
forestières disponibles au feu en progression ;
2.12.6 L’indice Forêt-Météo (IFM) [FWI : Fire Weather Index]
Cet indice résulte de la combinaison de l’IPI et de l’ICD et qui représente l’intensité du feu en
progression d’après la quantité d’énergie produite par unité de longueur du front.
Le calcul des différents indices se fait à l’aide de fonctions mathématiques qui sont décrites plus loin ;
de plus, chaque indice a une échelle de valeurs qui lui est propre. La fonction rendant compte du vent
dans l’IPI est une exponentielle simple qui double la valeur de l’IFM pour chaque augmentation de 19
km/h7 de la vitesse du vent. Les fonctions qui s’appliquent à l’indice du combustible léger et à l’indice de
l’humus sont semblables à celles de la méthode précédente. Pour tenir compte de l’effet du dessèchement
à long terme, on a donné à l’IS un poids faible mais variable qui apporte une correction à l’IH.
Le type de combustible dit «standard» est une forêt de pin généralisée se rapprochant le plus de la forêt
de pin gris et de pin tordu qu’on trouve en une bande presque continue d’un bout à l’autre du Canada. Ce
type correspond aux données de terrain sur lesquelles repose l’IFM. En fait, pour l’élaboration de l’IFM,
7
Kilomètres/heures
44
ils ont également utilisés des peuplements de pin blanc et de pin rouge ainsi que des plantations de pin
rouge pour obtenir les données sur la teneur en eau des combustibles et le comportement des feux. Il a
cependant été décidé très tôt que le but principal du projet était la création d’un nouvel indice de danger
de feu basé uniquement sur les conditions météorologiques, qui permettrait d’obtenir des résultats
uniformes partout au Canada. La question de savoir comment le comportement du feu varie en fonction
du type de combustible est apparue comme étant un problème distinct qui devait être abordé d’une autre
façon.
Remarque :
1.
ICL peut être utilisé pour indiquer la facilité d’allumage, ou la probabilité d’inflammation.
Allumage potentiel
Valeurs d’intervalle de l’ICL
Bas
Moyen
Elevé
Très élevé
Extrême
0–76
77–84
85–88
89–91
92+
Tableau 2.4: Inflammation potentielle par rapport à la valeur ICL
2.
L’indice IFM est utile pour déterminer les besoins de lutte contre l’incendie en plus d’être utilisées
pour l’information sur les conditions de risque d’incendie. Bien qu’IFM ne soit pas calculé directement à
partir des données météorologiques, il dépend de ces facteurs IPI et ICD.
IFM
valeur
Description
Type de danger d’allumage potentiel
Bas
0-5
Feu commence de glisser
Une personne peut tuer le feu
Moyen
5-10
Basse violence du feu
Simples équipement arrête le feu
Elevé
10-20
Moyenne violence du feu
La présence des pompiers est obligatoire
Très élevé
20-30
Surface du feu très intense
Difficile à contrôler le feu
Extrême
30+
Développement active du feu
L’incendie devient critique et intense
Tableau 2.5: Le danger potentiel d’incendie d’après l’indice IFM
Il ya deux objectifs du réseau de capteurs sans fil pour les feux de forêts pour cette étude :
(i) donner une alerte rapide d’un incendie potentiel de forêt, et
(ii) évaluer l’ampleur et l’intensité de l’incendie, si cela se réalisera. Les deux buts nécessaires pour
arrêter les mesures nécessaires pour combattre un incendie de forêt. Pour atteindre ces objectifs, l’étude
vise à concevoir les réseaux de capteurs basés sur les deux principales composantes de la méthode IFM :
45
ICL, et IFM. ICL est utilisé pour atteindre le premier objectif et IFM est utilisé pour atteindre le
deuxième.
Une forte valeur d’IFM indique qu’en cas de déclenchement d’un incendie, le feu serait difficile à
contrôler. Cette intuition est soutenue par plusieurs études. Voici à titre d’exemple trois indices IFM avec
leurs significations sur terrain :
(a) un incendie de surface modérée (IFM = 14).
(b) un incendie de surface très intense (IFM = 24).
(c) développement actif d’incendie (IFM = 34).
Figure 2.8: Différentes formes de l’IFM
2.13 Algorithme de détection Canadien
1.Algorithme IFM
2. Début
3. écrire (‘donner la valeur de T et H et P et V’) ;
4. lire (température,‘T’) ;
5. lire (humidité, ‘H’) ;
6. lire (pluie, ‘P’) ;
7. lire (vent, ‘V’) ;
8. ffmc = ICL (T, H, P, V); //fine fuel moisture code: indice de combustible léger
9. isi = IPI (ffmc, V); //initial spread index : indice de propagation initiale
10. dmc = IH (T, H, P) ; // Duff Moisture Code : indice de l’humus
11. dc = IS (T, P) ; //Drought Code : indice de sécheresse
12. Bui = ICD (dmc, dc) ; // Build Up Index : indice du combustible disponible
13. fwi = IFM (isi, bui) ; // Fire Weather Index : indice Forêt-Météo
14. si (fwi >=0 et fwi <5) alors
15. écrire (‘le niveau de danger est bas’)
16. sinon
17.
si (fwi >=5 et fwi <10) alors
18.
écrire (‘le niveau de danger est moyen’)
19.
sinon
46
20.
si (fwi >= 10 et fwi<20) alors
21.
écrire (‘le niveau de danger est haut’)
22.
sinon
23.
si (fwi >= 20 et fwi <30) alors
24.
écrire (‘le niveau de danger est très haut’)
25.
sinon
26.
si (fwi >= 30) alors
27.
écrire (‘le niveau de danger est extrême’) ;
28.
fin si
29.
fin si
30.
31.
fin si
fin si
32. fin si
33. fin
Figure 2.8 : Algorithme Canadien de détection des feux de forêt
2.14 Conclusion
L'utilisation des systèmes de surveillance des incendies de forêt basée sur des réseaux de capteurs sans
fil apporte plusieurs avantages par rapport aux systèmes traditionnels nécessitant des capteurs câblés.
Ces avantages peuvent être énumérés comme suit :
1. Les nœuds capteurs individuels sont relativement peu coûteux, permettant de collecter plus de
données comparativement à son coût;
2. Les composants logiciels standardisés, librement disponibles et modulaires réduit les coûts de
développement, de modification et de mise à jour du système;
3. Les nœuds capteurs sont relativement faciles à déployer et à exploiter;
4. Un système à base de capteurs peut assurer une réponse en temps réel de déclenchement des feux de
forêtpour les services des feux de forêt concernés.
47
PARTIE 2 : Contributions
PARTIE II : Contributions
48
CHAPITRE 3 : Conception et outils d’implémentation
3
Conception et outils
d’implémentation
3.1 Introduction
Dans ce chapitre nous présentons l’approche de détection des feux de forets adoptés dans ce mémoire.
Les nouvelles versions des deux méthodes de détection des feux de forêt décrites dans ce chapitre. Nous
présentons également dans ce chapitre certains diagrammes UML qui nous permettent de modéliser à la
fois les échanges de messages entre les objets communicants qui forment l’environnement d’évaluation et
de tests, et aussi les différentes interactions entre le concepteur et cet environnement.
3.2 Approche de détection des feux de forêts adoptée
L’approche de détection des feux de forêt que nous avons adoptée dans ce mémoire est illustrée par la
figure 3. Elle repose sur trois étapes principales : collecte de données environnementales, dissémination
de l’alarme en cas de détection de feux et l’analyse et prise de décision.
Figure 3 : Schéma bloc de l’approche proposée.
49
3.2.1 Module de collecte de données
Ce module permet de capturer les différentes conditions météorologiques nécessaires pour le calcul
des indices (ou formules), cette opération s’exécute périodiquement jusqu’à ce qu’un événement de
détection de feu a lieu. Une fois le feu détecté, une alarme est générée et envoyé au module de
communication pour qu’il l’achemine à son tour au centre de prise de décision.
3.2.2 Module de communication
Le module de communication est assuré par un réseau de capteurs structuré en mode de transmission à
un saut (topologie en étoile) ou en mode de transmission multi-sauts (topologie mesh). Il permet
d’acheminer les données (alarmes) générées par le module de collecte de données vers le module
d’analyse en respectant certains paramètres de qualité de service tels que la fiabilité (l’alarme doit arriver
au sink d’une manière sûre), contrainte temporelle (l’alarme doit arriver dans un temps raisonnable) et la
sécurité (le cheminement de l’alarme doit être sécurisé contre toute attaques ou actes malveillants).
3.2.3 Module d’analyse
Après avoir réceptionné les données conformément aux paramètres de qualité de service exigés par
l’application, le module d’analyse doit examiner les alarmes reçues selon leurs degrés d’intensité du feu
indiqué (voir tableau 2.2 page 41et tableau 2.5 page 45). Ensuite, cette information est traitée par le centre
de prise de décision et une opération à grande échelle d’investigation de la foret sera lancée en
conséquence, en utilisant en général des hélicoptères. Ceci a pour objectif la lute contre le feu déclenché
dans l’endroit par lequel l’alarme est arrivée et aussi d’autres endroits détectés.
3.3 Amélioration de la méthode canadienne
3.3.1 La version originale
Les conditions météorologiques et les indices à calculer sont représentés dans la figure 2.7 (page 42).
La spécification des indices et l’algorithme de calcul des indices sont détaillés dans l’annexe B.
3.3.2 Modifications apportés à la méthode canadienne
La figure suivante porte les principales modifications apportées à la méthode Canadienne. Les hypothèses
qui vont suivre présentent plus de détails sur cette amélioration.
50
Figure 3.1 : Structure de l’indice forêt météo adapté
3.3.2.1 Hypothèses
Pour simplifier les calculs de cette méthode, nous allons nous limiter à la période chaude de l’année,
où la probabilité des feux de forêts est forte. Prenons comme exemple le mois du juillet où l’activité des
feux augmente. Pour cela, nous avons affecté au paramètre précipitation (voire l’algorithme présenté dans
la figure 2.8 et figure 3.1) la valeur zéro « 0 » dans le symbole P dans les lignes 6,8,10,11. Ceci est
possible puisqu’il s’agit de l’été (absence de pluie). Pour cela, nous préciserons dans les tableaux Lf et Le
(voir Annexe B tableau B.1 et B.2) les valeurs spécifiques du mois de juillet. Nous mettrons aussi dans le
paramètre vent la valeur moyenne de l’été calculé 13(d’après les services météorologiques de la ville
d’ORAN). Ainsi, les sous système de précipitation calculés dans les équations qui définissent r 0 doivent
être éliminés. De même pour les sous systèmes de vent, la vitesse du vent W sera fixé à la valeur 13.
3.4 Améliorations de la méthode Coréenne
3.4.1 La version originale
La version originale de cette méthode est présentée dans le chapitre précédent (l’équation 2.1 et
l’équation 2.2).
3.4.2 Modifications apportés à la méthode Coréenne
3.4.2.1 Hypothèses
Pour simplifier les calculs de cette méthode, comme la méthode Canadienne on va se limiter à la
période chaude de l’année, supposons c’est le mois du juillet, pour cela on à pré dans le paramètre
précipitation (voire équation 2.1, page 41) zéro « 0 » car c’est l’été.
51
3.5 Modélisation UML de l’environnement d’évaluation et de test
Dans cette section, nous utilisons l’approche de modélisation UML pour modéliser les tâches de
configuration et les échanges d’informations entre déférents objets communicants qui interviennent dans
l’environnement d’évaluation et de test utilisé dans le cadre de ce projet. Les diagrammes de séquence
nous permettent de modéliser ces échanges et le diagramme de cas d’utilisations nous facilite la
description de l’interaction du concepteur avec l’environnement d’évaluation et de test. L’objectif de cette
modélisation est de montrer que l’environnement de test utilisé n’est pas lié à un choix technologique
particulier (MicaZ dans notre cas) mais qui peut s’appliquer à d’autres technologies concurrentes telles
que WaspMote [Web 14], BTnode [Web 15]. L'objectif de cette conception est de décrire
conceptuellement le fonctionnement de cet environnement indépendamment du choix des plates-formes
matérielles envisagés. Cette étude de modélisation a été motivée par le fait que les plates-formes de
capteurs disponibles sur le marché obéissent généralement aux mêmes règles d'utilisation et
d'exploitation. Elle nous facilitera dans le futur de mener de nouvelles expérimentations et tests sur
différentes plates-formes à des échelles variables.
3.5.1 Diagrammes de séquence
Nous décrivons dans les paragraphes qui suivent les différents diagrammes de séquences modélisant
les aspects pertinents de l’environnement d’évaluation et de test. Il s’agit dans un premier temps des
diagrammes dédiés à la configuration et le déploiement pour deux cas distincts : cas mono saut et cas
multi sauts. Le deuxième cas n’a pas été expérimenté dans ce travail, mais qui ne présente pas réellement
de difficultés techniques. Il suffit qu’un algorithme de routage adapté pour notre contexte soit disponible
pour pouvoir l’implémenter dans les nœuds relais. Dans un second temps, il s’agit d’un diagramme de
séquence dont l’objectif est de mieux illustrer les séquences par lesquelles passe une opération de collecte
de données depuis la source jusqu’au sink.
3.5.1.1 Configuration et déploiement
3.5.1.1.1
Cas filaire
Figure 3.2: Diagramme de séquence modélisant le déploiement et la configuration
52
Ce diagramme montre l’échange des différents messages de configuration et de déploiement qui
peuvent avoir lieu entre les objets communicants : sink et le poste de travail. Dans ce cas, le capteur est
supposé fixé dans la carte de programmation (sink).
3.5.1.1.2 Cas sans fils : OTAP (Over The Air Programming)
Figure 3.3: Diagramme de séquence modélisant le déploiement/configuration des capteurs et le relais via
la radio
Ce diagramme montre l’échange des différents messages de configuration et de déploiement qui
peuvent avoir lieu entre les objets communicants : capteurs, relais, sink et le poste de travail. Dans ce
cas, la programmation des capteurs et des relais se fera par la radio, le médium c’est l’air.
3.5.1.2 Récupération des données
3.5.1.2.1
Cas mono saut
Figure 3.4: Diagramme de séquence modélisant la collecte des données en mode mono saut
53
Ce diagramme montre l’échange des différents messages de collecte des données qui peuvent avoir
lieu entre les objets communicants : capteurs, sink et le poste de travail.
3.5.1.2.2 Cas multi saut
Figure 3.5: Diagramme de séquence modélisant la collecte des données en mode multi saut
Ce diagramme montre l’échange des différents messages de collecte des données qui peuvent avoir
lieu entre les objets communicants : capteurs, relais, sink et le poste de travail.
3.5.2 Diagramme de cas d’utilisation
Figure 3.6: Diagramme de cas d’utilisation qui modélise le raisonnement suivie
54
Ce diagramme permet de représenter les différentes interactions des différents acteurs (utilisateur,
capteur, sink) avec l’environnement d’évaluation et de tests dont le but est de montre les différentes
utilisations de cet enivrement selon plusieurs aspects : traitement et test, fonctions disponibles, et
configurations possibles.
3.6 L’environnement d’évaluation et de test
La figure 3.6 présente l’environnement d’évaluation et de test (banc d’essai) que nous avons utilisé
pour l’implémentation réelle des deux méthodes de détection des feux de forets et aussi pour les phases
d’évaluation et de test effectuées. Il s’agit d’un band d’essai orienté éducation fabriqué par la firme
Crossbow [Web 05]. Il est composé principalement d’une partie matériel et d’une partie logiciel. La partie
matérielle est composée parles objets communicants suivant :
- Les nœuds capteurs (A et B dans la figure) qui assurent la collecte selon un modèle prédéfini des
grandeurs physiques de l’environnement telles que la température, l’humidité, …etc
- Les nœuds relais (C et D dans la figure) dont la tâche principale est le routage des paquets vers le Sink.
- Le Sink (S dans la figure) qui est responsable de la collecte de toutes données issues des nœuds
capteurs.
- Enfin, le poste de travail dans lequel est réalisé des tâches de configuration, développement et de
programmation des nœuds capteurs.
Figure 3.7: Schéma simplifiée du banc d’essai
3.6.1 La MIB520 (Sink ou station de base)
C’est une carte d’interface USB [22] [23] [Web 05] pour la programmation de toutes les plates formes
MICA. Elle possède deux connecteurs de 51 pins pour raccorder la carte au capteur.
55
Figure 3.8: Architecture interne du MIB520CB
Figure 3.9: MIB520CB attaché avec le capteur
Dispositif
Spécification
Taux de transmission
57.6 K
inclue avec l’unité
Interface USB câble USB Male/Femelle
Interface capteur
Connecteurs
51-pin
Indicateurs
LED capteur: rouge vert, jaune
LED – allumé : vert,
Interface
Indicateurs
En cours de programmation : rouge
Programmation
Switch
Mise à zéro de la programmation du processeur et du
capteur
Interface Jtag
Connecteur
10-pin de tête male
alimentation
Allume le bus USB
Tableau 3.1: Aspect technique de la MIB520
56
3.6.1.1 ISP (In System Processor)
La MIB520 contient un processeur Atmega16L intégré dans le système (ISP) situé à U14 pour
programmer les capteurs. Le code est téléchargé par l’USB dans l’ISP, ensuit du l’ISP vers le capteur
[22].
3.6.1.2 Programmation des capteurs par la MIB520
La programmation des capteurs exige d’avoir TinyOS installés sur le pc. Ensuit la programmation ISP
des capteurs se fait par la connexion des capteurs MICAz a la MIB520 et ce dernier avec le pc via le câble
USB.
3.6.1.3 Reset
Le bouton Reset mettre à zéro le processeur du capteur et l’ISP, il doit aussi mettre à zéro le système
de surveillance à le quelle exécuté sur pc [22].
3.6.1.4 JTAG
La MIB520 contient un connecteur J13 qui connecte Atmel JTAG au circuit de débogage. Ce
connecteur assure l’alimentation de JTAG pod [22].
a.
Le pilote FTDI pour le port COM USB Virtuel
L’utilisation de la MIB520 nécessite l’installation du pilote FTDI FT2232C pour qu’il puisse
configurer le port USB comme un port COM virtuel.
 Lors de la connexion de la MIB520 avec le pc, Windows détecte la présence d’un nouveau
matériel, et affiche une fenêtre qui nous indiquons comment installer ce pilote, pour cela,
sélectionner la case à coché « installer à partir d’une liste ou d’un emplacement spécifique
(avancée) », parcourir jusqu’au dossier « pilote MIB520 » dans le CD-ROM du kit de RCSF, et
suivez le processus d’installation.
 Après la fin de l’installation, on doit trouver deux ports COM ajoutés dans le panneau de
configuration à l’emplacement suivant : Panneau de configuration Système  Matériels
Gestionnaire de périphérique ports.
 Les deux ports ajoutées sont com(n) et com(n+1) où le premier est réservé à la programmation des
capteurs et le seconde pour la communication.
3.6.1.5 Alimentation
La MIB520 est alimenté par le port USB du pc.
Remarque : au cours de la programmation du MICAz par la MIB520, il faut éteindre le MICAz par le
commutateur de la batterie (il faut programmer le MICAz sans batterie).
57
3.6.1.6 La station de base
Une station de base permet l'agrégation des données de réseau de capteur sur un PC ou toute autre
plate-forme d'ordinateur. N'importe quel capteur MICAz peut fonctionner comme une station de base
quand il est relié à un PC standard ou à une passerelle. La MIB520 fournit une interface série/USB pour
la programmation et la communication de données. Crossbow offre également une solution de passage
autonome, la MIB600 pour les réseaux Ethernet basé sur le TCP/IP [22].
3.6.2 La carte MPR2600 (MICAz)
Figure 3.10: MPR2600 avec antenne standard
Le MPR2600 est basé sur l'Atmel ATmega128L. L'ATmega128L est un microcontrôleur de basse
tension qui exécute MoteWorks par sa mémoire flash interne. La carte processeur simple (MPR2600) doit
être configuré pour capturer / traiter / communiquer par radio simultanément.
Le connecteur de 51 pins supporte des entrées analogiques, E/S numérique, I2C, SPI et UART. Ces
interfaces le rendent facile à se relier à une large variété de périphériques externes.
La radio IEEE 802.15.4 (ZigBee) du MICAz (MPR2600) offre deux hautes vitesses (250 Kbps) et une
sécurité matérielle (AES-128) [24].
Nœud capteurs
MicaZ
Telos
Imote2
RCSF430
Wavenis (Wave
front)
Processeur
Atmel ATMega
TI MSP430
Intel PXA271
128L
TI MSP430
TI MSP430
Xscale
Vitesse du processeur
16 MHZ
8 MHZ
13-416 MHZ
8 MHZ
8 MHZ
RAM
4 Ko
2 Ko/10 Ko
256 Ko
10 Ko
2 Ko
Espace programme
128 Ko
60Ko/48Ko
32 Mo
48 Ko
128 octets
Flash
512 Ko
256 Ko
32 Mo
1 Mo
Néant
Communication série
UART
DS2411
SPI, E2P
DIO, SPI, I2C, UART UART, GPIO
58
Batterie
2xAA
2/3A
3xAAA
PoLiFex
2xAA
Voltage
2.7 V
1.8 - 3.6 V
3.2 - 4.5 V
2.2 V
2.4 – 6 V
Radio
TI CC2420
TI CC2420 802.15.4
TI CC2420
TI CC1100
ASICRF Wavenis
802.15.4
Fréquence (KHz)
2400-2483
2400-2483
2400-2483
315/433/868/915
433/868/915
Débit de données
250 Kb/s
250 Kb/s
500 Kb/s
250 Kb/s
4.8-253 Kb/s
Dimension (mm)
58x32x7
13x26x5
36x48x9
65x40x6
26x20x4.5
Tableau 3.2: Caractéristiques de quelques capteurs les plus courants [25]
3.6.2.1 Schéma et diagramme bloc du MPR2600 / MICAz
Figure 3.11: Schéma fonctionnelle de MPR2600 [24]
Processor/Radio Board
MPR2600CA
Remarks
Processor Performance
Program Flash Memory
128K bytes
Measurement (Serial) Flash
512K bytes
Configuration EEPROM
4K bytes
Serial Communications
UART
0-3V transmission levels
Analog to Digital Converter
10 bit ADC
8 channel, 0-3V input
Other Interfaces
Digital I/O,I2C,SPI
Current Draw
8 mA
Active mode
< 15 μA
Sleep mode
2400 MHz to 2483.5 MHz
ISM band, programmable in 1 MHz
> 100,000 Measurements
RF Transceiver
Frequency band
steps
Transmit (TX) data rate
250 kbps
RF power
3 dBm(min) to 0 dBm(typ)
59
Receive Sensitivity
-90 dBm (min), -94 dBm (typ)
Adjacent channel rejection
45 dB
+ 5 MHz channel spacing
30 dB
- 5 MHz channel spacing
19.7 mA
Receive mode
11 mA
TX, -10 dBm
14 mA
TX, -5 dBm
17.4 mA
TX, 0 dBm
20 μA
Idle mode, voltage regulator on
1 μA
Sleep mode, voltage regulator off
Current Draw
Electromechanical
External Power
2.1 V – 3.6 V
Size (in)
0.95 x 0.95
(mm)
24.13 x 24.13
Weight (oz)
0.11
(grams)
3
LCC68
Tableau 3.3: Caractéristiques de MPR2600 [24]
3.6.2.2 Radio
La radio CC2420 de MICAz doit être accordée dans les canaux d’IEEE 802.15.4 qui sont numérotés
de 11 à 26 séparées par 5 MHz (2.405 GHz à 2.480 GHz) [22], le canal doit être sélectionné par
l’exécution de la routine radio CC2420 dans TinyOS suivante :
CC2420Control.TunePreset (uint8_t chnl).
Par défaut le canal 11 (2.480GHz) est choisi.
3.6.2.3 Flash Data Logger et Serial ID Chip
Tous les nœuds capteurs d’enregistrement des données, de mesures, d’informations d’utilisateur à 4Mbit serial flash (Atmel AT45DB041) sont connectés à un port ATMega128L ; cette puce est soutenue
dans TinyOS qui utilise cette puce en tant que système de fichiers micro. Le dispositif parallèle flash
support plus de 100 000 lecture de mesures [22].
3.6.2.4 Atmega128
Le processeur d'ATMega128L sur les nœuds capteurs a beaucoup de fusibles programmables pour
commander divers paramètres [22].
60
3.6.2.5 La batterie
Matériel de la plateforme Mote
Batterie standard
(#exigé)
Capacité typique de
batterie (mA-hr)
Opération pratique
Voltage intervalle (V)
MICAz
AA (2)
2000, Alcaline
3.6 à 2.7
Tableau 3.4: Alimentation du MPR2600 [22]
a.
Consommation
Dispositif
Opération (mA)
MICAz
ATMega128L
pleine opération
12 (7.37 MHz)
sommeil
0.010
réception
19.7
transmission (1 mW énergie)
17
sommeil
0.001
écriture
15
lecture
4
sommeil
0.002
Radio
Serial flash Memory
Tableau 3.5: Consommation d’énergie sur un MPR2600 [22]
b.
Moniteur de tension de la batterie MICAz [22]
Le MICAz utilise une référence de tension interne précise pour mesurer la tension de la batterie
(Vbatt), et pour mesurer cette tension on applique cette formule :
1252.352
𝑉𝑏𝑎𝑡𝑡 = 𝐴𝐷𝐶_𝐶𝑜𝑢𝑛𝑡
2.3
Où :
Vbatt = Tension de la batterie.
ADC_Count = donnée par la mesure de référence de tension précise de ADC.
Le composant VoltageM.nc de TinyOS peut être lié dans une application pour fournir ces possibilités
de mesure. Le mot-clé réservé TOS_ADC_VOLTAGE_PORT est tracé au canal 30 d’ADC dans le
MICAz.
c.
Luminosité [26]
𝐴𝐷𝐶𝐶𝑜𝑢𝑛𝑡𝑉𝑎𝑙𝑢𝑒 (𝐴𝐶𝑁𝑇𝑥) = 𝐼𝑁𝑇(16.5 ∗ [𝐶𝑉 − 1]) + 𝑆 ∗ 𝐶𝑉
61
2.4
𝑜ù𝐶𝑉 = 2𝑐 𝑒𝑡𝐶 = 𝑑𝑎𝑡𝑎& 0𝑥7 >> 4 𝑒𝑡𝑆 = 𝑑𝑎𝑡𝑎& 0𝑥𝐹
2.5
𝐿𝑖𝑔𝑕𝑡𝑙𝑒𝑣𝑒𝑙 (𝑙𝑢𝑥) = 𝐴𝐶𝑁𝑇0 ∗ 0.46 ∗ 𝑒 −3.13∗𝑅
2.6
𝑜ù𝑅 = 𝐴𝐶𝑁𝑇1/𝐴𝐶𝑁𝑇0
2.7
d.
Température [27]
𝑇𝑒𝑚𝑝𝑒𝑟𝑎𝑡𝑢𝑟𝑒 = −38.4 + 0.0098 × 𝑇𝑒𝑚𝑝𝑟𝑒𝑎𝑑𝑖𝑛𝑔
e.
2.8
Humidité [27]
𝐻𝑢𝑚𝑖𝑑𝑖𝑡é = −4.0 + 0.0405 × 𝐻𝑢𝑚𝑟𝑒𝑎𝑑𝑖𝑛𝑔 − 0.0000028 ∗ 𝐻𝑢𝑚_𝑟𝑒𝑎𝑑𝑖𝑛𝑔 2
2.9
3.6.3 Carte de capture MTS400
Développé en même temps avec MTS420 dans les laboratoires de recherches d'UC Berkeley et d'Intel,
le MTS400 offre quatre paramètres de détection environnementaux de base. Ces cartes capteurs utilisent
la dernière génération des capteurs de support basées sur IC. Ces dispositifs numériques d’énergie
efficace fournissent à leur tour la durée de vie prolongées de la pile et des performances la où des nœuds
capteur exigent l’entretien des champ-déployés. Ces capteurs sont prévus pour une large variété
d'applications s'étendant d'une station météorologique sans fil simple à un plein réseau maillé des nœuds
de contrôle de l'environnement.
Dispositif
Board
Spécification
Operating temp. range
-10°C to , +60°C
Operating humidity range
0% RH to 90% RH non-condensing
Dual-axis
Analog Devices
ADXL202JE
Accelerometer
Acceleration range; resolution
±2 g; 2 mg at 60 Hz
Nonlinearity
0.2% of full scale
Zero g bias level
2.0 mg/°C from 25°C
Barometric
Intersema
MS5534AM
Pressure Sensor
Pressure range; resolution
300-1100 mbar; 0.01 mbar
Accuracy
± 1.5% at 25°C
Ambient Light
TAOS
TSL2550D
Sensor
Spectral responsivity
400-1000 nm, similar to human eye
Relative Humidity
Sensirion
SHT11
& Temperature
Humidity range; resolution
0-100% RH; 0.03% RH
Sensor
Absolute RH accuracy
± 3.5% RH
Temp. accuracy
± 0.5°C @ 25°C
Tableau 3.6: Caractéristiques du MTS400 [28]
62
3.6.3.1 Structure de paquet
Bytes : 5
0/7
4
2
TinyOS
Xmesh
XSensor
Voltage
Header
Header
Header
2
2
Humidité
Température
20
…
2
CRC
MTS400 Payload
Tableau 3.7: Structure du paquet MTS400[29]
La structure du paquet présenté au dessus concerne la distribution Windows avec MoteWorks installé.
Type
Field Name
Description
uint16_t
voltage
Battery reading (also known as vref or voltage)
uint16_t
humidity
Humidity reading.
uint16_t
temp
Temperature reading.
uint16_t
cal_word1
Pressure calibration word 1 (intersema pressure sensor)
uint16_t
cal_word2
uint16_t
cal_word3
uint16_t
cal_word4
uint16_t
intersematemp
This is the humidity and pressure sensor reading
uint16_t intersemapressure This is the barometric pressure and temperature sensor reading
uint16_t
taosch0
<Need info>
uint16_t
taosch1
<Need info>
uint16_t
accel_x
Acceleration reading on the x –axis
uint16_t
accel_y
Acceleration reading on the y –axis
Tableau 3.8: Définition des champs d’un paquet MTS400
3.7 Présentation des logiciels utilisés
Sous Windows, il ya plusieurs outils logiciels pour configurer, programmer les capteurs et visualiser,
récupérer, simuler les données issus des capteurs. Dans ce qui suit nous présentons ces outils.
3.7.1 Outils de visualisation
L’outil MoteView fourni avec le kit Crossbow nous fournit en temps réel les informations nécessaires
suivant une topologie du réseau de capteurs reprogrammables.
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é.
On peut récupérer de différents capteurs les informations transférées à la station de base, qui envoie les
données à travers le port USB du PC connecté [16]. On récupère alors la température, la luminosité,
l’humidité, les accélérations (suivant l’axe des abscisses x et des ordonnées y) ainsi que l’état de la
63
batterie après une minimal configuration nécessaire pour permettre de récupérer ces données (selon notre
configuration MTS400).
3.7.1.1
Vérifier l'installation de Postgre SQL
Pendant l'installation de MoteView une base de données statique a été incluse pour permettre de
démontrer les dispositifs de MoteView sans être relié à un réseau de capteur actif ou à un serveur à
distance/à base de données. Les étapes décrites ici s'appliquent également au visionnement des données
rassemblées d'un réseau de capteur actif [30].
1.
Se connecter en live à un réseau de capteur sur le PC personnel :
Suivez les étapes suivantes pour visualiser les données d'un réseau de capteur relié à votre PC
local par l'intermédiaire d’une station de base MIB520.
Cliquer dessus l'icône Connect to RCSF. Choisir l’onglet Mode, vérifier les options choisies sur la
figure suivante et cliquer sur Next >> (Figure 3.11).
Figure 3.12 L’onglet Mode du MoteView
2. Dans l’onglet Gateway, choisissez les caractéristiques de connexion de la station de base dans les
listes déroulantes, ensuite si on utilise la MIB520 on va choisir le port com le plus haut et le taux en
baud 57600(Figure 3.12).
64
Figure 3.13:L’onglet Gateway du MoteView
3. Dans l’onglet Sensor board, décocher la case à cocher « View Alternate Table », et choisissez dans
la liste déroulante le nom de l’application de la carte appropriée (Figure 3.13).
Figure 3.14: L’onglet Sensor Board du MoteView
65
4. Si vous ne recevez pas des données, il est nécessaire d’activer la case à coché Live dans la fenêtre
principale du MoteView.
3.7.1.2
Visualisation des onglets
Sept onglets fournissent différentes méthodes de visualiser les données de capteur.
 L’onglet Données : cet onglet montre les dernières lectures reçues de capteur pour chaque nœud
dans le réseau. Les colonnes incluent node ID, server timestamp et les valeurs du paquet de capteur.
Les données de capteur sont automatiquement converties en unités de technologie standard.
Le clic-gauche sur l'en-tête de colonne permet de trier par node ID, parent, température, tension,
résultat de la fois passée, ou n'importe quelle autre lecture de capteur. Le clic droit sur en-tête de colonne
montre un menu instantané avec des conversions d'unité relative au capteur.
Figure 3.15: MoteView : Données temps réel de 4 capteurs branchés avec la station
On peut tracer des courbes pour étudier en temps réel les différentes informations reçues des capteurs
sélectionnés :
66
Figure 3.16: Présentation des données sous forme de courbes
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 nœud capteurs.
Figure 3.17: Présentation graphique des capteurs
67
3.7.1.3 Processus d’obtention des données en live par les capteurs
1. Installer MoteWorks et MoteView.
2. Installer FTDI (Future Technology Devices International Limited) pilote pour le port USB (port
COM virtuel), on obtiendra deux ports de communication virtuels par exemple COM3, COM4 ;
3. La programmation des nœuds capteurs est donnée à l’aide de MoteConfig. en suite on choisie le
port numéroté le plus petit pour la programmation des capteurs.
4. Allez à settings Interface board MIB520  COM3 Apply.
5. Le
dossier
à
télécharger
devrait
être
situé
dans
le
chemin suivant
:
CrossbowMoteViewXmeshmicazMTS400XMTS400_2420_hp.exe
6. On doit programmer la station de base par le fichier qui se trouve à l’emplacement suivant :
CrossbowMoteViewXmeshmicazXMeshBaseXMeshBase_2420_hp.exe
7. Nous devrions garder la même Group ID pour tout le réseau, et Node ID devrait être « 0 » pour la
station de base et différente de zéro pour les nœuds.
8. Ensuite cliquer sur le bouton program qui télécharge le programme dans les nœuds, pendant la
programmation le Switch doit être mise en off.
9. Ensuit ouvrir MoteView, et connecter au RCSF.
a. dans la case passerelle s’assurer que le numéro du port com est le plus grand (com4 dans notre cas).
b. dans la carte de capture choisissiez MTS400 comme Application Name et cliquer sur view alternate
table. ensuite choisissez mts400_results comme the database table name.
c. Allumer tous les nœuds. (mettez les batteries sur les nœuds et le switch à ON).
d. Cliquer sur done. Vous devriez pouvoir observer des données qui commencent à apparaitre par tous
les nœuds.
Remarque :
1. L’application définie dans l’exemple précédent c’est une compilation de l’application qui se trouve
dans le chemin suivant (c à d on peut consulter/modifier le code source NesCde l’application) :
CrossbowcygwinoptMoteWorksappsxmeshXMTS400  pour les nœuds, et
CrossbowcygwinoptMoteWorksappsxmeshXMeshBase  pour la station de base.
2. Les exemples considérés et les chemins indiqués sont liées un système d’exploitation Windows xp
et 1.x pour la version de TinyOS sous Cygwin.
3.7.2 Outils de récupération des données
Plusieurs manières peuvent être utilisées pour récupérer les données à partir des capteurs ;
3.7.2.1 Sous l’environnement Windows
L’émulateur Cygwin en mode commande sous Windows permet de visualiser nos données, les
commandes à tapées sous Cygwin sont :
68
xserve –platform=micaz
xserve -device=com4
La première ligne permet d’ajuster la plateforme micaz pour charger les pilotes nécessaires, et la
deuxième permet d’écouter le port com4, le résultat de ces commandes sont présentées ainsi :
Figure 3.18: Récupération des données par Cygwin
3.7.2.2
Sous l’environnement Linux
Le mode commande est la seule manière de récupérer les données, pour cela quelques commandes
sont utiles pour ce but dont :
 Combiner l’application d’écoute avec le port série par :
/opt/tinyos-1.x/tools/src/sf/sf 9001 /dev/ttyUSB1 57600 micaz
Figure 3.19: Réservation du port série pour l’écoute
 Et dans un deuxième onglet récupérer les mesures par l’écoute du port série réservée :
69
/opt/tinyos-1.x/tools/src/sf/sflisten 127.0.0.1 9001
Figure 3.20: Exemple de lectures brutes envoyées par les capteurs
La figure précédente montre les mesures des capteurs déployées, l’identification des colonnes est
expliquée dans la figure 4.6
3.7.3 Outils de programmation
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 nœuds capteurs.
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 à 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 nœud capteur et le port de communication.
Dans notre cas cela donne :
70
make micaz install mib520,com3
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.
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 :
 Makefile
 Makefile.component
 Un fichier de configuration de l’application
 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 nœuds capteurs 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=mts400
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 (voir Annexe A).
Chaque application doit au moins contenir le composant Main et son module Nom_applicationM.nc ;
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 [16].
71
3.7.4 Outils de supervision
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 nœud capteur 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 nœud capteur particulier et trouver des messages spéciaux
comme les messages de mise à jour et de synchronisation [16].
Figure 3.21: Vue des paquets reçus d’un nœud capteur par Xsniffer
72
3.7.5 Outils de configuration
Si MoteConfig [31] est installé avec MoteView, on suit les étapes suivantes pour charger les capteurs:
Ouvrir MoteView situé sur le bureau, ou en allant à démarrer  programme CrossbowMoteView
2.0F. Ensuite appuyer sur le bouton programme Mote sur la barre d’outils de MoteView pour engendrer
l’interface utilisateur graphique (GUI) MoteConfig suivant les indications de la figure 3.21 et 3.22.
Si MoteConfig est installé avec MoteWorks, donc on peut l’ouvrir par un simple click sur l’icône situé
sur le bureau, ou en allant à démarrer programme Crossbow MoteConfig.
Figure 3.22: Le bouton program Mote
Figure 3.23: Fenêtre de programmation des capteurs
L'onglet local program est utilisé pour télécharger des programmes sur les capteurs par la station de
base.
Pour programmer des nœuds capteurs correctement, installer le matériel comme suit :
73
1. La station de base devrait être actionné et relié au PC par l'intermédiaire d'un port USB.
2. Si on utilisant la MIB510, le commutateur SW2 devrait être en position OFF.
3. Les nœuds capteurs devraient être fortement branchés à la station de base.
4. Les nœuds capteurs devraient être arrêtés avant la programmation.
Cliquer sur Settings  Interface Board pour choisir la passerelle correcte et les paramètres de port.
Les pilotes de MIB520 virtuels installeront deux ports COM séquentiels sur le PC. Le port basnuméroté est employé pour programmer, et le port haut-numéroté est utilisé pour la communication.
La figure montre l'interface de configuration de MIB520 qui a créé COM 3 et 4 sur le PC. Dans cet
exemple, COM doit être choisie comme port série.
Ensuite, cliquer sur le bouton « select » et naviguer jusqu'au programme qu’on désir installer sur le
capteur, enfin appuyer sur le bouton programme pour compiler cette application et la télécharger sur le
capteur.
Remarque :
1- MoteConfig est installé directement avec MoteWorks et MoteView, et en mode graphique c’est le
seul moyen pour programmer les capteurs ;
2- On peut programmer les capteurs sans d’être branché sur la MIB520, et pour le faire on coche la
case à coché « OTAP Enable » dans la figure précédente, (cette méthode pose beaucoup de
problèmes surtout pour débutant).
Figure 3.24: Le choix de la station de base
74
3.7.6 Outils de compilation
Figure 3.25: Vue de Programmer’s Notepad
Pour programmer les capteurs par Programmer’s Notepad il faut tout d’abord connecter le capteur à la
passerelle et la passerelle au pc, ensuite :
1. charger l’application dans l’interface ;
2. cliquer sur la liste déroulante Tools et choisissez :
a. shell (pour compiler l’application avant), et taper la commande suivant :
make micaz
et OK (sélectionner d’autres s’il n’est pas le cas des capteurs micaz),
b. vérifier la bonne compilation de cette application par ”Writing TOS Image” qui se trouve dans la
fenêtre de sortie dans PN2 (en bas),
c. charger l’application sur le capteur, appuyer sur shell et taper la commande suivant :
make micaz install mib520, com6
(com6 est le port bas numéroté). Cette commande est commune pour les autres méthodes
d’installation (Cygwin/linux).
75
3.7.7 Outils de simulation
Avrora [32] est un simulateur pour réseaux de capteurs. Pour obtenir une simulation fiable, ce
simulateur est cycle accurate ce qui signifie qu’il simule pour chaque nœud toutes les instructions qui
s’exécutent sur ce nœud. Certes, cette approche offre une modélisation particulièrement précise mais on
ne peut pas espérer qu’elle passe à l’échelle. Même dans le domaine des systèmes sur puce, une
modélisation cycle-précis s’avère trop détaillée pour être utilisable en pratique. De plus, Avrora est écrit
en Java et chaque nœud est implémenté par un thread (processus léger) Java ce qui impose une difficulté
supplémentaire : il faut synchroniser les threads pour s’assurer qu’un nœud ne reçoive pas un paquet
avant que son voisin ne l’ait envoyé.
Et pour simuler une application par l’outil Avrora :
avrora -seconds=10 -nodecount=1 -monitors=energy main.elf
Remarque: les simulations d’Avrora peuvent prendre plusieurs types de paramètres, dans l’exemple
courant Avrora simule l’énergie.
76
Figure 3.26: Simulation d’énergie par Avrora
3.8 Programmation des capteurs
Tout d’abord, il faut avoir installé TinyOS et NesC, et pour le faire il existe deux méthodes :

Sous Windows :
1. installer un émulateur linux comme Cygwin et installer dessus TinyOS et nesC et commencer
les étapes qui viennent par la suite.
2. installer le logiciel MoteWorks qui englobe l’étape précédente et avoir d’autre utilitaires qui
facilitent la taches comme Programmer’s Notepad, MoteConfig, Xsniffer ...

Sous linux : installer directement les packages de TinyOS et nesC.
77
3.9 Conclusion
Ce chapitre a été consacré à la description des versions originales et modifiées des deux méthodes de
détection des feux de forêt que nous avons utilisées dans ce travail. Il aborde également la description de
l'environnement d'évaluation et de tests à l'aide des diagrammes UML. Ces diagrammes mettent en
évidence différents scénarios de déploiement/configuration, le mécanisme de collecte de données et leur
dissémination vers le sink, ainsi que les interactions d'utilisations possibles avec l'environnement utilisé.
L'objectif de cette conception est de décrire conceptuellement le fonctionnement de cet environnement
indépendamment du choix des plates-formes matérielles envisagés.
78
CHAPITRE 4 : Implémentation et tests
4
Implémentation et tests
4.1 Introduction
Dans ce chapitre nous avons implémenté et testé deux méthodes de détection de feux de forêt puisnous
les avons comparées. Pour cela nous considérons un réel perçu en mode applicatif, ce réel perçu
correspond à un équipement en fonction pour gérer des cas de prévention et de détection des feux pour
mieux gérer les situations d’alerte contre la destruction des forêts.
Notre but consiste après la comparaison entres les deux systèmes de détection de feux des forêts de
sortir du premier résultat abordable issue des avantages des deux systèmes pour concevoir et implémenter
un système de détection des feux de forêt basé sur les réseaux de capteurs sans fils spécialement adapté à
notre région.
Figure 4.1 : Schéma bloc résumant la méthodologie suivie
79
4.2 Implémentation de la méthode Canadienne
Dans le chapitre 3, nous avons présenté les équations nécessaires pour calculer l’indice de cette
méthode, nous présentons ainsi le code source en langage NesC pour mesurer par les capteurs les
paramètres de ses équations (humidité et température).
async event result_t Humidity.dataReady(uint16_t data)
{
humid= (uint16_t)(-4.0 + 0.0405 * (double)(data) -0.0000028 *
((double)(data))*((double)(data)));//Formule pour obtenir l’humidité
pack->xData.data1.Humidity = humid;//Remplir le champ humidité dupaquet
call Leds.yellowToggle();//Clignoter le témoin jaune, signe d’une lecture
réussie
return SUCCESS;// Opération réussie
}
Figure 4.2: Code source NesCpour la mesure de l’humidité
async event result_t Temperature.dataReady(uint16_t data)
{
Temp= (uint16_t)(-38.4 + 0.0098 *(double)(data));//Obtenir la température
pack->xData.data1.Temperature
=
Temp;//Remplir
le
champTempérature
du
paquet
return SUCCESS; // Opération réussie
}
Figure 4.3: Code source NesC pour la mesure de la température
4.3 Implémentation de la méthode Coréenne
Le système Coréen contient comme paramètre à mesurer l’humidité et la luminosité, nous présentons
ici le code source NesCpour le calcul de la luminosité :
//pour le calcul de la grandeur luminosité, on doit collecter les deux
mesures suivantes : lum1 et Lum2
async event result_t TaosCh0.dataReady(uint16_t data)
{
uint16_t lum1=data; // Récupération de la donnée lum1
return call TaosCh1.getData(); // Appel de la routine getData
}
async event result_t TaosCh1.dataReady(uint16_t data)
{
uint16_t lum2=data;// Récupération de la donnée lum2
80
call Leds.yellowToggle(); // clignoter témoin jaune signe d’une lecture
réussie
m= mts(lum1,lum2); // Appel de la fonction de conversion
pack->xData.data1.lux = m; // Remplir le champ lux du paquet par la
valeur convertie
return SUCCESS; // Opération réussie
}
float mts(uint16_t h0, uint16_t h1)
{
uint16_t
ChData,CV1,CH1,ST1;//Définir
le
type
des
variables
ChData,CV1,CH1,ST1
int ACNT0,ACNT1; // Définir le type des variables ACNT0,ACNT1
float CNT1,R,Lux; // Définir le type des variables CNT1,R,Lux
ChData = h0 & 0x00ff;//Récupérer les octets de poids faibles
if (ChData == 0xff) return -1.0; // Valeur hors intervalle
ST1 = ChData & 0xf;//Prendre l’octetde poids faible
CH1 = (ChData & 0x70) >> 4;//L’opération « ET » logique de la données
avec 112, ensuite décaler à gauche de 4 positions
CV1 = 1 << CH1;
CNT1 = (int)(16.5*(CV1-1)) + ST1*CV1;//Calculer un variable intermédiaire
ACNT0 = (int)CNT1;//Prendre la partie entière de la dernier variable
ChData = h1 & 0xff;//Les étapes précédentes avec les octetsdu poids forts
if (ChData == 0xff) return -1.0; // Valeur hors intervalle
ST1 = ChData & 0xf;
CH1 = (ChData & 0x70) >> 4;
CV1 = 1 << CH1;
CNT1 = (int)(16.5*(CV1-1)) + ST1*CV1;
ACNT1 = (int)CNT1;
R = ((float)ACNT1)/((float)ACNT0);
Lux = (float)ACNT0*0.46/exp(3.13*R);//La valeur finale de la luminosité
return Lux;//Retourner la valeur de la luminosité
}
Figure 4.4: Code source NesC pour la mesure de la luminosité
4.4 Etude détaillée et conception des deux systèmes de détection
Lors de l’analyse de l’existant nous avons obtenu par différentes manières (cas pratique et simulation)
les résultats des deux systèmes, on détaillera par la suite ces résultats.
4.4.1 La méthode Canadienne
81
4.4.1.1 Le cas pratique
Pour intégrer le code source NesC dans le nœud capteur on introduit l’instruction suivante :
Make micaz install.1 mib510,/dev/ttyUSB0
Et pour confirmer le bon chargement du nœud capteur on trouve à la fin de la compilation/chargement
l’écran suivant :
Figure 4.5: Commande de chargement d’un capteur
Ensuite, pour voir les données issues du capteur on introduit l’instruction suivante :
/opt/tinyos-1.x/tools/src/sf/sf 9001 /dev/ttyUSB1 57600 micaz
Et on obtient comme résultat :
La réponse par « Note : sync » veut dire que le port 9001 partagé pour récupérer les données est
synchronisé. Et pour récupérer ces données on introduisant dans un deuxième onglet l’instruction :
/opt/tinyos-1.x/tools/src/s/sflisten 127.0.0.1:9001
On obtient les données suivantes :
82
Figure 4.6: Réception des données brutes
Cette commande récupère du PC local à partir du port 9001 les données par l’utilitaire sflisten.
Pour mieux voir nos données (en décimal et séparé) on à construit une application en java qu’il
récupère ces données, pour cela on a généré deux fichier, le premier est une génération du fichier
XDataMsg.java à partir du fichier header.h à l’aide de l’utilitaire mig comme suite :
mig -o XDataMsg.java -java-classname=XDataMsg java header.h XDataMsg
Le deuxième fichier est recup.java, ce fichier récupère en corporation avec le premier en format
décimale et des données séparées les résultats voulu.
Après la compilation des deux fichiers (javac *.java) on les exécute comme suite : en deuxième onglet
comme précédemment on introduit :
Java recup [email protected]:9001
On obtient les résultats suivants :
83
Figure 4.7: Réception des données formatées en décimal
Figure 4.8: Calcul de l’indice IFM par une autre manière
La figure 4.8 représente une présentation graphique, sous forme d’une courbe, des mesures présentées
dans la figure précédente 4.7. Ces données sont capturées par une application développée sous Windows.
L’indice FWI (IFM) de cette méthode est comparé avec les paramètres d’entrée température et humidité.
Nous constatons que l’indice accompagnant la température augmente par opposition à la valeur de
l’humidité, ce qui est évident (quand la température augmente l’humidité diminue). Le seuil en trait rouge
84
nous indique le niveau extrême (30) de cet indice comparativement à la valeur réel (par exemple IFM=
90,5 Temp.=55.53 Humid.=24.5).
4.4.1.2 Résultat de la simulation
La simulation faite par l’utilitaire « Avrora » nous montre entre plusieurs paramètres à simuler dont le
temps de réponse (temps pour mesurer une capture), l’énergie... comme exemple la simulation de notre
application la réponse de la radio (temps nécessaire pour capter et envoyer la donnée) et temps
d’exécution nécessaire (cycles).
ln -s build/micaz/main.exe main.elf
Cette commande est pour créer un lien symbolique vers l’application (ce fichier est un fichier d’entrée
pour avrora), ensuite :
avrora -seconds=10 -nodecount=1 -monitors=energy main.elf
Simuler avec Avrora pour dix secondes un seul capteur, l’énergie du code source main.elf, le résultat
de simulation sera :
Avrora [Beta 1.7.112] - (c) 2003-2007 UCLA Compilers Group
Loading main.elf...OK
=={ Simulation events }=======================================================
Node
Time
Event
-----------------------------------------------------------------------------===========================================================================
Simulated time: 73728000 cycles
=={ Energy consumption results for node 0 }===================================
Node lifetime: 73728000 cycles,
10.0 seconds
CPU: 0.10060901502001952 Joule
Active: 5.554270616048178E-4 Joule, 180398 cycles
Idle: 0.10005358795841471 Joule, 73547602 cycles
ADC Noise Reduction: 0.0 Joule, 0 cycles
Power Down: 0.0 Joule, 0 cycles
Power Save: 0.0 Joule, 0 cycles
RESERVED 1: 0.0 Joule, 0 cycles
Standby: 0.0 Joule, 0 cycles
Extended Standby: 0.0 Joule, 0 cycles
Yellow: 5.013020833333334E-8 Joule
off: 0.0 Joule, 73727944 cycles
on: 5.013020833333334E-8 Joule, 56 cycles
85
Green: 5.013020833333334E-8 Joule
on: 5.013020833333334E-8 Joule, 56 cycles
Red: 0.03222660815429688 Joule
on: 0.03222660815429688 Joule, 36000051 cycles
Radio: 6.011285496988932E-4 Joule
Power Off:
Power Down:
Idle:
: 6.90673828125E-11 Joule, 8487 cycles
: 5.998719401041667E-4 Joule, 73712264 cycles
: 1.25654052734375E-6 Joule, 7249 cycles
SensorBoard: 0.020999999999999998 Joule
on:
: 0.020999999999999998 Joule, 73728000 cycles
flash: 6.0E-5 Joule
standby: 6.0E-5 Joule, 73728000 cycles
read: 0.0 Joule, 0 cycles
write: 0.0 Joule, 0 cycles
load: 0.0 Joule, 0 cycles
Figure 4.9: Simulation de l’énergie par avrora
Après plusieurs simulations dans le temps on obtient les courbes suivantes :
a.
La cpu
Figure 4.10: Mesure du nombre de cycle de CPU
86
b.
La radio
Figure 4.11: Mesure du nombre de cycle de la radio
Les figures 4.10 et 4.11 représentent le nombre de cycle consommé par la CPU et la Radio
respectivement. Nous constatons que le traitement des données (capture et calcul des formules et des
indices) consomme beaucoup moins de cycle par rapport à la radio. Ceci est du à la nature de la liaison
sans fils et le medium (radio) (présence de retransmissions causées par l’atténuation du signal et/ou les
interférences, etc. …).
4.4.2 La méthode Coréenne
4.4.2.1 Le cas pratique
De la même façon on intègre le code source NesC de l’application coréenne dans le nœud capteur par
la même instruction, et c’est identique pour la réservation du port 9001.
Et pour récupérer ces données on introduit dans un deuxième onglet la même instruction comme le
système canadien et on obtient les données suivantes :
Figure 4.12: Réception des données brutes
87
Cette commande récupère du pc local à partir du port 9001 les données par l’utilitaire sflisten.
Pour mieux voir nos données (en décimal et séparé) on compile les deux fichiers on les exécute
comme et on obtient les résultats suivants :
Figure 4.13: Réception des données formatée en décimal
12.00
10.00
8.00
6.00
4.00
2.00
0.00
humid [%]
lightc [lux]
1
6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
101
106
111
116
121
126
131
Korean Y
Figure 4.14: Calcul de l’indice Coréen par une autre manière
La figure 4.14 présente une illustration graphique, sous forme d’une courbe, des mesures présentées de
la figure 4.13. Ces données sont capturées par une application développée sous Windows. L’indice
Coréen de cette méthode est comparé à l’aide des mesures de l’humidité et de la luminosité. Le seuil de
référence pour cet indice Coréen est inclus dans l’intervalle 10-16. Ainsi, l’indice doit être à l’intérieur de
cet intervalle et toutes autre valeur en d’hors de l’intervalle est rejetée. Pour cela, ce système n’est pas
précis à cause des valeurs en d’hors des seuils min et max.
4.4.2.2 Résultats de simulation
De la même manière, nous lançons la simulation par l’outil avrora de la manière suivante :
88
onaz@ubuntu:~/Desktop/korean$ avrora -seconds=10 -nodecount=1 -monitors=energy
main.elf
Avrora [Beta 1.7.112] - (c) 2003-2007 UCLA Compilers Group
Loading main.elf...OK
=={ Simulation events }==================================================
Node
Time
Event
-----------------------------------------------------------------------------===================================================================
Simulated time: 73728000 cycles
=={ Energy consumption results for node 0 }===================================
Node lifetime: 73728000 cycles,
10.0 seconds
CPU: 0.10120973764672853 Joule
Active: 0.0016316897645263673 Joule, 529959 cycles
Idle: 0.09957804788220216 Joule, 73198041 cycles
ADC Noise Reduction: 0.0 Joule, 0 cycles
Power Down: 0.0 Joule, 0 cycles
Power Save: 0.0 Joule, 0 cycles
Standby: 0.0 Joule, 0 cycles
Extended Standby: 0.0 Joule, 0 cycles
Yellow: 0.0282563359375 Joule
on: 0.0282563359375 Joule, 31564896 cycles
Green: 5.013020833333334E-8 Joule
on: 5.013020833333334E-8 Joule, 56 cycles
Red: 0.03222660994466146 Joule
on: 0.03222660994466146 Joule, 36000053 cycles
Radio: 6.011648310302735E-4 Joule
Power Off:
Power Down:
Idle:
: 7.028808593750001E-11 Joule, 8637 cycles
: 5.998688720703126E-4 Joule, 73711887 cycles
: 1.295888671875E-6 Joule, 7476 cycles
SensorBoard: 0.020999999999999998 Joule
on:
: 0.020999999999999998 Joule, 73728000 cycles
89
flash: 6.0E-5 Joule
standby: 6.0E-5 Joule, 73728000 cycles
read: 0.0 Joule, 0 cycles
write: 0.0 Joule, 0 cycles
load: 0.0 Joule, 0 cycles
Figure 4.15: Simulation de l’énergie
Après plusieurs simulations dans le temps on obtient les courbes suivantes :
a.
La cpu
Figure 4.16: Mesure du nombre de cycle du CPU
b.
La radio
Figure 4.17: Mesure du nombre de cycle de la radio
Les figures 4.16 et 4.17 représentant le nombre de cycle consommé par la cpu et Radio
respectivement, on constate que le traitement des données (capture et calcul des formules) consomme
90
beaucoup moins de cycle par rapport la radio. Ceci est du a la liaison sans fils et le medium (radio)( vu les
retransmissions à cause l’atténuation du signal et les interférences, etc. …).
4.5 Comparaison entre les deux systèmes
Plusieurs points peut-on les citer pour comparer entre les deux systèmes, dont les plus intéressent sont
le temps qui consomme le capteur pour transmettre la radio et le temps consommé par la cpu pour
exécuter le programme et l’énergie consommé par chaque système, et la précision du programme.
Figure 4.18: Méthodologie adoptée pour l’étude comparative
4.5.1 Le temps consommé
4.5.1.1 Par la cpu
On simule ici le temps nécessaire CPU pour l’exécution de chaque programme.
Figure 4.19: Temps consommé par la cpu
91
D’après la courbe de la figure 4.19, le système coréen consomme plus de temps que le système
canadien du point de vu CPU, mais le code source NesC du système canadienne contient beaucoup plus
d’instructions que le système coréen (229 ligne pour le canadien et 171 pour le coréen - dans le fichier
principal).
4.5.1.2 Par la radio
On simule ici le temps nécessaire CPU pour l’exécution de chaque programme, le tableau suivant
représente le nombre de cycles nécessaire consommé par chaque système :
Temps (s)
10
20
30
40
50
60
70
Canadien
73711814
147439814
221167814
294895814
368623814
442351814
516079814
Coréen
73711437
147439437
221167437
294895437
368623437
442351437
516079437
Tableau 4.1: Comparaison entre le temps de réponse des deux systèmes
La différence de 377 cycles (0.000051 seconde) entre les deux systèmes rend le système coréen
meilleur en terme de consommation réduite du temps pour envoyer les paquets, la cause de ce retard pour
le système canadien c’est le nombre de champs (7 champs pour le coréen et 10 pour l’autre), mais par
application du règle de trois, le système canadien dans ce cas devient meilleur.
4.5.2 Evolution de l’énergie consommée (en joules)
4.5.2.1 Par la cpu
Temps
10
20
30
40
50
60
70
Canadien
0,10061012
0,20118675
0,30176338
0,40234002
0,50293663
0,60351326
0,70408989
Coréen
0,10121123
0,20244244
0,30367365
0,4049555
0,50621787
0,60744908
0,70868029
Tableau 4.2: Comparaison entre la consommation d’énergie (CPU) des deux systèmes
Le tableau ci-dessus prouvera que le système coréen consomme plus que le canadien du point du vue
CPU, et plus que le temps de simulation augmente plus la consommation d’énergie du point du vu CPU
augmente pour le système coréenne par rapport au système canadien.
92
4.5.2.2 Par la radio
Temps
10
20
30
40
50
60
70
Canada
0,0006011
0,0012011
0,0018011
0,0024011
0,0030011
0,0036011
0,0042011
Coréen
0,00060112
0,00120112
0,00180112
0,00240112
0,00300112
0,00360112
0,00420112
Tableau 4.3: Comparaison entre la consommation d’énergie (radio) des deux systèmes
La petite différence (2*10-8 joules) entre les deux systèmes rend le système canadien meilleur en
terme de consommation d’énergie pour la transmission radio.
4.5.2.3 Cas général
Figure 4.20: Consommation d’énergie par les deux systèmes
La courbe de la figure 4.20 montre clairement que le système coréen est gourmand en énergie par
rapport à l’autre système. Donc le système canadien est meilleur en terme de consommation d’énergie.
Dans ce cas, d’après les deux premières comparaisons (cpu et radio), une question se pose : A quel niveau
est se situe la différence entres les deux systèmes donc ? La réponse à cette question est que le nœud
capteur contient aussi de la mémoire flash, les leds et les circuits capteurs.
4.5.3 La précision
En comparant les données présentées dans les deux figures précédentes 4.13 et 4.7, nous constatons
que le système canadien plus précis que le système coréen. Ceci est du au fait que dans le premier, tous
93
les résultats obtenus par la capture de température/ humidité nous montrent une valeur de sortie précise
(ffmc, dc, dmc, fwi).Mais, dans le système coréen, les valeurs capturées (en particulier la luminosité) sont
perturbées dans les mêmes conditions, d’où des valeurs de sorties (y) perturbées, (cinq valeurs correctes
par rapport 11 valeurs) soit une précision de 45.45%
4.6 Conclusion
L’étude comparative des deux systèmes nous ramène à choisir clairement le système Canadien et ceci
pour les raisons suivantes :
·
Précision et la conformité de ses données à la réalité.
·
Rapidité.
·
Préféré des services météorologiques.
·
Consommation réduite de l’énergie.
94
Conclusion générale
L’objectif du travail réalisé est présenté dans ce mémoire est double. D’abord, il nous a sensibilisé sur
la gravité du phénomène des feux de forets et ses effets néfastes pour l’environnement climatique et les
populations qui vivent dans les alentours des forets. Ceci a permis aux autorités compétentes et aux
scientifiques de prendre ce phénomène au sérieux en vue de trouver des solutions efficaces, réalisables et
économiques. Ce que nous nous avons essayé de faire dans ce mémoire. En effet, après avoir mis en
cause les techniques de détections employées jusqu’à ce jour d’une manière générale et plus
particulièrement par les services concernés au niveau local (wilaya d’Oran, région ouest du pays), nous
avons opté pour une démarche technologique qui a été testée et déployée avec succès dans certains pays.
Celle-ci est fondée sur l’utilisation des réseaux de capteurs sans fil pour la détection des feux de forets.
Pour l’aspect détection, nous avons pris comme base de travail deux techniques de détection des feux de
forets largement utilisées dans la pratique : méthode Canadienne et méthode Coréenne. Ces deux
méthodes ont été étudiées, dans une certaine mesure adaptées, implémentées à l’aide d’un banc d’essai en
vue de les évaluer d’une manière réaliste qui tient compte de l’environnement réel ambiant.
Ce travail nous a permis aussi d’approfondir nos connaissances sur la technologie des réseaux de
capteurs sans fil et plus particulièrement leur programmation réelle en utilisant des bancs d’essais issus
des récents progrès réalisés dans le domaine de la nanotechnologie. Ce type de réseaux fait l’objet d’une
recherche intensive à l’heure actuelle dans les applications sociétales et industrielles.
A l’issue de ce travail et en se référant aux résultats d’évaluation et de tests obtenus, nous pouvons
conclure d’un part que la technologie des réseaux de capteurs sans fil est intéressante pour la détection
efficace des feux de forets et parfois même pour la prévention contre ces feux. D’autres part, ces résultats
ont révélé l’efficacité et la robustesse de l’approche Canadienne comparativement à l’approche Coréenne,
et son adéquation ainsi que son application dans le contexte local (c.-à-d. la région ouest du pays).
Dans cette conclusion, nous tenons à souligner quelques problèmes que nous avons rencontrés au
cours de la réalisation de travail :
 Absence de documents fiables qui détaillent ou au moins résument les conditions météorologiques
de notre région.
 Absence de toute source crédible sur la méthode Canadienne dans la littérature. Nous étions donc
obligés de contacter directement les services de conservations forestières Canadiennes pour nous
fournir des documents nécessaires sur leur méthode de détection.
95
 Manque considérable dans la littérature d’exemples concrets sur la manipulation et la
programmation des capteurs de type MICA-Z que nous avons utilisés dans notre projet. Ceci nous a
obligés parfois d’effectuer des déplacements au CERIST-Alger pour bénéficier de leur expérience
pratique dans ce domaine.
 Problèmes techniques liés à la récupération des données brutes collectés par les capteurs et leur
conversion en une forme directement exploitable par les outils logiciels employés, surtout le cas de
la grandeur physique luminosité.
Ce travail, à la fois d’intégration et de recherche, a été certes réalisé à l’aide d’un banc d’essai
expérimental très limité (2 nœuds capteurs, 2 nœuds relais et un sink) par rapport à une application réelle
des feux de forets à l’échelle d’une ville par exemple, où le nombre de capteurs nécessaires pour couvrir
toute la forêt est de l’ordre de milliers voir des dizaines de milliers. L’enjeu à notre avis est ce passage à
l’échelle pour pouvoir valider et consolider les résultats obtenus et développer d’autres aspects réseaux
liés essentiellement au routage avec une qualité de service acceptable des alarmes déclenchées suite aux
détections des feux de forets réalisées par les nœuds capteurs. Ces problématiques liées à la scalabilité et
la qualité de service dans un réseau dense de capteurs déployés seront proposés comme travaux de
recherches futures dans ce domaine.
96
Annexe A : TinyOS et NesC
1. Le système d’exploitation TinyOS
1.1 Pourquoi un nouveau OS pour les nœuds capteurs
 Rappel [15] : Caractéristiques des OS classiques
Les OS classiques sont généralement conçus pour un usage générique. Ils sont ainsi conçus en
supposant une disponibilité sans limite des ressources. Leur objectif est la facilité d'usage, la
rapidité et l’efficacité. Parmi leurs caractéristiques, on peut citer:
 Architecture Multi-thread =>Mémoire importante.
 Modèle supporte beaucoup d’E/S.
 Séparation entre espace noyau et utilisateur.
 Pas de contraintes d'énergie.
 Ressources disponibles.
 MAIS les contraintes d'un nœud capteur
Les OS classiques ne sont pas appropriés aux nœuds capteurs, vus que ces derniers sont caractérisés
par :
 Ressources énergétiques basses.
 Mémoire limitée.
 CPU lente.
 Petite taille.
 Parallélisme matériel limité.
 Communication radio : (Bande passante faible ; Portée radio courte).
 Malgré cela, les propriétés de l'OS souhaité pour les nœuds capteurs sont :
 Image mémoire petite.
 Efficacité en calcul et consommation d'énergie.
 La communication est fondamentale.
97
 Temps-réel.
 Construction efficace d'applications.
1.2 Présentation
TinyOS [15] est un système d’exploitation intégré, modulaire, open source destiné aux réseaux de
capteurs sans-fil. Sa conception a été entièrement réalisée en NesC
« langage orienté composant
syntaxiquement proche du C », mais on peut très facilement créer des applications personnalisées en
langages C, NesC, et Java...
Cette plate-forme logicielle ouverte et une série d'outils développés par l'Université de Berkeley est
enrichie par une multitude d'utilisateurs. En effet, TinyOS est le plus OS répandu pour les réseaux de
capteurs sans-fil. Il est utilisé dans les plus grands projets de recherches sur le sujet (plus de 10.000
téléchargements de la nouvelle version). Un grand nombre de ces groupes de recherches ou entreprises
participent activement au développement de cet OS en fournissant de nouveaux modules, de nouvelles
applications,... Cet OS est capable d'intégrer très rapidement les innovations en relation avec l'avancement
des applications et des réseaux eux même tout en minimisant la taille du code source NesCen raison des
problèmes inhérents de mémoire dans les réseaux de capteurs. La librairie TinyOS comprend les
protocoles réseaux, les services de distribution, les drivers pour capteurs et les outils d'acquisition de
données.
1.3 Allocation de la mémoire
TinyOS [Web 06] [33] occupe un espace mémoire très faible puisqu’il ne prend que 300 à 400 octets
dans sa distribution minimale. La gestion de la mémoire possède de plus quelques propriétés. Ainsi, il n’y
a pas d’allocation dynamique de mémoire et pas de pointeurs de fonctions. Bien sur cela simplifie
grandement l’implémentation. Par ailleurs, il n’existe pas de mécanisme de protection de la mémoire sous
TinyOS, ce qui rend le système particulièrement vulnérable aux « crashs » et corruptions de la mémoire.
1.4 L’Ordonnanceur TinyOS
L’ordonnanceur [Web 11] [33] TinyOS est au cœur de la gestion des tâches et des évènements du
système. Le choix d’un ordonnanceur déterminera le fonctionnement global du système et le dotera de
propriétés précises telles que la capacité à fonctionner en évènementiel.
L’ordonnanceur TinyOS comporte deux niveaux de priorité (bas pour les tâches, haut pour les
évènements) et une file d’attente FIFO (disposant d’une capacité de 7 places).
TinyOS s’appuie sur un fonctionnement évènementiel, c'est-à-dire qu’il ne devient actif qu’à
l’apparition de certains évènements, par exemple l’arrivée d’un message radio. Ce fonctionnement
évènementiel (event-driven) s’oppose au fonctionnement dit temporel (time-driven) où les actions du
98
système sont gérées par une horloge donnée. Le reste du temps, le capteur se trouve en état de veille,
garantissant une durée de vie maximale connaissant les faibles ressources énergétiques des capteurs.
1.5 Préemptif
Le caractère préemptif [Web 08] [Web 11] [16] d’un système d’exploitation précise si celui-ci permet
l’interruption d’une tâche en cours. Par ailleurs, entre les tâches, un niveau de priorité est défini
permettant de classer les tâches, tout en respectant la priorité des interruptions (ou évènements). Lors de
l’arrivée d’une nouvelle tâche, celle-ci sera placée dans la file d’attente en fonction de sa priorité (plus
elle est grande, plus le placement est proche de la sortie). Dans le cas ou la file d’attente est pleine, la
tâche dont la priorité est la plus faible est enlevée de la file d’attente FIFO.
1.6 Disponibilité et sources
TinyOS [Web 08] [Web 09] [16] 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.
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, du taux d’humidité…).
2. Le langage de programmation nesC
Le système d’exploitation TinyOS [Web 07] [33] s’appuie sur le langage NesC. Celui-ci propose une
architecture basée sur des composants, permettant de réduire considérablement la taille mémoire du
système et de ses applications.
Chaque composant correspond à un élément matériel (LEDs, timer, ADC …) et peut être réutilisé dans
différentes applications. Ces applications sont des ensembles de composants associés dans un but précis.
Les composants peuvent être des concepts abstraits ou bien des interfaces logicielles aux entrées sorties
matérielles de la cible étudiée (carte ou dispositif électronique).
2.1 Développement
2.1.1 Un composant [15]
- Exécute des Commandes.
- Lance des Events.
- Dispose d'un Frame pour stocker l'état local.
- Utilise la notion de Tasks pour gérer la concurrence.
99
Un Composant implémente des interfaces utilisées par d'autres composants pour communiquer avec
ce composant. NesC permet de déclarer 2 types de fichiers: les modules et les configurations.
2.1.2 Les interfaces
Les interfaces sont des fichiers décrivant les commandes et les évènements proposés par le composant
qui l’implémente. Les interfaces sont bidirectionnelles : Elles spécifient un ensemble de fonctions à
implémenter par les composants fournisseurs de l'interface (commands), et un ensemble à implémenter
par les composants utilisateurs de l'interface (events).
Remarque : command vs. event
Les commandes font typiquement des appels du haut vers le bas (des composants applicatifs vers les
composants plus proches du matériel), alors que les events remontent les signaux du bas vers le haut.
2.1.3 Les modules
Un module est un composant qui implémente une ou plusieurs interfaces et peut utiliser une ou
plusieurs interfaces.
2.1.4 Configurations
Dans nesC, deux composants sont reliés ensemble en les connectant (wiring). Les interfaces du
composant utilisateur sont reliées (wired) aux mêmes interfaces du composant fournisseur. Il existe 3
possibilités de connexion (wiring statements) dans nesC:

endpoint1 = endpoint2

endpoint1 -> endpoint2

endpoint1 <- endpoint2 (équivalent à : endpoint2 -> endpoint1).
Les éléments connectés doivent être compatibles : Interface à interface, "command" à "command",
"event" à "event". Il faut toujours connecter un utilisateur d'une interface à un fournisseur de l'interface.
2.1.5 Tâche et concurrence
Une tâche est un élément de contrôle indépendant défini par une fonction retournant void et sans
arguments:
task void myTask () {...}
Les tâches sont lancées en les préfixant par post:
post myTask ();
2.1.6 Commands vs. Events vs. Tasks
Command :
100
 Ne doit pas être bloquante c.-à-d. prend les paramètres, commence le traitement et retourne dans
l'application.
 Reporte le travail qui consomme du temps en postant une tâche.
 Peut appeler des commandes sur d'autres composants.
Event :
 Peut appeler des commandes, signaler d'autres événements, poster des tâches mais ne peut pas être
signalé par des commandes.
 Peut interrompre une tâche mais pas l'inverse.
Task :

Ordonnancement FIFO.

Non préemptive par une autre tâche, préemptive par un événement.

Utilisée pour réaliser un travail qui nécessite beaucoup de calculs.

Peut être postée par une "command" ou un "event".
2.1.7 l’instruction "atomic"
L'instruction "atomic" garantie que l'exécution de l'instruction se fait comme si aucun autre calcul ne
se fait simultanément. Une instruction "atomic" doit être courte. NesC interdit dans une instruction
atomique: call, signal, goto, return, break, continue, case, default, label.
2.2 Compilation
Les capteurs [33] possèdent en général la même architecture et sont programmables via le langage
NesC. Cependant plusieurs entreprises fabriquent de tels capteurs, ce qui implique quelques différences
qui sont palliées par le compilateur de NesC appelé ncc.
Pour effectuer une compilation, les fichiers doivent se situer dans le même répertoire contenant aussi
un makefile. Le compilateur traite les fichiers nesC en les convertissant en un fichier C étendu. Ce fichier
contiendra l'application et les composants de l'OS utilisés par l'application. Ensuite un compilateur
spécifique à la plateforme cible compile ce fichier C. Il deviendra alors un seul exécutable. Le chargeur
installe le code sur le nœud capteur (Mica2, Telos, etc.).
2.3 Convention de nommage en nesC
o
Extension des fichiers nesC: .nc [15]
o
Clock.nc : soit une interface (ou une configuration)
o
ClockC.nc : une configuration
o
ClockM.nc : un module
101
2.4 Organisation de l’architecture du langage NesC
Module
Configuration
Hérite
Implements
Wires
Composant
Uses
Provides
Interface
Command
events
async
C fonction
Figure 1: Architecture du langage NesC [34]
En résumé vocabulaire
 Application: un ou plusieurs composants reliés ensemble pour former un
exécutable.
 Composant : un élément de base pour former une application nesC. Il
existe deux types de composants: modules et configurations.
 Module : composant qui implémente/utilise une ou plusieurs interfaces.
 Configuration : composant qui relie d'autres composants ensemble.
 Interface : définie d'une manière abstraite les interactions entre deux
composants.
2.5 Mots clé de nesC
Interface
Collection des définitions des event et command
Module
Composants de base implémentés en NesC
Configuration
Composant produit par les autres liés
Implémentation
Contient les codes et les variables pour module ou configuration
Composant
Liste des composants liés à la configuration
Provide
Définies les interfaces implémenté par un composant
Use
Définie les interfaces utilisées par un module ou configuration
as
Alias une interface par un autre nom
Command
Fonction d’appel direct exposé par une interface
event
Retour du message exposé par une interface
102
call
Exécute une commande
Signal
Exécute un événement
post
Mettre une tâche en queue d’exécution
Task
La fonction qui doit être exécuté jusqu’au fond
Includes
Inclure l’entête du fichier
async
Pour commande, l’événement exécuté en asynchronisme
Atomic
Garantie l’exécution atomic d’un état
norace
Eliminer les avertissements des conditions détectés race nesC
Tableau 1: Mots clef du langage NesC [15]
2.6 Différences entre NesC et C, C++ et Java
Les langages C, C++ et Java ont une composition dynamique et ont un espace de noms (namespace)
global. Appeler une fonction requiert d’utiliser un nom qui est unique pour cette fonction dans l’espace de
noms. NesC a un autre objectif. D’abord, le code est divisé en composants, unités discrètes de
fonctionnalités. Un composant peut seulement faire référence à des variables de son propre espace de
noms. D’une certaine manière, les composants NesC sont semblables à des objets. La principale
différence est la portée des appels par référence. Tandis que les objets C++ et Java font référence à des
fonctions et des variables au niveau global, les composants NesC utilisent uniquement un niveau local.
Ceci signifie que non seulement il faut déclarer les fonctions mises en œuvre, mais que de plus un
composant doit déclarer les fonctions qui appellent ces fonctions.
2.7 Exemple
configuration Temperature {
}
implementation {
components Main, TemperatureM, LedsC, Temp,TimerC,GenericComm as Comm;
Main.StdControl ->TemperatureM.StdControl;
Main.StdControl ->TimerC;
Main.StdControl ->Comm;
TemperatureM.Timer ->TimerC.Timer[unique("Timer")];
TemperatureM.Leds ->LedsC;
TemperatureM.TempControl ->Temp.StdControl;
TemperatureM.ADC ->Temp;
TemperatureM.SendMsg ->Comm.SendMsg[65];
TemperatureM.ReceiveMsg ->Comm.ReceiveMsg[65];
}
Figure 2: Extrait du fichier Temperature.nc
Cette application utilise le MTS310 comme carte de capture [33].
103
module TemperatureM
{
provides {
interface StdControl;
}
uses {
interface Timer;
interface Leds;
interface StdControl as TempControl;
interface SendMsg;
interface ADC;
interface ReceiveMsg;
}
}
implementation {
...//code des redéfinitions des interfaces
}
Figure 3: Extrait du fichier TemperatureM.nc
L’utilisation des mots clefs « Use » et « Provide » au début d’un composant permet de savoir
respectivement si celui-ci fait appel à une fonction de l’interface ou redéfini son code.
104
Annexe B : Indices de la méthode canadienne
Annexe B : indices de la méthode canadienne
1. Symboles utilisés dans les équations
Toutes les grandeurs utilisées dans les équations numérotées sont représentées dans la liste qui suit par
des lettres uniques, quelquefois accompagnées d'un indice. Les symboles sont regroupes suivant leur
place dans l'ensemble. Toutes les teneurs en eau sont des pourcentages calculés en fonction de la masse
sèche. Midi est l’heure normale.
a. Météo
b.
T
Température à midi
H
Humidité relative à midi, %
W
Vitesses du vint a midi, Km/h
r0
Précipitation mesurée tous les jours à midi dans un endroit dégagé, mm d'eau
rf
Précipitation réelle, ICL
re
Précipitation réelle, 1H
rd
Précipitation réelle, IS
Indice du combustible léger (ICL)
m0
Teneur en eau du combustible léger le jour précédent
mr
Teneur en eau du combustible léger après la pluie
m
Teneur en eau du combustible léger après dessèchement
Ed
TEE du combustible léger pour le dessèchement
Ew
TEE du combustible léger pour le mouillage
k0
Valeur intermédiaire dans le calcul de kd
kd
Vitesse de dessèchement logarithmique, ICL, log10m/jour
k1
Valeur intermédiaire dans le calcul de kw
kw
Vitesse de mouillage logarithmique, log10m/jour
F0
ICL de la veille
F
ICL
c. Indice de l'humus (IH)
M0
Teneur en eau de l'humus le jour précédent
Mr
Teneur en eau de l'humus après la pluie
M
Teneur en eau de l'humus après le dessèchement
105
K
Vitesse de dessèchement logarithmique, IH, log10m/jour
Le
Longueur réelle de la journée dans IH, heures
b
Facteur pente dans l'effet de la pluie sur IH
P0
IH de la veille
Pr
IH après la pluie
P
IH
d. Indice de sécheresse (IS)
Q
Humidité équivalente de l’IS, multiples de 0,254 mm
Q0
Humidité équivalente de l'IS de la veille
Qr
Humidité équivalente après la pluie
v
Evapotranspiration potentielle, multiples de 0,254 mm d'eau par jour
Lf
Coefficient de la longueur du jour dans IS
D0
IS de la veille
Dr
IS après la pluie
D
IS
e. Indice de comportement de l'incendie (IPI, ICD, IFM)
2.
f(W)
Facteur vent
t(F)
Facteur humidité du combustible léger
f(D)
Facteur humidité de l'humus
R
Indice de propagation initiale (IPI)
U
Indice du combustible disponible (ICD)
B
IFM (forme intermédiaire)
S
IFM (forme finale)
Equations et méthodes de calcul
a. Indice du combustible léger (ICL)
𝑚0 = 147,2 (101 − 𝐹0 )/(59,5 + 𝐹0 )
3.1
𝑟𝑓 = 𝑟0 − 05𝑟0 > 0,5
3.2
−10 0
𝑚𝑟 = 𝑚0 + 42.5 𝑟𝑓 𝑒 251 −𝑚 0
−100
1−𝑒
𝑚𝑟 = 𝑚0 + 42.5 𝑟𝑓 𝑒 251 −𝑚 0
−6.93
𝑟𝑓
1−𝑒
𝑚0 ≤ 150
−6.93
𝑟𝑓
3.3.a
+ 0.0015 (𝑚0 − 150)2 𝑟𝑓0.5 𝑚0 > 150
𝐸𝑑 = 0,942 𝐻 0.679 + 11𝑒 (𝐻−100)/10 + 0,18 21,1 − 𝑇 1 − 𝑒 −0.115𝐻
106
3.3. 𝑏
3.4
𝐸𝑤 = 0,618𝐻 0.753 + 10𝑒
𝐻
𝑘0 = 0,424 1 –
100
𝐻 −100
10
+ 0,18 21,1 − 𝑇 1 − 𝑒 −0.115𝐻
1.7
+ 0,0694 𝑤
0.5
𝐻
1–
100
8
𝑘𝑑 = 𝑘0 × 0,581 𝑒 0.0365𝑇
100 − 𝐻
𝑘1 = 0,424 [1 −
100
3.5
3.6. 𝑎
3.6. 𝑏
1.7
] + 0,0694 𝑤
0.5
100 − 𝐻 8
[1 −
]
100
𝑘𝑤 = 𝑘1 × 0,581 𝑒 0.0365𝑇
3.7. 𝑎
3.7. 𝑏
𝑚 = 𝐸𝑑 + 𝑚0 − 𝐸𝑑 × 10−𝑘 𝑑
3.8
𝑚 = 𝐸𝑤 − 𝐸𝑤 − 𝑚0 × 10−𝑘 𝑤
3.9
250 − 𝑚
147,2 + 𝑚
3.10
𝐹 = 59,5
L’ICL se calcule de la façon suivante:
1.
F de la veille devient F0.
2.
Calculer m0en fonction de F0à l'aide de l'équation 3.1
3.
a. Si r0> 0.5, calculer rf à l'aide de l'équation 3.2
b. Calculer mr en fonction de rf et m0à l'aide de l'équation 3.3.a ou 3.3.b
(i) Si m0≤ 150, utiliser l'équation 3.3.a
(ii) Si m0 > 150, utiliser l'équation 3.3.b
c. mr devient alors le nouveau m
4.
Calculer Ed à l'aide de l'équation 3.4
5.
a. Si m0>Ed, calculer kd à l'aide des équations 3.6.a et 3.6.b
b. Calculer m à l'aide de l'équation 3.8
6.
si m0<Ed, calculer Ew à l'aide de l'équation 3.5
7.
a. Si m0<Ew calculer kw à l'aide des équations 3.7.a et 3.7.b
b. Calculer m à l'aide de l'équation 3.9
8.
Si Ed ≥ m0≥ Ew prendre m = m0.
9.
Calculer F en fonction de m à l'aide de l'équation 3.10, On obtient l'ICL de la journée.
L'utilisation de ces équations comporte deux restrictions:
 L'équation 3.3 (a ou b) ne s'applique pas lorsque r0≤ 0,5 mm; cela signifie que, par temps sec, le
sous-programme précipitation doit être omis.
 m a une limite supérieure de 250; cela signifie que lorsque l'équation 3.3 (a ou b) donne mr> 250, il
faut prendre mr = 250.
107
b. Indice de l'humus (IH)
𝑟𝑒 = 0,92 𝑟0 − 1,27
𝑟0 > 1,5
3.11
𝑃0
𝑀0 = 20 + 𝑒 (5.6348−43 .43 )
3.12
𝑏 =
100
𝑃 ≤ 33
0,5 + 0,3 𝑃0 0
3.13. 𝑎
𝑏 = 14 − 1,3𝑙𝑛𝑃0
33 < 𝑃0 ≤ 65
3.13. 𝑏
𝑏 = 6,2 𝐼𝑛𝑃0 − 17,2
𝑃0 > 65
3.13. 𝑐
𝑀𝑟 = 𝑀0 + 1000
𝑟𝑒
48,77 + 𝑏𝑟𝑒
3.14
𝑃𝑟 = 244,72 − 43,43 𝐼𝑛 𝑀𝑟 − 20
3.15
𝐾 = 1.894 𝑇 + 1,1 100 − 𝐻 𝐿𝑒 × 10−6
3.16
𝑃 = 𝑃0 𝑜𝑢𝑃𝑟 + 100𝑘
3.17
L'IH se calcule de la façon suivante:
1. P de la veille devient𝑃0 .
2. a. Si r0> 1,5 calculer re à l'aide de l'équation 3.11
b. Calculer M0en fonction de 𝑃0 à l'aide de l'équation 3.12
c. Calculer b à l'aide de l'équation appropriée parmi. 3.13.a, 3.13.b ou 3.13.c.
d. Calculer Mr à l'aide de l'équation 3.14.
e. Calculer 𝑃𝑟 en fonction de Mr à l'aide de l'équation 3.15. 𝑃𝑟 devient le nouveau 𝑃0
3. Prendre Ledans le tableau 3.1 ci-dessous.
4. Calculer k à l'aide de l'équation 3.16.
5. Calculer P en fonction de 𝑃0 (ou𝑃𝑟 ) et l'aide de l'équation 3.17. C'est l'IH de la journée
L'utilisation des équations donnant IH comporte trois restrictions:
 Les équations 3.11 à 3.15 ne s'appliquent pas à moins que r0>1,5; cela signifie qu'il faut omettre le
sous-programme précipitation par temps sec.
 Théoriquement, 𝑃𝑟 ne peut pas être inférieur à zéro. Si on obtient des valeurs négatives à l'étape 2e,
il faut prendre zéro.
 On ne doit pas utiliser des valeurs de T inférieures a - 1,1 dans l'équation 3.16. Si T < - 1,1, il faut
prendre T = -1,1.
Mois Janv. Févr. Mars Avr Mai Juin Juil. Août Sept Oct. Nov. Déc.
Le=
6,5
7,5
9,0 12,8 13,9 13,9 12,4 10,9 9,4 8,0
7,0
6,0
Tableau B.1: Longueur réelle de la journée (Le) pour le calcul de l’IH
108
c. Indice de sécheresse (IS)
𝑟𝑑 = 0,83𝑟0 − 1,27
𝑟 > 2,8
3.18
𝑄0 = 800𝑒 −𝐷0 /400
3.19
𝑄𝑟 = 𝑄0 + 3.937𝑟𝑑
3.20
𝐷𝑟 = 400 ln
800
𝑄𝑟
3.21
𝑉 = 0,36 𝑇 + 2,8 + 𝐿𝑓
3.22
𝐷 = 𝐷0 𝑜𝑢𝐷𝑟 + 0,5𝑉
3.23
IS se calcule de la façon suivante:
1.
D de la veille devient D0.
2.
b. Si r0>2,8, calculer rd a l'aide de l'équation 3.18
c. Si Calculer Q0en fonction de D0à l'aide de l'équation 3.19
d. Calculer Qr à l'aide de l'équation 3.20
e. Calculer Dr en fonction de Qr à l'aide de l'équation 3.21. Dr devient le nouveau D0
3.
Prendre Lf dans le tableau 3.2 ci-dessous
4.
Calculer V à l'aide de l'équation 3.22
5.
Calculer D en fonction de D0(ou Dr) à l'aide de l'équation 3.23. C’est l'IS de la journée
L'utilisation des équations donnant IS comporte quatre restrictions :
 Les équations 3.18 à 3.21 ne s'appliquent pas à moins que r0>2,8; cela signifie qu'on doit omettre le
sous-programme précipitation par temps sec.
 Théoriquement, Dr ne peut être inférieur à zéro. Si on obtient des valeurs négatives à l'étape 2d, il
faut prendre zéro.
 On ne doit pas utiliser des valeurs de T inférieures a -2.8, dans l'équation 3.22. Si T < -2,8, prendre
T = -2,8.
 V ne peut pas être négatif. Si l'équation 3.22 donne un résultat négatif, prendre V = 0.
Mois: Janv. Févr. Mars Avr. Mai Juin Juil. Août Sept. Oct. Nov. Déc.
Lf: -1,6 -1,6 -1,6 0,9 3.8 5.8 6.4 5,0 2,4 0,4 -1,6 -1,6
Tableau B.2: Coefficient de la longueur de la journée (Lf) pour le calcul de l’IS
d.
Indice de propagation initiale (IPI)
𝑓 𝑊 = 𝑒 0.05039𝑊
3.24
109
5.31
e.
𝑓 𝐹 = 91,9 𝑒 −0.1386𝑚 1 + 𝑚4.93 ×10 7
3.25
𝑅 = 0,208 𝑓 𝑊 𝑓 𝐹
3.26
Indice du combustible disponible (ICD)
𝑈 = 0,8
𝑈 = 𝑃− 1−
f.
𝑃𝐷
𝑃 ≤ 0,4𝐷
𝑃 + 0,4𝐷
0,8𝐷
0,92 + 0,0114𝑃
𝑃 + 𝑂, 4𝐷
3.27. 𝑎
1.7
𝑃 > 0,4𝐷
3.27. 𝑏
Indice Forêt-Météo (IFM)
𝑓 𝐷 = 0,626𝑈0. 809 + 2
𝑓 𝐷
𝑈 ≤ 80
1000
𝑈 > 80
25 + 108.64 𝑒 −0.023𝑈
3.28. 𝑎
3.28. 𝑏
𝐵 = 0,1 𝑅𝑓 𝐷
3.29
𝑙𝑛𝑆 = 2,72 (0,434 𝑙𝑛𝐵)0.647 𝐵 > 1 3.30. 𝑎
S = B,
B ≤1
3.30.b
IPI, ICD et IFM se calculent de la façon suivante :
1. Calculer f(W) et f(F) à l'aide des équations 3.24 et 3.25
2. Calculer R à l'aide de l'équation 3.26. C'est l'IPI de la journée
3. Calculer U à l'aide de l'équation 3.27.a Si P ≤ 0.4D ou à l'aide de l'équation 3.27.b Si P > 0,4D.
C'est l'ICD de la journée
4. Calculer f(D) à l'aide de l'équation 3.28.a Si U ≤ 80. Si U > 80, utiliser l'équation 3.28.b
5. Calculer B à partir de l'équation 3.29
6. Si B > 1, calculer S d'après son logarithme donné par l'équation 3.30.a. Si B ≤ 1, prendre S = B
selon l'équation 3.30.b. S est l'IFM de la journée.
110
Bibliographie
Bibliographie
[01]
B. Son, Y. Her, J. Kim, “RCSF_Forest_Fire_KOREA_2006: A Design and Implementation of
Forest-Fires Surveillance System based on Wireless Sensor Networks for South Korea
Mountains”. IJCSNS International Journal of Computer Science and Network Security, VOL.6
No.9B, September 2006.
[02]
Majid Bahrepour, Nirvana Meratnia, Paul Havinga, “AUTOMATIC FIRE DETECTION: A
SURVEY FROM WIRELESS SENSOR NETWORK PERSPECTIVE”, Pervasive Systems Group,
University of Twente :( date d’accès janvier 2012)
doc.utwente.nl/65223/1/Automatic_Fire_Detection.pdf
[03]
David M. Doolin et Nicholas Sitar, “Wireless sensors for wildfire monitoring”. University of
California, Berkeley, CA 94720 USA.
[04]
Nükhet SAZAK, Haldun ABDULLAH, “THE IMPORTANCE OF USING WIRELESS SENSOR
NETWORKS FOR FOREST FIRE SENSING AND DETECTION IN TURKEY”. 5th International
Advanced Technologies Symposium 2009, Karabuk, Turkey.
[05]
Luis Bernardo et Rodolfo Oliveira et Ricardo Tiago, and Paulo Pinto, “A FIRE MONITORING
APPLICATION FOR SCATTERED WIRELESS SENSOR NETWORKS ( A peer-to-peer crosslayering approach)” Faculdade de Ciencias e Tecnologia, Universidade Nova de Lisboa, P-2829516 Caparica, Portugal.
[06]
Imad H. Elhajj, George Mitri, «Remote Sensing for Forest Fire Prediction and
Detection » ,7èmes Journées géographiques Télédétection, Statistiques, et Sciences Sociales:
Beirut 2009.
[07]
B.Kechar, “Economie d'énergie dans les réseaux de capteurs sans fil: Economie d'énergie dans
les réseaux de capteurs sans fil en exploitant la redondance dans ces différentes formes",
Editions universitaires européennes, ISBN-13: 978-6131574351, 204 pages, 21 novembre 2011.
[08]
B.Kechar, L.Sekhri, “Formal modelling, Validation and Performance Evaluation of An Energy
Efficient and Low Latency Cross-layer MAC Protocol for Delay Sensitive Wireless Sensor
Network Applications”, accepted for publishing in the book "Petri Nets", ISBN 978-953-7619-XX. 2009. (date d’accès novembre 2011)
http://intechweb.org/invitations.php?code=7883c9894aa1997a8e5c0aa66fec7186
[09]
B.Kechar, Z.Bidai, “Energy Efficient Data Compression technique for Wireless Sensor Networks
in Tolerant End-to-End Delay Monitoring Applications”, Communications of the Arab Computer
Society Journal, Vol.3, No2. ISSN: 1090-102x, 2010.
[10]
B.KECHAR, « Problématique de la consommation d’énergie dans les réseaux de capteurs sans
fil ». Thèse de Doctorat d’état en Informatique, Université d’Oran, Juin (2010).
111
Bibliographie
[10]
B.Kechar, L.Sekhri, M.K.Rahmouni, "CL-MAC: Energy Efficient and Low Latency Cross-layer
MAC Protocol for Delay Sensitive Wireless Sensor Network Applications”, The Mediterranean
Journal of Computers and Networks, Vol.6, N°1, pp. 1-14 (Print ISSN: 1744-2397), January
2010.( date d’accès avril 2012)
Abstract accessible via ce lien: http://www.medjcn.com/papers%20archive/index.html
[12]
S. Megerian, M. Potkonjak, “Wireless Sensor Networks”, John Wiley & Sons, pp. 2990-2996,
2003
[13]
Willig, “Wireless sensor networks: concept, challenges and approaches”, Springer-Verlag,
pp.224-231, 2006.
[14]
M. Wang, J. Cao, J. Li, S. K. Das, “Middleware for Wireless Sensor Networks: A Survey”,
Journal of Computer Science and Technology, Vol. 23, No. 3, pp. 305-326, May 2008.
[15]
Y. hallal, « Réseaux de Capteurs Sans Fils » Support du cours (2008). accès net :
http://tice.utc.fr/moodle/file.php/498/support-SIT60.pdf(date d’accès janvier 2012)
[16]
H. Jmel – M. Caudron - A. Brisset – P.M. Guitard, « Réseaux de Capteurs Sans Fils: Projet
Avancé SE »,Sujet 3ème année électroniques : (date d’accès janvier 2012)
uuu.enseirb.fr/~kadionik/se/projets_avances/0708/rapport_sujet3_E3_0708.pdf
[17]
Rapport des incendies des forêts à partir du service de conservation des forêts, Bilan Général des
incendies de la wilaya d'ORAN 2009.
[18]
Grace, Asplund, Ely, Intorf, Droeg, “The Osborne Fire finder the basic lookout tools: Firemans
Guide California Region”.U.S. Department of Agriculture Forest Service, 1955:
www.socalfirelookouts.org/Osborne%20Fire-finderUsersGuide.pdf. (date d’accès janvier 2012)
[19]
T. A Santoni, J.F.Santucci, E. de Gentili, X. Silvani, F. Morandini, “Performance of a Protected
Wireless Sensor Network in a Fire:Analysis of Fire Spread and Data Transmission”. University
of Corsica/UMR CNRS SPE, Quartier Grossetti 20250 Corte, France: (date d’accès janvier 2012)
www.mdpi.com/1424-8220/9/8/5878/pdf.
[20]
CRAIG L, BEYLER, Ph D, “A Design Method for Flaming Fire Detection”: Centre for Fire
Safety Studies Worcester Polytechnic Institute.
[21]
Documentation envoyé par le service météorologique du canada.
[22]
MPR-MIB Users Manual: (date d’accès janvier 2010)
www.cs.ucsb.edu/~nchohan/docs/MoteManual.pdf
[23]
R. VAISH,: “APPLICATION OF WIRELESS SENSOR NETWORKS FOR ENVIRONMENTAL
MONITORING AND DEVELOPMENT OF AN ENERGY EFFICIENT CLUSTER BASED
ROUTING”. Master of Technology In Electrical Engineering.(Rourkela 2009):
hal.archives-ouvertes.fr/docs/00/44/39/61/PDF/newthesis.pdf(date d’accès janvier 2011)
112
Bibliographie
[24]
S. Jose, California, “MicaZ WIRELESS MEASUREMENT SYSTEM”.(date d’accès janvier 2010)
www.openautomation.net/uploadsproductos/micaz_datasheet.pdf.
[25]
K. Heurtefeux, « PROTOCOLESLOCALISÉS POUR RÉSEAUX DE CAPTEURS ». Doctorat
d’école doctorale Informatique et Mathématiques de Lyon (2009) : (date d’accès janvier 2012)
eavr.u-strasbg.fr/~loic/these.pdf.
[26]
J.A.R. Azevedo “Systems of Last Generation for the Observation, Prediction and Active
Monitoring of Forest Natural Spaces in the Macaronesia”: Program of Communitarian Initiative
INTERREG III B “Espaço the Açores-Madeira-Canary Islands” University of Madrid:
dme.uma.pt/people/faculty/amandio.azevedo/ForesmacUMa.pdf. (date d’accès janvier 2011)
[27]
partie du code source NesC qui définie les formules de MTS400 (logiciel tinyos 1.x).
[28]
MTS420/400: ENVIRONMENTAL SENSOR BOARD: (date d’accès janvier 2010)
bullseye.xbow.com:81/Products/product_pdf_files/wireless_pdf/MTS400-420_Datasheet.pdf.
[29]
XServe Users Manual: (date d’accès janvier 2010)
ftp://ftp.dcsl-uhcl.net/private/Research/Crossbow/XServe_Users_Manual_7430-0111-01_B.pdf.
[30]
MoteView Users Manual: (date d’accès mai 2010)
http://archive.cone.informatik.uni-freiburg.de/teaching/praktikum/Adhocnetworksw07/RCSF/mica2-cd/Manuals%20and%20Docs/MoteView_Users_Manual_7430-000804_C.pdf.
[31]
MoteConfig User’s Manual: (date d’accès mai 2010)
http://cone.informatik.uni-freiburg.de/teaching/labcourse/Adhocnetworks-w07/RCSF/mica2cd/Manuals%20and%20Docs/MoteConfig_Users_Manual_7430-0112-01_A.pdf.
[32]
Ludovic SAMPER, « Modélisations et Analyses de Réseaux de Capteurs ». Thèse de doctorat en
informatique de l’institut national polytechnique de GRENOBLE avril 2008.
[33]
M. Badet, W. Bonneau, « Mise en place d’une plateforme de test et d’expérimentation », Master
Technologie de l’Internet 1ère année (2005-2006) :
http://web.univ-pau.fr/~belloir/DOC/BadetBonneauRapportTER.pdf (date dernier accès: Janvier
2012)
[34]
B. Mathieu, V. Mathieu, « TinyOS et Zigbee : OS pour réseaux de capteurs ». (date d’accès mai
2010)
www-master.ufr-info-p6.jussieu.fr/2005/IMG/pdf/presentation-ZigBeeTinyOS.pdf
113
Webographie
Webographie
[Web 01]
http://www.planetoscope.com/
[Web 02]
http://www.lce-algerie.com/
[Web 03]
http://www.elmoudjahid.com/
[Web 04]
http://www.mdpi.com.
[Web 05]
http://www. Xbow.com.
[Web 06]
http://www.tinyos.net.
[Web 07]
https://www.millennium.berkeley.edu/
[Web 08]
http://tinyos.stanford.edu
[Web 09]
http://www.cs.utah.edu/~regehr/tinyos-tools-wg/
[Web 10]
http://www.hurray.isep.ipp.pt/activities/ZigBee_WG/
[Web 11]
http://fr.wikipedia.org/wiki/TinyOS
[Web 12]
http://www.techno-science.net/
[Web13]
http://www.atmel.com/
[Web14]
http://www.libelium.com/waspmote
[Web15]
http://www.btnode.ethz.ch/
[Web 16]
http://fr.ekopedia.org/
114
Résumé :
La Simulation est une étape intermédiaire pour valider un certain scénario ou valider une théorie,
mais l’implémentation réelle est une étape finale pour valider notre projet qui permet de concevoir un
système de détection des feux de forêt par un réseau de capteurs sans fil, la conception de ce système
est issue de l’étude des deux systèmes de détection canadienne et coréenne, ensuite adapter la
méthode canadienne (climat similaire) pour le contexte locale, ensuite nous avons programmer cette
méthode sous un langage de programmation NesC et un OS TinyOs, enfin comparer les résultats
issus des deux systèmes pour donner des recommandations.
Mots clés :
Réseau de capteurs sans fil; Simulation; Implémentation; Conception; NesC; TinyOs; Feux de forêts;
Climat; Adapter.

DEPARTEMENT D`INFORMATIQUE MEMOIRE Présenté par

Transcription

Documents pareils

AFH-G P?A2 - KOBOLD Messring GmbH

Les capteurs plans

TELECOMMANDE SANS FIL 6in1

Télécharger | 1.72 MB - ES Equipements Scientifiques

les capteurs ccd/cmos

Modifier l`avance à l`allumage

Tutorial 1.2. Moduler un paramètre avec un contrôleur

olutions - Mesures

Découvrez tous les textes poétiques et le tableau dans le