3.4.1 Communication avec d’autres gestionnaires de plans
Quand ils sont en interaction, les gestionnaires de plans maintiennent deux ´etats :
– ils sont en communication si un lien de communication existe entre les deux composants.
– ils sontconnect´es si ils interagissent. Deux gestionnaires de plans peuvent ˆetre connect´es et n’avoir pas de lien de communication. Toutes parties d’un plan qui d´epend d’un gestionnaire de plan distant est bien ´evidemment d´ependante de cette connexion.
Quand un gestionnaire local est connect´e `a d’autres gestionnaires, il notifie ces gestionnaires distants des modifications apparues dans son plan (structure et ex´ecution). Les messages ne sont envoy´es que pour les parties du plan pour lesquelles le gestionnaire distant est souscrit.
Afin de repr´esenter la d´ependance du plan joint aux connexions, une tˆache sp´ecifique est ins´er´ee dans le plan pour tout gestionnaire de plan distant, et toutes les tˆaches qui appar-tiennent `a ce gestionnaire sontexecuted bycette tˆache. Ainsi, si la connexion est perdue – par exemple parce que le gestionnaire local a pu d´eterminer que le gestionnaire distant n’est plus capable de remplir ses engagements – l’´ev`enement ef ailed de cette tˆache est ´emis et les tˆaches correspondantes sont termin´ees.
3.4.2 Gestion d’´ev`enements joints
La gestion d’un ´ev`enement joint est bas´e sur les r`egles suivantes :
1. la commande d’un ´ev`enement joint doit ˆetre appel´ee sur tous les gestionnaires de plan `a qui appartiennent cet ´ev`enement.
2. l’´ev`enement n’est ´emis que lorsque tous les gestionnaires de plans `a qui il appartient ont annonc´e qu’ils pouvaient l’´emettre.
Ces deux r`egles permettent de repr´esenter les m´ecanismes de la th´eorie des intentions jointes de Cohen et Levesque via le syst`eme de tˆache/´ev`enement. Ainsi, une tˆache jointe peut ˆetre vue comme unbut joint persistant :
– tous les robots pensent que la tˆache n’est pas encore achev´ee – ils ont tous accept´es d’accomplir la tˆache jointe.
– ils vont tous tenter de l’accomplir tant qu’ils ne sauront pas qu’elle est accomplie ou qu’elle ne peut pas ˆetre accomplie.
3.4.3 Diff´erences `a l’ex´ecution entre plans mono et multi-robots
Lorsque le syst`eme manipule des plans joints, quelques diff´erences de comportement existent dˆus `a la perte du caract`ere synchrone de m´ecanismes de l’ex´ecution : propagation des ´ev`enements, propagation des exceptions.
De plus, le syst`eme de garbage collection doit ˆetre capable de g´erer les tˆaches qui ne sont plus directement utiles pour le gestionnaire local, mais le sont pour les gestionnaires distants.
3.5 R´ esum´ e
Ce chapitre a pr´esent´e les m´ecanismes qui rentrent en jeu au cours de l’ex´ecution de du plan.
Le cycle d’ex´ecution est bas´e sur trois phases :
1. la phase de propagation d’´ev`enements, o`u un algorithme de propagation globale permet de r´epondre aux ´ev`enements ext´erieurs.
2. la phase de gestion d’erreur, o`u les erreurs d´etect´ees pendant la phase de propagation, et les violations de contraintes pr´esentes dans le plan, sont trait´ees.
3. la phase de garbage collection, ou un algorithme d’analyse globale du plan termine les tˆaches qui ne sont plus utiles pour la r´ealisation des buts du syst`eme et les tˆaches pour lesquelles des erreurs ont ´et´e d´etect´ees.
4
Gestion de plans
Par “gestion”, nous entendons la capacit´e de modifier le plan en cours d’ex´ecution. Ce cha-pitre pr´esente d’une part lestransactions, qui sont un m´ecanisme central pour la modification des plans dans notre composant. D’autre part, il pr´esente deux op´erateurs de modification du plan qui prennent en compte l’´etat courant d’ex´ecution du syst`eme, d´emontrant le d´eveloppement d’op´erateurs de modification de plans plus complexes sur la base de notre mod`ele de plan et de notre syst`eme d’ex´ecution.
4.1 Ex´ ecution et modification simultan´ ee des plans
4.1.1 Motivation
Notre mod`ele de plan ne permet pas, `a l’ex´ecution, de v´erifier si chaque tˆache prise `a part peut ou non ˆetre ex´ecut´ee dans la situation courante. En effet, notre gestionnaire de plan s’appuie sur les relations entre tˆaches et entre ´ev`enements pour d´eterminer cela. Il est donc critique que le plan vu par l’ex´ecutif soit toujours complet : il ne doit pas y manquer d’objets ou de relations.
Cette propri´et´e doit ˆetre maintenue alors que le plan est modifi´e. `A cette fin, nous avons d´evelopp´e un m´ecanisme central dans notre syst`eme de gestion de plan : la transaction.
4.1.2 Repr´esenter les modifications du plan
Une transaction est une repr´esentation d’un ensemble de modifications qui permettront de transformer le plan courant en un nouveau plan, lui aussi complet. Cette id´ee est emprunt´ee au monde des bases de donn´ees, adapt´ee `a notre probl´ematique de gestion de plan. Dans notre syst`eme, les transactions contiennent l’ensemble des modifications n´ecessaires pour transformer le plan courant en un nouveau plan. Ces modifications peuvent ˆetre appliqu´ees au plan courant
quand la transaction est compl`ete via une op´eration de commit. Si la transaction n’est plus valide ou plus n´ecessaire, elle eut ˆetre abandonn´ee (op´eration de discard).
4.1.3 Gestion de conflits entre ex´ecution et modification du plan
La construction d’un nouveau plan est une op´eration potentiellement longue. Si nous voulons que notre syst`eme puisse ´evoluer pendant que de nouveaux plans sont construits, il est n´ecessaire de g´erer les conflits pouvant apparaˆıtre entre les modifications du plan dues `a l’ex´ecution est les modifications repr´esent´ees dans les transactions.
Nous d´efinissons un ensemble de conflits pouvant ainsi apparaˆıtre, et nous d´efinissons un cycle d’interaction entre le producteur de plan qui construit la transaction, l’ex´ecutif et un composant `a part, appel´e le contrˆole de d´ecision.
4.1.4 Transactions comme outils distribu´es de modification de plan
Le m´ecanisme des transactions est tr`es bien adapt´e `a la modification de plan distribu´ee : chaque robot peut dans une transaction librement modifier son propre plan et les plans de ses pairs. De plus, une transaction distribu´ee ne peut ˆetre appliqu´ee au plan que lorsque tous les gestionnaires de plans qui la g`erent l’acceptent. Si un consensus ne peut ˆetre atteint, la transaction est abandonn´ee. Les transactions sont donc un outil central en multi-robot pour n´egocier en se basant sur les plans.