[american institute of aeronautics and astronautics aiaa modeling and simulation technologies...

USING MATLAB/SIMULINK FOR LAUNCH VEHICLE GN&C VALIDATION

Richard LeBoeuf, Ph.D. Dongyu Fu�

Jinho Kim, Ph.D.� Swales Aerospace, Inc. Beltsville, MD 20705

∗ Senior Controls Engineer, Member AIAA + Controls Engineer ⊕ Senior Controls Engineer Copyright 2002 The American Institute of Aeronautics and Astronautics Inc. All rights reserved.

Abstract An Integrated Guidance, Navigation and Control (GN&C) and Mission Analysis Tool architecture based on tools developed for NASA Kennedy Space Center launch vehicle Independent Verification and Validation (IV&V) are described. In this paper the tool architecture, based in the Mathworks Matlab environment, is defined using generic forms of existing models and analysis tools and representative output is given. Common input data handling and directory structures are recommended. Flight software guidance and control algorithm modeling and linearization methods and fidelity are discussed in the context of design versus IV&V. Methods for handling events and timing including engine burn times, on/off switching, flight software timing, dynamics based events, controller gain scheduling, and vehicle model aerodynamics and mass property staging using Stateflow and Simulink are explained. Time-domain mission analysis, stability analysis, Monte Carlo stress cases, and covariance analysis for GN&C and mission simulation and analysis are explained in the context of the Matlab programming environment. The benefits of heritage, knowledge capture, and general benefits of using the Mathworks platform for a common GN&C and mission design and analysis tool are discussed.

Introduction The conventional design and validation approach to GN&C and mission analyses includes the following tasks

- Trajectory optimization - Sensor validation - Flight control design - Flight Software verification - Performance, stability, and robustness

verification - Post mission analysis

The conventional approach investigates each individual task separately and uses the output of one for the input of another. Based on performance, an input design parameter can be modified in sequential feedback fashion. These approaches can be time-consuming and prone to data input translating errors. Thus there have been many approaches to make these processes more efficient and robust. The recent commercial off-the-shelf simulation analysis CAD tools such as MATLAB, SIMULINK, MatrixX, and Easy-5 have facilitated integration of these processes in a time-reducing and efficient manner. Previous works have explored some aspects of this integration. Rauw1 provides the nonlinear 6 degrees of freedom (DOF) Simulink blocks and all the subsystem blocks for flight dynamics and control. Magni, Bennani, and Terlouw2 present robust control analysis tools with Matlab and Simulink blocks to provide the common design model for flight control design and the corresponding performance evaluation based on the requirement during the landing phase. Waldraff and Finsterwalder3 suggest the use of MALAB/Simulink and DYMOLA for aircraft simulator modules. Tischler4 presents CONDUIT (Control Designer’s Unified Interface), which provides an environment for integrated control system and design using MATLAB/Simulink. We developed a nonlinear multi-body dynamics simulation including flexible and slosh modes in MATLAB/Simulink. The flight software model, written in C, is connected with the dynamic modules. The time based mission events are modeled with the Stateflow/Simulink. Then the corresponding linear model including GN&C elements, actuator, aerodynamics, sensor dynamics, flexible mode dynamics, and tail-wags-dog dynamics are also developed to provide the control algorithm design and performance evaluation. The modules are reusable and easy to understand. Implementation using Matlab data

AIAA Modeling and Simulation Technologies Conference and Exhibit5-8 August 2002, Monterey, California

AIAA 2002-4687

Copyright © 2002 by the American Institute of Aeronautics and Astronautics, Inc. All rights reserved.

Dow

nloa

ded

by S

tanf

ord

Uni

vers

ity o

n O

ctob

er 7

, 201

2 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

002-

4687

2 American Institute of Aeronautics and Astronautics

structures facilitates perturbation of design parameters for scenario and Monte Carlo analysis. This tool can be easily expanded for payload performance analysis.

Integrating GN&C & Mission Analysis The proposed integrated GN&C and mission analysis tool is based on the potential for sharing models, input data, and the use of mission analysis time-domain simulation results for deriving operating conditions for the GN&C linear system along the mission time line (Figure 1). Data, models, and their integration into a common architecture are discussed in the following subsections.

Operat ing point

Flight software

data

Vehicle & environ ment

data

Mission analysis Time-domain

GN&C analysis Frequency-domain

Co mmon models

Figure 1. Integration of mission analysis and GN&C analysis tools.

Data Sharing Putting both time-domain and frequency domain tools in one architecture on a common platform like Matlab eliminates the need to translate input data into more than one format. Developing a common data directory around a mission rather than by tool (Figure 2) can further facilitate the tool integration because all initialization and output files can be referenced based only on the mission or project directory. A user can input the project directory via a graphical user interface (GUI) and standard format data will be accessible for tool use or post-processing via a common GUI. For example, operating point data (e.g., Mach number) can be found under the directory “Simulation results” for use in the linear analysis for the same mission.

Non-Linear and Linear Models The expendable launch vehicle (ELV) Simulink models for time-domain simulation and frequency domain analysis are shown in Figures 3 and 4, respectively. The model components are described in more detail in the following subsections.

Data d irectory Mission 1 d irectory Flight software inputs Veh icle model in itializat ion Env ironment model in it ilization Simulat ion results Stability analysis results Mission 2 d irectory ...

Figure 2. Hypothetical sharing data directory.

Flight Software

Flight software can be modeled in Simulink, C-code or a mixture of the two. Simulink has the advantage that the model can be built graphically. However, for a high fidelity simulation, unless the flight software was generated from a Simulink model or is being linked in directly (e.g., as a hardware-in-the-loop component), it is advantageous to model the flight software in C. A C-code model can be more easily debugged because variables are easier to access via print statements rather than by installing scopes in the Simulink model. It may be argued that the Simulink model can be linearized using the “linmod” Matlab function, whereas a C-code version would not be amenable to numerical linearization. However, our approach has been to linearize the flight software analytically rather than numerically to ensure all states are represented.

Flight Software to Vehicle Interface

The flight software to vehicle interface uses masking and digital to analog (D/A) conversion operations to determine discrete commands and engine thrust vector control (TVC) or fin actuator commands from the binary flight software model outputs (Figures 5 and 6, respectively.) Only a linearized version of the actuator D/A quantization effects are included in the linear model since the discrete model changes are built into the time-domain simulation output file, which becomes a source of initialization data for the linear model.

Vehicle

The vehicle subsystem model contains hardware components (actuators, engines, reaction control system, sensors), equations of motion (rigid body translation and rotation, flexible body dynamics, slosh, tail-wags dog), mass properties, environment, and aerodynamics (Figure 7). These subsystems are explained in more detail below.

Dow

nloa

ded

by S

tanf

ord

Uni

vers

ity o

n O

ctob

er 7

, 201

2 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

002-

4687


Figure 3. Non-linear Simulink model.

Figure 4. Linear Simulink model.

cmd_TVC

cmd_VLV

simTime

SM_AIR_IGN

BME_LO_VE_ENABLE

VE_CUTOFF

t_ENG

f lag_lif tof f

BME_started

SRM_burning

BME_attached

SRM_attached

fairing_attached

S2E_attached

conf ig

pay load_attached

rgy ro

rlg

accel

SRM_burnout

Vehicle

BME_started

SRM_burning

cmd_VLV

VE_CUTOFF

BME_LO_VE_ENABLE

SHR2_INPUT_DISC

FIPS_PICKUP

FLIGHT_LOCK_IN_GND_CMD

SRM_IGN_GND_CMD

LIFTOFF_GND_CMD

simTime

t_ENG

TIMING


SRM_IGN_GND_CMD

SRM_IGN_ENABLED

LIFTOFF_GND_CMD

SM_AIR_IGN

SRM_burnout

separation

lif tof f

BME_started

SRM_burning

BME_attached

SRM_attached

f airing_attached

S2E_attached

conf ig

pay load_attached

Scheduler

SHR3_VOTE_OUTPUT

FIPS_PICKUP

cmd_TVC

cmd_VLV

SRM_IGN_ENABLED

SM_AIR_IGN

BME_LO_VE_ENABLE

VE_CUTOFF

separation

Interface (Software to Acuator)

rgy ro

rlg

accel

eth

ev

shr2_raw_gy ro

Interface (Sensor to Software)

? ? ?

? ? ?

ETH

EV

SHR2_RAW_GYRO

SHR2_INPUT_DISC

simTime

SHR3_VOTE_OUTPUT

Flight Software

Dow

nloa

ded

by S

tanf

ord

Uni

vers

ity o

n O

ctob

er 7

, 201

2 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

002-

4687


2

S2_SEP

1

FAIRING_SEP

U U(E)

Selector~=

~=

(uint16)0

bitwiseAND

S2_SEP_MASK

bitwiseAND

FAIRING_SEP_MASK

1

Flight Software Discrete Output

Figure 5. Discrete command decoding.

1

cmd_TVC

cmd_roll

cmd_yaw_s1

cmd_pitch_s1

cmd_yaw_s

cmd_pitch_s

U U(E)

Selector

Reshape

Reshape

Reshape

Reshape

Reshape

Demux

ANLG_WORD V_DAC

DAC5

ANLG_WORD V_DAC

DAC4

ANLG_WORD V_DAC

DAC3

ANLG_WORD V_DAC

DAC2

ANLG_WORD V_DAC

DAC1

1

Flight Software Discret Output

Figure 6. TVC command decoding.

4

SRM_burnout

3

accel

2

rlg

1

rgyro

BME_attached

w_bwrti_b

f lex_IMU

f lex_RG

f sp_i

r_til2cm_til

dcm_i2b

rgy ro

rlg

accel

SENSORS

r_til2cm_til

cmd_VLV

mass_gas

f _rcs_b

m_cm_rcs_b

Reaction Control System

mass_prop_eng

mass_gas

BME_attached

S2E_attached

f airing_attached

pay load_attached

SRM_attached

SM_AIR_IGN

conf ig

mass_total

r_til2cm_til

idot_cm_b

i_cm_b

Mass Properties

f _aero_b

f _eng_b

f _rcs_b

m_cm_aero_b

m_cm_eng_b

m_cm_rcs_b

f lag_lif tof f

mass_total

a_grav _i

idot_cm_b

conf ig

i_cm_b

simTime

BME_attached

f _bme_b

r_til2cm_til

f _v e_b

f _sm_b

f _s2e_b

t_ENG

mass_prop_s2e

v _cmwrti_i

f _total_i

f sp_i

altitude

r_eci2cm_eci

d_eci2cm

a_cmwrti_til

dcm_i2b

w_bwrti_b

f lex_IMU

f lex_RG

dcm_b2i

a_cmwrti_b

f lex_BME

wdot_bwrti_b

f lex_VE

f lex_SM

f lex_S2E

Equations of Motion

altitude

r_eci2cm_eci

r_t il2cp_til

r_t il2cm_til

v _cmwrti_i

w_bwrti_b

dcm_i2b

dcm_b2i

d_eci2cm

p_atm

dens_atm

sos_atm

v _cpwrtwind_b

a_grav _i

Envi ronment

f lag_lif tof f

BME_attached

SRM_attached

S2E_attached

BME_started

SRM_burning

BME_LO_VE_ENABLE

VE_CUTOFF

cmd_TVC

cmd_VLV

t_ENG

r_t il2cm_til

a_cmwrt i_b

wdot_bwrti_b

p_atm

w_bwrti_b

f lex_BME

f lex_VE

f lex_SM

f lex_S2E

mass_prop_engines

f _engines_b

m_cm_engines_b

SRM_burnout

f _bme_b

f _v e_b

f _sm_b

f _s2e_b

mass_prop_s2e

Engines/Actuators

lif tof f

conf ig

dens_atm

sos_atm

v _cpwrtw_b

r_til2cm_til

f _aero_b

m_cm_aero_b

r_til2cp_til

Aerodynamics

16

payload_attached

15

config

14

S2E_attached

13

fai ring_attached

12

SRM_attached

11

BME_attached

10

SRM_burning

9

BME_started

8

flag_liftoff

7

t_ENG

6

VE_CUTOFF

5

BME_LO_VE_ENABLE

4

SM_AIR_IGN

3

simTime

2

cmd_VLV

1

cmd_TVC

Figure 7. Vehicle subsystem Simulink model.

• Environment: Given vehicle position from the equations of motion model, the vehicle environment can be derived. The environment model typically computes the gravitational acceleration, wind, pressure, and speed of sound. The pressure, speed of sound, and wind are often interpolated from look-up tables as a function of altitude.

• Engines/Actuators: TVC and Fin actuator models were developed with inputs from the flight software to vehicle interface subsystem. Tail-wags-

dog (TWD) dynamics couple the vehicle and actuator accelerations. TWD dynamics can be disabled via a switch option. Actuator models can be linearized numerically using the Matlab “linmod” function or manually by removing nonlinearities such as limiters. An engine subsystem is disabled if it has separated from the vehicle or if, for a liquid engine, the valve is closed by the flight software, via the flight software to vehicle interface. The engine models took forms consistent with the manufacturers

Dow

nloa

ded

by S

tanf

ord

Uni

vers

ity o

n O

ctob

er 7

, 201

2 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

002-

4687


propulsion system data. Typically vacuum thrust, exit area, and mass (or mass flowrate, or specific impulse) are interpolated as a function of burntime or percent burn. Because they are primarily a function of time and not vehicle state, engine thrust and mass do not directly play a role in the linearization. However, through TVC angle perturbations in the neighborhood of the trim point and flexible dynamics effects, thrust makes a contribution to the equations of motion in the linearized model. This contribution was derived analytically.

• Reaction Control System (RCS): Two types of reaction control system models were implemented, one with constant thrust, and the other with a blowdown system. The blowdown system tank model assumes isotropic flow of an ideal gas when one or more thrusters is commanded on by the flight software via the flight software to vehicle interface. Linearization of the RCS system was performed analytically using describing functions.

• Sensors: Sensor models included accelerometer and gyro models. For some vehicles the inertial measurement unit post-processing for heading (or azimuth), altitude, longitude and latitude (or elevation) was included. Some vehicles have navigation built into the flight software. Sensor models can be linearized numerically using the Matlab “linmod” function or analytically by removing nonlinearities like limiters.

• Aerodynamics: The airframe model computes aerodynamic forces and torques based on angle of attack, sideslip, aerodynamic roll angle and Mach number and control surface deflections. Aerodynamic coefficients are functions of not only atmospheric conditions, but also vehicle configuration as shown in Figure 8. If aeroelasticity is modeled, additional inputs from the flexible dynamics model would be input to the airframe model. Numerical linearization can be used to develop a linearized airframe model from the non-linear model, except near the discrete model changes, where the derivatives cannot be computed. For that reason, we recommend using analytically derived linear airframe model. The vehicle configuration can be output from the time-domain simulation to be used for linear analysis table selection as a function of time.

• Equations of Motion: Equations of motion include rigid body translation and rotation, flexible body dynamics, slosh dynamics, and separation dynamics. Multi-body tail-wags-dog effects are

accounted for in the actuator models. Rigid body equations of motion were linearized analytically for GN&C stability analysis.

• Mass Properties: Like the aerodynamics subsystem, the mass properties subsystem is configuration dependent (Figure 9). However, the switching does not always match that of aerodynamic and flex data. The mass properties model implementation depends on the data available. For example, look-up tables of aggregate inertia and center of mass as a function of total mass from a preprocessor can be used. Alternatively, the aggregate vehicle mass properties can be computed in situ by combining component or combining component mass properties using the parallel axis theorem. Mass properties transferred from the time-domain simulation output to the linear analysis tool, however, linearization of the mass properties subsystem is generally not needed because they are independent of traditional perturbed states in a stability analysis.

Scheduler and Timing The scheduler and timing subsystems are discussed together because of their strong coupling. Discrete events and timing fall into several categories explained below:

• Component separation: Stage and fairing separation events in ELV simulations drive discrete aerodynamic coefficient, mass property, and flexible dynamics data changes. These model changes can be facilitated by making the underlying models a function of vehicle configuration. Model changes for separation events like booster separation or ordinance drop can be controlled the same way either using outputs directly from the flight software to vehicle interface (Figure 5) or using output from the Stateflow model (Figure 10) which tracks the overall vehicle configuration.

• Propulsion valve control: Liquid engine and reaction control system valve control is governed by the flight software model via the flight software to vehicle interface using decoding similar to the ordinance command decoding shown in Figure 5.

Dow

nloa

ded

by S

tanf

ord

Uni

vers

ity o

n O

ctob

er 7

, 201

2 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

002-

4687


7

r_ti l2ar_ti l

6

dref_x_sref

5

sref

4

cx

3

cn

2

cm

1

cl

flag_s

flag_s1_0s0f

flag_s1_0s1f

flag_s1_3s0b

flag_s1_3s3b

flag_s1_6s3b

flag_s1_9s0b

flag_s1_9s6b

flag_s1_9s3b

Reshape

Reshape

Reshape

Reshape

Reshape

Reshape

Reshape

Reshape

Reshape

Merge

OR

Demux

alpha

mach_no

phia

clcmcncx

srefdref _x_sref

r_til2ar_til

alpha

mach_no

phia

clcmcncx

srefdref _x_sref

r_til2ar_til

alpha

mach_no

phia

clcmcncx

srefdref _x_sref

r_til2ar_til

alpha

mach_no

phia

clcmcncx

srefdref _x_sref

r_til2ar_til

alpha

mach_no

phia

clcmcncx

srefdref _x_sref

r_til2ar_til

alpha

mach_no

phia

clcmcncx

srefdref _x_sref

r_til2ar_til

alpha

mach_no

phia

clcmcncx

srefdref _x_sref

r_til2ar_til

alpha

mach_no

phia

clcmcncx

srefdref _x_sref

r_til2ar_til

alpha

mach_no

phia

clcmcncx

srefdref _x_sref

r_til2ar_til14

phia

13

mach_no

12

alpha

11

s2

10

s1_0F

9

s1_1F

8

s1_456BO

7

s1_456B

6

s1_456B_789BO

5

s1_123BO_456B_789BO

4

s1_123BO_456NB_789BO

3

s1_123B_456NB_789BO

2

s1_123BO_456NB_789B1

s1_123B_456NB_789B

Figure 8. Aerodynamic data selector.

• Flight software scheduling: Controller filter and mode changes were accomplished by including the flight software sequencer in the flight software model. The sequencer model uses data as a function of time or a measured vehicle condition (e.g., measured acceleration) directly from mission data as in the actual flight software.

• Ground commands: Ground commands can be fed in as inputs to the timing block or the time a particular ground command is to be executed can be entered via a parameter. These can be conditioned on flight software state and vehicle

measurements. For example, in Figure 11, engine ignition occurs when the ground command is given only after ignition enabled becomes activated by the flight software.

• Flight software time bases: Flight software model execution can be governed using an enabled subsystem driven by a clock (acting like a hardware timer driving a real-time interrupt) as in Figure 12. Latency can also be added to the model as shown in the same figure.

Dow

nloa

ded

by S

tanf

ord

Uni

vers

ity o

n O

ctob

er 7

, 201

2 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

002-

4687


2

i_cm_b

1

r_til2cm_ti lMerge

mass_total

r_til2cm_til

i_cm_b

mass_total

r_til2cm_til

i_cm_b

mass_total

r_til2cm_til

i_cm_b

mass_total

r_til2cm_til

i_cm_b

mass_total

r_til2cm_til

i_cm_b

mass_total

r_til2cm_til

i_cm_b

OR

OR

Demux

12

mass_total

11

s2

10

s1_0F

9

s1_1F

8

s1_456BO

7

s1_456B

6

s1_456B_789BO

5

s1_123BO_456B_789BO

4

s1_123BO_456NB_789BO

3

s1_123B_456NB_789BO

2

s1_123BO_456NB_789B

1

s1_123B_456NB_789B

Figure 9. Mass properties data selector.

Figure 10. Stateflow subsystem.

Dow

nloa

ded

by S

tanf

ord

Uni

vers

ity o

n O

ctob

er 7

, 201

2 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

002-

4687


1

Flight Software Discrete Input

0

(double)

(uint16)bitwiseOR

FLIGHT_LOCKIN_MASK

bitwiseOR

LIFTOFF_MASK

2


1

LIFTOFF_GND_CMD

Figure 11. Ground command switching.

1

SHR3_VOTE_OUTPUTz

1

Unit Delay

ETH

EV

SHR2_RAW_RGYRO

SHR2_INPUT_DISC

simTime

SHR3_VOTE_OUTPUT

Flight Software

(uint16)

5

simTime

4

SHR2_INPUT_DISC

3

SHR2_RAW_GYRO

2

EV

1

ETH

Figure 12. Flight software clocking and latency.

• Engine burn time: Engine burn times are tracked as a function of valve opening for liquid engines and relative to ignition time for an engine that fires until burnout (Figure 13). The burn times are used for propulsion look up tables, that include vacuum thrust, mass and slosh properties as a function of burn time.

t_S2E

t_BME

1

t_ENG

t_S2E

t_BME

Reshape

Reshape

t_burn

BURN_TIME_INTEGRATOR

clock

logical

t_burn

BURN_TIME_BME

3

clock2

BME_started

1

S2E_VALVE_OPEN

Figure 13. Engine burn time examples.

Sensor to Flight Software Interface The sensor to flight software interface performs analog to digital (A/D) conversion and other necessary signal conditioning not included in the sensor or flight software models. Linearization would include quantization and latency.

Simulation and Analysis

Simulation and analysis tools are linked via common inputs and input of simulation output to the stability analysis (Figure 1). Matlab post-processing capabilities enable ready access to results (Figure 14). In addition, input data can be just as easily verified. Monte Carlo analysis or stress cases are enabled by simply changing the parameters in Matlab and running the simulation repeatedly using a batch script rather than through the Simulink GUI.

-200 0 200 400 600 800 1000 1200 1400 16000

1

2x 10

7 Inertial position (ft)

x

Vehicle ModelFlight Software NavigationMECO TargetSECO1 TargetSECO2 Target

-200 0 200 400 600 800 1000 1200 1400 16000

1

2

3x 10

7

y

-200 0 200 400 600 800 1000 1200 1400 1600-5

0

5

10x 10

6

Time (s)

z

Figure 14. Time domain simulation output. For any point along the mission time line, it is possible to use the operating point directly from the simulation output along with trim information to initialize the linear analysis tool for stability analysis. Given the linear model assembled using series and parallel connections in Matlab or using the Matlab function “linmod” to create the linear system from a Simulink model (e.g., Figure 4), Matlab functions can be used directly to compute single-input single-output (SISO) stability margins or multi-input multi-output (MIMO) singular values (Figures 15 and 16). In addition, bode plots, Nichols charts, and other frequency domain analysis tools can be readily applied in Matlab given the linear system (Figure 17).

Benefits Regardless of the chosen platform, there are many benefits of integrating GN&C and mission analyses. Flight software testing and debugging can be performed in more realistic environments, which include failure detection and isolation, simulated easily using Stateflow or other blocks (e.g., switches). By replacing sensor and actuator models with hardware components, hardware-in-the-loop (HITL) tests can be done progressively while maintaining good traceability.

Dow

nloa

ded

by S

tanf

ord

Uni

vers

ity o

n O

ctob

er 7

, 201

2 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

002-

4687


0 10 20 30 40 50 60 70 80 90 1007

8

9

10

11

12

13

14

15PLOT COMPARISON -- Gain/Phase Margins -- Elevator Loop Frequency Response

Time (s)

Gai

n M

argi

n (d

B)

0 10 20 30 40 50 60 70 80 90 10020

25

30

35

40

45

50

55

60

Time (s)

Pha

se M

argi

n (d

eg)

RBFLEXFLEX-TWD

Figure 15. SISO stability analysis margins output.

0 10 20 30 40 50 60 70 80 90 100-10

-5

0

5

10

15MIMO Stability Margin Assessment

Time (s)

Gai

n M

arg

in (

dB)

Upper BoundLower Bound

0 10 20 30 40 50 60 70 80 90 100-50

-40

-30

-20

-10

0

10

20

30

40

50

Time (s)

Pha

se

Mar

gin

(de

g)

Upper BoundLower Bound

Figure 16. MIMO stability analysis margins output.

10-6

10-5

10-4

10-3

10-2

10-1

100

101

102

103

104

-270

-180

-90

0

90

180

270

Elevator Loop Frequency Response -- Min. Gain Margin at Time: 91 sec.

Bode Plot

Phase (deg)Gain (dB)

Frequency (rad/s)

GainPhase

10-6

10-5

10-4

10-3

10-2

10-1

100

101

102

103

104-720

-540

-360

-180

0

180

360

-720 -540 -360 -180 0 180 360-330

-220

-110

0

110

220

330Nichols Plot

Phase (deg)

Gain (dB)

Stability Margins:

Gain Marigns: -62.1173 dB @ 0.00042522 rad/s

-57.9337 dB @ 0.24479 rad/s

-8.2859 dB @ 0.50868 rad/s

22.4033 dB @ 7.7282 rad/s

72.9396 dB @ 30.2204 rad/s

156.398 dB @ 438.3302 rad/s

Phase Marigns: 22.9743 deg @ 0.81446 rad/s

Figure 17. Bode and Nichols plot stability analysis snapshot.

Because the tool is integrated, using common data sources reduces the verification burden and minimizes the number of data ingest tools. In our tool development, many models have been reused in the linear and nonlinear simulation models for different types of vehicles as well. New development can benefit from the tool’s heritage. Due to its expandability, the current models can be easily integrated with the payload modules and performance validation modules due to the flight conditions and the mission profiles. Using Matlab as the platform yields additional benefits. Since automatic code generators (Matlab’s Real Time Workshop) are mature enough to generate flight software5 and the related documents, the tested flight algorithm block can be translated to the actual flight code. Matlab/Simulink provides many design modules (time-domain and frequency domain analysis tools) and post-analysis tools (plot routine and statistical routines), which can be used to reduce design time.

Conclusions Advancements in Mathworks tools has made it more practical to integrate GN&C and mission analyses. An architecture for this integrated tool was presented based on expendable launch vehicle GN&C and mission analysis tools provided to NASA KSC, would provide a starting point for similar applications to launch vehicle design.

Acknowledgement This paper was based on simulation and analysis tools prepared for NASA Kennedy Space Center Expendable Launch Vehicles Mission Analysis Branch under the program management of Mr. Vernon Wikander.

References 1. Rauw, M.O. “FDC 1.2 - A Simulink Toolbox for

Flight Dynamics and Control Analysis,” Zeist, The Netherlands, 1997.

2. Magni, J-F, Bennani, S. and Terlouw, J. (Eds), Robust Flight Control: A Design Challenge, Springer-Verlag London Ltd, 1997.

3. Waldraff, W., Finsterwalder, R., "MASTER-Project Overview for the Development of a Modular Vehicle Simulator," AIAA Modeling and Simulation Technologies Conference and Exhibit, 6-9 August 2001, Montreal, Canada.

4. Tischler, M., "CONDUIT-A New multidisciplinary Integration Environment for Flight Control Development," NASA TM-112203, June 1997.

5. Nguyen, V. H., Chaudhary, A. K., Poladian, D., Wong, V. L., and Zyss, M. J., “The GN&C of the SMV (Space Maneuver Vehicle) Flight Test Vehicle: Rapid Design of an Unpowered Autolanding System,” AAS GN&C 98-024.

Dow

nloa

ded

by S

tanf

ord

Uni

vers

ity o

n O

ctob

er 7

, 201

2 | h

ttp://

arc.

aiaa

.org

| D

OI:

10.

2514

/6.2

002-

4687

[american institute of aeronautics and astronautics aiaa modeling and simulation technologies...

Documents