{"id":2459,"date":"2012-07-09T21:03:40","date_gmt":"2012-07-10T02:03:40","guid":{"rendered":"http:\/\/www.livingreliability.com\/en\/?p=2459"},"modified":"2025-11-06T05:43:34","modified_gmt":"2025-11-06T10:43:34","slug":"rcm-living","status":"publish","type":"post","link":"https:\/\/www.livingreliability.com\/en\/posts\/rcm-living\/","title":{"rendered":"RCM – Living RCM"},"content":{"rendered":"

When most people discuss or practice RCM, they are really referring to initial\u00a0<\/em>RCM, the process by which the Functions, Failures, Failure Modes, Effects,<\/p>\n

\"Slide1<\/a>
Slide1 Living RCM<\/figcaption><\/figure>\n

Consequences, and mitigating actions are analyzed and documented based on the knowledge available to the analysts at the moment of analysis. The analysts’ recollections of the asset’s failure behavior are imperfect. It is necessary, therefore, to extend<\/em> initial RCM to the operational phase so that the maintenance plan will be continuously improved as new\u00a0information becomes available day-to-day from work order related experience. The Living RCM process ensures perfect data for analysis and decision modeling.<\/p>\n

The components of a maintenance decision system<\/h2>\n

1<\/strong>: The people in a maintenance organization possess skills, knowledge, and experience in operating and maintaining the organization’s physical assets. Management provides systems and software designed to capture the benefits of the organization’s “human capital”.<\/p>\n

\"Slide2<\/a>
Slide2 Components of decision making in maintenance<\/figcaption><\/figure>\n

2<\/strong>: Management systems and processes are intended to transform this available knowledge into profitable day to day decisions that reflect an item’s failure behavior. Those decisions determine \u00a0when, where, and how to perform maintenance to best effect.<\/p>\n

3<\/strong>: Reliability knowledge bases, such as RCM and other systems, capture the knowledge elicited from experienced personnel and organize it for optimal scheduled maintenance or exposing a redesign\u00a0requirement .<\/p>\n

4<\/strong>: Engineers apply Reliability Analysis (RA) techniques with which to build “decision models”. These models assist them in making the best possible maintenance decisions on what to maintain, when, and how. RA software applications are powerful, yet underused because the data needed by the\u00a0organization’s\u00a0Reliability Engineers is missing or inadequate. LRCM addresses this flaw in today’s maintenance information systems.<\/p>\n

5<\/strong>: The Work order system, for example SAP, should enable continuous improvement in the reliability knowledge base. Additionally it should provide the data necessary for RA. Currently, it fails in both these areas. LRCM addresses these gaps.<\/p>\n

6<\/strong>: A third set of maintenance decision tools should work in harmony with the other systems. These condition monitoring tools record observational data collected by a variety of automated and manual monitoring techniques. The components include real time databases, sensors, vibration analysis, oil analysis, and other systems designed to provide the reliability analyst with data to aid in maintenance decision making. The resulting monitoring databases are enormous but seldom exploited by automated decision models.<\/p>\n

7<\/strong>: There is a glaring lack of inter-operability among all these components. \u00a0LRCM harmonizes these systems for optimal, verifiable, day to day decisions.<\/p>\n

LRCM Functions<\/h2>\n

Practical decisions in maintenance must be:<\/p>\n

\"Slide3<\/a>
Slide3 LRCM actions<\/figcaption><\/figure>\n
    \n
  1. Automated,<\/li>\n
  2. Optimal, and<\/li>\n
  3. Verifiable as having contributed positively to maintenance objectives.<\/li>\n<\/ol>\n

    The most basic LRCM function ensures “analyzable” data in the SAP work order database. A lack of “good” data is the single most important obstacle to Reliability Analysis (RA). This obstacle frustrates the modern Maintenance Engineer.<\/p>\n

    The functions of LRCM are listed on Slide 3. LRCM ensures “perfect” transcription of \u00a0information into SAP. \u00a0Secondly, RCM improvements occur in a natural process of exposing conflicts between the technicians’ observations and current RCM knowledge. Thirdly, as the RCM knowledge hierarchy is amended, SAP catalogs synchronize with the changes so that work orders will always be true instances of RCM Failure Modes. This is a fundamental criterion for RA. Finally, LRCM generates the correct data in the correct form for RA.<\/p>\n

    LRCM Software Functions<\/h2>\n

    The LRCM application contains six distinct modules that accomplish these functions each of which is detailed in the subsequent slides.<\/p>\n

    \"Slide4<\/a>
    Slide4 LRCM Software Functions<\/figcaption><\/figure>\n
      \n
    1. Synchronizes the CMMS failure catalogs with the changing RCM knowledge hierarchy.<\/li>\n
    2. Ensures that the data on work orders is complete, accurate, and, therefore, analyzable.<\/li>\n
    3. Provides a quick non-obtrusive interface for building the initial RCM analysis.<\/li>\n
    4. Provides convenient and high quality updating of the RCM analysis with new work order field observations.<\/li>\n
    5. Retains an audit trail of the changing RCM analysis allowing display of the knowledge state at any previous point in time.<\/li>\n
    6. Uploads and displays images \u00a0as required to help describe a given Failure Mode and its Effects.<\/li>\n<\/ol>\n

      1. RCM \u2013 CMMS Synchronization<\/h3>\n

      When a technician, supervisor, or planner is entering his observations into the work order form it is\u00a0imperative\u00a0that the catalog selection values reflect current RCM knowledge.<\/p>\n

      \"Slide5<\/a>
      Slide5 RCM \u2013 CMMS Synchronization<\/figcaption><\/figure>\n
      \"Slide6<\/a>
      Slide6 Synchronization check and update<\/figcaption><\/figure>\n

      If this is not the case errors and omissions will occur in the work order history reducing confidence in analysis and resulting decision models. The LRCM process ensures that the CMMS Failure and Failure Mode catalogs are perfectly aligned with changing RCM knowledge.<\/p>\n

       <\/p>\n

       <\/p>\n

      Any RCM knowledge element that is not mapped to a corresponding value in the appropriate SAP Catalog[1<\/a>]<\/sup> will be marked appropriately (as in Slide 6) and automated synchronization may be activated.<\/p>\n

       <\/p>\n

      2. Complete, Accurate and Analyzable work order data<\/h3>\n

      The innovative LRCM work order data entry form for accomplishing complete, accurate, and analyzable work order data is the user interface for updating a work order shown in Slide 7 .<\/p>\n

      \"Slide7<\/a>
      Slide7 The LRCM UI: Complete, Accurate and Analyzable work order data<\/figcaption><\/figure>\n

      This form displays the “live” RCM knowledge hierachy. The user selects the Failure Mode(s) addressed by the work order by clicking on the respective Event type(s). This single action guarantees precise data entry. This precision occurs because each Failure Mode, displayed in the context of its related Function, Failure, and Effects is mapped to its corresponding set of CMMS catalog codes. Additionally, the form makes clear the distinction between Failure (F) and Suspension (S). There is practically no possibility of error.<\/p>\n

      Occasionally the information in the RCM hierarchy will disagree with reality on the ground. This will be obvious to the technician or supervisor \u00a0because the Effects description pops up on hovering over a Failure Mode. \u00a0In cases of discrepency the Feedback function associated with each node in the tree will advise the Reliability Engineer of the needed knowledge update. All such changes to the RCM knowledge base leave a permanent audit trail. It is possible, therefore, to display any prior knowledge state. This is particularly important for the investigation of significant failure, safety incidents or accidents.<\/p>\n

      3. Initial RCM analysis<\/h3>\n

      When performing RCM analysis the software’s user interface should be as unobtrusive as possible.<\/p>\n

      \"Slide8<\/a>
      Slide8 Adding or Selecting the analysis<\/figcaption><\/figure>\n

      The screenshot of Slide 8 illustrates that an authorized user can select, add or delete an analysis. He can copy and paste branches from one RCM tree into other locations on the same tree or into another RCM tree view.<\/p>\n

      \"\"<\/a>
      Slide9 The RCM Knowledge Builder tree view<\/figcaption><\/figure>\n

       <\/p>\n

       <\/p>\n

       <\/p>\n

      Slide 9 illustrates the tree view. The entire structure is accessible and visible and editing is done directly from the tree view of the RCM hierarchy.<\/p>\n

      \"Slide10<\/a>
      Slide10 Answering RCM questions 3 to 7<\/figcaption><\/figure>\n

       <\/p>\n

       <\/p>\n

       <\/p>\n

      Adding and editing a Failure Mode and its Effects, Consequences, Mitigating Actions, Skills, and scheduled Interval are accomplished in the popup window of Slide 10.<\/p>\n

      \"Slide11<\/a>
      Slide11 Criticality Analysis<\/figcaption><\/figure>\n

       <\/p>\n

       <\/p>\n

       <\/p>\n

      The Risk associated with each Failure Mode is analyzed in the second tab of the popup window. The selection grid, cell values, color coding, and Criticality calculation as the product of the probability and severity is configurable. Risk or “Criticality Analysis” can be useful as a way to prioritize maintenance activities or redesign.<\/p>\n

      4. Dynamic RCM<\/h3>\n
      \"Slide12<\/a>
      Slide12 Step 1 Feedback<\/figcaption><\/figure>\n

      RCM knowledge is dynamic.\u00a0It changes and grows, and therefore must be updated as experience reveals new information about failure modes. Slide 12 illustrates the first step in the knowledge update process – feedback from the field or shop. A pop up window allows anyone to submit text and images to suggest RCM knowledge additions or changes.<\/p>\n

      \"Step<\/a>
      Slide 13 Step 2 Knowledge Administrator Dashboard<\/figcaption><\/figure>\n

      LRCM provides the capability to update RCM knowledge subject to approval of the RCM administrator. Slide 13 illustrates Step 2 in the RCM dynamic update process. A knowledge administrator dashboard allows the individual responsible for RCM knowledge quality to accept or decline each suggestion. If accepted, the screen shifts to the appropriate location on the RCM tree view where the knowledge administrator can update the new information. A permanent record of the originator, change, and date is maintained in a knowledge audit trail.<\/p>\n

      5. RCM Knowledge Audit Trail<\/h3>\n
      \"Slide14<\/a>
      Slide14 RCM Audit Trail<\/figcaption><\/figure>\n

      LRCM provides an audit trail of evolving knowledge. All changes to the RCM knowledge base are retained. The audit trail module records progress in the organization\u2019s understanding of each Failure Mode, its Effects, and Consequences.<\/p>\n

      Continuous refinement of knowledge as required by the LRCM process will improve the effectiveness of maintenance.<\/p>\n

      The audit function also makes it possible to display the state of knowledge at any previous point in time. This capability is critical \u00a0for thorough investigation of accidents or serious failures.<\/p>\n

      \u00a06. Failure Mode (Effects) Image Gallery<\/h3>\n
      \"Slide15<\/a>
      Slide15 Image Gallery<\/figcaption><\/figure>\n

      The LRCM UI offers the possibility of adding pictures related to each failure mode. Users can upload up to three images per failure mode. Technicians can propose new images by sending their suggestions to the RCM administrator. One of the main purposes of associating images\u00a0with Failure Modes is to help in setting standards for declaring Failure, Potential Failure, or Suspension.<\/p>\n

      Reliability Analysis and Decision Modeling<\/h2>\n
      \"Slide16<\/a>
      Slide16 Reliability from the analysis of data<\/figcaption><\/figure>\n

      We acquire maintenance and operational information for one main purpose, which is to analyze that information so that we can improve our decision making rules. Often this singular objective is forgotten in the heat of battle. The gathering of information becomes an end unto itself. Excessive unnecessary detail reduces the value of data.\u00a0The LRCM process never strays from its objective, that of acquiring the right analysis enabling data with which to support the continuous improvement process.<\/p>\n

      \"\"<\/a>
      Slide17 CBM optimal decision modeling<\/figcaption><\/figure>\n

      Given the scale of maintenance in a mining or energy operation, it is desirable that the process for making a CBM decision be optimal, automated, and verifiable. Slide 17 illustrates a CBM optimizing system called EXAKT. The Reliability Analysis (RA) modeling illustrated in the figure and described in the following paragraphs appears complicated. It is, in fact, quick and easy thanks to the LRCM process.<\/p>\n

      The modeling process consists of three phases labelled 1, 2 and 3 in Slide 17:<\/p>\n

        \n
      1. The first phase develops the reliability model. An example of a reliability model is seen in the top left block of Figure 17. The equation is known as a \u201cProportional Hazard Model (PHM)\u201d wherein\u00a0h(t)<\/em> is the Failure Rate function, t<\/em> is the working age, and the\u00a0exponent contains the significant monitored variables.<\/li>\n
      2. In the second CBM modeling phase we build a prediction model, and<\/li>\n
      3. Thirdly, the reliability and predictive models (of 1 and 2) are combined in the \u00a0to generate a Remaining Useful Life Estimate (RULE) and an optimized model for automated decision support.<\/li>\n<\/ol>\n

        LRCM enables the benefits of powerful Reliability Analysis software<\/h2>\n

        Once we have the right data in the right format entered into the CMMS (SAP, Maximo, …) advanced software procedures become available to us.<\/p>\n

        \"Slide18<\/a>
        Slide18 Failure Mode cumulative damage calculated in Clockwork Solution’s Command\u00ae software<\/figcaption><\/figure>\n

        The Cumulative Failure Probability, F(t), when calculated at the time of interest, t, taking into account relevant age and sensor values, represents the percentage of “life” that has been used as a result of operation prior to t and the item’s current health state. F(t) derives from the system’s reliability block diagram, past and projected usage and maintenance, and the latest sensor data. Maintenance reduces<\/em> cumulative damage while the effect of past and projected usage<\/em> is to increase<\/em> cumulative damage. Exploiting this data in an automated way via RA is now a reality for the first time thanks to the LRCM process and Clockwork Solution’s Command\u00ae software application.<\/p>\n

        Day-to-day criticality of systems, components, and parts<\/h2>\n

        Another way of reporting the decision recommendation of the model is in terms of each failure mode’s current “criticality”.<\/p>\n

        \"Slide19<\/a>
        Slide19 Critical failure modes<\/figcaption><\/figure>\n

        Given the item’s current state, the projected usage, and projected maintenance schedule, what are the most critical items wanting attention? We can change the projected scenarios and run the calculation (i.e. the simulation) multiple times in order to decide on the best strategy, the one that best meets our availability, cost, and other operational requirements.<\/p>\n

        Projected failure probability for different maintenance and operation scenarios.<\/h2>\n

        The Cumulative Failure Probability graphs of Slide 20 trace the analytic procedure that can be followed by the Reliability Engineer. He can begin by predicting the system’s Cumulative Failure Probability F(t),\u00a0 under a “no maintenance” scenario.<\/p>\n

        \"Slide20<\/a>
        Slide20 Projected failure probability<\/figcaption><\/figure>\n

        The pie chart may tell us that the radio is at this \u00a0moment of interest the critical Line Replaceable Unit (LRU), the one most likely to fail in the current mission time window. If the system survival probability is unacceptable we may analyze the scenario of an immedate radio replacement and determine what would be the impact on mission survival? Will the radio replacement provide the needed system\u00a0reliability over the course of the mission (say the next 1000 hours of truck or shovel operation)? This analysis discovers that the Wheel system is the next most likely source of failure.<\/p>\n

        This, in turn, would lead us to investigate the impact of a projected overhaul in six months \u00a0time. Among the overhaul tasks we will include the Wheel system replacement. We run the simulation again (third curve) to determine whether this strategy will improve the truck’s reliability to the degree required to accomplish the mission.\u00a0In the analysis we test different operational profiles and maintenance plans. A what-if analysis, such as that of Slide 20, will quickly point us to the most effective maintenance plan for each equipment or system.<\/p>\n

        What is a sample?<\/h2>\n

        The foregoing ability to perform useful analysis and prediction depends on the quality of the data sample. By “sample” we mean an extraction of data that contains analyzable, predictive content. Most maintenance organizations are unable to produce such samples or the samples they do produce are inadequate for effective RA.<\/p>\n

        \"Slide9<\/a>
        Slide 21 Data transformation from CMMS to a sample<\/figcaption><\/figure>\n

        Initially, data, the way it is stored in the CMMS, is unusable for RA. It must be transformed (the arrows in Slide 21) into a Sample. A sample is a collection of Failure Mode life cycles. A beginning event (B) and ending event (EF and ES for ending by failure and suspension respectively) define each life cycle or “history”. RA software can calculate Failure Mode individual life beginnings by using the data in the CMMS database. However software cannot “infer” whether a Failure Mode ended its life by Failure or by Suspension. This information must be explicitly provided by the technician in the LRCM UI of Slide 7. RA performs by examining each Failure Mode history. It determines how each Failure correlates with the item’s virtual age[2<\/a>]<\/sup>, its projected usage, its projected maintenance, and with the item’s Condition monitored sensor data. Unless the ending event is recorded accurately\u00a0as having\u00a0occurred\u00a0by Failure, the computation will be compromised by uncertainty, which is illustrated by the low confidence depicted in the right hand graph of Slide 22. LRCM ensures that a sample, defined by a calendar window, accounts for every<\/em> life cycle (the arcs in Slide 21) including suspended<\/em> life cycles (represented by dashed partial arcs}.<\/p>\n

        Why discriminate between “S” and “F”?<\/h2>\n

        Not making the distinction precludes analyzing work order historical data for the purpose of developing or improving your decision models.<\/p>\n

        \"Slide22<\/a>
        Slide22 Decision confidence reported by OMDEC’s EXAKT CBM optimizer depends on accurate Event data in the CMMS<\/figcaption><\/figure>\n

        Slide 22 illustrates in a Conditional Probability Density graph, the ability of software to report the Remaining Useful Life Estimate (RULE). Importantly, the software also reports the standard deviation, which describes the uncertainty in the RULE. It is a key performance indicator (KPI) of the effectiveness of any Condition Based Maintenance task.<\/p>\n

        When Suspensions are mistaken for Failures, the uncertainty in a decision model rises because the analysis will have been mislead into correlating a Failed State with condition and age data patterns that in reality should associate with a non-failure renewal, that is, a Suspension. The LRCM UI avoids such errors. Additionally the UI always assigns SAP catalog values correctly because the Object Failure, Object Damage, and Failure Cause are already mapped to each displayed Failure and its Effects. This mapping is transparent to the user, who need concern himself only with the RCM representation of what actually was observed.<\/p>\n

        The results achieved by LRCM<\/h2>\n

        There are two types of Key Performance Indicators (KPIs). Slide 23 shows the improvement in work order information quality achieved through LRCM. Performance metrics should point us precisely to what we need to improve currently in our maintenance process. That is, they should trigger a control action. Subsequently they should confirm and measure the extent to which the control action had the desired effect.<\/p>\n

        \"Slide23<\/a>
        Slide23 Decision confidence reported by OMDEC\u2019s EXAKT CBM optimizer depends on accurate Event data in the CMMS<\/figcaption><\/figure>\n

        By tracking this key metric, the organization having adopted LRCM procedures will soon possess samples appropriate for analysis, decision modeling, and driving the continuous improvement process.\u00a0Low level KPI\u2019s in maintenance measure such indicators as:<\/p>\n

          \n
        1. Work order information quality,<\/li>\n
        2. RCM knowledge added,<\/li>\n
        3. The number of RAs performed and recommendations issued,<\/li>\n
        4. CBM performance measurement such as the standard deviation in remaining useful life estimation,<\/li>\n
        5. CBM hit and miss ratios (detection confidence).<\/li>\n<\/ol>\n

          Management sets low level objectives (i.e. KPI values) that:<\/p>\n