Automating CBM

It has been said, with considerable justification, that a condition based maintenance policy is of little practical use to a maintenance organization unless it can be automated. Proliferating oceans of condition data have outpaced the limited human resources that can be dedicated to CBM decision making. The solution is to automate CBM – not only the collection of data but also its interpretation. In this article we’ll describe the automation of EXAKT optimal CBM policies.

Using Exercise 1 as an example^[1], the failure mode to be monitored is “Trans”.^[2] Say the decision model for the Transmission failure mode resides in  \Desktop\Example\Cat340T_DMDR.mdb. Therefore, we can create a batch file, say Cat340T.bat that contains commands similar to those shown below.

We can schedule our command file to run, say, the last Saturday of every month, with a Windows instruction similar to:

When the EXAKT decision agent runs, it populates a table in the “_DMDR” database called “Decisions” illustrated below:

The decisions table is typically viewed using the EAM report generator or in the Mesh cloud deployed Predictive Analytics dashboard below.

Now that we have freed the reliability engineer from the drudgery of having to examine and interpret large quantities of routine CBM data, he can more profitably devote some of his time to Measuring and Improving CBM Effectiveness.

© 2016, Murray Wiseman. All rights reserved.

1. ^[1]In this example the decision model is of a “simple” item. A simple item has only a single failure mode”. Nevertheless the methods described here extend to the general case of “complex” items having more than one failure mode.↩
2. ^[2]Often the object part is all that is needed to specify a failure mode. The full Object part, Object damage, Failure cause syntax is implied to be respectively “Transmission”, “Fails”, due to “n/a”.↩