Protocole GOOSE

Le protocole GOOSE, décrit dans l’article 61850-8-1 de la Commission électrotechnique internationale (CEI), est l’un des protocoles les plus connus fournis par la norme CEI 61850. L’acronyme GOOSE (Generic Object-Oriented Substation Event) peut littéralement se traduire par « événement substation orienté objet général ». Toutefois, en pratique, il ne faut pas accorder une grande importance au nom original, car il ne donne aucune information sur le fonctionnement du protocole. Il est beaucoup plus pratique de considérer le protocole GOOSE comme un service conçu pour l’échange de signaux numériques entre les dispositifs de protection et d’automatisation (RPA).

Formation du message GOOSE

Dans la publication précédente [1], nous avons examiné le modèle d’information des dispositifs et l’organisation des données, en concluant par la formation des ensembles de données — Datasets. Les ensembles de données sont utilisés pour regrouper les données qui seront transmises par un dispositif via le mécanisme de message GOOSE. Par la suite, dans le bloc de contrôle de transmission GOOSE, une référence à l’ensemble de données créé est spécifiée ; ainsi, le dispositif sait exactement quelles données envoyer (voir la figure 1). Il convient de noter qu’un seul message GOOSE peut transmettre à la fois une seule valeur (par exemple, un signal de déclenchement de protection contre courant maximal (MCP)) et plusieurs valeurs simultanément (par exemple, un signal de déclenchement MCP et un signal d’opération MCP, etc.). Le dispositif récepteur peut, à son tour, extraire uniquement les données dont il a besoin du paquet.

Le paquet de message GOOSE transmis contient toutes les valeurs actuelles des attributs de données inclus dans l’ensemble de données. Lorsqu’une valeur d’un attribut change, le dispositif déclenche immédiatement l’envoi d’un nouveau message GOOSE avec les données mises à jour (voir la figure 2).

Par conception, un message GOOSE (Generic Object Oriented Substation Event) est destiné à remplacer la transmission de signaux discrets via les réseaux DC (courant continu) auxiliaires. Examinons à présent les exigences imposées au protocole de transmission de données dans ce contexte.

Communications numériques remplaçant les analogiques

Pour concevoir une alternative aux circuits de transmission de signaux entre les dispositifs de protection et d’automatisation (RPA), les propriétés des informations transmises entre les dispositifs RPA via des signaux discrets ont été analysées :

• Volume faible d’informations — essentiellement des valeurs « vraies » et « fausses » (ou logiques « zéro » et « un ») sont transmises entre les terminaux ;
• Vitesse de transmission élevée requise — une grande partie des signaux discrets transmis entre les dispositifs RPA, directement ou indirectement, affecte la vitesse de suppression des modes anormaux ; par conséquent, la transmission des signaux doit se faire avec une latence minimale ;
• Probabilité élevée de livraison des messages requise — pour mettre en œuvre des fonctions critiques, telles qu’émission d’une commande de déclenchement de disjoncteur depuis un dispositif RPA ou échange de signaux entre dispositifs RPA lors de l’exécution de fonctions distribuées, une livraison garantie des messages doit être assurée, tant en fonctionnement normal du réseau de transmission de données numériques qu’en cas de pannes à court terme ;
• Capacité à transmettre des messages à plusieurs destinataires simultanément — lors de la mise en œuvre de certaines fonctions RPA distribuées, une transmission de données d’un dispositif vers plusieurs autres est requise ;
• Surveillance de l’intégrité du canal de transmission des données nécessaire — la présence d’une fonction de diagnostic de l’état du canal de communication permet d’augmenter le facteur de disponibilité lors de la transmission des signaux, améliorant ainsi la fiabilité de la fonction réalisée par la transmission du message spécifié.

Ces exigences ont conduit au développement du mécanisme de message GOOSE (Generic Object Oriented Substation Event), qui répond à tous les critères énoncés.

Assurer la vitesse de transmission des données

Dans les circuits de transmission de signaux analogiques, le délai principal dans la transmission du signal est causé par le temps de réponse de la sortie discrète du dispositif et le temps de filtrage des rebonds de contact à l’entrée discrète du dispositif récepteur. Par rapport à cela, le temps de propagation du signal à travers le conducteur est négligeable.

De même, dans les réseaux de transmission de données numériques, le délai principal n’est pas tant causé par la transmission du signal à travers le milieu physique que par son traitement au sein du dispositif.

En théorie des réseaux de données, il est courant de segmenter les services de transmission de données selon les niveaux du modèle OSI (Open Systems Interconnection) [2], généralement en descendant de la couche « Application » (couche de présentation de l’application) à la couche « Physique » (couche d’interaction physique des dispositifs).

Dans sa représentation classique, le modèle OSI ne comporte que sept couches : physique, liaison de données, réseau, transport, session, présentation et application. Toutefois, les protocoles mis en œuvre peuvent ne pas inclure toutes les couches spécifiées ; autrement dit, certaines couches peuvent être sautées.

Le fonctionnement du modèle OSI (Open Systems Interconnection) peut être clairement illustré par l’exemple de la transmission de données de page web sur Internet depuis un ordinateur personnel. La transmission du contenu d’une page web sur Internet s’effectue à l’aide du protocole HTTP (Hypertext Transfer Protocol), qui est un protocole de la couche application. La transmission des données HTTP est généralement réalisée par le protocole de transport TCP (Transmission Control Protocol). Les segments du protocole TCP sont encapsulés dans des paquets de protocole réseau, qui dans ce cas est l’IP (Internet Protocol). Les paquets TCP forment des trames de la couche liaison de données Ethernet, lesquelles peuvent être transmises via différentes couches physiques selon l’interface réseau. Ainsi, les données d’une page web consultée sur Internet subissent au moins quatre couches de transformation lors de la formation d’une séquence de bits à la couche physique, suivies du même nombre d’étapes de transformation inverse. Un tel nombre de transformations entraîne des retards tant lors de la formation de la séquence de bits à transmettre que lors de la transformation inverse pour récupérer les données transmises. En conséquence, pour réduire la latence, le nombre de transformations doit être minimisé. C’est précisément la raison pour laquelle les données GOOSE (Generic Object Oriented Substation Event) (couche application) sont assignées directement à la couche liaison de données Ethernet, en contournant les autres couches.

En général, la norme IEC 61850-8-1 prévoit deux profils de communication qui décrivent tous les protocoles de transfert de données fournis par la norme :

• le profil « MMS » ;
• le profil « Non-MMS » (c’est-à-dire non-MMS).

Par conséquent, les services de transfert de données peuvent être mis en œuvre en utilisant l’un de ces profils spécifiés. Le protocole GOOSE (Generic Object Oriented Substation Event) (ainsi que le protocole Sampled Values) appartient spécifiquement au deuxième profil.

L’utilisation d’une pile « raccourcie » avec un nombre minimal de transformations est un moyen important, mais pas le seul, d’accélérer la transmission des données. L’emploi de mécanismes de priorisation des données contribue également à accélérer la transmission via le protocole GOOSE. Plus précisément, pour le protocole GOOSE, un identifiant d’encapsulation Ethernet distinct — l’Ethertype — est utilisé, qui possède une priorité délibérément plus élevée par rapport au reste du trafic, tel que celui transmis via la couche réseau du protocole Internet (IP).

Outre les mécanismes discutés, un cadre Ethernet de message GOOSE peut également être équipé de balises de priorité du protocole IEEE 802.1Q, ainsi que de balises de réseau local virtuel (VLAN) du protocole ISO/IEC 8802-3. Ces balises permettent d’augmenter la priorité des trames lors de leur traitement par les commutateurs réseau. Ces mécanismes d’amélioration de la priorité seront abordés plus en détail dans des publications ultérieures.

L’usage de toutes les méthodes considérées permet d’augmenter significativement la priorité des données transmises via le protocole GOOSE par rapport aux autres données transmises sur le même réseau à l’aide de protocoles différents, minimisant ainsi les retards lors du traitement des données dans les dispositifs source et récepteur, ainsi que lors du traitement par les commutateurs réseau.

Envoi d’informations à plusieurs destinataires

Les adresses physiques des dispositifs réseau — les adresses MAC (Media Access Control) — sont utilisées pour adresser les trames au niveau de la couche liaison de données. À cet égard, Ethernet permet ce qu’on appelle le multicast. Dans ce cas, une adresse multicast est spécifiée dans le champ d’adresse MAC de destination. Une plage d’adresses spécifique est utilisée pour les transmissions multicast via le protocole GOOSE (voir Figure 3).

Les messages dont la première octet de l’adresse a la valeur « 01 » sont envoyés à toutes les interfaces physiques du réseau ; par conséquent, la transmission multicast n’a pas de destinataires fixes, et son adresse MAC sert davantage d’identifiant pour le multicast lui-même que de pointeur direct vers ses destinataires.

Ainsi, l’adresse MAC d’un message GOOSE (Generic Object Oriented Substation Event) peut être utilisée, par exemple, lors de l’organisation du filtrage des messages sur les commutateurs réseau (filtrage MAC), et cette adresse peut également servir d’identifiant pour lequel les appareils récepteurs peuvent être configurés.

Ainsi, la transmission des messages GOOSE peut être comparée à une diffusion radio : le message est diffusé à tous les appareils du réseau, mais pour le recevoir et le traiter par la suite, l’appareil récepteur doit être configuré pour recevoir ce message spécifique (voir Fig. 4).

graph LR
    RPA1["PROT 1"] -->|"Publishing<br/>GOOSE message"| Switch["SWITCH"]
    Switch --> RPA2["PROT 2"]
    Switch --> RPA3["PROT 3"]
    Switch -.-> RPA4["PROT 4"]
    Switch x-.-x RPA5["PROT 5"]

    RPA2 --- D2["Device is subscribed<br/>and receives the message"]
    RPA3 --- D3["Device is subscribed<br/>and receives the message"]
    RPA4 --- D4["Device is not subscribed;<br/>it receives the message<br/>but ignores it"]
    RPA5 --- D5["Message is filtered<br/>at the switch"]

    style RPA1 fill:#000080,color:#fff,stroke:#000080,font-weight:bold
    style RPA2 fill:#000080,color:#fff,stroke:#000080,font-weight:bold
    style RPA3 fill:#000080,color:#fff,stroke:#000080,font-weight:bold
    style RPA4 fill:#000080,color:#fff,stroke:#000080,font-weight:bold
    style RPA5 fill:#000080,color:#fff,stroke:#000080,font-weight:bold
    style Switch fill:#fff,color:#000,stroke:#000,stroke-width:2px
    style D2 fill:none,stroke:none,color:#333
    style D3 fill:none,stroke:none,color:#333
    style D4 fill:none,stroke:none,color:#333
    style D5 fill:none,stroke:none,color:#333

Livraison garantie des messages et surveillance de l’état du canal

La transmission de messages à plusieurs destinataires en mode multicast, ainsi que les exigences de débits de données élevés, ne permettent pas la mise en œuvre de confirmations de livraison par les récepteurs lors de la transmission des messages GOOSE. La procédure d’envoi des données, de génération d’une confirmation par l’appareil récepteur, de réception et de traitement par l’appareil émetteur, ainsi que la retransmission en cas d’échec, prendrait trop de temps, pouvant entraîner des retards excessifs dans la transmission de signaux critiques.

À la place, un mécanisme particulier a été mis en œuvre pour les messages GOOSE afin d’assurer une forte probabilité de livraison des données.

Tout d’abord, en l’absence de modifications des attributs des données transmises, les paquets de messages GOOSE sont transmis de manière cyclique selon un intervalle défini par l’utilisateur (voir figure 5 a). La transmission cyclique des messages GOOSE permet une surveillance continue du réseau de communication. Un dispositif configuré pour recevoir un message s’attend à son arrivée à des intervalles de temps précis. Si un message n’arrive pas dans la période d’attente, le dispositif récepteur peut générer un signal d’erreur dans le réseau de communication, informant ainsi le dispatcheur de toute défaillance survenue.

Deuxièmement, lorsque l’un des attributs de l’ensemble de données transmises change, quelle que soit la durée écoulée depuis l’envoi du message précédent, un nouveau paquet contenant les données mises à jour est formé. Ensuite, l’envoi de ce paquet est répété plusieurs fois avec un délai minimal (voir figure 5 b), puis l’intervalle entre les messages (en l’absence de modifications des données transmises) revient à sa valeur maximale.

Troisièmement, le paquet de message Generic Object Oriented Substation Event (GOOSE) fournit plusieurs champs de compteur qui peuvent également être utilisés pour surveiller l’intégrité du canal de communication. Ces compteurs incluent, par exemple, le numéro de séquence cyclique (sqNum), dont la valeur varie de 0 à 4 294 967 295 ou jusqu’à ce que les données transmises changent. À chaque modification des données transmises dans un message GOOSE, le compteur sqNum est réinitialisé, et un autre compteur — le numéro d’état (stNum), qui évolue également cycliquement dans la plage de 0 à 4 294 967 295 — est incrémenté de 1. Ainsi, si plusieurs paquets sont perdus pendant la transmission, cette perte peut être suivie à l’aide de ces deux compteurs spécifiés.

Enfin, quatrièmement, il est également important de noter qu’une transmission GOOSE peut contenir, en plus de la valeur du signal discret lui-même, un attribut de qualité (quality flag) qui identifie une défaillance matérielle spécifique du dispositif source d’information, la présence du dispositif source d’information en mode test, ainsi que plusieurs autres modes anormaux. Ainsi, avant de traiter les données reçues selon les algorithmes prescrits, le dispositif récepteur peut effectuer une vérification de cet attribut de qualité. Cela peut prévenir un fonctionnement incorrect des dispositifs récepteurs d’information (par exemple, des opérations erronées).

Il convient de garder à l’esprit que certaines des mécanismes intégrés visant à assurer la fiabilité de la transmission des données peuvent entraîner des effets négatifs s’ils sont utilisés de manière incorrecte. Par exemple, si l’intervalle maximal entre les messages est choisi trop court, la charge du réseau augmente, même si, du point de vue de la disponibilité du canal de communication, l’effet de réduction de l’intervalle de transmission sera extrêmement négligeable.

Lorsque les attributs de données changent, l’envoi de paquets avec des délais minimum entraîne une augmentation de la charge du réseau (mode « tempête d’information »), qui peut théoriquement conduire à des retards dans la transmission des données. Ce mode est le plus complexe et doit être pris en compte comme base de conception lors de la mise en œuvre du réseau de communication. Toutefois, il convient de comprendre que la charge maximale est très brève ; selon les expériences menées dans notre laboratoire pour les tests d’interopérabilité des équipements fonctionnant selon les normes IEC 61850 au sein du Département de protection et automatisme des centrales nucléaires (RP&A NPP) de l’Université nationale de recherche en génie électrique (NRUP EE), de telles charges sont observées sur une période de 10 ms.

Mise en service et tests des systèmes de protection et automatisme (RPA) utilisant les communications GOOSE

Lors de la conception des systèmes RPA basés sur le protocole GOOSE, les procédures de mise en service et de test changent. La phase de mise en service consiste désormais à organiser le réseau Ethernet de l’installation électrique, qui comprendra tous les équipements RPA nécessitant un échange de données. Pour vérifier que le système est configuré et connecté conformément aux exigences du projet, il devient possible d’utiliser un ordinateur personnel doté de logiciels spécialisés préinstallés (Wireshark, GOOSE Monitor, etc.) ou des équipements de test spécialisés prenant en charge le protocole GOOSE (RETOM 61850, Omicron CMC). Il est important de noter que toutes les vérifications peuvent être effectuées sans interrompre les connexions préétablies entre les équipements secondaires (appareils RPA, commutateurs, etc.), car l’échange de données se fait via le réseau Ethernet. En revanche, lors de l’échange de signaux discrets entre les équipements RPA de manière traditionnelle (en appliquant une tension à l’entrée discrète de l’appareil récepteur lorsque la contact de sortie de l’appareil émetteur se ferme), il est souvent nécessaire de rompre les connexions entre les équipements secondaires afin de les intégrer aux circuits de l’appareil de test pour vérifier la correction des connexions électriques et la transmission des signaux discrets pertinents.

Conclusions

Le protocole GOOSE offre un ensemble complet de mesures visant à garantir les performances et les caractéristiques de fiabilité nécessaires lors de la transmission de signaux critiques. L’utilisation de ce protocole, combinée à une conception et une paramétrisation appropriées du réseau de communication et des équipements RPA, permet, dans plusieurs cas, d’abandonner l’usage des circuits en cuivre pour la transmission des signaux tout en assurant le niveau requis de fiabilité et de vitesse.

1. Anoshin A.O., Golovin A.V. NORME IEC 61850. Modèle d'information des dispositifs // News de l'ingénierie électrique No. 5 (77).
2. Réseaux d'information et de calcul : guide d'étude Kapustin, V. E. Dementiev. — Oulianovsk : UlGTU, 2011. — 141 p.