Addendum to: Summary Information for Reasoning About Hierarchical Plans

Addendum to: Summary Information for Reasoning About Hierarchical Plans

Lavindra de Silva Institute for Advanced Manufacturing, University of Nottingham, Nottingham, UK, e-mail: lavindra.desilva@nottingham.ac.ukRMIT University, Melbourne, Australia, e-mail: {ssardina, linpa}@cs.rmit.edu.au    Sebastian Sardina RMIT University, Melbourne, Australia, e-mail: {ssardina, linpa}@cs.rmit.edu.au    Lin Padgham
Abstract

Hierarchically structured agent plans are important for efficient planning and acting, and they also serve (among other things) to produce “richer” classical plans, composed not just of a sequence of primitive actions, but also “abstract” ones representing the supplied hierarchies. A crucial step for this and other approaches is deriving precondition and effect “summaries” from a given plan hierarchy. This paper provides mechanisms to do this for more pragmatic and conventional hierarchies than in the past. To this end, we formally define the notion of a precondition and an effect for a hierarchical plan; we present data structures and algorithms for automatically deriving this information; and we analyse the properties of the presented algorithms. We conclude the paper by detailing how our algorithms may be used together with a classical planner in order to obtain abstract plans.

Introduction

This paper provides effective techniques for automatically extracting abstract actions and plans from a supplied hierarchical agent plan-library. Hierarchically structured agent plans are appealing for efficient acting and planning as they embody an expert’s domain control knowledge, which can greatly speed up the reasoning process and cater for non-functional requirements. Two popular approaches based on such representations are Hierarchical Task Network (HTN) [8, 11] planning and Belief-Desire-Intention (BDI)  [19] agent-oriented programming. While HTN planners “look ahead” over a supplied collection of hierarchical plans to determine whether a task has a viable decomposition, BDI agents interleave this process with acting in the real world, thereby trading off solution quality for faster responsiveness to environmental changes. Despite these differences, HTN and BDI systems are closely related in both syntax and semantics, making it possible to translate between the two representations [20, 21].

While HTN planning and BDI execution are concerned with decomposing hierarchical structures (offline and online, respectively), one may perform other kinds of reasoning with them that do not necessarily require or amount to decompositions. For example, [6] and [22, 23] perform reasoning to coordinate the execution of abstract steps, so as to preempt potential negative interactions or exploit positive ones. In [7], the authors propose a novel application of such hierarchies to produce “richer” classical plans composed not just of sequences of primitive actions, but also of “abstract” steps. Such abstract plans are particularly appealing in the context of BDI and HTN systems because they respect and re-use the domain control knowledge inherent in such systems, and they provide flexibility and robustness: if a refinement of one abstract step happens to fail, another option may be tried to achieve the step.

A pre-requisite for these kinds of reasoning is the availability of meaningful preconditions and effects for abstract steps (i.e., compound tasks in HTN systems or event-goals in BDI languages). Generally, this information is not supplied explicitly, but embedded within the decompositions of an abstract step. This paper provides techniques for extracting this information automatically. The algorithms we develop are built upon those of [6] and [22, 23], which calculate offline the precondition and effect “summaries” of HTN-like hierarchical structures that define the agents in a multi-agent system, and use these summaries at runtime to coordinate the agents or their plans. The most important difference between these existing techniques and ours is that the former are framed in a propositional language, whereas ours allow for first-order variables. This is fundamental when it comes to practical applicability, as any realistic BDI agent program will make use of variables. A nuance worth mentioning between our work and that of Clement et al. is that the preconditions we synthesise are standard classical precondition formulas (with disjunction), whereas their preconditions are (essentially) two sets of literals: the ones that must hold at the start of any successful execution of the entity, and the ones that must hold at the start of at least one such execution. Yao et al. [26] extend the above two strands of work to allow for concurrent steps within an agent’s plan, though still not first-order variables.

Perhaps the only work that computes summaries (“external conditions”) of hierarchies specifying first-order variables is [24]. The authors automatically extract a weaker form of summary information (what we call “mentioned” literals) to inform the task selection strategy of the UMCP HTN planner: tasks that can possibly establish or threaten the applicability of other tasks are explored first. They show that even weak summary information can significantly reduce backtracking and increase planning speed. However, the authors only provide insights into their algorithms for computing summaries.

We note that we are only concerned here with how to extract abstract actions (with corresponding preconditions and effects), and eventually abstract plans, from a hierarchical know-how structure. Consequently, unlike existing useful and interesting work [12, 9, 2, 1], our approach does not directly involve guiding a planner toward finding a suitable primitive plan. We also do not aim to build new “macro” actions from sample primitive solution plans, as done in [3], for example.

Thus, the contributions of this paper are as follows. First, we develop formal definitions for the notions of a precondition and an effect of an (abstract) event-goal. Second, we develop algorithms and data structures for deriving precondition and effect summaries from an event-goal’s hierarchy. Unlike past work, we use a typical BDI agent programming language framework; in doing so, we allow for variables in agent programs—an important requirement in practical systems. Our chosen BDI agent programming language cleanly incorporates the syntax and semantics of HTN planning as a built-in feature, making our work immediately accessible to both communities. Finally, we show how derived event-goal summaries may be used together with a classical planner in order to obtain abstract plans (which can later be further refined, if desired, to meet certain properties [7]).

The Hierarchical Framework

Our definitions, algorithms, and results are based on the formal machinery provided by the CANPlan [21] language and operational semantics. While designed to capture the essence of BDI agent-oriented languages, it directly relates to other hierarchical representations of procedural knowledge, such as HTN planning [8, 11], both in syntax and semantics.

A CANPlan BDI agent is created by the specification of a belief base , i.e., a set of ground atoms, a plan-library , i.e., a set of plan-rules, and an action-library , i.e., a set of action-rules. A plan-rule is of the form , where is an event-goal, is a vector of distinct variables, is the context condition, and is a plan-body or program.111In [21] an event-goal is of the form where is a vector of terms. Here, we replace with and assume WLOG that , where . The latter is made up of the following components: primitive actions () that the agent can execute directly; operations to add () and remove () beliefs; tests for conditions (); and event-goal programs (), which are simply event-goals combined with the label “”. These components are composed using the sequencing construct . While the original definition of a plan-rule also included declarative goals and the ability to specify partially ordered programs [25], we leave out these constructs here and focus only on an AgentSpeak-like [18], typical BDI agent programming language.

There are also additional constructs used by CANPlan internally when attaching semantics to constructs. These are the programs nil, , and . Intuitively, nil is the empty program, which indicates that there is nothing left to execute; program represents the plan-rules that are relevant for some event-goal; and program realises failure recovery: program should be tried first, failing which should be tried. The complete language of CAN, then, is described by the grammar

The behaviour of a CANPlan agent is defined by a set of derivation rules in the style of Plotkin’s structural single-step operational semantics [16]. The transition relation on a configuration is defined using one or more derivation rules. Derivation rules have an antecedent and a conclusion: the antecedent can either be empty, or it can have transitions and auxiliary conditions; the conclusion is a single transition. A transition within a rule denotes that configuration yields configuration in a single execution step, where a configuration is the tuple composed of a belief base , a program , and the sequence of actions executed so far. Construct denotes a transition of type , where ; when no label is specified on a transition both types apply. Intuitively, -type transitions are used for the standard BDI execution cycle, and -type transitions for (internal) deliberation steps within a planning context. By distinguishing between these two types of transitions, certain rules can be disallowed from being used in a planning context, such as those dealing with BDI-style failure handling.

We shall describe three of the CANPlan derivation rules. The rule below states that a configuration evolves into a configuration (with no changes to and ) in one - or -type execution step, with being the set of all relevant plan-rules for , i.e., the ones whose handling event-goal unifies with ; mgu stands for “most general unifier” [13]. From , an applicable plan-rule—one whose context condition holds in —is selected by another derivation rule and the associated plan-body scheduled for execution.

The Plan construct incorporates HTN planning as a built-in feature of the semantics. The main rule defining the construct states that a configuration evolves into a configuration in one -type execution step if the following two conditions hold: (i) configuration yields configuration in one -type execution step, and (ii) it is possible to reach a final configuration from in a finite number of -type execution steps. Thus, executing the single -type step necessitates zero or more internal “look ahead” steps that check for a successful HTN execution of .

Unlike plan-rules, any given action program will have exactly one associated action-rule in the action-library . Like a STRIPS operator, an action-rule is such that is a symbol followed by a vector of distinct variables, and all variables free in , (the add list) and (the delete list) are also free in . We additionally expect any action-rule to be coherent: that is, for all ground instances of , if is consistent, then is consistent. For example, while the rule corresponding to an action with precondition (or ) and postcondition is coherent, the same rule with precondition is not, as there will then be a ground instance of such that its precondition is consistent but its postcondition is not: both its add and delete lists contain the same atom.

Assumptions

We shall now introduce some of the definitions used in the rest of the paper and concretise the rest of our assumptions. As usual, we use and to denote vectors of distinct variables, and to denote a vector of (not necessarily distinct) terms. Moreover, since the language of CANPlan allows variables in programs, we shall frequently make use of the notion of a substitution [13], which is a finite set of elements where are distinct variables and each is a term with . We use to denote the expression obtained from any expression by simultaneously replacing each occurrence of in with , for all .

We assume that the plan-library does not have recursion. Formally, we assume that a ranking exists for the plan-library, i.e., that it is always possible to give a child a smaller rank (number) than its parent. We define a ranking as follows.

Definition 1
  • A ranking for a plan-library is a function from event-goal types mentioned in to natural numbers, such that for all event-goals where is the same type as some , we have that .222We define the function , where two event-goals are the same type if they have the same predicate symbol and arity. The type of an event-goal is defined as , where .

In addition, we define the following two related notions: first, given an event-goal type , denotes the rank of in ; and second, given any event-goal mentioned in , we define (where ), i.e., the rank of an event-goal is equivalent to the rank of its type. In order that these and other definitions also apply to event-goal programs, we sometimes blur the distinction between event-goals and event-goal programs .

Finally, we assume that context conditions are written with appropriate care. Specifically, if there is no environmental interference, whenever a plan-rule is applicable it should be possible to successfully execute the associated plan-body without any failure and recovery; this disallows rules such as . Our definition makes use of the notion of a projection: given any configuration , we define the projection of the first component of the tuple as , the second as , and the third as .

Definition 2
  • A plan-library is coherent if for all rules , ground instances of , and belief bases , whenever (where is ground) there is a successful HTN execution of (relative to ) with . A successful HTNexecution of a program relative to a plan-library is any finite sequence of configurations such that , , and for all .

Intuitively, the term HTN execution simply denotes a BDI execution in which certain BDI-specific derivation rules associated with failure and recovery have not been used.

Summary Information

We can now start to define what we mean by preconditions and postconditions/effects of event-goals; some of these definitions are also used later in the algorithms. As a first step we define these notions for our most basic programs.

A basic program is either an atomic program or a primitive program. Formally, a program is an atomic program (or simply atomic) if , and is a primitive program if is an atomic program that is not an event-goal program. Then, like the postcondition of a STRIPS action, the postcondition of a primitive program is simply the atoms that will be added to and removed from the belief base upon executing the program. Formally, the postcondition of a primitive program relative to an action-library , denoted , is the set of literals

The postcondition of a test condition is the empty set because executing a test condition does not result in an update to the belief base. The postcondition of an action program is the combination of the add list and delete list of the associated action-rule, after applying the appropriate substitution.

While this notion of a postcondition as applied to a primitive program is necessary for our algorithms later, we do not also need the matching notion of a precondition of a primitive program. Such preconditions are already accounted for in context conditions of plan-rules, by virtue of our assumption (Definition 2) that the latter are coherent. What we do require, however, is the notion of a precondition as applied to an event-goal. This is defined as any formula such that whenever it holds in some state there is at least one successful HTN execution of the event-goal from that state.

Definition 3
  • A formula is said to be a precondition of an event-goal (relative to a plan- and an action-library) if for all ground instances of and belief bases , whenever , there exists a successful HTN execution of , where .

Unlike the postcondition of a primitive program, the postcondition of an event-goal program—and indeed any arbitrary program —is non-deterministic: it depends on what plan-rules are chosen to decompose . There are, nonetheless, certain effects that will be brought about irrespective of such choices. We call these must literals: literals that hold at the end of every successful HTN execution of .

Definition 4
  • Let be a program and a literal where its variables are free in . Then, is a must literal of (relative to a plan- and action-library) if for any ground instance of and successful HTN execution of , we have that .

A desirable consequence of the two definitions above is that any given set of must literals of an event-goal, like the postcondition of an action, is consistent whenever the event-goal’s precondition is consistent.

{theorem}

Let be an event-goal, a precondition of (relative to a plan-library and an action-library ), and a set of must literals of (relative to and ). Then, for all ground instances of , if is consistent for some ground substitution , then so is . Proof. We prove this by contradiction. First, note that since is a set of ground literals (by Definition 4 and because is ground), if is consistent, then for all literals it is the case that (i.e., is not the complement of ). Now let us assume that the theorem does not hold. This means that there must exist a ground instance of , such that is consistent for some ground substitution , but for some .

Since is consistent, there is at least one truth assignment for its (ground) atoms that satisfies . Suppose is the set of ground atoms consisting only of those mentioned in that were assigned the truth value true. Observe that . Then, according to Definition 3 (Precondition), there must exist a successful HTN execution of such that . Moreover, since are must literals of and is ground, by Definition 4, both and are also ground. By the same definition, and . However, according to our assumption, , and therefore . This contradicts the fact that , because is ground due to our assumption in Section “ASSUMPTIONS” that is coherent.  

In addition to must literals, there are two related notions. The first, called may summary conditions in [6], defines literals that hold at the end of at least one successful HTN execution of the program, and the second, weaker notion defines literals that are simply mentioned in the program or in one of its “descendant” programs; such literals may or may not be brought about when the program executes. It is this second notion, called mentioned literals, that we use.

Definition 5
  • If is a program, its mentioned literals (relative to a plan-library and an action-library ), denoted , is the set

We use this weaker notion because the stronger notion of a may summary condition in [6] is not suitable for our approach, which reasons about plans that will not be interleaved with one another—i.e., plans that will be scheduled as a sequence. For example, consider the figure below, which shows a plan-library for going to work on Fridays, possibly one belonging to a larger library from an agent-based simulation. The expressions to the left and right sides of actions/plan-rules are their preconditions and postconditions, respectively.

goToWorkFridays

goToWorkFridaysPlan

travelToWork

work

haveDrinks

intox

travelHome

driveHmPlan

fuelUsed

travelHmByTaxiPlan

travelHmByBusPlan

event-goal

plan-rule

action

Observe that fuelUsed is actually never asserted in the context of the hierarchy shown, because literal (“not intoxicated”) in the context condition of driveHmPlan is contradicted by literal intox. However, the algorithms in [6] will still classify fuelUsed as a may summary condition of plan goToWorkFridaysPlan, because some other plan may have a step asserting —perhaps a step that involves staying overnight in a hotel nearby—that can be ordered to occur between haveDrinks and travelHome.

Since we cannot rely on such steps, we settle for a weaker notion—mentioned literals—than the corresponding definition of a may summary condition. By our definition there can be literals that are mentioned in some plan-body but in fact can never be asserted, because of interactions that preclude the particular plan-body which asserts that literal from being applied. We avoid the approach of disallowing interactions like the one shown above in order to use the stronger notion of a may summary condition because such interactions are natural in BDI and HTN domains: event-goals such as travelHome are, intuitively, meant to be self-contained “modules” that can be “plugged” into any relevant part of a hierarchical structure in order to derive all or just some of their capabilities.

Finally, we conclude this section by combining the above definitions of must and mentioned literals to form the definition of the summary information of a program.

Definition 6
  • If is a program, its summary information (relative to a plan-library and an action-library) is a tuple , where is a precondition of if is an event-goal program, and otherwise; is a set of must literals of ; and is a set of mentioned literals of .

Extracting Summary Information

With the formal definitions now in place, in this section we provide algorithms to extract summary information for event-goals in a plan-library. Moreover, we illustrate the algorithms with an example, and analyse their properties.

Basically, we extract summary information from a given plan-library and action-library by propagating up the summary information of lower-level programs, starting from the leaf-level ones in the plan-library, until we eventually obtain the summary information of all the top-level event-goals.

Algorithm 1  

0:  Plan-library and action-library .
0:  Set of summary info. of event-goal types in .
1:  
2:  
3:  for  to where  do \hfill// Recall is the rank of
4:     for each such that  do
5:         
6:         
7:  return  

   Algorithm 2  

0:  Plan-body ; plan-library ; action-library ; and the set of summary information of primitive programs and event-goal types mentioned in .
0:  The summary information of .
1:   \hfill// We assume variables in are appropriately renamed
2:  Let where each is atomic
3:  
4:  
5:  return  

   Algorithm 3  

0:  Event-goal type ; plan-library ; and the set of summary information of plan-bodies of plan-rules such that .
0:  The summary information of .
1:   and \hfill// are sets of literals and is a set of sets of literals
2:  for each such that  do
3:      \hfill// Relevant variables in and below are renamed
4:     , where
5:     
6:  if  then \hfill// Obtain the must literals of
7:     
8:     
9:  return  

To be able to identify must literals, we need to be able to determine whether a given literal is definitely undone, or must undone, and possibly undone, or may undone in a program. Informally, a literal is must undone in a sequence of atomic programs if the literal’s negation is a must literal of some atomic program in . Formally, then, given a program and the set of summary information of all atomic programs in , a literal is must undone in relative to , denoted , if there exists an atomic program in and a literal , with , such that , that is, is the complement of .

Similarly, we can informally say that a literal is may undone in a program if there is a literal that is a mentioned (or must) literal of some atomic program in such that may become the negation of after variable substitutions. Formally, given a program and the set of summary information of all atomic programs in , a literal is may undone in relative to , denoted , if there exists an atomic program in , a substitution , and a literal ,333variables occurring in are renamed to those not occurring in with , such that .

Algorithm 1. This is the top-level algorithm for computing the summary information of event-goal types occurring in the plan-library. The algorithm works bottom up, by summarising first the leaf-level entities of the plan-library—the primitive programs (line 1)—and then repetitively summarising plan-bodies (Algorithm 2) and event-goals (Algorithm 3) in increasing order of their levels of abstraction (lines 3-6).

Algorithm 2. This algorithm summarises the given plan-body by referring to the set containing the summary information tuples of programs in . First, the algorithm obtains the summary information of each event-goal program in the plan-body from the summary information of the corresponding event-goal types in (line 1). This involves substituting variables occurring in relevant summary information tuples in with the corresponding terms occurring in the event-goal program being considered. Second, the algorithm computes the set of must literals () and the set of mentioned literals () of the given plan-body , by determining, from the must and mentioned literals of atomic programs in , which literals will definitely hold and which ones will only possibly hold on successful executions of (lines 3 and 4). More precisely, a must literal of an atomic program in is classified as a must literal of only if is not may undone in (line 3). Otherwise, is classified as only a mentioned literal of , provided is not also must undone in (line 4). The reason we do not summarise literals that are must undone is to avoid missing must literals in cases where they are possibly undone but then later (definitely) reintroduced, as we illustrate below.

Suppose, on the contrary, that the algorithm does summarise mentioned literals that are must undone. Then, given the plan-library below, the algorithm would (hypothetically) compute the summary information denoted by the two sets attached to each node, the one on the left being its set of must literals and the one on the right its set of mentioned literals.

event-goal

plan-rule

action

Observe that literal asserted by is not recognised as a must literal of simply because it is may undone by mentioned literal of (asserted by ), despite the fact that action of also subsequently adds . On the other hand, our algorithm does recognise as a must literal of by not including in the set of mentioned literals of (line 4).

Algorithm 3. This algorithm summarises the given event-goal type by referring to the set containing the summary information tuples associated with the plan-bodies of plan-rules handling . In lines 2 and 3, the algorithm takes the precondition of the event-goal as the disjunction of the context conditions of all associated plan-rules.444We do not need to “propagate up” context conditions as we do with plan-bodies’ summary information because higher-level context conditions account for lower-level ones due to Definition 2. Then, the algorithm obtains the must and mentioned literals of the event-goal by respectively taking the intersection of the must literals of associated plan-rules (lines 4 and 7), and the union of the mentioned literals of associated plan-rules (line 5). Applying substitution in line 4 helps recognise must literals of , by ensuring that variables occurring in the summary information of its associated plan-bodies have consistent names with respect to .

An illustrative example

We shall illustrate the three algorithms with the example of a simple agent (like the ones in [5]) exploring the surface of Mars. A part of the agent’s domain is depicted as a hierarchy in Figure 1. The hierarchy’s top-level event-goal is to explore a given soil location from current location . This is achieved by plan-rule , which involves navigating to the location and then doing a soil experiment. Navigation is achieved by rules and , which involve moving to the location, possibly after calibrating some of the rover’s instruments. Doing a soil experiment involves the two sequential event-goals of getting soil results for and transmitting them to the lander. Specifically, the former is refined into actions such as determining moisture content and average soil particle size, and transmitting results involves either establishing a connection with the lander, sending it the results, and then terminating the connection, or if the lander is not within range, navigating to it and uploading the soil results. The table in Figure 1 shows the summary information computed by our algorithms for elements in the figure’s hierarchy. Below, we describe some of the more interesting values in the table.

calib

establishCon

breakCon

event-goal

plan-rule

action

Program Must Literals Mentioned Literals
calib cal -
-
-
-
-
-
establishCon cE -
-
breakCon -
-
-
-
-
-
-
-
cal
cal
cal
Same as -
Same as -
cal
Same as Same as
Same as Same as
Figure 1: Must and mentioned literals (right) of atomic programs and plan-bodies in the hierarchy (left). The rightmost column only shows mentioned literals that are not also must literals. Abbreviations in the table are as follows: and variable . Rule ’s context condition binds to the lander’s location. Each plan-body corresponds to rule in the hierarchy.

Plan-body Must literals and of are derived from those of , after renaming variables and to respectively and in line 1 of Algorithm 2.

Plan-body While is a must literal of ’s primitive action , the literal is must undone by ’s last primitive action . Thus, is not a must (nor mentioned) literal of . On the other hand, literal is indeed a must literal of , along with literals and , both of which are derived from the summary information of event-goal .

Plan-body While is a must literal of event-goal , it is only a mentioned literal of because it is may undone in event-goal ; specifically, its mentioned literal is such that for . Similarly, must literal of is also may undone in .

Event-goal Since literal is a must literal of both of the event-goal’s associated plan-bodies and , and also occurs in the event-goal, the literal is classified as a must literal of the event-goal. Recall that this means that for any ground instance of the event-goal, literal holds at the end of any successful HTN execution of .

Soundness and Completeness

We shall now analyse the properties of the algorithms presented. We show that they are sound, and we then discuss completeness. First, it is not difficult to see that the presented algorithms terminate, and that they run in polynomial time.

{theorem}

Algorithm 1 always terminates, and runs in polynomial time on the number of symbols occurring in . Proof. Let be the total number of event-goal types occurring in and . Since a ranking function does exist for , we can rank it as follows. For each event-goal type occurring in that does not also occur in a plan-body mentioned in , we first set to , and then recursively assign the rank to and to its children event-goal types that are either not already ranked or have a higher rank.

Since the remaining algorithms are not recursive, the only non-trivial part is the algorithm for computing a unification in (where is a literal, is a program and is a set of summary information). This was shown to be linear on the number of symbols occurring in the two literals to be unified [14].  \hfill

This result is important when the plan-library changes over time, e.g. because the agent learns from past experience, and summary information needs to be recomputed frequently, or when it needs to be computed right at the start of HTN planning, as done in [24].

The next result states that whenever Algorithm 1 (Summ) classifies a literal as a must literal of an event-goal, this is guaranteed to be the case, and that the algorithm correctly computes its precondition and mentioned literals. More specifically, any computed tuple, which includes one event-goal type , formula and must literals , respects Definitions 3 and 4. Moreover, there is exactly one tuple associated with .

{theorem}

Let be a plan-library, be an action-library, be an event-goal type mentioned in , and let . There exists one tuple , the tuple is the summary information of , and (recall denotes the mentioned literals of ). Proof. We prove this by induction on ’s rank in . First, from our ranking function we obtain a new one by making event-goal ranks “contiguous” and start from .

[Base Case] Let be an event of rank in , that is, . Observe from the definition of a ranking for a plan-library (Definition 1) that if , then . This entails that for all plan-rules such that , no event-goals are mentioned in . There are two cases to consider.

Case 1.1. In the special case where no such plan-rule exists, then the call to procedure in line 6 of procedure returns tuple , which is indeed the summary information of .

Case 1.2. Now consider the case where there are one or more plan-rules in such that for all it is the case that but no event-goals are mentioned in . Let denote the (non-empty) set of all such plan-bodies. Then, we know from Lemma A that, due to line 1 in the algorithm, there is exactly one tuple for each primitive program mentioned in each plan-body , such that the tuple is the summary information of .

Next, observe that before reaching line 6 of procedure , procedure is called in line 5 for each plan-body . Then, from Lemma A, we know that, on the completion of line 5, there is exactly one tuple for each plan-body such that the tuple is the summary information of . Finally, from Lemmas A and A, we can conclude that on the completion of line 6 of the algorithm (i.e., after calling procedure ), there is exactly one tuple such that the tuple is the summary information of . Therefore, the theorem holds for the base case.

[Induction Hypothesis] Assume that the theorem holds if , for some .

[Inductive Step] Suppose . Let . There are two cases to consider.

Case 2.1. First, there is no plan-body such that there is an event-goal mentioned in (i.e., all plan-bodies in mention only primitive programs). Thus, . If , then the proof for this case is the same as Case 1.2 in the Base Case above.

Case 2.2. On the other hand, if , then the proof for this case is the same as Case 1.1 in the Base Case above.

Case 2.3. The third case is that and there exists a plan-body such that an event-goal is mentioned in . Then, let denote the (non-empty) set of event-goal types of all event-goals mentioned in all plan-bodies . From Definition 1 (Ranking), for all event-goals , . Then, by the induction hypothesis, for each , there is exactly one tuple such that the tuple is the summary information of . It is not difficult to see from procedure Summ that all such tuples exist in because the value returned by procedure is added to set in line 6, for each event-goal . After this, since has a higher rank than all , procedure will repeat its outer loop at least one more time (note that there may be other event-goals mentioned in with the same rank as or higher). The procedure will then call , by which point procedure will have already been called for each plan-body , and in turn, each such call will only have occurred after procedure is called for each event-goal .

Then, by Lemmas A and by A and the induction hypothesis, it follows that on the completion of the call to in line 5 for each , there is exactly one tuple such that the tuple is the summary information of . Finally, from Lemmas A and A, we can conclude that after calling procedure in line 6, there is exactly one tuple such that the tuple is the summary information of . Therefore, the theorem holds.  \hfill

Next, we discuss completeness. The theorem below states that any precondition computed by Algorithm 3 is complete: i.e., given any state from where there is a successful HTN execution of an event-goal, the precondition extracted for the event-goal will hold in that state. This theorem only concerns Algorithm 3 because we can compute preconditions of event-goals without needing to compute preconditions of plans.

{theorem}

Let be a plan-library, an action-library, an event-goal type mentioned in , and let . For all ground instances of and belief bases such that there exists a successful HTN execution of with , it is the case that . Proof. If has a successful HTN execution, then there is also a plan-rule associated with such that holds, where is an appropriate renaming of variables in . Since is a disjunct of (line 3 of Algorithm 3), it follows that . (See also proof of Lemma 9.)  \hfill

There are, however, situations where the algorithms do not detect all must literals of an event-goal. The underlying reason for this is that we do not reason about (FOL) precondition formulas; specifically, we do not check entailment, because this is semi-decidable in general [10]. In what follows, we use examples to characterise the four cases in which the algorithms are unable to recognise must literals, and show how some of the cases can be averted.

The first case was depicted in our example about going to work on Fridays: by Definition 4, literal is a must literal of goToWorkFridaysPlan, but Algorithm 2 classifies it as only a mentioned literal, as it cannot infer that the context condition of rule driveHmPlan is contradicted by literal intox, and therefore that driveHmPlan can never be applied.

The second case is where a literal is a must literal simply because it is entailed by a context condition. For example, take an event-goal that is associated with one plan-rule, whose context condition checks whether package is in truck , i.e., , and whose plan-body moves the truck to location . Observe that is a must literal of by definition, but since does not occur in the plan-body, Algorithm 2 does not consider the literal. We do not expect this to be an issue in practice, however, because such literals are accounted for by the event-goal’s (extracted) precondition.

The third case is where must literals are “hidden” due to the particular variable/constant symbols chosen by the domain writer when encoding literals. For example, given the following two plan-rules for an event-goal that sends an email from to , literal is only a mentioned literal of according to Algorithm 3 (line 7 in particular), but a must literal of it by definition:

Nonetheless, by changing to , which then mentions the same variable symbol as the first plan-body, is identified by the algorithm as a must literal of . In general, such “hidden” must literals can be disclosed by choosing terms with appropriate care.

Finally, while Algorithm 2 “conservatively” classifies any must literal that is may undone as a may literal, it could still be a must literal by definition. For example, given an event-goal , suppose that the following plan-rule is the only one relevant for the event-goal:

Then, by Definition 4, both and are must literals of the event-goal, but only is its must literal according to Algorithm 2, because it cannot infer that the context condition entails .555Note that if the context condition is just , then, by definition, would indeed be the only must literal of the event-goal, because it would then be possible for and to have the same value, and for to “undo” . While the algorithm does fail to detect some must literals in such domains, this can sometimes be averted by encoding the domain differently. For example, the above rule can be encoded as an action-rule instead, in which case Algorithm 1 (in line 1) will classify (and ) as a must literal of , under the assumption that action-rules are coherent.

An Application to Planning

One application of the algorithms presented is to create abstract planning operators that may be used together with primitive operators and a classical planner in order to obtain abstract (or “hybrid”) plans. While [7] focuses on algorithms for extracting an “ideal” abstract plan from an abstract plan that is supplied, here we give the details regarding how a first abstract plan may be obtained.

To get abstract operators from a plan-library and an action-library , we take the set and create an (abstract) operator for every summary information tuple . To this end, we take the operator’s name as , appended with its arity and combined with any additional variables occurring in ; the operator’s precondition as ; and its postcondition as the set of must literals .

Since mentioned literals of event-goals are not included in their associated abstract operators, it is crucial that we ascertain whether these literals will cause unavoidable conflicts in an abstract plan found. For example, consider the classical planning problem with initial state and goal state , and the abstract plan consisting of two event-goals (or abstract operators). Suppose and have the following plan-rules:

Notice that the postconditions (must literals) of abstract operators and are respectively and , and that is a classical planning solution for the given planning problem. However, when this plan is executed, if is decomposed using its second plan-rule, this will cause (mentioned literal) to be brought about, thereby invalidating the context condition of (which requires ).

To check for such cases, we present the following simple polynomial-time algorithm. Suppose that is the program corresponding to a classical planning solution for some planning problem, where each (ground) is either an action or event-goal. Then, we say that is correct relative to if for any (ground) literal occurring in the precondition of any , the following condition holds: if is not must undone and it is may undone (relative to ) in the preceding subplan by some mentioned literal of a step in the subplan,666We rely here on a slightly extended version of the definition of may undone from before, to have the exact step () and literal () responsible for the “undoing”. Moreover, observe that literals and are obtained by applying the same substitution that the planner applied to obtain