Sur la base de nos observations, 8 configurateurs sur 10 ne reconnaissent pas entièrement la configuration des fichiers SCD. Nous avons récemment rencontré un cas intéressant d’importation incorrecte qui nous a amenés à rédiger tissue 1791.
Contexte
Dans le cadre d’un de nos projets impliquant 43 IED (Intelligent Electronic Devices), nous avons développé un fichier SCD (Substation Configuration Description). L’équipement décrit dans le fichier comprenait des convertisseurs de signaux analogiques, des convertisseurs de signaux discrets, des terminaux de relais de protection et d’automatisation, ainsi que des contrôleurs de baie provenant de 8 fabricants différents. Lors de la conception du fichier SCD, nous avons pris en compte les spécificités de configuration des équipements de chaque fabricant afin d’assurer la compatibilité et une configuration unifiée lors de la mise en service.
Lors de l’importation du fichier SCD et de sa reconnaissance par les configurateurs d’IED (ICT), il a été constaté qu’un équipement d’un fabricant ne pouvait pas s’abonner aux messages GOOSE et aux flux de Valeurs Échantillonnées (SV). Cette capacité était absente car les blocs de contrôle configurés n’étaient pas affichés lors de l’importation des configurations des dispositifs émetteurs. Le fichier développé a passé la validation syntaxique SCL sans erreur, et l’ICT n’a signalé aucun problème lors de l’importation. Il s’est avéré que la raison pour laquelle les blocs de contrôle n’étaient pas affichés résidait dans l’absence de l’attribut confRev dans les blocs de contrôle du dispositif émetteur dans le fichier SCD. Dans cet article, nous examinerons pourquoi le configurateur du fabricant n’a pas affiché la configuration et si un tel comportement est correct.
Qu’est-ce que l’attribut confRev et à quoi sert-il ?
confRev est un attribut qui indique le nombre de fois que la configuration de l’ensemble de données référencée par l’attribut DatSet d’un bloc de contrôle a été modifiée. Cet attribut est requis pour la synchronisation de configuration entre l’émetteur et le récepteur ; sa valeur actuelle est incluse dans le message GOOSE publié et dans le flux SV.
Si un récepteur reçoit un cadre dont la valeur de confRev diffère de la valeur attendue sur la base de la configuration chargée, cela indique un déséquilibre entre la version de configuration de l’émetteur et la version réelle. La possibilité pour le récepteur de vérifier cet attribut peut être déterminée à partir du document PIXIT du dispositif.
Dans le PIXIT considéré, il est indiqué que le récepteur vérifie la valeur de confRev. Par conséquent, si cette valeur diffère de la valeur attendue, les signaux provenant du message entrant ne seront pas traités. Cet attribut fournit ainsi un moyen de protéger le dispositif récepteur contre une interprétation incorrecte des signaux entrants.
Évolution de confRev
Depuis la publication de l’IEC 61850 Édition 1 jusqu’à l’Édition actuelle 2.1, les exigences décrivant le rôle fonctionnel de l’attribut confRev ont été progressivement formalisées — des modifications qui ont directement contribué au problème que nous avons rencontré.
IEC 61850 Ed1
Dans la première édition de l'IEC 61850, confRev est défini comme le numéro de révision de la configuration du bloc de commande. Cet attribut est obligatoire pour les blocs de commande Report et facultatif pour les blocs de commande GOOSE et SV.
Pour les blocs de commande Report, confRev doit être incrémenté lorsqu'un élément est supprimé du jeu de données ou lorsque l'ordre des éléments change.
La valeur initiale de confRev n'est pas spécifiée par la norme. La valeur 0 est réservée.
La valeur de confRev ne doit pas être réinitialisée à sa valeur initiale lors d'un redémarrage de l'appareil.
IEC 61850 Édition 2
Avec la publication de l'Édition 2, la formalisation de l'attribut confRev a été étendue et partiellement révisée.
confRev est désormais défini comme un attribut reflétant le nombre de fois où la configuration du jeu de données référencé par l'attribut DatSet a été modifiée.
La différence clé par rapport à l'Édition 1 est que confRev devient obligatoire pour les blocs de commande GOOSE et SV dans le corps de la norme. Cependant, dans le schéma XML de l'Édition 2, confRev pour les blocs de commande GOOSE et SV reste facultatif.
Les conditions nécessitant une incrémentation de l'attribut ont été formalisées.
Modifications qui doivent être suivies pour les blocs de commande Report :
- suppression d'un élément du jeu de données ;
- changement de l'ordre des éléments du jeu de données ;
- configuration du jeu de données via le service SetBRCBValues qui modifie la valeur de l'attribut DatSet.
Modifications qui doivent être suivies pour les blocs de commande GOOSE :
- suppression d'un élément du jeu de données ;
- ajout d'un élément au jeu de données ;
- changement de l'ordre des éléments du jeu de données ;
- modification de la configuration via SetGoCBValues, où l'IED est responsable de l'incrémentation de confRev ;
- référence à une valeur DatSet déjà définie via SetGoCBValues.
Modifications qui doivent être suivies pour les blocs de commande SV :
- suppression d'un élément du jeu de données ;
- changement de l'ordre des éléments du jeu de données ;
- changement des valeurs des attributs MsvID, DatSet, SmpMod, SmpRate, OptFids.
À noter que pour les blocs de commande SV, l'incrémentation de confRev est affectée non seulement par les modifications de la configuration du jeu de données, mais aussi par les paramètres propres du bloc de commande.
Les modifications de la configuration du jeu de données via des services ne sont pas autorisées pour les blocs de commande SV.
Une recommandation a été ajoutée concernant l'étape d'incrémentation de confRev (pour les blocs de commande GOOSE et SV — tissue 1590 soulève la question de savoir pourquoi une recommandation analogue ne s'applique pas aux blocs de commande Report — cette question fait toujours l'objet de discussion) : la norme recommande d'incrémenter de 10 000 lorsque le changement intervient via les configurateurs (SCT, ICT), et de 1 lorsqu'il est modifié via les services MMS.
La valeur initiale de confRev n'est pas définie par l'IEC 61850, mais une plage d'entiers de 0 à 4 294 967 295 est spécifiée.
Le comportement de confRev pour les blocs de commande Report et GOOSE lors du redémarrage de l'appareil peut être implémenté de deux manières :
- restaurer la valeur à partir de la configuration de base ;
- restaurer la valeur à partir de la configuration au moment du redémarrage.
L'implémentation pour un appareil spécifique doit être indiquée dans le PIXIT.
Pour les blocs de contrôle SV, confRev ne doit pas être réinitialisé lors d’un redémarrage — il doit être restauré à partir de la configuration précédant le redémarrage.
La responsabilité de modifier la valeur de cet attribut incombe aux configurateurs (SCT et ICT). Les SCT et ICT doivent définir la valeur de confRev du bloc de contrôle lors de sa création ou de sa modification, conformément à la norme IEC 61850-7-2.
IEC 61850 Édition 2.1
Les exigences actuellement applicables pour confRev sont celles de l’Édition 2.1. Elles coïncident presque entièrement avec l’Édition 2, avec les ajouts suivants :
- pour la valeur réservée confRev=0 (héritée de l’Édition 2), une clarification a été ajoutée précisant qu’elle ne doit être utilisée que pour les blocs de contrôle Report, GOOSE ou SV qui ne possèdent aucune référence à un jeu de données ;
- pour les blocs de contrôle Report, confRev sera incrémenté lorsqu’un élément est ajouté au jeu de données. Toutefois, selon la réponse à tissue 673, l’Édition 2 autorise également l’incrémentation de confRev lors de l’ajout de nouveaux éléments au jeu de données, même si cette action n’est pas explicitement listée parmi les changements déclencheurs.
Investigation
Revenons au problème qui a motivé cet article. Le configurateur avait-il raison de refuser l’importation des blocs de contrôle GOOSE et SV depuis le fichier SCD, empêchant ainsi la finalisation de la configuration de l’appareil ?
Le problème observé découle d’une incohérence entre les exigences relatives à la présence de l’attribut dans le texte de la norme et dans le schéma. La validation intégrée des outils SCT et ICT vérifie généralement uniquement la conformité à la syntaxe SCL déclarée dans les schémas XML. En conséquence, les fichiers ICD sans confRev — et les fichiers SCD qui en dérivent, eux aussi sans confRev — passent avec succès la validation.
Dans notre tissue, nous avons proposé de rendre confRev obligatoire afin que les schémas des Éditions 2 et 2.1 soient alignés sur le texte de la norme et permettent de détecter les erreurs lors de la validation. La réponse reçue indiquait que l’attribut resterait optionnel dans le schéma afin de préserver la compatibilité descendante entre les éditions, et que la validation par les configurateurs ne devrait pas se limiter aux vérifications de schémas XML.
En travaillant avec les outils SCT et ICT provenant de fabricants russes, nous constatons que la plupart ne respectent pas les exigences de la norme concernant confRev. Étant donné que les fichiers SCL ne sont validés que par rapport au schéma XML — où confRev est optionnel pour GOOSE et SV — l’attribut est souvent absent des blocs de contrôle dans les fichiers ICD, et n’est donc pas ajouté par le SCT. Et lorsque confRev est présent dans l’ICD, les outils conservent sa valeur inchangée, ce qui signifie que les modifications de la configuration du jeu de données ne sont pas du tout suivies.
En examinant d’autres tissues sur le site de la base de données tissue, nous avons remarqué que personne n’avait précédemment soulevé ce problème — ce qui signifie que les collègues étrangers ne l’ont peut-être pas rencontré ou n’y ont pas prêté attention. Pour examiner une implémentation étrangère, nous avons utilisé l’ICT d’un fabricant bien connu largement déployé sur des installations, y compris en Russie.
Au cours de l’analyse, les modifications de la valeur confRev ont été testées en reproduisant divers scénarios opérationnels ainsi que des scénarios issus des procédures de test des ICT et des SCT.
Résultats
Lors de la création d’un bloc de contrôle GOOSE, l’ICT a attribué une valeur par défaut de 1.
La valeur 0 n’a pas été utilisée car l’ICT examiné fonctionne selon l’Édition 2. Nous avons également essayé de charger un ICD sans confRev : l’ICT a attribué une valeur par défaut de 1.
Lorsqu’une référence de jeu de données a été assignée au bloc de contrôle, confRev a été incrémenté de 10 000.
Lorsque la référence de jeu de données a été supprimée du bloc de contrôle GOOSE, confRev a été à nouveau incrémenté de 10 000.
Les modifications ultérieures — réorganisation des attributs du jeu de données, suppression d’attributs du jeu de données et modification de la référence du jeu de données — ont toutes provoqué une augmentation de confRev de 10 000, conformément aux recommandations de l’IEC 61850.
Lors de la tentative de suppression de la valeur confRev du bloc de contrôle, l’ICT a refusé de sauvegarder la configuration, invoquant la plage valide de 0 à 4 294 967 295.
Conclusions
Pour résumer l’investigation : le configurateur du fabricant sur notre projet a mal fonctionné lors de l’importation du fichier SCD. Le fichier SCD ne répondait pas aux exigences de la norme, pourtant l’ICT a chargé la configuration invalide sans informer l’utilisateur d’aucune erreur. Le problème a également été identifié du côté du SCT, utilisé pour développer le fichier : il a permis la création et l’exportation d’un fichier ne respectant pas l’IEC 61850.
Pour prévenir de tels problèmes à l’avenir, les développeurs de SCT et d’ICT devraient examiner la manière dont leurs outils traitent l’attribut confRev et s’assurer que sa valeur est incrémentée lorsque :
- la référence du jeu de données du bloc de contrôle change (modification de l’attribut DatSet) ;
- des éléments sont supprimés du jeu de données ;
- l’ordre des attributs dans le jeu de données change ;
- des éléments sont ajoutés au jeu de données.
Pour les blocs de contrôle SV, en outre lorsque :
- les paramètres MsvID, DatSet, SmpMod, SmpRate, OptFids changent.
Les procédures de test IEC 61850-10 pour les ICT et les SCT, ainsi que les documents Server Devices with IEC 61850-8-1 et PIXIT, spécifient la manière dont les outils et les dispositifs doivent se comporter lorsque la configuration du jeu de données d’un bloc de contrôle change.
Les développeurs de fichiers ICD et IID doivent vérifier la présence de confRev dans les blocs de contrôle s’il est déjà inclus dans le fichier.
Tekvel a mis au point des logiciels permettant des tests de conformité automatisés des configurateurs d’IED (ICT) et des configurateurs de système (SCT) par rapport aux exigences de l’IEC 61850. Les tests des ICT et des SCT sont tout aussi importants que les tests de conformité des IED déjà établis et largement pratiqués. De telles vérifications sont essentielles pour la mise en œuvre réussie du flux de travail d’ingénierie proposé par l’IEC 61850.
Comme indiqué en réponse à notre tissue, des outils supplémentaires d’analyse de fichiers SCD sont nécessaires — des outils capables de vérifier la configuration non seulement par rapport au schéma XML, mais également aux exigences de la norme elle-même. L’un de ces outils est Tekvel Inspector. Tekvel Inspector est utilisé sur les marchés russes et internationaux pour l’examen expert de fichiers SCD en cours de développement. L’outil identifie les non-conformités par rapport au schéma et à la norme, aide les clients finaux et les concepteurs de fichiers SCD en indiquant les zones de configuration nécessitant une attention particulière, et fournit des références aux normes pertinentes pour guider les bonnes pratiques de configuration. L’utilisation d’un fichier SCD ayant passé un examen expert par Tekvel Inspector lors de la mise en service permet d’éviter un grand nombre de problèmes liés à la configuration, réduisant ainsi la durée des travaux de mise en service.
Il est également important de souligner la nécessité d’un suivi continu des valeurs de l’attribut confRev lors de la mise en service et des opérations ultérieures. À ces étapes, lorsque l’ensemble de données sortant d’un émetteur est reconfiguré — entraînant un changement de confRev — il est essentiel de savoir que ce changement a eu lieu. Dans ce scénario, l’appareil émetteur transmettra des messages GOOSE/SV avec une valeur confRev mise à jour différente de celle spécifiée dans le fichier SCD, tandis que l’appareil récepteur attendra la valeur indiquée dans ce même fichier SCD. Dans ces circonstances, identifier la cause racine des problèmes de communication devient extrêmement difficile, car les deux appareils ont été configurés à l’aide du même fichier SCD. Sans un suivi continu des changements, cela conduit à une isolation prolongée des pannes — et en fin de compte à des durées globales de mise en service et de maintenance plus longues.
L’installation du complexe logiciel et matériel Tekvel Park en tant que système de surveillance dans une sous-station permet d’éviter de tels problèmes. La surveillance continue et la diagnostic des communications IEC 61850 permettent au personnel de mise en service et d’exploitation d’identifier en temps réel qu’une configuration spécifique d’un IED (intelligent electronic device) a changé. Cela améliore la visibilité du système en fonctionnement et renforce l’efficacité opérationnelle.