Industrial IoT: Predictive Maintenance with Vibration Sensors

Predictive maintenance is one of those IoT promises that has been “two years out” for a decade. The reason most projects underperform is not the AI. It is the basics — sensor placement, sampling, baselines, and the operational link between an alert and a wrench in someone’s hand.

We have shipped predictive maintenance programs for rotating machinery in oil & gas, manufacturing, and renewable energy. The pattern below is what works.

Pick the failure modes first, sensors second

The trap is starting from “let’s put vibration sensors on everything.” Start instead with the failures the customer wants to prevent.

For a typical rotating asset (motor, pump, compressor, fan), the dominant failure modes are bearing wear, imbalance, misalignment, looseness, and lubrication issues. Each has a vibration signature in a different frequency band. A sensor placement and sampling rate suitable for catching bearing defects in their early stage is different from one suitable for catching a coupling alignment problem.

Walk the failure tree with the maintenance team. They already know what fails and how often. The IoT system’s job is to catch those specific things earlier than the current schedule-based approach.

Sensor selection, briefly

For most industrial vibration applications:

• Piezoelectric accelerometers for high-frequency detail (bearing defects, gear mesh issues). Higher cost per sensor, but the data is honest.
• MEMS accelerometers for lower-frequency monitoring (imbalance, misalignment). Cheaper, lower power, and more easily wireless. Good enough for many use cases.
• Triaxial sensors when the orientation of the vibration is diagnostic (it usually is).

Sampling rate matters. Capturing bearing defects requires sampling at 20+ kHz. Most cloud-tethered sensors throttle to 1 kHz or lower to fit the bandwidth budget — which means they cannot see the failures they were sold to catch. Either sample fast and process at the edge, or sample slow and accept the limitations.

Edge processing is mandatory at scale

A sensor sampling 25 kHz across three axes generates 300 KB per second per sensor of raw data. A factory with a hundred sensors at that rate is 30 MB per second, 1.8 GB per minute. No one is shipping that to the cloud.

The right architecture pre-processes at the edge:

• Time-domain features: RMS, peak, crest factor, kurtosis. Computed every second, sent every minute.
• Frequency-domain features: peak energy in defined bands (1× running speed, bearing characteristic frequencies, etc.). Computed on a sliding window.
• Raw waveform on demand: kept in a local ring buffer, uploaded only when a downstream system requests detail for an investigation.

The result is kilobytes per sensor per minute reaching the cloud — easily ingested, queried, and modeled. The raw firehose stays at the edge.

Baselines first, models second

The single most useful tool in predictive maintenance is the per-asset baseline. Each individual machine has a vibration signature when healthy. Deviation from that baseline — even a small one — is more diagnostic than any absolute threshold.

Establishing baselines:

• Collect data for at least one full operating cycle (a shift, a day, a week — whatever covers the asset’s normal load variation).
• Tag the data with operating conditions (load, RPM, ambient temperature). Vibration changes with operating point; the baseline must account for that.
• Recompute baselines periodically. Machines age; what was healthy at install is not healthy at year five.

Most useful early-warning rules are simple: “RMS in the X-band has increased 2× over the rolling 30-day baseline.” Add an ML model only after the simple rules are working — the rules will catch the obvious failures and free the model to find the subtle ones.

Closing the loop with operations

The technical alert is only the first step. A predictive maintenance program that produces alerts no one acts on is worse than no program — it teaches the maintenance team that the dashboard is a distraction.

The integrations that matter:

• Alerts flow into the existing CMMS (computerized maintenance management system) as work orders, not into a parallel email channel.
• Alerts include context: what feature changed, by how much, against what baseline, with a link to the raw waveform.
• Action taken is fed back into the system. Did the alert lead to a finding? What was the root cause? The model improves only if the loop closes.

A program with technical alerts and no operational feedback loop will plateau in six months. A program with the loop closes will keep improving.

What good looks like at year one

A successful program at the twelve-month mark:

• 70-80% of catastrophic failures detected at least one shift in advance.
• Maintenance schedule shifted from time-based to condition-based for the monitored assets.
• A documented set of asset-specific rules and thresholds, refined from the first six months of operation.
• An ML model for anomaly detection deployed alongside the rules — not replacing them.
• Customer’s maintenance team using the system as their primary diagnostic tool, not an audit one.

What it does not look like: a slide deck with a single dramatic catch from month two and a quietly empty dashboard at month nine.

If you have a predictive maintenance project that is technically working but not changing maintenance behavior, the gap is usually in the loop, not the data.