conduit—a new multidisciplinary integration...

1American Institute of Aeronautics and Astronautics

CONDUIT—A NEW MULTIDISCIPLINARY INTEGRATION ENVIRONMENTFOR FLIGHT CONTROL DEVELOPMENT

Mark B. TischlerU.S. Army Aeroflightdynamics Directorate

Aviation Research, Development and Engineering Center, ATCOMAmes Research Center

Moffett Field, California

Jason D. Colbourne, Mark R. Morel, and Daniel J. BiezadDepartment of Aeronautical EngineeringCalifornia Polytechnic State University

San Luis Obispo, California

William S. Levine and Veronica MoldoveanuDepartment of Electrical Engineering

University of MarylandCollege Park, Maryland

Abstract*

A state-of-the-art computational facility for aircraftflight control design, evaluation, and integration calledCONDUIT (Control Designer’s Unified Interface) hasbeen developed. This paper describes the CONDUITtool and case study applications to complex rotary- andfixed-wing fly-by-wire flight control problems. Controlsystem analysis and design optimization methods arepresented, including definition of design specificationsand system models within CONDUIT, and the multi-objective function optimization (CONSOL-OPTCAD)used to tune the selected design parameters. Designexamples are based on flight test programs for whichextensive data are available for validation. CONDUITis used to analyze baseline control laws againstpertinent military handling qualities and control systemspecifications. In both case studies, CONDUITsuccessfully exploits trade-offs between forward loopand feedback dynamics to significantly improve theexpected handling qualities and minimize the requiredactuator authority. The CONDUIT system provides anew environment for integrated control system analysisand design, and has potential for significantly reducingthe time and cost of control system flight testoptimization.

*Copyright 1997 by the American Institute of Aeronauticsand Astronautics, Inc. No copyright is asserted in the UnitedStates under Title 17, U.S. Code. The U.S. Government has aroyalty-free license to exercise all rights under the copyrightclaimed herein for Governmental purposes. All other rightsare reserved by the copyright owner.

Introduction

The design, integration, and flight test developmentof flight control systems for modern fixed- and rotary-wing aircraft presents a challenging multidisciplinarytask that factors significantly in the overall time andcost of aircraft development.1 Comprehensive speci-fications such as those embodied in ADS-33C(rotorcraft),2 MIL-STD-1797A (fixed-wing),3

MIL-F-9490D (general control system characteristics),4

and sophisticated time- and frequency-domain evalua-tion techniques are applied to ensure desired perfor-mance and handling qualities and to minimize flight testtuning of highly augmented modern combat aircraft.The overlap of flexible airframe modes and high-bandwidth control laws drives the requirement forincorporating increasingly higher-order analytical andidentification-derived simulation models5 and auto-mated gain selection techniques in the control systemdesign process.6

The control law design and evaluation for a singledesign point is made very laborious as a result of thenumerous (often competing) design specifications andconstraints. This process must be repeated for the tens(or even hundreds) of configuration design points thatare evaluated for a full flight envelope control system.Further, the control system design engineer mustcontinually update and integrate improvements in themathematical models as hardware test data becomeavailable.1 Often, design specification changes are alsointroduced during the course of aircraft development,which as with the other changes require control law


retuning across the flight envelope. Since current toolsgenerally do not facilitate the study of the trade-offsbetween competing specifications, hardware character-istics, and performance metrics, the final design maynot make the best use of available control authority formodern control-configured vehicles. The failure toconsider such trade-offs can compromise controlsystem performance and handling qualities. Clearly,sophisticated interactive computational tools are neededto integrate the many aspects of the flight controldesign process.

The U.S. Army Aeroflightdynamics Directorate inconjunction with NASA, the University of Maryland,and California Polytechnic State University (San LuisObispo) have jointly developed a state-of-the-artcomputational facility for aircraft flight control designand evaluation referred to as CONDUIT. As theacronym implies, CONDUIT (Control Designer’sUnified Interface) provides an environment for designintegration and data resource management (Fig. 1).CONDUIT is a sophisticated “associate” that providescomprehensive analysis support and design guidance toa knowledgeable control system designer; it is not a“turn-the-crank” optimization program. CONDUIT

builds on an earlier design tool, GIFCORCODE,developed under the same cooperative effort.7

This paper describes the CONDUIT tool and casestudy applications to complex rotary-wing design andfixed-wing problems. The control system analysisand design optimization methods are presented first,including the definition of design specifications andsystem models within CONDUIT, and the multi-objective function optimization approach (CONSOL-OPTCAD) used to tune the selected design parameters.The rotorcraft flight control design example is basedon the analysis and optimization of control laws forthe RASCAL UH-60A helicopter. The NASA/ArmyRASCAL (Rotorcraft Aircrew Systems ConceptsAirborne Laboratory) is equipped with a programmablefly-by-wire flight control system to support a range ofresearch programs in flight control, simulation, andadvanced displays.8 CONDUIT is being used toevaluate the baseline control laws and control systemhardware, as provided by the RASCAL flight controlcontractor (Boeing Helicopter), versus the ADS-33Cspecifications. Then the selectable system gains areoptimized to improve system performance and handling

Handling-Qualities &Servoloop Specs

Airframe & FCS modelling

Flight Control LawArchitecture

Hardware characteristics(sensors and actuators)

Performancecriteria

Flight/ground testing(system ID results)

• Rapid setup by non-specialists

• Concurrent engineering

• Comprehensive FCS/HQ eval

• Tradeoff/sensitivity studies

• Automated FCS tuning

• Graphical user interface

Capabilities

Flight Control Engineer

A Multidisciplinary Integration Environment for Flight Control Development

CONDUIT -- Control Designer’s Unified Interface

Payoffs• Dramatic reduction in design cycle• Improved performance and HQ

Fig. 1 CONDUIT control system integration and design evaluation process.


qualities. The CONDUIT results are based on dynamicresponse models of the UH-60A helicopter obtainedfrom system identification, and thus are expected to behighly representative of actual RASCAL performancewithout further significant modification.

The second design example is based on the X-29Ahigh performance fixed-wing aircraft. A unique featureof this fly-by-wire aircraft is its forward-swept wingconfiguration, which renders the bare airframe highlyunstable and thus potentially more maneuverable thanconventional configurations. The X-29A was developedby Grumman and flown at NASA Dryden ResearchCenter.9 Extensive flight data and handling-qualitiesresults are available in the literature, including compari-sons with handling qualities and servo-loop specifica-tions, and design optimization studies. The resultspresented herein suggest that CONDUIT can provideoptions for considerable improvement in the X-29Ahandling qualities and servo-loop characteristics.

Key Features of CONDUIT

CONDUIT is built on top of the highly flexibleMATLAB/SIMULINK system modeling and analysisenvironment,10 which includes a graphical blockdiagram editor and block-diagram-to-code features.CONDUIT makes extensive use of the MATLABgraphical user interface (GUI) coding features to createa true interactive graphical user interface for problemsetup and pushbutton program operation (Fig. 2).

The user graphically selects the desired handlingqualities and flight control system specifications froma library of standard fixed- and rotary-wing speci-fications, or builds new specifications from generictime- and frequency-domain specifications. Specifica-tions are wired to the simulation block diagram via agraphical editor, thereby avoiding any manipulationof the extensive MATLAB “m” files used for eachspecification. The user can click on and bend thespecification boundary curves and the system auto-matically updates the relevant defining equations.

Fig. 2 Collage of CONDUIT displays.


Compliance with all active specifications isgraphically displayed on the criteria with a singlepushbutton command, thus significantly streamliningthe system evaluation process. A key feature ofCONDUIT is that a single mouse click on any of thespecifications brings up an extensive set of supportingplots that present all of the relevant analyses associatedwith the specification. A state-of-the-art multi-objectivefunction optimization environment (CONSOL-OPTCAD)11 is integrated into CONDUIT to allow theuser to tune selected design parameters (e.g., gains,time constants) for compliance with the active designspecifications, or to update control laws for changes inmodeling data and design specifications. An importantapplication of the automated tuning capability is forexamining the trade-offs between control systemperformance and actuator authority requirements,and between competing specifications. Finally, theCONDUIT problem definition and all results are storedand organized in a database for easy retrieval andcomparative studies by the user.

CONDUIT Evaluation and Design Process

Overview

In developing CONDUIT, we have taken the viewthat the aircraft developer has already conducted apreliminary design study to determine an appropriatecontrol law loop architecture. Alternatively, the selec-tion of the control law architecture may have beenbased predominantly on historical precedent within aparticular company. In either case, the control systemanalyst will use CONDUIT to evaluate the baselinedesign and to tune the design parameters for bestsystem behavior.

CONDUIT has two basic modes of operation: setupand run. Within CONDUIT’s setup mode, the useraccesses SIMULINK to define (or import) the simula-tion mathematical model and control law architecture.The aircraft response models are obtained from analyti-cal simulations or system identification results derivedfrom flight/ground test data. The main aspect of prob-lem setup in CONDUIT is the graphical selection andwiring of the handling qualities and servo-loop specifi-cations. The user must also set up a small initializationfile to define problem-dependent constants such assimulation time-step and test input signals.

In CONDUIT’s run mode, the user establishesstarting values for the design parameters and conductsan initial evaluation of all of the system specificationswith the push of a single button. Supporting plots are

examined for further insight into system behavior. Thenthe user can easily tune the design parameters manuallywith rapid access to all of the linear and nonlinearresponse implications, or use the automated tuningfeature to achieve Level 1 (“desirable region”) perfor-mance of all of the specifications. Finally, the optimiza-tion feature of CONDUIT can be exercised to tune thedesign parameters for best performance relative to aselected set of objective criteria.

The following sections give more detailedinformation on CONDUIT operating features.

a. Problem Setup in CONDUIT

The first step of the problem setup in CONDUIT isthe definition of the aircraft dynamics and control lawarchitecture within SIMULINK and the selection ofappropriate design specifications from the availablelibraries. The aircraft aerodynamic model is commonlya high-order linearized state-space representation that isnumerically extracted from a complex nonlinearsimulation model. System identification flight tests areoften conducted early in the aircraft developmentprogram to validate and update the simulationcharacteristics.12 The control law model must includeport limits (e.g., for a limited authority fly-by-wiresystem) and actuator rate and displacement saturationlimits. These nonlinear elements are vitally important indetermining aggressive maneuvering behavior formoderate and large control inputs.

There are currently five graphical librariescomprising over 50 specifications in CONDUIT:

• rotorcraft in hover/low speed flight2

• rotorcraft in forward flight2

• fixed-wing lateral/directional characteristics3, 13

• fixed-wing longitudinal characteristics3, 13

• general system characteristics4

The user scrolls through the libraries (e.g., Fig. 3) andselects, using the mouse, the specifications appropriateto the problem.

Three levels of compliance are defined for eachspecification, following the handling-qualities levelsconvention.2, 3 In the Level 1 region, the aircraftcharacteristics are “satisfactory without improvement.”This is the desirable performance region and is indi-cated in blue on the color monitor (darkest shade inblack and white). The bordering region is Level 2,“deficiencies warrant improvement.” This is theadequate performance region, and may be acceptableunder degraded system operations or for flight outside


Fig. 3 Example window from the handling qualityspecification libraries.

the baseline envelope. This region is indicated inmagenta on the color monitor (lightest shade in blackand white). The final region is Level 3, “deficienciesrequire improvement.” This is the inadequate perfor-mance region, where the mission task will be compro-mised. This region is indicated in red on the colormonitor (intermediate shade in black and white).

The splines that define the boundaries betweeneach level can be graphically altered to update thelibraries with new specifications or to evaluate thesensitivity of a design to changes in the criteria. Addi-tionally, CONDUIT accommodates the uncertainty inthe simulation mathematical model and changes inactual flight condition relative to the reference condi-tion by allowing the user to include a “design margin”as illustrated in Fig. 4. Thus, in flight, the controlsystem performance can degrade into this designmargin without entering the Level 2 region.

The specifications are then “wired” to theSIMULINK simulation model using a graphical “spec

Fig. 4 Bandwidth specification including a 0.6 designmargin.

editor.” Here, the user declares each specification tobelong to one of the following four classes: 1) hardconstraint, 2) soft constraint, 3) performance criterion,or 4) check spec only. The selection of specificationclass defines the solution strategy for the CONSOL-OPTCAD optimization process. The input and outputport connections for each specification are indicated inan information box in the spec editor, and are wired tothe simulation block diagram with pull-down menus.

b. Baseline Evaluation

The user requests a complete evaluation of systembehavior against the specifications by pressing a single“EVAL” button. CONDUIT executes the MATLABscripts associated with each of the selected specifica-tions and displays the results on the graphical specifi-cation plane. Multiple layers of supporting analysisplots are available to the user by simply clicking onthe respective specification (Fig. 5). This feature givesthe control system designer rapid insight into systembehavior and the effects of control system changes onspecification compliance.

c. Performance Comb

A distance algorithm in CONDUIT translates thelocation of the design point on each of the graphicalspecification criteria to a numerical rating. This nor-malized rating is based on the closest distance from theLevel 1/2 and Level 2/3 border splines and the localwidth of the Level 2 region (d1, d2, and d3, respec-tively, in Figs. 6 and 7). A rating of “1” indicates that


Fig. 5 Example of supporting plot that explains the results displayed on specification.

the design point lies on the Level 1/2 border spline. Arating of “2” indicates that the design point lies on theLevel 2/3 border spline. The numerical ratings for eachspecification are displayed on a performance comb(Pcomb) bar chart as shown in Fig. 8. The color of thebars displayed on the monitor corresponds to the color-coding of the Level 1, 2, or 3 region that the data lie in.Figure 8 shows the mapping of the specification resultsinto the Pcomb chart, and indicates the relative degreeof compliance with each of the specifications. Thesenumerical ratings are used by CONSOL-OPTCAD totune the design, as is discussed in the next section.

d. Design Tuning

The user graphically selects design parametersthat will be used by CONDUIT in the tuning process.Typically these are the feedback and feedforwardparameters (e.g., gains, time constants) that arescheduled as a function of flight condition in modernfly-by-wire aircraft. CONDUIT feeds the designparameters and constraints in the form of a “pseudo C”program file to the optimization engine CONSOL-OPTCAD.


Fig. 6 The distance to the two splines is used tocalculate the normalized value.

Fig. 7 Specifications that use vector data have thevalue determined by the “worst point” of the vector.

Nume rical value s of< 1 .0 is Le ve l I re gion1 .0 - 2 .0 is Le ve l II re gion> 2 .0 is Le ve l III re gion

Fig. 8 The Pcomb displays the mapping the between graphical specifications and numerical ratings.

The theoretical basis for CONDUIT’s automatedtuning function rests on the assumption that anyindividual specification can be adequately approxi-mated by a smooth (at least twice differentiable)function, mapping the design parameters into a realnumber. For example, if x ∈ Ω ⊂ Rn, where x is then-vector of parameters and Ω is the set of admissibleparameter values, then fi( x ) is the specification. Thespecification can be a performance criterion, meaning

that the goal is to minimize fi( x ) over all x ∈ Ω , or itcan be a constraint, meaning fi( x ) ≤ βi (βi real) inorder for x to be an admissible value for the designparameters.

The design problem, once it has been fullyformulated, will be solved iteratively starting fromsome initial guess, x o, for the design parameters. Forany constraint that is not satisfied at x o (e.g., fj( x o) >


βj) an obvious way to proceed is to treat that constrainttemporarily like a performance criterion and try tofind an x that minimizes fj( x ) subject to x ∈ Ω . Inattempting to minimize fj( x ), the computer will eithermove to an x that satisfies fj( x ) ≤ βj or show that nosuch solution exists. Thus constraints and performancecriteria are equivalent until a value of x that satisfies theconstraints is found.

The previous paragraphs show that a typicaldesign problem can be mathematically formulated as aconstrained multi-criterion parametric optimizationproblem. In most such problems it is necessary to tradeoff among competing criteria. For example, in mostcontrol design problems, increasing the feedback gainimproves tracking but degrades gain margin. In orderto use the computer to assist in solving such a designproblem it is necessary to reduce the multiple criteria toa single criterion that captures these trade-offs. It is wellknown that no weighted linear combination of criteriacan do this. Mathematically,

min , ,x

i i

i

m

i ix real∈

=∑ ( ) ≤ < ∞

Ωα α αf

1

0 (1)

always occurs at an x *(α) satisfying

min ,x

i x for i m∈

( ) ≤ ≤Ω

f some i 1 (2)

In other words, the value of x that minimizes any linearcombination of performance criteria always equals thevalue of x that minimizes one of the criteria. This isillustrated in Fig. 9a for a simple problem involving twodesign specifications and one design parameter. Theweights can only change which specific criterion isoptimized. All the others are ignored and no trade-offoccurs.

A good way to combine the multiple performancecriteria so as to balance competing objectives is asfollows:

min max , ,x i m

i i i ix real∈ ≤ ≤

( )

≤Ω 1

0α α αf (3)

The great advantage of this formulation is that theoptimal value of x can be placed anywhere in the regionof the parameter space bounded by the minima of theindividual criteria by appropriate choice of the αi. Thisis shown for the simple example in Fig. 9b. Thus any

Fig. 9a Linear combination of performance criteria.

Fig. 9b Min/max solution approach used in CONSOL-OPTCAD.

reasonable choice of the αi produces a trade-off amongthe specifications. The CONDUIT distance algorithmautomatically normalizes the weightings for the speci-fications, using the natural choice of the width of theLevel 2 regions. A designer could explore the trade-offsby adjusting the relative widths of the Level 2 regions.

The min/max formulation of Eq. (3) reduces thecomplex problem of multiple design criteria to aproblem of minimizing a scalar performance measuresubject to constraints. However, solving even the scalaroptimization problem is difficult since the criteriavalues fi( x ) are generally a highly nonlinear functionof the design parameters ( x ). CONDUIT employs the


CONSOL-OPTCAD11 optimization engine to solvethis difficult problem. As the iterative solutionprogresses and those fi( x ) that correspond to constraintsbecome satisfied they change from being performancecriteriato being constraints. Conceptually, such satisfiedconstraints redefine Ω. Thus, at each stage, CONSOL-OPTCAD is trying to solve a constrained parametricoptimization problem. The best algorithm known at thistime for solving such problems is Feasible SequentialQuadratic Programming (FSQP).14, 15 This is thealgorithm used by CONSOL-OPTCAD. The ideabehind FSQP is to approximate the original optimiza-tion problem by a sequence of quadratic programmingproblems. This approximation should result in quadraticconvergence near the optimum. The word “feasible”refers to the fact that the solution continues to satisfyany constraint at every iteration after the first one forwhich the constraint is satisfied.

System optimization using CONSOL-OPTCAD isconducted in three distinct phases. In Phase 1, thedesign parameters are tuned to ensure that the “hardconstraints” are satisfied; these are typically absolute(or relative) stability in each loop and other Level 1specifications that must be satisfied. Once all of thehard constraints meet the Level 1 criteria, the optimi-zation process moves into Phase 2 and begins to workon the “soft constraints.”

Most of the problem’s specifications are declaredas soft constraints. This choice allows CONDUIT toaccept a solution that does not strictly meet all of theLevel 1 requirements, but one that reaches the bestpossible compromise for the available actuatorauthority. If the design satisfies all of the Level 1requirements for the soft constraints, CONSOL-OPTCAD has achieved a “feasible solution.” Since anydesign that resides in the Level 1 region is feasible,Phase 2 optimization actually reaches a “family” ofdesign solutions. Now the optimization process entersPhase 3.

In Phase 3, CONSOL-OPTCAD will tune thedesign parameters to optimize the system to the selectedperformance criteria, and thereby select a final “bestdesign” from the family of feasible solutions. Twocommonly used performance criteria for control systemoptimization are actuator energy and feedback-loopcrossover frequency. Minimizing these parameterswill ensure that the Level 1 design specifications areachieved with the minimum use of control authorityand minimum sensitivity to sensor noise.

e. Trade-Off Studies

The user can systematically adjust control systemhardware parameters and criteria splines and thenquickly retune the design to generate trade-off curves.For example, an aircraft designer can evaluate thesensitivity of the required actuator performance tochanges in the aircraft agility and maneuverabilityrequirements. If modest relaxation in the criteria canallow the use of a significantly reduced actuatorbandwidth (thus lower cost and weight), the manufac-turer may seek a waiver of the specification from theprocuring agency.

f. Databasing

A focus of the ongoing CONDUIT developmenteffort is the integration of a database managementsystem to catalogue all CONDUIT problem definitionfiles and results. The completed databasing system willgreatly improve the organization of the CONDUITworkspace as compared to the simple directory struc-ture of MATLAB/SIMULINK. Previous design casesand associated results will be accessed by a single “casename,” allowing new cases to be rapidly generatedfrom stored configurations. An array of utilities willpermit the detailed comparison of design configurationsin plotted or tabular form. Design parameter and perfor-mance data will be plotted as a function of CONSOL-OPTCAD iteration to give the user maximum insightinto the tuning process.

Rotorcraft Control Law Design Study

a. Problem Setup

In this study, CONDUIT is used to analyze andtune the baseline control system for the RASCALUH-60A fly-by-wire research helicopter8 (Fig. 10).The RASCAL control law architecture is based on theAdvanced Digital Optical Control System (ADOCS)explicit model-following system.16 The schematicblock diagram of Fig. 11 illustrates the importantsystem elements. The block marked “CommandModel” (M) contains the desired dynamic responsecharacteristics, typically represented by low-ordertransfer functions. The block marked “AircraftDynamics” (P) is a 14 DOF linear state-spacerepresentation of the multi-input/multi-output UH-60bare airframe dynamics and precompensation toimprove dynamic decoupling.17 The aircraft dynamicsmodel was extracted from flight test data usingadvanced frequency-domain system identification


procedures specifically developed for the rotorcraft problem.18 Inputs to the helicopter are via the

Fig. 10 The RASCAL UH-60 helicopter.

Fig. 11 Model-following block diagram.

main rotor swashplate for pitch, roll, and verticalcontrol, and the tail rotor pitch for yaw control. Thevertical loop is not closed in this study because theopen-loop dynamics in this axis are well damped andalready meet the relevant handling-qualities require-ments. The block marked “inverse plant model” ( P−1)contains the inverses of low-order transfer-functionapproximations of P. If the inverse plant model isaccurate, the aircraft will track the desired “CommandModel” (M) response with very low bandwidthfeedback compensation (H). The feedbackcompensation (H) contains the feedback gains andcompensators for ensuring stability, robustness, anddisturbance rejection and suppressing any error arisingfrom incomplete cancellation by the plant inverse.

The complete SIMULINK schematic of theRASCAL system is shown in Fig. 12. The designparameters consist of nine feedback gains and threemodel response parameters. The three model responseparameters directly set the desired speed of commandedresponse for the pitch, roll, and yaw channels. Thehandling-quality specifications for this study areobtained from ADS-33C.2 Feedback-loopspecifications are also included to ensure adequatelevels of stability and robustness, and to minimizecontrol actuator saturation. The nine feedback gains arecomposed of three gains (proportional, integral, andrate) for each of the pitch, roll, and yaw channels. The“hard constraints” selected for this problem were gainand phase margin requirements for the feedback loops


and minimum stable real part for all closed-loopeigenvalues. Bandwidth, quickness, coupling, and wind

gust rejection

2

Roll Iput3

Yaw Input4

Collective Input

1

Pitch Input

Filter_Model_Inverse_Plant

PitchRollYawColl

swit1

++

++

CT Pure Delay Dynamics (75ms)

PitchRollYawColl

PLANT

uvwpqr

phithetapsi

1

u [ft/sec]2

v [ft/sec]3

w [ft/sec]4

p [rad/sec]5

q [rad/sec]6

r [rad/sec]7

phi [rad]8

theta [rad]9

psi [rad]

Actuator Rate

PitchRollYawColl

16

Yaw Actuator Rate [in/sec]

14

Pitch Actuator Rate [in/sec]15

Roll Actuator Rate [in/sec]

17

Collective Actuator Rate [in/sec]

PitchRollYawColl.44s

s +2s+12

.44s

s +2s+12

.44s

s +2s+12

Wind Gust Transfer Functions

5

Pitch_gust

6

Roll_gust

7

Yaw_gust

8

Collective_gust

UH−60A Model Following Block Diagram ADOCS Created by: Mark R. Morel

August 1, 1996

Low Order CrossfeedsActuator Command & Rate Saturation

UH−60A Dynamics10

Pitch Actuator [in]11

Roll Actuator [in]12

Yaw Actuator [in]13

Collective Actuator [in]

Actuator Position

PitchRollYawColl0

swit4

swit2

swit3

Demux

DemuxDemux Mux

Mux2

20

19

18

−1

−1

CT_Pure_Delay_Dynamics(105,0,98_ms)

PitchRollYaw

0

swit1

Filter_Model

Theta_model

Phi_model

Psi_model

q

p

r

Yaw Feedback Switch

Roll Feedback Switch

Pitch Feedback Switch

Mux

++

H Block

−1

57.3

Rad2Deg

21

p [deg/sec]22

q [deg/sec]23

r [deg/sec]24

phi [deg]25

theta [deg]26

psi [deg]

Demux

1/s1/s

1/s

27

x [ft]28

y[ft]29

z [ft]

Fig. 12 SIMULINK diagram of the RASCAL model-following control laws.

specifications from ADS-33C2 were all defined as “softconstraints.” The performance criteria selected were theactuator energy and feedback-loop crossover frequencyfor each of the three loops (f/e in Fig. 11).

b. Baseline and Optimized Design Performance

The performance of the baseline RASCAL systemdesign is shown on the CONDUIT specificationwindow in Fig. 13. The baseline design meets theLevel 1 criteria except for the yaw bandwidth and thepitch, roll, and yaw quickness. CONDUIT successfullytuned the design to reach a “feasible solution” thatachieved all hard and soft constraints. The Phase 3optimized design shown in Fig. 14 minimizes theselected performance criteria and meets Level 1requirements for all specifications.

Table 1 compares the design parameter values forthe optimized solution with the design parameter valuesfor the baseline system. The baseline design does notuse integral feedback loops; therefore, the gains forthese loops are set to zero for the baseline design. Twonoticeable changes for the optimized design are theincreases in the roll and yaw command modelfrequency parameters (Mphi and Mpsi), so the

associated quickness and bandwidth specificationscould be met. Figures 15a and 15b show the supportingplot for the yaw quickness and yaw actuator energyspecifications. The figures show that the yaw angle andyaw rate responses are smooth and do not possess anyunwanted oscillations. The associated actuator positionand rate responses (Fig. 15b) provide a completepicture of the system performance and indicate somedegree of saturation. This information can be used todecide whether the actuators are sufficient for thesystem.

The Table 1 comparison also shows a largedecrease in Kp along with an increase in the integralgain, KIphi. These changes allow a significant reduc-tion (28%) in the roll crossover frequency, withoutsacrificing the low frequency model tracking. There isan attendant reduction in roll channel phase margin.Further reduction in the control energy usage is limitedby the pitch, roll, and yaw quickness specifications,which have points resting on the design margin bordersfor small attitude changes. Further reductions in cross-over frequency are restricted by the wind gust rejectionresponse, which was relaxed to the design margin in allthree channels.


Fig. 13 RASCAL design using ADOCS gains.


Fig. 14 Optimized RASCAL design.


Table 1 Comparison of design parameters for baseline19 and CONDUIT solution

Designparameter

Function Baseline value Final value optimized inCONDUIT

Ktheta Pitch proportional gain 13.6 12.1Kphi Roll proportional gain 8.0 8.5Kpsi Yaw proportional gain 7.6 8.3Kq Pitch rate gain 6.4 6.4Kp Roll rate gain 2.4 0.28Kr Yaw rate gain 3.2 3.1KItheta Pitch integral gain 0 1.0KIphi Roll integral gain 0 2.3KIpsi Yaw integral gain 0 1.1Mtheta Pitch command model frequency 2.0 2.5Mphi Roll command model frequency 2.5 4.6Mpsi Yaw command model frequency 2.0 4.1

(a)

(b)Fig. 15 Supporting plots for the yaw quickness and actuator energy specifications.


Fig. 16 CONDUIT studies showing trade-off of position station accuracy against required actuator rate andcrossover frequency.

c. Position Hold Trade-Off

An example of how CONDUIT can be used toexamine the trade-off between hover hold performanceand actuator requirements is shown in Fig. 16. In thisexample, position and velocity feedback gains weretuned to reach various levels of hovering station-keeping accuracy, while the helicopter was subjectedto a simulated wind gust time history. A position holdspecification was employed as a soft constraint toenforce desired levels of station-keeping accuracy for aspecified wind gust strength. The results showsignificant gains in hover hold performance for actuatorrates of up to 2 in./sec, but little improvement for higherrates.

X-29 High Performance Fixed-Wing AircraftControl Law Design Study

The X-29A (Fig. 17) was an experimental aircraftflown at the NASA Dryden Flight Research Center todemonstrate the integration of several aerodynamicsand controls technologies into a highly maneuverableaircraft. It is a relatively small, single-seat aircraftpowered by a single F404-GE-400 engine. The vehicleincorporates a forward-swept wing and static instabilityto reduce trim drag and enhance maneuverability.20

The aircraft has three surfaces used for longitudinalcontrol: all moving canards, symmetric wing flaperons,and aft fuselage strake flaps. The wing-canard planformresults in a high level of instability that has a time-to-double amplitude near 150 msec.21 There exist bothlow- and


Fig. 17 X-29A forward-swept wing fly-by-wire demonstrator.

high-frequency instabilities resulting in a very limitedfrequency range of stability. Also, the baseline controlsystem has a crossover frequency more than half thecanard actuator mode, which if pushed a little higherexcites the actuator frequency.

a. X-29A Design Method and Flight Test Experience

The X-29A control law design approach concen-trated on maximizing robustness rather than maneuver-ability for envelope expansion flight tests. Thus, asdiscussed in detail in Ref. 21, initial flight tests of theX-29 handling qualities indicated that the aircraftcharacteristics were Level 2 (adequate). The maindeficiency reported by the pilots was sluggishness inthe pitch axis. A design optimization effort wasundertaken to determine if the pitch responsivenesscould be improved without adversely affecting thecontrollability, thus improving the handling qualities ofthe aircraft. An optimization technique was developedat Dryden that was based on a single cost function withseveral frequency domain derived components. Thiscost function was selected to ensure minimum accept-able stability levels and reasonable surface activity, andto minimize the closed-loop resonance and requiredpilot compensation, based on the Neal-Smithcriterion.22

Flight test engineers were not able to reach thedesign goal of 10 deg lead compensation and 0.0 dBresonant peak while maintaining adequate stabilitymargins and reasonable surface activity. However, thepilot lead was reduced by almost 50% from the originalgains and the achieved resonant peak was below 1.0 dB

for the given design point. The pilot comments sug-gested a significant improvement in the vehicle’s pitchresponse with the new gains. The design processshowed a definite trade-off between the stabilityconstraints, the surface activity, and the achievableNeal-Smith criterion. The resulting design had border-line stability margins and surface rates approaching themaximum capability of the system. CONDUIT wasexercised to determine if further improvements in thedynamic response characteristics were achievable bytuning the control system design parameters.

b. Problem Setup in CONDUIT

Figure 18 shows the block diagram of the X-29longitudinal control law created in the CONDUIT setupphase. The linearized models were developed andverified with flight test data from Dryden.9 The longi-tudinal control law uses proportional and integralcompensation in the forward path to improve aircraftpitch responsiveness. The lead-lag filter in the feedbackpath compensates for lags introduced by high-orderdynamics. Stabilization is provided by feedback ofvertical acceleration (nz), pitch rate (q), and (estimated)pitch acceleration ( q ). The pitch acceleration is esti-mated using a complementary filter that combines thecanard signal and a two-point derivative of pitch rate.The “g” command authority is scheduled as a functionof Mach number, altitude, and roll rate and is com-manded linearly with stick position. The design param-eters chosen in this study are the four feedback gains(G1, G2, G3, and G8), two PI controller gains (XKI1and XKP1), two lead filter parameters (a1 and b1), and


one pilot command gain (G7). Table 2 summarizes the purpose of these gains and their baseline values.

++

++

KST .9876s

s+.9881High Pass

Filter

.0127s+1.0124

s+.9881LowPass Filter

−0.3 −0.7−.005s−.4

sIntegrator_1

+++

dp_XKI1

Integral feedforward [(deg)/(deg)]

.0125s+1

s

Integrator_2

0swit1

2

Error Sig

10

Cnrd_act_pos [deg] 11

Flp_act_pos [deg] 12

Strk_act_pos [deg]

100

s+100Time delay1

dp_XKP1

Proportional feedforward [(deg)/(deg/sec)]

aproxZOH

aproxZOH_

++

100

s+100Noise filter aproxZOH2

100

s+100Time delay2

100

s+100Time delay

dcdsfdstf

Mux

9

Strk_act_rate [deg/sec]

8

Flp_act_rate [deg/sec]

7

Cnrd_act_rate [deg/se

Valpha

qthetaNz

Demux

x’ = Ax+Bu y = Cx+Du

X−29A 4

theta [deg]

5

nz [g]

3

q [deg/sec]

2

apha [deg]

1

V [ ft/sec]Canard actuator

Flap actuator

Strflap actuator

1 Longitudinal Stick

100

s+100Stick prefilter

GMAX GMAX [g/%]

57.3*32.2/VtrimVtrim

dp_G7 Pilot command gain [rad/g]

s+dp_a1

s+dp_b1Quickness FIlter

57.3

dp_G380s

s+80

Differentiator

dp_G1

dp_G3 dp_G8s

s+49.9968

High Pass Filt 1

200

s+200Antialiasing Filter

200

s+200Antialiasing Filter1

200

s+200Antialiasing Filter2

49.4309

s+50.0813

LowPass Filter1

18769

s +192.896s+187692

Pitch rate sensorPitch rate notch filters

Normal acceleration notch filters

Canard notch filter

+++

dp_G2

+ +

0swit1

−1Gain

6

feedback

dp_b.s +7.1167*dp_as+dp_a^22

s +2*dp_as+dp_a^22 Lead Compensation

Fig. 18 Longitudinal ND control laws for up-and-away flight.

Table 2 X-29A design parameters

Designparameter

Function Baselinevalue

Optimizedbaseline value

Quickness filterincluded value

Change relativeto baseline (%)

XKI1 Integral gain 1.0 1.4 1.9 91.8

XKP1 Proportional gain 0.23 0.20 0.18 –20.9

G1 nz feedback gain 0.0054 0.0054 0.0054 0

G2 q feedback gain –3.6 –3.2 –2.1 –40.8

G3 q feedback gain –0.18 –0.25 –0.25 –37.8

G7 Pilot gain 3.54 3.8 7.2 103.2

G8 High frequency q gain 16.7 15.6 12.8 –23.1

a1 Quickness filter zero NA NA 2.7 –31.8

b1 Quickness filter pole NA NA 8.3 –31.0

a Lead compensatorparameter

120.0 112.6 92.5 –22.9

b Lead compensatorparameter

11.0 10.3 8.4 –23.6

The “hard constraint” specifications chosen for thelongitudinal analysis were 1) feedback-loop stabilitymargins, 2) minimum stability for all closed-loopeigenvalues, and 3) a restriction on allowable change inthe steady state “g/stick” response. The “softconstraint” specifications were 1) the Neal-Smithcriterion,22 2) an updated mission oriented Bandwidthrequirement for Flight Categories A and D,13 and 3) atime-domain attitude quickness specification proposedin Ref. 13. The Phase 3 performance criteria wereselected as 1) the Neal-Smith optimizationspecification, which minimizes the closed-loop

resonance and required pilot compensation; 2) theactuator energy specification;and 3) the crossover frequency specification. Severalspecifications were chosen as “check only.” Theseincluded the Smith-Geddes criterion, the ControlAnticipation Parameter criterion (CAP), and the ωsp,Τθ2, ζsp criterion. The CAP and ωsp,Tθ2, ζsp param-eters are determined in CONDUIT from a lower-orderequivalent system (LOES) fit3 of the complete end-to-end system frequency response.


There are several advantages to the CONDUITproblem definition in comparison with the optimizationdesign technique used by X-29 engineers. The first isthat CONDUIT uses multi-objective optimization,which allows the relative importance of each specifi-cation to be determined by using “hard constraints,”“soft constraints,” or “performance criteria” rather thana single cost function incorporating the requirements ofseveral specifications. Second, the optimization designmethod used by the X-29 engineers was limited to theNeal-Smith frequency domain criterion, which dependson the linear system performance. This ignores thenonlinear influence of actuator saturation, which iscaptured by the time-domain quickness specification13

implemented in the CONDUIT solution. Anotherimportant aspect of the CONDUIT solution was thebalance of improvements in agility against theassociated increase in actuator energy requirements.

c. Baseline System Analysis in CONDUIT

The performance of the baseline X-29 design9 asdetermined by CONDUIT is shown in Fig. 19. Thisbaseline design corresponds to the “Normal-Digital”mode for up-and-away flight control law architecture.

The flight condition for this analysis is Mach 0.7 at analtitude of 20,000 ft.

The baseline X-29 aircraft meets all the hardconstraints except the stability margin criterion(GM = 7.9 dB, PM = 41.3 deg). Level 1 requirementsfor bandwidth requirement are met (soft constraint).Predicted handling qualities based on the Neal-Smithcriterion (soft constraint) are borderline Level 1.However, the pitch quickness (soft constraint) perfor-mance is deep in the Level 2 region. In addition, theNeal-Smith optimization criterion is far from thedesired 0 dB resonance and 10 deg pilot lead compen-sation. Also, the LOES based criteria and the Smith-Geddes criterion are also in the Level 2 regions. Theseresults suggest that the pitch characteristics of theaircraft are inadequate. This corresponds well to thepilot comments concerning sluggish response in thepitch axis for the initial design.21

CONDUIT was next used to determine how muchof an improvement could be made within the confinesof the baseline system architecture, the selected ninedesign parameters, and the available actuator authority.


Fig. 19 Baseline X-29A performance and handling qualities results.

The key concerns were to meet the stability require-ments, improve the moderate amplitude quickness, andreduce the required pilot compensation. The selectedperformance criteria were: minimum actuator energyand minimum crossover frequency.

d. Optimized X-29 Control System Performance

The optimization of the X-29 control laws usingCONDUIT revealed some interesting aspects of theproblem as formulated. First, it was revealed that thefeedback gain on nz (G1) had very little effect on thesystem response, and thus degraded the progress of theoptimization algorithm. Therefore, this value wasfrozen at its baseline value. Second, it was revealedthat there was no solution that meets all of the problemconstraints using the existing X-29 architecture andselected nine design parameters. The best solutionwithin the existing architecture is shown in Fig. 20.Although improvements from the baseline design areobserved, the moderate amplitude quickness require-ments could not be met using the existing architecture.

The most noticeable improvement is the increasedphase margin required to meet Level 1 stability marginrequirements. The optimized baseline designparameters are listed in Table 2.

In order to address the deficiency in the responsequickness, we included a first order lead-lag filter in thepilot command path. This “quickness filter” is seen inFig. 18 with a dashed box surrounding it. Baselinevalues of 4.0 and 12.0 were chosen for the filter zero(dp_a) and pole (dp_b). Starting with the baselinevalues and the two added design parameters,CONDUIT was used to tune the eleven designparameters in the new architecture. With addition ofthe quickness filter CONDUIT quickly converged toan acceptable solution by meeting all the hard and softconstraints. With the hard and soft constraints met,CONDUIT reached Phase 3, and was further able toreduce the crossover frequency and actuator energy.The optimized solution including the quickness filter isseen in Fig. 21. The resulting design parameters and the


Fig. 20 Optimized X-29A performance and handling qualities results (optimized baseline).


Fig. 21 Optimized X-29A performance and handling qualities results (with quickness filter).

percent change from the baseline design parameters arefound in Table 2.

The stability margins for this design (Fig. 22) areabout the same as those achieved for the optimizedbaseline (Fig. 20). However, there is now a substantialimprovement in the moderate amplitude quickness(Fig. 23) and bandwidth (Fig. 24) relative to the opti-mized baseline. Figure 25 shows that the required pilotcompensation (Lead = 16.2 deg) is about half that of thebaseline system (Lead = 29.8 deg). As expected, thecanard actuator is being taxed more severely; however,the system is less susceptible to actuator noise becausethe baseline crossover frequency (ωc = 9.63 rad/sec)was reduced (ωc = 8.99 rad/sec). The equivalent end-to-end response damping (Fig. 26) of the optimizedsystem has been reduced from ζsp = 1.46 to ζsp =0.895, due to the lead contribution of the quicknessfilter.

Fig. 22 Optimized X-29A stability margin results.


Fig. 23 Optimized X-29A moderate amplitude quickness requirement results.

Fig. 24 Optimized X-29A bandwidth requirement results.

Fig. 25 Optimized X-29A Neal-Smith results.


Fig. 26 Optimized X-29A LOES parameters.

These results show that CONDUIT was able toachieve increased agility and improved stabilitymargins within the constraint of the existing actuatorauthority. All of the desired handling quality require-ments were met, including the “check only” criteria:Smith-Geddes, CAP, and ωsp,Tθ2, ζsp.

Summary

1. A new computational facility for aircraft flightcontrol design and evaluation, CONDUIT, has beendeveloped and demonstrated. CONDUIT offers a state-of-the-art graphical environment for integrating simula-tion models and control law architectures with designspecifications and constraints. This tool providescomprehensive analysis support and design guidance toa knowledgeable control system designer. CONDUIToffers the potential for significant reduction in time andcost of design, analysis, and flight test optimization ofmodern flight control systems.

2. Libraries of preprogrammed specifications forrotorcraft, fixed-wing aircraft, and servo-loop designare rapidly configured to the user’s design problem.Compliance with all of the active specifications isgraphically displayed on the criteria with a singlepushbutton command, thus significantly streamliningthe system evaluation process. A comprehensive set ofsupporting plots is available for each specification,

thereby giving the analyst rapid insight into the controlsystem behavior. A state-of-the-art multi-objectivefunction optimization environment (CONSOL-OPTCAD) is integrated in CONDUIT to allow the userto tune selected design parameters (e.g., gains, timeconstants) for compliance with the active designspecifications and selected performance specifications.

3. Case study applications to complex rotary- andfixed-wing flight control problems were presented. Inthe helicopter example, the baseline RASCAL UH-60control system, as provided by the flight controlcontractor, is evaluated versus the ADS-33C handling-quality specifications. Then the selectable system gainsare optimized to meet all system performance andhandling-qualities specifications. In the X-29 fixed-wing example, CONDUIT analyses show that thehandling qualities for the baseline control systemexhibit poor quickness and inadequate stabilitymargins. No significant improvement in quickness isachievable by adjusting the controller parameters forthe baseline control law architecture. The inclusion of aquickness filter in the pilot command path provides anadditional degree of freedom for control system tuning.CONDUIT successfully exploits the trade-off betweenforward loop and feedback dynamics to significantlyimprove the expected handling qualities and stabilityrobustness.


References

1Tischler, Mark B. (Editor), Advances in AircraftFlight Control, Taylor and Francis Ltd., Bristol, Pa.,1996.

2United States Army Aviation Systems Command,“Handling Qualities Requirements for Military Rotor-craft,” ADS-33C, St. Louis, Mo., Aug. 1989.

3United States Department of Defense, “FlyingQualities of Piloted Vehicles,” MIL-STD-1797,Mar. 1987.

4Military Specification, Flight ControlSystems—General Specifications for Design,Installation, and Test of Piloted Aircraft, MIL-F-9490D, 1975.

5Tischler, M. B., “System IdentificationRequirements for High-Bandwidth Rotorcraft FlightControl System Design,” J. Guid., Control, and Dyn.,Vol. 13, No. 5, 1990, pp. 835–841.

6Takahashi, M. D., “Rotor-State Feedback in theDesign of Flight Control Laws for a Hovering Heli-copter,” J. Am. Helicopter Soc., Vol. 39, No. 1, 1994,pp. 52–62.

7Yudilevitch, G., Tischler, M. B., Levine, W. S.,and Lin, C., “Rotorcraft Flight Control System DesignBased on Multi-Criterion Parametric Optimization,”AIAA Guidance, Navigation, and Control Conference,Baltimore, Md., Aug. 7–9, 1995.

8Aiken, E., Jacobsen, R., Eshow, M., Hindson, W.,and Doane, D., “Preliminary Design Features of theRASCAL—A NASA/Army Rotorcraft In-FlightSimulator,” AIAA Paper 92-4175, Aug. 1992.

9Bosworth, John T., “Linearized Aerodynamicand Control Law Models of the X-29A Airplane andComparison with Flight Data,” NASA TM-4356, 1992.

10MATLAB®: High-Performance NumericComputation and Visualization Software. The MathWorks, Inc., Reference Guide, 1992.

11CONSOL-OPTCAD (TM) User’s Manual(Version 1.2–1.5, Released May 1992), University ofMaryland, College Park, Md., 1992.

12Tischler, M. B., “System Identification Methodsfor Aircraft Flight Control Development and Valida-tion,” from Advances in Aircraft Flight Control

(Tischler, M. B., Editor), Taylor and Francis Ltd.,Bristol, Pa., 1996.

13Mitchell, David G. and Hoh, Roger H.,“Proposed Incorporation of Mission-Oriented FlyingQualities into MIL-STD 1797A,” WL-TR-94-3162,Oct. 1994.

14Panier, E. R. and Tits, A. L. “On CombiningFeasibility, Descent, and Superlinear Convergencein Equality Constrained Optimization,” Math.Programming, Vol. 59, 1993, pp. 261–276.

15Lawrence, C., Zhou, J. L., and Tits, A. L.,“User’s Guide for CFSQP Version 2.4: A C Codefor Solving (Large Scale) Constrained Nonlinear(Minimax) Optimization Problems, Generating IteratesSatisfying All Inequality Constraints,” University ofMaryland, College Park, Md., 1996.

16Glusman, S. I., Dabundo, C., and Landis, K. H.,“Evaluation of ADOCS Demonstrator HandlingQualities,” Proceedings of the 43rd Annual NationalForum of the American Helicopter Society,Washington, D.C., May 1987.

17Catapang, D. R., Tischler, M. B., and Biezad,D. J., “Robust Crossfeed Design for Hovering Rotor-craft,” Int’l. J. Robust and Nonlinear Control, Vol. 4,No. 1, Jan.–Feb. 1994.

18Fletcher, J. W., “Identification of UH-60Stability Derivative Models in Hover from Flight TestData,” J. Am. Helicopter Soc., Vol. 40, No. 1, 1995,pp. 32–46.

19Tischler, M. B., Fletcher, J. W., Patrick, P. M.,Morris, M., and Tucker, G. E., “Flying QualityAnalysis and Flight Evaluation of a Highly AugmentedCombat Rotorcraft,” J. Guid., Control, and Dyn., Vol.14, No. 5, 1991, pp. 954–963.

20Clarke, Robert, Burken, John J., Bosworth,John T., and Bauer, Jeffrey E., “X-29 Flight ControlSystem: Lessons Learned,” from Advances in AircraftFlight Control (Tischler, M. B., Editor), Taylor andFrancis Ltd., Bristol, Pa., 1996.

21Bosworth, John T. and Cox, Timothy H., “ADesign Procedure for the Handling Qualities Optimiza-tion of the X-29A Aircraft,” NASA TM-4142, 1989.

22Neal, T. P. and Smith, R. E., “An In-FlightInvestigation to Develop Control System DesignCriteria for Fighter Airplanes, Volume I,”AFFDL-TR-70-74, Dec. 1970.

conduit—a new multidisciplinary integration...

Documents