SCADA MQTT : moderniser la télémétrie avec le report by exception

Les architectures SCADA MQTT remplacent le modèle classique où le maître interroge chaque RTU par des équipements qui remontent leurs données par exception à un broker central, et par des hôtes SCADA qui s'abonnent à ce dont ils ont besoin. Ce guide explique pourquoi ce changement économise de la bande passante et simplifie l'intégration, comment fonctionne la connaissance de l'état quand plus rien n'est interrogé, et comment migrer un système existant étape par étape. Vous construirez aussi un petit hôte Python qui détecte les RTU hors ligne ou dont les données sont figées, la compétence de base de tout SCADA fondé sur MQTT.

Fonctionnement de la télémétrie SCADA traditionnelle

Dans un système SCADA classique, la station maître mène la conversation. Elle interroge chaque RTU ou automate à tour de rôle en Modbus, DNP3 ou protocole propriétaire, en demandant les mêmes registres à chaque cycle, que quelque chose ait changé ou non. Ce modèle a de vrais atouts : le maître sait toujours si un équipement a répondu, et le timing est prévisible.

Il a aussi des coûts bien connus :

• De la bande passante consommée pour des données inchangées. Un niveau de cuve qui bouge deux fois par heure est quand même lu toutes les quelques secondes.
• Le temps de scrutation augmente avec le réseau. Sur des liaisons radio ou satellite, ajouter des RTU allonge le cycle d'interrogation pour tout le monde.
• Un couplage fort. Chaque nouveau consommateur, un historian, un outil d'analyse, une seconde salle de contrôle, interroge à nouveau les équipements ou dépend des interfaces du serveur SCADA.
• Des adresses d'équipements partout. Les tables de registres et les détails de protocole se diffusent dans chaque système qui a besoin des données.

Ce qui change avec le SCADA MQTT

Avec MQTT, la RTU ou la passerelle edge ouvre une connexion sortante vers un broker et publie les valeurs lorsqu'elles changent de façon significative. Hôtes SCADA, historians et tableaux de bord sont des abonnés. Le broker se trouve au milieu et redistribue les messages.

Le plus grand changement conceptuel est le report by exception (RBE). Au lieu d'être interrogé, le terrain rend compte. Une bande morte sur chaque valeur analogique et la publication immédiate de chaque changement d'état numérique maintiennent les données à jour avec une fraction du trafic. Le guide du report by exception détaille le dimensionnement des bandes mortes.

Le broker, pivot du SCADA

Dans une architecture SCADA MQTT, le broker devient le système nerveux central. Les équipements de terrain ne savent pas combien d'hôtes consomment leurs données et ne s'en soucient pas, et les hôtes n'ont pas besoin de connaître les adresses des équipements. Ce découplage permet des schémas difficiles à mettre en œuvre avec l'interrogation :

• Des hôtes SCADA redondants s'abonnent aux mêmes topics sans doubler le trafic terrain.
• Des consommateurs IT comme les historians, les outils d'analyse ou un jumeau numérique de l'installation s'abonnent en parallèle sans toucher au système de contrôle.
• Des migrations progressives peuvent faire tourner l'ancien et le nouveau SCADA côte à côte sur les mêmes données en direct.

Comprendre ce que fait un broker MQTT est ici fondamental : il route les messages, conserve les valeurs retenues et l'état des sessions, et contrôle qui peut se connecter.

Connaître l'état sans interrogation

L'objection la plus fréquente au SCADA MQTT est : « Si j'arrête d'interroger, comment savoir qu'une RTU est vivante ? » MQTT y répond à deux niveaux.

Keep alive et Last Will. Chaque client déclare un intervalle de keep alive. Si le broker n'entend rien pendant 1,5 fois cet intervalle, il ferme la session et publie le message Last Will du client, par exemple un offline retenu sur le topic de statut de la RTU. Lorsque la RTU se reconnecte, elle publie un online retenu. Chaque abonné, y compris ceux qui démarrent plus tard, voit l'état courant.

Sparkplug B. La spécification Sparkplug formalise ce mécanisme pour le SCADA : les edge nodes publient à la connexion des messages NBIRTH et DBIRTH contenant toutes les métriques, un NDEATH comme Last Will, et un primary host publie son propre STATE pour que les edge nodes sachent si un hôte SCADA est à l'écoute. Les hôtes peuvent demander une renaissance (rebirth) lorsqu'ils détectent une lacune. Ignition et de nombreuses passerelles edge l'implémentent nativement ; consultez applications Sparkplug primary host pour le côté hôte.

Même avec de simples topics JSON, vous devez aussi détecter les données figées : un équipement connecté dont les valeurs ont cessé de se mettre à jour, par exemple parce que ses E/S terrain sont défaillantes.

Exemple : un hôte SCADA MQTT minimal en Python

Cet hôte s'abonne au statut et à la télémétrie des RTU, suit l'état en ligne à partir des messages Last Will retenus et signale toute RTU dont les données n'ont pas changé ni été rafraîchies dans le délai de heartbeat attendu. Exécutez-le sur le serveur MQTT public gratuit avec un simulateur, puis pointez-le vers votre propre broker.

import json
import time
import uuid
import threading

import paho.mqtt.client as mqtt

BROKER, PORT = "broker.connectmq.com", 1883
PREFIX = "connectmq/demo/scada-7h2k"          # préfixe aléatoire : les données publiques sont lisibles par tous
STALE_AFTER = 120                             # secondes ; le heartbeat est de 60 s

rtus = {}   # rtu_id -> {"online": bool, "last_seen": float, "values": dict}
lock = threading.Lock()


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(f"{PREFIX}/+/status", qos=1)
    client.subscribe(f"{PREFIX}/+/telemetry/#", qos=1)


def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    rtu_id = parts[3]
    with lock:
        rtu = rtus.setdefault(rtu_id, {"online": False, "last_seen": 0.0, "values": {}})
        if parts[4] == "status":
            rtu["online"] = msg.payload.decode() == "online"
            print(f"[STATE] {rtu_id} is {'ONLINE' if rtu['online'] else 'OFFLINE'}")
        else:
            point = "/".join(parts[5:])
            rtu["values"][point] = json.loads(msg.payload)
            rtu["last_seen"] = time.time()


def watchdog():
    while True:
        time.sleep(10)
        now = time.time()
        with lock:
            for rtu_id, rtu in rtus.items():
                if rtu["online"] and now - rtu["last_seen"] > STALE_AFTER:
                    print(f"[STALE] {rtu_id}: no data for {int(now - rtu['last_seen'])} s")


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"scada-host-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=30)
threading.Thread(target=watchdog, daemon=True).start()
client.loop_forever()

Simulez une RTU dans un autre terminal en publiant un statut retenu et une valeur de télémétrie :

mosquitto_pub -h broker.connectmq.com -p 1883 -i rtu-sim-7h2k \
  -t 'connectmq/demo/scada-7h2k/rtu07/status' -m online -r -q 1
mosquitto_pub -h broker.connectmq.com -p 1883 -i rtu-sim2-7h2k \
  -t 'connectmq/demo/scada-7h2k/rtu07/telemetry/tank1/level' -m '{"value":3.42,"unit":"m"}' -q 1

Pour un simulateur de longue durée avec un vrai Last Will, utilisez mosquitto_sub ou un script avec --will-topic connectmq/demo/scada-7h2k/rtu07/status --will-payload offline --will-retain, puis arrêtez-le brutalement pour voir l'hôte réagir. N'utilisez le serveur MQTT public gratuit que pour des valeurs simulées comme celles-ci.

Migrer un système SCADA existant

Un remplacement en une seule fois est rarement nécessaire. Une démarche progressive préserve la sécurité de l'exploitation :

1. Commencez par un miroir. Ajoutez un publieur MQTT à côté du maître existant, soit un module SCADA qui transmet les tags, soit une passerelle edge qui lit les mêmes RTU en mode écoute seule. Rien ne change côté contrôle.
2. Définissez l'espace de noms. Convenez de la structure des topics (chemins ISA-95 ou group et node IDs Sparkplug) et du format de payload avant que les sources ne se multiplient.
3. Connectez les consommateurs en lecture seule. Historians, tableaux de bord et outils d'analyse passent sur le broker. Validez les valeurs par rapport aux écrans SCADA.
4. Convertissez les sites au RBE. Remplacez l'interrogation site par site, ou type de liaison par type de liaison, par des RTU ou passerelles edge compatibles RBE. Comparez la bande passante et la fraîcheur des données.
5. Migrez la commande avec prudence. Les commandes via MQTT nécessitent des mécanismes de confirmation, des timeouts et des verrouillages. Les messages de commande Sparkplug ou le request/response de MQTT 5 avec response topics aident à les structurer.
6. Retirez l'interrogation historique uniquement lorsque tous les consommateurs ont migré et que le comportement des alarmes a été vérifié.

Pièges de conception

• Pas de heartbeat. Un RBE pur sans rafraîchissement périodique rend une valeur figée impossible à distinguer d'une valeur stable.
• Horodatage par l'horloge de l'équipement sans synchronisation. L'analyse de séquence d'événements est faussée si les horloges des RTU dérivent. Utilisez NTP ou l'heure GPS à la source.
• QoS 2 partout. Elle ajoute des allers-retours sur les liaisons lentes. La QoS 1 avec des consommateurs idempotents est le choix habituel pour la télémétrie.
• Tout retenir. Retenez les statuts et les dernières valeurs, pas les flux à haute fréquence.
• Topics plats. rtu07/ai3 ne passera pas à l'échelle ; nommez par site et par équipement.

La place de ConnectMQ

Un broker servant de pivot SCADA a besoin de TLS, d'identifiants par équipement et d'une protection contre les clients défaillants. ConnectMQ fournit MQTT 3.1.1 et 5.0 avec TLS, lie chaque client ID aux identifiants fournis, et applique une protection contre les inondations de messages ainsi que le blocage d'IP après des échecs de connexion répétés. Le portail décode les payloads Sparkplug B, peut republier les données Sparkplug dans des topics ISA-95 lisibles, et propose des règles d'alerte à seuil avec un journal des alertes, pratique pour une vue d'exploitation rapide aux côtés de votre hôte SCADA. Logiciels SCADA, historians et scripts se connectent comme des clients MQTT ordinaires. Si vous préférez ne pas exploiter d'infrastructure de broker dans chaque centre de contrôle, un broker MQTT managé mérite d'être évalué ; pour les détails de mise en œuvre avec un logiciel SCADA précis, consultez Ignition avec MQTT, et pour le contexte général, le guide de l'IoT industriel avec MQTT.

Modernisez votre télémétrie SCADA avec ConnectMQ

Commencez par un site ou un type de RTU. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, connectez une passerelle et votre hôte SCADA, et comparez les données côte à côte avec votre interrogation existante.

Questions fréquentes

MQTT peut-il remplacer DNP3 ou Modbus dans un SCADA ?

MQTT remplace souvent le transport entre les sites terrain et le centre de contrôle, tandis que Modbus ou DNP3 peuvent rester utilisés localement entre une passerelle edge et les équipements de terrain.

Comment un hôte SCADA MQTT sait-il qu'un équipement est hors ligne ?

Grâce au message Last Will de l'équipement, publié par le broker à l'expiration du keep alive, ou grâce aux messages NDEATH de Sparkplug. Ajoutez une détection des données figées pour les équipements qui restent connectés mais cessent de se mettre à jour.

Sparkplug B est-il obligatoire pour un SCADA MQTT ?

Non, mais il normalise les messages de naissance et de mort, la définition des métriques et l'état des hôtes, ce qui facilite grandement l'interopérabilité entre hôtes SCADA et équipements edge.

Quelle QoS utiliser pour la télémétrie SCADA ?

La QoS 1 est le choix courant, combinée à des topics de statut retenus. La QoS 0 convient aux données à haute fréquence pour lesquelles l'échantillon suivant remplace un échantillon perdu.