Una banda de alarmas puede estar llena sin aportar mucha ayuda. En una perturbación, la pantalla reclama atención una y otra vez, pero puede no indicar qué señal necesita una acción. La fatiga de alarmas industriales empieza cuando el sistema consume atención antes de que el proceso se haya entendido.
Contar todas las anunciaciones de un día no basta para ver el problema. Ese total mezcla consolas, turnos, modos operativos, paradas, arranques, mantenimiento y perturbaciones reales. La pregunta útil es más concreta: en una consola y en un modo de operación determinado, ¿dio el sistema de alarmas al operador una señal accionable a tiempo? La guía sobre gestión de alarmas de HSE sitúa las alarmas en condiciones de planta que requieren evaluación o actuación oportuna. La serie ISA-18 presenta ese trabajo como un ciclo de vida, desde la definición y el diseño hasta la monitorización y la modificación.
Este artículo explica cómo medir la carga de alarmas, localizar patrones que merecen revisión y preparar una conversación de racionalización sin confundir la limpieza de un panel con una decisión de seguridad. Consulta primero la gestión de alarmas con evidencia antes de que un cambio entre en el proceso aprobado de racionalización y gestión del cambio.
Cuándo una alarma deja de ayudar
En la terminología de ISA, una alarma es una indicación audible o visible de un fallo, una desviación o una condición anómala que requiere una respuesta oportuna del operador. Su finalidad es avisar de una condición de proceso anómala o de un mal funcionamiento de equipo y requerir una respuesta a tiempo. El artículo de ISA sobre rendimiento de alarmas de seguridad hace esa distinción. Importa porque una sala de control puede tener muchos mensajes útiles que no deberían competir con las alarmas por la misma atención.
Un evento deja constancia de que algo ha ocurrido. Un diagnóstico puede servir a mantenimiento. Una notificación puede informar a otro rol de un estado rutinario. Una alarma debería significar que alguien responsable del proceso ha de evaluar una condición y decidir qué hacer dentro de un plazo. La página de la serie ISA-18 describe un informe complementario sobre notificaciones no alarmantes precisamente porque indicaciones y avisos para personas distintas del operador de sala no deberían añadir distracción innecesaria al sistema de alarmas.
La fatiga de alarmas aparece cuando avisos repetidos, de poco valor o mal temporizados consumen atención y dificultan detectar una alarma que requiere respuesta a tiempo. No significa que el operador deje de preocuparse de repente. Las personas se adaptan a la pantalla que reciben: aprenden qué mensajes se borran solos, qué etiquetas suelen estar activas y qué avisos de equipo llegan cuando la condición de proceso ya se ha visto por otra vía. La guía de HSE advierte que los sistemas de alarma deben tener en cuenta capacidades y límites humanos. Su análisis del incidente de la refinería de Milford Haven también muestra por qué una avalancha prolongada no se reduce a un problema de atención individual.
Por eso, una revisión no debería empezar por “¿qué alarma molesta?”. Debería empezar por “¿qué condición anómala representa, quién debe actuar y cuánto tiempo hay?”. EEMUA Publication 191 aborda el trabajo sobre sistemas de alarma. La pregunta no convierte la racionalización en una tarea sencilla, pero evita que un aviso se juzgue solo por el cansancio que produce.
Por qué el promedio diario puede ocultar el problema
Los totales diarios resultan atractivos porque se exportan con facilidad. También se malinterpretan con facilidad. Una consola que recibe 120 alarmas en veinticuatro horas tranquilas no supone la misma carga para el operador que otra que recibe esas mismas 120 en dos grupos de diez minutos durante un arranque. El trabajo cambia con el patrón temporal, el estado de operación, las áreas de planta que están a la vista y con si los mensajes son independientes o consecuencia de un único evento iniciador.
El artículo de ISA sobre rendimiento de alarmas de seguridad presenta métricas de ejemplo basadas en al menos 30 días de datos. Su tabla expresa el promedio de alarmas anunciadas por hora y por consola de operador, no un total de planta; cita aproximadamente seis como “muy probablemente aceptable” y aproximadamente doce como “máximo gestionable”. El mismo artículo presenta una métrica de avalancha como porcentaje de tiempo en dicha condición y da como ejemplo un objetivo inferior al uno por ciento. Son ejemplos publicados para evaluar el rendimiento del sistema de alarmas, no límites universales de aprobado o suspenso para cada unidad, equipo de turno o estado de operación.
El artículo describe una métrica de avalancha como el porcentaje de tiempo durante el cual un operador recibe más de diez alarmas en diez minutos ISA. La definición sirve porque deja visible el denominador. La visión actual de estándares de ISA también identifica tasas de alarma, alarmas permanentes y tiempos de respuesta como indicadores para la evaluación continua. El proyecto Alarm Rates II del Center for Operator Performance estudia la guía de tasas de alarma y su relación con el rendimiento del operador; es otra razón para no tratar un recuento bruto como contexto suficiente.
Para construir una línea base, separa operación normal, transiciones, ventanas de mantenimiento o prueba y perturbaciones conocidas ISA. Después calcula la tasa media por consola, el pico en ventanas de diez minutos, el tiempo en avalancha y la aportación de las alarmas más frecuentes. Una referencia se vuelve útil cuando obliga a preguntar qué consola, qué periodo, qué modo y qué alarmas crearon la carga. Sin esas etiquetas, un promedio diario puede parecer tranquilo mientras el operador sigue experimentando una avalancha.
Cómo el ruido cambia la confianza del operador
Las alarmas repetidas modifican la relación de trabajo entre una persona y el sistema. Si una etiqueta aparece muchas veces sin una condición nueva ni una respuesta práctica, pierde credibilidad. Si una alarma permanece activa durante un estado conocido, su presencia se normaliza. Si varias alarmas de consecuencia llegan antes de entender la condición iniciadora, la banda se convierte en un problema de búsqueda en vez de una ayuda para decidir. Esos patrones no prueban que un operador vaya a ignorar cada alarma. Sí crean un contexto en el que atender, verificar y responder cuesta más.
El artículo de ISA sobre alarmas de seguridad señala de forma explícita que, cuando las falsas alarmas se acercan al 50 %, disminuye la confianza del operador en una alarma de seguridad y puede disminuir la respuesta. También indica que una permanencia prolongada en alarma puede hacer que ese estado parezca normal y lo denomina normalización de la desviación. Son afirmaciones sobre el rendimiento de alarmas de seguridad en el contexto declarado por el artículo; no deben convertirse en un porcentaje único para todos los sistemas. Aun así, explican por qué una alarma permanente es más que un elemento desordenado de la pantalla.
El trabajo de James Reason sobre error humano permite hablar de esto sin culpar a la persona que está en la consola. Los fallos graves deben examinarse a partir de las condiciones y defensas del sistema que rodean la acción humana final, no solo de esa acción. Una revisión que solo pregunta por qué el operador reconoció una alarma deja fuera decisiones de diseño, condiciones de operación, procedimientos y estados de equipo que determinaron qué resultaba visible y plausible en ese momento.
Ese enfoque cambia las preguntas después de una avalancha. ¿La condición iniciadora estaba alarmada con suficiente antelación? ¿Se distinguían las alarmas de consecuencia de las posibles causas? ¿Una alarma permanente antigua ocupaba atención? ¿Existía un procedimiento de respuesta que el operador pudiera usar con presión de tiempo? La guía de HSE trata la gestión de alarmas como una cuestión de factores humanos, no solo como un ejercicio de configuración de ingeniería. Para reconstruir una secuencia de evento, consulta la investigación de incidentes industriales.
Construye una línea base de 30 días antes de cambiar nada
Una línea base de 30 días no es un estudio completo de racionalización. Es un punto de partida disciplinado. El artículo de ISA usa al menos 30 días de datos en sus métricas de rendimiento de ejemplo, y ISA describe ISA-TR18.2.5 como una guía sobre monitorización, evaluación y auditoría mediante medidas como tasas de alarmas, alarmas permanentes y tiempos de respuesta. Usa ese periodo para hacer observable el sistema antes de decidir qué modificar.
Empieza nombrando la consola o posición, el área de proceso, la fuente de datos y el intervalo exacto. No mezcles todas las consolas salvo que el equipo pueda explicar por qué sus cargas de trabajo son intercambiables. Marca en el historial los modos de operación: marcha estable, cambio de grado, limpieza, arranque, parada, pruebas, mantenimiento y recuperación tras una perturbación. Así queda una línea base que puede leerse después, no una acumulación de exportaciones sin contexto.
Después calcula las alarmas anunciadas medias por hora para cada consola e identifica las ventanas de diez minutos con mayor tasa. Mide el porcentaje de tiempo en avalancha según la definición elegida. Ordena las alarmas por recuento, pero conserva sus marcas temporales y modos para que la lista no esconda una ráfaga causada por una sola intervención. Cuenta las alarmas activas que permanecen durante periodos largos. Identifica alarmas inestables, que cambian de estado repetidamente; alarmas fugaces, que se borran antes de permitir una acción útil; y alarmas obsoletas, que siguen activas cuando su información ya no aporta valor. Son señales para revisar, no categorías de eliminación automática.
Luego inspecciona el patrón que hay detrás de cada candidata. Una alarma frecuente durante la limpieza puede ser apropiada en un modo e inapropiada en otro. Una alarma permanente puede reflejar una condición actual de proceso, un instrumento averiado, una configuración deficiente o una orden de trabajo sin cerrar. Un grupo de alarmas puede ser una cascada posterior a un único evento iniciador. Consulta el artículo de mantenimiento con evidencia de planta para los fallos de instrumentación. El documento de contenidos de EEMUA 191 enumera monitorización, evaluación y auditoría junto a diseño y operación; encaja con esta secuencia: medir, investigar y decidir.
Racionaliza las alarmas mediante decisiones, no limpieza
La racionalización pregunta si cada alarma candidata debe formar parte de la carga de trabajo del operador y, si debe hacerlo, cómo tiene que funcionar. La visión de estándares de ISA describe ISA-TR18.2.2 como guía de identificación y racionalización: decidir si hace falta una alarma, documentar sus detalles, asignar prioridades y clasificarla de acuerdo con una filosofía de alarmas. La descripción del ciclo de vida también conecta la racionalización con implementación, mantenimiento y gestión continua del cambio.
Reúne las preguntas en un único registro de revisión para cada alarma. ¿Qué condición anómala representa? ¿Debe actuar un operador de sala de control? ¿Qué ocurre si nadie actúa? ¿Cuánto tiempo hay disponible? ¿En qué modos es válida? ¿La prioridad procede de la consecuencia y del tiempo de respuesta? ¿Otra alarma representa ya la misma condición? ¿Esta etiqueta es consecuencia de otra alarma iniciadora? ¿Un fallo de instrumento o la ausencia de procedimiento explica su comportamiento?
Una revisión puede respaldar conservar una alarma cuando representa una condición anómala con una respuesta definida y oportuna. Puede indicar la reparación de un instrumento cuando el registro de eventos apunta a una mala medición y no a una alarma de proceso. Puede justificar revisar la presentación, la lógica por modo o la prioridad cuando el razonamiento y el tiempo de respuesta no sostienen la configuración actual. También puede justificar combinar o rediseñar duplicados si compiten por la misma acción del operador. La retirada requiere el proceso de decisión aprobado que documente por qué la alarma ya no cumple la filosofía vigente.
La página de EEMUA Publication 191 define su alcance como diseño, gestión y adquisición de sistemas de alarma, y la serie ISA-18 nombra filosofía documentada, priorización, monitorización y gestión del cambio como elementos del ciclo de vida. Una lista ordenada ayuda a decidir dónde mirar primero. No sustituye la justificación para cambiar una consigna, prioridad, estado de alarma, lógica o procedimiento de respuesta.
Una revisión puede respaldar conservar una alarma cuando el registro demuestra que da a la persona adecuada tiempo e información suficientes para actuar ante una condición anómala ISA. Cuando el registro no puede demostrarlo, la candidata pertenece al proceso de revisión aprobado. Para cambios autorizados, consulta la gestión de cambios con evidencia de planta.
Un recorrido de cuatro semanas desde los datos hasta la revisión
En la primera semana, acuerda la consola, la fuente de alarmas, el periodo y las etiquetas de modo operativo. Comprueba la alineación de relojes, los registros de eventos ausentes y las fuentes duplicadas antes de calcular métricas. Evita así que el equipo trate marcas temporales diferentes como si fueran una secuencia de proceso.
En la segunda semana, publica la línea base y selecciona familias de alarmas para revisar. Incluye una ráfaga, una alarma permanente y una alarma frecuente solo si los datos permiten clasificarlas así. Compara cada candidata con el registro de modo operativo y con cualquier orden de trabajo o cambio de procedimiento cercano. La investigación de tasas de alarma del Center for Operator Performance se ocupa del rendimiento de operadores, no de una métrica para toda la planta. La guía de HSE mantiene el foco en la evaluación o actuación oportuna del operador.
En la tercera semana, celebra un taller de racionalización con operaciones, ingeniería de control, instrumentación, mantenimiento y una persona que represente a seguridad de procesos. Lleva ventanas de eventos, tendencias, procedimientos, la filosofía vigente y el registro de línea base. Formula las mismas preguntas para cada candidata. Registra la incertidumbre en lugar de forzar una respuesta rápida. Si una candidata afecta a una función de seguridad o a una salvaguarda acreditada, usa el proceso de planta correspondiente y no la trates como una limpieza rutinaria.
En la cuarta semana, transforma los hallazgos aceptados en acciones controladas: investigar un instrumento, revisar un procedimiento, programar una revisión de diseño o iniciar el proceso formal de cambio. Asigna responsables y fechas. Conserva un registro de las candidatas descartadas y de sus motivos. Tras aplicar cambios aprobados, vuelve a vigilar la misma consola y los mismos modos. Un recuento menor por sí solo no prueba un sistema más seguro ni una mejor respuesta del operador. Puede reflejar una mejora legítima, un cambio estacional de operación, una condición oculta o un cambio que desplazó la información a otra parte. Compara la evidencia nueva con la línea base antes de declarar éxito.
La siguiente acción útil es pequeña: elige una consola y un periodo reciente de treinta días. Genera la línea base, identifica el peor periodo de diez minutos y lleva una familia de alarmas a una revisión documentada. Basta para sustituir una queja vaga sobre ruido por una pregunta concreta sobre acción del operador, condición de planta y autoridad para cambiar.
Preguntas frecuentes
¿Qué es la fatiga de alarmas en una planta industrial?
La fatiga de alarmas aparece cuando avisos repetidos, de poco valor o mal temporizados consumen atención y dificultan detectar una alarma que requiere respuesta a tiempo. Trata de condiciones de trabajo y del diseño del sistema de alarmas, no demuestra que a una persona no le importe. Revísala primero por modo operativo. HSE enmarca la finalidad alrededor de la evaluación o actuación oportuna.
¿Cuántas alarmas por hora puede gestionar un operador?
La respuesta depende de la consola, el modo operativo y la carga de trabajo; los ejemplos publicados por ISA usan tasas por consola y deben entenderse como referencias dependientes del contexto, no como límites universales. Un artículo de ISA ofrece ejemplos de alrededor de seis y doce alarmas medias por hora y por consola, y los acompaña con tiempo en condición de avalancha. ISA aporta el contexto.
¿Cómo puede una planta identificar alarmas molestas?
Empieza por el historial de eventos y el contexto operativo, y revisa las alarmas frecuentes, permanentes, inestables o obsoletas frente a la acción que exigen y la condición que representan. Conserva consola, modo y marcas temporales; un recuento bruto puede ocultar un mensaje válido de transición, un problema de instrumento o una consecuencia repetida. La guía de monitorización de ISA incluye tasas y alarmas permanentes entre las medidas pertinentes.
¿Qué debe documentarse durante la racionalización?
Documenta la condición anómala, la respuesta requerida, la consecuencia, el tiempo disponible, la prioridad, el modo operativo, la base de la consigna y cualquier decisión de gestión del cambio. Anota también acciones duplicadas para el operador y evidencia que apunte a intervenciones en equipos o instrumentos. La descripción de racionalización de ISA conecta esta tarea con necesidad, documentación, prioridad y clasificación.
¿Por qué no basta con suprimir alarmas ruidosas?
La supresión puede ocultar un síntoma sin resolver el diseño de la alarma, el estado del instrumento, el modo operativo o el procedimiento de respuesta ausente que generó el ruido. Toda decisión de suprimir debería apoyarse en la filosofía aprobada y en el proceso de cambio. EEMUA 191 sitúa el asunto dentro del diseño y la gestión del sistema de alarmas.