Predictive Maintenance Sensors: What to Measure, Where, and What AI Actually Does

Photo by John Crix on Unsplash.

Predictive maintenance in commercial buildings succeeds or fails on which signals you actually have. Dashboards do not save assets. Sensors for predictive maintenance, plus models that can read them honestly, do. This piece is the technique layer: what to measure on HVAC and rotating plant, where those sensors belong, and what AI predictive maintenance actually does with the data once it arrives. For the wider buildings PdM programme shape, start with predictive maintenance for buildings. This article stays on the sensing and modelling spine.

What to measure on HVAC and rotating plant

Three physical channels catch most of the failures that matter on fans, pumps, compressors and chillers. Everything else is useful context, not a substitute.

Vibration. Imbalance, misalignment, looseness and early bearing wear show up in the vibration spectrum long before a unit trips on temperature or current. A triaxial accelerometer on a motor drive end, or a permanently mounted probe on a fan bearing housing, is the classic sensor for predictive maintenance on rotating equipment. You do not need a laboratory-grade spectrum analyser on every AHU. You need a stable mounting point, a consistent sampling rate, and enough history to know what that specific machine sounds like when it is healthy.

Motor current and VFD amps. Current draw and VFD output amps catch both mechanical and electrical degradation. Bearing friction rises, so the motor works harder for the same speed. A failing phase or a drive that is hunting shows up as a change in the amps-versus-speed curve. Many VFDs already expose these points over BACnet or Modbus, which is why iot predictive maintenance programmes often start here before anyone buys a new vibration kit.

Temperature. Bearing housing temperature, motor winding temperature, supply and return water or air temperatures, and coil approach temperatures catch overheating, fouling and heat-transfer drift. Temperature alone rarely gives early warning of a mechanical fault the way vibration does, but it is cheap, already dense in most BMS point maps, and excellent as a corroborating signal when another channel drifts.

BMS-native points you already have. Valve and damper commanded versus actual position, duct static pressure, differential pressure across filters and coils, and refrigerant-cycle signals (suction and discharge pressure, superheat, subcooling) are not "extra sensors." They are already on the wire. Predictive maintenance IoT deployments that ignore them waste money. When a chiller's approach temperature climbs while compressor amps rise and vibration stays flat, the story is thermal, not mechanical. Cross-signal context is half the technique. For plant-level depth on chillers, see chiller plant optimization.

Where to place them

Instrument critical rotating equipment first. Compressors, supply and return fans, primary and secondary pumps, AHU fan sections, and chiller compressors are the assets whose downtime costs the most and whose failure modes are most visible on vibration, current and temperature. A portfolio with three chillers and forty VAV boxes does not need forty identical sensor kits on day one. It needs the plant that takes the building down when it fails.

Placement rules that hold up in the field:

• Mount vibration sensors on the stiffest part of the bearing housing, not on sheet-metal panels that ring.
• Prefer drive-end and non-drive-end points on motors that already show history of bearing or coupling issues.
• Read VFD amps and speed from the drive or BMS first; add a clamp-on CT only when the drive does not expose a clean point.
• Put temperature probes where heat actually accumulates under load (bearing caps, compressor discharge lines, coil leaving-water), not where the air is conveniently cool for a technician.
• Leave redundant, low-consequence equipment on calendar PM or run-to-failure until the critical set is stable.

Condition monitoring is the sensing layer that feeds this placement decision. The companion piece on condition monitoring in buildings covers how that layer sits under a maintenance policy. Condition based maintenance is the policy that acts when a threshold or model output crosses a line. This article does not replace either; it explains which sensors make both honest.

Vibration, current, temperature: which signal catches which failure

Primary means "usually the first clean flag." Secondary means "useful confirmation once another channel moves." Late means the fault is already expensive by the time the channel moves. No single row is a diagnosis. A rising vibration peak with flat current and flat temperature still needs a technician with a stethoscope or a spectrum tool before anyone orders a bearing. The table is a placement and triage aid, not a root-cause oracle.

What AI and ML actually do with those signals

Artificial intelligence predictive maintenance is pattern recognition on time series, not a mechanic living inside the model. Given enough clean history, a model learns what normal looks like for a given point or asset, then scores how far today's reading sits from that baseline. Six practical outcomes follow from that:

1. Baselines per asset. A fan that has always run a touch hot gets a different normal than the manufacturer's generic curve. Learned baselines beat one-size thresholds when the plant is idiosyncratic, which most retrofit buildings are.
2. Anomaly scores. Drift, spikes, stuck values, forecast residuals and cross-signal incoherence can all raise a score without waiting for a hard alarm. That is the difference between ai predictive maintenance and a BMS limit switch that only fires after the damage is obvious.
3. Remaining-useful-life style trends. Where failure history exists, models can project how long a degrading signature has before it crosses a risk band. Most commercial buildings lack dense failure labels, so RUL estimates should stay humble and come with confidence bounds, not a single confident date.
4. Cross-signal correlation. Vibration up, amps up, bearing temp up is a different story from vibration up alone. Correlation shrinks the candidate list before a person walks to the plant room.
5. Ranked decisions. The useful output is not another chart. It is a queue: which finding matters this week, what evidence supports it, and what to do next. Sensor Intelligence products that stop at dashboards leave the triage on the operator.
6. Thresholds still matter. Rule-based limits are not obsolete. They are the right tool when physics is simple and the failure mode is well known. Learned models add value where the "normal" band moves with load, weather and occupancy. Honest programmes use both.

None of this invents a missing accelerometer. If the point was never measured, the model cannot conjure it. That boundary is why sensor OEMs and analytics vendors still need each other; the co-sell case is spelled out in sensor OEM partnership.

What the models cannot do

Root-cause certainty from sparse points is the first hard limit. Three trending points on a 30-year chiller can narrow candidates. They cannot swear which gasket is leaking. Confirming cause still needs a person with gauges, oil analysis or a teardown when the signature is new to that asset.

Models also cannot invent missing sensors, replace technician judgment, or become a CMMS. Work orders, parts inventory and PM scheduling belong in maintenance management software. Explore is Sensor Intelligence: it reads BMS, meters and IoT, and returns a prioritised decision queue. It is not a CMMS, and we do not market it as one.

Ungrounded language models that "reason" about plant behaviour without the physics of the actual equipment are a separate failure mode. A grounded system checks a suggestion against how that unit actually behaves before the finding reaches a queue. Confidence without grounding is theatre.

Data quality is the gate

Bad points poison predictive maintenance sensors programmes faster than weak models do. A drifted supply-air sensor teaches the baseline the wrong normal. A stuck damper position point suppresses the very correlation that would have caught a failing actuator. One hand-off covers the failure modes in depth: smart building sensor data failures. Fix completeness, units, timestamps and liars before you trust an RUL curve.

Virtual sensors can fill redundancy when a correlated physical signal exists. They are not a licence to skip instrumentation on critical rotating plant. Treat them as a bridge, flagged as derived, and see virtual sensors in buildings for the boundary. For how HVAC-specific models use the same telemetry once quality is under control, the technique sibling is HVAC AI.

Putting the signals to work

FrostLogic Explore is Sensor Intelligence for smart buildings. It reads the BMS points and IoT sensors you already trust, runs anomaly detection, forecasting with confidence bounds, and what-if checks, and returns a prioritised decision queue. The tagline holds here: the dashboard is the question; the queue is the answer. Write access starts off by default and is granted per scope. Inside a granted scope, a proposed change waits for human review or runs automatically. Nothing writes outside a scope you turned on. Capability detail for the PdM lane lives on predictive maintenance; how the same feed lands as BMS analytics is on BMS analytics.

If you want to walk a plant-room point map and see which signals would actually move a queue, talk it through.

FAQ

Do I need new IoT sensors, or are BMS points enough for predictive maintenance? Often BMS points are enough to start, especially VFD amps, temperatures, pressures and valve or damper feedback. Dedicated vibration or current sensors help on critical rotating assets where the BMS never exposed a mechanical channel. IoT predictive maintenance works best when both layers feed the same model: BMS for context, added sensors for the failure modes the BMS never saw.

How is AI predictive maintenance different from rule-based thresholds? Thresholds fire when one point crosses one fixed limit. AI predictive maintenance learns a baseline per asset, scores drift and forecast residuals, and correlates across signals. Rules stay useful for simple physics. Models earn their keep when normal moves with load and season, and when one root cause would otherwise become a dozen independent alarms.

Is Explore a CMMS? No. A CMMS schedules work, tracks parts and closes work orders. Explore detects, forecasts and ranks decisions from sensor and BMS data. The two sit side by side. Explore does not replace maintenance management software.

Do more sensors always improve predictive maintenance? No. More noise, duplicate points and unvalidated installs make models worse. Instrument the critical rotating set first, validate the points you already have, then add channels that close a known failure-mode gap. Sensors for predictive maintenance only help when the data is trusted.

Does Explore write back to the BMS automatically? Write access starts off by default. You grant a scope when you want action, and inside that scope a proposal either waits for approval or runs automatically. Detection and ranking happen regardless. Writes only happen where you explicitly turned them on.

What is the difference between predictive maintenance IoT and condition monitoring? Condition monitoring is the sensing and data layer. Predictive maintenance IoT is that layer plus models that forecast or score degradation toward a decision. You can monitor condition without predicting. You cannot run honest PdM without condition data that holds up.

Can AI invent a vibration signal I never installed? No. Models can infer some quantities from correlated readings (virtual sensors), but they cannot manufacture a mechanical channel that was never measured. If bearing wear is the failure mode you care about, plan for a real vibration path on that asset.

Where should a portfolio start if budget is tight? One critical plant (a lead chiller or a primary AHU fan set), the BMS points already on that plant, plus vibration or current only where the BMS is blind. Prove the queue is useful, then scale. Portfolio-wide sensor shopping lists without a triage design are how programmes stall.