IMS bearing anomaly detection
I built an anomaly-detection pipeline from bearing vibration data to model training and alarm evaluation. On the public IMS dataset, the fixed protocol that holds out entire test runs did not establish an advantage for deep autoencoders.
The project
A reproducible anomaly-detection pipeline connects waveform acquisition, feature extraction, training, alarm evaluation and reporting. It compares a deep autoencoder, a denoising autoencoder, PCA and an RMS amplitude baseline under a shared protocol.
The archive and its documentation describe different recording ranges. The main evaluation is fixed to the documented range, with input and feature hashes retained to detect changed data or incomplete extraction.
How it works
Separate whole test runs
Vibration records are grouped by test run; the run used for evaluation stays out of training and alarm calibration.
Learn to reconstruct the input
Only the training-side runs are used to learn a model that reconstructs vibration features and to set the reconstruction-error level that triggers an alarm.
Compare on an unseen run
The fixed model and alarm threshold are applied to the unseen run, and its scores and alarms are compared with simpler methods.
Runs are separated before any learning. The held-out run is excluded from scaling, training, model selection and threshold calibration. Source runs are split by recording order, with unused gaps between stages. Alarms derived from spectral reconstruction error use only past and present information.
A split audit stops training if it finds held-out data, duplicate raw files or reversed timestamps. Tests deliberately introduce leakage and check that changing unseen data or future scores cannot alter trained results or past alarms.
What the records show
The fixed protocol did not establish an advantage for the deep models. Persistent alarms near the start of a run and a score that separates early from late recordings measure different properties. Transferring a threshold learned on other runs remained the central difficulty.
The recorded CPU results include trained weights, scores, environment details and source hashes. The comparison can be rerun, including cases where simpler baselines perform better.
- Vibration records
- 7,588 records
- Bearing observations
- 30,352 observations
- Trained models
- 18 models
- CPU run, excluding download
- 48.78 s
- Tests passed
- 59 tests
What this covers
The findings apply to this dataset and evaluation protocol. Without ground-truth failure-onset times, early-versus-late metrics do not measure fault-detection accuracy or remaining useful life.