Un guide complet sur les tests de Simulation HIL pour les ingénieurs en systèmes électriques

Principaux enseignements

• Les paramètres de protection sont validés avant qu’un contrôleur DER n’entre dans la boucle ; par conséquent, une marge de coordination qui varie lors du deuxième passage est imputable au DER et à rien d’autre.
• La répartition des responsabilités entre les différentes étapes et les dossiers de transfert versionnés entre les services de planification, d’ingénierie de protection et d’exploitation déterminent jusqu’où un programme HIL d’un service public peut réellement aller.
• L'exécution simultanée des normes CEI 61850 et IEEE C37.118 sur un même modèle de réseau permet aux équipes de la salle de protection et de la salle de contrôle de consulter un seul enregistrement d'événement au lieu de deux reconstitutions distinctes.

Les services publics bénéficient d'une protection fiable et de solutions d'interconnexion des ressources décentralisées (DER) lorsque les tests de la norme « Simulation HIL » sont menés sous la forme d'un programme séquentiel plutôt que d'une série de sessions de banc d'essai isolées.

La file d'attente ne cesse de s'allonger. Fin 2025 , environ 2 060 GW de capacités de production et de stockage étaient en attente d'un raccordement au réseau de transport à travers les États-Unis. Chaque projet finit par devenir un paramètre à vérifier, un modèle à valider ou un contrôleur à accepter. Le temps passé sur les bancs d'essai ne peut pas s'adapter au rythme de croissance de la file d'attente ; c'est donc l'ordre des opérations qui devient la contrainte.

Un banc de relais permet de répondre aux questions concernant un seul équipement. Un workflow HIL utilitaire permet de répondre aux questions relatives à une étude qui a débuté au stade de la planification, s'est poursuivie par la phase d'ingénierie de protection et s'achève par la mise en service d'une nouvelle ressource d'alimentation par le service d'exploitation. Un seul modèle de simulation prend en charge ces trois aspects, et une bonne gestion des transitions a un impact plus important sur le calendrier que n'importe quel cas de test, aussi ingénieux soit-il.

Ce qu'un programme HIL de services publics couvre au-delà d'un simple test de relais

Un programme HIL utilitaire couvre quatre aspects qu'un simple test de relais ne permet pas de vérifier. Il valide le modèle de réseau, les paramètres de protection qui y sont appliqués, les réponses des contrôleurs des ressources décentralisées (DER) dans le cadre d'un même ensemble de défauts, ainsi que les procédures d'exploitation qui suivent un déclenchement. Ces quatre éléments sont testés dans le cadre d'une seule simulation en temps réel de la même ligne de distribution.

Une équipe de planification du réseau de distribution commence généralement par une étude de court-circuit d’une ligne d’alimentation de 12,47 kV alimentant un nouveau site solaire de 5 MW, qui montre que le courant de défaut au niveau du réenclencheur diminue dès que le site est mis en service. Pour en faire un cas de référence, il faut modéliser la ligne d’alimentation sous forme de modèle de transitoire électromagnétique, intégrer le contrôle du réenclencheur et le relais du site dans la boucle, puis simuler les défauts avec le site en service et hors service.

Ces quatre cibles présentent des défaillances différentes et appartiennent à des personnes différentes. Une erreur de modélisation se traduit par un courant de défaut qui ne correspond pas aux données relevées sur le terrain. Une erreur de paramétrage se traduit par un relais qui se déclenche correctement, mais trop lentement. Une erreur du régulateur n'apparaît que lorsque la ressource décentralisée (DER) subit une chute de tension. Le fait de tester l'ensemble sur un seul banc d'essai permet de distinguer ces différentes défaillances.

Validation de la protection de séquencement et raccordement des ressources énergétiques distribuées (RED) sur un même banc d'essai

La validation des protections passe en premier, suivie de celle de l'interconnexion des ressources décentralisées (DER), car les cas relatifs aux DER reposent sur des paramètres dont la validité a déjà été démontrée. Si l'on procède dans l'ordre inverse, chaque résultat concernant les DER repose sur une hypothèse de paramètres non vérifiés, et un cas d'échec ne permet pas de déterminer quelle couche a présenté une défaillance.

Imaginons une sous-station équipée d’un nouveau site de batteries de 20 MW raccordé au même bus de 25 kV que trois lignes de distribution existantes. La simulation de protection reproduit des défauts proches et éloignés sur le différentiel du bus et les éléments de surintensité des lignes de distribution, sans prise en compte des ressources décentralisées (DER), confirmant ainsi que les marges de coordination sont respectées. Ce n’est qu’une fois ce test réussi que le contrôleur de batterie entre en boucle. Toute variation de marge observée lors du deuxième test est imputable aux ressources décentralisées (DER), ce qui justifie pleinement la journée supplémentaire de test au banc.

« La validation des protections passe en premier, suivie de celle de l'interconnexion des ressources décentralisées (DER), car les cas concernant les DER reposent sur des paramètres qui ont déjà fait leurs preuves. »

Qui est responsable de chaque étape et quels éléments sont transmis d'un groupe à l'autre ?

Le service de planification est responsable du modèle de réseau, le service d'ingénierie de protection est chargé des paramètres et de l'ensemble des défauts, tandis que le service d'exploitation est responsable des critères d'acceptation et des procédures de commutation. Chaque service transmet au suivant un ensemble défini de données plutôt que de simplement lui transmettre un fichier, et c'est précisément à ces points de transfert que les programmes HIL des services publics rencontrent généralement des difficultés.

Un dispositif de transition efficace entre ces groupes repose sur cinq éléments.

• Le modèle de réseau validé, dont les impédances des sources et les paramètres de ligne ont été ajustés en fonction des données de terrain
• La liste des défauts convenue, précisant les emplacements, les types et les durées, approuvée avant le début des essais au banc
• Le fichier de paramètres du relais, tel qu’il sera chargé dans l’appareil de terrain
• La configuration du contrôleur DER, y compris les courbes de maintien en fonctionnement, et la version du micrologiciel soumise aux tests
• Les critères de réussite exprimés sous forme de grandeurs mesurées, telles que le temps de déclenchement et le rétablissement de la tension

La version du micrologiciel est l'élément le plus souvent négligé, et c'est celui qui réserve les pires surprises. Un fichier de paramètres qui a été validé en mars se comportera différemment sur un appareil livré en juillet avec une version plus récente. L'équipe de planification se doit de faire preuve de la même courtoisie envers les équipes en amont, en leur communiquant l'impédance de source qu'elle a utilisée afin que les ingénieurs en protection n'aient pas à procéder ultérieurement à une rétro-ingénierie du courant de défaut.

« Chaque groupe remet au suivant un ensemble de fichiers bien défini plutôt que de simplement transférer des fichiers, et c'est précisément à ces points de transfert que les programmes HIL utilitaires se bloquent généralement. »

Rôle de l'Simulation HIL de puissance dans le cadre de la simulation HIL des contrôleurs

La principale différence entre le HIL de puissance ( Simulation HIL ) et le HIL de contrôleur ( Simulation HIL ) réside dans ce qui traverse la frontière. Le HIL de contrôleur échange des signaux et des messages de bas niveau avec un relais ou un contrôleur, tandis que le HIL de puissance envoie le courant et la tension réels à travers un amplificateur vers un équipement physique. Les services publics utilisent les deux, à différentes étapes.

Les essais de réception des relais et des contrôleurs de ressources décentralisées (DER) s'effectuent presque exclusivement sur un système HIL dédié aux contrôleurs. Un ingénieur en protection chargé de valider un élément de distance envoie des grandeurs secondaires analogiques et des points d'état au relais, puis relit la position du contact de déclenchement. Le HIL de puissance prend tout son sens lorsque l'élément testé fournit ou absorbe de la puissance réelle, comme c'est le cas pour un convertisseur à pleine charge, où le comportement sous charge est déterminant.

Le coût détermine la répartition. Le système HIL de puissance nécessite un amplificateur adapté à l'équipement, ainsi que des verrouillages de sécurité et de l'espace au sol ; c'est pourquoi la plupart des services publics disposent d'une baie d'alimentation et de plusieurs postes de contrôle. La plupart des questions relatives à la protection et aux ressources énergétiques décentralisées (DER) trouvent leur réponse au niveau des signaux.

Comment les normes CEI 61850 et IEEE C37.118 acheminent le trafic des relais et des PMU

La norme CEI 61850 achemine le trafic de protection, tandis que la norme IEEE C37.118 achemine le trafic de synchrophasors. Les messages GOOSE transmettent les signaux de déclenchement et de blocage entre le simulateur et le relais en quelques millisecondes ; les valeurs échantillonnées véhiculent le courant et la tension numérisés ; enfin, la norme C37.118 transmet des phasors horodatés à l'application à grande échelle soumise aux tests.

Une sous-station construite autour d'un bus de processus permet de réaliser une configuration épurée sur banc d'essai. Le simulateur publie des valeurs échantillonnées sur ce bus, le relais s'y abonne exactement comme il le ferait sur site, et le signal GOOSE de déclenchement revient vers le simulateur pour ouvrir le disjoncteur modélisé. La configuration du relais reste identique entre le banc d'essai et la sous-station, et c'est justement là tout l'intérêt.

Le trafic PMU remplit une fonction différente sur le même banc. Les flux C37.118 permettent de reproduire un défaut ou un déclenchement DER dans un estimateur d’état et de voir ce qu’aurait observé le personnel de la salle de contrôle. Le module « HYPERSIM » héberge le modèle de réseau, tandis que ces deux piles de protocoles prennent en charge les interfaces relais et PMU ; ainsi, les services de protection et d’exploitation lisent un seul événement plutôt que deux reconstructions de celui-ci.

Modes de défaillance courants qui apparaissent à un stade avancé des programmes HIL des services publics

Les défaillances tardives sont dues à des réglages qui n’ont jamais été validés par rapport aux capacités de l’équipement, à des modèles qui ne correspondent pas à la réalité du terrain et à des transferts au cours desquels un numéro de version a été perdu. Ces trois problèmes sont peu coûteux à détecter en laboratoire, mais coûteux à corriger une fois l’installation mise sous tension.

Les paramètres de protection des onduleurs constituent l’exemple le plus flagrant. Un seul défaut phase-terre de 500 kV, survenu en mars 2024, a entraîné la perte de 1 046 MW de production solaire et éolienne dans 28 installations du réseau Western Interconnection ; l’analyse qui a suivi a révélé que moins d’un tiers des paramètres d’onduleurs déclarés correspondaient à la capacité réelle des équipements. Un test de maintien en service par rapport au contrôleur réel montre immédiatement si une unité se déconnecte alors qu’elle se trouve bien en deçà de sa capacité nominale de résistance.

Une incohérence entre les modèles se manifeste plus tard et a des conséquences plus graves. Une impédance de source simulée de manière trop optimiste fausse toutes les marges de coordination vérifiées en laboratoire dans le même sens, et vous ne vous en rendrez compte qu’au moment où un défaut réel se produira. La dérive de version est le troisième facteur. Un fichier de paramètres, une configuration de contrôleur et une version de micrologiciel ont chacun leur propre version, et un programme qui n’enregistre pas ces trois éléments validera quelque chose que le terrain ne recevra jamais.

Assurer la pérennité du processus de travail au fil des cycles de projet successifs

Un workflow HIL utilitaire s'avère pérenne au fil des années lorsque le modèle, l'ensemble de défauts et les critères de réussite sont gérés comme des actifs permanents plutôt que comme des éléments résiduels d'un projet. Chaque nouvelle interconnexion part alors d'une base validée plutôt que d'une nouvelle construction, ce qui permet de réduire le nombre d'heures de test par projet.

Les services publics qui y parviennent ne multiplient pas les tests. Ils effectuent les mêmes tests sur un modèle qui ne cesse de s'améliorer, avec des paquets de transfert portant des numéros de version et un registre d'événements partagé. Cette rigueur porte ses fruits dès la deuxième année, lorsqu'une nouvelle demande de DER ne prend plus que deux semaines au lieu de deux mois.

C’est là tout l’intérêt de construire le programme autour d’un seul plateforme de simulation plutôt que d’une série de modules disparates. Les utilisateurs d’OPAL-RT ont souvent tendance à arriver avec une question précise et à rester parce que ce même modèle et ces mêmes interfaces de protocole continuent d’apporter des réponses à leurs questions suivantes. La valeur ne réside pas dans un test en particulier, mais dans le fait de ne jamais avoir à repartir de zéro à chaque nouveau projet.