Implantation des protocoles de communication FIPA dans la plate forme GAMA

Abstraction des protocoles d’interaction Figure 5 - Les protocoles d’interaction de FIPA implémentés dans GAMA La classe abstraite FIPAProtocol définit une méthode qui sert à vérifier s

L’Institut de la Francophonie pour

l’Informatique

L’unité de recherche Geodes, Institut de Recherche pour le Développement (UR079, IRD)

Master INTELLIGENCE ARTIFICIELLE ET MULTIMEDIA,

Année universitaire 2006 – 2008

Implantation des protocoles de communication

FIPA dans la plate-forme GAMA

Mémoire présenté par

VO Duc An

Stage effectué à l’UR079, IRD Bondy et au laboratoire MSI, IFI

Directeur : Alexis DROGOUL – Directeur de Recherche, UR079, IRD

HaNoi, Septembre 2008.

L’Institut de la Francophonie pour

l’Informatique

L’unité de recherche Geodes, Institut de Recherche pour le Développement (UR079, IRD)

Master INTELLIGENCE ARTIFICIELLE ET MULTIMEDIA,

Année universitaire 2006 – 2008

Implantation des protocoles de communication

FIPA dans la plate-forme GAMA

Mémoire présenté par

VO Duc An

Stage effectué à l’UR079, IRD Bondy et au laboratoire MSI, IFI

Directeur : Alexis DROGOUL – Directeur de Recherche, UR079, IRD

HaNoi, Septembre 2008

Remerciements

Je tiens à remercier tout particulièrement Alexis DROGOUL pour m’avoir encadré ces six mois En fait, j’ai de la chance de travailler sous la direction de Alexis DROGOUL dans le projet GAMA depuis plus d’un an Il est un professeur extraordinaire Je le remercie pour son amitié, sa patience avec mes questions souvent stupides, son encouragement, son soutien, et la liberté de recherche qu’il a bien voulu me laisser Les moments ó il m’a aidé à faire le debug sur Eclipse sont des moments inoubliables pour moi

Je remercie Quang de son amitié, son encouragement et son soutien tout au long de ce travail Je le remercie pour son aide à Bondy ainsi qu’à MSI Je lui souhaite tout le succès pour sa thèse

Je remercie François Sempé d’avoir accepté de rapporter sur ce travail

Je remercie Minh Thu, Khanh, Edouard et Doanh pour leur amitié, leur aide pour le temps à MSI

Je remercie chaleureusement mes camarades de la promotion XII pour leur amitié sans faille et leur souhaite bonne chance pour la soutenance

Je remercie les professeurs de l’IFI pour leurs aides pendant ces derniers trois ans à IFI Enfin, je remercie mes parents pour leur soutien et leur encouragement à tout instant Je leurs dédie ce travail

Tableaux des matières

I Introduction 6

II Problème actuel et les protocoles d’interaction de FIPA 7

II.1 Problème actuel de la communication dans GAMA 7

II.2 Les protocoles d’interaction de FIPA 8

II.2.1 Message FIPA ACL 9

II.2.2 Protocole d’interaction « FIPA Request » 9

III L’implémentation des protocoles d’interaction de FIPA dans GAMA 11

III.1 Diagramme de classe 11

III.2 Structure d’un « Message » 12

III.3 Abstraction des protocoles d’interaction 13

III.4 Mécanisme d’envoi et de réception d’un message 16

III.5 Vérification d’un message avec le protocole d’interaction employé 17

III.6 Langage GAML 18

III.6.1 Les primitifs, les variables, les objets d’un agent communicant 18

III.6.2 Exemple de GAML 21

IV Validation dans le modèle « fourmis » 25

IV.1 Le modèle « fourmis » original 25

IV.2 Le modèle « fourmis » avec la communication 27

IV.2.1 Fonctionnement du modèle 27

IV.2.2 La communication entre les agents 29

IV.2.3 Le fonctionnement du nouveau modèle dans GAMA 31

IV.3 Commentaire sur le fonctionnement de deux versions de « fourmis » 31

V Validation dans le modèle « AROUND » 33

V.1 Modèle AROUND original 33

V.2 Modèle AROUND avec la communication 35

V.3 Commentaire sur le fonctionnement de deux versions de « AROUND » 43

VI Conclusion et perspectives 48

Bibliographie 50

Annexe 51

Annexe A – Code source du modèle « fourmis » avec la communication 51

Annexe B – Code source du modèle AROUND avec la communication 59

Tableau des figures

Figure 1 - L’architecture d’une plate-forme d’agent proposée par FIPA 8

Figure 2 - Protocole d’interaction « FIPA Request » 10

Figure 3 - Les classes principales de l’implémentation 11

Figure 4 - Structure d’un message 12

Figure 5 - Les protocoles d’interaction de FIPA implémentés dans GAMA 13

Figure 6 - Modélisation d’un protocole d’interaction 13

Figure 7 - Protocole d’interaction FIPA Request 15

Figure 8 - Itinéraire d’un message de l’envoyeur au récepteur 16

Figure 9 - Un message respecte le protocole d’interaction employé 17

Figure 10 - Un message ne respecte pas le protocole d’interaction employé 18

Figure 11 - Protocole d’interaction FIPA Request 22

Figure 12 - Le comportement d’une fourmi dans le modèle « fourmis » original 25

Figure 13 - Le modèle « fourmis » original 26

Figure 14 - Le comportement d’un « foodFinder » 28

Figure 15 - Le comportement d’un « foodCarrier » 28

Figure 16 - Protocole « FIPA Contract Net » dans le modèle « fourmis » 29

Figure 17 - Protocole « No Protocol » entre foodCarrier et foodFinder 30

Figure 18 - Modèle « fourmis » avec la communication dans GAMA 31

Figure 19 - Deux ambulances vont prendre une même victime 34

Figure 20 - Relation entre military et explorer 36

Figure 21 - Procotole d’Interaction FIPA Request entre military et explorer 36

Figure 22 - Protocole d’Interaction « No Protocol » entre explorer et military 37

Figure 23 - Relation entre military et fireman 37

Figure 24 - Protocole d’Interaction FIPA Request entre military et fireman 38

Figure 25 - Protocole d’Interaction FIPA Request entre military et hospital 39

Figure 26 - Protocole d’Interaction « No Protocol » entre military et hospital 39

Figure 27 - Relation entre hospital et ambulance 40

Figure 28 - Protocole d’Interaction FIPA Request entre ambulance et hospital 40

Figure 29 - Protocole d’Interaction « No Protocol » entre les hôpitaux 41

Figure 30 - Protocole d’Interaction « No Protocol » entre hospital et ambulance 41

Figure 31 - Protocole d’Interaction FIPA Request entre hospital et ambulance 42

Figure 32 - Protocole d’Interaction FIPA Request When entre hospital et ambulance 43

Figure 33 – Repartition des ambulances dans la version originale 44

Figure 34 – Repartition des ambulances dans la nouvelle version 45

Figure 35 - Repartition des voitures des pompiers dans la version originale 46

Figure 36 - Repartition des voitures des pompiers dans la nouvelle version 47

I Introduction

GAMA (GIS & Agent-based Modelling Architecture) est une plateforme générique pour

la modélisation et simulation orientée agent GAMA est actuellement développée au sein

du laboratoire MSI et est financée principalement par l’IRD Ce projet regroupe plusieurs partenaires : IFI, IRD, CIRAD, EDF

Le développement de cette plateforme est en parallèle avec l’implémentation de plusieurs modèles complexes qui appartiennent à différents domaines La diversité des modèles développés nous aide à vérifier la généralité de la plateforme et l’assurer d’une part Elle sert également à découvrir les fonctionnalités manquantes de la plateforme d’autre part

En observant le déroulement de la simulation de quelques modèles, nous avons fait le constat qu’il n’existe pas encore actuellement de mécanisme de communication standardisé entre les agents dans GAMA En raison de cette absence, le fonctionnement

de ces modèles peut ne pas être réaliste, n’est pas efficace et parfois n’est pas correct Sans un mécanisme de communication, il n’est par exemple pas possible ou difficile pour les modélisateurs d’implémenter de mécanismes de coordination entre les agents

Ce stage de fin d’étude a donc pour but d’implémenter des protocoles de communication dans GAMA et de valider le fonctionnement de ces protocoles en les utilisant dans quelques modèles existants

Ce rapport présente le travail réalisé au cours du stage Il se compose de six parties Cette première partie donne une présentation générale du stage La deuxième partie introduit le problématique : la nécessité d’introduire des protocoles d’interaction dans GAMA Dans

la troisième partie, l’implémentation de ces protocoles dans GAMA est détaillée Les quatrième et cinqième parties présentent la validation du travail réalisé Dans la quatrième partie, une implémentation des protocoles d’interaction dans un modèle simple est présentée Puis une implémentation de ces protocoles d’interaction dans un modèle complexe est le contenu de la cinqième partie Ce rapport se termine avec une partie de conclusion et perspectives

II Problème actuel et les protocoles d’interaction de

FIPA

II.1 Problème actuel de la communication dans GAMA

Comme nous l’avons souligné au-dessus, actuellement, GAMA ne fournit pas encore de capacité pour modéliser une « vraie » communication entre des agents Les deux mécanismes existants, la communication par signal et la commande « ask », sont en effet très limités

Avec la communication par signal, un agent est capable de transférer des informations dans son environnement Après quoi, d’autres agents peuvent les lire puis réagir de façon appropriée Comme un signal est transféré par l’environnement, tous les autres agents peuvent le percevoir Dans le cas ó un agent A veut communiquer seulement avec un agent B, cela peut poser un problème : si A veut que les informations transférées ne soient visibles que par B, il n’y a aucun moyen pour lui de le préciser L’utilisation du signal n’est pas donc convenable dans ce cas De plus, la communication par signal est couteuse en temps de calcul quand le rayon du signal est grand

Dans GAMA, on peut également utiliser l’appel « ask » pour demander à un agent (ou à des agents) d’exécuter du code Cette commande est équivalente à l’envoi de messages entre objets On peut donc l’utiliser pour simuler le processus de l’envoi et de la réception

de messages entre les agents

Mais il n’est pas possible de modéliser un processus de négociation avec la commande

« ask » Plus précisément, l’agent A peut utiliser un « ask » pour demander à l’agent B à faire quelque chose, mais il n’y a aucune possibilité pour l’agent B de refuser de le faire,

et, de plus, aucune possibilité pour B d’informer A de ce refus Et si B exécute la demande de A, rien n’est prévu dans le langage GAML (langage de modélisation de GAMA) pour que B informe A du résultat Enfin, si B exécute l’action demandée par A, mais que l’exécution de cette action n’est pas réussie, aucun mécanisme n’est disponible pour prévenir A

Une autre nécessité est la capacité de coordination et de négociation entre des agents Considérons un exemple inspiré par le protocole Contract Net Supposons que l’on a deux types d’agent Un agent qui joue le rơle d’un gestionnaire Plusieurs autres agents qui jouent le rơle des participants Le gestionnaire souhaite faire effectuer une certaine tâche par un des participants

Le gestionnaire sollicite des propositions de m autres participants en publiant un appel d’offres (call for proposals, ou cfp en anglais) Cet appel spécifie la tâche, ainsi que toutes les condition que le gestionnaire souhaite placer sur l’exécution de cette tâche (temps minimum d’exécution, qualité de la réalisation, etc.) Les participants recevant cet appel d’offres sont considérés comme des « entrepreneurs » Parmi les m participants, j participants (j <= m) acceptent la sollicitation du gestionnaire en envoyant des offres au gestionnaire Et i participants (i = m – j) la refusent En recevant j appels d’offre de j participants, le gestionnaire choisit le participant le plus convenable pour exécuter la tâche Actuellement, il n’est pas possible de modéliser un scénario comme celui-ci dans GAMA, alors qu’il est pourtant très utile dans un environnement multi-agent (ó les

agents ne sont pas forcément tous égaux en terme de capacité, et pas forcément tous disponibles pour réaliser une tâche)

En implémentant différents modèles classiques des SMA, nous percevons qu’il existe bien des cas dans lesquels la coordination entre les agents joue un rôle vital Sans une bonne coordination et la capacité de négociation, le fonctionnement de tels modèles n’est pas efficace et parfois n’est pas correct

Donc il est nécessaire d’avoir un vrai mécanisme de communication dans GAMA Ce mécanisme devra nous aider à modéliser la communication, la négociation et la coordination entre les agents En plus, il devra fournir aux modélisateurs des primitives

de haut-niveau pour manipuler les protocoles de communications et traiter les messages

de façon confortable

II.2 Les protocoles d’interaction de FIPA

FIPA (Foundation of Intelligent Physical Agents) est un membre de l’IEEE Cette

organisation a pour objectif de standardiser le développement des technologies orientées agent Elle propose des normes et des spécifications pour l’interaction entre agents et pour les systèmes orientés agent Les spécifications de FIPA sont classées dans les catégories suivantes : communication entre agents, gestion des agents, transport d’agents, architecture abstraite des applications orientées agent Ces spécifications jouent un rôle d’indications pour la conception et le développement des applications orientées agent Elles aident aussi à augmenter l’interopérabilité entre ces applications La figure 1 est l’architecture d’une plate-forme d’agent proposée par FIPA

Figure 1 - L’architecture d’une plate-forme d’agent proposée par FIPA

On voit que cette plate-forme se divise en plusieurs sous-systèmes comme : Agent, Agent Management System, Directory Facilitator, Message Transport System Pour chacun de ces sous-systèmes, FIPA fournit plusieurs spécifications qui le décrivent

Parmi les spécifications de FIPA, nous nous intéressons aux spécifications qui concernent

la communication d’agent Ces spécifications définissent les protocoles d’interaction entre les agents Les protocoles d’interaction de FIPA sont des protocoles éprouvés pour

la communication d’agent Ils sont déjà implémentés dans quelques plate-formes d’agent comme JADE, FIPA-OS,…

Un protocole d’interaction est en fait une série de messages échangés entre des participants La spécification du protocole stipule l’ordre des messages que les participants doivent respecter Les protocoles d’interaction caractérisent différents scénarios de la communication En se basant sur chaque situation concrète, le modélisateur emploie le protocole approprié

Les protocoles d’interaction définis par FIPA sont FIPA Request, FIPA Query, FIPA Request When, FIPA Contract Net, FIPA Interated Contract Net, FIPA Brokering, FIPA Recruiting, FIPA Subscribe, FIPA Propose

Nous allons présenter en détail le protocole d’interaction « FIPA Request » Pour le détail des autres protocoles, vous pouvez suivre le lien de FIPA donné dans la section bibliographie

Mais pour faciliter la présentation du protocole « FIPA Request », nous regardons maintenant la notion Message de FIPA

II.2.1 Message FIPA ACL

Les agents réalisent des actions de communication en envoyant des messages et en les recevant FIPA définit plusieurs attributs qu’un message doit posséder Les plateformes d’agent qui implémentent la spécification de FIPA ne sont pas obligées d’implémenter tous les attributs définis L’auteur de la plateforme peut choisir les attributs qui sont considérés comme convenable pour sa plateforme

Voici quelques attributs de message définis par FIPA :

• Sender : cet attribut indique l’envoyeur du message

• Receiver : cet attribut contient le nom (les noms) d’un (des) récepteur(s) de

message

• Performative : cet attribut fait savoir le type de message Normalement, la valeur

de cet attribut donne une signification au message FIPA définit une série de performatifs avec les significations correspondantes Si vous vous intéressez, vous pouvez suivre le lien du document « FIPA Communicative Act Library Specification » qui se trouve dans la section bibliographie

• Protocol : cet attribut indique le protocole d’interaction que l’envoyeur de

message emploie pour envoyer ce message

• Content : cet attribut contient le contenu du message

• Conversation-id : cet attribut indique la conversation à laquelle ce message

appartient La notion de conversation est utilisée pour représenter le déroulement d’un dialogue entre les agents

II.2.2 Protocole d’interaction « FIPA Request »

Dans cette partie, nous regardons en détail le protocole d’interaction « FIPA Request » de FIPA Ce protocole permet un agent à demander un autre agent à effectuer une certaine action La représentation de ce protocole est donnée dans la figure 2

Figure 2 - Protocole d’interaction « FIPA Request »

Dans un protocole d’interaction, il y a deux types d’agent : l’initiateur (l’agent qui initie

le protocole) et le(s) participant(s) Le déroulement de ce protocole est comme suit :

L’initiateur commence le protocole en envoyant un message avec le performatif

« request » En recevant ce premier message de l’initiateur, le participant peut décider d’accepter la demande ou de la refuser Si le participant refuse la demande, il répond à l’initiateur un message avec le performatif « refuse » et le protocole se termine Si le participant accepte la demande, il communique cet accord à l’initiateur en utilisant un message avec le performatif « agree » Après avoir accepté la demande, le participant effectue l’action demandée Quand le participant termine l’exécution, il informe l’initiateur en envoyant un message avec le performative « inform » Ou bien si l’exécution a échoué, il informe l’initiateur en utilisant un message avec le performatif

« failure »

Dans ce protocole, les messages avec les performatifs « refuse », « failure » ou

« inform » du participant sont considérés comme des messages terminaux Après avoir reçu un de ces messages, le protocole d’interaction (ou bien la conversion correspondante) est donc considéré comme terminé

En se basant sur les spécifications des protocoles d’interaction de FIPA, nous avons réalisé une implémentation de ces spécifications dans GAMA, qui est détaillée dans la section suivante

III L’implémentation des protocoles d’interaction de

FIPA dans GAMA

Comme nous l’avons présenté dans l’introduction, le travail de ce stage se divise en deux parties principales

La première partie a consisté à implémenter les protocoles d’interaction de FIPA dans GAMA Puis, dans la deuxième partie, la validation du fonctionnement de ces protocoles d’interaction a été réalisée Plus précisément, nous utilisons le travail de la première partie pour faire communiquer (et coordonner) des agents dans différents modèles

Dans cette partie, nous présentons l’implémentation des protocoles d’interaction de FIPA dans GAMA

III.1 Diagramme de classe

Premièrement, nous présentons les classes principales de cette implémentation

Figure 3 - Les classes principales de l’implémentation

• Agent : Cette classe est utilisée pour représenter un agent Un agent peut

participer à plusieurs conversations à la fois Il peut jouer le rôle d’un initiateur ou d’un participant d’une conversation

• CommunicatingSkill : Cette classe définit les primitives qui servent à l’envoi et à

la réception des messages Dans GAMA, on utilise la notion de Skill pour représenter une compétence particulière d’un agent Plusieurs classes ont été développées pour implémenter différentes compétences des agents Par exemple, on a la classe CarryingSkill pour implémenter la compétence de porter des agents, la classe MovingSkill pour les compétences de déplacement, etc La classe CommunicatingSkill est donc développée pour la compétence de l’envoi et de la réception des messages Le modélisateur a besoin seulement de déclarer cette compétence pour les agents dans son modèle, et ses agents seront automatiquement dotés de tous les attributs et comportements nécessaires

• IMessage : Cette interface définit les attributs d’un message Elle représente le

morceau d’information transmis entre les agents On va décrire en détail cette classe dans la section qui suit

• FIPAProtocol : Cette classe abstraite représente la notion de protocole

d’interaction de FIPA Elle sert à vérifier si un message respecte la spécification d’un protocole d’interaction de FIPA ou pas On va décrire en détail cette classe et ses sous-classes dans la section qui suit

• Conversation : cette classe représente une conversation/un dialogue entre les

agents Dans une conversation, les agents échangent les informations en envoyant les messages et en les recevant Comme cela a déjà été décrit, il y a deux types d’agent dans une conversation : un initiateur et un/des participant(s) Une conversation est commencée par un initiateur La conversation suit un protocole d’interaction défini par FIPA Cela veut dire que les messages échangés entre l’initiateur et le(s) participant(s) doivent respecter la structure du protocole d’interaction actuellement employé

III.2 Structure d’un « Message »

Figure 4 - Structure d’un message

En se basant sur la spécification de FIPA, nous concevons notre propre classe de messages Dans GAMA, un IMessage représente donc le morceau d’information échangé entre les agents Il se compose des attributs suivants :

• sender : cet attribut détermine l’envoyeur du message

• receivers : c’est une liste qui contient le(s) récepteur(s) du message

• content : c’est une liste qui contient le contenu du message On peut mettre

n’importe quel type de donnée dans cette liste On laisse donc la liberté au modélisateur de manipuler le contenu du message dans son modèle

• performative : cet attribut fait savoir la signification du message FIPA définit une

série de performatifs ainsi que les significations correspondantes Pour plus d’information, vous pouvez suivre le lien de FIPA donné dans la section bibliographie

• conversation : un message appartient à une conversation Une conversation suit

un certain protocole d’interaction Cet attribut et l’attribut « performative » servent donc à vérifier si le message échangé respecte bien le protocole d’interaction actuellement employé

III.3 Abstraction des protocoles d’interaction

Figure 5 - Les protocoles d’interaction de FIPA implémentés dans GAMA

La classe abstraite FIPAProtocol définit une méthode qui sert à vérifier si un message échangé respecte un protocole d’interaction ou pas FIPA fournit les protocoles d’interaction comme : FIPA Request, FIPA Query, FIPA Request When, FIPA Contract Net, FIPA Interated Contract Net, FIPA Brokering, FIPA Subscribe, FIPA Propose Pour chaque protocole, on décrit la structure de ce protocole dans une classe correspondante avec le même nom Dans les classes de la figure ci-dessus, on voit la classe NoProtocol Cette classe est spécifique à GAMA Quand le modélisateur trouve que aucun protocole d’interaction de FIPA n’est convenable pour lui, il peut utiliser le protocole d’interaction NoProtocol Avec ce protocole, on peut envoyer et recevoir n’importe quel message Les performatifs des messages sont libres Mais c’est au modélisateur de terminer manuellement le protocole d’interaction en utilisant le primitif « end » fourni par le CommunicatingSkill

Figure 6 - Modélisation d’un protocole d’interaction

On sait qu’une Conversation suit un protocole d’interaction La classe correspondante a donc une référence à une sous-classe de FIPAProtocol qui détermine le protocole actuellement utilisé Un protocole d’interaction définit la série de messages autorisée

La question qui se pose maintenant est : comment peut-on modéliser la série de messages autorisée par un protocole d’interaction ? Pour le faire, on utilise la notion de ProtocolNode Un ProtocolNode contient les méta-informations d’un message Pour chaque protocole d’interaction, en se basant sur la structure définie dans la classe correspondante du protocole, on construit une liste de ProtocolNode Cette liste contient les informations qui nous permettent de vérifier si un message échangé respecte bien un protocole d’interaction ou pas

Un ProtocolNode se compose donc des attributs suivants :

• performative : cet attribut contient la valeur du performatif autorisé du message

correspondant

• sentByInitiator : cet attribut détermine si le message correspondant est envoyé

par l’initiateur ou par un des participants Si cette valeur est égale à vrai, le message correspondant vient de l’initiateur Sinon, il est envoyé par un des participants

• followingNodes : cette liste contient les ProtocolNodes suivants autorisés par le

protocole d’interaction Si cette liste est vide ou si la valeur de cet attribut est null, le ProtocoleNode actuel est le noeud terminal du protocole Un protocole d’interaction peut avoir plusieurs noeuds terminaux

Pour être plus clair, reconsidérons l’exemple du protocole d’interaction FIPA Request : nous regardons la série de message autorisée par ce protocole dans la figure suivante

Figure 7 - Protocole d’interaction FIPA Request

A partir de la figure 7, on a la liste des ProtocolNodes correspondants

Tableau 1 - Listes des ProtocolNodes de FIPA Request

Notons que l’on a un seul noeud avec le performatif « inform » Dans la spécification de

FIPA, on voit deux nœuds « inform » différents Ils sont « done » et «

inform-result » Mais grâce à notre conception de IMessage, l’attribut contenu du message est

une liste d’objets Cela veut dire que l’on peut mettre n’importe quelle donnée dans le

contenu d’un message, et qu’on peut donc regrouper ces deux nœuds « inform » de FIPA

en un seul nœud pour simplifier sa spécification

A partir de cet exemple, on peut voir que tous les protocoles d’interaction de FIPA

peuvent être modélisés en se basant sur l’approche des ProtocolNodes Si un message

échangé ne respecte pas le protocole d’interaction employé, on lèvera des exceptions On

a les exceptions suivantes (présentées dans la figure 6) :

• GamaException : C’est une exception générique de GAMA Une exception dans

GAMA est une sous-classe directe ou indirecte de cette classe

• CommunicatingException : Cette exception est levée quand il y a une erreur

générique de communication

• ConversationFinishedException : Cette exception est levée quand un message

est échangé dans une conversation déjà terminée Une conversation est considérée comme terminée si un message terminal est échangé Cela veut dire que, après qu’un message terminal est échangé, l’initiateur et le(s) participant(s) ne sont pas autorisés à échanger autres messages Sinon cette exception sera levée

• InvalidConversationException : cette exception est levée quand un message est

échangé dans une conversation qui est différente de l’attribut « conversation » du message

• ProtocolErrorException : cette exception est levée quand le performatif du

message actuel est différent du performatif autorisé par le protocole d’interaction actuellement employé

• UnknownProtocolException : cette exception est levée quand un message

emploie un protocole d’interaction qui n’est pas reconnu par GAMA

III.4 Mécanisme d’envoi et de réception d’un message

Dans cette section, nous regardons l’itinéraire d’un message de l’envoyeur au récepteur Considérons le diagramme de séquence suivant :

Figure 8 - Itinéraire d’un message de l’envoyeur au récepteur

L’envoyeur commence ce processus en demandant à son CommunicatingSkill d’envoyer

un message En recevant la demande de l’envoyeur et toutes les informations nécessaires,

le CommunicatingSkill crée une instance de Message et la met dans la liste des messages

à envoyer de MessageBroker Au cycle suivant de la simulation, le MessageBroker prendra les messages dans la queue d’attente et fera deux choses suivantes avec chaque message :

1 Premièrement, on ajoute le message à la conversation correspondante : Si le message est le premier message d’une conversation, on crée une nouvelle conversation avec le protocole d’interaction déterminé et on met le message dans la nouvelle conversation Si ce n’est pas le premier message, on cherche la conversation correspondante du message et on le met dans la conversation trouvée Le fait d’ajouter un message à une conversation permet de vérifier si le message respecte

bien le protocole employé actuellement ou pas On va détailler ce processus de vérification dans la section qui suit

2 Deuxièmement, on ajoute le message à la liste des messages du récepteur Chaque agent qui est capable de communiquer est doté d’une liste qui joue le rôle d’une boîte aux lettres Cette liste contient les messages de l’agent correspondant qui ne sont pas encore lus Quand un agent lit un message dans sa boîte aux lettres, ce message est supprimé automatiquement par GAMA Un agent communiquant possède aussi une liste de ses conversations actuellement en cours Quand une conversation est terminée, cette conversation et tous les messages correspondants seront aussi supprimés automatiquement par GAMA Le modélisateur n’a donc pas besoin (sauf s’il utilise le protocole NoProtocol) de gérer manuellement les messages Quand un message arrive dans la boîte aux lettres d’un agent, le modélisateur a toute la liberté

de le lire et de traiter le contenu de ce message en implémentant le code GAML correspondant dans son modèle

III.5 Vérification d’un message avec le protocole d’interaction employé

Comme nous l’avons présenté, les classes Conversation, FIPAProtocol, les sous-classes

de FIPAProtocol et ProtocolNode servent à vérifier si un message échangé respecte bien

le protocole d’interaction actuellement employé ou pas Dans cette section, nous regardons comment un message est vérifié par rapport à son protocole d’interaction Nous considérons deux cas différents

Premièrement, le cas dans lequel le message respecte bien le protocole d’interaction employé Ce cas est décrit dans la figure suivante :

Figure 9 - Un message respecte le protocole d’interaction employé

A chaque cycle de la simulation, le moteur de la simulation fait envoyer les messages dans la queue d’attente du MessageBroker Chaque message est ajouté à la conversation correspondante Et la conversation fera une validation du message nouvellement ajouté par rapport au protocole d’interaction que cette conversation suit Plus précisément, elle fait des vérifications suivantes :

• Vérifier le performatif du message par rapport aux performatifs autorisés par le protocole Si le performatif du message n’appartient pas aux performatifs autorisés pour le nœud suivant, un ProtocolErrorException sera levé

• Si c’est le premier message de la conversation, vérifier si le protocole employé est reconnu par GAMA Si le protocole employé n’est pas reconnu par GAMA, un UnknownProtocolException sera levé

• Vérifier si la conversation actuelle est déjà terminée ou pas encore Si un message est échangé dans une conversation déjà terminée, un ProtocolFinishedException sera levé

Si aucune exception n’est levée, le message sera ajouté à la conversation correspondante

et à la boỵte aux lettres du récepteur Si un des exceptions ci-dessus est levé, on aura le cas décrit dans la figure suivant

Figure 10 - Un message ne respecte pas le protocole d’interaction employé

III.6 Langage GAML

GAML (GAMA Modelling Language) est un langage qui sert à écrire les modèles dans

GAMA C’est un langage spécifique au domaine du multi-agent et de la modélisation, ó tout est prévu pour simplifier le travail d’un modélisateur On utilise GAML pour modéliser les comportements des agents La syntaxe de GAML s’appuie sur une structure

en XML Alexis DROGOUL, responsable de ce stage, se charge de réaliser la conception et le développement de ce langage Le développement de GAML se divise en deux tâches principales Premièrement, écrire un compilateur Deuxièmement, définir la syntaxe du langage

Dans ce rapport, nous ne présentons pas le détail de GAML Si vous vous intéressez à ce langage, il existe un tutoriel détaillé sur le site web de GAMA Nous nous concentrons plutơt sur le sujet du stage : la communication entre agents Nous présentons donc dans

la section suivante seulement les primitifs, les variables et les objets qu’un agent est doté quand il est déclaré comme capable de faire la communication

III.6.1 Les primitifs, les variables, les objets d’un agent communicant

Quand le modélisateur déclare que son agent est capable de faire la communication, son agent est automatiquement doté des primitifs, des variables et des objets dans la classe CommunicationSkill Concernant la syntaxe détaillée de GAML pour la déclaration de la

compétence de communication des agents, vous pouvez regarder le tutoriel en ligne qui

se trouve sur le site web de GAMA

III.6.1.1 Les primitifs

En ce qui concerne les primitifs, nous avons fournit les primitifs qui aident les agents à envoyer et répondre les messages Les primitifs de communication se divisent en deux catégories : les primitifs de base et les primitifs de haut-niveau

Deux primitifs de base sont send et reply Ces deux primitifs servent respectivement à

envoyer et répondre les messages

Les primitifs de haut-niveau sont agree, cancel, cfp, end, failure, inform, propose, query, refuse, rejectProposal, request, subscribe Comme vous voyez, le nom de ces

primitifs est identique avec le nom des performatifs définits par FIPA Si vous vous intéressez aux spécifications détaillées des performatifs de FIPA, vous pouvez suivre le lien du document « FIPA Communicative Act Library Specification » qui se trouve dans

la section bibliographie Un primitif de haut-niveau est utilisé pour répondre à un message L’intérêt de ces primitifs est que le modélisateur ne doit pas fournir la valeur du performatif du message répondu Cette valeur est remplie automatiquement en se basant sur le nom du primitif correspondant Tous ces primitifs de haut-niveau ont deux

arguments : message et content message est le message à répondre et est un argument obligatoire L’envoyeur de l’argument message joue le rôle du récepteur du message répondu content est le contenu du message répondu et est un argument facultatif

Primitif « send »

Ce primitif est employé pour envoyer un message Les arguments de ce primitif sont comme suit :

1 message non Le message à envoyer

2 receivers oui Le(s) récepteur(s) du message

3 content non Le contenu du message

4 performative oui Le performatif du message

5 protocol Le protocole d’interaction que la conversation de ce

message suit Si le message à envoyer est le premier message d’un protocole d’interaction, le modélisateur doit fournir cet argument Ca sert à créer une nouvelle conversation avec le protocole d’interaction correspondant Sinon, le modélisateur ne fournit pas cet argument Cet argument et l’argument

« conversation » sont exclusifs

6 conversation La conversation que ce message appartient Si le

message à envoyer n’est pas le premier message d’une conversation, le modélisateur doit fournir cet argument Ca sert à ajouter le message correspondant

à la bonne conversation Sinon, le modélisateur ne

fournit pas cet argument Cet argument est l’argument

« protocol » sont exclusifs

Tableau 2 – Les arguments du primitif « send »

Primitive « reply »

Ce primitif est employé pour répondre à un message Les arguments de ce primitif sont comme suit :

1 message oui Le message à répondre

2 performative oui Le performatif du message répondu

3 content non Le contenu du message répondu

Tableau 3 – Les arguments du primitif « reply »

Les primitifs de haut-niveau

1 agree Répondre un message avec le primitif « agree »

2 cancel Répondre un message avec le primitif « cancel »

3 cfp Répondre un message avec le primitif « cfp »

4 end Répondre un message avec le primitif « end »

5 failure Répondre un message avec le primitif « failure »

6 inform Répondre un message avec le primitif « inform »

7 propose Répondre un message avec le primitif « propose »

8 query Répondre un message avec le primitif « query »

9 refuse Répondre un message avec le primitif « refuse »

10 rejectProposal Répondre un message avec le primitif « reject-proposal »

11 request Répondre un message avec le primitif « request »

12 subscribe Répondre un message avec le primitif « subscribe »

Tableau 4 – Les primitifs de haut-niveau

III.6.1.2 Les variables

A côté des primitifs présenté ci-dessus, un agent communicant possède quelques variables supplémentaires Ces variables sont les listes des messages recus d’un agent communicant L’intérêt de ces variables est que à partir du code GAML du modèle, le modélisateur peut récupérer les messages dans la boîte aux lettres de l’agent de façon simple

Ces variables sont présentés dans le tableau suivant :

1 acceptProposals Une liste des messages avec le performatif « accept-proposal » de

l’agent correspondant

2 agrees Une liste des messages avec le performatif « agree » de l’agent

Tableau 5 – Les variables d’un agent communicant

III.6.1.3 Les objets

En plus des primitifs et des variables, un agent communicant est doté automatiquement deux types : message et conversation Cela veut dire que le modélisateur peut manipuler les objets de ces deux types dans le code GAML de son modèle Ou bien il peut utiliser les primitifs fournis par ces deux objets et accéder aux variables de ces deux objets

III.6.2 Exemple de GAML

Dans cette section, nous vous présentons un exemple GAML Nous avons implémenté une dizaine de protocole d’interaction de FIPA dans GAMA Mais par manque de place, nous présentons ici seulement le protocole d’interaction « FIPA Request » L’intérêt de cet exemple est seulement de montrer l’utilisation de quelques primitifs de communication présenté ci-dessus Nous n’avons pas ambitieux de présenter tous les aspects du langage GAML Nous ne présentons pas donc un modèle complet (seulement quelques fragments du code GAML concernant la communication)

Reconsidérons le protocole d’interaction « FIPA Request » dans la figure ci-dessous :

Figure 11 - Protocole d’interaction FIPA Request

Supposons que l’on a deux agents qui s’appellent « initiator » et « participant » respectivement Ils participent à une conversation qui emploie le protocole d’interaction

« FIPA Request » L’agent « initiator » joue le rôle de l’initiateur du protocole L’agent

« participant » joue le rôle du participant du protocole

Nous considérons les scénarios suivants du protocole « FIPA Request » :

1 Scénario 1 : L’agent « initiator » demande à l’agent « participant » de faire quelque chose mais l’agent « participant » refuse la demande

2 Scénario 2 : L’agent « initiator » demande à l’agent « participant » de faire quelque chose L’agent « participant » accepte la demande mais l’exécution de l’action demandée échoue

3 Scénario 3 : L’agent « initiator » demande à l’agent « participant » de faire quelque chose L’agent « participant » accepte la demande et l’exécution de l’action demandée se termine avec succès

Ensuite, nous allons présenter le code source GAML de chaque scénario avec les explications correspondantes

III.6.2.1 Scénario 1

• L’agent « initiator » envoie une demande à l’agent « participant »

< do action ="send">

< arg name ="receivers" value ="[participant]" />

< arg name ="protocol" value ="'fipa-request'" />

< arg name ="performative" value ="'request'" />

< arg name ="content" value ="['aller dormir']" />

</ do >

L’agent « initiator » commence le protocole d’interaction « FIPA Request » en envoyant un message à l’agent « participant » avec le contenu « aller dormir »

Comme vous voyez, le primitif « send » est employé ici Comme c’est le premier

message de la conversation, l’argument « protocol » fait savoir le protocole

d’interaction employé L’argument « receivers » contient une liste des récepteurs Dans ce cas, l’agent « participant » est le seul récepteur du message Le performatif

du message est « request » C’est le performatif initial du protocole d’interaction

« FIPA Request »

• L’agent « participant » refuse la demande

< do action ="refuse">

< arg name ="message" value ="requestFromInitiator"/>

< arg name ="content" value ="['je ne veux pas']" />

</ do >

Supposons que le message « request » envoyé par l’agent « initiator » se trouve dans

la variable « requestFromInitiator » L’agent « participant » refuse donc la demande

de « initiator » en répondant un message avec le contenu « je ne veux pas » Le primitif « refuse » est employé Un message avec le performatif « refuse » est donc

envoyé par l’agent « participant » C’est un message terminal du protocole d’interaction « FIPA Request », la conversation correspondante entre l’agent

« initiator » et l’agent « participant » se termine

III.6.2.2 Scénario 2

• L’agent « initiator » envoie une demande à l’agent « participant » en utilisant le

prmitif « send » avec les arguments nécessaire

< do action ="send">

< arg name ="receivers" value ="[participant]" />

< arg name ="protocol" value ="'fipa-request'" />

< arg name ="performative" value ="'request'" />

< arg name ="content" value ="['aller dormir']" />

</ do >

• L’agent « participant » accepte la demande

< do action ="agree">

< arg name ="message" value ="requestFromInitiator"/>

< arg name ="content" value ="['je vais le faire']" />

</ do >

En recevant la demande de l’agent « initiator », l’agent « participant » accepte la demande en répondant à l’agent « initiator » un message avec le performative

« agree » Le primitif « agree » est utilisé dans ce cas Donc on ne doit pas fournir

l’argument « performative » avec la valeur « agree »

• L’agent « participant » informe l’agent « initiator » que l’exécution de l’action

demandée a échoué « failure » est un des performatifs terminaux de ce protocole,

donc après l’envoi de ce message, la conversation entre l’agent « initiator » et l’agent

« participant » se termine Dans ce cas, le contenu de la réponse contient la raison

d’échec Attention : l’attribut « content » est un argument facultatif Le primitif

« failure » est employé, donc le message une répondu a « failure » comme la valeur

du performatif

< do action ="failure">

< arg name ="message" value ="requestFromInitiator"/>

< arg name ="content" value ="['le lit est en panne']" />

< arg name ="receivers" value ="[participant]" />

< arg name ="protocol" value ="'fipa-request'" />

< arg name ="performative" value ="'request'" />

< arg name ="content" value ="['aller dormir']" />

</ do >

• L’agent « participant » accepte la demande et répond l’initiator un message avec

le performatif « agree » en employant le primitif « agree »

< do action ="agree">

< arg name ="message" value ="requestFromInitiator"/>

< arg name ="content" value ="['je vais le faire']" />

</ do >

• L’agent « participant » informe l’agent « initiator » que l’exécution de l’action demandée se termine avec succès Le primitif « inform » est employé pour faire la réponse

< do action ="inform">

< arg name ="message" value ="requestFromInitiator"/>

< arg name ="content" value ="['je me trouve dans le lit']" />

</ do >

IV Validation dans le modèle « fourmis »

IV.1 Le modèle « fourmis » original

Le modèle « fourmis » original est le résultat du projet MANTA Ce projet est une partie

du travail de la thèse de doctorat de Alexis DROGOUL

Selon Alexis DROGOUL dans [3], « l'objectif du projet MANTA est de concevoir un

modèle multi-agent d'une colonie de fourmis afin d'étudier les mécanismes de

sociogenèse, de création de hiérarchies, de polyéthisme d'âge Les comportements des

fourmis sont exprimés sous la forme de tâches (enchaînements fixes d’actions)

elles-mêmes organisées dans une architecture de sélection d’actions, EMF (EthoModeling

Framework) La communication entre agents utilise la propagation de stimuli dans leur

environnement commun, ces stimuli jouant le double rôle de déclencheurs de

comportements et de guides pour la navigation des agents »

Alexis DROGOUL a re-implémenté dans GAMA une version simplifiée du modèle

original Ce modèle a une seule espèce qui s’appelle « ants » Le comportement de cette

espèce est très simple Il est décrit dans le diagramme suivant :

Figure 12 - Le comportement d’une fourmi dans le modèle « fourmis » original

La signification des variables booléennes est comme suit :

L’explication de ce diagramme est donc comme suit :

• Tant que [(placeActuelleAvoirNourriture = false) and (avoirSignalNourriture = false) and (avoirNourriture = false)], la fourmi se déplace aléatoirement sur

• Tant que [(placeActuelleAvoirNourriture = true) and (avoirNourriture = false)],

la fourmi prend la nourriture

• Tant que [(avoirNourriture = true) and (auNid = false)], la fourmi se déplace

vers son nid et met le signal de la nourriture sur l’environnement

• Tant que [(avoirNourriture = true) and (auNid = true)], la fourmi met la

nourriture sur le nid

Le fonctionnement de ce modèle dans GAMA est montré dans la figure ci-dessous :

Figure 13 - Le modèle « fourmis » original

Dans la figure ci-dessus, on voit les cases qui contiennent la nourriture, les cas qui ont le signal de la nourriture, le nid et les fourmis

On a trois types de fourmis ou bien on voit trois états différents des agents de l’espèce

« ants »

• Les fourmis de type 1 sont les fourmis qui sont en train de se déplacer aléatoirement sur l’environnement

• Les fourmis de type 2 sont les fourmis qui sont en train de suivre le signal de la nourriture

• Les fourmis de type 3 sont les fourmis qui sont en train se déplacer vers son nid et met le signal de la nourriture, ou bien la phéromone de la fourmi, sur l’environnement

L’intensité du signal de la nourriture d’une case est reflétée par la couleur de la case Plus l’intensité du signal d’une case est grande, plus la couleur de la case correspondante est claire

IV.2 Le modèle « fourmis » avec la communication

En se basant sur la version originale du modèle « fourmis » dans GAMA, nous implémentons ce modèle en utilisant des protocoles d’interaction de FIPA Au lieu d’utiliser le signal et l’environnement pour la communication, les agents vont maintenant échanger des messages L’intérêt de ce modèle est seulement de montrer le fonctionnement des protocoles d’interaction de FIPA dans GAMA Bien sûr que les vraies fourmis n’utilisent pas ce mécanisme !

re-IV.2.1 Fonctionnement du modèle

Imaginons que l’on a des « fourmis intelligentes » capables de faire de la communication

en échangeant des messages Dans cette version du modèle, on a deux espèces de fourmis qui s’appellent « foodFinder » et « foodCarrier » respectivement

Les fourmis de l’espèce « foodFinder » se chargent de se déplacer aléatoirement dans l’environnement pour chercher la nourriture Quand elles ont les informations concernant

la nourriture, elles envoient ces informations aux fourmis de l’espèce « foodCarrier » en utilisant les protocoles d’interaction

En recevant les informations envoyées par un « foodFinder », les fourmis de l’espèce

« foodCarrier » se chargent d’aller prendre la nourriture et de la déposer dans le nid

A chaque cycle de la simulation, les agents de l’espèce « foodFinder » et l’espèce

« foodReceiver » font les choses suivantes :

Figure 14 - Le comportement d’un « foodFinder »

Selon la figure ci-dessus, à chaque cycle de la simulation, un foodFinder fait donc deux tâches suivantes :

• « communiquer avec les foodCarriers » : cette tâche sera détaillée dans la section

qui suit

• « se déplacer aléatoirement pour chercher la nourriture » : à chaque cycle de la

simulation, la foodFinder choisit au hasard une case parmi ses huit cases voisins et se déplace dessus Il vérifie si la case actuelle contient de la nourriture Si oui, il envoie cette information aux foodCarriers

Figure 15 - Le comportement d’un « foodCarrier »

Selon la figure ci-dessus, à chaque cycle de la simulation, un foodCarrier fait deux tâches suivantes :

• « communiquer avec les foodFinders » : cette communication sera détaillée dans

la section qui suit

• « aller prendre la nourriture et la déposer dans le nid » : si un foodCarrier a une

information concernant la localisation de la nourriture, il ira la prendre et la déposer dans le nid Si un foodFinder n’a aucune information, il ne bouge pas

IV.2.2 La communication entre les agents

« FIPA Contract Net » et « No Protocol » sont les deux protocoles d’interaction employés pour implémenter la communication entre les foodFinders et les foodCarriers Le choix

de ces deux protocoles est totalement subjectif Ce n’est pas le meilleur choix On peut bien entendu utiliser autre protocole comme « FIPA Request » pour résoudre ce problème

L’implémentation de ces deux protocoles d’interaction dans ce modèle est comme suit :

Figure 16 - Protocole « FIPA Contract Net » dans le modèle « fourmis »

Si une fourmi de l’espèce « foodFinder » a des informations sur les positions qui contiennent la nourriture, elle commence la communication avec les fourmis de l’espèce

« foodCarrier » en employant le protocole d’interaction « FIPA Contract Net » Plus précisément, le foodFinder envoie un message avec le performative « cfp » pour démarrer

un appel d’offres Quand un foodCarrier reçoit un message « cfp », s’il est occupé, il répond avec un message « refuse » Un foodCarrier est considéré comme occupé s’il a déjà envoyé un message « propose » à un foodFinder et s’il n’a pas reçu de message

« reject-proposal » ou s’il a une information sur la position de la nourriture Sinon le foodCarrier répond au foodFinder avec un message « propose » Si tous les foodCarriers répondent avec un « refuse », le protocole d’interaction se termine Et le foodFinder continuera d’envoyer un message « cfp » au cycle suivant de la simulation Si au moins

un foodCarrier répond avec un message « propose », le foodFinder répond au premier message « propose » avec un message « accept-proposal » et refuse tous les autres messages « propose » en envoyant un message « reject-proposal » En recevant un message « reject-proposal » de foodFinder, le foodCarrier correspondant est considéré comme disponible pour autres messages « cfp » En recevant un message « propose » du foodFinder, le foodCarrier lit la position de la nourriture dans le contenu du message et y

va pour prendre la nourriture Quand le foodCarrier trouve que la position envoyée par le foodFinder n’a plus de nourriture, il envoie un message « inform » au foodFinder correspondant pour l’informer ce fait et indiquer qu’il est disponible

Le foodCarrier envoie alors un message « inform » aux autres foodFinders pour faire savoir à ces foodFinders qu’il est disponible Cette fois, le foodCarrier emploie le protocole d’interaction « no-protocol »

Figure 17 - Protocole « No Protocol » entre foodCarrier et foodFinder

En recevant des messages « inform » du protocole d’interaction « No Protocol » des foodFinders, le foodCarrier fait une mise à jours de la liste des foodFinders libres Parce qu’il envoie des messages « cfp » seulement aux foodFinders qu’il considère comme libres

IV.2.3 Le fonctionnement du nouveau modèle dans GAMA

Figure 18 - Modèle « fourmis » avec la communication dans GAMA

Dans la figure ci-dessus, on voit les deux types de fourmi : foodFinder et foodCarrier Nous utilisons les images différentes pour les deux espèces et les différents états de l’agent

1 foodFinder Un agent de l’espèce foodFinder

2 foodCarrier Un agent de l’espèce foodCarrier qui n’a pas

d’information sur la nourriture

3 foodCarrier Un agent de l’espèce foodCarrier qui a

l’information sur la nourriture

4 foodCarrier Un agent de l’espèce foodCarrier qui est en train de

porter la nourriture

Tableau 6 - Les images de fourmi

Nous venons de présenter deux versions du modèle « fourmis » La première version utilise le signal comme mécanisme de communication La deuxième version emploie deux protocoles d’interactions FIPA Contract Net et « No Protocol » pour échanger des messages L’intérêt de la deuxième version est de montrer le fonctionnement des protocoles d’interaction de FIPA dans GAMA dans un modèle simple Dans la section suivante, nous allons présenter le fonctionnement des protocoles d’interaction dans un modèle plus complexe

IV.3 Commentaire sur le fonctionnement de deux versions de

« fourmis »

Le fonctionnement de deux versions du modèle « fourmis » se base sur la communication entre les fourmis La version originale utilise le signal et l’environnement pour faire la

communication Tandis que la nouvelle version emploie les protocoles d’interaction de FIPA pour la communication

Dans la version originale, le signal est employé pour modéliser la phéromone des fourmis La phéromone s’évapore au cours du temps et se diminue en fonction de la distance Si le nombre de fourmi est petit (moins que 10 fourmis par exemple), on ne voit pas la communication et/ou la coordination entre les fourmis Parce que la phéromone mise par une fourmi s’est évapore avant que autres fourmis puissent la percevoir et la suivre Par contre, si le nombre de fourmis est suffisament grand (50 fourmis par exemple), on voit bien la communication et/ou la coordination entre les fourmis Parce que dans ce cas si une fourmi met un signal, la possibilité que ce signal est percu par autres fourmis est plus grande Et la quantité ainsi que l’intensité du signal sur l’environnement augmentent en fonction du nombre de fourmi

Dans la nouvelle version, les protocoles d’interaction FIPA sont employés pour faire la communication Bien entendu que avec ce modèle, l’utilisant du signal est plus réaliste que l’utisation des protocoles d’interaction de FIPA Dans la version originale, en raison

de l’évaporation de phéromone, parfois on perd l’information Avec cette version, la perte d’information n’existe plus

V Validation dans le modèle « AROUND »

V.1 Modèle AROUND original

Ce modèle est développé par CHU Thanh Quang dans sa thèse de doctorat Ce modèle

modélise les activités des secours terrestres après un tremblement de terre Il se compose

des espèces suivantes :

situated), Carrying

2 Un agent de cet espèce

est représenté par un polygone

5 Un agent de cet espèce

est représenté par un polygone

military Situated

Tableau 7 - Les agents du modèle AROUND

• ambulance : un agent de cette espèce représente une ambulance Sa tâche

principale est d’aller prendre les victimes sur le terrain puis de les déposer dans un

hôpital Une ambulance a une capacité qui représente le nombre de victimes qu’elle

peut contenir

• hôpital : un agent de cette espèce représente un hôpital Un hôpital se charge de

prendre et de soigner les victimes déposées par les ambulances

• victime : un agent de cette espèce représente une victime Si une victime est sur le

terrain, son état de santé s’aggrave au cours du temps Si une victime n’est pas prise à

l’heure par une ambulance, elle meurt sur le terrain Si une victime est dans une

ambulance ou dans un hôpital, son état de la santé s’améliore au fur et à mesure

• fireman : un agent de cette espèce représente une voiture de pompiers Elle est

responsable d’aller chercher les incendies et les éteindre Cette espèce a un attribut

qui représente la capacité d’eau de chaque agent La quantité d’eau d’un fireman

diminue au cours du temps quand il éteint un incendie Dès qu’un fireman n’a plus

d’eau, il va à une caserne pour prendre de l’eau

• military : un agent de cette espèce représente une caserne Une caserne est

responsable de fournir de l’eau aux firemen

• fire : un agent de cette espèce représente un incendie Si un incendie n’est pas pris

en charge par des firemen, son intensité augmenté au cours du temps Ou

inversement, l’intensité d’un incendie diminue en fonction du nombre de voitures des pompiers qui sont en train de l’éteindre

Avec le modèle AROUND actuel, la modélisation de certaines situations pose problème Premièrement, quand une ambulance veut aller chercher une victime, elle demande au

« service de recherche de chemin de GAMA » la position d’une victime Ce service renvoie la position de la victime actuellement la plus proche de l’ambulance Il y a cependant des cas ó plusieurs ambulances sont toutes proches d’une même victime Toutes iront donc chercher la même, ce qui n’est pas très efficace, ni très réaliste On a besoin donc d’un mécanisme pour organiser une certaine coordination entre les ambulances

Figure 19 - Deux ambulances vont prendre une même victime

Deuxièmement, le modèle utilise actuellement le signal comme mécanisme de diffusion

de l’information Ca pose quelques problèmes:

• Une ambulance diffuse un signal dans un rayon prédéfini Si une victime se trouve dans ce rayon, elle est considérée comme déjà dans l’ambulance Comme ça, son état de santé est augmenté, ce qui n’est pas très correct Parce que dans la réalité,

la victime n’est pas encore dans l’ambulance

• De la même façon, avec le signal de l’hơpital, si une victime est proche d’un hơpital, elle est considérée comme déjà dans l’hơpital Ce n’est pas correct non plus

• Si un incendie est dans le rayon du signal d’une voiture de pompiers, on considère que cette voiture est en train d’éteindre l’incendie Si plusieurs incendies sont dans le rayon du signal d’une voiture de pompiers à la fois, on considère que cette voiture des pompiers est en train d’éteindre ces incendies Ce qui n’est pas correct Parce que dans la réalité, une voiture des pompiers ne peut prendre en charge qu’un incendie à

la fois

Troisièmement, au début de la simulation, les voitures des pompiers sont distribuées actuellement partout dans le plan Dès le commencement de la simulation, chaque voiture des pompiers ira chercher l’incendie qui est le plus proche d’elle Dans la réalité, les voitures des pompiers sont normalement gérées par des casernes Et avant un

tremblement de terre, elles se trouvent dans les casernes Dès qu’un tremblement de terre

a lieu, toutes les voitures des pompiers d’une caserne iront éteindre le même incendie Parce que avec les voitures des pompiers d’une caserne (qui normalement se trouvent dans la même position), le « service de recherche de chemin » de GAMA renverra le même incendie On voit que s’il y a plusieurs incendies à la fois, il faut que l’on distribue les voitures des pompiers entre ces incendies

Le point le plus irréaliste dans le modèle actuel est que normalement après un tremblement de terre, on ne connaît pas réellement l’environnement Notamment, on ne connaît pas les positions des victimes ni celle des incendies Actuellement, on suppose que l’on connaît tout l’environnement, ce qui n’est pas correct

Pour améliorer le modèle actuel, nous le modifions en ajoutons une espèce et la capacité

de communication en utilisant les protocoles d’interaction aux espèces actuelles Et nous n’utilisons plus le signal Le choix des protocoles d’interaction à utiliser dépend de chaque situation et de l’expérience du modélisateur Dans le cadre de ce modèle, les protocoles d’interaction choisis permettent d’implémenter la communication et la coordination entre les agents L’objectif est de montrer le fonctionnement des protocoles d’interaction de FIPA et non pas de faire une version optimisée du modèle Si le choix de certains protocoles entraine des envois superflus de messages, il permet de tester les protocoles en question

V.2 Modèle AROUND avec la communication

Nous ajoutons une espèce qui s’appelle « explorer » Un explorer se déplace dans l’environnement Il envoie les informations concernant les victimes et les incendies aux casernes

L’organisation des espèces dans la nouvelle version du AROUND est donc comme suit :

On divise les explorers en équipes Chaque caserne a sa propre équipe d’explorers Dans

le plan (du quartier BaDinh par exemple), on a plusieurs casernes Une caserne se charge d’une zone du plan Dès que le tremblement de terre a lieu, la caserne demande à chaque explorer dans son équipe d’aller faire une patrouille dans sa zone Chaque explorer fait la patrouille sur des routes données par sa caserne Quand l’explorer voit des victimes ou des incendies, il envoie ces informations à sa caserne

Ci-dessous, c’est la figure qui représente la relation entre une caserne (un agent de l’espèce military) et son équipe d’explorers

Figure 20 - Relation entre military et explorer

Deux protocoles d’interaction « FIPA Request » et « No Protocol » sont employés pour implémenter la communication entre le military et l’explorer

Premièrement, c’est le protocole « FIPA Request »

Figure 21 - Procotole d’Interaction FIPA Request entre military et explorer

Si un military veut qu’un explorer fasse une patrouille, il commence le protocole en envoyant un message « request » Le contenu de ce message contient une liste des points

à patrouiller Si un explorer est occupé avec une patrouille en cours, il refuse la demande

Le protocole se termine S’il est libre, il accepte la demande en répondant un message « agree » Quand la patrouille est terminée, l’explorer envoie un message

« inform » à son military pour l’informer ce fait Le protocole est donc terminé et l’explorer devient libre pour d’autres patrouilles

Deuxièmement, c’est le protocole « No Protocol »

Figure 22 - Protocole d’Interaction « No Protocol » entre explorer et military

Sur la route de la patrouille, si un explorer voit des victimes et des incendies sur le terrain, il envoie ces informations à son military en utilisant le protocole « No Protocol »

A côté de l’équipe des explorers, chaque military a aussi une équipe des firemen (les voitures des pompiers)

Figure 23 - Relation entre military et fireman

La communication entre l’espèce military et l’espèce fireman est réalisée en utilisant principalement le protocole d’interaction FIPA Request

Figure 24 - Protocole d’Interaction FIPA Request entre military et fireman

En recevant les informations sur les incendies envoyées par les explorers, le military demande aux firemen de son équipe d’aller les éteindre Il envoie cette demande en utilisant le procotole FIPA Request Le military commence le protocole en envoyant le message avec le performatif « request » Si le fireman est occupé, il refuse la demande en répondant un message avec le performatif « refuse » S’il est libre, il accepte la demande

en répondant un message « agree » Quand l’incendie est éteint, le fireman correspondant envoie un message « inform » à son military pour l’informer de ce fait Le protocole se termine

En ce qui concerne les informations concernant les victimes, le military envoie ces informations aux hôpitaux qui sont les plus proches de lui Nous employons ce scénario parce que chaque military est responsable d’une zone du plan Cette zone se trouve autour du military correspondant Les victimes découvertes par ses explorers sont donc des victimes qui se trouvent normalement autour du military Ca nous aide à économiser

le temps pour prendre les victimes vers les hôpitaux les plus proches

Nous utilisons deux protocoles d’interaction pour implémenter la communication entre l’espèce military et l’espèce hospital

Premièrement, le protocole FIPA Request est employé par le military pour demander à un hospital son nombre de places disponible pour les victimes Ce protocole est montré dans

la figure suivante :

Figure 25 - Protocole d’Interaction FIPA Request entre military et hospital

Quand un military reçoit les informations des victimes envoyées par ses explorers, il fait

la communication avec les hôpitaux pour savoir les places libres de chaque hôpital En recevant la demande du military, chaque hôpital informe le military correspondant de son nombre de place disponible

Figure 26 - Protocole d’Interaction « No Protocol » entre military et hospital

Après avoir reçu les informations concernant les places disponibles des hôpitaux, le military distribue les victimes à prendre en charge aux hôpitaux Le military donne une priorité plus haute aux hôpitaux qui sont les plus proches de lui

Les ambulances sont aussi divisées en équipes Chaque hôpital gère une équipe d’ambulances Cette relation est représentée dans la figure suivante :

Figure 27 - Relation entre hospital et ambulance

En recevant les informations sur les victimes envoyées par les militaries, un hôpital distribue le travail à ses ambulances Un hôpital demande à une ambulance d’aller prendre une victime en utilisant le protocole d’interaction FIPA Request comme suit :

Figure 28 - Protocole d’Interaction FIPA Request entre ambulance et hospital