Agents administratifs

La norme FIPA propose trois agents de gestion : AMS, DF et ACC. Présentés en section 3.2.3, ils assurent l’organisation administrative et le contrôle de l’ensemble du système multi-agents. Ces trois agents administratifs se basent sur les bibliothèques de fonctions de l’API MERMAID de la même façon que nos autres agents embarqués. Cependant, ils sont les premiers à être lancés sur l’ensemble du SMA. En effet, les services qu’ils proposent vont permettre d’assurer le bon fonctionnement du système. Si la norme FIPA impose la présence de ces agents avec le respect des rôles qui leur sont associés, elle laisse cependant la possibilité de les adapter au contexte d’utilisation. Nous présentons donc ici nos adaptations spécifiques de ces trois agents.

5.1.3.1

AMS : le système de gestion d’agents

D’après les spécifications de la norme FIPA, l’agent AMS se charge de tenir à jour la liste de tous les agents évoluant sur la plateforme. Lors de son initialisation, un agent s’enregistre auprès d’AMS en lui indiquant ses in- formations dans un message. Il se désenregistre lors de sa terminaison par simple indication de son nom. La liste comporte les AID des agents, ces derniers regroupant deux informations : le nom de l’agent et son adresse IP avec un numéro de port. Dans le cadre d’un contact par D-Bus, le nom de l’agent suffit. L’adresse IP et le numéro de port sont utilisés pour un contact par Socket. Notre couche MTPS se charge de récupérer les informations nécessaires au transfert à partir de l’AID en fonction du système utilisé.

L’agent AMS peut également envoyer une requête d’arrêt à un agent. Nous adaptons cette capacité proposée par FIPA pour intégrer un service d’arrêt du SMA. Le principe est d’envoyer une requête d’arrêt à l’ensemble des agents enregistrés dans la liste de l’agent AMS. Actuellement, notre plateforme MERMAID ne dispose pas d’une interface graphique permettant de suivre le fonctionnement de nos agents. Nous incluons donc un service optionnel d’affichage de la liste facilitant le suivi de l’évolution du système multi-agents. Enfin, l’agent AMS permet de récupérer une identi- fication AID en fonction du nom d’un agent. Ce service est particulièrement utilisé par l’agent administratif ACC lors du routage d’un message. La Table5.6détaille ces différents services proposés pour notre adaptation de l’agent AMS.

5.1.3.2

DF : le facilitateur d’annuaire

A l’instar de l’agent AMS, l’agent DF tient à jour une liste d’éléments correspondant aux agents évoluant sur la plateforme. Cette fois, un élément correspond à un service et à l’agent qui le propose. Par conséquent, un même agent peut être enregistré plusieurs fois dans la liste pour chacun de ses services. De même, un service peut être enregistré plusieurs fois si plusieurs agents le mettent à disposition.

Lors de son initialisation, un agent va donc envoyer un message à l’agent DF pour chacun des services qu’il propose afin de les enregistrer séparément dans la liste. A la terminaison d’un agent ce dernier envoie un message avec son nom au service de désenregistrement de l’agent DF. Il retire alors de sa liste tous les éléments associés au nom de cet agent. Dans la norme FIPA, l’agent DF n’a pas de spécifications ajoutées à cette gestion des capacités des agents. Nous lui attribuons tout de même un service d’affichage de sa liste pour faciliter le suivi de l’évolution du SMA et notam- ment proposer une redondance en vérifiant que les noms enregistrés existent sur les listes d’AMS et de DF.

L’agent DF permet de récupérer le ou les noms des agents proposant un service donné. Comme plusieurs agents peuvent correspondre, l’agent DF peut renvoyer plusieurs réponses pour une seule requête. Dans ce cadre, il termine son interaction réponse en envoyant un dernier message de fin. Ce service est principalement utilisé par l’agent ACC pour le routage des messages. La Table5.7détaille les services offerts par notre agent DF.

CHAPITRE 5.MERMAID : une plateforme agent embarquée Z Y 5.1.Architecture

Service Description

Ce service requiert l’AID de l’agent. Par le biais de ce service, l’agent AMS register_AMS intègre un nouvel élément agent dans sa liste. Ce service ne renvoie pas de

messages à moins qu’une erreur n’empêche l’enregistrement effectif de l’agent. Ce service est l’antagoniste du précédent. Il requiert uniquement le nom d’un achieve_AMS agent. AMS retrouve l’élément correspondant au nom donné et le supprime de

sa liste. Ce service ne renvoie pas de messages à moins qu’une erreur n’empêche le retrait effectif de l’agent.

Comme le service précédent, celui-ci requiert le nom d’un agent pour permettre send_add à AMS de retrouver l’AID correspondant dans sa liste. Il renvoie ensuite

cette information par le biais d’un message de type réponse.

Ce service est optionnel et ne requiert aucune information spécifique. Il print_list_AMS affiche la liste des AID des agents actuellement enregistrés.

Il ne renvoie aucun message après traitement.

Ce service ne requiert pas non plus d’information particulière. Il parcourt quit_list_AMS sa liste et envoie un message d’arrêt à chaque agent y étant enregistré. Les

agents viendront d’eux-mêmes se désenregistrer auprès du service "achieve_AMS" et seront donc retirés de la liste au fur et à mesure.

Ce service ne renvoie aucun message après traitement. Table 5.6 – Services proposés par notre agent administratif AMS.

5.1.3.3

ACC : le canal de communication entre agents

L’agent ACC est responsable du routage d’un message à un agent destinataire. En effet, pour limiter leur empreinte mémoire, les agents du SMA ne connaissent pas spécifiquement les autres agents de la plateforme. Toute interaction se fait à l’intention d’un service nécessaire à l’avancement de l’agent. Par contre, ils connaissent par défaut les trois agents administratifs. Dans le cadre de l’envoi d’une requête, le service de routage de l’agent ACC ( send_mess) est contacté.

L’agent ACC propose également un service permettant l’envoi de plusieurs requêtes simultanées, une pour chaque réponse renvoyée par DF. Pour ce service, nous utilisons les informations d’encapsulation optionnelles détaillées en sous-section3.2.3. Nous utilisons principalement ce service dans le cadre du protocole CNP et l’indiquons via l’option "Protocole". Pour permettre le suivi de plusieurs interactions simultanées, nous utilisons également l’option "Iden- tifiant de conversation". La Table5.8résume les services spécifiques à notre agent ACC.

Nous illustrons le routage d’un message par ACC avec un exemple en Figure5.2. Pour cet exemple, nous consi- dérons que tous ces agents évoluent sur le même système embarqué et appartiennent donc au même environnement immédiat. Par conséquent, le système de communication utilisé est le protocole D-Bus. Ce transport est transparent pour les agents.

5.1. Architecture Z YCHAPITRE 5. MERMAID : une plateforme agent embarquée

Service Description

Ce service effectue l’intégration d’un nouvel élément à la liste des services register_DF du SMA. Il requiert un nom de service et le nom de l’agent le proposant. Ce

service ne renvoie pas de messages à moins qu’une erreur n’empêche l’enregis- trement effectif du service.

A l’inverse, celui-ci correspond à la suppression des services associés au nom d’agent reçu en paramètre. Plusieurs éléments pourront donc être retirés achieve_DF de la liste lors d’une seule requête. Ce service ne renvoie pas non plus de

message après traitement à moins d’avoir rencontré une erreur.

Ce service permet d’obtenir le nom du ou des agents proposant un service

send_name donné. Comme le nombre d’agents pouvant correspondre est variable selon

les cas, plusieurs réponses pourront être envoyées : une par agent concordant plus une indiquant la fin de la recherche.

Ce service est optionnel. Il permet à la fois de faciliter le suivi de la liste des services supportés par le SMA et d’offrir une certaine redondance print_list_DF d’informations concernant les noms des agents enregistrés. En effet, ces

derniers doivent également exister dans la liste gérée par AMS. Aucune réponse n’est générée par ce service.

Table 5.7 – Services proposés par notre agent administratif DF.

Service Description

Ce service permet le routage d’un message vers un agent destinataire à partir du nom d’un service que l’on souhaite contacter. Le message doit contenir 3 informations : le service cible, le type du message à transférer et le contenu du message à délivrer. send_mess Ce service se sert des traitements réalisés par le service "send_name" de l’agent DF

[Table5.7] et "send_add" de l’agent AMS [Table5.6]. Si une erreur intervient à n’im- porte quel stade du traitement, le routage du message est compromis et un message d’erreur est renvoyé à l’agent initiateur de la requête.

Ce service tire son nom de l’étape Call for proposal du protocole CNP présenté en sous-section 3.3.2. Il permet l’envoi de plusieurs requêtes simultanées à différents agents destinataires. Ce service se base sur le même mécanisme que le précédent send_Cfp tout en permettant la prise en compte de la totalité des retours de l’agent DF. Si une

erreur intervient pour l’un des agents contactés, les interactions avec les autres agents destinataires ne sont pas impactées.

CHAPITRE 5.MERMAID : une plateforme agent embarquée Z Y 5.1.Architecture Couche Logicielle Couche Matérielle

Agent A

service : a adresse : @A

D-Bus

ACC

send_mess @ACC

AMS

send_add @AMS

DF

send_name @DF

Agent B

b @B

Figure 5.2 – Diagramme présentant l’exemple du routage d’un message.

Nous considérons deux agents applicatifs, A et B, proposant chacun un service différent : "a" et "b", joignables aux adresses "@A" et "@B". Les agents administratifs ACC, AMS et DF sont illustrés avec leurs services "send_mess" [Table 5.8], "send_add" [Table 5.6] et "send_name" [Table 5.7]. Nous indiquons leurs adresses respectives comme étant "@ACC", "@AMS" et "@DF".

L’agent A souhaite contacter le service b pour une requête avec le message "mess". A fait appel à ACC et lui transmet une requête avec les indications nécessaires au transfert [message n◦1].

A partir du nom du service, l’agent ACC récupère en premier lieu le nom d’un agent offrant le service b. Il envoie à cette fin une requête au service "send_name" de DF [message n◦2]. Ce dernier traite sa demande et

lui retourne en réponse le nom "B" [message n◦3].

Une fois le nom de l’agent destinataire obtenu, ACC doit encore récupérer l’adresse pour le contacter. Il envoie une requête au service "send_add" d’AMS qui lui retourne l’information "@B" [message n◦4 et 5].

Lorsque l’agent ACC a réuni toutes les informations nécessaires au routage du message d’origine, il reconstitue le message à transférer à partir des informations reçues lors de l’activation de son service par l’agent A (le type de message à envoyer et son contenu). Il transmet ensuite ce message final au service b de l’agent B [message n◦6].

5.1. Architecture Z YCHAPITRE 5. MERMAID : une plateforme agent embarquée

Dans le document Intégration des systèmes multi-agents aux systèmes embarqués pour la délégation de tâches (Page 103-107)