Un GOOSE que no llega casi nunca es un problema del relé: lo descartan la red (VLAN, prioridad o filtrado multicast en los switches) o el suscriptor, que lo rechaza si no coincide con lo configurado (dirección, APPID, identificador, conjunto de datos o ConfRev) o si llega marcado como simulación o prueba sin que él esté en ese modo. Si llega tarde, el suscriptor declara la pérdida cuando vence el tiempo de vida (TAL) indicado en el propio mensaje.
Síntoma
Un disparo, un bloqueo o un permiso que viaja por GOOSE no llega al relé que debe recibirlo: la protección de barra no recibe el bloqueo, la 50BF no dispara la bahía vecina o el enclavamiento queda en estado desconocido. Otras veces el mensaje llega, pero tarde o de forma intermitente, y el suscriptor reporta pérdida de comunicación. Aparece sobre todo después de cambios de configuración, ampliaciones de la red o pruebas.
GOOSE (IEC 61850-8-1) viaja directamente sobre Ethernet como multicast de capa 2, sin IP. El publicador repite el mensaje periódicamente y, ante un cambio de estado, lo envía en ráfaga con intervalos crecientes. Cada mensaje dice cuánto esperar al siguiente: el tiempo de vida permitido (TAL). El suscriptor filtra y valida cada mensaje antes de usar sus datos.
Causas posibles, de la más a la menos probable
| Causa | Qué pasa | Cómo se ve |
|---|---|---|
| ConfRev u otro campo distinto de lo esperado | El publicador se reconfiguró y el suscriptor no se actualizó; APPID, identificador o dirección multicast diferentes | El mensaje está en la red; el suscriptor indica error de configuración o no indica nada |
| VLAN | El puerto del switch no pertenece a la VLAN del GOOSE, o la etiqueta se quita o se cambia entre switches | El mensaje existe en un tramo de la red y no en otro |
| Filtrado multicast en los switches | Filtros estáticos incompletos, o el switch descarta multicast no registrado | El GOOSE no aparece en el puerto del suscriptor |
| Simulación o modo de prueba | El mensaje sale con el indicador de simulación, o el publicador está en modo de prueba y su calidad marca «test»; el suscriptor en servicio normal no lo usa | Llega, pero no actúa; coincide con pruebas recientes |
| Calidad no válida | El dato publicado tiene calidad no válida o cuestionable | El suscriptor recibe y descarta el valor |
| Prioridad y congestión | Sin prioridad 802.1Q, el GOOSE compite con tráfico masivo (valores muestreados, MMS, video) | Retardos variables, más con carga de red |
| Bucles y reconfiguración de la red | Tormenta de difusión o reconvergencia de RSTP después de una falla de enlace | Pérdida temporal de todos los GOOSE de un segmento |
| TAL inadecuado | Tiempo de vida muy corto frente al tiempo de repetición real | Alarmas de pérdida intermitente sin falla de red |
| Necesita puesta en servicio (NdsCom) | El bloque de control indica que su configuración está incompleta | Analizadores y suscriptores marcan el flujo como error |
Qué revisar primero
- Diagnóstico del suscriptor. La mayoría de los IED muestran por cada suscripción si recibe, si hay error de configuración, de ConfRev o de calidad, y si el TAL venció. Empiece ahí.
- Captura de red en el puerto del suscriptor (puerto espejo o analizador IEC 61850): ¿llega el mensaje? Si llega, el problema es de suscripción o de modo; si no, de red.
- Comparación campo por campo entre el mensaje capturado y la configuración del suscriptor: dirección MAC de destino, VLAN y prioridad, APPID, identificador, referencia del bloque de control, conjunto de datos y ConfRev. Contraste ambos con el archivo SCD vigente; ver archivos SCL.
- Indicador de simulación y modo del publicador. Revise si quedó en simulación o en modo de prueba después de una intervención, y en qué modo está el suscriptor.
- Switches: pertenencia de puertos a la VLAN, tratamiento de la etiqueta, filtros multicast y colas de prioridad. Ver VLAN y prioridad IEEE 802.1Q y el switch Ethernet de subestación.
- Registro de eventos de la red: caídas de enlace, cambios de topología RSTP o PRP/HSR en el momento del problema.
- ¿La captura en el puerto del suscriptor muestra el mensaje?
- NoProblema de red: VLAN, filtros multicast, bucles o reconvergencia RSTP
- Sí¿Qué indica el diagnóstico del suscriptor?
- Error de configuraciónCampo distinto del SCD: MAC de destino, APPID, identificador, conjunto de datos o ConfRev
- Recibe pero no actúaIndicador de simulación, modo de prueba o calidad no válida
- Pérdida intermitenteTAL corto frente a la repetición real, o congestión sin prioridad 802.1Q
Cómo se confirma
- Con la captura: el mensaje está presente o no en cada tramo; el número de estado (stNum) cambia con el evento y el número de secuencia (sqNum) avanza sin huecos en las repeticiones.
- Con medición de tiempos: se compara la estampa de tiempo del cambio de estado en el publicador con la recepción y la actuación del suscriptor. IEC 61850-5 clasifica los tiempos de transferencia exigidos por tipo de mensaje; para disparos la exigencia es de pocos milisegundos.
- Con una prueba de extremo a extremo: un equipo de prueba con suscripción y publicación GOOSE simula el evento y mide el tiempo hasta el contacto de disparo del suscriptor. Ver las pruebas end to end.
- Con la reconfiguración corregida: al alinear el ConfRev o el campo errado con el SCD, la suscripción debe pasar a válida de inmediato.
Cómo evitar que se repita
- Gestione el SCD como única fuente de verdad: cada cambio en un publicador se descarga en todos sus suscriptores desde el mismo archivo.
- Supervise cada suscripción crítica con una alarma de pérdida que llegue al SCADA y defina el valor seguro de cada señal recibida.
- Documente la red: VLAN, prioridad, filtros multicast y puertos por IED, y verifíquelos en la puesta en servicio con capturas.
- Cierre cada intervención verificando el modo de cada IED (servicio, prueba, simulación) y registrándolo.
Qué no hacer
- No editar la configuración de un solo IED para «que coincida» sin actualizar el SCD: el próximo cambio reintroduce el error en otro equipo.
- No dejar equipos en simulación o en modo de prueba al terminar una intervención; registre el modo de cada IED en el acta de cierre.
- No desactivar la validación de calidad o de ConfRev en el suscriptor para que funcione.
- No asumir que el GOOSE es tan seguro como un cable sin supervisión: cada señal crítica necesita alarma de pérdida y un valor seguro definido.
Cuándo llamarnos
Si un GOOSE no llega o llega tarde, nuestro equipo revisa en remoto el SCD, la configuración de publicadores y suscriptores y los diagnósticos de los IED de las principales marcas, y le indica qué campo, qué switch o qué modo lo está descartando. Conozca la configuración remota de relés y nuestra ingeniería IEC 61850. Para medir tiempos y validar la lógica en sitio, hacemos pruebas de protecciones. Escríbanos.
Guías relacionadas
- Diagnóstico de disparos de protección: método
- Alarma de tierra en corriente continua
- IEC 61850 GOOSE
- Archivos SCL IEC 61850
- VLAN y prioridad IEEE 802.1Q
- RSTP y redundancia Ethernet
- PRP y HSR (IEC 62439-3)
Referencias
- IEC 61850-8-1, mapeo a MMS y a ISO/IEC 8802-3 (GOOSE).
- IEC 61850-7-2, interfaz abstracta de servicios de comunicación (bloque de control GOOSE, ConfRev).
- IEC 61850-5, requisitos de comunicación y clases de tiempo de transferencia.
- IEC 61850-7-4, modelo de nodos lógicos (modo, comportamiento y simulación en LPHD).
- IEEE 802.1Q, VLAN y prioridad.
Preguntas frecuentes
¿Por qué el relé suscriptor no recibe el GOOSE si lo veo en la red?
Porque el suscriptor compara cada mensaje con lo que tiene configurado: dirección multicast, APPID, identificador del GOOSE, referencia del bloque de control, conjunto de datos y ConfRev. Si un solo campo no coincide, o si el mensaje viene con el indicador de simulación y el suscriptor no está en modo simulación, lo descarta aunque esté en el cable.
¿Qué es el ConfRev y por qué rompe la suscripción?
Es la revisión de configuración del bloque de control GOOSE. Cambia cuando se agregan, quitan o reordenan miembros del conjunto de datos. Si el publicador se reconfiguró y el suscriptor sigue esperando el valor anterior, rechaza los mensajes hasta que se actualice su configuración.
¿Qué pasa cuando vence el tiempo de vida (TAL) de un GOOSE?
El suscriptor da por perdida la comunicación con ese publicador y marca los datos como no válidos; según la configuración, las señales recibidas pasan a un valor por defecto o mantienen el último. Por eso un disparo o un bloqueo por GOOSE debe tener definido su comportamiento ante pérdida del mensaje.