Un système multiagent

Les structures que nous allons ainsi créer dans la simulation doivent répondre à un certain nombre d’impératifs. elles doivent se comporter avec une certaine cohérence dictée par les lois physiques propres à ce genre de phénomène. Dans le même temps, celles-ci leur imposeront une certaine interaction bien précise avec le reste du fluide, aussi bien les particules de base que les autres tourbillons émergés. Ainsi, elles devront faire preuve d’une certaine autonomie, qui les distingue de leur environnement, et d’une interaction voire d’une vie sociale avec celui-ci. Avec un soupçon de téléologie, on voit que les propriétés vérifiées par nos structures réifiées sont quasiment celles caractéristiques d’un agent informatique. C’est donc cet outil qui les réalisera : nos structures vortex seront dans notre simulation membres d’un système multiagent.

Les systèmes multiagents sont des systèmes qui soulèvent des problèmes d’implémentation sans même introduire des comportements évolués pour les agents (asynchronisme/synchronisme, gestion de communications asynchrones, programmation évènementielle, gestion dynamique d’organisation ou de groupes, ...). Nous avons lors de nos différentes implémentations essayé différentes gestions de l’architecture des agents. Nous

allons ici décrire celles utilisant la plateforme multiagents MadKit (Multi-Agent Development Kit), développée au LIRM-Montpellier et qui, tout en laissant libre de proposer des modèles comportementaux évolués pour les agents, gère leurs possibles interactions. Nous décrirons ensuite une autre implémentation plus légère, ne s’appuyant pas sur un framework existant (mais n’en redéfinissant pas un non plus). Madkit nous a en effet permis de prototyper certaines fonctionnalités de la simulation, mais au prix d’un surcroit de calcul gênant sur le long terme.

5.4.2 MadKit

Une des caractéristiques d’un agent informatique théorique est l’autonomie. Cette notion recouvre généralement une vue de l’esprit qui veut que les agents s’exécutent en parallèle dans le SMA, sans ordre indépendant de leur volonté. C’est bien entendu impossible pour un agent informatique réel. Les calculs qui décrivent son comportement sont exécutés quand un certains nombres d’arbitres les y autorisent : système d’exploitation, machine virtuelle java, scheduler du SMA … A défaut d’une belle exécution parallèle, il faut se résigner à choisir un ordre d’exécution le moins gênant possible. Celui-ci rompra bien sûr la métaphore mais on n’a pas le choix : il faut juste le choisir au mieux, de manière à ne pas trop affecter le déroulement de la simulation [Meu 01]. Là où on a le plus facilement prise, c’est dans le scheduler³², l’ordonnanceur du SMA. Voyons donc quels outils de simulation du temps MadKit nous fournit [Fer 98].

Dans MadKit, les agents sont membres d’un groupe dans lequel ils jouent un rôle. Un agent de Madkit est nécessairement un :

• AbstractAgent : permet de gérer le cycle de vie d’un agent (création, fonctionnement et suppression), l’appartenance à un groupe et l’assignation d’un rôle ainsi que la gestion de l’envoi et de la réception de messages. Ces agents peuvent éventuellement s’exécuter dans un même thread et donc alors de manière séquentielle.

Et peut également être :

• Agent : classe dérivée de AbstractAgent où chaque agent s’exécute dans son propre thread.

Certains Agents, associés donc à un thread, ont un rôle particulier, et gèrent l’accès d’autres agents au calcul :

• Un agent activateur (Activator) va permettre de définir les mécanismes d’ordonnancements des actions du groupe d’agents auquel il est rattaché.

• Un agent ordonnanceur (Scheduler) gère plusieurs agents activateurs. Il dérive de la classe Agent et possède donc son propre thread.

32 Le mot anglais « Scheduler » à l’avantage sur le français « Ordonnanceur » de rajouter une connotation horaire conforme à l’intuition qu’on a de ses fonctions. Néanmoins, arrêtons là cet anglicisme.

• Un agent observateur (Watcher) va gérer un ensemble de sondes (Probe) afin d’observer les agents. Ces sondes peuvent aller extraire des informations sur des agents appartenant à un groupe donné et jouant un certain rôle.

Les communications se font par l’intermédiaire de messages et sont gérés par un mécanisme de type boîte aux lettres. Ainsi, chaque agent, héritier d’AbstractAgent, possède et gère sa propre boîte.

Tout ceci est résumé Figure 54.

En ce qui concerne notre application, nos tourbillons sont implémentés via une classe Tourbillon³³ héritière d’Agent. Un autre Agent s’occupera de l’ensemble des particules de base. Le comportement de celles-ci est en effet trop fruste pour justifier d’y consacrer les ressources d‘un agent par particule : le coût immense en calcul n’aurait aucune contrepartie34.

Figure 54 : Gestion de l'accès au calcul dans MadKit

5.4.3 Autre implémentation : déroulement synchronisé des automates

Un cycle de simulation fait agir les différentes entités de la simulation. Lors de la partie dévolue aux agents, on peut dans nos implémentations les plus récentes distinguer deux étapes :

• Déplacement des Tourbillons

• Gestion des interactions et de la stabilité des Tourbillons

33 Nous adoptons comme convention de mettre une majuscule aux noms communs « techniques » (classes, packages etc.).

Pour le déplacement on procède en deux temps, calculer la nouvelle vitesse puis en déduire la nouvelle position, ces calculs étant faits par rapport aux valeurs du pas de temps d’avant. Les nouvelles positions ainsi obtenues peuvent poser des problèmes « sociaux » aux tourbillons (cf. 5.4.5). On entre alors dans la deuxième partie, réglée dans chaque agent par un automate (cf. 5.4.4). Chaque agent exécute une transition sur son automate, jusqu’à ce qu’ils aient tous atteints l’état de satisfaction, qui est un état terminal. On passe alors à la suite du cycle de simulation.

Nous représentons ci-dessous le graphe des packages d’Aquasys en entier. C’est le package environment (Figure 56) qui contrôle ces cycles.

Figure 56 : Graphe de dépendance du package environment

5.4.4 Vie des Tourbillons

La partie sociale du comportement des agents Tourbillons est réglé par un transducteur incarnant une description de type éco-agent [Fer 95].

Un transducteur est une machine abstraite qui se présente comme un graphe orienté. On passe d’un sommet à l’autre en lisant sur une bande d’entrée un symbole, en allant ensuite sur le sommet prévu pour le symbole lu et pour l’état dont on part, et on écrit sur une bande de sortie un symbole d’un autre alphabet. On peut regarder la Figure 57 pour avoir un aperçu d’un tel automate. L’action symbolique d’écriture correspond pour nos agents à une action. Définissons à présent plus précisément ces machines.

Définitions : • Soit :

- un alphabet fini

- un semi-anneau , - Q un ensemble fini d’état

- I : Q  K l’ensemble des états initiaux - T : Q  K l’ensemble des états finaux

- : Q x x Q  K une fonction de transition

Le 5-uplet ( , Q, I, T, ) est alors appelé automate à multiplicité.

• Soit un alphabet, P( ) l’ensemble des polynômes à coefficients entiers de mots du langage généré par , un transducteur est un automate à multiplicité dont le semi-anneau est (P( ),+,.), avec + correspondant à l’union et . à la concaténation.

Un transducteur, dont l’alphabet d’entrée correspond aux perceptions possibles de l’agent, et l’alphabet de sortie à ses actions possibles, est au cœur de nos Tourbillons. Ce transducteur en fait ce qu’on appelle des éco-agents.

Un éco-agent est défini de la manière suivante :

- quatre états internes : satisfaction, fuite, recherche de satisfaction et recherche de fuite - des actions élémentaires de satisfaction ou de fuite

- une fonction de perception des agents gêneurs (c’est à dire les agents qui empêchent l’agent courant d’être satisfait ou de fuir)

- Une fonction d’agression d’autres agents

En l’occurrence, pour chacun de nos Tourbillons nous appelons : - les états internes de l’éco-agent :

o (S) être satisfait

o (SS) rechercher la satisfaction o (F) fuir

o (SF) rechercher la fuite

L’état initial est (SS) et l’état final est (S). - les fonctions de perceptions :

o (A) être attaqué

o (I) percevoir des gêneurs - les actions élémentaires :

o (TF) fuir

o (TS) se satisfaire - (TA) attaquer les agents

On utilise donc le transducteur suivant :

- est l’alphabet d’entrée des perceptions :

- est l’alphabet de sortie des actions élémentaires (TI, TE, N0 et N1 sont des actions « techniques » qui n’ont pas de sens dans la métaphore éco-agent).

- est l’ensemble des états de l’automate

- est défini par et

- est défini par et