Si vous consacrez du temps à l’IoT industriel, vous avez entendu à maintes reprises le même débat. Devrions-nous utiliser MQTT ou OPC UA ? La question est formulée comme une compétition, comme si un protocole devait gagner et l'autre devait perdre. En pratique, cette formulation est erronée. MQTT et OPC UA ont été conçus pour résoudre des problèmes fondamentalement différents, et la plupart des architectures IIoT de production finissent par utiliser les deux, souvent en même temps, sur la même passerelle.
Cet article explique ce que chaque protocole fait réellement bien, où il échoue et comment décider lequel appartient à quel côté de votre pipeline de données.
TL;DR
- MQTT déplace les octets. Il s'agit d'un transport léger pour la messagerie de publication/abonnement, indépendant de la charge utile et idéal pour les réseaux contraints et la télémétrie cloud.
- OPC UA change de sens. Il s'agit d'un cadre complet de modélisation des informations avec sécurité, données sémantiques et découvrabilité intégrées, conçu pour l'interopérabilité entre les usines.
- Ils ne s'excluent pas mutuellement. OPC UA PubSub (partie 14) peut fonctionner sur MQTT, vous offrant ainsi des données sémantiques en plus d'un pub/sub léger.
- Une passerelle IIoT typique parle OPC UA (ou Modbus, EtherNet/IP, S7) du côté sud, puis publie vers les courtiers MQTT du côté nord.
Deux origines différentes, deux mentalités différentes
MQTT est né en 1999 chez IBM, conçu par Andy Stanford-Clark et Arlen Nipper pour surveiller les oléoducs via des liaisons satellite. Les contraintes ont tout façonné : supposons que le réseau soit lent, coûteux et peu fiable ; supposons que l'appareil est petit ; garder l'en-tête du protocole microscopique ; laissez l'application décider quoi mettre dans la charge utile. Deux décennies plus tard, MQTT 3.1.1 est devenu une norme ISO (ISO/IEC 20922) et MQTT 5 a ajouté des fonctionnalités attendues par les architectures cloud modernes : propriétés utilisateur, expiration des messages, abonnements partagés, codes de motif.
OPC UA est né d’un monde différent. La Fondation OPC a publié la première spécification en 2008 en tant que successeur d'OPC Classic (OLE pour Process Control), qui avait lié l'industrie à Microsoft DCOM. Le mandat était de rompre cette dépendance tout en résolvant un problème plus difficile : comment faire pour qu'un automate Siemens, un contrôleur de mouvement Beckhoff, un servomoteur B&R et un Rockwell DCS se comprennent sémantiquement, et ne se contentent pas d'échanger des octets bruts ? La réponse d'OPC UA a été un modèle d'information : un espace d'adressage auto-descriptif dans lequel les données ont des types, des relations et une signification.
Ces histoires d’origine expliquent presque toutes les décisions de conception qui suivent.
Architecture
MQTT est centré sur le courtier et découplé. Les éditeurs envoient des messages aux sujets. Les abonnés manifestent leur intérêt pour les sujets. Un courtier central répartit le trafic. Les éditeurs et les abonnés ne se connaissent jamais directement. Le courtier peut être une petite instance Mosquitto intégrée ou un déploiement HiveMQ en cluster gérant des millions de clients – le protocole s'en fiche.
OPC UA était à l'origine client-serveur. Un client ouvre une session avec un serveur, puis émet des services : Browse pour explorer l'espace d'adressage, Read et Write pour accéder aux valeurs des nœuds, CreateSubscription pour être informé des modifications. Le serveur est avec état et fait autorité. Cela fonctionnait bien sur un réseau local, mais ne s'adaptait pas à une diffusion de type cloud.
OPC UA Part 14 a ajouté PubSub en 2018, prenant en charge à la fois les transports basés sur un courtier (MQTT, AMQP) et ceux sans courtier (multidiffusion UDP). C'était la reconnaissance par la fondation que le monde était passé d'un mode purement client-serveur.
Protocol selection by design axis
bar chartModèles de données
C’est là que les deux protocoles divergent le plus fortement.
MQTT est indépendant de la charge utile. Un corps de message peut être JSON, Protobuf, CBOR, binaire brut, JPEG ou texte brut. Le protocole le porte mais ne l’interprète pas. Votre hiérarchie de sujets (factory/line-3/oven/temperature) est une convention de dénomination que vous inventez et appliquez vous-même. Si un abonné a besoin de savoir que la « température » est en degrés Celsius et varie de 0 à 400, cette connaissance se trouve en dehors du protocole – dans la documentation, dans un contrat, dans un registre de schémas.
OPC UA est intensément structuré. Chaque nœud dans l'espace d'adressage a un NodeId, un BrowseName, un DataType, une Value et des références à d'autres nœuds. Les spécifications associées superposées – PLCopen pour la logique de contrôle, Auto-ID pour les lecteurs RFID, MachineTool, Pump, Robotics, Weihenstephan pour les brasseries – définissent à quoi ressemble une « pompe » ou une « MachineTool » en termes OPC UA. Un client qui n'a jamais vu votre appareil peut se connecter, parcourir l'espace d'adressage, découvrir ce qui est disponible et comprendre la sémantique de chaque valeur sans aucun accord préalable.
Cette capacité (connexion et découverte avec une sémantique complète) est la fonctionnalité phare d'OPC UA. C'est aussi ce qui le rend plus lourd.
Sécurité
MQTT s'appuie sur TLS pour le chiffrement du transport, le nom d'utilisateur/mot de passe ou les certificats client pour l'authentification et les ACL au niveau du courtier pour l'autorisation. Le modèle de sécurité réside chez le courtier. Différents courtiers implémentent l'autorisation différemment et il n'existe pas de moyen standard d'exprimer des autorisations précises dans le protocole lui-même.
OPC UA intègre une sécurité cryptographique dans la couche de messages. Certificats X.509 pour le client et le serveur, politiques de sécurité configurables (« Basic256Sha256 », « Aes256_Sha256_RsaPss »), signature et chiffrement par message, authentification utilisateur distincte de l'authentification des applications et contrôle d'accès basé sur les rôles défini dans la partie 18. Pour les environnements qui doivent démontrer leur conformité à la norme CEI 62443 ou NERC CIP, OPC UA vous fournit des primitives qui correspondent directement aux normes.
C'est l'un des arguments les plus forts en faveur d'OPC UA dans les usines : le modèle de sécurité a été conçu dès le premier jour pour les systèmes de contrôle industriels.
Bande passante et surcharge
Le paquet minimum de MQTT est de 2 octets d'en-tête fixe plus un en-tête et une charge utile variables. Une « PUBLISH » d'un flottant de 4 octets vers un sujet court fait moins de 20 octets sur le fil. QoS 0 (activer et oublier), 1 (au moins une fois) et 2 (exactement une fois) vous permettent d'échanger la fiabilité contre la bande passante.
OPC UA Binary est plus verbeux. Une simple notification d’élément surveillé peut comporter entre 50 et 100 octets. Les sessions, les abonnements et les jetons de sécurité ajoutent tous une surcharge de gestion d'état. Le protocole a été conçu pour le débit LAN et non pour la bande passante cellulaire. OPC UA sur HTTPS/SOAP (l'ancienne liaison XML) était vraiment lourd et est désormais rarement utilisé.
OPC UA PubSub sur MQTT ou UDP réduit considérablement la surcharge, notamment avec l'encodage JSON ou binaire UADP. Pour les nouvelles conceptions qui nécessitent à la fois une structure sémantique et une efficacité de bande passante, cette combinaison est de plus en plus la bonne réponse.
Découvrabilité
Branchez un client MQTT sur un courtier que vous n'avez jamais vu. Que pouvez-vous faire ? Vous pouvez vous abonner à « # » (tout avec caractère générique) et observer le flux du trafic, puis essayer de procéder à une rétro-ingénierie de la hiérarchie des sujets et du format de charge utile. C'est votre seule option sans documentation externe.
Branchez un client OPC UA sur un serveur que vous n'avez jamais vu. Vous pouvez parcourir l'intégralité de l'espace d'adressage, inspecter les types de données, lire les valeurs historiques, voir quelles méthodes sont appelables et identifier si le serveur implémente une spécification compagnon connue. Le protocole est fondamentalement introspectable.
Pour les systèmes qui évoluent fréquemment (où des machines sont ajoutées, retirées ou reconfigurées), cela est important. Les clients OPC UA s'adaptent automatiquement. Les clients MQTT ont besoin de mettre à jour leurs contrats hors bande.
Quand utiliser MQTT
MQTT est le bon choix lorsque :
- Vous envoyez des données télémétriques depuis des appareils périphériques vers le cloud, en particulier via des liaisons cellulaires, satellite ou autres liaisons à bande passante limitée.
- Vous avez de nombreux éditeurs et de nombreux abonnés et vous avez besoin d'un lien lâche entre eux.
- Vous intégrez des plateformes IoT hyperscaler (AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ Cloud) – elles parlent toutes nativement MQTT.
- Vous contrôlez le format de charge utile de bout en bout et n’avez pas besoin d’interopérabilité sémantique entre fournisseurs.
- Vous avez besoin d’une petite empreinte client sur des microcontrôleurs aux ressources limitées.
- Vous reliez les données OT aux systèmes informatiques (Kafka, bases de données de séries chronologiques, outils de business intelligence).
Quand utiliser OPC UA
OPC UA est le bon choix lorsque :
- Vous lisez des données provenant d'automates et de contrôleurs de mouvement dans l'usine. La plupart des principaux fournisseurs — Siemens (S7-1500), Beckhoff (TwinCAT), B&R (Automation Studio), Rockwell, ABB — embarquent des serveurs OPC UA dans leurs contrôleurs.
- Vous avez besoin d'une interopérabilité sémantique entre les équipements de différents fournisseurs sans écrire d'adaptateurs personnalisés pour chacun.
- Vous évoluez dans un environnement réglementé (pharmaceutique, automobile, aérospatial) où la provenance et la sécurité des données sont importantes.
- Votre structure de données évoluera avec le temps et les clients devront s'adapter sans recompilation.
- Vous implémentez une spécification compagnon connue (Weihenstephan pour les brasseries, Euromap pour les machines pour la plasturgie, Umati pour les machines-outils).
- Vous avez besoin d'une prise en charge intégrée pour l'accès historique, les alarmes, les conditions et les méthodes (fonctions appelables).
Le modèle hybride : OPC UA au sud, MQTT au nord
La plupart des passerelles IIoT modernes, y compris le Modibus MB213, implémentent ce qui est essentiellement une couche de traduction. Du côté sud (vers le terrain), la passerelle parle les protocoles parlés par les appareils de terrain : Modbus RTU et TCP, OPC UA Client to PLCs, EtherNet/IP, Siemens S7, BACnet pour l'automatisation des bâtiments. Du côté nord (vers le cloud ou l'entreprise), il publie sur des courtiers MQTT, souvent avec des certificats TLS et clients, en utilisant souvent Sparkplug B pour la structure de la charge utile.
Ce modèle fonctionne parce que les exigences de chaque côté sont différentes. L’usine a besoin de déterminisme, de découvrabilité et d’une sémantique standardisée – le territoire OPC UA. Le chemin vers le cloud nécessite une bande passante efficace, un couplage lâche et un large support d'écosystème – le territoire MQTT. La passerelle est l'endroit où la traduction a lieu.
Sparkplug B : MQTT avec sémantique
La plus grande faiblesse de Vanilla MQTT est le manque de structure de charge utile. Sparkplug B, une spécification Eclipse Foundation développée par Cirrus Link, répond à ce problème. Il définit :
Sparkplug B ne correspond pas à la profondeur sémantique d'OPC UA : il n'y a pas de spécifications associées, pas de méthodes, pas de modèle d'alarmes et de conditions. Mais il est considérablement plus léger qu’OPC UA et constitue la solution idéale pour de nombreux cas d’utilisation de la télémétrie dans le cloud.
- Un espace de noms de sujet standardisé (spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id})
- Actes de naissance et de décès afin que les abonnés sachent quelles mesures un éditeur propose et quand il se déconnecte
- Définitions de métriques fortement typées avec unités d'ingénierie, mise à l'échelle et état historique
- Numérotation séquentielle pour détecter la perte de message
OPC UA PubSub sur MQTT
Si vous souhaitez bénéficier de la richesse sémantique d'OPC UA mais de l'efficacité du transport de MQTT, OPC UA PubSub sur MQTT (Partie 14) est de plus en plus le modèle recommandé pour les nouvelles conceptions. L'éditeur sérialise les messages OPC UA à l'aide du codage binaire UADP ou du codage JSON et les publie dans des sujets MQTT. Les abonnés reçoivent des données OPC UA entièrement typées sans la surcharge liée à l'établissement de session.
Le compromis : la maturité des outils est inférieure à celle du client-serveur vanilla MQTT ou OPC UA. Tous les courtiers, toutes les plateformes cloud et tous les systèmes SCADA ne gèrent pas encore OPC UA PubSub correctement. Attendez-vous à ce que cela s’améliore rapidement au cours des deux à trois prochaines années.
Cadre décisionnel
En cas de doute, posez trois questions :
Où se trouvent les données et où doivent-elles aller ? D'une usine à l'autre : OPC UA. De l'usine au cloud : MQTT (ou OPC UA PubSub sur MQTT). Cloud à cloud : MQTT.
Qui contrôle le schéma ? Si vous contrôlez à la fois l'éditeur et l'abonné, MQTT ainsi qu'un format de charge utile documenté fonctionnent. Si vous avez besoin d’une interopérabilité entre fournisseurs sans accords bilatéraux, OPC UA.
Quel est le budget bande passante ? Cellulaire, LPWAN ou satellite : optez pour MQTT. LAN filaire sans contraintes : OPC UA convient parfaitement.
| Préoccupation | MQTT | OPC UA |
|---|---|---|
| Taille de la charge utile | Minime | Supérieur |
| Sémantique intégrée | Non | Oui |
| Découvrabilité | Non | Oui |
| Écosystème cloud | Excellent | Limité |
| Adoption au niveau de l'usine | Croissance | Dominante |
| Modèle de sécurité | Transports (TLS) | Messages + Transports |
| Spécifications du compagnon | Non (bougie B la plus proche) | Beaucoup |
| Meilleur ajustement | Télémétrie, pontage des nuages | Interopérabilité, systèmes de contrôle |
Pensée finale
La réponse honnête à « MQTT ou OPC UA ? » » est presque toujours « les deux, à des endroits différents ». MQTT est le bon outil pour déplacer efficacement les octets sur les réseaux. OPC UA est l'outil idéal pour faire évoluer le sens entre les fournisseurs. Une architecture IIoT bien conçue utilise chacun d’entre eux là où ses points forts correspondent au problème auquel elle est confrontée.
C’est précisément la raison pour laquelle les passerelles industrielles existent : pour rendre la frontière entre ces deux mondes propre, sécurisée et observable.
Modibus MB213 prend en charge MQTT (avec TLS, Sparkplug B et QoS configurable) et OPC UA (rôles client et serveur) prêts à l'emploi, aux côtés de Modbus RTU/TCP et d'autres protocoles industriels. Pour discuter d'une architecture spécifique, [contactez-nous](https://modibus.com).