L’environnement

Nous l’avons vu, Jacques Ferber définit l’agent comme ayant une connaissance partielle de son environnement et pouvant interagir avec lui. Mais dans le domaine des SMA, l’environnement est une notion très vague. Il peut avoir de multiples utilités et prendre de multiples formes.

20 CHAPITRE 2. ÉTAT DE L’ART

Jacques Ferber [33] explique que l’environnement peut être représenté comme un sys- tème unique (centralisé) ou comme un système distribué. Dans nos recherches, nous utilisons des environnements centralisés. En effet, dans le domaine du jeux vidéo, même dans le cas de jeux multi-joueurs, il est préférable d’utiliser un serveur central pour réali- ser les calculs de l’environnement afin d’éviter que l’un ou l’autre des joueurs ne puissent tricher.

Très souvent, l’environnement est utilisé comme un vecteur de communication en étant utilisé de plusieurs manières différentes. Nous dressons une liste non-exhaustive de ces possibilités :

— La méthode du tableau blanc consiste à laisser un message qui pourra être lu par tous les agents. Les messages laissés peuvent nécessiter certaines compétences pour être lus ou peuvent être limités à une zone géographique. Ces messages sont similaires aux phéromones laissés par les insectes dans leur environnement pour communiquer avec leurs semblables [27].

— La méthode du broadcast est le fait qu’un agent communique directement avec tous les autres agents présents dans un environnement sans que ces derniers n’aient à lire le message. Cette méthode est différente de la méthode du tableau blanc où les agents doivent interroger l’environnement pour lire les messages qu’il possède. Tout comme la méthode du tableau blanc, il est possible de filtrer les agents pouvant lire ces messages en imposant certaines compétences par exemple.

— La méthode pair-à-pair consiste en la mise en contact de deux agents afin qu’ils échangent entre eux sans passer par l’environnement.

Chacune de ces méthodes apporte un intérêt dans le domaine du jeu vidéo. La méthode du tableau blanc permet aux agents de voir les changements de l’environnement causés par la présence d’autres agents (ou de joueurs), des traces de pas au sol par exemple. La méthode broadcast permet, quant à elle, de simuler des communications de masse comme cela pourrait être le cas dans une communication par radio ou télépathie ou bien dans une discussion entre plusieurs agents. La communication pair-à-pair peut être utilisée afin de permettre aux agents de se notifier des interactions ne faisant pas partie des actes de langages (Par exemple pour notifier un contact entre deux agents).

Un environnement simple ne permet pas aux agents de communiquer en broadcast ou en pair à pair. Il manque en effet un moyen pour les agents de se mettre en relation. KQML et FIPA mettent en place des agents dits facilitateurs. Il s’agit d’agents particuliers permettant aux autres agents d’entrer en contact entre eux.

Les agents facilitateurs de KQML agissent comme des routeurs centralisant les informa- tions sur les agents présents dans le système. Cette centralisation pose un problème de disponibilité du système du fait que si le facilitateur ne fonctionne plus, les agents seront incapables de se contacter.

FIPA définit deux types d’agents facilitateurs :

1. Agent Management System (AMS) : permet aux agents de récupérer une liste des agents avec qui ils peuvent communiquer. Cet agent agit un peu comme le service des pages blanches d’un annuaire. Il est aussi en charge de la création et la destruction des agents du système qu’il manage.

2. Directory Facilitator (DF) : permet aux agents de récupérer une liste des services que chacun des autres agents met à disposition. Cet agent fonctionne comme le service pages jaunes d’un annuaire.

2.2. LES AGENTS ET LES SYSTÈMES MULTI-AGENTS 21

Un des objectifs de l’AMS de FIPA est d’améliorer la stabilité du système. Lorsque les travaux sur les facilitateurs ont été menés, c’était pour pallier le fait que les systèmes de découvertes de services (qu’ils soient agents facilitateurs ou non) fonctionnaient princi- palement de manière centralisée.

Chaque agent qui propose des services va envoyer la liste de ceux-ci à l’agent DF, au moment où il entre dans le système. Lorsqu’un agent A a besoin d’un service, il demande à l’agent DF de le mettre en liaison avec un agent pouvant exécuter ce service.

Nous l’avons vu précédemment, les moteurs physiques permettent, entre autres, de connaître le positionnement de chaque agent. Dans les SMA, l’environnement peut avoir ce rôle de renseigner les agents sur le positionnement des autres agents. Le position- nement des agents et la capacité de chaque agent de pouvoir connaître la position des autres agents ont une grande importance dans les SMA. Ainsi, Philippe Mathieu [57] propose 4 patterns fondamentaux pour le positionnement des agents :

— Le premier pattern permet delister le voisinage d’un agent en parcourant tous les agents du système pour chercher ceux qui lui sont proches.

— Le deuxième pattern divise l’environnement en grille (environnement discret) et liste les cellules proches de celle où se trouve l’agent pour déterminer son voi- sinage. Dans ce pattern, les agents d’une même cellule sont considérés comme des voisins proches et les agents présents dans deux cellules considérées comme proches sont eux-mêmes considérés comme proches les uns des autres. Ce deuxième pattern donne aussi un algorithme pour le déplacement des agents dans cet environnement.

— Le troisième pattern réalise la même chose que le deuxième pattern, mais entrans- crivant un environnement en espace continu vers un environnement discret afin de pouvoir appliquer les règles du deuxième pattern.

— Le quatrième pattern permet aux agents deconnaître leur positionnement en fonc- tion de la proximité social qu’ils ont avec les autres agents.

Dans le but de formaliser les interactions, Yoann Kubera, Philippe Mathieu et Sébas- tien Picault ont développé Interaction-Oriented Design of Agent simulations (IODA), une approche orientée interactions visant à formaliser les interactions et permettant de les définir par le biais d’une matrice. Les interactions de IODA représentent chaque action pouvant être réalisée par les agents. Chaque interaction définie un nombre d’agents im- pactés par elle et comment et sous quelles conditions ces agents sont impactés. Pour ce faire, les interactions possèdent des conditions qui sont la conjonction :

— De pré-conditions permettant de définir sous quelles conditions l’interaction peut être initiée. Par exemple, dans le cas d’une interaction où l’agent se nourrit, une pré-condition serait la nourriture n’est pas avariée ;

— De déclencheurs permettant d’indiquer quels événements déclenchent une inter- action. Toujours dans le cas d’une interaction où l’agent se nourrit, le déclencheur serait l’agent à faim.

Dans IODA, une interaction décrit aussi les agents sources (ceux qui initient l’interaction) et les agents cibles (ceux qui la subissent) ainsi que la cardinalité de cette interaction sous la forme (cardS(I), cardT(I)) avec cardS(I) représentant le nombre d’agents sources et cardT(I) représentant le nombre d’agents cibles.

Enfin, une interaction dans IODA possède une liste d’actions correspondant à des primi- tives qui seront exécutées par les agents qui exécutent l’interaction. Les primitives sont

22 CHAPITRE 2. ÉTAT DE L’ART

FIGURE2.4 – Matrice d’interaction de IODA.

similaires à des méthodes de la programmation orientée objets. Elles permettent de dé- finir les actions réalisables par les agents.

La modélisation des interactions que les agents peuvent exécuter se fait par le biais d’une matrice comme celle présente dans la figure 2.4. Dans cette matrice, les agents sources sont dans la colonne de gauche et les agents cibles dans la ligne supérieure. A l’intersection d’une ligne et d’une colonne on peut trouver les interaction qu’un agent source peut exécuter à destination d’un agent cible. La valeur d correspond à la portée de l’interaction.

IODA permet aussi de définir des perceptions. Dans IODA, chaque agent peut percevoir les agents dans leur voisinage (sous entendu dans leur halo). Ce concept de halo peut cependant avoir un inconvénient qui est qu’un agent ne possède qu’une seule manière de percevoir car il ne possède qu’un seul halo. Il est alors complexe, mais non impossible, de développer une perception orale et visuelle pour un même agent par exemple.

Dans nos travaux de recherche, nous avons décidé de faire de l’environnement un vecteur de communication qui a aussi comme rôle celui de facilitateur. Nous nous basons sur les agents facilitateurs définis par FIPA. Nous modifions cependant l’agent DF pour qu’il puisse filtrer les réponses qu’il donne aux requêtes des agents. Cela permet de générer un comportement où un agent propose certains services à une liste réduite d’agent, en fonction de leurs liens sociaux, leur hiérarchie ou autre. L’environnement aura aussi pour rôle de faire le lien entre le moteur physique du système et les agents afin que ces derniers puissent obtenir des renseignements sur le positionnement des autres agents du système.

2.3/

S

-

Nous avons décrit précédemment que les SMA peuvent être développés pour fonctionner en temps réel ou non. Le choix sera souvent dicté par les besoins du système : Y a nécessité d’observer les résultats du système pendant qu’il s’exécute, ou est-il possible d’analyser ces résultats lorsque le système aura terminé son exécution ?

Les systèmes en temps réel sont nécessaires lorsque le système doit répondre à des informations provenant de périphériques externes. Il peut s’agir de capteurs dans des ateliers, des usines ou dans les villes [45] [50] [91]. Dans ces exemples, le système doit réagir en temps réel afin d’adapter son comportement aux nouvelles données qu’il a reçu des périphériques externes. La littérature définit aussi un système temps réel comme un système qui n’est pas seulement caractérisé par ses fonctionnalités (temporelles) mais aussi et surtout par des contraintes de temps [66] [74]. Plus spécifiquement, il s’agit de systèmes dans lesquels les tâches exécutées possèdent une deadline.

Dans le domaine qui est le nôtre, lorsque l’utilisateur souhaite réaliser une action, il utilise un périphérique pour signaler au système l’action qu’il souhaite réaliser. C’est pourquoi