ADS-79D-HDBK Downloaded from https://www.everyspec.com Sub-Section 6 figure), for acquiring Maintenance Credit for a component using the Mechanical Health approach. K.5.1.1 Mechanical Health Credit Verification Process. In this section, a detailed view of the Mechanical Health Credit Verification process (Figure K-6) is provided. This process also discusses certain development steps needed to have a successful verification. The entry criteria for starting the health credit verification process are: 1) that the candidate system must be installed on the target aircraft platform; and, 2) that the candidate system must have collected data for the credit-seeking component.
This data can be collected from different hardware and software versions at an overall system level, as long as the different versions do not affect the incoming data for the target component. For example, say that a HI- based maintenance health credit is being sought for a bearing. Furthermore, the HI-algorithm fuses the four bearing energies (inner race, outer race, ball and cage) and provides a normalized value for health. So the data collected in this case would be the bearing energies. Let‘s also assume that the overall system has undergone various changes. As long as the system changes do not affect the bearing energies, it is appropriate to use them for HI development.
If, however, the system level changes do affect the bearing energy data, then the HI development process can only use the data from the point in time where the change was fielded. If such a situation arises, analysis should be performed to assess the appropriateness of the data. This is to ensure that the development and verification steps that follow will be specific and accurate for the target platform. If these criteria are met, the next step is to obtain the collected data. At this point it is important to determine whether sufficient data is available. The determination methodology needs to be approved by the aviation authority.
If the results of this analysis prove that a sufficient amount of data is present, then the existing database can be used for development and verification. If the results, however, prove that the amount of data is insufficient, then the decision needs to be made whether the potential risk of inaccurate development can be mitigated by either additional testing or by obtaining more data. If the ―Design Additional Testing and Approval‖ path is picked, then the existing database can be used for development and verification, as long as additional tests are designed and approved by AED.
On the other hand, if the ―Obtain Additional Database‖ path is chosen, then the additional data need to be gathered and reanalyzed for sufficiency. Once the database to be used is determined, metrics such as Probability of Detection (POD) and Probability of False positive (PFA) need to be determined. Depending upon the severity established for the component, follow the CI/HI guidelines as outlined in Appendix D of ADS-79D, ―Minimum Guidance for Determining CIs/HIs for Propulsion Systems,‖ to determine the POD and PFA. This will lead to the development of CI & HI thresholds and algorithm that should be treated as requirements.
Next, capture these requirements in a Configuration Specification Document. Upon completion of the Configuration Specification Document, the algorithm and configuration can be implemented. 202