OPC UA vs MQTT ou OPC UA via MQTT?

MQTT est un protocole réseau léger de type Publisher/Subscriber « PubSub » (publication/abonnement) basé sur TCP/IP qui transporte des messages entre des équipements (logiciels ou matériels). Il a été conçu pour permettre la récupération de données issues d’équipements distants disposant d’une faible connectivité réseau, par conséquent le volume de data à échanger et la consommation d’énergie pour l’émission des messages sont optimisés (pour plus d’info sur le MQTT, voir notre article).

OPC UA est un protocole de communication multiplateforme orienté services, ouvert et sécurisé. Il est conçu pour permettre l’interopérabilité des équipements, systèmes et applications logicielles d’automatismes industriels quels que soient les constructeurs. OPC UA est basé sur l’utilisation de modèles d’information qui définissent l’encodage des données ainsi que le format des données pouvant être transportées de différentes façons, avec différents protocoles. Utilisé fréquemment en architecture Client/Serveur, il supporte aussi le fonctionnement PubSub. (pour plus d’info sur OPC UA, voir notre article).

OPC UA via MQTT est l’un des protocoles prenant en charge la spécification PubSub d’OPC UA. Il vise à définir comment transporter les modèles d’information OPC UA à l’aide du protocole de transport MQTT.

Prosys OPC UA Forge est une plateforme Edge qui facilite l’intégration OT/IT et supporte OPC UA, MQTT et OPC UA via MQTT. Forge permet de réduire la complexité des échanges ainsi que l’harmonisation des données grâce à des fonctionnalités de logique métier simples et une configuration simplifiée de la connectivité cloud.

MQTT ou OPC UA ? Les comparaisons faites entre MQTT et OPC UA sont souvent biaisées et ne reflètent pas exactement la réalité, parce que la question reviendrait finalement à comparer des camions et des palettes (alors que l’un sert à transporter l’autre). En effet, MQTT est un moyen de transférer des messages d’un endroit à un autre, tandis qu’OPC UA vise davantage à normaliser le format des messages (transportés par une méthode de transfert).

Commençons par rappeler qu’OPC UA est une communication bidirectionnelle de type Client/Serveur tandis que MQTT est une communication unidirectionnelle. Si vous avez besoin d’une réponse à votre appel dans OPC UA, votre client l’obtient automatiquement, alors que dans MQTT, vous devez le faire de manière asynchrone avec un code personnalisé.

Une autre différence est que OPC UA dispose d’une sécurité intégrée, chaque connexion Client/Serveur est authentifiée et chiffrée indépendamment, garantissant ainsi une sécurité de bout en bout. Dans MQTT, vous devez implémenter la sécurité vous-même, difficulté qui croît avec le nombre de publishers et de susbscribers. En effet, MQTT propose par défaut une sécurité seulement au niveau du transport : toutes les communications entre les applications et le broker MQTT sont chiffrées, mais tous les abonnés connectés au broker peuvent lire toutes les données disponibles. Pour renforcer la sécurité, vous devrez utiliser les outils disponibles dans le broker MQTT.

Le décodage du payload est très différent entre OPC UA et MQTT (le payload désigne la partie des informations transmises dans le message) : le payload OPC UA est standardisé de telle sorte que tout client OPC UA disposant de fonctions de browsing et d’abonnement peut être configuré pour lire et écrire dans n’importe quel serveur OPC UA, tandis que dans MQTT, le payload n’a pas de format spécifique et est défini par le fabricant, obligeant la mise en œuvre du décodage du payload par le subscriber (l’abonné).

L’arborescence des « topics » MQTT, en particulier lorsqu’aucun chiffrement n’est utilisé, offre un moyen simple de configuration automatique. L’espace d’adressage OPC UA permet également la configuration automatique, même lorsque le transport de données est chiffré, mais nécessite davantage d’expertise et d’efforts de la part du programmeur.

L’intégration d’une couche de communication MQTT est plus rapide à mettre en œuvre qu’une couche de communication OPC UA qui nécessite notamment la prise en compte des acquittements des échanges et la gestion des différents types d’objet.

Enfin, MQTT s’adapte à des millions de valeurs et des millions de publishers tandis que les clients OPC UA peuvent facilement se connecter à des centaines de serveurs et à des dizaines de milliers de nœuds.

Symbolique de OPC UA via MQTT

On préfèrera OPC UA Client/Serveur à MQTT lorsqu’il s’agira d’intégrer des sources de données OT à  IT (typiquement ERP et MES) car celles-ci reposent majoritairement sur des échanges synchrones (cas d’échanges avec des automates). On tirera profit du MQTT et de sa configuration automatique facile lorsqu’il s’agira de publier des données OT vers l’informatique Cloud (alimentation de données en masse, Data Lake, Big data). Néanmoins, OPC UA via MQTT est pertinent dans les deux cas car il permet de combiner l’utilisation de payloads standardisés (ceux d’OPC UA) et les avantages du principe d’échange MQTT.  

Prosys OPC UA Forge est une application middleware qui, parmi ses diverses fonctionnalités, permet la conversion entre OPC UA Client/Server et OPC UA via MQTT. Bien que le cas d’utilisation le plus courant implique la publication de données depuis des serveurs OPC UA vers le Cloud à l’aide d’OPC UA via MQTT, la conversion peut également être effectuée dans le sens inverse. Cela permet d’écrire des données publiées sur le broker MQTT pour définir des points ou d’autres variables dans un serveur OPC UA.

Pour une communication sécurisée déterministe entre MES, SCADA et automates, par exemple, il ne semble pas qu’il y aura à l’avenir de bonnes alternatives à OPC UA. En effet, dans ces cas d’utilisation, vous voulez être sûr d’avoir établi une communication et d’obtenir un accusé de réception synchrone indiquant que votre opération d’écriture a réussi.

Pour tester Prosys OPC UA Forge :  TELECHARGEZ LA VERSION D’ESSAI

Article original rédigé par Pyry Grönholm, CEO de Prosys OPC, éditeur de Forge : https://prosysopc.com/blog/opc-ua-vs-mqtt/