Cyclicité des données : comprendre ce que c’est

Lorsque l’on traite un problème de data science, tous les projets ne se ressemblent pas. En fonction des données et de l’objectif visé, différentes méthodologies sont applicables au problème. La meilleure méthodologie dépend de nombreuses caractéristiques du problème : Quantité de données, présence d’un historique de pannes, etc…

Ici nous allons voir un des critères utilisés chez Amiral Technologies pour caractériser les données : la cyclicité des données.

Des données cycliques ? C’est quoi ?

Au plus simple, ce que nous nommons “données cycliques” sont des données issues d’une mesure d’un phénomène se répétant dans le temps. Dans ce cas, chaque cycle de mesures est l’ensemble des mesures temporelles (pression, température, courant, etc…) lié à l’un de ces phénomènes.

Figure 1: Exemple de mesure cyclique : les cycles d’une batterie 

Ici nous pouvons voir un exemple issu de mesures lors de cycles de charge et de décharge d’une batterie (lien du dataset). C’est un cas simple de cyclicité, où les données des différents cycles de charge constituent un ensemble de données cycliques, chaque cycle étant « 1 rechargement de la batterie ».   

Les données cycliques constituent un type de problème qui se retrouve régulièrement lors de l’analyse de données. L’intérêt principal d’identifier ce type particulier est qu’il est possible d’appliquer des algorithmes spécifiques pour traiter ces cas.

Quelles sont les conditions précises pour avoir des données cycliques ?

« Avoir un phénomène qui se répète » est une définition peu formelle de « données cycliques », et peut porter à confusion. Les vols d’un avion peuvent être vus comme un phénomène qui se répète, le « phénomène » ici étant le vol. Mais le comportement entre chaque vol peut varier énormément, par exemple en fonction des conditions météos ou du trajet effectué. Dans ce cas, les données ne sont pas considérées comme cycliques, car l’essentiel des variations dans les données sont liées à la nature du vol. A l’opposé, un bras robotique qui effectue en boucle la même opération de découpe, en prenant toujours le même temps, aura des données parfaitement cycliques.

En fait, pour avoir des données cycliques, il faut que les variations entre deux cycles soient le plus possible liées à l’état de santé du système que l’on souhaite étudier, et non pas à des variations dans le contexte d’utilisation.
Dans le cas où la très grande majorité des variations est due au contexte d’utilisation, les données ne sont pas considérées comme cycliques. En partant de ce pire cas, il existe tout un spectre de cas intermédiaires où les deux sources de variations sont présentes, jusqu’au cas idéal où les variations sont uniquement liées à l’état du système étudié. Plus les données sont proches du cas cyclique idéal, et plus les méthodes cycliques ont des chances de fonctionner.

En pratique, ce sont généralement les points suivants qui sont à vérifier pour savoir s’il est possible d’approcher le problème avec un point de vue de « données cycliques » :

  • Chaque cycle doit être de même longueur, ou au moins d’une longueur similaire.
    • Par exemple, pour les cycles de charge d’une batterie, le temps n’est pas exactement le même, mais il est comparable, et le système suit la même logique temporelle.
    • Au contraire, pour les vols d’un avion, il est évident que les temps seront très variables.

 

  • Les données de chaque cycle doivent être comparables, et issues d’un phénomène similaire
    • Comme évoqué précédemment, il faut regarder si les différences entre chaque cycle sont plutôt liées à une variation du système étudié, ou si elles dépendent essentiellement du contexte d’utilisation.
    • L’idée derrière est d’estimer si les variations intrinsèques aux systèmes ne vont pas être masquées dans les données par des variations de contexte.

Dans la pratique, il existe quelques subtilités que nous allons détailler ci-dessous.

Longueur du cycle

Lorsque les données sont issues d’une opération répétitive effectuée par une machine, généralement les cycles sont directement de même longueur. Les légères variations éventuelles peuvent être corrigées en rééchantillonnant les données. C’est le cas simple, où la “longueur” similaire est une longueur temporelle : chaque cycle fait le même temps, et il est donc clair que les données issues de ces cycles sont des séries temporelles de même longueur.
Par exemple dans le cas précédemment cité du chargement d’une batterie, la durée des cycles varie en moyenne de 4%, par rapport à la durée moyenne d’un cycle. Dans ce cas il est possible de rééchantillonner tous les cycles pour qu’ils soient de même longueur sans perte significative d’information.

Figure 2: Distribution de la longueur des cycles dans l’exemple des batteries

Il existe également des cas plus subtils, où les données peuvent se ramener à des cycles de même longueur par rapport à une longueur et non à un temps. C’est le cas de certains systèmes rotatifs, comme par exemple une turbine. Dans ces cas, si on considère un cycle comme les mesures (notamment vibrations) effectuées lors d’un tour de la turbine, alors les cycles varient en durée et dépendent fortement de la vitesse de rotation de la turbine. Mais en exprimant les variables mesurées en fonction de l’angle actuel de la turbine et non en fonction du temps, chaque cycle est alors de la même longueur, et peut éventuellement être traité par des méthodes cycliques.

Comparabilité

Avoir des cycles de même longueur ne suffit pas, il faut également avoir des données comparables. Par exemple, de nombreux échantillons de 30 secondes de mesures (température, pression, courant, etc…) pris aléatoirement sur une machine ne sont généralement pas comparables. Si la machine fait de nombreuses opérations différentes, alors l’opération en cours au moment de l’échantillon va être généralement le principal facteur qui influe sur les données mesurées, ce qui va avoir tendance à cacher les différences liées aux anomalies.

Dans un cas idéal, les mesures formant les cycles sont issues d’une même opération similaire répétée : le même mouvement pour un bras robotique, le même test de résistance d’une pièce, la même phase de démarrage, etc.

Un cas particulier régulier est lorsque les contextes influent beaucoup sur les données, mais il n’existe que quelques contextes différents d’utilisation dans le cadre du problème étudié. Dans ce cas il est possible d’avoir un modèle par contexte, s’il y a suffisamment de données pour apprendre à les reconnaitre. Cet apprentissage du contexte est important, car en prédiction de panne sans label historique, les contextes inédits sont très souvent catégorisés comme des pannes.

Le mot de la fin

Dans cet article, nous avons vu ce qu’étaient des données cycliques. Ce sont des données segmentées en cycles, ou chaque cycle correspond à la répétition d’un phénomène similaire, c’est-à-dire que les variations entre chaque cycle sont essentiellement dues à des changements intrinsèques au système étudié.

Dans la pratique, Il n’existe pas de cas idéal, mais simplement des cas où les méthodes cycliques sont plus appropriées. Dans ces contextes, il est en particulier possible d’utiliser des techniques spécifiques de génération de features. Ces techniques permettent par exemple d’améliorer les performances de modèles de détection de pannes à l’aveugle.

DiagFit contient un outil de génération de features très discriminants, analysant l’évolution temporelle de chaque cycle. Cette étape de génération de features permet la haute performance des modèles lors de l’apprentissage sur les données. Au lieu d’apprendre les modèles sur les données brutes, les données sont d’abord transformées en utilisant un générateur de features (éventuellement combiné avec d’autres techniques), puis les modèles sont construits sur ces données transformées.

Dans un prochain article, nous présenterons un cas concret d’utilisation de DiagFit pour la détection d’anomalie sans label historique, avec des données cycliques.

En savoir plus sur DiagFit, notre logiciel de prédiction de pannes en mode aveugle : https://www.amiraltechnologies.com/actualite/2020/09/diagfit-1-5/

Article de Vincent Heurtin, ingénieur calcul scientifique chez Amiral Technologies

Latest posts