IA en automatisation industrielle

Guide de l’article

Comment concevoir une détection de défaillance statistique 3 Sigma pour les pompes en Ladder Logic

Apprenez à implémenter une logique de moyenne mobile et d'écart-type dans un automate (PLC) pour détecter les anomalies de pression des pompes plus tôt que les alarmes de seuil bas fixes, et comment valider l'interverrouillage en toute sécurité dans OLLA Lab.

Réponse directe

La détection de défaillance de pompe 3 Sigma utilise des statistiques mobiles au sein de l'automate pour identifier un comportement analogique anormal avant qu'un seuil d'alarme fixe ne soit franchi. En calculant une moyenne mobile et un écart-type à partir d'échantillons de pression récents, la logique Ladder peut déclencher un arrêt sur des anomalies basées sur la variance, telles que la cavitation, les fuites ou des conditions de débit instables.

Ce à quoi cet article répond

Résumé de l’article

La détection de défaillance de pompe 3 Sigma utilise des statistiques mobiles au sein de l'automate pour identifier un comportement analogique anormal avant qu'un seuil d'alarme fixe ne soit franchi. En calculant une moyenne mobile et un écart-type à partir d'échantillons de pression récents, la logique Ladder peut déclencher un arrêt sur des anomalies basées sur la variance, telles que la cavitation, les fuites ou des conditions de débit instables.

Les alarmes statiques de basse pression sont une défense tardive, et non un système d'alerte précoce. Au moment où la pression de refoulement tombe enfin en dessous d'un seuil de déclenchement fixe, la pompe peut déjà subir une cavitation, une détérioration des joints ou une instabilité de débit visible dans le signal depuis plusieurs secondes.

Lors de la validation d'un scénario de pompe centrifuge dans OLLA Lab, un seuil de variance 3 Sigma sur un signal de pression de refoulement simulé de 4–20 mA a détecté des anomalies de perte de débit 4,2 secondes plus rapidement qu'une alarme de basse pression statique conventionnelle, et a déclenché un arrêt sécurisé avant que les dommages simulés aux joints ne surviennent [Méthodologie : n=24 cycles de défauts simulés dans un scénario de pompe centrifuge ; comparateur de référence = déclenchement sur basse pression fixe uniquement ; fenêtre temporelle = apparition de l'anomalie jusqu'à l'assertion de l'alarme sur un régime d'échantillonnage de 100 ms]. Il s'agit d'un benchmark interne Ampergon Vallis, et non d'une revendication de performance industrielle générale.

Le point technique est simple : les analyses dans le cloud sont utiles pour l'examen des tendances, mais l'interverrouillage déterministe appartient au contrôle en périphérie (edge). Si la logique doit agir immédiatement, l'automate ne doit pas attendre un historien, un tableau de bord ou un réseau qui pourrait être indisponible.

Pourquoi exécuter le contrôle statistique des processus (SPC) au niveau de l'automate ?

Le contrôle statistique des processus au niveau de l'automate est précieux car il combine la détection d'anomalies avec une action déterministe. La distinction est importante : les analyses peuvent expliquer une défaillance après coup, mais les interverrouillages doivent prévenir les dommages en temps réel.

Trois avantages pratiques justifient l'exécution d'une logique SPC bornée dans l'automate :

  1. Interverrouillage déterministe L'automate peut activer une alarme, arrêter un moteur ou inhiber un redémarrage dans le cycle normal de balayage et de sortie. C'est matériellement différent d'attendre une évaluation côté cloud et le retour du message.
  2. Résilience du réseau La logique de protection reste active même si la liaison IT/OT est coupée, si le broker est bloqué ou si l'historien compresse le signal en quelque chose de moins utile pour une détection rapide des défauts.
  3. Visibilité du signal haute fréquence L'automate voit l'entrée analogique au rythme de la tâche de contrôle. Un historien ne le fait souvent pas. Les flottements rapides, l'instabilité intermittente et les excursions de courte durée sont précisément les comportements que les seuils fixes manquent en premier.

Cela ne signifie pas que chaque fonction de maintenance prédictive appartient au Ladder Logic. Les diagnostics à long terme, les analyses de flotte et la planification de la maintenance basée sur des modèles sont généralement mieux gérés en amont. L'automate est l'endroit approprié pour une logique statistique bornée et déterministe qui doit influencer immédiatement l'état de la machine.

Du point de vue des normes, cette séparation est cohérente avec la discipline d'allocation fonctionnelle dans les systèmes de contrôle industriel : l'action protectrice doit rester déterministe et testable, tandis que les analyses consultatives peuvent se situer ailleurs (IEC, 2010 ; IEC, 2016). Différentes couches ont différentes obligations.

Quel est le calcul derrière la variance 3 Sigma en Ladder Logic ?

La logique 3 Sigma est un écart-type mobile appliqué à une balise de processus en direct. La formule est familière ; les détails de mise en œuvre sont là où les projets d'automate deviennent coûteux.

Pour une fenêtre d'échantillonnage de N lectures de pression :

μ = (1/N) × Σxᵢ

  • Moyenne

σ² = (1/N) × Σ(xᵢ - μ)²

  • Variance

σ = √σ²

  • Écart-type

UCL = μ + 3σ LCL = μ - 3σ

  • Limites de contrôle 3 Sigma

Si la valeur de pression actuelle tombe en dehors de cette bande, la logique active un bit d'anomalie statistique.

Blocs mathématiques requis en Ladder Logic

Une mise en œuvre pratique nécessite généralement ces types d'instructions :

  • Logique FIFO / FFL / décalage de tableau pour maintenir une fenêtre d'échantillonnage mobile
  • AVE ou logique ADD/DIV explicite pour calculer la moyenne mobile
  • SUB pour calculer l'écart par rapport à la moyenne
  • MUL pour mettre au carré l'écart
  • ADD pour accumuler les écarts au carré
  • DIV pour calculer la variance
  • SQRT pour calculer l'écart-type
  • MUL à nouveau pour générer la bande 3 Sigma
  • CMP / LIM / GRT / LES pour déclencher la condition d'anomalie

L'hypothèse sous-jacente est que le bruit du signal de base est approximativement stable et suffisamment bien comporté pour qu'une bande d'écart-type soit significative. Les signaux de pompe réels ne sont pas des distributions normales de manuel, et aucun ingénieur compétent ne devrait prétendre le contraire. Mais pour une détection d'anomalie bornée sur un régime de fonctionnement stable, la logique 3 Sigma est souvent utile car elle est simple, transparente et testable.

Comment programmer une moyenne mobile pour les capteurs de pression analogiques ?

Une moyenne mobile commence par un échantillonnage discipliné et des types de données corrects. Si le signal de pression analogique est stocké sous forme d'entiers puis divisé comme si la précision était facultative, les calculs seront trompeurs.

### Étape 1 : Échantillonner l'entrée analogique à un intervalle fixe

Utilisez une temporisation ou une tâche périodique pour échantillonner l'entrée de pression à un rythme constant. Un point de départ courant est :

- Intervalle d'échantillonnage : 100 ms - Taille de la fenêtre : 50 échantillons - Fenêtre d'observation : 5 secondes

Cela donne suffisamment d'historique récent pour détecter l'instabilité sans rendre la bande de contrôle trop lente.

### Étape 2 : Stocker les échantillons dans un tableau REAL

Utilisez des types de données REAL pour :

  • la pression actuelle
  • les éléments du tableau
  • la moyenne mobile
  • la variance
  • l'écart-type
  • les limites de contrôle supérieure et inférieure

Cela évite la troncature lors de la division et préserve la résolution analogique. La logique statistique construite sur des mathématiques entières est souvent une source silencieuse de mauvaises décisions.

### Étape 3 : Maintenir la fenêtre mobile

Implémentez une routine FIFO ou un décalage de tableau équivalent afin que chaque nouvel échantillon entre dans la fenêtre et que l'échantillon le plus ancien soit supprimé. Les contrôles clés sont :

  • le nombre d'échantillons valides
  • les limites du tableau
  • l'état d'initialisation
  • le comportement avant que le tableau ne soit entièrement rempli

Ne calculez pas la variance sur un tampon vide ou partiellement indéfini à moins que la logique ne gère explicitement cette condition. Les erreurs de division par zéro ne sont pas la preuve d'analyses avancées.

### Étape 4 : Calculer la moyenne mobile

Une fois le tableau rempli :

  • additionnez toutes les valeurs des échantillons
  • divisez par le nombre d'échantillons valides
  • stockez le résultat sous `Rolling_Mean`

Si votre plateforme prend en charge une instruction de moyenne, utilisez-la. Sinon, une sommation explicite convient, à condition que le coût d'exécution soit acceptable pour la période de la tâche.

Notes de mise en œuvre pratique

Un ensemble de barreaux (rungs) robuste comprend généralement :

  • un bit Data_Ready une fois la fenêtre d'échantillonnage pleine
  • une condition permissive Stats_Enable liée à l'état de fonctionnement de la pompe
  • une inhibition Bad_Input_Quality si le signal analogique est invalide, hors plage ou obsolète
  • un Startup_Mask_Timer pour éviter les alarmes intempestives pendant les transitoires

C'est là que le jugement de mise en service compte. Une pompe qui démarre, s'arrête ou change de mode de fonctionnement n'est pas statistiquement anormale en soi ; elle change simplement d'état. La logique doit connaître la différence.

Où OLLA Lab devient opérationnellement utile

OLLA Lab fournit un environnement borné pour tester cette logique de tableau avant qu'elle n'atteigne un contrôleur réel. Dans l'éditeur Ladder basé sur navigateur, les ingénieurs peuvent construire la structure FIFO, exécuter la logique en mode simulation et utiliser le panneau des variables pour observer le remplissage du tableau en temps réel.

Cela compte car « prêt pour la simulation » devrait signifier quelque chose d'observable. Opérationnellement, cela signifie qu'un ingénieur peut prouver, observer, diagnostiquer et durcir la logique de contrôle contre un comportement de processus réaliste avant qu'elle n'atteigne un processus réel. La syntaxe n'est qu'une partie de cela. La déployabilité est la partie la plus difficile.

Comment calculer l'écart-type et définir l'interverrouillage 3 Sigma ?

La séquence de barreaux pour l'écart-type doit être explicite, bornée et facile à tester. Si la logique est trop intelligente pour être révisée, elle est trop intelligente pour être fiable.

Séquence Ladder étape par étape

Une fois la moyenne mobile calculée :

  1. Parcourez chaque échantillon du tableau.
  2. Soustrayez la moyenne de l'échantillon.
  3. Mettez l'écart au carré.
  4. Accumulez les écarts au carré.
  5. Divisez par N pour obtenir la variance.
  6. Appliquez SQRT pour obtenir l'écart-type.
  7. Multipliez l'écart-type par 3.0.
  8. Ajoutez et soustrayez cette valeur de la moyenne pour créer les limites de contrôle supérieure et inférieure.
  9. Comparez la pression actuelle par rapport à ces limites.
  10. Verrouillez une alarme d'anomalie statistique si le signal est en dehors de la bande.

Exemple de logique de type Ladder

// Calculer la bande 3 Sigma MUL Standard_Deviation 3.0 Sigma_Band ADD Rolling_Mean Sigma_Band Upper_Control_Limit SUB Rolling_Mean Sigma_Band Lower_Control_Limit

// Déclencher l'alarme d'anomalie GRT Current_Pressure Upper_Control_Limit OTL Pump_Stat_Anomaly LES Current_Pressure Lower_Control_Limit OTL Pump_Stat_Anomaly

Considérations sur la conception de l'interverrouillage

Un interverrouillage utilisable nécessite généralement plus qu'une simple instruction de comparaison. Envisagez d'ajouter :

  • une temporisation de persistance pour qu'un échantillon bruyant ne déclenche pas la pompe
  • une séparation entre alarme et déclenchement
  • une inhibition de réarmement automatique jusqu'à l'examen par l'opérateur
  • des permissifs basés sur le mode pour que la maintenance ou le mode manuel ne déclenchent pas de faux arrêts
  • un journalisation des événements pour la moyenne, le sigma, la valeur actuelle et l'état de fonctionnement au moment du déclenchement

Un modèle propre est :

  • première violation → définir Stat_Alarm
  • violation soutenue pendant une durée définie → définir Trip_Request
  • arrêt confirmé → verrouiller Pump_Faulted

Cette séquence est plus facile à dépanner qu'un seul barreau qui fait tout mal.

Une correction qui vaut la peine d'être faite

La logique 3 Sigma ne remplace pas les limites de processus. Elle les complète. Vous avez toujours besoin d'une logique de basse pression, de marche à sec, de surcharge et de permissifs. La détection statistique détecte les comportements anormaux tôt ; les limites de protection fixes gardent toujours la limite d'un fonctionnement sûr.

Comment la logique 3 Sigma détecte-t-elle les fuites et la cavitation des pompes plus tôt que les alarmes statiques ?

La logique de variance détecte l'instabilité avant l'effondrement de la valeur absolue. C'est l'avantage principal.

Une petite fuite de joint, un problème d'aspiration ou un événement de cavitation précoce peut produire :

  • un flottement de pression
  • une augmentation de l'amplitude d'oscillation
  • des creux et des récupérations intermittents
  • un comportement de débit instable autour d'une valeur moyenne autrement acceptable

Une alarme fixe telle que « Déclencher si pression < 50 PSI » ignore tout cela jusqu'à ce que le signal franchisse enfin la ligne. À ce moment-là, la condition mécanique peut déjà se dégrader.

Une bande 3 Sigma réagit au comportement du signal par rapport à sa ligne de base récente. Si la pompe fonctionne normalement à 72 PSI avec une faible dispersion et commence soudainement à osciller entre 66 et 78 PSI, l'écart-type augmente même si la moyenne reste au-dessus du seuil de déclenchement statique. C'est souvent le premier avertissement utile.

Ce n'est pas de la magie, et ce n'est pas universel. Si le processus lui-même est naturellement instable, une alarme de variance peut simplement vous dire que le processus est variable. La méthode fonctionne mieux lorsqu'elle est appliquée à un régime de fonctionnement stable avec un comportement normal connu, un déclenchement par mode approprié et une fenêtre d'échantillonnage validée.

La recherche en surveillance de l'état et en détection d'anomalies soutient la valeur des caractéristiques sensibles à la variance pour les équipements rotatifs et les systèmes de processus, en particulier lorsqu'elles sont combinées avec des seuils spécifiques au domaine et un contexte opérationnel (Jardine et al., 2006 ; Lei et al., 2020 ; Yin et al., 2014). La mise en œuvre dans un automate est plus simple que de nombreuses approches basées sur des modèles, mais l'exigence de discipline d'ingénierie ne disparaît pas.

Comment choisir la fenêtre d'échantillonnage, la stratégie de balayage et la persistance de l'alarme ?

La fenêtre d'échantillonnage doit correspondre à la dynamique du processus, pas à la patience de l'ingénieur. Une fenêtre de 50 échantillons à 100 ms peut être raisonnable pour une pompe et inefficace pour une autre.

Facteurs de sélection de la fenêtre

Choisissez la fenêtre mobile en fonction de :

  • temps de réponse du capteur
  • dynamique de la pompe et de la tuyauterie
  • fréquence de perturbation attendue
  • temps de balayage et charge du contrôleur
  • tolérance aux alarmes intempestives
  • vitesse de réponse requise

Une fenêtre courte réagit plus vite mais est plus bruyante. Une fenêtre longue est plus fluide mais plus lente. La bonne réponse est généralement trouvée en testant les cas de défaut, et non en débattant sur des chiffres ronds.

Considérations sur le balayage et l'exécution

La logique statistique consomme des ressources du contrôleur. Dans un balayage d'automate séquentiel, les calculs de tableau répétés et les opérations en virgule flottante peuvent devenir coûteux, surtout sur les petits processeurs ou les tâches encombrées.

Surveillez :

  • la croissance du temps de balayage
  • les dépassements de tâches périodiques
  • les erreurs d'index de tableau
  • les conditions de division par zéro
  • les valeurs REAL non initialisées
  • la fréquence de recalcul excessive

Un modèle sensé est de :

  • échantillonner à un intervalle fixe
  • calculer les statistiques uniquement lorsqu'un nouvel échantillon arrive
  • séparer les interverrouillages de haute priorité des analyses de priorité inférieure
  • comparer l'impact du balayage pendant la validation

C'est une raison pour laquelle la simulation est importante. Il est moins coûteux de découvrir qu'une routine mathématique est abusive dans un environnement virtuel que pendant le démarrage avec les opérations en attente.

Persistance de l'alarme

Utilisez une temporisation de persistance ou une confirmation basée sur le comptage avant de déclencher. Les modèles courants incluent :

  • anomalie présente pendant 500 ms
  • 3 échantillons sur 5 consécutifs en dehors de la bande
  • violations répétées dans un seau temporel mobile

Cela réduit les déclenchements intempestifs tout en préservant la détection précoce. La valeur exacte doit être justifiée par rapport au risque de processus et à la vulnérabilité de la pompe, et non copiée sans validation.

Comment OLLA Lab simule-t-il les fuites de pompe pour la validation de la logique ?

La logique de variance doit être testée contre une perturbation dynamique, pas un forçage statique. Une valeur constante forcée ne prouve pas grand-chose au-delà du fait que le simulateur peut maintenir un nombre.

Dans OLLA Lab, les ingénieurs peuvent valider cette logique dans un environnement de répétition basé sur le Web qui combine l'exécution Ladder, l'inspection des variables en direct et le comportement simulé de l'équipement. Le flux de travail pertinent est borné et pratique :

  • construire la logique Ladder dans l'éditeur basé sur navigateur
  • exécuter le programme en mode simulation
  • surveiller la balise de pression, la moyenne, le sigma et les bits d'alarme dans le panneau des variables
  • injecter une perturbation analogique dans le signal de pression
  • observer l'état de la pompe simulée et la réponse au défaut

Modèles de perturbation utiles à injecter

Pour les tests d'anomalie de pompe, les cas les plus informatifs sont :

  • dérive analogique pour simuler une dégradation graduelle
  • perturbation en onde carrée pour simuler un comportement de processus instable
  • augmentation de l'amplitude du bruit pour simuler le début de la cavitation ou le flottement de pression
  • changement d'étape plus oscillation pour tester la logique de récupération et la temporisation de persistance

Le but n'est pas de créer des défauts théâtraux. Le but est de créer des signatures de défauts répétables et bornées et de vérifier que la logique répond comme prévu.

Ce que signifie la validation par jumeau numérique ici

La « validation par jumeau numérique » doit être utilisée avec précaution. Dans ce contexte, cela signifie valider la logique de contrôle par rapport à un modèle d'équipement simulé réaliste et un comportement de processus observable avant le déploiement. Cela ne signifie pas que la simulation est un substitut certifié pour les tests d'acceptation sur site, la vérification SIL ou la mise en service de l'usine.

Cette limite est importante. Un simulateur peut exposer les défauts de logique, les erreurs de séquençage et une mauvaise gestion des défauts tôt. Il ne peut pas certifier le câblage sur site, la qualité de l'installation des instruments, la réalité hydraulique ou la réponse de l'opérateur dans les conditions réelles de l'usine. Quiconque brouille ces catégories vend du confort plutôt que des preuves d'ingénierie.

Quelles preuves d'ingénierie devez-vous conserver lors de la construction d'une détection de défaillance statistique ?

Un dossier de projet crédible est un ensemble compact de preuves d'ingénierie, pas une galerie de captures d'écran. Si vous voulez que le travail soit révisable par un ingénieur principal, un instructeur ou un responsable du recrutement, documentez la logique comme un système de contrôle mérite d'être documenté.

Utilisez cette structure :

Indiquez ce qui compte comme un comportement réussi. Exemple : « L'automate doit activer une alarme d'anomalie statistique dans un délai de 1,0 seconde après une instabilité de pression soutenue et déclencher la pompe si l'anomalie persiste pendant 2,0 secondes en état Auto et Run. »

Spécifiez la perturbation appliquée : dérive, oscillation, augmentation d'amplitude, décrochage ou défaut mixte.

Documentez ce qui a changé après les tests : taille de la fenêtre, temporisation de persistance, masque de démarrage, seuil de comparaison ou permissif de mode.

  1. Description du système Définissez le système de pompe, la balise analogique surveillée, les modes de fonctionnement et l'action protectrice prévue.
  2. Définition opérationnelle du « correct »
  3. Logique Ladder et état de l'équipement simulé Enregistrez les barreaux pertinents, la liste des balises, l'intervalle d'échantillonnage, la longueur du tableau et l'état de fonctionnement de la pompe simulée pendant le test.
  4. Le cas de défaut injecté
  5. La révision effectuée
  6. Leçons apprises Indiquez ce que le test a exposé. De bons exemples incluent les faux positifs pendant le démarrage, le coût de balayage excessif ou un mauvais comportement pendant le remplissage partiel du tampon.

C'est le genre de preuve qui soutient l'examen technique. Elle montre la cause, l'effet, la révision et le jugement. Une capture d'écran seule montre généralement seulement que quelqu'un a capturé un écran.

Quelles normes et limites techniques comptent lors de l'utilisation d'interverrouillages statistiques sur les pompes ?

La logique d'anomalie statistique doit être traitée comme une amélioration diagnostique ou protectrice à moins d'être formellement conçue autrement. Ce n'est pas automatiquement une fonction de sécurité simplement parce qu'elle déclenche l'équipement.

Trois limites méritent d'être énoncées clairement :

Si la fonction fait partie d'un système instrumenté de sécurité, elle doit être conçue, validée et maintenue selon les exigences pertinentes du cycle de vie de sécurité. La nouveauté statistique n'exempte personne de la discipline IEC 61508 ou IEC 61511 (IEC, 2010 ; IEC, 2016).

  • Une alarme de variance n'est pas une revendication SIL.

La simulation peut valider le comportement de la logique et exposer les défauts tôt, mais elle ne remplace pas les FAT, SAT, vérifications de boucle ou la mise en service sur le processus réel.

  • La simulation n'est pas une preuve sur le terrain.

Un transitoire de démarrage, une course de vanne ou un transfert de service peut ressembler à un défaut si la logique n'est pas déclenchée par l'état du processus.

  • La détection anormale nécessite un contexte de mode.

Pour une pratique de fiabilité plus large, la littérature sur la surveillance de l'état souligne systématiquement que la qualité de la détection des défauts dépend de la qualité du signal, du contexte opérationnel et de la validation par rapport à des signatures de défauts connues, et non de la simple présence d'un algorithme (Jardine et al., 2006 ; Lei et al., 2020). En d'autres termes, une formule n'est pas encore une méthode.

References

Continuez à explorer

Related Reading

Transparence éditoriale

Cet article de blog a été rédigé par un humain, avec toute la structure de base, le contenu et les idées originales créés par l’auteur. Toutefois, cet article inclut un texte affiné avec l’assistance de ChatGPT et Gemini. L’IA a été utilisée exclusivement pour corriger la grammaire et la syntaxe, ainsi que pour traduire le texte original en anglais vers l’espagnol, le français, l’estonien, le chinois, le russe, le portugais, l’allemand et l’italien. Le contenu final a été relu, édité et validé de manière critique par l’auteur, qui en assume l’entière responsabilité quant à son exactitude.

À propos de l’auteur:PhD. Jose NERI, Lead Engineer at Ampergon Vallis

Vérification: Validité technique confirmée le 2026-03-24 par l’équipe QA du laboratoire Ampergon Vallis.

Prêt pour la mise en œuvre

Utilisez des workflows appuyés par la simulation pour transformer ces enseignements en résultats mesurables pour l’installation.

© 2026 Ampergon Vallis. All rights reserved.
|