Faire évoluer les modèles traditionnels des réseaux électriques vers une approche de modélisation ouverte

Principaux enseignements

• • Les fichiers hérités doivent être refondus en fonction d'un objectif d'étude vérifié, afin de conserver les connaissances techniques utiles et d'éliminer les contraintes logicielles opaques.

  • Les logiciels libres prennent tout leur sens lorsque les ingénieurs peuvent examiner les équations, les paramètres et le comportement des composants après le transfert.

  • Une migration progressive, assortie d'objectifs de validation clairs, permettra de remplacer un outil vieillissant sans perturber les études en cours, les activités d'enseignement ni la maintenance des modèles.

Le passage prévu à un logiciel de modélisation des réseaux électriques open source permettra de préserver la valeur technique des modèles existants et facilitera l'inspection, les tests et la réutilisation de ces travaux.

Aux États-Unis, plus de 70 % des lignes de transport d’électricité et des transformateurs de puissance ont plus de 25 ans. Ces installations anciennes laissent derrière elles d’anciens fichiers d’étude, des paramètres de protection et des cas d’étude qui continuent d’influencer le travail actuel. Ces fichiers contiennent souvent des paramètres optimisés et des hypothèses d’étude dont votre équipe a encore besoin. Lorsqu’un outil vieillissant masque la logique d’un modèle ou en limite l’accès, une reconstruction ouverte permet de récupérer ces connaissances au lieu de les laisser inexploitées.

Les anciens modèles conservent leur valeur si vous les migrez

Les anciens modèles restent importants, car ils contiennent des hypothèses validées, des paramètres optimisés et une logique d'analyse que votre équipe a déjà utilisés. Vous devez conserver ces connaissances lorsque le package d'origine bloque l'accès ou la révision. Une reconstruction minutieuse permettra de préserver ce travail utile. Une réinitialisation complète vous fera perdre le contexte dont vous avez encore besoin.

Un cas d'étude de stabilité transitoire pour un couloir de 230 kV illustre bien ce point. Même si l'ancien fichier ne s'ouvre peut-être que sur un seul poste de travail, les commandes du générateur, la séquence de perturbation et les données de ligne témoignent toujours d'un travail d'ingénierie solide. En transférant ce cas d'étude, vous préservez une conception qui a fait ses preuves. Vous ne conservez pas chaque ancien bloc simplement parce qu'il existe.

Cette différence déterminera le déroulement de la migration. Certaines parties d'un fichier existant seront transférées telles quelles, d'autres seront simplifiées, et d'autres encore ne passeront pas le cap de la révision. Votre objectif est d'obtenir un modèle qui réponde toujours à la question de l'étude, mais avec une structure plus claire et une logique plus visible. C'est ainsi que l'on modernise les anciens modèles de réseaux électriques sans perdre les éléments essentiels.

Commencez par les études que votre équipe utilise encore

L'ordre de migration doit tenir compte des pratiques techniques actuelles, des contraintes de conformité et des besoins pédagogiques. Commencez par les études que les utilisateurs continuent d'exécuter et auxquelles ils font confiance. Cette approche permettra de réduire les risques dès le début. Elle permettra également de concentrer les efforts là où les retards sont les plus préjudiciables. Votre équipe en percevra ainsi plus rapidement la valeur ajoutée.

Une étude de défauts sur les lignes d'alimentation utilisée chaque mois mérite qu'on s'y attarde avant de se pencher sur un cas concernant une unité mise hors service. Il en va de même pour un modèle de laboratoire que les étudiants utilisent encore chaque semestre ou pour une étude d'interconnexion qui sert toujours de base aux démarches d'homologation. Vous constaterez généralement qu'un petit nombre de fichiers représente l'essentiel de la charge de travail. C'est cette liste restreinte qu'il convient de traiter en priorité.

• Études relatives aux limites d'exploitation actuelles
• Fichiers utilisés pour l'analyse des paramètres de protection
• Modèles liés à des activités d'enseignement ou de recherche reproductibles
• Les boîtes qu'une seule personne peut encore ouvrir
• Fichiers contenant des données sources que vous pouvez encore vérifier

Cette approche garantit la faisabilité de la migration. Elle met également en évidence les risques cachés, tels qu’un fichier relais enregistré dans un format incompatible avec vos ordinateurs actuels. Les équipes qui s’appuient sur des études en cours instaurent plus rapidement un climat de confiance, car les ingénieurs peuvent comparer des résultats qui leur sont familiers. Cela facilite le remplacement d’un logiciel de simulation de réseaux électriques vieillissant sans interrompre le travail.

Optez pour un logiciel de modélisation de réseaux électriques ouverts afin d'assurer la traçabilité

Les logiciels de modélisation de réseaux électriques ouverts sont essentiels, car les modèles transférés doivent rester lisibles après le transfert. Les ingénieurs doivent pouvoir examiner les équations, les paramètres et les choix de solveurs sans avoir à deviner.

« Dans ce cas précis, la traçabilité primera sur la commodité. »

Prenons l'exemple d'un modèle d'excitateur issu d'une bibliothèque héritée verrouillée. Si le nouveau fichier n'affiche qu'une icône verrouillée et quelques paramètres de premier niveau, votre équipe ne pourra toujours pas vérifier les gains, les limites et la saturation. Une version modifiable permet d'accéder à la fonction de transfert, aux valeurs des paramètres et à la logique de contrôle. Cette visibilité offre aux réviseurs des éléments concrets à vérifier.

Le choix des outils doit tenir compte de cette exigence de traçabilité. Si deux logiciels de simulation de réseaux électriques permettent de simuler la même perturbation, optez pour celui qui garantit la visibilité et la réutilisabilité de la logique du modèle. Cette norme revêt une importance particulière dans le domaine des services publics, de la recherche et de l'enseignement. On accorde davantage de crédit à un résultat lorsqu'on est en mesure de comprendre comment le modèle l'a généré.

Mettre en correspondance chaque modèle existant avec le comportement requis du système

Avant de procéder à la refonte d’un fichier existant, il convient de définir en détail le comportement requis du système. Dressez la liste des perturbations, des commandes, des protections et des sorties que l’étude doit reproduire. Cette cartographie permettra de garantir que la refonte repose sur des données factuelles. Elle empêchera également les équipes de reproduire des structures obsolètes.

Un cas de raccordement d’un parc éolien illustre bien cela. Le modèle reconstruit doit reproduire la résistance aux variations de tension, le contrôle de la puissance réactive, la limitation de courant et la reprise après défaut dans les limites d’étude que vous utilisez aujourd’hui. Il n’a pas besoin de tous les indicateurs cachés de l’ancien progiciel. C’est vous qui définissez ce que le modèle doit faire lors des tests.

Sauter cette étape donne souvent un faux sentiment de sécurité. Un schéma peut sembler familier tout en ne tenant pas compte de la seule perturbation qui importe réellement pour votre étude. Une carte comportementale vous offre un cadre clair pour la refonte, la révision et la validation. Elle fournit également aux ingénieurs hésitants une base de comparaison objective lorsqu’ils demandent pourquoi une structure existante a été simplifiée.

Les bibliothèques de composants ouvertes permettent aux ingénieurs d'accélérer le processus de reconstruction

Les bibliothèques de composants ouvertes accélèrent la migration, car elles permettent de réutiliser des modules éprouvés plutôt que de devoir décrypter chaque ancien dispositif à partir de zéro. Les ingénieurs peuvent examiner un module et l'adapter aux données de l'usine. Cela permettra de réduire le temps de reconstruction. Cela facilitera également la révision par les pairs.

Le cas d'un régulateur de turbine illustre bien l'importance de cette approche. L'ancien modèle pouvait reposer sur un objet fournisseur présentant des limites cachées et des valeurs par défaut non documentées, tandis que la version remaniée peut utiliser des blocs de contrôle modifiables liés à des paramètres clairs. SPS SOFTWARE répond parfaitement à cette exigence, car les ingénieurs peuvent examiner la logique des composants au fur et à mesure qu'ils remanient les modèles de machines, de lignes, de convertisseurs et de contrôle. Le fichier final est ainsi plus facile à réviser et à enseigner.

La réutilisation ne fonctionne que si l'élément réutilisé reste visible. Si une bibliothèque permet de gagner du temps mais masque des équations, vous reproduirez le même problème de confiance dans un nouveau package. Les composants ouverts transforment la migration en une méthode de modélisation reproductible, plutôt qu'en une opération de sauvetage ponctuelle. Cette différence est essentielle pour travailler plus rapidement aujourd'hui et faciliter la maintenance à l'avenir.

Les flux de travail basés sur MATLAB facilitent le transfert de modèles

Un flux de travail basé sur MATLAB facilite la migration, car les données existantes se trouvent souvent déjà dans des scripts, des feuilles de calcul et des fichiers de paramètres. Vous pouvez transférer des valeurs, des graphiques et des routines de test en limitant les saisies manuelles. Cela permettra de réduire les erreurs de transcription. De plus, cela permettra aux ingénieurs de conserver leurs habitudes de travail.

Un modèle de convertisseur est souvent fourni avec un script contenant les valeurs de base, les gains de régulation, les données de filtrage et les perturbations de test. Lorsque le modèle reconstruit utilise toujours cette source de paramètres, vous n’avez pas besoin de saisir chaque valeur deux fois ni de gérer deux versions des mêmes données de l’installation. Cela permet tout simplement d’améliorer la cohérence. Cela facilite également la vérification des graphiques après chaque modification.

Cela revêt une importance particulière lorsque vous refontez des modèles de puissance hérités couvrant de nombreux fichiers. Les scripts partagés permettent d'assurer la cohérence des unités et des variantes de centrale, et facilitent la réexécution des mêmes tests après chaque révision. Les ingénieurs doivent toutefois continuer à examiner attentivement les hypothèses. Le travail de migration devient simplement plus clair et plus facile à reproduire.

La validation doit correspondre à l'objectif de l'étude avant le retrait du logiciel

La validation doit permettre de vérifier que le modèle reconstitué répond à la même question technique que l'ancienne étude. Il n'est pas nécessaire que les formes d'onde se superposent parfaitement lorsque l'étude porte uniquement sur le temps de coupure, la remontée de tension ou l'enclenchement des relais.

« C’est l’objectif de l’étude qui définit les critères de réussite. »

Le cas de la coordination des relais en est un bon exemple. Si les anciens et les nouveaux modèles se déclenchent au même courant et dans la même plage de temps, de légères différences dans les courbes internes n’auront pas d’incidence sur les résultats de l’étude. Les enjeux sont d’autant plus importants que les coupures de courant liées aux conditions météorologiques coûtent à l’économie américaine entre 18 et 33 milliards de dollars chaque année. La validation doit tenir compte de ce contexte sans rechercher la perfection visuelle.

Des critères de conformité clairs permettront également de mettre fin aux débats. Une étude sur les défauts transitoires peut exiger un rétablissement de la tension dans une plage définie après un délai de déclenchement donné, tandis qu’une étude de protection s’intéressera davantage au niveau de déclenchement et à la temporisation. Si un fichier remanié ne répond pas à ces critères, il n’est pas prêt. S’il les satisfait, vous pouvez retirer l’ancien progiciel en toute confiance.

Une migration par étapes permet aux ingénieurs de continuer à travailler pendant la transition

Une migration progressive permet à votre équipe de rester productive, car les anciens et les nouveaux modèles peuvent fonctionner en parallèle jusqu’à ce que le nouveau système ait fait ses preuves. Vous ne devriez mettre hors service l’ancien système qu’une fois que les études clés auront été validées, que les utilisateurs auront été formés et que la responsabilité de son exploitation aura été clairement définie. Cette approche permettra de protéger les travaux en cours. Elle permettra également de clarifier les responsabilités.

Une migration pratique commence souvent par une étude pilote, suivie d'un petit groupe de cas répétés, puis de tous les nouveaux travaux réalisés dans l'outil ouvert. Une équipe d'exploitation peut conserver l'ancien progiciel pour effectuer des vérifications d'archives pendant la première phase, tandis que les études mises à jour sur l'alimentation et la protection sont transférées vers l'ensemble reconstruit. SPS SOFTWARE facilite cette transition, car les ingénieurs peuvent reconvertir les fichiers en modèles modifiables qui restent lisibles pour la personne qui en assurera la maintenance par la suite. Cette visibilité perdurera au-delà de la migration elle-même.

C'est là le critère qui importe le plus. Les anciens modèles ne doivent être conservés que tant qu'ils vous aident à répondre aux questions techniques actuelles et à former le prochain ingénieur qui reprendra le flambeau. Une migration progressive permet de valoriser le travail déjà accompli sans pour autant se laisser paralyser par les anciens logiciels. Si cette transition est menée de manière rigoureuse, vous conserverez les aspects physiques utiles, vous vous débarrasserez des éléments superflus cachés et vous obtiendrez au final des modèles auxquels vous pourrez faire confiance.