Why are boundaries so important to define in an RCM Analysis?

What are the general rules for establishing boundaries?

Terry O

Terry:

Boundaries are set for two primary reasons:

1. They keep the RCM process under control especially when there are a number of groups working on the RCM process. For instance, without boundaries, if someone was working on an emergency diesel system, they may continue back to the distribution system. In the meantime, a group working on the distribution system may analyze a portion of the emergency diesel system. The result may be redundant PM on the system.

2. To keep a systems perspective on what is being reviewed. Otherwise you may work on just components of the system (such as recommended by the book you are referencing), which will cause you to miss system interactions.

I read the book, will send you comments by email.

Howard

Terry,

Just to build on what Howard has written here.

One of the principle challenges in starting an analysis is to se the boundaries. An experienced analyst needs to guide the boundary setting to make sure that the project is not:

a) Too high and inclusive, making the analyses superfluous and more likely to be inaccurate. (This is a common error) And;

b) Too low and at the detail level, there is a danger here of becoming too focussed on the asset out of context. Also when you are looking at a large scale project you will suffer from paralysis by analysis by analysing things at too low a level.
(Also a common error)

How do you chose the right level? This is an experience call and one that people learn over time. There are guidelines that can, and are, given. But at the end of the day it is down to the experience of the RCM analyst themselves.

Thanks Daryl and Howard,

When N&H wrote RCM - they focused on aircraft systems where boundaries were already well defined and universal regardless of the manufacturer of the aircraft.

In an industrial system where boundaries are less defined and more arbitrary - why can't we simply look at each component in a system or subsystem? Won't we catch every failure mode if we use a component approach?

Terry O

To further build on Howard and Darryl's comments...
When determining boundaries for an RCM analysis (classic approach), you have to keep in mind the length of time you expect to spend. An experienced facilitator/analyst should attempt to roughly estimate the number of failure modes to be analyzed in a given system after carefully studying the equipment, components, and history. Then, assume you will need an average of 4-7 minutes per failure mode (depends on the experience of the team) to do the FMEA portion of the analysis. Once you have decided how often and how long the team will meet to conduct the RCM analysis, it will give you some idea of how many sessions will be required.

If you try to include too much within the boundaries, it will either take too long to analyze (risk losing focus and commitment)or it will result in a less than accurate analysis. Either way, the result is not good.

We are getting ready to start a new RCM analysis in a couple of weeks, and we are planning for 12 3-hour meetings for an estimated 150 failure modes. It helps to be able to tell the team members (and their management) the scope of their time commitment up front. The system boundaries were selected in a way that made sense functionally but also fit into a reasonable timeframe for analysis.

Terrence,

quote:

why can't we simply look at each component in a system or subsystem? Won't we catch every failure mode if we use a component approach?

One of the paradigm shifts that N&H produced was to look at Functions; what does our asset do, rather that what it is. For example, a pumping system produces a given flow at a stated pressure differential, using a stated amount of power. It is treated as a black box; from a functional point of view, we are not concerned with whether, e.g.,
1. there is one pump or 20 pumps in the black box
2. the pump(s) is/are reciprocating, centrifugal, diaphram or other construction,
as long as the black box delivers the functional requirements.

Using this approach, the black box needs inputs, e.g., a supply of process fluids and power. It will work under some constraints, e.g., National and Company regulations/standards and policies, the Process control system etc. It also needs physical assets e.g pump(s), motors, auxiliaries etc. All these are required to produce the required output, which are defined by a set of performance standards (pressure, flow, temperature, vibration levels, power consumption etc.)

If we do not define the boundaries of this black-box system, it is hard to state what exactly we want to achieve. For example, we would keep the power supply itself out of this function and treat it as a separate system. For this purpose the power supply is an infinite source. Similarly, process fluid is expected to arrive at the right pressure, flow etc., at the inlet to the black box. Without a proper definition, there will be overlaps, and worse, missing assets in the study.

Back to N&H; if we accept that we maintain functions and not just assets, then it becomes clear that e.g., all pumps are not created equal, even though they are in the same service, are identical in build, but differ only in their operating philosophy. Their maintenance needs are only driven by the consequence of failure. Thus a duty pump failure has no consequence as long as the standby cuts in and takes full load. So a duty pump can be happy with minimal maintenance e.g., lub top ups, condition monitoring readings. The failure of the standby however can be costly (in $$$ or safety). So that definitely needs some maintenance. You can see that with a duty standby, the maintenance workload reduces quite significantly, compared with the conventional approach of tackling the same failure modes on both pumps.

This should address your question. You will certainly catch every failure mode by looking at component levels, but do you really need to? As discussed above, the operating context is a co-determinant of the applicable failure mode.

If I have been unclear, perhaps somebody else will pitch in.

Quote Reliability Centered Maintenance by Neil Bloom

"In Fact Nowlan & Heap started at the system level only as a matter of convenience. It was not a requirement. It was the component functional failure and it's manifestation at the aircraft (or plant) level that was really important to them.

...... "Establishing functions at the system and subsystem level is not a required part of the RCM Process! In fact, it may even diminish the accuracy of the analysis..."

Now before everyone goes off and fireworks start shooting:

1) remember community standards and respect rules here

2) we will have an opportunity to meet and hear Neil Bloom at RCM-2006 in Las Vegas.

Neil has a unique history of working in the commericial aviation industry during N&H early years and then on a Nuclear plant following.

You might want to pick up the book as there are some very unique ideas.

I am not trying to stir the pot here but I would like to get validation (or not) of some of these concepts.

Terry O

Shelley - Great points and that makes perfect sense to me.

You have to come to Vegas if this is the stage you are at. It will be an invaluable three days.

Terry

Thanks Terry.

I would love to attend RCM 2006, but ironically it overlaps the RCM analysis that I mentioned. Timing is everything, as they say, and I feel that I need to attend to the process here. However, I am hoping someone else from my site will attend. One question...will the proceedings be available after the conference? Some of us who cannot attend would probably be interested in obtaining a hard copy or CD.

Thanks,
Shelley

Shelley - yes - the CD and Book will be available right after the event. We also publish select papers at Reliabilityweb.com and in Reliability Magazine throughout the year.

Good luck on your RCM project. I hope you will tell us what is happening as you progress.

Terry O

Can we just use the boundaries defined in ISO14224 for which failure modes are already standardized & data are available?

Josh,

The boundaries in ISO 14224 are Equipment boundaries for the purpose of data collection. Where the Equipment itself forms the 'System' as in the case of single train Gas Compressors, this might be possible, but in most cases you are better off defining system boundaries for the RCM study you are considering.

The failure modes in ISO 14224 will correspond to 'Functional Failures' in RCM. Typically, you will have items called 'failed to start' or 'stopped while running' in the ISO. These are functional failures, and we need to go at least one level lower to get the failure modes, e.g., Motor Starter open circuit, or Coupling sheared.

Earlier I commented about depending excessively on standards, software or published databases. It would be useful to decide what you are after and then see what is the best source.

Terry,

With regard to your posting:

quote:

In an industrial system where boundaries are less defined and more arbitrary - why can't we simply look at each component in a system or subsystem? Won't we catch every failure mode if we use a component approach?

Yup. You will is the short answer. Functions work equally well at the component level as they do at the process / sub-process level.

You may not get it absolutely right within the operational context of the system but it would be pretty good.

I think there si a need to diferentiate between every failure mode and every reasonable failure mode under the specific operating context also. But that is probably for another discussion.

But it would take you forever and you would be creating a rod for your own back in terms of the workload required to carry out the analysis on even a moderate size.

Often we get blinkered looking at merely the method, but there is a need to look at the scalability of the thing and how it can be implemented over a large asset base in a time effective and resource light manner.

Thanks Daryl,

Sorry to be thick here but even if we define boundaries and we focus on systems at some point, don't we look at every component that has a failure mode? Or do I have the context wrong?

I am trying to discover why some RCM analyses get bogged down on boundary definition when it seems like you could simply draw circles on a blue print or schematic almost at random.

Of course that is an exaggeration but I was surprised when I posted this question that I did not draw the traditional ire when one questions classical RCM technique. It was leading me to believe we should simplify boundary setting.

I see your and others points about the workload so let me re-phrase the question:

How important is it that we get the boundaries set "right"?

Terry O

Terry,

When undertaking an RCM analysis there is no definition, highlighting, of every possible failure mode of every component.

Only of those failures that are reasonably likely to cause the loss of the function, or lead to the functional failure. (Which are one in the same here)

No ire here, RCM can be done at any level, be it component or equipment or asset etc. But personally I think it is correct to do it at a system, or process level. Generally speaking, to talk to another of you points, separation of

In terms of the correct level, my personal guidance is based upon the complexity of the system being analysed.

A quick example would be that of a screen on a wastewater plant (doing a lot in this industry currently). Each screening system takes in an entire screening set up which may be Duty, Assist and Standby screens. (Or any number of a myriad of combinations.

However, included in this is a washwater system that is used to provide wash water to the plant, as well as a conveying and removel system to remove what has been screened out.

Each of these additional systems, or sub-systems, are relatively complex in that there are a number of components and potential failure modes involved in them fulfilling their functions.

So personally, I would separate these two sub-systems out and treat them as separate analysis. Complexity is one of the leading reasons determining bondaries in this particular case.

If I were to keep them within the analysis it would read something like this;

Function (To screen etc etc etc)
Functional failure (Fails to screen etc etc)
Failure mode (Failure of wash water due to (maybe 20 - 40 or more failure modes depending on the specific system)

So the analysis runs the risk of becoming superfluous, poorly focussed and questionable in terms of accuracy.

This is why we dont do an analysis at the level of an entire generation plant, for example.(I think it is important to add that there is nothing formally saying you can't, merely that it is poor practice)

I would also add that doing it at the level of a solenoid within the wash water system, in this case, would just add to the burden of carrying out the analysis.

Again, and I know you appreciate this point, the key issue for RCM going forward is to become flexible, resource light and comprehensive without reducing the level of rigor and intensity required. I personally believe that doing it at the equipment or component level will, in most cases, go against this.

On another issue, and directly contrary to what I have just stated, it is often wise to do the analyses at an equipment or component level.

For example, we recently carried out some analyses for a 400KV transformer feeding a major part of UK / European infrastructure. Due to the critical nature of this asset, consequence wise, as well as other factirs such as cost of replacement, lead time and a whole host of other issues... we thought we would have been negligent to address this at a higher level regardless of complexity of the system.

Not a conclusive help but I hope these are a few pointers that are of use with regard to the points you raised.

I saw the bait you put out on another thread regarding functions, am dying to answer it but am a little hesitant at present.

Terry,

Sorry, the question was "How important is it to get the boundaries right". (I answered a whole other question with my earlier posting)

I would suggest it is vital to performing an analysis that is likely to be accurate, likely to be useful for larger scale implementations, and able to be carried out effectively.

In the J Mitchell's Physical asset mgmt book, there are 9 levels of asset hierarchy. At which levels should the rcm done?

To add to Daryl's information:

The NAVSEA MIL-P process actually looks at it this way:

You have a system, such as the HVAC system for a vessel. Within that boundaried system, you identify 'functionally significant items' which are items that deserve their own analysis within the system analysis. That might be the fan motor, compressor, etc.

In either case, I have found that it is more effective to address a complete system than just the component. For instance, I use the analysis of a vertical AC motor as an example of how complex an analysis can get on a single component, then I use a parallel pumping system with VFD's to show how a system can be more straight-forward.

By the way, Terry, interesting note. The author that you cite states that wastewater plant screens are considered hidden functions. I get the impression from Daryl's note that is not the case.

Howard

Howard,

They do perform protective functions both in terms of equipment and in terms of environmental compliance.

So they can be considered as hidden functions. I didn't mean to allude that they weren't.

However, you could argue the point that what they are protecting from is not abnormal conditions, rather something expected and common. So it would probably not stick.

Josh - There can be more than 9 levels or far less. It is not a static level.

This message has been edited. Last edited by: <Ozgipsy>,

Terrence,

A number of issues have been raised and answered, but let me add my 2c.

Boundaries: They define what is in and what is out; without such definition, studies can 'grow' or 'shrink' along the way, studies can overlap or duplicate. Not spending the effort to define boundaries can be wasteful in total effort terms.

Level of study: The more detailed a study the more (much more actually!) it costs. Again it is wasteful to conduct a study at a level where the costs dont justify it. For example, for an RCM study for your car, lets say you are working on the power plant. A functional failure can be 'fail to start' and one failure mode is that the starter motor does not turn the flywheel. What do you actually do if you know this outcome?
1. replace the starter motor assembly
2. open it up to find the clutch spring broken and replace that
3. open the assembly and find the drive pinion worn and replace that etc.

If you are in the US with relatively high labor costs, you will probably do (1). If you are in a developing country where spares cost a lot, you might do (2) or (3). So if you do an RCM in the US, is there any need to know any more than the fact the starter motor assembly needs replacement? Why do the study to a lower level?

Failure modes: There is an opportunity to look at a zillion failure modes that 'may' happen, but should we look at all of them? A credibility test has to be applied, so we eliminate the dross, else we can go on fishing expeditions. There are rules for credibility, but I wont go into it now.

Hidden Functions: there are clear guidelines on what is evident and what is hidden, and we have discussed this subject in another thread, so I wont add to it.

As a general rule, I would stop an RCM analysis at as high a level as is consistant with the level of part/assembly replacement. There are reasons to go to a lower level sometimes, but these must be challenged and accepted first.

This message has been edited. Last edited by: Vee,