Si l'on essayait de choisir le seul thème qui s'est manifesté le plus nettement dans la partie exposition de CIGRE 2026 à Paris, pour nous ce fut la virtualisation de la protection.
Et il ne s'agit plus d'un seul produit expérimental ni d'un beau concept sur des diapositives. En quelques heures de parcours du salon, nous avons rencontré ce thème sur les stands d'ABB, Siemens, Moxa, Welotec, Kalkitech et d'autres. Certaines entreprises proposent directement des fonctions de protection virtualisées, d'autres les serveurs sur lesquels ces fonctions doivent tourner, d'autres encore assemblent, à partir de composants de différents fabricants, des architectures multi-fournisseurs pratiquement prêtes.
Et plus nous discutions avec les représentants des entreprises, plus il devenait évident : la question clé n'est plus ici « peut-on faire tourner la protection dans une machine virtuelle ? ». Bien sûr que oui. Bien plus intéressante est une autre question : qui définit désormais l'architecture matérielle et répond de la fiabilité de toute cette plateforme de calcul ?
ABB : la protection se sépare définitivement du « fer »
L'un de nos premiers arrêts a été le stand d'ABB.
La protection centralisée n'est pas nouvelle pour ABB. Le portefeuille de l'entreprise comprend depuis plusieurs années le SSC600 — un équipement dans lequel les fonctions de protection et de commande, traditionnellement réparties entre les terminaux de chaque tranche, sont centralisées au niveau du poste.
L'étape suivante a été le SSC600 SW. Dans ce cas, de la plateforme matérielle dédiée d'ABB ne reste plus que l'implémentation logicielle. ABB décrit officiellement le SSC600 SW comme un produit purement logiciel, livré sous forme de machine virtuelle et destiné à fonctionner dans des environnements KVM et VMware ; le client peut utiliser la plateforme matérielle de son choix.
C'est justement la conversation avec les représentants d'ABB qui s'est avérée particulièrement intéressante.
La logique de livraison ressemble à peu près à ceci : l'image logicielle à déployer sur une machine virtuelle peut être obtenue séparément, la fonctionnalité requise étant ensuite activée par licence. Selon les représentants de l'entreprise sur le stand, une version pour un usage sur la plateforme ouverte SEAPATH est également en préparation.
Mais ce n'est même pas cela qui s'est révélé le plus important.
ABB s'abstrait presque entièrement de la façon dont le client construira l'infrastructure de calcul. L'entreprise est prête à formuler les exigences de performance du serveur selon le nombre et la composition des fonctions mises en œuvre, mais le choix de l'architecture matérielle précise reste à l'intégrateur système et au client.
De plus, nous avons demandé à part s'il existe des restrictions de principe au placement d'autres applications sur le même serveur physique. La réponse fut négative. Sur des machines virtuelles voisines pourraient tourner, par exemple, un SCADA, un contrôleur de communication et même des fonctions de protection virtualisées d'autres fabricants.
Et c'est ici qu'apparaît le revers de l'indépendance matérielle.
À la question de savoir exactement comment doit être construite une architecture serveur tolérante aux pannes, nous n'avons pas obtenu de réponse univoque. La redondance des nœuds de calcul, l'architecture de disponibilité continue/haute, le comportement en cas de défaillance d'un serveur physique — tout cela ne se trouve plus à l'intérieur du produit ABB, mais devient l'objet de la conception du système dans son ensemble.
Il s'agit d'un déplacement assez fondamental de la frontière de responsabilité.
Dans un terminal de protection traditionnel, le concepteur de l'équipement contrôle le processeur, le système d'exploitation, les interfaces matérielles et une bonne partie des mécanismes de garantie de la fiabilité. Dans le monde virtualisé, le fabricant fournit les fonctions de protection sous forme de logiciel, plus les exigences de l'environnement d'exécution. Et la tolérance aux pannes de toute la plateforme doit désormais être conçue par l'intégrateur, conformément aux exigences du client final. En réalité, le client peut déjà ici définir une plateforme matérielle type — et pas seulement matérielle, mais aussi logicielle, quant à l'environnement de déploiement des machines virtuelles, leur nombre, etc.
Un autre exponat intéressant d'ABB complétait bien ce tableau — le compact REX600, qui reçoit les signaux de transducteurs de mesure de faible puissance et remplit les fonctions de convertisseur de signaux analogiques. L'équipement peut aussi remplir des fonctions locales de protection de secours. ABB le positionne comme un élément intégrable au SSC600 et au SSC600 SW ; il prend en charge, entre autres, l'IEC 61869-9 et l'IEC 61869-13.
Le résultat est une architecture très caractéristique : près du matériel primaire reste une interface procédé relativement simple, tandis que les principales fonctions de calcul migrent vers une plateforme centralisée.
Moxa : si la protection est devenue un logiciel, où va-t-elle tourner ?
Des représentants d'ABB, nous avons obtenu les noms de deux fabricants de plateformes matérielles déjà utilisées ou envisagées par les clients pour de telles tâches : Moxa et Welotec.
C'est pourquoi l'arrêt suivant fut, tout naturellement, le stand de Moxa.
Et pratiquement au centre de l'exposition se trouvait en effet le DA-920E — un nouveau serveur sans refroidissement actif (de type sans ventilateur), positionné par l'entreprise spécifiquement comme plateforme pour Virtual Protection, Automation and Control — vPAC.
Ce n'est plus un ordinateur industriel ordinaire. Le DA-920E est au format 2U et répond aux exigences de l'IEC 61850-3, de l'IEEE 1613 et de l'IEC 60255. Au cœur, un Intel Xeon D-1834 à 8 cœurs et 16 threads ; jusqu'à 256 Go de RAM ECC pris en charge, quatre SSD 2,5 pouces avec RAID et un disque NVMe séparé, ainsi qu'une extension PCIe. Moxa relie directement ce produit au passage à la protection virtualisée.
Ici, on ressent particulièrement bien la formation d'un nouveau marché.
Un fabricant de protection n'a plus nécessairement à développer sa propre unité de calcul dédiée. Apparaissent des plateformes matérielles indépendantes, conçues précisément pour l'exploitation directement sur les ouvrages électriques.
Autrement dit, le mouvement ne va pas de l'équipement dédié directement à un serveur ordinaire de centre de données. Se forme plutôt une classe intermédiaire d'équipements : architecture x86 standard, mais dans une exécution conçue pour l'environnement électromagnétique et les conditions d'exploitation d'un poste.
Cependant, l'exponat le plus inhabituel de Moxa pour nous ne fut pas du tout le serveur.
Sur le stand, on montrait un prototype de récepteur GNSS/GPS réalisé au format SFP. Une antenne externe se connecte au petit module, qui est ensuite installé directement dans le port SFP d'un commutateur compatible. L'idée est qu'un tel module permet au commutateur lui-même de jouer le rôle de source de temps précis et de PTP Grandmaster, sans serveur de temps séparé.
Pour les petits postes, l'idée paraît extrêmement séduisante : l'équipement de synchronisation séparé se « replie » littéralement en un module SFP.
Mais pour l'instant, c'est justement un prototype. Et s'il devient un produit réel, la question principale ne sera plus son format impressionnant, mais la maturité de la mise en œuvre. Avec quelle souplesse les profils PTP seront-ils configurés ? Comment l'équipement se comportera-t-il en cas de perte du GNSS ? Comment se fera le rétablissement de la synchronisation ? Avec quelle stabilité fonctionnera-t-il dans divers régimes transitoires ?
C'est le cas où une très belle idée d'ingénierie doit encore prouver son aptitude à l'exploitation réelle.
Welotec : toute l'architecture dans une seule armoire
Sur le stand de Welotec, nous avons vu non pas un élément isolé, mais une démonstration pratiquement assemblée de ce à quoi peut ressembler une protection virtuelle multi-fournisseurs.
À la base se trouvait le RSAPC Mk2 — Rugged Substation Automation Computer. C'est aussi un serveur 2U d'exécution pour poste, sans ventilateur, avec IEC 61850-3 et IEEE 1613. En configuration maximale, on utilise un Intel Xeon W à 8 cœurs et 16 threads ; la plage de température annoncée va de −40 à +70 °C. Welotec propose pour cette plateforme divers environnements d'exploitation, dont VMware ESXi, Red Hat Enterprise Linux Real Time et, fait particulièrement intéressant, une préinstallation de LF Energy SEAPATH.
Mais bien plus importante que les caractéristiques du serveur était l'architecture de démonstration elle-même.
Sur une seule infrastructure étaient réunis les composants de plusieurs fabricants. SEAPATH servait de plateforme de virtualisation, une solution ABB était présentée comme protection virtualisée, et à côté tournait le SCADA/HMI zenon de COPA-DATA. L'infrastructure réseau était représentée par Westermo, et la synchronisation temporelle — notamment par des équipements Hopf.
De fait, l'inscription « Multi Vendor vPAC Demo Setup » sur le stand de Welotec s'est avérée l'une des images les plus parlantes de tout le salon.
Elle montre le changement principal : l'automatisation des postes cesse potentiellement d'être un ensemble d'équipements finis de fabricants individuels pour devenir un système de calcul intégrable.
Le serveur peut être fabriqué par une entreprise. L'hyperviseur ou la plateforme de virtualisation — par un autre écosystème. Les équipements de protection virtualisés — par un troisième. Le SCADA — par un quatrième.
La liberté augmente considérablement.
Mais dans le même temps, il devient bien plus difficile de répondre à la question : qui répond du résultat dans son ensemble ?
La présence de deux alimentations, de RAID, de PRP/HSR ou d'interfaces réseau redondées ne signifie pas en soi la tolérance aux pannes d'un système de protection virtualisé. Il faut définir les domaines de défaillance possibles, la stratégie de redondance des nœuds de calcul, le temps de rétablissement des fonctions admissible, le comportement des machines virtuelles en cas de défaillance et les exigences de mise à jour du logiciel d'infrastructure.
Autrement dit, la virtualisation transfère une part importante de la complexité d'ingénierie de l'IED individuel vers le niveau de l'architecture du système.
Kalkitech : l'étape suivante — le poste défini par logiciel
Sur le stand de Kalkitech, nous avons de nouveau retrouvé le même thème, mais ici il était formulé de façon encore plus large — Software Defined Substation (poste défini par logiciel).
L'architecture de démonstration utilisait la plateforme serveur SYNC, un bare-metal hypervisor et plusieurs machines virtuelles. Sur le schéma, côte à côte, figuraient des fonctions de protection virtuelles, dont le propre Kalkitech VPR et le SSC600 SW d'ABB, et au-dessus — d'autres applications d'automatisation.
Kalkitech développe depuis assez longtemps le concept de Virtual Protection Relay et propose son propre IEC 61850 VPR Framework. Il comprend l'abonnement aux Sampled Values, MMS, GOOSE, la configuration SCL, des reference protection functions et des interfaces pour connecter des algorithmes de tiers.
Et si, sur le stand d'ABB, nous parlions avant tout de la virtualisation de la protection, Kalkitech pose une question plus large : si la protection peut déjà être des applications, pourquoi le SCADA, la passerelle, l'IHM, la supervision et d'autres fonctions devraient-ils nécessairement rester des équipements physiques séparés ?
Après quatre stands différents — ABB, Moxa, Welotec et Kalkitech — la coïncidence est déjà difficile à tenir pour fortuite. Autour de la protection virtualisée commence à se former un écosystème technologique à part entière.
Siemens : la virtualisation — oui, mais sous le contrôle du fabricant
Sur cette toile de fond, l'approche de Siemens paraît particulièrement intéressante.
L'entreprise démontre elle aussi une protection virtualisée — le SIPROTEC V, qui utilise les algorithmes éprouvés du SIPROTEC 5. Siemens annonce une montée en charge jusqu'à 60 IED virtuels sur une seule plateforme de calcul.
Cependant, le modèle commercial diffère nettement de l'approche d'ABB.
Siemens utilise aussi le terme « hardware independent », mais l'indépendance matérielle est ici limitée à une liste de plateformes serveur d'exécution pour poste approuvées, ou whitelisted. De plus, Siemens parle directement d'une « packaged approach » : il est prévu de fournir au client un hardware/software bundle, dans lequel SIPROTEC V et le système d'exploitation sont déjà préinstallés sur du matériel validé.
Et c'est peut-être l'une des conclusions les plus intéressantes du parcours du salon : même au sein d'une seule tendance, les fabricants choisissent des modèles différents.
L'approche d'ABB peut se décrire grossièrement comme « la protection en tant que logiciel ». Le fabricant donne un produit logiciel et les exigences en ressources de calcul, tandis qu'une bonne part de l'architecture système reste à l'intégrateur.
L'approche de Siemens est plus proche de « virtualised protection as a validated system ». Le logiciel de protection est déjà séparé de l'IED traditionnel, mais le fabricant continue de contrôler la combinaison des plateformes logicielle et matérielle.
Laquelle des deux se rapprochera le plus de la future architecture massive des postes numériques — c'est loin d'être évident pour l'instant.
Arteche : une technologie qui ne s'est jamais généralisée
Sur fond de l'histoire très dynamique de la virtualisation, le stand d'Arteche paraissait étonnamment à contre-courant.
On y présentait un transformateur de courant optique, le SDO-OCT — une solution fondée sur l'effet Faraday. Le transducteur de mesure est entièrement passif, et l'électronique active est déportée dans un bloc électronique capable de former des Sampled Values conformément à l'IEC 61869-9.
Le principe lui-même est loin d'être nouveau. Des équipements similaires étaient présentés dans les salons du secteur il y a bien des années. C'est pourquoi il nous a paru particulièrement intéressant de demander aux représentants d'Arteche : de combien le marché a-t-il progressé pendant ce temps ?
La réponse fut plutôt dessillante.
Selon les représentants de l'entreprise, l'ampleur du déploiement des transformateurs de courant optiques reste à ce jour extrêmement faible. Bien plus, plusieurs fabricants ayant travaillé sur cette technologie ont, selon leur estimation, tout bonnement fermé les lignes correspondantes.
Et visuellement, le salon ne contredisait pas cette impression : durant notre parcours, le TC optique d'Arteche s'est révélé à peu près le seul exponat de ce type à avoir retenu notre attention.
Un contraste intéressant est apparu.
Les systèmes secondaires évoluent assez vite vers une architecture définie par logiciel, la virtualisation et des plateformes de calcul indépendantes. Tandis que la révolution des transducteurs de mesure primaires, promise au secteur il y a bien des années, avance pour l'instant beaucoup plus lentement.
Attrait technologique et adoption massive, on le sait, sont loin d'être toujours la même chose.
Hopf : 30 kilomètres entre l'antenne et l'horloge
Une autre découverte inattendue pour nous a été l'entreprise Hopf. Nous l'avons d'abord remarquée dans la démonstration multi-fournisseurs de Welotec, où son équipement était utilisé dans le système de synchronisation temporelle, après quoi nous avons décidé de passer sur son propre stand.
Hopf est spécialisée dans les systèmes de temps unifié. Sur le stand étaient présentés divers serveurs de temps, dont des versions à haute stabilité à oscillateurs au rubidium.
Mais ce qui a le plus retenu notre attention fut un petit composant du système d'antenne.
Il s'agit d'un convertisseur permettant de transporter le signal entre une antenne GNSS et un serveur de temps par fibre optique. Une portée allant jusqu'à 30 km était annoncée sur le stand.
À première vue, c'est un équipement plutôt de niche. Mais du point de vue d'un ouvrage réel, l'idée est très intéressante.
Dans le cas ordinaire, la longueur du trajet coaxial d'une antenne GNSS est limitée par l'atténuation. Même dans la documentation de Hopf pour ses propres systèmes d'antenne, un câble standard est limité à des dizaines de mètres et, avec certains types de câbles et amplificateurs, on parle déjà de centaines — mais pas de dizaines de milliers — de mètres (ces câbles n'étant toutefois plus aussi souples).
Le passage à la fibre change fondamentalement la donne.
L'antenne peut être déportée à une distance importante de l'ouvrage protégé — par exemple là où la vue du ciel satellitaire est meilleure ou où il est plus simple de satisfaire aux exigences d'implantation. Dans le même temps, disparaît le long trajet conducteur entre l'antenne extérieure et l'équipement à l'intérieur du bâtiment, ce qui est intéressant aussi du point de vue de l'isolation galvanique et de la protection contre la foudre.
C'est un bon exemple du fait que les choses vraiment intéressantes, dans un grand salon, sont loin d'occuper toujours la place centrale du stand.
Ce que le salon a montré au final
Après avoir parcouru ces stands, notre principale conclusion n'est pas que « la protection virtualisée est apparue ». Cette idée existe depuis plusieurs années déjà.
Autre chose a changé : autour d'elle, un marché commence à apparaître.
Il y a des fonctions en tant qu'applications chez ABB et Siemens. Il y a des plateformes de calcul dédiées de Moxa et Welotec. Il y a l'environnement ouvert SEAPATH. Il y a des entreprises comme Kalkitech, qui voient déjà la virtualisation comme la base d'un Software Defined Substation plus large. Apparaissent des démonstrations multi-fournisseurs où les produits de différents fabricants fonctionnent réellement au sein d'une seule architecture.
Ce qui signifie que la prochaine étape du développement portera non plus tant sur la preuve de la viabilité de principe de la protection virtuelle que sur l'ingénierie système.
Comment redonder les plateformes de calcul ? Comment définir les domaines de défaillance admissibles ? Peut-on placer le SCADA et la protection sur les mêmes serveurs physiques ? Qui répond de la mise à jour de l'hyperviseur ? Comment valider le système après un changement d'infrastructure ? Où passe la frontière de responsabilité entre le fournisseur des fonctions de protection et l'intégrateur système ?
Sur un poste numérique classique, l'un des objets clés de la conception était le réseau IEC 61850.
Il semble que le poste défini par logiciel gagne un objet de ce type de plus — l'infrastructure de calcul elle-même.
Et c'est peut-être précisément là que réside le changement majeur que l'on peut voir aujourd'hui à CIGRE.
La protection cesse peu à peu d'être seulement un équipement.
Elle devient une fonction logicielle.
Et avec cela, le client final, le concepteur et l'intégrateur système devront apprendre à concevoir non seulement la protection, le réseau et le système de synchronisation, mais aussi la plateforme sur laquelle cette protection vit.