Développement de modules de communication pour la coopération de robots mobiles en milieu naturel

HAL Id: hal-02594503

https://hal.inrae.fr/hal-02594503

Submitted on 15 May 2020

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

Développement de modules de communication pour la

coopération de robots mobiles en milieu naturel

A. Abonnat

To cite this version:

A. Abonnat. Développement de modules de communication pour la coopération de robots mobiles en

milieu naturel. Sciences de l’environnement. 2010. �hal-02594503�

MÉMOIRE EN VUE DE L’OBTENTION DU TITRE D’INGÉNIEUR

DÉPARTEMENT : GÉNIE ELECTRIQUE

ET

DU MASTER RECHERCHE MSIR

____________________________________

Développement de modules de communication

pour la coopération de robots mobiles en milieu

naturel

Présentée par

Arnaud ABONNAT

Tuteur industriel : M. Gil De Sousa

____________________________________

Juin 2010

Cemagref de Clermont-Ferrand

Campus universitaire des Cézeaux

24 avenue des Landais

BP50085

63172 Aubière cedex

2

Résumé

Ce stage intitulé « Développement de modules de communication pour la coopération

de robots mobiles en milieu naturel » est proposé par le centre de Clermont-Ferrand du

Cemagref, institut de recherche en sciences et technologies pour l’environnement. Ma

dernière année de formation d'école d'ingénieur à Polytech'Clermont-Ferrand en génie

électrique et la formation de Master Recherche deuxième année MSIR, (modèles,

systèmes, imagerie, robotique) correspondent au profil requis. Au sein de l'équipe

COPAIN animée par M. Jean-Pierre Chanet, mon objectif est le développement de

modules de communication sans fil par ZigBee assurant une qualité de service. La

solution proposée repose sur l'adaptation d'un capteur sans fil nommé LiveNode

habituellement utilisé dans les réseaux de capteur sans fil (RCSF). Un module simulant

une flotte de véhicules est également proposé afin d'étudier l'impact de la

communication sur la régulation de la flotte. Du 15 février au 14 août 2010, mon maître

de stage M. Gil De Sousa du Cemagref et mon tuteur de stage M. Lounis Adouane de

Polytech'Clermont-Ferrand s'assurent de l'avancement de mes travaux.

Abstract

This training course entitled " Development of modules of communication for the

cooperation of mobile robots in natural environment " is proposed by the Cemagref

center at Clermont-Ferrand. It is a research institute in sciences and technologies for the

environment. My last year of training of engineering school at

Polytech'Clermont-Ferrand in electric engineering and the training of the second degree at Master's MSIR,

(models, systems, imaging, robotics) corresponds to the required profile. Within the

team Copain manager by Mr. Jean-Pierre Chanet, my objective is the development of

modules of wireless communication by ZigBee assuring a quality of service. The

application is an adaptation of LiveNode usually used in the networks of wireless sensor

(WSN). A module simulating a fleet of vehicle is also proposed to study communication

the regulation of the fleet. Of February 15th in 14 August 2010, Mr. Gil De Sousa of

Cemagref and Mr. Lounis Adouane of Polytech'Clermont-Ferrand make sure of the

progress of my works.

: archive

ouverte

d'Irstea

4

Remerciement

Je remercie la direction du Cemagref de Clermont-Ferrand pour m'avoir permis de

réaliser mon stage de fin d'études d'école d'ingénieur au sein d'une équipe de recherche.

Je tiens à remercier tout particulièrement Gil De Sousa, mon maître de stage, et Roland

Lenain, « co-maître » de stage, pour l'attention avec laquelle ils ont suivi mon travail

ainsi que pour leur aide et la disponibilité qu'ils m'ont toujours manifestée.

Mes remerciements s'adressent également à Aurélien Jacquot pour ses nombreux

conseils, sa sympathie et sa bonne humeur qui contribuent au bon déroulement de mon

stage.

Merci également à toute l'équipe du Cemagref, particulièrement aux membres de la

pause café pour l'accueil qu'ils m'ont réservé.

Enfin, je profite de ce mémoire pour remercier M. Jacques Lafond et M. Michel James

pour m'avoir soutenu lors des deux ans nécessaires à valider ma première année à

Polytech'Clermont-Ferrand.

Table des figures

Figure 1 : La plateforme de robots mobiles ... 9

Figure 2 : Diagramme d'un véhicule ... 10

Figure 3 : Emplacement des capteurs sur le robucarTT... 10

Figure 4 : LiveNode première version ...11

Tableau 1 : Couches physique du protocole de communication IEEE 802.15.4 (2006)

[ZIGBEE 10]... 12

Figure 5 : AT91SAM7S256 Block Diagram [ATMEL 05] ... 13

Figure 6 : Diagramme AROCCAM ... 14

Figure 7 : Symétrie /Asymétrie d'une communication ... 16

Figure 8 : Collision de messages... 16

Figure 9 : Architecture de réseau ... 17

Figure 10 : Zone de couverture d'un réseau ad hoc... 17

Figure 11 : Routage TBRF ... 18

Figure 12 : Routage DSR ... 19

Figure 13 : Routage OLSR... 20

Figure 14 : Routage LAR1... 20

Figure 15 : Bandes passantes ... 21

Figure 16 : Principe d'une mesure OTT ... 22

Figure 17 : Principe d'une mesure RTT ... 22

Figure 18 : Principe d'une mesure RTT avec communications croissantes ... 23

Tableau 2 : Equation pour un filtre à 4 zones ... 24

Figure 19 : Observation des nœuds voisins, (1) directe, (2) indirecte, (3) rapporté ... 26

Figure 20 : Ordonnanceur par priorité ... 26

Figure 21 : Ordonnanceur SFQ... 27

Figure 22 : Ordonnanceur CBQ ... 27

Figure 23 : Ordonnanceur HTB ... 27

Figure 24 : Architecture logiciel du module de communication... 29

Figure 25 : Structure d'une trame ... 30

Figure 26 : Machine d'état de la fonction de réception ... 31

Figure 27 : Identifiant des différends nœuds ... 32

Figure 28 : Résultat d'une communication LiveNode vers Ordinateur... 33

Figure 29 : Résultat d'une communication Ordinateur vers LiveNode... 33

Figure 30 : Description du modèle... 34

Figure 31 : Fonction de commutation lisse... 35

Figure 32 : Calcul de la nouvelle trajectoire ... 36

Figure 33 : Trajectoire sans suivi et sans communication ... 37

Figure 34 : Trajectoire avec suivi et sans communication ... 37

Figure 35 : Trajectoire avec suivi et communication à 1% d'erreur ... 38

CemOA

: archive

ouverte

d'Irstea

6

SOMMAIRE

Table des figures ... 5

Introduction ... 7

I Présentation des organisations ... 8

I.1 Cemagref ... 8

I.2 Polytech'Clermont-Ferrand... 8

I.3 Master ... 8

II Contexte de l’étude ... 9

II.1 Plateforme robot mobile... 9

II.2 Capteur sans fil LiveNode...11

II.3 Logiciel AROCCAM ... 13

III Etat de L'art sur les réseaux ad hoc... 15

III.1 Problématique de la couche physique... 15

III.2 Problématique du routage ... 16

III.3 Définition de la qualité de service ... 20

III.3.1 Estimateur de bande passante... 21

III.3.2 Congestion d'un réseau... 25

III.3.3 Ordonnancement d’envoi de message... 26

IV Module de communication ... 29

IV.1 Architecture logicielle du module de communication ... 29

IV.2 Ordonnanceur du module de communication ... 32

IV.3 Expérimentations réalisées et résultats... 33

V Modélisation de la communication sans fil ... 34

V.1 Présentation du système et de l'objectif de la simulation ... 34

V.2 Description du modèle de simulation ... 34

V.3 Améliorations apportées au modèle de simulation... 35

V.4 Simulations réalisées et résultats ... 36

Conclusion ... 39

Bibliographies / Références... 40

Annexes ... 42

Introduction

L'agriculture moderne doit répondre aux besoins d'une population de plus en plus

importante. Afin d'accroitre la productivité, des machines agricoles de plus en plus

imposantes sont ainsi développées. Cependant, l'impact environnemental et les

contraintes mécaniques ont augmenté avec la taille de ces machines. Une des

alternatives proposées par le Cemagref est le développement d'une flotte de véhicules

qui collaborent, de manière autonome, pour réaliser une tâche agricole. Pour cela, les

travaux sur le guidage de véhicule le long d’une trajectoire, grâce aux mesures de

capteurs proprioceptifs et intéroceptifs, doivent être poursuivis. De plus, le pilotage

d'une flotte demande un échange d'information entre les véhicules. Les modules de

communication développés par mes soins seront ainsi embarqués sur chaque véhicule.

L'ensemble des modules forment un réseau similaire à un réseau de capteurs sans fil. La

recherche d’une communication avec un certain niveau de qualité de service, m’a

amené, dans un premier temps, à réaliser un état de l'art sur les réseaux de capteurs sans

fil ainsi que des méthodes de mesure et d'estimation du débit d'information voire, bande

passante disponible. Une politique de qualité de service a été implantée sur les modules

constitués d'un microcontrôleur et d’une puce de communication ZigBee. En parallèle

du développement des modules, j'ai programmé une interface pour le logiciel

AROCCAM. Pour étendre ces recherches sur l'influence de la qualité de la

communication dans le contrôle d'une flotte de véhicules, j'ai développé un module

dédié à la communication sans fil dans un modèle de simulation de flotte de véhicules.

CemOA

: archive

ouverte

d'Irstea

8

I Présentation des organisations

I.1 Cemagref

Le Cemagref, institut de recherche en sciences et technologies pour l’environnement,

est un établissement public à caractère scientifique et technologique (EPST) français au

même titre, par exemple, que l’INRA (Institut National de Recherche Agronomique). Il

est placé sous la double tutelle des ministères en charge de la Recherche et de

l'Agriculture. Il collabore avec d'autres organismes de recherche, universités, industriels

et collectivités territoriales sur les thématiques environnementales. Ses recherches

portent notamment sur la qualité des eaux de surface, la biodiversité, les technologies

vertes, le développement territorial, l'économie de l'environnement, les écotechnologies.

Le Cemagref dispose de neuf centres en métropole dont celui de Clermont-Ferrand et

deux antennes à Strasbourg et en Martinique. Le centre de Clermont-Ferrand, qui est

sous la direction de Mme Anne Rizand, possède un site au Cézeaux d'Aubière et un

second à Mondoldre. Les agrosystèmes, les dynamiques de l’environnement et

territoriales des espaces ruraux sont les thématiques de recherche abordées au centre de

Clermont-Ferrand. Les trois équipes Carac'Terre, Copain et Team de l'Unité de

Recherche Technologies et systèmes d'information pour les agrosystèmes (UR TSCF)

du département Ecotechnologies sont réparties sur les deux sites.

I.2 Polytech'Clermont-Ferrand

Polytech'Clermont-Ferrand anciennement C.U.S.T. forme des ingénieurs au sein de

l'université Blaise Pascal depuis 1969. Chaque année, plus de 200 élèves obtiennent le

titre d'ingénieur. La spécificité de l'école de Clermont est de regrouper plusieurs

disciplines dans les cinq départements que sont le génie biologique, le génie civil, le

génie électrique, le génie mathématique et modélisation et le génie physique. Le

département génie électrique, dirigé par M. Khalil El Khamlichi Drissi, propose une

formation complète dans son domaine en adéquation avec les besoins du monde

industriel. Les différents stages et projets ainsi que les conférences d'industriels sont

quelques uns des liens tournés vers les entreprises. Des enseignements avec des aspects

plus théoriques comme l'automatisme, le traitement de l'information sont aussi

prodigués. De plus, Polytech'Clermont-Ferrand propose aux élèves de suivre une

formation de Master Recherche en parallèle à leur dernière année d'étude.

I.3 Master

Le Master Recherche MSIR (modèles, systèmes, imagerie, robotique) a pour objectif de

former de futures doctorants en leur transmettant la méthodologie et la technique en leur

proposant quatre parcours, que sont la recherche opérationnelle et productique, les

systèmes d'information et de communication, l'imagerie-vision et la

robotique-perception.

II Contexte de l’étude

La réalisation d'une tâche agricole dans un champ nécessite généralement le passage de

plusieurs engins comparables à une flotte de véhicules. Le pilotage des engins de façon

automatique implique l'échange d'information. Dans le cadre du Cemagref, la flotte sera

constituée d'un tracteur qui jouera le rôle de véhicule guide et de deux plateformes

robots mobiles qui le suivront. Le développement des modules est réalisé de manière

générique pour pouvoir étendre l'application à un nombre plus important de véhicules

(Contrainte de la flotte,...). Les informations échangées seront transmises du module de

communication à un ordinateur (calculateur) embarqué qui réalisera la régulation de

trajectoire du véhicule. Le programme pour piloter les plateformes mobiles sera

développé avec le logiciel AROCCAM (Architecture d'Ordonnancement de Capteurs

pour la Création d'Algorithmes Modulaires). Une interface spécifique est également

développée pour relier le module de communication au logiciel AROCCAM. De plus, le

module développé durant le stage, se base sur l'expérience de l'équipe COPAIN et sur

leurs travaux déjà menés sur les réseaux de capteurs intelligents sans fil (RCSF). On

pourra notamment s’appuyer sur les travaux de M. Aurélien Jacquot réalisés durant sa

thèse intitulée « Supervision de réseaux d’Objets Intelligents Communicants sans fil »

basés sur un capteur intelligent nommé LiveNode.

L'idée directrice du stage est l'adaptation de ces capteurs, au rôle de module de

communication, embarqués sur les plateformes robots mobiles. Cette nouvelle

fonctionnalité impose un changement sur le réseau qui devient de type MANET. Un état

de l'art sur les réseaux ad hoc a été, dans un premier temps réalisé, suivi d'une

familiarisation avec le matériel électronique et les outils de développement disponibles.

II.1 Plateforme robot mobile

Figure 1 : La plateforme de robots mobiles

Les deux véhicules que le Cemagref utilise sont un robucarTT et un robuFAST (voir

Figure 1) de chez Robosoft. Ces solutions de plateforme mobile sont conçues pour des

déplacements rapides (6 m/s) en terrain naturel comme les champs agricoles. Un

ordinateur avec un système d'exploitation Ubuntu est embarqué sur chaque véhicule. Il

remplit le rôle de calculateur pour piloter la plateforme. Le logiciel AROCCAM remplit

le rôle d'interface entre les capteurs proprioceptifs, intéroceptifs et les actionneurs. Le

module de communication développé se comporte comme un capteur pour ce logiciel

(voir Figure 2).

10

Figure 2 : Diagramme d'un véhicule

Des équipements ont été rajoutés sur le robucarTT sur le site des Cézeaux (voir Figure

3). En voici une liste non exhaustive :

- un GPS avec correction centimétrique, (1);

- un radar, (2);

- une caméra, (3);

- un télémètre, (4);

- un modem Wi-Fi.

Figure 3 : Emplacement des capteurs sur le robucarTT

Notre projet équipe la plateforme d'un nouvel élément. Le module de communication

CemOA

: archive

ouverte

d'Irstea

est une adaptation d'un capteur sans fil nommé LiveNode à notre application.

II.2 Capteur sans fil LiveNode

Le LiveNode (ou LIMOS Versatile Embedded wireless sensor Node) développé par le

laboratoire LIMOS est un nœud de RCSF ou capteur sans fil. Un microcontrôleur

ARM7TDMI AT91SAM7S256 d’ATMEL Corporation permet de piloter différents

capteurs de grandeur physique ou dispositifs de mesure. Il peut également réaliser la

sauvegarde des données collectées par les capteurs et calculer de nouvelles informations

à partir de celles-ci. Une puce XBee ou XBeePro remplit le rôle de medium radio. Elle

communique avec le microcontrôleur par liaison série. Un module GPS peut lui être

également ajouté. Le LiveNode a pour vocation d’être utilisé comme un capteur

intelligent avec une longue autonomie (voir Figure 4).

Figure 4 : LiveNode première version

Une nouvelle version du LiveNode est actuellement en développement. Une carte

électronique munie du même microcontrôleur ARM7 et d’une puce XBeePro servira

d’élément de base ou de carte mère. Des cartes filles avec des dispositifs de mesure

seront connectées et pilotées par bus I²C à la carte mère. Afin que notre projet puisse

utiliser cette nouvelle version, une carte fille spécifique est à développer. Elle jouera le

rôle d'interface Entrée/Sortie.

La puce XBeePro est une solution technique répondant aux caractéristiques de la norme

ZigBee [ZIGBEE 10]. La spécification ZigBee décrit un protocole propriétaire pour

communiquer par radiofréquence s'appuyant sur la norme IEEE802.15.4. La norme

ZigBee prévoit l'utilisation de trois bandes de fréquence (868, 915 et 2400 MHz). La

gamme de fréquence de la puce XbeePro est de 2400 MHz. Cette norme a été

développée pour des applications industrielles à bas coût, une longue autonomie, un

faible débit et à moyenne portée. Les principaux paramètres de la couche physique sont

CemOA

: archive

ouverte

d'Irstea

12

décrits dans le tableau 1.

La portée théorique d'une puce XBeePro est de 1500m dans un espace libre d’obstacle

[XBEE 06]. La configuration de la puce permet notamment le choix du canal de

fréquence parmi les 16 disponibles de la bande de 2400 MHz. Il est aussi possible

d'attribuer une adresse à la puce et de désigner l'adresse d'une autre. Cela forme un

couple de puces communicantes implémentant un mode point-à-point. Le changement

de couple nécessite une reprogrammation de la configuration. Ce changement

demandant plusieurs secondes, le choix a été fait d'utiliser le mode « diffusion » (ou

« broadcast »). Un mécanisme de retransmission en cas de collision est présent. Le

nombre de tentatives de retransmission peut être choisi. Notre application utilise, par

défaut, trois tentatives. La configuration du port série est celle par défaut : 9600 b/s,

sans bit de parité et avec un bit de stop. Un buffer d'une capacité de 100 octets se trouve

en entrée du port série afin d'attendre la disponibilité de l'antenne partagée entre les

opérations d’envoi et de réception. Dans le cas où la bande passante se révèlerait

insuffisante, il est possible d'augmenter le débit du port série et/ou d'ajuster le nombre

de tentatives de retransmission.

Tableau 1 : Couches physique du protocole de communication IEEE 802.15.4 (2006)

[ZIGBEE 10]

Le microcontrôleur AT91SAM256 de chez ATMEL Corporation était déjà utilisé dans

des prototypes de capteurs intelligents du Cemagref (voir Figure 5). Les caractéristiques

qui ont amené à son choix lors du prototypage du capteur sont multiples [ATMEL 05].

Il intègre une mémoire flash de 256 Ko permettant de sauvegarder les données

collectées par les dispositifs de mesure. Il dispose de deux liaisons séries universelles

asynchrones (USART). Ces liaisons permettent de communiquer avec un module GPS,

facultatif, pour l'un et, le reste du réseau pour l'autre via la puce XBee. Sa fréquence de

fonctionnement est de 50 MHz et sa tension d'alimentation est de 3.3V.

Dans la configuration qui nous intéresse, dite de module de communication sans fil, le

microcontrôleur réalise la gestion du réseau avec la notion de qualité de service. L'un

des USART(s) est toujours relié à la puce XBeePro. L'autre relie le nœud devenu

CemOA

: archive

ouverte

d'Irstea

module de communication au PC avec l'interface logiciel AROCCAM.

Figure 5 : AT91SAM7S256 Block Diagram [ATMEL 05]

II.3 Logiciel AROCCAM

L'architecture d'ordonnancement de capteur pour la création d'algorithmes modulaires

(AROCCAM) est née d’une collaboration entre le Lasmea et le Cemagref [TESSIER

06]. Ce logiciel centralise les données capteurs et réalise une fusion de données pour

notamment les algorithmes de pilotage de véhicules. Cette architecture multitâche et

événementielle est légère en temps d'exécution. Une application possède une fonction

permettant de s'abonner à des interfaces et des fonctions programmes. Au lancement

d'AROCCAM, son noyau liste les différents abonnements propres à chaque application,

puis attend les événements des interfaces. Une fois qu'un événement est détecté, les

données de l'interface sont transmises aux applications qui disposent d’un abonnement

et les fonctions programmes des applications associées sont exécutées.

CemOA

: archive

ouverte

d'Irstea

14

La version d'AROCCAM utilisée est la version 1.12 fonctionnant avec le système

d'exploitation Ubuntu 8.0.4. Ce couple Ubuntu-AROCCAM correspond à la

configuration des applications déjà développées pour le pilotage du RobucarTT. Le

programme de l'interface n'est pas exportable sur une version plus récente du logiciel.

Le module de Communication n'est pas un capteur natif d'AROCCAM et nécessite donc

le développement d’une nouvelle interface (voir Figure 6).

Figure 6 : Diagramme AROCCAM

Noyau du logiciel

Application (A)

Interface (Joystick)

Application (B)

Interface (GPS)

Interface (Horloge)

Interface (Module de Communication)

Demande

d’abonnement à

des interfaces

Événements

III Etat de L'art sur les réseaux ad hoc

Les réseaux ad hoc sont des réseaux sans fil dans lequel les nœuds s'organisent par

eux-mêmes pour établir les communications au sein du réseau. Une forte dynamique dans

leur organisation caractérise les réseaux ad hoc. Les nœuds susceptibles d’appartenir à

un tel réseau sont souvent mobiles, d'autant plus s'ils sont embarqués sur des véhicules.

L'arrivée ou le départ d'un nœud dans le réseau est alors fréquent. On retrouve les

termes MANET (Mobile Ad hoc NETwork) ou VANET (Véhicule Ad hoc NETwork)

dans plusieurs publications [LABIOD 06]. Dans les réseaux ad hoc, des problématiques

déjà présentes dans les réseaux filaires, comme le routage, sont encore plus complexes à

résoudre.

III.1 Problématique de la couche physique

Les réseaux sans fil hertzien utilisent l'air comme médium de communication. La

propagation des ondes électromagnétiques est conditionnée par l'antenne utilisée

pouvant être omnidirectionnelle ou directionnelle.

La portée radio D d'une antenne, dans les conditions d'un espace libre de tout obstacle,

suit l'équation suivante :

Pr

4

Gr

Ge

Pe

D

×

×

×

×

=

π

λ

Où

λ

est la longueur d'onde, Pe et Pr sont respectivement la puissance émise et celle

reçue, Ge et Gr sont respectivement le gain isotrope de l'antenne de l'émetteur et de

celle du récepteur.

La réflexion des ondes, liée à la présence d’obstacles, diminue la portée précédemment

calculée. La zone de couverture d'une antenne correspond à l'espace dans lequel un

récepteur reçoit une puissance égale ou supérieure à sa puissance de réception.

Selon la puissance de chaque nœud, un problème d'asymétrie peut apparaître. La

communication est symétrique entre deux nœuds lorsqu'ils se trouvent chacun dans la

zone de couverture de l'autre. Elle est asymétrique quand l'un des deux nœuds n’est pas

dans la zone, et elle devient coupée si aucun des deux n’est à portée l’un de l'autre (voir

Figure 7). Une communication symétrique est donc nécessaire pour qu'elle soit

bidirectionnelle [LABIOD 06].

16

Figure 7 : Symétrie /Asymétrie d'une communication

La problématique des collisions de messages demeure la même que pour un réseau

filaire. Dans le cas de communications sur un seul canal de fréquence, des règles

permettent d'éviter une collision. Deux nœuds ne peuvent pas émettre en même temps,

s'ils sont mutuellement à portée. En outre, un nœud ne peut recevoir deux signaux en

même temps (voir Figure 8).

Figure 8 : Collision de messages

III.2 Problématique du routage

Le mécanisme d'acheminement d'un message d'un point à l'autre du réseau correspond

au routage. Il consiste à choisir le chemin reliant deux points du réseau. L'architecture

centralisée hiérarchisée s'oppose à l'architecture décentralisée multipoint complexe (voir

Figure 9). Un réseau centralisé permet de simplifier le routage. Les nœuds de niveaux

supérieurs centralisent les communications partant des niveaux inférieurs. Il suffit alors

que chaque nœud central connaisse ses voisins. Le goulot d'étranglement des nœuds

centraux provoque un fort risque de saturation. Afin de comprendre les différents

mécanismes en jeux et les méthodes pouvant être mises en place pour éviter les risques

mentionnés, une étude sur les différents protocoles de routages existants a été menée.

L'architecture multipoint complexe admet plusieurs routes possibles pour relier deux

points. La complexité du routage vient du choix du meilleur chemin parmi la multitude

CemOA

: archive

ouverte

d'Irstea

possible. L'avantage d'un tel système est de diminuer le risque de saturation du réseau.

Figure 9 : Architecture de réseau

Dans un réseau filaire, l'infrastructure est globalement fixe. Une fois l'architecture

connue, des tables de routage sont créées. La forte mobilité des nœuds des réseaux ad

hoc modifie fréquemment l'architecture. Chaque nœud du réseau est limité par sa portée

d'émission et est donc isolé d'une partie du réseau. La possibilité qu'a chaque nœud de

servir de relais radio permet d'étendre le réseau à l'ensemble des nœuds sous couverture

radio du réseau (voir Figure 10). La stratégie de routage doit être connue par l'intégralité

des nœuds.

Figure 10 : Zone de couverture d'un réseau ad hoc

La problématique du routage des réseaux ad hoc reste ouverte [CHANET1 07]. En effet,

la complexité est multiple :

- l'architecture est fortement dynamique;

CemOA

: archive

ouverte

d'Irstea

18

- la qualité de la communication varie selon la portée de chaque nœud, (notamment les

liens radios asymétriques);

- l'air est un médium ouvert aux perturbations, (bruits radio et obstacles physique);

- les ressources des nœuds sont souvent limitées (puissance de calcul, énergie …);

- le médium radio est peu fiable pour la sécurité.

Les protocoles de routage sont autant abondants que les problèmes rencontrés sont

nombreux. Les protocoles de routage sont répartis en quatre catégories : proactif,

réactif, hiérarchique et géographique [LABIOD 06].

Les protocoles de routage proactifs utilisent des tables de routage comme dans les

réseaux filaires. Afin de remédier au problème des mouvements des nœuds, les tables

sont mises à jour en continue. Ces mises à jour génèrent des communications

supplémentaires afin de maintenir le réseau.

Le protocole TBRPF (Topology Broadcast based on Reverse Path Forwarding) est un

exemple de protocole proactif. Chaque Nœud construit son arborescence menant à tous

les autres nœuds. L'algorithme de Dijkstra permet d'obtenir les routes les plus courtes en

nombre de sauts. Des messages « Hello » sont émis par chaque nœud périodiquement

pour signaler sa présence à ses voisins. Une fois l'arborescente construite, seuls les

changements de voisinage la mettent à jour. Cela permet de limiter la bande passante

utilisée uniquement aux messages de contrôle. La Figure suivante montre les

arborescences de deux nœuds.

Figure 11 : Routage TBRF

Les protocoles de routage réactifs explorent le réseau suite à une demande

d'établissement de communication. Le coût, en termes de communication, de la gestion

du réseau est faible. L'inconvénient d'un tel principe est le temps d'attente lié à

l'exploration.

Le protocole DSR (Dynamic destination-Sequenced Distance-Vector) appartient à cette

catégorie. L'exploration se fait par l’inondation de messages RREQ (Route REQuest)

possédant la liste des nœuds par lesquels ils sont passés. Chaque nœud ne transmet

qu'une fois le message. Une fois que le message RREQ arrive à destination, une réponse

CemOA

: archive

ouverte

d'Irstea

avec un message RREP (Route REPly) est renvoyée au nœud demandeur. Le RREP

possède la route qu'il faudra suivre. Le schéma suivant montre la recherche du chemin

entre le nœud A et le nœud G.

Figure 12 : Routage DSR

Les protocoles hiérarchiques sont destinés aux réseaux avec un grand nombre de nœuds.

Ce type de protocole permet une meilleure dissémination des informations en

regroupant des nœuds dans des sous-ensembles (ou « cluster »). Un nœud est désigné ou

élu maître de chaque sous-ensemble. L'ensemble des nœuds « maître » (ou

« clusterhead ») forment le sous-réseau de niveau supérieur. Le principal avantage de

cette solution est la réduction de la taille des tables de routage. Les protocoles

hiérarchiques sont également efficaces en présence de nœud avec un critère dominant

comme une position fixe ou une zone de couverture plus importante.

Le protocole OLSR (Optimized Link State Routing) est hiérarchique et proactif.

Périodiquement, il réalise la mise à jour des tables de routage par une inondation. Afin

de limiter le nombre de messages de contrôle, certains nœuds sont élus « nœud MPR »

(Multi Point Relay). Leur rôle est de propager l'inondation. Le Réseau s'organise autour

du sous-réseau des MPR comme le montre la Figure 13.

CemOA

: archive

ouverte

d'Irstea

20

Figure 13 : Routage OLSR

Les protocoles géographiques prennent en compte la situation physique des nœuds. Il

est indispensable d'avoir un moyen de localisation. Cette information facilite le routage

en donnant une direction à l'exploration.

Le protocole LAR1 (Location-Aided Routing) est géographique. Il prend en compte la

position que peut avoir le nœud de destination par rapport à sa position connue. Une

surface rectangulaire incluant le nœud émetteur et la zone de probable localisation du

nœud destinataire détermine les nœuds utilisables comme relais. La Figure 14

représente l'acheminement d'un message de A à J. Le nœud J pouvant se déplacer à une

vitesse Vj.

Figure 14 : Routage LAR1

III.3 Définition de la qualité de service

La qualité de service correspond à un niveau d’exigence requis par un client et à une

politique à suivre afin de répondre au mieux à ses attentes [LABIOD 06], [SWEENEY

04]. Les attentes souhaitées dans les réseaux de communication sont fortement

dépendantes de l'application. Un débit d'information infiniment élevé avec un temps de

CemOA

: archive

ouverte

d'Irstea

transfert et un taux d'erreur nul est l'objectif idéal. Les contraintes physiques et

techniques imposent des limites et un compromis entre ces trois objectifs. De plus, afin

d'appliquer une politique satisfaisante, des mesures doivent être réalisées pour estimer

l'état du réseau. Le temps de transfert peut être caractérisé par des mesures du délai

instantané et/ou du délai moyen pour le transfert d'un message entre l’émetteur et le

récepteur. La mesure de la gigue des messages correspondant à une fluctuation des

délais de transfert, est une autre valeur caractérisant le temps de transfert. La qualité du

réseau dépend également du taux d’erreurs. L'erreur peut être de différentes natures :

−

la perte d'un message;

−

la corruption de l'information du message;

−

la mauvaise insertion correspondant à l'arrivée d'un message au mauvais

destinataire.

La qualité du réseau peut être estimée de manière locale entre deux nœuds ou dans un

nœud, ou sur l'ensemble du réseau en interpolant la qualité du chemin entre deux points

du réseau. Le terme de bande passante est souvent utilisé pour parler du débit

d'information d'un réseau. Une liaison entre deux nœuds d'un réseau se caractérise par

une bande passante maximale théorique, une bande passante libre et la bande passante

utilisée (voir Figure 15). La bande passante maximale théorique est fixée par la

technologie choisie, tandis que la bande passante libre est limitée par l'application et

l'environnement de la liaison.

Figure 15 : Bandes passantes

III.3.1 Estimateur de bande passante

Les estimateurs de bande passante sont de type invasif ou non-invasif. Les estimateurs

invasifs reposent sur l'envoi de messages dédiés à la mesure. Ces estimations sont

d'autant meilleures que le nombre de messages de mesures sont nombreux. Il en résulte

néanmoins une diminution de la bande passante maximale utile. Les estimateurs

non-invasifs analysent des informations portées par les messages de la communication

courante. Ils utilisent également des informations sur l'état du nœud.

CemOA

: archive

ouverte

d'Irstea

22

III.3.1.a Les estimateurs de bande passante invasifs

Les estimateurs de bande passante invasifs utilisent la mesure du délai de transmission

d'un message entre l'émetteur et le destinataire. Le délai de transfert varie selon le

nombre de nœuds le long du trajet et la distance les séparant. Les deux méthodes

élémentaires pour cette mesure sont la méthode One-way Trip Time (OTT) et la

méthode Round-Trip Time (RTT) [LAI 99], [AMAM2 07]. La méthode OTT est une

mesure directe du temps entre l'envoi et la réception du message spécifique à la mesure.

Sa mise en œuvre impose que l'émetteur et le destinataire partagent une même base de

temps. Le destinataire mesure le temps entre la date d'envoi fixée et la date d'arrivée du

message spécifique à la mesure (voir Figure 16).

Figure 16 : Principe d'une mesure OTT

La méthode RTT est la mesure du temps entre l'envoi d'un message et la réception d'une

réponse à ce message. L'émetteur envoie un message spécifique. Le destinataire le

reçoit et renvoie un message d'acquittement en réponse (voir Figure 17). Le délai de

transfert est égal à la moitié du temps mesuré, dans l'hypothèse que l'aller et le retour

soient symétriques. Le principal avantage de cette méthode est qu'elle ne nécessite pas

de partager une même base de temps.

Figure 17 : Principe d'une mesure RTT

La formule suivante permet, par exemple, d’estimer la bande passante :

P

RTTf

L

K

BP

×

×

=

(rep.)

P

OTTf

L

K

BP

×

×

×

=

2

Où K est une constante prenant en compte le contexte du réseau. Elle peut varier de 0,87

CemOA

: archive

ouverte

d'Irstea

à 1,31. L est la taille des messages, RTTf (rep. OTTf) est la mesure RTT (rep. OTT)

filtrée et P est le taux de perte.

Le filtre de la mesure RTT est réalisé par la méthode EWMA d'équation :

)

1

(

)

1

(

)

(

n

=

RTTf

n

−

×

λ

+

RTT

×

−

λ

RTTf

(rep.)

OTTf

(

n

)

=

OTTf

(

n

−

1

)

×

λ

+

OTT

×

(

1

−

λ

)

Avec RTTf(n-1) (rep.OTTf(n-1)) la valeur précédente calculée et

λ

le gain du filtre. Si

λ

est proche de 1 le filtre est stable (les nouvelles mesures ont moins d'influence) et si

λ

est proche de 0, le filtre est agile (les nouvelles valeurs influent fortement la valeur

filtrée).

La méthode Train Of Packet Pair (TOPP) et la méthode Self-LOading Periodic Streams

(SLoPS) complètent la méthode RTT. La méthode TOPP envoie successivement deux

messages, tandis que la méthode SLoPS envoie un premier message puis envoie un

second message à la période suivante. La mesure du temps entre la réception des

messages d'acquittement permet d'estimer la bande passante perdue due à des

communications croissantes (voir Figure 18).

Figure 18 : Principe d'une mesure RTT avec communications croissantes

III.3.1.b Les estimateurs de bande passante non-invasifs

Les estimateurs de bande passante non-invasifs ne génèrent aucun message spécifique.

Ils utilisent les informations sur l'état du nœud comme le nombre de message en

transitions ou le temps d'attente dans le nœud. L'hypothèse que le nœud subisse un

goulot d'étranglement au niveau de l'envoi de message permet d'estimer la bande

passante. Dans le cas où il n'y a aucun message dans le nœud, on peut supposer que la

bande passante libre est maximale pour l'envoi de message. Inversement si le nombre de

CemOA

: archive

ouverte

d'Irstea

24

messages stockés augmente, alors la bande passante libre diminue.

La taille d'un message est une information qui peut être mesurée. Il est alors possible de

comparer le nombre d'octets reçus en une seconde au débit maximal théorique. De plus,

les protocoles de communication imposent souvent une encapsulation des données dans

une trame. Une trame dispose d’un entête et de données permettant généralement la

détection d'erreurs de transmission en fin de trame. Le calcul du taux d'erreurs complète

l'estimation. Certains entêtes possèdent la date de l'envoi du message et un identifiant de

message. Une mesure de RTT (ou de OTT) devient possible sans l'utilisation de

message spécifique. Dans le cas d'une application générant des communications en

continue la méthode Non Invasive Manet Bandwidth Estimator (NIMBE) [CHANET2

07] permet d'obtenir une bonne estimation basée sur les formules suivantes :









































−

×

−

×

=

min

2

exp

1

1

max

RTT

RTT

L

BP

BP

(Rep.)









































−

−

×

=

min

exp

1

1

max

OTT

OTT

L

BP

BP

L'ensemble des estimateurs de bande passante sont très sensibles aux pics de variation.

Le filtre Flip-Flop affine l'estimation de manière algorithmique. Selon la variation entre

deux estimations consécutives, l'équation inverse ou non les coefficients d'un filtre

EWMA. L'algorithme 1 est alors utilisé pour le choix de l'équation.

Où BP(x) est la bande passante estimée à l'instant x,

σ

la variance de la bande passante

et

λ

_{une constantes entre 0,5 et 1.}

Le filtre à adaptation de zone est une amélioration du filtre Flip-Flop [AMAM1 04]. Le

nombre de zones sont supérieurs à deux, contrairement au filtre Flip-Flop. La

correspondance zone-équation est résumée dans le Tableau 2.

Tableau 2 : Equation pour un filtre à 4 zones

CemOA

: archive

ouverte

d'Irstea

III.3.2 Congestion d'un réseau

La congestion d'un réseau est la conséquence de la réalisation d’un nombre important de

communications provoquant un ralentissement global de celui-ci. Une congestion peut

être locale ou globale. Des phénomènes non- exhaustifs en sont la cause. Le routage est

naturellement une cause de problèmes comme présenté dans le chapitre précédant. Des

goulots d'étranglement peuvent, par exemple, se trouver au niveau du nœud qui

centralise les communications. Des messages cherchant leur destinataire peuvent se

retrouver bloqués dans une boucle du réseau. Leurs accumulations rendent l'ensemble

des nœuds de la boucle bloquants aux autres communications. Une différence entre le

débit d'entrée et de sortie d'un même nœud, ainsi qu'une différence de débits entre

nœuds sont également une cause de congestion. Le blocage d'un message est également

possible à l'intérieur d'un nœud. Le chapitre suivant sur l'ordonnancement d'envoi de

message développera ce point. Une congestion peut également être due à un acte

malveillant. Un nœud corrompu peut bloquer ou mal rediriger les communications. La

sollicitation d'un nœud par un nombre important de demandes bloquera également les

communications [LABIOD 06]. Si aucune méthode n’est mise en place pour diminuer

voire arrêter la congestion, un problème local est susceptible de rapidement se propager

à l'ensemble du réseau. Limiter le temps passé d'un message dans le réseau est une

méthode courante pour diminuer la congestion d'une boucle. Le temps passé est

généralement mesuré en nombre de sauts du message avec la méthode TTL

(Time-To-Live). De la mémoire peut être rajoutée au nœud pour augmenter la taille des buffers de

réception, de manière à atténuer un pic d'activité. Il est également possible qu'un nœud

ayant rempli son buffer supprime un certain nombre de messages pour alléger le réseau.

En limitant le nombre de messages sur le réseau, la congestion se voit maîtrisée. Il est

possible de fixer le nombre d'envois de messages pour une période donnée, mais des

méthodes permettent d'exploiter le réseau de manière plus optimale. La mesure de la

bande passante libre permet de limiter au minimum l'envoi de messages afin d'éviter la

congestion du réseau.

Les réseaux ad hoc sont difficiles à protéger d'un nœud malveillant. La nature même du

réseau admet l'intégration de nouveaux nœuds. Les méthodes de cryptage sont une

solution pour sélectionner les nœuds entrants mais complexes à mettre en œuvre dans

les réseaux de capteur sans fil.

Une méthode consistant à observer les nœuds voisins et à leur attribuer une réputation

de fiabilité est possible [LABIOD 06]. Les nœuds avec une faible réputation sont peu

sollicités pour le routage. Trois méthodes, utilisant la possibilité d'écoute des nœuds,

sont possibles avec les réseaux sans fils (voir Figure 19) :

•

Le nœud émetteur A demande à B de transmettre un message pour C. Une fois sa

demande faite, le nœud A écoute le nœud B et vérifie qu'il le transmet correctement à C.

Alors A se fait une réputation de B, (méthode directe).

•

Le nœud D écoute ses voisins et entend que B doit transmettre un message à C. Il

vérifie que B transmet correctement à C. Alors D se fait une réputation de B, (méthode

indirecte).

•

Le nœud D écoute ses voisins et entend que B doit transmettre un message à C. Il

vérifie que B transmet correctement à C. Le nœud D finit par transmettre la réputation

de B à ses voisins, (méthode rapporté).

CemOA

: archive

ouverte

d'Irstea

26

Figure 19 : Observation des nœuds voisins, (1) directe, (2) indirecte, (3) rapporté

III.3.3 Ordonnancement d’envoi de message

Les messages dans un réseau n'ont pas tous la même fonction. Les chapitres précédents

ont décrit des méthodes utilisant des messages de contrôles en plus de ceux de

l'application. De plus, les messages de l'utilisateur ne remplissent également pas les

mêmes fonctions. Les nœuds du réseau transmettent indifféremment ces messages ou

utilise un ordonnanceur [DUVAL], [CLAFFY 03]. Ce dernier varie selon les attentes de

l'application. Une file de messages FIFO (First In First Out) permet de sauvegarder les

messages en attendant leur envoi. Cette méthode du moindre effort peut évoluer afin de

privilégier certains messages. Il est courant de caractériser les messages d'une priorité.

L'ordonnanceur se complexifie avec un classement des messages selon leur priorité

(voir Figure 20). Plusieurs files de messages matérialisent le résultat de ce classement.

L'ordonnanceur effectue alors l'envoi par ordre de priorité. Un problème de congestion

apparaît à ce niveau, des messages pouvant être bloqués par l'arrivée en continue de

messages plus prioritaires. Différents ordonnanceurs vont maintenant être présentés.

Leur différence vient généralement des critères de classement et d'envoi des messages

utilisés.

Figure 20 : Ordonnanceur par priorité

La méthode SFQ (Stochastic Fair Queuing) classe toujours les messages par priorité.

L'envoi se fait avec un tirage aléatoire au niveau des files de messages (voir Figure 21).

Des pondérations permettent aux files les plus prioritaires d'être privilégiées. Cette

Priorité

Priorité forte

Priorité

Priorité faible

Critère du

classement

File de messages

Critère

d'envoi

méthode a été proposée pour résoudre le problème de blocage des messages les moins

prioritaires.

Figure 21 : Ordonnanceur SFQ

La méthode CBQ (Class Base Queuing) n'utilise plus la priorité comme critère de

classement, mais la bande passante désirée pour le message (voir Figure 22). Une

mesure de la bande passante disponible en sortie est réalisée. L'envoi est accordé en

priorité aux messages les moins demandeurs de bande passante sous condition que la

bande passante libre est suffisante.

Figure 22 : Ordonnanceur CBQ

La méthode HTB (Hierarchical Token Bucket) utilise le type d'application auquel le

message est dédié (voir Figure 23). Selon les applications, les messages requièrent une

certaine bande passante. L'envoi se réalise comme pour la méthode CBQ.

Figure 23 : Ordonnanceur HTB

Priorité

Priorité forte

Tirage

aléatoire

Priorité faible

50 %

1%

Pondérations

Critère du

classement

File de messages

Critère

d'envoi

Bande

passante

souhaitée

Besoin fort

Besoin et

Bande

passante

disponibl

e

Besoin faible

Critère du

classement

File de messages

Critère

d'envoi

Mesure de la

bande passante

Classement

Téléchargement 6 Mb/s

Interactif 6 Mb/s

Vidéo 4 Mb/s

VoIP 4 Mb/s

Envoi en

fonction

de la

bande

passante

Mesure de la

bande passante

28

La méthode CSS (Clark Shenker Shang) classe les messages en fonction de leur besoin

d’arrivée à destination dans un temps borné ou non. L'envoi sera accordé aux messages

ayant le temps d'expiration le plus proche.

CemOA

: archive

ouverte

d'Irstea

IV Module de communication

IV.1 Architecture logicielle du module de communication

La programmation du microcontrôleur AT91SAM7S256 se réalise avec le logiciel de

développement IAR Embedded Workbench Kickstart. Ce logiciel permet la compilation

de codes en langage C et la programmation du microcontrôleur par liaison JTAG. Un

mode « Debug » est accessible pour corriger d'éventuelles erreurs de comportement du

programme. L'application développée doit configurer les périphériques du

microcontrôleur notamment les deux liaisons série asynchrone universel (USART(s)),

ordonner, réaliser l'envoi et la réception de messages sur ces deux liaisons, et assurer un

niveau de qualité de service. La Figure 24 décrit le modèle suivi pour structurer le

logiciel de communication. Un message reçu doit tout d'abord remonter les différentes

couches pour pouvoir être routé, puis redescendre pour être envoyé. La qualité de

service réalise des mesures dans toutes les couches traversées par les messages et

calcule les critères d'envoi.

Figure 24 : Architecture logiciel du module de communication

Le programme est réalisé de telle sorte qu'il puisse être amélioré. Pour cela, l'application

est divisée en plusieurs tâches. La tâche US assure la configuration et l’utilisation des

périphériques USART(s). La tâche TI assure la configuration et l’utilisation des

périphériques Timer(s). Ces deux premières tâches constituent la couche de plus bas

niveau. La couche supérieure est l'ordonnanceur, matérialisé par la tâche OR où est

organisé l'envoi des messages en fonction des données de la qualité de service. La

dernière couche correspond à la tâche RO qui détermine le routage de messages.

CemOA

: archive

ouverte

d'Irstea

30

Parallèlement à cette pile, la tâche QS réalise le relevé des mesures de la qualité de

service et calcule les critères permettant de prendre des décisions à son sujet.

Les fichiers « .h » d'une couche fournissent les interfaces uniquement pour la couche

supérieure. Les interfaces sont constituées par les prototypes des fonctions, des

constantes et définitions de type. Des fonctions sont uniquement dédiées à retourner les

valeurs des variables globales, ceci dans le but de limiter ce type de variables à une

même tâche. Les noms des variables globales, des constantes et des fonctions sont

constitués des deux premières lettres correspondantes à leur tâche associée, puis de

quatre autres lettres désignant leur rôle (une variable globale, une constante, une

fonction). Exemple : US_FUNC_trans_char.

Le fichier Boart.h fait la correspondance entre des étiquettes permettant d'accéder aux

ressources du microcontrôleur et des étiquettes propres à notre application, cela dans le

but de conserver le reste du programme en cas de changement de composant.

Le fichier frame.h définit la structure de la trame dans laquelle sont conservées les

données de la communication. Des informations supplémentaires sont ajoutées aux

données « utilisateur », afin d'assurer le routage, de caractériser le type de données, de

tester l'intégrité des données à leur réception et de propager des informations utiles à la

qualité de service. Actuellement, le réseau ne comprend que deux nœuds sans fils et ne

nécessite pas de champs identifiant le destinataire, mais dans le but de conserver un

certain niveau de généricité, plusieurs champs sont présents dans l'entête.

L'entête comprend les identifiants des différents nœuds acteurs de la communication, le

nombre de sauts possibles avant destruction du message, un critère sur la nature du

message, la date d'envoi et la taille du message (voir Figure 25).

L'identifiant de l'émetteur ID_E correspond au nœud à l'origine du message pour un

destinataire d'identifiant ID_D. Les messages transitent par une succession de couples

de nœuds transmetteur-récepteur d'identifiant ID_T et ID_R.

Le TTL (Time-to-Live) est une valeur initialisée à la création du message et

décrémentée à chaque saut de transmission. Le message est détruit si à sa réception, son

paramètre TTL est nul. Ce fonctionnement a pour but de lutter contre la congestion du

réseau par erreur de routage.

La Critère correspond à la nature du message. Il fait intervenir la notion de priorité et

sera décrite dans le chapitre sur l'ordonnanceur du module de communication.

Le corps de la trame contient les données « utilisateur ». Chaque donnée comprend le

nom de la donnée sur un octet et sa valeur sur quatre autres octets.

De plus, deux octets identifiant les trames de l'application en début de trame et un

checksum en fin de trame ne figurant pas dans la structure sont transmis.

La taille maximale d'une trame est fixée à 100 octets équivalant à la taille maximale du

buffer d'entrée de la puce XBeePro.

Figure 25 : Structure d'une trame

CemOA

: archive

ouverte

d'Irstea

Le fichier usart.c réalise les envois et les réceptions. Les fonctions atomiques utilisées

sont l'envoi d'un octet par appel de fonction et la réception d'un octet par interruption.

L'envoi d'une trame s'effectue par l'envoi successif des octets de la trame. Avant l'envoi

du premier octet, la valeur du checksum est initialisée à zéro, puis, après chaque envoi,

le checksum est calculé en réalisant un « ou-exclusif » entre sa valeur précédente et la

valeur transmise. La fonction d'interruption qui accuse la réception d'un octet, rend

compte également du décodage et de la vérification du checksum des trames. Le

décodage est réalisé à l'aide d'une machine d'états qui évolue à chaque réception d'octet

(voir Figure 26). Le temps passé dans cette fonction d'interruption est court. À chaque

état de la machine, la sauvegarde de l'octet reçu et un calcul du checksum intermédiaire

sont exécutés.

Figure 26 : Machine d'état de la fonction de réception

Une fois qu'une trame est reconnue correcte, elle est sauvegardée en attendant sa lecture

par une autre fonction. La taille mémoire étant limitée, seules les trois dernières trames

de chaque USART sont conservées. L'interface avec la couche supérieure se fait avec

deux fonctions : la fonction d'envoi et la fonction de réception d'une trame.

Le fichier ordonnanceur.c organise l'envoi des messages selon la stratégie expliquée

dans le chapitre suivant « Ordonnanceur du module de communication ». L'interface

avec la couche supérieure se fait avec deux fonctions : la fonction d’insertion et la

fonction de lecture d'une trame.

Le fichier routage.c est actuellement minimaliste. Les trames sont redirigées en fonction

de ID_D. Dans notre application les ordinateurs « PC » avec le logiciel AROCCAM ont

également un identifiant. Le routage se fait avec des identifiants connus d'avance afin de

réaliser des tests. Une version plus complexe avec l'utilisation de protocole routage

CemOA

: archive

ouverte

d'Irstea

32

CIVIC sera à développer pour assurer le fonctionnement d'un réseau ad hoc fortement

mobile.

Figure 27 : Identifiant des différends nœuds

Le fichier QoS.c calcule les paramètres utiles à l'ordonnanceur pour prendre ses

décisions. Le nombre total d'octets, le nombre d'octets d'erreur et le nombre des nœuds

voisins sont les informations nécessaires aux calculs. Ces relevés sont réalisés toutes les

secondes.

IV.2 Ordonnanceur du module de communication

L'ordonnanceur développé reprend le principe des trois phases présentées dans le

chapitre « Ordonnancement d’envoi de message ». Les messages entrants sont, tout

d'abord, classés selon certains critères, puis sauvegardés dans des files de messages,

pour finalement être sélectionnés et envoyés selon d'autres critères. Différentes idées ont

mené à cette solution. La première est le souhait de pouvoir différencier les messages

importants, urgents et normaux. La deuxième est de pouvoir utiliser l'ordonnanceur

comme régulateur de bande passante pour assurer la qualité de service. La dernière est

de réaliser un ordonnanceur suffisamment générique pour être utilisé pour d'autres

applications que la communication entre véhicules.

Les notions d'importance et d'urgence pour un message se retrouvent dans d’autres

applications comme la surveillance médicale. L'urgence fait référence au besoin

d'arriver rapidement. Tandis que la notion d'importance fait référence à la nécessité

d'arriver. Dans un premier temps, nous considérons donc qu'il est acceptable qu’un

message urgent soit perdu. L'hypothèse est, que s'il arrive en retard, alors l'information

est tout de même perdue car le message est obsolète. Il est également acceptable qu'un

message important mette du temps pour arriver voire qu'il reste bloqué et sauvegardé

pour être transmis plus tard. De plus, la notion de priorité reste valable pour les trois

types de messages, (urgents, importants et normaux). Des problèmes apparaissent

lorsqu'on considère le couple type et priorité du message. Ceci ressort également avec le

choix entre l'envoi d’un message normal avec une priorité maximale et l'envoi d’un

message urgent avec la priorité la plus faible. Il est possible alors de voir la priorité

comme une pondération entre types. Afin de simplifier la phase de classement, nous

utilisons des priorités restreintes à chaque type normal. Il devient possible de

caractériser les types et les priorités avec un seul critère correspondant au champ dédié

dans nos trames. La valeur « 0 » désigne les messages urgents, la valeur « 1 » les

importants et les valeurs de « 2 » à « 7 » la priorité des messages normaux. L'envoi

consiste à toujours envoyer les messages urgents. Dans le cas où il n'y a plus de

messages urgents, le taux d’erreurs mesuré par la qualité de service détermine si les

messages importants peuvent être envoyés. Au-delà d'un certain taux d’erreurs, le risque

de perdre un message est trop élevé, donc seuls les messages normaux pourront être

envoyés. L'ordonnanceur remplit également un rôle contre la congestion du réseau. Les

messages normaux sont majoritaires par rapport aux messages urgents et importants. Ils

sont donc la principale source de congestion, d'autant plus si leurs tailles sont

importantes. L'idée mise en place est de bloquer les messages de plus grande taille en

cas de bande passante faible. Un second classement selon la taille est donc appliqué aux

messages normaux.

IV.3 Expérimentations réalisées et résultats

Des essais de communication entre le LiveNode et l'HyperTerminal de l'ordinateur par

liaison série constituent les premiers tests de la phase de développement du programme

du nœud. Ils ont permis la validation de l'envoi et de la réception de messages par port

série. La communication LiveNode vers ordinateur est tout d'abord testée avec un

message « Hello » (voir Figure 28).

Figure 28 : Résultat d'une communication LiveNode vers Ordinateur

Le test de la communication ordinateur vers LiveNode consiste à faire répondre le

LiveNode. Un message avec une valeur quelconque est envoyé au LiveNode, qui une

fois reçu, renvoie à l'ordinateur un message avec la valeur incrémentée de un.

Figure 29 : Résultat d'une communication Ordinateur vers LiveNode

Les tests pour valider la communication sans fil par puces XBee nécessitent l'utilisation

d'un second nœud. L'envoi et la réception sont également testés avec un message «

Hello » et une réponse à un message. Le nœud relié à l'ordinateur remplit son rôle

définitif de module de communication, tandis que le second nœud joue le rôle émetteur

de message « Hello » ou de réponse.

Des essais similaires ont été faits une fois que l'interface dédiée au logiciel AROCCAM

fut programmée. Une succession d'essais a permis d'estimer une limite de fréquence

d'envoi en fonction du nombre de données.

L'intégralité des modules a été testée avec une application proche de leurs futures

utilisations. Un Ordinateur avec AROCCAM relié à un LiveNode et à un GPS constitue

une plateforme mobile. L'application transmet des données GPS à une fréquence de 2Hz

par le LiveNode au second LiveNode en position fixe. Un numéro de trame est ajouté

afin de comparer les trames envoyées et reçues.

CemOA

: archive

ouverte

d'Irstea