Dans les articles précédents de la série, nous avons montré comment Tekvel Magic confronte la configuration décrite dans un SCD à la configuration réelle des IED et comment, en un clic, il audite l'état courant des blocs de contrôle des comptes rendus via MMS. Aujourd'hui — le troisième cas, qui traite une tâche supplémentaire liée à la transmission de téléinformation : non pas vérifier, mais documenter. Transformer la configuration SCL de la transmission de comptes rendus en un formulaire lisible par un humain — vite, sur l'ensemble du parc d'équipements et sans accéder au réseau du poste.

Pourquoi un formulaire de transmission de téléinformation est-il nécessaire

Lorsque la transmission de télémesures et de télésignalisation par IEC 61850 est configurée — dans des IED de protection, des contrôleurs de tranche, des convertisseurs de mesure — vient tôt ou tard le moment de la remise. Le modèle de données configuré doit être transmis aux spécialistes du niveau supérieur : SCADA, téléconduite, dispatching, etc.

Idéalement, ils reçoivent un fichier SCD — selon la norme IEC 61850‑6, c'est un élément obligatoire de la documentation de projet et as-built, et c'est précisément le SCD qui facilite les travaux d'intégration. Dans la pratique, cependant, il n'y a pas toujours de SCD : on n'a parfois qu'un jeu de fichiers CID séparés, exportés des équipements. Dans les deux cas, un fichier XML « brut » est en soi peu adapté à la remise et à la discussion — il est difficile à lire pour une personne et peu pratique pour expliquer quels comptes rendus sont configurés, avec quels paramètres de transmission et quels signaux ils contiennent.

C'est pourquoi il est d'usage d'accompagner la configuration d'un formulaire de transmission de téléinformation — un document décrivant en clair ce qui est transmis et comment, à l'aide de comptes rendus MMS. Le même document est nécessaire en fin de mise en service : après la configuration des équipements secondaires sur le site, il faut élaborer la documentation as-built de la transmission de téléinformation. Constituer ce formulaire à la main — extraire des dizaines d'équipements les blocs de comptes rendus, leurs déclencheurs, leurs jeux de données et la composition des signaux — est long et propice aux erreurs. Le module de Tekvel Magic présenté ici le fait automatiquement : à partir d'un fichier SCD ou d'un jeu de fichiers CID, il produit un formulaire prêt en une seule passe.

Place dans la série : « comment c'est configuré », « comment ça fonctionne actuellement », « comment livrer cela »

Pour ne pas confondre trois tâches voisines, il est utile de garder en tête la répartition suivante :

  • Cas #1 — conformité : confronte le SCD de projet à la configuration réelle des équipements via MMS et produit un procès-verbal d'écarts.
  • Cas #2 — état : se connecte aux équipements via MMS et montre comment les comptes rendus fonctionnent en ce moment (RptEna, Owner, qui est abonné à quoi).
  • Cas #3 — documentation (celui-ci) : prend la configuration SCL et la transforme en un formulaire lisible et en documentation as-built. Pas de verdict « correspond / ne correspond pas » et pas d'accès au réseau — seulement une description soignée et lisible de comment est configurée la transmission des comptes rendus.

La particularité essentielle du troisième cas — il fonctionne entièrement hors ligne. Aucun accès au réseau du poste n'est nécessaire, aucun équipement actif : les fichiers suffisent. C'est commode au bureau, à l'étape de préparation de la documentation, lors de la remise du projet entre sous-traitants et lors de la constitution du dossier de livraison.

Série de « Cas Magic » de Tekvel Magic : conformité / état / documentation
Fig. 1. Série de « Cas Magic » du logiciel Tekvel Magic : conformité (#1, en ligne via MMS), état (#2, en ligne via MMS) et documentation (#3, hors ligne à partir du SCL) — trois tâches, chacune en une seule passe.

Comment cela fonctionne

Le scénario est aussi court que possible. Vous lancez le module — et dans la première boîte de dialogue, vous choisissez la source de données :

  • un fichier SCL (un SCD comportant plusieurs équipements, ou un CID/ICD isolé), ou
  • un dossier de fichiers CID (.cid / .iid / .icd / .scd / .scl) — chaque fichier est lu séparément, et les équipements de tous les fichiers sont regroupés dans un seul formulaire commun.

On vous propose ensuite de choisir les équipements pour lesquels le document doit être généré (il y a une option « tout sélectionner » — pratique quand le SCD en contient plusieurs dizaines). Le module retrouve, dans tous les équipements sélectionnés, les blocs de contrôle de transmission des comptes rendus — bufferisés (BRCB) et non bufferisés (URCB) —, développe les jeux de données associés, récupère dans le SCL les descriptions textuelles des signaux et assemble un document Word. En parallèle, un document distinct contenant les observations de configuration est généré (voir ci-dessous).

L'algorithme complet se suit plus aisément sous forme de logigramme — du choix de la source aux documents prêts :

flowchart TB
    A["Lancer le module"]
    B{"Source de données ?"}
    F["Un fichier SCL<br/><i>SCD / CID / ICD</i>"]
    G["Dossier de fichiers CID<br/><i>.cid/.iid/.icd/.scd/</i>"]
    C["Liste des IED<br/><i>noms et desc des équipements</i>"]
    S["Sélection des équipements<br/><i>option « tout sélectionner »</i>"]

    A --> B
    B -->|fichier| F --> C
    B -->|dossier| G --> C
    C --> S --> LOOP

    subgraph LOOP["Pour chaque IED sélectionné"]
        direction TB
        R["Recherche des blocs URCB / BRCB"]
        D["Expansion des jeux de données (DataSet)<br/><i>FCDA → LD / LN / DO / DA / FC</i>"]
        T["Extraction des descriptions des signaux<br/><i>desc depuis le SCL : DAI → DOI → LN</i>"]
        R --> D --> T
    end

    LOOP ==> DOC["<b>FORMULAIRE (.docx)</b><br/>vue d'ensemble par équipements •<br/>tableau récapitulatif des blocs •<br/>détail par bloc"]
    LOOP --> CHK["<b>OBSERVATIONS DE CONFIGURATION (.docx)</b><br/>jeux de données, déclencheurs/période,<br/>IP, recommandations de seuils"]
    DOC --> SAVE["Enregistrer les documents sur le disque"]
    CHK --> SAVE

    style A fill:#F3F3F3,stroke:#888
    style B fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style F fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style G fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style C fill:#F3F3F3,stroke:#888
    style S fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style R fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style D fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style T fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style DOC fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style CHK fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style SAVE fill:#FAFAFA,stroke:#AAA
Fig. 2. Algorithme de génération du formulaire de transmission de téléinformation à partir de données SCL (SCD ou jeu de fichiers CID).

Ce que contient le formulaire

Le document est généré avec une table des matières construite automatiquement (le champ se met à jour à l'ouverture dans Word). La structure est conçue pour qu'elle convienne aussi bien à l'ingénieur de mise en service qu'à l'intégrateur du niveau supérieur et au client final (chargé de la réception).

Tableau récapitulatif général par équipements

Si la source contient plusieurs IED, le document s'ouvre par une vue de haut niveau : une ligne par équipement — nom (avec un lien vers la section correspondante), description, adresse IP, nombre de URCB et de BRCB, total de blocs et d'objets de données, plus une ligne de totaux. C'est la « carte » de tout l'ensemble : on voit combien de comptes rendus, et lesquels, sont configurés sur l'ouvrage dans son ensemble, combien de signaux au total sont transmis au niveau supérieur, etc.

Section par équipement

À l'intérieur — trois niveaux de détail :

  • Paramètres de l'équipement : nom, description (issue de l'attribut desc de l'élément IED) et un tableau de tous les points d'accès avec leurs paramètres réseau (point d'accès / sous-réseau / IP / masque / passerelle).
  • Tableau récapitulatif des blocs de contrôle : une ligne par bloc — point d'accès, référence MMS au bloc, type (B/NB), nombre d'instances exposées, déclencheurs actifs (TrgOps) et champs optionnels (OptFlds), référence au jeu de données, nombre d'objets de données, temps de bufférisation (BufTm) et période d'envoi périodique (IntgPd). Les points « problématiques » sont visibles dès cet endroit : les blocs sans jeu de données affecté sont surlignés.
  • Informations détaillées par bloc : sous-sections séparées — attributs principaux, déclencheurs (avec la chaîne binaire TrgOps), champs optionnels (avec la chaîne binaire OptFlds), paramètres temporels avec leurs explications, et enfin la composition élément par élément du jeu de données, répartie sur les colonnes LD / LN / DO / DA / FC.

Il faut mentionner à part les blocs indexés. Selon la norme IEC 61850‑6, un bloc de contrôle peut être exposé sous la forme de plusieurs instances indépendantes (nom01 … nomNN, le nombre étant défini par l'attribut RptEnabled max). Le formulaire en tient compte : pour chaque bloc, le nombre réel d'instances exposées et leurs noms sont indiqués — exactement ce avec quoi le client du niveau supérieur va réellement travailler.

Et le plus utile pour la lisibilité — les descriptions de signaux dans la langue du projet. À chaque élément du jeu de données est associée la description textuelle du SCL (attribut desc). À la place d'un abstrait « MMXU1.A.phsA », on retrouve dans le document l'explication humaine issue du projet — et le sens de chaque compte rendu se saisit en quelques secondes, sans avoir à ouvrir un navigateur de modèle de données. Les descriptions sont reprises strictement « telles quelles » depuis le SCL : sans traduction et sans dictionnaire externe, pour que le document reflète exactement ce qui est dans la configuration.

Observations de configuration — dans un document séparé

Outre le formulaire, le module produit un document distinct Observations de configuration. Il s'agit d'un audit hors ligne léger : on contrôle les jeux de données (non affecté / introuvable dans le nœud logique attendu / vide), la cohérence entre les déclencheurs et les paramètres de transmission, les paramètres de communication (absence d'IP sur un point d'accès portant des blocs, doublons d'IP entre équipements) et les recommandations de seuil (BufTm trop grand, IntgPd trop petit). Chaque observation a un niveau — erreur, avertissement ou recommandation — et figure dans un tableau récapitulatif avec un surlignage par couleur. Pratique pour détecter des défauts typiques dès l'étape de préparation de la documentation, avant la remise.

À quoi cela sert — en pratique

La principale valeur est la rapidité et la lisibilité au moment de la remise. Vous remettez le projet à l'intégrateur SCADA ou au client — et, avec le SCD/CID, vous remettez un formulaire compréhensible qui montre immédiatement quels comptes rendus sont configurés, ce qu'ils contiennent et comment ils sont adressés. Vous clôturez la mise en service — avec le même module de Tekvel Magic, vous obtenez la documentation as-built de transmission de téléinformation, propre et uniforme sur l'ensemble du parc d'équipements. Et comme le module fonctionne hors ligne, il est commode aussi bien au bureau, lors de la préparation du dossier, qu'en site, ou lors de la remise de l'ouvrage entre sous-traitants — là où un accès en direct aux équipements peut faire défaut.

En complément des cas #1 et #2, on obtient le cycle complet : vérifier la conformité du SCD à la réalité, relever l'état courant des comptes rendus via MMS — et constituer la documentation lisible pour la remise. « Comment c'est configuré », « comment ça fonctionne maintenant » et « comment l'expliquer aux autres » — trois tâches, chacune en une seule passe.

Profitez-en ! Et n'oubliez pas : l'ingénierie IEC 61850 demande parfois un peu de Magie :)