Cookie
Electronic Team, Inc. uses cookies to personalize your experience on our website. By continuing to use this site, you agree to our cookie policy. Click here to learn more.

Accédez à un appareil Modbus RTU via un réseau — sans passerelle matérielle

Editorial Team Editorial Team
Mis à jour : Jul 16, 2026

Votre API, compteur d’énergie ou contrôleur de débit communique en Modbus RTU via un câble série. Votre SCADA, IHM ou enregistreur de données fonctionne sur une machine située à l’autre bout du bâtiment — ou à l’autre bout du pays. Ce guide montre comment combler cet écart avec un port COM virtuel, afin que votre logiciel existant ne voie jamais la différence.

Accéder à un appareil Modbus RTU via un réseau

Le problème : série d’un côté, réseau de l’autre

Modbus RTU reste le protocole dominant dans les usines, les postes électriques et les sites distants sur le terrain. Il est rapide, déterministe et pris en charge par pratiquement tous les appareils industriels fabriqués au cours des 40 dernières années. Le problème, c’est qu’il a été conçu pour un câble court, pas pour un réseau.

Le scénario typique ressemble à ceci : un maître Modbus — une plateforme SCADA telle que Kepware, Ignition ou une application personnalisée — doit interroger des registres sur un appareil distant. L’appareil dispose d’un port RS-232 ou RS-485. Le logiciel maître s’attend à un port COM local. Il y a un LAN d’entreprise — ou un WAN — entre les deux.
Point clé

Si vous avez déjà un PC ou un appareil Linux embarqué sur le site distant — un serveur, une passerelle edge, un Raspberry Pi — vous n’avez pas besoin d’un serveur de périphériques matériel. Un port COM virtuel logiciel peut faire le même travail, en utilisant le matériel que vous possédez déjà.
La réponse conventionnelle est un serveur de périphériques série matériel — un Moxa NPort, un Lantronix UDS ou un Digi PortServer. Ce sont des boîtiers dédiés qui se placent à côté du périphérique de terrain, se connectent à votre réseau et présentent le port série comme un socket TCP. Ils fonctionnent bien, mais ils coûtent $150–$500 par port, nécessitent une installation physique et ajoutent du matériel à maintenir sur chaque site distant.

Modbus RTU vs. Modbus TCP — et pourquoi la différence est importante

Avant d’aller plus loin, il est utile de comprendre ce que sont réellement ces deux variantes — car elles ne sont pas interchangeables, et cette distinction détermine le choix de l’approche.
Propriété
Modbus RTU
Modbus TCP
Transport
Câble série (RS-232, RS-485, RS-422)
Réseau Ethernet / TCP/IP
Format du cadre
Binaire, somme de contrôle CRC-16
Binaire avec en-tête MBAP, sans CRC
Port par défaut
Port COM physique (par ex. COM3)
Port TCP 502
Prise en charge multi-maître
Non — un seul maître par bus
Oui — plusieurs maîtres peuvent se connecter
Configuration requise de l’appareil
Tout appareil avec port RS-232/485
L’appareil doit prendre en charge Ethernet
Conversion de protocole
—
Oui, si l’appareil est uniquement RTU
Une passerelle Modbus TCP traduit entre ces deux variantes au niveau du protocole — elle parle RTU à l’appareil série et TCP au client réseau. Elle comprend les trames Modbus, supprime ou ajoute l’en-tête MBAP et convertit le CRC.

Un redirecteur de port COM virtuel comme Serial to Ethernet Connector fait quelque chose de différent : il transporte de manière transparente le flux brut d’octets série sur TCP. Le logiciel maître envoie toujours des trames Modbus RTU à un port COM — il se trouve simplement que le port COM est virtuel et que les octets traversent le réseau avant d’atteindre l’appareil série physique. Aucune conversion de protocole n’a lieu. L’appareil voit des trames RTU identiques ; le logiciel voit un port COM identique.
Remarque

Si votre logiciel maître parle déjà Modbus RTU et cible un port COM, l’approche par port COM virtuel ne nécessite aucune modification du logiciel. Si votre logiciel ne prend en charge que Modbus TCP (port 502), vous avez besoin d’une passerelle — ou que le logiciel lui-même gère la conversion. La plupart des plateformes SCADA modernes (Kepware, Ignition, Inductive Automation) prennent en charge les deux et vous permettent de choisir par canal.

Comment fonctionne le tunnel de port COM virtuel

Le Serial to Ethernet Connector s’exécute comme un service en arrière-plan sur deux machines simultanément : le côté serveur (où se trouve le port série physique) et le côté client (où s’exécute le logiciel maître Modbus). Ensemble, ils créent une paire correspondante de ports virtuels connectés par une session TCP persistante.

[Modbus Master (Kepware / Ignition)] → [Virtual COM5 — SEC client] ⟷ TCP / LAN / WAN ⟷ [SEC server] → [Physical COM1 RS-485] → [PLC / Meter / RTU]

Du point de vue de l’application, COM5 se comporte exactement comme un véritable port série. Le débit en bauds, la parité, les bits d’arrêt et les signaux RTS/CTS sont tous retransmis. L’application configure 9600 8N1 sur COM5 et obtient exactement ce comportement sur le COM1 distant — même s’il y a une connexion TCP entre les deux.

Cela signifie qu’aucune modification des configurations logicielles existantes n’est nécessaire. Si votre projet SCADA communiquait déjà avec un automate local sur COM3, il vous suffit de le rediriger vers le nouveau port virtuel et cela fonctionne. Le pilote Modbus ne sait pas — et ne se soucie pas — que le port est virtuel.
Modbus RTU sur un réseau
Période d'essai de 14 jours gratuits
Essayer gratuitement

Un-à-plusieurs et plusieurs-à-plusieurs : connecter plusieurs appareils à la fois

Un simple tunnel point à point est utile, mais Serial to Ethernet Connector va plus loin : il prend en charge les topologies de connexion un-à-plusieurs et plusieurs-à-plusieurs, ce qui correspond directement à la façon dont les véritables réseaux Modbus sont construits.
Un maître, de nombreux appareils esclaves

Un maître, de nombreux appareils esclaves

Dans le scénario industriel le plus courant, un seul maître Modbus (votre SCADA distant, IHM ou application d’acquisition de données) doit interroger de nombreux appareils de terrain — compteurs, automates programmables, RTU, variateurs — répartis sur un site ou sur plusieurs sites distants. Avec Serial to Ethernet Connector, vous configurez une connexion Server par port série distant et un port COM virtuel Client correspondant par appareil sur le PC maître. L’application maître voit un ensemble de ports COM virtuels, un par appareil, et interroge chacun comme s’il s’agissait d’une connexion série locale.

[Modbus Master SCADA] → COM5 ⟷ TCP ⟷ SEC server → COM1 → [Energy Meter, Site A]
→ COM6 ⟷ TCP ⟷ SEC server → COM1 → [PLC, Site B]
→ COM7 ⟷ TCP ⟷ SEC server → COM1 → [RTU, Site C]
Chaque port COM virtuel est un canal dédié et isolé. Le logiciel maître interroge chacun indépendamment, avec son propre débit en bauds, sa propre plage d’ID d’esclave et son propre intervalle d’interrogation. Il n’y a pas de limite théorique au nombre d’appareils distants — vous ajoutez une paire Server/Client pour chacun.
De nombreux maîtres, un seul appareil

De nombreux maîtres, un seul appareil

Serial to Ethernet Connector prend également en charge l’inverse : plusieurs applications maîtres Modbus — ou plusieurs postes de travail d’ingénierie — accédant simultanément au même périphérique série physique. Cela est utile lorsque, par exemple, un système SCADA et l’ordinateur portable d’un ingénieur de maintenance doivent tous deux lire le même compteur d’énergie ou PLC distant sans débrancher les câbles. Chaque maître se connecte au port du serveur et obtient son propre port COM virtuel, tandis que le serveur gère l’accès au port physique partagé.
De nombreux maîtres, de nombreux appareils

De nombreux maîtres, de nombreux appareils

Les deux topologies peuvent être combinées librement. Une grande installation peut comporter des dizaines d’appareils série distants, chacun desservi par sa propre instance de SEC Server, avec plusieurs postes de travail d’ingénierie ou nœuds SCADA détenant chacun un ensemble de ports Client virtuels. Le résultat est un réseau série virtuel complet — flexible, défini par logiciel, et ne nécessitant aucun matériel supplémentaire au-delà de ce qui est déjà en place.
Conseil pratique

Lorsque plusieurs maîtres partagent l’accès à un même port série physique, il est important que votre interrogation Modbus soit sérialisée — un seul maître doit envoyer une requête à la fois, car Modbus RTU ne dispose d’aucune détection de collision. La plupart des plateformes SCADA mettent automatiquement les requêtes en file d’attente. Si la vôtre ne le fait pas, configurez les maîtres pour utiliser des fenêtres d’interrogation qui ne se chevauchent pas ou utilisez des ports physiques distincts pour chaque maître.

Configuration étape par étape

Ce qui suit suppose que vous disposez de deux machines Windows sur le même réseau (ou connectées par VPN). Le même principe s'applique à Linux en utilisant l'édition en ligne de commande.
1
Installez Serial to Ethernet Connector sur les deux machines — Exécutez le programme d’installation sur la machine serveur (celle avec le port RS-232/485 physique connecté à votre appareil Modbus) et sur la machine cliente (celle sur laquelle votre logiciel SCADA ou maître Modbus s’exécute). Le même programme d’installation couvre les deux rôles.
Installez Serial to Ethernet Connector sur les deux machines
2
Créez une connexion serveur sur la machine avec le port physique — Ouvrez l’application, cliquez sur Ajouter une connexion → Série sur Ethernet → Serveur. Sélectionnez le port COM physique (par ex. COM1), définissez le débit en bauds et le format de trame pour qu’ils correspondent à votre appareil (par ex. 9600 8N1 pour la plupart des appareils Modbus RTU), et choisissez un port TCP sur lequel écouter (5000 par défaut). Cliquez sur Connecter — le service est maintenant à l’écoute.
Créer une connexion au serveur sur la machine avec le port physique
3
Créez une connexion Client sur la machine maître Modbus — Sur la deuxième machine, cliquez sur Ajouter une connexion → Série sur Ethernet → Client. Saisissez l’adresse IP de la machine serveur et le même port TCP (5000). Le logiciel créera un nouveau port COM virtuel (par ex. COM5) et se connectera. Vous verrez un statut Connecté dans les deux instances.
Créer une connexion Client sur la machine maître Modbus
4
Pointez votre logiciel maître Modbus vers le nouveau port virtuel — Dans Kepware, Ignition, ModRSsim, ou tout autre outil que vous utilisez, remplacez le port COM du canal par le nouveau port virtuel (COM5). Conservez tous les autres paramètres — débit en bauds, parité, ID esclave, fréquence d’interrogation — identiques. La communication devrait démarrer immédiatement.
5
Vérifiez avec un sondage Modbus — Utilisez Modbus Poll ou QModMaster pour envoyer une requête de lecture manuelle (Code de fonction 03) à l’ID esclave de votre appareil. Si les registres renvoient des valeurs, le tunnel fonctionne de bout en bout. Si vous obtenez un délai d’attente, vérifiez que le débit en bauds sur le port virtuel correspond au port physique, et qu’aucun pare-feu ne bloque le port TCP 5000.
Conseil RS-485

Les bus RS-485 multi-drop (plusieurs appareils, un câble) sont entièrement pris en charge. Configurez le port COM physique du côté serveur avec le contrôle RTS activé si votre adaptateur USB-vers-RS485 l’exige pour la commutation de direction en semi-duplex. Le port virtuel du côté client reproduira automatiquement le même comportement RTS.

Configurations courantes et types d’appareils

Le tunnel fonctionne avec tout appareil prenant en charge Modbus RTU. Configurations les plus fréquentes :


  • API (Siemens S7, Allen-Bradley, Schneider Modicon) — Programmation à distance et interrogation des données en direct sur le LAN de l’usine.
  • Compteurs d’énergie et de gaz (Eastron, Carlo Gavazzi, Socomec) — Relevé des compteurs dans le poste ou le local électrique depuis un système central de gestion de l’énergie.
  • Variateurs de fréquence (Danfoss, ABB ACS, Siemens SINAMICS) — Lecture des registres de vitesse/couple et écriture des consignes à distance.
  • RTU et relais de protection (Schweitzer SEL, GE Multilin) — Lecture des journaux d’événements et des registres d’état depuis des postes distants via WAN/VPN.
  • Balances industrielles et ponts-bascules (Mettler-Toledo IND, Rice Lake) — Lecture des valeurs de poids depuis un système central de répartition ou ERP.
  • Onduleurs solaires (SMA, Fronius, Growatt) — Surveillance du rendement, des données de chaîne et des codes défaut depuis une plateforme centrale de supervision.
  • Instruments de débit et de pression (Yokogawa, Endress+Hauser) — Acquisition des données de procédé sans remplacer le câblage de terrain RS-485 existant.
  • IHM et pupitres opérateur (Weintek, Kinco) — Partage du port COM d’un seul pupitre entre plusieurs postes de travail d’ingénierie.

Serveur de périphériques série logiciel vs. matériel : comparaison honnête

Les deux approches fonctionnent. Le bon choix dépend du fait que vous ayez déjà un PC à l’extrémité distante et de l’importance que vous accordez à la simplicité du déploiement par rapport à l’indépendance de l’appareil.
Critère
Serial to Ethernet Connector
Serveur de périphériques matériels (Moxa / Lantronix / Digi)
Coût initial par port
✓ Licence logicielle, paiement unique
150–500 $ de matériel par port
Installation physique requise
✓ Non — s’installe sur un PC existant
Oui — montage en rack ou sur rail DIN sur site
Fonctionne sans PC à l’extrémité distante
Nécessite un PC/serveur/SBC
✓ Oui — appareil autonome
Conversion de protocole (RTU → TCP)
Non — tunnel transparent uniquement
De nombreux modèles incluent cela en option
Prise en charge multi-drop RS-485
✓ Oui
✓ Oui
Un-à-plusieurs / plusieurs-à-plusieurs
✓ Oui — paires de ports virtuels illimitées
Limité par le nombre de ports physiques par unité
Configuration à distance
✓ Via l’interface logicielle ou la ligne de commande
Interface Web ou Telnet
Fonctionne via VPN / WAN
✓ Oui — c'est une connexion TCP
✓ Oui
Fonctionne sous Linux / embarqué
✓ Oui — édition CLI pour RPi, x86
Le matériel est le périphérique Linux
Aucune modification de l’application maître Modbus
✓ Redirigez simplement le port COM
✓ Même modèle de pilote de port virtuel
Idéal lorsque
Un PC ou un SBC se trouve déjà sur le site
Aucun PC du tout à l’extrémité distante

Problèmes courants et comment les résoudre

Délais d’attente Modbus à chaque interrogation

La cause la plus fréquente est un décalage de débit en bauds. Vérifiez que le port physique côté serveur et le port virtuel côté client sont configurés avec le même débit en bauds et le même format de trame que l’appareil de terrain. Les appareils Modbus RTU utilisent par défaut 9600 8N1, mais certains sont livrés avec 19200 ou 38400. Consultez le manuel de l’appareil ou utilisez d’abord un moniteur série sur le port physique.

La connexion se coupe après quelques secondes

Vérifiez si un pare-feu d’entreprise ou le Pare-feu Windows Defender ferme les connexions TCP inactives. Ajoutez une règle entrante sur la machine serveur pour le port TCP 5000. Si vous travaillez sur un WAN, confirmez que le VPN ou le routeur NAT n’interrompt pas la connexion en raison d’un délai d’inactivité ; activez le keepalive TCP dans les paramètres de Serial to Ethernet Connector pour éviter cela.

Collisions en semi-duplex RS-485

Si vous utilisez un adaptateur RS-485 qui nécessite un contrôle logiciel RTS pour la commutation de direction, activez le mode de basculement RTS sur le port physique dans la configuration côté serveur. Cela garantit que la broche d’activation de transmission de l’adaptateur est pilotée correctement avant chaque trame de requête Modbus. Sans cela, vous pouvez voir des réponses brouillées ou aucune réponse du tout.

Plusieurs esclaves sur un même bus RS-485 ne répondent pas

Le multi-drop RS-485 fonctionne normalement — un port COM virtuel côté client peut interroger tous les ID esclaves sur le bus. Assurez-vous que votre logiciel maître Modbus envoie des requêtes unicast avec des ID esclaves spécifiques (1–247) et non des requêtes broadcast (ID esclave 0), qui ne génèrent pas de réponses. Ajoutez des délais entre les interrogations si le bus est fortement chargé.

Test rapide de connectivité (Linux / Windows WSL):

nc -zv 192.168.1.50 5000
# Expected: Connection to 192.168.1.50 5000 port [tcp/*] succeeded!
# If this fails, the firewall is blocking the TCP port

Questions fréquemment posées

Non. L’approche du port COM virtuel signifie que votre logiciel continue d’utiliser le pilote Modbus RTU et cible un port COM — exactement comme il l’a toujours fait. Le seul changement est le numéro de port COM que vous sélectionnez. Aucun port TCP, aucune adresse IP, aucun changement de protocole à l’intérieur de l’application.
Oui. Le port physique RS-485 unique peut avoir de nombreux esclaves câblés dessus (jusqu’à 32 sur un bus standard, 256 avec des répéteurs). Le port COM virtuel du côté maître représente l’ensemble de ce bus. Votre maître Modbus envoie des trames adressées à des ID d’esclave individuels (1–247) et chaque appareil répond à sa propre adresse, exactement comme il le ferait sur une connexion série locale.
Il n’y a pas de limite stricte imposée par le logiciel lui-même. Chaque périphérique série distant reçoit sa propre paire de ports Serveur/Client. En pratique, la limite dépend de la bande passante de votre réseau et de la capacité d’interrogation de votre application maître Modbus. Les installations avec des dizaines de ports COM distants sont courantes, en particulier dans les environnements de comptage d’énergie et SCADA.
Sur un réseau local (LAN), la latence ajoutée est généralement de 1–5 ms — négligeable pour les applications d’interrogation. Sur un WAN ou un VPN, cela dépend de la qualité de la liaison, mais la plupart des applications SCADA et d’acquisition de données utilisent des intervalles d’interrogation mesurés en secondes, ce qui rend même 50–100 ms de latence ajoutée sans importance. Réglez votre délai d’expiration Modbus sur au moins 3× le temps d’aller-retour attendu par mesure de sécurité.
Le Serial to Ethernet Connector prend en charge un mode d'accès partagé dans lequel plusieurs ports virtuels clients se connectent au même port serveur. Le fonctionnement avec Modbus dépend de votre logiciel maître — Modbus RTU est un protocole de requête/réponse et les requêtes simultanées de plusieurs maîtres entreront en collision sur le bus. La plupart des plateformes SCADA gèrent cela via leur propre mise en file d'attente des requêtes ; si la vôtre ne le fait pas, utilisez des ports physiques séparés par maître ou sérialisez l'accès au niveau de l'application.
Oui, tant que le routeur du site distant dispose d’une IP joignable (statique ou DDNS) et que le port TCP est redirigé. En pratique, la plupart des routeurs cellulaires industriels prennent en charge la redirection de port ou les tunnels VPN, ce qui constitue l’option la plus sécurisée. Activez le paramètre keepalive dans Serial to Ethernet Connector pour récupérer proprement après de brèves coupures du réseau cellulaire.
Le tunnel TCP par défaut n’est pas chiffré, ce qui est une pratique standard sur les réseaux d’usine isolés. Pour les sites connectés au WAN, l’approche recommandée consiste à exécuter le tunnel à l’intérieur d’un VPN — IPsec ou WireGuard — qui chiffre l’ensemble de la session. Un tunnel SSH est également simple à mettre en place pour les configurations Linux à Linux.
Serial to Ethernet Connector
Accéder au port série distant via le réseau IP pour Windows
Essayer gratuitement
Période d'essai de 14 jours gratuits
La licence est disponible à partir de $259.95
Disponible pour