Predictive maintenance data requirements and how to start
· 5 min read · By YLinkTech
Predictive maintenance data requirements are smaller than most teams expect. You need four things: condition readings from the machine, the operating context around those readings, a clean maintenance history, and an asset register that ties them together. Start with one critical asset class and one failure mode, prove that an alert leads to a planned repair, then widen the scope.
The rest of this article explains each kind of data, how much history is enough, and a practical sequence for a first project.
What predictive maintenance is, and what it replaces
Maintenance work falls into three broad strategies. Reactive maintenance runs equipment until it fails. Preventive maintenance services equipment on a schedule or a cycle count. Predictive maintenance acts on evidence of the machine’s actual condition. The US National Institute of Standards and Technology (NIST) describes it as maintenance started from predictions of failure based on observed data such as temperature, noise and vibration.
Most plants use a mix. In NIST’s machinery maintenance survey of US discrete manufacturers, which reports annual values for 2016, establishments said their maintenance was on average 45.7% reactive, 31.8% preventive and 17.3% predictive. Among plants that relied mainly on preventive and predictive work, the half that used more predictive maintenance was associated with 15% less downtime and an 87% lower defect rate. Those are associations from a survey, not a promise for any single plant, but they explain the interest.
NIST also notes the cost side. Predictive maintenance usually needs a larger upfront investment than scheduled maintenance, because you must decide what to monitor, buy and integrate the hardware and software, and train people to respond. That is why the data question deserves attention before any model is built.
Predictive maintenance data requirements: four kinds of data
A model can only predict a failure if the data shows both the machine’s behavior and what happened to it afterward. The table lists the four categories and the gap that most often appears in each.
| Data | Examples | Usual source | Common gap |
|---|---|---|---|
| Condition data | Vibration, temperature, motor current, pressure, acoustic signals, oil analysis | Sensors, PLCs, historians, handheld routes | Sampling too slow for the failure mode, or readings never stored |
| Operating context | Speed, load, product or recipe, shift, ambient conditions, start and stop events | Control system, MES | Not joined to condition data, so a normal change in load looks like a fault |
| Maintenance history | Work orders, failure codes, parts replaced, date found and date fixed | CMMS or ERP maintenance module | Free-text notes, missing failure codes, close dates that do not match the real event |
| Asset register | Equipment hierarchy, make and model, criticality, sensor-to-asset mapping | CMMS, engineering records | Different asset IDs in each system |
Most plants already hold maintenance history and an asset register, in some condition. The first two categories are where new instrumentation or new plumbing is usually needed.
Match the measurement to the failure mode
Which sensor you need depends on how the asset fails. A worn bearing shows up in vibration long before it shows up in temperature. A fouled heat exchanger shows up in pressure and temperature differences. List the dominant failure modes for the asset first, then pick the measurement and the sampling rate that can reveal them. ISO 17359:2018, which ISO confirmed as current in 2023, gives general guidelines for setting up a condition monitoring program and points to the related standards for specific techniques.
How much history is enough
There is no fixed number of months. What matters is how many examples of the target failure the data contains, and failures of critical equipment are rare by design. That creates three realistic starting points:
- Few or no recorded failures. Use thresholds and anomaly detection. The system learns what normal looks like for each operating state and flags departures. No failure labels are needed, and it produces useful alerts early.
- Some recorded failures with good timestamps. Train a classifier that estimates the chance of failure within a set window, such as the next two weeks.
- Many run-to-failure examples. Estimate remaining useful life. This is the most demanding option and is rarely the right first project.
Many teams start with the first option on purpose. It delivers value while the labeled history that the other two need builds up.
How to start: six steps
- Rank assets by consequence. Score production impact, repair cost, safety exposure and failure frequency. Pick one asset class near the top that exists in several copies, so what you learn transfers.
- Choose one failure mode. State it precisely, along with how early a warning must arrive for planners to act on it.
- Audit the data you have. Check sampling rates, retention, timestamp alignment across systems, and whether work orders can be matched to the right asset and date.
- Close the gaps. Add sensors only where the failure mode requires them. Build a pipeline that lands condition, context and maintenance records in one place, keyed by a shared asset ID.
- Design the response before the model. Agree who receives an alert, what inspection follows, and how a confirmed finding becomes a work order. An alert that nobody owns changes nothing.
- Run a pilot and score it. Track alerts raised, alerts confirmed on inspection, failures missed, and warning time gained. Feed every inspection result back as a label.
If your organization is new to machine learning projects, an AI readiness assessment covers the wider questions of data ownership, skills and governance that sit around a pilot like this.
Pitfalls that stall first projects
- Collecting everything first. Streaming every tag from every machine creates storage cost without a question to answer. Start from the failure mode.
- Ignoring operating state. A model that does not know the line changed product will raise false alarms, and technicians stop trusting it quickly.
- Treating work orders as ground truth. Records are often closed days after the event or coded as “other”. Review a sample with the maintenance team before training on them.
- Leaving the model outside the workflow. Predictions belong in the maintenance system as inspection requests, not only on a separate dashboard.
- No plan for upkeep. Sensors drift, machines are rebuilt and products change. Models need monitoring and retraining, with a named owner.
Much of this depends on shop-floor and business systems sharing identifiers and events. The guide to MES and ERP integration patterns covers that layer.
How YLinkTech helps
YLinkTech works with manufacturing teams on the data and engineering work behind predictive maintenance. Our AI and Data practice audits the condition, context and maintenance data you already hold, builds the data pipelines and platforms that join them, and develops and monitors the models. We scope a first project around one asset class and one failure mode so you can judge the results before expanding. To talk through your equipment and data, contact our team.
Frequently asked questions
What data is needed for predictive maintenance?
You need four kinds: condition readings such as vibration, temperature or motor current; operating context such as load, speed and product; maintenance history with failure codes and dates; and an asset register that maps sensors and work orders to the same equipment ID. The measurements you choose should follow from the failure mode you want to catch.
Can you start predictive maintenance without failure history?
Yes. With few or no recorded failures, start with thresholds and anomaly detection, which learn the normal behavior of a machine in each operating state and flag departures from it. Record the result of every inspection that follows an alert. Over time those records become the labeled history that failure prediction models need.
What is the difference between preventive and predictive maintenance?
Preventive maintenance services equipment on a fixed schedule or cycle count, whether or not the machine needs it. Predictive maintenance acts on observed condition data, such as vibration or temperature, that indicates a developing fault. Most plants combine both, and keep scheduled work for assets where monitoring would cost more than it saves.
Sources
- NIST: Manufacturing machinery maintenance
- NIST: Economics of manufacturing machinery maintenance (AMS 100-34)
- ISO: ISO 17359:2018 Condition monitoring and diagnostics of machines, general guidelines
This article is general information, not professional advice. See our Disclaimer.