Dans un premier temps, nous travaillons sur un seul système embarqué. Nous nous servons de l’application sur une même carte pour valider notre hypothèse concernant le choix du protocole de négociation. Dans un second temps, nous avons étendu la possibilité d’établir notre plateforme MERMAID sur les CPU de plusieurs systèmes embarqués afin que la délégation puisse s’effectuer d’un agent sur une première machine vers un agent sur une seconde carte. Pour expérimenter ce mécanisme, nous adaptons notre précédent cas d’application de traitement d’images : la réalisation d’une interpolation.
7.2
|
Évaluation du temps de réponse du protocole de négociation
Notre première expérimentation est l’évaluation en termes de performance du protocole de négociation multi- agents, CNP, utilisé pour effectuer la délégation. Dans un premier temps, nous mesurons le temps de réponse du protocole sans le traitement découlant du zoom. Cette expérience nous permet d’évaluer le coût administratif du mécanisme.
7.2.1
Formalisation du SMA embarqué et application à MERMAID
Nous repartons du SMA précédemment réalisé et décrit en section 6.4 et reprenons les étapes de réalisation d’un système multi-agents embarqué décrites en section4.3pour construire notre nouveau SMA. Comme nous nous concentrons sur les aspects de délégation, nous plaçons de côté les intérêts liés à la flexibilité au cœur de notre précédente formalisation. Pour limiter les interactions en dehors du protocole CNP, nous regroupons les services des précédentes familles d’agents "Zoom" et "Pixel" dans le service de traitement principal de la famille "Image". Notre agent "Bordure" ayant été déterminé comme indépendant, il est conservé. Par ailleurs, nous intégrons à la famille "Image" un nouveau service pour la mise en place du protocole CNP.
À l’étape de la table des besoins, le service de négociation fait apparaître un nouveau manque : la nécessité de connaître la disponibilité des autres agents partageant la capacité de résoudre un service. En effet, la prise de décision concernant l’agent auquel la tâche sera déléguée nécessite de nouvelles interactions. Des modifications sont apportées en conséquence et la Figure 7.3représente notre nouvelle table des besoins.
Image
Familles d'agents
Bordure
Besoins Moyens
Agent indépendant
Calcul des bordures du zoom Disponibilité des autres agents Image
Bordure Image
Figure 7.3 – Table des besoins pour le cas de délégation de la tâche "zoom sur une image".
Nous finalisons la formalisation de nos agents embarqués avec la création de la matrice complète des interactions [Figure7.4]. En comparaison de notre précédent cas d’études, l’évaluation du protocole CNP nécessite de faire varier le nombre d’agents concernés. Nous établissons donc n instances d’agents Image.
Dans cette nouvelle matrice, l’agent ACC se charge d’effectuer la partie "d’appel" du protocole CNP : le Call for proposal (Cfp). En effet, il se renseigne auprès de DF et AMS pour établir la liste des agents offrant le même service "Zoom Image" que l’agent initiateur de l’appel. Il est ainsi en mesure de relayer l’appel au service CNP lié pour tous les agents concernés. Les agents continuent ensuite les étapes du protocole de négociation avec des messages de type réponse directement avec l’agent initiateur.
Pour déterminer la poursuite du protocole, il nous fallait déterminer les raisons poussant un agent à accepter ou rejeter une proposition. Nous avons identifié plusieurs paramètres intéressants tels que l’état d’un agent, le pourcentage d’utilisation de la ressource processeur, une méthode de calcul spécifique ou encore la localisation d’un agent dans le cadre du multi-cartes. Pour la validation de notre hypothèse concernant le protocole CNP, nous avons
CHAPITRE 7.Délégation de tâches Z Y 7.2.Temps de réponse de la négociation
Gestion administrative Application
Liste des services des agents +Ask register_DF + Ask achieve_DF + register_AMS + send_add + quit_list_AMS + achieve_AMS + register_DF + send_name + achieve_DF + send_mess + send_Cfp + Answer send_add + Answer send_name + Ask send_add + Ask send_name +Ask register_AMS + Ask achieve_AMS + Ask send_mess +Ask register_AMS + Ask achieve_AMS +Ask register_DF + Ask achieve_DF Source Cible
AMS
ACC
DF
Agent
Bordure
Agent
Image
AMS
ACC
DF
Agent
Bordure
Agent
Image
+ Calcul bordure + Zoom Image + Zoom Image CNP + Ask send_mess + Ask send_Cfp + Answer Zoom Image CNP + Ask Calcul bordure + Ask Zoom Image CNP + Answer Calcul bordure (1) (n)Figure 7.4 – Proposition de la matrice complète des interactions pour le cas de délégation de tâches.
choisi de nous concentrer sur la notion d’état de nos agents. Ainsi, les agents contactés par le Cfp vérifient leur état tel que présenté dans leur cycle de vie en section4.2. Sont-ils déjà occupés à réaliser une tâche (état Actif du service) ? Si la réponse est oui, ils renvoient à l’agent initiateur une proposition négative indiquant leur incapacité à répondre au besoin de ce dernier. Si la réponse est non, ils sont donc disponibles (état Prêt) et renvoient une proposition positive. Notre agent initiateur considère la première proposition qu’il reçoit comme étant la meilleure. Il renvoie donc un message de confirmation à l’agent lui ayant répondu le plus rapidement. Pour tous les autres agents ayant renvoyés une proposition positive, l’initiateur la refuse.
Enfin, l’agent dont la proposition a été acceptée vérifie qu’il n’a pas changé d’état au cours de la négociation. S’il est toujours disponible, il confirme sa proposition. L’agent initiateur clôt le protocole et lui délègue la tâche.
7.2.2
Protocole d’expérimentation
Notre objectif est d’évaluer spécifiquement le surplus d’activités induit par les interactions issues du protocole de négociation. Un élément de mesure consiste à prendre en compte le temps de réponse de notre protocole dans le cas le plus gourmand : tous les agents générés sont disponibles et émettent chacun une proposition. Cependant une seule de ces propositions sera acceptée par l’agent initiateur, et donc un seul agent contacté ira jusqu’au bout du protocole de négociation. Nous établissons notre expérimentation pour un nombre d’agents, proposant le même service de zoom sur une image, variant de 2 à 100, soit de 6 à 300 messages générés.
Le temps de réponse induit par la négociation relative à ce nombre d’agents est relevé. Nous considérons les résultats avec la fenêtre de temps du protocole appliqué à la mesure du temps de réponse de notre expérimentation sur la flexibilité [Section6.6]. Nous retrouvons ainsi la limite de réponse dynamique d’affichage d’une image de 25 ms pour la perception humaine et la limite de cadence d’une vidéo de 55 ms. Pour déterminer le temps de réponse du programme, nous déclenchons un décompte lors de la réception par un service CNP d’un agent d’une tâche jusqu’à l’obtention d’une solution avec un autre agent.
7.2. Temps de réponse de la négociation Z YCHAPITRE 7.Délégation de tâches
Pour déclencher le protocole de négociation, nous lançons notre expérimentation en contactant continuellement le même agent pour lui demander d’effectuer le service d’agrandissement sur une image donnée. La première fois, l’agent étant disponible, il accepte la demande et commence son travail. Ce service se termine à l’initiative de l’utilisateur. Nous laissons volontairement le service en attente pour provoquer une situation continue d’indisponibilité chez notre agent. Nous lui envoyons alors une nouvelle demande de traitement pour un agrandissement d’une autre image. Cette fois l’agent est occupé à traiter notre première demande, il déclenche alors le protocole de négociation pour déléguer notre service.
7.2.3
Résultats
Pour observer le fonctionnement de la délégation, ce dernier ne relevant d’aucune donnée quantitative, nous avons mis à jour l’affichage de l’image traitée pour indiquer l’identifiant de l’agent Image ayant pris en charge le service. Nous avons ainsi pu constater que si la première demande était bien traitée par l’agent contacté alors disponible, la demande suivante était traitée par un autre agent que l’utilisateur n’avait pas lui-même contacté. Ce changement d’agent responsable de la tâche permet d’attester du bon fonctionnement du principe de délégation. Par ailleurs, la reproductibilité de notre protocole pour chaque expérience nous permet de constater que l’agent héritant de la tâche à traiter n’est pas toujours le même, attestant ainsi d’une solution, issue des interactions entre les agents, non déterministe. Cette observation démontre l’indépendance de nos agents.
En termes de résultats quantitatifs, la Figure 7.5 présente les temps de réponse relevés au cours des négocia- tions. Ces valeurs représentent une moyenne des résultats obtenus lors des 5 expérimentations effectuées pour chaque nombre d’agents Image impliqués.
Figure 7.5 – Temps de réponse de la résolution du protocole de négociation CNP en fonction du nombre d’agents impliqués.
Nous relevons également les pourcentages du CPU et de la mémoire consommés durant la résolution de ces né- gociations. De la même façon que pour le temps de réponse, ces mesures se font en fonction du nombre d’agents déployés. Les résultats pour le CPU augmentent linéairement de 0,15 % de sa capacité pour 2 agents à 5,4 % pour 100 agents. Nous observons le même accroissement pour la mémoire, montant elle jusqu’à une consommation maximale de 0,3 %. Par ces résultats, nous constatons que les coûts administratifs en termes de consommation mémoire et CPU sont très faibles par rapport aux capacités maximales des composants. Il n’est donc pas nécessaire de chercher