El 24 de julio de 1994, una tormenta eléctrica desencadenó una serie de fallas en la refinería Texaco de Milford Haven, Gales. Durante cinco horas, los operadores intentaron controlar el caos mientras el sistema de alarmas los bombardeaba sin parar. La investigación oficial concluyó que la causa principal no fue la tormenta ni los equipos: fue que "el número excesivo de alarmas redujo la efectividad de la respuesta de los operadores." En los 11 minutos previos a la explosión, habían recibido 275 alarmas. Los incendios tardaron dos días en extinguirse y 26 personas resultaron heridas.
No es que no tuvieran información. Tenían demasiada — y eso fue exactamente el problema.
Este patrón se repite en plantas de tratamiento de agua, salas de calderas y líneas de producción: los sistemas generan más alarmas de las que cualquier operario puede procesar, y el resultado no es más seguridad sino menos.
El estándar internacional EEMUA 191 establece que una planta bien gestionada no debería superar 6 alarmas por hora por operador en condiciones normales. La realidad documentada en incidentes industriales es de 146 alarmas cada 10 minutos. Entre esos dos números vive el problema que este artículo describe — y que UniCloud resuelve.
Ver alarmas no es lo mismo que analizarlas
Cuando un sistema SCADA o un PLC muestra una alarma en pantalla, le está diciendo al operario que algo superó un límite. Eso es todo. No dice si eso pasó una vez esta semana o cuarenta. No dice si la duración fue de tres segundos o de cuarenta minutos. No dice si la tendencia viene en ascenso desde hace tres días.
Una alarma sin contexto histórico no es información accionable. Es ruido con urgencia artificial.
El problema se compone cuando se considera el efecto cascado: el 70% de los incidentes en plantas industriales ocurre durante arranque o paro de equipos, precisamente cuando una sola falla puede disparar decenas de alarmas en segundos. El operario ve el aluvión y no puede distinguir cuál fue la primera — la que desencadenó todo. Trabaja sobre consecuencias mientras la causa raíz sigue activa.
Analizar alarmas es diferente. Significa responder preguntas como: ¿cuál es la alarma que más tiempo acumula activa en el mes? ¿Qué máquina de mi flota tiene el peor comportamiento? ¿Esta alarma es nueva o es el mismo problema de siempre que nadie resolvió?
UniCloud Alarm Analytics fue diseñado específicamente para responder esas preguntas, sin código, sobre máquinas con PLCs Unitronics conectados.
Las 4 herramientas estadísticas que usa UniCloud
El módulo de Alarm Analytics de UniCloud opera sobre cuatro tags de PLC: Alarm Severity, Alarm Name, Alarm Duration y Alarm Index. Con esos datos, implementa un flujo de análisis en tres dashboards que cubre las principales metodologías de gestión de alarmas según ISA 18.2 y EEMUA 191.
1. Análisis Pareto / Bad Actors
El principio de Pareto aplica directamente a las alarmas industriales: el 20% de las alarmas configuradas genera el 80% de las activaciones totales. Estos son los "bad actors" — los focos de problema real en una planta.
UniCloud identifica automáticamente qué alarmas tienen mayor frecuencia y mayor duración acumulada, y las presenta ordenadas. El integrador no necesita revisar cientos de registros: los problemas que más cuestan ya están rankeados.
2. Análisis de tendencia
No basta saber cuántas alarmas hubo hoy. Lo que importa es si la curva sube, baja o es estable semana a semana. Una tendencia ascendente en alarmas Critical es la señal de deterioro antes del fallo — exactamente la ventana de intervención preventiva que el integrador necesita para actuar antes de que el cliente llame con un paro de producción.
3. Análisis de duración
Una alarma que dura 3 segundos y una que dura 40 minutos tienen el mismo aspecto en una lista de notificaciones. Su impacto real en disponibilidad es radicalmente diferente.
El análisis de duración acumulada por alarma es el indicador más directo de pérdida de disponibilidad. UniCloud lo calcula automáticamente y lo presenta por máquina y por tipo de alarma, permitiendo priorizar intervenciones según impacto real, no según frecuencia de aparición.
4. Distribución por severidad (Priority Distribution)
Un sistema de alarmas bien calibrado debería tener pocas alarmas críticas y la mayoría en niveles inferiores. Si el 60% de las alarmas de una máquina son críticas, hay dos posibilidades: o los límites están mal configurados, o hay un problema estructural. Ambos casos requieren atención diferente.
UniCloud desglosa las alarmas por nivel de severidad y permite comparar ese perfil entre máquinas de la misma flota. Una máquina con distribución anormal frente a sus pares es un candidato inmediato a revisión.
Análisis de causa raíz en tres pasos
El diseño de Alarm Analytics en UniCloud sigue una lógica de drill-down que va de lo general a lo específico:
Dashboard 1 — Vista de flota: muestra tendencias de alarmas Critical y Major en todas las máquinas, con ranking por duración y cantidad. El objetivo es identificar qué activo se comporta de forma anormal respecto al resto. Esta es la vista del jefe de mantenimiento o del gerente de operaciones.
Dashboard 2 — Asset → Alarms: una vez identificada la máquina problema, este dashboard muestra qué alarmas específicas tienen mayor impacto en ella. Combina frecuencia, duración y severidad para determinar cuáles requieren atención inmediata. Esta es la vista del técnico antes de una intervención.
Dashboard 3 — Alarm → Assets: invierte el flujo. Parte de una alarma específica y muestra cómo se comporta en todas las máquinas de la flota. ¿Es un problema de esa máquina, o es sistémico? Esta pregunta, respondida con datos, cambia completamente la estrategia de mantenimiento.
Los tres dashboards juntos forman el ciclo completo: identificar → priorizar → actuar → verificar.
Notificaciones automáticas: cerrar el ciclo
El análisis de alarmas identifica el problema. Las notificaciones automáticas aseguran que llegue a la persona correcta en el momento correcto.
UniCloud permite configurar tres tipos de trigger para notificaciones:
- Por alarma: cuando una alarma específica se activa (o supera un umbral de frecuencia)
- Por telemetría: cuando un valor de proceso cruza un límite definido
- Por calendario: reportes programados a horas o días específicos
El destinatario puede ser el técnico de campo, el supervisor de turno, o el cliente final — con niveles de acceso diferenciados. El mensaje puede enviarse por email o SMS.
El resultado es un sistema que no solo registra lo que ocurrió, sino que actúa cuando ocurre. La combinación de análisis histórico y notificación proactiva es lo que cierra la brecha entre ver alarmas y gestionar alarmas.
¿Qué significa esto en la práctica?
Una planta con tres equipos conectados a UniCloud tiene, desde el primer día, acceso a un sistema de análisis que cumple con los estándares ISA 18.2 y EEMUA 191 — los mismos que regulan la gestión de alarmas en industrias críticas a nivel mundial.
Sin código. Sin infraestructura adicional. Con los PLCs Unitronics ya instalados.
Lo que eso habilita no es solo mejor mantenimiento. Es un modelo de servicio diferente: en lugar de cobrar por visita de emergencia, el mantenedor puede ofrecer un contrato de mantenimiento predictivo respaldado por datos, con reportes mensuales que demuestran valor tangible al cliente.
La diferencia entre un mantenedor que "mantiene equipos" y uno que "gestiona el desempeño de activos" no es solo de posicionamiento. Es de cuánto puede cobrar por el mismo trabajo — y con qué argumento retiene al cliente el año siguiente.
La diferencia entre un mantenedor que "mantiene equipos" y uno que "gestiona el desempeño de activos" no es solo de posicionamiento. Es de cuánto puede cobrar por el mismo trabajo — y con qué argumento retiene al cliente el año siguiente.
¿Tienes máquinas con PLCs Unitronics conectadas y quieres ver cómo se ve Alarm Analytics con tus propios datos? Contáctanos en i40 Networks.
Referencias
UniCloud Alarm Analytics — Template oficial
EEMUA Publication 191 — Alarm Systems Guide
ISA 18.2 — Management of Alarm Systems
Alarm Floods and Plant Incidents — Automation.com
Pareto & Bad Actors in Alarm Management — exida