MQTT dans l'industrie manufacturière : pourquoi le protocole de l'Internet des objets s'est imposé sur le plancher de production

Points clés

• MQTT est un protocole de messagerie léger en publication/abonnement. À l'origine conçu pour la télémétrie à faible bande passante, il est désormais présent partout dans l'industrie manufacturière.
• Il découple les émetteurs (automates programmables, PLC, capteurs, machines) des abonnés (plateformes OEE, cloud, outils d'analyse) via un broker.
• Le modèle standard dans les ateliers modernes est Sparkplug B, une spécification MQTT qui ajoute la modélisation des données, les messages de naissance et de disparition, et le suivi d'état.
• MQTT s'adapte à des milliers d'appareils avec une bande passante minimale, ce qui explique pourquoi les solutions IIoT en périphérie l'ont adopté.
• Il complète OPC UA, il ne le remplace pas. De nombreuses architectures utilisent les deux.

En bref: MQTT est un protocole de messagerie publication/abonnement conçu pour l'IoT à faible bande passante mais adopté à grande échelle dans l'industrie car il découple les producteurs de données (machines) des consommateurs de données (plateformes OEE, cloud, outils d'analyse).

Les déploiements industriels modernes utilisent la spécification Sparkplug B au‑dessus de MQTT pour ajouter la modélisation des données et le suivi d'état dont le MQTT brut est dépourvu. MQTT et OPC UA répondent à des problématiques qui se chevauchent; de nombreuses architectures utilisent les deux.

Voir aussi OEE pour la fabrication par lots .

Qu'est‑ce que MQTT

MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie publication/abonnement inventé en 1999 chez IBM pour la télémétrie dans le secteur pétrolier et gazier à faible bande passante. L'architecture est simple :

• Émetteurs publient des messages sur des topics (canaux nommés) sur un broker.
• Abonnés demandent au broker les messages des topics qui les intéressent.
• Broker achemine les messages des émetteurs vers les abonnés sans que l'un ou l'autre se connaissent.

Le découplage est la valeur ajoutée. Un automate publie son état de fonctionnement sur un topic ; quiconque s'abonne reçoit les données. L'automate ne sait pas et ne se soucie pas de qui est le consommateur.

Pourquoi MQTT s'est imposé pour la télémétrie industrielle

Trois raisons :

• Efficacité en bande passante. Faible surcharge des messages, connexions persistantes, poignée de main minimale. Fonctionne sur réseaux cellulaires et réseaux contraints.
• Scalabilité. Un seul broker peut gérer des milliers d'appareils publiant simultanément.
• Découplage. Ajouter ou supprimer des abonnés sans toucher aux sources de données. Essayez de faire ça avec des intégrations point à point.

Pour une plateforme OEE consommant des données de plus de 50 machines dans une usine, MQTT est un choix naturel. Un broker, de nombreux émetteurs, de nombreux abonnés.

Pourquoi le MQTT brut n'est pas suffisant

Le MQTT brut n'impose aucun format pour le contenu des messages. Un automate publiant « 423 » sur le topic « line5/cycle » va bien jusqu'à ce que deux automates différents utilisent des conventions de topics, des unités ou des formats de message différents. L'intégration devient un casse‑tête.

La solution est Sparkplug B, une spécification ouverte au‑dessus de MQTT qui ajoute :

• Un espace de noms de topics standard (groupe/nœud périphérique/appareil/métrique).
• Des messages de naissance et de disparition pour que les abonnés sachent quand un appareil se connecte ou se déconnecte.
• Le suivi d'état et la persistance des valeurs (le broker conserve la dernière valeur connue).
• Un typage fort des métriques (int, float, boolean, datetime).

La plupart des déploiements industriels MQTT modernes utilisent Sparkplug B. Le MQTT brut fonctionne pour des projets greenfield avec une discipline stricte des topics mais ne monte que rarement en charge.

MQTT vs OPC UA

Ils se chevauchent mais résolvent des problèmes différents :

• MQTT est publication/abonnement, basé sur un broker, léger, idéal pour la télémétrie entre de nombreux émetteurs et de nombreux abonnés à grande échelle.
• OPC UA est client‑serveur (avec pub/sub optionnel), point à point, structuré, idéal pour des échanges de données fiables avec typage fort et sécurité.

De nombreuses architectures modernes utilisent les deux : OPC UA pour les échanges de données structurées au niveau de la ligne (automate vers passerelle), MQTT/Sparkplug B pour la télémétrie à grande échelle de la passerelle vers le cloud ou la plateforme OEE centrale.

Ce que signifie « espace de noms unifié » et pourquoi MQTT le permet

L'espace de noms unifié (UNS) est un modèle architectural où chaque système publie sur un broker MQTT partagé unique. Le broker devient la source unique de vérité pour toutes les données temps réel de l'usine. ERP, MES, plateforme OEE, historien, outils d'analyse, ils s'abonnent tous aux topics dont ils ont besoin sans intégrations point à point.

L'UNS remplace la hiérarchie rigide PLC → SCADA → MES → ERP par un bus plat en publication/abonnement. Il convient particulièrement aux transformations numériques greenfield et à la modernisation « lift‑and‑shift » d'usines avec des SCADA hérités.

Ce que cela signifie pour le choix d'une plateforme OEE

• La plateforme OEE prend‑elle en charge MQTT nativement ?
• Prend‑elle en charge Sparkplug B (et pas seulement le MQTT brut) ?
• Peut‑elle fonctionner sur site avec un broker existant ?
• Peut‑elle fonctionner comme émetteur (publier les valeurs OEE calculées) en plus d'être abonnée ?

Pour les PME manufacturières sans broker existant, l'OPC UA seul est souvent plus simple. Pour les opérations de plus grande taille ou multi‑sites, MQTT + Sparkplug B l'emporte généralement en termes de scalabilité à long terme.

Le module OEE de Fabrico prend en charge à la fois OPC UA et MQTT/Sparkplug B comme sources de données, et peut republier les métriques OEE calculées sur MQTT pour les consommateurs en aval.

Découvrez comment Fabrico capture cela automatiquement, explorez l'OEE pour la fabrication ou réservez une démo.

Lectures connexes

• OEE pour la fabrication par lots
• Diagramme de Pareto en fabrication
• KPI vs OKR en fabrication
• Lac de données vs entrepôt de données pour la fabrication

Questions fréquentes

Dois‑je utiliser MQTT ou OPC UA pour l'OEE ?

Pour la plupart des usines PME, OPC UA suffit et est plus simple. Pour les opérations multi‑sites ou les stratégies d'espace de noms unifié, MQTT/Sparkplug B est un meilleur choix à long terme.

Qu'est‑ce que Sparkplug B ?

Une spécification ouverte au‑dessus de MQTT qui ajoute une nomenclature standard des topics, des messages de naissance et de disparition, le suivi d'état et des métriques typées. La norme de facto pour le MQTT industriel.

Ai‑je besoin d'un broker séparé ?

Oui. MQTT est construit autour d'un broker. Choix courants : HiveMQ, EMQX, Mosquitto (open source), ou des brokers cloud (AWS IoT, Azure IoT Hub).

MQTT est‑il sécurisé ?

Oui, avec chiffrement TLS et authentification. Un MQTT anonyme et non chiffré en production n'est pas sûr.

Comment MQTT se compare‑t‑il à REST/HTTP pour la télémétrie ?

MQTT est beaucoup plus efficace pour la télémétrie continue. HTTP convient pour des appels d'API occasionnels. Pour des données machine circulant toutes les quelques secondes à travers des milliers d'appareils, MQTT l'emporte de manière décisive.