Valeurs échantillonnées routables (R-SV) : la clé de la protection différentielle de ligne virtualisée

La comparaison du courant différentiel au cœur de la protection de ligne n’a pas changé en un siècle. Les phasors de courant provenant des deux extrémités de la ligne arrivent au relais ; l’algorithme déclenche si la somme vectorielle dépasse un seuil. Ce qui change — siècle après siècle — c’est le chemin de communication transportant ces mesures. En mars 2025, Salt River Project (SRP) a mis en service ce qui est, à ce jour, la première déploiement de production publié de protection différentielle de ligne virtualisée (87L) utilisant des Valeurs Échantillonnées routables sur un réseau WAN MPLS, avec ABB SSC600 servant à la fois de plateforme vPAC (virtual Protection and Control) et de plateforme CPC (Communication Point) distante. Le résultat remet en question l’hypothèse par défaut selon laquelle un chemin IP à large échelle implique une pénalité de performance : le système vPAC a atteint un temps de déclenchement moyen de 19,45 ms avec une plage normalisée de 26,9 % ((max−min)/moyenne), comparé à 20,74 ms et 34,2 % pour un relais microprocesseur conventionnel fonctionnant en série sur un canal fibre direct. Le relais virtualisé connecté au WAN était à la fois plus rapide et plus stable.

Le problème des Valeurs Échantillonnées locales pour la protection différentielle de ligne

L’IEC 61850-9-2 définit les Valeurs Échantillonnées (Sampled Values) comme des trames multicast Ethernet de couche 2. Dans le bus de processus du sous-station, la couche 2 assure une livraison déterministe et à faible latence à travers un VLAN sans surcharge de routage IP — exactement l’outil approprié pour le bus de processus. Mais l’architecture présente une contrainte stricte : un cadre de couche 2 ne peut pas traverser un routeur. Pour la protection différentielle de ligne, où les échantillons de courant doivent être échangés entre deux sous-stations physiquement séparées, ce n’est pas une limitation que l’on peut contourner ; c’est une limite architecturale catégorique.

L’industrie a abordé ce problème par plusieurs approches, dont aucune ne s’est bien adaptée au fil du temps :

IEEE C37.94 — TDM synchrone sur des canaux N×64 kbps, optimisé pour les liaisons courtes en fibre multimode (< 2 km). Déterministe et prévisible, mais limité en bande passante, contraint en distance et incompatible avec l’infrastructure IP qui domine désormais les déploiements WAN des services publics.

SONET/SDH — Réseau WAN commuté en circuits fournissant des canaux synchrones avec une latence prévisible. Fiable, mais la technologie est en déclin contrôlé à l’échelle mondiale. La plupart des opérateurs retirent les infrastructures TDM ; les nouvelles constructions SONET/SDH sont rares.

Encodages WAN propriétaires — SEL MIRRORED BITS® encode les signaux de protection sur une liaison série synchrone ; GE DLAN+ utilise la G.703 à débit complet (E1/T1, jusqu’à 2 Mbps) avec une structuration propriétaire ; les relais SIPROTEC 5 de Siemens utilisent l’Ethernet Gigabit combiné à PRP/HSR pour un canal 87L routable et redondant (qualifié de « DIP » — Differential IP — dans la source PAC World, bien que ce ne soit pas un nom de produit officiel de Siemens). Ces solutions sont éprouvées opérationnellement dans leurs écosystèmes respectifs, mais nécessitent des extrémités compatibles aux deux terminaisons de ligne et ne proposent aucun chemin vers l’interopérabilité multi-vendeurs.

Le problème structurel est identique dans toutes ces approches : elles échangent la transparence contre la fiabilité, la distance contre la déterminisme, ou la bande passante contre le verrouillage. Aucune d’entre elles ne s’adapte à une architecture de protection centralisée où une seule instance de CPC ou de vPAC termine simultanément plusieurs différentielles de ligne, et où le fournisseur de l’unité de fusion à une extrémité est indépendant du fournisseur de protection à l’autre.

R-SV : la solution standard (IEC 61850-90-5 → IEC 61850-8-1 Ed.2.1)

Échantillons routables (R-SV), définis dans l’IEC 61850-90-5 et intégrés normativement dans les amendements de l’édition 2.1 (IEC 61850-8-1 AMD1:2020 pour la cartographie session/sécurité et IEC 61850-9-2 AMD1:2020 pour les blocs de contrôle spécifiques aux SV), résout le problème de la frontière de la couche 2 en enveloppant le contenu standard des SV dans une pile IP/UDP avec une couche session supplémentaire. Trois couches sont ajoutées au PDU IEC 61850-9-2 :

• Couche réseau (IP) : une adresse multicast IP, permettant une livraison point-à-multipoint — une unité de fusion publie simultanément vers plusieurs abonnés vPAC ou CPC distants
• Couche transport (UDP) : livraison sans connexion, préservant la faible surcharge des SV
• Couche session (IEC 61850-90-5) : Identifiant de session (0xA2 pour R-SV), en-tête de session portant des métadonnées de sécurité, charge utile

Le cadre résultant est routable à travers toute infrastructure IP — réseaux MPLS privés, VPN MPLS, et en principe Internet public.

L’IEC 61850-9-2 AMD1:2020 a également officiellement déprécié le bloc de contrôle des SV unicast (USVCB) ; le multicast (MSVCB) est désormais le seul modèle de livraison SV pris en charge.

Clarté de la numérotation standard : L’IEC 61850-9-2 définit les échantillons locaux (couche 2) pour l’usage du bus de processus. L’IEC 61850-90-5 a défini les échantillons routables (couche 3), désormais intégrés dans les amendements de l’édition 2.1 : IEC 61850-8-1 AMD1:2020 (cartographie session et sécurité) et IEC 61850-9-2 AMD1:2020 (bloc de contrôle R-MSVCB et dépréciation de l’unicast). L’IEC 61850-9-3 définit le profil PTP Power pour la synchronisation temporelle de précision — il ne s’agit pas de R-SV et ne doit pas être confondu avec celui-ci. Cette distinction est souvent floue dans la documentation des fournisseurs et les articles de conférence.

graph LR
    subgraph local["SV local — IEC 61850-9-2 (seulement couche 2)"]
        direction TB
        LA["Application : Émetteur SV (MSVCB)"]
        LP["Présentation : ASN.1/BER"]
        LD["Liens de données : Ethernet (EtherType 0x88BA) + VLAN 802.1Q"]
        LF["Physique : 100/1000BASE-T/SX"]
        LA --> LP --> LD --> LF
    end

    subgraph rsv["R-SV — IEC 61850-90-5 / Ed.2 Am.1 (couche 3)"]
        direction TB
        RA["Application : Émetteur SV (MSVCB)"]
        RP["Présentation : ASN.1/BER"]
        RS["Session : 0xA2 + HMAC/AES (IEC 62351-6)"]
        RT["Transport : UDP"]
        RN["Réseau : Multicast IP"]
        RD["Liens de données : Ethernet"]
        RF["Physique : GbE / MPLS WAN"]
        RA --> RP --> RS --> RT --> RN --> RD --> RF
    end
    local~~~rsv

Modèle de synchronisation : Les approches basées sur TDM comme C37.94 et autres reposent sur la déterminisme du canal — le relais sait quel emplacement binaire contient quelle mesure. Le R-SV ne peut pas s’appuyer sur le déterminisme du réseau sur un WAN. À la place, chaque paquet R-SV contient une horodatage PTP/GPS (précision ±1 µs). La fonction de protection réceptrice aligne les échantillons provenant des deux terminaux de ligne selon l’horodatage plutôt que selon la position dans un flux synchrone. Cela rend l’algorithme tolérant aux fluctuations du WAN, au prix d’une nécessité de temps de haute qualité provenant de sources indépendantes aux deux terminaux. AMD1:2020 a formalisé cela à travers l’attribut smpSynch dans le MSVCB, qui indique l’état de synchronisation de chaque échantillon (non synchronisé, source locale ou source externe), permettant à l’abonné d’évaluer la fiabilité de l’horodatage avant de l’utiliser pour l’alignement des phasors.

La norme spécifie également une sécurité optionnelle : l’authentification HMAC et le chiffrement AES, avec distribution des clés via l’architecture GDOI/KDC conformément à l’IEC 62351-9. Pour les déploiements où le trafic SV traverse une infrastructure située en dehors du périmètre de sécurité physique de l’exploitant, cela devient une exigence architecturale, et non une mesure de renforcement optionnelle.

Architecture ABB SSC600 CPC / vPAC

L’ABB SSC600 n’est pas un relais numérique au sens conventionnel. Il s’agit d’un Contrôleur de traitement des communications (CPC) — une plateforme qui héberge des fonctions de protection en tant qu’instances logicielles, recevant les données de processus depuis des unités de fusion externes via le bus de processus, plutôt que depuis des entrées analogiques câblées directement. Dans le déploiement SRP, le SSC600 fonctionne en deux modes : en tant que CPC matériel au terminal distant, et en tant que machine virtuelle exécutée sur une paire de serveurs renforcés de sous-station (vPAC) au terminal local.

Plateforme matérielle : CPU quadricœur exécutant Linux temps réel, avec les tâches de protection isolées du HMI au niveau du planificateur. Un DSP dédié (TMS320C674x) gère la chaîne de traitement des phasors 87L, assurant un traitement déterministe indépendant de la charge de calcul générale. GNSS : u-blox F9 (GPS, Galileo, BeiDou ; sensibilité −160 dBm). Moteur PTP assisté matériellement fonctionne en mode horloge ordinaire et horloge maître. Performance temporelle : ±1 µs absolu, erreur d’alignement de la fenêtre de phasor < 4 µs, erreur de phase du phasor 0,11 mrad à 50 Hz — bien dans la marge de sécurité de 20 mrad du comparateur différentiel.

PRP (IEC 62439-3) : Chaque paquet 87L — un cadre R-SV UDP/IP envoyé toutes les 1 ms — est dupliqué et transmis simultanément sur deux réseaux indépendants (LAN A / LAN B). Le récepteur accepte le premier cadre arrivé ; la duplication est rejetée. La commutation est transparente : transition mesurée < 4 ms, satisfaisant la exigence ENTSO-E pour la détection de défaillance de canal. Configurations validées incluent les commutateurs Hirschmann RSP35 et Ruggedcom RSG2488.

SR-IOV et son importance pour la protection : Lorsque SSC600 fonctionne en tant que machine virtuelle (VM), l’accès standard à la carte réseau (NIC) via hyperviseur introduit une latence et une surcharge CPU qui entrent en conflit avec la fenêtre de traitement de protection. La chaîne de traitement du DSP 87L exige que les échantillons SV timestampés arrivent dans un délai < 50 µs afin de maintenir la cohérence des phasors sur la fenêtre de mesure. Les chemins NIC paravirtualisés standard (virtio) ne peuvent garantir cela sous charge. SR-IOV (Single Root I/O Virtualization — Intel X710 ou Mellanox ConnectX4 Lx) résout ce problème en partitionnant la carte réseau physique en fonctions virtuelles (Virtual Functions) attribuées directement au système d’exploitation invité via VFIO-PCI (KVM, noyau 6.6+ vfio-pci) ou VMware DirectPath I/O, contournant entièrement la voie de données de l’hyperviseur. Résultat mesuré : entrée 2,7 µs + sortie 3,2 µs (méthodologie RFC 2544), avec une réduction d’environ 38 % de la charge CPU à une densité de trafic SV de 100 Mbps. Sans SR-IOV, la marge de jitter d’entrée est violée sous charge SV, rendant l’architecture inadaptée à la protection en production.

Pilotage SRP : configuration et méthodologie d’essai

L’article PAC World Issue 074 rédigé par des ingénieurs de SRP (Heap, Sivesind) et ABB (Nunes) décrit la méthodologie d’essai et le déploiement sur le terrain. La ligne d’essai est un circuit de sous-transmission simulé de 3,14 miles (5 km), 69 kV (base 100 MVA) en Arizona.

Les deux extrémités connectent des unités de fusion pour traiter les interrupteurs de bus via des VLAN dédiés SV/GOOSE. Les unités de fusion publient à 4,8 kHz (80 échantillons par cycle à 60 Hz). L’extrémité locale (vPAC) exécute SSC600 en tant que VM sur une paire de serveurs redondants ; l’extrémité distante exécute un SSC600 CPC matériel. Les deux se connectent à l’infrastructure WAN via des ports PRP doubles.

graph LR
    subgraph local["Sous-station locale"]
        MU_L["Unité de fusion\n(SV 4,8 kHz)"]
        SW_L["Commutateur du bus de processus"]
        vPAC["SSC600 vPAC\n(VM + SR-IOV)"]
        MU_L -->|VLAN SV/GOOSE| SW_L
        SW_L -->|Bus de processus| vPAC
    end

    subgraph wan["WAN"]
        MPLS["VPN MPLS\nCouche 3 R-SV\nLAN PRP A / LAN PRP B"]
    end

    subgraph remote["Sous-station distante"]
        SW_R["Commutateur du bus de processus"]
        CPC["SSC600 CPC\n(Hardware)"]
        MU_R["Unité de fusion\n(SV 4,8 kHz)"]
        SW_R -->|Bus de processus| CPC
        MU_R -->|VLAN SV/GOOSE| SW_R
    end

    SW_L -->|PRP LAN A| MPLS
    SW_L -->|PRP LAN B| MPLS
    MPLS -->|PRP LAN A| SW_R
    MPLS -->|PRP LAN B| SW_R
    vPAC <-->|"87L R-SV (IEC 61850-90-5)"| CPC

Configuration de test : 5 000 événements de défaut simulés — défauts phase-terre, phase-phase et défauts triphasés soudés à plusieurs emplacements le long de la ligne. Trois topologies de communication ont été testées :

1. Back-to-back — connexion directe par fibre (référence)
2. MPLS VPLS — SV couche 2 sur pseudolien MPLS
3. MPLS VPN — R-SV couche 3 (IEC 61850-90-5) sur VPN MPLS

Un relais microprocesseur conventionnel a été exécuté sur la même ligne simulée en parallèle pour chaque itération de test, fournissant une référence directe de comparaison.

Résultats

Données d’activation globales issues de 5 000 événements de défaut (plage normalisée = (max−min)/moyenne) :

* Agrégé sur toutes les topologies vPAC (MPLS VPLS + MPLS VPN) sur 5 000 événements de défaut. Les valeurs min/max (16,85 ms, 22,09 ms) sont les extrêmes individuels d’activation, pas des moyennes de moyennes. La plage normalisée est calculée comme (maximum − minimum) / moyenne, selon la méthodologie source.

Temps d’activation moyens par topologie selon l’emplacement du défaut (Tableau 4 dans la source PAC World), chacun étant la moyenne de 500 itérations :

La répartition par topologie révèle que la topologie vPAC Layer 2 (VPLS) a été la plus rapide, avec une moyenne de 18,28 ms, tandis que la topologie vPAC Layer 3 (R-SV sur MPLS VPN) a atteint une moyenne de 19,35 ms — soit encore 1,39 ms plus rapide que la référence directe du relais à microprocesseur. Les deux topologies vPAC ont surpassé les deux topologies à microprocesseur à chaque emplacement de défaut. Le relais à microprocesseur a montré des performances presque identiques sur les chemins direct et MPLS (20,74 ms chacun).

Dans l’ensemble des configurations testées, le système vPAC a atteint un temps moyen total de déclenchement inférieur de 6,2 % et une plage normalisée inférieure de 7,3 points de pourcentage par rapport au relais à microprocesseur fonctionnant en mode direct. Cette différence directionnelle contredit le modèle intuitif selon lequel chaque saut WAN ajoute de la latence et de l’imprévisibilité.

L’explication la plus cohérente : la chaîne de traitement de phasors basée sur DSP du SSC600 et l’alignement des échantillons piloté par horodatage éliminent les retards fixes liés à la planification et au traitement inhérents aux architectures de relais à microprocesseur traditionnels. La redondance sans interruption PRP empêche les pics de latence dus aux interruptions momentanées de canal qui contribuent à la variance plus élevée des déploiements à chemin unique. L’algorithme de protection lui-même est le même — l’environnement d’exécution et l’architecture de communication sont meilleurs.

Le système est entré en service de production sur la ligne 69 kV de la SRP en mars 2025. À la date de publication de PAC World, aucune panne réelle n’était survenue dans le système en service, les données de premier déclenchement sur le terrain restant donc en attente.

Paysage des fournisseurs

R-SV est une norme ouverte. Le paysage actuel des fournisseurs s’étend des encodages WAN propriétaires à la conformité complète à la norme IEC 61850-90-5 :

†La source PAC World (Tableau 1) qualifie la communication 87L Ethernet de Siemens de « DIP (GigE PRP/HSR) » — une abréviation informelle pour « Differential IP ». Ce terme n’apparaît pas dans la documentation produit de Siemens ; Siemens commercialise cette capacité comme communication de protection série avec redondance PRP/HSR dans la plateforme SIPROTEC 5.

La trajectoire est claire : les solutions SEL, GE et Siemens sont opérationnellement matures, mais propriétaires dans des degrés variés, nécessitant des extrémités compatibles avec le même fournisseur aux deux terminaux. L’approche Siemens utilise un transport ouvert (GigE + PRP/HSR avec redondance IEC 62439) mais un encapsulage de données de protection propriétaire ; la source PAC World l’indique avec « verrouillage par fournisseur » comme limitation (Tableau 1). L’SSC600 d’ABB est la seule solution de cette comparaison conçue nativement selon la norme ouverte IEC 61850-90-5 R-SV, permettant en principe un avenir où les fournisseurs d’unités de fusion et de fonctions de protection peuvent être sélectionnés indépendamment et interopérer via R-SV. Le déploiement SRP est, à ce jour, la première preuve publiée que cette architecture est viable en production. La question de savoir si l’interopérabilité multi-fournisseur R-SV se maintient en pratique — à travers différentes implémentations de la couche Session et la négociation des paramètres de sécurité — reste séparée et non résolue.

Questions ouvertes

Interopérabilité entre fournisseurs : Le pilote SRP associe l’SSC600 vPAC d’ABB à l’SSC600 CPC d’ABB et à des unités de fusion fournies par ABB. Aucune donnée de test publiée n’existe concernant l’interopérabilité R-SV entre l’implémentation d’ABB et des unités de fusion provenant de SEL, GE ou Schneider Electric. Les tests de conformité IEC 61850 pour R-SV sont moins matures que pour GOOSE et SV local ; l’interprétation par les fournisseurs des paramètres de la couche Session a historiquement divergé dans les premières implémentations de normes.

Latence spécifique à la topologie : La source PAC World fournit les temps moyens de déclenchement par topologie et emplacement de défaut dans le Tableau 4, montrant que le vPAC a surpassé le relais microprocesseur sur toutes les voies de communication et emplacements de défaut. La topologie vPAC de couche 2 (VPLS) (moyenne 18,28 ms) était notablement plus rapide que la topologie de couche 3 (R-SV sur MPLS VPN) (moyenne 19,35 ms), une différence de 1,07 ms attribuable à l’encapsulation supplémentaire IP/UDP et au traitement de la couche Session. Cependant, les valeurs globales de min/max/étendue normalisée (19,45 ms, 26,9 %) rapportées dans la source reflètent la distribution globale de 5 000 événements sur les deux topologies vPAC et ne peuvent pas être décomposées en écarts individuels de topologie à partir des données publiées.

Performance en cas de défaut réel : La ligne 69 kV du SRP est entrée en service en mars 2025 sans aucun défaut système enregistré à la date de publication. Les 5 000 événements de défaut simulés fournissent une base d’ingénierie solide, mais le comportement du premier déclenchement dans des conditions réelles du réseau électrique — avec un comportement réel du réseau MPLS, des fluctuations réelles du WAN et des exigences réelles de coordination de protection — n’a pas encore été documenté.

LAN publique et 5G pour la protection 87L : L’article MDPI Energies (2022) a évalué la latence du R-GOOSE sur une infrastructure cellulaire 5G. Aucune donnée équivalente n’existe pour le R-SV dans les applications de protection différentielle de ligne sur des réseaux LTE ou 5G publics. Les déploiements industriels actuels utilisent des réseaux MPLS privés avec une gestion de la QoS et des SLA garantis. La question reste ouverte pour les ingénieurs : les infrastructures de télécommunication publiques peuvent-elles répondre aux exigences en matière de jitter, de disponibilité et de déterminisme pour la coordination des protections 87L — une question qui devient de plus en plus pertinente à mesure que les fournisseurs d’énergie examinent des architectures de protection centralisées et hébergées dans le cloud.

Profil normatif pour le R-SV dans la protection 87L : Les amendements de l’édition 2.1 (IEC 61850-8-1 et IEC 61850-9-2, tous deux AMD1:2020) ont intégré le R-SV principalement pour les applications de synchrophasors (PMU/PDC). Les exigences techniques spécifiques à la protection différentielle de ligne via le R-SV — jitter maximal admissible, fréquence d’échantillonnage minimale, classe de précision de l’horodatage, asymétrie maximale de canal — ne sont pas explicitement codifiées. Le projet pilote SRP démontre un ensemble de paramètres fonctionnels ; la généralisation à d’autres topologies réseau et architectures de coordination de protection nécessite une validation supplémentaire et éventuellement l’attention du TC57 WG10.

Cybersécurité dans les déploiements sur le terrain : L’IEC 62351-9 définit la gestion des clés GDOI/KDC pour l’authentification et le chiffrement du R-SV. L’article SRP ne précise pas si le chiffrement HMAC ou AES a été activé sur le système de production. La mise en œuvre d’une infrastructure KDC pour les systèmes de protection R-SV opérationnels reste rare, et les expériences publiées sur la cybersécurité du R-SV dans des environnements de production sont pratiquement absentes.

Sources

1. Heap B., Sivesind A. (Salt River Project), Nunes M. (ABB Switzerland). Protection différentielle de ligne virtualisée : libérer la puissance de la communication des valeurs échantillonnées routables, une approche redondante et à faible latence. PAC World Magazine, numéro 074.

2. Adamiak M. (Adamiak Consulting), Falk H. (Out of the Box Consulting), DuBose C. (PCLtek). Aperçu et applications des GOOSE et valeurs échantillonnées sécurisées routables. PAC World Magazine.

3. Architecture réseau pour la communication IEC61850-90-5 : Étude de cas sur l’évaluation du R-GOOSE sur 5G. Energies (MDPI), volume 15, numéro 11 (article 3915), 2022.

4. R-GOOSE / R-SV — Aperçu technique IEC 61850. Xelas Energy.