Description d’une m´ethode dans HATP

Dans les domaines de planification HTN, les tˆaches de haut niveau sont appel´ees m´ethodes [Nau 03]. Une m´ethode peut ˆetre d´ecompos´ee en listes partiellement ordonn´ees de sous-tˆaches. Ces sous-tˆaches sont soit des m´ethodes soit des actions. Les m´ethodes HATP sont d´ecrites par un tupl

M =< N ame, P ar, goal, D > O`u :

– N ame comme pour les actions N ame repr´esente le nom de la m´ethode, c’est un symbole qui sert `a identifier la m´ethode.

– P ar repr´esente la liste de param`etres de la m´ethode. Cette liste contient un ensemble d’entit´es.

– goal c’est une liste de conditions qui d´efinit le but ou les m´eta-effets associ´es `a la m´ethode. Si ces conditions sont respect´ees, alors la m´ethode est d´ej`a r´ealis´ee et elle est r´eduite `a un ensemble vide.

– D repr´esente une liste de couples < Pi, T Li >. Cette liste d´efinit l’ensemble des d´ecompositions possibles pour la m´ethode. Ainsi, pour chaque d´ecomposition i, si la pr´econdition Pi est valide alors la liste de tˆaches partiellement ordonn´ees T Li est une fa¸con

possible de r´ealiser la m´ethode.

Figure_{3.5 – Liste de tˆaches partiellement} ordonn´ees 1 : Ta; 2 : Tb; 3 : Tc > 1 , > 2 ; 4 : Te > 3 ; 5 : Tf > 1 ; 6 : Td > 5 , > 4 ;

Figure _{3.6 – Description de la liste de tˆaches} partiellement ordonn´ees

Pour la description d’une liste de tˆaches partiellement ordonn´ees T Li, nous avons opt´e pour la description qui est souple et lisible. A chaque tˆache pr´esente dans la liste, on associe un identifiant num´erique. Les liens causaux sont d´ecrits grˆace `a des relations de pr´ec´edences entre les identifiants num´eriques des tˆaches. Ces relations de pr´ec´edences sont d´ecrites au moyen du symbole >.

Pour illustrer cette repr´esentation, on consid`ere l’exemple illustr´e par les figures 3.5-3.6. Dans cet exemple on peut constater que les tˆaches Ta et Tb sont ind´ependantes puisqu’elles n’ont aucune contrainte, donc elles peuvent ˆetre r´ealis´ees en parall`ele. Par contre, la tˆache Tc est pr´ec´ed´ee par Ta et Tb, ce qui signifie que la tˆache Tc ne peut ˆetre r´ealis´ee qu’apr`es la r´ealisation de Ta et Tb. La tˆache Tf est contrainte par Ta, Te par Tc et enfin Td qui est pr´ec´ed´ee par Te et Tf. La figure 3.7 illustre la d´eclaration d’une m´ethode nomm´ee TransmetreObjet. Cette m´ethode permet de transmettre un objet Obj de l’agent A1 `a l’agent A2. Le but de la m´ethode est d´ecrit au niveau de la condition goal. Si cette condition est respect´ee, alors cela signifie que la tˆache est d´ej`a r´ealis´ee et qu’on n’a pas `a aller plus loin. Dans le cas contraire, on a deux fa¸cons de r´ealiser la tˆache :

1. L’agent A1 pose l’objet Obj quelque part pour l’agent A2. Cette d´ecomposition est d´efinie par la m´ethode PoserQuelquePart. Elle est autoris´ee si sa pr´econdition est valide, c’est-`a- dire si Obj est bien d´etenu par A1.

2. L’agent A1 va aller donner l’objet Obj `a l’agent A2. Comme pour la premi`ere d´ecomposition ceci est d´efini par la m´ethode AllerDonner. Elle est aussi autoris´ee si sa pr´econdition est valide.

On peut observer au niveau de la premi`ere d´ecomposition, l’apparition d’une

nouvelle variable produite par la fonction SELECT dans la d´eclaration de la tˆache

P oserQuelqueP art(A1, A2, Obj, F ). Cette fonction permet de s´electionner un ensemble de variables d’un certain type et qui satisfont certaines conditions. Dans notre exemple, la variable

method T r a n s m e t t r e O b j e t ( Agent A1 , Agent A2 , Objet Obj ) { goal { A1 ! = A2; Obj >> A2 . o b j e t s ; Obj . p o s s e s s e u r = = A2; } ; // d e c o m p o s i t i o n 1 { preconditions { A1 ! = A2; Obj >> A1 . o b j e c t s ; Obj . p o s s e s s e u r = = A1; } ; subtasks {F = SELECT( Meuble , {F . l i b r e = = t r u e ; } ) ; 1 : P o s e r Q u e l q u e P a r t (A1 , A2 , Obj , F) ; } ; } // d e c o m p o s i t i o n 2 { preconditions { A1 ! = A2; Obj >> A1 . o b j e c t s ; Obj . p o s s e s s e u r = = A1; } ; subtasks { 1 : A l l e r D o n n e r (A1 , A2 , Obj ) ; } ; } }

F doit ˆetre de type Meuble et son attribut libre doit ˆetre `a vrai (c’est-`a-dire que le meuble peut accueillir un objet). De ce fait, une d´ecomposition qui comprend la fonction SELECT ne va pas g´en´erer qu’une seule branche, mais N branches modulo la taille de l’ensemble de variables produites par la fonction.

En comparant les d´eclarations des m´ethodes dans SHOP2 et HATP, on s’aper¸coit qu’il y a les diff´erences suivantes :

– HATP int`egre `a la description de la m´ethode la description de son but. Avec SHOP2 on peut arriver au mˆeme r´esultat en ajoutant une d´ecomposition suppl´ementaire, la pr´econdition de cette d´ecomposition va repr´esenter le but de la m´ethode et sa liste de tˆaches va ˆetre un ensemble vide. Dans HATP, si le test du but de la m´ethode est valide, on ne teste pas les d´ecompositions de celle-ci, puisque la tˆache est d´ej`a r´ealis´ee. Cependant, l’algorithme de SHOP2 va tester la validit´e de toutes les d´ecompositions associ´ees `a la m´ethode.

– L’expression des contraintes de pr´ec´edences dans SHOP2 est beaucoup plus lourde que dans HATP. En effet, Dans SHOP2, pour exprimer la pr´ec´edence entre tˆaches, on utilise des expressions sp´ecifiques (: unorderd tasklist1 . . . tasklisten), (: orderd tasklist1 . . . tasklisten). Le mot cl´e : orderd sp´ecifie que la liste de tˆaches doit ˆetre r´ealis´ee dans l’ordre de la d´eclaration des tˆaches. Par opposition, le mot cl´e : unorderd indique que les tˆaches peuvent ˆetre r´ealis´ees dans n’importe quel ordre.