Passerelle de protocole et pont transparent

« Gateway » peut désigner trois types d’appareils très différents. Un pont transparent transporte des octets par un autre chemin. Une passerelle de transport convertit une variante d’un protocole en une autre, par exemple Modbus RTU en Modbus TCP. Un traducteur de données lit des valeurs dans un protocole et les publie dans un autre, par exemple de BACnet vers Modbus. Demandez laquelle de ces fonctions assure le produit : chacune exige des spécifications et des essais différents.

Ce guide fait partie de la série Modbus et RS-485.

Trois fonctions

Un même produit peut assurer plusieurs de ces fonctions. Les termes commerciaux comme « transparent » sont employés de manière imprécise. Demandez à voir les écrans de configuration ainsi qu’un exemple de requête et de réponse.

Pont transparent

Un pont déplace le flux d’octets d’origine d’un chemin à un autre. Un serveur de périphérique série peut transporter un flux RS-485 sur un réseau IP, tandis qu’un logiciel distant le présente comme un port série. Le protocole ne change pas. Un flux série IEC 60870-5-101 transporté sur TCP reste IEC 101, pas IEC 104 ; des octets Modbus RTU bruts sur une connexion TCP ne sont pas du Modbus TCP.

Puisque rien n’est traduit, les deux extrémités doivent s’accorder sur tous les paramètres. Vérifiez :

• le délai ajouté, qui peut perturber la temporisation des caractères utilisée par Modbus RTU pour délimiter une trame ;
• le comportement lorsque la connexion réseau tombe puis revient ;
• la possibilité pour deux clients d’ouvrir le même flux série simultanément, ce qui créerait deux maîtres sur le bus.

Mettez le protocole d’origine en service de bout en bout, à travers le pont.

Passerelle de transport

Une passerelle Modbus TCP vers RTU comprend Modbus. Un client TCP lui adresse une requête avec l’adresse de l’appareil série dans l’identifiant d’unité. La passerelle retire l’en-tête MBAP de 7 octets, ajoute l’adresse RTU et le CRC, envoie la requête sur le bus et renvoie la réponse par TCP. La table de registres de chaque appareil reste inchangée. Le guide Modbus TCP et RTU explique les deux structures de trame.

La capacité, en revanche, change. Plusieurs clients TCP peuvent joindre une passerelle, mais le bus série ne transporte toujours qu’une seule requête à la fois. Le débit Ethernet n’augmente pas la capacité du bus. Demandez comment la passerelle traite les requêtes :

• Transmission directe. Chaque requête d’un client passe sur le bus. Trois clients interrogeant dix compteurs triplent le trafic ; les réponses lentes retardent tous les clients.
• Cache. La passerelle interroge elle-même le bus et répond aux clients depuis sa mémoire. Le trafic du bus reste constant, mais chaque valeur date de la dernière interrogation et la passerelle peut continuer à répondre après l’arrêt d’un compteur.

Dimensionnez le bus avec le calculateur de temporisation Modbus RTU et réglez les délais des clients au-delà du délai série de la passerelle.

Traducteur de données

Un traducteur lit des valeurs dans un modèle de données et les publie dans un autre. Il nécessite une correspondance explicite pour chaque point. Pour une température BACnet publiée sous forme de registre Modbus, cette correspondance doit indiquer :

Certaines informations disparaissent pendant la traduction. Un registre Modbus n’a ni unité, ni horodatage, ni indicateur de qualité. Les indicateurs d’état et tableaux de priorités BACnet, ainsi que les codes d’état OPC UA, n’ont pas d’équivalent Modbus. Décidez comment le système récepteur saura qu’une valeur est périmée : registre d’état distinct, registre d’âge ou valeur de présence qui change à chaque actualisation.

Lecture et écriture suivent des chemins distincts

Une passerelle qui publie une mesure n’accepte pas automatiquement les commandes en sens inverse. Écrire dans un registre publié peut modifier seulement la mémoire de la passerelle, être refusé ou déclencher une commande vers l’appareil de terrain configurée à cet effet. Les spécifications doivent préciser laquelle de ces actions se produit.

Avant un essai d’écriture, obtenez la table des commandes, les valeurs permises, le nom du responsable de l’équipement et le retour qui prouve la réponse de l’appareil. Ne testez jamais la commande en écrivant dans un registre contenant une mesure. Le guide des priorités BACnet explique pourquoi une écriture BACnet peut rester active après le moment où vous pensiez qu’elle prendrait fin.

Tester la fonction achetée

1. Utilisez des valeurs sources connues qui révèlent les erreurs : nombre négatif, valeur décimale, grand compteur et changement d’état.
2. Comparez la mesure source et la valeur reçue au même instant.
3. Arrêtez l’appareil source en laissant la passerelle allumée. Vérifiez que le récepteur voit une valeur périmée, pas une mesure stable.
4. Redémarrez la passerelle. Vérifiez ce que voit le récepteur avant la première nouvelle lecture : valeur par défaut, zéro ou ancienne valeur.
5. Si les écritures sont prévues, testez-les séparément avec le responsable de l’équipement.

Edge comme traducteur de données

Edge, sur le Gateway ZGW-20, fonctionne comme traducteur de données. Il lit les appareils Zigbee et LoRaWAN, les équipements Modbus TCP et RTU, les objets BACnet/IP et les serveurs OPC UA dans un modèle de données commun, avec une unité et un horodatage pour chaque mesure. Il publie ensuite ces données vers des plateformes énergétiques par MQTT ou HTTP, ou sous forme de registres Modbus TCP pour un BMS ou un système SCADA. Traitez chaque point publié comme un point de correspondance et testez-le comme ci-dessus. La page Connecter Edge à votre plateforme décrit les sorties de données d’Edge.