R-GOOSE et R-SV : quand IEC 61850 sort du poste

Dans l'IEC 61850, GOOSE est devenu l'un des mécanismes-clés d'échange rapide entre équipements électroniques intelligents. C'est GOOSE qui permet aux IED de protection, aux automatismes, aux contrôleurs de tranche et autres IED d'échanger des événements : actuations de protection, verrouillages, positions des organes de coupure, ordres de déclenchement, etc.

Mais le GOOSE classique a une limitation architecturale fondamentale : c'est un message de couche liaison Ethernet. Il fonctionne parfaitement à l'intérieur d'un réseau local de poste, mais n'est pas conçu pour être routé à travers des réseaux IP classiques.

Lorsque l'échange doit être organisé non seulement à l'intérieur d'un poste, mais entre objets distants du système électrique, le besoin d'un autre mécanisme apparaît — Routable GOOSE, ou R-GOOSE.

GOOSE classique : rapide, local, à l'intérieur du poste

GOOSE fonctionne selon le modèle publisher/subscriber : un équipement publie le message, et un ou plusieurs équipements abonnés l'utilisent.

Usages typiques de GOOSE :

• transmission de signaux de déclenchement ;
• verrouillages entre IED ;
• défaillance disjoncteur, protection de jeux de barres, transfert automatique de la source ;
• échange des positions de disjoncteurs et de sectionneurs ;
• etc.

Le principal atout de GOOSE est sa grande rapidité et une « surcouche » protocolaire minimale. Le message est transmis directement par Ethernet, au niveau L2. Cela rend GOOSE adapté aux tâches où les millisecondes comptent.

Mais c'est aussi sa limite : le GOOSE ordinaire ne se route pas à travers les réseaux IP. Son champ naturel d'application est le réseau technologique local du poste.

Pourquoi R-GOOSE est apparu

À mesure que les postes numériques évoluaient, il est devenu clair que ce type d'échange est nécessaire au-delà d'un seul objet.

Sont apparues des tâches dans lesquelles le message doit être transmis d'un nœud du système électrique à un autre, ou simultanément à plusieurs nœuds distants :

• téléaction de déclenchement / téléaccélération ;
• verrouillages inter-sites ;
• schémas spéciaux de protection (SPS) ;
• etc.

Pour de tels scénarios, l'Ethernet local ne suffit plus. Il faut pouvoir transmettre des événements par des réseaux IP, y compris l'infrastructure WAN de l'exploitant.

C'est précisément là qu'apparaît le Routable GOOSE — GOOSE routable.

Qu'est-ce que R-GOOSE

R-GOOSE est l'évolution de l'idée GOOSE pour les réseaux IP. Si le GOOSE classique travaille au niveau Ethernet, R-GOOSE ajoute la possibilité de transmettre via une infrastructure IP routable.

Pour simplifier :

GOOSE — pour l'échange rapide à l'intérieur du réseau local du poste. R-GOOSE — pour l'échange par réseau IP entre objets distants.

Dans l'IEC 61850, les variantes routables de GOOSE et de Sampled Values permettent d'utiliser le modèle publisher/subscriber non seulement à l'intérieur d'un seul réseau local, mais sur une infrastructure réseau plus large.

Important : R-GOOSE n'est pas « GOOSE qui va simplement plus loin ». C'est un autre contour d'ingénierie : routage IP, multicast, latence, gigue, QoS, tolérance aux pannes, cybersécurité et gestion de clés.

Et qu'est-ce que R-SV

Avec R-GOOSE, un second profil est aussi étudié — Routable Sampled Values, ou R-SV.

La logique est similaire. Les Sampled Values ordinaires sont transmis sur un réseau local, par exemple sur le bus de process d'un poste numérique. Mais certaines tâches exigent de transmettre les données sur de grandes distances.

Cela concerne d'abord les tâches liées aux mesures synchrophaseurs et aux fonctions distribuées de protection et d'automatisme. Si GOOSE et R-GOOSE sont avant tout des événements, alors SV et R-SV sont des mesures, transmises périodiquement.

Autrement dit :

R-GOOSE — événements routables. R-SV — données de mesure en flux ou périodiques, routables.

En pratique, R-GOOSE est nettement plus discuté et utilisé, car les scénarios de transmission distante d'événements — téléaction, verrouillages, schémas spéciaux de protection — sont plus nombreux et plus parlants pour les tâches appliquées de protection et d'automatisme.

Exemple 1. Téléaction de déclenchement à la place d'un sectionneur de mise à la terre

L'un des scénarios emblématiques d'application de R-GOOSE est l'envoi d'un ordre de téléaction de déclenchement à la place de l'utilisation d'un sectionneur de mise à la terre.

Dans les schémas traditionnels, sur des postes en antenne ou sur certaines travées, un sectionneur de mise à la terre peut être utilisé. Son rôle est de provoquer un court-circuit contrôlé pour que la protection côté source voie de manière fiable le défaut et déclenche la ligne.

Cette approche fonctionne, mais d'un point de vue ingénierie elle paraît assez brutale : pour isoler la section en défaut, on crée en pratique un court-circuit supplémentaire sur le réseau.

R-GOOSE permet d'aborder la même tâche autrement. Au lieu de créer un court-circuit artificiel, on peut transmettre un signal de téléaction au disjoncteur visé ou à un groupe de disjoncteurs par un réseau routable.

C'est particulièrement important dans les réseaux de distribution avec une part croissante de production décentralisée. Lors d'un court-circuit, le creux de tension affecte non seulement le départ en défaut, mais aussi les travées voisines. Plus le défaut persiste, plus le risque de déclenchement intempestif de consommateurs sensibles ou d'installations de production décentralisée augmente.

Une téléaction de déclenchement rapide permet de réduire la durée du creux de tension et de limiter l'impact du défaut sur les parties adjacentes du réseau. Autrement dit, R-GOOSE ici n'est pas intéressant comme « un nouveau protocole pour le protocole », mais comme un moyen d'implémenter une logique de déclenchement plus propre et plus rapide sans créer de court-circuit supplémentaire.

Exemple 2. Schémas spéciaux de protection (SPS)

Le deuxième scénario important, ce sont les schémas spéciaux de protection.

Ces schémas opèrent souvent non au sein d'un seul poste, mais à l'échelle d'une portion de réseau ou du système électrique. Pour prendre la décision, ils peuvent avoir besoin de signaux provenant de différents points : état des lignes, surcharges, état de la production, position des disjoncteurs, événements de défaut, paramètres du régime.

Dans ces tâches, il importe non seulement de recevoir le signal, mais de le livrer dans un temps imparti. Si l'événement s'est produit sur un site et que l'action de commande doit être exécutée sur un autre, le GOOSE local ordinaire ne suffit plus.

R-GOOSE peut être utilisé comme transport pour un échange d'événements rapide entre objets de SPS. Par exemple :

• transmission du fait de déclenchement d'une ligne ;
• envoi d'un ordre de délestage de charge ;
• envoi d'un ordre de limitation de production ;
• déclenchement d'une action de commande pré-définie ;
• échange de signaux entre plusieurs nœuds d'un schéma SPS.

Dans de tels systèmes, les exigences en termes de latence, de redondance des canaux, de cybersécurité et de diagnostic sont particulièrement importantes. On ne peut pas se contenter de dire : « le message passe par IP, donc tout fonctionne ». Il faut prouver que le réseau garantit le temps de livraison requis en régime normal, en cas de défaillances et lors de bascules de routes.

Exemple 3. Mesures synchrophaseurs

Un autre domaine d'application des profils routables de l'IEC 61850 est la transmission des données de mesures synchrophaseurs.

Les mesures synchrophaseurs sont importantes pour la supervision distribuée, l'analyse de stabilité, la conduite des régimes et la construction de systèmes WAMS/WAMPAC. Contrairement aux messages porteurs d'événements, ces données sont transmises périodiquement et doivent être horodatées avec précision.

D'un point de vue ingénierie, il existe une différence importante par rapport à la téléaction ou aux SPS. Pour la supervision, la latence de livraison en elle-même peut ne pas être aussi critique, à condition que chaque valeur porte un horodatage correct. Le système peut rassembler les données de différents équipements pour le même instant, puis effectuer l'analyse.

Mais si les données synchrophaseurs sont utilisées non seulement pour la supervision, mais pour un automatisme rapide, la latence redevient un paramètre critique. Dans ce cas, il faut prendre en compte non seulement la précision du temps, mais aussi le temps de livraison, la gigue, les pertes de paquets et le comportement du système en cas de dégradation des canaux de communication.

Couche réseau : L2 vs L3

D'un point de vue ingénierie, la principale différence entre GOOSE et R-GOOSE est la couche réseau.

GOOSE est adapté là où tout se passe à l'intérieur d'un seul réseau technologique. R-GOOSE est nécessaire là où la fonction sort des limites d'un seul poste et doit travailler à travers une infrastructure routable.

Sécurité : pourquoi Secure R-GOOSE compte plus que simplement R-GOOSE

Lorsque GOOSE reste à l'intérieur du réseau technologique isolé du poste, la sécurité reste importante : VLAN, contrôle d'accès, segmentation et autres mesures.

Mais lorsque le message sort des limites d'un poste, la question de la sécurité devient centrale.

Pour R-GOOSE et R-SV, il faut prendre en compte :

• l'authentification de la source du message ;
• l'intégrité des données ;
• la protection contre l'usurpation ;
• la protection contre la rediffusion d'anciens messages ;
• la gestion des clés ;
• la segmentation des zones réseau ;
• les pare-feux et les règles de routage ;
• la surveillance des anomalies ;
• la vérification du comportement en cas de perte de communication et de dégradation du canal.

Dans le réseau local du poste, un GOOSE publié par erreur peut déjà entraîner des conséquences graves. Dans un réseau inter-sites, le coût de l'erreur est encore plus élevé : le message peut déclencher des coupures, des actions de protection spéciales ou des changements de régime simultanément sur plusieurs sites.

C'est pourquoi R-GOOSE ne peut pas être considéré indépendamment des questions de cybersécurité.

Pourquoi le multicast exige un modèle de protection particulier

Pour la communication client-serveur classique, on peut utiliser le schéma habituel : client, serveur, TLS, certificats.

Mais GOOSE, R-GOOSE, SV et R-SV fonctionnent selon une autre logique. C'est du publisher/subscriber et du multicast. Un seul message peut être destiné à plusieurs abonnés à la fois.

Le modèle de sécurité doit donc aussi prendre en compte la communication de groupe. Il faut définir :

• qui a le droit de publier le flux ;
• qui a le droit de le recevoir ;
• quels équipements composent le groupe d'abonnés ;
• comment les clés sont distribuées ;
• à quelle fréquence elles sont renouvelées ;
• ce qui se passe en cas de compromission d'un équipement ;
• comment retirer un équipement du groupe ;
• comment diagnostiquer un échec d'abonnement dû à des problèmes de sécurité.

Dans les grands systèmes, sans gestion centralisée des clés, ce schéma devient rapidement ingérable. C'est pourquoi, pour les profils routables sécurisés, l'infrastructure de gestion des clés et des politiques d'accès joue un rôle important.

KDC : pourquoi il est nécessaire dans Secure R-GOOSE et Secure R-SV

Quand on parle de R-GOOSE et R-SV sécurisés, il importe de comprendre : il ne s'agit pas seulement du routage des messages par un réseau IP. Il s'agit de communication de groupe sécurisée.

GOOSE, R-GOOSE, SV et R-SV fonctionnent selon le modèle publisher/subscriber. Un équipement publie le flux, et plusieurs équipements peuvent en être abonnés. Ce n'est pas le schéma classique « client — serveur », où deux participants établissent une connexion sécurisée entre eux. Ici, une seule source doit transmettre le message en toute sécurité à un groupe de destinataires.

C'est précisément pour cela qu'apparaît la notion de Security Group — groupe de sécurité. Y entrent le publisher et tous les subscribers qui ont le droit de recevoir un flux donné.

Par exemple, pour un flux Sampled Values, ce groupe peut comprendre :

• l'équipement publisher, par exemple un merging unit (SAMU) ;
• tous les abonnés qui utilisent cet ensemble de mesures ;
• l'infrastructure chargée de vérifier les participants et de délivrer les clés.

Pour R-GOOSE la logique est la même : le groupe inclut l'équipement qui publie l'événement et tous les abonnés qui doivent le recevoir et l'utiliser dans leur logique.

Pour que tous les participants d'un tel groupe puissent vérifier l'authenticité des messages et, si nécessaire, les déchiffrer, il leur faut une clé symétrique commune. L'équipement ou la fonction qui distribue cette clé aux membres du groupe s'appelle KDC — Key Distribution Center, c'est-à-dire centre de distribution de clés.

flowchart TB
    subgraph PKI["Infrastructure de confiance"]
        PKIICON["🏛️ PKI<br/>émission et révocation des certificats"]
    end

    KDC["<b>🔐 KDC</b><br/><i>Key Distribution Center</i><br/>• vérification des certificats<br/>• politique du groupe<br/>• émission de clés symétriques<br/>• rotation (typiquement 24 h)<br/>• KDA — Key Delivery Assurance"]

    PKIICON -. certificats .-> KDC

    subgraph SG["Security Group · flux R-GOOSE / R-SV"]
        direction LR
        PUB["<b>Publisher</b><br/>p. ex. MU / IED / contrôleur SPS"]
        SUB1["Subscriber 1<br/>IED sur un poste distant"]
        SUB2["Subscriber 2<br/>équipement SPS"]
        SUB3["Subscriber N<br/>WAMS / centre de conduite"]
        PUB ==>|"R-GOOSE / R-SV<br/>multicast"| SUB1
        PUB ==>|" "| SUB2
        PUB ==>|" "| SUB3
    end

    KDC -. "<b>PUSH</b><br/>rotation<br/>centralisée de clé" .-> PUB
    KDC -. " " .-> SUB1
    KDC -. " " .-> SUB2
    KDC -. " " .-> SUB3
    SUB1 -. "<b>PULL</b><br/>après redémarrage<br/>ou désynchronisation" .-> KDC

    NOTE["<b>Ce qui est délivré</b><br/>• clé courante<br/>• clé suivante + heure d'activation<br/>• politique : algorithme MAC, chiffrement, période de rotation"]
    KDC -.-> NOTE

    style KDC fill:#FDE8E8,stroke:#F56C6C,color:#B71C1C
    style PUB fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style SUB1 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style SUB2 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style SUB3 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style PKIICON fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style NOTE fill:#F4F6FB,stroke:#9aa6c8,color:#3a4566

Pourquoi une clé symétrique

Dans R-GOOSE/R-SV sécurisés, l'authentification et le contrôle d'intégrité du message sont obligatoires. La confidentialité — c'est-à-dire le chiffrement du contenu — peut être appliquée en complément.

L'authentification s'effectue par le calcul d'une signature cryptographique particulière du message — Message Authentication Code, ou MAC. Certaines descriptions utilisent le terme HMAC, lorsque la signature s'appuie sur un algorithme de hachage.

La logique est la suivante :

1. Le publisher compose le message.
2. Un hash cryptographique est calculé sur le contenu du message.
3. Ce hash est protégé à l'aide d'une clé symétrique.
4. Le destinataire reçoit le message et recalcule lui-même le hash selon les mêmes règles.
5. Si la valeur calculée coïncide avec celle reçue, le message est considéré comme authentique et non modifié.

Autrement dit, l'abonné peut vérifier que le message provient bien d'un membre du groupe et n'a pas été altéré en chemin.

Si le chiffrement est utilisé, le même matériel de clé de groupe protège la charge utile du message. Important : on ne chiffre pas l'intégralité du message, mais justement le payload, pour que l'infrastructure réseau puisse traiter les en-têtes nécessaires.

Ce que fait exactement le KDC

Le KDC remplit plusieurs tâches.

Premièrement, il vérifie si l'équipement a le droit d'être membre du groupe de sécurité. Pour cela, des certificats numériques sont utilisés. Les membres du groupe et le KDC lui-même doivent disposer de certificats de confiance, et l'authenticité d'un participant est vérifiée via une infrastructure à clé publique — PKI.

Deuxièmement, le KDC distribue des clés symétriques aux membres du groupe. Ces clés sont nécessaires pour l'authentification des messages et, si le chiffrement est activé, pour protéger la charge utile.

Troisièmement, le KDC gère la politique de sécurité du groupe. La politique peut définir :

• quel algorithme MAC est utilisé pour former la signature cryptographique ;
• quel algorithme de chiffrement est appliqué, si le chiffrement est activé ;
• à quelle fréquence la clé doit être renouvelée ;
• si un mécanisme de confirmation de livraison des clés est utilisé ;
• quand la nouvelle clé doit entrer en vigueur.

Quatrièmement, le KDC est responsable du changement périodique des clés. Plus une même clé est utilisée longtemps dans le système, plus le risque de compromission augmente. Les clés doivent donc être renouvelées régulièrement. Les descriptions des profils routables sécurisés citent 24 heures comme période typique de rotation. Dans le même temps, on peut délivrer aux membres la clé courante et la suivante, ce qui donne une marge pour un basculement sécurisé.

PUSH et PULL : deux modes de distribution des clés

La livraison des clés du KDC aux membres du groupe peut s'effectuer de deux façons : PULL et PUSH.

En mode PULL, l'équipement demande lui-même la clé au KDC. Cela est nécessaire, par exemple, au démarrage de l'équipement, en cas de désynchronisation des clés, ou si l'équipement n'a pas pu recevoir correctement la clé envoyée précédemment. Avant de délivrer la clé, le KDC vérifie le certificat de l'équipement et son droit d'appartenance au groupe de sécurité correspondant.

En mode PUSH, le KDC diffuse lui-même la nouvelle clé aux membres du groupe. Ce mode est utile pour les mises à jour centralisées des clés, notamment dans les grands systèmes où la gestion manuelle des clés devient irréalisable.

En pratique, les deux mécanismes sont importants. PULL permet à l'équipement de se rétablir après un redémarrage ou des problèmes de clés. PUSH permet au KDC d'effectuer de façon centralisée la rotation régulière des clés pour tout le groupe.

Key Delivery Assurance : pourquoi on ne peut pas simplement « changer la clé »

Dans un système IT classique, l'échec d'une mise à jour de clé peut entraîner la perte d'accès à un service. Dans le système électrique, les conséquences peuvent être bien plus graves : si une partie des équipements n'a pas reçu la nouvelle clé, ils peuvent cesser d'accepter les messages critiques R-GOOSE ou R-SV.

Pour les fonctions de téléaction ou de SPS, cela est inacceptable. Le changement de clés ne doit pas bloquer le fonctionnement de la fonction principale.

C'est pourquoi le mécanisme KDA — Key Delivery Assurance est utilisé. Son sens est que le KDC peut contrôler la bonne livraison de la clé aux membres du groupe. Si la nouvelle clé a bien été livrée à un pourcentage défini de membres, le KDC envoie au publisher l'information autorisante, après quoi le publisher peut basculer sur la nouvelle clé au moment prévu.

Autrement dit, KDA sert à éviter que la rotation des clés ne devienne la cause d'une défaillance d'une fonction technologique.

Clé courante et clé suivante

Détail pratique important : on peut délivrer simultanément deux clés aux membres — la courante et la suivante.

Cela permet de préparer les équipements à l'avance au changement de clé. Le message indique non seulement l'information de clé courante, mais aussi le moment où la clé suivante doit devenir active. Grâce à cela, publisher et subscribers peuvent basculer de manière synchrone sur la nouvelle clé sans rupture de la communication sécurisée.

Si les membres disposent de la clé courante et de la suivante, une marge de temps apparaît, qui permet d'absorber une indisponibilité temporaire du KDC ou une défaillance de communication avec celui-ci.

Ce qui se passe en cas d'indisponibilité du KDC

Question opérationnelle très importante : que se passe-t-il si le KDC devient temporairement indisponible ?

Pour les fonctions d'ingénierie, la réponse ne doit pas être : « tout a cessé de fonctionner ». Si R-GOOSE est utilisé pour la téléaction ou les SPS, une perte temporaire de contact avec le KDC ne doit pas bloquer immédiatement la transmission et la réception des messages technologiques.

C'est précisément pour cela qu'on applique le schéma avec clés livrées à l'avance et période de validité des clés. Si les participants disposent déjà de la clé courante et de la suivante, ils peuvent continuer à travailler dans le cadre de la politique définie même pendant une indisponibilité courte du KDC.

Mais cela ne fait pas du KDC un élément secondaire. Sa défaillance doit être diagnostiquée, les événements doivent être journalisés, et l'exploitation doit comprendre :

• combien de temps le système peut fonctionner sans contact avec le KDC ;
• quels groupes de sécurité disposent déjà de la clé suivante ;
• quels équipements n'ont pas reçu la mise à jour ;
• quand commencera le risque de perdre la communication sécurisée ;
• comment rétablir la synchronisation des clés après le retour du KDC.

Le KDC et le fichier SCL

Pour l'ingénieur IEC 61850, il importe que les groupes de sécurité n'apparaissent pas de nulle part. Les fichiers SCL contiennent déjà des informations sur les flux, les liens publisher/subscriber, les DataSet, les Control Block, l'adressage et les souscriptions.

Sur la base de ces données, on peut déterminer quels équipements participent à un échange GOOSE, R-GOOSE, SV ou R-SV donné. Par conséquent, les informations SCL peuvent servir de base pour la constitution des groupes de sécurité et de la politique d'accès.

C'est un point important pour l'ingénierie et l'exploitation : la sécurité des profils routables doit être liée au modèle d'ingénierie du site, et non configurée à part « à la main » sans lien avec le projet SCD/SCL.

Si dans le fichier SCD la composition des abonnés a changé, cela impacte potentiellement non seulement le schéma de communication, mais aussi la composition du groupe de sécurité. Par conséquent, les modifications de projet doivent s'accompagner d'une révision des politiques du KDC et des droits des participants.

Ce que l'ingénieur doit vérifier lors du déploiement de Secure R-GOOSE

Lors du déploiement de Secure R-GOOSE ou Secure R-SV, l'ingénieur doit vérifier non seulement le fait du passage des messages, mais aussi toute la chaîne de confiance et de gestion des clés.

Une check-list pratique peut ressembler à ceci :

• le publisher et tous les subscribers sont définis pour chaque flux sécurisé ;
• pour chaque flux est défini un Security Group ;
• il est clair quels certificats utilisent les équipements et le KDC ;
• la procédure d'émission, de renouvellement et de révocation des certificats a été testée ;
• la politique du groupe est définie : algorithmes, rotation des clés, nécessité du chiffrement ;
• les modes PUSH et PULL ont été testés ;
• il est vérifié que l'équipement reçoit la clé après redémarrage ;
• le fonctionnement pendant l'indisponibilité temporaire du KDC est vérifié ;
• le mécanisme de rotation des clés est vérifié ;
• il est vérifié que le changement de clé ne bloque pas la fonction technologique ;
• les événements KDC et les erreurs de clés sont disponibles pour le diagnostic ;
• les modifications du projet SCD/SCL sont synchronisées avec les groupes de sécurité.

Routable ne veut pas dire Internet public

Le fait que R-GOOSE et R-SV soient routables ne signifie pas qu'ils doivent être transmis via l'Internet public non protégé.

R-GOOSE n'est pas « GOOSE via Internet ». C'est un mécanisme pour une infrastructure IP gérée, sécurisée et dimensionnée du système électrique.

Un tel réseau doit garantir :

• une latence prévisible ;
• la redondance ;
• le contrôle des routes ;
• la QoS ;
• la protection contre les accès non autorisés ;
• le diagnostic ;
• la supervision de l'état des canaux ;
• une responsabilité d'exploitation claire.

C'est pour cela que le déploiement de R-GOOSE n'est pas seulement une tâche de protection, mais aussi une tâche d'architecture réseau, de sécurité de l'information et d'exploitation.

Latence et performance

Pour le GOOSE local, la métrique principale est un temps de livraison rapide et prévisible à l'intérieur du réseau technologique.

Pour R-GOOSE, les exigences sont plus complexes. En plus du temps de livraison du message lui-même apparaissent :

• les latences de routage ;
• le traitement du multicast ;
• le fonctionnement des canaux WAN ;
• la redondance ;
• un éventuel traitement cryptographique ;
• le comportement en dégradation de la communication ;
• le temps de récupération après bascule de route.

Pour les tâches de supervision, une partie de ces latences peut être acceptable. Pour la téléaction et les SPS — non. Là, la latence devient une composante du temps total d'action de la fonction.

C'est pourquoi, lors de la conception de R-GOOSE, il faut commencer non par la question « comment transmettre le message », mais par :

quel est le temps de livraison maximal acceptable pour cette fonction ?

Et ensuite seulement choisir l'architecture réseau, les mécanismes de redondance, les exigences sur les canaux et les moyens de contrôle.

Différence pratique pour l'ingénieur

Pour l'ingénieur protection et SCADA, la différence entre GOOSE et R-GOOSE peut se formuler ainsi :

GOOSE — c'est une tâche locale dans le poste numérique. R-GOOSE — c'est une tâche à l'échelle du système électrique.

GOOSE exige la compréhension de :

• le fichier SCD ;
• le GOOSE Control Block ;
• le DataSet ;
• VLAN et priority tagging ;
• multicast MAC ;
• les paramètres stNum, sqNum, timeAllowedToLive ;
• les drapeaux test, simulation, ndsCom ;
• le comportement de l'abonné en cas de perte ou de modification du message ;
• etc.

R-GOOSE exige tout cela plus :

• l'adressage et le routage IP ;
• UDP multicast ;
• l'infrastructure multicast ;
• la QoS et le calcul des latences ;
• la redondance WAN ;
• la gestion des clés ;
• les certificats et les groupes de sécurité ;
• le diagnostic des flux sécurisés ;
• etc.

Où utiliser GOOSE et où utiliser R-GOOSE

flowchart TB
    START["<b>Quelle fonction implémentons-nous ?</b>"]
    Q1{"La fonction sort-elle<br/>des limites<br/>d'un seul poste ?"}
    Q2{"Que transmet-on :<br/>un événement ou<br/>des données périodiques ?"}
    Q3{"Latence admissible<br/>pour la fonction<br/>applicative ?"}

    GOOSE["<b>GOOSE</b><br/>Ethernet L2 · multicast<br/>VLAN · priority tagging<br/>SCD: GoCB · DataSet"]
    RGOOSE["<b>R-GOOSE</b><br/>IP / UDP multicast<br/>+ Secure session, KDC<br/>SCD + architecture réseau + cybersécurité"]
    RSV_MON["<b>R-SV (supervision)</b><br/>mesures synchrophaseurs<br/>WAMS / supervision distribuée<br/>essentiel — horodatage précis"]
    RSV_AUTO["<b>R-SV (automatisme)</b><br/>latence, gigue,<br/>pertes — critiques<br/>le WAN est conçu à part"]

    START --> Q1
    Q1 -- "non, local" --> GOOSE
    Q1 -- "oui, entre sites" --> Q2
    Q2 -- "événement" --> RGOOSE
    Q2 -- "mesures périodiques" --> Q3
    Q3 -- "supervision (dizaines–centaines de ms ok)" --> RSV_MON
    Q3 -- "automatisme rapide" --> RSV_AUTO

    NOTE1["⚠️ R-GOOSE / R-SV ≠ Internet public<br/>une infrastructure WAN gérée est requise<br/>avec QoS, redondance et contrôle des routes"]
    RGOOSE -.-> NOTE1
    RSV_MON -.-> NOTE1
    RSV_AUTO -.-> NOTE1

    style START fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style Q1 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q2 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q3 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style GOOSE fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style RGOOSE fill:#FBE9E7,stroke:#E64A19,color:#BF360C
    style RSV_MON fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style RSV_AUTO fill:#FDE8E8,stroke:#F56C6C,color:#B71C1C
    style NOTE1 fill:#F4F6FB,stroke:#9aa6c8,color:#3a4566

Le GOOSE ordinaire reste la solution optimale pour les fonctions locales du poste :

• verrouillages ;
• déclenchements ;
• signaux d'automatismes ;
• échanges entre IED de protection ;
• interaction entre équipements à l'intérieur d'un seul réseau technologique ;
• remplacement des circuits cuivre à l'intérieur du site.

R-GOOSE est nécessaire là où la fonction sort des limites d'un seul poste :

• téléaction inter-sites ;
• schémas spéciaux de protection ;
• transmission d'événements entre postes et centrales ;
• interaction avec des objets distants de production décentralisée ;
• logique de conduite de régime entre sites.

R-SV peut être intéressant pour les tâches de transmission de données de mesure via WAN, surtout lorsqu'il s'agit de mesures synchrophaseurs et de supervision distribuée.

Ce que cela change pour l'exploitation des postes numériques

Pour l'exploitation des postes numériques, l'apparition de R-GOOSE et R-SV signifie que la frontière de responsabilité de l'ingénieur s'élargit.

Auparavant, il suffisait de comprendre ce qui se passe à l'intérieur du bus station ou du bus process d'un poste. Désormais, pour une série de tâches, il faut comprendre aussi le réseau inter-sites :

• par quels routeurs passe le message ;
• comment est construit le multicast ;
• quelles latences sont acceptables ;
• où se trouvent le publisher et les subscribers ;
• comment le flux est protégé ;
• qui gère les clés ;
• ce qui se passera en cas de défaillance de canal ;
• comment se comportera le système en dégradation de la communication ;
• comment enregistrer et démontrer le fonctionnement correct lors des essais.

Ce n'est plus seulement « poste numérique » au sens strict. C'est l'infrastructure numérique de communication du système électrique.

Conclusion

GOOSE reste le mécanisme de base et efficace d'échange rapide d'événements à l'intérieur du poste numérique.

R-GOOSE étend cette idée aux réseaux IP routables et permet de construire des fonctions inter-sites : téléaction, schémas spéciaux de protection, verrouillages inter-sites et d'autres scénarios où un événement d'un nœud doit parvenir rapidement et en toute sécurité à plusieurs abonnés distants.

R-SV résout une tâche similaire pour les mesures, y compris les scénarios liés aux mesures synchrophaseurs et à la supervision distribuée.

Mais la conclusion principale est autre : R-GOOSE et R-SV ne sont pas simplement « GOOSE et SV par IP ». Ce sont des profils de communication routables sécurisés, qui exigent une nouvelle discipline d'ingénierie : calcul des latences, conception du multicast, gestion des clés, mise en œuvre de mécanismes de cybersécurité et vérification obligatoire du comportement du système en régimes normaux et de défaillance.

Le KDC dans une telle architecture n'est pas seulement « un serveur de clés » quelque part dans le réseau. Il lie entre eux le modèle d'ingénierie IEC 61850, la composition des groupes publisher/subscriber, les certificats numériques des équipements, les clés symétriques, la politique de rotation et la disponibilité opérationnelle de la communication sécurisée.

C'est pourquoi, en discutant de R-GOOSE, il est important de ne pas poser la question « peut-on faire passer GOOSE plus loin ? », mais une tout autre :

quelle fonction réalisons-nous, par quel réseau elle passe, quel temps de livraison est acceptable, comment le flux est-il protégé et que se passera-t-il en cas de défaillance de communication ?

Ce n'est qu'après avoir répondu à ces questions que R-GOOSE cesse d'être un beau terme issu de la norme pour devenir un outil de travail du système électrique numérique.