¿Qué es una alarma de falla de comunicación?
Una alarma de falla de comunicación es la alerta que un sistema SCADA levanta cuando un sitio remoto deja de responder, no porque el proceso salió mal, sino porque el enlace a él se oscureció. Responde una pregunta que preocupa a todo operador: esa lectura de presión plana y sin cambios, ¿es real, o es el último valor de un sitio que se cayó de la red hace una hora? Esta guía explica cómo se genera una alarma de falla de comunicación, por qué debe manejarse distinto de una alarma de proceso y cómo se relaciona con la lógica de latido y watchdog que hay debajo.
Alarma de falla de comunicación en una línea: Una alarma de falla de comunicación es una alarma de SCADA que indica que el maestro perdió comunicación con un dispositivo o sitio de campo, así que los datos que se muestran para ese sitio están rancios y ya no pueden confiarse. Es en el fondo una alarma sobre el propio sistema de monitoreo más que sobre el proceso, y se dispara cuando las respuestas, sondeos o mensajes de latido esperados dejan de llegar dentro de un timeout configurado, alertando a los operadores de que están efectivamente ciegos a esa ubicación hasta que el enlace regrese.
Cómo se detecta una alarma de falla de comunicación
Una alarma de falla de comunicación se genera por la ausencia del tráfico esperado. En una arquitectura de sondeo, el maestro espera una respuesta válida cada vez que interroga a un dispositivo; cuando las respuestas dejan de llegar y los reintentos sucesivos expiran, el maestro concluye que el dispositivo es inalcanzable y levanta la alarma. En una arquitectura de reporte por excepción o de publicación, se espera que el dispositivo de campo se reporte de forma periódica con un latido aun cuando nada haya cambiado, así que el maestro arranca una cuenta regresiva después de cada latido y declara falla de comunicación si el siguiente no llega antes de que expire el temporizador.
La temporización es deliberadamente tolerante para evitar alarmas falsas. Un solo sondeo o latido perdido por lo general se ignora, porque la pérdida momentánea de paquetes es normal en enlaces celulares y de radio; la alarma dispara sólo tras una racha de fallas o tras un periodo de gracia varias veces más largo que el intervalo normal de reporte. Este umbral es un balance: fíjelo demasiado justo y los operadores se ahogan en alarmas molestas cada vez que una torre celular hipa, fíjelo demasiado holgado y un sitio genuinamente muerto pasa inadvertido por demasiado tiempo. Acertar con ese timeout para cada tipo de enlace es una parte medular de calibrar un sistema de monitoreo remoto.
Una vez disparada, la alarma por lo general también marca los datos afectados como rancios para que los operadores no se dejen engañar por valores congelados. Una presión que no se ha actualizado en una hora sigue mostrando un número en la pantalla, y sin un indicador de rancio ese número parece una lectura viva y sana. Marcar los tags como sospechosos - atenuándolos, mostrando una hora de última actualización o superponiendo un banderín de falla de comunicación - es tan importante como la alarma misma, porque impide que la gente tome decisiones sobre datos que ya no se están refrescando.
Falla de comunicación contra una alarma de proceso real
La distinción crítica es que una alarma de falla de comunicación le dice algo sobre el sistema, mientras que una alarma de proceso le dice algo sobre el campo. Una alarma de presión alta significa que la presión de verdad está alta y alguien puede tener que actuar sobre el equipo. Una alarma de falla de comunicación significa que usted ya no sabe cuál es la presión - podría estar perfectamente normal o peligrosamente alta, y la respuesta honesta es que no puede ver. Tratar a las dos de la misma forma es una receta para la respuesta equivocada.
Esta diferencia moldea cómo debe presentarse y manejarse la alarma. Una alarma de falla de comunicación muchas veces recibe su propia categoría, color y prioridad para que los operadores la reconozcan de inmediato como un problema de visibilidad y no como una desviación de proceso. También suele suprimir o reclasificar las alarmas de proceso aguas abajo de ese sitio, porque una vez que el enlace está muerto, cualquier estado de alarma de proceso es sólo la última condición conocida congelada en su lugar; seguir tratando esos estados rancios como alarmas activas sería engañoso y saturaría la lista de alarmas. Manejar esto bien es una parte reconocida de la buena gestión de alarmas.
Hay también una dimensión sutil de seguridad. Una falla de comunicación debe tratarse en general como una pérdida de monitoreo sobre equipo potencialmente vivo, no como un evento benigno, sobre todo en sitios que pueden experimentar desviaciones reales. La respuesta correcta muchas veces es restaurar la visibilidad rápido o despachar a alguien a revisar físicamente la ubicación, precisamente porque el estado del proceso durante el apagón es desconocido. Descartar una falla de comunicación como una mera molestia de red puede dejar un problema genuino desarrollándose sin ser visto.
Alarmas de falla de comunicación en SCADA de nube y operaciones de campo
En operaciones distribuidas de petróleo y gas, las alarmas de falla de comunicación son muchas veces las alarmas más importantes operativamente que produce un sistema de monitoreo, porque los sitios no atendidos dependen por completo del enlace para tener cualquier conciencia. Cuando una plataforma de pozo se cae de la red, la alarma de falla de comunicación es lo único que se interpone entre el operador y el falso consuelo de una pantalla llena de números rancios pero de apariencia normal. Una plataforma SCADA de nube como Merobix se apoya en esta alarma para hacer visible lo invisible: en el momento que un sitio deja de reportarse, la alarma y las banderas de datos rancios le dicen al operador exactamente cuál ubicación se quedó callada.
Como la alarma cabalga sobre la lógica de latido y watchdog, su confiabilidad depende de que esa maquinaria subyacente esté configurada correctamente. El intervalo de latido fija qué tan rápido puede detectarse una falla, y el multiplicador de timeout fija qué tan tolerante es el sistema al ruido normal del enlace. Una plataforma que le permite ajustar estos por sitio - una plataforma celular parlanchina distinto de un enlace satelital marginal - produce alarmas de falla de comunicación que son a la vez prontas y confiables, en lugar de un chorro de alarmas falsas que los operadores aprenden a ignorar.
Los datos de falla de comunicación también son valiosos en agregado. Un sitio que levanta y limpia alarmas de falla de comunicación de forma repetida le está diciendo que su enlace es marginal mucho antes de que falle de plano, lo cual es una advertencia temprana de problemas de antena, energía o portadora. Generar tendencias de la frecuencia de fallas de comunicación en una flota convierte una dispersión de eventos molestos individuales en una señal de mantenimiento, dejando a los operadores arreglar un enlace fallando en una visita programada en lugar de perseguir una interrupción dura después de que el sitio ya se oscureció.
Preguntas frecuentes
¿En qué se diferencia una alarma de falla de comunicación de una alarma de proceso?
Una alarma de proceso reporta una condición real en el campo, como presión alta, sobre la que alguien puede tener que actuar. Una alarma de falla de comunicación reporta que el enlace al sitio está caído, así que los valores en la pantalla están rancios y el estado real del proceso es desconocido. Las dos exigen respuestas distintas: una alarma de proceso apunta al equipo, mientras que una de falla de comunicación significa que perdió la visibilidad y debe restaurarla o revisar físicamente el sitio.
¿Qué dispara una alarma de falla de comunicación?
La dispara la ausencia de la comunicación esperada más que cualquier valor malo específico. Cuando los sondeos quedan sin respuesta a través de reintentos repetidos, o cuando un dispositivo deja de enviar su latido periódico dentro de un timeout configurado, el maestro concluye que el sitio es inalcanzable y levanta la alarma. Se usan un periodo de gracia y un conteo de reintentos para que la pérdida momentánea ordinaria de paquetes no cause alarmas falsas.
¿Deben mostrarse los datos rancios durante una falla de comunicación?
Los últimos valores conocidos por lo general se mantienen en la pantalla pero marcados con claridad como rancios, con una hora de última actualización o un banderín de falla de comunicación, para que a los operadores no los engañen leyendo un número congelado como si fuera vivo. Marcar los tags afectados como sospechosos es tan importante como la alarma misma, porque una presión que no se ha actualizado en una hora sigue mostrando un valor de apariencia normal y podría ocultar un cambio real ocurrido después de que el enlace se cayó.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.