Writing / Refining
Start anomaly detection with the historian you already have
You do not need new sensors or a new platform to catch failing equipment early. You need two years of historian data, a clear definition of normal, and an alert someone will read.
Most plants that ask about anomaly detection expect the answer to start with a purchase: new vibration sensors, an IIoT gateway, a platform licence. Usually it does not. If you have run a process historian for a few years, you are probably sitting on enough data to catch a large share of equipment problems before they become trips.
This piece describes how we approach a first anomaly-detection project, and where it tends to go wrong.
Pick an asset that hurts
Start with one asset class where a failure is expensive and reasonably frequent: a feed pump that has tripped three times in two years, a compressor that keeps surprising the maintenance team, a heat exchanger whose cleaning schedule is guesswork. You want enough past events to check the model against, and enough cost per event that a few early warnings justify the work.
Avoid starting with the asset the vendor demo was built on. Start with the one your reliability engineer complains about.
Define normal per operating mode
A pump at 60 % throughput behaves differently from the same pump at 95 %. A fixed high-alarm limit cannot tell the difference between “running harder” and “starting to fail”. That is the whole reason alarm limits miss slow degradation.
The useful question is narrower: given the conditions right now, what would this asset normally read? In practice that means:
- Choosing the context tags: flow, load, suction conditions, ambient temperature, product grade.
- Choosing the health tags: discharge pressure, bearing temperatures, motor current, vibration if you have it.
- Learning the relationship between them from a period you trust, typically a year or more that excludes known failures and turnarounds.
The model then produces an expected band for each health tag. Readings outside the band, sustained for long enough to matter, are what you alert on.
Clean less than you think, label more than you want
Historian data is messy: compression artefacts, stuck values, instrument swaps, units that changed in 2019. You need to handle the worst of it, but the bigger lever is labels. Sit with operations for an afternoon and mark the known events: trips, repairs, cleanings, upsets. Without them you cannot tell whether the model would have helped.
The test of a model is not its accuracy score. It is whether it would have flagged last March’s trip early enough for someone to act.
Make the alert worth reading
Most anomaly projects that fail technically succeed in the lab and fail on the shift. The alerts are too frequent, too vague, or go to an inbox nobody watches. Three rules help:
- Show the evidence. Every alert names the two or three signals that moved and by how much, next to the expected band.
- Require persistence. A single point outside the band is noise. Several in a row, or a steady drift, is a signal.
- Route to an owner. One named person or role per asset, with a simple way to mark the alert useful or not. That feedback is how the model improves.
Run it in shadow mode first
Before anyone changes a maintenance decision, run the model alongside existing practice for a few weeks. Count the alerts, check each against what actually happened, and agree on the false-alarm rate the team can live with. That record is what turns a pilot into something operations trusts.
What you need to begin
- Read access to the historian (PI, IP.21, Ignition, or exports)
- Twelve to twenty-four months of data for one asset class
- A list of known failures and maintenance events in that period
- An engineer who knows the asset and can spare a few hours a week
That is enough to find out, in a few weeks, whether the approach works on your equipment. If it does, extending it to similar assets is mostly repetition.