Patent Description:
Entities desire that their assets operate optimally while on-line, that they are off-line as little time as possible, that all repair/refurbishment is scheduled (no unscheduled events/maintenance), and that failure events are avoided. For instance, operators of aircraft desire that their engines operate at high efficiency and performance, spend as little time as possible off wing or offboard, that all repairs and service visits are scheduled, and that significant failure events of engine components are avoided. Knowing the health state of an engine and/or one or more components thereof can facilitate accomplishing these goals.

Understanding the health state of an engine and/or one or more components thereof can present a number of challenges. For instance, aviation gas turbine engines typically have limited onboard sensors to measure or sense values for parameters that can indicate an engine/component health state. Conventionally, the health state of an engine and/or a component thereof has been based on a limited number of snapshots of data captured at various timepoints during operation of the engine. Each snapshot includes captured values for various parameters. The captured parameter values are fed into a health state module and the output is the health state of the engine and/or one or more components thereof. While the health state of conventional modules can provide insight into an engine's health state, the health state may only be based on only a limited number of snapshots. This limited number of snapshots may not provide the level of granularity required to reduce unscheduled engine removals (UER) and significant events and plan/target repair/maintenance for engine health issues to maximize Time-On-Wing (TOW).

Accordingly, systems and methods that address one or more of the challenges noted above would be useful.

<CIT> discloses a system and method for use in monitoring equipment condition employs an empirical model, a rules engine, incident generation and resolution logic, a display interface, and a messaging capability for interacting with other systems.

Aspects of the present disclosure are directed to distributed control systems and methods of controlling turbomachines.

In one aspect, a system is provided according to claim <NUM>.

In another aspect, a method is provided according to claim <NUM>.

The terms "upstream" and "downstream" refer to the relative flow direction with respect to fluid flow in a fluid pathway. For example, "upstream" refers to the flow direction from which the fluid flows, and "downstream" refers to the flow direction to which the fluid flows.

Aspects of the present disclosure are directed to a system and method for monitoring and diagnosis of the health of an asset, such as an aviation gas turbine engine. The systems and methods provided herein utilize a snapshot-continuous operating data based approach to determine the health status of an asset. Conventionally, continuous operating data has not been utilized to generate health estimates.

During operation of an asset, two types of data are captured, including snapshot data and Continuous Operating Data (COD). Snapshot data is captured at various timepoints during operation of the asset. That is, at a particular point in time, a "snapshot" of the operating conditions of the asset are captured. A snapshot includes values for various parameters at a particular point in time during operation of the asset. Continuous operating data is captured continuously during operation of the asset. Particularly, continuous operating data can be collected during a collection time period, e.g., from the start to the end of a flight. The continuous operating data can include a vast amount of data that includes captured values for various parameters over the collection time period. One or more sensors associated with the asset can sense or measure the values for the parameters of both types of data.

In one aspect, a system receives the continuous operating data associated with the asset. The continuous operating data includes parameter values for parameters over the collection time period. The system generates synthetic snapshot data based at least in part on the continuous operating data. The synthetic snapshot data includes one or more synthetic snapshots each containing the parameter values for the one or more parameters for a given timepoint within the collection time period. In some embodiments, the system creates one or more new snapshots by applying a machine-learned model that utilizes one or more COD-snapshot transfer functions that correlate the one or more synthetic snapshots with historical snapshot data associated with the aviation gas turbine engine. In some embodiments, the system can create one or more new snapshots by applying a set of rules. In addition to receiving continuous operating data, the system also receives snapshot data associated with the gas turbine engine, the snapshot data including one or more snapshots each containing parameter values for the one or more parameters for a given timepoint within the collection time period. The system adds the one or more new snapshots to the snapshot data.

The system applies one or more time-series pattern recognition techniques to the snapshot data to determine at least one alert score associated with the snapshot data. The alert score(s) associated with the snapshot data are determined based at least in part on one or more detected features associated with the parameter values for the one or more parameters of the snapshot data. Further, the system applies one or more time-series pattern recognition techniques to the synthetic snapshot data to determine at least one alert score associated with the synthetic snapshot data. The alert score(s) associated with the synthetic snapshot data are determined based at least in part on one or more detected features associated with the parameter values for the one or more parameters of the synthetic snapshot data. The system aggregates the at least one alert score associated with the snapshot data and the at least one alert score associated with the synthetic snapshot data via a probabilistic aggregation technique into an aggregated alert score. The system generates an output indicating a health status of the asset or one or more components thereof based at least in part on the one or more snapshots, new snapshots, and synthetic snapshots, or more particularly, based at least in part on the aggregated alert score. In this way, the output indicating the health status of the asset is based on both received snapshot data and received COD data.

<FIG> provides a schematic cross-sectional view of an aviation gas turbine engine according to one example embodiment of the present subject matter. Particularly, <FIG> provides an aviation high-bypass turbofan engine herein referred to as "turbofan <NUM>". The turbofan <NUM> of <FIG> can be mounted to an aerial vehicle, such as a fixed-wing aircraft, and can produce thrust for propulsion of the aerial vehicle. For reference, the turbofan <NUM> defines an axial direction A, a radial direction R, and a circumferential direction. Moreover, the turbofan <NUM> defines an axial centerline or longitudinal axis <NUM> that extends along the axial direction A for reference purposes. In general, the axial direction A extends parallel to the longitudinal axis <NUM>, the radial direction R extends outward from and inward to the longitudinal axis <NUM> in a direction orthogonal to the axial direction A, and the circumferential direction extends three hundred sixty degrees (<NUM>°) around the longitudinal axis <NUM>.

The turbofan <NUM> includes a core gas turbine engine <NUM> and a fan section <NUM> positioned upstream thereof. The core engine <NUM> includes a tubular outer casing <NUM> that defines an annular core inlet <NUM>. The outer casing <NUM> further encloses and supports a booster or low pressure compressor <NUM> for pressurizing the air that enters core engine <NUM> through core inlet <NUM>. A high pressure, multi-stage, axial-flow compressor <NUM> receives pressurized air from the LP compressor <NUM> and further increases the pressure of the air. The pressurized air stream flows downstream to a combustor <NUM> where fuel is injected into the pressurized air stream and ignited to raise the temperature and energy level of the pressurized air. The high energy combustion products flow from the combustor <NUM> downstream to a high pressure turbine <NUM> for driving the high pressure compressor <NUM> through a high pressure spool <NUM> or a second rotatable component. The high energy combustion products then flow to a low pressure turbine <NUM> for driving the LP compressor <NUM> and the fan section <NUM> through a low pressure spool <NUM> or a first rotatable component. The LP spool <NUM> is coaxial with the HP spool <NUM> in this example embodiment. After driving each of the turbines <NUM> and <NUM>, the combustion products exit the core engine <NUM> through an exhaust nozzle <NUM> to produce propulsive thrust.

The fan section <NUM> includes a rotatable, axial-flow fan rotor <NUM> that is surrounded by an annular fan casing <NUM>. The fan casing <NUM> is supported by the core engine <NUM> by a plurality of substantially radially-extending, circumferentially-spaced outlet guide vanes <NUM>. In this way, the fan casing <NUM> encloses the fan rotor <NUM> and a plurality of fan blades <NUM>. A downstream section <NUM> of the fan casing <NUM> extends over an outer portion of the core engine <NUM> to define a bypass passage <NUM>. Air that passes through the bypass passage <NUM> provides propulsive thrust as will be explained further below. In some alternative embodiments, the LP spool <NUM> may be connected to the fan rotor <NUM> via a speed reduction device, such as a reduction gear gearbox in an indirect-drive or geared-drive configuration. Such speed reduction devices can be included between any suitable shafts/spools within the turbofan <NUM> as desired or required.

During operation of the turbofan <NUM>, an initial or incoming airflow, represented by arrow <NUM>, enters the turbofan <NUM> through an inlet <NUM> defined by the fan casing <NUM>. The airflow <NUM> passes through the fan blades <NUM> and splits into a first air flow (represented by arrow <NUM>) that moves through the bypass passage <NUM> and a second air flow (represented by arrow <NUM>) which enters the LP compressor <NUM> through the core inlet <NUM>.

The pressure of the second airflow <NUM> is progressively increased by the LP compressor <NUM> and then enters the HP compressor <NUM>, as represented by arrow <NUM>. The discharged pressurized air stream flows downstream to the combustor <NUM> where fuel is introduced to generate combustion gases or products. The combustion products <NUM> exit the combustor <NUM> and flow through the HP turbine <NUM>. The combustion products <NUM> then flow through the LP turbine <NUM> and exit the exhaust nozzle <NUM> to produce thrust. Moreover, as noted above, a portion of the incoming airflow <NUM> flows through the bypass passage <NUM> and through an exit nozzle defined between the fan casing <NUM> and the outer casing <NUM> at the downstream section <NUM> of the fan casing <NUM>. In this way, substantial propulsive thrust is produced.

As further shown in <FIG>, the combustor <NUM> defines an annular combustion chamber <NUM> that is generally coaxial with the longitudinal centerline axis <NUM>, as well as an inlet <NUM> and an outlet <NUM>. The combustor <NUM> receives an annular stream of pressurized air from a high pressure compressor discharge outlet <NUM>. A portion of this compressor discharge air ("CDP" air) flows into a mixer (not shown). Fuel is injected from a fuel nozzle <NUM> to mix with the air and form a fuel-air mixture that is provided to the combustion chamber <NUM> for combustion. Ignition of the fuel-air mixture is accomplished by a suitable igniter, and the resulting combustion gases <NUM> flow in an axial direction A toward and into an annular, first stage turbine nozzle <NUM>. The nozzle <NUM> is defined by an annular flow channel that includes a plurality of radially-extending, circumferentially-spaced nozzle vanes <NUM> that turn the gases so that they flow angularly and impinge upon the first stage turbine blades of the HP turbine <NUM>. For this embodiment, the HP turbine <NUM> rotates the HP compressor <NUM> via the HP spool <NUM> and the LP turbine <NUM> drives the LP compressor <NUM> and the fan rotor <NUM> via the LP spool <NUM>.

Although turbofan <NUM> has been described and illustrated in <FIG> as representing an example gas turbine engine, the subject matter of the present disclosure may apply to other suitable types of engines and turbomachines. For instance, the subject matter of the present disclosure may apply to or be incorporated with other suitable turbine engines, such as steam and other gas turbine engines. Example gas turbine engines may include, without limitation, turbojets, turboprop, turboshaft, aeroderivatives, auxiliary power units, etc. Further, as will be explained below, a gas turbine engine, such as the turbofan <NUM>, is one example of an asset that can be monitored and diagnosed by the systems and methods described herein.

<FIG> provides a block diagram of a system <NUM> according to one example embodiment of the present subject matter. The system <NUM> is operable to monitor and diagnose the health of an asset <NUM> or many assets. In the depicted embodiment of <FIG>, the asset <NUM> is the turbofan <NUM> of <FIG>. It will be appreciated, however, that the system <NUM> can be utilized to monitor and diagnose the health of other assets, such as any suitable machine, device, system, etc. for which health monitoring is desirable. As one example, the asset can be the landing gear of an aircraft. As another example, the asset can be the main rotor of a rotary aircraft. As yet another example, the asset can be a drill bit of a drillstring for oil and gas exploration. These examples are not intended to be limiting; other examples are contemplated.

The asset <NUM> can include one or more associated sensors <NUM> for measuring or sensing the operating conditions of the asset <NUM>, e.g., during operation of the asset <NUM>. Particularly, the sensors <NUM> can measure or sense values for one or more parameters indicative of the operating conditions of the asset <NUM>. Example parameters that may be recorded for a gas turbine engine include, without limitation, the low pressure spool speed N1, the high pressure or core spool speed N2, the compressor inlet pressure and temperature P2, T2, respectively, the compressor discharge pressure P3, and/or the temperature at the inlet or outlet of the combustor, T3 and T45, respectively. Other example parameters may include the altitude, air speed, ambient temperature, weather conditions, etc. Values for other parameters can be sensed as well.

Generally, two types of data are captured by the one or more sensors <NUM> of the asset <NUM>, including snapshot data and continuous operating data (COD). COD is also referred to as continuous engine operating data (CEOD) in the aviation gas turbine engine field. The two data types will be further explained below.

Generally, the snapshot data includes one or more snapshots or snapshots of data captured at a given point in time, or "timepoint. " Each snapshot contains parameter values for one or more parameters for a given timepoint. For instance, with reference to <FIG> and <FIG>, <FIG> provides a block diagram of snapshot data <NUM> according to one example embodiment of the present subject matter. <FIG> provides a graph depicting the altitude of an aircraft to which the asset <NUM> is mounted during a flight as a function of time. <FIG> also illustrates snapshots captured during the flight, wherein the snapshots are part of the snapshot data <NUM> of <FIG>. As shown, various snapshots are captured during operation of the asset <NUM>. Particularly, the snapshot data <NUM> includes a first snapshot S1 captured at time t1, a second snapshot S2 captured at time t2, and a third snapshot S3 captured at time t3. It will be appreciated that the snapshot data <NUM> can include other snapshots of data as well, denoted by the Nth snapshot captured at time tN. The snapshot data <NUM> can include any suitable number of snapshots. As used herein, N denotes any suitable integer.

Each snapshot S1, S2, S3, SN includes parameter values for one or more parameters for a given timepoint. For instance, the first snapshot S1 captured at time t1 includes parameter values PV1-<NUM>, PV2-<NUM>, PV3-<NUM>, PVN-<NUM> that correspond to a first parameter P1, a second parameter P2, a third parameter P3, and an Nth parameter, respectively. All of the parameter values for the first snapshot S1 are captured at time t1. Likewise, the second snapshot S2 captured at time t2 includes parameter values PV1-<NUM>, PV2-<NUM>, PV3-<NUM>, PVN-<NUM> that correspond to the first, second, third, and Nth parameters P1, P2, P3, PN, respectively. All of the parameter values for the second snapshot S2 are captured at time t2. Further, the third snapshot S3 captured at time t3 includes parameter values PV1-<NUM>, PV2-<NUM>, PV3-<NUM>, PVN-<NUM> that correspond to the first, second, third, and Nth parameters P1, P2, P3, PN, respectively. All of the parameter values for the third snapshot S3 are captured at time t3. Other snapshots can include parameter values for the parameters as well, as represented in the Nth snapshot.

Snapshots can be captured based upon a trigger condition. As one example, snapshots can be captured at a predetermined time interval. As another example, snapshots can be captured when the aircraft to which the asset <NUM> is mounted reaches a predetermined altitude. For instance, as shown in <FIG>, the aircraft operates in various flight phases (FP), including takeoff FP1, climb FP2, cruise FP3, and descent and landing FP4. As shown, the predetermined altitudes are set in this example such that the first snapshot S1 is captured during takeoff FP1, the second snapshot S2 is captured during climb FP2, and the third snapshot S3 is captured during the cruise FP3. As noted above, other snapshots can be captured. For example, a snapshot can be captured after the aircraft performs a step climb SC while in cruise FP3 or when the aircraft reaches a predetermined altitude a second time, such as at some point during descent and landing FP4. To summarize, the snapshot data <NUM> includes one or more snapshots of data that each capture the operating conditions of the asset <NUM> or some component thereof at a given timepoint.

Returning to <FIG>, as depicted, the asset <NUM> can include or be associated with a communication unit <NUM>. Sensed snapshots or snapshot data can be routed to the communication unit <NUM>. The communication unit <NUM> can be a digital data link system or communications management unit (CMU) of an aircraft to which the asset <NUM> is mounted. Accordingly, in some embodiments, the communication unit <NUM> can be an Aircraft Communications, Addressing and Reporting System (ACARS), for example. The communication unit <NUM> can be mounted directly to the asset <NUM> or can be positioned remote from the asset <NUM>, e.g., within with the fuselage of the aircraft to which the asset <NUM> is mounted. The communication unit <NUM> can include one or more processors, one or memory devices, and a communication interface for communicating messages, alerts, etc. to a remote station. As one example, the snapshot data can be received and stored by the communication unit <NUM>. The communication unit <NUM> can then transmit the snapshot data to a remote station, such as a ground station or another aircraft. The snapshot data can be transmitted to the remote station using any suitable transmission technique and protocol. As will be explained further herein, the system <NUM> can receive the snapshot data and make health assessments of the asset <NUM> based on the received snapshot data.

In addition to the snapshot data, the one or more sensors <NUM> of the asset <NUM> can capture COD, or in this example, CEOD. Generally, as the name implies, COD is captured continuously over a time period, e.g., a COD collection time period spanning from a start point to an endpoint. The COD includes parameter values captured for one or more parameters over the time period. Values for parameters can be captured at different capture rates, e.g., once every millisecond, once every second, once every three seconds, etc. The parameter values for the parameters are captured in frames or capture frames.

For instance, with reference to <FIG> and <FIG>, <FIG> provides a block diagram of COD <NUM> according to one example embodiment of the present subject matter. <FIG> provides a graph depicting the altitude of the aircraft to which the asset <NUM> is mounted during flight as a function of time. <FIG> also illustrates the time period over which the COD of <FIG> is captured. As shown in <FIG>, the COD <NUM> includes time-sequential capture frames, including a first capture frame CF1, a second capture frame CF2, a third capture frame CF3, and so on to the Nth capture frame CFN. The COD <NUM> can include any suitable number of capture frames.

Each capture frame CF1, CF2, CF3, CFN of the COD <NUM> includes parameter values captured for one or more parameters. For instance, the first capture frame CF1 has captured parameter values V1-<NUM>, V2-<NUM>, V3-<NUM>, VN-<NUM> that correspond to the first parameter P1, the second parameter P2, the third parameter P3, and the Nth parameter, respectively. As the asset continues to operate, additional capture frames of parameter values are captured. Particularly, the second capture frame CF2 has captured parameter values V1-<NUM>, V2-<NUM>, V3-<NUM>, VN-<NUM> that correspond to the first, second, third, and Nth parameters P1, P2, P3, PN, respectively. Moreover, the third capture frame CF3 has captured parameter values V1-<NUM>, V2-<NUM>, V3-<NUM>, VN-<NUM> that correspond to the first, second, third, and Nth parameters P1, P2, P3, PN, respectively. As will be appreciated, the COD <NUM> can include many more captured frames of data than shown in <FIG> as represented by the Nth capture frame. Some of the parameters for which values are captured for the snapshot data and the parameters for which values are captured for the COD data can be the same or overlap. Accordingly, some of the values captured for the snapshot data and the values captured for the COD data can be the same or overlap.

COD <NUM> can be captured over a period of time as noted above. The COD collection time period can span between a start point and an end point. As shown in <FIG>, in some embodiments, the start point can correspond with a time at or before takeoff of the aircraft to which the asset <NUM> is mounted. The COD <NUM> can commence being sensed and recorded upon power up or spooling up of the asset <NUM>, while taxiing for takeoff, or at another suitable point in time, e.g., just before or just after takeoff. COD <NUM> can be continuously sensed and recorded for an entire flight or part of a flight as desired. For the depicted flight in <FIG>, the COD <NUM> is sensed and recorded from the start point, which occurs prior to takeoff, to the end point, which occurs after the aircraft has landed.

Returning again to <FIG>, the asset <NUM> can include or be associated with a recorder <NUM> that records the COD <NUM>. For instance, an engine monitoring unit or "black box" of a vehicle to which the asset <NUM> is mounted can record the sensed COD <NUM>. The sensed COD <NUM> can be stored in one or more memory devices of the recorder <NUM>. The recorder <NUM> can be mounted to the asset <NUM> (e.g., to or under a cowling) or can be positioned remote from the asset <NUM> (e.g., in an avionics bay of an aircraft to which the asset <NUM> is mounted). Once recorded and stored in the recorder <NUM>, the COD <NUM> is transmitted, routed, or otherwise moved to a remote station, e.g., by wired communication links, wirelessly, or by some other method. The COD <NUM> can be moved to the remote station automatically or manually. The COD <NUM> can be transmitted to the remote station using any suitable transmission technique and protocol. As will be explained further herein, the system <NUM> can receive the COD <NUM> in addition to the snapshot data and make health assessments associated with the asset <NUM> based on the received snapshot data and the COD data.

The system <NUM> will now be described in detail. Generally, as noted above, the system <NUM> is operable to monitor and diagnose the health of the asset <NUM> or components thereof. The system <NUM> can include one or more processing devices and one or more memory devices, e.g., embodied in one or more computing devices and data stores. The one or more memory devices can store data and instructions accessible by the one or more processors, including computer-readable instructions that can be executed by the one or more processors. The instructions can be any set of instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, such as the operations described herein for monitoring and diagnosing the health of the asset <NUM>.

As shown in <FIG>, the system <NUM> receives the snapshot data <NUM> associated with the asset <NUM>. The received snapshot data <NUM> is stored in a data store, such as snapshot data store <NUM>. In addition, the system <NUM> receives the COD <NUM> associated with the asset <NUM>. The received COD <NUM> is stored in a data store, such as COD data store <NUM>. With the COD <NUM> stored, the COD <NUM> is accessed and at parameter calculation module <NUM>, the one or more processors of the system <NUM> determine one or more values for additional parameters associated with the asset <NUM> based at least in part on the COD <NUM>. By way of example, as noted, the COD <NUM> can include sensed parameter values for various parameters, such as pressures and temperatures at different stations of the engine, ambient temperature, shaft spool speed, etc. The sensed values for these parameters can be utilized to calculate or determine values for other parameters associated with the asset <NUM>. For example, parameter values for parameters such as exhaust gas temperature (EGT), engine pressure ratios, stall margin, various mass flows, various efficiencies, etc. can be determined based at least in part on the sensed values. Calculated parameter values can be useful for monitoring and assessing the health of the asset <NUM>. The calculated values for the parameters can be added to or otherwise included in the COD <NUM>.

At a synthetic snapshot generator module <NUM>, the COD <NUM> that includes the sensed and calculated values for the parameters associated with the asset <NUM> is processed. Particularly, one or more processing devices of the system <NUM> can generate synthetic snapshot data <NUM> based at least in part on the COD <NUM>. The generated synthetic snapshot data can include one or more synthetic snapshots. Each synthetic snapshot can contain sensed and/or calculated parameter values for the one or more parameters for a given timepoint within the time period, i.e., the time period spanning from the start point to the end point of COD collection. For example, <FIG> shows synthetic snapshots generated at various timepoints within the COD collection time period. Particularly, a first synthetic snapshot SN1 is generated at a timepoint t1-SN, a second synthetic snapshot SN2 is generated at a timepoint t2-SN, and a third synthetic snapshot SN3 is generated at a timepoint t3-SN. By generating synthetic snapshots, the vast amount of data included in the COD <NUM> can be broken down into manageable, easier to handle data points that can be used to monitor and diagnose the health of the asset <NUM> or components thereof.

The synthetic snapshots can be generated for any suitable timepoints within the COD collection time period. As one example, the synthetic snapshots can be generated at timepoints that are spaced in time midway between snapshots captured as part of the snapshot data. As another example, the synthetic snapshots can be generated at timepoints such that there is at least one synthetic snapshot spaced a predetermined time (e.g., <NUM> seconds) from each snapshot captured as part of the snapshot data. As yet another example, the synthetic snapshots can be generated at timepoints that correspond with a maximum or minimum value for a particular parameter in one, some, or all the flight phases. For instance, one synthetic snapshot can be generated at a timepoint that corresponds with a maximum pressure at the outlet of the compressor of the asset <NUM> during takeoff, one synthetic snapshot can be generated at a timepoint that corresponds with a maximum pressure at the outlet of the compressor of the asset <NUM> during climb, one synthetic snapshot can be generated at a timepoint that corresponds with a maximum pressure at the outlet of the compressor of the asset <NUM> during cruise, and so on for each flight phase. In some embodiments, multiple synthetic snapshots can be generated at timepoints within a given flight phase, some of the flight phases, or all flight phases. For instance, a first synthetic snapshot that corresponds with a maximum or minimum value for a first parameter in a given one of the flight phases can be generated at a first timepoint and a second synthetic snapshot that corresponds with a maximum or minimum value for a second parameter in the same flight phase can be generated at a second timepoint. The synthetic snapshots can be generated at timepoints within the COD collection time period based on other criteria and/or considerations as well.

In some embodiments, one or more of the synthetic snapshots can include parameter values from a single capture frame. In some embodiments, one or more of the synthetic snapshots a given or multiple capture frames in close time-proximity to one another. For example, in some instances, a parameter value for every needed parameter to create a synthetic snapshot is sensed in a given capture frame. To obtain a parameter value for the needed parameter, a parameter value from an adjacent-in-time or closest-in-time capture frame can be utilized to generate the synthetic snapshot.

As shown in <FIG>, for this embodiment, the generated synthetic snapshot data, which includes the synthetic snapshots, is routed to two modules, including a snapshot creator module <NUM> and a synthetic health module <NUM>. In some alternative embodiments, the system <NUM> does not include the snapshot creator module <NUM>. Accordingly, in such alternative embodiments, the synthetic snapshot data is routed to the synthetic health module <NUM> but not the snapshot creator module <NUM>.

The snapshot creator module <NUM> is utilized as a feature generation tool. Particularly, the synthetic snapshot data <NUM> generated at the synthetic snapshot generator module <NUM> is input into the snapshot creator module <NUM>. The snapshot creator module <NUM> then creates one or more new snapshots using the synthetic snapshot data <NUM>. The one or more new snapshots can be added to the snapshot data <NUM> stored in the snapshot data store <NUM>. In this way, the new snapshots can enhance or augment the snapshot data. The increased number of data points may increase the confidence in the health alerts provided by the system <NUM>.

The snapshot creator module <NUM> creates the new snapshots by applying one or more machine-learned models that utilize one or more COD-snapshot transfer functions that correlate the one or more synthetic snapshots with historical snapshot data associated with the asset. In some embodiments, the historical snapshot data includes the snapshot data received at the snapshot data store <NUM> for the most recent flight or operation cycle. The snapshot creator module <NUM> can include instructions, models, functions, etc. The one or more processors of the system <NUM> can execute the instructions to implement the models, functions, etc. to ultimately create the new snapshots.

By way of example, <FIG> provides a block diagram depicting the snapshot creator module <NUM> of the system <NUM> creating new snapshots. As shown, the synthetic snapshot data <NUM> is input into the snapshot creator module <NUM>. The synthetic snapshot data <NUM> includes a first synthetic snapshot SN1, a second synthetic snapshot SN2, a third synthetic snapshot SN3, and so on to the Nth synthetic snapshot SNN. As noted above, each synthetic snapshot SN1, SN2, SN3, SNN can include values for parameters for a given timepoint. As depicted in <FIG>, the synthetic snapshots SN1, SN2, SN3, SNN are fed into a machine-learned model <NUM>. Particularly, the synthetic snapshots SN1, SN2, SN3, SNN are fed into COD-snapshot transfer functions of the machine-learned model <NUM>. In this example, the one or more COD-snapshot transfer functions include a first COD-snapshot transfer function TF1, a second COD-snapshot transfer function TF2, a third COD-snapshot transfer function TF3, and so on to the Nth COD-snapshot transfer function. The one or more COD-snapshot transfer functions TF1, TF2, TF3, TFN correlate the one or more synthetic snapshots SN1, SN2, SN3, SNN with historical snapshot data associated with the asset <NUM>. In this way, the inputs, which in this example are the values for the parameters of the synthetic snapshots SN1, SN2, SN3, SNN, can be utilized by the transfer functions TF1, TF2, TF3, TFN to generate outputs, which in this example is the new snapshot data <NUM>, which includes a first new snapshot NS1, a second new snapshot NS2, a third new snapshot NS3, and so on to the Nth new snapshot NSN.

The machine-learned model <NUM>, or more particularly the COD-transfer functions, can be trained based on historical snapshot data points. The COD-transfer functions can be trained based on COD and snapshot data obtained by the system <NUM> and can be retrained periodically as new data is obtained. In some instances, the transfer functions can be trained/retrained using snapshot data from a flight from which the COD used to generate the synthetic snapshot data is generated prior to the new data points being created. In this manner, the transfer functions can be trained with the most up-to-date data. In addition, the machine-learned model <NUM> can be trained based at least in part on the historical snapshot data associated with the asset <NUM> and fleet historical snapshot data associated with other assets that are a same model as the asset <NUM>. For instance, the fleet historical snapshot data can include snapshot data captured by other aviation gas turbine engines during their respective flights. In some alternative embodiments, the snapshot creator module <NUM> creates the new snapshots by applying a set of rules rather than on a trained machine-learned model or models.

Returning to <FIG>, with the new snapshots created, the new snapshots are added to the snapshot data <NUM> stored in the snapshot data store <NUM>. The snapshot data <NUM>, which includes the snapshots captured by the sensors <NUM> of the asset <NUM> or calculated therefrom and the new snapshots created by the snapshot creator module <NUM>, is input into a snapshot health module <NUM>. And as noted above, the synthetic snapshot data <NUM> generated at the synthetic snapshot generator module <NUM> is input into the synthetic health module <NUM>. Generally, the snapshot health module <NUM> and the snapshot health module <NUM> apply one or more time-series pattern recognition techniques or anomaly detection techniques using their respective received data to output alert scores for various alerts that indicate a health status of the asset <NUM> or one or more components thereof.

By way of example, <FIG> provides a block diagram depicting the snapshot health module <NUM> of the system <NUM> generating alert scores for various alerts that indicate a health status of the asset <NUM> or a component thereof. As depicted, the snapshot data <NUM> is input into the snapshot health module <NUM>. The snapshot data <NUM> includes the snapshots, e.g., S1, S2, S3, SN as shown in <FIG>, as well as the new snapshots, e.g., NS1, NS2, NS3, NSN as shown in <FIG>. The one or more time-series pattern recognition techniques <NUM> can be applied or utilized to detect certain features in the input snapshot data <NUM>. For example, the one or more time-series pattern recognition techniques <NUM> can be applied to detect trends, shifts, changes, or otherwise detect anomalies as well as other features in certain sensed or calculated parameter values in the input snapshot data <NUM>. Any suitable number of features can be considered.

For instance, in <FIG>, the features <NUM> include a first feature F1, a second feature F2, a third feature F3, a fourth feature F4, and so on to the Nth feature FN. As one example, the first feature F1 can be associated with detecting a shift for a first parameter, the second feature F2 can be associated with detecting a trend for the first parameter, the third feature F3 can be associated with detecting a shift for a second parameter, and the fourth feature F4 can be associated with detecting a trend for the second parameter. Other features can be associated with detecting shifts and/or trends in other parameters of the snapshot data.

One or more time-series pattern recognition techniques <NUM> or anomaly detection techniques can be applied to detect the features <NUM> in the received snapshot data <NUM> as noted above. Particularly, the applied time-series pattern recognition techniques <NUM> can be used to determine whether a given feature (e.g., a shift or trend associated with a parameter) exceeds a predetermined threshold. The predetermined thresholds can be set or determined based on historical data, for example. The predetermined thresholds can be any suitable types or combinations of thresholds. For instance, the predetermined thresholds can be rate of change thresholds, shift thresholds, maximum and/or minimum value thresholds, trend thresholds, etc..

An alert score for an alert can be generated based at least in part on whether one or more of the features associated with the alert exceed their respective thresholds. One or multiple features can be associated with a given alert. Alert scores can be generated for each alert. In some embodiments, the alert scores can be binary scores. For instance, when the one or more features associated with an alert exceed their respective thresholds, an alert score of "<NUM>" can be generated for the alert. When the one or more features associated with the alert do not exceed their respective thresholds, an alert score of "<NUM>" can be generated for the alert.

As depicted in <FIG>, for example, alert scores are generated for four alerts, including a first alert (Alert <NUM>), a second alert (Alert <NUM>), a third alert (Alert <NUM>), and a fourth alert (Alert <NUM>). Although four alerts are shown in <FIG>, any suitable number of alerts can be considered or have alert scores generated therefore. The alerts can indicate a health status of the asset <NUM> or a component thereof. As shown, for this example, an alert score of "<NUM>" has been output for Alert <NUM> as its associated features have exceeded their respective thresholds, an alert score of "<NUM>" has been output for Alert <NUM> as its associated features have exceeded their respective thresholds, an alert score of "<NUM>" has been output for Alert <NUM> as its associated features have not exceeded their respective thresholds, and an alert score of "<NUM>" has been output for Alert <NUM> as its associated features have exceeded their respective thresholds. Accordingly, three of the four alerts have output a score of "<NUM>" indicating that their respective one or more associated features have exceeded their respective thresholds. The alert scores output for the alerts can be forwarded to an aggregator <NUM> as shown in <FIG>.

<FIG> provides a block diagram depicting the synthetic health module <NUM> of the system <NUM> generating alert scores for various alerts that indicate a health status of the asset <NUM> or a component thereof. As illustrated, the synthetic snapshot data <NUM> is input into the synthetic health module <NUM>. The synthetic snapshot data <NUM> includes synthetic snapshots, e.g., SN1, SN2, SN3, SNN as shown in <FIG>. The one or more time-series pattern recognition techniques <NUM> can be applied or utilized to detect certain features in the input synthetic snapshot data <NUM>. For example, the one or more time-series pattern recognition techniques <NUM> can be applied to detect trends, shifts, changes, or otherwise detect anomalies as well as other features in certain sensed or calculated parameter values in the input synthetic snapshot data <NUM>. Any suitable number of features can be considered.

For instance, in <FIG>, the features <NUM> include a first feature F1, a second feature F2, a third feature F3, a fourth feature F4, and so on to the Nth feature FN. As one example, the first feature F1 can be associated with detecting a shift for a first parameter, the second feature F2 can be associated with detecting a trend for the first parameter, the third feature F3 can be associated with detecting a shift for a second parameter, and the fourth feature F4 can be associated with detecting a trend for the second parameter. Other features can be associated with detecting shifts and/or trends in other parameters of the snapshot data. The features of the synthetic health module <NUM> can be the same features as utilized in the snapshot health module <NUM> of <FIG>.

One or more time-series pattern recognition techniques <NUM> or anomaly detection techniques can be applied to detect features <NUM> in the received synthetic snapshot data <NUM> as noted above. Specifically, the applied time-series pattern recognition techniques <NUM> can be used to determine whether a given feature (e.g., a shift or trend associated with a parameter) exceeds a predetermined threshold. The predetermined thresholds can be set or determined based on historical data, for example. The predetermined thresholds can be any suitable types or combinations of thresholds. For instance, the predetermined thresholds can be rate of change thresholds, shift thresholds, maximum and/or minimum value thresholds, trend thresholds, etc. The one or more time-series pattern recognition techniques <NUM> applied to the features <NUM> can be the same techniques applied to the features <NUM> of the snapshot health module <NUM> as depicted in <FIG>.

Further, as noted above, an alert score for an alert can be generated based at least in part on whether one or more of the features associated with the alert exceed their respective thresholds. One or more multiple features can be associated with a given alert. Alert scores can be generated for each alert. In some embodiments, the alert scores can be binary scores. For instance, when the one or more features associated with an alert exceed their respective thresholds, an alert score of "<NUM>" can be output for the alert. When the one or more features associated with the alert do not exceed their respective thresholds, an alert score of "<NUM>" can be output for the alert.

As depicted in <FIG>, for example, alert scores are generated for four alerts, including a first alert (Alert <NUM>), a second alert (Alert <NUM>), a third alert (Alert <NUM>), and a fourth alert (Alert <NUM>). Although four alerts are shown in <FIG>, any suitable number of alerts can be considered. The alerts can indicate a health status of the asset <NUM> or a component thereof. As shown, for this example, an alert score of "<NUM>" has been output for Alert <NUM> as its associated features have not exceeded their respective thresholds, an alert score of "<NUM>" has been output for Alert <NUM> as its associated features have exceeded their respective thresholds, an alert score of "<NUM>" has been output for Alert <NUM> as its associated features have not exceeded their respective thresholds, and an alert score of "<NUM>" has been output for Alert <NUM> as its associated features have exceeded their respective thresholds. Accordingly, two of the four alerts have a score of "<NUM>" indicating that their respective one or more associated features have exceeded their respective thresholds and two of the four alerts have a score of "<NUM>" indicating that their respective one or more associated features have not exceeded their respective thresholds. The alert scores generated for the alerts can be forwarded to the aggregator <NUM> as shown in <FIG>.

As shown in <FIG>, the aggregator <NUM> receives the alert scores generated by the snapshot health module <NUM> and the alert scores generated by the synthetic health module <NUM>. The aggregator <NUM> can utilize a probabilistic aggregation technique to generate an output indicative of a health status of the asset <NUM> or a component thereof based at least in part on the alert scores generated by the snapshot health module <NUM> and the alert scores generated by the synthetic health module <NUM>. Particularly, the aggregator <NUM> can aggregate the alert scores associated with the snapshot data and the alert scores associated with the synthetic snapshot data via a probabilistic aggregation technique into an aggregated alert score. The output indicating the health status of the asset or one or more components thereof can be generated based at least in part on the aggregated alert score. The aggregator <NUM> can assign weighted values to alert scores and the output can be generated based on the alert score and the weighted values assigned to the alerts. For instance, one of the alerts can be a prime indicator of health and thus can carry more weight in determining the output. In some embodiments, the aggregator <NUM> can generate the output indicating the health status as one or more time-trend plots that trend or forecast certain parameters.

The generated output indicative of the health status of the asset <NUM> can be utilized by the system <NUM> or some other system to perform a control action. As one example, an electronic engine controller (EEC) of a gas turbine engine (the asset) can control the gas turbine engine based at least in part on the health status of the engine or a component of module thereof (e.g., a compressor). For instance, the EEC can control the gas turbine engine to operate more or less aggressively based on the health status. As another example, a maintenance system can receive the health status and automatically schedule a service visit based at least in part on the outputted health status associated with the asset. Other control actions are contemplated; the examples provided above are not intended to be limiting.

<FIG> provides a flow diagram of an example method (<NUM>) of monitoring and diagnosing the health of an asset according to one example embodiment of the present subject matter according to an example embodiment of the present subject matter. The method (<NUM>) of <FIG> can be implemented using, for instance, the system <NUM> and/or components thereof described herein. <FIG> depicts actions performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that various actions disclosed herein can be modified in various ways without deviating from the scope of the present disclosure.

At (<NUM>), the method (<NUM>) includes receiving, by one or more processors of a system, continuous operating data associated with an asset, the continuous operating data including parameter values for one or more parameters over a collection time period. For instance, the asset can be a gas turbine engine, such as an aviation gas turbine engine. Accordingly, the continuous operating data can be continuous engine operating data, for example. The system can be an engine monitoring and health diagnostic system. The continuous operating data can be collected for a collection time period spanning from a start point to an endpoint, e.g., as shown in <FIG>. In this way, continuous operating data can be collected for an entire flight. In some instances, continuous operating data can be collected for a portion of a flight. The continuous operating data can be collected continuously during the collection time period. Values for various parameters associated with the engine can be sensed and recorded. For example, a recorder associated with the engine can record values for one or more parameters frame by frame, or stated differently, capture frame by capture frame. Values for parameters can be captured in each frame or at a time interval in different capture frames. <FIG> provides an example block diagram of continuous operating data. The system can receive the continuous operating data and can store the continuous operating data in a data store accessible by one or more processors of the system.

In some implementations, the method (<NUM>) includes determining, by the one or more processors, one or more values for additional parameters associated with the asset, the one or more values for the additional parameters being determined using the continuous operating data. For instance, as shown in <FIG>, the continuous operating data stored in COD data store <NUM> can be accessed and the one or more processors of the system <NUM> can execute the parameter calculation module <NUM> to determine one or more values for additional parameters using the continuous operating data. The parameter calculation module <NUM> can include computer-readable instructions and one or more physics-based models, for example. The one or more values for the additional parameters of the continuous operating data can be used to generate the synthetic snapshot data at (<NUM>).

At (<NUM>), the method (<NUM>) includes generating, by the one or more processors, synthetic snapshot data based at least in part on the continuous operating data, the synthetic snapshot data including one or more synthetic snapshots each containing the parameter values for the one or more parameters for a given timepoint within the collection time period. For instance, synthetic snapshots can be generated at the timepoints shown in <FIG>. Any suitable number of synthetic snapshots can be generated. The one or more processors can execute the synthetic snapshot generator module <NUM> (<FIG>) to generate the synthetic snapshots. By generating synthetic snapshots, the vast amount of data included in the continuous operating data can be broken down into manageable, easier to handle data points that can be used to monitor and diagnose the health of the asset (e.g., an aviation gas turbine engine) or components thereof. In some implementations, at least one of the one or more synthetic snapshots is created at a timepoint within a defined operation phase (e.g., a climb phase of a flight) of the collection time period that corresponds with a maximum or minimum value for a given parameter of the one or more parameters.

At (<NUM>), the method (<NUM>) includes receiving, by the one or more processors, snapshot data associated with the asset, the snapshot data including one or more snapshots each containing parameter values for the one or more parameters for a given timepoint during operation of the asset. Particularly, for each operation cycle of an asset, one or more sensors associated with the asset can capture a "snapshot" of the operating conditions at particular timepoints or timestamps during operation. Each captured snapshot can include values for various parameters, such as pressures, temperatures, speeds, etc. As one example, the snapshot data can include at least one snapshot in each predefined operating phase of the asset, e.g., at least one snapshot in each flight phase. In some implementations, one, some, or all of the snapshots can be captured during the collection time period in which COD is recorded. In other implementations, one, some, or all of the snapshots can be captured during a time period of operation of the asset that is not during the collection time period. Moreover, in some instances, all of the timepoints associated with the snapshots can be different from the timepoints associated with the synthetic snapshots. In other instances, however, one or more of the synthetic snapshots can correspond in time with one of the snapshots. In this way, a snapshot and a synthetic snapshot can contain parameter values for one or more parameters for the same timepoint. In this regard, in some implementations, the accuracy of the synthetic snapshot, or the synthetic snapshots in general, can be checked against the actual snapshot.

In some implementations, the method (<NUM>) includes creating, by the one or more processors, one or more new snapshots by applying a machine-learned model that utilizes one or more COD-snapshot transfer functions that correlate the one or more synthetic snapshots with historical snapshot data associated with the asset. For instance, as shown in <FIG>, the synthetic snapshot data including the generated synthetic snapshots can be fed or input into a machine-learned model that utilizes one or more COD-snapshot transfer functions that correlate the one or more synthetic snapshots with historical snapshot data associated with the asset. Particularly, the COD-snapshot transfer functions can utilize the values for the parameters of the synthetic snapshots and create new snapshots of data. The machine-learned model can be trained based at least in part on the historical snapshot data associated with the asset and fleet historical snapshot data associated with other assets that are a same model as the asset. Further, the method (<NUM>) can include adding, by the one or more processors, the one or more new snapshots to the snapshot data, wherein the one or more new snapshots are added to the snapshot data prior to the output indicating the health status of the asset or the one or more components thereof is generated.

At (<NUM>), the method (<NUM>) includes generating, by the one or more processors, an output indicating a health status of the asset or one or more components thereof based at least in part on the snapshot data and the synthetic snapshot data. Accordingly, the health status of the engine is generated using a snapshot-COD based approach. That is, the output indicating the health status is generated based on snapshot data and synthetic snapshot data, which is generated based on COD. Further, in implementations in which new snapshots are created based at least in part on the generated synthetic snapshot data, the output indicating the health status of the aviation gas turbine engine or one or more components thereof based at least in part on the one or more snapshots, new snapshots, and synthetic snapshots.

In some implementations, to ultimately generate the output, the method (<NUM>) includes applying, by the one or more processors, one or more time-series pattern recognition techniques to the snapshot data to determine at least one alert score associated with the snapshot data, the at least one alert score associated with the snapshot data being determined based at least in part on one or more detected features associated with the parameter values for the one or more parameters of the snapshot data. Further, the method (<NUM>) includes applying, by the one or more processors, one or more time-series pattern recognition techniques to the synthetic snapshot data to determine at least one alert score associated with the synthetic snapshot data, the at least one alert score associated with the synthetic snapshot data being determined based at least in part on one or more detected features associated with the parameter values for the one or more parameters of the synthetic snapshot data. In such implementations, the output indicating the health status of the asset or the one or more components thereof is generated based at least in part on the at least one alert score associated with the snapshot data and the at least one alert score associated with the synthetic snapshot data.

Moreover, in some implementations, the method (<NUM>) includes aggregating, by the one or more processors, the at least one alert score associated with the snapshot data and the at least one alert score associated with the synthetic snapshot data via a probabilistic aggregation technique into an aggregated alert score. In such implementations, the output indicating the health status of the asset or the one or more components thereof is generated based at least in part on the aggregated alert score.

In some implementations, the system (e.g., the system <NUM> of <FIG>) or a second system associated with the system can perform a control action based at least in part on the generated output indicating the health status of the asset or one or more components thereof. By way of example, an EEC of an engine can control the gas turbine engine based at least in part on the health status of the engine or a component of module thereof (e.g., a compressor). For instance, the EEC can control the gas turbine engine to operate more or less aggressively based on the health status. As another example, a maintenance system can receive the health status and automatically schedule a service visit based at least in part on the outputted health status associated with the asset.

The system and method disclosed herein provide a number of technical and commercial advantages and benefits. For instance, system and method disclosed herein can provide automated health assessments of an asset or one or more components of an asset, such as a compressor. Such automated assessments can be provided in or near real-time. Further, by using COD in conjunction with snapshot data, the health state of an asset or one or more components thereof can be improved compared to traditional methods and systems. Further, the output indicative of the health state can provide a basis for optimal asset utilization and planning engine removal/maintenance activities. Furthermore, the system and method disclosed herein provide a non-intrusive technique for determining a health state. Moreover, the system and method disclosed herein provide opportunity to identify asset specific maintenance needs in service and reduces UER and significant failure events while achieving asset mission and maximizing TOW. In addition, the system and method disclosed herein provide opportunity to modify asset usage to maximize asset in service value.

<FIG> provides a block diagram of an example computing system <NUM> that can be used to implement methods and systems described herein according to example embodiments of the present subject. The computing system <NUM> is one example of a suitable computing system for implementing the computing elements of the system <NUM> described herein.

As shown in <FIG>, the computing system <NUM> includes one more computing device(s) <NUM>. The one or more computing device(s) <NUM> can include one or more processor(s) <NUM> and one or more memory device(s) <NUM>. The one or more processor(s) <NUM> can include any suitable processing device, such as a microprocessor, microcontroller, integrated circuit, logic device, or other suitable processing device. The one or more memory device(s) <NUM> can include one or more computer-readable medium, including, but not limited to, non-transitory computer-readable medium or media, RAM, ROM, hard drives, flash drives, and other memory devices, such as one or more buffer devices.

The one or more memory device(s) <NUM> can store information accessible by the one or more processor(s) <NUM>, including computer-readable instructions <NUM> that can be executed by the one or more processor(s) <NUM>. The instructions <NUM> can be any set of instructions that, when executed by the one or more processor(s) <NUM>, cause the one or more processor(s) <NUM> to perform operations. The instructions <NUM> can be software written in any suitable programming language or can be implemented in hardware. The instructions <NUM> can be any of the computer-readable instructions noted herein. Each module noted herein can include associated computer-readable instructions.

The memory device(s) <NUM> can further store data <NUM> that can be accessed by the processor(s) <NUM>. For example, the data <NUM> can include received data, such as COD and snapshot data. The data <NUM> can include one or more table(s), function(s), algorithm(s), model(s), equation(s), etc. according to example embodiments of the present subject matter.

The one or more computing device(s) <NUM> can also include a communication interface <NUM> used to communicate, for example, with other components or systems, such as maintenance systems, aircraft systems, etc. The communication interface <NUM> can include any suitable components for interfacing with one or more network(s), including for example, transmitters, receivers, ports, controllers, antennas, or other suitable components.

It will be appreciated that the inherent flexibility of computer-based systems allows for a great variety of possible configurations, combinations, and divisions of tasks and functionality between and among components.

Although specific features of various embodiments may be shown in some drawings and not in others, this is for convenience only. In accordance with the principles of the present disclosure, any feature of a drawing may be referenced and/or claimed in combination with any feature of any other drawing.

Claim 1:
A system (<NUM>), comprising:
one or more memory devices (<NUM>); and
one or more processors (<NUM>), the one or more processors (<NUM>) configured to:
receive continuous operating data (COD) associated with an asset, the COD including parameter values for one or more parameters over a collection time period, the parameter values being captured at a first capture rate over the collection period;
generate synthetic snapshot data based at least in part on the COD, the synthetic snapshot data including one or more synthetic snapshots each containing the parameter values for the one or more parameters for a given timepoint within the collection time period;
receive snapshot data associated with the asset, the snapshot data including one or more snapshots each containing parameter values for the one or more parameters for a given timepoint during operation of the asset, the snapshots being captured based on a trigger condition at a second capture rate lower than the first capture rate;
apply one or more time-series pattern recognition techniques to the snapshot data to determine at least one alert score associated with the snapshot data, the at least one alert score associated with the snapshot data being determined based at least in part on one or more detected features associated with the parameter values for the one or more parameters of the snapshot data;
apply one or more time-series pattern recognition techniques to the synthetic snapshot data to determine at least one alert score associated with the synthetic snapshot data, the at least one alert score associated with the synthetic snapshot data being determined based at least in part on one or more detected features associated with the parameter values for the one or more parameters of the synthetic snapshot data; and
generate an output indicating a health status of the asset or one or more components thereof based at least in part on the at least one alert score associated with the snapshot data and the at least one alert score associated with the synthetic snapshot data;
wherein the asset is an aviation gas turbine engine.