LivingRCM

Secondly, but less obviously, each software product embodies its own culture or point of view. We, as users, need to embrace that viewpoint in order to benefit fully from the application.

What do we mean by "optimal" in CBM? When we get CBM data, it’s indications are seldom "black and white". Torrents of data from proliferating sensors and process control systems tend to overwhelm.

Often our decisions are judgment calls. Judgment can span a spectrum of choices from extreme caution (acting too soon) to lethargy (waiting till it's too late). Making the best choice (given the current operating context) is what we mean by optimal.

I’ve heard the word optimal being used at this conference. For example “optimal reliability”. That’s not clear. We should, rather say, an 'optimal decision process' that achieves a certain objective, for example maximum availability or a specified survival probability in a time frame. Or, in a "cost constrained" operation (operating below market capacity), perhaps the optimizing objective is minimal cost. Or, optimization may seek to achieve a specified combination of one or more of the above.

A model is a procedure used to interpret data in order to achieve a long run objective. It may be a set of rules enshrined in an expert system. Or it might be a statistical model, or perhaps just someone’s gut feel. Even that’s a model, not one I would care to admit to my boss or to my company’s shareholders

Secondly, through software, we deploy that model in an automated way. I subscribe to the school of thought that unless CBM can be mostly automated using rules or algorithms, it will return limited benefits. There is too much data, and there are too few human resources to pronounce upon all that data.

Thirdly, the whole CBM exercise, is of little value unless we can measure its effects objectively, and improve it by tweaking our models. This third function is really what defines a maintenance and reliability engineer, in my view.

Firstly, that information on what happened actually has value. I’m talking about historical data in the CMMS. How many of us have had the thought ourselves or have heard the statement by technicians, planners, and consultants, that the information in the CMMS is being under-utilized? Some consultants even claim that it is useless. To the contrary, historical information in the CMMS is vitally important. The major failing of the CMMS industry is not to have provided tools and methods for harvesting knowledge from that rich information source.

Secondly, if we accept Premise 1, we may ask how may we convert that information to practical knowledge. What is knowledge in maintenance? It is the ability to make the right decisions, given the current data.

Premise 3 says, that we need to improve our (decision enabling) knowledge base continually.

What is reliability analysis (RA)? How does it differ from reliability-centered maintenance analysis (RCMA)?

RA is the study of failure modes that have occurred. And RCMA is the study of the failure modes that 'can' reasonably occur. Both those analyses populate the same knowledge base. They complement each other. RA sanity checks and refines the assumptions and approximations of RCMA, while RCMA provides the structured framework for a consistent language and thought process.

Animation 5-1

The first is the RCM reference number. This is a number that refers to a record in the RCM knowledge base. It is a one-to-many relationship. This relationship has powerful implications for reliability improvement. Linking of a significant work order to the RCM table means that the work order becomes an instance of a RCM knowledge record. And if that is true, then we can count the occurrences of significant item-function-failure-causes. Counting these instances (in various ways) is precisely the function of reliability analysis software and methods, examples of which are: Pareto, Jack-knife, Weibull, proportional hazard modelling, and many others.

I have visited many plant sites, have spoken with their maintenance and reliability analysts. All of them have purchased and attempted to use reliability analysis software. But they ran into a problem. They didn’t have the right data in the proper form to feed the otherwise very powerful software that they had puchased.

By adding these two pieces of information, we solve that problem.

What about that second suggested piece of information "Event Type"

There are, mainly, three event types: PF, FF, and S. Was this a functional failure (FF) that had consequences? Or, was it a potential failure (PF) that we caught on time to prevent the most dire consequences of the failure mode. Or, was this a suspension (S). A suspension is the renewal or replacement of a component for any reason other than failure, either potential or functional. The planner or technician may have found it expedient to replace the part even though it was not in a failed state nor showing any signs of impending failure.

Animation 6-1

Animation 6-2

We can check by hitting the offered link. And we bring up the associated knowledge document. The technician or planner reads the failure mode and the effects. And, determines whether this knowledge document describes the current situation. It does. So we grab the RCM reference number and enter it onto our work order. We have established the link.

What if we find some errors or would like to add some clarifying details, say to the Effects field? We edit the knowledge record. But wait! Can we allow anyone to modify the knowledge base? Yes, we can, because the edits are being tracked, just as in Word. The new or modified knowledge record is automatically routed to a verifier – a RCM facilitator if you will. A discussion could ensue. Eventually the knowledge base is updated with verified knowledge.

However, we don’t throw the edit tracked document away. It persists as a permanent audit trail of our evolving understanding of the failure behavior of our significant assets.

What if we can’t find a knowledge record in the RCM knowledge base that represents the current situation? We perform a mini-RCM analysis on the spot. What better time? The equipment has been opened. The situation (the Effects and Consequences) is fresh in the minds of all concerned.

We accomplish that via a bridge between the maintenance database and our reliability software applications. We call this bridge the "Events table". I call your attention to the fourth column of this table, the Event. Look carefully at the syntax of that event code. It begins with a letter, either E (for "ending") or B (for "beginning"). Then a number, which is none other than our RCM reference. And finally a suffix: FF, PF, or S.

Hence, in one succinct code we have captured precisely what happened. We see that a work order, say work order 9, expands into two events in the Events table. The ending of the life cycle of component 20890, and, the beginning of the life cycle of the renewed or replaced component. This is the form of data that reliability analysis software needs. The Events table was generated automatically from the work orders endowed with those two additional, simple, yet potent, pieces of information that we recommended in Slide 5.

Animation 7-1

Let’s say, for example, we would like to study the behavior of all the grease bearings on a particular class of ship. We create the Failure Model “Grease bearings”. And select all the RCM records whose instances we would like to include in our study. The results of that mapping are shown in the table at the right. Notice on the right, that we have mapped 11 RCM records to the failure model "Degaste general", or “general wear”.

Using this simple data mapping technique we can study any single or any group of failure modes.

Animation 7-2

We can plot failure rate graphs (top right). And because, you will recall, we have discriminated between functional and potential failure, we can study the behavior of either. That study will tell us to what extent our PFs are pre-empting our FFs, which, of course, is the aim of CBM.

Animation 7-3

We determine whether we have quality problems of some type as evidenced by the infant mortality behavior of this failure (hazard) rate graph.

We can hit a tab and get the down-time comparisons, or the cost comparisions, or the availability comparisions. There is no limit to the breadth and depth of studies that we can perform, with little effort, provided that we have captured those two pieces of information mentioned earlier.

The verticle axis measures the actual gravity of a failure mode. In this case it is measuring downtime. The horizontal axis measures frequency.

The graph has been sectioned into four quadrants. The dots represent the failure modes. Those which fall in the upper right quadrant require our most urgent managerial attention. They are both acute and chronic. This graphical representation tracks the results of our policy changes. As we modify our policies, we should see the failure mode dots migrating eventually towards the origin. Hence we have a clear, quantitative measure of our progress towards ultimate reliability.

The red and green graph is a visual representation of a decision model. The verticle axis represents the weighted sum of all those variables that have been found (by the RA) to be significant to the particular failure mode (or failure model) being studied.

The decision model answers the question, posed thousands of times by maintenance managers. "How do we set our CBM limits?"

Here is that Weibull hazard rate graph again. We notice that the Total failures curve and the Potential failures curve are very close to one another. The difference between the two, is the Functional failures curve. It is low and flat, which is the signature, of a well-maintained component.

Animation 11-2

On the top right we have our CBM key performance indicators. They tell us, in bottom line financial/managerial terms how well or poorly the current CBM policy meets the objectives of our CBM policy.