El archivo antes que el tablero: qué se prueba de verdad en una subestación digital.

Cuando se comisiona una subestación convencional, el trabajo de verificación tiene una forma conocida: alguien recorre los planos funcionales con un destacador y va marcando en verde cada interfaz comprobada, cable por cable. Es lento: una persona con el plano subrayado y el tester en la mano, borne por borne. Y funciona. En una subestación digital buena parte de ese recorrido no tiene dónde apoyarse. La señal que antes viajaba por un par de cobre dedicado ahora es, en varios tramos, un mensaje que comparte la red con otros cien, y para saber por dónde pasa hay que abrir un archivo XML.

Christian Brauner y Eugenio Carvalheira, de OMICRON, publicaron en PAC World a comienzos de 2021 un artículo que puso el dedo en la llaga: probar la automatización, las comunicaciones y las señales a SCADA toma hoy más tiempo que probar las funciones de protección. Las protecciones tienen oficio, herramientas y rutinas reutilizables; la automatización sigue siendo, en gran medida, trabajo manual de varias semanas con varios ingenieros. Su propuesta fue usar el archivo SCD como base de las pruebas: si el archivo describe los IEDs, las señales y los enlaces, una herramienta que lo lea puede verificar automáticamente lo que antes se marcaba a mano.

Cinco años y medio después esa idea ya se usa. El lío de ahora es otro: el archivo llega a la fábrica sin que nadie lo haya revisado, y ninguna automatización rescata un modelo mal construido. Sobre eso trata este artículo: qué se prueba realmente en una subestación digital, en qué orden, y qué queda afuera de cada etapa.

Esta primera parte se queda en el archivo: qué acredita un certificado, qué se le puede exigir al modelo antes de que exista un tablero, y un detalle de las clases de desempeño que conviene mirar antes de firmar una especificación. La segunda baja al patio.

Cuatro cosas distintas que llamamos «probar»

En una reunión de licitación, la palabra prueba aparece cada cinco minutos y casi nunca significa lo mismo. Son cuatro cosas distintas: cada una manda a una norma distinta y deja afuera cosas distintas.

Las cuatro se complementan y ninguna reemplaza a la otra; qué cubre cada una en un proyecto concreto depende del plan de pruebas y de los criterios de aceptación que se hayan escrito. En licitación todavía se pide el certificado y listo.

Qué acredita de verdad un certificado de conformidad

La parte 10 de la serie define el ensayo de conformidad: cómo se comprueba que un IED implementa correctamente los servicios de comunicación y el modelo de datos de la norma. El fabricante entrega cuatro documentos que se leen juntos: el PICS, que declara qué servicios soporta; el MICS, que describe el modelo de datos implementado; el PIXIT, que detalla las decisiones de implementación que la norma deja abiertas —tiempos de espera, comportamiento ante reconexión, límites de suscripciones—; y el TICS, que dice qué correcciones técnicas de la norma trae ese equipo. El laboratorio ensaya contra esa declaración, y el certificado cubre lo declarado y ensayado, no cualquier combinación posible.

Con ese certificado uno sabe que el IED puede hablar 61850. El proyecto todavía no empezó a probarse, y la propia parte 10 lo dice en su cláusula 5.

«Los ensayos de tipo y los ensayos de conformidad no garantizan por completo que se cumplan todos los requisitos funcionales y de desempeño. [...] El ensayo de conformidad no reemplaza las pruebas específicas del proyecto relacionadas con el sistema, como el FAT y el SAT.»

El mismo apartado es todavía más directo sobre el límite: «una norma de comunicación no normaliza las funciones del equipo que se comunica; por lo tanto, los modos de falla de las funciones quedan fuera del alcance». Y la parte 1, la introductoria de toda la serie, cierra su apartado sobre ensayos reconociendo que «el desarrollo posterior de los métodos de prueba cubrirá las pruebas de herramientas, de interoperabilidad y funcionales». La parte 10 avisa que el FAT y el SAT no vienen incluidos.

Con el certificado uno sabe que el stack 61850 del equipo pasó el ensayo. El enclavamiento puede estar mal escrito igual, al dataset puede faltarle la señal que el esquema necesita, y dos equipos certificados de fabricantes distintos pueden no entenderse en la configuración concreta que alguien les cargó.

El dato que mejor lo ilustra no sale de un caso aislado. En el plugfest de interoperabilidad de UCA International Users Group de 2019, de 159 archivos ICD entregados por los fabricantes, 10 pasaron la validación SCL sin errores —esquema y reglas semánticas de la parte 6—, y apenas 5 de esos 10 la pasaron con más de una herramienta. Los protocolos se entendieron mucho mejor que los archivos de configuración generados por las herramientas de cada fabricante. Era una campaña de ensayo, con equipos que no tenían por qué estar certificados ni liberados comercialmente, así que la cifra no se traslada tal cual al parque instalado; pero marca dónde estaba —y sigue estando— el trabajo. Ese contraste, que ya comentamos cuando escribimos sobre la red de la subestación digital, es el punto de partida de todo lo que sigue.

El archivo también es un objeto bajo prueba

El artículo de 2021 ya apunta en esta dirección: propone que en la fase de especificación se validen el archivo, las señales y los servicios de comunicación sin necesidad de ningún equipo físico. Lo que verifica ahí es la coherencia del sistema descrito —que las señales estén, que los enlaces cierren— usando el archivo como espejo. Lo que todavía no podía hacer es someter el archivo a las reglas de la propia norma, porque esas reglas se normalizaron después.

El lenguaje SCL se describe con un esquema XSD. Un XSD verifica la estructura y algunas restricciones de referencia, pero el esquema de SCL no alcanza a expresar todo lo que la norma exige: que cada suscripción apunte a un dato que realmente existe, que las direcciones no se repitan donde no deben, que las referencias cruzadas entre secciones cierren. Esa capa se venía cubriendo con reglas escritas en OCL, y en julio de 2025 la IEC publicó la TS 61850-6-3, que normaliza el formato de esas reglas procesables por máquina. Lo que normaliza es el formato y el método; el conjunto de reglas de cada parte se publica aparte, y qué tan completo sea el juego que aplica un validador depende de ese validador. Hay validadores libres que las implementan. El de referencia lo mantienen CentraleSupélec y EDF —es el que usa el ecosistema CoMPAS—, y los resultados que damos más abajo salen de su versión 1.3.0, con el esquema 2007B4 y sus 213 reglas semánticas. Ya no corre la excusa de que el archivo no se podía revisar.

Lo pusimos a trabajar sobre archivos reales. El caso que más nos interesó fue el de una subestación chilena en servicio, cuyo SCD revisamos este año a pedido del cliente: 260 hallazgos, con la mitad larga explicada por avisos repetidos que genera la herramienta de configuración de uno de los fabricantes y que no afectan al sistema. Los que pesan son tres, y están en el archivo maestro, no en los equipos. Primero, una red de estación única que quedó partida en tantas subredes como equipos; la norma no obliga a declarar una sola, pero acá la fragmentación no corresponde a la arquitectura real y además deja tapada una dirección IP repetida. Segundo, referencias rotas dentro del propio archivo, arrastradas desde la exportación. Y tercero, la sección de topología primaria: 22 interruptores y desconectadores sin terminales ni nodos de conexión, una lista de equipos agrupados por paño en vez de un unifilar conectado.

Ninguno de los tres impide que los equipos operen, y así quedó escrito en el informe que entregamos, con la línea exacta de cada hallazgo y qué pedirle al integrador. Importan para lo que venga después: cualquier ampliación, cualquier reemplazo de IED y cualquier prueba que quiera apoyarse en ese archivo arranca desde ahí. Lo que falta para poder decir que el archivo está bien es contrastarlo contra los equipos vivos.

Para tener referencias a los lados:

• Un SCD público de terceros, usado como caso de prueba en un repositorio abierto, arroja 322 hallazgos, entre ellos la misma dirección MAC multicast declarada para un mensaje GOOSE y para un flujo de valores muestreados. El Ethertype los separa, así que no hay choque garantizado, pero es una anomalía de direccionamiento y hay que ir a la red real a ver qué pasa.
• El SSD que genera nuestro motor a partir del unilineal pasa el esquema y arroja 4 errores semánticos, que son los huecos que el propio archivo declara en su bloque de pendientes: tres desconectadores con un solo terminal y un pararrayos sin terminal.

Ese último punto merece detenerse. El artículo de OMICRON recomienda a los dueños de activos exigir en las bases que el SCD traiga la sección Substation completa, con los interruptores y desconectadores y sus nodos lógicos XCBR, XSWI, CSWI y CILO, porque de ahí sale la correspondencia entre lo que hay en el patio y cada instancia del modelo. La recomendación es correcta, y el archivo que teníamos sobre la mesa no la cumple. Buena parte de lo que se apoya en las secciones de IEDs y de comunicaciones —ver los enlaces, simular equipos, leer permisos— seguiría siendo posible; lo que se pierde es justamente la vista de unifilar y la trazabilidad equipo del patio ↔ nodo lógico, que es lo que vuelve rápido el trabajo de prueba y lo que permite que otro entienda el archivo sin el proyecto al lado.

El cambio que ningún validador ve

Hay una categoría de problema que ningún validador encuentra, porque el archivo está impecable.

Entre dos revisiones del mismo proyecto, veinte objetos de mando pasaron de seleccionar-antes-de-operar a mando directo, y en la versión nueva quedaron 205 objetos con mando directo en total. El archivo nuevo es válido: ctlModel admite los dos valores, los dos están bien escritos y ninguna regla semántica tiene algo que decir.

Lo que cambia es el protocolo de mando. Con selección previa, el cliente reserva el objeto, el IED verifica condiciones y bloquea a los demás clientes durante unos segundos antes de que llegue la orden de operar; con mando directo, el IED ejecuta al primer mensaje —sigue verificando enclavamientos y confirmando el resultado, pero cualquier cliente con acceso puede operar sin reservar. La HMI puede pedir doble clic y mandar igual en directo; eso no es selección previa, aunque al operador se lo parezca. La decisión es legítima y hay proyectos donde el mando directo se justifica. Lo que no encontramos fue dónde quedó escrita: apareció en una re-exportación del proyecto.

Lo vimos porque comparamos el archivo con su revisión anterior campo por campo. Desde entonces esa comparación quedó fija en cómo revisamos: modelo de mando, composición y orden de los datasets, número de revisión de configuración, suscripciones y direcciones, siempre contra la versión previa. Un validador contesta si el archivo está bien hoy; lo que además hay que saber es qué se movió desde la última vez que alguien dijo que estaba bien. Si nadie firmó ese cambio, en terreno es un cambio silencioso.

«Clase P1» no significa lo mismo en todas las ediciones

Este detalle aparece solo al abrir dos normas en paralelo, y tiene consecuencias contractuales.

La parte 5 define las clases de desempeño. En su edición 2.0, de 2013, la clase P1 exige un tiempo de transmisión total por debajo de un cuarto de ciclo —clase de transferencia TT6, ≤ 3 ms— y P2 lo exige del orden de medio ciclo —TT5, ≤ 10 ms—, con P1 como lo típico para mensajes dentro de la subestación y P2 para los que van entre subestaciones.

La parte 10, publicada en 2012, describe cómo medir el desempeño de GOOSE y dice justo al revés: «para la clase de desempeño P1, el tiempo total de transmisión debe ser del orden de medio ciclo; por lo tanto se define 10 ms. Para la clase P2/P3, el tiempo total debe estar por debajo de un cuarto de ciclo; por lo tanto se definen 3 ms».

La parte 10 declara en sus referencias normativas que se remite a IEC 61850-5:2003, la edición 1, y advierte que para referencias fechadas solo aplica la edición citada. Cita bien, entonces. En esa edición las clases se repartían por tipo de red —P1 para distribución, P2 y P3 para transmisión— y el reparto de tiempos era ese. La parte 5 edición 2 llegó un año después de la parte 10 y cambió el criterio, dejando los mismos nombres de clase con contenidos distintos.

El resultado es que hoy conviven dos significados de «clase P1», los dos citables, los dos con norma detrás. Nuestra lectura es sobre las copias de edición 2.0 que tenemos a la vista; hay una versión consolidada de la parte 10 publicada en julio de 2025 cuyo contenido no verificamos.

Para quien redacta una especificación da lo mismo cuál edición gane: escriba el número de milisegundos, el tipo de mensaje, el método de medición y la edición que está citando.

Hasta acá el archivo

Nada de lo anterior toca un equipo. Son revisiones que se pueden hacer meses antes de que llegue el primer tablero, con el proyecto todavía en pantalla, y que evitan descubrir en fábrica lo que ya estaba escrito en el modelo.

Lo que viene después no se resuelve en el archivo. En la segunda parte (en preparación) miramos cómo se prueba una función cuando el disparo dejó de viajar por cobre, qué pide hoy el Coordinador antes de energizar una subestación en Chile, y qué sigue necesitando que alguien vaya al patio con un tester.

Fuentes

• C. Brauner, E. Carvalheira, Functional testing of IEC 61850 based Substation Automation Systems, PAC World, febrero de 2021 (republicado por Electrical Engineering Portal).
• IEC 61850-1 ed. 2.0, cl. 6.8 — alcance de los ensayos y desarrollos futuros.
• IEC 61850-4 ed. 2.0, cl. 7.3 y 7.3.7 — ensayo de tipo; SAT en cuatro etapas.
• IEC 61850-5 ed. 2.0, cl. 11.1.3.3 y 11.2 — clases de sincronización y de desempeño.
• IEC 61850-6 ed. 2.1 — lenguaje SCL; IEC TS 61850-6-3:2025, Format of machine-processable rules for validation of IEC 61850 XML-based files.
• IEC 61850-7-4 ed. 2.0 — clase LPHD, atributo Sim; Amd. 1, anexo A — modo y comportamiento.
• IEC 61850-8-1 ed. 2.0, anexo C — bit de simulación en la trama GOOSE; prioridad IEEE 802.1Q.
• IEC 61850-10 ed. 2.0, cl. 1, 3.1, 5, 5.1 y 8.2.3 — alcance del ensayo de conformidad, definición de FAT, límites declarados, medición de desempeño de GOOSE.
• IEC TR 61850-10-3:2022, Functional testing of IEC 61850 systems.
• IEC TR 61850-90-4 ed. 2 — guía de ingeniería de red.
• CIGRE WG B5.90, Guidelines for commissioning and testing of fully digital PACS — términos de referencia aprobados el 6 de enero de 2026; brochura planificada para 2029. CIGRE WG B5.84, IEDs virtuales.
• Coordinador Eléctrico Nacional — documentos de revisión del Departamento de Análisis de la Operación sobre estudios de protecciones, publicados en el portal de gestión de proyectos.
• UCA International Users Group — campaña de interoperabilidad 2019.
• EDA, La red de la subestación digital: lo que la norma define y dónde se gana la interoperabilidad.