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

>

MQTT est le seul transport répertorié dans le document IICF qui n'est pas vraiment lié à une infrastructure de couche supérieure. C'est la raison pour laquelle nous l'avons séparé en tant que transport. Examinons maintenant les cadres répertoriés dans le document IIC.

Cadres

Comme mentionné précédemment, la différence distinctive entre un cadre et un transport réside dans le fait qu'un cadre comprend une capacité de maintenance et d'application d'un modèle de données utilisé par les applications participant au cadre. Sur les quatre frameworks évoqués, OPC-UA, OneM2M, DDS et Web Services, nous ne regarderons que les trois premiers. Les services Web sont un cadre très connu avec de nombreuses références en ligne qui peuvent être trouvées pour la recherche, et pour cette raison, nous ne l'examinerons pas dans cet article. Pour chacun des frameworks sélectionnés (OPC-UA, OneM2M et DDS), nous fournirons un aperçu des bases de ce framework ainsi que les questions clés auxquelles il faut répondre pour déterminer si ce framework est la bonne solution pour votre application IIoT distribuée.

OPC-UA

Jetons un coup d'œil à OPC-UA comme premier framework. L'Open Platform Communications Unified Architecture (OPC-UA) est décrite dans le document IICF comme « Une architecture de communication industrielle pour une interopérabilité indépendante de la plate-forme, haute performance, sécurisée, fiable et sémantique entre les capteurs, les appareils de terrain, les contrôleurs et les applications au niveau de l'atelier en temps réel ainsi qu'entre l'atelier et le cloud informatique de l'entreprise."

Comme MQTT, OPC-UA est également une architecture basée sur un courtier. Les clients OPC-UA fournissent des objets de données au serveur et le serveur répond ensuite aux requêtes des autres clients OPC-UA. Généralement, ces objets de données sont des objets très centrés sur le périphérique qui sont essentiellement une collection de diverses variables d'entrée et de sortie de périphérique. Un graphe d'objets souhaités peut être construit par un client et le serveur cartographiera tous ses objets collectés et présentera une réponse cohérente au client demandeur. La figure 3 est un schéma d'architecture typique montrant un graphique des objets existants disponibles dans un système donné.

Figure 3. Graphique typique des objets de données de périphérique dans OPC-UA

L'infrastructure OPC-UA est principalement utilisée dans les environnements d'automatisation industrielle et de fabrication. Voici quatre questions auxquelles il faut répondre pour déterminer si OPC-UA est la bonne solution pour votre application :

Questions OPC-UA

1. Es-tu dans la fabrication discrète ?
2. Êtes-vous associé au programme German Plattform Industrie 4.0 ?
3. Créez-vous un appareil qui sera intégré par des ingénieurs ou des techniciens de contrôle ou de processus, plutôt que par des ingénieurs logiciels ?
4. Votre produit sera-t-il utilisé dans différentes applications dans différents systèmes, par opposition à un (type de) système dont vous contrôlez l'architecture ?
5. Créez-vous des équipements pour une "cellule de travail" ?

Si vous pouvez répondre « oui » à trois de ces questions, alors OPC-UA est le bon choix pour votre application.

OneM2M

Le deuxième cadre évoqué par le document IIC est oneM2M. La description d'un M2M dans le document IICF est la suivante :« oneM2M fournit une couche de service commune qui se situe entre les applications et le transport de connectivité. Il offre des fonctions dont les applications IoT dans différents segments de l'industrie ont généralement besoin. Ces fonctions sont exposées aux applications via des API RESTful. OneM2M Les normes comprennent une architecture de plate-forme horizontale qui s'intègre dans un modèle à trois couches comprenant des applications, des services middleware et des réseaux. Les normes de connectivité de OneM2M permettent aux applications hébergées sur des machines et des appareils connectés, des systèmes d'entreprise et des appareils mobiles de communiquer entre elles de manière efficace. , sécurisée. La plate-forme horizontale oneM2M est évolutive, car les éléments de service communs peuvent être déployés sur des hôtes, à la périphérie du réseau proximal ou dans le cloud de l'entreprise." Les principales applications qui utilisent oneM2M aujourd'hui sont la domotique et les applications à grande échelle exploitant les systèmes mobiles. Les services disponibles dans la couche de service commune sont fournis par de grandes entreprises de télécommunications. La figure 4 montre l'architecture des trois couches appelées dans oneM2M.

Figure 4. L'architecture oneM2M

Voici les cinq questions spécifiques auxquelles vous devez répondre pour déterminer si oneM2M est le bon choix pour votre application. Répondre « oui » à 3 de ces questions indiquerait que oneM2M est le bon choix pour vous.

Questions OneM2M

1. Savez-vous ce que signifie « ICT » et est-ce vous ? (Technologies de l'information et des communications)
2. Le réseau cellulaire est-il votre principale technologie de connexion ?
3. Vos applications cibles sont-elles en grande partie composées de pièces mobiles ?
4. Les composants de votre système peuvent-ils tolérer des connexions intermittentes et des latences mal contrôlées ?
5. Votre système tirera-t-il parti des services fournis par un fournisseur de communications tel qu'un opérateur de téléphonie ?

Service de distribution de données (DDS)

Le dernier framework que nous allons explorer est le DDS. Je dois admettre qu'en tant qu'auteur de cet article et employé de RTI, je suis partisan de DDS car je travaille avec lui depuis plus de 14 ans. Parmi les quatre frameworks mentionnés dans l'IIC IICF, DDS est le seul qui fournit une architecture Peer-to-Peer, Publish/Subscribe. Avec DDS, chaque application participe à un « bus de données » qui crée un espace de données global partagé. Cela signifie que le bus de données comprend un ensemble de sujets de données, chacun défini avec son modèle de données unique, qui peut ensuite être découvert par n'importe quel participant sur le bus de données. Une fois qu'une application homologue déclare son intention de publier des données sur un sujet ou de s'abonner à des données sur un sujet, via un mécanisme de découverte, DDS connectera tous les éditeurs appropriés avec leurs abonnés. La figure 5 est un schéma d'une architecture de bus de données en couches qui instancie trois bus de données qui se connectent via des passerelles situées entre les couches horizontales.

Figure 5. Architecture de bus de données en couches utilisant DDS

Cet exemple de diagramme est basé sur une application de surveillance des patients en soins de santé que vous trouveriez dans un hôpital. Cependant, ce n'est qu'un exemple des nombreux types d'applications d'autonomie en temps réel où DDS est utilisé aujourd'hui. Les autres domaines d'application incluent les réseaux intelligents, le pétrole et le gaz, les véhicules autonomes, les systèmes de transport et de défense. Voici les cinq questions que vous devez vous poser au sujet de votre application pour voir si DDS est le bon choix pour vous.

Questions DDS

1. Y a-t-il des conséquences graves si vous êtes hors ligne pendant quelques minutes/secs/msecs ?
2. Avez-vous dit "milliseconde" ou "microseconde" au cours des deux dernières semaines ?
3. Avez-vous plus de 10 programmeurs ?
4. Vos données ont-elles plusieurs destinations ?
5. Créez-vous une conception IIoT de nouvelle génération ?
   

Envelopper les choses

Comme je l'ai mentionné précédemment, étant donné que je travaille pour une société DDS, j'ai un faible pour l'infrastructure DDS et les problèmes qu'elle résout pour les systèmes autonomes en temps réel. Cela dit, j'espère que cet article vous a donné des outils à utiliser pour déterminer quelle est la bonne solution pour votre prochain ou actuel projet d'infrastructure distribuée. Parce que, vraiment, ces transports et ces frameworks sont tous bons pour résoudre des problèmes très différents. La clé est de déterminer où les exigences de votre application s'intègrent dans le paysage des solutions disponibles. Les outils recommandés ici incluent le cadre de connectivité Internet industriel IIC (IICF) ainsi que la liste des questions clés pour chaque solution. S'il manque quelque chose, n'hésitez pas à me contacter dans les commentaires. J'aimerais poursuivre la discussion et découvrir d'autres solutions pouvant aider les développeurs et les architectes à résoudre leurs problèmes de connectivité sans avoir à recréer la roue avec une solution propriétaire personnalisée.

Ressources supplémentaires :

• Le blog RTI>> Le document sur la connectivité Internet industrielle évalue les normes fondamentales :DDS, OPC-UA, services Web
• Webinaire gratuit à la demande :Comment le cadre de connectivité de l'IIC guide la sélection de la connectivité IIoT
  
  

上一页  [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