RTE's R#SPACE: Cómo el TSO francés construyó un PACS industrial multi proveedor basado en IEC 61850

La mayoría de los proyectos de subestaciones digitales son prototipos de concepto de un solo proveedor y un solo sitio. RTE —el operador de la red de transmisión de 2.600 subestaciones de Francia— está haciendo algo más difícil: construir una PACS completamente digital y multi proveedora desde cero, actuando como integrador de sistemas propio, y escalándola a lo largo de la red. El proyecto se llama R#SPACE. La primera subestación entró en funcionamiento en Ploeren (63 kV, Bretaña meridional) a finales de 2023; a principios de 2026, varias otras ubicaciones se encuentran en fase de puesta en servicio y ha comenzado la fase de escalado industrial.

Lo que hace inusual a R#SPACE no es solo la tecnología. Es el modelo operativo. RTE compra dispositivos IED a nivel de bay de un proveedor, dispositivos de interfaz de proceso de otro, ejecuta la HMI en una plataforma de virtualización de código abierto que desarrolló conjuntamente, y conecta la automatización a nivel de subestación mediante PLCs virtuales en contenedores Docker. Ningún proveedor individual posee el sistema. RTE lo hace.

A continuación se presenta la arquitectura, el ecosistema de proveedores, las realidades de pruebas y la hoja de ruta de despliegue —incluyendo las lecciones difíciles que no aparecen en los comunicados de prensa de los proveedores.

Por qué RTE desarrolló R#SPACE

La generación anterior de PACS de RTE era de tipo llave en mano: un proveedor, un sistema, flexibilidad limitada tras la puesta en servicio. Cambiar una función a nivel de subestación —por ejemplo, añadir un nuevo esquema de regulación de tensión o actualizar la pasarela de telecontrol— significaba volver al contratista original. Los costos eran altos y los plazos largos.

Tres factores impulsaron a RTE a replantear el modelo:

• La red francesa está absorbiendo una gran cantidad de generación renovable. Nuevas exigencias de monitoreo (interfaz LPIT mediante IEC 61869-9, datos de sensores avanzados) no pueden esperar hasta el próximo ciclo completo de actualización de PACS.

• El mantenimiento remoto se convirtió en una política a nivel de empresa. La arquitectura antigua, con sus herramientas específicas de proveedor y métodos de acceso propietarios, hacía casi imposible la administración centralizada remota en una flota mixta.

• RTE ya había probado el concepto. El proyecto demostrador "Postes Intelligents" [9] —dos subestaciones completamente digitales IEC 61850 con bus de proceso y bus de estación— demostró que la tecnología funcionaba pero reveló brechas de coordinación: problemas de alineación de fasores LPIT, manejo de sincronización degradada y la complejidad de la gestión de archivos SCL multi proveedora. R#SPACE fue diseñado para corregir lo que "Postes Intelligents" reveló.

La arquitectura de tres bloques

R#SPACE organiza la PACS en tres bloques funcionales. La división es deliberada: separa lo que puede virtualizarse hoy de lo que aún requiere hardware dedicado.

flowchart TD
    subgraph SL["Nivel de Subestación (Virtualizado)"]
        HMI["HMI / SCADA"]
        GW["Puerta de enlace de telecontrol y supervisión"]
        AUTO["Autómatas de nivel de subestación"]
        CYBER["Servidores de ciberseguridad"]
        STORE["Almacenamiento y configuración"]
    end

    subgraph NET["Nivel de Red"]
        direction LR
        PROC["Red de proceso\n(Duplicada, PRP)\n+ Sincronización PTP"]
        ADMN["LAN dedicada de administración"]
        PROC ~~~ ADMN
    end

    subgraph BAY["Nivel de Bay y Proceso"]
        direction LR
        BCU["Unidades de control de bay\n(Protección + Automatización)"]
        SCU["Unidades de control de equipamiento de interruptores"]
        PIU["Unidades de interfaz de proceso"]
        SAMU["Unidades de fusión autónomas"]
        BCU ~~~ SCU
        PIU ~~~ SAMU
    end

    SL <--> NET
    NET <--> BAY

Bloque 1 — Nivel de subestación. Este funciona en SEAPATH, la plataforma de virtualización de código abierto desarrollada conjuntamente por RTE bajo LF Energy. SEAPATH utiliza KVM como hipervisor, Corosync/Pacemaker para alta disponibilidad y libvirt para la gestión de máquinas virtuales. Las funciones virtualizadas incluyen la HMI local, la puerta de enlace de telecontrol, los servidores de ciberseguridad y los autómatas de nivel de subestación. Estos autómatas —que gestionan el cálculo de alarmas, la regulación de voltaje y la gestión de sobrecargas— se ejecutan como PLCs virtuales dentro de contenedores Docker con un tiempo de ciclo de 10 ms, gestionando hasta 30.000 entradas/salidas y 60.000 variables [7].

Solo las funciones con requisitos de tiempo de respuesta superiores a 100 ms se virtualizan en la Fase 1. Las funciones de protección permanecen en hardware dedicado.

Bloque 2 — Red. Una LAN duplicada con Protocolo de Redundancia Paralela (PRP) transporta todo el tráfico. La sincronización PTP se transmite a través de la LAN PRP. Una LAN física separada gestiona la administración de los IED. La topología de conmutación es sencilla: 2 conmutadores centrales para funciones de subestación y bay comunes, más 2 conmutadores por bay conectados a la pareja central en forma de estrella.

graph TB
    subgraph Central["Conmutadores Centrales"]
        CS1["Conmutador Central A\n(De subestación y bay común)"]
        CS2["Conmutador Central B\n(De subestación y bay común)"]
    end

    subgraph Bay3["Bay N"]
        B3S1["Conmutador de Bay N\nA"]
        B3S2["Conmutador de Bay N\nB"]
    end

    subgraph Bay2["Bay 2"]
        B2S1["Conmutador de Bay 2\nA"]
        B2S2["Conmutador de Bay 2\nB"]
    end

    subgraph Bay1["Bay 1"]
        B1S1["Conmutador de Bay 1\nA"]
        B1S2["Conmutador de Bay 1\nB"]
    end

    CS1 --- B1S1
    CS1 --- B2S1
    CS1 --- B3S1

    CS2 --- B1S2
    CS2 --- B2S2
    CS2 --- B3S2

Bloque 3 — Nivel de bay y proceso. Las Unidades de Control de Bay (BCUs) alojan la protección y la automatización a nivel de bay. Las Unidades de Interfaz de Proceso (PIUs), las Unidades de Control de Equipamiento de Interruptores (SCUs) y las Unidades de Fusión Autónomas (SAMUs) gestionan la interfaz con el equipamiento primario. En la prueba piloto de Ploeren, se desplegaron 10 IED a nivel de proceso únicamente en el lado del bus de proceso [1].

Separación de red: VLANs

RTE optó por la segregación de tráfico basada en VLAN en lugar de filtrado por dirección MAC. La razón es la escalabilidad: los filtros MAC se vuelven inmanejables a medida que aumenta el número de bayas. La estructura de VLAN es la siguiente:

• Cada baya tiene sus propias VLAN de SV y GOOSE, manteniendo contenidos los tráficos de valores muestreados de alta tasa.

• Las suscripciones entre baya — necesarias para la protección de barra y el bloqueo interbaya — tienen VLAN separadas.

• La sincronización PTP y MMS cada una tienen VLAN dedicadas.

• La calidad de servicio utiliza los bits de prioridad IEEE 802.1Q (0–7), configurados por IED y descritos en el archivo SCD [2].

Para una subestación con 6 baya, eso significa un mínimo de 14 VLAN: 6 × SV + 6 × GOOSE + 1 SV interbaya + 1 GOOSE interbaya (además de PTP y MMS). A gran escala, esto representa un esfuerzo serio de ingeniería de red — pero evita que las tormentas multicast de SV se propaguen más allá de los límites de baya.

RTE como integrador de sistemas

R#SPACE está diseñado para ser multi-proveedor por naturaleza. RTE no compra un sistema llave en mano de un único contratista. En cambio, define el marco de interoperabilidad — los modelos de datos IEC 61850, Perfiles de Aplicación Básica (BAPs), plantillas SCL, requisitos de ciberseguridad — y adquiere componentes individuales según esa especificación. Diferentes proveedores entregan BCUs, IEDs de interfaz de proceso, la plataforma HMI y el runtime de automatización a nivel de estación. Algunos componentes se desarrollan internamente o de forma colaborativa a través de proyectos de código abierto.

El marco de interoperabilidad va más allá de los protocolos de comunicación. Cubre la interoperabilidad operativa (modelos de datos comunes, perfiles armonizados, gestión coordinada de la calidad de datos) y la interoperabilidad no operativa (configuración SCL de arriba abajo, administración de IED basada en API estandarizada, ciberseguridad coordinada). Cada función de PACS se modela como un Dispositivo Lógico IEC 61850, y los ajustes se describen utilizando las clases de objetos de datos ING y ASG [2].

La magnitud del compromiso de RTE se refleja en los números de adquisición. El acuerdo marco de ocho años para IEDs a nivel de baya comienza con un primer lote de 41 BCUs y 92 PIUs. Los volúmenes máximos establecidos en el contrato: 2.418 BCUs y 5.390 PIUs [3]. Esto no es un programa piloto.

Pruebas: ¿qué realmente salió mal?

El artículo de CIGRE sobre pruebas de R#SPACE (Sesión 2024, SC B5) es inusualmente sincero sobre las dificultades [4]. La cadena de pruebas tiene cuatro etapas:

• pruebas de conformidad de componentes individuales,

• calificación del sistema del PACS integrado,

• pruebas de aceptación en fábrica (FAT) realizadas por el contratista de ensamblaje,

• y pruebas de aceptación en sitio (SAT).

El laboratorio de pruebas de RTE en el sitio "Transfo" cerca de Lyon incluye bancos de inyección de voltaje/corriente, paneles de I/O binarios, un servidor en tiempo real con capacidades MMS/GOOSE/SV, y un emulador central de IEC 60870-5-104. Alrededor del 60% de las pruebas a nivel de sistema se automatizaron utilizando scripts de Python.

Tres hallazgos destacan:

La mayoría de las anomalías fueron por IED individual, no entre dispositivos. La expectativa inicial era que la integración multi-proveedor sería la principal fuente de problemas. En la práctica, la mayoría de las incidencias se remontaron a no conformidades individuales en los IED — dispositivos que no implementaban completamente sus propios perfiles declarados según IEC 61850.

La convergencia del SCL fue dolorosa. Llevar el archivo de Descripción de Configuración del Sistema a un estado en el que todas las herramientas de los proveedores pudieran analizarlo e importarlo requirió varias semanas de intercambio entre el equipo de configuración de RTE y los proveedores de IED. Este es un problema conocido de integración IEC 61850, pero el contexto multi-proveedor lo empeoró — cada herramienta SCL del proveedor tenía interpretaciones ligeramente diferentes de casos límite.

Las fallas intermitentes fueron las más difíciles de detectar. Después de que el sistema superara todas las pruebas de cualificación, la monitorización continua detectó fallos aleatorios: algunos IED dejaban de repetir mensajes GOOSE durante períodos prolongados, luego volvían a funcionar. La caracterización de la causa raíz llevó tres meses [4]. Este es el tipo de problema que los sistemas de un solo proveedor podrían nunca mostrar, porque el entorno de prueba del proveedor es demasiado homogéneo.

La hoja de ruta de despliegue

gantt
    title Cronograma de Despliegue de R#SPACE
    dateFormat  YYYY
    axisFormat  %Y

    section I+D
    Demostradores de Postes Inteligentes     :done, pi, 2014, 2017
    Concepto y especificación de R#SPACE       :done, spec, 2017, 2020

    section Desarrollo
    Desarrollo externo e interno       :done, dev, 2020, 2022
    Pre-integración y FAT                 :done, fat, 2022, 2023

    section Despliegue
    Piloto en Ploeren (63 kV)                 :done, pilot, 2023, 2024
    +1 subestación                         :done, y2024, 2024, 2025
    +3 subestaciones planeadas                :active, y2025, 2025, 2026
    Escalado industrial                    :y2026, 2026, 2030
    Meta de 100 subestaciones               :milestone, m1, 2030, 2030

El ritmo es deliberadamente cauteloso. Una subestación se añadió en 2024, tres más planeadas para 2025. La meta es que 100 subestaciones operen con R#SPACE para 2030 [5] — aproximadamente el 4% de la flota de 2.600 subestaciones de RTE. La Fase 1 abarca subestaciones más pequeñas: nivel de voltaje único, conteo limitado de bayas, principalmente entre 63–90 kV. La Fase 2 abordará subestaciones multi-voltaje hasta 400 kV con topologías de barras complejas.

La plataforma SEAPATH, lanzada bajo licencia Apache 2.0 por LF Energy, ha atraído colaboradores más allá de RTE — entre ellos National Grid Electricity Transmission y GE Vernova. Cada cambio de código debe superar más de 700 pruebas unitarias, pruebas en tiempo real y pruebas de latencia en CI [6]. Este es un nivel inusual de rigor para un proyecto de código abierto de OT.

Lo que R#SPACE significa para la industria

Tres aspectos de este proyecto merecen atención de los ingenieros fuera de Francia.

El modelo del integrador de sistemas funciona, pero es costoso. RTE prácticamente desarrolló una capacidad técnica interna que la mayoría de las empresas eléctricas subcontratan por completo. La ventaja es la independencia: RTE puede cambiar proveedores, añadir funciones y actualizar componentes individuales sin renegociar un contrato llave en mano. El costo es un equipo especializado permanente que cubre modelado de datos IEC 61850, herramientas SCL, diseño de red, virtualización y ciberseguridad. No todas las TSO pueden permitirse esto.

La virtualización de código abierto para subestaciones es real. La plataforma SEAPATH no es un proyecto teórico. Funciona con tráfico de producción en Ploeren. KVM, Corosync/Pacemaker y contenedores Docker para funciones a nivel de subestación — esta es una alternativa creíble a las plataformas SCADA propietarias, al menos para funciones donde se aceptan tiempos de respuesta de más de 100 ms. Si el mismo enfoque puede eventualmente alojar funciones de protección (requerimientos inferiores a 4 ms) sigue siendo una pregunta abierta.

La integración multi-proveedor de IEC 61850 sigue siendo difícil. A pesar de dos décadas de eventos de pruebas de interoperabilidad, la convergencia SCL tardó semanas, los fallos de repetición GOOSE necesitaron meses para diagnosticarse, y la mayoría de los errores fueron problemas de conformidad por IED. R#SPACE es un recordatorio de que el estándar IEC 61850 permite la interoperabilidad; no la garantiza. El esfuerzo de ingeniería para lograrla a escala es considerable.

RTE planea compartir más experiencias operativas a través de los grupos de trabajo IEC TC57 WG10 y CIGRE B5. Para el resto de nosotros, la pregunta es si el modelo R#SPACE — TSO como integrador, plataforma de código abierto, arquitectura neutral a proveedores — se convierte en la excepción o en la plantilla.

Fuentes

[1] SCLE, "RTE R#SPACE: Estación piloto de Ploeren," https://scle.fr/en/cas-client/rte-rspace-ploeren-pilot-station/

[2] PAC World, "Hacia una implementación industrial de PACS completamente digitales en RTE," Número 74, 2024, https://www.pacw.org/towards-an-industrial-deployment-of-fully-digital-pacs-at-rte

[3] Efacec, "Efacec refuerza su contrato estratégico con RTE para automatización de subestaciones," https://www.efacec.com/news/efacec-strengthens-strategic-contract-with-rte-for-substation-automation/

[4] CIGRE Science & Engineering, No. 35, "Enfoque de pruebas para el Sistema de Automatización y Control de Protección R#SPACE de RTE," https://cse.cigre.org/cse-n035/b5-testing-approach-for-rtes-rspace-protection-automation-and-control-system.html

[5] LF Energy, "RTE despliega SEAPATH de LF Energy para automatización y control virtual de protección," https://lfenergy.org/rte-deploys-lf-energy-seapath-for-virtual-protection-automation-and-control/

[6] Proyecto SEAPATH, https://seapath.energy/

[7] Straton, "RTE revoluciona la gestión de subestaciones francesas gracias a Straton," https://straton-plc.com/en/rte-revolutionizes-the-management-of-french-substations-thanks-to-straton/

[8] Codra, "Sistema de control distribuido R#SPACE," https://codra.net/en/news/2020/08/distributed-control-system-rspace/

[9] V. Astier, V. Leitloff, T. Babagana, A. Kurtz Bui, et al., «Diseño, Prueba y Puesta en Marcha — «Subestaciones Inteligentes»», PAC World Magazine, septiembre de 2018, págs. 46–51.