La convergence IT/OT n'est-elle qu'un terme à la mode ?

Alors, la "convergence IT/OT" n'est-elle qu'un autre terme fantaisiste à la mode ?

Vous pourriez soutenir que c'est le cas. Chaque fois que quelqu'un a attrapé une nouvelle idée, il y a une tentative de la rendre mémorable et de la faire sonner comme "la meilleure nouvelle chose depuis le pain tranché". Donc, bien sûr, quelqu'un va trouver une phrase accrocheuse qui est censée inspirer le changement et qu'il peut utiliser pour le marketing.

Le fait est, cependant, que cette « convergence » de l'informatique et de l'OT n'est en réalité que la prochaine extension de l'utilisation des données.

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. L'équipement automatisé a été conçu pour exécuter une fonction spécifique qui devait être exécutée à une vitesse ou à un niveau de puissance que les humains ne pouvaient pas atteindre. Mais lorsque l'équipement automatisé tombait en panne, l'ingénieur de contrôle devait entrer dans le système pour déterminer ce qui n'allait pas. Cela nécessitait d'aller dans les registres des systèmes CPL pour rechercher des indices de la panne. Ce fut le début de l'utilisation des données de la technologie opérationnelle (OT) .

Disposer de certaines données menant au point de défaillance était bon pour les diagnostics - pour voir ce qui s'était passé à l'avance. En conséquence, les systèmes PLC ont commencé à utiliser des historiques pour conserver des flux de données plus longs provenant de capteurs, de radiateurs et d'actionneurs d'automatisation, en utilisant de grandes quantités de données OT.

En surveillant les données OT des historiques, les fonctions SCADA pourraient fournir aux opérateurs un aperçu du fonctionnement de l'équipement. Lorsqu'une panne était imminente, les fonctions SCADA permettaient aux opérateurs (ou aux superviseurs) de prendre des mesures avant que la panne ne se produise. Cela nécessitait que le système SCADA ait accès aux données des historiens et utilisait des communications propriétaires telles que MODBUS ou PROFIBUS pour mettre ces données à la disposition des opérateurs via des interfaces homme-machine (IHM). Mais la surveillance était exclusive aux performances de l'équipement, élargissant encore l'utilisation des données OT.

Grâce à l'observation de ces flux de données (jauges, écrans d'opérateur, etc.) et à une meilleure compréhension de la dérive des données, on pourrait reconnaître - via les systèmes SCADA - non seulement quand une panne d'équipement était imminente, mais que les données pouvaient également être utilisé pour analyser les défaillances de la qualité du produit lors des tests et de l'inspection - opérations qui peuvent avoir été plusieurs étapes plus tard dans le processus.

Cela a créé un besoin d'avoir des données OT liées aux données informatiques. Cela a abouti à la création d'interfaces complexes allant des automates programmables et SCADA aux systèmes de technologie de l'information (TI) comme le MES, permettant de relier les données relationnelles de défaillance du produit aux données opérationnelles de l'équipement fabriquant le produit. Certains l'ont également essayé directement vers l'ERP (et essaient toujours), mais les systèmes ERP ne sont pas équipés pour traiter et présenter ces données assez rapidement et de manière suffisamment détaillée par rapport à d'autres événements au cours du processus de fabrication.

Le problème avec les interfaces avec le MES est qu'elles sont hautement personnalisées et coûteuses, ajoutant parfois jusqu'à 40 à 50 % du coût de mise en œuvre d'un projet. La prochaine étape dans l'amélioration de l'accès aux données consisterait à rendre les données API plus accessibles au MES et à d'autres bases de données relationnelles. Lorsque ce besoin d'accès est combiné avec le coût de l'informatique et de la mémoire informatique devenant moins cher et la communication réseau devenant plus stable (entrent dans les réseaux 5G), il était logique de connecter les capteurs et actionneurs CPL directement aux réseaux informatiques (ce que nous appelons IIoT) et mettre leurs données à la disposition de... quiconque en a besoin.

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

Comment utiliser la convergence IT/OT ?

L'interfaçage des données OT avec les systèmes informatiques se heurte désormais à un nouveau problème.

Les systèmes PLC/SCADA qui surveillent les capteurs dans les historiques peuvent créer de grands flux de données (jusqu'à des mégaoctets) en quelques secondes. Du point de vue de la compréhension de la caractérisation d'un événement jusqu'aux systèmes informatiques, cependant, ce flux de données, même dans des délais courts, est tout simplement trop lourd à gérer pour les bases de données relationnelles des systèmes informatiques comme le MES. De nombreuses implémentations ont essayé d'enregistrer une instance de données de capteur (extraites d'un flux de données) pour capturer un élément de données unique, pour tenter une représentation des événements OT au niveau informatique. 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 les moyens 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. La déclaration de l'OEE 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 l'OEE est utilisé comme objet de données de niveau surveillance et non comme objet de niveau analyse. Cependant, en surveillant la valeur en temps réel de l'évolution de l'OEE, un système informatique peut reconnaître le taux et l'ampleur des changements et créer une alarme pour alerter d'un problème.

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

Le problème est de savoir comment agréger les données ?

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

La façon d'agréger les données dépendra des données que vous agrégez et de ce que vous essayez de surveiller dans le cadre du processus. Cela dépendra également de la capacité à interpréter les modifications du modèle d'agrégation des données.

Dans cette section, j'examinerai une de ces méthodes d'agrégation et présenterai quelques-unes 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 tels que des capteurs. La prémisse principale de la courbe est que, si s'il n'y a qu'une variation aléatoire normale dans un processus, la distribution des instances de données tombera dans un modèle ressemblant à une courbe de distribution naturelle.

La figure 1 montre à quoi pourrait ressembler la distribution des lectures 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 indiquant la moyenne, la médiane et le mode. Avec l'aimable autorisation de l'auteur.

Les principales caractéristiques de la courbe sont que la moyenne (moyenne), la médiane (valeur médiane 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 est utile de déterminer les valeurs +/-3 sigma et de les comparer aux limites de contrôle supérieure et inférieure et aux limites de spécification du produit.

Un exemple de scénario

Pour surveiller le processus d'une unité de production passant par un four de durcissement, le système MES prendrait note de l'heure à laquelle l'unité est entrée et sortie du four. Pendant ce temps, le système PLC (utilisant un capteur intelligent) créerait un flux constant de données de capteur de température qui seraient stockées dans une base de données historique locale dans le dispositif de détection. Lorsque l'unité de production sortait du four, le MES faisait une demande à l'appareil pour un agrégat des données de température pendant cette période de temps définie. Même avec une puissance de calcul limitée disponible au niveau de l'appareil, l'appareil peut 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 généralement le cas. , ou en essayant de traiter l'intégralité du flux de données.

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 UCL et LCL)

En effectuant 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 changements de tendance par rapport aux unités de production précédentes qui sont déjà passées par le four. Si les valeurs de +/- 3 sigma sont au-delà des limites acceptables, le MES marquera automatiquement l'unité de production comme suspecte, de même si la moyenne, la médiane ou le mode diffèrent 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 maîtrisé. Dans ce cas, cependant, il est toujours possible que les valeurs +/- 3 sigma soient dans les limites.

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

Maintenant, techniquement, si la distribution est asymétrique comme indiqué, 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 l'appareil peut toujours être utilisée pour déterminer si les limites de contrôle ont été violées.

Le point clé :s'il s'agit du type d'ensemble de données fourni par un capteur intelligent, cela indique à l'ingénierie de fabrication que le four n'est pas fonctionnant uniquement avec une variance aléatoire - et doit donc être étudiée.

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

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

Que le produit ait échoué en raison de problèmes de processus ou non, voir des valeurs de données dériver pendant un cycle de production peut également indiquer des problèmes fondamentaux de gestion de processus qui doivent être étudié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 destinés à fournir une vue sur les raisons pour la convergence des données OT et IT ainsi que la valeur potentielle de cette convergence . Dans chaque scénario de production, la bonne méthode d'agrégation des données devrait être évaluée et la programmation des appareils intelligents devrait rendre cette fonctionnalité disponible. Ou, comme alternative, des systèmes informatiques de pointe seraient programmés pour remplacer la fonctionnalité décrite pour les appareils intelligents.

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

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