Six steps to condition-based maintenance

An exciting trend in the world of CMMS is the increasing sophistication of condition-based maintenance (CBM) features and functions vendors offer and maintenance professionals actually use. Perhaps we’re finally turning a corner on the age-old firefighting mentality, replacing it with a more planned environment.

By David Berger, P.Eng.

An exciting trend in the world of CMMS is the increasing sophistication of condition-based maintenance (CBM) features and functions vendors offer and maintenance professionals actually use. Perhaps we’re finally turning a corner on the age-old firefighting mentality, replacing it with a more planned environment. CBM, a form of proactive, preventive or predictive maintenance, can be defined simply as maintenance initiated on the basis of an asset’s condition. Physical properties or trends are monitored on a periodic or continuous basis for attributes such as vibration, particulates in the oil, wear and so on. CBM is an alternative to failure-based maintenance initiated when assets break down, and use-based maintenance triggered by time or meter readings.

Vendors have incorporated CBM into their CMMS offerings in a number of ways. The simplest packages allow manual input of data such as condition readings for triggering PM routines. The more sophisticated CMMS software connects online to PLCs or other shop-floor devices for automated data collection. The software then analyzes incoming data to ensure that trends are on target and within user-defined control limits. When data strays outside limits, the software initiates a work order or takes some other action. It tracks variance from target as well as the worst and best readings.

View more asset management content on PlantServices.com

Condition monitoring versus control

Although condition monitoring is, in most cases, better than waiting for a breakdown, CBM isn’t the ideal solution. Wherever possible, implement automated control systems, as they minimize human error and significantly improve service levels.

For example, suppose a critical piece of equipment is monitored continuously to ensure that some temperature is within an acceptable range. If the temperature rises above the upper limit, a control loop can activate a fan to cool the overheated area until the temperature returns to an acceptable range.

This is clearly superior to a condition-monitoring system that merely alerts a human that the temperature was too high. It’s then up to the human to eliminate the variance condition effectively and efficiently.

However, it isn’t always possible to determine the root cause of a variance automatically. Nor is it always possible or cost-effective to take automatic action. In such cases, human intervention is desirable, making a condition-monitoring system preferable over an automated control system.

For example, when a sensor detects a machine vibration level above the upper control limit by a user-defined amount for a user-defined period, it can initiate an alarm condition. A human might be required to determine the many possible root causes of excessive vibration, such as operator error, raw material problems, jammed parts, machine wear and so on. A human might also be required to determine the most appropriate corrective action. Therefore, it’s impractical to automate the root-cause detection and subsequent control loop to fix the problem.

Six giant steps

There are many permutations and combinations to evaluate when trying to select and prioritize the conditions to monitor, how often, for which components, leading to what actions. Many companies have spent considerable time and money on internal and external resources to make these determinations, and some have been frustrated to the point of abandoning the exercise.

To make the process less onerous, prioritize the assets for which CBM might make sense based on what happens when an asset or component fails. If the consequences of failure are catastrophic (large loss of production, major safety risk), then CBM might be appropriate. Compare the cost of failure or use-based maintenance with CBM for a given asset, and factor in the approximate value of the asset failing to prioritize candidate CBM assets. Apply the six steps below to your prioritized short-list of assets and components. The example provided is for a cooling water system where out-of-range water temperature may have catastrophic consequences.

  1. Determine operating context for the asset being analyzed (cooling water system is to maintain water between 40°F and 45°F).
  2. Define the asset’s functions (maintain water temperature and contain water in the tank).
  3. Assess possible failures (water too hot or too cold).
  4. Identify possible failure modes or root causes (heat exchanger fouled, valve closed, pump bearing fatigued).
  5. Determine the most probable failure effects for each failure mode (inefficient heat exchanger results in higher utility cost, extra cooling tower sections in operation, eventual inability to deliver quality parts).
  6. Propose an appropriate maintenance task for each failure mode using failure history, probability and costs to compare financial and technical feasibility of corrective, preventive or predictive actions (monitor heat exchanger efficiency).

If CBM is the most cost-effective solution, select one or more condition indicators and define the frequency of data capture, the control limits, the business rules for triggering an alarm, and the action(s) to be taken for each indicator. Actions can range from an automated control loop, to sending a page to an area mechanic.

Advanced CBM features on a CMMS

Search for a CMMS package that supports CBM and you’ll find a variety of features. At a minimum, look for the basics such as the ability to establish upper and lower control limits that trigger an alarm, and notification or simple workflow to initiate a task when a trigger occurs. More sophisticated features include:

  • Multiple indicators per asset.
  • Trigger from one indicator resets all other triggers for a given asset.
  • Nesting of triggers with different cycles (cycle A is a 10-point inspection and cycle B = cycle A plus an additional inspection; as opposed to procedure A = 10-point inspection and procedure B = 11-point inspection).
  • Combining indicators using Boolean logic to produce consolidated or alternate indicators.
  • Recommending corrective action based on condition, i.e., using indicators, Boolean logic and/or setpoints (e.g., oil analysis reveals gas, particulate or temperature trends that necessitate a given PM work request).
  • Triggering a PM routine on a preferred day or date if the meter reading is within tolerance.
  • Forecasting when the next meter reading should occur based on historical readings.
  • PM shadowing to avoid duplicate PMs.
  • Overriding or taking credit for corrective work that covers PM work due, to avoid duplication.
  • Validating readings with a user-defined validation formula.
  • Color-coded alarm tables for indicators.
  • Graphic showing component hierarchy and corresponding indicators.
  • Hot spots on the graphic for drill-down to details about indicators.
  • Visibly distinguished conditions and alarms on the graphic (blinking, color change).
  • Acknowledging alarms or conditions easily from within the graphic screen.
  • Entering a new condition easily from within the graphic screen.
  • Dynamic integration of production activity with equipment and component hierarchy on the graphic screen (issue inspection work order to check out root cause of production line slowdown or pressure drop in vessel).
  • Trigger based on calculation of the history of condition readings (average, average variance, sum, median, max or min of last 10 readings must be within certain control limits).
  • Using data from anywhere in the CMMS database to establish a trigger (when ultrasonic reading is greater than the nominal wall thickness by a given factor).

E-mail Contributing Editor David Berger, P.Eng., at david@wmc.on.ca.