1.0 Présentation
L'Internet industriel des objets (IIoT) consiste en un réseau d'appareils connectés qui créent des systèmes capables de surveiller, collecter, échanger et analyser des données afin de permettre aux entreprises industrielles de prendre des décisions commerciales plus intelligentes et plus rapides. Les avantages de l'application des approches IIoT aux problèmes commerciaux industriels sont énormes, car même une petite amélioration en termes d'efficacité, de temps, de dépenses d'investissement et d'allocation des actifs se traduit par des économies et/ou une augmentation significative des revenus. Les solutions IIoT ont démontré ce type d'améliorations en pourcentage. Cependant, la mise en œuvre d'une solution IIoT nécessite une bonne compréhension de son architecture et de sa conception.
L'objectif de ce document est de fournir cette compréhension pour les systèmes de surveillance IIoT. Il convient de noter que les systèmes IIoT peuvent être utilisés à des fins de surveillance et de contrôle. Parmi ces deux cas d'utilisation, la surveillance est généralement plus simple à mettre en place et à maintenir. Les avantages immédiats de la surveillance IIoT comprennent : l'alerte à distance en cas d'anomalies, le suivi de l'historique et l'élimination du temps et des efforts nécessaires à la vérification manuelle.
La suite de ce document commence par une architecture conceptuelle pour la solution de surveillance IIoT dans la section 2.0. L'architecture conceptuelle fournit un cadre pour décrire les options d'architecture de conception qui sont détaillées dans la section 3.0. Un guide de sélection pour choisir entre les options est fourni dans la section 4.0. La présentation de l'écosystème et de la gamme de produits Omega Link dans la section 5.0 montre une instanciation de l'architecture de conception. La section 5.0 fournit une brève présentation du sujet de l'informatique en périphérie, qui revient à l'utilisation de l'IIoT pour le contrôle par opposition à la surveillance.
Le sujet de la sécurité IIoT est important. Nous laissons une discussion détaillée pour un autre document, mais nous fournissons un résumé des conseils liés à l'architecture dans l'Annexe. Les architectures conceptuelles et de conception présentées (ainsi que l'écosystème Omega Link d'Omega) intègrent la sécurité comme partie intégrante de leurs structures.
2.0 Architecture conceptuelle
2.1 Aperçu
L'architecture conceptuelle d'une solution IIoT est présentée à la figure 2.1. Un système est surveillé par un ou plusieurs capteurs. Le système et les capteurs sont sur site. Les informations provenant de ces capteurs sont envoyées vers un emplacement hors site dans le cloud via l'élément de connectivité. Nous appelons « communications nord-sud » les données transitant de l'élément de connectivité vers le cloud et « communications sud-nord » celles transitant de l'élément de connectivité vers les capteurs.
2.2 Éléments
2.2.1 Cloud
Le cloud est le lieu de stockage et d'analyse hors site des données provenant des capteurs. Il fournit également un accès sécurisé à ces données aux utilisateurs, généralement via une connexion à un navigateur web. Contrairement au stockage sur site, qui est généralement limité à l'accès à cet emplacement, le stockage et l'analyse dans le cloud sont disponibles via Internet. L'accès à Internet permet à un ou plusieurs utilisateurs d'accéder à ces données à distance via un ordinateur de bureau, une tablette ou un téléphone mobile. Des analyses avancées (par exemple, l'apprentissage automatique) sont également disponibles.
2.2.2 Connectivité
Le transfert sécurisé des informations entre les capteurs et le cloud est assuré par l'élément « Connectivité ». Comme nous le verrons dans la section suivante, cet élément est complexe en raison du nombre d'options disponibles et de sous-éléments impliqués. Quelle que soit sa complexité, la tâche reste la même : le transfert sécurisé des données.
2.2.3 Capteurs
Les capteurs permettent de détecter l'état du système. L'objectif de la solution IIoT est de transférer les données essentielles collectées par les capteurs vers le cloud afin qu'elles puissent être analysées et utilisées pour la prise de décision par des utilisateurs éloignés du système lui-même.
3.0 Architecture de conception
3.1 Présentation générale
L'architecture de conception (figure 3.1) approfondit l'architecture conceptuelle en fournissant des options et des éléments de conception pour chacune des fonctions principales (cloud, Connectivité, Capteurs). La figure 3.1 donne plus de détails sur les fonctions cloud, connectivité et capteurs. Vous trouverez plus d'explications dans les sous-sections ci-dessous.
3.2 Capteurs
3.2.1 Câblés ou sans fil
Du point de vue de l'architecture d'une solution IIoT, la distinction entre capteurs câblés et sans fil est l'attribut le plus important. Les sorties des capteurs câblés peuvent être analogiques ou numériques. Si elles sont analogiques, des moyens de conversion des données en format numérique pour la transmission doivent être disponibles en amont de la chaîne. Si elles sont numériques, le protocole de transfert des données doit être connu et pris en charge par la solution de connectivité (ce que nous appelons la connexion « southbound »). Le protocole numérique inclut à la fois les composants physiques (câbles, connecteurs) et le protocole logiciel. Vous trouverez plus de détails dans la section Connectivité : protocoles. Pour les capteurs sans fil, comme pour les capteurs à sortie numérique câblés, les données ont déjà été converties, il faut donc établir des protocoles pour l'envoi et la réception des informations. De plus, les composants physiques incluent une capacité de transmission et de réception sans fil.
3.2.2 Formats
Les formats permettent d'intégrer un ou plusieurs capteurs fonctionnant dans différents environnements et régimes réglementaires. Du point de vue de l'architecture IIoT, il est important de comprendre les formats qui combinent des capteurs avec une transmission sans fil. Ceux-ci sont représentés dans la figure 3.1 dans les encadrés en pointillés « unité unique ». L'un montre des capteurs associés à une connectivité cellulaire, permettant un accès direct au cloud. L'autre montre une combinaison capteur/émetteur qui fournit une connexion à une passerelle via une liaison sans fil.
3.2.3 Types de détection
Les capteurs détectent divers phénomènes physiques, chimiques, biologiques et nucléaires via un certain nombre de mécanismes ou de modalités. Du point de vue de l'architecture, les modalités de détection sont moins importantes que la manière dont les informations sont transmises du capteur au cloud.
3.3 Cloud
Le cloud se compose de 4 éléments principaux :
a. une plateforme, qui fournit une connexion sécurisée au système sur site, à la télémétrie et à la gestion des appareils. Un hub permet la communication à distance vers et depuis les systèmes sur site, sur plusieurs sites si nécessaire. Il gère généralement tous les aspects de la communication, y compris la gestion des connexions, la sécurité des voies de communication, ainsi que l'authentification et l'autorisation des appareils. Il applique également des quotas de connexion et de débit. La télémétrie et les autres messages provenant des appareils sont entrés dans le cloud et l'échange de messages est géré par le hub.
b. stockage pour conserver les données
c. traitement pour analyser les données
d. interface utilisateur et visualisation pour transmettre les résultats de l'analyse à l'utilisateur final, généralement via une interface de navigateur Web, mais dans le cas d'alarmes, par e-mail, SMS et/ou appel vocal.
3.4 Connectivité : configurations
La connectivité transfère les données vers le cloud et les commandes et informations de configuration vers le sud. Les informations d'authentification et d'autorisation pour des communications sécurisées sont également transférées vers le nord/sud. La structure de ce chemin de communication suit trois modèles décrits ci-dessous et illustrés à la figure 3.1.
1. Capteurs vers le cloud : le format de capteur/cellulaire à unité unique permet une connexion directe au cloud depuis le site.
2. Capteurs vers la passerelle vers le cloud : la configuration la plus courante implique une passerelle (voir la section suivante) qui assure la connexion entre les capteurs et le cloud. La passerelle dispose généralement d'options de connexion filaire et sans fil. L'option sans fil sera généralement un capteur/émetteur à unité unique, comme illustré à la figure 3.1.
3. Capteurs vers émetteur vers récepteur vers passerelle vers cloud : cette configuration est typique des installations existantes où il y a des émetteurs et des récepteurs et/ou où il y a un nombre important de capteurs câblés situés à une certaine distance de l'emplacement de la passerelle.
3.5 Connectivité : Passerelles
3.5.1 Présentation
Une passerelle sert de facilitateur de communication et, potentiellement, de plateforme de traitement des données des appareils. Son rôle est de transférer les données et les informations entre les capteurs et le cloud. Une passerelle peut également transformer les données dans le cadre du transfert. Elle prend en charge des protocoles de communication sécurisés qui incluent des informations d'authentification et d'autorisation. Une passerelle diffère d'un routeur en ce qu'elle joue un rôle actif dans la gestion de l'accès et du flux d'informations. Les passerelles peuvent être instanciées sous forme matérielle ou logicielle.
3.5.2 Passerelles matérielles
Les passerelles matérielles sont des appareils autonomes. Elles fournissent une ou plusieurs interfaces pour la connexion des capteurs vers le bas : filaire (analogique et numérique) et sans fil. Elles fournissent également un accès à Internet, soit intégré, soit via une connexion à un routeur.
3.5.3 Passerelles logicielles
Les passerelles logicielles sont installées sur des PC. Le logiciel peut fonctionner en avant-plan ou en arrière-plan, fournissant les mêmes liaisons de communication nord-sud que la passerelle matérielle, avec les interfaces physiques fournies par le PC. Les passerelles logicielles peuvent fournir des interfaces utilisateur pour l'accès à la configuration visuelle des capteurs et l'affichage des données des capteurs. Comme la passerelle logicielle fonctionne sur un PC, elle peut offrir un stockage et une visualisation des données sur site. L'accès à distance est également possible si le service informatique autorise un accès sécurisé depuis l'extérieur au réseau interne avec le PC. Si tel est le cas, la passerelle logicielle sur site peut rendre inutile la couche cloud.
3.6 Connectivité : protocoles
3.6.1 Aperçu
Le transfert de données via la solution IIoT nécessite l'utilisation de protocoles. Ces protocoles doivent être bien définis, sécurisés et, idéalement, conformes aux normes industrielles. Les spécifications techniques des protocoles peuvent inclure tout ou partie des éléments suivants : les caractéristiques physiques des connecteurs et du câblage, la manière d'établir un canal de communication, le format des données envoyées via ce canal. Le modèle OSI (figure 3.6.1 ci-dessous) décrit le protocole comme un ensemble de couches, chacune ayant une fonction spécifique.
3.6.2 Northbound : Passerelle vers/depuis le cloud
Il existe plusieurs protocoles standard pour l'interface entre la passerelle et le cloud. Quelques-uns des plus courants sont définis ci-dessous, accompagnés d'un schéma récapitulatif.
Le protocole HTTPS (Hypertext Transfer Protocol Secure) est le protocole du World Wide Web, destiné aux interactions de type requête/réponse. Le « S » dans « HTTPS » signifie « Secure » (sécurisé). Le protocole HTTP est basé sur du texte et donc assez verbeux, mais facile à mettre en œuvre.
Le protocole AMQP (Advanced Message Queueing Protocol) est un protocole de transfert de messages multiplexé, bidirectionnel et orienté connexion, avec un codage de données compact et inhérent. Contrairement aux protocoles plus anciens tels que HTTP, AMQP a été conçu pour les connexions de type IIoT au cloud.
MQ Telemetry Transport (MQTT). MQTT est un protocole de transfert client-serveur léger pour les messages. MQTT est utile pour les appareils IIoT en raison de son espace de code compact et de la petite taille de ses trames de messages.
Constrained Application Protocol (CoAP). Le Constrained Application Protocol est un protocole basé sur des datagrammes qui peut être mis en œuvre sur une couche de transport telle que UDP. Le CoAP peut être considéré comme une version compacte du HTTP, conçue pour répondre aux besoins de l'IIoT.
3.6.3 Southbound : passerelle vers/depuis les capteurs
À l'instar des protocoles northbound, il existe également de nombreuses options pour la connexion southbound entre la passerelle et le ou les capteurs. Ces options incluent les protocoles northbound énumérés précédemment. Cependant, en raison des contraintes liées aux appareils et aux installations sur site, telles que les systèmes de production et les réseaux déjà déployés, ces protocoles ont tendance à être développés en interne ou à constituer une norme de facto établie par un seul fournisseur pour ses produits. Citons par exemple : Zigbee, Bluetooth, WiFi, USB, SimpliciTI. Ces protocoles couvrent différents domaines de la pile OSI. Par exemple, Zigbee spécifie la couche réseau et les couches supérieures, tandis que le WiFi ne spécifie que les couches liaison de données et physique. Cette séparation des fonctionnalités permet également de combiner et d'associer certains protocoles.
4.0 Selection Guide
Le guide de sélection (figure 4.1) fournit des conseils pour choisir entre les différentes configurations de l'architecture de conception. L'accent est mis sur le choix entre le cellulaire, le sans fil ou le câblé. Le choix de la configuration sans fil ou entre les connexions câblées numériques et/ou analogiques dépend d'une analyse plus approfondie de l'application spécifique.
5.0 L'écosystème IIoT Omega Link
L'écosystème IIoT Omega Link est une instanciation de l'architecture de conception IIoT, comme illustré ci-dessous. Comme prévu, il comporte trois couches : le cloud, la connectivité (via des passerelles) et les capteurs. Il existe plusieurs options pour les passerelles, tant au niveau matériel (Omega et Avnet) que logiciel (OEG). Les capteurs sont disponibles en plusieurs formats, avec des connexions filaires et sans fil. Des protocoles standard sécurisés sont utilisés, notamment l'authentification et l'autorisation entre les couches et les appareils. Les protocoles exploitent AMQP et SimpliciTI pour permettre une configuration plug-and-play avec des produits compatibles avec l'écosystème.
6.0 Références
Architecture de référence Microsoft Azure IoT, version 2.1, 26/09/2018.
http://www.steves-internet-guide.com/internet-protocol-suite-explained/
http://www.steves-internet-guide.com/iot-messaging-protocols/
https://www.postscapes.com/internet-of-things-protocols/
Annexe A. Sécurité IIot
Les solutions IIot doivent être fiables pour fournir des données et des informations en matière d'intégrité, car elles surveillent et mesurent des systèmes et des environnements critiques. Cette fiabilité est vérifiée en s'assurant que le système est sécurisé contre les menaces. La modélisation des menaces est la meilleure approche pour concevoir la sécurité. À l'aide d'une configuration de solution IIoT type, nous pouvons identifier plusieurs zones (figure A.1). Les limites de ces zones correspondent aux points de transition des données et des informations d'un élément de la solution à un autre. Les menaces s'exerceront contre les limites de ces zones. Pour effectuer l'analyse des menaces, nous pouvons utiliser le modèle STRIDE, qui définit les menaces comme appartenant aux catégories suivantes dans le tableau ci-dessous.
Une explication détaillée de l'utilisation du modèle STRIDE dépasse le cadre de ce guide, mais la sécurité d'une solution IIoT doit être validée à l'aide de cette méthode ou d'une méthode équivalente pour chacune des zones de la figure A.1.
Qu'est-ce qu'un moteur pas à pas et un contrôleur ? – Omega Engineering Présentation des moteurs pas à pas
