Un enlace DNP3 o IEC 60870-5-104 que se cae y se recupera solo suele tener uno de estos orígenes: temporizadores del protocolo que no corresponden a la latencia real del canal, un firewall, NAT u operador celular que cierra la sesión TCP cuando no hay tráfico, dos maestros o conexiones que compiten por el mismo equipo, una avalancha de eventos que satura el gateway, o un canal físico inestable. El patrón de las caídas indica cuál es.
Síntoma
El centro de control pierde la comunicación con la subestación o con la planta, la recupera a los segundos o minutos, y el ciclo se repite. Los operadores ven datos congelados, alarmas de «enlace caído» y, al volver, una ráfaga de eventos atrasados. A veces el enlace es estable durante el día y se cae de noche, o funciona bien hasta que ocurre una falla en la red.
IEC 60870-5-104 y DNP3 corren sobre TCP/IP y supervisan la conexión con sus propios mecanismos: en IEC 104, temporizadores t0 a t3, ventanas k y w y tramas de prueba (TESTFR); en DNP3, confirmaciones de aplicación y mensajes de mantenimiento del enlace. Cuando uno de esos mecanismos vence, el extremo que lo detecta cierra la conexión y la reabre. El diagnóstico consiste en saber quién la cerró y por qué.
Causas posibles, de la más a la menos probable
| Causa | Por qué ocurre | Qué la delata |
|---|---|---|
| Sesión inactiva cerrada por un equipo intermedio | Firewall, NAT u operador celular con tiempo de inactividad menor que el intervalo de las tramas de prueba | Caídas en periodos sin tráfico, con intervalos regulares |
| Temporizadores frente a la latencia | t1 o los tiempos de confirmación de DNP3 más cortos que el retardo real del canal | Caídas en horas de mayor carga del canal o con radio y celular |
| Dos maestros o conexiones en conflicto | Maestro de respaldo que se conecta al mismo equipo, redundancia mal configurada, límite de conexiones | Una conexión desplaza a la otra; caídas al conmutar centros de control |
| Avalancha de eventos | Falla en la red con cientos de cambios en segundos que el gateway o el canal no alcanzan a enviar | Caídas que coinciden con eventos eléctricos |
| Canal físico inestable | Cobertura celular, desvanecimiento de radio, fibra o enrutadores con errores | Pérdida de paquetes y latencia variable medidas en el canal |
| Dirección IP cambiante o no autorizada | IP dinámica en un enlace celular, lista de maestros permitidos desactualizada | Rechazo de la conexión después de un cambio de IP |
Qué revisar primero
- Registro de caídas con su hora. Compare el patrón: intervalos regulares apuntan a temporizadores o a equipos intermedios; caídas con eventos eléctricos, a la capacidad; caídas aleatorias, al canal.
- Quién cierra la conexión. Los registros del gateway o de la RTU dicen si cerró por t1, por t3, por la ventana k, por una conexión nueva o porque el otro extremo la cerró.
- Equipos intermedios: router y firewall industrial, concentradores VPN y, en enlaces de radio y celulares, el tiempo de inactividad del operador.
- Latencia y pérdida del canal medidas durante varias horas, comparadas con los temporizadores configurados. La práctica es mantener t2 menor que t1 y t1 menor que t3.
- Conexiones activas en la estación remota: cuántos maestros están conectados y cuál tiene la transferencia activa. En IEC 104, los grupos de conexiones redundantes tienen una sola conexión activa a la vez.
- ¿Las caídas siguen un patrón regular de tiempo?
- Sí¿Ocurren en periodos sin tráfico?
- SíUn firewall, NAT u operador cierra la sesión inactiva: revise las tramas de prueba
- NoTemporizadores o ventanas del protocolo cortos frente a la latencia real del canal
- No¿Coinciden con eventos en la red eléctrica?
- SíAvalancha de eventos: revise buffers y capacidad del gateway y del canal
- No¿Hay otro maestro o una conexión de respaldo hacia el mismo equipo?
- SíConflicto de conexiones: revise la redundancia y los maestros permitidos
- NoRevise el medio físico: cobertura, radio, fibra o enrutadores intermedios
Cómo se confirma
- Captura de tráfico en ambos extremos o en el gateway: muestra la última trama antes de la caída, quién envió el cierre de TCP y qué temporizador venció.
- Analizador de protocolo que decodifica las tramas I, S y U de IEC 104 o las capas de DNP3, con los números de secuencia y las confirmaciones.
- Simulador de maestro conectado localmente a la RTU o al gateway: si el enlace local es estable, el problema está en el canal o en el centro de control.
- Prueba de avalancha en la puesta en servicio: generar muchos eventos a la vez y verificar que el enlace y el buffer los sostienen.
Cómo evitar que se repita
- Ajuste temporizadores y ventanas con la latencia medida del canal, no con los valores de fábrica, y acuérdelos con el centro de control.
- Defina el intervalo de las tramas de prueba menor que el tiempo de inactividad de los equipos intermedios.
- Diseñe la redundancia de centros de control y conexiones de acuerdo con el protocolo, con los maestros permitidos documentados.
- Dimensione los buffers de eventos para las avalanchas esperadas y para la duración razonable de una caída.
- Use IP fija o un servicio de VPN en los enlaces celulares.
- Aplique seguridad según IEC 62351 sin romper los tiempos del protocolo.
Qué no hacer
- No alargue los temporizadores sin medir. Unos temporizadores demasiado largos tardan en detectar una caída real y dejan al operador con datos viejos sin saberlo.
- No conecte un maestro de pruebas a una RTU en servicio sin coordinar: puede desplazar la conexión del centro de control.
- No deshabilite los buffers de eventos para «aligerar» el enlace.
- No abra el puerto del protocolo a cualquier dirección para resolver un rechazo.
Cuándo llamarnos
Si el enlace se cae y no está claro si es el protocolo, la red o la capacidad del gateway, nuestro equipo revisa en remoto la configuración de la RTU o del gateway, sus registros y los temporizadores frente al canal. Integramos y ponemos en servicio los enlaces de telecontrol con la integración de SCADA y gateways, y los diseñamos desde la ingeniería de comunicaciones. Escríbanos.
Guías relacionadas
- IEC 60870-5-104
- DNP3
- RTU y gateway de subestación
- Enlaces de radio y celulares
- Router y firewall industrial
- Sistema SCADA y HMI de subestación
- Mando rechazado desde el SCADA
Referencias
- IEC 60870-5-104, Network access for IEC 60870-5-101 using standard transport profiles, edición 2 y enmienda 1.
- IEEE 1815, Standard for Electric Power Systems Communications – Distributed Network Protocol (DNP3).
- IEC 62351, Power systems management and associated information exchange – Data and communications security.
Preguntas frecuentes
¿Por qué el enlace IEC 104 se cae cada cierto tiempo aunque el canal funciona?
Casi siempre por un temporizador o una ventana que no corresponde a la red: t1 vence porque el canal tiene más latencia de la prevista, o un equipo intermedio cierra la sesión TCP inactiva porque las tramas de prueba se envían con un intervalo mayor que su tiempo de inactividad.
¿Por qué se cae el enlace después de una falla en la red eléctrica?
Porque una falla genera en segundos cientos de eventos en todas las bahías. Si el gateway, su buffer o el canal no tienen capacidad para esa avalancha, las confirmaciones se retrasan, vencen los temporizadores y la conexión se reinicia justo cuando más se necesita.
¿Qué pasa con los eventos mientras el enlace está caído?
Tanto DNP3 como IEC 104 guardan los eventos con su estampa de tiempo en buffers de la estación remota y los envían al restablecer la conexión. Si la caída es larga o los eventos son muchos, el buffer puede desbordarse y se pierden los más antiguos o los más nuevos, según la configuración.