parametric diagnostics of flight control and propulsion for...
TRANSCRIPT
Submitted to AIAA Journal of Guidance, Control, and Dynamics • June 2004
1
Parametric Diagnostics of Flight Control and Propulsion for Rocket Ascent
Dimitry Gorinevsky∗ Honeywell Labs, Fremont, CA 94539
John R. Bain Honeywell Space Systems, Houston, TX 77058
Gordon Aaseng Honeywell Space Systems, Glendale, AZ 85308
∗Corresponding author: Honeywell Labs, 47102 Mission Falls Court, Fremont, CA 94539; phone: (510) 360-7906, e-fax: (208) 545-6408; e-mail: [email protected], [email protected]
Abstract. This paper describes a case study of model-based diagnostics system
development for a space launch vehicle application. The diagnostics algorithms
described in the paper can work with on-board or telemetry flight data. The key
innovation is in designing a distributed diagnostics system that directly uses
parametric data, such as sensors data. The computations are partitioned between the
subsystems and a central IVHM system to match the system knowledge partitioning.
The subsystem algorithms use detailed systems models. The central algorithms use
cross-vehicle fault signature knowledge. The developed algorithms provide fault
condition estimates that allow for consistent detection of incipient performance faults
and abnormal conditions.
2
1. Introduction This paper demonstrates an application of model-based parametric diagnostics approach to a space
vehicle GN&C-related application. This is done through a case study detailed in this paper. The
need for integrated vehicle health management (IVHM) has been long recognized. IVHM
functionality is a major requirement for the development of next generation space vehicles. The
main benefits expected from an IVHM system include:
• Improving system safety by detecting faults and acting on this information. The actions can
include control system reconfiguration, alerting, or mission management.
• Reducing cost and time required for maintenance and vehicle readiness checks. This is
particularly important for the next generation reusable vehicles that are supposed to have
much shorter turnaround and mission preparation time.
Achieving these benefits requires evaluating the system health state from the vehicle sensor data.
The health state evaluation logic might reside in the vehicle avionics or be based on ground and use
telemetry or flight-logged data. A basic approach to fault detection is through a range or threshold
checking of the sensor data. Recent advances in fault detection technology extend this in two
directions. One is developing IVHM systems capable of vehicle-wide integration of the fault
detection results to achieve a more accurate understanding of the fault root cause. Another is using
parametric data from the sensors and detailed system models to discriminate between component
deterioration and environmental influences.
The most prominent example of currently deployed IVHM system for an aerospace vehicle is the
Boeing 777 CMC (Central Maintenance Computer) developed by Honeywell in the 90s [9]. The same
technology was subsequently used in Honeywell’s Primus Epic CMC and AMOSS ground based
aircraft maintenance automation systems. The CMC computer is a separate avionics piece
connected through the vehicle buses to avionics of all the vehicle subsystems. Each subsystem has
its own diagnostics function, such as BIT/BITE (Built-In Test / Built-In Test Equipment). The
subsystems provide diagnostics messages in a predefined format. The CMC collects these messages
and reasons out the fault root causes that might have caused all these messages. As one example, a
3
single failed sensor or a loose connector might cause several hundred subsystems to announce
faults of different types. In this design, the subsystem diagnostics are typically developed and
implemented by the subsystem hardware vendors who have the detailed application knowledge.
The central IVHM function – the CMC – integrates these diagnostics and embeds the knowledge
how the subsystems are integrated in the vehicle.
This work discusses a step beyond the above described discrete diagnostics IVHM architecture and
towards parametric diagnostics. Instead of dealing with discrete data (fault/no fault, in/out of bound
measurement, etc), the parametric data comprising grey-scale sensor values are considered.
Compared to the discrete data diagnostics, the processing of parametric data has a number of
important benefits:
In general, parametric diagnostics are more detailed and accurate than discrete diagnostics
because they are based on more detailed data.
Parametric estimation of fault condition allows for providing more specific alerts, compared
to a mere presence of a fault, such as: ENGINE THRUST IS 5% BELOW THE NOMINAL.
Parametric estimation and diagnostics provides data necessary for prognostics trending.
This brings a potential benefit of a identifying an incipient fault condition and taking a
premeditative action (e.g., performing maintenance) before the fault has fully developed.
Parametric estimation can be used to discriminate between sensor drift and a system
problem
Typically, this work no exception, parametric diagnostics are based on using models of the system.
These models allow predicting system output variables based on the ambient conditions and input
variables. Such models are expensive and developing them requires detailed application
knowledge. Therefore parametric diagnostics, at least initially, should be focused on most critical
systems and functions, where the benefits are the strongest.
An approach to parametric fault estimation presented herein assumes that at least some of the
computations should be performed on the vehicle subsystem level. At the same time, a central
4
IVHM system is necessary for integrating the subsystem processing results and providing vehicle
level estimation and prognostics. Development of parametric diagnostics for vehicle subsystems
typically requires using detailed simulation models of subsystem dynamics. On another hand,
development of the central IVHM function requires understanding of how the subsystems are
integrated within the vehicle and what are cross-system fault signatures. The goal of this work is to
demonstrate these system architecture concepts in a case study of parametric diagnostics: estimation
of fault parameters for flight control (GN&C) and propulsion systems of the vehicle. In addition to
these, flight controls actuator – main engine gimbal actuator – is included as a separate subsystem in
this study.
The state of the art in parametric diagnostics is mostly defined by the FDI (Fault Detection and
Identification) work done in the controls community over last decade. A substantial literature on the
subject has been published, including several books, e.g., see [2], also see the surveys [2, 5, 7]. This
literature assumes availability of detailed dynamical models in analytical form, typically linear
models. Detailed fault models are usually assumed to be an integral part of the dynamical models.
Various analytical algorithms have been developed that estimate presence and sometimes
parameters of the faults from the available data. These approaches have practical implementation
deficiencies for the problem in hand.
Instead of analytical linear models, most of realistic detailed simulations in aerospace industry use
comprehensive nonlinear models developed by teams of people. When used in an IVHM
development, these are best described as ‘black-box’ models. This means a software implementation
of the model can be run to obtain results, but detailed analytical structure of the model is usually
unavailable.
The published FDI methods usually assume that the model is available as a single integrated block.
At the same time, the detailed knowledge of and modeling capability for different vehicle
subsystems is usually vested with different subsystem developers. A practical design of IVHM
system should take this fact into account.
In addition to the subsystem-level detailed FDI, there is a need for a centralized insight into faults
that manifest across different subsystems. This is not addressed in the existing FDI literature.
5
In this work the algorithms use linearized fault models for model prediction residuals. The
approach is an extension of the optimal fault estimation approach applied in [4]. However, instead
of point-wise estimation in [4], the faults are estimated by a linear-quadratic receding horizon
algorithm. Some of the prior work on the receding horizon estimation can be found in [1, 8].
2. Technical problem
The parametric IVHM system design approach described below has a broad applicability. In this
work it is explained and demonstrated in a case study. The object of the case study is a simulation
for ascent of a “Space Shuttle class” launch vehicle. The simulation provides a representative
environment for application of model-based Integrated Vehicle Health Management (IVHM). In the
case study, model-based IVHM algorithms attempts to determine selected “deterioration
parameters” seeded in the simulation.
The algorithms demonstrated in this paper assume that the data from flight (GN&C), propulsion,
and engine gimbal subsystems are available for processing at a high sampling rate. The algorithms
can reside in on-board avionics of the vehicle. In that case, the data is assumed to be transmitted
over on-board avionics buses of the vehicle and available to health management processors as
required. Alternatively the data can be transmitted in a telemetry stream and the algorithms reside
in an on-ground health management system. The conceptual computational logic and algorithms
partitioning are the same in either case.
The goal is to demonstrate estimation of the fault parameters describing degradation in the
propulsion engine (thrust loss), degradation or damage of the vehicle aerodynamic surface (drag
increase), degradation in the thrust vectoring system (gimbal actuator sluggishness), and signal drift
fault in a GN&C sensor (pitch sensor offset). The approach of this work consists of the following
three steps. First, a detailed simulation model is set up to simulate the relevant telemetry (or the
vehicle bus) data. The model allows simulating the faults in question. The results of the simulation
with the (known) seeded faults are logged and stored in a data file for subsequent processing. The
6
data in the file is subsequently replayed and processed by the developed fault estimation
algorithms. These algorithms have no information on the seeded faults and can be validated by
comparing the seeded and estimated fault parameters.
As a second logical step in the development, we discuss subsystem-level algorithms for computing
residuals from sensor data using subsystem prediction models. These residuals indicate an off-
nominal behavior of the system and are indicative of the fault presence. The residual computation
and prediction models are described in Section 3 of this paper.
Finally, the algorithms for estimating fault parameters from the residuals are described in Section 4.
These centralized algorithms use the prediction residuals from all subsystems and could reside in a
separate central IVHM processor. An important part of the estimation algorithm is computation of
fault sensitivities (fault signatures) for each of the faults. These fault signatures are subsequently
used by a receding horizon estimation algorithm performing a multivariate curve fit to compute
updates for the fault parameter estimates.
The discussion in this paper ends wth obtaining the fault parameter estimates. Getting these
estimates in consistent and accurate way is the most technically challenging part of the parametric
health management functionality. At the same time, the largest application value is in using the
obtained estimates on the fault parameters for alerting and decision making. The alerting and
decision logic is highly dependent on the application and accepted procedures. Discussing this logic
is outside of scope of this work.
As a part of the case study, a simulation model of the launch vehicle ascent was developed. This is a
simplified model of a Space Shuttle class vehicle that is based on data published in the open
literature. Detailed engineering simulations of Space Shuttle used by NASA have in excess of 100
states, and thousands of parameters. Details of such complex simulations are understood by teams
of people. Unlike that, the simulation set up in this study has on the order of 10 states, a few dozen
parameters, and is understood by a single person. The simulation describes the rocket launch flight
phase. Though the detail of the simulation is not presented here, below are some highlights.
7
A set of ordinary differential equations (ODE) numerically integrated in the simulation comes from
physics model describing dynamics of the system. The simulated ODE system is stiff, because the
timescales for rocket motion and fast GN&C actuator are very different. The magnitude of the
variables runs many orders of magnitude. For instance, the control toque is required to move a 5⋅106
lb thrust engine bell for angle tracking of ~10-3; while the final value of the achieved altitude is
~5⋅105.
We simulate a two-stage vehicle with liquid fuel (H2 and O2) delivering a “medium” payload to
LEO. We consider in-plane dynamics only for a planar equatorial flight that terminates in a 0°
inclination orbit. The modeling includes variation of mass, center of gravity, and moment of inertia
with the propellant expenditure. An aerodynamical model is borrowed from an asymmetric vehicle
(first stage drag minimum is at small positive angle of attack. The model assumes non-rotating
spherical Earth with inverse square gravitational field and exponential atmosphere. In the example
below, the first stage trajectory and vehicle data are primarily considered. This is because air drag is
still present and one of the considered fault symptoms is a drag increase
A simplified model of the GN&C system is implemented as a part of the simulation. In a trajectory
following guidance/control scheme, the engine bell is gimbaled to attain desired pitch angle while
the thrust is maintained at 100% (it is a function of altitude and stage). We assume a full-state
measurement to be available for the vehicle dynamics. A Neighboring Extremal (NE) closed-loop
guidance uses a point mass simulation to calculate the minimum fuel trajectory. NE guidance is
implemented as a full-state proportional feedback, which does not steer back to the original optimal
trajectory. Instead, at each guidance calculation, if the vehicle has deviated from the optimal path,
NE guidance provides the desired control for the optimal trajectory from that point to the desired
endpoint. A PID controller tuned using “trials-and-errors” is used for the main engine gimbal
actuator to keep the vehicle on the trajectory.
The simulation is PC based and programmed in Mathworks’ Simulink as a “continuous time”
model with Runge-Kutta integration of ODEs. The simulation covers the 370 sec trajectory of ascent
8
into an 80 x 150 nm equatorial orbit. The vehicle launch mass is 1.0438⋅108 slugs; mass flow rate is
constant in each stage; staging occurs upon expending of first stage propellant at tstage = 153.54 s. The
sensor and control data is logged at a 0.1 s sampling interval through the simulation run and saved
into a data file. The simulation model includes an ability to add (seed) the faults described in
Section 4.
The next section describes some detail of the prediction models. These are based on the same
underlying dynamics knowledge as the simulation but are differently structured, towards the needs
of the IVHM algorithms. One major difference is that simulation includes closed-loop GN&C
algorithms, while the prediction model just uses the actually applied control effort without a need
to detail how it was computed.
3. Residual computation and prediction model
The three subsystems considered in this case study (GN&C, Propulsion, and Gimbal) each include
an embedded model that allows computing prediction residuals from the available sensor data. The
fault parameter estimation from these residuals is performed by the central IVHM system. This
section discusses the prediction models and residual computations performed by the subsystems,
the following section – the fault estimation computations in the central IVHM system.
The general idea of the prediction model is to divide the variables describing subsystem operation
into two parts: inputs (this includes ambient condition data and data from other subsystems) and
outputs. The prediction model allows computing the outputs given the inputs. The differences
between the predicted (computed) and actually observed outputs make the prediction residuals.
Assuming that the prediction model accurately describes the nominal subsystem behavior, the
residuals should be zero if there is no fault. Nonzero residuals indicate that a fault is present.
It is important to emphasize that the prediction models for subsystems conceptually differ from the
simulation models. While the prediction model uses some of the available data to predict other data,
the simulation model is used to predict system evolution over the time. These models might be
9
based on the same system knowledge and contain some of the common blocks, but nevertheless are
conceptually very different.
Two types of data are processed in a predictive model of each subsystem. First is the sensor data
from the sensors attached to this subsystem. In addition to being processed internally, this data is
provided to other subsystem through the data buses. The second type of data is the external data
from other subsystems. This comprises both the raw sensor data and the derived variables
computed by other subsystems. The prediction residuals computed by the subsystems are provided
to the central parametric IVHM system.
A generic view of subsystem-level computations is outlined in Figure 1. One type of the processed
data is the data from the sensors attached to this subsystem. This data is provided to other
subsystems. The second type of data is the external data from other subsystems: the raw sensor data
and/or the derived variables computed by other subsystems. The model-based computations in the
subsystem provide the derived variables to other subsystems as well as the prediction residuals for
the central IVHM system.
predictionresidualsSu
bsys
tem
Internal data data Externaldata
sensors
Data from other subsystems
variableestimates
To central IVHM system
To other subsystems
Model-based
estimation
Figure 1: Member System for parametric diagnostics and prognostics.
Let us now consider the subsystem computations design for the three subsystems in this case study:
G&C, Propulsion, and Gimbal. These computations are based on the shared data available on the
vehicle avionics buses and in the telemetry stream. The data assumed to be available at a high
smapling rate include the following.
10
Vehicle state data
Downrange angle κ measured in rad
Altitude h measured in ft
Velocity v measured in ft/s
Flight path angle γ measured in rad
Engine gimbal angle δ measured in rad
Engine rotational rate ωe measured in rad/s
Vehicle rotational rate ω measured in rad/s
Pitch angle θ measured in rad
In the analysis to follow, the data listed above is collected in a state vector X,
[ ]T
evhX θωωδγκ= (3.1)
Vehicle accelerations and rates
The state variables in vector X (3.1) enter the right hand sides of equations of motion describing the
simulation model. In addition to these variables, some of the derivatives in left-hand side of these
equations are assumed to be available. These include
Vertical acceleration dv/dt measured in ft/s2
Flight path angle rate dγ /dt measured in rad/s
Vehicle rotational acceleration dω/dt measured in rad/s2
The vertical acceleration dv/dt and rotational acceleration dω/dt of the vehicle are directly measured
by the accelerometers in the inertial navigation system (INS) of the vehicle or can be computed as a
transformation of such direct accelerometer measurements. The flight path angle rate can be
estimated from high rate flight path angle measurements, other attitude measurements and the
actual path measurements. In the analysis to follow, the three mentioned accelerations are collected
in a vector A
T
dtd
dtd
dtdvA ⎥⎦
⎤⎢⎣⎡= ωγ
(3.2)
11
Gimbal actuator servo data
In the diagnostics algorithms to follow, the vehicle dynamics variables (3.1) and (3.2) are
complemented by the Gimbal actuators subsystem measurements. The following two variables are
assumed available:
Gimbal actuator position xact measured in rad
Gimbal actuator servo command xd measured in rad
The data from the above described sensors obtained in a simulation run is shown in Figure 2. The
time interval in the plots covers the first stage ascent. The data in the plots is the raw data and is
used by the below described algorithms to estimate the fault parameters for the vehicle.
50 100 150-1.405
-1.4
-1.395
-1.39
Downrange angle (rad)
50 100 150
5
10
15
x 104 Altitude (ft)
50 100 150
2000
4000
6000
8000 Velocity (ft/s)
50 100 150 0.40.60.8
11.2
Flight path angle (rad)
50 100 1500
5
10
15 x 10
-3 Engine gimbal angle (rad)
50 100 150 0
5
10
15
x 10-3Engine rotational rate (rad/s)
50 100 1500
5
10
15
x 10-3 Vehicle rotational rate (rad/s)
50 100 150
0.60.8
11.21.4
Pitch angle (rad)
50 100 150-0.05
0
0.05
Gimbal command (rad)
Time (s)50 100 150
-0.04-0.02
00.020.04
Gimbal position (rad)
Time (s) Figure 2: Sensor data traces obtained in the first stage ascent simulation
12
3. 1 Flight dynamics (GN&C) subsystem
Consider first the residual computation for the flight dynamics (GN&C) subsystem. The prediction
model is based on the same dynamics equations as used in the simulation model. The two equations
for center of mass motion have the form
[ ]γmgDδαTm
v sin)cos(1 −−+=& (3.3)
hrγvγmgLδαT
mvγ
s ++−++= cos]cos)sin([1
& (3.4)
The two attitude dynamics equations for the in-plane motion of the main rocket body and the
engine are
Qmmδmlω
αDαLαDαLlmωδmωJ
QmmδmlTδωm
αDαLmllmmωδmωJ
e
eeee
ee
cpee
)(]sin
)cossin()sincos[(cos
)(sinsin
)sincos]()[(cos
2
**
2*
**
+−−
+−++−=+
++−+
+−+=+
&&
&&
(3.5)
The mass, rotational inertia, and geometric parameters of the vehicle such as
secpee rlllmmmJJ ,,,,,,,, *** , in (3.3)--(3.5) are assumed to be known or are computed on-line from
the vector (3.1). The parameters L and D are respectively lift and drag. These forces can be
computed from the state vector X. The lift and drag depend on the pitch angle α = θ - γ and the
Mach number (the speed v). Computing L and D requires also knowing the atmospheric density,
which can obtained through the density tables based on the attitude h. The steering torque Q in
(3.5) is a result of the thrust vectoring and can be computed as
acttorque xKQ = , (3.6)
where Ktorque can be approximately assumed to be a constant. Finally, the thrust T in (3.5) comes
from Propulsion subsystem computations (see below).
13
The two coupled rotational dynamics equations (3.5) can be resolved with respect to the angular
accelerations ω& and eω& . The predictive model uses only calculated ω& . Adding the calculated ω& to
the calculated accelerations (3.3)--(3.4) leads to the predictive model equations that can be compactly
presented in vector form as
( )txTXFv
actA ,,,=⎥⎥⎥
⎦
⎤
⎢⎢⎢
⎣
⎡
ωγ&
&
&
(3.7)
Comparing the computed accelerations (3.7) against the observed accelerations (3.2) yields a 3 x 1
prediction residual vector for the GN&C system
( )txTXFAr actAflight ,,,−= (3.8)
3. 2 Propulsion subsystem
In this work, no detailed model of the propulsion was used. This was because of the limited work
scope and the model availability. No dynamical state variables of the rocket engine are modeled in
the simulation example, no sensor measurements specific to the propulsion are assumed. In a real
vehicle there are additional engine-specific measurements. A predictive model using the additional
measurements could produce additional residuals correlated with the thrust loss. This would
improve estimation accuracy.
The propulsion system closely interacts with the flight control system through the thrust it delivers.
In the simulation, a simple propulsion model is used. The thrust is assumed to be available as a
function of time and altitude. The prediction model assumes that sufficient sensor data is available
to the propulsion subsystem for continuously calculating the thrust using an embedded model. It is
further assumed that this computation is accurate in the absence of the faults. The computed thrust
is used by other subsystems.
14
The simple model used for the thrust prediction was exactly the same as one used in the initial
simulation. This model can be expressed in the form
( )tXFT T ,= , (3.9)
where X is as in (3.1) and only the second component of the vector X is used in (3.9).
3. 3 Gimbal actuation subsystem
We used a simplified model for the hydraulic actuator of the main engine gimbal suspension. The
actuator is used for vectoring the main engine thrust and, thus, is the main control actuator. The
attitude torque produced by the thrust force depends on the vectoring angle actx controlled by the
actuator in accordance with (3.6). The bandwidth of the control feedback loop used to guide the
vehicle along the trajectory is critically limited by the sluggishness of this actuator. The gimbal
actuation includes a servo-system for tracking the desired vectoring angle dx and the closed-loop
feedback linearizes the dynamics of the system. The assumed linearized model of the dynamics is a
first-order model of the form
factdact ωxxx )( −=& , (3.10)
where fω is the servo-system bandwidth indicative of the actuator sluggishness. An increase on
the sluggishness reduces the bandwidth.
The predictive model is based on the actuator model (3.10) and uses the available actuator position
measurement actx and the servo-system setpoint measurement dx . The predictive model should
verify if these two measurements satisfy the system dynamics equation (3.10). This equation cannot
be verified directly because there is a derivative actx& in the l.h.s. (3.10). Differentiation is a
noncausal operation and cannot be implemented exactly. The solution is to use an approximate
smoothing differentiator. To extract the information about the sluggishness, the model prediction
residual is computed as follows
15
( )dactfs
acts
gymbal xxs
xs
sr −+
−+
= ωττ
1, (3.11)
where s is the Laplace variable (differentiator operator), sτ is a smoothing filter pole (time
constant) and the two transfer functions describe the filtering operators applied to the two
respective signals. The two filters in the r.h.s. (3.11) have proper and strictly proper transfer
functions and can be easy implemented. Note that if (3.10) is satisfied then the residual in (3.11) is
exactly zero. Applying a smoothing filter is a linear transformation of the signal. It does not offset
the residual, just brings about a filtering delay while enabling differentiator implementation.
In this work, the filter pole sτ was selected by a trial and error method and was chosen to be
ss 05.0=τ . A more systematic design of differentiating filters should take into account the
statistical properties of the noise influencing the differentiated signal. Such noise is not modeled in
(3.10) but would likely influence a real-life sensor signal.
3. 4 Computed residual
The residuals are functions of time. The overall residual vector collecting the subsystem residuals
(3.8) and (3.10) has the form
⎥⎦
⎤⎢⎣
⎡=
)()(
)(trtr
trgymbal
flight (3.12)
The residual vector r (3.12) has four components. Figure 3 illustrates these four components
computed for the first stage ascent data in Figure 2. The faults have been included in the simulation
in Figure 2, therefore the prediction residuals in Figure 3 are nonzero. These residuals are further
used by the fault parameter estimation algorithm.
16
0 20 40 60 80 100 120 140 160 0
0.5
1
1.5 ACCELERATION [ft/s2]
0 20 40 60 80 100 120 140 160 0
1
2
3 x 10
-3 FLIGHT ANGLE RATE [rad/s]
0 20 40 60 80 100 120 140 160 -5
0
5
10 x 10
-4 PITCH ACCELERATION [rad/s2]
0 20 40 60 80 100 120 140 160 -5
0
5 x 10
-3 SERVO RATE [rad/s]
TIME [s] Figure 3: Residuals computed from the first stage ascent simulation data.
4. Estimating fault parameters The computational data flow architecture for the parametric IVHM processing as applied to the
problem at hand is outlined in Figure 4. The overall parametric IVHM system consist of a Central
IVHM System and thee subsystems: Propulsion, GN&C, and Gimbal. Thus partitioned, the three
subsystems can be implemented on separate processors communicating through on-board
databases, or telemetry link, or telemetry link and on-ground network. The key advantage of the
architecture is that software development requiring detailed domain knowledge for a subsystem
can be relegated to the subsystem provider.
Each of the subsystems collects data from affiliated sensors and computes residuals as discussed
earlier in Section 3. This section discusses the central processing of the residuals in some detail.
17
4.1 Parametric IVHM architecture
The GN&C subsystem computations are shown as the upper left block in Figure 4 schematics and
are described in Subsection 3.1. The arrow labeled “Predicted acceleration residuals” describes
computation of the acceleration residuals (3.7) in accordance with (3.8). These residuals are sent for
further processing into the Central IVHM System.
The Propulsion subsystem logic in Figure 4 (the middle block on the left) is discussed in Subsection
3.2. This logic does not produce any residuals that are specific for the engine. However it uses the
available sensor data to produce an estimate of the engine thrust (3.9) that is used by the GN&C
subsystem for computing the predicted acceleration residuals.
Prop
ulsi
on
subs
yste
m
Internal data data External data
Propulsion sensors
Propellant component flows
ThrustestimateModel-
basedestimation
Predicted acceleration residual
Internal data data External data
GN&C sensors:
Thrust vector data Airflow probe data
Model-based
estimation
Internal data data External data
Position sensors
Commanded position
EngineorientationModel-
based estimation
Actuatorrate residuals
Central Parametric HM: Estimate Fault Parameters
Sluggish Gimbal Signature
Air Drag Change Signature
Reduced Thrust Signature
Fault Signatures
Central IVHM System Subsystem HM
GN
&C
su
bsys
tem
G
imba
l su
bsys
tem
Pitch Sensor Drift
Figure 4: Conceptual organization of the fault parameter computations
18
The residual computations in the Gimbal actuator subsystem are as outlined in Subsection 3.3 and
are shown as the lower left block in Figure 4. This subsystem provides a filter output (3.11) to the
Central IVHM subsystem. An arrow depicting flow of this data is labeled as “Actuator rate
residual” in Figure 4.
The Central Parametric HM block of Central IVHM Subsystem in Figure 4 is where the fault
estimates are computed. In addition to the residuals (3.12), the Central Parametric HM block uses
fault signatures as an input. These fault signatures and their computation is defined below in this
subsection.
4.2 Fault modeling
As mentioned above, four different faults are considered in this case study. The intensities of these
faults make a fault parameter vector
⎥⎥⎥⎥
⎦
⎤
⎢⎢⎢⎢
⎣
⎡
=
offsetsensor pitchsssluggishne gimbal
change dragair lossthrust
f (3.13)
The components of the vector f (3.13) are measured in percent. The fault parameters (3.13) are
introduced into the simulation and prediction models as follows.
Engine thrust
When simulating the engine thrust fault, the thrust value T computed in (3.9) and used throughout
various parts of the prediction (and simulation) models at each time instant is replaced by the value
Tf = (1 – 0.01 f1) T, (3.14)
where f1 is the percentage of thrust loss, the first component of the vector f (3.13). In the prediction
model, this fault is associated with the Propulsion subsystem. The engine thrust reduction can be
caused by multiple reasons. It might be an indication of the remaining useful life depletion for a
reusable engine.
19
Air drag change
The air drag increase might be caused by a damage of the aerodynamic surface of the launch
vehicle. With an aerodynamic return vehicle being a part of the launch vehicle (such as Space
Shuttle orbiter or a planned OSP vehicle) the drag increase might indicate damage to the protective
covering of the return vehicle surface. This could be a serious problem, such as one in the Columbia
accident. This fault is simulated by replacing an instantaneous value of the air drag D in the flight
dynamics equations (3.3) and (3.5) with an increased drag
Df = (1 + 0.01 f2) D, (3.15)
where f2 is the percentage of the drag increase, the second component of the vector f (3.13). In the
prediction model, this fault is associated with the GN&C (Flight dynamics) subsystem.
Gimbal actuator sluggishness
The sluggish response of the gimbal actuator air drag increase can be caused by a hydraulic valve
problem or pressure loss in the hydraulic system of the actuator. This fault is simulated by changing
the bandwidth fω in gimbal dynamics equation (3.10) into the fault-modified value
1001808 3
0fωω f ⋅−= π
, (3.16)
where f3 is the percentage of the sluggishness increase, the third component of the vector f (3.13).
The nominal open-loop bandwidth of the actuator is assumed to be 10 35.0 −= sω (the actuator time
constant of 2.86 s). The 100% sluggishness increase of the fault corresponds to the open-loop
bandwidth reduction to 10 21.0 −= sω (the actuator time constant of 4.77 s). In the prediction model,
this fault is associated with the Gimbal actuator subsystem.
Pitch sensor fault
In this work, pitch sensor fault was modeled as a gain (calibration) error of the sensor. The pitch
sensor fault is simulated by replacing an instantaneous value of the pitch angle θ used in the GN&C
control law computations with the modified value
20
θf = θ /(1 + 0.01 f4) , (3.17)
where f4 is the percentage of the sensor gain loss, the last (fourth) component of the vector f (3.13).
In the prediction model, this fault is associated with the GN&C (Flight dynamics) subsystem. Both
the prediction and simulation models of the flight dynamics include GN&C control law as an
integral, but separate, part.
4.3 Sensitivity modeling
The fault parameters in (3.14)—(3.17) enter the system dynamics in a nonlinear way. The central
IVHM algorithms used in this work are based on a fundamental assumption that the system
dynamics changes caused by these faults is relatively small in most operating conditions. Thus, it
becomes possible to linearize the dependence of the residuals on the faults without loosing too
much accuracy. The estimation algorithms we use are based on such linearization and are
demonstrated to give sufficiently accurate estimates of the faults.
Let us proceed in describing the linearized dependence of the residuals on the faults in a rigorous
way. In general, the residual data processed by the Central IVHM System and used for the
estimation is the sampled values of the residual vector r (3.12) collected over some interval of time.
This data can be presented in the form
⎥⎥⎥⎥⎥⎥
⎦
⎤
⎢⎢⎢⎢⎢⎢
⎣
⎡
∆+
∆+∆+
=∆
)(
)2()(
)(
)0;,,(
Ntr
trtr
tr
NtY
b
b
b
b
b
M
, (3.18)
where tb is the time of the data collection beginning, ∆ is the sampling interval, and N is the number
of the sequential samples collected. The vector Y has the size of 4N .
21
The residual data (3.18) is based on the prediction models described in Section 3 and assume a
nominal system behavior, no fault. This zero intensity of fault, f = 0, is indicated by the last
argument in the l.h.s. (3.18). It is possible to extend the prediction model to include the fault models
(3.14)—(3.17) and use it to predict the system output in a case when a known fault is present. The
residual data obtained assuming a known fault will be further denoted as );,,( fNtY b ∆ .
Linearizing the residual data dependence on the fault vector f yields
fNtSNtYfNtY bbb ),,()0;,,();,,( ∆+∆≈∆ , (3.19)
where S is the 4N x 4 Jacobian of the map );,,( fNtY b ∆ with respect to its last argument
0
);,,(),,(=∂
∆∂=∆f
bb f
fNtYNtS (3.20)
The matrix S in (3.19), (3.20) is further called a sensitivity matrix. The four columns of this matrix
contain the signatures of the four faults in consideration.
The map );,,( fNtY b ∆ is not available analytically. Rather, pointwise values of this map can be
computed by running the extended prediction model (with the fault models incorporated).
Therefore the sensitivity matrix is computed by a secant (finite difference) method. This is done by
in turn incrementing each component of the fault vector and computing the respective residual data
vector );,,( fNtY b ∆ . The normalized increments of the residual vector then yield secant estimates
for the columns of matrix S. Such computation of the sensitivity matrix could be done prior to the
flight, assuming that the vehicle would closely follow the nominal trajectory. The pre-computed
fault signatures (columns of the matrix S) are stored and used for on-line processing of the flight
data stream. The on-line computational logic using these signatures is outlined in Figure 4.
There is an inaccuracy in using a precomputed sensitivity matrix since the actual vehicle state is not
exactly the same as for the planned trajectory and for the nonlinear map );,,( fNtY b ∆ the
computed matrix S depends on the actual system states. An alternative, more accurate, approach is
22
to compute the fault signatures on-line, for the actual system state data. Here is how this can be
implemented.
At each point of time, in addition to the nominal model prediction residuals (3.12), four more
residuals are calculated. Denote by r(t; f) the residual calculated by assuming the fault f in the
prediction model. Then the nominal model prediction residual is
)0;()(0 == ftrtr (3.21) The four fault signatures (columns s(j) of the matrix S) can be computed by running four additional
modified copies of the prediction model alongside with the nominal prediction model within the
on-line data processing framework. All five models are receiving the same data stream from the
vehicle, but assume different faults. Let e(j) , (j =1, …,4), be unit fault vectors with all components
zero except the unit component j. Then the expressions for the signatures are as follows
dtrdetrts
jj )();()( 0
)()( −= , (3.22)
where d is in the finite difference step size. Our case study used d=1. One percent faults do not
violate the linearization assumptions. The matrix S is then computed by sampling the signature data
as follows
⎥⎥⎥⎥
⎦
⎤
⎢⎢⎢⎢
⎣
⎡
∆+∆+
∆+∆+=∆
)()(
)()()()(
),,(
)4()1(
)4()1(
)4()1(
NtsNts
tstststs
NtS
bb
bb
bb
b
L
MOM
L
L
, (3.23)
The fault sensitivities (signatures) computed by a finite difference method are illustrated in Figure 6.
The four columns in the array of plots correspond to the four faults in consideration. The rows
correspond to the four residuals. Each plot shows a part of the time dependence s(j)(t). The combined
and sampled data in each column of the Figure 5 plot array make a column of the matrix S.
23
0 50 100 150 -1.5
-1
-0.5
0
ACC
ELER
ATIO
N
GIMBAL SLUGGISHNESS
0 50 100 150
-4
-2
0
x 10 -3
FLIG
HT
ANG
LE R
ATE
0 50 100 150
-2
-1
0
1 x 10
-3
PITC
H A
CC
ELE
RA
TIO
N
0 50 100 150 -2
-1
0
1
2 x 10
-4
EN
GIN
E A
NG
LE R
ATE
TIME (s)
0 50 100 150-1.5
-1
-0.5
0
THRUST REDUCTION
0 50 100 150
-4
-2
0
x 10-3
0 50 100 150
-2
-1
0
1 x 10
-3
0 50 100 150-2
-1
0
1
2 x 10
-4
TIME (s)
0 50 100 150-1.5
-1
-0.5
0
DRAG INCREASE
0 50 100 150
-4
-2
0
x 10-3
0 50 100 150
-2
-1
0
1x 10
-3
0 50 100 150-2
-1
0
1
2x 10
-4
TIME (s)
0 50 100 150-1.5
-1
-0.5
0
PITCH MEASUREMENT OFFSET
0 50 100 150
-4
-2
0
x 10 -3
0 50 100 150
-2
-1
0
1x 10
-3
0 50 100 150-2
-1
0
1
2x 10
-4
TIME (s) Figure 5: Fault signatures computed for the first stage ascend.
4.3 Estimation algorithm
Consider the linearized fault sensitivity model (3.19). In this model, )0;,,( ∆NtY b is the residual data
vector for the prediction based on the nominal model. In the absence of fault, the residuals should
be zero. This assumes the available prediction model ideally explains the data. In reality this is
never the case. For any real–life system the residuals would differ from identical zero because of the
sensor noise and modeling errors (scatter). All these factors are herein collected together in one
generalized ‘noise’ data vector. The following statistical model for the residual data vector Y is
assumed
eSfY += , (3.24)
24
where S is a known sensitivity (fault signature) matrix and e is an unknown ‘noise’ vector.
By making certain statistical assumptions about the variables in the residual data model (3.24) it is
possible to arrive at the ‘optimal’ estimates of the fault parameters. Of course, in practice these
statistical assumptions should be taken with a grain of salt. One possible way to look at different
assumed statistical parameters is to consider them as tuning parameters of an estimation algorithm.
These parameters can be tweaked to achieve a reasonable practical performance of the algorithm.
With that in mind, we assume that the noise e in (3.23) is a normally distributed vector with a
covariance matrix V. We also assume that the unknown fault vector f being estimated is an
independent (of the noise e) random variable and has a normal distribution with covariance matrix
R. In that case an optimal statistical estimate of the fault vector f from the noisy data can be
obtained as a Maximal Likelihood (Maximum A posteriori Probability) Estimate in the form
[ ] YVSSVSRf TT 1111ˆ −−−− += (3.25) The estimate (3.23) is obtained for the residual vector Y using the sensitivity matrix S. Actually
computing the estimate (3.23) requires also having the covariance matrices V and R as well. The
estimate (3.25) is known as a GLS (Generalized Least Squares) estimate.
The noise covariance V can be empirically estimated from the residual scatter in the absence of
faults. The covariance V can be expressed via autocorrelations and cross-correlations of the residual
channel noise. In this work the data were generated in a simulation and contained no sensor noise.
The only modeling error present was the linearization error in the first-order approximation (3.9) of
the residual dependence on the fault vector. When implementing the estimation algorithm, the
covariance matrix V was selected as a scaled unity matrix. This corresponds to the white noise of the
same amplitude being present in all the observation channels.
The covariance matrix of the faults was chosen in the form
R = diag {(F1) 2, …, (F4) 2} , (3.27)
25
where different faults are assumed to be probabilistically independent and Fj has a meaning of
expected fault intensity. The fault intensities can be set based on the knowledge of the fault nature
and were chosen as {F1, F2, F3, F4} = {20, 3.16, 10, 0.71}.
So far, the reasoning ignored the time dependence (time evolution) of the variables. In principle, the
estimate (3.23) can be obtained as a batch estimate from the entire set of data collected throughout
the flight. However, there might be a need to compute and update estimates through the flight so
that evolving faults can be estimated and observed on-line. To satisfy this need, we implemented
the GLS algorithm (3.25) for the fault parameter estimation in a receding horizon form. At each time
step, the receding horizon algorithms compute an estimate of the fault parameter vector using N
most recent data points. This estimate can be expressed in the form
[ ] ),,();0;,,()(ˆ 1111 ∆∆−=∆∆−+= −−−− NNtSSNNtYVSSVSRtf tTtt
Tt (3.27)
The result of computing the receding horizon estimate is shown in Figure 6 below. The four
subplots correspond to one fault each and show the seeded fault value (dashed line) and the fault
recovered by the receding horizon GLS algorithm from the data (solid line). In this example, the
data is sampled every 100 ms and the receding horizon algorithm uses a 250 point (25 s) history
buffer data for the residuals and fault sensitivities. The receding horizon estimate is updated every
10 s. This is visible as steps in the ‘staircase’ plots of the estimates. As one can see, the obtained
estimates are reasonable at each step and quite close to the seeded fault values. This is despite the
unmodeled nonlinearity of the fault dependence and a large condition number of the sensitivity
matrix. For example, at the last receding horizon computation step the condition number is 3.8⋅104.
26
0 50 100 150 0
10
20
30 GIMBAL SLUGGISHNESS, PERCENT
0 50 100 150 0
0.5
1
1.5 THRUST REDUCTION, PERCENT
0 50 100 150 0
1
2
3
4
5 DRAG INCREASE, PERCENT
0 50 100 150 0
0.2
0.4
0.6
PITCH MEASUREMENT OFFSET, PERCENT
Seeded Fault
Receding Horizon Estimate
Figure 6: Receding horizon GLS estimate of the faults.
A few extensions of the implemented estimation algorithm are possible. The receding horizon
estimation can be posed as a constrained optimization problem that incorporates a priori knowledge
about possible fault magnitudes as the optimization constraints. It could be also possible to
incorporate the knowledge of the fault evolution. In particular, one piece of such knowledge is that
some of the fault parameters can only evolve one way – the mechanical damage is accumulating
and no ‘healing’ is happening. A monotonic regression algorithm for fault estimate trending based
on constraint optimization is discussed in [6].
5. Conclusions
The paper has described a case study for centralized parametric diagnostics of flight critical systems
of a launch vehicle. The demonstrated architecture partitions model-based computation of the
27
residuals and faulty signatures into vehicle subsystem processors. The residuals are integrated for
the estimation in the central IVHM processor, which does not require access to the detailed
modeling knowledge. A receding horizon algorithm for GLS fault estimation was described. This
algorithm was demonstrated to provide accurate fault estimation in launch vehicle ascent
simulation.
6. Acknowledgement The authors wish to acknowledge useful discussions with and valuable application description
contribution of Carlos Garcia-Galan.
7. References
1. A. Alessandri, M. Baglietto, and G. Battistelli,, “Receding-horizon estimation for discrete-
time linear systems,” IEEE Tran. on Automatic Control, Vol. 48, No. 3, 2003, pp. 473--478
2. R.N. Clark, P.M. Frank, and R.J. Patton. Advanced is Fault Diagnosis for Dynamic Systems.
Springer Verlag, 2000
3. P.M. Frank ``Fault diagnostics in dynamic systems using analytical and knowledge-based
redundancy - A survey and some new results,'' Automatica, Vol.26, No.3, 1990, pp. 459--474.
4. S. Ganguli, S. Deo, and D. Gorinevsky, “Parametric fault modeling and diagnostics of a
turbofan engine,” IEEE Conf. on Control Applications, September 2004
5. J. Gertler ``Survey of model-based fault isolation and detection in complex plants,'' IEEE
Contr. Syst. Magazine, 1988.
6. D. Gorinevsky, “Monotonic regression filters for trending deterioration faults,” American
Control Conference, Boston, MA, June 2004
7. R. Isermann and P. Balle “Trends in the application of model based fault detection and
diagnosis of technical processes,” 1996 IFAC World Congress, San Francisco, CA, July 1996
8. K. R. Muske, J. B. Rawlings, and J. H. Lee, “Receding horizon recursive state estimation,”
American Control Conference, June 1993, pp. 900—904.
9. G. Ramohalli. “The Honeywell on-board diagnostic and maintenance system for the Boeing
777,” 11th IEEE/AIAA Digital Avionics Systems Conf., pp. 485--490, October 1992