En la ingeniería convencional según IEC 61850, los errores aparecen en el momento peor posible: durante la puesta en marcha, cuando el hardware está en el sitio, los equipos están desplegados y los plazos del proyecto están bajo presión. El proceso de ingeniería de arriba hacia abajo —formalizado en la TR IEC 61850-90-30:2025 y la TR IEC 61850-7-6 (Ed. 2)— adelanta dramáticamente ese momento: antes de seleccionar un único EID (dispositivo electrónico inteligente), antes de firmar un contrato y antes de que exista cualquier dispositivo físico. Catorce TSO europeos, incluyendo Elia y 50Hertz, firmaron una Declaración Común en 2023 respaldando este enfoque como la dirección para la ingeniería de subestaciones digitales. El primer artículo de esta serie abordó por qué la industria está avanzando en esta dirección y qué impulsó el consenso entre las catorce empresas. Este artículo explica la mecánica: qué ocurre en cada uno de los cinco pasos, qué archivos se intercambian y por qué el proceso produce mejores resultados que los anteriores.

Por qué el enfoque de abajo hacia arriba falla

El proceso convencional de IEC 61850 comienza con el EID. Se obtiene un archivo ICD del proveedor, se construye el sistema en torno a lo que el dispositivo puede hacer, y se comunican los requisitos mediante documentos de especificación en PDF —que cada proveedor lee e interpreta de forma independiente. Cuando surgen discrepancias, el equipo ya está adquirido, el proyecto está comprometido y las correcciones son costosas. El proceso de arriba hacia abajo invierte completamente esta secuencia: los requisitos funcionales se definen primero en formato legible por máquina, se validan sin hardware y solo entonces se entregan a los proveedores como una especificación estructurada que pueden procesar en sus propias herramientas.

El proceso de cinco pasos en resumen

El proceso consta de cinco pasos, cada uno generando un archivo estructurado que se convierte en la entrada del siguiente. Tres categorías de herramientas están involucradas: una Herramienta de Especificación del Sistema (SST) operada por el ingeniero de la utility, una Herramienta de Configuración del EID (ICT) operada por el proveedor del EID, y una Herramienta de Configuración del Sistema (SCT) operada nuevamente por el ingeniero de la utility. Así es como se conectan:

flowchart LR
    A["Paso 1\nPerfilado del Sistema\nFSD / ASD\n(SST)"] -->|"Archivos ASD\nespacio de nombres 6-100"| B["Paso 2\nEspecificación del Sistema\nISD / SSD\n(SST)"]
    B -->|"SSD\nto simulation"| C["Paso 3\nSimulación y\nValidación\n(Puerta de Simulación)"]
    C -->|"falla:\nrevisar SSD"| B
    C -->|"éxito:\nSSD validado\n+ ISD al proveedor"| D["Paso 4\nCapacidad del EID\nprocesar ICD\n(ICT)"]
    D -->|"procesar ICD + SSD"| E["Paso 5\nConfiguración del Sistema\nSCD\n(SCT)"]
    E -->|"SCD"| F["Despliegue del EID"]
    style C fill:#d4f4dd,stroke:#2d9e5a

Todos los archivos utilizan formato SCL con extensiones de espacio de nombres 6-100. El Paso 3 puede implicar un ciclo iterativo —la simulación está integrada al desarrollo de la especificación, con el ingeniero especificando, probando y refinando hasta confirmar el comportamiento. Los archivos ISD se envían a los proveedores solo después de que la especificación haya sido validada.

La Etapa 1 produce los bloques funcionales reutilizables utilizados en todo el proyecto. El ingeniero del sistema crea plantillas reutilizables — denominadas Descripciones de Especificación de Función (FSD) y Descripciones de Especificación de Aplicación (ASD) — sin hacer referencia a ningún fabricante o línea de productos específico de IED.

Una FSD describe una función de protección o control individual: sus nodos lógicos, señales y atributos de datos requeridos. Una ASD ensambla múltiples FSD en una aplicación completa — por ejemplo, una aplicación de protección por distancia (P21) o una aplicación de control de interruptor. La ASD también incluye:

  • Flujo de datos — cómo se mueven las señales entre funciones, anotado con el tipo de servicio (GOOSE, SMV o Interno) y dirección
  • BehaviorDescription — la lógica funcional, escrita ya sea como requisitos de texto plano o formalizada como Diagramas de Bloques de Función (FBD) según IEC 61131-3
  • ProcessResources — marcadores para señales esperadas de otras aplicaciones aún no combinadas en el proyecto

Este último elemento es importante. Cuando una aplicación de protección espera que una orden de disparo llegue al interruptor, esa conexión no puede resolverse completamente dentro de una sola ASD — la aplicación del interruptor es una plantilla separada. Por lo tanto, se modela como un marcador de ProcessResource, y se resuelve en la Etapa 2 cuando ambas aplicaciones se combinan.

Las funciones dentro de una ASD se agrupan mediante AllocationRoles — roles lógicos como "PIU", "Controlador de Bay", o "Protección". Un AllocationRole define lo que hará un IED lógico; no nombra un dispositivo físico ni un fabricante. En esta etapa, ningún proveedor está involucrado en absoluto.

En el prototipo de Elia, demostrado en diciembre de 2023 utilizando Helinks STS (Helinks/Alvexis), el equipo creó dos plantillas de ASD: una aplicación de interruptor con cuatro roles de asignación, y una aplicación de protección por distancia P21 con lógica de disparo según IEC 61131-3. Ambas plantillas fueron completamente independientes de las capacidades de productos de cualquier proveedor.

Thomas Sterckx de Elia resumió el principio: "Realmente se puede hacer de forma independiente de tecnología. También es una especificación independiente de proveedor."

Etapa 2: Especificación del Sistema — Requisitos de IED Legibles por Máquina

En la Etapa 2, el ingeniero instancia las plantillas de la biblioteca de ASD en un proyecto concreto. Cuando se combinan dos aplicaciones, sus ProcessResources se resuelven: la señal esperada de disparo a CB de la aplicación de protección ahora se mapea a la función real en la aplicación de interruptor. El sistema comienza a tomar forma — aún sin hardware.

Para cada IED físico en el proyecto, el ingeniero genera una Descripción de Especificación de IED (ISD): un archivo legible por máquina que reemplaza la pila tradicional de documentos PDF de requisitos. Una ISD contiene:

  • El modelo de datos esperado: dispositivos lógicos, nodos lógicos, objetos de datos y atributos (especificados mediante elementos DOS/DAS)
  • Especificaciones de DataFlow: qué señales debe recibir y enviar el IED, junto con el tipo de servicio y los UUIDs de SourceRef
  • Descripciones de comportamiento: la lógica funcional requerida que el IED debe implementar
  • Expectativas de interfaz física y nombrado (elementos LNodeSpecNaming)

Un ISD puede enviarse simultáneamente a varios proveedores. Cada proveedor lo procesa con su propia herramienta de configuración de IED — no leyendo e interpretando texto, sino mediante el análisis automático del archivo SCL. Las respuestas regresan en un formato estructurado y comparable. Como explicó Thomas Sterckx: "En lugar de darle al proveedor del IED una gran serie de documentos escritos, puedes darle algo que sea legible por máquina, que pueda procesar dentro de su propia herramienta."

La salida del Paso 2 es doble: archivos ISD para cada IED, y un SSD (System Specification Description) que captura la especificación completa del proyecto — el cual también sirve como entrada para el Paso 3. El SSD avanza inmediatamente a la simulación. Los archivos ISD, sin embargo, no se envían a los proveedores en este momento: se envían únicamente después de que la especificación haya sido validada mediante simulación (Paso 3, o al final del ciclo iterativo de simulación). Esta secuencia es intencional — enviar un ISD a un proveedor antes de la validación corre el riesgo de fijar una especificación que no se ha confirmado que funcione como se pretende.

Paso 3: Simulación y Validación del Sistema — Prueba antes de que exista el hardware

Este es el paso que define la ingeniería de arriba hacia abajo.

Sin hardware. Sin proveedor seleccionado. Sin contrato firmado.

El SSD o ASD se importa a una herramienta de simulación, y el comportamiento del sistema se prueba contra la especificación funcional — completamente en software. Lo que hace posible esta simulación es la estructura formal del propio ASD. Una especificación en PDF describe la lógica de protección en lenguaje natural. Un ASD codifica los mismos requisitos como Diagramas de Bloques de Función (FBD) según IEC 61131-3 — una representación que las herramientas pueden analizar, representar y ejecutar directamente. Esto no es simulación en sentido aproximado; es la ejecución directa de la especificación tal como está escrita.

Se disponen de dos vistas. La primera es un gráfico de flujo de datos: recursos de proceso (entradas) a la izquierda, lógica funcional en el centro, salidas a la derecha. Todos los caminos de señal son visibles, incluyendo el tipo de servicio y la dirección — el ingeniero puede rastrear cualquier entrada hasta cualquier salida antes de que se configure un solo IED. La segunda es la ejecución de comportamiento: donde el ASD contiene lógica FBD según IEC 61131-3, la herramienta la representa y permite manipulación interactiva. Establezca un valor de entrada como activo — la señal se propaga a través del diagrama de bloques de función en tiempo real, y se observa qué salidas se activan.

Para la validación estructurada a gran escala, las escenarios pueden definirse como casos de prueba tabulares: una fila por escenario, con valores de entrada predefinidos y valores de salida esperados para cada señal en la aplicación. La herramienta ejecuta la secuencia, marca discrepancias y captura los tiempos, permitiendo verificar el comportamiento dependiente del tiempo donde la precisión en milisegundos es importante.

Es importante destacar que la simulación no necesariamente es una verificación única al final del trabajo de especificación. Como describió Jackson Moore: "esto puede ser un proceso iterativo — la prueba puede realizarse mientras el diseño aún se está desarrollando." En la práctica, esto significa que el ingeniero puede especificar una parte del ASD o SSD, simularlo, refinarlo basándose en los resultados y simularlo nuevamente — ciclando entre especificar → simular → refinar hasta que el comportamiento esté completamente confirmado. La herramienta de simulación está integrada en el flujo de trabajo de especificación, no se añade a él.

La salida del Paso 3 no es un nuevo archivo. Es una especificación verificada — el mismo SSD o ASD, confirmado que se comporta como se pretende. En este punto, los archivos ISD están listos para enviarse a los proveedores (Paso 4): llevan una especificación que ha sido ejecutada y validada, no simplemente escrita. El argumento económico es directo: un error de especificación encontrado en el Paso 3 cuesta una tarde de re trabajo en un archivo SCL. El mismo error encontrado durante la puesta en marcha — después de la adquisición, después de la movilización, con hardware en sitio y equipos desplegados — cuesta órdenes de magnitud más. El mecanismo técnico es igualmente directo: debido a que el comportamiento está formalizado en IEC 61131-3 en lugar de en lenguaje natural, puede ser ejecutado por una herramienta independientemente de cualquier dispositivo específico.

Jackson Moore, quien demostró la simulación en el prototipo de Elia: "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 — El Proveedor Responde

El archivo ISD se envía al fabricante del IED, quien lo importa en su Herramienta de Configuración del IED. La herramienta compara automáticamente la especificación con el modelo de datos real del dispositivo — identificando qué nodos lógicos y objetos de datos están disponibles, cuáles deben crearse y dónde las convenciones de nombramiento del proveedor difieren de las de la especificación.

La salida es un ICD de proceso: un archivo ICD estándar extendido con información de mapeo del espacio de nombres 6-100. Documenta explícitamente:

  • Cómo cada nodo lógico en la especificación se mapea al LN real del proveedor (mappedLnUuid, mappedDoName)
  • Marcadores de referencia externa (extRefUuid) vinculados a entradas SourceRef en la especificación — estos se resolverán automáticamente por el SCT en el Paso 5
  • Cualquier desviación en BehaviorDescription: si el proveedor no puede implementar la lógica especificada exactamente como está escrita, esa desviación se documenta en el archivo en lugar de dejarse implícita
  • Rastreabilidad basada en UUID que vincula el ICD de proceso con el SSD y el ISD original a través de la entrada de encabezado SourceFiles

Los proveedores tienen dos opciones de implementación. Pueden mantener nombres propietarios mientras documentan el mapeo completo, maximizando la compatibilidad hacia atrás con las cadenas de herramientas existentes. Alternativamente, pueden importar el modelo de datos unificado de la especificación, adoptando los nombres exactamente como se especifican, lo que maximiza la interoperabilidad, a costa de un mayor trabajo de adaptación dentro de la TIC.

En la prueba de concepto (PoC) de Elia, Cedric Harispu demostró este paso utilizando Siemens DIGSI 5 con una unidad de fusión 6MU y un relé de protección de distancia 7SA87. DIGSI 5 reconoció automáticamente los dispositivos lógicos del ISD, gestionó el mapeo de LNode a LN, y generó archivos ICD de proceso para ambos dispositivos, incluyendo la creación de entradas de GOOSE que no formaban parte de la configuración predeterminada del dispositivo.

El resultado crítico: el ingeniero recibe una respuesta legible por máquina. Las discrepancias entre la especificación y la capacidad del proveedor son explícitas, rastreables y documentadas, no enterradas en un intercambio de correos electrónicos.

El ICD de proceso no es solo "la respuesta del proveedor". Está diseñado para permitir la verificación automatizada en el lado del usuario. Una vez recibido el ICD de proceso, la herramienta de configuración del sistema (SCT) puede comparar automáticamente la implementación del proveedor con la especificación original, marcando señales no mapeadas, desviaciones en nombres y vacíos en BehaviorDescription sin necesidad de inspección manual. Como declaró Thomas Sterckx: "este ICD de proceso también permite automatizar la etapa de validación en el lado del usuario — para validar lo que se ha recibido de un proveedor de IED."

Paso 5: Configuración del Sistema — Ensamblaje Automatizado del SCD

El ingeniero del sistema recibe archivos ICD de proceso de todos los proveedores e los importa en la herramienta de configuración del sistema (SCT). La SCT lee la información de mapeo del espacio de nombres 6-100 y automatiza el ensamblaje del SCD final.

Específicamente, la SCT:

  1. Crea instancias de IED a partir de las plantillas de ICD de proceso
  2. Resuelve las entradas SourceRef de la especificación en enlaces ExtRef concretos, utilizando los mapeos extRefUuid proporcionados por el proveedor
  3. Genera conjuntos de datos, bloques de control GOOSE y SMV, y parámetros de comunicación
  4. Marca cualquier señal no resuelta — donde un elemento de la especificación no fue cubierto en el ICD de proceso

En la prueba de concepto (PoC) de Elia, la importación de dos archivos ICD de proceso (unidad PIU y relé de protección de distancia de Siemens) en Helinks STS pobló una matriz GOOSE con suscripciones, generó bloques de control con conjuntos de datos para señales de posición y disparo, y produjo una configuración de comunicación completa — las 28 entradas ExtRef en la IED PIU se resolvieron automáticamente, y aparecieron bloques de control GOOSE donde antes no había ninguno.

Herramientas de SCT que admiten la importación de ICD de proceso y la resolución automática de enlaces SourceRef — como Tekvel Park — pueden realizar este ensamblaje con intervención manual mínima.

El grado de automatización en el Paso 5 es directamente proporcional a la calidad del trabajo realizado en los Pasos 1 a 4. Un ISD completo, un proceso ICD bien ejecutado con mapeo completo y una BehaviorDescription validada del Paso 3 hacen que el Paso 5 sea en gran medida automático. Cualquier brecha en esos archivos anteriores se traduce directamente en trabajo de configuración manual aquí.

Tras la exportación del SCD, el archivo se devuelve al fabricante del EID para la carga final del dispositivo. En la prueba de concepto (PoC) de Elia, el SCD se importó en DIGSI 5 y se verificó en un entorno de Siemens Digital Twin — dos dispositivos virtuales que confirmaron la recepción correcta de valores muestreados, el comportamiento de suscripción GOOSE y la coherencia de la nomenclatura del modelo de datos antes de tocar cualquier hardware físico.

Lo que esto cambia

La ingeniería top-down según IEC 61850 cambia tres aspectos para el ingeniero profesional. Los errores de especificación se detectan durante la fase de diseño — antes de las decisiones de adquisición, antes de los compromisos con los proveedores, antes de que cualquier hardware esté en el sitio. La interacción con los fabricantes de EID se vuelve estructurada: un ISD reemplaza los documentos PDF, un proceso ICD reemplaza las respuestas informales, y todo el intercambio es legible por máquina y rastreable. Y la selección de proveedores se vuelve verdaderamente competitiva: un ISD enviado a varios proveedores produce respuestas comparables y estructuradas que pueden evaluarse sobre méritos técnicos.

Thomas Sterckx de Elia lo expresó directamente: "Ahora puedes probar lo que has diseñado antes de que se implemente en un dispositivo. Se pueden identificar muchos errores potenciales mucho antes en el proceso de ingeniería."

Los estándares técnicos están publicados. La herramienta existe. El proceso de adquisición está en funcionamiento en Elia. El próximo artículo de esta serie examina cómo el formato ISD cambia el proceso de adquisición y licitación de EID en la práctica.

Fuentes

  1. Thomas Sterckx, Yannick Thiessoz, Jackson Moore, Cedric Harispu — Webinar de prueba de concepto de ingeniería top-down IEC 61850 (Grupo Elia, diciembre de 2023)
  2. Grupo Elia — Visión común para la ingeniería top-down IEC 61850 (2023)
  3. TR IEC 61850-90-30:2025 — Redes y sistemas de comunicación para la automatización de las empresas eléctricas — Parte 90-30: Guías para la ingeniería de sistemas IEC 61850
  4. TR IEC 61850-7-6:2024 (Ed. 2) — Guías para la gestión de sistemas y proyectos IEC 61850