La conclusión principal de la historia de quince años del IOP: la calidad de los archivos SCL —sobre todo los ICD generados por las herramientas ICT de los fabricantes— sigue siendo el cuello de botella crítico en la integración multifabricante. En el IOP 2019, solo 10 de 159 archivos ICD (6,28%) superaron la validación sin errores, lo que llevó a una revisión fundamental de la filosofía de pruebas de UCAIug: desde 2020 la funcionalidad ICT se convirtió en parte obligatoria de las pruebas de certificación de IED. Paralelamente creció el papel de las reglas de validación legibles por máquina (OCL), y el IOP 2024 identificó más de 120 problemas, la gran mayoría relacionados con archivos SCL. Estos resultados se trasladan directamente al IEC TC 57 WG10 a través del mecanismo del User Feedback Task Force y la base de datos TISSUE, influyendo en el desarrollo del propio estándar IEC 61850-6.
Historia y cronología de los eventos UCAIug IOP
UCA International Users Group (UCAIug) es una organización sin ánimo de lucro que promueve la integración e interoperabilidad de los sistemas eléctricos basados en estándares internacionales. La organización actúa como paraguas de tres grupos de usuarios: CIM, IEC 61850 y OpenFMB. En el ámbito del IEC 61850, UCAIug desempeña tres funciones clave: acreditación de laboratorios de pruebas para las pruebas de conformidad, certificación de los resultados de las pruebas de conformidad, y organización de los eventos de pruebas de interoperabilidad (IOP).
Los eventos IOP se celebran cada dos años desde 2011. La diferencia fundamental entre IOP y las pruebas de conformidad: mientras que las pruebas de conformidad verifican si un dispositivo concreto cumple el estándar, el IOP tiene como objetivo identificar aquellas partes del estándar que admiten distintas interpretaciones y pueden impedir el intercambio de información entre dispositivos certificados de diferentes fabricantes.
| Año / Ciclo | Lugar | Participantes | Enfoque principal |
|---|---|---|---|
| 2011 | EDF R&D, París, Francia | 19 empresas, 14 fabricantes, 37 personas | Pruebas IED uno a uno; intercambio básico de SCL (ICD/CID/SCD) |
| 2013 | TÜV SÜD, Múnich, Alemania | 43 empresas, 20 fabricantes, 93 personas | Uno a uno + primera prueba del proceso de ingeniería (top-down/bottom-up); compatibilidad retroactiva Ed.2 |
| 2015 | Hotel Crowne Plaza, Bruselas, Bélgica | 49 empresas, 29 fabricantes, 130 personas | Uno a uno + pruebas en profundidad de procesos SCL (con participación de ENTSO-E); primeras pruebas de conformidad para SCT/ICT por DNV GL |
| 2017 | Nueva Orleans, Luisiana, EE.UU. | 7+ fabricantes MU (lista completa no publicada) | Primera prueba «integrada» — simulación de una subestación completa en lugar de pruebas por pares; participación de NIST |
| 2019 | EPRI, Charlotte, Carolina del Norte, EE.UU. | 25 fabricantes de 12 países, ~70 IED | Primera pista dedicada a SCL/SCT; aplicación integrada en paralelo; validación de 159 ICD con 5 herramientas |
| 2021–2022 | Virtual (oct. 2021) + CESI/KEMA, Milán, Italia (jul. 2022) | 28 fabricantes, ~80 personas | 2 SCT en paralelo; integrador independiente (POWER Engineers); 7 pruebas funcionales; primer R-GOOSE seguro con KDC |
| 2023–2024 | SCL IOP virtual (dic. 2023) + Birmingham, Alabama, EE.UU. (sep. 2024) | 130 personas, 86 dispositivos/aplicaciones | BAP (IEC 61850-7-6); validación OCL; autoconfiguración de red desde SCD; más de 120 problemas detectados |
| 2025–2026 (previsto) | Europa (otoño 2026) | — | Previsto junto con el IEC 61850 Boot Camp |
A partir del ciclo 2021–2022, cada IOP se divide en un componente SCL virtual (prueba de intercambio de archivos de configuración) y un componente F2F presencial (pruebas funcionales con equipos reales), celebrados con varios meses de diferencia.
Cuándo las pruebas de herramientas de configuración se convirtieron en una disciplina independiente
La evolución del enfoque de las pruebas SCT/ICT es una de las tendencias más reveladoras en la historia del IOP.
En el IOP 2011 en París, las pruebas de intercambio SCL eran obligatorias para todos los participantes (cada fabricante debía presentar un ICD y/o CID), pero se realizaban como actividad auxiliar sin pista dedicada. La conclusión principal: «No existe una herramienta completa de validación SCL» — la validación XML resultó insuficiente para verificar el cumplimiento del IEC 61850-6, y las implementaciones no podían interpretar correctamente el XSD sin una lectura profunda del estándar.
En el IOP 2013 en Múnich, el flujo de trabajo de ingeniería (top-down y bottom-up) se convirtió por primera vez en una de las principales áreas de prueba. Aquí se descubrieron «numerosos problemas relacionados con la configuración de dispositivos y el proceso de ingeniería basado en SCL» (según DNV), lo que impulsó el desarrollo de procedimientos formalizados de prueba de herramientas.
En 2015, DNV GL inició el desarrollo de los primeros procedimientos de conformidad para SCT e ICT: «DNV GL is working with the UCAIug to develop the first release of the conformance test procedures for Substation engineering and device configuration tools». En el IOP 2015 en Bruselas, con participación de ENTSO-E, se realizaron por primera vez pruebas en profundidad de los procesos SCL, y los resultados se presentaron inmediatamente en la reunión del IEC TC57 WG10, estratégicamente programada para la semana siguiente en el mismo edificio de ENTSO-E.
Una pista SCT formalmente dedicada apareció en el IOP 2019: el evento se dividió en dos flujos de prueba independientes — (1) intercambio SCL entre System Configuration Tools y (2) aplicación integrada. Este fue el punto de inflexión tras el cual las pruebas de herramientas de configuración adquirieron carácter sistemático.
Metodología de pruebas SCT/ICT
Base procedimental
Las pruebas SCT/ICT se apoyan en varios niveles de documentación. El UCAIug Test Procedure Working Group (TPWG) desarrolla y mantiene los procedimientos de prueba, realizando el seguimiento de los problemas a través del sistema Redmine (redmine.ucaiug.org) con subproyectos dedicados: SCL Tooling, Server, Client, GOOSE Performance. Los procedimientos para SCT e ICT fueron desarrollados por DNV GL sobre la base de Edition 2, acreditados por UCAIug, e incluyen casos de prueba con índices como sCnf (conformidad), sDs (DataSet), sSvp (Sampled Values), etc.
El estándar base IEC 61850-10 (Ed.2, 2012) define los métodos y los casos de prueba abstractos, pero los procedimientos específicos para SCT/ICT fueron más allá de su alcance y fueron desarrollados por UCAIug junto con los fabricantes. Con la evolución del estándar, se añaden las reglas de IEC 61850-6-3 — reglas de verificación SCL legibles por máquina basadas en OCL (Object Constraint Language), aplicadas ampliamente por primera vez en el IOP 2024.
Tipos de archivos SCL en las pruebas
| Tipo de archivo | Función en IOP | Período de prueba activa |
|---|---|---|
| ICD (IED Capability Description) | Archivo de entrada principal para SCT; define el rango completo de capacidades del IED (nombre IED = «TEMPLATE»). Validación masiva en IOP 2019 (159 archivos) | Desde 2011 hasta la actualidad |
| SCD (System Configuration Description) | Resultado clave del trabajo SCT; configuración completa de la subestación | Desde 2011 hasta la actualidad |
| CID (Configured IED Description) | Subconjunto de SCD para un IED específico; se carga en el dispositivo | Desde 2011 hasta la actualidad |
| SSD (System Specification Description) | Diagrama unifilar, niveles de tensión, LN requeridos; punto de partida del enfoque top-down | Desde 2015, activamente desde 2021 |
| IID (Instantiated IED Description) | Configuración IED específica del proyecto; utilizada en el enfoque bottom-up (introducido en Ed.2) | Desde 2013, activamente desde 2019 |
| SED (System Exchange Description) | Descripción de la interfaz entre proyectos (introducido en Ed.2) | Limitado desde 2013; pruebas ampliadas previstas |
Flujos de trabajo de ingeniería probados
El enfoque top-down es el método principal promovido por el estándar y el más activamente probado en el IOP desde 2019. El proceso incluye la creación de un SSD con diagrama unifilar, importación de archivos ICD de todos los fabricantes en el SCT, asignación de IED a funciones, configuración de suscripciones GOOSE/SV, bloques de informe, parámetros de comunicación y generación del SCD; luego importación del SCD en los ICT específicos de cada fabricante para extraer el CID; y finalmente carga del CID en los IED físicos. En el IOP 2021 este proceso se probó de extremo a extremo con la participación del integrador independiente POWER Engineers.
El enfoque bottom-up implica la configuración individual de IED a través de ICT específicos del fabricante, generación de archivos IID/CID e importación posterior en el SCT para la integración del sistema. Este enfoque sigue siendo necesario cuando las herramientas top-down no pueden manejar las características de suscripción específicas del fabricante.
La ingeniería de ida y vuelta (round-trip) es el intercambio iterativo entre SCT e ICT, donde los cambios a nivel de sistema (SCD) se transfieren de vuelta al ICT (a través de IID), y los cambios del ICT regresan al SCT. En el IOP 2021, POWER Engineers describieron el proceso así: el SCD se entregaba a los fabricantes en puntos de control, los fabricantes lo importaban en su ICT, notificaban los errores y se iniciaba un ciclo iterativo de intercambio.
Evolución de las pruebas según las ediciones del estándar
Era Edition 1 (IOP 2011)
El IOP 2011 trabajó exclusivamente con SCL Ed.1 (esquema 2003). Solo estaban disponibles los tipos de archivo ICD, SSD, SCD y CID — sin IID ni SED. Los tests principales cubrían MMS Client/Server, GOOSE básico y SV iniciales (9-2). Las pruebas SCT/ICT se limitaban al intercambio de archivos CID y la creación básica de SCD. Conclusiones clave: la validación XSD no equivale a la validación SCL; no existía una versión validada del XSD con las correcciones TISSUE.
Transición a Edition 2 (IOP 2013, 2015, 2017)
El IOP 2013 fue el primer evento en el que se probaron las capacidades de Edition 2: nuevos tipos de archivo IID y SED, compatibilidad retroactiva con Ed.1 y sección Services ampliada. Los problemas registrados en Redmine incluían: gestión de espacios de nombres (Issue #445), mezcla de modelos de datos Ed.1 y Ed.2 en un solo archivo SCL (Issue #444), formato ClientLN poco claro (Issue #446), uso de ExtRef para suscripción GOOSE y SV (Issue #445), y gestión de tipos de datos en DataSets (Issue #463).
En el IOP 2015, con participación de ENTSO-E, se desarrolló un proceso de ingeniería generalizado — por primera vez el área SCL se probó con tanta profundidad. Los resultados se transmitieron inmediatamente al WG10 y fueron una de las causas del retraso en la publicación del CDV de IEC 61850-6 Ed.2.1.
El IOP 2017 en Nueva Orleans trajo el paso de las pruebas por pares a una aplicación integrada — modelización de una subestación real con dispositivos asignados a funciones. Entre los problemas descubiertos figuró la ausencia en IEC 61850-6 de una forma de describir la configuración de autenticación para un cliente (Issue IOP_2017/8).
Era Edition 2.1 (IOP 2019, 2021–2022, 2023–2024)
El IOP 2019 fue un punto de inflexión. El resultado de validar 159 archivos ICD con 5 herramientas — solo el 6,28% sin errores — llevó a que la funcionalidad ICT se incluyera en las pruebas de conformidad obligatorias de IED para Ed.2 Amendment 1.
En el IOP 2021–2022 dos SCT trabajaron en paralelo por primera vez para crear un SCD para la misma subestación. El integrador independiente POWER Engineers actuó como desarrollador neutro de SCD. Para las pruebas funcionales en Milán se realizaron 7 pruebas end-to-end, incluida una del TSO belga Elia, que reveló que algunos IED bloqueaban la protección al perder la sincronización PTP. Por primera vez se probaron ADMS funcional basado en IEC 61850 y R-GOOSE seguro con Key Distribution Center (KDC).
El IOP 2023–2024 introdujo reglas OCL para la validación de ICD y el enfoque Basic Application Profiles (BAP) según IEC 61850-7-6. Como señaló Christoph Brunner (convocador de WG10): «Durante la preparación del IOP24 descubrimos que muchos archivos ICD de varios fabricantes contenían elementos Services incompletos o incorrectos». De los más de 120 problemas encontrados, la mayoría fueron detectados por las nuevas reglas OCL.
Resultados, problemas y herramientas participantes
SCT e ICT participantes
| Herramienta | Fabricante | Tipo | Participación confirmada en IOP |
|---|---|---|---|
| ASE61850 SCL Manager | ASE / Kalkitech | SCT | 2021 (SCL IOP virtual), 2022 (Milán), 2024 (Birmingham) |
| Helinks STS | Helinks | SCT | 2022 (Milán — ingeniería SCD para F2F) |
| IEC 61850 System Configurator | Siemens | SCT | Todos los IOP desde 2011; soporte Ed.1, Ed.2, Ed.2.1 |
| OpenSCD / CoMPAS | LF Energy (código abierto) | SCT | Ecosistema en crecimiento; Transpower NZ migró a OpenSCD en 2024 |
| DIGSI 4/5 | Siemens | ICT | Todos los IOP desde 2011 |
| PCM600 / IET600 / ITT600 | ABB / Hitachi Energy | ICT | IED (REL670, REB670, etc.) ampliamente utilizados en IOP |
| AcSELerator Architect | SEL | ICT | IED (SEL-451, SEL-421, etc.) participaron en IOP |
| Enervista (herramientas serie UR) | GE / Alstom / GE Vernova | ICT | Participación y autoría de white papers sobre resultados de pruebas multifabricante |
| Automation Studio | Efacec | ICT | IOP 2013 (Múnich) — BCU 500, UC 500 |
| MiCOM S1 Agile | Schneider Electric | ICT | Participación en varios IOP |
Los datos se basan en fuentes públicamente disponibles (artículos PAC World, blogs de fabricantes, LinkedIn).
Problemas típicos de interoperabilidad
Gestión de espacios de nombres — área crónicamente problemática. Los fabricantes utilizan namespaces propietarios en secciones privadas sin proporcionar los esquemas XSD, lo que hace imposible una validación correcta.
Las secciones privadas siguen siendo fuente de incompatibilidad. Las herramientas SCT a menudo no pueden procesar datos propietarios en los elementos Private. La pérdida de información durante la conversión (ICD → SCD → CID) es un problema documentado.
Desajustes en DataTypeTemplates se producen cuando los fabricantes modifican los tipos de datos sin seguir los procedimientos establecidos. Error típico: «FCDA does not refer any existing DA or BDA in DataTypeTemplates section».
Conflictos de direcciones y bloques de control: GOOSE AppID, direcciones MAC y IP deben coordinarse a través del SCT, pero los diferentes fabricantes implementan de forma distinta GSESettings, ReportSettings y SMVSettings (Fix vs. Conf vs. Dyn).
La configuración de suscripción GOOSE/SV es «la parte más compleja» de las pruebas multifabricante (GE Vernova). La vinculación de suscripciones a través de elementos ExtRef difiere significativamente entre fabricantes.
Manejo de archivos SCD grandes: los SCD reales pueden contener más de un millón de líneas, lo que los hace prácticamente ininterpretables. En proyectos grandes (p. ej., 2300 IED) se han reportado problemas de rendimiento y fallos de SCT.
La sección Services — problema agudizado en el IOP 2024. Muchos ICD contenían elementos Services incompletos, impidiendo que los SCT determinaran las operaciones permitidas con el dispositivo. Especialmente crítico con ClientServices (ausencia del atributo goose) y valKind/valImport.
Logros y tendencias positivas
ENTSO-E declaró: «El IOP demostró que partes del estándar IEC 61850 y los productos son muy estables… no es necesario esperar para aplicar IEC 61850».
La aparición de SCT de código abierto (OpenSCD/CoMPAS, LF Energy) es un cambio de paradigma: Transpower NZ en 2024 implementó un flujo completo en OpenSCD sin dependencia de ningún fabricante. La configuración automática de equipos de red desde SCD, demostrada en el IOP 2024, abre camino a reducciones significativas en costes de comisionamiento.
Impacto en el estándar IEC 61850 y documentos relacionados
La relación entre el IOP y el desarrollo del estándar es bidireccional. El canal directo (IOP → WG10) se implementa a través del User Feedback Task Force y la base de datos TISSUE (iec61850.tissue-db.com). El canal inverso (WG10 → IOP) se expresa en que WG10 desarrolla reglas OCL testadas en el IOP. El IEC 61850-6-3 (en desarrollo) formaliza estas reglas.
El IOP también influyó en IEC 61850-6 Amendment 2 (2024), que introdujo la identificación UUID de elementos, el elemento SclFileReference y el seguimiento mejorado de los derechos de ingeniería.
Los resultados del IOP se reflejan en las brochures de CIGRE: TB 819 (WG B5.50, 2020) señala que «debido a la interoperabilidad limitada de los productos IEC 61850 y la alta complejidad del estándar… varios proyectos encontraron serias dificultades». WG B5.68 (2018) aborda directamente los requisitos de interoperabilidad de herramientas. TB 401 ofrece un método estructurado de prueba funcional.
Línea de tiempo de la evolución de las pruebas SCT/ICT
| Parámetro | 2011 (París) | 2013 (Múnich) | 2015 (Bruselas) | 2017 (Nueva Orleans) | 2019 (Charlotte) | 2021–2022 (Virtual+Milán) | 2023–2024 (Virtual+Birmingham) |
|---|---|---|---|---|---|---|---|
| Formato de pruebas | Uno a uno | Uno a uno | Uno a uno + SCL profundo | Aplicación integrada | Pista SCL + integrada | SCL virtual + funcional F2F | SCL virtual + funcional BAP |
| Pista SCT dedicada | No | Parcialmente | SCL profundo | No (formalmente) | Sí | Sí | Sí |
| Edición del estándar | Ed.1 | Ed.1 + Ed.2 | Ed.2 | Ed.2 | Ed.2 / 2.1 | Ed.2.1 | Ed.2.1 / Ed.2 Amd.2 |
| Tipos de archivos SCL | ICD, CID, SCD | + IID, SED | + SSD | + SSD | Los 6 tipos | Los 6 tipos | Los 6 + ASD (BAP) |
| Herramientas de validación | Ninguna adecuada | Iniciales | DNV GL | — | 5 herramientas | Múltiples | OCL (RISEclipse) + XSD |
| Integrador independiente | No | No | ENTSO-E | No | No | POWER Engineers | POWER Engineers |
| Número de SCT | — | — | — | — | Múltiples | 2 | Múltiples |
| Resultado SCL clave | «Sin validador SCL completo» | Problemas namespace, mezcla Ed.1/2 | Pruebas SCL profundas | Sin plan de pruebas formal | 6,28% ICD pass rate | Intercambio SCD, prueba Elia | 120+ problemas (OCL) |
Conclusión: perspectivas estratégicas para el mercado de herramientas de configuración
La historia de quince años del IOP revela tendencias fundamentales para los desarrolladores de SCT/ICT. En primer lugar, la calidad de los archivos ICD/IID es el talón de Aquiles de la integración multifabricante: la inclusión de pruebas ICT en la certificación obligatoria de IED crea un nuevo imperativo de mercado. En segundo lugar, la validación OCL está desplazando a la validación XSD como herramienta principal. En tercer lugar, el enfoque BAP y la autoconfiguración desde SCD definen el vector de desarrollo para los próximos años. En cuarto lugar, la aparición de SCT open-source e integradores independientes señala la desconcentración del mercado.
Finalmente, cada IOP confirma: la ingeniería top-down sigue siendo el enfoque correcto, pero los obstáculos prácticos —distintas interpretaciones del estándar, problemas con secciones privadas y elementos Services— requieren aún soluciones híbridas. El IOP 2026 en Europa promete ser el próximo punto de control de madurez de las herramientas de configuración.