Applications Des Réseaux de Capteurs Intelligents Et de La Communication Sans Fil À L'instrumentation Des Structures de Génie Civil
Applications Des Réseaux de Capteurs Intelligents Et de La Communication Sans Fil À L'instrumentation Des Structures de Génie Civil
Applications Des Réseaux de Capteurs Intelligents Et de La Communication Sans Fil À L'instrumentation Des Structures de Génie Civil
Aussi les secteurs du génie civil constituent-ils autant de cibles potentielles pour des réseaux de
capteurs sans-fil. Le Réseau scientifique et technique du ministère en charge des transports en géné-
ral et la Division Métrologie et Instrumentation du LCPC en particulier se sont donc naturellement
appliqués ces quatre dernières années à acquérir ces technologies et développer les compétences
associées afin de les décliner dans les applications faisant appel à de l’instrumentation. Le but de
cet article est de faire découvrir ces technologies [4] et leurs potentialités, de mettre en évidence les
nouveaux défis de ces transmissions sans support filaire [2], puis de présenter à l’aide de quelques
exemples les premières réalisations concrètes du LCPC en la matière.
Définitions
–– une (ou plusieurs) voie de mesure, à laquelle est connecté un élément sensible à une grandeur physi-
que à mesurer ; un accéléromètre, une jauge, un thermocouple, un MEMS [5] en sont des exemples ;
–– pour chaque voie de mesure, un étage qui met en forme l’information analogique (électrique, opti-
que, mécanique) du senseur et la convertit en une information numérique (octets, niveaux logiques) ;
–– un processeur dont la fonction minimale est d’acquérir les données issues de chaque voie de
mesure ; ce processeur a une capacité d’intégrer et d’exécuter des algorithmes métier, voire d’hé-
berger un système d’exploitation ; ce peut être, selon le cas, un simple microcontrôleur 8 bits ou un
processeur dédié au traitement de signal tel un Digital Signal Processor (DSP) ; dans certains cas, le
processeur assure également une gestion évoluée de l’énergie électrique dont dispose le capteur ;
–– éventuellement une capacité de mémorisation externe au processeur lorsque sa mémoire interne
ne suffit pas à répondre au besoin de stockage des données et des programmes ; les mémoires RAM
ou FLASH en sont des exemples ;
–– un étage de communication permettant au processeur de dialoguer avec le système de supervision,
voire avec d’autres capteurs ; cette communication peut être filaire (liaison série point à point de type
RS232, Bus série de type RS485, Ethernet ; etc.) ou sans-fil (Wifi, Zigbee, Bluetooth, ISM, etc.).
La figure 1 représente le synoptique d’un capteur sans-fil complet possédant 2 voies de mesure et
les liens entre les différents étages qui le composent.
–– exécuter des algorithmes plus ou moins complexes sur les données relevées comme calculer des
minimums et maximums, filtrer, moyenner, calculer des transformées de Fourier, des corrélations
intervoies, etc.
–– réagir dynamiquement à des ordres reçus du superviseur comme (dés)activer une voie, modifier un
seuil, ajouter un autre type de traitement sur les données, communiquer avec un autre capteur, etc.
–– réagir à des dysfonctionnements de son environnement comme une voie qui ne répond plus, un
seuil atteint de façon intempestive qui désactive en permanence la mesure, un lien de communica-
tion défaillant, etc.
–– s’auto-identifier, s’autolocaliser, s’autoreconfigurer, s’autoréparer, etc.
Même s’il est clair qu’un capteur ne possède que l’intelligence qu’on lui a assignée, une nouvelle
forme de structuration de cette intelligence émerge dans le domaine des systèmes embarqués et
notamment des capteurs sans-fil du fait de l’hébergement par le capteur d’un système d’exploita-
tion tels Windows ou Linux dans le monde bureautique, ou encore Operating System (OS). Un OS
offre au concepteur une exploitation simplifiée des capacités du processeur et de ses périphériques,
et permet surtout à l’utilisateur final de reconfigurer totalement le capteur sans avoir à le manipu-
ler ni le reprogrammer en laboratoire. En outre, le capteur intégrant un OS peut être totalement
reconfiguré à chaud et à distance, ce qui contribue fortement à diminuer les coûts de maintenance
et d’exploitation du système.
Les capteurs intelligents, tout particulièrement ceux intégrant un OS, disposent sensiblement des
mêmes capacités qu’un ordinateur classique muni de cartes d’acquisition (sans écran, clavier ni
souris). Plus l’intelligence embarquée est élevée, plus il y a d’électronique dans le capteur comme
l’illustre la figure 2. Si l’on se rapproche d’une configuration de type réseau d’ordinateurs, les cap-
figure 2
Quelques capteurs
intelligents intégrant des
OS (TinyOs et μCLinux)
utilisés par le LCPC.
Le développement des capteurs intelligents et des capteurs sans-fil répond tout naturellement à ce
besoin en étendant à l’infini le champ des topologies possibles. En effet, la déconnexion physique
inhérente au sans-fil permet a priori à chaque capteur de communiquer avec tout autre capteur
présent dans sa sphère d’influence radio. Par ailleurs, un capteur intelligent est systématiquement
un capteur identifié ou identifiable, de sorte que, si l’on associe les données captées à la source à
l’identifiant du capteur, les octets peuvent transiter par n’importe quel chemin du réseau sans que
les données perdent la mémoire de leur origine.
La figure 3 donne quatre exemples de topologies de réseaux de capteurs. Les deux topologies les
plus répandues sont les topologies en étoile et en bus, dans lesquelles chaque nœud ne connaît que
le superviseur et où les chemins de communications nœud-superviseur sont uniques et physique-
ment figés.
figure 3
Quatre exemples de
topologies de réseaux de
capteurs.
figure 4
Le protocole TCP/IP
a : OSI modélisant le
TCP/IP
b : deux modules
électroniques implémentant
l’IP, respectivement en Wifi
et en Éthernet.
a b
• Selon que l’on accepte ou non de perdre des données, on choisira une protocole plus ou moins
fiable et un protocole connecté ou non.
• Selon la capacité énergétique du capteur, on choisira un protocole plus ou moins consommateur
de ressources.
• Selon la gamme des distances entre capteurs, on choisira un protocole incluant le multi-saut, la
possibilité de relais, etc.
• Selon la topologie souhaitée pour les nœuds, on choisira un protocole permettant le multi-saut, la
communication entre capteurs, la connexion du nombre souhaité de capteurs.
• Selon le temps de latence accepté pour la communication, le débit visé, la présence d’échanges à
durée déterministe, on choisira un protocole à haut débit, un protocole déterministe.
Par ailleurs, les systèmes d’exploitation embarqués prennent toujours en charge de façon native un
standard de communication ; en effet, l’intérêt de ces OS issus du monde bureautique est offrir un
mode de communication de base, en plus d’ajouter une couche d’abstraction logicielle entre les
ressources électroniques du capteur et l’application métier (étage de conditionnement, divers ports
d’entrée/sortie, etc.). Citons, à titre d’exemple, les OS embarqués μCLinux ou Windows CE qui
proposent nativement le protocole TCP/IP ou TinyOS offrant le 802.15.4 (couche basse du Zigbee,
autre protocole sans-fil).
Aussi dans le domaine du sans-fil, le concepteur électronique doit-il tenir compte du fait que mesu-
rer correctement la grandeur physique que l’on désire connaître revêt la même importance que
maîtriser la consommation énergétique.
Il n’y a aucun schéma ni solution unique et générique couvrant tous les besoins possibles. Néanmoins
le concepteur cherchera toujours à choisir les composants électroniques les plus sobres et son choix
devra être dicté, entre autres, par les considérations suivantes.
• Si l’instrumentation est prévue pour une courte durée (quelques heures à quelques jours) : les tech-
nologies actuelles des batteries permettent de pallier presque toutes les situations, y compris celles
des communications radio en continu (batteries au plomb et NiMh), tout en restant de dimensions
raisonnables (quelques cm3).
• Si l’instrumentation ne nécessite pas de communications ou de mesures fréquentes : le processeur
peut véritablement optimiser la consommation en n’activant les modules d’acquisition/condition-
nement et de communication radio qu’aux seuls moments nécessaires. De plus, de nombreuses
familles de processeurs proposent des modes de veille permettant à ceux-ci de ne presque rien
consommer. Les sorties des états de veille peuvent être paramétrées sur événement, sur dépasse-
ment de seuil, à un moment précis, etc. Par exemple, la mesure et la transmission de la température
ou d’une déformation ne nécessitent pas de capteur sans-fil fonctionnant à 100 % de leur capacités
durant 100 % du temps. Ainsi, si l’on fait le choix de batteries, à condition d’avoir la place de les
intégrer, le capteur peut tenir des mois, voire des années selon la dynamique de l’application.
• Si l’instrumentation est prévue pour durer très longtemps et/ou nécessite des communications
radio fréquentes, les solutions sont plus délicates à trouver. Il faut viser la sobriété extrême de la
carte constituant le capteur, minimiser le nombre de composants électroniques, employer tous les
modes de veille possibles, optimiser les rapports cycliques des phases d’écoute ou de commu-
nication sur le réseau, utiliser les protocoles réseau dédiés aux basses consommations (Zigbee,
BlueTooth) en étudiant, dans ce cas, les possibilités d’employer des répéteurs intermédiaires et de
Plus généralement, la meilleure façon d’économiser de l’énergie consiste à limiter la durée des
communications et leur nombre. Les capteurs intelligents peuvent répondre à ce besoin. On privi-
légiera tout système pouvant exécuter les traitements du signal et de ses divers algorithmes au plus
près de la source, c’est-à-dire capables de traiter les données mesurées au niveau des capteurs. C’est
au niveau de chaque capteur que se décidera quelles données transmettre et à quelle cadence. En
effet, sauf si les données doivent faire l’objet d’une interprétation globale en temps réel, chaque
capteur peut mémoriser ses propres données, éventuellement les traiter en partie, et ne les transmet-
tre au superviseur que par blocs et de façon sporadique. En envoyant moins de données et moins
souvent, on diminue les besoins en communications.
Selon l’application, la synchronisation peut être simplement souhaitable ou être un besoin crucial.
Par exemple, si l’on mesure une température sur ouvrage, grandeur physique qui évolue lentement,
un écart de datation de l’ordre de la seconde entre deux mesures distinctes n’influence généralement
pas les algorithmes de thermocontrôle ; en revanche, dans le domaine de la propagation des ondes
dont la dynamique est élevée (de l’ordre de 5 000 dans l’acier ou le béton), les données résul-
tant de l’échantillonnage de ces ondes doivent souvent être corrélées avec une précision de l’ordre
de la microseconde.
Comme tout système électronique (ordinateur, magnétoscope, etc.), le capteur intelligent intègre
nativement un quartz, c’est-à-dire un composant électronique qui lui permet de compter le temps.
Comme chaque quartz possède sa propre incertitude et que les capteurs ne démarrent pas en même
temps, les bases de temps des capteurs ne peuvent être parfaitement en phase sans un mécanisme
de synchronisation. Par construction donc, ainsi qu’en matière de vieillissement électronique et de
sensibilité à la température, les composants différant l’un de l’autre, les capteurs qui en associent
plusieurs diffèrent encore plus, et la corrélation de leurs données nécessite donc un mécanisme de
synchronisation.
S’il semble simple de mettre en œuvre un mécanisme de synchronisation dans les réseaux filaires
où l’on peut par exemple employer l’un des fils pour véhiculer un top synchro resynchronisant les
capteurs, c’est bien plus complexe dans le cas des liaisons sans-fil. Ce top synchro, qui pourrait être
envoyé par radio aux capteurs depuis le superviseur, doit se propager à travers le réseau, marqué
par sa topologie, être capté par le module radio du capteur, décodé et interprété comme une inter-
ruption de synchronisation. À ce délai, il faut ajouter ceux, non déterministes, dus au transit des
données, aux échecs (mécanisme d’échec/rémission des trames, transparent pour l’utilisateur), à
l’exécution des protocoles au niveau de chaque capteur, à la topologie et à la mise en œuvre phy-
sique du protocole sans-fil (ad hoc, broadcast ou diffusée, etc.). Ces délais additionnés constituent
la latence d’un réseau. Du fait de cette latence et des topologies des réseaux, la simple distribution
Une analyse des techniques implémentées pour synchroniser des réseaux de capteurs sans-fil per-
met de classer les solutions en trois catégories que nous passons en revue dans les paragraphes
suivants.
Pour mettre en œuvre ce mécanisme, des protocoles dédiés ont été développés et sont intégrables
logiciellement dans les capteurs sans-fil. Étant donné le lien fort entre la communication, la récep-
tion et la resynchronisation de la base de temps, certains protocoles de synchronisation sont direc-
tement liés à des protocoles de communication comme :
–– le Network Time Protocol (NTP), compatible avec la mise en œuvre du protocole de communi-
cation TCP/IP, mais ne permettant pas le mécanisme du multi-saut, pourtant nécessaire pour qu’un
signal franchisse par saut les différents nœuds qui séparent un capteur du superviseur émettant le
top synchro (précision de l’ordre de la μs) ;
–– le Reference Broadcast Protocol (RBS), similaire au NTP, mais non lié au protocole TCP/IP,
offrant le mécanisme du multi-saut à travers le réseau (précision de l’ordre de 10 μs) ;
–– le Timing-sync Protocol for Sensor Network (TPSN) [12], compatible avec la mise en œuvre du
protocole de communication Zigbee, offrant le mécanisme du multi-saut (précision de l’ordre de
20 μs).
Ce type de mécanismes fait l’objet de nombreux travaux de recherche et développement, car bien
que ces protocoles soient efficients en théorie, dans la pratique leur mise en œuvre augmente sen-
siblement la consommation des capteurs. En effet, pour recevoir la balise de synchronisation, voire
la réémettre, le capteur doit communiquer aussi souvent que l’impose la période de synchronisa-
tion. Par ailleurs, l’approche statistique englobée par ces protocoles dans l’évaluation de la latence
réseau se dégrade fatalement avec le nombre de sauts et avec la distance. Aussi la précision de la
synchronisation n’est-elle pas la même pour tous les capteurs d’un même réseau. Les capteurs les
plus proches peuvent être synchronisés avec le superviseur à quelques microsecondes près, tandis
que les plus éloignés le seront selon le cas à plusieurs dizaines, voire centaines de microsecondes
près. Selon l’application visée, des compromis entre distance, période de synchronisation et période
de réveil radio du capteur peuvent être trouvés au niveau de la mise en œuvre.
Le superviseur distribue à travers le réseau une balise de synchronisation et, à réception de cette
balise, chaque capteur en écoute à ce moment précis (écoute périodique ou sur événement) synchro-
nise sa base de temps sur cette balise (de façon similaire à la synchronisation distribuée) (figure 5).
Ensuite, chaque nœud synchronisé réémet une balise de synchronisation dès qu’il est réveillé (pério-
diquement ou sur événement). Enfin, lorsqu’un capteur détecte un événement, il compte le temps
jusqu’à capter la balise de synchronisation du capteur agissant comme source de synchronisation
qui a été synchronisé le plus récemment.
Les inconvénients de ce mécanisme sont une précision faible (de l’ordre de la milliseconde) et qui
décroît rapidement avec la distance et le nombre de sauts. De plus, comme pour la synchronisation
distribuée, cette méthode n’est pas déterministe. En revanche, elle présente l’avantage de ne pas ou
peu augmenter la consommation unitaire de chaque capteur et de fournir une solution aux réseaux
multi-sauts. Le Post Facto synchronization Protocol (PFP) est un exemple de protocole expérimen-
tal développé avec ce mécanisme.
figure 6
Synchronisation de capteurs
par technique GPS. PPS
Module
GPS RESET Quartz
TIMER 100 MHz
T = 1s ± 50 ns Heure
Processeur
figure 7
Quelques modules GPS
a, b : petits modules
directement intégrables
c : modules GPS en
composants électroniques.
a b c
• Moins un capteur est complexe en termes de traitements à effectuer, de nombre de fonctions élec-
troniques à implémenter, etc. plus il est intégrable ou susceptible d’être optimisé.
• Plus un capteur est intégré, moins il consomme.
• Si un capteur est difficile d’accès du fait de son lieu d’installation, il le sera chaque fois qu’il fau-
dra remplacer les batteries.
• Un capteur enfoui, par exemple noyé dans le béton, porte moins loin (quelques mètres au maxi-
mum suivant la technologie) qu’un capteur accessible.
• Un capteur enfoui doit être soit autonome en énergie pour toute la durée de l’instrumentation,
soit télé-alimenté, mais, dans ce cas, depuis une source relativement proche (quelques dizaines de
centimètres au maximum en RFID [14]).
• Un capteur télé-alimenté ne peut subvenir aux besoins d’une électronique complexe, aussi les
capteurs de ce type doivent-ils être sobres en fonctions logicielles et matérielles.
• La fabrication d’un micro-capteur intégré dédié à une application est très onéreuse (développe-
ment d’ASIC ou de FPGA) et l’application doit amortir ce coût spécifique.
Certaines des technologies citées ci-dessus ont été mises en œuvre afin d’être évaluées et leur
capacité à être adaptées aux contextes du génie civil a été appréciée. Cette mise en œuvre inter-
vient dans certains cas dans le cadre d’applications en cours de recherche et développement au
LCPC.
Quel que soit le lien physique, l’emploi de l’IP au niveau des capteurs et du superviseur leur garantit
des communications fiables. La fiabilité d’un tel protocole signifie que :
–– l’émetteur est assuré que les octets émis sont reçus par le destinataire ;
–– le destinataire est assuré que les octets reçus de l’émetteur sont intègres.
En outre, le TCP/IP fait partie des protocoles qui permettent de gérer de très grands nombres de
points du réseau. Les meilleurs exemples sont l’Internet mondial qui relie des millions d’ordina-
teurs ou encore les nombreux réseaux d’entreprises qui peuvent intégrer des milliers de nœuds
(imprimantes, PC et autres terminaux IP). Ainsi, dans le domaine des WSN, l’IP – décliné en Wifi –
permet d’envisager des réseaux de plusieurs centaines de capteurs.
Bien que robuste, tout type de réseau – filaire ou non – peut subir des coupures (coupure d’un
fil, perte de la porteuse RF, etc.). L’avantage des protocoles de haut niveau tel que l’IP est d’être
capable de réagir en cas de problème sur le réseau. La pile IP notifie alors à l’application, capteur
ou superviseur, qu’un problème est intervenu (avec un numéro d’erreur normalisé correspondant à
l’anomalie). L’application, capteur ou superviseur, peut alors réagir en conséquence, par exemple en
réessayant la transmission dix secondes plus tard, en allumant une led rouge, etc.
Lorsque le protocole IP est implémenté en Wifi, une coupure de communication courante est due
à la perte de couverture radio. Un espace de communication Wifi est généré par un Access Point
(AP). Son rayon d’action est limité par la puissance d’émission qui lui est propre (de 0,1 à 1 W),
par la propriété du canal de propagation et l’adaptation de l’antenne, par l’absorption du milieu
environnant (obstacles, métal, etc.) et par le bruit (concurrence électromagnétique, etc.). Tant qu’un
capteur Wifi se trouve dans la zone de couverture de l’Access Point, les communications réussiront.
En revanche, en dehors ou à la limite de cette zone, les communications peuvent échouer.
Pour évaluer la portée courante d’un Access Point Outdoor générant une zone Wifi, des tests ont
donc été menés sur un véritable ouvrage d’art, dans le cadre du système de Contrôle acoustique
pour la surveillance des câbles (CASC). Nous décrivons ci-après le premier de ces tests, tandis que
le second le sera dans le paragraphe consacré à CASC.
››Description de l’ouvrage
Les tests in situ ont été effectués sur le pont d’Ancenis. Bien qu’âgé de plus de cinquante ans, ce
pont demeure l’un des plus grands ponts suspendus de France (figure 8). Ses dimensions, ses élé-
ments en métal et de maçonnerie en font une cible parfaite pour valider le Wifi. Voici une descrip-
tion sommaire de l’ouvrage, livré en 1953 par la société Baudin-Châteauneuf :
–– ce pont relie la ville d’Ancenis (44) à la commune de Lire (49) en franchissant la Loire ;
–– il est suspendu par deux plans amont et aval de câbles, chacun comprenant 17 suspentes de part
et d’autre de la travée centrale qui en compte 52 ; pour chaque ferme, la suspension comporte
19 câbles toronnés réunis en faisceau continu d’un ancrage à l’autre ;
–– sa longueur totale est de 412 m, sa portée principale est de 238 m ;
–– la hauteur au dessus de la Loire est de 10 m, la hauteur en tête de pylône est de 28,7 m ;
–– les pylônes sont en béton armé, le treillis de la poutre est en acier.
–– le superviseur (un PC portable standard) est placé au niveau d’une chambre d’ancrage, lieu sûr et
inaccessible au public, disposant de réseaux électrique et téléphonique ;
–– l’Access Point Wifi Outdoor sur trépied est positionné de façon dégagée à une dizaine de mètres
de la chambre d’ancrage et relié au PC superviseur par un câble Power Over Internet (i.e. intégrant
réseau et alimentation) ;
–– il est demandé à des capteurs CASC Wifi autonomes sur batteries, positionnés en divers endroits
de l’ouvrage, d’effectuer cinq mesures du rapport signal à bruit (en dB)1 et de les transmettre au
superviseur.
Les tests ont été menés selon des configurations typiques de l’installation d’un tel système sur
ouvrage, bien entendu au regard des besoins en instrumentation et des possibilités de déploiement,
ainsi que dans quelques configurations extrêmes du point de vue des communications hertziennes.
• Première configuration
L’Access Point est positionné sur le toit de la chambre d’ancrage aval côté Ancenis (figure 9). Il
se situe dans le plan des câbles aval. Les tests sont pratiqués en éloignant les capteurs Wifi de la
chambre d’ancrage, depuis la suspente no 1 (S1) jusqu’à la suspente no 17 (S17) et même au-delà
(figure 10). À mesure que l’on éloigne le capteur Wifi de la chambre d’ancrage se rencontrent de
nombreux obstacles métalliques.
figure 9
Access Point Wifi Outdoor
sur la chambre d’ancrage,
i.e. dans le plan des câbles.
1
Pour évaluer la portée du lien de radio-transmission Wifi entre un capteur et l’Access Point, le capteur intelligent CASC
Wifi intègre une fonction permettant d’évaluer le rapport signal à bruit (RSB exprimé en dB) vu par un capteur en un lieu et
un temps donnés. Il s’agit de la différence minimum de puissance entre le signal que l’on cherche à recevoir et le bruit (bruit
thermique, bruit industriel, microondes, bruit dû aux autres réseaux Wifi, etc.). On le définit à l’aide d’un logarithme à base
10 par RSB = 10log (puissance du signal/puissance du bruit). Si le signal est plus puissant que le bruit, le RSB est positif,
si le signal est noyé dans le bruit, le rapport est négatif. Le RSB minimum dont un capteur CASC a besoin pour dialoguer
correctement est donné par le constructeur des composants Wifi qui le constituent. En règle générale, des communications
fiables Wifi sont garanties dès lors que le RSB atteint 5 dB au moins. En-deçà, on a atteint la limite de portée du Wifi.
• Seconde configuration
L’Access Point est à présent positionné à 20 m en aval du pont (figure 11). Dans cette configuration
qui permet d’élargir le champ d’action de l’Access Point, c’est-à-dire d’améliorer le rayonnement
de ses antennes, une nouvelle série de tests est pratiquée (figure 12). En retrait du plan des câbles,
l’Access Point couvre mieux l’ensemble de l’ouvrage, ce qui diminue les risques de masquage du
Wifi par rapport à la situation précédente où l’Access Point était situé sur le toit de la chambre d’an-
crage, autrement dit dans le plan des câbles.
figure 11
Access Point situé à 20 m
en aval du pont sur la rive
droite.
figure 12
Schéma de la seconde
configuration vue de
dessus.
››Résultats et conclusions
Des séries de tests sont menés dans les deux configurations. Pour évaluer le rapport signal à bruit
d’une configuration, on moyenne les mesures effectuées par deux capteurs à raison de cinq mesures
chacun. La figure 13 donne la répartition du RSB en fonction de la position des capteurs sur l’ouvrage
et pour les trois séries de mesures : en configuration 1 avec des capteurs masqués ne voyant pas l’Ac-
cess Point (courbe mauve), en configuration 1 avec des capteurs voyant l’Access Point (courbe bleue),
en configuration 2, l’Access Point Wifi étant donc en retrait de l’ouvrage (courbe jaune).
Nous voyons qu’avec un Access Point positionné sur le toit de la chambre d’ancrage, les commu-
nications avec des capteurs même masqués sont fiables (RSB au moins égal à 5 dB) jusqu’à la
suspente no 33, soit une couverture de plus du tiers de l’ouvrage. Cette couverture est évidemment
étendue si les capteurs sont sortis du plan des câbles, comme l’ont montré des tests complémen-
taires en nacelle. Lorsque l’Access Point est positionné en retrait de l’ouvrage, la couverture est,
comme attendu, encore meilleure, avec plus de la moitié de l’ouvrage couverte (jusqu’à la suspente
no 44) en communications fiables.
Globalement ces essais ont permis de conclure à la viabilité du Wifi comme moyen de communi-
cations inter-capteurs sur ouvrage d’art ; non seulement ils valident la couverture de la zone ciblée
par un seul Access Point même dans une configuration très défavorable du point de vue radio-fré-
quence (capteurs masqués), mais ils démontrent que cette zone peut couvrir le tiers, voire la moitié
de l’ouvrage.
Par ailleurs, comme on l’a vu en positionnant l’Access Point en léger retrait par rapport à l’ouvrage,
les possibilités d’extension de la zone Wifi sont nombreuses :
En extrapolant les résultats, on peut suggérer un positionnement de deux Access Points susceptible
d’assurer une couverture totale de l’ouvrage en Wifi (figure 14) compte tenu de la symétrie de
celui-ci.
figure 14
Positionnement de deux
Access Points en vue
d’assurer une couverture
totale de l’ouvrage en Wifi.
Le cas du pont d’Ancenis est intéressant, car représentatif à la fois des structures à câbles et de bon
nombre d’ouvrages composés de nombreux éléments métalliques hostiles aux propagations radio
(treillis du tablier, pylônes câbles). Cette validation dépasse donc largement le simple cadre du pont
suspendu d’Ancenis.
figure 15
Positionnement de deux
Access Points pour une
couverture totale de
l’ouvrage en Wifi.
figure 16
Le capteur CASC équipé
d’un module Zigbee
et d’un module Wifi en
vue d’une évaluation
comparative
a : le module Zigbee
b : le capteur CASC
prototype
c : le module Wifi.
a b c
figure 17
Tests de transmission de
données réalisés avec un
système CASC équipé du
protocole Zigbee
a : placement des trois
capteurs CASC sur le banc
de test
b : simulation de chocs.
a b
figure 18
Chocs provoqués en trois
endroits de la ligne de
capteurs CASC équipés en
Zigbee.
On a tout d’abord appliqué des chocs d’intensité assez faible pour ne faire réagir qu’un seul capteur
à la fois. Les résultats sont satisfaisants sur le plan fonctionnel, car la norme tient ses promesses :
les transmissions sont fiables, les données sont intègres et parfaitement acheminées par le protocole
quel que soit le routage et le nombre de sauts.
Les chocs de forte intensité appliqués par la suite déclenchent simultanément les trois capteurs,
lesquels cherchent alors à transmettre en même temps des données au superviseur. Mais comme
la norme Zigbee ne prévoit pas de connexions multiples simultanées, le module Zigbee associé au
superviseur reçoit les données des trois capteurs successivement sans notion de priorité. Remarquons
que le protocole TCP/IP autorise pour sa part la communication simultanée entre un quelconque
nœud IP et plusieurs autres nœuds par le mécanisme des sockets. Les modules Zigbee n’ayant pas
La consommation électrique des modules Zigbee est effectivement basse (environ 20 mW) et le
mode de veille fonctionne correctement. Néanmoins, l’incapacité d’un module Zigbee à être réveillé
depuis l’extérieur du nœud auquel il est associé limite beaucoup le déploiement de ce protocole.
En effet, lorsqu’il est en veille, le module Zigbee n’assure plus le mécanisme de transitivité ; aussi,
pour qu’à tout moment le capteur C3 de notre montage d’essai puisse dialoguer avec le capteur C1,
il faut impérativement que le capteur C2 soit en éveil. Ce principe peut, dans de nombreux cas, être
restrictif car, pour les capteurs ne transmettant (donc ne consommant) que sur événement, il impose
que chaque nœud situé sur le plus court chemin au superviseur demeure toujours (ou souvent) en
éveil. C’est l’infériorité des réseaux ad hoc par rapport aux réseaux à base d’infrastructures (type
Wifi, GPRS), dans lesquels les nœuds consomment certes plus, mais sont toujours assurés lorsqu’ils
communiquent de voir le superviseur quel que soit le routage.
La distance théorique maximum de 100 m entre deux nœuds n’a pu être atteinte en extérieur dans
un environnement pourtant moyennement bruité (présence de métal, pas de masquage direct, etc.).
Empiriquement la distance moyenne de 30 m maximum a pu être atteinte entre deux nœuds Zigbee.
Les antennes Zigbee ne sont pas optimisées.
Les débits sont faibles et augmentent sensiblement les durées des échanges mais, au regard du
volume des données classiquement acquises et transmises dans l’instrumentation en génie civil, ces
débits de l’ordre de la dizaine de koctets par seconde restent acceptables.
Sauf à faire partie de la Zigbee Alliance et contrairement à l’IP, la pile Zigbee n’est pas directe-
ment intégrable au processeur que le concepteur a retenu (selon d’autres critères). La pile Zigbee
n’est accessible que via des modules contenant eux-mêmes un processeur qui interface et gère les
couches physiques et logiques du module radio Zigbee. Si ce principe facilite considérablement
l’écriture des fonctions d’exploitation du réseau Zigbee, il n’en demeure pas moins que cette situa-
tion marketing implique la présence de deux processeurs sur une carte où un seul suffirait et ceci
augmente la consommation et le volume du capteur.
Les tests menés pour évaluer la technologie Zigbee ont été limités à une simple application et tou-
tes les potentialités de cette norme n’ont pas été approfondies. Néanmoins, le retour d’expérience
présenté ci-dessus montre que ce protocole pourrait répondre à des besoins en phase avec ses spé-
cificités. Notons que, dans le cas présent, l’évaluation a été faite à partir de modules Zigbee clés
en mains dont la seule interface côté processeur – cœur du capteur – est un port série. La Division
métrologie et instrumentation du LCPC évaluera bientôt une solution intégrée où la couche Zigbee
sera directement accessible au développeur via un petit OS embarqué dans un monoprocesseur. La
plate-forme Mote, décrite dans un paragraphe qui lui est consacré, est représentative de ce type de
solution intégrée.
Ensuite, sur chaque événement que le capteur doit dater, le capteur lit la valeur du timer à l’instant
Ti et corrige cette valeur en Ti’ en effectuant une simple règle de 3. Pour une erreur native moyenne
E estimée à 9 700 cycles, l’équation (1) montre comment corriger la datation des événements pour
en tenir compte.
(1)
En pratique, même lorsque le quartz est de qualité moyenne (p.p.m. élevé), l’erreur qui lui est due
excède rarement les 10 à 50 μs par seconde. Grâce à ce mécanisme, dès qu’un capteur du LCPC
capte le GPS, les événements sont datés avec une précision de 1 μs. Par ailleurs, comme le proces-
seur qui reçoit la trame d’information GPS contient l’heure absolue GMT, le capteur LCPC date ses
données avec l’heure absolue à la microseconde près.
Partant de la capacité du capteur à estimer précisément l’erreur native de son quartz et de l’influence
quasi nulle de l’évolution de la température et du vieillissement électronique sur de courtes périodes
(quelques centaines de secondes à quelques minutes), le LCPC a pu optimiser la consommation du
capteur. En effet, comme expliqué ci-dessus, le capteur sait estimer précisément la période réelle
de son quartz (par rapport à la période théorique). L’optimisation consiste simplement à démarrer
un deuxième timer, synchronisé non sur le signal PPS mais sur une période tenant compte de l’er-
reur native estimée du quartz, à éteindre le module GPS intégré au capteur et, dès lors, à dater les
événements sur la valeur du deuxième timer. Le module GPS n’est rallumé que de loin en loin pour
resynchroniser les timers. Les périodes d’allumage/extinction du module GPS se déterminent alors
suivant les divergences constatées empiriquement (mais constantes) et selon le degré d’exigence
dans la datation d’un événement.
Par la mise en place de rapports cycliques dans l’allumage du module GPS, cette optimisation per-
met également de pallier les situations de pertes temporaires, mais parfois longues de la couverture
GPS.
››Résultats
Une manipulation a permis de mettre au point un capteur divergeant d’une microseconde toutes
les 45 s. Comme l’erreur de datation maximale tolérée par l’application est de 30 μs, le capteur
doit allumer son module GPS toutes les 22 min. Il doit le laisser allumé pendant 3 min, période de
Plusieurs générations du système ont été mises au point par le LCPC au cours des trente dernières
années, l’une d’entre étant industrialisée par la société Quasar Concept [16]. Cette génération par-
ticulière équipe et surveille encore aujourd’hui plusieurs ouvrages en France : ponts d’Aquitaine,
de Foix, de Merlebach, d’Ancenis, etc. Ces déploiements, les retours d’expérience et les analyses
post-mortem d’ouvrages surveillés par le système CASC en ont prouvé l’efficacité et la pertinence.
Dans la panoplie des moyens actuellement disponibles pour prévenir en temps réel la dégradation
des câbles des ouvrages, ce système est une référence.
Le CASC se veut un outil d’aide à la décision pour le gestionnaire, à qui il offre en temps réel une
information sur les ruptures survenant dans les câbles de l’ouvrage. En tenant compte des emplace-
ments des ruptures et des autres informations à sa disposition, le gestionnaire peut mettre en place
des stratégies allant de la simple réduction du trafic à la démolition de l’ouvrage.
figure 19
Système CASC de
surveillance de câbles
a : capteurs CASC fixés au
niveau d’un collier
b : armoire de supervision.
Ce superviseur connaît les positions relatives des capteurs (L12, L23, etc.) et peut calculer les
écarts temporels séparant les détections par différents capteurs (ΔT12, ΔT23). Il est alors capable
de localiser la rupture. Dans l’exemple de la figure 20, une rupture est survenue entre les capteurs
C1 et C2. Les capteurs C1, C2 et C3 ont détecté le passage de l’onde acoustique et envoient l’in-
2
L’élément sensible intégré à chaque capteur CASC est un accéléromètre. Celui-ci, positionné dans le sens longitudinal
du câble lors de l’installation, permet au capteur CASC de mesurer en permanence l’accélération longitudinale (en g) du
câble vue à son niveau ; lors du passage d’une onde due à une rupture, l’accélération dépasse un seuil paramétré (en g). Le
capteur enregistre le niveau (en g) de l’onde et le temps (en μs) lors du dépassement du seuil.
(2)
où
figure 20
Principe de localisation
d’une rupture par le
système CASC.
Bien qu’efficient et fonctionnel, le système CASC a fait l’objet, ces quatre dernières années, d’une
évolution globale. Tout d’abord, à des fins de recherches visant à mieux comprendre le phénomène
et à vérifier certains modèles, il était souhaitable que le capteur CASC puisse, en cas de dépasse-
ment du seuil, enregistrer la forme complète du signal sur une fenêtre de temps (et non pas seu-
lement une valeur maximum). Le système CASC était un système filaire, soumis aux contraintes
exposées en introduction : lourdeur et défaillance de la connectique, coûts. Le redéveloppement
du système en une version sans-fil (au moins partiellement) semblait pertinent. Enfin, l’armoire de
supervision comportait des matériels et des logiciels propriétaires couteux, que l’emploi de nou-
velles technologies tels que les réseaux intelligents et les logiciels à architecture objet a permis de
simplifier grandement.
La résolution de ces différentes contraintes a conduit à la mise au point d’un nouveau système
CASC (figure 21).
figure 21
Principe de
fonctionnement du
nouveau système CASC.
figure 22
Le nouveau capteur CASC
a : en développement
b : intégré en boîtier.
a b
››Résultats
Les développements du nouveau système CASC ont abouti à la réalisation d’une plate-forme pro-
totype complète composée d’un superviseur, d’Access Points de différentes capacités et de cinq
capteurs CASC prototypes (figure 24).
figure 24
Photos de la plate-
forme CASC prototype
développée pour les tests
de validation.
Par la suite, plusieurs séquences de tests d’intégration et de validation ont été menées pour optimiser
puis valider le fonctionnement du système. En particulier, le système CASC, installé dans le banc
de 200 m du LCPC, a fait l’objet de nombreux tests dans le cadre d’un plan de test et de validation
(figures 25a et b). In situ, le système a équipé la poutre du VIPP de Merlebach portée à la rupture
lors d’essais menés par le Réseau scientifique et technique du ministère en charge des transports
(figures 25c et d). Le système a également servi à l’instrumentation d’un échantillon de câble sol-
licité en traction dans le banc de fatigue des câbles du laboratoire ELSA du centre de recherches de
la Commission des Communautés européennes à Ispra, Italie (figure 25e). Une version prototype
de trois capteurs CASC a été acquise par le CCR d’Ispra pour l’occasion.
››Perspectives industrielles
Durant l’année 2007, le LCPC fait développer sur fonds propres une présérie industrielle d’une
vingtaine de capteurs CASC. Ils seront installés sur le pont d’Ancenis, qui fait déjà l’objet d’un
contrat de surveillance des câbles par l’ancienne version du système CASC. Le choix de ce site est
pragmatique : cet ouvrage appartient au patrimoine des ponts suspendus ; des ruptures sont régu-
lièrement avérées ; sa situation permet des interventions rapides de maintenance ou de contrôle du
système CASC ; enfin, le nouveau système sera en concurrence avec l’ancienne génération, ce qui
permettra de conforter les résultats observés.
Parallèlement à cette validation de terrain, le LCPC effectuera un transfert industriel du nouveau
système CASC par vente de licences non exclusives à des sociétés spécialisées dans l’instrumenta-
tion d’ouvrages. Des contacts ont déjà été pris.
››Perspectives technologiques et scientifiques
Malgré les résultats positifs du nouveau système CASC, de nombreux travaux d’optimisation res-
tent à mener, notamment en matière de consommation d’énergie. Le nouveau système CASC est
c e
d
encore de nature filaire pour l’alimentation électrique des capteurs. Même si un fil d’alimentation
simple réduit largement le coût de mise en œuvre du système (par rapport à un câble série spé-
cifique et blindé) en intégrant les avancées des technologies de récupération et de sauvegarde de
l’énergie citées plus haut [17], l’autonomie totale est parfaitement envisageable. Actuellement la
consommation du système CASC est de l’ordre de quelques dizaines de milliwatts. Si l’on réduit
cette consommation à quelques milliwatts, l’autonomie est possible, car le boîtier choisi présente un
volume et des surfaces suffisants pour intégrer des batteries de stockage et des panneaux solaires.
Sur le plan scientifique, les travaux de recherche sur la propagation des ondes dans les câbles,
notamment l’analyse de ces signaux pour en déduire des pathologies, devraient trouver une pre-
mière application grâce au nouveau système CASC. Celui-ci est désormais capable d’enregistrer
et de traiter en temps réel des signaux de très haute dynamique, tout en conservant une datation
absolue. Au niveau de chaque capteur ou de façon centralisée au niveau du superviseur, les modèles
scientifiques pourront être implémentés sous forme d’algorithmes temps réel opérationnels.
La nature du projet exclut tout développement de protocoles propriétaires pour l’échange des don-
nées numériques entre le drone et la station au sol. Aussi, outre la communication protocolaire sur
la base du TCP/IP, les technologies suivantes, mises en œuvre pour le développement du nouveau
système CASC, ont-elles pu être reprises et adaptées pour la PMI :
Par ailleurs, pour répondre aux besoins complexes des nombreux algorithmes implémentés ou pré-
vus par l’instrumentation embarquée, l’OS embarqué μCLinux a été intégré en 2007 au processeur
de la carte embarquée. Le niveau d’abstraction ajouté entre les algorithmes et les ressources du
processeur et de ses périphériques constitue une aide pour les développeurs.
Il ressort clairement du rapport de cette étude que de nombreuses applications filaires pourraient
évoluer avantageusement grâce à des technologies sans-fil (par exemple en sismologie ou en géo-
technique) réduisant coûts, durées de déploiement et de mise en œuvre des systèmes. Il apparaît
également que les nouvelles capacités tels que les OS embarqués associés à des protocoles de com-
munication sans-fil natifs, ou encore l’intégration maximale nécessitée par les capteurs noyés dans
les structures, pourraient motiver le développement de nouvelles applications.
Sur cette base, un projet de Plate-forme sans fil générique (PSFG) a été lancé. Son but est de syn-
thétiser l’ensemble des briques fonctionnelles développées, maîtrisées et déclinables pour d’autres
applications. Le cahier des charges de cette plate-forme a été rédigé. L’objectif global est de rendre
le LCPC capable de délivrer (sous formes de licences) une plate-forme dont le superviseur est
ouvert à l’ajout et à l’intégration d’algorithmes métiers de l’instrumenteur (sous forme de lien
à des progiciels ou par intégration de bibliothèques logicielles telles les DLL). Le superviseur
In fine, outre la cession d’un savoir-faire à des contractants, l’objectif est de constituer une plate-
forme aux capacités ascendantes, qui capitalise et diffuse sous forme d’un standard les avancées du
LCPC en matière de réseau de capteurs intelligents sans fil.
Au niveau matériel, le Mote possède une architecture classique, avec cependant la particularité que
les senseurs sont placés sur une carte fille et reliés au module de base par des connecteurs. Cela
permet de disposer de cartes capteurs variées, pouvant contenir des éléments sensibles à l’intensité
lumineuse, à la température, à l’accélération, etc. Les plans électroniques étant libres et ouverts, il
est possible de développer des cartes capteurs sur mesure tel que dans [20].
Par ailleurs, le fait que l’environnement d’exécution TinyOs est open source, donc libre de droits,
et fortement optimisé au niveau énergétique, a contribué à son implémentation sur d’autres plates-
formes sans fil, telles que Btnodes [21], les Motes d’Intel [22], ScatterWeb [23], etc.
Pour illustrer ces qualités, une étude des performances de TinyOs a été menée, en comparaison
avec le système multitâche temps réel Ecos. Les résultats montrent que les performances sont amé-
liorées d’un facteur 8, les coûts en instruction et en mémoire sont réduits d’un facteur 2 et 30 res-
pectivement, la consommation énergétique d’un facteur 12. Ces résultats montrent que le modèle
événementiel et l’utilisation du concept de composant logiciel aboutissent à des résultats adaptés
aux fortes contraintes des réseaux de capteurs sans fil [24]. En effet, dans le modèle événementiel,
il existe deux contextes d’exécution : le premier est temps réel et ne peut être interrompu, l’autre
exécute des traitements plus longs déclenchés par les gestionnaires d’événements. Enfin, la requête
et son traitement effectif sont découplés dans le temps, souvent de manière asynchrone afin de ne
pas bloquer le processeur de façon prolongée [19].
Il nous a semblé par ailleurs intéressant d’évaluer les performances de l’accéléromètre MEMS
ADXL202 sur deux axes disponibles sur la carte senseur, en comparant lors d’une analyse modale
les fréquences propres d’une maquette de pont en construction obtenues avec le Mote à celles obte-
nues avec un accéléromètre filaire.
Cette maquette de pont est conçue de telle manière que ses fréquences propres sont du même ordre
de grandeur qu’un pont en construction (figure 27a). Le Mote et le capteur filaire sont placés côte
à côte à l’extrémité de la maquette sur le tablier (figure 27b).
figure 27
a : maquette d’un pont en
construction
b : capteurs filaire et
sans-fil.
a b
figure 28
a : schéma du réseau a b
b : photographie du PC et
du Mote utilisé en station
de base.
Le Mote senseur qui effectue la mesure et le Mote station de base qui reçoit les données sont tous
les deux programmés avec une application embarquée NesC, un langage de programmation par
composants, extension du C et développé dans l’environnement TinyOs (figure 29).
figure 29
a : application embarquée
capteur
b : application embarquée
station de base.
a b
Un proxy TCP/IP redirige les trames reçues via liaison série depuis le Mote de base vers un super-
viseur modifié pour les circonstances (figure 30a).
On a mesuré en continu pendant 90 s les vibrations selon l’axe horizontal dues à une excitation
de type impulsionnel. Les variations temporelles de l’accélération sont présentées pour le capteur
filaire sur la figure 30b et pour le Mote sur la figure 30c.
figure 30
Mesures de l’accélération
a : le superviseur
b : mesures avec le capteur
filaire
c : mesures avec le Mote.
ab
c
figure 31
Transformée de Fourier
discrète de l’accéléromètre
filaire (en noir) et de
l’accéléromètre Mote
(en vert).
tableau 1
Fréquences propres extraites (Hz) Fréquences propres extraites (Hz)
Fréquences propres de la
Accéléromètre filaire Accéléromètre MEMS Erreur relative (%)
maquette de pont.
de référence en réseau sans fil
Bien qu’un peu de bruit dans l’espace des fréquences soit présent sur le Mote, ce qu’avaient noté
précédemment Spencer et al. [25], l’analyse des fréquences propres est satisfaisante relativement à
la référence filaire. Si l’on ajoute la possibilité de développer une carte capteurs avec des accéléro-
mètres de haute précision, l’application des Mote à l’analyse modale est très prometteuse.
Conclusions et perspectives
Les travaux réalisés par le LCPC en matière de réseaux de capteurs sans fil intelligents ont été
importants au cours des quatre dernières années et tous n’ont pas été présentés dans le cadre de cet
article. Outre s’imprégner de la culture du domaine, il a fallu intégrer de nouvelles technologies
et de nouveaux standards et penser différemment les développements qui les implémentent. Par
une démarche pragmatique consistant à s’approprier, puis à mettre en œuvre les technologies, la
Division Métrologie et Instrumentation du LCPC a validé certaines technologies dans des contextes
réels du génie civil (validation du Wifi sur un ouvrage d’art) ou lors d’applications concrètes (ana-
lyse modale par Mote, instrumentation d’un drone, etc.).
La durée de vie des ouvrages à surveiller, l’efficience économique et la pérennité des développe-
ments électroniques au sein du Réseau scientifique et technique ont amené à privilégier l’implémen-
tation de standards : protocoles TCP/IP ou Zigbee, OS embarqués de type Linux ou TinyOS. Leur
utilisation confère aux capteurs conçus une longue durée de vie, les rend robustes, reconfigurables
à chaud et réutilisables pour des applications similaires. La veille et l’appropriation technologiques
sont devenues une attribution stratégique de la Division.
La liste des technologies décrites n’est pas exhaustive et de nouvelles technologies ou de nouveaux
concepts sont à l’étude, comme l’intégration du protocole de communication sans-fil BlueTooth
associé à des microprocesseurs à très basse consommation (par exemple le MSP430). L’héritage
Le passage de solutions filaires aux technologies sans-fil impose de nouvelles contraintes. L’analyse
de ces contraintes (en termes d’énergie, de synchronisation, d’intégration) montre qu’aucune
évidence technologique ne se fait jour, étant donné la variété des contextes d’instrumentation.
L’application finale elle-même et les critères de mises en œuvre déterminent les choix de principes
et de technologies. Quelle topologie, quelles distances à couvrir, quelle durée d’autonomie, quelles
dimensions à respecter, quel environnement cible, etc. ne sont qu’un échantillon des nombreuses
questions que le concepteur doit se poser afin de faire les choix adaptés. L’énergie étant la contrainte
la plus forte, ce sujet fait l’objet d’études approfondies. La majorité des instrumentations visées
étant outdoor, les solutions solaires seront particulièrement évaluées.
Ces constats amènent le LCPC, comme de nombreux acteurs du secteur (université de Berkeley,
de Harvard, consortiums industriels) à envisager le développement de plates-formes génériques
[25] intégrant le mieux-disant technologique qu’ils ont développé ou acquis afin de le rendre décli-
nable au mieux des besoins de chaque application. En effet, malgré la diversité des besoins et des
solutions, les standards que sont les protocoles et les OS, ainsi que les fonctions traditionnellement
utilisées dans l’instrumentation permettent des factorisations comme le prévoit la plate-forme sans
fil générique du LCPC dont les déclinaisons seront orientées vers le génie civil (quand d’autres ont
une orientation plus domotique ou télécom).
Les premières réalisations réussies, en particulier l’application CASC sans fil pour laquelle le LCPC
envisage des transferts industriels en 2008, ont prouvé l’efficacité de ces technologies. D’autres
développements en cours ou à venir devraient permettre d’asseoir encore ces technologies dans
un monde promis à de grands bouleversements technologiques comme l’extension de ces techno-
logies au domaine de la sécurité routière en général et de la voiture communicante en particulier.
Le développement des réseaux universels de communications sans fil préexistants, assurés par des
opérateurs tiers (UMTS, Wimax) devrait également simplifier la question de la présence ou de la
création d’un réseau autour d’un ouvrage de génie civil.
Références bibliographiques
1 Lewis F.L., Wireless Sensor Networks, In : Cook 6 Shin Young J., Architecture of Smart, Distributed
D.J., Das S.K. (eds), Smart Environments : Sensor Systems, University of California,
Technologies, Protocols, and Applications, Berkeley. 10 janvier 1996.
University of Texas John Wiley, New York, 2004. 7 Liu J., Li B., Distributed Topology Control in
2 Paek J., Chintalapudi K., Govindan R., Masri S., Wireless Sensor Networks with Asymmetric
A Wireless Sensor Network for Structural Health Links, Proceedings of IEEE Globecom 2003
Monitoring : Performance and Experience, Wireless Communications Symposium, San
Second IEEE Workshop on Embedded Francisco, Californie, Etats-Unis, 1-5 décembre
Networked Sensors (EmNetS-II), Computer 2003, 3, pp. 1257-1262,.
Science Department ; University of Southern 8 Dunkels A., Alonso J., Making TCP-IP viable for
California ; Los Angeles, Etats-Unis, mai 2005. Wireless Sensor Networks, Proceedings of the
3 Cousin V., Analyse économique du Système First European Workshop on Wireless Sensor
CASC, Rapport interne commandé par le LCPC Networks (EWSN 2004), Session Work-in-
à la société Processus & Innovation, décembre progress, Berlin, Allemagne, janvier 2004.
2005. 9 Gast M.S., 802.11 Wireless Networks, The
4 Culler D., Estrin, D. ; Srivastava, M., Overview definitive guide. O’Reilly edition, 2002.
of Wireless Sensor Networks, IEEE Computer 10 Hassanein H., Luo J., Reliable Energy Aware
Society, 37 (8), University of California, Berkeley, Routing In Wireless Sensor Networks, Second
août 2004, pp. 41-49. IEEE Workshop Dependability and Security in
5 Warneke B., Pister, K.S.J., MEMS for distributed Sensor Networks and Systems, 24-28 avril 2006,
wireless sensor networks, Proceedings of the pp. 54-64.
9th International Conference on Electronics, 11 Elson J., Estrin D., Time Synchronization for
Circuits and Systems, Dubrovnik, Croatie, 15-18 Wireless Sensor Networks, Proceedings of
septembre 2002. the 2001 International Parallel and Distributed