Vibration Anomaly Detection at the Edge: How It Works

A pump in a plant runs for two years without a failure, which is good for the plant and bad for anyone who wants to train a fault classifier: there are no examples of the fault. That’s why most vibration monitoring with machine learning is framed as anomaly detection rather than classification. The model learns what this machine’s normal vibration looks like, and anything sufficiently different raises a flag. Doing vibration anomaly detection at the edge, on a microcontroller next to the sensor, adds memory, power and bandwidth limits to that problem. This article explains how the approach works, what the public benchmarks show about its accuracy, and where it fails in practice.

Key Takeaways

• Anomaly detection trains on normal data only, which fits machines that rarely fail. It flags “different”, not “broken”.
• A common baseline is an autoencoder trained to reconstruct normal features; a high reconstruction error is the anomaly score.
• Public benchmarks show the problem is hard: the DCASE 2020 autoencoder baseline scored between about 66% and 85% AUC across six machine types.
• Thresholds decide false alarms. At one decision every 10 s, a per-window false-positive rate of 0.1% means about 8.6 false alarms per day per sensor unless decisions are combined.
• Changes in speed, load or mounting look like anomalies. The model has to see the machine’s normal operating range, or condition on it.

The problem: no failures to learn from

Supervised classifiers need labelled examples of each fault: inner-race defect, outer-race defect, imbalance, misalignment. Industrial machines rarely provide them, and laboratory fault datasets don’t transfer easily. Smith and Randall’s 2015 benchmark study in Mechanical Systems and Signal Processing applied three established diagnostic techniques to the entire Case Western Reserve University bearing dataset, one of the most widely used datasets for testing bearing diagnostics, and made recommendations on how the data should be used and how future benchmark data should be generated. A model that learns that dataset well has learned a particular test rig.

Anomaly detection sidesteps the shortage. Chandola, Banerjee and Kumar’s survey in ACM Computing Surveys defines the general problem as finding patterns that don’t conform to expected behavior, and organizes methods by whether they need labelled anomalies. The semi-supervised setting, with labels for normal data only, is the one that matches a running machine.

How edge anomaly detection works

Features first: compact descriptions of a window

Raw vibration at several kilohertz is too much data to feed a small model directly. Typical features summarize a window: RMS in frequency bands, FFT magnitudes binned on a log or mel scale, envelope spectra around a bearing resonance band, kurtosis or crest factor for impulsiveness. The DCASE 2020 machine-condition task, built on the ToyADMOS and MIMII sound datasets, used log-mel spectrograms with 128 bands and 64 ms frames, concatenating five frames into a 640-value input. Vibration systems use the same idea with features suited to the machine’s mechanics.

A model of normal: the autoencoder baseline

An autoencoder is a network that compresses its input through a narrow bottleneck and tries to reconstruct it. Trained only on normal windows, it learns to reconstruct normal well and anything unfamiliar poorly. The reconstruction error becomes the anomaly score.

The DCASE 2020 baseline is a useful, documented reference: fully connected layers of 128 units around an 8-unit bottleneck, trained on normal sounds only, scoring each clip by its mean squared reconstruction error. The MLPerf Tiny benchmark later adopted the same kind of fully connected autoencoder for its anomaly detection task, with a reference model of about 270 KB, because it runs on microcontrollers.

What the benchmarks show

The DCASE 2020 Task 2 description by Koizumi and colleagues reports that the challenge drew 117 submissions from 40 teams, and its baseline results show how hard the problem is. Averaged over ten runs on the development set, the autoencoder’s AUC ranged from about 66% (fan) to about 85% (slide rail), with partial AUC at low false-positive rates between about 51% and 68%. Many submissions did far better than the baseline, but the spread across machine types is the point: a method that works on one machine can be mediocre on another.

The MIMII dataset authors, Purohit and colleagues, recorded normal and anomalous sounds of valves, pumps, fans and slide rails in real factory environments, with anomalies such as contamination, leakage, rotating unbalance and rail damage. Real factory noise is part of the problem, not an inconvenience to filter out.

Thresholds and false alarms

An anomaly score needs a threshold, and the threshold sets the false-alarm rate. The arithmetic is unforgiving. An illustrative example: a sensor that makes a decision every 10 seconds makes 8,640 decisions a day. If the threshold is set at the 99.9th percentile of normal scores, each window has a 0.1% chance of a false positive, and the sensor raises about 8.6 false alarms a day. Across 50 sensors that’s more than 400.

Combining decisions helps enormously. Requiring three consecutive windows above threshold, and assuming the windows’ errors are independent (real windows are correlated, so the true benefit is smaller), cuts the per-window false-positive probability to one in a billion and the expected false alarms to about one every 300 years per sensor. That’s why the partial AUC at low false-positive rates, which DCASE reports alongside AUC, matters more for maintenance than the overall AUC.

Operating conditions look like faults

A pump at a different speed, a fan with a different load or a sensor remounted on a different bolt produces a different vibration signature. To an anomaly detector trained on one condition, that’s an anomaly. Later DCASE editions explicitly addressed this kind of domain shift. In practice, the training data must cover the machine’s normal operating range, or the model must be given the operating condition (speed, load) as an input, or a separate model must exist per condition.

What changes on the device

At the edge, the pipeline is the same but the budgets are tight. Features are computed in fixed point or with a small FFT on the microcontroller. The autoencoder is quantized to int8 and run with an embedded runtime. Only scores, or alarms with a snippet of the raw data, are transmitted, which saves bandwidth and power compared with streaming raw vibration. Thresholds are often learned on the device during a commissioning period of known-normal operation, which adapts the model to that machine’s mounting and environment.

Vibration anomaly detection approaches compared

Approach	Needs fault examples?	Strength	Weakness	Edge cost
Threshold on overall RMS or velocity	No	Simple, maps to severity standards	Misses early faults; sensitive to load	Very low
Band energies or envelope features + statistical limits	No	Interpretable; good for known bearing frequencies	Needs mechanical knowledge per machine	Low
Autoencoder on spectral features	No (normal only)	Learns complex normal patterns	Threshold and domain shift; needs normal data covering conditions	Moderate (int8 model)
Supervised fault classifier	Yes	Names the fault	Fault data rare; transfers poorly between machines	Moderate
Hybrid: anomaly detection on device, diagnosis by expert or cloud	Partly	Fewer false alarms reach people; raw snippets for diagnosis	More system complexity	Moderate

What to actually do

Collect normal data across the operating range

Record the machine at every normal speed, load and season you can before training. Gaps in normal data become false alarms.

Start with interpretable features

Band RMS, envelope energy around the bearing resonance and kurtosis are cheap on a microcontroller and easy for a maintenance engineer to check. Add a learned model when they’re not enough.

Set thresholds from the false-alarm budget

Decide how many false alarms per month the maintenance team will tolerate, convert that to a per-window rate at your decision interval, and set the threshold and persistence rule (k of n windows) to meet it.

Give the model the operating condition

If speed or load varies, measure it and either include it as a model input or train separate models per condition.

Validate with whatever anomalies you can get

Seeded faults on a test rig, historical failures, or deliberate changes (an added imbalance mass) are better than no validation. Report AUC and the false-positive rate at your chosen threshold.

What not to do

Don’t report a high AUC from one machine as evidence that the method works on another. And don’t set the threshold from the test set; set it from normal data and the false-alarm budget.

How to put it to work

If you have an hour

Take a week of normal scores from one sensor, compute the threshold at your chosen percentile and count how many windows would have alarmed. Multiply by your sensor count.

If you have a sprint

Record normal operation across the machine’s speed and load range, train a small autoencoder on band features, quantize it and run it on the device for a week. Log every alarm and review each one with a maintenance engineer.

If you want it to last the product’s lifetime

Re-learn the normal baseline after maintenance, remounting or process changes, and keep a record of every confirmed anomaly with its raw data. Over time those records become the labelled fault data the system didn’t have at the start.

The question to ask yourself: “How many false alarms per month will this system raise across all my sensors, and will the maintenance team still trust it after the first month?”

Frequently asked questions

What is vibration anomaly detection?

It’s monitoring a machine’s vibration with a model of its normal behavior and flagging windows that differ significantly from normal. Unlike fault classification, it doesn’t need examples of failures, so it suits machines that rarely fail.

How does an autoencoder detect anomalies?

An autoencoder is trained to compress and reconstruct normal data. It reconstructs normal inputs well and unfamiliar inputs poorly, so the reconstruction error serves as an anomaly score. A threshold on that score decides whether to raise an alarm.

Why does my anomaly detector give so many false alarms?

Usually because the threshold is set too low for the number of decisions per day, because single windows trigger alarms without a persistence rule, or because normal operating changes (speed, load, remounting) weren’t in the training data.

Can anomaly detection run on a microcontroller?

Yes. Compact features and a small int8 autoencoder fit on many microcontrollers; the MLPerf Tiny benchmark includes an anomaly detection task with a fully connected autoencoder reference model. Running at the edge means only scores or alarms need to be transmitted.

How do you evaluate an anomaly detector without failure data?

Use whatever anomalies are available (seeded faults, historical failures, deliberate changes such as an added imbalance), report AUC and the false-positive rate at the operating threshold, and run the system on normal operation long enough to measure the real false-alarm rate.

Related reading: accelerometer specs for vibration monitoring, vibration data for predictive maintenance and from sensor input to embedded inference.

Sources

1. Koizumi, Y., Kawaguchi, Y., Imoto, K., et al. (2020). “Description and Discussion on DCASE2020 Challenge Task 2: Unsupervised Anomalous Sound Detection for Machine Condition Monitoring.” Proceedings of the DCASE 2020 Workshop. arXiv:2006.05822. https://arxiv.org/abs/2006.05822
2. DCASE Community (2020). “Unsupervised Detection of Anomalous Sounds for Machine Condition Monitoring” (Task 2 description and baseline). https://dcase.community/challenge2020/task-unsupervised-detection-of-anomalous-sounds
3. Purohit, H., Tanabe, R., Ichige, K., Endo, T., Nikaido, Y., Suefusa, K., & Kawaguchi, Y. (2019). “MIMII Dataset: Sound Dataset for Malfunctioning Industrial Machine Investigation and Inspection.” arXiv:1909.09347. https://arxiv.org/abs/1909.09347
4. Chandola, V., Banerjee, A., & Kumar, V. (2009). “Anomaly Detection: A Survey.” ACM Computing Surveys, 41(3), 1–58. https://doi.org/10.1145/1541880.1541882
5. Smith, W. A., & Randall, R. B. (2015). “Rolling Element Bearing Diagnostics Using the Case Western Reserve University Data: A Benchmark Study.” Mechanical Systems and Signal Processing, 64–65, 100–131. https://doi.org/10.1016/j.ymssp.2015.04.021
6. Banbury, C., Reddi, V. J., Torelli, P., Holleman, J., et al. (2021). “MLPerf Tiny Benchmark.” Proceedings of the Neural Information Processing Systems Track on Datasets and Benchmarks. arXiv:2106.07597. https://arxiv.org/abs/2106.07597