Acoustic Predictive Maintenance in Practice
You don't need a sensor on every machine to start listening to them. A phone recording per machine on a regular round, scored and sorted by confidence, can tell a maintenance team where to look first. This is a routine for doing that, and an honest list of where you still need sensors.
Predictive maintenance usually means sensors: accelerometers on bearings, a gateway, a dashboard, a contract. For a plant's most critical assets that is money well spent. For the long tail of conveyors, fans, small pumps, compressors and drives that nobody instruments, the usual monitoring is a person who happens to notice a noise.
Acoustic predictive maintenance sits in between. The idea is simple: record each machine regularly, have a model do the first listen, and send people to the machines whose recordings sound wrong or uncertain. This post lays out a routine for doing that with a phone and Saina's mechanical specialist, where it helps, and where it doesn't. For the background on methods and the specialist's published evaluation, start with the pillar, machine fault detection from sound.
The routine
1. Make a machine list
One row per machine you will record: an ID, what it is in plain words ("belt-driven fan on the paint line extractor"), how it normally runs (constant speed, cycles, load changes), and who to call. The plain description becomes the state of every request for that machine, so write it once and well.
Check each machine type against what the specialist was trained on before you add it. Rolling-element bearings, a rotating-machine test rig, induction motors, one 3D printer and one industrial air compressor are in its training data. Fans, pumps and valves are not, and on public recordings of those (MIMII) the specialist detected faults worse than the base model, 50% against 70%. For those rows, plan to test both and use the base model if it does better on your recordings.
2. Fix where and how to record
From the specialist's card: hold the phone against or next to the housing, record 1 to 10 seconds, with the machine running steadily. Clips over 10 seconds are refused, never cut.
Add your own rules so recordings are comparable week to week:
- Mark the spot on the housing with paint or a sticker.
- Record in the same operating state each time (for example, at full load mid-shift).
- Use the same phone model where you can.
- Name files with machine ID and date, so nothing needs typing at the machine.
3. Pick a cadence
Weekly for machines that matter, monthly for the rest, are reasonable starting points (illustrative, not measured). The aim is to fit recordings into rounds people already walk, such as an operator's start-of-shift checks, instead of adding a new walk.
4. Score every recording
Each recording goes into one request with two questions: is it normal, and if not, which condition. Only offer conditions that are possible for that machine, plus a healthy option. For a motor, ask only whether it sounds normal: the specialist says only healthy or not for motors. For a compressor, normal or abnormal is all its training data supports.
5. Escalate by confidence
Run in decision mode with a threshold. Each answer then comes back accepted, or with no selection and a reason (below_threshold, below_margin or tie). Turn that into three queues:
- "Not normal", accepted: a work request for a technician to inspect the machine, with the recording attached.
- No confident answer: re-record at the next round, and have someone who knows the machine listen to the clip. Repeated uncertainty on one machine is itself worth a visit.
- "Normal", accepted: log it. No action.
How to flag uncertain AI decisions covers the review branch in more depth.
6. Check it against what technicians find
For the first months, every inspection triggered by a recording should end with a note: what the technician found. Also have someone record a few machines just before planned maintenance, when you know the condition. That gives you a small labelled set from your own plant, which is the only measurement that tells you whether this works on your machines.
A scoring script
Illustrative; the request shape follows the API docs.
import base64, csv, requests
MACHINES = { # from your machine list
'CV-07': {'state': 'The clip is a recording of a rolling-element bearing on a conveyor '
'drive shaft at constant speed, phone held against the housing.',
'conditions': {'healthy': None,
'inner': 'Inner race bearing fault',
'outer': 'Outer race bearing fault',
'ball': 'Ball (rolling element) fault'}},
'M-12': {'state': 'The clip is a recording of a three-phase induction motor at constant '
'speed, phone held next to the motor housing.',
'conditions': None}, # motors: normal or not only
}
def score(machine_id, wav_path):
m = MACHINES[machine_id]
questions = {'normal': {'type': 'yes_no',
'question': 'Is the machine operating normally (no fault or anomaly audible)?'}}
if m['conditions']:
questions['condition'] = {'type': 'single_choice',
'question': 'Which condition does the machine in this clip have?',
'options': m['conditions']}
audio = 'data:audio/wav;base64,' + base64.b64encode(open(wav_path, 'rb').read()).decode()
r = requests.post('https://api.saina.run/v1/ask',
headers={'Authorization': f'Bearer {API_KEY}'},
json={'model': 'saina-helm-2-omni-0.8b', 'specialist': 'mechanical',
'mode': 'decision', 'threshold': 0.8,
'state': m['state'], 'audios': [audio], 'questions': questions})
r.raise_for_status()
return r.json()['answers']
def queue_for(answers):
normal = answers['normal']['selected'] # True, False, or None if not confident
if normal is False:
return 'inspect'
if normal is None:
return 'listen_and_rerecord'
return 'log'
Write each result, with the probabilities, to the same log or CMMS record as the recording. A threshold of 0.8 is the default and a starting point, not a validated setting for your plant.
Where this saves effort
- Machines with no monitoring at all. Going from nothing to a recorded, scored check on a regular schedule is a real change, and the cost is a few seconds per machine on an existing round.
- Knowledge that isn't on shift. The operator recording the clip doesn't need to know what a worn bearing sounds like. The person who does gets a queue of recordings to check instead of a route to walk.
- A record over time. Even when the model says normal, you now have a dated recording of each machine. When something fails, there is a history to listen back to.
Where you still need sensors and specialists
- Critical assets. If a failure stops the line or hurts someone, use vibration monitoring, with permanently mounted sensors on the most critical ones. The specialist's card is explicit: it is a screening aid, not a substitute for inspection, vibration analysis or a qualified technician, and not for safety-critical shutdown decisions.
- Early bearing wear. The model hears audio at 16 kHz, so sound above 8 kHz is not in its input, and that is where some early bearing defects first show. Ultrasound instruments and vibration analysis see those stages; a phone recording scored this way won't. See bearing fault detection from sound for more on this.
- Machine types outside its training. Fans, pumps, valves, slide rails: test before trusting, and compare with the base model.
- Continuous coverage. A weekly recording finds what is audible that week. Faults that develop in days need continuous sensors or a condition-monitoring vendor's service.
- Your own machine's normal. If you have one machine type in quantity, recording its normal sound for a while and training your own anomaly detector on it may outperform a general model on that machine.
On the published evaluation: the specialist's card reports 88% across 1,165 held-out clips from its seven training sources, against 30% for the base model. Those are lab and workshop recordings of a small number of machines. Expect lower accuracy on other machines, mounts and rooms, and check on your own recordings before you rely on it. With the specialist on, general audio accuracy drops (56% against 69.4%), so use it for machines only.
Running it on site
Recordings from a plant often can't leave it. The specialist is published as a complete open-weights model (Apache 2.0) at run-saina/saina-helm-2-omni-0.8b-mechanical and loads on its own with saina 0.6.0 or later. Install the server with pip install "saina[local,server,media]" and list the specialist in SAINA_MODELS, pinned to a revision (for example SAINA_MODELS=run-saina/saina-helm-2-omni-0.8b-mechanical@<commit>). The script above then points at your own server instead of api.saina.run.
Pinning matters for a routine like this. Specialists are deployed separately from their model, so an update to the base model doesn't change the specialist you checked against your technicians' findings. When you move to a new revision, re-run your labelled set first.
Try it
The home page's Machine fault example runs a compressor recording with and without the specialist (no account; 5 free runs). In the console, the Compressor fault preset takes your own clip. Introducing Saina specialists explains how specialists work across the API.
Related posts
- Machine fault detection from sound (pillar)
- Introducing Saina specialists
- Bearing fault detection from sound