Pourquoi connecter Modbus RTU au cloud ?
Modbus RTU reste le protocole de terrain le plus répandu dans l’industrie mondiale, présent sur des dizaines de millions d’équipements : variateurs de fréquence, automates programmables, compteurs d’énergie, analyseurs de réseau, capteurs de température et de pression, onduleurs photovoltaïques. Pourtant, ce protocole série des années 1970 n’a pas été conçu pour Internet.
Connecter ces équipements au cloud apporte des bénéfices immédiats :
- Supervision à distance 24/7 sans déplacement sur site
- Alertes en temps réel sur dépassement de seuil ou anomalie
- Historique et tendances pour la maintenance préventive
- Reporting automatisé pour la conformité et les audits énergétiques
- Intégration ERP/GMAO via API REST ou webhooks
Architecture d’une passerelle Modbus RTU vers cloud
La passerelle se connecte physiquement au bus RS485 en tant que maître Modbus. Elle interroge cycliquement les esclaves selon une configuration paramétrable (liste de registres, adresses, fréquence de polling), convertit les valeurs en messages JSON/MQTT et les transmet vers le cloud.
Équipements RS485 Passerelle Eziwan Cloud
──────────────── ───────────────── ──────────────
Variateur ──┐ ┌─ Modbus RTU maître MQTT broker
Compteur ──┤── RS485 ──┤ Polling registres → Dashboard
Automate ──┘ └─ 4G / Ethernet Alertes / API
Points clés de l’architecture :
| Paramètre | Valeur typique |
|---|---|
| Interface physique | RS485 2 fils (A/B) ou RS232 |
| Baudrate | 9 600 / 19 200 / 38 400 bps |
| Parité | None 8N1 ou Even 8E1 |
| Connexion cloud | MQTT TLS sur 4G LTE |
| Intervalle de polling | 1 s à 15 min (configurable) |
| Tampon local | 72 h de données |
Configuration des registres Modbus à lire
La passerelle permet de configurer précisément quels registres lire sur quels esclaves. Chaque point de mesure est défini par :
- Adresse esclave (1 à 247)
- Type de registre : Holding (FC03), Input (FC04), Coil (FC01), Discrete Input (FC02)
- Adresse de registre (0 à 65535)
- Type de données : INT16, UINT16, INT32, FLOAT32, BOOLEAN
- Facteur d’échelle et offset pour convertir en unité physique
- Étiquette / tag pour le dashboard (ex. "puissance_active_kW")
Cette configuration se fait depuis l’interface cloud Eziwan, sans accès physique à l’installation — idéal pour les sites distants ou difficiles d’accès.
Transmission MQTT : QoS, TLS et rétention
Une fois les registres lus, la passerelle publie les valeurs sur un broker MQTT (Eziwan Cloud, AWS IoT Core, Azure IoT Hub ou Mosquitto auto-hébergé). Les bonnes pratiques :
- QoS 1 (at-least-once) pour garantir la délivrance malgré les coupures réseau
- TLS 1.3 obligatoire pour chiffrer le transport
- Authentification par certificat client x509 pour l’identité de la passerelle
- Topic hiérarchique :
site/zone/equipement/tagpour faciliter le filtrage - Payload JSON avec timestamp ISO 8601, valeur et unité
Cas d’usage industriels typiques
Les applications de la connexion Modbus RTU → cloud couvrent de nombreux secteurs :
Énergie et utilities
- Télérelève de compteurs électriques (Eastron SDM, SOCOMEC, Carlo Gavazzi)
- Supervision de générateurs et onduleurs
- Monitoring de tableaux TGBT
Production industrielle
- Surveillance de variateurs de fréquence (Schneider ATV, Danfoss, ABB)
- Contrôle de compresseurs et pompes
- Suivi de fours et étuves industriels
Eau et assainissement
- Télésurveillance de stations de pompage
- Mesure débit, pression, niveau
- Détection de défaut à distance
Sécurité OT/IT : l’approche zero-trust
La connexion de réseaux OT (Operational Technology) à Internet introduit des risques de cybersécurité. L’approche Eziwan applique les principes zero-trust :
- Connexion sortante uniquement — la passerelle initie le tunnel, aucun port n’est ouvert en entrée
- Segmentation réseau — le réseau OT (RS485) reste isolé du réseau IT
- Certificats par équipement — chaque passerelle a une identité cryptographique unique
- Mises à jour OTA signées — impossible d’installer un firmware non authentifié
- Journalisation — toutes les connexions et anomalies sont tracées