Donald L. Simon and Jonathan S. Litt

Glenn Research Center, Cleveland, Ohio

A Data Filter for Identifying Steady-State 

Operating Points in Engine Flight Data 

for Condition Monitoring Applications

NASA/TM—2010-216359

July 2010

GT2010–22818
NASA STI Program . . . in Profi le

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA Scientifi c and Technical Information (STI) 

program plays a key part in helping NASA maintain 

this important role.

The NASA STI Program operates under the auspices 

of the Agency Chief Information Offi cer. It collects, 

organizes, provides for archiving, and disseminates 

NASA’s STI. The NASA STI program provides access 

to the NASA Aeronautics and Space Database and 

its public interface, the NASA Technical Reports 

Server, thus providing one of the largest collections 

of aeronautical and space science STI in the world. 

Results are published in both non-NASA channels 

and by NASA in the NASA STI Report Series, which 

includes the following report types:

• TECHNICAL PUBLICATION. Reports of 

completed research or a major signifi cant phase 

of research that present the results of NASA 

programs and include extensive data or theoretical 

analysis. Includes compilations of signifi cant 

scientifi c and technical data and information 

deemed to be of continuing reference value. 

NASA counterpart of peer-reviewed formal 

professional papers but has less stringent 

limitations on manuscript length and extent of 

graphic presentations.

• TECHNICAL MEMORANDUM. Scientifi c 

and technical fi ndings that are preliminary or 

of specialized interest, e.g., quick release 

reports, working papers, and bibliographies that 

contain minimal annotation. Does not contain 

extensive analysis.

• CONTRACTOR REPORT. Scientifi c and 

technical fi ndings by NASA-sponsored 

contractors and grantees.

• CONFERENCE PUBLICATION. Collected 

papers from scientifi c and technical 

conferences, symposia, seminars, or other 

meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientifi c, 

technical, or historical information from 

NASA programs, projects, and missions, often 

concerned with subjects having substantial 

public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientifi c and 

technical material pertinent to NASA’s mission.

Specialized services also include creating custom 

thesauri, building customized databases, organizing 

and publishing research results.

For more information about the NASA STI 

program, see the following:

• Access the NASA STI program home page at 

http://www.sti.nasa.gov

• E-mail your question via the Internet to help@

sti.nasa.gov

• Fax your question to the NASA STI Help Desk 

at 443–757–5803

• Telephone the NASA STI Help Desk at

 443–757–5802

• Write to:

 NASA Center for AeroSpace Information (CASI)

 7115 Standard Drive

 Hanover, MD 21076–1320
Donald L. Simon and Jonathan S. Litt

Glenn Research Center, Cleveland, Ohio

A Data Filter for Identifying Steady-State 

Operating Points in Engine Flight Data 

for Condition Monitoring Applications

NASA/TM—2010-216359

July 2010

GT2010–22818

National Aeronautics and

Space Administration

Glenn Research Center

Cleveland, Ohio 44135

Prepared for the

Turbo Expo 2010

sponsored by the American Society of Mechanical Engineers (ASME)

Glasgow, Scotland, United Kingdom, June 14–18, 2010
Acknowledgments

The authors graciously acknowledge the organizations that contributed to this effort including the United States Army Aviation and 

Missile Research Development Engineering Center, Aviation Engineering Directorate; the United States Army Research Laboratory, 

Vehicle Technology Directorate; and the NASA Aviation Safety Program, Integrated Vehicle Health Management Project.

Available from

NASA Center for Aerospace Information

7115 Standard Drive

Hanover, MD 21076–1320

National Technical Information Service

5301 Shawnee Road

Alexandria, VA 22312

Available electronically at http://gltrs.grc.nasa.gov

Trade names and trademarks are used in this report for identifi cation 

only. Their usage does not constitute an offi cial endorsement, 

either expressed or implied, by the National Aeronautics and 

Space Administration.

Level of Review: This material has been technically reviewed by technical management. 
A Data Filter for Identifying Steady-State Operating Points in Engine 

Flight Data for Condition Monitoring Applications 

Donald L. Simon and Jonathan S. Litt 

National Aeronautics and Space Administration 

Glenn Research Center 

Cleveland, Ohio 44135 

Abstract 

This paper presents an algorithm that automatically 

identifies and extracts steady-state engine operating points 

from engine flight data. It calculates the mean and standard 

deviation of select parameters contained in the incoming flight 

data stream. If the standard deviation of the data falls below 

defined constraints, the engine is assumed to be at a steadystate operating point, and the mean measurement data at that 

point are archived for subsequent condition monitoring 

purposes. The fundamental design of the steady-state data 

filter is completely generic and applicable for any dynamic 

system. Additional domain-specific logic constraints are 

applied to reduce data outliers and variance within the 

collected steady-state data. The filter is designed for on-line 

real-time processing of streaming data as opposed to postprocessing of the data in batch mode. Results of applying the 

steady-state data filter to recorded helicopter engine flight data 

are shown, demonstrating its utility for engine condition 

monitoring applications. 

Introduction 

Aircraft operators rely on engine condition monitoring 

programs to assist them in managing the health of their gas 

turbine engine assets. These functions, which are based on 

engine gas path measurement data collected at a small number 

of quasi-steady-state operating points each flight, are typically 

performed in off-board ground stations (Refs. 1 to 3). The 

quality of the steady-state measurement data directly impacts 

the quality and timeliness of the corresponding health 

assessments. For commercial transport aircraft, which follow a 

consistent flight profile including extended time at cruise 

operating points, data acquisition strategies are applied to 

collect engine data at relatively consistent points from flight to 

flight. However, for military or other aircraft that do not 

follow a regular flight profile, data acquisition at repeatable 

engine operating points each flight is not possible, or may be 

limited to takeoff data points only. Engines on these aircraft 

can experience a broad range of operating conditions during 

the course of a flight, including periods of transient and of 

quasi-steady-state operation. The steady-state data acquisition 

approach presented in this paper is applicable for all aircraft 

engines including those that exhibit relatively stable operating 

profiles and those that exhibit highly transient behavior. The 

approach is designed for real-time on-board implementation, 

but it can also be used for processing recorded data post-flight. 

In either application it will significantly compress the data into 

a reduced number of points reflecting engine performance. 

Such an approach is beneficial for situations where it is not 

practical to transmit full flight data sets off the aircraft, or to 

archive flight data for the entire lifetime of an engine. 

This work was initiated under a previous effort conducted 

by the authors to develop a prototype technique to perform the 

real-time automated assessment of available power in 

helicopter turboshaft engines (Ref. 4). That effort included the 

development of a steady-state data filter designed to process 

actual helicopter engine Health and Usage Monitoring System 

(HUMS) data to extract steady-state operating points. The 

steady-state data were in turn utilized to trend engine 

operating performance over time. Although initially applied to 

helicopter engine data, this filter and the associated lessons 

learned have broad applicability to other aircraft gas turbine 

engine applications including fixed-wing military and 

commercial aircraft. 

The remaining sections of this paper are organized as 

follows. First, the steady-state data filter architecture is 

presented and individual elements are discussed. Next, 

additional logic applied to limit analysis of data to that 

collected within a user-defined range of the engine operating 

envelope and to reduce data outliers is discussed. Several 

examples of the steady-state data extracted by the filter from 

helicopter engine flight data sets are given. These include 

examples of engines exhibiting nominal performance 

characteristics, as well as several anomalous performance 

examples. Following the example results, a discussion of 

practical considerations for applying the method is provided. 

Finally, conclusions are presented. 

Nomenclature 

KIAS Indicated airspeed, knots 

HUMS Health and usage monitoring system 

LPF Low pass filter 

N Number of samples in steady-state buffer 

Ng Gas generator speed 

Np Power turbine speed 

OAT Outside air temperature 

SHP Shaft horsepower 

TGT Turbine gas temperature 

Tminbuff Minimum steady-state buffer length 

Tthermmax Maximum temperature difference 

NASA/TM—2010-216359 1 
yk Parameter sample at current time step, k 

σ Standard deviation 

μ Mean 

ωn Low pass filter natural frequency 

ζ Low pass filter damping ratio 

τtherm Thermal transient filter time constant 

k Time sample index (subscript) 

Steady-State Data Filter Approach 

The steady-state data filter, which is coded in Matlab (The 

MathWorks, Inc.), is designed to perform the real-time 

identification and archiving of steady-state engine operating 

points from streaming flight data. The architecture of this filter 

is shown in Figure 1. The fundamental component of the 

architecture is the state transition logic, which determines the 

steady-state operating status of the engine. The state transition 

logic is predominantly generic, and can be applied to data 

collected from any dynamic system with minor modifications. 

The other components shown in Figure 1 are included to 

improve the quality and quantity of the identified steady-state 

operating points. The incoming flight data processed by the 

steady-state data filter consist of various sensed engine and 

aircraft parameters of interest, selected by the end user. Each 

incoming parameter stream, or channel, of the flight data first 

passes through a discrete low pass filter to reduce noise. 

Additional logic is applied to detect large thermal transients 

(thermal transient filter) and to ensure that data are only 

archived from desired regimes of the engine operating 

envelope (operating regime recognition logic). The low pass 

filtered data, the engine’s thermal transient status, and the 

engine’s operating regime status are passed into the state 

transition logic. Here the data are buffered into a window of 

data, and the mean and standard deviation of each parameter 

within the buffer window are calculated. The logic transitions 

between different states denoting transient or steady-state 

operation based upon whether standard deviation magnitude, 

persistency, and operating regime constraints are met. A 

vector of parameter means is archived for each identified 

steady-state operating point. The remainder of this section will 

discuss each element of the architecture in more detail. 

State Transition Logic 

The steady-state data filter is designed to facilitate on-line 

real-time processing of dynamic data (as opposed to postprocessing of the data in a batch mode). The key component 

of the filter is the state transition logic shown in Figure 2. 

Most of the state transition logic is completely generic. 

Domain-specific knowledge is only incorporated through a 

small number of operating regime conditional statements. 

The state transition logic has three states it can transition 

between when processing incoming data. These three states 

are described below: 

 

Flight

data

Low pass

filters

State transition

logic

Steady‐state

operating

points

Thermal

transient filter

Operating

regime

recognition

logic

Ss1 = [120.1 90.4 555.6]

Ss2 = [140.6 92.3 660.1]

0

1

2

Figure 1.—Steady-state data filter architecture. 

State 0: Buffer initial window of data 

Within State 0 an initial window of data of a user specified 

length is buffered. The time length of this buffer is referred to 

as Tminbuff. The underlying logic associated with State 0 is: 

• The state transition logic enters State 0 upon startup and 

any resets. 

• The logic remains in State 0 until a Tminbuff window of 

data is buffered from the incoming data stream. 

• Encountering any of the following conditions will result 

in the buffer being cleared (reset), and the state transition 

logic remaining in State 0: 

– Operating regime exceedance. 

– Thermal transient exceedance. 

– Data dropouts in the incoming data stream. 

• Once a Tminbuff window of data is buffered, the mean and 

standard deviation of the data contained within the 

window for each parameter are calculated. If the standard 

deviation of all parameters falls below user specified 

thresholds, the engine is considered to be at steady-state. 

The program will transition to: 

– State 1 if the steady-state criteria are not met. 

– State 2 if the steady-state criteria are met. 

State 1: Sliding Buffer Window of Non-Steady-State 

Data 

Within State 1, the state transition logic slides the buffer 

window of data forward in time when a new incoming data 

slice becomes available. This is achieved by appending the 

new data slice to the buffer and discarding the oldest data 

slice. This buffer will be of fixed length, specified by Tminbuff. 

The logic within State 1 does the following: 

• Recursively calculates the mean and standard deviation for 

each parameter whenever an update to the buffer occurs. 

NASA/TM—2010-216359 2 
State 0

• Buffer initial window of data

In 

operating regime

and thermally

stable?

Buffer >= Tminbuff?

Reset

Buffer

Append next

time slice

No

Yes

No

Yes

Calculate 

μ and σ

at steady

state?

No

State 1

• Sliding buffer of

non-steady-state data

In

operating regime

and thermally

stable?

Append new & 

Remove oldest

time slice

No

Yes

No

Update

μ and σ

at steady

state?

Yes

State 2

• Expanding buffer of

steady-state data

In

operating regime

and thermally

stable?

Append new

time slice

No

Yes

Yes

Update

μ and σ

at steady

state?

No

Archive parameter

μ’s calculated 

during the previous

time step

Archive parameter

μ’s calculated during

the previous time step.

Buffer the most recent

Tminbuff of data, and

calculate μ and σ of each

parameter in the buffer.

Yes

Figure 2.—Steady-state data filter state transition logic.

• Remains in State 1 while: 

– The steady-state criteria are not met 

and 

– Operating regime exceedance, thermal transient 

exceedance, and data dropouts are not encountered. 

• Triggers a transition to State 2 if the steady-state criteria 

are met. 

• Triggers a transition to State 0 if operating regime 

exceedance, thermal transient exceedance, or data 

dropouts occur. 

State 2: Expanding Buffer Window of Steady-State 

Data 

If all of the defined steady-state criteria are met, the state 

transition logic enters State 2. In State 2, the buffer is 

expanded by appending new incoming data as long as all 

steady-state criteria continue to be met. The logic associated 

with State 2 does the following: 

• Appends new time slices of data to the existing steadystate data buffer. 

• Recursively calculates the mean and standard deviation 

for each parameter in the buffer each time new data are 

added. 

• If operating regime exceedance, thermal transient 

exceedance, or data dropouts are encountered, mean 

steady-state data that were calculated during the previous 

time step are archived, the buffer is reset, and the logic 

transitions to State 0. 

• If the standard deviation of any of the parameters 

exceeds its defined threshold, the engine is assumed to 

no longer be in steady-state. As a result, the logic 

associated with State 2 does the following: 

– The mean parameter values that were calculated 

during the previous time step are archived. 

– A new data buffer consisting of the most recent 

Tminbuff window of data is created. 

– The mean and standard deviation of each parameter 

within the new window are calculated. 

– The logic transitions to State 1. 

No limit is placed on the maximum size of the buffer 

window in State 2. In general, a larger buffer will require a 

larger transient to trigger a standard deviation threshold 

exceedance. However, this has not been found to have any 

noticeable effect on the quality of the archived mean steadystate data. 

Recursive Calculation of Mean and Standard 

Deviation 

To facilitate real-time implementation, the mean, μ, and 

standard deviation, σ, of each parameter are calculated 

recursively. Whenever a new time slice of data is added to an 

existing data buffer, the standard deviation and mean for each 

incoming parameter are updated. Re-calculating the mean and 

standard deviation values each time step based upon all 

samples stored in the buffer (batch mode) would require 

considerable processing overhead. Therefore, recursive 

calculations for the mean and standard deviation are used. 

These equations only require the mean and standard deviation 

values from the previous time step, the most recent parameter 

sample, and in the case of the sliding window (State 1) the 

oldest parameter sample. There are a few issues that 

complicate this logic, namely: 

• Parameters are not all sampled at a common frequency. 

• Parameters that are sampled at a common frequency are 

not necessarily synchronized to sample at the same time. 

• Synchronization discontinuities in the data sample rate 

and intermittent data dropouts occasionally occur. 

The steady-state data filter includes logic to account for each 

of the issues listed above. 

NASA/TM—2010-216359 3 
Different recursive mean and standard deviation 

calculations are applied depending on which state the logic is 

in. These calculations are shown below: 

1. New parameter appended, oldest parameter removed 

from buffer channel (sliding buffer—State 1) 

( 0 )

1

k

k k

y y

N −

− μ =μ + (1)

( ) ( )( ) ( )( )

2

1

1 0 1 0

1

1

k

k

yyyy kk kk k k N

−

− −

σ

σ = + − ⎡ μ − μ− − μ − ⎣ −

...

μ ⎤

⎦

(2)

where 

N number of parameter samples in buffer channel 

k current time step 

yk parameter sample at current time step, k

y0 oldest parameter sample, which is being removed from 

buffer 

2. New parameter appended to existing buffer channel 

(expanding buffer—State 2) 

1

1

k k

k k

y

N

− −

− μ μ =μ + (3)

(( ) ( )( )) 2

1 1

1 2

1 k k N yy k k N σ = − σ + −μ −μ − − − k k (4)

Equations (1) to (4) can be derived from the approaches and 

formulas for the recursive calculation of mean, variance, and 

standard deviation in References 5 to 7. 

Low Pass Filters 

During initial development, the steady-state data filter was 

applied to a helicopter HUMS data set. At this time, an 

interesting observation was made when comparing the number 

of steady-state data points the filter identified in the two 

engines installed on the same aircraft. Although the two 

engines were operated in a very similar fashion, the steadystate data filter consistently identified more steady-state points 

in engine no. 2 than it did in engine no. 1. Upon closer 

observation it was discovered that the primary factor causing 

this discrepancy was the variance in engine sensor 

measurements, particularly the engine no. 1 torque sensor 

measurement. To address this issue, discrete second order low 

pass filters (LPFs) were added to pre-process the data 

contained in each incoming HUMS data channel. The 

formulation of the LPFs is given in Eq. (5) where ωn is the 

natural frequency and ζ is the damping ratio of the filter. 

Although Eq. (5) is shown in continuous time form, the LPFs 

are actually implemented in discrete time form (i.e., digital 

filters) as the incoming HUMS data are digital. The LPF 

associated with each data channel is discretized and applied in 

accordance with the sample rate of the channel. The effect of 

adding these filters is two-fold. First, it provides improved 

consistency in the number of steady-state points identified 

from each engine. Second, it also allows more steady-state 

points to be identified, particularly at high power regions 

where the sensor measurements tend to exhibit more variance. 

Adding the LPFs resulted in approximately a 2.5° increase in 

the number of steady-state points identified. 

( )

( )

2 filtered

2 2 unfiltered 2

n

n n

Y s

Y ss s

ω = + ζω +ω (5)

Thermal Transient Filter 

In investigating the outlier points identified by the steadystate data filter with the low pass filters, it was observed that 

many of these points were collected immediately after the 

engine had undergone a substantial power transient. For 

example, the first data point collected after transitioning from 

idle power to an intermediate or high power point was often an 

outlier. These occurrences may have resulted from the fact 

that the engine had not yet reached a thermal equilibrium; 

metal temperature thermal heat soak effects are typically slow 

relative to other engine dynamics. To help address this issue, 

additional logic was developed and incorporated into the 

steady-state data filter to ensure that the recorded engine 

turbine gas temperature (TGT) is in quasi-steady-state for an 

extended period of time (on the order of minutes) prior to 

collecting steady-state points. This thermal transient logic is 

implemented by calculating a lagged version of TGT from the 

HUMS data with a time constant of τtherm, and comparing this 

parameter to the second-order low pass filtered value of TGT. 

The continuous time formulation of the TGT first order lag is 

shown in Eq. (6). A discrete version of this equation is 

implemented within the thermal transient filter. 

Figure 3 shows a transient example of TGT (black curve), the 

corresponding low pass filtered TGT (blue curve), and first 

order lagged TGT (red curve).1

 If the absolute difference 

 

1

Due to the proprietary nature of the data, axis scales have been removed from 

the figures in this document 

NASA/TM—2010-216359 4 
Figure 3.—Comparison of unfiltered, low pass 

filtered, and lagged TGT during a thermal 

transient. 

between the low pass filtered and lagged versions of TGT is 

greater than Tthermmax the engine is assumed to be in thermal 

transient. In this case, the buffer is cleared and the state 

transition logic enters State 0. Once the absolute difference 

between these two parameters is less than Tthermmax, the logic 

resumes buffering data. τtherm and Tthermmax can be considered 

tuning parameters. Results will vary as these parameters are 

adjusted.

( )

( )

lagged

unfiltered therm

TGT 1

TGT 1

s

s s = τ +

(6)

Operating Regime Recognition Logic 

The steady-state data filter also includes operating regime 

recognition logic. The purpose of this logic is to ensure that 

steady-state data are only collected when the engine is 

operating within a user specified portion of the operating 

envelope, and to help reduce outlier points. For example, one 

can include constraints to ensure that data are only collected 

within a certain altitude, airspeed, power setting, or time range 

within the flight profile. Additional logic can be included to 

ensure that steady-state data are not collected while the engine 

is operating in a mode known to impact engine performance, 

such as when the anti-ice bleed system is on. 

Helicopter Engine Example 

HUMS data sets provided by the U.S. Army were used to 

develop and evaluate the steady-state data filter. All HUMS 

data provided were collected from UH-60L aircraft equipped 

with T700-GE-701C engines. The T700-GE-701C engine 

serves as the power plant for the latest UH-60L Black Hawk 

variants and AH-64A/D Apaches (Refs. 8 and 9). This 

1800 horsepower-class engine is a modular two-spool design 

consisting of a gas generator section and a free power turbine. 

The engine is controlled through the interaction of an 

Electrical Control Unit and a Hydromechanical Control Unit. 

These HUMS data sets included data from 15 different vehicle 

tail numbers (30 engines) encompassing 1688 missions 

totaling 2813 aircraft flight hours. Also, these data consisted 

of a select subset of the HUMS parameters available. A list of 

the 14 HUMS parameters provided, along with their 

associated sample rates, is shown in Table 1. 

TABLE 1.—HUMS PARAMETERS 

Parameter 

name 

Sample 

rate 

Definition 

1. Time_Stamp Variable Time of data sample 

2. Baro_Alt 5 Hz Pressure altitude (ft) 

3. Anti-Ice 1 1 Hz Engine 1 anti-ice bleed (on/off) 

4. Anti-Ice 2 1 Hz Engine 2 anti-ice bleed (on/off) 

5. KIAS 5 Hz Indicated airspeed (knots) 

6. Ng 1 5 Hz Engine 1 gas generator speed (%) 

7. Ng 2 5 Hz Engine 2 gas generator speed (%) 

8. Np 1 5 Hz Engine 1 power turbine speed (%) 

9. Np 2 5 Hz Engine 2 power turbine speed (%) 

10. OAT 2 Hz Outside air temperature (°C) 

11. TGT 1 2 Hz Engine 1 turbine gas temp (°C) 

12. TGT 2 2 Hz Engine 2 turbine gas temp (°C) 

13. Torque 1 5 Hz Engine 1 torque (%) 

14. Torque 2 5 Hz Engine 2 torque (%) 

Tables 2 through 5 show the various constraints and design 

parameters applied in setting up the steady-state data filter for 

the helicopter engine data example. The maximum acceptable 

standard deviation, σ, for each parameter, along with the 

minimum buffer window length, Tminbuff, is shown in Table 2. 

All seven of the σ constraints and the Tminbuff constraint must 

be met for an engine to be considered in steady-state. There is 

a trade-off in the specification of these parameters—smaller σ

constraints and a larger minimum buffer size will generally 

result in improved quality (less variance) in the identified 

steady-state points, although there will be relatively fewer of 

them, whereas larger σ constraints and a smaller minimum 

buffer size will result in greater variance but more identified 

points. The values in Table 2 were established manually 

through trial and error while observing the quality of the 

identified steady-state data. 

The design parameters for the low pass filter and the 

thermal transient filter are shown in Tables 3 and 4. Similar to 

the σ and Tminbuff constraints, these values were chosen through 

trial and error while observing the quality of the identified 

steady-state data. 

NASA/TM—2010-216359 5 
TABLE 2.—STEADY-STATE DATA FILTER MAXIMUM 

ACCEPTABLE STANDARD DEVIATION LEVELS AND 

MINIMUM BUFFER WINDOW LENGTH 

Parameter Maximum σ

and minimum buffer length 

Torque σ 0.5% 

Ng σ 0.2% 

TGT σ 1.5 °C 

Np σ 0.2% 

Baro Altitude σ 30 ft 

KIAS σ 4 knots 

OAT σ 1 °C 

Tminbuff 15 s 

TABLE 3.—LOW PASS FILTER DESIGN PARAMETERS 

Parameter Value 

ωn (natural frequency) .......................................... 0.05⋅2π (radians) 

ζ (damping ratio)......................................................................... 1.4 

TABLE 4.—THERMAL TRANSIENT FILTER DESIGN 

PARAMETERS 

Parameter Value 

τtherm (time constant) .................................................................. 80 s 

Tthermmax (max Δ between filters) .............................................. 5 °C 

The applied operating regime logic constraints are shown in 

Table 5. For this example, steady-state points are only 

collected above 90 percent corrected gas generator speed to 

avoid engine start-up and idle operating points. Logic is also 

applied to make sure the engine anti-ice bleed valve is not 

open, as that will impact engine performance. Additionally, 

logic is applied to make sure that the aircraft is operating in 

flight at an indicated airspeed (KIAS) above 40 knots. It was 

observed that many of the steady-state outlier points were 

collected at the start of a mission while the aircraft was 

operating on the ground. While the cause of these outliers is 

not completely understood, adding the KIAS operating regime 

constraint helped to alleviate that problem. 

TABLE 5.—OPERATING REGIME LOGIC CONSTRAINTS 

Parameter Constraint 

Ng Corrected ......................................................................... > 90% 

KIAS ............................................................................... > 40 knots 

Anti-Ice Bleed ............................................................................ Off 

Results 

Figure 4 shows a time history plot of TGT collected from 

one engine over one flight. This illustrates the highly transient 

behavior of the data and the challenge in identifying steadystate operating points. 

Figure 4.—Measured TGT from one engine over one flight. 

Figure 5.—Comparison of raw and steady-state SHP versus 

TGT data collected from a single flight. 

An example of the steady-state HUMS data from a single 

flight is shown in Figure 5. Here SHP2

 versus TGT data are

plotted. Because engine operation is strongly influenced by the 

ambient operating conditions, corrected parameters (Ref. 10) 

are shown here and throughout the remainder of the paper to 

reduce data scatter. In Figure 5, the cyan points represent all of 

the raw SHP versus TGT data collected during the mission 

while the red points represent the steady-state points identified 

by the steady-state data filter. Due to transient operating 

excursions, a considerable amount of variation is evident in 

the raw data. The steady-state points represent a tighter 

clustering around the engine steady-state operating line. 

Figure 6 shows a scatter plot of the steady-state data points 

identified from a single engine over a 5 month period of time. 

The upper half of the figure shows Ng versus TGT data and 

the lower half of the figure shows SHP versus TGT data. The 

color of each point denotes the time the steady-state point was 

collected, corresponding to the color bar on the right side of 

the plots. As a point of reference, the engine steady-state cycle 

deck response at the corrected operating condition is shown 

(green curves). 

 

2

Note: Shaft horsepower, SHP, which is proportional to torque times power 

turbine speed, is not measured directly. It is calculated as: 

SHP = Constant ° Torque ° Np 

NASA/TM—2010-216359 6 
Engine condition monitoring is frequently conducted by 

comparing engine data to a reference model, e.g., a cycle deck. 

The difference between the actual engine data and the 

reference model forms what are known as performance 

residuals or performance deltas (Ref. 2). Figure 7 shows a 

scatter plot of the ΔNg and ΔSHP performance residuals for 

the same steady-state engine data shown in Figure 6. At each 

identified steady-state operating point, a ΔNg and ΔSHP 

residual were generated by referencing the mean Ng and SHP 

data against that predicted by the cycle deck when run to the 

corresponding altitude, airspeed, OAT, and turbine 

temperature (TGT). For this engine, it can be observed that 

ΔNg is operating at approximately 1 percent above nominal 

over the entire TGT operating range. The ΔSHP residual is 

shown to vary as a function of TGT. This relationship is due to 

the lapse rate effects of the T700 engine. Power lapse rate 

reflects the change in the ratio of actual to rated power with 

operating condition and deterioration level. The steady-state 

data examples shown over the remainder of the paper will 

present residual data. 

Results—Benefit of Including the Low Pass 

Filter (LPF) and the TGT Thermal Transient 

Filter 

Figure 8 illustrates the benefit of including the low pass 

filter in the steady-state data filter logic. This figure shows a 

comparison of the steady-state data points identified with and 

without applying the LPF. All results are based on a HUMS 

data set collected from a single aircraft over 45 days. The 

upper two subplots show the ΔSHP versus TGT steady-state 

data collected without the LPF, while the bottom two subplots 

show the data collected with the LPF. The inclusion of the 

LPF significantly increases the number of steady-state points 

identified. Furthermore, the number of steady-state points 

identified on each of a helicopter’s two engines was found to 

correlate better when the LPF was applied. 

As previously described, the application of the TGT 

thermal transient filter excludes steady-state data collected 

immediately after the engine has undergone a significant 

thermal transient. Figure 9 shows an example of the ΔSHP 

versus TGT steady-state data points identified without (top 

plot) and with (bottom plot) this filter. This example is based 

upon data collected from one engine over a two month time 

period. In the top plot there are several outlier points above the 

main cluster of data. In the bottom plot most of these points 

have been eliminated. The inclusion of the TGT filter results 

in a tighter clustering of the data, but it also reduces the 

overall number of steady-state points identified. A system 

designer must weigh these trade-offs when deciding whether 

or not to include the filter, and also when choosing what 

values to specify for the filter’s design parameters. 

Figure 6.—Example of the steady-state data collected from an 

individual engine over 5 months.

Figure 7.—Example of the steady-state residual data collected 

from an individual engine over 5 months. 

Figure 8.—Example of ΔSHP versus TGT with and without LPF. 

NASA/TM—2010-216359 7 
Figure 9.—Example of ΔSHP versus TGT with and without 

TGT transient filter. 

Figure 10.—Example of steady-state points collected with antiice bleed valve open.

Figure 11.—Example of steady-state data points collected with 

(postulated) inlet barrier filter installation. 

Results—Visualization of Changes in Engine 

Performance 

In analyzing the HUMS data sets, it was observed that 

several of the engines exhibited abrupt performance shifts. 

These events were all discovered through manual analysis–the 

steady-state data filter does not include any automated 

diagnostic functionality. Several examples of these events are 

shown and discussed below to demonstrate how the steady-state 

data filter outputs could potentially be used for engine condition 

monitoring purposes if coupled with diagnostic logic. 

Anti-Ice Bleed On 

As previously described, the operating regime recognition 

logic includes a check to make sure that the engine anti-ice 

bleed valve is not open when steady-state data are collected. 

To illustrate what could occur if that logic were not included, 

a HUMS data set was analyzed using the steady-state data 

filter with the anti-ice bleed valve logic disabled. Figure 10

shows the results of that evaluation. Here five steady-state 

data point outliers were identified. These five points were 

collected on a single flight while the anti-ice bleed valve was 

open. These points are approximately –15 percent ΔSHP from 

the other steady-state points collected from the engine. The 

shift in ΔNg when the bleed valve is open is less apparent. 

Although this example is not an actual bleed anomaly it 

illustrates how the steady-state data filter could be used to 

recognize bleed valve faults. 

Installation of Auxiliary Hardware 

Figure 11 shows an example of the steady-state ΔSHP 

versus TGT data collected from two engines installed on the 

same aircraft over a three month time period. Both engines 

undergo an abrupt decrease in ΔSHP on the same date. 

Steady-state points collected after this date are denoted by the 

cyan through red color spectrum. While the authors have no 

knowledge of the actual cause, it is postulated that this shift 

was due to the installation of inlet barrier filters on the 

engines. Like the anti-ice bleed valve example, this is not an 

actual anomaly. However, it illustrates the potential use of the 

tool to reveal abrupt performance shifts. It also demonstrates 

the need to be aware of any maintenance actions or the 

installation of auxiliary hardware, such as inlet barrier filters, 

on the engine(s). 

Instrumentation Anomalies 

Figure 12 to Figure 14 show three instrumentation 

anomalies that were discovered in the HUMS data sets. The 

first example, shown in Figure 12, depicts steady-state data 

collected from an engine over a three month time period. The 

figure contains two separate groupings of steady-state data. 

The initial data (blue points) were collected when a bias was 

present in the TGT measurement recorded in the HUMS unit. 

A clearly discernable shift in the data is evident on the flights 

NASA/TM—2010-216359 8 
Figure 12.—Example of steady-state data points collected with 

a TGT instrumentation bias. 

Figure 13.—Example of steady-state data points collected with 

a torque measurement dropout.

Figure 14.—Example of steady-state data points collected with 

an OAT instrumentation bias. 

after this problem was rectified (red points). Since both ΔNg 

and ΔSHP are referenced against TGT, this anomaly resulted 

in a noticeable shift in both plots (ΔNg versus TGT and ΔSHP 

versus TGT).

Figure 13 shows an example of the steady-state data 

collected when a dropout of the torque measurement occurred. 

Unlike the previously presented TGT bias example, this 

instrumentation anomaly was intermittent. At times the torque 

reading appeared correct, while at other times a full dropout 

(torque reading of zero) or a partial dropout (incorrect reading 

greater than 0) occurred. SHP is calculated as a function of the 

recorded torque and power turbine speed. Therefore the torque 

dropout instrumentation anomaly is evident in the ΔSHP 

versus TGT plot, but does not affect the ΔNg versus TGT plot 

as Ng is sensed directly (i.e., it is not calculated as a function 

of measured torque). 

The final instrumentation anomaly example is shown in 

Figure 14. This figure shows steady-state data points from an 

aircraft experiencing intermittent bias in the outside air 

temperature (OAT) measurement. The recorded aircraft OAT 

measurement intermittently exhibited a negative bias as large 

as 80 °C. OAT is used for parameter correction (correction of 

Ng, SHP, and TGT), as well as input to the cycle deck used to 

calculate the nominal Ng and SHP values. Therefore, any bias 

in OAT will have a pervasive effect on the ΔNg versus TGT 

and ΔSHP versus TGT plots. Although data from only one 

engine are shown, the OAT bias has the same effect on the 

data collected from each engine installed on the same aircraft. 

Discussion 

The development of the steady-state data filter described in 

this paper was an evolutionary process. The initial version of 

the architecture only contained the state transition logic, which 

is completely general and applicable to any dynamic system. 

Due to the insufficient quantity and quality of the steady-state 

points identified by the filter, attributed primarily to 

characteristics of the engines’ operation, additional domainspecific functionality was progressively added. This included 

the low pass filter, the thermal transient filter, and the 

operating regime recognition logic (see Figure 1). Discussions 

with T700 domain experts in the U.S. Army proved to be 

invaluable during this process. These discussions provided 

insight into the engine operating modes that could impact 

performance readings, and approaches that could be taken to 

improve the filter, including those that help to reduce data 

outliers. Based on the experience with the T700 helicopter 

engine data, it is expected that similar adaptations would be 

necessary to extend the technique to other gas turbine engine 

applications. 

In analyzing the HUMS data sets, it was found that 

instrumentation anomalies and the occurrence of events that 

impacted engine performance were fairly common. If 

unaccounted for, these events could negatively impact the 

performance of an engine monitoring system that relies on the 

NASA/TM—2010-216359 9 
NASA/TM—2010-216359 10 

identified steady-state data to make engine health assessments. 

Consequently, additional sensor validation logic should be 

included within the engine monitoring system in a practical 

implementation (Refs. 11 and 12). Furthermore, it would be 

beneficial for such an engine monitoring system to have 

knowledge of engine maintenance actions that might impact 

performance readings, including engine overhauls, line 

maintenance, or installation of auxiliary hardware such as inlet 

barrier filters. In the case of the automated power assessment 

logic described in Reference 4, trend monitoring reset logic 

was included in case the engine performance parameters are 

observed to undergo an abrupt shift. This allows a more rapid 

and accurate response to performance changes. 

As shown in Tables 1 to 5, the steady-state data filter 

incorporates a number of user-defined design parameters. To a 

large degree the specification of these parameter values is made 

based on a manual assessment of the data identified by the filter. 

There are definite trade-off decisions. The designer is typically 

faced with choosing between quantity (i.e., more points) versus 

quality (i.e., less variance in the data and fewer outliers). For 

instance, for a fault detection scheme it would be important to 

eliminate known outliers to help reduce false alarms. 

In the case of the automated power assessment logic 

described in Reference 4, the objective is to provide a realtime assessment of available power. Therefore, every steadystate point identified was utilized. However, if the data were to 

be used for other applications, such as ground-based postflight performance trend monitoring, it might be prudent to 

include logic to limit the number of steady-state points 

collected. This would be desirable if the cost of telemetering 

large quantities of data off the aircraft is a concern, or if the 

end user wants to maintain uniform temporal spacing between 

the data points collected. Additionally, logic could be added to 

constrain the filter to collect only a specified number of points 

each flight. This could be within fixed ranges of engine 

operating power specified by the user (e.g., ground idle, 

intermediate power, high power). 

Conclusions 

A technique for the automatic detection and archiving of 

steady-state engine operating points has been developed and 

demonstrated. Its ability to effectively recognize steady-state 

segments in transient data has been shown. The initial 

implementation was completely general and applicable to any 

dynamical system. In the course of developing the tool, several 

domain-specific enhancements were incorporated to improve the 

performance of the steady-state data filter. These enhancements 

included low pass filtering of the incoming data, logic to avoid 

collecting data immediately after a major thermal transient, and 

operating regime recognition logic to constrain the operating 

point and operating mode where data are collected. The technique 

has been demonstrated to be effective in revealing engine 

performance shift events due to the installation of auxiliary 

hardware and instrumentation anomalies. 

The steady-state data filter could be an important part of a 

diagnostic system for engines that do not have a consistent 

operating profile, such as those on military vehicles. Its ability 

to identify and archive steady-state points for use in trend 

monitoring can have a profound impact on the way propulsion 

health monitoring is carried out; an example of this impact is 

the previously reported turboshaft engine power assurance 

system, which uses this filter. Although designed for real-time 

on-board implementation, the filter could also serve an 

important role for post-processing of engine data collected in 

flight. The storage requirements necessary to archive full 

flight HUMS data collected from a fleet of aircraft is 

staggering. The data filter could be used to compress engine 

flight data into a small number of steady-state performance 

points collected during each flight. This approach could 

eliminate the need for long term archiving of the HUMS data, 

thus greatly reducing data storage requirements. 

References 

1. Society of Automotive Engineers E-32, 2005, “A Guide to the 

Development of a Ground Station for Engine Condition 

Monitoring,” SAE Aerospace Information Report 4175A. 

2. Von Karman Institute for Fluid Dynamics, 2003, “Gas Turbine 

Condition Monitoring and Fault Diagnostics,” Lecture Series 2003–

01. 

3. Doel, D., 1994, “TEMPER—A Gas-Path Analysis Tool for 

Commercial Jet Engines,” Journal of Engineering for Gas Turbines 

and Power, Vol. 116, pp. 82–89. 

4. Simon, D.L., Litt, J.S., 2008, “Automated Power Assessment for 

Helicopter Turboshaft Engines,” NASA/TM—2008-215270, 

American Helicopter Society Forum 64, Montreal, QC, Apr. 29 –

May 1. 

5. Pébay, P., 2008, “Formulas for Robust, One-Pass Parallel 

Computation of Covariances and Arbitrary-Order Statistical 

Moments,” Technical Report SAND2008–6212, Sandia National 

Laboratories. 

6. Chan, T.F., Golub, G.H., LeVeque, R.J., 1979, “Updating Formulae 

and a Pairwise Algorithm for Computing Sample Variances,” 

Technical Report STAN–CS–79–773, Department of Computer 

Science, Stanford University. 

7. Young, P., 1984, “Recursive Estimation and Time Series Analysis: 

An Introduction,” Springer-Verlag New York, Inc., New York, NY. 

8. “Technical Manual, Aviation Unit and Intermediate Maintenance 

Manual, Engine, Aircraft Turboshaft Models T700–GE–700, T700–

GE–701, T700–GE–701C, T700–GE–701D,” Army TM 1–2840–

248–23, Headquarters, Departments of the Army and the Air Force, 

1 Jun. 1999. 

9. GE Aviation website: http://www.geae.com/engines/military 

/t700/t700-701c.html, accessed Nov. 20, 2009. 

10. Volponi, A.J., 1999, “Gas Turbine Parameter Corrections,” Journal 

of Engineering for Gas Turbines and Power, Vol. 121, pp. 613–621. 

11. Volponi, A. J., 1994, “Sensor Error Compensation in Engine 

Performance Diagnostics,” ASME Paper 94–GT–58. 

12. Healy, T.A., Kerr, L.J., Larkin, L.J., 1998, “Model Based Fuzzy 

Logic Sensor Fault Accommodation,” Journal of Engineering for 

Gas Turbines and Power, Vol. 120, pp. 533–536. 
REPORT DOCUMENTATION PAGE Form Approved 

OMB No. 0704-0188 

The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the 

data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this 

burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. 

Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB 

control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 

1. REPORT DATE (DD-MM-YYYY)

01-07-2010 

2. REPORT TYPE

Technical Memorandum 

3. DATES COVERED (From - To)

4. TITLE AND SUBTITLE

A Data Filter for Identifying Steady-State Operating Points in Engine Flight Data for 

Condition Monitoring Applications 

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S)

Simon, Donald, L.; Litt, Jonathan, S. 

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

WBS 645846.02.07.03.12 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration 

John H. Glenn Research Center at Lewis Field 

Cleveland, Ohio 44135-3191 

8. PERFORMING ORGANIZATION

 REPORT NUMBER

E-17295 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration 

Washington, DC 20546-0001 

10. SPONSORING/MONITOR'S

 ACRONYM(S)

NASA 

11. SPONSORING/MONITORING

 REPORT NUMBER

NASA/TM-2010-216359 

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified-Unlimited 

Subject Category: 07 

Available electronically at http://gltrs.grc.nasa.gov 

This publication is available from the NASA Center for AeroSpace Information, 443-757-5802

13. SUPPLEMENTARY NOTES

14. ABSTRACT

This paper presents an algorithm that automatically identifies and extracts steady-state engine operating points from engine flight data. It 

calculates the mean and standard deviation of select parameters contained in the incoming flight data stream. If the standard deviation of the 

data falls below defined constraints, the engine is assumed to be at a steady-state operating point, and the mean measurement data at that 

point are archived for subsequent condition monitoring purposes. The fundamental design of the steady-state data filter is completely 

generic and applicable for any dynamic system. Additional domain-specific logic constraints are applied to reduce data outliers and variance 

within the collected steady-state data. The filter is designed for on-line real-time processing of streaming data as opposed to post-processing 

of the data in batch mode. Results of applying the steady-state data filter to recorded helicopter engine flight data are shown, demonstrating 

its utility for engine condition monitoring applications.

15. SUBJECT TERMS

Systems health monitoring; Gas turbine engines; Fault detection; Statistical analysis 

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF

 ABSTRACT

UU 

18. NUMBER

 OF 

 PAGES

17 

19a. NAME OF RESPONSIBLE PERSON

STI Help Desk (email:help@sti.nasa.gov) 

a. REPORT

U 

b. ABSTRACT

U 

c. THIS 

PAGE

U 

19b. TELEPHONE NUMBER (include area code)

443-757-5802 

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std. Z39-18