Qu'est-ce que MQTT et comment les entreprises d'automatisation industrielle peuvent-elles l'utiliser ?

Si vous vous impliquez dans l'Internet industriel des objets (IIoT), vous verrez forcément un nouvel acronyme être utilisé partout :MQTT. Bien que MQTT soit relativement nouveau dans le domaine de l'automatisation, il existe depuis plus de 20 ans. Il a été développé à l'origine comme un protocole pour obtenir des données de champs pétrolifères distants, mais jusqu'à récemment, il n'a jamais été beaucoup adopté en dehors de cette application de niche. Il apparaît désormais comme l'un des principaux protocoles des projets de transformation numérique pour la fabrication.

Qu'est-ce que MQTT ?

MQTT signifie Message Queuing Telemetry Transport. Il s'agit d'un protocole de transport de messagerie de publication/abonnement client-serveur, considéré comme un protocole de messagerie léger pour l'envoi de petits paquets d'informations dans des applications à bande passante limitée. À la base, il est considéré comme une norme OASIS au cœur de la connectivité IoT.

Historique

À la fin des années 1990, il y avait un besoin pour un protocole de communication léger qui serait capable de transmettre des données à partir de sites pétroliers distants avec des vitesses de connexion extrêmement faibles, peut-être aussi faibles que 300 bauds. La stratégie consistait à tirer parti des capacités déjà offertes dans la couche transport, qui utilisait le protocole TCP. Le protocole d'application proposé supprimerait toute redondance ajoutée à la charge utile de transmission. Il devait également être avec état et ne signaler que par exception. Avec ces contraintes à l'esprit, Phillips 66 a travaillé avec Arlen Nipper de Cirrus Link Solutions et Andy Stanford-Clark d'IBM pour développer ce qui est maintenant connu sous le nom de protocole MQTT.

Premières utilisations commerciales

Alors que les entreprises d'automatisation ont été approchées avec le protocole MQTT au début des années 2000, sa seule autre utilisation commerciale était avec les applications Facebook Messenger et Apple Messages. La principale caractéristique intéressante est que le protocole garantit un état et une qualité des données. Lorsqu'un expéditeur tapait, le destinataire voyait alors les trois points désormais trop familiers sur l'écran. Il était également utilisé dans certaines applications de surveillance à domicile et de données météorologiques, mais à ce stade, l'utilisation de MQTT était plutôt limitée.

Adoption de l'automatisation

Au milieu des années 2010, Arlen Nipper a de nouveau approché les entreprises d'automatisation pour promouvoir l'utilisation de MQTT. Il y avait un besoin émergent d'obtenir des données de fabrication supplémentaires agrégées sans demande de réseau importante. Cependant, certaines capacités supplémentaires devaient être développées afin d'être acceptées dans la fabrication. Cirrus Link Solutions, avec Inductive Automation, a poursuivi le développement de ce qui est maintenant la norme Sparkplug, qui comprend les attributs nécessaires à l'automatisation, à savoir un ensemble défini de sujets, une charge utile standard et la compression des messages.

Aperçu de la structure

MQTT utilise une structure similaire à la structure de dossiers d'un ordinateur. Je vais utiliser le bureau Windows comme exemple. Le bureau a un dossier appelé Mes documents. Dans Mes documents, il y a un autre dossier appelé Famille, et dans ce dossier se trouve un dossier pour chaque membre de la famille. Le chemin vers mon dossier serait Bureau/Mes Documents/Famille/David. Je sauverais (publierais) tous mes documents à David. Quiconque voulait lire mes documents ouvrirait (s'abonnerait) à David.

Les appareils qui utilisent le protocole MQTT publieront et s'abonneront à un chemin de sujet similaire appelé espace de noms. Tout comme un ordinateur, il est organisé du plus général au plus spécifique. Plus le niveau auquel je souscris est élevé, plus je recevrai de données. Il existe également des caractères génériques qui peuvent être utilisés pour aider à définir un chemin de rubrique. Un astérisque (*) inclut tout depuis le niveau actuel jusqu'au niveau inférieur. Un plus (+) déplace le chemin d'un niveau vers le bas. J'ai inclus quelques exemples plus bas dans l'article.

Alignement avec les normes ISA

La norme ISA-95 est bien comprise dans le secteur de la fabrication. Il décrit un modèle standard et une terminologie pour l'interface entre les systèmes d'entreprise et de contrôle. Bien qu'elle soit généralement réalisée sous forme de hiérarchie, en commençant par un ERP en haut et des appareils en bas, la norme traite principalement des données de fabrication et de la manière dont elles doivent être structurées. Étant donné que MQTT utilise un espace de noms de rubrique, ceux-ci peuvent être facilement alignés sur la hiérarchie ISA-95. Il est recommandé qu'un espace de noms de rubrique suive l'entreprise, le site, la zone, la ligne et la cellule lors de sa construction. Le dossier racine de l'éditeur/abonné doit également exister au niveau approprié. Par exemple, un automate qui contrôle une cellule doit publier ses données dans une rubrique Entreprise/Site/Zone/Ligne/Cellule. Si un historique de processus est spécifique à une zone, il doit souscrire toutes les données au niveau de l'entreprise/du site/de la zone.

Architecture

L'une des questions courantes découlant de l'utilisation de MQTT est de savoir ce qui se passe en cas de perte de connectivité. Plusieurs options peuvent être utilisées pour atténuer ces situations. Une solution courante consiste à utiliser une méthode de "stockage et retransmission". Par exemple, les systèmes SCADA qui se trouvent au niveau de la couche de contrôle continueront à collecter des données jusqu'à ce que la connexion au courtier MQTT soit rétablie. Il convient de noter que lorsque la connexion au courtier reprend, les horodatages de toutes les données stockées restent intacts.

MQTT prend également en charge l'utilisation de courtiers de sauvegarde. Tant qu'il existe un courtier principal, si cette connexion est perdue, les nœuds connectés basculeront automatiquement vers un autre courtier. La relation est généralement configurée via une application (comme un système SCADA) qui prend en charge cette fonctionnalité.

Une autre solution est obtenue grâce à l'utilisation du clustering. Ceci est typique pour les applications qui ne peuvent se permettre aucune perte de données. Une configuration courante consiste à disposer de plusieurs courtiers MQTT disposés dans un cluster. Tous ces courtiers se connaissent et partageront des messages au sein du cluster. Lorsque la connectivité est perdue, les éditeurs et les abonnés aux données acheminent de manière transparente les données vers un autre courtier sans aucune perte.

Il est courant pour une application d'entreprise d'utiliser les données de toutes ses usines. Pour ce scénario, MQTT prend en charge l'utilisation du pontage qui est similaire à un système de stockage et de retransmission. Dans cette architecture, un courtier publiera ou reliera tout ou partie de son espace de noms à un autre courtier. En d'autres termes, un courtier d'usine ferait le lien avec un courtier d'entreprise. Les rubriques publiées et la structure de l'espace de noms peuvent être définies. Cela limite à la fois la quantité de données publiées et fournit un contexte pour le courtier destinataire.

Publier toutes les données telles quelles avec un astérisque (*) et ne définir aucune structure est le moyen le plus simple, mais cela peut entraîner de nombreuses données inutiles et potentiellement déroutantes. Afin de fournir un certain contexte de données, un sujet peut être ajouté au début de l'espace de noms de sujet publié. Par exemple, Enterprise/Site pourrait être ajouté à l'espace de noms Plant Area/+/Cell, ce qui entraînerait l'envoi d'Enterprise/Site/Area/+/Cell au courtier Enterprise. Le résultat est que les données au niveau de la cellule de toutes les lignes seraient disponibles à partir de ce système (notez l'utilisation du caractère générique +).

Tous ces scénarios peuvent être déployés. Un système SCADA peut utiliser le stockage et le transfert vers un cluster MQTT. Il pourrait y avoir des clusters principaux et de sauvegarde, mais cela ajouterait probablement une complexité inutile. Enfin, un cluster d'usine peut établir une passerelle vers un cluster d'entreprise pour maximiser l'intégrité des données. C'est idéal pour l'analyse d'entreprise et l'apprentissage automatique, car ceux-ci nécessitent des quantités importantes de données de bonne qualité.

Sécurité

L'une des principales préoccupations concernant l'envoi et la réception de données de fabrication sur Internet est celle de la cybersécurité. Bien que le seul moyen d'être vraiment sécurisé consiste à utiliser un espace d'air, cela empêchera une organisation de se transformer numériquement. L'un des principaux avantages de MQTT est celui de la sécurité. Alors que d'autres protocoles de communication nécessitent l'ouverture de ports réseau, MQTT ne nécessite qu'une connexion sortante vers le courtier. Les usines ne sont pas tenues d'ouvrir des ports entrants, ce qui est très intéressant pour les services informatiques.

Considérations futures

Dans de prochains articles, j'explorerai les applications courantes avec MQTT. Bien que le protocole soit censé être assez plug-and-play, il y aura probablement un intérêt pour des détails techniques supplémentaires. Les chefs d'entreprise voudront peut-être réfléchir à la manière dont MQTT affectera leurs efforts actuels de transformation numérique. Et, bien sûr, les responsables de l'ingénierie voudront certainement savoir quel impact MQTT aura sur eux.

En conclusion, MQTT ne doit pas être considéré comme un remplacement de l'architecture existante. Aligné sur les exigences de l'industrie 4.0, il tire parti de ce qui est déjà en place. OPC UA et d'autres protocoles continueront d'être nécessaires, car ils sont plus verbeux pour les applications de contrôle. Cependant, lorsqu'il s'agit d'agréger des quantités importantes de données, MQTT constitue un excellent choix.