Quel est l’intérêt du MQTT pour la télégestion ?

Le MQTT est un protocole que l’on associe fréquemment aux IoT ; dans un article récent (Pourquoi le MQTT ne se résume-t-il pas à l’IoT ?) nous présentions son fonctionnement ainsi que son usage pour les échanges avec les automates en mettant en évidence son intérêt au-delà des objets connectés.

VERDONE, entreprise toulousaine spécialiste de l’installation et de la mise en œuvre de solutions d’automatisme et de régulation, a réalisé des projets exploitant le protocole MQTT pour la télésurveillance de sites distants au travers de connexion 3G. Alexia Waroude et David Caillier, respectivement Automaticienne et Directeur des opérations, ont eu la gentillesse de répondre à nos questions afin de partager leur expérience de ce protocole.

Les avantages sont nombreux ! Tout d’abord, c’est un protocole simple d’accès, il est facile de trouver des tutoriels sur internet et de monter rapidement une plateforme pour un budget raisonnable. C’est un protocole vraiment accessible par rapport aux protocoles LonWorks, KNX et BACnet qui nécessitent de l’expertise et une pratique régulière pour en conserver une bonne maîtrise.

Le MQTT est très performant pour la mise en route et la maintenance de la supervision. Utilisant un broker en point central de la communication, il est très facile et rapide d’identifier l’origine d’un problème de communication : il suffit de s’abonner aux données en parallèle des subcribers et des publishers, d’arrêter la communication d’un côté ou de l’autre du broker afin d’identifier si le problème vient de la liaison automate/broker ou de la liaison broker/ supervision. L’outil de diagnostic appelé MQTT Explorer facilite ces opérations de recherche de problèmes de communication. À titre de comparaison, avec le Modbus, il faut utiliser un snifer comme WireShark pour voir les trames qui passent, ce qui n’est pas très convivial ; quant au BACnet la recherche de problèmes peut-être encore plus longue.

Le MQTT est un protocole événementiel, il est donc très léger en bande passante. Sur un de nos projets, la récupération de données depuis 40 châteaux d’eau à une période de 5 minutes ne pèse que 600Mo par mois ! Le fait que ce soit un protocole purement événementiel présente un second avantage, lorsqu’une variable change de valeur, la donnée arrive tout de suite à la supervision. Ainsi nous avons réalisé des tests avec un automate communiquant en MQTT et le broker connecté à une supervision PcVue® au travers d’une connexion 3G. Le laps de temps entre l’envoi d’une commande depuis la supervision et le retour de l’état calculé dans l’automate nécessite moins d’une seconde. C’est très performant.

Le MQTT est naturellement conçu pour communiquer de 1 vers n (NDLR, comprenez d’un publisher vers un subscribers). Si nous reprenons l’exemple de télégestion des châteaux d’eau, lors d’un changement de mesure de températures d’une sonde ou d’un changement d’index de compteur, la valeur est envoyée simultanément à la supervision et au logiciel de management des énergies. L’automate n’a ainsi qu’une seule requête à faire pour rafraichir la variable.

Le protocole MQTT intègre la bufférisation en cas de coupure de liaison. Pour un site télégéré via une connexion 3G, dans le cas où la connexion est interrompue, l’automate stocke les événements dans son unité centrale. Une fois la connexion rétablie, le broker publie tous les événements et la supervision récupère ainsi toutes les données historisées ; il n’y a pas de perte de données. Il en va de même entre le broker et la supervision. Là où c’est particulièrement performant, c’est que ce fonctionnement est intrinsèque au MQTT et ne demande pas de programmation contrairement au Modbus TCP/IP. De plus, dans le cas du superviseur PcVue® que nous utilisons, les payloads sont codés en Json ce qui permet de faire passer l’horodate dans la structure du payload. Cela signifie que toutes les données sont horodatées à la source. C’est extrêmement pratique pour faire de la discrimination et dans le cas de la bufférisation à la suite d’une perte de connexion, cela permet de récupérer les données correctement horodatées dans la supervision.

Enfin, le MQTT est libre de droits, fiable et sécurisé, il est compatible avec les contraintes de cybersécurité : mise en place de login pour l’accès au broker et échanges cryptés.

Ce protocole est arrivé avec les objets connectés. Pour les sites isolés où l’on doit gérer la communication en 3G, il y a vraiment un truc à faire avec ce protocole événementiel qui utilise peu de flux. Le domaine du traitement de l’eau est un très bon exemple d’application, tout comme la gestion de postes à Haute Tension. Pourquoi ? Parce que c’est purement événementiel avec horodatage à la source. Ainsi en cas de basculement de poste HT ou de disjonction, on est averti très rapidement et avec la bonne date.

Tous les sites qui ont été faits en Modbus IP, parce que c’était le seul protocole totalement ouvert et fonctionnant bien, pourraient utiliser du MQTT. En effet, le gros inconvénient du Modbus est que la communication est à l’initiative du maître, ce qui implique d’interroger l’esclave. Le gros avantage du MQTT par rapport au Modbus est que dès qu’un événement change, l’esclave publie la donnée. Finalement, le MQTT pourrait remplacer avantageusement le Modbus parce qu’il permet l’horodatage à la source et offre les avantages d’un protocole événementiel, tout en étant simple à comprendre et à déployer !

Concernant la fiabilité et le choix de localisation du broker ?

Dans nos applications, nous avons choisi d’installer le broker là où on installe le serveur d’acquisition PcVue®. Le broker peut aussi être redondé et chaque automate peut publier sur les 2 brokers en même temps. Il est ainsi possible de déployer deux logiciels broker adossés à deux serveurs d’acquisition de la supervision. Ensuite dans le cas de PcVue la redondance de la supervision suit celles des brokers.

Concernant les contraintes de cybersécurité ?

Nativement le MQTT intègre une sécurité par authentification des connexions providers-broker et broker-subscribers ; ce qui présente un avantage supplémentaire par rapport à d’autres protocoles comme le Modbus.

En complément dans l’application de télégestion des châteaux d’eau, des tunnels VPN ont été mis en place à l’initiative des automates locaux. Les automates montent via la 3G un tunnel IP sec qui va jusqu’au superviseur et tous les échanges passent au travers du tunnel VPN. Pas de port entrant depuis l’extérieur directement sur le broker, on passe d’abord via une connexion VPN. On peut dire que le broker est à l’écoute sur un réseau local parce que les équipements sont sur un VPN avec adresse IP fixe préétablie.

Et concernant le broker ?

Nous avons choisi le broker libre de droits Mosquito®, qui est utilisé par énormément de monde sur de très nombreuses applications depuis des années. Sur nos applications, il ne nous a jamais posé de problème. Il est aussi possible d’utiliser des logiciels payants si l’on souhaite disposer d’un suivi logiciel particulier. Néanmoins il faut noter qu’en associant le broker à une infrastructure VPN de bout en bout, le broker n’a plus la responsabilité de la sécurité.

De plus en plus de constructeurs s’intéressent au MQTT (NDLR l’offre produit reste encore réduite), nous sommes convaincus que son usage va se développer. Aujourd’hui, nous avons réalisé des applications avec le SCADA PcVue® et les automates WAGO®. Le MQTT est intégré de manière optimum dans PcVue parce que les développeurs ont inclus un mode transparent qui permet de donner aux variables PcVue® le même nom que le topic dans MQTT. Il n’y a plus de communication à programmer dans PcVue® ; cela représente un gain de temps très important pour la programmation et c’est de plus très facile à utiliser et à maintenir.

Sur nos applications, c’est impressionnant comment l’ensemble PcVue® WAGO® fonctionne bien. De plus, les premiers projets avec de nouveaux protocoles sont habituellement ardus parce qu’il y a de l’expérience à acquérir et que de nombreuses choses à savoir ne sont pas écrites dans les documentations, ici ce n’est absolument pas le cas.

Nous pensions déjà depuis deux ou trois ans que le MQTT présentait toutes les qualités pour des applications de télégestion. Par ailleurs, nous intégrons le logiciel PcVue® depuis de très nombreuses années et sommes accompagnés par ATYS CONCEPT, son distributeur, au travers de leur expertise produit.

Historiquement, le projet était parti sur un vieux protocole en RTC avec des solutions classiques de télérelève. Nous avons échangé avec ARC Informatique, l’éditeur de PcVue®, qui a été séduit par le projet et a décidé d’intégrer le protocole MQTT dans PcVue®, avec en plus comme je le disais précédemment une approche très intéressante puisque la programmation de la communication dans PcVue® est extrêmement simplifiée.

C’est un partenariat gagnant-gagnant qui nous a permis une belle réalisation et permet aujourd’hui à PcVue® de se différencier de nombre de ses confrères.

Lire notre article Pourquoi le MQTT ne se résume-t-il pas à l’IoT ? pour tout comprendre du MQTT.

Vous avez une expérience avec des solutions ATYS CONCEPT que vous souhaitez partager ? Ecrivez-nous !