Cartographie architecturale au sein de l'Internet industriel

En fonction de l'emplacement et de la fonction, la bonne solution de connectivité doit être évaluée et sélectionnée pour les différents scénarios :

• Appareils intelligents (points de terminaison)
• Connexions appareil-cloud
• Connectivité dans le cloud
• Connectivité utilisateur (cloud-à-utilisateur)

Norme de service de distribution de données

Entre les appareils et le cloud (connexions WAN), DDS offre une solution idéale avec :

• Interactions avec état
  • Connexions/déconnexions intelligentes et possibilité de renvoyer uniquement les données pertinentes lors de la reconnexion
  • Intelligence intégrée au bus, sans surcharge applicative
• De nombreux modèles de flux de données, pour répondre aux exigences actuelles et futures
• Style d'architecture de publication-abonnement basé sur les données
• Évolutivité, performances, résilience et sécurité

À l'intérieur des terminaux eux-mêmes, DDS a été largement appliqué pour les mêmes raisons énumérées ci-dessus pour les connexions appareil-à-cloud. De plus, DDS permet de concevoir des appareils intelligents qui fonctionnent de manière très fiable et répondent aux exigences de sécurité et de longévité dans des secteurs tels que la santé et l'automobile. DDS prend également en charge la diversité des transports et des plates-formes au sein d'un système, comme indiqué précédemment en termes de capacités de passerelle et de services de routage.

DDS a également fait des percées dans le cloud. Ici, les exigences couvrent une gamme plus large et donnent lieu à un mélange d'options de connectivité. DDS peut prendre en charge cette diversité de connectivité et peut également favoriser la longévité des solutions cloud.

En revanche, d'autres technologies ont plus de sens pour les connexions WAN utilisateur-cloud (voir l'illustration). À ce stade du modèle de connectivité, les technologies Web traditionnelles telles que les sockets Web et HTTP répondent aux exigences centrées sur l'humain avec :

• Interactions apatrides
• Modèle de flux de données unique (requête)
• Style d'architecture demande-réponse axé sur l'humain
• Infrastructure d'évolutivité et de sécurité établie
• Performances et résilience tolérantes (y compris des connexions et des applications faciles à redémarrer)
• Accès omniprésent à partir d'appareils mobiles ou de clients légers

Flexibilité de déploiement

Les domaines DDS permettent d'isoler facilement les sous-systèmes avec des plans de communication de données individuels. En plus de faciliter les règles de sécurité avec séparation logique, les domaines permettent également d'adapter les règles de découverte des points de terminaison et les niveaux d'activité et de réduire considérablement la bande passante du réseau et la surcharge CPU/mémoire sur les connexions de passerelle. Comme le montre le schéma précédent, par exemple, les domaines DDS peuvent être définis avec :

• Domaine 0 sur les connexions WAN. Dans le domaine 0, la découverte peut être limitée à la détection des points de terminaison de passerelle et des services de routage. (Ces passerelles agissent comme des proxys pour les terminaux dans leurs domaines.)
• Domaine 1 englobant les appareils et le cloud. La découverte complète des appareils peut être effectuée sur les bus de l'appareil et du cloud.

DDS prend également en charge un choix de transports, notamment UDP, TCP, la mémoire partagée, OpenSSL (TLS/SSL, DTLS) et les connexions à faible bande passante. Par exemple, dans le cas d'utilisation générique, la connectivité DDS entre les appareils et le cloud peut utiliser DDS sur TCP. En règle générale, les directives de transport sont différentes pour :

• LAN :utilisez UDP (avec multidiffusion, si disponible). Cela s'applique au sein d'un cloud ou pour les communications d'application à application.
• WAN :pour les communications appareil-cloud, utilisez TCP (avec TLS).

DDS est adopté pour cette dernière catégorie afin de fournir un accès à distance à n'importe quel bus de données DDS. DDS peut gérer l'état pour un partage de données transparent et une commutation entre les réseaux cellulaires et Wi-Fi. L'état est géré indépendamment de la mobilité et de la commutation du réseau, et la qualité de service (QoS) DDS peut introduire des règles résilientes pour la distribution et la gestion des informations d'état.

Enfin, pour les communications cloud-humain (périphériques d'utilisateurs mobiles ou clients légers), vous pouvez utiliser des sockets Web traditionnels et HTTP(s) (sur TCP).

Pour une démonstration en ligne de l'accès à distance à partir d'applications Web, visitez le site de démonstration RTI Connext DDS à l'adresse http://info.rti.com/demo_iot.