Dans les projets de postes numériques, on accorde généralement beaucoup d'attention à GOOSE, SV, PTP et à l'infrastructure réseau. C'est compréhensible : GOOSE et SV sont des communications extrêmement critiques — sensibles aux délais, à la perte de paquets et à la qualité de l'infrastructure réseau, tandis que la synchronisation temporelle conditionne directement la fiabilité des mesures et des événements.
Mais il existe une autre couche importante, sans laquelle le poste numérique ne devient pas un véritable système d'automatisation — l'échange MMS et, en particulier, les comptes rendus IEC 61850. C'est par les comptes rendus que le SCADA, le système de conduite, l'IHM, les passerelles et les systèmes de supervision reçoivent la téléinformation — télésignalisation et télémesure — des équipements électroniques intelligents (IED).
En pratique, les problèmes de comptes rendus IEC 61850 paraissent souvent trompeusement simples : la connexion MMS est établie, l'équipement est joignable, le client « voit » le serveur, mais les données ne se mettent pas à jour, une partie des signaux disparaît, les événements se dupliquent ou le bloc de contrôle des comptes rendus ne s'active tout simplement pas. La cause n'est presque jamais un seul « mauvais paquet », mais une incohérence entre le modèle de données, la configuration SCL, les réglages client et la configuration réelle de l'IED.
Voici les problèmes les plus aigus rencontrés lors du travail avec les blocs de contrôle des comptes rendus dans l'IEC 61850.
La connexion MMS est établie, mais le bloc de contrôle des comptes rendus n'est pas activé
L'une des situations les plus fréquentes : le client établit avec succès la connexion MMS avec l'IED, mais aucune donnée de compte rendu n'arrive. Au niveau réseau, tout semble normal : la joignabilité IP est là, la session TCP est établie, la connexion MMS est active.
La première chose à vérifier est l'état de l'attribut RptEna du bloc de contrôle des comptes rendus concerné.
RptEna = true signifie que le bloc de contrôle des comptes rendus est activé par le client et doit transmettre les données conformément à sa configuration.
RptEna = false signifie que le bloc de contrôle des comptes rendus n'est pas activé, donc aucune donnée ne transite par lui.
Le piège est qu'une connexion MMS réussie ne signifie pas en soi que les comptes rendus se sont mis à fonctionner. Le serveur MMS peut répondre aux requêtes, permettre la lecture du modèle de données et renvoyer des valeurs d'attributs isolés — et pourtant le bloc de contrôle des comptes rendus reste inactif.
Conclusion pratique : lors du diagnostic, on ne peut pas se limiter au contrôle « liaison ou non ». Il faut vérifier l'état du bloc de contrôle des comptes rendus concret, avant tout l'attribut RptEna.
Divergence de ConfRev : le client refuse d'activer le compte rendu
ConfRev est un compteur de révision de configuration. Selon l'IEC 61850-7-2 (ed.2.0, §17.2.2.7 pour les blocs bufferisés et de façon analogue pour les non bufferisés), il reflète le nombre de modifications du jeu de données (DataSet) que le bloc de contrôle des comptes rendus référence via l'attribut DatSet.
La norme énumère explicitement quelles modifications incrémentent ConfRev :
- la suppression d'un membre du jeu de données ;
- l'ajout d'un membre du jeu de données ;
- le réordonnancement des membres du jeu de données ;
- la modification de la valeur de l'attribut
DatSet(basculement du bloc vers un autre jeu de données).
Voici un détail souvent mal compris : ConfRev ne change pas lorsqu'on modifie les autres paramètres du bloc de contrôle des comptes rendus lui-même — TrgOps, BufTm, IntgPd, OptFlds, RptID et autres. Autrement dit, modifier les déclencheurs, le temps de bufférisation ou la période d'integrity n'augmente pas, à soi seul, ConfRev. Cette révision est « liée » précisément à la composition et à l'ordre du jeu de données, et non aux réglages de transmission des comptes rendus en général.
De nombreux clients IEC 61850, à la connexion, lisent le ConfRev du modèle actif du serveur et le comparent à la valeur qu'ils attendent d'après le fichier SCL/CID. Si les valeurs ne concordent pas, le client peut refuser d'activer le bloc de contrôle des comptes rendus.
En pratique, une divergence de ConfRev indique presque toujours que la composition du jeu de données dans l'équipement et dans la configuration du client a divergé. Causes typiques :
- la composition du DataSet a été modifiée ;
- un signal a été ajouté ou supprimé ;
- les membres du jeu de données ont été réordonnés ;
- le bloc de contrôle des comptes rendus a été basculé vers un autre DataSet ;
- le fichier CID a été reconstruit avec un jeu de données mis à jour ;
- une nouvelle configuration a été chargée dans l'équipement ;
- le projet SCADA a été mis à jour mais non synchronisé avec la configuration réelle de l'IED.
Il en résulte parfois sur le site une situation paradoxale : dans la documentation de projet et le fichier SCL tout semble correct, mais le client n'active pas le compte rendu parce que le ConfRev réel dans l'équipement est différent.
C'est particulièrement dangereux lorsque différents intervenants du projet travaillent avec des versions différentes des fichiers SCL : le metteur en service utilise une version de CID, le développeur SCADA une autre, le fabricant de l'équipement en a chargé une troisième, et une quatrième se trouve dans l'archive du projet.
Conclusion pratique : en cas de problème de comptes rendus, il faut comparer non seulement le fichier SCL qui « devrait » être dans l'équipement, mais le modèle réel que le serveur fournit via MMS. Un navigateur MMS ou l'analyse d'une capture PCAP est utile ici. Et comme ConfRev suit précisément le jeu de données, en cas de divergence de révision il faut chercher avant tout la différence de composition, d'ordre et de types des éléments du DataSet.
Un bloc de contrôle des comptes rendus est déjà occupé par un autre client
Sur un poste numérique, un même IED sert souvent plusieurs clients : SCADA, IHM, passerelle de téléconduite, système de supervision, station d'ingénierie, enregistreur d'événements, etc. Tous peuvent vouloir recevoir le même jeu de données.
Mais une seule instance d'un bloc de contrôle des comptes rendus ne peut pas être activée par plusieurs clients à la fois. Si un client a déjà activé un bloc de contrôle des comptes rendus donné, un second client, en tentant de l'activer, recevra un refus et ne pourra tout simplement pas activer le compte rendu.
Un signe du problème est RptEna déjà à true alors que « notre » client n'a pas encore activé ce compte rendu.
Commence alors la difficulté pratique : le serveur n'indique pas toujours quel client exactement a occupé le bloc de contrôle des comptes rendus (via l'attribut Owner). Parfois on le voit dans le diagnostic de l'IED, parfois seulement à partir du trafic réseau, en analysant les adresses IP des clients qui lisent et écrivent les attributs du bloc de contrôle des comptes rendus.
L'IEC 61850 prévoit un mécanisme d'indexation du Report Control Block. Par exemple, au lieu d'un seul BRep01, le serveur peut prendre en charge les instances BRep0101, BRep0102, etc. Cela permet à plusieurs clients de travailler avec des instances différentes d'un même bloc de contrôle des comptes rendus logique.
Mais en pratique la prise en charge de l'indexation dépend de l'équipement et du client précis. De plus, si le client « cherche lui-même un index libre », cela peut entraîner un comportement inattendu lors des redémarrages, des pertes de liaison et des rétablissements de connexion.
Conclusion pratique : pour les systèmes critiques, mieux vaut ne pas s'appuyer sur la recherche automatique d'un bloc de contrôle des comptes rendus libre, mais affecter d'avance à chaque client sa propre instance. Cela doit figurer dans la configuration, les fichiers SCL et les réglages SCADA/IHM/passerelle.
Le bloc de contrôle des comptes rendus est activé, mais les événements n'arrivent pas
Autre problème fréquent : RptEna = true, le bloc de contrôle des comptes rendus est activé, mais les données n'arrivent pas lorsque les signaux changent. Parfois le client ne reçoit des données que périodiquement, parfois seulement après une General Interrogation, parfois rien du tout.
Ici il faut regarder TrgOps — Trigger Options.
C'est précisément ce paramètre qui définit pour quelles raisons le serveur doit générer un compte rendu. L'IEC 61850 utilise les options principales suivantes :
data-change— transmission au changement de valeur ;quality-change— transmission au changement de qualité ;data-update— transmission à la mise à jour des données ;integrity— transmission périodique de l'état complet ;general-interrogation— transmission sur demande d'interrogation générale.
Le problème pratique le plus aigu est qu'un compte rendu peut être formellement activé alors que les déclencheurs nécessaires ne le sont pas.
Par exemple, si seul integrity est actif, le client recevra des mises à jour périodiques mais ne verra pas les événements au moment où les signaux changent.
Si quality-change n'est pas actif, le client peut ne pas recevoir un changement de qualité des données, alors que pour l'exploitation c'est critique : le signal peut rester dans le même état tandis que sa qualité passe à invalid, questionable, substituted ou test.
Si l'écriture des trigger options nécessaires n'est pas prise en charge côté client, celui-ci peut tenter d'activer les flags, mais le serveur refusera l'écriture. Résultat : le bloc de contrôle des comptes rendus est activé, mais ne fonctionne pas comme l'attend l'intégrateur.
Conclusion pratique : lors de la mise en service des comptes rendus, il faut vérifier non seulement que le bloc de contrôle des comptes rendus est activé, mais aussi la valeur réelle de TrgOps dans le modèle actif de l'IED. Il est particulièrement important de contrôler data-change, quality-change, integrity et general-interrogation.
Le DataSet dans le client ne correspond pas au DataSet dans l'équipement
Le bloc de contrôle des comptes rendus ne contient pas en lui-même tous les signaux. Il référence un DataSet — le jeu de données qui doit être transmis au client.
Si le client et le serveur comprennent différemment la composition du DataSet, les problèmes les plus désagréables commencent : une partie des signaux se met à jour, une partie non, les valeurs « glissent », la qualité est interprétée de façon incorrecte et le diagnostic devient peu évident.
Dans la réponse MMS, les données du jeu sont transmises non pas comme des « signaux nommés avec des tags lisibles », mais comme une séquence d'éléments. Le client doit savoir d'avance quel élément correspond à quel signal. Si la composition du DataSet a changé dans le serveur alors que le client continue d'utiliser l'ancienne description, la correspondance est rompue.
Et l'on pourrait penser que l'attribut confRev décrit plus haut devrait protéger contre ce problème — mais que faire si le client ne le traite pas ?
Un exemple simple : le client attend dix signaux SPS, alors que dans l'équipement le deuxième élément du jeu a été remplacé par un DPS. Extérieurement, le compte rendu peut continuer d'arriver, mais le client ne peut plus interpréter correctement toute la séquence de données. Beaucoup de clients, dans cette situation, traitent une partie des données jusqu'à la première incompatibilité de type, puis cessent de mettre à jour les éléments restants.
Du point de vue de l'exploitation, c'est dangereux car le problème peut ressembler non pas à une perte totale de communication, mais à une dégradation partielle : « une partie des signaux se met à jour, une partie est figée ».
Conclusion pratique : en cas de soupçon de mise à jour incorrecte des données, il faut comparer la composition réelle du DataSet dans l'IED à la configuration du client. Il est important de vérifier non seulement le nombre d'éléments, mais aussi leur ordre, les types de données, les contraintes fonctionnelles et les références aux Data Object / Data Attribute concrets. Rappelons que ce sont précisément les modifications de ce jeu que reflète ConfRev — c'est pourquoi une divergence de DataSet et une divergence de ConfRev vont généralement de pair.
Doublons d'événements issus d'un bloc de contrôle des comptes rendus bufferisé
Les comptes rendus bufferisés servent à ce que les événements ne soient pas perdus lors d'une perte temporaire de la liaison entre le client et le serveur. Le serveur bufferise les événements, et après le rétablissement de la connexion le client doit recevoir ce qu'il a manqué.
Mais il y a ici un détail important de l'IEC 61850 : le serveur attribue à chaque événement un entryID, et le client doit suivre correctement quels entryID ont déjà été traités.
Si le client gère mal l'entryID, lors d'une perte de liaison, d'un redémarrage du client ou d'une réactivation du bloc de contrôle des comptes rendus bufferisé, il peut traiter les mêmes événements à nouveau. Dans les journaux d'événements, cela apparaîtra comme une duplication.
Il est particulièrement important de tenir compte des différences de comportement entre implémentations et éditions de la norme. Dans certains scénarios, le serveur, à la reconnexion, peut transmettre tous les événements du buffer si le client n'a pas écrit le bon entryID avant d'activer RptEna.
Conclusion pratique : si des événements en double apparaissent dans le système, il faut analyser non seulement les événements eux-mêmes, mais aussi le comportement du client face au bloc de contrôle des comptes rendus bufferisé : comment il stocke l'entryID, ce qu'il écrit à la reconnexion, comment il réagit à la perte de liaison et au redémarrage.
Une foi excessive dans le fichier SCL
L'une des principales causes de problèmes avec les comptes rendus IEC 61850 est la certitude que le fichier SCL/CID disponible correspond exactement à ce qui est réellement chargé dans l'équipement.
En pratique, ce n'est pas toujours le cas. Certains équipements sont configurés non pas directement à partir d'un fichier CID, mais via leurs propres outils d'ingénierie et leurs fichiers de réglages internes. Parfois le CID est exporté de l'équipement mais n'est pas la source de sa configuration active. Parfois, après des modifications dans le logiciel d'ingénierie, la nouvelle configuration n'a pas été chargée dans l'IED. Parfois le SCADA a été configuré à partir d'un fichier alors que l'équipement fonctionne avec un autre.
C'est pourquoi, lors de l'investigation de problèmes de comptes rendus, il est utile de travailler avec trois sources à la fois :
- le fichier SCL/CID considéré comme celui du projet ;
- le modèle MMS réel, lu depuis l'équipement ;
- la capture PCAP de l'échange entre client et serveur.
Si ces trois sources ne concordent pas, le problème vient presque certainement d'une désynchronisation des configurations. Bien entendu, tout cela peut être détecté automatiquement à l'aide d'un système de supervision IEC 61850.
Ce qu'il importe de prendre en compte à la réalisation
De nombreux problèmes de comptes rendus IEC 61850 peuvent être évités dès l'étape de conception et de mise en service.
Pour chaque client, il faut définir d'avance quels blocs de contrôle des comptes rendus il utilise.
Si plusieurs clients reçoivent les mêmes données, il faut leur affecter explicitement des instances différentes de blocs de contrôle des comptes rendus, plutôt que de compter sur la sélection automatique d'un index libre.
La composition du DataSet doit être figée et synchronisée entre l'IED, le SCADA, l'IHM, les passerelles et les systèmes de supervision.
Après une modification de la composition du DataSet, il faut contrôler le changement de ConfRev et mettre à jour les configurations client. Cela dit, il faut garder à l'esprit que modifier uniquement les paramètres du bloc (par exemple TrgOps ou BufTm) ne change pas ConfRev — mais la configuration client peut malgré tout devoir être mise en conformité.
Pour les comptes rendus bufferisés, il faut vérifier séparément les scénarios de perte de liaison, de redémarrage du client et de rétablissement de la connexion.
Les essais de réception devraient inclure non seulement le contrôle « les données arrivent », mais aussi celui des changements événementiels, des changements de qualité, de la General Interrogation, des comptes rendus integrity et du comportement à la coupure de connexion.
Conclusion
Les comptes rendus IEC 61850 ne sont pas un simple « relevé de données via MMS ». C'est un mécanisme de transmission sporadique, événementielle, dans lequel comptent le modèle de données, le DataSet, les déclencheurs, la bufférisation, les révisions de configuration et le comportement du client.
Les problèmes les plus aigus naissent généralement non pas d'une défaillance réseau, mais d'une désynchronisation entre ce qu'attend le client et ce qui est réellement configuré dans l'IED.
C'est pourquoi le principe clé du diagnostic est simple : ne pas se fier à une seule source d'information. Le fichier SCL, les réglages client, le modèle MMS réel de l'équipement et la capture PCAP doivent être considérés ensemble.
C'est précisément cette approche qui permet de distinguer rapidement un problème réseau d'un problème de configuration, de trouver la cause d'un compte rendu qui ne fonctionne pas et d'éviter les situations où la connexion MMS est établie, mais où le poste numérique ne reçoit en fait pas de téléinformation fiable.