(Rte-Com) NT-DI-CNER-DCCL-SYS-18-00287-Ind.4.1 RSPACE Exigences D'implémentation IEC 61850

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

Exigences d’implémentation IEC 61850
39 Pages 0 annexes
Documents annulés : NT-DI-CNER-DCCL-18-00287-Ind.4

Documents de référence :
Référence fonctionnelle : Extrait du 01/02/2022 de Jira GoPro du projet R#SPACE
Résumé : ce document regroupe les exigences nécessaires à l’interopérabilité des différents éléments (composants ou
fonctions) 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-00287 Date d’approbation :
Indice : 4.1 - Page : 2/39

Rédacteur(s) Vérificateur(s) Approbateur(s)
Nom Visa Nom Visa Nom Date/Visa
01/02/2022 01/02/2022 01/02/2022
Volker LEITLOFF Volker LEITLOFF Timothée MICHEL

X VL X VL X
Xavier MICHAUT Volker LEITLOFF Volker LEITLOFF Timothée MICHEL
Signé par : LEITLOFF Volker Signé par : LEITLOFF Volker Signé par : MICHEL Timothée
Tarik MACHKOUR 03/02/2022
X Xavier Michaut
Xavier MICHAUT
Signé par : CN2I Michaut Xavier

01/02/2022
X
Tarik MACHKOUR
Signé par : MACHKOUR Tarik
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 02/07/19 Pour approbation Bastien ILAS Initiation du document
Xavier MICHAUT
2 14/06/19 Pour approbation Revue après Dialogue Compétitif des lots SCU, SAMU, BCU
Volker LEITLOFF
Xavier MICHAUT Revue après la dernière séquence du Dialogue Compétitif des lots SCU,
3 18/09/19 Pour approbation
Volker LEITLOFF SAMU, BCU
Xavier MICHAUT MàJ intégrant des modifications ou des précisions apportées par FdM ou
4 14/12/21 Pour approbation Volker LEITLOFF dans le cadre des échanges techniques (comités, FQR…) avec les titulaires
Tarik MACHKOUR des contrats de développement
Xavier MICHAUT
Correction dans RS-7454, ajout de RS-5025 qui n’apparaissait pas dans la
4.1 01/02/22 Pour approbation Volker LEITLOFF
version 4 du document et intégration de RS-7235 (initialement RS-5902)
Tarik MACHKOUR
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 : 4.1 - Page : 3/39

SOMMAIRE
1. Introduction ...................................................................................................................................................4
2. MOD - Implémentation de la modélisation IEC 61850 Rte............................................................................5
3. COM - Communication et services IEC 61850 dans R#SPACE..................................................................... 19
4. LAN.IED - Exigences du réseau LAN applicables aux IED ............................................................................ 25
5. SYNC.IED - Exigences de Synchronisation applicables aux IED ................................................................... 29
6. LLN0.QUAL - Traitement des DO Mod/Beh/Sim/Health du LLN0 et des attributs de 'qualité' .................. 33
Indice : 4.1 - Page : 4/39

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 01 février
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 : 4.1 - Page : 5/39

2. MOD - Implémentation de la modélisation IEC 61850 Rte
Priorité Phase 1 - Pilotes Fonction modifiée le 2021-11-18
Identifiant RS-6769 Étiquette RS1_V4
Version 2.0
Versions précédentes : RS-4554
Cette partie décrit les modalités d'implémentation de la Modélisation IEC 61850 de Rte décrite dans [Rte-
Mod] (Cf. NT-RD-CNER-DCCL-SYS-15-00254) et les fichiers SCL associés.
MOD-01 Implémentation de la modélisation IEC 61850 de Rte RS-7237

Priorité : Phase 1 - Pilotes Modifiée le : 2021-11-17 Étiquette : RS1_V4
Version : 2.0 Version précédente : RS-4555 Version suivante :
Les fonctions de chaque IED correspondent à un ou à plusieurs LD de la modélisation IEC 61850 de Rte
(Cf. [Rte-Mod], NT-RD-CNER-DCCL-SYS-15-00254).
Chaque fonction doit être implémentée sur la base du modèle IEC 61850 de Rte avec les LD, LN & les DO
associés conformément au fichier SCL (Cf. [Rte-Conf]).
Les fichiers SCL associés donnent l’exhaustivité des données dans chaque LD/LN/DO/DA à implémenter. Les
règles d'instanciation des LD/LN/DO/DA sont données par les exigences de [Rte-Conf].
Remarque
Les liens entre les DO publiés et souscrits par chaque fonction sont précisés dans la spécification applicative
associée à chaque LD.
MOD-10 Codage des objets de type AnalogValue RS-4618

Version : 1.0 Version précédente : Version suivante :
Les valeurs analogiques représentées par des objets de type AnalogValue sont codées sur des flottants 32 bits
(Cf. §6.3 IEC 61850-7-3 : Attribute name = f et Attribute type = FLOAT32).
MOD-11 Unités des valeurs analogiques RS-6770

Les unités associées aux objets de type MV sont définies dans le fichier SCL de la modélisation IEC 61850 de
Rte [Rte-Mod] et devront être respectés (Cf. IEC 61850-6).
L'IED doit être conforme au traitement exigé par §6.3 de la norme IEC 61850-7-3 : "The value of f shall be the
floating point representation of the measured value. The formula to convert between f and the process value
shall be: pVal = f * 10^units.multiplier".
Remarque
Les SV conformes à la IEC 61869-9 ont un units.multiplier = 0.
Indice : 4.1 - Page : 6/39

MOD-12 La non-utilisation du DO GrRef RS-4965
Priorité : Phase 1 - Pilotes Modifiée le : 2021-11-02 Étiquette : RS1_DC2-3_modifié_round_2
La modélisation des fonctions Rte en IEC 61850 ne fait pas appel à une hiérarchie de LD (Nested LD de §8.2.5
de l'IEC 61850-7-1). En conséquence, le DO GrRef du LLN0 des LD n'est pas utilisé (§5.3.4 de l'IED 61850).
MOD-13 Utilisation de CmdBlk pour le blocage des commandes RS-7454

Si besoin, le blocage des commandes sur les objets commandables sera géré par LN. Le DO LNxxx/CmdBlk est
utilisé pour gérer la commandabilité de l'ensemble des objets commandables associé au LN (Cf. §7.7.2 de l'IEC
61850-7-1 et §6.2.2.8 de l'IEC 61850-7-4-Ed2.1).
Lorsque CmdBlk = true, toutes les commandes sur les objets commandables sont refusées (blocked by
command).
Remarque
Rte n'utilisera pas cet attribut pour les LN dont la commandabilité des objets est gérée par des DO dédiés à
ces LN (Ex. le LN CSWI qui utilise CSWIx/BlkOpn ou CSWIx/BlkOpn).
MOD-14 Implémentation "Process as Questionnable" RS-4968

Le traitement de "Process as Questionnable" (IEC 61850-7-4 Ed2.1 Annexe A) doit être implémenté pour
chacune des entrées des LD implémentés.
Le traitement de ces entrées ("Ignore", "Processed as Valid" ou "Processed as Invalid") est défini dans les BAP
associés.
Remarque
Extrait de IEC 61850-7-4 Ed2.1 Annexe A : "Processed as questionable” means that the application should
decide how to consider the status value.
Indice : 4.1 - Page : 7/39

MOD-15 Implémentation "Process as Invalid" RS-4969
La signification de "Process as invalid" (IEC 61850-7-4 Ed2.1 Annexe A) est définie pour chaque fonction dans
son BAP. (Colonne "Ignore").
MOD-20 Règles de nommages des LD RS-7431

La modélisation IEC 61850 de Rte décrit des LD génériques. Le nom des LD de la modélisation correspond à
l’attribut "inst" des objets "LDevice" de l’implémentation dans les IEDs (Cf. §9.3.4 de l'IEC 61850-6-Ed2.1 :
"inst = Identification of the LDevice within the IED. Its value cannot be the empty string. It is always used as key
part for references to logical devices within the SCL file".
Une fois configurés, leurs noms (attribut "ldName" des objects "LDevice") doivent respecter le product
naming tel que défini dans la norme (Cf. §8.5.3 de l'IEC 61850-6-Ed2.1) à savoir la concaténation sans
underscore de [IEDName] et [LDevice] :
 IEDName : tel que défini dans les règles de nommage des IED.
 LDevice : nom du LD dans la modélisation.
ExemplePALLU4ZBRANBCU1LDPX ou
 PALLU : code du poste PALLUAU
 4ZBRAN : identifiant de la tranche (4 : niveau de tension 90 kV)
MOD-21 Règles de nommage des IED RS-7432

Les règles de nommage suivantes sont applicables aux IED de l'écosystème (Ex. BCU, SAMU, SCU, TAC, PDL,
PDB, AUT, TCD, PO) pour la définition de l'attribut iedName.
Le nom de l’IED est importé par SCL et devra être configurable dans le champ des possibles de caractères et
de longueur tels que définis dans la norme IEC 61850.
Le nom de l'IED ne devra pas être interprété pour connaitre par exemple son type ou sa tranche
d'appartenance.
Exemples
 PALLU4ZBRANBCU1
 PALLU4CBO1SAMU1
 PALLU0TGSCU2
Indice : 4.1 - Page : 8/39

MOD-31 Règles de publication du DA Time Stamp RS-5164
Pour tous les DA TimeStamp (§6.1.2.9.3.3 de l'IEC 61850-7-2), les règles suivantes s'appliquent :
1. L'attribut TimeQuality doit être fourni de manière effective avec toutes ses composantes :
LeapSecondsKnown, ClockFailure, ClockNotSynchronized & TimeAccuracy. Les règles définies dans
§6.1.2.9.3.3 de l'IEC 61850-7-2 doivent être respectées.
2. La valeur du Timestamp doit être codée sur 24 bits, soit une résolution du champ de 60 ns. La
résolution de l'IED doit être au moins 1 µs qui correspond à la précision demandée dans RS-5025.
3. L'IED synchronisé hébergeant la fonction doit pouvoir fournir de manière effective la datation (taguage
temporel) de chaque changement d'état de chaque DO.
- ClockFailure = True en de dysfonctionnement de l'horloge interne de l'IED.
- ClockNotSynchronised = True est publié en cas de perte de la synchronisation externe de l'IED.
- TimeAccuracy reprend une des valeurs de Table 6 (Cf. 7.6.2.5 de l'IEC 61588) fournie par la source
de temps GMC du réseau LAN.
Indice : 4.1 - Page : 9/39

MOD-40 Traitement des attributs orCat et orIdent RS-7053
Priorité : Phase 1 - Hors Pilotes Modifiée le : 2021-12-14 Étiquette : RS1_V4
Les attributs origin.orCat et origin.orIdent sont définis dans la l’IEC 61850-7-2-Ed2.1 :
Exigence 1
Les DA origin (cas des DO avec un CDC de type SPC, DPC, INC, ENC, BSC, ISC) et originSrc (cas des DO avec un
CDC de type ACT) sont implémentés dans les DO où ils sont identifiés (Cf. SCL de la modélisation IEC 61850).
Exigence 2
Les attributs origin.orCat et origin.orIdent sont mis à jour suivant le schéma suivant applicable au LDCMDDJ :
Indice : 4.1 - Page : 10/39

Exigence 3
Sur réception d’une commande hors MMS (Ex. étape 4) sur un objet dont la position est acquise du procédé,
les attributs origin.orCat et origin.orIdent associés au DO reflétant la position de l'objet doivent prendre la
valeur de l'émetteur de la commande si un retour de position positif est acquis dans un délai de 30 secondes
après réception de la commande.
Autrement, le changement d’état sera considéré comme venant du process :

 pour les changements d’état consécutives à celui généré par la commande
OU
 pour les changements d’état qui ont lieu au-delà des 30 secondes consécutives à la réception de la
commande.
Le schéma suivant illustre le comportement attendu :
T0 T1 T1+30s
XCMD.OpCls
XCBR0.Pos (Cas 1)
orIdent = IV IV IV IV IV IV IV IV IV
XCBR0.Pos (Cas 2)
orIdent = IV IV SC SC SC SC SC SC SC
XCBR0.Pos (Cas 3)
orIdent = IV IV SC SC SC SC SC P P
XCBR0.Pos (Cas 4)
orIdent = IV IV SC P P P P P P
XCBR0.Pos (Cas 5)
orIdent = IV IV IV IV IV IV IV P P
IV Initial value
SC : Station-control (issue de XCMD0.OpCls)
P : Process
Une commande MMS sur un objet (de type [xxC]) dont la position est acquise du procédé (Ex. commande
secours) reste traitée conformément à l'IEC 61850-7-2 avec un délai de prise en compte défini dans l'attribut
operTimeout de l'objet commandable.
Indice : 4.1 - Page : 11/39

Exigence 4
Les valeurs de l'attribut origin.orCat sont définis dans l'IEC 61850-7-2 (Cf. §6.2.4.4).
Les commandes sont acceptées en fonction de l'émetteur avant d'être traitées conformément aux exigences
de prise en compte du mode d'exploitations quand elles en dépendent :
Émetteur non accepté Émetteur accepté Émetteur accepté
Quel que soit le mode [en mode distant] [en mode local]
0. Not supported 3. Remote-Control 2. Station-Control
1. Bay Control 6. Automatic-remote 5. Automatic-Station
8. Process
7. Maintenance
Remarques
 La valeur origin.orCat=4 (automatic-bay) n'est pas utilisée à cette phase du projet.
 Les attributs origin.orCat et origin.orIdent sont utilisés par Rte dans cette phase du projet dans le cas
d'une commande MMS. Ils ne sont pas utilisés pour les ordres de déclenchement de type ACT
(PTRC.Op, PTRC.Tr, PSCH.Op) issus des fonctions de protection (Bay-level).
Indice : 4.1 - Page : 12/39

MOD-50 Commandes : généralités et prérequis RS-7420
La gestion des commandes dans le système R#SPACE est transverse et impacte plusieurs IED.
Les schémas qui suivent illustrent l'implémentation des mécanismes de commandes qui impactent les
interfaces disjoncteurs, sectionneurs et MCB (Miniature Circuit Breaker). Ces mécanismes nécessitent :
 L'implémentation de la norme IEC 61850 pour les volets obligatoires (Mandatory).
 L'implémentation des exigences fonctionnelles au niveau des IED (Cf. exigences fonctionnelles)
 L'implémentation de la modélisation IEC 61850 de Rte jusqu'au niveau des DA (Cf. SCL de modélisation)
des LD impliqués dans la chaine de commande.
 L'implémentation des exigences qui suivent
MOD-51a Commandes : mécanisme de commande pour le disjoncteur RS-7421

Les schémas suivants illustrent des cas d'utilisation des mécanismes de commandes pour le disjoncteur :
Commande classique : enclenchement du disjoncteur depuis LDCMDDJ
Indice : 4.1 - Page : 13/39

Commande secours (directe) sur LDDJ
Ordre de déclenchement (triphasé) par une fonction ou un automate de protection (rappel du use
case qui n'est pas une commande)
Indice : 4.1 - Page : 14/39

MOD-51b Commandes : mécanisme de commande pour le sectionneur RS-7422
Les schémas suivants illustrent des cas d'utilisation des mécanismes de commandes pour le sectionneur :
Commande classique : depuis le BCU
Commande secours (directe) sur LDSxy
Remarque (exigence subsidiaire)

La temporisation associée à l'attribut LDSxy/XSWI1.Pos.pulseConfig est utilisée pour réinitialiser l'état des
attributs LDSxy/XCMD.OpOpn et LDSxy/XCMD.OpCls.
Indice : 4.1 - Page : 15/39

MOD-51c Commandes : mécanisme de commande pour les MCB RS-7423
Le schéma suivant illustre le cas d'utilisation du mécanisme de commandes pour les MCB (Mignature Circuit
Breaker) :
Remarque (exigence subsidiaire)

La temporisation associée à l'attribut LDITFUA/XCBRxx.Pos.pulseConfig est utilisée pour réinitialiser l'état des
attributs LDITFUA/XCMD.OpOpn et LDSxy/XCMD.OpCls.
Indice : 4.1 - Page : 16/39

MOD-52 Commandes : contrôle du mode d'exploitation pour les commandes MMS RS-7030
Sur réception d’une commande MMS sur un DO de type [xx]C (DPC, SPC, ENC, …), l’IED devra vérifier les
conditions suivantes :
Cas d'une commande indépendante du mode d'exploitation

La commande ne nécessite pas de vérification du mode d’exploitation site ou tranche (exemple : manœuvre
de secours du disjoncteur issue du PO, Mod des LN ou LD (LLN0.Mod, ...).
Cas d'une commande dépendante du mode d'exploitation

 Si la commande est listée dans le SCD tel que décrit dans [Rte-Conf],
ALORS
le contrôle du mode d’exploitation se fait en utilisant l’entrée applicative <mode d’exploitation
indépendant site> si celle-ci existe.
 Dans les autres cas,
Le contrôle du mode d’exploitation se fait en utilisant l’entrée applicative <mode d’exploitation>
Remarque
La dépendance de mode d'exploitation est définie pour chacune des commandes (au niveau des attributs de
type [xxC]) du fichier SCL de modélisation IEC 61850.
MOD-53 Commandes : contrôle de cohérence RS-7359

Sur réception d'une commande MMS sur un objet commandable : l'IED effectue un contrôle de cohérence sur
la valeur actuelle de l'objet.
 L'état inconnu (Ex. Pos.stVal=intermediate-state ou Pos.stVal=bad-state) ou non-valid (q.validity
différent de valid) n'est pas un motif de refus de commande.
 Un état déjà atteint est un motif de refus de commande, et le refus doit être conforme à RS-7163.
Remarques
 Pour les objets dont le retour n'est pas disponible (commande d'organe sans acquisition de la position
par exemple), une position calculée uniquement à partir des commandes précédentes ne doit pas être
considérée :
- Pour les attributs de type SPC : par configuration, le stVal ne sera pas instancié.
- Pour les attributs de type DPC : un control model "direct-with-normal-security" (Cf. §20.2 de l'IEC
61850-7-2) implique que la position n'est pas acquise.
 Dans le cas d'un ordre reçu en GOOSE, aucun contrôle de cohérence vis-à-vis de la valeur actuelle de
l'objet n'est réalisé.
Indice : 4.1 - Page : 17/39

MOD-54 Commandes : traitement des Add-Cause applicables à l'ensemble des IED RS-7163
Les AddCause (§20.5.2 de l'IEC 61850-7-2-Ed2.1) sont demandés pour les DO commandables afin d’identifier
la raison du refus de commande envoyé par un serveur (Ex. PO) au client (Ex. SCU, BCU....).
Parmi la liste définie par la norme (§6.2.4.5 de l'IEC 61850-7-2-Ed2.1 ou /20.11 de l'IEC 61850-8-1-Ed2.1), les
AddCause suivants sont demandés avec le comportement associé :
Pour l'ensemble des DO commandables (hors LLN0.Mod)

N° Libellé Traitement
Blocked-by-switching- Conforme à l'IEC 61850-7-2.
2
hierarchy Utilisé quand la commande dépend du mode d'exploitation.
8 Blocked-by-Mode Conforme à l'IEC 61850-7-2.
Command-already-in-
12 Conforme à l'IEC 61850-7-2.
execution
13 Blocked-by-health Conforme à l'IEC 61850-7-2.
Conforme à l'IEC 61850-7-2.
20 No-access-authority Traitement spécifique en lien avec le RBAC non-demandé en absence de
sécurisation des flux MMS.
25 None Conforme à l'IEC 61850-7-2.
Il n'est pas demandé de bloquer la commande dans ce cas.
26 Inconsistent-parameters Néanmoins cette incohérence doit être journalisée dans l'IED (Syslog).
Utilisation à minima de l'attribut ctlVal.
Pour les DO avec control Model = direct control with enhanced security (avec un DA stVal)
N° Libellé Commentaire
RS-7025 Commande ordinaire (DJ)
5 Position-reached RS-7195 Commande ordinaire (Sxy)
RS-7026 Commande d'enclenchement forcé
16 Time-limit-over RS-7195 Commande ordinaire (Sxy)
Indice : 4.1 - Page : 18/39

AddCause demandés dans LDCMDDJ et LDCMDSxy
Les AddCause suivants sont utilisés dans le BCU avec des exigences spécifiques (Cf. LDCMDDJ et LDCMDSxy
dans [Rte-BCU]) :
4 Invalid-position RS-7038 AIVO invalide (DJ et Sxy)
RS-7024 Ordres d'ouverture/fermeture
RS-7025 Traitement des commandes ordinaires venant de la conduite
9 Blocked-by-process
RS-7026 Traitement de la commande d'enclenchement forcé
RS-7195 Traitement des commandes ordinaires venant de la conduite
10 Blocked-by-interlocking RS-6929 Refus AIVO (DJ et Sxy)
11 Blocked-by-synchrocheck
AddCause demandés dans le LDDJ

Les AddCause suivants sont utilisés dans le
9 Blocked-by-process RS-6934 Traitement du LDDJ à la réception de l'information de Baisse pression SF6 2e stade
Remarques
 Les autres AddCause peuvent être implémentés mais ne seront pas exploités par Rte.
 L'information de défaut interne du disjoncteur (LDDJ/XCBR0.EEHealth) n'est pas un motif de refus de
commande par LDDJ et n'est donc pas associée à l'AddCause "Blocked-by-process" (contrairement à
l'exemple donné dans §6.2.4.5 de l'IEC 61850-7-2-Ed2.1).
Indice : 4.1 - Page : 19/39

3. COM - Communication et services IEC 61850 dans R#SPACE
Version 2.0
Versions précédentes RS-4609
Cette partie décrit les exigences à respecter pour l'interface de communication IEC 61850 des IEDs du système
R#SPACE.
COM-01 Instanciation des Control Block GOOSE et Report RS-4610

Priorité : Phase 1 - Pilotes Modifiée le : 2021-11-02 Étiquette : BCU RS1_V3 SAMU SCU
Les Control Block liés à la communication (GOOSE, Report) sont configurés par LD au sein du LLN0. Pour
chaque fonction, les règles suivantes sont à respecter:
Report Control Block

Tous les Report Control block seront instanciés avec les champs TrgOps (trigger options) suivants (§12.3.3.3
de l'IEC 61850-7-2) :
 dchg : data-change
 qchg : quality-change
 integrity : avec une période définie par l'attribut IntgPd (cette option est généralement utilisée pour les
besoins de télémesure).
 general-interrogation : 'GI = TRUE' pour une interrogation générale à chaque connexion Client-Serveur.
Remarque :
L'utilisation de 'data-update' (dupd) (§17.2.2.9 de l'IEC 61850-7-2) est exclue pour certaines report
(commandes, ..) mais peut être utilisée pour ne pas perdre des informations au CDE ou journal de bord.
GOOSE Control Block

Chaque fonction (LD) doit pouvoir être configurée avec au maximum trois GOOSE Control Blocks.
Le nom du Control Block et la totalité de ses paramètres doivent être configurables par import SCL.
COM-02 Instanciation des SV Control Block RS-4611

Priorité : Phase 1 - Pilotes Modifiée le : 2021-09-15 Étiquette : RS1_V3 SAMU
Les Control Block liés à la publication/souscription des SV sont instanciés par LD au sein du LLN0 de ce LD.
Pour chaque fonction, les règles suivantes sont à respecter:
 Pour chaque LD, trois SV Control Blocks doivent pouvoir être définis.
 Le nom du SV Control Block et la totalité de ses paramètres doivent pouvoir être configurables par
import SCL.
Indice : 4.1 - Page : 20/39

Remarque
Les SV Control Block sont instanciés dans les IED publiant des flux SV, par exemple les SAMU et les MU.
COM-03 Souscription aux GOOSE RS-4612

Priorité : Phase 1 - Pilotes Modifiée le : 2021-11-02 Étiquette : BCU RS1_V3 SCU
La souscription aux GOOSE doit se faire par combinaison de ' goID' (GOOSE identifier, §18.2.1.4 de l'IEC
61850-7-2) et de l'adresse Multicast de destination.
Les différents attributs permettant de garder une chronologie dans les messages doivent être utilisés pour
détecter les anomalies de réception, en particulier à l'aide des valeurs 'StNum' (state number, compteur
incrémenté du dernier changement d'état dans la GOOSE) et 'SqNum' (sequence number, compteur
incrémenté au dernier envoi d'une GOOSE).
La GOOSE reçue est traitée en INVALIDE si un des cas suivants se produit:

 StNum inférieur au StNum de la GOOSE précédente.
 SqNum égale ou inférieure au SqNum de la GOOSE précédente avec la même StNum.
Remarque
Les règles d'adressage de l'adresse Multicast doivent être explicitées. De préférence, le traitement du filtrage
des adresses MAC (Media Access Control) doit suivre les recommandations de l'annexe B (§Table B.1) de l'IEC
61850-8-1.
COM-04 Souscription aux SV RS-4613

Priorité : Phase 1 - Pilotes Modifiée le : 2021-11-02 Étiquette : BCU RS1_V2
La souscription des SV doit se faire par combinaison de 'MsvID' (multicast sampled value identifier, §19.2.1.4
de l'IEC 61850-7-2) et de l'adresse Multicast de destination.
Remarque
De préférence, le traitement du filtrage des adresses MAC (Media Access Control) doit suivre les
recommandations de l'annexe B (§Table B.1) de l'IEC 61850-8-1.
Indice : 4.1 - Page : 21/39

COM-05 Configurabilité du champs GSEControl Block RS-4614
Les exigences suivantes sont à respecter pour les plages des GOOSE Control Block (Cf. §12.4 de la IEC 61850-
90-4) :
 MAC adress : les adresses MAC doivent pouvoir être configurées dans la plage maximale admise par la
norme.
 APPID : doit pouvoir être configuré dans la plage maximale admise par la norme.
 VLAN Prio : doit pouvoir être configurée dans la plage maximale admise par la norme.
 VLAN ID : doit pouvoir être configurée dans la plage maximale admise par la norme.
 GoID : doit pouvoir être configurée dans la plage maximale admise par la norme.
 GoCBName : doit pouvoir être configurée dans la plage maximale admise par la norme.
 Les MinTime doivent pouvoir être dans la plage [1 ms, 10 000 ms].
 Les MaxTime doivent pouvoir être dans la plage [1 ms, 60 000 ms].
L'ensemble de ces valeurs doit être configurable par import de fichier SCL.
COM-06 Plages des SV Control Block RS-4616

Les exigences suivantes sont à respecter pour les plages des SV Control Block (SVCB) (Cf. §12.4 de la IEC
61850-90-4) :
 MAC adress : doit pouvoir être configurée dans la plage maximale admise par la norme.
 APPID : doit pouvoir être configuré dans la plage maximale admise par la norme.
 VLAN Prio : doit pouvoir être configurée dans la plage maximale admise par la norme.
 VLAN ID : doit pouvoir être configurée dans la plage maximale admise par la norme.
 SVID : doit pouvoir être configurée dans la plage maximale admise par la norme.
 SVCBName : doit pouvoir être configurée dans la plage maximale admise par la norme.
COM-07 Configurabilité de l'attribut GSE Control Block RS-4615

Les exigences suivantes sont à respecter pour les plages des GSE Control Block (Cf. Table 27 de l'IEC 61850-6).
 name : doit pouvoir être configurée dans la plage maximale admise par la norme.
 desc : doit pouvoir être configurée dans la plage maximale admise par la norme.
 datSet : doit pouvoir être configurée dans la plage maximale admise par la norme.
 confRev : doit pouvoir être configurée dans la plage maximale admise par la norme.
 type : doit toujours avoir la valeur "GOOSE".
 appId : doit pouvoir être configurée dans la plage maximale admise par la norme.
Nota
GSE Control Block est utilisé pour la configuration des GOOSE.
Indice : 4.1 - Page : 22/39

COM-08 Configurabilité du Champs SV Control Block (SVCB) RS-4617
Sauf si une plage réduite est acceptée dans la spécification particulière des IED concernés, les exigences
suivantes sont à respecter pour les plages des Sampled Value Control Block (Cf. Table 29 de l'IEC 61850-6).
 Name: doit pouvoir être configurée dans la plage maximale admise par la norme.
 desc : doit pouvoir être configurée dans la plage maximale admise par la norme.
 DatSet : doit pouvoir être configurée dans la plage maximale admise par la norme.
 ConfRev : doit pouvoir être configurée dans la plage maximale admise par la norme.
 smvID : doit pouvoir être configurée dans la plage maximale admise par la norme.
 multicast : est toujours fixé à TRUE.
 SmpRate : doit pouvoir être configurée dans la plage demandée dans [Rte-SAMU]. A défaut : plage
maximale admise par la norme (cf. IEC 61869-9 et IEC 61850-9-2).
 nofASDU : doit pouvoir être configurée dans la plage demandée dans [Rte-SAMU]. A défaut: plage
maximale admise par la norme (cf. IEC 61869-9 et IEC 61850-9-2).
COM-10 Services de communication IEC 61850 RS-7249

Les services de communication IEC 61850 sont à implémenter dans les différents types d'IED conformément
aux exigences de [Rte-Conf].
COM-11 DataSet RS-4665

Les exigences suivantes sont applicables aux DataSet:

1. Au moins 5 DataSet par LD sont requis. Les DataSet à prévoir sont les suivants :
- GOOSE IaT : GOOSE Intra-tranches n'ayant pas vocation d'être souscrits par une fonction en dehors
de la tranche fonctionnelle à laquelle appartient le LD.
- GOOSE InT : GOOSE Inter-tranches devant être souscrits par des LD appartenant à d'autres
tranches fonctionnelles.
- GOOSE V : GOOSE verticaux ayant vocation à être souscrites par une fonction appartenant au
fonds de poste (Tranche Générale, Automate de poste, autres automates...).
- REPORT PO : Reports souscrits par le PO.
- REPORT GTW : Reports souscrits par la GTW.
- Par ailleurs, pour les SAMU/MU, les dataset relatifs au SV sont requis [Cf. Rte-SAMU].
2. Le nom 'name' des DataSet est configurable dans la plage complète autorisée par la norme.
3. La description 'desc' des DataSet est configurable dans la plage complète autorisée par la norme.
4. Les DataSet sont constitués uniquement de 'FCDA' pour les GOOSE et 'FCD' pour les Report.
5. Les DataSet sont instanciés uniquement dans les LLN0 des LD auxquels elles appartiennent.
Indice : 4.1 - Page : 23/39

COM-12 Substitution et Blocage RS-7369
Les attributs subEna, subQ et subID sont demandés pour les attributs pour lesquels la substitution est
demandée (PresCond=MFsubst).
La substitution de l’attribut ‘q’ est réalisé pour l’ensemble du vecteur : [validity ; detailQual ; source ; test ;
operatorBlocked] avec l’application de §D.3 de l’IEC 61850-7-2-Ed2.1 : « If source is in the “substitute” state,
then validity shall be overruled by the definition of the substituted value ».
Le besoin de substitution concerne les DO (quand ils sont requis dans le modèle IEC 61850) dont les CDC sont
listés ci-dessous (Cf. §7.2.4 de l’IEC 61850-7-3-Ed2.1) :
Besoin de Valeurs Valeur de Utilisation

CDC Commentaires
substitution substituées substitution BlkEna
ENS, ENC Oui stVal et q subVal et subQ Non
SPS, SPC Oui stVal et q subVal et subQ Non
INS, INC Oui stVal et q subVal et subQ Non
DPS, DPC Oui stVal et q subVal et subQ Non
MV Oui instMag et q subMag et subQ Oui
CMV Oui instCVal et q subCVal et subQ Oui
BSC, ISC Oui valWTr et q subVal et subQ Non
APC Non mxVal et q Non demandé Non
BAC Oui mxVal et q subVal et subQ Non
Composé de plusieurs CMV. Substitution
DEL, HDEL Oui (par CMV) Voir CMV Voir CMV Non
au niveau des CMV qui le compose.
WYE, Composé de plusieurs CMV. Substitution
Oui (par CMV) Voir CMV Voir CMV Non
HWYE au niveau des CMV qui le compose.
SEQ Oui (par CMV) Voir CMV Voir CMV Non
HMV Oui (par CMV) Voir CMV Voir CMV Non
Remarques
 Les DA relatifs à la substitution sont identifiés dans les fichiers SCL décrivant la modélisation Rte (Cf.
[Rte-Conf]).
 Les DO indiqués « Mandatory but not used » dans le référentiel de configuration (fichiers SCL) de Rte
n'auront pas besoin d'être substituables.
 La substitution n'est pas traitée quand les échanges ont lieu entre LD du même IED.
 Les BAP utilisent les entrées avec une qualité quand elle est substituée.
Indice : 4.1 - Page : 24/39

COM-16 Constitution des DataSet RS-7427
Toutes les données publiées dans les GOOSE et Report sont systématiquement accompagnées par leurs
Attributs qualité 'q' et timestamp 't'.
Toutes les données publiées dans des DO commandables (CDC, SPC, DPC, ENC...) sont systématiquement
accompagnées par les DA 'OpRcvd', 'OpOk' et 'tOpOk'.
Remarque
Les DA relatifs sont identifiés dans les fichiers SCL de modélisation demandée par Rte (Cf. [Rte-Mod]).
COM-20 Capacité d'émission et de réception des IED RS-7368

La capacité d'émission et de réception demandée pour les interfaces IEC 61850 des IED est décrite de manière
détaillée dans le référentiel de configuration avec la liste des services requis par IED.
Indice : 4.1 - Page : 25/39

4. LAN.IED - Exigences du réseau LAN applicables aux IED
Identifiant RS-7243 Etiquette RS1_V3 RS1_V4
Version 2.0
Version précédentes RS-5015
Cette partie décrit les exigences liées au réseau LAN (Local Area Network) des IED du système R#SPACE. Elle
couvre les exigences liées aux réseaux :
 LAN CC : réseau de contrôle commande sur lequel les échanges entre IED du système sont réalisés (par
GOOSE, SV, Report MMS...).
 LAN Admin : réseau d'administration de l'IED. Les exigences fonctionnelles d'administration des IED
sont décrites dans [Rte-Admin].
LAN-01 Interface de l'IED compatible avec un réseau PRP RS-7242

L'interface LAN CC de l'IED doit être compatible avec une interface réseau redondée PRP (Parallel Redundancy
Protocol défini dans l'IEC 62439-3). Il est constitué de deux réseaux indépendants A et B, de topologie
identique ou non, et peut être implémenté avec des équipements de différents fournisseurs.
Ce réseau permet donc, de manière transparente, de palier à une défaillance simple, qui peut être :
 Panne de switch (commutateur)
 Panne de lien physique (Ex. fibre optique)
 Panne d’interface de communication (physique ou logique).
LAN-03a Interface des équipements terminaux permanents (Cible phase 1) RS-5019

Priorité : Phase 1 - Hors Pilotes Modifiée le : 2021-11-02 Étiquette : BCU RS1_V3 SAMU SCU
Les interfaces réseau des équipements terminaux permanents (dont les IED SAMU, SCU, BCU) sont des
interfaces fibres optiques connectées sur des modules SFP génériques 1000-Base LX 1310 monomode.
La connectique est de type LC, donc détrompée (coté IED comme coté Switch) sans besoin d’atténuateurs.
Remarque
Les fibres monomode doivent suivre les recommandations de G.652-2016 de l'UIT-T.
Indice : 4.1 - Page : 26/39

LAN-03b Interface des équipements terminaux permanents (acceptables pour la RS-6516
phase pilote)
Les interfaces réseau des équipements terminaux permanents acceptables pour la phase pilote sont des
interfaces fibres optique connectés sur module SFP générique de type :
 1000-Base SX : 850 nm multimode
 1000-Base LX : 1310 nm monomode
La connectique est de type LC, donc détrompée (coté IED comme coté Switch) sans besoin d’atténuateurs.
Remarque
 L'interface 100-Base FX (1300 multimode) est acceptable pour les SAMU et les SCU pour la phase pilote.
 Les fibres monomode doivent suivre les recommandations de G.652-2016 de l'UIT-T.
LAN-10a Principes de configuration et filtrage : LAN CC RS-7244

Dans R#SPACE, pour des raisons de stabilité et de contrôle des flux d'informations échangés au sein du
système, les flux Multicast de type GOOSE/SV (couche 2 du modèle OSI) seront filtrés.
Ces paquets sont, de par le standard, directement identifiables dans le réseau via leur adresse MAC et leur
VLAN ID. De ce fait, les IED doivent pouvoir traiter les VLAN ID et les adresses MAC.
Remarque
Le mécanisme du VLAN (Virtual LAN) sera utilisé pour construire un ensemble de réseaux logiques dans le LAN
CC. Ces réseaux permettront d’empêcher la diffusion de flux Multicast (Ex. GOOSE) vers des interfaces qui ne
les supportent pas où qui n'en ont pas besoin pour leur fonctionnement.
Voici un exemple de configuration (parmi d'autres) qui pourrait être utilisé par Rte :
 Pour les GOOSE :
- 1 VLAN par tranche : destiné à limiter la diffusion des GOOSE émises et reçu au sein d'une même
tranche
- 1 VLAN pour les flux verticaux : destiné à restreindre la diffusion des GOOSE émises et reçues entre
les tranches et les automates/protections de poste/site
 Pour les SV :
- 1 VLAN par tranche
- 1 VLAN dédié à la fonction de Protection Différentielle de Barres (PDB).
 Pour les MMS et autres flux IP (hors administration) :
- 1 VLAN
 Pour le PTP :
- 1 VLAN
Indice : 4.1 - Page : 27/39

LAN-10b Principes de configuration et filtrage : LAN Admin RS-7247
Priorité : Phase 1 - Hors Pilotes Modifiée le : 2021-11-02 Étiquette : BCU RS1_V4 SAMU SCU
L’administration de l'IED doit se faire via un port dédié à l'administration. Dans ce cas, l'administration de
l'IED doit pouvoir se faire depuis ce port et de manière exclusive (Cf. [Rte-Cyber]). Les flux d'administration
sont transportés dans un VLAN dédié, le marquage (VLAN ID) étant réalisé par l'IED.
L'administration de l'IED depuis le port LAN CC doit être bloquée nativement ou doit pouvoir être bloquée par
l'administrateur.
LAN-20 Représentation de la chaine de fonctionnement SAMU->BPU->SCU RS-7245

La chaine fonctionnelle SAMU + BPU+ SCU + Switchs est modélisée de la manière suivante :
Le temps de fonctionnement global T

T = tps + tmu + tst + tp + tsc
Chaine TC/TT + SAMU

 tps : délai lié au temps de propagation dans le réducteur de mesure
 tmu : délai de réception, de traitement et de publication de la SAMU/MU
Les exigences liées à cette partie sont définies dans RS-5855.
Remarques
 Le délai inclut le temps de retard maximal de traitement (tpd) défini dans le §6.902.2 de la
norme IEC 61869-9:2016
 D'après la norme IEC 61869-9 : tmu ≤ 2 ms
BCU, BPU (Bay Protection Unit) ou tout IED hébergeant une fonction du système
 tp1 : temps de réception, bufférisation, traitement des SV, des GOOSE... par un LD du BCU ou d'une
BPU.
 tp2 : temps de traitement de l'algorithme de protection et de publications du LD du BCU ou d'une BPU
(GOOSE de déclenchement...)
 tp = tp1 + tp2
Les exigences liées à cette partie sont définies par fonction (se reporter aux exigences associées).
SCU
 tsc1 : délai de réception et de décodage du SCU.
 tsc2 : temps de traitement du SCU qui inclut le temps d'action de la sortie (polarisation et action du
relais auxiliaire).
 tsc = tsc1+ tsc2
Les exigences liées à cette partie sont définies dans RS-5855.
Indice : 4.1 - Page : 28/39

Switch
 tst : retard total lié au délai entre la réception et l'émission au niveau de l'ensemble des n switchs de la
chaine. (tst = tst1 + tst2 + ... + tstn)
LAN-21 Temps de fonctionnement des IED RS-7246

Les performances demandées au niveau des IED sont les suivants :

Temporisation Performance requise IED
Temps réel entre un événement ayant lieu sur le primaire et ses
tps < 500 µs -
résultats à la sortie (voir §3.4.601 de l'IEC 61869-6)
tmu < 2 ms SAMU Voir §6.902.2 de la l'IEC 61869-9
tst < 1 ms Switch Périmètre du LAN Rte (hors périmètre des lots 2 & 3)
tsc < 2 ms SCU Conformément aux exigences du [Rte-SCU]
tp - BPU Défini par LD (Ex. LDPX, LDPDB, LDPMC...)
Les contraintes sur les temps de fonctionnement imposent la réduction des valeurs des temporisations tp et
tsc. Pour cela, le temps de transfert d'information (Transfer time défini dans §11.1.1.4 de l'IEC 61850-5) doit
être de classe TT6 (Table 1 de l'IEC 61850-5).
Remarque
Afin de respecter les performances globales, les exigences de la temporisation tp (BPU) prennent en compte
les délais au niveau de chacun des IED de la chaîne. Ces exigences sont définies par LD.
Par exemple, l'exigence sur le temps de déclenchement sur un défaut triphasé sur un réseau THT de la
fonction de distance est de 20 ms (temps de la chaine globale entre l'apparition du défaut et le changement
d'état du relais de sortie). En conséquence, l'exigence sur le temps de déclenchement sur un défaut triphasé
en zone 1 de la fonction LDPX est de 15 ms (temps de fonctionnement entre l'acquisition des SV par le BCU et
l'envoi de la GOOSE de déclenchement).
Indice : 4.1 - Page : 29/39

5. SYNC.IED - Exigences de Synchronisation applicables aux IED
Identifiant RS-6855 Etiquette RS1_V4
Version 2.0
Cette partie décrit les exigences relatives au système de synchronisation par le LAN du système R#SPACE et le
comportement attendu des différents IEDs suivant l'état de synchronisation du système.
Deux architectures de synchronisation sont envisagées dans le cadre de R#SPACE :
Postes avec une horloge serveur PTP associée à une source GNSS
Dans ce cas, l'attribut ClockClass caractérise l'état de synchronisation (§Table 5 de la norme IEC 61588-Ed2) :
 ClockClass=6 : si l'horloge est synchronisée par sa référence de temps primaire.
 ClockClass=7 : si l'horloge est synchronisée initialement par la source primaire mais a perdu sa source
de synchronisation tout en restant dans son domaine de maintien de la précision de synchronisation
(Holdover Mode).
Postes avec une horloge serveur PTP associée à une source NTP (depuis INUIT)
Cette architecture assure une synchronisation locale de niveau poste et est suffisante pour les fonctions qui
ne nécessitent pas de synchronisation avec d'autres IED d'autres postes (Ex. Protection Différentielle de
Liaison) ou de synchronisation absolue avec l'UTC (Ex. fonction PMU).
Dans ce cas, l'attribut ClockClass caractérise l'état de synchronisation avec des valeurs qui dépendent de
l'implémentation des constructeurs d'horloge. Cet attribut peut alors prendre les valeurs 6 ou 7 ou des valeurs
différentes.
Dans les deux cas, les attributs qui caractérisent la synchronisation sont publiés conformément à l'IEC 61588-
Ed2 :
 priority1
 priority2
 clockClass
 clockAccuracy
 timeSource
 offsetScaledLogVariance
 numberPorts
Indice : 4.1 - Page : 30/39

SYNC-10 Client Synchronisation R#SPACE PTP RS-5025
Les IED du système R#SPACE doivent être compatibles avec la norme de synchronisation PTP (IEC 61855-
Ed.2) avec le profil de synchronisation défini dans la norme IEC 61850-9-3-Ed.1. À ce titre:
 Les IEDs MU, SAMU et tous IED de protection différentielle doivent pouvoir se synchroniser en PTP
avec une classe de précision T5 (Cf. Table 2 & 3 de l'IEC 61850-5) soit une précision de 1 µs.
 Les IED BCU et les autres IED protections doivent pouvoir se synchroniser avec une classe de précision
T1 ou supérieur (Cf. Table 2 & 3 de l'IEC 61850-5) soit une précision de 1 ms.
 Les IED SCU doit pouvoir se synchroniser avec une classe de précision T2 ou supérieur (Cf. Table 2 & 3
de l'IEC 61850-5) soit une précision de 100 µs.
Cette synchronisation est à assurer quand la qualité du signal PTP le permet sur la base du cadre défini le §7
de la norme IEC 61850-9-3).
Remarque
L'exigence SYNC-16 (RS-5913) est applicable pour la datation. À ce titre, la datation à la source (interface
procédé) doit être le plus précis possible pour l'acquisition des valeurs analogiques (MU / SAMU). Les
protections, qui souscrivent aux SV doivent utiliser la datation de celles-ci et n'ont donc pas besoin, à leur
tour, d'être synchronisées avec la même précision.
SYNC-11 Comportement des IED en fonction de l'état de synchronisation RS-7177

Les IED traitement les attributs suivants en fonction de l'état de synchronisation de l'IED
 TimeQuality.ClockFailure pour tous les IED (§6.2.3.8 de l’IEC 61850-7-2-Ed2.1).
 TimeQuality.ClockNotSynchronized pour tous les IED
 TimeQuality.TimeAccuracy pour tous les IED
 SmpSynch pour la SAMU
Indice : 4.1 - Page : 31/39

Comporteme
N° Scénarios État des attributs annoncés à l'IED Comportement tout IED
nt SAMU
clockQuality.clockClass = 6 ou 7 ClockFailure=FALSE
Comportement nominal avec
1 ET ClockNotSycnhronized=FALSE SmpSynch=2
source GNSS
clockQuality.timeSource =10 ou 20 TimeAccuracy=n
Comportement nominal sans
source GNSS
(avec source primaire NTP
clockQuality.timeSource > 20 TimeAccuracy=n
uniquement)
Comportement dégradé :
perte de la source GNSS
(avec maintien de la source
clockQuality.timeSource > 20 TimeAccuracy=n
primaire NTP)
Comportement dégradé :
perte de toute source
primaire ([GNSS+NTP] OU ClockFailure=FALSE
4 NTP) clockQuality.clockClass > 7 ClockNotSycnhronized=FALSE SmpSynch=1
Le GMC reste synchronisé TimeAccuracy=n
par son oscillateur interne
(au-delà de son holdover)
Comportement dégradé : ClockFailure=TRUE
5 dégradation de l’oscillateur Non-prise en compte ClockNotSycnhronized=TRUE SmpSynch=0
interne de l'IED TimeAccuracy=n
Non-réception des paquets SmpSynch = 1
ClockFailure=FALSE
PTP ou 2
6 Non-connue ClockNotSycnhronized=FALSE
(pendant le Holdover de suivant l'état
TimeAccuracy=n
l'IED) initial
Non-réception des paquets
ClockFailure=FALSE (ou TRUE)
PTP
7 Non-connue ClockNotSycnhronized=TRUE SmpSynch=0
(au-delà du Holdover de
TimeAccuracy=n
l'IED)
Remarques
 Scénario 4 : correspond aussi à clockQuality.timeSource = A0 mais ne doit pas être pris en compte par
l'IED.
 Scénario 6 : l'attribut du SmpSynch doit garder sa valeur initiale calculée avant la perte des paquets PTP
et ce pendant toute la durée du Holdover.
 Scénario 7 : le choix du traitement de l'attribut ClockFailure=FALSE dans ce scénario permet de
distinguer la défaillance liée à ce scénario de celle du scénario 5. La norme précise que cet attribut
reflète la confiance accordée à la valeur du Timestamp (Cf. §6.2.3.8 de l'IEC 61850-7-2). Le traitement
de cet attribut est laissé libre au constructeur.
 Le TimeAccuracy est calculé suivant l'IEC 61850-7-2-Ed2.1.
Indice : 4.1 - Page : 32/39

SYNC-15 Durée du Holdover RS-7178
Lors d'un événement de type "perte des paquets PTP reçus", l'IED doit pouvoir rester dans sa classe de
précision sur son oscillateur interne pendant une durée d'au moins 5 secondes à iso-température Cf. §6.904.5
de la norme IEC 61869-9 et §7.6.3 de l'IEC 61850-9-3-Ed1). Pendant ce temps, la valeur publiée du DO
SmpSync n'est pas modifiée.
SYNC-16 Règles de publication des Time Stamp : regroupement et datation de la source RS-5913
Priorité : Phase 1 - Pilotes Modifiée le : 2021-11-02 Étiquette : RS1_DC2-3_modifié_round_2
La publication des Time Stamp doit suivre les règles définies dans la norme IEC 61850-5 (§11.1.1.2, 11.1.1.3 &
11.1.1.4). Les règles suivantes doivent être prises en compte :
 Datation des DO élaborés par un LD : sur référence horaire interne de l'IED (quel que soit son état de
synchronisation).
 Datation des DO résultant d’un regroupement (fonction logique) : datation du dernier changement
constaté sur les données.
Le Time Stamp du regroupement est le même que celui de la dernière donnée ayant changé d'état
(corrigé suivant le §11.1.1.3 de l'IEC 61850-5)
 Datation des DO résultant d’une publication MMS des GOOSE souscrits : la datation reprend la datation
du GOOSE souscrit (datation de la source).
Remarque
Tout traitement différent de ces principes sera précisé dans la spécification associé au LD.
SYNC-17 Comportement d'un client PTP en cas de retour au fonctionnement nominal RS-7433
En cas de reboot ou mise sous tension (Cf. [Rte-Admin]), l'IED doit retrouver sa synchronisation en fonction de
l'état de synchronisation sur le réseau LAN et conformément au §7 de la norme IEC 61850-9-3) au plus tard
une minute après récupération de son état de fonctionnement nominal.
Indice : 4.1 - Page : 33/39

6. LLN0.QUAL - Traitement des DO Mod/Beh/Sim/Health du LLN0 et des
attributs de 'qualité'
Version 2.0
Dans cette partie, on décrit les comportements attendus des IED compatibles IEC 61850 Ed2.1 en mode non-
nominal (ex. réception et émission d'informations avec qualité invalide "q=invalid") et l'implémentation des
modes IEC 61850 prévus par la norme pour la testabilité des IEDs.
HEALTH-01 Règles de publication du DO LLN0.Health des LD RS-4556

Les règles suivantes sont à appliquer pour l'établissement de la valeur publiée du LLN0.Health :
 LLN0.Health = 1 (OK) : la fonction est opérationnelle.
 LLN0.Health = 2 (Warning) : la fonction est opérationnelle, mais fonctionne en mode dégradé (e.g.
indisponibilité d'une ou plusieurs entrées qui peuvent être ignorées (cf. BAP). Le constructeur doit
détailler les situations conduisant à ce comportement en dehors des cas spécifiés.
 LLN0.Health = 3 (Alarm) : la fonction est bloquée ou non-opérationnelle (problème hardware,
problème logiciel, problème d'exécution de l'algorithme de la fonction, indisponibilité d'une ou
plusieurs entrées essentielles...)
Le DO LLN0.Health publié par une fonction prend les valeurs 2 (Warning) ou 3 (Alarm) uniquement en cas
d'impact avéré ou supposé sur la fonction.
Si plusieurs critères conduisent à publier un DO Health dégradé, c'est le problème le plus sévère qui est pris
en compte pour en déterminer la valeur publié (logique "OU").
Remarques
1. Ce traitement est appliqué également au LDSUIED. Le LDSUIED/LLN0.Health n'est pas un groupement
des LLN0.Health des LD de l'IED.
2. En fonction de la nature du critère qui conduit à afficher un Health détérioré (=2 ou 3) de l'IED, il peut
n'y avoir aucun impact sur certaines fonctions. Par exemple, une panne de carte d'acquisition TOR n'a
pas forcément un impact sur toutes les fonctions implémentées dans le SCU.
HEALTH-02 Valeur du DO LLN0.Health d'un LD quand LPHD0.PhyHealth = 3 RS-7234

Le LN LPHD est instancié au niveau du LDSUIED mais aussi dans chacun des LD d'un IED.
Quand LDSUIED/LPHD0.PhyHealth=3 (Alarm), les DO LDxxx/LLN0.Health des LD instanciés dans l'IED
prennent aussi la valeur 3.
Les règles de publication des valeurs du LDSUIED/LPHD0.PhyHealth sont décrites dans la fonction GENE-IED.
Indice : 4.1 - Page : 34/39

HEALTH-03 Règles de publication du LDxxx/LLN0.Health sur défaut matériel RS-7012
En complément de l'exigence générique qui couvre le traitement du LDSUIED/LPHD0.PhyHealth, l'exigence

suivante traite le cas des IED disposant d'une interface d'entrées/sorties (E/S) physiques.
En cas de défaillance d'un module d'E/S, tout LD dont le fonctionnement est lié à ce module doit passer à
LDxxx/LLN0.Health=3 (Alarm).
Ce fonctionnement doit être dynamique en fonction de la configuration instanciée et donc du câblage défini
par RTE dans le fichier SCD (Cf. [Rte-Conf]).
Exemple
Pour le LDDJ dont :
 Les positions sont câblées sur le module N°3 (module d'entrées binaires).
 Les déclenchements/enclenchement sur le module N°1 (module de sorties binaires).
Si le module N°3 passe en défaut (suite à une défaillance physique), le LDDJ/LLN0.Health=3 bien que la
fonction de déclenchement pourrait rester disponible. En effet, la défaillance du module d'Entrée empêche la
fonction associée au LDDJ de traiter la position des organes.
LDSUIED-40 Règles de publication du DO LDSUIED/LPHD0.PhyHealth des IED RS-7235

L'équipement doit surveiller en permanence son fonctionnement interne et signaler un défaut matériel
suivant les règles suivantes :
 En fonctionnement normal, l'IED publie un LDSUIED/LPHD0.PhyHealth = 1 (OK)
 En cas de panne d'un élément sans impact fonctionnel sur tous les LD instanciés (Ex. problème de
LED...etc), l'IED publie un LDSUIED/LPHD0.PhyHealth = 2 (Warning).
En complément, les DO publiés par le LDSUIED (voir [Rte-Mod]) doivent indiquer l'élément défaillant.
 En cas de panne avec impact fonctionnel sur tous les LD hébergés dans l'IED (Ex. carte d'alimentation ou
CPU), et si l'interface de communication de l'IED est encore en capacité d’émettre, il publie un
LDSUIED/LPHD0.PhyHealth = 3 (Alarm).
Remarques
 La philosophie sous-jacante est de publier :
- LDSUIED/LPHD0.PhyHealth = 3 (Alarm) pour un problème affectant toutes les LD hébergés par
l’IED
- LDSUIED/LPHD0.PhyHealth = 2 (Warning) pour un problème n’affectant qu’une partie ou aucune
des fonctions hébergées.
 Cette philosophie permet d'éviter de passer le LDxxx/LLN0.Health d'une fonction à 3 (alarm)
(conséquence du passage de LDSUIED/LPHD0.PhyHealth à 3) alors que la fonction est toujours
opérationnelle malgé la défaillance matérielle.
 La cible de R#SPACE est d'utiliser uniquement le LN LDSUIED/LPHD0 mais nécessite l'introduction de la
hiérarchisation des LD (Cf. §8.2.5 de l'IEC 61850-7-1-Ed2.1). Ceci n'étant pas prévu dans le cadre de la
phase 1, tous les LD d'un IED sont considérés comme des root LD et le DO LDxxx/LPHD0.PhyHealth est
instancié dans chacun des LD bien qu'ils ne soient pas utilisés par Rte. Concernant leur animation, ils
pourraient hériter de l'état du LDSUIED/LPHD0.
Indice : 4.1 - Page : 35/39

MOD.BEH.SIM-01 Implémentation des attributs du DO Mod (on, test, test/blocked...) RS-7367

Chaque fonction du système, implémentée dans un LD, doit pouvoir bénéficier des fonctionnalités du DO
LLN0.Mod défini dans la norme IEC 61850 (IEC 61850-7-1-Ed2.1, IEC 61850-7-4-Ed2.1, IEC 61850-10-Ed2...).
Chacun des DO LDxxx/LLN0.Mod des LD de l'IED doit être contrôlable et doit supporter la liste complète des
possibilités offertes par la norme, ainsi que les comportements normés associés, définis par l'IEC 61850-7-4-
Ed2.1 (Cf. §7.2.5, Table 213) :
 on
 blocked (applicable aux IED avec E/S physiques)
 test
 test/blocked (applicable aux IED avec E/S physiques)
 off
Ainsi, le mode TEST est implémenté au niveau de chaque LD de l'IED.
Remarque
Les exigences de chaque IED peuvent compléter cette exigence en indiquant le traitement groupé des
LLN0.Mod de certains LD pour lesquels le mode reste toujours identique (pas de passage en mode test
individuel).
MOD.BEH.SIM-02a Implémentation du DO Beh et le lien avec les LDSUIED/LLN0 RS-6930

Chacun des DO LDxxx/LLN0.Beh des LD du l'IED doit supporter la liste complète des possibilités offertes par la
norme IEC 61850, ainsi que les comportements normés associés, définis par l'IEC 61850-7-4-Ed2.1 (Cf. §7.2.5,
Table 213) :
 on
 blocked (applicable aux IED avec E/S physiques)
 test
 test/blocked (applicable aux IED avec E/S physiques)
 off
L'implémentation du ce DO est faite conformément à l'IEC 61850-7-4-Ed2.1 (Cf. §7.1, Table 209), sachant que
LDSUIED est considéré comme un root LD au niveau de chaque IED.
Indice : 4.1 - Page : 36/39

Pour les LLN0.Beh :
 La valeur du DO LDSUIED/LLN0.Beh est celle du LDSUIED/LLN0.Mod (Cf. IEC 61850-7-4, §7.1 : For a root
logical device, it is the same as the mode 'LLN0.Mod').
 La valeur du LDxxx/LLN0.Beh est une combinaison de (Cf. IEC 61850-7-4, §7.1 : For non-root logical
device, it depends on its own current operating mode ('LLN0.Mod'), and the current operating
behaviour of the logical device that contains it (containing 'LLN0.Beh')) :
- LDSUIED/LLN0.Beh
- LDxxx/LLN0.Mod
Pour les LNxxx.Beh :

La valeur du LDxxx/LNxxx.Beh est une combinaison de (Cf. IEC 61850-7-4, §7.2.5)) :
 LDxxx/LLN0.Beh
 LDxxx/LNxxx.Mod (quand celui-ci est instancié)
Remarques
 Ceci permet, entre autres, de passer simultanément tous les LD d'un IED en mode Test.
 Les modes "blocked" et "test-blocked" ont un impact sur les interfaces procédé d'un LD. En
conséquence, pour les LD qui ne contiennent pas une interface procédé, le comportement en mode
"blocked" est identique à celui en mode "on" et le comportement en mode "test/blocked" et identique
à celui en mode "test".
 Voici un exemple qui illustre le comportement demandé par la norme (en absence d'un root LD,
LDSUIED), on change la valeur de LDxxx/LLN0.Mod :
 Voici un exemple qui illustre le comportement attendu (en absence d'un root LD, LDSUIED), on change
la valeur de LDSUIED/LLN0.Mod :
MOD.BEH.SIM-02b Comportement de LD implémentés dans le même IED RS-6441

Les LD implémentés dans le même IED respectent le comportement défini en annexe a de la norme IEC
61850-7-4 en fonction des DA test et q aussi pour les informations qu'il souscrit et qui sont publiées par un LD
instancié dans le même IED.
Si ces données ne sont pas échangés via l'interface de communication IEC 61850 mais via un bus de données
interne à l'IED, ce bus de données doit également transmettre ces DA pour prise en compte par le LD abonné.
Indice : 4.1 - Page : 37/39

MOD.BEH.SIM-03 Traitement des DO LN.Mod et LD.Mod pour le mode TEST RS-5346
Information: Le fonctionnement des modes de test IEC 61850 est défini entre autres par l'annexe A de la
norme IEC 61850-7-4. Cette annexe seule ne permet pas de définir le comportement attendu d'une
fonction de façon précise.
Exigences : les règles suivantes s'appliquent pour R#SPACE

 “Processes as valid” : traitement normale de l'information d'entrée
 “Processes as invalid” : traitement de l'information suivant les spécifications des BAP identiquement au
cas où cette donnée d'entrée arrivent avec une qualité "invalid". Dans le tableau des BAP cela
correspond au cas INVALID + other.
 “Processes as questionnable” : traitement de l'information suivant les spécifications des BAP
identiquement au cas où cette donnée d'entrée arrivent avec une qualité "questionnable". Dans le
tableau des BAP cela correspond au cas QUESTIONNABLE + other.
MOD.BEH.SIM-04 Implémentation du mode SIM RS-5347

Le LN LDSUIED/LPHD0 est instancié dans chaque IED afin de gérer la supervision physique et le
comportement global de l'IED.
Ce LN, contient le DO LDSUIED/LPHD0.Sim et doit être implémenté conformément au §7.8 de la norme IEC
61850-7-1 Ed.2. Ainsi, l'IED doit se comporter conformément au §6.2.4.16.1 de la norme IEC 61850-10-Ed2 &
§7.8.1 de la norme IEC 61850-10-Ed2 :
 Lorsque le DO LDSUIED/LPHD.Sim=TRUE, l'IED identifie les GOOSE et les SV avec le bit Sim=TRUE. A
l'apparition d'un flux GOOSE ou SV avec le bit Sim=TRUE (identique à un flux déjà souscrit), L'IED utilise
ce flux comme flux d'entrée. Les flux SV et GOOSE avec bit Sim=FALSE sont ignorés à partir de cet
instant. Les flux n'ayant pas changé l'état du bit Sim (restés avec LPHD.Sim=FALSE) continuent à être
traités normalement.
 Lorsque le DO LDSUIED/LPHD.Sim=FALSE, les flux GOOSE et SV avec le bit Sim=TRUE sont ignorés à
partir de cet instant. Seuls les flux GOOSE et SV avec bit Sim=FALSE sont traités.
Il doit être possible d'utiliser le mode SIM

 avec un LD en mode "on" ou "on-blocked"
 avec un LD en mode "test ou "Test-blocked"
Remarques
 Aucun IED du système, autre que les équipements de test IEC 61850, ne doit générer de trame avec le
flag Sim=TRUE. Cela s'applique aussi aux SAMU qui publient des trames de test générés par elles.
 La combinaison des différents modes TEST et SIM de l'IEC 61850 dans le Système R#SPACE sera mise en
œuvre à travers des outils dédiés et des procédures particulières ultérieurement.
 Les commandes reçues par l'IED sont traités indépendamment du mode SIM de l'IED.
Indice : 4.1 - Page : 38/39

QUALITY-01a Implémentation des DA 'q' (Quality) et 't' (Timestamp) RS-7238
Tout DO implémenté doit associer à son DA portant l’information les DA suivants :

 t (Timestamp) avec ses attributs (Cf. 6.2.3.7 de l'IEC 61850-7-2)
 q (Quality) avec ses attributs (Cf. 6.2.3.9 de l'IEC 61850-7-2).
Cela concerne par exemple les DA :
 stVal pour les CDC de type SPS, DPS, INS, ENS, ACT, ENS, VSS, SPC, DPC, INC, ENC...
 general, phsA, phsB et phsC pour les CDC de type ACT, ACD...
 mag et instMag pour les CDC de type MV.
 cVal er instCVal pour les CDC de type CMV.
La liste exhaustive est fournie dans les fichiers SCL de la modélisation IEC 61850 qui englobent dans chaque LD
modélisé les LN, DO et DA requis.
Remarque
Cette exigence est demandée même si ce le DA portant l'information n'est pas obligatoire (Mandatory)
dans l'IEC 61850-7-3.
QUALITY-01b Implémentation du DA 'q' dans les DataSet RS-7239

La configuration des DataSet (Cf. 9.3.7 de l'IEC 61850-6-Ed2.1) se fera systématiquement avec l'intégration
des attributs de qualité associées à chaque DO (Data Object) conformément aux exigences de [Rte-Conf].
Remarques
 Même si certaines applications / fonctions ne nécessitent pas l'utilisation de la qualité associée aux
informations auxquelles elles sont abonnées, la qualité restera présente dans les communications.
 Le traitement de la qualité et le comportement associé sont réalisés au niveau de la fonction abonnée.
QUALITY-02 Traitement des DA 'q' conformément aux BAP RS-7240

Le traitement des informations de qualité des DO souscrits par un LD est décrit via les fichiers BAP (Basic
Application Profile) pour chaque fonction associée à un LD (Cf. GENE-IED).
Chaque BAP définit pour un LD donné l'interprétation des informations de qualité des attributs auxquels il est
abonné (via entrée applicative) et leur interprétation :
 Traitement comme une entrée valide
 Ignorer la valeur de l'attribut
 Blocage de la fonction (LDxxx/LLN0.Health=Alarm)
L'implémentation dans les IEDs doit donc respecter ces profiles sans restriction.
Indice : 4.1 - Page : 39/39

Par ailleurs, tous les attributs du vecteur qualité (validity, detaillQual, source, test et operatorBlocked) doivent
être implémentés (attributs Mandatory dans l'IEC-61850-7-2-Ed2.1).
Remarques
 Les BAP sont à implémenter dans les IED et ne nécessitent pas d'être configurables.
 Il n'est pas demandé de vérifier la cohérence des attributs de qualité auxquels la fonction souscrit
(correspondance entre q.detailQual et q.validity conformément (§D.1 de l'IEC 61850-7-2-Ed2.1). Chacun
des attributs de qualité est considéré par la fonction qui y souscrit indépendamment des autres
attributs.
 En cas de plusieurs attributs actifs avec un traitement différencié du BAP, c'est le cas le plus défavorable
qui s'applique.
Exemple : si DOxxx.q.validity=questionnable avec un BAP qui prévoit de la considérer comme valide et
DOxxx.q.OldData=true avec un BAP qui prévoit de bloquer la fonction, c'est le blocage de la fonction
qui est appliqué.
QUALITY-03 Lien entre qualité et supervision des IED RS-7241

Pour les besoin de supervision du fonctionnement des IED, les informations du type :
 Health (LNxxx.Health, LLN0.Health)
 EEHealth (LNxxx.EEHealth).
 PhyHealth (LDSUIED/LPHD.PhyHealth)
sont requises et doivent refléter la capacité d'opération de la fonction (Cf. [Rte-Admin]).
Ils doivent tenir compte, outre l'état matériel (HW) de l'IED dans laquelle la fonction est hébergée :
 des causes conduisant à la publication de DA qualité non-nominaux (autre que q.validity=true).
 des informations associées aux attributs de qualité de la fonction ou de l'IED qui l'héberge (Cf. BAP).
QUALITY-04 Prise en compte du LLN0.Health dans le traitement de l'attribut 'q' RS-7225

Tout attribut publié par un LD doit prendre en compte l'état de l'attribut LLN0.Health du LD :
 Si LDxxx/LLN0.Health = 1 (Ok) : pas d'impact sur 'q'
 Si LDxxx/LLN0.Health = 2 (Warning) : pas d'impact direct sur 'q'
 Si LDxxx/LLN0.Health = 3 (Alarm) : les DO du LD sont publiés avec q.validity=invalid.
FIN DU DOCUMENT

(Rte-Com) NT-DI-CNER-DCCL-SYS-18-00287-Ind.4.1 RSPACE Exigences D'implémentation IEC 61850

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-Com) NT-DI-CNER-DCCL-SYS-18-00287-Ind.4.1 RSPACE Exigences D'implémentation IEC 61850

Transféré par

Droits d'auteur :

Formats disponibles

Date d’approbation :

R#SPACE – Lot 23 Tranche

Documents annulés : NT-DI-CNER-DCCL-18-00287-Ind.4

Accessibilité : Filières : Domaine GED :

Centre National Expertise Réseaux

R#SPACE – Lot 23 Tranche

Volker LEITLOFF Volker LEITLOFF Timothée MICHEL

Signé par : CN2I Michaut Xavier

Signé par : MACHKOUR Tarik

Lieu de conservation (ou...) : DOKI

R#SPACE – Lot 23 Tranche

R#SPACE – Lot 23 Tranche

R#SPACE – Lot 23 Tranche

MOD-01 Implémentation de la modélisation IEC 61850 de Rte RS-7237

MOD-10 Codage des objets de type AnalogValue RS-4618

MOD-11 Unités des valeurs analogiques RS-6770

R#SPACE – Lot 23 Tranche

MOD-13 Utilisation de CmdBlk pour le blocage des commandes RS-7454

MOD-14 Implémentation "Process as Questionnable" RS-4968

R#SPACE – Lot 23 Tranche

MOD-20 Règles de nommages des LD RS-7431

MOD-21 Règles de nommage des IED RS-7432

R#SPACE – Lot 23 Tranche

R#SPACE – Lot 23 Tranche

Les attributs origin.orCat et origin.orIdent sont définis dans la l’IEC 61850-7-2-Ed2.1 :

R#SPACE – Lot 23 Tranche

Autrement, le changement d’état sera considéré comme venant du process :

R#SPACE – Lot 23 Tranche

R#SPACE – Lot 23 Tranche

MOD-51a Commandes : mécanisme de commande pour le disjoncteur RS-7421

Commande classique : enclenchement du disjoncteur depuis LDCMDDJ

R#SPACE – Lot 23 Tranche

R#SPACE – Lot 23 Tranche

Commande classique : depuis le BCU

Commande secours (directe) sur LDSxy

Remarque (exigence subsidiaire)

R#SPACE – Lot 23 Tranche

Remarque (exigence subsidiaire)

R#SPACE – Lot 23 Tranche

Cas d'une commande indépendante du mode d'exploitation

Cas d'une commande dépendante du mode d'exploitation

MOD-53 Commandes : contrôle de cohérence RS-7359

R#SPACE – Lot 23 Tranche

Pour l'ensemble des DO commandables (hors LLN0.Mod)

R#SPACE – Lot 23 Tranche

AddCause demandés dans le LDDJ

R#SPACE – Lot 23 Tranche

COM-01 Instanciation des Control Block GOOSE et Report RS-4610

Report Control Block

GOOSE Control Block

COM-02 Instanciation des SV Control Block RS-4611

R#SPACE – Lot 23 Tranche

COM-03 Souscription aux GOOSE RS-4612

La GOOSE reçue est traitée en INVALIDE si un des cas suivants se produit:

COM-04 Souscription aux SV RS-4613

R#SPACE – Lot 23 Tranche

COM-06 Plages des SV Control Block RS-4616

COM-07 Configurabilité de l'attribut GSE Control Block RS-4615

R#SPACE – Lot 23 Tranche

COM-10 Services de communication IEC 61850 RS-7249

COM-11 DataSet RS-4665

Les exigences suivantes sont applicables aux DataSet:

R#SPACE – Lot 23 Tranche