La norme CEI 61850 relative aux messages GOOSE et comment la tester dans le cadre de automatisation de sous-stations

Principaux enseignements

• Les tests GOOSE selon la norme CEI 61850 commencent par l'analyse des fichiers SCL, des ensembles de données et de la signification des signaux avant de passer au traitement des paquets en temps réel.
• La synchronisation à quelques millisecondes près n'est garantie que si la conception de la multidiffusion, la gestion des commutateurs et la logique des abonnés sont testées comme un tout.
• Le protocole DNP3 joue toujours un rôle important dans les échanges de supervision, mais la logique de déclenchement relève du protocole GOOSE.

Pour garantir la fiabilité des tests GOOSE selon la norme CEI 61850, il faut commencer par respecter une rigueur technique bien avant de capturer le moindre paquet.

Les essais selon la norme CEI 61850 sont essentiels, car le flux de données de protection n'est efficace que si le sens du message, le timing et la réponse de l'abonné correspondent tous à l'objectif de protection. Les coupures de courant coûtent à l'économie américaine entre 28 et 169 milliards de dollars chaque année, ce qui nous rappelle utilement qu'une communication de protection défaillante entraîne un coût système bien plus élevé. Vous ne validez pas un réseau de manière isolée. Vous démontrez que la sous-station se déclenchera, bloquera ou verrouillera exactement au moment où elle le doit.

La norme CEI 61850 GOOSE transmet les signaux de protection sans délai d'interrogation

La norme CEI 61850 GOOSE transmet les changements d'état et les déclenchements sous forme de messages d'événement, ce qui permet aux dispositifs de protection de réagir dès qu'un état change, sans attendre un cycle d'interrogation. Ce comportement fait de GOOSE une solution particulièrement adaptée aux logiques d'enchaînement, de blocage, de déclenchement de transfert et de défaillance des disjoncteurs au sein du poste électrique.

Un relais d'alimentation qui détecte un défaut interne peut signaler immédiatement un état de déclenchement, et un dispositif électronique de commande (IED) de disjoncteur peut recevoir cette information sans avoir à demander au préalable une mise à jour. Le message étant diffusé en multidiffusion, plusieurs appareils peuvent réagir simultanément. Cela s'avère crucial lorsqu'un déclenchement différentiel de bus doit atteindre plusieurs baies à la fois. Vous testez la rapidité, mais vous vérifiez également la cohérence des actions entre plusieurs abonnés.

GOOSE fonctionne parce que le message est répété à un rythme soutenu après un changement d'état, puis que la fréquence de répétition diminue une fois que le nouvel état est stabilisé. Cette répétition aide les abonnés à conserver un état valide même en cas de perte d'une trame. Les ingénieurs en protection se concentrent parfois uniquement sur le tracé des paquets, alors que la vérification globale est plus simple. Chaque bit du jeu de données doit représenter une action claire qu'un autre dispositif interprétera de la même manière.

La vitesse de GOOSE dépend de la conception de la multidiffusion sur le bus de la station

Les performances de GOOSE dépendent du comportement des commutateurs, du transfert multicast, du marquage des priorités et de la segmentation du réseau sur le bus de la station. Les problèmes de latence proviennent généralement d'une mauvaise gestion du trafic plutôt que du protocole lui-même. Une conception rigoureuse permet de garantir la prévisibilité du trafic de protection en cas de défaillance, d'opérations de maintenance et de redémarrage des équipements.

Une défaillance courante survient lorsqu'un commutateur géré continue de diffuser massivement du trafic multicast sur des ports qui n'ont pas besoin de trafic GOOSE. Une baie de protection reçoit alors des trames supplémentaires provenant d'émetteurs sans rapport avec elle, et l'abonné continue de fonctionner jusqu'à ce qu'une rafale de trafic technique arrive. Votre capture de paquets affichera des trames GOOSE, mais le temps de transfert variera. C'est pourquoi la conception des VLAN et les paramètres de priorité méritent la même attention que la logique de relais.

Les tests sur les stations de bus doivent inclure des conditions de charge normales et des conditions de charge maximale. Le déclenchement d'un disjoncteur pendant un transfert de fichiers de maintenance via un ordinateur portable constitue un test utile, car il met en évidence la gestion des files d'attente au sein de la matrice de commutation. Un réseau plat qui masque la congestion des ports ne permettra pas d'obtenir des résultats significatifs selon la norme CEI 61850. Une bonne conception du réseau garantit que le trafic GOOSE reste court, local et priorisé.

« Le protocole GOOSE de la norme CEI 61850 transmet les changements d'état et les déclenchements sous forme de messages d'événement, ce qui permet aux dispositifs de protection de réagir dès qu'un état change, sans attendre un cycle d'interrogation. »

Commencez les tests IEC 61850 par la validation des fichiers SCL

La validation SCL constitue le premier test sérieux, car elle permet de vérifier que le modèle d'ingénierie correspond bien aux appareils que vous prévoyez de mettre en service. Si les fichiers ICD, CID, SSD ou SCD présentent des incohérences, les tests de paquets ne feront que confirmer que la conception erronée a été correctement mise en œuvre.

• Vérifiez que chaque éditeur et chaque abonné utilise les mêmes références de nœuds logiques.
• Vérifiez que les éléments du jeu de données correspondent aux noms de signaux approuvés dans la logique de protection.
• Vérifiez les paramètres du bloc de contrôle, en particulier les champs relatifs à l'adresse MAC, au VLAN et à la priorité.
• Vérifiez les numéros de révision afin que les abonnés ne rejettent pas sans le savoir un ensemble de données mis à jour.
• Assurez-vous que le fichier importé associe chaque signal à l'entrée/sortie physique ou au point interne prévu.

Un scénario de transfert illustre bien l'importance de cette étape. La logique peut sembler parfaite dans le fichier de configuration des relais, mais le fichier SCD peut attribuer le bit de déclenchement de la défaillance du disjoncteur à un objet de données erroné. La compilation s'effectuera sans problème, mais la sous-station continuera de fonctionner de manière incorrecte. Vous gagnerez des jours de dépannage si vous considérez le fichier d'ingénierie comme un objet de testplutôt que comme un simple document administratif.

Vérifier que les ensembles de données correspondent à chaque fonction de protection avant de procéder aux tests de signal

La vérification de l'ensemble de données précède l'injection du signal, car chaque fonction de protection dépend de l'objet de données, de l'état de qualité et de la version du bloc de contrôle précis qu'elle attend. Un abonné peut recevoir une trame GOOSE valide et néanmoins interpréter une signification erronée si la structure de l'ensemble de données est incorrecte.

Un scénario de défaillance d'un disjoncteur illustre bien ce principe. L'émetteur peut transmettre la position du disjoncteur, l'activation de la protection et l'état de verrouillage dans un seul ensemble de données, mais le destinataire n'aura peut-être besoin que de deux de ces informations et s'attendra à les recevoir dans un ordre différent ou avec une contrainte fonctionnelle différente. Une capture en temps réel du réseau ne permettra pas toujours de détecter cette divergence. Il est nécessaire de comparer point par point la fonction de protection prévue et le contenu de l'ensemble de données.

Les tests de signal ne prennent tout leur sens qu’une fois que cette cartographie a été validée. Provoquez un défaut, activez le contact auxiliaire d’un disjoncteur ou basculez un verrouillage, puis vérifiez que l’élément de l’ensemble de données concerné change et que la logique de l’abonné réagit. Vous vérifiez autant la sémantique que le transport. C’est cette étape qui distingue les tests IEC 61850 d’un simple contrôle de l’état du réseau Ethernet.

«Vous évaluez les performances de protection de bout en bout, et pas seulement le transit des trames. »

Les systèmes de protection nécessitent une latence GOOSE de l'ordre de quelques millisecondes

Le trafic de protection GOOSE doit arriver dans un délai de quelques millisecondes, car la logique de déclenchement et de blocage perd de sa valeur lorsque le délai de communication avoisine le temps de suppression de l'élément défaillant. L'objectif pratique pour le trafic de protection à haut débit est généralement inférieur à 4 ms pour les performances de type 1A .

Un test en laboratoire indiquant un temps de latence moyen de 1,5 ms en période de trafic faible ne suffit pas. Il faut également effectuer des mesures lors d'événements de pic de trafic, de redémarrage des appareils et de reconvergence des commutateurs. Un abonné qui répond en 2 ms la plupart du temps, mais dont le temps de réponse grimpe à 9 ms lors d'une surcharge du réseau, risque tout de même de déclencher un système de dépassement de seuil ou de coupure de bus. Les tests de latence n'ont de valeur que s'ils prennent en compte les moments critiques.

Les horodatages, les numéros de séquence et les intervalles de retransmission vous aident à distinguer le retard de transport du comportement de l'application. Observez le changement d'état, la première retransmission et la modification de la sortie de l'abonné comme une seule et même chaîne d'événements. Si le relais attend la fin d'un traitement interne après avoir reçu la trame, la trace des paquets ne suffira pas à elle seule à donner une image complète de la situation. Vous mesurez les performances de protection de bout en bout, et pas seulement le transit des trames.

Les problèmes d'interopérabilité trouvent généralement leur origine dans les paramètres par défaut définis par les fabricants

Les problèmes d'interopérabilité proviennent généralement de choix techniques par défaut, tels que l'ordre des ensembles de données, la gestion de la qualité, le contrôle des révisions et les paramètres VLAN. Des appareils de différents fabricants peuvent parfaitement prendre en charge la norme CEI 61850 tout en ne communiquant pas entre eux si les paramètres par défaut ne sont pas modifiés. Il faut s'attendre à ce que les tests inter-fabricants mettent en évidence des hypothèses que les projets impliquant un seul fabricant ne révèlent pas.

Un cas fréquent se produit après le remplacement d'un relais. Le nouvel appareil publie les mêmes noms de signaux logiques, mais son bloc de contrôle par défaut utilise un numéro de révision différent et un modèle de retransmission différent. L'abonné détecte le trafic, mais rejette tout de même la mise à jour ou conserve un état antérieur. Ce type de défaillance est difficile à détecter, à moins que votre plan de test ne prévoie des vérifications délibérées de publication et d'abonnement entre différents fournisseurs.

Les tests d'interopérabilité doivent passer de l'importation technique au comportement en conditions réelles sans sauter les étapes intermédiaires. Vérifiez l'importation du fichier, confirmez les valeurs des blocs de commande, déclenchez le signal et observez le contact de sortie ou le point logique interne. Cette séquence permettra de mettre en évidence à quel moment le problème survient. Les déclarations de conformité générales ne vous diront pas si votre schéma précis fonctionne sur le bus de votre station.

Les outils IEC 61850 doivent enregistrer les événements de relecture de paquets

Pour réaliser des tests IEC 61850 efficaces, il faut disposer d'un ensemble d'outils permettant simultanément de capturer des trames, d'injecter des événements, de mesurer les délais et d'observer les sorties des abonnés. Aucun outil ne permet à lui seul de valider l'ensemble du système. Vous constituez ainsi une chaîne de preuves, depuis les fichiers d'ingénierie jusqu'à la réponse des appareils en temps réel.

Une configuration en boucle fermée permet de clarifier considérablement cette chaîne. Un simulateur en temps réel d'OPAL-RT peut simuler un défaut, publier ou souscrire du trafic GOOSE, et montrer comment la logique de protection réagit sous une contrainte temporelle contrôlée. La capture de paquets reste importante, mais elle s'avère bien plus utile lorsqu'elle est associée à une perturbation connue et à une sortie de relais mesurée. C'est ainsi que l'on teste le schéma de protection plutôt que le simple réseau.

Le protocole DNP3 continue de prendre en charge le trafic de supervision, moins rapide, en dehors de la logique de déclenchement

La principale différence entre les protocoles GOOSE (IEC 61850) et DNP3 réside dans le fait que GOOSE achemine le trafic lié aux événements pour les logiques de protection où le temps est un facteur critique, tandis que DNP3 gère les données de supervision qui peuvent tolérer une transmission plus lente. Il est recommandé de faire transiter les chemins de déclenchement par GOOSE et de réserver DNP3 à l'interrogation, à la commande, aux alarmes et aux échanges avec le centre de contrôle.

Une passerelle de sous-station qui transmet l'état des disjoncteurs et les valeurs analogiques à une salle de contrôle constitue un bon cas d'utilisation du protocole DNP3. En revanche, ce n'est pas le cas pour un déclenchement de disjoncteur, un déclenchement de bus ou une autorisation de transfert. Ces signaux nécessitent un comportement de multidiffusion déterministe au sein du bus de la station, et le protocole DNP3 n'a jamais été conçu pour cette tâche. Le fait de mélanger ces rôles entraîne généralement de longs cycles de dépannage, car le choix du protocole est en soi inapproprié.

Les équipes qui testent les deux protocoles dans le cadre d'un même projet parviennent généralement à la même conclusion. Une attribution claire des signaux, un contrôle rigoureux de la SCL et des vérifications de synchronisation de bout en bout importent davantage que les slogans relatifs aux protocoles. OPAL-RT convient à cette phase d'exécution où vous devez tester la logique de protection dans des conditions de défaillance reproductibles, mais ce principe s'applique à tout banc d'essai sérieux. Une ingénierie rigoureuse garantira la fiabilité du protocole GOOSE de la norme CEI 61850, tandis que le protocole DNP3 continuera à servir la couche de supervision plus lente, là où est sa place.