Forum: LRCM

Thanks Alan, for the great question.

Yes, the U.S. military FMECA standard (MIL-STD-1629A) and the LSAR (MIL-STD-13882B as well as GEIA-0007, the new LSAR standard) contain the structural elements that you listed.

To respond thoroughly, allow me to state the four organizational challenges to achieving reliability from data. They are:

1. Data extraction and transformation,
2. Managing knowledge and the work order RCM relationship,
3. Generating a sample for analysis, and
4. Reliability analysis

Each of the above depends on its predecessor. We must extract and transform LSAR "knowledge" so that it may be accessed and managed dynamically within the day-to-day work order process. LRCM manages workorders as instances of knowledge records. It applies failure mode life end attributes (usually one of FF, PF or S) needed for sample generation. Finally, we analyze the sample using a variety of reliability analysis techniques including Weibull, PHM, and simulation modeling.

Having restated the goal, let's get back to your question. The following Excel sheet illustrates FMEA as structured in the LSAR.



The 12 narrative codes you listed are represented in the above by the letters A - K in the column "Fmncnabg" (the "Failure Mode Narrative Code"). A transformation of the above view provides the following table, easily useable by LRCM.



For clarity the system name has been placed into column A. The end item acronym code (Eiacodxa) header is renamed "Item". (FMEA knowledge is associated with an Item, which is a class or type of equipment). The failure mode indicator of column E has been placed into column C with the header "Indicator". The combination of Item and Indicator constitute a unique reference (i.e. RCMREF) to a LRCM knowledge view. That knowledge view is actually composed of several physical Excel rows (for example, the rows 2 to 7 whose indicators are all "BAAA").

The inserted Function and Failure columns are empty because their SAE JA1011 concepts do not map directly to LSAR B table elements. This is not a LRCM show stopper. These RCM columns will be populated dynamically within the LRCM day-to-day process. The Fmncnabg column is now in column F under the heading "Code".

Because LRCM requires quick readability the letter codes have been replaced by their LSAR descriptions, with one exception. The LSAR "Failure Cause" was rephrased as "due to" (e.g. row 3 of column F). The reason will be obvious to RCM II practitioners who consider separate definitions of "failure mechanism", "failure mode", and "failure cause" to be imprecise. They depend on the depth of causality, which can change from one situation to the next. A failure mechanism is just a failure cause at the next lower link in the causality chain. That is to say, one selects a failure mode (cause, mechanism) at the appropriate causality depth. The "due to" clause provides additional levels of causality as needed.

One final change made by the transformation was to combine records with text spanning two or more rows (for example as in rows 5 and 6). Such fragmented records have been combined into a single row (as in row 5 of the transformed sheet) in accordance with the GEIA-0007 standard. Thus the sequencing column J from the first table has been eliminated.

Summarizing, the LSAR is compatible with the LRCM process. The item, function, failure, and effects are fully visible and updatable. The LRCM process requires a few software enabled features, such as:

1. revison control,
2. verification and authorization of changes,
3. auditing knowledge changes and contributors.

Murray

Thanks for the explanation. I am interested in how you performed the transformation that you described.
Alan

Such transformations can be automated quite easily using Talend. Here is the Talend job:

Here is a description of each component

1. FMs: The process starts with the original data (in this case in about 100 Excel files). This is a tFileList component that gathers up all the files according to the mask that is set up in the component's configuration
2. rcm: This contains the metadata for the excel sheets
3. tUnite_1: This combines all files into a single stream
4. RemoveDashes: This is a Talend tReplace component that is set up to remove dashes from the end item acronym code so that it can be used in an inner join later on with the ERN table (which doesn't have dashes).
5. Add RowId: This is a tJavaFlex component with some java code to add a numerical sequence column to be used for sorting in the next component.
6. ReverseSort: This is a tSortRow component used to reverse sort all rows for processing in the next step.
7. CombineRows: This second tJavaFlex component contains some Java code to combine rows containing text that spans multiple rows.
8. ForwardSort: Resorts the stream in ascending order.
9. tMap_1: Inner joins of the Item names (from the ern Excel sheet) and Failure mode narratives (FmNarratives Excel sheet).
10. RcmKb: Output to a database (Oracle, MySql, or whatever).

Rather than Excel files, the source could have been the LSAR database directly, in which case the Talend job would have been different and probably even simpler. The point is that this method overcomes the first of the four challenges to achieving reliability from data.
Murray

That's very interesting. Do you do a similar transformation for the work order data too? Can you share with us what that Talend job would look like?
Alan

Sure. Here is the job flow diagram.

Here is a short description of each Talend component.

1. Excel WO files / SAP: These are SAP Excel reports of the entire work order table in about 12 files. (Again we could have gone directly to the BAPIs to simplify this step.)
2. Workorders1: Metadata
3. TUnit_1: Combine files into a single stream
4. ComplianceCheck1: Reject any non-integer work orders (general cleaning, etc.) and truncate any oversize functional locations (errors to be fixed).
5. tMap_1:Inner join the Items (i.e. the Items for reliabilty analysis) to the work orders via the Equipment number.
6. EquipmentList: List of Equipment (ItemIDs and their Item names)
7. ComplianceCheck2: Truncate any oversize functional locations.

Of course your Talend jobs would look different depending on the specifics of your data and architectures. But the principles will be the same. The output would look something like this:



Now, we're just about ready to proceed to the second challenge, Managing the work order RCM relationship.
Murray

That sounds like the biggest challenge. How do you do it?
Alan

You're right Alan. It is the most difficult challenge. Nevertheless, it is the key to achieving reliability from data. Therefore, it is the key to achieving continuous process improvement (CPI) in maintenance and reliability.

BI-Cycle has developed the LRCM platform to deal with this challenge. Its important function is the linking of work orders to knowledge records. Here is a screenshot:

The screenshot belies the complexity of the problem, especially when considering that a single work order may reference several RCM knowledge records. Another issue is that the knowledge base is dynamic. It is always changing and growing. Yet the integrity of the work order to knowledge record links must be maintained. As an example, assume that you've decided to split a knowledge record into two records since greater detail is necessary for analysis (inspired, perhaps, by a growing appreciation of the consequences of a particular failure mode). If such is the case, the software needs to let you quickly reassign the work orders between the two new RCM records.

The converse is also a likely requirement. You may decide that there is too much detail in a particular RCM analysis. That is, it is not worthwhile for maintainers to split hairs when reporting the failure mode. In this case you will need to combine two or more failure modes (and their corresponding work order records). The software handles this. Its other major function is to filter and group (called "slicing and dicing") in preparation for challenge three, sample generation.

You've got my attention. Tell me about challenge three.
Alan

Challenge three is about failure mode age tracking. As difficult as that sounds, we do need to track the true working ages at the significant failure mode (component, subsystem) events in order to obtain well defined life cycles (aka histories, lifetimes) for analysis. A sample is a collection of life cycles. Reliability analysis methods require a sample as input. Each life cycle is a "point" in the sample.

The third challenge then is to convert the output of challenge two into a sample (called an Events table). This can get tricky when one considers that serialized components (say engines, or electic motors) can move among different parent equipment with interludes (suspended animation) in a warehouse. Nevertheless, software can handle it. No less is required if we are to proceed to challenge 4.
Murray

Don't stop there. Tell me about challenge four.
Alan

You'll be relieved and happy to hear that challenge four is the easiest one. There is a substantial number of good reliability analysis software products offered by recognized vendors. These products have one thing in common. They need data. Not just any data, but data in the form of a "sample" (not coincidentally, the output of challenge three).

One such product is EXAKT. The EXAKT software extends conventional reliability analysis from two (age and reliability) to many dimensions (that include CBM and process data). For more info on EXAKT head over to the Exakt forum.