Effiziente Behandlung von Dekompositionsaxiomen in Panda 2 Projektbericht

Universität Ulm 89069 Ulm Deutschland Fakultät für Ingenieurwissenschaften, Informatik und Psychologie Institut für Künstliche Intelligenz Effiziente Behandlung von Dekompositionsaxiomen in Panda 2 Projektbericht Vorgelegt von: Louisa Pragst Gutachter: Prof. Dr. Susanne Biundo-Stephan Betreuer: Pascal Bercher Gregor Behnke 2015

Fassung 2. August 2015 c 2015 Louisa Pragst This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/de/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. Satz: PDF-L A TEX 2ε

Zusammenfassung Dieser Bericht für das Projekt Anwendung von Planungstechnologie und probabilistischem Schließen an der Universität Ulm beschäftigt sich mit der Umsetzung von abstrakten Literalen und Dekompositionsaxiomen im Planungssystem Panda 2. Zur Behandlung von Dekompositionsaxiomen gibt es zwei Möglichkeiten: die native Umsetzung, bei der sie in den Planungsprozess integriert werden, und die Kompilierung, bei der das Modell vor Beginn des Planungsprozesses in ein äquivalentes Modell ohne Dekompositionsaxiome überführt wird. Der Planer Panda 2 verwendet die zweite Variante. Dabei kann es zu hohen Laufzeiten kommen und in bestimmten Fällen kann das kompilierte Modell das in From Abstract Crisis to Concrete Relief [BS01] definierte Legalitätskriterium verletzen. Im Verlauf des Projekts wurde die Implementierung der Vorverarbeitung von Panda 2, die der Behandlung von Dekompositionsaxiomen dient, verändert. Ziel dieser Änderung ist es, die Laufzeit der Vorverarbeitung zu verringern und die Legalität der Domäne auch nach der Vorverarbeitung zu gewährleisten. Der Hauptteil dieses Projektberichts beschreibt daher, wie die Vorverarbeitung vor und nach Beginn des Projekts implementiert wurde, und vergleicht die Auswirkung der Änderungen auf die Laufzeit. Die Implementierung des Kompilierungsprozesses wird in dieser Arbeit erstmals systematisch beschrieben. Zusätzlich wird beschrieben, wie eine Behandlung von abstrakten Literalen und Dekompositionsaxiomen ohne Vorverarbeitung ermöglicht werden kann, also eine native Umsetzung durch den Planer ohne Kompilierung. iii

Inhaltsverzeichnis 1 Einleitung 1 2 Der hybride Planungsformalismus 5 2.1 Die logische Sprache.............................. 5 2.2 Zustände und Zustandsübergänge....................... 6 2.3 Pläne...................................... 7 2.4 Dekompositionsmethoden und Dekompositionsaxiome........... 7 2.5 Legalität von Dekompositionsmethoden................... 10 2.6 Das hybride Domänenmodell und das hybride Planungsproblem...... 10 3 Panda 2 13 3.1 Vorverarbeitung................................. 13 3.2 Der Planungsalgorithmus........................... 15 4 Nicht-native Implementierung von Dekompositionsaxiomen 17 4.1 Ursprüngliche Kompilierung.......................... 17 4.1.1 Vorgehen................................ 17 4.1.2 Diskussion der ursprünglichen Kompilierung............. 24 4.2 Geänderte Kompilierung............................ 25 4.2.1 Ausnutzen der Erreichbarkeitsanalyse................ 25 4.2.2 Berücksichtigung des Implementierungskriteriums.......... 29 4.2.3 Evaluation................................ 31 5 Native Implementierung von Dekompositionsaxiomen 39 5.1 Open Precondition Flaw............................ 39 5.2 Abstract Task Flaw............................... 48 5.3 Causal Threat Flaw.............................. 49 5.4 Zusammenfassung............................... 50 6 Zusammenfassung und Ausblick 51 A Änderungen an Panda 2 auf Code-Ebene 53 B Gegenüberstellung des Programmablaufs vor und nach Beginn des Projektes 57 v

1 Einleitung Möchte ein Mensch etwas planen, z.b. eine Reise, setzt er sich zunächst grobe Ziele wie Ich muss von Ulm nach Berlin fahren. Dabei ist ihm bewusst, dass es mehrere Möglichkeiten gibt, das zu tun; er könnte mit dem Auto fahren oder mit dem Zug. Diese Möglichkeiten haben verschiedene Voraussetzungen und unterschiedliche Konsequenzen. Wird die Autofahrt gewählt, muss der Mensch einen Führerschein und ein Auto haben. Bei der Zugfahrt muss dagegen ein Ticket gekauft werden. Abhängig von den äußeren Umständen muss er sich also im Verlauf des Planens für eine dieser Möglichkeiten entscheiden. Es kann aber nützlich sein, solche Entscheidungen erst später zu treffen. Betrachtet man dagegen die Planung mit einem Computer, besteht diese zunächst aus drei großen Komponenten: dem Modell, dem Problem und dem Planer. Das Modell bildet relevante Teilbereiche der Welt ab. Dazu gehört unter anderem, welche Klassen von Objekten existieren, in welchen Verhältnissen sie zueinander stehen können und welche Aktionen möglich sind. Das könnte etwa sein, dass es Züge und Autos gibt und man mit ihnen fahren kann, um an einen anderen Ort zu gelangen. Das Problem definiert einen Ausgangszustand und welcher Zustand von dort aus erreicht werden soll, z.b. Ich bin in Ulm und Ich möchte nach Berlin. Diese beiden Komponenten werden üblicherweise mit Hilfe einer formalen Beschreibungssprache, wie z.b. PDDL oder XML, modelliert. Der Planer ist ein Programm, das diese Modelle als Eingabe bekommt und einen Plan ausgeben soll, durch dessen Ausführung der Ausgangszustand in den Zielzustand überführt werden kann. Um Menschen einen möglichst einfachen Umgang mit diesen Komponenten zu ermöglichen, ist es sinnvoll, sie an das menschliche Planen anzupassen. Eine Möglichkeit dafür ist das hybride Planen [BS01]. Während der Erstellung eines Modells bietet das hybride Planen die Möglichkeit eine abstrakte Aktion reise(ulm, BERLIN, LOUISA) anzugeben, und zu dieser die Aktionen reise_mit_auto(ulm, BERLIN, LOUISA) und reise_mit_zug(ulm, BERLIN, LOUI- SA) als mögliche Differenzierungen, wie in Abb. 1.1 dargestellt. Dadurch kann Expertenwissen über die Umsetzung gewisser Aufgaben in das Modell einfließen. Die Erstellung des Modells wird auf diese Weise für den Modellierer intuitiver, da sie dem eigenen Vorgehen ähnelt. Es stellt sich nun die Frage, wie für eine abstrakte Aktion Vor- und Nachbedingungen angegebenen werden können. Sowohl die Autofahrt als auch die Zugfahrt haben klar definierte Vor- und Nachbedingungen, die sich voneinander unterschieden. Für die abstrakte Aktion kann nicht festgelegt werden, dass auf jeden Fall ein Zugticket benötigt wird, und genau sowenig, dass unbedingt ein Auto vorhanden sein muss. Daher kann man entsprechende Bedingungen nicht in die Vorbedingung der abstrakten Aktion aufnehmen. 1

1 Einleitung reise_moeglich(louisa) reise(ulm, BERLIN, LOUISA) mit dem Auto mit dem Zug hat_fuehrerschein(louisa) verfuegbar(auto, LOUISA) reise_mit_auto(ulm, BERLIN, LOUISA) hat_zugticket(louisa) reise_mit_zug(ulm, BERLIN, LOUISA) Abbildung 1.1: Beispiel für eine abstrakten Aktion reise(ulm, BERLIN, LOUISA), die durch die Aktionen reise_mit_auto(ulm, BERLIN, LOUISA) und reise_mit_zug(ulm, BERLIN, LOUISA) weiter differenziert werden kann. Stattdessen wird im hybriden Planen eine zusätzliche Bedingung und ein Dekompositionsaxiom, das diese näher definiert, verwendet. Ein Dekompositionsaxiom gibt an, für welche anderen Bedingungen eine Bedingung stehen kann. So kann der Modellierer die Bedingung reise_moeglich(louisa) einführen und als Vorbedingung für die abstrakte Aktion verwenden. Durch ein Dekompositionsaxiom bekommt reise_moeglich(louisa) dann die Bedeutung ( auto V Auto : (hat_fuehrerschein(louisa) verfuegbar(auto, LOUISA))) (hat_zugticket(louisa)). Die Reise ist also möglich, wenn die Person entweder ein Auto und einen Führerschein hat oder aber ein Zugticket. Die Verwendung von Dekompositionsaxiomen hat verschiedene Vorteile. Ohne Dekompositionsaxiome müsste die Vorbedingung von reise(ulm, BERLIN, LOUISA) leer bleiben; das würde bedeuten, dass die Aktion immer ausführbar erscheint. Das Modell wäre weniger präzise, da eigentlich bekannte und relevante Informationen nicht enthalten sind. Weiterhin ist eine leere Vorbedingung für die abstrakte Aktion für den Modellierer sehr unintuitiv, da ihm bewusst ist, dass die Aktion nicht immer ausgeführt werden kann, und er auch in der Lage ist, Bedingungen für die Ausführung anzugeben. Ein entsprechender Test ist außerdem in der Lage zu überprüfen, ob eine Differenzierung zu einer abstrakten Aktion passt. Damit kann der Modellierer bei der Erstellung seines Modells unterstützt werden, z.b. würde ein Fehler festgestellt werden, wenn die Vorbedingung von reise_mit_zug(ulm, BERLIN, LOUISA) versehentlich leer wäre. Wenn die Vorbedingung der abstrakten Aktion ebenfalls leer wäre, ließe sich kein Fehler feststellen. Ein weiterer Vorteil ist, dass während des Planens früher festgestellt werden kann, ob ein abstrakter Task nicht ausführbar ist. Damit kann der Suchraum um ein Vielfaches verkleinert werden. Der Planer hat nun verschiedene Möglichkeiten, Dekompositionsaxiome zu behandeln. Zum einen können sie nativ umgesetzt werden. Das bedeutet, dass bestehende Planungsalgorithmen und Heuristiken angepasst werden müssen, um mit Dekompositionsaxiomen umgehen zu können. Eine andere Möglichkeit wäre, in einem Vorverarbeitungsschritt Bedingungen mit Dekompositionsaxiom mit Hilfe von Kompilierung durch ihre Dekom- 2

position zu ersetzen. Das ursprüngliche Modell wird dabei in ein äquivalentes Modell ohne Dekompositionsaxiome umgewandelt. Planer und Heuristiken müssen in diesem Fall nicht angepasst werden, man profitiert dann allerdings auch nicht von den Vorteilen von Dekompositionsaxiomen für die Planung. Im Rahmen des Projektmoduls Medieninformatik wird der hybride Planer Panda 2 betrachtet. Dieser Planer implementiert in der aktuellen Version die Umsetzung der Dekompositionsaxiome durch Vorverarbeitung. Beispielsweise würde die Aktion reise mit der Vorbedingung reise_moeglich während der Vorverarbeitung in zwei Aktionen mit den Vorbedingungen hat_zugticket(louisa) bzw. hat_fuehrerschein(louisa) verfuegbar(auto, LOUISA) aufgeteilt werden. Dadurch bleiben alle Vorteile während der Modellierung erhalten, während gleichzeitig der Planungsprozess nicht geändert werden muss (solche Änderungen wären umfangreich und werden in Kapitel 5 angesprochen). Diese Vorgehensweise schränkt allerdings die Flexibilität bei der Präsentation von Plänen ein, da Pläne nur für das kompilierte Modell erstellt werden können. Wenn Pläne auch abstrakte Aktionen enthalten können, ist es möglich, dem Problemsteller, abhängig von dessen Vorwissen, mehr oder weniger detailreiche Lösungen zu präsentieren, so dass er weder über- noch unterfordert wird. Durch die Vorverarbeitung von Panda 2 kommt es zu einem Blowup bzgl. der Größe der Domäne. Die Zeit für die Vorverarbeitung steigt dabei so stark an, dass manche Domänen nicht mehr sinnvoll bearbeitet werden können. In dieser Arbeit wird erstmals der Kompilierungsprozess von Panda 2 beschrieben, so dass nachvollziehbar wird, wie es zu dieser Explosion kommt. Die Implementierung von Panda 2 wird so geändert, dass für Domänen mit vielen Dekompositionsaxiomen die Zeit für die Vorverarbeitung der Domäne verringert wird. Außerdem wird in dieser Arbeit die native Umsetzung von Dekompositionsaxiomen betrachtet, um in Zukunft das Erstellen von Plänen mit an den Nutzer angepassten Abstraktionsebenen zu ermöglichen. Im zweiten Kapitel wird zunächst der zugrundeliegende hybride Planungsformalismus beschrieben. Kapitel 3 beschreibt Panda 2 in der Form, in der es vor diesem Projekt vorlag. Daraufhin werden in Kapitel 4 die Änderungen vorgestellt, die eine schnellere Vorverarbeitung von Dekompositionsaxiomen ermöglichen, während Kapitel 5 erläutert, wie Dekompositionsaxiome nativ umgesetzt werden könnten. Zuletzt erfolgt eine Zusammenfassung der Erkenntnisse und ein Ausblick auf künftige Arbeiten. 3

2 Der hybride Planungsformalismus Die Implementierung von Panda 2 basiert auf dem hybriden Planungsformalismus, der u.a. in From Abstract Crisis to Concrete Relief [BS01] und Hybrid Planning and Scheduling [Sch09] beschrieben wird. Dieses Kapitel bietet einen kurzen Überblick über die für diese Arbeit relevanten Aspekte dieses Planungsformalismus. 2.1 Die logische Sprache Als Grundlage für den hybriden Planungsformalismus dient eine logische Sprache L. Diese ist gegeben durch: L = (Z,, FR r, FR f, FR r, FR f, FC, FV) Z ist eine endliche Menge von Sortensymbolen; die Subsortenbeziehung wird über die endliche Menge definiert, die eine Halbordnung 1 auf Z festlegt. FR r, FR f, FR r und FR f sind Z*-indizierte Familien 2 von disjunkten, endlichen Mengen von Relationssymbolen. Es wird R r als die Menge aller rigiden, primitiven Relationssymbole definiert, R f als die Menge aller flexiblen, primitiven Relationssymbole, R r als die Menge aller rigiden, abstrakten Relationssymbole und R f als die Menge aller flexiblen, abstrakten Relationssymbole. Ob ein Relationssymbol rigide oder flexibel ist, wirkt sich auf seine Verwendbarkeit in Zustandsübergängen aus, was in Abschnitt 2.2 näher erläutert wird. Die indizierte Menge von FR r ist eine Partition von R r, die indizierte Menge von FR f eine Partition von R f, die indizierte Menge von FR r eine Partition von R r und die indizierte Menge von FR f eine Partition von R f. FC bezeichnet eine Z-indizierte Familie von disjunkten, endlichen Mengen von Konstantensymbolen und FV eine Z-indizierte Familie von disjunkten, unendlichen Mengen von Variablensymbolen. Die Menge aller Konstantensymbole wird mit C bezeichnet, die Menge aller Variablensymbole mit V. In den Beispielen, die diese Arbeit verwendet, werden Variablensymbole klein geschrieben; Sortensymbole beginnen mit einem Großbuchstaben und Konstantensymbole werden komplett in Großbuchstaben notiert. Zur Verbesserung der Lesbarkeit wird außerdem FR r (z 1,..., z n ), also die Menge rigider, primitiver Relationssymbole, die durch das Tupel 1 Man spricht von einer Halbordnung, falls z i, z j, z k Z gilt: Reflexivität: (z i, z i) Antisymmetrie: (z i, z j) (z j, z i) z i = z j Transitivität: (z i, z j) (z j, z k ) (z i, z k ) 2 Seien X und Y Mengen. Als X-indizierte Familie von Elementen aus Y wird eine Abbildung von X nach Y bezeichnet, mit X Y : x y x. 5

2 Der hybride Planungsformalismus (z 1,..., z n ) Z* indiziert wird, mit R r,(z1,...,z n) bezeichnet; für die übrigen Familien wird diese Schreibweise analog verwendet. Ein Literal r(φ 1,..., φ n ) besteht aus einem Relationssymbol r R r,(z1,...,z n) R f,(z1,...,z n) R r,(z1,...,z n) R f,(z1,...,z n) und Konstanten- bzw. Variablensymbolen φ i C zi V zi, i {1,..., n}. Abkürzend wird in dieser Arbeit auch r( φ), mit φ = φ 1,..., φ n, verwendet. Literale können entweder positiv (r( φ)) oder negativ ( r( φ)) sein. Durch das Literal werden φ 1,..., φ n zueinander in die Beziehung gesetzt, die von r repräsentiert wird. 2.2 Zustände und Zustandsübergänge Ein Model M für eine logische Sprache L ist durch ein Tupel (D, S, I) gegeben; mit der Z-indizierten Familie von Trägermengen D, der Menge von Zuständen S und der zustandsunabhängigen Interpretation I. Ein Zustand s S ist dabei eine Funktion s : R f {x x D*} : r {(x 1,..., x n ) x i D zi, i {1,..., n}}, wobei r R f,(z1,...,z n). Die Interpretation I weist zum einen Konstantensymbolen Elemente der entsprechenden Trägermengen zu, I : C D : c x, mit c C z, x D z. Zum anderen wird von I jedes rigide Relationssymbol auf eine Menge passender Relationen abgebildet, I : R r {x x D*} : r {(x 1,..., x n ) x i D zi, i {1,..., n}}, wobei r R r,(z1,...,z n). Um Variablensymbole zu Elementen der Trägermenge zuzuordnen, werden Belegungen β : V D : v x mit v V z, x D z verwendet. Für ein positives Literal r( φ), einen Zustand s S, ein Model M und eine Belegung β sagt man r( φ) ist gültig in s genau dann, wenn (I β (φ 1 ),..., I β (φ n )) I(r) für rigide Relationssymbole und (I β (φ 1 ),..., I β (φ n )) s(r) für flexible Relationssymbole gilt. Dabei ist I β (φ) für φ V gleich β(φ) und für φ C gleich I(φ). Das negative Literal r( φ) gilt genau dann in Zustand s, wenn r( φ) in s nicht gilt. Die Notation für Gültigkeit ist s = M,β r( φ). Ein Task t ist definiert als Tupel ( v, prec, post). Dabei ist v V; prec und post stellen die Vor- bzw. Nachbedingung von t dar und sind Konjunktionen von Literalen, die ausschließlich Konstantensymbole aus C oder Variablensymbole aus v enthalten. Ein Task ist genau dann grundiert, wenn über ein Model M = (D, S, I) und eine Belegung β allen Variablensymbolen aus v sowie allen verwendeten Konstantensymbolen passende Elemente der Trägermenge zugeordnet werden. Man unterscheidet primitive und abstrakte Tasks. Die Vorbedingung prec eines primitiven Tasks darf ausschließlich Relationssymbole aus R r und R f enthalten; die entsprechende Nachbedingung post nur Relationssymbole aus R f. Für einen abstrakten Task sind zusätzlich abstrakte, flexible Relationssymbole in post und sowohl rigide als auch flexible abstrakte Relationssymbole in prec erlaubt. Um einen Zustandsübergang zu erreichen, wird ein primitiver, grundierter Task t auf einen Zustand s angewandt. Abstrakte Tasks können nicht direkt auf Zustände angewendet werden; sie müssen in primitive Tasks zerlegt werden. Eine Erläuterung dieser Zerlegung bietet Abschnitt 2.4. Die Anwendung eines primitiven, grundierten Tasks t auf einen Zustand s für ein Model 6

2.3 Pläne M und eine Belegung β ist möglich, wenn s = M,β prec 3 gilt. Wird der Task t auf den Zustand s angewandt, überführt er diesen in einen Zustand s, was als (s, s ) = M,β t notiert wird. Der Zustand s entsteht aus s, indem für jedes positive Literal r( φ) das Tupel (I β (φ 1 ),..., I β (φ n )) in die Menge s(r) aufgenommen wird; für jedes negative Literal r( φ) wird der entsprechende Tupel gegebenenfalls aus s(r) entfernt. Daher gilt s = M,β post. Eine Tasksequenz, notiert als t 1 t 2, überführt einen Zustand s genau dann in einen Zustand s, wenn gilt: s S : ((s, s ) = M,β t 1 ) ((s, s ) = M,β t 2 ). Man schreibt dafür (s, s ) = M,β (t 1 t 2 ). 2.3 Pläne Ein Plan P ist definiert als ein Tupel (T, <, VC, CL). T bezeichnet eine endliche Menge von Planschritten (l, t). Mithilfe des Labels l werden mehrfach vorkommende Tasks t voneinander unterscheidbar gemacht. Die Menge < gibt die Ausführungsreihenfolge der Planschritte vor und ist eine Halbordnung auf T. Ihre Elemente werden als Ordnungsconstraints bezeichnet. VC ist eine endliche Menge von (Un-)Gleichungen der Form (v = φ) oder (v φ) für v V und φ V C. Die Gleichungen stellen die geltenden Variablenconstraints dar. Die Menge CL enthält die kausalen Links, Tupel der Form (t i, t j, r( x)) mit einem Literal r( x) und t i, t j T. Für alle kausalen Links muss gelten, dass r( x) Konjunktionsglied der Vorbedingung des Tasks von t j und Konjunktionsglied der Nachbedingung des Tasks von t i ist. Dann sichert der Kausale Link zu, dass zwischen der Ausführung von t i und t j kein anderer Task r( x) verändert. Man bezeichnet daher auch r( x) als geschützt durch den kausalen Link (t i, t j, r( x)). Damit schafft t i eine Voraussetzung dafür, dass t j ausgeführt werden kann. 2.4 Dekompositionsmethoden und Dekompositionsaxiome Um festzulegen, wie ein abstrakter Task t zerlegt werden kann, werden Dekompositionsmethoden für diesen Task verwendet. Jeder abstrakte Task muss mindestens eine Dekompositionsmethode haben. Eine solche Methode µ ist als Tupel (t, P, VC) definiert. Dabei ist P der Plan, der t implementiert, und VC sind zusätzliche Variablenconstraints, die Variablensymbole aus t mit Variablensymbolen aus P identifizieren. Abstrakte Tasks können in der Regel auf mehr als nur eine Weise zerlegt werden. Da sich die Pläne der Dekompositionsmethoden in ihren Bedingungen oder Effekten unterscheiden können, dürfen Relationssymbole aus R r R f R r R f für die Vorbedingung und aus R r R r für die Nachbedingung abstrakter Tasks verwendet werden. Auf diese 3 Für prec = r 1( φ 1)... r n( φ n) gilt s = M,β prec genau dann, wenn s = M,β r 1( φ 1)... s = M,β r n( φ n). Für die übrigen logischen Operatoren kann analog vorgegangen werden. 7

2 Der hybride Planungsformalismus Weise können bereits auf abstrakter Ebene Abhängigkeiten zwischen Tasks berücksichtigt werden. Durch ein Dekompositionsaxiom δ wird festgelegt, für welche anderen Ausdrücke ein abstraktes Literal r( φ) stehen kann. Dekompositionsaxiome wurden erstmals in From Abstract Crisis to Concrete Relief [BS01] eingeführt und in Hybrid Planning and Scheduling [Sch09] ausführlicher erläutert. Ein Dekompositionsaxiom δ wird notiert als r( φ) σ, wobei σ eine DNF über Relationssymbole aus R f R r R r R f ist. Das abstrakte Literal r( φ) kann durch jedes Disjunktionsglied aus σ konkretisiert werden. Sei r( φ) ein abstraktes Literal, seien r x y x ( φ x y x ), x {1,..., n}, y x {1,..., m x } zerlegende Literale und seien φ x w x, x {1,..., n}, w x {1,..., h x } diejenigen Variablensymbole, die nicht in φ, aber in einem φ x y x vorkommen. Dann repräsentiert die Notation r( x) σ eine Formel der Form: ( φ : r( φ)) ( φ 1 1... φ 1 h 1 : r 1 1( φ 1 1)... r 1 m 1 ( φ 1 m 1 ))... ( φ n 1... φ n h n : r n 1 ( φ n 1 )... r n m n ( φ n m n )) Nun kann auch die Gültigkeit von abstrakten Literalen definiert werden. Für ein positives, abstraktes Literal r( φ) mit dem Dekompositionsaxiom r( x) σ, einen Zustand s S, ein Model M und eine Belegung β sagt man r( φ) ist gültig in s genau dann, wenn s = M,β σ. Das negative Literal r( φ) gilt genau dann in Zustand s, wenn r( φ) in s nicht gilt. Durch die Einführung von abstrakten Literalen und ihren Dekompositionsaxiomen können implizit Disjunktionen in der Nachbedingung enthalten sein. Im Bereich des probabilistischen Planens gibt es ebenfalls Disjunktionen in der Nachbedingung. Zwischen diesen beiden Anwendungen der Disjunktion muss aber unterschieden werden. Im probabilistischen Planen steht eine Disjunktion in der Nachbedingung für Nichtdeterminismus, z.b. Unsicherheit über die Auswirkungen einer Handlung. Der erstellte Plan muss funktionieren, egal welcher Effekt eintritt. Die Disjunktion in einem Dekompositionsaxiom wird dagegen verwendet, um die verschiedenen Möglichkeiten der Zerlegung eines abstrakten Tasks exakt darstellen zu können. Während der Planung wird durch die Dekomposition der Effekt festgelegt. Der erstellte Plan kann auf diesen Effekt angewiesen sein um zu funktionieren. Betrachten wir nun noch einmal das Beispiel aus der Einleitung. Es existieren zwei Tasks: reise_mit_auto(stadt1, stadt2, person, auto) PRE hat_fuehrerschein(person) in(stadt1, person) verfuegbar(auto, person) POST ausgeruht(person) in(stadt1, person) in(stadt2, person) 8

reise_mit_zug(stadt1, stadt2, person) PRE in(stadt1, person) hat_ticket(person) anschluss_verpasst(person) POST ausgeruht(person) in(stadt1, person) in(stadt2, person) 2.4 Dekompositionsmethoden und Dekompositionsaxiome Diese sollen zu dem abstrakten Task reise(stadt1, stadt2, person) zusammengefasst werden. Dabei stellen stadt1, stadt2, person und auto Variablensymbole mit passender Sorte dar. Man definiert nun reise(stadt1, stadt2, person) als: reise(stadt1, stadt2, person) PRE in(stadt1, person) reise_moeglich(person) POST in(stadt1, person) in(stadt2, person) Das Dekompositionsaxiom zu reise_moeglich wäre dann: person V Person : reise_moeglich(person) auto V Auto : hat_fuehrerschein(person) verfuegbar(auto, person) hat_ticket(person) anschluss_verpasst(person). Die Nachbedingung von reise(stadt1, stadt2, person) enthält nur in(stadt1, person) in(stadt2, person). Da die Aussage ausgeruht(person) ausgeruht(person) immer wahr ist, ist ein abstraktes Literal an dieser Stelle nicht erforderlich. Es könnte dennoch eingesetzt werden um bereits auf abstrakter Ebene anzuzeigen, dass diese Effekte auftreten. Man kann die Hierarchie noch erweitern. Oft braucht man mehr als nur einen Zug, um zum Zielort zu gelangen. Der Task reise_mit_zug(stadt1, stadt2, person) ist daher abstrakt, ebenso das Relationssymbol anschluss_verpasst. Eine mögliche Dekomposition für anschluss_verpasst könnte dann zum Beispiel sein: person V Person : anschluss_verpasst(person) verschlafen(person) zug V Zug : hat_verspaetung(zug). Diese Bedingung in dem Task reise(stadt1, stadt2, person) korrekt anzugeben, würde ihn sehr unübersichtlich werden lassen. Außerdem ist es aufwendig, die Bedingungen über mehrere Hierarchieebenen korrekt und konsistent zu halten. Die Informationen auf abstrakter Ebene auszulassen würde dem entgegenwirken, führt aber zu Unklarheiten, wann ein abstrakter Task angewendet werden kann. Die Einführung von Dekompositionsaxiomen sorgt für eine bessere Handhabbarkeit der Taskhierarchie, ohne dass relevante Informationen verloren gehen. 9

2 Der hybride Planungsformalismus 2.5 Legalität von Dekompositionsmethoden Damit abstrakte Tasks sinnvoll eingesetzt werden können, sollten ihre Dekompositionen mit ihnen zusammenhängen. Beispielsweise wäre die Dekomposition des abstrakten Tasks reise(stadt1, stadt2, person) in einen Plan, der einen Einkauf umsetzt, nicht sinnvoll. Um derartige Methoden zu verhindern, wird in From Abstract Crisis to Concrete Relief [BS01] die Legalität von Dekompositionsmethoden definiert. Betrachtet wird eine Methode µ = (t, P, VC), die den Task t = ( v, prec, post) dekomponiert. Sei außerdem t 1... t n eine Tasksequenz, die genau die in P enthaltenen Tasks verwendet und aufgrund der Ordnungsconstraints auch so angeordnet werden kann. Dann sei t 1 = ( v, prec, post ) und post die Formel, die durch die Tasksequenz generiert wird 4. Für ein Model M und eine Belegung β ist µ genau dann legal, wenn für jede solche Tasksequenz gilt: ( s S : s = M,β prec prec) ( s, s S mit (s, s ) = M,β (t 1... t n ) : s = M,β post post). Es wird also gefordert, dass, wenn in einem Zustand die Vorbedingung des ersten Planschritts gilt, auch die Vorbedingung des abstrakten Tasks gelten muss. Außerdem muss nach Anwendung der Tasksequenz auf einen Zustand die Nachbedingung des abstrakten Tasks gelten. Durch diese beiden Kriterien kann sichergestellt werden, dass kausale Links auf den abstrakten Task bei der Dekomposition weitervererbt werden können. Sie werden im weiteren Verlauf dieser Arbeit zusammenfassend als Implementierungskriterium bezeichnet. 2.6 Das hybride Domänenmodell und das hybride Planungsproblem Ein Domänenmodell D basiert auf der zuvor beschriebenen logischen Sprache L und ist definiert als Tupel (T p, T a, M, ). Dabei repräsentiert T p eine endliche Menge von primitiven Tasks, T a eine endliche Menge von abstrakten Tasks, M eine endliche Menge von Dekompositionsmethoden und eine endliche Menge von Dekompositionsaxiomen. Darauf aufbauend wird ein Planungsproblem P für ein Domänenmodell D durch ein Tupel (D, P init ) repräsentiert. P init steht für den initialen Plan, der das Problem darstellt, und wird auch als initiales Tasknetzwerk bezeichnet. In diesem Plan enthalten sind zwei 4 Ein Task t = ( v, prec, post), der den Zustand s in den Zustand s überführt, generiert eine Formel post genau dann, wenn gilt s = M,β post post. Eine Tasksequenz t 1... t n generiert eine Formel post genau dann, wenn post von einem t i(1 i n) generiert wird und für alle t j(i < j n) gilt: s, s S mit (s, s ) = M,β t j : s = M,β post s = M,β post. 10

2.6 Das hybride Domänenmodell und das hybride Planungsproblem spezielle primitive Planschritte, t init und t goal. Der Task t init erzeugt den initialen Zustand durch seine Nachbedingung; dem zugehörigen Task fehlt die Vorbedingung. Nach t init können weitere Planschritte gegeben sein. Man gibt damit einen groben Handlungsablauf an, oft durch abstrakte Tasks; es soll herausgefunden werden, ob und wie dieser Ablauf umgesetzt werden kann. Um beispielsweise Wie komme ich von Ulm nach Berlin? zu lösen, könnte man den Task reise(ulm, BERLIN, LOUISA) in P init aufnehmen. Der Task t goal ist immer der letzte Planschritt; sein Task besitzt keine Nachbedingung. Eine Vorbedingung kann angegeben werden, muss es aber nicht. Wenn keine Vorbedingung existiert, ist nur die Umsetzung des durch P init gegebenen Handlungsablaufs von Interesse. Existiert eine Vorbedingung für t goal, enthält sie Merkmale des Zielzustandes, also Literale, die nach Ausführung des Plans gelten sollen. Damit können zusätzliche Bedingungen an den Plan gestellt werden. Man könnte etwa ausgeruht in Berlin ankommen wollen; dazu ist ein Zug besser geeignet als ein Auto. Um das bei der Planung sicherzustellen, kann das Literal ausgeruht in die Vorbedingung von t goal aufgenommen werden. Eine Lösung eines Planungsproblems P ist ein Plan, der die nachfolgenden Bedingungen erfüllt: 1. Der Plan muss durch Modifikationen von P init entstehen. Eine Möglichkeit der Modifikation ist es, neue Tasks, kausale Links, Ordnungsconstraints oder Variablenconstraints in die entsprechenden Mengen von P init aufzunehmen. Außerdem können abstrakte Tasks mithilfe ihrer Dekompositionsmethoden dekomponiert werden. Gegeben sei ein Plan P m = (t m, < m, VC m, CL m ), der entweder P init oder ein Modifikation desselben ist. Sei (l, t) t m und gelte weiterhin (t, P, VC) M mit P = (T p, < p, VC p, CL p ). Dann wird eine solche Dekomposition durchgeführt, indem der Planschritt (l, t) aus t m entfernt wird. Stattdessen werden die angepassten Planschritte aus T p eingeführt. Außerdem werden die Elemente aus VC, < p, VC p und CL p zu den entsprechenden Mengen von P m hinzugefügt. Zuletzt werden die kausalen Links auf t vererbt. Dazu werden alle kausalen Links, die (l, t) enthalten, entfernt und stattdessen neue kausale Links, die die Planschritte aus T statt (l, t) verwenden, wann immer möglich erstellt und hinzugefügt. Ein kausaler Link (t i, (l, t), r( x)) mit einem Literal r( x) und t i T m kann an einen Planschritt t j T p vererbt werden, wenn r( x) ein Konjunktionsglied der Vorbedingung von t j ist. Der resultierende kausale Link ist dann (t i, t j, r( x)). Analog kann für ((l, t), t i, r( x)) vorgegangen werden. Die Forderung, dass die Lösung eine Modifikation von P init sein muss, stellt sicher, dass ein Zusammenhang zwischen dem Problem und der Lösung besteht. Durch P init wird das Problem, das gelöst werden soll, spezifiziert. Wenn die Lösung nicht durch die genannten Modifikationen entstünde, könnte dadurch die Problemstellung verändert werden, so dass zwar ein ausführbarer Plan erstellt werden würde, dieser aber nichts mehr mit dem gestellten Problem zu tun hätte. Beispielsweise könnte reise(ulm, BERLIN, LOUISA) aus P init entfernt werden und als Lösung ein Plan mit dem Planschritt reise_mit_zug(ulm, MUENCHEN, LOUISA) angegeben werden. Der Plan ist zwar ausführbar, setzt aber keine Reise von Ulm nach Berlin um. Damit ist er unbrauchbar. 11

2 Der hybride Planungsformalismus 2. Es dürfen keine offenen Vorbedingungen enthalten sein. Um das sicherzustellen muss jedes Literal, das in der Vorbedingung eines Planschritts vorkommt, durch einen kausalen Link geschützt werden. Dieses Kriterium stellt sicher, dass alle in der Lösung enthaltenen Planschritte auch ausführbar sind. 3. Es dürfen keine kausalen Threats existieren. Ein kausaler Threat eines kausalen Links (t i, t j, r( x)) liegt vor, wenn die Ordnungs- und Variablenconstraints es ermöglichen, dass ein t k zwischen t i und t j ausgeführt werden kann, obwohl r( x) in der Nachbedingung von t k vorkommt. Mit diesem Kriterium wird gewährleistet, dass der kausale Link für jede Linearisierung des Plans erfüllt wird, und der Plan damit in jedem Fall ausführbar ist. 4. Der Plan darf ausschließlich primitive Tasks enthalten, denn abstrakte Tasks sind nicht direkt ausführbar. Dieses Kriterium wäre hinfällig, wenn Pläne auf verschiedenen Abstraktionsebenen erstellt werden könnten. Dann müssten auch abstrakte Tasks im Lösungsplan zugelassen sein. Die Integration dieses Features in Panda 2 ist jedoch nicht Teil dieser Arbeit, daher wird hier nicht weiter auf diesen Fall eingegangen. 5. Alle Variablen sind an Elemente der Trägermenge gebunden. Dieses Kriterium dient dazu, sicherzustellen, dass ein Task auf einen Zustand angewendet werden kann. Enthält ein Task eine ungebundene Variable, ist er nicht grundiert; die Ausführbarkeit von Tasks ist aber nur für grundierte Tasks definiert, da andernfalls nicht klar ist, welche Konstante verwendet wird. 12

3 Panda 2 Panda 2 ist ein am Institut für künstliche Intelligenz der Universität Ulm entwickeltes Planungssystem, an dem im Verlauf dieses Projekts konzeptionelle Änderungen vorgenommen wurden. Um einerseits diese Änderungen und andererseits vor allem auch die Motivation hinter diesen Änderungen nachvollziehen zu können, ist ein tiefer gehendes Verständnis der Algorithmen in Panda 2 notwendig. Daher widmet sich dieser Abschnitt dem Aufbau von Panda 2 vor Beginn dieses Projekts. Die Implementierung von Panda 2 stammt von Bastian Seegebarth und Pascal Bercher; die Kompilierung der Dekompositionsaxiome wurde von Bastian Seegebarth umgesetzt und wird in diesem Abschnitt zum ersten Mal formal beschrieben. Zunächst wird die Vorverarbeitung erklärt, durch die ein im Panda 2 -XML-Format vorliegendes Planungsproblem in Datenstrukturen umgewandelt wird, mit denen ein effizientes Planen möglich ist. Dem folgt eine Erläuterung des eigentlichen Planungsalgorithmus. Abb. 3.1 zeigt den gesamten Planungsprozess. 3.1 Vorverarbeitung Im ersten Schritt der Vorverarbeitung werden die relevanten Panda 2 -XML-Dokumente eingelesen und deren Inhalt auf passende Datenstrukturen abgebildet. Diese Darstellung der Domäne und des Planungsproblems wird als kanonische Darstellung bezeichnet. Hier werden noch keine Änderungen an der Domäne vorgenommen. Es folgt die sogenannte Kompilierung; aus ihr resultiert die kompilierte kanonische Darstellung. Diese ist eine äquivalente Repräsentation der Domäne und des Planungsproblems, die ohne abstrakte Literale und Dekompositionsaxiome auskommt. Die Vorgehensweise zur Erstellung dieser Repräsentation ist von entscheidender Bedeutung, es folgt daher eine genaue Betrachtung in Kapitel 4.1.1. Nach der Kompilierung wird das entstandene Modell in eine effiziente Darstellung überführt. Die bisher als Objekte gespeicherten Daten werden nun als Zahlen repräsentiert. Durch diese Darstellung wird wesentlich schnelleres Planen ermöglicht und es wird weniger Speicher verbraucht. Vor dem eigentlichen Planen folgen nun weitere Vorverarbeitungsschritte, die den explorierten Suchraum möglichst klein halten sollen. Dazu gehören zum Beispiel eine relaxierte Erreichbarkeitsanalyse und die Erstellung eines Task Decomposition Graphs (TDG) [Kee14]. 13

3 Panda 2 Domäne in Panda 2 -XML Problem in Panda 2 -XML einlesen kanonische Darstellung bla Eliminierung der Dekompositionsaxiome bla bla kompilierte kanonische Darstellung 1:1 Übersetzung der Domänebla in eine effektive Datenstruktur effiziente Darstellung Erreichbarkeitsanalyse Planungsgraph TDG Planungsprozess zeitlicher Verlauf basiert auf nutzt aus Lösung Abbildung 3.1: Ablauf des Planungsprozesses vor diesem Projekt. 14

3.2 Der Planungsalgorithmus 3.2 Der Planungsalgorithmus Ein Ablaufdiagramm des Planungsalgorithmus von Panda 2 ist in Abb. 3.2 dargestellt. Der Algorithmus beginnt damit, P init in die sogenannte Fringe einzufügen. Die Fringe enthält alle bisher erstellten und noch nicht expandierten Pläne. Danach beginnt die Ausführung einer Schleife: Zunächst wird aus der Fringe der vielversprechendste Plan ausgewählt. Welcher Plan das konkret ist, hängt von der Planselektionsstrategie ab. Dieser Plan wird dann aus der Fringe gelöscht und weiter verarbeitet, indem die enthaltenden Flaws detektiert werden. Von einem Flaw spricht man, wenn eines der in Kapitel 2.6 vorgestellten Lösungskriterien verletzt wird. Falls der Plan keine Flaws enthält, ist er eine Lösung und wird zurückgegeben. Falls Flaws vorhanden sind, wird mithilfe der Flawselektionsstrategie ein Flaw bestimmt, der behoben werden soll. Für die verschiedenen Flawklassen gibt es jeweils festgelegte Möglichkeiten der Modifikation. Alle Modifikationen, die den gewählten Flaw beheben können, werden auf den Plan angewandt. Daraus entsteht jeweils ein neuer Plan, der in der Fringe gespeichert wird. Die Schleife beginnt nun von vorne, solange bis eine Lösung gefunden wurde oder keine weiteren Pläne vorhanden sind. Eine ausführliche Beschreibung des Planungsalgorithmus sowie der dazu gehörige Pseudocode kann in Exploiting Task Decomposition Graphs for Hierarchical Planning. [Kee14] nachgelesen werden. 15

3 Panda 2 Füge initialen Plan in Fringe ein keine Lösung Fringe leer sonst Wähle Plan aus Fringe gemäß Planselektionsstrategie Detektiere Flaws im Plan Lösung keine Flaws sonst Wähle Flaw gemäß Flawselektionsstrategie Behebe Flaw Füge resultierende Pläne in Fringe ein Abbildung 3.2: Ablauf des Planungsalgorithmus. 16

4 Nicht-native Implementierung von Dekompositionsaxiomen Dieses Kapitel beschreibt das Vorgehen bei der Kompilierung von Dekompositionsaxiomen. Dabei wird zunächst beschrieben, wie der bisherige Ablauf der Kompilierung in Panda 2 war. Dieser wurde von Bastian Seegebarth umgesetzt und wird in dieser Arbeit erstmals systematisch dargelegt. Der zweite Teil behandelt die konzeptionellen Änderungen, die Panda 2 im Verlauf dieses Projekts erfahren hat, und evaluiert diese. Dazu gehört zum einen, dass die Erreichbarkeitsanalyse früher durchgeführt wird und die dadurch erhaltenen Informationen zur Reduzierung der Methodenanzahl vor der Kompilierung verwendet werden. Ähnliche Konzepte wurden bereits in Landmarks in Hierarchical Planning [ESB10], Improving Hierarchical Planning Performance by the Use of Landmarks [EBSB12] und Exploiting Task Decomposition Graphs for Hierarchical Planning [Kee14] vorgestellt. Zum anderen wird während der Kompilierung auf die Einhaltung des Implementierungskriteriums geachtet, so dass die resultierende Domäne korrekt ist, während es in der ursprünglichen Implementierung möglich war, dass die durch die Kompilierung entstehende Domäne nicht mehr das Implementierungskriterium erfüllt. Auch dabei wird die Anzahl der Methoden, und damit auch die Laufzeit, verringert. Neben den konzeptionellen Änderungen, die hier beschrieben werden, wurden weitere, rein implementatorische Schritte zur Verbesserung der Vorverarbeitungszeit unternommen. Eine vollständige Übersicht der Änderungen an Panda 2 findet sich in Anhang A. 4.1 Ursprüngliche Kompilierung Dieser Abschnitt beschreibt den Kompilierungsprozess, wie er bisher in Panda 2 vorlag. Nach der ausführlichen Schilderung des Vorgehens erfolgt eine kurze Diskussion dieses Vorgehens. 4.1.1 Vorgehen Algorithmus 1 sorgt dafür, dass das Planungsproblem keine abstrakten Literale mehr enthält. Dazu werden in Teil 1 des Algorithmus zunächst für jedes Dekompositionsaxiom r( x) σ alle abstrakten Literale r ( x) in σ durch ihre Dekompositionen ersetzt. 17

4 Nicht-native Implementierung von Dekompositionsaxiomen Data : D = (T p, T a, M, ), die zu kompilierende Domäne /* Teil 1 */ 1 foreach r( x) σ do 2 foreach r (ȳ ) σ, r r do /* jedes Vorkommen von r in σ wird durch σ ersetzt */ 3 σ = replaceeveryoccurence(σ, r, σ); 4 end 5 end /* Auf der rechten Seite jedes Dekompositionsaxioms sind an dieser Stelle nur noch primitive Literale vorhanden */ /* Teil 2 */ 6 foreach ( v, prec, post) T a do 7 foreach r( x) σ do /* jedes Vorkommen von r in prec wird durch σ ersetzt */ 8 prec = replaceeveryoccurence(prec, r, σ); /* jedes Vorkommen von r in post wird durch σ ersetzt */ 9 post = replaceeveryoccurence(post, r, σ); 10 end 11 end /* Die Vor- und Nachbedingungen aller Tasks enthalten nur noch primitive Literale */ /* Teil 3 */ 12 foreach µ M with µ = (t, P, VC), P = (T p, < p, VC p, CL p ) do 13 foreach r( x) σ do 14 foreach (t i, t j, r( x)) CL p do /* jedes Vorkommen von r in r( x) wird durch σ ersetzt */ 15 r( x) = replaceeveryoccurence(r( x), r, σ); 16 end 17 end 18 end /* Alle kausalen Links enthalten nur noch primitive Literale */ Algorithmus 1: Dieser Algorithmus erstellt Tasks und Methoden für die neue Domäne ohne abstrakte Literale. Diese sind eine Kopie der Tasks und Methoden der alten Domäne; sie enthalten aber an jeder Stelle, an der in der alten Domäne r war, stattdessen σ, für r( x) σ. 18

4.1 Ursprüngliche Kompilierung Wenn beispielsweise zwei Dekompositionsaxiome r a r und r b c in der ursprünglichen Domäne enthalten sind, wird nach dem ersten Abschnitt des Algorithmus r a r durch r a b c ersetzt. In Teil 2 werden alle abstrakten Literale in den Vorund Nachbedingungen der Tasks durch ihre Dekompositionen ersetzt und schließlich in Teil 3 auch alle abstrakten Literale und Tasks, die in den kausalen Links der Methoden enthalten sind. In Folge dieser Ersetzung können nun Disjunktionen und Quantoren in den Vor- und Nachbedingungen von Tasks sowie in den geschützten Bedingungen der kausalen Links von Methoden enthalten sein. Es folgt also ein weiterer Kompilierungsschritt, der dafür sorgt, dass die Vor- und Nachbedingungen von Tasks wieder Konjunktionen von Literalen sind und die geschützten Bedingungen von kausalen Links wieder Literale. Der erste Schritt ist die Umwandlung von komplexen Vor- und Nachbedingungen von Tasks zu Konjunktionen von Literalen. Dazu wird jeder Task nach drei Regeln behandelt, die im Folgenden erläutert werden. Beispielhaft werden sie an den in Abschnitt 2.4 eingeführten Tasks und Dekompositionsaxiomen verdeutlicht. 1. Enthält eine der Vor- oder Nachbedingungen des Tasks eine Disjunktion, werden neue Tasks in der Anzahl der Disjunktionsglieder angelegt. Jeder dieser neuen Tasks hat an Stelle der Disjunktion eines der Disjunktionsglieder in der Bedingung. Der Task reise(stadt1, stadt2, person) wurde im vorherigen Kompilierungsschritt zu reise(stadt1, stadt2, person) PRE in(stadt1, person) ( ( auto V Auto : hat_fuehrerschein(person) verfuegbar(auto, person) ) ( hat_ticket(person) anschluss_verpasst(person) )) POST in(stadt1, person) in(stadt2, person) geändert. Zur Übersichtlichkeit wird das Literal anschluss_verpasst vorerst nicht durch seine Dekompilierung ersetzt; tatsächlich wäre es das aber an dieser Stelle bereits. Die Disjunktion hat zwei Glieder, daher wird reise(stadt1, stadt2, person) durch zwei neue Tasks ersetzt: reise.0(stadt1, stadt2, person) PRE in(stadt1, person) hat_fuehrerschein(person) auto V Auto : verfuegbar(auto, person) POST in(stadt1, person) in(stadt2, person) und 19

4 Nicht-native Implementierung von Dekompositionsaxiomen reise.1(stadt1, stadt2, person) PRE in(stadt1, person) hat_ticket(person) anschluss_verpasst(person) POST in(stadt1, person) in(stadt2, person). 2. Enthält eine der Vor- oder Nachbedingung des Tasks einen Existenzquantor über eine Variable v, werden neue Tasks in der Anzahl der Konstanten der Sorte von v angelegt. Für jeden dieser neuen Tasks werden alle Vorkommen von v durch eine passende Konstante ersetzt. Angenommen es existieren drei Konstanten der Sorte Auto: VW, BMW und OPEL. Dann wird der Task reise.0(stadt1, stadt2, person) durch die drei Tasks reise.0.0(stadt1, stadt2, person) PRE in(stadt1, person) hat_fuehrerschein(person) verfuegbar(vw, person) POST in(stadt1, person) in(stadt2, person), reise.0.1(stadt1, stadt2, person) PRE in(stadt1, person) hat_fuehrerschein(person) verfuegbar(bmw, person) POST in(stadt1, person) in(stadt2, person) und reise.0.2(stadt1, stadt2, person) PRE in(stadt1, person) hat_fuehrerschein(person) verfuegbar(opel, person) POST in(stadt1, person) in(stadt2, person) ersetzt. 3. Enthält eine Vor- oder Nachbedingung des Tasks einen Allquantor über die Variable v (das kann durch die Negation eines abstrakten Literals passieren; auf der rechten Seite eines Dekompositionsaxioms sind Allquantoren sonst nicht erlaubt), wird jedes Literal, in dem v vorkommt, durch eine Konjunktion mit Gliedern in der Anzahl der Konstanten der Sorte von v ersetzt. Jedes Konjunktionsglied besteht aus dem vorher genannten Literal, hat allerdings an Stelle von v eine der Konstan- 20

4.1 Ursprüngliche Kompilierung ten. Die Vorbedingung von reise.1(stadt1, stadt2, person) ist bisher ohne die Ersetzung von anschluss_verpasst dargestellt worden. Tatsächlich wird aber das Literal anschluss_verpasst(person) bereits im ersten Kompilierungsschritt durch reise.1(stadt1, stadt2, person) PRE in(stadt1, person) hat_ticket(person) verschlafen(person) zug V Zug : hat_verspaetung(zug) POST in(stadt1, person) in(stadt2, person). ersetzt. Wenn die Domäne zwei Konstanten der Sorte Zug enthält, beispielsweise ICE und IRE, wird durch diese Regel der Task reise.1(stadt1, stadt2, person) ersetzt durch den Task reise.1.0(stadt1, stadt2, person) PRE in(stadt1, person) hat_ticket(person) verschlafen(person) hat_verspaetung(ice) hat_verspaetung(ire) POST in(stadt1, person) in(stadt2, person). Diese Regeln werden solange auf einen Task bzw. auf die resultierenden Taskmengen angewandt bis die Vor- und Nachbedingung weder Quantoren noch Disjunktionen enthalten. Man erhält dadurch eine Menge von Tasks, die statt des ursprünglichen Tasks in die Domäne aufgenommen werden. Für jeden behandelten Task müssen auch die mit ihm zusammenhängenden Methoden angepasst werden. Die Planschritte der Methoden können zu diesem Zeitpunkt Tasks wie reise(stadt1, stadt2, person) enthalten, die nicht mehr Teil der Domäne sind. Diese müssen mit den neuen Tasks, etwa reise.0.0(stadt1, stadt2, person), reise0.1(stadt1, stadt2, person), reise0.2(stadt1, stadt2, person) und reise.1.0(stadt1, stadt2, person), ersetzt werden. Daher wird für jede Methode überprüft, ob sie den veränderten Task dekomponiert oder als Planschritt enthält. Ist das der Fall, wird die Methode ersetzt durch neue Methoden, die an den entsprechenden Stellen statt des alten Tasks einen der neuen Tasks verwenden. Die Methode (reise(stadt1, stadt2, person), P, VC) würde also beispielsweise gegen (reise.0.0(stadt1, stadt2, person), P, VC), (reise.0.1(stadt1, stadt2, person), P, VC), (reise.0.2(stadt1, stadt2, person), P, VC) sowie (reise.1.0(stadt1, stadt2, person), P, VC) ausgetauscht werden. Das Vorgehen für die geschützten Bedingungen kausaler Links folgt einem ähnlichen Muster, allerdings müssen in diesem Fall auch Konjunktionen behandelt werden. Alle 21

4 Nicht-native Implementierung von Dekompositionsaxiomen Methoden werden überprüft; wenn einer der kausalen Links der Methode kein Literal ist, wird folgendermaßen vorgegangen: 1. Schützt ein kausaler Link der Methode eine Disjunktion, werden neue Methoden in der Anzahl der Disjunktionsglieder angelegt. Jede dieser neuen Methoden hat an Stelle des kausalen Links über die Disjunktion einen kausalen Link über eines der Disjunktionsglieder. 2. Schützt ein kausaler Link der Methode einen Existenzquantor über die Variable v, werden neue Methoden in der Anzahl der Konstanten der Sorte von v angelegt. Für jede dieser Methoden werden alle Vorkommen von v in dem kausalen Link durch eine passende Konstante ersetzt. 3. Schützt ein kausaler Link der Methode einen Allquantor über die Variable v, wird jedes Literal, in dem v vorkommt, durch eine Konjunktion mit Gliedern in der Anzahl der Konstanten der Sorte von v ersetzt. Die Glieder der Konjunktion bestehen aus dem vorher genannten Literal; jedes Glied hat aber an Stelle von v eine der Konstanten. Hierbei entsteht ein kausaler Link über eine Konjunktion. 4. Schützt ein kausaler Link der Methode eine Konjunktion, wird der kausale Link durch neue kausale Links in der Anzahl der Konjunktionsglieder ersetzt. Jeder dieser kausalen Links schützt dann eines der Konjunktionsglieder. Diese Regeln werden solange auf alle kausalen Links angewandt, bis sie jeweils nur ein Literal schützten. Hierbei können illegale Methoden entstehen, wie in Abbildung 4.1 dargestellt. Beispielsweise könnte in der unkompilierten Domäne eine Methode Planschritte zu dem Task treffe_vorbereitungen(person) PRE TRUE POST reise_moeglich(person) und dem Task reise(stadt1, stadt2, person) sowie ((l1, treffe_vorbereitungen(person)), (l2, reise(stadt1, stadt2, person)), reise_moeglich(person)) als kausalen Link zwischen den beiden enthalten. Zunächst werden die Tasks ersetzt, so dass unter anderem eine Methode mit dem Planschritt zu reise.0.2(stadt1, stadt2, person), die die Autoreise mit einem Opel umsetzt, und dem Planschritt treffe_vorbereitungen.0(person) PRE TRUE POST hat_fuehrerschein(person) verfuegbar(opel, person) existiert. Diese Methode enthält zunächst noch ((l1, treffe_vorbereitungen.0(person)), (l2, reise.0.2(stadt1, stadt2, person)),reise_moeglich(person)) als kausalen Link. Nach der Kompilierung des kausalen Links ist diese Methode durch mehrere andere Methoden ersetzt worden. Zu diesen neuen Methoden gehört unter anderem eine Methode mit den 22

4.1 Ursprüngliche Kompilierung µ r 1 r 2 r 1 r 2 r 1 r 2 t 1 t 2 Kompilierung der Vor- und Nachbedingungen µ 1 r 1 r 2 r 1 r 1 t 11 t 21 (...) Kompilierung der kausalen Links µ 11 r 1 r 1 r 1 t 11 t 21 µ 12 r 2 r 1 r 1 t 11 t 21 Abbildung 4.1: Zunächst werden die abstrakten Vor- und Nachbedingungen der Tasks zerlegt; dadurch entstehen mehrere neue Methoden. Die enthaltenen Tasks haben ausschließlich primitive Vor- und Nachbedingungen. Durch die Kompilierung der kausalen Links ohne Berücksichtigung der verbleibenden Vor- und Nachbedingungen entstehen kausale Links, die nicht korrekt sind. Die entsprechenden Methoden werden daher aus der Domäne entfernt. 23

4 Nicht-native Implementierung von Dekompositionsaxiomen kausalen Links ((l1.0, treffe_vorbereitungen.0(person)), (l2.0.2, reise.0.2(stadt1, stadt2, person)), hat_ticket(person)) sowie ((l1.0, treffe_vorbereitungen.0(person)), (l2.0.2, reise.0.2(stadt1, stadt2, person)), anschluss_verpasst(person)). Diese Literale sind aber weder Konjunktionsglied der Vorbedingung von treffe_vorbereitungen.0(person) noch Konjunktionsglied der Nachbedingung von reise.0.2(stadt1, stadt2, person). Im ursprünglichen Modell war der kausale Link berechtigt, durch die getrennte Kompilierung von Tasks und kausalen Links ist aber ein kausaler Link entstanden, der keinen Sinn mehr macht. Im letzten Schritt der Kompilierung werden daher Methoden, die solche kausalen Links enthalten, gesucht und aus der Domäne entfernt. 4.1.2 Diskussion der ursprünglichen Kompilierung Nachdem das Vorgehen bei der Kompilierung von Dekompositionsaxiomen ausführlich erläutert wurde, diskutiert dieser Abschnitt die Auswirkungen dieses Vorgehens auf die Laufzeit sowie auf die Korrektheit der resultierenden Domäne. Laufzeit In der Bachelorarbeit Hybrid Planning in Cyber Security Applications [Pra13] wurde festgestellt, dass die Laufzeit des Panda 2 -Planers auch bei eher einfachen Planungsproblemen zu der vorgestellten Domäne sehr lang ist. So benötigt ein beispielhaftes Planungsproblem mit 57 Konstanten allein für die Vorverarbeitung über 14 Stunden, sogar wenn die Lösung für das Planungsproblem bereits im Anfangszustand erreicht ist. Bei genauerer Analyse kann festgestellt werden, dass aus den ursprünglichen 170 Tasks der Domäne nach der Kompilierung 497 Tasks und aus den 100 Methoden 170.132 Methoden entstanden sind. Existenzquantoren haben den stärksten Einfluss auf das Wachstum der Tasks- und Methodenanzahl, da für jede Konstante der entsprechenden Sorte ein neuer Task bzw. eine neue Methode entsteht. Bei einer Verschachtlung von Existenzquantoren multipliziert sich die Anzahl der entstehenden Tasks und Methoden. Die Domäne enthält 19 Dekompositionsaxiome, die durchschnittlich zwei bis drei Disjunktionsglieder haben. Existenzquantoren kommen insgesamt 30 mal vor, sechs davon sind einfach verschachtelt und einer sogar dreifach, was zu einem extremen Wachstum führt. Außerdem gibt es 43 abstrakte Tasks, die oft mehrere abstrakte Literale verwenden. Durchschnittlich ist ein abstrakter Task nach der Kompilierung durch neun Tasks ersetzt worden (bei 57 Konstanten in der gegebenen Konstellation). Selbst wenn jede Methode im Durchschnitt nur vier abstrakte Tasks verwendet, würden daraus schon 656.100 1 Methoden entstehen. Durch eine ausgiebige Verwendung von Existenzquantoren und Dekompositionsaxiomen 1 Für 100 Methoden mit je vier abstrakten Tasks, wobei jeder abstrakte Task durch neun neue Tasks ersetzt wird, ergeben sich 100 9 9 9 9 = 656.100 neue Methoden. 24