Pourquoi le MQTT ne se résume-t-il pas à l’IoT ?

Le MQTT (Message Queuing Telemetry Transport) est un protocole léger utilisant une faible bande passante et ayant une faible consommation énergétique. Il a vu le jour en 1999 dans le but de surveiller des pipelines dans le désert, un environnement isolé nécessitant une liaison satellite très onéreuse à l’époque. 

Aujourd’hui ce protocole orienté M2M (Machine-to-Machine) présente de nombreux avantages pour la remontée, la centralisation et la distribution d’informations temps réel en local ou entre des sites distants. Cela permet notamment aux systèmes SCADA d’accéder aux données IoT, ce qui fait du MQTT l’un des principaux protocoles de messagerie IIoT (internet des objets industriels). Le MQTT, grâce à son principe de fonctionnement et à l’organisation de ses messages, présente aussi de forts arguments pour son utilisation dans un cadre d’intercommunication entre logiciels métier. 

Utilisant une connexion TCP-IP, il peut fonctionner au travers d’un réseau Ethernet, WiFi ou encore 4G. Il est donc tout naturel de le retrouver comme une solution de télégestion dans les domaines du bâtiment, des smart cities, des énergies, de la logistique et de l’industrie. 

Souvent assimilé à la technologie LoRa et identifié dans la grande famille des protocoles IoT, le positionnement du MQTT est confus pour un grand nombre. Découvrez dans cet article le fonctionnement du MQTT ainsi que ses principales utilisations dans l’industrie. 

Le protocole MQTT est basé sur le principe de publication et d’abonnement. Les clients MQTT se connectent à un broker et s’abonnent aux informations qui les intéressent. Un client MQTT peut publier des messages sur un topic (sujet) ou s’abonner à un topic pour recevoir les messages publiés par d’autres clients. Plusieurs clients peuvent s’abonner à un même topic et publier dans un même topic.  

Un client MQTT qui publie un message est appelé « Publisher » tandis qu’un client qui s’abonne aux topics pour recevoir un message s’appelle un « Subscriber ». Un client peut être Publisher et Subscriber à la fois. 

Le broker est le centre du réseau MQTT. C’est en réalité un logiciel pouvant être exécuté sur différents systèmes d’exploitation (Windows /Linux/ MacOs) et hébergé en local ou dans le cloud. De nombreux brokers sont disponibles, en version gratuite ou payante. 

Les messages sont filtrés par sujet, appelés « Topic ». Un broker contient généralement plusieurs topics et sous topic. Le rôle du broker est donc de recevoir les messages qu’un Publisher a publié dans un topic et les retransmettre aux Subscribers de ce même topic. 

Un message est publié sous une certaine clef topic, permettant l’organisation et l’accès à l’information dans le broker. Les clients abonnés peuvent donc récupérer uniquement les informations qui les concernent en s’abonnant à certains topics. 

Une clef topic se présente sous la forme suivante : 

TopicParent1/TopicParent2/…/TopicDestinataire 

Exemple : Atelier1/Ligne2/machine1/Temperature 

Chaque niveau de topic est séparé par un « / ».  

L’architecture pouvant être complexe, il peut être intéressant d’utiliser des Wildcards, autrement appelés caractères génériques ou caractères joker.

Il y a deux types de Wildcards : 

• Simple niveaux “+” : Utiliser un “+” permet de remplacer un niveau de topic.  

Par exemple, Atelier1/Ligne2/+/Température permettra de s’abonner à la température de toutes les machines de la ligne 2 de l’atelier 1. 

•  Multiniveau “#” : Un “#” ne s’utilise qu’en fin de clef topic.  

Par exemple, Atelier1/Ligne2/machine1/# permettra de s’abonner à toutes les informations disponibles dans la machine 1 de la ligne 2 de l’atelier 1. 

Les différents niveaux de topic rappellent une philosophie objet très utilisée en milieu industriel permettant la modélisation des données. Les modèles de données sont exploitables dans différents systèmes d’automatismes et de supervision, comme par exemple le SCADA PcVue et sa fonctionnalité Application Architect.

Plus d’information ici

Les informations contenues dans les messages sont encapsulées sous forme de Payload. Le format d’un Payload n’est pas normé en MQTT, il peut ne pas avoir de format spécifique (chaîne de caractères simples ou valeur uniquement). Cependant, le format le plus fréquent dans la pratique est le JSON (JavaScript Object Notation). 

C’est donc le fabricant ou le développeur qui définit son propre Payload laissant une grande liberté et beaucoup de souplesse quant à l’organisation des messages. En contrepartie cela implique que le Subscriber a la capacité de décoder le Payload. L’idéal est que le Subscriber dispose d’une fonctionnalité de décodage paramétrable ne nécessitant aucune programmation informatique ou modification de son code source. Ainsi, il pourra s’interfacer avec différents types de Publishers. 

De plus en plus présent comme solution d’accès aux données, le MQTT ouvre l’intercommunication entre les logiciels métier (ERP, GMAO, MES) et les SCADA de manière organisée et simplifiée sans nécessiter une bande passante particulièrement élevée (donc une rapidité de transmission très élevée sur des réseaux TCP/IP performants). 

Le MQTT peut néanmoins être présent sur l’intégralité d’une chaîne de transmission d’informations. Il peut être utilisé directement par des capteurs ou des automates mais aussi pour l’interconnexion de différents systèmes d’information. Enfin, il est aussi très employé avec les capteurs LoRa. 

Le MQTT permet l’acquisition de données en provenance de capteurs communicants. Bien que très présente dans les applications domestiques, cette solution n’est pas la plus répandue dans le secteur industriel du fait de la très faible quantité de capteurs MQTT disponibles.  

Certains logiciels SCADA permettent une connexion MQTT. Cette solution a pour avantage de bénéficier de l’horodatage des informations à la source ; c’est-à-dire la date-heure de la mise à jour de la donnée transmise. Cela permet aussi la remontée d’informations terrain vers les systèmes d’information au plus proche des équipements de production en évitant une série d’intermédiaires de communication ayant pour seul intérêt de rendre ces données accessibles aux systèmes d’information. En pratique, Les automates MQTT restent assez rares pour l’instant. 

Le principe des wildcards propre au MQTT facilite l’interconnexion des systèmes. Le rôle du broker est de centraliser les informations et de les redistribuer aux systèmes intéressés. Il représente le point de convergence de toutes les transmissions MQTT. Il permet donc la mise en place d’une politique de cybersécurité tout à fait compatible avec la segmentation des réseaux. De même, le broker gère la distribution des messages limitant ainsi les échanges de données. En effet, le broker envoie un message lorsque l’information est différente du message précédent, les clients n’ont donc pas besoin de l’interroger périodiquement. Ce cas d’utilisation est de plus en plus présent aux vues des différents avantages qu’il présente. 

Très utilisé avec la technologie Lora, le MQTT permet la distribution des informations IoT transmises via LoRaWAN (protocole radio) au travers d’un réseau TCP/IP. Son organisation Objet sous forme de Topic permet de conserver la représentation d’un capteur au sein d’un réseau tout en ajoutant les avantages du cas précédent. Cette utilisation est à l’heure actuelle la plus populaire dans le cadre de la remontée d’information IoT dans le secteur industriel. 

Le MQTT centralise les échanges d’informations grâce au broker, permettant la mise en place d’une politique de cybersécurité dans le cadre d’une segmentation des réseaux terrains et des réseaux administrés tout en limitant les flux sur ces mêmes réseaux.  

Le fonctionnement sous forme de topic propose une organisation des messages intuitive grâce à son analogie « Objet » permettant la représentation des éléments physiques. Cela a pour effet de simplifier le développement de la solution ainsi que sa maintenance. 

Dans le cas de l’utilisation de réseaux avec des connexions peu fiables, le MQTT permet un stockage des messages avant leur publication vers les abonnés au rétablissement de la connexion. L’horodatage à la source assure une qualité des données ainsi qu’une fiabilité des informations. 

Découvrez la plateforme IoT SCADA PcVue qui embarque nativement les fonctionnalités MQTT pour vos applications en cliquant ici. 

ATYS CONCEPT vous accompagne sur le déploiement de solutions logicielles compatibles MQTT, LoRa ou REST pour vos applications industrielles. 

Vous avez des questions, contactez-nous.

Article rédigé par notre expert : Adam Rispail, Technicien Support Produit chez ATYS CONCEPT.