Condition-based Maintenance (CBM) is about using the actual data gathered from the devices to decide what maintenance activity needs to be performed on the physical assets being monitored.
The connected device provides a set of continuous measurements (temperature, vibrations, air pressure, heat, etc.) for the physical asset. This data along with the required operating specification of the physical assets can be used to create rules for maintenance activities and taking corrective action.
For the elevator use case, we talked about operating temperature requirement earlier as part of the instrumentation design. With the device data being available, the maintenance service can be scheduled whenever the degradation of asset starts.
For example,
X being optimum temperature,
X > Threshold Value –> Alert the service professional. The service professional can inspect the elevator remotely and approve the spare part suggested by the system. The elevators can continue to be functional under limited load, and the load sensor rule now triggers at 150 kg instead of 300 kg. This ensures at any given point; the load does not increase beyond the expected value in case of degradation.
Take another example of a scheduled maintenance service for your automobile. 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 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 is needed based on actual, rather than a predetermined schedule.
There are two approaches to arrive at condition-based maintenance:
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 > 150 kg, execute load alert/beep rule and start the elevator only when the load falls below 150 kg.
The rule can be a simple rule or a combination of rules. The rules can be visually modeled using a programming language or a tool supported by the core platform. The rules are created using the parameters or fields of the device payload. In the above example, optimum temperature, elevator load are the fields defined as part of the payload.
The second approach is monitoring the values and detecting an anomaly. The anomaly detection is about identifying the data and events, which do not conform to the expected pattern as compared to other items in the data set. For example, assume you haven’t defined 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. Another example would be in the case of fire, where this might be detected as an anomaly by the system indicating the dramatic rise in the temperature. There could be another case where fire sensors itself could be tracking fire events. These two cases could be combined to derive a correlation and thereby enabling you to make a more precise observation.
All anomalies might not necessarily be real problems, but detecting anomaly should be a key requirement to ensure any susceptive exceptions are being caught by the system.
Tip – Anomalies can be detected using unsupervised machine learning algorithms like K-means. Libraries such as Spark MLlib provide first class support for many machine learning algorithms.
In future, we could see pre-built templates available for industry verticals which provide the domain model, rules, process flows, machine learning models, anomaly detectors and the job of the system integrator would be to map the device data into the domain model, extend the data model and customize the flow based on the client requirements.
There may be hundreds or thousands of such rules in a complex manufacturing system, and it becomes very imperative to capture such requirements as part of your connected design. The connected design phase is yet to catch on, and most of the noise is around IoT platforms and implementations. The futuristic software products will provide end-to-end IoT implementations from a connected design perspective and also provide large-scale simulations to simulate the design and the end product.