Una captura de tráfico con Wireshark muestra lo que realmente viaja por la red de la subestación: en GOOSE, el número de estado (stNum), el de secuencia (sqNum), el tiempo de vida (TAL), la revisión de configuración y el bit de simulación; en Sampled Values, el contador de muestras y la sincronización; en MMS, asociaciones, reportes y retransmisiones TCP. Comparada con el SCD, una captura distingue en minutos un problema de red de uno de configuración.
Qué se gana con una captura
Cuando un GOOSE no llega o llega tarde, un IED pierde la conexión MMS o el relé declara inválidos los valores muestreados, cada equipo da su propia versión de los hechos. La captura de tráfico es el árbitro: muestra qué tramas existen en un punto de la red, con qué contenido y a qué ritmo. Wireshark, el analizador de protocolos de código abierto más usado, trae decodificadores para los tres servicios de IEC 61850 que interesan en la subestación: GOOSE, Sampled Values (SV) y MMS.
GOOSE y SV viajan directamente sobre Ethernet, sin IP, con sus propios tipos de trama: 0x88B8 para GOOSE y 0x88BA para SV. MMS viaja sobre TCP/IP, en el puerto 102. Por eso una misma captura sirve para revisar el bus de estación completo, siempre que el punto de conexión vea el tráfico.
Dónde se conecta el analizador
El switch de subestación no reparte todo a todos. Con VLAN y filtrado de multicast, cada puerto recibe solo lo que necesita, y un portátil conectado en un puerto libre verá muy poco. Hay tres formas de llegar al tráfico:
| Punto de captura | Qué ve | Cuidado |
|---|---|---|
| Puerto espejo del switch | Copia del tráfico de los puertos o VLAN elegidos | Con carga alta el espejo puede descartar tramas; según el modelo, entrega o quita la etiqueta VLAN |
| TAP en el enlace de un IED | Todo lo que entra y sale de ese IED, sin alterar la red | Hay que intervenir el enlace para instalarlo |
| Puerto del propio IED suscriptor | Lo que realmente llega al relé | Solo es posible si el IED tiene un segundo puerto o una función de espejo |
En redes con redundancia hay un punto adicional. Con PRP, cada trama viaja duplicada por dos LAN independientes; para saber si una de ellas falla hay que capturar en las dos. Con HSR, las tramas llevan una etiqueta propia y circulan en ambos sentidos del anillo; el analizador se conecta normalmente detrás de una RedBox. La guía de PRP y HSR explica el mecanismo.
Qué revela una trama GOOSE
Cada mensaje GOOSE trae en su cabecera lo necesario para diagnosticar casi cualquier problema:
- gocbRef, datSet y goID: identifican el bloque de control, el conjunto de datos y el mensaje. Si no coinciden con lo que el suscriptor espera según el SCD, la trama se descarta aunque llegue.
- APPID, dirección MAC multicast y VLAN: la identidad en la capa de enlace. Un error aquí hace que el switch o el suscriptor filtren el mensaje.
- stNum: número de estado. Sube una unidad cada vez que cambia algún dato del conjunto.
- sqNum: número de secuencia. Avanza en cada repetición del mismo estado y vuelve a cero cuando cambia el estado.
- timeAllowedtoLive (TAL): el tiempo que el suscriptor debe esperar al siguiente mensaje antes de declarar la pérdida.
- confRev: revisión de la configuración del conjunto de datos. Debe coincidir en publicador y suscriptor.
- Bit de prueba o simulación: en la edición 1 era «test»; en la edición 2 indica que el mensaje es simulado, y solo lo aceptan los suscriptores que están en modo de simulación.
- ndsCom: indica que el bloque de control necesita comisionamiento, por ejemplo con un conjunto de datos vacío.
El detalle del mecanismo de repetición está en la guía de GOOSE.
Patrones que delatan cada problema
La utilidad de la captura está en reconocer patrones. Estos son los más frecuentes:
| Lo que muestra la captura | Lo que suele significar |
|---|---|
| El mensaje no aparece en el punto del suscriptor pero sí junto al publicador | La red lo filtra: VLAN no permitida en algún puerto o filtrado multicast mal configurado |
| El mensaje llega, pero el suscriptor lo rechaza | Diferencia en gocbRef, datSet, APPID, MAC o confRev frente al SCD, o bit de simulación activo |
| stNum sube continuamente sin eventos reales | Un dato del conjunto oscila: entrada que rebota, calidad inestable o analógico incluido por error |
| Dos secuencias de stNum y sqNum intercaladas con el mismo gocbRef | Dos publicadores con la misma identidad, típico tras copiar la configuración de un IED |
| Huecos en sqNum o intervalos mayores que el TAL | Pérdida de tramas: congestión, puerto espejo saturado o enlace con errores |
| Tramas sin etiqueta VLAN donde se esperaba una | Prioridad 802.1Q perdida; el tráfico crítico compite con todo lo demás |
Los dos últimos casos se cruzan con la configuración de VLAN y prioridad IEEE 802.1Q y con los problemas de tormenta de tráfico.
- ¿Aparece el mensaje en un puerto espejo o TAP junto al suscriptor?
- No¿Aparece junto al publicador?
- SíLa red lo filtra: revise VLAN y filtrado multicast en cada switch del camino
- NoEl publicador no lo emite: revise el bloque de control y su habilitación en el IED
- Sí¿Coinciden gocbRef, datSet, APPID, MAC y confRev con lo que el suscriptor espera según el SCD?
- NoError de configuración: corrija el SCD o el IED y vuelva a cargar
- SíRevise el bit de simulación, el modo del suscriptor y si el TAL vence entre mensajes
Sampled Values y MMS
Sampled Values. En el bus de proceso la captura muestra cada flujo de la merging unit con su identificador (svID), el contador de muestras (smpCnt), la indicación de sincronización (smpSynch) y la calidad de cada canal. Un smpCnt con saltos indica tramas perdidas; un smpSynch en cero indica que la merging unit perdió la referencia de tiempo. Ambos casos llevan al relé a bloquear sus funciones, como se describe en valores muestreados perdidos en el bus de proceso. El volumen también se ve: un flujo SV tiene miles de tramas por segundo, y la captura revela si un puerto recibe flujos que no le corresponden.
MMS. Aquí la captura es de TCP/IP: se ven la asociación entre cliente e IED, la lectura del modelo, la habilitación de reportes y los mandos. Los patrones típicos son retransmisiones TCP (pérdida o congestión), asociaciones rechazadas (límite de clientes del IED o parámetros de autenticación), conexiones que el cliente abre y cierra en bucle y reportes que llegan con desbordamiento de búfer. La guía de IEC 61850 MMS describe los servicios.
Límites de la captura
- El sello de tiempo es del portátil. No sirve para medir el tiempo de transferencia de un GOOSE con la exactitud que exige un disparo; para eso hay equipos con sello por hardware y tiempo común.
- El espejo no es neutral. Con mucho tráfico puede perder tramas propias y hacer creer que la red las pierde.
- La captura muestra la red, no la lógica. Si el GOOSE llega correcto y el relé no actúa, el problema está en la lógica o en el modo del IED.
- Con autenticación de IEC 62351 el contenido sigue visible, pero la validez de la firma no se comprueba sin las claves.
Para comparar lo capturado con lo diseñado, abra el SCD con nuestro visor SCL IEC 61850, una herramienta gratuita, y revise las direcciones esperadas de cada mensaje.
Cuándo pedir apoyo
Si la captura confirma que el problema es de configuración (identificadores, conjuntos de datos, VLAN o direcciones), la corrección está en el SCD y en los IED. En Tiza Group hacemos la ingeniería y configuración IEC 61850 de subestaciones de media, alta y extra alta tensión y de plantas industriales, incluida la revisión de tráfico en la puesta en servicio. Si el problema está en los ajustes o la lógica de un relé, lo resolvemos con la configuración remota de relés. Escríbanos con la marca y el modelo de sus equipos.
Guías relacionadas
- IEC 61850 GOOSE: cómo funciona, stNum, sqNum y pruebas
- GOOSE que no llega o llega tarde
- IEC 61850 Sampled Values
- IEC 61850 MMS
- Switch Ethernet de subestación
- Archivos SCL de IEC 61850
- VLAN y prioridad IEEE 802.1Q para GOOSE y SV
- Pruebas de la red de comunicaciones de una subestación
- Modo prueba IEC 61850: Mod, Beh, Sim y bit de prueba
- Comunicaciones de subestación por nivel de tensión
Referencias
- IEC 61850-8-1, Specific communication service mapping (SCSM) – Mappings to MMS and to ISO/IEC 8802-3 (GOOSE y MMS).
- IEC 61850-9-2, Specific communication service mapping (SCSM) – Sampled values over ISO/IEC 8802-3.
- IEC 61850-7-2, Basic information and communication structure – Abstract communication service interface (ACSI).
- IEC TR 61850-90-4:2020, Network engineering guidelines.
- IEC 62439-3, Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR).
- Documentación de Wireshark: decodificadores de GOOSE, SV y MMS (wireshark.org).
Preguntas frecuentes
¿Dónde conecto el portátil para capturar GOOSE en una subestación?
En un puerto espejo del switch que lleva el tráfico de interés o, mejor, con un TAP en el enlace del IED. Conectarse a un puerto cualquiera no sirve si el switch filtra el multicast por VLAN o por grupo: solo verá lo que ese puerto tiene permitido recibir.
¿Por qué el stNum de un GOOSE sube sin que haya ocurrido ningún evento?
Porque algún dato del conjunto publicado está cambiando. Suele ser una entrada binaria que rebota, una calidad que oscila o un valor analógico incluido por error en el conjunto de datos. La captura muestra cuál de los miembros cambia en cada incremento.
¿Puedo medir el tiempo de transferencia de un GOOSE con Wireshark?
Solo de forma aproximada. El sello de tiempo lo pone la tarjeta de red del portátil, que no está sincronizada con los IED y añade su propio retardo. Para medir el tiempo de transferencia se usan equipos de prueba con sello de tiempo por hardware y referencia común de tiempo.