IoT predictive maintenance: from vibration data to a maintenance decision

What IoT predictive maintenance is

Predictive maintenance

Maintenance planned from the measured condition of a machine and the trend of that condition, rather than from a calendar or after a breakdown.

Most rotating machinery fails gradually. A bearing with a damaged race, a misaligned coupling or an unbalanced rotor changes how the machine vibrates long before it stops. Preventive maintenance ignores that signal and replaces parts by the calendar; reactive maintenance waits for the breakdown. Predictive maintenance watches for the change and plans the repair around it.

IoT is what makes this practical across a whole plant. Route-based vibration surveys with a portable analyser have existed for decades, but a technician visits each machine only now and then. A connected sensor measures all the time, sends the result over a network and lets software watch many assets at once. The question this article answers is what has to be true at every step for that stream of data to end in a maintenance decision that a team trusts.

The engineering chain from sensor to work order

Every predictive maintenance system, bought or built, has the same five links. A weakness in an early link cannot be repaired by a later one: no model can find a fault frequency that the sensor never captured.

Choosing and mounting the sensor

Vibration is the most informative signal for rotating machinery, because most mechanical faults – imbalance, misalignment, looseness, bearing and gear damage – show up in it first. Temperature usually rises later, when the damage is already advanced. Motor current helps where nothing can be mounted on the machine itself.

• Sensor type. MEMS accelerometers are compact, inexpensive and easy to build into a connected node; piezoelectric sensors cover a wider frequency range with lower noise. Early bearing damage shows at high frequencies, so check bandwidth and noise floor against the faults you want to catch, not only the price.
• Axes. One axis can miss a fault that shows in another direction. Misalignment often appears axially, imbalance radially. Multi-axis sensing adds little cost at the sensor and saves a second installation.
• Mounting. The mount is part of the measurement. A stud or a rigid bonded mount on a clean, flat surface near the bearing passes high frequencies; a magnet, or a sensor on a thin cover plate, damps them or adds resonances of its own. Mount the same way on every machine of a type, or the readings cannot be compared.
• Environment and power. Heat, oil, washdown and metal around the antenna decide whether a wireless node works in practice. A battery-powered node trades how often it measures against how long it lasts, and that is a design decision, not a detail.

Sampling, and where to process the signal

The sampling rate has to cover the highest fault frequency you care about, with margin, and each capture has to be long enough to separate the closely spaced frequencies that tell one fault from another. Slow machines need longer captures; fast ones need higher rates. Machines with variable speed also need the speed at the moment of capture, or the spectrum cannot be read correctly.

Raw waveforms are large. Streaming all of them from every node is rarely sensible over a low-power radio or a metered connection, so most systems split the work between the edge and the cloud.

The hybrid row is the usual answer: compute features continuously at the edge, send them on a schedule, and capture a full waveform when something changes, so that an analyst or a model has the evidence behind each alert.

Reference levels, machine learning or both

There are two ways to decide that a machine is no longer healthy. Reference levels are fixed limits: an overall vibration level, or the amplitude at a known bearing or gear frequency, that should not be exceeded on this machine. They are transparent, easy to explain to a maintenance team and work from the first day. Their weakness is that one limit rarely fits every machine, load and speed.

Machine learning instead learns what normal and faulty look like from data. Supervised models take features such as RMS, kurtosis, crest factor and the energy around the running speed and its harmonics, and classify the state of the machine or the type of fault. They adapt to each asset and can tell an inner-race defect from looseness. They need history, ideally with confirmed faults, and someone who owns their errors.

For feature-based vibration diagnostics, a random forest is often the most practical first model. It combines many decision trees, captures non-linear relations between features, tolerates noisy measurements and needs little memory and compute, so it can run on a gateway or even on the sensor node. Support vector machines are a similar option. Deep neural networks working on raw spectra or waveforms can find patterns that hand-made features miss, but they need far more labelled data and compute. Fuzzy logic sits between rules and learning: it encodes an engineer’s diagnostic rules but grades the answer – normal, warning or fault – instead of a hard yes or no.

My own research has been on the signal side of this choice: correlation analysis of rolling-bearing vibration with outer- and inner-race defects, a vibration monitoring platform for in-wheel electric motors, and data-driven detection of wheel imbalance from accelerometer signals. It grew out of work with colleagues at the Karpenko Physico-Mechanical Institute of the National Academy of Sciences of Ukraine on correlation and coherent cross-spectral analysis of vibration as a periodically non-stationary random process, and continued with colleagues at Ivan Franko National University of Lviv. In the published imbalance study the classifier is a fuzzy-logic algorithm that grades each analysis window as normal, warning or imbalance; in a follow-up paper, not yet published, I train a random forest on time- and frequency-domain features from the same kind of test bench. What I take from that work is that features grounded in the physics of the machine are what make any model trustworthy. Start with reference levels, keep the waveforms, and add machine learning once you have labelled faults to teach it.

Adding cameras: what vibration cannot see

Vibration shows how rotating parts behave. It says little about what a conveyor looks like. A torn or drifting belt, material spilling at a transfer point, a blocked chute, a damaged roller or a guard left open can all develop without a clear vibration signature. Cameras see them directly.

Computer vision models running on or near the camera can watch a line continuously: track the belt edges to detect drift, compare frames with a reference to spot damage or foreign objects, and flag spillage or jams. Like vibration models, they need training images from your own line, lighting that stays consistent, lenses protected from dust and a clear rule for what becomes a warning.

At Indeema we also use cameras that analyse conveyors and other machine elements visually. The two signals answer different questions – vibration describes how rotating parts behave, images describe the condition and position of the parts you can see – so warnings from both should reach the same person and the same work order.

From early warning to a work order

A prediction that nobody acts on prevents nothing. The last link is as much organisational as technical: who receives the warning, what it contains and how it becomes planned work.

Connect warnings to the maintenance system the team already uses, so a confirmed warning opens a work order with parts and a time window instead of an e-mail that gets lost. Then count false alarms as seriously as missed faults: every needless inspection costs a technician’s time, and too many of them teach people to ignore the system. The downtime cost method gives you the figures to weigh a missed failure against an unnecessary visit.

A worked example: iReDS

iReDS is a vibration-diagnostics product owned and developed by Indeema, and it follows the chain above. An accelerometer unit captures multi-axis vibration from rotating machinery, the signal is analysed against reference levels, and operators get alarms, a dashboard and reports. People decide and act on them; the system does not control the machine.

On top of the reference levels, AI analyses vibration signals and identifies the type of fault in bearings and other rotating mechanisms. That is what moves iReDS from condition monitoring to predictive maintenance: it warns of developing faults before failure so maintenance can be planned, instead of being forced by a breakdown.

As reported, iReDS reduces the number of unplanned downtimes caused by failures of key machine elements by up to 75%. That is an upper bound on monitored equipment in operation, not a typical or guaranteed result. What a plant gains depends on its machines, its failure history and how quickly warnings turn into work.

If you are weighing this kind of system for a production floor, see how it fits alongside other connected systems on the manufacturing page.

When condition monitoring is enough

Predictive maintenance is not always worth it. Data, models and the discipline around alerts all cost money, and on some equipment a simpler approach wins.

• Cheap, redundant or quickly swapped assets. If a standby pump can be switched in within minutes and the failure damages nothing else, run-to-failure or a periodic check can cost less than any sensor.
• Fast or random failures. Electronic faults and some hydraulic failures give little warning in vibration. A trend-based system has nothing to trend; protect these with design, redundancy or simple alarms instead.
• No history and no confirmed faults. Without them a learned model has nothing to learn from. Reference levels with sensible alarms – plain condition monitoring – are the honest first step, and they build the history a model will need later.
• No one to act. If warnings cannot become planned work within the time they give you, a prediction only tells you earlier about a breakdown you will still have.

A practical rule: start with condition monitoring on the machines whose failures cost the most, keep the data, record what every inspection finds, and move to prediction where the history shows faults that develop slowly enough to plan for.

Where to start

If the list shows that sensing hardware, firmware and analytics have to be designed together for your equipment, that is research and development work rather than an off-the-shelf installation. Start with one line, prove the chain end to end, then scale.