Note éditorial
Cet article ouvre une nouvelle série sur l’ingénierie top-down selon la norme IEC 61850 — l’un des changements les plus significatifs dans la méthodologie d’ingénierie des sous-stations numériques ces dernières années. Deux nouveaux rapports techniques IEC (TR 61850-90-30 et TR 61850-7-6 édition 2) sont désormais publiés ; une coalition de 14 fournisseurs d’électricité européens a officiellement soutenu cette approche ; et les premières déploiements en production sont sur le point de commencer. Dans cette série, nous retraçons ce changement depuis ses origines jusqu’à ses implications concrètes — pour les réseaux de transport, les fournisseurs d’IED et les développeurs d’outils. Ce premier article établit le contexte.

En 2023, quatorze opérateurs de réseaux de transport et fournisseurs d’électricité européens ont signé une déclaration commune sur l’ingénierie selon la norme IEC 61850. Ce n’était pas un instrument réglementaire. Il ne comportait aucun mécanisme d’application. Mais il s’agissait de quelque chose de rare dans la normalisation industrielle : un groupe de grands fournisseurs d’électricité, chacun attaché à ses propres processus, parvenant à un accord partagé sur la manière dont l’ingénierie devrait fonctionner — et s’engageant publiquement à le faire.

L’initiative a été menée par le groupe Elia — l’OPR belge Elia et sa filiale allemande 50Hertz — et a attiré treize autres fournisseurs d’électricité. Ensemble, ils ont publié ce qui est désormais connu sous le nom de Vision commune sur l’ingénierie IEC 61850 : un document qui décrit un processus d’ingénierie top-down en cinq étapes, explique ce que cela exige des fournisseurs d’outils et d’IED, et démontre — à travers un prototype fonctionnel — que cela est techniquement réalisable aujourd’hui.

Cet article examine ce que dit la Vision commune, comment elle est née, et ce que cela signifie pour les personnes et organisations qui conçoivent des sous-stations numériques.

Le problème : pourquoi l’approche actuelle présente des limites structurelles

Le flux de travail d’ingénierie IEC 61850 standard actuel repose sur les équipements. Un fournisseur d’électricité établit des exigences — généralement sous forme de documents Word ou PDF — et les envoie aux fournisseurs d’IED. Chaque fournisseur interprète ces exigences, configure un équipement selon sa propre chaîne d’outils, puis renvoie un fichier de description de capacité (ICD). L’ingénieur système assemble la configuration finale du système en croisant les fichiers ICD, en résolvant manuellement les différences de noms, et en reliant manuellement les ensembles de données, les abonnements GOOSE et les éléments ExtRef.

Cette approche a permis de concevoir des systèmes IEC 61850 fonctionnels pendant vingt ans. Mais elle est devenue structurellement limitante à mesure que les sous-stations numériques passent des déploiements pilotes à une infrastructure standard, et que les grands fournisseurs d’électricité gèrent simultanément des dizaines de projets IEC 61850.

Les problèmes sont bien compris par les praticiens :

  • Écarts d’interprétation. Les spécifications au format PDF laissent place à des malentendus. Deux fournisseurs lisant le même document peuvent produire des configurations sensiblement différentes. L’utilisateur ne s’en rend compte qu’au moment de la mise en service.
  • Absence d’échange lisible par machine. Il n’existe pas de format formel, traitable par outil, pour communiquer ce qu’un IED (intelligent electronic device) doit faire. Chaque projet recrée la spécification à partir de zéro.
  • Vérification tardive. La vérification commence généralement après la sélection et l’achat des équipements — le moment le plus coûteux pour découvrir une erreur de conception.
  • Pas de réutilisation. Les spécifications de fonction développées pour un projet ne peuvent pas être transférées directement au suivant. Chaque déploiement recommence le cycle d’ingénierie.

Thomas Sterckx, expert en sous-stations virtuelles chez Elia Engineering et co-rédacteur des rapports techniques IEC pertinents, a décrit la direction du changement lors d’un webinaire technique en décembre 2023 : « Au lieu de donner [au fournisseur d’IED] une longue série de documents écrits… vous pouvez lui donner quelque chose de lisible par machine, qu’il peut traiter dans son propre outil. »

L’Histoire : De la déclaration CIGRE 2012 à la Déclaration commune 2023

La demande d’amélioration des processus d’ingénierie IEC 61850 n’est pas nouvelle. En 2012, l’organisation CIGRE a publié une déclaration — sous les comités d’étude A3 et B5 — appelant à des améliorations dans la manière dont les systèmes IEC 61850 étaient spécifiés et conçus. Les exigences formulées à cette époque sont restées largement non satisfaites pendant une décennie.

En 2018, Elia a participé à OSMOSE, un projet de recherche financé par l’Europe. OSMOSE a mis au point le cadre conceptuel initial pour ce qui est aujourd’hui l’approche d’ingénierie ascendante : commencer par des spécifications de fonction indépendantes de tout dispositif particulier, et formaliser l’échange entre les réseaux et les fournisseurs dans des formats structurés et lisibles par machine.

À partir de 2020, le groupe de travail 10 du TC57 de l’IEC a commencé à développer deux rapports techniques qui donneraient une base normative à ces concepts : TR IEC 61850-90-30, traitant de la modélisation des fonctions dans SCL, et TR IEC 61850-7-6 ed2, couvrant les profils d’application de base. Tous deux ont depuis été publiés — TR 7-6 ed2 en 2024, TR 90-30 en 2025.

La Déclaration commune, signée en 2023 par le groupe Elia et treize autres réseaux européens, a été le moment où cette trajectoire est devenue un signal du marché. Comme l’a observé Sterckx : « Je pense pouvoir dire que nous sommes enfin capables de répondre aux déclarations ou aux exigences qu’ils avaient demandées en 2012. »

Parallèlement à la Déclaration commune, Elia a mené un projet de démonstration avec trois partenaires industriels — Condis/Helinks (outils de spécification système), Siemens (outils de configuration d’IED), et Triangle MicroWorks (simulation et test) — montrant le processus complet en cinq étapes à l’aide d’outils prototypes.

La Vision commune décrit un processus d’ingénierie fondé sur cinq étapes séquentielles. La logique est véritablement descendante : le processus commence par des exigences fonctionnelles exprimées entièrement indépendamment de tout dispositif spécifique, et ne parvient à la configuration matérielle qu’à la fin.

flowchart LR
    P1["① Profilage du système\n(FSD / ASD templates)"]
    P2["② Spécification du système\n(ISD files)"]
    P3["③ Simulation et validation\n(ASD / SSD testing)"]
    P4["④ Capacité de l'IED\n(process ICD)"]
    P5["⑤ Configuration du système\n(SCD)"]

    P1 --> P2 --> P3 --> P4 --> P5

Étape 1 — Profilage du système. Les ingénieurs créent des modèles de fonctions et d’applications réutilisables. Une Description de spécification de fonction (FSD) définit une seule fonction — protection à distance, commande de disjoncteur, surveillance de transformateur. Une Description de spécification d’application (ASD) combine plusieurs FSD, définit le flux de données entre elles et peut inclure une logique de comportement formelle écrite en IEC 61131-3. Il est essentiel de noter que ces modèles ne font référence à aucun dispositif physique. Ils définissent ce que le système doit faire, pas comment un dispositif particulier le fait.

Étape 2 — Spécification du système. Les modèles d’application sont instanciés dans un projet. L’ingénieur assemble une spécification du système et génère des spécifications par IED : des fichiers Description de spécification d’IED (ISD) — des documents structurés SCL qui définissent formellement le modèle de données, les interfaces de signal et les valeurs de configuration. Un fichier ISD est indépendant du fournisseur. Le même fichier peut être envoyé en parallèle à plusieurs fournisseurs, sollicitant des réponses concurrentes sur les capacités.

Étape 3 — Simulation et validation du système. Une fois les fichiers ISD complets, la conception peut être testée avant toute sélection ou achat de dispositif. Les outils importent les fichiers ASD et SSD, simulent la logique d’application — y compris les descriptions de comportement en IEC 61131-3 — et permettent d’exécuter des séquences de test par rapport aux entrées et sorties attendues. Pour cette étape, le projet de démonstration a utilisé le DTM (Distributed Test Manager) de Triangle MicroWorks. Comme l’a souligné Jackson Moore, ingénieur d’application chez Triangle MicroWorks : "De nombreuses erreurs potentielles peuvent maintenant être identifiées beaucoup plus tôt dans le processus d’ingénierie — et sont comparativement beaucoup moins chères et plus faciles à corriger."

Étape 4 — Description de la capacité de l'IED. Les fournisseurs reçoivent le fichier ISD, l’importent dans leur outil de configuration d’IED (ICT), et cartographient les capacités réelles de leur dispositif selon la spécification. Lorsque les capacités du dispositif correspondent à la spécification, la cartographie est directe. Lorsqu’il existe des différences — noms de dispositif logique différents, objets de données absents, implémentations alternatives — le fournisseur documente formellement l’écart. Le résultat est un process ICD : un fichier ICD standard étendu avec des informations explicites de cartographie entre la spécification et le dispositif. Ce fichier indique à l’outil de configuration du système exactement comment chaque élément de la spécification de l’utilité est mis en œuvre dans le dispositif réel.

Étape 5 — Configuration du système. L’outil de configuration du système (System Configuration Tool, SCT) importe les fichiers ICD de processus provenant de chaque fournisseur. En utilisant les informations de mappage intégrées dans chaque fichier, il lie automatiquement les nœuds logiques aux dispositifs réels, génère les blocs de contrôle GOOSE et les ensembles de données, et remplit les abonnements ExtRef. Le résultat est un fichier SCD complet — avec une intervention manuelle sensiblement réduite par rapport à l’approche actuelle.

Le prototype : un flux de travail complet, en direct

Le prototype mené par Elia a parcouru les cinq étapes à l’aide d’un scénario d’ingénierie réel, bien que simplifié : une application de disjoncteur et une application de protection à distance implémentées sur quatre IED. Le flux de travail a été démontré publiquement lors d’un webinaire organisé en décembre 2023 par Triangle MicroWorks.

Dans la démonstration :

  • Helix STS (Condis/Helinks) a géré le profilage du système et la spécification du système, générant des fichiers ASD et ISD à partir de modèles de fonctions assemblés dans son environnement d’outil.
  • Le DTM de Triangle MicroWorks a importé l’ASD et a démontré la simulation de l’application de protection à distance P21, incluant la manipulation interactive des entrées et un séquenceur de tests piloté depuis Excel.
  • DIGSI 5 de Siemens a importé les fichiers ISD pour une unité de fusion 6MU et un relais de protection à distance 7SA87, effectué le mappage LNode vers LN, et exporté les fichiers ICD de processus — avec la possibilité de conserver la dénomination native du dispositif ou d’adopter le modèle de données unifié issu de la spécification.
  • Helix STS a ensuite importé les deux fichiers ICD de processus, implémenté automatiquement les spécifications LNode à l’aide des données de mappage, généré les blocs de contrôle GOOSE et les ensembles de données, et exporté un SCD complet.
  • Le Digital Twin de Siemens a importé le SCD, appliqué la configuration GOOSE, et exécuté simultanément les deux dispositifs virtuels afin de vérifier le flux de signaux et le modèle de données.

L’intégralité du flux de travail a utilisé l’espace de noms SCL 6-100 — l’extension définie dans la TR 61850-90-30 et la TR 61850-7-6 qui introduit les nouveaux éléments SCL requis par le processus : AllocationRole, SourceRef, LNodeSpecNaming, BehaviorDescription, et autres.

Ce que cela signifie pour le marché

La Déclaration commune et le prototype associé ont un public ciblé précis : les fournisseurs d’IED et les fournisseurs d’outils qui doivent comprendre ce que les grandes entreprises européennes attendent de leurs produits.

Pour les fournisseurs d’IED, la modification formelle de l’interface ISD change la dynamique d’achat. Une entreprise utilisant un fichier ISD lisible par machine peut l’envoyer simultanément à plusieurs fournisseurs et comparer leurs réponses ICD de processus — y compris les écarts documentés — dans un format structuré. La barrière à la bascule vers un autre fournisseur diminue. Comme l’a souligné Sterckx : "Un ISD est indépendant du fournisseur et vous pouvez facilement le transmettre à plusieurs fournisseurs d’IED et recevoir plusieurs offres en retour."

Pour les fournisseurs d'outils de configuration des IED, la Vision commune définit des exigences concrètes en matière de fonctionnalités : import de fichiers ISD, mappage LNode vers LN, export de fichiers ICD de processus, et documentation des écarts. Ce sont ces fonctionnalités qui détermineront si un outil est utilisable dans le nouveau flux de travail.

Pour les fournisseurs d'outils de configuration système, l'exigence clé est la prise en charge des fichiers ICD de processus : la capacité à lire les informations de mappage contenues dans un fichier ICD de processus et à les utiliser pour automatiser la génération du fichier SCD.

Le groupe Elia a indiqué une feuille de route menant à des projets de production en 2029–2030, avec une acquisition d'outils prévue vers 2027. Ce calendrier donne à l'écosystème des outils plusieurs années — mais les décisions concernant la priorité du développement sont déjà prises. La TR 90-30 et la TR 7-6 ed2 sont publiées. Le processus a été démontré. Elia se prépare à lancer un appel d'offres pour un écosystème d'ingénierie.

Conclusion

La Vision commune est une réponse bien structurée à un problème réel et reconnu. L’approche actuelle d’ingénierie selon IEC 61850 — spécification par PDF, intégration manuelle, validation tardive — n’est pas là où un standard mature devrait se trouver. Quatorze fournisseurs d’électricité soutenant formellement la même définition de processus crée un signal de demande que le marché des outils ne peut ignorer.

L’infrastructure des normes est en place. La démonstration de concept montre que le processus est techniquement réalisable avec les outils existants. La question maintenant est de savoir à quelle vitesse l’écosystème plus large — fournisseurs d’IED, fournisseurs d’outils et fournisseurs d’électricité au-delà de la coalition actuelle — s’alignera sur l’approche décrite par la Vision commune.

Les articles suivants de cette série examinent les détails techniques : le processus en cinq étapes en profondeur, le format de fichier ISD et ce que cela change concernant l’acquisition des IED, l’espace de noms SCL 6-100 et ce que les développeurs d’outils doivent implémenter, ainsi que le fichier ICD de processus en tant que point pivot entre spécification et configuration.

Sources primaires : webinaire technique — « Établissement d’un processus de spécification indépendant des fournisseurs pour l’ingénierie descendante des systèmes IEC 61850 » (Triangle MicroWorks / Elia Group, décembre 2023) ; TR IEC 61850-90-30:2025 ; TR IEC 61850-7-6 ed2:2024 ; Elia Group — Common Vision on IEC 61850 Engineering.

Photo : Sous-station Mercator 380 kV, Kruibeke, Belgique (Elia). Supercharge / Wikimedia Commons, CC BY-SA 3.0.