Transmission série vers TCP transparente ou conversion de protocole : que faut-il à votre appareil ?
Choisissez une passerelle série vers TCP transparente si le logiciel hôte doit continuer à utiliser le protocole série existant de l’appareil. Choisissez la conversion de protocole si l’hôte attend un autre protocole applicatif, par exemple Modbus TCP plutôt que Modbus RTU. La première transporte des octets ; la seconde interprète les messages et les reconstruit.
Cette décision précède le choix du matériel. « RS485 vers Ethernet » décrit les interfaces, mais ne garantit pas la compatibilité des logiciels aux deux extrémités. Une conception aboutie doit aussi tenir compte du découpage en trames, de la maîtrise du bus, des nouvelles tentatives et de la sécurité.
Ce que fait réellement une passerelle série transparente
En mode transparent brut, la passerelle transfère les octets de charge utile série via une connexion TCP et écrit les octets de charge utile TCP reçus sur son port série. L’application reste responsable des commandes de l’appareil, des sommes de contrôle, de l’analyse des réponses et de la signification des commandes. Vérifiez le mode choisi : les modes COM virtuel ou de commande du port série peuvent ajouter leur propre négociation et nécessiter un logiciel hôte adapté.
C’est un point de départ utile pour un protocole binaire propriétaire ou une application série existante pouvant utiliser un pilote COM virtuel pris en charge. Vérifiez si l’application dépend de signaux de commande de modem, du signal BREAK, d’une temporisation précise ou du comportement du pilote série local. Une passerelle qui transporte des octets de données ordinaires ne reproduit pas nécessairement ces fonctions.
Par exemple, si un instrument utilise une commande documentée avec un préfixe de longueur, l’hôte peut accumuler les octets TCP jusqu’à disposer de la réponse complète à cette commande. Aucun mappage de registres n’est nécessaire, mais l’hôte a toujours besoin de l’analyseur du protocole de l’instrument.
TCP ne conserve pas les limites des messages série
TCP fournit un flux d’octets fiable et ordonné. Le récepteur peut obtenir une partie d’un message applicatif lors d’une lecture, ou plusieurs messages ensemble. Les segments TCP et les lectures de socket ne constituent pas des enregistrements applicatifs. C’est le modèle de transport défini dans la RFC 9293.
Exemple illustratif : un appareil envoie deux messages de huit octets, A et B. L’application réceptrice peut lire les cinq premiers octets de A, puis les trois octets restants de A avec les huit octets de B. Ces limites de lecture ne sont qu’un exemple, pas une prédiction du comportement du réseau. L’analyseur doit mettre en tampon les données incomplètes et extraire les messages complets à l’aide de la longueur, du délimiteur ou des autres règles de découpage en trames du protocole.
La temporisation série doit être traitée séparément. Modbus RTU utilise des silences pour séparer les trames et impose des contraintes de temps entre caractères ; la spécification de la liaison série, section 2.5.1.1, les définit, y compris la recommandation de temporisation pour les débits en bauds plus élevés. Les bits de départ, de parité et d’arrêt de l’UART ne sont pas non plus des octets ordinaires de charge utile TCP.
Ne supposez pas que les intervalles entre les arrivées de données réseau reproduisent les silences série. Une passerelle a besoin d’une mise en tampon appropriée et de règles de transmission série adaptées. Les délais de paquetisation ne suffisent pas, à eux seuls, à prouver qu’une trame RTU restera intacte en sortie série. Testez les entrées fragmentées, les octets retardés et les requêtes qui se suivent sans intervalle.
Modbus RTU dans un tunnel diffère de Modbus TCP
Une requête Modbus TCP utilise un en-tête MBAP de sept octets et une unité de données de protocole (PDU). Modbus RTU utilise une adresse série, la PDU et un CRC. Un tunnel transparent peut transporter l’intégralité des octets RTU, CRC compris, dans TCP, mais un client Modbus TCP standard attend le format MBAP.
Une passerelle de conversion analyse le MBAP, achemine l’identifiant d’unité (Unit Identifier) vers la destination série configurée, construit la requête RTU, vérifie le CRC de la réponse et associe celle-ci à la transaction TCP d’origine. La longueur MBAP permet l’analyse des messages ; l’identifiant de transaction associe les requêtes à leurs réponses. Voir le guide de mise en œuvre Modbus TCP/IP, sections 3.1.2–3.1.3.
Exemple détaillé, inventé à des fins d’illustration : lire deux registres de maintien à partir de l’adresse zéro transmise dans le protocole, sur l’appareil série 7. La fonction 03 et l’adressage à base zéro dans le protocole suivent la spécification du protocole applicatif Modbus, sections 4.4 et 6.3. Ces octets illustrent le codage ; ils ne représentent ni un essai de produit Obeita ni la table de registres d’un appareil réel.
- PDU de la requête :
03 00 00 00 02. - Requête Modbus TCP :
00 2A 00 00 00 06 07 03 00 00 00 02. L’identifiant de transaction est002A; la longueur0006compte l’identifiant d’unité et les cinq octets de la PDU. - Requête RTU correspondante :
07 03 00 00 00 02 C4 6D. Le CRC calculé est transmis en commençant par l’octet de poids faible.
Dans cet exemple, la PDU reste inchangée. Convertir le format des trames de transport ne traduit pas automatiquement un jeu de commandes propriétaire, ne déduit pas les facteurs d’échelle et ne résout pas l’ordre des données réparties sur plusieurs registres. Ces besoins exigent un mappage explicite.
Définir la maîtrise du bus série et la politique de nouvelles tentatives
Le modèle de liaison série Modbus autorise un seul maître initiateur et une seule transaction à la fois. Ajouter des clients Ethernet n’augmente pas la capacité de traitement simultané de la liaison série. Si plusieurs hôtes doivent y accéder, exigez un ordonnanceur documenté, des limites de file d’attente, une gestion des délais d’attente et un routage des réponses. Ne raccordez pas un autre maître effectuant des interrogations actives au même bus sans mécanisme d’arbitrage conçu à cet effet.
Demandez ce qui se passe lorsqu’une requête en attente expire, qu’un client se déconnecte ou qu’une réponse série arrive en retard. Un serveur transparent acceptant plusieurs sockets a besoin de règles explicites d’attribution du bus ; la seule acceptation des connexions ne garantit pas un fonctionnement multiclient sûr.
Scénario de panne : un appareil exécute une écriture, mais sa réponse est perdue avant de parvenir au client. Une nouvelle tentative de l’application peut exécuter cette écriture une seconde fois. Une retransmission TCP au sein d’une connexion est différente de l’émission d’une nouvelle requête applicative. Un identifiant de transaction Modbus ne garantit pas, à lui seul, une suppression persistante des doublons.
Classez les commandes selon leurs effets. Répéter l’affectation d’une consigne peut être acceptable ; répéter une commande qui démarre un cycle peut ne pas l’être. Pour les écritures aux conséquences importantes, définissez un contrôle de séquence pris en charge par l’appareil, une vérification de cohérence de l’état ou une procédure de reprise par l’opérateur plutôt que des nouvelles tentatives inconditionnelles.
Définir le périmètre de sécurité du déploiement
Ni TCP non sécurisé ni Modbus TCP classique ne fournit intrinsèquement un accès applicatif chiffré et authentifié. Vérifiez les fonctions réellement prises en charge par la passerelle et le client choisis. Modbus Security spécifie TLS et l’authentification par certificat ; les deux extrémités doivent les prendre en charge, et la fourniture ainsi que le renouvellement des certificats doivent être planifiés.
La liste de contrôle du déploiement doit prévoir de limiter l’accès réseau à la passerelle aux systèmes autorisés, d’isoler le réseau de contrôle, de protéger les accès d’administration et d’éviter une exposition directe à l’Internet public. Un VPN ou une passerelle de sécurité approuvés peuvent protéger un chemin réseau, mais le segment local restant et les autorisations d’accès à l’appareil doivent encore être examinés. Le chiffrement ne détermine pas quel client authentifié peut effectuer une écriture.
Une liste de contrôle pratique pour le choix et la réception
- Identifier les deux protocoles. Consignez ce que l’appareil émet et ce que l’hôte accepte : octets série bruts, RTU-over-TCP, Modbus TCP ou un autre format documenté.
- Vérifier les prérequis électriques. Vérifiez, au regard des exigences d’installation, le choix entre RS232 et RS485, le câblage à deux ou quatre fils, le brochage, le débit en bauds, la parité, les bits d’arrêt, la mise à la terre, l’isolation, la terminaison et la polarisation.
- Attribuer la responsabilité du découpage en trames. Identifiez le composant qui assemble les messages et respecte la temporisation série, en précisant notamment la taille maximale des trames et le comportement face à des entrées mal formées.
- Spécifier l’accès et la reprise. Définissez la maîtrise du bus, le comportement des clients simultanés, les permissions de commande, les délais d’attente, les limites de file, la gestion des reconnexions et les nouvelles tentatives d’écriture sûres.
- Vérifier les cas difficiles. Utilisez un banc d’essai pour tester les lectures TCP partielles et regroupées, les appareils absents, les réponses tardives, les reconnexions, la saturation des files et les accès refusés. Fixez les critères de réussite avant les essais.
Choisissez le transfert transparent lorsque la compatibilité des protocoles existe déjà et que le découpage en trames peut être géré de manière fiable. Choisissez la conversion lorsque l’hôte exige un autre format de message ou un modèle de données explicite. Si l’une des deux extrémités n’est pas documentée, recueillez des éléments probants avant d’arrêter une architecture de passerelle.
Préparer vos exigences de passerelle pour Obeita
Pour une discussion technique ciblée avec Obeita, préparez un manuel d’appareil expurgé des informations sensibles, des trames de requête et de réponse représentatives, les paramètres série, le protocole hôte, le nombre d’appareils, les contraintes temporelles et le comportement attendu en cas de panne. Retirez les identifiants d’accès, les identifiants clients et les données de procédé confidentielles. Ces éléments permettent d’évaluer les travaux de transport, de conversion et de validation nécessaires.
Découvrez le service de connectivité des équipements existants d’Obeita et le projet livré d’adaptation série vers Ethernet et DTU cellulaire (en anglais) pour des travaux d’intégration similaires. Pour discuter des protocoles de votre appareil et de votre hôte, contactez Obeita.
