Configurar alarmas de energía sin generar ruido operativo

Equipo Yubox
Equipo Yubox
24 de July, 2026
Energía Alarmas Industria
Configurar alarmas de energía sin generar ruido operativo

La norma EEMUA 191, la guía de referencia en gestión de alarmas industriales, fija un umbral concreto para una sala de control sana: en operación estable, el promedio no debería superar una alarma cada 10 minutos. El estándar ISA-18.2 va más allá y define con precisión cuándo una alarma dejó de ser información y se volvió ruido: si una misma señal transiciona entre normal y activa tres o más veces en 60 segundos, es una “alarma parpadeante” (chattering alarm), y si un sistema recibe más de 10 alarmas en 10 minutos, eso ya califica como una inundación de alarmas (alarm flood). Ya cubrimos qué severidad asignar a cada evento eléctrico; este artículo va un nivel más abajo, a los parámetros de configuración que determinan si esa alarma suena una vez con sentido o suena veinte veces sin que nadie la atienda.

Deadband: por qué un umbral simple genera alarmas parpadeantes

Configurar “avisar si el desequilibrio de voltaje supera 3%” parece suficiente, pero un valor que oscila de forma natural alrededor del umbral —2.9%, 3.1%, 2.8%, 3.2%— dispara y limpia la alarma en cada cruce. Eso es exactamente una alarma parpadeante según la definición de ISA-18.2, y es la causa más común de que un operador termine ignorando el canal completo.

La corrección es el deadband (banda muerta): un umbral asimétrico donde el valor de disparo y el valor de limpieza no son el mismo número. Si la alarma se dispara al cruzar 3.0% de desequilibrio, no se limpia hasta que el valor baja de 2.5%, no de 2.99%. Esa banda de medio punto absorbe el ruido normal de medición sin ocultar una tendencia real. El tamaño correcto del deadband no es universal: depende de la varianza propia de cada circuito, por lo que debe calibrarse contra el histórico de esa línea específica, no copiarse de otra instalación.

On-delay: confirmar antes de disparar

El segundo parámetro es el on-delay (o debounce): exigir que la condición se sostenga un tiempo mínimo —típicamente 10 a 60 segundos, según la variable— antes de declarar la alarma activa, en vez de disparar en la primera lectura fuera de rango.

Esto importa especialmente en energía porque varios eventos normales de planta generan picos momentáneos que parecen fallas: la corriente de arranque (inrush) de un motor grande puede llegar a 6-8 veces su corriente nominal durante 1-2 segundos, y una caída de tensión momentánea al conmutar una carga pesada puede durar menos de medio ciclo. Un umbral sin on-delay convierte cada arranque de motor o cada conmutación de carga en una alarma; con 10-15 segundos de confirmación, esos transitorios normales nunca cruzan el umbral de tiempo y solo se reporta lo que persiste.

El costo de un on-delay mal calibrado es real en el otro sentido: si es demasiado largo, un hueco de tensión que sí daña equipo sensible (como describimos en huecos de tensión bajo IEC 61000-4-30) puede quedar sin alarma porque terminó antes de completar la ventana de confirmación. Por eso el on-delay se define por variable, no como un valor global: milisegundos para huecos de tensión, segundos para corriente de arranque, minutos para tendencias de desequilibrio.

Cuando cae la red: de 40 alarmas a un solo evento

El escenario que más ruido genera en una planta con monitoreo distribuido no es un sensor defectuoso, es un evento real que afecta a muchos puntos a la vez. Cuando la red eléctrica cae, cada medidor, cada gateway y cada tablero instrumentado puede perder comunicación o reportar voltaje cero casi al mismo instante. Sin agrupación, eso son 40 alarmas individuales de “sin comunicación” o “voltaje bajo” llegando en el mismo minuto: una inundación de alarmas en el sentido literal de ISA-18.2, muy por encima del umbral de 10 en 10 minutos que define el estándar.

La solución no es silenciar esas alarmas, es correlacionarlas por causa raíz antes de notificar. Si 15 medidores en el mismo alimentador reportan pérdida de comunicación dentro de la misma ventana de 30 segundos, el sistema debe agrupar eso en un solo evento —“corte de red en alimentador X, 15 puntos afectados”— en vez de mandar 15 notificaciones idénticas. El operador necesita saber que cayó la red, no recibir la misma noticia 15 veces con 15 nombres de dispositivo distintos. Esta misma lógica de agrupar señales relacionadas en un evento compuesto es la que ya aplicamos al diseñar alarmas para eventos climáticos: una señal aislada es ruido, un patrón correlacionado es una alarma que vale la pena atender.

Horarios de silencio para eventos ya conocidos

No toda condición fuera de rango es una sorpresa. Un mantenimiento programado que desenergiza un circuito, una prueba de arranque de generador (la práctica de “ejercicio” mensual recomendada por NFPA 110), o una ventana de trabajo con el interruptor abierto intencionalmente son eventos que el equipo ya sabe que van a ocurrir. Configurar una supresión programada —lo que ISA-18.2 llama estado de “fuera de servicio” o “shelved”— para esas ventanas evita que el sistema dispare la misma alarma crítica que dispararía un corte real, sin necesidad de que alguien la reconozca y la descarte manualmente cada vez.

La diferencia frente a simplemente apagar el sensor es que la supresión programada tiene inicio y fin definidos: si el mantenimiento se extiende más de lo previsto, la alarma vuelve a activarse automáticamente al vencer la ventana, en vez de quedar silenciada de forma indefinida por olvido.

Escalamiento: qué pasa si nadie confirma la alarma

Una alarma sin destinatario claro ni plazo de respuesta es tan inútil como una alarma que suena de más. El complemento del deadband y el on-delay es el escalamiento por confirmación (ACK): la alarma crítica llega primero al canal normal (chat del equipo de turno); si nadie la confirma en una ventana definida —por ejemplo 5 minutos para un evento de severidad alta—, escala automáticamente a un segundo contacto o a un canal que sí interrumpe (llamada telefónica). Esto cierra el hueco más común de los sistemas de alarma mal configurados: notificaciones que sí se enviaron, pero a una persona que estaba fuera de cobertura o que las vio tarde, sin que nadie más se enterara del retraso.

Metas medibles: cómo saber si su configuración de alarmas funciona

EEMUA 191 y ISA-18.2 no son solo checklists de buenas prácticas, dan números concretos contra los que se puede medir una instalación real:

  • Tasa promedio en operación estable: menos de 1 alarma cada 10 minutos por consola u operador.
  • Alarmas en pie (standing alarms): menos de 10 alarmas activas sin reconocer en promedio; un número alto indica que se están generando alarmas que nadie resuelve.
  • Distribución por prioridad: aproximadamente 5% críticas, 15% altas y 80% bajas o informativas. Si más del 20-30% de las alarmas de una planta están marcadas como críticas, la clasificación está mal calibrada y la severidad real se diluye.
  • Definición de inundación: más de 10 alarmas en 10 minutos. Es la métrica que indica si el sistema necesita agrupación por causa raíz, no solo ajustar umbrales individuales.

Auditar la configuración de alarmas de un circuito contra estos cuatro números, con datos de al menos un mes de histórico, es más útil que revisar umbral por umbral: revela de inmediato si el problema está en un deadband mal calibrado, en falta de agrupación, o en una clasificación de severidad que convirtió casi todo en “crítico”.

Cómo se configura esto en la práctica

En Yubox Cloud, cada variable que reporta un medidor de energía LoRaWAN —voltaje, corriente, factor de potencia, desequilibrio— tiene su propio deadband, su propio on-delay y su propia ventana de supresión programada, calibrados contra el histórico de ese circuito específico y no contra un valor genérico de catálogo. La agrupación por causa raíz corre sobre los mismos datos que ya llegan al gateway LoRaWAN de la planta, cruzando eventos de comunicación perdida entre dispositivos del mismo alimentador antes de decidir si se notifica un evento o quince.

Conclusión

Una alarma de energía bien configurada no es la que nunca suena, es la que suena una sola vez por cada problema real: con deadband para no parpadear, on-delay para no reaccionar a transitorios normales, agrupación por causa raíz para no multiplicar un solo corte de red en decenas de avisos idénticos, y un plazo de escalamiento para que una alarma sin respuesta no se quede sin dueño. Los cuatro parámetros de ISA-18.2 y EEMUA 191 —tasa promedio, alarmas en pie, distribución por prioridad y definición de inundación— son la forma de comprobar, con números y no con intuición, si la configuración actual protege la operación o solo la satura. ¿Quiere auditar la configuración de alarmas de su planta? Conversemos.