topleft topright
Engine Performance Monitoring and Alarming

Presented at the American Helicopter Society (AHS) International conference, 2008

Authors:  Ken Todd, Chad Wogoman, Kristen Law  

 


 

Engine Performance Monitoring and Alarming Overview 

 

Overview

 

Health and Usage Monitoring Systems (HUMS) have revolutionized many aspects of aircraft operation, functional check flight evolutions, and maintainability, and have inherently provided increased safety margin; however, few have capitalized on on-wing parameter alarming, including engine performance.  

 

Due to the increased frequency of operating our military aircraft in such locations as Afghanistan, Iraq, and aboard naval vessels where aircraft engines are subjected to the most austere environments in terms of sand and salt water, accelerated engine performance degradation can be expected.  Unlike foreign object damage (FOD) and blade failures, which in most cases creates a severe rotor 1/rev unbalance and are quickly discovered by vibration monitoring, sand and saltwater induced engine performance degradation is essentially transparent to vibration monitoring due to the uniform wear (sand erosion) and encrustation (salt water) induced circumferentially around the affected rotor.  The only effective and efficient means to alert the aircrew of low engine performance conditions of this nature, outside of a protracted pilot-initiated performance check, is to capitalize on the monitoring and alarming features of the respective aircraft’s HUMS.  

 

To compound these issues/concerns, mission planning to max gross weight has more often become a reality than a training exercise, and in the case of the United States Marine Corps H46 program, mission planning to power available is being explored when minimum required engine performance is a limiting factor.  Thus decreasing the safety margin associated with periodic performance checks in terms of data collection frequency. 

 

For example, currently on the H46 aircraft, the aircrew is required to obtain engine performance data every 50 flight-hours, via Honeywell’s Aircraft Integrated Maintenance System (AIMS), in order to assess engine performance acceptability.  Acceptability is determined by whether or not the engine produces a torque (corrected by pressure altitude and outside air temperature) that is equal to or greater than minimum required, which is established by the respective engine’s power turbine inlet temperature (corrected by outside air temperature).  In the event that engine performance is deemed acceptable, minimum guaranteed power is used over the course of the next 50 flight-hours to aid mission planning efforts.  Why is that a concern?  Let’s assume that performance margin (% above minimum guaranteed) was 0%.  If we were to operate in an environment where severe sand erosion and salt encrustation could be expected, we will quickly drop below minimum guaranteed power available, though the user would not be made aware of this “low power” condition until the next 50 flight-hour performance check.  Coupled with mission planning to max gross weight, the safety margin quickly deteriorates. 

 

Again, when considering the rapid rate at which these engines degrade in low altitude flights over saltwater and sand, concerns heighten when also giving consideration to the frequency in which engine performance data is being collected.  These concerns are even more justified when considering instantaneous failures such as foreign object damage and blade failures, if the resultant magnitude of unbalance is not sufficient enough to exceed a vibration alarm. 

 

Furthermore, there are several additional advantages to implementing engine performance monitoring and alarming, extending beyond safety.  These advantages include reduced costs per flight-hour (costs induced by man-hour expenditure, fuel, etc.), inherent in performing protracted, pilot initiated performance checks; as well as facilitating a means of migrating towards on-condition maintenance in terms of engine performance. 

 

Therefore, the Marine Corps H46 community has recently funded an initiative to accurately measure engine performance real-time and capitalize on the AIMS on-board alarming feature; essentially paving the road to on-wing engine performance monitoring. 

 

Design Concerns and Strategies (refer to Figure 1.) 

 

The AIMS/H46 engineering staff quickly realized the intrinsic hurdles that would have to be overcome in order to gain confidence levels high enough to implement real-time engine performance monitoring and alarming, to include data accuracy and fidelity, and stability. 

 

Data Accuracy and Fidelity: 

 

Foremost, from the infancy of the AIMS program, the AIMS’ team has employed several techniques not only to exploit data fidelity and accuracy issues, but also to suppress the respective parameter’s alarming feature during these invalid states.  The net result is avoiding parameter alarms induced by erroneous data.  These techniques include specific phase induced maintenance actions to ensure system integrity, acquisition unit (AU) self-calibration, and real-time parameter range and rate of change checking.  For example, AIMS’ source for power turbine speed is currently a torque signal isolation assembly, which when fails induces very large and rapid power turbine speed indications.   With rate of change faulting logic applied, AIMS recognizes this failure and generates and documents a fault for the relevant parameter.  Once faulted, the alarming mechanism is suppressed for the respective parameter, as well as the affected engine’s performance computations.  This logic has been applied to a number of monitored aircraft and engine parameters to include gas generator speed, main rotor speed, torque, etc. 

 

Secondly, performance algorithm accuracy was a concern, due to the proposed change in data collection methodology:  protracted pilot-initiated check targeting a specific altitude (2,000 ft pressure altitude (PA) ± 200 ft), airspeed (120 kts Indicated Air Speed (IAS) ± 10 kts), etc. vs. a much broader flight profile, real-time.  As a result, an effort was initiated and the original equipment manufacturer (OEM), General Electric, was tasked with developing and validating engine performance reject criteria that would facilitate the engine performance monitoring and alarming effort. 

 

As a result, the OEM developed five independent tables as a function of pressure and altitude (0, 2,000, 5,000, 8,000, and 10,000 ft PA), consisting of four independent reject lines per table as a function of IAS (0, 60, 90, and 130 kts IAS), per engine due to inlet loss variations between the #1 and #2 engines. 

 

Engine Performance Data Stability: 

 

Additional design concerns regarding data instability need to be addressed. This issue is inherent in rotary wing aircraft where engine parameter movements are a function of flight control inputs which are constantly being manipulated.  Therefore, the AIMS’ team designed and developed a software program that utilizes the OEM’s revised engine performance reject criteria, interpolates minimum required torque for each valid data point, and subsequently calculates engine performance margin for each respective performance point.  The % margin rolling average is then calculated using several different techniques in order to explore which “smoothing” logic/algorithm was most effective and reflective of the engine’s true performance output. 

 

Ultimately, the AIMS’ team elected to implement a rolling average by utilizing an “averaged block” scheme.  For example, assume that each “block” of data contains 100 valid data “samples” (20 seconds worth of valid data collected at 5Hz) and assume 100 blocks define the rolling average.  Restated, if the valid data samples and blocks equal zero, then the rolling average will not be displayed or alarmed until 10,000 valid data samples (100 blocks * 100 samples of valid data per block) have been collected.  In terms of time, this equates to 33 minutes worth of valid data samples (10,000 valid data samples / 300 seconds).  Once the number of data samples has been stored in each of the minimum number of blocks, the rolling average parameter will be displayed and alarmed at 5Hz.  Furthermore, the average of the oldest block will be “copied” to each individual sample of the current block prior to adding any new samples.  As the current block collects "new" data, the "copied" data will be eliminated. 

 

Flow Diagram

Figure 1.  Engine Performance Monitoring and Alarming Flow Diagram 

 

Implementation Concerns and Strategies (refer to Figure 1.) 

 

Design consideration must be made for AU cannibalization, engine removal and replacement, and uncorrected faulted performance parameters, due to the potential for data to be misrepresented or become stagnant and outdated. 

 

Misrepresented Data: 

 

To avoid data misrepresentation, the AIMS’ team elected to add specific software logic that would reset the engine performance margin number (valid data samples and blocks equal zero) within the AU non-volatile memory, as well as suppress the display of this value to the user, in the event of an AU cannibalization or engine removal and replacement. 

 

Stagnant Data: 

 

Stagnant data caused by a faulted parameter becomes a concern considering that engine performance monitoring and alarming is utilized  to determine engine performance acceptability, as well as in aiding mission planning efforts,.  For example, if the user experienced a performance parameter fault, the engine performance computations will be suppressed until the fault has been corrected.  If consideration is not given to stagnant data and in the event the fault was not corrected, , the user would be displayed with a performance margin value that may or may not be reflective of true engine performance.  Furthermore, when a parameter is in a faulted state, the alarming mechanism is suppressed.  Therefore, if an instantaneous power loss were experienced while the performance computations were suppressed, the user would not be notified of the low power condition until the fault was corrected.  To avoid scenarios such as these, the AIMS’ team elected to add specific software logic that would reset the engine performance margin number (valid data samples and blocks equal zero) within the AU non-volatile memory, as well as suppress the display of this value to the user, when the engine performance margin number has not been “refreshed” for a specified period of flight-hours. 

 

Summary 

 

The new capability to provide real-time engine performance assessment alleviates insufficient data collection frequency concerns; and the susceptibility of operating an aircraft with engine(s) producing performance margin less than the minimum required will be significantly reduced, due to on-wing alarming.  Furthermore, the aircrew will be provided with engine performance data real-time on-wing, facilitating a safer/more accurate means of mission planning.

 


 

 
Next >
webmaster@diagnosticsolutions.org
Joomla Templates by JoomlaShack Joomla Templates