La démarche de création de modèle en vue de la prédiction de pannes peut s’avérer difficile, semée d’embuches et parfois déceptive.
La première source de déception peut venir du fait que les modèles générés peuvent paraître opaques quant à l’information fournie à l’utilisateur pour pouvoir remonter à la panne observée. On observe une réticence des industriels, parfois à juste titre, à « faire confiance » à une intelligence artificielle et de perdre « la maîtrise » de leurs interventions.
Quelle méthodologie suivre pour générer des modèles prédictifs dont le diagnostic est suffisamment explicable pour vaincre cette réticence ?
Lors de précédents articles « Analyser, nettoyer et transformer des séries temporelles industrielles » puis « Une exploration aux profondeurs des séries temporelles » nous avons mis en avant des outils qui permettent de bien explorer la donnée en vue d’en maitriser le contenu (matrice de corrélation, exploration fréquentielle, etc.).
Dans cet article nous allons vous présenter comment à la suite de l’analyse, la création de groupes de capteurs associés à des modèles monocapteur et multicapteurs permet de favoriser l’explicabilité de l’indicateur final sur lequel se base le diagnostic.
Créer des groupes de capteurs pour mieux cibler chaque problématique
Grâce à notre expérience sur des cas d’usages variés, nous sommes venus à la conclusion que les modèles de prédiction de pannes étaient plus explicables et permettaient une analyse des causes racines plus fine, lorsque ceux-ci étaient composés de « sous-modèles » spécialisés.
En effet, la création de groupes de capteurs permet d’isoler les caractéristiques qui les lient (présentées ci-dessous) et permet alors de les analyser séparément. En isolant unitairement les « problèmes » dans des groupes, lorsqu’une anomalie sera détectée, il sera plus facile de l’identifier et de remonter à sa cause. On améliore ainsi considérablement l’explicabilité.
Groupes « Spatiaux »
Dans le contexte de la supervision d’un équipement complexe, type avion, train ou robot mécanique, il est souvent pertinent de décomposer l’équipement en sous-systèmes, regroupant chacun, un sous-groupe de capteurs. Ce faisant, des capteurs qui sont spatialement cohérents ensembles et qui ont un lien physique se retrouveraient dans le même groupe : les capteurs du moteur, les capteurs de la roue etc. Cela permettra, par la suite, d’associer à ces sous-groupes de capteurs, des modèles qui caractériseront la normalité spécifique à certaines dynamiques ou certains dysfonctionnements au niveau local.
En plus de cette décomposition, il convient d’ajouter des indicateurs mettant en jeux des représentants de chaque sous-groupe afin d’identifier des effets de corrélation sur des capteurs qui n’appartiennent pas nécessairement au même groupe.
Bien que l’idée semble être intuitive et allant de soi, il n’en demeure pas moins vrai que procéder à cette décomposition d’une manière automatique, générique et agnostique à l’équipement spécifique, ne va pas de soi. Dans la suite, quelques éléments de solution sont discutés.
Groupes de « Corrélation »
Grâce à la matrice de corrélation présentée dans un article précédent il est possible d’identifier si les comportements des signaux de certains capteurs ont des synergies au cours du temps qui plaide en faveur de leur inclusion dans un même sous-groupe.
En effet, si deux capteurs ou plus ont des signaux qui évoluent ensemble au cours du temps, les isoler dans un groupe permettra de leur attacher un algorithme et des caractéristiques qui se focaliseront sur l’analyse de ces synergies et sur ces liens inter-capteurs.
Certaines variables du modèle permettront alors de surveiller la normalité de ces synergies par rapport à celles observées lors de l’apprentissage.
Groupes de « Fréquence »
Nous avons pu identifier dans un article précédent que l’analyse d’un même signal à travers différentes bandes de fréquences peut permettre de débruiter celui-ci et ainsi de révéler des pannes qui étaient masquées par le signal complet.
Isoler les capteurs par groupe de fréquence, par exemple isoler les hautes fréquences des basses fréquences, permet donc de sélectionner des algorithmes et caractéristiques multivariés qui seront pertinents dans l’analyse des synergies inter-capteurs sur cette bande de fréquence spécifique.
Générer des modèles univariés et/ou multivariés
Les modèles multi capteurs
Les modèles mono capteur
Comme précédemment mentionné, la création de groupes, qu’elle se base sur la nature des capteurs, leur corrélation ou le contenu fréquentiel de leurs données, vise à permettre d’associer par la suite à chaque groupe des algorithmes pertinents en fonction de l’analyse désirée.
En utilisant cette approche, l’utilisateur sélectionne les algorithmes de détection les plus adaptés et maximise ainsi la pertinence des résultats obtenus.
Ces modèles, appelés multicapteurs car analysant plusieurs capteurs ensemble, prennent donc en compte les relations entre les capteurs et se focalisent exclusivement sur ces liens lors de la détection d’anomalie.
Dans ce cadre « mono » capteur, l’approche consiste à associer un algorithme de détection d’anomalies à un générateur de caractéristiques qui analyseront exclusivement le signal d’un seul capteur.
Ces modèles monocapteur se concentrent donc sur les dérives, les variations ou, plus généralement, l’évolution des « signatures » des séries temporelles observées. La détection de toute nouveauté dans le signal spécifique du capteur est ainsi faite sans prendre en compte les autres capteurs environnants. Dans ce contexte l’analyse se focalisera uniquement sur la dimension temporelle des séries temporelles.
💡 Pour information : L’analyse mono capteur pourrait suggérer un aspect très partiel de ce qu’est la normalité d’un équipement complexe. Cependant, il ne faut pas oublier qu’en raison du couplage inhérent aux équipements en mode « boucle fermée », ce que révèle un changement de signature d’un seul capteur va bien au-delà de ce simple capteur (ou de son sous-groupe). Puisque les incidents sur des parties de l’équipement, loin de ce capteur, impactent celui-ci par le principe de la commande en boucle fermée, alors les conséquences se réinjectent un peu partout dans l’équipement.
Déterminer l’indicateur final de détection de pannes
Une fois les étapes précédentes exécutées, on obtient un modèle par capteur ainsi que plusieurs modèles pour les sous-groupes de capteurs. Il faut maintenant définir le modèle global, qui est l’agrégation des modèles générés précédemment et qui permettra d’avoir un indicateur global qui lèvera les alarmes une fois en opération sur le terrain.
Le vote si aucun label de pannes dans les données
Dans le contexte d’une approche à l’aveugle, il se peut que le jeu de donnée utilisé pour l’entrainement ne contienne aucun « label » de pannes puisque celui-ci contient uniquement des séries temporelles dépourvues de défauts.
Dans ce contexte, on viendra tout d’abord observer un à un les indicateurs générés. On vérifiera que ceux-ci ne sont pas aberrants (trop bruités, trop de faux positifs sur des données saines gardées pour le test etc.) et on viendra les désélectionner ou modifier leur seuil et/ou le lissage au besoin.
Ensuite, l’indicateur final est généré en prenant tout simplement le maximum des indicateurs de tous les modèles générés ce qui conservera uniquement l’enveloppe globale. Ceci suppose évidemment que lesdits indicateurs auraient été préalablement normalisés afin que leurs niveaux puissent être comparés.
On obtient ainsi l’indicateur final.
Le vote si volonté de se focaliser sur un type de pannes
Dans le contexte où l’utilisateur souhaite concevoir un modèle axé sur un type spécifique de panne présent dans les données, l’étape de « voting » joue un rôle crucial. En effet, si un type de panne particulier est associé à des coûts importants pour un équipement donné, et que la priorité est de détecter ou même d’anticiper rapidement ces incidents, l’utilisateur cherchera à orienter le modèle en conséquence. Ce cas d’usage nécessite la présence, dans les données d’apprentissage d’occurrence du défaut sur lequel, l’on souhaite se focaliser.
Dans ce cas, lors de l’analyse des différents modèles générés à l’aveugle, l’utilisateur se concentrera alors sur ceux qui détectent le mieux le type de panne ciblé. Au moment du vote, plusieurs choix s’offriront à lui :
- Ne conserver que les modèles contribuant activement à la détection de ce type de panne, afin de créer un modèle final hautement spécialisé.
- Garder tous les modèles pour maintenir la possibilité de détecter d’autres types d’anomalies, tout en accordant un poids significatif aux modèles qui contribuent efficacement à la détection du type de panne spécifique, assurant ainsi une reconnaissance correcte de celle-ci.
L’explicabilité de l’indicateur final
Lorsque le modèle est déployé opérationnellement, la détection d’une anomalie indique qu’un des sous-modèles a généré un indicateur dépassant son seuil de normalité.
Grâce à la visualisation des sous-modèles et de leurs données brutes associées, l’utilisateur peut rapidement identifier celui qui est sorti de sa normalité et a provoqué la l’alarme. Cette information lui permet de remonter efficacement à la cause principale de la panne, qu’il s’agisse par exemple, d’une dérive d’un capteur (exemple, capteur S3 de la figure 4) ou d’une sortie de la normalité d’un modèle spécifique à un sous-groupe particulier de capteurs (exemple, group 1 de la figure 4). Ce dernier est souvent associé à un sous ensemble physique de l’équipement ou à un sous ensemble de phénomènes physiques mis en jeu au sein de l’équipement (électrique, mécanique, hydraulique, etc).
Cette transparence et cette explicabilité dans la détection des anomalies dissipent l’effet de « boîte noire », facilitant ainsi la rédaction du rapport de maintenance.
En fournissant une compréhension claire de la nature et de l’origine des pannes, cette approche favorise une intervention rapide et ciblée sur le terrain, contribuant ainsi à minimiser les temps d’arrêt et à améliorer la fiabilité des équipements.
Grâce à la nature itérative de cette méthodologie, l’utilisateur peut revisiter chaque étape pour améliorer la performance de son modèle final, garantissant ainsi une évolution continue et une adaptation précise aux besoins spécifiques de détection des pannes.
Bonus, ajouter un modèle supervisé dans une approche ‘à l’aveugle’
Chez Amiral Technologies nous mettons en avant l’approche non-supervisée (à l’aveugle) car celle-ci permet de mettre en œuvre une stratégie de prédiction de pannes très rapidement, sans avoir besoin de beaucoup d’historique de données de pannes et surtout parce que celle-ci sera résiliente à la nouveauté. Néanmoins lorsque les données le permettent l’apprentissage d’un modèle supervisé peut être bénéfique pour enrichir le modèle général.
Générer un modèle supervisé
Dans une approche non supervisée, la priorité réside dans une qualification précise de la normalité afin d’assurer que toute déviation détectée soit réellement une nouveauté par rapport à ce qui était présent dans les données d’apprentissage.
En revanche, dans un cadre supervisé, il est crucial de caractériser avec précision la (ou les) panne(s) que l’on souhaite identifier, garantissant ainsi sa reconnaissance adéquate par la suite.
Pour ce faire, il est essentiel d’avoir une quantité suffisante d’échantillons de la panne, qui soient représentatifs et variés en termes de contextes et d’équipements, pour permettre un apprentissage et une reconnaissance précise.
Si la base de données le permet, alors il parait pertinent de créer un modèle supervisé hautement spécialisé pour un type de pannes.
Toutefois, pour garantir la résilience du modèle face à de nouvelles données, il est recommandé de l’associer à d’autres « sous-modèles » comme présenté dans les paragraphes précédents.
Le vote avec un modèle supervisé
Tout comme dans le processus de vote où les données sont labélisées, le modèle supervisé se rajoutera aux divers modèles construits sur les données brutes, contribuant ainsi à enrichir le modèle global.
Grâce à sa spécialisation, le modèle supervisé permettra au modèle global d’atteindre une certaine pertinence dans la détection des pannes spécifiques pour lesquelles il a été conçu.
Lorsque l’utilisateur effectuera le vote final pour le modèle, il aura la liberté d’attribuer un poids prédominant ou non à ce modèle en fonction de l’importance des pannes observées, offrant ainsi une flexibilité accrue dans le processus de prise de décision.
Nouvelle release – DiagFit 3.0
Avec DiagFit 3.0, la réalisation de toutes les opérations mentionnées ci-dessus est désormais à portée de main, sans nécessité d’écrire une seule ligne de code. L’ensemble des analyses et opérations proposées (groupes de corrélation, sélection des modèles, vote etc.), sont basées sur des algorithmes propriétaires éprouvés pour les séries temporelles industrielles. L’interface intuitive est conçue pour simplifier la vie des utilisateurs, offrant une navigation fluide au cœur des séries temporelles et générant automatiquement les représentations graphiques associées aux capteurs. Grâce à un guidage étayé par notre méthodologie solide, les utilisateurs explorent leurs données pour en extraire les informations essentielles, indispensables à la mise en place d’une démarche de maintenance prédictive efficace.
