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:
- «El problema de las alarmas en la Industria»
- «¿Por qué es necesario mejorar el funcionamiento de los sistemas de alarmas?»
- «Primeros pasos en la Gestión de Alarmas. Midiendo el desempeño del Sistema de Alarmas»
- «Mejorando los KPIs de alarmas de forma rápida y sencilla»
- «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.