La plupart des projets de sous-stations numériques sont des preuves de concept monovendeur, monolocalisées. RTE — l’opérateur du réseau de transport de 2 600 sous-stations en France — entreprend quelque chose de plus difficile : construire une PACS entièrement numérique, multi-vendeurs, à partir de zéro, en agissant lui-même en tant qu’intégrateur système, et la déployer à grande échelle sur le réseau. Ce projet s’appelle R#SPACE. La première sous-station est entrée en service à Ploeren (63 kV, Bretagne du sud) à la fin 2023 ; dès le début 2026, plusieurs autres sites sont en phase de mise en service et la phase de montée en puissance industrielle a commencé.

Ce qui rend R#SPACE inhabituel, ce n’est pas seulement la technologie. C’est le modèle opérationnel. RTE achète des EID (équipements d’interface de processus) au niveau baie chez un fournisseur, des dispositifs d’interface de processus chez un autre, exécute l’HMI sur une plateforme de virtualisation open-source qu’il a co-développée, et relie l’automatisation au niveau de la sous-station à l’aide de PLC virtuels dans des conteneurs Docker. Aucun fournisseur unique ne possède le système. RTE le possède.

Voici l’architecture, l’écosystème des fournisseurs, les réalités de test et la feuille de route du déploiement — y compris les leçons difficiles qui ne figurent pas dans les communiqués de presse des fournisseurs.

Pourquoi RTE a conçu R#SPACE

La génération précédente de PACS de RTE reposait sur un modèle clé en main : un seul fournisseur, un seul système, flexibilité limitée après la mise en service. Modifier une fonction au niveau de la sous-station — par exemple, ajouter un nouveau schéma de régulation de tension ou mettre à jour la passerelle de télécommande — impliquait de revenir vers l’entreprise initiale. Les coûts étaient élevés et les délais longs.

Trois éléments ont poussé RTE à repenser ce modèle :

  • Le réseau français absorbe une masse importante de production d’énergie renouvelable. De nouvelles exigences de surveillance (interfaces LPIT via IEC 61869-9, données de capteurs avancées) ne peuvent pas attendre le prochain cycle complet de rafraîchissement de la PACS.

  • La maintenance à distance est devenue une politique d’entreprise. L’ancienne architecture, avec ses outils spécifiques aux fournisseurs et ses méthodes d’accès propriétaires, rendait la gestion à distance centralisée presque impossible sur une flotte mixte.

  • RTE avait déjà testé le concept. Le projet démonstrateur « Postes Intelligents » [9] — deux sous-stations entièrement numériques IEC 61850 avec bus de processus et bus de station — a prouvé que la technologie fonctionnait, mais a mis en évidence des lacunes de coordination : problèmes d’alignement des phasors LPIT, gestion dégradée de la synchronisation, et la complexité de la gestion des fichiers SCL multi-vendeurs. R#SPACE a été conçu pour corriger ce que « Postes Intelligents » avait révélé.

L’architecture en trois blocs

R#SPACE organise la PACS en trois blocs fonctionnels. La séparation est volontaire — elle sépare ce qui peut être virtualisé aujourd’hui de ce qui nécessite encore du matériel dédié.

flowchart TD
    subgraph SL["Niveau de sous-station (virtualisé)"]
        HMI["HMI / SCADA"]
        GW["Passerelle de télécommande et de supervision"]
        AUTO["Automatons au niveau de la sous-station"]
        CYBER["Serveurs de cybersécurité"]
        STORE["Stockage et configuration"]
    end

    subgraph NET["Niveau réseau"]
        direction LR
        PROC["Réseau de processus\n(Dupliqué, PRP)\n+ Synchronisation PTP"]
        ADMN["LAN d'administration\ndédié"]
        PROC ~~~ ADMN
    end

    subgraph BAY["Niveau de baie et de processus"]
        direction LR
        BCU["Unités de contrôle de baie\n(Protection + Automatisation)"]
        SCU["Unités de contrôle de matériel de commutation"]
        PIU["Unités d'interface de processus"]
        SAMU["Unités de fusion indépendantes"]
        BCU ~~~ SCU
        PIU ~~~ SAMU
    end

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

Bloc 1 — Niveau de sous-station. Ce niveau fonctionne sur SEAPATH, la plateforme de virtualisation open-source développée conjointement par RTE dans le cadre de LF Energy. SEAPATH utilise KVM comme hyperviseur, Corosync/Pacemaker pour la haute disponibilité, et libvirt pour la gestion des machines virtuelles. Les fonctions virtualisées incluent l’HMI local, la passerelle de télécommande, les serveurs de cybersécurité et les automatons au niveau de la sous-station. Ces automatons — chargés du calcul des alarmes, de la régulation de tension et de la gestion des surcharges — s’exécutent en tant que PLC virtuels à l’intérieur de conteneurs Docker avec une période de cycle de 10 ms, gérant jusqu’à 30 000 entrées/sorties et 60 000 variables [7].

Seules les fonctions nécessitant des temps de réponse supérieurs à 100 ms sont virtualisées lors de la phase 1. Les fonctions de protection restent sur du matériel dédié.

Bloc 2 — Réseau. Un LAN dupliqué utilisant le protocole de redondance parallèle (Parallel Redundancy Protocol, PRP) transporte tout le trafic. La synchronisation PTP (Precision Time Protocol) est diffusée via le LAN PRP. Un LAN physique distinct gère l’administration des IED (intelligent electronic devices). La topologie de commutation est simple : deux commutateurs centraux pour les fonctions de sous-station et de baie communes, plus deux commutateurs par baie connectés en étoile aux deux commutateurs centraux.

graph TB
    subgraph Central["Commuteurs centraux"]
        CS1["Commutateur central A\n(Pour les fonctions de sous-station et de baie communes)"]
        CS2["Commutateur central B\n(Pour les fonctions de sous-station et de baie communes)"]
    end

    subgraph Bay3["Baie N"]
        B3S1["Commutateur de la baie N\nA"]
        B3S2["Commutateur de la baie N\nB"]
    end

    subgraph Bay2["Baie 2"]
        B2S1["Commutateur de la baie 2\nA"]
        B2S2["Commutateur de la baie 2\nB"]
    end

    subgraph Bay1["Baie 1"]
        B1S1["Commutateur de la baie 1\nA"]
        B1S2["Commutateur de la baie 1\nB"]
    end

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

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

Bloc 3 — Niveau de baie et de processus. Les unités de contrôle de baie (BCU) hébergent les fonctions de protection et d’automatisation au niveau de la baie. Les unités d’interface de processus (PIU), les unités de contrôle de matériel de commutation (SCU) et les unités de fusion indépendantes (SAMU) assurent l’interface avec l’équipement primaire. Lors du pilote de Ploeren, 10 IED de niveau processus ont été déployés uniquement du côté du bus de processus [1].

Ségrégation du réseau : VLANs

RTE a choisi la ségrégation du trafic basée sur les VLAN plutôt que le filtrage par adresse MAC. La raison en est l’évolutivité : les filtres MAC deviennent ingérables à mesure que le nombre de baies augmente. La structure des VLAN est la suivante :

  • Chaque baie dispose de ses propres VLAN SV et GOOSE, permettant de contenir le trafic à haute fréquence des valeurs échantillonnées.

  • Les abonnements inter-baies — nécessaires pour la protection de barre et les verrous — bénéficient de VLAN distincts.

  • La synchronisation PTP et MMS disposent chacune de VLAN dédiés.

  • La qualité de service utilise les bits de priorité IEEE 802.1Q (0–7), configurés par IED et décrits dans le fichier SCD [2].

Pour une sous-station de 6 baies, cela implique au minimum 14 VLANs : 6 × SV + 6 × GOOSE + 1 SV inter-baie + 1 GOOSE inter-baie (plus PTP et MMS). À grande échelle, il s’agit d’un effort sérieux d’ingénierie réseau — mais cela empêche les tempêtes de multicast SV de se propager au-delà des limites des baies.

RTE en tant qu’intégrateur système

R#SPACE est conçu pour être multi-fournisseur. RTE ne souscrit pas à un système clé en main auprès d’un seul contractant. À la place, il définit le cadre d’interopérabilité — les modèles de données IEC 61850, les Profils d’Application de Base (BAPs), les modèles SCL, les exigences de cybersécurité — et achète des composants individuels conformes à cette spécification. Différents fournisseurs livrent les BCUs, les IED d’interface de processus, la plateforme HMI et l’exécuteur d’automatisation au niveau de la sous-station. Certains composants sont développés en interne ou de manière collaborative via des projets open-source.

Ingénieurs effectuant la mise en service des armoires IED R#SPACE. Source : Straton

Le cadre d’interopérabilité va au-delà des protocoles de communication. Il couvre l’interopérabilité opérationnelle (modèles de données communs, profils harmonisés, gestion coordonnée de la qualité des données) ainsi que l’interopérabilité non opérationnelle (configuration top-down SCL, administration des IED basée sur des API standardisées, cybersécurité coordonnée). Chaque fonction PACS est modélisée comme un Logical Device IEC 61850, et les réglages sont décrits à l’aide des classes d’objets de données ING et ASG [2].

L’ampleur de l’engagement de RTE se reflète dans les chiffres des marchés. La commande-cadre de huit ans pour les IED de niveau baie commence par un premier lot de 41 BCUs et 92 PIUs. Les volumes maximums inscrits dans le contrat : 2 418 BCUs et 5 390 PIUs [3]. Ce n’est pas un programme pilote.

Armoires IED R#SPACE assemblées pour les tests en usine. Source : Efacec

Tests : ce qui s’est réellement mal passé

L’article CIGRE sur les tests de R#SPACE (Session 2024, SC B5) est exceptionnellement franc sur les difficultés rencontrées [4]. La chaîne de tests comporte quatre étapes :

  • tests de conformité des composants individuels,

  • qualification du système du PACS intégré,

  • essais d’acceptation en usine (FAT) effectués par l’entreprise d’assemblage,

  • et essais d’acceptation sur site (SAT).

Le laboratoire de test de RTE sur le site « Transfo » près de Lyon comprend des bancs d’injection de tension/courant, des panneaux d’entrées/sorties binaires, un serveur temps réel doté de capacités MMS/GOOSE/SV, ainsi qu’un émulateur central IEC 60870-5-104. Environ 60 % des tests au niveau du système ont été automatisés à l’aide de scripts Python.

Trois constats se démarquent :

La majorité des anomalies concernaient les IED individuellement, et non les interactions entre appareils. On s'attendait à ce que l'intégration multi-vendeurs soit la principale source de problèmes. En pratique, la majorité des incidents remontaient à des non-conformités individuelles des IED — des dispositifs ne mettant pas pleinement en œuvre leurs propres profils IEC 61850 déclarés.

La convergence du fichier SCL a été pénible. Il a fallu plusieurs semaines d’échanges entre l’équipe de configuration de RTE et les fournisseurs d’IED pour arriver à un état du fichier de description de configuration du système (System Configuration Description) que les outils de tous les vendeurs pouvaient parser et importer. Il s’agit d’un problème d’intégration connu avec IEC 61850, mais le contexte multi-vendeurs a aggravé la situation — chaque outil SCL du vendeur interprétait légèrement différemment les cas limites.

Les défaillances intermittentes ont été les plus difficiles à identifier. Après que le système ait passé tous les tests de qualification, une surveillance continue a détecté des dysfonctionnements aléatoires : certains IED cessaient de répéter les messages GOOSE pendant de longues périodes, puis reprenaient. L’identification de la cause racine a pris trois mois [4]. C’est le genre de problème que les systèmes mono-vendeurs pourraient ne jamais rencontrer, car l’environnement de test du vendeur est trop homogène.

La feuille de route du déploiement

gantt
    title Chronologie du déploiement de R#SPACE
    dateFormat  YYYY
    axisFormat  %Y

    section Recherche et développement
    Démonstrateurs de postes intelligents     :done, pi, 2014, 2017
    Concept et spécification de R#SPACE       :done, spec, 2017, 2020

    section Développement
    Développement externe et interne          :done, dev, 2020, 2022
    Pré-intégration et FAT                    :done, fat, 2022, 2023

    section Déploiement
    Pionnier de Ploeren (63 kV)               :done, pilot, 2023, 2024
    +1 sous-station                           :done, y2024, 2024, 2025
    +3 sous-stations prévues                  :active, y2025, 2025, 2026
    Montée en puissance industrielle           :y2026, 2026, 2030
    Objectif : 100 sous-stations              :milestone, m1, 2030, 2030

Le rythme est volontairement prudent. Une sous-station ajoutée en 2024, trois autres prévues pour 2025. L’objectif est de compter 100 sous-stations fonctionnant avec R#SPACE d’ici 2030 [5] — soit environ 4 % de la flotte de 2 600 sous-stations de RTE. La phase 1 couvre les sous-stations plus petites : un seul niveau de tension, un nombre limité de baies, principalement 63–90 kV. La phase 2 s’attaquera aux sous-stations multi-tensions jusqu’à 400 kV avec des topologies de barres complexes.

La plateforme SEAPATH, publiée sous licence Apache 2.0 par LF Energy, a attiré des contributeurs au-delà de RTE — notamment National Grid Electricity Transmission et GE Vernova. Chaque modification de code doit passer plus de 700 tests unitaires, des tests en temps réel et des tests de latence dans le CI [6]. C’est un niveau de rigueur inhabituel pour un projet logiciel open-source de type OT.

Ce que R#SPACE signifie pour l’industrie

Trois aspects de ce projet méritent l’attention des ingénieurs en dehors de la France.

Le modèle d’intégrateur système fonctionne, mais il est coûteux. RTE a essentiellement mis en place une capacité d’ingénierie interne que la plupart des fournisseurs d’électricité externalisent entièrement. L’avantage est l’indépendance : RTE peut changer de fournisseurs, ajouter des fonctions et mettre à jour des composants individuels sans renégocier un contrat clé en main. Le coût est un groupe spécialisé permanent couvrant la modélisation des données IEC 61850, les outils SCL, la conception de réseaux, la virtualisation et la cybersécurité. Tous les RTE ne peuvent pas se permettre cela.

La virtualisation open-source pour les postes de transformation est réelle. La plateforme SEAPATH n’est pas un projet théorique. Elle gère du trafic en production à Ploeren. KVM, Corosync/Pacemaker et des conteneurs Docker pour les fonctions au niveau du poste — il s’agit d’une alternative crédible aux plateformes SCADA propriétaires, du moins pour les fonctions où des temps de réponse de plus de 100 ms sont acceptables. La question demeure ouverte quant à savoir si cette approche pourra éventuellement héberger des fonctions de protection (exigeant des temps de réponse inférieurs à 4 ms).

L’intégration multi-fournisseurs selon IEC 61850 reste difficile. Malgré deux décennies d’événements de tests d’interopérabilité, la convergence SCL a pris des semaines, les échecs de répétition GOOSE ont nécessité des mois pour être diagnostiqués, et la plupart des bugs étaient liés à la conformité par IED. R#SPACE est un rappel que la norme IEC 61850 permet l’interopérabilité — elle ne la garantit pas. L’effort d’ingénierie nécessaire pour y parvenir à grande échelle est considérable.

RTE prévoit de partager davantage d’expériences opérationnelles via les groupes de travail IEC TC57 WG10 et CIGRE B5. Pour le reste d’entre nous, la question est de savoir si le modèle R#SPACE — RTE en tant qu’intégrateur, plateforme open-source, architecture neutre envers les fournisseurs — devient une exception ou un modèle.

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., « Conception, essais et mise en service — « Postes intelligents » », PAC World Magazine, septembre 2018, pp. 46–51.