Researchers describe their experience using graphics tools and utilities while building an application, AUTOPS, that uses a graphical Machintosh (TM)-like interface for the input and display of data, and animation graphics to enhance the presentation of results of autonomous space vehicle operations simulations. AUTOPS is a test bed for evaluating decisions for intelligent control systems for autonomous vehicles. Decisions made by an intelligent control system, e.g., a revised mission plan, might be displayed to the user in textual format or he can witness the effects of those decisions via out of window graphics animations. Although a textual description conveys essentials, a graphics animation conveys the replanning results in a more convincing way. Similarily, iconic and menu-driven screen interfaces provide the user with more meaningful options and displays. Presented here are experiences with the SunView and TAE Plus graphics tools used for interface design, and the Johnson Space Center Interactive Graphics Laboratory animation graphics tools used for generating out out of the window graphics

Aldridge, J. P.

Benson, S.

Bochsler, Daniel C.

Horner, S.

Kullman, A.

Mulder, T.

Parrott, W.

Roman, D.

Schmeckpeper, K. R.

Watts, G.

English

NASA Technical Reports Server

N90-20661
APPLICATIONS OF GRAPHICS TO SUPPORT A TESTBED
FOR AUTONOMOUS SPACE VEHICLE OPERATIONS
K. R. Schmeckpeper, J. P. Aldridge, S. Benson,
S. Horner, A. Kuilman, T. Mulder, W. Parrott,
D. Roman, G, Watts
McDonnell Douglas Space Systems Company
Houston, Texas 77062
ABSTRACT
We describe our experience using graphics
tools and utilities while building an
application, AUTOPS, that uses a graphical
Macintosh (TM)-like interface for the input
and display of data, and animation graphics to
enhance the presentation of results of
autonomous space vehicle operations
simulations. AUTOPS is a test bed for
evaluating decisions for intelligent control
systems for autonomous vehicles. Decisions
made by an intelligent control system, e.g., a
revised mission plan, might be displayed to
the user in textual format or he can witness
the effects of those decisions via "out of the
window" graphics animations. Although a
textual description conveys essentials, a
graphics animation conveys the replanning
results in a more convincing way. Similarily,
iconic and menu-driven screen interfaces
provide the user with more meaningful
options and displays. We present our
experiences with the SunView and TAE Plus
graphics tools that we used for interface
design, and the Johnson Space Center
Interactive Graphics Laboratory animation
graphics tools that we used for generating our
"out of the window" graphics.
INTRODUCTION
For several years, much effort has gone into
the development and application of enabling
and enhancing technologies for support of
space operations. Many new technologies and
methods, such as artificial intelligence and
expert systems, have been applied to flight
Daniel C. Bochsler
LinCom Corporation - Houston Operations
Houston, Texas 77058
design software, user interface problems,
ground and flight crew training, ground based
mission control operations, robotic operations,
flight systems management, etc. [1] The
AUTOPS (autonomous operations) test bed
integrates many of these technologies into a
single framework to develop effective
operations management, an element of mission
success that is equal in importance to reliable
hardware and software. [21
AUTOPS is an evolving tool that has thus far
been developed to the point of a feasibility
demonstration that makes considerable use of
animated graphics and screen interaction
graphics. The animations are used for
demonstrating proximity operations autonomy
in operation planning, mission monitoring, and
fault management. Screen graphics
additionally assist in demonstrating vehicle
monitoring and health maintenance expert
systems and rendezvous planning activities.
Because these items form uniquely
informative means to convey system behavior
to an analyst, they form an important feature
of AUTOPS.
Although the importance of good graphics is
unquestionable, their development has
previously represented a significant
commitment of time and effort. The
availability of graphics tools has significantly
changed this level of commitment. In this
paper, we discuss our recent experience with
using some of these tools.
AUTOPS CONCEPT
Figure 1 illustrates the architecture of
AUTOPS. The test bed consists of a collection
65
https://ntrs.nasa.gov/search.jsp?R=19900011345 2020-03-19T22:51:35+00:00Z
of objectsdedicatedto specificactivities:a test
bed controller and vehicles that contain
subobjectssuch as intelligent vehicle control
systems, orbital and hardware simulations,
and data managementcapabilities. The
graphic capabilities are isolated from the
computationalcapabilitiesin the graphicsand
operator interface objects controlled by the
test bed controller. This architecturepermits
the reuseof codedevelopedby othersor the
use of tools developedby others to produce
the desired interfaces. Intelligent control is
accomplished through cooperating expert
systems that perform mission direction,
mission monitoring, operationsplanning, and
systemhealth monitoringand fault recovery.
Currently, "vehicles" use software simulation
as the means for providing orbital motion
parametersand consistentsensorresponseto
the orbital environment and vehicle
subsystemoperation. It is our intent to
provide the capability to integrate hardware
into the test bed to provide someof these
data. For example,if it weredesirableto test
the ability of a vision sensorfor use in close
proximity operations, a television picture
could be generated using the animated
graphicsand fed back to the vision hardware
for the appropriate vehicle. A more
immediateexample is to use a fuzzy logic
hardwarechip to provide engine firings in
place of the fuzzy logic controller software
usedin the feasibility demonstration.
Finally, other featuresof AUTOPSincludethe
executionof the operationin real time and
integration of currently available programs,
especially simulation software. Real-time
operation means here that the simulation
computationswill occuroftenenoughto reflect
actual behavior of an autonomous space
vehicleand that time spentby expert systems
in arriving at a decision for action will be
taken into account.
SCREENI TERFACES
Our feasibility demonstrationrequired three
screen interface designs: a main Operator
Interface (OI), an interface to the electrical
power systemexpert system(EPSYS),and an
interface to the propulsion system expert
system (PROPSYS).These interfaces were
constructedover a periodof time in which we
were significantlyincreasingour graphicstool
capability. The first to be built, the EPSYS
interface,was createdwith SunViewwhich is
systemsoftwarefor our SUNnetwork.The Ol
andPROPSYSinterfaceswerecreatedwith TAE
Plus softwareobtainedfrom GoddardSpace
Flight Center.
EPSYSis a prototypediagnosticexpertsystem
for monitoringthe electrical power systemof
an autonomous huttle-likespacevehicle. Its
functionis to detectand explainanomaliesand
generateplans to recover from systemfaults.
EPSYS supportsa window- and menu-based
user interface. The user-interfaceis composed
of a basewindow that is subdividedamonga
groupof graphicand text subwindows(Figure
2). Each graphic subwindowrepresentsa
control panel for a physical subsystem. The
control panels are composedof parameter
headingsand a matrix of associatedstatus
lights and trend symbols. A commandbutton
and hierarchicalmenu system were designed
to allow the user to easily communicatewith
the expertsystem. The final componentof the
interfaceis a scrollabletext subwindow. The
function of this window is to organize and
display the textual representationof the high-
level interactionsand conclusionswithin the
expert system,
Our choicesfor the developmentof the EPSYS
interface were SunView and X. We chose
SunViewlargelybecausewe had accessto the
source code of a SunView-basedinterface
which supportedmany of the samefunctional
requirementsthat EPSYS possessed. Also,
SunView is well-documented. At this time,
our in-house version of X had several bugs
and lacked complete and accurate
documentation. In addition, the
documentation we possessed supplied few
examples. Also, our version of TAE Plus, an X
code generator, was an early release and did
not support many of the functions we needed
to implement, The EPSYS interface was
completed in three weeks by two
programmers, including learning the SunView
system.
The second interface we built was for the OI
for inputting orbital parameters and showing
calculational results. We elected to use TAE
Plus for this task. TAE Plus allows the user to
build a graphics interface with a Macintosh
(TM)-like feel by using a graphics workbench
tool with a mouse. It adds a layer of
66
programmingover standardX code,such that
the developeris requiredto havelittle, if any,
X programming knowledge. Once the
developerhas the interface screenor panels
designed, the workbenchtool can generate
code that implements it. Currently, the,
workbenchwill generatecode in the C and
Ada languageswith Fortranand C++ generators
under development.
Approximately one week was spent in
learning how to use TAE Plus and how to
integrate its generated code into an
application. The original OI design was
completed and implementedin tour claysby
one programmer. An additional week was
spent in editing the interface by "tweaking"
the placementof items in a panel. Figure 3
presentsthe prototypeOI mastercontrol panel
and vehiclestatesoutputpanels. The graphics
workspace is the only panel that requires
direct X programming.
Figure 4 shows an overlayed Initialization
panel where the user can select one of ten
rendezvouscases and either accept default
data or modify any of the orbital elements.
This panelrequiredthe most time to complete,
as all work was performedon a SUN 3/50.
TAE Plus was designed to run on a SUN 3/60.
A twenty-four character limitation on display
text length required that the titles on the
rendezvous case selection buttons be created
in halves and dragged to their locations on the
panel.
The Propulsion Expert System (PROPSYS) is
another prototype for a fault management
system. PROPSYS will be a part of a
distributed network of cooperating expert
systems forming the System Monitor for an
autonomous vehicle. It is a rule-based system
written in CLIPS. Its user interface was
developed using TAE Plus and X. The user
interface is composed of a main control panel
which is used to generate subsystem faults
(Figure 5). The subsystem chosen brings up
other panels with menus to enter parameters
necessary for fault generation. After fault
generation is complete, display panels that are
appropriate for monitoring the subsystem
during fault analysis and recovery appear
(Figure 6). A standard X window displays text
provided by the expert system during its
operation. The text provides information on
high-level interactions and conclusions made
by the expert system.
The PROPSYS interface was completed in about
four weeks by two programmers. This
included learning TAE Plus and integrating its
generated code with the application code.
Access to existing TAE Plus code provided
invaluable assistance and reduced our
development time.
ANIMATION GRAPHICS EXPERIENCE
The integration of the AUTOPS Testbed
Prototype with an existing graphics package
was a simple, straight-forward procedure. In
order to connect the prototype to the graphics,
the AUTOPS Testbed Prototype software was
loaded onto a Sun workstation located in the
NASA Interactive Graphics Lab. This Sun
contained Raster Technologies' graphics boards
to provide a graphics engine and was
connected to a high-resolution color monitor.
The modification of code in order that AUTOPS
could be integrated with the graphics was also
a minor procedure that consisted of
customizing three routines and a data file. The
three routines and the data file were copied
from the graphics package into the AUTOPS
simulation code. They were then modified to
fit our requirements. This consisted of picking
the vehicle models that we were using, in this
case, models of the Shuttle Orbiter and the
Orbital Maneuvering Vehicle, choosing
information such as eye-point position,
background models for the stars and the Earth,
lighting, and size of the vehicle models. After
the modifications were completed, the
resulting code was compiled and linked into
the simulation code. The Prototype was then
executed in the same way that it was before
the graphics was integrated into it. The
procedure for integrating the AUTOPS
prototype with the graphics required two
programmers for two days.
Figure 7 shows one of the runs made with this
system. The asterisks show positions of the
orbiter at constant time intervals. Speed is
thus indicated by the separation of successive
indicators. This example illustrates the
triggering of a replan by an expert system
planner in response to an anomaly, in this
case, a loss of general purpose computer
redundancy. Flight rules specify that the
vehicle shall back straight out to a 200 foot
67
range in this event. The graphicsemphasize
and record this behavior.
CONCLUSION
We have found that graphicstools provide a
practicalsolutionto quickly buildingexcellent
interfaces, that the tools are rapidly
improving, and that the time for changesis
growing sufficiently short that timely
modificationsof the interfacesto accomodate
user preferences is now practical. Also,
animatedgraphicscan be easily adaptedto
enhance computational results without
extensivemodification of an application that
doesnot supportsuchcapacity.
_CES
1)
2)
Wang, Lui and Bochsler, Daniel, "Space
Shuttle Onboard Navigation Console
Expert/Trainer System," p. 11, NASA
CONFERENCE PUBLICATION 2491, First
Annual Workshop on Space Operations
Automation and Robotics (SOAR 87),
Houston, TX, August 5-7, 1987.
Beck, Harold,"Application of Technology
to Space Flight Operations," Workshop on
Space Launch Management and
Operations,
ORBITAL SIM
SUBSYSTEM SIMS
NTELUGENT
VEHICLE_
VEHICLE CHARACTERISTICS
VEHICLE CAPABILITIES
CURRENT STATE INFO
ORBITAL SIM
SUBSYSTEM SIMS
INTELLIGENTCONTROLS
VEHICLESENSEIqS
VEHICLE CHARACTERISTICS
VEHICLE CAPABILITIES
CURRENT STATE INFO
ORBITAL SIM
SUBSYSTEM SIMS
INTELLIGENTCONTROLS
VEHICLE CAPABIL1
CURRENT STATE I_
MONITORING DATA
"GROUND TRUTH"
TV, RADAR SENSOR DATA
PLUME IMPINC-_MENTAND
TETHER CORRELATIONS
MISSION DIRECTOR
MISSION MONITOR
GPS PI.N'_ER
SYSTEM MONITOR
Figure 1. AUTOPS architecture
68
O2
)4.q.)_ I FOLD
STJsTU$
ORIGINAL PAGE IS
OF POOR QUALITY
LSC ZAC 3A|
++m+M+STATUS
Figure 2 EPSYS User Interface
Sin Time N:HII..m:_
DlmS_ Stl;;(
X _O0(.X
Z IO0_O(.X
x-bl. _O_X,X
ll,mmlr lr l,lr,S_ m.x
_ETF.CTO m'4_Im_l ES:
tllmt.Pe0el_lr) lie, nine: Cln'c lodwp :
,lo_2 1_0 11_ 219 101pto_. 160 _I_ 219 1
_t(t.ll_.pl,m,+_) C+m't r,llSllt._
X-got m_olx.x ]OC_I.X
Y-Dot. )l_(.x _.x
Z-Dot )coolx.x _(.X
P+cl._t -mm_ m_ooc<.x
S_m r_m B:H_:m:S_
r_ S'rA_[
X mO_(.X
T m_C_C.X
Z _t.X
_loL _XX_.X
1_4rl_.r ro-o.*m- ]O_.X
pl l,oh V4v _ll
Figure 3 AUTOPS Operator Interface
69
= _P,¢,,+
_I_ _!+_';_ _._r_ _
L-M W.A
Figure 4 AUTOPS Initialization Interface
1 2
Figure 5 PROPSYS Main Control Panel
$
7O
ORIG!NAL PAGE IS
OF POOR QU_'4LITY
Figure 6 PROPSYS Fault Monitoring Panel
Figure 7 AUTOPS Animation Graphics Output
71

DESTINATION MARS
Mike Remus
Morton Thiokol, Inc.
(Paper not provided by publication date.)
73
PRECEDING PAGE 13LArC,( l";T F:LF.,-_ _ "7,__ RI_N_



Applications of graphics to support a testbed for autonomous space vehicle operations

Applications of graphics to support a testbed for autonomous space vehicle operations

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server