La place de MQTT dans les architectures industrielles

Dans un épisode récent du podcast « Augmented Ops », nous avons exploré le paysage des architectures IoT industrielles et le rôle joué par le protocole MQTT avec Dominik Obermaier, cofondateur et directeur technique de HiveMQ. Intitulée «Construire des architectures industrielles avec MQTT », cette discussion avec M. Obermaier examine le rôle de MQTT, la manière dont il prend en charge de nouvelles architectures telles que l’Unified Namespace (UNS), et les raisons pour lesquelles de nombreux fabricants repensent leur infrastructure numérique afin de tirer parti de ces nouvelles technologies et approches.

Depuis la création de HiveMQ dès la fin de ses études universitaires, jusqu’à sa participation au comité technique MQTT pendant plus d’une décennie et à sa contribution à l’élaboration de la norme, M. Obermaier apporte un éclairage nuancé sur cette technologie et son application dans le secteur industriel. Il invite notamment les industriels à adopter le protocole MQTT pour mettre en place des infrastructures industrielles à l’échelle de l’entreprise.

M. Obermaier a retracé l’histoire du protocole MQTT, expliquant qu’il avait été initialement développé en 1999 par IBM pour un cas d'utilisation dans le secteur pétrolier et gazier, cas d'utilisation d’être open source en 2010, ce qui a permis à quiconque de mettre en œuvre la spécification sans avoir à s’acquitter de redevances. Ce changement a donné l’élan initial à la prolifération du protocole MQTT, qui a d’abord été utilisé dans les installations domotiques, avant de devenir le protocole de communication privilégié pour des applications aussi variées que les voitures connectées, l’industrie et la fabrication. Mais qu’est-ce qui distingue exactement le protocole 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 (appelée « sujet ») au sein d’un courtier central, et peut également s’abonner aux données publiées sur ce courtier par d’autres nœuds. Il en résulte que lorsqu’un message est publié, il est automatiquement reçu par tous les abonnés — contrairement aux protocoles qui impliquent d’interroger en continu un client à intervalles réguliers pour demander des données mises à jour. Comme l’explique M. Obermaier, « cela signifie que vous dissociez les producteurs de données des consommateurs de données ». Les clients MQTT sont également généralement conçus pour fonctionner selon le principe du « signalement par exception », ce qui signifie qu’ils ne publient un message vers le courtier que lorsque les valeurs des données changent réellement.

Cela rejoint une autre caractéristique distinctive du protocole MQTT : sa conception légère, qui le rend particulièrement adapté aux environnements réseau aux ressources limitées que l'on retrouve souvent dans les milieux industriels. Contrairement à des protocoles plus verbaux qui nécessitent une surcharge importante au niveau des paquets, MQTT utilise un format binaire pour la communication entre les clients et les brokers, avec un en-tête fixe de seulement 2 octets, ainsi qu'un en-tête variable de 12 octets au maximum. Associé au principe de « rapport par exception », cela se traduit par une réduction significative du trafic réseau, ce qui fait de MQTT la solution idéale pour les applications à grande échelle nécessitant un débit élevé.

La clé de l’essor du protocole MQTT réside dans sa simplicité. La spécification a été délibérément conçue pour « faciliter au maximum sa mise en œuvre par les clients », explique M. Obermaier. Grâce à sa mise à disposition en libre accès 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. De plus, il existe un certain nombre de bibliothèques MQTT open source dans divers langages qui facilitent encore davantage l’utilisation de MQTT par les développeurs dans leurs projets.

Si la simplicité et la flexibilité de la spécification MQTT offrent de nombreux avantages par rapport à d’autres protocoles, elles posent également un certain nombre de défis. Par exemple, M. Obermaier explique que « le protocole ne se soucie pas » de la structure des données envoyées — celles-ci pouvant aller du texte aux images, en passant par toute autre donnée pouvant être convertie en format binaire, jusqu’à un volume impressionnant de 256 mégaoctets. Si la flexibilité en matière de charge utile et de nombreux détails de mise en œuvre rend la spécification très polyvalente, elle complique également la garantie de l’interopérabilité avec divers systèmes qui peuvent chacun implémenter MQTT de manière différente.

Le simple fait de spécifier MQTT comme protocole de données souhaité ne suffit pas à garantir une interopérabilité parfaite entre deux systèmes, car cela ne précise pas comment les données sont encodées ni ce que contient réellement la charge utile. Et si cela rend la spécification simple à mettre en œuvre pour les producteurs de données, cela impose en revanche une charge plus importante aux systèmes qui les consomment pour pouvoir réellement exploiter ces données. M. Obermaier avance cette raison pour expliquer pourquoi des frameworks tels que Sparkplug B ont commencé à gagner en popularité, car ils normalisent de nombreux aspects de MQTT afin de faciliter considérablement l’interopérabilité.

Sparkplug B est un framework 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 des états, etc. M. Obermaier explique qu’en établissant une norme concernant « la forme que doit prendre la charge utile, la structure des sujets MQTT, etc. », des frameworks tels que Sparkplug ont facilité la mise en place de l’interopérabilité sans qu’il soit nécessaire de se soucier des détails relatifs à la manière dont la spécification MQTT est mise en œuvre par des systèmes disparates.

L’architecture pour laquelle MQTT se prête particulièrement bien est le concept d’espace de noms unifié (UNS), qui a gagné en popularité dans l’ensemble du secteur ces 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 transfert de données de bout en bout au sein d’une organisation », ce qui entraîne « de nombreux silos de données ». Avec un UNS, en revanche, il existe un « hub central accessible aux équipes OT, aux équipes informatiques et aux applications », explique-t-il. Cela élimine le besoin de connexions point à point entre les nœuds, permettant ainsi à 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 UNS sont les suivantes : il doit être piloté depuis la périphérie (c'est-à-dire que les nœuds périphériques transmettent leurs informations au hub central), fonctionner selon le principe de la notification par exception, être léger et reposer sur une architecture ouverte. MQTT répond à tous ces critères, grâce à son modèle de communication de type « publication/abonnement », à sa capacité à fonctionner selon le principe de la notification par exception, à sa faible consommation de bande passante et au fait que sa 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 l’UNS, M. Obermaier souligne que « l’Unified Namespace, pour être très clair, est un concept, et non une technologie ». Et tandis que « Sparkplug et MQTT sont des technologies, l’UNS est un concept » pouvant être mis en œuvre à l’aide de différentes technologies de messagerie.