Cas Magic #2 : audit des blocs de contrôle des comptes rendus dans les IED — en un clic

Dans un article précédent, nous avons examiné le cas dans lequel Tekvel Magic confronte la configuration des jeux de données, des comptes rendus et des blocs de contrôle de transmission GOOSE et Sampled Values décrits dans un fichier SCL à la configuration réelle des IED. Aujourd'hui — un autre cas : comment, en un clic, obtenir un instantané de l'état courant des blocs de contrôle de transmission des comptes rendus (URCB / BRCB) sur plusieurs équipements à la fois.

Pourquoi creuser du côté des RCB

Les blocs de contrôle de transmission des comptes rendus sont un « contrat » entre le serveur (l'IED) et les clients (SCADA, passerelles, automates de niveau supérieur, outils de diagnostic). Le serveur publie des données via des blocs de contrôle bufferisés (BRCB) et non bufferisés (URCB) ; le client réserve le bloc dont il a besoin, l'active (RptEna = true) et commence à recevoir des événements sur changement de données, changement de qualité ou de manière périodique (ou à la demande). Sur un ouvrage réel, ces blocs sont en général configurés dans les équipements, mais savoir qui les utilise vraiment une fois le poste mis en service est une autre question.

Il existe par ailleurs des cas franchement désagréables : les comptes rendus dans les équipements ne sont réservés par personne, alors que le client de niveau supérieur, au lieu de s'abonner aux événements, parcourt l'ensemble des serveurs avec un polling périodique tout simple. « Tout a l'air de fonctionner », mais le modèle événementiel de l'IEC 61850 — précisément celui pour lequel la transition vers le poste numérique a été engagée — est, en réalité, désactivé. La charge sur le réseau augmente, le déterminisme de la réaction est perdu, les événements sont « collés » par la période de polling, et le simple fait que les comptes rendus ne soient pas utilisés peut rester ignoré pendant des années — jusqu'à l'analyse d'un incident. Une seule passe d'audit révèle cet état instantanément.

Quels blocs sont actuellement activés dans les équipements du poste ? Quels clients les ont réservés ? Quels déclencheurs (TrgOps) et champs optionnels (OptFlds) sont configurés ? Quels jeux de données leur sont rattachés et quelle est la composition de ces jeux ? Quelles sont les valeurs de BufTm et de IntgPd, et sont-elles cohérentes avec ce que l'on attendait de la documentation de projet ? Ces questions reviennent régulièrement à la réception de l'ouvrage : les représentants techniques du client final ont besoin de s'assurer que les comptes rendus fonctionnent réellement et sont réellement utilisés — et non « configurés puis laissés en plan ». Auparavant, ce genre d'instantané se constituait à la main : petit à petit, avec un navigateur de modèle de données, des relevés sur papier et des conversations avec l'intégrateur. Aujourd'hui, le même résultat sort d'une seule passe.

Comment cela fonctionne

Le scénario est le scénario habituel. Vous êtes sur le site, un ordinateur portable équipé de Tekvel Magic est raccordé au réseau du poste, et le fichier SCD du projet est à portée de main. Vous lancez l'essai — et la toute première boîte de dialogue demande comment vous voulez désigner l'équipement :

• saisir manuellement l'adresse IP de l'équipement (lorsque le SCD n'est pas encore disponible ou que vous vérifiez un point précis), ou
• choisir l'équipement à partir du fichier SCD — la boîte de dialogue affiche alors la liste des IED avec leurs noms et leur attribut desc (descriptions), avec sélection unitaire ou multiple.

Dans le second cas, Tekvel Magic récupère lui-même les adresses IP des équipements choisis dans la section Communication (ConnectedAP / Address / P type="IP") et se connecte à chacun d'eux via MMS. Ainsi, en un clic, vous pouvez réaliser un audit de l'utilisation des comptes rendus sur, par exemple, huit équipements à la suite — vous obtenez un document distinct par équipement.

Une fois l'association MMS établie, l'outil lit le modèle de données complet de l'équipement, identifie tous les blocs URCB et BRCB et interroge leurs attributs — RptID, RptEna, DatSet, ConfRev, OptFlds, BufTm, SqNum, TrgOps, IntgPd, GI, Resv, Owner (pour les URCB), plus PurgeBuf, EntryID, TimeOfEntry, ResvTms (pour les BRCB). En parallèle, Tekvel Magic récupère la composition de chaque jeu de données. Le résultat est un procès-verbal au format MS Word.

Ce que contient le procès-verbal

À l'ouverture du document, vous voyez une table des matières générée automatiquement et trois sections principales : paramètres de connexion, tableau récapitulatif des blocs et informations détaillées pour chacun d'eux.

Le tableau récapitulatif comporte une ligne par RCB. Pour chaque bloc figurent :

• la référence au bloc dans le modèle d'information de l'équipement (par exemple, IEDName/LLN0$BR$Report01) ;
• le type du bloc — bufferisé (B) ou non bufferisé (NB) ;
• l'état : RptEna = ON / OFF ;
• Owner — l'adresse IP du client propriétaire, si le bloc est réservé et que le serveur expose cette information. Owner est décodé depuis l'OCTET STRING « brut » en une forme lisible 192.168.0.42:5001 ; si le bloc est effectivement libre, la cellule affiche un tiret ;
• l'ensemble des déclencheurs actifs (dchg, qchg, dupd, integrity, GI) et des champs optionnels (SeqNum, TimeStamp, ReasonCode, DataSet, DataRef, BufOvfl, EntryID, ConfRev) ;
• la référence au jeu de données utilisé, le temps de bufférisation BufTm et la période d'intégrité IntgPd.

Avec ce seul tableau, à la réception, l'essentiel est déjà visible : quels comptes rendus sont configurés, lesquels d'entre eux quelqu'un a effectivement réservés et s'il reste des blocs qui « flottent » avec un ensemble de déclencheurs vide.

Ensuite — les informations détaillées pour chaque bloc. On y trouve la liste complète des attributs avec leurs descriptions, des sous-sections distinctes avec le décodage des champs binaires TrgOps et OptFlds (un bit par ligne — ce qui est activé et ce qui ne l'est pas), les paramètres temporels avec l'explication de la signification de chaque valeur, et enfin la composition élément par élément du DataSet, répartie sur les colonnes LD / LN / DO / DA / FC. Si un fichier SCD a été choisi à l'étape de la connexion, chaque FCDA reçoit en plus une description textuelle (attribut desc) — extraite directement du SCL via le DOI correspondant. En pratique, c'est inestimable : à la place d'un abstrait « MMXU1.A.phsA.cVal.mag.f », vous voyez immédiatement « Courant de la phase A, entrée n° 1 » — et le sens de chaque compte rendu se saisit en quelques secondes.

Le document est assemblé avec une table des matières et une numérotation automatique des sections.

À quoi cela sert — en pratique

En complément du module de comparaison de configuration présenté précédemment (où les comptes rendus issus d'un fichier SCD sont confrontés à la configuration réelle des IED), ce module traite la seconde moitié des questions SCADA classiques : « comment c'est configuré » est complété par le constat « comment ça fonctionne maintenant ». À la mise en service, cela réduit le temps passé à comprendre « pourquoi les événements n'arrivent pas » ; à la réception, cela donne à la commission un artefact facile à vérifier ; en exploitation, cela permet de relever périodiquement, en quelques minutes, l'image « qui est abonné à quoi » sur l'ensemble du parc d'équipements. Et dans les cas particulièrement désagréables, cela aide à détecter l'essentiel : que le modèle événementiel de l'IEC 61850 est formellement configuré sur le site mais, en pratique, n'est pas utilisé. Une passe, un procès-verbal, une discussion avec le sous-traitant — au lieu de dizaines de courriels et de tableurs improvisés.

Profitez-en ! L'ingénierie IEC 61850 demande parfois un peu de Magie :)