Comment mettre en place un outil de gestion des tests de relais de protection auquel les ingénieurs font confiance

Principaux enseignements

• La vérification des éléments et la validation du schéma sont deux tâches distinctes, et la plupart des programmes de test ne s’occupent que de la première.
• C'est la simulation en boucle fermée qui met en évidence les comportements en matière de coordination, de réenclenchement et d'interaction avec l'onduleur, que la forme d'onde d'injection fixe ne permet pas de reproduire.
• Une bibliothèque de cas de défaillance réutilisable, associée au fichier de paramètres, permet de transformer les erreurs de configuration en tests de régression plutôt qu'en découvertes sur le terrain.

Un processus de test des relais de protection prend tout son sens lorsqu'il permet de détecter une erreur de paramétrage ou de logique avant la mise en service du système, plutôt qu'après qu'un défaut l'ait mise en évidence.

La barre a été placée plus haut. Près de 70 GW de nouvelle capacité solaire devraient être mis en service entre 2026 et 2027, ce qui représente une augmentation de 49 % de la capacité solaire en service aux États-Unis par rapport à la fin de l’année 2025. Le courant de défaut provenant de ces centrales est limité et régulé par des dispositifs de contrôle ; par conséquent, les éléments liés à la distance et à la direction présentent un comportement que le plan de test de l’ère électromécanique n’avait jamais envisagé. L’injection secondaire confirme à elle seule que le relais se comporte conformément à ses réglages, sans toutefois permettre de détecter que ces réglages ne sont pas adaptés au réseau concerné.

La solution ne réside pas dans l'ajout de points d'injection. Il s'agit plutôt de boucler la boucle, en plaçant le relais en amont d'un système simulé qui réagit à ses décisions de déclenchement, puis de reproduire les cas de défaut jugés plausibles par vos études de planification. Vous continuerez bien sûr à effectuer des vérifications au niveau des éléments. Ce qui change, c'est que le schéma est validé en tant que système avant même que quiconque ne le mette sous tension.

Ce que les essais des relais de protection révèlent réellement sur un schéma

Les essais des relais de protection permettent de vérifier trois éléments distincts. Le premier est que le matériel des relais effectue correctement les mesures. Le deuxième est que les réglages correspondent à l'étude de coordination approuvée. Le troisième est que le schéma élimine un défaut dans les délais tolérés par le réseau. La plupart des programmes vérifient correctement les deux premiers éléments, mais presque jamais le troisième.

Un test de banc de vérification de l’élément de distance confirme que le point de déclenchement se déclenche à 85 % de l’impédance de la ligne. Il ne dit rien sur ce qui se passe lorsque le signal de téléprotection du terminal distant arrive avec 12 ms de retard après un basculement de communication et que le relais local revient sur le temporisage de la zone 2. On ne peut répondre à cette deuxième question que lorsque le relais fonctionne par rapport à un modèle du réseau dans lequel il est intégré.

Les études de coordination permettent de définir les paramètres. C'est lors des essais que l'on vérifie si ces hypothèses résistent à la réalité de la topologie du réseau, des rapports de transformation des instruments de mesure et de la latence des communications. C'est en considérant ces deux activités comme indépendantes l'une de l'autre que l'on aboutit à des paramètres corrects qui finissent par protéger le mauvais système.

« La plupart des programmes vérifient correctement les deux premiers points, mais presque jamais le troisième. »

Quand les essais d'injection en régime permanent ne suffisent plus

L'injection secondaire cesse d'être suffisante dès lors qu'une décision du relais influe sur ce que ce dernier va mesurer par la suite. L'injection reproduit une forme d'onde fixe et évalue la réponse par rapport au seuil de déclenchement et au temps de réponse attendus. Elle ne permet pas de montrer le réenclenchement d'un disjoncteur sur une source affaiblie, la variation d'angle d'un générateur après le premier déclenchement, ni la réaction d'une boucle de régulation d'onduleur à la chute de tension que le relais vient de prolonger.

Imaginez une ligne de 138 kV équipée d'un système de réenclenchement automatique sur un bus qui alimente également une centrale solaire de 60 MW. Une injection en boucle ouverte confirme que le relais se déclenche et lance un réenclenchement dans les délais prévus. Seul un test en boucle fermée montre que la centrale résiste à la première chute de tension, se déclenche lors de la deuxième et laisse le réenclenchement alimenter une source bien moins puissante que celle prévue dans le fichier de réglage.

Les relais se comportent exactement comme prévu, tandis que le schéma aboutit à un résultat que personne n'avait prévu, car chaque dispositif a été vérifié isolément. L'injection reste rapide et utile pour la vérification des éléments. Elle ne permet toutefois pas de répondre aux questions relatives aux interactions, et c'est là que les schémas modernes échouent.

Fonctionnement des tests de relais en boucle fermée avec simulation en temps réel

Les essais de relais en boucle fermée consistent à intégrer un relais physique dans la boucle de commande d'un modèle de réseau électrique fonctionnant en temps réel. Le simulateur calcule la réponse du réseau toutes les 25 à 50 microsecondes, transmet les tensions et les courants au relais, reçoit en retour les signaux de déclenchement et de fermeture, puis les applique au disjoncteur du modèle au cours du même pas de temps.

L'interfaçage s'effectue de deux manières. Les signaux analogiques amplifiés pilotent les entrées d'un relais traditionnel, tandis que les systèmes numériques de sous-station acheminent les valeurs échantillonnées selon la norme CEI 61850 vers le port du bus de processus. Les signaux de déclenchement et de blocage sont renvoyés sous forme de messages GOOSE, et les flux de synchrophasors respectent la norme IEEE C37.118 lorsque des éléments à grande échelle sont concernés. Des plateformes telles que « HYPERSIM » d’OPAL-RT publient ces trois types de données à partir d’un seul modèle, ce qui permet aux relais numériques et conventionnels de partager une même interface.

La gestion de la latence est ici plus importante que la taille brute du modèle. Un événement GOOSE arrivant avec 4 ms de retard à l'intérieur de la boucle entraîne un temps de compensation différent de celui observé sur le terrain ; c'est pourquoi la synchronisation entre l'éditeur et l'abonné est mesurée lors de la configuration plutôt que supposée.

Choix entre l'injection en boucle ouverte et la validation en boucle fermée

La principale différence entre l'injection en boucle ouverte et la validation en boucle fermée réside dans la rétroaction. L'injection consiste à diffuser une forme d'onde enregistrée ou calculée au niveau du relais et à évaluer la réponse. La boucle fermée permet au relais d'agir sur le système qu'il mesure, mettant ainsi en évidence les comportements de coordination, de stabilité et de récupération qu'un fichier de lecture fixe ne peut pas reproduire.

Les coûts et le calendrier tirent dans des directions opposées. Un ensemble de tests et un fichier de paramètres permettent de vérifier les éléments en un après-midi. La création d'un modèle en temps réel de la sous-station prend plusieurs jours la première fois, mais ne coûte ensuite presque rien à relancer à chaque révision des paramètres.

Créer des bibliothèques de scénarios de défaillance couvrant des conditions de réseau plausibles

Une bibliothèque de scénarios de défaut est un ensemble réutilisable de cas permettant de tester un schéma de coordination à chaque modification de ses paramètres. Créez-la à partir d'études de planification dont vous avez déjà vérifié la fiabilité, en couvrant les topologies de charge maximale et minimale, les défaillances N-1 qui modifient l'impédance de la source, ainsi que les types et emplacements de défauts utilisés dans votre étude de coordination.

Cinq familles de boîtes de vitesses couvrent l'essentiel des configurations de transmission rencontrées en service.

• Défauts triphasés et monophasés à la terre mesurés à 0 %, 50 % et 100 % de la longueur de la ligne
• Les défauts à la terre à haute résistance situés près du bord de l'élément de terre atteignent
• Défauts qui évoluent d'une phase à deux phases au cours de la séquence de coupure
• Réenclenchement sur un défaut persistant alors que le terminal distant est déjà ouvert
• Perte du canal de téléprotection lors d'un défaut en zone

La couverture prime sur le volume. Les causes liées à l'intervention humaine, telles que des paramètres incorrects, des erreurs logiques et des erreurs humaines non prises en compte, représentent 39 % de toutes les erreurs d'exécution enregistrées entre 2020 et 2024 ; c'est précisément le type de problèmes qu'une bibliothèque de tests permet d'éliminer. Une bibliothèque qui s'exécute à chaque révision des paramètres transforme ces causes en problèmes de régression.

Modes de défaillance permettant à des erreurs de fonctionnement d'atteindre le terrain

La plupart des dysfonctionnements qui passent inaperçus lors des essais proviennent de lacunes dans le plan de test plutôt que de défauts au niveau du relais. Ces lacunes concernent généralement des branches logiques non testées, des paramétrages modifiés après la dernière validation, une saturation des transformateurs de mesure qui n'a pas été prise en compte dans la modélisation, ainsi qu'un comportement des communications vérifié sur un banc d'essai « au repos » plutôt que sur un réseau sous charge.

La logique de défaillance du disjoncteur est la cause récurrente de ce problème. C'est la branche que personne ne teste, car son déclenchement nécessite un disjoncteur bloqué ; ainsi, le chemin d'initiation est vérifié, tandis que l'interaction avec les éléments adjacents de la zone 2 n'est pas vérifiée. Les tests en boucle fermée permettent de simuler ce cas à moindre coût, puisque le disjoncteur du modèle refuse tout simplement de s'ouvrir.

La dérive de version arrive en deuxième position. Les paramètres sont ajustés lors de la mise en service, le fichier de relais devance la version de référence testée, et le rapport de validation cesse discrètement de décrire l'appareil en service. Le fait de lier la bibliothèque de cas au fichier de paramètres au sein d'un seul système de contrôle des modifications élimine toute ambiguïté, car une révision qui n'a pas été réexécutée apparaît alors comme un élément en suspens.

« La plupart des dysfonctionnements qui passent inaperçus lors des tests sont dus à des lacunes dans le plan de test plutôt qu’à des défauts du relais. »

Ce que des essais de relais menés de manière rigoureuse apportent aux ingénieurs des services publics au fil du temps

Des séries de tests de relais menées de manière rigoureuse. Chaque scénario que vous validez en boucle fermée génère un modèle réutilisable, une bibliothèque de cas et des mesures de temps qui serviront de point de départ au projet suivant ; ainsi, la courbe de l'effort diminue tandis que la couverture augmente. C'est là le retour sur investissement, et il se reflète dans les statistiques d'interruptions de service avant même d'apparaître dans les rapports de test.

Les équipes de terrain en font les premiers les frais. Une équipe de mise en service disposant d’enregistrements des cycles en boucle fermée pour chaque zone et chaque branche logique consacre son temps sur site à valider l’installation plutôt qu’à corriger les défauts de conception. Les responsables techniques s’en rendent compte plus tard, lorsqu’une révision des paramètres nécessite un après-midi de nouveaux cycles d’essai au lieu d’une équipe de nuit et d’une interruption de la ligne.

Aucun de ces deux résultats ne dépend d’un simulateur plus puissant. Tous deux reposent sur le fait de considérer le relais comme un composant à part entière au sein d’un modèle de système, et de refuser de valider un schéma qui n’a pas été testé dans les conditions réelles auxquelles il sera confronté. Les équipes qui développent des bancs d’essai avec OPAL-RT parviennent à la même conclusion : c’est le modèle qui constitue l’actif durable. En le maintenant à jour et en veillant à ce que la bibliothèque de cas reste liée au fichier de paramètres, le schéma cessera de vous réserver des surprises.