Un nuevo e importante mecanismo de validación de archivos SCL aparece en el proceso de ingeniería de IEC 61850 — el OCL (Object Constraint Language), un lenguaje para describir formalmente restricciones y reglas para los objetos del modelo de información.
En 2025 se publicó la especificación técnica IEC TS 61850-6-3 «Format of machine-processable rules for validation of IEC 61850 XML-based files». Define el formato y el método de descripción de reglas formales OCL que pueden ser importadas e interpretadas por herramientas de software. Entre los escenarios previstos está la validación de archivos SCL en distintas etapas de especificación y diseño.
Además, ya no se trata solo de una tecnología prometedora. Las comprobaciones OCL empiezan a aplicarse en la práctica.
Por qué el XSD ya no basta
La base tradicional de la validación formal del SCL es el XML Schema Definition — XSD.
Con él se puede comprobar la estructura de un documento XML:
- si un determinado elemento está permitido;
- si puede encontrarse en este lugar;
- qué atributos están previstos para él;
- si un atributo es obligatorio;
- si un valor corresponde a un determinado tipo de dato.
Esta comprobación es necesaria. Pero sus posibilidades están limitadas por la propia naturaleza del XML Schema. El XSD responde bien a la pregunta: «¿Está bien formado el documento XML?»
Sin embargo, muchos requisitos de la IEC 61850 están relacionados no con la estructura de elementos XML aislados, sino con las relaciones entre distintos objetos y parámetros del modelo.
La presencia de un objeto puede exigir la presencia de otro. El valor de un atributo puede imponer restricciones al valor de otro. La admisibilidad de una determinada configuración puede depender de varios elementos del SCL a la vez.
Al mismo tiempo, cada uno de esos elementos, por separado, puede cumplir plenamente con el XML Schema.
Qué aporta el OCL
El OCL permite describir formalmente reglas aproximadamente del siguiente tipo: si se cumple la condición A, entonces el objeto B debe existir o tener determinadas propiedades.
Después de eso, tal regla puede aplicarse automáticamente a un archivo SCL, y las infracciones encontradas — registrarse mediante una herramienta de software.
Un ejemplo sencillo tiene que ver con la declaración de las capacidades de servicio de un IED.
En la sección Services, el dispositivo describe las capacidades que soporta, incluidas las relacionadas con informes. Si un IED declara un valor de maxReports > 0 —es decir, informa de la capacidad de usar uno o varios Report Control Block—, debe, al mismo tiempo, declarar el soporte de al menos un tipo de informe:
- bufReport = true — se soportan informes almacenados en búfer;
- unbufReport = true — se soportan informes no almacenados en búfer.
O pueden soportarse ambos tipos.
De lo contrario, surge una contradicción lógica: el dispositivo declara la capacidad de trabajar con informes, pero al mismo tiempo no declara el soporte de ninguno de sus tipos.
Al mismo tiempo, desde el punto de vista del XML, cada atributo en sí mismo puede ser perfectamente correcto: el elemento existe, el valor tiene un tipo permitido, la estructura del documento cumple con el XSD. El problema no está en el XML, sino en la relación entre los valores.
Son precisamente esas relaciones las que el OCL permite formalizar y comprobar automáticamente.
El XSD comprueba ante todo la corrección de la estructura del documento. El OCL permite comprobar las reglas que debe satisfacer el modelo descrito en él.
Del texto de la norma a la regla legible por máquina
Hoy, una parte significativa de los requisitos de la IEC 61850 existe en forma textual. El desarrollador de un producto de software, el fabricante de un dispositivo, el proyectista o el experto debe leer la cláusula correspondiente de la norma, interpretarla e implementar por sí mismo la comprobación necesaria.
El OCL permite representar parte de esos requisitos en una forma formal, legible por máquina. Una regla como «si se cumple la condición X, el elemento Y debe poseer la propiedad Z» puede existir como una regla formal que una herramienta de software es capaz de ejecutar automáticamente.
Al mismo tiempo, la IEC TS 61850-6-3 define precisamente el formato y el modo de descripción de tales reglas, mientras que las propias reglas pueden usarse como componentes legibles por máquina de las partes correspondientes de la IEC 61850.
Gracias a ello, la validación del SCL se vuelve más reproducible y menos dependiente de la interpretación manual de los requisitos por un especialista concreto.
OCL — uno de los focos del UCAIug IOP
La dirección del desarrollo se ve especialmente bien en los ensayos internacionales de interoperabilidad de la IEC 61850.
La validación OCL ya se aplicó en ciclos anteriores del UCAIug IOP en la comprobación del SCL, junto con otras líneas de prueba de las herramientas de configuración. Los errores y no conformidades del SCL siguen siendo tradicionalmente una de las clases notables de problemas detectados en esos eventos.
El siguiente gran punto de control será el UCAIug IEC 61850 IOP 2026.
La parte presencial de los ensayos internacionales tendrá lugar en Utrecht, Países Bajos. El programa principal de ensayos está previsto para el 12–16 de octubre de 2026. El evento será un espacio para la verificación práctica de la interacción entre dispositivos, gateways y herramientas de software IEC 61850 de distintos fabricantes.
Teniendo en cuenta el desarrollo de la IEC 61850-6-3 y la experiencia ya acumulada en IOP anteriores, el OCL y la validación automatizada del SCL se convierten en una de las líneas notables de los ensayos internacionales de interoperabilidad.
Es una señal importante para el sector: el OCL pasa gradualmente de la categoría de un nuevo mecanismo de la norma a un instrumento práctico de comprobación de la calidad de los datos de ingeniería de la IEC 61850.
De la comprobación del XML a la comprobación de reglas de ingeniería
Hace tiempo que el SCL dejó de ser solo un archivo XML para el intercambio de configuración entre programas.
En el proceso de ingeniería moderno de la IEC 61850, el SCL se convierte de hecho en la descripción digital de un sistema de automatización de subestación.
Por eso se desarrolla también, de forma natural, el instrumental de su comprobación:
- XSD — ¿está bien formado el documento XML?
- NSD — ¿el modelo de información utilizado corresponde a los requisitos de la IEC 61850?
- OCL — ¿se cumplen las reglas y relaciones más complejas entre los objetos de ese modelo?
Precisamente en esto reside el valor fundamental del OCL.
Permite pasar de comprobar la corrección formal del XML a la comprobación automatizada de requisitos de ingeniería que antes había que interpretar y controlar manualmente.
Por eso el OCL debe considerarse no simplemente como un lenguaje más en el ecosistema de la IEC 61850, sino como un paso hacia una validación más profunda y formalizada del SCL. De una descripción legible por máquina de la subestación digital — a una comprobación legible por máquina de las reglas de ingeniería.