Comment MQTT s'intègre dans les architectures industrielles

Dans un récent épisode du podcast Augmented Ops, nous avons exploré le paysage des architectures industrielles IoT et le rôle que joue MQTT avec Dominik Obermaier, cofondateur et directeur technique de HiveMQ. Intitulée"Building Industrial Architectures with MQTT", la discussion avec Obermaier examine le rôle de MQTT, la manière dont il prend en charge de nouvelles architectures telles que l'espace de noms unifié (UNS) et les raisons pour lesquelles de nombreux fabricants réarchitecturent leur infrastructure numérique afin de tirer parti de ces nouvelles technologies et approches.

Depuis la création de HiveMQ à sa sortie de l'université jusqu'à sa participation au comité technique MQTT pendant plus de dix ans et à l'élaboration de la norme, M. Obermaier apporte un point de vue nuancé sur cette technologie et son application dans l'industrie manufacturière. Il invite notamment les fabricants à adopter un MQTT pour construire des infrastructures industrielles à l'échelle de l'entreprise.

M. Obermaier a retracé l'histoire de MQTT, expliquant qu'il a été développé pour la première fois en 1999 par IBM pour un projet pétrolier et gazier ( cas d'utilisation ), avant d'être ouvert à tous en 2010, ce qui a permis à quiconque de mettre en œuvre la spécification sans avoir à payer de droits d'auteur. Ce changement a donné l'élan initial à la prolifération de MQTT, qui a d'abord été utilisé dans les installations domotiques, avant de devenir un protocole de communication privilégié pour tout ce qui concerne les voitures connectées et les cas d'utilisation dans l'industrie et la fabrication. Mais qu'est-ce qui distingue exactement MQTT de la myriade d'autres protocoles contemporains tels que HTTP ou OPC UA (architecture unifiée de communication en plateforme ouverte)?

Tout d'abord, MQTT suit le modèle de communication publication/abonnement (souvent abrégé en Pub/Sub). Cela signifie que tout nœud d'une infrastructure MQTT peut publier des données à une adresse spécifique (connue sous le nom de sujet) dans un courtier central, et peut également s'abonner aux données publiées dans le courtier par d'autres nœuds. Ainsi, lorsqu'un message est publié, il est automatiquement reçu par tous les abonnés, contrairement aux protocoles qui impliquent l'interrogation permanente d'un client à intervalles réguliers pour demander des données mises à jour. Comme l'explique M. Obermaier, "cela signifie que vous découplez les producteurs de données des consommateurs de données". Les clients MQTT sont aussi généralement conçus pour "rapporter par exception", ce qui signifie qu'ils ne publient un message au courtier que lorsque les valeurs des données changent réellement.

Ceci est lié à une autre caractéristique de MQTT - sa conception légère, qui le rend particulièrement adapté aux environnements réseau contraignants que l'on trouve souvent dans les milieux industriels. Contrairement aux protocoles plus verbeux qui nécessitent une surcharge de paquets importante, MQTT utilise un format binaire pour la communication entre les clients et les courtiers, avec un en-tête fixe de seulement 2 octets, ainsi qu'un en-tête variable d'un maximum de 12 octets. Associé au rapport par exception, ce format permet de réduire considérablement le trafic réseau, ce qui rend MQTT idéal pour les applications à grande échelle qui nécessitent un débit élevé.

La clé de la prolifération de MQTT est sa simplicité. La spécification a été délibérément conçue pour "rendre sa mise en œuvre extrêmement facile pour les clients", explique M. Obermaier. Grâce à sa mise à disposition par l'organisme de normalisation MQTT, OASIS, n'importe qui peut mettre en œuvre la spécification à partir de zéro en utilisant le langage de programmation de son choix. En outre, il existe un certain nombre de bibliothèques MQTT open source dans différents langages qui simplifient encore l'utilisation de MQTT par les développeurs dans leurs projets.

Si la simplicité et la flexibilité de la spécification MQTT offrent un certain nombre d'avantages par rapport à d'autres protocoles, elles posent également un certain nombre de problèmes. Par exemple, M. Obermaier explique que "le protocole ne se soucie pas" de la structure des données envoyées, qui peuvent être du texte, des images ou toute autre donnée pouvant être transformée en binaire, jusqu'à un maximum de 256 mégaoctets. Si la flexibilité de la charge utile et de nombreux détails de la mise en œuvre rend la spécification très polyvalente, elle complique également l'interopérabilité avec divers systèmes qui peuvent tous mettre en œuvre MQTT de différentes manières.

Le simple fait de spécifier MQTT comme protocole de données souhaité ne suffit pas à garantir une interopérabilité transparente entre deux systèmes, car il ne précise pas comment les données sont encodées ni ce que la charge utile contient réellement. Bien que cette spécification soit simple à mettre en œuvre pour les producteurs de données, elle impose un fardeau plus important aux systèmes qui consomment ces données pour qu'ils les utilisent réellement. Obermaier souligne que c'est la raison pour laquelle des frameworks comme Sparkplug B ont commencé à gagner en popularité, car ils normalisent de nombreux aspects de MQTT pour faciliter l'interopérabilité.

Sparkplug B est un cadre open-source qui permet l'intégration transparente de données provenant de diverses sources de manière bidirectionnelle et interopérable en définissant des modèles cohérents pour la structure des sujets MQTT, la charge utile, la gestion de l'état, etc. M. Obermaier explique qu'en établissant une norme sur "l'aspect de la charge utile, l'aspect de la structure du sujet MQTT, etc.", des cadres comme Sparkplug ont facilité l'interopérabilité sans avoir à se préoccuper des détails de la mise en œuvre de la spécification MQTT par des systèmes disparates.

Un type d'architecture que MQTT se prête particulièrement bien à la mise en œuvre est le concept d'espace de noms unifié (UNS), qui a gagné du terrain dans l'industrie au cours des dernières années. M. Obermaier souligne que les technologies traditionnelles "fonctionnent avec des protocoles point à point, ou parfois des protocoles de bus qui ne sont pas vraiment conçus pour le mouvement de données de bout en bout au sein d'une organisation", ce qui se traduit par "de nombreux silos de données". Avec un UNS, en revanche, il y a un "hub central accessible aux OT, aux IT et aux applications", explique-t-il. Cela élimine le besoin de connexions point à point entre les nœuds, ce qui permet à quiconque d'accéder aux données de l'espace de noms et de les interroger.

Mais pourquoi utiliser MQTT ? Les exigences techniques minimales pour un SNU sont qu'il soit piloté par la périphérie (c'est-à-dire que les nœuds à la périphérie fassent un rapport au centre), qu'il fasse un rapport par exception, qu'il soit léger et qu'il soit construit sur une architecture ouverte. MQTT répond à tous ces critères, grâce à son utilisation d'un modèle de communication de type publication/abonnement, à sa capacité à signaler les exceptions, à sa faible utilisation de la bande passante et au fait que la spécification est ouverte et peut être mise en œuvre gratuitement par n'importe qui. Bien qu'il existe une forte synergie entre MQTT et UNS, M. Obermaier souligne que "l'espace de nommage unifié, pour être très clair, est un concept, ce n'est pas une technologie". Et si "Sparkplug et MQTT sont des technologies, UNS est un concept" qui peut être mis en œuvre avec un certain nombre de technologies de messagerie différentes.