L’automate de modes du coordinateur

L’automate du coordinateur, comme le montre la figure 4.6 contient 5 modes corres- pondant à différentes phases liées au processus de coordination. Nous avons choisi la représentation du coordinateur sous forme d’automate afin d’avoir un modèle de prise de décision homogène. La décomposition en modes permet de faciliter la conception et la modification du coordinateur.

Waiting Send_Suggestions Treat_Responses Receive_Notifications {controller_requesti} != {}/ coord_inprogress <- vrai Determine_Reconfiguration_Possibilities final_decision=null et end_round=vrai {mode_updatedi}=involved_controllers / update(current_config) coord_inprogress <- faux final_decision=acceptation / sens_authorization({coord_decisioni}, involved_controllers) final_decision=refus/ send_refusal({coord_decisioni}, involved_controllers) coord_inprogress <- faux treat_responses({controller_responsei}, involved_controllers, end_possibility_list, end_round, final_decision) coordinateur({controller_requesti}, {controller_responsei},{mode_updatedi}) = (coord_inprogress, {coord_suggestioni}, {coord_decisioni})

involve_others=false/ send_authorization({coord_decisioni}, involved_controllers) involve_others=vrai determine_Reconfiguration_Possibilities( {controller_requesti}, GC_list, involve_others) send_suggestions({coord_suggestioni}, round, GC_list, involved_controllers,

end_possibility_list, end_round)

FIG. 4.6 – L’automate de modes du coordinateur

4.4.3.1 Les entrées et sorties de l’automate

Les entrées et sorties de l’automate du coordinateur sont présentées dans son entête. Les entrées

Les entrées de l’automate sont :

– les requêtes des contrôleurs ({controller_requesti}). Ici, la notation {} désigne un

ensemble,

– les réponses des contrôleurs aux propositions ({controller_responsei}),

– les notifications reçues des contrôleurs après l’exécution des reconfigurations ({mode_updatedi}).

Les sorties

Les sorties de l’automate sont :

– la notification envoyée aux contrôleurs au début et à la fin d’un processus de coordination (coord_inprogress),

– les propositions de reconfiguration (coord_suggestioni) envoyées aux contrôleurs,

– la décision du coordinateur ({coord_decisioni}) envoyée aux contrôleurs à la fin

d’un processus de coordination.

4.4.3.2 Le processus de coordination géré par l’automate de mode

Le mode Waiting correspond à un coordinateur en attente des requêtes des contrô- leurs. Si le coordinateur reçoit une requête, il envoie une notification (coord_inprogress= vrai) à tous les contrôleurs leur indiquant qu’il y a une coordination en cours. Il passe ensuite au mode Determine_Recon f iguration_Possibilities qui permet de déter- miner à travers l’action determine_Recon f iguration_Possibilities ({controller_requesti},

GC_list, involve_others), les éventuelles reconfigurations requises pour les autres régions contrôlées. Cette action permet donc de garantir une configuration globale qui satisfait la requête et qui respecte en même temps les contraintes/objectifs du système. Dans le

cas où plus d’une configuration du système vérifient ces deux conditions, les différentes possibilités sont mises dans une liste ordonnée. Les entrées de cette action sont donc les requêtes des contrôleurs ({controller_requesti}) et ses sorties sont la liste des possibilités

de configurations satisfaisant la requête (GC_list) et la détermination du fait que la coordination implique ou pas la reconfiguration d’autres régions (involve_others).

Si la requête reçue n’implique pas la reconfiguration d’autres régions (involve_others = f aux), le coordinateur envoie son autorisation au contrôleur qui a envoyé la requête à travers l’action (send_authorization ({coord_decisioni},

involved_controllers)). Sinon (involve_others = vrai), le coordinateur passe au mode S end_S uggestions et envoie les propositions aux contrôleurs concernés à tra- vers l’action send_suggestions({coord_suggestioni}, round, GC_list, involved_controllers,

end_possibility_list, end_round). Ici, la variable locale round indique le numéro du tour de coordination considéré. En fait, si plus d’une configuration du système satisfont la requête et les contraintes/objectifs gérés par le coordinateur, le processus de coordina- tion est divisé en un ensemble de tours ou chaque tour est lié à une des configuration considérée de la liste ordonnée GC_list. La variable involved_controllers est un tableau de booléens dont la taille est le nombre des contrôleurs. Elle permet d’indiquer les contrôleurs qui sont impliqués dans un tour de coordination. Le contenu de la variable involved_controllers est mis à jour en affectant la valeur vrai aux éléments dont les indices correspondent au contrôleur qui a envoyé la requête et les autres contrôleurs impliqués dans le tour de coordination courant. La variable end_possibility_list permet de déter- miner si toute la liste GC_list a été parcourue. La variable end_round est une sortie qui détermine si un tour de coordination est fini. Cette variable est mise à f aux par l’action send_suggestions puisqu’il s’agit du début du tour. Elle prendra la valeur vrai après le traitement des réponses des contrôleurs comme nous allons voir dans la suite de cette section.

Après avoir envoyé les propositions, le coordinateur passe au mode T reat_Responses dans lequel il traite les réponses des contrôleurs aux propositions et détermine sa décision. Dans l’action treatresponses ({controller_responsei}, involved_controllers,

end_possibility_list, end_round, f inal_decision), le paramètre f inal_decision est une sor- tie qui détermine si le traitement des réponses a donné lieu à une prise de décision finale. Le paramètre end_round est une sortie qui détermine si toutes les réponses ont été traitées. Le paramètre end_possibility_list est une entrée qui indique si toutes les possibilités ont été parcourues, ce qui conduit à la prise d’une décision de refus si jamais les réponses du dernier tour de coordination n’ont pas conduit à une décision d’autorisation de reconfi- guration. Si dans un tour donné, après le traitement de toutes les réponses, la décision finale du coordinateur n’est pas encore prise, il retourne au mode S endSuggestionspour

traiter la possibilité suivante dans la liste GC_list. Si la décision du coordinateur est d’au- toriser la reconfiguration, il envoie l’autorisation (send_authorization ({coord_decisioni},

involved_controllers)) aux contrôleurs impliqués pour qu’ils lancent la reconfiguration. Si la décision est le refus, elle est envoyée au contrôleur qui a envoyé la requête à travers l’action send_re f usal ({coord_decisioni}, involved_controllers).

Après avoir envoyé la décision, s’il s’agit de refus le coordinateur passe au mode Waiting, sinon il passe au mode Receive_Noti f ication dans lequel il traite les notifi- cations (mode_updatedi) des contrôleurs après le chargement des bitstreams. S’il re-

Configurations globales mode1 j1.2 mode2 j2.2 moden jn.2 mode1 j1.1 mode2 j2.1 moden jn.1 Régions reconfigurable Région1 1 2 ... K ... Régionn Région2 mode1 j1.K mode2 j2.K mode2 jn.K ... ... ... ... ... ... ... FIG. 4.7 – La table GC du coordinateur

çoit des notifications de tous les contrôleurs auxquels il a autorisé la reconfiguration (mode_updatedi = involved_controllers), il met à jour sa vision de la configuration cou-

rante du système à travers l’action update(current_con f ig), notifie aux contrôleurs la fin du processus de coordination (coord_inprogress= f aux) et passe au mode Waiting. Plus de détails sur le mécanisme de coordination sont présentés dans le reste de cette section.