Une taxonomie pour l'IIoT

Les rois jouent aux échecs sur des tabourets en verre fin. Quelqu'un s'en souvient ?

Pour la plupart, c'est probablement du charabia. Mais pas pour moi. Ce mnémonique m'aide à me souvenir de la taxonomie de la vie :Royaume, Phylum, Classe, Ordre, Famille, Genre, Espèce.

L'étendue, la profondeur et la variété de la vie sur Terre sont écrasantes. Une taxonomie divise logiquement les types de systèmes par leurs caractéristiques. La science de la biologie serait impossible sans une bonne taxonomie. Il permet aux scientifiques de classer les plantes et les animaux en types logiques, d'identifier les points communs et de construire des règles pour comprendre des classes entières de systèmes vivants.

L'étendue, la profondeur et la variété de l'Internet industriel des objets (IIoT) sont également écrasantes. La science des systèmes IIoT a besoin d'une taxonomie organisée de la même manière des types d'applications. Ce n'est qu'alors que nous pourrons discuter des architectures et des technologies appropriées pour mettre en œuvre des systèmes.

Le premier problème est de choisir des divisions de niveau supérieur. Dans le règne animal, vous pouvez étiqueter la plupart des animaux soit des animaux "terrestres, marins ou aériens". Cependant, ces descriptions environnementales n'aident pas beaucoup à comprendre l'animal. L'« architecture » d'une baleine ne ressemble pas beaucoup à une pieuvre, mais elle ressemble beaucoup à un ours. Pour être compris, les animaux doivent être divisés par leurs caractéristiques et leur architecture.

Il n'est pas non plus utile de diviser les applications par leurs industries telles que « médical, transport et énergie ». Bien que ces environnements soient importants, les architectures et technologies applicables ne se divisent tout simplement pas selon les secteurs d'activité. Ici encore, nous avons besoin d'une compréhension plus approfondie des caractéristiques qui définissent les défis majeurs, et ces défis détermineront l'architecture.

Je me rends compte que c'est une affirmation puissante, voire choquante. Cela implique, par exemple, que les normes, protocoles et architectures sur mesure dans chaque industrie ne sont pas des moyens utiles pour concevoir les futures architectures des systèmes IIoT . Néanmoins, c'est un fait clair des systèmes sur le terrain. Comme dans la transformation qu'est devenue l'Internet d'entreprise, les technologies génériques remplaceront les approches spécialisées. Pour approfondir notre compréhension et réaliser la promesse de l'IIoT, nous devons abandonner notre vieille pensée spécifique à l'industrie.

Alors, que pouvons-nous utiliser pour les divisions? Quelles caractéristiques déterminantes pouvons-nous utiliser pour séparer les mammifères des reptiles des insectes de l'IIoT ?

Il existe des milliers et des milliers d'exigences, à la fois fonctionnelles et non fonctionnelles, qui pourraient être utilisées. Comme chez les animaux, nous devons trouver ces quelques exigences qui divisent l'espace en grandes catégories utiles.

La tâche est simplifiée par la réalisation que l'objectif est de diviser l'espace afin que nous puissions déterminer l'architecture du système . Ainsi, de bons critères de division sont a) non ambigus et b) impactants sur l'architecture. Cela peut sembler facile, mais c'est en fait très peu trivial. La seule façon de le faire est par l'expérience. Nous sommes au début de notre quête. Cependant, des progrès significatifs sont à notre portée collective.

À partir de la vaste expérience de RTI avec près de 1000 applications IIoT du monde réel, je suggère quelques premières divisions ci-dessous. Pour être aussi précis que possible, j'ai également choisi des « métriques » pour chaque division. Les lignes, bien sûr, ne sont pas si nettes. Mais les chiffres imposent la clarté, et c'est essentiel; sans repères numériques (mètres ?), le sens est trop souvent perdu.

Proposition de taxonomie IIoT

Fiabilité [Métrique :La disponibilité continue doit être meilleure que "99,999 %"]

Nous ne pouvons pas nous contenter de la platitude « hautement fiable ». Presque tout « a besoin » de ça. Pour être significatif, nous devons être plus précis sur les exigences architecturales pour atteindre cette fiabilité. Cela nécessite de comprendre à quelle vitesse une panne cause des problèmes et à quel point ces problèmes sont graves.

Nous avons découvert que le moyen le plus simple et le plus utile de catégoriser la fiabilité est de se demander :« Quelles sont les conséquences d'une panne inattendue pendant 5 minutes par an ? » (Nous choisissons 5 min/an ici uniquement parce qu'il s'agit de la spécification d'or « 5-9s » pour les serveurs de classe entreprise. De nombreux systèmes industriels ne peuvent pas tolérer même quelques millisecondes de temps d'arrêt inattendu.)

Il s'agit d'une caractéristique importante car elle a un impact considérable sur l'architecture du système. Un système qui ne peut pas échouer, même pour une courte période, doit prendre en charge l'informatique redondante, les capteurs, la mise en réseau, etc. Lorsque la fiabilité est vraiment critique, elle devient rapidement un — ou peut-être le — moteur architectural clé.

Temps réel [Métrique :Réponse < 100 ms]

Il existe des milliers de façons de caractériser le « temps réel ». Tous les systèmes doivent être « rapides ». Mais pour être utile, nous devons spécifiquement comprendre quelles exigences de vitesse pilotent l'architecture.

Une architecture qui peut satisfaire un utilisateur humain ne voulant pas attendre plus de 8 secondes pour un site Web ne satisfera jamais un contrôle industriel qui doit répondre en 2 ms. On retrouve le « coude dans la courbe » qui impacte fortement la conception se produit lorsque la vitesse de réponse est mesurée en quelques dizaines de millisecondes (ms) voire microsecondes (µs). Nous choisirons 100 ms, simplement parce qu'il s'agit de la gigue potentielle (latence maximale) imposée par un serveur ou un courtier dans le chemin des données. Les systèmes qui répondent beaucoup plus rapidement que cela doivent généralement être peer-to-peer, ce qui a un impact architectural énorme.

Échelle de l'ensemble de données [Métrique :taille de l'ensemble de données > 10 000 éléments]

Encore une fois, il existe des milliers de dimensions à mettre à l'échelle, notamment le nombre de « nœuds », le nombre d'applications, le nombre d'éléments de données, etc. Nous ne pouvons pas diviser l'espace par tous ces paramètres. En pratique, ils sont liés. Par exemple, un système avec de nombreux éléments de données a probablement de nombreux nœuds.

Malgré le vaste espace, nous avons constaté que deux questions simples sont en corrélation avec les exigences architecturales. Le premier est la "taille de l'ensemble de données", et le genou dans la courbe est d'environ 10 000 éléments. Lorsque les systèmes deviennent aussi gros, il n'est plus pratique d'envoyer chaque mise à jour des données à chaque récepteur possible. Ainsi, la gestion des données elle-même devient un besoin architectural clé. Ces systèmes ont besoin d'une conception « centrée sur les données » qui modélise explicitement les données, permettant ainsi un filtrage et une livraison sélectifs.

Échelle d'équipe ou d'application [Métrique :nombre d'équipes ou d'applications en interaction> 10]

Le deuxième paramètre d'échelle que nous choisissons est le nombre d'équipes ou d'applications développées indépendamment sur le « projet », avec un point d'arrêt autour de 10. Lorsque de nombreux groupes indépendants de développeurs créent des applications qui doivent interagir, le contrôle de l'interface de données domine le défi de l'interopérabilité. Encore une fois, cela indique souvent le besoin d'une conception centrée sur les données qui modélise et gère explicitement ces interfaces.

Défi de découverte des données d'appareils [Métrique :>20 types d'appareils avec des ensembles de données à plusieurs variables]

Certains systèmes IIoT peuvent (ou même doivent) être configurés et compris avant l'exécution. Cela ne signifie pas que toutes les sources et tous les récepteurs de données sont connus, mais plutôt que cette configuration est relativement statique.

Cependant, lorsque les systèmes IIoT intègrent des racks et des racks de machines ou d'appareils, ils doivent souvent être configurés et compris pendant le fonctionnement. Par exemple, une IHM de contrôleur d'usine peut avoir besoin de découvrir les caractéristiques d'un appareil ou d'un rack installé afin qu'un utilisateur puisse choisir les données à surveiller. Le choix de « 20 » appareils différents est arbitraire. Le point :lorsqu'il existe de nombreuses configurations différentes pour les appareils dans un rack, cette « introspection » devient un besoin architectural important pour éviter la gymnastique manuelle. La plupart des systèmes dotés de cette caractéristique ont bien plus de 20 types d'appareils.

Focus de distribution [Métrique :Déploiement > 10]

Nous définissons le « fan out » comme le nombre de destinataires de données qui doivent être informés du changement d'un seul élément de données. Cela a un impact sur l'architecture car de nombreux protocoles fonctionnent via des connexions uniques 1:1. La plupart du monde de l'entreprise fonctionne de cette façon, souvent avec TCP, un protocole de session 1:1. Les exemples incluent la connexion d'un navigateur à un serveur Web, d'une application téléphonique à un backend ou d'une banque à une société émettrice de cartes de crédit.

Cependant, les systèmes IIoT ont

[1] [2] 下一页