La gestión de alarmas en fabricación es la disciplina que garantiza que cada alarma que ve un operador sea real, relevante y accionable. Esta guía explica por qué se producen las avalanchas de alarmas, qué exige el ciclo de vida de ISA-18.2, cómo definir prioridades y bandas muertas, y cómo publicar eventos de alarma por MQTT para que dashboards, notificaciones y herramientas de análisis vean la misma verdad.
Por qué importa la gestión de alarmas
Una alarma existe para avisar al operador de que algo requiere una respuesta en un tiempo limitado. Cuando esa promesa se rompe, las personas aprenden a ignorar las alarmas. Síntomas típicos en plantas sin gestión de alarmas:
- Alarmas permanentes que siguen activas durante días porque nadie puede o quiere corregir la causa.
- Alarmas intermitentes (chattering) que se activan y desactivan muchas veces por minuto alrededor de un límite.
- Avalanchas de alarmas tras una perturbación, cuando una sola causa raíz dispara decenas de alarmas consecuentes y la importante desaparece de la pantalla.
- Todo es prioridad alta, de modo que la prioridad no aporta información.
- Alarmas sin respuesta definida, configuradas "por si acaso" durante la puesta en marcha.
El resultado es la fatiga de alarmas. Los operadores reconocen sin leer, y cuando llega una alarma realmente crítica compite con el ruido. Las investigaciones de varios incidentes industriales conocidos señalaron a operadores desbordados como factor contribuyente, y por eso la gestión de alarmas se convirtió en una disciplina formal.
Fundamentos de ISA-18.2
ANSI/ISA-18.2 (y su equivalente internacional IEC 62682) es la norma de referencia para la gestión de alarmas en la industria de procesos, y sus ideas se aplican igual de bien a la fabricación discreta. Su concepto central es un ciclo de vida de la gestión de alarmas:
| Etapa | Qué ocurre | Resultado |
|---|---|---|
| Filosofía | Definir qué es una alarma, prioridades, colores, tiempos de respuesta, KPI | Documento de filosofía de alarmas |
| Identificación | Encontrar alarmas candidatas a partir de estudios de riesgos y necesidades de calidad y mantenimiento | Lista de candidatas |
| Racionalización | Justificar cada alarma: causa, consecuencia, respuesta, tiempo de respuesta, prioridad | Base de datos maestra de alarmas |
| Diseño detallado | Definir límites, bandas muertas, retardos, lógica de supresión | Alarmas configuradas |
| Implementación | Desplegar, probar, formar a los operadores | Sistema en producción |
| Operación | Los operadores responden; el aplazamiento (shelving) y el fuera de servicio se gestionan por procedimiento | Eventos de alarma |
| Mantenimiento | Reparar instrumentos, probar alarmas | Sistema mantenido |
| Supervisión y evaluación | Medir tasas de alarmas, avalanchas, principales infractores | Acciones de mejora |
| Gestión del cambio | Controlar altas, bajas y cambios de límites | Registro de auditoría |
| Auditoría | Revisión periódica frente a la filosofía | Informe de auditoría |
El paso más valioso para la mayoría de las plantas es la racionalización. Para cada alarma, pregunta: ¿cuál es la causa, qué ocurre si nadie actúa, qué debe hacer exactamente el operador y de cuánto tiempo dispone? Una alarma sin una respuesta clara a la tercera pregunta no es una alarma: es un evento o una notificación y pertenece a un registro, no a la pantalla del operador.
ISA-18.2 también ofrece referencias de uso habitual para la carga de alarmas por operador y define una avalancha de alarmas como una ráfaga que supera lo que un operador puede gestionar, normalmente más de diez alarmas en diez minutos. Utiliza las cifras de la norma en tu filosofía en lugar de inventar las tuyas.
Una gestión de alarmas en fabricación que los equipos puedan sostener: prioridades y diseño
Definir prioridades
La prioridad debe surgir de dos factores: la gravedad de la consecuencia y el tiempo disponible para responder. Una matriz sencilla funciona:
| Consecuencia | Respuesta necesaria en minutos | Respuesta necesaria en una hora o más |
|---|---|---|
| Seguridad, medio ambiente o daño grave a equipos | Alta | Media |
| Pérdida de producto o retención por calidad | Media | Baja |
| Pérdida menor de eficiencia | Baja | No es una alarma (evento o notificación) |
Mantén reducida la proporción de prioridad alta. Si más que una pequeña minoría de las alarmas configuradas son de prioridad alta, revisa la racionalización.
Bandas muertas y retardos
La mayoría de las alarmas intermitentes son un problema de diseño, no de proceso:
- Banda muerta (histéresis): una alarma que se activa por encima de 80 °C solo se despeja por debajo de, por ejemplo, 78 °C.
- Retardo a la activación: la condición debe cumplirse durante un tiempo determinado antes de que la alarma se active, lo que filtra picos momentáneos.
- Retardo a la desactivación: la condición debe desaparecer durante un tiempo determinado antes de que la alarma vuelva a normal, lo que evita reactivaciones rápidas.
Supresión y aplazamiento
Durante una parada planificada, las alarmas de caudal bajo de una bomba detenida son esperables e inútiles. La supresión basada en estado oculta las alarmas que no tienen sentido en el estado actual de la máquina. El aplazamiento (shelving) permite a un operador retirar temporalmente una alarma molesta mediante un procedimiento controlado con un límite de tiempo automático, para que no quede olvidada.
Publicar eventos de alarma por MQTT
Las alarmas suelen originarse en PLC, DCS o SCADA. Publicarlas por MQTT permite que otros consumidores (tableros andon, notificaciones móviles, sistemas de mantenimiento, análisis) usen los mismos eventos sin integraciones separadas. Dos tipos de topic funcionan bien juntos:
acme/plant1/press/line3/press2/alarm/HYD_TEMP_HI retained: current state of this alarm
acme/plant1/press/line3/alarm-events not retained: every transition, for history
El topic retenido por alarma ofrece a cualquier cliente la lista de alarmas activas con solo suscribirse a .../alarm/#. El flujo de eventos alimenta una base de datos para KPI de alarmas como alarmas por hora, las diez más frecuentes y periodos de avalancha.
El ejemplo de Python siguiente implementa una alarma con banda muerta y retardo a la activación sobre una lectura de temperatura, y publica ambos topics. Utiliza paho-mqtt 2.x y el servidor MQTT público gratuito para pruebas; no lo uses para datos de producción.
import json
import time
import uuid
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/alm-2e7b/press2"
ALARM_ID = "HYD_TEMP_HI"
HIGH, CLEAR, ON_DELAY_S, PRIORITY = 80.0, 78.0, 5.0, "HIGH"
active = False
pending_since = None
def publish_alarm(client, state, value):
event = {"alarm": ALARM_ID, "state": state, "priority": PRIORITY,
"value": value, "limit": HIGH, "ts": time.time()}
client.publish(f"{BASE}/alarm/{ALARM_ID}", json.dumps(event), qos=1, retain=True)
client.publish(f"{BASE}/alarm-events", json.dumps(event), qos=1)
print(event)
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/hydraulic/temp", qos=1)
def on_message(client, userdata, msg):
global active, pending_since
value = json.loads(msg.payload)["tempC"]
now = time.time()
if not active:
if value > HIGH:
pending_since = pending_since or now
if now - pending_since >= ON_DELAY_S:
active = True
publish_alarm(client, "ACTIVE", value)
else:
pending_since = None
elif value < CLEAR:
active, pending_since = False, None
publish_alarm(client, "CLEARED", value)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"alarm-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()
Envía lecturas superiores a 80 durante más de cinco segundos y la alarma se activa; solo se despeja por debajo de 78. El reconocimiento puede añadirse del mismo modo: el HMI publica un evento de reconocimiento y el servicio de alarmas actualiza el estado retenido a ACTIVE_ACKED.
Checklist de gestión de alarmas
- Redacta una filosofía de alarmas de una página antes de configurar nada nuevo.
- Exporta la lista actual de alarmas y ordénalas por frecuencia; las diez primeras suelen generar la mayor parte de la carga.
- Racionaliza esas primero: causa, consecuencia, respuesta, tiempo, prioridad.
- Añade bandas muertas y retardos a cada alarma intermitente.
- Degrada a eventos o notificaciones las alarmas sin acción del operador.
- Implementa supresión basada en estado para máquinas detenidas o en cambio de formato.
- Mide semanalmente la tasa de alarmas por operador y los periodos de avalancha.
- Controla los cambios de límites y prioridades mediante la gestión del cambio.
Dónde encaja ConnectMQ
ConnectMQ es un broker MQTT gestionado que transporta eventos de alarma entre controladores, dashboards y servicios de notificación, con MQTT 5, retained messages, TLS y WebSocket seguro para pantallas andon en el navegador. El portal también incluye reglas de alerta por umbral y un registro de alertas, útiles para notificaciones de supervisión sencillas, por ejemplo una cámara frigorífica o la temperatura de un rodamiento que supera un límite fijo. Complementan, pero no sustituyen, a las alarmas de proceso racionalizadas y a los sistemas de seguridad de tu PLC o SCADA, que siguen siendo el lugar para las alarmas que requieren una acción del operador.
Para hacer visibles las alarmas en la línea, combínalas con un sistema andon digital y con la monitorización del estado de las máquinas. La guía de fabricación inteligente muestra cómo encajan los datos de alarmas en la arquitectura de datos completa de la planta, y los mismos topics pueden mostrar las alarmas activas sobre un gemelo digital 3D de la línea.
Envía tus eventos de alarma a través de ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com sin tarjeta de crédito, publica tus primeros topics de alarma y observa cómo la lista de alarmas activas se actualiza en directo en el explorador de topics.
Preguntas frecuentes
¿Qué es una avalancha de alarmas?
Una avalancha de alarmas es un periodo en el que las alarmas llegan más rápido de lo que un operador puede responder, a menudo después de que una sola perturbación dispare muchas alarmas consecuentes. ISA-18.2 suele usar como umbral más de diez alarmas en diez minutos por operador.
¿Qué es la racionalización de alarmas?
Es la revisión sistemática de cada alarma para documentar su causa, consecuencia, acción requerida del operador, tiempo de respuesta permitido y prioridad. Las alarmas que no superan esta revisión se eliminan o se convierten en eventos.
¿ISA-18.2 es solo para la industria de procesos?
Se redactó para la industria de procesos, pero su ciclo de vida, la racionalización y la supervisión del desempeño se aplican también a las líneas de fabricación discreta.
¿Se puede usar MQTT para alarmas de seguridad?
Las funciones de seguridad pertenecen a sistemas de seguridad y PLC certificados. MQTT es muy adecuado para distribuir información de alarmas a dashboards, notificaciones y análisis, no para ejecutar acciones de seguridad.
