L’intergiciel MWAC

Les applications que nous construisons sont distribuées sur de nombreux agents. Cela nous permet de réduire la complexité de conception. Nos agents, en plus de leur tâches applicatives, embarquent tous un module intergiciel et ce indépendamment de leur architecture (voir figure 8.11).

FIG. 8.11 – Architecture de nos systèmes multi-agents physiques

Il existe alors deux manières de voir l’intergiciel : un composant MWAC et un archétype d’agent MWAC.

Le composant MWAC. L’intergiciel peut être enfoui dans un composant que nous appelons MWAC

(du nom de notre modèle). Nous partageons les entrées/sorties en deux familles : les entrées/sorties lo-giques (à destination de la partie commande de l’agent) et les entrées/sorties bits (à destination des

Conclusion 161

organes d’émission/réception).

Les entrées logiques du composant sont : – l’identifiant de l’agent,

– le niveau d’énergie (entier compris entre 0 et 100), – un couple (destinataire, message à émettre).

La sortie logique du composant sont : – un couple (émetteur, message reçu).

Les entrées au niveau bit du composant sont :

– un flot de bits en entrée (données brutes⁶reçues par le récepteur HF).

Les sorties logiques du composant sont : – un flot de bits en sortie.

Cette implémentation de l’intergiciel permet de faire totalement abstraction du modèle : il conviendra donc particulièrement bien aux entités actives non critiques d’un point de vue énergétique et à la plupart des applications multi-agents et ce indépendamment des architectures de ces derniers.

Un archétype d’agent. Certaines applications critiques (notamment d’un point de vue énergétique)

nécessitent d’avoir accès à des données internes de l’agent comme la liste des voisins ou même de dégra-der les interactions (voir l’application EnvSys, §9.1). Pour les applications nécessitant plus de flexibilité de ce point de vue, nous proposons un archétype d’agent. Cet archétype d’agent est basé sur l’architec-ture eASTRO (cf §5.4.4). Pour chacun des modules de cette architecl’architec-ture, des éléments du modèle sont instanciés. Par exemple, le module de représentation du monde contiendra d’office les données sur les autres et sur soi. La mise en oeuvre d’un tel intergiciel est abordé dans l’application EnvSys.

8.5 Conclusion

Nous avons proposé un modèle basé sur l’auto-organisation pour permettre une gestion efficace des communications dans un réseau sans fil soumis à des contraintes énergétiques. La structure de base de notre organisation est un groupe mettant en jeu trois différents rôles : les représentants qui gèrent les com-munications au niveau du groupe, les agents de liaison qui permettent les comcom-munications entre groupes et les simples-membres qui ne jouent aucun rôle actif dans l’acheminement des messages. Le mécanisme utilisé est basé sur l’attribution de rôle. Cependant, l’écoute indiscrète est utilisé par les agents pour vé-rifier leurs croyances sur leur environnement.

L’auto-organisation permet l’ajout ou la suppression d’éléments sans nécessiter de reconfiguration manuelle. Les capacités adaptatives de l’auto-organisation permettent une tolérance aux pannes: le dys-fonctionnement d’une des entités ne nuit pas à l’intégrité de notre système. Notre phase de simulation nous a permis de comparer notre approche multi-agents par rapport à des approches classiques.

Les agents présentent des caractéristiques intéressantes en terme d’ingénierie logicielle comme la gé-néricité qui permet une évolution facile de l’application. La solution a d’ailleurs été adaptée en intergiciel par envoi de messages exploitable sous la forme d’un composant ou d’un archétype d’agent.

Conclusion

La troisième partie de ce mémoire a abordée le point dur principal en terme de modèle dans la catégorie de systèmes visés par la méthode DIAMOND : celui du maintien d’intégrité fonctionnelle et de la communication dans un réseau ouvert d’entités physiques. Le sans fil est la traduction physique extrême de la décentralisation. Ce point concerne donc essentiellement l’intégration dans les agents d’aspects relevant de l’interaction et de l’organisation.

Dans un premier chapitre, nous avons introduit un domaine de recherche très actif, celui des réseaux sans fil et plus particulièrement le routage dans les réseaux ad-hoc. Nous avons présenté une revue des protocoles de routage, solution proposée par la communauté des réseaux.

Dans un second chapitre, nous avons présenté les deux grands courant de maintien d’intégrité fonc-tionnelle en informatique : la réplication de services et l’auto-organisation. Nous avons insisté sur cette dernière car elle est la seule applicable au contexte du routage.

Dans le troisième chapitre nous présentons notre solution pour la gestion des communications dans les systèmes complexes physiques. Notre modèle n’est pas basé sur un protocole de routage mais par une infra-structure dont une des fonctions est cette gestion du routage. Ce modèle est le coeur d’un intergiciel.

TAB. 8.1 – Appréciation de notre approche selon les critères de la RFC 2501 Critère Appréciations

Taille du réseau Notre modèle supporte bien le passage à l’échelle (à moduler par la non opti-malité des routes)

Connectivité du réseau Les noeuds supportent un grand nombre de voisins. En fait, plus le nombres de voisins est élevé plus l’approche par auto-organisation est intéressante. Taux de changement

de topologie et mobi-lité

Ce critère est toujours difficile à apprécier. Les changements de topologie d’au-tant mieux tolérés que le nombre d’échanges de messages est élevé (consé-quence de l’écoute indiscrète). Un changement de topologie localisé n’a au-cune conséquence sur les autres noeuds.

Capacité des liaisons Ce critère est dépendant de la couche physique et donc de l’implémentation. Taux de liaisons

unidi-rectionnelles

En présence de liaisons unidirectionnelles l’agent ayant la plus faible portée sera simple membre

Type de trafic En cas d’un système à trafic non uniforme, la cohérence de l’organisation n’est pas maintenue.

Ratio et fréquence des périodes de sommeil des noeuds

Ce critère est dépendant de la couche physique et donc de l’implémentation.

164 Conclusion

Le modèle MWAC et son intergiciel associé vont nous permettre de faire abstraction de la gestion des communications dans les systèmes complexes physiques ouverts que nous souhaitons modéliser. Nous présentons, pour conclure, un tableau récapitulatif de l’adéquation entre notre approche et certaines caractéristiques de problèmes selon la RFC⁷2501.

7. Les RFC (Request For Comment) sont des documents publiés par l’IETF (Internet Engineering Task Force) qui décrivent, spécifient, aident à l’implémentation, standardisent et débattent de la majorité des normes, standards, technologies et protocoles liés à Internet et aux réseaux en général.

165

quatrième partie

Introduction

Ce partie est consacrée à une application qui met en oeuvre la méthode DIAMOND et une utilisation du modèle MWAC.

Le premier chapitre de cette partie commence par présenter le projet EnvSys qui a pour but l’mentation d’un réseau hydrographique souterrain. Les objectifs et la problématique d’une telle instru-mentation sont abordés. Il présente ensuite l’analyse du problème selon la méthode DIAMOND.

Dans un second chapitre, nous présentons la plate-forme de simulation qui nous a permis d’évaluer les performances attendues de notre solution. Nous introduisons aussi l’implémentation des agents (plate-forme cible et organisation du code).

169

Chapitre 9

Application à l’instrumentation sans fil :

gestion d’un réseau de capteurs sans fil

Ce chapitre présente l’application de notre méthode et de notre modèle de communication pour les réseaux sans fil dans le cadre du projet EnvSys (Environment System). Dans une première section nous introduisons ce projet d’instrumentation non filaire d’un réseau hydrographique souterrain. Dans une deuxième section nous présentons le traitement du problème avec la méthode DIAMOND.