Modbus TCP : le protocole Ethernet de l’industrie
Modbus TCP/IP est la variante Ethernet du protocole Modbus, standardisée en 1999. Il conserve le modèle maître/esclave et la structure des registres (Holding, Input, Coil, Discrete Input) de Modbus RTU, mais les transporte sur TCP/IP port 502. Résultat : Modbus TCP s’intègre naturellement dans les réseaux IT d’entreprise tout en restant compatible avec l’écosystème Modbus existant.
Ses avantages par rapport à Modbus RTU :
- Vitesse : 100 Mbit/s vs 115 kbps max en RS485
- Topologie libre : pas de limitation à 32 nœuds sur un bus linéaire
- Multi-maître : plusieurs clients peuvent interroger un même esclave
- Distance : Ethernet standard jusqu’à 100 m, fibre pour les grandes distances
Architecture de connexion Modbus TCP → cloud
La passerelle joue le rôle de client Modbus TCP (maître) vis-à-vis des équipements locaux, et de client MQTT vis-à-vis du cloud. Elle s’intercale entre le réseau OT et le réseau cloud.
| Couche | Équipement / Protocole |
|---|---|
| Terrain (équipements) | Automates, variateurs, compteurs avec port Ethernet |
| Réseau LAN industriel | Switch Ethernet, VLAN OT |
| Passerelle | Eziwan Gateway (client Modbus TCP + client MQTT) |
| Transport cloud | MQTT over TLS 1.3 / 4G LTE ou Ethernet WAN |
| Cloud | AWS IoT Core, Azure IoT Hub, Eziwan Cloud |
| Application | Dashboard, alertes, API REST, reporting |
Lecture des registres Modbus TCP : types de données supportés
La passerelle interroge tous les types de registres Modbus TCP définis par la norme :
Registres 16 bits :
- Holding Registers (FC03) — lecture/écriture, valeurs process (consignes, paramètres)
- Input Registers (FC04) — lecture seule, mesures temps réel (courant, tension, débit)
Bits discrets :
- Coils (FC01/FC05) — lecture/écriture, sorties logiques (relais, commandes)
- Discrete Inputs (FC02) — lecture seule, entrées logiques (états, défauts)
Types de données encodés :
- INT16, UINT16 (1 registre)
- INT32, UINT32, FLOAT32 IEEE 754 (2 registres, Big Endian ou Little Endian)
- INT64, DOUBLE (4 registres)
- STRING ASCII
Envoi MQTT vers AWS IoT, Azure IoT Hub ou Eziwan
Une fois les registres lus, la passerelle publie les mesures sur le broker MQTT cible. Les trois plateformes majeures sont supportées :
AWS IoT Core
- Connexion via MQTT over TLS port 8883
- Authentification par certificat x509 AWS
- Règles IoT vers DynamoDB, S3, Lambda ou QuickSight
Azure IoT Hub
- Connexion via AMQP ou MQTT TLS
- Device Twin pour la configuration à distance
- Stream Analytics pour le traitement temps réel
Eziwan Cloud
- Configuration zero-touch, pas d’infra à gérer
- Dashboard préconfigué avec unités industrielles
- Alertes SMS/email en moins de 30 secondes
Polling et optimisation de la fréquence d’acquisition
Le choix de la fréquence de polling impacte à la fois la fraîcheur des données et la consommation de données mobiles.
| Type de mesure | Fréquence recommandée |
|---|---|
| Grandeurs électriques (P, Q, I, U) | 1 à 10 s |
| Températures process | 30 s à 5 min |
| Niveaux, débits | 1 à 5 min |
| États discrets (alarmes) | 1 à 5 s |
| Compteurs (énergie, volume) | 5 à 15 min |
La passerelle peut également être configurée en mode on-change : une valeur n’est transmise que si elle varie d’une quantité configurable (deadband), ce qui réduit significativement le volume de données.
Supervision multi-sites : l’architecture centralisée
Pour un parc de plusieurs sites industriels, la même architecture se réplique :
- Une passerelle par site, chacune polle ses équipements Modbus TCP locaux
- Toutes les passerelles publient vers le même broker MQTT cloud (ou des topics distincts par site)
- Une seule interface de supervision centralise tous les sites
- Les alertes sont configurées globalement avec escalade par site
Cette architecture centralisée avec des passerelles locales est le standard de la télésurveillance industrielle multi-sites.