MEJORANDO LOS KPIs DE ALARMAS DE FORMA RÁPIDA Y SENCILLA

En este cuarto artículo de la serie sobre el problema de las alarmas en la industria hablaremos sobre cómo conseguir “rápida y fácilmente” resultados de mejora gracias a nuestra Gestión de las Alarmas. Ojo al entrecomillado, no quiero que nadie me tome por mentiroso: la velocidad y facilidad dependerá de cada planta, de las herramientas disponibles y de las personas involucradas.

Aquí puedes encontrarlos todos los artículos de esta serie:

1. “El problema de las alarmas en la Industria”
2. “¿Por qué es necesario mejorar el funcionamiento de los sistemas de alarmas?”
3. “Primeros pasos en la Gestión de Alarmas. Midiendo el desempeño del Sistema de Alarmas”
4. “Mejorando los KPIs de alarmas de forma rápida y sencilla”
5. “Errores que hacen fracasar los proyectos de mejora del sistema de alarmas”

Los datos de las alarmas

Como vimos en el tercer artículo de la serie, cualquier ICS guarda dos tipos de datos sobre las alarmas:

• Datos estáticos, básicamente los parámetros de las configuraciones de cada alarma, como su tag, tipo (HI, HIHI, LO, LOLO, etc), severidad (ALTA, MEDIA, BAJA) o los valores de ajuste.
• Datos dinámicos, los recogidos en el log de alarmas del sistema (tag de alarma, tipo de alarma producida, time stamp, etc)

Los primeros pueden darnos una idea de cómo se trató el tema de las alarmas durante la configuración del ICS (por ejemplo, nos permite ver si por defecto se han dejado habilitadas todas las alarmas de todos los tags, cuántos niveles de severidad se han empleado y su distribución, si se han clasificado en función del riesgo sobre el que alertan, etc) mientras que analizando los segundos podemos saber a qué se enfrentan los panelistas durante su jornada de trabajo (principalmente de forma cuantitativa). Los datos estáticos nos dicen “qué se configuró en el ICS” y los dinámicos “qué es lo que se ve en la consola de operación”.

En consecuencia, será el análisis de estos datos dinámicos el que nos permita saber un poco más acerca de cómo se comporta nuestro Sistema de Alarmas y sacando partido de este conocimiento podremos hacer más fácil el trabajo de los operadores de panel, lo que redundará en su salud, en la seguridad de las instalaciones y en sus resultados económicos como vimos en el segundo artículo de esta serie.

¿Qué dicen los datos dinámicos de nuestro Sistema de Alarmas?

Basándonos en el análisis de los datos dinámicos de las alarmas podremos clasificar nuestro Sistema de Alarmas en una de las siguientes categorías de desempeño

La siguiente imagen ilustra gráficamente estos niveles de desempeño cuantificados. El objetivo para nuestro Sistema de Alarmas debería ser conseguir que durante el 99% del tiempo presente un valor máximo promedio de 1 alarma cada 10 minutos y en situaciones de máxima exigencia un máximo de 10 alarmas cada 10 minutos.

Consiguiendo resultados pronto. Resolviendo los “Malos Actores”

Los llamados “Malos Actores” (Bad Actors en la literatura en inglés) son un pequeño número de tags del ICS que sin embargo son responsables de gran parte de las alarmas que se registran en el sistema.

Se trata de la aplicación del Principio de Pareto a la Gestión de Alarmas. Este principio viene a decir que en multitud de fenómenos analizados, se comprueba empíricamente que unos pocos de los elementos bajo análisis tienen una gran influencia en los resultados finales, mientras que el resto -la mayoría- tienen muy poca. Aunque Vilfredo Pareto observó este fenómeno en sus estudios sobre la riqueza (comprobó por ejemplo que en Italia, el 20% de la población era propietaria del 80% de la tierra) y ya escribió sobre ello en 1896, fue Joseph Moses Juran quien universalizó el concepto a partir de 1941 al aplicarlo a los problemas de calidad en la producción.

Para identificar a nuestros “Malos Actores” podríamos elaborar un ranking de las alarmas más frecuentes -por ejemplo, un Top Ten durante el período de análisis- y comprobaríamos cómo estos diez tags serían responsables de un porcentaje elevado del total de alarmas registradas durante ese periodo.

Identificar nuestros “Malos Actores” y resolver sus problemas tiene la ventaja de permitirnos conseguir rápidos resultados de mejora de los KPIs de las alarmas sin demasiado esfuerzo (de forma general, habrá que ver cada caso particular). Es por tanto una buena forma de “vender” las virtudes de nuestro programa de Gestión de Alarmas.

En algunas plantas la mejora del Sistema de Alarmas se limita a la resolución periódica de los “Malos Actores”, aunque una buena Gestión de Alarmas no debería quedarse sólo en eso o el recorrido del proyecto de mejora del Sistema de Alarmas será corto. Si sólo trabajamos identificando y resolviendo los “Malos Actores” veremos que al poco tiempo no habrá tanta diferencia entre la influencia del Top Ten y la del resto de alarmas registradas por lo que el efecto positivo de su resolución cada vez incidirá menos en los KPIs de alarmas. Este y otros errores típicos en la Gestión de Alarmas que provocan el fracaso de los proyectos de mejora de los Sistemas de Alarmas serán tratados con más detalle en futuros artículos de la serie.

Los “Malos Actores” suelen entrar dentro de lo que el ISA 18.2 Nuisance Alarms (Alarmas Molestas) y que analizaremos con más detalle a continuación, presentando algunas posibles soluciones.

Las Alarmas Molestas

El estándar ISA 18.2 define una alarma molesta (Nuisance alarm) como aquella alarma que se produce excesivamente, de forma innecesaria o que no vuelve a su estado normal después de que se efectúa la adecuada acción correctiva. Estas alarmas suelen producirse cuando la planta está en un estado estable, o en condiciones normales de operación y por lo tanto, contribuyen a elevar el número de alarmas habitual en el panel.

Una exposición habitual a un elevado número de alarmas acaba insensibilizando al operador más responsable: es el “Efecto Pedro y el Lobo”

La mayoría de las veces, la única respuesta del panelista ante una alarma molesta es reconocerla y/o silenciarla. Obviamente, si el sistema tiene habitualmente demasiadas alarmas de este tipo, el panelista acaba despreocupándose de ellas, volviéndose insensible a ellas por lo que es fácil que no detecte una nueva alarma que sí fuese real, al confundirla con una de estas alarmas molestas (es lo que llamo “Efecto Pedro y el Lobo”).

Las causas de estas alarmas molestas son varias, por ejemplo:

• Los valores de ajuste de las alarmas no son los adecuados (demasiado próximos a las condiciones normales de operación)
• Las alarmas son utilizadas para informar a los panelistas de situaciones que no son anormales (no son verdaderas alarmas, lo veremos con detalle más adelante)
• El ajuste de la banda muerta/histéresis de las alarmas no es el adecuado (por defecto o por exceso)
• Fallos aleatorios de la instrumentación.
• Instrumentación fuera de servicio.
• Transmisores con rango inadecuado
• Los valores de ajuste de las alarmas no tienen en cuenta los distintos modos de operación de la planta.

Podemos distinguir los siguientes tipos de alarmas molestas:

Alarmas “parlanchinas” (Chattering alarms) y Alarmas fugaces (Alarm burst)

Ambos tipos son similares. Se trata de alarmas que aparecen y desaparecen en múltiples ocasiones durante un determinado periodo de tiempo, las primeras son más repetitivas (el “ruido” que generan dura más en el tiempo) mientras que las segundas son más esporádicas.

Según el estándar ISA 18.2 “Una alarma parlanchina es aquella que transiciona repetidamente entre el estado de alarma y el estado normal en un corto periodo de tiempo”. Sinónimos de una alarma parlanchina son las alarmas repetitivas y fugaces, que se definen, respectivamente, como “la misma alarma activándose y volviendo a la normalidad repetidamente durante un periodo de tiempo” y como “las alarmas que se activan y se desactivan poco después” según la definición del EEMUA-191.

Este tipo de alarmas molestas puede darse por ejemplo por una conexión defectuosa de la instrumentación o cuando la variable de proceso oscila en valores cercanos al ajuste de disparo de la alarma, por ruido en la variable de proceso, etc. En estos dos últimos casos podría resolverse haciendo modificaciones en las configuraciones del ICS, utilizando los parámetros de temporización a la conexión/desconexión (para las señales discretas) y de la histéresis/banda muerta en el caso de las señales analógicas.

El estándar ISA 18.2 da una serie de valores recomendados para estos ajustes, en función del tipo de variable, aunque no es recomendable aplicarlos a ciegas, a riesgo de hacer que la alarma no se active nunca, reducir el tiempo disponible que tiene el panelista para actuar (porque la alarma suena demasiado tarde) o convertir una alarma parlanchina en una alarma permanente.

En futuros artículos de la serie veremos con más detalle lo que en la literatura en inglés se conoce como Alarm Response Timeline o Cronología de la Respuesta a una Alarma y se comprenderá el peligro de aplicar estos valores sin considerar cada caso individualmente.

Alarmas permanentes, perennes o rancias (Stale alarms o Long Standing alarms)

Son alarmas que permanecen activas por más de 24h.

Suponen una distracción para el panelista, ya que al mostrarse en la pantalla de resumen de alarmas compiten por la atención del panelista con las alarmas que se van produciendo: si la pantalla de resumen muestra por ejemplo, 200 líneas y gran parte de ellas están ocupadas por estas alarmas rancias es fácil que “se escape” una nueva alarma, al ser confundida con otra de las que siempre aparecen en el listado.

Habitualmente, la pantalla de resumen de alarma de los ICS funciona como una lista FIFO (First In, First Out) de manera que a medida que van añadiéndose elementos a la lista los más antiguos son expulsados, con el inconveniente de que si no se comunican o resuelven a tiempo estas alarmas rancias “se hacen invisibles” para el operador, ya que desaparecen del listado.

De forma general, estas alarmas rancias se deben a problemas con la instrumentación (avería, desconexión, etc), pero también a equipos o parte de la planta que no está funcionando (originando alarmas perennes de bajo caudal, presión, temperatura, etc mientras no se ponga en marcha) o bien a un mal uso/configuración de las alarmas. Por ejemplo, en algunas de las plantas donde he trabajado la práctica habitual era alarmar el paro de las bombas. Como las bombas siempre están duplicadas -una de ellas en marcha y la otra parada, disponible para entrar en servicio si la otra falla- siempre teníamos en alarma una de las bombas de la pareja; además, por una mala configuración en el ICS, cuando se producía la alarma y el panelista la reconocía, ésta no desaparecía de la pantalla de resumen de alarmas, con lo que las bombas paradas “devoraban” la pantalla de resumen de alarmas.

Alarmas fuera de servicio

Son alarmas silenciadas (temporal o definitivamente), desactivadas físicamente o deshabilitadas desde el ICS para que “no molesten” sonando innecesariamente o bien ocupando líneas del listado resumen de alarmas

Las razones pueden ser varias, por ejemplo:

• Una instrumentación que falle aleatoriamente (porque origina “alarmas parlanchinas”) .
• Instrumentación desmontada en terreno, o que todavía no está en servicio (origina “alarma rancia”).
• Instrumentación asociada a una planta o equipo que está parado (origen de “alarmas rancias”).

Mientras la alarma está fuera de servicio, es posible que haya que modificar la forma de operar; por ejemplo, al carecer de una determinada alarma, el panelista deberá estar más atento a otras indicaciones que le permitan detectar la situación anómala que antes le indicaba la alarma fuera de servicio, por lo que es importante saber qué alarmas están fuera de servicio en todo momento y que esta información se traslade convenientemente a los distintos turnos de trabajo.

Dependiendo de la forma de dejar fuera de servicio una alarma, sonará en panel o no o quedará registro o no en el ICS. Por ejemplo, si una alarma se silencia desde panel, probablemente algún log del ICS registre qué usuario y cuándo la silenció y fácilmente podremos saber qué alarmas tenemos fuera de servicio en cada momento. Si el silenciado es hardware, por ejemplo, puenteando un contacto en terreno, debemos mantener manualmente un listado de alarmas fuera de servicio, por lo que si no tenemos en práctica rigurosos procedimientos de trabajo es prácticamente seguro que alguna alarma se nos va a escapar.

Los ICS incluyen la funcionalidad de Alarm Shelving o de Silenciado Temporal de Alarmas durante un tiempo prefijado, de manera que una vez transcurrido ese tiempo vuelve a “dar voz” a la alarma, evitando así el riesgo de que la alarma se quede silenciada eternamente. En futuros artículos trataremos esta funcionalidad con más detenimiento.

Alarmas duplicadas

Son aquellas alarmas que alertan de la misma situación anómala.

Un caso típico y fácil de entender podrían ser las alarmas de HI y de HI-HI o de LO y LO-LO en un mismo tag. Habría que revisar si es conveniente o no configurar una alarma y una pre-alarma: ¿alertan de riesgos diferentes?, ¿tienen distintas acciones correctivas?, ¿es realmente una pre-alarma o en la práctica ambas alarmas son casi simultáneas?

Otro ejemplo podría ser el de una variable que se visualiza en panel pero que al mismo tiempo se utiliza para efectuar un cálculo en el ICS. Si la instrumentación falla tendremos simultáneamente dos alarmas en el panel: la de la indicación y la del error en el cálculo.

Alarmas de fallo en la instrumentación

Esta categoría engloba a distintas alarmas indicando problemas en la instrumentación. En una instalación bien diseñada y mantenida este tipo de alarmas debería suponer un porcentaje mínimo del total de alarmas.

En una planta donde trabajé, analizando los datos de alarmas encontré un caudalímetro que cada vez que se arrancaba la bomba de la línea donde estaba instalado (algo que ocurría frecuentemente, porque la bomba operaba de forma intermitente) se iba fuera de rango, con la consiguiente alarma de fallo de instrumento.

Alarmas que NO son alarmas

¿Una alarma que no es una alarma? ¿cómo es eso posible?

El estándar ISA 18.2 define una alarma como “un medio audible y/o visible que sirve para indicar al operador el mal funcionamiento de un equipo, una desviación en el proceso o una condición anormal que precisa de su respuesta”.

Si cuando se produce una alarma, la actuación del operador es ignorarla porque no avisa de nada grave, reconocerla o silenciarla para que deje de sonar, es que no se trata de una alarma, si no de cualquier otro tipo de aviso.

La siguiente tabla muestra distintos tipos de notificaciones que pueden ofrecer los ICS actuales (cada uno de ellos podría llamarlas de formas diferentes), y cuándo utilizarlos, según la situación que se produzca en el proceso y si se requiere o no de la actuación del panelista.

Atendiendo a esta tabla, por ejemplo, el paso de una etapa a otra de una secuencia automática que se desarrolla normalmente debería indicarse mediante un MENSAJE (es algo esperable y no requiere de la actuación del panelista), si la misma secuencia se desarrolla de manera anómala (por ejemplo, completar un paso ha tomado más tiempo del habitual), el operador recibirá una ALERTA. Si por ejemplo, la secuencia se interrumpe por algún motivo, la notificación podría ser una ALARMA, mientras que el RECORDATORIO podría usarse cuando la secuencia se detiene a la espera de que el panelista efectúe alguna acción, o por ejemplo, para reanudarla después de una interrupción alertada mediante una alarma. Algunos ICS disponen de un tipo de aviso especial, que permite el registro el evento en el histórico del sistema pero que no se anuncia al panelista.

En algunos casos estas “alarmas que no son realmente alarmas” se heredan al migrar ICS antiguos, como apuntaba en un artículo anterior titulado “Migración de Sistemas de Control Industriales“. Tal vez condicionados por las limitaciones del antiguo ICS se utilizaban alarmas para indicar al panelista situaciones que, según las recomendaciones de los estándares más actuales sobre alarmas, no deberían serlo.

Si el proyecto de migración se plantea como un simple “copia y pega” de las configuraciones del antiguo ICS (por desconocimiento de las mejoras que podrían conseguirse, por velocidad en la migración, porque se piensa que se ahorra dinero procediendo así, porque se cree que así la adaptación de los panelistas al nuevo sistema será mejor y más rápida, etc) y no se muestran al usuario final las capacidades del nuevo ICS es posible que traslademos al nuevo ICS un problema de alarmas ya existente y que incluso lo agravemos tras la migración. A veces, el problema es que los usuarios creen que el nuevo sistema debe seguir funcionando de la misma manera, con lo que se pierde una de las posibles mejoras que ofrece el nuevo ICS.

Recuerdo en uno de mis proyectos de Gestión de Alarmas que encontré alarmas de “BYPASS ACTIVADO”. Dependiendo del tipo, activar un bypass puede que no sea una situación muy habitual. En el caso de un bypass que afecte a un enclavamiento/interlock la razón tiene que estar muy justificada, y puede que por procedimiento operativo requiera de la autorización de algún mando, dejar registro de cuándo y por qué se activo, etc. En otros casos, es corriente hacerlo, como ocurre por ejemplo con los bypasses de puesta en marcha.

Personalmente, creo que es correcto configurar algún elemento en el ICS de manera que podamos registrar el evento “activación de un bypass” en un log del sistema e informar/recordar al panelista que el bypass está activado (un aviso confirmando que está activo, una indicación en un gráfico de operación, una pantalla resumen con los bypasses activos, etc), pero atendiendo a la definición que da el estándar, no debería ser una ALARMA, tal vez un RECORDATORIO o un MENSAJE.

Conclusiones

• La resolución de los “Malos Actores” permite conseguir con rápidez y sin demasiado esfuerzo la mejora de los KPIs del Sistema de Alarmas, pero nuestra Gestión de Alarmas no debe limitarse exclusivamente a identificar y resolver sucesivas tandas de “Malos Actores”.
• Algunas alarmas molestas pueden resolverse gracias a las configuraciones del ICS (temporizaciones a la conexión/desconexión, ajuste de histéresis/banda muerta, etc). Otras simplemente no deberían ser ni alarmas, al no cumplir con las características que definen los estándares.
• A menudo, al migrar un ICS no se considera el Sistema de Alarmas y heredamos también los problemas que pudiera tener el antiguo sistema, que incluso pueden agravarse en el nuevo. Es conveniente conocer las mejoras que el nuevo ICS ofrece en relación con las alarmas y aprovechar para mejorar lo existente.
• Aunque el exceso de alarmas es un problema en sí, hay que verlo también como un síntoma de otros problemas en la organización. Por ejemplo, el exceso de alarmas debidas a problemas con la instrumentación nos estaría indicando que la selección de los instrumentos o su mantenimiento no es el correcto.

Como siempre, invito a los posibles lectores de este artículo a que lo enriquezcan mediante sus aportaciones en la sección de comentarios. Ojalá que el tiempo empleado en su lectura les haya parecido provechoso y les agradezco que me ayuden a darle mayor difusión recomendándolo y compartiéndolo con los contactos de su red. Espero contarles también como lectores de los próximos artículos de la serie.

Artículos relacionados

EL INCENDIO DE LA CATEDRAL DE NOTRE DAME DE PARÍS