MQTT pour la télémétrie des services d'eau potable et d'assainissement

La télémétrie MQTT dans la gestion de l'eau réunit stations de pompage, réservoirs, surpresseurs et postes de relevage dispersés dans une seule couche de données en direct, à laquelle exploitants, ingénieurs et outils de planification peuvent tous s'abonner. Ce guide montre comment structurer cette télémétrie, quels signaux publier et de quelle manière, et comment déclencher des alertes à seuil sur les niveaux et les pressions avant qu'un réservoir ne se vide ou qu'une bâche ne déborde. Vous exécuterez aussi un petit simulateur de station et un outil d'alarme que vous pourrez adapter à de vrais équipements.

Le problème de la télémétrie dans les réseaux d'eau

Un service d'eau type exploite des dizaines à des centaines de sites distants répartis sur son territoire. Beaucoup ont été raccordés au fil des décennies avec des RTU, des radios et des protocoles différents, et sont interrogés par un maître SCADA central. Cette organisation fonctionne, mais elle crée des difficultés bien connues :

• Des scrutations lentes sur une radio partagée. Interroger chaque site à tour de rôle signifie qu'une alarme de niveau peut attendre la scrutation suivante.
• Des données enfermées dans le SCADA. Les équipes gestion patrimoniale, modélisation hydraulique et énergie demandent des exports ou construisent des interfaces point à point fragiles.
• Des générations d'équipements hétérogènes. Chaque nouveau type de site ajoute un driver et une table de registres de plus.
• Des sites cellulaires partout. Les sites récents utilisent des modems cellulaires, qui privilégient les connexions sortantes initiées par l'équipement plutôt que l'interrogation entrante.

MQTT inverse le sens : chaque station publie ses propres changements vers un broker, et chaque consommateur, SCADA compris, s'abonne. Si vous préparez le volet SCADA de cette transition, lisez MQTT dans les systèmes SCADA en complément de ce guide.

Que publier depuis chaque site

Partez des questions d'exploitation, pas de la liste de registres de la RTU. Le tableau ci-dessous constitue une base pratique pour les sites d'eau potable et d'assainissement.

Deux règles font fonctionner ce tableau. Publiez les valeurs analogiques par exception, avec une bande morte dimensionnée d'après la précision de l'instrument, et publiez immédiatement chaque changement d'état. Le guide du report by exception explique le dimensionnement des bandes mortes et pourquoi un heartbeat reste nécessaire.

Concevoir les topics d'un réseau d'eau

Les topics doivent refléter la façon dont les exploitants pensent le réseau : secteur, site, équipement, mesure. Une hiérarchie dans l'esprit d'ISA-95 assure la cohérence :

waterco/north/reservoir-hilltop/tank1/level
waterco/north/booster-ridge/pump2/running
waterco/north/booster-ridge/discharge/pressure
waterco/south/lift-station-07/wetwell/level
waterco/south/lift-station-07/site/status

Des règles qui portent leurs fruits plus tard :

• Gardez des noms de sites et d'équipements stables et en minuscules ; ils deviennent des identifiants dans tous les systèmes en aval.
• Mettez une mesure par topic, ou un petit objet JSON par équipement, et choisissez une seule approche pour tout le service.
• Donnez à chaque site un topic site/status retenu avec un Last Will, pour qu'une connexion cellulaire perdue apparaisse comme offline plutôt que comme des valeurs figées.
• N'encodez pas les numéros de registres des RTU dans les topics. Conservez-les dans un champ source si les ingénieurs en ont besoin.

Lorsque les noms de tags SCADA existants suivent déjà une convention, faites la correspondance avec la nouvelle hiérarchie dans la passerelle plutôt que de renommer les points dans le SCADA. Les exploitants conservent les noms qu'ils connaissent, et chaque nouveau consommateur obtient des topics propres et prévisibles. Documentez la correspondance une fois et révisez-la à chaque ajout de site, car les incohérences coûtent bien moins cher à corriger au deuxième site qu'au cinquantième.

Exemple : simulateur de station de pompage

Le script ci-dessous simule un surpresseur et le réservoir qu'il alimente : deux pompes, la pression de refoulement et le niveau du réservoir. Il publie par exception avec des heartbeats et un Last Will, ce qui en fait un bon substitut pendant que vous concevez tableaux de bord et alertes. Il utilise le serveur MQTT public gratuit, réservé aux tests, et n'envoie donc que des valeurs simulées sous un préfixe aléatoire.

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

BROKER, PORT = "broker.connectmq.com", 1883          # production : votre broker, port 8883 + TLS
CLIENT_ID = f"booster-sim-{uuid.uuid4().hex[:6]}"   # production : "YOUR_CLIENT_ID"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:6]}/north/booster-ridge"
HEARTBEAT = 300


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code, "- publishing under", BASE)
    client.publish(f"{BASE}/site/status", "online", qos=1, retain=True)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID)
client.will_set(f"{BASE}/site/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.connect(BROKER, PORT, keepalive=60)
client.loop_start()

level, pumps = 3.2, [False, False]
last = {}
last_full = 0.0


def publish(name, value, deadband=None, unit=None, retain=False):
    prev = last.get(name)
    if prev is not None and not force:
        if deadband is None and value == prev:
            return
        if deadband is not None and abs(value - prev) < deadband:
            return
    payload = {"value": value, "ts": int(time.time())}
    if unit:
        payload["unit"] = unit
    client.publish(f"{BASE}/{name}", json.dumps(payload), qos=1, retain=retain)
    last[name] = value


while True:
    force = time.time() - last_full >= HEARTBEAT
    demand = random.uniform(0.010, 0.020)
    supply = 0.018 * sum(pumps)
    level = round(max(0.0, level + supply - demand), 3)

    # Régulation de niveau simple : démarrer les pompes quand le réservoir baisse, arrêter quand il est plein
    if level < 2.8:
        pumps = [True, level < 2.4]
    elif level > 3.6:
        pumps = [False, False]

    pressure = round(1.2 + 2.1 * sum(pumps) + random.uniform(-0.03, 0.03), 2)

    publish("reservoir/level", level, deadband=0.03, unit="m")
    publish("discharge/pressure", pressure, deadband=0.08, unit="bar")
    publish("pump1/running", pumps[0], retain=True)
    publish("pump2/running", pumps[1], retain=True)

    if force:
        last_full = time.time()
    time.sleep(5)

Observez la station depuis un autre terminal :

mosquitto_sub -h broker.connectmq.com -p 1883 -i booster-watch-01 \
  -t 'connectmq/demo/+/north/booster-ridge/#' -v

Vous verrez le réservoir baisser lentement, les pompes démarrer, la pression de refoulement bondir et le niveau remonter, avec seulement quelques messages par minute malgré une boucle de cinq secondes.

Alertes à seuil sur les niveaux et les pressions

La télémétrie prouve sa valeur quand elle signale un problème suffisamment tôt. Sur un broker ConnectMQ privé, vous pouvez ajouter des règles d'alerte à seuil dans le portail, par exemple un niveau de réservoir inférieur à 1,5 m ou une pression de refoulement supérieure à 6 bar, et consulter chaque alerte déclenchée dans le journal des alertes. Les ingénieurs disposent ainsi d'une vue rapide et indépendante des limites critiques pendant un pilote ou en parallèle du SCADA.

Certaines conditions ne se résument pas à un seuil unique. Les cycles courts d'une pompe, par exemple, correspondent à un nombre de démarrages sur une durée. La bonne approche pour ce type de logique est un petit service abonné, connecté au broker comme un client MQTT ordinaire :

import json
import time
from collections import deque

import paho.mqtt.client as mqtt

MAX_STARTS_PER_HOUR = 6
starts = {}            # topic -> deque des horodatages de démarrage
state = {}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe("connectmq/demo/+/north/+/+/running", qos=1)


def on_message(client, userdata, msg):
    running = json.loads(msg.payload)["value"]
    was_running = state.get(msg.topic, running)
    state[msg.topic] = running
    if running and not was_running:
        window = starts.setdefault(msg.topic, deque())
        now = time.time()
        window.append(now)
        while window and now - window[0] > 3600:
            window.popleft()
        if len(window) > MAX_STARTS_PER_HOUR:
            print(f"ALERT short-cycling: {msg.topic} started {len(window)} times in 1 h")
            # Transmettre ici à votre outil d'astreinte, de SMS ou de ticketing.


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"shortcycle-{time.time_ns() % 1000000}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

La même approche fonctionne avec Node-RED ou tout autre outil compatible MQTT. L'envoi des notifications reste dans l'outil que votre équipe d'exploitation utilise déjà.

Checklist sécurité et fiabilité

Les services d'eau sont des infrastructures critiques : l'exigence est plus élevée que pour un projet IoT classique.

1. TLS sur le port 8883 pour chaque station ; n'envoyez jamais de télémétrie en clair sur des réseaux cellulaires ou publics.
2. Un nom d'utilisateur, un mot de passe et un client ID uniques par station, révocables individuellement.
3. Des connexions uniquement sortantes depuis les stations ; aucun port entrant ouvert sur les modems.
4. Une supervision séparée de la commande. Les commandes de pompes et de vannes restent dans le SCADA avec ses verrouillages, sauf si une conception validée en décide autrement.
5. Un statut de site retenu avec Last Will, et des alertes sur les passages inattendus à offline.
6. Une mise en tampon locale dans les stations, pour que les courtes coupures ne créent pas de trous dans les données réglementaires.
7. Une synchronisation horaire à la source pour des séquences d'événements exactes.
8. Une norme de topics documentée, portée par une seule équipe, appliquée à chaque nouveau site.

Choisir où faire tourner le broker

Les services d'eau à connectivité mixte, certains sites en radio privée et d'autres en cellulaire, ont intérêt à disposer d'un broker joignable de partout en TLS. Un broker MQTT managé retire les mises à jour et le renouvellement des certificats de la charge de travail du service. ConnectMQ fournit MQTT 3.1.1 et 5.0, une vue des équipements ISA-95 qui regroupe sites et équipements, et des options Dedicated ou BYOC pour les services qui ont besoin d'un cluster isolé ou d'un déploiement dans leur propre compte cloud. Pour les choix d'architecture entre automates de station, passerelles et relais SCADA, consultez connectivité des automates vers le cloud ; pour le comportement des modems cellulaires, MQTT sur réseau cellulaire. Le guide de l'IoT industriel avec MQTT relie l'ensemble de ces éléments.

Lancez un pilote de télémétrie de l'eau avec ConnectMQ

Choisissez un réservoir et une station de pompage, connectez-les à un broker MQTT cloud et définissez des alertes sur les niveaux et pressions les plus importants. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et visualisez dès aujourd'hui les données en direct de vos stations dans l'explorateur de topics.

Questions fréquentes

MQTT peut-il remplacer notre SCADA de gestion de l'eau ?

MQTT remplace généralement le transport de la télémétrie, pas les fonctions SCADA. Le SCADA s'abonne au broker pour l'exploitation, tandis que d'autres équipes consomment les mêmes données de manière indépendante.

Comment savoir qu'une station de pompage a perdu ses communications ?

Donnez à chaque station un Last Will sur un topic de statut retenu. Lorsque son keep alive expire, le broker publie offline, et les abonnés ou les règles d'alerte réagissent immédiatement.

Quelle bande morte utiliser pour les niveaux de réservoir ?

Quelques centimètres sont typiques, selon la précision de l'instrument et la vitesse de variation du niveau. Associez-la à un heartbeat périodique pour qu'un niveau stable prouve tout de même que la station est vivante.

MQTT est-il suffisamment sûr pour des infrastructures d'eau critiques ?

MQTT avec TLS, des identifiants par station, des connexions uniquement sortantes et la séparation entre supervision et commande constitue une base solide. Associez-le au programme global de cybersécurité de votre service.