U.S. Army ADS-79D-HDBK — ADS-79D-HDBK.pdf

Downloaded from https://www.everyspec.com ADS-79D-HDBK c. Fault Validation: Detection algorithms should be validated to ensure that they are capable of detecting the intended faults. One common method of algorithm validation is to create (i.e. ―seed‖) a fault in a new or overhauled component or to simply use a known faulted component, and collect data on the fault‘s progression to failure in controlled testing which simulates operational use. Data collected from this test are used as source data for the detection algorithm as described in Appendix J.

Another common method of algorithm validation is to formally inspect components removed from service though normal operations and maintenance practices. If the component is determined to have a fault of interest that is desired to be detected, the field data can be used as source data for the detection algorithm. In either case, the algorithm‘s results are compared to actual component condition through direct measurement. Anomaly detection should be able to identify instances where data are not within expected values and flag those instances for further review and root cause analysis.

Such detection may not be able to isolate a single fault condition (or failure mode) to eliminate ambiguity between components in the system, and may form the basis for subsequent additional data capture and testing to fully understand the source of the abnormality (also referred to as an ―anomaly.‖). In some cases, the anomaly may be a CI reading that responds to a maintenance error rather than the presence of a fault. For example, misalignment of a shaft by installation error could be sensed by an accelerometer, with a value close to a bearing or shaft fault. CBM can also be used to control the conditions that cause the vibrations, which prevents the failures from occurring.

Detail guidance for general CIs and HIs are found in Appendix D. Because many faults are discovered through vibration analysis, guidance for vibration-based diagnostics is found in Appendix E. Operating state parameters (examples: gross weight, center of gravity, airspeed, ambient temperature, altitude, rotor speed, rate of climb, and normal acceleration) are used to determine the flight regime. The flight environment also greatly influences the RUL for many components. Regime recognition is essentially a form of State Detection, with the state being the vehicle‘s behavior and operating condition.

Regime recognition is subject to similar criteria as CIs in that the regime should be mathematically definable and the flight regime should be a unique state for any instant, with an associated confidence boundary. The operating conditions (or regime) should be collected and correlated in time for the duration of flight for use in subsequent analysis. For detailed guidance regarding regime recognition, refer to Appendix B. 5.6 Health assessment (HA). Health assessment is accomplished by the development of HIs or indicators for maintenance action based on the results of one or more CIs. HIs should be indexed to a range of color-coded statuses such as:

green (nominal – no action required), yellow (elevated advisory – watch/prepare for maintenance), orange (caution/remaining life limited - schedule and perform maintenance when optimal for operations), and red (warning/increased risk - ground aircraft/maintenance required). Each fault should contribute to the determination of the overall health of the aircraft. Status of the equipment should be collected and correlated with time for the condition during any operational cycle. HIs should integrate with the existing maintenance and logistics information systems. This integration extends to Interactive Electronic Technical Manuals (IETMs) where applicable. 5.7 Prognostics assessment (PA).

Using the description of the current health state and the associated failure modes, the PA module determines future health states and RUL. The estimate of RUL should use some representation of projected usage/loads as its basis. RUL estimates should be validated during system test and evaluation, and the estimates should show 90% or greater accuracy to the failures 23