Vibration tells you what the machine is doing. Physics tells you why.
We combine vibration analysis and machine learning for condition monitoring, predictive maintenance and product sensing. The work starts with the sensor, the mounting and the mechanics, so that every feature a model sees can be traced back to something physical.
A specialist practice of MLAIA Data ScienceLed by Dr. Yochai Edlitz · Ph.D., Weizmann Institute
Sensing & acquisition
Most vibration models fail at the sensor. Not in the network.
A spectrum can only show what the measurement chain lets through. Before choosing a model, we check what the sensor, mount and sampling plan can support.
Vibration is one part of our Audio & Acoustics practice, and the same measurement discipline applies as for microphones.
01
Sensor choice
IEPE piezoelectric accelerometers offer wide bandwidth and a low noise floor. MEMS accelerometers are cheap, small and DC-coupled, but noise density and bandwidth often limit early fault detection. Acoustic-emission sensors work at far higher frequencies and respond to crack growth and friction rather than bulk motion.
02
Mounting & resonance
Stud mounting preserves the most bandwidth; adhesive, magnetic and handheld mounts progressively lower the mounted resonance and distort the high-frequency band. Brackets and enclosures add their own modes. If the band you need for envelope analysis sits near a mounting resonance, the measurement, not the model, sets the ceiling.
03
Sampling & anti-aliasing
Sample rate follows the highest band of interest, not the shaft speed. Impact-excited resonances used for bearing diagnosis often sit in the kilohertz range. We check anti-aliasing, ADC resolution against the noise floor, record length for frequency resolution, and whether streaming or triggered snapshots fit the power budget.
04
Speed reference
A tachometer or encoder pulse turns a hard problem into a tractable one. Without it, speed must be estimated from the vibration itself, which works on some machines and not others. We decide early whether a speed signal is available or must be estimated.
Classical diagnostics
Know the fault frequencies. Then look for them properly.
Many mechanical faults have a signature that physics predicts. A classical baseline finds those signatures directly and gives a learned model something concrete to beat.
Characteristic frequencies such as BPFO, BPFI, ball spin and cage frequency follow from bearing geometry and shaft speed. Real bearings slip slightly, so these lines are smeared rather than exact. We compute expected frequencies with tolerance bands and check harmonics and sidebands, such as inner-race lines modulated at shaft speed.
Envelope analysis
Early defects produce small periodic impacts that excite high-frequency resonances. Band-pass filtering around a resonance, demodulating, and taking the envelope spectrum exposes the defect repetition rate. Band choice is critical; spectral kurtosis and the kurtogram select it from data rather than by guesswork.
Order tracking for variable speed
When speed changes during a record, frequency lines smear across the spectrum. Resampling to constant shaft angle, using a tachometer or estimated speed profile, converts frequency to order. Shaft harmonics and gear-mesh components then stay in fixed bins, which also stabilizes learned features.
Resonance & modal behaviour
Run-ups, coast-downs and impact tests reveal natural frequencies and how they shift with temperature, load or assembly. A rising level is not always wear: a forcing frequency moving onto a structural mode produces a similar symptom. Separating the two avoids replacing healthy parts.
Simulated outer-race defect on a bearing with nine rolling elements and a 25 Hz shaft (BPFO = 90 Hz), with impact timing jittered by 1% to mimic slip. The raw spectrum shows shaft lines and a resonance but no clear defect line; band-pass filtering around the resonance and taking the envelope exposes the defect rate and its harmonics.Simulated run-up from 10 to 40 Hz with components at 1× and 3× shaft speed. An ordinary spectrum smears each component across the speed range; resampling to constant shaft angle with a tachometer signal turns them back into sharp, fixed order lines.
Machine learning
Labeled faults are rare. Design for that from the start.
Machines are healthy most of the time, and the failures you care about may never have been recorded. Vibration analysis machine learning has to work with that imbalance.
Anomaly detection on healthy data
Models trained only on normal operation, from autoencoders to density estimates on engineered features, flag departures from a learned baseline. The hard part is normalizing for operating condition so that load, speed and temperature changes do not look like faults.
Supervised fault classification
Where seeded-fault or historical failure data exist, classifiers can name the fault type. Public lab bearing datasets help development but rarely transfer directly to a different machine, mount or speed range. We validate on machines and conditions the model has not seen, not on random splits.
Degradation & remaining useful life
Remaining useful life is best framed as a time-to-event problem with censored data, since most units are still running when data collection ends. We treat health indicators as covariates and avoid single-number predictions without uncertainty.
Vibration is also an input for products: detecting contact, usage or mechanical states through an accelerometer. The constraints resemble edge audio AI: small models, tight memory, and behaviour validated on the target device.
Evaluation
Measure the alarm, not the accuracy. False alarms have a price.
Maintenance teams stop trusting a system after a few unnecessary call-outs. We evaluate alerts the way they will be used, with the cost of each error made explicit.
We agree the relative cost of a false alarm and a missed fault with you before tuning thresholds. That choice shapes the alert logic, persistence rules such as requiring several consecutive anomalous windows, and which cases go to human review.
How the alert rule, not only the threshold, sets the false-alarm budget, under idealised assumptions: one scored window per minute and independent Gaussian healthy scores. Real anomaly scores are correlated in time, so persistence helps less than shown here. The point is the shape of the tradeoff, which we measure on your own healthy data.
What we measureFalse alarms per machine per month at the chosen thresholdDetection lead time before a confirmed faultMissed detections, reviewed case by caseStability across speed, load and temperaturePerformance on machines held out from trainingRobustness to sensor drift and loose mounts
How an engagement runs
From raw signals to a threshold you trust.
Four stages, each ending with something you can inspect.
01
Review the measurement chain
Inspect sensors, mounts, sampling, speed references and existing recordings. Establish what the data can reveal before modeling.
02
Build the physics baseline
Compute expected fault frequencies, envelope spectra and order-tracked features. See what a classical approach detects and where it falls short.
03
Add learning where it pays
Train anomaly or classification models on the baseline features, split by machine and operating condition so results reflect deployment.
04
Set thresholds & hand over
Tune alert logic against the agreed false-alarm cost, document limits and failure modes, and plan drift monitoring.
We have almost no recorded failures. Can machine learning still help?
Often, yes. Anomaly detection trained on healthy operation can flag departures from normal behaviour without fault labels, provided load and speed changes are controlled for so they do not trigger alarms. A physics baseline built on expected fault frequencies also needs no labels and helps explain what an anomaly model reacts to.
Are MEMS accelerometers good enough for bearing fault detection?
It depends on the machine and how early you need to detect. MEMS sensors are attractive on cost, size and power, but their noise floor and bandwidth can hide the small high-frequency impacts that envelope analysis relies on for early detection. We compare the sensor's specifications with the expected signal levels and, where possible, test it next to a reference accelerometer.
Our machines run at variable speed. Does that rule out spectral methods?
No, but it changes the approach. Order tracking resamples the signal to constant shaft angle so that speed-related components stay in fixed bins. With a tachometer this is straightforward; without one, speed can sometimes be estimated from the vibration itself. Learned models also benefit, because order-domain features vary far less with speed.
Can you predict exactly when a component will fail?
Not as a single date. Remaining useful life is better treated as a probability over time, estimated from degradation indicators and censored run histories. That gives maintenance planners a risk curve with uncertainty, which is more honest and more useful than a point estimate.
Can the analysis run on the sensor node instead of in the cloud?
Frequently. Envelope features, band energies and compact anomaly models can run on embedded processors, sending only features or alerts upstream to save bandwidth and power. The tradeoff is less raw data for later investigation, so we usually recommend keeping occasional raw snapshots for review and retraining.