Fleet-level failure prediction for improved vehicle maintenance

Abstract

The ground-based computing system receives performance parameter data for similar components located on similar aircraft and determines a corresponding degradation level and rate of change of degradation for each similar component. Vehicle-level degradation for the group of similar components is generated based on an analysis of the composite degradation of the similar components in each group. At least one of a remaining useful life (RUL) and a state of health (SOH) for each of the respective similar components is determined based on a comparison of the degradation level of each of the similar components with the vehicle-level degradation for the group of similar components. A predicted maintenance time for each of the similar components is determined based on the corresponding at least one of the RUL and SOH for the similar components, thereby enabling cost-effective maintenance of the components to be determined based on the vehicle-level information.

Description

[Technical Field]

[0001] Cross-reference of related applications This patent application is a continuation-in-part application of U.S. Patent Application No. 16 / 801,596, filed on 26 February 2020, entitled “PROGNOSTICS FOR IMPROVED MAINTENANCE OF VEHICLES,” which is a continuation-in-part application of U.S. Patent Application No. 16 / 583,678, filed on 26 September 2019, entitled “HIGH FREQUENCY SENSOR DATA ANALYSIS AND INTEGRATION WITH LOW FREQUENCY SENSOR DATA USED FOR PARAMETRIC DATA MODELING FOR MODEL BASED REASONERS,” which is a continuation-in-part application of U.S. Patent Application No. 16 / 163,726, filed on 18 October 2018, the entire contents of which are incorporated herein by reference.

[0002] Embodiments of the present invention generally relate to determining when maintenance is required for components of complex vehicles, such as aircraft. Furthermore, embodiments identify whether maintenance is required for similar components of all similar aircraft based on an analysis of vehicle-level data associated with such components, and generate a dynamic and cost-effective "predictive maintenance" schedule that is feasible for certified maintenance technicians based on the condition of the components, as opposed to conventional, costly, and labor-intensive "scheduled maintenance" based on fixed time intervals. [Background technology]

[0003] Maintenance of complex systems such as vehicles, aircraft, spacecraft, and other systems incurs significant operational costs. Maintenance of such systems is typically performed on a predetermined schedule (based on cyclical time) for the various components of the system. The schedule may be simply time-based, e.g., every three months, or it may be based on a combination of time, usage, and reliability metrics, e.g., every three months or every 1000 hours of operation, determined by a Mean Time Between Failures (MTBF) component reliability calculation. Time and usage are typically based on the performance history of the same or similar components used in similar operating environments. Such fully reliability-metric-based scheduled maintenance has been shown to be suboptimal for many commercial and Department of Defense systems. The Office of the Secretary of Defense (OSD) has issued Directive 4151.22 (Mandate), mandating that all systems follow a Condition-Based Maintenance Plus (CBM+) process by 2032. The CBM+ process provides maintenance scheduled based on the condition of the components and no longer provides predetermined time-based and usage-based maintenance. However, compliance with CBM+ requirements presents significant challenges.

[0004] Such predetermined scheduled maintenance of components has been satisfactory in some environments, but this type of maintenance has not worked well for some equipment / vehicles in other environments. Predetermined scheduled maintenance has been found to be a cause of delays in vehicle availability due to unnecessary maintenance, which is costly and can lead to accidental accidents by removing parts for testing and replacing them. Consider, for example, a jet aircraft. The same type of jet aircraft can be used in a variety of very different environmental conditions, e.g., deserts with widely changing temperatures and blowing sand, versus temperate regions with only a small amount of airborne dust. Furthermore, even when the same aircraft operates under the same external environmental conditions, different pilots, especially military pilots, may choose to fly the same aircraft in substantially different ways, causing different load variations to the aircraft structure. Also, different missions will bring different levels of stress to the aircraft's components. Thus, predetermined scheduled maintenance of components may result in not performing necessary maintenance because the stress is greater than expected, or in performing unnecessary maintenance because the stress level is significantly lower than expected. Reliable failure prediction to improve the timing of maintenance on vehicle components provides a more cost-effective solution, avoids unnecessary maintenance, increases the operational uptime of the aircraft / system, and better utilizes maintenance personnel. Performing maintenance only when actually needed is even more crucial when multiple similar aircraft must be maintained. Therefore, more accurate prediction of maintenance for components within similar types of aircraft is needed, enabling improved onboard testing criteria for components and simultaneous maintenance decisions across the entire vehicle for similar components, by utilizing component performance metrics across multiple similar aircraft for the same components. [Overview of the Initiative] [Problems that the invention aims to solve]

[0005] One objective of one embodiment of the present invention is to update the on-board component model with higher accuracy to meet the need for providing highly reliable fault prediction based on the incorporation of vehicle-level metrics of corresponding component performance across multiple similar aircraft.

[0006] Another objective of one embodiment of the present invention is to identify whether maintenance of the same components arranged in all similar aircraft is necessary based on the analysis of vehicle-level data associated with such components. A ground-based computing system receives data on performance parameters of similar components arranged in similar aircraft and determines the corresponding degradation levels and rates of change of degradation for each of the similar components. The vehicle-level degradation of groups of similar components is generated based on the analysis of the combined degradation of the similar components in each group. At least one of the remaining useful life (RUL) and the state of health (SOH) of each of the similar components is determined based on the comparison of the degradation level of each of the similar components with the vehicle-level degradation of the group of similar components. The predicted maintenance time for each of the similar components is determined based on at least one corresponding one of the RUL and SOH of the similar components, thereby enabling the determination of cost-effective maintenance of components based on vehicle-level information.

Means for Solving the Problems

[0007] Some exemplary embodiments of the present invention incorporate inputs from the IVHM system and the data fusion module described below with reference to the accompanying drawings for a better understanding of the operation of the embodiments of the present invention.

Brief Description of the Drawings

[0008] [Figure 1] A block diagram of an on-board operational IVHM system and its interface for diagnostic analysis of equipment failures in an aircraft is shown. [Figure 2]This shows a block diagram of the design, operation, and maintenance processes and interfaces of the IVHM system. [Figure 3] This shows a subsystem model for use with the IVHM system. [Figure 3A] Figure 3 shows a diagram representing the components of the model. [Figure 4] Figure 3 shows a diagram representing the functional nodes in the model. [Figure 5] Figure 3 shows a diagram representing the sensor nodes in the model. [Figure 6] Figure 3 shows a diagram representing the calibrated boundary sensor nodes in the model. [Figure 7] This diagram shows the data mapping to the sensor nodes. [Figure 8] This diagram shows the mechanism for testing models intended for use in IVHM systems. [Figure 9] An example of a disability analysis report is shown below. [Figure 10] An example of a false alarm report is shown below. [Figure 11] This is a block diagram of one embodiment of a data message interface in which high-frequency sensor data and low-frequency sensor data are processed and integrated. [Figure 12] Figure 11 is a block diagram of one embodiment of an anomaly detector and degradation detector. [Figure 13] Figure 11 is a block diagram of one embodiment of the data fusion module shown. [Figure 14] This paper presents exemplary high-frequency sensor data from vibration sensors in motor bearings of centrifugal pumps, showing representative sensor data for both normal and defective pump bearings. [Figure 15] This paper presents exemplary high-frequency sensor data from vibration sensors in motor bearings of centrifugal pumps, showing representative sensor data for both normal and defective pump bearings. [Figure 16]Exemplary high-frequency sensor data from sensors monitoring power to a centrifugal pump, corresponding to the power associated with good and bad bearings, respectively, is shown. [Figure 17] Exemplary high-frequency sensor data from sensors monitoring power to a centrifugal pump, corresponding to the power associated with good and bad bearings, respectively, is shown. [Figure 18] This is an illustrative graph showing high-frequency sensor signals used for dynamic anomaly detection and the derived average of the sensor signals. [Figure 19] This is an illustrative graph showing high-frequency sensor signals used for dynamic anomaly detection and the derived average of the sensor signals. [Figure 20] This is an illustrative graph showing high-frequency sensor signals used for dynamic anomaly detection and the derived average of the sensor signals. [Figure 21] This is an illustrative graph showing high-frequency sensor signals used for dynamic anomaly detection and the derived average of the sensor signals. [Figure 22] This is an illustrative graph of a high-frequency sensor signal with a derived mathematical function, which is also used in dynamic anomaly recognition. [Figure 23] Figure 12 is a flowchart of an exemplary process that can be used to implement the anomaly / degradation detector. [Figure 24] Figure 13 is a flowchart illustrating an example of a process that can be used to perform data fusion. [Figure 25] This is a block diagram of an exemplary computing system for performing high-frequency sensor analysis and integration with low-frequency sensor data. [Figure 26] This is a block diagram of an exemplary failure prediction system for determining the need for component-level maintenance based on the state of the components. [Figure 27] This is a block diagram of an exemplary hybrid system with different models that characterize the behavior and parameters of each component. [Figure 28] This shows service quality metrics at the component level. [Figure 29]This shows an example of the degradation of bearing performance and power distribution performance of a brine pump. [Figure 30] This graph shows an example of the change in the slope of brine pump performance, which is used to determine the remaining service life. [Figure 31] This diagram shows the components of a brine pump monitored in an exemplary physical system model of a brine pump. [Figure 32] An example flowchart for particle filter determination and end-of-life prediction is shown. [Figure 33] An example flowchart for particle filter determination and end-of-life prediction is shown. [Figure 34] Figure 27 is a block diagram showing a more detailed exemplary embodiment of the two-stage Kalman filter. [Figure 35] This is a flowchart illustrating an exemplary process for a two-stage Kalman filter. [Figure 36] A block diagram of an exemplary vehicle-level failure prediction system is shown, which uses collected vehicle-level data to provide improved component maintenance metrics based on vehicle-level data. [Figure 37] A block diagram of an exemplary vehicle-level failure prediction system is shown, which uses collected vehicle-level data to provide improved component maintenance metrics based on vehicle-level data. [Figure 38] Figure 37 is a block diagram of the analysis fusion module. [Figure 39A] This flowchart illustrates the process of improving the accuracy of models and algorithms used for both onboard component performance evaluation and vehicle-level component performance evaluation. [Figure 39B] This flowchart illustrates the process of improving the accuracy of models and algorithms used for both onboard component performance evaluation and vehicle-level component performance evaluation. [Figure 40]This flowchart illustrates the process of determining when all similar components in an aircraft vehicle require simultaneous maintenance based on vehicle-level performance metrics and a generated predictive maintenance schedule. [Figure 41] This block diagram shows the design, training, and improvement of onboard and vehicle-level fault prediction systems. [Figure 42] This shows a graphical user interface (GUI) for selecting reports and metrics generated by a vehicle-level fault prediction system for a single aircraft, a subset of aircraft within a vehicle, or the entire vehicle. [Figure 43] This chart shows a predicted maintenance schedule for an exemplary component compared to maintenance scheduled on a time interval basis. [Figure 44] This shows a GUI for controlling a ground-based vehicle failure prediction system. [Figure 45] This is a flowchart for determining the State of Health (SOH) indicator of an example structural component. [Figure 46A] This is a graph showing the maintenance characteristics of the components versus time. [Figure 46B] This is a graph showing the maintenance characteristics of the components versus time. [Figure 47] This chart shows the relationship between repeated loading, stress, and crack propagation in structural materials. [Figure 48] This chart illustrates the interrelationships between fault management, various maintenance methods, and actions. [Modes for carrying out the invention]

[0009] Embodiments of vehicle-level failure prediction benefit from the descriptions of embodiments and features associated with other inventions, such as those described in relation to Figures 1 to 35. Embodiments of vehicle-level failure prediction are described in relation to Figures 36 to 48.

[0010] In one embodiment, the fault prediction system utilizes inputs from the data fusion module 1175 and the MBR diagnostic engine 106. The IVHM system includes all the modules in Figure 11, the MBR diagnostic system, and the current subject fault prediction system, and its description begins with a reference to the text associated with Figure 26, which follows the descriptions of the MBR diagnostic engine and the data fusion module.

[0011] IVHM, which utilizes Model-Driven Architecture (MDA) and Model-Based Engineering (MBE), is a solution that certifies software and hardware elements all at once, rather than flight-certifying them each time the system changes or is upgraded. This results in significant cost savings by using XML-formatted configuration files containing models that possess the system's diagnostic domain knowledge. While the models need to be validated for accuracy, they do not require expensive and time-consuming software flight certification. This reduces military operational and support costs by 25% to 35%.

[0012] Figure 1 shows the functional behavior and interface of the IVHM (Integrated Vehicle Health Management) system 10 of the aircraft 12, where the MBR (Model-Based Inference) engine 14 operates on a computing device (not shown) in the aircraft 12's avionics bay. The aircraft is shown and described with reference to Figure 1, but the embodiment is not limited to this type of vehicle. Observed behavior 16 refers to BIT (Built-in Test), parametric, analog, and discrete sensor data obtained from various aircraft avionics data buses. Expected behavior 18 refers to what is expected from modeled domain knowledge 20 of various subsystems, line-replaceable units (LRUs), and system-wide components (this model is represented in XML format). Components refer to subsystems, LRUs, and parts. If the observed behavior 16 differs from the expected behavior 18, an abnormal behavior (mismatch / residual) is registered, and the MBR engine 14 enters diagnostic mode (causal analysis). Through various inference algorithms and analysis of BIT, parametric, and sensor data, the MBR engine 14 generates results 22 including detection of faulty components, isolation of a single faulty component or similar components into ambiguity groups, false alarm identification, functional evaluation of the faulty component (i.e., leaks in the pump, leaks in the pipes, airflow obstruction, bearing damage, and other physically dependent evaluations of the component), and unknown anomalies. In the case of unknown anomalies, the model 20 is refined with additional information about the component and its interaction with other components related to its failure mode. This information is obtained from the manufacturers of these components, and additional failure modes are added to the existing model. To reduce ambiguity groups of similar elements in a chain (series or parallel), additional sensors are typically required to isolate specific components within the ambiguity group. If additional sensors cannot be applied due to size, weight, and power limitations, the maintenance manager must perform off-board diagnostic analysis within the local ambiguity group.

[0013] Figure 2 shows a block diagram of the IVHM system 100. The various components in Figure 2 are linked to each other to logically combine interconnected functions, failure modes, failure probabilities, and functional evaluations in the modeled system, and are also linked to design sources (114, 116, 118, 120), real-time or post-processing input data delivered to the pilot's display (obtained from the operational flight program 102), ground systems (obtained from OFP 102), and storage on disk (126) for the maintenance manager's ground maintenance actions 122. For illustrative purposes, the IVHM system 100 is represented as a block diagram, but the functions and methods described may be logically combined in hardware components in various ways.

[0014] The Operational Flight Program (OFP) 102 includes hardware and software for managing the overall operation of the vehicle. OFP 102 includes a runtime diagnostic engine IVHMExec 104. OFP 102 may also be implemented as a standalone avionics IVHM computer that is passively mounted on the avionics data bus, actively interfaced with the mission planning system, and actively interfaced with the ground systems and maintenance system 122. IVHMExec 104 includes a diagnostic model-based inference (MBR) engine 106. The MBR engine 106 combines a physical model of a vehicle system or subsystem with input data describing the system state, and then performs deterministic inference to determine whether the system is functioning correctly or whether a system anomaly exists, and if a system anomaly exists, isolates and identifies the location and type of any faults and false alarms present. IVHMExec 104 writes maintenance records to a disk 126, which can also be accessed by a portable maintenance device viewer 122.

[0015] The MBR engine 106 receives real-time sensor data via a data message interface 108, where high-frequency and low-frequency sensor data are analyzed and integrated together to facilitate decision-making by the MBR engine 106. The MBR engine 106 also receives a vehicle runtime operation model 110 via a real-time operation interface 112. The vehicle model 110 is created by a modeling engineer using a model development graphical user interface (GUI) 114. The model 110 is created and validated offline (non-real-time) using the MBR engine 106 and then exported to an XML file used by the real-time embedded build of IVHMExec 104. In addition to creating the model 110, the GUI 114 is also used to validate the model. Validation and validation is a test of the model's internal logic and elements without using specific input data. This process is necessary to ensure that the model is logically consistent and free from errors that would cause the model to malfunction or not function at all.

[0016] As a further step in the model development process, the test manager 116 evaluates the model by testing it against simulated flight data 118 or actual flight data 118. The development interface 120 allows for modification and addition of the MBR engine 106 algorithm, which is a separate class linked statically or dynamically (statically for standalone IVHMExec, and dynamically for integration with a graphical user interface (GUI)) to the IVHMExec 104 runtime executable file. While verification logically tests the model, the test manager 116 ensures that the model performance and output are as desired. Once the model is verified and tested, an XML model configuration file 110 is generated.

[0017] IVHMExec 104 is an execution unit that runs the MBR engine 106 in real time by loading an XML representation of the model and applying the model to input sensor data messages received from various buses within the vehicle and / or stored historical data in various formats for playback on the ground. IVHMExec 104 may also be used by the test manager 116 via the development interface 120. The storage interface 124 connects the MBR engine 106 to the recording data storage 126. The recording data 126 includes log files, complete timestamped states of the equipment, e.g., snapshots, timestamped fault / fault anomalies, detection, isolation, and any functional evaluations for isolation. The log files also include the MBR engine software status (version number, fault and restart), identification of other aircraft software, their version numbers, state at the time of failure in case of failure, software restart, and functional evaluations leading to the failure. The collection of this data enables the playback of diagnostic visualizations of actual events that occurred on the aircraft, allowing maintenance managers to better understand the interactions of both hardware and software leading to the failed component. The recording data storage 126 stores the raw data used by the MBR engine 106 and the results of its processing.

[0018] In one embodiment, the MBR engine 106 includes dynamically calibrated data input capability and a set of logic gates (such as intersection AND, union OR, exclusive OR XOR), rules, instances (history), and decision trees combined within the sensor logic for IVHM data fusion of parameterized direct analog sensor data and corresponding built-in test (BIT) inputs. The comparison of parametric data, direct analog sensor data, and BIT results provides a measure of reliability in fault and false alarm prediction.

[0019] Here, an example of creating a model used by the MBR engine 106 is described. In one embodiment, the model provides data fusion from many sources within the modeled vehicle. In particular, the model may include parameterized data input capability, enabling the MBR engine 106 to include analog data inputs and quantified digital data inputs, having fixed or dynamically calibrated boundaries for measured physical quantities to determine the presence of anomalies. Parameterized data anomaly determination can be based on simple fixed boundaries, dynamically changing calibration values ​​based on physical sensor behavior, or more complex determination properties including signal noise reduction, windowing, latency, and similar parameterized data adjustments. These data calibration parameters and thresholds become sensor node properties for evaluation during real-time operation of the system. Functions can be represented as logical sets and operands, and rules may be represented as logical sets, natural language semantics, historical behavior (case-based), or decision trees (failure tree analysis). For example, in the case of a pressure function, the model evaluates whether flow pressure is provided and combines other inputs according to the desired function logic. In one embodiment, each input must show a positive result for the function to evaluate as true, but other logical functions may also be used. Various user-defined parameters of this function can be represented as node properties of the function. The binary IVHMExec 104 real-time engine, running on one of the vehicles or on the XML MBR Model 110 and avionics computing device, provides the IVHM capabilities / functions for the entire vehicle.

[0020] Parametric and BIT MBR models may include components and sensors associated with their functions. In one embodiment, a model of a vehicle system or subsystem may be represented as nodes in a graph, as shown in Figure 3. In particular, Figure 3 shows an example of an environmental control subsystem (ECS) that includes both diagnostic and non-diagnostic nodes, as represented using the model development GUI 114 of Figure 2. For illustrative purposes, a specific example is described, but the principles described herein may be applied to any subsystem or system of a vehicle. A modeling engineer interacts with the model in Figure 3 via the GUI 114 of Figure 2.

[0021] Diagnostic nodes are used directly by the MBR model inference engine to determine system components causing faults or false alarms, while non-diagnostic nodes are used for tasks such as comparing sensor outputs and BIT test results. Non-diagnostic nodes are used for real-time comparison of parametric sensor data and BIT data results. Parametric sensors represent the true system behavior (when the sensor is not faulty), and if the sensor is nominally operating when the BIT data indicates a failure of the corresponding component, this result is indicated as a false alarm. Faulty sensors are identified from false positive and false negative tests of the sensor. Components such as flow pressure components refer to specific system elements whose state (e.g., on, off, high pressure or low pressure, etc.) and status (operable, faulty, leaking, etc.) are indicated by the MBR engine 106 by connecting the component to other elements of the model. Sensor nodes are modeled with input data that can take many forms, such as direct sensor analog inputs, parametric data inputs, and binary BIT data inputs. Referring to Figure 3, a typical component node is shown as the ECS flow pressure sensor node 202. Other component nodes include ECS Flow 204, ECS Cooling 206, and ECS Ready 208.

[0022] Figure 3A shows the various user-defined parameters of node 202, which can be viewed by the modeling engineer by double-clicking the function node icon, displaying the window shown in Figure 3A for node 202 (circular). The parameters defined in the node properties include the node class 301, default parameter values ​​303, and data items 305 that define the capabilities, outputs, and status data types of node 202. Certain labels and features are shown in Figure 3A, but these may be changed depending on the function being modeled and the design of the modeled vehicle.

[0023] The default parameter values ​​303 and 311 indicate the failure probability (failure mode) input from the component supplier, with "0" indicating no available supplier data. Alternatively, the failure probability can be input from historical performance data. This can be recalculated by degradation events, i.e., the failure probability increases with degradation events. The intermittency threshold 313 refers to a time period of intermittent or random behavior, with an exemplary default value of 5 seconds. The state 315 defines various states of the component, such as on, off, high voltage, etc. The available and in-use parameters 317 are both shown as set to "true," i.e., the component is both available and in use. A "false" state in either parameter 317 may be due to failure and / or other reasons such as power loss, and the link specification 319 specifies a link to other components by the functional node.

[0024] Another type of node in the model in Figure 3 is the function node. A typical function node is shown as the Provide Flow Pressure node 210. Other function nodes include Provide Flow 212, Provide Cooling 214, and Provide ECS Ready 216. Each function node in Figure 3 represents a basic AND function. Provide Flow Pressure 210 is used, for example, to determine whether flow pressure is provided (logical set and logical operand) and combines with other inputs according to the desired function logic. In this example, each input must show a positive result for the resulting function state to be true. Various user-defined parameters of function node 210 can be viewed by the modeling engineer by double-clicking the function node icon, which displays the window for function node 210 (ellipse) shown in Figure 4. The parameters defined in the node properties include the node class 302, default parameter values ​​304, and data items 306 that define the capabilities, outputs, and status data types of node 210. Certain labels and features are shown in Figure 4, but these can be changed depending on the function being modeled and the design of the modeled vehicle.

[0025] Another type of node in the model in Figure 3 is the physical sensor node. A typical physical sensor node is shown in Figure 3 as the ECS_FlowPressure node 218 (trapezoid). Another physical sensor node is shown as the ECS_Temperature node 238. Physical and virtual nodes are used in the model to represent input data, which can take many forms. As mentioned above, the modeling engineer interacts with the model in Figure 3 via GUI 114. Various user-defined parameters for the physical sensor node 218 can be viewed by the modeling engineer by double-clicking the node icon, which displays the window for the physical sensor node 218 shown in Figure 5. In the case of the sensor node 218, the parameterized input data is used along with fixed upper and lower limits (tolerance thresholds) defined as default in the node properties window shown in Figure 5. The use of parameterized data allows for direct analysis of quantified sensor values ​​listed in the sensor node properties as raw values ​​402, as seen in Figure 5. In this case, sensor raw values ​​402 include the measured flow pressure of the ECS subsystem. If the raw value 402 falls below the lower limit 404 or exceeds the upper limit 406, the sensor indicates an anomaly, which is then used by the MBR engine 106 (Figure 2) along with the rest of the model to determine the nature and cause of the anomaly (Causal Analysis Figure 2).

[0026] Another example of a physical sensor node is the BIT ECS_Flow Pressure Fault 220. This sensor uses built-in test (BIT) data from the modeled system, which indicates either abnormal or normal operation in the data output. This BIT test is designed to use the same upper and lower limits as the corresponding parameterized sensor, but may produce different results in the case of abnormal operation. Therefore, the BIT test is used as input along with a separate parameterized data input to the XOR_ECS_Flow Pressure node 222, which is an exclusive OR (XOR) sensor node. In some cases, only the BIT test sensor may be available to the maintenance administrator. In this case, the BIT test is used as a diagnostic sensor similar to the parametric sensor node used here for ECS Flow Pressure 218. Other physical sensor nodes in the model in Figure 3 include the BIT_ECS_Not Ready node 240 and the BIT_ECS_Temporary Fault node 242.

[0027] The XOR_ECS_flowpressure node 222 receives inputs from the physical sensor node BIT_ECS_flowpressure_fault 220 and the parameterized input sensor node ECS_flowpressure_ND 228 (non-diagnostic). The reason a separate parameterized input sensor is used for the XOR input is that this input is for non-diagnostic purposes (no diagnostic cycle is performed). Sensors can be either diagnostic, meaning they are used by the MBR engine to determine system faults and false alarms, or non-diagnostic, meaning they are removed from MBR engine evaluation. In the case of XOR sensor inputs, the non-diagnostic parametric sensor input 228 is preferable to avoid interference with the MBR engine, as the XOR logic and output are complementary and isolated from MBR engine processing. In the example used here, the BIT test sensor 220 is also non-diagnostic for the same reason. Furthermore, in the case of XOR sensors, a blank function 226 is used to satisfy the design requirement that each sensor has a downstream function attached to it. Another blank function is shown in 236. Similarly, for node 222, XOR_ECS_temporary_node 244 receives input from the physical sensor node BIT_ECS_temporary_fault 242 and the parameterized sensor node ECS_temperature_ND 224.

[0028] The XOR_ECS_flow pressure node 222 generates a separate output stream and shows a positive Boolean result only if the connected sensors (parameterized sensor node 228 and the corresponding BIT test node 220) provide different evaluations. Under normal operating conditions, this should not happen, so the XOR sensor node is useful for determining when one of the system's BIT or parameterized inputs is providing an abnormal result. This provides the modeler with another tool for diagnosing the health of the system, which may otherwise be difficult to analyze.

[0029] An example of a case where only the BIT test data field is available is shown in Figure 3 as the BIT_ECS_flow status flag fault node 230, which provides sensor input to the providing flow node 212. In this case, the BIT test node 230 is for diagnostic purposes and is used directly by the MBR engine. Other model element types seen in Figure 3 include comments that describe the function of the model, shown as, for example, 232, and output icons 234 that allow model elements outside of the model elements shown in the submodels shown in Figure 3 (i.e., Outside submodel: "Output to LTA") to communicate with the submodel, specifically the providing cooling function node 214.

[0030] In some cases, parametric nodes do not have fixed upper and lower limits. In this case, a separate node class can be used, for example, as shown in Figure 6. This node is not part of the subsystem model in Figure 3. Here, a second input is used that provides a calibration value (e.g., calibration voltage) that may change over time. The measured value must then fall within a percentage range defined by Calibration_minus_percent 502 and Calibration_plus_percent 504 (generally determined from subsystem supplier information) around the calibration value. This type of sensor node can be used instead of boundary_sensor_cfg class nodes, such as the ECS flow pressure node 218 in Figures 3 and 5, if known calibration values ​​exist for the limits of the parameterized sensor.

[0031] In one embodiment, a model like the one shown in Figure 3 includes a list of data fields corresponding to each element of the model. For example, as shown in Figure 7, the value of ECS_Temperature(C)602 is mapped to the diagnostic ECS_Temperature Sensor node 604 and the non-diagnostic ECS_Temperature Sensor node 606 within the ECS submodule. These are labels for the data columns in the file format used as data input for this model, allowing all data fields for various sensors within each subsystem to be systematically defined in a single file. A separate data item is mapped to the BIT test data node, and a calibration data item is mapped to the calibrated sensor node. The raw value data item selection in the drop-down menu 608 indicates that this exemplary data item is a raw measurement from the ECS temperature sensor. Each sensor in the model (parametric or BIT) is mapped to a data item, along with any calibration value dataset for the calibrated parametric sensor.

[0032] Referring back to Figure 2, after the IVHM MBR model is built using the model development GUI 114 (with all sensors, components, and functions in place to emulate the operation of each subsystem), there are two ways to run the model using actual or simulated system data. As mentioned above, GUI 114 includes a direct method of running the MBR model using flight data 118 recorded using the test manager 116. Figure 8 shows a typical test manager window with a new test popup window 702. When a flight replay test 704 is selected, the appropriate test simulated data or actual flight data file can be selected from option 706 and loaded into the test manager 116 in Figure 2. After the model is tested using the data file, an output file is generated and can be viewed along with the analyzed diagnostic results stored after being written as a maintenance record (i.e., maintenance record storage 126 in Figure 2). Other test cases with existing flight data may already be selected from those shown in 708. The specific test shown in Figure 9 is just a representative example, and many other tests may be used.

[0033] In an alternative embodiment, a modeling engineer using GUI 114 (Figure 2) may test the model using the command-line standalone version of IVHMExec 104 (Figure 2). For this procedure, an XML (Extensible Markup Language) file containing information about the model and data mapping is generated (i.e., a complete version of Figure 8 from a different GUI screen not shown). <aps>>(APS.vmdl) Model 706). This file can be executed using the command-line standalone version of IVHMExec 104 to generate an output file in a designated storage location that can be loaded into the PMD Data Viewer 122 (Figure 2). The result should be identical to that generated by the Test Manager 116 (Figure 2) for the same flight data, but the command-line procedure allows for batch file processing of large datasets and varying numbers of system MBR models.

[0034] An example of model test output data is shown in Figure 10 (PMD Viewer 122 Figure 2). The MBR engine 106 (Figure 2) isolates failures in the ECS cooling components using both faults in the parameterized ECS temperature sensor, represented as the ECS_temperature node 238, and supporting data in other subsystem components, including other temperature sensors (in some of these cases, e.g., for the LTA laser amplifier driver temperature (not shown), the only available data is from BIT tests, and therefore a BIT test node is used to support this case). The logic of the interconnected subsystem submodels, as shown similarly in Figures 2 and 10, indicates this result when the parameterized sensor ECS_temperature node 238, which measures the ECS temperature, is determined to be an anomaly with appropriate supporting data (from other sensors within the subsystem or external sensors from other subsystem models). Furthermore, the BIT test BIT.ECS_temporary failure node 242, which measures the ECS temperature anomaly, indicates the failure separately. This sensor node is non-diagnostic and therefore not used to determine system failures, but it is used as a comparator for the non-diagnostic ECS_temperature_ND parametric sensor node 224. The variation between the BIT node and the parametric node can indicate a fault BIT test or sensor, and this is one of the capabilities added by implementing a parameterized sensor.

[0035] Figure 10 shows an example of the output of the MBR engine 106 that generates a false alarm. In this case, the power distribution unit (PDU) P5V sensor 802, a parametric sensor that measures voltage within the system's PDU submodel, is generating an anomaly because the data input for this subsystem is outside the defined parametric range. The parametric sensor node implementation allows for the direct use of this sensor data, avoiding potentially cumbersome hardware BIT test results. The parameterized node also allows for direct analysis of quantitative data for calculating reliability measures, windowing of data for false data points, and similar analyses. In this submodel, a comparator analysis is performed using the XOR_PDU_P5 node 804 between the parametric node PDU_P5_ND 806 and BIT test data from BIT_PDU_P5_Voltage Fault 808 to determine if there is any discrepancy between these two results indicating a sensor or BIT test failure. In the following example, the anomaly is determined to be a false alarm because other subsystems would expect a similar anomaly in the case of an actual system hardware failure. Since no other such anomalies exist, the MBR engine 106 can determine that this anomaly is a false alarm (the result listed in the upper right box in Figure 10). The other lines shown below this box and above the graphic are timestamps supporting the result in Figure 10.

[0036] The central objective of the present invention is to generate high-fidelity real-time diagnostic capabilities for vehicles and other systems (false alarm (FA) rejection, fault detection (FD), fault isolation (FI), and parameter trends of equipment failure), but is particularly suitable for aircraft (but not limited thereto). The present invention provides embedded software diagnostic capabilities on numerous hardware devices and operating systems, as well as system avionics integration for determining system health during real-time system operation in flight. By implementing parametric data input from high-frequency and low-frequency sensors and XOR parameter-BIT comparator fusion, the system has the ability to analyze quantitative sensor inputs, develop advanced fault reliability measures and false alarm reliability measures, and identify and analyze BIT failures while maintaining effective system health management and diagnostic capabilities.

[0037] Figure 11 is a block diagram of an embodiment 1100 of the data message interface 108 (Figure 2) in which both high-frequency and low-frequency sensor data are processed and integrated together. The dashed line 1105 separates the high-frequency sensor data processing components shown above line 1105 from the low-frequency sensor data processing components shown below the line. Low-frequency sensor data processing represents a conventional method. Low-frequency sensors 1110 provide relatively low data rate outputs and can be associated with sensors such as pressure, temperature, volume, flow, voltage, and current. Such sensor outputs are typically associated with analog voltages that are converted into digital signals by an analog-to-digital converter (A / D) 1115. Of course, if the sensor provides a digital output directly, the digital output does not need to be processed by the A / D converter 1115.

[0038] The digital signal representation of the sensor output is supplied as input to an alarm detector 1120, which functions to determine whether or not an alarm condition exists. Such determination is based on a comparison of whether the digital value of the sensor output falls within a fixed window of values ​​defined by static, stored upper and lower thresholds associated with each respective sensor. Such a comparison can be performed by a microprocessor comparing the sensor value to the corresponding threshold, or by a dedicated circuit, such as an integrated circuit comparator. If the sensor output value falls within the respective window, the function of the parameter of the sensed component is determined to be within acceptable limits, i.e., not an alarm condition. If the sensor output value falls outside the respective window, the function of the parameter is determined to be outside acceptable limits, i.e., an alarm is required. If the sensor window is relatively wide (the low and high thresholds are far apart), extreme or abnormal operating conditions may cause the sensed parameter to exceed such a window, thereby generating an alarm. This corresponds to a false positive. A wide window allows most signals, especially noisy signals, to register as alarms while the system is functioning properly. This is generally the case in pre-flight tests where the components and sensors have achieved a normal steady state. The internal steady-state time can be up to 30 minutes for certain systems, such as radar. Once a steady state is achieved, false alarms are significantly reduced. Current methods require a long schedule and budget to achieve an understanding of the remaining false alarms as well as the acceptable static lower and upper thresholds for each sensor. With the implementation of the MBR engine, this effort and budget are reduced by 90% in just two test flights. True false alarms are easily identified, allowing for addressing the real failure for maintenance (repair or replacement). Persistent false positives (exceeding the upper threshold) indicate that the corresponding sensor has failed. A zero sensor raw value represents an electrical short circuit within the sensor.To minimize false alarms, if the sensor window is set relatively narrow (low and high thresholds close together) to accommodate sensor outputs corresponding to extreme or abnormal operating conditions, there is a risk that the sensed parameter may be operating with unacceptable characteristics that are not judged as abnormal / alarm conditions because the sensor output is outside the narrow window. This corresponds to a false negative. A false negative indicates that a possible actual anomaly missed alarm registration and tagging, which would otherwise have been processed in the detection cycle for causal analysis. Therefore, there is a challenge in establishing a window with fixed upper and lower thresholds.

[0039] The output from the alarm detector 1120 consists of input digital sensor values, each with a digital tag indicating whether an alarm is present or absent. This provides input to the data regulator 1125, which provides data formatting and alignment. Since digital outputs from different sensors may have different numbers of digits or values ​​with different encoding methods, the data format converts these values ​​into a standardized data representation and format (i.e., floating-point, integer, binary bit, etc.), as well as data digit padding as needed. Also, since the sensor data rate (frequency) is typically different for each of the different sensors, converting each sensor data stream to a data stream having a common data rate, e.g., 50 Hz, makes it easier to integrate and process information from such various sensors and data branches. The data regulator 1125 can be implemented on a microprocessor capable of formatting to provide conformity of the representation of sensor values, and can utilize a common clock to establish a time-synchronized signal to a single common data rate for each digital sensor output, which may require either upsampling or downsampling of each sensor data stream to convert to a target common data rate, e.g., 50 Hz.

[0040] Other data 1130 represents other information obtained from sensors or monitoring, such as hardware and software BITs, system fault codes, warnings, cautions, advisories, weather, and biological (vehicle operator, e.g., pilot's heart rate) data. Signals associated with this information are further processed by the A / D converter 1135, alarm detector 1140, and data adjustment 1145, which perform functions similar to those described above for the corresponding A / D converter 1115, alarm detector 1120, and data adjustment 1125, respectively.

[0041] The high-frequency sensor 1150 provides high data-rate analog information and can include, for example, sensors such as stress gauges, strain gauges, accelerometers, vibration sensors, transducers, torque gauges, acoustic sensors, and optical sensors. Such sensor outputs are converted to digital signal representations by the A / D converter 1155 and input to the anomaly / degradation detector 1160 (see Figure 12 and text for a more detailed explanation), which performs the function of determining whether each sensor data stream represents an anomaly and / or degradation state. If it is determined that one or both of these conditions exist for a sensor value, the corresponding digital sensor data is output to output 1162 with an embedded flag display containing real-time sensor information at a downsampled sensor data rate. Output 1163 is the raw output of the digital sensor data for all sensors, but after being downsampled to reduce the amount of data associated with each sensor. This output 1163 contains data for all sensors except the downsampled (substantially low) data rate and is intended to be used by an additional real-time processor (not shown) to provide diagnostic health determinations. Downsampled data is easier to manage (requiring less memory for storage, resulting in a smaller size) and process compared to processing all real-time sensor data, reducing the time and processing power required for processors performing real-time diagnostic health determinations. Data conditioner 1165 operates similarly to data conditioner 1125, except that it must process substantially more sensor data per unit time, as high-frequency sensors typically generate orders of magnitude more data than low-frequency sensors at the same time interval. The format used by all data conditioners accommodates the incorporation of flags for abnormal or degraded conditions, or alarm statuses.

[0042] The data fusion module 1170 (see Figure 13 for a more detailed explanation) maps incoming sensor data streams within a travel time window to correlated groups of sensor data, i.e., the sensor data from each sensor within a group should also reflect the anomaly or failure, such that a component anomaly or failure sensed by data from one sensor in the group is indicated by data from other sensors in the group. For example, suppose the first group consists of sensor data associated with sensors that sense pump vibration, power consumed by the pump, and flow rate generated by the pump. Also suppose the pump is degraded due to bearing wear. If the bearings are sufficiently worn, the pump will generate non-standard vibrations. The power consumed by the pump may increase or surge the power demand at startup due to the increased friction of the worn bearings. The sensor data associated with the flow rate generated by the pump may or may not show a reduced non-standard flow, depending on the severity of the degradation, when the pump motor attempts to compensate for the increased load (power) that increases the rotation of the pump shaft while maintaining the required flow. Ultimately, continuing this process will cause bearing cracks, shaft misalignment, and possibly burnt motor wire windings, leading to failure of the pump components.

[0043] The consistency of sensor data indicating an out-of-standard state from two or more sensors within a sensor group is a process for identifying the presence of actual degradation or failure. Actual fault isolation is determined by the MBR engine algorithm 106 (Figure 2) when compared to the MBR model 20 (Figure 1). Conversely, data from one sensor indicating an out-of-standard state that is not verified by sensor data from other sensors in the group may be a false alarm, possibly due to a transient anomaly (random or intermittent), or a false alarm indicating that the sensor itself is not functioning properly due to a persistent out-of-standard state.

[0044] Sensor data associated with other upstream or downstream components can also be included in the group. In the pump example above, assume that the pump is controlled to produce a flow of liquid that is guided through a component, such as an engine that requires cooling. In this further example, a thermal sensor associated with the engine can also be included in the group, since a pump failure could also result in increased engine heating that may exceed the desired operating range. Thus, it will be understood that the grouping of correlated sensor data can be associated with the sensed attributes of two or more components. The group of sensor data may include sensor information from the high-frequency sensor 1150, the low-frequency sensor 1110, and / or other data sensors 1130. Naturally, data from some sensors may not be included in any group and may therefore be analyzed and considered individually.

[0045] The data fusion module 1170 analyzes mapped sensor data within a time window that increases over time, either on a group basis for sensor data contained within a predetermined group of correlated sensors, or for individual units where the sensor data is not part of any group. The data fusion module 1170 determines whether a tag should be associated with a group / individual sensor data based on usage and operating standard range information stored for each group / individual of sensor data, where the tag consists of one of a predetermined set of condition codes. Each condition code is mapped to and compared with similar fault codes generated by the components. The condition codes are then transmitted for further processing in the MBR engine 106 (Figure 2), while the fault codes and condition codes are stored in non-volatile memory. For example, a condition code of "0" indicates that the sensed attribute of the component is within the normal operating range; a condition code of "1" indicates an abnormality / failure of the component; a condition code of "2" indicates a detected false positive that may be caused by the normal operating range of the sensor being too wide to include undesirable operating conditions; and a condition code of "3" indicates a detected false negative that may be caused by a sensor failure or by the sensor's normal range calibration window being too narrow, causing the detection cycle of the MBR engine 106 to miss evidence of an actual abnormality.

[0046] Sensor data, along with condition codes, is transmitted from the data fusion module 1170 to the diagnostic model-based inference engine 106 for further analysis. The data fusion module 1170 is implemented by software running on a microprocessor / computer that can map the sensor data stream into correlation groups, compare each sensor value to a dynamic normal operation window with upper and lower thresholds, determine whether an anomaly / failure associated with one sensor in a group is supported by a correlation of anomalies / failures from another sensor in the group, and encode each sensor data using an error code tag representing the determined malfunction / failure.

[0047] Figure 12 is a block diagram of one embodiment of the anomaly and degradation detector 1160 of Figure 11. This detector is preferably implemented by software running on a graphics processing unit (GPU), such as a system-on-a-chip, which has hundreds, if not thousands, of GPU processor cores available for processing. This supports the simultaneous processing of outputs from multiple sensors. The A / D converter may utilize dedicated hardware circuitry, but the A / D converter may also be implemented in software utilizing the GPU core. Similarly, the data adjustment module 1165 may be implemented by software running on the GPU core. The digital sensor input 1205 from the A / D converter 1155 is received as input by a signal scale identification module 1210, which receives parametric values ​​from the sensor in a dynamic / moving window of valid values ​​and thresholds. The dynamic window of valid values ​​is established based on historically stored normal data for the operation of the vehicle to which the sensor is associated. The raw sensor data received by the signal scale identification block 1210 is passed to the downsample module 1215, which reduces the size of the sensor data stream by substantially eliminating normal data (retaining a small amount of time-stamped normal data with a large amount of deleted duplicate data represented by this data sample). Representatives of non-standard parameter data are tagged with a timestamp and the number of deleted duplicate data represented by this data sample. This downsampled data stream transmitted on output 1220 allows for the recreation of the initial data stream for non-real-time offline analysis. The identification of the operating mode block 1225 analyzes the sensor data and compares it to different stored historical value ranges associated with the corresponding different operating modes of the vehicle, e.g., pre-flight, taxi, takeoff, acceleration and deceleration, loitering, weapons delivery, landing, and post-flight operating modes, to name a few. The selection detection mode block 1230 receives the output from the identification of the operating mode block 1225, which identifies the operating mode of the vehicle.The selected detection mode block 1230 causes the mode parameter 1235 to identify the corresponding stored parameter set for each sensor (upper and lower thresholds, as well as other mode-dependent factors) that define the normal window of expected values ​​specific to that operating mode.

[0048] These parameters are sent to the anomaly / degradation detection module 1240, which uses the corresponding parameters in each sensor data stream to identify values ​​that fall outside the expected operating standards defined by these parameters. Thus, the dynamic window of normalized operation for each sensor changes depending on the operating mode. This provides a dynamic change in the normal parameters of each sensor based on the operating mode, and therefore allows for a more accurate determination of whether an anomaly / degradation is detected, by changing the corresponding "normal value window" to allow for values ​​expected during a particular operating mode. Since sensor values ​​can vary considerably depending on the operating mode, adjusting the window thresholds and parameters for each operating mode greatly increases the ability to eliminate false alarms without having to utilize a single large tolerance range to cover all operating modes. Offline training based on previous sensor data collected and stored for various operating modes allows for the refinement of these window thresholds.

[0049] The abnormal measurement module 1245 receives the respective sensor data from the abnormal / degradation detection module 1240. Module 1245 measures the parameter distance of the value associated with each sensor output against the normal parameter value of the determined operating mode. Based on these parameter distance measurements, the abnormal measurement module 1245 determines for each sensor output whether the function sensed by the sensor is operating within the normal mode or whether an abnormality exists. If the sensor output value is within the corresponding normal value window, normal operation is determined, i.e., the function is operating within the expected operating range. If the sensor output is outside the corresponding normal value window, an abnormality in operation is determined, i.e., the function is operating with degraded performance or in a faulty state, or there is a problem with the sensor or its calibration. See the tag condition codes described above. Such tags are applied to each sensor output and sent to the configured abnormal and degradation flag module 1250. Module 1250 incorporates such tags into each of the sensor output values ​​sent to the data adjustment module 1165 as output 1162.

[0050] Figure 13 is a block diagram of one embodiment of the data fusion module 1170 shown in Figure 11. The fusion module 1170 may be implemented by software running on a microprocessor-based computer. The data mapper module 1310 receives an incoming stream of sensor data 1305 from data adjustment modules 1125, 1145, and 1165. This module maps or correlates data from the incoming sensor stream so that data from different correlated sensors is integrated into their respective groups within a moving time window, as described above. That is, as the time window moves, the sensor outputs occurring within that time window should be mapped to correlated groups. Since the incoming sensor data is standardized to a common data rate, a time within each time window can be selected to capture one data output for each sensor. Since the sensors supplying the data are known in advance and the groups of correlated sensors can be manually predetermined, correlation information (sets of correlated sensors) can be stored in memory and used by the data mapper to route the relationships of sensor outputs to their respective correlated groups. These groups of correlated sensor outputs are input to a fused data module 1315, which analyzes the data of the group of correlated sensor outputs, including the sensor outputs in the group determined to be degraded / abnormal, against a stored set of initial performance parameters for the corresponding group of correlated sensors. The fused data module 1315 fuses or combines the data of the correlated groups of sensor outputs into a single dataset tagged with conditional failure codes or anomaly codes to support further analysis provided by the diagnostic model-based inference engine 106. The fused output data from the fused data module 1315 is input to a parameter characterization module 1320, which compares the data associated with each group of correlated sensor outputs with the output from a single sensor that is part of each correlated sensor group. This comparison preferably utilizes the corresponding output from a single sensor from a past or last state.Such comparisons with past output sensor states are useful for indicating and predicting future states that may show abnormal behavior or at least a tendency toward abnormal behavior. The results of such comparisons are stored in a queue and then output to the MBR engine 106 as a set organized as output 1175 for further analysis. The queue enables variable data rate output to accommodate any processing waits required by the MBR engine 106 while managing the input data rate 1175 without data loss (by dynamically allocating more processor RAM to the queue as needed and freeing up allocated RAM when not needed).

[0051] Figures 14 and 15 show exemplary high-frequency sensor data 1405 and 1505 from vibration sensors in motor bearings within centrifugal pumps for corresponding normal and defective pump bearings, respectively. Sensor output data 1405 represents vibration from a normally operating bearing within the pump and shows repetitive amplitude fluctuations 1410 with a larger amplitude corresponding to the pump condition, which in normal conditions slightly enlarges the smaller amplitude fluctuations 1415 corresponding to the pump condition that produces less vibration. The larger amplitude fluctuations 1410 typically correspond to pump conditions where a larger load is occurring due to compensation for fluid backflow in the impeller housing or a change in load, while the smaller amplitude fluctuations 1415 correspond to no fluid backflow and less vibration. Both 1410 and 1415 represent steady-state operation of the centrifugal pump. Note that the rotor (pump shaft) speed remains constant throughout the indicated time interval.

[0052] Sensor output data 1505 represents vibrations from a malfunction / defect in the pump's bearings. Somewhat similar to the modification in Figure 14, there are recurring larger amplitude outputs 1510 interspersed with smaller amplitude outputs 1515. However, note that the difference between the average of the smaller amplitude outputs and the average larger amplitude outputs is significantly larger in Figure 15 than the same corresponding difference in Figure 14. Also, the amplitude spike 1520 at the start of the larger amplitude output portion 1510 has a significantly higher amplitude than any of the rest of the larger amplitude output portion 1510. Note that over time, the amplitude difference of spike 1520A is further exaggerated compared to the corresponding rest of the larger amplitude portion 1510. Such vibration differences at the start of the pump cycle may correspond to increased friction due to bearing wear. Note also the system's baseline trend towards higher frequencies over time (e.g., an increase in the average slope from the start). This indicates the occurrence of pump shaft degradation and misalignment, as well as the possible eventual failure of the pump unless repaired.

[0053] Once sensor data is collected and stored in response to normal expected bearing vibrations during pump operation under good work instructions, this data can be compared to sensor data during service in operation (during aircraft flight) to determine whether the pump is functioning correctly or requires maintenance or replacement. As described below with respect to Figures 16 and 17, such a determination is preferably made based on information obtained from two or more sensing parameters.

[0054] Figures 16 and 17 show exemplary high-frequency sensor data 1605 and 1705 from sensors monitoring power to centrifugal pumps with good and bad bearings, respectively. Sensor output data 1605, corresponding to the power consumed by the pump with good bearings, includes a larger amplitude portion 1610 representing relatively high power consumption, with a smaller amplitude portion 1615 representing relatively low power consumption. Note that the timescales in Figures 16 and 17 are the same, but different from the timescales associated with Figures 14 and 15. For example, the larger amplitude portion 1610 may correspond to the time when the pump is operational and under load, while the smaller amplitude portion 1615 corresponds to a time interval with a lighter load or perhaps almost no load. Sensor output data 1705 corresponds to the power consumed by the pump with bad bearings, and includes a larger amplitude portion 1710 representing higher power consumption for lower power consumption, as indicated by the time interval 1715. However, the spike 1720 from the sensor of power consumption represents more than an order of magnitude greater than the maximum power consumption shown during the corresponding time interval 1610. Such extremely high power consumption needs coincide with the initial starting of a pump (or pump cycle) that has faulty bearings, which cause particularly high initial resistance to move the rotating parts of the pump.

[0055] The fusion of data from the pump vibration sensor and the pump power sensor leads to a highly reliable determination of whether the pump bearings are malfunctioning / deteriorating. A positive correlation between both the faulty bearing signal 1505 and the power sensor data 1705 results in a reliable determination that the associated pump requires at least maintenance or possibly replacement. Conversely, if there is no positive correlation between two or more sensor signals, it is possible that only one sensor signal indicating a fault is a false positive. Such a false positive may be the result of a transient condition such as a transient change in vehicle operation or temporary electrical interference. Alternatively, the lack of positive correlation may indicate that the sensor associated with detecting the malfunction is itself faulty or possibly out of calibration.

[0056] Figures 18, 19, 20, and 21 are exemplary graphs showing the high-frequency sensor signals and derived sensor signal averages used for dynamic anomaly recognition. This technique is independent of and performed in addition to the operation-based processing mode, but both are performed in parallel at the anomaly / degradation detection 1160. Only parameter anomaly tags with other information described below are transferred to the data fusion 1170. Note that the timescale (horizontal axis) of these graphs is not the same as that which these graphs are presented to help illustrate how different moving averages are used for dynamic anomaly recognition. In Figure 18, the output 1805 from the high-frequency sensor forms the basis for a set of three different moving averages, each with short-term, medium-term, and long-term timescale periods. In this example, the shorter-term timescale average 1810 is substantially shorter than the medium-term timescale average 1815, which is shorter than the longer-term timescale average 1820. Timescale duration refers to the number of sensor data values ​​used to calculate the corresponding short-term, medium-term, and long-term moving averages. The number of values ​​may vary depending on the sensor data rate and the typical rate of change of sensor values. At initial data acquisition, these moving averages are dynamically set according to the incoming parameter values ​​and the rate of change of amplitude. The medium-term moving average timescale is generally observed to be 1.5 to 2.5 times the short-term moving average timescale. The long-term moving average timescale duration is generally observed to be twice (or more) the medium-term moving average timescale duration. It should be noted that larger timescale durations for the medium-term and long-term moving averages have the effect of reducing the magnitude (amplitude) in the resulting curves. These moving average sampling windows may be refined by offline training on previous sensor data. They can be set statically once sufficient confidence in their applicability is obtained, thus reducing the computational power available for other processes. As shown in Figure 18, the substantially consistent average magnitude of the sensor output is reflected by the corresponding substantially linear short-term moving average 1810, medium-term moving average 1815, and long-term moving average 1820, respectively.

[0057] Figure 19 shows the output 1905 of a high-frequency sensor with associated short-term, medium-term, and long-term moving averages 1910, 1915, and 1920, respectively. In this example, there was a substantial amplitude, a short-term transient, over a period of interval 1925. The short-term moving average 1910 closely tracks the sensor signal 1905 during this transient interval. However, as shown in the figure, the medium-length moving average 1915 and the longer-term moving average 1920 have timescales that cause little variation in these averages during the transient interval. Such transients may reflect short, transient (intermittent or transient) anomalies relative to the moving average time interval associated even with the medium-length moving average 1915. These can be caused by random noise in the data due to a noisy data bus, environmental effects, or some other neighborhood mechanistic effect. This behavior is also known as a non-sustained shift of the moving average and thus indicates random statistical fluctuations in the signal.

[0058] Figure 20 shows the output 2005 of a high-frequency sensor with associated short-term, medium-term, and long-term moving averages 2010, 2015, and 2020, respectively. This example shows the substantial initial magnitude change of the sensor output value starting at interval 2025. The initial magnitude change of the sensor output decreases by the end of interval 2025, but it still remains at a significantly higher level than its progressing interval 2025 (i.e., an increase in the slope of the baseline curve). As can be understood, the short-term moving average 2010 closely tracks the sensor output values ​​before, during, and after interval 2025. However, the duration of interval 2025 is substantially longer than the number of values ​​used for the medium-term moving average 2015 so that the medium-term moving average 2015 begins to track toward the short-term moving average 2010, and these two moving averages substantially coincide at the end of interval 2025. During the 2025 interval, the long-term moving average 2020 slowly moves upward toward the medium-term moving average 2015, but it should be noted that by the end of the 2025 interval, the long-term moving average 2020 has not yet reached the value of the medium-term moving average 2015. The long-term moving average 2020 will eventually converge to the medium-term moving average 2015 (assuming the sensor output values ​​remain relatively constant at the end of the 2025 interval), but for this to occur, a considerable number of moving average rollover calculations will be required, depending on the number of sensor values ​​used and the difference between them and the long-term moving average. The fact that the baseline slope slowly increases during large sampling of parameter values ​​(numerous consecutive moving average calculations) indicates deviant behavior, i.e., a persistent shift in the moving average (note all curves). This is registered (tagged) as an anomaly and degradation event in the corresponding parameter data. The components corresponding to these moving averages are not faulty and are still usable, but are in a degraded state (i.e., the operating conditions must be adjusted to lower values ​​to achieve a steady state). However, at some point in the near future, this component may be repaired or replaced for the full normal performance of the component.

[0059] Figure 21 shows the output 2105 of the high-frequency sensor with associated short-term, medium-term, and long-term moving averages 2110, 2115, and 2120, respectively. In this example, the sensor output value 2105, starting at interval 2125, undergoes a steady rate of increase in value until it reaches a value substantially outside the nominal range at the end of interval 2125. As expected, the short-term moving average 2110 closely tracks the value of the underlying sensor value 2105. The medium-length moving average 2115 (medium sampling window) begins to rise toward the short-term moving average 2110 but does not reach the value of the short-term moving average 2110 until after the end of interval 2125. As expected, the long-term moving average 2120 begins to slowly move upward toward the medium-term moving average 2115 but does not reach the same value as the medium-term moving average 2115 by the end of the graph shown. This example shows a sustained change in the sensor output value (a sustained shift in the moving average) from the value shown before interval 2125 to a new, relatively out-of-nominal moving average at the end of interval 2125. This example indicates a component that is nearing failure. It must be repaired or replaced very soon, i.e., preferably when the vehicle in question returns to storage. The baseline slope is continuously and sharply increasing without any decrease. If this is a critical component, vehicle safety is involved if the vehicle continues to operate as is. The vehicle operator should return to base. The parameter data is tagged as a critical anomaly (for a critical component) with an alarm that is immediately processed by the MBR engine 106 and information that is displayed to the pilot (assuming the vehicle is an aircraft) or transmitted to a ground-based pilot for immediate action.

[0060] Figure 22 is an illustrative graph of high-frequency sensor values ​​from which criteria used to support dynamic anomaly recognition are derived. This illustrative graph provides a visual representation of the criteria determined on the moving data window 2210 based on the underlying sensor values ​​2205. These criteria provide a basis for determining whether an alarm should be triggered for the corresponding function sensed by the associated sensor values. Line 2215 represents the slope of the data values ​​contained within the window 2210. Line 2220 represents the arithmetic mean (u) of the data values ​​contained within the window 2210. The vertical line 2225 is a visual representation of the standard deviation (SD) of the data values ​​contained within the window 2210. In general, alarms are triggered by, |s|<0.0167 and SD / u<1 / 6 This is how it is set. This technique addresses the verification of persistent shifts in sensor output values ​​and the determination of alarm coefficients, i.e., when an alarm should be triggered. The technique is based on low probability with a Gaussian distribution statistic that determines a consistency value exceeding six standard deviations, normalized by the mean. Note that the standard deviations are normalized by the mean to accommodate different sensor output values. Comparing this to Figures 18-21, note that the normalized signal with a moving average (Figure 22) produces a smaller slope "s" for persistent shifts in the moving average, resulting in a smaller SD / u value. This creates the necessary conditions (as described above) for generating an alarm.

[0061] Figure 23 shows a flowchart of exemplary independent parallel processes that can be used to perform the anomaly / degradation detection shown in Figure 11. The stream of digital output from the sensors 1205 is received as input to process 2305, which determines the appropriate moving window of data associated with each sensor. Each sensor outputs data at a fixed data rate, although the output data rates of different sensors may vary. Since the output data of each sensor is uniquely identified for that sensor, the known data rate of each sensor can be stored in memory and then retrieved to help determine the appropriate moving data window, i.e., the number of sensor output values ​​that are grouped together for analysis. Following process 2305, the digital sensor data stream is downsampled in process 2310 to minimize the amount of data transmitted on output 1220. Often, when an anomaly is flagged, the same anomaly exists across a series of moving data windows. Downsampling can consist of counting the number of consecutive moving data windows each having the same anomaly for a given sensor output, and then encoding the counted number of data frames / windows with the data associated with the last consecutive moving data window having the same anomaly, so that the original data can be reconstructed as needed by simply duplicating the associated data for the counted number of times. This procedure is also used for nominal data to reduce its output size. This information is expected to be used both in real time for predicting the future state / value of components and in non-real-time environments such as maintenance analysis performed at maintenance locations. Output 1220 may be transmitted wirelessly or otherwise to a ground control station and / or maintenance location, or stored locally in non-volatile storage and later transferred from storage to the maintenance location, or acquired from the vehicle by a connected handheld device running a PMD viewer.

[0062] In step 2315, the current operating mode is determined, and the corresponding stored parameters for that operating mode are selected. In the case of an aircraft, the current operating mode can be takeoff, standard acceleration, combat acceleration, cruising at a steady speed, landing, etc. This information can be determined from a flight plan stored in memory, or from the analysis of sensor data that reflects the operating mode, such as wheel weight, accelerometer, speed, and rate of change of altitude. Predetermined stored criteria / thresholds for such sensor data can be used to determine the operating mode when compared with the current sensor tag. Detection parameters associated with a specific operating mode, such as upper and lower thresholds, or stored normal values ​​for the determined operating mode are selected. Each of the multiple anomaly detectors 1160 is connected to the same existing set of high-frequency sensors (1 to n sensors) within the component and implemented on one core of the GPU. Alternatively, multiple anomaly detectors 1160 can be run on the same GPU core for different sensors from similar or different components. Sensor thresholds and calibration information are available from supplier data and are stored in the vehicle for processing of real-time input vehicle data. There are enough GPU cores that can be used for each high-frequency sensor in the vehicle.

[0063] In step 2320, the current sensor value is compared to the selected detection parameters for the current movement window. In actual measurements (real-time input signals), these selected detection parameters match the nominal behavior of the component to which the sensor is attached. An artificial neural network (ANN) with input, hidden, and output layers with backpropagation can be used as an anomaly detection mechanism. Stored training data is organized into groups of classes and used for monitoring capabilities (offline supervised learning). An n-dimensional Gaussian function can be used to model each class. These are also called radial basis functions (RBFs). They capture the statistical properties and dimensional interrelationships between the input and output layers. The algorithmic goal of the RBF ANN is an output parameter of "0" for nominal component behavior and an output parameter of "1" for non-nominal component behavior.

[0064] In step 2325, for normal sensor values, such as abnormal outputs, the difference between the sensor value and the corresponding normal detection parameter is calculated and stored. This information is useful for offline training of sensor data and for improving the RBF function model. In step 2330, data flags / tags are set for the corresponding sensor data as needed.

[0065] In step 2335, the short-term, medium-term, and long-term moving averages for the output of each sensor for each moving window are determined. The calculation of moving averages is well understood by those skilled in the art, and there is no difficulty in implementing such calculations and software. In step 2340, the difference between these moving averages and the trend of the moving averages are determined. In step 2345, the determined trend is compared with stored historical trend data to determine whether an abnormal condition exists. If a persistent shift (as determined above) exists in each step 2347, the process continues to verify and validate the need for an alarm flag and transmits the corresponding sensor data to 2350.

[0066] In step 2350, the slope, mean, and standard deviation of each sensor output in each movement window are calculated. Those skilled in the art will know how to perform such calculations in software using a standard microprocessing unit or an arithmetic processing unit. These calculations can also be performed on a graphics processing unit. In step 2355, "Test 1" is performed, and the slope is compared to a predetermined stored slope threshold to determine whether an abnormal condition exists. In step 2360, "Test 2" is performed, and the normalized standard deviation is compared to a predetermined stored standard deviation threshold to determine whether an abnormal condition exists. In step 2365, if both "Test 1 and Test 2" are outside the normal range, it is determined that abnormal behavior exists. If necessary, an abnormal / degraded flag is set in step 2330 following step 2365. Also in step 2330, the high-frequency sensor data is downsampled to have substantially the same data rate as the data rate received from the low-frequency sensor and other data sensors. This facilitates easier processing and integration of sensor data from all sources by the data fusion block 1170.

[0067] Figure 24 shows a flowchart of an exemplary process that can be used to implement the data fusion shown in Figure 13. In process 2405, the incoming sensor data stream 1305 is routed (mapped) to a predetermined group in which each data stream within the group is correlated. Sensor data correlation has been described above. Each sensor data stream is uniquely identified, and the sensors in the correlated group are predetermined and stored in memory, for example, by manual input by a modeling engineer (Figure 2) who identifies the sensors in each correlated group. This information is stored in memory and then retrieved to separate the incoming data streams into correlated groups. These correlated groups may be temporarily stored in memory for individual analysis, as well as for correlation analysis against any faults indicated by the individual sensor outputs.

[0068] In step 2410, for each correlated group, the sensor value is compared to the corresponding normal range of the value associated with the current operating mode. Based on this analysis, sensor data associated with groups identified as abnormal is tagged with a condition code. In step 2415, the fused group sensor data is compared to individual (single) sensor values ​​for correlation or lack of correlation across multiple data windows to detect abnormal behavior or a trend toward abnormal behavior. For example, individual sensor data from one of the correlated sensors 1110 or 1130 in relation to a group of correlated high-frequency sensors 1150 may be useful in confirming anomalies or preventing potential false alarms where individual sensor data is not validated by other abnormal sensor outputs from others in the group. Alternatively, such individual sensor data may reflect normal operation, while the corresponding group of correlated sensors from the high-frequency sensors may show a trend toward abnormal behavior. This represents a "false negative" of an individual sensor where single sensor data does not respond sufficiently to provide a warning that the component in question may require some form of maintenance.

[0069] Figure 25 is a block diagram of an exemplary computing system 2500 for performing high-frequency sensor analysis and integration with low-frequency sensor data. The core of the computing system on chip (SOC) is a microprocessor 2505, which may also include an arithmetic processing unit and / or a graphics processing unit (GPU). Alternatively, the GPU may be used independently to process some of the calculations / decisions in Figures 23 and 24, i.e., excluding the “graphic” information. Read-only memory (ROM) 2510 contains stored program instructions and data used by the microprocessor 2505. Random access memory (RAM) 2515 is also used by the microprocessor 2505 as a place where data can be stored and later read (the GPU also has its own RAM). Non-volatile memory devices 2520 are used to store instructions and / or data that will not be lost in the event of a power loss in the computing system. Input / output (I / O) buffers 2525 are coupled to the microprocessor 2505 to facilitate the reception of external data and the transmission of data from the microprocessor to external devices. The input device 2530 represents a conventional method for a user to input information into a computing system, such as a keyboard or mouse. The output device 2535 represents a conventional method for transmitting information from a computer system to a user, such as a video monitor or printer. Depending on the number of parallel cores in the microprocessor 2505 (or GPU), all cores provide sufficient computing power to process the data from all sensors according to the process described above. For example, one core can be used to process all the data from one correlated group of sensors, because all sensors in that group have outputs that need to be stored and compared with the outputs of other sensors in that group.

[0070] As will be understood by those skilled in the art, the ROM 2510 and / or non-volatile storage device 2520 store an operating system that enables the microprocessor 2505 to communicate information with peripheral devices as shown in the figure. More specifically, sensor data is received via I / O 2525, stored in memory, and then processed according to the stored program instructions to achieve the detection of abnormalities and degradation of components associated with each sensor. Based on the analysis of sensor data as described above, those skilled in the art will know how to implement in computer system software to determine moving averages of different lengths as described with respect to Figures 18 to 21 over successive moving data windows and compare each value of the moving averages of different lengths with stored thresholds for a particular operating mode. Similarly, with respect to Figure 22, those skilled in the art will know how to calculate the slope, mean, and standard deviation of sensor data in successive moving data windows in software and compare the results with stored criteria. Different thresholds and values ​​corresponding to different operating modes of each vehicle are stored in memory. Once the operating mode is determined, the corresponding stored thresholds and values ​​are used for comparison with information derived from the sensor during each operating mode. In contrast to using only fixed upper and lower thresholds to determine the normal operating range of a given sensor for all types of operating conditions, the techniques described herein provide dynamic, i.e., changing criteria for a given sensor to determine abnormalities / degradation that depend on changes in sensor data and / or the vehicle's operating mode.

[0071] When used, unless otherwise specified, the terms “top,” “bottom,” “front,” “back,” “up,” “down,” and similar terms should not be interpreted as limiting the embodiment to a particular orientation. Instead, these terms are used only in relative terms.

[0072] Figure 26 shows a block diagram of an exemplary failure prediction system 2600 for determining whether maintenance at the component level is required for an aircraft / system, while providing degradation / failure status awareness for aircraft / system equipment, by determining the past, present, and future performance / degradation status at the component level. The system 2600 operates at the component level, meaning that the data and information being processed can be related to a single component or multiple components simultaneously, depending on the detection and tagged abnormal behavior of component data from the data fusion module 1175 and the output from the MBR diagnostic engine 106, enabling interconnected degradation / failure modes between multiple interrelated components. To process all the data and information from multiple components within a complex vehicle system, the failure prediction system 2600 may consist of multiple processing systems, each dedicated to processing information and data associated with a different single component.

[0073] The data interface module 2605 receives input 1175 from the data fusion module, identifies tagged data and alarms, and passes this separated data to the LRU / system selection and data transfer module 2610. Alarms are immediately passed by module 2610 to the damage estimation module 2625. The output from 106 (MBR diagnostic engine) consists of multiple component fault codes corresponding to fault / failure and false alarm isolation for each component, as well as nominal data and functional analysis of the cause of the fault / failure (e.g., leaking pipe, worn bearing, motor shaft misalignment). Both fault data and nominal data correspond to BIT and parametric data passed to the damage estimation module 2625. Alarms from multiple sources and corresponding decomposition fusion data (i.e., for each component, data separated for degraded components in the LRU / system selection and data transfer module 2610 and incorporated into multiple streams that are simultaneously transferred to various modules with the highest priority given to component data with alarms) are also passed from the data fusion module 1175 to the damage estimation module 2625 via the data interface 2605 and the LRU / system selection and data transfer module 2610.

[0074] The LRU / system selection and data transfer module 2610 identifies and isolates relevant tagged data associated with the components being analyzed (tagged data with the highest alarm priority), as well as corresponding aircraft data such as BIT, parametric, analog (direct sensor signals without analog-to-digital (A / D) conversion), discrete (hardware ON / OFF control signals passed via software bits), environmental (internal environmental conditions such as humidity, pressure, temperature, and dust), and external measurement data (e.g., sand, dust, heat, wind, rain). This data is transmitted to the model interface module 2620. The model interface module 2620 creates multiple data streams, one for each component. The tagged data is metadata obtained from anomaly detectors (high-frequency sensors), low-frequency sensors, and other data streams that have data fused with tagged alarms and verified evidence data. The verified evidence data consists of data representing 1) no fault, 2) fault, 3) false alarms (either false negative or false positive), and 4) a functional analysis of the causes of 2) and 3). Verified evidence data from various interacting / interconnected component sensors regarding the current component's fault / failure mode is received from the anomaly / degradation detector module 1160, fused in the data fusion module 1175, and provided to the data interface module 2605. This data is decomposed in the LRU / system selection and data transfer module 2610 for the current component's fault / failure mode. Independently verified evidence data is received from the MBR diagnostic engine 106, which performs fault / failure / false alarm separation from parametric and BIT data from various interacting / interconnected component sensors regarding the current component's fault / failure mode.The LRU / system selection and data transfer module 2610 also requests case-based history from the maintenance history database 2618 associated with relevant component maintenance data (including post-flight pilot cries and maintenance manager notes) via the maintenance history database interface 2615, which is then compared in real time with the current abnormal component behavior and alarm data. These histories consist of case-based records and stored parameter values ​​of the relevant components. The maintenance history DB interface module 2615 can, for example, use ANSI SQL statements to extract previously stored repair and replacement information as well as tests performed, contained in these maintenance records written by maintenance managers. Maintenance managers are technicians assigned to perform maintenance on aircraft / system components for which the maintenance manager has obtained maintenance certification. These maintenance records also include in-flight real-time evaluations previously stored by the fault prediction engine and are stored in the maintenance history database 2618, which is preferably a relational database. Maintenance managers enter maintenance notes via a graphical user interface (GUI) when fixing, repairing, or replacing components, further visually observing the degradation status of the components. The relevant records also include the original BIT and sensor parametric recording data from which the degradation was determined. The recorded notes may also include a manual entry description of the nature of the alarm, and a functional analysis of why the component alarm was issued and what remediation steps were taken to correct the alarm / problem.

[0075] The model interface module 2620 sends a request to the failure prediction model database 2635 to identify the relevant component based on the decomposed tagged data received from the LRU / system selection and data transfer module 2610 for a specific component. The failure prediction model database 2635 then requests the hybrid PS model module 2630 to send the relevant physical-based model, e.g., an XML file, an empirical model, e.g., an XML file, and a physical system logic / functional model, e.g., an XML file. These models / files are "blueprints" containing definitions and knowledge of the component regarding its diagnostics and failure predictions, as well as its attributes, functions, behaviors, and semantics. As illustrated in more detail with respect to Figure 27, the physical-based model of the relevant component generates residuals along with the empirical model of the relevant component, utilizing the values ​​associated with the component compared to the current corresponding data values, and also generating the resulting residuals. These residuals are combined to form a complete observation of the current data compared to the combined model. Near zero residuals means there is no abnormal component behavior (small residuals may be caused by component noise, which can be later eliminated by training the system offline from the collected data).

[0076] The damage estimation module 2625 utilizes residuals from the physical model (i.e., the physical-based system damage equation) and the empirical model, along with the physical system logic / functional model, to generate a representation of the degradation behavior of each component. Residuals are the differences between the expected component attributes, functions, behaviors, and semantics and the corresponding attributes generated by the current data stream of the component being evaluated. Residuals are generated for each of the three models during component evaluation and are typically close to zero for aircraft components with good performance. The degradation level represents the severity level of the alarm displayed to the pilot / mission operator. The alarm level can be correlated, for example, to the remaining service life (RUL) of the component as determined by the damage estimation module 2625. An RUL between 70% and 51% indicates mild degradation behavior (assuming a gradual decline rather than a sharp decline from the most recent RUL value), 50% to 11% indicates moderate degradation behavior, and less than 11% requires repair or replacement of the component. Naturally, varying percentages can occur depending on expected future wear / degradation and the severity of future environmental conditions. Damage estimation module 2625, RUL, and EOL (End of Life) determinations are described in more detail below.

[0077] The alarm generator module 2645 generates an alarm based on the RUL level determined by the damage estimator module 2625. It calculates the RUL slope from current and previously stored RUL data and generates an alarm level based on this slope and the current RUL value. For example, a change in slope exceeding a predetermined amount may signal that the deterioration is too rapid and trigger an alarm, even if the RUL value alone would not guarantee the generation of an alarm. This is further illustrated in Figure 30. The calculated RUL curve 3005 is determined from historical and current data. For deteriorated components, the slope 3010 is dynamically calculated across sliding windows of the RUL calculation. The final RUL curve slope is calculated across several consecutive sliding windows, e.g., three windows. This is the average of the RUL curve slopes, calculated, weighted, and normalized against the same units as the y-axis (RUL axis) to generate a one-to-one unit relationship between the y-axis and x-axis (i.e., a time axis that generates a unitless slope). This unitless slope is compared against a predetermined threshold, e.g., 0.5. If this slope is greater than a predetermined threshold, an alarm is issued. The time unit (x-axis value) is the difference between the start of the operation and the current time (within each sliding window), and the start RUL is the past RUL at the start of the operation (i.e., used in the first sliding window, subsequent sliding windows use the last RUL calculation in the previous sliding window, and so on). The alarm is passed to the pilot display 2650, which presents a visual display indicating the alarm level with the relevant LRU / component for pilot action. Depending on the degree of degradation, the specific component, and the flight and mission criticality of the component, the decision may be to continue the flight mission even with a known degraded component.

[0078] The algorithm selection module 2660 determines the algorithms to be used by the damage estimator module 2625 and the state predictor module 2670. The algorithm 2668 associated with the currently analyzed component is identified and loaded from the algorithm selection module 2660 into the memory of the damage estimator module 2625 and the state predictor module 2670 for processing. The state predictor module 2670 uses historical states to calculate the current and predicted future states of the component being analyzed (using the particle filter algorithm). These states are updated as new data such as BIT, parametric sensor, analog, discrete, and environmental data related to the component in question are received. The analysis data database 2655 receives and stores all analysis data from the damage estimator module 2625, along with hybrid model parameters from the hybrid model module 2630 and the state predictor module 2670.

[0079] The Quality of Service (QoS) computer 2675 calculates QoS metrics at the IVHM diagnostic and failure prediction system level, as well as at the component level. Some of these metrics are shown in Figure 28. Note that in Figure 28, all metrics relate to the current aircraft / system and its components. RUL is calculated in the damage estimation module 2625, while End of Life (EOL), a future prediction, is calculated in the condition prediction module 2670. Component QoS metrics are calculated in the QoS computer module 2675 for the target vehicle / aircraft and stored in the analysis data DB 2655 for all current aircraft. The offline ground-based vehicle-level failure prediction system accumulates data (mining data) from all aircraft / systems and generates single, multiple, or whole-vehicle reports from these stored metrics. These QoS metrics are passed to the condition prediction module 2670, which stores this information in the analysis data DB 2655. This data is later retrieved offline on the ground for various report generation and data replay. Mission plan 2665 provides a mission profile to damage estimator module 2625 and mission plan information to condition predictor module 2670. Mission plan module 2665 receives equipment damage information from damage estimator module 2625 to construct a degraded mission plan, i.e., an alternative modified mission plan (if possible) depending on the degree of degradation of the components. Condition predictor module 2670 periodically receives the updated mission plan from mission plan module 2665 and, in return, provides mission plan module 2665 with the current and future equipment degradation status to construct a reactive and proactive mission plan based on the equipment status. All analysis data from damage estimator module 2625 and condition predictor module 2670 is stored in analysis data 2655.

[0080] Figure 27 shows a block diagram of an exemplary hybrid model system 2630, consisting of 1) a physics-based model module 2710, 2) an empirical model module 2715, and 3) a data-driven functional physics system model module 2720, for each component whose behavior and degradation trends are reliably characterized. Potential inaccuracies and defects in the physics-based model (due to manufacturing imperfections in components, structures, etc., and / or other causes such as microstructural cracks in wing structures, faulty transistor circuits, and substandard quality materials such as resistors and capacitors) are effectively overcome by the use of the empirical model. Empirical model residuals are generally additional, resolving imperfections due to various causes not considered in the physics-based model. These residuals may be subtractive, in which case the physics-based model is over-specified (it models in more detail than the available component data on the aircraft / system). In such cases, component suppliers are required to provide additional necessary data in the component output. A zero empirical model residual means that the constituent elements are functioning correctly, or that previously observed discrepancies have been sufficiently refined from the empirical model to produce a zero residual for the current operating mode, usage, mission, and environment. From Figure 27, the residuals r'(p) and r(p) can be expressed mathematically.

number

number

number

[0081] The output 2751 of the summing node 2740 is the input to the performance estimation module 2755, which is forwarded to the damage estimation module 2625, stored in the analysis data 2655, and the refinement of the model parameters is stored in the failure prediction model DB 2635. The condition predictor module 2670 receives the updated analysis (consisting of model parameters and residuals) from the analysis data 2655. In the performance estimation module 2755, the initial input is received from the initial performance parameter database 2760, which stores historical performance data for all aircraft / system components. A comparison of the parameter residuals 2751 with the corresponding parameters obtained from the database 2760 provides input to the extended Kalman filter observer module 2765, which filters the input, and provides output to the performance estimation module 2755, which includes the delta difference of performance. The output of the performance estimation module 2755 is a feedback loop routed to the physical base model 2710, where a predetermined performance difference between predicted performance measurements and historical performance measurements triggers a root cause analysis. The continuous decline in performance is caused by the increasing degradation of the corresponding component.

[0082] As an example, a degraded brine pump was selected and its various component signals were monitored over several tens of minutes of operation. Figure 29 shows the degradation of the pump's bearing performance and power distribution performance. Over several minutes of operation, the bearing vibration amplitude 2905 rises rapidly from normal operation to the onset of degradation 2910 and to a potential point of significant failure 2915. Similarly, in Figure 29, the pump's power distribution 2920 rises sharply from the onset of bearing degradation 2925. The large power 2930 required could cause degradation of additional pump components if it is possible to continue at this level of operation. Over many flights, more accurate initial performance parameters are obtained as a continuous process from offline ground training on the model and algorithm, which is performed through the collected data and the refinement / elaboration of the model and algorithm.

[0083] The physics-based model 2710 includes several equations that characterize the behavior of the component in question based on the physics of the component, e.g., electrical, mechanical, and hydrodynamic. It describes the nominal behavior and, if component damage indications exist (from input parametric and BIT data streams), how this damage is expected to increase in both quality and quantity. Damage indications may not be monotonic in nature. Damage may be caused by intrinsic properties of the component (e.g., battery recovery or effects attributable to semiconductors in a power system) or by extrinsic influences such as incomplete / partial maintenance operations. Each failure mode may generally have a different damage propagation model. The empirical model 2715 is very useful in capturing these differences in the different component failure mode damage variations and, potentially, component repair (if the hardware has this capability) of the component physics-based model 2710. These equations naturally vary depending on the specific component being characterized. For example, an exemplary brine pump can be characterized by the behavior of its individual components as shown in Table 1 below. [Table 1] The definitions of the above parameters are shown in Table 2. [Table 2] Table 3 shows the nominal parameter values ​​for a typical brine pump. [Table 3]

[0084] Empirical Model 2715 provides a model of target component data values ​​that models normal system operation based on a statistically significant sample of component operation data. Such empirical models based on historical performance data of components allow for a wider range of performance expectations than physical-based models, because the same component may have operated at different stress levels and / or in different environments. As an example, monitoring the time-dependent fluid flow (over different times of day, days, weeks, months, etc.) through a brine pump impeller housing and pipes characterizes the operation and use of a local brine pump. The corresponding data values ​​provide a statistically significant empirical model that empirically defines the brine pump for use in the operation and use of a local aircraft / system. By utilizing the empirical model, different RUL and EOL predictions for the same brine pump at different locations on the same aircraft / system or the same brine pump in another aircraft / system provide real-world variability that can be used to determine the RUL and EOL of the monitored brine pump. Such results improve the accuracy of RUL and EOL predictions.

[0085] The physical system model 2720 is a data-driven functional model. The failure prediction node within the physical system model 2720 includes expected usage parameters of components related to the aircraft / system's mission profile and its operating modes (i.e., pre-flight, taxi, takeoff, loitering, etc.). The observed / measured behavior, i.e., data values, is compared to the corresponding functional model, i.e., the acceptable range (threshold) of the corresponding measured data values, which is the "blueprint" of acceptable behavior, and the residual 2745 of this comparison is the output.

[0086] For example, a subset of brine pump components of an exemplary physical system model 2720 is shown in Figure 31. It consists of a “failure model” and a “modeling process” using different parameters / characteristics to model the brine pump, and in this example a subset of brine pump components is shown. The partial brine bump representation 3100 shows a brine “supply line,” a brine “pressurized output” through the impeller (black triangle), and a motor rotating shaft that provides torque supplied by the motor to circulate the brine within the brine pump cooling system. The “failure model” consists of affected inputs 3105, affected symptoms 3110, affected outputs 3115, input 3120, failure mode 3125, output 3130, and checkbox 3135. Checkbox 3135 represents the correlation between affected inputs 3105 and input 3120, between affected symptoms 3110 and failure mode 3125, and between affected outputs 3115 and output 3130. As an example, note that the correlation of pump limits in failure mode 3125 corresponds to the symptoms of excessive heat, excessive noise, and excessive vibration in affected symptom 3110. This is also true for the other correlations mentioned above. These correlations make a significant contribution to the generation of a high-fidelity model of the brine pump. The model must include the data types necessary to understand the degradation of the components under scrutiny. Modeling process 3140 describes the typical data specifications required. Typical specifications include “record specifications,” “algorithm specifications,” “trend specifications” (quality and quantity of degradation), and “prediction specifications.” Depending on the components being modeled, other specifications may be required (e.g., wiring diagram specifications for electrical components).

[0087] The performance estimation module 2755 and the enhanced Kalman filter 2765 together measure the difference in component performance over a time-dependent sliding sensor data window. The enhanced Kalman filter 2765 is used as an observer of component sensor parameters over time; that is, it uses the sensor parameter history to monitor and calculate changes in component parameters over a variable time-dependent sliding sensor parametric data window. The enhanced Kalman filter provides nonlinear dynamics in component performance. First, it calculates the performance of a component from existing stored training data (trained offline), calculates the difference with the current data, and compares it to the performance of past components. The change in performance is forwarded to the performance estimation module 2755. The enhanced Kalman filter observer 2765 and the performance estimation module 2755 are based on a robust bank of two-stage Kalman filters (in the first module 2765 used as the “observer”) that simultaneously estimate both the performance state and the degradation bias (if observed in a component, see Figure 29 as an example of a sensor signal). The input 2705, along with the parameter residuals 2751 (from the physical system model 2720) and the initial performance parameters 2760, proceeds to the Kalman filter stage 1, performance estimation 2755. Passed to the second stage of the extended Kalman filter observer 2765, the output of this stage is the new component parameters, i.e., component parameters adjusted by averaging the residuals over a small sampling window relative to the direct input 2705. In stage 2, 2765, the estimation result from stage 1 is considered the "measured value". The output of stage 2 provides the dynamic delta difference in the performance measured value and improved component parameters to improve the performance estimation in performance estimation 2755. This two-stage Kalman filter method is designed for fast convergence by fast covariance matrix calculation, which provides fast degradation detection and separation of anomalously behaving components.Two-stage Kalman filters are commonly known, for example, VRNPauwels, 2013, Simultaneous Estimation of Model State Variables and Observation and Forecast Biases Using a Two-Stage Hybrid Kalman Filter, NASA, ASIN: B01DG0AT6A. The two-stage mechanism also determines whether the sensor parametric data shows degradation, positions the sensor, quantifies the degradation, and outputs the results.

[0088] The two-stage Kalman filter is shown in detail in Figure 34. The dynamics of the constituent parameters are described using discrete linear time-varying state-space-time equations. These are as follows:

number

number

number

number

number

number

[0089] The damage estimation module 2625 determines the amount of damage to each component. In the brine pump example, the damage vector equation is given by the following equation (note that all variables in the physical-based model equation are directly measured parametric sensor values ​​or values ​​derived from these sensor parametric data). Friction and wear (sliding and rolling friction) r thrust (t=w thrust r thrust ω 2 r radial (t=w radial r radial ω 2 Here, w thrust = Thrust bearing wear coefficient w radial = Radial bearing wear coefficient ω = pump rotation speed (defined earlier) r thrust = sliding friction r radial = Rolling friction Damage vector d(t)=[a4(t),r thrust (t),r radial (t)] θ Here, d(t) = is the damage vector, a4(t) = Impeller area coefficient (defined earlier) r thrust= Sliding friction (defined earlier) r radial= This is rolling friction (as defined earlier). θ = pump temperature Significant damage to brine pumps occurs due to bearing wear, which is a function of increasing friction (i.e., subject to the coefficient of friction). The wear vector is determined by the coefficient of wear. w(t)=φ(t)=[w a4 ,w thrust ,w radial ] θ Here, φ(t) is used as the parameter vector in the prediction algorithm. Differentiate it from the weight calculation. θ = pump temperature The RUL calculation in the damage estimator module 2625 is identical to the EOL calculation described below for the condition predictor 2670, except that the RUL is calculated at the present time and is not a future projection / prediction. A typical RUL graph 3005 representing the degradation of a degraded brine pump over time is shown in Figure 30. The RUL can be estimated at any point in the aircraft / system's operating history, even if there are no faults / failures and / or component defects (i.e., the defect equation is valid for all operating conditions in either the past or present time horizon for which data is available). A future prediction of the RUL (when data is unavailable) is known as the End of Life (EOL) prediction.

[0090] The state predictor 2670 uses a state vector, which is time-dependent. For a brine pump, the complete state vector equation can be written as follows (note that all variables in the physical-based model equation are directly measured parametric sensor values ​​or values ​​derived from these parametric sensor data): x(t)=[ω(t),θ thrust (t), θ radial (t), θ oil (t), a4(t), r thrust (t),r radial (t)] θ θ thrust = represents the temperature of the thrust bearing (as defined earlier). θ radial = Radial bearing temperature (defined earlier) θ oil = Oil temperature (defined earlier) a4(t) = Impeller area coefficient (defined earlier) r thrust = sliding friction (defined earlier) r radial = represents rolling friction (defined earlier). ω(t) = pump motor rotation (defined earlier) The state predictor 2670 uses a time-dependent state vector, i.e., the state of the brine pump at any given time. Both the damage equation and the state equation define the physics of the components at any given time. The end-of-life (EOL) of a brine pump is predicted numerically using a particle filter algorithm that predicts the future state of the brine pump using the state vector equation and damage equation described above. The future state particle probability density (note that x is the state vector described above) is given by the particle filter (PF) process. The particle filter (PF) performs the following calculations.

number

number

number

number

[0091] The particle filtering process is a robust technique that avoids the linearity and Gaussian noise assumptions of Kalman filtering, providing a robust framework for long-term horizon failure prediction while effectively considering uncertainty. Correction terms are estimated during offline training / learning to improve the accuracy and precision of the algorithm for long-term horizon prediction from the collected analysis data 2655. The particle filtering method assumes that the equation of state representing the evolution of the degradation mode over time can be modeled as a first-order Markov process with additive noise, iteratively refined sampling weights, and conditionally independent outputs.

[0092] Figures 32 and 33 show exemplary flowcharts of the particle filter algorithm and EOL prediction, respectively. In step 3205, the particle filter algorithm is initialized with initial particle parameters stored in memory. In step 3210, an initial particle population is generated based on the initial particle parameters. In step 3215, particles are propagated using a state predictor model. In step 3220, the weights assigned to various parameters are updated based on the current measurements of each parameter in step 3225. In step 3230, it is determined whether the updated weights are degenerate weights. Degenerate weights are defined as the difference in particle weights, i.e., a few particles having high weights and the remaining particles having low weights. If all resampled particles have similar weights within <= 5%, particle variation weight degeneracy is interrupted. The NO determination in step 3230 results in the repetition of the process by returning to step 3215. A YES determination in step 3230 leads to resampling in step 3235, followed by further iteration by returning to step 3215. Resampling is necessary if the degeneracy has not been interrupted. To avoid calculating particles that do not contribute to the estimation, resampling (3235) is performed on the current number of particles (particles propagated to step 3215). These particle weights are outliers and are rejected. The particle filtering process is also described by the particle filtering equation described above.

[0093] Figure 33 is a flowchart of an exemplary method for providing EOL determination. In step 3305, EOL generation is initiated. In step 3310, an initial particle population (an arbitrary initial number of particles selected for computation, improved after offline algorithm and model training from stored raw and analytical data) is estimated. In step 3315, particles are propagated using a state predictor model. In step 3320, a determination is made as to whether a predetermined percentage of EOL has been reached for the component under consideration. A NO determination in step 3320 leads to an iteration back to step 3315, where further propagation of particles using the state predictor model occurs, followed by another determination in step 3320. A YES determination in step 3320 results in the generation of an EOL prediction in step 3325. The continuous component EOL prediction (for degraded components) during aircraft / system operation is stored in analytical data 2655. This EOL prediction is used for future aircraft / system operation. The EOL forecast allows for the creation of an EOL probability distribution function (PDF) from this data and previous historical data by ground and offline vehicle-level failure prediction engines for further analysis to generate the EOL forecast, which is provided as a report to the product support team. The above equation provides a more detailed explanation of the EOL determination. Note that RUL is calculated at the present time and does not involve future state prediction. This calculation is identical to the EOL calculation described above, except that the RUL calculation at the current time is determined using the EOL equation and method described above.

[0094] As shown in more detail in Figure 44, Figures 36 and 37 provide block diagrams of an exemplary vehicle-level fault prediction system 3600 in which user-selectable controls are provided by a GUI 3601. The exemplary GUI 3601 consists of a menu bar 3602 with multiple menus and a toolbar 3603 with multiple executable button icons configured to initiate actions indicated by names in tooltips 3604 displayed when the mouse is hovered over the button icons. The main screen body 3605 is a table displaying rows for all available aircraft, each row displaying one aircraft identified by its tail number (aircraft from vehicles of similar types are individually identified by their tail numbers). Each column in the table may display attributes specific to the aircraft's tail number, such as its serial number, tail number, mission capability (ground-based, partially missionable (PMC), non-missionable (NMC), and fully missionable (FMC)), its zone, its location, and other user-defined attributes. Each displayed aircraft can be selected with the mouse to indicate its status, equipment assets, etc. The GUI has a role-based mode of operation, meaning each role relates to different uses by personnel with different purposes. These personnel could be: 1) mission operators who plan and execute aircraft missions; 2) maintenance managers who are responsible for aircraft maintenance; 3) trainers who train mission operators and maintenance managers; 4) model designers who develop models of physical components (physics-based, data-driven, and empirical); 5) database administrators who maintain database functions; and 6) programmers who develop, maintain, and generate software for the operation of vehicle-level fault prediction systems. To provide flexibility and simultaneous use, the GUI can run independently on servers with different operating systems and various servers (e.g., mission servers, maintenance servers, training servers, technical data servers, etc.).

[0095] When the "Server" button icon on toolbar 3603 is changed from "Off" to "On" (by a mission operator in mission operator mode), the vehicle-level fault prediction system enters autonomous mode, establishing various data socket links with the COMMS system 3605, which then receives data from various aircraft in flight or from other aircraft in ground operations such as pre-flight testing, ground taxiing, and pre-launch. All GUI functions typically run autonomously unless selected by the mission operator to be run manually. Maintenance managers can instruct the system via GUI 3601 to run various calculations and predictions in offline "maintenance mode" (i.e., when not attempting to acquire new aircraft data or when COMMS 3605 is inactive), build reports required for predictive maintenance schedules, and build maintenance schedules based on the Mean Time Between Failures (MTBF) of aircraft components. The MTBF is developed during the design phase from component specifications, derived from reliability and test data from component suppliers. These, as illustrated in Figure 43, support inventory management and supply chain operations in the Enterprise Asset Management (EAM) system when predictive maintenance is needed or when a failure occurs requiring immediate corrective maintenance, storing components and parts and preparing them for repair / replacement. Trainers via GUI 3601 can run the system in offline “trainer mode” to instruct and train others on the use of the vehicle-level failure prediction system by replaying accumulated raw and analyzed data. In designer mode, during the design phase and subsequent refinements in other stages, designers create models, validate them, and test them with synthetic and / or actual flight data from the 4355 Test Manager (Figure 41) via GUI 3601 (Figure 44). Maintenance managers also have this capability via GUI 3601 (Figure 44). Programmer mode is a development mode for building, modifying, or enhancing the vehicle-level failure prediction system 3600.

[0096] Figures 36 and 37 are block diagrams of an exemplary vehicle-level fault prediction system 3600. The system collects vehicle-level data, improves onboard fault prediction models, and generates component maintenance metrics to enable determination of whether maintenance is required for common components of all similar aircraft. System 3600 provides a dynamic predictive maintenance schedule for maintenance tasks that can be performed by certified technicians. As used herein, “vehicle-level data” refers to data from multiple similar types of aircraft. Naturally, data from multiple different vehicles can be collected and analyzed at the vehicle level. Data interface 3625 provides a communication interface (API) for receiving data from different input devices. Communication channel 3605 represents data transmitted wirelessly (via tactical communication link) from the vehicle / aircraft's onboard embedded avionics fault prediction engine to System 3600 operating on a ground-based server. All aircraft have this engine operating on an avionics mission computer or a separate IVHM computer located in the avionics bay. COMMS 3605 is a set of multiple communication channels available to all vehicles of the aircraft. System 3600 is designed to receive data from all of these communication channels. "Similar aircraft / similar type aircraft" refers to aircraft of the same model and specification category. For example, the same military aircraft, e.g., the F-35A designated for use by the U.S. Air Force, may have different components and capabilities than the F-35B and F-35C designated for use by the U.S. Navy. In such a situation, one group of "similar aircraft" (vehicles) includes F-35A aircraft designated for use by the U.S. Air Force, another group of similar aircraft includes F-35B aircraft designated for use by the U.S. Navy, and yet another group of similar aircraft includes F-35C aircraft designated for use by the U.S. Navy.On the ground, aircraft data can be transferred via an umbilical cable (network cable) connection 3610, or by removing hot-swappable solid-state drives (SDDs) 3615 from the aircraft, physically transporting them to a maintenance control center, and passing the data to the vehicle-level fault prediction engine 3600 via an SSD drive receptacle 3620. The data interface 3625 accommodates the format associated with receiving input data from different data rates and sources (when connected to the aircraft communication link). Input data received from the aircraft identified by the data interface 3625 includes timestamped sensor data with an existing header (metadata) to identify the specific component / aircraft tail number from which the data was received. The input data also includes analysis data tagged to identify the relevant component / aircraft tail number generated by the onboard MBR diagnostic engine 106(14), and analysis data tagged to identify the relevant component generated by the onboard fault prediction system 2600. This data is stored in the storage 3626 database via two paths. 1) When the aircraft is operational and transmitting data via a radio communication link, the data interface module 3625 receives the data and passes it directly to the data distribution module 3630, which stores this data in the data storage 3626 database. 2) When the aircraft is on the ground, for example during post-flight operations, data is passed via manual transfer 3615 to the vehicle failure prediction system 3600 via the umbilical cable connection 3610 or the SSD drive receptacle interface 3620, then to the data interface module 3625, and finally to the data storage 3626 database. Requests made from the data distribution module 3630 to storage 3626 retrieve newly stored data from the data storage 3626 module for offline use.

[0097] Models, algorithms, and components are mapped in triplets of (one, one, one), (one, many, one), or (one, many, many). Mappings (one, many, one) and (one, many, many) occur when components are similar / identical and multiple algorithms can produce accurate results for the components. It should be noted that in this mapping model, there is always only one (i.e., combination of three-tier models) associated with a component. This enables automatic selection of model-algorithm components in the failure prediction model module 3640. The data distribution module 3630 retrieves data from the storage module 3626 database (having access to database triggers that enable automatic data pulling when new data arrives) and delivers the "retrieved" data to the failure prediction model module 3640 analysis system. Module 3640 applies to the components of algorithm module 3670 and selects the appropriate three-tier model specific to the component using the appropriate algorithm selected from the algorithm library 3680. This enables the model-algorithm component system to perform failure prediction for the components. The data distribution module 3630 transmits raw data to the automated logistics environment (ALE) modules 3800 and 3830. The failure prediction model module 3640 has a mapping of algorithms related to the component models. Each component has an individually tailored algorithm (for example, an electronic system does not have the same algorithm as a mechanical or structural system). Within the failure prediction model module 3640, the data is further distributed to the physical-based failure prediction model 3641, the empirical failure prediction model 3642, and the data-driven failure prediction model 3643. Similarly, the failure prediction algorithm module 3670 consists of the physical-based module 3671, the empirical module 3672, and the data-driven module 3673. Data is transmitted from module 3641 to module 3671, and the cumulative model residuals are transmitted from the residual distribution module 3650 to module 3671.This is done in the same manner for modules 3642, 3672, and 3650, as well as modules 3643, 3673, and 3650, respectively. The processing and operation of these modules are substantially the same as those described for module 2630 (in Figure 27), namely the corresponding models: the physical-based model module 2710, the empirical model module 2715, and the data-driven functional physical system model module 2720. The failure prediction model used in module 3640, shown in Figure 36, functions to provide failure predictions for each of the similar components located in multiple similar aircraft, so that the relative performance of each of the similar components can be compared to the collective performance (mean, median, etc.) of other similar components with respect to the data received from data distribution module 3630. Similarly, the algorithm used in module 3670 functions to provide an algorithm for the three-tier model of module 3640 for each of the same components located in multiple similar aircraft, so that the relative performance of each of the similar components can be compared to the collective performance of other similar components with respect to the data received from data distribution module 3630. The various models of the failure prediction model module 3640 and the failure prediction algorithm module 3670 are stored in the model library DB 3660 and algorithm library DB 3680, respectively, and retrieved for use based on the specific component data being evaluated. The residual distribution module 3650 improves the accuracy and precision of the prediction results and continuously refines both the models and algorithms. The improvements are stored in the model library DB 3660 and algorithm library DB 3680 for the models and algorithms, respectively. As described in system 2600, non-zero residuals indicate degradation events that are subsequently confirmed by the parameter performance estimation module 2755. This is substantially the same process used in system 3600.

[0098] Figure 41 shows the design, training, and improvement of a vehicle-level failure prediction system. In design mode, the modeling engineer 4310 uses graphical user interfaces 4315, 4325, and 4335 to input changes and modifications to the physical-based model, data-driven model, and empirical model of the target component, respectively. For example, each model 4320, 4330, and 4340, which can be stored in the Predictive Model Markup Language (PMML) including modifications, is then stored in the failure prediction model library 4350. Similarly, the algorithm engineer 4370, utilizing the algorithm development interface 4375, can input modifications to each algorithm in programming files 4380, for example, as Java® files, JNI files (an interface between Java® and C++ data structures), and C++ files. The updated programming files 4380 are stored in the algorithm library 4385.

[0099] The test manager 4355, utilizing models from the failure prediction model library 4350 and corresponding algorithms from the algorithm library 4385, can test prediction accuracy based on simulated or recorded flight data from the storage database 4360 (flight data migrated from 3626 storage (Figure 36)). The results of regression tests and accuracy tests are stored in results 4365, which are used by the algorithm refinement and training module 4395 to improve accuracy by modifying the corresponding algorithms stored in the algorithm library 4385, and also by the model refinement and training module 4390 to improve the accuracy of the corresponding models stored in the failure prediction model library 4350.

[0100] In design mode, the user has the ability to select analyses of similar components across similar aircraft and time horizons (hours, months, years, and decades) via a graphical user interface (GUI) and appropriate component algorithms. These selections may be described as XML files containing ANSI SQL statements for component models and algorithms, and stored in the databases of failure prediction model library 4350 and algorithm library 4385. The embedded SQL statements in the XML files enable the automatic extraction of data from various databases when executed by test manager 4355. The XML files become script files for performing reproducible tests. Automated script file tests are crucial for regression testing of models and algorithms applied to the component under test. These are easily updated for new parameter improvements, while old parameters are stored in the XML files. <histories>< / histories> It is retained under the label. In operating mode, in system 2600, the failure prediction model and corresponding algorithm configuration files are transferred to the aircraft (the model database is migrated) and stored in the aircraft in failure prediction model DB 2635 and algorithm 2668 files, respectively. Similarly, in system 3600, these are stored in model library DB 3660 and algorithm library DB 3680 and used for processing in failure prediction model module 3640 and algorithm module 3670. Vehicle-level analysis proceeds further in damage estimator module 2625 operating on vehicle data in the same manner as described for damage estimator module 3674 operating on onboard system 2600 data (similar processing control taken from system 3600 by modifying the communication line 2600 of system 2600). Similarly, vehicle-level analysis proceeds with a state predictor module 3675 operating on vehicle data in the same manner as described for the state estimator module 2670 operating on onboard system 2600 data (with similar processing control taken from system 3600, including SOH calculations within system 2600 and modifications to the communication line 2600).

[0101] The algorithm library DB 3680 stores all algorithms developed for all components on an aircraft where performance analysis is available. The algorithms used in algorithm module 2668 are a small subset of the complete set of algorithms developed for the vehicle-level fault prediction system 3600 (i.e., neural networks, Kalman filters, and particle filters that are efficient and fast for onboard processing). Some of these algorithms applied to specific components include logistic regression, linear regression, time series, symbolic time series, random forests, decision trees, moving averages, principal component analysis (PCA), support vector machines (SVN), Markov chains, Bayesian methods, Monte Carlo methods, neural networks (many of them), particle swarm optimization, various filters (Kalman filters and particle filters), fast Fourier transform (FFT), gradient and Ada boost, wavelets, genetic, natural language, clustering, classification, learning and training, and data mining.

[0102] The output from the damage estimator module 3674 is provided as input to the analysis fusion module 3690, which is shown in more detail in Figure 38. Note that the processing of the damage estimator module 3674, the state estimator module 3675, and the alarm generator module 3676 is substantially the same as the corresponding functions of systems 2600 and 3600. The state predictor module 3675 is enhanced for SOH calculations in system 3600, thereby providing an additional communication link (via COMMS 3605) for both modules 3674 and 3600 to transmit their analysis results to system 2600 when both systems 2600 and 3675 are operating with COMMS 3605 active. These modules provide information to the aircraft flight control system (FCS) for possible hardware and software reconfigurations (described later). Similarly, in system 3600, both modules 3674 and 3675 are optimized from short-term horizons (longer than one day) to long-term horizons (less than 50 years or more than 50 years, depending on when the aircraft's vehicle becomes obsolete). In system 2600, these modules function in the short-term horizon, depending on the aircraft's mission flight time (from takeoff to landing). The analysis fusion module 3690 fuses the analysis outputs and associated data from module 3674 for all similar components for all similar aircraft within a selected analysis time horizon (e.g., durations of hours, days, months, years, or decades). The data fusion module 3691 (Figure 38) operates in a similar manner to the data fusion module 1170 in Figure 26, mapping and averaging the input outputs from the damage estimation module 3674 predictions within a travel time window correlated to appropriately tagged components or groups of similar components.Module 3691 transmits tagged alarms to alarm generator 3676 (which functions similarly to alarm generator 2645 but is optimized for vehicle-level calculations), and these alarms are then registered to the mission operator dashboard 3785 when connected to COMMS 3605 in mission operator mode, and to the maintenance manager dashboard 3790 in maintenance manager mode. Module 3691 also transmits data and analysis to condition predictor module 3675 (enhanced and optimized for vehicle-level calculations, including SOH calculations), which performs the same tasks defined earlier, but in analysis fusion module 3690, it also calculates and predicts the state of health (SOH) indicators for components in 4405 (Figure 42). RUL and EOL are calculated by damage estimation module 3674 and are the state of components (abnormal behavior) (fault / fault, fault isolation, false alarms, and root cause analysis are obtained from MBR diagnostic engine 106(14)). The abnormal behavior data and analysis obtained from the MBR diagnostic engine 106(14) are then stored in the analysis data repository 3710 and used for metric calculation in metric 3740 and report generation in report 3750, respectively.

[0103] The output from the analysis fusion module 3690 is provided as input to the metrics module 3740, which provides grouping of information on a user-selectable basis. For example, the GUI 4400 in Figure 42 shows various user-selectable criteria that can be used to sort the information provided by the analysis fusion module 3690 into selected failure prediction reports 4405, maintenance schedule reports 4410, or QoS reports 4415 generated by the reporting module 3750. Note that the metrics and reporting functions shown in Figure 28 are a subset of those shown in Figure 42. In addition to the failure / degradation and quality of service (QoS) criteria shown in Figure 42, various types of maintenance reports, such as scheduled maintenance, preventive maintenance, predictive maintenance, and corrective maintenance, can also be selected by the user and generated for viewing (within the mission dashboard 3785 and maintenance dashboard 3790) and printing (print function print module 3795). An existing time horizon for performing predictions is shown in 4420. This can be updated via button 4440 for short (up to 1 day), medium (several months), and long (several decades) horizons. Reports can be generated for a single aircraft 4425, a subset of aircraft 4430, or all aircraft 4430. Button 4435 allows you to search for existing stored forecasts that have been run previously and make adjustments to obtain better reporting results. Button 4445 allows you to print the selected report, button 4450 saves the report and forecast, and button 4455 exits the report screen.

[0104] Figure 43 shows an exemplary predictive maintenance schedule 4500 generated by the electronic component reporting module 3750 (Figure 37). The State of Health (SOH), Remaining Service Life (RUL), and End of Life (EOL) metrics for one or more similar components are grouped into the metrics module 3740 (obtained from the damage estimation module 3674 and the condition prediction module 3675) and sent to the reporting module 3750 for generating reports and for storing the metrics and reports in the failure prediction results DB 3760. All other metrics shown in Figure 42 for reporting purposes are calculated in the metrics module 3740 using current data and current analysis obtained from the module analysis data repository 3710 and the failure prediction results DB 3760. At the user's discretion, viewing and printing metrics and reports is achieved by querying the failure prediction results DB (Figure 37) for existing data (not new) and existing metrics, reports, and data (data from the analysis data repository 3710) with the correct existing parameters selected by the user. Otherwise, new metric forecasts and reports are generated on the fly for new data and new parameter options and stored for later use upon user request. Data from the analysis data repository 3710 and the failure prediction results DB module 3760 can also be visualized concurrently with existing metrics and reports, respectively, or generated together as a new report.

[0105] Figure 43 shows chart 4500 with graph 4505 above and graph 4510 below, each having the same x-axis timeline but different y-axes, with RUL / EOL as a percentage on the y-axis in chart 4505 and arbitrary y-axis (i.e., arbitrary height of the bar graph for visual impact) in chart 4510. Graph 4505 shows line 4515 representing the predicted RUL of the component in question, which is declining with a downward slope increasing from 100% in January to 75% in April. The increasing downward trend is a cause for concern from a maintenance perspective and, in some cases, a concern of critical failure of the component within days. Line 4520 represents one forecast made for line 4515 in April based on a further increasing downward trend, and line 4525 represents another forecast made for line 4515 in April based on a smaller downward trend. Line 4520 represents 0% RUL in May, and line 4525 represents 0% RUL in June, with 0% RUL representing a potential critical failure. The duration between lines 4520 and 4525 is called the uncertainty period (or uncertainty envelope). Based on these forecasts and a predetermined threshold amount, e.g., 30% RUL, which can change with changes in the amount and slope of the RUL forecast for a particular component, the need for maintenance is indicated based on these actual-condition forecasts before a fixed, predetermined maintenance schedule interval, such as a scheduled maintenance interval generated by logistics engineering via reliability-centered maintenance (RCM) analysis. 0% RUL indicates the end of life (EOL) of the component. Graph 4510 shows the predicted maintenance scheduled during the interval 4535 immediately preceding the beginning of May, based on the forecasts in Graph 4505. This is in contrast to the logistics engineering planning a pre-scheduled maintenance interval 4540 for the component between October and November. Furthermore, please note that if line 4530 does not experience 4535 predictive maintenance events based on the status of its components, it will align with line 4520 or line 4525 (EOL with 0% RUL).If predictive maintenance 4535 occurs, the impact on line 4515, i.e., line 4530, indicates a significant increase in the lifespan of the component in question, while benefiting from increased aircraft operational efficiency. Button 4545 provides display of previously stored graph data and predictions, button 4550 stores the current graph data and predictions for later use, button 4555 prints the current graph, and button 4560 exits the current screen.

[0106] The historical and training data database 3730 contains historical data collected from the analysis of data associated with all components analyzed during online and offline operation. The training system module 3720 periodically updates the algorithms used by the analysis fusion module 3690 using the data contained in the database 3730 to provide more refined and accurate analysis.

[0107] The analysis data repository 3710 contains all previously analyzed data from the MBR diagnostic engine 106(14), the onboard PMBR of the fault prediction engine 2600, and the PMBRGCS (ground-based vehicle-level fault prediction engine 3600). This information is made available to the analysis fusion module 3690 to help improve the accuracy of the analysis and to provide access to this information by the metric module 3740 for the generation of user-selected reports by module 3750. Analysis performed by module 3690 is also sent to the database 3710 to be integrated with historical data information. Database 3710 also communicates with the algorithm library database 3680 to allow for continuous improvement of the algorithms. Improvements to both models and algorithms can be performed autonomously online or offline in the training system module 3720 (since module 3600 runs on a ground-based server and is not a flight or mission-critical system for aircraft operations). These improvements provide data and analysis received from module 3690 for cumulative analysis in module 3720, receive data from module 3710, and receive data and analysis from modules 3770 and 3780. The training algorithm for module 3720 is obtained from the algorithm library DB 3680. Using data from the historical database, high-fidelity improvements can be made in combination with the moving average algorithm for existing analysis and the principal component algorithms for parametric and BIT data of other modules (described above), and can be stored for performing analysis of the next data of similar components in the historical and training data DB module 3730. In addition, the failure prediction accuracy and algorithm tuning / training module 3770 provides interactive communication with the algorithm library database 3680 and provides input to the analysis data repository 3710. Module 3770 provides continuous accuracy updates that are reflected in modifications to the corresponding algorithms used for analyzing component data.Similarly, module 3710 also communicates with the failure prediction model tuning and training module 3780, which in turn communicates with the models stored in the model library database 3660.

[0108] The failure prediction results database 3760 receives and stores user-selected metrics and data from the metric module 3740 and corresponding reports from the report module 3750. The database 3760 also communicates with the analysis data repository 3710, which provides access to the analyzed data. The database 3760 also provides information to the mission dashboard 3785 and the maintenance manager dashboard 3790. The mission dashboard 3785 is accessible in mission operator mode (role-based access) of the operational vehicle-level failure prediction system 3600. It provides access to all operational and ground-based aircraft situation awareness, as well as all menus and buttons in the vehicle-level failure prediction system 3600 GUI module 3601, except for the model design function. Similarly, the maintenance manager dashboard 3790 is accessible to maintenance managers in maintenance manager operating mode or in the maintenance manager role. Maintenance managers can access all menus and buttons in the GUI 3601, except for the model design function. The output from each of these dashboards is provided to the print function module 3795 when the print button is clicked in GUI 3601, which then provides print output of the items selected on the dashboard (see Figure 44).

[0109] In this exemplary embodiment, data from the data distribution module 3630 is provided to the Organic Automated Logistics Environment (ALE) (i.e., Maintenance and Support System) 3800 and ALE Contractor Logistics 3830. The output from module 3800 is provided to the data mining module 3810, which selects data for storage and extracts data for use from the database farm 3820. Similarly, the output from module 3830 is provided to the data mining module 3840, which selects data for storage and extracts data for use from the database farm 3850. The ALE Maintenance and Support System (logistics operations for both the military and its contractors) provides enterprise-level applications necessary for maintenance functions such as three levels of maintenance, repair and / or replacement, and overhaul, as well as other organizational functions such as supply chain functions for inventory management, spare parts and parts ordering. The Vehicle-Level Fault Prediction and Diagnostic System 3600 provides diagnostic and fault prediction data and analysis to these ALEs. Figures 39A and 39B are flowcharts 4100 illustrating how vehicle-level component performance metrics are used to improve the accuracy of models and algorithms used for performance evaluation of both onboard components (system 2600) and offboard components (system 3600), as well as for improving the associated models and algorithms. Flowchart 4101 defines the training and learning performed to improve models and algorithms using the integrated development environment (IDE) system shown in Figure 41. Note that the descriptions provided below are equally applicable to both model improvement and algorithm improvement. The collected raw data in storage 3626 or data farm 3850 is extracted in step 4105 via a data mining algorithm that searches for aircraft and similar aircraft component metadata (i.e., suffix numbers) within the stored files. Data farm 3820 is generally not available to the military contractor that built the system; it is only available to the military branch that owns the system.In step 4110, the parameters and parameter feature extraction of constituents and similar constituents using classification and machine learning algorithms are performed on this data (i.e., the data is preprocessed). Generally, there is enough data collected over the entire operating time interval of the aircraft that even if there is a small amount of missing data, it will not negatively affect the analysis. In step 4115, statistical sampling filter algorithms are used to select, manipulate, and analyze constituents and similar constituent parameters of representative sets of the training and test datasets to identify patterns and trends in the larger dataset under examination, as shown in step 4120 for the training dataset and step 4125 for the test dataset. In step 4130, the training dataset 4120 undergoes further preprocessing for feature selection, scaling, and dimensionality reduction. Feature selection is the process by which the training dataset undergoes feature exclusion, i.e., the exclusion of outlier data, reducing undesirable features in the dataset that could lead to inaccurate analysis. Dimensionality reduction transforms the dataset into a lower dimensionality, providing rapid pattern recognition and reducing the complexity of the resulting computation. Scaling can be used to improve the numerical stability of both algorithms and models that have a scaling factor between a minimum and maximum value (generally between zero and one). This data is also added to the test dataset 4125 to provide finer refinements. In step 4135, the training dataset is used to train a machine learning algorithm to find the most accurate features and patterns to refine the 3-layer model parameters and algorithm parameters associated with the model. These parameters are further optimized in step 4140 through parameter optimization by weighted sampling of data from historical and current datasets that best describe the 3-layer model and their algorithms. In step 4145, the post-processing and decision time, RUL, SOH, and EOL are calculated and compared to historical and current aircraft flight data results. If these are far from already available values, for example, greater than 10%, refinements continue in step 4130.If the value is close to an already available value (but not close enough, e.g., greater than 1% but less than or equal to 10%), the refinement continues in process 4135. After n refinements, if the value does not change much, e.g., within 1%, the final model and algorithm parameters and metrics are stored in the new data in process 4155, the new parameters are added to the test data in 4125 and also stored in the new data in 4155. The new data in 4155 refers to the failure prediction model library in database 4350, the algorithm library in 4385, and the results in 4365 (for the refined test dataset and metrics) in Figure 41. These databases (4350, 4385, 4365) are then migrated to the 3660 model library DB, 3680 algorithm library DB, and 3740 failure prediction results DB of the vehicle-level failure prediction system 3600, respectively. Similarly, these databases (4350, 4385, 4365) will be migrated to the onboard system 2600, with 2635 failure prediction model DBs, 2668 algorithms (subset algorithms only), and 2655 analysis data, respectively. Migrating the 4350, 4385, and 4365 databases to systems 2600 and 3600 will achieve improved accuracy and refinement of the models and algorithms.

[0110] In operating state 4102, the model and algorithm database in process 4165 references databases 3660 (model library DB) and 3680 (algorithm library DB) within system 3600, respectively. Processes 4170 through 4185 are parallel processes to existing processes occurring in 3770 (failure prediction accuracy and algorithm tuning and training) and 3780 (failure prediction model tuning and training) for algorithms and models, respectively. This occurs only when new data arrives for parameter performance tuning and model and algorithm improvement (if COMMS 3605 is active and sending data to system 3600, otherwise existing data in 3626 storage is used). The initial analysis and data are extracted by the learning and training algorithms of the training system in process 4101 described above. When new data arrives, the sensitivity and specificity of the model analysis are initiated in process 4170. For models, this analysis searches for changes in model output values ​​resulting from changes in model input values. It also determines the uncertainty of the model parameters from input to output result. The algorithm's sensitivity checks the degradation rate of "true positives," and the algorithm's specificity checks the degradation rate of "true negatives" that are correctly identified. The rate of true negatives tends to decrease the rate of true positives when taken for an entire set of similar components on an aircraft. Sensitivity and specificity improve accuracy in RUL, EOL, and SOH measurements. Step 4175 determines the uncertainty of the metric calculation to, for example, ±5%. If this percentage is greater than the set amount, step 4170 is restarted; otherwise, the process proceeds to verification and validation testing in step 4180. In step 4180, regression tests are performed (existing successful test scripts are executed) and compared to previous test results. If these test results pass in step 4185, the new analysis and data are sent to the database in step 4101 for storage and future processing. If these test results do not pass, the analysis and processing return to step 4170, and the process continues as described above.

[0111] Figure 40 is a flowchart illustrating how vehicle-level performance metrics for components are used to determine when a single / all similar components within an aircraft vehicle require maintenance / simultaneous maintenance. There are two modes: 1) autonomous mode and 2) offline mission operator / maintenance technician mode. Autonomous mode is activated when COMMS 3605 is active and the server button on 3601 is clicked "on," enabling a handshake between system 3600 and COMMS 3605 via a software socket connection. Real-time data transmission from COMMS 3605 to data distribution module 3630 validates the automated mode (i.e., incoming data is the trigger). In autonomous mode, if degradation / fault / failure event alarms exist, these are visualized on screen 3605 (Figure 44) for a specific aircraft tail number as follows: gray for "ground-based" aircraft, green for "fully mission-ready (FMC)", orange for "partially mission-ready (PMC)", and red for "non-mission-ready (NMC)" (i.e., a table for all similar aircraft). Further action requires intervention from the mission operator. Note that PMC means the aircraft can still perform its mission in degraded mode. NMC, on the other hand, means the aircraft will enter recovery mode (flight termination sequence), i.e., return home as quickly as possible, land in a safe location, or crash. The operator can click on rows that are orange or red (i.e., each row on screen 3605 is information about an aircraft with a unique tail number, either operational or on the ground). When a row is clicked, another details screen provides visibility of all material assets on that particular aircraft, along with their associated metrics obtained from metric module 3740. Low RUL and SOH percentages motivate mission operators to view predicted maintenance schedules by simply clicking on degraded asset rows to display a screen like the one shown in Figure 43.In offline mission operator / maintenance technician mode, the data collected in storage 3626 is used to perform the same operations as above, but offline by clicking the “Run Prediction” button in 3601, or by clicking the aircraft (row) in 3605 and then the asset row, as described above, to view the results in Figure 43, i.e., to determine further actions to take. The predicted maintenance schedule shown in Figure 43 for degraded assets depends on the flow chart shown in Figure 40.

[0112] Figure 43 shows the case where, for each decision in the decision shape 4230 of Figure 40, predictive maintenance occurs "before" the pre-planned scheduled maintenance. A work order is issued to the maintenance staff in step 4235. The "later" predictive maintenance schedule has the effect of moving the planned and scheduled maintenance line 4540 (in step 4245) above the predictive maintenance schedule line 4535. In both the "before" and "later" cases, the training system module 3720 (updating the history and training DB 3730) and the failure prediction results DB 3760 are updated via step 4240. Step 4200 receives input from modules 3660, 3680, and 3760, calculates RUL, EOL, and SOH in modules 3674 and 3675, and identifies degradation events and component performance degradation. Modules 3690 and 3740 provide essential processing in processes 4210 and 4215, while processes 4220, 4225, 4230, 4235, 4240, and 4345 are calculated in report module 3750 for predictive maintenance schedules and pre-planned scheduled maintenance, respectively. The graphing trigger capability shown in Figure 43 is present in report module 3750 via print function 3795, as well as in other modules that may require graphing capabilities.

[0113] State of Health (SOH) is a percentage score that depends on the relevant physics, chemistry, and / or biology (i.e., biotechnology) of the components. For example, the SOH of a battery is the maximum remaining capacity C in the i-th cycle. i It is estimated by dividing it by the nominal capacity C0.

number

number

number

number

number

number

[0114] In process 4635, the critical crack length L at which structural failure is predicted is critical A determination is made as to whether or not the critical length L of a crack that could cause structural failure is reached. If the YES determination is made in step 4635, an alarm is generated on the mission dashboard in step 4640. critical Since this has been determined, the generation of the alarm is appropriate. The critical crack length L is predicted to cause a structural failure. critical The NO determination by step 4635, indicating that the condition has not yet been reached, is followed by updating the crack parameters, sensor parameters, new environmental conditions and mission profile, and new usage parameters in step 4645. Following this update, another calculation iteration is continued in step 4650 by returning to step 4615, so that a further decision can be made by step 4635 based on the new information.

[0115] Figures 46A and 46B are graphs of the maintenance characteristics versus time of the components. Module 3800 represents the military's organic maintenance and support system used for generating maintenance task orders, performing (at least) intermediate levels of maintenance (Level I), supply chain and inventory management, etc. Module 3830 represents the defense contractor's maintenance and support system. The defense contractor may be required by the organization operating the aircraft to perform Level D (i.e., storage level maintenance), and the organization may then require its suppliers and manufacturers to perform Level D maintenance. Level O maintenance is provided by the organization operating the aircraft (i.e., the military) along with technical data and possibly services provided by the aircraft contractor or developer (i.e., the contractor team may be integrated into the military). Various types of maintenance are shown in Figure 46A as probabilities of “performance state” versus “time” on the y-axis, ranging from 100% performance to near 0% performance, indicating corrective maintenance and reflecting the end-of-life (EOL) of components (where very expensive component overhauls may be performed while the components remain operational). For maintenance purposes, the remaining service life (RUL) and remaining service life (RUP) of components / line replaceable units (LRUs) should be maximized while avoiding unscheduled maintenance. The definitions of the terms shown in Figure 46A are defined below. [Table 4-1] [Table 4-2] From this graph, it is clear that when a potential failure 4710 occurs, the component often has a substantial RUL beyond the scheduled time for preventive maintenance 4715, making preventive maintenance 4715 typically less cost-effective in practice, while adding more costs than predictive maintenance 4730. Therefore, using predictive maintenance with maintenance based on actual performance results in a longer operational life for components, thus minimizing component replacement / repair costs, as well as labor costs for performing maintenance while keeping the aircraft operational for a longer period. In Figure 46B, the dashed line 4755 represents the zero maintenance value 4750. This value represents the transition point between Average Logistics Delay Time (MLDT) and Average Repair Time (MTTR) (due to aircraft downtime with work orders for unscheduled maintenance of the aircraft) and the ready-to-operate state 4755. MLDT can be due to various delays in management operations, lack of means of transport or long time for round-trip transport, and other reasons. Once the MLDT is resolved, an additional MTTR is required to perform maintenance repair or replacement operations. Note that the positive peaks and direct drops to zero in Graph 4760 generally represent components approaching End-of-Life (EOL), which may lead to unscheduled maintenance (a complete overhaul of expensive components).

[0116] In Figure 48, fault management 4910 consists of diagnostics and supervision 4905 (fault detection, fault isolation, false alarm rejection, and root cause analysis) and failure prediction 4915 (degradation analysis and metric calculation: RUL, EOL, SOH for aircraft equipment health), as well as various interrelated maintenance actions, procedures, and reconfigurations (all 4920 through 4999). It is important to understand that high-fidelity and accurate diagnostics and failure prediction have a significant impact on component and aircraft maintenance, repair, and overhaul (MRO) activities. Accurate fault and failure isolation, false alarm rejection, and equipment degradation determination reduce maintenance workload, reduce operational vehicle load on aircraft, and help with decades of operational costs by eliminating up to 50% of the cost burden (significant over decades) with accurate diagnostics and failure prediction. The vehicle-level failure prediction diagnostic system 3600 analyzes, calculates, stores, and reports for each of these various maintenance functions. The maintenance procedures 4920 are categorized into scheduled maintenance 4935 and unscheduled maintenance 4940. Scheduled maintenance 4935 is further classified into preventive maintenance 4950, predictive maintenance 4955, corrective maintenance 4960, and on-demand maintenance 4965 (referring to the execution of urgent and mill maintenance when necessary). Similarly, unscheduled maintenance 4940 is classified into reactive / emergency maintenance 4970. Blocks 4950-4965 are each associated with their typical maintenance actions performed by certified technicians in blocks 4991-4994 for scheduled maintenance 4935. Reactive / emergency maintenance 4970 has its reference maintenance action block 4995. The key difference between reactive / emergency maintenance 4970 and on-demand maintenance 4965 is that reactive / emergency maintenance includes planned maintenance tasks in conjunction with the need for reactive / emergency, whereas on-demand maintenance tasks may result in ad-hoc time interval maintenance not being planned (e.g., the best available time).The replacement / repair task 4925 is categorized into scheduled / planned repair 4975 and unscheduled / unplanned repair 4980. Blocks 4975 and 4980 have associated maintenance operations 4996 and 4997, respectively. The aircraft flight control system is fault-tolerant and adaptively resilient, and as a result, hardware and software can be reconfigured in flight from failures by sending commands to reconfigure (e.g., stuck hardware bits, stuck switches, stuck relays, etc.). Reconfiguration 4930 performs such adaptive resilience, which is only available in fault-tolerant systems 4945 with static redundancy 4985 and dynamic redundancy 4990. Damage estimation module 3674 and state estimation module 3675 perform this reconfiguration function, which is only available in flight operation while the vehicle-level failure prediction system 3600 is operational and connected to the onboard failure prediction system 2600 via COMMS 3605. System 2600 requests additional processing from System 3600, which provides information regarding the necessary analysis and command sequence triggers. System 2600 constructs and verifies the command sequence for transmission to the aircraft flight control system (FCS). If System 3600 is unavailable for any reason, System 2600 constructs the best possible command sequence from the available information, with some uncertainty. There is a direct feedback link to System 3600 for generating a command sequence (from triggers provided by System 2600) for reconfiguring the aircraft without stopping it. However, this command sequence information is only a recommendation to the FCS. Systems 2600 and 3600 only provide situational awareness; the FCS must make the final decision on whether or not to send a reconfiguration command sequence, depending on various factors such as available hardware and software redundancy, the current mission, environmental conditions, and possible cascading failures and malfunctions (failure of one component causing failures of other components, as well as other subsystem components). Most of this information is provided by Systems 2600 and 3600.Static and dynamic redundancy are handled by the FCS. Static redundancy in fault-tolerant systems (requiring high reliability in real-time performance) generally deals with the memory correction code and majority voting scheme "m from n systems" in block 4998 (in the FCS). Similarly, dynamic redundancy requires high-fidelity and accurate diagnostics (module 106(14)), fault prediction diagnostics (modules 2600 and 3600), and redundant hardware. Computation hardware can be single, dual, triple, or quadruple redundant systems (i.e., identical in all respects). In such cases, the FCS uses a majority voting scheme among hardware outputs to determine the most likely and best outcome (i.e., single means a single point of failure, dual means a master-slave configuration where the master takes over the slave, triple means two out of three similar outcomes, quadruple means three out of four similar outcomes, etc.). In quadruple redundant hardware, the hardware complexity arises when two pairs show different results, and each pair shows the same result. Which pair should be selected? Further information / evidence is needed to select the correct pair. It becomes even more difficult when each computer shows different results. These are topics of concern in FCS, not in diagnostic and failure prediction systems. Note that the elements in Figure 48 play a role in failure prevention, fault elimination, and failure prevention through degradation-dependent redundancy (HW,SW).< / aps>

Claims

1. 1. A method implemented by a ground-based computing system, comprising: receiving performance parameter data for similar components located on a plurality of similar aircraft; determining a corresponding degradation level and degradation rate of each of said similar components; generating a vehicle-level impairment for the groups of similar components based on an analysis of the composite impairment of similar components within each group; determining at least one of a remaining useful life (RUL) and a state of health (SOH) for each of the respective similar components based on a comparison of a deterioration level of each of the similar components to the vehicle-level deterioration of the group of similar components; and determining a predicted time for maintenance for each of the similar components based on corresponding at least one of the RUL and the SOH of the similar components, thereby enabling determination of cost-effective maintenance of components based on vehicle-level information.

2. 10. The method of claim 1, wherein receiving data includes transferring data for a plurality of similar components from each similar aircraft to the ground-based computing system while the aircraft is on the ground, the data being based on component performance parameters stored in an aircraft data storage device while the aircraft is in flight.

3. 10. The method of claim 1, wherein receiving data comprises transferring data for a plurality of similar components from each similar aircraft to the ground-based computing system via a wireless communication link while the aircraft is in flight.

4. determining a corresponding deterioration level and deterioration rate of each of the similar components; determining, by at least one of a physical model of the respective similar component and an empirical model of the respective similar component, a first residual that is a difference between a current state of the performance parameter of the respective similar component and a corresponding state of the performance parameter of the respective similar component as determined by at least one of the physical model and the empirical model; determining, by the physical system model of each similar component, a second residual that is the difference between a current state of the performance parameter of the similar component and a predetermined range of states of the performance parameter of the corresponding similar component as determined by the physical system model; and determining a degradation level of the respective similar component and a degradation change rate of the respective similar component based on a combination of the first residual and the second residual.

5. generating the vehicle-level degradation for each similar component; The method of claim 1 , comprising generating a weighted average of the RUL of all like components.

6. determining the SOH for each of the respective like components; Determining the current SOH of each of the like components; and for each of the similar components, comparing a current corresponding SOH to a state of 100% performance to generate a current SOH for the similar components.

7. determining the RUL for each of the respective similar components; The method of claim 6 , comprising determining a RUL for each of the similar components based on previous determinations of the RUL for similar components and a rate of degradation of performance for the respective similar component.

8. 1. A method implemented by a ground-based computing system for improving accuracy of degradation determination of on-board components of an aircraft, comprising: receiving performance parameter data for similar components located on a plurality of similar aircraft; determining, based on the received data, a corresponding degradation level and a degradation rate of each similar component by at least two models of each of the corresponding similar components; generating a vehicle-level degradation for each group of similar components based on the degradation of similar components within each group; modifying at least one of the at least two models of similar components based on the vehicle-level degradation to improve accuracy of the at least one model; and transmitting the modified at least one model to similar aircraft, wherein the modified at least one model can be used to replace a previous version of the at least one model to generate an on-board deterioration analysis, thereby increasing the accuracy of the on-board deterioration analysis based on vehicle-level data.

Images