Structure et fonctions d’un agent

La classe de base d’un agent MADKIT(AbstractAgent), définit quelques fonctionnali- tés de base pouvant être nécessaires dans les modèles classiques.

Fonctionnalités

Cycle de vie. L’agent dispose de quatre états (création, activation, exécution, et destruction), et a la possibilité de démarrer d’autres agents sur le noyau local (et de les désactiver par la suite). Par contre, aucun mécanisme concret d’exécution n’est défini à ce niveau.

Communication. La communication est implémentée sous forme de passage de message asynchrone4, soit d’agent à agent identifiés par leurAgentAddress ou leur groupe et rôle, soit sous la forme d’une diffusion à tous les teneurs d’un rôle dans un groupe donné.

Organisation. Tout agent dispose de primitives permettant d’observer son organisation lo- cale (connaître les groupes et rôles courants) et d’y agir (prise de rôle, entrée et retraits de groupes).

Outils. La classe de base des agents permet également de manipuler une éventuelle inter- face graphique associée à l’agent, les flots d’entrée/sortie, etc.

Messages

Les messages sont définis par héritage à partir d’une classe de baseMessagequi ne dé- finit que la notion d’émetteur et destinataire. Une bibliothèque de messages de base (voir figure 6.7) est néanmoins fournie et permet l’envoi de chaînes, d’objets sérialisés, de do- cuments XML, ou bien de messages conformes aux spécifications KQML et FIPA-ACL. Ils restent extensibles pour s’adapter à tout protocole d’interaction.

AbstractMessage

KQMLMessage ACLMessage

ActMessage StringMessage Message

XMLMessage ObjectMessage

FIG. 6.7 – Hiérarchie des messages standards

La sémantique du passage de message de MADKITa un trait un peu particulier : toute manipulation de message par le noyau n’entraîne aucune recopie. Cela signifie qu’un mes- sage construit et envoyé viasendMessagepar un agent ne sera pas copié au moment de

4_{Si l’on se place dans le cas d’agents dont on contrôle les politiques d’ordonnancement, comme nous le ver-}

sa délivrance dans la boîte au lettre du destinataire, et que celui-ci ne recevra donc que la recopie de la référence.

Pourquoi ce choix, par rapport à un modèle où tout message transitant par le noyau au- rait entraîné une copie du message (ce qui aurait garanti le cloisonnement des données) ? Principalement par souci de généricité des modèles de communications : on peut recons- truire un modèle par recopie à partir de celui que nous proposons, mais l’inverse n’aurait pas été faisable. Le second avantage, fort prosaïque est celui de l’efficacité. Le chapitre 8

donne quelques évaluations de la performance du système d’envoi de messages, locaux ou distants.

Politiques d’exécution

Agents concurrents Pour faciliter les implémentations de modèles plus “cognitifs” d’agents, la classe de base Agent est définie pour associer un processus à chaque agent. Quelques fonctions de base sont rajoutées, comme la mise en attente d’un message.

Agents synchrones Néanmoins, pour certains types de systèmes, en particulier les sys- tèmes multi-agents réactifs, il est nécessaire de gérer un grand nombre d’agents (jusqu’à des centaines de milliers) de granularité assez fine, et de contrôler leur ordonnancement. Cela est quasi-impossible si l’on se repose sur un mécanisme de processus en raison de de la sur- charge induite. Dans ce cas, on utilise ces agents “synchrones” via des agents externes qui vont définir leur politique d’exécution synchrone. Des agents d’observation peuvent être ajoutés pour avoir une vue globale sur certaines propriétés, à l’instar des plate-formes clas- siques de simulation comme CORMAS [Bousquet et al., 1998] ou Swarm [Burkhart, 1997].

Sonde Sonde Sonde Activateur Activateur Observateur Ordonnanceur Référençable _{Référençable} Référençable Référençable Référençable

FIG. 6.8 – Fonctionnement des agents synchrones

Ce modèle permet l’utilisation de plusieurs ordonnanceurs simultanés d’un système si- mulé par le mécanisme de groupe et rôle. Cette architecture est décrite plus en détail dans [Gutknecht et al., 1998]. L’intérêt de cette implémentation est que les agents exécutés dans ces systèmes synchrones ont exactement les mêmes fonctionnalités (passage de message, vue

organisationnelle, ...) que les agents en processus et peuvent donc être associés facilement en systèmes hybrides. De plus, la gestion du mécanisme de simulation ou d’observation repose une fois encore sur l’approche en groupe et rôle. Par exemple, on va associer une sonde à une certaine propriété présente dans les tenants d’un rôle donné sur un certain groupe.

[Michel, 2000] montre plus en détail les conséquences de cette architecture pour le contrôle du biais dans les simulations multi-agents.

1 2 3 4

5 6

résultats de perceptions

actions en retour

(a) activités parallèles

1 3 5

2 4

résultats de perceptions

actions en retour

(b) activités séquentielles

FIG. 6.9 – Deux modes de synchronisation

Pour préciser ce problème, prenons l’exemple classique d’un ensemble d’agents à activer sur un environnement commun.

Une approche possible consiste à mettre en place une synchronisation exécutant tour à tour chacun des agents. Chaque entité va alors percevoir des modifications de son état et entourage (environnement simulé, messages, structure organisationnelle) puis agir sur celui-ci - figure6.9(a).

Une autre approche courante consiste à séparer cycles de perception et d’action, et de synchroniser d’abord l’ensemble des perceptions et des traitements chez les agents. Ensuite seulement est définie l’action des agents et leur prise en compte par le modèle applicatif - figure6.9(b).

Cette approche peut paraître plus complexe (puisque l’on subdivise les activités des agents), elle a néanmoins l’avantage d’éviter un favoritisme pour le premier agent activé (premier à percevoir et agir dans le premier modèle).

On pourrait continuer en décrivant la structure d’une simulation conduite par événe- ments, ou des mécanismes plus complexes comme [Magnin, 1996] qui évalue en permanence les moments clés d’une simulation d’agents spatialement situés.