Gestión de alarmas para ingenieros HMI
Puedes dibujar la pantalla de operador más tranquila y más conforme a norma del mundo y aun así fracasará si el sistema de alarmas que hay por debajo está roto. La disciplina de color en la pantalla y la disciplina de alarmas en la lógica son el mismo proyecto visto desde dos extremos, y la mayoría de las plantas solo llega a hacer la primera mitad.
Esta guía es la mitad de las alarmas. Está escrita para quien construye la HMI, no para el departamento de seguridad de proceso: qué te exige realmente la gestión de alarmas, qué decisiones hay que tomar antes de dibujar nada y cómo debe aparecer exactamente la prioridad de alarma en la pantalla.
1. El modo de fallo: nadie diseñó las alarmas
Las alarmas son la única parte de un sistema de control que casi nunca se diseña. Los símbolos se revisan. Las distribuciones de pantalla se revisan. Las alarmas se añaden: de una en una, a lo largo de años, por quien estuviera en planta esa semana y normalmente como respuesta a un incidente que nadie quiere repetir.
El resultado es predecible y llamativamente parecido en todos los sectores:
- Avalanchas de alarmas. Una sola perturbación dispara una alarma, que dispara doce alarmas consecuentes, que el operador no puede leer lo bastante rápido como para actuar sobre ninguna de ellas.
- Alarmas persistentes. Alarmas activas desde hace semanas porque la condición es real pero nadie puede resolverla. Ocupan la lista de resumen de forma permanente y el operador aprende a pasar de largo.
- Alarmas oscilantes. Una señal que se queda pegada a su umbral genera cientos de transiciones a la hora. Todas ellas son ruido.
- Alarmas que no son alarmas. “Bomba 3 arrancada”. No pasa nada malo; no hay nada que hacer. Es un evento, registrado como alarma, compitiendo por la misma atención.
La medida habitual de salud es la tasa de alarmas por operador. El benchmark de EEMUA 191, muy citado, considera que unas 150 alarmas por operador y día (unas seis a la hora) marcan el límite de lo manejable en operación estable, con un objetivo “muy probablemente aceptable” más cercano a una alarma cada diez minutos y un tope duro de unas diez alarmas en los diez minutos posteriores a una perturbación. La mayoría de las plantas existentes que se miden por primera vez encuentran tasas varias veces superiores.
Trata esas cifras como un termómetro, no como un objetivo de diseño. Si tu tasa es de 2.000 al día, el problema no es que tengas que borrar 1.850 alarmas: es que en esta planta nadie ha decidido nunca para qué sirve una alarma.
2. La única regla que arregla casi todo
ISA-18.2 define una alarma como un medio audible o visible de indicar un mal funcionamiento de un equipo, una desviación de proceso o una condición anómala que requiere una respuesta. Esas últimas palabras sostienen toda la norma.
Así que la prueba para cada alarma candidata es una sola pregunta, y no es técnica:
¿Qué se supone que tiene que hacer el operador al respecto y de cuánto tiempo dispone?
Si no hay respuesta —ninguna acción, o una acción que nadie podría ejecutar a tiempo, o una acción que ocurre automáticamente de todos modos—, entonces no es una alarma. Podrá ser una entrada de registro, una tendencia, una orden de trabajo de mantenimiento o una indicación de estado en la pantalla. Todo eso es útil. Nada de eso debería sonar ni ocupar el banner de alarmas.
Aplicando solo esta regla, sin ninguna herramienta, se suele eliminar una fracción enorme de una lista de alarmas heredada. Es además la regla que hace abordable el diseño de la HMI: lo que sobrevive es lo bastante pequeño como para representarlo con honestidad en una pantalla.
3. El ciclo de vida de ISA-18.2, en el orden en que te lo encuentras
ISA-18.2 (publicada también como IEC 62682) plantea la gestión de alarmas como un ciclo de vida y no como un documento. Como ingeniero de HMI te encontrarás las etapas más o menos en este orden:
| Etapa | Qué produce | Qué te juegas en ella |
|---|---|---|
| Filosofía | Las reglas escritas de la planta: qué es una alarma, cuántas prioridades existen, qué significa cada color, qué respuesta se espera | Tus convenios de color y de símbolo tienen que encajar con ella, o la pantalla contradice al papel |
| Identificación | Alarmas candidatas procedentes del HAZOP, los P&ID, los incidentes y las peticiones de los operadores | Todavía nada, pero es aquí donde la lista crece sin control |
| Racionalización | Para cada alarma: causa, consecuencia, acción correctora, tiempo de respuesta, prioridad y consigna | Esta es la entrada de tu diseño. Sin racionalización no hay prioridades defendibles |
| Diseño detallado | Bandas muertas, retardos a la conexión y a la desconexión, reglas de supresión, correspondencia prioridad-color, diseño de la visualización | La mitad de esto es tuya |
| Implementación | Configuración de PLC/DCS, objetos de la HMI, formación | Tuya |
| Operación y mantenimiento | Aparcado de alarmas, gestión del fuera de servicio, pruebas | La pantalla tiene que mostrar estos estados con honestidad |
| Seguimiento y evaluación | Métricas de tasa, listas de malos actores, análisis de avalanchas | Alimenta la siguiente revisión |
| Gestión del cambio y auditoría | Cambios controlados, revisión periódica | Evita que la pantalla y la lógica se separen |
No hace falta que seas el dueño del ciclo de vida. Lo que sí hace falta es que te niegues a adivinar las partes que se saltaron: si nadie sabe decirte la prioridad de una alarma ni qué hace el operador con ella, eso es un hallazgo, no un detalle que rellenes tú.
4. Asignar prioridad sin discutir
La prioridad no es importancia y no es gravedad. Es urgencia de la respuesta del operador, y se deriva de dos cosas: cómo de mala es la consecuencia si no se hace nada y cuánto tiempo tiene el operador antes de que esa consecuencia llegue.
Una matriz consecuencia/tiempo mantiene la discusión objetiva. Una asignación típica de cuatro niveles:
| Prioridad | Consecuencia si no se atiende | Tiempo de respuesta | Porcentaje típico de la lista |
|---|---|---|---|
| P1 · Crítica | Seguridad, medio ambiente o pérdida grave de equipo | Minutos | ~5 % |
| P2 · Alta | Pérdida de producción, pérdida de calidad, riesgo de disparo | Decenas de minutos | ~15 % |
| P3 · Media | Operación degradada, coste creciente | Horas | ~80 % |
| P4 · Baja | Sin consecuencia; solo para conocimiento | Sin plazo | Usar con moderación |
La distribución importa tanto como las definiciones. Si un tercio de tus alarmas son P1, el esquema de prioridades no aporta información: el operador no puede jerarquizar una lista en la que todo es crítico. Aproximadamente 5 / 15 / 80 es la forma a la que aspiran casi todas las filosofías de alarmas, y merece la pena contrastar tu lista con ella antes de diseñar una sola pantalla.
La P4 merece desconfianza. En la práctica, la mayoría de las “alarmas informativas” son eventos que pertenecen a un registro o a un campo de estado de la pantalla. Si nunca requiere una respuesta, cuestiona que deba estar siquiera en el sistema de alarmas.
5. Mostrar la prioridad en la pantalla
Vamos con la parte de HMI. La paleta tranquila de ISA-101 existe precisamente para que el color de alarma tenga dónde aterrizar. La correspondencia canónica:
Tres reglas gobiernan cómo aparecen:
El color nunca es la única señal
Alrededor de uno de cada doce hombres tiene alguna forma de deficiencia de visión del color, y la confusión rojo/verde es la más frecuente. Toda indicación de alarma debe llevar una segunda señal no cromática: el número de prioridad en el badge (P1, P2), una forma distinta, una posición o un texto. Un círculo rojo y un círculo naranja que solo se diferencian en el tono son, para una parte considerable de tus operadores, el mismo círculo.
La alarma va montada sobre el equipo, no al lado
Un operador que barre un sinóptico debería poder responder a “qué pasa y dónde” en una sola fijación de la vista. Eso significa que el badge de alarma va encima de la bomba, de la válvula, del motor: un pequeño disco relleno en una esquina fija del símbolo, con el texto de la prioridad. El equipo sigue mostrando su propio estado (en marcha, parado, sin feedback) por debajo; el badge es aditivo.
Por eso los nueve estados estándar de motor incluyen “en marcha + alarma P1” y “en marcha + alarma P2” como estados propios en lugar de sustituir el color de marcha: el operador necesita los dos datos a la vez.
Parpadear significa no reconocida, y nada más
El parpadeo es la señal de atención más cara de la que dispones, y es agotadora. Resérvala para un único significado: una alarma nueva que nadie ha reconocido todavía. Una vez reconocida, el badge pasa a fijo y se mantiene hasta que desaparece la condición. Una pantalla en la que las cosas parpadean permanentemente ha enseñado a sus operadores a ignorar el parpadeo.
6. Las tres visualizaciones que necesita un sistema de alarmas
- El banner. Siempre visible, en todas las pantallas, mostrando las alarmas no reconocidas de mayor prioridad: normalmente la línea o las dos líneas más recientes. Responde a “¿pasa algo ahora mismo?” sin tener que navegar.
- El resumen. Una lista ordenable y filtrable de alarmas activas con prioridad, tag, descripción, hora y estado de reconocimiento. La ordenación por defecto debe ser primero por prioridad y luego por hora, no solo por hora, que entierra una P1 bajo una avalancha de P3.
- El badge del sinóptico. Sobre el gráfico de proceso, tal como se ha descrito arriba. Es lo que convierte “LSHH-104 muy alto” en “ese depósito, el de ahí”.
Una cuarta vista —la página de histórico y análisis de alarmas— es para ingeniería y no para operación, pero es de donde salen tus métricas de tasa y tus listas de malos actores, así que no la omitas.
7. Aparcado, supresión y fuera de servicio: hazlos visibles
Toda planta real necesita una forma de silenciar temporalmente una alarma: un transmisor que se sabe averiado, una unidad parada por mantenimiento, una alarma molesta a la espera de arreglo. ISA-18.2 distingue estos mecanismos, y la consecuencia importante para la HMI es la misma en todos ellos:
Una alarma suprimida tiene que verse suprimida. Nunca dejes que la pantalla dé a entender que una alarma callada es una alarma sana.
En la práctica: un tag aparcado conserva un marcador atenuado en el sinóptico, aparece en un filtro específico de “aparcadas” dentro del resumen y lleva una caducidad. Aparcar sin caducidad se convierte en supresión permanente, que es como las plantas acaban con instrumentos “temporalmente” deshabilitados desde hace tres años.
8. Cortar la oscilación antes de que llegue a la pantalla
La mayor parte del ruido de alarmas se arregla en la lógica, y ahí sale más barato que en la HMI:
- Banda muerta. La alarma se repone en un valor claramente por dentro del umbral, no en el umbral mismo. Un pequeño porcentaje del rango elimina casi toda la oscilación.
- Retardo a la conexión. La condición tiene que mantenerse un tiempo definido antes de que se dispare la alarma. Los transitorios que se resuelven solos en dos segundos nunca necesitaron un operador.
- Retardo a la desconexión. Evita el parpadeo a la salida.
- Supresión basada en estado. Una alarma de caudal bajo en una bomba parada no es información: es ruido. Suprime las alarmas que carecen de sentido en el estado actual del equipo, y haz que esa lógica sea explícita y esté documentada, no un apaño escondido.
- Primera causa y agrupación causa-efecto. Cuando un evento raíz produce necesariamente diez alarmas consecuentes, presenta la causa raíz y colapsa el resto.
Son los cambios con más rendimiento de los que dispones. Solo la banda muerta y el retardo a la conexión reducen habitualmente la tasa de alarmas de una planta a menos de la mitad, y no cuestan más que tiempo de revisión.
9. Qué medir
No se puede discutir sobre la calidad de las alarmas sin números. El conjunto mínimo:
- Media de alarmas por operador y hora, y por operador y día: el número de salud principal.
- Pico de tasa en una ventana de diez minutos: detecta las avalanchas que las medias esconden.
- Los diez peores actores: en la mayoría de las plantas, un puñado de tags genera una parte enorme de todas las alarmas. Arreglar diez de ellos cambia la experiencia del día a día más que cualquier rediseño.
- Número y antigüedad de las alarmas persistentes: alarmas activas durante más de un turno.
- Distribución de prioridades: compárala con la forma 5 / 15 / 80.
- Número de alarmas aparcadas y cumplimiento de su caducidad.
10. Una lista de comprobación que puedes aplicar esta semana
- Exporta la lista de alarmas. Cuéntalas. Calcula la tasa diaria por operador.
- Para cada alarma, rellena tres columnas: consecuencia, acción del operador y tiempo de respuesta. Todo lo que tenga la columna de acción en blanco es candidato a eliminarse o a bajar de prioridad.
- Ordena los diez peores actores por número de disparos y arréglalos con banda muerta, retardo a la conexión o supresión basada en estado.
- Comprueba la distribución de prioridades. Si las P1 pasan del ~10 %, vuelve a racionalizar.
- Confirma que cada prioridad tiene un color propio y una señal no cromática propia en la pantalla.
- Confirma que el parpadeo significa exactamente una cosa en tu HMI.
- Confirma que las alarmas suprimidas y las aparcadas se ven como tales.
- Pon un banner en todas las pantallas si aún no lo hay.
Dibuja los estados de alarma, no los improvises. Los badges P1/P2, los marcadores de alarma y de estado y la paleta tranquila de ISA-101 están integrados en el Symbol Builder: colorea el cuerpo del equipo y exporta los nueve estados estándar, badges incluidos, como un juego listo para importar.
Abrir el Symbol Builder → Conseguir la chuleta de ISA-101 →Preguntas frecuentes
¿ISA-18.2 es lo mismo que IEC 62682?
En la práctica sí: IEC 62682 es la adopción internacional de ANSI/ISA-18.2, así que una planta que se certifique contra cualquiera de las dos trabaja con el mismo ciclo de vida. EEMUA 191 es una guía aparte, más antigua y más prescriptiva, muy utilizada por sus benchmarks de rendimiento.
¿Cuántas prioridades deberíamos tener?
Tres o cuatro. Con tres (crítica / alta / baja) basta para la mayoría de las plantas y son más fáciles de asignar con coherencia. A partir de cuatro, las fronteras dejan de ser defendibles, lo que empuja todo hacia arriba.
¿Las alarmas deben ser audibles?
Sí para las P1 y normalmente para las P2, con un sonido distinto por prioridad y silenciable de forma independiente del reconocimiento. Una señal acústica que no se puede silenciar sin reconocer enseña a los operadores a reconocer a ciegas.
¿Dónde queda el diseñador de la HMI si la planta no tiene filosofía de alarmas?
Escribe las dos páginas que importan: las definiciones de prioridad con sus tiempos de respuesta y la correspondencia de color y forma. Consigue que las firmen. No es un documento de filosofía completo, pero hace defendible tu pantalla y suele ser la semilla que la planta necesitaba.