Downloaded from https://www.everyspec.com ADS-79D-HDBK communication bandwidth and reasonable search technology constraints which limit file transmittal to approximately one megabyte of data per flight hour. Therefore, National Level data transfer should be limited to transmission of only processed CBM metrics and not raw, high-speed sampled sensor measurements. However, Web site archival storage should be sized to capture all collected data including unprocessed, sampled sensor measurements for later use in refining and developing new condition indicators.
For detailed guidance on the practical limits of data acquisition and handling with regard to Regime Recognition and Vibration refer to the discussion and tables found in Appendices B and E. 5.4 Data manipulation (DM). Data manipulation, also referred to as signal processing, should be governed by best practice throughout the data processing steps. Standardizing a specific set of practices is ineffective as each application requires techniques best fitted to its particular needs.
Each set of resultant files, from raw data to processed data to State Detection to Health Assessment, should be linked to each other to demonstrate a ―chain of custody‖ and also to indicate which set of algorithms were used. As CBM is a dynamic and evolutionary system, the outcome of State Detection, Health Assessment, Prognostics Assessment, and Advisory Generation is dependent upon the software modules used. Traceability of this software is essential for configuration management and confidence in the result. Detailed guidance for data integrity and data management is referenced in the Data Integrity Appendix (Appendix L). 5.5 State detection (SD).
State Detection uses sensor data to determine a specific condition. The state can be ―normal‖ or expected, an ―anomaly‖ or undefined condition, or an ―abnormal‖ condition. States can refer to the operation of a component or system, or the aircraft (examples, flight attitudes and regimes). An instance of observed parameters representing baseline or ―normal‖ behavior should be maintained for comparison and detection of anomalies and abnormalities. Sections of the observed parameter data that contain abnormal readings which relate to the presence of faults should be retained for archive use in the knowledge base as well as for use in calculation of CIs in near real time.
The calculation of a CI should result in a unique measure of state. The processes governing CI and HI developments are: a. Physics of Failure Analysis: This analysis determines the actual mechanism which creates the fault, which, if left undetected, can cause failure of the part or subsystem. In most cases, this analysis is to determine whether material failure is in the form of crack propagation or physical change (example: melting and embrittlement). This analysis determines the means to sense the presence of the fault and evolves the design decisions which place the right sensor and data collection to detect the fault. b. Detection Algorithm Development (DAD):
The process of detection algorithm development uses the Physics of Failure Analysis to initially select the time, frequency, or other domain for processing the data received from the sensor. The development process uses physical and functional models to identify possible frequency ranges for data filtering and previously successful algorithms as a basis to begin development. Detection algorithms are completed when there is sufficient test or operational data to validate and verify their performance.
At a minimum, systems‘ underlying algorithms for flight critical applications should provide a 90% probability in detection of incipient faults and also have no more than a 10% false positive rate (indications of faults that are not present). Further details are found in Appendices D and I. For non critical applications, the probability of detection and false positive rate may vary significantly lower than 90% POD and higher than 10% PFA depending on what additional maintenance associated with false positives is acceptable to the maintainer and platform manager. 22