From: AAAI Technical Report FS-94-01. Compilation copyright © 1994, AAAI (www.aaai.org). All rights reserved.
KnowledgeAcquisition
and
Reactive Planning for the Deep Space Network
Randall W. Hill,
Jr., Kristina Fayyad, Patricia Santos, Kathryn Sturdevant
Jet PropulsionLaboratory
California Institute of Technology
4800 OakGrove Drive, M/S525-3660
Pasadena, CA91109-8099
{hill, kristina, trish, kathys}@negev.jpl.nasa.gov
Abstract
Weare building a reactive planning agent (REACT-P)
to automatethe operadonof a the communications
link
in NASA’s
DeepSpace Network(DSN). Wedesire
agent capable of executing plans and reactively replanning whennecessary. Since the reactive planning
agent must be built to interact with legacy (i.e.,
unmodifiable) systems, there are a number of
significant challengesthat mustbe addressed:(1)
what extent and howshould the legacy systems be
reverse-engineered
andmodeledin order to supportthe
developmentof a reactive planning agent? (2) Since
the legacy systems were built to support human
interactive control, mostof the informationneededfor
reactive planning is located in the humancomputer
interface. Howdo we identify and acquire the
knowledgeelements neededfor reactive planning? To
address the fast issue weare using a scenario-based
knowledgeacquisition methodologyand subsequently
building models of the legacy systems using a
simulation authoring toolkit namedRIDES(Munro,
1993). The reactive planner is being built in Soar
(Laird et al., 1987), whichwill be integrated and
tested, and refmedwith the RIDES-based
simulator.
whilemaintaining
at least the currentlevel of reliability. To
.accomplish this goal REACT-Pmust be capable of
performingmanyof the sameoperations that are currently
done manually by DSNstation Operators, and thereby
significantly reducethe amountof humaneffort neededto
performmonitorand control tasks in the domain.
Wehaveelsewhereidentified a numberof factors that
makeit difficult to implementa planner for a domainlike
the DSN(see Chien,Hill, and Fayyad,1994). In this paper
we address the knowledgeacquisition problem by fast
giving a brief overviewof the DSNtask domainand the
nature of problem solving there. Next, we present an
approach to knowledgeacquisition that builds on our
experiences in developing a DSNperformance-support
system called the Link Monitor and Control Operator
Assistant (LMCOA)
and an intelligent tutoring systemfor
DSNOperators called REACT.
Finally, wedescribe a set
of knowledge acquisition methods and tools we are
developingto supportthe approach.
2. Task Domain: Deep Space Network
The Deep Space Network (DSN) is a worldwide
network of deep space tracking and communications
complexeslocated in Madrid,Spain, Canberra, Australia,
and Goldstone, California. Each of these complexesis
1. Introduction
¯ capable of performingmultiple missions simultaneously,
each of whichinvolves operating a communications
link. A
Oneof the significant challenges to developingand
DSNcommunications
link is a collection of devicesused to
fielding a real-worldplanner is in the acquisition of the
track and communicate
with an unpiloted spacecraft.
knowledge
neededfor it to function autonomously
in a realCurrently,mostof the tasks requiringthe control of a
world problem domain.This paper describes howwe are
DSNcommunications link are performed by human
addressing the knowledgeacquisition problem in the
Operators on a system called the LMC
(Link Monitorand
developmentof an agent, namedREACT-P,
for a realControl)
system.
The
Operators
are
given
tasks that involve
world domain, the communications link monitor and
configuringand calibrating the communications
equipment,
control system of NASA’sDeep Space Network (DSN).
and then they monitor and control these devices while
Theunderlying motivationfor developingREACT-P
is the
goal of significantly improvingthe productivityof the DSN tracking a spacecraft or celestial body. The Operators
followwritten proceduresto performtheir missiontasks. A
This paper describes workperformedby the Jet Propulsion procedurespecifies a sequenceof actions to execute, where
the actions are usually commands
that mustbe entered via
Laboratory,CaliforniaInstitute of Technology,
undereontIact
systemkeyboard.
with the NationalAeronauticsandSpaceAdministration.Other the link’s monitor-and-control
Once issued, a commandis forwarded to another
members
of the teamworkingon this project includeW.Lewis
subsystem,whichmayaccept or reject it, dependingon the
JohnsonandLornaZorman
at Universityof SouthernCalifornia
state of the subsystemat the time that the command
is
(USC)InformationSciencesInstitute, andAllenMunroat the
USCBehavioralTechnology
Laboratory.
received. The Operator receives a messageback from the
72
subsystemindicating whether the command
was accepted
or rejected, and in cases wherethere is no response, a
messagesaying that the command
"timed out" is sent.
These messagesdo not indicate whether the action was
successful or whatthe results of the action were. Rather,
the Operator has to monitor subsystem displays for
indicationsthat the actioncompleted
successfullyandthat it
had its intended effects. It is common
for commands
to be
rejected or for commands
to fail due to a numberof realworldcontingenciesthat arise in the executionof a plan or
procedure.
4. General Approach to Knowledge
Acquisition
Wetreat the knowledge acquisition problem of
developing a DSNreactive planning agent as being
analogous to the challenge of training novice DSN
Operators. To understand the analogy, consider the
following.Achieving
an expert-levdof skill is difficult: it
takes humanOperators manymonthsof training and onthe-job experience to become experts. Muchof the
difficulty in human
skill acquisitionis relatedto the situated
nature
of
the
domain
knowledge(Hill&Johnson, 1993a;
3. Automating the DSN
Hill, 1993; Suchman, 1987). Most of the procedure
A prototype called the Link Monitor and Control
manualsonly describe howto do the job In a cookbook
Operator Assistant (LMCOA)
was developed to improve
style, wherea plan is expressedas a sequenceof actions. In
Operatorproductivity by automatingsomeof the functions
manyinstances, the dependencies,goals, and assumptions
of the LMC.The LMCOA
performstasks by: (1) selecting
behind each action, which happens to be the kinds of
a set of plans to execute, (2) checkingwhethera plan’s
knowledge
that humansacquire through experience, are not
preconditions have been satisfied, (3) issuing the
documented. The humanOperator learns what she can
commands,and (4) subsequently verifying that the
fromthe proceduremanuals;the gaps in her knowledge
are
commandshad their intended effects. The Operator
often filled by trial anderror experimentation,
whichcan be
interacts with the LMCOA
by watching the plans as they
a slowprocessin the absenceof a tutor.
are being executedand pausingor skippingportions of the
TheREACT
intelligent tutoring system implementsan
plan that needto be modifiedfor somereason. Whena plan
approachcalled impasse-driven tutoring (Hill&Johnson,
fails, the LMCOA
lacks the ability to recover on its own.
1993b;Hill, 1993; Hill&Johnson,1994). Students acquire
Instead, the Operatoris left to figure out howto recover
knowledgeusing REACT
by interacting with simulated
from the failure. In observing Operators perform their
DSNcommunications
devices; they receive training whenit
duties, wefind that they havean amazingability to adapt .is clear that they havereachedan impassein executinga
the written proceduresto the contingenciesthat arise in the
procedure.It is assumedthat the humanagent knowsor has
courseof their execution.Areal-worldplannerhas to have
access to the basic plans or proceduresfor operating the
the sameflexibility and knowledgeas a humanOperatorin
equipment;she incrementally adds to her knowledgeand
order to succeedin performingDSNmissions.
skill by performingtasks on a realistic simulator. When
the
REACT-P
is a new version of the LMCOA
that will
student reaches an impasse(i.e., she is no longer able to
reactively generatea plan in responseto a plan failure or
makeprogresstowardthe goal), the tutor Interacts with the
changein goals initiated by the Operator.It will needto
her and provides the knowledge dements required to
have the sameability to recover from plan failure as is
resolve the impasse. Problem solving impasses are
demonstratedby humanOperators. In (Chien, Hill, and
therefore viewedas learningopportunitiesfor the student.
Fayyad,1994) we describe a numberof reasons whyit is
Theimpasseis a result of a knowledge
gapor error, andthe
difficult to deploy a planner for the DSNdomain.Oneof
tutor’s role is to identify that the impassehas occurredand
the reasons given is that it is difficult to acquire and
then determine what knowledgeis neededto resolve the
maintainthe knowledge
that is neededto do the planning.
impasse.
Since the REACT-P
agent mustinteract with legacy (i.e.,
The knowledgeacquisition process for the REACT-P
unmodifiable)systems, there are a numberof significant
reactive planningagentcan be viewedas similar to tutoring
knowledgeacquisition challenges that mustbe addressed:
human Operators. Knowledgeacquisition begins by
(1) To what extent and howshould the legacy systems
acquiring a declarative description of as muchof the
reverse-engineered and modeledin order to support the
domain knowledgeas possible. The knowledgeis then
developmentof a reactive planning agent? (2) SInce the
refmedand gaps are filled by applying the REACT-P
agent
legacy systems were built to support humaninteractive
to a task. Gapsand errors are indicated by impasses,where
control, muchof the information needed for reactive
an impasseis an inability of the REACT-P
agent to make
planning is located in the humancomputerinterface. How progress towardthe achievementof a goal. Theseimpasses
do weidentify and acquire the knowledgeelementsneeded represent opportunitiesto acquire newknowledge
or correct
for reactive planning?(3) Finally, muchof the knowledge existing knowledge.
neededfor planning is not explicitly documented:it is
Thekind of knowledge
that expert Operatorsappearto
learned on the job by the Operators. Howdo weacquire
needfor skilled behavioris the sameas whatis neededfor
knowledge
that is currently a learned skill? Theseare the
the reactive planner. At a minimum,this knowledge
knowledgeacquisition challenges that drive the approach includes the following:(1) plans andtheir actions, (2)
wedescribe below.
preconditions for each action, (3) the effects
postconditionfor eachaction, (4) the goalsof eachplan, (5)
73
a partial order amongplans, (6) dependenciesamongplans,
(7) temporalconstraints on plans and actions, wherethe
preconditions, postconditions and goals are expressedin
terms of object attribute-values (Hill, 1993). The
knowledge
acquisition problem,of course, is in gathering
this information,since, as we’vealreadysaid, it is normally
only found in an expert’s skill base and not recordedin a
declarativeform.Fragments
of this informationexist in the
procedure manualsand operating guides for the various
devices, but muchof it is undocumented
and can only be
deducedfromexperiencesinteracting with the devices.
to performan operation. Precedencerelations are specified
by the nodes and arcs of the network. The behavioral
knowledge
identifies system-statedependenciesin the form
of pre- and postconditions. Temporalknowledgeconsists
of both absolute (e.g. Acquire the spacecraft at time
02:30:45)and relative (e.g. Performstep Y5 minutesafter
step X) temporalconstraints. Conditionalbranchesin the
network are performed only under certain conditions.
Optional paths are those whichare not essential to the
operation, but may,for example,providea higher level of
confidencein the data resulting froma plan if performed.
Eachnodein the TDN
is called a plan andcontains actions
to be performed. A plan also has goals, pre- and
5. Knowledge Acquisition Tools and Methods
postcondition constraints and temporal constraints
Ourapproachto acquiring knowledge
for the reactive
"associatedwith it. Moredetails about TDNs
are providedin
planner employs the tools shownin Figure 1. REBUS (Fayyad& Cooper1992).
(RequirementsEnvisaging ByUsing Scenarios) (Zorman,
In our experience of building TDNs,the knowledge
1994) and the TDN(Temporal Dependency Network)
bases associatedwith evena single TDN
are quite large and
Authoring Tool are used for acquiring declarative
difficult to build andmaintain. In addition, they rely on
descriptionsof the domain(i.e., devicemodels,procedures, informationfrommanydifferent sources: documentationin
etc.) and the plans used by REACT-P
to performtasks in
paper form, interviews with experts, and text logs of
the domain. RIDESis a simulation authoring toolkit
operationsproceduresfromactual missions, just to namea
(Munroet al., 1993) that is used for implementing
few. As we build more TDNs,muchof this information
executable modelof the devices whosedescriptions were
can be usedagain. Asa result, weare currently developing
acquired with REBUS.
Thesimulation serves as a testing
a TDN
authoringtool to assist Operatorsand developersin
groundfor the REACT-P
agent, and it also helps in the
building, editing, and maintainingTDNs.
validation of the domainmodel. Finally, REACT-P
is an
Withthe TDNauthoring tool, users can graphically
agent implementedin Soar (Laird et al., 1987) that uses
build a TDN
and specify all the informationrequired in a
knowledge from REBUS
and the TDNauthoring tool to
TDN. For example, they graphically create boxes
performtasks andreactively plan, as necessary.In the rest
representingplans, and drawthe links betweenthe plans to
of this section wedescribeeach of the tools just mentioned represent dependenciesbetweenplans. A small segmentof
and howthey are used for acquiring knowledgefor the
a TDNis shownin Figure 2 and contains three plans in
REACT-P
agent.
sequence.This maybe all that the users sees if she initially
creates just a high level TDN
includingskeletal plans anda
partial order of plans. Whena plan is created, the user
It ~citiclioa
gives it a nameandspecifies whattype of plan it is; there
REBUS ]
&rid
description
are different types of plansdepending
on the type of actions
to be takenin a plan, e.g. a manualactionto be takenby the
.Operator, or a list of commands
to be sent to a subsystem.
goals ]
plans
In our example, each of these plans is a command
plan
actionsI
associated
with
the
34
meter
Antenna
Subsystem.
The
Pm/lx~on’~ims
I
putial ¢rd~ ofplam]
sequence of actions for the plan namedClear Boresight
Offsets is shownin Table1. Thefirst two actions set the
simulltioa
ElevationandCross Elevationcorrection offsets to 0. The
execate TDN
tztims
last action sends the structure containing these two
REA
CT-P]
RIDES
reau to a¢iom
variablesto the subsystem.
¯ .
mdLMCOA
.[°N
1
[
1"
¯ ...~L~d
Botesight
"~r
Ct’ar
Borm~ght
Figure 1. REACT-P
and Knowledge
Acquisition Tools.
Figure 2. Portion of a TDN
Temporal Dependency Network (TDN)
Weuse a representation called a TemporalDependency
Network(TDN)to express the basic plan structure and
interrelationships amongplans. ATDN
is a directed graph
that incorporates temporal and behavioral knowledgeand
also provides optional and conditional paths through the
network.Thedirected graph represents the steps required
74
For each plan, the user can then specify the following
informationabout it: the sequenceof actions within the
plan, the pre- and postconditionsof each action, goals of
plans, and temporalconstraints on plans. Depending
on the
knowledgethat the user has about the actions, he mayor
maynot be able to specify all of this information. The
postconditionsof the last action in Table1. fall out nicely
fromthe action itself; thoughthis isn’t alwaysthe case.
Since this last action sends data to the subsystem,it is
necessary to makesure that the subsystem did indeed
receive the newdata values. In this case, we are only
concernedwith the two variables in the structure which
correspond to the first two actions in the plan. The
postconditions for the last command
in Clear Boresight
Offsetsare shownin Table2.
Plan:
Clear BoresightOffsets
Actions:
setvar A34CorrEl0
setvar A34CorrXel0
sendvar ActualCorrData
I
Table1. Plan actions.
Pian:
Action:
Post.condition:
I
Clear BoresightOffsets
sendvar ActualCorrData
ActualCorrData.el= 0
ActualCorrData.xel= 0
Table2. Postconditionfor ClearBoresightOffsets.
In our current prototype,mostof the informationabout
a plan is specified by filling in text forms. Asthe tool
develops,knowledge
bases of actions with their associated
pre and postconditionsand knowledgebases of plans will
be available so that newTDNs
can be built frompieces of
existingones.
Theoutputs of the tool are a text file that completely
defines the TDNand a file depicting the graphical
representation of the TDN.Thesetwo files will be loaded
by the reactive planner.Thegraphicalrepresentationis the
basis for a dynamicdisplay of the TDNin the reactive
planner which shows the progress of the TDNas it is
executing. Thetext file is loadedby the reactive planner
whichuses it to create an executableTDN.
In our example, REBUS
helped to define the device
¯ modelsthat were needed to build a simulation of the
antenna subsystem with RIDES. REBUShas a rich
ontologyfor describingobjects, types, andattributes in the
domain.This fits well with the object, attribute, value
informationneededfor authoringa simulation with RIDES.
For example,in the plan namedLoadBoresight Parameters
shownin Figure2., oneof the parametersset is the number
of boresight points, numbs_points.The representation of
this object using REBUS
is shownin Table 3. This object
of coursehas manyother attributes correspondingto other
boresight parameters. Analysis with REBUSfurther
defined the attribute numbs_.pointsas havingone of two
values: 3 or 5. In addition, REBUS
representedthe default
valueof this object as being3. Definingthe rangeof values
for a value is very necessaryfor our simulationin RIDES
as
well as for pre- and postconditionsin the TDN.Hence,in
the user interface of our simulationbuilt with RIDES,
two
objects weredefined:onefor eachof the possible valuesof
numbs_points.This forces the user to select betweenone
of the twovalid settings of this attribute. Aportionof the
object definition for one of these settings in RIDES
is
shownin Table3.
REBUS
object: ant_boresight
attribute: num_bs_points
range:one of 3, 5
default:3
I
RIDES
object: boresight_w
name:3-button
textvalue:"3"
location:[40r1055
]
Table 3. REBUS
and RIDES
object representations.
Analysis using REBUS
also helped to define pre- and
postconditionsin the TDN.Again, referring to the example
in Figure 2., weneededto find the preconditionsfor the
plan ClearBoresightOffsets. Thepreconditionwasthat the
boresighting procedurehad stopped. However,instead of
representing this as a precondition, weonly ne~edto put
the Clear BoresightOffsets plan after the Boresightplan.
Thereasonfor this is that the Boresightplan executedthe
boresighting procedure. Hence, whenthe boresighting
REBUS:Scenario-based Interview Methodology
procedurefinished, the Boresightplan finished. In this
case, REBUS
defined a dependencybetweenthe Boresight
One of the ways that we acquire knowledgeis
and ClearBoresightOffsetsplans.
through a scenario-based interview methodology.This
Given that REBUS,the TDNauthoring tool, and
approach is being implementedin a tool called REBUS
¯
RIDES
overlap in the knowledgethat they help to acquire
(Requirements Envisaging By Using Scenarios) at the
about
a domain, we envision using these tools as a
University of SouthernCalifornia Information Sciences
acquisitiontools.
Institute by LomaZormanand W.LewisJohnson(Zorman, coordinatedsuite of knowledge
1994; Benneret al., 1993). REBUS
is a graphical editing
RIDESSimulation Authoring Toolkit
tool designed to enable domainexperts and knowledge
The TDNauthoring tool and REBUS
provide the first
engineersto define the behaviorrequirementsfor a system
steps
in
the
knowledge
acquisition
process--they
assist in
by using scenarios. Scenarios provide a context for
the acquisition of declarative descriptions of the domain,
acquiring informationboth about devices andproceduresby
including descriptions of howthe devices work. This
having the expert walk through a scenario with the
interviewer. This is a rigorous approachto capturing much knowledgemayinclude a lot of the operator pre- and
in both planning and plan
of the informationthat is usedunderspecial circumstances, postconditions used by REACT-P
andit reveals failure modesthat are often not documented. execution. To refine the model of the domainthat is
acquiredwith these twotools, weuse the RIDES
simulation
75
authoringtoolkit (Munroet al., 1993)to developworking
models of the devices. We use the simulation to
communicate
with the subsystemengineers about howtheir
system worksso as to refine the knowledgeabout system
states, state transitions, and control. By observing a
simulation,the engineercan validate the system’sbehavior
in a morefamiliar waythan is achieved by looking at a
declarative description of the behavior. Wewould
eventually like to put RIDES
into the hands of these same
DSNsubsystemengineers for use as a design tool and
meansof creating a living and interactive functional
specification of their system, somethingwhichis greatly
neededif wehope to understandand automaticallycontrol
it.
Hence, one of the ways that we refine the REACT-P
knowledgebase is to showa behavioral modelof what is
knownabout a subsystemto an engineer. Thesimulationis
refined by modifyingthe deviceobjects andtheir attributevalues. In manycases a changein the device modelmay
also cause changesto the REACT-P
knowledge
base (e.g.,
preconditionmayneedto be addedor modifiedto reflect a
change to a device attribute.) Since RIDESuses an
attribute-centered approachto representing devices and
their behavior,this fits nicely with the kind of knowledge
that weneedfor representingpreconditions,postconditions,
goalstates, andso on.
A second way that the RiDES-basedsimulation is
usedfor refining the knowledge
base is throughinteractions
with the REACT-P
agent. The simulation provides a
realistic setting for testing REACT-P
and iteratively
refining both the simulator and the planning agent’s
knowledge.Therole of the simulator is further enhanced
by the fact that the DSNoperational environment is
relatively inaccessiblefor routine testing of experimental
prototypes. Whenaccess to the DSNis granted, the time
spent there is quite costly and there are extremesafety
measures that must be observed, so there are some
pragmaticreasonsfor usinga simulator.
experimenters, will likely have to do muchof the
knowledgeacquisition using the tools described in this
paper.
REACT-P:A Soar Agent for Monitor and Control
The REACT-P
agent is being developed in the Soar
(Laird et al., 1987) problem solving architecture.
mentionedabove, wehave developedan interface between
Soar and RIDES
so that REACT-P
can be tested against the
RIDES-based
simulations of the DSNdevices. Theinitial
REACT-P
agent design is based on the expert cognitive
modelused for the REACT
intelligent tutoring system(Hill,
1993). TheREACT
tutor is capable of reactively planning
smallportionsof a task basedon the needto help a student
overcomean impasse encountered while performing the
task. REACT-P
will extendthis capability to deal with the
needto recoverfromdeviceanomaliesor failures.
REACT-P
will be run against different scenarios on
the RiDES-based
simulator. In this waywe will emulate
the skill acquisition process wesee in humanOperators
wholearn throughexperience--particularlywhenthey reach
impasse points where they are forced to acquire new
knowledge
in order to completea task. In this case, we, the
6. Conclusions
In conclusion, weare building an agent to perform
monitor and control tasks on complexcommunications
devices. Theagent must be capable of expert humanlevels
of performance,and wepostulate that the wayto acquire
the knowledgeto accomplishthis goal is similar to how
humanslearn and acquire skill. Weoutline someof the
difficulties of acquiringknowledge
in a real-worlddomain,
.and wepostulate that the knowledgeacquisition problem
for developing a real-world planner should be treated
analogouslyto the waythat humanOperatorsare trained to
acquire a skill, that is, throughexperienceand knowledge
refinement,Finally, our approachis describedfor capturing
knowledgeabout the problem domainwith a combination
of tools andrepresentations.
76
7. References
(Benneret al., 1993) K. Benner, M.S. Feather, W.L.
Johnson, L. Zorman. "The Role of Scenarios in the
Software Development Process." In N. Prakash, C.
Rolland, and B. Pernici, editors, Information System
DevelopmentProcess, IFIP Transactions A-30, Elsevier
SciencePublishers, September,1993.
(Chien, Hill, Fayyad, 1994) S. Chien, R. Hill,
Fayyad."WhyReal-worldPlanningis Difficult." Working
Notes of the 1994 Fall Symposiumon Planning and
Learning: On to Real Applications, NewOrleans, LA,
November1994, AAAIPress.
(Fayyadet al., 1993) K. Fayyad,R. Hill, and E.J.
Wyatt. "KnowledgeEngineering for TemporalDependency
Networks as Operations Procedures." Proceedings of
AIAAComputingin Aerospace9 Conference, October 19¯ 21, 1993,SanDiego,CA.
(Hill&Johnson, 1993a) R. Hill and W.L. Johnson.
"Designing an intelligent tutoring system based on a
reactive modelof skill acquisition." Proceedingsof the
WorldConferenceon Artificial Intelligence in Education
(AI-ED93), Edinburgh,Scotland, 1993a.
(Hill&Johnson, 1993b) R. Hill and W.L. Johnson.
"Impasse-driventutoring for reactive skill acquisition."
Proceedings of the 1993 Conference on Intelligent
Computer-Aided Training and Virtual Environment
Technology (ICAT-VET-93), NASA/Johnson Space
Center, Houston,Texas, May5-7, 1993b.
(Hill, 1993) R. Hill. "Impasse-driventutoring for
reactive skill acquisition." Ph.D. diss., University of
SouthernCalifornia, 1993.
(Hill et al., 1993)R. Hill, K. Sturdevant, and W.L.
Johnson. "Towardan embeddedtraining tool for Deep
Space Network Operations." Proceedings of AIAA
Computingin Aerospace 9 Conference, October 19-21,
1993, San Diego, CA.
(Hill&Johnson, 1994) R. Hill and W.L. Johnson.
"Situated Plan Attribution for Intelligent Tutoring." To
appear in the Proceedings of the Twelfth National
Conferenceon Artificial Intelligence, July 31-August4,
1994,Seattle, WA.
(Laird et al., 1987) J. Laird, A. Newell and
Rosenbloom.
Soar:. Anarchitecture for generalintelligence.
Artificial Intelligence,33, 1987:1-64.
(Munroet al., 1993) A. Munro,M.C. Johnson, D.S.
Surmon,and J.L. Wogulis."AIIribute-CenteredSimulation
Authoring for Instruction." Proceedings of AI-ED93,
WorldConferenceon Artificial Intelligence in Education,
Edinburgh,Scotland; 23-27 August1993.
(Suchman,1987) Suchman,L.A. Plans and Situated
Actions: The Problemof Human-Machine
Communication.
Cambridge
University Press, NewYork, 1987.
(Zorman, 1994) Zorman, Lorna. "Requirements
Envisaging by Utilizing Scenarios." Ph.D. Diss., in
preparation,Universityof SouthernCalifornia, 1994.