Ressources Hexagon pour vous

La méthode la plus éprouvée pour améliorer un système d'alarme.

Il existe une méthode qui, à moindre coût et avec moins d'effort, est plus efficace que toute autre technique pour améliorer un système d'alarme existant, mais sous-performant. Mais que signifie exactement "sous-performant" ? Voici quelques exemples de certains des pires systèmes d'alarme que nous avons rencontrés (et tous étaient réparables !) :

• Plusieurs systèmes de contrôle avec des alarmes individuelles qui se déclenchent plus de 100 000 fois par mois
• Un système d'alarme où plus de 70 % des déclenchements (environ mille par jour) sont causés par des instruments défectueux nécessitant une maintenance
• Un système dominé par quelques alarmes inutiles, de sorte que 98 % des déclenchements proviennent de seulement sept alarmes – plus de 600 fois par jour en moyenne
• Un système sans gestion efficace des changements, où une suppression manuelle et incontrôlée des alarmes éliminerait 98 % des occurrences d'alarme (environ 18 000 par jour) de la vue de l'opérateur. Cela peut inclure des alarmes très importantes
• De nombreux systèmes générant en moyenne plus de 25 000 alarmes par jour, certains atteignant plus de 100 000 – soit une alarme toutes les 3 secondes, voire plus d'une par seconde
• Un système constamment en inondation d'alarmes, avec une moyenne de près de 40 alarmes par minute pendant plus de quatre jours
• Une seule alarme qui s'est produite plus de 200 000 fois en UNE SEULE JOURNÉE
• Un grand site industriel avec de nombreuses unités  en réseau générant plus d'un milliard d'alarmes par an – 2,7 millions par jour

À première vue, de tels problèmes peuvent sembler accablants. Comment gérer 50 000 alarmes par jour ? Facile, non ? Avec une approche judicieuse, des cas comme ceux-ci peuvent être considérablement améliorés en quelques jours, voire quelques semaines.

Sept étapes

Il existe un processus en sept étapes pour améliorer les systèmes d'alarmes existants. Il est simple et a prouvé son efficacité dans plus de mille projets d'amélioration des alarmes.

1. Développer un document sur la philosophie des alarmes. Voilà comment bien gérer les alarmes !

2. Analyser les données d'alarme existantes pour établir un point de référence et identifier les zones problématiques.

3. Résoudre les alarmes de type « bad actor ».

4. Effectuer la documentation et la rationalisation des alarmes (D&R) et créer une base de données principale des alarmes.

5. Mettre en place une technologie d'audit des alarmes et de gestion des changements.

6. Implémenter des techniques de gestion des alarmes en temps réel, comme les alarmes basées sur l'état.

7. Contrôler et maintenir le système amélioré avec des analyses continues et des processus de travail.

Les trois premières étapes sont souvent réalisées simultanément. Ces étapes sont faciles, rapides, peu coûteuses et ne nécessitent pas beaucoup de ressources internes. Elles sont également très puissantes, c'est pourquoi elles figurent en tête.

La philosophie des alarmes est importante, mais elle n'est pas une "prérequis" pour trouver et résoudre vos alarmes les plus fréquentes. L'analyse des alarmes consiste également à mettre en place un suivi des performances du système d'alarmes. Ces deux étapes sont des exigences obligatoires de la norme ISA 18.2 de gestion des alarmes. Mais même l'analyse initiale, à elle seule, peut vous orienter vers l'étape cruciale n°3 : trouver et résoudre vos alarmes les plus fréquentes et gênantes – les "Bad Actors" !

L'étape de résolution des  « bad actors » peut réduire votre taux d'alarme de 60 % à 80 % ou plus. Cela peut résoudre des problèmes comme ceux que nous avons déjà évoqués. Cette étape peut être réalisée en quelques jours ou semaines avec un effort à temps partiel. Elle ne nécessite pas de consultants. Bien qu'il existe de nombreux problèmes qu'elle ne résout pas (comme un mauvais choix de priorité des alarmes), elle constitue un excellent point de départ pour gagner en crédibilité et entraîner toute l'équipe dans le processus d'amélioration des alarmes. Cela facilitera l'adhésion et développera l'élan.

Il existe plusieurs catégories d'alarmes inutiles (ou "Bad actors") et plusieurs méthodes pour les traiter. Avec un nombre suffisant de   « Bad Actors, un système d'alarme devient inutile. Cela peut entraîner des conditions de sécurité dangereuses, car les alarmes importantes ou critiques se perdent dans la masse des alarmes inutiles.

L'expérience montre qu'un nombre relativement restreint d'alarmes configurées provoque la majorité des déclenchements d'alarmes, ce qui alimente tous les problèmes de taux d'alarme élevés. "Relativement restreint" signifie entre 20 et 50 alarmes configurées. Personne n'a jamais conçu intentionnellement une alarme pour qu'elle se déclenche plus de 20 000 fois par mois, mais de telles alarmes existent et elles peuvent être corrigées !

Les 20 alarmes les plus fréquentes représentent généralement entre 25 % et 95 % de la charge totale du système. Si ces alarmes sont traitées efficacement, une amélioration majeure du système se produira. Il est étonnant que de telles alarmes inutiles existent, car il est peu probable que le meilleur ingénieur en contrôle d'une entreprise ait conçu des alarmes qui se comportent comme celles que nous allons décrire. Et pourtant, elles existent ; nous les trouvons dans presque tous les systèmes que nous analysons.

Figure 1 : Les 10 alarmes les plus fréquentes d'un seul système – données sur 8 semaines

Dans cet exemple, seulement 10 alarmes représentent 96 % de la charge totale du système. Ces résultats proviennent de seulement huit semaines de données, et plusieurs des alarmes se sont déclenchées plus de 100 000 fois. Ce phénomène n'était en aucun cas voulu, et corriger seulement ces 10 alarmes réduirait la charge du système de 96 %. Curieusement, cinq des 10 alarmes (les alarmes "BADPV") concernent des instruments défectueux. Corriger cinq instruments ne devrait pas être compliqué.

Voici quelques exemples avant-après de la résolution des   « Bad actors » provenant de quinze systèmes de contrôle différents :

Figure 2 : Montants de l'amélioration apportée par la résolution de l'alarme « Bad Actor »

Dans les systèmes ci-dessus, moins de 50 alarmes ont été analysées à l’aide des techniques que nous allons aborder. La réduction moyenne des alarmes obtenue a été supérieure à 65 %. Cela représente un gain substantiel pour un peu de travail ! Ne seriez-vous pas satisfait si vous analysiez environ 30 alarmes et réduisiez de plus de la moitié le taux d’alarmes ? Voici comment.

Les principaux types d'alarmes inutiles :

• Alarmes qui "cliquettent" (qui disparaissent rapidement, puis se répètent immédiatement)
• Alarmes éphémères (qui ne durent que quelques secondes avant de disparaître, puis peuvent se répéter)
• Alarmes stagnantes (qui restent actives pendant des jours, des semaines, voire des mois)
• Alarmes supprimées (l'opérateur ne les voit pas, mais leur suppression n'est pas contrôlée ni suivie)
• Alarmes dupliquées (dynamiques, où une condition génère plusieurs alarmes sur différents points)
• Alarmes dupliquées (configurées, où plusieurs points liés génèrent des alarmes si l'un d'eux se déclenche)
• Les alarmes gênantes liées à des diagnostics d'instruments (comme des alarmes de "mauvaise mesure")

Les deux premières – alarmes qui "cliquettent" et alarmes éphémères – sont les pires ! Ce sont les principales responsables des taux d'alarme élevés. Mais les résoudre nécessite souvent une technique de calcul approfondie.

Alarmes stagnantes (Longues durées)

Les alarmes stagnantes restent actives pendant des périodes prolongées. Chercher les alarmes qui sont restées actives pendant plus de 24 heures est un bon point de départ. Nous avons trouvé des alarmes restées actives pendant des mois, voire des années. (C'est incroyable ce que les gens tolèrent.) Elles encombrent les écrans d'alarmes et diminuent l'importance perçue de toutes les autres alarmes.

Y a-t-il vraiment de nombreuses conditions anormales nécessitant l'action d'un opérateur pour éviter une conséquence qui dure plus d'une journée ? Ou pendant des mois ? Ces alarmes reflètent souvent des conditions stables de l'unité, comme un équipement volontairement mis à l'arrêt. Elles correspondent généralement à des alarmes qui n'ont pas été configurées conformément aux principes du Handbook de Gestion des Alarmes.

Les alarmes stagnantes sont résolues en comprenant les états du processus et du matériel impliqué. Elles sont généralement éliminées en les reconfigurant pour se conformer à la définition d’une alarme. Les alarmes qui restent stagnantes ne sont souvent pas des alarmes en réalité – elles sont simplement des indications de statut. Elles indiquent souvent si un élément est "activé" ou "désactivé". Il ne faut quasiment jamais créer une alarme qui se base uniquement sur l'état "activé" ou "désactivé" d'un élément. Il existe toujours des circonstances valides où un élément devrait être désactivé. L'alarme devrait indiquer que "cet élément DOIT être activé mais est désactivé" (ou vice versa). Cette situation est anormale et nécessite une action de l'opérateur. La conception de cette alarme peut nécessiter un peu d'imagination ou l’implémentation d’une logique ou d’une méthode d’alarme basée sur l'état de opération de l’Equipment.

Alarmes supprimées

Lors d'une analyse initiale d'un système utilisée pour établir la liste de résolution des | « Bad actors», il est également important d'identifier toutes les alarmes configurées qui sont supprimées. Cela signifie que l'alarme est toujours configurée, mais qu'une sorte de substitution a été choisie pour éliminer son affichage à l'opérateur. Presque tous les systèmes de contrôle possèdent cette capacité, mais elle est souvent mal utilisée. La suppression d'alarme est souvent incontrôlée. Nous avons trouvé des alarmes très importantes qui ont été supprimées pendant des mois, sans que personne ne s'en aperçoive. À la fin de la résolution des « Bad actors»,, il ne devrait plus y avoir d’alarmes supprimées. Les alarmes sont souvent supprimées à cause de comportements gênants, comme les "cliquetis", qui peuvent être corrigés. La suppression doit être rigoureusement contrôlée, visible et suivie. Cette technique est appelée "Mise en veille des alarmes".

Alarmes dupliquées:

Il existe naturellement deux types d’alarmes en double.

1. Alarmes dupliquées dynamiques
   Ce sont des alarmes qui se produisent de manière constante dans un court laps de temps, à proximité d'autres alarmes spécifiques. Si vous utilisez votre logiciel d’analyse d'alarme pour lister les alarmes qui se produisent toujours dans, par exemple, une seconde l’une de l’autre, vous trouverez probablement une bonne liste sur laquelle travailler. Ces alarmes sont très probablement des annonces multiples, sous différentes formes, du même événement de processus. Par exemple, si une pompe s'arrête, on peut immédiatement recevoir des alarmes de pression de décharge basse, de débit faible et d'ampérage faible. Ces autres alarmes peuvent être valides lorsque la pompe fonctionne, mais pas lorsqu'elle est intentionnellement arrêtée et que ces valeurs sont attendues.
   La situation individuelle déterminera quelles alarmes doivent être conservées et quelles doivent être supprimées, ou quelles modifications logiques doivent être effectuées.

2. Alarmes dupliquées configurées
   Les interconnexions entre les points d'un DCS peuvent créer des cas d'alarme en double configurée. Par exemple, un capteur de mesure de processus peut être connecté à un point sélecteur, à un point totalisateur, à un point logique, à un point de contrôleur, etc. Souvent, une alarme de type "mauvaise mesure" est configurée pour chaque point (généralement par défaut), de sorte que si le capteur entre dans cette condition, plusieurs alarmes simultanées se produiront. Cela distrait l'opérateur en annonçant plusieurs alarmes causées par un seul événement (le capteur défectueux). Il ne devrait y avoir qu'une seule telle alarme, configurée sur le point où l'opérateur est le plus susceptible de prendre l'action. Si le point du capteur alimente un autre point de contrôleur, l'alarme devrait être placée sur le contrôleur pour signaler la mauvaise mesure. C'est parce que l'action que l'opérateur doit prendre face à une mauvaise lecture est susceptible de mettre le contrôleur en mode manuel et d'ajuster la sortie manuellement. Le point du contrôleur lui-même indiquera que la mesure d'entrée est défectueuse.

Alarmes de diagnostic des instruments gênants

Il est assez courant, mais toujours surprenant, de voir de grandes quantités d'occurrences d'alarmes indiquant une mauvaise mesure ou un problème similaire avec l'instrumentation. Ces alarmes sont souvent dans les centaines ou les milliers !

Figure 3 : Système d'alarme dominé par des alarmes de diagnostic des instruments

Lorsqu'une boucle a été conçue, quelqu'un a-t-il dit à l'ingénieur de contrôle ce qui suit ? "Oh, et au fait, je veux que ce capteur entre fréquemment en état de ‘Mauvaise mesure’, et je veux au moins 650 alarmes de ‘Mauvaise mesure’ par semaine au minimum." Et si cela avait été dit au meilleur ingénieur de contrôle de l'entreprise, aurait-il pu le faire ? Probablement pas ! Et pourtant, nous trouvons ces situations dans presque tous les systèmes que nous analysons.
Puisqu'aucun instrument n'a été conçu pour être dans un tel état, chacune de ces situations peut être corrigée, et elles ne devraient pas être tolérées. Elles sont mal configurées en termes de plage, de "blocage de mesure" ou il y a un problème d'installation. La justification originale pour installer un débitmètre n'incluait probablement pas la spécification qu’il était acceptable qu'il ne fonctionne pas la moitié du temps ! Pourtant, les gens tolèrent cela. Nous ne tolérerions pas un compteur de vitesse défectueux dans notre voiture.

Ces situations doivent être résolues. Une défaillance de l'instrument retire un indicateur de processus de la vue de l'opérateur. Le temps que les opérateurs passent à confirmer le problème d'instrumentation réduit leur attention sur d'autres tâches. Si un instrument défectueux n'est pas nécessaire, il doit être retiré, conformément à une procédure de gestion des changements (MOC). Un instrument défectueux de manière indéfinie pourrait être considéré comme une violation de la procédure MOC.

Il y a plusieurs décennies, les capteurs d'instruments analogiques disponibles avaient un compromis significatif entre précision (chiffres significatifs) et gamme ; vous pouviez obtenir une grande précision uniquement sur une petite plage, probablement inférieure à la variation possible du processus. Les ingénieurs de contrôle étaient bien conscients de ce compromis et étaient habitués à concevoir dans ces contraintes. Mais lorsque de tels capteurs à plage limitée ont été mis en œuvre dans un DCS, les alarmes de "mauvaise mesure" se produisent fréquemment et ne représentent pas une anomalie.

La révolution numérique qui nous a donné le DCS nous a également fourni des capteurs de mesure considérablement améliorés. Les capteurs modernes peuvent généralement fournir toute la précision nécessaire sur l'ensemble de la plage sur laquelle le processus peut varier. Cependant, certaines installations continuent de suivre les pratiques de configuration plus anciennes et ne prennent pas en compte les conséquences de générer de nombreuses alarmes de mauvaise mesure lors de conditions telles que le démarrage et l'arrêt. Les points de contrôleur auront généralement des "modes de mise en veille". Ce sont des actions prédéterminées prises lorsqu'une mesure d'entrée devient défectueuse, telles que passer à la sortie maximale, à la sortie zéro, ou maintenir la dernière sortie. Ces choix doivent être effectués avec soin, mais ils minimisent la possibilité pour la mesure de se dégrader au départ !

La configuration par défaut doit maintenant être de configurer la plage de l'instrument pour toute la plage des valeurs possibles que le processus peut avoir (y compris les conditions d'arrêt ou ambiantes), puis vérifier si la précision obtenue est suffisante. Si ce n’est pas le cas (ce qui est rare avec les transmetteurs modernes), achetez un meilleur transmetteur ! Mais ne configurez pas la plage à un endroit où vous savez que vous obtiendrez un état de mauvaise mesure dans les conditions attendues.

Les débits de pression différentielle sont souvent les pires fautifs. Si, en cas de débit nul, il y a un léger déséquilibre dans les tuyaux, le compteur tente de signaler un léger débit négatif ou inverse. La plage de débit peut ne pas être configurée pour accepter un léger négatif, donc l'état de mauvaise mesure et l'alarme se produisent. De tels points doivent être configurés pour gérer le cas de zéro. Un seuil peut être configuré et limité à une valeur nulle, de sorte qu'un petit flux négatif ne soit pas produit, ce qui pourrait affecter certains calculs en aval.

La plupart des DCS ont la capacité de limiter une valeur analogique aux extrémités de la plage, plutôt que d'entrer dans un état de mauvaise mesure. Cette capacité doit être bien comprise et utilisée correctement. (Cela implique plus de lecture de la documentation !)

Processus de travail continu

Un processus de travail doit être en place pour identifier et résoudre les nouvelles alarmes gênantes. Le processus changera ou sera modifié, les capteurs vieilliront ou développeront des problèmes, et de nouvelles alarmes gênantes apparaîtront. Des analyses continues des alarmes peuvent repérer et signaler ces problèmes, mais il doit y avoir une personne chargée d'agir et de corriger la situation. Nous avons constaté qu'une fois les alarmes gênantes initiales résolues, les opérateurs remarqueront cela, réaliseront que c'est possible et ne seront pas très tolérants envers de nouvelles alarmes gênantes ! C'est une bonne chose.

N'hésitez pas à nous contacter pour plus d’informations ou si vous avez des questions. Pour plus de détails, nous vous recommandons ce livre blanc gratuit : Making a Big Dent In Nuisance Alarms
Et bien sûr, The Alarm Management Handbook, Second Edition