A Road to Cost and Downtime Predictability
In the business / general aviation world trending, or engine condition monitoring has been in use for the better part of 40 years. It’s fair to say that over these 40 years the experience that many have had with the process has been mixed to say the least. How many maintenance personnel have found an engine problem only to realize that the trend had not predicted it, or that worse still, the trend did show a change but for various reasons we did not take real notice? In this article I intend to give some insight into why in the early days there were significant limitations and why the current state of the art has come a long way towards being a reliable and useable tool.
My own experience with trending began in a rather unusual way. In mid 1981, completely out of the blue, a Gulfstream II crew chief (of a large customer with four G2 aircraft) called me wanting to discuss setting up an engine trending program on his personal Radio Shack TRS80 micro-computer. I remember it distinctly, as he not only amusingly referred to the computer as a ‘Trash 80’ but I found the discussion intriguing. So much so that I ended up persuading management to buy a then brand-new IBM PC for my use and then writing (in BASIC) all of the original test cell and trending programs for Airwork. Thus began a career long involvement with engine testing and on-wing performance that continues to this day.
Ultimately, trending is an attempt to anticipate problems in order to control and minimize aircraft downtime and engine operating cost. Over the last forty years Trend Monitoring (or Condition Monitoring) of in-service engine performance data, has migrated from such technically astute amateurs with early personal computers and curiosity, through a few small independent businesses and MRO’s (such as Airwork and later Dallas Airmotive) that provided a service to operators and now to OEM’s with very sophisticated AI assisted modeling.
So, how does trending work and what are the strengths and weaknesses of the output of the analysis and what has changed to make this a tool that companies are prepared to expend significant capital and effort to make work?
As most in this business know the basic idea is to gather a set of data of the engines’ operating performance on the wing, and set up a reference dataset to which subsequent data can be compared, identify changes and use those changes as a health indicator or diagnostic tool.
It’s probably intuitively obvious that, for example, the higher the temperature of the air entering the engine the higher the temperature exiting the engine. This means that ambient conditions have a direct effect on engine operation; the principal ambient conditions we need to correct for are air pressure and temperature. To effectively compare our subsequent engine data sets to the baseline values they must somehow be converted to the baseline ambient conditions. In actuality, we convert all of the data, including the data of the baseline values themselves to a standard set of conditions. This allows easy comparison of the engine to other engines of the same type as well as to itself and, with some caveats, comparison to the engine test cell data.
By convention and for convenience we generally convert the data to a set of standard conditions that are known as ‘Sea Level Static’ or SLS. ‘Sea Level’ refers to the ICAO Standard Atmosphere values of Temperature and Atmospheric Pressure at sea level, these are 15 Degrees Celsius (59 F) and 14.67 psi (29.92 ins Hg) respectively, and ‘Static’ refers to zero wind speed and no forward motion of the engine. As implied above, these are the same reference ambient conditions used in engine test cells for pre-release acceptance.
To perform this conversion we use a set of standard mathematical procedures that allow conversion of engine parameters, such as speeds and temperatures, to SLS conditions. These procedures are based on knowing the outside static air temperature, the forward speed and the operating altitude as well as key engine operating parameters, all of which are typically available in the cockpit. We also need to recognize that flying the aircraft brings with it changes in ambient conditions that the engines will encounter, such as altitude and forward speed, which can cause data errors which we call ‘data skew’. Because of this it was, until recently, standard procedure to only take data readings when the aircraft was in stable level flight, and the engines had been allowed to operate at a constant throttle position for some minimum time.
By performing these conversions, we can compare engine operating performance to a standard but, as you might guess, the accuracy and resulting diagnostic benefits rely to a large extent on several factors:
The accuracy of the source data,
The maturity of the analysis system (how comprehensive is the knowledge base) and,
The frequency and skill of the data review.
Let’s take a brief look at the history of these factors over the last forty years and the changes, both deliberate and incidental, that have brought us to the present day:
The accuracy of the source data:
The adage we have all heard with respect to computers or, for that matter, any method of analysis, is GIGO, ‘garbage in garbage out’. Simply, if we feed the system inaccurate data then we will get the wrong answers.
In the early days of trending, and still used on some older aircraft today, input data largely relied on the aircraft being in stable flight and a pilot filling out a form that recorded cockpit readings of both aircraft flight data and engine data.
Ensuring the aircraft and engines were in stable operating conditions for a defined period of time. i.e. ‘straight and level with throttles not touched’.
How much care was taken when noting the reading on mostly analog gages.
Which pilot took the data (potential parallax error while looking at a gage)
Data skew’ errors where, because of the time involved, flight conditions may have changed between the first and last recorded reading.
Today we still require this same data, but the method of acquiring it has become either flight management systems, digital electronic engine controls or, in some cases, STC’d recording devices to capture and store it (not to mention their ability to alert the crew with error messages).
The ability of these systems to very rapidly capture multiple channels of data essentially eliminates ‘data skew’, which means we no longer require the aircraft to be in stable flight. We can now record data during other, more transient, phases of flight such as engine start, takeoff, climb, descent and landing as well as cruise.
We now have the ability to take multiple ‘snapshots’ and average them when appropriate. Thus the ‘data space’ available for analysis has been greatly expanded and the accuracy and consistency of the data gives confidence in the analysis.
One issue that can be mitigated, but never completely eliminated, is the accuracy of the instrument / sensor itself. However, with years of sensor development and hugely increased input data to analyze there are statistical and / or AI learning processes that can quickly identify this as a potential issue.
The Maturity of the Analysis system:
If you are a single aircraft operator then the database you build is clearly going to be relatively small, which is not to say unusable. After all, at the fundamental level you are looking for changes against the engine’s own baseline.
OEM’s in particular have embraced trending as, given the drive towards on-condition maintenance and the parallel adoption of Power by the Hour (PBH) programs, what was once the operator’s cost is now theirs.
Pre-emptive diagnosis is key to this and for those operators on a PBH program the regular submission of flight management system or engine electronic control (FADEC, DEEC etc.) downloaded data is generally a maintenance requirement.
Today, engine trending is one of the key enablers of engine ‘on-condition’ maintenance along with such capabilities as video borescopes, digital data recording, spectrographic oil analysis and vibration monitoring / analysis.
At a higher-level a large database of many engines allows comparisons with how the fleet as a whole is operating and can vey quickly identify non-obvious issues such as bad sensors or sensor calibration.
Large Fleet databases allow an overview of the rates of deterioration of engines on average and the variation. This aids in planning downtime, rental fleet size and even such things as geographic location effects.
It’s a natural tendency to believe the data you record but this is not always the case, comparison with how other engines are performing can identify this as a possible source of error quickly.
This simple fact gives the owners of large databases, such as the OEM’s and organizations such as CAMP, an inherent advantage.
For the OEM’s, who have all begun to invest heavily in AI, it provides a ready-made source of training data for their AI modules.
Frequency and quality of review:
Ideally a review after every flight would allow some level of confidence in spotting any significant change or apparent change to the engine.
It is not unusual in my experience that trends are only reviewed, at least by small fleet operators, when a pilot reports something anomalous.
Experience in interpreting the trends has always been a skill only gained with time which is now being augmented by AI systems.
Changes are much easier to spot when the source data is collected electronically, rather than manually by the pilot, as the corrected data is much more consistent with far less scatter.
With reliable input data statistical / AI methods can be used to very quickly diagnose problems.
In summary, even though trending has been useful in many ways over the years, it is clear that current aircraft with their inbuilt engine data acquisition systems are inherently much more accurate and reliable, which has largely overcome the GIGO issues. As FADEC’s and Flight Management systems were really developed to enable better, more reliable control of engines and aircraft, the by-product of good, clean, repeatable engine and flight data can be viewed as a happy piece of serendipity. The same can be said of the resources committed by the OEM’s who once largely viewed Trending as an uncertain science. Their interest in PBH programs was almost solely driven by the desire to accelerate recovery of their capital investment in engine development and improve their ongoing cash-flow. Ultimately though, as this focused their attention on minimizing costs, PBH led to fleet databases, improved sensors and AI diagnostics.
Serendipitous or not, ultimately, these developments have given the Operator the potential for much improved control over engine cost, predictability and downtime.
For more information on the science behind trend monitoring please see “How to Correct engine data to SLS conditions”.
Comments