Hackaton Fluvius : Défi relevé

Comme vous le savez chez Berger-Levrault, nous n'avons pas peur des défis, au contraire, nous les relevons avec plaisir !
Performance des actifs 4.0 est une conférence et une exposition virtuelles pour apprendre comment les nouvelles technologies 4.0 et les principes fondamentaux de l'exploitation, de la maintenance et de la gestion des actifs se renforcent mutuellement pour améliorer la fiabilité des équipements et la performance des coûts dans les industries à forte intensité d'actifs. Cette conférence et exposition virtuelle aura lieu du 15 au 17 septembre 2020.
Avant la conférence, Performance des actifs 4.0 a organisé 3 Hackathons sur des sujets récents liés à la maintenance.
CARL Software a participé à l'un des Hackathons, dont le thème est :

“Fluvius : prédiction des pannes à partir des données des capteurs et de l'humidité.“

Suite à sa présentation, CARL Software a été l'un des finalistes du défi.

Le contexte

1. Système actuel :

Actuellement, les sous-stations électriques sont équipées de capteurs d'humidité et de température. La condensation (résultat d'une humidité élevée et d'une température basse) peut réduire la durée de vie des équipements électriques. Il est donc nécessaire de détecter les défaillances du système de chauffage et la présence d'eau dans les sous-sols.
Aujourd'hui, cette détection est effectuée par un seuil fixe de température et d'humidité. Ce seuil peut être ajusté manuellement et il n'existe donc pas de système intelligent qui utiliserait des données historiques ou contextuelles pour améliorer le seuil.

Cependant, le système est sujet à un taux élevé de fausses alarmes, ce qui signifie qu'il y a beaucoup d'alertes et finalement de vrais dommages, ce qui tend à nous les faire ignorer. Or, en réduisant les seuils pour diminuer les alertes, on risque de passer à côté de défaillances.
En conclusion, dans les deux cas, le système d'alerte devient obsolète.

2. les améliorations souhaitées

L'objectif principal du projet est d'améliorer le système d'alerte. Il est fortement suggéré de le faire en définissant des seuils plus intelligents basés sur des données historiques (observations précédentes) et/ou des données contextuelles (météo, type de bâtiment, etc.). Les fausses alarmes doivent être évitées, ou au moins détectées pour annuler l'alerte. La livraison souhaitée n'est pas une solution complète mais une liste d'étapes de traitement des données pour rendre le seuil plus intelligent.
Nous avons pu détecter différents types de phénomènes sur les données, en fonction du capteur. Suite aux analyses, nous avons pu réfléchir à des suggestions.

Notre approche

• Des prévisions temporelles pour tirer la sonnette d'alarme :
  Grâce à la mise en œuvre de Modèles ARIMAnous pouvons prévoir les prochaines valeurs en utilisant celles de l'Union européenne.
  Cela nous permet de détecter les défaillances du système de chauffage.
  Cependant, cette méthode consiste à modifier la distribution des données.

• 

• 

• Nivelez les données en soustrayant la moyenne mobile :
  Pour éviter le problème mentionné ci-dessus, nous pouvons soustraire leur moyenne mobile de la série chronologique.
  C'est simple, mais cette proposition peut manquer de précision quant à l'endroit où les changements se produisent.

• 

• 

• Adapter le modèle avec la détection des changements :
  Une façon plus sophistiquée de traiter le problème mentionné est de détecter les changements brusques dans la distribution et d'entraîner un nouveau modèle chaque fois qu'un changement se produit. Cela évite de déclencher de fausses alarmes lorsque
  les changements se produisent, mais il est possible que des défaillances précédemment détectées deviennent invisibles. L'utilisation conjointe des différentes méthodes est donc nécessaire.

• Améliorer les seuils avec la moyenne mobile :
  Puisque nous pouvons maintenant détecter les défaillances, les seuils peuvent être adaptés en utilisant la moyenne mobile comme base. Les alarmes seront beaucoup moins nombreuses de cette façon.

• Détecter les défaillances des capteurs grâce à l'analyse multivariée :
  Nous voulons utiliser les corrélations entre les variables pour détecter les capteurs défectueux. En effet, lorsqu'un capteur génère des valeurs incorrectes, cela peut déclencher de fausses alertes. Cependant, si une seule variable est affectée, cela signifie que le capteur est probablement défectueux, et nous pouvons éviter de déclencher une alerte pour panne.

• 

• 

Résultat de ce défi

Nous avons choisi de répondre à ce défi par une liste de suggestions, mais nous nous sommes surtout concentrés sur l'utilisation de Modèles ARIMA pour prédire correctement la série temporelle donnée. Cependant, notre expérience nous a permis de suggérer d'autres possibilités à explorer afin d'améliorer le système d'alerte.
A notre avis, les différentes suggestions faites doivent être utilisées ensemble et adaptées à chaque station. L'objectif est que les utilisateurs reçoivent des alarmes de différentes sources avec la possibilité de :

• Désactivez ceux qui ne sont pas utiles,
• Donnez la priorité aux plus intéressants,
• Croisez-les pour en générer de nouvelles (par exemple ALARM_3 = ALARM_1 ET ALARM_2 ou ALARM_6 = ALARM_4 NOR (ALARM_5 ET ALARM_3)),
• Ajustez les paramètres de leurs seuils en fonction de la confiance dans les autres alarmes.

Il serait également possible de développer une visualisation des données permettant aux utilisateurs de jouer avec les données et les solutions pour les expérimenter dans un terrain de jeu.
Pour la suggestion concernant la stratégie d'analyse actuelle, nous ne voyons pas la nécessité de modifier le système actuel de rapport quotidien.
Cependant, il serait plus pratique d'avoir la même stratégie d'échantillonnage (en d'autres termes, la même période entre les mesures) pour tous les capteurs afin de mieux utiliser les variables corrélées.

Annexes

ARIMA et SARIMA sont des adaptations de Modèles ARMA. Les objectifs de ces derniers sont de faire de la prévision de séries temporelles (prédire l'observation future avec la seule connaissance des observations passées). Elle est proche de la régression linéaire avec l'utilisation des données passées comme prédicteurs.
Un site Modèle ARMA est composé de deux parties. La première est la composante AR (Auto-Regressive), qui définit la relation entre une observation au moment présent et celles des moments précédents. La seconde est sa composante MA (Moving Average), qui définit la relation entre une observation au moment présent et les erreurs résiduelles du moment présent et des moments précédents. Il est important de noter que, théoriquement, un processus doit être stationnaire pour pouvoir être strictement décrit par une Modèle ARMA.

Cependant, la stationnarité du processus est difficile à obtenir car les séries temporelles ont des composantes non stationnaires (tendance et saisonnalité). Il existe toujours des moyens de transformer le processus jusqu'à ce que la stationnarité puisse être acceptée.
La première consiste à différencier la série temporelle pour supprimer la tendance. Le premier ordre de différentiation applique l'opérateur 1-𝐿 au processus, le second ordre l'opérateur (1-𝐿)2 et le troisième ordre l'opérateur (1-𝐿)3.
𝑑-ème ordre l'opérateur (1-𝐿)𝑑, avec 𝐿 l'opérateur défini par 𝐿(𝑋𝑡)=𝑋𝑡-1 ((1-𝐿)(𝑋𝑡)=𝑋𝑡-𝑋𝑡-1). Si 𝑌𝑡=(1-𝐿)𝑑(𝑋𝑡) est un processus 𝐴𝑅𝑀𝐴(𝑝,𝑞), alors 𝑋𝑡 est un processus 𝐴𝑅𝐼𝑀𝐴(𝑝, 𝑑, 𝑞).
La seconde consiste à prendre également en compte la saisonnalité avec un processus 𝑆𝐴𝑅𝐼𝑀𝐴(𝑝, 𝑑, 𝑞)×(𝑃, 𝐷, 𝑄)𝑠 où le processus extrait du 𝑌𝑡=𝑋𝑖+𝑠*𝑡, 𝑖∈⟦0, 𝑠-1⟧ est un processus 𝐴𝑅𝐼𝑀𝐴(𝑃,𝐷,𝑄).

Explication des processus SARIMA :
https://www.youtube.com/watch?v=YIoBRDueHKo
Même s'il est écrit pour les utilisateurs de Python, le guide suivant est utile pour comprendre comment paramétrer un modèle ARIMA :
https://www.machinelearningplus.com/time-series/arima-model-time-series-forecasting-python/

Pour plus de détailsn'hésitez pas à lire l'article ci-dessous :
Hackaton-Fluvius-2020