close

Вход

Забыли?

вход по аккаунту

?

6.1991-2759

код для вставкиСкачать
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
AIAA 91=2759
PILOT'S ASSOCIATE: A
GRATION
ARCHITECTURE FOR DECISION AIDING
K.J. Keller, K.C. Stanley
McDonnell Aircraft Company
McDonnell Douglas Corporation
St. Louis, MO
c
AIAA Guidance, Navigation
For permission to copy or republish, contact the American Institute of Aeronautics and Astronautics
370 L'Enfant Promenade, S.W., Washington, D.C. 20024
d
PILOT'S ASSOCIATE: AN INTEGRATION ARCHITECTURE
FOR DECISION AIDING
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
K.J. Keller, K.C. Stanley
McDonnell k r a f t Company
McDonnell Douglas Corporation,
St. Louis, Mo.
ABSTRACT
As part of the Pilot's Associate (PA)
program, McDonnell Aircraft (MCAIR)
Company developed and demonstrated an
"associate" system for tactical aircraft performing
an air-to-ground battlefield interdiction mission.
The demonstrated mission functionality included
threat assessment, system capabilities
assessment, threat reaction planning, target attack
planning, pilot monitoring, and information
management. Appropriate controls and displays
were developed to support the demonstration in a
manned aircraft dome simulator. The system
development approach and software architectureis
based upon a task network system model. The
activities of the pilot, PA and external agents
such as a wingman are modelled by objects called
tasks. Tasks may be decomposed into a complex
sequence, or network, of more detailed
subcomponents. This model of the task
sequences and their functionality define a
hierarchical network of tasks which allow the
representation of complex system and pilot
activity for steady state behavior and reaction to
changes in the environment. It captures
dependencies and interactions between activities
and provides a means for system control of the
PA problem solving process. The structure
derived from the task network system model
provides: 1) a domain specific requirements
language or representation that is shared by the
domain expert and software developer, 2) data
structures and frameworks for the software
design, and 3) visibility into the system behavior
that helps create a more intuitive interface and
system operation. The above features combine
to potentially improve the downstream life cycle
performance and favorably impact training and
the tailoring of the system in the field. The
Pilot's Associate program (contract W33615-86C-3802) is sponsored by the Defense Advanced
Research Projects Agency (DARPA) and
administered by the United States Air Force.
Copyright
0
1991
by
McDonnell
Douglas.
Published by the American
Institute
of
Aeronautics
and
Astronautics, Inc. with permission.
1.0 INTRODUCTION
The Pilot's Associate (PA) is a system of
cooperating knowledge-based systems that will
improve the mission effectiveness of the tactical
fighter pilot by supporting the pilot in
performing mission tasks. The cooperating
knowledge based systems consist of six modules:
situation assessment (SA), system status (SS),
mission planning (MP), tactical planning (TP),
pilot/vehicle interface (PVI), and system
executive (SE). The SA module monitors and
assesses the external environment.
SS
determines the status of the aircraft systems and
recommends responses to degraded or emergency
situations. M P generates recommendations
relative to the mission plan. TP recommends
tactical responses to threat actions and supports
target attack. The PVI module performs
information management and monitors pilot
actions. An SE module coordinates system
activity to guarantee responsiveness and
coherency.
This paper describes the characteristics of
the Pilot's Associate (PA) domain, and then
discusses the functional and architectural
requirements of the Pilot's Associate (PA)
system. It then outlines the components of the
Task Network architecture developed by
McDonnell Aircraft to support the development
of the PA system. Finally, it discusses the
features of the architecture and how they relate to
development of a real-time decision support
system.
2.0 PA PROBLEM DOMAIN
REOUIREMENTS
The PA system operates in an environment
described as: complex, dynamic, hostile,
resource-bounded, and interactive. These
characteristics define requirements for the PA
software architecture (figure 1-1).
Context Model
Task Network
. .
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
Domain Char* Complex
Dynamic
Hostile
Resource-bounded
Interactive
Dependency
Task Network Components
Packet Post-Processors
Mission Model
Context Model
Exception Handlers
Task Execution
v
Explicit Representation of Plans
Supports Modular System Development
Provides a Requirements Specification Language
Supports a Representation of a Model of the
User's Activity
Provides Event-Driven, Adaptive Behavior
Figure 1-1. PA Software Architecture Requirements
communications. The PA software architecture
will provide a framework for cooperation between
tasks to ensure high resource utilization in a
timely manner.
The environment is complex since its
initial state is largely unknown and behaves in
ways that are only partially understood. The
environment is dynamic since external forces not
under PA's control can change without warning,
and in unpredictable ways. These characteristics
require a software system that can monitor and
react to significant changes in the environment
[Firby, 198911; [Hendler, 198712.
The PA role as a decision support and task
automation system for the pilot requires a system
interface that is highly interactive. It also requires
a system software design that is capable of
changing focus of attention rapidly and smoothly
to support the changing objectives of the pilot.
The environment is hostile since dynamic
changes in the world may affect PA objectives in
a negative manner. Some of these hostile
changes may be due to intelligent activity
specifically directed at thwarting PA objectives
through destruction, capabilities impairment, or
deception. The software design must support
quick recovery from hostile actions without
ignoring unaffected, ongoing, PA activity.
Other requirements of the PA software
architecture are real-time operation, and
distributed processing. PA is a "real-time"
software system since correct operation depends
both on logical correctness and timeliness of
responses to a dynamic environment [Stankovic,
198813. Software in an avionics environment is
distributed across multiple processors. A PA
implementation will likely be partitioned among
several processors to decrease the
communications overhead with the various
subsystems interacting with PA.
PA operation is resource-bounded. Some
examples of resources that must be considered
during PA operation are: time, fuel, weapons,
countermeasures, data processing, memory, and
2
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
3.0 TASK NETWORK ARCHITECTURE
Tasks represent a central component of the
architecture. System functionality is defined in
terms of the tasks of the system. The task
network is modelled after the the procedural
network structure, first proposed in the NOAH
system [Sacerdoti, 198314. The partially ordered
sequence of tasks in the network identifies
control flow and context information for the state
of the mission.
Through an explicit
representation of system and pilot tasks, the
system may reason about it's own activities.
Typically, this reasoning involves predicting
system timeliness, interactions between tasks,
errors of omission by an external agent (e.g. a
pilot), the information requirements of the pilot,
or responses to failure conditions of the task.
Each task is represented as a specialist
responsible for performing a function when
activated.
The PA system is composed of a number of
modules which are implemented using common
software frameworks for system development.
Each of the modules is developed using this
system architecture. The system architecture is
composed of software elements for system
control, data representation, and inferencing. The
Task Network architectureprovides a mechanism
for system coordination in a number of areas. It
controls the modules by the synchronization of
functionality between and within modules. It
provides a representation for pilot activity
consistent with the tasks of the pilot in the
mission.
It provides a mechanism for
partitioning functions between modules and the
pilot.
3.1 Components
The task network represents the tasks which
are to be performed in support of a mission.
This requires that the sequence of the tasks, and
other significant parameters of the tasks be
modelled. An example of the structure of a task
network is shown in Figure3.1-3. Tasks are
defined in a hierarchical manner such that they
may be decomposed into subtasks which refine
the activities that they represent. This is useful
for reasoning about tasks at different levels of
abstraction in monitoring, planning, and
execution.
The task network provides
mechanisms for:
1) system coordination,
2) maintaining assumptions about the
environment,
3) handling exceptions, and
4) representation of interaction with the
pilot.
The top-level architecture of the task
network framework is shown in figure 3.1-2.
The main components of the framework are:
packet post-processing, the context model, the
task network mission model, exception handling
and task execution. Data flow in this architecture
consists of communication from external
processes through packet post processing which
appropriately manipulates the data to update
objects in the context model. Events are
signalled to the task network mission model,
resulting in changes in task status or the
execution of an exception handler. When tasks
are activated they are placed on a task agenda and
executed in order of priority. The execution of
tasks may result in the modification of internal
models (internal actions) or the communication
of data to other processes (external actions).
HANDLER
Figure 3.1 -2.
Task Network Top-Level Architecture
3
.
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
I
Perform Mission
Figure 3.1-3
I
Example Task Network Structure
The Context Model is developed as an
hierarchical, distributed, object-oriented database.
The Context Model is used to represent
information about the external environment, the
pilot, the aircraft, and the PA system itself
(figure 3.1-4). This representation was designed
to allow the detection of events from state data.
Since PA has relatively little control over actions
in the external environment (e.g. hostile threats,
weather, etc.), it must make many assumptions
during plan generation and execution. PA must
be able to adapt quickly and correctly when the
external environment changes in a way that
invalidates the planned system behavior. A
software construct called a dependency provides
PA with the capability to detect violations in
assumptions.
Pilc
which influence the validity and efficiency of
plans. These dependencies allow the tasks to
represent complex relationships between the
tasks and the state of the environment (i.e. the
context of the current situation). These
dependencies are checked when changes are made
to the Context Model parameters. When
dependencies are violated, this is signalled to the
task. This signal is referred to as an exception.
~
Exceptions represent violated dependencies
which involve a response by the system. This
response is referred to as an exception handler.
These exception handlers are defined for tasks to
aid in the recovery of violations in the
assumptions of the plan. Exception handlers
may be either local or system exception handlers.
Local handlers are implemented using methods
on the task which result in minor, local, changes
to the plan or states of various systems. System
handlers involve the creation of System
Response Plans which use the Task Network
framework as a control mechanism for replanning
of portions of the currently executing task
network.
3.2 Features
Figure 3.1-4 Dependency
Representation
The Task Network allows dependencies to
be placed on states of the environment, the pilot,
and the PA system through a subset of the Task
Network framework referred to as the Context
Model. Dependencies represent assumptions
The Task Network architecture provides
support for requirements specification, system
design, and system development.
The
components of the architecture allow for the
uniform representation of the elements of the
domain. These components and their interrelationships were developed to address the
requirements of the PA domain. The benefits of
the Task Network Architecture are realized from a
set of features which aid in the development of a
4
real-time decision support system. These
features are described in the following sections.
Software Contains Exdicit Representation
of Functionality
3.2.1 ExDlicit Remesentation of SvStem
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
&as
The partially ordered sequence of tasks, also
commonly referred to as a non-linear plan
representation, is capable of describing
ambiguous ordering constraints on tasks due to
uncertainty in execution order and concurrency in
task execution. Tasks in the task network are
represented hierarchically, describing the mission
at various levels of detail. Tasks contain both
declarative and procedural components.
The requirements of the PA system are
often described in terms of the aircraft mission.
This mission description includes the objectives
of the pilot and his weapon system in a hostile
and uncertain environment.
Mission
decomposition is usually performed using a
number of representative scenarios. Mission
decomposition is a top-down approach to
dissecting a combat mission into its functional
segments. Those segments are then divided into
tasks which are required to complete each
segment. As the functions and tasks become
more specific, they can be analyzed in terms of
information flow and functional partitioning.
The task network supports this specification
through it's explicit representation of the
sequence of tasks in the mission.
The task network architecture has a dual
nature in the role of the explicit task
representation. The task representation is both a
model of the state of the mission and a control
paradigm for the synchronization of autonomous
systems. This dual nature provides the capability
to specify functions in the context, (i.e. the state
of the mission), in which they will be executed.
It also provides a mechanism for specifying
temporal constraints on the execution sequence of
tasks.
The explicit representation of functions as
tasks in the system provides advances in software
design by supporting graceful adaptation through
reasoning about task timeliness, the explicit
representation of parallelism in task execution,
by promoting modular coding techniques,
explicit control synchronization between tasks,
and visibility into system operation through the
use of mnemonic names for tasks (figure 3.2-5).
Enables Control Reasoning
Completing tasks by their assigned
deadlines is the very definition of a hard real-time
system. However, the character of the Pilot's
Associate prompts us to expand the definition to
include the concepts of both hard and soft
deadlines. While meeting hard deadlines is still a
requirement for correctness, meeting soft
deadlines is not smctly required, but is certainly
desirable. The design philosophy of the PA has
been that the system need not have sufficient
computing power to complete any conceivable
set of tasks, only that it have the ability to
choose the right subset of tasks to complete.
For this reason, we expect that in some
situations, not ail tasks will complete on time.
,
Control reasoning is useful for a decision
support system with soft deadlines which is
attempting to optimize its performance outside of
hard scheduling constraints. The system may
predict missed deadlines, delete unnecessary steps
to meet imminent deadlines, and perform
reasoning about solution quality/timeliness tradeoffs. Control reasoning is also supported by the
management of system priorities on tasks.
Figure 3.2-5. Task Network
Structure
Priorities are assigned to tasks during the
mission execution, using the tasks' importance,
deadline, duration, and the current mission time.
5
The importance of a task is established before the
start of the mission, although task importances
may change depending on the mission context.
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
SUDDorts COOrdination and Cooaeration
The PA system is a collection of diverse
knowledge based systems with the possibility of
concurrent execution. While concurrency may
not be utilized physically, the components of the
PA are intended to operate in a functionally
distributed fashion. Functional distribution, in
this context, merely means that the components
are designed to allow the possibility of
concurrent operation. Each component is a realtime AI system. That is, each component
receives events and data asynchronously and
carries out steps of assessment, planning and
execution, all constrained by timing
requirements. For such a collection of real-time
knowledge based systems to form an integrated
system, they need to behave in a coordinated
manner that is also timely, responsive, and
adaptive to a changing environment.
4
Object-Oriented
FA Mission
Context Models
Figure 3.2.2-1. PA Object
Oriented System Design
activities, which provides a mechanism for
representing and detecting conflicting interactions
between tasks. The problem of finding such
interactions in non-linear plans is a
combinatorial problem [Wilkins, 198815, and
therefore provides several difficulties to a realtime system using such a representation.
Coordination refers to a system-wide
coherence among tasks and plans, to a resource
management scheme based on a global
perspective, and to dynamic adjustment of tasks
and plans to accommodate changes in overall
system performance goals. Coordination, in
short, is what makes the whole system add up to
more than just the sum of the parts. And
because coordination must take place in a realtime environment, the system must weigh the
extent of coordination activities against deadline,
processing, and communication constraints so
that the resulting benefits are not cancelled by the
overhead of the coordination effort.
3.2.2 Modularity
Obiect-Oriented Software Design
One of the key characteristics of the PA
design is the use of object-oriented programming
techniques to represent, monitor, track, and
resolve events that occur within the pilot’s
problem domain. This is achieved through the
use of the Task Network and the Context Model
frameworks (figure 3.2.2-1). In addition, much
of the information managed by the PA is objectoriented in nature; including: 1) information
about tasks which must be performed to
successfully complete the mission (including
their relationship to other tasks) and, 2)
information about the mission environment that
relates to other known information (For example,
an SA-11 is known to be a ground threat. This
relationship implies that certain options pertinent
to dealing with ground threats are to be
considered when evaluating a specific instance of
an SA-1 1).
The concept of coordination and cooperation
of distributed, knowledge-based systems is being
examined extensively in the research community.
The PA program attempted to address some of
the issues of distributed problem solving through
the development of several knowledge-based
systems in areas of situation assessment, system
status, mission planning, tactics planning, and
pilot/vehicle interface. Each of these systems
were allocated functionality supporting a realtime decision support system for pilot aiding.
The task network architecture supports the
development of a distributed system through the
synchronization of module activities in
performing mission tasks. The task network
identifies temporal relationships between module
Many of these relationships are represented
using Task Networks and Context Models, linked
6
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
(via message passing facilities) with each other
and with a pattern matching Fact Base (as shown
in Figure 3.2.2-1). It is believed that the
representation of the PA design using objectoriented programming techniques will provide an
affordable, upwardly compatible mechanism for
integrating new mission functionality into a PA
eqllippedahaft.
One of the key features of the Task
Network approach is the ability to describe tasks
from the perspective of a mission, and then use
that same description as a foundation for code
development. This philosophy is supported by
the encapsulation of functionality as provided by
object-oriented programming. The most efficient
means of designing and modifying a Task
Network data structure is through the use of a
graphical interface. The Task Network
implementation offers a mechanism by which
application code could be seamlessly integrated
with code generated from a Task Network Tool
(figure 3.2-2).
The benefits of object oriented software
design are seen in the mapping of the domain
structure into the system architecture. Data
abstraction and information hiding promote
efficiency in software design, debugging, and
maintenance.
Hierarchical Function Specification
Requirements are specified through mission
decomposition. Successive refinement of the
details of the mission aid in the derivation, and in
the organization, of functional requirements.
The task network provides a mechanism for
abstracting the program, minimizing clutter and
increasing system clarity. The decomposition of
the mission into independent tasks leads to
modular software and aids in managing the
complexity of the system design.
ODDoI;tunistic Execution of Tasks
i-
The sequence of tasks in the network
identify temporal constraints on control flow.
The non-linear plan representation allows
ambiguity of task ordering. The execution of
tasks may be performed opportunistically and
behavior is situationally dependent. This allows
the system to improve and tune it's performance
based on the context of the cunrent situation.
Figure 3.2-2. Task Network
Tool Workstation
3.2.3 Reauirements Specification Lanmage
The task network architecture provides
support through the entire software development
process, from requirements generation
(specification) through maintenance. Each
module function is developed using the task
network hmework for planning, assessment, and
human interface functions. The task network
framework is a programming paradigm for the
development of intelligent systems. The goal of
the framework is to provide a common language
between the requirements specifier, system
designer, and system user. This will lead to
systems which have traceable requirements in the
program design and whose operation may be
easily understood by the user. The program
structure serves as a model of the user in
performance of his mission. The network of
Control Flow ManiDuhted GraDhically
The partially ordered sequence of tasks lends
itself very well to a graphical depiction of the
sequence of tasks performed during the mission.
The implementation of tools for the graphical
manipulation of tasks provides an efficient and
intuitive interface for system control
specification. At the same time tools will also
provide aid in debugging the performance and
functionality of the system since the current state
of the system is represented pictorially through
the state of the tasks in the network.
7
tasks, organized into a partially ordered sequence,
describe the sequence of tasks to be performed by
the system and user. Unplanned events must
also be accounted for in the system design. The
design for the detection of unplanned events,
dependencies, makes the conditions for plan
failure explicit.
execution of these tasks. In some cases, the
tasks may oniy be monitored to maintain context
information for the system, and in other cases
information may be provided in a timely fashion
based on the recognition of the execution of the
task by the user.
u
Context Obiects Identify Relevant
Parameters of Environment to be Assessed
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
Svstem Reauirements Specified in Mission
Decomposition
The Context Model is used as an objectoriented database for representing state
information about the domain. These states
identify known parameters necessary for a
decision support system to perform it's function.
The context model is the primary interface to,
and between, tasks.
The analysis of the mission results in
identification of pilot and system activities as
they relate to various phases of the mission.
This analysis includes the identification of
mission objectives, tasks that need to be
performed, information required to perform the
mission successfully, candidate approaches for
automation and decision aiding support, and the
identification of constraints imposed by
combinations of the above.
3.2.4 User Activity Model
The primary goal for modeling the user in
the task network architecture is to minimize
interactions between the system and the user and
thereby develop a non-intrusive, cooperative
decision support framework. Through modeling
the user, the system is supplied with necessary
context sensitivity to work efficiently with the
user.
Sequencing tasks in the mission identifies
the context within which tasks are to be
performed and the temporal constraints for
efficient and effective mission performance.
Through the process of mission decomposition,
functional requirements are identified along with
the context that they are to be executed. This is
a result of the representation of the mission
sequence--mixing pilot and system activities
together in a coordinated fashion.
The task network models the user's
activities as a well structured sequence of tasks
identifying preferred task execution sequences.
This sequence is assumed to be a valid sequence
for task execution.
Task Assignment
Tasks may relate to activities involving
information gathering, decision making, or the
performance of external activities or systems
control. The integration of assessment,
planning, and execution in a interleaved system
architecture are central to the task network
concept for decision support system
development.
Active Tasks Identify Current Activities
Typically, monitoring systems have
focused on task elements (discrete, atomic
operator actions) to determine intent pouse,
198716. From sequences of these task elements,
higher level actions and goals are inferred.
Although this approach appears to be intuitively
correct, some complications make it extremely
burdensome. First, for any desired outcome, the
operator may have several distinct methods to
achieve that goal. When looking for distinct task
elements, all possible methods would need to be
explicitly encoded into the monitoring system.
If a slight modification of an existing method is
developed, it must be added to the system.
Second, as tasks compete for the pilot's
attention, a task element necessary for one task
may counteract a task element performed in
support of the other. All such interactions would
need to be identified. Third, the timing
Tasks may be assigned to the system or the
pilot. The concept of dynamic task allocation,
however, is still somewhat controversial and
poses some difficult issues in decision support
development. System predictability may suffer if
allocation of tasks is not static and is constantly
being modified.
Analysis of the decision aiding role of the
system will determine the appropriate role of the
system in mission performance. Tasks may be
performed by the user of the system and there are
a number of ways to support the user in the
8
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
relationships between task elements is also
important.
3.2.5 Event-Driven Adaptive Behavior
The pilot monitoring approach which was
adopted, focussed on the state of the world
represented in the Context Model, rather than on
explicit pilot interaction. The approach isolates
the monitor from the need to identify all methods
of performing a task, all actions that may undo a
given task, and explicit legal time intervals for
tasks. The result is concise, robust, taskmonitoring rules that can be incrementally
enhanced as the Context Model grows richer.
Embedded applications must be capable of
recognizing and responding to exceptional
situations. This is especially true for the PA
system which is in an environment which is
hostile, dynamic, and very uncertain. The
system must be responsive to changes in the
environment which hinder the successful or
efficient execution of the mission.
m d e n c i e s Identifv Imminent and Detected
Failures of Plans
The task network represents the activities of
the user by activating tasks when evidence
indicates that they are being performed or have
been completed. Active tasks identify the
information which is required by the user of the
system. This provides a mechanism for
providing information to the user which is both
relevant and timely .
The task network architecture supports
monitoring for exceptional conditions through
the dependency mechanism. Dependencies are
distributed throughout the task network at several
levels of the task hierarchy. These dependencies
identify significant events which signal predicted
and detected failures of tasks. Each task is
defined as a modular collection of procedural
knowledge about how to recognize and respond to
predefined events.
DeDendencies on Parameters Provide
Evidence to Activate Tasks
I
I
For each user task, the factors need to be
identified which signal that the candidate task is
being performed or has been completed. Factors
can be related to direct activity of the pilot, to
environmental conditions such as threats and
weather, to mission performance assessment, to
aircraft systems, to the model of the pilot, or to
the state of PA. Factors can be either the
presence or the absence of a condition including
the states of other tasks.
Exception Handlers Modify Behavior
Throwh Chanves in Explicit Plans
Exception handlers are procedures which are
implemented to respond appropriately to events.
Each task is responsible for handling these events
by one of several classes of reactions such as:
abandoning the task, retrying to achieve the
results of a task, choosing an alternate method
for accomplishing the task results, or repairing
the cause of the error. The complexity of
exception handlers may be quite simple, or may
require extensive replanning of the mission.
Active Tasks Identifv Information Reauirep
By modeling the operator in the system, it
is possible to predict his needs and therefore
identify the appropriate decision support role.
The task network relates tasks with the
information that is needed to perform that task.
This allows the system to identify system
activities to supply this information. Such
functionality has been prototyped in the PA
system Display Management function. By
associating information content with display
formats, it is possible to identify displays which
satisfy the information requirements of the active
tasks, and thereby automatically select and
present displays which relate this information.
Replanninrr and Execution Are Interleaved
It is not possible to predict all possible
events which will be encountered in any mission.
Deliberation on new plans often involves
extensive processing resources devoted to solving
problems encountered in the execution of plans.
However, a real-time system cannot afford to halt
execution while replanning is underway. The
current design of the task network allows the
system to inhibit tasks which are in an exception
state, while continuing to execute other tasks
which are unaffected by the exception.
In an unpredictable environment, a system
must be able to react to unexpected changes in an
9
intelligent manner. Although, several researchers
have addressed this issue [Agre, 198717; Firby,
198911; [Hendler, 198712; [Maes, 198918, work
on integrating reaction with planning is just
beginning. This implies that a general solution
to intelligent reactivity will not be available in
the near future.
Downloaded by UNIVERSITY OF NEW SOUTH WALES (UNSW) on October 26, 2017 | http://arc.aiaa.org | DOI: 10.2514/6.1991-2759
4.0
R. James Firby. "Adaptive Execution in
Complex Dynamic Worlds", Ph.d.
Dissertation, Yale Computer Science Dept.,
YALE/CSD/RR#672, January, 1989.
coNCLUSION
James A. Hendler, James C. Sanborn. "A
Model of Reaction for Planning in Dynamic
Domains", DARPA Knowledge Based
Planning Workshop Proceedings, December,
1987.
The PA problem domain is indicative of
real-time decision support systems. In many
cases it is much more demanding than may be
expected in other domains, but most of the
characteristics may be expected to some extent.
The architecture developed for the PA system is
intended to be a general framework from which
systems may be implemented which address these
domain characteristics.
John Stankovic. "Real-Time Computing
Systems: The Next Generation", IEEE Hard
Real-Time Systems Tutorial, 1988.
'!
Sacerdoti, Earl D., A Structure for Plans and
Behavior (Elsevier: Computer Science
Library, 1977).
The Task Network Architecture provides a
framework for developing real-time decision
support systems. Benefits result from it's
uniform representation of planning, and
assessment. It provides a common language
between the requirements generator, developer and
system user. By allowing visibility into system
operation, system testing is made simpler. This
visibility also aids in system acceptance from the
user because of increased understanding of the
system behavior.
Wilkins, David E., Practical Planninrr:
Extending. the Classical Planninrr Paradigm
(San Mateo: Morgan Kaufmann Publishers,
1988), (p. 11).
Rouse, William B., Norman D. Geddes, and
Renwick E. Curry, "An Architecture for
Intelligent Interfaces: Outline of an Approach
to Supporting Operators of Complex
Systems", Human-Computer Interaction, Vol.
3, No. 2, 1987.
i
Real-time performance is supported by the
Task Network architecture through it's capability
to model system activity, and reason about
system timeliness. The architecture supports
parallel implementations of a system through the
explicit specification of task sequences and
functional partitions. The ability to recognize
and appropriately respond to unplanned situations
is provided through the use of dependencies and
exception handlers. The primary advantage of
the Task Network architecture is provided by the
integration of system functionality with a model
of the system user's activities.
Philip Agre and David Chapman. "Pengi: An
Implementation of a Theory of Activity",
Proceedings of the American Association of
Artificial Intelligent, 1987.
Pattie Maes. "The Dynamics of Action
Selection", Proceedings of the International
Joint Conference on Artificial Intelligence,
1989.
ACKNOWLEDGEMENT
The concepts discussed in this paper are the
result of five years of research and development
by the McDonnell Aircraft Pilot's Associate
development team, including FMC Corporation.
10
Документ
Категория
Без категории
Просмотров
0
Размер файла
427 Кб
Теги
2759, 1991
1/--страниц
Пожаловаться на содержимое документа