Benchmarks temporellement expressifs

3.6.1. Les benchmarks des IPC

La première compétition IPC s'est déroulée en 1998 avec la première version du langage PDDL. Les aspects temporels n'ont été intégrés au langage PDDL2.1 et aux benchmarks qu'en 2002 avec la tenue d'IPC'2002.

Tous les benchmarks5 temporels des compétitions IPC (y compris IPC'2008) sont des extensions des benchmarks classiques, auxquels on a simplement ajouté une durée aux actions, et où l'on a précisé les instants caractéristiques d'apparition des effets ou de nécessitation des préconditions. Comme nous l'avons déjà expliqué, [Cushing et al, 2007.b] ont démontré que tous ces domaines étaient temporellement simples. Ils proposent des modifications permettant de le vérifier facilement6. Une précondition ou un effet d'une action est dit "sûr" s'il ne peut exister de plan exécutable dans lequel cette précondition ou cet effet provoque obligatoirement un conflit entre ordre causal et ordre temporel. [Cushing et al, 2007.b] montrent que si toutes les préconditions et tous les effets des actions d'un domaine sont "sûrs", alors le domaine est temporellement simple. Ils démontrent ensuite que les effets over all, qui peuvent être soit des transitions (cf. section 3.5.2.d), soit des affectation de valeurs, sont "sûrs". Il suffit donc de modifier les domaines des compétitions IPC pour obtenir des domaines équivalents ne contenant que des préconditions et effets dont on a montré qu'ils étaient "sûrs". L'action Drive du domaine Depots est ainsi modifiée en utilisant des fluents multivalués (les modifications apparaissent en gras) :

(:durative-action Drive

:parameters (?x - truck ?y - place ?z - place)

:duration (= ?duration (/ (distance ?y ?z) (speed ?x)))

:condition (and ;;(at start (at ?x ?y))) ;; Fluent Multivalué

:effect (and ;;(at start (not (at ?x ?y))) ;; Fluent Multivalué

;;(at end (at ?x ?z)) ;; Fluent Multivalué

(over all (-> (location ?x) ?y ?z)) ;; Fluent Multivalué

))

Cette modification pourrait être réalisée sans utilisation de fluents multivalués et de manière plus simple en utilisant notre modalité "transition over" sur toute la durée de l'action sans inclure implicitement la précondition "le camion ?x se situe en ?y au début de l'action" dans les effets :

(:durative-action Drive

:parameters (?x - truck ?y - place ?z - place)

:duration (= ?duration (/ (distance ?y ?z) (speed ?x))) :condition (and (at start (at ?x ?y)))

:effect (and ;;(at start (not (at ?x ?y)))

;;(at end (at ?x ?z))

(->over all (at ?x ?z)))

))

5 _{2002 : Depots, DriverLog, ZenoTravel, Satellite, Rovers ; 2004 : Satellite, Airport, UMTS ; 2006 : Openstacks,} Pathways, Pipesworld, Storage, TPP, Trucks ; 2008 : CrewPlanning, Elevators, ModelTrain, ParcPrinter, PegSol, Sokoban, Transport, WoodWorking.

6

3.6.2. Elaboration de benchmarks temporellement expressifs

Comme les benchmarks des competitions IPC étaient inappropriés, puisque temporellement simples, nous avons mis au point plusieurs nouveaux benchmarks temporellement expressifs. Les premiers domaines que nous présentons utilisent des actions duratives de PDDL2.1. Nous avons ensuite progressivement développé des benchmarks plus expressifs et plus complexes qui intègrent des intervalles temporels, puis des modalités temporelles. Les caractéristiques des domaines et des problèmes sont aussi de natures différentes et complémentaires. Tous ces benchmarks peuvent être téléchargés à l'adresse donnée ci-dessous7.

a) Problèmes temporellement expressifs en PDDL2.1

Les trois premiers domaines étendent l'exemple de [Cushing et al., 2007.a, Figure 3] de trois manières différentes :

• les problèmes "tempo-depth-n" étendent ce problème sur un plus grand nombre de niveaux. Les plans-solutions nécessitent n "étapes" composées de triplets d'actions concurrentes.

• les problèmes "tempo-width-m" nécessitent m triplets d'actions concurrentes sur uniquement trois niveaux du graphe pour obtenir le but.

• les problèmes "tempo-matrix-n×m" combinent les difficultés des deux précédents.

Domaine tms-k-t-light : ce domaine (dérivé de temporal machine shop, [Cushing et al.,

2007.a]) est inspiré par une application du monde réel. Chaque problème tms-k-t-p, concerne l'utilisation de k fours (kilns), chacun ayant une durée de chauffe différente, pour cuire p morceaux de céramique (bake-ceramic) de t types différents. Chacun de ces types de céramique nécessite un temps de cuisson différent. Ces céramiques peuvent ensuite être assemblée pour produire différentes structures (make-structure). Les structures résultantes peuvent alors être recuites pour obtenir des structures plus grandes (bake-structure). Nous avons développé cette version "light" pour les planificateurs temporellement expressifs qui ne prennent pas en compte les actions duratives plus riches autorisant l'utilisation des intervalles temporels.

b) Problèmes utilisant des intervalles temporels

Ces problèmes utilisent les actions duratives plus riches telles qu'elles sont définies dans [Smith, 2003], pour lesquelles les préconditions ou les effets peuvent se réaliser sur des intervalles quelconques relatifs au début ou à la fin des actions. Nous avons étendu le domaine tms-2-3-light en utilisant ces intervalles temporels (domaine tms-2-3) et développé un nouveau domaine relatif à la cuisine.

Domaine Cooking : ce domaine permet de planifier la préparation d'un repas, ainsi que sa

consommation en respectant des contraintes de maintien de température. Les problèmes cooking-carbonara-n que nous avons utilisés pour ces tests permettent de planifier la préparation de n plats de pâtes à la carbonara. Ici encore, la concurrence des actions est obligatoire pour obtenir le but. En effet, il est nécessaire que les plaques électriques fonctionnent pour que l'eau et l'huile soient chaudes afin de cuire les pâtes et les lardons. Il est également nécessaire d'effectuer ces cuissons en parallèle pour pouvoir servir un plat dont

7

tous les éléments soient chauds sur toute la durée de consommation. Nous donnons ici, en utilisant les extensions de [Smith, 2003], le codage de l'action boiling-water :

(:durative-action boiling-water

:parameters (?p - cooking-plate ?w - water-pan) :duration (= ?duration 10)

:condition (and (over [start end[ (ready ?p)))

:effect (and (over [start (+ start 2)[ (not (hot-water ?w))) (over [(+ start 2) end] (hot-water ?w))))

Avec les intervalles de [Smith, 2003], le domaine comprend 8 opérateurs. Sa traduction en PDDL2.1 en décomposant certaines actions en actions plus simples, que nous apellerons

cooking-pddl2.1, en comprend 18. Nous donnons ici la décomposition en PDDL2.1 de

l'action boiling-water :

(:durative-action boiling-water

:parameters (?p - cooking-plate ?w - water-pan) :duration (= ?duration 10)

:condition (and (over all (ready ?p))

(at end (boiling-water-finished ?p ?w))) :effect (and (at start (boiling-water-ing ?p ?w))

(at start (boiling-water-enabled-part1 ?p ?w)) (at start (not (hot-water ?w)))))

(:durative-action boiling-water-part1

:parameters (?p - cooking-plate ?w - water-pan) :duration (= ?duration 2)

:condition (and (over all (boiling-water-ing ?p ?w))

(over all (boiling-water-enabled-part1 ?p ?w))) :effect (and (at end (not (boiling-water-enabled-part1 ?p ?w))) (at end (boiling-water-enabled-part2 ?p ?w)))) (:durative-action boiling-water-part2

:parameters (?p - cooking-plate ?w - water-pan) :duration (= ?duration 8)

:condition (and (over all (boiling-water-ing ?p ?w))

(over all (boiling-water-enabled-part2 ?p ?w))) :effect (and (at start (hot-water ?w))

(at end (not (boiling-water-enabled-part2 ?p ?w))) (at end (boiling-water-finished ?p ?w))))

c) Problèmes utilisant les modalités sur les intervalles temporels

Domaine temporal-machine-shop-k-t : ce domaine étend le domaine "tms-k-t-light". Pour

représenter des domaines plus proches de la réalité nous avons défini un langage plus expressif (cf. section 3.5). Nous donnons ici la description complète du problème tms-2-3-03 issu du domaine temporal-machine-shop-2-3. Si l'on utilise toute l'expressivité de TLP-GP pour décrire ce domaine, on peut introduire une incertitude sur l'instant où un four commencera à être suffisamment chaud après le démarrage d'une action fire-kiln (somewhere [start (+ start 1)] (ready ?k)), puis pour garantir le maintien de cet état sur une durée fixée (over [(+ start 1) end[ (ready ?k)). Par ailleurs, il est possible que la cuisson d'une céramique prenne moins de temps que prévu, et nous pouvons également représenter l'incertitude sur l'instant exact où cette cuisson va se terminer (somewhere [(- end 5) end] (baked ?p)). L'utilisation d'un état initial daté permet de définir une plage durant laquelle l'énergie nécessaire au fonctionnement des fours sera disponible (over [0 30[ (energy)) et après laquelle elle ne le sera plus ((at 30 (not (energy)))). Nous pouvons aussi représenter le fait que les poteries cuites seront disponibles (pour livraison par exemple) sur certaines plages temporelles. La structure p1/p2 devra être prête sur l'ensemble d'un intervalle temporel (over [30 40] (baked-structure p1 p2)), alors que la céramique p3 devra être prête sur un intervalle

de durée 5, mais que le planificateur pourra placer n'importe quand dans un intervalle plus grand fixé (minimal-duration 5 anywhere [30 40] (baked p3)).

(define (domain domain-tms-2-3)

(:requirements :strips :typing :durative- actions)

(:types

piecetype1 piecetype2 piecetype3 – piece kiln8 kiln20 – kiln)

(:predicates (energy ) (ready ?k – kiln) (baking ?p – piece) (treated ?p – piece) (baked ?p – piece)

(structured ?p1 - piece ?p2 – piece) (baked-structure ?p1 - piece ?p2 - piece)) (:durative-action fire-kiln1

:parameters (?k – kiln8) :duration (= ?duration 8) :condition (over all (energy )) :effect (and

(somewhere [start (+ start 1)]

(ready ?k))

(over [(+ start 1) end[ (ready ?k)) (at end (not (ready ?k)))))

(:durative-action fire-kiln2 :parameters (?k – kiln20) :duration (= ?duration 20) :condition (over all (energy )) :effect (and

(somewhere [start (+ start 2)]

(ready ?k))

(over [(+ start 2) end[ (ready ?k)) (at end (not (ready ?k)))))

(:durative-action bake-ceramic1

:parameters (?p - piecetype1 ?k – kiln) :duration (= ?duration 15)

:condition (over all (ready ?k)) :effect (and

(over [start end[ (not (baked ?p))) (over [start end[ (baking ?p)) (at end (not (baking ?p)))

(somewhere [(- end 5) end] (baked ?p)))) (:durative-action bake-ceramic2

:parameters (?p - piecetype2 ?k – kiln) :duration (= ?duration 10)

:condition (over all (ready ?k)) :effect (and

(over [start end[ (not (baked ?p))) (over [start end[ (baking ?p)) (at end (not (baking ?p)))

(somewhere [(- end 3) end] (baked ?p)))) (:durative-action bake-ceramic3

:parameters (?p - piecetype3 ?k – kiln) :duration (= ?duration 5)

:condition (over all (ready ?k))

(over [start end[ (not (baked ?p))) (over [start end[ (baking ?p)) (at end (not (baking ?p)))

(somewhere [(- end 1) end] (baked ?p)))) (:durative-action treat-ceramic1

:parameters (?p – piece) :duration (= ?duration 3)

:condition (over all (baking ?p)) :effect (at end (treated ?p))) (:durative-action treat-ceramic2 :parameters (?p – piecetype2) :duration (= ?duration 2)

:condition (over all (baking ?p)) :effect (at end (treated ?p))) (:durative-action treat-ceramic3 :parameters (?p – piecetype3) :duration (= ?duration 1)

:condition (over all (baking ?p)) :effect (at end (treated ?p))) (:durative-action make-structure :parameters (?p1 - piece ?p2 – piece) :duration (= ?duration 1)

:condition (and (over all (baked ?p1)) (over all (treated ?p1)) (over all (baked ?p2)) (over all (treated ?p2)))

:effect (at end (structured ?p1 ?p2))) (:durative-action bake-structure :parameters

(?p1 - piece ?p2 - piece ?k – kiln) :duration (= ?duration 3)

:condition (and (over all (ready ?k))

(over all (structured ?p1 ?p2))) :effect (and

(over [start end[

(not (baked-structure ?p1 ?p2))) (at end (baked-structure ?p1 ?p2)))))

(define (problem tms-2-3-03) (:domain domain-tms-2-3) (:objects k1 – kiln8 k2 – kiln20 p1 – piecetype1 p2 – piecetype2 p3 – piecetype3) (:init (over [0 30[ (energy )) (at 30 (not (energy )))) (:goal (and

(over [30 40] (baked-structure p1 p2)) (minimal-duration 5 anywhere [30 40]

Nous allons maintenant présenter les résultats des tests expérimentaux que nous avons réalisés en utilisant ces benchmarks pour comparer TLP-GP avec d'autres planificateurs temporels.