Nota editorial
Este artículo inicia una nueva serie sobre la ingeniería top-down según IEC 61850, uno de los cambios más significativos en la metodología de ingeniería de subestaciones digitales en los últimos años. Ahora se han publicado dos nuevos informes técnicos de la IEC (TR 61850-90-30 y TR 61850-7-6 ed2); una coalición de 14 empresas eléctricas europeas ha respaldado formalmente este enfoque; y las primeras implementaciones en producción están a punto de materializarse. En esta serie, rastreamos ese cambio desde sus orígenes hasta sus implicaciones prácticas: para las empresas eléctricas, los proveedores de IED y los desarrolladores de herramientas. Este primer artículo establece el contexto.

En 2023, catorce operadores de sistemas de transmisión y empresas eléctricas europeas firmaron una declaración común sobre la ingeniería según IEC 61850. No fue un instrumento regulador. No contaba con mecanismos de cumplimiento. Pero fue algo que rara vez ocurre en la normalización industrial: un grupo de grandes empresas eléctricas, cada una protectora de sus propios procesos, convergiendo en una posición compartida sobre cómo debería funcionar la ingeniería — y comprometiéndose públicamente a ella.

La iniciativa fue liderada por el Grupo Elia —el operador de red belga Elia y su filial alemana 50Hertz— y atrajo a otras trece empresas eléctricas. Junto publicaron lo que hoy se conoce como la Visión Común sobre la Ingeniería IEC 61850: un documento que describe un proceso de ingeniería top-down de cinco pasos, explica qué requiere de los proveedores de herramientas y de los fabricantes de IED, y demuestra — a través de un concepto de prueba funcional — que es técnicamente alcanzable hoy.

Este artículo examina lo que dice la Visión Común, cómo surgió y qué significa para las personas y organizaciones que construyen subestaciones digitales.

El problema: ¿Por qué el enfoque actual tiene límites estructurales?

La metodología actual de ingeniería según IEC 61850 se basa en dispositivos. Una empresa eléctrica prepara los requisitos — típicamente en documentos de Word o PDF — y los envía a los proveedores de IED. Cada proveedor interpreta esos requisitos, configura un dispositivo según su propia cadena de herramientas y devuelve un archivo de descripción de capacidad (ICD). El ingeniero del sistema ensambla la configuración final del sistema cruzando referencias entre estos archivos ICD, resolviendo manualmente las diferencias de nomenclatura y vinculando conjuntos de datos, suscripciones GOOSE y elementos ExtRef a mano.

Este enfoque produjo sistemas IEC 61850 funcionales durante veinte años. Pero se ha vuelto estructuralmente limitante a medida que las subestaciones digitales pasan de implementaciones piloto a infraestructura estándar, y a medida que grandes empresas eléctricas gestionan simultáneamente decenas de proyectos IEC 61850.

Los problemas son bien conocidos entre los profesionales:

  • Vacíos en la interpretación. Las especificaciones en formato PDF permiten malinterpretaciones. Dos proveedores que lean el mismo documento pueden generar configuraciones significativamente diferentes. El usuario se entera en la fase de puesta en marcha.
  • Falta de intercambio legible por máquinas. No existe un formato formal ni procesable por herramientas para comunicar lo que debe hacer un IED. Cada proyecto recrea la especificación desde cero.
  • Pruebas tardías. La verificación suele comenzar tras la selección y compra del dispositivo, el momento más costoso para descubrir un error de diseño.
  • Falta de reutilización. Las especificaciones de funciones desarrolladas para un proyecto no pueden transferirse directamente al siguiente. Cada despliegue reinicia el ciclo de ingeniería.

Thomas Sterckx, experto en subestaciones virtuales en Elia Engineering y coeditor de los informes técnicos relevantes de la IEC, describió la dirección del cambio en un seminario técnico de diciembre de 2023: "En lugar de darle al proveedor del IED una larga serie de documentos escritos... puedes darle algo que sea legible por máquina, que pueda procesar dentro de su propia herramienta."

La Historia: De CIGRE 2012 a la Declaración Común 2023

La demanda de procesos de ingeniería mejorados para sistemas IEC 61850 no es nueva. En 2012, la organización CIGRE publicó una declaración — bajo los comités de estudio A3 y B5 — que solicitaba mejoras en la forma en que se especificaban e ingenierizaban los sistemas IEC 61850. Las exigencias formuladas en ese momento permanecieron en gran medida sin cumplir durante una década.

En 2018, Elia participó en OSMOSE, un proyecto de investigación financiado por la Unión Europea. OSMOSE desarrolló el marco conceptual inicial para lo que hoy es el enfoque de ingeniería ascendente: comenzar con especificaciones de funciones independientes de cualquier dispositivo en particular, y formalizar el intercambio entre las empresas eléctricas y los proveedores en formatos estructurados y legibles por máquinas.

A partir de 2020, el Grupo de Trabajo 10 del TC57 de la IEC comenzó a desarrollar dos informes técnicos que darían una base normativa a estos conceptos: TR IEC 61850-90-30, que aborda la modelización de funciones en SCL, y TR IEC 61850-7-6 ed2, que cubre los perfiles de aplicación básicos. Ambos han sido publicados desde entonces — el TR 7-6 ed2 en 2024, y el TR 90-30 en 2025.

La Declaración Común, firmada en 2023 por el Grupo Elia junto con trece otras empresas eléctricas europeas, fue el momento en que esta trayectoria se convirtió en una señal de mercado. Como observó Sterckx: "Creo que puedo decir que finalmente estamos siendo capaces de cumplir con las declaraciones o requisitos que pidieron en 2012."

Junto con la Declaración Común, Elia completó un proyecto de prueba de concepto con tres socios industriales — Condis/Helinks (herramientas para especificación de sistemas), Siemens (herramientas para configuración de IED), y Triangle MicroWorks (simulación y pruebas) — demostrando el proceso completo de cinco pasos mediante herramientas prototipo.

La Visión Común describe un proceso de ingeniería basado en cinco pasos secuenciales. La lógica es verdaderamente de arriba hacia abajo: el proceso comienza con requisitos funcionales expresados completamente independientes de cualquier dispositivo específico, y solo llega a la configuración física del dispositivo al final.

flowchart LR
    P1["① Perfilado del Sistema\n(FSD / ASD templates)"]
    P2["② Especificación del Sistema\n(ISD files)"]
    P3["③ Simulación y Validación\n(ASD / SSD testing)"]
    P4["④ Capacidad del IED\n(procesar ICD)"]
    P5["⑤ Configuración del Sistema\n(SCD)"]

    P1 --> P2 --> P3 --> P4 --> P5

Paso 1 — Perfilado del Sistema. Los ingenieros crean plantillas reutilizables de funciones y aplicaciones. Una Descripción de Especificación de Función (FSD) define una sola función — protección por distancia, control de interruptor, monitoreo de transformador. Una Descripción de Especificación de Aplicación (ASD) combina múltiples FSDs, define el flujo de datos entre ellas y puede incluir lógica de comportamiento formal escrita en IEC 61131-3. Críticamente, estas plantillas no hacen referencia a ningún dispositivo físico. Definen lo que el sistema debe hacer, no cómo lo hace ningún dispositivo en particular.

Paso 2 — Especificación del Sistema. Las plantillas de aplicación se instancian en un proyecto. El ingeniero ensambla una especificación del sistema y genera especificaciones por IED: archivos Descripción de Especificación de IED (ISD) — documentos estructurados en SCL que definen formalmente el modelo de datos, las interfaces de señal y los valores de configuración. Un archivo ISD es independiente del proveedor. El mismo archivo puede enviarse a múltiples proveedores en paralelo, solicitando respuestas competitivas sobre la capacidad.

Paso 3 — Simulación y Validación del Sistema. Con los archivos ISD completos, el diseño puede probarse antes de seleccionar o adquirir cualquier dispositivo. Las herramientas importan archivos ASD y SSD, simulan la lógica de la aplicación — incluyendo las descripciones de comportamiento en IEC 61131-3 — y permiten ejecutar secuencias de prueba contra entradas y salidas esperadas. Para este paso, el PoC utilizó el DTM (Distributed Test Manager) de Triangle MicroWorks. Como dijo Jackson Moore, Ingeniero de Aplicaciones en Triangle MicroWorks: "Muchos errores potenciales ahora pueden identificarse mucho antes en el proceso de ingeniería — y son comparativamente mucho más baratos y fáciles de corregir."

Paso 4 — Descripción de la Capacidad del IED. Los proveedores reciben el archivo ISD, lo importan en su herramienta de configuración de IED (ICT), y mapean las capacidades reales del dispositivo a la especificación. Cuando las capacidades del dispositivo coinciden con la especificación, el mapeo es directo. Cuando existen diferencias — nombres de dispositivos lógicos diferentes, objetos de datos ausentes, implementaciones alternativas — el proveedor documenta formalmente la desviación. El resultado es un ICD procesado: un archivo ICD estándar extendido con información explícita de mapeo de especificación a dispositivo. Este archivo indica a la herramienta de configuración del sistema exactamente cómo cada elemento de la especificación de la utilidad se implementa en el dispositivo real.

Paso 5 — Configuración del sistema. La herramienta de configuración del sistema (System Configuration Tool, SCT) importa archivos ICD de proceso de cada proveedor. Utilizando la información de mapeo incorporada en cada archivo, vincula automáticamente los nodos lógicos a dispositivos reales, genera bloques de control GOOSE y conjuntos de datos, y rellena las suscripciones ExtRef. El resultado es un archivo SCD completo, con una intervención manual significativamente menor que la requerida por el enfoque actual.

La prueba de concepto: un flujo de trabajo completo en vivo

La prueba de concepto liderada por Elia recorrió todos los cinco pasos utilizando un escenario de ingeniería real, aunque simplificado: una aplicación de interruptor automático y una aplicación de protección por distancia implementadas en cuatro IED. El flujo de trabajo se demostró públicamente en un seminario web celebrado en diciembre de 2023 por Triangle MicroWorks.

En la demostración:

  • Helix STS (Condis/Helinks) se encargó del perfilado del sistema y la especificación del sistema, generando archivos ASD e ISD a partir de plantillas de funciones ensambladas en su entorno de herramientas.
  • El DTM de Triangle MicroWorks importó el ASD y demostró la simulación de la aplicación de protección por distancia P21, incluyendo la manipulación interactiva de entradas y un secuenciador de pruebas controlado desde Excel.
  • DIGSI 5 de Siemens importó los archivos ISD para una unidad de fusión 6MU y un relé de protección por distancia 7SA87, realizó el mapeo de LNode a LN, y exportó archivos ICD de proceso — con la opción de conservar la nomenclatura nativa del dispositivo o adoptar el modelo de datos unificado de la especificación.
  • Helix STS importó ambos archivos ICD de proceso, implementó automáticamente las especificaciones de LNode utilizando los datos de mapeo, generó bloques de control GOOSE y conjuntos de datos, y exportó un SCD completo.
  • El Digital Twin de Siemens importó el SCD, aplicó la configuración GOOSE y ejecutó ambos dispositivos virtuales simultáneamente para verificar el flujo de señales y el modelo de datos.

Todo el flujo de trabajo utilizó el espacio de nombres SCL 6-100 — la extensión definida en la TR 61850-90-30 y la TR 61850-7-6 que introduce los nuevos elementos SCL necesarios para el proceso: AllocationRole, SourceRef, LNodeSpecNaming, BehaviorDescription, entre otros.

Lo que esto significa para el mercado

La Declaración Común y la prueba de concepto adjunta tienen un público objetivo específico: proveedores de IED y proveedores de herramientas que necesitan comprender qué esperan las grandes empresas eléctricas europeas de sus productos.

Para los proveedores de IED, el cambio formal en la interfaz ISD altera la dinámica de adquisición. Una utility que posea un archivo ISD legible por máquina puede enviarlo simultáneamente a varios proveedores y comparar sus respuestas ICD de proceso — incluyendo desviaciones documentadas — en un formato estructurado. La barrera para cambiar de proveedor disminuye. Como señaló Sterckx: "Un ISD es independiente del proveedor y puedes enviarlo fácilmente a varios proveedores de IED y obtener múltiples ofertas de vuelta."

Para los proveedores de herramientas de configuración de IED, la Visión Común define requisitos de funcionalidad concretos: importación de ISD, mapeo de LNode a LN, exportación de ICD de proceso y documentación de desviaciones. Estas son las características que determinarán si una herramienta es utilizable en el nuevo flujo de trabajo.

Para los proveedores de herramientas de configuración de sistemas, el requisito clave es el soporte del ICD de proceso: la capacidad de leer la información de mapeo en un archivo ICD de proceso y utilizarla para automatizar la generación del SCD.

Elia Group ha indicado una hoja de ruta de desarrollo que llega hasta 2029–2030 para los primeros proyectos de producción, con la adquisición de herramientas prevista para aproximadamente 2027. La cronología otorga al ecosistema de herramientas varios años, pero las decisiones sobre prioridad de desarrollo ya se están tomando. TR 90-30 y TR 7-6 ed2 están publicadas. El proceso ha sido demostrado. Elia se está preparando para convocar una licitación para un ecosistema de ingeniería.

Conclusión

La Visión Común es una respuesta bien estructurada a un problema real y reconocido. El enfoque actual de ingeniería según IEC 61850 —especificación mediante PDF, integración manual, validación tardía— no es donde debería estar un estándar maduro. La firma de catorce utilities en la misma definición de proceso genera una señal de demanda que el mercado de herramientas no puede ignorar.

La infraestructura de estándares está en su lugar. La demostración del concepto prueba que el proceso es técnicamente viable con herramientas existentes. La pregunta ahora es cuán rápido se alineará el ecosistema más amplio —proveedores de IED, proveedores de herramientas y utilities más allá de la coalición actual— con el enfoque descrito en la Visión Común.

Los artículos siguientes de esta serie examinan los detalles técnicos: el proceso de cinco pasos en profundidad, el formato de archivo ISD y lo que cambia sobre la adquisición de IED, el espacio de nombres SCL 6-100 y lo que los desarrolladores de herramientas necesitan implementar, y el ICD de proceso como punto de inflexión entre especificación y configuración.

Fuentes primarias: Webinar técnico — "Estableciendo un proceso de especificación independiente de proveedores para la ingeniería ascendente de sistemas IEC 61850" (Triangle MicroWorks / Elia Group, diciembre de 2023); TR IEC 61850-90-30:2025; TR IEC 61850-7-6 ed2:2024; Elia Group — Visión Común sobre Ingeniería IEC 61850.

Foto: Subestación Mercator de 380 kV, Kruibeke, Bélgica (Elia). Supercharge / Wikimedia Commons, CC BY-SA 3.0.