From: AAAI Technical Report SS-95-04. Compilation copyright © 1995, AAAI (www.aaai.org). All rights reserved.
Planning Shuttle Mission Preparation Activities
Jane T. Malin
Intelligent Systems Branch, ER22
NASA- Johnson Space Center
Houston, TX77058
malin@aio.j sc.nasa.gov
(713) 483-2046, FAX483-3204
Debra Schreckenghost and Dan Ryan
Metrica
NASA- Johnson Space Center, ER22
Houston, TX 77058
schreck@alo.jsc.nasa.gov
(713) 244-6134
Abstract
The Space Propulsion Robust Analysis Tool
(SPRAT)project is developing technology
support Space Shuttle ground operations personnel
as they manageand carry out mission preparation
analysis and related analyses in missions. The
initial SPRAT
prototype provides intelligent
support and automationfor mission analysis set-up
and documentation for Propulsion consumables
analysis. SPRAT
models the actions taken by
flight support personnel during mission preparation
and uses this modelto generate an action plan.
SPRAT
represents mission preparation actions as
they relate to planning and scheduling, and thus
provides a general action representation for a broad
range of tasks.
Wehave recently delivered our phase 1 prototype
to the targeted user group (the PROP
flight
controllers) for evaluation. This paper provides
progress report on howthe current SPRAT
prototype supports flight controllers in performing
mission preparation activities, and howwe propose
to enhancethis support through extensions to the
current planning capability. Support for planning
analysis tasks is described, and related to the
consumables analyses performed by PROPflight
controllers. Wefocus on user interaction with this
planning process, and the evolution of the
predominantly manual planning system we have
today to a moreautomated planner. Wealso
discuss howthe knowledgerepresentations
developed for SPRAT
support this evolution. The
paper closes with our plans for future workand a
summaryof our conclusions.
1 Introduction
2 Planning for Analysis Tasks
Theanalysis and interpretation of scientific and
engineering data combinemanualand computerbasedactivities in sequencesthat vary as the
conditions of the analyses change. Thus,
applications designedto assist analysts in
performingthese activities offer challengesfor
planning technology. Wehave developed the
SPRAT
system to assist space flight design
personneland flight controllers in planning
analyses conductedprior to a mission, and in
performing analyses in response to anomalous
situations during a mission. The SPRAT
prototype
automates and supports managingSpace Shuttle
Propulsion (PROP)mission preparation in the task
area of consumablesanalysis.
SPRAT
assists users in building an action item list
of required consumablesanalysis tasks, and in
managingthe results of performingthese actions.
Thesetasks include both executing analysis
software and producing mission preparation
reports. The user interacts with SPRAT
throughout mission preparation. Actions are added
to the list whennewor changedmission def’mition
data becomesavailable. Results of actions are
stored in SPRAT
once they are executed.
77
SPRAT
is an exampleof the class of applications
that providesupport to users performingscientific
and engineering analysis tasks. A common
approachis to provideassistance to the analyst in
defining a plan for performingthe analysis, in
executing that plan, and in documentingrelevant
results of the analysis. Thus, a common
aspect of
this type of application is the requirementfor
representationof the actions that the analyst
performs to accomplishhis analysis tasks. Action
representations developedfor scientific and
engineeringanalysis include the task of developing
scientific models[2], data interpretation tasks for
geological exploration [5], and data preparation
tasks for imagedata [6, 1]. AI modelingconcepts
have also been applied in representing information
to ensure that the software (often model-based)
used in these analysesis appropriateto the task [2,
5].
Theseanalysis tasks are typically complexand
iterative, with trial anderror refinementof the
analyses. Task complexity is often managedby
providing
hierarchical
organization
ofthetask’s
actions.
Taskinteraction
andrefinement
requires
providingtechniquesfor repairing the plan to
reflect what waslearned in previous, unsuccessful
analyses, and for reusing old plans. Thesoftware
that these systemsintegrate with is often custom,
legacy software, requiring an open, distributed
architecture integrating heterogeneoussystems.
Thecharacteristics of analysis tasks in general have
resulted in the needfor considerableuser
interaction with the planning process. This
interaction is neededboth whendeveloping(and
repairing) the plan and whenexecutingthe plan.
Duringplan development,the user specifies the
task to be performed(correspondingto a set of
analysis goals). Configuration information about
the specifics of the analysis situation mayalso be
provided. Duringplan execution, the user often
initiates specific actions and maysuggest plan
changes.It is also importantto permit the user to
define and modifyaction definitions in responseto
changesin software and requirementsfor specific
analysis situations.
.~1~- 12 Months
f=
¯
The consumables analyses conducted by Space
Shuttle PROPconsumablesofficers are an example
of these types of analysis tasks. Typicaltasks
performedduring consumablesanalysis are: (1)
determiningthe quantities of fuel available and
required to achievemissionobjectives safely, (2)
schedulingfuel tank interconnections to maintain
massbalances, and (3) placing propellantconsuming
events on a timeline that is part of the
mission plan. Throughoutthe year preceding a
flight, several types of missionchangesinitiate
newcycles of analysis to determine howchanges
affect consumables.Iterative evaluations are
neededfor nominaland contingencysituations and
for proposedmission plans and objectives, flight
rules and procedures. Thesesituation what-if
analyses are used to determineimpacts to mission
objectives and procedures. During missions,
additional analyses are performedas needed.
Figure 1 provides an overviewof the Shuttle
PROPconsumables analysis.
I
~
~ess"1 month
~~rRealtime
t - 3 MonthSF/ightCycle
EngineeringCycle
InterconnectPlan
InterconnectPlan
--
-vernier/novemier
-no deploy
-no rendezvous
-payload margins
-rendez margins
-event "blocks"
-
-raisethe orbit
E
+
-Return to Launch
(~
E
-TransAtlantic
Landing
-Abort to Orbit
-raisa-the-orbitavant-b,ocks
~
"
. E
Reports
~’¢
~od.
except
~ ’~1~’~
~E~l
SpreadSheet
E
(priority tables)
~[pD(~,~
,,y.~-
~
~~1~
E
~
~’i
COMPS
- Fit ReadinessReview
-
I Iterate
I
Launch go/no-go
Flight Rules Annex
Flight DataFile
Flight OpsReview
PROPConsumables
Final Tlmellnes
Iterate
I
-Pdodty
Table
- Preflight
Tagup
[
~
Iterate
I~lP,Propellant
Loading
(actuals)
Figure 1. Shuttle
Propulsion Consumables Analysis Process
78
3 The SPRAT Prototype
The SPRAT
system assists the consumablesofficer
in performingmission preparation analyses by
helping plan the actions neededto conductthe
analyses [7]. Missionpreparation actions include
the executionof simulation and analysis software,
the interpretation of results fromthese
computations, and the generation of mission
preparation reports summarizingdecisions. Action
managementconsists of creating and modifying
action operators[9], buildinga list of these actions
(the actionlist, whichis a set of analysisplans) to
accomplishanalysis purposes, and tracking the
outcomeof the actions on this list as they are
performed.Action list creation can be viewedas
planning, and action tracking as monitoringplan
execution.
The SPRAT
system utilizes an action-based
planner, whereaction-based planning is
characterized by temporal/causalrelationships
amongactions [6]. It groupsthe analysis tasks as
a networkof processes, wherea process consists
of action nodesand their relations to input/output
nodesand to other action nodes(see figure 2).
Input and output nodesare objects containing data
values. Action nodes are action operators. An
action operator consists of the following:
¯ analysis task: description of the task purpose
¯ instructions: information on howto conduct the
task
¯ constraints: conditions under whichthe action is
relevant.
SPRAT
represents two types of constraints that
mustbe satisfied for an action to be addedto the
actionlist:
¯ precedenceconstraints: dependencyrelations
betweenthe action and its data inputs and
outputs (e.g., input a => action b => output
translates to input a is usedin action b to
produceoutput c; see figure 2)
¯ analysis context: propositions that must hold
true for an action to be addedto the list (see
Table 1 for propulsionanalysis context).
Applicableprocesses are identified based on the
goals of the analyst. Theanalyst specifies his
purposeas either the responseto a changein
missiondefinition data, or as the needto generatea
report. Thespecified purposeis used to activate
either input nodes (correspondingto a changein
missiondefinition data) or output nodes
(correspondingto the need to producethat output).
Contextparametersdescribing the analysis
79
conditions are used to constrain propagation
through this network. Actions from the applicable
processare then placedon the action list, if the user
concurs with them. Simple ordering constraints
are used to construct a list of actions. Currently,
the software precedenceconstraints are used in
ordering actions. Theability to order actions using
informationabout delivery deadlines and priorities
is not yet supported.
Table 1: Propulsion Analysis Context
Contexts
Standard Insertion
Direct Insertion
Deploy operations
Rendezvousoperations
Special ManeuverOPS
Orbit Adjust Bum
Ballast
Data Cycle
Engineering
Flight
Flight Readiness Review
Actual
Fli[ht Data File Updates
Analysis Type Ascent/Entry
Orbital
Exploratory
Category
Mission
Figure 2 describes the representation of precedence
constraints and illustrates using these constraints to
determinethe neededactions after a changein
mission definition data (e.g., lome.sf.isp). The
suggested actions from the examplein part B are:
¯ execute conman(left omsengine standard
configuration)
¯ execute conman(2 oms engines standard
configuration)
¯ execute tlcalc (nominalconfiguration)
Note that the conmananalysis software is
scheduledfor executionbefore the tlcalc analysis
software, since conmanoutputs are used by tlcalc.
Theexecutionof actions on the action list is
monitoredto determine howactions are
dispositioned and to documentthe outcomeof
actions. Theinformation neededto track the
disposition of actions is representedin the action
tracking record. An action list consists of a
collection of these action tracking records stored in
a database. Actions are not removedfrom the
action list whencomplete.Instead their status is
markedcompleted(or canceled, failed, etc.).
the end of the mission preparation analyses, the
action list represents a history of what wasdone
(similar to Kant’stask executionhistory [5]).
A. General Representation of PrecedenceConstraints
+.,<,,,.,
¯".
~.:~.
+~&".+"~¢.::-:.~:+:~:t.m
¯¯ ~..’+:~
,o.,,,.,,,,,.
~ :omm, m-,.om-sm
~+..:.~+mm+:++..++++~
,o,,,..x,’.,,rmE~’-:.~
........+ .::+:+~++...’:.~+tZ,.-.++
,ore,,,’.,,,,"
¯
. ..............
.++
~M+~’+~
~:++~-+
.... .:.::
+:’:.+:+.::m+
::..+..+,.+,,::.:+,
. .+
.~:::..:
.~:.+...
.... :
,~;~.~.’ Execute
~~:’.:.i
OMS
Performance
+......
~I~CONMAN-~’OME-STD
l~~~~::"::~:"+~+::~"
’:::’"" "~.....................
~"
5un’m’lal+y i
~.’,:~+.’0:.+
,::,).~+.:.m~:-.’-:+.P:..:’~.~.:’~’.’.:.:..’.
,’::::::::+:.:-:.:.:.:.+::-:.:+~:::::::::::
+..::::::,::
+ ..’+.-.re.+.. ¯ .:.:,..,...,’:.,:.’.:.:.:.’:.:.:.
:...........~~:,.::....
::.....:..~.:.:::~.....
~
,:x+,,:,,,, ~".........+.
,o,,..,,.m,,,,,..~.,,,,
:+i+
..:.+.:’&~+::::::::.:
[~~+.+."i
re,,.,’~" ,.m..,e ~" S~.~ CONMAN-eOme-STD
IIIm
¯
. g
::’~.~’....
........
.......~:::
B. Using PrecedenceConstraints to DetermineRelevant Actions
Figure 2. Precedence Constraints
This history includes information about howan
action was performed(contained in the model
usage record (MUR)).The MUR
is an extension
of Ellman’s modeldevelopmentrecord [2] that
describes developmentand testing relative to a
model’sintended use.
for Propuls|on System
Figure3 illustrates the action representationin
SPRAT.
SPRAT
provides a muchsimpler, manual form of
plan repair than Lansky[6] and Kant [5]. The
status of an action is changedto reflect changesin
the executionof the action (e.g., actions that are
removedare canceled, actions that are delayed are
suspended,actions that are successful are
completed,actions that fail are aborted). When
changeis made,informationuseful in explaining
whythe changeoccurred can be entered by the user
into an action "results" field in the MUR.
80
SPRAT
also provides the ability for a user to
extendthe set of available actions by building
action operators. This action editing capability is
central to the SPRAT
knowledgeacquisition
strategy. Instead of doing extensive, up-front
knowledgeengineering, we provide the ability for
users to describe action operators as they need
them"on the job". Anextension of this
philosophy of on-the-job knowledgeacquisition is
providingrepresentative (though simple) capability
as soon as possible for user evaluation. Thus, the
SPRAT
system is intended to evolve in response to
the actual use of the system.
Action List Database
A~donTracldng RecordX
TrackingParameters
m~
Base of Action Operators
Action OperatorA
TaskDeflniUon
t,,,,~
luser-solecte~
anal.vumose
I
;InmrmtkxmIhow,oc,m+,m,,,ctmI
ConstraintRelaUons
~Mne
ModelUsageRecord
AcUonOperator B
TaskDefinition
Cons~lntRelations
~l~tion TrackingRecordY
TrackingParameters
ModelUsageRecord
~tion Tracking RecordZ
TrackingParameters
ModelUsageRecord
Action OperatorC
TaskDeflniUon
ConstraintRelations
Action O~rator D
TaskDefinition
ConstraintRelaUons
Figure 3. SPRATAction Representation
4 User Interaction
with SPRAT
Thenature of the mission preparation tasks has
required SPRAT
to support active user interaction
with all aspects of the planningprocess. In
particular, the user interacts with SPRAT
when
¯ building action operators
¯ creating action lists
¯ executingactions on the list
Eachof these types of interaction is described
below.
4.1 Building Action Operators
Users must be able to define newaction operators
specific to a mission. SPRAT
provides an action
editor wherethe user can create or alter action
operators easily. Informationthat the user must
provideto build an action operator includes task
purposeand instructions, analysis context, and
precextence constraints. At a minimum,
the user
must define a unique action namewhencreating a
newoperator.All other attributes can be specified
(or modified) later. To makean action operator
available to the planner, precedenceconstraints
must be specified. For the propulsion system,
there are two maintypes of action operators:
software execution and report generation.
Providingan action editor has significantly reduced
the cost to deliver the system, since extensive
knowledgeengineering and maintenanceis not
required. Aproject goal is for users to developthe
knowledgebase of actions as part of performing
mission analyses. Since actions from previous
missions can be loaded into SPRAT,we expect
that they will be used in evolvingstandard
"subplans"for the moretypical aspects of mission
preparation(derivation of standard operating
procedures (SOP)). Support for deriving SOPs
will be addedin the future.
Althoughthe current prototypeis specific to the
Shuttle propulsion domain, SPRAT
is being built
to permit use in manydifferent domains.Part of
building a domain-specific instance of SPRAT
is
determiningthe types of actions, the inputs
required to do those actions, the outputs generated
by the actions, and the analysis contexts relevant to
the domain. Figure 4 illustrates using SPRAT
to
create an action operator.
ACTION []
EDITOR
ACTION:
I
~N-2OME-STD
Irstructlom:
(~lew/EdltAction)
I
1. Configure for 20MSIx~n
I
2. S~ect 2 CMEde~lnatlon
|
$. Specifyoneof delts-T, delta-V, or I
u~e
I
ReportOutp~
Context
ParsedOutputs
Step 1: Specify name, task, and instructions
ACTION []
EDITOR
of Results
mm
,c,o.
I
~orrdPin.I/.~p
Iorne-ln~lf.rnr
Iome-ln
Jf.fr
Iome-le~t.lm
Iome-ln~
f.rnr
Iome-k~J(t.fr
~OMS-FIE
RF-SUMI4ARY-OUT
PUT
I
I Edit Relations I ~
rome-ln.~.mr
rome-ln.sf.fr
rome-ln.xf.lsp
rome-ln.xf.mr
ron~-In.xf.fr
Select relation type and use menusto
specify related objms
0 data Inputs
0 file outputs
affected reportl
O0preceding actiom 0
0 sub-actlom
an~ysiscontext
ReportOutputs
CVlewAll Rel.iom)
Context
ParsedOutputs
Step 2: Define the relationship to input and output
Figure
4. Building
an Action Operator
4.2 Creating an Action List
Usersalso control the addition of actions to the
action list. SPRAT
suggests candidate actions to
be performed(based on changesin input data or on
the needto generate a report) and the user decides
if they should be addedto the list. This preview
capability guaranteesthat the user concurswith the
suggestedset of actions (e.g., is the data change
sufficiently large to warrantperformingthe
suggestedaction) and permits the user to correct
any mistakes(e.g., forgot to specify analysis
context) before these actions are mergedinto the
list. Theuser can also identify actions that are
redundantor in conflict with actions already on the
list. Finally, the user can comparecandidate plans
resulting fromdifferent initial situations before
deciding whichactions are most appropriate.
In addition to determiningactions in responseto
data changesand for report generation, the user
also can performwhat-if/predictive analysis by
postulating changesin input data and evaluating the
different plans that are suggested. For an action to
be suggested, both the precedenceconstraints must
be satisfied and the analysis context must hold.
Theplanningprocessis highly interactive at this
time. Weexpect SPRATto evolve toward a more
automatedplanning process, including
¯ identification of actions that are redundantor in
conflict with actions already on the list
¯ replanning whenan action fails, and merging
these newactions onto the existing list
This is part of a larger issue of howto mergenew
actions into a large action list containingmultiple,
smaller plans.
4.3 Executing an Action Plan
the outcomeof the action. Theintent of the action
is defined by the user’s purposein performingthe
action and the analysis context in whichthe action
is relevant (e.g., rendezvousoperations). The
waythe action is conductedis characterized by the
activities/steps composing
the action, the input data
used to performthe analysis, and the characteristics
of the tools used in the analysis (model
developmentrecord [2]). The outcomeof the
action describes both the analysis products and the
completionstatus of the execution.
Informationdescribing whyan action is on the list
is automatically stored in the MUR
whenthe action
is addedto the list. This informationincludes the
purposeand context of the analysis (previously
specified by the user), the values of any inputs
used in the analysis, and any actions that must
precedethis action.
Duringthe course of the analysis, the user specifies
information in the MUR
that describes the outcome
or results of the analysis. Theseresults include
both the products of the analyses (e.g.,
consumablesusage) and information about the
execution of the action (was the action completed
and howwas it completed, was the action
successful and if not why,whywas the action
canceled or aborted, what was done in response to
an unsuccessful action). Information about
analyses that were canceled or unsuccessful is
useful, since knowledgeabout whyan approach
wasn’t pursuedor what causedit to fail maybe
useful whenperformingsimilar analyses in the
future. All of the informationabout the results of
the analysisis enteredas a text description.
SPRAT
supports the user in tracking the execution
of actions on the action list. Actiontracking
requires information about whyan action was
suggested by the planner, howthe action was
conducted,and whatthe disposition of the action
was. This informationis represented in the action
tracking record, whichconsists of information
about execution status (whoperformedaction,
whencompleted,priority of action) and the Model
Usage Record (MUR).The tracking record also
includes schedulinginformation (deadlines,
priorities). Theuse of this informationin planning
(or the possible integration of SPRAT
with
schedulingsystem) is an open issue.
Theaction list summarizesall actions performed
during mission preparation. For the propulsion
application, there is one list for eachmission.
Sinceall actions remainon the action list, even
whencompleted,this list represents multiple,
simultaneous analysis goals correspondingto
multiple plans. Viewingfilters permit the user to
extract different subsets of the action list basedon
his/her interests and priorities. For example,an
analyst can view:
¯ all actions assigned to a particular person
¯ all actions in-progress, canceled, etc.
¯ all actions with a specific deadline
¯ all actions of a priority class
Theseviewingfilters can also be used in accessing
informationstored in previous mission lists (using
the plan to index into a missionanalyses database).
The MUR
includes information about the intent of
the action, the waythe action wasconducted, and
Figure 5 summarizeshowthe user interacts with
the SPRATsystem.
83
Software
Mission
Definition
Data
/ results of
/ analyses
N design
/
, meters /
Reports
inputs to /
reports/
/
/
II Action
I
ListII Action
I I/oII Action
I Structures
II ManagementllOependendesll
Editor
I
I/O Structures
Userselectsversionof missiondefinition data;
SPRAT
loads data into its data structuresand
differenceswith previousload
Action List Management
Userexecutesactions andstores results in MUR
SPRAT
automaticallystores conditionsrequired
for analysesandprovidesaccessto stored value,
Action Dependencies
Userspecifiespurposeandcontextof analysis;
SPRAT
suggestsa set of actions (a plan) to process
changes
in missiondefinition;
Userapprovesactions; SPRAT
addsthemto action list
Action Editor
Userspecifies newaction operators;
SPRAT
creates these operators and makesthem
availableto planner
Figure 5. User Interaction
5 Future Work
Ourexperience with action list management
in
SPRAT
has already raised a numberof issues
related to both plan creation and plan repair. For
SPRAT,
the challenge is to provide an adaptable
plan with a goal structure that modelsflight
controller goals. Thegoal of an action is needed
for tracking the action (did the action achievethe
desired effect? was an observed change
intended?), and to providegoals that can be
manipulatedusing traditional replanning techniques
[3,4]. Enhancementsto the current planning
capability include:
¯ providingfor goal hierarchy and levels of
abstraction in actions by permitting subactions
(with subgoals) to be associated with an action.
Subactionsare viewedas constituent actions, or
actions that mustall be completedfor a higher
level goal to be satisfied.
¯ increasing the automationof the planning
process, including
- removingactions that are redundantor in
conflict with actions alreadyon the list
with the SPRATSystem
replanningwhenan action fails (e.g., the
results of an analysis violate flight
constraints) and mergingthese newactions
onto the existing list
This is related to the issue of howto mergenew
actions into a large action list containing
multiple, smaller plans, and to delete items on
the list that no longerhold.
¯ ordering actions using scheduling information
available in the tracking record (deadlines,
priorities)
¯ providing assistance in deriving SOPsfrom
action list histories, and in using these histories
as indices into the databaseof results
¯ extending the representation of results beyonda
simple text description and automatingthe
collection of results wherepossible
Accessingand modifyingarchived actions also
remains an issue. Thesearchived actions resemble
case bases of partial plans [8].
Our developmentapproach has been to get as much
capability as possible quickly into the user’s hands.
Wealso want the users to do their ownknowledge
engineering "on the job". Thus, manycapabilities
in the initial systemare in a very simplifiedform
(text fields, manualoperations). Weexpect this
initial capability to be modifiedand enhancedonce
we have a better understanding of howthe system
is actually used. Theuser evaluation is an
importantpart of getting this feedback. By
concentrating on providingbreadth of capability
(evenif someportions are very simpleinitially),
we enable evolution to a moreautomatedsystem in
the future.
The SPRATprototype was developed using a
commercialexpert system shell (Gensym’sG2).
SPRAT
is being re-implementedusing a distributed
architecturethat interfaces with the existing
"legacy" systems that performanalyses. This
requires integrating the planner with (1) a data base
or case base of actions and missionlists, (2)
constraint checker to determinewhenthe results of
analysis actions violate flight constraints requiring
newaction items, and (3) telemetry representing
PROP
state and configuration (for plan repair
during missions).
6
Conclusions
SPRAT
provides support for consumablesanalysis
tasks conducted by PROPconsumablesofficers.
The SPRAT
system includes a simple planner that
selects and partially orders actions in supportof the
mission planning process. These actions require
evaluating resource usage in what-if schedule
cases, and analyzing resource usage impacts on
procedures, and vice versa. SPRAT
has not
required a procedureexecution system or a
scheduler, but could interface with them. The
SPRAT
domainis a rich mission planning testbed
for integrating planning and procedureexecution
with scheduling.
The SPRAT
project has addressed howthe nature
of a task affects the representationof actions, and
has developeda general action representation
supporting a broad range of tasks. Such
representations can be applied to other types of
activities (such as software developmentand
analysis over large data bases). Theyalso enable
the developmentof moreflexible tools for
representing and reasoning about actions.
Common
representations for procedures, action
lists, plans and schedulescan support the
integration of several types of operations support
tools.
SPRAT
is designed to reduce ground operations
costs not only in ControlCenters, but in analysis
and simulation in flight design and mission
85
preparation. Increased automation and support for
simulation and analysis reduces the complexityof
mission preparation and reduces analysis time by
reducing the numberof unnecessary analyses.
SPRAT
also supports standardization and reuse of
analysis plans and better tracking and
documentation. The support provided by SPRAT
for managingiterative and interdependent analysis
tasks should be generally useful in other domains
where such tasks are performed. SPRAT
has been
developedgenerically, so that users can develop
and maintain analysis planning databases in a
variety of domains.
References
[ 1] Chien, S. 1994. Automatedsynthesis of image
processing proceduresfor a large-scale image
database. Proc IEEEConference on Image
Processing.
[2] Ellman,T., 1993. Atoolbox and a record for
scientific model development. Proc. SOAR-93,
(NCP 3240). Houston, TX: NASA-JSC,1993:
321-328.
[3] Elsaesser, C.; R. MacMillan,1991.
Representation and Algorithmsfor Multiagent
Adversarial Planning. MITRETech Report
91 W000207.
[4] Georgeff, M.; A. Lansky, 1987. Reactive
reasoning and planning.Proc AAAL1987: 677682.
[5] Kant, E., 1988. Interactive problemsolving
using task configuration and control.IEEEExpert,
Winter 1988.
[6] Lansky, A., M. Friedman, L. Getoor, S.
Schmidler, N. Short. 1995. The collage/kouros
link: Planningfor imageprocessing tasks.
submitted to AAAI Spring Symposiumon
Integrated PlanningApplications. Stanford, CA.
[7] Malin, J.T.; D. Ryan;D. Schreckenghost,
1994. "ModelingActions and Operations to
Support MissionPreparation", Proc. 3rd Int’l
Symp.on Artificial Intelligence, Robotics, &
Automation for Space (i-SAIRAS), JPL,
Pasadena, CA, October, 1994: 385-388.
[8] Zito-Wolf, R.; R. Alterman, 1993. A
frameworkand an analysis of current proposals for
case-based organization and representation of
procedural knowledge. Proc AAAI: 73-78.
[9] Tate, A; J Hendler; M. Drummond.
1990. A
review of ai planning techniques. Readingsin
Planning. ed J. Allen, J. Hendler, A Tate. Morgan
Kaufman. 26-49.
Acknowledgments
Thanks to TimHill and GrayumWatts for
significant efforts in the design and developmentof
the SPRAT
system. Thanksto flight controller
MatthewBarry, for insight into mission
preparationtasks and for significant contributions
to the design of SPRAT.
86