Pull the downtime Pareto before anything else
The first question is not which assets to instrument. It is what actually stops the line. Pull twelve months of downtime by reason code and rank it by hours and by lost contribution margin. On a large share of plants, the top causes are changeovers, material starvation, operator-induced jams, quality holds and short stops — and equipment failure sits fourth or fifth. Predictive maintenance addresses none of the top four. Starting it anyway is a common and expensive way to spend a year improving something that was not the constraint.
When equipment failure is genuinely in the top two, the next question narrows the scope hard. Get the contribution margin per hour of downtime for each line from finance, not from engineering. Plants routinely discover that one constrained line is worth several thousand to several tens of thousands of dollars an hour and everything else is worth close to nothing, because the other lines have buffer or spare capacity. That single number turns a four-hundred-asset program into a six-asset program, and the six-asset version is the one that succeeds.
None of this is a reason not to do the work. It is the difference between a program that pays for itself in one avoided outage and a subscription nobody can justify at renewal.
You are probably here because
- A gearbox failed on a Sunday and took the line down for eleven hours
- Corporate asked for a predictive maintenance plan and nobody is sure where to start
- You installed wireless sensors last year and nobody looks at the portal
- A vendor quoted a program covering every asset in the plant and the number was large
The last two are the same failure. Coverage was chosen by asset count instead of by what an outage on each asset actually costs.
Your maintenance record is weaker evidence than it looks
The maintenance system holds every work order for a decade, which sounds like a training set. Open the failure code field and the picture changes. On most sites a large fraction of closed work orders carry a blank code, a catch-all, or a code chosen because it was first in the dropdown at the end of a shift. Failure mode, cause and the actual finding live in a free-text note if they live anywhere.
The downtime record has the same character. Reason codes are picked by an operator under pressure to get the line running, and there is almost always one code that absorbs everything ambiguous. If forty percent of your downtime is coded to a single generic reason, you do not have a downtime dataset yet; you have a downtime estimate.
This has a direct consequence. Supervised prediction of a specific failure mode needs labelled failures, and a critical pump that fails every four years across six identical units gives you perhaps eight to ten events inside the retention window — several of which will turn out on inspection to be something other than what the code says. That is not a dataset. It is a set of anecdotes, and honest project design starts by admitting it.
There is a way forward, and it starts with reading the free text. Extracting the actual finding from work-order notes, mapping it onto a failure-mode taxonomy, and giving the planners a way to correct it, is a genuinely useful project in its own right. It improves the maintenance program whether or not any model is ever built, and it is the only path to labels that mean something.
The historian may not hold what the trend appears to show
Process historians are built to store decades of data cheaply, which they do by not storing most of it. Values are recorded only when they deviate from the last recorded value by more than a configured amount, and the archive applies a further compression pass on top of that. The trend on screen is interpolated between kept points, and it looks continuous because the display draws a line.
For process supervision that is fine. For detecting a transient that precedes a failure, it can be fatal: the spike you need may never have been written. Before designing anything, check the compression settings on the tags you intend to use, and look at the actual stored point density rather than the chart. It is common to find a tag configured with a deviation band wide enough that a meaningful excursion is invisible.
Vibration is a separate matter again. A trend of overall vibration amplitude at one-minute intervals is a screening tool and nothing more. Diagnosing a bearing needs the waveform — spectra with enough resolution to see the defect frequencies, and envelope analysis to pull the bearing signature out from under the shaft dominant. That data usually does not exist in the historian at all, and adding it means route-based collection or permanently mounted sensors, which is a hardware decision with a real cost attached.
Where the classical methods already win
It is worth being blunt about this. For rolling-element bearings on rotating equipment, vibration analysis is a mature discipline with known defect frequencies, established severity bands and decades of practice. A competent analyst on a monthly route will find developing bearing faults months ahead, and no general-purpose model trained on your handful of historical failures will outperform that. Recommending a machine learning project where the answer is a vibration route and a trained analyst is not a service to the client.
| Asset and failure mode | What works today | Does modelling add anything? |
|---|---|---|
| Bearing wear on motors, pumps, fans | Vibration spectra and envelope analysis on a route | Little. Automate the screening, keep the analyst |
| Misalignment and imbalance | Vibration at running speed and harmonics | Little, and it is well understood physics |
| Electrical faults in motors | Current signature analysis, insulation testing | Some, for continuous screening across a fleet |
| Heat exchanger and cooling fouling | Manual efficiency calculations, done rarely | Yes. Continuous efficiency tracking against regime is a real gain |
| Compressor and chiller efficiency drift | Periodic performance tests | Yes, particularly with weather and load normalization |
| Fleets of similar assets | Per-asset thresholds nobody maintains | Yes. Cross-asset comparison is where models earn their place |
The pattern in that table: modelling adds the most where the signal is spread across many variables and there is no single precursor an instrument can watch, and where you have many similar assets so a fleet comparison is possible. It adds the least where physics already provides a precursor and an established method reads it.
Operating regime is most of the feature engineering
A pump running at forty percent flow and the same pump at ninety percent produce entirely different signatures in vibration, power and temperature. A chiller in July and the same chiller in February are different machines from a data point of view. A model that does not condition on regime will alarm every time production changes product, weather turns, or a line runs a short order — and every one of those alarms is correct in the sense that something changed, and useless in the sense that nothing is wrong.
The practical answer is to identify the discrete operating states from process tags, build features relative to the expected behaviour within a state, and either exclude transitions or model them separately. Startups and shutdowns are the noisiest periods and often the most informative, so excluding them permanently throws away signal, but including them naively floods the alert queue in the first week.
This is unglamorous work, it is where most of the engineering hours go, and it is the difference between a system a reliability engineer trusts and one that gets muted in month two.
Where the effort goes on a program that works — our weighting
Share of effort across programs we have scoped. Detection is the smallest line, which surprises nobody who has run one.
Ask what lead time each asset needs, per asset
An alert two hours before a failure is worth something only if two hours is enough to act. Required lead time is set by three things: how long it takes to get the part, when the next planned outage is, and how long the repair takes. For a stocked bearing on a line with a weekly maintenance window, twenty-four hours might be plenty. For a large motor with a twelve-week rewind and no spare, an alert needs months of warning or it is just a countdown.
Write the required lead time next to each asset before designing anything. It changes the answer completely. If an asset needs eight weeks of warning and the physics of the failure mode gives you days, then no detection system solves the problem and the honest recommendations are different: buy a spare, add redundancy, change the design, or accept the risk deliberately. That is a valuable conversation and it is one a good engineering partner should raise unprompted rather than sell a model into.
Set the alert budget from the size of the team
A reliability team of two people can properly investigate somewhere between five and fifteen alerts a week alongside their other work. That number is the specification. Set thresholds to produce that volume and report what detection rate you achieve at that operating point. A system that generates forty alerts a week will be ignored within a month regardless of how good it is, and the ignoring is rational: nobody can chase forty leads and do their job. Tuning to the team is not a compromise on quality. It is the only setting at which quality can be observed.
The output is a work order, not a dashboard
The person who acts on a prediction is the maintenance planner. The planner's day runs inside the maintenance system: a backlog, a schedule, parts and labour, an outage window. A separate portal with trends and scores is a place they will visit twice.
An alert that gets acted on has a specific shape. It names the asset by the tag the plant uses, not by a database identifier. It states the suspected failure mode in the language of the failure taxonomy. It carries the evidence — the trend that moved, the comparison against the fleet or against this asset's own history, the regime it was observed in. It proposes an inspection task specific enough to schedule, such as a thermographic scan or a vibration reading at a named point. And it lands in the planner's queue as a proposed work order, with the ability to reject it and say why.
Those rejections are the feedback loop. Within a couple of months the rejection reasons will show you which asset classes generate noise, which alerts fire in the wrong regime, and which thresholds are wrong. Without them there is no way to improve, and the program stalls at whatever the initial tuning happened to produce.
Send us your downtime data and a tag list, and we will tell you if this is worth doing.
Twelve months of downtime by reason code and asset, plus the tag list and compression settings for the assets you care about. You get back a written read: which assets carry enough downtime cost to justify a program, whether your historian holds the resolution needed, and what the honest first phase is. Email contact@precisionfederal.com.
contact@precisionfederal.comMeasuring a program that claims credit for absences
The hard part of proving value is that success looks like nothing happening. Avoided-downtime figures depend on counterfactuals, and any number built that way can be argued with, which means it will be, usually at budget time.
Design the measurement before the pilot, and lead with the one number a maintenance manager will believe: the confirmed finding rate. How many alerts were issued, how many were investigated, and how many of those investigations found the condition the alert predicted. A program running at one confirmed finding in three alerts is doing real work. One in twenty is generating inspections nobody should be paying for.
Then record captured lead time on each confirmed finding: how long between the alert and the planned intervention. That number is what tells you whether the program is delivering warning you can act on, or merely predicting things you were about to find anyway. And keep a simple count of unplanned events on covered assets against the two years prior. It is a crude measure with real confounds, and it is the one an operations director will ask for.
Expect calendar time. You need failures to not happen, and on assets that fail annually that means six to twelve months before any claim about avoided events is defensible. Anyone promising a proven return in a quarter is describing something other than reliability.
Build, buy, or hire an analyst
For bearings and general rotating-equipment condition monitoring, buy. Wireless vibration and temperature sensors have come down to a few hundred dollars a point installed, gateways are straightforward, and the vendor analytics for standard failure modes are adequate. Pair them with a trained analyst, in-house or on contract, and you will get most of the available value with none of the build risk.
Build where the value depends on things a vendor cannot see: your process context, your product mix, your failure taxonomy, your maintenance workflow. Fleet comparison across your own similar assets, efficiency drift normalized by your operating regimes, and the integration that turns an alert into a scheduled work order — those are specific to you, and they are where an internal or partner build earns its cost.
And sometimes the answer is neither. If preventive maintenance compliance is at sixty percent, fix that first. It is cheaper than any program described here, the failure modes it prevents are known, and a plant that cannot execute its existing maintenance plan will not execute a predictive one. We have said this to prospective clients and watched them buy sensors anyway, and the sensors did not help.
The mistakes we get called in to fix
- Every asset in the plant covered, chosen by count rather than by downtime cost per hour
- Models trained on failure codes without ever reading the work-order text behind them
- Tags pulled without checking compression, so the precursor transient was never stored
- No operating-regime conditioning, producing an alarm on every product changeover
- Thresholds tuned to a metric rather than to the number of alerts the team can investigate
- Alerts delivered to a portal instead of into the planner's queue as a proposed work order
- No required lead time recorded per asset, so warnings arrive far inside the parts lead time
- Value measured only in avoided downtime, with no confirmed-finding rate to stand behind it
A first phase with a real decision gate
How we sequence a first program
The gate at week four is the important one, and it should be written into the engagement. Roughly a third of the assessments we have run end with a recommendation to instrument differently, fix the maintenance record, or not proceed. A partner who cannot reach that conclusion is not assessing anything.
Before you start
- Downtime Pareto pulled, with equipment failure's actual rank against the other causes
- Contribution margin per downtime hour from finance, per line, not an average
- Required lead time written next to every candidate asset, driven by parts and outage windows
- Historian compression checked on the specific tags you intend to use
- Failure codes audited — what share are blank, generic, or contradicted by the notes
- Weekly alert budget agreed with the people who will investigate the alerts
- Write-back path into the maintenance system confirmed before any model is built
- Confirmed-finding rate adopted as the headline measure, with avoided downtime as secondary
Bottom line
Predictive maintenance works when it is narrow. Cover the few assets whose failure genuinely costs money, be honest that your failure labels are weak and recover what you can from the text, condition everything on operating regime, and set alert thresholds from the size of the team that has to chase them. Deliver into the maintenance system as a proposed work order, measure by confirmed findings, and keep a real gate early enough to stop. Where the failure mode is a bearing and the answer is a vibration route with a trained analyst, say so and save everyone a year.
Frequently asked questions
For supervised prediction of a specific mode, more than most plants have — a handful of events across a decade is not enough, especially once miscoded ones are removed. The workable approach on scarce failures is to model healthy behaviour within each operating regime and flag departures, which needs a lot of good-condition data rather than a lot of failures.
No. Select assets by the cost of an hour of their downtime and by whether you could act in time given parts lead time and outage windows. Most plants find that a handful of assets carry nearly all the value. Blanket coverage produces an alert volume nobody can work and a cost nobody can defend at renewal.
Most often because it does not condition on operating regime, so every product change, load swing or seasonal shift looks like an anomaly. The second common cause is thresholds set from a statistical criterion instead of from the number of investigations the team can actually perform in a week.
Sometimes, and check before assuming. Historians store data by exception and compression, so the stored series can be much sparser than the trend display suggests, and short precursor transients may never have been written. Look at actual stored point density on your specific tags, and expect vibration waveform data to be absent entirely.
Lead with the confirmed finding rate: alerts issued, alerts investigated, and investigations that found the predicted condition. Add captured lead time on each confirmed finding. Keep avoided-downtime figures as a secondary measure, because they rest on a counterfactual and will be challenged. Expect six to twelve months before any of it is defensible.