NASA Technical Memorandum 104242

From an Automated Flight-TestManagement System to a Flight-TestEngineer's Workstation

E. L. Duke, R. W. Brumbaugh, M. D. Hewett, and D. M. Tartt

(t_A£A-T*_-104242) FROM AN AUTOMATFO N91-32_51F[ IGHT-TtST HANAG6MENT SYSTEM TO A

FtIGHT-TL_T ENGINFER,S WORKSTATION (NASA)I.6 D

CSCL 09_ Unclast- -0045 7., jG3/o2

-" October 1991

NASANational Aeronautics and

Space Administration

i

NASA Technical Memorandum 104242

From an Automated Flight-TestManagement System to a Flight-TestEngineer's Workstation

E. L. DukeNASA Dryden Flight Research Facility, Edwards, California

R. W. BrumbaughPRC Inc., Edwards, California

M. D. Hewett and D. M. TarttG & C Systems Inc., San Juan Capistrano, California

v

1991

N/_.S/_National Aeronautics andSpace Administration

Dryden Flight Research FacilityEdwards, California 93523-0273

29-I

From an Automated Flight-Test Management System to a Flight-Test

Engineer's Workstation

E.L. Duke

R.W. Brumbaugh*M.D. HeweR**D.M. Tartt**

NASA Dryden Flight Rose.arch FacilityP.O. Box 273

Edwards, California 93523-0273

1 SUMMARY

This paper describes the capabilities and evolution ofa flight-test engineer's workstation (called TEST_PLAN)from an automated flight-test management system. The

concept and capabilities of the automated Right-test man-agement system ate explored and discussed to illustratethe value of advanced system prototyping and evolution-ary soRware development.

2 NOMENCLATURE

ART

ATMS

dof

FIE

GUI

HARV

RDBMS

TACT

automated reasoning tool

automated flight-test management system

degree of freedom

flight-test engineex

flight-test trajectory controller

flight-test trajectory guidance

graphical user interface

High Alpha Research Vehicle

relational database management system

tacticalaircrafttechnology

3 INTRODUCTION

This paper describes the development and capabilities eraflight-test engineer's workstation called TEST.PLAN andits evolution from the automated flight-test managementsystem (ARMS). The ARMS was a tool for flight-testplanning and scheduling it contained expert systems formaneuver ordering, range management, and maneuver re-quirements evaluation. These expert systems were com-b/ned with three and six-degree-of-freedom simulations,

state-of-the-art trajectory optimization, and a powerfulgraphic user interface to provide a desk top workstation.

"PRC Inc., Edwards, C.al/fomia

"*G&C Systems tar., San Juan Capistrano, Califonfia

TEST.PLAN is a computer program designed to run onstandard graphics workstations as an aid to flight-test en-gineers (VrEs) in planning and executing flight-test pro-grams. TEST_PLAN allows the FIE to organize and fileextensive amounts of planning data while satisfying plan-ning requiremems on a Right-by-Right basis using air.craftandflight-specificinformationaboutinstrumentation,

telemetry,range,center-of-gravity,airborneand ground

support,aerodynamicconfiguration,systemconfiguration,

and payload.

TEST.PLAN is the result of several generations of evo-lution. Originally combined with a maneuver autopilot,the first version of the ARMS was designed for flight-test maneuver planning and scheduling as well as ma-neuver execution and real-time flight-test monitoring; thisfirst version of the ATMS was demonstratedin October

1987 using the NASA simulation facility at the DrydenFlight Research Facility. A second workstation version ofATMS evolved from lessons learned from the preliminaryversion_this second version eliminated the maneuver au-

topilot concept but retained a real-time flight monitoringcapability; version two of the ATMS was demonstrated inmid-1990 at NASA using the F-18 High Alpha ResearchVehicle (HARV) flight-test plans. A third commercial vex-sion of ATMS (called TEST.PLAN)resulted from the ear-tier experience and is designed as a FTE aid in planningand executing flight-test programs; TEST.PLAN is cur-rently being used or considered for use by United Statesand international flight-test organizations.

4 THE AUTOMATED FLIGHT.TF_ST MANAGE-lVIENT SYSTEM

The ATMS was originally developed at the NASA Dry-den Flight Research Facility as a part of the NASA Air-craft Automation Program-a programfocused on apply-ing interdisciplinary state-of-the-art technology in artificialintelligence, controltheory,and systems methodology toproblems of operating and flight testing high-performanceaircraft. In this section we present the background and adescription of the ArMS [1.2,3].

29-2

4.1 Background of the Automated Flight-TestManagement System

The ATMS was an outgrowth of the flight-test trajectoryguidance (FT'I'G)work performed over the past decade onsuch programs as the F-111 Tactical Aircraft Technology(TACT) Program, the F-15 Propulsion/Airframe Integra-tion Program, and the 1=-15 l(P-Cone Program [4]. TheFTTG provided display information to the pilot to allowcomplex, demanding flight research maneuvers to be flownmote accurately. The FTI'G was extended to a closed-loop system for the Highly Maneuverable Aircraft Tech-nology (HiIviAT) Program flight-test maneuver autopilot(FI_) [5]. In conjunction with this flight research atDryden, Integrated Systems, Inc., under contract to NASAhas developed a design methodology for these types ofcontrollers [6,7,8] which has resulted in the basis of a

flight-test trajectory controller (FTTC) which was flighttested in early 1990 on the F-15 Highly Integrated DigitalElectronic Control (HIDEC) aircraft [9]. This FTTC wasa major component of the ATIVISas originally conceivedand implemented.

The ATMS project was structured around a flight-testscenario and was an extension of work performed bySPARTA, Inc., (SPARTA, Inc., Laguna Hills, CA) un-der contract to NASA defining the need for a Na-tional Remote Computational Flight Research Facility(NRCFRF). The work on the NRCFRF contract defined

the need for an expanded remotely augmented vehi-cle (RAV) capability and a flight program to demon-strate that capability. In the ATMS, a range, en-ergy, and flight-test monitor expert system was usedin conjunction with the FrTC to order maneuversby priorities and energy management considerations

while restricting the vehicle to the confines of a specifiedEdwards AFB test range. This expert system could be usedonline to control the rese_ch aircraft in flight and monitorthe progress of a flight test; or offiine as a planning tool forordering the test maneuvers for a flighL The expert systemused predictions of maneuvers based on simulation modelsfor planning and actual flight-test data measurements forreal-time vehicle control, data monitonng and flight testmanagement.

4.2 Components of the Automated Flight-TestManagement System

The main components of the ArMS were a trajectory con-troller based on the FTTC system [7,8], a flight-test plan-ning expert system, a man-machine interface, and a flight-test monitoring expert system. The partitioning of func-tions in the ATIVISwas designed with two goals in mind;minimizing the bandwidth of the communication betweencomponents, and appropriate distribution of functions be-tween numeric and symbolic processing.

The components described in this section perform the flightplanning and monitoring functions. The fully developedATMS ('Fig. 1) was expected to perform program plan-ning, block planning, and in-flight replanning which arenot described herein as they were never implemented inthe first ATMS.

4.2.1 Trajectory Controller

The trajectory controller was a collection of outer-loopguidance control laws which provide precise control for a

Preflightplanningfunctions

Programplanning

Blockplanning

* 1FIIgM

planning I I

Infllght monitoring, controlling, and replannlng functions

_'_I _ InflightController replanning I

[ Ior--i

9tilde

Fig. 1 ATMS functions.

29-3

vehicle performing high-quality frightresearch maneuverssuch as level accelerations, wind-up turns, and pushover-pullup maneuvers. The trajectory controller was algorith-mic, implemented in FORTRAN 77, and executed on anumeric processor.

The interface between the trajectory controller and the re-maining components of the ATMS was designed to min-imize the bandwidth of the communications across that

interface. The trajectory controller accepted input com-mands consisting of an ordered list of maneuvers by type.Each maneuver consisted of a trim poinL maneuver con-ditioas, and end conditions. These commands contained

from three to seven parameters each.

Once maneuver commands were received by the trajec-tory controller, the controller operated independently of theATMS until another command list was received. The tra-

jectory controller generated trajectories and trajectory fol-lowing controls based on the maneuver commands and theaircraft instrumentation.

4.2.2 Flight.Test Planning Expert System

Flight-test planning must be done at several levels. At the

highest level, the flights required for an entire program areestablished by the project requirements. At the next level,blocks of flights are determined by a more detailed analy-sis of the project requirements and are partitioned accord-ing to similarity of prerequisites, flight envelope require-ments, and test needs to establish an orderly progression ofblocks of flights satisfying the high-level project require-meats. Within each block a number of individual flights areidentified based on the detailed analysis of maneuvers re-quired to satisfy the block requirements. Individual flightsare then identified with a number of these maneuvers and

the FIE must order maneuvers within a flight based onconsiderations of range, fuel, and energy management, aswell as maneuver priorities.

The ATMS implemented only the test planner expert sys-tem. The test planner accepted a list of maneuvers and or-dered them using rules that considered maneuver priorities,energy management, test range boundaries, and envelopelimitations. Maneuvers which could not be included in the

flight plan were eliminated from the plan being developed.

The flight-test planning expert system accepted test planinputs from the FTE using a menu driven and icon based

man-machine interface or previously stored test plan en-tries. When the list of test maneuvers was entered into

the ATMS, the FTE selected the flight-test planning expertsystem which then used its knowledge base to order ma-neuvers, prioritize maneuvers, and construct a trajectory.As each maneuver was added to the planned trajectory, itwas tested to insure that no system constraints had been

violated. When constraint violations occurred, the flight-test planning expert system displayed information to theFTE describing the constraint violations and provided anexplanation of the constraint, if requested. Maneuver pri-ority was extremely important when fuel constraints were

tested; lower priority maneuvers were removed from thetest plan to satisfy fuel constraints.

The flight-test planning expert system was developed usingthe Automated Reasoning Tool (ART) expert system de-velopment environment hosted on a symbolic computerwith a numeric processor board. It contained over200 rules.

4.2.3 Man-Machine Interface

The man-machine interface component of the ATMS pro-vided a means of information entry and display. This in-tefface was used during flight planning and flight plan exe-cution. The main display had three major components: themap, timeline, and command menu. In the map section ofthe main display were two types of displays: the trajectoryplanningdisplay(Fig.2), and thetrajectory map display(Fig.3).Thesemap displayspresentedatwo-dimensional

view of the test range with the aircraft trajectory superim-posed. The stored map was larger than the portion pre-sented on the display.Pan and scroll were accomplishedby usingthe mouse to choosean appropriate button de-

pictedacross the top of the display. A"navigate" buttonwas also includedtoquicklydetermine courseanddistancebetween present aircraft position and any point within thestored map. The timefine component of the main displaypresented information on the aircraft trajectory in terms ofaltitude as a function of timeorevents. Figure 4 shows atimeline display of altitude as a function of time. Timelinescroll buttons allowed the FIE to examine different time or

event segments by scrolling the timeiine. The commandmenu portion of the main display allowed the user to se-leet (using "mouse" or keyboard inputs) ATMS operationalmodes, maneuvers, or explanations of ATMS actions.

The man-machine interface was rule based with over

200 rules and presented on the computer monitor andkey-board. The interface was developed in ART.

4.2.4 Flight.Test Monitor Expert System

The flight-test monitor expert system provided an inter-face between the FTE and either the planned trajectoryortheactualtrajectory(whethergeneratedby simulation

orflight),Thissystemalsoprovidedthetrajectorycon-troller with inputs from the list of maneuvers in the planned

trajectory.

The flight-test monitor expert system issued maneuverrequests to the trajectory controller, then monitored the air-craft parameters of interest to insure that no system con-straints were violated. This system also monitored ma-neuver quality. When a system constraint was violated orthe quality of a maneuver was tmacceptable, the flight-test

monitor expert system notified the FIE of the problem andmade recommendations based on the information within

its knowledge base. Each maneuver was selected from thelist of planned maneuvers in order; the flight-test monitor

29-4

AIt 30HDG 090Mach 0.8

Entryconditions

Exit

conditions `

AIt30 KHDG 270Mach 0.7

,j (Top/bottom In K ff of range segments) _ N t

I Event4 I I I

y speed-power ] V, "c'_U_e_O_._l/_m) a in_t)N_ I

(Maneuver)

\ I !

Maint 30 K Event 5Maint 270 wind-up tumDecel to 0.7

910_3I

Fig. 2 Trajectory planning display.

Air 3OHDG 090Mach 0.8

Entryconditions

Exitconditions

Air 30 KHDG 270Mach 0.7

k/flop/bottom In K ft of range segments) "_.d90 r

10

Event 4 Jspeed-power

(Maneuver)

(Transition segment)

Maint 30 KMaint 270Decel to 0.7

%

tI

/J

Event 5 1wind-up turn

Fig. 3 Trajectory map display.

910_3..

expert system initiated these maneuvers and then waitedfor the trajectory controller to finish a maneuver before

proceeding to the next maneuver on the list.

4.3 Automated Flight-Test Management SystemConfigurations

on ati : the workstation,

were used to develop and evaluate flight-test plans. Thesimulation validation system Was also used to aid in thevalidation of the flight system including aircraft m_fica-tions. The flight system was used to actually conduct flighttest by executing the flight-test plan, monitoring the perfo¢-mance of the aireraR, and controlling the aircraft in flight.

4.3,i Flight-Test Engineer's Workstation

the simulation vaiidati0a system, and the flight system.The FTE workstation and the simulatioa validation system The configurations of the FTE workstation is shown in

Figure 5. This system was used by the FTE to develop

29-5

Altitudexl0 3

50

4O

3O

20

10

0

Altitude versus time

/ Event4 [ ' Event5 [ _ j I

-- speed-power I I wind-up turn / t_lnt 30JClimb to 32 1 \ .a].t 270 I JutsoI Turn to 270 I \ Decel to 0.7 J HDG 270IAccelto0.9| ..: Mach0.7

0:30 5:00 7:00 7:30 10:00Time

910030

Fig. 4 "13melinedisplay.

preliminary flight-test planswithouthavingto use the air-craft simulator. This provided the FTE with a stand-=donesystemthatwasseparatedfrom the aircraftsimulator,whichwasalwaysin greatdemand,andthus allowedmoreflexibility in test plan development.

The FIE workstation included two computers; a symbolic

computer with a numeric processor board and a graphicsworkstation. The LISP processor on the computer con-tained the flight-test planning expert system, the man-machine interface system, and the rule-based portion of theflight-test monitoring expert system. The numeric proces-sor on the symbolic computer contained a three dngree-of-freedom (3 dot')digital performance simulation (DPS) andthe software to execute the algorithmic, trajectory manage-ment portion of the flight-test management expert system.The LISP processor andnumericprocessor boardcommu-nicated using an intemai bus. The graphics workstationcontainedasix degree-of-freedom(6 dot')simulationof theaircraftand theFTTC. The two computerscommunicatedusingEthernetwith a standardprotocol.

4.3.2 Simulation Validation System

The configuration of the simulation validation system isshown in Figure 6. This system was used by the FIE toevaluate flight plans developed on the FIE workstationto provide detailed pilot-in-the-loop mission briefing andfamiliarization, and as a validation facility for testing theATMS as well as the ground and =drcraft systems to be usedin the actual flight testing.

The simulation validation configuration of the ATMS in-cluded three computers;the symboliccomputerand twore=d-timemini computers. The computerin the simula-tion validation system was configured identically to the

FTE workstation configuration of this processor. One minicomputer (designated the "control law computer") con-rained the trajectory controller software and communicatedwith the symbolic computer using a standard protocol. Thecommunication between this mini computer and the sym-bolic computer was identical to the communication be-tween the computer and the graphics workstation in theFTE workstation configuration. The other mini computercontained a detailed 6 dof simulation of the aircraft and

also contained detailed models of the downiink and uplinktelemetry system. The two mini computers communicatedin engineering units through FORTRAN named commonblocks using a two-port shared memory.

4.3.3 Flight System

The configuration of the ATMS flight system is shown inFigure 7. The flight system was to be used to conduct flighttest by executing the flight test plan, monitoring the perfor-mance of the aircraft, and controlling the aircraft in flight.

The flight system configuration of the ATMS includedthree computers; a symbolic computer and two mini com-puters. The computer in the flight system was configuredidentically to the FTE workstation and simulation valida-tion system configurations of this computer. One mini con-trol law computer contained the trajectory controller soft-ware and communicated with the computer using a stan-dard protocol. The communication between the controllaw computer and the smailet computer was identical tothe communication between the smaller computer and thecontrol law computer in the simulation validation systemconfiguration. A second mini computer (designated the=engineering units computer") was included in the flightsystem and provided processing required for the uplink anddowniink telemetry systems. The communication between

29-6

_Knowledge englneerlngprogramming

t DisI: lays User Inputs

Expert system , • _ Trajectory ,,

m-m Intlrfaces Man / manager,,machine / I c°nstralnt I

Expert Interface / ! checker I _3d°f,I system s T

I Planner I -- "I Displays [ Executive

,I M°nlt°r I <_J _arC_e I _ 1680 JTraJsctory_data files

• USP processor/Symbolic computer

Trslectorygenerator

4Ethemet

Interface6 dof software

Right-test trajectorycontroller

I Maneuverfile II C°mmandgenerator I

_,Graphlce workstation

Fig. 5 FTE workstation configuration.

910_t0

the two mini computerswasidentical to the commtmlca- _ _tion between the two mini computers in the simulation val-idation configuration. In the flight system, the simulation systems concepts [2,10]. This rapidprot0typing facility

was intended to allow easy transition from concept to sire-mode] of the aircraft and telemetery systems were to be ........ulation then to flight. Not only was ATMS _ systemreplaced with_ systems. ........... to be used |n this facility, it was the first system to benefit

from the capabilities provided by =_flds]_acl_llty..... i_'_$ THE EVOLUTION OF TEST_PLAN FROM THE ...........

AUTOMATED FLIGHT-TEST MANAGEMENT As oflginally conceived, ATMSwastohavecombiaedsev-

SYSTEM

The first version of the ATMS was used to develop therapid prototyping facility for flight research in advanced

era] concepts into a single system that would allow plan-ning, simulation, execution, and monitoring of researchtest flights. But this was lmachievable for sever_ r_sons.

The most apparent problem was the inadequaciesof thesymbolic processor s and the expert system developmentlanguage when appH_ to real-time tad¢_. Without this

29-7

programmingI

Expert systemm-m Interfaces

Expertsystems

-_. J Planner

Monitor

Disl:lays User Inputs

Man

machineInterface

._ Displays I

-, _ Trajectorymanager

i I I Isoftware software data files

USP proceuor _ _ 68020Symbolic computer

Ethamet

Tralectorycontroller

__ Interface

software

Flight-test tralectorycontroller

i..o u .rIIoomo.n.generator I

Real-time minicontrol law computer

Fig. 6 Simulation validation system configuration.

Shared Imemory

l f___Slmulation., N

6 dot real-time IITI simulation _ _I Real-time |

mini computer J

910_41

facility these problems might not have been detected untilmuch later in the development program.

The problem of computers and expert system developmentlanguages was addressed by re-implementing the expertsystems using CLIPS ('C' Language Production System),converting from LISP to 'C,' using X-windows for thegraphical user interface, and re-hosting the system on stan-dard numeric workstations.

Finally, experience in the rapidpro_otyping showed the dif-ficulties inherent in a system as ambititious as ATMS. In-stead of a tingle system to manage all aspects of pianning,

simulation, execution, and monitoring, we decided to de-velop several separate but compatible systems. Thus, therapid prototyping facility allowed realistic decisions to bemade about the viabRity of the ATMS concept.

TEST.PLAN is the result of the decision to expand the por-

tion of ATMS that provided the FTE with a planning tool.This system, while the development was under governmentauspices, was called the "flight test engineer's worksta-tion" [3] and TEST_PLAN when extended and commer-

cialized by G & C Systems Inc. (G & C Systems Inc., SanJuan Capistrano,CA).

29-8

_nowledge engineering

programming Dis| lays User Inputs I

J_ ! Tr "---I/"-- Expert system _ -, _ alectory •I / m-m Interfaces T manager

I/ I .,nI/ I machine [ Constraint I , ,Ill Expert I I Interface I checker I ! 3 do, I

II I systems I --_ Displays J " _ ' ' _ "

q_ll _'.o.- II !/Hi Monitor I I -- _ interfa_=ce-_'_ra_jTrajectoryII i I I ! I_n_t_a rC_e software data files

[ LISPp rOcessOr _ A ' 68020

Trajectorycontroller

Interfacesoftware

Flight-test trajectorycontroller

i

generator I

Real-time minicontrol law computer

CMD• upllnkTape

storage

Fig.7 Flightsystemconfiguration.

I Telemetrydownlink

monitor

Engineering units ]conversion

Real-time miniengineering units

computer

I10e42

6 TEST.PLAN

TEST_PLAN isa computerprogramdesignedtorunon

standardgraphicsworkstations(undereithertheUNIX ®

orVMS operatingsystems)asan aidtoFTEs inplanningandexecutingfright-testprograms.TEST..PLAN allows

the FIE to organize and file extensive amounts of planningdata while satisfying planning requirements on a flight-by-flight basis using aircraft and flight specific information

(_ UNIX iSa w._ Ixademaxk of AT & T BeJ]Lalxxalodes, Whip

ple),,New kc_cy.

about instrumentation, telemetry, range,center-of-gravity.airborne and ground support,aerodynamic configuration,system configuration, and payload.

6.1 TEST_PLAN Components

The primarycomponentsof TEST..PLAN (shown inFig.8)include:

I.A planningfacilitywithoverI000fright-testplan-

ningprocedures,

29-9

Automated test planner

FRInterlace

Fig. 8 TEST.PLAN system architecture.

.__ Flight Ireports [

ASCII files I

Right

reportsformat

database(Oracle)

01004,1

2. an extensive graphical user interface (GUI),

3. an interface with a relational database managementsystem (RDBMS),

4. an alrcrat_ performance simulation facility,

5. a flight card generation facility, and

6. expert system based planning aids.

In the following sections, we will discussthese compo-nentsof TEST.PLAN.

6.1.1 Planning Facility

The heartof TEST.PLAN [II]isa planningfacility

consistingof a planningmatrixand over I000 plan-

ning procedures. The planningmatrixconsistsof

flight-test maneuvers and contingency maneuvers orga-nized by flights for each individual aircraft in a flight-testprogram. The planning matrix Is displayed tn an easy touse format (Fig. 9).

The automated planning procedures allow the FIE toplan flight-test programs by defining maneuvers and fill-ing out the planning matrix. The basic philosophy imple-mented in the TEST.PLAN planning facility (Fig. 10) fea-tttres the creation of a centralized database of test pointsin an RDBMS which must be satisfied in the flight-testprogram; the creation of multiple flight-test plans con-sisting of test points assignedto flight-test maneuvers,flight-test maneuvers assigned to flights, and flights as-signed to blocks of flights for specific flight-test aircrat_;and continuous,automatedconstraintcheckingbetween

test points, maneuvers, and flights for test point require-ments and flight assignments on a flight-by-flight basis.

29-10

Maneuvers1 2 3 4 5 6 7 8

NNI

i i limid

_momoll

Maneuvers

1 2 34567 8

ill iiIII ,

::':"

Maneuvers1 2

i

3 4 5 6

Contlngencles

m

Contingencies

Ingencles

Fig. 9 Planning matrix display.

6.1.2 Graphical User Interface

TEST.PLAN uses graphics extensively. One of itsmost visible features Is a highly developed GUI usingX-windows. This interface consists of windows, pan-

els, canvasses, action buttons, and menus. Maximumuse of is made of mouse initiated operations. The inter-

face permits the FIE to execute procedures in any orderdesired---the FTEis not limited to the serial, predefined or-

der of events typically found in a menu-driven application.

IWindup,urn JIStabmty

I Low priority20K - 0.71_

I- -EiE! IEo'I91O044

Using the TEST_PLAN GUI, the flight-test engineer canperform many tasks which would normally require exten-sive paper and pencil work. These automated tasks in-elude laying out planning matrices, planning blocks offlights, defining test points, defining flight-test maneuvers,assigning test points to flight-test maneuvers, sequencingllight-test maneuvers to minimize fuel and time required,writing flight cards, and satisfying test point constraints.These test points constraints may be based on instrumen-tation, aircraft configuration, range (operating area) re-

quirements, telemetry requirements, system configuration,

29-11

Test pointdatabase

I_:_i_,_: ::./-:_:;::_::_'>:,'::_:::.>_-_| )2:_: ::i::.:*;:__.>-_>:_:i'_:'::_:'_::__ _._.>-_'i-'_:__

Flight.test planning

,..-.:_':.:.:.:.::. _::<.---:-:-:.:_:_-:._,/:_._ :. w .,.x_ "::;-:::::::

Planfiles

Fig.I0 The TF,,ST..PI.,A_planningphilosophy.

910_,15

air and ground support requirements, payload, weight andbalance requirements, flight limits, trim point conditions,or test point prerequisites.

6.1.3 Relational Database Management System

TEST.PLAN is functionally integrated with the Oracle Re-lational Database Management System (RDBMS). TheRDBMS contains a database of test points for a flight-test program. TEST.PLAN incorporates many procedureswhich greatly simplify database queries, record additions,modifications and deletions. No special knowledge of thedatabase query language Is requited because TEST.PLANprovides the user a set of menus, action buttons, and dataentry fields as part of the GUI.

6.1.4 Airtraft Performance Simulation

TEST.PLAN contains a 3 dof generic aircraftperformancesimulation. This simulation requites the user to define anaerodynamic model (of lil_ and drag coefficients as func-tions of Mach number and angle of attack) and a propul-sion system model (of thrust and fuel flow as functions ofaltitude and power lever angle).

Using the simulation and this simple definition of the vehi-cle, TEST.PLAN can compute the trajectory and fuel usedin any of 52 preprogrammed maneuvers such as climbs, de-scents, level accelerations and decelerations, cruise, turns,and dynamic maneuvers. The flight-test engineer also hasthe capability of building new maneuvers by stringing to-gether combinations of individual maneuvers.

6.1.5 Flight Card Generation Facility

TEST.PLAN provides a flight card generation facilitywhich uses default entries from the flight card database togenerate a set of flight cards for a specific flight. The nom-inal flight card is shown in Figure 11. However, the formatcan be customized to any desired during the customizationportion of an installation of TEST.PLAN.

6.1,6 Expert System Based Planning Aids

TEST.PLAN contains two expert system planning aids;a flight planner and a block planner. The block plannerassigns maneuvers (which contain test points) to flights,attempting to minimize the number of flights required toexecute the maneuvers within the block while satisfyingconstraints on instrumentation, configuration, flight lim-its, flight conditions, prerequisite test points, and range re-quirements. The flight planner reorders maneuvers withinindividual flights attempting to satisfy constraints whileminimizing fuel and range time used; the flight planneruses fuel and time data obtained from trajectories gener-

ated in the perfommace simulation. An explanation facil-ity is provided.

7 CONCLUDING REMARKS

This report des_bes the automated flight-test manage-ment system and an automated flight test planning sys-tem called TEST.PLAN. The evolution of TEST_PLAN

from automated flight-test management system is detailedto illustrate the use of rapid prototyping to define systemrequirements.

29-12

Pos PM Exp

m

2

AIt/Mach

m

4

w

5

1 1 KE .2 1 --

3 2 KE

QB

6 3 PM

7 4 KE

9 5 KF

m

8

10 6 PM

.2 1450 ->0.8

30 ) 0.8

SN145238

Flight Number

FQ - 001

START UP, TM CHK (238.2)TAXl (320.2)MIL TO (257.6) ! MIL CLRotate at 175 to theta = 10

MIL Climb to 30MC (310.2)

WUT to Nz = 6.00.5 g/sec

30 / 0.8 ITB

30 / 0.9 ITB

30 / 0.7 DESCENT to 100.7 M to 300ITB every 5K

10 / 300 ITB

10/300 GEAR DN / 1/2 FLAPSYANKEE PATTERNAPPROACHES

10 / 250 DESCENT to PatternILS

1.2 / 150 TOUCH & GOS to LandingFuelAero breaking to nose fall-throughMax breaking with nose on RWY

Fig. 11 Nominal flight card format.

Dl00_mb

8 REFERENCES

[1] HewetL Marle D., David M. TartL Eugene L. Duke,Robert E Antoniewicz, and Randal W. Brumbaugh,"The Development of an Automated Flight Test Man-agement System for Flight Test Planning and Moni-toting," Proceedings of the First International Con-ference on Industrial and Engineering Applicationsof Artificial Intelligence and Expert Systems, Tulla-homa, TN, June 1-3, 1988, Vol. 1, University often-nessee, 1988, pp. 324-333.

[2] Duke, Eugene L., MarleD. HeweR, Randal W. Brum-baugh, David D. TartL Robert E Antoniewicz, and

Arvind K. Agarwal, "The Use of an Automated FlightTest Management System in the Development ofa Rapid-Prototyping Flight Research Facility," 4thConference on Artificial Intelligence Applications,Long Beach, CA, May 4-6, 1988. (See also NASATM-100435, 1988.)

[3] TarR, David D., Marie D. HeweR, Eugene L. Duke,James A. Cooper, and Randal W. Brumbaugh, "TheDevelopment of a Flight Test Engineer's Workstationfor the Automated Flight Test Management System,"Proceedings of the Societyof Flight Test Engineers,20th Annual Symposium, Reno, NV, Sept. 18-21,i989, pp. 5.2-1 to 52.-12.

29-13

[4] Duke, Eugene L., Michael R. Swarm, Einat K.

Enevoldson, and Thomas D. Wolf, "Experience with

Flight Test TrajectoryGuidance," J. Guidance, Con-trol and Dynamics, Vol. 6, No. 5, 1983, pp. 393-398.

[5] Duke, Eugene L., Frank E Jones, and Ralph B. Ron-

co]J, Development and Flight Test of an ExperimentalManeuver Autopilot for a Highly Maneuverable Air-craft, NASA TP-2618, 1986.

[6] Walker, Robert and Naten Gupta, "Flight Test Trajec-

tory Control Analysis," NASA CR-170935, 1983.

[7] Meuon, P.K.A. and R.A. Walker, "Aircraft Flight Test

Trajectory Control," ISI Report No. 56, Integrated

Systems, Inc., Santa Clara, CA, Oct. 1985. (See also

NASA CR-179428, 1988.)

[8] Menon, P.K.A., M.E. BadgeR, and R.A. Walker,

"Nonlinear Maneuver Autopilot for the F-15 Air-

craft," ISI Report No. 71, Integrated Systems, Inc.,Santa Clara, CA, Dec. 1985.

[9] Antoniewicz, Robert F., Eugene L. Duke, and P.K.A.

Menon, "Flight Test of a Trajectory Controllcr Us-ing Lincarizing Transforms With Measurement Feed-back," AIAA Guidance, Navigation and Control

Conference, Part I, Portland, OR, AIAA 90-3373,

Aug. 1990, pp. 518-532.

[10] Duke, Eugene L., Randal W. Brumbaugh, andJames D. Disbrow, "A Rapid Prototyping Facility

for Flight Research in Advanced Systems Concepts,"Computer, May 1989, pp. 61--456.

[ 11] Automated Flight Test Planning System: TEST.PIAN

User's Gu/de, G & C Systems, Inc., 30250 Rancho

Viejo Road, San Juan Capisttano, CA 92675, 1991.

Form Approved

REPORT DOCUMENTATION PAGE No.o7o4 i=,Public reportingb_rden for thiscollection of informationb estimated to average 1 hourper response, Inctud|ngthe time for reviewtnglnstruC.t,ions, parching exhr,t_ngdata sou_t_s-,gatheringand maintainingthe data needed, and completingand reviewing the collectionof information. Send comments regardingthis ouroon estimate or anyDiner asps= o ; mcollection of irfformation, ]ndudlng eugpstior4 for reducingthis burden, to WashingtonFioedquartersServioas Dlroctor.'o|or information Operationsand Reports,1215 JeffersonDIwIQ Highway,Sub 1204, Arlington,VA22202..4302, andto the Office of Management led Budget, Paporwo_ ReductionPro oct (0704-0188), Washington, OC 20503.

1. AGENCY USE ONLY (LeaW blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED

October 1991 Technical Memorandum

4. TITLE AND SUBTITLE 5. FUNDING NUMBERS

From an Automated Flight-Test Management System to a Right-Test

Engineer's Workstation

6. AUTHOR(S)

E. L. Duke, R. W. Brumbaugh, M. D. Hewett, and D. M. Tartt

7. PERFORMINGORGANIZATIONNAME(S)ANDADDRESS(EB)

NASA Dryden Flight Research FacilityP.O. Box 273

Edwards, California 93523-0273

9. SPONSORING/MONITORINGAGENCYNAME(S)ANDADDRESS(ES)

National Aeronautics and Space Administration

Washington, DC 20546-3191

iii

11. SUPPLEMENTARY NOTES

8. PERFORMING ORGANIZATIONREPORT NUMBER

H-1761

10. SPONSORING/MONITORINGAGENCY REPORT NUMBER

Prepared as AGARD paper #29, Guidance and Control Panel 53rd Symposium, Air Vehicle Mission Control andManagement, Oct. 22-26, 1991, Amsterdam, The Netherlands

12a. DISTRIBU'TIONIAVAILABILITY STATEMENT 12b. DISTRIBUTION CODE

Subject category 62

13. ABSTRACT (Maximum 200 words)

This paperdescribes the capabilities and evolution of a flight-test engineer's workstation (called TEST_PLAN) from

an automated tlight-test management system. The concept and capabilities of the automated flight-test management

system am explored and discussed to illustrate the value of advanced system prototyping and evolutionary software

development.

14. SUBJECT TERMS

Automatic planning; Expert systems; Flight test; Workstation

17. SECURITYCLASSIFICATION18. SECURITYCLASSIFICATIONoF REPORT OFTHiSPAGeUnclassified Unclassified

NSN7540-01-280-5500

19. SECURITY CLASSIFICATION

OF ABSTRACT

Unclassified

lS. NUMBER OF PAGES

1616. PRICE CODE

A0220. LIMITATION OF ABSTRAC'T

Unlimited

Standard Form 298 (Rev. 2-89)Pree4:rlbed by ANe| Bid. ZJG-I 8

298-102

Ir

t