Retours d’usage sur la conception des modèles

Eléments comparés

Nous avons utilisé pour cette comparaison deux domaines distincts, dans plusieurs configura-tions, ainsi que trois moteurs de planification, là encore avec différents ensembles de paramètres.

Domaines

La génération de scénarios a été réalisée sur deux exemples : Gas Station, un exemple très sim-plifié portant sur une opération de remplissage d’une voiture dans une station service, et Arakis, un exemple plus complet correspondant au chargement d’un camion citerne sur un dépôt pétrolier. Chaque exemple est associé à un modèle d’activité en ACTIVITY-DL, qui est utilisé pour générer un domaine de planification PDDL, auquel sont ensuite rajoutés les opérateurs de prédiction des com-portements, traduits manuellement depuis le modèle du domaine en DOMAIN-DL.
Chacun des deux exemples a été testé avec deux situations buts différentes : End, correspondant à la réalisation de la tâche principale, et Fire, qui correspond au déclenchement d’un feu. La première demande un minimum d’ajustements, tandis que la seconde en nécessite a priori davantage. Dans le cas du feu, la génération a été faite avec et sans sélection préalable d’une trame scénaristique.
De plus l’exemple Arakis, de par sa taille, a été testé avec deux modèles de domaine différents : une version Arakis-Basic, où seuls sont présents les opérateurs de prédiction des comportements corres-pondant au bon déroulement de la procédure (c’est à dire que les comportements “accidentels” — feu, fuite, etc. — ont été enlevés), et une version Arakis-Full qui comporte l’ensemble des opérateurs. Enfin, chaque exemple a été testé avec une situation initiale correspondant à la présence d’un seul agent, ou bien de deux agents.
Un troisième domaine de planification est présenté à titre de comparaison : Fake, qui contient des actions écrites à la main et non générées à partir d’un modèle d’activité, et qui ne garantit donc pas la cohérence des actions des agents. Il s’agit du domaine utilisé pour générer le plan présenté précédem-ment dans la figure 6.4. Le tableau 9.1 récapitule les caractéristiques de chaque condition.

Moteurs de planification

La génération des scénarios a été réalisée avec les trois moteurs de planification présentés précédem-ment : FF, Fast Downward et VHPOP.
FF-v2.3 a été utilisé sans modifications, ce qui correspond au moteur utilisé comme point de com-paraison lors de la compétition IPC-6 pour la catégorie “satisfaction” [Helmert et al., 2008].
Fast Downward a été testé dans deux configurations différentes : d’une part, avec une recherche A* sans heuristique (A* blind), ce qui correspond au moteur utilisé comme point de comparaison pour la catégorie “optimisation” lors de la même compétition, et d’autre part dans une configuration “lazy greedy best-first” avec deux heuristiques : FF et “context-enhanced additive”. On les notera respec-tivement F D A∗ et F DLG .
VHPOP a été également utilisé dans deux configurations : d’un côté, la configuration utilisée pour la compétition IPC-3, et de l’autre, une configuration reprenant les heuristiques et stratégies de sélec-tion de failles du moteur UCPOP sur lequel il est basé. On notera respectivement VI PC et VUC P .

Influence du moteur sur les plans générés

Le premier constat réalisé est que le choix du moteur de planification influence fortement le con-❙tenu du plan généré, et donc du scénario, et ce même sur des domaines très simples comme ●❛ ❋✐ où il n’existe qu’une seule combinaison d’ajustements permettant d’aboutir à l’événement .
La figure 9.1 présente une comparaison visuelle des plans générés à partir des conditions GF1 par trois moteurs différents : le plan (a) a été généré avec F F , le plan (b) a été généré avec F D A∗ et le plan
(c) a été généré par VI PC /VUC P (F DLG génère, comme F F , le plan (a)). Les plans (a) et (b) ont fait l’objet d’une phase de réécriture des liens de causalité pour obtenir un plan partiellement ordonné, et les opérateurs abstraits ont ensuite été supprimés des trois plans. Les graphes correspondant sont retranscrits dans l’annexe E.
On peut ainsi remarquer que le plan (b) contient le minimum d’ajustements nécessaires, tandis que le plan (a), généré par des moteurs visant un plan satisfaisant et non optimal, contient des ajuste-
ments inutiles qui mènent à un comportement de type ■❣♥♦ .
Le plan (c), dont les étapes ont été directement ordonnées par le moteur VHPOP, n’est pas optimal non plus, dans le sens où certains ajustements sont placés en début de plan alors qu’ils ne sont néces-saires que pour des étapes ultérieures. Ceci peut poser problème dans le cas où l’on doive générer un nouveau plan en cours d’exécution : ces ajustements auront alors été déclenchés inutilement, ce qui aurait pu être évité en attendant le dernier moment pour les lancer.

Validité des plans générés

Les plans générés ont été validés à l’aide du validateur PDDL INVAL 2, créé par Patrick Haslum. D’une part, nous nous sommes assurés de la validité des plans directement générés par les moteurs de planification : plans séquentiels pour F F et F D, et plans partiellement ordonnés pour V H POP . D’autre part, nous avons cherché à valider les plans générés par DIRECTOR à partir de ces moteurs en réalisant les étapes suivantes :
– complétion du graphe de points clés avec les plans intermédiaires générés par les moteurs (dans le cas où le scénario résulte de la sélection préalable d’une trame scénaristique) ;
– réécriture des liens de causalité entre les étapes ;
– traduction de ce graphe de scénario vers une représentation d’un plan partiellement ordonné en PDDL, en parcourant le graphe à partir de la situation finale et en associant à chaque étape un marqueur temporel, en suivant l’algorithme 5 décrit dans l’annexe D ;
– validation de ces plans à partir d’un problème PDDL composé de la situation initiale et de la situation but du scénario.
Un problème intéressant se pose pour la validation des plans générés par DIRECTOR à partir de do-maines comportant un seul agent et plus d’un niveau de tâches mères. On se retrouve alors dans le cas ❛❣❡♥oùles étapes ❆❜ possèdent comme effet à la fois le retrait et l’ajout du fait ✭❤❛ et que ce fait est présent dans les préconditions des étapes ❆❜❛ , qui sont considérées comme parallèles par DIRECTOR. Elles peuvent en effet être appliquées soit avant soit après ces dernières, selon que l’on considère que l’agent évalue les conditions de satisfaction de ses tâches en cours à la fin de son tour, ou au début de son tour suivant — ce qui n’a pas d’incidence sur le scénario une fois les tâches abstraites retirées. Il semblerait que INVAL considère ce cas comme un conflit (une précondition d’une étape étant rendue vraie par une étape parallèle), même si dans notre considérés comme valides par INVAL à partir du moment où les étapes sont ordonnées manuelle-ment, dans un ordre comme dans l’autre, nous considérons donc que ces plans constituent des plans partiellement ordonnées PDDL valides. Il est également à noter que VHPOP génère les plans corre-spondants comme des plans séquentiels et ne considère pas lui non plus ces étapes comme pouvant être parallèles. Une fois ce cas particulier résolu, cependant, tous les plans générés par DIRECTOR ont été considérés comme valides par INVAL.
Une meilleure mesure de la validité d’un scénario serait toutefois de valider ceux-ci après la suppres-sion des étapes abstraites : pour cela il serait nécessaire de modifier le domaine de planification en supprimant toutes les préconditions et effets des opérateurs qui ont trait à l’ordonnancement des tâches et des actions (❤❛ , , etc.).

Temps de génération des plans

Les temps obtenus pour la génération des plans dans chaque condition et par chaque moteur de configuration sont présentés dans les tableaux 9.2 et 9.3. Chaque chiffre correspond à la moyenne des temps obtenus sur trois itérations de la génération de plan.
Le tableau 9.2 présente les temps obtenus dans le cas de la génération d’un scénario sans sélection de trame scénaristique préalable, chiffres qui correspondent donc au temps mis par le moteur de planification pour générer un plan, auquel doivent être ajoutés le temps de transformation du plan séquentiel en plan partiellement ordonné pour FF et Fast Downward, et le temps de suppression des opérateurs abstraits dans tous les cas, soit entre 0.010s et 0.040s pour chacune de ces deux étapes (temps obtenus sur les générations présentées ici).
Le tableau 9.3 présente les temps obtenus pour la génération de scénario avec sélection préalable d’une trame scénaristique, ici choisie arbitrairement. La trame scénaristique utilisée pour l’exemple G comportait 3 points clés (❙♦✉❞✬■❣♥✐ , ❋✉✐et ❋❡✉), tandis que la trame utilisée pour l’ex-emple A en comportait 7 (il s’agit de celle présentée dans la figure 7.5). La première ligne de chaque exemple correspond au temps total de complétion de la trame scénaristique (temps de création des liens de causalité et de suppression des opérateurs abstraits compris), et les lignes suivantes corre-spondent aux temps de planification obtenus pour chaque itération sur les points clés.
Une durée de 120s a été fixée comme limite haute pour la génération d’un plan, durée à partir de laquelle la génération a été arrêtée manuellement ; ces cas sont indiqués dans le tableau par le sym-bole ∞. Le symbole ①représente les cas où le moteur de planification a subi un crash lors des trois tentatives de génération de plan. Le symbole − indique que la génération n’a pas pu être évaluée dans ces conditions : soit parce que la génération a été arrêtée lors d’une étape précédente pour la complétion d’une trame scénaristique, soit dans le cas de VHPOP et du domaine A pour une raison de prérequis. En effet, si VHPOP est censé prendre en compte les quantifications universelles dans les préconditions et effets des opérateurs, les heuristiques correspondantes ne sont implémentées ❋✉❧❧quelorsque les quantifications portent sur des constantes, et non sur des objets. Le domaine ❆ , qui contient de telles préconditions, n’a donc pas pu être évalué avec VHPOP.

Discussion

Des trois moteurs utilisés, seul Fast Downward s’est avéré suffisamment stable et complet pour la génération de plans sur les domaines créés par DIRECTOR. FF, qui a obtenu des résultats promet-teurs sur le domaine G, n’a pas été capable de traiter le domaine A, d’une taille plus conséquente. VHPOP, quant à lui, s’est heurté sur ce dernier à un problème de prise en compte des quantifications universelles.
La question se pose à présent de savoir si les temps obtenus par Fast Downward sont acceptables pour les besoins de DIRECTOR en termes de génération de scénarios. D’après [Porteous et al., 2010].