Impl´ ementation des agents et de l’environnement

commencer par ´etudier les probl`emes li´es `a l’impl´ementation des agents et de l’environnement et nous nous int´eresserons ensuite `a la mani`ere dont la mod´elisation du temps est consid´er´ee dans les simulations multi-agents.

3.4

Probl´ematiques li´ees `a l’impl´ementation des agents et de

l’environnement

3.4.1 Difficult´e d’avoir un point de vue g´en´erique

D’un point de vue technique, les caract´eristiques d’un simulateur multi-agents sont bien sˆur en grande partie li´ees `a l’architecture logicielle utilis´ee pour impl´ementer les agents et l’en- vironnement. Dans ce cadre, les besoins et les contraintes qui portent sur celle-ci peuvent varier tr`es fortement du fait de l’h´et´erog´en´eit´e des domaines o`u la simulation multi-agents peut-ˆetre appliqu´ee. Les structures des mod`eles repr´esentants les agents et l’environnement ne sont en effet pas les mˆemes suivant le cadre exp´erimental dans lequel on se place (RMC, ´ecologie, ´ethologie, etc.). L’architecture d’un simulateur multi-agents est donc bien sˆur tr`es fortement influenc´ee par la nature du syst`eme source que l’on souhaite mod´eliser. C’est d’ailleurs sans aucun doute l’une des raisons pour lesquelles il n’existe pas `a l’heure actuelle de m´ethodologie g´en´erique li´ee `a la mod´elisation et `a l’impl´ementation des syst`emes multi-agents qui fasse l’ob- jet d’un consensus. En cons´equence, la nature de l’environnement (continu ou discret, statique ou dynamique, etc.), la granularit´e des actions/perceptions (fine ou grossi`ere) et la complexit´e de l’architecture interne d’un agent sont autant de points sur lesquels le mod´elisateur est amen´e `a faire des choix personnels qui sont fonction de ses besoins. Le nombre impressionnant de plates-formes existantes en est la manifestation.

3.4.2 Probl´ematiques invariantes

Malgr´e cela, pour r´epondre aux objectifs que nous nous sommes fix´es dans cette th`ese, il nous faut ici essayer d’exhiber quelques invariants li´es `a l’impl´ementation du couple agents/en- vironnement. Et ce, afin de clairement identifier les caract´eristiques qui sont sp´ecifiques aux simulations multi-agents. L’approche multi-agents impose en effet des contraintes, plus ou moins fortes, que toute impl´ementation, et a fortiori les propositions de cette th`ese, doivent prendre en consid´eration.

N´ecessit´e d’une architecture modulaire

Tout d’abord, il est pr´ef´erable que le design de l’architecture logicielle envisag´ee soit la plus modulaire possible. Les raisons en sont `a la fois pratiques et conceptuelles. Pratiques dans le sens o`u il est n´ecessaire d’avoir un minimum de g´en´ericit´e afin de pouvoir impl´ementer faci- lement des variations sur les agents et/ou l’environnement sans remettre en cause l’ensemble du code source. Conceptuelles car le paradigme agent appelle naturellement une program- mation modulaire car il est question de mod´eliser des entit´es individuelles et autonomes. De plus, ces deux aspects sont bien sˆurs fortement li´es : plus une impl´ementation est modu- laire, plus elle a de chances d’impl´ementer des agents et un environnement conceptuellement corrects et vice versa. La plupart des plates-formes de simulation multi-agents int`egrent ces aspects et proposent des architectures agent modulaires et/ou des environnements componen- tiels ([Lhuillier, 1998] par exemple). Pour ce faire, le mod`ele objet est aujourd’hui utilis´e dans

la majorit´e des cas. Les agents et l’environnement sont alors repr´esent´es par une collection d’objets dont les interfaces accessibles d´efinissent les moyens grˆace auxquels ils interagiront32. Au-del`a des contraintes li´ees `a des consid´erations purement g´enie logiciel comme celle que nous venons d’´evoquer, il est encore plus int´eressant d’exhiber les contraintes g´en´eriques sous-tendues par le concept d’agent lui-mˆeme. Nous pensons qu’il existe deux contraintes fondamentales qui p`esent sur l’impl´ementation des agents et de l’environnement :

– la contrainte de localit´e : un agent est une entit´e dont les perceptions et les actions n’ont qu’une port´ee locale.

– la contrainte d’int´egrit´e environnementale : un agent ne doit pas ˆetre en mesure de modifier directement les variables d’´etat de l’environnement.

Contrainte de localit´e

Cette premi`ere contrainte est incontournable. Comme nous l’avons dit pr´ec´edemment, l’environnement n’est pas enti`erement accessible pour un agent. Ce dernier n’a en principe qu’une perception locale du monde dans lequel il se trouve et ses actions sont limit´ees dans leur port´ee. Pour prendre en compte cet aspect, l’impl´ementation doit n´ecessairement fournir un moyen de d´efinir le rayon d’action/perception d’un agent. Pour cela, deux solutions non exclusives sont possibles :

1. approche discr`ete (centr´ee environnement) ; o`u l’impl´ementation de l’environnement d´e- finit la granularit´e des perceptions/actions de par la nature du mod`ele utilis´e.

2. approche continue (centr´ee agent) ; o`u la port´ee de chaque perception/action fait l’ob- jet d’un traitement particulier fonction de sa nature et des caract´eristiques de l’agent concern´e.

Approche discr`ete. Lorsque l’environnement peut ˆetre facilement discr´etis´e en une jux- taposition de zones (les pi`eces d’une maison, les nœuds d’un r´eseau, le d´ecoupage d’une zone g´eographique, etc.), la premi`ere solution consiste `a utiliser les caract´eristiques du mod`ele envi- ronnemental pour d´efinir la port´ee des perceptions/actions de mani`ere g´en´erique. De la mˆeme fa¸con que pour un environnement repr´esent´e par un objet unique, chaque zone d´efinit une interface qui d´ecrit les actions qui peuvent lui ˆetre appliqu´ees. La dimension d’une zone est alors utilis´ee comme unit´e spatiale pour d´efinir la port´ee des perceptions/actions. De plus, une relation de voisinage entre les diff´erentes zones est utilis´ee pour d´efinir la topologie de l’environnement. Dans le cas d’une maison cette relation peut ˆetre concr´etis´ee par les portes qui existent entre les pi`eces par exemple.

L’exemple le plus courant d’une telle impl´ementation consiste dans une grille de cellules (ou patch) r´eguli`ere (figure 3.7). Pour ce type environnement, les deux relations de voisinage les plus utilis´ees sont les suivantes :

– le voisinage de Von Neumann o`u une cellule est en relation avec les cellules adjacentes qui se trouvent aux quatre points cardinaux : Nord, Sud, Est et Ouest.

32

Quelle que soit la nature de l’impl´ementation, pour que les agents puissent respectivement percevoir et agir sur leur environnement, celle-ci doit fournir des m´ecanismes qui leur permettent de consulter et de modifier, non n´ecessairement de mani`ere directe, l’´etat de l’environnement. L’interface de l’environnement d´efinit ainsi les actions et les perceptions que l’agent peut invoquer grˆace `a l’attribution d’une r´ef´erence, que celle-ci soit encapsul´ee ou non, directe ou indirecte comme c’est le cas lorsqu’un objet interm´ediaire tel qu’un effecteur est utilis´e par exemple. De fa¸con duale, l’interface de l’agent est utilis´ee par l’environnement pour concr´etiser de potentielles modifications sur son ´etat physique.

3.4 Impl´ementation des agents et de l’environnement 61

Unité spatiale de perception et d’action

Fig. 3.7 – L’environnement comme une grille de cellules.

– le voisinage de Moore o`u les voisins d’une cellule sont les huit cases adjacentes.

Largement utilis´ee pour leur simplicit´e d’impl´ementation, les m´ethodes `a base de grille ont par ailleurs le bon goˆut de permettre la d´efinition de dynamiques environnementales bas´ees sur des algorithmes h´erit´es du domaine des automates cellulaires. Cependant leurs utilisations posent le probl`eme de la granularit´e spatiale des perceptions/actions qu’un agent peut effectuer du fait de la r´egularit´e de leur discr´etisation : quelles que soient les actions d’un agent, et on sait qu’elles peuvent ˆetre tr`es h´et´erog`enes, leur port´ee est toujours la mˆeme (modulo un certain facteur) : la cellule.

Approche continue. Au contraire, la seconde solution consid`ere chaque agent comme le r´ef´erentiel par rapport auquel la port´ee effective de chaque perception/action doit ˆetre calcul´ee. Il s’agit ici d’augmenter la finesse de la mod´elisation du syst`eme en individualisant ce traitement en fonction du type de la perception/action et des caract´eristiques de l’agent. On doit par exemple ˆetre capable d’impl´ementer le fait que les capteurs visuels d’un robot n’ont pas forc´ement une port´ee qui soit un multiple de celle de ses capteurs d’ondes radio. On doit aussi pouvoir prendre en compte l’´etat de fonctionnement dans lequel se trouvent les capteurs pour d´efinir leur port´ee : on peut par exemple d´esirer l’alt´erer volontairement en la multipliant par un nombre r´eel. Cette impl´ementation de la contrainte de localit´e est bien sˆur une solution plus complexe `a mettre en œuvre que la pr´ec´edente et son application s’adresse plus particuli`erement `a la mod´elisation de syst`emes o`u l’environnement est non d´eterministe et/ou continu. La copie d’´ecran pr´esent´ee par la figure3.8illustre cette approche. Dans cette simulation chaque agent poss`ede un rayon de perception qui lui est propre, ici repr´esent´e par un cercle dont l’agent est le centre.

Le principal inconv´enient de ce type d’impl´ementation r´eside dans le fait que le code source associ´e peut rapidement devenir impossible `a d´evelopper et/ou `a r´eutiliser si cette approche est mise en œuvre de mani`ere ad hoc. A ce propos, l’´etude r´ealis´ee dans sa th`ese par Magnin sur les relations entre un agent et son environnement montre que de nombreux inconv´enients, rencontr´es aussi bien lors de l’analyse que de l’impl´ementation des syst`emes multi-agents, sont en fait dus `a un manque de diff´erenciation entre la partie physique d’un agent et son syst`eme

Rayons de perception

Fig. 3.8 – Approche continue pour la perception et l’action.

d´ecisionnel [Magnin, 1996]. Magnin parle de confusion des rˆoles entre la composante physique et le cerveau d’un agent. Son travail montre les probl`emes li´es `a une telle confusion ainsi que l’importance de faire une telle distinction d’un point de vue g´enie logiciel.

On retrouve aussi cette id´ee de s´eparation explicite entre diff´erentes composantes d’un agent dans les travaux de Lhuillier [Lhuillier, 1998] et de Souli´e [Souli´e, 2001]. Il est en effet clairement beaucoup plus simple de modifier ou de substituer les diff´erents ´el´ements d’une simulation (agents et/ou environnement) si l’action, la perception, le comportement interne d’un agent et l’environnement sont mod´elis´es par des entit´es distinctes. En effet, lorsqu’un agent utilise, pour percevoir ou agir, des m´ethodes d´efinies dans la classe qui repr´esente l’envi- ronnement, il n’est pas possible de remplacer le mod`ele de l’environnement par un autre, plus complexe, sans avoir `a modifier l’ensemble des classes concern´ees, c’est-`a-dire celles de l’agent et de l’environnement. Outre cet ind´eniable aspect pratique, cette distinction est aussi d’un int´erˆet conceptuel fondamental qui nous am`ene `a discuter la deuxi`eme contrainte que nous avons propos´ee : la contrainte d’int´egrit´e.

Contrainte d’int´egrit´e environnementale

L’´enonc´e de cette contrainte stipule qu’un agent ne doit pas modifier directement les variables d’´etat de l’environnement. En effet, ce n’est pas une entit´e en mesure de calculer la cons´equence r´eelle de ces d´ecisions sur l’´evolution du monde. Comme le souligne Ferber, le r´esultat de l’action d’un agent est aussi fonction des autres actions et de l’´evolution endog`ene de l’environnement [Ferber, 1999]. Ainsi, il est conceptuellement incorrect qu’un agent puisse modifier une variable mod´elisant l’´etat de l’environnement. Tr`es peu de travaux int`egrent cette contrainte et l’action d’un agent est g´en´eralement mod´elis´ee par son r´esultat pour des raisons de simplicit´e. Autrement dit, dans la majorit´e des cas, les agents modifient les variables environnementales de leur propre chef pour signifier leurs actions.

3.4 Impl´ementation des agents et de l’environnement 63

Pour compliquer les choses, les notions d’agent et d’environnement sont `a ce point ins´e- parables qu’une partie de l’entit´e conceptuelle d´esign´ee par le terme agent est contenue dans l’environnement. Pour illustrer notre propos, prenons l’exemple de la simulation d’un robot r´eel. Lorsque nous employons le terme agent pour le d´esigner, nous faisons r´ef´erence au robot dans son ensemble : le programme informatique qui l’habite et ses moyens d’action physiques (bras articul´e, syst`eme de d´eplacement, etc.). Dans la r´ealit´e, ce n’est pas parce que le syst`eme d´ecisionnel du robot prend l’initiative d’une action que le r´esultat escompt´e va forc´ement se r´ealiser33 : ses moyens physiques peuvent ne pas ˆetre op´erationnels par exemple (m´ecanique cass´ee, manque d’´energie, etc.). Or ce qui est appel´e agent dans la figure 3.1 est une boˆıte noire dans laquelle toutes les variables d’´etat sont par d´efinition accessibles aux processus qui mod´elisent la dynamique de l’agent. Dans le cadre d’une simulation, les variables qui repr´e- sentent la partie physique d’un robot ne doivent donc pas se trouver dans cette boˆıte noire, puisqu’elles ne sont pas sous le contrˆole de l’agent. Par cons´equent, ces variables font partie int´egrante de l’environnement. C’est pourquoi, pour simuler un agent, il convient de faire une distinction nette entre les variables d’´etat qui sont utilis´ees par son architecture interne et les variables qui mod´elisent sa partie physique.

Ceci ´etant dit, il nous faut ici revenir quelques instants sur la repr´esentation sch´ematique d’un syst`eme multi-agents que nous avons donn´ee dans la section3.2.1. Comme nous l’avons dit pr´ec´edemment, du point de vue d’un agent, tout ce qui ne concerne pas son architecture interne fait de facto partie de l’environnement. Par ailleurs, nous venons de voir l’importance de l’environnement dans la r´ealisation d’une action. C’est pourquoi, lorsque l’on consid`ere l’impl´ementation d’un syst`eme comportant plusieurs agents, il est conceptuellement tout `a fait incorrect de repr´esenter le fait que deux agents puissent interagir ensemble en concr´etisant un lien direct entre leurs deux architectures internes, sans passage par l’environnement (figure 3.9). La figure3.9 illustre cette contrainte.

Fig. 3.9 – La contrainte d’int´egrit´e environnementale implique qu’il ne doit pas exister de relation directe entre les architectures internes de deux agents autonomes.

La s´eparation explicite entre les diff´erentes composantes d’un agent trouve ici une justifica- tion suppl´ementaire. En effet, si cette distinction n’est pas effective dans l’impl´ementation, il est difficile de garantir qu’un agent n’a pas un acc`es direct sur l’architecture interne d’un autre, comme c’est en fait souvent le cas. Nous mettrons en ´evidence ce probl`eme dans le chapitre 7. Pour l’instant, on peut remarquer que concr´etiser cette distinction dans l’impl´ementation

33

On trouve dans [Brooks, 1992] une tr`es int´eressante analyse des probl`emes qu’il faut prendre en compte lorsqu’on s’attaque `a la simulation de robots r´eels : imperfection des valeurs fournies par les senseurs, incertitude sur le r´esultat des commandes appliqu´ees aux effecteurs, etc.

n’est pas du tout trivial et peut rapidement devenir un casse-tˆete si l’on n’y prend pas garde. En effet, comme nous venons de le voir dans le cas d’un robot, la fronti`ere entre un agent et son environnement est assez subtile. Elle d´epend d’ailleurs aussi de la nature de l’agent consid´er´e : les capteurs et les effecteurs sont bien sˆurs tr`es diff´erents suivant les diff´erentes cat´egories d’entit´es qui peuvent ˆetre rencontr´ees. De plus, du fait de la relation forte qui existe entre ces deux entit´es, le design de l’un influence le design de l’autre. Ce qui constitue `a n’en pas douter le principal frein `a l’´elaboration de codes r´eutilisables. Utiliser le code repr´esentant le comportement d’un agent sur un autre environnement que celui pour lequel il a tout d’abord ´et´e con¸cu n´ecessite encore aujourd’hui de lourdes modifications.

Pour ´eviter de faire la confusion des rˆoles dont parle Magnin, une tr`es bonne solution consiste `a consid´erer les moyens d’action et de perception d’un agent comme des modules individuels distingu´es de son syst`eme conatif. C’est par exemple ce que propose Souli´e qui r´eifie dans son travail les notions de capteurs et d’effecteurs [Souli´e, 2001]. Il fait ainsi une distinction claire entre les modules qui repr´esentent le syst`eme conatif et ceux qui mod´elisent la partie physique de l’agent, notamment ses moyens de perception et d’action, qui eux font partie de l’environnement. Il parle ainsi de l’instance de l’agent dans l’environnement.

Finalement, outre l’impl´ementation de l’architecture interne des agents d’un cˆot´e et celle de l’environnement de l’autre, la v´eritable difficult´e r´eside en fait dans la mani`ere dont le lien et la fronti`ere qui existent entre ces deux abstractions sont concr´etis´es. Autrement dit, le point le plus d´elicat se situe dans ce que Souli´e a tr`es justement appel´e le lien de d´ependance bidirectionnelle entre un agent et son environnement. Son travail montre clairement que l’´etude de ce lien constitue un point cl´e pour l’´elaboration de structures logicielles g´en´eriques.

Pour r´esumer, il est important de faire la distinction entre les deux composantes d’un agent d`es le mod`ele conceptuel de mani`ere `a respecter la contrainte d’int´egrit´e environnemen- tale dans l’impl´ementation. Nous aurons l’occasion de revenir sur ce point important `a de nombreuses reprises dans ce document. Il constitue en effet un des piliers de notre analyse et nous montrerons comment cette id´ee peut ˆetre g´en´eralis´ee. Nous verrons alors tous les b´e- n´efices que l’on peut tirer d’une distinction claire entre les deux composantes d’un agent : le corps et l’esprit34.