Documentation
Modbus RTU à distance : lire une liaison série RS-485 par Internet
Le Modbus RTU à distance est le cas d’école de la supervision multi-sites : les compteurs, capteurs et automates parlent Modbus RTU sur un bus série RS-485, et le logiciel qui doit les interroger est à des centaines de kilomètres. Deux chemins existent — et il faut les présenter honnêtement. Soit on déporte la liaison série elle-même avec Virtual-IO, la fonction de port série à distance de VIGIL-MESH : la supervision ouvre un port COM virtuel comme si le bus était local. Soit le site dispose déjà d’une passerelle Modbus TCP : on transporte alors le Modbus TCP par le mesh, chiffré, sans ouvrir de port.
Le besoin : interroger un bus RS-485 qui est sur un autre site
Modbus RTU est né sur la liaison série : un maître unique interroge des esclaves adressés de 1 à 247, le plus souvent sur une paire RS-485. Le protocole est partout — compteurs d’énergie, centrales de mesure, variateurs, régulateurs, automates — mais il ne connaît que son bus. Dès que la supervision, l’outil de configuration ou l’historisation sont ailleurs, la question se pose : comment atteindre le bus sans tirer une ligne, sans exposer le site sur Internet et sans multiplier les boîtiers ?
La supervision centralisée
Un exploitant suit plusieurs sites — locaux techniques, stations, bâtiments. Les compteurs et régulateurs de chaque site parlent Modbus RTU, la supervision est au siège.
L’outil constructeur
Le logiciel de paramétrage du variateur ou du régulateur ne connaît qu’un port COM et le protocole RTU. Aucune option réseau, et l’équipement est loin.
Le diagnostic ponctuel
Une valeur douteuse, un esclave qui ne répond plus : il faut lire quelques registres et observer le trafic du bus — sans envoyer quelqu’un sur place.
Deux chemins honnêtes, selon ce que le site possède déjà
Il n’y a pas de chemin unique « meilleur partout ». Le bon choix dépend d’une seule question : le site a-t-il déjà une passerelle Modbus TCP devant son bus RS-485 ?
Une machine du site (PC industriel, box Linux) est reliée au bus par un adaptateur USB–RS-485 et devient provider : elle partage son chemin de périphérique. La machine de supervision, elle, monte un port virtuel local — un vrai port COM sous Windows, un pty /dev/ttyVIGIL-<nom> sous Linux — et votre maître Modbus RTU l’ouvre comme si le bus était branché sur le poste. Le fonctionnement détaillé est décrit dans Port série à distance.
- Rien ne change côté esclaves : le bus, les adresses, les registres et l’outil maître restent identiques — seul le port COM que l’outil ouvre est virtuel.
- Un seul écrivain à la fois : l’écriture est exclusive, ce qui colle au modèle Modbus du maître unique. Jusqu’à 8 machines peuvent observer le trafic en lecture.
- Chiffré de bout en bout dans la session mesh, accès accordé machine par machine, rien d’exposé sur Internet.
Si l’équipement parle déjà Modbus TCP, ou si le site a déjà une passerelle Modbus RTU/TCP devant son bus, inutile de déporter la liaison série : le mesh transporte le Modbus TCP comme n’importe quel flux IP. Une machine du site rejoint le réseau privé par une seule connexion sortante ; la supervision joint cette machine par son adresse overlay, et c’est elle qui relaie le flux Modbus TCP autorisé vers la passerelle. Les ACL limitent l’accès au strict nécessaire.
- Le protocole reste natif : pas de conversion supplémentaire, la supervision parle Modbus TCP à la passerelle comme en local.
- Pas de port ouvert : le port 502 n’est jamais exposé sur Internet, l’accès passe par le réseau privé et ses ACL.
- Déjà documenté : ce chemin — passerelle de site, moindre privilège, limites — est traité en détail dans Accès distant Modbus et SCADA. Cette page ne le duplique pas.
| Situation du site | Chemin conseillé |
|---|---|
| Bus RS-485 nu, pas de passerelle — et un outil qui ne parle que COM/RTU | Chemin A : Virtual-IO, port COM virtuel côté supervision |
| Passerelle Modbus RTU/TCP déjà en place, ou équipements Modbus TCP | Chemin B : Modbus TCP transporté par le mesh |
| Besoin d’observer le trafic RTU brut à plusieurs (diagnostic) | Chemin A : fan-out en lecture seule vers plusieurs machines |
Cas concret : la supervision au siège, le bus à trois heures de route
Un local technique héberge une dizaine de compteurs d’énergie sur un bus RS-485, interrogés en Modbus RTU. L’historisation et les bilans tournent au siège, à trois heures de route. Le site n’a ni passerelle Modbus TCP, ni IP fixe, ni personnel informatique — et la politique maison interdit, à raison, d’ouvrir un port sur la box du site.
Jusqu’ici, les relevés se faisaient sur place, un portable branché au bus : un déplacement par campagne de mesure, et aucune visibilité entre deux passages.
- 1Posez une machine provider sur le siteUne box Linux ou un PC industriel, reliés au bus par un adaptateur USB–RS-485 à auto-direction, sont enrôlés dans le réseau. La machine n’établit que des connexions sortantes.
- 2Créez le partage dans l’onglet Virtual-IOConsole web → le réseau → onglet Virtual-IO : nom du partage, machine provider, chemin du périphérique (
/dev/ttyUSB0…), puis vitesse et parité conformes au bus (par exemple 9 600 8N1 ou 19 200 8E1 — reprenez la configuration existante des compteurs). - 3Donnez lecture-écriture à la machine de supervisionElle seule pourra émettre les requêtes (un seul écrivain — cohérent avec le maître unique Modbus). Les autres machines restent à « aucun », ou « lecture » pour du diagnostic passif. Enregistrez.
- 4Pointez le maître Modbus vers le port virtuelSous Windows, le driver crée un vrai port COM ; sous Linux, le partage apparaît en
/dev/ttyVIGIL-<nom>. Configurez votre logiciel de supervision exactement comme sur site : même vitesse, mêmes adresses esclaves, mêmes registres. - 5Élargissez le timeout de réponse, puis validezAjoutez la latence aller-retour du lien Internet au temps de réponse habituel des esclaves, avec de la marge, et vérifiez le comportement sur quelques cycles complets d’interrogation avant la mise en production.
Timing Modbus RTU : ce qu’un lien Internet change
Modbus RTU délimite ses trames par des silences sur le bus (les fameux temps inter-caractères). Cette mécanique reste locale : c’est le port série de la machine provider qui parle au bus, à la vitesse du bus. Ce qui traverse Internet, c’est l’aller-retour requête-réponse entre votre maître et le provider — et cette latence-là s’ajoute à chaque transaction.
Limites et statut bêta
L’accès est accordé machine par machine — il n’y a pas d’exposition d’un sous-réseau entier. Les formules sont détaillées sur la page tarifs.