La détection d'anomalies audio vous permet d'entendre les problèmes des moteurs, pompes, ventilateurs et réducteurs avant qu'ils ne se transforment en pannes. Ce guide de cas d'usage explique le fonctionnement de la surveillance acoustique, les modèles qui tournent sans difficulté sur du matériel edge, et comment publier des scores d'anomalie via MQTT pour que tableaux de bord et équipes de maintenance reçoivent un signal clair sans que personne ne diffuse d'audio brut.
Pourquoi écouter les machines
Les techniciens expérimentés diagnostiquent les machines à l'oreille : le sifflement d'un roulement sec, le cognement rythmique d'une fixation desserrée, le chuintement d'une vanne qui fuit. La surveillance acoustique automatise ce savoir-faire et l'applique en continu.
Le son présente des avantages pratiques par rapport à d'autres capteurs :
- Sans contact. Un microphone n'a pas besoin d'être monté sur un arbre en rotation ni câblé à un automate, ce qui facilite les mises à niveau d'installations existantes.
- Large couverture. Un seul microphone peut surveiller un petit groupe de machines ou toute une section de convoyeur.
- Information riche. Les fréquences révèlent les vitesses de rotation, les frottements, la cavitation, les fuites d'air et les chocs.
- Matériel bon marché. Les microphones MEMS coûtent peu, et les modèles numériques se connectent directement aux microcontrôleurs et aux ordinateurs monocartes.
L'inconvénient, c'est le bruit. Les usines sont bruyantes, les sons de fond changent sans cesse et les machines voisines s'invitent dans chaque enregistrement. Un système utile doit distinguer « différent de d'habitude » de « le chariot élévateur vient de passer ».
Comment fonctionne la détection d'anomalies audio
Presque tous les systèmes concrets suivent le même pipeline.
1. Capture
Enregistrez de courts extraits (généralement d'une à dix secondes) à 16 kHz ou plus. De nombreux défauts de machine apparaissent sous 8 kHz, mais les fuites d'air et certains défauts de roulement produisent des composantes ultrasonores ou à haute fréquence : adaptez donc la fréquence d'échantillonnage et le microphone au défaut qui vous intéresse.
2. Extraction de caractéristiques
Les formes d'onde brutes sont difficiles à comparer. Convertissez chaque extrait en spectrogramme log-mel : une image temps-fréquence dont les bandes de fréquence sont espacées selon la perception humaine de la hauteur, avec l'énergie sur une échelle logarithmique. Des alternatives plus simples existent : énergies par bande, centroïde spectral et niveau RMS.
3. Apprendre la normalité
Les défaillances étant rares, les modèles sont entraînés uniquement sur des enregistrements normaux. L'objectif n'est pas de reconnaître un défaut précis, mais de mesurer à quel point un nouvel extrait s'éloigne de tout ce que le modèle a entendu en fonctionnement normal.
4. Évaluer et décider
Chaque extrait reçoit un score d'anomalie. Un seuil, fixé à partir de la distribution des scores d'enregistrements normaux mis de côté, décide si l'extrait est inhabituel. Des règles de persistance (plusieurs extraits inhabituels d'affilée) éliminent les bruits ponctuels.
Les options de modèles pour l'edge
| Approche | Méthode de score | Matériel | Points forts | Points faibles |
|---|---|---|---|---|
| Référence d'énergie par bande | Distance à la moyenne et à la variance par bande | Microcontrôleur ou Pi | Minuscule, explicable | Manque les changements de motif subtils |
| Mélange gaussien sur caractéristiques | Log-vraisemblance négative | Classe Raspberry Pi | Gère plusieurs modes de fonctionnement | Choix des caractéristiques délicat |
| Isolation Forest sur caractéristiques | Longueur de chemin | Classe Raspberry Pi | Multivarié, rapide à entraîner | Ingénierie des caractéristiques requise |
| Autoencodeur convolutif | Erreur de reconstruction sur spectrogrammes | Pi avec accélérateur, Jetson | Apprend des motifs complexes | Plus de données, plus difficile à expliquer |
| Embedding pré-entraîné plus distance | Distance aux embeddings normaux | Jetson ou boîtier edge avec GPU | Performant avec peu de données d'entraînement | Modèle plus volumineux |
Une démarche raisonnable consiste à commencer par la référence d'énergie par bande, à prouver que le son porte un signal pour votre machine, puis à passer à un autoencodeur si nécessaire. Le tutoriel Isolation Forest pour les données de capteurs détaille l'approche par caractéristiques, et le même schéma s'applique aux caractéristiques audio.
Un écouteur edge minimal avec sortie MQTT
Le script ci-dessous s'exécute sur un Raspberry Pi ou toute machine Linux équipée d'un microphone. Il enregistre des extraits de deux secondes, calcule les énergies logarithmiques dans des bandes espacées selon l'échelle mel, apprend une référence pendant les premières minutes, puis publie un score d'anomalie pour chaque extrait.
pip install "paho-mqtt>=2.0" numpy sounddevice
# Sous Raspberry Pi OS, il peut aussi falloir : sudo apt install libportaudio2
import json
import time
import uuid
import numpy as np
import paho.mqtt.client as mqtt
import sounddevice as sd
PREFIX = "connectmq/demo/snd-4be0/plant1/line2/fan3"
RATE, CLIP_S, BANDS = 16_000, 2.0, 32
LEARN_CLIPS = 60 # environ deux minutes de son normal
THRESHOLD = 4.0 # z absolu moyen sur l'ensemble des bandes
def mel_edges(n_bands, fmin=50, fmax=7_800):
mel = lambda f: 2595 * np.log10(1 + f / 700)
inv = lambda m: 700 * (10 ** (m / 2595) - 1)
return inv(np.linspace(mel(fmin), mel(fmax), n_bands + 1))
EDGES = mel_edges(BANDS)
def band_features(clip):
spec = np.abs(np.fft.rfft(clip * np.hanning(len(clip)))) ** 2
freqs = np.fft.rfftfreq(len(clip), 1 / RATE)
feats = [spec[(freqs >= lo) & (freqs < hi)].sum() for lo, hi in zip(EDGES[:-1], EDGES[1:])]
return np.log10(np.array(feats) + 1e-10)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"listener-{uuid.uuid4().hex[:8]}")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
history, mean, std, streak = [], None, None, 0
while True:
clip = sd.rec(int(RATE * CLIP_S), samplerate=RATE, channels=1, dtype="float32")
sd.wait()
feats = band_features(clip[:, 0])
rms_db = float(20 * np.log10(np.sqrt(np.mean(clip ** 2)) + 1e-9))
if len(history) < LEARN_CLIPS:
history.append(feats)
if len(history) == LEARN_CLIPS:
mean = np.mean(history, axis=0)
std = np.std(history, axis=0) + 1e-3
client.publish(f"{PREFIX}/audio/status",
json.dumps({"state": "monitoring", "bands": BANDS}),
qos=1, retain=True)
continue
z = np.abs((feats - mean) / std)
score = float(np.mean(z))
top_band = int(np.argmax(z))
streak = streak + 1 if score > THRESHOLD else 0
msg = {"ts": time.time(), "score": round(score, 2), "threshold": THRESHOLD,
"rmsDb": round(rms_db, 1),
"topBandHz": [round(EDGES[top_band]), round(EDGES[top_band + 1])],
"isAnomaly": streak >= 3, "model": "band-baseline-v1"}
client.publish(f"{PREFIX}/audio/score", json.dumps(msg), qos=0)
Le message contient volontairement la bande de fréquence qui a le plus dévié. Un technicien qui voit « anomalie, changement le plus fort entre 2,1 et 2,4 kHz » dispose d'un bien meilleur point de départ que s'il ne voyait qu'un voyant rouge.
Exécutez le script dans une pièce calme, laissez-le apprendre pendant deux minutes, puis émettez un son ou tapotez le bureau près du microphone et regardez le score monter :
mosquitto_sub -h broker.connectmq.com -p 1883 -i snd-watch-4be0 -t "connectmq/demo/snd-4be0/#" -v
Pourquoi publier des scores et non de l'audio
Diffuser l'audio brut de chaque machine coûte cher, pose des problèmes de confidentialité (les microphones peuvent capter des conversations) et n'est pas nécessaire. Évaluer en edge et publier un message JSON compact toutes les quelques secondes garde une bande passante minime et le son sur site.
Lorsqu'un extrait est signalé, vous pouvez quand même vouloir une preuve. Un bon compromis consiste à stocker localement l'extrait signalé et à ne publier que ses métadonnées, ou à téléverser de courts extraits à la demande via un topic de commande, en restant sous la limite de taille de message du broker.
Passer de la référence à l'autoencodeur
Si la référence d'énergie par bande prouve que le son porte un signal mais manque des défauts plus subtils, l'étape suivante habituelle est un petit autoencodeur convolutif entraîné sur des spectrogrammes log-mel d'extraits normaux. Entraînez-le sur une station de travail, convertissez-le en TensorFlow Lite ou ONNX, et exécutez-le sur l'équipement edge à la place de la référence. Côté MQTT, rien ne change : l'écouteur publie toujours un score, un seuil et la version du modèle sur le même topic. Les tableaux de bord et les règles d'alerte continuent de fonctionner, et vous pouvez comparer les deux modèles en les exécutant côte à côte pendant une semaine, chacun publiant sur son propre topic de score.
Liste de contrôle du déploiement
- Fixez le microphone de façon constante. Déplacer le microphone modifie la référence ; fixez-le et documentez sa position.
- Enregistrez tous les modes normaux. Ralenti, mi-charge, pleine charge et démarrage ont chacun leur son ; apprenez-les tous ou conditionnez l'évaluation à l'état de la machine.
- Utilisez l'état de la machine comme contexte. Abonnez-vous au topic d'état de la machine et suspendez l'évaluation pendant les changements de série ou les nettoyages.
- Fixez les seuils à partir de données normales mises de côté, et non à partir des extraits d'entraînement eux-mêmes.
- Exigez une persistance avant d'alerter.
- Protégez la confidentialité. Traitez l'audio localement et ne publiez jamais d'extraits bruts sur des topics partagés ou publics.
- Réapprenez après une maintenance. Une nouvelle courroie ou un nouveau roulement modifie légitimement le son.
Du score à l'action de maintenance
Les scores d'anomalie prennent de la valeur lorsqu'ils rejoignent d'autres signaux. Un score acoustique en hausse, accompagné d'une hausse des vibrations et de la température, constitue un indice fort ; un pic acoustique isolé au passage d'un chariot élévateur, non. Cette fusion et l'étape d'estimation des dates de défaillance sont traitées dans la maintenance prédictive par machine learning, tandis que les méthodes de détection d'anomalies IoT expliquent où chaque détecteur doit s'exécuter. Le guide IA et IoT replace la surveillance acoustique dans le paysage plus large de l'edge AI.
Connecter les écouteurs à l'usine
Chaque écouteur n'est qu'un client MQTT : ajouter une machine revient à déployer un équipement de plus avec son propre topic. Pour les expérimentations, l'espace du serveur MQTT public gratuit convient avec des sons synthétiques. Pour de vraies machines, utilisez un broker MQTT privé dans le cloud avec TLS sur le port 8883 et des identifiants par écouteur. ConnectMQ affiche chaque écouteur dans la vue des équipements organisée par niveaux ISA-95, vous permet de suivre les scores dans l'explorateur de topics en direct et peut déclencher des alertes à seuil sur le champ score sans code supplémentaire.
Commencez à écouter avec ConnectMQ
Créez un broker MQTT managé sur ConnectMQ avec l'offre gratuite Serverless sur app.connectmq.com, sans carte bancaire, remplacez l'hôte et les identifiants dans le script de l'écouteur et regardez le score acoustique de votre première machine apparaître en temps réel.
Questions fréquentes
Quel microphone utiliser pour la détection d'anomalies audio ?
Un microphone MEMS numérique ou un microphone USB correct suffit pour la plupart des défauts audibles. Pour les fuites d'air et les premiers dommages de roulement, envisagez des microphones et des fréquences d'échantillonnage qui captent les hautes fréquences.
La détection d'anomalies audio peut-elle s'exécuter sur un microcontrôleur ?
Les références simples d'énergie par bande et les petits modèles TinyML tournent sur des microcontrôleurs performants comme l'ESP32-S3. Les autoencodeurs sur spectrogrammes complets nécessitent généralement un Raspberry Pi avec accélérateur ou un équipement de classe Jetson.
Comment gérer un bruit de fond important ?
Placez le microphone près de la machine, apprenez la référence dans des conditions de fond réalistes et exigez plusieurs extraits anormaux consécutifs avant d'alerter. Les microphones directionnels aident aussi.
Est-il sûr d'envoyer de l'audio via MQTT ?
Privilégiez l'envoi de scores et de métadonnées plutôt que d'audio. Si vous devez envoyer des extraits, utilisez un broker privé avec TLS et identifiants, jamais un espace de test public.
