Dossier IoT

Modbus RTU vers MQTT — conversion et bridge industriel

Convertir Modbus RTU en MQTT JSON : QoS 0/1/2, TLS, AWS IoT Core, Azure IoT Hub, Mosquitto, Sparkplug B. Architecture, configuration et sécurité. Guide Eziwan.

En bref
Un bridge Modbus RTU → MQTT interroge vos équipements RS485/RS232 via polling Modbus, encapsule chaque mesure dans un message JSON MQTT avec timestamp, QoS configurable et chiffrement TLS 1.3, puis publie vers le broker MQTT de votre choix (AWS IoT Core, Azure, HiveMQ, Mosquitto ou Eziwan). La conversion est entièrement configurable sans code.

Pourquoi convertir Modbus RTU en MQTT ?​

Modbus RTU est le langage de la machine. MQTT est le langage du cloud. Le bridge Modbus RTU → MQTT est la traduction entre ces deux mondes : il permet à vos équipements industriels legacy de communiquer avec les plateformes IoT modernes sans aucune modification de l’installation existante.

Avantages de MQTT pour le transport de données industrielles :

  • Légèreté : 2 octets d’en-tête minimum, idéal pour la 4G et les connexions coûteuses
  • Publish/subscribe : découplement entre la production (passerelle) et la consommation (dashboard, API)
  • Session persistante : les messages sont mis en file pendant les coupures réseau
  • QoS configurable : garantie de délivrance adaptée à chaque type de donnée
  • TLS natif : chiffrement et authentification sans surcouche applicative

Architecture du bridge Modbus RTU → MQTT​

Le bridge fonctionne en deux phases distinctes et indépendantes :

Phase 1 — Collecte Modbus RTU (côté terrain) La passerelle est le maître Modbus. Elle envoie des requêtes de lecture (FC01/02/03/04) aux esclaves RS485 selon un planning de polling configurable. Chaque réponse est décodée, mise à l’échelle et horodatée localement.

Phase 2 — Publication MQTT (côté cloud) Les valeurs décodées sont encapsulées dans des messages JSON et publiées sur le broker MQTT. Si la connexion est indisponible, les messages sont bufferisés localement (72 h) et retransmis à la reconnexion avec leur timestamp d’origine.

RS485 Bus                 Passerelle Eziwan              MQTT Broker
──────────               ──────────────────              ────────────
Esclave 1 ──┐            ┌── Modbus RTU master           AWS IoT Core
Esclave 2 ──┤── RS485 ──►│   Polling FC03/FC04    MQTT  Azure IoT Hub
Esclave 3 ──┤            │   Decode + Scale      ──TLS►  HiveMQ
Esclave n ──┘            └── JSON builder                Mosquitto
                              Buffer 72h                  Eziwan Cloud

Structure des topics MQTT pour Modbus RTU​

L’organisation des topics MQTT est cruciale pour la maintenabilité et l’intégration :

Convention recommandée :

{site}/{zone}/{equipement}/{tag}

Exemples :

usine/atelier_a/variateur_01/frequence_hz
usine/atelier_a/variateur_01/courant_a
usine/tgbt/compteur_principale/puissance_active_kw
usine/tgbt/compteur_principale/energie_kwh

Topics de métadonnées (Sparkplug B) :

spBv1.0/usine/NBIRTH/passerelle_01      ← Annonce de connexion
spBv1.0/usine/NDATA/passerelle_01       ← Données process
spBv1.0/usine/NDEATH/passerelle_01      ← Déconnexion (LWT)

Brokers MQTT compatibles​

La passerelle Eziwan est compatible avec les principaux brokers MQTT du marché :

BrokerHébergementProtocoleCas d’usage
AWS IoT CoreCloud AWSMQTT TLSIntégration AWS (Lambda, S3, Timestream)
Azure IoT HubCloud AzureMQTT / AMQPIntégration Azure (Stream Analytics, Cosmos DB)
HiveMQ CloudCloud géréMQTT 5.0 + TLSSparkplug B, UNS, multi-broker
MosquittoAuto-hébergéMQTT 3.1.1SCADA local, latence minimale
Eziwan CloudCloud géréMQTT TLSClé en main, dashboard intégré

Gestion de la déconnexion et buffering​

Les réseaux industriels (4G, Wi-Fi en milieu difficile) sont sujets aux coupures. Le bridge Modbus RTU → MQTT gère cela par :

  • Last Will Testament (LWT) : message automatique publié par le broker quand la passerelle se déconnecte
  • Session persistante : le broker conserve les souscriptions et les messages QoS 1/2 en attente
  • Buffer local : la passerelle stocke les mesures en mémoire flash pendant la coupure
  • Resynchronisation : à la reconnexion, les messages sont retransmis dans l’ordre chronologique

Ce mécanisme garantit aucune perte de données même lors de coupures réseau prolongées — critique pour les applications de comptage d’énergie ou de suivi de production.

Intégration avec les TSDB cloud​

Les données MQTT sont généralement stockées dans une base de données de séries temporelles (Time Series Database) :

  • InfluxDB : open-source, excellent pour les métriques industrielles
  • AWS Timestream : serverless, intégré à AWS IoT Core
  • Azure Data Explorer : haute performance pour les grands volumes
  • TimescaleDB : PostgreSQL étendu, SQL natif
  • Eziwan Storage : stockage inclus, rétention configurable

Depuis la TSDB, les données alimentent les dashboards Grafana, les rapports de performance et les modèles de maintenance prédictive.

Questions fréquentes

À consulter aussi