OT Asset Health Monitoring Without Ripping Out Legacy Systems

You almost certainly do not need to replace control hardware to monitor asset health. In most brownfield plants the majority of the useful signal is already being measured and then discarded: motor current, run hours, start counts, cycle times, valve stroke times, filter differential pressure, and years of alarm history. It is not kept, not contextualised, and not connected to the maintenance record. Retrofitting monitoring is mostly a data problem, and new sensors belong only where the existing signals genuinely cannot answer the question.

That framing matters because the usual proposal is the opposite. A vendor-agnostic condition monitoring programme is presented as a capital project involving sensors on everything, and it dies in the budget cycle. The version that survives starts by harvesting what is already there, proves value on a handful of assets, and buys sensing selectively out of the savings.

Three terms that get used interchangeably

They are not the same thing, and conflating them is how scopes get out of control.

Condition monitoring measures the physical condition of a machine directly: vibration, temperature, oil particulates, ultrasound. It needs sensing on the asset and it tells you about mechanical degradation.

Asset health monitoring is broader. It combines condition data with process data, duty data and maintenance history to produce a view of whether an asset is performing as it should. Much of it can be derived from signals you already have.

Predictive maintenance is the decision layer on top: estimating when intervention is needed and scheduling accordingly. It depends on the two above being trustworthy, and it is usually promised first and delivered last.

This article is about the middle one, because it is where the unclaimed value sits in a legacy plant.

What your plant is already measuring

Before specifying a single sensor, inventory what exists. In eighteen years of plant work I have not once found this list to be empty, and I have frequently found it to be enough.

Variable frequency drive data. A VFD already computes motor current, torque, speed, output frequency, DC bus voltage, and its own fault history. Current draw at a known speed and load is a genuinely good health indicator for pumps, fans, conveyors and agitators: it rises as bearings degrade, as impellers wear, as belts slip, as material builds up. Most plants read a run-stop bit from the drive and ignore everything else on the bus.

Run hours and start counts. Duty is the denominator for every degradation calculation. An asset that has run 400 hours since overhaul and one that has run 8,000 are not comparable, and a motor with high start frequency is under a completely different stress than one that runs continuously. This is usually available and rarely kept per overhaul cycle.

Cycle and dwell times. For anything that repeats, the time to complete a cycle is a sensitive early indicator. A valve taking longer to stroke, a press taking longer to reach pressure, a filler taking longer per unit. The degradation shows up in timing well before it shows up in a failure.

Valve travel and stroke time. Control valve position against demand tells you about sticking, hysteresis and packing friction, and a smart positioner already computes much of it.

Differential pressure across filters and exchangers. Fouling is directly measured and the trend is normally available already.

Alarm and event history. Years of it, in most plants, and largely unused. The sequence and frequency of alarms around an asset is itself a health signal, and it is free.

The maintenance record. What was replaced, when, why and what was found. This is the ground truth for every model you will build, and it is text rather than numbers, which is why it needs different handling. I went through that in RAG on maintenance logs and work orders.

Where new sensing actually pays

New sensors are justified when the failure mode is mechanical, develops over a useful lead time, and does not show up in duty or process data early enough to act on.

That is mainly vibration on rotating equipment where a bearing or imbalance failure is both likely and costly, thermography on electrical connections and on assets where a hot spot precedes failure, ultrasound for leaks, steam traps and early bearing wear, and oil analysis on gearboxes and large drives where particulates lead failure by months.

Note what is not on that list: putting a sensor on everything. Which brings up the rule that matters more than any technology choice.

Criticality first, and be ruthless about it

The most common way these programmes fail is scope. Somebody decides to monitor every asset, the data volume becomes unmanageable, the alerts become noise, and nothing gets acted on.

Rank assets by consequence of failure multiplied by likelihood, and monitor the top of that list only. Consequence means lost production, safety exposure, environmental exposure, and repair cost including lead time on spares. A cheap pump with a six-month spare lead time can outrank an expensive one with a shelf spare.

Then exclude, deliberately, two categories. Assets that are run to failure by design should not be monitored, because knowing earlier changes nothing. And assets where you could not act on the warning anyway, because there is no access window until the next shutdown, are worth monitoring only if the lead time is long enough to reach that window.

A first phase of ten to twenty assets is usually right. It is enough to prove the case and small enough to finish.

The architecture, without touching the control system

This is the part that makes the project approvable, and it is straightforward.

Read only, and one direction. The monitoring layer subscribes to data. It does not write to a PLC, it does not change a setpoint, and it has no path to do so. This is not a policy, it is the topology, and it is why the change can be made without reopening the safety case. The reasoning is the same as in AI in safety-critical systems.

An edge gateway, not a PLC change. The gateway reads from the existing sources, whether that is the drive network, the SCADA server, the historian, or the PLC through a read-only connection, and publishes upward. No control logic is modified, which means no revalidation of the control system and a much shorter approval path in a regulated plant.

Publish into a structured namespace. Give every signal an identity that describes the asset physically rather than the system it came from, so site/area/line/pump1/current rather than a tag number. This is the practical payoff of the architecture in OPC UA, MQTT and the Unified Namespace: once the asset hierarchy exists, every subsequent use case inherits it instead of rebuilding it.

Decide where history lives, deliberately. Health work needs long retention at moderate resolution, which is a different profile from control trending, and getting it wrong is expensive to undo. That decision is the subject of historian vs time-series database vs data lake.

Join to the work order system. Without this you have trends and no outcomes. With it you can measure whether the programme is working.

Where these programmes go wrong

No baseline. Health is relative. If you did not capture what the asset looked like when it was known good, after its last overhaul, you are comparing against whatever condition it happened to be in when you switched the system on. Capture a baseline per asset per overhaul cycle and re-baseline after major work.

The asset hierarchy does not exist. Signals arrive with tag names and nobody can say which physical asset they belong to. Building that hierarchy is tedious and it is the foundation, because every rollup, every comparison between similar assets, and every maintenance join depends on it.

Duty is ignored. Comparing two identical pumps without normalising for hours run and duty cycle produces confident nonsense.

Alerts with no route to action. An email to a distribution list is not a route. The alert has to arrive as something a planner can schedule, with enough evidence to justify the work. This is the same failure I described in anomaly detection on PLC time-series data: the detection is rarely the weak part, the response path is.

Nobody owns it. After the integrator leaves, sensors fail, gateways drop off, and models drift. Within a year the dashboard is wrong and people have stopped looking. Assign the ownership before go-live, not after.

The business case, simply

The case is almost always made on converting unplanned downtime to planned, and it is worth doing the arithmetic rather than asserting a percentage.

Take a line producing 60 units an hour at 20 of margin per unit, so 1,200 an hour when stopped. It suffers six unplanned stoppages a year at eight hours each: 48 hours, or 57,600 a year.

Suppose monitoring gives enough warning to convert half of those into planned interventions taken at a changeover, costing two hours instead of eight. That is three events at eight hours plus three at two hours, so 30 hours instead of 48. Eighteen hours recovered, worth 21,600 a year on that one line.

That number is usually enough to fund the first phase, and it deliberately excludes the softer benefits: fewer secondary failures, less expedited freight on spares, and maintenance labour planned rather than emergency. Build the case on the hard number and let the rest be upside.

The honest caveat is that the saving depends entirely on the lead time being long enough to act, which is why the criticality screen excludes assets you could not act on anyway.

The bottom line

Asset health monitoring in a legacy plant is mostly an exercise in using what you already measure. Drives, run hours, cycle times, valve behaviour, differential pressures and alarm history contain a great deal of the answer, and they are already on the network. Add sensing where the failure mode is mechanical, develops slowly, and stays invisible to that data, and nowhere else.

Rank by criticality and start with fifteen assets rather than fifteen hundred. Keep the connection read only so nothing in the control system has to change. Build the asset hierarchy properly, because every later use case depends on it. Baseline each asset, normalise for duty, join alerts to work orders, and give the programme an owner. None of that requires ripping anything out, and it is the version that is still running two years later. Where the data goes once you are collecting it is the next decision, and I worked through it in monitoring industrial data without a historian.