Connectivité des données dans l'architecture de référence de l'Internet industriel

Aujourd'hui, l'Industrial Internet Consortium (IIC) a publié l'Industrial Internet Reference Architecture (IIRA). L'IIC est le plus grand des consortiums de l'Internet des objets (IoT) avec plus de 170 membres (iiconsortium.org). Plus important encore, c'est le seul axé sur les systèmes industriels. La première version publique de l'IIRA est un aperçu formel de l'architecture des systèmes d'un point de vue de haut niveau. Il couvre tout, des objectifs commerciaux à l'interopérabilité des systèmes. L'architecture établit de nombreuses directives techniques clés. De manière critique, cela élimine également de nombreuses approches; une architecture concerne autant ce que vous ne pouvez pas faire que ce que vous pouvez faire.

Chez Real-Time Innovations (RTI), nous sommes particulièrement enthousiasmés par un aspect clé :l'architecture de connectivité IIRA. La « connectivité », ou la façon dont les choses communiquent, est l'un des plus grands défis de l'émergence de l'Internet industriel des objets (IIoT). L'IIRA adopte une approche innovante et distribuée de « bus de données » qui facilite l'interopérabilité tout en offrant des performances, une fiabilité et une sécurité optimales.

La puissance de l'architecture commune

En fin de compte, l'IIoT consiste à créer des systèmes distribués. Connecter intelligemment toutes les pièces afin que le système puisse fonctionner, évoluer, évoluer et fonctionner de manière optimale est le cœur de l'IIRA.

Pour activer l'IIoT, nous devons développer un commun une architecture qui peut couvrir les capacités informatiques, interagir entre les fournisseurs et faire le pont entre les industries. Au fil du temps, les technologies communes qui couvrent les industries remplacent toujours les systèmes sur mesure. Cependant, l'adoption progressive et l'adaptation de la technologie actuelle sont également cruciales. L'IIoT doit donc intégrer de nombreux standards et technologies de connectivité. L'architecture IIC mélange explicitement les différentes technologies de connectivité dans un avenir interconnecté qui peut permettre la vision globale d'un nouveau monde extrêmement connecté.

C'est le problème de "l'interopérabilité", et c'est vraiment la spécialité de RTI. RTI participe à 15 normes et efforts de consortiums différents. Ils couvrent de nombreux secteurs :systèmes navals, avionique, énergie, dispositifs médicaux, véhicules sans pilote, électronique grand public, contrôle industriel et télévision, pour n'en nommer que quelques-uns. Tous se concentrent sur la façon de faire fonctionner les systèmes ensemble. L'IIC s'appuie sur l'expérience de ces industries et plus encore.

Le défi de l'intégration

Lorsque vous connectez de nombreux systèmes différents, le problème fondamental est le problème d'interconnexion « N au carré ». La connexion de deux systèmes nécessite la mise en correspondance de nombreux aspects, notamment le protocole, le modèle de données, le modèle de communication et les paramètres de qualité de service (QoS) tels que la fiabilité, le débit de données ou les délais. Bien que la connexion de deux systèmes soit un défi, elle peut être résolue avec un « pont » à usage spécial. Mais il n'évolue pas ; connexion N les systèmes ensemble nécessitent N -ponts carrés. Comme N devient grand, cela devient intimidant.

Une façon d'atténuer ce problème est de garder N petit. Vous pouvez le faire en dictant toutes les normes et technologies sur tous les systèmes qui interagissent. De nombreux organismes de normalisation spécifiques à l'industrie empruntent avec succès cette voie. Par exemple, l'architecture européenne générique des véhicules (GVA) spécifie tous les aspects de la construction de véhicules terrestres militaires, des connecteurs de bas niveau aux modèles de données de haut niveau. L'effort allemand Industrie 4.0 prend une passe similaire dans l'industrie manufacturière, faisant des choix pour la commande et la livraison, la conception de l'usine, la technologie et la planification des produits. Un seul standard par tâche est autorisé.

Cette approche facilite l'interopérabilité. Malheureusement, le résultat est limité dans sa portée car les normes rigoureusement choisies ne peuvent pas fournir toutes les fonctions et fonctionnalités. Il y a tout simplement trop d'exigences spéciales pour traverser efficacement les industries de cette façon. Dicter des normes ne résout pas non plus le problème d'intégration héritée. Ces deux restrictions (portée et limites héritées) rendent cette approche inadaptée à la construction d'un Internet industriel de grande envergure et intersectoriel.

À l'autre extrémité du spectre, vous pouvez construire un point de pont très général. Les services Web d'entreprise fonctionnent de cette façon, en utilisant un "Enterprise Service Bus" (ESB) comme Apache Camel. Cependant, malgré le « bus » dans son nom, un ESB n'est pas un concept distribué. Tous les systèmes doivent se connecter à un point unique, où chaque norme entrante est mappée à un format d'objet commun. Étant donné que tout correspond à un format, l'ESB ne nécessite qu'une traduction "à sens unique", évitant le N -problème au carré. Camel, par exemple, prend en charge des centaines d'adaptateurs qui convertissent chacun un protocole ou une source de données.

Malheureusement, cela ne fonctionne pas bien pour les systèmes industriels exigeants. Le service ESB unique est un point d'étranglement et de défaillance évident. Les ESB sont des programmes volumineux et lents. Dans l'entreprise, les ESB connectent des systèmes à grande granularité n'exécutant que quelques transactions par seconde. Les applications industrielles ont besoin d'un service beaucoup plus rapide, fiable et à plus petite granularité. Ainsi, les ESB ne sont pas viables pour la plupart des utilisations IIoT.

La norme de base de connectivité IIRA

L'IIRA adopte une approche intermédiaire. La conception introduit le concept de "Connectivity Core Standard". Contrairement à un ESB, la norme de base est en grande partie un concept distribué. Certains points de terminaison peuvent se connecter directement à la norme principale. D'autres points de terminaison et sous-systèmes se connectent via des « passerelles ». La norme de base les relie ensuite tous ensemble. Cela permet plusieurs protocoles sans avoir à faire le pont entre toutes les paires possibles. Chacun n'a besoin que d'un pont vers le noyau.

Comme un ESB, cela résout le N -problème au carré. Mais, contrairement à un ESB, il fournit un cœur distribué rapide, remplaçant le modèle de service centralisé. Les technologies de connectivité héritées et moins performantes se transforment en une passerelle vers la norme de base. Il n'y a que N transformations, où N est le nombre de normes de connectivité.

De toute évidence, cette conception nécessite une norme de connectivité de base très fonctionnelle. Certains systèmes peuvent se débrouiller avec des cœurs lents ou simples. Mais la plupart des systèmes industriels doivent identifier, décrire, trouver et communiquer un grand nombre de données avec des exigences inédites dans d'autres contextes. De nombreuses applications nécessitent une livraison en quelques microsecondes ou la capacité d'évoluer jusqu'à des milliers, voire des millions de valeurs de données et de nœuds. Les conséquences d'une défaillance de fiabilité peuvent être graves. Étant donné que la norme de base est vraiment le cœur du système, elle doit être performante.

L'IIRA spécifie les fonctions clés que le cadre de connectivité et sa norme de base devraient fournir :la découverte de données, les modèles d'échange et la « qualité de service » (QoS). Les paramètres de QoS incluent la fiabilité de livraison, la commande, la durabilité, la durée de vie et les fonctions de tolérance aux pannes. Grâce à ces capacités, la connectivité principale peut mettre en œuvre le transport fiable, rapide et sécurisé requis par les applications exigeantes dans tous les secteurs.

La sécurité est également critique. Pour que la sécurité fonctionne correctement, elle doit être intimement mariée à l'architecture. Par exemple, la norme "de base" peut prendre en charge divers modèles et capacités de livraison. La conception de la sécurité doit correspondre exactement à ceux-ci. Par exemple, si la connectivité prend en charge la publication/l'abonnement, la sécurité doit en faire autant. Si le noyau prend en charge la multidiffusion, il en va de même pour la sécurité. Si le noyau prend en charge la découverte dynamique plug-n-play, la sécurité doit en faire autant. La sécurité qui est ainsi intimement mariée à l'architecture peut être imposée à tout moment sans changer le code. La sécurité devient juste une autre qualité de service contrôlée, bien que configurée de manière plus complexe. C'est un concept très puissant.

La sécurité intégrée doit s'étendre au-delà du noyau. L'IIRA perme

[1] [2] 下一页

Une taxonomie pour l'IIoT RTI Connext sur Snappy Ubuntu