Dans l’ingénierie conventionnelle IEC 61850, les erreurs apparaissent au moment le plus critique : lors de la mise en service, lorsque le matériel est sur site, les équipes sont déployées et les délais de projet sont sous pression. Le processus d’ingénierie par le haut — formalisé dans la TR IEC 61850-90-30:2025 et la TR IEC 61850-7-6 (Éd. 2) — reporte ce moment de manière significative : avant même la sélection d’un seul IED, avant la signature d’un contrat, avant que tout dispositif physique n’existe. Quatorze réseaux de transport d’électricité européens, dont Elia et 50Hertz, ont signé une Déclaration commune en 2023 pour soutenir cette approche comme orientation pour l’ingénierie des sous-stations numériques. La première article de cette série a abordé les raisons pour lesquelles l’industrie évolue dans cette direction et ce qui a conduit à l’accord des quatorze entreprises. Cet article explique la mécanique : ce qui se produit à chacune des cinq étapes, quels fichiers sont échangés, et pourquoi ce processus produit de meilleurs résultats que ce qui existait auparavant.

Pourquoi l’approche par le bas est insuffisante

Le processus conventionnel IEC 61850 commence par l’IED. Vous obtenez un fichier ICD auprès du fournisseur, vous construisez le système autour de ce que le dispositif peut faire, et vous communiquez les exigences à travers des documents de spécification PDF — que chaque fournisseur lit et interprète de manière indépendante. Lorsque les incohérences apparaissent, l’équipement est déjà commandé, le projet est engagé, et les corrections sont coûteuses. L’approche par le haut inverse entièrement cette séquence : les exigences fonctionnelles sont définies en premier, sous forme lisible par machine, validées sans matériel, et ne sont ensuite transmises aux fournisseurs qu’en tant que spécification structurée qu’ils peuvent traiter dans leurs propres outils.

Le processus en cinq étapes en bref

Le processus se compose de cinq étapes, chacune produisant un fichier structuré qui devient l’entrée de la suivante. Trois catégories d’outils sont impliquées : un outil de spécification système (SST) exploité par l’ingénieur de la société de distribution, un outil de configuration d’IED (ICT) exploité par le fournisseur d’IED, et un outil de configuration système (SCT) exploité à nouveau par l’ingénieur de la société de distribution. Voici comment ils sont connectés :

flowchart LR
    A["Étape 1\nProfilage du système\nFSD / ASD\n(SST)"] -->|"Fichiers ASD\nespace de noms 6-100"| B["Étape 2\nSpécification du système\nISD / SSD\n(SST)"]
    B -->|"SSD\nvers simulation"| C["Étape 3\nSimulation et\nValidation\n(Passage de simulation)"]
    C -->|"échec :\nrevoir SSD"| B
    C -->|"succès :\nSSD validé\n+ ISD vers fournisseur"| D["Étape 4\nCapacité de l’IED\ntraiter ICD\n(ICT)"]
    D -->|"traiter ICD + SSD"| E["Étape 5\nConfiguration du système\nSCD\n(SCT)"]
    E -->|"SCD"| F["Déploiement de l’IED"]
    style C fill:#d4f4dd,stroke:#2d9e5a

Tous les fichiers utilisent le format SCL avec des extensions d’espace de noms 6-100. L’étape 3 peut impliquer une boucle itérative — la simulation est intégrée au développement de la spécification, avec l’ingénieur spécifiant, testant et affinant jusqu’à ce que le comportement soit confirmé. Les fichiers ISD sont transmis aux fournisseurs uniquement après validation de la spécification.

L’étape 1 produit les blocs fonctionnels utilisés dans l’ensemble du projet. L’ingénieur système crée des modèles réutilisables — appelés Descriptions de spécification de fonction (FSD) et Descriptions de spécification d’application (ASD) — sans aucune référence à un fabricant d’IED ou à une gamme de produits spécifique.

Une FSD décrit une fonction de protection ou de commande unique : ses nœuds logiques, ses signaux et les attributs de données requis. Une ASD assemble plusieurs FSDs en une application complète — par exemple, une application de protection à distance (P21) ou une application de commande de disjoncteur. L’ASD contient également :

  • Flux de données — comment les signaux circulent entre les fonctions, annotés par le type de service (GOOSE, SMV ou Interne) et la direction
  • BehaviorDescription — la logique fonctionnelle, rédigée soit sous forme de spécifications textuelles, soit formalisée sous forme de diagrammes de blocs de fonction (FBD) selon la norme IEC 61131-3
  • ProcessResources — des espaces réservés pour les signaux attendus provenant d’autres applications qui ne sont pas encore intégrées dans le projet

Cet dernier élément est important. Lorsqu’une application de protection attend une commande de coupure pour atteindre le disjoncteur, cette connexion ne peut pas être résolue entièrement au sein d’un seul ASD — l’application de disjoncteur est un modèle distinct. Elle est donc modélisée comme un espace réservé ProcessResource, et résolue à l’étape 2 lorsque les deux applications sont combinées.

Les fonctions au sein d’une ASD sont regroupées à l’aide de AllocationRoles — des rôles logiques tels que « PIU », « Contrôleur de baie » ou « Protection ». Un AllocationRole définit ce qu’un IED logique devra faire ; il ne nomme pas un dispositif physique ou un fabricant. À ce stade, aucun fournisseur n’est impliqué du tout.

Dans le prototype démonstré par Elia en décembre 2023 à l’aide de Helinks STS (Helinks/Alvexis), l’équipe a créé deux modèles ASD : une application de disjoncteur avec quatre rôles d’allocation, et une application de protection à distance P21 avec une logique de coupure selon IEC 61131-3. Ces deux modèles étaient entièrement indépendants des capacités des produits de tout fournisseur.

Thomas Sterckx d’Elia a résumé le principe : « Vous pouvez vraiment le faire de manière indépendante de la technologie. C’est également une spécification indépendante du fournisseur. »

Étape 2 : Spécification du système — Exigences d’IED lisibles par machine

À l’étape 2, l’ingénieur instancie les modèles de bibliothèque ASD dans un projet concret. Lorsque deux applications sont combinées, leurs ProcessResources sont résolus : le signal de coupure attendu par l’application de protection vers le disjoncteur est maintenant mappé à la fonction réelle dans l’application de disjoncteur. Le système commence à prendre forme — toujours sans matériel.

Pour chaque IED physique du projet, l’ingénieur génère une Description de spécification d’IED (ISD) : un fichier lisible par machine qui remplace la pile traditionnelle de documents PDF d’exigences. Une ISD contient :

  • Le modèle de données attendu : les dispositifs logiques, les nœuds logiques, les objets de données et les attributs (spécifiés via les éléments DOS/DAS)
  • Les spécifications DataFlow : quels signaux l'IED doit-il recevoir et envoyer, avec le type de service et les UUID SourceRef
  • Les BehaviorDescriptions : la logique fonctionnelle requise que l'IED doit implémenter
  • Les attentes concernant l'interface physique et la nomenclature (éléments LNodeSpecNaming)

Un ISD peut être envoyé simultanément à plusieurs fournisseurs. Chaque fournisseur le traite avec son propre outil de configuration d'IED — non pas en lisant et interprétant du texte, mais en analysant automatiquement le fichier SCL. Les réponses reviennent sous une forme structurée et comparable. Comme l’a expliqué Thomas Sterckx : « Au lieu de donner [au fournisseur de l'IED] une longue série de documents rédigés, vous pouvez lui donner quelque chose de lisible par machine, qu’il peut traiter à l’intérieur de son propre outil. »

La sortie de l’étape 2 est double : des fichiers ISD pour chaque IED, et un SSD (System Specification Description) qui capture la spécification complète du projet — qui sert également d’entrée à l’étape 3. Le SSD est immédiatement transféré à la simulation. Les fichiers ISD, cependant, ne sont pas envoyés aux fournisseurs à ce stade : ils sont transmis uniquement après que la spécification a été validée par simulation (étape 3, ou à la fin du cycle itératif de simulation). Cette séquence est volontaire — envoyer un ISD à un fournisseur avant validation risque de verrouiller une spécification qui n’a pas été confirmée comme fonctionnant comme prévu.

Étape 3 : Simulation et validation du système — Tester avant que le matériel n’existe

C’est l’étape qui définit l’ingénierie par le haut.

Aucun matériel. Aucun fournisseur sélectionné. Aucun contrat signé.

Le SSD ou l’ASD est importé dans un outil de simulation, et le comportement du système est testé par rapport à la spécification fonctionnelle — entièrement en logiciel. Ce qui rend cela possible, c’est la structure formelle de l’ASD lui-même. Une spécification PDF décrit la logique de protection en langage naturel. Un ASD encode les mêmes exigences sous forme de diagrammes de blocs de fonction IEC 61131-3 — une représentation que les outils peuvent analyser, afficher et exécuter directement. Il ne s’agit pas d’une simulation au sens approximatif ; il s’agit de l’exécution directe de la spécification telle qu’écrite.

Deux vues sont disponibles. La première est un graphe de flux de données : les ressources de processus (entrées) à gauche, la logique fonctionnelle au milieu, les sorties à droite. Tous les chemins de signal sont visibles, y compris le type de service et la direction — l’ingénieur peut tracer n’importe quelle entrée vers n’importe quelle sortie avant même que le premier IED ne soit configuré. La seconde est l’exécution du comportement : lorsque l’ASD contient de la logique FBD IEC 61131-3, l’outil la rend graphiquement et permet une manipulation interactive. Atteignez une valeur d’entrée à « active » — le signal se propage en temps réel à travers le diagramme de blocs de fonction, et vous observez quelles sorties se déclenchent.

Pour une validation structurée à grande échelle, les scénarios peuvent être définis sous forme de cas de test tabulaires : une ligne par scénario, avec des valeurs d’entrée prédéfinies et des valeurs de sortie attendues pour chaque signal de l’application. L’outil exécute la séquence, signale les écarts et capture les temps — permettant ainsi de vérifier le comportement dépendant du temps lorsque la précision au millième de seconde est essentielle.

Il est important de noter que la simulation n’est pas nécessairement une étape unique en fin de travail de spécification. Comme l’a décrit Jackson Moore : "cela peut être un processus itératif — les tests peuvent avoir lieu pendant que la conception est encore en cours de développement." En pratique, cela signifie que l’ingénieur peut spécifier une partie de l’ASD ou du SSD, la simuler, la raffiner en fonction des résultats, puis simuler à nouveau — en bouclant sur spécifier → simuler → raffiner jusqu’à ce que le comportement soit entièrement confirmé. L’outil de simulation est intégré au flux de travail de spécification, et non ajouté à la fin.

La sortie de l’étape 3 n’est pas un nouveau fichier. Il s’agit d’une spécification vérifiée — le même SSD ou ASD, confirmé pour se comporter comme prévu. À ce stade, les fichiers ISD sont prêts à être envoyés aux fournisseurs (étape 4) : ils contiennent une spécification qui a été exécutée et validée, et pas simplement rédigée. L’argument économique est direct : une erreur de spécification détectée à l’étape 3 coûte une demi-journée de rework sur un fichier SCL. La même erreur détectée lors de la mise en service — après l’approvisionnement, après la mobilisation, avec du matériel sur site et des équipes déployées — coûte des ordres de grandeur supérieurs. Le mécanisme technique est tout aussi direct : comme le comportement est formalisé en IEC 61131-3 plutôt qu’en langage naturel, il peut être exécuté par un outil indépendamment de tout dispositif spécifique.

Jackson Moore, qui a démontré la simulation dans le prototype Elia : "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 — Le fournisseur répond

Le fichier ISD est envoyé au fabricant de l’IED, qui l’importe dans son outil de configuration d’IED. L’outil croise automatiquement la spécification avec le modèle de données réel du dispositif — identifiant quels nœuds logiques et objets de données sont disponibles, lesquels doivent être créés, et où les conventions de nommage du fournisseur diffèrent de celles de la spécification.

La sortie est un ICD de processus : un fichier ICD standard étendu avec des informations de mappage provenant de l’espace de noms 6-100. Il documente explicitement :

  • La correspondance de chaque nœud logique de la spécification avec le LN réel du fournisseur (mappedLnUuid, mappedDoName)
  • Les emplacements de remplacement des références externes (extRefUuid) liés aux entrées SourceRef de la spécification — ces liens seront résolus automatiquement par le SCT à l’étape 5
  • Toute déviation de BehaviorDescription : si le fournisseur ne peut pas implémenter la logique spécifiée exactement comme écrite, cette déviation est documentée dans le fichier plutôt que laissée implicite
  • La traçabilité basée sur les UUID reliant l’ICD de processus au SSD et à l’ISD d’origine via l’entrée d’en-tête SourceFiles

Les fournisseurs disposent de deux options d’implémentation. Ils peuvent conserver les noms propriétaires tout en documentant la correspondance complète — maximisant ainsi la compatibilité descendante avec les chaînes d’outils existantes. Ou bien, ils peuvent importer le modèle de données unifié issu de la spécification, en adoptant exactement les noms tels qu’indiqués — maximisant ainsi l’interopérabilité, au prix d’un travail d’adaptation plus important au sein du système informatique et de communication (ICT).

Dans le projet pilote Elia, Cedric Harispu a démontré cette étape à l’aide de Siemens DIGSI 5, associé à une unité de fusion 6MU et à un relais de protection de distance 7SA87. DIGSI 5 a reconnu automatiquement les dispositifs logiques à partir du fichier ISD, géré la correspondance LNode-LN, et généré des fichiers ICD de processus pour les deux équipements — y compris la création d’entrées GOOSE qui ne faisaient pas partie de la configuration par défaut de l’équipement.

Le résultat critique : l’ingénieur reçoit une réponse lisible par machine. Les écarts entre la spécification et les capacités du fournisseur sont explicites, traçables et documentés — et non plus enfouis dans des échanges de courriels.

Le fichier ICD de processus n’est pas simplement « la réponse du fournisseur ». Il est conçu pour permettre une vérification automatisée du côté utilisateur. Une fois reçu, le SCT peut automatiquement comparer l’implémentation du fournisseur à la spécification originale — en signalant les signaux non mappés, les écarts de nomenclature et les lacunes dans la description du comportement, sans inspection manuelle. Comme l’a souligné Thomas Sterckx : « ce fichier ICD de processus permet également d’automatiser l’étape de validation du côté utilisateur — pour valider ce que vous avez reçu d’un fournisseur d’IED. »

Étape 5 : Configuration du système — Assemblage automatisé du SCD

L’ingénieur système reçoit les fichiers ICD de processus de tous les fournisseurs et les importe dans l’outil de configuration du système (SCT). Le SCT lit les informations de mappage depuis l’espace de noms 6-100 et automatise l’assemblage du fichier SCD final.

Plus précisément, le SCT :

  1. Crée des instances d’IED à partir des modèles ICD de processus
  2. Résout les entrées SourceRef issues de la spécification en liens ExtRef concrets, en utilisant les mappages extRefUuid fournis par le fournisseur
  3. Génère les ensembles de données, les blocs de contrôle GOOSE et SMV, ainsi que les paramètres de communication
  4. Signale tout signal non résolu — lorsque des éléments de la spécification n’ont pas été couverts dans l’ICD de processus

Dans le projet pilote Elia, l’importation de deux fichiers ICD de processus (unité de pilotage Siemens PIU et relais de protection de distance Siemens) dans Helinks STS a rempli une matrice GOOSE avec des abonnements, généré des blocs de contrôle avec des ensembles de données pour les signaux de position et de déclenchement, et produit une configuration de communication complète — les 28 entrées ExtRef dans l’IED PIU ont été résolues automatiquement, et des blocs de contrôle GOOSE sont apparus là où auparavant il n’y en avait aucun.

Les outils SCT qui prennent en charge l’importation des fichiers ICD de processus et la résolution automatique des liens SourceRef — tels que Tekvel Park — peuvent effectuer cet assemblage avec un intervention manuelle minimale.

Le degré d’automatisation à l’étape 5 est directement proportionnel à la qualité du travail effectué aux étapes 1 à 4. Un ISD complet, une procédure ICD bien exécutée avec une cartographie complète, ainsi qu’une description de comportement validée à l’étape 3 permettent de rendre l’étape 5 largement automatique. Tout manque dans ces fichiers amont se traduit directement par un travail de configuration manuelle ici.

Suite à l’export du SCD, le fichier est renvoyé au fournisseur d’IED pour le chargement final du dispositif. Dans le projet pilote (PoC) d’Elia, le SCD a été importé dans DIGSI 5 et vérifié dans un environnement Siemens Digital Twin — deux dispositifs virtuels confirmant la réception correcte des valeurs échantillonnées, le comportement d’abonnement GOOSE et la cohérence des noms du modèle de données avant toute intervention sur du matériel physique.

Ce que cela change

L’ingénierie top-down IEC 61850 change trois aspects pour l’ingénieur praticien. Les erreurs de spécification sont détectées pendant la phase de conception — avant les décisions d’achat, avant les engagements des fournisseurs, avant que tout matériel ne soit sur site. L’interaction avec les fournisseurs d’IED devient structurée : un ISD remplace les documents PDF, un process ICD remplace les réponses informelles, et l’échange entier devient lisible par machine et traçable. Et la sélection des fournisseurs devient véritablement compétitive : un seul ISD envoyé à plusieurs fournisseurs produit des réponses comparables et structurées pouvant être évaluées sur des critères techniques.

Thomas Sterckx d’Elia l’a dit directement : "Vous pouvez maintenant tester ce que vous avez conçu avant qu’il ne soit mis en œuvre dans un dispositif. Beaucoup d’erreurs potentielles peuvent maintenant être identifiées beaucoup plus tôt dans le processus d’ingénierie."

Les normes techniques sont publiées. Les outils existent. Le processus d’approvisionnement est en cours chez Elia. L’article suivant de cette série examine concrètement comment le format ISD transforme le processus d’achat et de mise en concurrence des IED.

Sources

  1. Thomas Sterckx, Yannick Thiessoz, Jackson Moore, Cedric Harispu — IEC 61850 Top-Down Engineering PoC Webinar (Groupe Elia, décembre 2023)
  2. Groupe Elia — Common Vision for IEC 61850 Top-Down Engineering (2023)
  3. TR IEC 61850-90-30:2025 — Réseaux de communication et systèmes pour l’automatisation des services publics — Partie 90-30 : Lignes directrices pour l’ingénierie système IEC 61850
  4. TR IEC 61850-7-6:2024 (Éd. 2) — Lignes directrices pour la gestion des systèmes et des projets IEC 61850