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 :
- 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.
- 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.
- 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 :
- Parcourez chaque échantillon du tableau.
- Soustrayez la moyenne de l'échantillon.
- Mettez l'écart au carré.
- Accumulez les écarts au carré.
- Divisez par N pour obtenir la variance.
- Appliquez SQRT pour obtenir l'écart-type.
- Multipliez l'écart-type par 3.0.
- Ajoutez et soustrayez cette valeur de la moyenne pour créer les limites de contrôle supérieure et inférieure.
- Comparez la pression actuelle par rapport à ces limites.
- 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.
- 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.
- Définition opérationnelle du « correct »
- 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.
- Le cas de défaut injecté
- La révision effectuée
- 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
Related reading
Explore the full Ladder Logic Mastery hub →Related reading
Related article 1 →Related reading
Related article 2 →Related reading
Related article 3 →Related reading
Practice this workflow in OLLA Lab ↗