Vibration Data for Predictive Maintenance: What to Collect

Picture a plant that installs wireless vibration sensors on 200 motors, sends an overall RMS value to the cloud every hour, and a year later has 1.7 million numbers and no prediction it trusts. The sensors work. The problem is the data: a single overall value can’t tell an unbalanced fan from a failing bearing, nobody recorded the motor’s speed or load when each value was taken, and the three bearings that did fail were replaced without anyone noting which motor or when. Collecting vibration data for predictive maintenance is a data-design problem before it’s a machine-learning problem. This article explains what to capture, how often, with what context, and how the standards and research describe the path from waveform to remaining-life estimate.

Key Takeaways

• Condition-based maintenance has three steps, as Jardine, Lin and Banjevic’s 2006 review put it: data acquisition, data processing and maintenance decision-making. The decision is only as good as the first step.
• ISO 13374-1 describes the processing chain in blocks, from acquisition and signal manipulation through state detection and health assessment to prognostics and advisory output. Each block needs different data.
• Store raw waveforms periodically, not continuously. A single axis at 25.6 kS/s and 16 bits is about 4.4 GB per day if kept continuously; a one-second capture every ten minutes is about 7.4 MB.
• Record operating condition (speed, load, process state) with every capture. Without it, a change in load looks like a change in health.
• Log maintenance actions and findings as labeled events. Lei and colleagues’ 2018 review of prognostics identified run-to-failure data as a central limitation of remaining-life methods.

The problem: data that can’t show a trend

Predictive maintenance promises to replace a part shortly before it fails instead of on a fixed schedule or after a breakdown. That requires seeing degradation develop over weeks or months and estimating when it will cross a limit. The data has to support three things: detecting that something has changed, diagnosing what it is, and projecting how fast it’s getting worse.

An overall vibration level supports the first, partly. It rises with many faults, but also with load, speed and nearby machinery, and by the time an overall level moves, an early bearing defect has often been visible in the spectrum or envelope for some time. Diagnosis needs the waveform, or at least features computed from it at the right frequencies. Projection needs a consistent history of those features under comparable conditions, plus examples of what happened at the end.

What the standards and research describe

Three steps of condition-based maintenance

Jardine, Lin and Banjevic’s widely cited 2006 review in Mechanical Systems and Signal Processing organized condition-based maintenance into data acquisition, data processing and maintenance decision-making. They distinguished value-type data (a single number per measurement, such as temperature or overall vibration), waveform data (such as vibration time series) and multidimensional data (such as images), and noted that waveform data needs signal processing before it can support diagnosis. Their review also stressed that event data, records of what was done to the machine and what was found, is as important as condition data, and is often the part that’s missing.

A processing chain in blocks

ISO 13374-1, Condition monitoring and diagnostics of machines – Data processing, communication and presentation – Part 1: General guidelines, sets out a reference architecture for condition-monitoring software. It divides processing into functional blocks: data acquisition, data manipulation (signal processing and feature extraction), state detection (comparison with baselines and alarm limits), health assessment (diagnosis), prognostic assessment (future health and remaining life) and advisory generation (recommended actions). The value of the model for a data project is that each block has inputs: state detection needs a baseline, health assessment needs fault signatures, prognostics needs history. ISO 17359, the general guideline for condition-monitoring programs, adds the step that comes before all of them: choosing which machines and failure modes to monitor and with which techniques.

Where alarm limits come from

For overall vibration severity, ISO 20816-1 provides evaluation zones that classify a machine’s vibration from newly commissioned through acceptable for long-term operation, restricted operation and damage likely, with machine-specific parts of the series giving values for particular machine types. These limits are a starting point for state detection on overall levels. For specific faults, such as rolling-element bearing defects, diagnosis relies on the frequency content: Randall and Antoni’s 2011 tutorial on bearing diagnostics describes envelope analysis, which demodulates the high-frequency resonances excited by each impact to reveal the bearing’s characteristic fault frequencies, and requires a sample rate high enough to capture those resonances.

From health indicator to remaining life

Lei, Li, Guo, Li, Yan and Lin’s 2018 systematic review of machinery prognostics divided the process into four technical steps: data acquisition, construction of a health indicator, division of the machine’s life into health stages, and remaining-useful-life prediction. A health indicator is a quantity that changes monotonically with degradation, computed from features such as RMS, kurtosis or band energy, or learned by a model. The review identified the scarcity of run-to-failure data under realistic conditions as a recurring limitation: many methods were developed and validated on a small number of laboratory datasets.

For a real deployment, that limitation is the practical lesson. Every failure that occurs in the field and is properly recorded, with the history leading up to it and the finding when the machine was opened, is the most valuable data the program will produce.

A data budget, worked through

Illustrative numbers for one motor with a single-axis accelerometer:

• Sample rate: 25.6 kS/s, enough for an analysis bandwidth around 10 kHz for envelope analysis.
• Resolution: 16 bits, 2 bytes per sample, so 51.2 kB/s.
• Continuous storage: 51.2 kB/s × 86,400 s ≈ 4.4 GB per day per axis.

That’s too much to send from hundreds of machines, and most of it is redundant. A typical alternative:

• Raw waveform: a 1-second capture every 10 minutes, 144 captures per day ≈ 7.4 MB per day. A longer capture once a day (for example 10 seconds) adds frequency resolution for slow machines.
• Features: overall RMS velocity and acceleration, peak, kurtosis and a few band energies computed on the device every minute, a few hundred bytes each.
• Context: shaft speed, load or current, and process state stored with every capture and feature.
• Events: alarms, inspections, repairs and findings, logged with the machine ID and time.

With 1-second captures, frequency resolution is 1 Hz, which separates most bearing and gear frequencies on machines running at normal speeds. Slow machines and closely spaced frequencies need longer captures.

What each kind of data supports

Data	Rate and size	Supports	Without it
Overall level (RMS velocity)	Every minute to hour; bytes	State detection against ISO 20816 zones	No simple severity check
Features (band energy, kurtosis, envelope peaks)	Every minute; hundreds of bytes	Trending, early detection, health indicators	Late detection, no diagnosis between captures
Raw waveform captures	Every few minutes to hours; kilobytes to megabytes	Diagnosis, new features later, model training	Can’t diagnose or recompute features
Operating condition (speed, load, state)	With every capture and feature	Comparing like with like; normalizing features	Load changes look like faults
Maintenance events and findings	Whenever they happen	Labels for diagnosis and prognostics; validation	No way to check or train predictions
Machine metadata (type, bearings, gear teeth, mounting)	Once, updated on change	Calculating fault frequencies	Spectral peaks can’t be attributed

What to actually do

Choose machines and failure modes first

Following ISO 17359’s approach, list the machines whose failure is costly and the failure modes you want to catch, and choose sensors, locations and data rates for those modes.

Keep raw captures, not just numbers

Store periodic waveforms with enough length and sample rate for the fault frequencies of interest. Features can always be recomputed from raw data; raw data can’t be recovered from features.

Record the operating condition every time

Capture speed and load (or a proxy such as motor current) with each sample, and compare features only within similar operating states.

Make maintenance logging part of the job

Every inspection, repair or replacement should record the machine, the date, the part and what was found. Give technicians a form that takes a minute, and use the entries as labels.

Start with simple, explainable indicators

Trend overall levels against ISO 20816 zones and a few fault-specific features against each machine’s own baseline before training complex models. They give a reference to judge models against.

What not to do

Don’t send only an hourly RMS value and expect diagnosis later. And don’t discard the data from machines that fail; that history is the most valuable part of the dataset.

How to put it to work

If you have an hour

Pick one critical machine and write down what’s recorded today: which values, how often, whether speed and load are stored, and where maintenance history lives.

If you have a sprint

Set up periodic raw captures and minute-by-minute features on a few machines, with operating condition attached, and a simple maintenance-event form. Review the first month’s trends with a maintenance technician.

If you want it to last the product’s lifetime

Keep machine metadata, sensor locations, firmware versions and feature definitions under version control, and audit maintenance logging quarterly. If you build monitoring products, make raw capture and context recording standard features, not options.

The question to ask yourself: “When the next bearing fails, will we have the history to see when it started and the record to know it was the bearing?”

Frequently asked questions

What vibration data is needed for predictive maintenance?

Periodic raw waveform captures with enough sample rate and length for the fault frequencies, features computed more often for trending, the machine’s operating condition with every sample, machine metadata such as bearing and gear details, and logged maintenance events.

How often should vibration be measured for predictive maintenance?

It depends on how fast the failure modes develop. Many systems compute features every few minutes and keep raw captures every few minutes to hours, with longer captures daily. Faster-developing faults need more frequent data.

Is overall RMS vibration enough?

It’s useful for severity checks against ISO 20816 zones, but it rises late for many faults and can’t distinguish between them. Diagnosis and early detection need spectral or envelope features computed from the waveform.

Why does operating condition matter?

Vibration changes with speed, load and process state. Without that context, a change in load can look like a change in health, which produces false alarms and hides real trends.

What is remaining useful life prediction?

It’s estimating how long a machine or component can run before it reaches a failure threshold, usually by tracking a health indicator over time and projecting it forward. Research reviews note it depends heavily on having run-to-failure data.

Related reading: vibration anomaly detection at the edge, accelerometer specs for vibration monitoring and edge vs cloud processing for industrial data.

Sources

1. Jardine, A. K. S., Lin, D., & Banjevic, D. (2006). “A Review on Machinery Diagnostics and Prognostics Implementing Condition-Based Maintenance.” Mechanical Systems and Signal Processing, 20(7), 1483–1510. https://doi.org/10.1016/j.ymssp.2005.09.012
2. Lei, Y., Li, N., Guo, L., Li, N., Yan, T., & Lin, J. (2018). “Machinery Health Prognostics: A Systematic Review from Data Acquisition to RUL Prediction.” Mechanical Systems and Signal Processing, 104, 799–834. https://doi.org/10.1016/j.ymssp.2017.11.016
3. International Organization for Standardization (2003). ISO 13374-1:2003, Condition monitoring and diagnostics of machines – Data processing, communication and presentation – Part 1: General guidelines. https://www.iso.org/standard/21832.html
4. International Organization for Standardization (2018). ISO 17359:2018, Condition monitoring and diagnostics of machines – General guidelines. https://www.iso.org/standard/71194.html
5. International Organization for Standardization (2016). ISO 20816-1:2016, Mechanical vibration – Measurement and evaluation of machine vibration – Part 1: General guidelines. https://www.iso.org/standard/63180.html
6. Randall, R. B., & Antoni, J. (2011). “Rolling Element Bearing Diagnostics—A Tutorial.” Mechanical Systems and Signal Processing, 25(2), 485–520. https://doi.org/10.1016/j.ymssp.2010.07.017