Machine Health Monitor
Edge-AI predictive maintenance for rotating machines (RD-001)
The Machine Health Monitor (RD-001) is an AIoT predictive-maintenance sensor from SVB Tech Labs that watches rotating machines — motors, pumps and fans — for bearing wear, imbalance and misalignment. A small wireless node reads vibration from a 3-axis MEMS accelerometer, turns each second into compact vibration features, and runs the machine-learning model on the microcontroller itself, so raw data never has to leave the plant. It learns each machine's own healthy signature for about a day, then warns when the machine drifts away from it. In lab trials on real run-to-failure recordings it flagged every one of four bearing failures 42 to 120 hours ahead, with under one false alarm per machine per month. It is an early-stage R&D prototype: the full signal chain and models are verified in software and on an emulated chip, ahead of the first hardware build and plant pilot.
R&D prototype · verified in software and emulation · hardware pilot next · not yet for sale
At a glance
Machine Health Monitor, in short.
- What it is
- An on-device (edge) vibration sensor for predictive maintenance of rotating machines
- Watches for
- Bearing wear (outer, inner, ball), imbalance and misalignment on motors, pumps and fans
- How it senses
- 3-axis wideband MEMS accelerometer (ST IIS3DWB), ~13.3 kHz per axis; optional current clamp for shaft speed
- Where the AI runs
- On the node itself — no cloud needed to detect a fault
- Edge hardware
- ESP32-S3 microcontroller (WROOM-1-N8R8 with PSRAM)
- Connectivity
- Wi-Fi and MQTT to a plant gateway (Raspberry Pi or any Linux/Windows box)
- On-node model size
- 2.9 KB INT8 fault classifier, plus a self-learning anomaly engine (~185 KB RAM in all)
- Early warning (lab)
- 42–120 h before 4 real bearing failures; ≤ 0.71 false alarms per machine-month
- Status
- R&D prototype — verified in software and emulation; hardware bring-up and bench rig next
- Developer
- SVB Tech Labs, Hyderabad, India
Why RD-001
Catch a failing machine days before it stops the line
A bearing fails and the line stops
An unplanned motor, pump or fan failure can halt production for days. The warning signs are in the vibration long before the breakdown, but nobody is listening to them minute by minute.
Experts visit; faults don't wait
A vibration analyst with a handheld meter visits now and then. Damage that starts between visits grows unseen, and skilled analysts are scarce and expensive to send to every machine.
Streaming everything to the cloud is heavy
Raw vibration is a firehose. Shipping it all to the cloud for analysis costs bandwidth and money, adds latency, and raises questions about where a plant's operating data ends up.
Factory-set thresholds misfire
Every installation vibrates differently — mounting, load and the machine itself. One fixed alarm threshold across a fleet either cries wolf on healthy machines or misses early damage on others.
How it works
How the Machine Health Monitor works, in five steps
Step 01
Mount the node on the machine
Fix the sensor node to the bearing housing or motor casing, close to where the vibration is. One node reads three axes, so it watches vertical, horizontal and axial motion at the same measurement point.
Step 02
Power it and point it at the gateway
Give the node power and the Wi-Fi details and the address of the plant gateway. The node publishes over MQTT; the gateway runs on a Raspberry Pi or any Linux or Windows box on the plant network.
Step 03
Let it learn the machine
For about a day the node only learns: it builds a statistical picture of this specific machine's healthy vibration, per operating speed, with no labels and no factory thresholds. It judges the machine against itself from then on.
Step 04
Screen the baseline at install
When learning ends, the gateway screens the baseline so a machine that was already damaged at install is not learned as 'normal'. A suspect baseline waits for a person to mark it healthy or send it for inspection.
Step 05
Watch, and get warned early
The node now scores every window against the learned baseline and escalates Normal → Watch → Warning → Critical as evidence builds. The gateway adds the likely fault, points to the sensor that alarmed first, and shows it all on a dashboard.
Features
Everything the monitor does, from sensing to warning
Senses the machine in detail
Wideband 3-axis vibration
An ST IIS3DWB MEMS accelerometer samples each axis at about 13.3 kHz, wide enough to catch the high-frequency impacts of early bearing damage.
Three axes, one point
Vertical, horizontal and axial motion are measured together, so misalignment that shows up as an axial harmonic is not missed.
22 vibration features per second
Each one-second window becomes a compact set of features — impulsiveness, ISO velocity, shaft orders, envelope and bearing-defect scores — not a raw waveform.
Speed without a tachometer
Shaft speed is estimated from the vibration itself (with a nameplate hint), or read from an optional current clamp on synchronous motors.
Thinks on the node (TinyML at the edge)
Self-learning anomaly engine
A lightweight statistical model learns each machine's healthy signature and flags when it drifts, using a Mahalanobis distance to that baseline — the signal validated to warn 42–120 h early.
2.9 KB fault classifier
A quantised INT8 neural network (22→16→4) names the likely fault family — bearing, imbalance or misalignment — in under 3 KB of flash.
Physics for the bearing part
A physics rule reads the envelope spectrum at the bearing's defect frequencies to suggest which part is failing: outer race, inner race or ball.
No cloud in the loop
Detection, learning and diagnosis all run on the microcontroller. The plant keeps working — and keeps warning — even with no internet.
From node to dashboard
Standard MQTT
The node publishes health, status and feature messages over MQTT like any industrial IoT device, under a documented schema (rd001.health.v1).
Plant gateway
A small gateway service (paho-mqtt and NumPy only) subscribes to every node, runs the diagnosis and serves a dashboard — no TensorFlow, no heavy web stack.
Retained status for late joiners
Current state is published as retained MQTT, so a dashboard, SCADA system or cloud bridge that connects late immediately sees where each machine stands.
Dashboard by machine and sensor
Level, score-vs-threshold trend, ISO zone, estimated speed, install screening and diagnosis, all per machine and per sensor.
Warnings you can act on
Each machine judged against itself
Per-machine baselines gave 0% false positives on healthy test bearings, where a one-size-fits-all detector flagged 8–18% of healthy windows.
Clean escalation
Alarms step up through Watch, Warning and Critical with hysteresis, and in the lab each held to failure without flapping back and forth.
Points to the real culprit
On a shared shaft, healthy neighbours shake too near the end. The gateway attributes the fault to the sensor that alarmed first and strongest — 45 h ahead of its neighbours in a replay.
Lead with the anomaly
The validated signal is 'this machine has changed'. The fault label is shown as indicative, since it firms up only as an episode builds.
Robust in a real plant
Catches a broken sensor
Each window is checked for a dead, stuck, flat or saturated sensor. A faulty window is reported but never scored or learned, so a loose sensor can't raise a false alarm or poison the baseline.
Rides out network outages
While MQTT is down, windows are written to a power-cut-safe on-node log (about three days for three axes) and replayed in order when the link returns, with no duplicates and nothing lost.
Screens damaged installs
Install-time screening caught 92–100% of already-damaged machines in testing, so their damage is not mistaken for normal.
Headroom for Wi-Fi and growth
Moving learning buffers to PSRAM keeps internal RAM flat during learning, leaving room for Wi-Fi, TLS and future on-node models.
Private by design, and honest about limits
Operating data stays on site
Because the AI runs on the node and gateway, a plant's vibration and operating patterns need never leave its own network.
The plant owns its dataset
Learning windows are kept on the gateway as the start of the plant's own labelled dataset, for retraining on its real machines.
Decision support, not a trip relay
RD-001 gives early warning for a person to act on. It is not a safety shutdown or protection device, and does not replace an analyst on critical assets.
Scoped to what was tested
It targets motors, pumps and fans above ~10 Hz shaft speed. Gearboxes, reciprocating and very low-speed machines were not validated.
Who it's for
Who the Machine Health Monitor is for
Plant maintenance teams
Get days of warning before a bearing seizes, so a repair can be planned into a shift change instead of forced by a breakdown in the middle of a run.
Motor, pump and fan fleets
Put a low-cost node on each rotating asset and watch them all from one dashboard, instead of sending an analyst round with a handheld meter now and then.
Plants wary of the cloud
Keep condition monitoring entirely on the plant network — the node detects faults on-chip and the gateway runs on a Raspberry Pi, with no vibration data leaving site.
Sites with no vibration expert
The node learns each machine on its own, with no thresholds to set and no spectra to read, and raises a plain Watch / Warning / Critical level for the team.
OEMs and system integrators
A documented MQTT schema and retained messages let the health data flow into existing SCADA, Node-RED or cloud dashboards without bespoke glue.
Pilot and evaluation partners
Early industrial partners who want to co-develop and trial predictive maintenance on their own machines as RD-001 moves from the lab to a bench rig and first plant.
Compare
RD-001 vs periodic manual inspection vs run-to-failure
| Capability | RD-001 Machine Health Monitor | Periodic manual inspection | Reactive (run-to-failure) |
|---|---|---|---|
| Warns before a failure | Days ahead (42–120 h in lab) | Only at the next visit | No — you find out when it breaks |
| Watches continuously | Every minute, every machine | Periodic spot checks | Not at all |
| Needs a vibration expert on site | No — it learns the machine | Yes | No |
| Adapts to each machine | Learns its own baseline | Analyst's judgement | — |
| Works without the cloud | Yes — AI runs on the node | Yes | Yes |
| Keeps operating data on site | Yes | Yes | Yes |
| Cost to cover a whole fleet | A node per machine | Analyst time per round | Repair and lost production |
Glossary
Predictive-maintenance terms, explained
- Predictive maintenance
- Fixing a machine based on its actual condition — acting on early warning signs — rather than on a fixed schedule or only after it breaks down.
- Condition monitoring
- Continuously measuring a machine's health, usually from vibration, temperature or current, to spot developing faults. RD-001 does this from vibration, on the machine itself.
- Vibration analysis
- Reading a machine's vibration to diagnose faults. Bearing damage, imbalance and misalignment each leave a distinct pattern in the frequency content of the signal.
- Edge inference (TinyML)
- Running a machine-learning model on a small, low-power microcontroller at the source of the data, instead of sending the data to a server or the cloud to be analysed.
- Self-baselining anomaly detection
- Learning what one specific machine's healthy vibration looks like, then flagging when it drifts from that — so each machine is judged against itself, not a fleet-wide threshold.
- Mahalanobis distance
- A statistical measure of how far a new reading sits from a learned 'normal' cloud of readings, accounting for how the features vary together. RD-001's engine uses it to score anomaly.
- Envelope analysis
- A signal-processing technique that pulls out the repeating impacts a damaged bearing makes, even when they are buried under louder machine vibration.
- BPFO / BPFI / BSF
- Ball-pass frequency outer/inner race and ball-spin frequency: the characteristic repetition rates at which a defect on each bearing part shows up, used to tell which part is failing.
- ISO 20816
- The international standard for rating machine vibration severity by velocity into zones A–D. RD-001 reports the ISO zone alongside its own anomaly level.
- MQTT
- A lightweight publish/subscribe messaging protocol common in industrial IoT. RD-001 nodes publish health and status over MQTT to the plant gateway.
FAQ
Frequently asked questions about the Machine Health Monitor
What is the Machine Health Monitor (RD-001)?
It is an AIoT predictive-maintenance sensor from SVB Tech Labs for rotating machines such as motors, pumps and fans. A wireless node measures vibration and runs a machine-learning model on the microcontroller itself to warn, days ahead, when a bearing is wearing or a shaft is going out of balance or alignment.
What faults can it detect?
Bearing degradation (outer race, inner race and ball defects), imbalance and misalignment on motors, pumps, fans and similar rotating equipment. It was not validated on gearboxes, reciprocating machines or very low-speed machines (below about 10 Hz shaft speed).
How much early warning does it give?
In lab trials on real run-to-failure recordings (NASA IMS), it raised a sustained warning 42 to 120 hours before each of four bearing failures, and the warning held to failure without flapping. These are research-dataset results, not yet a guarantee on your machines.
Does it need the cloud or the internet?
No. The learning, anomaly detection and diagnosis all run on the node and a local gateway, so faults are detected on the plant network with no internet. You can optionally bridge the data to the cloud, but it is not required.
Does it need a vibration expert to set up?
No. Each node learns its own machine's healthy signature for about a day, with no thresholds to set and no spectra to interpret, then reports a plain level — Normal, Watch, Warning or Critical — with a suggested fault.
What hardware does it run on?
A sensor node built on an ESP32-S3 microcontroller (the WROOM-1-N8R8 module with PSRAM) reading an ST IIS3DWB 3-axis accelerometer, with an optional current clamp for shaft speed. A plant gateway runs on a Raspberry Pi or any Linux or Windows machine.
How does it avoid false alarms?
It judges each machine against its own learned baseline rather than a fleet-wide threshold, which gave 0% false positives on healthy test bearings and under 0.71 false alarms per machine-month. It also checks every window for a faulty sensor and never scores a bad reading.
How does it know which machine or bearing is actually failing?
On a shared shaft, healthy neighbours vibrate too near the end. The gateway attributes the fault to the sensor that alarmed first and most strongly — in one replay, about 45 hours before its neighbours reacted.
What stage is RD-001 at?
It is an early-stage R&D prototype. The full chain from sensor to dashboard, and all the models, are verified in software and on an emulated ESP32-S3; the next steps are bringing it up on real hardware, a bench rig with seeded faults, and a first plant pilot.
Is it available to buy?
Not yet. RD-001 is in development and is not priced or sold. SVB Tech Labs is looking for pilot partners to trial it on real machines. Message us on WhatsApp if you would like to be involved.
Learn more
Keep exploring.
Machine Health Monitor
Predict failures before they stop your machines
RD-001 is in active R&D and looking for pilot partners with real motors, pumps or fans to trial it on. Tell us about your machines.