Skip to main content
predictive-maintenanceiiot-sensorscondition-monitoringvibration-analysis

IIoT Sensors for Predictive Maintenance: Which Sensor, Which Failure Mode

Prevly Team·

IIoT Sensors for Predictive Maintenance: Which Sensor, Which Failure Mode

In one line: The sensor you need is decided by the failure mode you're chasing, not by a catalog. For most rotating equipment, three signals (vibration on the bearings, temperature, and motor current) cover the majority of failure modes; you add pressure, flow, acoustic, or speed where a specific fault demands it. Two or three well-placed sensors beat a dozen poorly chosen ones.

The plant that instrumented everything and still got surprised

A maintenance team decides to get serious about condition monitoring. They buy a pile of IIoT sensors, clamp them onto the critical assets, wire everything up, and wait for the platform to warn them about the next failure. Three months later a gearbox seizes with no alert. When they go back through the data, the reason is obvious: they mounted a general-purpose sensor sampling once a second on a bearing whose defect frequency lives at 4,000 Hz. The signal that would have caught the fault was never in the data. They didn't have a monitoring problem. They had a sensor-selection problem.

This is the quiet failure mode of IIoT projects. It's easy to buy sensors and hard to buy the right sensors, mounted the right way, sampling fast enough, in the right place. Choosing well starts with a question most sensor catalogs never ask: what failure am I actually trying to catch?

What IIoT sensors do in predictive maintenance

An IIoT (Industrial Internet of Things) sensor is a networked sensor whose readings flow off the machine into a system that can analyze them: a time-series database, a feature pipeline, a predictive model. In predictive maintenance, the sensor's job isn't to display a number on a gauge; it's to produce a signal that a model can watch for the early signature of a developing fault. The value is in the coverage (which failure modes your chosen sensors can see), not in the count.

That reframes the buying decision. You're not asking "how many sensors can I afford?" You're asking "which physical symptoms does each of my critical failure modes produce, and which sensor reveals that symptom soonest?" Get that mapping right and three sensors outperform thirty.

Start from the failure mode, not the sensor

Every failure mode announces itself through physics before it announces itself through a breakdown. A degrading bearing produces impacts, then heat. A cavitating pump produces pressure pulsations and a distinctive high-frequency hiss. A motor with a broken rotor bar produces sidebands in its current draw. The sensor is just the instrument that hears the announcement.

So the selection logic runs backwards from the catalog:

  1. List the dominant failure modes for the asset (a criticality analysis or a plain FMEA does this: bearings, seals, imbalance, cavitation, electrical).
  2. Name the physical symptom each one emits (mechanical vibration, heat rise, pressure pulsation, current sideband, acoustic emission).
  3. Pick the sensor that reads that symptom earliest and most cleanly.

Do that and you'll usually find the same two or three signals keep coming up. That's not a coincidence: it's why vibration, temperature, and motor current are the workhorses of condition monitoring.

The sensor-to-failure-mode map

Here's the reference. It maps the sensor types a predictive platform ingests to the failure modes each one reveals, how early it typically catches them, and where it goes blind. Screenshot it before you spec a single sensor.

| Sensor | Failure modes it reveals | Typical lead time | Blind spot | |---|---|---|---| | Vibration (accelerometer) | Bearing defects, imbalance, misalignment, mechanical looseness, gear-mesh faults, resonance | Weeks to months (bearings, in the frequency domain) | Slow thermal/lubrication faults; useless if under-sampled or badly mounted | | Temperature (RTD / thermocouple) | Bearing overheating, lubrication breakdown, winding/insulation degradation, cooling loss, friction | Hours to days: a confirming, mostly lagging indicator | Early mechanical defects (vibration sees a spalling bearing weeks before temperature moves) | | Motor current & voltage (MCSA) | Broken rotor bars, air-gap eccentricity, stator faults, load anomalies, supply problems | Weeks (electrical faults); non-contact and cheap to add | Needs the motor running under load; less direct on driven-equipment mechanics | | Acoustic / ultrasonic | Very-early bearing fatigue, lubrication starvation, compressed-air/steam/vacuum leaks, electrical partial discharge, steam-trap and valve faults | Often the earliest bearing warning; immediate for leaks | Noisy environments; specialized sensors; harder to trend continuously | | Pressure | Cavitation, blockage/fouling, seal leakage, valve faults, filter clogging, hydraulic/pneumatic degradation | Varies: fast for cavitation, slow for fouling | Process-side only; won't see bearing or electrical faults | | Flow rate | Pump wear and efficiency loss, blockage, leakage (paired with pressure) | Slow: a gradual efficiency drift | Insensitive to mechanical/electrical root causes | | Speed (RPM) | Belt slip; and it's the reference that makes vibration order-analysis and current signatures interpretable | Context signal, not a standalone fault detector | Rarely a fault source by itself |

The pattern the table exposes: no single sensor sees everything, and the sensors overlap on the faults that matter most. That overlap is a feature: a bearing that's failing shows up in vibration and, later, in temperature, and the two agreeing is stronger evidence than either alone.

The three workhorses, in depth

Vibration: the richest signal for rotating equipment

If you buy one sensor for a pump, motor, fan, compressor, or gearbox, buy an accelerometer. Vibration carries more information about mechanical health than any other single signal, because nearly every rotating fault (imbalance, misalignment, looseness, and especially bearing degradation) modulates the machine's vibration in a characteristic way.

The catch is that the useful information lives in the frequency domain, and getting there imposes real requirements. Bearing defect frequencies (BPFO, BPFI, BSF, FTF: the bearing fault frequencies derived from geometry and shaft speed) sit at hundreds to thousands of Hz, and the early-warning energy sits higher still. A sensor sampling at 1 Hz for a temperature-style trend is worthless here. Continuous bearing monitoring wants raw waveform capture in the multi-kHz range (12.8 kHz is a common working figure) so an FFT can resolve those defect frequencies and their harmonics.

Placement and mounting decide everything else. An accelerometer belongs on the bearing housing, in the load zone, rigidly coupled: a loosely mounted or badly oriented sensor produces data no model can rescue. Two axes on a critical bearing beat one. And once you have the signal, ISO 20816 severity zones give you the vocabulary for how bad "bad" is.

Temperature: slow, unglamorous, and honest

Temperature is the sensor everyone already has and nobody thinks about. An RTD or thermocouple on a bearing, a winding, or a casing updates slowly (seconds are fine) and asks nothing of your sample rate. What it gives you is a signal that's hard to argue with: heat rise is a near-universal late symptom of friction, lubrication failure, electrical loss, and cooling problems.

Be honest about what "late" means. By the time a bearing is meaningfully hotter, the vibration signature has usually been climbing for weeks. Temperature is a confirming indicator, not an early-warning one, which is exactly why it pairs so well with vibration. Vibration tells you something is developing; temperature tells you it's progressing. Cross-sensor correlation is where the real diagnostic confidence comes from: rising vibration with rising temperature is a bearing; rising temperature with flat vibration is more likely a cooling or lubrication issue.

Motor current: the non-contact workhorse

Motor Current Signature Analysis (MCSA) is the signal reliability engineers underuse. A clamp-on current transformer on the motor leads reads the machine's electrical behavior without touching the mechanics: no drilling, no mounting on a hot or hazardous surface, often installable in the MCC. In the current spectrum you can see broken rotor bars, air-gap eccentricity, stator winding faults, and load anomalies, and because mechanical faults modulate the load, current sometimes carries a mechanical story too.

Its limits are the flip side of its convenience: the motor has to be running under load for the signature to appear, and it reads the motor most directly: the driven equipment's mechanical faults show up more faintly. As a cheap, non-invasive complement to vibration, though, it's hard to beat. Bearing-related problems are consistently the leading category of electric-motor failure in the classic IEEE and EPRI motor-reliability studies, which is why vibration-plus-current on a critical motor covers so much ground.

The rest, briefly

Acoustic and ultrasonic sensors catch the earliest bearing fatigue and lubrication starvation (subsurface stress emits high-frequency acoustic energy before it emits classic vibration defect frequencies), plus a whole class of faults the others miss: compressed-air and steam leaks, failing steam traps, valve passing, and electrical partial discharge. Pressure and flow are the process-side pair: they reveal cavitation, fouling, seal leakage, and pump efficiency loss that a vibration sensor never will. Speed (RPM) rarely detects a fault on its own, but it's the reference that makes vibration order-analysis and current signatures interpretable: without shaft speed, a defect frequency is just a number.

Where sensor selection goes wrong

More sensors is a vanity metric. The three ways IIoT sensing actually fails have nothing to do with count:

Wrong sample rate. The single most common mistake, and the one that seizes gearboxes silently. A sensor sampling too slowly to resolve a fault's frequency simply doesn't contain the fault. Match the sample rate to the failure mode: high for bearings and gears, slow-and-fine for thermal trends.

Wrong placement or mounting. A sensor on the wrong side of a coupling, at the wrong orientation, or loosely attached produces data that looks plausible and means nothing. Mounting is where vibration projects live or die.

One sensor, one failure mode thinking. Real diagnosis is multi-signal. The strongest evidence comes from sensors agreeing: vibration and temperature both trending on the same bearing, or pressure and flow both drifting on the same pump. A platform that fuses signals catches faults that any single channel would miss, and rejects false alarms that a single channel would raise.

And one question every reliability engineer asks: what happens when a sensor itself fails? It will: clamps loosen, cables chafe, transmitters drift. A monitoring system built for a real plant has to tell a sensor fault from a machine fault and keep running on what's left, rather than emitting a phantom machine anomaly because a channel went dead. For measurements you genuinely can't lose, the answer is deliberate redundancy (a second accelerometer on the critical bearing), decided up front.

How many sensors, and where

The honest answer to "how many sensors per machine?" is: as few as cover your dominant failure modes cleanly, and no more. For a typical critical pump or motor, that's often three channels (vibration on the drive-end bearing, temperature on the same bearing, and motor current), with a second vibration axis or a second bearing added where criticality justifies it. You instrument the failure modes that will actually stop the line, not every measurable quantity.

Spend the budget you'd have wasted on breadth to buy quality and correct installation on the few signals that matter. A well-mounted, correctly-sampled accelerometer on the right bearing is worth more than a network of cheap transducers reporting numbers nobody can act on.

A worked example: picking the signals for a pump

Here's the selection logic on a single asset: illustrative of the method, not a specific customer result. Take a critical centrifugal pump. Its dominant failure modes are bearing degradation, seal failure, cavitation, and motor faults.

Work the map. Bearings → vibration on the drive-end and non-drive-end housings, sampled fast enough to resolve defect frequencies, with temperature on the drive-end bearing as the confirming indicator. Cavitation and seal issues → pressure at the suction and discharge, optionally with flow to catch efficiency drift. Motor faults → a clamp-on current transformer on the supply. That's four sensor types covering four failure modes, chosen because each reads a symptom the others can't, not because a catalog bundled them. A general-purpose sensor sampling once a second on the casing would have covered none of it.

What this looks like with Prevly

Prevly is built to work with the sensors you choose, not a proprietary hardware kit:

  • It uses your existing sensors. Prevly ingests vibration, temperature, pressure, current, voltage, flow rate, RPM, and acoustic signals over read-only OPC-UA or MQTT. There's no swap-out, no vendor-locked transducer: whatever speaks a standard protocol drops in, and if the machine has nothing, you retrofit external sensors and a read-only gateway.
  • It fuses the signals instead of watching them one at a time. The models learn each asset's normal across all its channels, so a bearing confirmed by vibration and temperature reads as high-confidence, and a dead channel reads as a sensor problem (validated and quality-scored per reading), not a phantom machine fault.
  • Every alert names the sensor that drove it. Feature attribution reports which signals moved and by how much, so your engineer verifies the finding against the physics instead of trusting a black-box score. RUL estimates come as conformal prediction intervals, validated on real NASA C-MAPSS data (an honest RMSE 14.33 on the standard FD001 test).
  • It runs on-premise. The pipeline, storage, and models stay inside the plant network.

Scoping which sensors go where on your specific machines is part of setting up a pilot, not a self-service checkout: we work through the failure modes and the placement with you before anything gets mounted.

Frequently asked questions

What sensors do I need for predictive maintenance? Start from the failure modes, not the catalog. For most rotating equipment the core set is vibration on the bearings, temperature, and motor current: those three cover the majority of mechanical and electrical failure modes. Add pressure, flow, acoustic, or speed where a specific fault (cavitation, leaks, early bearing fatigue) demands it.

How many IIoT sensors does one machine need? As few as cover its dominant failure modes cleanly. For a typical critical pump or motor that's often three or four channels: vibration, temperature, and current, plus pressure where cavitation matters. Two or three well-placed, correctly-sampled sensors outperform a dozen poorly chosen ones. Instrument the failures that stop the line, not everything measurable.

Which sensor detects bearing failure earliest? Acoustic/ultrasonic energy rises first (subsurface fatigue, sometimes months out) but is subtle; vibration is the reliable workhorse, catching defect frequencies weeks to a couple of months ahead in the frequency domain; temperature moves last, confirming a fault that's already progressing. A platform that watches vibration continuously and correlates temperature gives the most actionable window.

Do IIoT sensors have to be wired into the machine's PLC? No. Condition-monitoring sensors mount non-invasively on the outside of the asset and publish their data through a gateway to a monitoring system that reads them: it never writes to the control system. A read-only path is a passive observer, which is exactly what an OT-security review wants to see.

Can I use the sensors I already have? Usually, yes. If your machine already exposes vibration, temperature, current, or pressure over OPC-UA or MQTT, a predictive platform can ingest them directly with no new hardware. You add sensors only for the failure modes your existing instrumentation doesn't cover.

Spec the sensors for one machine

You don't need to instrument the plant to start. Pick your most critical asset, list the failure modes that would actually stop it, and choose the two or three signals that read those symptoms earliest. Get those mounted well and sampled right, and you'll have coverage that a truckload of the wrong sensors would never buy.

Request a Prevly demo and we'll map the failure modes to a sensor set for your first machine with you.

Related reading: Retrofit PdM onto old machines · Bearing fault frequencies explained · ISO 20816 vibration severity · Getting started with vibration analysis · From sensors to predictions