Cada alarma tiene que ganarse su sitio en la consola.
La racionalización de alarmas es la etapa del ciclo de vida de gestión de alarmas de ANSI/ISA-18.2 (IEC 62682) en la que cada alarma existente o propuesta se contrasta con la filosofía de alarmas de la planta y se justifica, se reespecifica o se elimina. Una alarma avisa al operador de una condición anormal que exige una respuesta a tiempo, así que la prueba es concreta: qué consecuencia tiene no hacer nada, qué respuesta se espera y si queda tiempo para ejecutarla. Una alarma sin una respuesta de operador propia no es una alarma racionalizada: es un evento al que se le ha puesto una sirena.
Lo que la racionalización decide, alarma por alarma.
| Indicador | Qué mide | Objetivo habitual |
|---|---|---|
| Tasa media de alarmas | Alarmas anunciadas por operador en operación estable. | Unas 150 al día, aproximadamente 1 cada 10 minutos; por encima de 2 cada 10 minutos suele considerarse inmanejable. |
| Avalancha de alarmas | Una ráfaga que llega más rápido de lo que nadie puede leer, y menos aún atender. | Más de 10 alarmas en 10 minutos por operador es el umbral habitual; el tiempo en avalancha debería quedar muy por debajo del 1 %. |
| Alarma repetitiva | Se anuncia y se borra en rápida sucesión, típicamente tres o más veces por minuto. | Objetivo: cero. Un puñado de señales repetitivas genera habitualmente la mayor parte del volumen de una consola entera. |
| Alarma fugaz | Se anuncia y se borra tan rápido que el operador no puede responder, sin repetirse. | Objetivo: cero; casi siempre es un problema de banda muerta, retardo o calidad de señal. |
| Alarma persistente | Permanece anunciada de forma continua más de 24 horas. | Como mucho unas pocas en un día, cada una con responsable y plan — no una decoración permanente de la pantalla. |
| Diez principales contribuyentes | Parte del volumen total que aportan las diez señales más frecuentes. | Debería ser una fracción pequeña. Cuando es la mitad, usted tiene diez problemas, no un problema de gestión de alarmas. |
Qué significa «racionalizada»
No significa «hemos bajado el número». Significa que cada alarma de la consola tiene causa, consecuencia, respuesta, tiempo de respuesta y prioridad documentados, acordados entre operación, proceso y seguridad, y registrados en la base de datos maestra de alarmas. Ese registro, y no la configuración, es la vara de medir.
De dónde sale la reducción
Sobre todo de tres movimientos: eliminar alarmas sin respuesta de operador, arreglar el corto número de señales repetitivas y duplicadas que generan casi toda la carga, y suprimir por diseño — alarmas condicionadas al estado, para que las que carecen de sentido con la unidad parada no lleguen mientras está parada.
Aparcar no es suprimir
Aparcar (shelving) es una retirada temporal, registrada y con caducidad, iniciada por el operador, que vuelve automáticamente y aparece en una lista de revisión. La supresión por diseño es una regla ingenierizada y documentada. Un aparcado permanente sin caducidad no es ninguna de las dos cosas: es una alarma desactivada en silencio con un rastro que nadie lee.
Por qué los sistemas de alarmas vuelven a degradarse.
- Racionalizar una vez, como proyecto, y no auditar nunca más. Vigilancia y evaluación son etapas del ciclo de vida; sin ellas el volumen vuelve a subir en un par de años.
- Inflación de prioridades. Cada responsable defiende que su alarma es de prioridad alta, y una consola sin prioridad baja es una consola sin prioridades.
- Usar el aparcado como botón de silencio, sin caducidad ni lista de revisión.
- Alarmas añadidas directamente al sistema en servicio para una situación puntual, saltando la gestión de cambios, y jamás retiradas.
- Usar alarmas como recordatorios, notas de turno o registro de eventos. Si no es una condición anormal que exige respuesta a tiempo, su sitio es el registro.
- Ignorar el problema de avalancha porque la tasa media parece aceptable. Las medias esconden los diez minutos posteriores a un disparo, justo cuando el operador más necesita una consola legible.
- Descartar el historial de alarmas a los 30 días, lo que impide demostrar tanto el problema como la mejora.
De qué depende el sistema de alarmas.
El desempeño de alarmas se mide sobre el historial de eventos, así que hereda la calidad de la capa de datos: marcas de tiempo coherentes, una única base de tiempo y el contexto de equipo que permite unir una alarma del DCS con un cambio de estado de la línea. Eso es lo que aportan la contextualización y un Unified Namespace, con ISA-95 aportando la jerarquía de equipos por la que agregan los recuentos. Aguas abajo, las avalanchas suelen ser la primera evidencia disponible para un análisis de causa raíz, las alarmas molestas repetidas en el mismo equipo son a menudo una señal de mantenimiento que nadie ha leído como tal, las paradas provocadas por alarma aparecen como pérdida de disponibilidad en el OEE, y qué alarmas están aparcadas o suprimidas es uno de los puntos que debe sobrevivir a un relevo de turno.
La mayoría de consolas están a una semana de análisis honesto de ser utilizables.
Alarm Triage lee una exportación de alarmas y eventos que usted aporta, agrupa las avalanchas, ordena los contribuyentes repetitivos, fugaces y persistentes, y redacta acciones de racionalización candidatas que su equipo puede aceptar o rechazar. Razona sobre el registro que usted le entrega: no se conecta a su DCS ni cambia configuración alguna. Cinco ejecuciones gratuitas y luego forma parte del plan de agentes.
Ver Alarm Triage