RCM – detail and depth

When RCM analysts lack clear goals regarding the amount of detail (i.e. the number of failure modes) to include in the analysis or the depth of causality at which to identify a failure mode, an RCM review session can easily bog down and consume valuable time. The facilitator must guide the analysts along a path that bypasses excessive detail and depth yet still avoids a superficial  and indefensible analysis.

For example, consider the following:

Fire Hydrant System v7.5
  1. To be able to provide high pressure water to hydrant system at a pressure > 145 psig with a flow rate of 2000 gpm (design) in the presence of a back-up pump
   1.1. Provide pressure in the absence of back-up pump set
     1.1.1. Pump Set Fails caused by n/a
     1.1.2. Diesel engine Fails caused by n/a
     1.1.3. System piping Fails caused by n/a

There are several interesting aspects in the above analysis snippet that are worth elaborating. The code phrases “able to” and the “in the presence of” in the Function Statement are reminders. These memory aids recall that the occurrence of a failure mode on its own may have no consequences. (I.E. the definition of “hidden consequences”.)

It is useful to examine the first failure (i.e the failed state) “1.1. Provide pressure in the absence of back-up pump set”. Why such a counter-intuitive way to express the failed state? Because it makes for a more concise analysis. Hidden failures are a recurrent phenomenon in maintenance. So RCM has adopted a syntax that avoids having to repeat the failure and failure mode analysis for each redundant device in the group. Additionally, the phrasing “in the absence of” avoids the need for including failure modes such as “Pump 1 and Pump 2 both fail”. It will become clear, as you proceed in the RCM analysis, that the necessary PM actions mitigating all situations can derive from the failure state as it is expressed in 1.1 above.

In addition to the issue of hidden failures, two common questions recur in the RCM analysis process, namely “How deep?” and “How many?”. The first question asks, “at what granularity do we identify the Object Part?”.^[1] And the second asks “How many failure modes shall we identify?” The following segment illustrates these issues:

 4. To contain up to 1000 gal of fuel for diesel pumps in the presence of a redundant wall (2 tanks)
   4.1. Cannot contain
     4.1.1. Diesel tank drain valve Leaks caused by n/a
   4.2. Contains in the absence of a redundant wall
     4.2.1. Diesel tank Inner wall fails caused by n/a
     4.2.2. Diesel tank Outer wall fails caused by n/a

RCM meetings tend to slow down whenever there is lack of clarity about detail and depth. A case in point, regarding the depth of analysis, occurs typically when identifying the Object part. Notice the subtle difference between 4.1.1 on the one hand and 4.2.1 and 4.2.2 on the other. In 4.1.1 the italicized Diesel tank drain valve  was identified as the object part.  But in 4.2.2 and 4.2.3 we say the object part is “Diesel tank” and we provide the required specificity (inner wall or outer wall) in the Object damage segment. Note the non-uniformity. What principles should guide us in making such knowledge structural decisions?

The higher up in the hierarchy the failure mode (object part) is the more inclusive or broad its physical scope. That is, the failure mode will encompass more complexity. But the details within that complex component may not be relevant if the component rarely fails and when it does it is discarded and replaced. The lower the level the more narrow its scope.” Graphically, the principle would look like this:

4.2.1 and 4.2.2 respect this principle of identifying a fewer number of object parts.  4.1.1 considers that the the drain valve should be tracked as ab object part in its own right. What is the advantage of trying to push the specificity as far to the right (in the object damage and failure cause segments) as we can? Simplicity. Fewer catalog values to chose from. And flexibility. In the example we could have only one Object part “Diesel tank”.  Nevertheless we would not lose the ability to track the the drain valve, but as a failure mechanism rather than an object part.  The RCM analysis, guided by this principle, will generate the simplest and most maintainable knowledge tree without sacrificing analytic detail where needed.

A second advantage, having to do with ease of continuous knowledge management, is the ability to alter the depth and detail of the RCM analysis. For example, in the context of your maintenance department, if you didn’t care what part of the tank fails or why it fails, the failure mode would reduce to “Diesel tank” (and we could leave the other two grammatical segments at the default “Fails” and “n/a” respectively). Later, if we wanted more depth and/or detail we could add new combinations of Object damage and Failure cause to the Object part. Conversely we could remove them if we decided less detail is appropriate. The Object part catalog value, in all cases, would remain unchanged.

The question “How many” can consume, unnecessarily, enormous amounts of time in an RCM analysis session. Take for example the Diesel engines driving the water pumps in the Fire Hydrant System. We know that there are many mechanisms and causes for the failure of Object part “Diesel engine”. How many of those should we include in the analysis? Is “1.1.2. Diesel engine Fails caused by n/a” sufficient? If not, which additional causes (or failure mechanisms) should we include? For example should we include “Diesel engine Fails caused by “Corrosive particulate fouling the radiator”? RCM provides simple answers to the question “How many?”.

1. If it (the failure mode) is reasonably likely include it.
2. If it has happened before and can happen again include it.
3. If it is less likely but the consequences are severe enough include it.
4. If you’re currently doing some PM task to address the failure mode (for example checking the sight glass daily for particles in the coolant flow) include it.

The MESH “feedback/suggestion” system (described here) allows anyone at anytime to initiate refinements in the RCM analysis  yet still ensure quality control by the facilitator.

© 2015 – 2020, Murray Wiseman. All rights reserved.

1. ^[1]The Object part is the SAP catalog name for the first grammatical segment of the failure mode “sentence”. The failure mode sentence consists of a subject (the part), an action phrase that describes the mechanism by which the part deteriorates, and a “due to” clause that describes the cause.↩