a library of system-derived problem-solving methods for planning

Int. J. Human—Computer Studies (1998) 48, 417—447

A library of system-derived problem-solving methodsfor planning

ANDRE VALENTE

University of Southern California, Information Sciences Institute 4676 Admiralty Way,Marina del Rey, CA 90292, USA. e-mail: [email protected]

V. RICHARD BENJAMINS

Artificial Intelligence Research Institute (IIIA), CSIC, Campus UAB, 08193 Bellaterra,Barcelona, Spain. e-mail: [email protected] and University of Amsterdam, SocialScience Informatics (SWI), Roetersstraat 15, 1018 WB, Amsterdam, The Netherlands.e-mail: [email protected]

LELIANE NUNES DE BARROS

Department of Electrical Engineering, Universidade de SaJ o Paulo, SaJ o Paulo, SP-Brazil.e-mail: [email protected]

Constructing a planner for a particular application is a difficult job, for which littleconcrete support is currently available. The literature on planning is overwhelming andthere exists no clear synthesis of the various planning methods which could be used byknowledge engineers. The contribution of this paper concerns an approach to provideconcrete support for engineering planning systems. We use modern knowledge modelingapproaches to analyse planning systems described in the literature. The analysis yieldsa detailed description of these planning systems in terms of the domain knowledge theyuse and the problem-solving methods they comprise. We show how the result of theanalysis can be considered as a library of system-derived problem-solving methods forplanning. This library consists of planning problem-solving methods along with theirassumptions, which describe the applicability conditions on the domain knowledge of themethods. We describe how the library supports knowledge engineers in building plann-ing systems and present two implemented tools based on the approach.

( 1998 Academic Press Limited

1. Introduction

Several libraries of problem-solving methods have been developed in recent years,stemming in large part from the KADS-I library of interpretation models (Breuker, 1987).Many of these libraries, such as the COMMONKADS Library (Breuker & van de Velde,1994), are broad, comprehensive efforts in which methods are assembled for a variety oftypes of problems. Other libraries focus on a specific type of problem, such as diagnosis(Benjamins, 1995). Although these libraries employ different organizations and havesomewhat different scopes, they have in common an attempt to store a number ofmethods for being reused in developing knowledge-based systems.

This paper presents a library of problem-solving methods for solving planning prob-lems. The methods in the library were obtained by describing planning methods avail-able in the AI literature, which characterizes our library as system-derived, as opposed to

1071-5819/98/040417#31$25.00/0/hc970192 ( 1998 Academic Press Limited

418 A. VALENTE E¹ A¸.

domain-derived libraries in which methods are developed by abstracting from problem-solving strategies employed in application domains (Cottam & Shadbolt, 1996).

Developing a library of planning methods by collecting them from the AI literaturemay seem at first an easy task. After all, planning is one of the oldest and moreextensively developed research areas in AI, and literature abounds. However, thisabundance turns out to be a problem. Contrary to what one would expect in sucha traditional field, there exists no clear synthesis available of the available methods andtheir applicability. Further, most of the methods are described in terms of search, whichoffers little help in understanding the applicability of the method to a certain domain.The few analyses of the existing methods have concentrated on characteristics such asefficiency, soundness and completeness and expressiveness—which may be important tocompare the efficiency of different planning algorithms, but help little in constructing anapplication.

Therefore, in addition to its standard role as a tool to help in engineering a knowledge-based system, the library has another important role. It can be seen as a framework forrepresenting and analysing planning methods. The library defines a number of compo-nents (knowledge roles and basic methods) to describe planning methods in a commonlanguage which makes it possible to map, classify and compare different methods.

The library describes the planning methods in terms of a number of knowledgemodeling components inspired on the COMMONKADS framework (Schreiber, Wielinga,de Hoog, Akkermans & Van de Velde, 1994) and also related to the work of Chandra-sekaran, Johnson and Smith (1992) and Steels (1990). These components adopta division in two layers. In the domain layer, a set of typical knowledge roles characterizethe main types of domain knowledge used in planning methods. They also help inunderstanding the way knowledge is structured by providing an index to the domainmodels used to play these roles. In the task layer, a task-method decomposition structureindexes a set of basic methods by defining in what ways a planning task can bedecomposed (what we will call task structures), and what decomposition results fromapplying the basic methods to those tasks. Detailed control knowledge is later added tothese decompositions by means of control structures. The task-method decompositionstructure proposes a characterization of planning methods in general, as distinct realiz-ations of a basic decomposition of the planning task into three tasks: propose, critiqueand modify (Chandrasekaran, 1990). In order to connect the domain with the task layer,a set of assumptions (or features) is used to specify when a method is applicable toa domain or a problem, and vice versa.

Currently, the library concentrates on the so-called classical planners, which impliesthat it inherits their limitations and behavioral assumptions. For example, it assumesthere is a single agent; changes in the world can only be caused by the agent; actions donot take time to be performed; etc. The library can, however, naturally be extended tocomprise other types of planners (e.g. case-based, planners that use uncertainty) as well asmethods for other types of planning problems (e.g. plan execution, plan recognition).

This paper provides an overview of the library and discusses how it can be used toengineer planning systems. Earlier versions of (parts of ) the library presented in thispaper were discussed in Valente (1995), Benjamins, Barros and Valente (1996), Barros,Valente and Benjamins (1996) and Barros, Hendler and Benjamins (1997). In Valente(1995), we discussed in detail the knowledge roles and domain models. In Barros et al.

PROBLEM-SOLVING METHODS FOR PLANNING 419

(1996), we concentrated on the basic methods and the task-method decompositionstructure. In Benjamins et al. (1996), we extended the coverage of the library, and focusedon the knowledge acquisition benefits of the library, by concentrating on the assumptions.In Barros et al. (1997), we focus on the extension of these methods to include controlknowledge.

This paper is structured as follows. In Section 2, we briefly describe the frameworkused to represent the methods. Section 3 summarizes the domain part of the library, viz.the knowledge roles and domain models. Section 4 describes the task part of the library,namely the task-method decomposition tree and the basic tasks and methods it com-prises. In Section 5, we describe how our library can support the knowledge acquisitionprocess. Two kinds of support are demonstrated: (1) given a description of domaincharacteristics, finding what possible planners are adequate for the domain, and (2) givena planner, defining its assumptions (domain requirements). This support was partiallyautomated, first with the help of the general tool TIN A (Benjamins, 1994, 1995) and laterwith the construction of a specialized tool called PAR-KAP (Barros et al., 1997). InSection 6, we present our conclusions.

2. A framework for representing and storing the methods

The planning methods in our library are represented in a framework inspired on theCOMMONKADS knowledge modeling framework (Schreiber et al., 1994). Problem-solv-ing methods are described in terms of tasks, task structures, control structures, domainmodels and assumptions.

¹asks are specified by an input/output relation plus a goal. We present the input andoutput of tasks by roles that knowledge plays in problem solving. For instance, an inputor output role like hypothesis means that some domain knowledge plays the role ofhypothesis for the task during the reasoning process. Tasks may also refer to knowledgestructures which are used but whose contents do not change during problem solving;these structures are the static roles. In contrast, input and output roles are dynamic roles(static roles are not considered to be input). Static roles are analogous to knowledgebases in knowledge-based systems.

¹ask structures specify a hierarchical decomposition of tasks into sub-tasks. Each taskin a task structure can be decomposed again, creating a layered task structure. Taskstructures make no detailed commitment to control, e.g. which task should be executedfirst. Some tasks are considered primitive, in that they are supposed to be implementedor implementable using some inferencing mechanism. Figure 1 presents a graphicaldisplay of a task structure in which a general task called planning is decomposed intothree tasks: propose refinement, critique plan and modify-plan.

Control structures are basically a group of control statements that express what is thecontrol regime of a certain task structure: in which order the tasks will be executed, etc.Control structures are said to impose control on a specific task structure. Below is onepossible control structure for the task structure shown in Figure 1.

1. Propose-refinement backtracking-point and exit-point,2. Select-goal backtracking-point.3. Propose-expansion backtracking-point.

FIGURE 1. Graphical display of a task structure.


4. Test-for-unachieved-goals exit-point.5. Critique-plan fail-point.6. Consistency-critique fail-point.7. Interaction-critique.8. Modify-plan backtracking-point and cond: (conflictOempty). Control ordering:

(5 is-before 8) and (2 is-before 3) (3 is-before 4).

Domain models are structures that use elements of domain knowledge to be used inproblem-solving methods. Typical examples are models that specify causal dependenciesbetween symptoms and diseases in medical domains (causal model), or models thatspecify structural hierarchies for physical devices (structural models). The term is used inthe meaning proposed in KADS, i.e. a structure containing some elements of domainknowledge. In the specific way they are used in this paper, domain models are similar tothe method ontology in PROTEGE (Gennari, Tu, Rotenfluh & Musen, 1994).

Assumptions. There is an intrinsic interdependency between domain knowledge (know-ledge roles and domain models) and task knowledge (tasks, task structures, controlstructures). A choice in the space of possible tasks to solve a given problem imposeslimitations in choices in the space of domain models to represent the domain knowledgeabout that problem, and vice versa. This is due to the fact that a choice in one spacerequires assumptions with respect to elements in the other space (Aamodt, Benus,Duursma, Tomlinsen, Schrooten & Van de Velde, 1992). In order to know whether a taskstructure can be used in a given application domain, the domain must guarantee thatthese assumptions are fulfilled. The other way around, characteristics of the domain maylimit the possible planning task structures to be used.

In this paper, we distinguish three main types of assumptions. First, availabilityassumptions (Benjamins & Pierret-Golbreich, 1996) require the availability of a certaintype of knowledge to operate. In terms of the library developed here, this means thatknowledge must be available to fill a certain static role. Second, property assumptionsmay specify particular requirements about the specific domain models that will fill thestatic roles. For example, certain planning methods assume that knowledge can be


structured in a hierarchical task network. Third, specific methods may require not onlythat knowledge is available and can be meaningfully structured in certain domainmodels, but also that it fulfils certain additional requirements. For instance, certain typesof planners that use causal links require not only that these links are available but thatthey form a complete casual theory. To this third type belong also the importantassumptions related to the pragmatic characteristics of the methods, like system require-ments, efficiency, etc. This last type of requirement will not be investigated in this paper,and will be the subject of further research.

3. Characterizing how planners use and structure domain knowledge:knowledge roles and domain models in planning

Despite the emphasis on efficient search algorithms, the planning literature shows thatequally important is the smart use of some knowledge structures—in our terminology,domain models. For instance, the basic advantage of ABSTRIPS (Sacerdoti, 1974) over STRIPS

(Fikes & Nilsson, 1971) lies not in their search methods, which are highly similar, but inthe use by ABSTRIPS of a representation of the world using ‘‘levels of criticality’’ associatedwith the operator’s precondition to reflect their importance in the planning process.ABSTRIPS (and the so-called hierarchical planning approaches in general) shows that a wellorganized and structured domain model can decrease the planning work. Therefore, weclaim that an analysis of the domain models used in planning should play a central partin understanding, evaluating and describing planning methods.

We propose that the analysis of domain models used in planning should be based onthe roles they play in problem solving, i.e. the static roles in the planning methods. Wedescribe in this section a set of basic static roles organized in a part-of hierarchy. Theseroles provide a basis for describing what types of knowledge a planning method employs.We will use this typology to classify some of the main domain models proposed in theplanning literature. Also, we will describe a number of basic dynamic knowledge roles thatare used in describing the knowledge that is input or output to the task. It is important toobserve that the characterization of planning domain models presented in this sectioncontains elements that are not actually used in the method library we propose in Section4. This occurs because the library concentrates so far on classical planners, that, forexample, do not make use of the role meta-planning knowledge. In the future, wewill incorporate other classes of planning methods [e.g. O-P LAN (Currie & Tate, 1991),and the skeletal plan refinement method of Friedland and Iwasaki (1985)] for which allthe roles in the typology will be necessary.

3.1. STATIC ROLES IN PLANNING

Figure 2 shows a part-of organization of static roles (Valente, 1995). Each decompositionin the tree means that a given planning method has a choice of either using a domainmodel that plays the parent role (e.g. world description) or using separate domainmodels for each of the children (e.g. state description and state changes) thattogether perform the parent role. That is, planning methods choose how much theydifferentiate roles of knowledge in solving the problem, but the choices are constrained inpart by the relationships shown in the tree. For example, one can only differentiate plan

FIGURE 2. Part-of tree of static roles in planning.


description into plan structure and plan assessment knowledge (thoughnot necessarily both; plan assessment knowledge is frequently omitted). There arealso interdependencies within the same level, which are not shown in the part-of tree. Forexample, one cannot have a model for state changes without a model for statedescription. These interdependencies will be discussed below. It is important tonotice that sometimes, in method descriptions in the literature, the model for one of theroles in such a pair of interdependent roles may be implicit or described in lessdetail—and, in fact, one of the powerful advantages of this way to structure roles is toalert the engineer for the existence and importance of the other, related, role.

The top elements of the tree are two basic roles. First, the plan model role defineswhat a plan is and what it is made of. It consists of two parts: the world descriptiondescribes the world on which the plan is executed, and the plan descriptiondescribes the abstract structure of the plan being constructed. Second, the meta-planning knowledge role comprises knowledge about the planning process—asopposed to knowledge about the plan, which is in the plan model. Since most plannersdo not reason or have explicit representations of the planning process, our attention willbe concentrated in detailing the plan model. Below we will describe these roles, theirsub-roles, and describe a number of domain models proposed in the planning literaturethat perform each role.

3.1.1. World descriptionThe world description role describes the world about which we are planning and

comprises two sub-roles: state description and state changes. The statedescription role contains the knowledge necessary to represent or describe the stateof the world. Examples of domain models to play this role in planning systems are a set offirst-order predicates (STRIPS-like) or a set of fluents from the Situation Calculus (Mc-Carthy & Hayes, 1969). The state changes role comprehends all the informationconnected to the specification of changes in the state of the world. This role also containsthe specification of the elements that compose a plan. (but not how they are composed,see plan composition below). Examples of domain models to play this role inplanning systems are: the add-delete lists (ADL) used in STRIPS (Fikes & Nilsson, 1971); orthe hierarchical task networks (HTNs) (Tate, 1977), (Erol, Hendler & Nau, 1994) which are,


in fact, descriptions of sub-plans; or skeletal plans (Friedland & Iwasaki, 1985) which areabstract descriptions of previously generated plans. In case of HTNs, the sub-plans maycome fully or partially specified. Fully specified means that the sub-plans contain all theauxiliary constraints necessary for continuing the planning process (e.g. ordering con-straints or truth constraints such as causal-links). Partially specified means that thesub-plans come with a correct and useful decomposition of the plan goal but not with allthe needed causal links (see McAllester & Rosenblitt, 1991) for a real-world planningapplication. The state change data role contains additional data about the statechanges. Most of these data are information about different resources used in the statechange. Two particularly important resources are agents and time.

3.1.1.1. Domain models for world description. In the planning literature, there isa surprisingly small variety of domain models for playing the role of world description(state description and state changes). According to Georgeff (1987), most systems haveused representations for actions and events that are based in one way or another oneither the STRIPS representation of operators (Fikes & Nilsson, 1971) or the representationof state changes based on McCarthy’s Situation Calculus (McCarthy & Hayes, 1969) (thefirst being itself strongly related to the second). Moreover, because they must refer tostates, the representation of state changes (actions and events) is always based on therepresentation of the world itself.- For instance, the STRIPS representation assumes thatthe state of the world is represented by a set of first-order predicates; the situationcalculus assumes it is represented by a set of fluents; Ginsberg (1991) uses possibleworlds; Excalibur (Drabble, 1993) uses qualitative process theory. These representations(ontologies) provide foundations in which the domain models for state changes are built.However, the variety is much more significant for domain models for state changes. Wemay not only have actions and events of several types (e.g. STRIPS operators), but alsocausal relations [e.g. NONLIN (Tate, 1977)], partial plans [e.g. NOAH’s SOUP procedures(Sacerdoti, 1974)] and skeletal plans (e.g. Friedland’s MOLGEN and NONLIN).

The representation of states does not influence the performance of the planner much(at least not as much as the plan representation), but it is the major factor in determiningthe type of problems the planner may solve (i.e. its scope). The more powerful, richer andmore adequate to the problem the world representation is, the more likely it is that theplanner operates adequately in the specific application domain. On the other hand, theway state changes are represented may bring some advantages; for instance, ABSTRIPS’s

advantage over STRIPS is due to the improvement in the representation of state changesby including levels of criticality. Such correlation can be explained if we consider that thestructure (composition) of a plan is strongly based on the state changes that are itselements.

Table 1 presents a sample of domain models for sub-roles of world description. ‡

- This interdependence is the reason why state changes and state description are not indepen-dent roles but two parts of the same role world description. The same holds for the sub-roles of plandescription and for the fact that world description and plan description are sub-parts of planmodel.

‡ Notice that the table is not intended to list all possible domain models or even types of domain models. Itsaim is to provide a list of interesting examples. The same holds for Tables 2 and 3.

TABLE 1Examples of domain models to perform sub-roles of world description

System/technique Role Domain model Description

Situation calculus Statedescription

Situations Described by holdspredicates

(McCarthy & Hayes, 1969) State changes Result predicates Described by Resultpredicates

STRIPS Statedescription

FOL atomic wffs Set of atomic first-orderwell-formed formulas(wffs)

(Fikes & Nilsson, 1971) State changes STRIPS

operatorsAdd- and delete-lists plus

preconditions

ABSTRIPS (Sacerdoti, 1974) State changes ABSTRIPS

operatorsVariant of STRIPS operators

with preconditionsordered by level ofcriticality

NOAH (Sacerdoti, 1975) State changes SOUP procedures Partial plans expressed asQLISP procedures

MOLGEN (Stefik, 1981) State changes MARS operators Operators organized ina class hierarchy

MOLGEN (Friedland &Iwasaki, 1985)

State changes Skeletal plans Library of predefinedskeletal plans

Ginsberg’s formalism State descrip-tion

Possible worlds States as possible worlddescriptions

(Ginsberg, 1991) State changes Possible worlds Changes in possible worlds

Excalibur (Drabble, 1993) Statedescription

Process theory Sets of processes relatedby causal influences

SIPE (Wilkins, 1984) State changedata

Unit resources Single unit resourcehandling

O-PLAN2 (Tate, 1993) State changedata

Authority Model of authority require-ments for activities


3.1.2. Plan descriptionThe plan description role describes the structure and features of the plan beinggenerated and comprises two sub-roles: plan structure and the (optional) planassessment knowledge.

3.1.2.1. Plan structure. This role specifies how the parts of a plan (actions, sub-plans) areassembled together. Since in the end the primitive elements of a plan are states or statechanges in the world, this role specifies in fact a structure which makes use of the‘‘vocabulary’’ specified in the world description role. By specifying ordering, theplan structure also specifies (indirectly) how the plan is to be executed. There areseveral varieties in the structure of plans that can be identified in the literature. They canbe described by the way the plan structure accommodates three sub-roles.


f Plan elements. These are usually the same elements defined as state changes, but notnecessarily so. Many planners use graphs in which only some of the nodes correspondto a state change, while others may correspond to goals, for example.

f Plan composition. This role contains the description of the plan with respect to how theplan elements are arranged in order to make up a plan. This role includes, for instance,whether the plan will be a partial or a total ordering, or whether it includes iteration orconditional operators. The composition may also be hierarchical: plans are composedof sub-plans, and so on up to atomic plan steps.

f Plan data. This role includes all sorts of auxiliary information that annotates the plan,ranging from bookkeeping information, to information about resource use in parts ofthe plan (which is aggregated over state change data for some or all of the state changedata which are used as plan elements), to any kind of auxiliary constraint about theplan.

3.1.2.2. Plan assessment knowledge. This role determines whether a certain plan (orsub-plan) is valid (hard assessment knowledge), or whether a plan is better than another(soft). Based on this knowledge, a plan can be modified or criticized. An example of hardplan assessment knowledge is the truth-criterion, which is used to find out ifa condition is true at some point in the plan. TWEAK (Chapman, 1987) uses a modal truthcriterion (MTC) which defines when a particular condition in a plan is necessarily orpossibly true by formally stating all possible interaction problems. Another example ofa domain model for hard plan assessment knowledge is causal-link knowledgeused in SNLP (McAllester & Rosenblitt, 1991). Knowledge for testing the consistency ofthe auxiliary constraints is also an example of hard plan assessment knowledge.An example of soft knowledge would be that plans with smaller number of plan-steps arepreferred. This paper only deals with hard assessment knowledge. Assessment knowledgecan also be domain-specific, in which case it can be used to criticize the plan moreefficiently.

3.1.2.3. Domain models for plan descriptions. Domain models for describingplans come in several varieties, and several degrees of expressiveness. To someextent, their richness depends on the way the states and state changes are defined.For instance, it is only possible to reason about plan resources if state changes incorpor-ate the concept. One may argue that it is an automatic inheritance, but one is not obligedto take care of the influences of the resources in the plan only because they arerepresented.

Advances in early planners happened more on the plan composition. Therefollowed proposals for adding plan assessment knowledge, starting with HACKER

and INTERPLAN (Tate, 1974). Later came planners that took care of state change datasuch as resources and time constraints.

In Table 2, we present a sample of domain models of a number of classical planningsystems that play sub-roles of plan description.

3.1.3. Domain models for meta-planning knowledgeMeta-planning knowledge is knowledge about the planning process. It is usually em-ployed to reason about alternative methods for planning within the same system, at


run-time. The use of meta-planning knowledge was introduced with Stefik’s MOLGEN, andhas been used in several systems since then. MOLGEN introduced the use of severalstrategies defined in terms of four basic planning operators and their control in theplanning process. Meta-planning knowledge is frequently used in planning architecturesand systems which use re-planning. For instance, the O-PLAN (Currie & Tate, 1991)architecture used knowledge sources (similar but improved in relation to MOLGEN’s

planning operators) as the primitive building blocks of the planning process. Theknowledge sources are controlled dynamically by an agenda. Recent work by the samegroup in the model (I-N-OVA' (Tate, 1994) also uses a planning agenda, in this caserepresented as constraints. In Table 3 we summarize some of the domain models thatperform the role of meta-planning knowledge. Note that since the library present-ed in Section 4 contains only classical planners, it does not make use of this role, which isthus not developed in detail in the remainder of this paper.

TABLE 3Domain models to perform meta-planning knowledge


MOLGEN (Stefik, 1981) Meta-planningknowledge

Strategies Control strategies described interms of planning operators

Meta-planningknowledge

Planning oper-ators

Basic steps in plan synthesis

O-PLAN (Currie &Tate, 1991)


Knowledgesources

Improved set of planningcontrol primitives


Agenda Agenda of pending issuesin the planning process

TABLE 2Domain models to perform sub-roles of plan description


STRIPS (Fikes &Nilsson, 1971)

Plan composition List of operators Ordered sequence ofoperators

HACKER (Sussman,1975) Plan assessment

knowledge

Critics Patterns of ‘‘bugs’’ inthe plan

INTERPLAN (Tate,1974) Plan assessment

knowledge

Protections Goal protections toassess problems inthe plan

MOLGEN (Stefik,1981) Plan assessment

knowledge

Constraints Express interdepen-dencies betweensub-plans


3.2. DYNAMIC ROLES IN PLANNING

The basic problem solved in planning tasks is to generate a sequence of actions (a plan)whose execution accomplishes a given goal. A planning problem is characterized by twoinputs: an initial state and a goal description of the world. We distinguish the followingdynamic roles.f Current state. The role current state is initially filled by a description of the

world in the initial state, and later it is modified to contain intermediary states in theplan.

f Goal. The role goal describes the changes to the world that must be accomplished bythe plan. The content of goal can be a set of conditions or a set of actions to beaccomplished. Initially this role points to the original problem goal. During theplanning process the content of the role is dynamically modified by establishing newsubgoals and deleting achieved goals.

f Plan. The dynamic knowledge role plan is a composite role whose content isconstantly modified during the planning process until a solution is found. It consists ofthe following.1. Plan-steps which are the steps in the plan that correspond to actions in the domain.2. Ordering constraints over the plan-steps, e.g. that one action precedes another. The

type of order imposed on the plan-steps in the plan (e.g. partial or total) depends onthe static role plan structure employed by the planner.

3. »ariable binding constraints which keep track of how variables of plan-steps areinstantiated with domain knowledge such as objects, resources and agents.

4. Auxiliary constraints that represent temporal and truth constraints betweenplan-steps and conditions. Auxiliary constraints are present in the plan only assupport knowledge for the planning process. When a solution plan is found, theyare no longer useful, unless the plan is to be reused. An example of anauxiliary constraint is a causal link, which is defined by (i) a condition in theplan that has to be true (e.g. a goal condition), (ii) a plan-step that needs thiscondition to be true and (iii) another plan-step that makes this condition true.Another example of an auxiliary constraint is point truth constraint, which requiresthat some condition be true before a certain plan-step can occur (Kambhampati,1995).

f Conflict. The role conflict contains the result of checking the plan for inconsisten-cies with respect to its conditions. Whenever a condition is unexpectedly false, a con-flict is detected. The conflict role can point directly to a plan-step that violatessome interval of the truth value of a condition, or just point to a set of inconsistentconstraints [like in UMCP (Erol et al., 1994)].

4. Planning task structures

Based on an analysis of many classical planning systems, we have identified relevanttasks and problem-solving methods. They can be organized into a task-method de-composition structure (Orsvarn, 1996; see Figure 3), where a method consists of (solidlines) sub-tasks and a (sub-) task can be realized by alternative (dashed lines) methods.Ellipses represent tasks and rectangle methods.

FIGURE 3. A task-method decomposition structure for planning.


We claim that the class of planners we are dealing with share a general, high-levelproblem-solving method which we call propose—critique—modify (PCM-). That is, allplanners contain in one way or another three basic tasks: (i) propose refinement,(ii) critique plan and (iii) modify plan. Planners differ in how they achieve each of thesesteps, i.e. in what PSMs they use to perform these three tasks. These differences also reflecttheir choices in terms of how planning knowledge is represented. Figure 3 shows a set ofPSMs we have found in the literature to realize these tasks.

Actually, the PCM method represents a whole family of methods, in the sense thatsome-times not all of its sub-tasks need to be carried out. For example, the PCM familyincludes methods that only do propose, or propose and modify. The tasks presented inFigure 3 are described below.

4.1. THE PLANNING TASKS

Below is a detailed description of the individual tasks presented in the task-methoddecomposition tree in Figure 3.

4.1.1. Propose refinementThis task has the goal of adding new steps or constraints to the plan. The knowledge

roles involved in this task are: world description, plan structure and planassessment knowledge. To realize this task, we found a method called propose I,

- It is interesting to note that the idea of proposing a single high-level method for a class of problems is notnew. In Chandrasekaran (1990), a similar method is proposed, also called propose—critique—modify, to solvedesign problems.


which can be decomposed into three sub-tasks: select goal, propose expansion and testfor unachieved goals.

f Select goal. This task selects a goal from the set of goals to be accomplished. The goalcan be either a goal state to be achieved or a goal action to be accomplished bya number of actions. For select goal, three methods can be used: linear select, randomselect and smart select. STRIPS chronologically selects the last goal state established byits search strategy, which we call linear select. NONLIN (Tate, 1977) randomly selects anygoal that has not yet been accomplished. SNLP (McAllester & Rosenblitt, 1991)randomly selects goals from the set of pending goals. It is also possible to select a goalin a more intelligent manner which minimizes possible future modifications (smartselect) (Drummond & Currie, 1989). In this case, the method uses the static role planassessment knowledge to select a goal. An example of smart select was proposedby Kambhampati (1995), where a goal-selection strategy is described called MTC-based- goal selection, which selects a goal state only when it is not necessarily trueaccording to the modal truth criterion.

f Propose expansion. This task takes the selected goal, and proposes a way to accomplishit using state changes. The state change can be a new plan step, or an actiondecomposition which will be added to the plan at the place of the goal action. Thepropose expansion task can be realized by three alternative methods. Decompositionpropose proposes a goal decomposition, which means to propose a more detailed wayto accomplish the goal. This method is only applicable if the goal is a goal action.Goal-achievement propose, selects an operator whose effect includes the selected goal,constraining the place of the operator in the plan to be necessarily before the selectedgoal. When a new operator is added to the plan, its preconditions are added to the setof goals. When there is already a step in the plan that achieves the goal, only theordering constraint is added to the plan. This method is used by SNLP and REFINEMENT

SEARCH (Kambhampati, 1995) planning algorithms. The smart propose method isapplied by STRIPS and PRODIGY (Carbonell and the PRODIGY Research Group, 1992)which are implemented by means-end analysis (Newell & Simon, 1963), and exploitsthe difference between the goal state and the current state to select an operator. Withineach of the three methods, there are still different ways to propose an expansion,depending on the backtracking points left (e.g. on the decomposition choice, on theoperator, or on variable bindings). In the case of adding a step, the different insertionpoints in the plan can be considered as another backtracking point [e.g. TOCL (Barretand Weld, 1994)].

f ¹est for unachieved goals. This task checks the current plan for unachieved goals, andrecords them in the dynamic role goal. It also tests whether the preconditions(sub-goals) of an operator are already achieved in the current state (when the plancomposition is total-order). We identified three methods to realize this task: theMTC-based goal-test, the current-state goal-test and the agenda-based goal test. Plannersthat exploit causal-links use the simple agenda-based method, because they only need

- When we write MTC-based or causal-link based, we mean MTC or causal-link like. Thus, they do nothave to be pure MTC or causal-link.


to check for the existence of goals not yet processed; goals, once achieved, are preserved(protected) through the causal links.

4.1.2 Critique planThe critique plan task checks for conflicts and the quality of the plan generated so far,using plan assessment knowledge. The role plan assessment knowledge can pointto ‘‘hard’’ constraints (interaction and the satisfiability of the plan constraints) and ‘‘soft’’constraints (the factors that define when a given plan is better than another). Weidentified one method to realize this task which we called critique I. This method consistsof two sub-tasks: consistency critique and interaction critique.

f Interaction critique. When checking for conflicts, this task verifies whether the pro-posed action for accomplishing the goal would interact with other goals in the plan(e.g. one action might undo the precondition of another action). Note that this taskinvolves explicit reasoning about interactions. For realizing the interaction critiquetask, we identified two methods: (i) the causal-link-based critique, which checks if theproposed plan-step threats any existent causal link; and (ii) the MTC-based critique,which uses the modal truth criterion to check the existence of a step that possiblydeletes any achieved goal.

f Consistency critique. This task checks the consistency of the overall constraints on theplan generated so far. This task differs from the interaction critique in the sense that itcan find more general conflicts between the constraints than the deleted-conditionconflict. More complex planning systems can also check the consistency of the assignedresources and agents. We identified the constraint propagation method to realize thistask.

4.1.3. Modify planThe modify plan task is responsible for modifying the plan with respect to the results ofthe critique plan task (a conflict). By using plan assessment knowledge, a modificationcan be done by adding ordering, binding or secondary preconditions to the plan until thepossible conflict (violation) is solved or avoided. We identified three methods to realizethis task: the causal-link-based and the MTC-based method for partial-ordered plans, andthe ordering selection method for total-order plans. The causal-link-based method addscausal links to the plan which prevent the conditions contained in conflict from beingundone. The MTC-based method adds constraints to the plan in such a way that theconditions in conflict are necessarily true. The ordering selection method is used intotal-order plans to select a point in the plan where to insert the operator such that theconflict can be avoided [as e.g. in PRODIGY (Carbonell & the PRODIGY ResearchGroup, 1992)].

4.2. CONTROL STRUCTURES

As we have mentioned before, the task-method decomposition structure can representa family of planning systems, which means that we can describe a particular plannerfamily by specifying the tasks it executes and the methods it uses to perform those tasks.During planning, sub-tasks can be executed in various ways by the application of


different control regimes. In fact, many planning systems from the literature differ fromeach other only with respect to their control knowledge. Therefore, a characterization ofa planning PSM needs also a specification of its control structure. The control structureknowledge includes the steps of a strategy, the order between them, conditions, loops,backtracking points, exit points, etc. Through the specification of control structures, wecan relate the individual tasks and methods to specific planners.

Based on our analyses we have identified two types of control structures: fully specifiedand partially specified.

4.2.1. Fully specified control structuresThese structures correspond to the control knowledge present in well-known existingplanning algorithms such as STRIPS, NONLIN, PRODIGY, SNLP, UCPOP, etc. In such controlstructures, the execution ordering between all the tasks are fully specified and most of thecorresponding algorithms are proved complete and correct (due to the correct specifica-tion of conditions, backtracking points, exit points, recursive calls, etc.). The following isan example of a fully specified control structure given in terms of tasks and methodsfound in our library (Section 4) that represents the SNLP planner (McAllester & Rosen-blitt, 1991).

CONTROL-STRUCTURE: SNLP-CONTROL

1. test-for-unachieved-goals (method: agenda-based-test)2. if goal" empty then exit3. else select-goal (method: random-select)4. propose-expansion (method: goal-achievement-propose); backtracking-point5. interaction-critique (method: causal-link-based-critique)6. consistency-critique (method: constraint-propagation)7. if conflictOempty then8. modify-plan (method: causal-link-based-modify); backtracking-point9. else SNLP; recursive-invocation

The above control structure specifies that the SNLP method executes the following tasks:test-for-unachieved-goals, select-goal, propose-expansion, interaction-critique, consist-ency-critique and modify-plan. The methods that SNLP uses to perform those tasks are,respectively, agenda-based-test, random-select, goal-achievement-propose, causal-link-based-critique, constraint-propagation and causal-link-based-modify. The steps from1 to 9 are supposed to be executed in that order, unless the system execution fails andbacktracks. There are two backtracking points: step 4 and step 8. Step 2 is an exitcondition and step 9 a recursive invocation point.

To support the selection of a control regime which has a better performance in a givendomain, assumptions can be made by a fully-specified control structure. Those assump-tions are in general related to the cost and performance analysis of the known planners.For example, the domain feature ratio of negative to positive threats candetermine the performance of different planners (Knoblock & Yang, 1995). In the case ofthe SNLP planner, it has a better performance in domains where the ratio of threats islarge (Knoblock & Yang, 1995).


4.2.2. Partially specified control structuresThese structures correspond to identified patterns of control knowledge that recur inmany planning algorithms. We capture these control patterns for each non-primitivemethod from the task-method decomposition structure (Section 4), i.e. propose-critique-modify, propose-I and critique-I. For example, in the method propose-critique-modify, thetest-for-unachieved-goals task is always used as an exit-point, while the propose-expansiontask is a backtracking point and the select-goal task is always executed before thepropose-expansion task. Moreover, some total-order planners (e.g. PRODIGY) solve thenonlinearity problem by considering the select-goal task as a backtracking point,another way would be considering the modify plan task as a backtracking point like inthe TO planning algorithm (Minton, Bresina & Drummond, 1991) when realizing theprimitive method ordering selection.

Partially specified control structures can be included in a knowledge acquisition tool toprovide support on control specification when none of the fully specified structures apply(Section 5.3). We show below the description of two partially specified control structuresfor the methods: propose-critique-modify and propose-I. The way we describe them here isin accordance with their representation in the frame-based tool PAR-KAP (see Section5.3).

CONTROL-STRUCTURE Propose-Critique-ModifyLoop:(involves STEP-1) and (involves STEP-2) and ( involves STEP 3)and has-a exit-condition: (goal"empty)Tasks:STEP-1. propose-refinement; is a backtracking-point and exit-pointSTEP-2. critique-plan; is a fail-pointSTEP-3. modify-plan; is a backtracking-point and

has-a execution-condition: (conflictOempty)Partial control ordering: (STEP-2 is-before STEP-3)

The Propose-Critique-Modify method executes three tasks labeled by STEP-1,STEP-2 and STEP-3, which are the steps involved in a loop. At some point, the loop issupposed to have an exit condition such as (goal" empty). STEP-1 and STEP-3 arebacktracking points. STEP-2 is a fail-point and STEP-3 is executed only if there is anyconflict. The partial control ordering tells that STEP-2 is supposed to be executed beforeSTEP-3: the planner can only modify the plan after doing a critique. Planning algorithmsvary the ordering in which they execute STEP-1: a planner can either critique the planuntil no more conflicts exist or just critique the last proposed refinement and leave thepossible threats to be reestablished as new sub-goals. In that way the control structuremakes no commitment to ordering STEP-1.

CONTROL-STRUCTURE Propose 1Tasks:STEP-1. select-goal; is a backtracking-pointSTEP-2. propose-expansion; is a backtracking-pointSTEP-3. test-for-unachieved-goals; has-a exit-condition: (goal"empty)Partial control ordering: (STEP-1 is-before STEP-2)


The Propose-1 method has no loop and necessarily executes the three tasks:select-goal, propose-expansion and test-for-unachieved-goals (labeled by the above stepnames). STEP-1 and STEP-2 are backtracking points. STEP-3 is an exit point. Thepartial control ordering given by this control structure tells that a goal is supposed to beselected before a plan expansion being proposed. Planning algorithms vary the orderingin which they execute STEP-3. Therefore, no commitment ordering is made involvingthis step.

Partially-specified control structures can also make assumptions that are not necessar-ily related to performance but to completeness and correctness of the algorithm. Forinstance, the above control-structure uses STEP-1 as a backtracking-point which isusually done by a total-order planner which does not execute the critique and modifytask. This is done in order to ensure the system completeness (Carbonell & the PROD-IGY Research Group, 1992), i.e. to design a nonlinear total order planner.-

5. Using the library: knowledge acquisition

In addition to being an analytical framework for synthesizing and understandingplanning methods, the library presented in this paper is intended as a support tool whenbuilding a planner that requires a planning method. Its main use for this function is inconfiguring methods into a planner which is adequate to a given problem in an applica-tion domain. Each choice in the space of possible methods has consequences for thechoices of the domains it can be applied to, and vice versa. Therefore, this configurationprocess is an interplay in which, on the one hand, components are selected from thelibrary and, on the other, the knowledge they require from the application domain isacquired—or, vice versa, domain knowledge acquired drives the selection of compo-nents. Central in this process is the use of assumptions that express dependencies betweena task and domain. The configuration process involves, from the point of view of thelibrary, two basic knowledge acquisition tasks.‡

1. Given a characterization of a particular application domain in terms of abstractassumptions such as the availability of modal truth criteria, find which task structuresin the library are appropriate to be used, and which control structures can be appliedto these task structures.

2. Given a particular task/control structure (i.e. a model of a planner), find whatrestrictions (i.e. assumptions) a domain must obey in order to use the task/controlstructure.

Other types of acquisition tasks, such as relaxing assumptions and reselecting compo-nents, can be constructed based on the functionality provided in these two basicacquisition tasks.

- Different ways to design a nonlinear total order planner would be either a planner that uses the methodordering selection to perform the modify plan task or a planner that does backtracking in the proposeexpansion task with respect to the ordering constraints.

‡ Of course, other knowledge acquisition tasks for acquiring knowledge from the domain (as opposed tofrom the library) are necessary. These tasks are outside the scope of this work, since many general techniquesand tools are available for them.


In this section, we will discuss how the library can be used. We will first discuss in somedetail the role of assumptions in the use of the library (Section 5.1). Then, we will describetwo systems we have implemented, TIN A (Section 5.2) and PAR-KAP (Section 5.3), thatprovide automated support for the basic knowledge acquisition tasks described above.

5.1. THE ROLE OF ASSUMPTIONS

As we described in Section 2, the choices on task and domain spaces are stronglyinterconnected; we represent these connections by assumptions. Assumptions play a cru-cial role in selecting a PSM or in characterizing domains. First, it must be kept in mindthat in some cases they are ‘‘soft’’ requirements. If one has an implemented planner thatwould be easier to use for whatever reason, the acquisition process becomes biasedtowards forcing the domain to fulfill the assumptions required by this planner. Domainscan be, to some extent, malleable enough to be bent to these needs. For instance, in somecases it does not matter whether to model the stage changes as add—delete lists or as tasksorganized in a hierarchical manner. For instance, Unix can be seen as a planningapplication domain in which the goals are sets of information of states of the files anddirectories, and the steps consist of issuing Unix shell commands. Since there seems to bevery little hierarchy in the command set, it seems more natural at a first glance to modelthe Unix commands as STRIPS-operators. On the other hand, as every experienced Unixuser knows, one can specify aliases and shell scripts that in practice implement higher-level commands for specialized tasks—the existence of languages such as awk relies toa large extent on this technique. So the question sometimes is not whether you can modelthe domain in a certain way, but whether it seems natural or adequate to do so.

Second, and more importantly, knowledge availability is not only a matter of lookingat what your method needs, but at what is already available in the domain. One shouldtry to use the maximum of the knowledge available in the domain. If (hypotheticallyspeaking) all we have is the Unix manual, flat operators is the best we can come up with.However, if we do have experts that can devise or have already devised efficient shellscripts, it is best to use them. There is a natural trade-off between knowledge and search.In figurative terms, knowledge is the result of previous search recorded in a compiledform. The more (heuristic) knowledge you have, the less you need to rely on search. Ofcourse, a planner can come up alone with the shell scripts, and many learning architec-tures rely precisely on that. However, if you have them available, why not use them andtherefore ‘‘save’’ in search? In this sense, different assumptions and requirements made bydifferent methods present opportunities to make the best use of the knowledge naturallyavailable in the domain.

Third, it is possible in principle to characterize planning application domains using theassumptions, in the same way that we use them to characterize types of methods—e.g.partial-order vs. total-order planners. However, this characterization requires establish-ing a way to write the assumptions by referring only to characteristics of the applicationdomain (also called domain features in the literature) that are independent of specifictasks, and thus ‘‘intrinsic’’ to that domain. For instance, while a method assumption for‘‘decomposition propose expansion’’ requires that knowledge is available and appropri-ate to fill the world description with an HTN domain model, it is not totally clearwhat domain features indicate whether such an assumption will hold. In this example, we


speculate that one indication is the way goals are seen in the domain: when goals arenaturally seen as ‘‘actions’’, HTNs are adequate, whereas when goals are ‘‘states’’, ADLs aremore suitable. In some modern planners, the distinction between state-goals and action-goals disappears, as in DS1’s planner (Smith, Rajan & Muscettola, 1997). In summary,we are interested in finding the relations between characteristics of application domainsand domain representations, which would be, through our library, related to PSMs forplanning. For an outline of how this classification could be made, see Benjamins et al.(1996).

5.2. AUTOMATING THE USE OF THE LIBRARY: TIN A

In previous work (Benjamins, 1994, 1995), we have developed a general knowledgeacquisition tool TIN A (Tool in Acquisition) that is based on the notions of tasks, PSMs,assumptions, domain knowledge and strategies. TIN A works by matching assumptionsof PSMs with domain knowledge.

In order to work, TIN A needs three kinds of knowledge: (1) a generative grammar-describing the legal PSM combinations, (2) conditions on the rewrite rules of the grammarand (3) domain characterizations. The library can be represented in terms of these threekinds of knowledge as follows.

f ¹he task-method decomposition as the grammar. The decomposition structure shown inFigure 3 can easily be represented as a grammar. The decomposition structure isrepresented as a quadruple SP, ¹, PM, CMT, where ¹ denotes the set of tasks relevantfor the planning task P. PM stands for the set of primitive PSMs. CM is the set ofcomposite problem-solving methods that decompose tasks into sub-tasks. In terms ofa grammar, P would be the start symbol, ¹ the non-terminals, CM the rewrite rulesand PM the terminals. Starting at P, a grammatically legal sentence corresponds toa valid planning task structure.Figure 4 illustrates some of the composite PSMs represented as rewrite rules. TIN A usesthe definite clause grammar (DCG) of Prolog to represent the task-method decomposi-tion. Because DCG allows for normal Prolog code within the grammar, we can easilyinclude the assumptions. Figure 4 depicts two alternative PSMs for planning, whichbelong to the PSM-family,‡ and three PSMs for the test for unachieved goals task.

f Assumptions as conditions on rewrite rules. The identified relations between static rolesof a PSM and their fillings by domain knowledge (see Section 3) are in fact theassumptions of the PSM: the fillings characterize the domain requirements of the PSM [cf.the method ontology of Gennari et al. (1994)]. Therefore, assumptions are imple-mented as constraints between static roles and domain knowledge. Assumptions arerepresented as conditions on the rewrite rules, which means that a rewrite rule can onlybe applied if its assumptions are satisfied. They are implemented separately from thegrammar, as shown in Figure 5.

- The fact that the grammar is generative implies that it can only build a ‘‘well-formed’’ planner. SeeBenjamins (1994) for a discussion on the relation between TIN A and other ‘‘grammar’’ approaches such asGDMs (van Heijst, Terpstra, Wielinga & Shadbolt, 1992).

‡Note that the second grammar rule for planning represents a ‘degenerated’ member of the PCM family.

FIGURE 4. Some grammar rules representing planning methods. The term at the left side of the arrow ina grammar rule represents a task. The right part of the arrow represents a composite method (ending in -CM).It consists of a reference to the method’s assumptions, and a set of subtasks (ending in-) T and/or primitive PSMs

(ending in -PM), and appearing in [ ]).


f Static roles as domain characterizations. One result of our analysis of planning is theidentification of static roles and their relations to domain knowledge (Figure 2). Ouranalysis has revealed that there are three main static roles which can be fulfilled bydifferent kinds of domain knowledge. The three main static roles are: (1) plan composi-tion, (2) world description and (3) plan-assessment knowledge. Their respective fillingsby domain knowledge are (1) total or partial order, (2) ADL or HTN and (3) causal linksor truth criterion. Below we list six examples of meaningful domain types in planning.

f Total-order/HTN/causal-links.f Total-order/ADL/causal-links.f Partial-order/ADL/causal-links.f Partial-order/ADL/truth-criterion.

FIGURE 5. Some examples of PSM assumptions.

FIGURE 6. Two examples of domain types, characterized by static-role fillings.


f Partial-order/HTN/causal-links.f Partial-order/HTN/truth-criterion.

The remaining two domain types are total-order/HTN/truth-criterion and total-or-der/ADL/truth-criterion. If one can use the truth-criterion (MTC) to calculate allimplications from the current state (which is known in a total order plan), then these twodomains would also be meaningful, but usually MTC is not used in total order plans.Figure 6 illustrates two examples as they are represented in TIN A.

5.2.1. Using TIN A to find applicable task structures in the library for a particular domainIn this section we will show how TIN A can automate the task of finding a planning taskstructure from the library which is adequate for a given type of domain.

Suppose we take the domain type (1) from Figure 6: partialorder—ADL—truth-criterion. If we give this description to TIN A, it outputs four different applicabletask structures. The fact the several task structures are found is due to the fact that tasks


can have several alternative methods to realize them. One of the task structuresgenerated, is shown below as a tree of methods:

propose—critique—modify—CMpropose—I—CM

random—select—goal—PMgoal—achievement—propose—expansion—PMmtc—based—test—for—unachieved—goals—PM

critique—II—CMmtc—based—interaction—critique—PM

mtc—based—modify—plan—PM

We can see that this task structure uses the PCM method, consisting of its threesub-tasks. For each of the sub-tasks, the possible methods have been checked forapplicability by evaluating their assumptions. The generation process has bottomed outin the primitive methods (ending in ‘‘PM ’’). Actually, the presented task structure is that ofTWEAK (Chapman, 1987). TWEAK randomly selects a goal to be achieved and proposes anexpansion that has the goal condition as an effect. It uses MTC-based methods to checkfor unachieved goals and interactions, and to modify the plan. The critique-II belongs tothe family of the critique-I methods, the former being a degenerated version (no consist-ency critique) of the latter.

5.2.2. ºsing ¹IN A to find the assumptions of a given task structure in the libraryAbove, we gave TIN A a domain as input while seeking a task structure as output. In thissection, we will show an example of using the tool the other way around: by providinga specific task structure as an input, and obtaining as output the assumptions that haveto be true in order for the task structure to be applicable. Currently, we have representedin TIN A five well-known planners: STRIPS, PRODIGY, SNLP, NONLIN and TWEAK. In thisexperiment, we will input SNLP.

Figure 7 shows the task structure representing SNLP that is given as an input to TIN A,and the set of assumptions that is retrieved for each of the methods used by SNLP. Somemethods do, however, not have assumptions (e.g. random select goal).

The example discussed above demonstrates that it is possible to obtain the assump-tions that underly a particular planning task structure. It is then up to the knowledgeengineer to decide whether a specific application domain satisfies the assumptions.

5.3 PAR-KAP: THE USE OF A FRAME-BASED LANGUAGE TO REPRESENT THE PLANNINGLIBRARY

TIN A is a general tool that was used to represent the library, and as such the workdescribed above has some limitations. The main limitation in what concerns the planninglibrary is that TIN A does not have facilities for representing control knowledge. Thislimitation was overcome by implementing a system called PAR-KAP (Barros et al., 1997).In this section, we briefly present implementation details and examples of the use of thisKA tool. PAR-KAP supersedes TIN A in that it is able to provide the same kinds ofsupport we showed that TIN A provides. In the representation below, we will concentrateon the part not covered by TIN A, that is, control knowledge.

FIGURE 7. Task structure of SNLP and its assumptions as retrieved by TINA.


PAR-KAP (for Parka in Knowledge Acquisition for Planning) is an efficient, frame-based version knowledge acquisition tool. PAR-KAP uses the PARKA KNOWLEDGE REP-

RESENTATION SYSTEM developed at the University of Maryland (Andersen, Hendler, Evett& Ketter, 1994). PARKA is implemented in C, using relational databases to provide scalingto large knowledge bases and can be used to represent an ontology of classes, sub-classes,individuals and properties of these. PAR-KAP uses PARKA’s Application ProgrammingInterface (API) but is itself implemented in Lisp, running on a Sparc workstation.

The use of PARKA to represent the planning library allows easy inspection andmaintenance of that knowledge. Below, we will briefly describe how PARKA’s generalframe-based language is used to represent the planning library.

f ¹ask method decomposition structure. This structure is represented as a tree of methodsand tasks, linked by two types or relations, executes and is- performed-by. A taskis-performed-by a method (possibly by more than one), and a method executes a task.A method has a propriety controls which specifies a control regime over the tasksexecuted by the method.

Figure 8 gives an example of how a part of the task method decomposition structure isrepresented in PAR-KAP: critique plan is a task that is-performed-by critique-I

FIGURE 8. Representation of a task-method decomposition in PAR-KAP.

FIGURE 9. The SNLP planner in PAR-KAP.


which is a method. critique-I executes the tasks: interaction critique andconsistency critique which are controlled by the control structure critique-Icontrol.f Known planners. In the planning library, we define a number of planning methods

corresponding to well known planners from the literature (like STRIPS, NONLIN, SIPE,SNLP, UCPOP, etc.) which correspond to specific subtrees (strategies) in the task-methoddecomposition (see Figure 3). Figure 9 shows PAR-KAP’s representation of SNLP

planner which executes the primitive-methods: random-select, agenda-based-test, etc.The planner has a fully-specified control structure called: SNLP-control which corres-ponds to the control structure shown in Section 4.2. As we mentioned in that section,control structures can also make domain assumptions, which are also represented inPAR-KAP through the ‘‘requires’’ property (see Figure 9).

f Knowledge roles and assumptions. In PAR-KAP, the static knowledge roles are repre-sented as a part-of tree, like in Figure 2. A domain model which fulfils a knowledge roleis represented as values for the property plays given to the leaves of the part-of tree.A property assumption is represented by the property requires whose value is a do-main-model. Figure 10 illustrates how PAR-KAP represents and links thosethree library components: the part-of tree of knowledge roles, domain models and


assumptions. It presents an example of how the decomposition-propose method re-quires the HTN domain model to play the static role state change.

f Control-structure. Representing the control relationships among the tasks of a methodis done by linking methods to control specifications via the property controls (seeFigure 9). A method’s control structure is represented using step names which arerelated to the (sub-) tasks executed by the method, allowing, in this way, more than onecontrol regime to be associated to the same method. The control structure providesordering and algorithmic relations between the (sub-) tasks, using pointers to variouscontrol-specific terms such as backtracking-point, exit-point, etc. Thus, the controlinformation for the propose-critique-modify method shown in Section 4.2 can berepresented in PAR-KAP as shown in Figure 11.

5.3.1. Using PAR-KAP to find applicable task and control structures in the library for agiven domainPAR-KAP is able to find a PSM in the library adequate to an application domain, givena description of this domain in terms of its features. PAR-KAP then outputs eithera known planner or a PSM with a partially specified control structure which needs to becompleted by the knowledge engineer.

FIGURE 11. Control structure knowledge for the propose-critique-modify method.

FIGURE 10. Domain models and assumptions for the decomposition-propose method in PAR-KAP.

FIGURE 12. PAR-KAP control structure output.



First, PAR-KAP uses the internal representation of the task-method decompositionstructure shown in Figure 3 to generate several applicable task structures which satisfya given domain specification, in the same way as TIN A does.

After generating a list of tasks and the corresponding primitive-methods, PAR-KAPhas to select a suitable control structure. As described in Section 4.2, control knowledgecan be fully specified or partially specified; this is reflected in the representation andretrieval of control structures in PAR-KAP. A fully specified control regime may beselected (1) when the selected primitive-methods match with the primitive-methods ofa well-known planner (as in Figure 9) and (2) when all the planner’s assumptions aresatisfied by the domain specification. When none of the fully-specified control regimescan be selected, PAR-KAP suggests the partially-specified control regime associated toeach of the applicable non-primitive methods (see Section 4.2).

As an example, suppose we give PAR-KAP the following domain specification.

state-changes"HTNplan-assessment-knowledge"causal-link-protectionplan-composition"partial-orderstate-change-data"resourcesstate-description"logical-predicates

The system returns a list of how the high-level tasks can be decomposed into theprimitive tasks shown in Figure 12. This figure also gives an example of one of thecontrol structures that is returned for these inputs.

The control regime suggested above combines three partially specified control struc-tures of three non-primitive methods: propose-critique-modify, propose-I and critique-I(two of them are described in Section 4.2). It is up to the knowledge engineer to accept itand complete it to become a fully specified control structure.

6. Conclusions

In this paper, we have presented a library of system-derived planning problem-solvingmethods. The methods are described in terms of the tasks they comprise and the controlstructures over these tasks. PSMs are organized in task-method decompositions, andrefer to domain models through assumptions. We have shown two knowledge acquisi-tion tools, TIN A and PAR-KAP, that can partly automate the use of the library,providing concrete support for the knowledge acquisition process. One kind of supportconcerned the configuration of an applicable planner for a particular application domainusing the PSMs from the library. The application domain in question is matched to theassumptions of PSMs until an adequate configuration of PSMs is found to solve the specificproblem. In fact, all possible PSM configurations are found that match the domain athand, yielding, in several cases, ‘‘new’’ planners. The other kind of knowledge acquisitionsupport concerned the generation of the domain assumptions, given a particular planner.The planner is decomposed into its constituting PSMs, for each of which the assumptionsreferring to domain knowledge are retrieved.

It is important to notice that the library proposed in this paper is basically a modelingaid. That is, it helps a knowledge engineer in selecting a problem-solving methodadequate to the application. However, a question that remains is how to operationalize


this PSM. The type of library we constructed follows the COMMONKADS tradition ofseparating analysis and design. The conceptual model is supposed to be a product byitself, based upon which the engineer proceeds to design an application and thenprogram a computer system. Design issues are left to a separate model, the design model,which is distinct from the model of expertise where PSMs are specified. Future researchwill address the issue of operationalizing the library so that a configured method can beused to generate semi-automatically an actual computer program.

Another important aspect of this library is that it can be seen as a knowledge-levelframework to understand and compare planning methods. The main advantages of thisframework over the traditional comparisons in the literature (usually based on algorithmefficiency) are that: (1) because it abstracts away from implementation or algorithmdetails, it is easier to understand and (2) because it concentrates on how knowledge isused by the methods, instead of their efficiency, it makes explicit features which arecritical to the knowledge engineering process. In addition to method comparison, theframework can be used to help in understanding new proposed planning methods in theAI/planning literature, by pointing out what are the features of the new system that aredifferent from the known planning systems.

This also points to the way we foresee the library being extended. Each time a know-ledge engineer uses the library to build a new planning system, it can add new domainmodels, tasks or methods by fitting them into the existing framework. This processintroduces interesting issues such as the complexity of the process of checking theconsistency of these new components. In future versions PAR-KAP, we will introducea user interface to the planning library, in order to allow the continuous update andrefinement of the planning knowledge. We intend to make the PAR-KAP tool availableover the Internet to allow it to be remotely accessed and used.

The library presented in this paper differs from related work in two main ways. First, itis basically a conceptual device, in which what is provided is a more or less formal modelof the methods represented. In contrast, other research groups (e.g. Klinker, Bhola,Dallemagne, Marques & McDermott, 1991) have proposed libraries that provide a num-ber of program modules or routines that can immediately operationalize the model intoa working system. It is possible and viable to operationalize our library in a similarmanner, but that has not been a target of our work so far. Second, this library containsmodels derived from an analysis of existing planning systems and algorithms. Themodels proposed by Cottam and Shadbolt (1996) were derived from characterizations ofplanning processes in specific application domains. This characterizes our library assystem-derived, as opposed to domain-derived.

Future work includes working on various extensions of the library. First of all, we willextend the library with more planning methods in order to cover more planners,including skeletal planners, case-based planners, planners that use operators with uncer-tainty and planners that deal with resources. Second, as we include more planningmethods, we will also have to include their respective assumptions describing the domainfeatures required by the methods. Third, we will have to deepen the notion of assumptionof our planning methods. In this paper, assumptions were described as constraintsbetween static roles and their domain fillings or domain model characteristics (e.g.world—description"HTN). However, we still need to establish a relation betweenthese domain-model characteristics and the application-domain features. We need to


find answers to questions such as ‘‘is the HTN world description a domain feature(available or not in the domain) or is it a choice of domain model (that can always beused to structure the domain) ?’’. In future research, we will investigate the possibility toexpress assumptions in terms of such application-domain features.

We would like to thank James Hendler (UMD) for his contribution to PAR-KAP. Andre Valentegratefully acknowledges the support of DARPA through contract DABT63-95-C-0059, as part of theDARPA/Rome Laboratory Planning Initiative (ARPI). Richard Benjamins is supported by the Nether-lands Computer Science Research Foundation with financial support from the NetherlandsOrganization for Scientific Research (NWO), and by the European Commission through a MarieCurie Research Grant (TMR). Leliane Nunes de Barros acknowledges the CNPq (Brazilian nationalresearch council) and the University of Maryland.

REFERENCES

AAMODT, A., BENUS, B., DUURSMA, C., TOMLINSEN, C., SCHROOTEN, R. & DE VELDE, W. V. (1992).Task features and their use in CommonKADS. Deliverable D1.5, version 1.0 KADS-II/TI.3/VUB/TR/006/1.0, VUB, UVA.

ANDERSEN, W., HENDLER, J., EVETT, M. & KETTER, B. (1994). Massive parallel matching ofknowledge structures. In H. KITANO & J. HENDLER, Eds. Massively Parallel Artificial Intelli-gence. Cambridge, MA: AAAI/MIT Press.

BARRET, A. & WELD, D. S. (1994). Partial-order planning: evaluating possible efficiency gains.Artificial Intelligence, 67, pp. 71—112.

BARROS, L., HENDLER, J. & BENJAMINS, V. R. (1997). Par-KAP: a knowledge acquisition tool forbuilding practical planning systems. In Proceedings of the IJCAI-97, Nagoya, Japan.

BARROS, L., VALENTE, A. & BENJAMINS, V. R. (1996). Modeling planning tasks. In Proceedings ofthe 3rd International Conference on Artificial Intelligence Planning Systems, AIPS-96, pp. 11—18.Edinburgh, U.K.

BENJAMINS, V. R. (1994). On a role of problem solving methods in knowledge acquisition:experiments with diagnostic strategies. In L. STEELS, A. T. SCHREIBER & W. VAN DE VELDE,Eds. 8th European Knowledge Acquisition Workshop, EKAW-94, Lecture Notes in ArtificialIntelligence, Vol. 867, pp. 137—157. Berlin, Germany: Springer.

BENJAMINS, V. R. (1995). Problem-solving methods for diagnosis and their role in knowledgeacquisition. International Journal of Expert Systems: Research and Applications, 8, 93—120.

BENJAMINS, R., BARROS, L. & VALENTE, A. (1996). Constructing planners through problem-solving methods. In B. GAINES & M. MUSEN, Eds. Proceedings of the 10th KnowledgeAcquisition for Knowledge-Based Systems Workshop (KAW+96). Banff, Canada.

BENJAMINS, V. R. & PIERRET-GOLBREICH, C. (1996). Assumptions of problem-solving methods. InN. SHADBOLT, K. O’HARA & G. SCHREIBER, Eds. 9th European Knowledge AcquisitionWorkshop, EKAW-96, Lecture Notes in Artificial Intelligence, Vol. 1076, pp. 1—16. Berlin:Springer.

BREUKER, J. & VAN DE VELDE, W., Eds. (1994). CommonKADS Library for Expertise Modelling.Amsterdam: IOS Press.

BREUKER, J. A., WIELINGA, B. J., VAN SOMEREN, M., DE HOOG, R., SCHREIBER, A. T., DE GREEF,P., BREDEWEG, B., WIELEMAKER, J., BILLAULT, J. P., DAVOODI, M. & HAYWARD, S. A. (1987).Model driven knowledge acquisition: interpretation models. ESPRIT Project P1098 Deliver-able D1 (task A1), University of Amsterdam and STL Ltd.

CARBONELL, J. & THE PRODIGY RESEARCH GROUP (1992). PRODIGY 4.0: the manual andtutorial. Technical Report CMU-CS-92-150, School of Computer Science, CMU.

CHANDRASEKARAN, B. (1990). Design problem solving: a task analysis. AI Magazine, 11, 59—71.CHANDRASEKARAN, B., JOHNSON, T. R. & SMITH, J. W. (1992). Task-structure analysis for

knowledge modeling. Communications of the ACM, 35, 124—137.CHAPMAN, D. (1987). Planning for conjunctive goals. Artificial Intelligence, 32, 333—377.


COTTAM, H. & SHADBOLT, N. (1996). Domain and system influences in problem solving models forplanning. In N. SHADBOLT, K. O’HARA & G. SCHREIBER, Eds. 9th European KnowledgeAcquisition Workshop, EKAW-96, Lecture Notes in Artificial Intelligence, Vol. 1076,pp. 354—369. Berlin: Springer.

CURRIE, K. & TATE, A. (1991). O-Plan: the open planning architecture. Artificial Intelligence, 52,49—86.

DRABBLE, B. (1993). Excalibur: a program for planning and reasoning with processes. ArtificialIntelligence, 62, 1—40.

DRUMMOND, M. & CURRIE, K. (1989). Goal ordering in partially ordered plans. In Proceedings ofthe 11th IJCAI, pp. 960—965. Detroit, MI.

EROL, K., HENDLER, J. & NAU, D. S. (1994). UMCP: a sound and complete procedure forhierarchical task-network planning. In Proceedings of the 2nd International Conference onArtificial Intelligence Planning Systems (AIPS-94).

FIKES, R. E. & NILSSON, N. J. (1971). STRIPS: a new approach to the application of theoremproving to problem solving. Artificial Intelligence, 2, pp. 169—203.

FRIEDLAND, P. & IWASAKI, Y. (1985). The concept and implementation of skeletal plans. Journal ofAutomated Reasoning, 1.

GENNARI, J. H., TU, S. W., ROTENFLUH, T. E. & MUSEN, M. A. (1994). Mapping domains tomethods in support of reuse. International Journal of Human—Computer Studies, 41, 399—424.

GEORGEFF, M. P. (1987). Planning. Annual Review of Computer Science, 2, 359—400.GINSBERG, M. L. (1991). Possible worlds planning. In J. ALLEN et al., Ed. Reasoning About Plans,

pp. 213—243. Los Altos, CA: Morgan Kauffman.KAMBHAMPATI, S. (1995). Planning as refinement search: a unified framework for evaluating

design tradeoffs in partial-order planning. Artificial Intelligence, 76 (Special issue on planningand scheduling).

KLINKER, G., BHOLA, C., DALLEMAGNE, G., MARQUES, D. & MCDERMOTT, J. (1991). Usable andreusable programming constructs. Knowledge Acquisition, 3, 117—136.

KNOBLOCK, C. & YANG, Q. (1995). Relating the performance of partial-order planning algorithmsto domain features. SIGART Bulletin, 6, 33—41.

MCALLESTER, D. & ROSENBLITT, D. (1991). Systematic nonlinear planning. In Proceedings ofAAAI-91, pp. 634—639. Anaheim, CA.

MCCARTHY, J. & HAYES, P. J. (1969). Some philosophical problems from the standpoint ofartificial intelligence. Machine Intelligence, 4.

MINTON, S., BRESINA, J. & DRUMMOND, M. (1991). Commitment strategies in planning: a com-parative analysis. In IJCAI-91. Sydney, Australia.

NEWELL, A. & SIMON, H. (1963). GPS: A program that simulates human thought. In E. FEIGEN-

BAUM & J. FELDMAN, Eds. Computers and Thought, pp. 279—293. New York: McGraw-Hill.ORSVA® RN, K. (1996). Principles for libraries of task decomposition methods—conclusions from

a case-study. In N. SHADBOLT, K. O’HARA & G. SCHREIBER, Eds. 9th European KnowledgeAcquisition Workshop, EKAW-96, Lecture Notes in Artificial Intelligence, Vol. 1076,pp. 48—65. Berlin: Springer.

SACERDOTI, E. D. (1974). Planning in a hierarchy of abstraction spaces. Artificial Intelligence, 5,115—135.

SACERDOTI, E. D. (1975). Planning in a hierarchy of abstraction spaces. In Proceedings of theInternational Joint Conference on Artificial Intelligence. Tblisi, Russia.

SCHREIBER, A. T., WIELINGA, B. J., DE HOOG, R., AKKERMANS, J. M. & VAN DE VELDE, W. (1994).CommonKADS: A comprehensive methodology for KBS development. IEEE Expert, 9, 28—37.

SMITH, B. D., RAJAN, K. & MUSCETTOLA, N. (1997). Knowledge acquisition for the onboardplanner of an autonomous spacecraft. In E. PLAZA & V. R. BENJAMINS, Eds. KnowledgeAcquisition, Modeling and Management, pp. 252—268. Berlin: Springer.

STEELS, L. (1990). Components of Expertise. AI Magazine, 11, 29—49.STEFIK, M. (1981). Planning with constraints (MOLGEN: Part 1). Artificial Intelligence, 16,

111—140.SUSSMAN, G. J. (1975). A Computer Model of Skill Acquisition. Artificial Intelligence Series, Vol. 1.

New York: American Elsevier.


TATE, A. (1974). INTERPLAN: a plan generation system which can deal with interactions betweengoals. Technical Report MIP-R-109, University of Edinburgh, Edinburgh.

TATE, A. (1977). Generating project networks. In Proceedings IJCAI-77, pp. 888—893, Paris.TATE, A. (1993). Authority management—coordination between planning, scheduling and control.

In Proceedings of the IJCAI-93 Workshop on Knowledge-based Production Planning, Schedulingand Control. Chambery, France.

TATE, A. (1994). Representing plans as a set of constraints—the SI-N-OVAT model. Technical report,University of Edinburgh, Edinburgh.

VALENTE, A. (1995). Knowledge level analysis of planning. SIGART Bulletin, 6, 33—41.VAN HEIJST, G., TERPSTRA, P., WIELINGA, B. J. & SHADBOLT, N. (1992). Using generalised directive

models in knowledge acquisition. In T. WETTER, K. D. ALTHOFF, J. BOOSE, B. GAINES, M.LINSTER, F. SCHMALHOFER, Eds. Current Developments in Knowledge Acquisition: EKAW-92,Berlin, Germany: Springer.

WILKINS, D. E. (1984). Domain independent planning: representation and plan generation.Artificial Intelligence, 22, 269—301.

a library of system-derived problem-solving methods for planning

Documents