Implantation des protocoles de communication FIPA dans la plate forme GAMA

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,
2ème année, Spécialité RECHERCHE
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
l’Informatique

la

Francophonie

pour

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

Master INTELLIGENCE ARTIFICIELLE ET MULTIMEDIA,
2ème année, Spécialité RECHERCHE
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 où 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.

6


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 où 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 (où les

7


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
8


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.

9

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.

10


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.

11


• 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é.

12


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

13

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.

14


Figure 7 - Protocole d’interaction FIPA Request

A partir de la figure 7, on a la liste des ProtocolNodes correspondants.
Numéro
performative
sentByInitiator
followingNodes
1
request
true
2, 3
2
refuse
false
null
3
agree
false
4, 5
4
failure
false
null
5
inform
false
null
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 « inform-done » et « informresult ». 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.

15


• 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
16


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 :

17


• 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, où
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
18

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 :
No

Argument

Obligatoire

Signification

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

19


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 :
No

Argument

Obligatoire
oui

Signification

1

message

Le message à répondre.

2

performative oui

Le performatif du message répondu.

3

content

Le contenu du message répondu.

non

Tableau 3 – Les arguments du primitif « reply »

Les primitifs de haut-niveau
No

Primitif

Signification

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 :
No
Variable
Signification
1 acceptProposals Une liste des messages avec le performatif « accept-proposal » de
l’agent correspondant.
20


2

agrees

3

cancels

4

cfps

5

failures

6

informs

7

proposes

8

queries

9

refuses

10

rejectProposals

11

requests

12

requestWhens

13

subscribes

14

messages

15

conversations

Une liste des messages avec le performatif « agree » de l’agent
correspondant.
Une liste des messages avec le performatif « cancel » de l’agent
correspondant.
Une liste des messages avec le performatif « cfp » de l’agent
correspondant.
Une liste des messages avec le performatif « failure » de l’agent
correspondant.
Une liste des messages avec le performatif « inform » de l’agent
correspondant.
Une liste des messages avec le performatif « propose » de l’agent
correspondant.
Une liste des messages avec le performatif « query » de l’agent
correspondant.
Une liste des messages avec le performatif « refuse » de l’agent
correspondant.
Une liste des messages avec le performatif « reject-proposal » de
l’agent correspondant.
Une liste des messages avec le performatif « request » de l’agent
correspondant.
Une liste des messages avec le performatif « request-when » de
l’agent correspondant.
Une liste des messages avec le performatif « subscribe » de
l’agent correspondant.

Une liste de tous les messages dans la boîte aux lettres de l’agent
correspondant.
Une liste de toutes les conversations en cours de l’agent
correspondant.
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 :

21


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']" />

22


</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">

23


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

III.6.2.3. Scénario 3
• L’agent « initiator » envoie une demande à l’agent « participant » en utilisant le
primitif « send ».
<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 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>

24


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) ellesmê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 :
No

Variable

1

placeActuelleAvoirNourriture

2

avoirSignalNourriture

3

avoirNourriture

4

auNid

Signification
true
false
La place actuelle de la fourmi contient
La place actuelle de la fourmi ne contient pas
de la nourriture.
de nourriture.
Une des places voisine de la fourmi a
Une des places voisine de la fourmi n’a pas
un signal de nourriture.
de signal de nourriture.
La fourmi est en train de prendre la
La fourmi n’est pas en train de prendre la
nourriture.
nourriture.
La fourmi est au nid.
La fourmi n’est pas au nid.

25