Gestion des contraintes

Changement d’états au cours de la vie d’une contrainte

Lorsque un agent reçoit une contrainte, celle-ci passe par plusieurs étapes résumées dans la machine à états figure 4.4. À chaque transition, l’appelant est informé via l’envoi d’un message d’information spécifique. Comme on l’a vu précédemment, lors de la réception d’une contrainte, l’agent va essayer de trouver une solution pour gérer cette contrainte, puis dans un second temps exécuter les tâches qui la satisferont. Si il ne trouve pas de solution, la contrainte passe

direc-tement dans l’état failure. Dans le cas nominal, elle passe dans l’état running au moment où

les tâches qui la gèrent commencent réellement à s’exécuter (et non une de ces préconditions).

Si nous reprenons l’exemple de la section 4.2.3, la contrainte passe dans l’état runninglors de

l’exécution de la tâchefuse. Depuis cet étatrunning, plusieurs évolutions sont possibles :

– Le cas nominal est que la tâche se termine avec succès, et donc que la contrainte est eff

ec-tivement satisfaite : la contrainte passe alors dans l’étatsuccess.

– Un second cas possible est la rencontre d’un aléa : l’agent va alors chercher une solution lo-calement (ce processus sera décrit plus précisément dans 4.3.2). Dans ce cas, la contrainte

4.3. INTERACTIONS ENTRE AGENTS 51

solution locale, et la contrainte reprend alors l’étatrunning, soit l’agent échoue à trouver

une solution locale et la contrainte passe dans l’état d’échec définitiffailure.

– Enfin, l’agent peut réagir à deux stimuli externes. Lors de la réception d’un message

pause, la contrainte passe dans l’étatpaused, elle pourra revenir dans l’état runninglors

de la réception d’un message continue. Et lors de la réception d’un message abort, la

contrainte est annulée et passe dans l’étataborted.

Dépendances entre les contraintes et rôle de l’étatpaused

Dépendances entre contraintes Dans une boucle spaclassique, la phase de planification n’a de sens que si le modèle est valide, et de même l’exécution n’a de sens que si la planification

a effectivement construit un plan valide. Il existe donc des liens de dépendances entre ces trois

constructions. On retrouve implicitement des dépendances analogues dansroar, via l’ordre de

déclaration des contraintes (avec les primitivesmakeetensure). Si l’on considère à nouveau le

listing 4.4, il apparaît assez clairement que la contrainteplan_ctrn’a de sens que si la contrainte

mapping_ctrest bien maintenue, et de même pour pour les contraintesexec_ctretmonitor_ctr. On considère donc la relation transitive de dépendance entre les contraintes, et celle-ci est direc-tement liée à l’ordre de déclaration de ces contraintes.

Dépendances et changement d’états On ne peut traiter une contrainte que si toutes celles dont

elle dépend sont dans cet état, i.e. que toutes les contraintes dont elle dépend sont satisfaites.

Observons les états dans lesquels la contrainte peut aller à partir de l’étatrunning. L’étatsuccess

ne présente pas d’intérêt, car il n’a de sens que dans des requêtes “discrètes” (via la primitive

make). L’étattemporary failureest plus intéressant, il indique un échec (au moins) temporaire,

mais cela signifie aussi que la contrainte n’est temporairement plus maintenue, et donc qu’on ne

peut plus continuer à garantir les contraintes qui dépendent d’elle. On va donc mettre enpause

toutes les contraintes qui dépendent de la contrainte temporairement en échec, arrêtant ainsi leur exécution. Si la contrainte finit par trouver une solution, l’agent pourra alors envoyer un message

continuepour réveiller les contraintes qui en dépendent. Ce mécanisme est illustré par la figure 4.5. Il permet d’assurer de manière générique que les dépendances d’exécution sont bien toujours garanties, et que les agents n’essaient pas de calculer ou exécuter des informations à priori non valides.

L’étatpaused L’étatpaused met uniquement en pause l’exécution de la recette actuellement exécutée. En particulier, il ne remet pas en cause le choix des tâches à exécuter, et donc le contexte dynamique. Nous avons envisagé d’interrompre puis de relancer les transitions en cas

de solution, mais cette approche avait deux problèmes. Elle est d’une part moins efficace dans

le cas nominal car elle implique de recalculer les tâches à exécuter, puis à choisir à nouveau la bonne recette. D’autre part, il est possible que l’agent se fasse “voler” la ressource par un autre

agent, qui en avait besoin à ce moment. Étant donné que l’étatpausedest un état transitoire assez

court, le contexte dynamique ainsi que le choix de la recette courante restent à priori valides, il est

avantageux de les conserver. L’introduction de cet étatpausedrépond donc mieux au problème

pos _{3DPlan locomotion}

init pos :0 run pos :0

init pos :1 run pos :1

temporary failure pos :0

pause pos :1

run pos :0

continue pos :1 run pos :1

temporary failure pos :0

pause pos :1

failure pos :1

abort pos :1 aborted pos :1

Figure4.5 – Messages échangés entre 3 agents en cas d’échec temporaire. Dans ce cas précis,

la satisfaction de la contraintepos :1dépend de la satisfaction de la contraintepos :0: un échec

temporaire de cette seconde implique donc la mise en pause de la première.

L’étatpausedet exécution Du point de vue de l’exécution, la pause d’une recette est équiva-lente aux étapes suivantes :

1. l’interruption de la primitive synchrone courante (wait, abort ou un appel à la couche

fonctionnelle, on suppose ici que les méthodes de la couche fonctionnelle sont incorrup-tibles)

2. faire suivre des messagespauseà toutes les contraintes actuellement maintenues

3. attendre le messagecontinue

4. faire suivre des messagescontinueà toutes les contraintes actuellement en pause

5. relancer l’exécution de l’opération synchrone interrompue.

Conclusion

Dans cette section, nous nous sommes intéressés aux dépendances entre les contraintes et ce que cela impliquait pour l’exécution des tâches associées. Nous avons présenté les mécanismes

4.3. INTERACTIONS ENTRE AGENTS 53 garantissant une exécution correcte en cas d’échec temporaire d’une des contraintes. Nous al-lons maintenant nous intéresser à la manière dont sont gérées les erreurs lors de l’exécution, d’abord localement au niveau de l’agent, puis plus généralement au niveau du système composé de l’ensemble des agents.