Identifying executable plans

Tania Bedrax-Weiss∗ Jeremy D. Frank Ari K. J´onsson† Conor McGann∗ NASA Ames Research Center, MS 269-2 Moffett Field, CA 94035-1000, {tania,frank,jonsson,cmcgann}@email.arc.nasa.gov

Abstract AI solutions for planning and plan execution often use declarative models to describe the domain of interest. Generating plans for execution imposes a different set The planning system typically uses an abstract, long- of requirements on the planning process than those im- term model and the execution system typically uses a posed by planning alone. In highly unpredictable ex- ecution environments, a fully-grounded plan may be- concrete, short-term model. In most systems that deal come inconsistent frequently when the world fails to with planning and execution, the language used in the behave as expected. Intelligent execution permits mak- declarative model for planning is different than the lan- ing decisions when the most up-to-date information guage used in the execution model. This approach en- is available, ensuring fewer failures. Planning should forces a rigid separation between the planning model acknowledge the capabilities of the execution system, and the execution model. The execution system and the both to ensure robust execution in the face of uncer- planning system have to agree on the semantics of the tainty, which also relieves the planner of the burden plan, and having two separate models requires the sys- of making premature commitments. We present Plan tem designer to replicate the information contained in Identification Functions (PIFs), which formalize what the planning model in the execution model. Since much it means for a plan to be executable, and are used in conjunction with a complete model of system behavior of the knowledge may be shared between the planning to halt the planning process when an executable plan is and execution systems, this produces a model synchro- found. We describe the implementation of plan identifi- nization problem. Furthermore, if the execution system cation functions for a temporal, constraint-based plan- wants to relay information back to the planner, in this ner. This particular implementation allows the descrip- scenario, the information has to be translated. Not us- tion of many different plan identification functions. ing the same language may be detrimental because syn- chronization and translation may introduce errors and Introduction increase model engineering effort. If both the execution and planning systems have a Planning has been an important problem in Artifcial common language, then information from and to the Intelligence, but plan execution is a problem that AI executive can flow seamlessly. Furthermore, changes has often overlooked. In fairly simplistic and highly- in the planning model are then automatically propa- predictable environments, the planning system can gated to the execution model. In addition, it is easier hand a fully-grounded plan to the execution system and to modify the boundary between planning and execu- the execution system will be able to execute it flaw- tion systems in such systems. Even if a single model for lessly. However, in unpredictable environments, a fully planning and execution is not available, there are still grounded plan will often result in execution failures. good reasons for making it easy to vary the boundary Additionally, it is inefficient for the planning process between planning and execution systems using a single to commit to decisions in advance that are likely to be model of system behavior. Many candidate execution invalidated during execution. One way to avoid these systems may be available; identifying the right one re- problems is to have an intelligent execution system that quires a planning model that can be used with any one is able to “fill in the blanks” given a plan that is not of the possible execution systems. fully grounded. Intelligent execution may range in com- executable plan plexity from fairly simple computations to a process re- An is a plan that the execution sys- sembling full-blown planning. Depending on the char- tem can make any remaining decisions and then trans- acteristics of the execution environment, the best plan late the result into commands that can be sent to the to hand to the execution system will contain more or hardware with which the system is interacting. Based less commitment and information. on this notion, the “executability” of a plan depends di- rectly on the capabilities of the execution system. For 1QSS Group, Inc. a general model of system behavior, we would like to 2Research Institute for Advanced Computer Science specify which parts of that model describe the commit- ments that should be made by the execution system. Models of System Behavior In this paper we provide the formalism and implemen- The system model defines the set of possible states tation of Plan Identification Functions PIFs . These and actions, along with rules that specify allowed functions exactly characterize the executable plans in and forbidden relations between actions and states. a model that is shared between the planner and the The states and actions are defined by predicates like executive. Thus, they serve to separate the duties of pointingAt(object) and slewFromTo(obj1, obj2). planning by partitioning the planning problem into a We define a partial plan as a collection of temporal pred- set of commitments that are made in advance, and a icate statements, based on a given model. We assume set that are interleaved with plan execution. that the parameter set for each predicate doesn’t have We will proceed by presenting a simple example to to be fully grounded. This notion naturally supports clarify some of these notions. more flexible planning paradigms such as those used in constraint-based planning systems. A Simple Example The rules in the system model specify, directly or To examine the issues involved in generating plans for indirectly, the conditions for a state or action being in execution, let us consider a simple spacecraft that can the plan: slew (i.e, turn to different orientations), take pictures, • which instantiations of state/action predicates are and download pictures to Earth. valid A plan request for this spacecraft might consist of a set of picture requests, and then a request for down- • for each action/state, what other states or actions loading some or all of these pictures to Earth. The must exist in the plan to support it planning process would generate an “executable plan” • the temporal and parametric relations between states that achieved those goals. The execution agent would and actions then execute the plan by thrusting to rotate the space- craft, activating camera components, and transmitting For example, a model for our simple spacecraft data. would state that the predicates include pointingAt, slewingFromTo, takePicture, download A traditional approach to this problem would be . Legal in- based on separating the planning from execution at stantiations of slewingFromTo are limited to those some specific level of abstraction. For example, the where the origin and destinations are not the same, and takePicture planning process might involve generating slew ac- instantiations are limited to objects and tions, orientation maintenance actions, picture-taking times where an overly bright object, like the sun, is not actions, and download actions. The complete plan, at in the frame. There are a number of relations between takePicture that level of abstraction, would then be executed by predicates in this model; for example, a breaking each high-level action down into specific com- must be done within a period where the spacecraft is mands that together perform the action. The slew ac- pointing at the object in question. This means that pointingAt tions, for example, would be broken down into engine there must be a predicate in the plan, and warmup, thruster firing, wait, opposite thruster firing, that furthermore, the appropriate pointingAt must takePicture and then stabilization. The sequence of execution com- have the same object value as the , must takePicture mands would have to fit within the time allocated to start no later than the and must end no the slew action. earlier than the takePicture. If the execution system is sophisticated, it could de- It should be noted that this core approach covers ba- termine how fast to slew, since the slewing rate is con- sic STRIPS-like descriptions, where states are preserved trolled by the time spent firing the engines at the start by the frame axioms and action definitions define state and end of the slew. Slower slew rates typically save changes. It also covers constraint-based approaches, fuel. The execution system might also be able to deter- with and without an explicit representation of time or mine when to start activities that have some temporal resources. Furthermore, in STRIPS, the initial state flexibility. Rather than waiting until the next action and goal statements are simply part of a partial plan start time, which is bound to be later rather than ear- that must be extended to include the actions necessary lier, to provide a safety margin, the execution system to go from the initial state to a goal state. Since both could determine that all earlier actions have been com- planning and execution use the same model, the plan is semantically meaningful to both the planner and the pleted, that the action in question can start as early as 1 a given time, and then start that action at that time. executive . In the Remote Agent Experiment (JMM+00; The rest of the paper is organized as follows. We MNP+98), the planning process built a partial plan first provide a formal definition of PIFs and character- where certain temporal decisions were left to the ex- ize some useful properties of PIFs . We then describe ecution engine. These temporal decisions were limited an implementation of PIFs in a planning framework to those that together formed a simple dispatchable net- called EUROPA. We identify some important imple- work (MMT98). However, as noted in (JMM+00), the mentation details that arise when implementing PIFs notion of retaining flexibility in the executed plan can 1This idea is borrowed from (MDF+02), which we de- be generalized to an arbitrary set of decisions. scribe later in the paper. in this framework. We then conclude and discuss sev- In constraint-based planning, partial and complete eral open issues. plans are represented as networks of intervals. The con- nections between intervals in such a network are defined Plan Identification by the configuration rules. We now turn our attention to formally defining the con- Partial plans and completions cepts related to general plan identification. We begin In CBP, a partial plan consists of a set of intervals and with a general and expressive approach to planning, a set of constraints among the variables representing which supports arbitrary variables, quantitative tem- those intervals. poral relations, arbitrary constraints, and expressive A partial plan P is valid, if for every applicable con- activity-state rules. figuration rule, all the intervals and constraints required P P instanti- Constraint-based planning by those rules are in . A partial plan is ated, if each variable has been given a single value. A In order to address realistic problems, a planning partial plan P is consistent if none of the constraints in paradigm must support actions and states with tem- the plan are violated and inconsistent otherwise. poral extent, complex relations among action and state A planning problem is simply a partial plan. This arguments, as well as complex model rules about condi- notion generalizes the very restrictive STRIPS notion tions and effects of actions and states. In recent years, of only specifying an initial state and a set of goals. The different approaches have been proposed for moving notion of a planning problem as a partial plan allows away from the classic STRIPS paradigm, and towards specific actions as goals, supports the specification of more realistic approaches that incorporate explicit rep- maintenance goals, makes it easy to define exogonous resentations of time and resources. These approaches events, and much more. Planners can modify plans in fall into a broad category called Constraint-Based Plan- two ways. A restriction is defined as the binding of a ning (CBP) (SFJ00). variable or the addition of a constraint. A relaxation is The basic idea behind CBP is to use variables to defined as the unbinding of a variable or the removal of represent all aspects of states and actions, and to use a constraint. An extension of a given partial plan, P , is constraints to enforce relations between those variables. a plan Q such that each interval in Q can be mapped to The basic element in constraint-based planning is an in- a compatible interval in P , and each constraint in P is terval. An interval is simply a predicate holding over a in Q. Thus, restricting a plan P results in an extension period of time. The start and end of the interval and Q, and relaxing a plan Q0 results in a plan P 0 such that the parameters of the predicate are described by vari- Q0 is an extension of P 0. ables. More formally, an interval is a tuple, (p, X, s, e), A partial plan, Q is complete if every interval is in- where B is a predicate name, X is a vector of variables stantiated and the plan is valid. Q is a completion of defining the arguments to the predicate, and s and e every relaxation of Q. We say that a problem instance are temporal variables, defining the start and end of P has a solution if it has a consistent completion Q. the interval. The strictest notion of solving a planning problem P A planning domain is defined by the set of interval is to find a consistent completion of P . However, a more types, and a set of configuration rules. A configura- general notion is much more useful when it comes to tion rule is a generalization of the notion of precon- planning for execution agents that are not completely ditions and effects. Instead of specifying only state trivial in complexity. In essence, solving a planning values before and after an action, a configuration rule problem P for an intelligent execution agent involves can specify arbitrary temporal relations specifying how finding a consistent extension Q that can be executed by actions and states must relate in a valid plan. This the given execution agent. We now turn our attention means that a configuration rule can specify that when- to a general formulation of such a notion. ever an attribute is assigned an interval of a certain kind, other intervals must exist in the plan, such that Plan identification functions specific constraints are satisfed. In addition to tem- Consider a partial plan encountered during the course poral constraints, configuration rules can specify other of planning. We would like a declarative description constraints amongst the parameters of the actions and of the set of plans that can be accepted for execution states. by the execution system. This is the notion of plan In our spacecraft example, identification functions (PIFs ). The basic idea is to consider a takePicture(x) interval, I, for the cam- have a mapping that indicates whether or not a partial era attribute. A configuration rule might specify that plan is suitable for a given execution engine or not. there must be a pointingAt(y) interval, J, such that Identifying inconsistency is a natural complement to x = y, the start of J is at least 10 seconds before the plan identification. Consider a partial plan that has start of I, and the end of J is no earlier than the end no valid completions. In a sense, the partial plan is of I. Notice that the latter constraint in the rule is not a dead-end. However, it is computationally expensive strictly a precondition or an effect, but only involves to determine whether any given partial plan is incon- temporal constraints. sistent or not. Consequently, it is useful to think of a “consistency identification function” that maps partial YES plans to T, F, or ?, where the T value indicates that the Flaws == {} plan is consistent, F indicates it is inconsistent, and ? Model PlanId indicates that the consistency of the plan is not known. The original notion of a PIF appeared in (JMM+00). Flaws != {} This definition combined the notion of consistency with NO executability, and used three return values, T, F and ? A return value of F indicated that the plan violated some Partial Plan constraint, i.e. no extension of the plan was consistent, which forced the planner to backtrack. A return value Figure 1: The Plan Identification Function as a Flaw of T indicated that all intervals were valid and consis- Filter tent according to a set of applicable configuration rules, and thus planning was complete. A return value of ? indicated that the plan was consistent but not valid, plans that require only a bounded amount of time to and thus the planner had to continue searching for an solve. In cases where a PIF returns inconsistent plans extension. to the executive, it is also useful to characterize the In this paper, we define a more relaxed notion of a amount of time that search in the infeasible space is plan identification function. A PIF maps partial plans performed. Because of the different search procedures to the values Y and N. A return value of Y indicates required we provide two definitions below. a plan is executable and a return value of N indicates We first want to formally characterize an executive a plan is not executable. Keeping the definitions as that can efficiently ensure a completion of a consistent general as possible, we do not pose any more restrictions plan can be found, if one exists. A PIF , i, enforces on the evaluations of partial plans. For example, it is O(f(n)) solvability if, for any consistent partial plan P possible that plan execution systems may be based on satisfying i(P ) = y, then in time O(f(|P |)) either a technology that works in the space of inconsistent plans, consistent completion of P can be found or it can be and thus we want to be able to specify PIFs that are shown that no consistent completion of P exists. able to pass inconsistent plans to the execution system. We therefore look at specific characteristics of PIFs that On the other hand, if the executive is handed an in- are desirable in certain cases. consistent plan, the problem is somewhat different. In this case, no completion is possible. Instead, we must Characteristics of plan identification find a completion of the original planning problem that functions the planner attempted to solve. Suppose the original planning problem is R. A PIF , i, enforces O(f(n)) Regardless of the impact of execution, we assume that a transformability if, for any partial plan P satisfying P partial plan must be consistent when the plan execu- i(P ) = y, then in time O(f(|P |)) a series of transfor- tion commences. We also assume that the instructions mations of P resulting in a Q, a consistent completion the execution system issues to the underlying hardware R, can be found, or it can be shown that no such com- are based on fully instantiated plans. If either of these pletion exists. conditions is not satisfied, then the plan execution sys- tem must be able to come up with a consistent complete plan. Examples The simplest question one can ask of a plan handed to the execution system is whether it has a consistent completion. In most (but not all) cases, such correct- In the Remote Agent Planner, the PIF accepted only ness would be a crucial characteristic of an executable consistent and valid plans where all parameter variables plan. had been assigned specific values, but tolerated unas- signed temporal variables forming a dispatchable simple A PIF , i, enforces correctness if, for any partial plan + P , such that f(P ) = y, P has at least one consistent termporal network (JMM 00). The restriction that the completion. resulting temporal network be dispatchable made the The next question is how much work needs to be done PIF correct and provided a linear bound on how much by an execution engine to find a consistent completion time it would take the execution engine to complete a in different circumstances. This is a particularly inter- given plan. This is an O(n) solvable PIF . esting question if uncertainty during execution is taken Recent techniques have extended the ability of execu- into account. tion systems to handle uncertainty in temporal quan- A PIF , i, enforces solvability if, for any partial plan tities. In particular, (MMV01) presents an algorithm P , such that i(P ) = y, all extensions of P are complete that can detect when a temporal network with uncer- and consistent. tainty can be executed without failure, and (MM01) It is often difficult to find plans satisfying the above presents an algorithm for executing such networks in property without finding a complete plan to begin with. polynomial time. Thus, we can write PIFs for such As such, it is useful to identify PIFs that return partial problems that are O(f(|P |)), where f is a polynomial. From Plan Identification to Flaws EUROPA

We have formally defined the PIF as a function from Planner a plan and a model to an answer of either Y or N. In practical applications, however, a planner using the PIF Plan would like further indication of what is wrong with the Identification plan when the answer is N. A more useful notion of a PIF , depicted in Figure 1, is one that given a plan and a model, returns a set of possible plan modifications if Plan Database the answer is N and the empty set if the answer is Y. Model Token Network We refer to the set of plan modifications as flaws. A flaw is a modification to a partial plan, either a Constraint Execution restriction or a relaxation. Let F(P ) be the set of flaws Network System derived from plan P . We can now redefine a PIF as a F(P ) Partial Plan Temporal Partial Plan’ mapping: F(P ) → 2 . That is, the PIF identifies a Network (possibly proper) subset of the flaws that define the set of plan modifications that a planner can make. The set of flaws can be defined in different ways de- pending on how the planner conducts search. For ex- Figure 2: Planning For Execution With EUROPA ample, suppose the partial plan has valid extensions. Then the set of flaws might consist only of the set of restrictions that a planner can impose in its search for a In our spacecraft example, the state of the camera completion that satisfies the PIF . However, a planner might be one attribute. When a picture is being taken, such as ASPEN (FRCY97) can benefit from flaws that the camera takes on the state takePicture, otherwise, are restrictions or relaxations, since it can search the the state is cameraIdle or slewingFromTo. Similarly, space of infeasible solutions. the attitude of the spaccraft could be another attribute, Notice that it could require exponential space to de- whose values are instantations of slewingFromTo and fine very complex plan identification functions if it were pointingAt. necessary to enumerate all the possible sets of flaws and A partial plan in EUROPA consists of a mapping of the mapping that applied for each of those flaw sets. attributes to sequences of intervals, a set of free inter- Practicality dictates that we have a concise manner of vals, and a set of constraints on variables in the given both expressing and evaluating PIFs . intervals. Free intervals are intervals that have not been sequenced on attributes yet. We assume for simplicity An Implementation of Plan that the set of flaws of a partial plan is comprised of Identification free intervals and unbound variables 2. A plan identifi- cation function, then, takes the set of free intervals and We have implemented the notion of a PIF as a flaw unbound variables in the plan database and returns a filter in the context of the Constraint-based Attribute subset of these in response to a query from the planner. and Interval Planning framework (FJ03) (CAIP), in the Figure 2 shows the overall architecture of EUROPA system called EUROPA (Extensible Universal Remote in the context of planning for execution. The system is Operations Planning Architecture). In this section we composed of the following modules: a planner, a plan first give an overview of EUROPA, then describe the database, and a plan identification module. Planning PIF implementation. Further details on EUROPA im- begins with a partial plan and a domain model. The plementation can be found in (FJ03); in this section, we plan database is initialized with the partial plan and focus on those aspects that are most relevant to PIFs . the model. During planning, a planner can query the plan database through the plan identification module EUROPA Overview for flaws in the initial partial plan. Flaws are defined in CAIP is an extension of CBP. Like the basic constraint- terms of the model configuration rules and the PIF acts based planning paradigm, intervals provide the basic as a filter. If no flaws remain and the plan is consistent, representation of actions with durations and states with the planner concludes that a plan has been found. If temporal extent. The key addition is in the notion of an flaws remain, however, the planner makes commitments attribute. An attribute represents some system, subsys- to resolve the remaining flaws by updating the plan tem or other aspect of the domain for which planning is database. The planner thus alternates between asking being done. An attribute can only take on one value at the plan identification module for flaws and updating a given time, so attributes enforce a mutual exclusion the plan database until a plan that satisfies the model relation among intervals that are assigned to the same and the PIF is found. attribute. In addition, each interval must be placed on 2Note that this set of flaws is only useful for planners that an attribute. This requirement enforces mutual exclu- search in feasible space, but EUROPA can support other sion among all intervals. flaws as well. In the EUROPA plan database, predicate arguments, LEGEND timepoints, and attributes of an interval are represented predicate Interval Temporal as variables. Configuration rules impose constraints on Variable Precedence Equality the values these variables can take. The plan database Constraint Constraint manages the variables and constraints and makes use of a temporal network to maintain consistency between temporal variables and the temporal relationships im- Camera off ready takePic(B) posed by the configuration rules. The plan database also uses a constraint network to maintain consistency among all other variables and constraints. Consider the following simple model of the spacecraft Attitude pointAt(A) domain. The first half of the model specifies the inter- vals that can appear on each attribute, and the second half specifies the configuration rules. We use the simple temporal relations of Allen’s Algebra to specify con- pointAt(D=d) turnTo(C) straints between the timepoints of required intervals. We also assume that parameters of different intervals with the same variable name require the parameters to Figure 4: A simple partial plan for the model described take on the same value. in Figure 3

Attitude:{pointAt(object), turnTo(object)} Camera:{off(), ready(), takePic(object)} In EUROPA, the parameter equivalence is handled Take-Picture(B) → met-by ready() by creating a new variable for the required turnTo inter- Take-Picture(B) → contained-by pointAt(B) val and posting an equivalence constraint between the ready() → met-by off() parameters. In this example, the parameter C of the pointAt(B) → met-by turnTo(B) turnTo predicates has been equated with the param- eter A of the sequenced pointAt() interval. Finally, Figure 3: A simple model of the spacecraft domain. we note that C has not been bound to any particular value, while parameter D of the other turnTo has been EUROPA enforces configuration rules by means of bound to value d. the following plan invariant: whenever a plan modifica- tion results in a change to the set of plan completions, Plan Identification in EUROPA the intervals in the plan are updated. New intervals In EUROPA, the PlanId function is implemented as are added as free intervals. In the case of relaxations, a filtering operation on the set of flaws in the plan some intervals that were part of the plan may no longer database. To support this, the system must provide be justified, and if so, the intervals and all associated capabilities to: variables and constraints are removed. In the case of re- strictions, new intervals, variables and constraints may 1. obtain access to the set of flaws in the plan database; be needed in the plan, and if so, they are added. 2. define a filter expressing criteria for including or ex- Figure 4 shows a plan fragment based on the simple cluding a flaw; model. The Camera attribute is initially turned off, then it is ready, and then it is taking a picture. While the 3. obtain a set of filtered flaws by applying such a filter. Camera is taking a picture of the object, the Attitude These capabilities are accomplished by providing: is pointing at the object. Notice that there are two free intervals, one with predicate turnTo and one with pred- 1. a flaw storage mechanism, referred to as the icate pointAt. The free interval turnTo was generated FlawCache, which keeps the set of flaws in the plan by the plan invariant, while the free interval pointAt database synchronized with changes made through was part of the initial problem instance. explicit commitments by the planner or derived Consider the interval pointAt(A) which is in- through inference. serted on the Attitude attribute. In this case, the 2. a highly customizable filtering structure which allows rule pointAt(B) → met-by turnTo(B) means that pre-defined conditions and/or new custom conditions if a pointAt(B) interval exists in a plan, then a to be seamlessly integrated in a single filter. turnTo(B) must preceed the pointAt(B). The pres- 3. a flaw querying facility which handles all access to ence of the pointAt(A) interval forces the addition the FlawCache and applies filtering criteria defined of the free turnTo(C) interval due to the plan invari- by the planner. ant. Similarly, if the pointAt(A) interval is removed from the Attitude attribute, then the free interval The remainder of this section describes in more detail TurnTo(C) is no longer justified, and is removed from the framework developed to achieve this in an efficient the plan. and customizable manner. Planner Planner and event-based synchronization leads to efficient im- plementation. LEGEND Module Filter Condition Condition while(done==false) Criteria Class Flaw if (isConsistent()) Query Flaw Connection A B A contains B filteredFlaws=getFlawsFromQuery() Query if (filteredFlaws.isEmpty()==false) A B A calls B nextFlaw = choose(filteredFlaws) Plan FlawCache Identification 1 or more resolve(nextFlaw) Module instances else done=true else... // rest of the algorithm omitted Plan Datbase end while

Figure 5: Class Diagram of the PlanId Framework Figure 6: Planning with Flaw Queries. Framework Class Diagram Figure 5 presents the internal details of the PlanId mod- Step 1: PlanDatabase ule referenced in Figure 2. The gener- FlawCache={A, B, C,pointAt(D = d),turnTo(C)} ates events indicating changes to intervals and variables FilteredFlaws:{A, B, C,pointAt(D = d)} when the plan invariant is invoked. These events are re- nextFlaw: pointAt(D = d) FlawCache ceived by the and used to maintain the set Step 2: of all flaws in the system, i.e. all free intervals and un- FlawCache={A, B, C, E,turnTo(C),turnTo(E)} bound variables. Events indicating a restriction may FilteredFlaws:{A, B, C, E} FlawCache cause a flaw to be removed from the e.g. in- nextFlaw: E serting a free interval or assigning a value to an unbound Step 3: variable. Events indicating a relaxation may cause a FlawCache={A, B, C}turnTo(E = d),turnTo(C)} FlawCache flaw to be inserted into the e.g. relaxing to FilteredFlaws:{A, B, C} domain of a variable or freeing an inserted interval. nextFlaw: A A planner creates a FlawQuery at the beginning of the planning process. It is by means of a FlawQuery that a planner obtains the relevant subset of flaws as indicated by a filter. Planner-specified filters are de- Figure 7: Evolution of the flaws for the partial plan in fined in a FilterCriteria object, which is just a collec- Figure 4. tion of Conditions. Each FlawQuery has exactly one FilterCriteria instance, provided to it during con- To see how the flaw filtering works, consider the sam- struction. Condition objects provide the customiza- ple partial plan shown in Figure 4. There are five tion necessary for planners to filter out flaws they wish flaws: the variables A, B and C, the turnTo(C) inter- to ignore. For a Flaw in the FlawCache to be returned val and the pointAt(D = d) interval; the FlawCache by a FlawQuery, all Conditions must be satisfied. has these five flaws. Now suppose that the PIF fil- In order to gain access to the set of flaws and the set of ters out intervals with predicate turnTo. Then the set flaw changes, each FlawQuery establishes a Connection of filtered flaws consists of the three variables and the with the FlawCache. A Connection provides access pointAt(D = d) interval. to all flaws in the FlawCache. A Connection also The basic loop of a planner is similar to the fragment provides a location to store information on changes presented in Figure 6. At each step, the planner re- in the FlawCache since the the FlawQuery was last quests the filtered flaws. Once the flaws are retrieved, queried. Notifications of changes in the contents of the the planner uses some criteria to select a flaw, then uses FlawCache, i.e. flaws inserted or removed, are pushed another criteria to resolve the flaws. Application of the to each connection from the FlawCache as the latter is plan invariant and propagation of variable changes in synchronized with the PlanDatabase. the constraint network result in updates to the Flaw- This architecture provides a number of useful fea- Cache. Subsequent queries to the FlawQuery will re- tures. First, the FlawCache can support many con- turn a new set of flaws that accounts for these updates nections at once, enabling it to provide flaws to many and the filtering of these flaws by the PIF . planners. Second, a wide variety of simple conditions To see this process in action, let us consider a few are provided, enabling a very large number of different steps of planning given the partial plan and PIF that we PIFs to be expressible. Third, it is very straightforward have described. This process is shown in Figure 7. Let to develop additional conditions making the approach us assume that choose selects flaws according to some very extendible. Finally, emphasis on lazy evaluation arbitrary order. Also suppose that resolve performs an insertion for free intervals or a variable assignment for if it belongs to one of the intervals that falls within the unbound variables. After inserting pointAt(D = d) horizon. we see that the plan invariant ensures the creation of The time at which an event actually occurs is usu- a turnTo(E) interval. The FlawQuery, however, indi- ally different from the planned time. This difference cates that the set of filtered flaws at step 2 only includes can sometimes prove costly since it may cause some as- the variables A, B, C, E. At the next step, choose() re- sumptions that were made in the planning stage to fail. turns flaw E; there is only one possible value, d, and In EUROPA, the temporal network is implemented as thus the plan invariant doesn’t lead to the creation of a Simple Temporal Network (DMP91). Simple Tempo- any new variables or intervals. ral Networks guarantee that if the network is consistent, Such a simple filter could be achieved with a sin- an appropriate set of bindings of the temporal variables gle condition which would check the predicate name of can be found in polynomial time. Thus, if the tempo- each interval flaw and exclude it if it matched the name ral network is consistent, no further commitments on turnTo. time have to be made during planing. This is assuming that the executive is intelligent enough to be able to EUROPA Plan Identification Function find this appropriate set. A PIF provides the means to Capabilities define this flexibility if it implements a condition that EUROPA’s PIF framework supports the following con- filters temporal variable flaws. If no temporal variable ditions, among others: flaws are passed on to the planner, these decisions will remain unbound (though constrained by the temporal • Interval predicate filtering - filters all intervals of a network) until execution time. particular predicate. Overcommitment at planning time may prove costly • Interval variable filtering - filters selected variable of in other ways. In cases where a plan consists of high- all intervals with a particular predicate. level and low-level tasks, the low-level task expansion • Attribute filtering - filters all intervals and all vari- of the high-level tasks may depend highly on when the ables of all intervals from a particular attribute. tasks get executed. In such cases, it is convenient to let the execution system map high-level tasks into low- • Temporal filtering - filters intervals according to a level tasks during execution. This frees the planner variety of temporal specifications. One example is a from generating low-level tasks, and allows the execu- filter for intervals guaranteed not to happen within a tive to choose the low-level tasks that best fit the actual temporal extent (a horizon filter). execution. In EUROPA, high-level and low-level tasks In practice, different applications will impose differ- can be placed on separate attributes. A PIF provides ent requirements on plan executives. In an execution the means to define this flexibility by implementing a environment that is uncertain, there are advantages to condition that filters flaws depending on whether they not fully specifying a plan. To be robust against un- are allowed to be placed on high-level attributes or not. certainty in the execution environment a plan must be A free interval can be placed on a high-level attribute flexible. For instance, if decisions cannot be determined if it belongs to the set of allowable states of that at- in advance because the way in which they are made de- tribute. An unbound variable belongs to the high-level pends on factors that are only determined at execution attribute if it belongs to an interval that can be placed time, it may be advantageous to leave these decisions on the attribute. up to the execution system. The PIF framework al- There are instances of planning for execution when lows considerable latitude in defining the capabilities some planning decisions inside one execution cycle may of execution systems, and thus enables the planning determine what will happen in a future execution cycle. technology to be more widely useful. However, it also These commitments are sometimes unnecessary, espe- provides considerable flexibility within a single applica- cially in uncontrolled execution environments. These tion. Engineers can design different PIFs and analyze planning decisions may manifest themselves as particu- the resulting performance of the integrated planning lar predicate logic statements or as arguments to pred- and execution system, and choose the PIF that works icate logic statements. A PIF povides the means to best. delay commitment on these predicates or variables by An execution system will typically only care about implementing a condition that filters flaws on whether the plan developing inside the current execution win- they are based on these predicates or variables. dow. If this execution system is implemented as a plan- ner, a PIF could be used to focus the planning effort Complexity Analysis on that execution window only using the horizon fil- In the simplest implementation, one could omit the ter. Such a PIF would contain a horizon condition that FlawCache and Connection infrastructure. Resolving a would specify, for each free interval and each unbound query would be accomplished by iterating over all inter- variable, whether it falls within the horizon or not. A vals and variables in the plan database and for each, ap- free interval falls within the horizon if its start time and plying the filter to test for inclusion or exclusion. This end time variable domains include the horizon time- would result in a worst-case time-complexity given by points. An unbound variable will fall inside the horizon (Nv + Ni) ∗ Nc ∗ Cc where Nv is the number of vari- ables, Ni is the number of intervals, Nc is the number under uncertainty. Cypress enables human intervention of conditions in the filter, and Cc is the average cost of during planning and plan execution. Cypress uses the evaluating a condition. 3 ACT representation to model both planning and execu- Since the points of greatest cost are in the evalua- tion. The boundary between SIPE and PRS is flexible, tion of conditions, we seek to reduce the execution of as PRS can invoke SIPE to handle run-time plan fail- condition tests. This is accomplished in a numnber of ures. However, there is no facility in Cypress to describe ways: the boundary between the planner and plan execution in a declarative way. 1. The last set of filtered flaws are cached in each + + FlawQuery. The Remote Agent (RA) (MNP 98; JMM 00) is an agent architecture for spacecraft control that was used 2. The current set of flaws in the plan database are in a 2-day experiment of an autonomous probe. The RA cached in the FlawCache. consisted of a planner, a plan execution system, and a 3. Each cache is maintained through notifications of mode identification and reconfiguration system. The changes. RA planner built plans that were temporally flexible so that the plan execution system could decide on-the-fly 4. Conditions may be ordered to fail fast, based on the which tasks to start and end (MMT98). This repre- characteristcis of each problem. sented a significant advance at the time; however, other 5. The FlawQuery is updated only when the planner applications using the RA could not use any other di- consults it for the latest set of flaws. Thus, the vide between planning and execution. Furthermore, the queries are only run on the set of flaws that were three components of the system used different modeling added since the last query. languages with different semantics, requiring consider- The resulting worst-case cost of a query is approx- able effort to ensure model synchronization. IDEA (MDF+02; DLM03) is an agent architecture imated by: N+ ∗ Nc ∗ Cc where N+ is the number of flaws inserted into the flaw cache since the last query.4 designed to overcome shortcomings in the RA approach The approximation omits the cost of caching events to agent modeling. IDEA provides a simple virtual during synchronization of the FlawCache and the Plan- machine that supports plan execution, consisting of a Database. This is reasonable since the costs of caching model, plan database, plan runner, and reactive plan- are much less than the cost of evaluating the conditions ner. The job of the reactive planner component of an over all insertions. Notice that we do not need to worry IDEA agent is to ensure that a “locally executable” plan about flaws that are removed from the cache, since they is returned. Thus, a crucial task is to define the scope aren’t returned to the planner in any case. of the Reactive Planner’s job. The PIF is a natural way to focus on those parts of the model that must be ad- Related Work dressed by the Reactive Planner. IDEA also supports many planners operating on the same plan database, A wide variety of agent architectures have been de- and thus the same model. PIFs are a natural way signed to support both planning and execution. We to define the scope of these various planners in order will not describe all aspects of these systems here. We to ensure that planners do not step on each others’ will describe how these systems characterize the bound- toes. IDEA also supports multi-agent architectures us- ary between planning and execution, and compare it to ing inter-agent communication. The original notion of the approach we have described here. IDEA is to separate models for each agent; these mod- Many integrated planning and plan execution frame- els are intended to be written in the same language and works define a fixed boundary between their compo- share components. Partial plans serve as the medium nents. These systems also use different modeling lan- by which planners communicate with the executive, as guages, in some cases with different semantics, and thus well as the medium by which IDEA agents communi- have potential problems with model synchronization. cate with each other. However, the PIF can (in prin- Finally, these systems do not have a crisp declarative ciple) be used to simply divide up the model amongst characterization of the boundary between the compo- the agents in a similar manner to the way it divides up nents. Examples of integrated planning and plan exe- models amongst planners; the crucial problem to solve cution systems in this category are O-Plan (TDK94), is dividing plan databases efficiently among the IDEA 3T (BFG+97), and Propice-Plan (DI99). agents. Cypress (WMLW95) is a planning and plan execu- tion framework designed for a variety of applications, Conclusions and Future Work including military operations. Cypress is a loosely cou- We have described plan identification functions as a way pled integration of the SIPE planner, the PRS reactive of circumscribing the planning problem that must be execution system, and Gister-CL system for reasoning solved in order to create an executable plan. PIFs have 3In practice only some of the conditions will be executed the advantage of enabling a single model to character- since we discard the flaw after the first condition fails. ize both the planning problem and the plan execution 4 N+ << (Ni + Nv) since there are relatively few flaw problem. They also enable easy characterization of the insertions resulting from each planner commitment. boundary between planning and plan execution, even in cases where different models for planning and execu- A. J´onsson, P. Morris, N. Muscettola, K. Rajan, and tion are used. They also provide considerable flexibil- B. Smith. Planning in interplanetary space: Theory ity, as they allow the boundary between planning and and practice. In Proceedings of the Fifth Interna- execution to be adjusted. We have described the im- tional Conference on Artificial Intelligence Planning plementation of the PIF framework of EUROPA, and and Scheduling, 2000. shown how it can be used to implement many PIFs for N. Muscettola, G. Dorais, C. Fry, R. Levinson, and different type of plan execution systems. C. Plaunt. Idea: Planning at the core of autonomous We have implicitly assumed that a single model of reactive agents. In Proceedings of the 3d International system behavior can be written, so that PIFs can be NASA Workshop Planning and Scheduling for Space, used to separate the part of system behavior that per- 2002. tains to the execution system. The IDEA project + N. Muscettola and P. Morris. Execution of tempo- (MDF 02) is pursuing this notion, but it remains to ral plans with uncertainty. In Proceedings of the 17th be seen how the concepts extend to more sophisticated National Conference on Artificial Intelligence, 2001. planning and control architectures. P. Morris, N. Muscettola, and I. Tsamardinos. Re- We have described one way of using PIFs to divide a formulating temporal plans for efficient execution. In model amongst many planners. This approach does not th Proceedings of the 15 National Conference on Arti- address important architectural issues of mutli-agent ficial Intelligence, 1998. access to a shared plan representation. It also doesn’t address the issue of how to structure the plan represen- N. Muscettola, P. Morris, and T. Vidal. Dynamic con- trol of plans with temporal uncertainty. In Proceedings tations used by planners and executives. The efficient th implementation of PIFs may be impacted by this archi- of the 17 International Joint Conference on Artifi- tecture. cial Intelligence, 2001. Note that while the plan that is passed to the ex- N. Muscettola, P. Nayak, B. Pell, , and B. Williams. ecutive may define a set of plan completions, there is Remote agent: To boldly go where no ai system has no reason to assume that the executive chooses one of gone before. Artificial Intelligence, 103(1-2), 1998. these completions, and in fact no way to characterize D. Smith, J. Frank, and A. J/‘onsson. Bridging the the actions of the executive in a declarative way. gap between planning and scheduling. Knowledge En- PIFs can be used for more than just separating plan- gineering Review, 15(1), 2000. ning from the execution system. One can also imagine A. Tate, B. Drabble, and R. Kirby. O-plan2: An open partitioning the planning problem into many different architecture for command, planning and control. In- problems using a collection of PIF functions. telligent Scheduling, 1994. D. E. Wilkins, K. L. Myers, J. D. Lowrance, and L. P. References Wesley. Planning and reacting in uncertain and dy- namic environments. Journal of Experimental and R. Bonasso, R. Firby, E. Gat, D. Kortenkamp, Theoretical Artificial Ingelligence D. Miller, and M. Slack. Experienences with an ar- , 7(1), 1995. chitecture for intelligent, reactive agents. Journal of Experimental and Theoretical Artificial Ingelligence, 9(2), 1997. O. Despouys and F. Ingrand. Propice-plan: Towards a unified framework for planning and execution. In Pro- ceedings of the 5th European Conference on Planning, 1999. M. Dias, S. Lemai, and N. Muscettola. A real-time rover executive based on model-based reactive plan- ning. In Proceedings of the International Conference on Robotics and Automation, 2003. R. Dechter, I. Meiri, and J. Pearl. Temporal constraint networks. Artificial Intelligence, 49:61–94, 1991. J. Frank and A. J´onsson. Constraint based attribute and interval planning. Journal of Constraints, To Ap- pear, 2003. A. Fukunaga, G. Rabideau, S. Chien, and D. Yan. To- ward an application framework for automated plan- ning and scheduling. In Proceedings of the 15th In- ternational Joint Conference on Artificial Intelligence, 1997.