By the 5Tech engineering team · Published August 2023 · Written for maintenance and reliability engineers and plant managers. This is an educational engineering guide; market and consultancy figures are cited as industry ranges, the acceptance targets are labelled illustrative, and nothing here is a 5Tech customer result.
Most predictive-maintenance programs that disappoint don't fail on the algorithm. They fail on a sensor mounted in the wrong place, a model trained on three labelled failures, or an alert stream so noisy that the maintenance crew muted it by the second week. A predictive-maintenance system that actually works is a signal-processing and data-labelling problem wrapped in a maintenance-workflow problem — and it earns trust as advice to a planner, never as a trip wired into the control loop. Get those right and the model is almost an afterthought. Get them wrong and no model can save you.
Who this is for, and the one claim
This is for the reliability engineer who owns the vibration route and the plant manager who signs off the maintenance budget. If you are being sold "AI predictive maintenance," the useful question is not how accurate is the model — it is which failure modes does it catch, how early, how often does it cry wolf, and what does a planner do when it fires?
The central claim of this guide is narrow on purpose: a predictive-maintenance system is only as good as its worst-engineered link — sensor, signal chain, or labels — and for a large share of assets a condition-based threshold, a spectral rule, or a control chart beats a machine-learning model outright. Machine learning is one tool in the box, and often not the first one you should reach for.
Set the vocabulary straight first
These terms get used interchangeably in sales decks; on the plant floor they are different strategies with different costs, and the international standards keep them distinct.
- Reactive (run-to-failure) — repair after it breaks. Cheapest to set up, most expensive when it fails at the worst moment.
- Preventive (time- or usage-based) — service on a schedule regardless of condition. The DOE FEMP guide reports it saves roughly 12–18% over reactive, but it replaces healthy parts and does nothing for random failures (US DOE FEMP).
- Condition-based / predictive — act on the measured state of the machine. Condition-based maintenance (CBM) triggers on a measured parameter crossing a limit; predictive adds a forecast of remaining useful life (RUL). Predictive is a superset of CBM, not a synonym.
Two standards define this space and are worth reading before you buy anything. ISO 17359 (Condition monitoring and diagnostics of machines — General guidelines) is the parent document: it sets out how to choose measured parameters — vibration, temperature, tribology, flow, contamination, power, speed — direct monitoring at real failure modes, and set alarm criteria. ISO 13374 (Data processing, communication and presentation) defines the processing pipeline every serious system follows. If a vendor cannot map their product onto these, that is a signal in itself.
The pipeline is standardised — the model is one block of six
ISO 13374 breaks condition monitoring into six functional blocks, and this is the single most clarifying model in the field. Each block constrains the next, and — tellingly — the last block the standard defines is not "control action." It is advisory generation. The standard itself frames the output as advice.
Signal & feature blocks (get these right or nothing above matters)
DA — Data Acquisition: transducer to calibrated digital samples, with quality flags.
DM — Data Manipulation: filtering, FFT/envelope analysis, feature extraction.
Most program failures are here, not in the model.
Assessment & advisory blocks
SD — State Detection: normal vs abnormal against a baseline.
HA — Health Assessment: diagnose the fault.
PA — Prognostic Assessment: estimate remaining useful life.
AG — Advisory Generation: recommend an action to maintenance.
Reference data flow. The ISO 13374 chain (DA→DM→SD→HA→PA→AG) turns raw vibration into an advisory that becomes a CMMS work order for a planner. A heavy advisory boundary keeps the model out of the PLC and safety loop, which stays authoritative; a sensor fault raises a data-quality flag rather than hiding a real fault. (Illustrative reference architecture, not a specific installation.)
The unglamorous half: sensors, signals, and speed
The blocks that decide whether a program works — DA and DM — are pure engineering, and they are where money is quietly lost.
- Sensor selection and mounting. An accelerometer stud-mounted on a bearing housing has usable bandwidth into the kilohertz range; the same sensor on a magnetic base or, worse, a handheld probe can roll off long before the bearing-defect frequencies you care about. Mounting is not a detail — it sets your ceiling.
- Anti-alias filtering. Sample below twice the highest frequency of interest without an analog anti-alias filter, and high-frequency energy folds down and masquerades as a low-frequency fault. Aliasing produces confident, wrong diagnoses; no model downstream can undo it.
- Windowing and resolution. FFT-based analysis needs a window (Hann is the common default) and enough lines of resolution to separate, say, a bearing tone from a nearby running-speed harmonic. Too short a window and the peaks smear together; too long and you miss transients.
- Variable speed and load. This is the one that breaks naive systems. On a machine that changes speed, fault frequencies move, so a fixed spectral band is meaningless. The fix is order tracking — resampling against a tachometer or encoder so analysis is referenced to shaft rotation, not clock time — and segmenting data by operating condition so you compare like with like.
None of this involves AI. All of it determines whether AI could ever help.
The hardest problem in the whole program: labels
Ask any team that has shipped a real predictive model what nearly killed it, and the answer is rarely the algorithm. It is the data — specifically, honestly-labelled failure examples, which are scarce, imbalanced, and often wrong.
The reasons are structural, not fixable by effort alone:
- Failures are rare by design. A well-run plant produces very few real failures per asset per year. A supervised classifier may have thousands of "healthy" hours and a literal handful of "failure" events — a class imbalance of hundreds or thousands to one.
- The labels you have are noisy. The CMMS work-order history — your only ground truth — was written for billing and parts, not for machine learning. "Replaced bearing" may mean it failed, or that a technician swapped it on suspicion while the machine was open. Failure onset time, the label you actually need for RUL, is almost never recorded.
- Run-to-failure data is expensive and unethical to collect. You cannot deliberately destroy production assets to gather training data, so seeded-fault test rigs and physics-based models fill the gap — and neither perfectly matches your line.
Practical responses exist — anomaly detection and one-class models that learn only "normal," transfer from seeded-fault datasets, semi-supervised labelling, careful handling of imbalance — but each is a hedge, not a cure. Treat any accuracy number computed on a handful of failures with deep suspicion: with five positive examples, one lucky or unlucky case swings your reported recall by 20 points. This is the honest reason so many pilots look brilliant and so few scale.
Condition monitoring where it starts: a reliability engineer takes a vibration reading at the bearing housing, with wireless sensor tags on the motor casing. The quality of this measurement — sensor, mounting point, technique — caps everything the analytics can do downstream.
Define "works" before you build: acceptance criteria
A predictive system without written acceptance criteria cannot pass or fail — it can only generate opinions. Set four numbers per asset class, up front, with the maintenance team in the room. The targets below are illustrative starting points to negotiate against your own failure history — not benchmarks 5Tech has measured.
| Acceptance criterion | Illustrative target (set per asset) | Why it decides adoption |
|---|
| Detection recall (real faults caught) | ≥ 0.90 on held-out labelled faults | A miss ships a failure you promised to prevent. |
| False-alarm budget | ≤ 1 false alert per asset per quarter | Alarm fatigue is how crews learn to ignore the system. |
| Warning lead time | ≥ parts + scheduling lead time (e.g. 2–4 weeks) | A true alert that arrives too late to act on has no value. |
| Abstain / low-confidence behaviour | Flag "insufficient data" rather than guess | A silent wrong answer is worse than an honest "don't know." |
Notice what dominates: the false-alarm budget. Precision and recall trade off, and in maintenance the asymmetry is brutal. A missed defect is expensive once; a stream of false alarms is expensive every week and, worse, trains the crew to disbelieve the system — at which point even its true alerts do nothing. Warning lead time is the other half of the contract: the alert has to beat the combined lead time of ordering the part and finding a slot to install it, or it is just anxiety.
A model that cries wolf is not a good model with a tuning problem. It is a negative-value system that will be switched off — and it will take the true alarms down with it.
Often the right answer is not machine learning
This is the part sales decks skip. For a large fraction of industrial failure modes, a threshold, a spectral rule, or a control chart is cheaper, more explainable, and far easier to validate and certify than a neural network — and it is what ISO 17359 and generations of vibration analysts already do. Reach for a model when the pattern is genuinely too complex, multivariate, or variable for these methods, not by default.
| Failure mode / question | Simpler method that often suffices | When ML earns its place |
|---|
| Rolling-element bearing defect | Envelope (demodulation) spectrum + ISO alarm bands | Large mixed fleets, many speeds, faint early stages |
| Imbalance / misalignment | 1× and 2× running-speed vibration thresholds | Rarely — classical analysis is decisive here |
| Overheating / lubrication | Temperature limit + rate-of-change alarm | Rarely — a threshold is explainable and enough |
| Process / quality drift | SPC control charts (e.g. Western Electric rules) | High-dimensional, coupled multivariate signals |
| Novel, non-separable signatures across many sensors | — | This is the genuine case for ML |
Advisory, not control — and why that line is non-negotiable
Predictive maintenance is decision support for the maintenance function. Its output is an advisory that a planner reviews and schedules — the AG block of ISO 13374, by name. It must not be wired as an automatic trip into the process-control or safety loop.
The reasoning is the same discipline that governs any AI touching physical plant. Speed and accuracy are not the same as safety. A prognostic model is statistical, occasionally wrong, and not designed for deterministic, bounded-time response — the properties a safety function must have. Protective trips (over-temperature, over-speed, over-pressure) belong to the PLC and the safety-instrumented system, which are validated, deterministic, and fail-safe; the predictive layer sits above that boundary and advises it. If the monitoring layer degrades or goes offline, nothing on the process should change: the machine keeps running under its existing controls, and the correct failure mode is a data-quality flag — "I can no longer see this asset" — never a silent gap that looks like health. Let a model's guess pull a breaker and you have coupled production availability to model uncertainty, which is exactly backwards.
Deployment is the start, not the finish
The model going live is the beginning of the expensive part. A predictive program is a standing commitment, and the lifecycle is where budgets are really spent.
- Drift. Baselines move as machines are rebuilt, loads change, and seasons shift ambient temperature. A "normal" learned in winter can alarm all summer. Plan to monitor the monitor and re-baseline on change.
- Versioning and governance. Every model in production needs a recorded version, the data it was trained on, and its acceptance results — so that when it misbehaves you can answer "what changed?" and roll back to a known-good version.
- Validation as a staged gate, not a one-off. Run new models in shadow mode first — producing advisories that are logged but not acted on — until they clear the acceptance criteria against recent labelled events, then promote with sign-off.
- Sensor lifecycle. Accelerometers drift and cables fatigue. Calibration schedules and health checks on the sensors themselves are part of the program; an un-calibrated sensor is a confident liar.
- CMMS integration and end-of-life. An advisory that does not become a scheduled work order in the CMMS (computerized maintenance management system) changes nothing. Close the loop: alert → work order → feedback on whether the fault was real → back into the labels. And decommission models when the asset is modified enough that their training no longer applies.
Make it a number, then price being wrong
Whether a given asset justifies a predictive program is an arithmetic question, not a matter of enthusiasm.
Annual value = avoided-failure downtime + extended asset life + reduced secondary damage + labour & overtime saved − ( sensors + wiring/gateway + integration + data labelling + model build & retraining + validation + false-alarm handling )
Two terms decide most cases. First, criticality: the value scales with what a failure of this asset actually costs — a spared, non-critical pump rarely justifies instrumentation, while a single unspared bottleneck can pay for a whole program. Second, the cost of false alarms, which belongs in the denominator and is routinely forgotten: every wolf-cry burns a technician's time and a little more of the crew's trust. A technically excellent model can carry negative net value if its false alerts interrupt production or erode confidence faster than its true alerts save money. The DOE and Deloitte ranges in the callout are the prize; this formula is how you find out whether a specific asset is anywhere near it.
What to remember
- The program lives or dies in the signal chain and the labels, not the algorithm — sensor, mounting, anti-alias, windowing, order tracking come first.
- Failure data is scarce, imbalanced, and noisily labelled; distrust any accuracy figure built on a handful of real failures.
- Write acceptance criteria up front: recall, a hard false-alarm budget, warning lead time beyond parts-plus-scheduling, and honest abstention.
- For many failure modes a threshold, envelope spectrum, or SPC chart beats ML — cheaper, explainable, easier to validate.
- Keep it advisory: it feeds the CMMS and a planner, never an automatic trip in the control or safety loop.
Where to start
Skip the platform search and the fleet-wide rollout. Pick one asset class you already lose sleep over — an unspared pump, a critical gearbox, a press that fails without warning — pull its CMMS failure history, and honestly count how many cleanly-labelled failures you actually have. Then choose the simplest method that could work: nine times out of ten that is a threshold or an envelope-spectrum rule with alarm bands from ISO 17359, and only the tenth genuinely needs a model. Write down the four acceptance numbers, run it in shadow mode against the last year of events, and see whether it would have caught what hurt you — with enough lead time to act. One honestly-measured asset teaches you more than any fleet dashboard.
If you want a second pair of engineering eyes on that first asset — sensor selection, the signal chain, and an honest "does this even need ML?" read before you spend — talk to the 5Tech engineering team. We would rather help you validate a threshold than sell you a model you don't need.
References & further reading
- ISO 17359:2018 — Condition monitoring and diagnostics of machines: General guidelines: parent standard; choosing measured parameters, directing monitoring at real failure modes, and setting alarm criteria.
- ISO 13374-1:2003 — Condition monitoring and diagnostics of machines: Data processing, communication and presentation: the six-block processing model (DA, DM, SD, HA, PA, Advisory Generation) that structures a condition-monitoring system.
- U.S. Department of Energy, FEMP — Operations & Maintenance Best Practices Guide (Release 3.0): predictive-maintenance savings of 8–12% over preventive alone, ~30–40% potential for reactive-heavy sites, and maintenance-strategy benchmarks.
- McKinsey & Company — IoT value set to accelerate through 2030: factory settings as the single largest IoT value pool (~26%, US$1.4–3.3 trillion by 2030).
- Deloitte — Predictive Maintenance and the Smart Factory: ~US$50 billion annual unplanned-downtime cost and the 5–20% productive-capacity impact of poor maintenance.
- Deloitte Insights — Industry 4.0 and predictive technologies for asset maintenance: program-average ranges for uptime, cost, and planning-time improvement (read as consultancy averages, not guarantees).
The reference data-flow diagram is an illustrative architecture, not a specific installation.
Send 5Tech one workflow, inspection task, sensor problem, robotics challenge, or prototype idea. We will review it and suggest a practical next step. Start My Free First Phase — a free first review of one idea. If it is not practical, we will tell you.