LRCM – Reporting failure modes of rotable components

Living RCM demands that the technician transmit accurate, consistent information regarding the failure mode(s) found during the execution of a work order. But what if the technician does not know which failure mode in a removable complex component actually occurred?

Introduction

That would be the case when the event that causes the failure is due to an unidentified defect occurring deep inside a complex component such as an engine or printed circuit board. The entire module would be swapped with a new one taken from the spares inventory. The failed rotable component would be sent for repair, either to an in-house rebuild shop, to the OEM, or to a third party repair facility. The actual failure mode, therefore, cannot normally be identified on the original work order. How then shall the technician complete the work order adequately for the purpose of subsequent reliability analysis? Does this represent an insurmountable problem for reliability analysis and CBM decision modeling?

Solution

The way to look at this problem depends on the consequences of failure and the operational context. RCM theory^[1] teaches us that all information has a cost and a value. When the information’s value to the organization exceeds its cost, the reliability engineer recommends capturing the useful data so that it may be analyzed. Conversely, if the consequences and frequency of failure do not justify excessive depth of causality, the failure mode might be recorded on the work order simply as: “Object part: PCB, Object damage: Fails, Failure cause: n/a”. This implies that knowing the reliability of the board as a whole suffices. The reliability engineer has judged that it is not worthwhile to expend extra resources to identify which integrated circuit component failed. The RCM knowledge base tree would not, in this case, extend beryond the PCB itself.

Tracking the ages of individual failure modes in rotable components.

On the other hand, if engine unavailability and / or  reliability subtract significantly from enterprise profitability, the reliability engineer will likely wish to monitor engine failure in greater depth. He will require that the rebuild shop indicate:

1. The part(s) that failed or potentially failed, and
2. The part(s) that did not fail but were replaced expediently

How does this information migrate back from the shop work order to the original work order that was executed on the parent equipment from which the failed component was removed?

Answer: It doesn’t need to. The EAM keeps track of each serialized component’s removals from a parent and re-installation on the same or another parent. Sometimes these components are known as “traced” or “rotable” components. The rebuild technician executes a “related” work order that inherits the working age of the parent equipment from the original work order. The EAM freezes the rotable component’s “virtual” hour meter which resumes again when installed on its new parent.

Each part replaced in the rebuild shop is zero timed by the RA software because the rebuild technician reports their life ending events as “Suspension”, “Failure”, or “Potential failure”. All unreported failure modes retain their accumulated virtual ages. When the rotable component resumes service the ages of all failure modes (those that were zero timed and those that remained unchanged in the module) will advance in concert with their new parent’s hour meter. The diagram above illustrates this process.

Conclusion

The EAM’s ability to track rotable components has remained mostly unexploited. This accounts for the paucity of reliability analysis and decision modeling in the maintenance shop despite the richness of data analysis, storage, and manipulation technology. The RCM  analysis tree provides a logical map for acquiring useful data as long as the failure modes are defined at an appropriate level of causality.

© 2015, Murray Wiseman. All rights reserved.

1. ^[1]as does cost accounting theory↩