Condition-based maintenance (CBM) is about using the actual data gathered from the assets to decide what maintenance activity needs to be performed on the physical assets being monitored. In other words, it is a maintenance strategy that measures operational parameters in assets to determine a change in their condition, performing maintenance only when the need arises.
The sensors attached to assets transmit a continuous stream of data (their operational parameters) to the cloud platform. This stream of data is then analyzed in the cloud to create rules for maintenance activities.
Let’s take an example of scheduled maintenance service for your automobile to understand the application of condition-based maintenance. The service schedule is usually specified as part of the manufacturer’s operation manual based on the average operating condition rather than the actual usage and current condition of the automobile. Using condition-based maintenance, the service and maintenance activity, like the oil change in your vehicle, should be triggered when the service and replacement are needed based on actual, rather than a predetermined schedule.
The first approach is by creating predetermined rules based on the actual value provided by the devices and executing the required action. For example, if the optimum temperature of an elevator is > 40 and load > 150kg, execute load alert and start the elevator only when the load falls below 150kg.
The rule can be a simple rule or a combination of rules. The rules are laid or visually modelled using a programming language or a tool supported by the core platform.
The second approach is monitoring the values and detecting an anomaly. The anomaly detection is about identifying the data and events which doesn’t conform to the expected pattern as compared to other items in the dataset. For example, assume you haven’t predefined any rules for optimum temperature functionality and data from the devices is being collected every second, say 15, 15, 17, 18 and on the third day you see this pattern 29,.30, 30, 29…, clearly the values read on the first day are less than half of the values read on the third day. This signifies an anomaly in the system, which can trigger an alert for someone to inspect the system.