CBM

Condition Monitoring

Definition

CBM (Condition-Based Maintenance, condition monitoring/state-based maintenance) is a maintenance strategy based on real-time equipment condition data. By collecting equipment operation data through sensors such as vibration, temperature, current, oil, and acoustics, and combining threshold judgment or machine learning algorithms for fault diagnosis and remaining useful life prediction, maintenance is triggered when condition indicators exceed thresholds. This enables a shift from scheduled maintenance (TBM) to on-demand maintenance, reducing maintenance costs and minimizing unplanned downtime.

CBM is a core component of PHM (Predictive Health Management) and follows standards such as ISO 13374 and ISO 17359. The data collection frequency ranges from seconds to hours, depending on the type of equipment and failure modes.

Technical Features

CBM uses an edge + cloud architecture: the edge side performs real-time collection, preprocessing, and simple alarms; the cloud performs in-depth analysis, model training, and trend prediction. Vibration analysis, oil analysis, and thermal imaging are common methods. IoT SIM cards provide stable connectivity for sensors and edge gateways distributed in factories, wind farms, and along railways, ensuring real-time transmission of condition data to the PHM platform.

Use Cases

CBM is widely applied in industrial scenarios such as wind power, rail transportation, mining, petrochemicals, electric power, aviation, and shipping. Typical applications include rotating machinery vibration monitoring, bearing fault warning, transformer condition assessment, and track condition monitoring. SimtoLink provides stable connectivity, dedicated APN, and industrial IoT solutions for CBM sensors and edge gateways.

When sampled condition is enough to trigger maintenance

In condition-based maintenance the IoT SIM carries condition values the edge has already chosen, not a vibration waveform moved to the cloud without selection. The failure mode of a bearing, a gear, or a transformer decides the sampling: some watch a slow temperature change, some a vibration spectrum, some particles in oil. The technical point is a chain that can be stated from threshold to work order: which point, which feature, how long it persisted, and whether the edge already filtered the startup shock. A SIM outage should not automatically open an “equipment fault” work order, and a real excursion alarm should not wait in a queue until the next hour. Waveform files and periodic features must travel apart. One upload of a raw waveform will otherwise delay every temperature point for the day.

The conditions are whether the equipment allows an edge gateway, and whether the site is reachable only by cellular. The gateway should store features and unsent alarms locally and, when the connection returns, report them at the sample time rather than rewrite the trend at the arrival time. Time sync has to be stable, or different points cannot be correlated. Access should be restricted to the analysis platform. Certificate updates need a window in which the old certificate still works, so the whole site’s gateways do not lose the connection on the same day. Bind the SIM to the equipment tag and the sensor id. When a sensor is replaced in maintenance, keep the end of the old curve. If large files are allowed only in a shutdown window, write that window into the gateway policy. It must not share priority with alarms during production. Measure coverage at the install point in a wind nacelle, a mine roadway, or a ship compartment. A metal housing makes the signal strength from the lab meaningless.

A common error is to treat a catch-up spike after communications return as a sudden change in equipment condition and open a repair order automatically. Another is a sample rate pushed down by the data plan until the fault frequency can no longer be seen. The curve is still “online” and can no longer support the original criterion. Several gateways sharing one egress with no equipment tag draw neighboring machines’ temperatures on one line. A firmware upgrade that restarts acquisition during production leaves a stretch of zeros, which a model then learns as a normal stop. Acceptance should use a known startup shock and an intentional link cut, and check that a work order appears only when the rule is met and that catch-up points land on the original time. A fuller health-management frame is described under PHM.

A maintenance work order should name the feature that triggered it, how long it persisted, and whether the data was complete. A spike caused by communications catch-up has to be excludable by the rule. A loose sensor, a change in mounting torque, and real bearing wear can all raise vibration. Without an installation event they cannot be separated. The edge should keep the original basis of the judgment for as long as the work order stays open. Otherwise the curve is still on the platform and the site can no longer review it. Mark the first run after a model update as observation. Do not immediately generate work orders in bulk from the new threshold. Rate-limit large-file upload inside a shutdown window, and keep it off alarms that are happening now. When the same equipment changes gateway, stop the old SIM and let the new SIM inherit the tag. Record the gap as “replacement,” not “equipment stopped.” If the site has only periodic features and no agreed sample rate, the report should say the current data cannot support the original fault-frequency judgment, rather than still issuing a definite repair conclusion.

When a work order is closed, write whether the basis was a live alarm or catch-up after the fact. Catch-up data cannot prove that someone was sent at the time. Mark the run-in period after a sensor replacement on its own. Thresholds during run-in may differ, but the difference has to be visible on the curve. Before edge storage is cleared, confirm the platform has accepted the features for that interval. Clearing them deletes the basis of the judgment. Record the clear itself on the equipment history, so a later gap in the curve can be explained.


Related Terms

Back to the IoT SIM Card Glossary