Content uploaded by Marie desJardins
Author content
All content in this area was uploaded by Marie desJardins on May 16, 2013
Content may be subject to copyright.
Hybrid Planning:
Marie desJardins
SRI International
333 Ravenswood Ave.
Menlo Park CA 94025
marie@erg.sri.com
An Approach to Integrating Generative and
Case-Based Planning
Anthony Francis*
Georgia Institute of Technology
AI/Cognitive Science Group
College of Computing
Atlanta GA 30332-0280
centanr~cc.gatech.edu
Michael Wolverton
SRI International
333 Ravenswood Ave.
Menlo Park CA 94025
mjw@erg.sri.com
Abstract
This paper describes ongoing research on the develop-
ment of a hybrid planning system that integrates case-
based reasoning (CBR) methods into SIPE-2,
t
a gen-
erative planning system. Novel aspects of this work
include the integration of CBR methods with a hier-
archical task network (HTN) planner; the estimation
of adaptation cost based on a classification of planning
conditions; the reuse of plans using SIPE-2’s replan-
ning techniques; the extraction and application of ad-
vice from retrieved cases to guide planning in a form
of plan replay; the representation and use of opaque
constraints, which describe the human planner’s deci-
sion factors; and the provision of case-based support for
managing a distributed, continuous planning process.
Introduction
We are developing a hybrid planning approach that in-
tegrates case-based planning methods into SIPE-2, a hi-
erarchical task network (HTN) planner (Wilkins 1988).
This hybrid planning research is being performed as
part of an applied research project entitled "Joint Mar-
itime Crisis Action Planning (JMCAP)." Crisis action
planning demands quick, continuous, distributed plan-
ning. The goal of the JMCAP project is to provide
support in this environment for mixed-initiative plan-
ning, in which the human planner and the automated
system jointly create a plan. Crisis action planning,
which is currently performed entirely by human plan-
ners, is a mixture of first-principles procedures (e.g.,
Navy and Marine doctrine) and past experience. Pro-
viding mixed-initiative planning support therefore re-
quires the integration of first-principles planning meth-
ods with case-based methods that permit plan reuse.
In addition to this operational motivation, there
are a number of functional reasons to add case-based
methods to a generative planner. The first and most
straightforward of these is performance speed-up. Next,
in a mixed-initiative environment, case-based methods
enable the system to learn over time by recording plan-
ning decisions made by a human. Finally, by noting
*Work performed while at SRI International
tSIPE-2 is a trademark of SRI International
and recording decisions and conflicts in the distributed,
continuous planning process, the system can learn over
time to manage this process more effectively.
The rest of this paper describes our hybrid planning
approach. (This research is in its early stages, and the
approach is only partially implemented.) We first dis-
cuss the natural similarities between SIPE-2’s opera-
tors and cases in a CBR system, and then describe how
cases are represented, created, retrieved, and adapted.
Finally, we briefly describe how we propose to repre-
sent human decision factors and to support distributed
planning, then summarize our conclusions.
Operators and Cases
SIPE-2 uses planning operators (templates describing
how to expand goals into subgoals and tasks) to hierar-
chically decompose high-level goals into low-level (exe-
cutable) actions. Each operator has a purpose, which
describes the type of goal that it can be used to ex-
pand, a set of preconditions, which specify the situations
(world state) for which it is relevant, and plot (expan-
sion), which is a partially ordered network of subgoals
and actions. An operator is indexed by its purpose,
and the preconditions are used to determine whether
to apply the operator in the current situation. When
an operator is matched, the planner expands the goal
by splicing the operator’s plot into the plan where the
goal appears, and adding appropriate constraints and
variable bindings.
We plan to use case-based methods within SIPE-2
by identifying appropriate cases at each level during
the hierarchical decomposition process. This will occur
at run time, at the same time that appropriate opera-
tors are identified. Cases in this system are treated as
generalized operators. The key difference between op-
erators and cases is that cases generally will not match
the situation exactly, so the indexing, retrieval, and ap-
plication methods will differ. During planning, the best
case or operator will be selected (either by the user, or
automatically, using internal evaluation criteria). If an
operator is selected, it will be applied as usual. If a
case is selected, it must be adapted so as to apply to
the current situation. This will be done by means of
45
From: AAAI Technical Report WS-98-15. Compilation copyright © 1998, AAAI (www.aaai.org). All rights reserved.
SIPE-2’s replanning methods or advice extraction (both
described later in the paper).
Case Representation
We have developed a case representation that includes
the problem that the case has solved (analogous to the
purpose of an operator); a plan or plan fragment (anal-
ogous to the plot); the context in which the plan was
applied (analogous to the preconditions); and outcome
information (e.g., execution-time feedback), which may
be used as a factor in case selection.
The core component of a case is the plan it contains.
(The plan is the solution part of the case, in traditional
CBR terminology.) A SIPE-2 plan consists of multiple
levels. The top-level plan is the initial problem (the
highest-level goal(s) to be achieved). Each level below
the top level is a partially ordered network of subgoals
and actions that describes an intermediate plan expan-
sion. A goal at level i is linked to its expansion at
level i ÷ 1 through descendant and ancestor links. The
expansion, or plan wedge, is simply the plot of the op-
erator that was applied to expand the higher-level goal.
As the subgoals are expanded, all of the ordering links
are maintained, and new links can be introduced by the
planner to order actions in parallel branches (e.g., to en-
able the effect of an action introduced by one operator
to satisfy a precondition required by another).
The context of the case consists of the conditions in
the current situation that are relevant to the application
of the cases, as discussed in the next section; and the
human decision factors associated with the plan, which
are discussed below ("Plan Rationale").
Case Indexing
The hybrid planner must provide efficient mechanisms
for storing plans as cases in the libraries, and indexing
them to facilitate their retrieval and reuse. In partic-
ular, the system must identify features (such as objec-
tives and constraints) for indexing the stored plans.
Recent results in case-based reasoning research sug-
gest that ease of adaptation is a useful similarity met-
ric (Smyth & Keane 1995). Projecting the adaptation
cost of a case is in general a difficult problem, but SIPE-
2’s rich plan representation helps us to do this. Embed-
ded in the plan structure is a record of how the planning
operators were applied to produce the plan; the opera-
tors themselves encode information about their applica-
bility. We identify relevant preconditions on which the
original plan depends, then classify these into condition
classes according to the expected cost of violating them,
as discussed in the next section.
To determine these relevant preconditions, we
have extended PRODIGY/Analogy’s footprint index-
ing method (Veloso 1995). The footprint of a goal
problem is the subset of the initial world state that
has contributed to the solution of the goal--that is, the
conditions that have made a solution possible, or in-
fluenced the structure of a solution. In STRIPS-based
planners like PRODIGY/Analogy, computing the foot-
print of a goal involves regression from the goal back
through the preconditions of the operator network to
the literals of the initial world state. In hierarchical
planners like SIPE-2, computing the footprint is simi-
lar, but requires a slightly more complex process to an-
alyze the plan structure below the goal (i.e., the goal’s
expansion). (A detailed description of this algorithm
beyond the scope of this paper.)
Footprint Condition Classes
SIPE-2 splits the necessary conditions for an operator’s
application into two sets: the subgoals that it must try
to achieve, and the preconditions that make it valid.
SIPE-2 will not try to make a precondition true: if an
operator’s precondition cannot be satisfied (by a pred-
icate in the initial world state, or by an effect of an
action that appears earlier in the plan), the operator is
invalid and will not be considered for application.
We can segregate the footprint of a goal into condi-
tions that support subgoals, and conditions that sup-
port the operator preconditions. For plan adaptation in
SIPE-2, precondition support is more important than
goal support. If a condition that supported a subgoal
is missing in a new situation, the rest of the plan is
not necessarily invalidated: an adaptation process can
likely replan for the open goal without disturbing the re-
mainder of the plan. But if a condition that supported
a precondition is missing, that operator is invalid, and
the entire plan wedge corresponding to the operator’s
expansion must be removed.
We have developed a set of condition classes that can
be used to further distinguish among types of precon-
dition support. These condition classes can be under-
stood by considering the operators that were used to
generate the plan. First, a precondition may be unique
to an operator and incompatible with the preconditions
of other operators. For example, in the maritime plan-
ning domain, there might be several operators that de-
scribe strategies to perform noncombatant evacuation,
each tailored to a specific type of terrain. In this case,
changing the terrain would force us to select another
operator. We refer to a condition that satisfies this
type of precondition as a hinge: the operator choice is
effectively determined by the presence or absence of the
condition.
Another important situation arises when all opera-
tors that can achieve a goal depend on a single shared
precondition: for example, all operators that achieve
the goal to evacuate noncombatants on rigid inflatable
boats (RIBs) depend on the weather being appropriate
(the waters must be calm). If this condition is not satis-
fied, the planner will not be able to find a new operator
to achieve this goal--the goal itself, along with the op-
erator that introduced it at the higher level, must be
replanned. We refer to this kind of initial condition as
a linchpin: removing it makes higher-level portions of
the plan fall away.
46
In summary, we distinguish the following qualitative
classes of conditions in the initial world state of a plan,
listed in order of increasing importance (or, more ac-
curately, in order of increasing cost of repairing a plan
when they are violated):
¯
External: a condition in the initial world state that
does not support a precondition or goal of the plan.
Removing such a condition will not change the formal
properties of the plan (although the condition may be
highly significant to the user).
¯ Phantomizing (or Goal): a condition that phan-
tomizes a goal, and therefore can likely be replanned
for if removed.
¯ Enabling (or Precondition): a condition that
makes aa operator precondition true, and that would
invalidate a plan wedge if removed.
¯
Hinge: a subclass of preconditions that determine an
operator choice--i.e., that discriminate among sev-
eral operators that solve the goal.
¯ Linchpin: a subclass of preconditions that uniquely
allow us to satisfy a particular goal--i.e., all operator
choices that can satisfy this goal require this precon-
dition.
We expect that the actual cost of violating a given
class of precondition will be largely domain dependent.
(Costs include both computational costs and time de-
lays in the planning cycle.) We plan to apply adaptive
techniques to learn these costs empirically.
Case Retrieval
Retrieving cases from a library requires that the cur-
rent and past problems and situations be compared, to
determine which cases are most similar or most applica-
ble. The hybrid planner will use the footprint condition
classes described above to index plans in the library.
The planner will also retrieve plans that are estimated
to require the least adaptation cost. This estimation
will be based on the expected violation costs of the
conditions in the retrieved case that fail to match the
current situation.
Other retrieval criteria we are investigating include
the use of domain-specific knowledge to compute a
weighted match (e.g., matching higher-level objectives
and operational constraints is more important than
matching low-level details such as available resource
types); additional plan analysis to estimate the cost of
replanning to adapt the retrieved plan; and extracting
advice before storing a case to use as additional indices
(see "Plan Replay--Advisable Planning").
Case Adaptation
Once a case has been retrieved, it must be applied, us-
ing the differences between the initial situation and the
current situation to adapt the solution. We are ex-
ploring two approaches to case adaptation: reuse and
replay. In case reuse, the case consists of a description
of a problem, and an associated solution, which is re-
trieved and spliced into the plan. In case replay, on
the other hand, a trace of the original planning process
is stored and used to solve the new problem by guid-
ing the search, essentially creating an analogy of the
previous solution in the current context. SIPE-2’s plan
structure already records all of the planning decisions
and constraints, so only minimal extensions to the rep-
resentation are required to support both plan reuse and
plan replay.
We are extending existing SIPE-2 components to pro-
vide these two approaches to case adaptation, and will
then explore heuristic methods for deciding which of
the two approaches is appropriate for any given case
retrieval. SIPE-2’s replanner serves as the core for the
plan reuse system, and the Advisable Planner is the
foundation for plan replay. These are described in the
following subsections.
Plan Reuse----Replanning in SIPE-2
Plan reuse in SIPE-2 entails adjusting the initial condi-
tions of the retrieved plan to match the new situation,
eliminating invalid or irrelevant parts of the retrieved
plan, adding new goals that may have been absent in
the original plan, and eliminating the goals in the case
that are not part of the new problem.
Adjusting the initial conditions requires matching the
objects and predicates in the retrieved case to the cur-
rent situation. SIPE-2’s replanner already does part of
this work, but it has only a limited ability to rebind
variables, so we are extending the replanner to do more
sophisticated variable matching and rebinding.
Plan critics within SIPE-2 are used during both plan-
ning and replanning to evaluate the quality of partial
or complete plans along multiple dimensions (e.g., re-
source utilization, temporal constraints, and interaction
of parallel actions). The replanner applies the plan crit-
ics to an existing plan (the retrieved case), using an up-
dated situation description (the current situation), and
detects failed preconditions and phantoms that are no
longer valid. These failures cause wedges of the plan to
be spliced out and replanned.
The hybrid planner can additionally introduce new
top-level goals that did not appear in the retrieved plan,
or delete goals that are not relevant in the current sit-
uation. The new goals are incorporated into the plan
network at the top level, and expanded via the nor-
mal plan expansion methods (i.e., operator expansion
or the use of additional cases). Deleted goals are re-
moved from the plan network, which entails removing
the plan wedges corresponding to the goals’ expansions.
After a goal is deleted, the replanner again applies the
critics to determine whether other parts of the plan de-
pended on conditions produced in this wedge.
Unfortunately, in some circumstances the replanner
may eliminate more of the plan than necessary: for ex-
ample, a high-level operator might be invalidated, even
though most of the wedge beneath it would remain valid
once replanning was complete. The replanner cannot
47
preserve this valuable past planning knowledge; this is
one of the cases where the system can apply the plan
replay methods we introduce next.
Plan Replay--Advisable Planning
The Advisable Planner (AP) was originally developed
to support mixed-initiative planning by allowing a user
to specify constraints on a plan in the form of ad-
vice (Myers 1996). AP implements three classes of ad-
vice: role advice (what objects should fill certain vari-
ables in a plan), method advice (what types of opera-
tors should be used to solve certain goals), and sketch
advice (what specific operators should be used to solve
certain goals under certain conditions).
We are using AP to develop a plan replay mechanism
that is more flexible than traditional replay. Advice will
be extracted from a plan and used for case indexing, re-
trieval, and adaptation (by applying the advice in the
new planning process). One straightforward approach
to advice extraction is to use each operator application
in the plan to encode a piece of sketch advice. More
sophisticated approaches could be used to detect the
objects or classes of operations used in the plan. We
also expect to identify new advice types (e.g., repre-
senting a decision to defer the expansion of a particular
goal) that would be useful in case adaptation.
Extracting advice from retrieved plans provides a
natural way to handle multiple-goal problems not ad-
dressed by any single case in the case base. Compos-
ing the advice extracted from two single-goal plans per-
mits the planner to be guided by both plans simultane-
ously. There is a potential for conflicts or redundancy,
but SIPE-2’s plan critics will identify and resolve these
problems.
Plan Rationale
In the current implementation, retrieved cases are as-
sumed to be complete SIPE-2 plan structures. We plan
to relax this assumption by developing methods to in-
corporate incomplete plan structures that are provided
by a plan authoring system or another external source.
These plans will most likely be missing important in-
formation, such as decision points, preconditions, and
a detailed situation description. To support the use of
these external plans, we are developing a language for
annotating a plan structure. This language will include
decision factors used by a human planner that are out-
side SIPE-2’s automated reasoning capabilities.
We propose to model human decisions as opaque
constraints--that is, the system will record that the hu-
man planner has made a decision, or indicated that a
property of the situation was important, but that the
system does not necessarily know why. While the sys-
tem may not be able to fully reason about these opaque
constraints, it will be able to partially determine when
they are violated, and use that partial information to
interactively (with user support) resolve the conflict,
order to adapt a retrieved plan appropriately.
Distributed Planning
One of the major objectives of the JMCAP project is
to develop techniques for distributed, continuous plan-
ning. To this end, we have developed a distributed ver-
sion of SIPE-2 (desJardins & Wolverton 1998; Wolver-
ton & desJardins 1998) in which multiple communicat-
ing planning agents cooperate to develop an integrated,
consistent joint plan. We envision two ways in which
hybrid planning will support the distributed aspects of
our planning system.
First, cases can support the process of assigning sub-
goals to the agents who will solve them. Whenever a
planning agent generates a new subgoal, it makes the
decision whether to solve the subgoal itself or to as-
sign the subgoal to another agent that it thinks can
solve it. By extending our case representation to in-
clude successful past goal-to-agent assignments, CBR
can support the planning agent’s decision by allowing
the system to allocate similar goals to similar agents
in similar future situations. This support is analogous
to the way that cases store successful operator appli-
cations: in both situations, CBR selects a method of
solving a goal that has a history of success in similar
situations, or that a human operator had reason to se-
lect; the only difference is that the "method of solving
a goal" now is the assignment of that goal to another
agent instead of a planning operator.
Second, cases can be used to store extracted advice
at the metalevel in order to avoid and resolve con-
flicts during distributed planning. Planning successes
and failures, along with any conflict resolution actions
taken, will be recorded and stored with the case, and
will be converted into advice to guide the new planning
process. This recorded information will include back-
tracking points and reasons, plan repairs performed at
execution time in response to execution failures or op-
portunistic goal achievement, and conflicts that arise
during distributed planning or plan merging. These re-
trieved cases will be used to guide the distributed plan-
ning process, by suggesting the information require-
ments of distributed agents and the planning choices
that are most likely to minimize conflicts.
Conclusions
We have described a hybrid planning approach that in-
tegrates case-based methods into a generative planning
system (SIPE-2). This work is preliminary, but rep-
resents a significant advance in the state of the art of
case-based and generative planning integration.
Acknowledgments
This research was funded by the Office of Naval Re-
search (ONR) and the Space and Naval Warfare Sys-
tems Command (SPAWAR) under contract N66001-97-
C-8515. The authors would like to thank Mr. Dave
Swanson, JMCAP Project Manager at SPAWAB., for
inputs and feedback. Thanks also to Karen Myers and
David Wilkins of SRI International for their contribu-
tions to this work.
References
desJardins, M., and Wolverton, M. J. 1998. Coor-
dinating planning activity and information flow in a
distributed planning system. In desJardins, M., ed.,
AAAI Fall Symposium on Distributed Continual Plan-
ning. AAAI Press Technical Report (forthcoming).
Myers, K. L. 1996. Advisable planning systems. In
Tate, A., ed., Advanced Planning Technology. AAAI
Press.
Smyth, B., and Keane, M. 1995. Experiments on
adaptation-guided retrieval in a case-based design sys-
tem. In Veloso, M., and Aamodt, A., eds., Case-
Based Reasoning Research and Development. New
York: Springer Verlag. 313-324.
Veloso, M. M. 1995. Planning and Learning by Ana-
logical Reasoning. Springer-Verlag.
Wilkins, D. E. 1988. Practical Planning: Extending
the Classical AI Planning Paradigm. Morgan Kauf-
mann.
Wolverton, M. J., and desJardins, M. 1998. Con-
trolling communication in distributed planning using
irrelevance reasoning. In AAAI-98. To appear.
Appendix
1. Integration name/category: JMCAP hybrid
planning
2. Performance task: Hierarchical plan generation in
a military (maritime planning) domain
3.
Integration objective: Efficiency (computational
and user interaction), reuse of expert decision-making
criteria
4. Reasoning components: Plan retrieval,
constraint-based plan adaptation (repair), advice ex-
traction for plan reuse, plan merging, footprint ex-
traction (indexing)
5. Control architecture: Primarily CBR as slave
6. CBR cycle step(s) supported: Retrieval, Reuse,
Revision, Merging, Retention
7. Representations: Plans, advice
8. Additional components: User interaction (during
retrieval and repair)
9. Integration status: Proposed
10.
Priority future work: Implementation, develop-
ment of case library, empirical evaluation.