Caso mágico #4: simulador de servidor MMS — sé el dispositivo, prueba el SCADA

Una ejecución de Tekvel Magic — y el dispositivo elegido del SCL cobra vida: se inicia un servidor MMS a partir de su modelo de datos y se abre un panel de control en el navegador. Cambias los valores y la calidad de las señales — y el cliente de nivel superior recibe informes dchg/qchg reales, exactamente como de un IED real. El módulo funciona sin un solo dispositivo físico en el banco: basta un archivo SCL.

En los artículos anteriores de la serie mostramos cómo Tekvel Magic compara la configuración de un SCD con la configuración real del IED, cómo, con un clic, captura el estado actual de los bloques de control de informes por MMS y cómo convierte una configuración SCL en un formulario legible de transferencia de teleinformación. Hoy — el cuarto caso, que aborda la tarea desde el otro lado de la mesa. Hasta ahora Magic trabajaba con lo que ya existe: archivos y dispositivos activos. Ahora se convierte en el propio dispositivo — para probar a quien recibe esos informes.

Por qué emular un dispositivo

La transferencia de teleinformación por IEC 61850 siempre tiene dos lados: el dispositivo servidor (un IED de protección, un controlador de bahía, un transductor de medida) que genera los informes por MMS, y el cliente de nivel superior (un servidor de telecontrol, el SCADA) que se suscribe a esos informes y los muestra al operador. El primer lado suele probarse a fondo en el proyecto. En cambio, el lado receptor — cómo exactamente el nivel superior recibe, interpreta y muestra los informes — es mucho más difícil de probar.

La razón es simple: para probar el cliente con honestidad hace falta un servidor en funcionamiento que entregue los datos correctos en el momento correcto. Y ahí empiezan las dificultades:

• Algunos dispositivos aún no están en la instalación o no están del todo puestos en marcha. La configuración y la aceptación del nivel superior a menudo corren en paralelo con la configuración — o incluso el suministro — de algunos dispositivos, y a veces por delante. No hay contra qué probar el nivel superior.
• El dispositivo está, pero no se consigue sacarle el estado necesario. ¿Cómo obligar a un terminal real a emitir bad-state para la posición de un interruptor, calidad questionable o la bandera test — y encima en una secuencia controlada? En un dispositivo en servicio esto es imposible o inseguro (por ejemplo, porque las bahías de la instalación ya están en operación).
• Hay que reproducir un escenario raro. Pérdida y recuperación de la validez, sustitución de valores — tales situaciones sencillamente no se crean en una instalación real.

Como resultado, la aceptación del nivel superior a menudo se convierte en observar lo que por casualidad llegó de la red, en lugar de una prueba dirigida. El módulo de Tekvel Magic que se presenta aquí cierra esa brecha: inicia un servidor MMS directamente desde un archivo SCL y ofrece un panel cómodo desde el cual el ingeniero controla los valores y la calidad de las señales — y observa cómo reacciona el cliente.

Lugar en la serie de escenarios de prueba del SCADA: leer, mostrar, documentar — y jugar como el dispositivo

Para no confundir tareas próximas, conviene tener presente la división en toda la serie de escenarios de prueba relacionados con el SCADA:

• Caso #1 — conformidad: compara el SCD de proyecto con la configuración real de los dispositivos por MMS y emite un informe de discrepancias.
• Caso #2 — estado: se conecta a los dispositivos por MMS y muestra cómo funcionan los informes ahora (RptEna, Owner, quién está suscrito a qué).
• Caso #3 — documentación: toma la configuración SCL y la convierte en un formulario legible de transferencia de teleinformación, offline.
• Caso #4 — emulación (este): toma la configuración SCL y se convierte en el dispositivo que describe, generando informes reales para probar el lado receptor.

La diferencia clave del cuarto caso es que es activo. Los tres primeros trabajan con lo que ya existe: leen, comparan, muestran, documentan. Aquí, por primera vez, Magic no observa el tráfico, sino que lo crea — actúa como servidor IEC 61850 y hace el papel de un dispositivo que puede que ni siquiera esté todavía en la instalación, o que puede no estar configurado. Esto desplaza el foco de la prueba del dispositivo al nivel superior: no «¿está el IED bien configurado?», sino «¿recibe y muestra los datos correctamente quien está por encima?».

Cómo funciona

El escenario es lo más corto posible. Lanzas el módulo — y en el primer diálogo seleccionas un archivo SCL: puede ser un CID/ICD aparte con un único dispositivo o un SCD de subestación con varias decenas de IEDs. Si hay varios dispositivos en el archivo, el módulo propone elegir uno — el que va a «representar».

A partir de ahí todo ocurre automáticamente: el módulo inicia un servidor MMS a partir del modelo de datos del dispositivo seleccionado y abre un panel de control en el navegador. Desde ese momento, para cualquier cliente de nivel superior en la red el simulador es indistinguible de un IED real: tiene el mismo modelo de datos, los mismos bloques de control de informes, los mismos conjuntos de datos y la dirección del SCL.

Todo el recorrido se sigue mejor con un diagrama de bloques — desde la elección del archivo hasta el flujo de informes al nivel superior:

flowchart TB
    A["Iniciar el módulo"]
    F["Seleccionar un archivo SCL<br/><i>CID / ICD / SCD</i>"]
    S["Seleccionar un dispositivo<br/><i>si el archivo tiene varios IEDs</i>"]
    P["Comprobar: ¿hay RCB<br/>con conjuntos de datos?"]
    B["Iniciar el servidor MMS<br/><i>modelo del IED seleccionado</i>"]
    C["Cliente interno<br/><i>readback + sondeo en segundo plano</i>"]
    W["Panel web<br/><i>se abre en el navegador</i>"]

    A --> F --> S --> P --> B
    B --> C
    B --> W
    W ==> ACT

    subgraph ACT["Acciones del ingeniero en el panel"]
        direction TB
        V["Cambiar valores de las señales"]
        Q["Cambiar la calidad (validity / test / source)"]
        AC["Barrido automático de valores y calidad"]
        V --> RPT
        Q --> RPT
        AC --> RPT
        RPT["Informes dchg / qchg por MMS"]
    end

    ACT ==> EXT["<b>CLIENTE DE NIVEL SUPERIOR</b><br/>SCADA / gateway / despacho —<br/>recibe y muestra los informes"]

    style A fill:#F3F3F3,stroke:#888
    style F fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style S fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style P fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style B fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style W fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style V fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style Q fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style AC fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style RPT fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style EXT fill:#E8F5E9,stroke:#43A047,color:#1B5E20

Conviene destacar aparte el tratamiento de un SCD de subestación. Según IEC 61850-6, ese archivo describe decenas de dispositivos en un único modelo — y no se puede iniciar directamente de él un servidor para un único IED. El módulo lo resuelve solo: extrae el dispositivo seleccionado a un archivo temporal de un único dispositivo, gestionando con cuidado los puntos de acceso (incluida la construcción ServerAt, cuando un punto referencia el servidor de otro). El ingeniero no tiene que pensar en esto — basta con indicar el nombre del dispositivo.

Un punto más — Tekvel Magic puede exponer el dispositivo simulado en su dirección IP extraída del archivo SCL. Eso también es importante.

Qué puede hacer el panel de control

El panel se abre en un navegador normal y se actualiza en tiempo real. Dentro — varios bloques coordinados.

Estado de los bloques de control de informes expuestos por el dispositivo simulado. Una tabla de todos los bloques — bufferizados (BRCB) y no bufferizados (URCB) — con su estado en vivo: RptEna, SqNum, EntryID, Owner, la bandera de interrogación general (GI), la hora del último evento, el conjunto de datos, los disparadores activos (TrgOps) y los campos opcionales (OptFlds). Se ve qué cliente se suscribió a qué bloque y qué está realmente activado.

Control de valores. Las señales se agrupan por conjunto de datos. Para cada objeto de datos el panel elige por sí mismo la entrada cómoda: una lista desplegable para señales discretas (posición del interruptor — off/on/intermediate/bad-state), un campo numérico para medidas. Las magnitudes multifásicas (WYE/DEL/SEQ) se escriben en todas las fases a la vez. Cada escritura se verifica por readback — lo que ves en el panel ha ido con seguridad al modelo y al informe.

Control de calidad. Un formulario aparte para cada señal: validity (good / invalid / questionable), las banderas test y operatorBlocked, la fuente process/substituted. Cualquier cambio de calidad genera un informe qchg — justo lo que se necesita para comprobar cómo el nivel superior muestra la invalidez y los datos de prueba.

Historial de cambios y registro de operaciones. Cada cambio de valor o de calidad se registra en un historial cronológico — con el valor actual, la calidad actual y una marca de tiempo. Se lleva un registro aparte de las acciones del operador. No se pierde nada, incluso si los cambios llegan más rápido de lo que se actualiza la página.

Barrido automático — prueba masiva de escenarios en un clic

La conmutación manual es buena para comprobaciones puntuales, pero cuando hay que pasar una señal por todos sus estados — o probar de una vez un conjunto de datos entero — entra en escena el barrido automático. Marcas las señales, fijas el intervalo y el número de ciclos — y el módulo recorre cíclicamente todos los valores con sentido de cada señal según su tipo (CDC):

• discretas (DPC/DPS): off → on → intermediate → bad-state;
• únicas (SPC/SPS/ACT): false → true;
• enumeradas y enteras (INS/ENS): por una serie de valores;
• medidas (MV/CMV/WYE/DEL/SEQ): por una serie de valores.

Con la opción «+ calidad» activada, tras cada valor se puede además recorrer una secuencia de estados de validez: invalid → questionable → good+test → good+operatorBlocked → good+substituted → y de vuelta a good. Así, en una sola ejecución el nivel superior recibe el espectro completo de combinaciones «valor × calidad» — ideal para comprobar la visualización de todos los estados de una vez. El barrido se puede pausar o detener; al detenerlo, la calidad de todas las señales se devuelve con cuidado a good para que el modelo no quede en un estado «corrupto».

Para qué sirve — en la práctica

El principal valor es la posibilidad de probar el nivel superior cuando conviene, y no cuando se «tiene suerte» con el tráfico de dispositivos reales.

Poner en marcha el nivel superior con antelación. Los dispositivos aún están en camino, pero el servidor de telecontrol o el servidor SCADA ya hay que configurarlo y probarlo. El simulador, construido a partir del SCD de proyecto, representa al futuro dispositivo — el mapeo de señales, las suscripciones a informes y la visualización se pueden depurar de antemano.

El nivel superior se implanta cuando los armarios ya están en operación. Situación frecuente: los armarios de protección y SCADA de una bahía llevan mucho tiempo en servicio, mientras que la ampliación o modernización del nivel superior (un nuevo servidor SCADA, un gateway, un centro de despacho) se hace después. Ya no se pueden iniciar cambios de señales en los dispositivos en servicio para probar la recepción en el nivel superior — el equipo está bajo carga, e interferir en su operación es inadmisible. El simulador elimina esa limitación: actúa como «suplente» del dispositivo en operación usando la propia configuración SCL de este, y todos los cambios necesarios — posiciones, medidas, calidad — se inician desde él, sin tocar los armarios reales en operación.

Probar la visualización de calidad y datos de prueba. ¿Cómo verá el operador una señal con calidad invalid? ¿Filtrará el nivel superior los datos con la bandera test? El simulador permite fijar cualquier combinación de bits de calidad y observar la reacción — algo prácticamente imposible de reproducir en un dispositivo en servicio.

Reproducir escenarios raros e «incómodos». Una posición intermedia del interruptor, la pérdida de la validez y su restablecimiento, una serie de cambios rápidos — todo esto se fija desde el panel o se ejecuta con el barrido automático en una secuencia controlada.

Formación y demostración. El simulador es un banco visual para formar al personal en el trabajo con informes IEC 61850 y para demostrar cómo se ve la transferencia de teleinformación «en movimiento».

Junto con los casos anteriores, se forma un buen conjunto de escenarios de prueba para un ingeniero de SCADA moderno. El caso #1 comprueba que el dispositivo está configurado según el proyecto; el caso #2 muestra cómo funcionan los informes ahora; el caso #3 produce documentación legible; y el caso #4 permite jugar como el dispositivo y asegurarse de que el nivel superior recibe y muestra todo correctamente. «Cómo está configurado», «cómo funciona ahora», «cómo explicarlo a los demás» — y, por fin, «cómo se recibirá en el otro extremo».

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