Sur le terrain, l'un des défis récurrents en maintenance prédictive sur pompes centrifuges est de gérer les faux positifs générés par des seuils de vibration trop rigides. J'ai souvent vu des équipes déclencher des interventions coûteuses — ou ignorer des alarmes devenues bruyantes — parce que le seuil était calibré une fois, puis figé. Dans cet article, je partage ma méthode pour mettre en place des seuils adaptatifs de vibration qui réduisent les faux positifs tout en maintenant une sensibilité suffisante pour détecter les vrais problèmes.

Pourquoi les seuils fixes posent problème

Un seuil fixe (par ex. 4 mm/s RMS) est simple à implémenter et rassurant, mais il oublie la réalité opérationnelle : charge variable, démarrages/arrêts fréquents, variations hydrauliques, changements saisonniers, et même la variabilité entre unités similaires. Ces facteurs créent des fluctuations de bruit de fond qui, si elles ne sont pas prises en compte, génèrent des alarmes inutiles.

Principes de base d'un seuil adaptatif

  • Mesurer la dynamique normale en continu plutôt que définir une limite unique.
  • Séparer les états de fonctionnement (idle, charge partielle, pleine charge) pour avoir des références par mode.
  • Utiliser des métriques robustes (RMS, enveloppe, kurtosis, spectre) et combiner-les.
  • Appliquer des méthodes statistiques et temps réel (moyennes mobiles, percentiles, détection de changement) pour faire évoluer le seuil.

Étapes concrètes pour calibrer un seuil adaptatif

Voici une méthode que j'ai utilisée sur plusieurs sites industriels, intégrée parfois via des solutions SCADA/IIoT (ex. Siemens MindSphere, Emerson AMS, SKF @ptitude ou plateformes basées sur ThingWorx).

  • Phase 0 — Inventaire et segmentation: identifier tous les états de fonctionnement de la pompe (démarrage, régime transitoire, régime stable, variations de débit) et associer des tags opérationnels (capteurs de débit, fréquence variateur, état pompe).
  • Phase 1 — Collecte de base: acquérir des données de vibration sur une période représentative (typiquement 2–4 semaines) avec une fréquence d'échantillonnage suffisante pour capturer les harmoniques (≥10 kHz pour enveloppe si on surveille roulements, sinon 2–5 kHz pour signaux globaux).
  • Phase 2 — Nettoyage et attribution d'état: filtrer les segments de données par état de fonctionnement; supprimer les données corrompues ou les événements extrêmes connus (arrêt d'urgence).
  • Phase 3 — Calcul de référence dynamique: pour chaque état, calculer les statistiques robustes: médiane, écart interquartile (IQR), percentiles 90/95, RMS moyen et écart-type, kurtosis.
  • Phase 4 — Définition du seuil adaptatif: définir le seuil comme une fonction des statistiques, par exemple: seuil = médiane + k * IQR, ou seuil = percentile95 + margin (où k et margin sont ajustés selon criticité).
  • Phase 5 — Application en ligne et lissage temporel: mettre en place un algorithme qui met à jour la référence avec une fenêtre glissante (ex. rolling 7 jours) et applique un filtrage pour éviter les réactions à des pics transitoires (ex. exiger dépassement > t secondes).
  • Phase 6 — Validation terrain: surveiller le taux d'alarmes vs interventions pendant 30–90 jours, ajuster k/margin et la logique de suppression d'alarme (hystérésis, votes sur multi-capteurs).

Exemples de formules de seuil

Voici des formules simples que j'utilise comme point de départ :

Seuil basé sur médiane/IQRSeuil = médiane_mesure + 1.5 * IQR_mesure
Seuil basé sur percentilesSeuil = percentile95_mesure + 0.1 * percentile95_mesure
Seuil hybride RMS+KurtosisSi kurtosis > 3 (pics impulsifs) alors seuil = RMS_median * 0.8 sinon seuil = RMS_median * 1.2

Ces coefficients (1.5, 0.1, 0.8/1.2) sont à ajuster en fonction de la criticité et des retours terrains.

Traitement du signal et choix des indicateurs

Sur pompes centrifuges, certains indicateurs sont particulièrement utiles :

  • RMS — bon pour l'énergie globale du signal.
  • Enveloppe — très utile pour détecter problèmes de roulements ou cavitation (impulsions).
  • Spectre (FFT) — pour identifier déséquilibres, désalignements, défauts de pales selon harmoniques.
  • Kurtosis & crest factor — détectent l'apparition d'impulsions; précieux pour capter défauts naissants.

Je recommande de calculer plusieurs indicateurs et de les combiner dans une logique de vote : par exemple, déclencher alarme seulement si au moins deux indicateurs dépassent leur seuil.

Gestion des variations opérationnelles

La clé d'un système adaptatif efficace est la contextualisation. Quelques pratiques que j'applique :

  • Associer les seuils à des plages de fréquence du moteur (pour pompes variées par variateur). Un même niveau de vibration peut être normal à 3000 tr/min mais critique à 1500 tr/min.
  • Utiliser des entrées processus (débit, pression, position vanne) pour exclure certains transitoires du calcul des références.
  • Intégrer des fenêtres de non-alarme lors des démarrages/arrêts (paramétrables selon la courbe de montée en charge).

Algorithme en temps réel : exemple simple

Voici un pseudo-algorithme que j'ai déployé sur des contrôleurs edge (ex. National Instruments, Advantech ou gateways IIoT) :

  • Collecter mesures vibration toutes les secondes.
  • Attribuer état opératoire (via tag PLCSpeed, flow).
  • Pour l'état courant, mettre à jour rolling_window (dernières 7j ou 10k mesures).
  • Calculer median et IQR; seuil = median + 1.5 * IQR.
  • Si mesure instantanée > seuil pendant plus de T_hold (ex. 60 s) —> flag d'alerte locale.
  • Validation serveur : si alerte persistante et confirmée par spectre/enveloppe —> notification maintenance.

Réduire les faux positifs avec des stratégies complémentaires

  • Vote multi-capteurs: utiliser capteurs sur paliers opposés; un seul capteur qui dépasse peut être bruit local.
  • Validation spectrale: exiger la présence d'harmoniques caractéristiques (ex. fréquence de balourdissement, fréquence de défaut de roulement) pour valider l'alerte.
  • Machine Learning léger: modèles de clustering (k-means, isolation forest) pour repérer comportements anormaux sans étiquettes. J'ai utilisé Isolation Forest pour prioriser événements et réduire le bruit.
  • Feedback humain: intégrer un mécanisme de labelisation simple : technicien confirme/infirme alarme; cela améliore un modèle supervisé ultérieur.

Outils et plateformes

Sur plusieurs projets j'ai intégré ces approches via :

  • Solutions de condition monitoring dédiées : SKF @ptitude, Emerson AMS — pour pipelines de diagnostic et offres d'alarme avancées.
  • Plateformes IIoT : ThingWorx, Siemens MindSphere — pour l'orchestration, le stockage temporel et la mise à jour des seuils.
  • Edge computing : gateways Advantech, NI ou solutions basées sur Raspberry Pi + logiciels open-source (Prometheus + Grafana pour visualisation).

La bonne pratique est d'installer une boucle d'amélioration continue : mesurer, ajuster, valider, et incorporer le retour des équipes de maintenance. Les seuils adaptatifs ne sont pas une magie — ils demandent un peu de governance, mais ils rendent la surveillance bien plus robuste et crédible vis-à-vis des opérationnels.