Sélectionner la connectivité IIoT optimale : Cadres vs Transports

Concevoir une infrastructure distribuée pour l'Internet Industriel des Objets (IIoT) peut ressembler à naviguer dans un labyrinthe de protocoles et standards. En tant que développeur ou architecte système, vous avez probablement déjà une liste d'options – TCP, UDP, MQTT, CoAP, OPC-UA, DDS, et plus – chacune promettant de résoudre une tranche différente du puzzle de la connectivité. Le vrai défi est de déterminer quelle solution s'aligne véritablement avec les besoins de votre application.

Heureusement, une étude indépendante et neutre vis-à-vis des fournisseurs a déjà cartographié le paysage. Le Consortium Internet Industriel (IIC) a publié le Cadre de Connectivité Internet Industriel (IICF), un guide complet qui évalue les forces et compromis de chaque transport et cadre. Les résultats sont maintenant publics, vous offrant une base décisionnelle fondée sur les données.

Ci-dessous, nous parcourons les questions clés à vous poser, comparons les capacités des transports et cadres, et mettons en évidence les technologies les plus pertinentes identifiées par l'IICF. À la fin, vous aurez une image plus claire de l'option qui convient le mieux à votre application IIoT unique.

À propos du Consortium Internet Industriel (IIC)

Fondé en 2014 par des leaders de l'industrie tels que Cisco, Intel, AT&T, IBM et GE, l'IIC a grandi pour inclure plus de 250 entreprises membres. Sa mission est de faire progresser le potentiel commercial de l'IIoT en développant des standards, bancs d'essai et documents de meilleures pratiques. L'IICF est l'un de ses produits phares, offrant un cadre neutre pour évaluer les solutions de connectivité dans des scénarios réels.

Transport vs Cadre : Comprendre la pile

Dans l'IICF, les solutions de connectivité sont divisées en deux couches :

• Transport – Mécanismes de bas niveau qui déplacent des octets bruts entre points de terminaison (ex. TCP, UDP, MQTT).
• Cadre – Abstractions de niveau supérieur qui imposent des modèles de données, la découverte et l'interopérabilité sémantique (ex. OPC-UA, DDS, OneM2M).

La Figure 1 illustre la pile globale, soulignant où s'insèrent les transports et cadres.

Alors qu'un transport se contente de livrer des octets, un cadre enveloppe ces octets en messages structurés, permettant aux applications de bénéficier de fonctionnalités comme le filtrage de données, la découverte de contenu et les politiques de sécurité.

Options de transport

Voici un aperçu des capacités de transport couvertes par l'IICF (Tableau 1). Le tableau est disponible en image dans le document original ; vous pouvez le consulter ici :

MQTT – Le transport télémétrie éprouvé

MQTT est le seul transport dans l'IICF qui n'impose pas de modèle de données. Son architecture légère basée sur un courtier le rend idéal pour les scénarios où les appareils doivent simplement publier des données télémétriques vers un système backend.

La conception basée sur un courtier facilite le couplage lâche mais peut ne pas satisfaire des exigences strictes de temps réel ou déterministes. Utilisez le test rapide suivant : répondez « oui » à au moins trois des questions ci-dessous pour confirmer que MQTT est un bon choix.

• Votre application est-elle principalement de la collecte de données ?
• La communication appareil-à-appareil est-elle minime ?
• L'interopérabilité est-elle une préoccupation secondaire ?
• Avez-vous de nombreux petits appareils à faible consommation ?
• La complexité logicielle est-elle faible pour votre équipe ?

Cadres

Les cadres ajoutent une couche de sens sémantique aux données, permettant des patterns d'interaction plus riches. Nous nous concentrons sur les trois cadres les plus largement adoptés identifiés par l'IICF : OPC-UA, OneM2M et DDS.

OPC-UA – Le standard de l'automatisation industrielle

OPC-UA est un cadre basé sur un courtier qui offre un échange de données sécurisé et temps réel entre dispositifs industriels et systèmes d'entreprise. Il est particulièrement adapté à la fabrication discrète et aux environnements où la sémantique des appareils doit être préservée.

Répondez « oui » à au moins trois des questions suivantes pour évaluer l'adéquation d'OPC-UA :

• Travaillez-vous dans la fabrication discrète ?
• Êtes-vous aligné avec le programme allemand Industrie 4.0 ?
• Votre appareil sera-t-il intégré par des ingénieurs de contrôle plutôt que des développeurs logiciels ?
• Le produit servira-t-il des applications diverses à travers plusieurs systèmes ?
• Construisez-vous de l'équipement pour une cellule de travail ?

OneM2M – Une couche de service transversal

OneM2M fournit une plateforme horizontale qui se situe entre les applications et le transport, exposant des services IoT communs via des API RESTful. Il excelle dans le mobile, l'automatisation domestique et les déploiements à grande échelle où la connectivité cellulaire et l'intégration aux fournisseurs de services sont clés.

Utilisez la liste de contrôle ci-dessous pour voir si OneM2M s'aligne avec vos besoins :

• Comprenez-vous la signification de TIC (Technologies de l'Information et de la Communication) ?
• La cellule est-elle la technologie réseau principale ?
• Vos applications impliquent-elles une mobilité significative ?
• Votre système peut-il tolérer des connexions intermittentes et une latence variable ?
• Exploiterez-vous les services fournis par les opérateurs télécoms ?

Data Distribution Service (DDS) – Publication/Souscription temps réel

DDS est un cadre de publication/souscription pair-à-pair qui crée un bus de données partagé. Il est conçu pour les scénarios à faible latence et haute fiabilité tels que les véhicules autonomes, la défense et la surveillance médicale.

Posez-vous ces cinq questions pour déterminer l'adéquation de DDS :

• De brèves interruptions ont-elles des conséquences graves ?
• Avez-vous utilisé des termes comme « milliseconde » ou « microseconde » dans vos discussions récentes ?
• Votre équipe compte-t-elle plus de dix développeurs ?
• Vos données doivent-elles atteindre de nombreuses destinations ?
• Construisez-vous un système IIoT de prochaine génération ?

En résumé

La bonne solution de connectivité dépend de vos exigences spécifiques – volume de données, latence, fiabilité et niveau d'interopérabilité sémantique nécessaire. Utilisez l'IICF comme point de départ, passez en revue les listes de contrôle, et considérez comment chaque transport ou cadre répond à vos contraintes clés.

Si vous identifiez des lacunes ou avez des cas d'usage supplémentaires, n'hésitez pas à nous contacter. La connaissance collective de la communauté peut affiner votre choix et éviter de réinventer la roue.

Ressources supplémentaires

• Blog RTI – Le document de connectivité IIC évalue les standards de base : DDS, OPC-UA, WebServices
• Webinaire gratuit à la demande : Comment le cadre de connectivité de l'IIC guide le choix de la connectivité IIoT