Traduction de A c - Langage d’actions A c k ext

CHAPITRE 6 LA COORDINATION DES AGENTS DE LEOPAR++

6.1 Langage d’actions A c k ext

6.1.1 Traduction de A c

Dans cette section nous exposons la traduction du langage d’actions Ac

kext en langage

ASP. Comme le langage d’actions est uniquement un langage de représentation et ne permet pas de raisonner sur les actions, il est nécessaire de le traduire en un autre langage, en l’occur- rence ASP. La phase de traduction se réalise automatiquement à l’aide des règles suivantes :

Traduction de obviate(a, F, L)

L’axiome obviate rend une action non ex´ecutable, et ce, tant que l’ensemble des fluents F tf1, . . . , fmu sont vrais et que les fluents L tl1, . . . , lnu sont des objectifs finaux. Le

prédicat obviate joue un rôle important lors de la détermination de l’action exécutable. Il se retrouve dans l’axiome executable, défini plus loin, et indique si une action peut s’exécuter ou pas :

obviatepa, T q Ð holdspf1, Tq, ..., holdspfm, Tq, finallypl1q, ..., finallyplnq, timepT q.

Traduction de subGoal(a, F, L)

Le concept de sous-objectif est très puissant. Il permet de délimiter l’espace de recherche de l’action à exécuter si L tl1, . . . , lnu sont des objectifs finaux et F tf1, . . . , fmu sont

vrais. Noter que dès l’instant où un sous-objectif est vérifié, il interdit, par l’introduction du prédicat occSubgoal, l’exécution d’une autre action dans le mode séquentiel. Comme nous le verrons plus loin, le prédicat occSubgoal est testé dans la règle de causes.

Si F est un ensemble vide :

2toccurspa, T q, occSubgoalpT qu2 Ð finallypl1q, ..., finallyplnq, timepT q.

sinon

2toccurspa, T q, occSubgoalpT qu2 Ð holdspf1, Tq, ..., holdspfm, Tq,

Traduction de executable(a,F)

Nous traduisons l’axiome ex´ecutable comme suit en ASP :

executablepa, T q Ð holdspf1, Tq, ..., holdspfm, Tq, not obviatepa, T q, timepT q.

Traduction de uncertain(a,{Fi})

Pour des ensemblestF1, ..., Fiu avec tf11, ..., f1ju F1 et F1 F , nous traduisons l’ind´eter-

minisme comme suit :

1tF1pT q, ..., FipT qu1 Ð occurspa, T q, timepT q.

holdspf11, Tq..., holdspf1j, Tq Ð F1pT q, timepT q.

...

holdspfi1, Tq, ..., holdspfij, Tq Ð FipT q, timepT q.

Traduction de control(l,F)

L’axiome control permet de vérifier le plan d’action et de détecter des modèles d’exécution. Le plan d’exécution est dépendant des actions dont l’effet est incertain et il est nécessaire d’éviter des exécutions indésirables comme des boucles infinies. Dans l’axiome ci-dessous, le prédicat releaseGoal permet d’annuler la poursuite d’un objectif l.

releaseGoalplq Ð holdspf1, Tq, ..., holdspfm, Tq, timepT q.

Traduction de causes(a,l,F)

Cet axiome vérifie les conditions d’exécution et les effets d’une action. Notez que dès qu’une action est interdite d’exécution durant l’instant T , le prédicat obviate est vrai. Le prédicat holds permet de définir les effets de l’action a exécutée occurspa, T q. Le prédicat causes permet de prédire l’effet de l’execution d’une action au temps T . Nous traduisons la cause des actions comme suit :

executablepa, T q Ð holdspf1, Tq, ..., holdspfm, Tq, not obviatepa, T q,

holdspl, T 1q Ð occurspa, T q, actionpaq, timepT q.

causespa, l, T q Ð executablepa, T q, actionpaq, timepT q.

Traduction de prefer(a,F)

La traduction de l’axiome stipule que l’action s’exécute en préférence dès que les fluents F sont vérifiés. Dans le cas où F H, l’action est exécutée en priorité en tout temps :

si F H

2toccurspa, T q, existsP referedActionpa, T qu2 Ð executablepa, T q, causespa, cq, not holdspc, T q, holdspf1, T q, ..., holdspfm, T q, timepT q.

sinon si F H

2toccurspa, T q, existsP referedActionpa, T qu2 Ð executablepa, T q, causespa, cq, not holdspc, T q, timepT q.

Il est à noter que le prédicat existsPreferedAction se retrouve dans l’expression occurs dans le cas de l’exécution séquentielle.

Traduction des conditions d’ex´ecution

Il y existe deux modes d’exécution : séquentiel et parallèle. Le mode séquentiel, par défaut, stipule qu’à chaque étapes de temps T , une seule et unique action peut s’exécuter. Pour ce faire, nous introduisons dans la traduction ASP les contraintes suivantes :

1tpossibleActionpA, T q : actionpAqu1 Ð timepT q.

occurspA, T q Ð executablepA, T q, possibleActionpA, T q, actionpAq,

not existsP ref eredActionpA, T q, not occSubgoalpT q, not goalpT q, timepT q.

La fonction tpossibleActionpA, T q : actionpAqu Ð timepT q permet d’énumérer toutes les actions possibles pour un temps T donné. Par exemple dans le cas où T r1, 2s, A P ta, bu alors la fonction retourne les deux ensembles réponses suivants :

S1 tpossibleActionpa, 1qu

S2 tpossibleActionpb, 1qu

S3 tpossibleActionpb, 1q, possibleActionpa, 1qu

...

S16 tpossibleActionpb, 2q, possibleActionpa, 2q, possibleActionpb, 1q, possibleActionpa, 1qu

Maintenant, la fonction 1tpossibleActionpA, T q : actionpAqu1 Ð timepT q avec les valeurs numériques entourant la fonction précédente mint...umax sont une extension de la logique non monotone et indiquent au programme P que le nombre d’axiomes nbrAxiomes retournés `

a vrais respectent la contraintes min ¤ nbrAxiomes ¤ max. Cette contrainte indique qu’une seule action est sélectionnée durant chaque étape de temps, assurant ainsi la séquentialité des actions à être exécutées. La fonction retourne les ensembles réponses suivants :

S1 tpossibleActionpa, 1q, possibleActionpa, 2qu

S2 tpossibleActionpb, 1q, possibleActionpb, 2qu

S3 tpossibleActionpb, 1q, possibleActionpa, 2qu

S4 tpossibleActionpb, 2q, possibleActionpa, 1qu

Le mode parallèle parallel est une alternative au mode séquentiel. Il permet que plusieurs actions s’exécutent en parallèle. Le planificateur ASP doit toutefois s’assurer qu’il n’y a pas un accès concurrent aux données en écriture. Cette vérification se fait à l’aide du prédicat concurrentAcces. Les contraintes suivantes de parallélisme viennent remplacer les contraintes précédentes de séquentialité :

occurspA, T q Ð actionpAq, timepT q, executablepA, T q, actionpAAq, concurrentAccespA, AAq, not occurspAA, T q, not goalpT q.

concurrentAccespA, AA, T q Ð actionpAq, actionpAAq, executablepA, T q, executablepAA, T q, causespA, C1, T q, causespAA, C1, T q, timepT q.

concurrentAccespA, AA, T q Ð concurrentAccespAA, A, T q, actionpAq, actionpAAq. Ð actionpAq, concurrentAccespA, AA, T q, actionpAAq, occurspA, T q, occurspAA, T q,

timepT q.

Lors de l’exécution parallèle, il est important d’empêcher l’accès concurrents à la même res- source. Pour ce faire, la fonction concurrentAcces identifie les paires d’actions qui ne doivent pas s’exécuter en parallèle. L’axiome concurrentAcces énumère les actions qui ont un effet sur le même fluent. Par exemple, les actions movepa, bq et movepa, tableq ont pour effet consécutif onpa, bq et onpa, tableq. Ils font référence au même effet2 _{et ils ne doivent pas s’ex´}_{ecuter en}

parallèle. De même, il est interdit d’exécuter des actions qui ont des effets opposés, comme par exemple onpa, bq et onpa, bq.

La règle suivante vérifie qu’un fluent et son opposé ne peuvent coexister au même temps t. Ð holdspF, T q, holdsp F, T q, fluentpF q, timepT q.

Traduction de l’inertie

Nous traduisons les lois d’inerties (voir Lifschitz, 1999) comme suit :

holdspf, T 1q Ð timepT q, holdspf, T q, not holdsp f, T 1q. holdsp f, T 1q Ð timepT q, holdsp f, T q, not holdspf, T 1q.

Traduction des ´etats initiaux

Les états initiaux respectent l’hypothèse du monde fermé (Closed World Assumption). Nous traduisons les états initiaux comme suit :

holdspf, 0q Ð initiallypfq. holdsp f, 0q Ð not initiallypfq.

Traduction de l’objectif final

Afin de guider le processus de planifications vers l’objectif final, nous introduisons les règles suivantes. Elles intègrent l’axiome releaseGoal, qui permet d’annuler la poursuite/concrétisation

2. Dans le cas d’actions qui retournent un effet composé de plusieurs attributs, un traitement additionnel permet de détecter un accès concurrent.

d’un objectif :

f inallyGoalplq Ð finallyplq, not releaseGoalplq.

negGoalpT q Ð finallyGoalplq, not holdspc, T q, timepT q. goalpT q Ð timepT q, not negGoalpT q.

existP lanÐ goalpT q, timepT q. Ð not existP lan.

La contrainte d’intégrité existP lan fait en sorte de garder les plans qui mènent à l’objectif final. Tous les plans qui ne mènent pas à l’objectif final sont éliminés de l’espace de recherche.

Dans le document Système d'aide à la décision pour le réseau de distribution (Page 81-86)