9.5. Validación de Mecanismos de Redundancia y Failover

UF1794 | Demostrando la alta disponibilidad empíricamente

graph TD subgraph Prueba_Failover ["Prueba de Redundancia (Ej: Anillo MRP)"] PLC["PLC (Manager)"] -->|"Envío Cíclico PROFINET RT"| IO["Periferia IO (Client)"] PLC -.->|"Cortar Cable Físicamente"| SW["Switch Nodo"] end subgraph Wireshark_Trace ["Traza Wireshark (Medición Empírica)"] T1["Paquete N
(t = 1.000 s)"] T2["Paquete N+1
(t = 1.002 s)"] GAP["[ CORTE - RECALCULO DE ANILLO ]
Delta Time = 0.050 s"] T3["Paquete N+2
(t = 1.052 s)"] T4["Paquete N+3
(t = 1.054 s)"] T1 --> T2 --> GAP --> T3 --> T4 end Prueba_Failover -->|"Captura de Tráfico (Mirroring)"| Wireshark_Trace style GAP fill:#e74c3c,color:white style T2 fill:#27ae60,color:white style T3 fill:#27ae60,color:white

1. El Momento de la Verdad: "Pull the Plug"

Has diseñado una red en anillo (MRP) para garantizar que si un cable se rompe, la fábrica no se detiene. Durante el SAT (Site Acceptance Test), el cliente no se va a conformar con ver la configuración en tu pantalla. El cliente te pedirá que literalmente "desenchufes el cable" (Pull the Plug) en medio de la producción para demostrar que el sistema de Failover (conmutación por error) funciona.

Para un técnico de UF1794, esta prueba debe realizarse con un protocolo estricto para evitar daños. Nunca se realiza con motores moviéndose a máxima velocidad por primera vez. Se hace en un estado de "máquina en vacío" o simulando el movimiento de los actuadores, verificando únicamente que el PLC no entra en modo "STOP" y que el SCADA se recupera.



2. Observación en el PLC y el HMI

Al desconectar un cable del anillo MRP, ocurren varias cosas en una fracción de segundo:

  1. El switch que pierde el enlace envía un aviso al Manager del anillo (MRM).
  2. El MRM abre su puerto bloqueado para restaurar la topología lineal.
  3. Si el proceso de recálculo (Failover) tarda más que el Watchdog Time configurado en el PLC (por defecto suele ser de 3 a 6 ciclos de actualización, ej. 6 ms), el PLC declarará "Fallo de Periferia".
  4. Veremos parpadear el LED rojo "BF" (Bus Fault) en el PLC durante un instante, pero si la redundancia funciona, volverá a verde sin detener la CPU.


3. Medición Empírica con Wireshark: El "Delta Time"

Para certificar formalmente que el anillo ha cumplido el estándar (ej. recuperación en menos de 200 ms), necesitamos medir el tiempo exacto que la red estuvo "muerta". Aquí es donde entra en juego Wireshark de forma magistral.

El procedimiento paso a paso es el siguiente:

  • Preparación: Configura un "Port Mirroring" en el switch principal hacia tu PC.
  • Filtro de Visualización: Aplica un filtro en Wireshark para aislar la comunicación cíclica entre el PLC y un esclavo concreto. Por ejemplo: eth.addr == MAC_DEL_ESCLAVO and profinet.
  • El Truco del Tiempo: En Wireshark, ve a View > Time Display Format y selecciona "Seconds Since Previously Displayed Packet" (Delta Time). Ahora, en lugar de la hora del reloj, verás el tiempo transcurrido desde el paquete anterior. En una red sana a 2ms, verás que cada paquete marca 0.002.
  • El Corte: Inicia la captura y dile a un compañero que desenchufe el cable del anillo.
  • Análisis: Detén la captura y busca en la columna de tiempo. Verás una larga lista de 0.002, de repente un paquete marcará un "salto" de tiempo (ej. 0.045), y luego los paquetes volverán a 0.002. ¡Felicidades! Acabas de demostrar empíricamente que tu red tardó exactamente 45 milisegundos en curarse.


4. Redundancia de Pasarela (VRRP)

El "Failover" no solo se aplica a los anillos de Capa 2. En la frontera con la red corporativa IT (Capa 3), dependemos de una Puerta de Enlace (Default Gateway). Si ese router se estropea, la fábrica se queda sin internet ni conexión al ERP.

Durante el SAT, también se debe probar el protocolo VRRP (Virtual Router Redundancy Protocol). En esta arquitectura, hay dos routers físicos, pero comparten una única IP "Virtual" (ej. 192.168.1.1). El PLC tiene configurada esa IP Virtual como su pasarela. Si apagas el router principal, el router de respaldo asume la IP Virtual en segundos. El PLC ni se entera de que el router físico ha cambiado, garantizando un flujo de datos ininterrumpido hacia el exterior.

Salida de Wireshark con formato "Delta Time"
No.  Time       Source        Destination   Protocol  Info
1    0.002011   PLC_Main      IO_Device_A   PNIO      C_Dev - Output Data
2    0.001995   PLC_Main      IO_Device_A   PNIO      C_Dev - Output Data
3    0.002005   PLC_Main      IO_Device_A   PNIO      C_Dev - Output Data
--- [CORTE FÍSICO DEL CABLE MRP] ---
4    0.048500   PLC_Main      IO_Device_A   PNIO      C_Dev - Output Data
5    0.002010   PLC_Main      IO_Device_A   PNIO      C_Dev - Output Data
6    0.001998   PLC_Main      IO_Device_A   PNIO      C_Dev - Output Data
Figura 1: El registro innegable. Cambiando la vista de tiempo en Wireshark a "Segundos desde el paquete mostrado anteriormente" (Delta Time), el ingeniero puede identificar al instante el "Gap" (hueco temporal) generado por la rotura del cable. En este caso, el paquete 4 tardó 48.5 milisegundos en llegar, demostrando que el anillo MRP recalculó su topología mucho antes del límite de 200 ms estipulado por la normativa.
Fuente: Elaboración propia.

📝 Evaluación Técnica: Pruebas de Failover

1. Durante la prueba de aceptación en planta (SAT), el cliente exige validar la fiabilidad de la red desenchufando un cable en pleno funcionamiento. ¿Cuál es el comportamiento esperado y aceptable de un anillo PROFINET MRP correctamente configurado al sufrir este corte?

2. El ingeniero de planta te pide certificar que el anillo MRP se ha recuperado en menos de 200 ms. Has configurado un puerto espejo y tienes Wireshark capturando la comunicación cíclica entre el PLC y un esclavo. ¿Qué configuración visual de Wireshark te dará esta respuesta al instante?

3. Para garantizar la redundancia de acceso a Internet/ERP en la Capa 3, se han instalado dos Routers industriales en la fábrica. ¿Cómo funciona el protocolo VRRP (Virtual Router Redundancy Protocol) en este escenario?

🤖 Ejercicio Práctico 9: Calculador de Tiempo de Inactividad (Downtime)

Objetivo: Replicar mediante código la función "Delta Time" de Wireshark para detectar brechas de comunicación simulando un ping continuo.

Copia el siguiente *prompt* y pégalo en un modelo de IA (como ChatGPT, Gemini o Claude).

Actúa como un ingeniero de pruebas de redes. Escribe un script en Python que simule un monitor continuo (Ping) y calcule el tiempo exacto de "Failover" si se interrumpe la red. El script debe: 1. Crear un bucle continuo (cada 0.1 segundos) que envíe una petición a una IP simulada (puedes simular la respuesta usando `time.time()`). 2. Guardar el "Timestamp" (marca de tiempo) exacto de la última respuesta exitosa. 3. Simular que, tras 5 segundos de ejecución, la red "cae" (falla la respuesta) durante exactamente 150 milisegundos (0.150s), y luego se recupera. 4. Cuando el script vuelve a recibir una respuesta exitosa tras el fallo, debe calcular la diferencia entre el tiempo actual y el "Timestamp" guardado de la última respuesta válida. 5. Imprimir en rojo una alerta: "⚠️ FALLO DE RED DETECTADO. Tiempo de inactividad (Gap): [X] milisegundos. ¿Soporta el MRP < 200ms? -> [PASS/FAIL]". Comenta el código explicando que esta simple resta de timestamps es exactamente la matemática que aplica Wireshark cuando cambiamos la vista a "Delta Time".