Interrogation industrielle, saturation des files et nouvelles tentatives

Un maître Modbus RTU envoie une requête, attend la réponse ou l’expiration du délai, puis seulement envoie la suivante. Un bus RS-485 a donc une capacité maximale qu’aucun réglage ne peut dépasser. Une passerelle Modbus TCP placée devant ce bus n’augmente pas sa capacité. Si le collecteur demande davantage, la file des requêtes en attente s’allonge et la valeur affichée prend du retard sur l’horloge. Comptez les transactions avant de régler les intervalles d’interrogation.

Ce guide fait partie de la série sur la qualité et la transmission des données.

Compter les transactions au point partagé

Comptez au goulet d’étranglement. Dix clients Modbus TCP qui lisent au travers d’une même passerelle série partagent son unique port RS-485, quelle que soit la rapidité d’Ethernet. La passerelle met leurs requêtes en file et les envoie une par une sur le bus.

Exemple sur un bus RS-485 à 9 600 bit/s, 8 bits de données, parité paire et 1 bit d’arrêt :

Ce bus actualise chaque point toutes les 3,4 s environ, au mieux. Demander un intervalle de 1 s représente 3,4 fois sa capacité. Le calculateur de durée Modbus RTU ci-dessous utilise les mêmes entrées. Il donne 85 ms par échange et 0,68 s pour une requête adressée à chacun des huit compteurs. Avec cinq blocs par compteur, le cycle dure 3,4 s.

Avec 11 bits par caractère, un caractère dure 1,15 ms à 9 600 bit/s et le silence intertrame de 3,5 caractères dure 4,0 ms. Au-delà de 19 200 bit/s, le guide de la ligne série fixe ce silence à 1,75 ms et le délai intercaractère à 0,75 ms (section 2.5.1.1). Un débit plus élevé réduit le temps sur le fil, mais pas le délai de réponse de l’appareil. À 38 400 bit/s, le même échange prend environ 37 ms, dont 20 ms pour le compteur.

Lisez des blocs plus grands. Chaque transaction paie le prix d’une requête, du délai de l’appareil et d’un silence intertrame, quel que soit le nombre de registres renvoyés. À 9 600 bit/s avec un délai d’appareil de 20 ms, vingt lectures de 2 registres prennent environ 870 ms. Une seule lecture des mêmes 40 registres consécutifs prend environ 130 ms. Les codes de fonction 03 et 04 peuvent lire jusqu’à 125 registres par requête (protocole applicatif Modbus V1.1b3, sections 6.3 et 6.4). Si un bloc englobe une adresse que l’appareil n’implémente pas, il échoue avec l’exception 02, adresse de données illégale. Ne fusionnez que des plages déclarées lisibles dans la table des registres et vérifiez si celle-ci impose une limite plus basse par requête.

BACnet MS/TP rencontre une limite comparable sous une autre forme. Un contrôleur n’émet que lorsqu’il détient le jeton ; un routeur envoie au plus Max_Info_Frames requêtes à chaque passage du jeton. Edge interroge BACnet via BACnet/IP : il accède donc aux contrôleurs MS/TP par un routeur et chaque lecture attend le tour de celui-ci. Le guide BACnet/IP et MS/TP calcule le temps de rotation du jeton.

Coût d’un appareil hors ligne

Chaque requête adressée à un appareil qui ne répond pas attend l’expiration du délai complet. Dans notre exemple, avec un délai de 1 s et cinq requêtes par compteur, un seul compteur hors ligne ajoute 5 s à chaque cycle. Le cycle passe de 3,4 s à 8,0 s et les sept compteurs sains sont lus à moins de la moitié de leur fréquence initiale.

Le guide de la ligne série indique un délai de réponse typique d’une seconde à plusieurs secondes à 9 600 bit/s (section 2.4.1). C’est prudent pour un appareil lent, mais coûteux sur un bus chargé. Réglez plutôt le délai à partir de mesures. Relevez pendant une journée de fonctionnement normal la réponse la plus lente de chaque appareil, puis fixez un délai environ deux fois plus long. Pour un compteur dont la réponse la plus lente prend 150 ms, choisissez 300 ms. La pénalité de l’appareil hors ligne passe alors de 5 s à 1,5 s dans cet exemple.

Ralentissez ensuite les tentatives pour cet appareil. Par exemple, après trois expirations consécutives, retirez-le du programme normal et marquez ses points comme périmés. Envoyez-lui une requête de vérification toutes les 60 s. Quand l’une réussit, reprenez le programme normal. Les compteurs sains retrouvent leur cycle de 3,4 s et le compteur hors ligne ne coûte plus que 0,3 s par minute.

Le bus doit tout de même disposer d’une marge pour les délais qui expirent avant le ralentissement. Avec un intervalle de 5 s, notre bus garde 1,6 s de marge. Un appareil hors ligne avec un délai de 300 ms coûte 1,5 s et tient dans cette marge ; avec un délai de 1 s, il coûte 5 s et ne tient plus. Si les expirations d’un appareil dépassent la marge, répartissez les appareils sur plusieurs bus.

Lorsque les requêtes arrivent plus vite qu’elles ne sont traitées

Interrogez le bus de l’exemple chaque seconde : le collecteur produit 40 requêtes par seconde et le bus en traite environ 12. La file grossit d’environ 28 requêtes par seconde. Si elle est traitée dans l’ordre, une requête émise après dix minutes avait été placée en file environ sept minutes plus tôt. Tous les indicateurs d’état peuvent rester verts : le bus travaille, les appareils répondent et aucune requête n’échoue. Seuls les horodatages révèlent des données vieilles de sept minutes.

Décidez quoi faire du travail en retard :

Surveillez l’âge de la plus ancienne requête en attente ainsi que la longueur de la file. Sur un bus qui suit la cadence, aucune requête n’attend plus d’un intervalle d’interrogation. Déclenchez une alarme si la plus ancienne dépasse deux intervalles.

Séparer les points en direct des registres d’énergie

La plupart des points n’ont pas besoin de l’intervalle le plus court. Un registre d’énergie en kWh est un total cumulatif : une lecture toutes les 15 minutes ne perd aucune énergie, car la lecture suivante comprend tout ce qui s’est passé depuis la précédente. Une puissance, une consigne ou un état de disjoncteur utilisés pour le pilotage demandent des secondes.

Interrogez les quelques points en direct à intervalle court et les registres d’énergie et de configuration à intervalle long. Supposons que chaque compteur de l’exemple fournisse un bloc direct toutes les 5 s et quatre blocs d’énergie toutes les 15 minutes. Les lectures directes utilisent alors 8 × 85 ms = 0,68 s sur chaque période de 5 s. Les 32 lectures d’énergie prennent 2,7 s une fois toutes les 15 minutes. Répartissez-les dans l’intervalle pour qu’elles ne tombent pas toutes au quart d’heure et ne retardent pas les lectures directes de 2,7 s.

Réessayer seulement ce qui peut réussir

Derrière une passerelle Modbus TCP, deux délais s’additionnent : celui du client et celui de la liaison série de la passerelle. Fixez le délai du client au-delà du délai série de la passerelle augmenté du temps passé par la requête dans sa file. Sinon le client abandonne une requête que la passerelle traite encore, la réessaie et place une seconde copie de la même lecture sur le bus. Le guide Modbus TCP et RTU traite des délais et des limites de connexion de la passerelle.

L’expiration du délai après une écriture (fonction 06 ou 16) ne prouve pas que l’écriture a échoué. L’appareil peut l’avoir appliquée sans que la réponse parvienne au client. Relisez le registre avant de réessayer. Réécrire deux fois une consigne absolue est sans conséquence. En revanche, une écriture qui déclenche une action, comme une remise à zéro de compteur ou un ordre de démarrage, peut agir deux fois : ne la réessayez jamais sans relecture.

Le ralentissement exponentiel avec délai aléatoire compte quand plusieurs clients partagent un serveur. Plusieurs clients Modbus TCP derrière une passerelle, ou une flotte de Gateways qui se reconnectent à un même serveur après une panne, réessaient simultanément si chacun n’ajoute pas de délai aléatoire. AWS décrit ce modèle, avec des plafonds sur le nombre de tentatives et sur le délai maximal. Sans cette précaution, les tentatives après le rétablissement peuvent continuer à saturer une liaison lente. Sur un bus RS-485 avec un seul maître, le délai aléatoire n’apporte rien ; c’est le ralentissement propre à chaque appareil qui compte.

Tester la reprise sous charge

1. Exécutez la liste complète des points aux intervalles prévus pendant au moins une heure. Relevez la durée du cycle. Elle doit rester inférieure à l’intervalle d’interrogation le plus court, avec une marge d’au moins les délais d’expiration d’un appareil.
2. Éteignez un appareil. Une fois ses tentatives ralenties, les lectures des autres doivent à nouveau dater de moins de deux intervalles.
3. Rallumez-le. Ses points doivent redevenir actuels dans la période d’une requête de vérification, soit 60 s dans l’exemple.
4. Coupez la liaison amont pendant 30 minutes. Les lectures locales doivent garder leurs horodatages habituels ; la file de sortie doit grossir au débit prévu : points par minute × 30.
5. Rétablissez la liaison. Chaque lecture en attente doit arriver une seule fois. Comptez les lectures par point et par horodatage chez le destinataire et vérifiez que le cycle du bus retrouve la valeur de l’étape 1 en deux cycles au plus.

Interrogation dans Edge

Edge sur le Gateway ZGW-20 dispose de cinq emplacements de connexion Modbus. Chaque emplacement correspond à un point de terminaison, port série ou hôte et port TCP, et possède ses propres files, limites de débit, mesures de latence et ralentissement en cas d’erreur. Il suspend aussi les lectures directes pendant 2 000 ms après une écriture. Tous les identifiants d’unité sur un même emplacement partagent ces réglages : un appareil défaillant derrière une passerelle peut donc retarder les appareils sains du même emplacement. Utilisez un emplacement par point de terminaison indépendant.

Le ralentissement en cas d’erreur compte les requêtes échouées consécutives sur l’emplacement, et non sur un seul appareil. Après 3 échecs, Edge arrête les lectures sur l’emplacement pendant 5 s ou deux intervalles d’interrogation, selon la durée la plus longue. Après 6 échecs, la pause est de 15 s ou trois intervalles ; après 10, de 30 s ou cinq intervalles. Une seule réponse réussie remet le compteur d’erreurs à zéro. Les appareils sains du même emplacement répondent généralement entre les requêtes vers l’appareil hors ligne : le compteur atteint donc rarement 3. Les délais de l’appareil hors ligne continuent alors à expirer à chaque cycle, d’où l’importance du réglage de ce délai.

Par défaut, un emplacement envoie jusqu’à 20 requêtes directes et 5 requêtes planifiées, alignées sur l’horloge, par seconde. Les deux limites peuvent être réglées entre 1 et 100. La limite directe par défaut dépasse la capacité du bus de notre exemple, environ 12 requêtes par seconde à 9 600 bit/s : réglez-la sous la capacité mesurée. La file planifiée garde 5 000 requêtes et abandonne les plus anciennes en premier. La file directe en garde 250 et fusionne les lectures équivalentes. Quand la latence d’un emplacement dépasse 5 000 ms, Edge limite les lectures directes de cet emplacement à une par seconde. Edge regroupe les lectures contiguës en blocs de 125 registres au maximum. Chaque emplacement signale sa dernière latence, sa latence moyenne et son nombre d’erreurs ; Edge consigne un avertissement s’il abandonne des lectures planifiées. Un appareil passe hors ligne après deux interrogations attendues manquées, jamais avant cinq minutes.

Ces limites protègent un bus lent. Elles n’augmentent pas sa capacité. Une interface Modbus ZMB est le maître RS-485 de son propre bus court. Le ZMB-31 lit jusqu’à 30 registres de l’équipement voisin et les envoie au Gateway par le réseau maillé Zigbee. Plusieurs ZMB remplacent un long bus partagé par plusieurs bus courts, chacun avec son propre budget de délais d’expiration.