Most digital substation projects are single-vendor, single-site proofs of concept. RTE — the operator of France's 2,600-substation transmission grid — is doing something harder: building a fully digital, multi-vendor PACS from scratch, acting as its own system integrator, and scaling it across the network. The project is called R#SPACE. The first substation went live at Ploeren (63 kV, southern Brittany) in late 2023; as of early 2026, several more sites are in commissioning and the industrial ramp-up phase has begun.

What makes R#SPACE unusual is not just the technology. It is the operating model. RTE buys bay-level IEDs from one supplier, process interface devices from another, runs the HMI on an open-source virtualization platform it co-developed, and ties the station-level automation together with virtual PLCs in Docker containers. No single vendor owns the system. RTE does.

Here is the architecture, the vendor ecosystem, the testing realities, and the deployment roadmap — including the hard lessons that don't make it into vendor press releases.

Why RTE built R#SPACE

RTE's previous generation of PACS was a turn-key model: one vendor, one system, limited post-commissioning flexibility. Changing a substation-level function — say, adding a new voltage regulation scheme or updating the telecontrol gateway — meant going back to the original contractor. Costs were high and timelines long.

Three things pushed RTE to rethink the model:

  • The French grid is absorbing massive amounts of renewable generation. New monitoring requirements (LPIT interfaces via IEC 61869-9, advanced sensor data) cannot wait for the next full PACS refresh cycle.

  • Remote maintenance became a company-wide policy. The old architecture, with its vendor-specific tools and proprietary access methods, made centralized remote administration nearly impossible across a mixed fleet.

  • RTE had already tested the concept. The "Postes Intelligents" [9] demonstrator project — two fully digital IEC 61850 substations with process bus and station bus — proved the technology worked but exposed coordination gaps: LPIT phasor alignment issues, degraded-synchronization handling, and the complexity of multi-vendor SCL file management. R#SPACE was designed to fix what "Postes Intelligents" revealed.

The three-block architecture

R#SPACE organizes the PACS into three functional blocks. The split is deliberate — it separates what can be virtualized today from what still requires dedicated hardware.

flowchart TD
    subgraph SL["Substation Level (Virtualized)"]
        HMI["HMI / SCADA"]
        GW["Telecontrol &\nSupervision Gateway"]
        AUTO["Station-Level\nAutomatons"]
        CYBER["Cybersecurity\nServers"]
        STORE["Storage &\nConfiguration"]
    end

    subgraph NET["Network Level"]
        direction LR
        PROC["Process Network\n(Duplicated, PRP)\n+ PTP Sync"]
        ADMN["Dedicated\nAdmin LAN"]
        PROC ~~~ ADMN
    end

    subgraph BAY["Bay & Process Level"]
        direction LR
        BCU["Bay Control Units\n(Protection + Automation)"]
        SCU["Switchgear\nControl Units"]
        PIU["Process Interface Units"]
        SAMU["Stand-Alone\nMerging Units"]
        BCU ~~~ SCU
        PIU ~~~ SAMU
    end

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

Block 1 — Substation level. This runs on SEAPATH, the open-source virtualization platform RTE co-developed under LF Energy. SEAPATH uses KVM as the hypervisor, Corosync/Pacemaker for high availability, and libvirt for VM management. The virtualized functions include the local HMI, telecontrol gateway, cybersecurity servers, and station-level automatons. Those automatons — handling alarm calculation, voltage regulation, overload management — run as virtual PLCs inside Docker containers with a 10 ms cycle time, managing up to 30,000 I/Os and 60,000 variables [7].

Only functions with response time requirements above 100 ms are virtualized in Phase 1. Protection functions remain on dedicated hardware.

Block 2 — Network. A duplicated LAN with Parallel Redundancy Protocol (PRP) carries all traffic. PTP synchronization is broadcast through the PRP LAN. A separate physical LAN handles IED administration. The switching topology is straightforward: 2 central switches for substation-wide and common bay functions, plus 2 switches per bay connected to the central pair in a star.

graph TB
    subgraph Central["Central Switches"]
        CS1["Central Switch A\n(Substation-wide &\nCommon Bay)"]
        CS2["Central Switch B\n(Substation-wide &\nCommon Bay)"]
    end

    subgraph Bay3["Bay N"]
        B3S1["Bay N\nSwitch A"]
        B3S2["Bay N\nSwitch B"]
    end

    subgraph Bay2["Bay 2"]
        B2S1["Bay 2\nSwitch A"]
        B2S2["Bay 2\nSwitch B"]
    end


    subgraph Bay1["Bay 1"]
        B1S1["Bay 1\nSwitch A"]
        B1S2["Bay 1\nSwitch B"]
    end

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

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

Block 3 — Bay and process level. Bay Control Units (BCUs) host protection and bay-level automation. Process Interface Units (PIUs), Switchgear Control Units (SCUs), and Stand-Alone Merging Units (SAMUs) handle the interface to primary equipment. At the Ploeren pilot, 10 process-level IEDs were deployed on the process bus side alone [1].

Network segregation: VLANs

RTE chose VLAN-based traffic segregation over MAC address filtering. The rationale is scalability — MAC filters become unmanageable as bay counts grow. The VLAN structure looks like this:

  • Each bay gets its own SV and GOOSE VLANs, keeping high-rate sampled value traffic contained.

  • Inter-bay subscriptions — needed for busbar protection and interlocking — get separate VLANs.

  • PTP synchronization and MMS each get dedicated VLANs.

  • Quality of Service uses IEEE 802.1Q priority bits (0–7), configured per IED and described in the SCD file [2].

For a substation with 6 bays, that means 14 VLANs minimum: 6 × SV + 6 × GOOSE + 1 inter-bay SV + 1 inter-bay GOOSE (plus PTP and MMS). At scale, this is a serious network engineering effort — but it keeps SV multicast storms from propagating across bay boundaries.

RTE as system integrator

R#SPACE is multi-vendor by construction. RTE does not buy a turn-key system from a single contractor. Instead, it defines the interoperability framework — the IEC 61850 data models, Basic Application Profiles (BAPs), SCL templates, cybersecurity requirements — and purchases individual components to that specification. Different suppliers deliver BCUs, process interface IEDs, the HMI platform, and the station-level automation runtime. Some components are developed internally or collaboratively through open-source projects.

Engineers commissioning R#SPACE IED cubicles. Source: Straton

The interoperability framework goes beyond communication protocols. It covers operational interoperability (common data models, harmonized profiles, coordinated data quality management) and non-operational interoperability (top-down SCL configuration, standardized API-based IED administration, coordinated cybersecurity). Every PACS function is modeled as an IEC 61850 Logical Device, and settings are described using ING and ASG data object classes [2].

The scale of RTE's commitment shows in the procurement numbers. The eight-year frame agreement for bay-level IEDs starts with an initial batch of 41 BCUs and 92 PIUs. The maximum volumes written into the contract: 2,418 BCUs and 5,390 PIUs [3]. That is not a pilot program.

R#SPACE IED cubicles assembled for factory testing. Source: Efacec

Testing: what actually went wrong

The CIGRE paper on R#SPACE testing (Session 2024, SC B5) is unusually candid about the difficulties [4]. The testing pipeline has four stages:

  • conformance testing of individual components,

  • system qualification of the integrated PACS,

  • factory acceptance testing (FAT) by the assembly contractor,

  • and site acceptance testing (SAT).

RTE's test lab at the "Transfo" site near Lyon includes voltage/current injection racks, binary I/O panels, a real-time server with MMS/GOOSE/SV capabilities, and an IEC 60870-5-104 center emulator. Around 60% of system-level tests were automated using Python scripts.

Three findings stand out:

Most anomalies were per-IED, not inter-device. The expectation going in was that multi-vendor integration would be the primary source of problems. In practice, the majority of issues traced back to individual IED non-conformities — devices not fully implementing their own declared IEC 61850 profiles.

SCL convergence was painful. Getting the System Configuration Description file to a state where all vendors' tools could parse and import it took several weeks of back-and-forth between RTE's configuration team and the IED suppliers. This is a known IEC 61850 integration problem, but the multi-vendor context made it worse — each vendor's SCL tool had slightly different interpretations of edge cases.

Intermittent failures were the hardest to find. After the system passed all qualification tests, continuous monitoring detected random malfunctions: some IEDs would stop repeating GOOSE messages for extended periods, then resume. Characterizing the root cause took three months [4]. This is the kind of problem that single-vendor systems might never surface, because the vendor's test environment is too homogeneous.

The deployment roadmap

gantt
    title R#SPACE Deployment Timeline
    dateFormat  YYYY
    axisFormat  %Y

    section R&D
    Postes Intelligents demonstrators     :done, pi, 2014, 2017
    R#SPACE concept & specification       :done, spec, 2017, 2020

    section Development
    External & internal development       :done, dev, 2020, 2022
    Pre-integration & FAT                 :done, fat, 2022, 2023

    section Deployment
    Ploeren pilot (63 kV)                 :done, pilot, 2023, 2024
    +1 substation                         :done, y2024, 2024, 2025
    +3 substations planned                :active, y2025, 2025, 2026
    Industrial ramp-up                    :y2026, 2026, 2030
    Target 100 substations               :milestone, m1, 2030, 2030

The pace is deliberately cautious. One substation added in 2024, three more planned for 2025. The target is 100 substations running R#SPACE by 2030 [5] — roughly 4% of RTE's 2,600-substation fleet. Phase 1 covers smaller substations: single voltage level, limited bay count, primarily 63–90 kV. Phase 2 will address multi-voltage substations up to 400 kV with complex busbar topologies.

The SEAPATH platform, released under Apache 2.0 by LF Energy, has attracted contributors beyond RTE — National Grid Electricity Transmission and GE Vernova among them. Every code change must pass over 700 unit tests, real-time tests, and latency tests in CI [6]. That is an unusual level of rigor for an open-source OT project.

What R#SPACE means for the industry

Three aspects of this project deserve attention from engineers outside France.

The system integrator model works, but it is expensive. RTE essentially built an internal engineering capability that most utilities outsource entirely. The payoff is independence: RTE can swap vendors, add functions, and update individual components without renegotiating a turn-key contract. The cost is a permanent, specialized team covering IEC 61850 data modeling, SCL tooling, network design, virtualization, and cybersecurity. Not every TSO can afford this.

Open-source virtualization for substations is real. The SEAPATH platform is not a paper project. It runs production traffic at Ploeren. KVM, Corosync/Pacemaker, and Docker containers for station-level functions — this is a credible alternative to proprietary SCADA platforms, at least for functions where 100+ ms response times are acceptable. Whether the same approach can eventually host protection functions (sub-4 ms requirements) remains an open question.

Multi-vendor IEC 61850 integration is still hard. Despite two decades of interoperability testing events, SCL convergence took weeks, GOOSE repetition failures needed months to diagnose, and most bugs were per-IED conformance issues. R#SPACE is a reminder that the IEC 61850 standard enables interoperability — it does not guarantee it. The engineering effort to achieve it at scale is substantial.

RTE plans to share further operational experience through IEC TC57 WG10 and CIGRE B5 working groups. For the rest of us, the question is whether the R#SPACE model — TSO as integrator, open-source platform, vendor-neutral architecture — becomes the exception or the template.

Sources

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

[2] PAC World, "Towards an Industrial Deployment of Fully Digital PACS at RTE," Issue 74, 2024, https://www.pacw.org/towards-an-industrial-deployment-of-fully-digital-pacs-at-rte

[3] Efacec, "Efacec strengthens strategic contract with RTE for substation automation," https://www.efacec.com/news/efacec-strengthens-strategic-contract-with-rte-for-substation-automation/

[4] CIGRE Science & Engineering, No. 35, "Testing approach for RTE's R#SPACE Protection Automation and Control System," https://cse.cigre.org/cse-n035/b5-testing-approach-for-rtes-rspace-protection-automation-and-control-system.html

[5] LF Energy, "RTE Deploys LF Energy SEAPATH for Virtual Protection Automation and Control," https://lfenergy.org/rte-deploys-lf-energy-seapath-for-virtual-protection-automation-and-control/

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

[7] Straton, "RTE revolutionizes the management of French substations thanks to straton," https://straton-plc.com/en/rte-revolutionizes-the-management-of-french-substations-thanks-to-straton/

[8] Codra, "Distributed control system 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., "Design, Test & Commissioning — 'Postes Intelligents'," PAC World Magazine, September 2018, pp. 46–51.