(Rte-Conf) NT-DI-CNER-DCCL-SYS-18-00256-Ind.5.1 Exigences de Paramétrage Et Configuration Des SAMU-SCU-BCU

Date d’approbation :
- Date d’applicabilité :
Date de fin de validité :
- NT DI CNER-DCCL-SYS 18 00256
Indice : 5.1
R#SPACE – Lot 23 Tranche

Exigences de paramétrage et de configuration
79 Pages 25 annexes
Documents annulés : NT-DI-CNER-EM-18-00256-Ind.5

Documents de référence :
Référence fonctionnelle : Extrait du 29/03/2022 de Jira GoPro du projet R#SPACE
Résumé : ce document regroupe les exigences de configuration et de paramétrage applicables aux IED de niveau tranche du
système R#SPACE.
Accessibilité : Filières : Domaine GED :

RTE Métier DI Privé
Domaine professionnel DI
Processus local ING
Centre National Expertise Réseaux

Campus Transfo
2119 avenue Schneider
69330 Jonage www.rte-france.com 05-09-00-COUR
NT-DI-CNER-DCCL-SYS-18-00256 Date d’approbation :
Indice : 5.1 - Page : 2/79

Rédacteur(s) Vérificateur(s) Approbateur(s)

Nom Visa Nom Visa Nom Date/Visa
29/03/2022 29/03/2022 29/03/2022
Frédéric FOUSSERET Volker LEITLOFF Timothée MICHEL

X FF X VL X
Jean-Etienne LEMAIRE Frédéric FOUSSERET Volker LEITLOFF Timothée MICHEL
Signé par : FOUSSERET Frederic Signé par : LEITLOFF Volker Signé par : MICHEL Timothée
29/03/2022
X
Jean-Etienne LEMAIRE
Signé par : LEMAIRE Jean-Etienne
Lieu de conservation (ou...) : DOKI

*Le rédacteur s’assure de la validité du contenu du document et de sa conformité aux règles documentaires.
*Le vérificateur dispose des compétences techniques adaptées pour une vérification du contenu du document.
*L’approbateur est une personne autorisée à la publication du document, engageant l’entité. Il s’assure de la faisabilité des instructions décrites ainsi que de la mise en œuvre des
moyens nécessaires et valide la date de mise en application.
DIFFUSION
Pour action Pour information
Équipe projet R#SPACE
HISTORIQUE
Projet ou
Indice Date Rédacteur Modifications
Pour approbation
1 21/06/18 Pour approbation Équipe lot 8 Initiation du document
2 27/04/19 Pour approbation Frédéric FOUSSERET Revue après round 2 du Dialogue Compétitif des lots SCU, SAMU, BCU
3 23/09/19 Pour approbation Frédéric FOUSSERET Revue après round 4 du Dialogue Compétitif des lots SCU, SAMU, BCU
4 29/04/20 Pour approbation Frédéric FOUSSERET Modifications suite aux retours de la phase de développement. Cf. Ind.4
5 11/01/22 Pour approbation Frédéric FOUSSERET Modifications suite à la consolidation des exigences lot 23
RS-6907 (Configuration du/des serveurs Syslog) : suppression de la ligne
Syslog name et ajout de la ligne SyslogMaxSev
5.1 29/03/22 Pour approbation Frédéric FOUSSERET
RS-7412 (Configuration des COMTRADE) : modification du libellé des
entrées logiques
Copyright RTE. Ce document est la propriété de RTE. Toute communication, reproduction, publication même partielle est interdite sauf
autorisation écrite du Gestionnaire du Réseau de Transport d'Électricité (RTE)
Indice : 5.1 - Page : 3/79

SOMMAIRE
1. Introduction ...................................................................................................................................................4
2. Interface - Configurateur de lot – généralités ...............................................................................................5
3. Interface - Configurateur des lots BCU, SCU, SAMU et IED de tranche ...................................................... 13
4. Informations en entrée ............................................................................................................................... 69
5. Informations en sortie ................................................................................................................................ 78
Indice : 5.1 - Page : 4/79

1. Introduction
Ce document présente l’ensemble des exigences fonctionnelles nécessaires pour les fonctions
d’administration et de supervision applicables aux IED de niveau tranche du système R#SPACE.
Cette version correspond à celle éditée dans le cadre du dialogue compétitif des lots 2 et 3 du projet R#SPACE
(phase 1) complétée par les modifications apportées en phase de développement.
Les exigences correspondent à l’extraction de Jira (outil de gestion des exigences fonctionnelles) du 29 mars
2022.
Remarque
Les exigences fonctionnelles sont identifiées par une clé unique « RS-xxxx » qui est associée à une version
donnée.
Exemple :
Version 1 Version 2
Exigence A RS-xxA1 RS-xxA2
Exigence B RS-xxB1 RS-xxB2
Quand l’exigence B renvoie à l’exigence A, c’est bien la dernière version qui doit être prise en compte.
Ainsi, quand l’exigence RS-xxA2 renvoie à l’exigence RS-xxB1, c’est bien l’exigence RS-xxB2 qui doit être
considérée. La clé RS-xxB1 apparait dans la case « Version précédente » de l’exigence RS-xxB2.
Indice : 5.1 - Page : 5/79

2. Interface - Configurateur de lot – généralités

Priorité Phase 1 - Pilotes Modifiée le 03.12.2021
Identifiant RS-7451 Étiquette RS1_DC2-3_initial
Version 1.1
Version précédente RS-5113
Cette fonction regroupe les exigences générales liées à la configuration et au paramétrage des IEDs et
équipements du système R#SPACE.
01_Définitions-01_IED / équipement RS-5217

Priorité : Phase 1 - Pilotes Modifiée le : 06.12.2021 Étiquette : RS1_DC2-3_initial
Version : 1.0 Version(s) précédente(s) : Version(s) suivante(s) :
"IED" signifie "Intelligent Electronic Devices" ; il s’agit des équipements communicants du système R#SPACE
selon la norme IEC 61850.
Par opposition, on parlera juste d’équipement pour ceux qui ne communiquent pas en IEC61850 (switches par
exemple).
01_Définitions-02_Configurateur d'IED / équipement RS-5218

Priorité : Phase 1 - Pilotes Modifiée le : 06.12.2021 Étiquette : RS1_DC2-3_initial RS1_DC2-
3_modifié_round_2
Le configurateur d’IED / équipement est un outil informatique associé à un IED/équipement précis fourni par
le constructeur de l’IED/équipement. Cet outil permet de réaliser un projet (cf. RS-5315) dans le but de
changer la configuration/paramétrage de l’IED/équipement.
Au sens de la norme IEC 61850, il s'agit de l'ICT (IED Configurator Tool).
Indice : 5.1 - Page : 6/79

01_Définitions-03_ Configuration et Paramétrage RS-7405

Priorité : Phase 1 - Pilotes Modifiée le : 07.01.2022 Étiquette : RS1_DC2-3_modifié_round_4
Version : 1.0 Version(s) précédente(s) : RS-5222 Version(s) suivante(s) :
Cette exigence définit les notions de Configuration, Paramétrage et Consigne au sens du projet R#SPACE (et
non de la norme IEC 61850).
Configuration :
Il s’agit du processus qui consiste, à l’aide d’outils informatiques, à définir les caractéristiques et les valeurs
des données permettant de définir les possibilités fonctionnelles et techniques d’un système. La configuration
permet donc de définir et/ou de décrire le système, ses équipements, ses fonctions et l’ensemble de sa
communication interne.
À l’issue de ce processus sont générés des fichiers qui seront importés dans les configurateurs d’IED (cf. RS-
5218) afin de configurer les équipements constitutifs du système.
Donnée statique :
Information élémentaire, définie par les exigences RTE et/ou la modélisation RTE, figée pour une version
donnée des exigences et / ou de la modélisation.
Les données statiques sont préconfigurées par le fournisseur de l’IED et ne peuvent pas être changées par
RTE.
Selon la norme IEC 61850, il pourra s’agir :
 de DA qui ont pour Fonctional Constraint FC=DC, CF, EX, comme par exemple les DA minVal, maxVal ou
units d’un DO représentant un paramètre ou une donnée de configuration fonctionnel,
 de certaines données du langage SCL et/ou de balises privées RTE.
Donnée de configuration :
Information élémentaire, élaborée par le configurateur, nécessaire à la description de la constitution d’un
système (sans ses paramètres).
Les données de configuration sont persistantes, i.e. sauvegardées lors d'un reboot, et leur changement peut
nécessiter un reboot de l’IED.
Selon la norme IEC 61850, il s’agira :
 en général d’un DA qui a pour Fonctional Constraint FC=SP, SG, ST, DC, ou CF, et dont l’écriture en run-
time sera interdite pour un client (sauf par le process concernant les FC opérationnelles),
 de certaines données du langage SCL et/ou de balises privées RTE.
Paramètre :
Ce terme désigne une donnée dont la modification de la valeur permet d’agir sur le fonctionnement /
comportement d’un système ou équipement sans en changer la configuration. On pourra citer, par exemple,
la mise en ou hors service d’une fonction (sans supprimer la fonction elle-même de la configuration du
système), un seuil ou une temporisation.
Les paramètres sont persistants et leur changement ne nécessite pas de reboot de l’IED.
Selon la norme IEC 61850, il s’agira en général d’un DA qui a pour Fonctional Constraint FC=SP ou SG. Il s’agit
par exemple du DA setVal.
Indice : 5.1 - Page : 7/79

Remarque :
Les notions de paramètres "on line" et "off-line" utilisées dans les anciens paliers RTE (ELECTRE) sont
caduques pour R#SPACE. Les paramètres "off-line" tels qu'ils étaient définis correspondent dorénavant à des
données de configuration et les paramètres "on-line" à des paramètres.
Paramétrage :
Processus de détermination des valeurs des paramètres (n'inclut pas le chargement des paramètres dans les
IED/équipements).
Commande d’état d’une fonction :

Requête de changement destinée à modifier le comportement d'une ou plusieurs fonctions.
Selon la norme IEC 61850, il s’agira en général :
 de la modification de la valeur d’un DO de type ENC au travers les commandes MMS (par exemple DO
Mod pour mettre ES/HS la fonction portée par le LD).
Les commandes d’état d’une fonction sont persistantes, i.e. sauvegardées lors d'un reboot et leur
changement ne nécessite pas de reboot de l’IED.
Valeurs de consignes temps réel :

Requête de changement de valeur d’une variable destinée à modifier le comportement d'une ou plusieurs
fonctions.
 de la modification de la valeur d’un DO de type APC (controllable analogue process value) au travers les
commandes MMS.
Les valeurs de consignes temps réel sont volatiles et leur changement ne nécessite pas de reboot de l’IED.
Commande :
Requête de changement d’état d'un élément du procédé transmise avec possibilité de refus et/ou
d’acquittement.
 de la modification de la valeur d’un DO de type « Control » au travers les commandes MMS (par
exemple : commande d’ouverture du DJ).
Les commandes sont volatiles et leur utilisation ne nécessite pas de reboot de l’IED.
Remarque :
Concernant la substitution, la norme sera respectée :
 Si la substitution concerne un DA 'volatile' (FC=ST et MX), alors la substitution est également 'volatile'.
 Si la substitution concerne un DA non volatile (FC=CF, par exemple) alors la substitution est
"mémorisée'.
Référence : IEC 61850-7-3-Ed2.1, Table B.1 – Functional constraints (FcKind).
Indice : 5.1 - Page : 8/79

01_Définitions-04_Outil de configuration système R#SPACE RS-5223

3_modifié_round_2
Configurateur Système R#SPACE (R#CONF) :

Il s'agit d'un outil logiciel du projet R#SPACE (développé par RTE) qui permet, à partir de la modélisation IEC
61850 et des données issues des outils d'expression du besoin, de réaliser la configuration d'un
système R#SPACE dont les communications sont basées sur la norme IEC 61850. Cet outil est indépendant des
outils associés aux IED/équipements et fournit l'ensemble des données de configuration qu'elles soient
normalisées par la norme IEC 61850 ou non (ex. automates, données IHM, ...).
Au sens de la norme IEC 61850, il s’agit du SCT (System Configurator Tool).
01_Définitions-05_Outil de Paramétrage RS-5232

3_modifié_round_2
Outil de Paramétrage (R#PARAM) :

C'est un outil informatique développé par RTE qui permet l'élaboration des paramètres (RS-5222) pour les
IED/équipements et pour les fonctions qu'ils hébergent.
02_Outils-01_Fourniture d'un configurateur d'IED / équipement RS-5069

3_modifié_round_2
Chaque IED/équipement associé au projet R#SPACE doit être fourni avec son propre configurateur (RS-5218).
Indice : 5.1 - Page : 9/79

02_Outils-02_Rôle du configurateur d'IED / équipement RS-5220

3_modifié_round_2
Le configurateur d’IED/équipement doit permettre de configurer et paramétrer l’intégralité d’un

IED/équipement en modifiant les valeurs associées dans le projet (cf. RS-5315) intégrant l’IED/équipement au
travers des IHMs ergonomiques.
Dans le cadre de R#SPACE, il est demandé :
 que la configuration et le paramétrage puisse se faire complètement par imports des fichiers de
configuration et de paramétrage fournis par RTE comme décrit dans la suite des exigences ;
 sur l'ensemble des éléments présents dans ces fichiers, aucun opérateur n'a besoin d'intervenir
"manuellement" dans le processus de configuration ;
 qu’il soit possible pour l’utilisateur de gérer l'accès aux IHM du configurateur d'IED (cf. RS-5073).
02_Outils-03_Identification/Nommage d’un projet au sein du configurateur d’IED/équipement RS-5316

Le choix du nom du projet (cf. RS-5315) doit être laissé libre à l’utilisateur.
02_Outils-04_Sauvegarde d’un projet du configurateur d’IED/équipements RS-5317

Un projet doit pouvoir s’exporter d’un configurateur d’IED/équipement et être sauvegardé/stocké.
Indice : 5.1 - Page : 10/79

02_Outils-05_Restauration d’un projet dans un configurateur d’IED/équipements RS-5318

Un projet sauvegardé doit pouvoir être réimporté/restauré dans un configurateur d’IED/équipement.
02_Outils-06_Compatibilité descendante des nouvelles versions du configurateur d’IED/équipements RS-5319

Dans le cadre de l’évolution du configurateur d’IED/équipement, une compatibilité descendante doit être
assurée pour pouvoir prendre en charge les projets réalisés dans les versions antérieures.
02_Outils-07_Export du FCPE du configurateur d’IED/équipement RS-5320

Le configurateur d’IED/équipement doit pouvoir générer et exporter à partir d’un projet un FCPE (Fichier de
Configuration et de Paramétrage de l'Equipement, cf. RS-5230) pour un IED/équipement donné.
02_Outils-08_Identification/Nommage du FCPE RS-5321

L’identification d’un fichier FCPE (cf. RS-5230) doit se faire de manière unique. Un nom par défaut constitué,
par exemple, du nom du projet source, du nom de l’IED cible et d'une date/heure (si le FCPE n’est généré que
pour un seul IED) pourra être proposé. Le choix final du nom doit être laissé libre à l’utilisateur.
02_Outils-09_Chargement du fichier FCPE dans les IED/équipements RS-5234

Priorité : Phase 1 - Hors Pilotes Modifiée le : 06.12.2021 Étiquette : RS1_DC2-3_initial
Le fichier FCPE (cf. RS-5230) doit pouvoir être chargé dans l'IED/équipement cible en utilisant le mécanisme
défini par [Rte-Admin].
Remarque
Dans une première phase du projet, RTE accepte que le FCPE n’ait pas de réalité « physique ». C’est-à-dire,
que RTE autorise que la configuration d’un IED/équipement puisse se faire par connexion directe entre le
configurateur et l’équipement/IED. Néanmoins, les autres exigences restent applicables et devront être
transposées à ce mécanisme toléré.
Indice : 5.1 - Page : 11/79

02_Outils-10_Rédemarrage des IED/équipements après chargement du fichier FCPE RS-5235

3_modifié_round_2
Le chargement et la prise en charge d'une nouvelle version d'un fichier FCPE (cf. RS-5230) ne doivent pas
nécessiter le redémarrage de l'IED/équipement si seuls des paramètres y ont été modifiés.
Remarques
 Si les paramètres RTE sont potentiellement différents des paramètres des IED (ce qui a conduit à
l'introduction du mécanisme de transformation décrit ultérieurement), la notion de paramètres RTE
peut aussi être différente de celles des paramètres de l'IED (i.e. un paramètre RTE peut correspondre à
une ou plusieurs données de configuration de l’IED).
 Aussi, le fichier de transformation, décrit dans la suite des exigences, permettra à chaque fournisseur
d'IED de stipuler si la modification du paramètre RTE aura une incidence sur une donnée de
configuration au sens de l'IED/équipement pouvant entraîner le redémarrage de celui-ci ou une
réinitialisation d'une fonction. L'objectif est que les personnes qui réaliseront/prépareront les
configurations soient averties.
03_Droits d'accès-01_Modifications à partir du configurateur d'IED / équipement RS-5073

3_modifié_round_2
Une gestion de droits d’accès et profils utilisateurs doit être intégrée au configurateur d’IED/équipement
selon des mécanismes décrits dans les documents [Rte-Admin] et [Rte-Cyber].
Remarque
La volonté de RTE est de pouvoir restreindre, pour la plupart des utilisateurs, la configuration et la
modification des paramètres à partir du configurateur de l'IED/équipement au seul import des fichiers
(Fichiers de configuration normalisée, de configuration non normalisée et des paramètres). Les modifications
ne sont autorisées qu'à partir des outils de configuration et de paramétrage de RTE qui assurent la gestion des
versions.
03_Droits d'accès-02_Modifications en face avant RS-5071

Priorité : Phase 1 - Pilotes Modifiée le : 03.12.2021 Étiquette : Modifié_Round2_DC2-3
RS1_DC2-3_initial RS1_DC2-
3_modifié_round_4
Il ne doit pas être possible de modifier la configuration et les paramètres en face avant d'un IED ou d'un
équipement si celui-ci en est muni.
Indice : 5.1 - Page : 12/79

03_Droits d'accès-03_Accès à l'IED ou équipement hors canal principal d'administration RS-5120

Priorité : Phase 1 - Pilotes Modifiée le : 03.12.2021 Étiquette : Modifié_Round2_DC2-3
RS1_DC2-3_initial RS1_DC2-
3_modifié_round_4
Il doit être possible d’interdire les modifications de configuration et de paramétrage d'un IED/équipement
hors canal d’administration principal (par exemple, en utilisant un PC de maintenance avec un configurateur
connecté sur un port en face avant ou sur un switch).
04_Traçabilité-01_Suivi des modifications RS-5062

Priorité : Phase 1 - Hors Pilotes Modifiée le : 03.12.2021 Étiquette : RS1_DC2-3_modifié_round_4
Toutes les actions de modifications de la configuration et du paramétrage interne d’un IED, quelles que soient
leurs origines, devront être tracées au niveau de l’IED (système de log compatible avec les exigences
d’administration du système), notamment :
Chargement/modification de la configuration et du paramétrage :

 La date et l’heure d'import,
 La date et l’heure de modification,
 Versions des fichiers utilisés (si possible version du SCD ou fichier de paramètres, le cas échéant à
minima la version du fichier FCPE).
Si le configurateur d’IED offre la possibilité de modifier unitairement les données par lien
« direct » avec l’IED (sans fichier intermédiaire) :
 La/les données modifiées,
 La date et l’heure de modification,
 Les anciennes et nouvelles valeurs.
Remarque
Cette dernière voie de modification n'est néanmoins pas celle préconisée par RTE (autorisée uniquement pour
des profils "expert" cf. RS-5073).
04_Traçabilité-02_Affichage des versions sur les IEDs / équipements RS-5097

S’ils en sont pourvus, les IEDs / équipements devront pouvoir afficher sur leur Face Avant (s'ils en sont
pourvu) a minima les informations suivantes:
 Identification du projet (RS-5315) ;
 Identification du FCPE (RS-5230).
Indice : 5.1 - Page : 13/79

3. Interface - Configurateur des lots BCU, SCU, SAMU et IED de tranche

Priorité Phase 1 - Pilotes Modifiée le 03.12.2021
Identifiant RS-7376 Étiquette RS1_V4.1
Version 2.0
Version précédente RS-5101
Cette fonction regroupe l'ensemble des exigences liées aux formats des fichiers de configuration et de
paramétrage, aux mécanismes d'import et d'export de ces fichiers dans le configurateur d'IED. Elles
complètent et précisent les exigences générales aux configurateurs de lots (Cf. RS-5113).
Équipements concernés :
Les IED concernés par cette fonction sont les IED de niveau tranche à savoir les suivants :
 BCU (Bay Control Unit) ;
 SCU (Switchgear Control Unit) ;
 SAMU (Stand Alone Merging Unit) ;
 MU (Merging Unit) ;
 TAC (TéléACtion) ;
 PDB (Protection Différentielle de Barre) ;
 BPU (Bay Protection Unit) :
- PDIF (Protection DIFférentielle de liaison) ;
- PDIS (Protection de DIStance).
Remarque
Certaines exigences s'appliquent également à d'autres IED du système : Automates, passerelles...
Indice : 5.1 - Page : 14/79

01_Configuration et Paramétrage-01_Généralités-01_Processus de configuration et paramétrage RS-5975

Le processus de configuration et de paramétrage envisagé est décrit dans les exigences qui suivent. Il est
représenté par le schéma suivant :
Indice : 5.1 - Page : 15/79

01_Configuration et Paramétrage-01_Généralités-02_Configuration normalisée, non-normalisée et RS-5233

paramétrage
3_modifié_round_2
L’intégralité de la configuration sera portée par le SCD au travers les éléments définis dans les exigences :
 Valeur d’un DO/DA figée au niveau DAI selon la norme ou le namespace RTE (range d’un setting,
activation d’une fonction…) ;
 Valeur d’un attribut du SCL privé ou non (adresse IP) ;
 Mapping de la communication…
L’outil de paramétrage (cf. RS-5232) génère quant à lui les paramètres (cf. RS-5222) dans un format
« standard » RTE représentant le paramètre ou réglage RTE et porté par un fichier différent du SCD (cf. RS-
5224) à destination des configurateurs d'IED/d’équipements.
Le fichier de transformation portera quant à lui :

 la représentation des paramètres ou réglages métier ;
 leur représentation (DO) selon la norme IEC 61850 à travers la modélisation RTE ainsi que la
transformation associée (équation) dans le cas d’un support du paramètre par l’IED en lieu et place des
paramètres constructeur correspondant ;
 les paramètres ou données de configuration constructeur de l’IED correspondants aux paramètres RTE
et la transformation associée.
L’outil de configuration système (cf. RS-5223) génère deux typologies de données à destination des
configurateurs d'IED/d’équipements :
Configuration normalisée IEC 61850 :

Cf. RS-6040
Configuration privée ou non normalisée IEC 61850 :

Cf. RS-5165
Les fichiers de configuration (SCD) et de paramétrage sont importés par le configurateur de l’IED selon les
mécanismes décrit dans les exigences RS-5179 et RS-5192.
Le fichier de transformation sera mis à disposition par le fournisseur conformément à l’exigence RS-5058.
Indice : 5.1 - Page : 16/79

01_Configuration et Paramétrage-01_Généralités-03_R#QUALIF RS-6146

R#QUALIF est un outil développé par RTE. Il s’agit dans le principe d’une base de données alimentée par les
équipes réalisant les qualifications des systèmes qui permet de :
 s’assurer que les ICD générés pour chaque équipement/IED par leurs fournisseurs respectifs sont
compatibles avec la version de la modélisation RTE depuis laquelle ils ont été générés ;
 suivre les versions applicatives et de modélisation au niveau LD ;
 autoriser l’utilisation d’une fonction d’un IED donné après qualification de celle-ci selon un périmètre
défini ;
 autoriser l’utilisation des combinaisons d’IED avec une version donnée après avoir réalisé des essais
d’intégration.
À ces fins, R#QUALIF stocke :

 les versions des XSD (cf. RS-6144) et des NSD de la norme ;
 les NSD de RTE (cf. RS-6145) ;
 la modélisation RTE au format SCL et ses évolutions.
 les modèles équipements/IED physiques associés à chaque fournisseur ;
 les ICD associés à chaque modèle d’équipement (et définis pour chaque version de modélisation et de
l’applicatif (exigences)).
01_Configuration et Paramétrage-01_Généralités-04_Exigences relatives au langage SCL-01_Généralités RS-6831

Priorité : Phase 1 - Pilotes Modifiée le : 10.09.2021 Étiquette : RS1_V4.1
Les fichiers ICD et SCD doivent respecter le langage SCL défini dans l’IEC 61850-6-Ed2.1.
Le fichier Excel joint en annexe : « RTE requirements for SCL and Tools » définit pour chaque élément /
attribut du langage SCL les exigences de RTE.
Le fichier est composé d’onglets correspondant aux différentes branches du SCL (tIED…).
Les valeurs possibles pour chaque attribut doivent être interprétées comme suit :
 Yes : l’attribut/élément est demandé par RTE et doit donc obligatoirement être présent ;
 Yes because mandatory : l’attribut/élément est demandé car obligatoire selon la norme ;
 Yes, but non-conformance acceptable : l’attribut/élément est souhaité par RTE mais peut malgré tout
ne pas être présent ;
 No : l’attribut/élément n’est pas souhaité par RTE et ne doit pas être présent ;
 No by inheritance : l’attribut/élément ne doit pas être présent car dépendant d’un autre élément dont
la présence n’est pas demandée ;
 No, but non-conformance acceptable : l’attribut/élément n’est pas demandé par RTE mais peut malgré
tout être présent ;
 N/A : Non applicable ;
 See RTE IEC 61850 modeling : renvoi à la modélisation SCL qui impose ou non l’élément ;
 See "R#SPACE – Lists of IEC 61850 Services for BCU- SCU-MU-TAC-PROT": renvoi à la liste des services
qui impose ou non l’élément.
Indice : 5.1 - Page : 17/79

La colonne A, définit si l’attribut doit être présent dans l’ICD.

La colonne B définit la valeur de l’attribut ou élément attendue par RTE dans le cas d’un élément requis ;
La colonne C définit les tests qui seront réalisés par l’outil R#QUALIF sur l’ICD ;
La colonne D définit l’utilisation de l’attribut/élément pour les outils RTE ;
La colonne E définit si l’attribut/élément sera présent dans le SCD ;
La colonne F définit la valeur de l’attribut dans le SCD ;
La colonne G définit l’origine de la valeur dans le SCD.
01_Configuration et Paramétrage-01_Généralités-04_Exigences relatives au langage SCL-02_Cas particulier de RS-5983

valKind
L’utilisation de l’attribut valKind tel que défini dans la norme IEC 61850-6 (§9.5.4) est demandée pour
R#SPACE ainsi que la possibilité de changer la valeur de valKind (de Set à RO) dans le cas des DAI.
Il doit être possible d'utiliser valKind selon la norme au niveau DataType ou DAI.
La différence entre le niveau DataType ou DAI est la possibilité de changer la valeur ou non par un autre outil.
En effet, au niveau DataType, celle-ci est immuable.
Au niveau DataType :
 La valeur « RO » signifiera que le DA ne peut pas être modifié en run-time. Il s’applique essentiellement
aux données statiques (cf. RS-5222) et données de configuration. Il s'agit par exemple des DA ctlModel,
minVal, units, maxVal ;
 La valeur « Conf » sera utilisée lors de l'export des fichiers de modélisation au format SCL pour les DA
représentant un paramètre (cf. RS-5222) qui n'ont pas vocation à être exposés en run-time dans la
première phase du projet.
Remarque : les valeurs des bornes min / max et autres DA associés au paramètres (unités…) et données de
configurations seront définies dans la partie DAI des fichiers de modélisation RTE. Ces valeurs seront à
respecter.
Dans le cas d'une non-exposition effective des paramètres, ceux-ci ne devront pas apparaître dans l’ICD. Dans
le cas où les données sont exposées, ce qui est acceptée par RTE, l'attribut valKind devra être enlevé des
DataTypes pour être mis au niveau DAI avec pour valeur « Set » pour le DA portant la valeur du paramètre et
conservé au niveau DataTypes mais avec la valeur « RO » pour les autres DA associés (borne maximale par
exemple).
Au niveau DAI :
 La valeur valKind = « RO » signifiera que la valeur du DA ne peut pas être changée en run-time ;
 La valeur valKind = « Set » signifiera au contraire que la valeur peut être changée en run-time;
 Il doit aussi être possible de pouvoir changer la valeur de valKind au niveau du SCT (de Set à RO pour les
functional constraints CF, DC et SP). Ceci concerne essentiellement les données de configuration (cf. RS-
5222).
Indice : 5.1 - Page : 18/79

L’ICT devra donc être compatible avec le « statement » I211 Support changed (reduced capability) valKind
(e.g.from Set to RO or to Conf) (Table 46) du SCL Implementation Conformance Statement (SICS) et l’IED devra
supporter le service ValueHandling dont l’attribut setToRo devra être à “true” dans l’ICD.
RTE ne prévoit pas d’utiliser la valeur « Spec » de valKind (ni au niveau DataType, ni au niveau DAI).
La valeur initiale de valKind pour chaque DA concerné est précisée par RTE dans le fichier de modélisation ;
celle-ci devra être respectée par le fournisseur d’IED et devra donc transparaître comme telle dans l’ICD (sauf
pour le cas des DA de settings comme décris précédemment).
01_Configuration et Paramétrage-01_Généralités-04_Exigences relatives au langage SCL-03_Cas particulier de RS-6692

valImport
L’utilisation de l’attribut valImport tel que défini dans la norme est demandée pour R#SPACE.
Une valeur à « false » de valImport interdit aux autres outils lors du processus d’ingénierie de modifier la
valeur du DA.
RTE précisera la valeur souhaitée pour chaque DA concerné au niveau DAI ou DataType dans le fichier de
modélisation ; celle-ci devra être respecté par le fournisseur d’IED et devra transparaître comme telle dans
l’ICD.
Dans le cas particulier des DA associés aux paramètres relatés à l’exigence RS-5983 (données identifiées par
« valKind = conf » dans le fichier de modélisation), si les données sont exposées par l'IED, il est demandé
d'ajouter au niveau des DAI valImport avec comme valeur « true » pour le DA qui porte la valeur et au niveau
DataType avec comme valeur « false » pour les DA définissant par exemple les bornes min, max…
Remarque
valImport sera toujours associé à valKind. D’une manière général et à des fins de visibilité, si valKind est défini
au niveau DatatypeTemplage, valImport sera aussi défini à ce niveau (hors cas des paramètres avec valkind =
« conf » où il n’y a pas de valImport) et respectivement au niveau DAI.
Indice : 5.1 - Page : 19/79

01_Configuration et Paramétrage-01_Généralités-04_Exigences relatives au langage SCL-04_Cas particulier RS-6894

des initialisations des variables
Deux modes d’initialisation des variables sont proposés par la norme :

1. Au travers les DataTypes,
2. Au travers les Data Attribute Initialisation (DAI).
Il doit être possible d'utiliser les deux méthodes.
1. Les données dont l’initialisation sera demandée dans les DataTypes seront définies dans le fichier de
modélisation au format SCL.
2. Les DAI seront utilisés pour indiquer les valeurs par défaut de certaines données de configuration ou
données du process basées sur un attribut opérationnel (SP, SG, ST) et certaines données de
configuration de type CF ou DC, conformément à la norme IEC 61850.
Ces valeurs sont à importer nativement ou via le médiateur.
L’initialisation des données pourra être associée à l’utilisation des attributs valKind et valImport
conformément aux exigences RS-5983 et RS-6692 pour par exemple, interdire la mise "on" en run-time d'une
fonction désactivée en configuration (cf. RS-6191).
Concernant l'initialisation des données les cas suivants sont à considérer :

 Cas d’une donnée volatile (cf. RS-5222) : si une valeur par défaut a été définie dans le fichier SCD, celle-
ci s’applique à la donnée après chargement du SCD mais aussi après chaque reboot de l’IED ; Si aucune
valeur par défaut n’a été définie, la donnée est réinitialisé à la valeur par défaut définie par le
constructeur.
 Cas d’une donnée permanente : si une valeur par défaut a été définie dans le fichier SCD, celle-ci
s’applique à la donnée après chargement du SCD uniquement. Après reboot de l’IED, la valeur de la
donnée d’avant le reboot est réutilisée. Il peut s’agir de celle du SCD si la valeur n’a pas été changée en
run-time. Si aucune valeur par défaut n’a été définie, après chargement du SCD la donnée est initialisée
à la valeur par défaut définie par le constructeur.
 Cas des données du process : les règles précédentes s’appliquent, cependant la valeur de la donnée
peut changer après recalcule de la part de l’IED de la nouvelle valeur.
Indice : 5.1 - Page : 20/79

01_Configuration et Paramétrage-01_Généralités-05_Rôle et exigences spécifiques à l'ICD RS-7410

Chaque fournisseur d'IED devra, après adaptation de l'IED aux exigences RTE et à la modélisation, fournir l'ICD
correspondant à un type d’IED donné. Celui-ci devra être unique.
L'ICD portera :
 les capacités de l'IED au sens de la norme IEC 61850,
 les sections privées du constructeur de l'IED (à limiter autant que possible),
 les sections privées propres à R#SPACE et imposées par RTE (cf. le XSD RTE défini dans l’exigence),
 des éléments de l’espace de nom spécifique à RTE (cf. le NSD RTE défini dans l’exigence RS-6145).
Cet ICD devra respecter les exigences idoines. Sa conformité à la norme et aux exigences RTE sera vérifiée par
RTE après réception de celui-ci en phase de développement puis en amont des qualifications de l'IED.
Le fichier ICD sera intégré au processus de configuration R#SPACE (par l’intermédiaire de l’outil R#QUALIF cf.
RS-5975) après la phase de qualification de l’IED.
L'ICD sert de base à la création du SCD qui sera fourni au configurateur spécifique de l'IED.
Pour chaque type d’IED, une évolution côté fournisseur (Firmware, PLC, Hardware,…) ou côté RTE (Version
applicative d'une fonction, Version de la modélisation au niveau d’un LD,…) nécessitera la génération d’un
nouvel ICD.
Indice : 5.1 - Page : 21/79

01_Configuration et Paramétrage-01_Généralités-06_Déclinaison de la modélisation-01_Instanciation des LD RS-7406

Pour chaque type d’IED (selon exigence, la modélisation SCL définira l’enveloppe maximale des LD à
instancier.
Le fournisseur devra proposer un ICD en adéquation avec la modélisation en y intégrant l’intégralité des LD
définie dans le fichier de modélisation SCL et en respectant les principes suivants:
 Il doit être possible de pouvoir changer le nom des LD au niveau du SCT via le service ConfLDName qui
doit être supporté conformément à l’exigence.
 Une fonction portée par un LD doit pouvoir être activée / désactivée. Une fonction inactive peut être
considérée comme une fonction absente de l’IED bien qu’implémentée et réciproquement.
 Certaines fonctions portées par un LD peuvent être mises en service ou hors service conformément à la
modélisation.
 La modélisation détermine si une fonction peut être mise en test ou non.
 Toutes ces notions passent par la modification du DO Mod du LLN0 du LD.
 La distinction entre ces notions sera réalisée par le respect de la table de vérité suivante et l’utilisation
du nouveau DO : LSET.SetMod dont les valeurs possibles seront « on » et « off » et dont la mise off sera
prioritaire sur les valeurs du DO LLN0.Mod dans la détermination de l’état général (Beh) du LD :
- Si LD/LLN0.SetMod=on, LLN0.Beh = LD/LLN0.Mod
- Si LD/LLN0.SetMod=off, LLN0.Beh = off
Indice : 5.1 - Page : 22/79

01_Configuration et Paramétrage-01_Généralités-06_Déclinaison de la modélisation-02_Instanciation des LN RS-7407

Afin de limiter le nombre d’ICD « template » fournis pour un IED donné (cf. RS-5977), il est demandé
d’instancier, pour chaque LD instancié selon l’exigence RS-6191, l’intégralité des LN donnée par la
modélisation en respectant strictement les valeurs des attributs lnClass et lnInst.
La plupart des LN seront toujours activés.
Une fonction / sous-fonction peut être portée par un LN, elle peut donc être activée / désactivée. Une
fonction / sous fonction inactive peut être considérée comme absente de l’IED bien qu’implémentée et
réciproquement.
Certaines fonctions / sous-fonctions portées par un LN peuvent être mises en service ou hors service
conformément à la modélisation.
Toutes ces notions passent par la modification du DO Mod du LN.
La table de vérité suivante est à respecter :
01_Configuration et Paramétrage-01_Généralités-06_Déclinaison de la modélisation-03_Instanciation des DO RS-6895

Pour chaque LN instancié conformément à l’exigence RS-5984, l’intégralité des DO donnée par la modélisation
au format SCL doit être instanciée, à l'exception :
 du cas particulier des DO de paramétrage tel que précisé dans l’exigence RS-5983,
 des DO des « boundary LN » LPDI, LPDO, LPAI, LPLE dont les DO instanciés seront dépendants de l’IED.
Les DO non utilisés ne seront pas définis dans les DataSets et la communication réalisée au niveau du SCD par
RTE.
Indice : 5.1 - Page : 23/79

01_Configuration et Paramétrage-01_Généralités-06_Déclinaison de la modélisation-04_Instanciation des DA RS-6192

Pour chaque DO instancié, l’intégralité des DA donnée par la modélisation au format SCL doit être instanciée.
Les DA non utilisés ne seront pas définis dans les DataSets et la communication réalisée au niveau du SCD par
RTE.
01_Configuration et Paramétrage-01_Généralités-06_Déclinaison de la modélisation-05_Instanciation des RS-7400

ENUM
Les ENUM Type définis dans la modélisation SCL seront issus de la norme ou des NSD RTE. Ceux-ci seront
réduits aux seuls éléments nécessaires à RTE lorsque cet ENUM est liée à de la « logique pure », c’est-à-dire
dont seule une customisation de l’applicatif et du modèle de données permet de répondre à la modélisation
RTE (cas du CtlModelKind par exemple) et ne s’applique pas aux capacités matérielles intrinsèques d’un IED
(Exemple : LedOnColKind défini dans les NSD RTE qui permet de choisir la couleur des LED, et donc lié aux
capacités de l’équipement).
Dans le cas d’un ENUM liée à de la « logique pure », la constitution des ENUM Type devra être respectée à
l'identique au niveau de l’ICD et des « DataTypeTemplates ».
Concernant les ENUM potentiellement liés aux capacités de l’IED, le fichier de modélisation comportera
l’enveloppe maximale et celle-ci sera à adapter dans l’IED et transparaître dans l’ICD selon les capacités
réelles des IED.
01_Configuration et Paramétrage-01_Généralités-06_Déclinaison de la modélisation-07_versions RS-7419

Conformément à l’exigence RS-5977, un nouvel ICD est à produire dès qu’il y a pour chaque type d’IED, une
évolution côté fournisseur (Firmware, PLC, Hardware,…) ou côté RTE (Version applicative d'une fonction,
Version de la modélisation au niveau d’un LD...).
Il est donc nécessaire que ces informations soient identifiées dans le corps du fichier SCD mais aussi pour
certaines exposées par le serveur IEC 61850.
Concernant le type d’IED

L’attribut « type » du langage SCL au niveau de la section IED est laissé à l’appréciation du fournisseur. Le DA
LDSUIED/LPHD0.PhyNam.model est laissé à l’appréciation du fournisseur.
RTE demande que le type d’IED selon l’exigence RS-5101 soit reporté dans la balise privée « COMPAS-
IEDType ».
Concernant le nom du fournisseur

Celui-ci doit être porté par le DA LDSUIED/LPHD0.PhyNam.vendor mais aussi par l’attribut « manufacturer »
du langage SCL au niveau de la section IED. Sa valeur est laissée à l’appréciation du fournisseur.
Indice : 5.1 - Page : 24/79

Concernant la version firmware

Celle-ci doit être portée par le DA LDSUIED/LPHD0.PhyNam.swRev.
RTE demande, en attendant le support des « boundary LN » (LPDI...), que la version du firmware soit globale à
l’IED en intégrant les versions logicielles des éventuelles cartes dans la détermination de la version.
Aussi, RTE demande qu’une modification de la logique programmable de l’IED afin d’adapter celui-ci à ses
exigences n’ait pas d’influence sur swRev. Sa valeur est laissée à l’appréciation du fournisseur selon la
contrainte sus-citée.
Concernant la version hardware

Celle-ci doit être portée par le DA LDSUIED/LPHD0.PhyNam.hwRev.
RTE demande, en attendant le support des « boundary LN » (LPDI...), que la version du hardware soit globale à
l’IED en intégrant les versions des éventuelles cartes dans la détermination de la version.
Concernant la version applicative de l'adaptation de l’IED aux spécifications RTE au niveau de

chaque LD
Il s’agit par exemple de la modification de la logique programmable afin d’adapter l’IED aux exigences RTE.
Il est demandé d’exposer dans le DA du LD suivant : LD/LLN0.NamPlt.swRev la chaîne composée de la version
des exigences applicatives qui sera communiquée par RTE (sur trois nombres X.X.X (majeur, mineur et
correctif) pour chaque fonction ainsi que de l’éventuelle déclinaison fournisseur laissée à l’appréciation du
fournisseur.
Les deux versions seront séparées par un point «.».
Exemple
La valeur du DA sera 2.1.1.1.0 pour une version des exigences RTE 2.1.1, et 1.0 pour l’implémentation
fournisseur.
Une balise privée « RTE-LD-ChangeLog » est à compléter par le fournisseur à chaque évolution de l’applicatif
afin de détailler les évolutions apportées.
Concernant la version de la configuration de base de l’IED

La détermination de la valeur de l’attribut SCL « configVersion » est laissée à l’appréciation du fournisseur.
Concernant le numéro de série de l'IED

Celui-ci doit être porté par le DA LDSUIED/LPHD0.PhyNam.serNum. La détermination de sa valeur est laissée
à l’appréciation du fournisseur.
Concernant la version de la modélisation au niveau d’un LD

Celle-ci correspond au numéro de version de la modélisation d’un LD.
Le numéro de la version doit être exposé dans le DA du LD correspondant : LD/LLN0.NamPlt.configRev. La
valeur est celle donnée par RTE et pour lequel le mapping de données a été réalisé.
Une balise privée « RTE-LD-Model-ChangeLog » sera complétée par RTE à chaque évolution de la modélisation
afin de détailler les évolutions apportées aux LD.
Indice : 5.1 - Page : 25/79

Concernant l’identification des fichiers SCL (ICD, SCD)

Le nom des fichiers SCL ne peut pas être utilisé comme référence (ceux-ci peuvent être aisément modifiés et
ne pourront par exemple pas intervenir dans le chiffrement des fichiers le cas échéant). Aussi, il est demandé
d’utiliser les attributs SCL dédiés (id, version et revision de la branche Header) au niveau de l’ICD et lors de
l’import du SCD.
RTE demande que l’attribut « id » ne soit pas nul.
La clé composée (id, version et revision) devra toujours être unique même si certains éléments peuvent être
nuls (au niveau de l’ICD) et RTE garantira aussi son unicité au niveau du SCD.
Concernant la traçabilité des fichiers ICD

Les évolutions d’un ICD devront être tracées au niveau de la balise « History » de la branche « Header ». En
plus de l’attribut « when » obligatoire, RTE souhaite à minima le remplissage de l’attribut « what ».
L'attribut confRev au niveau des GSEControl et ReportControl sera incrémenté par le SCT conformément à la
norme lors de la création/modification d'un ControlBlock.
Le DA LLN0.NamPlt.valRev sera aussi incrémenté par le SCT lors de la création/modification de la
configuration d'un LD.
Le paramétrage n'est pas porté par le fichier SCD mais par le fichier de paramétrage et le mécanisme de
transformation. Il est donc demandé lors de l’import des paramètres de mettre à jour la valeur des DA
LLN0.NamPlt.paramRev pour chaque LD de l'IED avec la valeur de l'attribut VersionFichier du fichier de
paramètre RTE.
Lorsque les valeurs des versions sont portées par des DA, celles-ci doivent transparaître au niveau DAI (avec
valKind=RO) dans l’ICD.
Cas particulier du LPHD

Aucune hiérarchie n’a été actuellement définie entre les LD d’un IED, de ce fait tous les LD sont considérés
comme « root », nous devons donc selon le fascicule 61850-7-1 paragraphe 8.2.5 utiliser le LN LPHD pour
chaque LD.
Le LPHD du LDSUIED restera celui utilisé dans les datasets. Concernant la constitution des LPHD, celle du
LDSUIED sera différente de ceux des autres LD car constituée de l’ensemble des DA exprimés dans la
modélisation. Les LPHD des autres LD, seront réduits aux DO mandatory (Proxy, NamPlt, PhyNam, PhyHealth
et MaxDl).
Indice : 5.1 - Page : 26/79

01_Configuration et Paramétrage-01_Généralités-06_Déclinaison de la modélisation-08_Cas particulier de RS-5982

ProtNs
Priorité : Phase 1 - Pilotes Modifiée le : 07.01.2022 Étiquette :
La description des « DataTypeTemplates » dans la modélisation SCL sera la plus exhaustive possible et
correspondra au plus juste au besoin RTE. C’est pourquoi RTE exprimera aussi les DA type appartenant à des
structures propres aux services de communication (SCSM). Ces DA type seront dès lors exprimés avec une
balise « ProtNs », conformément à l’IEC 61850-6-Ed2.1.
Ces données devront être reprises dans l’ICD (au niveau d’une balise « ProtNs ») et devront impérativement
être accessibles (exposées en communication). Il s’agit par exemple de la structure « Oper » pour
un « ctrlVal ».
01_Configuration et Paramétrage-01_Généralités-07_Exigences RTE relative aux Services RS-5980

Les services que doivent supporter les ICT sont définis dans l’exigence RS-5979.
Les services que doivent supporter les IED sont définis dans l’exigence RS-4664.
01_Configuration et Paramétrage-01_Généralités-08_Exigences RTE relative au SICS RS-5979

L’ICT doit respecter les exigences de la norme IEC 61850 (IEC 61850-6-Ed2.1, Cf. Table G.1 – IED configurator
conformance statement) concernant les fonctions à supporter.
Aux exigences normatives sur le caractère optionnel ou non d’une fonction de l’ICT, le document Excel joint
en annexe (RSPACE – RTE requirements for SCL and Tools) liste les fonctions qu’un IED doit supporter dans le
cadre de R#SPACE.
La colonne E de l’onglet ICT SICS précise les exigences de RTE et les valeurs des cellules doivent être comprises
ainsi :
 Les fonctions obligatoires (M), demandées de fait par RTE (colonne E à « yes ») ;
 Les fonctions optionnelles (O ou conditionnées C1, C2…) sont soit :
- demandées par RTE (colonne E à « yes ») ;
- non demandées par RTE mais pouvant être néanmoins intégrées (colonne E à « No but
acceptable») ;
 Les fonctions « AtLeastOne (1) » sont au choix du fournisseur et RTE demande qu’une au moins soit
présente conformément à la norme, c’est pourquoi la colonne E aura pour valeur « yes but
acceptable».
Indice : 5.1 - Page : 27/79

01_Configuration et Paramétrage-01_Généralités-09_Rôle et exigences spécifiques au SCD RS-5976

Comme décrit dans l’exigence RS-5233, l’intégralité de la configuration sera portée par le SCD au travers les
éléments définis dans les exigences :
 Valeur d’un DO/DA figée au niveau DAI selon la norme ou le namespace RTE (i.e. range d’un setting,
activation d’une fonction…) ;
 Valeur d’un attribut du SCL privé ou non (i.e. adresse IP) ;
 Mapping de la communication inter et intra-IED.
Il sera donc utilisé pour:
 configurer la partie communication (conformément à la norme) ainsi que les autres éléments prévus
par la norme ;
 configurer les éléments souhaités par RTE mais non normalisés : I/O, LED, communication intra-
IED,…importés au travers le médiateur (RS-5059) ;
 configurer les éléments tels que l’activation/désactivation d’une fonction, les ranges de settings… au
travers les DO/DA correspondants au niveau DOI/DAI.
Le configurateur d’IED doit supporter ses éléments.
Le SCD ne sera pas utilisé pour :
 la modification de services (activation, timeout) conformément à la norme ;
 le paramétrage ; en effet, les paramètres fonctionnels qui doivent pouvoir être modifiés seront groupés
dans un fichier séparé du SCD et à importer via le médiateur et le fichier de transformation. Cela
concerne les paramètres des LD (i.e. réglages) et éventuellement d’autres paramètres à définir.
Indice : 5.1 - Page : 28/79

02_ConfigurationIEC61850-01_Mécanisme d'import et de chargement de la configuration normalisée RS-5179

3_modifié_round_4
L'ingénierie système sera réalisée dans le configurateur Système R#SPACE.

À l’issue de ce processus sera généré le fichier SCD (cf. RS-5233) qui devra être importé.
L'ensemble des données normalisées doit être importé nativement par le configurateur d'IED.
Remarque :
Il se peut que les interprétations ou supports de certaines données de la norme ne soient pas supportées par
l'IED et son configurateur. À des fins de compatibilité et à défaut d'interopérabilité, ces données doivent être
a minima importables par le mécanisme de médiation applicable à la configuration privée (cf. RS-5192). Cela
doit néanmoins rester marginal.
Indice : 5.1 - Page : 29/79

02_ConfigurationIEC61850-02_Import et contrôle de cohérence des fichiers de configuration RS-5140

3_modifié_round_2
L’import est l’étape qui précède l’intégration des données de configuration au projet dans le configurateur
d’IED (ICT).
Les nouvelles valeurs du fichier ne sont prises en compte dans le projet qu’à l’issue de la validation de
l’import.
Avant ou après import dans le configurateur d’IED d'un fichier de configuration normalisée, un contrôle de
cohérence devra être automatiquement effectué.
Les critères suivants devront à minima être utilisés :
 conformité du fichier fourni par rapport à la norme IEC 61850 (données au format NSD et XSD (cf. RS-
6144)) ;
 conformité du fichier par rapport aux données RTE (selon la modélisation au format SCL) ;
 conformité des des « DataTypesTemplates » ;
 conformité à l’ICD ;
 conformité des instanciations des LD par rapport aux ressources de l’IED (cf. RS-6191) ;
 conformité de la configuration de la communication au travers de l’utilisation des « Input/ExtRef » et
« InRef » et selon les restrictions de l’IED ;
 conformité de la variante BAP et de la valeur par défaut implémentées par rapport au fichier de
configuration si la configuration de ceux-ci n’est pas implémentée ;
 le contrôle de versions (la version à importer doit préférentiellement être supérieure à la dernière
version importée).
Si des incohérences pouvant nuire à l’intégrité du projet sont décelées lors de ces contrôles (la classification
des incohérences est laissée à l’appréciation du constructeur), l’import n’est pas validé et l’utilisateur doit en
être averti explicitement.
Pour les autres incohérences sans influence sur l’intégrité du projet, un rapport de cohérence devra être
présenté à l’utilisateur à qui la validation de l’import sera demandée. La classification des incohérences devra
être soumise à RTE pour approbation.
Ce rapport doit pouvoir être exporté ou copié dans un fichier.
Si aucune incohérence n’est détectée, le fichier importé est automatiquement validé.
Si le contrôle de cohérence a été réalisé avant import, la validation autorise l’import et le passage en phase
d’intégration au projet.
Si le contrôle de cohérence a été réalisé après import, la validation autorise le passage en phase de
chargement.
Un import non validé n’est pas réalisé si le contrôle a eu lieu avant, ou supprimé si le contrôle de cohérence a
eu lieu après.
Un fichier importé non validé empêche le passage à l’étape d’intégration des données de configuration au
projet.
Indice : 5.1 - Page : 30/79

02_ConfigurationIEC61850-03_Intégration-01_Affichage des modifications de configuration normalisée RS-5196

L’intégration des données au projet succède à un import validé des données de configuration privées et
normalisées. Elle consiste à appliquer les nouvelles valeurs importées dans le configurateur d’IED au projet.
Avant la réalisation de cette étape, un affichage des actions qui seront effectuées sur le projet en cours doit
être réalisé :
 Suppression(s) ;
 Modification(s) ;
 Ajout(s).
Un rapport des modifications est alors présenté à l'utilisateur qui valide ou pas la poursuite des opérations.
Le format d’affichage sera proposé par le fournisseur et validé par RTE en phase de réalisation.
02_ConfigurationIEC61850-03_Intégration-02_Modification des valeurs du projet en cours RS-5194

3_modifié_round_2
Suite à la validation par l’utilisateur de l’intégration des données du fichier de configuration normalisées et
non normalisées dans le configurateur d’IED, les valeurs des données de configuration correspondantes sont
modifiées.
02_ConfigurationIEC61850-03_Intégration-03_Echec de la mise à jour du projet en cours RS-5197

En cas d'échec d’intégration de la configuration normalisée dans le projet en cours, celui-ci doit revenir dans
son état antérieur.
Un rapport sur l'erreur rencontrée doit être affiché. Ce rapport doit pouvoir être exporté ou copié dans un
fichier.
02_ConfigurationIEC61850-04_Export de la configuration initiale de l'IED RS-5114

Priorité : Phase 1 - Pilotes Modifiée le : 10.09.2021 Étiquette : Configuration IEC61850
RS1_DC2-3_initial XML
Le configurateur d'IED doit pouvoir exporter un fichier ICD générique correspondant à une configuration
initiale pour chaque type d'IED géré par celui-ci.
Indice : 5.1 - Page : 31/79

02_ConfigurationIEC61850-05_Configuration des échanges-01_Communs RS-6693

Les mécanismes standards de la norme de déclaration de la communication sont à respecter et à maintenir.

Comme définit dans l'IEC 61850-7-2 :
 L’« ObjectReference » d’un « ControlBlock » est définit par : LDname/LLN0.CBname
 Les « ControlBlockName » et « DataSetName » doivent respecter les règles suivantes :
- Le nombre de caractères doit être inférieur ou égal à 32 ;
- Le nom doit débuter par une lettre.
 Le « DataSetName » est unique au sein d’un « LN » ;
 Le « ControlBlockName » est unique au sein d’un « LD » ;
Pour le DO « InRef », les valeurs des DA seront définis comme suit :

 Le « setSrcRef » est définit par le « ObjectReference » du DO (ex : LDname/XCBR0.Pos) ;
 Le « setSrcCB » est définit par le « ObjectReference » du « ControlBlock » (ex :
LDname/LLN0.RTE_LLN0_CB_GSE_EXT) ;
 Le « setTstRef » est définit par le « ObjectReference » du DO (ex : LDname/XCBR0.Pos) ;
 Le « setTstCB » est définit par le « ObjectReference » du « ControlBlock » (ex :
LDname/LLN0.RTE_LLN0_CB_GSE_EXT).
Pour le « Input/ExtRef », le « srcCBName » est définit par le « ObjectReference » du « ControlBlock » (ex :

LDname/LLN0.RTE_LLN0_CB_GSE_EXT).
Indice : 5.1 - Page : 32/79

02_ConfigurationIEC61850-05_Configuration des échanges-02_Communication statique RS-7408

Pour la configuration des échanges statiques (GOOSE et SV) entre LD d'IED différents et ne nécessitant pas
de commutation dynamique vers des flux de test, le processus élémentaire suivant (basé sur le « later
binding » et l'utilisation d’ « Input/ExtRef ») devra être respecté :
1. Au niveau du SCL
RTE fournit la modélisation au format SCL avec la déclaration de chaque entrée applicative d’un LD,
nécessitant une communication statique, sous la forme d’« Input/ExtRef » au niveau LLN0 du LD, avec
l’attribut « desc » prédéfini avec le nom du signal applicatif correspondant à celui des exigences fonctionnelles
correspondantes :
La syntaxe utilisée est : STAT_NOMLD_NOM DU SIGNAL_PLAGE_TYPE_INDICE_DAop_NUMFLUX avec :

 STAT : préfixe obligatoire signifiant le caractère statique du signal au sens de la configuration;
 NOMLD : chaîne de caractères obligatoire représentant le nom du LD (LD.inst) d'appartenance du
« Input/ExtRef » selon la modélisation RTE ;
 NOM DU SIGNAL : chaîne de caractères obligatoire représentant le nom du signal applicatif selon les
exigences fonctionnelles correspondantes ;
 PLAGE : entier permettant de différencier les instanciations d'un signal applicatif en
termes d'échanges, par défaut figé à 1 si une seule instance ;
 TYPE : chaîne de caractères obligatoire représentant le type (au sens de la norme IEC 61850) de
l’élément opérationnel (hors TimeStamp et Qualité) du signal applicatif après une éventuelle
conversion de celui du DA opérationnel (« DAop ») défini en communication dans le SCD ;
 INDICE : entier obligatoire permettant de différencier les différents CDC des signaux en entrée
souhaités pour une instance d’un signal applicatif ;
 DAop : chaîne de caractères obligatoire représentant le nom du DA portant la valeur « opérationnelle »
du signal. Sert à déterminer quel DA est à utiliser dans l’applicatif lors par exemple du mapping d’un DO
avec plusieurs DA opérationnels (cas du DO OP qui possède comme DA : général, phA…) ;
 NUMFLUX : entier obligatoire représentant le numéro de flux qui dans le cas des échanges statiques est
toujours égal à « 1 » au niveau du SCL de modélisation, de l’ICD et du SCD. ;
 Les underscores "_" sont obligatoires même pour les chaînes optionnelles qui ne seraient pas utilisées.
Ce champ doit être considéré comme la clef de correspondance entre l’applicatif spécifié dans le Cahier des
Charges Fonctionnel et la communication.
Si RTE souhaite plusieurs entrées de même rôle applicatif (STAT_NOMLD_NOM DU SIGNAL_TYPE), plusieurs
« Input/ExtRef » seront instanciés correspondant à un attribut « desc » différent (incrémentation de l’élément
PLAGE).
D'un point de vue applicatif, un "OU Logique" devra être appliqué entre ces Input/ExtRef.
Afin d’avoir le plus de souplesse possible pour le « later binding » réalisé dans le SCT, RTE pourra définir
autant d' « Input/ExtRef » pour une même entrée applicative (STAT_NOMLD_NOM DU SIGNAL_PLAGE) que
de n-uplets (pLN/pDO et pServT) possibles et attendus. Chaque valeur de n-uplet différente correspondra à un
INDICE différent.
Attention : la valeur de l’élément « INDICE » sera générée aléatoirement, i.e. pour deux versions différentes
de la modélisation un n-uplet pLN/pDO/ pServT pourra correspondre à deux valeurs de l’élément « INDICE »
différentes.
Indice : 5.1 - Page : 33/79

Si ces n-uplets représentent des types différents du type attendu au niveau de l’élément opérationnel du
signal applicatif (élément « TYPE » du champ « desc » de l’ « Input/ExtRef »), les règles de conversion de types
(et valeurs) (« Enum » vers « boolean »…) seront aussi communiquées le cas échéant avec les exigences
fonctionnelles pour les indices (« INDICE ») concernés.
Il n’est pas prévu d’avoir une conversion de valeurs pour un même type.
La modélisation proposera aussi un « InRef » avec un champ « purpose » de même valeur que le « desc »
(hors NUMFLUX, INDICE, DAop, i.e. STAT_NOMLD_NOM DU SIGNAL_PLAGE_TYPE, le type pouvant être
différent). Cet « InRef » sera utilisé uniquement si la communication est réalisée entre deux LD de même IED.
2. Au niveau de l'ICD
Pour chaque « Input/ExtRef » défini par RTE, pré-remplit l’adresse interne « intAddr » (image de la variable ou
structure utilisée dans l’applicatif) selon une codification qui lui est propre et qui permet de répondre à ces
exigences.
Les autres attributs «iedName», «ldInst», «prefix», «lnClass», «doName», «ldInst», «daName»,
«serviceType», «srcLDInst», «srcPrefix», «srcLNClass», «srcLNInst» et «srcCBName» ne sont pas complétés au
niveau de l’ICD.
3. Gestion de la communication au niveau du SCT

RTE déclare la communication, au travers son SCT, dans le SCD en remplissant les attributs
« iedName », «ldInst», «prefix», «lnClass», «doName», «ldInst», «daName», «serviceType», et «srcCBName»
des « Input/ExtRef » utiles uniquement si l’échange est bien entre deux LD d’IEDs différents.
La communication peut être déclarée au niveau DO ou DA.
Pour une instanciation d’une entrée applicative (STAT_NOMLD_NOM DU SIGNAL_PLAGE), un seul
« Input/ExtRef » (STAT_NOMLD_NOM DU SIGNAL_PLAGE_ TYPE_INDICE_DAop) sera complété.
Il se peut que l’intégralité des Input/ExtRef (« INDICE » différents) d’une même instance d’un signal applicatif
(STAT_NOMLD_NOM DU SIGNAL_PLAGE_TYPE) ne soit pas complétée par le SCD du fait que l’instance du
signal applicatif n’est pas utile pour le système donné ; dans ce cas ni les « Input/ExtRef » de même racine
STAT_NOMLD_NOM DU SIGNAL_PLAGE_TYPE dans le champ « desc » ni l'InRef de la communication interne
dont l’attribut « purpose » a pour valeur « STAT_NOMLD_NOM DU SIGNAL_PLAGE_TYPE » n'ont été
complétés ; Le FIP déclaré en référence à l’« Input/ExtRef » est alors à appliquer.
Dans tous les cas, les « Inputs/ExtRef » ne seront pas supprimés par le SCT conformément à la norme IEC
61850 du fait de la présence d’adresses internes (intAddr) remplies dans l’ICD.
Le BAP à appliquer à une entrée dont la communication est déclarée en statique et extérieure à l’IED est celui
défini en référence à l’« Input/ExtRef » rempli dans le SCD.
L'ICT doit être capable d'importer les éléments du SCD tels que définis afin de configurer automatiquement
l'IED.
Indice : 5.1 - Page : 34/79

02_ConfigurationIEC61850-05_Configuration des échanges-03_Communication dynamique RS-7409

Du fait de la redondance des SCU et SAMU, ou pour le cas de la fonction d’aiguillage des tensions barre, ou
encore pour l’utilisation d’un flux de test, il est nécessaire de pouvoir changer la souscription à un flux SV
ou GOOSE dynamiquement au niveau de chaque LD.
Pour la configuration des échanges dynamiques ou nécessitant une commutation vers des flux de tests entre
LD d'IED différents, le processus élémentaire suivant basé sur le DO « InRef » de la norme IEC 61850 devra
être respecté :
1. Au niveau du SCL
RTE fournit la modélisation au niveau SCL avec la déclaration de chaque entrée applicative d’un LD nécessitant
une communication dynamique sous la forme d’un « InRef » au niveau LLN0 du LD avec l’attribut « purpose »
prédéfini avec le nom du signal applicatif correspondant à celui des exigences fonctionnelles correspondantes.
La syntaxe utilisée est : DYN_NOMLD_NOM DU SIGNAL_PLAGE_TYPE avec :

 DYN : préfixe obligatoire signifiant le caractère dynamique du signal au sens de la configuration ;
 NOMLD : chaîne de caractères obligatoire représentant le nom du LD (LD.inst) d'appartenance du
« InRef » selon la modélisation RTE ;
 PLAGE : entier permettant de différencier les instanciations d'un signal applicatif en termes d'échanges,
par défaut figé à 1 si une seule instance;
 TYPE : chaîne de caractères obligatoire représentant le type (au sens de la norme IEC 61850) de
conversion de celui du DA opérationnel (« DAop ») défini en communication dans le SCD ;
Ce champ doit être considéré comme la clef de correspondance entre l’applicatif spécifié dans le Cahier des
Charges Fonctionnel et la communication.
Attention : En aucun cas, l'indice du « InRef » ne devra être pris en référence car celui-ci sera généré
automatiquement et de manière non déterministe par les outils RTE pour chaque version de la modélisation
d'un LD.
Si RTE souhaite plusieurs entrées de même rôle applicatif (DYN_NOMLD_NOM DU SIGNAL_TYPE),

plusieurs « InRef » seront instanciés correspondant à un attribut « purpose » différent (incrémentation de
l’élément « PLAGE »).
D'un point de vue applicatif, un "OU Logique" devra être appliqué entre ces InRef.
Pour un même « InRef » (DYN_NOMLD_NOM DU SIGNAL_PLAGE_TYPE) sera défini autant d’ « Input/ExtRef »

que de n-uplets (pLN/pDO et pServT) possibles et attendus.
Cela dans le but de documenter les entrées possibles, et potentielles sources de la communication
dynamique, comme le propose la table 51 du fascicule IEC 61850-6 (colonne IEC/IID – expected input of
logical nodes) mais aussi afin d’avoir le plus de souplesse possible pour le « later binding » réalisé dans le SCT.
Chaque valeur de n-uplet différente correspondra à un INDICE différent. INDICE est un entier obligatoire qui
s’ajoute à DYN_NOMLD_NOM DU SIGNAL_PLAGE_TYPE dans la description du « Input/ExtRef ».
Indice : 5.1 - Page : 35/79

Attention : la valeur de « INDICE » sera générée aléatoirement, i.e. pour deux versions différentes de la
modélisation un n-uplet pLN/pDO et pServT pourra correspondre à deux valeurs de « INDICE » différentes.
À l’élément « INDICE » sera aussi ajoutée une chaîne de caractères obligatoire « DAop » représentant le nom
du DA portant la valeur « opérationnelle » du signal. Cet élément est utile lors, par exemple, du mapping d’un
DO avec plusieurs DA opérationnels (cas du DO OP qui possède comme DA : général, phA…) afin de
discriminer celui qui est à utiliser applicativement.
Le champ « desc » des « Input/ExtRef » ainsi ajoutés à la modélisation aura donc pour valeur :
DYN_NOMLD_NOM DU SIGNAL_PLAGE_TYPE_INDICE_DAop
Si ces n-uplets représentent des types différents du type attendu au niveau de l’élément opérationnel du
signal applicatif (élement « TYPE » du champ « purpose » du « InRef » ou « desc » des « Input/ExtRef »), les
règles de conversion de types (et valeurs) (« Enum » vers « boolean »…) seront aussi communiquées le cas
échéant avec les exigences fonctionnelles pour les indices (élément « INDICE ») concernés.
Il n’est pas prévu d’avoir une conversion de valeurs pour un même type.
Dans l’ICD, deux solutions sont possibles selon l’implémentation native ou non par le fournisseur de la
communication dynamique :
2.1. Solution 1 : Gestion native de « InRef » et de la commutation de flux (« InRef » « porte » le signal
commuté)
Le fournisseur, pré-remplit l’adresse interne « intAddr » (image de la variable utilisée dans l’applicatif) du
« InRef » au niveau des DAI selon une codification qui lui est propre ainsi que le DA « purpose » tel que défini
dans la modélisation.
Les DA « setSrcRef », « setSrcCB », « setTstRef », « setTstCB », et « tstEna » sont aussi instanciés avec une
valeur « nulle » mais associés aux attributs « valKind » et « valImport » mis respectivement à « Set » et « true
» (« false » pour tstEna qui ne pourra être modifié qu’en run-time par une action volontaire d’un être
humain).
Afin de définir les sources potentielles à commuter (en mode nominal ou test et uniquement si cela est
nécessaire), dans l’ICD, le fournisseur, pour chaque « Input/ExtRef » correspondant à un « InRef » défini par
RTE, le duplique autant de fois que le nombre de sources pouvant être commutées en ajoutant à la fin du
champ « desc » NUMFLUX où NUMFLUX prend les valeurs de 1 à n (n étant a minima le nombre maximum de
flux commutables demandé par RTE dans les exigences [Rte-BCU] (Cf. GENE-BCU et GENE-IED).
Le champ « desc » est dès lors au format DYN_NOMLD_NOM DU
SIGNAL_PLAGE_TYPE_INDICE_DAop_NUMFLUX.
Les autres attributs « iedName », «ldInst», «prefix», «lnClass», «doName», «ldInst», «daName»,
niveau de l’ICD.
Indice : 5.1 - Page : 36/79

2.2. Solution 2 : Gestion non native de « InRef » et de la commutation de flux (utilisation de

« Input/ExtRef » de manière statique et utilisation du DO « InRef » comme paramètre de
commutation applicatif) :
Le fournisseur, pré-remplit l’adresse interne « intAddr » (image de la variable utilisée dans l’applicatif) du
« InRef » au niveau des DAI selon une codification qui lui est propre ainsi que le DA « purpose » tel que défini
dans la modélisation. Les DA « setSrcRef », « setSrcCB », « setTstRef », « setTstCB », et « tstEna » sont aussi
instanciés avec une valeur « nulle » mais associés aux attributs « valKind » et « valImport » mis
respectivement à « Set » et « true» (« false » pour tstEna qui ne pourra être modifié qu’en run-time par une
action volontaire d’un être humain).
Afin de définir les sources potentielles à commuter (en mode nominal ou test et uniquement si cela est
nécessaire), dans l’ICD, le fournisseur, pour chaque « Input/ExtRef » correspondant à un « InRef » défini par
RTE, l’instancie autant de fois que le nombre de sources pouvant être commutées en ajoutant à la fin du
champ « desc » NUMFLUX où NUMFLUX prend les valeurs de 1 à n (n étant a minima le nombre maximum de
flux commutables demandé par RTE dans les exigences [Rte-BCU] RS-6674, RS-6609 et RS-6652).
De plus le fournisseur, pré-remplit pour chaque « Input/ExtRef » les adresses internes « intAddr » (image de la
variable ou structure utilisée dans l’applicatif) selon une codification qui lui est propre et qui permet de
répondre à ces exigences.
Le champ « desc » est dès lors au format DYN_NOMLD_NOM DU
SIGNAL_PLAGE_TYPE_INDICE_DAop_NUMFLUX.
Les autres attributs « iedName », «ldInst», «prefix», «lnClass», «doName», «ldInst», «daName»,
niveau de l’ICD.

RTE déclare la communication, au travers de son SCT, dans le SCD en remplissant les attributs
« iedName », «ldInst», «prefix», «lnClass», «doName», «ldInst», «daName», «serviceType», «srcCBName»,
des « Input/ExtRef » utiles (i.e. pour une instance d’une entrée (DYN_NOMLD_NOM DU
SIGNAL_PLAGE_TYPE), pour chaque NUMFLUX nécessaire un seul INDICE est complété) ainsi que les DA «
setSrcRef » et « setSrcCB », « setTstRef », « setTstCB » et « tstEna » du « InRef » au niveau DAI conformément
à l’exigence RS-6693.
valImport est mis à « false » pour l’ensemble des attributs précédents du « InRef ».
valKind est généralement laissé à « Set » sauf cas particuliers précisés dans les autres exigences.
Dans ce cas, RTE pourra changer la valeur des DA « setSrcRef », « setSrcCB », « setTstRef », « setTstCB » et
« tstEna » de manière dynamique. Néanmoins, les valeurs possibles des DA « setSrcRef », « setSrcCB », «
setTstRef », « setTstCB » ne pourront correspondre qu’aux « Input/ExtRef » déclarés dans le SCD.
Si lors de la modification en run-time ou à l’initialisation dans le SCD d’une source celle-ci n’a pas été déclarée
ou encore si les DAI des attributs du « InRef » n’ont pas été initialisés ou l’ont été mais de manière erronée
(« tstEna » = « true », mais « setTstCB » ou « setTstRef » non complétés au niveau DAI), le signal applicatif
devra devenir invalide (BadReference) et l'applicatif le traitera conformément au BAP porté par le « InRef ».
Si le signal applicatif n’est pas utile, aucune source au travers les « Input/ExtRef » n’est complétée pour une
même entrée instanciée (DYN_NOM_LD_NOM DU SIGNAL_PLAGE_TYPE) et les attributs du « InRef » ne sont
pas complétés, enfin « valKind » est mis à « RO » pour l’ensemble des DA du « InRef ».
Dans ce cas, le FIP porté par le « InRef » est à appliquer à celui-ci.
Indice : 5.1 - Page : 37/79

3.1. Use case 1 : un seul « Input/ExtRef » est complété

Cela revient à avoir une communication statique.
Remarque :
Dans ce cas, afin d’être homogène avec la communication statique, seul un « Input/ExtRef » avec
NUMFLUX=1 pourra avoir été complété. Les attributs du « InRef » seront déclarés afin de faire référence à cet
« Input/ExtRef » et « valkind » sera figé à « RO » pour ces attributs. Dans le cas contraire le signal applicatif
devra devenir invalide (BadReference) et l'applicatif le traitera conformément au BAP porté par le « InRef ».
3.2. Use case 2 : plusieurs « Input/ExtRef » sont complétés

Si plusieurs « Input/ExtRef » sont complétés (y compris le flux de test), et ce, selon les modalités définies à
l’exigence RS-6822 (i.e., « valKind » à « RO » dans le SCD pour les attributs « setSrcCB » et « setSrcRef » du
« Inref »), le basculement automatique est alors activé et doit s’appliquer. Au contraire, si les modalités de
l’exigence RS-6822 ne sont pas appliquées (i.e., « valKind » à « Set » dans le SCD pour les attributs
« setSrcCB » et « setSrcRef » du « Inref »), le basculement est réalisé de manière externe (automate ou
opérateur).
Les changements de valeurs des paramètres « setTstRef » et « setTstCB » (et respectivement « setSrcRef » et
« setSrcCB ») en run-time ne peut pas être fait simultanément en utilisant des SGCD du fait que la fonctionnal
constraint de ces DO n’est pas de type SG mais SP uniquement. Aussi, le changement des valeurs devra être
réalisé par le client IEC 61850 en respectant le séquencement suivant :
 Etat initial : setXXXRef = « AncienneValeur1 » setXXXCB = « AncienneValeur2 »
 Etape 1 : setXXXRef est modifié à la valeur vide ;
 Etape 2 : setXXXCB est modifié à la valeur vide ;
 Etape 3 : setXXXCB est modifié à « NouvelleValeur1 » (optionnel, si la valeur souhaitée est vide) ;
 Etape 4 : set XXXRef est modifié à « NouvelleValeur2 »
Ce mécanisme permet donc d’éviter un couple cohérent mais non souhaité de valeurs des deux paramètres
qui engendrerais un signal applicatif en entré non souhaité. En effet, le signal applicatif sera invalide
(BadReference) conformément à précédemment tant que l’étape 4 n’est pas atteinte.
l'IED et l’IED doit gérer l'aspect dynamique.
Indice : 5.1 - Page : 38/79

02_ConfigurationIEC61850-05_Configuration des échanges-04_Echanges internes à un IED RS-7411

RTE a besoin de définir l’intégralité des échanges entre LD. Or ces échanges dépendent de l’allocation
fonctionnelle des LD au sein des IED.
Quand un échange se fait entre deux LD de deux IED différents, celui-ci est réalisé en respectant la norme IEC
61850 et sa configuration est réalisée selon la norme et les exigences RTE (Cf. RS-7408 et RS-7409).
Concernant les échanges entre LD de même IED, ceux-ci sont souvent propriétaires. RTE doit pouvoir définir
ces échanges entre les LD par configuration et ce, en utilisant le « later-binding ».
L’implémentation des IED est réalisée par le SCT de RTE. Il définit si la communication entre deux LD est
interne ou externe à l’IED et ce, indépendamment pour chaque signal d’entrée d’un LD (avec un mélange
possible pour un même LD). Aussi, chaque signal doit pouvoir être mappé en interne ou en externe, qu’il soit
statique ou dynamique.
Pour la configuration des échanges entre LD d'un même IED, le processus élémentaire défini à l’exigence RS-
7409 devra donc être respecté avec les particularités suivantes en fonction des phases du processus de
configuration.
1. Au niveau du SCL
Les échanges internes définis dans la modélisation sont indépendants du besoin « statique » ou
« dynamique » de RTE et dépendent exclusivement de l’allocation fonctionnelle des LD au sein d’un IED.
Les signaux à prendre en compte sont donc ceux définis conformément à l’exigence RS-7408 et RS-7409 avec
les syntaxes idoines.
Dans le cas d’un signal statique, RTE fournira en plus dans la modélisation au niveau SCL, la déclaration de
chaque entrée applicative d’un LD nécessitant une communication statique sous la forme d’un « InRef » au
niveau LLN0 du LD avec l’attribut « purpose » prédéfini avec le nom du signal applicatif correspondant à celui
des exigences fonctionnelles correspondantes :
La syntaxe utilisée est : STAT_NOMLD_NOM DU SIGNAL_PLAGE_TYPE avec

 STAT : préfixe obligatoire signifiant le caractère dynamique du signal ;
 NOMLD : chaîne de caractères obligatoire représentant le nom du LD (LD.Inst) d'appartenance du
« InRef » selon la modélisation RTE ;
 PLAGE : entier permettant de différencier les instanciations d'un signal applicatif en termes d'échanges,
par défaut figé à 1 si une seule instance;
 TYPE : chaîne de caractères obligatoirereprésentant le type (au sens de la norme IEC 61850) de
conversion de celui du DA opérationnel (DAop) défini en communication dans le SCD ;
Indice : 5.1 - Page : 39/79

Il est demandé de respecter le point 2 de l’exigence RS-7409 avec la particularité suivante dans le cas d’un
signal statique uniquement (préfixe STAT) : l’instanciation dans l’ICD du signal par le fournisseur correspond à
la création du « InRef » précédent auquel une adresse interne aura été ajoutée et à la création des
« Input/ExtRef » conformément à l’exigence RS-7408 uniquement. Il n’est pas demandé de dupliquer
les « Input/ExtRef » en incrémentant l’élément NUMFLUX.
Remarque :
Dans tous les cas, il n’est pas prévu d’instancier un nouvel INDICE de Input/ExtRef du fait que la donnée ne
provienne pas d’une communication externe Dans le cas d’un signal applicatif pouvant être interne ou
externe, l’attribut «pServ » du « Input/ExtRef » ne sera pas complété.

Dans le cas d’un signal statique (préfixe STAT) ou dynamique (préfixe DYN) et interne à l’IED, RTE déclare la
communication au travers son SCT comme décrit dans l’exigence RS-7409 et conformément à l’exigence RS-
6693.
Remarque :
Bien qu’on soit en interne à l’IED, les Inputs/ExtRef sont bien complétés au niveau du SCD (l'attribut
serviceType sera néanmoins absent du SCD) pour communiquer à l’IED les données internes potentiellement
utilisables.
Pour un même « InRef », interne et externe peuvent coexister (cas d’un signal de test par exemple).
l'IED et l’IED doit gérer l'aspect dynamique.
Indice : 5.1 - Page : 40/79

02_ConfigurationIEC61850-05_Configuration des échanges-05_Commutation automatique des flux RS-6822

Il est demandé dans les exigences [Rte-Mod] applicables aux BCU et SCU de pouvoir basculer
automatiquement d’un flux SV à un autre (cf. RS-6706) (et respectivement pour les GOOSE (cf. RS-6747)) lors
de la défaillance d’un flux dit principal.
Ces mêmes exigences spécifient le fonctionnel attendu.
Concernant la configuration de ce mécanisme, celle-ci se base sur la communication dynamique. Le
basculement ne peut pas concerner une communication statique, ni interne à l’IED.
Le flux principal est toujours porté par le « Input/ExtRef » dont l’attribut « desc » à pour « NUMFLUX », la
valeur 1.
Le flux de secours est porté par celui dont « NUMFLUX » vaut 2.
Un troisième « Input/ExtRef » (NUMFLUX=3 au nombre max de NUMFLUX) pourra être utilisé pour le flux de
test conformément à l’exigence sur la communication dynamique.
Remarque : Rien ne doit empêcher dans le principe de déclarer en flux de tests les flux portés par NUMFLUX1
et NUMFLUX2.
La distinction entre une communication dynamique avec commutation automatique ou non se fait par la
valeur de l’attribut « valkind » des DA « SetSrcCB » et » SetSrcRef » du DO « Inref » associé aux
« Input/Extref ». Dans le cas d’un basculement automatique, « valKind » sera à RO dans le SCD.
La valeur de SetSrcCB et SetSrcRef sera initialisée dans le SCD vers le signal porté par le premier
« Input/ExtRef » (ie. NUMFLUX=1).
Comme Ces deux DA ne peuvent donc plus être modifiés par quelconque client, ils doivent néanmoins être
mis à jour lors des basculements de sources par l’IED. La valeur de « SetSrcCB » et « SetSrcRef » devra donc
être mise à jour et correspondre à tout moment à la source qu’utilise ou que doit utiliser (cas du flux de tests
activé, tstEna = True) la fonction.
Indice : 5.1 - Page : 41/79

02_ConfigurationIEC61850-06_Mapping d'une interface réseau physique avec un AccessPoint RS-7402

Priorité : Phase 1 - Hors Pilotes Modifiée le : 11.01.2022 Étiquette : PDL_0 PX_0 PdB_1 RS1_V4.1
Pour chaque AccessPoint (AP) de l’ICD (et utilisable par RTE), les caractéristiques des ports physiques devront
être définies au travers l’utilisation des paramètres de description des connexions physiques (Cf. §9.4.6 de
l’IEC 61850-6-Ed2.1).
L’ensemble des ports affectés à l’AP (a priori deux ports du fait de la redondance PRP) devra ainsi être décrite.
Un des deux ports sera décrit avec PhysConn type à "Connection" et l’autre à "RedConn".
Les éléments de type P : Type, Plug et Port devront être eux aussi obligatoirement renseignés pour chaque
PhysConn type.
Les valeurs possibles Pour P type = Type

Les valeurs suivantes sont à prendre en considération et à mettre en relation avec les exigences de
connectivité RTE (Cf. [Rte-Com]) :
 100BaseT
 1000BaseT
 100BaseFX
 1000BaseLX
 Monomode
Les valeurs possibles Pour P type = Plug

Les valeurs suivantes sont à prendre en considération et à mettre en relation avec les exigences de
connectivité RTE (Cf. [Rte-Com]) :
 RJ45
 LC
Les valeurs possibles Pour P type = Port

La valeur doit correspondre de manière strictement identique à l’identification visuelle (étiquette, sérigraphie)
du port en face avant ou face arrière de l’équipement. Cette valeur doit aussi être intelligible et unique pour
un IED donné (par exemple : port A…).
Concernant les Access Points, définis au nombre de deux dans le SCL de modélisation (un AP pour le réseau
61850 et un pour le réseau d’administration), il est toléré que les IED en possèdent plusieurs pour le réseau
IEC 61850 (pour distinguer par exemple des niveaux de performance de GOOSE et SV). Dans ce cas, les
contraintes de chaque AP devront être communiquées à RTE au travers une FQR, de plus, dans l’ICD, le nom
des AP devra reprendre celui du SCL de modélisation (conformément au fichier Excel d’exigences sur le SCL,
Cf. RS-5981) en lui rajoutant _X (X étant un entier de 1 à n).
Par exemple : PROCESS_AP_1 et PROCESS_AP_2.
Indice : 5.1 - Page : 42/79

02_ConfigurationIEC61850-07_Configuration des TC indépendantes du site en local RS-6227

Certaines commandes seront indépendantes du site en local.

La configuration de ces commandes se fera par instanciation dans la modélisation SCL de 10 DO « InRef » (1 à
10) au niveau du LDMODEXPF avec comme champ « purpose » la valeur « Commande indépendante site en
local_X», avec X de 1 à 10.
L’ensemble des exigences de configuration devra être respecté (création de l’ICD selon le respect de la
modélisation, valKind…).
Le DA « setSrcRef » sera initialisé dans le SCD et permettra dès lors de communiquer à la fonction les objets
contrôlables donc la modification pourra se faire indépendamment du site en local.
La valeur du DA ne pourra pas être modifiée en run-time ; aussi, au niveau du SCD, l’attribut valKind sera mis à
« RO ».
La valeur du DA ne pourra pas être modifiée par un autre outil ; aussi, au niveau du SCD, l’attribut valKind sera
mis à « RO ».
02_ConfigurationIEC61850-08_Configuration des COMTRADE RS-7412

Priorité : Phase 1 - Hors Pilotes Modifiée le : 29.03.2022 Étiquette : RS1_V4.2
RTE a besoin de configurer les voies analogiques, digitales et triggers de la perturbographie.

La perturbographie peut gérer des signaux applicatifs provenant de l’IED ou en externe à celui-ci.
Il est donc nécessaire de décrire ces signaux et la communication au niveau de la fonction :
 L’utilisation de la communication interne dynamique pour la configuration de ces signaux en entrée de
la fonction est demandée ;
 La déclaration des signaux se fera uniquement au niveau DO ;
 La déclaration d’un signal potentiellement statique sera réalisée dans le SCD en ne remplissant qu’un
seul « Input/ExtRef » (avec NUMFLUX=1) du signal dynamique ;
 Les « InRef » auront pour attribut « purpose » les valeurs suivantes :
 Pour les entrées analogiques : DYN_LDEPF_ANALOG CHANNEL X_1_AnalogueValue avec X =1 à 16*
 Pour les entrées digitales : DYN_LDEPF_DIGITAL CHANNEL X_1_BOOLEEN avec X =1 à 64*
 Les valeurs proviennent des exigences de la fonction (Cf. [Rte-BCU]).
Concernant la configuration de l’enregistrement réel d’une voie, celui-ci s’effectue pour chaque signal
applicatif mais il faut pouvoir distinguer les DO des DA, par exemple on pourra enregistrer indépendamment
la qualité de la valeur opérationnel du DO.
Aussi, les enregistrements, les labels de ceux-ci et les mises en route seront configurés au travers des LN RADR
et RBDR de la modélisation. Ces LN devront être instanciés pour chaque piste enregistrée (i.e. 16 RADR et 144
RBDR conformément à [Rte-BCU]).
Indice : 5.1 - Page : 43/79

Un mapping entre les signaux (au niveau DO) en entrée de la fonction et les LN RADRx et RBDRy qui décrivent
chaque piste / trigger au niveau DO/DA est à réaliser en utilisant les DO SrcRef des LN RADR et RBDR et les
préfixes des LN :
 Le DO SrcRef fera référence aux « InRef » de la fonction LDEPF, qui correspondront aux DO à enregistrer
selon la communication dynamique.
 Les LN RBDRx (x = 1 à 64) n'ont pas besoin de préfixe et représenteront la valeur opérationnelle (définie
par le DA décrit dans le champ « purpose » du « InRef ») d'un signal digital ;
 Les LN bRBDRx (x = 1 à 64) représenteront leurs qualités ;
 Les LN aRBDRx (x = 1 à 16) représenteront les qualités des signaux analogiques RABRy (y de 1 à 16))
avec la relation x=y ;
 Les LN RADRx (x = 1 à 16) n'ont pas besoin de préfixe et représenteront la valeur opérationnelle (définie
par le DA décrit dans le champ « purpose » du InRef) d'un signal analogique.
La configuration sera donc réalisée au niveau DAI par le SCT en définissant pour chaque piste :
 son libellé avec les DA : RADRx.ChNum1.dU ou RBDRy.ChNum1.dU.
 dans le cas des pistes digitales (RBDRx), si elles réalisent une mise en route ou non avec le DO LevMod
(valeurs réalisant la mise en route : Positive or rising, Negative or falling. Other quant à lui signifiera que
la piste ne réalise pas de mise en route.
 sa source, avec les DO : RADRx.SrcRef et RBDRx.SrcRef. La source pointera vers les DA (qualité, valeur)
des entrées déclarées de la fonction (« InRef »). S’il n’y a aucune source, ou si celle-ci n’est pas
cohérente avec les entrées déclarées, la piste ne doit pas être gérée. De fait, le FIP ne s’applique pas et
n’est donc pas à gérer ici.
Si le FIP ne s’applique pas, concernant les BAP :

 ceux-ci s’appliquent exclusivement aux pistes digitales (DIGITAL CHANNEL) réalisant une mise en route ;
 les données enregistrées ne sont pas concernées par les BAP, l’enregistrement est brut.
Les valeurs des DA ne pourront pas être modifiées en run-time ; aussi, au niveau du SCD, l’attribut valKind
sera mis à « RO ».
Les valeurs des DA ne pourront pas être modifiées par un autre outil ; aussi, au niveau du SCD, l’attribut
valKind sera mis à « RO ».
RTE tolère que ces données, bien que normalisées mais étant exclusivement dédiées à de la configuration, ne
soient pas exposées par le serveur dans la première phase du projet R#SPACE. L’ICD devra dès lors être
cohérent en utilisant les sections privées RTE adéquates.
Dans tous les cas, cette solution propriétaire devra être validée par RTE.
Indice : 5.1 - Page : 44/79

02_ConfigurationIEC61850-09_Configuration du réseau d’administration RS-6694

La configuration du réseau d’administration (cf. [Rte-admin]) sera réalisée dans le SCD au niveau de chaque
IED au travers les éléments du langage SCL idoines (branche Communication / Subnetwork / ConnectedAP).
Le fichier « RSPACE – RTE requirements for SCL and Tools.xslx » fourni avec les exigences est à respecter
concernant le nom de l’Access Point et les éléments devant transparaître dans l’ICD (Address, PhyConn…).
Au niveau de la branche Communication / Subnetwork / ConnectedAP, pour l’Access Point du réseau
d’administration, aucun service IEC 61850 (GSE ou SMV) ne sera déclaré par RTE au niveau du SCD.
Enfin, l’Access Point ne sera lié à aucun serveur IEC 61850 de la branche IED.
03_ConfigurationPrivée-01_Généralités-01_Origine et destination du fichier de configuration privée RS-5190

La configuration privée telle que définie dans l’exigence RS-5165 est générée par RTE au travers du
Configurateur Système R#SPACE (cf. RS-5223) et doit pouvoir être importé dans le configurateur d’IED.
Elle sera intégrée au fichier SCD au travers des sections privées et/ou des domaines de noms privés.
De par sa définition, elle ne peut pas être importée nativement par l’ICT. Cependant, elle doit pouvoir être
importée selon le mécanisme tel que défini dans l’exigence RS-5192.
03_ConfigurationPrivée-01_Généralités-02_Mécanisme d'import et de chargement RS-5192

3_modifié_round_2
Le mécanisme à implémenter pour la gestion de la configuration privée (non normalisée IEC 61850, cf. RS-
5165) sera proche de celui de la gestion des paramètres (i.e. appliquer le mécanisme de transformation
(médiateur) à la configuration privée et les exigences associées).
Cependant, il n’est pas demandé de « fichier de transformation » pour les données de configuration. Les
éléments de transformation seront réalisés par le fournisseur et intégrés au médiateur. RTE qualifiera
l’import, mais ne demande pas d’avoir un regard sur les équations de transformation.
La phase d'import (conformément aux exigences définies pour l'import des paramètres et à l'amendement
sus-cité) devra succéder automatiquement à la phase d'import de la configuration normalisée (cf. RS-5179)
qui se serait réalisée avec succès.
Les deux configurations seront en effet dans le même fichier SCD.
Indice : 5.1 - Page : 45/79

03_ConfigurationPrivée-01_Généralités-03_Gestion des sections privées RTE RS-7403

L’ensemble des éléments privés défini par RTE est spécifié dans le fichier Excel et le fichier XSD fourni en
annexe aux exigences.
Une des particularités de R#SPACE par rapport à la norme IEC 61850 est que :
 certaines sections privées nécessitent une initialisation au niveau de l’ICD-. Celles-ci sont spécifiées
dans les exigences idoines ;
 lors de l’import du SCD, l’ICT ou le médiateur doivent être capables d’en interpréter certaines pour
configurer l’IED.
Le fichier Excel fourni en annexe définit :
1. D’un côté, les privés que le fournisseur devra mettre dans l’ICD avec deux cas :
- Les privés exclusivement pour RTE, et donc la seule action de votre part est de les prendre tels que
communiqués par le SCL de modélisation, et de les mettre dans l’ICD ;
- Les privés dont une exigence est associée et qui devront être aussi mis dans l’ICD ;
2. De l’autre côté ceux que nous rajouterons dans le SCD et qui concernent aussi deux cas :
- Les privés exclusivement pour RTE, dans ce cas vous n’avez rien à faire dessus ;
- Les privés qui doivent être interprétés par vous, auquel cas une exigence doit être associée.
La conformité du fichier SCD à ce schéma XSD devra être vérifiée lors des imports au niveau de l’ICT ou du
médiateur (Cf. RS-5140).
Indice : 5.1 - Page : 46/79

03_ConfigurationPrivée-02_Configurer les BAP-01_Configuration effective RS-6901

Priorité : Phase 2 Modifiée le : 07.01.2022 Étiquette : RS1_V4.1
Afin de configurer au niveau de l'IED les variantes des BAP à utiliser ainsi que la valeur par défaut à appliquer
dans le cas d'une substitution de l'entrée invalide, le processus d'échanges (statique, dynamique et interne
aux IED) est appliqué avec les particularités / précisions suivantes :
Utilisation d’une classe privée RTE tBAP_RTE définie dans RTE_CLASS.xsd fourni en annexe avec les
attributs suivants :
 variant : une chaîne de caractères représentant la variante selon l'énumération définie par RTE dans
RTE_CLASS.xsd et selon les exigences sur les BAP ;
 defaultValue : la valeur du DA par défaut selon les types de la norme IEC 61850 ;
 dataStreamKey : valeur correspondant au « desc » ou « purpose » du signal sur lequel le BAP
s’applique.
Condition d'application de cette classe :

Cet attribut est ajouté et appliqué selon les conditions suivantes :
Pour une communication dynamique ou interne :

Il se situe au niveau des DOI « InRef » ; L’attribut « dataStreamKey » est potentiellement inutile mais sa
présence et sa complétude sont requis par soucis d’homogénéité.
Pour une communication statique externe :

Au niveau de la balise « Inputs » pour les « Inputs / ExtRef » (le langage SCL ne permettant pas d’avoir de
privés au niveau Inputs/ExtRef. L’attribut « dataStreamKey » sert de clef vers le « Inputs/ExtRef » ;
L'ICT doit être capable d'importer ces éléments et de configurer l'IED sur cette base soit au travers du
médiateur soit nativement.
03_ConfigurationPrivée-02_Configurer les BAP-02_Contrôle de cohérence RS-7404
L’ICT doit vérifier lors de l’import de la configuration (cf. RS-5140), la conformité des BAP implémentés dans
l’IED (qu’ils aient été configurés selon l’exigence RS-5961 ou qu’ils soient figés en dur dans l’IED comme toléré
dans une première phase du projet R#SPACE) avec les valeurs définies dans le fichier SCD décrites à
l’exigence RS-5961 .
 Lorsque le « Input/ExtRef » ou respectivement « Inref » font référence à un DO, la valeur par défaut
indiquée dans le BAP pour ce DO s’applique au DA opérationnel correspondant défini dans DAop du
champ « desc » ou respectivement « purpose » selon la valeur du DA qualité ;
 Lorsque le « Input/ExtRef » ou respectivement « Inref » font référence à un DA le BAP ne s’applique
pas ;
 Si aucun champ privé de configuration du BAP n’est associé à un « Input/ExtRef » ou respectivement
« Inref » par le SCD, le BAP ne s’applique pas à l’entrée ;
 Le BAP défini au niveau d’un DO « InRef » s’applique à celui-ci dans le cas de son invalidité (par exemple
si le « InRef » est mal configuré et n’est pas capable de déterminer le DO/DA à aiguiller).
Indice : 5.1 - Page : 47/79

03_ConfigurationPrivée-03_Configurer les FIP (Functional Input profil) RS-7415

Afin de configurer au niveau de l'IED les valeurs par défaut à affecter aux variables applicatives lorsqu’aucun
signal n’est mappé sur une entrée d’un LD, le processus d'échanges (statique, dynamique et interne aux IED)
est appliqué avec les particularités / précisions suivantes :
1. Utilisation d’une classe privée RTE tFIP_RTE définie dans RTE_CLASS.xsd fourni en annexe avec
les attributs suivants :
 defaultValue : valeur par défaut ;
 dataStreamKey : valeur correspondant au « desc » ou « purpose » du signal sur lequel le FIP s’applique.
2. Cet attribut est ajouté et appliqué selon les conditions suivantes :

 pour une communication dynamique ou interne :
- Il se situe au niveau des DOI « InRef » ; L’attribut « dataStreamKey » est potentiellement inutile
mais sa présence et sa complétude sont requis par soucis d’homogénéité.
- La valeur sera conforme au type défini dans l'élément « TYPE » du champ "purpose";
- La valeur par défaut indiquée dans l'attribut s'applique.
 pour une communication statique externe :
- au niveau de la balise « Inputs » pour les « Inputs / ExtRef » (le langage SCL ne permettant pas
d’avoir de privés au niveau Inputs/ExtRef. L’attribut « dataStreamKey » sert de clef vers le
« Inputs/ExtRef » ;
- La valeur sera conforme au type défini dans l'élément « TYPE » du champ "desc";
- La valeur par défaut indiquée dans l'attribut s'applique et se substitue à la valeur du DA
opérationnel défini par l'élément « DAop » du champ "desc".
L'ICT doit être capable d'importer ces éléments et de configurer l'IED sur cette base soit au travers du
médiateur soit nativement.
Indice : 5.1 - Page : 48/79

03_ConfigurationPrivée-04_Configurer les LED-01_via l’ICT RS-6697

Il doit être possible de configurer les LED de l’IED (mapping vers un DO/DA IEC 61850, couleurs, …) grâce au
configurateur d’IED (ICT) en fonction des possibilités offertes par l’IED.
03_ConfigurationPrivée-04_Configurer les LED-02_via le SCD RS-7413

Afin de configurer les LED des IEDs, le mécanisme de mapping basé sur « InRef » avec des « boundary LN »
préconisé par l’IEC 61850-7-5-Ed1 pour les DI/DO sera à appliquer avec les particularités et les précisions
suivantes :
Exigence 1
Les données de configuration sont définies au niveau d'un « boundary LN » (LPLE « System Physical LED
representation ») qui est défini dans le LDSUIED (cf. modélisation RTE) ;
Ce LN n’étant actuellement pas normalisé, RTE ne demande pas (mais ne l'empêche pas...) dans une première
phase du projet R#SPACE de le supporter nativement et donc d’exposer les données. RTE demande seulement
dans un premier temps d’utiliser ce LN et le mécanisme de mapping via « InRef » associés uniquement à des
fins de configuration.
C’est pourquoi, l’ensemble des éléments seront dans des sections privées en plus du namespace RTE (cf.
exemple d'ICD et de SCD pour les DI / DO). L’ICT (au travers du médiateur) devra comprendre la sémantique
et être capable de l’importer et de configurer l’IED en conséquence ;
Exigence 2
La constitution et l’instanciation des LN (un « boundary LN » par carte et l'instanciation des DO « multi »
correspondants au nombre de LED comme par exemple « InRef », ainsi que les DO de settings) de l’IED seront
réalisées par le fournisseur et précisées dans l’ICD*conformément aux possibilités offertes par l’IED ;
Exigence 3
Les DO de settings (hors identifications des LED et cartes) sont au niveau de la description du LN pour la
plupart optionnels mais doivent être instanciés selon la capacité de configuration réelle des LED de l'IED
(clignotement possible ou non...) ;
Cependant, bien que l'on soit dans une section privée (du fait de la non exposition des données imposée par
RTE), tout DO instancié et dont la valeur peut être modifiée par RTE devra avoir ses DA exposés au niveau DOI.
Les attributs valImport et valKind devront être remplis respectivement à "true" et "Set" pour le DA portant la
valeur.
Pour les autres DA, valImport et valKind devront être remplis respectivement à "false" et "RO" au niveau DAI,
si cela n’est pas déjà réalisé dans les « DataTypeTemplate » ;
Indice : 5.1 - Page : 49/79

Exigence 4
Les DO non utiles à RTE n'ont pas à être instanciés. Cependant, bien que l'on soit dans une section privée (du
fait de la non exposition des données imposée par RTE), tout DO instancié et non nécessaire à RTE (par
exemple LedBlkMod dont la valeur devrait être toujours à "fix"), devra avoir sa valeur exposée au niveau DOI
(s'il est nécessaire de le préconfigurer et que la valeur à une influence sur le comportement de l'IED pour
répondre aux exigences RTE, ce qui est le cas pour l'exemple LedBlkMod) et les attributs valImport et valKind
devront quelle que soit la valeur être remplis respectivement à "false" et "RO" si cela n’est pas déjà réalisé
dans les « DataTypeTemplate » ;
Exigence 5
Concernant les DO d'identification d'une LED au niveau d'une carte, ceux-ci sont aussi optionnels au niveau de
la description du LN. Les LN permettant l’identification visuelle de la LED au niveau de la face avant doivent
être instanciés dans un premier temps au niveau de l'ICD.
Les valeurs doivent être renseignées au niveau DAI et pour chaque DA, valImport et valKind devront être
remplis respectivement à "false" et "RO" si cela n’est pas déjà réalisé dans les « DataTypeTemplate » ;
Exigence 6
Lorsque les données seront exposées (ce qui n'est actuellement pas demandé explicitement par RTE dans
cette première phase de R#SPACE), il sera demandé que les DO nécessaires à l'identification d'une LED au
niveau du hardware (carte, position de la carte) soient remplis à des fins de maintenance;
Exigence 7
Un attribut dans une section privée (la norme interdisant la création de nouveaux DA), définie par RTE mais
devant être remplie par le fournisseur au stade de l'ICD, au niveau de chaque DO permettra d’identifier les
groupes de settings (DO) communs dont la valeur (DA setVal) doit être la même du fait d’une limitation de
configuration de l’IED (par exemple, dans le cas où les couleurs ne se configurent pas au niveau de chaque
LED de l’IED mais au niveau d'une carte ou d'un groupe de LED) :
 RTE-SettingGroup : Entier définissant un groupe commun de setting pour un même DA.
Exigence 8
Une LED peut être pilotée (Allumée/Eteinte) directement par le changement de valeur d’un DO de type
« booléen » qui aura été préalablement mappé à la LED par configuration ou par le changement de valeur du
DO « cmdLED » ;
Indice : 5.1 - Page : 50/79

Exigence 9
Afin de réaliser le mapping des LED, l’exigence RS-6412 s’applique dans le cas d’une communication interne
statique avec les particularités suivantes :
 Dans la modélisation, RTE communiquera les « Input/ExtRef » des signaux internes pouvant être
mappés vers une LED avec un champ « desc » qui aura pour valeur :
STAT_LDSUIED_LPLE X LED Y_1_TYPE_INDICE_DAop_1
- L’instanciation des Input/ExtRef selon l’élément INDICE sera réalisée par RTE et fourni dans la
modélisation ;
- L’instanciation des Input/ExtRef selon les éléments X et Y sera réalisée par le fournisseur dans
l’ICD. X correspond au LN.inst du LPLE représentant la carte physique et Y le numéro de la LED de la
carte, correspondant à l’indice du DO CmdLED.
- L’instanciation des Input/ExtRef selon l’élément TYPE sera réalisée par RTE et fournie dans la
modélisation ; Les conversions de type à appliquer par le LPLE vers le booléen représentatif de
l’état brute de la LED (avant d’appliquer à ce booléen les DO de configuration pour générer l’état
effectif de la LED) est donné dans les exigences SCU/SAMU.
 Au niveau du LLN0 du LDSUIED, devront être instanciés autant de « InRef » que de LED de l’IED
conformément au point 1 de l’exigence RS-6412.
Cette instanciation est à réaliser par le fournisseur.
Le champ « purpose » aura dès lors pour valeur STAT_LDSUIED_LPLE X LED Y_1_ BOOLEEN.
Exigence 10
Comme l’ensemble des DA ne sert que pour de la configuration, les attributs valKind et valImport associés au
DA qui auront pour valeurs respectives « Set » et « true » dans l’ICD seront respectivement mis à « RO » et
« false » dans le SCD.
03_ConfigurationPrivée-05_Configurer les I/O-01_via l’ICT RS-6700

Il doit être possible de configurer les I/O de l’IED (mapping vers un DO/DA IEC 61850, battantes, …) grâce au
configurateur d’IED (ICT).
Indice : 5.1 - Page : 51/79

03_ConfigurationPrivée-05_Configurer les I/O-02_via le SCD RS-7414

Afin de configurer les entrées/sorties TOR et analogiques (4-20mA, hors U/I) des IEDs, le mécanisme de
mapping basé sur « InRef » avec des « boundary LN » définis par l’IEC 61850-7-5-Ed1 pour les DI/DO sera à
appliquer avec les particularités et les précisions suivantes :
Exigence 1
Les données de configuration sont définies au niveau de « boundary LN » (LPDO « System Physical Digital
Output », LPDI System Physical Digital Input, et LPAI « System Physical Analog Input ») qui sont définis dans le
LDSUIED (cf. modélisation RTE) ;
Remarque :
Ces LN n’étant actuellement pas normalisés, RTE ne demande pas (mais ne l'empêche pas...) dans une
première phase du projet R#SPACE de les supporter nativement et donc d’exposer les données. RTE demande
seulement dans un premier temps d’utiliser ces LN et le mécanisme de mapping via « InRef » associés
uniquement à des fins de configuration.
C’est pourquoi, l’ensemble des éléments seront dans des sections privées en plus du namespace RTE (cf.
exemple d'ICD et de SCD, avec comme sections privées RTE-LN0 et RTE-DOI).
L’ICT (au travers du médiateur) devra comprendre la sémantique et être capable de l’importer et de
configurer l’IED en conséquence ;
Exigence 2
La constitution et l’instanciation des LN (un « boundary LN » par carte et l'instanciation des DO « multi »
correspondants au nombre d’entrées / sorties – « Indx » et « InRef », ainsi que les DO de settings) de l’IED
seront réalisées par le fournisseur et précisées dans l’ICD*conformément aux possibilités offertes par l’IED ;
Exigence 3
Les DO de settings (hors identifications des E/S et cartes) sont au niveau de la description du LN pour la
plupart optionnels mais doivent être instanciés selon la capacité de configuration réelle des entrées/sorties de
l'IED et conformément aux exigences RTE concernant les SAMU et SCU (configuration des battantes...).
valeur.
si cela n’est pas déjà réalisé dans les « DataTypeTemplate » ;
Remarque :
Au respect des exigences RTE près (battantes…), il n’est donc pas demandé d’instancier tous les DO de
settings s’ils ne sont pas supportés par l’IED ;
Indice : 5.1 - Page : 52/79

Exigence 4
De plus, les DO de settings optionnels et non utiles à RTE (configuration possible de l'IED mais dont l'accès
n'est pas spécifié par RTE, par exemple VinTyp correspondant au type AC/DC d'une entrée, qui serait
potentiellement toujours figé à DC) n'ont pas besoin d'être instanciés.
RTE), tout DO instancié et non nécessaire à RTE, devra avoir sa valeur exposée au niveau DOI (s'il est
nécessaire de le préconfigurer et que la valeur à une influence sur le comportement de l'IED pour répondre
aux exigences RTE) et les attributs valImport et valKind devront quelle que soit la valeur être remplis
respectivement à "false" et "RO" si cela n’est pas déjà réalisé dans les « DataTypeTemplate » ;
Exigence 5
Concernant les DO d'identification d'une entrées / sorties au niveau d'une carte sont aussi optionnels au
niveau de la description du LN. Cependant, doivent être instanciés dans un premier temps au niveau de l'ICD,
ceux permettant l'identification visuelle de l'E/S au niveau du bornier et de sa position sur le bornier en face-
arrière de l'équipement à des fins de génération automatique de schéma à partir du SCD et pour faciliter le
mapping de la part de RTE dans le SCT.
remplis respectivement à "false" et "RO" si cela n’est pas déjà réalisé dans les « DataTypeTemplate » ;
Exigence 6
cette première phase de R#SPACE), il sera demandé que les DO nécessaires à l'identification d'une entrée /
sortie au niveau du hardware (carte, position de la carte) soient remplis à des fins de maintenance ;
Exigence 7
Un attribut dans une section privée (la norme interdisant la création de nouveaux DA), défini par RTE mais
devant être rempli par le fournisseur au stade de l'ICD, au niveau de chaque DO permettra d’identifier les
groupes de settings (DO) communs dont la valeur (DA setVal) doit être la même du fait d’une limitation de
configuration de l’IED (par exemple, dans le cas où les battantes ne se configurent pas au niveau de chaque
entrée pour l’IED mais au niveau d'une carte) :
 RTE-SettingGroup : Entier définissant un groupe commun de setting pour un même DA.
Exigence 8
La gestion des entrées doubles et la temporisation de complémentarité associée (permettant le passage de la
valeur du DA à Bad-State) est définie au niveau de chaque LD concerné (LDDJ...). La gestion de la
complémentarité est demandée de manière applicative et non pas au niveau des entrées afin de ne pas
rajouter de contraintes supplémentaires en terme de configuration sur le mapping des entrées vers l'applicatif
notamment ;
Exigence 9
Une sortie peut être pilotée directement par le changement de valeur d’un DO de type « booléen » qui aura
été préalablement mappé à la sortie par configuration ou par le changement de valeur du DO « cmdDO » ;
Indice : 5.1 - Page : 53/79

Exigence 10
Afin de réaliser le mapping des entrées, l’exigence RS-6412 s’applique dans le cas d’une communication
interne statique ; Le DO « Ind » de l’entrée est mappé au « InRef » du LLN0 du LD qui nécessite d’acquérir la
valeur de l’entrée.
Exigence 11
Afin de réaliser le mapping des sorties, l’exigence RS-6412 s’applique dans le cas d’une communication
interne statique avec les particularités suivantes :
mappés vers une sortie avec un champ « desc » qui aura pour valeur : STAT_LDSUIED_LPDO X Sortie
Y_1_TYPE_INDICE_DAop_1
modélisation ;
l’ICD. X correspond au LN.inst du LPDO représentant la carte physique et Y le numéro de la sortie
de la carte, correspondant à l’indice du DO CmdDO.
modélisation ; Les conversions de type à appliquer par le LPDO vers le booléen représentatif de
l’état brute de la sortie (avant d’appliquer à ce booléen les DO de configuration pour générer l’état
effectif de la sortie) est donné dans les exigences SCU/SAMU.
 Au niveau du LLN0 du LDSUIED, devront être instanciés autant de « InRef » que de sorties de l’IED
conformément au point 1 de l’exigence RS-6412.
Cette instanciation est à réaliser par le fournisseur. Le champ « purpose » aura dès lors pour valeur
STAT_LDSUIED_LPDO X Sortie_PLAGE_BOOLEEN.
Exigence 12
Indice : 5.1 - Page : 54/79

03_ConfigurationPrivée-06_Configurer le Modbus RS-6905

Afin de configurer les entrées/sorties ModBus ainsi que l'interface, le mécanisme de mapping basé sur
« InRef » avec des « boundary LN » tel qu'utilisé pour les DI/DO sera à appliquer. À ce jour, il n’est pas prévu
d’utiliser l’IEC 61850-80-5 afin d’homogénéiser la manière de configurer les éléments privés. Les particularités
et les précisions suivantes sont à appliquer :
Exigence 1
Les données de configuration sont définies au niveau de « boundary LN » (LMBI «System Physical ModBus
Interface» et LMSI « System Physical Modbus Slave Interface ») qui sont définis dans le LDSUIED
(Cf. modélisation IEC 61850 RTE) ;
Remarque :
Ces LN n’étant actuellement pas normalisés, RTE ne demande pas (mais ne l'empêche pas...) dans une
première phase du projet R#SPACE de les supporter nativement et donc d’exposer les données. RTE demande
seulement dans un premier temps d’utiliser ces LN et le mécanisme de mapping via « InRef » associés
uniquement à des fins de configuration.
C’est pourquoi, l’ensemble des éléments seront dans des sections privées en plus du namespace RTE (Cf.
exemple d'ICD et de SCD pour les DI/DO). L’ICT (au travers du médiateur) devra comprendre la sémantique
et être capable de l’importer et de configurer l’IED en conséquence ;
Exigence 2
La constitution et l’instanciation des LN de l’IED seront réalisées par le fournisseur et précisées dans l’ICD.
La logique suivante est à respecter :
 un « boundary LN » LMBI
 plusieurs instances de LMSI
 l'instanciation des DO « multi » correspondants au nombre d’entrées / sorties : indx, AnInx et CmdDOx,
ainsi
 les DO de settings.
Indice : 5.1 - Page : 55/79

Exigence 3
RTE demande l'instanciation au niveau de l'ICD pour chaque IED supportant le ModBus, de :
 une interface (LN LMBI)
 10 esclaves (LNs LMSI) constitués de :
- 10 entrées ModBus (15 digitales (DO Indx avec x=1 à 10)
- 10 analogiques (DO AnIny avec y=11 à 20))
- 20 sorties digitales (DO CmdDOz avec z = 21 à 40)).
Les plages de x, y et z se succèdent afin de pouvoir utiliser les mêmes DO de settings dont l’instanciation est
multiple (par exemple le DO « ModBusFunction » sera instancié 40 fois, une fois pour chaque entrée / sortie
et son indice d’instanciation permettra de déterminer l’entrée / sortie ModBus de l’esclave correspondante.
valeur.
si cela n’est pas déjà réalisé dans les « DataTypeTemplate ».
Exigence 4
Concernant les DO d'identification de l'interface ModBus, ceux-ci sont optionnels au niveau de la description
du LN, cependant ils doivent être instanciés au niveau de l'ICD.
remplis respectivement à "false" et "RO" si cela n’est pas déjà réalisé dans les « DataTypeTemplate ».
Exigence 5
cette première phase de R#SPACE), il sera demandé que les DO nécessaires à l'identification d'une interface
ModBus au niveau du hardware (carte, position de la carte…) soient remplis à des fins de maintenance.
Exigence 6
Afin de réaliser le mapping des entrées ModBus (« AnIn », « Ind »), l’exigence RS-6412 s’applique dans le cas
d’une communication interne statique ; Le DO (« AnIn », « Ind » de l’entrée est mappé au « InRef » du LLN0
du LD qui nécessite d’acquérir la valeur de l’entrée.
Indice : 5.1 - Page : 56/79

Exigence 7
Afin de réaliser le mapping des sorties, l’exigence RS-6412 s’applique dans le cas d’une communication
interne statique avec les particularités suivantes :
mappés vers une sortie ModBus avec un champ « desc » qui aura pour valeur : STAT_LDSUIED_LMSI X
Sortie Y_1_TYPE_INDICE_DAop_1
modélisation ;
l’ICD. X correspond au LN.inst du LMSI représentant l’esclave et Y le numéro de la sortie de
l’esclave, correspondant à l’indice du DO CmdDO.
modélisation ; Les conversions de type à appliquer par le LMSI vers le booléen représentatif de
l’état brute de la sortie (avant d’appliquer à ce booléen les DO de configuration pour générer l’état
effectif de la sortie) est donné dans les exigences SCU/SAMU.
 Au niveau du LLN0 du LDSUIED, devront être instanciés autant de « InRef » que de sorties modbus
conformément au point 1 de l’exigence et au nombre d’instanciation demandé dans la présente
exigence.
Cette instanciation est à réaliser par le fournisseur.
Le champ « purpose » aura dès lors pour valeur STAT_LDSUIED_LMSI X Sortie_PLAGE_BOOLEEN.
Exigence 8
Indice : 5.1 - Page : 57/79

03_ConfigurationPrivée-07_Configuration des entrées courant et tension RS-5970

L'essentiel de la configuration des entrées courant et tension des SAMU est portée par les LN TVTR et TCTR.
Néanmoins, il est nécessaire à RTE de connaître le lien entre les LN TVTR et TCTR et les entrées physiques de
l'équipement.
Un mapping par configuration au niveau SCD n'est pas demandé à ce stade du projet R#SPACE.
Il est donc demandé que dans l'ICD, soit placé au niveau des DOI des LN TVTR et TCTR, le paramètre privée :
RTE-PhysicalTVTCbinding avec une valeur du type
NumInput_v_BoardNum_w_BrdPos_x_ConnName_y_ConnRef_z.
NumInput Number of physical inputs of the board or group.
BoardNum Number of the board
BrdPos Physical position of the board
ConnName Connector name of the input
ConnRef Reference of the input on the connector
v, w, x, y, z peuvent être des entiers ou des chaînes de caractères.

Pour chaque configuration différente des entrées analogiques (U et I) d'une SAMU, un nouvel ICD devra être
fourni.
Indice : 5.1 - Page : 58/79

03_ConfigurationPrivée-08_Configuration du SNMP RS-6906

La configuration du SNMP sera réalisée dans le SCD par extension de l’élément P type de la balise « Address »
au niveau de l’accès Point du réseau d’administration dans la branche communication.
Les éléments de configuration sont les suivants :
Valeur de l'attribut P type Description
SnmpUserName Nom d'utilisateur pour la connexion (la stratégie n'est pas encore définie)
Protocole d'authentification, valeurs possibles :
none
hmac-128-sha-224
SnmpAuthProt
hmac-192-sha-256
hmac-256-sha-384
hmac-384-sha-512
SnmpAuthKey Password / clé pour l'authentification
Protocole de confidentialité, valeurs possibles :
none
SnmpPrivProt aes-cfb-128
aes-cfb-192
aes-cfb-256
SnmpPrivKey Password / clé pour la confidentialité
Indice : 5.1 - Page : 59/79

03_ConfigurationPrivée-09_Configuration du/des serveurs Syslog RS-6907

La configuration du/des serveurs Syslog (cf. [Rte-Admin] et [Rte-Cyber]) sera réalisée dans le SCD par
extension de l’élément P type de la balise « Address » au niveau de l’accès Point du réseau d’administration
dans la branche communication.
Les éléments de configuration sont les suivants :
Valeur de
l'attribut P Description
type
SyslogIP Adresse IP du serveur Syslog
Protocole de transport Syslog
Valeurs possibles :
udp
tcp
SyslogProt tcp/tls
Ce paramètre est à implémenter à partir du moment où il y a plusieurs protocoles possibles
implémentés dans l’IED pour le transfert Syslog conformément aux exigences et planning
d’implémentation de la cybersécurité.De même pour les valeurs, à ajuster en fonction des protocoles
implémentés.
Valeur du code de la catégorie des messages. Global à l'ensemble des messages de l'IED. Par défaut
13 selon recommandation de l'IEC62351, valeurs possibles de 0 à 23 selon les codes des catégories
du tableau ci-dessous. La priorité PRI du message sera donnée par l'équation suivante : Priorité =
SyslogCat
(catégorie × 8) + gravité (Cf. [Rte-Cyber]).
Le choix de la gravité est à déterminer par les fournisseurs pour chaque message suivant les valeurs
possible des exigences de sévérité (Cf. [Rte-Cyber]).
Gravité (severity) maximale jusqu’à laquelle un log est envoyé.
Permet de filtrer l’envoi des logs.
SyslogMaxSev Valeurs possibles [None ; 0 ; 1 ; 2 ; 3 ; 4 ; 5 ; 6 ; 7].
Si le paramètre est mis à « None », aucun message n’est envoyé.
Si le paramètre est mis à « 5 », seuls les messages dont la gravité vaut 0, 1, 2, 3, 4 ou 5 sont envoyés.
Indice : 5.1 - Page : 60/79

Codes de catégories
Code Mot-clé Description
0 kern messages du noyau
1 user messages de l'espace utilisateur
2 mail messages du système de messagerie
3 daemon messages des processus d'arrière-plan
4 auth messages d'authentification
5 syslog messages générés par syslogd lui-même
6 lpr messages d'impressions
7 news messages d'actualités
8 uucp messages UUCP
9 cron Taches planifiées (at/cron)
10 authpriv sécurité / élévation de privilèges
11 ftp logiciel FTP
12 ntp Synchronisation du temps NTP
13 security log audit
14 console log alert
15 solaris-cron Taches planifiées (at/cron)
16 local0 Utilisation locale libre 0 (local0)
Remarque
Le format des messages n’est pas configurable est doit se conformer au format proposé par la norme 62351-
14.
04_Paramétrage-01_Définitions-01_Paramètres standards RS-5224

Les paramètres "standards" RTE expriment uniquement le besoin fonctionnel de RTE, indépendamment des
considérations spécifiques à chaque IED et de la modélisation IEC 61850. Ils seront mis à disposition dans
des fichiers de paramètres dits standards en sortie de l’outil de paramétrage (cf. RS-5232).
Indice : 5.1 - Page : 61/79

04_Paramétrage-01_Définitions-02_Paramètres IED (constructeur) RS-6236

Priorité : Phase 2 Modifiée le : 06.12.2021 Étiquette : RS1_DC2-3_modifié_round_2
Chaque IED possède actuellement des paramètres propres, dis constructeur, différents de ceux de RTE et de
ceux définis dans la modélisation.
Dans une prochaine phase du projet, il sera demandé au fournisseur de supporter nativement les paramètres
de la modélisation IEC 61850 qui du point de vue de RTE se substitueront à terme aux paramètres
constructeurs.
04_Paramétrage-01_Définitions-03_Paramètres 61850 RS-6237

Priorité : Phase 2 Modifiée le : 06.12.2021 Étiquette : RS1_DC2-3_modifié_round_2
La modélisation définit les paramètres des fonctions selon la norme IEC 61850. A ce stade du projet, il n’est
pas demandé aux IED de les supporter. Dans une seconde phase, les IEDs doivent les supporter nativement.
Les paramètres IEC 61850 doivent pouvoir se substituer aux paramètres constructeurs.
04_Paramétrage-01_Définitions-04_Transformation des paramètres standards RS-5225

Les paramètres fonctionnels exprimés par RTE n'ont pas tous d'équivalence directe avec les paramètres
spécifiques de chaque IED. De plus, afin de préparer la migration dans les futurs paliers RTE, les paramètres de
la modélisation IEC 61850 RTE déjà définis pour R#SPACE par RTE sont à supporter.
Il est donc nécessaire de spécifier les opérations à réaliser pour passer des paramètres standards RTE vers les
paramètres constructeurs spécifiques à chaque IED ou vers les paramètres IEC 61850 au fur et à mesure de
leur support. Des fichiers de transformations seront utilisés dans ce but.
Indice : 5.1 - Page : 62/79

04_Paramétrage-02_Généralités-01_Mécanisme d'import et de chargement des paramètres RS-5186

3_modifié_round_2
Du point de vue de RTE, à ce jour coexistent trois ensembles de paramètres :

 Les paramètres « standards » RTE
 Les paramètres IEC 61850 modélisés
 Les paramètres constructeurs.
Ces trois ensembles n'étant pour l'instant pas liés par une bijection, RTE n'utilisera pas, dans une première
phase du projet R#SPACE, les services de la norme IEC 61850 pour la modification des paramètres mais un
mécanisme autre défini dans les exigences suivantes.
À ce titre :
 RTE ne demande donc pas d'exposer sur le serveur IEC 61850 de l'IED les DA définis dans la
modélisation des paramètres fonctionnels.
 Il n'est donc pas demandé dans la branche « DataTypeTemplate » du fichier ICD d'avoir les DA
correspondants.
Attention, certains DA ayant pour FC : SP, SG devront néanmoins être exposés (et auront besoin de
l'utilisation des services idoines) conformément à la modélisation dans le cas d'utilisations autres que le
paramétrage, il pourra s'agir par exemple des consignes ARS.
RTE n'utilisera pas non plus le fichier SCD pour modifier les paramètres, mais un autre fichier dit fichier de
« paramètres standards ».
Indice : 5.1 - Page : 63/79

04_Paramétrage-02_Généralités-02_Version XML RS-5183

La dernière version disponible du XML doit être supportée (actuellement la version 1.1).
04_Paramétrage-02_Généralités-03_Origine et destination du fichier de paramètres standards RS-5056

Le fichier de paramètres « standards » est généré par RTE au travers l’outil de paramétrage (cf. RS-5232) et
est importé dans le configurateur d’IED.
04_Paramétrage-03_FichierTransformation-01_Elaboration du fichier de transformation RS-5058

Le fichier de transformation est élaboré par le fournisseur d'IED et validé par RTE lors de la qualification de
l'IED.
04_Paramétrage-03_FichierTransformation-02_Version XSLT RS-5184

La version 2.0 du XSLT doit être supportée.
04_Paramétrage-03_FichierTransformation-03_Import des fichiers de transformation RS-5080

3_modifié_round_2
Le configurateur d’IED (au travers du médiateur, cf. RS-5059) doit permettre d’importer les versions
successives des fichiers de transformation des IED qu’il est capable de configurer et paramétrer.
Indice : 5.1 - Page : 64/79

04_Paramétrage-03_FichierTransformation-04_Contrôle de cohérence RS-5226

L’import précède l'intégration du fichier de transformation dans le configurateur d'IED.

Avant ou après import dans le configurateur d’IED d'un fichier de transformation, un contrôle de cohérence
devra être automatiquement effectué.
 Validation de la prise en charge de l'IED cible du fichier de transformation par le configurateur d'IED ;
 le contrôle de versions (la version à importer doit être supérieure à la dernière version importée) ;
 Identification et validation des paramètres spécifiques de l'IED (adresses ou autres identifiants uniques)
;
 Cohérence avec les fonctions instanciées dans l'IED.

Si des incohérences pouvant nuire à l’intégrité de l'IED sont décelées lors de ces contrôles (la classification des
incohérences est laissée à l’appréciation du constructeur), le fichier importé n’est pas validé et l’utilisateur
doit en être averti explicitement.
Pour les autres incohérences sans influence sur l’intégrité de l'IED, un rapport de cohérence devra être
présenté à l’utilisateur à qui la validation de l’import sera demandée.

La validation du contrôle de cohérence est une condition nécessaire et suffisante pour valider l'import et
passer à la phase d'intégration. Le cas échéant, l'import doit être réalisé s'il est postérieur au contrôle.
La non-validation du contrôle de cohérence entraine la suppression de l'import si ce dernier est antérieur au
contrôle.
04_Paramétrage-03_FichierTransformation-05_Intégration dans le configurateur d'IED/équipement RS-5227

Cette phase suit la phase d'import.

Le configurateur d'IED/équipement devra intégrer les transformations associées à l'IED cible du fichier de
transformation.
04_Paramétrage-03_FichierTransformation-06_Suivi des fichiers de transformation RS-5228

Le configurateur d'IED/équipement doit permettre à tout moment de visualiser la liste des fichiers de
transformation et les modèles d'IED/équipements associés.
Indice : 5.1 - Page : 65/79

04_Paramétrage-03_FichierTransformation-07_Mécanisme de transformation des paramètres standards RTE RS-5229

Le fichier de transformation ainsi intégré au configurateur permet de spécifier le passage des paramètres
standards RTE vers les paramètres de l’IED qu’ils soient constructeur ou selon la modélisation IEC 61850 en
fonction du support de celle-ci (cf. RS-5186).
04_Paramétrage-04_Import-01_Import de paramètres standards RTE RS-5059

3_modifié_round_2
Il doit être possible d’importer des paramètres standards RTE basés sur les fichiers de transformation des IED
supportés. Cette fonction d'import pourrait être portée par un applicatif séparé ou, de préférence, par un
plugin intégré au configurateur d'IED. RTE préfèrerait une solution intégrée. Cette fonction (et par
extrapolation l’applicatif associé en fonction de la solution retenue par le fournisseur) est nommée
« médiateur ».
NB: Le médiateur pourra être utilisé aussi pour les données de configuration (cf. RS-5192).
04_Paramétrage-04_Import-02_Association entre les fichiers de transformation et l'IED/équipement cible RS-5066

La fonction d'import de paramètres standards RTE devra réaliser automatiquement l'association entre les
fichiers de transformation et les IED du fichier de paramètres.
En cas de difficulté d'association, il devra être proposé à l'utilisateur de réaliser l'association manuellement et
son choix devra être conservé pour les usages ultérieurs.
Indice : 5.1 - Page : 66/79

04_Paramétrage-04_Import-03_Contrôle de cohérence lors de l'import des paramètres standards RTE RS-5129

L’import est l’étape qui précède la transformation. Les nouvelles valeurs du fichier ne sont appliquées dans le
fichier FCPE que lors de l’étape de chargement qui succède à la transformation.
Avant ou après import dans le configurateur d’IED d'un fichier de paramétrage standard, un contrôle de
cohérence devra être automatiquement effectué.
 le respect des plages de valeurs (conformément au fichier de transformation, contrôle sur les
paramètres RTE (standard) uniquement) ;
 la conformité du fichier aux attentes de l’outil (XSD implémenté…) ;
 le contrôle de versions (la version à importer doit préférentiellement être supérieure à la dernière
version importée) ;
 le changement de cible (Site, Niveau de tension, Tranche, IED).
Si le contrôle de cohérence a été réalisé après import, la validation autorise le passage en phase de
transformation. Un fichier non validé n’est pas importé si le contrôle a eu lieu avant, ou supprimé si le
contrôle de cohérence a eu lieu après.
La non-validation d'un fichier importé empêche le passage à l’étape de transformation.

Si le contrôle de cohérence a été réalisé avant import, la validation autorise l’import et le passage en phase de
transformation.
Pour les incohérences sans influence sur l’intégrité du FCPE, un rapport de cohérence devra être présenté à
l’utilisateur à qui la validation de l’import sera demandée.
Si des incohérences pouvant nuire à la transformation et à l’intégrité du FCPE sont décelées lors de ces
contrôles (la classification des incohérences est laissée à l’appréciation du constructeur), l’import n’est pas
validé et l’utilisateur doit en être averti explicitement.
04_Paramétrage-05_Transformation en paramètres spécifiques IED RS-5130

Lorsque le contrôle de cohérence est validé, les paramètres de l’IED sont calculés (selon la modélisation IEC
61850 en fonction de son support ou constructeur) à partir des paramètres RTE.
Pour l’IED cible :
 Un rapport de transformation est alors généré. Ce rapport doit pouvoir être exporté ou copié dans un
fichier ;
 Si une erreur est générée pendant la transformation, le rapport de transformation est présenté à
l'utilisateur. L'opération de transformation est abandonnée et le chargement sera impossible. Le
rapport de transformation doit pouvoir être exporté ;
 Si aucune erreur n'est rencontrée, l'étape de transformation est validée automatiquement.
Indice : 5.1 - Page : 67/79

04_Paramétrage-06_Intégration-01_Contrôle de cohérence avant l’intégration au projet en cours RS-5065

L’intégration du fichier succède à une transformation validée.

Avant l’intégration au projet, après la transformation validée (RTE->IEC 61850 ou RTE->Constructeur), un
nouveau contrôle de cohérence doit être réalisé.
Les critères minimaux à considérer sont :

 le respect des plages de valeurs attendues par l'IED (IEC 61850 ou non) ;
 le format du fichier conformément au XSD ;
 les paramètres à modifier.
Un rapport de cohérence est alors présenté à l'utilisateur qui valide ou pas la poursuite de l'opération
d’intégration. La validation pourra être automatique si aucun écart n'est détecté.
Le rapport doit pouvoir être exporté ou copié dans un fichier.
04_Paramétrage-06_Intégration-02_Affichage des paramètres à modifier avant l’intégration au projet en RS-5132

cours
L’intégration consiste à appliquer les nouvelles valeurs importées dans le configurateur d’IED au projet en
cours.
Avant le chargement dans le fichier FCPE, un affichage des actions qui seront effectuées sur le projet en cours
doit être réalisé :
 Paramètre constructeur ou IEC 61850 RTE;
 Description ;
 Valeur avant modification ;
 Valeur après modification ;
 Reboot de l'IED ou réinitialisation d'une fonction.
Un rapport des modifications est alors présenté à l'utilisateur qui valide ou pas la poursuite de l'opération
d’intégration.
04_Paramétrage-06_Intégration-03_Prise en compte des nouveaux paramètres par le configurateur RS-5072

d'IED/équipement
Suite à la validation par l’utilisateur de l’intégration des paramètres transformés dans le configurateur d’IED,
les valeurs des données correspondantes du projet en cours sont modifiées.
Indice : 5.1 - Page : 68/79

04_Paramétrage-06_Intégration-04_Echec de mise à jour du projet en cours RS-5137

En cas d'échec d’intégration des paramètres transformés au projet, le projet en cours doit revenir à son état
antérieur.
Un rapport sur l'erreur rencontrée doit être affiché. Ce rapport doit pouvoir être exporté ou copié dans un
fichier.
05_ Interface Web Administration et configuration RS-6823

Les outils de configuration propres aux fournisseurs (ICT) doivent posséder une interface de services Web
dédiée aux gestes d'administration et de configuration afin de réaliser ces gestes de manière uniforme et
identique quel que soit l’ICT. Il s’agit d’une interface minimaliste et standardisée par Rte. Cette interface est
définie dans l’exigence ADMIN-01-Interface Web Administration et configuration de [Rte-admin].
Indice : 5.1 - Page : 69/79

4. Informations en entrée
Configuration normalisée RS-6040
Priorité : Pilotes Modifiée le : 10.09.2021 Étiquette : RS1_DC2-3_initial
La configuration dite "normalisée" regroupe la part de la configuration (cf. RS-5222) qui se base
exclusivement sur la norme IEC 61850 et sur les objets qui y sont modélisés.
Configuration privée RS-5165

Priorité : Pilotes Modifiée le : 07.01.2022 Étiquette : RS1_DC2-3_initial RS1_DC2-
3_modifié_round_2 RS1_DC2-
3_modifié_round_4
La configuration privée ou "non normalisée" contient la part de la configuration (cf. RS-5222) qui n’est pas
normalisée par l’IEC 61850 mais qui doit néanmoins être mise à disposition des IED. Il peut s’agir par exemple
dans le cas du lot SAMU, SCU de R#SPACE, de la configuration des cartes I/O.
Sa description sera intégrée dans le fichier de configuration normalisée IEC 61850 (SCD, cf. RS-5089) selon les
modalités qui sont définis dans la suite des exigences (utilisation de la balise « Private » du SCL) ; des sous-
éléments XML à cette balise peuvent être insérés par RTE et sont propres à un espace de nom spécifique à
RTE ((cf. le XSD RTE défini dans l'information RS-6143) (cf. le NSD RTE défini dans l’exigence RS-6145)).
Fichier ICD RS-5087

3_modifié_round_2
Le fichier ICD est un fichier XML du langage SCL qui décrit les capacités de l'interface IEC 61850 d'un IED
donné.
Les exigences RTE au sujet de l’ICD sont spécifiées dans l’exigence RS-5977.
Fichier SCD RS-5089

3_modifié_round_2 RS1_DC2-
3_modifié_round_4
Le fichier SCD est décrit selon le langage SCL de la norme IEC 61850.
Ce fichier au sein du projet R#SPACE regroupera la configuration normalisée (cf. RS-6040) et la configuration
non-normalisée (cf. RS-5165).
Indice : 5.1 - Page : 70/79

Fichier de paramètres standards Rte RS-5109

3_modifié_round_4
Le fichier de paramètres standards RTE est une sortie de l'outil de paramétrage RTE.
Le fichier utilise le langage XML.
Son extension sera de type .par
Il contient l'ensemble des paramètres fonctionnels d'une tranche ; son XSD est décrit dans l'exigence RS-5141.
Exemple de Fichier :
Indice : 5.1 - Page : 71/79

Fichier de transformation RS-6908

3_modifié_round_4 RS1_V4
Format :
Le format utilisé pour le fichier de transformation est le XSLT (eXtensible Stylesheet Language
Transformations), le langage de transformation des fichiers XML.
Spécificités de l'IED :
Ce fichier étant spécifique à chaque modèle d'IED et à son rôle (type) dans le système (BCU par exemple),
certaines données sont spécifiques (adressage interne/noms des attributs à utiliser et plages de valeurs
notamment).
Le fichier de transformation permet de réaliser le passage d'un fichier de paramètres standards vers les
données spécifiques de paramétrage d'un IED donné.
Ce fichier de transformation est écrit pour faire nativement une restitution HTML, cependant il contient
toutes les informations utiles pour réaliser les transformations nécessaires à d'autres usages dont ceux
demandés au configurateur d’IED.
Structure générale :
Le fichier comprend les principales parties suivantes :
 Entête du fichier ;
 Version du fichier ;
 Définition de l'IED cible ;
 Métadonnées du fichier ;
 Définition des paramètres XSL ;
 Template Equipement ;
 Template Fonctionnalités.
Entête du fichier :
L'entête porte la déclaration du type de fichier et les définitions des espaces de noms utilisés.
À noter que l'espace des noms MathML est utilisé ici pour permettre la restitution graphique des formules de
calculs de certains paramètres.
Version du fichier :
La version du fichier est précisée dans la variable : VersionFichierTransformation
Indice : 5.1 - Page : 72/79

Définition de l'IED :
C'est la définition de l'IED cible. Plusieurs attributs sont actuellement utilisés pour identifier de manière
unique l'IED cible conformément à l’exigence RS-5987 :
 Le Modèle d’IED (selon le fournisseur) précisé dans la variable : Modele;
 La version logicielle (firmware) précisée dans la variable : VersionLogicielle ;
 La version matérielle (hardware) précisée dans la variable : VersionMaterielle ;
 Le nom du fournisseur (vendor ou manufacturer) précisé dans la variable : Fournisseur ;
 Le type d’IED RTE précisé dans la variable : TypeRTE ;
 Les références à l’ICD de l’IED précisées dans les variables : IdentifiantICD, RevisionICD et VersionICD.
Remarque :
Un fichier de transformation est donc identifié de manière unique par la clé composée des éléments
précédents permettant d’identifier l’IED auquel il s’applique ainsi que la version du fichier.
Métadonnées du fichier de paramètres standards :

Cette partie permet de récupérer les attributs de l'élément racine du fichier de paramètres standards qui sera
transformé:
 Site ;
 Niveau de Tension ;
 Tranche ;
 Version du fichier (VersionFichier) ;
 Date de modification.
Définition des paramètres standards en paramètres XSLT :

La définition sous forme de paramètres XSLT permet de définir une seule fois chaque paramètre standard RTE
et ensuite de pouvoir l'utiliser directement dans le reste du fichier.
Dans l'exemple ci-dessous, on récupère uniquement les paramètres de la fonction "PX" associé à l'IED
identifié par la variable XSLT "$EQUIPEMENT/@Equipement":

 <xsl:param name="MES-PX" select="//FONCTIONS/FONCTION[@Nom='PX' and
@Equipement=$EQUIPEMENT/@Equipement]/Paramètre[@Nom='MES-PX']"/>
 <xsl:param name="X1" select="//FONCTIONS/FONCTION[@Nom='PX' and
@Equipement=$EQUIPEMENT/@Equipement]/Paramètre[@Nom='X1']"/>
 <xsl:param name="T1" select="//FONCTIONS/FONCTION[@Nom='PX' and
@Equipement=$EQUIPEMENT/@Equipement]/Paramètre[@Nom='T1']"/>
Template "Initial" (<xsl:template match="/" name="xsl:initial-template">) :

Ce Template est utilisé pour faire la mise en page de la restitution en HTML :
 Définition des différentes parties de la page (head, body, footer) ;
 Définition du style CSS à appliquer aux éléments de la page (html>head>style).
À partir de ce Template, on appelle le Template "Equipement".
Indice : 5.1 - Page : 73/79

Template "Equipement" (<xsl:template match="EQUIPEMENTS/EQUIPEMENT">) :

Ce Template permet :
 d'une part de se restreindre aux paramètres standards définis pour un équipement cible ;
 et d'autre part, de structurer le tableau (définition des entêtes / colonnes) qui va accueillir les résultats
des autres templates (lignes de données du tableau).
Tous les autres templates spécifiques sont appelés par ce template principal.
Template Spécifique (<xsl:template name="ParametresZones">, par exemple) :

Le Template spécifique regroupe l'ensemble des paramètres spécifiques de l'IED associés à une fonctionnalité
donnée; chaque paramètre spécifique à l'IED y apparait comme une ligne du tableau HTML.
Chaque paramètre spécifique de l'IED :
1. est représenté par un élément html "<tr>" (une ligne du tableau) avec comme identifiant (attribut "id")
son adresse interne ;
2. contient les sous-éléments html "<td>" (valeurs constituant une ligne de tableau) ;
3. peut contenir un attribut propre "data-boucleRetour" qui permet de spécifier à l'outil de paramétrage
s'il doit permettre la surcharge exceptionnelle de ce paramètre (boucle retour). Cet attribut aura la
valeur "oui" (data-boucleRetour="oui") dans ce cas.
Elément <td class="adresseIED"> :

Sa valeur reprend l'identifiant interne du paramètre.
Elément <td class="descriptionIED"> :

Sa valeur correspond à la description du paramètre.
Elément <td class="valeurIED"> :

Il contient deux sous-éléments qui permettent de décrire la valeur du paramètre :
1. sous-élément : contient soit la valeur soit la formule XSLT permettant de calculer
la valeur du paramètre ainsi que les attributs data-ValeurMin, data-ValeurMax et data-PasValeur ;
2. sous-élément : contient l'unité en notation SI associée à la valeur. Cet élément
peut aussi contenir d'autres sous-éléments qui pourraient être utilisés par l'outil de paramétrage ;
3. sous-élément : peut contenir la liste de valeurs possibles à utiliser pour
la boucle retour. Ces informations ne seront pas visibles sur la restitution HTML (visibilité désactivé
par CSS).
Elément <td class="FormulePourAffichage"> :

Cet élément contient sous forme de notation MathML, quand cela est applicable, la formule de calcul du
paramètre spécifique en fonction des paramètres standards RTE.
Elément <td class="ParametresRTE"> :

Il contient l'ensemble des paramètres standards RTE qui participent au calcul du paramètre spécifique sous
forme d'éléments <td class="ParametreRTE">.
Indice : 5.1 - Page : 74/79

Sous-élément <td class="ParametreRTE"> :

Il contient les informations suivantes:
 sous-élément : nom du paramètre standard RTE tel qu'affiché ;
 sous-élément : contient la formule XSLT permettant de récupérer la valeur
du paramètre standard RTE ;
 sous-élément : contient la formule XSLT permettant de récupérer l'unité en
notation SI associée au paramètre.
Elément <td class=" ImpactFonctionnel"> :

Pour un paramètre, cet élément défini l’impact de la modification du paramètre sur l’IED.
Les valeurs possibles seront : Reboot de l’IED, Réinitialisation fonctionnelle ou vide.
Modélisation SCL RS-7398

Priorité : Pilotes Modifiée le : 07.01.2022 Étiquette : RS1_V4.1
La modélisation SCL est l'expression de la modélisation RTE (fichier Word) au format SCL, et ce, jusqu'au
niveau des BDA. Elle est la référence du projet R#SPACE.
La modélisation au format SCL sera déclinée en plusieurs fichiers (un par type d’IED cf. RS-5101).
Chaque fichier de modélisation précisera l’instanciation maximum enveloppe des LD pour le type d’IED donné.
La conformité du fichier SCD à ce fichier devra être vérifiée lors des imports au niveau de l’ICT ou du
médiateur (cf. RS-5140).
Name Space Description (NSD) RTE (LN/DO RTE et ENUM RTE) RS-6145
Priorité : Pilotes Modifiée le : 07.01.2022 Étiquette : RS1_DC2-3_modifié_round_2
L’intégralité des nouvelles données définies par RTE est communiquée, pour prise en compte, au travers du
fichier SCL de modélisation.
La conformité du fichier SCD à ce fichier devra être vérifiée lors des imports au niveau de l’ICT ou du
Indice : 5.1 - Page : 75/79

Schéma XSD du fichier de paramètres standards RS-6909

Ce fichier XSD définit la structure des fichiers XML de paramètres standards.
Diagramme :
PARAMETRES_RTE :
L'élément racine regroupe les données d'identification de la Tranche (Site, Poste/NiveauTension, Tranche et la
version du fichier). Il contient toutes les autres branches.
OUVRAGES & OUVRAGE :

L'élément "OUVRAGES" est un conteneur pour l'ensemble des éléments de type "OUVRAGE".
L'élément "OUVRAGE" représente un Ouvrage physique comme une Ligne (LIT) ou un Transformateur. Il
regroupe l'ensemble des attributs électrotechniques (RXH, IST) extraits de référentiels ou calculés sous la
forme d'éléments de type "Parametre".
Indice : 5.1 - Page : 76/79

REDUCTEURS_MESURES & REDUCTEURS_MESURE :

L'élément "REDUCTEURS_MESURES" est un conteneur pour l'ensemble des éléments de type
"REDUCTEUR_MESURES".
L'élément "REDUCTEUR_MESURES" représente un réducteur de mesure physique. Il est identifié par ses
attributs (Nom, Type de réducteur, Classe) et contient deux éléments de type "Parametre" qui correspondent
aux valeurs primaires et secondaires de la grandeur physique mesurée.
FONCTIONS & FONCTION:

L'élément "FONCTIONS" est un conteneur pour l'ensemble des éléments de type "FONCTION".
L'élément "FONCTION" représente une instanciation d'une fonctionnalité telle que spécifiée par RTE. Il est
identifié par ces attributs (Nom, Description) et contient des éléments de type "Parametre" qui correspondent
aux paramètres de la fonction.
De plus, une fonction est associée à un élément de type "EQUIPEMENT" (attribut "Equipement").
EQUIPEMENTS & EQUIPEMENT :

L'élément "EQUIPEMENTS" est un conteneur pour l'ensemble des éléments de type "EQUIPEMENT".
L'élément "EQUIPEMENT" représente un IED (par exemple, une protection ou un automate). Il est identifié
par ses attributs (Modele, VersionLogicielle, VersionMaterielle, IdentifiantICD, VersionICD, RevisionICD,
TypeRTE et Fournisseur). De plus, il contient les éléments de type "PARAMETRE" qui permettent de
surcharger des paramètres spécifiques équipements quasi-figés à l'issue de la qualification de l'IED.
Parametre :
L'élément "Parametre" représente un paramètre défini par ses attributs nom, description et type de
paramètres.
Il contient les sous-éléments: "Valeur" et "ListeValeurs".
Valeur :
Cet élément contient la valeur du paramètre (de type numérique ou chaîne de caractères).
Lorsque la valeur est de type "Numerique", cet élément peut prendre en attributs les informations relatives à
l'unité, à la plage de valeurs, au pas, au "TypeMesure" ("Ohm/Phase", "Ohm/Boucle") et "TypeValeur"
("HT", "BT").
ListeValeurs :
Pour un paramètre de type "ChaineDeCaracteres", cet élément regroupe l'ensemble des valeurs possibles.
Indice : 5.1 - Page : 77/79

Schéma XSD du fichier de paramètres standards RS-6144

Ces fichiers XSD définissent la structure des fichiers XML du langage SCL défini dans le document IEC 61850-6.
RTE demande que ceux-ci soient respectés.
L’exigence RS-5981 donne la version à respecter.
La conformité du fichier SCD à ces fichiers devra être vérifiée lors des imports au niveau de l’ICT ou du
Ces fichiers se nomment :
 SCL.xsd
 SCL_IED.xsd
 SCL_Enums.xsd
 SCL_DataTypeTemplates.xsd
 SCL_BaseTypes.xsd
 SCL_BaseSimpleTypes.xsd
 SCL_Substation.xsd
 SCL_Communication.xsd
Schéma XSD des sections privées RTE RS-6143

Ce fichier XSD définit la structure des éléments XML RTE présents sous le nœud « Private » du fichier SCL. Ces
éléments RTE sont présents dans le fichier de modélisation SCL (RS-5948) et/ou le fichier SCD ( RS-5089 ).
Le fichier Excel joint en annexe récapitule l'intégralité des balises privées RTE.
Indice : 5.1 - Page : 78/79

5. Informations en sortie
FCPE RS-5230
Fichier de Configuration et de Paramétrage de l'Equipement (FCPE)

Le FCPE est un fichier dont le format est spécifique à chaque constructeur qui regroupe l’ensemble des
données / valeurs de configuration et de paramétrage ainsi que la logique programmable (si existante) définie
par le constructeur pour particulariser l’équipement avec les fonctions demandées par RTE dans son cahier
des charges.
Ce fichier, qui peut être :
 un fichier binaire,
 un ensemble de fichiers,
 une connexion directe du configurateur de l’équipement vers l’équipement,
est directement chargé dans l’équipement, en une seule fois, ou de manière partielle selon la nature des
modifications (paramètres, configuration ou logique).
Projet RS-5315
Un projet est un fichier (ou ensemble de fichiers) propre à un configurateur d’IED/équipement qui regroupe, à
un instant donné, les données de configuration et/ou de paramétrage associé à un IED/équipement ou un
ensemble d’IED/équipements.
L’export d’un projet pour le chargement d’un IED/équipement donné est le FCPE (cf. RS-5230).
Indice : 5.1 - Page : 79/79

ANNEXES
Les annexes suivantes sont prescriptives et complètent le présent document :
1. RSPACE – RTE requirements for SCL and Tools 2. Services IEC 61850 RSPACE - Référentiel pour IED-
20200915.xslx 23_20220105
3. Paramètres STANDARDS 20211103.xsd 4. Fichier Transformation 20211103.xslt
5. RTE_LN_NSD 20211105.nsd 6. RSPACE_MODELISATION_PRIVATE_20210903.xslx
7. RTE_CLASS_20200429.xsd 8. SCL_MODELISATION_20211224.scl
Les annexes ci-dessous sont quant à elles uniquement à titre illustratif :
9. ESSAI-225kV-6ABCDE.1 20211103.par
Les annexes suivantes, fournies également à titre illustratif, n’ont pas été remises à jour dans ce document
par rapport aux évolutions de la modélisation (Exemple : BAP et FIP par exemple). Cependant, les principes
explicités n’ont pas évolué :
10. DIDO ICD 20190923.icd 11. DIDO SCD 20190923.scd

12. Communication statique ICD 20190923.icd 13. Communication statique SCD 20190923.scd
14. Communication dynamique ICD cas natif 20190923.icd 15. Communication dynamique SCD cas natif 20190923.scd
16. Communication dynamique ICD cas non natif 17. Communication dynamique SCD cas non natif
20190923.icd 20190923.scd
18. Communication interne ICD 20190923.icd 19. Communication interne SCD 20190923.scd
20. MODBUS ICD 20190923.icd 21. MODBUS SCD 20190923.scd
22. MODEXPF ICD 20190923.icd 23. MODEXPF SCD 20190923.scd
24. COMTRADE ICD 20190923.icd 25. COMTRADE SCD 20190923.scd
FIN DU DOCUMENT

(Rte-Conf) NT-DI-CNER-DCCL-SYS-18-00256-Ind.5.1 Exigences de Paramétrage Et Configuration Des SAMU-SCU-BCU

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

(Rte-Conf) NT-DI-CNER-DCCL-SYS-18-00256-Ind.5.1 Exigences de Paramétrage Et Configuration Des SAMU-SCU-BCU

Transféré par

Droits d'auteur :

Formats disponibles

Date d’approbation :

R#SPACE – Lot 23 Tranche

Documents annulés : NT-DI-CNER-EM-18-00256-Ind.5

Accessibilité : Filières : Domaine GED :

Centre National Expertise Réseaux

R#SPACE – Lot 23 Tranche

Rédacteur(s) Vérificateur(s) Approbateur(s)

Frédéric FOUSSERET Volker LEITLOFF Timothée MICHEL

Signé par : LEMAIRE Jean-Etienne

Lieu de conservation (ou...) : DOKI

R#SPACE – Lot 23 Tranche

R#SPACE – Lot 23 Tranche

R#SPACE – Lot 23 Tranche

2. Interface - Configurateur de lot – généralités

01_Définitions-01_IED / équipement RS-5217

01_Définitions-02_Configurateur d'IED / équipement RS-5218

R#SPACE – Lot 23 Tranche

01_Définitions-03_ Configuration et Paramétrage RS-7405

R#SPACE – Lot 23 Tranche

Commande d’état d’une fonction :

Valeurs de consignes temps réel :

R#SPACE – Lot 23 Tranche

01_Définitions-04_Outil de configuration système R#SPACE RS-5223

Configurateur Système R#SPACE (R#CONF) :

01_Définitions-05_Outil de Paramétrage RS-5232

Outil de Paramétrage (R#PARAM) :

02_Outils-01_Fourniture d'un configurateur d'IED / équipement RS-5069

R#SPACE – Lot 23 Tranche

02_Outils-02_Rôle du configurateur d'IED / équipement RS-5220

Le configurateur d’IED/équipement doit permettre de configurer et paramétrer l’intégralité d’un

02_Outils-03_Identification/Nommage d’un projet au sein du configurateur d’IED/équipement RS-5316

02_Outils-04_Sauvegarde d’un projet du configurateur d’IED/équipements RS-5317

Un projet doit pouvoir s’exporter d’un configurateur d’IED/équipement et être sauvegardé/stocké.

R#SPACE – Lot 23 Tranche

02_Outils-05_Restauration d’un projet dans un configurateur d’IED/équipements RS-5318

Un projet sauvegardé doit pouvoir être réimporté/restauré dans un configurateur d’IED/équipement.

02_Outils-06_Compatibilité descendante des nouvelles versions du configurateur d’IED/équipements RS-5319

02_Outils-07_Export du FCPE du configurateur d’IED/équipement RS-5320

02_Outils-08_Identification/Nommage du FCPE RS-5321

02_Outils-09_Chargement du fichier FCPE dans les IED/équipements RS-5234

R#SPACE – Lot 23 Tranche

02_Outils-10_Rédemarrage des IED/équipements après chargement du fichier FCPE RS-5235

03_Droits d'accès-01_Modifications à partir du configurateur d'IED / équipement RS-5073

03_Droits d'accès-02_Modifications en face avant RS-5071

R#SPACE – Lot 23 Tranche

03_Droits d'accès-03_Accès à l'IED ou équipement hors canal principal d'administration RS-5120

04_Traçabilité-01_Suivi des modifications RS-5062

Chargement/modification de la configuration et du paramétrage :

04_Traçabilité-02_Affichage des versions sur les IEDs / équipements RS-5097

R#SPACE – Lot 23 Tranche

3. Interface - Configurateur des lots BCU, SCU, SAMU et IED de tranche

R#SPACE – Lot 23 Tranche

01_Configuration et Paramétrage-01_Généralités-01_Processus de configuration et paramétrage RS-5975

R#SPACE – Lot 23 Tranche

01_Configuration et Paramétrage-01_Généralités-02_Configuration normalisée, non-normalisée et RS-5233

Le fichier de transformation portera quant à lui :

Configuration normalisée IEC 61850 :

Configuration privée ou non normalisée IEC 61850 :

R#SPACE – Lot 23 Tranche

01_Configuration et Paramétrage-01_Généralités-03_R#QUALIF RS-6146

À ces fins, R#QUALIF stocke :

01_Configuration et Paramétrage-01_Généralités-04_Exigences relatives au langage SCL-01_Généralités RS-6831

R#SPACE – Lot 23 Tranche