Frameworks et transports :choisir la meilleure solution de connectivité IIoT

Construire une infrastructure de système distribué dans le paysage émergent de l'Internet des objets industriel (IIoT) d'aujourd'hui peut être une tâche pour le moins intimidante. Si vous êtes développeur ou architecte système, vous savez qu'il existe de nombreux outils et protocoles disponibles pour déplacer les données dans votre application distribuée. Sans oublier la possibilité de construire votre propre solution personnalisée directement sur les sockets TCP ou UDP. Ne serait-il pas formidable si une grande partie du travail qui devait être fait avant que vous puissiez prendre une décision sur votre prochaine infrastructure était déjà fait pour vous ?

Vous savez quoi? Le travail a été fait et est maintenant disponible pour vous aider à prendre cette décision. Vous devez vous demander :« Qui a fait toutes ces recherches et est-ce biaisé par une entreprise cherchant à vendre sa propre solution ? » La bonne nouvelle est que la recherche a été réalisée par un consortium indépendant, l'Industrial Internet Consortium (IIC). Elle a été menée d'une manière neutre et impartiale et les informations qui en résultent sont désormais à votre disposition.

Avis de non-responsabilité :Oui, je travaille pour une entreprise qui fournit une infrastructure pour l'Internet industriel, mais je ne dis en aucun cas que notre solution est la meilleure. La vraie réponse à la question « Quelle est la meilleure solution ? » c'est :"Ça dépend".

La réponse dépend de ce dont vous avez besoin d'une solution d'infrastructure :

• Avez-vous juste besoin d'envoyer des octets de données d'un point A à un point B ?
• Avez-vous besoin que les données soient fournies de manière fiable ?
• Avez-vous besoin d'une connaissance centrée sur les données pour que l'infrastructure puisse fournir des décisions de livraison efficaces pour une solution plus intelligente ?
• Quelle partie du traitement des données souhaitez-vous transférer à l'infrastructure ?

Les réponses à ces questions critiques, et bien d'autres, sont ce que j'étudie dans cet article. À la fin de cet article, nous espérons que vous aurez les informations dont vous avez besoin pour prendre une décision éclairée sur la meilleure solution pour votre application unique.

À propos du Consortium Internet industriel (IIC)

L'IIC a été formé en 2014 par de très grands acteurs du paysage de l'Internet industriel. Les sociétés fondatrices (Cisco, Intel, AT&T, IBM et GE) ont entrepris de créer une organisation centrée uniquement sur les besoins des applications de l'Internet industriel. Aujourd'hui, le consortium est composé de plus de 250 entreprises, grandes et petites. Les résultats de ce consortium comprennent un ensemble de documents qui décrivent les besoins et les solutions potentielles pour ces types d'applications Internet industrielles. Le document IIC Industrial Internet Connectivity Framework (IICF), un document d'orientation, est parfait pour vous aider à déterminer la meilleure solution pour les exemples basés sur le marché. En plus de divers documents, ils ont également établi des bancs d'essai qui seront utilisés pour prouver la capacité de diverses technologies à répondre à divers exemples de marché du monde réel. Des informations sur les documents disponibles et les bancs d'essai basés sur le marché sont disponibles sur le site Web de l'IIC.

Fournir des données :Transports et frameworks

Il existe de nombreuses solutions disponibles aujourd'hui pour obtenir des données entre les applications. Dans le document IICF, ces solutions sont réparties en deux catégories :les transports et les frameworks. Examinons ces deux types de solutions de transfert de données pour voir où elles s'intègrent dans la pile globale de couches de connectivité. La figure 1 ci-dessous montre cette pile de connectivité.

Figure 1. Pile du cadre de connectivité IIC

Presque tout le monde qui lit ce document a vu une pile de connectivité comme celle-ci, mais la pile de l'IIC a une distinction claire :les couches de transport et de structure.

En règle générale, nous avons tendance à regrouper toutes les solutions que vous voyez dans les catégories transport et framework, mais il existe une très grande différence entre un transport et un framework. Un transport est utilisé pour fournir des données d'un point A à un point B, tandis qu'un cadre exploite essentiellement la capacité d'un transport tout en fournissant un système de type de données pour l'interopérabilité. En termes simples, lorsqu'elle n'utilise qu'un transport, l'application doit formuler les données dans un tampon générique pour les transmettre au transport. Cependant, avec un framework, l'application a juste besoin de transférer les données au framework, et le framework s'occupera de construire un tampon pour que le transport sous-jacent puisse aller de l'avant et envoyer ses données. Travailler au niveau des données pour une application présente de nombreux avantages pour les applications offrant des fonctionnalités telles que le filtrage et la découverte de contenu, tandis que si votre application n'utilise quelque chose qu'au niveau de la couche de transport, il appartient à l'application d'implémenter la découverte et le filtrage si nécessaire. Le tableau 1 vous donne toutes les capacités disponibles à chaque couche de transport ou de structure.

Tableau 1. Capacités de transport et de cadre

Pouvez-vous créer une application Internet industrielle distribuée à l'aide d'un transport ? Oui. Pouvez-vous créer une application Internet industrielle distribuée à l'aide d'un framework ? Oui. Est-ce que l'un est meilleur que l'autre? La vraie réponse est :"Ça dépend." Cela dépend des exigences de votre application quant à la solution la mieux adaptée à votre infrastructure. Le reste de cet article passera en revue plusieurs de ces frameworks et transports afin que vous puissiez décider quelle est la bonne technologie pour votre application.

Transports

Il existe de nombreuses solutions disponibles aujourd'hui pour obtenir des données entre les applications. Dans l'IICF, il existe des transports appelés qui exploitent les interfaces de socket IP standard d'UDP ou de TCP. Si votre application a besoin d'un transfert de données fiable, un développeur choisira TCP pour ses capacités orientées connexion et ses mécanismes fiables. Pour une connexion plus simple et un transfert de données non fiable, UDP serait choisi pour sa facilité d'utilisation et sa livraison en multidiffusion. Pendant des années, la plupart des applications réseau ont utilisé ces interfaces de base pour envoyer et recevoir des données. Toutes les capacités fournies par les transports de couche supérieure (énumérées dans le Tableau 1) devraient être construites directement, au sein de l'application. Lorsque nous examinons les transports de couche supérieure de DDS-RTPS, CoAP, MQTT, HTTP et OPC-UA Bin, nous n'examinerons en réalité que les détails de CoAP et MQTT. Les transports DDS-RTPS, HTTP et OPC-UA Bin sont essentiellement liés directement aux frameworks au-dessus d'eux de DDS, Web Services et OPC-UA respectivement. Les capacités de ces transports seront discutées dans le cadre de la discussion sur le cadre à suivre.

MQTT

Jetons un coup d'œil à Message Queuing Telemetry Transport (MQTT). Encore une fois, MQTT est répertorié ici en tant que transport car il n'applique ni n'implémente de modèle de données pour les applications. Il ne fournit qu'un tampon sur lequel les applications doivent formuler leurs données pour l'envoi et la réception. Son objectif principal pour lequel il a été créé est répertorié dans son nom :Télémétrie. Avoir un appareil ou une application sur le terrain se connecte et rapporte des données à un cloud backend ou à un emplacement de traitement hors site. Ce transport est idéal pour des choses comme une passerelle IoT domestique ou le gestionnaire d'un ensemble d'appareils déployés. L'architecture principale de MQTT est basée sur un courtier, comme le montre la figure 2.

Figure 2. Architecture du courtier MQTT

Dans cette architecture, tous les clients distants envoient leurs données au courtier MQTT, et le courtier est responsable de l'envoi de ses données à tous les clients qui ont demandé ces données. Cette architecture basée sur un courtier facilite l'envoi et la réception de données de manière faiblement couplée, mais elle ne se prête pas à la prise en charge d'applications industrielles à faible latence et hautement déterministes. En tant que transport, MQTT a sa place dans le paysage global des applications industrielles distribuées. Ce qui suit est un outil que vous pouvez utiliser pour déterminer si MQTT est quelque chose que vous devriez utiliser pour votre projet suivant ou en cours. Voici cinq questions « oui » ou « non » pour vous. Si votre réponse à au moins trois de ces questions est « oui », alors MQTT est le bon choix pour vous.

Questions MQTT

1. Considérez-vous votre application comme une collecte de données ?
2. Y a-t-il peu de communication appareil-appareil ?
3. L'interopérabilité n'est-elle pas une considération ?
4. Avez-vous beaucoup de petits appareils ?
5. Le logiciel est-il un défi mineur ?

   [1] [2] 下一页

   Connexion des pièces :intégration d'un composant portable conforme à FACE à un environnement de simulation HIMSS18 :L'amélioration des soins de santé n'est PAS un problème technologique