Un pilote vPAC en 2026 dispose d’un large éventail de produits à choisir. L’ABB SSC600 SW, le GE PhasorController, le Siemens SIPROTEC V, la plateforme de référence LF Energy SEAPATH qui a atteint la version 1.0 en février 2025, ainsi qu’une longue série d’offres des membres de l’Alliance vPAC. Chacun d’entre eux apporte sa propre réponse aux mêmes questions d’ingénierie : quelle interface IEC 61850 un dispositif électronique intelligent (DEI) virtualisé doit-il exposer, comment est-il configuré, comment est-il synchronisé en temps réel, comment est-il supervisé en exploitation, et comment est-il mis à jour sans mettre la sous-station hors service ?

Ce qui manquait jusqu’à présent, c’est un cadre industriel qui fixe ces réponses — et ce cadre est en train d’être rédigé. Le groupe de travail CIGRE B5.84 — intitulé en intégralité « Recommandations et contraintes pour le développement et l’interfaçage des dispositifs électroniques intelligents virtualisés mis en œuvre dans les systèmes de protection, d’automatisation et de contrôle » — est l’entité qui mène ce travail. Il est animé par David Macdonald (GB), avec David Madrid et Marcus Stollfuss comme co-auteurs de l’article de cadre publié dans CIGRE Future Connections le 20 janvier 2026, puis repris dans ELECTRA 345 en avril 2026.

CIGRE n’est pas un organisme de normalisation — c’est l’association internationale des grands systèmes électriques, et ses groupes de travail produisent des brochures techniques, et non des normes normatives. Ce que CIGRE possède, c’est un lien de catégorie A entre le comité d’étude B5 (Protection et Automatisation) et le TC 57 de l’IEC, le comité technique qui détient la norme IEC 61850. En pratique, cela signifie que les travaux du SC B5 de CIGRE — et plus particulièrement ceux des groupes de travail pertinents pour les DEI virtualisés comme B5.60 (TB 891) et B5.84 — constituent une voie directe d’entrée pour les éditeurs de l’IEC. Une définition de DEI virtualisé issue de B5.84 n’est donc pas une règle contraignante, mais c’est le document que les rédacteurs de l’IEC consulteront lorsqu’il sera nécessaire d’aborder explicitement la virtualisation dans la prochaine partie de la norme IEC 61850.

L’article de cadre et les conditions d’engagement (TOR) définissent ensemble la portée attendue de la brochure technique finale, prévue pour le premier trimestre 2028, ainsi que les implications pour les projets vPAC actuellement mis en œuvre.

Pourquoi CIGRE s’est intéressé à ce sujet

Le groupe de travail B5.84 n’est pas apparu de nulle part. Il est le successeur direct du groupe de travail B5.60, lancé en 2017 et ayant produit la brochure technique 891, intitulée « Architectures de protection, d’automatisation et de contrôle avec fonctionnalités indépendantes du matériel (FIH) », en avril 2023. La TB 891 a posé les bases conceptuelles : les fonctions PAC peuvent être déconnectées de la boîte dans laquelle elles résident actuellement, et il existe deux voies architecturales pour y parvenir — une solution DEI basée sur une couche intermédiaire avec des interfaces standardisées vers des conteneurs d’application, et un système centralisé de protection et de contrôle basé sur serveur qui regroupe les applications sur des unités informatiques redondantes.

TB 891 a également fourni à l’industrie l’argument sur le cycle de vie qui a été cité dans chaque présentation vPAC depuis : les cycles de vie du matériel PAC sont approximativement de 10 à 15 ans, tandis que ceux de l’installation primaire sont de 40 à 60 ans. On remplace la relais plusieurs fois au cours de la durée de vie du disjoncteur. Chaque remplacement implique une reconstruction du panneau, une nouvelle SCD, une nouvelle campagne de mise en service. La fonctionnalité indépendante du matériel promet de rompre ce cycle.

Ce que TB 891 n’a pas fait délibérément, c’est de spécifier le vIED lui-même. Il a décrit l’option architecturale ; il n’a pas précisé à quoi le vIED doit ressembler à ses interfaces, comment il est configuré, comment il est supervisé, ou comment il est mis à jour. C’est là que B5.84 comble le vide.

Le cadre présenté dans l’article CIGRE est direct : un pourcentage important de la base installée d’IED est en fin de vie ou s’en approche. Les fournisseurs d’électricité sont sur le point de prendre les décisions de remplacement suivantes. S’ils le font sans une vision établie par un organisme de normalisation sur ce qu’est un vIED, l’industrie va obtenir exactement ce qu’elle a obtenu lors de la première vague de déploiements IEC 61850 — six dialectes spécifiques aux fournisseurs de la même idée.

Ce que le Groupe de travail couvre réellement

Le mandat d’activité (TOR), signé par la présidence du SC B5 et daté du 8 janvier 2024, énumère les sujets que le Groupe de travail traitera.

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#fafaf7",
    "fontFamily": "Roboto Flex, Inter, system-ui, sans-serif",
    "primaryColor": "#1e1f1d",
    "primaryTextColor": "#fafaf7",
    "primaryBorderColor": "#58c1da",
    "lineColor": "#cbcbc4",
    "mainBkg": "#1e1f1d",
    "nodeTextColor": "#fafaf7",
    "darkTextColor": "#fafaf7",

    "cScale0":  "#1e1f1d", "cScaleLabel0":  "#fafaf7", "cScaleInv0":  "#58c1da",
    "cScale1":  "#d6f0f6", "cScaleLabel1":  "#0d5566", "cScaleInv1":  "#58c1da",
    "cScale2":  "#fdf0c5", "cScaleLabel2":  "#5c3f00", "cScaleInv2":  "#f5b301",
    "cScale3":  "#d1efe1", "cScaleLabel3":  "#0e4f31", "cScaleInv3":  "#2f9e6a",
    "cScale4":  "#fbd6d8", "cScaleLabel4":  "#6e1014", "cScaleInv4":  "#e5484d",
    "cScale5":  "#c3e7ef", "cScaleLabel5":  "#0d4452", "cScaleInv5":  "#2fa9c6",
    "cScale6":  "#dde0e3", "cScaleLabel6":  "#2e3338", "cScaleInv6":  "#6e7681",
    "cScale7":  "#1e1f1d", "cScaleLabel7":  "#fafaf7", "cScaleInv7":  "#58c1da",
    "cScale8":  "#1e1f1d", "cScaleLabel8":  "#fafaf7", "cScaleInv8":  "#58c1da",
    "cScale9":  "#1e1f1d", "cScaleLabel9":  "#fafaf7", "cScaleInv9":  "#58c1da",
    "cScale10": "#1e1f1d", "cScaleLabel10": "#fafaf7", "cScaleInv10": "#58c1da",
    "cScale11": "#1e1f1d", "cScaleLabel11": "#fafaf7", "cScaleInv11": "#58c1da"
  }
}}%%
mindmap
  root((WG B5.84<br/>champ d'application))
    Définition
      IED virtuel · ce qu'il est et ce qu'il n'est pas
      Risques, avantages, solutions
    Interface
      IEC 61850 obligatoire
      Règles et fichiers de configuration
      Synchronisation temporelle
    Cycle de vie
      Administration et mise à jour
      Surveillance de l'IED virtuel
    Ressources
      Capacité de communication
      Capacité mémoire
      Capacité CPU
    Côté hôte
      Exigences du serveur pour l'hébergement de l'IED virtuel
      Exigences de l'interface serveur-vers-IED virtuel
      Exigences du serveur industriel
      Comparaison des hyperviseurs
      Redondance
      Surveillance du matériel/middleware/logiciel
    Avenir
      Avenir du concept d'IED virtuel
      Liaison avec le jumeau numérique

Quelques points méritent d'être mis en évidence dans cette carte.

L’interface IEC 61850 est obligatoire. À la fois le TOR et l’article CIGRE le précisent deux fois : un IED virtuel doit exposer une interface IEC 61850 et doit être configurable selon les règles et fichiers de configuration IEC 61850. Il n’existe pas de voie équivalente propriétaire du fournisseur. Si un produit se prétend être un IED virtuel et ne consomme pas un SCD, il s’agit d’un autre type de produit.

Les deux approches VM et conteneur sont prises en compte. L’article CIGRE décrit explicitement les deux méthodes principales de virtualisation : les systèmes basés sur hyperviseur, où chaque machine virtuelle contient son propre système d’exploitation, et les systèmes basés sur conteneurs, où les conteneurs s’exécutent sur le système d’exploitation hôte via un moteur de conteneurs. Le WG traite les deux approches. Il ne choisit pas de vainqueur, et d’après la rédaction du TOR, il est peu probable qu’il le fasse. Une présentation comparative est à prévoir.

La supervision et la mise à jour bénéficient chacune d’un chapitre. Deux des sujets listés sont « l’administration et la mise à jour des IED virtuels » et « la supervision des IED virtuels ». Pour toute personne ayant une expérience terrain des mises à jour massives de firmware sur une flotte d’IED de niveau baie, c’est la section à lire en premier lorsque la brochure est publiée. Un IED virtuel (vIED) facile à déployer lors de la validation en usine mais impossible à entretenir sur le terrain représente un recul, pas une avancée.

La plateforme hôte est incluse dans le champ d’application — mais pas l’architecture PACS elle-même. Le groupe de travail couvre le côté serveur : exigences en matière de serveurs industriels, comparaison des hyperviseurs, redondance, surveillance du matériel, du middleware et du logiciel. Ce qu’il ne couvre pas, c’est la façon dont l’ensemble du PACS est architecturé, ni la structure du serveur pour les PACS centralisés — ce point est réservé au groupe de travail B5.70.

C’est une distinction utile à comprendre. Le B5.84 vous indique ce qu’un vIED doit être à ses interfaces et comment son hôte doit se comporter pour le soutenir. Il ne vous dit pas si vous devez construire un PAC centralisé, un vPAC distribué ou hybride. L’architecture relève d’un autre groupe de travail.

Ce que le groupe de travail ne couvre pas explicitement

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#fafaf7",
    "fontFamily": "Roboto Flex, Inter, system-ui, sans-serif",
    "primaryColor": "#ffffff",
    "primaryTextColor": "#1e1f1d",
    "primaryBorderColor": "#e2e2dc",
    "lineColor": "#cbcbc4"
  }
}}%%
flowchart LR
    subgraph IN["B5.84 IN scope"]
        direction TB
        I1["Définition du vIED"]
        I2["Interface IEC 61850"]
        I3["Configuration · synchronisation temporelle"]
        I4["Mise à jour · supervision"]
        I5["Dimensionnement du CPU · mémoire · réseau"]
        I6["Exigences de la plateforme hôte"]
        I7["Comparaison des hyperviseurs"]
        I1 ~~~ I2 ~~~ I3 ~~~ I4 ~~~ I5 ~~~ I6 ~~~ I7
    end
    subgraph OUT["OUT of scope"]
        direction TB
        O1["Choix de l’architecture PACS"]
        O2["Structure du serveur PACS centralisé<br/>(réservé au groupe de travail B5.70)"]
        O3["Certification des produits fournisseurs"]
        O4["Choix entre VM et conteneur comme politique"]
        O1 ~~~ O2 ~~~ O3 ~~~ O4
    end
    IN -.->|"complète"| OUT

    classDef inItem  fill:#d6f0f6,stroke:#58c1da,color:#0d5566;
    classDef outItem fill:#dde0e3,stroke:#6e7681,color:#2e3338;
    class I1,I2,I3,I4,I5,I6,I7 inItem
    class O1,O2,O3,O4 outItem
    style IN  fill:#eff8fb,stroke:#58c1da,stroke-width:1.5px,color:#0d5566;
    style OUT fill:#f3f3ee,stroke:#6e7681,stroke-width:1.5px,color:#2e3338;

Les ingénieurs qui n’ont lu que les documents marketing concernant le vPAC ont tendance à supposer que le cadre CIGRE finira par leur indiquer quelle architecture choisir — serveur central, serveurs distribués, hybride avec boîtiers en périphérie. Ce ne sera pas le cas. Le groupe de travail B5.84 considère l’architecture comme donnée et répond à une question plus restreinte, mais plus utile : quelle que soit la position du vIED, que doit-il devoir au reste du système ?

Le TOR mentionne également le « futur du concept de vIED » et note un lien entre le IED virtuel et le concept de jumeau numérique comme sujet que le groupe de travail va examiner. Toutefois, la nature exacte de ce lien dans la brochure n’est pas encore disponible au public.

Les deux méthodes de virtualisation, côte à côte

L’article CIGRE décrit les deux méthodes comme suit. En les associant à ce qui est actuellement livré sur le marché :

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#fafaf7",
    "fontFamily": "Roboto Flex, Inter, system-ui, sans-serif",
    "primaryColor": "#ffffff",
    "primaryTextColor": "#1e1f1d",
    "primaryBorderColor": "#e2e2dc",
    "lineColor": "#cbcbc4"
  }
}}%%
flowchart TB
    subgraph H["Hyperviseur + VMs"]
        direction TB
        HW1["Matériel informatique industriel<br/>(IEC 61850-3 / IEEE 1613)"]:::hw
        HV["Hyperviseur (KVM / VMware ESXi)"]:::platform
        OS1["Système d'exploitation invité · vIED-A"]:::runtime
        OS2["Système d'exploitation invité · vIED-B"]:::runtime
        OS3["Système d'exploitation invité · vIED-C"]:::runtime
        APP1["Application de protection A"]:::app
        APP2["Application de protection B"]:::app
        APP3["Application de protection C"]:::app
        HW1 --> HV
        HV --> OS1 --> APP1
        HV --> OS2 --> APP2
        HV --> OS3 --> APP3
    end
    H ~~~ C
    subgraph C["Moteur de conteneurs + conteneurs"]
        direction TB
        HW2["Matériel informatique industriel<br/>(IEC 61850-3 / IEEE 1613)"]:::hw
        OSH["Système d'exploitation hôte (Linux, noyau temps réel)"]:::platform
        CE["Moteur de conteneurs"]:::platform
        CT1["Conteneur · vIED-A"]:::runtime
        CT2["Conteneur · vIED-B"]:::runtime
        CT3["Conteneur · vIED-C"]:::runtime
        AP1["Application de protection A"]:::app
        AP2["Application de protection B"]:::app
        AP3["Application de protection C"]:::app
        HW2 --> OSH --> CE
        CE --> CT1 --> AP1
        CE --> CT2 --> AP2
        CE --> CT3 --> AP3
    end

    classDef hw       fill:#1e1f1d,stroke:#1e1f1d,color:#fafaf7;
    classDef platform fill:#d6f0f6,stroke:#58c1da,color:#0d5566;
    classDef runtime  fill:#fdf0c5,stroke:#f5b301,color:#5c3f00;
    classDef app      fill:#d1efe1,stroke:#2f9e6a,color:#0e4f31;
    style H fill:#fafaf7,stroke:#e2e2dc,stroke-width:1.5px,color:#1e1f1d;
    style C fill:#fafaf7,stroke:#e2e2dc,stroke-width:1.5px,color:#1e1f1d;

L’article CIGRE expose directement la distinction : « la différence entre les deux réside dans le fait que la machine virtuelle contient son propre système d’exploitation (OS), tandis que les conteneurs fonctionnent tous sur le système d’exploitation hôte. » Cette distinction modifie la réponse à presque toutes les questions que la brochure entend traiter.

  • Synchronisation temporelle : dans le modèle de machine virtuelle (VM), chaque système d’exploitation invité termine le PTP séparément. Dans le modèle de conteneur, le système d’exploitation hôte détient l’horloge et les conteneurs l’héritent. La discipline que vous écrivez pour l’un ne s’applique pas à l’autre.
  • Gestion des mises à jour : mettre à jour une machine virtuelle signifie orchestrer un système d’exploitation plus une application ; mettre à jour un conteneur signifie échanger une image. Le profil de risque est différent.
  • Surveillance : ce qui constitue un signal « le vIED est en fonction » diffère. Un conteneur peut être en fonction alors que son application est arrêtée ; une machine virtuelle peut être en fonction alors que sa carte réseau a perdu son pilote. Le Groupe de travail (WG) devra définir le signal de surveillance au niveau IEC 61850 afin qu’il ne dépende pas de la méthode utilisée par l’hôte.

Aujourd’hui, chaque fournisseur proposant des produits vPAC a sa propre réponse à ces questions. La brochure ne prescrira pas une implémentation, mais devrait définir l’interface et le comportement au niveau IEC 61850 que tout vIED doit exposer, indépendamment de la méthode de virtualisation sous-jacente.

Temps réel, déterminisme et les éléments que le Groupe de travail ne peut pas ignorer

L’article de CIGRE identifie « l’un des défis de la virtualisation » comme étant « garantir une faible latence et des performances déterministes ». Pour la protection, cela est décisif : l’IEC 61850-5 impose un temps de transfert de 3 ms pour un message d’action de type 1A. Une plateforme virtualisée doit respecter cette contrainte dans les conditions les plus défavorables : charge maximale, processus de fond le plus gourmand, voisin bruyant sur la même socket — ou elle ne la respecte pas.

Des travaux académiques récents ont explicitement décrit les techniques nécessaires. Noyaux Linux temps réel, fixation des processeurs (CPU pinning) pour attribuer des cœurs dédiés au vIED, placement conscient du NUMA, passage direct du matériel (hardware passthrough) pour les cartes réseau traitant les flux SV et GOOSE, configuration du planificateur d’hyperviseur pour une latence déterministe. Les benchmarks publiés par la TU Delft sur des contrôleurs virtualisés dans une sous-station IEC 61850 définie logiciellement ont montré des temps moyens de transmission GOOSE inférieurs à la contrainte de 3 ms imposée par l’IEC 61850 — mais uniquement avec la configuration temps réel en place, et uniquement à des charges de trafic contrôlées. Les travaux d’évaluation de MDPI font la même mise en garde : la latence de communication augmente à mesure que l’on ajoute des vIED et que le trafic de fond croît, et la relation n’est pas linéaire.

C’est l’élément le plus difficile que le Groupe de travail doit consigner sans devenir un guide de sélection de fournisseurs. On s’attend à ce que la brochure spécifie la surveillance et la notification permettant à un fournisseur d’électricité mesurer si son hôte respecte les objectifs de déterminisme, plutôt que d’imposer une version spécifique de noyau Linux ou d’hyperviseur. La formulation du TOR — « évaluation de la capacité en communication, mémoire et CPU » — soutient cette interprétation.

Les livrables et le calendrier

Le TOR énumère quatre trimestres de jalons sources ; tout le reste (début du projet de travail, rythme d’examen interne) n’est pas fixé à une date et ne doit pas être interprété comme tel.

Section Milestone 2027 Q4 2028 Q1 2028 Q2
Brochure Brouillon de la fiche technique (TB) pour examen par le SC ◆
Brochure Fiche technique finale (critique) ◆
Communications Tutoriel ◆
Communications Webinaire ◆

Q4 2027 pour la version préliminaire de la fiche technique (TB) présentée au comité d’étude. Q1 2028 pour la TB finale. Q2 2028 pour le tutoriel et le webinaire. L’article publié par ELECTRA fait partie de ce calendrier — il s’agit de la première note publique du groupe de travail (WG), conçue pour présenter le cadre alors que la brochure est encore en cours d’élaboration.

Selon les normes du groupe de travail CIGRE, ce calendrier est serré. Il est également le bon. Le marché des vPAC évolue suffisamment rapidement pour qu’une brochure publiée vers la fin de la décennie décrive un musée.

Trois décisions techniques à prendre avant la publication de la brochure

Si vous menez un projet pilote vPAC en 2026, trois conséquences découlent du cadre tel qu’il est actuellement défini.

Premièrement, assurez-vous que vos candidats vIED exposent une interface IEC 61850 configurable à partir de fichiers SCL (conformément à la exigence du TOR selon laquelle les vIED doivent être « configurables selon les règles et fichiers de configuration IEC 61850 »), et non via une interface graphique propriétaire. Tout ce qui est mis en service aujourd’hui à l’aide d’un outil de configuration propriétaire se situera en dehors de cette exigence et sera susceptible de nécessiter une refonte une fois la brochure publiée.

Deuxièmement, décidez maintenant si vous empruntez la voie des machines virtuelles (VM) ou celle des conteneurs, et adaptez votre supervision et votre processus de mise à jour à ce choix. Le groupe de travail ne choisira pas un vainqueur. Il définira cependant ce que le vIED doit au reste du système en matière de supervision et de mise à jour ; si votre projet pilote expose déjà ces signaux via MMS, vous n’aurez pas besoin de rééquiper les systèmes lorsque la brochure sera publiée.

Troisièmement, prêtez attention à ce que le groupe de travail ne couvre pas. L’architecture de votre PACS — centrale, distribuée, hybride — n’est pas du ressort de B5.84. C’est une décision technique à prendre par vous. La structure de serveur PACS centralisée est mentionnée dans le TOR de B5.84 comme faisant partie des travaux du groupe de travail B5.70 (un groupe de travail distinct). Ne pas attendre que B5.84 vous indique si vous devez construire un CPC. Il ne le fera pas.

En ce qui concerne spécifiquement la supervision — le chapitre le plus susceptible d’être rétrofité dans des outils existants plutôt que développé de toutes pièces — les entreprises qui utilisent aujourd’hui des outils de surveillance du trafic IEC 61850 en temps réel ont un avantage. Un vIED, tout comme un IED matériel, publie des données sur un bus. Des outils tels que Tekvel Park, qui supervisent déjà le trafic GOOSE, SV et MMS dans des réseaux PACS réels, considèrent un vIED comme un simple émetteur ; ils ne se soucient pas de savoir si la source est un relais ou une machine virtuelle, tant que l’interface et le comportement IEC 61850 sont intacts. C’est là le point que le groupe de travail impose : l’identité du vIED pour le reste de la sous-station est son interface IEC 61850, et non son matériel.

Hyperviseur contre conteneur et la frontière de cybersécurité

Deux grandes questions restent en suspens, et la brochure devra y répondre.

La première concerne la recommandation entre hyperviseur et conteneur. L’article CIGRE présente les deux approches de manière équilibrée. Le TOR inclut « comparaison des hyperviseurs ». La pratique industrielle actuelle est partagée : VMware ESXi et Linux KVM dominent le camp des machines virtuelles (VM) ; Kubernetes, k3s et des moteurs de conteneurs sur mesure apparaissent dans le camp des conteneurs. SEAPATH, la référence de LF Energy, est basée sur KVM. La plupart des produits vPAC commercialisés par les fournisseurs aujourd’hui sont basés sur des machines virtuelles. Si le Groupe de travail (WG) reste neutre, la brochure sera une référence utile ; s’il favorise une méthode, cela redéfinira les plans techniques des fournisseurs.

La seconde concerne la frontière avec la cybersécurité. La virtualisation réduit les surfaces d’attaque à certains endroits (un hôte sécurisé à la place de vingt appareils exposés) et les augmente ailleurs (une compromission de l’hyperviseur devient maintenant une compromission de la sous-station). Le TOR ne place pas la cybersécurité dans un titre de chapitre, mais le sujet est inévitable. La question intéressante est de savoir si B5.84 fera référence au travail du Groupe de travail B5.66 / SC D2 sur la cybersécurité des systèmes opérationnels (OT), ou s’il rédigera sa propre courte déclaration sur ce que l’interface vIED doit à une architecture de sécurité. L’article CIGRE ne donne pas de réponse à cette question.

Pour les ingénieurs qui considèrent encore certaines parties de la pile IEC 61850 comme optionnelles — les Valeurs échantillonnées en particulier, où le coût des unités de fusion et du bus de processus a été utilisé comme argument pour différer l’adoption — le cadre du Groupe de travail B5.84 apporte, en passant, une réponse. Un vIED n’a pas d’entrées I/O natives. Il n’a pas d’entrées cuivre. La seule façon dont il voit la sous-station est via le bus de processus et le bus de station IEC 61850. La virtualisation rend la pile complète obligatoire d’une manière que les IED matériels n’ont jamais tout à fait fait, car un IED matériel pouvait toujours revenir à une entrée CT câblée. Dans le monde des vIED, il n’y a pas de retour en arrière — le bus de processus EST l’entrée. Les économies issues de la suppression de vingt IED ne sont réelles que si l’infrastructure d’unités de fusion située en dessous est déjà en place.

Faites attention à ne pas attendre deux ans pour les réponses. Les sous-stations mises en service aujourd’hui vivront pendant 40 ans. Le cadre est rédigé pour elles.

Sources