Condition monitoring is a model, not a purchase

The word condition monitoring has been claimed by vibration-analysis vendors and IoT platforms for so long that it now sounds like a hardware category. For a maintenance team, it is something simpler and more durable: a structured way to record what an asset's key parameters are doing over time, decide what good and bad look like, and act when a reading crosses a line.

That definition matters because it changes where you start. If condition monitoring is hardware, the project begins with procurement and a controls integrator. If condition monitoring is a model, the project begins with a question you can answer today: which parameters on which assets, if they drifted, would cause the failures that hurt us most? You can start monitoring those this week with the readings your technicians already take on rounds.

The hardware is not wasted ambition. It is the second step. Once the model is in place and people trust it, wiring a gateway to push readings automatically is a small change, not a new system.

Start with parameters and limits

A monitored parameter is the unit of condition monitoring. Each one ties to an asset and carries four things: the unit it is measured in, a warning limit, a critical limit, and the action that should happen when each limit is breached. That is the entire contract, and it is enough to be useful.

Pick parameters where a trend precedes a failure rather than ones that only confirm it after the fact:

  • Bearing or motor temperature, where a slow climb often leads a mechanical failure by days.
  • Hydraulic or line pressure, where drift signals a leak, a worn pump, or a fouled filter.
  • Furnace or process temperature, where excursions threaten both the asset and the product.
  • Lubricant level or flow, where a quiet decline ends in a seized component.

Setting the limits is a conversation, not a science project. Start with the manufacturer's range and your own bad memories of what the reading looked like before the last failure. The limits are not permanent; the point is to get a defensible first line in place so the system has something to compare against.

Capture readings where the work already happens

The reason condition monitoring programs stall is rarely the analytics. It is data capture. If logging a reading means walking back to an office and opening a spreadsheet, the readings stop the first busy week. The model only holds if capture sits inside the work the technician is already doing.

Two capture paths feed the same append-only reading log. A technician on rounds enters the reading on a phone at the asset, the same way they complete a checklist. Or a PLC, SCADA, or IoT gateway pushes readings automatically through a token-authenticated ingest API. Because both land in one immutable time series, you can digitize the manual readings first and automate only the assets where continuous data justifies the integration. Nothing has to be rebuilt when the gateway arrives.

An append-only log matters for more than tidiness. When a reading becomes evidence in a breakdown investigation or an audit, it has to be clear that it was recorded at the time and not edited afterward.

Classify at write, then act

The difference between a logbook and a monitoring system is what happens at the moment a reading is written. Each reading should be classified immediately as normal, warning, or critical against its limits, and that classification should drive an action without waiting for someone to review a report.

A warning notifies the users scoped to that asset so a human can decide whether to plan work. A critical reading is treated as a real event: it can automatically open a breakdown so the response starts now, not at the next round. To avoid drowning the team, repeated criticals on the same parameter should deduplicate into one open breakdown rather than a new one every reading.

This is the loop that earns trust. The first time a critical reading opens the right breakdown before anyone noticed the machine was in trouble, condition monitoring stops being a compliance chore and becomes the thing the morning meeting looks at first.

Turn readings into a forward-looking signal

A history of readings is only worth collecting if it changes what you do next. The asset view should make the trend obvious at a glance: a health banner, a card per parameter with a sparkline and recent statistics, and a fuller threshold-band chart that plots the readings against the warning and critical lines with the breaches marked.

Two derived signals do most of the forward-looking work. A drift-to-limit projection estimates when a parameter will reach its limit if the current trend holds, which converts a vague worry into a plannable date. Stale-sensor detection flags parameters that have stopped reporting, because a monitor everyone trusts that quietly went silent is more dangerous than no monitor at all.

At the fleet level, the same data ranks the assets that need attention now and surfaces the sensors that have gone stale, so a reliability lead can triage a whole plant from one screen instead of opening assets one by one.

Where this leads

Condition monitoring done this way is valuable on its own: fewer surprise failures, breakdowns that open themselves, and a maintenance record that shows you were watching. It also leaves you with a clean, trustworthy reading history — the prerequisite for any heavier condition-based analysis you might choose to add later, rather than a promise that model-based prediction is around the corner.

So the sequence is the point. Put limits on the parameters that matter, capture the readings where the work happens, act at write, and let the data tell you where automation and prediction will pay off. You end up with a condition-monitoring backbone you trust, built without ripping out a single PLC.