La convergence IT/OT est-elle vraiment qu'un mot à la mode ? Décryptage de sa vraie valeur

Alors, la « convergence IT/OT » n'est-elle qu'un autre terme gadget à la mode ?

On pourrait le dire. Chaque fois que quelqu'un s'empare d'une nouvelle idée, il y a une tentative pour la rendre mémorable et pour la faire sonner comme « la meilleure nouvelle chose depuis le pain tranché ». Donc, bien sûr, quelqu'un va inventer une phrase accrocheuse censée inspirer le changement, et qu'il pourra utiliser pour le marketing.

Le fait est, cependant, que cette « convergence » de l'IT et de l'OT n'est vraiment que la prochaine extension de la rendre les données utilisables.

Qu'est-ce que la convergence IT/OT ?

Il y a quelque temps, nous avons vu le début de l'automatisation dans la fabrication. Les équipements automatisés étaient conçus pour effectuer une fonction spécifique qui devait être réalisée à une vitesse ou un niveau de puissance que les humains ne pouvaient pas atteindre. Mais quand l'équipement automatisé tombait en panne, l'ingénieur contrôle devait accéder au système pour déterminer ce qui n'allait pas. Cela nécesschait d'accéder aux registres des systèmes API pour chercher des indices de la panne. C'était le début de l'utilisation des données de la technologie opérationnelle (OT).

Avoir des données menant au point de panne était bon pour le diagnostic — pour voir ce qui s'était passé avant. En conséquence, les systèmes API ont commencé à utiliser des historiseurs pour conserver des flux de données plus longs provenant de capteurs, chauffeurs et actionneurs d'automatisation — en utilisant de grandes quantités de données OT.

En surveillant les données OT des historiseurs, les fonctions SCADA pouvaient fournir aux opérateurs un aperçu du fonctionnement de l'équipement. Quand une panne était imminente, les fonctions SCADA permettaient aux opérateurs (ou superviseurs) une chance d'agir avant que la panne ne se produise. Cela nécessitait que le système SCADA ait accès aux données des historiseurs, et utilisait des communications propriétaires comme MODBUS ou PROFIBUS pour rendre ces données disponibles aux opérateurs via les interfaces homme-machine (IHM). Mais la surveillance était exclusive à la performance de l'équipement, élargissant davantage l'utilisation des données OT.

En observant ces flux de données (jauges, écrans d'opérateur, etc.) et en comprenant davantage la dérive des données, on pouvait reconnaître — via les systèmes SCADA — non seulement quand une panne d'équipement était imminente, mais que les données pouvaient aussi être utilisées pour analyser les défaillances de qualité de produit aux tests et inspections — des opérations qui pouvaient être plusieurs étapes plus loin dans le processus.

Cela a créé le besoin d'avoir les données OT liées aux données IT. Cela a abouti à la création d'interfaces complexes des API et SCADA vers les systèmes de technologie de l'information (IT) comme les MES, permettant de relier les données relationnelles de défaillance de produit aux données opérationnelles de l'équipement fabriquant le produit. Certains ont essayé directement vers l'ERP aussi (et essaient encore), mais les systèmes ERP ne sont pas équipés pour traiter et présenter ces données assez rapidement et avec assez de détails par rapport aux autres événements pendant le processus de fabrication.

Le problème avec les interfaces vers les MES est qu'elles sont hautement personnalisées et coûteuses, ajoutant parfois jusqu'à 40-50 % du coût d'implémentation d'un projet. La prochaine étape dans l'amélioration de l'accès aux données serait de rendre les données API plus accessibles aux MES et autres bases de données relationnelles. Lorsque ce besoin d'accès est combiné avec la baisse du coût de l'informatique et de la mémoire et la stabilité accrue des communications réseau (entrez les réseaux 5G), il a eu du sens de connecter les capteurs et actionneurs API directement aux réseaux IT (ce que nous appelons l'IIoT) et de rendre leurs données disponibles à... qui en a besoin.

Tout ce contexte vise à souligner que rendre les données OT plus facilement accessibles aux systèmes IT est simplement la prochaine étape dans un processus plus long d'évolution technologique qui nous a menés à l'Industrie 4.0.

Comment la convergence IT/OT peut-elle être utilisée ?

L'interface des données OT vers les systèmes IT rencontre maintenant un nouveau problème.

Les systèmes API/SCADA qui surveillent les capteurs dans les historiseurs peuvent créer de grands flux de données (jusqu'à des mégaoctets en taille) en quelques secondes. Du point de vue de la compréhension de la caractérisation d'un événement jusqu'aux systèmes IT, cependant, ce flux de données — même sur de petits intervalles de temps — est simplement trop important pour être géré par les bases de données relationnelles des systèmes IT comme les MES. De nombreuses implémentations ont essayé d'enregistrer une instance de données de capteur (prise d'un flux de données) pour capturer un seul élément de données, pour tenter une certaine représentation des événements OT au niveau IT. Beaucoup ont trouvé, cependant, que lier une instance de données OT à un événement de qualité d'un produit pendant la fabrication n'est pas très efficace pour surveiller la qualité d'un processus en général.

Nous devons maintenant déterminer des façons d'agréger les flux de données des systèmes OT d'une manière qui conserve les caractéristiques importantes d'un événement de production. Le rapport de TRS (Taux de Rendement Synthétique) est l'une de ces tentatives d'agrégation. Il est important de reconnaître que lors de l'utilisation de toute forme d'agrégation de données, il y aura une certaine perte des détails importants d'un événement de qualité. C'est pourquoi le TRS est utilisé comme objet de données de niveau surveillance et non d'analyse. Cependant, en surveillant la valeur en temps réel du TRS qui change, un système IT peut reconnaître le taux et l'ampleur des changements et créer une alarme pour alerter sur un problème.

Pour analyser ce problème réel, vous devrez revenir au flux de données original qui a été utilisé pour créer la valeur de TRS. Au moins avec la valeur de TRS fournie en temps réel, les ingénieurs de fabrication et de contrôle gagnent en visibilité sur un problème assez tôt pour pouvoir revenir à l'historiseur pour analyse avant que l'événement ne soit enterré par plus de données du flux de données OT.

La question est : comment agréger les données ?

La réponse, comme toujours, est... cela dépend !

Comment agréger les données dépendra de quelles données vous agrégez et de ce que vous essayez de surveiller dans le processus. Cela dépendra aussi de la capacité à interpréter les changements dans le modèle d'agrégation de données.

Dans cette section, j'examinerai une telle méthode d'agrégation et présenterai certaines des façons d'interpréter les changements dans cet ensemble de données.

La « courbe de distribution naturelle » ou histogramme est l'une des représentations graphiques les plus courantes des données provenant d'appareils comme les capteurs. La prémisse principale de la courbe est que, si il n'y a que une variation aléatoire normale dans un processus, la distribution des instances de données tombera dans un motif ressemblant à une courbe de distribution naturelle.

La Figure 1 montre à quoi pourrait ressembler la distribution des relevés d'un capteur de four avec une variation normale lorsqu'elle est tracée dans un histogramme.

Figure 1 : Courbe de distribution de la température du four montrant moyenne, médiane et mode. Avec l'aimable autorisation de l'auteur.

Les caractéristiques clés de la courbe sont que la moyenne, la médiane (valeur du milieu du flux de données) et le mode (valeur avec le plus d'occurrences) sont tous approximativement égaux. Cela peut être utilisé comme référence pour déterminer si le processus rencontre des problèmes. Tant qu'il y a une indication que le processus est sous contrôle, il y a de la valeur à déterminer les valeurs +/- 3 sigma et à les comparer aux limites de contrôle supérieures et inférieures et aux limites de spécification du produit.

Un scénario d'exemple

Pour surveiller le processus d'une unité de production passant par un four de cuisson, le système MES noterait l'heure d'entrée et de sortie de l'unité du four. Pendant ce temps, le système API (en utilisant un capteur intelligent) créerait un flux constant de données de capteur de température qui serait stocké dans une base de données d'historiseur local dans le dispositif de détection. Lorsque l'unité de production sort du four, le MES ferait une demande au dispositif pour un agrégat des données de température pendant cette période définie. Même avec une puissance de calcul limitée disponible au niveau du dispositif, le dispositif pourrait prendre des centaines (voire des milliers) de points de données et fournir un ensemble de données agrégées au MES — au lieu de fournir une seule instance des données du capteur, comme c'est typique, ou d'essayer de traiter le flux de données entier.

Voici un ensemble de valeurs de données agrégées pour cette unité de production :

• Moyenne : 90,0
• Médiane : serait très proche de 90,0
• Mode : environ 90,0 degrés également
• Distribution +/- 3 Sigma : 87,0, 93,0 (à vérifier avec LCS et LCI)

En faisant une analyse rapide des différences entre la moyenne, la médiane et le mode, le MES peut rechercher une surveillance de contrôle de processus acceptable ainsi que des tendances de changement par rapport aux unités de production précédentes qui sont déjà passées par le four. Si les valeurs +/- 3 sigma sont au-delà des limites acceptables, le MES signalerait automatiquement l'unité de production comme suspecte, de même si la moyenne, la médiane ou le mode différaient significativement les uns des autres ou des produits précédents.

La Figure 2 présente un exemple de la façon dont ces mêmes valeurs indiqueraient un processus qui n'était pas sous contrôle. Dans ce cas, cependant, il est encore possible que les valeurs +/- 3 sigma puissent être dans les limites.

Figure 2 : Exemple de différences de moyenne, médiane et mode dans un processus asymétrique. Avec l'aimable autorisation de l'auteur.

Maintenant, techniquement, si la distribution est asymétrique comme montré, les valeurs +/- 3 sigma peuvent ne pas être considérées comme valides en raison de la nature asymétrique de l'ensemble de données. Mais l'analyse immédiate par le dispositif peut encore être utilisée pour déterminer si les limites de contrôle ont été violées.

Le point clé : si c'est le genre d'ensemble de données fourni par un capteur intelligent, c'est une indication pour l'ingénierie de fabrication que le four n'opère pas avec seulement une variance aléatoire — et devrait donc être investigué.

D'autres différences dans la moyenne, la médiane et le mode (par exemple, la moyenne et la médiane sont égales, mais le mode est différent) peuvent également indiquer des conditions comme une distribution bimodale qui suggèrent de multiples influences de processus en jeu. Une fois de plus, l'ingénierie de fabrication devrait examiner le processus.

Lorsque les ensembles de données ci-dessus sont liés directement à l'unité de production au niveau MES, ces données peuvent être utilisées — avec les résultats de test et d'inspection — pour indiquer s'il y a un lien entre la variation de la température du four et l'échec de l'unité de production.

Que le produit ait échoué à cause des problèmes de processus ou non, voir les valeurs de données dériver pendant une série de production peut également indiquer des problèmes fondamentaux de gestion de processus qui doivent être investigués.

Résumé

Les exemples précédents d'agrégation de données ne reflètent qu'un scénario spécifique, mais ils sont censés fournir un aperçu des raisons de la convergence des données OT et IT ainsi que de la valeur potentielle de cette convergence. Dans chaque scénario de production, la méthode correcte d'agrégation de données devra être évaluée, et la programmation des dispositifs intelligents devra rendre cette fonctionnalité disponible. Ou, comme alternative, des systèmes edge computing seraient programmés pour remplacer la fonctionnalité décrite pour les dispositifs intelligents.

Le résultat final est que, bien que l'industrie utilise fortement « convergence IT/OT » comme terme à la mode pour décrire la technologie changeante, il y a un changement légitime dans le traitement des données que la technologie derrière le terme à la mode fournit. Les entreprises qui tirent parti de la technologie de convergence, et qui apprennent à agréger et interpréter correctement les données présentées via la convergence, peuvent gagner des avantages pratiques dans l'efficacité des programmes de qualité et de gestion d'installations. Dans l'environnement concurrentiel mondial d'aujourd'hui, utiliser n'importe quel avantage est bon pour le résultat net.

Donc, la réponse est non. La convergence IT/OT n'est pas seulement un terme à la mode. C'est un outil précieux dans l'évolution de la technologie d'acquisition et de gestion de données qui peut grandement bénéficier aux entreprises manufacturières. Apprendre comment agréger les données du niveau OT pour que les systèmes au niveau IT puissent les traiter est une partie importante de la convergence.