Réduire les alarmes intempestives avec l’ISA 18.2 dans Honeywell Experion et Emerson Ovation
Trop d'alarmes intempestives empêchent l'opérateur de voir plus facilement l'avertissement important. La norme ISA-18.2 fournit un cadre de cycle de vie pour décider quelles alarmes doivent apparaître sur la console, comment elles doivent se comporter et comment leurs performances doivent être évaluées.
Pourquoi le nombre d'alarmes devient-il incontrôlable ?
Lorsque chaque variable analogique reçoit plusieurs limites par défaut, les variations normales du procédé peuvent générer des notifications répétées. Une alarme doit signaler une condition anormale nécessitant une réponse opérateur définie, et non simplement indiquer qu'une valeur a changé. Commencez par définir une philosophie d'alarme, rationalisez les alarmes en fonction de celle-ci, gérez les modifications et évaluez les performances à partir de l'historique réel des événements.
Comment définir la priorité, la zone morte et le délai ?
Attribuez la priorité en fonction des conséquences de l'inaction et du temps de réponse disponible, à l'aide de la matrice approuvée du site. Définissez la zone morte ou l'hystérésis afin d'empêcher les oscillations autour d'un seuil, et utilisez un délai d'activation uniquement lorsque le risque lié au procédé le permet. Il n'existe pas de pourcentage ni de nombre de secondes universel pour les boucles de débit, de niveau ou de pression. Vérifiez qu'un délai ne peut pas dissimuler une condition dangereuse évoluant rapidement.
Dans Honeywell Experion et Emerson Ovation, vérifiez la version installée et l'objet d'alarme configuré avant de modifier les attributs. Les produits associés, tels que le module IOTA Honeywell Experion Series 8 et le module d'entrée analogique Emerson Ovation, s'intègrent à des systèmes dont le comportement des alarmes doit être vérifié dans la configuration réelle. Ne supposez pas que les deux plateformes utilisent des paramètres ou des blocs identiques.
Que doit contenir une base de données principale des alarmes ?
Enregistrez pour chaque alarme sa variable, son objectif, la condition anormale, la conséquence, l'action opérateur requise, le temps de réponse, la priorité, le seuil, la zone morte, le délai, les règles de mise en attente ou de suppression, ainsi que l'historique des révisions. Rejetez ou reconcevez les alertes qui ne nécessitent aucune action utile de la part de l'opérateur. Définissez les objectifs de performance à partir de la philosophie d'alarme et de l'historique d'exploitation du site, plutôt que de copier une cible fixe pour les alarmes actives ou les rafales provenant d'une autre installation.
Quand la mise en attente est-elle appropriée ?
La mise en attente retire temporairement une alarme de la vue active de l'opérateur dans le cadre d'une procédure contrôlée. Définissez qui peut la mettre en attente, pour quelle raison, pendant combien de temps, avec quelle visibilité et selon quelles modalités de retour automatique. Évitez de considérer une temporisation fixe de mise en attente au démarrage comme un substitut à une gestion des alarmes adaptée aux états du procédé. Les alarmes critiques pour la sécurité nécessitent un examen particulier conformément à la politique du site.
Comment acheminer les alarmes via OPC UA ?
Si le serveur prend en charge OPC UA Alarms & Conditions, abonnez-vous aux événements pertinents et vérifiez le type d'événement, la source, l'horodatage, l'état actif, l'acquittement et les transitions de retour à la normale. Les abonnements aux événements peuvent mieux préserver les transitions que l'interrogation périodique, mais la livraison et la mise en mémoire tampon dépendent toujours de la configuration du serveur et du client. Ne limitez pas les événements en aval aux niveaux High et Emergency, sauf si le cas d'utilisation et la politique de conservation du récepteur autorisent explicitement l'exclusion des événements de priorité inférieure. Définissez les paramètres de publication et de file d'attente à partir d'un débit testé plutôt que de valeurs génériques fixes.
Comment un opérateur peut-il gérer une rafale d'alarmes ?
Analysez les séquences d'alarmes pour trouver la cause initiatrice, puis rationalisez les alarmes dépendantes et appliquez, par conception, une suppression approuvée lorsque l'état du procédé les rend non pertinentes. Préservez la visibilité des dangers nécessitant une action. Testez les modifications dans des scénarios réalistes de perturbation et suivez, par équipe, les alarmes fréquentes, les alarmes oscillantes, les rafales et la réponse des opérateurs. Tout test forcé doit suivre une procédure approuvée qui protège l'installation et le personnel.
Quelle est la première étape pratique ?
Prélevez un historique représentatif des alarmes du système Honeywell Experion ou Emerson Ovation installé. Identifiez les alarmes les plus fréquemment répétées, confirmez l'action opérateur requise et rationalisez la priorité, les limites, la zone morte et le délai avant de modifier de nombreuses variables à la fois. Maintenez la base de données principale des alarmes et la configuration active synchronisées au moyen de la gestion des modifications.
Auteur : Zhao Mingyuan est ingénieur en automatisation industrielle et possède plus de 10 ans d'expérience dans les automates programmables, les systèmes DCS et les systèmes de contrôle.
