A1
A2
A3
A1 A2
A3 A4 A5 A6 A7 A8 A9 A10
Zoom par 3 agents Pixel Zoom par 10 agents Pixel
(Agent no3 avec CPU à plus de 60 %) (Agents no3, 5 et 8 avec CPU à plus de 60 %) Figure 6.14 – Résultats d’un zoom, partagé entre plusieurs agents avec une interpolation effectuée par 3 (à gauche) et 10 (à droite) agents Pixel, sur l’image standard "Lena". Certains agents Pixel se voient attribuer un
contexte d’exécution peu favorable et réagissent en conséquence.
6.7
|
Synthèse de l’expérimentation
Il est cependant important d’analyser ces résultats en prenant en compte les apports qualitatifs de l’approche multi-agents. En effet, dans le cadre du traitement d’images comme dans d’autres domaines applicatifs, un surcoût administratif peut être envisagé pour obtenir un résultat plus précis ou une exécution plus flexible et plus modulaire. A travers ces résultats quantitatifs nous soulevons donc l’importance d’utiliser l’approche multi-agents au sein des systèmes embarqués en considérant toujours un objectif d’équilibre entre les avantages et les inconvénients de cette solution.
Dans le cadre de cette expérimentation nous relevons donc un coût administratif élevé estompé par un apport en flexibilité validé. Nous allons à présent nous focaliser sur cet apport pour voir si nous pouvons l’appliquer aux SE en tant qu’ensemble matériel et notamment en ce qui concerne l’optimisation de la gestion des tâches.
Chapitre 7
Délégation de tâches par SMA entre cartes
embarquées
"La sagesse est fille de l’expérience."
Léonard De Vinci Architecte, Artiste, Ingénieur, Peintre, Philosophe, Scientifique, Sculpteur (1452 - 1519)
Nos expérimentations du mécanisme de délégation de tâches par un SMA dans le contexte du traitement d’images se déroulent selon trois étapes :
- dans un premier temps, nous éprouvons la performance du protocole multi-agents pour obtenir une délégation de tâches ;
- ensuite, nous reprenons les évaluations visuelles en considérant la possibilité de coupler la flexibilité présentée au chapitre précédent avec le mécanisme de délégation ;
- enfin, nous étendons cette délégation à un contexte hétérogène en établissant notre SMA sur différentes cartes embarquées.
7.1
|
Délégation dynamique des tâches
Nous avons abordé l’optimisation de notre système embarqué par l’angle de la gestion des tâches dans la section
2.1 et plus précisément en introduisant l’idée d’une délégation des tâches dans la section 2.2 [Définition 5]. Nous intervenons alors après le travail de l’ordonnanceur, ce dernier étant intégré en phase de conception au système embarqué. Nous proposons une éventuelle correction des choix de ce dernier une fois les paramètres liés au contexte considéré. Nous incluons le terme "dynamique" pour souligner cet apport en réactivité induit par l’application d’un SMA.
Dans la section2.2, nous expliquons que certaines ressources des systèmes embarqués sont capables d’effectuer des tâches communes. Ces ressources sont pourtant dédiées à une forme de tâche spécifique. Ce choix de conception s’explique par une préférence de robustesse du produit, c’est à dire l’assurance d’un service rendu, par rapport à une réelle optimisation des capacités du SE.
Nous souhaitons apporter la possibilité pour des unités matérielles partageant les mêmes capacités à résoudre certains types de tâches de pouvoir se répartir le travail. La Figure 7.1illustre cette possibilité.
7.1. Délégation dynamique des tâches Z YCHAPITRE 7.Délégation de tâches
Espace
utilisateur
Espace
matériel
Unité 1
Unité 2
Unité 3
Tâc
A1
Tâc
A4
Tâc
D3
Tâ
e 5
Tâc
A5
Tâc
A2
Tâc
A5
Délégatio
n
Délégation
CapacitéA
, C CapacitéB
, A CapacitéD
, C, ETâc
A2
Figure 7.1 – Principe de délégation de tâches de type A entre unités matérielles possédant la capacité pour résoudre ce type de tâche.
Le schéma présente trois unités matérielles avec des capacités pour différents types de tâches notées A, B, C, D et E. Par souci de robustesse, chaque unité a été dédiée à un type de tâche en particulier :
- l’unité 1 est capable de traiter les tâches de type D, C et E et est dédiée aux tâches de type D ; - l’unité 2 est capable de traiter les tâches de type B et A et est dédiée aux tâches de type B ; - l’unité 3 est capable de traiter les tâches de type A et C et est dédiée aux tâches de type A.
Lors de l’utilisation du système embarqué, nous représentons sur la figure le cas d’une surcharge d’affectation de tâches de type A à la troisième unité matérielle. Sans délégation, le temps de résolution total est la somme des temps de résolution de chaque tâche. Avec une délégation, l’unité matérielle peut ré-affecter certaines tâches à une autre unité matérielle possédant la capacité adéquate. L’unité 2 a la capacité de résoudre les tâches de type A. Les tâches A2 et A5 lui sont donc déléguées pour optimiser l’emploi du SE et réduire le temps de résolution total.
Pour effectuer la délégation, nous devons instaurer une possibilité de discussion entre nos unités matérielles. Cette discussion doit permettre d’établir à quelle unité matérielle la tâche sera déléguée ainsi que les paramètres à prendre en compte pour la décision de délégation. Nous rappelons notre proposition concernant la délégation des tâches, introduite dans la partie 1.5de ce document :
◆
✓
⇣
⌘
Les processus pouvant négocier une délégation des tâches allouées, par le biais d’interactions multi-agents entre différents systèmes embarqués, optimiseront la gestion des tâches de chaque SE de façon réactive.
Rappel hypothèse #3
En section3.3, nous avons présenté les différents cas de convergences régissant les SMA. Dans notre cadre d’ap- plication, nos composants peuvent posséder des buts différents. Ils partagent des ressources communes qui pourront être suffisantes ou insuffisantes selon la capacité du SE impliqué. Enfin, afin de déléguer certaines tâches face à un afflux de requêtes, nous estimons les compétences de chaque composant comme insuffisantes. Nous nous plaçons donc dans le cadre de comportements sociaux de type négociation.
Nous proposons donc d’utiliser les algorithmes multi-agents de type négociation présentés en section 3.3.1pour établir la délégation tout en satisfaisant les besoins à la fois d’optimisation et de robustesse des SE.
Nous considérons actuellement la caractéristique "indisponible" pour déclencher la délégation. Concrètement, lorsqu’une tâche est en cours de traitement, l’unité passe en état "indisponible". Si une tâche est assignée à une unité indisponible, cette dernière cherchera à la déléguer.
CHAPITRE 7.Délégation de tâches Z Y7.1.Délégation dynamique des tâches
En perspectives, nous discuterons de l’intégration d’autres paramètres de décision liés aux capacités de l’unité considérée et aux préférences de l’utilisateur. Pour ce travail de thèse, nous nous concentrons sur la possibilité d’uti- liser un protocole de négociation multi-agents pour effectuer la délégation. Nous avons choisi d’utiliser le protocole CNP également détaillé dans la partie3.3.1.
Nous avons présenté l’intérêt de la délégation de tâches pour un système embarqué en prenant l’exemple des unités matérielles. A présent, nous considérons ce processus au niveau de nos agents reliés au même composant matériel : le CPU. Par le biais d’expérimentations entre plusieurs cartes embarquées nous retrouverons l’apport décrit. Pour cette délégation entre agents, les tâches correspondent à la réalisation de services.
La Figure7.2présente le schéma du mécanisme de délégation de tâches employé entre les agents sur notre plate- forme. Nous y présentons des agents de la même famille offrant un service "S", ainsi qu’un service "S CNP" associé. Leur service S passe en état indisponible durant le traitement d’une tâche. S’ils reçoivent une autre requête durant ce traitement, ils activent le service CNP associé pour chercher à déléguer la tâche.
Agent 2
Agent 1
Agent n
tâche 2traitement
tâche 11
3
S CNP S CNP Service S S S S CNP tâche 34
tâche 26
tâche 47
5
tâche 22
ACC
traitement
traitement
Figure 7.2 – Mécanisme de délégation des tâches entre agents proposant le même service S grâce au protocole CNP.
L’étape (1) correspond à la réception d’une tâche par l’Agent 1 pour son service S. Étant alors disponible, il entame le traitement nécessaire pour l’achever. L’étape (2) indique l’arrivée d’une nouvelle requête. Toujours occupé par la première demande, l’Agent 1 passe cette tâche à son service CNP en étape (3). Il engage ainsi un processus de négociation visant à déléguer la tâche 2 à un autre Agent proposant le même service S. Pendant ce temps, en (4), l’Agent 2 a lui-même reçu une demande et, étant disponible, a commencé à travailler à sa résolution. En étape (5), le processus CNP est activé. L’agent ACC se charge de la première étape du protocole pour contacter les autres agents de cette famille. La négociation aboutira à un échec avec l’Agent 2 déjà occupé, mais à une entente avec l’Agent n qui était disponible. En (6), la tâche 2 est donc envoyée par l’Agent 1 au service S de l’Agent n.
En (7), une nouvelle requête arrive pour l’Agent 1. Ce dernier suivra le même cheminement de résolution (n’étant toujours pas disponible). Cette fois-ci, il ne recevra cependant que des refus lors de la négociation. La tâche sera donc placée en attente de l’Agent 1 dans sa file de réception d’origine : celle du service S.