Aujourd'hui j'ai choisi d'aborder un sujet souvent évoqué par nos clients et intégrateurs, et qui reste encore sans réponse concrète. L'Internet Industriel des Objets fait appel à de nouveaux protocoles de communication et qui plus est, à de nouvelles architectures techniques. L'enjeux pour les industriels que je rencontre est de bien comprendre :
Je vais donc essayer avec cet article de vous aider à faire la lumière sur MQTT et OPC-UA, pourquoi l'un plus que l'autre… ou pourquoi l'un ou/et l'autre ?
Les questions que l'on observe sont : "Dois-je utiliser OPC-UA ou MQTT ?", "Quelle est la différence entre Pub/Sub et Client/Server ?"
Si vous recherchez de la performance avec une bande passante très limitée, le protocole MQTT utilisant une méthode de Publication/Souscription est beaucoup plus efficace qu'un protocole avec des méthodes de double vérifications (hand shaking) de type Client/Serveur. OPC-UA Part 14 définit une architecture Pub/Sub pour les communications réseaux LAN et WAN. En fonction des architectures, différents challenges sont à anticiper :
En clair, le sujet n'est pas OPC-UA versus MQTT... Les 2 protocoles peuvent trouver leur place dans une architecture qui se complète.
MQTT est un protocole léger, basé sur une architecture mettant en œuvre un broker de messages où le "payload" est totalement spécifique à l'application. Il est donc dans ce contexte indispensable que chaque application puisse décoder ce fameux "payload" pour en exploiter les données. Une caractéristique qui peut avoir certains inconvénients si beaucoup d'applications/objets connectés à faire communiquer sont différents.
OPC-UA est en synthèse le remplaçant moderne de l'OPC-DA. C'est une architecture où le protocole de communication n'est qu'un des composants adressé par le standard. Une application avec une couche OPC-UA est capable d'exposer ses données à tous les équipements et systèmes d'un réseau meshé, le tout sous un format orienté objet. La communication actuelle est basée sur une méthode client/serveur où le serveur expose un ensemble de services standards permettant de naviguer au sein des objets, lire et écrire des données, appeler des méthodes ou encore souscrire pour des modifications de données ou événements. OPC-UA peut utiliser TCP ou SOAP. C'est un protocole indépendant des plateformes hardware et software, il fonctionne aussi bien sous Windows que Linux - ou même sur un chipset embarqué. En clair, fini les DCOM Windows de l'OPC-DA.
OPC-UA et MQTT ont tous les deux une couche de sécurité intégrée, un critère très important à l'ère du tout connecté.
Voici quelques éléments de comparaison sur les 2 protocoles ici mis en comparaison :
| OPC-UA | MQTT | |
| Communication | TCP, UDP | TCP |
| Patterns | RPC, Pub/Sub | Pub/Sup |
| QoS | No | Yes |
| Authentification | User, PKI | User, PKI |
| Encryption | Yes | Yes |
| Standard API | No | No |
| Semantic Data | Yes | No |
Finalement en regardant de plus près MQTT et OPC-UA il devient très difficile de les comparer - en tout cas de les mettre au même niveau. En effet, OPC définit la structure de la communication, comme peut l'être un service Web REST par exemple. De l'autre côté MQTT est davantage un moyen de transport de la donnée, au même titre que HTTP.
Dans l'exemple ci-dessous, nous mettons en œuvre une architecture avec un échange de données via MQTT. Le broker MQTT, hébergé sur un serveur - On-Premise ou Cloud - permet à tous les systèmes de communiquer entre eux. Ainsi un équipement peut publier ou souscrire à une donnée - de manière verticale (entre les machines équipées d'InTouch Edge et System Platform) ou de manière horizontale (sous forme de communication M2M, mais sans relation point à point via une table d'échanges par exemple).
Dans la nouvelle version des OI Server Wonderware propose la fonction de Store & Forward permettant en cas de rupture de communication avec le broker, de stocker en local les données - qui seront restituées ultérieurement avec leurs horodatages à la source.