Developement Of A Batch Mode For Conduit And Its ... - Cal Poly

THE DEVELOPMENT OF A BATCH MODE FOR CONDUIT
AND ITS APPLICATION TO A ROTORCRAFT FLIGHT CONTROL SYSTEM
A Thesis
presented to the faculty of the
California Polytechnic State University, San Luis Obispo
In Partial Fulfillment
of the Requirements for the Degree of
Master of Science in Aeronautical Engineering
by
Ryan Patrick Dibley
June 2000

© 2000
Ryan Dibley
All Rights Reserved
ii

APPROVAL PAGE
TITLE:
The Development of a Batch Mode for CONDUIT
and its Application to a Rotorcraft Flight Control System
AUTHOR:
Ryan P. Dibley
DATE SUBMITTED: May 25, 2000
Advisor or Committee Chair
Signature
Committee Member
Signature
Committee Member
Signature
Committee Member
Signature
Committee Member
Signature
iii

ABSTRACT
The Development of a Batch Mode for CONDUIT
and its Application to a Rotorcraft Flight Control System
Ryan P. Dibley
A Batch Mode capability was developed for CONDUIT, providing for the
capability to quickly create, optimize, and analyze multiple CONDUIT problems. The
Sensitivity Tools of CONDUIT were automated and incorporated into Batch Mode, such
that multiple number of CONDUIT problems could be fully optimized without user
intervention. In order to demonstrate the capabilities of Batch Mode, the lateral channel
of the partial authority SH-2G control system was analyzed in Batch Mode. A group of
cases, ranging in velocity from hover to 100kts, were optimized to produce a gain
schedule of the four active gains. A second group of cases were created, based on the
hover flight condition, in which the stability derivatives, identified using CIFER, were
varied to their known accuracies. The results of this second group were then plotted
simultaneously on the HQ Window, to demonstrate the ability for Batch Mode to check
for system robustness.
iv

ACKNOWLEDGEMENTS
I would like to thank Dr. Mark Tischler for his guidance and assistance
throughout the course of my thesis. I would also like to thank my co-workers, Chad
Frost, Kenny Cheung, Doug Hiranaka, and Jason Colbourne, for without their
suggestions, help, and knowledge of CONDUIT, this project would not have been
possible. Finally, I would like to thank Dr. Daniel J. Biezad for both providing me with
the basis of my knowledge of control engineering, and for giving me the opportunity and
drive to continue my education.
v

TABLE OF CONTENTS
TABLE OF CONTENTS ............................................................................................................................VI
LIST OF TABLES ....................................................................................................................................VIII
LIST OF FIGURES .....................................................................................................................................IX
NOMENCLATURE.....................................................................................................................................XI
1 OVERVIEW OF CONDUIT............................................................................................................... 1
1.1 THE STRUCTURE OF CONDUIT......................................................................................................... 5
1.1.1 Fundamental Structure ............................................................................................................ 5
1.1.2 Block Diagram (Setup Mode) .................................................................................................. 6
1.1.3 Design Parameters (Setup Mode)............................................................................................ 7
1.1.4 Specs (Setup Mode).................................................................................................................. 8
1.1.5 HQ Window (Setup Mode)..................................................................................................... 13
1.1.6 Init File (Setup Mode)............................................................................................................ 14
1.1.7 HQ Window (Run Mode) ....................................................................................................... 15
1.1.8 Pcomb (Run Mode) ................................................................................................................ 16
1.1.9 Design Parameters Window (Run Mode) .............................................................................. 17
1.2 METHOD OF OPTIMIZATION.............................................................................................................. 18
1.3 SENSITIVITY TOOLS.......................................................................................................................... 23
1.3.1 Insensitive Parameters........................................................................................................... 24
1.3.2 Correlated Parameters .......................................................................................................... 27
2 DEVELOPMENT OF BATCH MODE ........................................................................................... 29
2.1 INTRODUCTION................................................................................................................................. 29
2.2 SETUP MODE.................................................................................................................................... 29
2.2.1 Creating the Batch Problem .................................................................................................. 30
2.2.2 Modifying the Cases............................................................................................................... 30
2.2.3 Saving the Cases .................................................................................................................... 31
2.2.4 Batch Mode GUI Fundamentals ............................................................................................ 33
2.2.5 Setup Mode GUI .................................................................................................................... 40
2.2.6 Constructing A Batch Problem .............................................................................................. 46
2.3 RUN MODE....................................................................................................................................... 47
2.3.1 Run Methods .......................................................................................................................... 47
2.3.2 Running A Case...................................................................................................................... 48
2.3.3 Run Mode GUI....................................................................................................................... 50
2.3.4 Running A Batch Problem ..................................................................................................... 55
2.4 ANALYSIS MODE.............................................................................................................................. 57
2.4.1 Fundamentals of Analysis Mode............................................................................................ 57
2.4.2 Analysis Mode GUI................................................................................................................ 61
2.5 SENSITIVITY AUTOMATION .............................................................................................................. 71
2.5.1 Typical Use of Sensitivity Tools............................................................................................. 71
2.5.2 Sensitivity Automation Development ..................................................................................... 77
2.5.3 Sensitivity Log........................................................................................................................ 86
3 EVALUATION OF THE SH-2G USING BATCH MODE............................................................ 89
3.1 DESCRIPTION OF THE SH-2G............................................................................................................ 90
3.1.1 SH-2G Control System........................................................................................................... 91
3.1.2 Required Modifications to the Block Diagram ...................................................................... 96
vi

3.2 BASELINE OPTIMIZATION................................................................................................................. 97
3.3 GAIN SCHEDULING OF THE SH-2G................................................................................................. 103
3.3.1 Setup of Problem.................................................................................................................. 103
3.3.2 Running of the Gain Schedule Batch Problem .................................................................... 106
3.3.3 Gain Schedule Results.......................................................................................................... 107
3.4 ROBUSTNESS EVALUATION OF THE SH-2G.................................................................................... 113
3.4.1 Parameters to Vary.............................................................................................................. 113
3.4.2 Modification of the Original Model..................................................................................... 115
3.4.3 Creation of the Robustness Cases........................................................................................ 116
3.4.4 Running the Robustness Check Cases.................................................................................. 117
3.4.5 Results of the Robustness Check.......................................................................................... 118
3.4.6 Conclusions of the Robustness Plot Capability ................................................................... 122
4 FUTURE WORK ............................................................................................................................. 123
4.1 SETUP MODE.................................................................................................................................. 123
4.2 RUN MODE..................................................................................................................................... 123
4.3 ANALYSIS MODE............................................................................................................................ 123
4.4 SENSITIVITY AUTOMATION ............................................................................................................ 124
5 LESSONS LEARNED ..................................................................................................................... 125
6 CONCLUSIONS............................................................................................................................... 127
BIBLIOGRAPHY...................................................................................................................................... 128
APPENDIX................................................................................................................................................. 130
vii

LIST OF TABLES
TABLE 1 – SENSITIVITY AUTOMATION RUN LOGIC........................................................................................ 77
TABLE 2 - SPEC SELECTION LOGIC.................................................................................................................. 78
TABLE 3 - VARIATIONS OF DERIVATIVES...................................................................................................... 114
viii

LIST OF FIGURES
FIGURE 1 - COOPER-HARPER RATING SCALE.................................................................................................... 1
FIGURE 2 - CONDUIT SPECS........................................................................................................................... 4
FIGURE 3 – CODING STRUCTURE OF CONDUIT............................................................................................... 5
FIGURE 4 - THE MATLAB SIMULINK ENVIRONMENT...................................................................................... 7
FIGURE 5 - DESIGN PARAMETERS..................................................................................................................... 8
FIGURE 6 - A CONDUIT SPEC ........................................................................................................................ 9
FIGURE 7 - CONFIGURING A SPEC ................................................................................................................... 12
FIGURE 8 - HQ WINDOW................................................................................................................................ 13
FIGURE 9 - SUPPORT PLOT .............................................................................................................................. 15
FIGURE 10 – PCOMB WINDOW ........................................................................................................................ 16
FIGURE 11 - DESIGN PARAMETERS WINDOW.................................................................................................. 17
FIGURE 12 - 2D GRADIENT VISUALIZATION (HYPOTHETICAL) ....................................................................... 18
FIGURE 13 - CONCEPTUAL STEP SIZE CALCULATION ...................................................................................... 19
FIGURE 14 - INSENSITIVE PARAMETER ........................................................................................................... 24
FIGURE 15 - BLOCK DIAGRAM REPRESENTATION OF AN INSENSITIVE PARAMETER ........................................ 25
FIGURE 16 - INSENSITIVE PARAMETERS.......................................................................................................... 26
FIGURE 17 - BLOCK DIAGRAM REPRESENTATION OF CORRELATED PARAMETERS .......................................... 27
FIGURE 18 - BATCH PROBLEM FILE AND DIRECTORY STRUCTURE.................................................................. 33
FIGURE 19 - SETUP MODE GUI ...................................................................................................................... 34
FIGURE 20 - MAIN WINDOW........................................................................................................................... 35
FIGURE 21 - FILE MENU ................................................................................................................................. 37
FIGURE 22 - INSERT FAMILY AND CASE INTERFACES..................................................................................... 38
FIGURE 23 - BUTTON TOOLBAR...................................................................................................................... 39
FIGURE 24 - GENERAL SETUP WINDOW........................................................................................................... 42
FIGURE 25 – GAIN SCHEDULE PARAMETER SETUP WINDOW .......................................................................... 44
FIGURE 26 - ADD/EDIT/REMOVE/ PARAMETER GUI...................................................................................... 45
FIGURE 27 - RUN MODE GUI ......................................................................................................................... 50
FIGURE 28 – ORDERING THE CASES................................................................................................................ 53
FIGURE 29 - RUN STATUS WINDOW................................................................................................................ 54
FIGURE 30 - RUN STATUS FILE ....................................................................................................................... 55
FIGURE 31 - THE RUN MODE GUI OF A CURRENTLY RUNNING PROBLEM...................................................... 56
FIGURE 32 – PBRUSH...................................................................................................................................... 58
FIGURE 33 - ORGANIZATION OF GAIN SCHEDULE FIGURES............................................................................. 60
FIGURE 34 - ANALYSIS MODE GUI - HQ WINDOW ....................................................................................... 61
FIGURE 35 - MULTIPLE CASE PLOT ................................................................................................................. 64
FIGURE 36 - INITIAL GAIN SCHEDULE WINDOW ............................................................................................ 65
FIGURE 37 - ADD/EDIT/REMOVE PLOT GUI................................................................................................... 66
FIGURE 38 - NEW GAIN SCHEDULE PLOT ....................................................................................................... 68
FIGURE 39 - MULTIPLE PAGE CONCEPT .......................................................................................................... 70
FIGURE 40 - INSENSITIVITY PLOT................................................................................................................... 72
FIGURE 41 - SAMPLE CRAMER RAO PLOT....................................................................................................... 73
FIGURE 42 - CONCEPTUAL REPRESENTATION OF CORRELATED PARAMETERS ................................................ 75
FIGURE 43 - THE DIFFICULTY OF GROUPING PARAMETERS ............................................................................. 80
FIGURE 44 - EXAMPLE CRAMER RAO PLOT – INITIAL PARAMETERS .............................................................. 83
FIGURE 45 - EXAMPLE CRAMER RAO PLOT - ONE PARAMETER FROZEN ........................................................ 84
FIGURE 46 - EXAMPLE CRAMER RAO PLOT - TWO CORRELATED PARAMETERS ............................................. 85
FIGURE 47 - SENSITIVITY LOG........................................................................................................................ 87
FIGURE 48 - SH-2G ........................................................................................................................................ 90
FIGURE 49 - SH-2G ROTORBLADE SERVOFLAP .............................................................................................. 91
FIGURE 50 - MECHANICAL MIXER REPRESENTATION...................................................................................... 92
FIGURE 51 - SH-2G BLOCK DIAGRAM ............................................................................................................ 93
FIGURE 52 - CONTROL SYSTEM BLOCK .......................................................................................................... 94
ix

FIGURE 53 - SIMPLIFIED ASE BLOCK ............................................................................................................. 95
FIGURE 54 - ROLL - ATTITUDE HOLD BLOCK ................................................................................................. 96
FIGURE 55 - REMOVED SIMULINK BLOCKS..................................................................................................... 97
FIGURE 56 - INITIAL SPEC SELECTION............................................................................................................. 98
FIGURE 57 - EVALUATION OF INITIAL GAINS .................................................................................................. 99
FIGURE 58 – INITIAL OPTIMIZED BASELINE.................................................................................................. 100
FIGURE 59 – OPTIMIZED BASELINE WITH FINAL SPEC SELECTION................................................................. 101
FIGURE 60 – OPTIMIZED BASELINE WITH FINAL SPEC SELECTION AND CONFIGURATION.............................. 103
FIGURE 61 - INITIAL BATCH MODE GUI ...................................................................................................... 104
FIGURE 62 - FINAL SETUP GUI OF THE GAIN SCHEDULING CASES............................................................... 106
FIGURE 63 – INITIAL RUN MODE OPTIMIZATION.......................................................................................... 107
FIGURE 64 – HQ WINDOW OVERLAID RESULTS ........................................................................................... 108
FIGURE 65 - GAIN SCHEDULE PLOTS AGAINST VELOCITY............................................................................. 109
FIGURE 66 – A PROBLEM WITH THE DAMPING SPEC ..................................................................................... 111
FIGURE 67 - CORRECTED GAIN SCHEDULE.................................................................................................... 112
FIGURE 68 - ROBUSTNESS CHECK SETUP ...................................................................................................... 117
FIGURE 69 - ROBUSTNESS OF CRITICAL STABILITY MARGINS ....................................................................... 118
FIGURE 70 - ROBUSTNESS PLOT OF ALL STABILITY MARGINS....................................................................... 119
FIGURE 71 - OPEN-LOOP BODE RESPONSE OF RANDOM CASES...................................................................... 120
x

Acronyms
NOMENCLATURE
ASE – Automatic Stabilization Equipment
CIFER – Comprehensive Identification from Frequency Responses
CONDUIT – Control Designer’s Unified Interface
CPU – Central Processing Unit
dp – Change in design parameter
FCS – Flight Control System
kts - Knots
L0 – Collective input
R1C – Lateral input
R1S – Longitudinal input
RP – Rudder pedal input
Symbols
α – Angle of Attack
n – Normal acceleration in G’s
τ f - Rotor flap time constant
xi

1 Overview of CONDUIT
The purpose of a flight control system is not only to augment the stability of an
aircraft, but to improve its handling as well. During the early years of flight control
system development, design parametrics for dynamic stability such as the Phugoid Mode,
Short Period Mode, and n/α were used. However, these criteria did not account for
unconventional designs, nor did they necessarily improve the pilot’s opinion of the way
the aircraft handled. Thus, research was performed as a means to quantify good handling
qualities of aircraft. A rating scale was developed to rate the handling of an aircraft, the
Hooper-Carper Rating scale, shown in Figure 1.
Figure 1 - Cooper-Harper rating scale
1

This rating system was used in conjunction with flight test data using a variable
stability aircraft to create a group of handling qualities specifications, in which
measurable parameters of an aircraft’s performance could be used to predict pilot opinion
of the handling of the aircraft.
By incorporating handing qualities specifications into the design of an aircraft, it
will most likely have good handling qualities. However, there are certain consequences
involved when doing so. The process of evaluating a single spec (specification) is time
consuming, much less several specs, resulting in possibly long design cycles.
Furthermore, the presence of multiple competing specs adds another level of complexity
to the problem. Another difficulty is that if the model, control architecture, or any
component of the system changes, the entire process must be repeated. Finally, while a
system might be created that meets all necessary specifications, chances are that it is not
optimal. Trade-off studies may be developed as a means to make best use of the
available control authority, however, this can be time consuming.
In response to these difficulties, a multi-objective optimization program, called
CONSOL-OPTCAD, was developed at the University of Maryland. This program
interfaced with the MATLAB environment, using MATLAB’s system modeling
capabilities. A model following control system was developed for the UH-60, using the
CONSOL-OPTCAD multi-objective optimization to optimize the control system based
on several handling qualities specifications. In doing so, the capability of the
optimization routine was demonstrated. However, its use was still limited in that the
UH-60 problem was hard-wired into CONSOL-OPTCAD. Modifying the code to work
with a new problem involved several months of work. A variant of this effort was thus
2

created. Called GIFCOCODE, it incorporated a simple GUI with custom-made specs.
While the graphical output was an improvement from the original CONSOL-OPTCAD,
the problem was still hard-wired, making it of little use.
The program was reworked again, in order to account for these deficiencies. An
easy to use graphical interface was thus created. In addition, this new version was to be
flexible, allowing the user to quickly change the problem definition. A library of
modular specifications was created, allowing the user to pick specs for the particular
problem. This new version allowed the user to set up and optimize a problem in a matter
of hours, shortening the design cycle. Multiple competing specs could be used, as this is
accounted for in GIFCOCODE. Finally, changes in the system became inconsequential,
since the system could be evaluated in a matter of minutes. This latest evolution of the
original CONSOL-OPTCAD code was called CONDUIT (Control Designer’s Unified
Interface).
CONDUIT is a versatile design tool which allows the control engineer to rapidly
design an optimized control system, based on multiple handling qualities specifications,
in a graphical environment. The control system to be optimized is modeled using
MATLAB Simulink. Parameters of the block diagram are defined such that they may be
varied by CONSOL-OPTCAD in the optimization. Handling qualities specifications, are
represented in CONDUIT as modules, allowing the user to “plug-in” only those needed
for the particular problem. Specs are represented graphically, as shown in Figure 2, often
mirroring their appearances from their source.
3

Figure 2 - CONDUIT specs
As in the original handling qualities specifications, each spec has three levels,
Blue, Magenta, and Red, indicating the Cooper Harper Levels 1, 2, and 3 respectively.
For the sake of clarity, the three colors are represented in this document as White, Light
Grey, and Dark Grey for Levels 1, 2, and 3 respectively. As CONDUIT optimizes the
system, it plots the points on the graphs, and uses graphical means to determine their
ratings. CONDUIT also provides an array of analysis tools, for after the optimization is
finished.
4

1.1 The Structure of CONDUIT
1.1.1 Fundamental Structure
Optimization
commands
TCL
〈 Main controlling
component
〈 Graphical User
Interface
Optimization
status
Passing of data and
commands of the
current operation
COMATLAB
〈 Optimization
Optimization results
Simulation and
parameter data
MATLAB
〈 System Modeling
〈 Data Management
〈 Graphical display of
results
Figure 3 – Coding structure of CONDUIT
CONDUIT is made up of three major components. First, the main GUI is written
in the TCL scripting language and serves as the main controlling component. Most all
processes are invoked in one way or another from the TCL code. The second component
is CONSOL-OPTCAD which, in the latest version of CONDUIT, is written as a
MATLAB CMEX function and is thus renamed to COMATLAB. As it is derived from
the original CONSOL-OPTCAD code, it is the core of the optimization. However, it
does not control the optimization, but merely operates under the control of the TCL code.
While the TCL code controls almost every aspect of CONDUIT, it does not handle the
computations and data itself. Rather, CONDUIT uses the MATLAB environment, the
third component of CONDUIT, to manage all data and calculations. In addition to it
5

eing ideal for the computations necessary for control analysis, MATLAB provides the
Simulink environment, allowing the user to easily construct a model of the control
system. Finally, MATLAB provides great flexibility for graphically displaying the
results, using the many pre-existing plotting functions of the MATLAB Control Toolbox.
While these three components make up the basis of CONDUIT, there are several other
smaller components within these three which provide the functionality behind
CONDUIT. These smaller components will be discussed in the following sections, to the
extent of providing a basis for the explanation of Batch Mode. Furthermore, they will be
explained with respect to the two operating modes of CONDUIT: Setup Mode, in which
the CONDUIT problem is created, and Run Mode, which is used to optimize the problem
and analyze the results.
1.1.2 Block Diagram (Setup Mode)
All simulation is performed in the MATLAB environment. Thus, the model of
the aircraft and the control system itself must be simulated in MATLAB, using its
modeling and simulation capabilities of the MATLAB Simulink environment. Simulink
is a graphical simulation tool that allows the user to build control systems in block
diagram form.
6

Input Block
Output
Block
CONDUIT Switch
Figure 4 - The MATLAB Simulink environment
Simulink includes representations of all the common blocks found in a typical
block diagram. Building the block diagram in Simulink is a matter of assembling the
blocks, interconnecting them, and setting their values. Input and Output signals to and
from the system are incorporated using Simulink Input/Output blocks, which allow
CONDUIT to choose any input and output for a particular simulation. Furthermore,
specialized Simulink switch blocks provide the capability for CONDUIT to select
different control architectures or feedback paths. Thus, by configuring the system in such
a way, CONDUIT has great flexibility over how the simulations can be run.
1.1.3 Design Parameters (Setup Mode)
In order for CONDUIT to optimize the system, it must have the ability to alter it.
Thus, CONDUIT allows the user to select parameters of the block diagram for
COMATLAB to modify. These parameters are referred to as Design Parameters, and are
essentially MATLAB variables that can be used in any component of the block diagram.
7

They are typically used as gains, however they could be used for nearly any other
purpose.
Design Parameter
Figure 5 - Design Parameters
Design parameters are defined by simply adding them to the block diagram.
When the CONDUIT analysis, or “problem”, is opened, CONDUIT scans the block
diagram to find the design parameters. They are distinguished by the required “dp_” or
“dpp_” prefixes in their names, which define the variables as design parameters and
positive-valued design parameters, respectively.
1.1.4 Specs (Setup Mode)
The handling qualities specifications, or “specs” for short, represent the actual
government handling qualities specifications, such as ADS-33 or MIL-STD-1797. The
CONDUIT specs are modular, so that any combination of specs can be assigned to a
CONDUIT problem by just “plugging them in”, metaphorically speaking. Each spec is
self-contained, that is, they contain all the code required to evaluate the aircraft and plot
the results, as specified by each government handling qualities specification.
8

Level 3
Level 2
Constraint Type
Level 1
Test Point
Reference
Figure 6 - A CONDUIT Spec
A CONDUIT spec is represented in a graphical manner, most often resembling
that of the original government handling qualities specification. The spec of Figure 6
was taken from the ADS-33D document. A spec will have two or more regions,
representing Levels 1, 2, and 3 of the Cooper-Harper rating scale.
CONDUIT specs are not limited to those published in government publications
such as ADS-33 or MIL-STD-1797. A large number of CONDUIT specs have been
created specifically for CONDUIT. These specs are used to properly constrain the
optimization of a problem. For example, if a control system is modeled in CONDUIT
and only the ADS-33 specs were used, CONDUIT may very well optimize the system at
the expense of increased bandwidth to satisfy the performance specs. Or worse, it may
sacrifice the stability of the aircraft. Thus, two additional classes of specs were created.
The first class of specs, commonly referred to as “Stability Specs”, are used to ensure
9

stability of the system, checking parameters such as the eigenvalues, the phase margin,
and the gain margin of the system. The other class is used to improve the efficiency of
the system, reducing the bandwidth or the required actuator energy of the system.
COMATLAB uses a multi-objective optimization routine, which allows it to
optimize several competing specs. However, this also means that all specs are treated
equally by COMATLAB. Thus, a spec for a trivial parameter would be competing on the
same level as a spec that ensures stability. To account for this, COMATLAB was written
with the capability to rank the importance of specs. While the specs can be assigned to
any one of five constraints, only three of them are used by COMATLAB. The
constraints are as follows, in order of importance:
• Hard Constraints – The highest priority, the ratings of all other specs are to be
compromised to push the Hard Constraints into Level 1. This constraint is usually
reserved for stability specs, such as the Eigenvalues or Stability Margins specs.
• Soft Constraints – Soft constraints follow the hard constraints in priority. They are
only considered once all hard constraints have been satisfied in Level 1. At that time,
COMATLAB tries to move them into Level 1. In doing so, COMATLAB is not
allowed to compromise the Level 1 ratings of the hard constraints, however, the Level
ratings of all other specs may be sacrificed to ensure Level 1 ratings for the soft
constraints. The soft constraint is usually given to specs that ensure the performance
of an aircraft, such as many found in ADS-33 or MIL-STD-1797.
• Objective Constraints – The lowest priority of the constraints, objective specs are
only considered once all hard and soft constraints have been satisfied in Level 1. As
with the soft constraint, objective specs may not be improved at the expense of the
10

higher priority hard and soft constraint specs. Objective specs are reserved for energy
or bandwidth specs, which are used to optimize a stable, performing control system.
Once all objective specs have been pushed to Level 1, COMATLAB will continue to
try to push these specs into Level 1 as far as possible.
• Summed Objective Constraints – The summed objective is not a new constraint type,
but a subset of the Objective constraint. Its purpose is best explained through
example. If two soft constraints were related in such a way that each spec could only
benefit through the degradation of the other, then COMATLAB would exploit the
ratings of the lower priority objective specs to improve the ratings of the soft
constraints. This luxury is not available with the objective specs, since there are no
lower priority specs to exploit. Thus, to account for this situation, the summed
objective constraint was created. The results of all summed objective specs are added
together, creating a new “spec” for COMATLAB. By grouping the specs together
this way, the competing specs are forced to work together to improve the collective of
summed objective specs.
• Check Only Specs – Specs of this class are not passed to COMATLAB for
optimization. However, they are evaluated at each iteration and exist merely so that
the user can view the results of the spec, for reference only.
In addition to the classifications and constraint types of specs, there are five types
of specs, delimited by the method used to calculate the results:
• Time Point – The time response of the system is used to calculate a single point to
plot on the spec. Time specs require an input signal.
11

• Time Line – The time response is plotted directly on the spec and must stay within a
region defined by the spec. Time Line specs also require input signals.
• Frequency Point – The frequency response of the system is used to calculate a single
point, which is plotted on the spec.
• Frequency Time – The same as a Time Line spec, but the frequency response (Bode
plot) is used.
• LOES (Low Order Equivalent System) – These specs use model identification
techniques similar to those used in CIFER, to fit a low order transfer function to the
high order system. The form of the low order transfer function is selected by the user,
depending on the parameters required for the spec calculation. The identified
parameters of this low order system are then used to calculate the results, and a single
point is plotted on the spec.
Inports Outports Switch Flags
Symbols
X,Y plot values
Spec Axes Limits
Spec Options
Input Signal
LOES Profiles
Constraint Type
Figure 7 - Configuring a spec
12

To configure the spec to the current CONDUIT problem, parameters such as the
inputs and outputs from the block diagram, CONDUIT switches, the input signal, the
LOES low order transfer function form, spec options, and other parameters. These can
all be seen in the HQ Editor in Figure 7, which is used to configure specs. It is shown
here only to demonstrate the parameters which can be changed.
1.1.5 HQ Window (Setup Mode)
Figure 8 - HQ Window
The specs selected for a CONDUIT problem are displayed in the HQ Window
(Handling Qualities Window), shown above, which serves as the interface to the specs. It
is used in setup mode to add and configure specs, and has further functionality in Run
Mode.
13

1.1.6 Init File (Setup Mode)
One last functionality is required of CONDUIT to make it truly versatile. The
explanation of the features of CONDUIT so far has accounted for most of the capability
needed to optimize a problem. However, the designers of CONDUIT had the foresight to
realize that it might be helpful to run a user defined MATLAB script at the start of the
problem, as a “catch all”, to account for any additional settings. This script is called the
Init File (Initialization File) and is used to set any miscellaneous parameters that are not
set elsewhere.
Three parameters of CONDUIT are set in the Init file, the time step used in linear
simulations, input signals to be used in simulations, and CONDUIT switches to be used
in the block diagram. All three parameters are defined as global variables, which are read
by CONDUIT, and all use a specific form for their names.
Any other required parameters can be set by direct assignment, or by calling user
defined MATLAB scripts and functions. For example, the state space matrices of the
aircraft are typically loaded into global variables to be used in the block diagram. By
using variables for the four matrices, it saves the user the trouble of copying these
potentially large matrices into one-line fields within the state space block in Simulink. It
also allows the state space model to be easily modified by the user. In the case of the
SH-2G gain scheduling to be discussed later in this paper, eleven different flight
conditions were investigated, but only three identified state space models were available.
At the start of each problem (referred to as a “case” in Batch Mode), the state space
matrices of the three known flight conditions were loaded, and an interpolation method
was used to calculate the matrices to be used for the remaining 8 cases. The resulting
14

matrices were then assigned to variables used in the state space block of the Simulink
block diagram. This was all accomplished using functions in the Init file.
1.1.7 HQ Window (Run Mode)
In Run Mode, the HQ Window is used to view the results of an evaluation or
optimization. The results are plotted as either points or lines, depending on the type of
spec, shown in Figure 8. By right clicking on a spec, a support plot will be created as in
Figure 9, which displays detailed information about the simulation results.
Figure 9 - Support plot
15

1.1.8 Pcomb (Run Mode)
Figure 10 – Pcomb window
The Pcomb, or performace comb, displays the level ratings of each of the specs. It
is referred to as a “comb” because of the appearance of the multiple bar graphs of the
window. Each row of the Pcomb represents a single simulation that is plotted on the HQ
Window. The background of the bar plot, on the right half of the window, is split into
three sections. The left section represents Level 1, the middle Level 2, and the right,
Level 3. The bar is drawn starting on the left edge. The distance which a bar extends
into a region represents the relative distance into that level. Additionally, the color of the
bar reflects the level rating as well, following the same Level color scheme of the specs.
In the case of Figure 10, all constraints are blue, indicating Level 1 performance, except
for one. Of the Level 1 constraints, the OvsPiF3 spec is just within the Level 1 region,
the BnwRoF2 spec has a slightly larger margin, while the remaining specs are all well
within Level 1. The single red bar of HldNmH1 indicates that this constraint is in
Level 3, and the length extending off the right of the plot indicates that it is far into that
16

level. The numbers over the bar plots represent the distances into each level region as
well, but are not important in this discussion.
1.1.9 Design Parameters Window (Run Mode)
The design parameters are the means by which COMATLAB optimizes the
problem. They are displayed by CONDUIT by the Design Parameters Window, shown
in Figure 11.
Figure 11 - Design Parameters window
In this window, the design parameters are arranged vertically. On the left is the
name of each design parameter. The center column shows the actual value, while the
column on the right shows the frozen state of the parameter. “Freezing” a parameter has
the effect of removing it from the set of design parameters that COMATLAB can vary in
an optimization. The value remains constant at the current value. In addition to
displaying the value and frozen state of the design parameters, the design parameters
window allows the user to change the values as well.
17

1.2 Method of Optimization
A CONDUIT optimization is an iterative process. The optimization starts with an
evaluation of the system with the initial design parameters. This evaluation becomes
iteration zero and serves as a starting point. COMATLAB is then called. It investigates
the system at the starting point to determine how to vary the design parameters to better
the system. The design parameters are then changed to these new values, only slightly
different from the previous values, creating a new iteration. COMATLAB is called
again, and the process repeats. Thus, the optimization starts with a given set of design
parameters, and slowly iterates towards the final values.
To understand certain concepts of CONDUIT and Batch Mode, the means by
which COMATLAB evaluates the system and determines the best change in design
parameters must be explained. A simple example might help explain this process:
Cost
Vectors of Maximum Gradient
dpp_X
dpp_Y
Figure 12 - 2D Gradient visualization (hypothetical)
18

The plot in the figure above represents a hypothetical gradient of a two-constraint
system. The X and Y axes each represent a design parameter, while the Z axis represents
the cost of the system. The contour of this surface is constant for a given problem and is
defined by the constraints of the problem (the specs). Thus, for any given set of design
parameters (any X,Y coordinate), the gradient (slope of the cost function) can be
calculated, indicated by the black arrows in the figure. The optimization would start out
at a position on the surface, located by the design parameter values. It is then a matter of
finding the direction of the largest negative slope (shown as arrows on the plot), since
moving in this direction would reduce the cost of the system. Once the direction is
found, it must be determined how far to “step” in that direction. If the design point were
on the edge of a local minimum “pit”, moving too far towards the center of the pit might
step past the minimum and up the other side, as illustrated in Figure 13.
Cost
dx 2
dx 1
C 1
C 3
C MIN
dpp_X
dpp_Y
Figure 13 - Conceptual step size calculation
The distance dx 1 represents the ideal distance, while the step size dx 2 shows the
results of a step size that is too large.
19

Thus, different step sizes would be checked to determine the optimal length.
After the direction and the step size have been determined, the optimization routine sets
the design parameters to their new values. The process is then repeated for each iteration
until no further improvement can be made. A few things should be noted at this point.
First, there is always an absolute minimum to the system, however there may also be
several local minimums. Which minimum COMATLAB moves towards depends on the
starting point, as well as the contour of the surface. Thus, the selection of the specs used
(to shape the surface), as well as the selection of the starting design parameters (to define
the starting point) is critical.
This simplified example is essentially what COMATLAB does during an
optimization. However, the actual process is much more complicated. The design space
is actually n-dimensional, and the actual methods for calculating the search direction and
step size are also more complicated. A full explanation of the theory behind these
processes is beyond the scope of this paper, however, a simple description of procedure is
as follows:
When COMATLAB is called, it performs a series of simulations to determine the
gradient of the system. The gradient is analogous to the slope of the cost function at that
given point, in n dimensions. Using the gradient, it then finds the direction in design
space with the largest negative change in cost. This direction is referred to as the “search
direction”. COMATLAB will then try to determine how far to move along this direction,
referred to as the “step size”. Determining the search direction and step size can take
many simulations, and it is not guaranteed that the first search direction found will be
used, since a lower gradient direction might prove better with a different step size. Once
20

the search direction and step size have been determined, the design parameters are
changed accordingly and COMATLAB exits.
As mentioned earlier, CONDUIT has a priority hierarchy for specs. In order to
accommodate for these priorities in the optimization, COMATLAB changes the active
constraints of the problem based on the current conditions of the specs. There are three
possible conditions, referred to as Phases, that correspond to the three spec constraint
types. They are listed below in the order that they would normally be encountered during
an optimization.
• Phase 1 – Characterized as having one hard constraint not satisfied in Level 1, this
phase concentrates only on the hard constraints, attempting to push them into
Level 1. In doing so, COMATLAB will sacrifice the ratings of soft and objective
specs, if necessary.
• Phase 2 – In this phase, all hard constraints have been satisfied in Level 1,
however one or more soft constraints have not. Thus, this phase will concentrate
on the soft constraints, pushing them into Level 1 at the expense of the objective
specs but without violating the Level 1 ratings of the hard constraints.
• Phase 3 – The final phase of a successful optimization, the optimization enters
this phase when all hard and soft constraints have been moved into Level 1.
Objective specs may or may not be Level 1. The optimization continues in this
phase, pushing the objective specs as far as possible into Level 1. As with the
previous phases, COMATLAB will not allow the hard or soft constraints to be
pushed out of Level 1 to improve objective specs. As a result, COMATLAB will
degrade the hard and soft constraints right up to the Level 1/2 border, in an
21

attempt to push the objective specs as far into Level 1 as possible. The
optimization continues until COMATLAB can no longer move the objective
specs.
During an optimization, COMATLAB will eventually not be able to determine a
search direction and step size that will improve the system. This could occur in any
phase, and any iteration number. COMATLAB will then exit, indicating the reason for
stopping:
• “A proper search direction cannot be found.” - In this case, the optimization routine
can’t determine how to modify the design parameters to improve the system. This is
usually caused by COMATLAB having too many degrees of freedom in which to
move, and thus the problem of finding a search direction becomes indeterminate. By
reducing the number of active design parameters, this could be remedied. However,
this end message can also be a result of invalid design parameters, those that would
result with invalid results from the specs. Thus, to remedy this problem, the initial
design parameters should be refined, and a sensitivity analysis should be run to freeze
design parameters.
• “A local minimum has been obtained.” – This message indicates that the system has
been optimized, but that it is not necessarily the best solution. As stated earlier, there
may be several local minimums, while there is only one absolute minimum. In the
case of this exit message, COMATLAB has determined that the current point is one
of several local minimums, and that it could not find an absolute minimum.
• “A feasible point is not found to satisfy all hard constraints.” – This indicates that
given the initial starting point, the optimization routine could not determine any
22

change in the design parameters that would push all of the Hard constraints into
Level 1. This could be a result of the starting point being too far from a valid
solution, but the reason might also lie in the problem setup.
• “Further decrease of the most active specifications cannot be achieved.” – This
message simply indicates that COMATLAB can’t determine a search direction that
will improve the system.
• “The design parameters haven’t varied in the last 3 iterations.” – Just as the message
says, if CONDUIT can’t move the design parameters from their current value in three
iterations, and this point is not a local or absolute minimum, then CONDUIT stops
with this message.
• “Congratulations… “ – This message indicates that the system is fully optimized,
with all specs in Level 1. This is different from the local minimum message above in
that the optimization routine has determined this point to be the absolute minimum, or
best design point for the system.
1.3 Sensitivity Tools
As a CONDUIT optimization progresses, COMATLAB can get stuck and quit
with one of the messages listed in the previous section. If the message indicates that the
optimization stopped prematurely, it could mean a problem with the setup of the
CONDUIT problem itself, or a problem with the active design parameters. If too many
unnecessary design parameters are active, COMATLAB may have trouble determining
the search direction, as there are too many degrees of freedom. Thus, the system is
indeterminate. To help the user refine the list of design parameters, CONDUIT provides
23

the Sensitivity Tools, which are used to determine insensitive and correlated parameters
to freeze.
1.3.1 Insensitive Parameters
There are two types of design parameters that adversely affect the success of an
optimization. The first type being insensitive parameters, in which the parameter has
little or no effect on the results of the system. Going back to the simple two-dimensional
system, an insensitive parameter could be represented by the figure below.
cost=0
Cost
cost=max
dpp_insensitive
dpp_sensitive
Figure 14 - Insensitive parameter
Of the two design parameters represented in the figure, moving along the axis of
the insensitive parameter does not change the cost value of the system. Moving in the
direction of the sensitive parameter axis does make a difference. In this simple example,
the search direction is quickly apparent to the casual observer. COMATLAB would have
24

no problem with this simple case either, but when this example is extended to many more
dimensions, a simple problem can become complex very quickly. Thus, it is necessary to
remove insensitive parameters, such as the one in represented in Figure 14, in order to
refine the problem and allow COMATLAB to determine a solution. The details of doing
such are to be discussed shortly.
An alternative explanation of an insensitive parameter could be demonstrated in
block diagram form. Figure 15 shows the block diagram representation of an insensitive
parameter. The insensitive parameter is isolated and thus, has no way to alter the system.
While this exact representation would never be seen in an actual block diagram, the
equivalent may occur under some circumstances. For instance, if all of the critical specs
for the current phase are longitudinal specs, design parameters of the other axes may not
affect the system at all, provided there is little coupling in the system. Other conditions
could contribute to the insensitivity of a parameter as well.
Insensitive Parameter
Figure 15 - Block diagram representation of an insensitive parameter
25

The Sensitivity Tools looks at the effects of design parameters on the constraints.
The design parameters and specs to use for the analysis are chosen, and are typically
chosen to reflect the current active design parameters and specs. The sensitivity tools
operates by calculating the gradient matrix for the chosen specs and design parameters,
from which the effects of individual design parameters can be determined. The output is
scaled to percentage values, plotted as in Figure 16.
Figure 16 - Insensitive parameters
The rule of thumb with insensitive parameters is that any parameter over 20%
should be frozen. In the case of the figure above, the dpp_RF and dpp_RAHSF
parameters would be frozen. By removing the unnecessary degrees of freedom,
26

COMATLAB will stand a better chance at determining a search direction and continuing
the optimization.
1.3.2 Correlated Parameters
The second class of parameters that will hold up an optimization are correlated
parameters. Put simply, correlated parameters are redundant parameters for the current
design point. The figure below describes this problem in block diagram form.
(a)
(b)
Figure 17 - Block diagram representation of correlated parameters
Just as with the block diagram representation of insensitive parameters, this
representation would not appear in a typical block diagram exactly as above, but it might
exist in a similar form. Looking at the block diagram of Figure 17a, it is clear that the
two gains perform the same function. Thus, one of the two parameters is unnecessary
and can be frozen.
To check for correlated parameters, the sensitivity tools performs the same
calculation of the gradient matrix as with the insensitivity analysis, but uses the values to
calculate the Cramer Rao percentage of each design parameter. The Cramer Rao
percentages can be thought of as the level correlation of a parameter to another.
Insensitive parameters must be frozen prior to this analysis, otherwise they would appear
27

to have very high Cramer Rao percentages. Since a correlated design parameter by
definition is correlated with another parameter, all design correlated design parameters
will be matched with at least one other design parameter of a similar magnitude. As
shown in Figure 17b, it is possible for a design parameter to be correlated to more than
one design parameter. To resolve the correlation, all but one of the design parameters in
a group must be frozen. As with the insensitive parameters, freezing these parameters
will reduce the degrees of freedom, improving the chances of COMATLAB to continue
the optimization.
Sensitivity Tools provides the user with a means to analyze the control system for
insensitive and correlated parameters. In identifying and freezing these parameters, the
complexity of the problem is reduced. Thus, Sensitivity Tools provides the user with the
means to revive a CONDUIT optimization that has stopped due to insensitive or
correlated parameters.
28

2 Development of Batch Mode
2.1 Introduction
While CONDUIT is a very powerful design tool, it is limited in that it can only
analyze an aircraft at a single design point. Running or analyzing more than one problem
requires a significant amount of user intervention. Batch Mode was created with the
intent of providing the capability to run multiple CONDUIT problems automatically. In
order to accomplish this goal, three requirements had to be addressed. First, Batch Mode
had to have the ability to create several CONDUIT problems. In doing so, it also had to
have the capability to modify every parameter of a problem which might be varied by a
user in CONDUIT, when creating multiple cases to gain schedule, etc…. The second
requirement of Batch Mode was that it had to be able to automatically run the multiple
cases in such a way as to minimize user intervention. Finally, Batch Mode had to
incorporate the means to quickly and effectively view the results of a large number of
CONDUIT problems.
These three requirements, dealing with the creation, execution, and analysis of
multiple CONDUIT problems, were developed into separate modes, henceforth to be
referred to as Setup Mode, Run Mode, and Analysis Mode respectively.
2.2 Setup Mode
As mentioned in the Batch Mode introduction, the purpose of Setup Mode is to
create multiple CONDUIT problems. To do so, it had to be decided how the multiple
problems were to be organized, and how they were to be saved on disk. Furthermore, the
parameters available to be varied between cases had to also be defined. Finally, the
29

means to create, modify, and save the multiple cases had to be developed based on the
criteria above.
2.2.1 Creating the Batch Problem
Batch Mode does not replicate all the functionality of the CONDUIT GUI. Doing
so would not only be redundant, but unnecessary, since varying certain parameters would
cause the cases to become unrelated. Since Batch Mode can not create new CONDUIT
cases, it uses a previously created CONDUIT problem which it modifies to create the
remainder of the problems. This “template” problem is created by the user prior to
entering Batch Mode. Typically, it is set up as one of the cases to be created and run in
Batch Mode. The case is then fully optimized in CONDUIT to ensure that the template
problem is set up so that it will properly optimize, and to obtain a starting set of design
parameters for all other cases.
Once the template case has been created and optimized, a new directory is
created. The template file is then copied to the new directory. Upon opening Batch
Mode, the user picks the name of the template file in the newly created directory. The
name of the template file becomes the name of the “Batch Problem”, while the new
directory and all files and directories under it, make up the Batch Problem itself.
2.2.2 Modifying the Cases
Using the Setup Mode GUI, the user can then modify all parameters useful to a
multi-problem analysis. These parameters include the following:
30

HQ Window – The design margin for the specs and the spec options can be varied.
Parameters such as the number and definition of specs can’t be changed, as this would
prevent any meaningful comparison of the results.
Design Parameters – The starting design parameter values and their frozen states can be
defined.
Block Diagram – Batch Mode allows for different block diagrams to be used to permit
the comparison of different control architectures. Additionally, variables in the block
diagram can be set through the Init file, to be described next.
Init File – The Init file serves as the “catch-all”, allowing for nearly any other variation
not mentioned above. Switches, input signals, variables, functions, scripts, etc… can be
utilized to vary the cases as needed.
2.2.3 Saving the Cases
Once all of the cases have been created and modified, they must be saved to disk.
In creating the means to do so, two options were considered.
The first method was to save only the changes that were needed to vary the
template problem for each case. At run time, the template case would be modified to the
configuration of the specific case. The results would be cataloged and saved to a file in
the Batch Problem directory.
The second method was to create subdirectories, one for each case. The template
problem would them be modified to the variations of the particular case, and copied to
the appropriate directory. Thus, each subdirectory would represent an individual case,
and the files within that directory would be a complete CONDUIT problem capable of
31

eing opened by a regular session of CONDUIT. The running and saving of the problem
would be done in the same way as in CONDUIT.
Each method has its benefits and deficiencies. The first method would take up
less disk space, however the running and saving of the problem would be more complex.
Conversely, the second method would require much more disk space, the amount
depending on the number of cases. A typical CONDUIT problem might take up 1-2
megabytes of disk space after the results have been saved. Even with a large number of
cases, however, the amount of space needed is still reasonable, considering the size of
modern hard drives.
Saving multiple CONDUIT problems would have many more advantages, though.
The organization of the cases is much clearer, and the components of the individual cases
can be seen by simply viewing the Batch Problem directory. Furthermore, by using this
method, the running of the cases would be greatly simplified, as the code need only to
switch to a particular directory and use the run code already developed for CONDUIT.
Finally, the second method is more versatile in that many of the functions of Batch Mode
can be performed by hand. The user may open and run the individual cases using
CONDUIT, delete cases by deleting their respective subdirectories, or create new cases
by copying a case subdirectory and its contents to a new subdirectory.
32

Batch Problem Directory
sh2glat.cdt
sh2glat.int
sh2glat.mdl
sh2glat.cdt
(All other files used to
create different cases)
sh2glat.cdt
sh2glat.int
sh2glat.mdl
sh2glat.cdt
hover.mat
Case 1 Directory
sh2glat.cdt
sh2glat.int
sh2glat.mdl
sh2glat.cdt
60kts.mat
Case 1 Directory
sh2glat.cdt
sh2glat.int
sh2glat.mdl
sh2glat.cdt
100kts.mat
Case 1 Directory
Figure 18 - Batch Problem file and directory structure
Thus, when a Batch Problem is created, Batch Mode creates a directory for each
case, copies files of the template problem to each directory, and modifies them according
to the variations defined by the user. A CONDUIT problem is composed of a specific
group of files, however other files are often included in addition. These extra files often
are used to store the aircraft dynamics model and, in the case of a gain scheduled
problem, scripts may also be included which modify the stability derivatives according to
the flight condition. Batch mode also has its own files, using the extension “.b”, to which
are saved all parameters unique to Batch Mode. All of these additional files are copied to
the case directory as well.
2.2.4 Batch Mode GUI Fundamentals
Now that the required procedures of Setup Mode have been discussed, the details
of the Graphical User Interface will be explained. The Setup Mode GUI is shown below
33

in Figure 19. The Batch Mode GUI is a unified interface, that is, all thee modes share the
same common interface. Thus, the common attributes will be discussed first, followed by
the details of Setup Mode.
Figure 19 - Setup Mode GUI
The Batch Mode GUI comprised of several sections, listed from top to bottom:
File Menu, Button Toolbar, Main Window, Mode and Status Section. The organization
of the GUI is best explained starting with the Main Window, shown in Figure 20.
34

File Menu
Button Toolbar
Main Window
Family Window
Case Number Window
Display Area
Mode Select/Status Window
Figure 20 - Main Window
The Main Window is comprised of three areas, the Display Area, the Case
Number Area, and the Family Area. The Display Area is the most dynamic of all the
GUI components, changing to suit the needs of the current mode. For instance, in Setup
Mode, it displays a window of cells to allow the user to modify the individual cases. In
Run Mode, it displays the run status of the cases, while in Analysis Mode, this window
changes to show the HQ Window, Pcomb, Design Parameter gain schedule plots, and all
other results. Figure 20 shows the Display Area in Setup Mode, displaying parameters to
be modified. Since there are more parameters to be varied than there is space in the
35

window, within each Mode, the Display Area may display more than one “window”.
This will be discussed in more detail later.
To the left of the Display Area is the Case Number Area. In this section of the
GUI, the case numbers and the names of cases are listed, the case number on the left and
the name on the right. All the cells in this area can be changed in Setup Mode by simply
editing the individual cell.
Each case is defined by a unique case number. This uniqueness is ensured
through the naming convention for the subdirectories, in which the prefix of each case
subdirectory name is the Batch Problem name, and the suffix is the case number.
The names in the column on the right are only labels. They do not represent
directory names, or any other parameter of the case. The only purpose for the names are
to give a short description by which the user may identify the characteristics of the case
in Batch Mode. For instance, in the case of a Batch Problem that is gain scheduling over
a range of velocities, the velocities might be listed in this column.
The Case Number Window remains visible throughout all modes of the Batch
GUI. Besides the uses mentioned above, it serves as a means to indicate the current case
being run in Run Mode, and allows the user to select the results for that particular case in
Analysis Mode. These details will be discussed later with their respective topics.
On the far left of the Main Window is the Family Area. Just as the name column
mentioned in the previous section, families are not used as parameters in the CONDUIT
problems of a Batch Problem. Rather, they are an organization tool for grouping similar
cases. Each Batch Problem consists of one or more families. Each family consists of one
or more cases.
36

An example of the use of several families would be if the user wished to produce
both a gain schedule, and a check for robustness of the system. The gain schedule would
be comprised of several cases, their velocities differing slightly. Several cases for the
robustness check would be created by perturbing the stability derivatives. The gain
schedule cases would be kept in one family, while the robustness cases would be kept in
another. Thus, the results of the two could be analyzed separately, and the problem
becomes very clear and organized.
The Family Area is also persistent in all aspects of the Batch GUI. In all modes,
clicking on a cell in the Family Area will display the appropriate cases in the Case
Number Area, as well as the data pertinent to the current family in the Display Area. In
Setup Mode, the name of the family can be changed by selecting the family, and then
clicking on it again to edit it.
The remainder of the Setup Mode GUI sections are much more straightforward.
The File Menu resides at the top of the Batch Mode GUI, and it behaves in the same way
as any conventional pull-down menu. It contains some of the commands used less
frequently, thus freeing up space on the remainder of the GUI. Currently, only Setup
Mode commands are listed in the menu. Three pull-down menus are available: File, Edit,
and Insert.
Figure 21 - File Menu
37

The File menu contains the commands for the loading an existing or a new Batch
Problem, the creation of a new Batch Problem on disk, and functions for quick saving
and loading. Once all parameters have been varied for each case, the user selects Create
Batch Problem from the File menu. The directories and files are then created for all
cases. This process takes anywhere from seconds to minutes, depending on the
complexity of the individual cases. Thus, the quick save and load functions were created
to save to disk only the values defined in the Batch Mode GUI, allowing the data to be
saved in less than a second. Batch Mode may then be reopened at a later date, and the
quick load function can be used to restore the settings of the Batch Mode GUI to continue
the setup of a problem.
The Edit menu allows the user to copy, paste, and create series of cases. This
functionality is not part of the current version of Batch Mode, but will be included in
future versions. Further discussion of the limitations of this version of Batch Mode will
be discussed at the end of the Setup Mode GUI section.
To the right of the Edit menu is the Insert menu, which gives the user the option
to add new cases or families to the current Batch Problem. The GUI for these two
functions are shown below.
Figure 22 - Insert Family and Case Interfaces
38

The Insert Family GUI, on the left in Figure 22, consists simply of a box to enter
the new family name. Clicking on OK will add the family to the list of current families.
On the right hand side of the figure is the Insert Cases GUI, which is used to create new
cases. The user may select which family to insert the cases and the number of cases to
add. In addition to this, the user may choose to insert these new cases using the default
values, or the current settings of another case. If the settings of another case are to be
copied, all parameters but the case number are copied.
Window Selection Buttons
Window Specific Functions
Button Toolbar
Figure 23 - Button Toolbar
Just below the File Menu is the Button Toolbar. This row of buttons lists all
possible commands of the current Mode. The buttons on the left half are used to select
the current “window”. In the same way as the Batch Mode GUI is split into three modes,
39

Setup, Run, and Analysis, so are the each of these modes split up into sub-sections.
These sub-sections are referred to as “windows”. The details of the windows will be left
to later discussion, but for now, they should be thought of as being views of different sets
of data, that appear in the Display Area of the Main Window. The window selection
buttons are visible at all times within their respective modes, and change when the mode
is switched. On the right half of the Button Toolbar are buttons, sliders, or text specific
to the current window. These objects remain visible only in their respective windows.
They provide functionality to the current window.
The two final objects of the Batch GUI are located at the bottom of the Batch
Mode window. On the left hand side are the Mode Buttons. Clicking on the buttons will
switch Batch Mode into the respective modes. On the bottom right of the Batch Mode
GUI is the Status Window. This window shows the current status of Batch Mode. When
Batch Mode is writing the Batch Problem to file, running the Batch Problem, or when
any other time consuming process is running, the current status of the process is detailed
in this window.
2.2.5 Setup Mode GUI
As mentioned earlier, the intent of Setup Mode was to allow the user to modify
any parameter that could be modified within CONDUIT, constraining the functionality
limitations to only those variations deemed unnecessary in a multi-problem CONDUIT
analysis. In creating this list of parameters to vary, it was quickly determined that
multiple windows had to be used to organize all parameters. Thus, five windows were
conceptualized for Setup Mode:
40

• General (parameters) – This window would provide the user with the ability to vary
parameters which are typically required in a CONDUIT problem, such as the design
margin.
• Design Parameters – The Design Parameters window was enables the user to select
the values of the design parameters for each case, and their initial frozen states.
• Spec Options – Used to set the spec options for every spec of every case.
• Gain Schedule Parameters - The Gain Schedule Parameters window allows the user to
create constants to be used within the Batch Mode GUI.
• User Defined - Allows the user to create functions, variables, constants, switches,
etc… within the Init file.
Batch Mode is to be eventually incorporated into CONDUIT. Thus, from the start
of the design conceptualization, no compromises were made to its capabilities. When it
came time to start development, preliminary time schedule estimates indicated that the
project was to take twice as long as expected. Thus, for the sake of the time limitations,
only certain capabilities were incorporated. Those parameters incorporated in this project
include the General and Parameter windows in Setup Mode, the Run Mode, and the HQ
Window and Gain Schedule windows in Analysis Mode.
The Display Area of the General Window is pictured below in Figure 24. The
window is a spreadsheet, with the individual cases defined by the rows, and the
parameters along the columns. Six parameters may be set using this window listed below:
41

Figure 24 - General setup window
• Init String – This parameter allows the user to insert a string on the first line of the
Init file. This string may be of any length, and can contain several lines of MATLAB
code, separated by semicolons. An additional feature of this column is that the user
may use the “#” character anywhere in the cell to represent the case number. Thus,
when the case is created on disk and the string is inserted into the Init file, all “#”
symbols will be converted to the actual number of the current case. Through the use
of the Init String, the user has the ability to make up for most of the limitations of
Batch Mode in its current development state. Eventually, with the advent of the User
Defined window, this column will be removed.
• Block Diagram – This cell allows the user to select the block diagram used for the
particular case. Typically, a single block diagram would be used for all cases.
However, the option still remains. When the Batch Problem is created, this file is
copied to the case subdirectory and renamed, if it does not match the batch problem
name already. A valid filename must be used in this field.
• Run Case – The Run Case column determines whether or not the particular case is to
be optimized in Run Mode. Thus, if a new case is added to a previously run Batch
42

Problem, the user can deselect the original cases so they are not run again. The value
of the cell is toggled Yes and No by clicking on the button in the cell.
• Stop At Phase – When running a CONDUIT problem, the user can opt to run the
problem for a number of iterations, or choose to stop the optimization when certain
conditions occur. It is the second of these options that is enabled with this cell. By
entering a 2, 3, or 0, the user can instruct Batch Mode to run the particular case until
the optimization has reached Phase 2, Phase 3, or when the dp=0 condition has been
reached, respectively.
• Number of Iterations to Run – The second method of stopping a CONDUIT run is to
specify a number of iterations to run. In Batch Mode, this is accomplished by
entering a value in the Number of Iterations to Run cell. If a value of zero is used, the
system will be evaluated at the current design point, but not optimized. As in
CONDUIT, either the number of iterations or the stop condition can be used, but not
both. Thus, when the user clicks on the Number of Iterations to Run cell, the Stop At
Phase cell will be disabled, and vice versa.
• Design Margin – This column sets the design margin of the problem. Just as in
CONDUIT, a valid number from 0-1 must be specified.
It might be noted that the column widths of the General Window seem
abnormally wide, and that the GUI does not appear to use the window space effectively.
However, this same window must be used to display the same HQ Window information
as in CONDUIT, along with every other output window of CONDUIT. Thus, when the
Batch Mode GUI was designed, it was done in such a way as to maximize the size of the
Display Area of the Main Window. An additional comment that is often brought up by
43

the casual observer is that since the window is so large for these few parameters, that they
should be incorporated with other parameters from different windows. However, all
other windows have a variable number of parameters, which with a larger number of
parameters would require as much space as possible. Adding the general parameters
would only take away from that space. Thus, while the design might not be ideal for all
windows, it is the best compromise considering the limitations.
Figure 25 – Gain Schedule Parameter setup window
The second Setup Mode window developed was the Gain Schedule Parameter
window, shown in Figure 25. In this window, the user may define constants to be used
elsewhere in the Batch Mode GUI. These constants are much like the name column in
the Case Number Area, in that they do not directly affect any CONDUIT setting. Rather,
they are accessed through other areas of the Batch GUI. Specifically, they can be used as
44

the abscissa in the gain schedule plots of Analysis Mode. Thus, gain schedule plots can
be made against the case number, velocity, angle of attack, or any other parameter which
is defined in this section. In addition to this, these values will eventually be referenced as
constants by the User Defined setup window. For example, if a column title from the
Parameter window were to be passed to a function declared in the User Defined window,
the value of the Parameter for that particular case would be used in place of the column
title name.
By default, the Parameter window initially has only the case number listed. This
value can not be removed or edited. To add parameters, the user would press the
Add/Remove Parameter button on the Button Toolbar. A small window will appear, as
shown in Figure 26.
Figure 26 - Add/Edit/Remove/ Parameter GUI
Using this GUI, the user can create a new column, remove an existing column, or
edit the name of an existing column. The action to be performed is defined by the top
pull-down menu of the window. If a parameter is to be edited or removed, the Field pulldown
window would be used to select one of the current parameters. The Name edit box
is used to specify the name of a new parameter, or the new name of the edited parameter.
45

Once the new column is added, the user may define values for each case. If a cell is left
blank or with the default value of “-“, that particular case will be excluded from the cases
used in a gain schedule plot.
2.2.6 Constructing A Batch Problem
Thus, to put a perspective on how each component works in the construction of a
Batch Problem, a typical problem would be created as such: The user would first create
and optimize a CONDUIT problem to serve as the template of the Batch Problem.
Typically, this template problem would be created so that it is the best match of all of the
cases. A new directory would be created and the template problem would be copied
there. Batch Mode would be started, and the template case in the newly created directory
would be selected.
Upon starting Batch Mode, the GUI would contain one case, the template. The
user would then create however many families deemed necessary, and create any number
of cases in each family. The settings for the cases would then be edited using the Batch
Mode GUI. Once all cases were configured, the Create Batch Problem command would
be selected under the File Menu. Batch Mode would then create subdirectories for each
case, modify the files that make up the individual problems, and copy these files to the
individual subdirectories. Thus, the Batch Problem will have been created, the
subdirectories each containing individual CONDUIT problems. The next step is to
switch to Run Mode to optimize or evaluate the Batch Problem.
46

2.3 Run Mode
The object of the Run Mode is to provide the ability to run multiple CONDUIT
problems in such a way as to minimize user intervention. In developing this capability, a
method of running the multiple problems had to be defined, taking into consideration
several possibilities. The process of running the cases also had to be developed in such a
way that it was completely automatic. Furthermore, it also had to provide sufficient
feedback to the user, thus, the GUI was developed to display the results and current status
of the cases.
2.3.1 Run Methods
In the preliminary planning for Run Mode, several methods of running the cases
were considered. Primarily, these methods dealt with how to actually run the multiple
cases. One possibility was to simply run the cases in sequence, one at a time. An
alternate method would be to run multiple cases at once, taking advantage of the
capabilities of multi-processor machines. However, most of the capability required to
control multiple CPUs was removed from MATLAB in the latest release. Thus the
sequential method was chosen.
The secondary consideration to the run method dealt with how best to use the
design parameters to optimize multiple cases. The first idea that was proposed was to
start the first case with the design parameters assigned to it. After that case has been
optimized, the design parameters would be passed as the starting parameters of the next
case. Thus, if a gain schedule were done in small increments, each case would start with
design parameters close to the optimized values, theoretically speaking. While this
method would probably work well under the right conditions, those conditions are very
47

specific. The method fails when the cases are not related by such a pattern. Also, the
method requires that each preceding case ran successfully. Thus, it was thought that
these conditions were too specific and that it would be best if the design parameters
weren’t passed in this way. Instead, it was decided to use the design parameters from the
initial optimized case as the starting point for each case, unless otherwise specified in the
Design Parameters Setup window.
2.3.2 Running A Case
The method used in the running of the cases of a Batch Problem is very similar to
the method used by CONDUIT. In Batch Mode, however, the process is all automated.
Prior to an optimization, the user would set the run order of the cases. Upon
starting the run of the cases, Batch Mode creates a list of cases to be run, and orders them
based on the run order. As the Batch Problem is run, it progresses through this list
running each case sequentially.
For each case, the run sequence mirrors the processes of a CONDUIT
optimization. It does not run the cases in CONDUIT, but uses equivalent code, running
the problems entirely in MATLAB. By divorcing Batch Mode from CONDUIT, it can be
run without user intervention, and without the need for the CONDUIT GUI. In fact,
Batch Mode has been tested and run entirely from a command line interface, allowing
users to log in using telnet and run Batch Problems from anywhere. While this is not
included in the current version of Batch Mode, it just goes to show the flexibility gained
by running problems in this way.
When Batch Mode starts an optimization of a case, it first switches to the
directory of the case. It then loads the problem in the same way as CONDUIT would.
48

An initial Pcomb is run, and the problem optimization is started with the appropriate stop
condition, just as it would be done manually in CONDUIT. At each iteration, the current
status is output to the Run Mode GUI. Additionally, a text file, named “RunStatus” is
created in the Batch Problem directory, which lists the current status of the run.
If an optimization stops due to an error message, Batch Mode will decide whether
or not to run an automated sensitivity analysis. It makes this decision based on the
current phase and the exit message returned from COMATLAB. If a sensitivity analysis
is to be run, Batch Mode will perform the analysis using the specs critical to the current
phase, and the non-frozen design parameters. Based on the analysis, design parameters
would then be frozen, and the optimization would continue. The process then repeats
until any of three conditions occur:
1. It is determined that a sensitivity analysis is not to be run, based on the error message
and current run conditions.
2. All design parameters were frozen as a result of the sensitivity analysis.
3. No design parameters could be frozen based on the sensitivity analysis.
After the case has been run, it is saved in the same exact manner as a regular
CONDUIT problem. The Iteration History is also saved in the standard format. In
addition to these two files, Batch Mode saves other parameters such as the optimization
end message and run order to the “.b” file of the current problem. Thus, this information
will be available to display the next time the Batch Problem is loaded.
49

2.3.3 Run Mode GUI
Figure 27 - Run Mode GUI
The figure above shows the interface for the Run Mode. It might be noted that
the basic structure of the GUI is the same as in Setup mode, and that the two differences
are in the Button Toolbar and the Display Area of the Main Window. Starting with the
Main Window, the Family Area responds in the same way as in Setup Mode. By clicking
on a family cell, the cases of the selected family will appear. The family names can not
be changed. In Run Mode, the data in the Case Number Area serves only as a reference
to the information displayed in the Display Area. As with the Family Area, neither the
case number nor the name can be changed.
The Display Area changes completely in Run Mode to reflect the information
specific to this new mode. The leftmost column, the Run Order, defines a unique number
50

used to determine the order the cases are optimized. This number can be either entered
by hand, or set using the Order Cases button, to be explained later. If the user happens to
use the same number for two separate cases, Batch Mode will automatically determine
the order of the two cases.
To the right of the Run Order column is the Phase Column. While a case is
running, the corresponding cell in this column shows the current phase of the
optimization. After the optimization of a case has finished, this column shows the final
phase reached. If a stop condition was specified in Setup Mode, such as Phase 2, Phase
3, or dp=0, this number will appear in the cell as well. The value of the phase cell will be
separated by the stop condition by a “/”, as shown in Figure 27.
The final feature of the phase column is that it changes color based on the phase
value. Just like a stoplight, Phase 1 is colored red, Phase 2 is colored yellow, and Phase 3
is colored green. By coloring the cells, the user can quickly scan a large number of cases
to determine the results of a Batch optimization.
The next column to the right is the Iteration Number column. Just as the phase
column displays the current or final phase value, so does the Iteration Number column
display the current or final iteration for each case. Additionally, if a number of iterations
to run was specified in Setup Mode, it will appear to the right of a “/” in each cell, giving
an indication as to how many more iterations are to be run.
The last column in the Display Area shows the Optimization Result Message.
When a CONDUIT optimization stops, a message is displayed showing the reason for the
end of the optimization. The result messages may indicate anything from a successful
optimization, to a completion of a number of iterations, to a case in which CONDUIT can
51

not make any improvements. As with the Phase column, the cells in this column are also
colored red, yellow, and green to indicate their merit. A message indicating a serious
problem in the particular case, such as “A feasible point is not found to satisfy all hard
constraints”, will result in a red cell. Messages that reflect cases in need of minor
alterations are colored yellow. An example would me the message: “Further decrease of
the most active specifications cannot be achieved.” Lastly, a successful optimization is
colored green. This could be due to a successful COMATLAB exit message, the
optimization reaching a specified number of iterations, or by the optimization reaching a
specified phase. As with the phase column, the coloring of the Optimization Result
Messages allows the user to evaluate the results at a glance.
The Button Toolbar changes completely between Setup and Run Mode. Unlike
the configuration in Setup Mode, Run Mode has only one “window” and thus, all buttons
in the toolbar perform actions. As implied by its name, the Run button starts the Batch
optimization. Just to the right is the Stop button, which is used to stop a currently
running Batch optimization. As in CONDUIT, pressing the stop button will stop the
optimization after the currently running iteration is finished.
The next object on the Button Toolbar is an iteration status message, listing the
current iteration of the case that is running, or the total iterations run of the last completed
case. As with the Iteration column of the Main Window, the total iterations to be run for
the particular case is listed to the right of a “/”. This total works in the same way as the
Iteration Number display of the CONDUIT GUI. If a number of iterations to run was
specified for a case, that number appears on the right of the slash. If a stop condition was
52

specified, the total number of iterations to be run is set to 1000, thus ensuring that the
optimization will reach a stop condition.
On the right hand side of the Button Toolbar is the Order Cases button. As
mentioned earlier in the description of the Run Order column of the Main Window, the
Order Cases button is an alternative way to set the values of the Run Order column. By
pressing this button, a list box opens up on the right side of the Main Window, and a
button labeled “Order Automatically” appears to the left of the Order Cases button.
Figure 28 – Ordering the cases
If the run order of any case was defined by hand, they will be displayed in the list
box, in order, from top to bottom. To add or remove a case from the run order, the user
can click on the Run Order cells. The cases will then be added or removed from the list
box. Cases can also be inserted by highlighting the insert point on the list box. If a
53

specific run order is not required, the user may have Batch Mode define the run order by
pressing the Order Automatically button.
Figure 29 - Run Status window
The last option on the Button Toolbar is the Run Status. Pressing this button
opens up a status window, shown in Figure 29, which is updated at each iteration of a
run. This window has two sections. The top section deals with the current running case,
showing the current case, family, iteration, phase, and the number of cases that have been
run up to this point. The bottom section of the window shows a history of previously run
cases. The run order, case number, name, and result message are listed for each case that
has been run.
By providing the status information in a compact window, the user can minimize
the Batch Mode Window, thus freeing up desktop space to work on other applications.
Second, due to the nature of MATLAB GUIs, the Batch Mode GUI is not refreshed until
the start of the next iteration. Thus, if another window covers up part of the Batch Mode
GUI, or the Batch Mode GUI is minimized, the text and graphics will not reappear until
54

the following iteration. The smaller size of the Run Status window would both allow the
window to remain open on the desktop, and would also lessen the chance that it is
covered up by another window. Thus, the run status information would always be
available.
Similar to the Run Status window, the Run Status file created at each iteration
displays the same information:
Running Case: 6
Family: Family 1
Iteration: 3/5
Phase: 3
Cases Run: 6/6 (100%)
RunOrder Case Name Result
1 1 Case 1 1 Iterations completed.
2 2 Case 2 2 Iterations completed.
3 3 Case 1 The optimization has reached Phase 2 or
better.
4 4 Case 1 Pcomb evaluation performed.
5 5 Case 1 The optimization has reached Phase 3.
6 6 Case 1 Running...
Figure 30 - Run Status file
The remaining GUI components are much simpler, and perform nearly the same
functions as in Setup Mode. The File Menu is inactive in Run Mode, as there are
currently no available options for this mode. The Status Window displays the status of
the current operation. While a problem is running, a brief message displays the Case and
Family of the current problem, as well as the current and total number of cases to be run.
Finally, the Mode Buttons are used to switch to a different mode, just as in Setup Mode.
2.3.4 Running A Batch Problem
After the run order has been established, and the Status Window has been opened,
the Batch optimization is then started by pressing the Run Button. At this point, the Run,
55

Order Cases, and Mode buttons all become disabled. At the same time, the Stop button
becomes active, as shown in Figure 31.
Figure 31 - The Run Mode GUI of a currently running problem
As the cases run, the GUI changes to reflect the current status, demonstrated in
Figure 31. First, the row of the running case and the family it belongs to are highlighted
in blue. The cells of the running case are updated to the current values, and the phase is
colored accordingly. The iteration number text in the Button Toolbar is also updated.
The Optimization Result Message column is updated at the end of the optimization of
each case. Finally, the Status Window at the bottom of the GUI is updated to list the
status of the run, showing the case number, name, and the number of cases currently run.
In addition to the Run Mode GUI, the Run Status window and file are updated as well.
56

2.4 Analysis Mode
The third section of Batch Mode, the Analysis Mode is analogous to the Run
Mode in CONDUIT. The intent of Analysis Mode is to provide the user with a means to
analyze all aspects of each case, thus the it must duplicate all functionality of the
CONDUIT Run Mode. Unlike the CONDUIT Run Mode, the Analysis Mode has the
additional requirement of displaying a large amount of data from multiple cases in a way
that is clear and concise. Thus, the end design has some similarities to the CONDUIT
Run Mode GUI, but most has been reworked to better display the data.
2.4.1 Fundamentals of Analysis Mode
The Analysis Mode mirrors all of the capability of CONDUIT Run Mode. Each
section of CONDUIT Run Mode is represented in Analysis Mode by an individual
window, much in the same way as in the Batch Setup Mode. The following windows are
displayed: HQ Window, Pbrush, Design Parameters, Iteration History, Sensitivity
(Analysis), Gain Schedule. As mentioned in the discussion of Setup Mode, only two
windows were developed for this version of Batch Mode, the HQ Window and Gain
Schedule Window.
The HQ Window displays the same information available on the HQ Window in
CONDUIT, with a few additions. The Batch HQ Window shows the HQ Window for
each case, just as in CONDUIT. The window is arranged such that the user may switch
rapidly between the results of the different cases. As in CONDUIT, the iteration can be
selected for each case, support plots may be viewed, and the HQ Editor window may be
opened to view the setup of each spec. Three additional functions include jump-to-phase
57

uttons, a zoom out feature, and overlaid plots. These features will be discussed in detail
in the Analysis Mode GUI section.
Level 3
(Red)
Pcomb
Distance
Value
Level 2
(Magenta)
Level 1
(Blue)
Constraints
Cases
Figure 32 – Pbrush
The Pcomb of CONDUIT will eventually be replaced in Batch Mode with the
Pbrush, which is essentially a three dimensional representation of the Pcomb. A picture
of the possible interface is shown in Figure 32 above. Basically, the Pbrush would be the
same as a Pcomb, with the third dimension expanded to show the data for each case. The
length of each bar indicates the distance into each level, as in CONDUIT. However, the
level borders are not present. Rather, the color of each bar changes to indicate the level
of each constraint. The arrangement could be rotated to view the structure at any angle.
In addition, the numeric distance values from the Pcomb are written on the top of each
58

ar. (Only displayed on one bar in the figure) Thus, the user could snap to a top view to
clearly display the values for all cases.
The next three windows of Analysis Mode will replicate the features of their
respective displays in CONDUIT. The DP Window will display the values of the design
parameters for all cases and iterations. The Iteration History Window will show the
information of the CONDUIT Iteration History feature in an organized and concise
format. Finally, the Sensitivity Analysis will allow the user to perform a sensitivity
analysis for each individual problem.
A feature new to CONDUIT, introduced in Analysis Mode is the capability to plot
gain schedules using the design parameter values of the different cases. This capability is
found in the Gain Schedule Window of Analysis Mode. Using the definitions of the Gain
Schedule Parameters Window in Setup Mode, the user can plot the design parameters
against any user-defined parameter. The data points of the plot are ordered in the order
of the gain schedule parameter values defined in Setup Mode. The Gain Schedule
Window has the ability to organize many gain schedule “plots”, organized on a number
of “pages”. Pages can be thought of as a piece of paper upon which a plot can be drawn.
Each page can have several overlaid plots. This system is best illustrated by the figure
below.
59

Plot 1
Page 1
Plot 2
Display
Area
Plot 3
Page 2
Plot 1
Figure 33 - Organization of gain schedule Figures
The properties of each plot, such as the line color and style can be set by the user
to create sensible plots. Additionally, all plots may be modified or removed later.
Finally, a capability of the Gain Schedule Window to be added in future versions
of Batch Mode is the ability to arrange multiple Pages in the Display Area at once. As in
the CONDUIT Analysis Tools, multiple Pages of the Gain Schedule Window (reduced in
size) might be viewed simultaneously in the Display Area.
60

2.4.2 Analysis Mode GUI
Figure 34 - Analysis Mode GUI - HQ Window
The Analysis Mode GUI, shown in Figure 34, shares the same common interface
with Setup and Run modes. As with Run Mode, the only difference in the interface is
with the Button Toolbar and the Display Area. On the left section of the Button Toolbar
are the window buttons, which select the six different windows in Analysis Mode. The
section on the right half of the Button Toolbar is reserved for features of each window.
The Display Area works in the same way as in Setup Mode, showing information
pertinent to each window. As in Run Mode, the Family and Case Number windows can
not be edited. Rather they serve as a method to select the displaying of case specific
information in the Display Area, the details of which are to be discussed later. The
remaining features, the File Menu, Mode Buttons, and Status Window, all work in the
61

same way as in Run Mode. Two windows were developed for Analysis Mode, to be
discussed next.
When entering Analysis Mode, the default window selected is the HQ Window,
shown in Figure 34. As discussed earlier, the HQ Window displays the same information
as the CONDUIT HQ Window, but in a way that facilitates the viewing of results from
all cases. The Display Area shows the HQ Window just as it appears in CONDUIT. By
default, it displays the data from the first case of the first family. To select another case,
the user may switch to the appropriate family by clicking on a cell in the Family
Window, and selecting the desired case cell in the Case Number Window. The HQ
Window will then be updated to display the results for the new case.
On the button frame are the controls specific to this window. Third from the left
is the iteration number indicator, which displays the current iteration of the displayed
case. Just to the right is the iteration slider. This is used to select the current iteration
and works in the same way as a conventional slider. Changes are immediately reflected
in the HQ Window plots. On the far right of the Button Toolbar is the phase
indicator/selector, which consists of three buttons, labeled for each of the three phase
numbers. This object serves two functions. First, it displays the phase of the current case
by coloring the appropriate button. Second, by pressing one of the three buttons, the
iteration slider will jump to the first iteration of the selected phase, if it exists.
One of the intents of Analysis Mode is to present the results in such a way as to
quickly view the results of all cases. The current HQ Window does just that. However,
if there are more than 12 specs in a case, the user must scroll the HQ Window to view all
62

of the specs. Thus, a zoom feature was proposed to zoom out the HQ Window, allowing
all specs of a particular case to fit in the Display Area.
At the time CONDUIT was first written, the multi-case batch environment was
not even thought of. Thus, the HQ Window is limited in its capability in this respect.
Incorporating the zoom feature would have required the arduous task of rewriting the
entire HQ Window code. As a result, this feature was postponed until that time which the
structure of the specs and HQ Window are revised. The details of the Zoom function will
still be discussed briefly.
The Zoom feature of the HQ Window will size and arrange the specs accordingly
so that they will fit on a single HQ Window. Since they will most likely be reduced in
size by some degree, the borders of the specs will be highlighted in one of three colors,
indicating their level ratings. Thus, by displaying the specs in this mode, the user could
quickly switch between cases and determine the ratings of all the specs.
Just to the right of the Zoom button is the Plot Multiple button. This button
allows the user to overlay the plots of multiple cases on the same HQ Window. To do so,
the user must first select the cases to be plotted by right clicking on the case cells. Each
case selected this way will be highlighted blue in the Case Number Window. In selecting
the cases, the user may switch to different families to select cases in other families. Once
all cases have been selected, the user presses the Plot Multiple button, which plots the
points of all cases on the HQ Window simultaneously, as shown in Figure 35. The
Iteration slider and Phase indicator/selector will be disabled since they are not valid in
this mode.
63

Figure 35 - Multiple case plot
The Plot Multiple feature would be useful for two primary reasons. First, in the
case of a gain schedule, the multiple plot would show which specs could not be pushed to
Level 1. However, the primary use of this feature, would be in the determination of the
robustness of the system. At a given flight condition, the user may perturb the stability
derivatives to the extents of their known accuracy, creating a multitude of cases
representing all possible combinations. Rather than optimizing these cases, the user
would simply evaluate each case. When the results are plotted simultaneously, the result
is a “thumbprint” plot. Thus, by ensuring that the area of this thumbprint stays within the
Level 1 region, the robustness of the system can be ensured. This is, of course, assuming
that the control system was modeled accurately and the errors of the stability derivatives
are accurate as well.
64

Figure 36 - Initial Gain Schedule Window
Figure 36 shows the final window developed for this version of Batch Mode, the
Gain Schedule Window. Initially, the Display Area is blank, as no pages or plots
currently exist. The Button Toolbar has several functions and displays specific to the
Gain Schedule Window. Just to the right of the Window buttons is a button labeled
“Add/Delete Plots”. When it is pressed, a window opens, shown below.
65

Figure 37 - Add/Edit/Remove Plot GUI
This window provides for all the functionality to add, edit, or remove a plot or
page. The button at the top of the window defines the action of the window. The user
may choose from the following options: New Page, Add Plot, Edit Plot, Remove Current
Page, Remove Current Plot. The New Page option is used to create a plot on a new page.
Add Plot is used to add a new plot to the current page. Edit plot is used to edit the name,
design parameter, color, line style, graph limits, or to turn the grid on and off for the
currently selected plot. Selecting Remove Current Page will delete the current page and
66

all plots contained within it, and the Remove Current Plot function will delete the
currently selected plot.
The next cell down is the Plot Name cell, which is used to name the new plot or
rename an existing plot. The Page Name cell performs the same function for the name of
the newly created or currently edited page. The Parameter option is a pull down menu,
giving the user the option to select any one of the parameters defined in Setup Mode as
the abscissa of the plot. Likewise, the Design Parameter to plot is set by the next pull
down button. The remaining pull down buttons and edit boxes are used to set the color,
line style, X Limits, Y Limits, and the grid. Once all the options are set, pressing the Ok
button will perform the action specified in the first cell.
On the far right of the Button Toolbar is the Page indicator and slider. The Page
Indicator displays the number of the currently displayed page, along with the total
number of pages. The slider allows the user to select the currently viewed page.
67

Figure 38 - New Gain Schedule plot
When a page is created, it appears in the Display Area as shown in Figure 38. Of
specific importance is the information on the Title Bar of the Main Window. This is the
control and information panel for the current page. On the far left of the Display Area
title bar is the name of the page. In this case, the plot is simply called “Plot 1”. Moving
to the right, the next item is the plot number, which lists the number of the currently
displayed plot and total number of plots on the current page. The next item to the right is
the plot number slider, which is used to choose the currently selected plot of the page.
The last two items are the design parameter of the currently selected plot and the
Parameter against which it was plot. The design parameter is listed on a pull down
button that can be used to switch the plot to show the results of a different design
parameter.
68

The gain schedule itself is plot in the Display Area. The X-Axis is labeled with
the appropriate parameter, and a legend is created to distinguish multiple plots. The
current plot is drawn bold to distinguish it from the other plots. Changing the plot slider
changes the design parameter cell to the appropriate value, along with highlighting the
newly selected plot.
Thus, in using the gain schedule plot, several plots and pages may be created.
The user may then switch between the pages by clicking on the page slider. In future
versions of Batch Mode, the user may choose to view more than one plot in the Display
Area at the same time. This functionality would be accessed through the Arrange Plots
button on the button toolbar. Any number of pages could be viewed simultaneously.
Each page would include the graph itself, as well as the components of the Title Bar.
Thus, the multitude of shrunk down windows would still be accessed in the same way as
when they were full size. An example of this future capability is demonstrated below.
69

Figure 39 - Multiple page concept
70

2.5 Sensitivity Automation
Batch Mode, up to this point, has accomplished all of the objectives except for
one. It has the ability to create multiple CONDUIT problems and modify every
parameter of a problem that could be modified by a user. It has the ability to
automatically run the multiple cases, and incorporates the means to quickly and
effectively view the results of these problems. The only objective lacking is the ability to
run the problems in such a way as to minimize user intervention. When running a
CONDUIT problem, sometimes the optimization can get stuck. The user must then run a
sensitivity analysis, freeze insensitive and correlated parameters, and continue. While
this is not necessary for some cases, the same can’t be said for all cases. Thus,
considering the large number of cases that could be used in a Batch Problem, some
automation of this process had to be implemented, and so the Sensitivity Automation was
created.
2.5.1 Typical Use of Sensitivity Tools
Before the development of the Sensitivity Automation can be discussed, the
details of the Sensitivity Analysis must be explained, with emphasis on the actions
performed by the user. When an optimization ends, it lists a reason why. Depending on
this reason, the user may opt to either accept the results and quit, or run a sensitivity
analysis. Typically, unless the message indicates that the problem is fully optimized, the
user would usually run a sensitivity analysis. The first step in a Sensitivity Analysis is
the selection of the design parameters for the gradient calculation. Typically, the
parameter selection would reflect the non-frozen parameters of the problem. However,
71

the user may choose to freeze additional parameters for other reasons. The gradient is
then calculated, from which the insensitivities and correlations can later be determined.
The user then chooses the specs to be used in the insensitivity calculation, and narrows
down the design parameter selection even further, if necessary. The specs to be used in
the insensitivity calculation are chosen based on their constraint type, and the current
phase. In Phase 1, the optimization routine is looking only at the hard constraints. Thus,
if any problems exist, they are due to the hard constraints and so they must be used. In
Phase 2, the soft constraints are likewise critical and should be used, while the objective
specs are to be used in Phase 3. The insensitivity plot is then created, shown in Figure 40.
Figure 40 - Insensitivity Plot
72

The general rule of thumb is that any design parameter with an insensitivity value
over 20% should be frozen.
After freezing the insensitive parameters, the user would then investigate
correlated parameters. The gradient would be recalculated with the new set of design
parameters. This same set of design parameters and the same specs would then be used
to calculate the Cramer Rao percentages, which would be plot on a separate graph.
Checking for correlated parameters is a little more complicated than insensitivities. First
of all, parameters with Cramer Rao percentages over 20% are considered to be highly
correlated, and should be investigated. Second, correlated parameters always come in
groups of two or more. These groups are distinguished by their relative magnitudes.
Figure 41 - Sample Cramer Rao plot
73

In the case above, if there were any pairs of parameters under 20%, it is still
possible for them to be correlated to each other, but the effect is not enough to create a
problem for the optimization routine. The pair of parameters, dpp_RAHAR and
dpp_RAHA, are correlated to each other as well, but in this case they are significant
enough so that they can cause the optimization routine to hang up on them. Since both
parameters do roughly the same thing to the system, one of them is unnecessary and
needs to be removed. Thus, by freezing one of the parameters, it reduces the dimensions
of the gradient, simplifying the problem for the optimization. After one of the design
parameters is frozen, if the gradient and Cramer Rao percentages are recalculated, the
Cramer Rao percentage of the other parameter will drop to below 20% (since it is no
longer correlated with any active design parameters).
The third set of correlated values in Figure 41 is a group of three design
parameters. (The group that dpp_PF is correlated with is ambiguous, but it will be
assumed that it is correlated to dp_RAHSF and dpp_RF for this discussion.) When more
than two design parameters are grouped together in this way, determining which
parameters to freeze can be tricky.
74

(a)
(b)
(c)
Figure 42 - Conceptual representation of correlated parameters
In the case of two design parameters correlated to each other, their relation to
each other is as shown in Figure 42a. While this exact configuration would never be seen
in a block diagram, it represents the relationship between two correlated parameters that
may exist in a similar or equivalent form in the block diagram. When three design
parameters are correlated, they might be represented by either Figure 42b or Figure 42c.
In the case of Figure 42b, all three cases are correlated to each other. To resolve this
problem, the user would have to freeze two of the three parameters.
In the case of the correlated parameters of Figure 42c, rather than the three
parameters all being correlated to each other, two of the parameters are correlated to the
third. Thus, freezing parameter 7 would resolve the correlations. However, freezing
75

parameter 8 would not resolve the correlation between parameter 7 and 9. The same
could be said for freezing parameter 9, having no effect on the correlation between
parameters 7 and 8. Thus, some experimentation would need to be done to determine the
actual relationship of the design parameters.
If four or more parameters are correlated, then it could quite possibly be that all
four design parameters are correlated, or it could be two pairs of correlated parameters
that just happen to have similar Cramer Rao percentages. Thus, to resolve the correlation
of three or more parameters, the user would refer to the block diagram to possibly gain
insight on which parameter to freeze. However, with the complexity of most block
diagrams, this might not be feasible. Thus, trial and error would be the next best step.
The user would freeze a parameter, recalculate the gradient and Cramer Rao bounds, and
repeat the process until all parameter correlations are resolved. Ideally, each parameter
of a group should be frozen individually to see if the parameters are related as in Figure
42c. By freezing only the critical parameters, more design parameters are still available
to COMATLAB, providing it with the greatest amount of flexibility so that the
optimization may be able to progress further than if additional parameters were frozen.
Once the insensitive and correlated parameters are frozen, the user would then
restart the optimization. The optimization would hopefully then continue further. This
process of running sensitivity analyses and optimizations would continue until
satisfactory results have been reached, the sensitivity analysis can’t find any parameters
to freeze, or all design parameters have been frozen.
76

2.5.2 Sensitivity Automation Development
The development of the Sensitivity Automation was done in such a way as to
replicate the actions a user might typically make. In doing so, it was discovered that a
simple set of rules could produce accurate results.
When the optimization of a case stops, and COMATLAB returns an exit message,
the Batch Mode run code will then determine whether a sensitivity analysis should be
run. It bases its decision on the logic of Table 1, which takes into account the exit code
and the ending phase.
Table 1 – Sensitivity Automation Run Logic
Phase \ Code 1 2 3 4 5 6 7 8
1 Yes Yes Yes Yes No No Yes No
2 Yes Yes Yes Yes No No Yes No
3 Yes Yes Yes Yes No No Yes No
Code
Exit Codes
Exit Message
1 A proper search direction cannot be found.
2 A feasible point is not found to satisfy all hard constraints.
3 Further decrease of the most active specifications cannot be achieved.
4 A local minimum has been obtained.
5 The optimization has reached Phase 2 or better.
6 The optimization has reached Phase 3.
7 The design parameters haven’t varied in the last 3 iterations.
8 (A number of) Iterations Completed.
77

The logic of the table above is simple to understand. The only three exit codes
that do not result in a sensitivity automation are the stop conditions based on reaching a
phase or number of iterations. Because the user specified the optimization to stop when
one of these conditions occurs, there is no reason to continue the optimization. All other
exit conditions specify optimizations that should continue as far as possible. Thus, the
sensitivity automation is run in an attempt to continue further.
Once the sensitivity automation is started, it chooses which specs are to be used in
the analysis based on the current phase. The logic for choosing the specs to use is listed
in the table below.
Phase Hard Soft Objective Summed Objective
1 Yes No No No
2 No Yes No No
3 No No Yes No
Table 2 - Spec selection logic
The logic of the table is based on the active constraints of each phase. Thus, if the
optimization stops in Phase 1, where the Hard constraints are optimized, the hard
constraints are used. Likewise, the soft constraints are used if the optimization stops in
Phase 2. The objective specs are used in Phase 3, and not the summed objective specs.
This is done because frequently, only summed objective specs exist in a problem. Thus,
if a sensitivity analysis were performed on only one spec, the gradient matrix would most
likely be scaled improperly and the results would be invalid.
After the specs have been chosen, the sensitivity automation then picks the design
parameters to be used. When the sensitivity automation is run for the first time, it uses all
78

non-frozen design parameters, the default frozen states of the case. Thereafter, it will
choose specs depending on the conditions of the last sensitivity run. If the last run of the
sensitivity tools was performed in the same phase as the current, then the current nonfrozen
design parameters are used. Thus, continuing in this manner, the design
parameters will be refined until the optimization can move out of the current phase, or the
optimization can no longer continue. When the optimization moves into a new phase,
the run code resets the frozen states of the design parameters to the default values of the
case. Design parameters frozen in previous phases were done so based on constraints
that are no longer critical. Thus, using the default values increases the possible search
directions, allowing the problem to proceed with the greatest chance of success.
The design parameters are first checked for insensitivity. First, the gradient is
calculated using the specs and design parameters. Sensitivity percentages are then
calculated using this gradient. The process of removing insensitive parameters is simple.
Any parameter with an insensitivity over 20% is frozen.
After the insensitive parameters are frozen, the sensitivity automation then
focuses on correlation of parameters. The gradient must be calculated again, so the
insensitive parameters just frozen won’t appear in the Cramer Rao percentages, which are
calculated next. As with the insensitivity check, all parameters with Cramer Rao
percentages over 20% must be investigated. Unlike the check for insensitive parameters,
the correlation check is much more complicated.
When investigating correlated parameters, a person would look for pairs or groups
of parameters with roughly the same Cramer Rao percentages. One parameter would be
frozen from each group, the gradient and Cramer Rao percentages recalculated, and the
79

process would repeat until all Cramer Rao percentages were under 20%. When this
process is automated, several areas of difficulties arise. The greatest difficulty is in the
grouping of the parameters. Even for a person, determining the groups of parameters can
sometimes be an ambiguous task.
Figure 43 - The difficulty of grouping parameters
The difficulty in grouping correlated design parameters is apparent in Figure 43.
It is clear that dpp_RAHAR and dpp_RAHA belong together, as do dpp_RF and
dp_RAHSF. However, it is not apparent which group of specs dpp_PF belongs to. It
might be that it belongs to one of the two groups, or it might also be that all five
parameters are correlated to some degree. Thus, while it can sometimes be difficult for a
person to decide which parameters are grouped together, this difficulty is increased
80

tenfold when a computer, which does not have the adaptive reasoning capability of a
person, is required to do the same.
Three possible approaches to the problem were considered. The first, called the
“grouping method”, would take the approach a person might take, attempting to group
design parameters together based on their relative values. For parameters to be grouped
together, their values must match within a specified tolerance. The ambiguous parameter
of Figure 43 is the first type of problem for the sensitivity automation. In the case of the
example of Figure 43, the ambiguous parameter would be assigned to each group,
attempting to reduce the Cramer Rao percentages of each trial group on a trial by error
basis. By freezing the parameters of the group other than the ambiguous parameter first,
if that parameter is still present when all other parameters are frozen, it can be concluded
that the ambiguous parameter belonged to the other group.
The second type of problem for the grouping method would be the case of four
parameters of similar magnitudes. The sensitivity automation would again have to split
up the parameters and try different combinations to determine the groupings.
In either case, there is no way to account for groups of more than two design
parameters without a large increase in required computations. Each possible test group
above requires a gradient calculation, which is equivalent in complexity to a Pcomb
calculation. Thus, while these ambiguities can be accounted for to some degree, the
added computational requirements are far too great.
The second approach considered, referred to as the “trial and error” method, is
similar to the strategy of early chess programs, in which the computer would look ahead a
number of moves, considering all possible move combinations of both the computer and
81

opponent. The computer would then rank the results of each combination and choose the
move that promises the best possible outcome. In the case of resolving correlated
parameters, each parameter would be frozen one at a time. The gradient and Cramer Rao
percentages would be recalculated and the results from this freezing would then be
evaluated in the same manner. This process would repeat for every combination of
freezing of design parameters. The end results would then be examined, and the
combination with the highest number of non-frozen design parameters would be used.
While this method would guarantee that the Cramer Rao percentages were reduced below
20%, freezing the least number of design parameters, the computational requirements for
all the possible combinations make this method unfeasible. It might be possible to
improve this method, but the number of gradient calculations would still be large.
The method that was eventually used was much simpler than the two other
methods, both in the computational requirements and its abilities. It involves freezing the
parameter with the highest Cramer Rao percentage, reevaluating the gradient and Cramer
Rao percentages, and repeating the process. While this method appears at first to be too
simple, it is surprising how effective it can be. This can best be demonstrated through an
example.
82

Figure 44 - Example Cramer Rao plot – Initial parameters
In the figure above, there are two groups of correlated design parameters. A
group of two at the bottom of the plot, and three parameters with larger Cramer Rao
percentages on the top of the plot. Upon calculating these values, the algorithm would
freeze the largest value, dpp_RF. After freezing the design parameter and recalculating
the gradient and Cramer Rao percentages, the new values would appear as in Figure 45.
83

Figure 45 - Example Cramer Rao plot - One parameter frozen
After freezing the first parameter, two possible conditions might exist, both of
which are shown in Figure 45. In the first scenario, the freezing of the design parameter
removed the correlation of the three parameters, resulting in the light gray bars
superimposed on the plots of dp_RAHSF and dp_PF. The other possibility is that the two
remaining parameters are still correlated, as shown with the dark blue bars. If that is the
case, then the next highest parameter would be frozen, and the gradients and Cramer Rao
percentages would be recalculated. Whichever event occurs, the ending values would
eventually reach the point where only two parameters are still correlated, as in Figure 46.
Freezing one of the two remaining parameters would result in all parameters being noncorrelated.
84

Figure 46 - Example Cramer Rao plot - Two correlated parameters
The chosen method works regardless of the actual groupings of the correlated
parameters, as demonstrated in the previous example. The number of gradient
calculations required is less than or equal to the best possible case of the other two
methods. Furthermore, the difficulties incurred in the “grouping method” due to groups
of three or more design parameters do not affect this method at all.
The only one possible shortcoming of this method is that when dealing with three
or more correlated parameters, it does not employ the means to freeze the minimum
number of specs. In other words, if the parameters are related as in Figure 42c, and the
critical design parameter is not frozen first, design parameters may be frozen
unnecessarily. While it is possible for this to happen, it is unlikely since correlated
parameters typically come in groups of two. In the rare case that its limitations of this
85

method are exceeded, the result would only be the unnecessary freezing of a minimal
number of extra design parameters. However, this limitation is acceptable when
considering the time savings and reduction of complexity obtained through the use of this
method.
2.5.3 Sensitivity Log
Several times during the optimization of each case, the sensitivity automation is
called to freeze insensitive and correlated parameters. This information is not reported on
the Run Mode GUI. If the user wishes to view the actions taken by the sensitivity
automation, he or she can refer to the Sensitivity Automation log file, located in each
case directory. The name of the file is Sensitivity.Log. A sample Sensitivity Log is
shown below in Figure 47.
SENSITIVITY ANALYSIS***************************************************
********
5/8/2000 15:43
Iteration: 2
Phase: 3
Stop Condition: The design parameters haven’t varied in the last 3
iterations.
Specs Used:
RmsAcG1 Lat
CrsLnG1 Lat
Insensitivity Analysis-------------------------------------------------
--------
Design Parameters used:
dp_RAHSF
dpp_RAHA
dpp_RAHAR
dpp_RF
Insensitive Parameters:
dp_PAHSF
dp_RAHSF
dpp_DIRMC
Correlated parameters analysis-----------------------------------------
--------
86

Design Parameters used:
dpp_RAHA
Correlated Parameters:
Summary of results-----------------------------------------------------
--------
Remaining active design parameters:
dpp_RAHA
Exiting sensitivity analysis. Continuing run of current case.
Figure 47 - Sensitivity Log
In this automated sensitivity analysis, the optimization stopped in Phase 3 when
the design parameters could not be changed in the last 3 iterations. Because the
optimization was in Phase 3, the specs critical to that phase, namely the two Summed
Objective specs, were used. All four design parameters were checked for insensitivity,
and three parameters were frozen. Since only one design parameter remained, a check
for correlated parameters was not performed. The end of the log indicates that one design
parameter remains active, and that the optimization will continue.
Upon completion, the sensitivity automation would exit to the run algorithm,
continuing the optimization of the current case with the same stop condition. The cycle
of running a sensitivity analysis and an optimization would continue until it is determined
that satisfactory results have been obtained, the sensitivity automation has frozen all
design parameters, or the sensitivity analysis was unable to freeze any design parameters.
Run Mode would then move on to the next case.
In conclusion, the sensitivity automation performs the same process that would be
performed by a user analyzing a CONDUIT problem. It provides the means of
automatically identifying and freezing insensitive and correlated parameters. By adding
87

this capability to the automated run of each CONDUIT problem, they stand a better
chance of running to completion. This reduces the number of cases which must be
investigated by the user and thus, satisfies the requirement of Batch Mode to minimize
user intervention.
88

3 Evaluation of the SH-2G Using Batch Mode
Having developed the functionality of Batch Mode, it was then necessary to
exercise it using a real world example to demonstrate its capabilities. In Setup Mode, it
was desired to show the ability of Batch Mode to create multiple CONDUIT problems,
configuring their properties as needed to reflect the different flight conditions. This
demonstration must also show the capabilities of Run Mode; how it can run multiple
optimizations or evaluations of the system without user intervention. Finally, it must
demonstrate the two primary functions of Analysis Mode: It must show the ability to
create useful gain schedule plots, and it must be able to demonstrate its use in creating
robustness plots, from which the user could ensure the performance of the system to the
extent of the known error of the model.
The particular problem used for the demonstration was the control system
currently under development for the Kaman SH-2G Seasprite. This system was chosen
based on several reasons. The primary reason was that the aircraft had been modeled at
three flight conditions using CIFER (Comprehensive Identification from FrEquency
Responses), which identifies and models a system based on frequency sweeps from flight
test data. Models at hover, 60kts and 100kts were available. The remaining flight
conditions could then be determined through interpolation, making the control system
ideal for gain scheduling. Another reason for using this model is related to the second
capability of Analysis Mode, the robustness plots. Since the models were created using
CIFER, the accuracy of each stability derivative is known. Thus, they may be varied to
check the robustness of the system. Finally, the size of the control system architecture is
89

not exorbitantly large, and thus the large number of cases to be optimized would run
quickly.
3.1 Description of the SH-2G
Figure 48 - SH-2G
The SH-2G Seasprite is a multi-purpose maritime helicopter that is currently in
use with the US Navy, the Egyptian Navy, and is soon to be in use by Australia and New
Zealand. It is a conventional helicopter, having a single main rotor and a tail rotor. It
uses a fully articulated rotor head, but rather than using a conventional swashplate, the
SH-2G uses on-blade control, a feature specific to Kaman. On the trailing edge of each
blade, approximately 3/4 from the root of the blade, is located a servoflap, which is used
to control the individual rotor.
90

Figure 49 - SH-2G rotorblade servoflap
By deflecting this flap, a torsional moment is imparted on the blade, twisting it
and causing a change in pitch of the blade. In using this method of control, the
complexity and weight of a conventional rotor head can be removed from the aircraft.
Additionally, servo flap control provides extra stability, lower levels of vibration, and
reduces the control loads such that the helicopter can be flown in the case of a loss of
hydraulics.
3.1.1 SH-2G Control System
The original SH-2G was developed in the 1960’s, and used an analog control
augmentation system. In recent years, Kaman has updated the aircraft with new
electronics, including a digital flight control system. In both variants of the control
system, the control architecture is that of a partial authority system. The pilot’s stick is
91

connected through mechanical linkages directly to the hydraulic actuators. The FCS is
connected in parallel to the mechanical system, reading information from the stick and
feedback sensors, and passing commands to its own set of actuators. The output from the
pilot’s actuators and those of the FCS are then mechanically mixed, as represented by
Figure 50. The mixing is such that for the lateral channel, the pilot has 75% authority
and the FCS has 25%.
δ PILOT
δ FCS
Pilot Input
Hydraulic Boost
To Rotor
FCS Input
FCS
Actutator
Figure 50 - Mechanical mixer representation
A partial authority control system is a hybrid system. The digital flight control
system design is that of an attitude system, while the pilot input to the hydraulic boost
responds as a rate system. Thus, the combined system responds like a rate command
system initially, with the long-term behavior of an attitude command system.
92

Figure 51 - SH-2G block diagram
Figure 51 shows the top-level block diagram of the SH-2G. Pilot stick commands
are input to the system on the upper left section of the block diagram. They pass through
the Control System block, which represents both the mechanical system and the flight
augmentation system. The commands are then input to the aircraft plant, the responses of
which are both output from the system and fed back through the FCS. The raw feedback
information passes through a Sensors block, which simulates the sensors on the actual
aircraft, and back to the Control System block. Thus is the basis of the simulation.
93

Figure 52 - Control System block
The control system itself is displayed in Figure 52. This block demonstrates the
nature of the partial authority system. Following the mechanical control system, the pilot
inputs are first passed through the mechanical linkages of the Lower Link blocks. They
then pass through the Boost Actuators and to the Upper Links block, where they are
summed with the commands of the augmentation system.
The augmentation system starts with the pilot and sensor inputs, which are passed
to the Simplified ASE (Automatic Stabilization Equipment) block. This block contains
the control laws of the augmentation system for each axis, shown in Figure 53.
94

Figure 53 - Simplified ASE block
The outputs are then passed to the ASE Servos and then to the Upper Links block,
which mixes the outputs of the mechanical and augmented control systems, to be output
to the Aircraft Plant.
It was stated earlier that one of the primary reasons for choosing the SH-2G
control system is that the block diagram is simple enough so that simulation times are
short. Since more than 10 cases were to be optimized, and even more are to be evaluated,
a decision was made to investigate only one axis. Not only would this reduce the
simulation times greatly (to approximately 1 hour per optimization), but it would also
simplify the analysis.
Within the ASE are the control blocks of each axis. The block corresponding to
the lateral channel is shown below.
95

Figure 54 - Roll - Attitude Hold block
The lateral axis controller is an attitude control system with proportional and rate
feedback. The only four design parameters of the lateral channel are located within this
block. Two gains are used as rate and attitude feedback gains: dpp_RAHA and
dpp_RAHAR. The other two design parameters are a stick force gain, and a stick filter:
dp_RAHSF and dpp_RF.
3.1.2 Required Modifications to the Block Diagram
Several modifications were needed to streamline the block diagram for the
purposes of this project. First, all non-essential input and output connectors were
replaced by terminating blocks. By doing so, a Simulink simulation will take less time to
run. This modification made a noticeable difference in run times.
96

CONDUIT Attitude Latch
Removed
Blocks
Figure 55 - Removed Simulink blocks
The second modification was the removal of components from the altitude and
heading hold blocks. These blocks were originally set up so that the block diagram
would automatically turn heading and altitude holds on and off in the same way as on the
actual aircraft. When flying the actual helicopter with the holds on, if the pilot moves the
collective or rudder pedals, the altitude or heading holds will be turned off, respectively.
Removing the inputs will turn the holds back on. This attention to detail was unnecessary
for the intended use, and thus, most of it was removed. All that remains of these blocks
are the means to turn the holds on and off.
3.2 Baseline Optimization
Using the block diagram detailed in the previous section, a baseline CONDUIT
case was created as a template for all Batch Mode cases to follow. Three identified flight
models were available from CIFER, hover, 60kts and 100kts. The flight condition
97

chosen for the template was that of the hover case, primarily because it has been used in
several previous analyses and is known to be well behaved. The Init file developed by
Chad Frost for his work with the SH-2F was used. With this Init file, the airspeed is
defined, and the state space matrices of the three identified models are interpolated for
the current velocity. Thus, models can be created for any velocity up to 100kts. The Init
file was set for 0kts.
The design parameters used for the template case were those developed by Kaman
in the actual flight testing of the SH-2G. All design parameters except for the four lateral
gains were frozen from the start of the optimization.
The specs were carefully chosen so that they applied to this class of aircraft. The
list of specs is as follows:
Figure 56 - Initial spec selection
Starting with the upper left corner, the Eigenvalues (EigLcG1) and Stability
Margins (StbMgG1) specs were chosen to ensure stability of the aircraft. Thus, they
were set as hard constraints. The next spec, the Bandwidth spec (BnRoF2) was taken
from the set of ADS-33D specs, and is set as a soft constraint, since it is a performance
98

spec. The next spec is the Gust Rejection spec (HldNmH1) which was used to ensure
that the system had some level of capability to account for disturbances. On the next row
are the Actuator RMS spec (RmsAcG1) and the Crossover Frequency spec (CrsLnG1).
Both of these two specs serve to reduce the energy and computational requirements of the
control system after the performance and stability specs have been met. Thus, these
specs were designated as summed objective specs. They might have worked just as well
as objective specs, but tying them together with the summed objective reduces the
chances of the optimization routine getting stuck. All specs were connected to the lateral
channel of the block diagram.
Figure 57 - Evaluation of initial gains
Using the original set of gains, the system was evaluated, resulting in Figure 57.
All specs were in Level 1 except for the Bandwidth spec which, was Level 2. The
optimization was started using the dp=0 stop condition. The problem ran for 41
iterations, stopping with the message: “The design parameters haven’t varied in the last 3
iterations.” The results of the optimization were as shown in Figure 58.
99

Figure 58 – Initial Optimized baseline
The results showed that the problem was not properly constrained by the selected
specs. After the optimization had pushed all specs into Level 1, it then started working
on reducing the Actuator RMS and Crossover specs. This reduction was achieved by
relaxing the damping ratio of the system, as can be seen in the time response of the
Normalized Attitude Hold spec. The only spec which accounted for the damping to any
extent, was the Normalized Attitude Hold spec, and it only ensured that the response was
less than 10% of the original peak value after 10 seconds. As demonstrated in the figure,
this limited constraint was not sufficient to ensure reasonable damping. The response
still oscillated quite a bit, just clearing the corner at 10 seconds. Thus, a damping spec
was added to the problem, and it was re-optimized. After 21 iterations, including a
sensitivity analysis, the optimization could continue no further. The results are displayed
below in Figure 59.
100

Figure 59 – Optimized baseline with final spec selection
The damping spec ensured that the damping ratio would not fall below a value of
0.35. The results of this can be seen in the time response of the Normalized Attitude
Hold spec in the figure above, in that the response became reasonably damped. Thus,
with the addition of this spec, the problem became properly constrained at this flight
condition.
One final problem was encountered with the constraints of the problem, but it was
only discovered after a batch problem was created and run. The details of creating and
running a batch problem will be left to the next section however, the problem will be
discussed here as it pertained to the configuration of the baseline case. It was found that
at velocities from 50kts to 80kts, the optimization reduced the crossover to the point that
the system became open-loop. This resulted in poor gain schedule plots, as many of the
gains were pushed to zero.
The reason behind this was in the configuration of the Normalized Attitude Hold
spec, in that it did not constrain the crossover frequency properly. With this spec, the
time response is normalized to the maximum roll angle of the signal. Because there is no
101

integrator in the lateral controller, the long-term response of these normalized signals
behave similarly, regardless of the input signal. Thus, when normalized, a signal having
a maximum angular response of 20°, corresponding to a system with a crossover of
.001 rad/s (essentially open loop), has a similar time response to a signal with a
maximum angular response of 2° and a crossover of 1rad/s. Therefore, the spec
configuration had to be modified to better constrain the crossover of the system.
The spec was modified so that it used the actual response of the system. In doing
so, the spec ensures adequate damping of the system, and thus, a finite crossover. The
values of the Level 1 envelope had a direct effect on the crossover of the system, the
degree of which varied between the different flight conditions. To determine the limits of
the envelope, the angular position and rate feedback gains were adjusted to produce a
spectrum of responses for various crossover frequencies, at hover, 60kts, and 100kts. An
input signal of sufficient magnitude was used such that saturation did not occur. It was
found that to ensure a crossover in the range of .8rad/s < ω C < 3rad/s, the envelope had to
limit the disturbance to within approximately 5.5°. The spec was modified to remove the
normalization of the signal. Instead, the response was scaled so that a value of 5.5°
corresponded to the 1° Level 1 boundaries from 0-10 seconds. Once again, the Batch
Problem was created and run. After viewing the results, it was found that these
boundaries had to be reduced to 5° since the crossover frequencies of the optimized cases
were much lower than those of the aforementioned test cases. The spec was modified
once again, this time changing the actual boundaries of the spec. (since this new value
was found to give reasonable results in all cases) The resulting spec is shown in the
optimized baseline results of Figure 60.
102

Figure 60 – Optimized baseline with final spec selection and configuration
Using this final set of specs, the problem was optimized at the three flight
conditions, and was found to properly constrain the crossover frequency. The optimized
hover case was then used as the baseline problem to create the multiple cases for the gain
schedule.
3.3 Gain Scheduling of the SH-2G
Batch Mode provides the user with the ability to quickly produce gain schedules
for aircraft. This capability will be demonstrated in three sections. First, it will be shown
how Batch Mode can easily setup and create multiple cases. Second, the optimization of
the multiple cases will be shown. Finally, the capability to create gain schedule plots will
be demonstrated, the cases ranging in velocity from hover to 100kts.
3.3.1 Setup of Problem
The setup of the batch problem started with the optimized baseline case. The end
design parameters were saved as the default for the case, their frozen states set such that
103

only the four lateral gains were active. Thus, each case to be created in the batch
problem will start with these values. A new directory was created for the batch problem,
and the baseline case was copied to that directory. Batch Mode was started, selecting the
baseline problem in the new directory. The Batch Mode GUI appeared as shown below.
The single case shown is the baseline problem, with the default values set.
Figure 61 - Initial Batch Mode GUI
This baseline case was then modified to become the first case of the gain
schedule, the hover case. First, the Family name was changed to “Vel. Sched” (Velocity
Schedule) for later reference. Also for reference, the name of the case was changed from
the default of “sh2glat1” to “Hover”.
104

In the General Window, the first parameter to modify was the Init String cell. As
explained previously, any text in the Init String cell is copied directly onto the first line of
the Init file, replacing all “#” symbols in the string with the case number. To distinguish
each case of the gain schedule, the velocity was defined using this cell. The Init file uses
the variable “airspeed” as the airspeed in knots. Thus, the text “airspeed=0;” was added
to the Init String cell. Because this value was originally declared later in the Init file, it
would be re-declared to the value of the template Init file. Thus, the declaration of the
template Init file was rewritten such that the variable would only be set if it had not been
previously declared. As such, the original Init file could still be used with a normal
CONDUIT problem, as well as with Batch Mode.
The default value of the Block Diagram File cell was already set properly and
needed no modifications. The Run Case column, which defines which cases are to be
optimized in Run mode, was set to “Yes”. The Stop At Phase column was left with the
default value of zero, setting Batch Mode to stop when the design parameters no longer
can be changed. Since the Stop At Phase column was selected, the Number of Iterations
to Run cell was left inactive. Finally, the Design Margin cell was left with the default
value of 1.
It was then necessary to set the Gain Schedule Parameters Window, so that gain
schedule plots could be plot against velocity, omitting irrelevant cases to follow in later
sections. Using the Add/Edit/Remove Parameter GUI, a new column labeled “Velocity”
was created. A value of zero was put in the blank cell.
After all the parameters of the hover case were set, it was time to create the other
remaining cases of the gain schedule. Using the Insert New Cases function of the Setup
105

GUI, ten more cases were added using the hover case as a template. For the remaining
cases, it was simply a matter of altering the names, Init String, and Velocity columns.
The final Setup GUI appeared as in Figure 62.
Figure 62 - Final Setup GUI of the Gain Scheduling cases
The Batch Problem was then created using the Create Batch Problem function of
the Setup GUI. Problem directories were created and all required files were copied,
resulting in eleven individual CONDUIT problems.
3.3.2 Running of the Gain Schedule Batch Problem
Batch Mode was switched into Run Mode, and the cases were ordered using the
Order Automatically feature. The Run Status button was then pressed so that the batch
106

optimization could be monitored, and the optimization was started. Batch Mode then
progressed through the list of cases, optimizing each one.
Figure 63 – Initial Run Mode optimization
The results of the batch run can be seen on the Run Mode GUI in Figure 63. All
cases ended in Phase 3, due to the dp=0 condition. As such, all cells of the Phase column
were colored green. The Optimization Result Message column also indicated successful
optimizations.
3.3.3 Gain Schedule Results
After all the cases had been run, Batch Mode was switched to Analysis Mode to
view the results. Typically, the user would view the results of the HQ Window, flipping
quickly between cases, to ensure each case ran properly. For the sake of being concise,
107

the Plot Multiple feature of the Analysis HQ Window was used to create a plot,
overlaying the results of all the cases, shown in Figure 64. Viewing the results in this
way, the entire range of velocities can be viewed simultaneously to find any Level 2 or 3
results.
Figure 64 – HQ Window overlaid results
Looking at the plot of Figure 64, it is clear that all specs fell within the Level 1
region. Since the results of the HQ Window turned out well, the gain schedule was
created.
108

Figure 65 - Gain Schedule plots against velocity
The results of the initial gain schedule plot left much to be desired. At first
glance, it appears to be anything but ordered, however a few patterns were discovered
that led to the cause of the poor results. From the sensitivity logs of the individual cases,
it was learned that the attitude and rate feedback gains, dpp_RAHA and dpp_RAHAR
were the most active design parameters. It was then curious why these two parameters
wouldn’t have smooth gain schedules. However, the schedules from 0-50kts and 60-
90kts seem to follow either increasing or decreasing patterns. Between 50kts and 60kts,
the design parameters of both cases change drastically. Since 60kts was one of the three
identified points used in the interpolation, it was theorized that the linear interpolation
109

method was causing problems. Thus the interpolation was changed to use a cubic
interpolation.
While the interpolation method might have been a possible cause of the jump in
values at 50-60kts, it could not explain the large inconsistencies at 100kts. In no case
were the design parameters consistent with the trends leading up to that velocity. Thus,
some other problem was responsible. It was noticed that the time response to disturbance
input on the attitude hold spec was close to a first order decaying signal from velocities in
the range of 50-80kts. At 90kts, a small amount of overshoot appeared, and at 100kts, the
signal had a significant amount of overshoot, and an oscillating response.
The minimum damping ratio of .35, enforced by the damping spec, was enough to
constrain the system such that the cases did not wildly oscillate, however it did not
produce consistent results. In the mid-range velocities, the system had a higher damping
ratio than at lower and higher speeds, for a given set of gains. Thus, the mid-range cases
did not have to work as hard to meet Level 1 ratings.
The broken-loop crossover frequency of the system showed that the attitude hold
spec was not stringent enough to constrain the problem. The remaining cases were
checked, and it was discovered that the crossover varied from .4rad/s to 2rad/s. At this
range, the system was not properly constrained equally over the range of cases. Thus, to
even out the constraint requirements, the borders of the attitude hold spec were reduced
even further from 5.5° to 5°. The spec was also modified such that the axes were to
scale, so that the time response did not need to be scaled.
The batch problem was run once again. However, it was noticed early in the
optimization that some of the cases could not progress to a solution. Closer investigation
110

evealed that the damping spec was taking points off of the plot improperly. This is
illustrated by the support plot shown below.
Figure 66 – A problem with the damping spec
The damping ratio spec looks for local maximum and minimums and assumes
they define the envelope of decay. When a high frequency oscillation is superimposed on
a dominant lower frequency, the points picked for the damping ratio calculation are no
longer valid. In the case of the response of Figure 66, the invalid point resulted in a
period that was less than half of the actual value. The resulting point plotted on the spec
was on the imaginary axis, at a value of approximately 8rad/s.
Since this high frequency oscillation always occurred immediately after the initial
peak, a restriction was put on the selection of the points such that the period had to be
larger than 4 seconds, or the point would not be used. This time gave a sufficient buffer
to ensure that no invalid points were used. After the modification was made, the spec
was able to return accurate results.
Once again, the batch problem was run, but this time with more success. A
second gain schedule was created for the new results, shown in Figure 67.
111

Figure 67 - Corrected gain schedule
This gain schedule shows a large improvement over the original plot. For the
most part, all four design parameter schedules are mostly smooth, and all four can be
seen to follow an identifiable path.
112

3.4 Robustness Evaluation of the SH-2G
The second feature of Analysis Mode to be demonstrated is the capability of
Batch Mode to evaluate the robustness of a system. In doing so, it will be demonstrated
that Batch Mode has the ability to set up multiple cases for evaluation. Using these
evaluated cases, it will also be shown how thumbprint plots are created, from which the
user can ensure the performance of the system to the extent of the known error of the
model.
3.4.1 Parameters to Vary
In the creation of a robustness plot, a large number of cases are created to be plot
simultaneously. The stability margins are varied to their known accuracy in each case to
observe the effects of the parameter changing on the level ratings of the specs. Thus, the
creation of the individual cases started with the identified CIFER data used to build the
models. This information can be found in the Appendix. This table lists the stability
margins, their values, their Cramer Rao percentages, and their insensitivities; all of which
were calculated in the model identification. Parameters for the state space matrices F and
G, the system and input matrices, were available along with the time delays. Finally, the
rotor flap time constant (τ F ) was defined, which is used in the calculation of the control
derivatives. Thus, knowing these values and their accuracies (given by the Cramer Rao
Percent), the model could be varied to test for system robustness.
The second consideration in the variation of the stability margins was determining
the combination of parameters to be varied for the individual cases. The parameters to
vary were split into four categories: control derivatives, time delays, rotor flap time
113

constant, and the remaining stability derivatives. Of these categories, the control
derivatives and time delays were the most critical. Since the rotor flap time constant was
used in the calculation of the control derivatives, it was also considered important. Thus,
these critical parameters were varied by adding and subtracting their 3σ deviations. All
combinations of deviation were created as per the logic of Table 3, resulting in 20 cases.
Table 3 - Variations of derivatives
Case Parameter Sign (Parameter) Sign ( F )
12 LFRS + +
13 LFRS + -
14 LFRS - +
15 LFRS - -
16 LFRC + +
17 LFRC + -
18 LFRC - +
19 LFRC - -
20 MFRS + +
21 MFRS + -
22 MFRS - +
23 MFRS - -
24 MFRC + +
25 MFRC + -
26 MFRC - +
27 MFRC - -
Case Parameter Sign (Parameter)
28 RF (Time Delay) +
29 RF (Time Delay) -
30 L0 (Time Delay) +
31 L0 (Time Delay) -
114

An actual check for robustness would vary the parameters in such a way as to
explore all possible combinations of all variables. Thus, in addition to the individual
variation of parameters of the critical cases, it was necessary to modify the remaining
design parameters as well. Since the goal is to demonstrate the capability to check for
robustness, and not in fact to guarantee the robustness in all possible situations, only 21
additional cases were created. In each case, all stability margins were varied to their
known accuracies, with a random direction of variation.
3.4.2 Modification of the Original Model
To incorporate the different conditions of the large number of cases, the capability
had to be created to modify the problem, as described above. Thus, a function was
written to be incorporated into the Init file. The function is called using the following
form:
Robust(CaseNumber,Random,Sign,TfSign)
• CaseNumber – The Batch Mode case number.
• Random – A flag used to set whether the direction of variation is random or not.
• Sign – The direction of the variation of a parameter. Also used to scale the error
percentage.
• TfSign – Same as Sign, but for the rotor flap time consant.
Thus, while some of the settings were passed to the function, other settings were
hard-wired in the function. This was done for two reasons. First, the stability derivatives
to modify were hard-wired in the function and organized by case number, simply because
there were too many parameters to pass to the function. Second, by passing some of the
115

simpler parameters, it provided greater flexibility and the differences between cases could
be observed in Batch Mode.
The function would start by loading the original model. It would then determine
which stability margins to vary, based on the case number. Each parameter would then
be varied using the variation directions and scaling factors passed to the function. The
new model would be saved under a new name, and the original interpolation code was
modified to load this new model if it existed.
3.4.3 Creation of the Robustness Cases
The method of creating the cases to be evaluated is very similar to the methods of
the gain schedule. Thus, only the differences in procedure will be discussed in detail.
First, the same batch problem was opened so that additional cases could be added for the
robustness check. To properly organize the cases, a new family was created and renamed
to “Robustness”. Twenty cases were created using the hover case as a template, to be
used for the robustness check of the critical parameters. The names of each case were
used to indicate the different control derivatives or time delays. The Init String column
of the General Window was changed. Since the Init file defaults to 0kts airspeed when a
value is not passed through Batch Mode, it was removed from that column for clarity. In
its place, the call to the Robust function was placed using the proper settings for each
case. Finally, the Number of Iterations to Run cell was activated and set to zero in all
cases, in order that Batch Mode only evaluate the initial Pcomb for each case.
A second family was created for the random cases used in the robustness check,
and 21 additional cases were created. These cases were configured in the same way as
critical parameters, but the random flag was set. The corresponding case numbers were
116

set in the Robust function to vary all parameters for each case. The results of the
robustness setup can be seen in Figure 68.
Prior to entering Run Mode, the Run column of the General Window was enabled
in the two new families, and disabled in the original velocity schedule case. The cases
were then created using the Create Batch Problem option of the File menu.
Figure 68 - Robustness check setup
3.4.4 Running the Robustness Check Cases
Once the cases have been created, Batch Mode was switched into Run Mode. The
cases were set using the Order Automatically feature. Since the cases progress quickly
during an evaluation of cases, the Run Status window was not necessary. The evaluation
117

was then started by pressing the Run button. It progressed in much the same way as the
velocity schedule cases, only much faster.
3.4.5 Results of the Robustness Check
Figure 69 - Robustness of critical stability margins
Switching to Analysis Mode, a multiple HQ Window plot was created overlaying
the critical cases, the time delays and control derivatives. The plot shows a scatter of
points in most of the point specs, and small deviations in the attitude hold line spec.
Thus, the value of such a feature is apparent. By overlaying the points at the extremities
of their accuracy, the user can quickly determine whether the system has a chance of
deviating from Level 1 due to inaccuracies of the model, by observing the region or
“thumbprint” of points. In the case of the evaluation of Figure 69, all of the specs lie a
118

comfortable distance within the Level 1 region, except for the Bandwidth spec. In the
case of that spec, the points move right up against the Level 1/2 border, but are still
shown to be Level 1. A plot was then made for the 21 random cases, shown below.
Figure 70 - Robustness plot of all stability margins
When the critical stability margins robustness plot is compared to the random
plot, the term “critical” might not seem appropriate, but it must be remembered that the
random case is varying all of the critical stability margins simultaneously. When more
than one stability margin is allowed to change at once, the results vary to a larger extent.
The results of Figure 70 were circled in the three specs with the greatest variation in the
plots, to indicate the possible region of variation for the points, or thumbprint. In the case
of the Stability Margins spec, the variation was much larger than in the single variations
119

of the critical parameters, however all points lie within the Level 1 region. Since only the
edge of the plot comes close to the Level 1/2 border, it is probably safe to say that the
points will most likely be Level 1 for this spec. The plot of Figure 71 shows the plot of
the open loop bode response of all the random cases, which was used to calculate the
stability margins. The plots define a region in which the bode response could be
expected to fall, for any given variation, which could be taken into account in the design
of the system to ensure robustness. It also shows the large variance in crossover from
1.5rad/s to 3rad/s, resulting in the spread of points on the Stability Margins spec.
Figure 71 - Open-loop bode response of random cases
The Bandwidth spec is a different situation than the stability margins. The locus
of the points lies just next to the Level 1/2 border. Thus for many variations, the spec
120

will be degraded to Level 2. This movement to just within the Level 2 border may or
may not be acceptable, depending on the spec. If the intrusion occurred on a stability
spec such as the Eigenvalues or Stability Margins spec, then a slight degradation such as
this might cause instability. However, for the case of an ADS-33D spec such as the
Bandwidth spec, the slight degradation into Level 2 might be acceptable. This is because
the spec itself was created based on statistical results of pilot opinion, and are not
necessarily absolute. Secondly, the Level 2 ratings might only occur with specific
variations in the system that rarely occur. However, if the designer felt that some design
margin was necessary, then the design margin of the template case could be changed, the
problem re-optimized, the robustness check cases recreated, and the case re-run. By
using the results of the robustness plots, the user could redefine the design margin to the
minimum value required to meet Level 1 in all possible variations.
The damping ratio spec had the largest spread of points of all the specs. The
reason for such a large spread is that the damping ratio spec is a time point spec. Time
point specs rely on the algorithm to pick data off of a time response. The difficulties in
doing so are numerous, primarily because the time response can vary in form to such a
great extent. In particular, the damping ratio spec requires the maximum and minimum
peaks of the signal as it decays to calculate the damping ratio based on the equations for a
second order system. When this method is applied to a higher order system, problems
can occur. Higher frequency oscillations make it difficult for the algorithm to identify
the dominant frequency. Additionally, the value calculated for a well behaved 23 rd order
system (for example) might oscillate as a second order response would, however when
the points are taken and the damping calculated, it might not appear to be accurate,
121

simply because the system is not a second order system. Finally, if the system is
overdamped, no peaks can be found to make a calculation, thus an arbitrary value of –1 is
assigned, shown as the arrow on the real axis. Thus, because of the problems with this
spec in determining the damping ratio, and that the results will jump in their value when
overdamped (and remain at that value regardless of the actual overdamped value), the
damping ratio spec is a weakly driving spec in an optimization.
Therefore, the robustness plots can also be used to identify specs which only
weakly drive the optimization. After discovering a weak spec, it could then be replaced
with a stronger spec. In this case, however, there was no alternative.
The remainder of the specs vary to some degree, but they do not come close to
violating the Level 1 ratings. The Eigenvalues spec does not change at all, as the
variation in parameters does not cause instability.
3.4.6 Conclusions of the Robustness Plot Capability
Several things have been shown in the demonstration of the Robustness capability
of Analysis Mode. First, it showed how the system could be checked for robustness.
Second, it showed how the violations of the Level 1 region could be used in the redesign
of the problem, using the minimum increase in design margin. Finally, it was shown that
the robustness plots could be used to find weak optimization specs.
122

4 Future Work
Due to the uncompromising attitude taken in the early design conception with
respect to the inclusion of features, many features remain to be implemented.
Additionally, a project such as this one leaves many possibilities for future
improvements, as well.
4.1 Setup Mode
Only the basic functionality of Setup Mode was developed for the first version of
Batch Mode. Three additional windows remain to be developed, the Design Parameters
Window, the Spec Options Window, and the User Defined Window. Once these features
have been created, Setup Mode will be fully functional, enabling the users to vary every
parameter of a CONDUIT problem easily and quickly.
4.2 Run Mode
Run Mode is complete in its current state, however, one additional possibility is
being considered. Due to the potentially large number of cases in a Batch Problem, the
use of multiple processors to run cases simultaneously is being considered. By running
the cases in parallel, large time savings in run times may be accomplished.
4.3 Analysis Mode
Of all the sections that merit additional work, Analysis Mode is the largest. This
is simply because there are so many possibilities in the viewing of large amounts of data
in so many different forms.
123

The HQ Window, as developed already, only stands for two improvements. First,
is the zoom capability to allow a large number of specs to be viewed without scrolling the
window, and second, the capability to overlay support plots of multiple cases. These
improvements were not possible in the current version due to limitations of the
CONDUIT specs and HQ Window.
As with the HQ Window, the Gain Schedule Window was complete except for a
few extra features. These features include the ability to arrange multiple plots within the
Display Area, and the capability to drag plots to the desktop, creating stand-alone figures
as in the CONDUIT Analysis Tools.
In addition to the added features of the two windows created for Analysis Mode,
several other features are to be implemented. The Pbrush Window will be created to
display the information of the Pcomb for multiple cases. A Design Parameters window
will be created such that every design parameter of every case can be viewed for any
iteration. The Sensitivity Tools will be incorporated into Analysis Mode as well,
allowing the user to view the results of automated sensitivity analyses, or to perform an
analysis on a particular case. Finally, in the time during which the remaining Analysis
Mode features are developed, a feature will be created to allow the user to select a case
and switch back to CONDUIT, to view the results not displayed currently in Batch Mode.
4.4 Sensitivity Automation
Further use of the Sensitivity Automation could be used after an optimization to
improve the results of a gain schedule. Research could be done to determine if it is
possible to smooth the gain schedule by checking for insensitive parameters, adjusting
their values to fit the expected trend of the gain schedule, and re-optimizing.
124

5 Lessons Learned
Four significant lessons were learned in the course of this thesis. Specifically, the
lessons deal with the running of problems in Batch Mode:
1. It was learned that terminating unused input and output blocks can significantly
improve simulation times. In a Batch Mode problem with a large number of cases,
this small gain in run time can result in large time savings.
2. If interpolation is used to create cases between two known models, then the
interpolation method must be chosen such that the stability derivatives vary smoothly
in a realistic manner. If not, then the results of resulting gain schedules can be
inaccurate or have discontinuities.
3. Time specs must be watched carefully over the range of varying cases.
As demonstrated with the damping ratio spec, time specs that require a signal of a
specific form can return invalid results when the signal is not of this form. Since time
signals can vary to many different forms, it is best to avoid time specs in Batch
Problems. However, if they must be used, they should be checked at several different
cases to ensure the time signal is of the appropriate form for the spec. If not, then the
spec must be modified to accommodate for the discrepancies.
4. The cases must be well constrained over the entire range of cases. In the case of the
SH-2G problem, it was found that the original Attitude Hold spec was not sufficient
to constrain the problem in the mid-range velocities, and the system went open loop.
As a result, the gains in this region were arbitrary, and the gain schedules weren’t
smooth. In addition to the cases being well constrained, they must also be similarly
constrained. In other words, the critical constraint should be the same for all cases. If
125

not, then the specs most critical to the system might change from case to case. Thus,
the specs might be driven in different directions, resulting in poor gain schedules.
126

6 Conclusions
In the course of this paper, it has been shown that Batch Mode is an effective tool
for use with multiple CONDUIT problems. Batch Mode provides the user with the
capability of creating a large number of CONDUIT problems for optimization or
evaluation. These problems can then be optimized or evaluated without intervention by
the user. Batch Mode also provides the capability to analyze the results of a large
number of optimized or evaluated cases in an efficient manner. It offers HQ Window
thumbprint plots to check for robustness, along with gain schedule plots against user
defined variables. The Sensitivity Tools of CONDUIT were automated for use with
Batch Mode, giving the Run Mode the ability to automatically freeze insensitive or
correlated parameters. Finally, it was shown that the simple logic of the correlation
freezing was sufficient for the purposes of freezing correlated parameters.
The optimization of the SH-2G demonstrated many of the features and
capabilities of Batch Mode. First, it demonstrated the ease by which a Batch Mode
problem could be created, optimized, and evaluated. The results of these cases were then
used to show that smooth gain schedules could be obtained through the use of Batch
Mode. Finally, the use of thumbprint plots to examine the robustness of a system were
also shown to be effective.
127

BIBLIOGRAPHY
1. Frost, Chad R. “Design and Optimization of a Rotorcraft Flight Control System
Using the Control Designer’s Unified Interface (CONDUIT).” M.S. Thesis,
California Polytechnic State University, San Luis Obispo, 1999.
2. Math Works Inc., The. Building GUIs with MATLAB. Reference Manual, Natick,
Massachusetts: The Math Works, Inc., 1997.
3. Math Works Inc., The. Control System Toolbox User’s Guide. Reference Manual,
Natick, Massachusetts: The Math Works, Inc., 1997.
4. Math Works Inc., The. Using MATLAB. Reference Manual, Natick, Massachusetts:
The Math Works, Inc., 1997.
5. Math Works Inc., The. Using MATLAB Graphics. Reference Manual, Natick,
Massachusetts: The Math Works, Inc., 1997.
6. Math Works Inc., The. Using Simulink. Reference Manual, Natick, Massachusetts:
The Math Works, Inc., 1997.
7. Morel, Mark R. “CONDUIT Handling Qualities Specifications: Development,
Unique Features, and Applications.” M.S. Thesis. California Polytechnic State
University, San Luis Obispo, 1997.
8. Nise, Norman S., Control Systems Engineering. 2 nd ed. Redwood City, California:
The Benjamin/Cummings Publishing Company, Inc., 1995.
9. Tischler, Mark B., ed. Advances in Aircraft Flight Control. Bristol, PA: Taylor &
Francis Inc., 1996.
10. Tischler, Mark B., Jason D. Colbourne, Kenny K. Cheung, Chad R. Frost, William S.
Levine, and Veronica Moldoveanu. CONDUIT “The Control Designer’s Unified
128

Interface” Course Notes. NASA Conference Proceedings CP-1998-10157. Moffett
Field: National Aeronautics and Space Administration, 1998.
11. Tischler, Mark B., Mavis G. Cauffman. Comprehensive Identification from
FrEquency Responses. An interactive facility for system identification and
verification. Volume 1 – Class Notes. Class Notes from short course held at NASA
Ames Research Center, Moffett Field, California, September, 1994.
12. Tomashofski, Chris A., and Mark B. Tischler. “Flight Test Identification of SH-2G
Dynamics In Support Of Digital Flight Control System Development.” Paper
presented at the 55 th Annual Forum of The American Helicopter Society, Montreal,
Canada, May 25-27, 1999.
13. United States Army Aviation and Troop Command, “Handling Qualities
Requirements For Military Rotorcraft”, ADS-33D, St. Louis, Missouri, May 1996.
129

APPENDIX
130