Solutions IIoT | 6 Solutions de communication IoT industrielles

Pour dire que la tâche de sélectionner votre IoT industriel (IIoT ), l'infrastructure de communication est une entreprise très complexe serait un euphémisme. L'évaluation de la myriade de solutions disponibles dans le commerce est à la fois longue et coûteuse. Essayez de télécharger et d'évaluer plusieurs solutions de chaque type d'infrastructure et vous vous retrouverez rapidement au milieu d'un projet qui prendra à plusieurs ingénieurs un bon six mois. Nous sommes tous passés par là et je veux vous aider à gagner un temps précieux !

Le but de cet article est de vous présenter les solutions d'infrastructure IIoT populaires disponibles dans le commerce - AMQP, CoAP, DDS, RTI Connext DDS, MQTT et ZeroMQ - et de mettre en évidence les capacités de chaque solution. Les six domaines d'évaluation suivants seront appliqués :architecture, modèles de communication, transports, type de données et filtrage, qualité de service et sécurité.

Cliquez ici pour télécharger la version PDF imprimable.

1. Architecture

Selon le modèle architectural d'une infrastructure de communication donnée, la connexion logique (illustrée dans la figure 1, ci-dessous) que les applications utiliseront pour communiquer avec d'autres applications à travers l'infrastructure varie. Les deux architectures les plus basiques utilisées dans les solutions middleware d'aujourd'hui sont (1) les architectures peer-to-peer et (2) les architectures en étoile basées sur les courtiers.

1. Archites peer-to-peer permettre aux applications de communiquer directement entre elles sans avoir à envoyer de données à un élément intermédiaire. Ces architectures sont intrinsèquement plus efficaces pour la livraison des données, car seules les applications d'envoi et de réception utilisent des ressources CPU pour terminer le transfert. Par conséquent, seules les applications qui ont les données et les applications qui ont besoin des données consommeront des cycles CPU; se traduit ainsi par une répartition efficace du traitement en fonction des exigences de l'application. L'autre avantage d'une architecture peer-to-peer est que la livraison déterministe des données est beaucoup plus réalisable car il n'y a pas d'« intermédiaire » qui gère les données entre les applications producteur et consommateur.

Figure 1. Schémas architecturaux des différents protocoles IoT.

2. Solutions basées sur les courtiers exiger que toutes les applications qui envoient des données transfèrent les données directement au serveur du courtier, après quoi il se retournera et renverra ces données aux applications réceptrices. L'avantage de cette architecture est que le courtier gère toute la complexité liée à l'envoi/la réception des données. Généralement, ces solutions ont des outils intégrés pour voir exactement quels chemins de données sont actifs, qui envoie des données et qui reçoit des données. Les solutions basées sur les courtiers introduisent une latence dans la livraison des données et présentent également un point de défaillance unique, de sorte que si le courtier échoue, toutes les communications échouent également. Pour résoudre le problème du point de défaillance unique, la plupart de ces implémentations prévoient des serveurs de courtage redondants et hautement disponibles.

2. Modèles de communication

La prise en charge des modèles de communication est essentielle à une infrastructure que vous pouvez utiliser tout au long du cycle de vie de votre projet ou de votre gamme de produits. Le projet initial peut nécessiter uniquement la publication/l'abonnement, mais les projets ou produits suivants peuvent nécessiter des modèles supplémentaires tels que la demande/réponse ou la mise en file d'attente. Dans cet aspect, toutes les solutions IoT existantes disponibles aujourd'hui ne peuvent pas prendre en charge tous les modèles nécessaires dont votre projet aura besoin. Pour le tableau de comparaison, nous avons identifié les modèles les plus courants utilisés aujourd'hui et si chaque solution d'infrastructure fournit ce modèle. Voici les modèles les plus couramment utilisés aujourd'hui :

• Publier / S'abonner :Une application (abonné) demande des données 1 fois, puis toutes les mises à jour ultérieures des données sont ensuite « poussées » vers l'abonné. Pas besoin de demander continuellement des mises à jour des données.
• Demande/Réponse/RPC (Appel de procédure à distance ) :une application demandeuse envoie des demandes et une application répondeur répond à la demande.
• Mise en file d'attente (ou point à point ) :Les données sont transmises à un serveur qui contiendra les informations dans une file d'attente. Les données peuvent ensuite être extraites de la file d'attente ou transmises aux consommateurs. Contrairement à Publish/Subscribe, chaque donnée est distribuée à une seule application réceptrice.
• Un vers plusieurs  : possibilité de faire en sorte que plusieurs applications réceptrices obtiennent les mêmes données à partir d'une seule source.
• Plusieurs vers un  : Possibilité de recevoir des données de plusieurs sources dans une seule application consommatrice.

3. Transports &Routage/Pont

La plupart des solutions middleware de communication prennent en charge TCP comme protocole de communication principal. L'utilisation de TCP vous offre une livraison fiable des données à l'aide du mécanisme de fiabilité intégré inhérent à TCP. Cela peut être idéal pour des flux de données spécifiques qui nécessitent une fiabilité, mais est excessif et ajoute une surcharge inutile aux données de capteur simples qui ne nécessitent pas une livraison fiable. Certaines des solutions IoT telles que ZeroMQ et DDS prennent également en charge d'autres transports tels que la mémoire partagée. Un transport à noter est l'utilisation du transport UDP pour DDS. Étant donné que la mise en œuvre de la fiabilité est intégrée à DDS, elle ne nécessite pas de transport fiable en dessous. Cela permet aux applications de choisir quels flux de données sont une livraison fiable et quels flux nécessitent le meilleur effort.

Le routage des données entre les transports et à travers le WAN est quelque chose que toutes ces solutions fournissent d'une manière ou d'une autre. Dans le monde d'aujourd'hui où les systèmes d'entreprise, tirant parti des technologies ESB et Web, doivent également accéder à certaines des données en temps réel, il est essentiel que le middleware de communication prenne également en charge la connexion à ces technologies. Pour cette raison, vous verrez le routage et le pontage comme un composant essentiel du middleware du système distribué.

4. Type de données et filtrage

La façon dont les données sont encapsulées et représentées sur le fil est également unique à l'infrastructure donnée. Certaines solutions n'envoient que des octets bruts de données, et c'est à l'application de sérialiser et de désérialiser les données. D'autres n'envoient que des données texte/chaîne afin que les informations puissent être représentées au format XML ou JSON. Ce scénario est très courant dans les technologies Web d'aujourd'hui, mais peut être très inefficace car à chaque envoi de données, le paquet contient également la description des données, faisant parfois de la taille du paquet plus de 3 fois sa taille d'origine. De plus grandes tailles de paquets augmentent l'utilisation de la bande passante ainsi que l'utilisation du processeur à la fois du côté envoi et du côté réception du transfert. Mettez un courtier au milieu de cela et vous doublez maintenant le nombre de paquets sur le fil.

D'autres solutions, telles que DDS, permettent l'utilisation de données fortement typées qui sont sérialisées et désérialisées de manière unique par le middleware. Le schéma est envoyé séparément, ce qui n'est pas le cas avec XML ou JSON, et donc vous ne payez pas de pénalité par message (ou échantillon). Cela devient également très important pour le filtrage des aspects. Supposons que vous configurez un seul éditeur avec de nombreux abonnés. Certains des abonnés peuvent vouloir toutes les données, mais certains des abonnés ne voudront qu'une partie des données. Sans avoir une solution de données fortement typée, vos applications devront gérer l'ensemble de cette fonctionnalité de filtrage, qui est encore plus de code à écrire. Avec des solutions comme DDS où les informations de type sont fortement définies, le middleware peut gérer tout le filtrage pour vous. Moins de code =des développeurs plus heureux :). En fait, RTI Connext DDS a des fonctionnalités supplémentaires pour fournir ce filtrage du côté écrivain du transfert de données, ce qui se traduit par moins d'utilisation de la bande passante sur le fil et moins de traitement CPU sur les appli

[1] [2] 下一页