Une exécution de Tekvel Magic — et l'équipement choisi dans le SCL prend vie : un serveur MMS est démarré à partir de son modèle de données, et un panneau de commande s'ouvre dans le navigateur. Vous modifiez les valeurs et la qualité des signaux — et le client du niveau supérieur reçoit de vrais comptes rendus dchg/qchg, exactement comme d'un IED réel. Le module fonctionne sans un seul équipement physique sur le banc : un fichier SCL suffit.
Dans les articles précédents de la série, nous avons montré comment Tekvel Magic confronte la configuration d'un SCD à la configuration réelle de l'IED, comment, en un clic, il relève l'état courant des blocs de contrôle des comptes rendus via MMS et comment il transforme une configuration SCL en un formulaire lisible de transmission de téléinformation. Aujourd'hui — le quatrième cas, qui aborde la tâche de l'autre côté de la table. Jusqu'ici, Magic travaillait avec ce qui existe déjà : des fichiers et des équipements en service. Désormais, il devient lui-même l'équipement — pour tester celui qui reçoit ces comptes rendus.
Pourquoi émuler un équipement
La transmission de téléinformation par IEC 61850 comporte toujours deux côtés : l'équipement serveur (un IED de protection, un contrôleur de tranche, un convertisseur de mesure) qui produit les comptes rendus via MMS, et le client du niveau supérieur (un serveur de téléconduite, le SCADA) qui s'abonne à ces comptes rendus et les affiche à l'opérateur. Le premier côté est en général testé de fond en comble sur un projet. Le côté récepteur, en revanche — comment exactement le niveau supérieur reçoit, analyse et affiche les comptes rendus — est bien plus difficile à tester.
La raison est simple : pour tester le client honnêtement, il faut un serveur en fonctionnement qui délivre les bonnes données au bon moment. Et c'est là que les difficultés commencent :
- Certains équipements ne sont pas encore sur le site ou ne sont pas entièrement mis en service. Le paramétrage et la réception du niveau supérieur se déroulent souvent en parallèle de la configuration — voire de la livraison — de certains équipements, et parfois en avance. Il n'y a rien contre quoi tester le niveau supérieur.
- L'équipement est là, mais on ne parvient pas à en tirer l'état requis. Comment faire produire à un terminal réel un
bad-statesur une position de disjoncteur, une qualitéquestionableou un drapeautest— et de surcroît dans une séquence contrôlée ? Sur un équipement en service, c'est soit impossible, soit dangereux (par exemple parce que les tranches de l'ouvrage sont déjà en exploitation). - Il faut reproduire un scénario rare. Perte et rétablissement de la validité, substitution de valeurs — de telles situations ne se créent tout simplement pas sur un ouvrage réel.
Résultat : la réception du niveau supérieur se transforme souvent en observation de ce qui est arrivé par hasard du réseau, au lieu d'un test dirigé. Le module de Tekvel Magic présenté ici comble cette lacune : il démarre un serveur MMS directement à partir d'un fichier SCL et offre un panneau pratique depuis lequel l'ingénieur pilote les valeurs et la qualité des signaux — et observe la réaction du client.
Place dans la série de scénarios de test du SCADA : lire, montrer, documenter — et jouer l'équipement
Pour ne pas confondre des tâches voisines, il est utile de garder en tête la répartition sur toute la série de scénarios de test liés au SCADA :
- 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 : prend la configuration SCL et la transforme en un formulaire lisible de transmission de téléinformation, hors ligne.
- Cas #4 — émulation (celui-ci) : prend la configuration SCL et devient l'équipement qu'elle décrit, générant de vrais comptes rendus pour tester le côté récepteur.
La particularité essentielle du quatrième cas est qu'il est actif. Les trois premiers travaillent avec ce qui existe déjà : ils lisent, comparent, montrent, documentent. Ici, pour la première fois, Magic n'observe pas le trafic mais le crée — il agit comme un serveur IEC 61850 et joue le rôle d'un équipement qui n'est peut-être pas encore présent sur le site, ou qui n'est peut-être pas configuré. Cela déplace le point de mire du test de l'équipement vers le niveau supérieur : non pas « l'IED est-il correctement configuré », mais « celui qui est au-dessus reçoit-il et affiche-t-il correctement les données ».
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 sélectionnez un fichier SCL : ce peut être un CID/ICD isolé avec un seul équipement ou un SCD de poste avec plusieurs dizaines d'IED. S'il y a plusieurs équipements dans le fichier, le module propose d'en choisir un — celui qu'il va « jouer ».
Ensuite, tout se passe automatiquement : le module démarre un serveur MMS à partir du modèle de données de l'équipement sélectionné et ouvre un panneau de commande dans le navigateur. À partir de ce moment, pour tout client du niveau supérieur sur le réseau, le simulateur est indiscernable d'un IED réel : il a le même modèle de données, les mêmes blocs de contrôle des comptes rendus, les mêmes jeux de données et l'adresse issue du SCL.
Tout le cheminement se suit aisément sous forme de logigramme — du choix du fichier au flux de comptes rendus vers le niveau supérieur :
flowchart TB
A["Lancer le module"]
F["Sélectionner un fichier SCL<br/><i>CID / ICD / SCD</i>"]
S["Sélectionner un équipement<br/><i>si le fichier contient plusieurs IED</i>"]
P["Vérifier : y a-t-il des RCB<br/>avec des jeux de données ?"]
B["Démarrer le serveur MMS<br/><i>modèle de l’IED sélectionné</i>"]
C["Client interne<br/><i>readback + scrutation en arrière-plan</i>"]
W["Panneau web<br/><i>s’ouvre dans le navigateur</i>"]
A --> F --> S --> P --> B
B --> C
B --> W
W ==> ACT
subgraph ACT["Actions de l’ingénieur dans le panneau"]
direction TB
V["Modifier les valeurs des signaux"]
Q["Modifier la qualité (validity / test / source)"]
AC["Balayage automatique des valeurs et de la qualité"]
V --> RPT
Q --> RPT
AC --> RPT
RPT["Comptes rendus dchg / qchg via MMS"]
end
ACT ==> EXT["<b>CLIENT DU NIVEAU SUPÉRIEUR</b><br/>SCADA / passerelle / dispatching —<br/>reçoit et affiche les comptes rendus"]
style A fill:#F3F3F3,stroke:#888
style F fill:#E0F2F1,stroke:#26A69A,color:#004D40
style S fill:#EDE7F6,stroke:#7E57C2,color:#311B92
style P fill:#EDE7F6,stroke:#7E57C2,color:#311B92
style B fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
style C fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
style W fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
style V fill:#FFF8E1,stroke:#F9A825,color:#E65100
style Q fill:#FFF8E1,stroke:#F9A825,color:#E65100
style AC fill:#FFF8E1,stroke:#F9A825,color:#E65100
style RPT fill:#E8F5E9,stroke:#43A047,color:#1B5E20
style EXT fill:#E8F5E9,stroke:#43A047,color:#1B5E20
Il convient de souligner à part le traitement d'un SCD de poste. Selon l'IEC 61850-6, un tel fichier décrit des dizaines d'équipements dans un même modèle — et on ne peut pas en démarrer directement un serveur pour un seul IED. Le module s'en charge lui-même : il extrait l'équipement sélectionné dans un fichier temporaire à un seul équipement, en gérant soigneusement les points d'accès (y compris la construction ServerAt, lorsqu'un point référence le serveur d'un autre). L'ingénieur n'a pas à y penser — il suffit d'indiquer le nom de l'équipement.
Un point de plus — Tekvel Magic peut exposer l'équipement simulé à son adresse IP extraite du fichier SCL. C'est important aussi.
Ce que sait faire le panneau de commande
Le panneau s'ouvre dans un navigateur ordinaire et se met à jour en temps réel. À l'intérieur — plusieurs blocs coordonnés.
État des blocs de contrôle des comptes rendus exposés par l'équipement simulé. Un tableau de tous les blocs — bufferisés (BRCB) et non bufferisés (URCB) — avec leur état en direct : RptEna, SqNum, EntryID, Owner, le drapeau d'interrogation générale (GI), l'heure du dernier événement, le jeu de données, les déclencheurs actifs (TrgOps) et les champs optionnels (OptFlds). On voit quel client s'est abonné à quel bloc et ce qui est réellement activé.
Commande des valeurs. Les signaux sont regroupés par jeu de données. Pour chaque objet de données, le panneau choisit lui-même la saisie commode : une liste déroulante pour les signaux discrets (position du disjoncteur — off/on/intermediate/bad-state), un champ numérique pour les mesures. Les grandeurs polyphasées (WYE/DEL/SEQ) sont écrites sur toutes les phases à la fois. Chaque écriture est vérifiée par readback — ce que vous voyez dans le panneau est garanti d'être parti dans le modèle et dans le compte rendu.
Commande de la qualité. Un formulaire distinct pour chaque signal : validity (good / invalid / questionable), les drapeaux test et operatorBlocked, la source process/substituted. Tout changement de qualité génère un compte rendu qchg — exactement ce qu'il faut pour vérifier comment le niveau supérieur affiche l'invalidité et les données de test.
Fil des changements et journal des opérations. Chaque changement de valeur ou de qualité est enregistré dans un fil chronologique — avec la valeur courante, la qualité courante et un horodatage. Un journal distinct des actions de l'opérateur est tenu. Rien n'est perdu, même si les changements arrivent plus vite que la page ne se rafraîchit.
Balayage automatique — test en masse de scénarios en un clic
La commutation manuelle convient aux vérifications ponctuelles, mais lorsqu'il faut faire passer un signal par tous ses états — ou tester d'un coup un jeu de données entier — le balayage automatique vient à la rescousse. Vous cochez les signaux, réglez l'intervalle et le nombre de cycles — et le module parcourt cycliquement toutes les valeurs pertinentes de chaque signal selon son type (CDC) :
- discrets (DPC/DPS) : off → on → intermediate → bad-state ;
- simples (SPC/SPS/ACT) : false → true ;
- énumérés et entiers (INS/ENS) : sur une série de valeurs ;
- mesures (MV/CMV/WYE/DEL/SEQ) : sur une série de valeurs.
Avec l'option « + qualité » activée, après chaque valeur on peut en plus parcourir une séquence d'états de validité : invalid → questionable → good+test → good+operatorBlocked → good+substituted → et retour à good. Ainsi, en une seule exécution, le niveau supérieur reçoit tout l'éventail des combinaisons « valeur × qualité » — idéal pour vérifier l'affichage de tous les états d'un coup. Le balayage peut être mis en pause ou arrêté ; à l'arrêt, la qualité de tous les signaux est soigneusement ramenée à good afin que le modèle ne reste pas dans un état « corrompu ».
À quoi cela sert — en pratique
La principale valeur est de pouvoir tester le niveau supérieur quand cela arrange, et non quand on « a de la chance » avec le trafic d'équipements réels.
Mettre en service le niveau supérieur en avance. Les équipements sont encore en transit, mais le serveur de téléconduite ou le serveur SCADA doit déjà être paramétré et testé. Le simulateur, construit à partir du SCD de projet, joue le futur équipement — le mappage des signaux, les abonnements aux comptes rendus et l'affichage peuvent être mis au point à l'avance.
Le niveau supérieur est déployé alors que les armoires sont déjà en exploitation. Situation fréquente : les armoires de protection et de SCADA d'une tranche sont en service depuis longtemps, tandis que l'extension ou la modernisation du niveau supérieur (un nouveau serveur SCADA, une passerelle, un poste de conduite) est réalisée plus tard. On ne peut plus initier de changements de signaux depuis les équipements en service pour tester la réception au niveau supérieur — le matériel est sous charge, et interférer avec son fonctionnement est inadmissible. Le simulateur lève cette contrainte : il agit comme une « doublure » de l'équipement en service en utilisant la propre configuration SCL de celui-ci, et tous les changements requis — positions, mesures, qualité — sont initiés depuis lui, sans toucher aux armoires réelles en exploitation.
Tester l'affichage de la qualité et des données de test. Comment l'opérateur verra-t-il un signal de qualité invalid ? Le niveau supérieur filtrera-t-il les données portant le drapeau test ? Le simulateur permet de positionner n'importe quelle combinaison de bits de qualité et d'observer la réaction — ce qui est pratiquement irréalisable sur un équipement en service.
Reproduire des scénarios rares et « inconfortables ». Une position intermédiaire de disjoncteur, la perte de validité et sa levée, une série de changements rapides — tout cela se règle depuis le panneau ou s'exécute par le balayage automatique dans une séquence contrôlée.
Formation et démonstration. Le simulateur est un banc visuel pour former le personnel au travail avec les comptes rendus IEC 61850 et pour montrer à quoi ressemble la transmission de téléinformation « en dynamique ».
Associé aux cas précédents, cela constitue un bon ensemble de scénarios de test pour un ingénieur SCADA moderne. Le cas #1 vérifie que l'équipement est configuré conformément au projet ; le cas #2 montre comment les comptes rendus fonctionnent maintenant ; le cas #3 produit une documentation lisible ; et le cas #4 permet de jouer l'équipement et de s'assurer que le niveau supérieur reçoit et affiche tout correctement. « Comment c'est configuré », « comment ça fonctionne maintenant », « comment l'expliquer aux autres » — et, enfin, « comment cela sera reçu à l'autre bout ».
Profitez-en ! Et n'oubliez pas : l'ingénierie IEC 61850 demande parfois un peu de Magie :)