Détection des fuites d'air comprimé avec capteurs IoT de débit et de pression

La détection des fuites d'air comprimé transforme une perte invisible et permanente en un chiffre que l'on peut suivre, communiquer et traiter. Dans ce guide, vous allez concevoir un dispositif de surveillance avec des capteurs de débit et de pression qui publient via MQTT, calculer les fuites à partir de la consommation hors production et de la chute de pression, et déclencher des alertes lorsque le taux de fuite remonte après une campagne de réparation.

Pourquoi les fuites d'air comprimé méritent une surveillance continue

L'air comprimé est l'une des utilités les plus coûteuses d'une usine par unité d'énergie utile fournie : le compresseur convertit l'électricité essentiellement en chaleur, et seule une fraction se retrouve en travail à l'outil. Les fuites aggravent la situation, car elles consomment de l'air à chaque heure de chaque jour, y compris la nuit et le week-end, quand rien ne produit.

La plupart des usines savent déjà que les fuites existent. Les équipes de maintenance réalisent des campagnes de détection par ultrasons, étiquettent les fuites et les réparent. Le problème, c'est la suite : sans mesure, personne ne peut dire combien la campagne a fait économiser, et en quelques mois de nouvelles fuites apparaissent sur les raccords rapides, les flexibles usés, les purgeurs et les joints de vérins. La surveillance continue boucle la boucle. Elle vous donne le taux de fuite du jour, le compare au taux mesuré après la dernière réparation et signale quand il est temps de lancer la campagne suivante.

Que mesurer

Pas besoin d'un capteur sur chaque machine pour commencer. Un petit nombre de points de mesure répond aux questions importantes.

Les débitmètres massiques thermiques sont le choix habituel pour le collecteur, car ils mesurent directement le débit normalisé et génèrent peu de perte de charge. De nombreux modèles actuels exposent leurs mesures en Modbus RTU ou Modbus TCP, certains en 4-20 mA, et quelques-uns parlent MQTT nativement.

Architecture : du capteur au chiffre de fuite

Le chemin des données suit le même schéma que pour toute surveillance d'utilités :

1. Les capteurs et compteurs sont installés sur le réseau d'air et sur les compresseurs.
2. Une passerelle edge (un PC industriel, un Raspberry Pi avec une interface RS-485, un automate doté d'une bibliothèque MQTT ou Node-RED) interroge les registres Modbus ou les entrées analogiques toutes les quelques secondes.
3. La passerelle publie du JSON via MQTT vers un broker, avec une structure de topics fondée sur la hiérarchie de l'usine.
4. Les consommateurs s'abonnent : un historien écrit les valeurs dans une base de séries temporelles, un petit service calcule les indicateurs de fuite, et les tableaux de bord et alertes lisent les résultats.

Le broker découple tous ces éléments. Si vous ne savez pas exactement ce que fait un broker MQTT dans ce schéma, voyez-le comme le standard téléphonique auquel se connectent tous les producteurs et consommateurs : ajouter un nouveau tableau de bord ne touche jamais à la passerelle.

Une organisation des topics conforme à l'ISA-95 garde l'ensemble lisible et permet à ConnectMQ d'afficher les appareils par niveau dans sa vue des appareils :

connectmq/plant1/utilities/compressed-air/header/flow        {"ts":1760600000,"nm3_min":18.4}
connectmq/plant1/utilities/compressed-air/header/pressure    {"ts":1760600000,"bar":6.9}
connectmq/plant1/utilities/compressed-air/end-of-line/pressure {"ts":1760600000,"bar":6.4}
connectmq/plant1/utilities/compressed-air/comp1/state        {"ts":1760600000,"state":"load","kw":72.5}
connectmq/plant1/utilities/compressed-air/leak/offshift      {"ts":1760600000,"nm3_min":4.1,"share_pct":22.3}

Le dernier topic est une valeur calculée, publiée en retained afin qu'un tableau de bord ouvert à tout moment affiche immédiatement le dernier chiffre de fuite.

Méthode 1 : débit de référence hors production

La façon la plus simple et la plus robuste de quantifier les fuites en continu est d'observer le débit lorsque la production est arrêtée. Pendant une fenêtre d'arrêt planifiée (pas de poste de nuit, dimanche, pause déjeuner sur une ligne qui s'arrête complètement), presque tout ce qui traverse le collecteur est de la fuite, plus quelques usages légitimes permanents comme l'air de purge ou des lames d'air qui n'ont pas été coupées.

Le service ci-dessous s'abonne au débit du collecteur, vérifie si l'heure actuelle tombe dans une fenêtre d'arrêt configurée, calcule la moyenne du débit sur cette fenêtre et publie le résultat. Il utilise le serveur MQTT public gratuit pour la démo, réservé aux tests ; remplacez-le par vos identifiants en production.

#!/usr/bin/env python3
"""Off-shift compressed air leak estimator."""
import json
import statistics
import time
from datetime import datetime

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
PREFIX = "connectmq/demo/air-7f3k/plant1/utilities/compressed-air"
FLOW_TOPIC = f"{PREFIX}/header/flow"
LEAK_TOPIC = f"{PREFIX}/leak/offshift"
IDLE_HOURS = range(1, 5)          # 01:00-04:59 est une fenêtre d'arrêt planifiée
PRODUCTION_AVG_NM3_MIN = 18.0     # débit moyen de référence en production

samples = []
window_open = False


def in_idle_window(now: datetime) -> bool:
    return now.hour in IDLE_HOURS


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(FLOW_TOPIC, qos=1)


def on_message(client, userdata, msg):
    global window_open
    data = json.loads(msg.payload)
    now = datetime.now()
    if in_idle_window(now):
        window_open = True
        samples.append(float(data["nm3_min"]))
    elif window_open and samples:
        leak = statistics.median(samples)
        result = {
            "ts": int(time.time()),
            "nm3_min": round(leak, 2),
            "share_pct": round(100 * leak / PRODUCTION_AVG_NM3_MIN, 1),
            "samples": len(samples),
        }
        client.publish(LEAK_TOPIC, json.dumps(result), qos=1, retain=True)
        print("Published leak estimate:", result)
        samples.clear()
        window_open = False


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="leak-estimator-7f3k")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.loop_forever()

Utiliser la médiane plutôt que la moyenne rend l'estimation insensible à quelqu'un qui souffle brièvement une pièce pendant la nuit. Dans une vraie usine, vous prendriez la fenêtre d'arrêt dans le planning de production ou dans l'état des machines plutôt que dans une plage horaire fixe, et vous soustrairiez les usages permanents connus.

Méthode 2 : test de chute de pression

Lorsqu'il n'y a pas encore de débitmètre, ou pour le valider, un test de chute de pression fournit une estimation directe des fuites. Tous les consommateurs étant arrêtés, on coupe les compresseurs et on enregistre la pression du réseau pendant qu'elle baisse. Comme les transmetteurs de pression publient déjà via MQTT, il suffit de noter le début et la fin du test.

Le débit de fuite en air libre vaut approximativement :

Q_leak [l/min free air] = V [l] x (p1 - p2) [bar] / (t [min] x 1.013 [bar])

V   = total system volume (receivers + piping)
p1  = start pressure, p2 = end pressure (gauge)
t   = time to fall from p1 to p2

Par exemple, avec un réseau de 3 000 litres qui passe de 7,0 à 6,0 bar en 2 minutes, la fuite vaut environ 3 000 x 1,0 / (2 x 1,013), soit à peu près 1 480 l/min d'air libre. Certains praticiens appliquent un facteur de correction, car les fuites débitent davantage à pleine pression qu'en fin de test ; quelle que soit la convention choisie, appliquez-la de manière cohérente pour que les résultats restent comparables dans le temps.

Réalisez le test aux mêmes moments chaque mois et publiez le résultat sur un topic leak/decay-test : vous obtenez une seconde courbe de tendance indépendante du débitmètre.

Alertes et KPI de détection des fuites d'air comprimé

Les chiffres ne changent les comportements que si quelqu'un les voit. Un ensemble pratique d'alertes et de KPI :

1. Débit de fuite hors production par nuit, suivi chaque semaine. C'est le chiffre phare.
2. Part des fuites en pourcentage du débit moyen de production, utile pour comparer des usines de tailles différentes.
3. Puissance spécifique (kW par m³/min) de la centrale de compression, qui révèle des cycles charge/vide inefficaces.
4. Perte de charge entre le refoulement du compresseur et l'extrémité du réseau, qui explique souvent pourquoi les consignes ont été relevées.
5. Alerte lorsque la part des fuites dépasse le niveau post-réparation d'une marge que vous choisissez, signe qu'une nouvelle campagne ultrasons s'impose.

Dans le portail ConnectMQ, vous pouvez créer une règle d'alerte sur seuil sur le champ nm3_min ou share_pct du topic de fuite ; chaque dépassement est consigné dans le journal des alertes. Pour des notifications par e-mail, messagerie ou SMS, un petit flux Node-RED ou un abonné Python connecté au broker relaie l'événement, car ConnectMQ n'envoie pas lui-même de webhooks. Le guide des alertes sur seuil présente ce pattern pas à pas.

Pièges courants

• Mauvaise position du débitmètre. Installer le débitmètre avant le sécheur mesure aussi les pertes de purge et d'évacuation des condensats. Placez-le après le traitement de l'air, sauf si vous voulez précisément les inclure.
• Oublier les usages permanents. Les lames d'air, buses de soufflage et refroidisseurs d'armoire laissés en marche la nuit ne sont pas des fuites, mais du gaspillage. Identifiez-les séparément pour que le chiffre de fuite reste honnête.
• Confondre débit normal et débit standard. Assurez-vous que tous les débitmètres utilisent les mêmes conditions de référence avant de comparer ou d'additionner.
• Aucun lien avec l'état de production. Sans savoir quand l'usine est à l'arrêt, la référence relève de la devinette. Récupérez l'état depuis vos topics de surveillance de l'état des machines si vous les avez déjà.
• Projets ponctuels. Un tableau de bord sans propriétaire se dégrade vite. Confiez le KPI de fuite à une personne et passez-le en revue dans la même réunion que les autres chiffres énergétiques.

S'intégrer dans la stratégie énergétique globale

L'air comprimé n'est généralement qu'une ligne d'un programme plus large. Le même broker et la même structure de topics transportent les compteurs électriques, le gaz et l'eau : l'estimateur de fuites ci-dessus se place donc à côté des données décrites dans le suivi énergétique de l'usine et de la ventilation par machine issue du sous-comptage électrique. Si vous préparez l'ISO 50001, l'air comprimé est fréquemment identifié comme un usage énergétique significatif, et des données de fuite continues deviennent une preuve d'amélioration. Pour la vision stratégique de la place de l'énergie parmi les autres initiatives, consultez le guide de l'industrie intelligente.

Exploiter le broker vous-même est possible, mais les données d'utilités n'ont de valeur que si elles sont toujours disponibles. Un broker MQTT cloud retire les correctifs, les certificats et les soucis de disponibilité de la liste de l'équipe de maintenance, qui peut se concentrer sur la réparation des fuites.

Surveillez votre air comprimé avec ConnectMQ

ConnectMQ est un broker MQTT managé avec TLS, une vue des appareils compatible ISA-95, un explorateur de topics en direct et des alertes sur seuil. Prototypez votre surveillance des fuites sur broker.connectmq.com, puis créez gratuitement un broker Serverless, sans carte bancaire, et pointez-y vos passerelles.

Questions fréquentes

Faut-il un débitmètre pour commencer la détection des fuites d'air comprimé ?

Non. Des transmetteurs de pression suffisent pour réaliser des tests périodiques de chute de pression et enregistrer les résultats via MQTT. Un débitmètre massique thermique sur le collecteur principal rend la mesure continue et constitue l'étape suivante recommandée.

À quelle fréquence calculer l'estimation des fuites ?

Une fois par fenêtre d'arrêt planifiée suffit généralement, soit en pratique chaque nuit ou chaque week-end. Suivez les valeurs chaque semaine afin que le bruit à court terme ne déclenche pas de campagnes inutiles.

Les contrôleurs de compresseurs existants peuvent-ils fournir les données ?

Souvent, oui. De nombreux contrôleurs de compresseurs exposent l'état de charge, la pression et les heures de fonctionnement en Modbus, qu'une passerelle peut lire et publier via MQTT à côté de vos propres capteurs.

Le broker MQTT calcule-t-il lui-même le taux de fuite ?

Non. ConnectMQ transporte les données des capteurs et peut déclencher des alertes sur seuil à partir des valeurs publiées. Le calcul des fuites s'exécute dans un petit service, un flux Node-RED ou un script edge qui se connecte au broker en tant que client MQTT.