En un artículo anterior cubrimos el caso en el que Tekvel Magic compara la configuración de los conjuntos de datos, los informes y los bloques de control de transmisión de GOOSE y Sampled Values descritos en un archivo SCL con la configuración real de los IEDs. Hoy — otro caso: cómo, con un solo clic, obtener una instantánea del estado actual de los bloques de control de transmisión de informes (URCB / BRCB) a la vez en varios dispositivos.

Por qué conviene mirar hacia los RCB

Los bloques de control de transmisión de informes son un «contrato» entre el servidor (el IED) y los clientes (SCADA, pasarelas, PLCs de nivel superior, herramientas de diagnóstico). El servidor publica datos a través de bloques de control bufferizados (BRCB) y no bufferizados (URCB); el cliente reserva el bloque que necesita, lo activa (RptEna = true) y empieza a recibir eventos por cambio de datos, cambio de calidad o de forma periódica (o bajo demanda). En una instalación real estos bloques suelen estar configurados en los dispositivos, pero quién los utiliza realmente cuando la instalación está ya en explotación es otra cuestión.

Hay además casos francamente desagradables: los informes en los dispositivos no los tiene reservados nadie, mientras el cliente de nivel superior, en lugar de suscribirse a los eventos, recorre todos los servidores con un polling periódico de toda la vida. «Todo parece funcionar», pero el modelo orientado a eventos de la IEC 61850 — precisamente aquel por el que se emprendió la transición a la subestación digital — está, de hecho, desactivado. Aumenta la carga sobre la red, se pierde el determinismo de la respuesta, los eventos se «pegan» por el periodo de polling, y el hecho de que los informes no se usen puede pasar desapercibido durante años — hasta que llega el análisis de un incidente. Una sola ejecución de la auditoría revela ese estado al instante.

¿Qué bloques están activados ahora mismo en los dispositivos de la subestación? ¿Qué clientes los han reservado? ¿Qué disparadores (TrgOps) y campos opcionales (OptFlds) tienen configurados? ¿Qué conjuntos de datos están enlazados a ellos y cuál es su composición? ¿Cuáles son los valores de BufTm e IntgPd, y son coherentes con lo que se esperaba ver en la documentación de proyecto? Estas preguntas surgen con regularidad en la aceptación de la instalación: los representantes técnicos del cliente final necesitan asegurarse de que los informes funcionan realmente y se usan realmente — y no están «configurados y abandonados». Antes esa instantánea se montaba a mano: poco a poco, con un navegador del modelo de datos, anotaciones en papel y conversaciones con el integrador. Ahora lo mismo se obtiene de una sola ejecución.

Cómo funciona

El escenario es el habitual. Está usted en la instalación, con un portátil con Tekvel Magic conectado a la red de la subestación, y el archivo SCD del proyecto a mano. Lanza la prueba — y en el primer cuadro de diálogo el software ya pregunta cómo quiere identificar el dispositivo:

  • introducir la dirección IP del dispositivo manualmente (cuando el SCD aún no está disponible o se está verificando un punto concreto), o
  • elegir el dispositivo a partir del archivo SCD — en el diálogo aparece una lista de IEDs con sus nombres y el atributo desc (descripciones), con posibilidad de selección individual o múltiple.

En el segundo caso, Tekvel Magic extrae automáticamente las direcciones IP de los dispositivos seleccionados de la sección Communication (ConnectedAP / Address / P type="IP") y se conecta a cada uno por MMS. Es decir, con un solo clic puede usted auditar el uso de los informes en, por ejemplo, ocho dispositivos seguidos — y recibirá un documento separado por cada uno.

Establecida la asociación MMS, el software lee el modelo de datos completo del dispositivo, encuentra todos los bloques URCB y BRCB y consulta sus atributos — RptID, RptEna, DatSet, ConfRev, OptFlds, BufTm, SqNum, TrgOps, IntgPd, GI, Resv, Owner (para URCB), más PurgeBuf, EntryID, TimeOfEntry, ResvTms (para BRCB). En paralelo, Tekvel Magic recopila la composición de cada conjunto de datos. El resultado es un protocolo en MS Word.

Qué hay dentro del protocolo

Al abrir el documento se ve un índice generado automáticamente y tres secciones principales: parámetros de conexión, tabla-resumen de bloques e información detallada para cada uno de ellos.

La tabla-resumen contiene una fila por cada RCB. Para cada bloque se indican:

  • la referencia al bloque en el modelo de información del dispositivo (por ejemplo, IEDName/LLN0$BR$Report01);
  • el tipo de bloque — bufferizado (B) o no bufferizado (NB);
  • el estado: RptEna = ENC / DES;
  • Owner — la dirección IP del cliente propietario, si el bloque está reservado y el servidor expone esa información. Decodificamos Owner desde la OCTET STRING «en crudo» a una forma legible 192.168.0.42:5001; si el bloque está realmente libre, la celda muestra un guion;
  • el conjunto de disparadores activados (dchg, qchg, dupd, integrity, GI) y de campos opcionales (SeqNum, TimeStamp, ReasonCode, DataSet, DataRef, BufOvfl, EntryID, ConfRev);
  • la referencia al conjunto de datos utilizado, el tiempo de búfer BufTm y el periodo de integración IntgPd.

Solo con esta tabla, en la aceptación, ya se ve lo principal: qué informes están configurados, cuáles de ellos ha reservado realmente alguien y si hay bloques «colgados en el aire» con el conjunto de disparadores vacío.

Protocolo Word de Tekvel Magic: parámetros de conexión y tabla-resumen de bloques URCB/BRCB
Fig. 1. Fragmento del protocolo Word de Tekvel Magic: parámetros de conexión y tabla-resumen de los bloques URCB/BRCB. El estado RptEna y la columna Owner están resaltados con color; los disparadores y los campos opcionales se muestran en columnas separadas.

A continuación — información detallada para cada bloque. Aquí aparece la lista completa de atributos con descripciones, subsecciones separadas con la decodificación de los campos de bits TrgOps y OptFlds (un bit por línea — qué está activado y qué no), los parámetros temporales con explicaciones del significado de cada valor y, por último, la composición elemento a elemento del DataSet, distribuida en las columnas LD / LN / DO / DA / FC. Si en la conexión se ha seleccionado un archivo SCD, a cada FCDA se le asocia adicionalmente una descripción textual (atributo desc) — extraída directamente del SCL por el DOI correspondiente. En la práctica esto es invaluable: en lugar del abstracto «MMXU1.A.phsA.cVal.mag.f» se ve enseguida «Corriente de la fase A, entrada nº 1» — y el sentido de cada informe se capta en segundos.

Protocolo Word de Tekvel Magic: información detallada sobre un bloque URCB
Fig. 2. Sección detallada del protocolo para un único URCB: atributos principales, decodificación de los disparadores TrgOps y de los campos opcionales OptFlds, con el estado de cada bit.

El documento se monta con índice y numeración automática de secciones.

Para qué sirve esto — en la práctica

En conjunto con el módulo de comparación de configuración presentado anteriormente (en el que los informes del archivo SCD se cotejan con la configuración real de los IEDs), este módulo cierra la segunda mitad de las preguntas típicas del SCADA: «cómo está configurado» se complementa con el hecho «cómo está funcionando ahora». En la puesta en marcha, esto reduce el tiempo dedicado a investigar «por qué no llegan los eventos»; en la aceptación, proporciona a la comisión un artefacto fácilmente verificable; en explotación, permite captar periódicamente en minutos la imagen «quién está suscrito a qué» en todo el parque de dispositivos. Y en los casos particularmente desagradables ayuda a detectar lo principal: que el modelo orientado a eventos de la IEC 61850 está formalmente configurado en la instalación, pero en la práctica no se utiliza. Una ejecución, un protocolo, una conversación con el contratista — en lugar de decenas de correos y hojas de cálculo improvisadas.

¡Que lo disfrutes! A veces la ingeniería de la IEC 61850 exige un poco de Magia :)