Ordered Task
Decomposition:
Theory and Practice
Part 2
Dana S. Nau
Dept. of Computer Science, and
Institute for Systems Research
University of Maryland, College Park, MD
Nau: PLANET, 2000
1
Approach (and Outline)
Day 1
Day 2
Theory
1. Principles of
HTN planning
2. Computer
bridge
4. Ordered Task
Decomposition
3. Electronic Design
and Manufacturing
5. SHOP
6. Evacuation
planning
Applications
 Very quick review
 Comments
 Continue where I left off
Nau: PLANET, 2000
2
What Activities Should a Planning
System Plan?
 In AI planning, researchers traditionally have only
allowed the planner to plan activities that will have a
direct physical effect
 Examples:
 picking up a block
 moving a truck
 In human planning, we also plan lots of other activities
Nau: PLANET, 2000
3
What Activities Should a Planning
System Plan?
 In AI planning, researchers traditionally have only
allowed the planner to plan activities that will have a
direct physical effect
 Examples:
 picking up a block
 moving a truck
 In human planning, we also plan lots of other activities
 Example 1:
 Planning information-gathering operations
travel by air
airport(x,a) airport(y,b) ticket (a,b) travel (x,a) fly(a,b) travel(b,y)
Nau: PLANET, 2000
4
What Activities Should a Planning
System Plan?
 In AI planning, researchers traditionally have only
allowed the planner to plan activities that will have a
direct physical effect
 Examples:
 picking up a block
 moving a truck
 In human planning, we also plan lots of other activities
 Example 2:
 Planning bookkeeping operations
travel by air
airport(x,a) airport(y,b) ticket (a,b) store some info travel (x,a) fly(a,b) travel(b,y)
about the ticket
Nau: PLANET, 2000
5
What Activities Should a Planning
System Plan?
 In AI planning, researchers traditionally have only
allowed the planner to plan activities that will have a
direct physical effect
 Examples:
 picking up a block
 moving a truck
 In human planning, we also plan lots of other activities
 Example 3:
 Planning when/how to create and retrieve plans
travel by air
plan how to travel to Cyprus
store this plan into the current state
Nau: PLANET, 2000
finish work
at the office
pack for
the trip
execute the
stored plan
6
Homework Assignment
 Yesterday, I asked you to formulate and execute a plan
for going to the beach
 Analyze that plan, to see if it contains any of the
following activities:
(1) information-gathering operations
(2) bookkeeping operations
(3) planning when/how create and retrieve plans
Nau: PLANET, 2000
7
Concrete Example
 Malik Ghallab and Piergiorgio Bertoli and I plan to go
bicycling on Sunday (instead of going to the barbecue)
 One part of the plan:
 Find a bicycle shop
 Find out if they have suitable bicycles
 If so, then plan how to go to it
 This involves information-gathering, bookkeeping, and
planning when to do other planning
Nau: PLANET, 2000
8
Concrete Example
 Malik Ghallab and Piergiorgio Bertoli and I plan to go
bicycling on Sunday (instead of going to the barbecue)
 One part of the plan:
 Find a bicycle shop
 Find out if they have suitable bicycles
 If so, then plan how to go to it
 This involves information-gathering, bookkeeping, and
planning when to do other planning
 Another information-gathering part of the plan:
 Would you like to join us?
 If so, please let us know!
Nau: PLANET, 2000
9
Review of
Ordered Task Decomposition
 Goal-directed, but generates actions in the same order in
which they will later be executed
 Whenever we want to plan the next task
 we’ve already planned everything that comes before it
…
task tm
s0
op1
s1
op2
s2
…
task tn
Si–1
opi
…
 Thus, we know the current state of the world
Nau: PLANET, 2000
1
Answer to a Question from Yesterday
 Question: Suppose there’s an action b
that will come late in the plan
and will cause a lot of backtracking. m1
 In this case we might like to plan
a1 b
for b first. Won’t total-order
planning preclude us from doing that?
Nau: PLANET, 2000
task t
m2
a2
m3
b
a3
m4
b
a4
1
b
Answer to a Question from Yesterday
 Question: Suppose there’s an action b
task t
that will come late in the plan
and will cause a lot of backtracking. m1
 In this case we might like to plan
a1 b
for b first. Won’t total-order
planning preclude us from doing that?
 Answer: Not necessarily
m2
a2
m3
b
a3
m4
b
a4
b
task t
 One way to do it:
Tell the planner to create a plan for b
and retrieve that plan later
find a plan p for b
m
store p
m1
a1
Nau: PLANET, 2000
do p
task t’
m2
a2
do p
m3
a3
m4
do p
a4
do p
1
Answer to a Question from Yesterday
 Question: Suppose there’s an action b
task t
that will come late in the plan
and will cause a lot of backtracking. m1
 In this case we might like to plan
a1 b
for b first. Won’t total-order
planning preclude us from doing that?
 Answer: Not necessarily
m2
a2
m3
b
a3
m4
b
a4
b
task t
 Another way to do it:
Tell the planner to start by checking
m
b’s preconditions, without
check b’s preconditions
actually planning for b
m1
a1
Nau: PLANET, 2000
task t’
m2
b
a2
m3
b
a3
m4
b
a4
b
1
Answer to Another Question
 Question: With total-order planning,
task t
can we interleave subgoals?
m1
load a
Nau: PLANET, 2000
load b
m2
deliver a
deliver b
1
Answer to Another Question
 Question: With total-order planning,
task t
can we interleave subgoals?
 Answer:
m1
m2
 Not in SHOP, because all of the
subtasks will be totally ordered load a load b deliver a deliver b
 Sometimes we can circumvent
this, by using methods that put
task t
the subtasks into a different order
load all
deliver all
 In some cases this is natural;
in other cases it is clumsy
load a
load b
deliver a
deliver b
 We have an extension to the
SHOP algorithm called M-SHOP
[Nau et al., TR, 2000], in which some
of the subtasks can be unordered
Nau: PLANET, 2000
1
two different
task lists
Answer (Continued)
 Basic idea for M-SHOP:
load and deliver a
load and deliver a
 When we have several task
m1
m2
lists without an ordering
between them, do this:
load a deliver a
load b deliver b
loop
if all of the task lists are empty, then exit
remove the first item from one of the task lists
decompose it, and put its subtasks at the front of the task list
repeat
 Need a way to handle protected conditions
 How we do this is described in [Nau et al., 2000]
 M-SHOP is available at http://www.cs.umd.edu/projects/shop
as part of the latest software distribution for SHOP
 Currently they are separate programs
 In the next release, they’ll be merged into a single program
Nau: PLANET, 2000
1
Answer (Continued)
 M-SHOP doesn’t fully
implement partially
ordered task lists
 It can take multiple task lists
load and deliver a
m1
load a
deliver a
load and deliver a
m2
load b
deliver b
as part of its input
 It doesn’t allow methods to have subtasks that are partially
ordered
 However
 To allow methods to have partially ordered subtasks is an easy
generalization
 We’ve written down the algorithm, but haven’t implemented it yet
Nau: PLANET, 2000
1
Review of the SHOP Algorithm
state S; task list T=( t ,t ,…)
1 2
procedure SHOP (state S, task-list T, domain D)
operator instance o
1.
if T = nil then return nil
2.
t1 = the first task in T
state o(S) ; task list T=(t2, …)
3.
U = the remaining tasks in T
4.
if t is primitive & an operator instance o matches t1 then
5.
P = SHOP (o(S), U, D)
nondeterministic choice
6.
if P = FAIL then return FAIL
among all methods m
7.
return cons(o,P)
whose preconditions
8.
else if t is non-primitive
can be inferred from S
& a method instance m matches t1 in S
& m’s preconditions can be inferred from S then
9.
return SHOP (S, append (m(t1), U), D)
10. else
task list T=( t1 ,t2,…)
11.
return FAIL
method instance m
12.
end if
end SHOP
task list T=( u1,…,uk ,t2,…)
Nau: PLANET, 2000
1
Encoding the Blocks World Algorithm
into SHOP
loop
if there is a clear block x such that
x or a block beneath x is in a location inconsistent with the goal
and
x can be moved to a location such that
x and all blocks beneath x will be in locations consistent with
the goal
then move x to that location
else if there is a clear block x such that
x or a block beneath x is in a location inconsistent with the goal
then move x to the table
else exit
endif
repeat
Nau: PLANET, 2000
1
How to Encode
“x or a block beneath it is in a location inconsistent with the goal”
(:- (need-to-move ?x)
;; need to move x if x needs to go from one block to another
((on ?x ?y) (goal (on ?x ?z)) (different ?y ?z))
;; need to move x if x needs to go from table to block
((on-table ?x) (goal (on ?x ?z)))
;; need to move x if x needs to go from block to table
((on ?x ?y) (goal (on-table ?x)))
;; need to move x if x is on y and y needs to be clear
((on ?x ?y) (goal (clear ?y)))
;; need to move x if x is on z and something else needs to be on z
((on ?x ?z) (goal (on ?y ?z)) (different ?x ?y))
;; need to move x if x is on something else that needs to be moved
((on ?x ?w) (need-to-move ?w)))
Nau: PLANET, 2000
2
Example (Continued)
loop
if there is a clear block x such that
x or a block beneath x is in a location inconsistent with the goal
and
x can be moved to a location such that
x and all blocks beneath it will be in locations consistent with
the goal
then move x to that location
else if there is a clear block x such that
x or a block beneath x is in a location inconsistent with the goal
then move x to the table
else exit
endif
repeat
Nau: PLANET, 2000
2
Operators for Moving Blocks
(:operator (!pickup ?x)
((clear ?x) (on-table ?x))
((holding ?x)))
c
(:operator (!putdown ?x)
((holding ?x))
((on-table ?x) (clear ?x)))
(:operator (!stack ?x ?y)
((holding ?x) (clear ?y))
((on ?x ?y) (clear ?x)))
a
b
a
a
b
c
b
c
a
b
c
(:operator (!unstack ?x ?y)
((clear ?x) (on ?x ?y))
((holding ?x) (clear ?y)))
Nau: PLANET, 2000
2
Example (Continued)
loop
if there is a clear block x such that
x or a block beneath x is in a location inconsistent with the goal
and
x can be moved to a location such that
x and all blocks beneath it will be in locations consistent with
the goal
then move x to that location
else if there is a clear block x such that
x or a block beneath x is in a location inconsistent with the goal
then move x to the table
else exit
endif
repeat
Nau: PLANET, 2000
2
Representing Tasks
Initial state:
(clear c)
(clear b)
(on c a)
(ontable b)
(ontable a) (handempty)
c
a
b
Goals: a
(on a b) b
(on b c)
c
 Suppose we use the task list
 ((achieve (on a b)) (achieve (on b c)))
 This won’t do what we want
 First it will perform the task (achieve (on a b))
 Then it will perform the task (achieve (on b c))
 Instead, we need a task list something like
 ((achieve (on a b) (on b c)))
 Need to keep track of
 which goals we have achieved and need to preserve
 which goals remain to be achieved
 How to do this?
Nau: PLANET, 2000
2
Bookkeeping
 Keeping track of what the goals are
 Insert information about this into the current state
 This is convenient because it lets us use precondition-matching
to match methods to goals
 Keeping track of the goals that we have achieved and
need to preserve
 Insert information about this into the task list
 Could also have put this into the current state instead

That’s what we do in other domains, such as the logistics
domain [Nau et al., 2000]
Nau: PLANET, 2000
2
Bookkeeping Operator and Methods
(:operator (!assert ?atoms) ; ?atoms is a list of atoms to assert
()
; no preconditions
?atoms
; put the list of atoms into the current state
0)
; this operator has no cost
(:method (assert-goals (?first . ?rest) ?atoms)
()
'((assert-goals ?rest ((goal ?first) . ?atoms))))
; recursively build a list
; of atoms to assert into
; the current state
(:method (assert-goals nil ?atoms) ; we’ve built the entire list, so assert it
()
'((!assert ?atoms)))
(:method (achieve-goals ?goals)
; assert all the goals into the current state,
()
; then call move-block to achieve them
'((assert-goals ?goals nil) (move-block nil)))
Nau: PLANET, 2000
2
if there is a clear block x such that
- x or a block beneath x is in a location inconsistent with the goal and
- x can be moved to a location such that x and all blocks beneath it
will be in locations consistent with the goal
then move x to that location
(:method (move-block ?nomove)
;; method for moving x from y to z
(:first (clear ?x) (eval (not (member '?x '?nomove))) (on ?x ?y)
(goal (on ?x ?z)) (different ?x ?z) (clear ?z) (not (need-to-move ?z)))
'((!unstack ?x ?y) (!stack ?x ?z) (move-block (?x . ?nomove)))
;; method for moving x from y to table
(:first (clear ?x) (eval (not (member '?x '?nomove)))
(on ?x ?y) (goal (on-table ?x)))
'((!unstack ?x ?y) (!putdown ?x) (move-block (?x . ?nomove)))
;; method for moving x from table to y
(:first (clear ?x) (eval (not (member '?x '?nomove)))
(on-table ?x) (goal (on ?x ?y)) (clear ?y) (not (need-to-move ?y)))
'((!pickup ?x) (!stack ?x ?y) (move-block (?x . ?nomove)))
…
Nau: PLANET, 2000
2
else if there is a clear block x such that
x or a block beneath x is in a location inconsistent with the goal
then move x to the table
else exit
endif
(:method (move-block ?nomove)
…
;; method for moving x out of the way
((clear ?x) (eval (not (member '?x '?nomove)))
(on ?x ?y) (need-to-move ?x))
'((!unstack ?x ?y) (!putdown ?x) (move-block ?nomove))
;; if none of the above preconditions were satisfied, then we're done
nil
nil)
Nau: PLANET, 2000
2
Question
 I can run SHOP on the blocks world for you right now.
 Would you like me to do so?
Nau: PLANET, 2000
2
Experimental Comparison
 Experimental comparison
 Planning domains:
 Blocks world
 Logistics
 UM Translog
 Planning systems compared:
 Blackbox - Graphplan plus satisfiability
 IPP
- Graphplan plus ADL
 TLplan
- forward search with modal-logic pruning rules
 UMCP
- “classical” HTN planning
 SHOP
- Ordered Task Decomposition
Nau: PLANET, 2000
3
Time
Blocks World
 100 randomly
generated problems
 167-MHz Sun Ultra
with 64 MB of RAM
 Blackbox and IPP
could not solve
any of these problems
 TLplan’s running time
was only slightly worse
than SHOP’s
Number of actions in plan
 TLplan’s pruning rules
[Bacchus et al., 2000]
have expressive power
similar to SHOP’s
 Using its pruning rules,
they encoded a blockstacking algorithm
similar to ours
Nau: PLANET, 2000
3
Logistics
 110 randomly
generated problems
 Same machine
as before
 As before, Blackbox
and IPP could not
solve any of these
problems
 TLplan ran
somewhat slower
than SHOP
(about an order of
magnitude on large
problems)
Nau: PLANET, 2000
Time
Number of actions in plan
3
Logistics (Continued)
 30 problems from




the Blackbox
distribution
SHOP and TLplan
on the same
machine as before
Blackbox on a faster
machine, with 8GB
of RAM
SHOP was about an
order of magnitude
faster than TLplan
TLplan was about
two orders of
magnitude faster
than Blackbox
Nau: PLANET, 2000
Time
Number of actions in plan
3
UM Translog
 HTN planning domain [Andrews et al., 1995]
 Inspired by the logistics domain, but about an order of magnitude
larger
 Several different kinds of packages, vehicles, and procedures for
handling the packages
 e.g., hazardous materials need special handling
 Several dozen primitive operators
 Several dozen methods
 Typical problems: dozens of vehicles, dozens of packages
 SHOP versus UMCP
 UMCP [Erol, 1994] is our “classical” HTN planner
 Couldn’t test the other planners
 Difficult to translate this domain into an action-based format
 Will say more about this later
Nau: PLANET, 2000
3
UM Translog (Continued)
 100 randomly
Time
generated problems
 Same machine
as before
 UMCP did much
worse than SHOP
Number of actions in plan
Nau: PLANET, 2000
3
Digression: Translating HTN Problems
into Action-Based Planning Problems
 Can we compare these results with those of
action-based planners (IPP, Blackbox, etc.)?
 Problem:
 HTN planning is strictly more expressive then
STRIPS-style planning (Erol et al. 1994)
 HTN problems from domains that include
unbounded recursion among their methods cannot
be expressed in STRIPS
 However:
 UM-Translog does not include recursive methods
at all
 For such cases, Amnon Lotem [Lotem & Nau,
2000] has defined an algorithm that translates an
HTN domain into a STRIPS domain
Nau: PLANET, 2000
m1
m1
m1
...
3
HTN-to-STRIPS Algorithm
HTN
Operator
Preconditions
STRIPS
Operator
Add Effects
p1
Load
p2
e1
Preconditions
Add Effects
p1
Load
p2
e1
Load-completed
Artificial
predicate
Nau: PLANET, 2000
3
HTN-to-STRIPS Algorithm
HTN
Method
STRIPS
Operator
Preconditions
Load-top
(?p, ?t, ?o)
m
Door-open
Load Door-closed
(?t)
(?p, ?t, ?o)
(?t)
Add Effects
Door-opencompleted
(?t)
Loadcompleted
(?p, ?t, ?o)
op-m
Artificial
operator
Load-topcompleted
(?p, ?t, ?o)
Door-closedcompleted
(?t)
Nau: PLANET, 2000
3
Translating UM-Translog into STRIPS
 Lotem used the algorithm to translate a subset of the
UM-Translog domain into a STRIPS-style representation
 There were several problems with that approach:
 Poor readability of the resulting domain(artificial operators and
predicates)
 The artificial operators can be filtered out from the final solution,
but we cannot guarantee minimal parallel length of the reported
plan
 A huge number of instantiated actions. Only very simplified
versions of the test problems could be solved using Blackbox
and IPP.
Nau: PLANET, 2000
3
Manual Encoding of UM-Translog
Specs
Manual
HTN Encoding
STRIPS-Style Encoding
Translation
Algorithm
operators
methods + operators
 Guidelines:
 Do not create artificial operators
 Keep the domain compact (smaller number of instantiated actions)
 Findings:
 It was difficult to express such a spec by using only operators.
 Many operators became context-specific to preserve order constraints
 Domain was still large, although more compact then the previous one
 Could run IPP on some simple UM Translog problems, but not
Blackbox
Nau: PLANET, 2000
4
AIPS-2000 Planning Competition
 Two tracks:
 Track 1: STRIPS and PDDL planners
 Track 2: “hand tailored” planners
 many more problems, much harder problems
 We entered SHOP in Track 2
 We didn’t do much preparation for the competition
 We felt very confident that SHOP would perform best
 We were wrong!
 SHOP ran much faster than the Track-1 planners, but it wasn’t
the best planner in Track 2
 In two domains, we got incorrect results on a few problems
 In the other problem domains, a new planner called
TALplanner was faster
Nau: PLANET, 2000
4
AIPS-2000 Planning Competition
(Continued)
 Why we got the errors
 We had to translate from PDDL to SHOP by hand
 In two domains, we didn’t do the translation correctly
 The errors were minor, but caused incorrect results
 For next time, we are writing an PDDL-to-SHOP translator
 Why TALplanner was faster (we think)
 Like TLplan, TALplanner does forward search guided by pruning
rules written in modal logic
 many of the same advantages as the SHOP algorithm
 TALplanner uses highly optimized data structures
 For next time, we intend to do the same for SHOP
 Example: by making a simple modification to SHOP’s state
representation, we made SHOP more than an order of
magnitude faster
Nau: PLANET, 2000
4
Related Publications
[Andrews et al., 1995] Andrews, Kettler, Erol, and Hendler. UM Translog: A
Planning Domain for the Development and Benchmarking of Planning
Systems. Tech. Report CS-TR-3487, Dept. of Computer Science, U. of MD.
[Bacchus et al. 2000] Bacchus and Kabanza. Using Temporal Logics to
Express Search Control Knowledge for Planning. Artificial Intelligence,
116(1-2):123-191.
[Erol et al., 1994]
Erol, Hendler, and Nau. UMCP: A Sound and Complete
Procedure for Hierarchical Task-Network Planning. AIPS-94, 249-254.
[Lotem & Nau, 2000] A. Lotem and D. Nau. N ew Advances in GraphHTN:
Identifying Independent Subproblems in Large HTN Domains. In Proc. Fifth
International Conference on Artificial Intelligence Planning and Scheduling
(AIPS-2000), April 14-17, 2000, pages 206-215. Breckenridge, CO.
<http://www.cs.umd.edu/~nau/papers/AIPS-2000.pdf>
[Nau et al., 1999]
D. Nau, Y. Cao, A. Lotem, and H. Munoz-Avila. SHOP:
Simple Hierarchical Ordered Planner. IJCAI-99, August 1999, pp. 968-973.
<http://www.cs.umd.edu/~nau/papers/shop-ijcai99.pdf>
[Nau et al., 2000]
D. S. Nau, Y. Cao, A. Lotem, and H. Muñoz-Avila.
SHOP and M-SHOP: Planning with Ordered Task Decomposition. Tech.
Report CS TR 4157, University of Maryland: College Park, MD, 2000.
<http://www.cs.umd.edu/~nau/papers/shop-ijcai99.pdf>
Nau: PLANET, 2000
4
6. Evacuation Planning
Theory
1. Principles of
HTN planning
2. Computer
bridge
4. Ordered Task
Decomposition
3. Electronic Design
and Manufacturing
5. SHOP
6. Evacuation
planning
Applications
 Joint work with David Aha, Leonard Breslow, and Héctor
Muñoz-Avila
Nau: PLANET, 2000
4
Noncombatant
Evacuation Operations (NEOs)
 Goal:
 Assist the US Dept. of State to evacuate
people whose lives are in danger
 noncombatants, nonessential military
personnel, host-nation citizens, thirdcountry nationals
 Characteristics:
 Joint task force - geographically
distributed, often multi-national
 Uncertainty
 Complexity (200+ tasks)
 US Ambassador is senior authority
 More than ten NEOs were conducted within
the past decade
Nau: PLANET, 2000
4
HICAP:
Hierarchical Interactive Case-based Architecture for Planning
U
S
E
R
IDS
Requests
Elicited plan
Plan
HICAP
Scenario
 Motivation
 Interactive decision support tool - user in control
 Guided by military doctrine
 Provide access to previous experiences
 Plan elicitation by reusing cases
 Plan revision by reusing lessons learned
 Inferencing on standard procedures
 Perform bookkeeping
 Reduce the chances of error
 Help secure accountability
Nau: PLANET, 2000
4
Why HTN Planning?
 Hierarchical planning is natural for military organizations
Strategic
National
Strategic
Theater
Operational
JCS / NCA
CINC
JTF
Tactical
Nau: PLANET, 2000
4
HICAP:
Hierarchical Interactive Case-based Architecture for Planning
U
S
E
R
IDS
Requests
Plan
Scenario
Elicited plan
Lessons
Deliverer
HICAP
Hierarchical
Task Editor
(HTE)
NaCoDAE/HTN
CCBR Tool
SHOP
Generative
Planner
DecTS
Decision
Tracker
Mixed-initiative planner
 Interactive case retrieval: Select among alternative task
decompositions
 Generative planning: Automated task component
 Resource conflict identification and resolution
Input: Doctrine & resources, cases, methods, lessons
 HTN representation
Output: Elicited plan
Nau: PLANET, 2000
4
Hierarchical Task Editor
U
S
E
R
Task
HTE (i.e., manual)
1. Apply Doctrine
2. Manual Edits
NaCoDAE/HTN
3. Apply Cases
SHOP
4. Apply Methods
Task Decomposition
Nau: PLANET, 2000
4
Example SHOP Methods
Select Helicopter Launching Base
Establish Base
within Flying
Distance
alternative Launch from
methods Carrier Battle
Transport helicopters
available (H)
Security force
available (F)
Group
Transport helicopters
available (H)
Helicopters have air
refuel. capability (H)
Select Helicopter Launching Base
Select possible area (A)
Transport sec. force (F,A,H)
Embark sec. force (F,H)
Fly(H,A)
Disembark (F,H,A)
Position security force (F,A)
Transport fuel to (A)
...
 Decompose tasks into (more tactical) subtasks
 Consider restrictions (e.g., transport helicopters available)
 Resolve interactions (e.g., deploy security force first)
 If necessary, backtrack and try other methods
Nau: PLANET, 2000
5
NaCoDAE/HTN: Navy Conversational
Decision Aids Environment
- NaCoDAE/HTN implements Conversational Case Based Reasoning
User
- NaCoDAE/HTN allows interactive
elicitation of situations from the user
Alternative decompositions
(cases) for the task ranked
according to the user’s answers
Nau: PLANET, 2000
<Q,A>
process
…
selects
case
System’s
Situation
Knowledge
5
Methods Versus Cases
SHOP
Methods denote generic task
decompositions and conditions for
selecting those decompositions:
Task: travel(From,To)
Decomposition:
travelC(From, Station1)
travelIC(Station1,Station2)
travelC(Station2, To)
Conditions:
in(To,City1)
in(To,City2)
trainStation(Station1,City1)
trainStation(Station2,City2)
Nau: PLANET, 2000
NaCoDAE/HTN
Cases denote concrete task
decompositions (taken from
previous plans) and preferences for
selecting those decompositions:
Task: travelC(Penn ST.,Downtn NYC)
Decomposition:
take(taxi, Penn St., Downtn NYC)
Questions:
Is it raining hard in NYC? No
Is the passenger carrying
luggage? No
5
Using NaCoDAE/HTN
Planning tasks
World State
Nau: PLANET, 2000
5
SiN:
SHOP integrated with NaCoDAE/HTN
In a mixed-initiative manner either SHOP or NaCoDAE/HTN has control over
the decomposition process and cedes control to the other if it cannot proceed
In control
System’s
Situation
Knowledge
SHOP
…
NaCoDAE/HTN
SHOP
Nau: PLANET, 2000
…
5
SiN: Algorithm
 Let t be the task currently being decomposed
 If t is primitive return a success
 Else if SHOP is in control
 SHOP decomposes t if possible. If SHOP cannot decompose t but
NaCoDAE/HTN can, then cede control to NaCoDAE/HTN.
 Else if NaCoDAE/HTN is in control
 NaCoDAE/HTN decomposes t if possible. If NaCODAE/HTN cannot
decompose t but SHOP can, then cede control to SHOP.
 Else if neither SHOP nor NaCoDAE/HTN can decompose t
 Backtrack if possible. If it is not possible, then return a failure.
Nau: PLANET, 2000
5
SiN: Example – Mixed Initiative
SHOP
Methods denote generic task
decompositions and conditions for
selecting those decompositions:
Task: travel(From,To)
Decomposition:
travelC(From, Station1)
travelIC(Station1,Station2)
travelC(Station2, To)
Conditions:
in(To,City1)
in(To,City2)
trainStation(Station1,City1)
trainStation(Station2,City2)
Nau: PLANET, 2000
NaCoDAE/HTN
Cases denote concrete task
decompositions and preferences for
selecting those decompositions:
Task: travelC(Penn ST.,Downtn NYC)
Decomposition:
take(taxi, Penn St., Downtn NYC)
Questions:
Is it raining hard in NYC? No
Is the passenger carrying
luggage? No
5
SiN: Example – Mixed Initiative
In control
SHOP
Travel(Greenbelt, NYC)
Travel(Greenbelt,Union St.)
Taxi(Greenbelt,GreenbeltM)
Metro(GreenbeltM,Union St.)
NaCoDAE/HTN
Train(Union St.,Penn St.)
Travel(Penn St.,Downtn NYC)
Taxi(Penn St.,Downtn NYC)
Nau: PLANET, 2000
5
Evaluating HICAP
 Use HICAP to plan a NEO subtasks
 compare performance with other approaches
 How to evaluate? Can’t actually carry out a NEO
 ModSAF - simulation program developed by the US Army
 Simulates real-world military scenarios
 Finite state simulation with modular components that
represent individual entities and parts of entities
 Example: simulated tank
 Physical components (turret, etc.) and behavioral
components (move, attack, target, react to fire, etc.)
 Certain 3D aspects are also represented that can affect
sensory and movement behavior
 terrain elevation, trees, vegetation, rivers, oceans,
atmospheric conditions, etc.
 Realism is sufficient for training exercises
Nau: PLANET, 2000
5
Snapshot of the MoDSAF Simulator
Nau: PLANET, 2000
5
Evaluation: Empirical Methodology
Blind study: HICAP user did not know the simulated scenario
NEO Subtask: Transport 64 evacuees from meeting site to embassy
• Meeting site at forested crossroads outside of city
• Terrain database from Camp Lejeune
Transport by
Land
Land
Air
Air
Selection Method:
1. HICAP
2. Most frequently used plan
3. Heuristic Choice (escort avg.)
4. Random
Nau: PLANET, 2000
Escorted?
No
Yes (tanks)
No
Yes (attack helicopters)
We used the same performance
measures used by the US armed
forces:
• Casualties (Evacuees, friendlies,
hostiles)
6
Two Scenarios and Average Results
(ModSAF is non-deterministic  10 Runs)
Evacuees Saved:
64
54
49
44
39
1
Nau: PLANET, 2000
9
8
7
6
5
4
3
2
1
0
9
8
7
6
5
4
3
2
1
0
59
HICAP:
Most Frequent:
Heuristic:
Random:
Friendly Casualties: Hostile Casualties:
2
1
2
1
2
Scenarios: 8 2-person dismounted hostile teams:
1. Anti-tank missiles, or
2. Anti-aircraft missiles
6
Related Work
System
SHOP
Generative
Case-based
Mixed-initiative
X
CHEF
X
Prodigy/Analogy
X
SIPE II
X
NaCoDAE/HTN
X
X
X
X
MI-CBP
X
X
X
SiN
X
X
X
Nau: PLANET, 2000
Interleaved
X
6
Job Announcement
 We want to hire a full-time research scientist to work on
extensions to HICAP
 Research areas:
mixed-initiative planning, case-based reasoning, generative
planning, knowledge management, and machine learning
 The work will be joint between the University of Maryland
and NRL's Intelligent Decision Aids Group
 Ideal applicants will have some relevant research
experience/interest, and Java software development expertise
 Experience with simulators, military applications, and/or
Smalltalk would also be welcome
 The position is available now

 If you’re interested, please let me know!
Nau: PLANET, 2000
6
Related Publications
[Muñoz-Avila et al., 1999a]
H. Muñoz-Avila, D. McFarlane, D. Aha, J. Ballas, L. Breslow and D.
Nau. Using guidelines to constrain interactive case-based HTN
planning. In Proceedings of the Third International Conference on
Case-Based Reasoning (ICCBR-99), 1999. Finalist for the best
paper award.
<http://www.aic.nrl.navy.mil/papers/1999/AIC-99-004.ps.Z>
[Muñoz-Avila et al., 1999b]
H. Muñoz-Avila, D. Aha, L. Breslow and D. Nau. HICAP: an
interactive case-based planning architecture and its application to
noncombatant evacuation operations. In IAAI-99, 1999, pages 870875. <http://www.aic.nrl.navy.mil/papers/1999/AIC-99-002.ps.Z>
[Muñoz-Avila et al., 2000]
H. Muñoz-Avila, D. W. Aha, L. A. Breslow, D. S. Nau and R. Weber.
Integrating Conversational Case Retrieval with Generative Planning.
In EWCBR-2000, 2000. Trento, Italy: Springer-Verlag.
Nau: PLANET, 2000
6
Summary
Theory
1. Principles of
HTN planning
2. Computer
bridge
4. Ordered Task
Decomposition
3. Electronic Design
and Manufacturing
5. SHOP
6. Evacuation
planning
Applications
 Ordered task decomposition is an adaptation of HTN planning
 Prolog-style left-to-right search; high degree of expressivity
 Grew out of our work in two application domains:
 manufacturing planning and the game of bridge
 SHOP: domain-independent planning algorithm
 Sound and complete over a wide class of problems
 Powerful enough for use in complex applications

Evacuation planning
Nau: PLANET, 2000
6
Conclusions
 For a long time, AI planning researchers thought that
forward search was not a good way to generate plans
 Recent results (SHOP, TLplan, FF) strongly suggest otherwise
 AI planning is becoming capable enough to be used in
real-world applications
 Synergy between theory and applications
 Understanding what works in practical planning
situations can produce better planning theories
 This will lead to better real-world planners
Nau: PLANET, 2000
Theory
Practice
6
Future Work
 Improvements to SHOP
 optimize the data structures
 PDDL-to-SHOP translator
 Planning with incomplete information
 Contingency plans, evaluation of alternatives
 Somewhat like the game-tree search we did in Bridge Baron
 Semi-automated knowledge acquisition
 Case-based reasoning to synthesize HTN methods in HICAP, by
observing what plans the human user creates in what situations
 Multi-agent planning
 Integrate SHOP with the IMPACT multi-agent environment
Nau: PLANET, 2000
6
Acknowledgements, and
Where to Get More Information
 Sponsors
 Government: NSF, NRL, ARL, DARPA
 Industry: Great Game Products, Northrop Grumman
 Where to get more information
 Computer Bridge
http://www.cs.umd.edu/~nau/bridge/bridge.html
 EDAPS
http://www.cs.umd.edu/~nau/projects/edaps/edaps.pdf
 SHOP
http://www.cs.umd.edu/projects/shop/
 HICAP
http://www.aic.nrl.navy.mil:80/hicap/
Nau: PLANET, 2000
6