Au tutoriel du comité d'études B5 du CIGRE, trois experts internationaux reconnus en protection et postes numériques ont montré l'étape suivante de l'évolution du secteur. Les fonctions de protection se séparent progressivement des terminaux dédiés et migrent vers des plateformes de calcul sur serveur. Mais la discussion la plus intéressante aujourd'hui ne porte plus sur la faisabilité technique, mais sur la façon de concevoir, de tester et d'exploiter de tels systèmes — et sur qui, en fin de compte, répond de leur fonctionnement.
Dans la salle du Palais des Congrès de Paris, à la table de la présidence siègent Alex Apostolov, rédacteur en chef de la revue PAC World et spécialiste chez OMICRON electronics ; Ratan Das, spécialiste chez Siemens Energy et animateur du groupe de travail de l'IEEE qui a élaboré le guide IEEE C37.300 sur la protection et la commande centralisées ; et David MacDonald, architecte solutions et normalisation chez GE Grid Automation et animateur du groupe de travail CIGRE B5.84 sur les équipements de protection virtualisés.
Le tutoriel du comité d'études B5 était consacré au développement des architectures des systèmes de protection, d'automatisation et de commande, avec une attention particulière au bus de process et à la virtualisation des équipements de protection.
Les trois exposés se sont alignés presque en une seule séquence historique.
D'abord, le lien des équipements de protection avec le matériel primaire devient numérique grâce au bus de process. Ensuite, les fonctions de protection se séparent des nombreux terminaux physiques et sont centralisées. Enfin, l'étape suivante — la virtualisation : la fonction de protection devient une application logicielle, et le serveur, une plateforme de calcul que l'on peut par la suite remplacer sans changer l'algorithme de protection lui-même.
En un peu plus de vingt ans, le secteur a parcouru le chemin des premières démonstrations de transmission de valeurs instantanées numérisées via IEC 61850 jusqu'à des systèmes de protection virtualisés fonctionnant sur des plateformes serveur.
Et la nature des questions a changé en même temps que la technologie.
Aujourd'hui, la question principale n'est plus « est-ce que ça marchera ? », mais : comment en être propriétaire, comment le tester et l'entretenir — et qui répond du système si ses composants sont fournis par des fabricants différents ?
Vingt ans de la démonstration à l'usage industriel
Le premier exposé d'Alex Apostolov était consacré au bus de process.
À sa base se trouve la brochure technique du CIGRE TB 949, « Process Bus in Protection, Automation & Control Systems », qui synthétise l'expérience accumulée par le secteur dans l'application du bus de process : solutions d'architecture, redondance, projets réels, résultats d'enquêtes auprès des exploitants et des fabricants, aspects économiques et directions futures de développement.
L'histoire s'est révélée plus longue qu'on ne l'imagine parfois.
Les travaux qui ont ensuite conduit à l'IEC 61850 ont commencé dès les années 1990. En 2004, le profil 9-2LE est devenu une étape pratique importante dans le développement de la transmission de valeurs instantanées numérisées et de l'interopérabilité des équipements de différents fabricants. Apostolov a rappelé comment, à la session du CIGRE de cette même année, ABB, Siemens et Omicron démontraient déjà des équipements fonctionnant ensemble avec des flux SV.
Cependant, une dizaine d'années se sont écoulées entre la démonstration de la technologie et son large usage industriel.
Le secteur observait de près la nouvelle architecture, accumulait de l'expérience, lançait des projets pilotes. À partir du milieu des années 2010, le nombre de déploiements a commencé à croître rapidement.
« Nous sommes à un point de bascule : la quasi-totalité des grands exploitants du monde ont pris le cap de la numérisation ».
Derrière cette conclusion se trouve un matériau assez vaste : plus de 200 publications analysées, une soixantaine de projets examinés et les résultats d'une enquête sectorielle.
La plupart des projets étudiés portent non pas sur la construction de nouveaux ouvrages, mais sur la rénovation de postes existants. C'est important : le bus de process cesse progressivement d'être une technologie réservée aux nouveaux ouvrages numériques « idéaux » et entre dans la pratique de la modernisation des postes existants.
Un petit glossaire
Pour la suite de la discussion, il est utile de définir quelques termes fixés dans la terminologie internationale.
- MU / SAMU — équipements qui convertissent les signaux analogiques de courant et de tension en flux numériques de valeurs instantanées SV.
- SCU — unité d'interface avec l'appareillage, assurant les E/S binaires.
- PIU — unité d'interface avec le process, combinant les fonctions de conversion des signaux analogiques et binaires.
Comme l'a noté Apostolov, la terminologie y est encore employée de façon pas tout à fait cohérente.
- PRP et HSR — mécanismes de redondance réseau à récupération sans perte de la transmission de données.
- PTP — le protocole de synchronisation temporelle de haute précision IEEE 1588, qui permet de transmettre l'échelle de temps directement sur le réseau Ethernet et, dans de nombreuses architectures, de se passer de lignes de synchronisation par impulsions distinctes.
Ce qui pousse le bus de process — et ce qui le freine
Les raisons de l'adoption peuvent se répartir en économiques et technologiques.
L'économie — moins de câblage cuivre et de travaux de montage, des armoires et des locaux plus compacts, une réduction du volume de travaux en rénovation et une baisse potentielle des coûts de maintenance et de modernisation.
Les avantages technologiques — une sécurité accrue du personnel, la souplesse de l'architecture, l'évolutivité, des possibilités élargies de surveillance de l'état des équipements et une base pour l'intégration fonctionnelle ultérieure.
Mais les obstacles sont eux aussi bien concrets.
Il manque aux exploitants leur propre expérience de la technologie. Les difficultés du fonctionnement conjoint d'équipements de différents fabricants sont particulièrement visibles à l'étape de conception et de paramétrage. La cybersécurité impose des exigences supplémentaires à l'architecture. De nouvelles méthodes de diagnostic et d'essais sont nécessaires.
Et, sans doute, l'une des questions les plus importantes, ce sont les outils.
La norme IEC 61850 elle-même permet de construire de nombreuses architectures différentes, mais la complexité de la configuration est encore trop souvent reportée directement sur l'ingénieur. Apostolov a souligné à part la nécessité d'outils qui doivent masquer la complexité technologique de l'IEC 61850 à l'utilisateur, au lieu de le contraindre à travailler avec elle manuellement en permanence.
« Le marché a besoin d'outils qui masqueront la complexité technologique de l'IEC 61850 à l'utilisateur, au lieu de le contraindre à travailler avec elle manuellement en permanence ».
Une question à part est l'économie.
Souvent, le poste numérique est évalué en comparant le coût de composants isolés d'une solution traditionnelle et d'une solution numérique. Mais le bénéfice réel n'apparaît qu'à l'évaluation du coût total de possession : conception, câblage, construction, mise en service, maintenance, rénovation et remplacement ultérieur des équipements.
Et c'est justement le cycle de vie qui devient particulièrement intéressant à l'étape suivante du développement.
De dix mille liaisons à la protection centralisée
Ratan Das a commencé son exposé par une histoire personnelle.
En 1981, à peine entré dans un exploitant, il a reçu la tâche de préparer le schéma des liaisons entre les équipements d'un ouvrage doté de trois groupes de production de 500 MW chacun.
Environ 10 000 liaisons.
Le concepteur élaborait les schémas, puis ils étaient vérifiés, puis tout cela devait être physiquement monté et vérifié sur l'ouvrage.
Les générations suivantes de protection ont progressivement réduit cette complexité.
Les relais électromécaniques ont cédé la place aux relais statiques, puis les terminaux à microprocesseur sont apparus. L'IEC 61850 a permis de remplacer une part importante des liaisons filaires par un échange numérique.
La question logique suivante est apparue il y a une dizaine d'années : si les mesures analogiques et les signaux binaires sont déjà disponibles via le bus de process, est-il obligatoire que chaque tranche ait son propre terminal de calcul ?
C'est ainsi qu'est apparu le concept de protection et de commande centralisées — CPC (Centralized Protection and Control).
Les unités d'interface restent près du matériel primaire. Elles reçoivent mesures, états et commandes. Et les algorithmes de protection et de commande sont reportés sur une plateforme de calcul centralisée au niveau du poste.
Selon Das, on peut y voir la génération suivante du développement des systèmes de protection.
« Quand, en 2013, nous avons écrit un article sur un système de protection sur serveur, beaucoup le regardaient comme une fantaisie folle. Aujourd'hui, sur les stands de cette session, la protection fonctionne précisément sur des serveurs ».
Mais la centralisation ne résout qu'une partie du problème.
Les fonctions sont déjà réunies sur une plateforme de calcul commune, mais le logiciel peut encore rester étroitement lié à la plateforme matérielle spécifique du fabricant.
L'étape suivante est de séparer l'un de l'autre.
Les fonctions à part, la plateforme matérielle à part
C'est précisément en cela que consiste l'idée d'indépendance de la fonctionnalité vis-à-vis de la plateforme matérielle — FIH (Functionality Independent of Hardware).
Le principe de base est simple : le remplacement de la plateforme de calcul ne doit pas exiger un remaniement substantiel des fonctions applicatives de protection.
Bien sûr, l'indépendance absolue n'existe pas. Une nouvelle plateforme peut nécessiter des pilotes, une vérification de compatibilité, un paramétrage de l'environnement d'exécution.
Mais l'algorithme de protection lui-même ne devrait pas avoir à être recréé à chaque fois simplement parce que le fabricant du processeur a arrêté une ancienne génération ou que le matériel serveur a changé.
C'est en cela que consiste le changement fondamental du cycle de vie.
Aujourd'hui, le terminal de protection est en fait un produit unique : les algorithmes de protection, le processeur, le système d'exploitation, les interfaces réseau, l'alimentation et le boîtier sont fournis ensemble.
Lorsque la partie matérielle devient obsolète, il faut souvent remplacer tout le terminal.
Dans un système virtualisé, la fonction applicative et la plateforme de calcul commencent à vivre des cycles de vie différents.
Pour le secteur de l'énergie, c'est particulièrement important. Le matériel primaire est exploité pendant des décennies, tandis que les plateformes de calcul évoluent bien plus vite.
En conséquence, au cours de la durée de vie du matériel primaire, plusieurs générations de moyens de calcul de protection peuvent se succéder.
Avec la nouvelle architecture, changer à chaque fois la fonction de protection elle-même n'est plus obligatoire.
Les essais peuvent augmenter, et le travail sur site diminuer
À première vue, il semble que la virtualisation devrait réduire le volume des essais.
Das a fait une réserve importante : il est plus exact de le formuler tout autrement.
On peut même réaliser davantage d'essais — mais en transférer une part importante du site vers le laboratoire.
Une application logicielle peut être testée de manière exhaustive indépendamment d'un ouvrage particulier.
Si, par la suite, seule la plateforme de calcul change, tandis que le code de la fonction de protection elle-même reste inchangé, l'ensemble des essais fonctionnels de l'application n'a plus nécessairement à être répété directement au poste.
L'essentiel de la vérification d'une nouvelle plateforme peut être fait à l'avance.
Cela change potentiellement de façon sérieuse le processus même de remplacement des équipements.
Aujourd'hui, remplacer un terminal signifie souvent un projet, des validations, une mise hors service, un montage, un paramétrage et un ensemble complet de vérifications.
Dans un système de protection défini par logiciel, le remplacement de la plateforme matérielle peut, à terme, devenir une opération bien plus standard.
Mais avec cela apparaît une question organisationnelle fondamentale : qui garantit l'ensemble du système et comment se répartit la responsabilité entre les acteurs ?
La discussion y est revenue après les exposés.
Ce que la virtualisation apporte au juste
Le troisième exposé — de David MacDonald, animateur du groupe de travail CIGRE B5.84 sur les équipements de protection virtualisés — était consacré directement à la virtualisation.
La principale différence d'un système virtualisé par rapport à un système centralisé ordinaire ne réside pas seulement dans l'usage d'un serveur.
Entre les fonctions applicatives et la plateforme matérielle apparaît une couche de virtualisation, qui permet de séparer les applications logicielles du matériel serveur spécifique et de les isoler les unes des autres.
Pour les machines virtuelles, l'élément de base d'une telle couche est l'hyperviseur — un moyen logiciel qui permet d'exécuter simultanément plusieurs machines virtuelles isolées sur un même serveur physique.
Les fonctions applicatives de protection peuvent s'exécuter dans des machines virtuelles distinctes. Une autre approche est la conteneurisation, où plusieurs applications utilisent un système d'exploitation commun mais sont isolées les unes des autres par des moyens logiciels. Une variante combinée est également possible — par exemple, placer des applications conteneurisées à l'intérieur d'une machine virtuelle.
Pour les systèmes où l'on prévoit l'usage d'applications de différents fabricants, les machines virtuelles sont particulièrement intéressantes grâce à une séparation plus stricte des environnements logiciels.
Une fonction de protection virtuelle isolée peut être déployée, testée ou mise à jour indépendamment des autres fonctions s'exécutant sur le même serveur.
C'est précisément cette possibilité qui crée les conditions préalables à des systèmes dans lesquels des applications de différents fabricants peuvent fonctionner sur une plateforme de calcul commune.
Dans un système centralisé traditionnel, cette liberté est bien moindre : les fonctions sont réunies, mais l'ensemble de la solution reste un système matériel-logiciel unique d'un seul fournisseur.
La plateforme matérielle ne disparaît pas
Ici, il importe de ne pas tomber dans un piège terminologique.
L'indépendance vis-à-vis de la plateforme matérielle ne signifie pas que n'importe quel serveur conviendra pour la protection.
Les exigences envers la plateforme de calcul restent extrêmement sérieuses.
Il faut tenir compte des performances du processeur et de la mémoire, des interfaces réseau, de la redondance de l'alimentation et des disques, des conditions d'exploitation, de la compatibilité électromagnétique, des moyens de gestion à distance, du schéma de redondance et des exigences de fiabilité.
En outre, pour chaque équipement virtuel, il faut définir les ressources de calcul requises et les caractéristiques du réseau virtuel.
Autrement dit, la virtualisation ne supprime pas la conception d'ingénierie de la partie matérielle.
Elle change autre chose : la plateforme matérielle cesse de déterminer la fonctionnalité applicative de la protection elle-même.
C'est une distinction importante.
Deux modèles de redondance
Pour un système de protection sur serveur, on peut recourir à différentes approches de redondance.
La plus évidente — deux serveurs indépendants sur lesquels s'exécutent simultanément des instances identiques des protections. Chacun est capable d'émettre son propre ordre de déclenchement.
Une variante plus complexe — un cluster de plusieurs serveurs.
Dans ce cas, un groupe de nœuds est géré comme un système de calcul unique. En cas de défaillance d'un serveur, ses applications peuvent être automatiquement redémarrées sur un autre nœud.
Pour décider de l'état des membres du cluster, on utilise un nombre impair de nœuds — par exemple trois ou cinq. Cela permet de déterminer une majorité et d'exclure le nœud défaillant.
Il est également possible de migrer une machine virtuelle d'un serveur physique à un autre.
Et c'est là qu'apparaît l'une des particularités fondamentales de la nouvelle architecture : ce qui est désormais redondé n'est pas nécessairement l'équipement physique lui-même, mais la capacité d'exécuter la fonction.
Pour un système de protection traditionnel, ces deux notions coïncidaient pratiquement.
Pour un système virtualisé — ce n'est plus le cas.
Microsecondes : là où la virtualisation rencontre le temps réel
Cependant, un système de protection sur serveur impose à l'infrastructure de calcul des exigences très différentes de celles des systèmes d'information ordinaires.
Il ne suffit pas d'assurer un temps d'exécution de la fonction court en moyenne.
La protection exige un temps de réaction prévisible et une dispersion limitée des retards, même dans des conditions défavorables.
Les systèmes d'exploitation ordinaires sont avant tout optimisés pour l'usage efficace des ressources, non pour un déterminisme temporel strict.
La virtualisation elle-même peut aussi introduire des retards supplémentaires : un paquet réseau traverse plusieurs couches logicielles avant de parvenir à l'application de protection.
Pour raccourcir ce chemin et réduire les retards, on utilise des mécanismes spéciaux d'accès direct et accéléré aux interfaces réseau — en particulier, PCI passthrough, SR-IOV et DPDK.
Une analyse détaillée de ces technologies fera l'objet d'un article distinct. Ce qui compte ici, c'est autre chose : dans un système de protection virtualisé, le chemin réseau et le mode d'acheminement des données jusqu'à l'application deviennent une partie de la conception d'ingénierie au même titre que le choix du processeur, la répartition des ressources de calcul ou le réglage du fonctionnement en temps réel.
Mais la principale conclusion de MacDonald ne portait pas sur le choix d'une technologie précise.
Le déterminisme ne peut pas simplement être déclaré. Il faut le mesurer et le confirmer par des essais.
Comment est construite la plateforme ouverte SEAPATH
Comme exemple illustratif d'architecture, MacDonald a examiné la plateforme ouverte LF Energy SEAPATH.
Ici, les équipements virtuels de protection se situent au-dessus d'un ensemble d'outils standard de virtualisation et de gestion de l'infrastructure de calcul.
On utilise Linux avec un noyau pour le fonctionnement en temps réel, KVM, QEMU et libvirt. Pour le réseau virtuel, on applique les outils logiciels correspondants, et pour construire une infrastructure tolérante aux pannes — des mécanismes de clustering.
La répartition des ressources de calcul joue un rôle important.
Les cœurs du processeur peuvent être affectés à des tâches déterminées. On tient compte de l'architecture NUMA — l'organisation de l'accès des processeurs à la mémoire vive dans les plateformes serveur multiprocesseurs. On gère les priorités des threads et le traitement des interruptions.
Autrement dit, le serveur cesse d'être simplement « un ordinateur sur lequel on a lancé la protection ».
Il devient un environnement de calcul spécialement réglé pour exécuter des fonctions critiques en temps réel.
Tester une protection sans arrêter les autres
La virtualisation offre des possibilités très intéressantes conjointement avec les mécanismes standard IEC 61850 Test et Simulation.
Imaginons que, sur un même serveur, fonctionnent les équipements virtuels de plusieurs tranches.
L'un d'eux doit être testé.
On peut le mettre en mode d'essai et lui fournir des flux SV et GOOSE simulés depuis une valise d'essai.
Pendant ce temps, les équipements virtuels voisins continuent de travailler avec les données réelles de l'ouvrage.
Les messages GOOSE de test sont marqués en conséquence, de sorte que les équipements d'actionnement restés en mode normal ne doivent pas exécuter les commandes qu'ils contiennent.
Ainsi apparaît la possibilité de localiser l'essai d'une fonction isolée à l'intérieur d'un système en fonctionnement.
Pour une architecture centralisée traditionnelle, une telle indépendance des composants logiciels isolés s'obtient bien plus difficilement.
Le déterminisme doit être prouvé sous charge
Le groupe de travail examine aussi des essais spéciaux de la plateforme de calcul.
On mesure de combien le temps réel d'exécution des tâches s'écarte de celui attendu.
De tels essais sont réalisés de nombreuses fois et sous une charge créée artificiellement sur le processeur, la mémoire et le sous-système réseau.
Le plus révélateur est l'essai de bout en bout.
La valise d'essai génère une sollicitation, la protection virtuelle la traite et renvoie un ordre GOOSE de déclenchement.
On mesure le chemin complet du signal — de la sollicitation à l'ordre de réponse.
Et la plateforme de calcul est délibérément placée dans des conditions défavorables de concurrence pour les ressources.
C'est précisément là que devient visible la différence fondamentale entre une application serveur ordinaire et une fonction de protection.
Pour la protection, ce qui compte n'est pas le meilleur résultat, ni même le moyen.
Ce qui compte, c'est la caractéristique garantie dans les pires conditions prévues.
Cybersécurité : pas d'avantages sans nouveaux risques
La centralisation et la virtualisation créent simultanément de nouveaux moyens de protection et de nouvelles menaces.
D'une part, l'isolation des machines virtuelles permet de limiter la propagation des défaillances et les conséquences de la compromission d'applications isolées.
On peut appliquer le démarrage de confiance, la vérification d'intégrité et la signature des images logicielles, la ségrégation des droits, l'authentification multifacteur et le chiffrement.
D'autre part, apparaissent de nouveaux composants critiques : l'environnement de virtualisation lui-même, le système d'exploitation du nœud, les moyens de gestion centralisée, la chaîne d'approvisionnement logicielle.
De plus, les conséquences d'une attaque réussie sur une infrastructure serveur commune peuvent potentiellement être bien plus vastes que la compromission d'un terminal isolé.
C'est pourquoi affirmer qu'un système virtualisé est « plus sûr » en soi serait trop simple.
Il est plus exact de dire que la virtualisation change le modèle de menaces et l'éventail des moyens de protection.
Questions de la salle : de la fiabilité à la responsabilité
La partie la plus intéressante du tutoriel a commencé après l'ouverture des micros.
Les questions de la salle ont bien montré à quel point la nature de la discussion professionnelle a changé.
Le débat ne portait plus sur la possibilité de la virtualisation en tant que telle, mais sur ses limites pratiques.
« Ne créons-nous pas un nouveau point unique de défaillance ? »
La première question naturelle concernait la fiabilité.
Dans un poste numérique traditionnel, des dizaines d'équipements physiques sont répartis par tranches. La défaillance d'un terminal précis est généralement localisée à un ensemble limité de fonctions.
Dans un système virtualisé, une part importante des fonctions peut dépendre de seulement quelques serveurs.
N'apparaît-il pas un nouveau point unique de défaillance ?
La réponse des intervenants fut que l'infrastructure de calcul peut être redondée de façon bien plus profonde et plus économique qu'un grand nombre d'équipements dédiés.
Une fonction de protection peut avoir plusieurs instances fonctionnant simultanément, placées sur des serveurs différents. En cas de défaillance d'un nœud, le fonctionnement peut se poursuivre sur un autre.
Mais les représentants des exploitants ont, à juste titre, attiré l'attention sur l'autre versant.
La défaillance d'un composant commun est en effet potentiellement capable de toucher de nombreuses fonctions à la fois.
C'est pourquoi on ne peut pas simplement comparer « deux terminaux » et « deux serveurs ».
Une analyse de fiabilité de toute l'architecture est nécessaire : les serveurs, les commutateurs, les cartes réseau, les alimentations, l'environnement de virtualisation, les moyens de gestion et les applications elles-mêmes.
La virtualisation ne supprime pas l'ingénierie de fiabilité traditionnelle.
Elle ne fait qu'offrir d'autres façons de construire la redondance.
« Et qui répond si le logiciel et le serveur viennent de fabricants différents ? »
La question sans doute la plus pratique est venue d'un représentant de Scottish and Southern Electricity Networks (SSEN, Royaume-Uni) — un opérateur de réseaux électriques britannique.
Supposons que la protection virtuelle a été développée par le fabricant A.
La plateforme serveur a été fournie par le fabricant B.
L'environnement de virtualisation — par le fabricant C.
La protection a mal fonctionné.
À qui le client doit-il téléphoner ?
C'est là l'une des tâches clés non résolues de la nouvelle architecture.
Les intervenants ont noté qu'un certain équivalent existe déjà aujourd'hui dans les postes numériques équipés de matériels de différents fabricants.
Des équipements de différentes entreprises sont réunis par un réseau IEC 61850 commun, mais la responsabilité du système dans son ensemble doit tout de même être attribuée à une partie précise — le client ou un intégrateur système désigné.
Pour un système de protection virtualisé, ce problème ne devient que plus visible.
Par conséquent, le secteur a besoin non seulement de normes techniques d'interfaces.
Il faut des règles de qualification des plateformes de calcul, de compatibilité des applications, de diagnostic, d'essais et de répartition contractuelle de la responsabilité.
En fait, il s'agit de la formation d'un nouveau modèle d'exploitation des systèmes de protection.
Mieux vaut parler non d'indépendance, mais d'affranchissement des contraintes
Une formulation intéressante a été proposée par un participant à la discussion de l'Electricity Supply Board (ESB, Irlande) — une compagnie énergétique irlandaise.
Selon lui, l'expression « indépendance vis-à-vis de la plateforme matérielle » ne décrit pas tout à fait exactement le problème.
Une fonction de protection traditionnelle ne « dépend » pas tant de la plateforme matérielle qu'elle en est contrainte.
La durée de vie des algorithmes de protection est souvent déterminée non par leur obsolescence conceptuelle.
Ce sont les alimentations, les convertisseurs de tension, les modules processeur qui tombent en panne. Le fabricant arrête une plateforme matérielle précise — et avec elle, il faut changer tout l'équipement.
Même si les algorithmes eux-mêmes satisfont pleinement l'exploitant.
La virtualisation rompt potentiellement ce lien.
La fonction demeure, et la plateforme de calcul peut être mise à jour de façon indépendante.
En ce sens, il s'agit en effet plutôt non d'une absence totale de dépendance matérielle, mais d'un affranchissement de la fonctionnalité applicative des contraintes d'une génération précise d'équipements.
Où s'arrête l'indépendance vis-à-vis de la plateforme matérielle
Un représentant de Schweitzer Engineering Laboratories (SEL, États-Unis) — fabricant réputé d'équipements et de solutions pour la protection, l'automatisation et la commande — a soulevé une question technique encore plus intéressante.
Les fonctions de protection standard peuvent être virtualisées et exécutées sur une plateforme serveur type.
Mais il existe des méthodes où l'algorithme est étroitement lié à un équipement de mesure dédié.
Par exemple, les protections à ondes progressives exigent une fréquence d'échantillonnage extrêmement élevée.
Dans de tels cas, transmettre un énorme flux de données vers un serveur central peut être irrationnel.
Une option consiste à effectuer un tel traitement directement dans l'unité d'interface avec le process.
Mais là non plus, tout n'est pas si simple.
Si la fonction utilise les données de plusieurs points distants, un calcul local sur un seul équipement ne résout plus le problème.
Au final, la discussion a conduit à une conclusion plus importante que l'idée de « tout reporter sur le serveur » : la virtualisation ne signifie pas la centralisation obligatoire de la totalité des fonctions.
Différents algorithmes peuvent s'exécuter à différents niveaux.
Les fonctions qui n'utilisent que des données locales et exigent un délai minimal peuvent rester près du process.
Les fonctions qui utilisent l'information de plusieurs tranches — s'exécuter au niveau du poste.
Les fonctions système — à un niveau encore plus élevé.
Autrement dit, l'avenir pourrait s'avérer non pas entièrement centralisé, mais plutôt un système de protection défini par logiciel hiérarchiquement distribué, où le lieu d'exécution de chaque fonction est choisi en fonction de ses exigences.
Et qu'en est-il de la moyenne tension ?
Une question à part concernait les réseaux de distribution.
Aux niveaux de haute tension, un terminal de protection est un élément relativement coûteux. En moyenne tension, le coût des équipements isolés est nettement plus faible.
Le sens économique de la virtualisation y subsiste-t-il ?
Les intervenants estiment que oui.
Les tableaux modernes reçoivent de plus en plus des moyens numériques intégrés de mesure et de commande. À terme, l'unité d'interface avec le process pourrait faire partie de l'appareil de coupure lui-même.
Et les fonctions de protection sont alors ajoutées par logiciel.
Il en résulte un niveau supplémentaire de séparation des cycles de vie : l'achat du matériel primaire se sépare de l'achat et du développement ultérieur des fonctions de protection et d'automatisation.
Ce sont justement les postes de distribution de masse qui pourraient, à terme, devenir l'un des plus grands domaines d'application des systèmes de protection définis par logiciel.
Au final
Le plus révélateur du tutoriel n'a pas été prononcé depuis les diapositives.
Pendant tout le bloc de discussion ouverte, presque personne n'a demandé : « À quoi sert au juste la protection virtualisée ? »
Les questions étaient autres.
Comment assurer le déterminisme requis ? Comment redonder l'infrastructure serveur ? Comment tester une fonction isolée sans toucher aux autres ? Que laisser directement près du process et que reporter sur le serveur ? Comment change la cybersécurité ? Et, enfin, qui répond du résultat si l'application, l'environnement de virtualisation et la plateforme matérielle sont fournis par des entreprises différentes ?
Pour une technologie que, il y a une dizaine d'années à peine, beaucoup percevaient comme un concept assez audacieux, c'est sans doute le meilleur indicateur de maturité.
La protection commence réellement à quitter le « fer ».
Mais le principal défi de l'étape suivante n'est plus de prouver la possibilité de principe de la virtualisation.
Le secteur devra apprendre à concevoir, qualifier, tester et exploiter la protection comme un système défini par logiciel.
Et à en juger par ce dont les spécialistes ont débattu au CIGRE 2026, cette transition a déjà commencé.