The planning problem in AI: Structuring domains and

` degli Studi di Roma “La Sapienza” Universita Dottorato di Ricerca in Ingegneria Informatica XVII Ciclo – 2005

The planning problem in AI: Structuring domains and evaluating plans

Marcelo Oglietti

` degli Studi di Roma “La Sapienza” Universita Dottorato di Ricerca in Ingegneria Informatica XVII Ciclo - 2005

Marcelo Oglietti

The planning problem in AI: Structuring domains and evaluating plans

Thesis Committee

Reviewers

Prof.ssa Luigia Carlucci Aiello (Advisor) Prof. Amedeo Cesta Prof. Marco Schaerf

Prof. Erik Sandewall Prof. Sam Steel

c 2005 Copyright ° by Marcelo Oglietti ISBN: 88-901942-0-0

Author’s address: Marcelo Oglietti Dipartimento di Informatica e Sistemistica Università degli Studi di Roma “La Sapienza” Via Salaria 113, I-00198 Roma, Italy e-mail: [email protected] www: http://www.dis.uniroma1.it/∼oglietti/

To Lita, Celso, Guille and to the memory of Jorge Dutra and all those who quietly dedicate most of their lives to trying to make the world a slightly more just place, as he did.

Acknowledgements I am very grateful to Prof. Luigia Carlucci Aiello. She guided me through the first stages of this research and has been extremely patient and dedicated invaluable hours —many robbed to sleeping time— to read every draft of these pages. Her sense of humor kept me awake during the last days, when I had already passed the point of complete exhaustion. I have no words to express what I owe to Prof. Amedeo Cesta. We traveled every inch of the research landscape reported in this dissertation together. He was a permanent guide and an enthusiastic brainstorming pal. He pointed me to absolutely all the literature I read during this research. But, the most important aspect I would like to highlight is that he puts as much passion and humor in this work as to make me feel it was pure fun. Both continuously provided me with magic comments that allowed me to turn the obscure pages I tend to wrote into something more readable. Prof. Erik Sandewall and Prof. Sam Steel read a preliminary version of this thesis and contributed with a number of comments, that I found extremely useful; not only to improve this thesis, but also for future research. I thank them for their great attention and their acute comments. I would like to thank Prof. Giuseppe De Giacomo for his comments about how to compare action theories and Prof. Giorgio Ausiello for his many patient answers about complexity. I thank Sara Bernardini for reading a late draft of the thesis and highlighting a myriad of inaccuracies in it; she also contributed with valuable comments that helped to improve it. I also thank Francesco Savelli for his illuminating comments about the Situation Calculus and ConGolog. He and Federico Pecora discussed with me many half-cooked ideas and through that process helped me finish with something more coherent. I am grateful to the authorities at CONAE for their permanent support to this research project. Nothing of this could have been done without their continuous trust. In particular, I would like to thank Conrado Varotto, Fernando Hisas, Alberto Ridner and Carlos Alonso, whose support was crucial in different moments. I thank the administration and technical personnel at CONAE, DIS and iii

ISTC-CNR for their help with various matters. In particular I would like to thank Mónica Roca, Tiziana Toni, Arturo Maidana and Jorge Fern´ andez, not only for frequently helping me from their specific sphere of responsibilities, but most of all, for their continuous help even outside that sphere. I also thank the members of the Planning and Scheduling Team (PST) at ISTC-CNR, and my colleges at DIS and CONAE for creating a stimulating environment in which this research has been developed. In particular, I would like to thank Manfred Pacher and Carlos Falcon for being really good friends and for taking care of many technical things in CONAE, making possible for me to focus almost exclusively on this research during the last three years. Finally, I want to thank all the people I love for being the emotional support behind not only this work but my whole life. Special thanks: to Sandra Cartasso and Marcelo Huck, for being to me the friends I would like to be to others and for being close when Jorge died; to Cristina Carvalho and Tamara Villoslada, for being always there, even with thousands of kilometers separating us; to Martin Levenson and Pablo Funes (whose experience they generously gave me when I started to walk inside the computing world), not only for being extraordinary friends, but also for that wonderful and extraordinary rich experience we share building our small but precious MAPA (how many things we learned those few years!); to Tiziana Toni, Antonello Proteo, Seimoni Vacca and his two families, Stefano Diamante, Francesco Savelli, Sara Bernardini, Rosangela Scalzo, Riccardo Rasconi, Federico Pecora, Simone Fratini, Amedeo Cesta, Valeria Bordoni, Claudio Tavella, Maria Chiara Sabato and all my friends in Rome (Klandestini and Blackrockers included!), for turning a foreign city into home in such a short period of time; to Jane Brodie, Fernando Queirel, Fabian Peretti, Eleonora Franco, Silvia Duhau, Alberto and Eduardo Romero, Gabriela Vernieri, Mariela Alonso, Alejandro Rivas, Billie Lue-Fung, Marilin Alaniz, Alejandra and Patricia Toledo, Moira Soto, Maria Moreno, Noemi Tessio, Pablo Kaniesfsky, Marcelo Samia, Anahi Asquineyer, Federico Rasenberg, Ricardo Lima, Christian Bhar, Osvaldo Deledone, Camila Fisher, Eduardo Ribolzi, Pablo Anigstein, Cristian Filici, Julio Vega, Felipe Pasquevich, Jorge Medina, Anibal Ambrosino, Gabriela Steren and all my friends in Argentina, for making my life so happy so many years; and last but not less, to my mother Margarita Marzetta, mi nonna Margarita Grill and her sisters Ducha and Maria, my father Celso Oglietti and his new family, Pablo Gagliesi and Leonardo Pomeranchic, Edith Biancotti, and finally, to my beloved brother Guillermo Oglietti and Camila Vollenweider, for being my most enthusiastic fans ever. Forgive me, it is impossible to mention all of you! Rome, Italy October 20th, 2004

Marcelo Oglietti

Abstract This dissertation presents two main ideas: a novel strategy to model planning domains, and a new approach to evaluating the quality of plans for domains with incomplete information and sensing. Our strategy for model planning domains in a more structured way is built following three logical steps that can be repeated on top of various current planning frameworks. We choose STRIPS as it is a very well known planning framework. The first step is extending the framework to explicitly represent the concurrent activities as distinct concurrent threads of actions. We present a formalism called CSTRIPS (from Concurrent STRIPS), that extends STRIPS to include state variables, sorts, and primitives for an explicit and direct representation of concurrent actions. We first introduce this empowered STRIPS by presenting its syntax and semantics, then address aspects that help understand its effectiveness. As for the complexity of reasoning, we prove CSTRIPS to be not worse than STRIPS on the expanded case. The second step is introducing a new notion of object suited for modeling planning domains as a set of objects instead of simple operators. These objects have the features usually associated with objects in programming languages; they have a client/supplier relationship, an explicit interface, hidden data, etc. The third step is introducing an Object-Oriented ( O-O) language for defining planning domains. We present pDOOML, from Planning Domain Object Oriented Modeling Language. This language has most of the key features associated with O-O languages in programming. It allows us to specify a library of classes using standard O-O practice, e.g. multiple-inheritance. Afterwards, we can define a planning domain by declaring the set of objects that composes it and by specifying how they are linked. The objects are created by declaring them instances of a given class in the library. Now we turn to a new approach for evaluating plans. Here, we introduce a new notion of how to measure plan quality. This notion is presented on top of PKS, a framework for planning with incomplete information and sensing, introduced by Bacchus and Petrick in [BP98]. We choose PKS because it is an extension of STRIPS to domains with incomplete information and sensing. v

This means that PKS can be proposed as a reference for comparisons with other formalisms that approach the problem from other perspectives. To this end, we provide a formal semantics for PKS, as well as analyzing and extending it. We prove that for any finite instance of the PKS planning problem, the reachable states are finite; on the basis of this result we propose an improved planning algorithm that is not only sound, as the one proposed by the original authors, but also complete. We extend PKS to include conditional plans with cycles and introduce the distinction between different classes of solutions: strong, strong cyclic, weak acyclic and weak cyclic. In contrast with current belief, we prove that some weak acyclic solutions are more likely to succeed for a limited execution than some strong cyclic solutions, revealing the lack of a method for judging the quality of different solutions. Finally, we introduce a quality measure for all classes of solutions, and a quantitative method for comparing them.

Contents 1 Introduction 1.1 O-O knowledge representation for planning . . . . . . . . . . . 1.2 Evaluating and comparing plans with incomplete information and sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Summary and structure of the dissertation . . . . . . . . . . . .

1 2 5 7

2 The planning problem in AI 11 2.1 Introducing the automated planning problem . . . . . . . . . . 12 2.1.1 A formal unifying view of planning . . . . . . . . . . . . 18 2.2 The Situation Calculus . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1 The planning problem in the Situation Calculus . . . . 23 2.3 STRIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3.1 The State Space . . . . . . . . . . . . . . . . . . . . . . 27 2.3.2 The Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3.3 The Semantics . . . . . . . . . . . . . . . . . . . . . . . 31 2.4 STRIPSsorts : A many-sorted version of STRIPS . . . . . . . . . 34 2.5 STRIPSOWA : An Open World Assumption STRIPS . . . . . . 40 MUTEX 2.6 STRIPS : Dealing with sets of mutex atoms . . . . . . . 41 SAS 2.7 STRIPS : Using State Variables . . . . . . . . . . . . . . . . 44 2.7.1 Comparing: state variables vs. atoms . . . . . . . . . . 50 2.8 Further enhancements of STRIPS . . . . . . . . . . . . . . . . . 52 CEff 2.8.1 STRIPS : STRIPS enhanced with conditional effects 53 2.8.2 Expressing preconditions . . . . . . . . . . . . . . . . . 53 2.8.3 Writing effects . . . . . . . . . . . . . . . . . . . . . . . 53 2.8.4 Combining extensions . . . . . . . . . . . . . . . . . . . 54 2.8.5 About the semantics of PDDL 2.1 . . . . . . . . . . . . 55 2.9 Presenting the Two Oil Tanks domain . . . . . . . . . . . . . . 57 2.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 vii

I

An object-oriented language for planning domains

71

3 Explicit Concurrent Planning (ECP) 3.1 Introducing ECP . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 CSTRIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 The State Space . . . . . . . . . . . . . . . . . . . . . . 3.2.2 The Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 The Semantics . . . . . . . . . . . . . . . . . . . . . . . SAS 3.3 CSTRIPS : Using State Variables . . . . . . . . . . . . . . . 3.4 The other extensions of CSTRIPS . . . . . . . . . . . . . . . . 3.5 The Two Oil Tanks domain example revisited . . . . . . . . . . 3.5.1 The Shared Oil Tank domain: A more coupled example 3.5.2 Upgrading for tanks that use “erosion aware” valves . . 3.6 Analyzing CSTRIPS . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 On the relations with STRIPS . . . . . . . . . . . . . . 3.6.2 Planning algorithms and complexity . . . . . . . . . . . 3.6.3 Taking advantage of explicit concurrency . . . . . . . . 3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73 73 79 79 80 84 87 91 93 95 103 106 106 106 108 109

4 Object-Domains 4.1 A world of objects based on ECP . . . . . . . . . . . . . 4.1.1 In a world of ground atoms . . . . . . . . . . . . 4.1.2 Sub-domains . . . . . . . . . . . . . . . . . . . . 4.1.3 Classifying the ground atoms . . . . . . . . . . . 4.2 Defining an Object-Domain . . . . . . . . . . . . . . . . 4.3 The Meaning of an Object-Domain . . . . . . . . . . . . 4.4 Object-Domains for extensions of CSTRIPS . . . . . . . 4.5 The Two Oil Tanks domain as an object-domain . . . . 4.5.1 Revisiting the case of tanks with “erosion aware” 4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . valves . . . .

111 114 114 116 119 120 123 127 129 132 134

5 pDOOML: An O-O Language for planning 5.1 pDOOML: The Language . . . . . . . . . . . . . . . . 5.1.1 Declaring a class . . . . . . . . . . . . . . . . . 5.1.2 Inheritance . . . . . . . . . . . . . . . . . . . . 5.1.3 The accessible features . . . . . . . . . . . . . . 5.1.4 Abstract classes, deferred and constant features 5.1.5 Specifying threads . . . . . . . . . . . . . . . . 5.1.6 Declaring functions . . . . . . . . . . . . . . . . 5.1.7 The heirs of SORT and STATEVAR . . . . . . . . 5.1.8 A general purpose library of state variables . . 5.1.9 An array of state variables . . . . . . . . . . . 5.2 TOT & SOT revisited with pDOOML . . . . . . . . .

. . . . . . . . . . .

137 138 138 141 144 146 146 147 148 150 154 154

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

5.3

5.2.1 The heirs of SORT and STATEVAR for TOT & SOT . 5.2.2 The heirs of OBJECT for TOT & SOT . . . . . . . . 5.2.3 Specifying the TOT & SOT planning domains . . 5.2.4 Upgrading for “erosion aware” tanks . . . . . . . . 5.2.5 About the semantics of pDOOML . . . . . . . . . 5.2.6 The advantages of using pDOOML . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

155 156 161 162 166 168 170

II Evaluating and comparing plans with incomplete information and sensing 171 6 A formalization and extension of PKS 6.1 PKS: The heir of STRIPS for incomplete information 6.2 Database-State space & Knowledge-State space . . . . 6.3 The PKS planning problem . . . . . . . . . . . . . . . 6.4 Solutions to the PKS planning problem . . . . . . . . 6.5 Remarks on the proposed formalization of PKS . . . . 6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

173 174 175 178 181 187 188

7 Analyzing the PKS planning framework 7.1 The PKS Database-State space . . . . . . . . . . . . . . . . . . 7.2 The PKS Knowledge-State space . . . . . . . . . . . . . . . . . 7.3 The PKS reasoning capabilities . . . . . . . . . . . . . . . . . . 7.4 The PKS complexity . . . . . . . . . . . . . . . . . . . . . . . . 7.5 PlanPKS* : a sound and complete planning algorithm for PKS 7.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

191 191 194 194 195 196 199

8 A quantitative analysis of plan quality 8.1 Are the four classes of solutions a guide for their quality? . . . 8.2 A quantitative measure of plan quality for comparing solutions 8.3 An approximation for acyclic solutions . . . . . . . . . . . . . . 8.4 An approximation for cyclic solutions . . . . . . . . . . . . . . 8.5 Comparing strong, strong cyclic, weak acyclic and weak cyclic solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

201 201 205 207 209

. . . . . .

. . . . . .

. . . . . .

. . . . . .

212 214

9 Conclusion 217 9.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 A Notation 223 A.1 Set theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 A.2 First Order Logic . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Bibliography

227

Chapter 1

Introduction We started this research after some years of experience in software engineering for space mission operations, with the main motivation of attacking the problem of planning them. After building the necessary background in AI planning, two questions directed our research. Why current planning domain definition languages are not object-oriented, or at least as modular as programing languages? Why are there so many different planning frameworks growing independently, and without a clear understanding of their specific contributions and relations? Both questions are a direct product of highly practical motivations. With regard to the first question, our concern is that modeling complex systems (as a space operation environment) without a modular language for describing planning domains is something too error prone and difficult to manage. If we cannot rely on a modular language, it is almost impossible to divide the modeling work among many engineers. With regard to the second question, we are concerned about which framework is convenient to use for a particular problem at hand. We should have a formal approach to guide us when selecting a framework for a certain application. We realized that this problem was too vast. Indeed, when we deal with incomplete information and sensing it was not even clear how to formally compare different solutions to the same planning problem because they contain branches and loops. So, we decided to analyze the problem of plan quality for incomplete information and sensing, because it could bring us a step closer to the understanding of how to compare different planning frameworks and seemed a more manageable problem. The following two questions summarize the main objectives of this thesis: • How to define a planning domain definition language as modular and object-oriented as the current programming languages? • How to compare and relate different plans for domains with incomplete information and sensing? 1

2

CHAPTER 1. INTRODUCTION

The two following sections expand these two independent queries that motivate the research described in this thesis, and our answers to them. The last section of this introduction briefly summarizes the main results and the structure of the dissertation.

1.1

Object-Oriented knowledge representation for planning

The power of the modeling tools for AI Planning is far below what is found in computer programming languages. In some ways present knowledge engineering resembles the old days of programming in assembler. For example, it is not uncommon to hear inside the AI Planning community, comments like “everything can be done with modeling languages like the Situation Calculus [McC68] in its modern versions”. The Situation Calculus is a deductive planning framework based on first order logic introduced by McCarthy and Hayes at the end of the sixties. We will briefly introduce it in Section 2.2. To anyone who comes from years of developing complex software systems, this sounds like the melancholic comments of old programmers about the fact that everything is possible with assembler. Which is certainly true in an ideal world of omnipotent programmers, but completely impossible in ours. It is important to highlight that high level programming languages cannot reproduce every possible assembler code, but the hope is that we can avoid several problems with restrictions. We have seen these restrictions made several times in the history of programming languages, most recently during the amazing object-oriented revolution, and they have always paid off. If you want to do real knowledge engineering in a big project, to describe a really complex planning domain with, say, tens of engineers working in parallel, you will soon discover that the current planning domain modeling languages are not structured at all, and that those engineers are writing the same unique big code. In this category we have not only the mentioned Situation Calculus, but also most modern languages, including PDDL [MGH+ 98, McD98] and its extension to temporal domains PDDL 2.1 [FL03], the planning domain definition languages used in the International Planning Competition (IPC)1 . Why are there no modular or even object-oriented planning domain languages? Searching for an answer, we decided to analyze various planning frameworks looking into their main characteristics to identify those that can lead us to more modular or O-O frameworks. We will use CSP-Based Planning2 to denote several similar planning frameworks based on the Constraint 1

The IPC is a bi-annual event, hosted at the Artificial Intelligence Planning and Scheduling Conference series, see http://ipc.icaps-conference.org/. 2 We write in boldface every concept when we introduce it or define it.

1.1. O-O KNOWLEDGE REPRESENTATION FOR PLANNING

3

Satisfaction Problem [MSCD92, Mus94, GL94, CO96, RKC+ 99, JMM+ 00, FJ03, CFO04]. All these frameworks are efforts oriented to solve practical problems, all have nurture from the scheduling techniques. These frameworks have attracted our attention because they represent several concurrent threads of activities and use state variables, as it is common in scheduling. Intuitively, the presence of these two characteristics make easier to modify them to achieve modularity and object-orientation. These frameworks are quite complex, most of them include many heterogeneous features all bundled together and lack formal semantics. So, it was not easy to go beyond the intuition level and understand clearly which of their characteristics were essential for our task. As we describe in the first part of this dissertation, the explicit representation of concurrency is the most important feature to increase the modularity in the description of planning domains. We describe that it is enough to have a very simple planning framework that represents concurrency explicitly to construct a really modular and object-oriented domain description language. So, we propose to call Explicit Concurrent Planning (ECP) all the planning frameworks such that plans explicitly represent which actions are executed concurrently. We develop these ideas by presenting a formal ECP framework for planning with concurrent threads. We present CSTRIPS (from Concurrent STRIPS), presented first in [OC04], an ECP extension of STRIPS [FN71, Lif86]. In fact, we prefer to highlight the main characteristics of ECP by presenting them on top of a very well known planning frameworks. The relatively simplicity of STRIPS helps underlining what is new. Proceeding otherwise would have had the drawback of blurring features that characterize ECP with those of the underlying framework. This heir of STRIPS only differs from it in one characteristic: it represents the concurrency of actions explicitly in the form of different threads that change in parallel and such that it is necessary to plan for all of them explicitly. We later enhance CSTRIPS by describing many other powerful extensions, including a many-sorted version, and a version based on state variables. To emphasize how an ECP framework is constructed, we present these extended versions by extending STRIPS and then showing how to build the corresponding ECP version of that extension. One of these combined extensions is of particular interest because its starting point – the corresponding extended STRIPS we use for building it – has semantics that encloses the core features of that of PDDL 2.1 [FL03]. Afterwards, we define Object-Domains, i.e. planning domains that are defined as a collection of objects, as a means to enhance our capabilities for modeling planning domains. By specifying a planning domain as an ObjectDomain we can specify more semantic properties of the domain than usual, most of the properties that usually characterize an object in the programming language literature: e.g. namely objects are related by a client/supplier rela-

4


tionship, the interfaces of the objects are accessed only by the corresponding clients, some data are hidden and can be accessed only by them, etc. An Object-Domain specification can be automatically controlled to see if it is consistent, meaning that the declared properties and relations of its objects are respecting overall the specification. For example, checking that no object wrongly accesses data that it should not, as it is the case when an object accesses data of another object that is not one of its suppliers. This procedure of declaring an Object-Domain and controlling if it is consistent guarantees the knowledge engineer that the objects in the specified planning domain behave as intended. This is indispensable for a real distribution of the modeling effort. Several engineers can work in parallel specifying different objects and at the end we can control that the entire specification is consistent. Our presentation of Object-Domains is based on CSTRIPS and all its extensions, but, as we explain in Chapter 4, it is extremely easy to proceed in the same way for any other ECP framework. Furthermore, the definition of Object-Domain and consistency is almost the same for any ECP framework. We then introduce pDOOML from Planning Domain Object Oriented Modeling Language (pronounce it “p-doomel”). pDOOML is a simple ObjectOriented (O-O) language for defining planning domains as Object-Domains. This language allows the knowledge engineer to specify a library of classes. Also, it is possible to define a new class by inheriting from one or more previously declared classes as in O-O programming. Afterwards, we can declare an Object-Domain by simply creating objects from the library of classes and link them as desired. Our presentation of this language is based on the ObjectDomains for CSTRIPS and all its extensions, but, as we explain in Chapter 5, it is extremely easy to proceed equivalently for any other ECP framework. Even if this problem is extremely relevant when we deal with really huge and complex planning domains 3 , notably few works have focused at some level on the notion of objects in planning, namely McCluskey and Porteous (e.g. in [MP97, McC00]) and Biundo and Stephan (e.g., in [BS96]). Even if these works centrally pursue the same objectives as ours, the direction they take is quite different from ours. In fact, the notion of object in their works lacks most features usually associated with object-orientation, like for example the objects’ interface or the client/supplier relationship between objects, both central in the object-oriented classical literature and also in our work. It is worth highlighting that this account can be taken as a possible explanation about why the AI planning community has not produced until now a really object-oriented planning domain definition language. Indeed, all major 3

See [McD04] for an on-going attempt with the same underlying motivations. McDermott introduces OPT (from Ontology with Polymorphic Types), “an attempt to create a generalpurpose notation for creating ontologies, defined as formalized conceptual frameworks for domains about which programs are to reason.”

1.2. EVALUATING AND COMPARING PLANS WITH INCOMPLETE INFORMATION AND SENSING 5 mainstream planning frameworks do not represent concurrency explicitly, but, as we said, the explicit representation of concurrency has been the fundamental step in constructing objects and later, based on them, an O-O planning domain definition language. We open a new path for Object-Orientation in Knowledge Engineering for Planning and simultaneously we open the door for planning algorithms that profit from this O-O more structured representation.

1.2

Evaluating and comparing plans with incomplete information and sensing

In AI Planning, increasing attention has been devoted to the problem of planning with incomplete information and sensing, as a response to its relevance for achieving realistic applications. Various frameworks for this kind of planning problem have been presented in recent years, e.g. [DINR96, DINR97, BP98, CRT98, BCR01, PB02, CPRT03, CGT03, Rin03]. In the second part of this dissertation we study one of these frameworks, namely PKS (Planning with Knowledge and Sensing), proposed by Bacchus and Petrick in [BP98, PB02]. In [BP98] the authors define a modeling framework for incomplete information and sensing. In [PB02] they introduce a planning algorithm, called PlanPKS, which produces conditional plans for incomplete information and sensing problems. We provide formal semantics for PKS and derive some properties grounded on it. PKS is a generalization of STRIPS [FN71, Lif86] that addresses planning with incomplete information and sensing. While STRIPS reasons on the “state of the world”, PKS reasons on the “knowledge of the agent about the world”. Moreover, we consider PKS of interest because the general familiarity with STRIPS makes PKS easier to understand and compare with previous planning formalisms than any other framework for incomplete information and sensing. In addition, various frameworks for this kind of planning problems have grown completely isolated from one another in recent years, except for the implicit comparison that relies on experimental testing against common benchmarks. Therefore, PKS can be used as a common base to understand the scope and relationship between all these planning frameworks. Certainly, to use PKS for this purpose, we need to have its semantics formally defined in detail. So, we define this formal semantics. Actually, the formal semantics we provide include some features not present in the original version. The original version of PKS was defined only for acyclic plans. We extend PKS to include conditional plans that are graphs and therefore can have cycles, as well as a distinction between different classes of solutions: strong, strong cyclic, weak acyclic and weak cyclic. These extensions are necessary to perform a theoretical comparison of PKS with other

6


frameworks, like [DINR96, DINR97], that can generate cyclic plans. We also enhance PKS by providing a new planning algorithm that is sound and complete. The original planning algorithm was sound but not complete. Hence, in planning with incomplete information and sensing, we deal with plans that might have cycles and not only branches. The main subject of the second part of this dissertation deals with the problem of comparing different solutions of this planning problem. In [CPRT03] the authors present three classes of solutions: (1) Plans that are strong solutions, meaning that they have no cycles and satisfy the goal in all their possible terminations; (2) Plans that are strong cyclic solutions, meaning that, even if they have cycles, it is always possible to escape from them (i.e. there is always a branch that might take the plan out of the loop) and the goal is satisfied in all their possible terminations; and (3) Plans that are weak solutions, a class that encloses all other solutions. In [CPRT03] it is stated that “weak and strong solutions correspond to the two extreme requirements for satisfying reachability goals”, and that in cases where “weak solutions are not acceptable and strong solutions do not exist [. . . ] strong cyclic solutions are a viable alternative.” These statements were made according to the assumption that in some applications, e.g. safety critical ones, one cannot accept weak solutions of any type. Clearly, by assuming a priori that weak solutions are forbidden, we leave them out, and deal only with strong and strong cyclic ones. This assumption is not useful for every planning problem, hence, we need to consider also weak solutions when answering the question about the quality of plans in general. We identified another interesting set of solutions, the weak acyclic solutions (plans that do not have cycles but such that the goal is not satisfied in all its terminals). It is enough to notice that this set of solutions is not included in those strong acyclic to understand that the previous statements cannot be taken as valid in general, i.e. strong cyclic solutions are not always better than weak ones. We prove that, if we do not assume the execution of a plan to run forever, there are weak acyclic plans that are better than strong cyclic ones, and so, that the classification of plans in strong, strong cyclic, weak acyclic and weak cyclic does not give us any indication of their quality as solutions. Hence, the question we posed at the beginning of this section, about which solutions are better, has become more important. We have revealed the lack of existence of a method to analyze the quality of solutions. The main result of the second part of this dissertation is a general quantitative method to analyze the quality of solutions and compare them. The key idea behind this development is extremely simple: independently of the class of solution a plan belongs to, its probability of success after a certain number of steps of execution is the most important index of its quality. So, we define a quantitative quality measures for any kind of plan as equal to this probability. Then we proceed by delivering various approximations of this quality

1.3. SUMMARY AND STRUCTURE OF THE DISSERTATION

7

measures that can be applied to the different classes of solutions. Finally, we explain how to use these measures to compare solutions and choose the best ones4 .

1.3

Summary and structure of the dissertation

This dissertation presents two main contributions: a novel strategy to model planning domains in a more structured way than nowadays, and a new approach to evaluate the quality of plans for domains with incomplete information and sensing. Our strategy to model planning domains is built following three logical steps that can be repeated on top of various current planning frameworks. These logical steps are: First, to extend the framework to explicitly represent the concurrent activities as distinct concurrent threads; second, to introduce a new notion of object suited for modeling planning domains as a set of objects instead of simple operators; and third, to introduce an Object-Oriented ( O-O) language for defining planning domains. In this thesis we choose to present these ideas on top of STRIPS as it is a very well known planning framework. So, we proceed by first presenting STRIPS, and extend it with several additional facilities. This extension method may be contrasted with the restriction method, where one first defines one general language and then introduces a number of restrictions to prove specific properties of the system. We favor the extension method as new results are acquired in a stepwise manner, highlighting the specific contribution of each step. We introduce a new notion of how to measure plan quality, based on PKS a framework for planning with incomplete information and sensing introduced by Bacchus and Petrick in [BP98]. We choose PKS because it is an extension of STRIPS to domains with incomplete information and sensing. This allows us to present this ideas about plan quality to the most wide audience possible, and in a very unified form. The dissertation consists of this Introduction, Chapter 2, two parts with our main contributions, and a closing chapter with some concluding remarks. In Chapter 2 we introduce the planning problem in AI. We start by giving a broad overview of it, introducing the common terminology, and we explain an unifying pattern we propose to use when describing a planning framework. Afterwards, we briefly describe the Situation Calculus [McC68], the first planning framework. Then, we give a formal detailed description of STRIPS [FN71]. Most current planning frameworks are heirs of STRIPS, and those we present in Parts I and II are not an exception. So, presenting STRIPS helps us not only to introduce the reader to the most widely known planning framework, 4

We presented first these ideas in [Ogl05].

8


but also to introduce the notation we use later, and the pattern we follow overall in this dissertation, each time we present a planning framework. Then, we present several extensions to STRIPS. This is important because the various frameworks we present in Parts I and II also contain these extensions. This allows us, particularly in Part I, to concentrate on the really important issues, and at the end of each chapter briefly comment on how to build extensions using the method we describe in this chapter. Finally, we present the Two Tanks Oil (TOT) domain, to show how the current techniques for modeling planning domains are stressed when dealing with highly concurrent domains. This helps us to highlight the differences with the approach we present in Part I: The TOT domain is the running example for this part. Part I, named “An object-oriented language for planning domains”, consists of three chapters. • In Chapter 3 we introduce the concept of explicit concurrent planning. Then, we formally present the syntax and semantics of CSTRIPS, an ECP extension of STRIPS, which is the most basic pure ECP framework. Then, we present several extensions of CSTRIPS and analyze this framework, its relation with STRIPS its planning algorithms and complexity issues. Also we comment on how to build CPDDL2.1, an ECP extension of PDDL2.1. Finally we revisit the TOT domain example to show how easy it is to model it with an ECP framework, and present a more coupled example, the Shared Oil Tank (SOT) problem. • In Chapter 4 we present the syntax and semantics of objects and of object-domains — planning domains made up by sets of objects — and show how object-domains are translated into CSTRIPS domains guaranteeing certain semantic properties. We explain how to define objectdomains for the various extensions of CSTRIPS we presented in the previous chapter, and for CPDDL2.1. Finally, we show how to model the TOT example as an object-domain. • In Chapter 5 we present pDOOML, an object-oriented language for specifying object-domains for CSTRIPS and its extensions. We explain how to specify libraries of classes, how to specify new classes inheriting from old ones, and how to build an object-domain by creating objects of those classes. Then, we model the TOT and SOT examples with this language, to manifest its great modularity. In addition, we explain the semantics of pDOOML, i.e. how a planning domain specified in pDOOML is translated into a CSTRIPS Object-Domains. And finally we make some observations about the main characteristics of this language. Part II, named “Planning with incomplete information and sensing”, consists of three chapters.

9 • In Chapter 6 we present the formal semantics for PKS. We first define what in PKS takes the place of states in STRIPS, the database-states. We also define the knowledge-states, and how these two kinds of states are related. We define an instance of the PKS planning problem and then what is a solution for this problem. The extended version of PKS we present deals with four kinds of solutions: strong, strong cyclic, weak acyclic and weak cyclic. • In Chapter 7 some results are derived, based on this formal semantics. The main outcomes are summarized as follows: – We prove that, given a finite instance of the PKS planning problem, the reachable state space associated with that instance is finite. By reachable state space we mean the subspace of the database-state space that can be visited by the reasoning mechanism of PKS when searching for a solution to that instance. This result is somehow surprising in a framework with operators whose effects can add formulas with universally quantified variables. – We describe a new planning algorithm PlanPKS* which is sound and complete for the formal semantics given here. This is an improvement with respect to the planning algorithm proposed in [PB02], which is sound but not complete. – We consider complexity aspects, prove that the PKS plan existence problem is at least in EX P. This is caused by the presence of the operators’ parameters. The problem restricted to parameterless operators is in P SP ACE. • In Chapter 8 we explain how to compare the quality of the various classes of solutions: strong, strong cyclic, weak acyclic, and weak cyclic. First we show that, contrary to current belief, some weak acyclic solutions have a larger probability of success after executing a finite number of steps than some strong cyclic solutions, thus, highlighting the lack of a proper method for judging the quality of solutions. Afterwards, we advance in resolving this problem by providing a quantitative measure of the quality of solutions of any class, and a quantitative method for comparing these solutions. Chapter 9 gives some concluding remarks and closes the dissertation, but for an appendix with the notation we used in it.

Chapter 2

The planning problem in AI In this chapter we present the main topic of this dissertation: The planning problem in AI. We start by giving a broad view and simultaneously introducing most of the basic terminology commonly used inside the planning and scheduling research community, particularly including what a planning framework is. After this, we explain the general pattern we propose to use when describing a planning framework. Afterwards, we briefly describe the Situation Calculus [McC68], and then we give a formal detailed description of STRIPS [FN71]. Most planning frameworks are extensions of STRIPS, and the main results of this dissertation, presented in Parts I and II, are not an exception to this. So, presenting STRIPS helps us not only to introduce the reader to the most widely known planning framework, but also to introduce the notation we use later, and the pattern we follow overall this dissertation, each time we present a planning framework. Then, we present several extensions to STRIPS. We present each of them isolated from the others, and explain at the end how to combine them. The presentation of these extensions is important because the various frameworks we present in Parts I and II contain them. This allows us, particularly in Part I, to concentrate on illustrating the important issues of each framework, and just comment at the end of each chapter on how to extend it using the method we describe in this chapter. Finally, we present the Two Tanks Oil domain, an example of a planning domain that is our running example for Part I. We do not provide here the reader with an historical perspective of the various planning frameworks in AI because there are many texts that do just that. We prefer to offer a more unified view, presenting all the frameworks using a unique formal pattern. We refer the reader interested in an historical perspective to the first two chapters of [Bäc92]. We refer the reader to Appendix A for the notation used throughout the 11

12

CHAPTER 2. THE PLANNING PROBLEM IN AI

following sections.

2.1

Introducing the automated planning problem

Automated on-line planning. Figure 2.1 shows a broad conceptual view of what is intended as automated on-line planning in AI. The objective of automated planning is to automatically generate plans 1 and execute them to control a system to make it behave in a certain desired way. In general the system to be controlled is a real physical system. The desired behaviour is specified by a human user by setting some goals through a user interface tool (called GUI in the figure). These goals can be of various types. Current practice refers to reachability goals 2 when the request is only to act on the system until its internal state is such that it satisfies all the requested goals. In this case usually it is said that the system has reached a goal state and the plan terminates. It is common to use the terms extended goals when the request goes beyond this, and the goal conditions are requested onto any or some intermediate states. For example, in addition to a subset of goal states, it might be requested to avoid certain dangerous states. So, extended goals include, as a particular case, reachability goals. Also the cases of plans that might run forever are included as valid extended goals, i.e. plans that that might never terminate, always keeping the required extended goals. Clearly, these plans might be changed for other plans, thus terminating them. If some new goals are requested by the user, the planner might produce a new plan and replace it for the previous plan under execution. The goals are passed to the planner, a program in charge of generating the plans to satisfy the desired goals. The generated plans are passed to the controller which is in charge of executing them. The controller controls the system by sending it basic commands usually called actions. Usually it is said that an action is executed whenever the controller commands the system by sending it that action. The system can have several internal physical states. The set of all the internal states of a system is called the State Space. The execution of an action at a given state might produce a change of state. This new state is usually referred to as the result of the execution of the action at that state. The physical state of the system can change for several reasons. The commanding of some action might change its state. The environment into which the system is embedded can change its state through events. Finally, the system can change its state by its own internal events. It is not possible to 1

In this section we write in italic mostly to mark the concepts that have a counterpart in the figures. 2 It is also common to find the term attainment goals instead of reachability goals.

2.1. INTRODUCING THE AUTOMATED PLANNING PROBLEM

13

Ctrl Start Exec

Environment ts en Ev

Goals

User

Actions

Plans

GUI

Internal Events

Planner

Controller

System

Observations Observations

Observations

Figure 2.1: Automated on-line planning Ctrl Start Exec


Plan description

Domain specification

Internal Events

Actions

User

GUI

Extended goal specification

Planner

Controller

System

Observations

Execution Monitor

Observation description

Observations

Observations

Figure 2.2: Automated domain independent on-line planning Ctrl Start Exec

User

GUI

Extended goal specification


Plan Description

Domain specification Planner

Internal Events

System

Observation description Observations

Figure 2.3: Automated domain independent off-line planning Ctrl Start Exec


Plan Description

Internal Events

Actions

User

GUI

Controller Observations

Figure 2.4: The execution model for off-line planning

System

14


execute an action in every state of the system. When this is possible we say that the action is executable in that state. An action, even when executed in an executable state, not necessarily produces the desired change of the system state, because of the synchronous occurrence of either environmental events 3 or internal events. In such cases, it is common to say that the system is not deterministic. Notice that in these cases the result of the execution of an action in a given state is not unique. It depends on the synchronous occurrence of the events. There are various types of plans. They range from simple ordered lists of actions, to entire complex programs (with control structures like while or if) to be executed by the controller. Sometimes actions can be time-tagged, some other times the whole plan operates in real time. So, in general, the fact that the controller is executing a plan, does not mean that it is sending commands to the system permanently, it uses part of the execution time in looping, waiting until a particular set of observations occur, etc. It is usual to name sequential plan any not time-tagged ordered list of actions. In general, the controller can gather observations about the system, and these observations are used to change the path of the plan execution, e.g. choosing between two paths, depending on the value of a certain observation. If it is not always possible to deduce the state of the system from the observations we say that there is partial observability, and planning under this condition is referred to as planning with incomplete information and sensing. It is common to say that a planner is on-line when the plan under execution might be permanently modified by the planner to adjust it to any unexpected new status of the system. So, the planner continuously gathers observations about the system and might react in real-time generating new plan updates. Clearly, in this schema the planner is a program that contains hardcoded a model of the system, and uses it to produce plans given the goals requested to it. In fact, in this schema also the representation of the goals, observations and plans is hardcoded in the planner, controller and GUI. In case we need to automatically generate plans to control a different system, it is likely that the planner program cannot be used without being extensively rewritten. Clearly, reusability in this approach is very low. Domain independent on-line planning. Figure 2.2 shows a broad conceptual view of what is intended as domain independent automated on-line planning in AI. Basically the situation is the same as above, but for the fact that now the planner does not have hardcoded any information about how the system is. The idea is that the planner does not know anything a priori (hardcoded) about the system. The information about the system is passed to 3

Sometimes the environmental events are called exogenous events.


15

the planner by means of a written description. A special modeling language is needed for this purpose. We say that the planner is domain independent when it knows about the system only through a model described by modeling language. When describing a system using a modeling language, it is common in planning to say that we have specified a planning domain. Sometimes, a unique language is used for all the modeling. This is the case of the Situation Calculus [McC68], and many other frameworks, as we explain briefly in Section 2.2. But it is more common in planning to use at least two specialized modeling languages: A more basic language to model the internal state of the system; and another language to model the actions, i.e. to model how they change the state of the system. Usually the definition of the latter relies on the former, because it needs to describe system states to specify how actions alter them. This latter approach is the one used in STRIPS [FN71] (presented in Section 2.3) and in all the other planning frameworks we present in this dissertation, all heirs of STRIPS. Any language used to specify a planning domain is usually called a domain specification language. We call any language used to specify the state of the system a state description language. A single element of the language represents a state of the physical system, while the whole language represents its complete state space. It is common practice in planning to refer to the state description language as the state space and to its elements as states, thus, blurring somehow the distinction between representation and reality. It is not a big problem to follow this slightly confusing practice if the reader is aware of the distinction. In case we need to refer to the real physical system, we will state that explicitly. Otherwise, in the rest of this dissertation, whenever we refer to a state and a state space we mean its corresponding representation in some state description language and the whole language itself. Sometimes the modeling language leaves certain parameters free, with the purpose of representing a family of similar systems. Also it is usual to refer any specification of a family of similar systems as a planning domain. So far we have characterized domain independent planning, nevertheless, it is important to highlight that to maximize the reusability of the planner program, the representation of goals, observations and plans should not be hardcoded. We need languages to describe them: a goal specification language to specify any extended goal; observation description language, to describe the observations; and a plan description language for representing the plans. In Figure 2.2 we assume the presence of a program, called execution monitor, able to both gather the observations and provide the planner with a description of them in the corresponding observation description language. Therefore, to build a domain independent planner program it is necessary to choose the following four languages: a domain specification language, an observation description language, a goal specification language and a plan de-

16


scription language. The first three languages are used for writing the planner’s input, the latter, for its output. Each planner’s input is called an instance of the planning problem. The planner core, named the planning algorithm, is the algorithm that actually computes a solution plan for any instance of the planning problem. So, the planner needs to be able to interpret the first three languages, to understand its input, and to write the computed solution plan in the latter. Usually the definition of the three languages used to specify the planner ’s input are based on that of the state space (the language used to specify a state of the system). Very frequently all these languages are built on top of a single first order language. It is common in planning to refer any fixed set of these languages as a planning framework, and to choose a name to identify each of them. Each planning framework implicitly defines the major boundaries of which kind of planning problems can be represented and solved properly by it. Every planning framework has an associated unique set of planning problem instances that can be represented by it and that completely characterize it. We can have many planning algorithms for the same planning framework. So, when building a planner, the choice of the planning algorithm is not as essential as the choice of the planning framework. Suppose, after choosing both of them we discover a problem in the planning algorithm that can be fixed by replacing it by a new algorithm. The planning framework is not affected at all by the change. Instead, if the problem is that the planning framework is not expressive enough to capture the system we want to plan for, we can fix this only by changing the planning framework. Usually this means also a change of the planning algorithm. From now on, the word “planning” will be used to refer to domain independent planning. Similarly, with the word planner we understand a domain independent planner. The terms action theory and action languages are also frequently used instead of planning framework, mostly, when the focus is on the capabilities of the framework for representing action, and not on planning. It is also frequent to refer to the state of the system as the state of the world or the state of the domain. The planning problem formulated in its generality, as we have done above, is an extremely complex problem. So, it should not be surprising that simplifying it was the first step made historically in planning. In the remaining of this section we present several of these simplifications, all of them implicitly assume some properties about the system that are not necessarily valid in general. Simplifying: Off-line planning. A first simplification of this general view starts by assuming that we can split the previous continuous on-line process into two sequential steps. In the planning step the plan is generated but not


17

executed. In the execution step the plan is executed until it terminates (if ever), but it is never replaced by a new plan regenerated on the fly. Figures 2.3 and 2.4 on page 13 show these two steps. In both figures the planner acts only in the planning step and it does not receive any on-line feedback from the execution monitor about the state of the system. In fact, the execution monitor is not depicted because it does not interact with the planner anymore. There are many implicit assumptions behind this simplification, all of them need to hold for this approach to succeed. First, it is assumed that during the time we take for planning and until the plan starts working, the state of the system does not change. Second, we assume that the plan contemplates a suitable reaction whatever the future evolution of the system is and independently of the events that can make it change state. Further simplifications. The second assumption we mentioned above implicitly made by off-line planning is particularly hard. Plans are never as embracing as that, except for very simple systems. So, most commonly this approach is accompanied by other assumptions, as the ones described below, that increase the probability that the execution of the plan satisfies the requested goal. • Finite State Space. A system has a finite state space when the number of its internal states is finite. • Full-obsevability. A system is full-observable when there is a one-toone correspondence between the values of the observations and the state, i.e. it is possible to know precisely its state from the observations at every instant of time. Usually, we gather observations about the system, but given certain values of these observations at a certain instant, it is not always possible to determine which state the system is in, because many different states are coherent with those observations. So, if the system is not full-observable, we cannot always be sure of the system state at every instant. An extreme case is when we have null observability, meaning that the agent cannot gather any observation, and hence, it knows nothing about its current state. When this happens we talk about conformant planning. • Deterministic and event-less planning. An action is called deterministic when the outcome of its execution for any system state is always the same, i.e. when the result of its execution is a unique state. A system is event-less when the environment does not generate events that change the state of the system, neither the system has internal events that change it. So, when a system is event-less the only way to

18

CHAPTER 2. THE PLANNING PROBLEM IN AI change its state is by the execution of actions. A system is deterministic when it is event-less and all its actions are deterministic. In this case the planner only needs to know the initial state to know exactly every future state product of the execution of actions. So, in this case, it is not necessary to look at the observations anymore.

Classical planning. Classical planning usually means domain independent automatic planning simplified by all previously mentioned assumptions: reachability goals, plans as ordered list of actions (to be executed in real time, no time-tagging), off-line planning, deterministic domains, event-less domains, domains with full-observability, and a finite state space. Figures 2.5 and 2.6 represent this. The changes with respect to Figures 2.3 and 2.4 on page 13 are: (1) in both the planning and execution steps we have that the environment ellipsis, its corresponding events arrow, and the loop arrow that represents the internal events, are no more present because the system is event-less; (2) the feedback from the system to the planner is now directly the initial state, not anymore observations, because we now have full-observability; (3) there is no need of the observation feedback from the system to the controller ; in fact, being the system full-observable, the planner knows exactly its initial state, and because it is deterministic and event-less, we do not need to check for the states anymore, as they are only the product of the executed actions; (4) the user requests reachability goals, not extended goals as before; (5) the controller commands the system with actions that are now deterministic; and (6) the planner generates and the controller executes a sequential plan, not more complex plans.

2.1.1

A formal unifying view of planning

So far, we presented a broad view of the planning problem in AI, together with the basic terminology. We introduced the idea of a planning framework and explained that each of them has an associated set of planning problem instances, those that can be represented by it and that completely characterize it. We now give a broad view of how to formally specify a planning framework, i.e. we briefly explain the general pattern we propose to use when describing any of them. Coherently, this is the method we follow when presenting many of them throughout this dissertation, including when we introduce our main results in Parts I and II. We said in the Introduction that one of our underlying long-term motivations is to develop a formal approach to guide us selecting the right planning framework for each planning problem. We want to understand the relationship between the various planning frameworks existing today and which are their specific contributions by using a formal approach. We think that defining


19

Ctrl Start Exec

Sequential Plan description

Domain specification User

GUI

Reachability goal specification

Planner

System

System state description Initial State

Figure 2.5: Classical Planning in AI Ctrl Start Exec

Sequential Plan Description Deterministic Actions

User

GUI

Controller

System

Figure 2.6: The execution model for Classical Planning them in a uniform and formal way is almost a prerequisite for this, in fact we want to compare them formally in order to understand their approaches and specific contributions. We start presenting this pattern for the case of planning frameworks that assume full-observability and off-line planning. As we said above, to actually do domain independent planning we need a domain specification language for specifying the domain. Most of the times this language is built on top of a language used to describe the states of the system. As we said above, we refer to it as the state space, and call states its elements. We also explain that we need to specify the goal, which is done using a goal language. Therefore, if we assume that the planning framework is named PF, and that LDPF denotes its domain specification language, SPF its state space and LGPF its extended goal language, we have that the set of all possible instances of the PF planning problem, denoted by IPF is simply the cartesian product of these three languages: IPF ≡ LDPF × SPF × LGPF Nothing more can be represented by this framework PF. We simply write x ∈ IPF to denote that x is a particular instance of the PF planning problem, so we have: x = (D, s0 , G) with D ∈ LDPF the planning domain of x; s0 ∈ SPF the initial state of x; and G ∈ LGPF the goal of x. Afterwards, we need to define what is a plan for the framework PF. This

20


is necessary because, as we said above, the form of these plans changes a lot from framework to framework. So we need to specify which is the plan description language that the framework PF uses. We call it the set of all possible plans in framework PF, and denote it by Plans(LDPF ). Usually, the meaning of a plan depends also on which particular planning domain we are planning for. So, given a planning domain D ∈ LDPF we denote the valid set of plans for domain D as Plans(D). Hence, we define the previously mentioned set of all plans Plans(LDPF ) as the union of Plans(D) over every possible domain in LDPF . To complete the presentation of the semantics of the planning framework PF it is necessary to give, for every instance x ∈ IPF of the PF planning problem, a function to define when a plan can be considered a solution of x. In the case of reachability goals it is enough to define a η : LGPF × SPF → {>, ⊥ }, such that, for every pair of a goal G ∈ LGPF and a state s ∈ SPF (the current state), it returns > when G is satisfied and ⊥ otherwise. In the case of the more general extended goals, we need to provide a more complex function η : LGPF × Plans(LDPF ) × SPF → {>, ⊥ }, such that for every goal G ∈ LGPF , plan P ∈ Plans(LDPF ) and initial state s0 ∈ SPF it returns > when G is satisfied (that is to say, the conditions G imposes on the intermediate states and on the relationships between the various actions in P are satisfied) and ⊥ otherwise. In case we are dealing with systems that are not fully-observable, this is not valid anymore, because in general we do not know the initial state. In this case we can proceed in various ways. One is based on using directly the observation description language. We can call it the observation space, O , and simply write: as we did in the case of the states, and denote it by SPF O ×L IPF ≡ LDPF × SPF GPF

It is also possible to assume that these observations can always be mapped to a set of states (not just one as in the case of full-observability). This set of states consists of all those states that are coherent with the observations. So, we can use the power set of the state space SPF that represents all its possible O , i.e.: subsets, denoted 2SPF instead of SPF IPF ≡ LDPF × 2SPF × LGPF Finally, it is also possible to use a language to represent the knowledge of the agent about the world, instead of the observations or the associated subsets of states. If we denote this language by LKSPF , we have: IPF ≡ LDPF × LKSPF × LGPF This is the case of PKS [BP98, PB02], the planning framework for incomplete information and sensing we present in Part II of this dissertation. In the PKS

2.2. THE SITUATION CALCULUS

21

planning framework the corresponding language LKSP KS is complex enough to need three databases to keep its elements. Due to that, we call it database state space and denote it by DS P KS . So, for any framework PF like PKS we have: I ≡ L × DS × L PF

DPF

PF

GPF

In the partial observability case we also need to change the definition of η in O , 2SPF or L a similar way, replacing SPF for SPF KSPF (or DS PF ) like we did above when defining the instances of the planning problem. In the on-line case the instances of the planning problem depend on the current plan under execution at any time. So, we also need to include the cartesian product with Plans(LDPF ), the language used to describe the current plan under execution. Whenever presenting a planning framework, in this dissertation we follow the previous pattern. All the frameworks we describe deal only with reachability goals. All those presented in this chapter, as well as CSTRIPS and its extensions presented in Section 3.2, are deterministic frameworks that assume full-observability. On the contrary, as was said above, PKS, the framework presented in Part II, deals with incomplete information and sensing. Contemporary research addresses the main topic of this dissertation from two different points of departure, namely traditional AI planning, and the logics of actions and change. A major difference between the two approaches is that questions of computational complexity serve an important role in AI planning, while in the logic-based approaches they are often disregarded in favor of considerations of heuristic rules and search-limiting constraints. In the next section we briefly present the Situation Calculus [McC68, Rei00]. This is the only logic-based approach we introduce. The rest of this dissertation uses the AI planning perspective. In Section 2.3 we introduce STRIPS [FN71], the oldest and best known AI planning framework. Afterwards, we present many AI planning frameworks using an extension method, i.e. by extending STRIPS in a stepwise manner, as we explained in the introduction. We introduce these frameworks in a rather more formal way than is usual in AI planning, with a conscious effort to bring these two perspectives nearer enough to help the comparison between them.

2.2

The Situation Calculus

We now briefly introduce the Situation Calculus 4 . The Situation Calculus is a many-sorted first order language with equality, denoted here by LSitCal , defined as usual by a tuple (W, C, V, P, F) of mutually disjoint sets of sorts, constant, variable, predicate and function symbols, and such that it complies with the following5 : 4

For a complete modern description of it we refer the reader to [Rei00]. In Section 2.4 on page 34 we introduce in detail a many-sorted first order logic; here we assume the reader familiar with these concepts. 5

22

CHAPTER 2. THE PLANNING PROBLEM IN AI • It has three sorts: action for the actions, situation for the situations, and object to enclose all other sorts of objects in the world. So, we have: W = {action, situation, object} • It uses countably infinite variable symbols of each sort. We denote always with a the variables of sort action using subscripts (or superscripts) to distinguish between them; similarly, with s we denote variables of sort situation. • S0 is the only constant symbol of sort situation. Its meaning is to target the initial situation. • Result 6 is a function symbol whose result is of sort situation, it is binary and its arguments are respectively of sort action and situation. Its meaning is to return the resulting situation after applying an action to a given situation. For example, the new situation reached after applying an action a at any situation s is represented by Result(a, s). The situation after applying any n given actions a1 , . . . , an in sequence at situation S0 is: Result(an , . . . Result(a2 , Result(a1 , S0 )) . . . ) The fact that S0 and Result are the unique mechanisms to produce a situation guarantees us that a situation is always of the above form. As a shortcut, we write the latter situation as Result( [a1 , a2 , . . . , an ], S0 ). • A special binary predicate symbol Exec 7 whose arguments are respectively of sort action and situation. Its meaning is that it evaluates to true only when the action is executable in that situation. For example, given any action a and a situation s, Exec(a, s) means that a is executable in the situation s. • A binary predicate symbol < whose arguments are both of sort situation. s < s0 means that s is a proper sub-history of actions s0 . • A set P static of predicate symbols with arity n ≥ 0 whose arguments are of any sort but situation, intended as relations valid at any situation (“static”). 6

Even if this is the symbol used in [McC68], more recently it is common to use the symbol do. We here use Result to help the reader make the appropriate links between the Situation Calculus and the STRIPS planning framework we present later. 7 Usually the predicate symbol used is P oss — from possible — but we use here Exec — from executable — to help the reader make the appropriate links between Situation Calculus and the STRIPS planning framework we present later.


23

• A set F static of function symbols whose result is of sort object, with arity n ≥ 0 and whose arguments are of any sort but situation, intended as functions valid at any situation (“static”). • A set P f luents of Relational Fluents: Predicate symbols with arity n ≥ 0, whose first n − 1 arguments are of any sort but situation and whose last argument is of sort situation. They are intended as relations that depend on the current situation (“dynamic”). • A set F actions of Action Functions: Function symbols of sort action with arity n ≥ 0 whose arguments are of any sort but situation. They are intended as “parameterized actions”, e.g. move(A, B). • A set F f luents of Functional Fluents: Function symbols of any sort but situation with arity n ≥ 0, whose first n − 1 arguments are of any sort but situation, and whose last argument is of sort situation. They are intended as a function whose value depends on the current situation (“dynamic”). Notice that both relational and functional fluents take just one argument of sort situation: the last argument. We denote with termssituation (LSitCal ) the set of all terms of sort situation. The set of primitive actions, denoted by termsp.action (LSitCal ), is defined as the sets of all terms of sort action such that they do not contain functional fluents.

2.2.1

The planning problem in the Situation Calculus

We now show how the Situation Calculus can be used for planning. The State Space. When McCarthy introduced the Situation Calculus he defined a situation as a complete state of the universe at an instant of time, and proposed to treat situations as ordinary objects of a first order logic. Hence, a situation was defined as a state of the world, and vice versa. As we said above, being S0 and Result the unique terms of mechanism that produce a situation, all situations are always written as some Result( [a1 , . . . , an ], S0 ) ∈ termssituation (LSitCal ) for some ai . Even if this suggests that the state space should be SSitCal ≡ termssituation (LSitCal ), it is not the case. In most domains, after executing two different chains of actions, e.g. (a1 , . . . , an ) and (a01 , . . . , a0n ), it is possible to arrive into the same state of the world. So, we have that both Result( [a1 , . . . , an ], S0 ) and Result( [a01 , . . . , a0n ], S0 ) denote the same state. Hence, it is necessary to add into this modeling when these chains produce the same state of the world. In other words, we need to specify when two situations s and s0 are equivalent, denoted s ∼ s0 . Suppose that the

24


equivalent relation ∼ is given, if we denote each equivalence class as usual by: [s]∼ ≡ { s0 | s ∼ s0 }, we can define the state space as: © ª SSitCal = k | k = [s]∼ ∧ s ∈ termssituation (LSitCal ) The initial state is always given by S0 , but the real specification of it goes implicit in the specification of ∼. More recent versions of the Situation Calculus [Rei91, Rei93, Rei00] change this, redefining a situation as the history of the applied actions. So, different situations can correspond to the same state of the world. In this new formulation of the Situation Calculus, a situation is not a state of the world, but a history of actions applied starting at the initial situation S0 . The dynamic properties of the world are modeled by using the relational fluents that depend on which situation we evaluate them (and clearly, include the use of functional fluents as terms of those relational fluents). Hence, the state of the world at a situation s is determined by all the predicates and relational fluents that hold at that situation. Consequently, the state space 8 , denoted by SSitCal , is a particular subset of the Situation Calculus: SSitCal ⊆ LSitCal To specify the initial state we need to specify the axioms that hold in the initial situation. These axioms might have either relational or functional fluents, but they cannot use the Result function, hence, only S0 can take the situation place in the fluents, e.g. P(c, S0 ), P0 (f (S0 ), c0 ) ⊃ P(c0 ). This theory describes the state of the world at the initial situation. In the rest of this section we follow this last version of the Situation Calculus. The Domain Specification Language. We now sketch how to specify a planning domain using the Situation Calculus language LSitCal 9 : 1. Specify the unique name axioms for all the primitive actions. 2. Specify the “static” axioms independent of the situations: axioms written without using fluents, neither relational nor functional, for example P(f (c), c0 ) ⊃ P0 (c). 3. Specify an action precondition axiom for each primitive action act, i.e. for each act ∈ termsp.action (LSitCal ), like this: 8

Defined in the previous section as the language used to specify the state of the world. There are also some foundational axioms that need to be included in the theory, see [Rei00]. 9


25

∀s . Exec(act, s) ≡ φ(s) for any WWF φ(s) of the Situation Calculus, i.e. for any φ(s) ∈ LSitCal meaning that a is executable in a situation s only if φ(s) holds. 4. Specify a successor state axiom for each functional fluent, i.e. for each f ∈ F f luent , like this: ∀a, s . f (Result(a, s)) = t ≡ a = act(t) ∨ ( f (s) = t ∧ (∀t0 . act(t0 ) 6= a) ) for some action function act, i.e. act ∈ F action . So, act(t) is a primitive action, meaning that the function fluent f has value t after applying an action a in situation s only if either a is the primitive action act(t) or if t was its value in s and a did not change it. Notice that all the previous specifications are a subset of LSitCal . So, the Domain Specification Language, denoted by LDSitCal , in the Situation Calculus is a subset of LSitCal itself, i.e.: LDSitCal ⊆ LSitCal The Goal Language. The goal is written as φ(s), for any WFF φ(s) of the LSitCal not containing other situations s0 . The meaning is that we require φ(s) to hold at situation s. So, also the goal specification language is a subset of LSitCal : LGSitCal ⊆ LSitCal The planning problem instances. We can write the set of instances of the planning problem in the Situation Calculus as: ISitCal ≡ LDSitCal × SSitCal × LGSitCal But, clearly, according to the above observations, we have: ISitCal ⊂ LSitCal × LSitCal × LSitCal . This is the main characteristic that distinguishes the Situation Calculus (and many other frameworks, as we observed above): A unique logical language is used to represent everything, from the state of the world to the execution of the actions that change it. Plans and solutions. In the Situation Calculus a plan is defined as an ordered list of primitive actions. Notice that every situation s, being a history of actions from S0 , implicitly defines a plan from S0 to the situation s itself. For example, if we have that s = Result([a1 , . . . , an ], S0 ) the list of primitive

26


actions (a1 , . . . , an ) is a plan that changes the situation from S0 to s. But, we do not have any guarantee that every primitive action is executable in the corresponding situation. So, we need to define when a situation (i.e. its associated plan) is executable. It is enough to require: ∀a, s0 . ( Result(a, s0 ) < s ) ⊃ Exec(a, s0 ) We use Executable(s) as a shortcut of the previous expression to simplify the exposition below. Usually resolution is used to find plans in the Situation Calculus. Suppose we have a goal G(s) ∈ LSitCal . Given the theory composed by the domain specification D ∈ LDSitCal and the initial situation S0 ∈ S, we request a problem solver based on resolution to prove the following formula: @s . G(s) ∧ Executable(s) To prove it wrong, resolution produces a situation that satisfies both the goal and Executable(s), and this situation contains the sequence of actions that compose an executable plan that is also solution for the specified goal G(s) 10 . Some final observations. As we mentioned above, one of the most singular characteristics of the Situation Calculus [McC68] is that it uses a unique first order language LSitCal to represent the world, from the state of the world to the execution of actions that change that state. This is also valid for many other frameworks, from the earliest one QA3 [Gre69] that is similar to the Situation Calculus, to recent formalisms like [GL93, DINR96, GL98]. In contrast with other formalisms — such as for example STRIPS (see Section 2.3) — it is important to notice that in the Situation Calculus the function Result, which maps actions and situations into situations, is an element of the language: Remark 2.2.1.1 In the Situation Calculus the execution of actions is described by the function Result which is an element of F, the set of function symbols of the language LSitCal . Finally, we avoided to mention that the frame axioms are used in the Situation Calculus to state which features of the world do not change when applying an action. The frame problem, an undesirable but necessary proliferation of frame axioms, was reported as a major problem of the Situation 10

GOLOG[LRL+ 97] is a logical programming language that allows us to write very expressive macros of formulas of the Situation Calculus. It can be used to constrain the acceptable situations, thus making the search process more efficient than using only resolution. These macros work as extended goals because they not only specify some required goal fluents to hold, they require conditions over the intermediate situations. Conversely, we do not deal with extended goals in any of the frameworks we present.

2.3. STRIPS

27

Calculus in [MH69]. It is possible to avoid this problem by defining LSitCal as a Second Order Language, see the details in [Rei93, Rei00]. Everything stated above remains true in case we use a Second Order Language instead of a First Order one. STRIPS, the planning framework we present in the next section, avoids this problem by a completely different strategy.

2.3

STRIPS

As Bäckström wrote: “Modern planning is said to begin with the STRIPS system” [Bäc92]. We highlight the characteristics of STRIPS [FN71] that can be considered as laying the foundations of modern planning.

2.3.1

The State Space

In STRIPS, we use a first order language with equality L defined by a tuple (C, V, P, F) of mutually disjoint sets of constant, variable, predicate and function symbols, to describe the state of the world. In Section A.2 we explain that there are various methods for specifying the language L and show the one we use in this dissertation, that is the one most used in planning. A state is represented by any subset of ground atoms of L, meaning the subset of ground atoms that hold in that particular state of the world. Definition 2.3.1.1 The set of all ground atoms in L, denoted by A, and the State Space, denoted by SST RIP S , are respectively defined by: A ≡ atoms(L)[ ∅] \ {>, ⊥} SST RIP S ≡ 2A We explicitly exclude from A the only two atomic sentences that are also logical symbols {>, ⊥} because we want in A only ground atoms made up from predicate symbols. For simplicity, when there is no confusion, we write S instead of SST RIP S . S represents the whole set of states of the world that can be represented with STRIPS. We say that S 0 is a state subspace of S whenever S 0 ⊆ S. Definition 2.3.1.2 Given any subset A0 ⊆ A of the set of all ground atoms, we denote by S(A0 ) its associated state subspace, defined by: 0 S(A0 ) ≡ 2A ⊆ SST RIP S Clearly: S(A) = SST RIP S . As we said above, any state s ∈ S is intended to describe the properties of the world at a particular instant of time. It is important to highlight that any state s is a logical theory in the first order language L. The properties of the world are represented by formulas in this language L. So, we need to define when this state (and logical theory) entails the formulas of L.

28


First of all, we need to define how a state s entails any ground literal of L. We are presenting the Close World Assumption (CWA) [Rei78] version of STRIPS, i.e. we assume a ground atom is false when it is not present in a state, and true otherwise. Formally: ∀s ∈ S ∀a ∈ A . ( a ∈ s iff s |= a ) ∀s ∈ S ∀a ∈ A . ( a 6∈ s iff s |= ¬a ) Hence, under the CWA we can define exactly when a state entails any ground literal of L, and when it entails any conjunction of literals. As usual, we write these conjunctions simply as “conjunctive” sets of literals. Definition 2.3.1.3 Given any state s ∈ S and any ground literal ` of L, i.e. ` ∈ literals(L)[∅], we say that s logically entails `, denoted by s |= `, iff: (` = >) ∨ (` ∈ A ∧ ` ∈ s) ∨ (` = ¬a ∧ a ∈ A ∧ a 6∈ s) Once we have defined how a state s entails the ground literals of L, we are capable of easily extending the definition of entailment to more complex formulas, for example, to conjunctions of ground literals of L. As usual, we write them as “conjunctive” sets of literals, i.e. any subset of literals(L)[∅]. Definition 2.3.1.4 Given any state s ∈ S and any set φ of ground literals of L, i.e. φ ∈ 2literals(L)[∅] , we say that s logically entails φ, denoted also by s |= φ, iff: ( ∀` ∈ φ . s |= ` ) It is worth noticing that, due to the definition of s |= `, for any set φ of ground literals we have 11 : ( s |= φ ) ⇔ ( + φ ⊆ s ∧ atoms(−φ) ∩ s = ∅ ). In general, once we have defined how a state s entails the ground literals of L, we are capable of reasoning about more complex formulas using a standard first order reasoning mechanism as resolution. Hence, for the most general case of any φ ∈ L describing a property of the world, we can use resolution to prove whether or not s logically entails the formula φ which describes that property of the world. In this general case, s |= φ is defined in terms of resolution and at the lowest level, when it is needed to check if s entails a ground atom, it relies on what we stated above. Frequently, computational complexity reasons make it convenient to restrict STRIPS by using only a subset of the formulas to describe the properties of the world. So we may consider any subset L0 ⊆ L that allows us to decrease the complexity of the planning problem we introduce in the following sections, e.g. we may restrict ourselves to use only conjunctions of ground literals of L. 11

The notation +φ and −φ means respectively the sets of positive and negative literals of φ, see Section A.2.

2.3. STRIPS

29

We chose to present the CWA version of STRIPS in more details because it is closer to the original version and also it is the most commonly used. In what follows, when we write STRIPS, we mean only its CWA version. In Section 2.5 we describe how to modify the CWA version of STRIPS to deliver an open world assumption version of it.

2.3.2

The Syntax

In STRIPS, we use a first order language with equality L defined by a tuple (C, V, P, F) of mutually disjoint sets of constant, variable, predicate and function symbols. We use another set of symbols N , disjoint from the previous ones, to represent the names of the operators. Definition 2.3.2.1 The Operator Specification Language is defined by: LOST RIP S ≡ { α | α = ( nα (~x) : P (~x) ⇒ Add(~x)Del(~x) ) } where: • nα ∈ N is the operator’s name, denoted by: N (α) = nα ; • ~x = (x1 , . . . , xn ) with xi ∈ V ∪ terms(L)[∅], for all i=1, . . . , n and n ∈ N0 , the operator’s parameters, a possibly empty finite tuple of variable symbols or ground terms, denoted by ~x(α) = ~x; • P (~x) ⊆ literals(L)[V(~x(α))] , the operator’s preconditions 12 ; • Add(~x), Del(~x) ⊆ atoms(L)[V(~x(α))] , the operator’s effects, respectively called its add and delete lists. For simplicity, when there is no confusion, we write LO instead of LOST RIP S . It is usually requested that the operator’s parameters are only variable symbols, i.e. xi ∈ V. This is done because clearly it is of no use to declare an operator with ground terms as parameters. Nevertheless we accept them, i.e. xi ∈ V ∪ terms(L)[∅], because they allow us to treat in a uniform way both operators and instantiated operators, i.e. operators whose parameters are replaced by ground terms (see Definition 2.3.2.3). For example, this allows us to introduce sets like Eff + (α) below, with a definition valid for both operators and instantiated operators. For any operator α = ( nα (~x) : P (~x) ⇒ Add(~x)Del(~x) ) ∈ LO we introduce the following notation: • Pre(α) ≡ P (~x) • Eff + (α) ≡ Add(~x) • Eff − (α) ≡ Del(~x) 12

The notation V(~x(α)) ⊆ V means the set of variables that appear in ~x(α), see Section A.2.

30


For example, if α = (nα (x, y) : {¬P1 (y)} ⇒ {P2 (x), P3 } {P4 (x), P5 (y)}) we have Pre(α) = {¬P1 (y)}, Eff + (α) = {P2 (x), P3 } and Eff − (α) = {P4 (x), P5 (y)}. Being Pre(α) a subset of literals, we write +Pre(α) meaning the subset of all positive literals in Pre(α) and −Pre(α) meaning the one with all negative literals 13 of Pre(α), so, in the example +Pre(α) = ∅ and −Pre(α) = {¬P1 (y)}. Definition 2.3.2.2 The STRIPS Domain Specification Language, denoted by LDST RIP S , is defined by: LDST RIP S ≡ 2LO \ ∅ For simplicity, when there is no confusion, we write LD instead of LDST RIP S . A STRIPS domain is simply specified by any nonempty set of operators. These operators completely characterize the domain, they are the only operators that can be applied in the domain, hence, they model every action that can be executed in the domain. We write D ∈ LD to mean that D is a STRIPS domain. Given any D ∈ LD , we write α ∈ D to express that α is an operator of D. Definition 2.3.2.3 Given any operator α ∈ LO and any STRIPS domain D ∈ LD , we define the sets respectively called the expansion of the operator and of the domain, as follows: • E(α) ≡ • E(D) ≡

{ αθ | θ : V(~x(α)) → terms(L)[∅] } S α∈D E(α)

E(α) contains all possible instantiations of the operator α. We call instantiated operator any αθ ∈ E(D). For example, given an operator α specified as ( nα (x, y) : {P (x, y)} ⇒ {Q(x, y)} {R(x, y)} ) ∈ LO and a substitution θ where θ(x) = c1 and θ(y) = c2 , we have that the resulting instantiated operator αθ is ( nα (c1 , c2 ) : {P (c1 , c2 )} ⇒ {Q(c1 , c2 )} {R(c1 , c2 )} ) also in LO . Notice that V(~x(α)) = {x, y} and that V(~x(αθ)) = ∅. We denote with LGST RIP S the Goal Specification Language for STRIPS. For simplicity, when there is no confusion, we write LG instead of LGST RIP S . To simplify the present exposition, we restrict STRIPS to the case of reachability goals. As usual, with reachability goals we understand goals such that the fact that they are satisfied depends only on the current state and not on the previous history of states. The most general language to express reachability goals is simply the whole first order language L, i.e. LG ≡ L. We do not commit STRIPS to a particular goal specification language because this is not 13

The notation +Pre(α) and −Pre(α) means respectively the sets of positive and negative literals of Pre(α), see Section A.2.

2.3. STRIPS

31

indispensable. We prefer to leave it as general as possible. We get different members of the STRIPS family depending on which subset of L we choose as goal specification language. If we choose LG = L we get all the members of the STRIPS family based on reachability goals. Clearly, we can be more restrictive (usually to decrease the complexity of the planning algorithms), and deal with some members of the STRIPS family. For example, we can restrict LG to be made only of Horn clauses or only of literals. We denote with STRIPSG:Horn the members of the family such that LG is restricted to Horn clauses, i.e.: LG:Horn ⊂ L. Similarly, when LG is restricted to literals we write STRIPSG:lit . Definition 2.3.2.4 The set of all instances of the STRIPS Planning Problem, denoted by ISTRIPS , is defined by: ISTRIPS ≡ LD × S × LG Therefore, x ∈ ISTRIPS means that x is any instance of the STRIPS Planning Problem. We introduce the following notation for any instance x = (D, s0 , G) ∈ ISTRIPS : • D(x) ≡ D

the planning domain specification of x;

• s0 (x) ≡ s0

the initial state of instance x;

• G(x) ≡ G

the goal of instance x.

When dealing with more restricted members of the STRIPS family, like for example STRIPSG:Horn or STRIPSG:lit , we denote the corresponding sets of G:Horn G:lit G:Horn G:lit instances by ISTRIPS and ISTRIPS . Clearly, ISTRIPS ⊂ ISTRIPS and ISTRIPS ⊂ ISTRIPS . In most cases we simply write STRIPS and ISTRIPS , without the superscript, meaning that what we say is independent of LG .

2.3.3

The Semantics

The semantics of STRIPS is given by showing when an instantiated operator is executable, and which is the result of applying it. In STRIPS, instantiated operators that add and delete the same atomic proposition do not make sense. We eliminate these ill defined operators as follows. Definition 2.3.3.1 Given any STRIPS domain D ∈ LD , we say that any of its instantiated operators αθ ∈ E(D) is consistent iff there are: 1. No competing preconditions: +Pre(αθ) ∩ atoms(−Pre(αθ)) = ∅ 2. No inconsistent effects:

Eff + (αθ) ∩ Eff − (αθ) = ∅

32


Definition 2.3.3.2 Given any instance x ∈ ISTRIPS , we say that any instantiated operator αθ of this domain, i.e. αθ ∈ E(D(x)), is executable in a state s ∈ S, iff 14 : αθ is consistent ∧ s |= Pre(αθ). When αθ is consistent and Pre(αθ) = ∅, the instantiated operator is executable in any state. Definition 2.3.3.3 Given any instance x ∈ ISTRIPS , and any of its instantiated operators αθ ∈ E(D(x)) such that it is executable in state s ∈ S, we say that, the application of αθ in state s results in state s0 ∈ S, denoted by: s |=αθ s0 , iff we have: s0 = s ∪ Eff + (αθ) \ Eff − (αθ). The fact that αθ is executable, and hence consistent, guarantee that the order in which the ground atoms are added to and subtracted from s is not important. We use Result(αθ, s) to refer to the result state s0 of the previous definition, i.e. we define the partial function Result : E(D) × S → S⊥ defined for every instantiated operator αθ ∈ E(D) and for every s ∈ S by: ½ 0 s if (αθ is executable in s) ∧ (s |=αθ s0 ) Result(αθ, s) ≡ ⊥ o.w. Definition 2.3.3.4 Given any STRIPS domain D ∈ LD , a plan P~ in domain D is defined as any finite ordered list of instantiated operators, i.e. any (α1 θ1 , . . . , αm θm ) with m ∈ N0 and such that each αi θi ∈ E(D). We denote by Plans(D) the set of all plans in D and by Plans(LDST RIP S ) the set of all STRIPS plans. Given a plan P~ = (α1 θ1 , . . . , αm θm ) in Plans(D), we say that its length, denoted by kP~ k, is m, the length of the ordered list of instantiated operators. Definition 2.3.3.5 Given any STRIPS domain D ∈ LD we say that a plan P~ = (α1 θ1 , . . . , αm θm ) ∈ Plans(D) is executable in state s0 ∈ S iff: ∃s1 , . . . , sm ∈ S . ( s0

|=α1 θ1 s1

|=α2 θ2 s2 ... |=αm θm sm )

In this case we say that the application of P~ in state s0 results in state ~ sm , and denote this by: s0 |=P sm . Note that each αi θi is executable in state si−1 ∈ S for all i = 1 . . . m. To determine when a plan is a solution to a planning problem we need to provide a semantics for the goal specification language LG . When we are dealing only with reachability goals we know that the goal exclusively depends 14

Being Pre(αθ) a set of literals, the meaning of s |= Pre(αθ), introduced in Definition 2.3.1.4, is +Pre(αθ) ⊆ s ∧ atoms(−Pre(αθ)) ∩ s = ∅.

2.3. STRIPS

33

on the state where we are evaluating it, and hence to determine when a plan reached a goal state we only need to specify the function: η : LG × S → {>, ⊥ } that defines, for each pair (G, s) of a reachability goal and a state, when G is or not satisfied in s. In the most general case, when LG = L, the function η is defined by: ½ > if s |= G η(G, s) ≡ ⊥ o.w. Being G a formula of L in the most general case we know for sure that s |= G is defined as explained in Section 2.3.1. We say that a goal G is satisfied in a state s whenever η(G, s) = >, otherwise, when η(G, s) = ⊥, we say that G is not satisfied in s. For practical applications, it is usual to restrict the goal specification language so that a goal can be proved for any state s more efficiently. For example consider STRIPSlits , the case when LG is restricted to be any conjunction of ground literals of L, i.e. LG = 2literals(L)[∅] . This allows us to use Definition 2.3.1.4 that shows s |= G equivalent to +G ⊆ s ∧ atoms(−G) ∩ s = ∅, and therefore, η is simplified to: ½ > if (+G ⊆ s) ∧ (atoms(−G) ∩ s = ∅) η(G, s) ≡ ⊥ o.w. Notice that it is simple to add existentially quantified variables in LG , like in ADL[Ped86, Ped87], defining η(G, s) as equal to > iff it exists a substitution θ of the variables in G for ground terms such that with the previous definition of η we have η(Gθ, s) = >. Definition 2.3.3.6 Given any instance x ∈ ISTRIPS , we say that any plan P~ = (α1 θ1 , . . . , αm θm ) ∈ Plans(D(x)) is a solution of x iff : ~ ∃sm ∈ S . ( s0 (x) |=P sm ∧ η(G(x), sm ) = > ) We denote by SOLSTRIPS (x) the set of all solutions of x. We write P~ ∈ SOLSTRIPS (x) meaning that P~ is a solution of x. This completes the presentation of the semantics of STRIPS. We presented under the name STRIPS all the members of the family such that the preconditions are conjunctions of literals and the add and delete lists are sets of atoms. We have committed ourselves neither to any restriction on the expressiveness of the goal specification language, nor on the cardinality of the sets of symbols, nor on the arity of the predicates and functions. It is worth noticing that this choice of the expressiveness of preconditions is not indispensable, we chose it because of its great simplicity.

34


STRIPS and the Situation Calculus. In STRIPS we can write: Result(αm θm , . . . Result(α2 θ2 , Result(α1 θ1 , s0 )) . . . ) completely in parallel with what we did in the Situation Calculus, but contrary to what happens in that case (see Remark 2.2.1.1 in page 26), the function Result is not part of the first order language we use to build STRIPS, i.e. Result 6∈ F. Remark 2.3.3.7 In STRIPS, L is used to represent each state of the world, and reason about it, but no symbol of it can represent a change of state, i.e. L is excluded from reasoning about the dynamics of the world. Given a state s ∈ S and a formula φ ∈ L we can check if s |= φ, but in that case we are always reasoning inside the same state, i.e. s. There is no way to reason about different states in STRIPS using L. For that it is necessary to rely on the application of instantiated operators. The reasoning about the dynamics of the world is made by another logic, represented by the application of instantiated operators, whose semantics is defined as above. For example, to reason if state s0 follows s after applying αθ, we use a different logical entailment: s |=αθ s0 . In the following sections we show several extensions of STRIPS.

2.4

STRIPSsorts : A many-sorted version of STRIPS

It is usual in planning to use a set of sorts to restrict the terms that can be assigned to the operator’s parameters. This in turn translates into a manysorted version of the operator’s preconditions, and its add and delete lists. It is clear that, being all these defined as terms, literals and atoms of L, we need to “upgrade” and change the first logic language L for a many-sorted version. The classical first order language we have been using when presenting STRIPS is a one-sorted first order language where all the variables, constants, predicates and functions are associated just with one sort. To make a manysorted version of STRIPS we need a many-sorted first order language. We denote it by Lsorts . Before we continue, we highlight that even if it is common in planning to see the word type used in the place of sort, we prefer the latter because it is more accurate from a logical point of view 15 . A many-sorted first order language is usually constructed by introducing a nonempty finite set of sorts symbols denoted here by W. This set is disjoint 15

For example, type is used in PDDL [MGH+ 98, McD98] and its extension to temporal domains PDDL 2.1 [FL03]. There are also some frameworks that use the word sort, as for example [MP97].

2.4. STRIPSSORTS : A MANY-SORTED VERSION OF STRIPS

35

from every other set of symbols used to construct the language Lsorts and the STRIPSsorts ’s operators. Afterwards, we need to associate the different elements of the language with these sorts. This can be easily done by providing the following functions 16 : • sort : C → W

defined for every c ∈ C

• sort : V → W

defined for every x ∈ V

• sort : P →

Wk

• sort : F → W k+1

defined for every P ∈ P such that arity(P ) = k defined for every f ∈ F such that arity(f ) = k

These functions classify any constant and variable by sort. We introduce the following sets, defined for every sort w ∈ W, which respectively contain only the constants and variables of that sort: • C(w) ≡ { c | c ∈ C ∧ sort(c) = w } • V(w) ≡ { x | x ∈ V ∧ sort(x) = w } Clearly we have: C = ∪w∈W C(w) and V = ∪w∈W V(w). The language Lsorts is constructed as usual, starting by recursively defining the terms of each sort. For any w ∈ W the set of terms of Lsorts of sort w, denoted termsw (Lsorts ), are recursively defined by 17 : • Any variable term x ∈ V s.t. sort(x) = w • Any constant term c ∈ C s.t. sort(c) = w • Any function term f (t1 , . . . , tk ) of arity(f ) = k s.t. sort(f ) = (w1 , . . . , wk , w) ∧ sort(t1 ) = w1 ∧ . . . ∧ sort(tk ) = wk We then continue by recursively defining the atomic formulas and WFF of the logic, including at any level the sorts as it was done above with terms, (see [End72] for details). In Section A.2 we show that there are different methods for specifying L. The most direct one consists of listing the sets of symbols (C, V, P, F) and specifying the arity function (by listing the return value of this arity function for every predicate and function symbol). We also introduce the method we use in this dissertation that is the one most used in planning. The same happens when specifying the many-sorted first order language Lsorts . The simplest choice is just to explicitly list the sets of symbols (W, C, V, P, F) and the values of the arity function as in the previous case, plus, specify the sort function 16

In the last two entries we are defining in fact many functions, not just two, one function for each possible arity of the predicates and functions of L. 17 In the last entry we are defining in fact many functions one for each different arity.

36


by listing what it returns for all the sets of symbols. Instead, in parallel with what we do in the case of L, we follow here the method most commonly used in planning to specify sorts in functions and predicates 18 . This syntax relies on modifying the declaration of the sets P and F by explicitly adding the sort information. Instead, to declare the set of constants and variables we prefer to directly list the sets C(w) and V(w) for each sort, understanding respectively C and V as their corresponding unions for all sorts W. We show how this is done by means of a simple example. Suppose we want to specify the following many-sorted first-order language: • W = {w, w0 } • C = {c1 , c2 , c3 } • V = {x, y, z} • P = {P1 , P2 } • F = {f, g} • arity(P1 ) = 1, arity(P2 ) = 2, arity(f ) = 2, arity(g) = 2 • sort(c1 ) = w, sort(c2 ) = w, sort(c3 ) = w0 , sort(x) = w, sort(y) = w,sort(z) = w0 , sort(f ) = (w, w, w0 ), sort(g) = (w, w0 , w0 ), sort(P1 ) = w, sort(P2 ) = (w, w0 ) We write instead: • W = {w, w0 } • C(w) = {c1 , c2 } and C(w0 ) = {c3 } • V(w) = {x, y} and V(w0 ) = {z} • (:predicates P1 (x − w), P2 (x − w, z − w0 )) • (:functions f (x − w, y − w) − w0 , g(x − w, z − w0 ) − w0 ) ) and we have that both C = C(w) ∪ C(w0 ) and V = V(w) ∪ V(w0 ) are like above. It is a well known result in logic that many-sorted first order languages can be encoded into a one-sorted language, and hence, even if they are convenient to use, because they appeal as “more expressive” to humans, from a strictly formal point of view, in Enderton’s words: “there is nothing essential that can be done with them that cannot already be done without them” [End72]. To define a STRIPSsorts we proceed in a way similar to STRIPS, but for the use of a many-sorted first order language Lsorts instead of L and for the addition of sorts also to operators. In what follows we sketch this. We use a many-sorted first order language with equality Lsorts defined as shown above by using a tuple (W, C, V, P, F) of mutually disjoint sets of 18

We are following here the PDDL syntax for types, as sorts are called in PDDL, see [MGH+ 98, McD98, FL03].


37

sorts, constant, variable, predicate and function symbols, to describe the state of the world. We define Asorts as the set of all ground atoms of the manysorted first order language Lsorts and use it to define the STRIPSsorts ’s State Space. Formally: Asorts ≡ atoms(Lsorts )[∅]

SST RIP Ssorts ≡ 2Asorts

The entailment of a ground atomic literal by a state is defined in the same way as in STRIPS. What needs to be changed is the definition of the operator specification language, because now we need to associate a sort with every parameter. Definition 2.4.0.8 The STRIPSsorts ’s Operator Specification Language is defined by: LOST RIP Ssorts ≡ {α | α = (nα (x1 − w1 , . . . , xn − wn ) : P (~x) ⇒ Add(~x)Del(~x)) ∧ n ∈ N0 } where: • nα ∈ N is the operator’s name, denoted by: N (α) = nα ; ~ = (w1 , . . . , wn ) with wi ∈ W for all i=1, . . . , n; • w • ~x = (x1 , . . . , xn ) with xi ∈ V(wi ) ∪ termswi (Lsorts )[∅] for all i=1, . . . , n the operator’s parameters, a possibly empty finite tuple of variable symbols or ground terms, denoted by ~x(α) = ~x; • P (~x) ⊆ literals(Lsorts )[V(~x(α))] , the operator’s precondition; • Add(~x), Del(~x) ⊆ atoms(Lsorts )[V(~x(α))] , the operator’s effects respectively called its add and delete list. The definition of the domain specification language is completely similar but for LOST RIP Ssorts instead of LOST RIP S , formally: LDST RIP Ssorts ≡ 2

LOST RIP S

sorts

\∅

Accordingly, we need to update the definition of the expansion of the operator and domain, taking care of the sorts. In parallel, the goal specification language LGST RIP Ssorts is similarly restricted to be any subset LGST RIP Ssorts ⊆ LST RIP Ssorts . Hence, the set of all instances of the STRIPSsorts Planning Problem, denoted by IST RIP Ssorts , is defined by: IST RIP Ssorts ≡ LDST RIP Ssorts × SST RIP Ssorts × LGST RIP Ssorts . The semantics of STRIPSsorts is similar to that of STRIPS. All the definitions (i.e, consistent instantiated operator, executable instantiated operator, etc.) are parallel with those of STRIPS, we just need to use the ST RIP Ssorts domain, operators, etc. instead of those of ST RIP S.

38


It is easy to realize that we can encode STRIPSsorts into its simpler onesorted version STRIPS. Clearly this is possible because it is possible to encode the many-sorted first order language into a simpler one-sorted language. Hence, again, even if STRIPSsorts is more convenient to use, because it appeals as “more expressive” to humans, from a strictly formal point of view, we can paraphrase Enderton’s words: there is nothing essential that can be done with STRIPSsorts that cannot already be done with STRIPS. In other words: even if STRIPSsorts is easier to use when modeling planning domains, its computational complexity is the same as that of STRIPS. The advantages of STRIPSsorts have not added extra computation cost. It is worth noticing that this is not always the case; see for example [Ero95], to appreciate how the more appealing decomposition methods in Hierarchical Task Networks (HTN) are not for free. Upgrading for sets of sorts In planning, it is common to use a hierarchy of sorts instead of a simple set of them, as we did above. For example, this happens in PDDL [MGH+ 98, McD98], in its extension to temporal domains PDDL 2.1 [FL03], and in [MP97, McC00]. Even if they use different syntax for declaring the sort hierarchy, all of them produce the same type of hierarchy: there are some sorts and some sets of these sorts 19 . Afterwards, what is associated with the constants, variables, predicates and functions are not the sorts, but these sets of sorts. It is not necessary to also associate the elements of the language with the sorts, because a singleton set of sorts does the same work, e.g. if we want to associate a constant c with a sort w we use the singleton {w} instead of just w. We explain how to extend what we did above to upgrade STRIPSsorts to deal also with sets of sorts. First, we need to declare the basic sorts and as many sets of sorts as wanted. We explain now how. As we did above, we introduce W a nonempty finite set of sorts symbols disjoint from every other set of symbols used. We declare W simply by listing its contents, as we did above. The set of all possible sets of sorts symbols is simply 2W , the power set of W. To declare which set of sorts we mean, we simply list its elements or use a combination of set operations over any previously defined set of sorts. Second, we need to repeat all the steps we did above to upgrade STRIPS into a version that deals with sorts, but using the set of sorts instead of the basic sorts. The meaning will be that the associated sorts are those in the set. For example, if we have W = {w, w0 , w00 }, a predicate P 0 (x − {w, w0 }) 19

A set of sorts is called a supersort in [MP97] and a type as well as the sorts in PDDL.


39

accepts terms of either w or w0 sort, but not of sort w00 . A constant c of sort {w, w0 } is of any of either sort, and so can be used to ground a predicate like P (x − {w, w0 }) as well as one like P 0 (y − {w}), but a constant c0 of sort {w0 } cannot ground the latter predicate. There are many ways for declaring these hierarchical sets of sorts. We follow [MP97]: the set of basic sorts is declared first by enumeration, and afterwards, the various sets of sorts are declared by enumeration or using the set union operation of previous sorts. For example: being the basic sets of sorts {w, w0 } we can declare a set of sorts w00 = {w, w0 }. So, the set of set of sorts is W = {{w} , {w0 } , w00 }. We abuse this notation in two forms: First, we do not write the braces in the case of singletons, e.g. W = {w, w0 , w00 }; second, we avoid listing any singleton set of a basic sort that is not used, e.g. if we do not use {w0 } and we needed it only to define w00 we write W = {w, w00 } abstracting the otherwise useless presence of w0 . The use of sets of sorts makes more flexible the declaration of predicates and functions avoiding the repetition of constants. We exemplify this starting from STRIPSsorts . Suppose we have two sorts w and w0 , and two predicates P (x − w) and P 0 (x0 − w0 ), being x and x0 variables of the corresponding sort. If the range for predicate P is from 0 to 90 and that for P 0 goes from 0 to 100 we need to declare two separate sets of constants like for example: C(w) = {0, . . . , 90} and C(w0 ) = {00 , . . . , 1000 } (we have 192 constants) because we cannot use the constants 0 . . . 90 in P 0 , as they are of a different sort. With the upgrade of STRIPS to sets of sorts that we have presented here, this problem is avoided. We again use two basic sorts {w, w0 } and one set of sorts w00 = {w, w0 }, so W = {w, w0 , w00 }. We declare the predicates: we write P (x − w) meaning P (x − {w}), and P 0 (x0 − w00 ) meaning P 0 (x0 − {w, w0 }). Afterwards, we can declare the set of constants without repetitions: C(w) = {0, . . . , 90} and C(w00 ) = {0, . . . , 100} (we have only 102 constants) 20 . As it is desired, the predicate P (x−w) can be grounded only with constants of sort w, i.e. as we want only in the range 0, . . . , 90, while P 0 (x0 − w00 ) can be grounded with all the constants. From now on, when we write STRIPSsorts we mean the upgraded version that deals with sets of sorts. In the rest of our dissertation we use sorts only in the examples, because they improve their readability. Our theoretical constructions will not deal with many-sortedness. It should be clear at this point, that adding sorts to a planning framework does not add power to it. Instead, it complicates the formal exposition. Clearly, when using sorts in the examples we will be assuming the many-sorted and sets of sorts versions of the formalisms. 20

Notice that in this way we avoided to write the less meaningful variant C(w0 ) = {91, . . . , 100} and C(w00 ) = C(w) ∪ C(w0 ).

40


2.5

STRIPSOWA : An Open World Assumption STRIPS

We now explain how to transform our previous formalization of a CWA version of STRIPS into an open world assumption one, referred to as STRIPSOWA . We start by explaining what the open world assumption is as opposed to the closed one. Under the Open World Assumption (OWA) we cannot assume that a ground atom is false when it is not present in a state. Therefore, to define an OWA version of STRIPS we need to explicitly include the negated literals in S, i.e. by defining its state space as follows: SST RIP SOWA ≡ 2(literals(L)[ ∅]\{>,⊥}) Under the OWA we have: ∀s ∈ SST RIP SOWA ∀a ∈ A . ( a ∈ s ∧ ¬a 6∈ s iff s |= a ) ∀s ∈ SST RIP SOWA ∀a ∈ A . ( ¬a ∈ s ∧ a 6∈ s iff s |= ¬a ) States s that contain a and ¬a are called inconsistent states and are not allowed. We describe below how we need to change the definitions given in the previous sections, starting by the new definition of s |= `, to obtain STRIPSOWA . Definition 2.5.0.9 Given any state s ∈ S and any ` ground literal of L, i.e. ` ∈ literals(L)[∅], we say that s logically entails `, denoted by s |= `, iff: ` ∈ s. As it was said, when dealing with the OWA it is usual to exclude the inconsistent states by construction. We do this by means of two separate measures: 1. by requiring that the initial state belongs to a subset of SST RIP SOWA trimmed of inconsistent states. To this end, we introduce the following filter function Con : 2SST RIP SOWA → 2SST RIP SOWA that eliminates these inconsistent states. The function Con is defined for every state subspace S ⊆ SST RIP SOWA by 21 : Con(S) = { s | s ∈ S ∧ ∀a ∈ +s . ¬a¬ ∈ s }. 2. by guaranteeing that the inconsistent states cannot arise as the result of an instantiated operator (see the corresponding definition below). We need a new OWA definition of the operator specification language LOST RIP SOWA . It is like the definition of LOST RIP S but for the definition of Add(~x), Del(~x) ⊆ atoms(L)[V(~x(α))] where atoms is replaced by literals, i.e. Add(~x), Del(~x) ⊆ literals(L)[V(~x(α))]. Now the effects can add or delete literals, not just atoms. 21

With +s we denote the subset of s that contains only its positive literals, see Section A.2.

MUTEX

2.6. STRIPS

: DEALING WITH SETS OF MUTEX ATOMS

41

The definition of the set of all instances of the STRIPSOWA planning problem needs to change to avoid inconsistent initial states, hence, it is defined by: IST RIP SOWA ≡ LD × Con(S) × LG . That is to say, for every x ∈ IST RIP SOWA , we have s0 (x) ∈ Con(S). The “No inconsistent effects” part of the definition of consistency of an instantiated operator αθ changes into: • •

Eff + (αθ) ∩ Eff − (αθ) = ∅ + Eff + (αθ) ∩ atoms(−Eff + (αθ)) = ∅

The first part remains the same as before, but for the OWA we need to take care of another possible source of inconsistency, when we add both a and ¬a. The definition of executability of an instantiated operator αθ in a state s ∈ SST RIP SOWA does not change because it is written in terms of s |= Pre(αθ) that was already changed above. Hence, what changes is that now s |= Pre(αθ) is no more equivalent to +Pre(αθ) ⊆ s ∧ atoms(−Pre(αθ)) ∩ s = ∅ but to Pre(αθ) ⊆ s. It is now required in fact that both positive and negative literals belong to s. The definition of the result of applying an instantiated operator αθ in a state s ∈ Con(SST RIP SOWA ) changes, the result state s0 now is 22 : s0

=

s ∪ Eff + (αθ) \ ( Eff − (αθ) ∪ Eff + (αθ) )

We add the set Eff + (αθ) to what is subtracted from s to guarantee that no inconsistent state arises. Hence, the resulting s0 in s |=αθ s0 cannot be inconsistent if s is not already inconsistent. Finally, the definition of η in its most general form does not change because it is written in terms of s |= G. It indeed changes for the more restricted case of LG consisting of conjunctive sets of literals. In this case we simply require that all the literals of G be present in s: ½ > if G ⊆ s η(G, s) ≡ ⊥ o.w.

2.6

STRIPS

MUTEX

: Dealing with sets of mutex atoms

Both, in physics and in programming, it is common to model the world as composed of many objects changing in mutual interaction. Each one of these objects is usually understood as having various internal states. At each instant of time each object is considered to be in a unique state. The most 22

The notation Eff + (αθ) means the set { ¬a | a ∈ +Eff + (αθ) } ∪ { a | ¬a ∈ −Eff + (αθ) }, see Section A.2.

42


natural way to model this is to use a set of values (e.g. a set of numbers, alphanumeric strings, etc.), such that each value identifies in a unique way a possible internal state of the object and the whole set all its internal states. In physics, the time evolution of each object is represented by a function from the set that represents the time to the set of values that represents the internal states of the object. The time is usually modeled by the set of real numbers. Frequently, the internal states of each object are considered finite, but not always. Also in computing it is common to follow that practice. For example, the computational representation most commonly used in programming is to represent the state of an object using a variable in which the value that identifies the current state is saved23 . When the object changes its state, the corresponding new value is assigned to that variable. Notably, in planning, the use of variables takes a more secondary place. The preeminent role for modeling a planning domain is taken by predicates and ground atoms, as we saw in our previous sections. For example, in STRIPS the state space is defined as any subset of ground atoms. So, it is not surprising that when modeling a planning domain, it is extremely frequent to require that some ground atoms cannot hold in the same state. This comes from the following fact. As we explained above, each object in the planning domain is modeled as being in a unique internal state at each instant. So, if we use a set of ground atoms to represent the various internal states of the object, we need to require that only one of those ground atoms holds in each state. We need this in order to avoid states in which an object is simultaneously in two internal states. Hence, for each object in the planning domain we will commonly use a set of ground atoms that are mutually exclusive. In this way we guarantee the intended semantic when modeling the internal state of each object. We call these ground atoms MUTEX, from mutually exclusive, and we call any state that contains MUTEX ground atoms as semantically inconsistent states24 . For example, suppose we have to model a domain in which there is an elevator that can stop at different levels, from 0 to 50. Suppose we use a single predicate Level(x) for modeling it stopped at level x. We need to guarantee that it cannot appear a state that simultaneously has two different ground versions of the predicate Level(x), e.g. Level(0) and Level(50). MUTEX STRIPS is an extension of STRIPS that excludes these semantically inconsistent states from the state space. We proceed in parallel with what was 23

Frequently more than one variable is used to this end. The current state of the object is represented by the tuple of their current values. 24 Notice that we are not considering a planning graph[BF97], i.e. we are not considering the MUTEX relationship that appear when expanding all the operators at each step of a planning graph. The MUTEX relationship between ground atoms we highlight here is independent of the planning time. It comes from using ground atoms for modeling the various objects in the planning domain, each of them with a unique internal state.

MUTEX

2.6. STRIPS

: DEALING WITH SETS OF MUTEX ATOMS

43

done for generating STRIPSOWA in Section 2.5: (1) we add to the specification of a domain the declaration of many sets of MUTEX ground atoms; and afterwards, (2) we guarantee that MUTEX ground atoms cannot appear in any state by means of two separate measures: (2.1) by requiring that the initial state belongs to a subset of S trimmed of all semantically inconsistent states; and (2.2) by avoiding that an inconsistent state arises as the result of the application of an instantiated operator. In the rest of this section we develop one by one these steps: (1) Specifying many sets of MUTEX ground atoms: MUTEX The language to specify sets of MUTEX ground atoms, denoted LA MUTEX A MUTEX is defined by LA ≡ 22 . So, any X ∈ LA is such that its elements are subsets of ground atoms, i.e. for any X ∈ X we have X ⊆ A. MUTEX In STRIPS we need to add to the specification of a domain the set MUTEX X ∈ LA with the specification of all the sets of MUTEX ground atoms, MUTEX formally: LDMUTEX ≡ LDSTRIPS × LA . MUTEX

Hence, given any STRIPS D, i.e. D ∈ LDMUTEX , we have that D1 contains the operators and D2 the sets of MUTEX ground atoms. We use the more mnemonic indexes O instead of 1 and X instead of 2. So, we write α ∈ DO = D1 to mean that α is an operator and X ∈ DX = D2 to mean that X is a set of MUTEX ground atoms. (2) Guaranteeing that MUTEX ground atoms cannot appear in any state. (2.1) Requiring that the initial state belongs to a subset of S trimmed of all semantically inconsistent states: We introduce the following filter function Con : 2S → 2S that eliminates these inconsistent states. The function Con is defined for every state subspace S ⊆ S by: Con(S) = { s | s ∈ S ∧ ∀X ∈ DX , ∀a ∈ s , @a0 ∈ s . a, a0 ∈ X } MUTEX So, the definition of the set of all instances of the STRIPS planning problem needs to change to avoid inconsistent initial states, hence, it is defined by: IST RIP S MUTEX ≡ LDMUTEX × Con(S) × LG . That is to say, for every x ∈ IST RIP S MUTEX , we have s0 (x) ∈ Con(S). (2.2) Avoiding that an inconsistent state arises as the result of the application of an instantiated operator: The “No inconsistent effects” part of the definition of consistency of an instantiated operator αθ changes into: • •

Eff + (αθ) ∩ Eff − (αθ) = ∅ ¯ ¯ ∀X ∈ DX . ¯Eff + (αθ) ∩ X¯ ≤ 1

44


The first part remains the same as before, but we need to exclude, for every set of MUTEX atoms in the domain, any operator that adds more than one atom of each set of MUTEX atoms. The definition of executability of an instantiated operator αθ in a state s ∈ SST RIP SOWA does not change because it is written in terms of s |= Pre(αθ) that was already changed above. The definition of the result of applying an instantiated operator αθ in a state s ∈ Con(S) changes, the result state s0 now is: s0

=

s ∪ Eff + (αθ) \ ( Eff − (αθ) ∪ Eff + (αθ) ) 

where: Eff + (αθ)

[

=

X∈DX

 [



X \ {a}



a ∈ X∪Eff + (αθ)

The set Eff + (αθ) contains, for every set of MUTEX atoms of the domain X ∈ DX and for every atom a in Eff + (αθ) that belongs to that set, all those atoms except a itself. We add the set Eff + (αθ) to what is subtracted from s to guarantee that no inconsistent state arises, thus, eliminating from s any previous atom that is MUTEX with the atoms we are adding. Hence, the resulting s0 in s |=αθ s0 cannot be inconsistent if s is not already inconsistent.

2.7

STRIPS

SAS

: Using State Variables SAS

Now we introduce STRIPS a planning framework that extend STRIPS by adding the capability of using state variables. We have named this framework SAS by STRIPS to address the fact that Bäckstr¨ om’s SAS [BK91, Bäc92] family of planning frameworks was the first extension of STRIPS based on state variables 25 . As we explain at the beginning of the previous section, if we use a set of ground atoms to represent the various internal states of an object, we need to take care that only one of those ground atoms holds in each state. Using STRIPS we need to do this by hand when defining the operators that will MUTEX model the actions in the domain. STRIPS saves us this burden. When modeling the domain, we can just declare which are the sets of MUTEX ground MUTEX atoms, and leave STRIPS to take care of the consistency. However, both MUTEX STRIPS and STRIPS still need to permanently delete all the atoms that are MUTEX with those atoms they add to a state. This observation leads us to a better strategy for dealing with the previous problem that, not only avoids 25

SAS stand for for Simplified Action Structures.

SAS

2.7. STRIPS

: USING STATE VARIABLES

45

the bundle of the manual specification of the deletion of the corresponding MUTEX MUTEX ground atoms as STRIPS does, but also avoids altogether the permanent deletion of these MUTEX ground atoms. We can use state variables instead of predicates and ground atoms. Indeed, to model the different states we just assign different values to the state variables. We exemplify this resuming the example of the previous section of an elevator that can stop at various levels, from 0 to 50. We used a single predicate Level(x) for modeling it stopped at level x, and we needed to guarantee that no state simultaneously has two different ground versions of the predicate. Now, instead of using the predicate Level(x), we can use a state variable, e.g. Level and assign values from 0 to 50 to it. The current value of Level gives us the current level of the elevator, e.g. after assigning 25 to Level, denoted Level := 25, we know that the current value of Level is 25, denoted Level = 25, the same as including the atom Level(25) in the current state and deleting from it all other ground atoms derived from Level(x). Clearly, the state variables are not variables of V, variables of the language L used to construct STRIPS. We need also to establish a domain of values for each of the state variables. As we show below, it is convenient to use the ground terms of L as the values for the state variables. The reason for this is that we want to assign these state variables inside the add list of the operators whose parameters are instantiated to ground terms of L. So, the pair of the state variable and its current value will be now used to describe the world in the same way as in STRIPS we used the ground atoms of L. We need to redefine the State Space completely. It is worth highlighting SAS that, contrary to STRIPS, the State Space of STRIPS changes depending on how many state variables we use, and on the domain of these variables. We start by partitioning the set of function symbols F into two disjoint sets SAS FSTRIPS and F . The latter function symbols are used exclusively to identify SAS the state variables, thus, we call F the set of state variables identifiers. We denote by LF SAS the subset of L made of the equality predicates, and such SAS that its left term is a functional term made with a symbol in F and its right SAS term does not contain symbols of F . We denote by LFSTRIPS the subset of SAS

L whose terms do not contain symbols of F . Hence, we have two disjoint sets of atoms: SAS ASTRIPS ≡ atoms(LFSTRIPS )[ ∅] \ {>, ⊥} and A ≡ atoms(LF SAS )[ ∅]; SAS

and its associated disjoint state subspaces: S(ASTRIPS ) and S(A ). The first one of this subspaces is used as usual, but the second one is replaced by one based on state variables. SAS Given any state variable identifier V ∈ F of arity n, we denote by V(~x) its associated function term whose terms are all variables, i.e. all (~x)i ∈ V.

46


Definition 2.7.0.10 We define the term-expansion of any state variable SAS identifier V ∈ F , denoted by E terms (V), as: © ª E terms (V) ≡ V(~x)θ | θ : V → terms(LF SAS )[∅] and the term-expansion of any subset of state variable identifiers F 0 ⊆ F denoted by E terms (F 0 ), as: E terms (F 0 ) ≡ ∪V∈F 0 E terms (V) We refer to any v ∈ E terms (F

SAS

SAS

,

) as a state variable.

E terms (V) contains all the possible forms of making the corresponding deSAS rived terms V(~x) ground. Given any state variable identifier V ∈ F , its domain, denoted by DV , is defined as any subset of ground terms, formally: DV ⊆ terms(L)[∅]. DV represents all the values that can be assigned to any state variable in E terms (V). For every state variable v ∈ E terms (V) we define Dv = DV . So, the domain of all the state variables derived from the same state variable identifier shares the same domain DV . SAS

Definition 2.7.0.11 Given any set F of state variable identifiers, each SAS of them with a specified domain, we define the associated STRIPS State Space, denoted by SST RIP S SAS , by: SST RIP S SAS ≡ S(ASTRIPS ) × S

SAS

where : S

SAS

≡

Y v∈ E terms (F

SAS

SAS

Dv SAS

) SAS

Notice that we use the cartesian product S instead of S(A ). S is the state space of the state variables and by construction guarantees us that never two MUTEX ground atoms hold. That is all that changes in the Space SAS State. Being S defined as a cartesian product of the domains of all the state SAS variables in the domain, we denote as usual by dim(S ) the dimension of the SAS cartesian product. Hence, dim(S ) = n means that we have n state variables in the domain. We now write (s, ~s) ∈ SST RIP S SAS being s ∈ S(ASTRIPS ) ⊆ SAS SAS SST RIP S and ~s ∈ S , i.e. ~s is a dim(S )-tuple. We use v as an index of the tuple, i.e. we write (~s)v to access the v component of ~s. For example, SAS suppose we have E terms (F ) = {v1 , . . . , vm } and all Dvi = R ∪ {⊥}, we have 26 . It is worth underscoring that this is that SST RIP S SAS ≡ SST RIP S × Rm ⊥ how the state space is defined in PDDL 2.1, except for the preeminent place 26

Notice that we abuse the notation using ⊥ with the following two different meanings: (1) as usual in set theory, we use the symbol ⊥ to mean that the numeric value is undefined; (2) as usual in first order logic, we use the symbol ⊥ as the symbol meaning false in the first order language L.

SAS

2.7. STRIPS


47

one particular state variable, the time, is given there 27 . There are various possible syntax for specifying the set of state variables and its domains of possible values. We exemplify below the one we use in this dissertation 28 . We write: ( :statevariables V1 (x, y) . . . Vm (x) ) meaning the following state variable identifiers: SAS F = {V1 , . . . , Vm }, with: arity(V1 ) = 2, . . . , arity(Vm ) = 1. and their associated domains are specified writing: (D)V1 = N (D)V2 = R ∪ {⊥} ... (D)Vm = {A, B, C, D} We need to explain how these new states entail the ground literals of L. SAS Given any state (s, ~s) ∈ SST RIP S SAS with a set of variables F and any ground literal ` of L, i.e. ` ∈ literals(L)[∅], we say that (s, ~s) logically entails `, denoted by (s, ~s) |= `, iff:

where:

(` = >) ∨ (` ∈ ASTRIPS ∧ ` ∈ s? ) ∨ (` = ¬a ∧ a ∈ ASTRIPS ∧ a 6∈ s? ) i S h s? = s ∪v∈E terms (F SAS ) (v = (~s)v )

Exactly the same definition as in STRIPS, but for s? taking the place of s. This guarantees that we do not need to change anything in the preconditions or the goal language. SAS What we change instead is the definition of the STRIPS Operator Specification Language, denoted by LOSAS . We only need to change the definition of the add and delete lists: • We need to restrict the add list to contain only atoms derived from LFSTRIPS or LF SAS : 27

The state space is defined in [FL03] (Definition 2) as: R⊥ × S(ASTRIPS ) × Rm ⊥ . The first R⊥ is a state variable distinct from the rest and specialized to save the current time. The elements of the subspace S(ASTRIPS ) are called logical states in [FL03]. The place of the state variables is taken by the primitive numeric expressions in [FL03], but for the fact that these are restricted in PDDL 2.1 to be only numerical, i.e. their values are restricted to be necessarily in R⊥ . 28 Notice that we use the tag :statevariables instead of :functions used in PDDL. This is SAS because in STRIPS we distinguish between the symbols of F that are used as simple functions of the first order language L and those used to build the state variables. We use :functions for the former and :statevariables for the latter. This is the way in which the SAS partition F into the two sets FSTRIPS and F is specified. It is worth highlighting that even if they are very different, because only the state variables alter the fabric of SSTRIPS SAS into S , there is no a mechanism in PDDL/PDDL 2.1’s syntax to distinguish these two symbols.

48

CHAPTER 2. THE PLANNING PROBLEM IN AI Add(~x) ⊆ atoms(LFSTRIPS )[V(~x(α))] ∪ atoms(LF SAS )[V(~x(α))]; • We need to limit the delete list to contain only atoms derived from LFSTRIPS : Del(~x) ⊆ atoms(LFSTRIPS )[V(~x(α))].

When we write an operator’s add list, we write (v := t) instead of (v = t) to help the reader notice that v is a state variable and that t is what will be assigned to it when the operator is applied. It is not necessary to change the definition of the preconditions. SAS For any instantiated operator αθ and any state variable v ∈ E terms (F ) we define: + 0 0 0 • Eff + := (αθ, v) ≡ { (v := t) | v = v ∧ (v := t) ∈ Eff (αθ) } The set of all the assignment expressions with v in the left side that appear in Eff + (αθ). + • Eff + := t (αθ, v) ≡ { t | (v := t) ∈ Eff (αθ) } The set of all the terms that appear in Eff + (αθ) as right hand side of the assignment expressions that contain the state variable v in its left hand side. SAS

The STRIPS STRIPS: LD

Domain Specification Language is defined like in L ≡ 2 OSAS \ ∅. So, we write D ∈ LD SAS SAS

ST RIP S

SAS

ST RIP S

meaning that D is a domain of STRIPS . There is no need to change the goal specification language. Finally, the set of all instances of the STRIPS Planning Problem, denoted by IST RIP S SAS , is defined by: IST RIP S SAS ≡ LD

ST RIP S

SAS

× SST RIP S SAS × LG .

The “No inconsistent effects” part of the definition of consistency of an instantiated operator αθ changes into: 1.

Eff + (αθ) ∩ Eff − (αθ) = ∅

2.

∀v ∈ E terms (F

SAS

¯ ¯ ¯ ) . ¯Eff + := (αθ, v) ≤ 1

The first part remains the same as in STRIPS, but we need to exclude any operator that assigns more than one value to a state variable. The definition of when an instantiated operator αθ is executable in a state (s, ~s) ∈ SST RIP S SAS is like in STRIPS, we require: αθ is consistent ∧ (s, ~s) |= Pre(αθ).

SAS

2.7. STRIPS


49

Definition 2.7.0.12 Given any instance x ∈ IST RIP S SAS with a set of state SAS variable identifiers F , and any of its instantiated operators αθ such that it is executable in state (s, ~s) ∈ SST RIP S SAS , we say that the application of αθ in state (s, ~s) results in state (s0 , s~0 ) ∈ SST RIP S SAS , denoted by: (s, ~s) |=αθ (s0 , s~0 ) iff:

• s0

=

s ∪ Eff + (αθ) \ Eff − (αθ);

• and for all v ∈ E terms (F SAS

For any STRIPS

SAS

) we have:

domain D ∈ LD

(s~0 )v = Eff + := t (αθ, v).

, the set of plans of a domain Plans(D) is defined exactly like in STRIPS. We say that a given plan P~ = (α1 θ1 , . . . , αm θm ) ∈ Plans(D) is executable in state (s0 , s~0 ) ∈ SST RIP S SAS iff: ∃(s1 , s~1 ), . . . , (sm , s~m ) ∈ SST RIP S SAS . ( (s0 , s~0 ) |=α1 θ1 (s1 , s~1 ) ... |=αm θm (sm , s~m ) ) ST RIP S

SAS

In this case we say that the application of P~ in state s0 results in state ~ (sm , s~m ), and denote this by: (s0 , s~0 ) |=P (sm , s~m ) Given any instance x = (D, (s0 , s~0 ), G) ∈ IST RIP S SAS , we say that any plan ~ P = (α1 θ1 , . . . , αm θm ) ∈ Plans(D) is a solution of x iff : ~

∃(sm , s~m ) ∈ S . ( (s0 , s~0 ) |=P (sm , s~m )

∧

η(G(x), sm ) = > )

Like in STRIPS we denote by SOLST RIP S SAS (x) the set of all solutions of x and write P~ ∈ SOLST RIP S SAS meaning that P~ is a solution of x. We mention two advantages of this approach based on state variables. First, we have embedded the fact that predicates are MUTEX inside the “fabric” of the state space. So, there is no need to control that no MUTEX predicate appears twice in a single state, as in the previous section, because this is guaranteed by the properties of the state space itself. Second, usually we have a smaller state space, as we show in Section 2.7.1. SAS As we have commented we have named this framework by STRIPS to address the fact that Bäckstr¨ om’s SAS [BK91, Bäc92] family of planning frameworks were the first extension of STRIPS based on state variables 29 . In the SAS family the standard SSTRIPS state space has been replaced by a state space defined as the cartesian product of the domain of the different SAS SAS state variables, i.e. like S . Indeed, if we restrict STRIPS to the case of P = ∅ (collapsing ASTRIPS = ∅) we have that its state space SST RIP S SAS is 29

The SAS frameworks include some other very interesting features that go beyond the scope of this dissertation.

50

CHAPTER 2. THE PLANNING PROBLEM IN AI SAS

SAS

transformed from S(ASTRIPS ) × S to S . The latter is like the state space defined in [Bäc92]. The only difference between the state space defined in SAS [Bäc92] and S relies on how the set of state variables is specified. In SAS it is necessary to specify a set of m state variable indices and the corresponding m domains for each one of them. Each index completely identifies the state SAS variables, they are as many as the indices, i.e. m. In STRIPS we also SAS specify the set F of any m state variable identifiers (the same if we restrict identifiers to a sequence of numbers), but these do not correspond one-to-one to the state variables. The set of state variables is defined as the elements of the term-expansion of the set of identifiers, which contains all possible ground terms made from those state variable identifiers that are functions of the logic L. So, even if we have m state variable identifiers, we can end with more state variables depending on the result of the term-expansion. For example, having just one state variable identifier, In, of arity 1 and two constants, c and c0 , we SAS have two state variables: In(c) and In(c0 ). So, if we further restrict STRIPS SAS to have, not only P = ∅, but also that all the symbols in F have arity 0, the resulting framework has the same state space as the one used for the SAS family.

2.7.1

Comparing: state variables vs. atoms

In contrast with STRIPS, which represents the state of the world using atoms, SAS the SAS [BK91, Bäc92] formalism is based on state variables 30 . The STRIPS framework we presented above embraces both approaches. This is reflected in the structure of its state space SST RIP S SAS defined as the cartesian prodSAS uct S(ASTRIPS ) × S . The first term of this product represents the atombased STRIPS-like part of the state space and the second term the state variable-based SAS-like part. Bäckstr¨ om wrote in [Bäc92] that the state variable approach “seems to be conceptually more appealing to automatic control researchers” than the atom-based STRIPS approach. We show here that it is not only more appealing but also more convenient to use exclusively state variables instead of atoms. This usually brings a significative reduction in the size of the state space every time we are modeling a domain composed by objects with many internal states. We now compare the size of the state space when using the classic STRIPS framework to model a domain with these characteristics with that resulting SAS from exclusively using state variables. For the latter we use the STRIPS 30 B¨ ackstr¨ om In [B¨ ac92] refers to “multi-valued discrete state variables” instead of just “state variables”. “Multi-valued” emphasizes the contrast between these variables, that can take many values, and the STRIPS atoms that are two-valued, i.e. they can only be true or false. “Discrete” highlights that SAS’s state variables are restricted to take a discrete number of values.

SAS

2.7. STRIPS


51

framework restricted to the case P = ∅. In this case we have S(ASTRIPS ) = ∅ and the state space is given exclusively by the state variable part. So, we compute and compare the size of the state spaces SST RIP S and SST RIP S SAS = SAS S two times. First, we exemplify this for the simple elevator domain we introduced at the beginning of this section (see page 45) and the previous one (see page 42). For the STRIPS case we have only one predicate, Level(x), which can only be grounded with any of the constants from 0 to 50 signaling the floor at which SAS the elevator stopped. For the STRIPS case restricted to the exclusive use of state variables, we have only one state variable Level such that we can assign any of the values from 0 to 50 to it. So, we have: ¯ ¯ ¯ SAS ¯ |SST RIP S | = 2|A| = 251 >> S ¯ = |DLevel | = 51 ¯ Second, we repeat the previous computation for an abstract domain that consists of m objects Oi (i = 1, . . . , m), each of them with ni internal states. For the STRIPS case, we have a unary predicate Pi (sorti x) for every object Oi such that for each of them the corresponding predicate can be grounded with any of the constants from 1 to ni ; Pi (j) means that the object Oi is in its internal state j. We denote by Ai the set {Pi (1), . . . , Pi (ni )} of ground SAS atoms that correspond to the internal states of Oi . For the STRIPS case restricted to the exclusive use of state variables, we have a state variable SOi for every object Oi and such that we can assign any of the values from 1 to ni to it; SOi = j means that the object Oi is in its internal state j. So, we have: Pm Pm ¯ ¯ m |SST RIP S | = ¯2A ¯ = 2|A| = 2|∪i=1 Ai | = 2( i=1 |Ai | ) = 2( i=1 ni ) ¯ ¯ Qm ¯ SAS ¯ ¯S ¯ = |DSO1 × . . . × DSOm | = |DSO1 | . . . |DSOm | = i=1 ni .

and

When all objects have the same number of internal states n, i.e. when ni = n for all i, we have: ¯ ¯ ¯ SAS ¯ |SST RIP S | = 2mn and ¯S ¯ = nm . If the number of internal states of the objects is significative, i.e. ni >> 2, we have: ¯ ¯ Pm ¯ SAS ¯ Qm |SST RIP S | = 2( i=1 ni ) >> ¯S ¯ = i=1 ni ¯ ¯ ¯ SAS ¯ and |SST RIP S | = 2mn >> ¯S ¯ = nm

when

52


when the number of internal states of the objects is significative, i.e. n >> 2. At the other extreme, when all the objects have only two internal states (n = 2), the size of both state spaces is of the same order: ¯ ¯ ¯ SAS ¯ |SST RIP S | = 22m & ¯S ¯ = 2m So, we conclude that it is convenient to always use state variables instead of atoms. When the objects in a domain have few internal states (n ∼ 2) both approaches result in states spaces of similar size. When these objects have many internal states (n >> 2) the state variable approach results in a much smaller state space. It is worth noticing that this reduction is not essential for the discrete case. Any state variable with a numeric domain can be encoded into STRIPS using a number of atoms to encode the various digits of a binary representation of any number we assign to the state variable. For example, we can model the previous elevator example using only six atoms A1 , . . . , A6 instead of 51. We binary encode the current level of the elevator in these six atoms. For example A6 = true, A5 = . . . = A1 = false corresponds to the binary number 100000 meaning that the elevator is in level 32, the corresponding decimal number. So, this reduction in the size of the state space comes only as a byproduct of the usual modeling practice in STRIPS. If we proceed by using atoms to binary encode state variables we cancel this advantage. But this can be done only at the expense of the modeler who need to deal with the binary encoding. Clearly, the state variables approach is more adequate than this binary encoding of atoms from an epistemological viewpoint. Finally, we want to highlight that the disadvantage of using atoms instead of state variables holds for most planning frameworks as they heavily rely on atoms to model the world like for example PDDL 2.1. To avoid this trouble we used exclusively state variables when designing pDOOML, the O-O language for modeling planning domains we present in Chapter 5.

2.8

Further enhancements of STRIPS

We have presented the basic STRIPS family of planning frameworks in Section 2.3. As we said, the various members of that family are obtained depending on how we restrict the expressiveness of the goal specification language, the cardinality of the sets of symbols, and the arity of the predicates and functions. Afterwards, in the previous three sections we presented three exMUTEX tensions of STRIPS: STRIPSsorts , STRIPSOWA and STRIPS . We now briefly sketch some other extensions of STRIPS.

2.8. FURTHER ENHANCEMENTS OF STRIPS

2.8.1

STRIPS

CEff

53

: STRIPS enhanced with conditional effects

CEff

We denote STRIPS the extension of STRIPS that includes operators with conditional effects. Conditional effects is a keyword commonly used in planning for meaning effects that change depending on the state at which the operator is executed. Extending STRIPS to include conditional effects is straightforward. Clearly it is necessary to change the syntax of the operators because we have no more one add and one delete list, but many, and such that each pair of them is applied depending on the condition being satisfied in the state at which the operator is executed. The main changes in the semantics are in the definition of when an instantiated operator is consistent, and in the result of applying it. In STRIPS the definition of when an operator is consistent is independent of the state where CEff it is executed. Instead, in STRIPS , this definition depends on the state where the operator is executed. Being the effects conditional, they actually change depending on the state where we are considering executing the operator. So, an operator can be consistent in a state, and inconsistent in another one. Clearly, the result of applying an operator changes depending on the state the operator is executed. As we said above, only the add and delete list whose associated condition is entailed by the current state operates adding and deleting the corresponding ground atoms. This is the whole purpose of CEff having STRIPS . The PKS framework we present in Part II has conditional effects. PKS is also an extension of STRIPS, hence, the reader can pick up the details of how to extend STRIPS for conditional effects from that part.

2.8.2

Expressing preconditions

As noticed in Section 2.3, we chose to express the preconditions of STRIPS operators as conjunctive sets of literals because of the great simplicity. It is not difficult to extend the preconditions to include more complex formulas. For example, introducing disjunctions of the previous conjunctive sets of literals in the preconditions changes only the definition of when an instantiated operator is consistent. We need to change the “no competing preconditions” part of the relative definition. We need to treat separately each conjunctive set of literals that appear in the terms of the disjunction, and repeat what is required in the original definition for set of literals.

2.8.3

Writing effects

The situation of add and delete lists is rather different. They are sets of ground atoms, because SSTRIPS is made of subsets of ground atoms. The whole semantics of STRIPS is based in this fact. The application of an instantiated

54


operator changes a state by the addition and subtraction of ground atoms from the original state. Hence, changing the add and delete lists is usually accompanied by changing the state space, and vice versa. This is exactly what SAS happened when we introduced STRIPS : we changed the definition of the State Space and then we needed to change the definition of the add and delete list accordingly. Anyway, there is plenty of room for extensions hidden in our definition of the add and delete lists simply as sets of atoms. There are many different forms to specify these sets of atoms. Until now we have been assuming the direct listing of them, but this is not necessary. Indeed, in Section 4.1.1 we present a language that allows us to specifiy a set of atoms in a more concise way, avoiding listing all their elements.

2.8.4

Combining extensions

It is straightforward to combine some of the previous extensions. For example: MUTEX

• STRIPSsorts denotes the version of STRIPS that combines both the MUTEX many-sorted extension STRIPSsorts and the STRIPS . MUTEX

MUTEX

• STRIPSOWA denotes the combination of STRIPSOWA and STRIPS SAS

• STRIPSsorts denotes the version of STRIPS that combines both the SAS many-sorted extension STRIPSsorts and the STRIPS extension based on the state variables. This combined version is the one we use in most examples. An interesting advantage of this combination is that the constants associated with each sort provide a domain by default for the state variables of that sort. Suppose we have a state variable identifier V of sort w, the default domain of V is 31 : DV = C(sort(V)) = C(w) So, if the sets of constants of each sort C(w) provide the desired range of values for the state variable identifier of that sort, we do not need to explicitly declare its domain DV , it is taken by default as C(sort(V)). Otherwise, we simply define DV explicitly, and this definition overwrites the default domain C(sort(V)). We now exemplify the notation we use to declare the state variables SAS in STRIPSsorts 32 . Suppose that we have the following four sorts W = 31

This is also the domain of all the state variables v derived from this identifier because we have DV = Dv (see on page 46). 32 We use the same syntax as in PDDL 2.1 but for the definition of the domain of each variable. These definitions are not present in PDDL 2.1 because the domain is limited to be real numbers or undefined, i.e. it is always R⊥ , and therefore is not specified, but intended implicitly; see [FL03].

.

2.8. FURTHER ENHANCEMENTS OF STRIPS

55

{w, somenat, nat, real}, that the constants of sort w are only two C(w) = {T 1, T 2}, that t is the only variable of sort w, that somenat ⊆ nat ⊆ real, that C(somenat) = {1, . . . , 100}, that C(nat) = N, that C(real) = R (so we have C(somenat) ⊆ C(nat) ⊆ C(real) = R), by declaring: (:statevariables (V1 (t − w) − somenat), (V2 (t − w) − nat), (V3 (t − w) − real) ) We declare six state variables: V1 (T 1), V1 (T 2), V2 (T 1), V2 (T 2), V3 (T 1) and V3 (T 2). Their associated domains are by default equal to the set of constants of the corresponding sort, i.e.: (D)V1 = {1, . . . , 100} (D)V2 = N (D)V3 = R so, if this is what is wanted, it is not necessary to declare the domains. Otherwise, it is possible to overwrite those definitions adding one or more definitions. For example, by writing (D)V2 = {1, . . . , 1000} we overwrite the domain of the state variable identifier. SAS,CEff

denotes the version of STRIPS that combines both the • STRIPSsorts SAS many-sorted extension STRIPSsorts , the STRIPS extension for state CEff variables, and STRIPS the conditionals-effects version we have mentioned just above. Clearly not all the combinations are allowed, e.g. STRIPS cannot be combined with STRIPSOWA .

2.8.5

About the semantics of PDDL 2.1 SAS

As we commented above, in Section 2.7, the STRIPS state space contains the state space of PDDL 2.1 [FL03] as a particular case. What is remarkable is that most features of the semantics of PDDL 2.1 SAS,CEff given in [FL03] can be accommodated within STRIPSsorts by introducing minor extensions and conventions 33 . From the point of view of the syntax, it should not be necessary to remark that the differences are completely superficial. We have chosen the present 33

SAS,CEff

STRIPSsorts is the extension of STRIPS that combines both STRIPSsorts , STRIPS CEff and STRIPS presented just above in the previous section.

SAS

56


syntax because it is more convenient when dealing with the theoretical features of the various planning frameworks. In general, we can transform the syntax of STRIPSSAS,CEff into that of PDDL 2.1 by adding some syntactic sugar sorts into the former. Indeed, one of the major differences is that we use, like in the original version of STRIPS, two lists to specify the effects — add and delete — instead of the convention used in PDDL of interpreting positive and negative literals of a unique effect list respectively as members of the add and delete lists. We proceeded in this way to avoid syntactical changes when passing from STRIPS to STRIPSOWA , the OWA extension presented in Section 2.5. From the point of view of the semantics, as an example, we want to comment how some features of PDDL 2.1 can be accommodated in STRIPSSAS,CEff : sorts • Time: We have already commented in Section 2.7 (page 47) that there is no inconvenient to proceed in the same way as PDDL 2.1 does for modeling time. We can as well use a state variable of sort R⊥ distinct from the rest and specialized it to save the current time34 . We can call this state variable total-time —as called in PDDL 2.1—. We need to ban all operators of modifying this state variable (we can simply do this by modifying the Operator Specification Language requiring that totaltime cannot be present in an add list). Except for that, total-time is an ordinary state variable, and so, it can be accessed in the preconditions of the operators and used to specify goals. • Time actions, durative actions and concurrent plans: We need to add some special syntax to the actions to state their duration and increase the total-time value at each step of execution. We need also to add some special syntax to state if the various conditional-effects of the actions are “at start”, “at end” or “overall” with respect to the elapsed time when each action is executed. We need to include this in the semantics (e.g. similarly to what is done in [FL03]). The plans in PDDL 2.1 are sequences of “timed actions”, meaning an ordered pair of a time tag and the current instantiated operator. So, we need to modify the syntax for writing plans accordingly. About the various concurrent interactions we refer the reader to Sections 3.3 and 3.4 where we discuss concurrency. It is not difficult to proceed in the same way using the implicit and time-tagged concurrency 35 approach of PDDL 2.1. • Plan metrics: Again we use a state variable distinct from the rest and specialized to save the current plan-metric. Then we need to add some syntax to define what is computed at each step of the plan as the plan 34

In what follow we avoid to add “of sort R⊥ ” when modeling a PDDL 2.1 state variable because, as we said, this is the unique sort allowed in PDDL 2.1 for state variables. 35 See the introduction to Chapter 3 for an explanation of these concepts.

2.9. PRESENTING THE TWO OIL TANKS DOMAIN

57

metric and assigned to that variable. Clearly, any mathematical expression of other state variables of sort R⊥ will do as in PDDL 2.1. As in the total-time case, we need to exclude the possibility of modifying the plan-metric variable in the operators. Finally, we need to add some syntax as is done in PDDL 2.1 to state if the plan-metric will be minimized or otherwise. This is only a flag for the planner. There are several more features of PDDL 2.1 we did not comment above, like discretised durative actions and continuous effects. We want to state clearly that we are not delivering here an extension of STRIPSSAS,CEff that sorts completely encloses PDDL 2.1. The point of this short section is just to underline that having both the same state space, sorts (called types in PDDL 2.1) and conditional-effects, most other features can be reproduced easily. Finally, we want to highlight the reverse side of this comparison, i.e. the features of STRIPSSAS,CEff that are not present in PDDL 2.1. sorts • The state variables of PDDL 2.1 are restricted to be only numerical, i.e. their values are restricted to be necessarily in R⊥ . Instead in STRIPSSAS,CEff they can be of any sort and their domain is explicitly sorts specified. we distinguish between the symbols of F that are • In STRIPSSAS,CEff sorts used as simple functions of the first order language L and those used to build the state variables. We use for this two tags: :statevariables for the state variables and :functions — the only one used in PDDL 2.1 — for the simple functions. It is worth highlighting that only the state SAS variables alter the fabric of SSTRIPS into S . Clearly, these features can be added to PDDL 2.1 without any problem, just by following what we did in Section 2.7.

2.9

Presenting the Two Oil Tanks domain

We now present the Two Oil Tanks (TOT) domain. This domain is used through Part I as the running example. Every time we terminate the presentation of a new feature we revisit this example to show how the new feature helps us in the modeling of the TOT domain. The TOT domain is partially depicted in Figure 2.7. It consists of five parts: two agents, two oil tanks, and the rest of the world. The two agents act concurrently. The levels of the tanks change concurrently with the agents’ actions. For the sake of simplicity we model in detail only both oil tanks and abstract the other properties of the rest of the world. Each agent has the

58


In1

Oil Tank #1 Out1

A1

Oil Tank #2

Level1 Level2

In2

Out2

{RW(1), RW(5), ...} The Rest of the World

A2

Figure 2.7: Two Oil Tanks Domain Example capability to execute in parallel actions from two sets: (a) actions that only modify the flow rate of the input/output valves of the oil tanks (and do not modify the rest of the world); (b) actions that only modify the state of the rest of the world (and do not modify the state of the tanks). In Figure 2.7, for any concurrent thread of activities that the agents can pursue, we have drawn a dotted arrow that points from the agent to the properties of the domain that the corresponding thread controls. The agents do not control the level of the tanks directly, they only control the input/output valves. It is worth noting that in this domain the level of the tank is a concurrent process that runs in parallel with everything the agents do. In modeling the TOT example we assume that every step of the plan takes the same unit of time. The level of each tank at a certain instant is the sum of the input(+)/output(-) valves flow exchange over the level at the previous state. Each input valve controls the flow exchanged between the oil provider and the oil tanks. Each output valve regulates the flow exchanged between the agent and its corresponding oil tank. The agents need to adjust the output because they need to consume different rates of oil depending on which actions of set (b) they are executing, i.e. a certain precise range of oil output flow appears as a precondition in those actions. Instead of totally abstracting the rest of the world, we use a simple representation for it. We assume that: 1. All possible states of the rest of the world can be represented by the combinations of the ground atoms derived from a single unary predicate RW(r). We use a special sort rw for it, and assume that there are neither


59

functions, nor state variables of sort rw, and that the associated set of constants is C(rw) = {1, . . . , 1000}36 . As there are no other terms of sort rw but the constants, we have that the set of ground atoms that can be derived from RW(r) is simply ARW = { RW(1), . . . , RW(1000) }. The state subspace that models the rest of the world is the associated RW state subspace S(ARW ), i.e. 2A . It contains all possible subsets of the ground atoms of ARW . The following sets are all examples of valid states of the rest of the world: ∅, {RW(10)}, {RW(5), RW(323), RW(1000)} and ARW . 2. Each agent can add only one atom RW(r) per step and it can add an atom RW(r) only when an atom RW(r − 1) is already present in the state. Simultaneously with the addition of RW(r), the agent needs to delete the atom RW(r − 1) from the state. We require this condition to limit the “power” of the agents when acting on the rest of the world. For the presence of RW(1000) it is required to add RW(0). 3. We assume that each agent can add an atom RW(r) to the state of the world only for certain values of r, and that two predicates A1Can(r) and A2Can(r) hold only when respectively agent A1 and A2 can add the atom RW(r) to the state of the rest of the world. So, if agent A1 tries to add an atom RW(r), we require that the precondition A1Can(r) holds. We require this condition to further restrict the power of action of each agent by forcing them to coordination. The idea is that only between both of them can add every atom, but none of them can taken alone. So, they need to coordinate. 4. To add any atom derived from RW(r) it is necessary to have a flow of oil that depends on r. Hence, each agent needs to adjust its associated output valve to a certain precise flow before adding the atom RW(r). For this we use an auxiliary total function A12Flow : C(rw) → C(f low) that gives, for every constant in C(rw), the required flow of oil. We require this to link the actions of the agents on the rest of the world with their tanks. In the TOT domain the goal is to accomplish some state of the RW(r) properties of the rest of the world, and simultaneously avoid the tank overflows or underflows. If any tank overflows or underflows, we mark the corresponding tank level with an undefined ⊥ tag, meaning that the level could not be computed anymore, i.e. this atom cannot be later removed by any other operator. SAS As we explained before, we use STRIPSsorts , the extension of STRIPS with state variables and sorts to simplify as much as possible the presentation of the example. We now show how to model the TOT domain using it. 36

Both the predicate RW and the sort rw stand for “Rest of the World”.

60

CHAPTER 2. THE PLANNING PROBLEM IN AI SAS

The State Space. We start by explaining how the state space of STRIPSsorts is structured for the TOT domain. This state space is determined by the set of symbols (W, C, V, P, F) that generates the first order language L. In SAS STRIPSsorts we partition the set of function symbols F into two disjoint sets SAS SAS FSTRIPS and F . The set F of state variables identifiers gives origin to the set of state variables. These variables together with the ground atoms that may be derived determine the state space as introduced in Definition 2.7.0.11 SAS as SST RIP S SAS ≡ S(ASTRIPS ) × S . We model the state of both tanks by using state variables and the state of the rest of the world by using predicates. In this way we present an example that contains both possibilities to help a better comparison between the two techniques. Hence, for modeling the TOT SAS example we have: P = 6 ∅, F 6= ∅ and FSTRIPS = ∅. Sorts, constants and variables. We use four sorts37 : tank, f low, number and rw. The former is used to identify the tanks. The sorts f low, number and rw contain different ranges of numerical integer values. We have two constants of sort tank to identify both tanks: {T 1, T 2}. The sort f low has the following set of numerical constants {0, . . . , 10}. The sort number includes the sort f low, it extends the range by adding the numerical constants until 100 and the undefined symbol ⊥. The sort rw is {1, . . . , 1000} but does not contain number, because it does not have the symbol ⊥. We use one variable t for the sort tank, two x, y for number, and two r and r0 for rw. State variables. It is more natural to think the input/output valves and the level of each tank as state variables. Otherwise, if we model them with predicates (e.g. In1(x), Out1(x), Level1(y), . . . with x and y respectively the current flow and level values), we need to take care of the fact that each ground form of each of these predicates are MUTEX 38 . Notice that contrary to what happens with RW(r), we cannot accept a state with two different ground versions of In1(x), e.g. In1(1) and In1(10), because a valve cannot simultaneously have a flow of 1 and 10. So, we use three state variables for each tank. We use In(T 1), Out(T 1) and Level(T 1) for Tank #1 and In(T 2), Out(T 2) and Level(T 2) for Tank #2. In each case the first two are of sort f low and the last one of sort number. The associated domain of all these variables is the default one, given directly by their sorts, i.e. the set of constants corresponding to each sort. So, for the In(t) and Out(t) state variables of sort flow is {0, . . . , 10} and for Level(t) of sort level is {0, . . . , 100, ⊥}. By assigning a value x of sort 37

These sorts are sets of basic sorts, not simple basic sorts, see Section 2.4. MUTEX In Section 2.6 we explained this problem in general and how STRIPS helps us to SAS take care of that fact automatically. In Section 2.7 we explained that STRIP also deals with this problem and it does this more efficiently. 38


61

number to the state variable Level(T 1), written Level(T 1) := x, we mean that the level of the Oil Tank #1 is x. Similarly, Level(T 2) := x for Tank #2. As stated above, in the TOT domain the level at a certain state is determined by the oil level and the input/output valves flows at the previous state. We exemplify this for Tank #1. If at any state (si , ~si ) ∈ SST RIP S SAS we have that Level(T 1) := 50, In(T 1) := 10 and Out(T 1) := 5, we know that in the next state (si+1 , ~si+1 ) we have Level(T 1) := 55, from 55 = 50 + 10 − 5, independently of how the operators simultaneously change the values of the valves, i.e. these new values of the valves at state i + 1 will only affect, together with the new level Level(T 1) := 55 the level of Tank #1 at the next step i + 2 39 . We use the constant ⊥ of sort number, to specify whenever the level is out of range, either because of overflow or underflow, i.e. in these cases we write Level(T 1) := ⊥. We exemplify both cases: (a) Overflow: if in a state si we have Level(T 1) := 95, In(T 1) := 10, Out(T 1) := 3 in the next state si+1 we have Level(T 1) := ⊥, from 95 + 10 − 3 = 102 > 100; (b) Underflow: if in a state si we have Level1(T 1) := 3, In(T 1) := 5, Out(T 1) := 10 in the next state si+1 we will have Level1(T 1) := ⊥, from 3 + 5 − 10 = −2 < 0. Predicates. As we said above, we model in detail only both oil tanks and abstract the rest of the world, modeling it with a single unary predicate RW of sort rw. As we use state variables to model the tanks, we need only one predicate to model the TOT domain: RW(r − rw), for the state of the rest of the world. SAS

SAS

The Lsorts language and the S state space. We gather all previous SAS specifications of the sets that are necessary to specify the language Lsorts : • Sorts: W = {tank, f low, number, rw} • Constants: C(tank) = {T 1, T 2}, C(f low) = {0, . . . , 10}, C(number) = {1, . . . , 100, ⊥} , C(rw) = {1, . . . , 1000} • Variables: V(tank) = {t}, V(number) = {x, y}, V(rw) = {r, r0 } • The set of functions FSTRIPS = ∅. • The state variables: (:statevariables (In(t − tank) − f low) (Out(t − tank) − f low) (Level(t − tank) − number) ) ~ we have: With the notation of Section 2.7 we can write this in general, for every plan P SAS ∀i=0...(kP~ k−1) (si , ~si ) ∈ S . (~si+1 )Level(T 1) := (~si )Level(T 1) + (~si )In(T 1) − (~si )Out(T 1) . 39

62

CHAPTER 2. THE PLANNING PROBLEM IN AI • The predicates: (:predicates RW(x − f low) )

Hence, we have specified above a set of three state variable identifiers: SAS F = {In, Out, Level} and we have only two constants of sort tank. So, we have specified the following SAS six state variables (we have dim(S ) = 6): SAS E terms (F ) = {In(T 1), Out(T 1), Level(T 1), In(T 2), Out(T 2), Level(T 2)} The values of the state variables for the levels are of sort number; the values of the other state variables are of sort f low. It is not necessary to overwrite the default given by their corresponding sort constants to any of these state variables, i.e. we have (D)In = (D)Out = C(f low) and (D)Level = C(number). The operators. We now show how to specify the operators. We proceed in several steps in a trial and error manner: We first propose how to write the operators, then explain what is wrong with that proposition; we then refine them, and so on. Sometimes, we group the operators considering various properties, like: which agent acts, if they execute one or two actions in parallel, etc. To avoid repetitions, we write a tag, e.g. (1.2), before each group of operators, and use it when possible, e.g. by writing (Operators 1.2) instead of repeating them. Sometimes, when convenient, we skip writing the operators altogether writing instead simply . . . to suggest their presence. Given the description of the tanks functionality, we do not need to require any precondition to the agents to move the valves of their tanks. Given the description of the rest of the world as above, for every operator that models agent A1 adding RW(r) (for r > 1) we need to require in its precondition A1Can(r), RW(r − 1), (Out(T 1) = A12Flow(r)): in addition, we need to include RW(r) in its add list, and RW(r − 1) in its delete list. Similarly, for agent A2 we have: preconditions A2Can(r), RW(r − 1) and (Out(T 2) = A12Flow(r)), its add list RW(r), and its delete list RW(r − 1). The case of r = 1 requires RW(1000) instead of RW(r − 1). So, to simplify the exposition, we encapsulate this edge behaviour by using an auxiliary function Pred(r − rw) − rw that always returns the desired value. To simplify the specification of the operators we use the usual auxiliary operators + and − for addition and subtraction, and ≤ for comparisons. We assume that the +, − and ≤ return ⊥ if any of their arguments is ⊥. Also we use the auxiliary functions (A12Flow(r − rw) − f low) and (Pred(r − rw) − rw) introduced before and the following auxiliary predicates: • A1Can(r − rw) ≡ it holds only when the agent A1 can add RW(r) to the state of the rest of the world


63

• A2Can(r − rw) ≡ similarly for A2 • RWA1Ok(r−rw) ≡ A1Can(r)∧RW(Pred(r))∧(Out(T 1) = A12Flow(r)) • RWA2Ok(r−rw) ≡ A2Can(r)∧RW(Pred(r))∧(Out(T 2) = A12Flow(r)) • LevelOk(t − tank) ≡ (Level(t) 6= ⊥) ∧ (0 ≤ Level(t) + In(t) − Out(t))∧ (Level(t) + In(t) − Out(t) ≤ 100) • LevelsOk ≡ LevelOk(T 1) ∧ LevelOk(T 2) • UpdateLevel(t − tank) ≡ (Level(t) := Level(t) + In(t) − Out(t)) RWA1Ok(r) holds when all the preconditions necessary to allow agent A1 to add RW(r) to the state of the rest of the world hold. Similarly, RWA2Ok(r) for A2. LevelOk(t) holds only when it is possible to update the level Level(t) without underflow or overflow. LevelsOk holds when that is possible for both tanks. UpdateLevel(t) assigns the new value to the level. Also, we use the following macro; when placed inside an add list, it means that we update the levels of both tanks: • UpdateLevels ≡ UpdateLevel(T 1), UpdateLevel(T 2) Step (1): Just what the agents do. Suppose we write the following four operators: (CtrlIn(t − tank, x − f low) : {} ⇒ {In(t) := x} {}) (CtrlOut(t − tank, x − f low) : {} ⇒ {Out(t) := x} {}) (CtrlRWA1(r − rw) : {RWA1Ok(r)} ⇒ {RW(r)} {RW(Pred(r))}) (CtrlRWA2(r − rw) : {RWA2Ok(r)} ⇒ {RW(r)} {RW(Pred(r))})

A1 can control the input and output valves using the operators CtrlIn(T 1, x) and CtrlOut(T 1, x), and the rest of the world using CtrlRWA1(r). The preconditions of this last operator take care of what was requested for the rest of the world, i.e. CtrlRWA1(r) can be executable in a state s only when RW(Pred(r)) holds in s, A1 can add RW(r), and the flow of the output valve of Tank #1 is A12Flow(x). Similarly, A2 can control the input and output valves using CtrlIn(T 2, x) and CtrlOut(T 2, x), and the rest of the world using CtrlRWA2(r). It is worth underscoring that these operators model exactly the individual actions of both agents in the TOT domain, as it was described above. So, according to “common sense”, nothing more should be associated with them. But, as we explain now, this is not at all the case. First of all, because if the operators are defined as above, none of them takes care of updating the level of the tanks.

64


Step (2): Taking care of the tanks. So, we discard the previous operators and rewrite below a new specification for them such that both agents take care of computing the level of both tanks. We add into the add list of all previous operators an assignment that updates the level of the corresponding tank and the precondition LevelOK(t). Hence, using auxiliary predicates introduced just above the operators are: //(2.1) Modular operators: an agent (either A1 or A2) executes only one action + levels update: (CtrlIn(t − tank, x − f low) : {LevelsOk} ⇒ {(In(t) := x), UpdateLevels} {}) (CtrlOut(t − tank, x − f low) : {LevelsOk} ⇒ {(Out(t) := x), UpdateLevels} {}) //(2.2) Agent A1 executes one action + levels update: (CtrlRWA1(r − rw) : {RWA1Ok(r), LevelsOk} ⇒ {RW(r), UpdateLevels} {RW(Pred(r))}) //(2.3) Agent A2 executes one action + levels update: (CtrlRWA2(r − rw) : {RWA2Ok(r), LevelsOk} ⇒ {RW(r), UpdateLevels} {RW(Pred(r))})

The first problem with the previous operators is that there is no operator that updates the tanks levels when the agents do nothing. This is easy to correct by adding the following operator to the previous list: //(2.0) Neither agent executes an action, only the levels are updated: (Level12Evol() : {LevelsOk} ⇒ {UpdateLevels} {}) We recall that it is an important characteristic of the domain that each agent can pursue several activities in parallel. For example, agent A1 can execute in parallel the following pair of operators CtrlIn(t, x) and CtrlRWA1(r) or this other pair CtrlOut(t, x) and CtrlRWA1(r), (instead, it cannot execute in parallel CtrlIn(t, x) and CtrlOut(t, x)). According to the definition of the operators, only one of the actions can be executed in each step. Hence, we need to model the TOT domain differently, to add this lost concurrent behaviour. Step (3): The explosion begins. Inside the STRIPS framework, the only way to resolve this problem is by using a new set of operators that groups any pair that can be possibly executed concurrently. We need to keep the four previous operators, because concurrency is optional, and hence, the previous operators will model the case when there is no concurrency. //(3.0) Neither agent executes an action, only the levels are updated:


65

(Operators 2.0) //(3.1) Modular operators: an agent (either A1 or A2) executes only one action + levels update: (Operators 2.1) //(3.2) Agent A1 executes only one action + levels update: (Operators 2.2) //(3.3) Agent A2 executes only one action + levels update: (Operators 2.3) //(3.4) Agent A1 executes two actions concurrently + levels update: (CtrlInRWA1(x − f low, r − rw) : {RWA1Ok(r), LevelsOk} ⇒ {(RW(r)(In(T 1) := x), UpdateLevels} {RW(Pred(r))}) (CtrlOutRWA1(x − f low, r − rw) : {RWA1Ok(r), LevelsOk} ⇒ {(RW(r)(Out(T 1) := x), UpdateLevels} {RW(Pred(r))}) //(3.5) Agent A2 executes two actions concurrently + levels update: (CtrlInRWA2(x − f low, r − rw) : {RWA2Ok(r), LevelsOk} ⇒ {(RW(r)(In(T 2) := x), UpdateLevels} {RW(Pred(r))}) (CtrlOutRWA2(x − f low, r − rw) : {RWA2Ok(r), LevelsOk} ⇒ {(RW(r)(Out(T 2) := x), UpdateLevels} {RW(Pred(r))})

Step (4): The explosion continues. Sadly, the previous set of operators is not enough because it does not capture still another concurrent activity: the agents A1 and A2 can choose to act in parallel. The operators we just defined consider only each agent acting alone. We can apply the same technique and add a new set of operators grouping the actions that can be simultaneously made by both agents. The new set of operators is: //(4.1) Modular operators: an agent (either A1 or A2) executes only one action + levels update: (Operators 3.1) //(4.2) Agent A1 executes only one action + levels update: (Operators 3.2) //(4.3) Agent A2 executes only one action + levels update: (Operators 3.3) //(4.4) Agent A1 executes two actions concurrently + levels update: (Operators 3.4) //(4.5) Agent A2 executes two actions concurrently + levels update: (Operators 3.4)

66


//(4.6) Agent A1 and A2 both executes only one action + levels update: (CtrlInA1InA2(x − f low, y − f low) : {LevelsOk} ⇒ {(In(T 1) := x), (In(T 2) := y), UpdateLevels} {}) (CtrlOutA1InA2(x − f low, y − f low) : {LevelsOk} ⇒ {(Out(T 1) := x), (In(T 2) := y), UpdateLevels} {}) (CtrlInA1OutA2(x − f low, y − f low) : {LevelsOk} ⇒ {(In(T 1) := x), (Out(T 2) := y), UpdateLevels} {}) (CtrlOutA1OutA2(x − f low, y − f low) : {LevelsOk} ⇒ {(Out(T 1) := x), (Out(T 2) := y), UpdateLevels} {}) (CtrlRWA1InA2(r − rw, x − f low) : {RWA1Ok(r), LevelsOk} ⇒ {RW(r), (In(T 2) := x), UpdateLevels} {RW(Pred(r))}) (CtrlRWA1OutA2(r − rw, x − f low) : {RWA1Ok(r), LevelsOk} ⇒ {RW(r), (Out(T 2) := y), UpdateLevels} {RW(Pred(r))}) (CtrlInA1RWA2(x − f low, r − rw) : {RWA2Ok(r), LevelsOk} ⇒ {RW(r), (In(T 1) := x), UpdateLevels} {RW(Pred(r))}) (CtrlOutA1RWA2(x − f low, r − rw) : {RWA2Ok(r), LevelsOk} ⇒ {RW(r), (Out(T 1) := x), UpdateLevels} {RW(Pred(r))}) (CtrlRWA1RWA2(r − rw, r0 − rw) : {RWA1Ok(r), RWA2Ok(r), LevelsOk} ⇒ {RW(r), RW(r0 ), UpdateLevels} {RW(Pred(r)), RW(Pred(r0 ))}) //(4.7) Agent A1 executes two actions concurrently and A2 only one action + levels update: (CtrlInRWA1InA2(x − f low, r − rw, y − f low) : {RWA1Ok(r), LevelsOk} ⇒ {(In(T 1) := x), RW(r), (In(T 2) := y), UpdateLevels} {RW(Pred(r))}) (CtrlOutRWA1InA2(x − f low, r − rw, y − f low) : {RWA1Ok(r), LevelsOk} ⇒ {(Out(T 1) := x), RW(r), (Out(T 2) := y), UpdateLevels} {RW(Pred(r))}) ... //(4.8) Agent A2 executes two actions concurrently and A1 only one action + levels update: (CtrlInA1InRWA2(x − f low, y − f low, r − rw) : {RWA2Ok(r), LevelsOk} ⇒ {(In(T 1) := x), (In(T 2) := y), RW(r), UpdateLevels} {RW(Pred(r))}) (CtrlOutA1InRWA2(x − f low, y − f low, r − rw) : {RWA2Ok(r), LevelsOk} ⇒ {(Out(T 1) := x), (In(T 2) := y), RW(r), UpdateLevels} {RW(Pred(r))}) ...


67

//(4.9) Both agents execute two actions concurrently + levels update: (CtrlInRWA1InRWA2(x − f low, r − rw, y − f low, r0 − rw) : {RWA1Ok(r), RWA2Ok(r0 ), LevelsOk} ⇒ {RW(r), (In(T 1) := y), RW(r0 ), (In(T 2) := y), UpdateLevels} {RW(Pred(r)), RW(Pred(r0 ))}) (CtrlOutRWA1InRWA2(x − f low, r − rw, y − f low, r0 − rw) : {RWA1Ok(r), RWA2Ok(r0 ), LevelsOk} ⇒ {RW(r), (Out(T 1) := y), RW(r0 ), (In(T 2) := y), UpdateLevels} {RW(Pred(r)), RW(Pred(r0 ))}) ...

Step (5): The overflow/underflow case. Sadly, the previous set of operators it is still not enough. Notice that no operator deals with the overflow and underflow case. To treat this case we need to add three additional operators for each one of the operators of the previous Step (4), thus, multiplying by three the total number of operators. We show how to do this taking as an example the first of the operators in (4.1) named (CtrlIn(t − tank, x − f low), defined above as: (CtrlIn(t − tank, x − f low) : {LevelsOk} ⇒ {(In(t) := x), UpdateLevels} {}) We need to add the following three additional operators: (CtrlInError1(t − tank, x − f low) : {¬LevelOk(T 1), LevelOk(T 2)} ⇒ {(In(t) := x), (Level(T 1) := ⊥)} {}) (CtrlInError2(t − tank, x − f low) : {LevelOk(T 1), ¬LevelOk(T 2)} ⇒ {(In(t) := x), (Level(T 2) := ⊥)} {}) (CtrlInError12(t − tank, x − f low) : {¬LevelOk(T 1), ¬LevelOk(T 2)} ⇒ {(In(t) := x), (Level(T 1) := ⊥), (Level(T 2) := ⊥)} {})

and then do this for every operator defined in the previous step 40 . We left this to the end because this is not only related to the concurrent properties of the domain, but it is also a byproduct of the fact that we have no conditional-effects operators. Otherwise, we can include the overflow/underflow treatment inside the same operators above without adding new 40

LevelOk(t) is defined in page 62 as a shortcut of a conjunction. So, we are abusing the notation when writing ¬LevelOk(t) in the operators above because the negation of a conjunction represents a disjunction and disjunctions are not allowed as preconditions. This can simply be avoided by redefining these operators by writing one operator for each term in the disjunctions. We proceed in this way here and in the following chapters to simplify the exposition.

68


ones. So, we do not consider this multiplication by three as an essential part of the explosion inherent to concurrency we described above. Discussion. First of all, we want to highlight that using state variables and sorts simplify the specification a lot. In any case, it should be clear at this point that STRIPS, even with extensions, is not too apt for modeling concurrent domains. The explosion of operators we have shown is a direct product of the fact that many things in the domain might change concurrently. From our point of view, one of the major drawbacks of this approach is that it is completely not modular. First of all, because any change we add to the domain (for example, another agent with its own tank) triggers the modification of all the previous specified operators. We cannot just add some new operators with the new features, we need to rewrite most of the previous operators. In addition, it is almost impossible to use the usual divide and conquer strategy for modeling. Notice that, even in this very simple domain, we cannot divide the modeling work. We cannot set two knowledge engineers to work separately with each pair of agent and tank, because the operators are completely interdependent. It is worth highlighting that even if the two tanks in the domain are completely uncoupled, there is no way to represent this properly within STRIPS and all the concurrency needs to get mixed inside each operator. Interleaving: A different approach. We now show how to model this problem using interleaving. With this trick we can avoid some of the problems, but not the most important of all. Indeed, as we show below, the lack of modularity remains. We first explain the idea of interleaving. Suppose we want to model the concurrent execution of the operator CtrlIn(t, x) described in Step (1) and the simultaneous update of both tanks’ levels. Instead of building an operator that mixes both preconditions and effects, like we did in Step (2), we can interleave both executions. First, we execute CtrlIn(t, x), and afterwards, we update both tank levels. We need to change the time unit and make two steps equivalent to a unit. Also, we need to force this interleaving, because otherwise a third action can be executed in the middle, ruining everything. We use a predicate T oggle to force this, by requiring the preconditions of CtrlIn(t, x), that when applied deletes it, and by requiring it to be false in the preconditions of the operator that will only update the tanks levels and add T oggle. This results in the following two operators: (CtrlIn(t − tank, x − f low) : {T oggle} ⇒ {(In(t) := x)} {T oggle}) (Level12Evol() : {¬T oggle, LevelsOk} ⇒ {T oggle, UpdateLevels} {})


69

The TOT domain has many other possible concurrent actions, not only these two. To incorporate them following this interleave pattern we need to use a longer interleave step that covers all possible concurrent activities. In the TOT domain we can have at maximum six concurrent activities. This occurs when each one of the two agents execute two concurrent activities plus the updating of both tanks. Hence, we need an interleave step of six and we will use a state variable Interleave instead of a single predicate T oggle to switch between them. The steps will depend on the value of Interleave as follows: 1 for A1 controlling its valves, 2 for A1 controlling RW(r), 3 for A2 controlling its valves, 4 for A2 controlling RW(r), 5 for updating Tank #1 and 6 for updating Tank #2. Clearly, we need to change the time unit such that six plan steps correspond to one time unit. The operators are: //(I.1) Modeling TOT with interleaving, main operators: (CtrlInA1(x − f low) : {(Interleave = 1)} ⇒ {(Interleave = 2), In(T 1) := x} {}) (CtrlOutA1(x − f low) : {(Interleave = 1)} ⇒ {(Interleave = 2), Out(T 1) := x} {}) (CtrlRWA1(r − rw) : {(Interleave = 2), RWA1Ok(r)} ⇒ {(Interleave = 3), RW(r)} {RW(Pred(r))}) (CtrlInA2(x − f low) : {(Interleave = 3)} ⇒ {(Interleave = 4), In(T 2) := x} {}) (CtrlOutA2(x − f low) : {(Interleave = 3)} ⇒ {(Interleave = 4), Out(T 2) := x} {}) (CtrlRWA2(r − rw) : {(Interleave = 4), RWA2Ok(r)} ⇒ {(Interleave = 5), RW(r)} {RW(Pred(r))}) (Level1Evol() : {(Interleave = 5), LevelOk(T 1)} ⇒ {(Interleave = 6), UpdateLevel(T 1)} {}) (Level2Evol() : {(Interleave = 6), LevelOk(T 2)} ⇒ {(Interleave = 1), UpdateLevel(T 2)} {})

There is still a problem with the previous set of operators. They force the agents to act, to modify the valve states and the rest of the world, in any turn. To solve this last problem, we need to add the following noop operators for every activity that is optional, i.e. all but the tanks level updates. Clearly, the noop operators do nothing, but need to update the Interleave state variable (and require it in their preconditions). //(I.2) Modeling TOT with interleaving, noop operators: (CtrlValvesA1noop() : {(Interleave = 1)} ⇒ {(Interleave = 2)} {}) (CtrlRWA1noop() : {(Interleave = 2)} ⇒ {(Interleave = 3)} {}) (CtrlValvesA2noop() : {(Interleave = 3)} ⇒ {(Interleave = 4)} {}) (CtrlRWA2noop() : {(Interleave = 4)} ⇒ {(Interleave = 5)} {})

Still, the overflow/underflow case remains to be treated. Thanks to the interleaving, we can just add more operators that treat this case in the corresponding interleaving step, they are optional for the operators Level1Evol() and Level2Evol() from (I.1):

70


//(I.3) Modeling TOT with interleaving, the overflow/underflow operators: (Level1EvolError() : {(Interleave = 5), ¬LevelOk(T 1)} ⇒ {(Interleave = 6), (Level(T 1) := ⊥)} {}) (Level2EvolError() : {(Interleave = 6), ¬LevelOk(T 2)} ⇒ {(Interleave = 1), (Level(T 2) := ⊥)} {})

This trick widens our possibilities of modeling concurrency, but the fact that it is necessary to keep track of the interleaving by means of some mechanism (as the Interleave state variable above) entangles all the operators again, making the approach not modular.

2.10

Summary

In this chapter we introduced the planning problem in AI, simultaneously introduced most of the basic terminology, and proposed a general pattern to use when describing a planning framework. We briefly described the Situation Calculus [McC68]; we presented STRIPS [FN71] simultaneously introducing the notation and the pattern we follow each time we present a planning framework. Afterwards, we presented several extensions to STRIPS. We presented each extension isolated from the others and explained at the end how to combine them. We introduced STRIPSsorts , a many-sorted (and set of sorts) version, because it is useful for the examples. We introduced STRIPSOWA , an Open World Assumption (OWA) version, because PKS, the framework we present in Part II, works with the OWA, unlike STRIPS which is based on the CWA. We MUTEX introduced STRIPS , an extension that deals with set of MUTEX atoms, because it is an intermediate step between STRIPS and the use of state variSAS ables like in STRIPS . We consider it important because the original version of PKS, together with many other features, has a mechanism to deal with sets MUTEX SAS of MUTEX atoms like the one of STRIPS . We introduced STRIPS , a version that uses state variables, because state variables are indispensable if we want to deal with real problems. In fact, they are the best way to treat SAS,CEff MUTEX predicates, and because the combined extension STRIPSsorts encloses the core features of the semantic of PDDL 2.1 (both has the same state space, sorts and conditional-effects). Finally, we presented the Two Tanks Oil (TOT) domain. It allowed us to show how the current techniques for modeling planning domains are stressed when dealing with highly concurrent domains. This will help us to highlight the differences with our approach to deal with this kind of domains. We present it in Part I of this dissertation, where we use the TOT domain as the running example.

Part I

An object-oriented language for planning domains

71

Chapter 3

Explicit Concurrent Planning (ECP) 3.1

Introducing ECP

Modeling the intrinsic concurrency of many real world domains is a challenging goal only partially explored in planning. A comment from [BB01] well explains the lack of research in this direction: “despite the interest in multiagent applications (...) and the large body of work on distributed multi-agent planning, very little research addresses this basic problem of planning in the context of concurrent interacting actions.” Concurrency has been approached in various ways that we now briefly survey. We broadly classify the various approaches in four groups depending on how the planning frameworks confront what we consider the main issue, i.e. how concurrency is represented in a plan. First, we introduce the planning frameworks with passive concurrency. Afterwards, we introduce those with active concurrency divided in three groups: those that treat the concurrency as time-tagging of the actions, those that treat it as implicit in the potential parallelism of a partial order plan, and those that do it by representing the parallelism explicitly as concurrent threads. Passive concurrency. On-going actions can be modeled by using a “continuous tense predicate” (e.g. Flying(A)) that marks the action as on-going. When this “continuous tense predicate” holds, the action is on-going. Clearly, we also need at least two operators: one that makes the “continuous tense predicate” true for starting the on-going action and another one that makes it false to terminate the on-going action. When more than one of these “continuous tense predicates” predicate holds, we simply have more than one on-going actions. Hence, this is an extremely simple way of representing the concur73

74

CHAPTER 3. EXPLICIT CONCURRENT PLANNING (ECP)

rency of actions that has the great advantage of not requiring any change to the planning framework. This approach has been followed in different planning frameworks, see [Rei00] for the Situation Calculus (replacing in previous sentences ‘predicate’ with ‘fluent’) and [BA01, Bac03] for PDDL. The major drawback of this approach is that the many “continuous tense predicates” that represent the concurrency of on-going actions are passive and cannot really act by themselves, hence, they are not actions in the usual AI planning sense, e.g. as the instantiated operators in STRIPS. They are passive in the sense in which predicates are passive. It is only the standard list of actions that is active and changes the state of the world. Hence, concurrency is usually done by interleaving the actions in this approach1 , and it is in many cases impossible to start two actions simultaneously. We refer to this form of representation of concurrency as passive concurrency. Also important is that, as noted in [Bac03], this approach is not modular. ConGolog [DLL00], is a concurrent logic programming language based on the Situation Calculus that represents concurrency explicitly. Sadly, ConGolog programs cannot be synthesized because they are macros and do not belong to first order logic. It is only possible to synthesize the plans normally represented in the Situation Calculus. When actually dealing with planning, ConGolog programs work just as constraints imposed on the various steps of the plan under synthesis. Only the plans that comply with the ConGolog program requirements will be considered valid solutions. So, ConGolog programs guide the problem solving engine helping it to prune undesirable plans. It is worth noticing that this is exactly how extended goal languages are commonly used in planning. They constrain the intermediate steps of the solutions, hence, pruning undesirable plans. However, as we said, the resulting synthesized plans are not generic ConGolog programs, but only those synthesized within the Situation Calculus. We cannot plan for ConGolog programs that explicitly represent concurrency of actions. Hence, the observations made in the previous paragraph hold for the ConGolog approach. Concurrency as time-tagging. A common problem to most approaches that rely on interleaving for modeling concurrency is that they usually cannot express the case of two actions starting synchronously at the same instant, as we commented above about some passive concurrency approaches. The usual path inside those frameworks to resolve this problem is to add time. We briefly exemplify this with the Situation Calculus (see [Rei00] for more). We add a last argument of sort real number to each action, e.g. a(~x, t). It is clear that a situation like Result([a1 (c~1 , 0), a2 (c~2 , 10), a3 (c~3 , 10)], S0 ))) models a plan in which the first action a1 (c~1 , 0) takes place at time 0, and both actions 1

We explained in Section 2.9 how concurrency can be represented by interleaving actions.

3.1. INTRODUCING ECP

75

a2 (c~2 , 10) and a3 (c~3 , 10) are synchronous actions that take place at time 10. Implicit representation of concurrency. Most of the planning frameworks deal with concurrency implicitly as a side effect of the planning phase. Quoting Bäckström, several approaches follow the intuitive idea that “a nonlinear plan is a parallel plan if any unordered action can be executed in parallel without interfering with each other”[Bäc92]. In the previous phrase “nonlinear” means a partial order plan. Partial order planning was introduced by Sacerdoti [Sac75]. Among the planning frameworks with an implicit representation of concurrency some have been formalized, e.g., ADL [Ped86, Ped87], the SAS family [BK91, Bäc92], HTN [Ero95] and recently PDDL 2.1 [FL03]. Even if these frameworks explore very different strategies for planning, all of them represent concurrency implicitly, like in partial order planning. The same is valid for several works oriented to produce practical architectures (see [GK91, MB02], to name a few). Also COLLAGE [Lan98] is an interesting non-traditional action-based planner which follows a similar approach. It is a CSP-Based Planner that divides the problem into regions and uses local search techniques to exploit the structure given by the regions to improve the search costs. Its plans consist of partially ordered actions, i.e. it does not represent concurrency explicitly. This implicit approach has various limitations such as the difficulty to express quantitative synchronization constraints between actions. For a more complete discussion of these limitations see for example: [Bre01, Bre03, FGJ03, McC03]. The commonly given formal definition of a partial order plan is as ordered pairs: the first element is a set of actions, and the second one is a partial order over these actions. The exact definition of these actions changes depending on the particular framework (e.g. in those based on STRIPS actions are any subset of instantiated operators). Most frameworks for partial order planning state that they treat concurrency (in this implicit form). Nevertheless, most times, the semantics for this implicit concurrency are not developed in detail; a recent exception is [FL03] for PDDL 2.1. Most frequently the semantics reach only the point of understanding a partial order plan simply as a notation for describing a set of plans: all the linear plans that can be made from the same actions of the partial order plan and that respect the partial order (see [RN03]). Notably, this interpretation does not leave much room for concurrency other than by treating it through interleaving the concurrent actions as explained above. In fact, a partial order plan is stated only as a notation for many linear plans. The path commonly followed is to add the time, much in the same way as the concurrency by time-tagging procedure explained above. When following this implicit representation of concurrency it is common to understand that only “When time is introduced into the modeling of a domain it is possible for concurrent activity to occur in a plan” [FL03],

76


meaning that we can represent concurrency, particularly synchronous actions, only when time is incorporated. Interestingly, the semantics for PDDL 2.1 follows this path: “It is possible for multiple actions to be given the same time stamp, indicating that they should be executed concurrently” [FL03]. Explicit representation of concurrency. A number of sparse approaches goes beyond the previous assumptions and proposes some kind of explicit representation of concurrency. We call Explicit Concurrent Planning (ECP) any planning framework whose plans represent the concurrent activities in a domain by explicitly listing the various concurrent threads of actions. We refer with a concurrent thread to any list of temporarily subsequent actions. The actions in each concurrent thread are chosen from a set of actions that uniquely characterize the thread. Notice that, this definition of ECP excludes any temporal overlapping of the actions inside each thread. So, it excludes any possible concurrency between the actions of a single thread. In ECP concurrency might occurs only between actions in different threads. It is worth highlighting that concurrency is achieved independently of which is the chosen representation of time. This contrasts with most of the strategies analyzed before that relay on time-tagging to state concurrency. An example of ECP is BTPL [Bre01, Bre03], an approach that includes some level of explicit representation of concurrency (and time) based on the concept of events. As we commented on page 2, we use CSP-Based Planning to denote various similar planning frameworks based on the Constraint Satisfaction Problem [MSCD92, Mus94, GL94, CO96, RKC+ 99, JMM+ 00, FJ03, CFO04]. All these frameworks are ECP because of their treatment of concurrency. All of them are efforts oriented to solve practical real-life problems, and therefore, they have various additional features. An important inspiration for all these approaches derives from research on CSP scheduling, e.g. [BPN01, CS94], in which the world is modeled as a set of concurrent resources that should accommodate a set of activities satisfying heterogeneous constraints of various complexity. In a modeling perspective, resources are seen here as concurrent threads that change in parallel on a timeline and may have synchronization points when specific activities are using them (for example when an activity requires two heterogeneous resources to be executed). We are interested in studying the use of concurrent threads for planning actions, similarly to the use of resources in CSP scheduling. HSTS [Mus94], the planner used in the Remote Agent Experiment [MPPW98], extends concepts from scheduling to represent planning causal knowledge. In that planner the concurrent threads are called state variables and are state transition systems that change in parallel and represent complex behavior of physical systems. Synchronization points are then introduced to model causal constraints among domain

3.1. INTRODUCING ECP

77

components. Unfortunately the formal semantics of HSTS has not been yet completely described (see [FJ03] for recent attempts). In ECP, actions are usually represented as instantiated operators, but not in all cases. For example, in most CSP-Based Planning frameworks the actions are represented with the various values that some state variables can take. Each one of these state variables represents a concurrent thread of actions. The other state variables represent the state of the world. The state space is SAS SAS a cartesian product like the state space S in STRIPS (see Section 2.7). Similar modeling ideas are used in some formal approaches to verification. Some approaches closely related to this kind of modeling are used in the analysis of concurrent programs as Concurrent Transition Systems (see [HKV02]). The application of these modeling approaches of concurrency to planning has not been presented so far. Another approach that represents concurrency explicitly is presented by Boutilier and Brafman in [BB01]. Our work is similar to this one, hence a further remark is worth doing with respect to the differences between the present chapter and [BB01]. In [BB01] each operator by convention has as its first argument a free variable denoting the acting agent (e.g. suppose that a is a variable of sort agent, any operator is written like α(a, ~x)), thus, assuming that each agent can perform only one action at a time, so any concurrent action must be performed by distinct agents. With CSTRIPS we take the representation of concurrent actions one step higher in abstraction and define a domain directly as a set of concurrent threads, each represented by a set of operators. The application of instantiated operators of the various threads models the concurrent activity in the domain. We can have as many concurrent actions as threads because only one operator per thread can be applied in parallel. Each one of these concurrent threads models a thread of activities that occur concurrently with those of the others threads of the domain. Hence, operators do not need to have the agent as first argument anymore and an agent can be easily modeled as having more than one concurrent thread, as shown in our examples. Clearly, by taking this step we have left the STRIPS framework. Therefore, it was necessary to deliver a formal semantics for our new framework. CSTRIPS also overcomes a pending issue noticed in [BB01]: To determine the precise effect of concurrently executed actions that negate some precondition of another concurrent action. This is done by formally defining when concurrent actions (instantiated operators) are consistent and by introducing this as a condition for an operator to be executable. Furthermore, we are not presenting only CSTRIPS, but many other extensions, SAS like CSTRIPS based on state variables, CSTRIPSsorts a many-sorted verSAS,CEff sion, and of particular interest, CSTRIPSsorts a version that combines both previous ones with conditional-effects.

78


Our goal. We are interested in developing a formal ECP framework for planning with concurrent threads. We provide the knowledge engineer with the capabilities of modeling a domain by explicitly associating different actions with different threads of change. As we commented in the Introduction, we present these ideas by extending STRIPS. We considered better to highlight the main characteristics of ECP by presenting these ideas on top of the most common planning framework. The simplicity of STRIPS helps underline what is new. If we would have proceeded otherwise using a less common planning framework, the reader should have to distinguish which of the features presented are those that characterizes ECP from those of the underlying framework. So, we chose to present ECP in the purest possible form, and chose STRIPS [FN71, Lif86] as the best candidate. We first built CSTRIPS, a simple and deterministic ECP version of STRIPS. CSTRIPS differs from STRIPS only in one characteristic: It represents the concurrency of actions explicitly in the form of threads that change in parallel, and such that it is necessary to plan for all of them explicitly. The main contribution of this chapter is to formally introduce CSTRIPS (from Concurrent STRIPS), a simple and basic extension of STRIPS which allows us to describe planning domains as collections of concurrent threads, and to later enhance it by describing many other powerful extensions of it, including a many-sorted version and a version based on state variables. CSTRIPS is also intended as a theoretical intermediate framework that helps us to link the novel ECP CSP-Based Planning approaches with most current planning frameworks that are not ECP (e.g. PDDL 2.1). CSTRIPS is an ECP framework which explicitly models the concurrent characteristics of a domain as concurrent threads in simultaneous parallel change. Each concurrent thread is modeled as a set of STRIPS-like operators exclusively associated with it. CSTRIPS is more adequate than STRIPS from an epistemological viewpoint [MH69], we can say that CSTRIPS appeals as “more expressive” to humans than STRIPS, in the sense that it allows us to explicitly express the concurrent properties of a domain2 . In fact, CSTRIPS gives the knowledge engineer effective features for partitioning the model development, thus allowing for the exploitation of the concurrent properties of a domain. But, how is this improvement reflected in the computational complexity? This chapter answers the following two important questions: (a) does CSTRIPS perform more poorly than STRIPS? We show that it is possible to encode any CSTRIPS planning problem into STRIPS and that, in the worst case, its reasoning has the same complexity as STRIPS on the expanded instances 3 ; (b) are there cases in which the explicit representation of concurrency 2

In Section 3.6.2 we show that CSTRIPS can be encoded in STRIPS. So, in a strictly computational sense, CSTRIPS is not more expressive than STRIPS. 3 This contrasts with what happens in HTN Planning. HTN is another extension of

3.2. CSTRIPS

79

yields a computational advantage? We show that in certain domains, those in which there are permanently many parallel actions in execution, it is possible to speed up the reasoning by representing the domain as concurrent threads. After introducing CSTRIPS, we explain how to deliver many extensions of SAS it, e.g. CSTRIPSsorts a many-sorted version, and CSTRIPS a version based on state variables. We do this with great simplicity, thanks to the modular approach we used to deliver many extensions of STRIPS in Chapter 2. SAS Afterwards, we revisit the TOT example, using the CSTRIPSsorts version that combines both previously mentioned ones, to show how simple and natural it can be modeled using CSTRIPS. We also explore a more coupled variant, the Shared Oil Tank example (SOT). In a final section we analyze some aspects of the CSTRIPS framework: its relation with its ancestor STRIPS, planning algorithms and complexity issues. Finally, it is worth highlighting that the CSTRIPS family has been designed, as the examples TOT and SOT testified, with the Multi-Agent Planning in mind, from the very beginning. Our approach, even if exemplified here as an extension of STRIPS, can be straightforwardly applied to many other current planning frameworks, e.g. to deliver an ECP framework build from PDDL 2.1 [FL03] by applying the same method we use to deliver CSTRIPS from STRIPS, see Section 3.4 page 92. CSTRIPS and its extensions pave the way to provide theoretical foundations to some of the above mentioned CSP-Based Planning recent explorations of planning with concurrent threads. In other words, we are not thinking of CSTRIPS — and its extensions — only as a new framework useful to build practical applications, we consider CSTRIPS the best way to present the essentials of any ECP framework, and hope that this increasing understanding of ECP fundamentals will allow us develop better ECP frameworks to tackle practical problems.

3.2

CSTRIPS

In this section we formally introduce the syntax and semantics of CSTRIPS.

3.2.1

The State Space

As in STRIPS, we use a first order language with equality L defined by using a tuple (C, V, P, F) of mutually disjoint sets of constant, variable, predicate and function symbols, to describe the state of the world. In CSTRIPS the State Space is defined exactly as the STRIPS State Space (see Definition 2.3.1.1). STRIPS also intended to give more structure when specifying planning domains, but — as shown in [Ero95] — it has a greater computational complexity than STRIPS.

80


Definition 3.2.1.1 The State Space, denoted by SCST RIP S , is defined by: SCST RIP S ≡ SST RIP S Hence, we have that SCST RIP S = 2A and, again, a state is represented by any subset of ground atoms of L, meaning the subset of ground atoms that hold in that particular state. Correspondingly, as in STRIPS, A denotes the set of all ground atoms in L. We say that any S 0 ⊆ S is a state subspace of S, and S(A0 ) denotes the associated state subspace of any subset A0 ⊆ A of the set of all ground atoms (see Definition 2.3.1.2). For simplicity, when there is no confusion, we write S instead of SCST RIP S . We are presenting a CWA version of CSTRIPS, and the definitions given in Section 2.3.1 of how in STRIPS a state s entails a formula in L are valid also for CSTRIPS. Therefore, the following statements valid in STRIPS continue to be valid in CSTRIPS: 1. s |= ` iff ( ` ∈ A ∧ ` ∈ s ) for any ` ∈ literals(L)[∅]

∨

( ` = ¬a ∧ a ∈ A ∧ a 6∈ s )

2. s |= φ iff ( ∀` ∈ φ . s |= ` ) for any φ ∈ 2literals(L)[∅] Also equivalent to: ( s |= φ ) ⇔ ( + φ ⊆ s ∧ atoms(−φ) ∩ s = ∅ ). Like in STRIPS, once we have defined how a state s entails the ground literals of L, we are capable of reasoning about more complex formulas using a standard first order reasoning mechanism as resolution. For the most general case of any φ in L, using resolution we can prove if s logically entails the formula φ that describes that property of the world. In this general case s |= φ is defined in terms of resolution; at the lowest level, when it is needed to check if s entails a ground atom, it relies on the previous definition of s |= φ for literals. It is straightforward to transform the CWA version of CSTRIPS we are presenting here into an open world assumption CSTRIPS (CSTRIPSOWA ). It is enough to follow the indications given in Section 2.5 to transform STRIPS into STRIPSOWA and apply them correspondingly to CSTRIPS to get the OWA version of the latter: CSTRIPSOWA .

3.2.2

The Syntax

As in STRIPS, we use a first order language with equality L defined by using a tuple (C, V, P, F) of mutually disjoint sets of constant, variable, predicate and function symbols, to describe the state of the world; we use another set of symbols N , disjoint from the previous sets, to represent the names of the operators which are also defined like in STRIPS (see Definition 2.3.2.1).

3.2. CSTRIPS

81

Definition 3.2.2.1 The Operator Specification Language is defined by: LOCST RIP S ≡ LOST RIP S For simplicity, when there is no confusion, we write LO instead of LOCST RIP S . We use the same notation to refer to the preconditions and effects of an operator, i.e. Pre(α), +Pre(α), −Pre(α), Eff + (α) and Eff − (α). The main idea underlying CSTRIPS is that there are a finite number of concurrent threads that change simultaneously in parallel. CSTRIPS explicitly represents this fact, it assumes that it is necessary to explicitly plan for all these simultaneous threads. In general not all operators can be applied in any thread, hence, to specify a domain we need to specify a non empty set of operators for each thread of the domain. Hence, a thread is simply characterized by any nonempty set of operators, that’s to say, any element of the power set 2LO minus the empty set, i.e. 2LO \ ∅. Definition 3.2.2.2 The CSTRIPS Concurrent Thread Specification Language, denoted by LTCST RIP S , is defined by: LTCST RIP S ≡ LDST RIP S So, the language used to define a concurrent thread T in CSTRIPS is exactly the language used to define a whole STRIPS domain LDST RIP S = 2LO \ ∅. For simplicity, when there is no confusion, we write LT instead of LTCST RIP S . To specify a thread it is enough to give any T ∈ LT , i.e. any nonempty set of operators: T ⊆ LO ∧ T = 6 ∅. In this case T specifies all the operators that can be applied in this thread. We now introduce a language that allows us to specify exclusively domains with n concurrent threads. Definition 3.2.2.3 The family of CSTRIPS(n) Domain Specification Languages, denoted by LDCST RIP S(n) , is defined for any n ∈ N by: Y LD ≡{D | D = Ti ∧ Ti ∈ LT } CSTRIPS(n)

i=1,...,n

For simplicity, we write LD(n) instead of LDCST RIP S(n) , when there is no confusion. The elements of LD(n) are any cartesian product of a fixed number n of threads. Each of those n threads contains the nonempty subset of operators that can be applied in the corresponding thread. A language to specify domains with any number of threads is simply the union of the previous languages over any possible n. Definition 3.2.2.4 The CSTRIPS Domain Specification Language, denoted by LDCST RIP S , is defined by: [ LDCST RIP S ≡ LD(n) n∈N

82


For simplicity, when there is no confusion, we write LD instead of LDCST RIP S . In CSTRIPS, a domain is defined as any element of this language, i.e. D ∈ LD . Being D defined as a cartesian product of its thread specifications, we denote as usual by dim(D) the dimension of the cartesian product. Hence, dim(D) = n means that the domain has n concurrent threads, and we can write D = (T1 × . . . × Tn ). (D)i denotes the ith set of the cartesian product that defines D, i.e. (D)i = Ti , and it is called the ith thread of D. (D)i contains all the operators that can be used by the ith concurrent thread of D: only the execution of operators in (D)i can represent actions associated with the ith concurrent thread. If the ith concurrent thread is finite, i.e. |(D)i | = ki ∈ N, we can write: (D)i = { αi,1 , . . . , αi,ki } being the operators αi,j for j = 1 . . . ki the operators of the ith thread. Being a CSTRIPS domain a set, as usual we denote by D = D0 the set equality. Clearly, if D = D0 , we have that dim(D) = dim(D0 ) = n and Ti = Ti0 for all i = 1 . . . n. Definition 3.2.2.5 Two CSTRIPS domains D and D0 are equivalent, denoted by D ∼ D0 , iff dim(D) = dim(D0 ) = n and there exists a domain D00 ≡ (D0 )i1 × . . . × (D0 )in such that the tuple (i1 , . . . , in ) is a permutation of (1, . . . , n), and D00 = D. Given D ∈ LD a domain of n concurrent threads we say that any of its elements α ~ = (α1 , . . . , αn ) ∈ D is an n-thread operator. A domain has all possible n-thread operators that can be made by combining n operators each taken from a different thread. Notice that each component of α ~ corresponds to the definition of a STRIPS operator, and if the domain has only one concurrent thread, n = 1, we get the classical definition of a STRIPS domain. A n-thread operator α ~ represents n operators that are simultaneously applied in parallel. The ith component is always an operator of the ith thread of D, i.e. (~ α)i ∈ (D)i . (~ α)i represents what α ~ does in the ith concurrent thread. For any n-thread operator α ~ ∈ D of any n-thread domain D ∈ LD we introduce the following notation that extends the previous notation on operators to n-thread operators: S + • Eff + (~ α)i ) α) ≡ i=1...n Eff ((~ S − α)i ) • Eff − (~ α) ≡ i=1...n Eff ((~ S • Pre(~ α) ≡ α)i ) i=1...n Pre((~ This extension proceeds by adding the contribution of all the components of the n-thread operator. Definition 3.2.2.6 Given any operator α ∈ LO , any thread T ∈ LT , any n-thread operator α ~ ∈ D of any domain D ∈ LD of n concurrent threads, we

3.2. CSTRIPS

83

define the sets respectively called the expansion of the operator, the thread, the n-thread operator, and of the domain, as follows: • E(α) ≡ • E(T ) ≡

{ αθ | θ : V(~x(α)) → terms(L)[∅]} S E(α) α∈T

α) ≡ E((~ α)1 ) × . . . × E((~ α)n ) • E(~ S • E(D) ≡ α) α ~ ∈D E(~ E(α) contains all possible forms of instantiating the operator α, E(T ) contains all possible forms of instantiating all the operators of the thread T , E(~ α) contains all possible forms of instantiating all the components of α ~ , and E(D) contains all possible forms of instantiating all the n-thread operators in the ~ θ~ ∈ E(D), meaning domain. We call instantiated n-thread operator any α what results from applying the corresponding substitution to every component of α ~ , i.e. replacing all the parameters of each (~ α)i with the corresponding ground terms given by (θ~ )i , e.g.: α ~ θ~ = (α1 θ1 , . . . , αn θn ). We denote with LGCST RIP S the goal specification language for CSTRIPS. For simplicity, when there is no confusion, we write LG instead of LGCST RIP S . To simplify the exposition, we restrict CSTRIPS to reachability goals, as we did with STRIPS. Also in parallel with STRIPS, the most general goal language for reachability goals is given by the whole first order language, i.e. LG ≡ L, and we do not commit CSTRIPS to a particular goal specification language for the same reasons. We get different members of the CSTRIPS family depending on which subset of L we choose as the goal specification language. If we choose LG equal to L we get all the members of the CSTRIPS family based on reachability goals. We can be more restrictive and, for efficiency issues, deal only with a more restricted subset. For example, we can restrict LG to be made only of Horn clauses or only of literals. We denote with CSTRIPSG:Horn the members of the family such that LG is restricted to be made only of Horn clauses, i.e.: LG:Horn ⊂ L. Similarly, when LG is restricted to be made only of literals we write CSTRIPSG:lit . This is exactly what we have done for the STRIPS case, and therefore, for the present case of reachability goals, we have: LGCST RIP S = LGST RIP S . Definition 3.2.2.7 The set of all instances of the CSTRIPS Planning Problem, denoted by ICSTRIPS , is defined by: ICSTRIPS ≡ LDCST RIP S ×S ×LG Therefore, x ∈ ICSTRIPS means that x is any instance of the CSTRIPS Planning Problem. Exactly like in STRIPS, we introduce the following notation, for any x = (D, s0 , G) ∈ ICSTRIPS :

84

CHAPTER 3. EXPLICIT CONCURRENT PLANNING (ECP) • D(x) = D

the planning domain specification of x;

• s0 (x) = s0

the initial state of instance x;

• G(x) = G

the goal of instance x.

Also following STRIPS, when dealing with more restrictive members of the CSTRIPS family, as CSTRIPSG:Horn and CSTRIPSG:lit , we denote the corG:Horn G:lit G:Horn responding sets of instances by ICSTRIPS and ICSTRIPS . Clearly, ICSTRIPS ⊂ G:lit ICSTRIPS and ICSTRIPS ⊂ ICSTRIPS . In most cases we simply write CSTRIPS and ICSTRIPS , without the superscript, meaning that what we state is independent of how LG is defined. We denote with ICSTRIPS(n) the set of all instances of the CSTRIPS(n) Planning Problem defined by: ICSTRIPS(n) ≡ LD(n) × S × LG . Each CSTRIPS(n) planning problem is a restriction of the CSTRIPS planning problem that exclusively deals with a fixed number n of concurrent threads. Hence, ICSTRIPS(n) is a proper subset of ICSTRIPS : ICSTRIPS(n) ⊂ ICSTRIPS and we have S that ICSTRIPS = n∈N ICSTRIPS(n) .

3.2.3

The Semantics

Before starting the illustration of the semantics of CSTRIPS, we want to eliminate ill defined n-thread operators. As we saw, in STRIPS it does not make sense that an operator’s effect adds and deletes the same atom. Now, due to the fact that we apply n threads simultaneously in parallel, we need to take care of the more complex interactions between the operators that act in parallel. We need to exclude the execution of simultaneous operators that have competing preconditions or inconsistent effects. Definition 3.2.3.1 Given any CSTRIPS domain D ∈ LD of n concurrent threads, i.e. dim(D) = n, and any of its instantiated n-thread operator α ~ θ~ = ~ (α1 θ1 , . . . , αn θn ) ∈ E(D), we say that α ~ θ is consistent iff there are: 1. No competing preconditions:

~ ∩ atoms(−Pre(~ ~ =∅ + Pre(~ αθ) αθ))

2. No inconsistent effects:

~ ∩ Eff − (~ ~ =∅ Eff + (~ αθ) αθ)

We can also require to exclude all n-thread operators that have no effect, by simply requiring Eff(~ α) 6= ∅. Conversely, notice that usually we would like to require that every thread has an operator without preconditions and without effects to model the situation when that individual thread should wait, for example, because it cannot apply any of its operators with effects. We are committing ourselves here to require neither of these two conditions in general, because they are not strictly necessary in all cases. Notice that the

3.2. CSTRIPS

85

present definition of consistency includes the STRIPS case for each individual operator: the competing preconditions condition (1) implies +Pre(αi ) ∩ − Pre(αi ) = ∅ and, equivalently, the inconsistent effects condition (2) implies Eff + (αi ) ∩ Eff − (αi ) = ∅. Definition 3.2.3.2 Given any instance x ∈ ICSTRIPS whose domain has n concurrent threads, i.e. dim(D(x)) = n, we say that any instantiated n-thread operator α ~ θ~ of this domain, i.e. α ~ θ~ ∈ E(D(x)), is executable in a state 4 ~ s ∈ S, iff : α ~ θ~ is consistent ∧ s |= Pre(~ αθ) ~ = ∅ the instantiated operator is executable When α ~ θ~ is consistent and Pre(~ αθ) in any state. Definition 3.2.3.3 Given any instance x ∈ ICSTRIPS whose domain has n concurrent threads, i.e. dim(D(x)) = n, and any of its instantiated n-thread operator α ~ θ~ ∈ E(D(x)) such that it is executable in state s ∈ S, we say that, ~ the application of α ~ θ~ in state s results in state s0 ∈ S, denoted s |=α~ θ s0 , iff we have: ~ \ Eff − (~ ~ s0 = s ∪ Eff + (~ αθ) αθ) The properties implicit in the fact that α ~ θ~ is executable, and hence consistent, guarantee that the order in which the ground atoms are added to and ~ s) to refer to the subtracted from s is not important. We use Result(~ αθ, result state s0 of the previous definition, i.e. we define the partial function Result : E(D(x)) × S → S⊥ defined for every instantiated operator α ~ θ~ ∈ E(D(x)) and for every s ∈ S by: ( ~ s0 if (~ αθ~ is executable in s) ∧ (s |=α~ θ s0 ) ~ s) ≡ Result(~ αθ, ⊥ o.w. Definition 3.2.3.4 Given any CSTRIPS domain D ∈ LD of n concurrent threads, a n-thread plan P in a domain D is defined as any finite ordered list of instantiated n-thread operators, i.e. (~ α1 θ~1 , . . . , α ~ m θ~m ) with m ∈ N0 such ~ that each α ~ i θi ∈ E(D). We denote by Plans(D) the set of all n-thread plans in D and by Plans(LDCST RIP S ) the set of all n-thread plans. Given a n-thread plan P = (~ α1 θ~1 , . . . , α ~ m θ~m ) ∈ Plans(D), we say that its length, denoted by kPk, is m, the length of the list of instantiated n-thread operators. Notice that a plan P is an n × m array, where n is the number of concurrent threads of the domain, its dimension, and m is its length, i.e. n = dim(D(x)) and m = kPk. ~ a set of literals the meaning of s |= Pre(~ ~ given by Definition 2.3.1.4, Being Pre(~ αθ) αθ), ~ ~ is +Pre(~ αθ) ⊆ s ∧ atoms(−Pre(~ αθ)) ∩ s = ∅. 4

86


Definition 3.2.3.5 Given any domain D ∈ LD of n concurrent threads we say that P = (~ α1 θ~1 , . . . , α ~ m θ~m ) ∈ Plans(D) is executable in state s0 ∈ S iff: ∃s1 , . . . , sm ∈ S . ( s0

~

|=α~ 1 θ1 s1

~

~

|=α~ 2 θ2 s2 ... |=α~ m θm sm )

In this case we say that the application of P in state s0 results in state sm , and denote this by: s0 |=P sm . Note that each α ~ i θ~i is executable in state si−1 ∈ S for all i = 1 . . . m. To determine when a n-thread plan is a solution of a CSTRIPS instance of the planning problem we need to provide semantics for the goal specification language. We denote with LGCST RIP S the Goal Specification Language for CSTRIPS. As we did in the case of STRIPS, to simplify the present exposition, we restrict STRIPS to the case of reachability goals. When we are dealing only with reachability goals we know that the goal depends exclusively on the state we are evaluating it, and hence to determine when a n-thread plan reaches a goal state we only need to specify the function: η : LG × S → {>, ⊥ } that defines, for each pair (G, s) of a reachability goal and a state, when G is or not satisfied in s. Observing the domain of the function η and the fact that the state space of CSTRIPS was defined as that of STRIPS, it should not be surprising that: LGCST RIP S ≡ LGST RIP S . Hence, all we said about LGST RIP S in Section Section 2.3.2 is also valid for LGCST RIP S . Particularly the fact that we do not commit CSTRIPS to a particular goal specification language because this is not indispensable. We prefer to leave it as general as possible. We get different members of the CSTRIPS family depending on which subset of L we choose as the goal specification language, exactly as was explained in Section 2.3.2 for the STRIPS case. For simplicity, when there is no confusion, we write LG instead of LGCST RIP S . So, in the most general case for reachability goals, when LG = L, the function η is defined exactly as in STRIPS by: ½ > if s |= G η(G, s) ≡ ⊥ o.w. Being G, even in the most general case, a formula of L, we know for sure that s |= G is defined as explained in Section 3.2.1. So, as in STRIPS, given any goal G ∈ LG , we say that a goal G is satisfied in a state s whenever η(G, s) = >, otherwise, when η(G, s) = ⊥, we say that G is not satisfied in s. As we commented for STRIPS, for more practical applications, it may be convenient to restrict the goal specification language so that η can be computed more efficiently. An example is CSTRIPSlits , the case when LG is restricted

SAS

3.3. CSTRIPS


87

to be any conjunction of ground literals of L, i.e. LG ≡ 2literals(L)[∅] , that we analyzed in Section 2.3.1. Notice that it is simple to add existentially quantified variables in LG to the previous case, like in ADL[Ped86, Ped87]. We thus define η(G, s) as equal to > iff there exists a substitution θ of the variables in G for ground terms such that the previous definition of η(Gθ, s) = >. Definition 3.2.3.6 Given any instance x ∈ ICSTRIPS whose domain has n ~ m θ~m ) ∈ Plans(D(x)) is a concurrent threads, a n-thread plan P = (~ α1 θ~1 , . . . , α solution of instance x iff : ∃sm ∈ S . ( s0 (x) |=P sm ∧ η(G(x), sm ) = > ) We denote by SOLCSTRIPS (x) the set of all solutions of x. Hence, P ∈ SOLCSTRIPS (x) means that P is a solution of x. We denote by SOLCSTRIPS(n) (x) the set of all solutions of any instance x ∈ ICSTRIPS(n) ⊂ ICSTRIPS . This completes the semantics of CSTRIPS. We have presented under the name of CSTRIPS all the members of the family such that the expressiveness of the preconditions and effects are conjunctions of negative and positive literals. We neither commit ourselves to a particular restriction on the expressiveness of the goal specification language, nor on the cardinality of the sets of symbols, nor on the arity of the predicates and constants. It is worth noticing that this choice of the expressiveness of preconditions and effects is not indispensable. We chose this particular restriction in their expressiveness because of its great simplicity. For example, extending the current presentation to include conditional effects is straightforward. In contrast, introducing disjunction in the preconditions and effects is more complex because this affects the definition given for consistent n-thread operators.

3.3

CSTRIPS

SAS

: Using State Variables SAS

SAS

In this section we introduce CSTRIPS . CSTRIPS denotes the version of CSTRIPS with state variables. We explain this extension of CSTRIPS with more details because it is the only one that actually requires some work. Instead, as we comment in the next section, most other extensions can be delivered very easily following the same steps explained in Chapter 2, but on top of CSTRIPS instead of STRIPS. It is straightforward to build this extension on top of CSTRIPS following the procedure presented in Section 2.7 but in this case, this is not enough. We need to take care of the fact that the operators at different threads might possibly try to assign different values to the same state variable. Notably, one SAS of the modifications we introduced when presenting STRIPS on page 48

88


when translated to CSTRIPS already does this. We gave a new “No inconsistent effects” part for the definition of consistency of instantiated operators. This change was the product of taking care of a similar problem, the possible multiple appearance of the same state variable in an operator. We write below how it is translated for the CSTRIPS case. For any instantiated n-thread operator α ~ θ~ ∈ E(D) we require: 1. 2.

~ ∩ Eff − (~ ~ = ∅ Eff + (~ αθ) αθ) ¯ ¯ SAS ¯ + ~ ¯ terms ∀v ∈ E (F ) . ¯Eff := (~ αθ, v)¯ ≤ 1

The previous definition of consistency is troublesome, mainly because sometimes it works against our intuition, and also because in practice, it forces us to use always different state variables for the different threads. We now exemplify this unexpected behaviour. Suppose, we have 10 concurrent threads, each of them with various operators that do something with the world, plus a noop operator that does nothing. Suppose that we want to count with a state variable how many times they do nothing. Suppose also that we declare a state variable named count, whose values are natural numbers, to save the current count, and that we specify the following assignment: (count := count + 1) in the add list of each noop operator. This works as intended, except when more than one, let’s say 3, of those threads execute a noop operator concurrently. In that case, the combined n-thread operator even if consistent (because even if (count := count+1) appears in more than one different operators’ add list it is exactly the same), it will not work as expected. Because, it will add only one to the previous count value and not three. The solution to this problem is simply to use a different state variable for every thread, i.e. count1 , . . . , count10 , and in each thread increment only the corresponding counter. So, we add (counti := counti + 1) in the add list of the noop operator of the ith thread. If we need the total we just use (count1 + . . . + count10 ). SAS So, it is not a problem if we just leave CSTRIPS like that, with the previous definition of consistency and no other change, but it is certainly inconvenient, because error-prone and uncomfortable to use. Hence, we now briefly describe a better strategy for all numeric 5 state variables: 1. We modify the definition of consistency given above to allow only one assignment for each state variable in all the add lists of the instantiated n-thread operator. This avoids the counterintuitive behaviour we commented above6 . 5 6

We call numeric state variables all those whose sort is a subset of the real numbers. The definition we gave above for consistency allows more than one occurrence of an

SAS

3.3. CSTRIPS


89

2. We introduce the following four new special addition, subtraction, multiplication and division “cumulative assignments” symbols: +=, −=, ×= and /=, all distinct from every other symbol used. 3. We extend the syntax of the Operators Specification Language by allowing these “cumulative assignments” into the add list of the operators in the following way: For any state variable v and term t (whose variables are restricted to be parameters of the operator) any of the following four “cumulative assignment” expressions can be included in an add list: (v+= t), (v−= t), (v×= t) and (v/= t) . These symbols can be part neither of the preconditions nor of the goal language. 4. We further modify the definition of consistency so that the components of any instantiated n-thread operator α ~ θ~ can simultaneously have over the same state variable v only one of the following three cases: (a) one assignment (v := t); (b) any combination of (v+= ti ) and (v−= tj ) ; or (c) any combination of (v×= ti ) and (v/= tj ) . No pair of these ~ So, if in any component three cases should occur simultaneously in α ~ θ. ~ of α ~ θ there is an assignment (v := t), that is the only time v appears ~ neither another assignment nor a “cumulative assignment” can in α ~ θ, appear in it. Otherwise there is uncertainty about the final value of the state variable. Notice that if we assign the value after applying the “cumulative assignments” we overwrite their effects. Similarly, we restrict the simultaneous use of the four “cumulative assignments” to the two pairs of commutative operations, i.e. the addition and subtraction by one side, and the multiplication and division by the other. These pairs cannot operate over the same state variable simultaneously. 5. We modify Definition 3.2.3.3 of the result of the application of an instantiated n-thread operator by the one we show below that accommodates the expected semantics, i.e. that all the contributions for each occurrence of a “cumulative assignment” effectively accumulate. Notice that being SCST RIP S , the state space of CSTRIPS, defined as equal SAS to SST RIP S , we have that the state space of CSTRIPS is defined by: SCST RIP S SAS ≡ SST RIP S SAS . The same happens with the goal specification language, so we have: LG ≡ LG . To complete what SAS SAS CST RIP S ST RIP S is needed for delivering this new definition of the result of applying an instantiated n-thread operator, we assume that a new definition of the Operator assignment. For example, in the above example (count := count + 1) appears in more than one concurrent operator’s add list. This happens every time the same assignment appears in more than one concurrent operator.

90


Specification Language LO and the corresponding definition of SAS CST RIP S the Domain Specification Language LD is given according to SAS CST RIP S

SAS

the above comments. Hence, the set of all instances of the CSTRIPS ning problem, denoted by ICST RIP S SAS , is defined by: ICST RIP S SAS ≡ LD

CST RIP S

SAS

plan-

× SCST RIP S SAS × LG SAS

+ Finally, we need to extend the definitions of Eff + := (αθ, v) and Eff := t (αθ, v) introduced on page 48 for instantiated n-thread operators, and add one more for each cumulative assignment. For any instantiated n-thread operator α ~ θ~ ∈ SAS terms E(D) and any state variable v ∈ E (F ) we define:

~ v) ≡ { (v 0 := t) | v = v 0 ∧ (v 0 := t) ∈ Eff + (~ ~ } • Eff + αθ, αθ) := (~ The set of all the assignment expressions with v in the left side that ~ appear in Eff + (~ αθ). ~ v) ≡ { t | (v := t) ∈ Eff + (~ ~ } αθ, αθ) • Eff + := t (~ ~ as right hand side of The set of all the terms that appear in Eff + (~ αθ) the assignment expression that contains the state variable v in its left hand side. ~ v) ≡ { t | (v+= t) ∈ Eff + (~ ~ } • Eff + αθ, αθ) += t (~ ~ as right hand side of The set of all the terms that appear in Eff + (~ αθ) the “cumulative assignment” addition expression that contains the state variable v in its left hand side. ~ v) ≡ { t | (v−= t) ∈ Eff + (~ ~ } • Eff + αθ, αθ) −= t (~ ~ as right hand side of the The set of all the terms that appear in Eff + (~ αθ) “cumulative assignment” subtraction expression that contains the state variable v in its left hand side. ~ v) ≡ { t | (v×= t) ∈ Eff + (~ ~ } αθ, αθ) • Eff + ×= t (~ ~ as right hand side of The set of all the terms that appear in Eff + (~ αθ) the “cumulative assignment” multiplication expression that contains the state variable v in its left hand side. ~ v) ≡ { t | (v/= t) ∈ Eff + (~ ~ } • Eff + αθ, αθ) /= t (~ ~ as right hand side of The set of all the terms that appear in Eff + (~ αθ) the “cumulative assignment” division expression that contains the state variable v in its left hand side. Now we have all the elements required for the new definition of the semantics of the application of an instantiated n-thread operator. This new definition SAS is the logical translation of STRIPS ’s Definition 2.7.0.12 for the CSTRIPS case (the first two items), but it also includes the treatment of the four new “cumulative assignments” (the last two items).

3.4. THE OTHER EXTENSIONS OF CSTRIPS

91

Definition 3.3.0.7 Given any instance x ∈ ICST RIP S SAS with a set of state SAS variable identifiers F , and any of its instantiated operators αθ such that it is executable in state (s, ~s ) ∈ SCST RIP S SAS , we say that, the application of any executable instantiated n-thread operator α ~ θ~ ∈ E(D) in state (s, ~s ) results 0 in state (s , s~0 ) ∈ SCST RIP S SAS , denoted by: (s, ~s ) |=αθ (s0 , s~0 ) iff: ~ \ Eff − (~ ~ ; s ∪ Eff + (~ αθ) αθ) ¯ ¯ SAS ¯ ~ v)¯¯ = 1 we have: • for all v ∈ E terms (F ) . ¯Eff + αθ, := (~ • s0

=

~ v) ; (s~0 )v = Eff + αθ, := t (~ ¯

• for all v ∈ we have:

¯ ¯

¯ ¯

¯

SAS ¯ ~ v)¯¯=¯¯Eff + (~ ~ ¯ ¯ + αθ, ~ v)¯¯=0 E terms (F ). ¯Eff + αθ, := (~ ×= αθ, v)¯=¯Eff /= (~

(s~0 )v

= (~s )v +

X ~ t∈Eff + αθ,v) += t (~

• for all v ∈ E terms (F we have:

SAS

(s~0 )v

X

t −

t;

~ t∈Eff + αθ,v) −= t (~

¯ ¯ ¯ ¯ ¯ ¯ ¯ ~ v)¯¯=¯¯Eff + (~ ~ ¯ ¯ + αθ, ~ v)¯¯= 0 ). ¯Eff + αθ, := (~ += αθ, v)¯=¯Eff −= (~ Q

t ~ t∈Eff + αθ,v) ×= t (~

= (~s )v Q

t ~ t∈Eff + (~ αθ,v) /= t

.

Notice that we required the instantiated n-thread operator to be executable. So, we know it is consistent, and in the new definition of consistency we have eliminated all the possible combinations of the “cumulative assignments” but three (see the 4-th item in page 89). The last three entries in the above Definition represent the partial results associated with respectively the three disjoint cases (a), (b) and (c) on page 89. Therefore, it is not necessary to treat the other cases. They are excluded for being inconsistent.

3.4

The other extensions of CSTRIPS

In this section we briefly comment about the various other extensions of CSTRIPS. • CSTRIPSsorts denotes the version of CSTRIPS that combines the manysorted extension of CSTRIPS. It is straightforward to deliver it starting from CSTRIPS and following the procedure presented in Section 2.4.

92

CHAPTER 3. EXPLICIT CONCURRENT PLANNING (ECP) • CSTRIPSOWA denotes the OWA version of CSTRIPS. It is straightforward to build this extension on top of CSTRIPS following the procedure presented in Section 2.5. MUTEX

• CSTRIPS denotes the version of CSTRIPS that can deal with sets of MUTEX predicates. It is also straightforward to build this extension on top of CSTRIPS following the procedure presented in Section 2.6. CEff

• CSTRIPS denotes the version of CSTRIPS that includes operators with conditional effects. It is straightforward to build this extension on top of CSTRIPS following the procedure presented in Section 2.8.1. MUTEX

• CSTRIPSsorts denotes the version of CSTRIPS that combines both MUTEX the many-sorted extension CSTRIPSsorts and the CSTRIPS . MUTEX

MUTEX

• CSTRIPSOWA denotes the combination of CSTRIPS Open World Assumption version: CSTRIPSOWA .

and the

SAS

• CSTRIPSsorts denotes the version of CSTRIPS that combines both the SAS many-sorted extension CSTRIPSsorts and the CSTRIPS extension based on the state variables. This combined version is the one we use in the examples. SAS,CEff

• CSTRIPSsorts denotes the version of CSTRIPS that combines both SAS the many-sorted extension CSTRIPSsorts , the CSTRIPS extension for CEff state variables, and CSTRIPS the conditionals-effects version.

About CPDDL 2.1 As we said at the beginning of this chapter our approach, even if exemplified here as an extension of STRIPS, can be straightforwardly applied to many other current planning frameworks. Particularly interesting is to deliver an ECP framework built from PDDL 2.1 [FL03] by applying the same method we use to deliver CSTRIPS from STRIPS. We call CPDDL 2.1 this potential ECP version of PDDL 2.1. We have highlighted SAS,CEff in Section 2.8.5 that STRIPSsorts encloses the core features of the semanSAS,CEff tics of PDDL 2.1 given in [FL03]. So, CSTRIPSsorts is an ECP planning framework that encloses the core features of the semantics of the potential SAS,CEff CPDDL 2.1 7 . The fact that we have delivered CSTRIPSsorts smoothly, suggests the viability of easily delivering CPDDL2.1. 7

In PDDL 2.1 the assignment operator := is denoted with assign. The “cumulative assignments” operators + =, − =, × = and / = are denoted respectively with increase, decrease, scale-up and scale-down.

3.5. THE TWO OIL TANKS DOMAIN EXAMPLE REVISITED

In1

Oil Tank #1 Out1

A1

Oil Tank #2

Level1 Level2

93

In2

Out2


A2

Figure 3.1: Two Oil Tanks Domain Example

3.5

The Two Oil Tanks domain example revisited

This section shows how easily we model the Two Oil Tanks domain (presented in Section 2.9) within CSTRIPS. This highly contrasts with STRIPS. Figure 3.1 repeats Figure 2.7 of page 58, to facilitate the reading. We do not repeat here the description of the features of the TOT domain, they may be found also on page 58. SAS We now show how to model this domain in CSTRIPSsorts . We use it instead of CSTRIPS to keep the present exposition close to that of Section 2.9, but we highlight that, even using the more humble CSTRIPS, it is quite easy to specify the TOT domain (using propositions like for example In1(x), Out1(x), In2(x), Out2(x), Level1(x) and Level2(x) instead of the state variables, and using only one sort). This also contrasts with Section 2.9. We use the same sorts, constants, variables, state variables and the same predicates as in Section 2.9. So, the language and the state space are the same. The concurrent threads. We model the TOT example using six different concurrent threads in the following way: T1 is used to model how A1 controls the input and output valves of Tank #1; T2 models how A1 controls the rest of the world; T3 models how A2 controls the input and output valves of Tank #2; T4 models how A2 controls the rest of the world; T5 models the change of the level of oil in Tank #1; and finally, T6 the same for Tank #2. The thread T1 has three operators: the first one models how A1 controls the input valve of Tank #1, the second one models how it controls its output

94


valve and the third is a noop operator that does nothing: it is used to wait the other threads when necessary. T1 = { (CtrlIn1(x − f low) : {} ⇒ {(In(T 1) := x)} {}), (CtrlOut1(x − f low) : {} ⇒ {(Out(T 1) := x)} {}), (noop() : {} ⇒ {} {}) }

The thread T2 has two operators: the first one for modeling how A1 interacts with the rest of the world, and the second one is a noop operator. T2 = { (CtrlRW1(r − rw) : {RWA1Ok(r)} ⇒ {RW(r)} {RW(Pred(r))}), (noop() : {} ⇒ {} {}) }

The thread T3 , like T1 , has three operators: the first one models how A2 controls the input valve of Tank #2, the second one models how it controls its output valve, and the third one is a noop operator. T3 = { (CtrlIn2(x − f low) : {} ⇒ {(In(T 2) := x)} {}), (CtrlOut2(x − f low) : {} ⇒ {(Out(T 2) := x)} {}), (noop() : {} ⇒ {} {}) }

The thread T4 , like T2 , has two operators: the first one for modeling how A2 interacts with the rest of the world, and the second one is a noop operator. T4 = { (CtrlRW2(r − rw) : {RWA2Ok(r)} ⇒ {RW(r)} {RW(Pred(r))}), (noop() : {} ⇒ {} {}) },

The thread T5 has only two operators. The first one models the physical change of the level of Tank #1. The second one deals with the overflow/underflow of the tank. We will use the auxiliary predicates LevelOk(t) and UpdateLevel(t) that respectively hold when it is possible to update the Level(t) without error and actually update the level, both introduced in Section 2.9. Notice that it does not have a noop because it needs to update the tank level permanently. T5 = { (Level1Evol() : {LevelOk(T 1)} ⇒ {UpdateLevel(T 1)} {}), (Level1Error() : {¬LevelOk(T 1)} ⇒ {(Level(T 1) := ⊥)} {})},

The thread T6 is similar to T5 but it deals with the change of the level of Tank #2. T6 = { (Level2Evol() : {LevelOk(T 2)} ⇒ {UpdateLevel(T 2)} {}), (Level2Error() : {¬LevelOk(T 2)} ⇒ {(Level(T 2) := ⊥)} {})},


95

So, being the concurrent threads those described above, the following CSTRIPS 6-thread domain completely models the TOT example: DTOT ≡ T1 × T2 × T3 × T4 × T5 × T6 Discussion. We first highlight how contrasting the simplicity of the previous specification is, if compared with that presented in Section 2.9. Notice that the operators are not entangled, it is a description of the domain as uncoupled as the domain itself, and it is more modular. On one side, it is more apt for a divide and conquer strategy: We can divide the modeling work much more easily by asking one knowledge engineer to model agent A1 and Tank #1, and another one to model agent A2 and Tank #2. It is also more modular in the much more important sense that the addition of new pairs of agents and tanks does not change anything of the definition of the previous already defined pairs of agents/tanks. It is worth highlighting that: • The level of each tank is modeled as a process that changes according to the physical rules of flow exchange. The level of a tank at a certain state is computed directly from the state of it at the previous state, by adding to the level the input flow and subtracting the output flow. So, this example shows how simple it is to model processes within CSTRIPS. This contrasts with the difficulties encountered by others to model processes. See [McD03] for a discussion of this subject. • The tanks are resources of oil that the agents use when realizing actions on the rest of the world. This is an unusual approach for representing resources in planning that we further explore in the next example.

3.5.1

The Shared Oil Tank domain: A more coupled example

The fact that the tanks are resources is not well exemplified by the TOT example, because those resources are not shared by the two agents. Each tank in the TOT domain is exclusively used by a single agent. We now present the Shared Oil Tank (SOT) domain, a more coupled variant, with the purpose of showing how to model shared resources in CSTRIPS. We also use this example to describe not only the domain as in the TOT example, but a complete instance of the CSTRIPS planning problem and a plan that solves it. Actually, SAS as in the TOT domain, we use CSTRIPSsorts to simplify the presentation. The Shared Oil Tank (SOT) domain is partially depicted in Figure 3.2. It consists of five parts: three agents, one shared oil tank, and the rest of the world. The three agents act concurrently. The level of the tank changes also concurrently with the agents’ actions. As in the TOT example, for the sake of

96


In

Level

Out1

A1

Out2

A2

Out3

A3


Figure 3.2: The Shared Oil Tank Domain Example simplicity, we model in detail the oil tank and abstract the other properties of the rest of the world. Also like the TOT example, each agent has the capability to execute in parallel actions from two sets: (a) actions that only modify the flow rate of the input/output valves of the oil tanks (and do not modify the rest of the world); (b) actions that only modify the state of the rest of the world (and do not modify the state of the tanks). As in the TOT domain, the agents do not control the level of the tanks directly, they only control the input/output valves. The level of the tank is a concurrent process that runs in parallel with everything the agents do. Again, we will assume that every step of the plan takes the same unit of time, and that the level of each tank at a certain instant is the direct sum of the input(+)/output(-) valves flow exchanges over the level at the previous state. Again the agents need to adjust the output flow to different levels because they need to consume different rates of oil depending on which actions of set (b) they are executing, i.e. a certain precise range of oil output flow appears as a precondition in those actions. Like in the TOT domain, instead of totally abstracting the rest of the world we use a simple representation for it. We model it by taking the same four assumptions enumerated when describing the TOT example on page 58 and adding some to model how the new third agent interacts with the rest of the world. We assume that: 1. A3 is more able to deal with the rest of the world. It can add an RW(r) atom to the rest of the world state for any value r (so we do not need to add a new predicate A3Can(r)).


97

2. But, as a trade off, we assume A3 has a more costly oil consumption scheme. So, we need to add a new auxiliary function A3Flow that gives, for every constant that can be added to the rest of the world, the flow of oil agent A3 needs. In the TOT domain example we did not specify when exactly the predicates A1Can(r) and A2Can(r) hold and which values A12Flow(r) returns. Our purpose was just to describe the TOT domain and it was not necessary to give more details. Now, on the contrary, we not only describe the SOT domain but, in addition, we show a plan accomplishing a goal. In order to do this, we need to specify in detail both previous predicates and the function A12Flow(r). To avoid increasing the complexity of this example we present them in the following simple form: • A1Can(r) holds only when r is odd and A2Can(r) for r even; • A12Flow(r) returns simply r mod 10 8 , and that A3Flow(r) returns 5 for r ≤ 5, and 10 otherwise. As in the TOT domain, the goal is to accomplish some state of the RW(r) properties of the rest of the world and simultaneously avoid the tanks overflow or underflow. If the tank overflows or underflows, we mark the tank level with an undefined ⊥ tag, meaning that the level cannot be computed anymore, i.e. this predicate cannot be removed later by any other operator. Sorts, constants, variables, state variables and predicates. We do not need a sort tank, as we did for the TOT example, because we have only one tank. We use the other sorts of the TOT example with their corresponding set of constants and variables. Also, as in the TOT example we partition the SAS set of function symbols F into two disjoint sets FSTRIPS and F . Again we SAS have FSTRIPS = ∅. But we need a different set F because we have different state variables. In the SOT example we have only one tank, but this tank has four valves instead of two: one input valve that controls the oil input into the tank, and three output valves, that control the oil feeding into each agent. Clearly, we have only one level to compute. So, we will use five state variables to model the state of the tank: In, Out1, Out2, Out3 and Level. All of them have arity zero, the first four contain values of sort f low, and the last one values of sort number. As in the TOT example, we use the constant ⊥ that is part of the sort number to specify whenever the level is out of range, either because of overflow or underflow, i.e. in this cases we write Level := ⊥. We use only one predicate: RW(r), exactly as before. 8

We denote x mod y the modulo y of x, the remainder of the integer division of its two operands, i.e. x mod y ≡ x − (x/y) ∗ y.

98

CHAPTER 3. EXPLICIT CONCURRENT PLANNING (ECP) SAS

SAS

The Lsorts language and the S state space. We gather all previous SAS specifications of the sets that are necessary to specify the language Lsorts : • Sorts: W = {f low, number, rw} • Constants: C(f low) = {0, . . . , 10}, C(number) = {1, . . . , 100, ⊥}, C(rw) = {1, . . . , 1000} • Variables: V(number) = {x, y}, V(rw) = {r, r0 } • The state variables: (:statevariables (In − f low) (Out1 − f low)(Out2 − f low)(Out3 − f low) (Level − number) ) • The predicates: (:predicates RW(r − f low) ) We have specified above a set of five state variable identifiers: SAS F = {In, Out1, Out2, Out3, Level} and they are all of arity zero, so, we have the same number of state variables SAS (dim(S ) = 5): SAS E terms (F ) = {In, Out1, Out2, Out3, Level} The first four of them have values of sort f low and the latter of number. Their domains are the default domains, i.e.: DIn , DOut1 , DOut2 , DOut3 = C(f low) and DLevel = C(number). The concurrent threads. We model the SOT domain using seven concurrent threads in the following way. The threads T1 and T2 are used to model the concurrent activities of agent A1, T1 to model how agent A1 controls the input and Out1 valves of the tank, and T2 to model how it interacts with the rest of the world. Similarly, T3 and T4 are used to model the concurrent activities of agent A2, and T5 and T6 those of agent A3. Through T3 the agent A2 controls valve Out2 and through T4 it interacts with the rest of the world. Similarly, through T5 the agent A3 controls valve Out3 and T6 models its interaction with the rest of the world. We have also T7 to model the change of the level of the tank oil. To simplify the specification of the operators we use the usual auxiliary operators + and − for addition and subtraction, and ≤ for comparisons. We assume that the +, − and ≤ return ⊥ if any of their arguments is ⊥. Also we use the auxiliary functions (A12Flow(r − rw) − f low), (A3Flow(r − rw) − f low) and (Pred(r − rw) − rw) introduced before and the following auxiliary predicates, similarly to what we did in the TOT example:


99

• A1Can(r − rw) ≡ it holds only when the agent A1 can add RW(r) to the state of the rest of the world (when r is odd) • A2Can(r − rw) ≡ similarly for A2 (when r is even) • RWA1Ok(r − rw) ≡ A1Can(r) ∧ RW(Pred(r)) ∧ (Out1 = A12Flow(r)) • RWA2Ok(r − rw) ≡ A2Can(r) ∧ RW(Pred(r)) ∧ (Out2 = A12Flow(r)) • RWA3Ok(r − rw) ≡ RW(Pred(r)) ∧ (Out3 = A3Flow(r)) • LevelOk ≡ (Level 6= ⊥) ∧ (0 ≤ Level + In − Out1 − Out2 − Out3) ∧ (Level + In − Out1 − Out2 − Out3 ≤ 100) • UpdateLevel ≡ (Level := Level + In − Out1 − Out2 − Out3) The thread T1 has three operators: the first one models how A1 controls the input valve of the tank, the second one models how it controls its Out1 valve, and the third one is a noop operator that does nothing and is used to wait when necessary. T1 = { (CtrlIn(x − f low) : {} ⇒ {(In := x)} {}), (CtrlOutA1(x − f low) : {} ⇒ {(Out1 := x)} {}), (noop() : {} ⇒ {} {}) }

The thread T2 has two operators: the first one for modeling how A1 interacts with the rest of the world, and the second one is a noop operator. T2 = { (CtrlRWA1(r − rw) : {RWA1Ok(r)} ⇒ {RW(r)} {RW(Pred(r))}), (noop() : {} ⇒ {} {}) }

The thread T3 has two operators: the first one models how A2 controls the Out2 valve of the tank, and the second one is a noop operator. T3 = { (CtrlOutA2(x − f low) : {} ⇒ {(Out2 := x)} {}), (noop() : {} ⇒ {} {}) }


The thread T5 has two operators: the first one models how A3 controls the Out3 valve of the tank, and the second one is a noop operator. T5 = { (CtrlOutA3(x − f low) : {} ⇒ {(Out3 := x)} {}), (noop() : {} ⇒ {} {}) }

100



The thread T7 has only two operators. The first one models the physical change of the level of tank. The second one deals with the overflow/underflow of the tank. It does not have a noop because it needs to update the tank level permanently. T7 = { (LevelEvol() : {LevelOk} ⇒ {UpdateLevel} {}), (LevelError() : {¬LevelOk} ⇒ {(Level := ⊥)} {})}

So, being the concurrent threads those described above, the following CSTRIPS 7-thread domain completely models the SOT example: DSOT ≡ T1 × T2 × T3 × T4 × T5 × T6 × T7 A planning problem. Suppose that we have an instance of the planning SAS problem in CSTRIPSsorts such that the initial state (s0 , ~s0 ) is such that the atoms RW(1) and RW(5) hold, all the three valves are closed In = Out1 = Out2 = Out3 = 0, and the tank is empty Level = 0. In the notation presented in Section 2.7 we write this: • Initial state: s0 = {RW(1), RW(4)} (~s0 )In = 0, (~s0 )Out1 = 0, (~s0 )Out2 = 0, (~s0 )Out3 = 0, (~s0 )Level = 0 Suppose the goal is the following conjunctive list of literals: • Goal:

G = {RW(3), RW(6), ¬RW(5), (Level ≥ 10)}

The solution. We show below a plan of four steps that is a solution for this instance. 

    P ≡    

CtrlIn(10) noop() noop() noop() noop() noop() LevelEvol()

noop() noop() CtrlOutA2(2) noop() CtrlOutA3(5) noop() LevelEvol()

CtrlOutA1(3) noop() noop() CtrlRWA1(3) CtrlOutA2(0) noop() CtrlRWA2(2) noop() CtrlOutA3(10) noop() CtrlRWA3(5) CtrlRWA3(6) LevelEvol() LevelEvol()

         

Before entering into a detailed explanation of the single steps of plan P, we want to point out that each column correspond to a single step of execution,


101

starting from the left. So, each step of the plan is determined by the corresponding column with the instantiated 7-thread operator to execute. Instead, each row represents a distinct concurrent thread. Each row contains all the instantiated operators that are subsequently executed in a single thread. The actions of the agent A1 are represented in the first two rows, those of the agent A2 in the next two rows, those of agent A3 in the next two rows, and T7 (that models the change of the tank level) in the last row. The first step of the plan is to apply the left most column to the initial state (s0 , ~s0 ) producing the first intermediate state (s1 , ~s1 ). The second step is to apply the second column to the first intermediate state; the following states are produced in the same way. So, using the notation we introduce in this chapter we have: (s0 , ~s0 ) |=(P)1 (s1 , ~s1 ) |=(P)2 (s2 , ~s2 ) |=(P)3 (s3 , ~s3 ) |=(P)4 (s4 , ~s4 ) We address any intermediate ith step of the plan P, i.e. its ith column starting from the left, by (P)i . We now explain plan P step by step: how it changes the state of the world until it solves the planning problem. We avoid to comment the thread T7 (the seventh row in P), because it always executes the operator LevelEvol() to permanently update the level of the oil tank. • 1st step (P)1 : In the first step A1 fixes the input valve In to the flow rate 10, to start filling the tank. So, the result of this step is reflected in the 1st intermediate state where the In flow is 10. As we explained above, it takes one step more until this In flow of 10 affects the level of the tank. Clearly, the agents cannot interact with the rest of the world, because this kind of actions requires oil and there is none in the tank yet. So, we have that the resulting state has only one change: the flow of In is now 10. • 1st intermediate state: s1 = {RW(1), RW(4)} (~s1 )In = 10, (~s1 )Out1 = 0, (~s1 )Out2 = 0 (~s1 )Out3 = 0, (~s1 )Level = 0 • 2nd step (P)2 : In the second step agent A2 fixes a flow of 2 to its associated valve Out2. In this way the flow of Out2 will become 2 at the 2nd intermediate state. Thanks to this A2 will be able to execute any action that needs a flow of 2 as a precondition in the 3rd step. For the same reasons agent A3 does Out3 := 5. Clearly, the agents still cannot do anything about the rest of the world because the tank is still empty. They need to wait at least until the next step to start modifying the rest of the world. The new level of the tank is computed as 10, from the addition of the input flow of 10, and the subtraction of the three output flows of 0 to the previous level of 0.

102


• 2nd intermediate state: s2 = {RW(1), RW(4)} (~s2 )In = 10, (~s2 )Out1 = 0, (~s2 )Out2 = 2 (~s2 )Out3 = 5, (~s1 )Level = 10 • 3rd step (P)3 : Agent A1 sets the flow of Out1 to 3. Agent A2 now can execute CtrlRWA2(2) and add RW(2) into the state of the rest of the world, because all the preconditions of this operator are fulfilled: Out2 = 2 = A12Flow(2), RW(1) holds, and A2 can add RW(2) because 2 is even9 . This operator adds RW(2) and simultaneously deletes RW(1). Agent A2 concurrently closes the output valve Out2 to avoid wasting oil. Similarly, A3 can execute CtrlRWA3(5) because: Out3 = 5 = A3Flow(5), RW(4) holds and this agent can add RW(r) for any r. This adds RW(5) to the state and deletes RW(4). Concurrently A3 needs to increase the output flow to Out3 = 10 to be able of execute CtrlRWA3(6) in the next step given that A3Flow(6) = 10. The new level of the tank is computed as 13, from the addition of the input flow 10, and the subtraction of the three output flows 0, 2 and 5 to the previous level of 10. • 3rd intermediate state: s3 = {RW(2), RW(5)} (~s3 )In = 10, (~s3 )Out1 = 3, (~s3 )Out2 = 0 (~s3 )Out3 = 10, (~s1 )Level = 13 • 4th step (P)4 : Agent A1 now can execute CtrlRWA1(3) because all the preconditions of this operator are fulfilled: Out1 = 3 = A12Flow(3), RW(2) holds, and A1 can add RW(3) because 3 is odd. This adds RW(3) to the state and deletes RW(2). Similarly, A3 can execute CtrlRWA3(6) because Out3 = 10 = A3Flow(6) and RW(6) holds. This adds RW(6) to the state and deletes RW(5). The new level of the tank is computed as 10, from the addition of the input flow 10, and the subtraction of the three output flows 3, 0 and 10 to the previous level of 13. • 4th state: a goal state! s4 = {RW(3), RW(6)} (~s4 )In = 10, (~s4 )Out1 = 3, (~s4 )Out2 = 0 (~s4 )Out3 = 10, (~s1 )Level = 10 Notice that without agent A2 closing its output valve Out2 in the third step the level would have finished in 8, failing to match the condition (Level ≥ 10) requested in the goal. 9

On page 97 we assumed that in the SOT domain A2Can(r) holds only when r is even, and A1Can(r) otherwise.


3.5.2

103

Upgrading for tanks that use “erosion aware” valves

In this section we briefly sketch two new domains: the Two Erosion Aware Oil Tanks (TEAOT) and the Shared Erosion Aware Oil Tank (SEAOT) domains. These domains are respectively like the TOT and SOT domains but for the fact that the oil tanks used are different in the following feature: they use “erosion aware” valves. These valves have a “maintenance needed” LED that turns on after their flow value has been changed more times than a certain limit (we use one million in this example). In this way the valves are “aware” of their degree of erosion and alert maintenance about the need of replacement. Afterwards, maintenance needs to intervene replacing the eroded valve for a new one. To simplify this example as much as possible we abstract the rest of maintenance activities supposing that its services come immediately after a “maintenance needed” LED turns on and after replacing the valves do nothing. We assume that the replacement action does not alter the flow of the valve. We impose the limit that maintenance can replace only one valve at a time. In this way maintenance can be simply modeled by a single thread. This thread should has one operator for each valve, to model the corresponding replacement of them, plus one noop operator. We denote the simplified version of the TEAOT and SEAOT domains when only the input valves are “erosion aware” valves respectively by TEAOTIn and SEAOTIn . Now we present in detail the TEAOTIn domain. We use two new sorts count and ledstate. We use the count sort for counting how many times each valve flow is changed and the ledstate sort to describe the state of each LED. Their associated constants are respectively: C(count) = {0, . . . , 1000000}

and

C(ledstate) = {ON, OFF}

We need to add the definition of the following state variables: (InCounter(t − tank) − count) (InLED(t − tank) − ledstate) (LastIn(t − tank) − f low) This gives us six new state variables: InCounter(T 1) and InCounter(T 2) are used to keep the count of how many times the input valves of respectively Tank #1 and Tank #2 change the flow value; InLED(T 1) and InLED(T 2) are used to keep the state of the LED of the input valves of the tanks; and LastIn(T 1) and LastIn(T 2) to keep the last value of the corresponding input valve. Finally, we use the predicate ReplacedIn(t − tank) as a flag through which the maintenance service signal it has replaced the valve. Notably, to model the TEAOTIn domain we need to modify none of the six threads that define the TOT domain. We only need to add a thread to model the behaviour of each “erosion aware” valve plus one more to model the maintenance service response as described above. So, we add to the TOT

104


domain presented before the following three threads: T7 to model the counter and LED of valve In(T 1); T8 similarly but for valve In(T 2); and T9 to model the response of the maintenance service. The thread T7 has four operators: the first one updates InCounter(T 1) every time the value of the input valve In(T 1) changes; the second one turns on the LED InLED(T 1) when the counter InCounter(T 1) reaches the value of one million; the third one reset the counter InCounter(T 1) and turn off the LED InLED(T 1) after the valve was replaced; and the fourth one is a noop operator. T7 = { (CounterUpdate() : {(InCounter(T 1) < 1000000) ∧ (In(T 1) 6= LastIn(T 1))} ⇒ {(InCounter(T 1) := InCounter(T 1) + 1), (LastIn(T 1) := In(T 1))} {}), (LEDUpdate() : {(¬ReplacedIn(T 1)), (InCounter(T 1) ≥ 1000000)} ⇒ {(InLED(T 1) := ON)} {}), (ReplaceUpdate() : {(ReplacedIn(T 1))} ⇒ {(InCounter(T 1) := 0), (InLED(T 1) := OFF)} {(ReplacedIn(T 1))}), (noop() : {} ⇒ {} {}) }

We skip the specification of the thread T8 because it is exactly as the one above of thread T7 but replacing T 1 by T 2. The thread T9 has three operators to model the maintenance activities: the first one models the replacement of valve In(T 1), the second one models that of valve In(T 2), and the third one is a noop operator. T9 = { (ReplaceIn1() : {(InLED(T 1) = ON)} ⇒ {(ReplacedIn(T 1))} {}), (ReplaceIn2() : {(InLED(T 2) = ON)} ⇒ {(ReplacedIn(T 2))} {}), (noop() : {} ⇒ {} {}) }

So, being the concurrent threads T1 , . . . , T6 those described in the TOT example, and T7 , . . . , T9 the ones described above, the following CSTRIPS 9-thread domain completely models the TEAOTIn domain: DT EAOT In ≡ T1 × T2 × T3 × T4 × T5 × T6 × T7 × T8 × T9 It is easy to model the complete TEAOT domain by repeating what we did above when modeling TEAOTIn domain. We need to add a new predicate ReplacedOut(t − tank) and again six new state variables with completely similar roles but now for the output valves. The state variables are defined as:


105

(OutCounter(t − tank) − count) (OutLED(t − tank) − ledstate) (LastOut(t − tank) − f low) We need to add two more threads: T10 to model the counter and LED of valve Out(T 1), and T11 to do the same but for valve Out(T 2). Finally, we need to modify T9 to model the response of the maintenance service also for the replacement of the output valves. So, the new T9 consist of five operators, the previous three plus ReplaceOut1() and ReplaceOut2() for the output valves defined exactly as the previous ones but for replacing In for Out. So, being the concurrent threads T1 , . . . , T6 those described in the TOT example, and T7 , . . . , T11 as explained in the previous paragraphs the TEAOT domain is completely modeled by the following CSTRIPS 11-thread domain: DT EAOT ≡ T1 × T2 × T3 × T4 × T5 × T6 × T7 × T8 × T9 × T10 × T11 It is also straightforward to model the SEAOTIn domain by following the same approach we have used above for the TEAOT domain. We need to add the same two sort count and ledstate with the same associated set of constants as for the TEAOT domain. We also need to add the three state variables for each “erosion aware” valve in the tank. For example, we add: (InCounter − count) (InLED − ledstate) (LastIn − f low) for the In valve and similarly for the other three valves Out1, Out2 and Out3. Finally, we need to add to the seven threads of the SOT domain, T1 , . . . , T7 , two new threads for each “erosion aware”. One updates the counter associated to the valve ( e.g. InCounter) and the other updates the LED associated with the valve ( e.g. InLED). So, they are completely similar to respectively the threads T7 and T8 presented above. Also we need to add one final thread to model the maintenance service similar to the thread T9 showed above. We have presented the TEAOT and SEAOT domains whose tanks have “erosion aware” valves with a LED signaling to maintenance the need of replacement. To conclude this section we want to highlight that it was possible to specify these domains reusing completely the specifications of the TOT and SOT domains. We only needed to add new state variables and threads to model the new features of the domain.

106

3.6


Analyzing CSTRIPS

This section explores the complexity issues of CSTRIPS; its relation with STRIPS; it shows how any planner for STRIPS can be used for planning in CSTRIPS and describes a basic CSTRIPS property concerning the gain in branching factor in highly parallel domains.

3.6.1

On the relations with STRIPS

It is easy to realize that when reducing CSTRIPS to one thread, we recover the STRIPS semantics, i.e. we have 10 : • ISTRIPS = ICSTRIPS(1) • ∀x ∈ ISTRIPS . SOLCSTRIPS(1) (x) = SOLSTRIPS (x) A 1-thread plan P ∈ SOLCSTRIPS(1) is just a list of instantiated operators, exactly like in STRIPS. This means that we can interpret any STRIPS instance as a CSTRIPS(1) instance and their solutions will be the same: STRIPS and CSTRIPS(1) are formally equivalent, both have the same expressiveness and complexity; they differ only in their ontological commitment [RN03]. However, any time the STRIPS instance is modeling more than one concurrent thread the interpretation of a STRIPS instance as a CSTRIPS(1) instance goes against the ontological commitment made by CSTRIPS. In this case, to respect the ontological commitment, what should be done is to translate the STRIPS instance into the corresponding CSTRIPS(n) instance for n equal to the number of threads modeled by the STRIPS instance. As usual in STRIPS, the concurrent threads are modeled by means of the objects of the logic L. For example the operator Go(x, y), where x represents the robot that goes to place y, implicitly assumes that there are n robots that in principle can act in parallel, hence it should be translated to a CSTRIPS(n) instance with one concurrent thread for each robot and changing the predicate to Go(y), where y represents the place. In fact, in CSTRIPS a predicate is associated with a thread, a robot in this case.

3.6.2

Planning algorithms and complexity

We showed above that STRIPS is covered as a particular case of CSTRIPS. CSTRIPS is more adequate than STRIPS from an epistemological viewpoint [MH69], we can say that CSTRIPS is more appealing to humans than STRIPS to express concurrent properties of a domain, as we can express explicitly the 10

In Section 2.3 we introduce ISTRIPS denoting the set of instances of the STRIPS planning problem and SOLSTRIPS (x) for the set of solutions of an instance x ∈ ISTRIPS .

3.6. ANALYZING CSTRIPS

107

different concurrent actions of a plan. It is important to underline that this advantage of CSTRIPS has not added extra computation cost. This is not always the case, see for example [Ero95] to appreciate how the more appealing decomposition methods of HTN are not for free. We now prove — by encoding any expanded instance of CSTRIPS into an expanded instance of STRIPS — that the complexity of the planning problem for the expanded instances are equal. In a sense, what happens is analogous to the case of STRIPSsorts presented in Section 2.4. We showed that even if in STRIPSsorts we can specify domains with sorts, which is impossible in STRIPS, the former can be encoded in the latter. So, nothing essential can be done in STRIPSsorts that cannot already be done with STRIPS. Even if CSTRIPS is more appealing to humans than STRIPS, from a strictly formal point of view, there is nothing essential that can be done with CSTRIPS that cannot already be done with STRIPS. So, in a strictly computational sense, CSTRIPS is not more expressive than STRIPS. Given any instance x ∈ ICSTRIPS we denote by E(x) = (E(D(x)), s0 (x), G(x)) the expansion of x, and by E(ICSTRIPS ) = {E(x) | x ∈ ICSTRIPS } the set of all expanded instances of the CSTRIPS planning problem. Correspondingly, E(ISTRIPS ) denotes the set of all expanded instances of the STRIPS planning problem. The total function iC2S : E(ICSTRIPS ) → E(ISTRIPS ), called the instanceCSTRIPS-to-STRIPS translation, is defined for any expanded instance x ∈ E(ICSTRIPS ) by: iC2S(x) = (EDSTRIPS , s0 (x), G(x)) ∈ ISTRIPS with:

EDSTRIPS = { αθ | α ~ θ~ ∈ E(D(x)) ∧ ~ ⇒ Eff + (~ ~ Eff − (~ ~ ) ∧ αθ = (n0α : Pre(~ αθ) αθ), αθ) 0 ~ ~ ~ nα =; N ((~ αθ)1 ); N ((~ αθ)2 ); . . . ; N ((~ αθ)n ) } This function converts any expanded instance of CSTRIPS into an expanded instance of STRIPS encoding in the name of each STRIPS operator the names ~ of the n components of each instantiated n-thread operator α ~ θ. Without loss of generality we assume that the concatenations n0α are valid STRIPS operators name symbols not used otherwise. So, we have that inside Plans(LDST RIP S ) we can identify the subset of domains that are product of the previous encoding. We denote this subset as PlansiC2S (LDST RIP S ). Having defined the state space in CSTRIPS exactly as the state space of STRIPS, we can use directly s0 (x) and a reachability goal G(x) as the initial state and goal of the STRIPS instance. It is easy to see that iC2S can be computed by a polynomial algorithm. The total function pS2C : PlansiC2S (LDST RIP S ) → Plans(LDCST RIP S ), called the plans-STRIPS-to-CSTRIPS translation, converts any solution of a

108


STRIPS instance, that is the “encoding” — by iC2S — of a CSTRIPS instance, into a solution of the original CSTRIPS instance. It is easy to give an algorithm that computes this function in polynomial time. For any P ∈ PlansiC2S (LDST RIP S ) it simply “parses” the name of each operator in P and constructs the corresponding instantiated n-thread operator. In general, an “encoded” STRIPS operator has a name like nα =; n1 ; n2 ; . . . ; nn . Hence, for any ni in the name nα , the algorithm simply lookups in the corresponding ith thread of the CSTRIPS’s domain D(x) the operator with that name. In ~ i of the n-thread operator. This that way it recovers the ith component (~ αθ) algorithm is also polynomial. Notice that the functions pS2C and iC2S guarantee us that the solutions are preserved: ∀x ∈ E(ICSTRIPS ) . P ∈ pS2C(SOLSTRIPS (iC2S(x))) ⇔ P ∈ SOLCSTRIPS (x) and being both functions computable in polynomial time, we reduced the expanded CSTRIPS planning problem to the expanded STRIPS planning problem preserving the set of solutions. Also, we showed before that ISTRIPS ⊆ ICSTRIPS , hence, we have already proved the following theorem. Theorem 3.6.2.1 The expanded CSTRIPS planning problem has the same complexity as the expanded STRIPS problem. This implies that any planning algorithm for STRIPS can be used also for CSTRIPS. Clearly, any STRIPS algorithm used for planning in CSTRIPS is not optimal, because it does not take advantage of the explicit representation of concurrency. An interesting approach is to use the planning algorithm presented in [BB01], it is extremely easy to adapt it for planning inside the CSTRIPS framework. But, as our next section suggests, much still remains to be explored.

3.6.3

Taking advantage of explicit concurrency

Remark 3.6.3.1 CSTRIPS can reduce the branching factor when searching for a plan in concurrent domains because of its explicit representation of concurrency. It does this by a factor of n1n when the instantiated operators are homogeneously distributed through the n concurrent threads. Suppose that we have a STRIPS domain D that models n concurrent threads, e.g. there are n agents that can perform one activity per time, but that can operate in parallel in the domain. We denote with E(D) the set of all possible instantiated operators of D, and assume that this set is finite, and |E(D(x))| = m. The fact that a domain has n concurrent threads cannot be represented explicitly in STRIPS, so when searching for a plan the planner needs to consider the possible application of all m instantiated operators.

3.7. SUMMARY

109

Therefore, to consider one step of evolution of the n threads, e.g. one action for each agent, we need to consider n times m instantiated operators, i.e. mn possibilities. When modeling the same problem in CSTRIPS we use a n concurrent threads domain. Therefore, the m possible actions are now divided into the n concurrent threads. We assume that this distribution is homogeneous, and hence each thread has m n possible actions. Therefore, to consider one step of evolution of the n threads, we need to consider n times but only m n possibilities, m n i.e. ( n ) . Hence, in this case, we have a decreasing factor of n1n , i.e. nn less choices that in STRIPS 11 .

3.7

Summary

In this chapter we have formally introduced Explicit Concurrent Planning presenting CSTRIPS, the most basic ECP framework derived from STRIPS. We explained how to deliver several extensions of CSTRIPS, like CSTRIPSsorts SAS a many-sorted version and CSTRIPS a version based on state variables. SAS,CEff CSTRIPSsorts — the version that combines both previous versions plus SAS,CEff conditional-effects — is of particular interest. As STRIPSsorts encloses the SAS,CEff core features of the semantics of PDDL 2.1 given in [FL03], CSTRIPSsorts is an ECP framework that should enclose the core features of a potential ECP version of PDD2.1 we call CPDDL 2.1. With the TOT and SOT examples we have shown several advantages of the ECP approach over the classical one. These examples show how simple it is to model processes, even processes that are resources concurrently used by several agents. The examples also highlight the potential of CSTRIPS and its extensions to structure the description of a domain by separating its components. This is particularly underlined by the TEAOT and SEAOT examples. These examples showed that it was possible a complete reuse of the specifications of the TOT and SOT domains when modeling the TEAOT and SEAOT domains. We just added to the TOT and SOT previously defined threads new ones that model the behaviour of the new “erosion aware” valves. Finally, we analyzed the relation between CSTRIPS and STRIPS, and proved that the expanded CSTRIPS planning problem has the same computational complexity as the expanded STRIPS planning problem. So, even if CSTRIPS is more appealing to humans than STRIPS, in the sense that it allows us to explicitly model the concurrent activities of a domain, this advantage is not paid off by an increased complexity. We have also proved that any 11

Notice that in CSTRIPS one step of evolution of the n threads corresponds to the application of just one α ~ θ~ operator, i.e. one step of the plan P. In STRIPS this corresponds to n steps of the plan.

110

CHAPTER 3

planning algorithm for STRIPS can be used for CSTRIPS, even if in general it will be suboptimal, and showed that planners for ECP frameworks can improve of a decreasing branching factor in domains that are highly concurrent.

Chapter 4

Object-Domains The majority of research efforts in AI planning has been devoted to improve the performance of reasoning algorithms, and to cope with the uncertainty of execution in real environments. A third aspect is also important for bridging the gap between theory and application in planning, namely, the knowledge engineering effort. This chapter is a theoretical contribution to knowledge engineering in planning, and proposes a formal method that allows us to model a domain as a set of objects. The desiderata of a modeling language suitable for large scale industrial applications include, among others, features like the following [Mey88]: extendibility, the property of adapting software products to changes of specifications; reusability, the ability of software elements to serve in the construction of many applications; compatibility, the ability to facilitate the combination of software elements. In order to include these features, object-oriented languages incorporate properties such as: a client/supplier relationship between the objects, specified explicit interfaces accessible only by the object clients, the notion of hidden data that can be accessed only by the object, etc. These properties enable a structured approach to application development, that can be carried out by groups of people, with a methodology for subdivision of labor, coordination, incremental refinement, error control, etc. The current practice of knowledge engineering in planning is far from achieving these results, and specific work is needed to bridge the distance from industrial practice. This work represents a step in this direction because it addresses the following question: is it possible to define an object for the description of planning domains with properties close to those of the objects in the standard object-oriented languages? The positive answer to this question is the main contribution of this chapter. In the following we describe a new way of structuring knowledge representation of planning domains by representing them as collections of objects, called object-domains. The properties of 111

112

CHAPTER 4. OBJECT-DOMAINS

these objects are akin to those defined in the object-oriented literature such as those mentioned above (client/supplier relationship, explicit interface, hidden data, etc.). Before moving on, it is worth reminding that two notable works have focused at some level on the notion of objects in planning, namely McCluskey and Porteous (e.g.,in [MP97, McC00]) and Biundo and Stephan (e.g., in [BS96]). The OCL family of object-centered languages studied by McCluskey and Porteous pursues the idea that the use of richer structural information about a planning domain by means of an object-centered specification improves the efficiency of planning and the quality of the result. The notion of object in OCL is that of the ordinary objects in a many-sorted First-Order Logic1 . They introduce an object-centered planning framework, meaning that the planning domain’s operators are defined in terms of how they change the state of objects. They associate each object with a set of ground atoms that defines its possible states. Using the notation introduced for STRIPS in Section 2.3, we can state this formally using a set of sort object to enclose all object identifiers (i.e. constants): They associate any object o ∈ C(object) with a subset of ground atoms Ao such that the associated subspace S(Ao ) defines all the possible states of o. Hence, in their work, the word object represents a completely different concept from the one we associate with that word in this chapter. For example, their objects lack most of the features usually associated with object-orientation, like for example the objects’ interface or the client/supplier relationship between objects, both central in the object-oriented classical literature and also central to the goals of our work. Biundo and Stephan’s work also has motivations close to ours. They also strive to obtain a modular modeling language that allows rich data types, like lists, stacks, etc. Quite different is the formal direction of these authors. Also their definition of object is similar to that of objects in ordinary sorted First-Order Logic. They give structure by means of abstraction, a temporal logic, and “pieces of ordinary programs” merged inside, to introduce abstract data types that can be composed by some “operations”: Union, Extension and Refinement. The introduction of pieces of ordinary programs in the definition of a planning domain produces a significant impact on the semantics of the planning language. On the contrary, our definition of object is similar to that of object-oriented programming languages, where an object has a complex structure of data and procedures, a client/supplier relationship with other objects, etc. as we described above. The main contribution of this chapter is to introduce a new formal method to structure the knowledge representation of a planning domain. This is done 1

In [MP97] they introduce a set of objects identifiers, define a sort as any subset of those objects identifiers — meaning all the objects that belong to that sort — and state that for every object in a domain there exists a unique object identifier that refers to it.

113 by means of a definition of object based on concurrent threads, the central concept in Explicit Concurrent Planning. This concept is used to specify Object-Domains, domains exclusively composed by sets of objects. The objects of an object-domain are inspired in the homonymous concept of the classical literature on programming languages, mostly about modularity and object-orientation, e.g. [Mey88]. The objects of an object-domain have an explicit interface, hidden data, and a set of concurrent threads. These objects are related by a client/supplier relationship. The concurrent threads of an object can modify and access the object’s data and the data of its suppliers interfaces. So, any object can exclusively interact with its own data and that in the interface of its suppliers. Correspondingly, only the threads of an object and those of its clients can interact with the object’s interface. The hidden data of an object are accessed and modified only by itself. Only the read-write part of the interface data can be modified by threads of the object clients, its read-only part can only be accessed. We introduce this strategy for structuring the knowledge representation of planning domains given a definition of object-domain based on the CSTRIPS framework. We choose this framework because it is the simplest ECP framework, and this allows us to give the most basic exposition of object-domains. Furthermore, we want to highlight that the main ideas exposed here can be applied to any ECP framework straightforwardly, because the definition of an object-domain is based on the concept of concurrent thread common to these frameworks. In fact, we explain in Section 4.4 how to define object-domains for all the extensions of CSTRIPS introduced in Chapter 3. It is worth highlighting that, by introducing these more structured objects, we perform a first and necessary step for the development of object-oriented languages for the knowledge engineering of planning domains as the one we propose in Chapter 5. Clearly, we need to have a precise definition of an object before building languages to describe them in a structured and concise form. Furthermore, it is interesting to highlight that we have created the bases to translate any statement typical of the object-oriented literature about the quality of the design of programs into the quality of the specification of an object-domains for planning. We can also automatically control many errors in the semantical properties of any domain specified in term of these structured objects. Both these things are not possible in previous approaches. This chapter contains five other sections. In the next section we introduce some formal machinery we need to define the object-domains formally. Afterwards, in two subsequent sections we introduce the language to declare an object-domain and its semantics by mean of the definition of a consistent object-domain, both based on CSTRIPS. Then we explain how to define an object-domain for the other extensions of CSTRIPS. In the last section we revisit the TOT and TEAOT domains by modeling them with objects exem-

114 S L E

CHAPTER 4. OBJECT-DOMAINS → → →

{L} | (S ∪ S) | (S ∩ S) | (S \ S) E | E, L atoms(L)

Table 4.1: Set of rules for the grammar GA plifying how to define an object-domain.

4.1

A world of objects based on ECP

In this section we introduce three formal machineries we need to deal concisely with the definition of an object-domain. First, a language to describe sets of atoms; second, an algebra to manipulate the sub-domains of an object-domain; and third, a series of functions that deliver the sets of ground atoms related to an operator, an n-thread operator, and to any sub-domain.

4.1.1

In a world of ground atoms

In both STRIPS and CSTRIPS, the state of the world is affected only by the execution of, respectively, instantiated operators and n-thread operators, by adding and deleting ground atoms to the current state. So, A, the set of all possible ground atoms, represents all the statements that can be part of a state of the world in a CWA. This highlights the importance of having proper tools to specify sets of ground atoms, and hence, to specify states. Notably it is frequent in planning that, for specifying the initial state, no other mechanism is used than an explicit enumeration of the ground atoms that compose the state. In what follows we introduce the language L(GA ) that allows us to specify any possible set of ground atoms. Definition 4.1.1.1 Given any first order language L, the sets of ground atoms specification language, denoted by L(GA ), is defined as the language produced by the grammar GA shown in Table 4.1. The first entry in the grammar (as usual it starts with S) presents the standard syntax for all classical set operations that return a set, i.e. ∪ union, ∩ intersection and \ subtraction. The second entry actually produces the list of elements in the sets. The final entry determines that the elements of these sets are atomic sentences. Both ground and not ground atoms are allowed. The semantics of this language are given below by the function χ that maps any specification of ground atoms into its corresponding set.

4.1. A WORLD OF OBJECTS BASED ON ECP

115

Definition 4.1.1.2 The total function 2 χ : L(GA ) → 2A is recursively defined for any specification of ground atoms s ∈ L(GA ) by:  S  i=1,...,k ζ(Pi )    χ(s0 ) ∪ χ(s00 ) χ(s) ≡  χ(s0 ) ∩ χ(s00 )    χ(s0 ) \ χ(s00 )

if if if if

s = {P1 , . . . , Pk } s = (s0 ∪ s00 ) ∧ s0 , s00 ∈ L(GA ) s = (s0 ∩ s00 ) ∧ s0 , s00 ∈ L(GA ) s = (s0 \ s00 ) ∧ s0 , s00 ∈ L(GA )

where the auxiliary function ζ : atoms(L) → 2A is defined for any P ∈ atoms(L) by: ½ {P } if P ∈ A ζ(P ) ≡ { P θ | θ : V(P ) → terms(L)[∅] } if P 6∈ A

The last three entries of the function χ give the usual semantics for union, intersection and subtraction of sets. Instead, its first entry applies to lists of atomic sentences. The function ζ translates each atomic sentence in the list into a set of ground atoms: If the atomic sentence in the list is ground the set is a singleton with just that ground atom, i.e. if P ∈ A we have that ζ(P ) = {P }. If the atomic sentence in the list is not ground, then ζ delivers a set with all possible ways of making the atomic sentence ground, i.e. if P 6∈ A we have that ζ(P ) = { P θ | θ : V(P ) → terms(L)[∅] }. For example, suppose that there are no function symbols in the language L, i.e. F = ∅, and the constant symbols are just two C = {c1 , c2 }, writing the following specification of ground atoms: Aspe = ({P1 (x, y), P2 (y)} \ {P1 (x, c2 )}) ∈ L(GA ) specifies the following set: χ(Aspe ) = {P1 (c1 , c1 ), P1 (c2 , c1 ), P2 (c1 ), P2 (c2 )} ⊆ A The result of the union of the first following two sets minus the third one: ζ(P1 (x, y)) = {P1 (c1 , c1 ), P1 (c1 , c2 ), P1 (c2 , c1 ), P1 (c2 , c2 )} ζ(P2 (y)) = {P2 (c1 ), P2 (c2 )} ζ(P1 (x, 2)) = {P1 (c1 , c2 ), P1 (c2 , c2 )} It is worth noticing that with L(GA ) it is easy to specify infinite sets of ground atoms. For example, it is enough to have in the logic L one unary function symbol succ and one constant symbol 0 that the set of ground terms terms(L)[∅] becomes infinite, and so, {P1 (x)} ∈ L(GA ) specifies an infinite set of ground atoms, i.e. the following: χ(s) = {P1 (0), P1 (succ(0)), P1 (succ(succ(0))), . . .} Therefore, by considering efficiency issues, it is convenient to put some restrictions on L(GA ). Some of the restrictions we impose are in the syntax \ C (e.g. below GA and G− A ), some in the semantics (e.g. L (GA )), others combine 2

The notation A, meaning the set of all ground atoms but {>, ⊥}, was introduced in Definition 2.3.1.

116


both. The aim is to reduce the computational complexity of the planning problem, still leaving the language with enough expressiveness for practical purposes. Definition 4.1.1.3 We define the following languages that are all restricted subsets of L(GA ): \

1. L(GA ) is obtained by restricting the first entry of the grammar GA to subtraction operation: S → {L} | (S \ S); 2. L(G− A ) is obtained by further restricting the first entry of GA banning all set operations: S → {L}; 3. L(G0A ) is obtained by restricting the first entry of GA to S → {L} and the third entry to E → A, i.e. an enumeration of ground atoms; 4. LC (GA ) has the same syntax as L(GA ); it is obtained by restricting the semantics by a new χ, exactly like the original are, but for the second entry of the definition of ζ (when P 6∈ A) which is replaced by { P θ | θ : V(P ) → C }. The variables are replaced only by constants, not by generic ground terms. \

5. LC (GA ) combines the previous restrictions 1 and 4. 6. LC (G− A ) combines the previous restrictions 2 and 4. Finally, in what follows we will abuse the notation we have just presented. Whenever a symbol is declared to be any possible set of ground atoms, we later accept to assign any specification of ground atoms directly to that symbol, instead of the ground atoms themselves. For example, suppose we have defined A as any subset of ground atoms of a language L, i.e. A ⊆ atoms(L)[∅]. We will write A = s with s ∈ L(GA ) for the specification of A as the ground atoms that s specifies. Instead, to be strictly formal, we should have written A = χ(s), because only χ(s) is a subset of atoms(L)[∅].

4.1.2

Sub-domains

Intuitively a sub-domain of a certain domain of n concurrent threads is obtained by considering only some of those n threads. We introduce here a formal definition and some simple notation that allow us to express properties of sub-domains that we need later.


117

We denote 3 by (D)τ , where τ ⊆ {1, . . . , dim(D)} ⊆ N, the cartesian product of some of the threads of the original domain D as indicated by the set τ and ordered in increasing value, i.e. for any set τ = {i1 , . . . , im } ⊆ {1, . . . , dim(D)} ⊆ N such that: i1 < . . . < im , we have that: (D)τ ≡ (D)i1 × . . . × (D)im . For example, being D = T1 × . . . × T7 we have that: (D){2,5,7} = (D)2 × (D)5 × (D)7 = T2 × T5 × T7 . When τ = ∅ we have (D)∅ = ∅. Notice that when τ is a singleton, τ = {i}, both notations agree (D)τ = (D){i} = (D)i = Ti . Definition 4.1.2.1 Given any domain D ∈ LD and being τ ⊆ N such that (D)τ = D, we say that D0 is a sub-domain of D, conversely that D is a super-domain of D0 , denoted D0 v D, iff: ∃τ 0 ⊆ τ . D0 = (D)τ 0 . Clearly, when D0 v D we know by definition that there exists a set τ 0 ⊆ N such that D0 = (D)τ 0 , and therefore, we can write directly (D)τ 0 v D. As usual D0 < D denotes a proper sub-domain. It is convenient to extend the notation to single threads: T v D meaning that T is one of the threads of D, formally: ∃i ∈ N . T = (D)i = (D){i} v D. Finally, notice that any domain is also a sub-domain of itself D = D{1...n} v D. Notice that being D a set we can always write D0 ⊆ D, but in this case 0 D is a subset of D, meaning some of the n-tuples originally in D. Instead, when we write (D)τ v D with |τ | = m, we have that (D)τ has now m-tuples: some subset of the n original components indicated by τ . For example, given any n-thread domain D = T1 × . . . × Tn we have that each element of D is an n-thread operators. When we write D0 ⊆ D we are simply taking some of those n-thread operators in D0 . When we write D0 v D we are taking some of the threads of D to build a new domain D0 , such that its elements are not more n-thread operators, but m-thread operators with m = Dim(D0 ). We introduce operators for any pair D0 , D00 of sub-domains of D, being 0 D = (D)τ 0 v D and D00 = (D)τ 00 v D: • Common minimum super-domain: D0 t D00 = (D)τ 0 t (D)τ 00 ≡ (D)τ 0 ∪τ 00

v D

• Common greatest sub-domain: D0 u D00 = (D)τ 0 u (D)τ 00 ≡ (D)τ 0 ∩τ 00

v D

• Complementary sub-domain: D0 \\ D00 = (D)τ 0 \\ (D)τ 00 ≡ (D)τ 0 \τ 00 3

v D

The operation (D)τ , corresponds to the projection operation in Relational Algebra [Cod70, Cod72]. The other operations introduced in this section t, u, \\ and ⊗ have no equivalents in Relational Algebra, in particular neither D t D0 , nor D ⊗ D0 , are equivalent to join.

118


Intuitively, the common minimum super-domain contains all the threads of both D0 and D00 . Conversely, the common greatest sub-domain has only the threads that are common to both D0 and D00 . Finally, D0 \\ D00 has only the sets that are in D0 and not in D00 . For example, being dim(D) ≥ 7, we have that: (D){2,5,7} t (D){2,6} = (D){2,5,6,7} , (D){2,5,7} u (D){3,5,7} = (D){5,7} and (D){2,5,7} \\ (D){5} = (D){2,7} . It is important to underscore that all the previous operators are closed in D, i.e. the result of applying them to any pair of sub-domains of D gives us always a sub-domain of D. For any pair D0 , D00 ⊆ D of subsets of D we can always write D0 ∪D00 , D0 ∩D00 and D0 \ D00 , meaning respectively the union, intersection and complement of the sets. This results in another subset of D, i.e. a set of n-tuples, that contains the union, intersection and complement of the n-tuples in D0 and D00 . Completely different from what happened with \ , t and u, whose results are not subsets of D because they operate with its threads. We now introduce an operator whose operands are any pair of domains or of their sub-domains and not, as in the previous cases, just pairs of subdomains of a common domain. Given any two domains Da , Db ∈ LD and any 0 0 of its sub-domains Da v Da and Db v Db , we denote the composite cartesian 0 0 product of these two sub-domains as: Da ⊗ Db ≡ T1 × . . . × Tn 0 0 0 0 0 0 being its dimension n = na + nb with na = dim(Da ) and nb = dim(Db ) and being its threads defined by: ( 0 0 (Da )i , for i = 1, . . . , na 0 0 Ti ≡ (Db )(i−na0 ) , for i = (na + 1), . . . , n 0

0

0

0

Note that both Da and Db are sub-domains of Da ⊗ Db , because we have 0 0 0 0 0 0 that: (Da ⊗ Db ){1,...,na0 } = Da and (Da ⊗ Db ){(na0 +1),...,m} = Db . The operator ⊗ is not closed even when applied over two sub-domains of a common domain. Its result in fact is not a sub-domain of that domain, but a new domain that, as the following example shows, can contain many times any single thread of the original domain, and in any order: (D){2,5} ⊗ (D){2,7} = (D)2 × (D)5 × (D)2 × (D)7 6= (D){2,5} t (D){2,7} = (D)2 × (D)5 × (D)7 v D. Given any domain D ∈ LD and ` being (D)τ1 , . . . , (D)τr v D any r subdomains of D, we say that the set D = {(D)τ1 , . . . , (D)τr } is a partition of the threads of D iff the set {τ1 , . . . , τr } is a partition of the set {1 . . . n} ⊆ N. In this case we have that being each τi nonempty, each (D)τi has at least one thread; and that, being all τi ’s pair-wise disjoint, we have for any i 6= j that (D)τi u (D)τj = ∅. Finally, being all τi ’s a cover of {1 . . . n} we know that the (D)τi ’s containàll the threads of the domain, hence: (D)τ1 t . . . t (D)τk = D. We denote by ?D the set of all partitions of the threads of D.


119

Being D a set, we reserve the usual mathematical concept of a partition of D to© any set whose elements are subsets of D, not sub-domains, i.e. if ª ΠD = D1 , . . . , Dk is a partition of D we have that all Di are subsets of D and therefore contain some of the n-thread operators originally in D, not necessarily some of its threads.

4.1.3

Classifying the ground atoms

We now define a series of sets to classify the ground atoms in various ways depending on how they can be affected or be required by sets of operators when executing. We proceed by classifying them at three levels: First, at the level of a single operator, i.e. all ground atoms affected or required by that operator; second, at the level of a single n-thread operator, i.e. all ground atoms affected or required by any operator that is in any component of the n-thread operator; third, at the level of any sub-domain, i.e. all ground atoms affected or required by any of the operators of that sub-domain. Because a single thread is a sub-domain, and the whole domain is also a sub-domain, the previous level includes both any thread and the domain. Definition 4.1.3.1 We define the following sets of ground atoms: 1. Given any operator α ∈ LO : S + + • AEff (α) ≡ αθ∈E(α) Eff (αθ) S − − • AEff (α) ≡ αθ∈E(α) Eff (αθ) +

−

• AEff (α) ≡ AEff (α) ∪ AEff (α) S • A+Pre (α) ≡ αθ∈E(α) +Pre(αθ) S −Pre • A (α) ≡ αθ∈E(α) atoms(−Pre(αθ)) • APre (α) ≡ A+Pre (α) ∪ A−Pre (α) • A(α)

≡ AEff (α) ∪ APre (α)

2. Given any n-thread operator α ~ ∈ D ∈ LD we define: S + Eff + ((~ • AEff (~ α) ≡ α)i ) i=1...n A S − − Eff Eff • A (~ α) ≡ ((~ α)i ) i=1...n A S Eff α) ) • AEff (~ α) ≡ i i=1...n A ((~ S +Pre +Pre • A (~ α) ≡ ((~ α)i ) i=1...n A S −Pre −Pre • A (~ α) ≡ ((~ α)i ) i=1...n A S Pre Pre • A (~ α) ≡ ((~ α)i ) i=1...n A S • A(~ α) ≡ α)i ) i=1...n A((~

120


3. Given any sub-domain (D)τ v D ∈ LD : i hS S + Eff + (α) • AEff ((D)τ ) ≡ A i∈τ α∈(D)i hS i S − Eff − (α) • AEff ((D)τ ) ≡ A i∈τ α∈(D)i h i S S Eff (α) A • AEff ((D)τ ) ≡ i∈τ α∈(D)i hS i S +Pre (α) • A+Pre ((D)τ ) ≡ A i∈τ α∈(D)i h i S S −Pre (α) A • A−Pre ((D)τ ) ≡ α∈(D)i i∈τ hS i S Pre (α) • APre ((D)τ ) ≡ A i∈τ α∈(D)i h i S S • A((D)τ ) ≡ A(α) i∈τ α∈(D)i Noticing that any domain D ∈ LD of n concurrent threads is also a subdomain of itself D = D{1...n} v D and that any thread of a domain is also a sub-domain T = (D)i = D{i} v D, it is clear that the previous definitions for sub-domains are also valid for the whole domain and for any of + − its threads. Hence, we write: AEff (D), AEff (D), AEff (D), . . ., A(D) and + − AEff (T ), AEff (T ), AEff (T ), . . ., A(T ). For example, if T = (D)i we have − − AEff (T ) = AEff ((D)i ). Furthermore, A(D) = A(D{1...n} ), the set of all ground atoms of D, contains all the ground atoms that are affected or required by any operator of any thread of the domain D, or equivalently, by any + + n-thread operator in D. Finally notice that AEff (α) = AEff (E(α)) because + the expansion of α is already inside the definition of AEff (α). The same is + + valid for AEff (~ α), AEff ((~ α)i ) and for all other sets defined.

4.2

Defining an Object-Domain

We now introduce the Object-Domain Specification Language, a language that allows us to specify CSTRIPS domains based on a new construct: objects. We start by showing how to specify an object. In addition to a set of threads, that is what characterized a CSTRIPS domain, an object is composed by three sets of ground atoms explicitly declared to be the object’s read-write, read-only and hidden data, and a couple of sets used to state the client/supplier relationship between objects. To identify each object we use another set of symbols I, disjoint from the previous sets of symbols used for defining CSTRIPS. When defining the components of the object’s tuple we simultaneously introduce the notation to access its different components.

4.2. DEFINING AN OBJECT-DOMAIN

121

Definition 4.2.0.2 The CSTRIPS Object Specification Language, denoted LObjCST RIP S , is definednby: o ro hid Sup LObjCST RIP S ≡ o | o = (io , Do , Arw , A , A , I ) o o o o where: • I(o) = io ∈ I is the object’s identifier. For any identifier of an object i ∈ I, we denote by O(i) its corresponding object, hence: O(I(o)) = O(io ) = o ; • D(o) = Do ∈ LDCST RIP S is the object’s domain, the set of concurrent threads associated exclusively with the object; • Arw (o) = Arw o ⊆ A is the object’s read-write interface data specification, a specification of the set of ground atoms that can be manipulated by its clients; • Aro (o) = Aro o ⊆ A is the object’s read-only interface data specification, a specification of the set of ground atoms that can be accessed but not manipulated by its clients; • Ahid (o) = Ahid o ⊆ A is the object’s hidden data specification, a specification of the set of ground atoms that are manipulated exclusively by the object; • I Sup (o)= IoSup ⊆ I \ I(o) the identifiers of the object’s suppliers. For simplicity, when there is no confusion, we write LObj instead of LObjCST RIP S . For any object o ∈ LObj we introduce the following additional notation: • AItf (o) ≡ Arw (o) ∪ Aro (o) the object’s interface data, the set of ground atoms that can be manipulated or accessed by the object and its clients. • A(o) ≡ AItf (o) ∪ Ahid (o) the object’s data, the set of ground atoms that are associated with the object. S • Aw (o) ≡ A(o) ∪ [ i∈I Sup (o) Arw (I(i))] the modifiable data, the set of ground atoms that the object’s threads can modify: its own ground atoms and its suppliers’ read-write interfaces. S • Ar (o) ≡ A(o) ∪ [ i∈I Sup (o) AItf (I(i))] the accessible data, the set of ground atoms that the object’s threads can access: its own ground atoms and its suppliers’ interfaces. Commonly in planning we have domains with a finite number of operators and concurrent threads of them, hence the set of identifiers of the object’s suppliers can be specified by simple enumeration. To specify the sets of ground atoms of the interface and hidden data of every object we need to use a different approach, because they can be large or even infinite. In general, a ground atom is the product of some substitution of the arguments of an atomic sentence

122


by ground terms. Depending on the member of the CSTRIPS family we are using, we can easily have an infinite number of ground atoms derived from just one atomic sentence. Even when dealing with finite cases the presence of the operator parameters appeal us to use a more symbolic representation than the simple enumeration. We use any language LA ⊆ L(GA ) to specify the sets of ground atoms associated with each object, i.e. to specify the sets of ground atoms Arw (o), Aro (o) and Ahid (o). The language L(GA ) was introduced in Section 4.1.1. We do not commit here to any particular subset of L(GA ). The most general case LA = L(GA ) is also the most costly from a computational point of view. So, choosing LA as one of the restrictions introduced in Definition 4.1.1.3, like LC (GA ) or LC (G− A ), seems more convenient for most practical applications. There are many ways of specifying these sets of ground atoms and we are not committed here to any particular subset of the language L(GA ), because its usefulness highly depends on the practical applications. The chosen language certainly impacts on any algorithm constructed to check properties of the domain. The function χ, also introduced in Section 4.1.1, maps any specification given in the language L(GA ) into the actual set of ground atoms. As we commented at the end of that section, we abuse the notation and when specifying the object’s read-only interface, read-write interface and hidden data we write them directly as some specification given in L(GA ). So, we write Arw (o) = s for some s ∈ L(GA ) instead of writing Arw (o) = χ(s). For example, suppose a language L with only two constants C = {c, c0 } and no other terms, we write Arw (o) = {P1 (x), P2 } ∈ L(GA ) meaning Arw (o) = χ({P1 (x), P2 }) = {P1 (c), P1 (c0 ), P2 }. Definition 4.2.0.3 The Object-Domain Specification Language, denoted LDObj , is defined by: LDObj ≡ 2LObj \ ∅ . An Object-Domain is defined as any element of this set, i.e.: DObj ∈ LDObj . In consequence, an object-domain is simply any nonempty set of objects, i.e.: Obj Obj is finite, its cardinality is the number of its objects, i.e. D ¯ Obj⊆ ¯ LObj . If D ¯D ¯ = r ∈ N means that DObj has r objects and we can write: DObj = {o1 , . . . , or }. Given an object-domain DObj ∈ LDObj , the set I Sup (o) of each object’s suppliers defines a supplier binary relation between the objects of DObj : © ª Sup ≡ (o, o0 ) | o, o0 ∈ DObj ∧ I(o) ∈ I Sup (o0 ) The inverse of this © relation is the client binary relation: ª Clt ≡ Sup−1 = (o, o0 ) | o, o0 ∈ DObj ∧ I(o0 ) ∈ I Sup (o) For any object o ∈ DObj we denote by I Clt (o) ⊆ I the set of identifiers of its clients, defined © by: ª Clt I (o) = I(o) | ∃o0 ∈ DObj ∧ (o0 , o) ∈ Clt

4.3. THE MEANING OF AN OBJECT-DOMAIN

123

So, we have that any object is a client of its suppliers, and a supplier of its clients.

4.3

The Meaning of an Object-Domain

¯ ¯ Definition 4.3.0.4 Given any object-domain DObj ∈ LDObj with ¯DObj ¯ = r objects we define its underlying CSTRIPS domain by: DCSTRIPS (DObj ) ≡ D(o1 ) ⊗ . . . ⊗ D(or ) For simplicity, we write D(DObj ) instead of DCSTRIPS (DObj ) when there is no confusion. By construction we have: P • dim( D(DObj ) ) = ri=1 dim(D(oi )) • ∀o ∈ DObj we have: D(o) v D(DObj ) ` • If all D(oi ) are nonempty we have that D(DObj ) ≡ {D(o1 ), . . . , D(or )} ` ` is a partition of the threads of D(DObj ), i.e. D(DObj ) ∈ ?D(DObj ) Therefore, when defining the objects of an object-domain we can assume that D(o) v D(DObj ) and refer to D(o) as the object’s sub-domain. Definition 4.3.0.4 shows what we said at the beginning of this section, namely, that LDObj is a language that permits us to define CSTRIPS domains, because it is enough to give any DObj ∈ LDObj to define a valid CSTRIPS domain: D(DObj ). Nothing of what was defined in the previous section guarantees us that the components of the objects in an object-domain behave accordingly to what we expect from the name we gave them. In this section we define the set of properties that an object-domain should fulfill to be consistently defined. These properties assure us that the objects’ components have the expected behaviour in the semantics of CSTRIPS. Before proceeding, we introduce some definitions. ¯ ¯ Definition 4.3.0.5 Given any object-domain DObj ∈ LDObj with ¯DObj ¯ = r objects, we define the data of DObj , i.e. the set of all explicitly declared ground atoms of DObj , by: [ A(DObj ) ≡ A(o) o∈DObj

Notice that in general we have: A(D(DObj )) 6= A(DObj ). The former contains all ground atoms that can be affected or required by the operators of any thread in the underlying CSTRIPS domain D(DObj ), see Definition 4.1.3.1.

124


Instead, the latter contains all ground atoms explicitly declared as data of the objects in DObj . We show below how these two sets need to be related to specify a consistent object-domain. Given any object-domain DObj for any subset of its objects’ identifiers, i.e. for any I 0 ⊆ I ∧ ∀i ∈ I 0 , ∃o ∈ DObj . i = I(o), we introduce the following notation that gives us the sub-domain of D(DObj ) composed by the sub-domains of all the objects pointed by the identifiers in I 0 : D(I 0 ) ≡ ti∈I 0 D(O(i)) . Sup Hence, D(I (o)) is the aggregated sub-domain of all the suppliers of the object o, D(I Clt (o)) of all its clients, D({I(o)} ∪ I Sup (o)) of the object and its suppliers, and D({I(o)} ∪ I Clt (o)) of the object and its clients. ¯ ¯ Definition 4.3.0.6 Given any object-domain DObj ∈ LDObj with ¯DObj ¯ = r and any of its objects o ∈ DObj , we say that o is consistent in DObj iff the following conditions hold: 1. The set A(o) is disjoint from the corresponding sets of the other objects in DObj ∀o0 ∈ DObj ∧ o0 6= o . A(o0 ) ∩ A(o) = ∅ 2. Only the threads of the object and its clients can access or modify Arw (o) if ∃T v D(DObj ) . A(T ) ∩ Arw (o) 6= ∅ ⇒ T v D({I(o)} ∪ I Clt (o)) 3. Only the threads of the object and its clients can access Aro (o) if ∃T v D(DObj ) . APre (T ) ∩ Aro (o) 6= ∅ ⇒ T v D({I(o)} ∪ I Clt (o)) 4. Only the threads of the object can modify Aro (o) if ∃T v D(DObj ) . AEff (T ) ∩ Aro (o) 6= ∅ ⇒ T v D(o) 5. Only the threads of the object access or modify Ahid (o) if ∃T v D(DObj ) . A(T ) ∩ Ahid (o) 6= ∅ ⇒ T v D(o) 6. The object’s hidden data cannot be totally unused by its threads Ahid (o) ⊆ A(D(o)) 7. The object’s threads can modify only its modifiable data (i.e. the object’s data and its suppliers’ read-write interface data)

∀T v D(o) . AEff (T ) ⊆ Aw (o) 8. The object’s threads can access only its accessible data (i.e. the object’s data and its suppliers’ read-only interface data)

∀T v D(o) . APre (T ) ⊆ Ar (o) We say that an object-domain is consistent when all its objects are consistent. Con(LDObj ) denotes the set of all consistent object-domains, Con(LDObj ) ⊆ LDObj .

4.3. THE MEANING OF AN OBJECT-DOMAIN

125

Hence, we write DObj ∈ Con(LDObj ) to state that DObj is a consistent objectdomain. Notice that when a object-domain is consistent, the definition guarantees us (Condition 1) that the sets A(oi ) are pair-wise disjoint, for all the objects in the domain: ∀i, j ∈ {1 . . . r} ∧ i 6= j . A(oi ) ∩ A(oj ) = ∅. Clearly, the r sets A(oi ) cover A(DObj ) by definition. Hence, if they are all nonempty, they are a partition of A(DObj ). Theorem 4.3.0.7 If an object-domain DObj is consistent we have: A(D(DObj )) ⊆ A(DObj ) The inclusion A(D(DObj )) ⊆ A(DObj ) holds by definition (Conditions 7 & 8). The definition of consistency guarantees us that the object’s hidden data cannot be totally unused by the objects’s threads (Condition 6), but we do accept read-write and read-only interface data that are not used by the object’s threads. Therefore the opposite inclusion A(D(DObj )) ⊇ A(DObj ) does not hold in general. We are excluding the case of unused ground atoms in the hidden data, but we accept ground atoms that are not modified but only accessed. By definition we know that only the object’s threads can modify these atoms (Condition 5), hence, we are certain that their presence or absence in any intermediate state of any plan of an instance will remain unmodified exactly as in the initial state. This can be useful. Indeed, being these ground atoms accessed by the preconditions of the object’s threads, they can be used to tailor different behaviours of the objects’s operators depending on the initial situation. By contrast, when the ground atoms of the hidden data are neither accessed nor modified by the object’s threads, this can be only the result of the presence of unnecessary ground atoms in the object’s data specification. Hence, by classifying this as not consistent we avoid these unnecessary data, i.e. a consistency checker algorithm will signal this problem helping the knowledge engineer in removing them. Clearly, the case of the object’s read-only interface data is different because these data are accessed by the threads of the object’s clients and can be useful even if the object’s threads neither access nor modify them. In this case, for any given instance, these ground atoms act as constants whose state is given by the initial state, and such that they can be accessed only by the threads of the object’s clients. The same is also valid for the object’s read-write data that can be not only accessed but also modified by the threads of the object’s clients. Notice that the ground atoms in the object’s interface that are neither accessed nor modified by the object act as variables that can be accessed only by the threads of the object’s clients. Furthermore, there are two classes of objects that relay on these extreme cases.

126


Definition 4.3.0.8 An object o ∈ LObj is a passive-data object iff D(o) = ∅ ∧ I Sup (o) = ∅ ∧ I Clt (o) 6= ∅ ∧ Arw (o) 6= ∅ An object o ∈ LObj is a constant-data object iff D(o) = ∅ ∧ I Sup (o) = ∅ ∧ I Clt (o) 6= ∅ ∧ Arw (o) = ∅ ∧ Aro (o) 6= ∅

Both passive-data and constant-data objects do not have threads to act on the world (D(o) = ∅). Hence we require that they do not have suppliers (I Sup (o) = ∅), because without threads they cannot access or modify their suppliers interface data. Also, due to the same fact, the consistency Condition 6 guarantees us that they do not have hidden data too. Both these objects need to have clients, otherwise they become completely useless. What distinguishes these objects is the following: A passive-data object necessarily has some read-write interface data and optionally some read-only interface data; a constant-data object has no read-write data, but necessarily has some read-only data. Hence, the clients can modify the read-write interface data and access the whole interface data of the passive-data objects, but only access the read-only data of the constant-data objects. Notice that a passive-data object can have Aro (o) 6= ∅, i.e. it can also provide some constants for its clients. The objects of an object-domain are inspired by the homonymous concepts in the object-orientation classical literature on programming languages, e.g. [Mey88]. The objects of an object-domain are related by a client/supplier relationship, they have an specified explicit interface, hidden data, and a set of concurrent threads that can modify and access these data and the data of its suppliers interfaces. Any object can interact exclusively with its own data and that of its suppliers by the explicitly declared interface. Correspondingly, only the threads of an object and those of its clients can interact with the object’s interface. The hidden data of an object is accessed and modified only by itself. Only the read-write part of the interface data can be modified by the object clients, the read-only part can only be accessed by them. Therefore, a first advantage of defining a planning domain using an objectdomain specification is that the planner can control that the domain formed by an aggregation of objects is consistently defined, and therefore, that it will reflect the main properties described above, so guaranteeing us a greater level of semantics control in a domain definition. It is worth noticing that this allows us to specify entire object-domains that respect the principle of information hiding, and that have minimum interfaces. These principles are central to structure the modeling of any planning domain and indispensable if we want to specify really huge and complex domains. Also, it is very interesting that we can translate any statement typical of the object-oriented literature about the quality of the design of programs to the quality of the specification of

4.4. OBJECT-DOMAINS FOR EXTENSIONS OF CSTRIPS

127

an object-domain for planning, e.g. the presence of passive-data objects is an indicator of a poor object-orientation in the specification of a planning domain or the size of the objects’ interface should be minimized. Nothing of what we said is possible in any current planning framework. Finally, it is worth remarking that, by introducing object-domains, we are not introducing a new planning problem, the planning problem continues to be the CSTRIPS planning problem. We show how any object-domain has associated an underlying CSTRIPS domain, a completely ordinary CSTRIPS domain over which the planning problem is formally defined. With the introduction of object-domains we gain more expressive power when defining a planning domain, but we have not done this at the cost of a higher computational complexity. We can understand any object-domain as just a particular highly structured way of defining a CSTRIPS domain.

4.4

Object-Domains for extensions of CSTRIPS

Notably in the definition of the Object Specification Language (Def. 4.2.0.2) there is only a single definition that explicitly depends on the fact that we are using CSTRIPS and no extension of it. This single item is the D(o) the object’s domain defined as any CSTRIPS domain, i.e. D(o) ∈ LDCST RIP S . Therefore, to define an object for any other extension of CSTRIPS, we need to change that entry and simply require the domain to be of the corresponding extension. For example, to define an object for CSTRIPSsorts , the many-sorted version, we need to require simply D(o) ∈ LDCST RIP Ssorts . There is another more subtle subject we need to upgrade for the case of SAS Object-Domains for CSTRIPS because of the change in the structure of the state space. In Definition 4.2.0.2 the object’s data was defined as any SAS subset of A — the set ground atoms — but in CSTRIPS we have also state variables. Hence, we need to upgrade the definition of LObj from the SAS one given for CSTRIPS to a new one for CSTRIPS . The only change that we need to make is to replace A with A∗ in the previous definition, where A∗ SAS is defined as follows. Being E terms (F ) the set of all state variables derived SAS from the set of state variables identifiers F , we define the set of ground atoms and state variables as: S terms SAS A∗ ≡ A E (F ) Afterwards, we proceed exactly as we did for the case of CSTRIPS, but always replacing A with A∗ . There is nothing more that needs to be changed in the definition of Object-Domain and in that of consistency of an Object-Domain, SAS for making them valid for CSTRIPS . Also the language L(GA ), presented in Section 4.1.1, needs to be upgraded

128


by including the state variables as valid data for any object. Definition 4.4.0.9 Given any first order language L, the sets of ground atoms and state variables specification language, denoted by L(GA∗ ), is defined as the language produced by the grammar GA∗ that is exactly like the GA defined in Table 4.1 but changing the last entry for: E

→

atoms(L) | terms(LF SAS )

where terms(LF SAS ) (see Definition 2.7.0.10) is the set of all possible terms SAS derived from the set of state variables identifiers F . Consequently, we need to upgrade Definition 4.1.1.2 that gives the meaning of this language. Therefore, we need to replace it with a new function ∗ χ : L(GA∗ ) → 2A defined like before, but adding the following new entry for the case of function terms derived from state variable identifiers: [ χ(s) ≡ ζ 0 (Vi (~xi )) if s = {V1 (~x1 ), . . . , Vk (~xk )} i=1,...,k ∗

where the auxiliary function ζ 0 : terms(LF SAS ) → 2A is defined for any V(~x) ∈ terms(LF SAS ) by: ½ { V(~x) } if V(~x) ∈ A∗ 0 ζ (V(~x)) ≡ ∗ { V(~x)θ | θ : V(~x) → A } if V(~x) 6∈ A∗ In what follows we will abuse the notation in parallel with what we explained for the case of L(GA ). Whenever a symbol is declared to be any possible element of A∗ we later accept to assign any specification of ground atoms or state variables directly to that symbol. For example, suppose we have defined A ⊆ A∗ . We write A = s with s ∈ L(GA∗ ), meaning that A is the set of ground atoms that s specifies. Instead, to be strictly formal, we should have written A = χ(s). For example, if we write Arw (o) = s for any s ∈ L(GA∗ ) instead of writing χ(s). Suppose a language L with only two constants C = {c, c0 } and no other terms, and suppose V1 and V2 are both state variables identifiers. We write Arw (o) = {P1 (x), P2 , V1 (x), V2 } ∈ L(GA∗ ) meaning Arw (o) = χ({P1 (x), P2 , V1 (x), V2 }) = {P1 (c), P1 (c0 ), P2 , V1 (c), V1 (c0 ), V2 }. About Object-Domains for CPDDL 2.1 It is worth highlighting the only thing we need to modify to this chapter in order to have formally defined object-domains for CPDDL 2.1 4 is the same single entry that we modified when building the various extensions of CSTRIPS: we need to require the domain being of the corresponding framework, i.e. D(o) ∈ LDCP DDL 2.1 . 4

In Section 3.4 page 92 we called CPDDL 2.1 the potential ECP version of PDDL 2.1.

4.5. THE TWO OIL TANKS DOMAIN AS AN OBJECT-DOMAIN

In1

Oil Tank #1 Out1

A1

Oil Tank #2

Level1 Level2

129

In2

Out2


A2

Figure 4.1: Two Oil Tanks Domain Example

4.5

The Two Oil Tanks domain as an object-domain

We presented the TOT domain first using the STRIPS planning framework in Section 2.9; later on we revisited it using CSTRIPS, in Section 3.5, to show how the latter improves our modeling capabilities with respect to concurrency. In this section we show how our modeling capabilities increase even further by describing the TOT domain as an object-domain. Figure 4.1 repeats Figure 2.7 to facilitate the reading. But we do not repeat here the description of the features of the TOT domain, the reader should refer to Section 2.9. We do not detail which sorts, constants, variables, functions, state variables and predicates we use here, because they are exactly the same as in Section 3.5. The objects. We model the TOT domain using five objects. We denote these objects oi for i = 1 . . . 5, and we specify them below using the Object Specification Language LObj , i.e. oi ∈ LObj . We now briefly describe them. Objects o1 and o2 are used to model the two agents A1 and A2. Objects o3 and o4 are used to model the two oil tanks #1 and #2. Object o5 is used to model the rest of the world. Object o1 has two threads that model the actions that agent A1 can execute: T1 models the agent’s actions that control the Oil Tank #1 and T2 models all other activities that A1 can execute in parallel, those that allow it to interact with the rest of the world. Similarly, object o2 (which corresponds to agent A2) is modeled by means of the two threads T3 and T4 , the former controls the Oil Tank #2 and the latter interacts with the rest of the world. Object o3 , which corresponds to Oil Tank #1, has one thread T5 to model the change of the level of oil. Likewise, object o4 models

130


the change of Oil Tank #2 with its thread T6 . Object o5 represents the rest of the world. This is a passive-data object, i.e. it has no threads and consists only of read-write data. The read-write data of o5 is defined as any ground atom derived from RW(r), the single predicate used in the TOT domain to abstract the rest of world. The definition of consistency guarantee us that this read-write interface data can be accessed and modified exclusively by the clients of o5 , i.e. the two agents. There is no need to specify or explain the six concurrent threads T1 , . . . , T6 mentioned above, because they are exactly those introduced when modeling the TOT domain using CSTRIPS in Section 3.5. Anyway, to help the reader, we repeat them below in a compact way. T1 = { (CtrlIn1(x − f low) : {} ⇒ {(In(T 1) := x)} {}), (CtrlOut1(x − f low) : {} ⇒ {(Out(T 1) := x)} {}), (noop() : {} ⇒ {} {}) } T2 = { (CtrlRW1(r − rw) : {RWA1Ok(r)} ⇒ {RW(r)} {RW(Pred(r))}), (noop() : {} ⇒ {} {}) } T3 = { (CtrlIn2(x − f low) : {} ⇒ {(In(T 2) := x)} {}), (CtrlOut2(x − f low) : {} ⇒ {(Out(T 2) := x)} {}), (noop() : {} ⇒ {} {}) } T4 = { (CtrlRW2(r − rw) : {RWA2Ok(r)} ⇒ {RW(r)} {RW(Pred(r))}), (noop() : {} ⇒ {} {}) }, T5 = { (Level1Evol() : {LevelOk(T 1)} ⇒ {UpdateLevel(T 1)} {}), (Level1Error() : {¬LevelOk(T 1)} ⇒ {(Level(T 1) := ⊥)} {})}, T6 = { (Level2Evol() : {LevelOk(T 2)} ⇒ {UpdateLevel(T 2)} {}), (Level2Error() : {¬LevelOk(T 2)} ⇒ {(Level(T 2) := ⊥)} {})},

We use the following five symbols to respectively identify the previous five objects: OA1, OA2, OT1, OT2 and ORW. We assume theses symbols are taken from the set of symbols I introduced in Section 4.2 to identify objects. The specification of the TOT domain as an object-domain is given by: DTObj OT = {o1 , o2 , o3 , o4 , o5 }

where: io o1 o2 o3 o4 o5

= ( OA1, = ( OA2, = ( OT1, = ( OT2, = ( ORW,

Do

Arw o

Aro o

Ahid o

IoSup

T1 × T 2 , T3 × T 4 , T5 , T6 , ∅,

∅, ∅, {In(T 1), Out(T 1)} , {In(T 2), Out(T 2)} , {RW(r)} ,

∅, ∅, {Level(T 1)} , {Level(T 2)} , ∅,

∅, ∅, ∅, ∅, ∅,

{OT1, ORW} {OT2, ORW} ∅ ∅ ∅

) ) ) ) )

We arranged the various elements in an array to facilitate the reader identify


o1 A1 OT1

o3

A2 R

131

o2

o5

OT2

o4

Figure 4.2: The Two Oil Tanks domain client/supplier relationship them, and added an extra comment line above the six definitions that describes the elements corresponding to each column: Column io contains the identifiers of each object; column Do contains their sub-domains, the cartesian product of its threads; column Arw o contains their read-write interface data specification; column Aro contains their read-only interface data specification; column Ahid o o contains their hidden data; and column IoSup the set of objects identifiers that are suppliers of the corresponding object. For example, object o1 , has an identifier OA1, and a sub-domain T1 × T2 , no read-write, read-only or hidden data, and the set of objects identifiers of its suppliers {OT1, ORW}. The latter set identifies o3 and o5 as its suppliers, because OT1 is the identifier of o3 , and ORW that of o5 . In Figure 4.2 we show the client/supplier relationship between the objects of this domain, with arrows going from the objects to its suppliers. The object o1 has two suppliers: its oil tank, represented by o3 , and o5 , which represents the rest of the world. Similarly, o2 has also two suppliers: its oil tank, represented by o4 , and again o5 . Neither the tanks, nor the rest of the world have suppliers. Objects o3 and o4 have one thread each, respectively T5 and T6 that model the change of their respective tanks’ level. These objects have both read-write data, defined respectively as {In(T 1), Out(T 1)} and {In(T 2), Out(T 2)}. Notice that this read-write interface data is made from state variables. Instead, object o5 has no thread, no suppliers and only some read-write interface data defined by {RW(r)}. Notice that this read-write interface consists of ground atoms, i.e. the set χ(RW(r)) = {RW(1), . . . , RW(1000)} with all the ground atoms derived from instantiating RW(r). The underlying CSTRIPS domain is given by: D(DTObj OT ) = D(o1 ) ⊗ D(o2 ) ⊗ D(o3 ) ⊗ D(o4 ) ⊗ D(o5 ) D(DTObj OT ) = T1 × T2 × T3 × T4 × T5 × T6 We recover exactly DTOT — the CSTRIPS version of the TOT domain —

132


defined on page 95. Discussion. It is worth noting that the specification of the object-domain can be seen as another method for specifying a CSTRIPS domain, but interestingly it is more than that. In fact, a consistent definition of the object-domain guarantees that the semantics of the objects are what we expect. A small example will further highlight this fact, by contrasting it with what happens in CSTRIPS and STRIPS. Let us suppose that when modeling this domain in CSTRIPS we have two engineers, one modeling agent A1 and the Oil Tank #1, and the other one working on agent A2 and the other tank. Suppose also that the latter engineer makes a mistake while specifying an operator of agent A2 whose effect is to wrongly modify the flow rate of some of the valves of Oil Tank #1. This mistake may not affect the behaviour of agent A2 that the engineer is modeling, and hence, can pass unnoticed. But clearly this error will cause almost certainly an improper behaviour of agent A1 modeled by the other engineer. Instead, this kind of errors can be detected if the engineers work by specifying this domain as an object-domain as above. Supposing again that the second engineer makes the same mistake when specifying the operators of agent A2 (now part of object o2 ), a software tool that checks if the objectdomain is consistent will find the problem. This happens because object o2 that models agent A2 cannot access the interface of object o3 that models Oil Tank #1 because the latter is not one of its suppliers. It is worth noting that this is just an example of the mistakes that this strategy can detect (the one associated with Condition 1 in Definition 4.3.0.6), but that checking for consistency will find other kinds of errors associated with the other conditions in that definition. It is worth highlighting that this defect of CSTRIPS that the object-domain approach supersedes is common to most planning frameworks, e.g. neither in STRIPS [FN71, Lif86] nor in PDDL 2.1 [FL03] is possible to detect this kind of errors. In fact, the situation is even slightly worse than in CSTRIPS. Due to the lack of explicit representation of concurrency it is more difficult to split the specification work.

4.5.1

Revisiting the case of tanks with “erosion aware” valves

In Section 3.5.2 we have introduced the TEAOT and SEAOT domains. These domains are respectively like the TOT and SOT domains but for the fact that the oil tanks have “erosion aware” valves. These valves have a “maintenance needed” LED that turns on after their flow value has been changed more than one million times. In this section we revisited the TEAOT domain modeled previously. Exactly as happened in the previous section, there is no need to specify or explain the eleven concurrent threads T1 , . . . , T11 we use in


133

this section to model TEAOT, because they are exactly those presented in Section 3.5.2, when defining DT EAOT as a CSTRIPS 11-thread domain. Now we show how to model the TEAOT domain as an object-domain. We model TEAOT using six objects oi with i = 1, . . . , 6. We use the first five of these objects exactly as when modeling the TOT domain. We use objects o1 and o2 to model the two agents A1 and A2; objects o3 and o4 to model the two oil tanks #1 and #2; and object o5 to model the rest of the world. But we need to change the specification of objects o3 and o4 to incorporate the fact that now the oil tanks use “erosion aware” valves. The other three objects remains completely unchanged. Finally, we need to add o6 a new sixth object that models the maintenance service. The “erosion aware” valves of Tank #1 are modeled by adding into the specification of object o3 of the TOT domain the following: (a) the threads T7 and T10 that model the In(T 1) and Out(T 1) valves; (b) read-write interface data: the ground atoms ReplacedIn(T 1) and ReplacedOut(T 1); (c) read-only interface data: the state variables InLED(T 1) and OutLED(T 1) with the state of the corresponding LEDs; and (d) hidden data: the state variables InCounter(T 1), OutCounter(T 1), LastIn(T 1) and LastOut(T 1). We model Tank #2 in a complete similar way, adding to the definition of object o4 of the TOT domain the threads T8 and T11 ; the read-only interface data InLED(T 2) and OutLED(T 2); and the hidden data InCounter(T 2), OutCounter(T 2), LastIn(T 2) and LastOut(T 2). The object o6 models the maintenance service. Its sub-domain is the thread T9 of the definition of DT EAOT in Section 3.5.2 and declares as its suppliers the two Tanks #1 and #2. This allow it to access the state variables InLED(T 1), InLED(T 2), OutLED(T 1), OutLED(T 2), and replace the valves by adding the corresponding ground atoms ReplacedIn(T 1), ReplacedIn(T 2), etc. So, the specification of the TEAOT domain as an object-domain is given by: DTObj EAOT = {o1 , o2 , o3 , o4 , o5 , o6 }

where: io

Do

o1=( OA1, T1 × T2 , o2=( OA2, T3 × T4 , o3=( OT1, T5 × T7 ×T10 , o4=( OT2, T6 × T8 ×T11 , o5=( ORW, o6=( OMA,

∅, T9 ,

Arw o ∅, ∅, {In(T 1), Out(T 1), ReplacedIn(T 1), ReplacedOut(T 1)}, {In(T 2), Out(T 2), ReplacedIn(T 2), ReplacedOut(T 2)}, {RW(r)} , ,

Aro o

Ahid o

∅, ∅, ∅, ∅, {Level(T 1), {InCounter(T 1), InLED(T 1), OutCounter(T 1), OutLED(T 1)}, LastIn(T 1), LastOut(T 1)}, {Level(T 2), {InCounter(T 2), InLED(T 2), OutCounter(T 2) OutLED(T 2)}, LastIn(T 2), LastOut(T 2)}, ∅, ∅, ∅, ∅,

IoSup {OT1, ORW} ) {OT2, ORW} ) ∅ )

∅

)

∅ {OT1, OT2}

) )

134


The underlying CSTRIPS domain is given by: D(DTObj EAOT ) = D(o1 ) ⊗ D(o2 ) ⊗ D(o3 ) ⊗ D(o4 ) ⊗ D(o5 ) ⊗ D(o6 ) D(DTObj EAOT ) = T1 × T2 × T3 × T4 × T5 × T7 × T10 × T6 × T8 × T11 × T9 So, we recover a domain that is equivalent 5 to DT EAOT , the CSTRIPS version of the TEAOT domain defined on page 105, i.e. D(DTObj EAOT ) ∼ DT EAOT . We want to underscore that when modeling the TEAOT domain we use — without a change— the same specification we gave for the TOT domain of the objects o1 , o2 and o5 . These objects model the two agents and the rest of the world. All of them have the same behaviour in both domains. Furthermore, with respect to the oil tanks we reuse an hundred percent of the specification of the TOT domain. To model the TEAOT we simply add new threads, interface and hidden data to model its new features. This shows the potential of this approach to structure the description of a domain by separating its components. To conclude this section we want to highlight that being the counters InCounter(T 1) and OutCounter(T 1) declared as hidden data of object o3 , we can guarantee that if the object-domain is consistent, no other thread but those of o3 neither access nor modify these state variables. The same can be said about the counters InCounter(T 2) and OutCounter(T 2) declared as hidden data of object o4 , with respect to that object. So, we have also shown how to use the principle of information hiding when modeling a planning domain. This allow us to improve the robustness and modularity of the modeling.

4.6

Summary

This chapter has shown that, by representing the concurrent properties of a planning domain as concurrent threads, it is possible to give a completely formal definition of Object-Domains, i.e. a planning domain specified as an aggregate of objects. These objects have properties closely related to those of the objects in the programming languages literature. Briefly, objects are related through a client/supplier relationship, have an explicitly specified interface, hidden data, and a set of concurrent threads that can modify and access these data, and the data of its suppliers interfaces. The main contribution of this chapter is the introduction of this new formal method to build structured knowledge representations of planning domains which is crucial for tackling really huge and complex domains. 5

In CSTRIPS two domains are equivalent when their definitions differ only in the order of the threads of the cartesian products (see Definition 3.2.2.5).

135 The examples of the TOT and TEAOT domains show that to declare them as object-domains is not more complex than in CSTRIPS, but the benefits are great because once they are specified as an object-domain we can check many semantics properties about them, which is not possible in CSTRIPS. As the sketchy discussion after the TOT example on page 132 shows, the definition of consistency of an object-domain (Definition 4.3.0.6) can be used to build software tools to support the knowledge engineering of planning domains by checking consistency during and after the modeling task. The TEAOT domain example underlines the unusual levels of reusability we obtain with this approach and that it is possible to use the principle of information hiding when specifying planning domains. Both things help us to increase the robustness and modularity of the knowledge engineering for planning. The introduction of objects identifies a backbone methodology not only for modeling the domain but, more importantly, for allowing a subdivision of labor among knowledge engineers having the theoretical tools for clearly defining the interfaces among them. This chapter introduced a formal definition of objects that paves the way and gives foundation for the development of Object-Oriented Languages for Knowledge Engineering for planning domains, languages that define classes and use a heir/ancestor hierarchy to relate them, etc.; classes that when compiled generate a set of objects that form the planning domain. In the next chapter we present pDOOML an example of a language with these characteristics. In conclusion, it is worth saying that — as explained above — our approach, even if exemplified here over CSTRIPS and all the extensions we presented in Chapter 3, can be straightforwardly applied to other current planning frameworks like PDDL 2.1 [FL03].

Chapter 5

pDOOML: An O-O Language for planning domains In this chapter we introduce pDOOML (pronounce it “p-doomel”), from Planning Domain Object Oriented Modeling Language. pDOOML is a simple Object-Oriented (O-O) language for defining planning domains as ObjectDomains. This language allows the knowledge engineer to specify a library of classes. Each of these classes, as in O-O Programming, specifies a different class of objects. As in O-O programming, it is possible to inherit from one or more previously declared classes to define a new class. Finally, we can declare an Object-Domain by simply creating objects from the library of classes and link them as desired. The Object-Domain written in pDOOML can be automatically translated — compiled — into a specification written in LObj of a consistent ObjectSAS Domains for the CSTRIPSsorts . The present version of pDOOML only genSAS SAS erates CSTRIPSsorts domains such that P = ∅, FSTRIPS = ∅ and F 6= ∅, i.e. the language L that pDOOML generates has only state variables. We discard here the predicates because we showed in Section 2.7.1 that the use of state variables is more appealing from an epistemological viewpoint and usually results in a reduction of the state space. So, the state space is determined SAS only by the state variables. If P = ∅ we have SST RIP S SAS ≡ S . The first simplifying consequence resulting from this choice is that we can avoid writing the delete list in the operators, because it will be always empty. This is due to the fact that the state variables are always assigned in the add list of the operators and never in the delete list. In this chapter we first present the main characteristics of pDOOML, including some classes of its general purpose library. Afterwards, we explain how to build a library of classes for the TOT, SOT, TEAOT and SEAOT domains we introduced in the previous chapters, and how to specify these two 137

138

CHAPTER 5. PDOOML: AN O-O LANGUAGE FOR PLANNING

domains using the aforementioned library. Then, we briefly explain the semantics of pDOOML, i.e. how an Object-Domain specified with pDOOML is SAS translated into an Object-Domain for CSTRIPSsorts written in LObj . Finally, we make some observations highlighting the most important characteristics of pDOOML. This chapter is not intended as a reference manual for the pDOOML language, but as a description aiming at proving its concepts. So, we do not describe every detail of its syntax and semantics, but only those that are necessary to prove that it is possible to build an O-O language like pDOOML for modeling planning domains.

5.1

pDOOML: The Language

As in O-O programming when specifying a class we can declare that it inherits from another previously specified class. We have three top classes from which all other classes necessarily inherit: SORT, STATEVAR and OBJECT. The heirs of SAS SORT are classes that when translated specify the various sorts of CSTRIPSsorts and the domain of the state variables. The heirs of STATEVAR are used to SAS declare the various state variables of CSTRIPSsorts . The heirs of OBJECT are SAS used to declare the various objects of the CSTRIPSsorts Object-Domains. The pDOOML three top classes generate three genealogies of classes without crossbreeding, i.e. it is not possible to create a class by inheriting from classes belonging to more than one genealogy. First we start explaining the language dealing with the heirs of the class OBJECT. Later, in Section 5.1.7, we introduce the other two top classes and their heirs. We design pDOOML as a strongly typed language, and use the notation usually used in O-O programming to represent this, i.e. the various represent the various types that can be used; when declaring parameters we declare its associated type and every time we pass an object as an argument it needs to match the type of the parameter; an assignment is only valid between objects of the same type; etc. As a convention, we use bold for the keywords of the language, UPPERCASE for classes identifiers, and enclose inside for constructs of the syntax as or .

5.1.1

Declaring a class

As in any O-O programming language we specify everything by specifying classes. The declaration of a class consists of three parts: its header, its interface and its body. The header specifies the name of the class, the external suppliers (i.e. suppliers created by other classes) and the ancestors of the class. The class interface declares the public part of the class that is

5.1. PDOOML: THE LANGUAGE

139

accessible by the classes that uses it, i.e. its clients. The class body declares the private part of the class, accessible only inside the class declaration itself. The declaration of the interface is subdivided into various blocks by the following keywords: readwrite, readonly, functions and objects. In the readwrite and readonly blocks we declare the state variables that are respectively read-write and read-only 1 . Inside the functions we declare auxiliary functions that can be used in the threads of the class and in those of its clients. In the objects block we declare all the object suppliers of this class that the class itself creates. These suppliers can be accessed by the class and its clients. The declaration of the body is also subdivided into various blocks by the following keywords: functions, hidden, objects and threads. Inside each of these blocks we specify all the internal features of the class. In the block functions we declare auxiliary functions that only the threads of the class can use. Inside hidden it is declared the hidden data of the class, accessible only by its own threads. The body’s objects block declares all the object suppliers of this class that the class itself creates. These suppliers are private to the class, only the class can access them. We use the word feature to refer to any of them in general. When a block is empty it is not necessary to write its associated keyword. Inside the threads block we can declare only thread features with the following syntax: thread = ; Inside the functions block we can declare only function features with the following syntax: (); Inside all other blocks we use the following syntax to declare its various features: ; When more than one feature is of the same we can write: < f eaturename1 >, . . . , ; In this last case we say that the is the type of the feature. Any block can contain only certain types of features. The blocks readwrite, readonly and hidden contain only features of a type that is an heir of STATEVAR. The block objects contains only features of a type that is an heir of OBJECT. The block functions contains only features of a type that is 1

These state variables are read-only for the clients of the class, not for the class itself.

140


an heir of STATEVAR and the same is true of the that appears inside the part. The threads block can contain only features of thread type. We now describe an example of how the declaration of an heir of OBJECT is done. Suppose SCi (for any i in N) is a class heir of Sort and that OCi (for any i in N) is a class heir of Object. The declaration of the class A that we show below specifies a class such that: (1) it has two read-write data a and b, respectively of sort SC1 and SC2 ; (2) it has two read-only data c and d, respectively of sort SC3 and SC4 ; (2) it has two hidden data e and f , respectively of sort SC5 and SC6 ; (3) it declares as its suppliers two external objects O1 and O2 respectively of class OC1 and OC2 ; (4) it creates and declares as its suppliers two objects O3 and O4 respectively of class OC3 and OC4 ; (5) it declares two thread features T 1 and T 2; (6) it declares the data s1 and s2 of sort SC0 as external; and (7) it declares OBJECT as its ancestor. When creating an object using this class we need to pass two interface data of the corresponding types in the places of s1 and s2 that declared as external data. It is worth highlighting that (6) implies the addition of the objects whose interface data is passed into the list of suppliers of the object created. About (5) we note that a thread specification has a syntax similar to that of a thread in CSTRIPS but restricted to use certain state variables in a form we detail later. class A(OC1 O1; OC2 O2; SC0 s1, s2) : OBJECT { interface : readwrite : SC1 a; SC2 b; readonly : SC3 c; SC4 d; body : hidden : SC5 e; SC6 f ; objects : OC3 O3; OC4 O4; threads : thread T 1 =; thread T 2 =; }


5.1.2

141

Inheritance

We now explain with an example how the inheritance mechanism works. We declare the ancestors of a class after its name and external suppliers list, separating them with a semicolon. The declaration of class B that we show below specifies a class such that: (1) it inherits all the features of class A; (2) it overrides the feature a making it now of the sort SC7 ; (3) it adds another feature g of sort SC7 to the read-only data; (4) it overrides feature e of the hidden data; (5) it adds another feature h to the hidden data; (6) it declares as its suppliers three external objects O1, O2 and O5 respectively of class OC1 , OC1 and OC2 ; (7) it specifies that the two objects declared as external objects by A are respectively O1 and O5; and (8) it specifies that the two data declared as external by A are respectively s1 and s2. class B(OC1 O1, O2; OC2 O5; SC0 s1, s2) : A(O1, O5, s1, s2) { interface : readonly : SC7 a; SC7 g; body : hidden : SC8 e; SC8 h; }

An equivalent B declared without inheriting from class A is declared as: class B(OC1 O1, O2; OC2 O5; SC0 s1, s2) : OBJECT { interface : readwrite : SC7 a; SC2 b; SC7 g; readonly : SC3 c; SC4 d; body : hidden : SC8 e; SC6 f ; SC8 h;

142


objects : OC3 O3; OC4 O4; threads : thread T 1 =; thread T 2 =; }

Renaming and replicating features. As usual in O-O to avoid name conflicts we rename the inherited features. We use the clause rename . . . as . . . for this. To replicate some inherit features we use the clause clone . . . as . . .. We use the clause remove . . . to eliminate an inherit feature. We access the features of the ancestors using the class name and a dot, i.e. ANCESTORNAME.f eature. All these clauses go between the declaration of the ancestors and the start of the declaration of the features of the class. We exemplify this below by writing a variant of the previous class B called B0 . class B0 (OC1 O1, O2; OC2 O5; SC0 s1, s2) : A(O1, O5, s1, s2) clone A.a as j; rename A.a as k; remove A.O3; { interface : readonly : SC7 a; SC7 g; body : hidden : SC8 e; SC8 h; }

An equivalent B0 declared without inheriting from the other classes is declared below. Notice that now we have not lost the original feature a of class A. It appears in B0 under the name k. Also this feature has been replicated, and we have an identical feature named j. And O3 is no longer a feature of B0 . class B0 (OC1 O1, O2; OC2 O5; SC0 s1, s2) : OBJECT { interface : readwrite : SC1 j; SC1 k; SC7 a;


143

SC2 b; SC7 g; readonly : SC3 c; SC4 d; body : hidden : SC8 e; SC6 f ; SC8 h; objects : OC4 O4; threads : thread T 1 =; thread T 2 =; }

Multiple inheritance. A class can heir from more than one class. Suppose we have a class A’ that inherit directly from OBJECT and has the same features as the first version of B, i.e.: class A’(OC1 O1) : OBJECT { interface : readonly : SC7 a; SC7 g; body : hidden : SC8 e; SC8 h; }

Another form of declaring class B is simply by inheriting from both A and A’ and removing the features a and e of the latter. When we declared B as inheriting only from A on page 141 these features have been overwritten by the declaration of B, and hence, we need to remove them now. class B(OC1 O1, O2; OC2 O5; SC0 s1, s2) : A(O1, O5, s1, s2), A’(O2) remove A.a; remove A.e; { }

144


5.1.3

The accessible features

When specifying the threads of a class we need to refer to state variables and functions, exactly as in CSTRIPS. The accessible data features we can use when declaring the threads of a class are: (1) all the data features (read-write, read-only and hidden) declared in the class, (2) all the data features declared in all the ancestors of the class, and (3) all the data features in the interfaces of the suppliers of the class (both those created inside the class and those external). Only those in (1) and those in the read-write parts of the suppliers can be modified, i.e. we can assign values only to them. We call them the modifiable data features. Finally, there are some function features that can be used. The accessible function features are: (1) all static function features of any class (see Section 5.1.6), (2) all the function features declared in the class, (3) all the function features declared in the ancestors of the class and (4) all the function features declared in the interfaces of the suppliers of the class. We refer with accessible features to both accessible data features and accessible function features. The notation to access the features of the suppliers objects is the one used in O-O Programming, a dot added after the name of the object and then the name of the feature. For example, suppose we have declared the class A introduced on page 140, and now we declare another class C as below. Suppose also that the classes OC1 and OC2 have neither data nor functions in their interfaces. class C(SC1 s00 ) : OBJECT { interface : body : hidden : SC0 s, s0 ; objects : OC1 O; OC2 O0 ; A OA(O, O0 , s, s0 ); threads : thread T 1 =; }

The accessible data features inside the specification of the thread T 1 are: OA.a, OA.b, OA.c, OA.d, s, s0 , and s00 . From those seven, only five are modifiable: OA.a, OA.b, s, s0 and s00 , and so, only these five can be assigned in the add list of the operators of the thread T 1. The first four are features


145

of the object OA, while the last two are declared inside the class C. But we cannot access the other features of OA, like e or O3, because they are not part of the interface. From the previous four features we can access, we can assign values only to the first two that are declared in the readwrite part of the interface of A. We cannot assign values to those features, like OA.c or OA.d that appear in the readonly part of A. We can only “read” their values, i.e. we can use them only in the operators’ precondition of the thread T 1. The only accessible function features are those static. Due to the fact that the heirs of STATEVAR always have a unique read-write data, it is convenient to use the following convention when assigning a new value to it 2 . Suppose we declare in a class a data as INTEGER i. Afterwards, we write directly i := 10 instead of i.value := 10. In pDOOML, as in the previous chapters of this dissertation, we use the symbol “ :=00 to denote assignment. Declaring exclusive modification rights for a feature. In the above declaration of class C, by declaring s and s0 in the hidden block of the body, we state that these two features are accessed and modified exclusively by the threads of C. Also the object features O and O0 inside the body blocks are accessed and modified exclusively by C. By declaring a data feature in the readwrite block of the interface we state that the clients of that class can access and modify those features, e.g. features a and b of class A in Section 5.1.6. By declaring a data feature in the read-only block of the interface we state that the clients of that class can access but not modify those features, e.g. features c and d of the same class A. These data are read-only for the clients of the class, not for the class itself. We exemplify below how to state in pDOOML that an external feature or an external class (meaning all the features in the interface of that object) are used exclusively by the threads of the class. We declare a class C’ with two objects O and O0 and two state variables s and s0 as external. With the keyword ex we declare both objects and the state variable s0 of its exclusive use for modification. class C’(ex OC1 O, O0 ; SC1 s, ex s0 ) : OBJECT { ... threads : thread T 1 =; }

2

A similar convention is usual in O-O programming with the classes that represent basic types.

146


5.1.4

Abstract classes, deferred and constant features

A thread or a function feature of a class can be declared as deferred meaning that there is no definition of what the thread or the function actually does. The real definition of the feature has been deferred to the heirs of that class. When a class has a deferred thread or function feature we say that it is abstract. An abstract class cannot be used to declare features of other classes. They are used only as ancestors. Any heir of an abstract class inherits the deferred features and if it does not override them with new features it also becomes abstract. Hence, an heir of an abstract class becomes not abstract only when overwriting all the deferred features for implemented ones. A feature is declared constant when its value cannot be modified after the object associated to the class is created. When a feature is constant it cannot be assigned once an object of that class has been created. The following is an example of an abstract class with a constant feature, a deferred function and a deferred thread. class ABS { interface : readonly : constant SC2 f := < initvaluedeclaration >; functions : deferred SC1 f 1(SC2 x); threads : deferred thread T 1; }

5.1.5

Specifying threads

A thread specification has a syntax similar to that of a thread in CSTRIPS but restricted to use only accessible features. We now explain how to specify the thread T 1 of the class C described on page 144. We assume that all the accessible data of this thread, i.e. OA.a, OA.b, OA.c, OA.d, s, s0 and s00 , are heirs of INTEGER. Suppose we want the thread to have only two operators, named respectively Op1 and Op2. The former has as a precondition that the accessible data OA.a is greater than 10 and that the accessible data s is equal to 100. Its effect is to assign OA.a − s + x to the modifiable data OA.b. The latter has as precondition that OA.c − x are less than 1000. In that case its effect is to assign to the modifiable data OA.a that sum.


147

threads : thread T 1 = { (Op1(INTEGER x) : {(OA.a > 10), (s = 100)} ⇒ {(OA.b := OA.a − s + x)}), (Op1(INTEGER x) : {(OA.c − x < 1000)} ⇒ {(OA.a := OA.c − x)}) }; ...

5.1.6

Declaring functions

We now explain the functions block of the classes. Suppose we declare the following two classes D and E: class D : OBJECT { interface : functions : external SC1 f 1(SC2 x); body : functions : external SC2 f 2(SC1 x; SC2 y); } class E : OBJECT { interface : functions : external SC2 f 3(SC3 x); body : hidden : ... objects : D OD; functions : SC4 f 4(SC3 x, y) = { OD.f 1( f 3(x), f 3(y) ) }; threads : thread T 1 =; }

In this case, inside the specification of the thread T 1, we can use only the functions OD.f 1, f 3, f 4 and all the static functions. We cannot use the function f 2 of object OD because it is not declared inside its interface. We introduce static functions in the next paragraph. The keyword external means that we only give the signature of the functions and do not declare

148


how they actually are computed. Recall that the semantics of pDOOML is given by a translation to another language — the language to specify ObjectSAS Domains in CSTRIPSsorts — and so, by declaring a function as external we are just saying that the function is already present in the target language. Notice that in the previous chapters, when dealing with the TOT and SOT examples, we assumed exactly this, that the current implementation of the common functions and operators we used was already given. The function f 4 is not declared as external, and so, the specification of what that function computes is given in the block after the “=” symbol. The syntax SC2 f 3(SC3 x); specifies that function f 3 parameter is of type SC3 and returns a value of type SC2 . Notice that we can call the function f 3 with the parameters x and y of function f 4 because they are of type SC3 that is required by f 3. Then we can use the outputs of f 3 to call the function f 1 of object OD because they are both of type SC2 that is required by that function. There is also another keyword that is used only when declaring functions inside the interface block. In general a function is declared as static when it can be computed without any reference to the dynamic values of the class in which it is declared. The value can only be computed by using the features of the class declared as constant and its parameters. These static functions then can be called inside the declaration of every thread as if they were globally accessible. For example, if we have declared a class G as below: class G : OBJECT { interface : functions : external static SC3 f 3(SC4 x, y); }

Inside the specification of the thread T 1 of the previous class E, we can use also the static function G.f 3 even if the class E is not a supplier of any object of class G. In fact, notice that G is the class name, not an object identifier. When specifying a thread or function we need to pass the actual object as an argument when calling a function we use the keyword this.

5.1.7

The heirs of SORT and STATEVAR

We have explained how to specify the heirs of the class OBJECT that we use to model the objects of the Object-Domains. We now explain how to specify the heirs of the other two top classes SORT and STATEVAR. As we said, we use the heirs of the former to specify sorts and the domains of the state variables, and


149

the latter to specify the state variables themselves. The classes of the SORT genealogy are further restricted not to declare features of a class belonging to any of the other two genealogies. The classes of the STATEVAR genealogy can declare features of classes belonging to the SORT genealogy but not of classes belonging to the OBJECT genealogy. Every class in the SORT genealogy always has a unique data feature named value that represents the domain of the state variable of that sort. The heirs of the class STATEVAR in pDOOML take a role similar to that of the basic types of the O-O programming languages (usually built-in classes). Every heir of the class STATEVAR always has two data features: value and domain. The former represents the actual value of the state variable. The latter is any heir of SORT that specifies the domain of the state variable. So, the heirs of SORT are used to specify the heirs of STATEVAR, and the heirs of STATEVAR to specify the heirs of OBJECT. Due to the fact that both the heirs of SORT and STATEVAR have different syntactic restrictions, we use two new keywords to identify them: sortclass and svclass, instead of using class that we reserve only for those heirs of OBJECT. Even if this is not strictly necessary, using these keywords when declaring a class helps humans distinguish between the three without backtracking all the genealogy until discovering which of the three top classes is the ancestor. We show below the declaration of the three top classes, but for the general purpose static functions that we do not represent: class OBJECT { } sortclass SORT { interface : readonly : deferred constant SORT value := EMPTYSET; } svclass STATEVAR { interface : readwrite : deferred STATEVAR value; readonly : deferred constant SORT domain; }

150


Notice that the last two top classes SORT and STATEVAR are abstract, because they both contain deferred features.

5.1.8

A general purpose library of state variables

One of the great advantages of having an O-O modeling language for planning domains is that this language is highly modular. We can build a general purpose library in order to avoid the repetition of the specifications that are always used, and also to increase the reusability of the modeling effort. Due to the fact that most sorts and state variables classes are derived from a few basic ones, like for example those that represent the integer and real numbers, these classes are perfect candidates for the general purpose library. In fact, as we said above, the heirs of the class STATEVAR in pDOOML take a role similar to that of the basic types of the O-O programming languages. These basic types are usually an essential part of the general purpose library. Furthermore, they are usually built-in classes. We describe below a few classes of this general purpose library of pDOOML that we need to use later when modeling the TOT and SOT domains. First, we list BOOLEAN, a class for state variables with boolean values and its associated sort class BOOLEANSET. Notice that most common boolean operators are defined as external static functions. sortclass BOOLEANSET : SORT { interface : readonly : constant BOOLEANSET value; } svclass BOOLEAN : STATEVAR { interface : readwrite : BOOLEAN value; readonly : constant BOOLEANSET domain; functions : external static BOOLEAN not(BOOLEAN x); external static BOOLEAN infix or(BOOLEAN x, y); external static BOOLEAN infix and(BOOLEAN x, y); ... }

Second, we list INTEGER, a class for state variables with integer values, and its


151

associated sort class INTEGERSET. Notice that most common operators of the integer numbers are defined as external static functions. Notice the presence of the static functions In(INTEGER x) and Subset(INTEGER x, y); in the class INTEGERSET. The former returns true only when x is inside the set of values represented by the class INTEGERSET. The latter is used to derive new heirs of INTEGERSET with a restricted range of values as we explain below. Notice that function In(INTEGER x) is defined also for the class INTEGER, based on its definition in class INTEGERSET. sortclass INTEGERSET : SORT { interface : readonly : constant INTEGERSET value; functions : external static BOOLEAN In(INTEGER x); external static INTEGERSET Subset(INTEGER x, y); ... } svclass INTEGER : STATEVAR { interface : readwrite : INTEGER value; readonly : constant INTEGERSET domain; functions : static BOOLEAN In(INTEGER x) = {domain.In(x)}; external static INTEGER infix + (INTEGER x, y); external static INTEGER infix − (INTEGER x, y); external static INTEGER infix /(INTEGER x, y); external static INTEGER infix ∗ (INTEGER x, y); external static INTEGER infix >= (INTEGER x, y); external static INTEGER infix (INTEGER x, y); external static INTEGER infix < (INTEGER x, y); ... }

Third, we introduce a notation that can be used to derive a new class by inheriting from any heir of SORT that has a Subset(INTEGER x, y) function,

152


like the class INTEGERSET, and change its range of values using this function. The class INTSET10 declared below is exactly like INTEGERSET but reduced to the integers from 0 to 10. sortclass INTSET10 : INTEGERSET[0, 10]{}

The previous declaration is a shortcut for3 : sortclass INTSET10 : INTEGERSET { interface : readonly : constant INTSET10 value := INTEGERSET.Subset(0, 10); }

Fourth, we introduce a notation that can be used to derive a new class by inheriting from any heir of STATEVAR and change its domain. The class INT10 declared below is exactly like INTEGER but its domain is reduced to the integer values between 0 and 10, i.e. those in INTSET10. svclass INT10 : INTEGER[INTSET10]{}

The previous declaration is a shortcut for: svclass INT10 : INTEGER { interface : readonly : constant INTSET10 domain; }

Finally, we list INTUNDEF, a class for state variables with integer values plus the undefined value ⊥, and its associated sort class INTUNDEFSET. We need this class because the tank Level state variables can have an ⊥ value not included in the above INTEGERSET. We use undef in pDOOML instead of ⊥ with exactly the same meaning. sortclass INTUNDEFSET : INTEGERSET { interface : readonly : 3

We assume that the static functions In and Subset defined in INTEGERSET are defined in such a way that they work properly over heirs of INTEGERSET with a reduced set of values as INTSET10.


153

constant INTUNDEFSET value := AddElement(“undef 00 ); functions : external static BOOLEAN In(INTUNDEFSET x); external static INTUNDEFSET Subset(INTEGER x, y); ... }

svclass INTUNDEF : INTEGER { interface : readwrite : INTUNDEF value; readonly : constantINTUNDEFSET domain; functions : static BOOLEAN In(INTUNDEF x) = {domain.In(x)}; external static INTUNDEF infix + (INTUNDEF x, y); external static INTUNDEF infix − (INTUNDEF x, y); external static INTUNDEF infix /(INTUNDEF x, y); external static INTUNDEF infix ∗ (INTUNDEF x, y); external static INTUNDEF infix >= (INTUNDEF x, y); external static INTUNDEF infix (INTUNDEF x, y); external static INTUNDEF infix < (INTUNDEF x, y); ... }

Notice that these classes inherit respectively from INTEGERSET and INTEGER. The class INTUNDEFSET overrides the declaration of the Subset(x, y) function, because now this function is used to derive heirs of INTUNDEFSET with a restricted range of values but keeping the undefined value undef . The class INTUNDEF overrides its domain feature for one of INTUNDEFSET class and overrides all the functions such that now they accept as argument not only integers but also undef 4 . The observations we made above about the function In are also valid for this case. Both classes override the feature value with one of its own class.

4

The external functions against which these functions are mapped are different. The new ones handle the undefined symbol undef and return it if any of the arguments is undef .

154


5.1.9

An array of state variables

pDOOML has a special notation to specify features that are array of other features. Particularly, we explain this for the case of an array of state variables, i.e. an array of features whose type is an heir of STATEVAR. We now exemplify this by declaring a class G that declares in its hidden block a feature named barr that is an array of eleven state variables of type BOOLEAN. To declare barr we write: BOOLEAN[INTSET10] barr;. We used the class INTSET10 declared in the previous section. This class is an heir of the class INTEGERSET but restricted to contain only the range from 0 to 10. The cardinality of INTSET10 defines the number of elements of the array barr; the actual numbers in INTSET10 define the valid indexes for accessing the eleven elements of the array. So, to access the eleven elements of the array feature barr we write barr[0], . . . , barr[10]. Below we use this notation writing barr[index] in the declaration of thread T 1. It is also possible to use the function BOOLEAN In(INTEGER x); that appear in the declaration of INTEGERSET as static function (see Section 5.1.8). So, we can write barr.In(index) for any index feature of type INTEGER to check if index is inside the right range of integer values for access the elements of barr. For the present example this is equivalent to write 0

The planning problem in AI: Structuring domains and

The planning problem in AI: Structuring domains and

Suggest Documents

Problem structuring in transport planning: Cognitive mapping

GETTING TO THE AIRPORT: THE OLDEST PLANNING PROBLEM IN AI

AI Planning: Systems and Techniques1

Problem structuring - Good Better Best

On evaluating the performance of problem structuring

Problem Structuring and MCDA - School of Education

DOMAINS: A FRAMEWORK FOR STRUCTURING MANAGEMENT ...

Structuring the Transition From Example Study to Problem Solving in ...

Evaluation of Representations in AI Problem Solving

Structuring of the AÃ§ai Pulp Exporting Agribusiness ... - RBGN - Fecap

AI Planning in a Chemical Plant Domain

AI Planning in Web Services Composition - CiteSeerX

Replication of the Hard Problem of Consciousness in AI and Bio-AI: An ...

Projection Global Consistency: Application in AI Planning

Genetically Evolved Macro-Actions in AI Planning

AI-based movement planning for autonomous and

AI Techniques for Planning Telecommunication

STRATEGIC MANAGEMENT Problem structuring methods - DTU ETD

Sustainability assessment as problem structuring - Maastricht University

Technological Roadmap on AI Planning and Scheduling

THE CURRENT STATE OF AI PLANNING

Adversarial Planning in Complex Domains - Semantic Scholar

Solving the Path Planning Problem in Mobile

Forward-Chaining Planning in Nondeterministic Domains