GOOSE con PRP o HSR: supervise el disparo y la validez del mensaje

1. La redundancia es solo una frontera

Un enlace Ethernet sano no demuestra una orden de disparo utilizable. PRP y HSR mejoran disponibilidad, pero el publicador puede perder datos válidos, el suscriptor rechazar una configuración o el circuito de salida fallar. Especifique cada frontera. El alcance IEC 62439-3:2021 describe redundancia sin interrupción, sin prometer supervivencia ante cualquier fallo común. Primero defina el comportamiento de protección al perder comunicación. La guía de subestaciones digitales aporta el contexto arquitectónico.

2. Defina señales e independencia

Identifique publicador, conjunto de datos, bloque, revisión, direccionamiento, VLAN, tratamiento de calidad y supervisión de cada señal. Distinga disparo directo, permiso, bloqueo y enclavamiento: la pérdida tiene efectos diferentes. Documente fuentes, fibras, conmutadores y cajas de redundancia compartidos. Dos puertos en el mismo conmutador no son redes independientes. IEC 61850-8-1 referencia el mapeo; su página identifica la enmienda consolidada. Use texto normativo adquirido y documentación de implementación para aceptación; no invente cláusulas desde el resumen.

3. Presupuesto temporal ilustrativo

Suponga 20 ms desde la transición de entrada del publicador hasta la salida del suscriptor. Asigne 3 ms a publicar, 2 ms a tránsito, 4 ms a procesamiento y 3 ms a salida. La suma es 12 ms y deja 8 ms.

Son asignaciones ilustrativas, no especificaciones medidas ni límites IEC. Una reconvergencia adicional de 30 ms ya excede el presupuesto antes de recibir una retransmisión. No modele PRP/HSR como conmutación ordinaria con recuperación; pruebe la entrega real por el camino restante. La interrupción del interruptor pertenece al presupuesto total de despeje separado.

4. Seleccione topología y respuesta

PRP emplea redes separadas; HSR, rutas redundantes en su topología. Ninguno corrige la pérdida del IED origen. SEL muestra interacción desfavorable entre reconvergencia y retransmisión. Esto exige probar tiempos bajo fallo, no fijar demora universal.

5. Escriba la matriz causa-efecto

La desaparición de un bloqueo puede reducir seguridad; retenerlo indefinidamente puede reducir dependabilidad. Perder permiso suele retirarlo, pero no debe deshabilitar silenciosamente el respaldo local. No trate datos obsoletos de disparo directo como orden nueva salvo definición explícita de la aplicación. Acuerde la decisión con el responsable y demuestre el firmware real. Incluya reinicios, revisiones incompatibles, modos de prueba/simulación y retorno. Cada alarma necesita responsable y mensaje accionable, no solo diagnóstico oculto.

6. Pruebe fallos observables

Use entorno aislado o interrupción aprobada. Corte cada camino por turno y demuestre disparo correcto y ausencia de disparos indebidos. Repita con pérdida de alimentación del publicador, reinicio del suscriptor, tráfico de fondo y configuración de prueba incompatible. Capture entrada, estado transmitido, validez recibida y salida con base temporal común trazable. Solicite archivos, objetos de supervisión, configuración de conmutadores y planos. Documente descarte de duplicados cuando sea observable. Relacione la pérdida de comunicación con la revisión de falla de interruptor y teledisparo, incluida independencia del respaldo.

7. Preguntas prácticas

¿Recuperación cero significa latencia cero?

No. Describe la redundancia. Publicación, tránsito, procesamiento y salida siguen consumiendo tiempo.

¿La alarma PRP sustituye supervisión GOOSE?

No. Salud del camino y datos válidos son cuestiones distintas; documente ambas.

¿Perder GOOSE debe disparar siempre?

No hay respuesta universal. La función de la señal, el respaldo y la política operativa determinan la acción.

8. Fuentes primarias

• IEC 62439-3:2021
• IEC 61850-8-1
• SEL — Arc-Flash