RCM boundaries and Living RCM

In performing your RCM analysis on this butterfly valve, you decided to treat the hydraulic system as a separate analysis. You drew the boundary in such a way that the cylinder-actuator belongs to the hydraulic system and not to the valve. That is perfectly legitimate. You can draw the boundaries in any way that you find convenient.

Now you ask whether you should list,  or in some way, reference in the valve’s RCM analysis, a failure mode affecting the valve but occurring within the hydraulic system.  If so, how should you include this reference?

Assume that the failure mode identified in the hydraulic system analysis is:

• Object part =”Cylinder”,
• Object damage = “Seal leaks”,

Should we list this failure mode in the Valve analysis as a general description, say

• Object part: “Hydraulic system”
• Object damage: “Fails”

Traditionally, in RCM analysis, this would not present any problem. You would simply indicate in the comment text area that the failure mode is analyzed elsewhere. You would not include a mitigating action within this appearance of the failure mode.

However LRCM works day-to-day with the RCM analysis where technicians select failure mode work order instances directly from the RCM tree. Furthermore, LRCM builds upon the RCM analysis as new information comes to light. If the failure mode is represented in two RCM locations, you have the possibility that some technicians will erroneously select the general failure mode leaf in the valve’s RCM tree. Other technicians will correctly select the specific failure mode in the hydraulic system’s RCM knowledge tree. This will result in separate instance counts of what really should be the same failure mode. The samples used by reliability analysis algorithms would be distorted. The reliability analyst would analyze two failure mode instance samples rather than one.

Here is a simple solution in Mesh, which is consistent with John Moubray’s  RCM II approach regarding failure modes handled elsewhere. In the RCM valve analysis describe the failure mode as follows:

• Object part = Hydraulic System.
• Object damage = “Fails”,
• Due to = “See Hydraulic system analysis”.

In this way the technician will know, without needing to unfold the leaf, that he should not select this failure mode but rather he should locate the specific failure mode in the Hydraulic System’s RCM knowledge tree. ^[1]

A second related issue concerns the generation of the maintenance schedules. Since the RCM analysis is represented in a dashboard we need to avoid duplicate failure modes for two reasons. One, the count of failure modes would be distorted when filtering on one or both of the two systems involved. Secondly, the maintenance schedules would contain the failure mode in both its general and specific form. A simple solution would include the code “{gen}” in the Effects text (similarly to the method proposed in the article on common cause failures). The extraction, transformation, and loading (ETL) program will skip the general failure mode. thereby precluding its appearance in the RCM tasks dashboard and in the maintenance schedules.

This was an interesting situation that came to light because of the LRCM extension and its functionality requiring the RCM analysis to be integrated into the daily work order process.

© 2016, Murray Wiseman. All rights reserved.

1. ^[1]As a road map item, we can disallow certain general failure modes from being selected if they are fully analyzed elsewhere.↩