IEC 61850-10:2012/AMD1:2025

IEC 61850-10 ®
Edition 2.0 2025-07
NORME
INTERNATIONALE
AMENDEMENT 1
Réseaux et systèmes de communication pour l'automatisation des systèmes
électriques -
Partie 10: Essais de conformité
ICS 33.200  ISBN 978-2-8327-0566-7

IEC 61850-10:2012-12/AMD1:2025-07(fr)

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC -  IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
dans 25 langues additionnelles. Egalement appelé
Published détaille les nouvelles publications parues.
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.

Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
____________
Réseaux et systèmes de communication pour
l’automatisation des systèmes électriques -
Partie 10: Essais de conformité

AMENDEMENT 1
AVANT-PROPOS
1) La Commission Électrotechnique Internationale (IEC) est une organisation mondiale de normalisation composée
de l’ensemble des comités électrotechniques nationaux (Comités nationaux de l’IEC). L’IEC a pour objet de
favoriser la coopération internationale pour toutes les questions de normalisation dans les domaines de
l’électricité et de l’électronique. À cet effet, l’IEC – entre autres activités – publie des Normes internationales,
des Spécifications techniques, des Rapports techniques, des Spécifications accessibles au public (PAS) et des
Guides (ci-après dénommés "Publication(s) de l’IEC"). Leur élaboration est confiée à des comités d’études, aux
travaux desquels tout Comité national intéressé par le sujet traité peut participer. Les organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l’IEC, participent également aux
travaux. L’IEC collabore étroitement avec l’Organisation Internationale de Normalisation (ISO), selon des
conditions fixées par accord entre les deux organisations.
2) Les décisions ou accords officiels de l’IEC concernant les questions techniques représentent, dans la mesure du
possible, un accord international sur les sujets étudiés, étant donné que les Comités nationaux de l’IEC intéressés
sont représentés dans chaque comité d’études.
3) Les Publications de l’IEC se présentent sous la forme de recommandations internationales et sont agréées
comme telles par les Comités nationaux de l’IEC. Tous les efforts raisonnables sont entrepris afin que l’IEC
s’assure de l’exactitude du contenu technique de ses publications; l’IEC ne peut pas être tenue responsable de
l’éventuelle mauvaise utilisation ou interprétation qui en est faite par un quelconque utilisateur final.
4) Dans le but d’encourager l’uniformité internationale, les Comités nationaux de l’IEC s’engagent, dans toute la
mesure possible, à appliquer de façon transparente les Publications de l’IEC dans leurs publications nationales
et régionales. Toutes divergences entre toutes Publications de l’IEC et toutes publications nationales ou
régionales correspondantes doivent être indiquées en termes clairs dans ces dernières.
5) L’IEC elle-même ne fournit aucune attestation de conformité. Des organismes de certification indépendants
fournissent des services d’évaluation de conformité et, dans certains secteurs, accèdent aux marques de
conformité de l’IEC. L’IEC n’est responsable d’aucun des services effectués par les organismes de certification
indépendants.
6) Tous les utilisateurs doivent s’assurer qu’ils sont en possession de la dernière édition de cette publication.
7) Aucune responsabilité ne doit être imputée à l’IEC, à ses administrateurs, employés, auxiliaires ou mandataires,
y compris ses experts particuliers et les membres de ses comités d’études et des Comités nationaux de l’IEC,
pour tout préjudice causé en cas de dommages corporels et matériels, ou de tout autre dommage de quelque
nature que ce soit, directe ou indirecte, ou pour supporter les coûts (y compris les frais de justice) et les dépenses
découlant de la publication ou de l’utilisation de cette Publication de l’IEC ou de toute autre Publication de l’IEC,
ou au crédit qui lui est accordé.
8) L’attention est attirée sur les références normatives citées dans cette publication. L’utilisation de publications
référencées est obligatoire pour une application correcte de la présente publication.
9) L’IEC attire l’attention sur le fait que la mise en application du présent document peut entraîner l’utilisation d’un
ou de plusieurs brevets. L’IEC ne prend pas position quant à la preuve, à la validité et à l’applicabilité de tout
droit de brevet revendiqué à cet égard. À la date de publication du présent document, l’IEC n’avait pas reçu
notification qu’un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois, il y a lieu
d’avertir les responsables de la mise en application du présent document que des informations plus récentes
sont susceptibles de figurer dans la base de données de brevets, disponible à l’adresse https://patents.iec.ch
[et/ou] www.iso.org/brevets. L’IEC ne saurait être tenue pour responsable de ne pas avoir identifié de tels droits
de brevet.
L’Amendement 1 à l’IEC 61850-10 a été établi par le comité d’études 57 de l’IEC: Gestion des
systèmes de puissance et échanges d’informations associés.
Les modifications majeures du présent amendement sont les suivantes:
– les procédures d’essai de conformité du serveur ont été actualisées; les nouveaux cas
d’essai sont les suivants: sAss4, sAss5, sAssN7, sSrv14, sSrv15, sDs15, sSg11.sSg14,
sRp15, sRp16, sRp17, sRp23, sRpN9, sBr29, sBrN9, sBrN10, sGop12, sGos8.15,
sGos20.23, sGosN7, sSBOns8, sTm6, sTm7, sTmP1, sTmP2, sTmP5, sTmPN1;
– les procédures d’essai de conformité du système client ont été actualisées; les nouveaux
cas d’essai sont les suivants: cAss10, cAssN8, cAssN9, cSrv10, cSrvN7.cSrvN9, cSg46,
cRp14.22, cRp40.46, cBr14.22, cBr30.32, cBr46, cLog9, cLog46, cLogN4, cGcb46,
cSBOns10, cFt16, cMsvcb1, cMsvcb2, cMsvcb46;
– les procédures d’essai des valeurs échantillonnées ont été fusionnées dans le serveur;
– les procédures d’essai de conformité relatives à l’outil de configuration d’IED du serveur ont
été actualisées; les cas d’essai d’exportation du fichier ICD et d’importation du fichier SCD
ont été fusionnées dans le serveur, les nouveaux cas d’essai sont les suivants: tTf4, tTf5;
– les procédures d’essai de conformité relatives à l’outil de configuration système ont été
actualisées; les nouveaux cas d’essai sont les suivants: tSieN2, tSce8.10, tSceN2, tDfeN3,
tSmo7.9, tSse4.7, tSsi5.6, tSeh7.11;
– les procédures d’essai de performances GOOSE ont été actualisées; les classes de
performances ont été actualisées pour s’aligner sur les mises à jour de définitions de classe
de performances.
Le texte de cet Amendement est issu des documents suivants:
Projet Rapport de vote
57/2769/FDIS 57/2797/RVD
Le rapport de vote indiqué dans le tableau ci-dessus donne toute information sur le vote ayant
abouti à son approbation.
La langue employée pour l’élaboration de cet Amendement est l’anglais.
Ce document a été rédigé selon les Directives ISO/IEC, Partie 2, il a été développé selon les
Directives ISO/IEC, Partie 1 et les Directives ISO/IEC, Supplément IEC, disponibles sous
www.iec.ch/members_experts/refdocs/. Les principaux types de documents développés par
l’IEC sont décrits plus en détail sous www.iec.ch/publications/.
Une liste de toutes les parties de la série IEC 61850, publiées sous le titre général Réseaux et
systèmes de communication pour l’automatisation des systèmes électriques, se trouve sur le
site Web de l’IEC.
Le comité a décidé que le contenu de ce document ne sera pas modifié avant la date de stabilité
indiquée sur le site web de l’IEC sous webstore.iec.ch dans les données relatives au document
recherché. À cette date, le document sera:
• reconduit,
• supprimé, ou
• révisé.
___________
1 Domaine d’application
Ajouter le nouveau texte suivant après le premier alinéa du Domaine d’application (avant la
NOTE):
Les extensions de cybersécurité fournies par l’IEC 62351 sont soumises à un essai de
conformité par rapport à l’IEC 62351-100-4 et à l’IEC 62351-100-6.
2 Références normatives
Insérer les nouvelles références normatives suivantes:
IEC/IEEE 61850-9-3:2016, Communication networks and systems for power utility automation
– Part 9-3: Precision time protocol profile for power utility (disponible en anglais seulement)
IEC 61869-9:2016, Transformateurs de mesure – Partie 9: Interface numérique des
transformateurs de mesure
Supprimer les références normatives existantes suivantes:
IEC 62439-3:2012, Réseaux industriels de communication – Réseaux d’automatisme à haute
disponibilité – Partie 3: Protocole de redondance en parallèle (PRP) et redondance
transparente de haute disponibilité (HSR)
4 Abréviations
Insérer le nouveau terme abrégé suivant:
PTP Precision Time Protocol (protocole PTP)
6 Essais de conformité associés au dispositif
Remplacer le texte, les figures (Figures 2 à 6) et les tableaux (Tableaux 1 à 71) existants de
l’Article 6 par les nouveaux textes, figures et tableaux suivants:
6.1 Méthodologie d’essai
Les essais de communication nécessitent au moins deux dispositifs destinés à communiquer
entre eux. Des essais d’interopérabilité complets de tous les produits potentiels ne sont pas
réalisables. Par conséquent, le concept d’essai doit inclure les dispositifs, configurations et
scénarii d’essai. Il convient de vérifier par essai, et dans des conditions appropriées, le
comportement dynamique en utilisant des cas d’essai bien définis.
Des messages sont générés pour soumettre à essai les capacités de communication. Il
convient d’utiliser, le cas échéant, des stimuli câblés (contacts, tensions, courants, etc.) et des
stimuli par liaison série, le cas échéant.
Une attention particulière doit être accordée aux équipements de communication tels que
coupleurs en étoile, commutateurs, etc., qui doivent prendre en charge toutes les
caractéristiques sollicitées de la norme, tout en excluant les contingences et limites
supplémentaires. Les procédures d’essai doivent tenir particulièrement compte de l’influence
de la méthode de communication (client-serveur, GOOSE, SV, etc.) utilisée par le DEE. La
vérification des applications fonctionnelles (utilisation de messages GOOSE) ne fait pas partie
intégrante d’un essai de conformité même si des outils de pointe peuvent proposer ce type
d’analyse.
6.2 Procédures d’essai de conformité
6.2.1 Généralités
Le présent paragraphe décrit les exigences relatives aux procédures d’essai, la structure
d’essai et les cas d’essai abstraits (objet à soumettre à l’essai). Le format et quelques exemples
de procédures d’essai détaillées (méthode de réalisation de l’essai) sont donnés à l’Annexe A.
6.2.2 Exigences relatives aux procédures d’essai
Les exigences relatives aux procédures d’essai sont les suivantes:
– les cas d’essai abstraits décrivent le ou les objets qui doivent être soumis à essai et les
procédures d’essai détaillées décrivent de quelle manière un ingénieur ou un système
d’essai doit réaliser les essais;
– les cas d’essai comportent une référence à l’alinéa ou aux alinéas applicables du ou des
documents référencés;
– les résultats d’essai doivent être reproductibles dans le même laboratoire d’essai et dans
d’autres laboratoires;
– prise en charge d’essais automatisés avec intervention humaine minimale, dans toute la
mesure du possible;
– les essais doivent se concentrer sur les situations ne pouvant pas facilement faire l’objet
d’une vérification par essai au cours, par exemple, d’un essai de réception en usine ou sur
site, et éviter les risques liés à l’interopérabilité, par exemple:
• vérifier le comportement du dispositif dans le cas de paquets retardés, perdus, en double
exemplaire ou défectueux;
• risques liés à la configuration, à la mise en œuvre et au fonctionnement;
• non-concordance des noms, paramètres, réglages ou types de données;
• dépassement de certaines limites, plages ou temporisations;
• forcer les situations pour vérifier par essai les réponses négatives;
• vérifier tous les chemins de diagramme d’états (de commande); et
• forcer les opérations de commande simultanées de clients multiples;
– les essais ACSI se concentrent sur la couche application (mise en correspondance);
– le dispositif en essai (DEE) est considéré comme une boîte noire. L’interface E/S et
l’interface de communication sont utilisées pour les essais;
– les essais incluent la vérification des versions, du modèle de données et du fichier de
configuration, ainsi que l’emploi de la terminologie de la série ISO/IEC 9646 applicable.
Les procédures d’essai doivent être formatées comme indiqué à la Figure 2. Dans le cadre de
ce format, le document relatif aux procédures d’essai peut également être utilisé comme rapport
d’essai. Quelques exemples de procédures d’essai sont représentés à l’Annexe A.
Figure 2 – Format de procédures d’essai
6.2.3 Structure d’essai
Les cas d’essai sont structurés comme suit:
– documentation et contrôle de version (IEC 61850-4);
– fichier de configuration (IEC 61850-6);
– modèle de données (IEC 61850-7-3 et IEC 61850-7-4);
– mise en correspondance des modèles et services ACSI (IEC 61850-7-2 et SCSM
applicable).
6.2.4 Cas d’essai pour la vérification d’un dispositif serveur
6.2.4.1 Généralités
La présente partie de la série IEC 61850 spécifie l’architecture du système d’essai et des cas
d’essai abstraits pour les dispositifs serveurs. Les cas d’essai abstraits doivent être utilisés
pour définir des procédures d’essai permettant de réaliser des essais.
NOTE Les procédures d’essai spécifiques au SCSM sont fournies par les laboratoires d’essai choisis en commun
par les participants au marché.
6.2.4.2 Architecture du système d’essai pour la vérification d’un dispositif serveur
La réalisation d’un essai de dispositif serveur nécessite une installation d’essai minimale.
L’architecture d’essai comporte les éléments suivants (voir Figure 3):
– DEE;
– simulateur client pour initier et générer les messages TPAA;
– simulateur GOOSE pour transmettre les messages GOOSE corrects et incorrects;
– simulateur SV pour transmettre les messages SV corrects et incorrects;
– responsable d’essai pour démarrer/arrêter le cas d’essai, démarrer/arrêter l’analyseur et
archiver les résultats d’essai;
– base de référence de temps;
– outil d’ingénierie pour configurer le DEE;
– analyseur de protocole pour stocker toutes les données de trafic du réseau pour chaque
cas d’essai;
– générateur de signal pour forcer des événements binaires et analogiques, commandé par
le responsable d’essai ou l’ingénieur d’essai.

Figure 3 – Architecture du système d’essai pour la vérification d’un dispositif serveur
Le système d’essai doit comprendre la documentation relative au matériel et au logiciel du
système d’essai.
6.2.4.3 Présentation générale de la procédure d’essai de commande de
documentation et de version
Les cas d’essai énumérés dans le Tableau 1 doivent s’appliquer.
Tableau 1 – Cas d’essai de documentation du serveur
Cas Description des cas d’essai
d’essai
Vérifier si la version logicielle principale/secondaire indiquée dans la documentation de la PICS et
le DEE correspondent (IEC 61850-4). La PICS doit comporter:
• la déclaration de conformité ACSI conformément à l’IEC 61850-7-2:2010, Annexe A;
sDoc1
• la PICS de l’IEC 61850-9-3 (si prise en charge);
• la classe de conformité a, b, c ou d (si prise en charge) de l’IEC 61869-9.
Vérifier si la version logicielle principale/secondaire indiquée dans la documentation PIXIT et la
sDoc2 version logicielle du DEE correspondent (IEC 61850-4). Les PIXIT doivent indiquer les
informations exigées comme le sollicitent les cas d’essai
Vérifier si la version logicielle principale/secondaire indiquée dans la documentation MICS et la
version logicielle du DEE correspondent (IEC 61850-4). La MICS doit indiquer la sémantique de
sDoc3 tous les nœuds logiques, objets de données, attributs et énumérations de données non
normalisés. La MICS peut contenir d’autres éléments dans des sections supplémentaires du
MICS.
Vérifier si la version logicielle principale/secondaire indiquée dans la documentation TICS et la
sDoc4 version logicielle du DEE correspondent (IEC 61850-4). La TICS doit indiquer que les questions
techniques obligatoires et applicables sont mises en œuvre.
Vérifier l’ICD si les capacités du serveur dans la ou les sections "services IED" correspondent aux
sDoc5
services ACSI spécifiés dans la PICS.

6.2.4.4 Cas d’essai pour le fichier de configuration
Les cas d’essai énumérés dans le Tableau 2 doivent s’appliquer.
Tableau 2 – Cas d’essai pour le fichier de configuration du serveur
Cas Description des cas d’essai
d’essai
sCnf1 Vérifier la version SCL = "2007", révision = "B", release = "4"
sCnf2 Vérifier que le codage XML est UTF-8 ou utf-8;
sCnf3 Vérifier que l’ICD valide selon le schéma SCL: version 2007, révision B, version 4
sCnf4 Utiliser l’outil ICT pour exporter un fichier ICD. Si l’ICD n’est pas pris en charge, exporter le fichier
IID. Utiliser ce fichier pour les essais restants. Il n’est pas autorisé de modifier ce fichier SCL avec
des outils d’usage général tels qu’un éditeur XML.
Condition: lorsque l’ICD n’est pas fixe
sCnf5
Importer le fichier ICD ou IID de sCnf4 dans SCT SIMULATOR et générer le fichier SCD comme suit:
• mettre à jour l’appellation IED;
• modifier l’adresse IP/MAC;
• modifier l’appellation SubNetwork;
• ajouter l’appellation DataSet (si prise en charge);
• ajouter l’appellation ReportControl (si prise en charge);
• ajouter l’appellation GSEControl (si prise en charge);
• ajouter l’appellation SampledValueControl (si prise en charge);
• ajouter des flux de données (ExtRef) provenant d’autres IED (si noIctBinding=F).
Importer le fichier SCD dans l’outil ICT et sélectionner l’IED à traiter à partir des IED désignés dans
le fichier SCD par l’appellation IED
Cas Description des cas d’essai
d’essai
sCnf6 Compléter le GOOSE et SV subscribe de sCnf5 et exporter le fichier IID. Vérifier que l’ExtRef intAddr
ne change pas lorsque la liaison externe change. Il convient qu’intAddr ne contienne pas de données
externes.
Condition: lorsque GOOSE et/ou SV subscribe est pris en charge
sCnf10 Vérifier que l’ICD a au plus un poste ou une ligne ou un processus existe au niveau SCL et que
l’attribut "name" est "TEMPLATE".
Condition: lorsqu’un poste, une ligne ou une section de processus est présent
sCnf11 Vérifier que l’ICD n’a aucun LNode lié à un IED différent de "TEMPLATE" ou "none"
Condition: lorsqu’un poste est présent
sCnf20 Vérifier que l’élément "Communication" existe:
• IED/Services/DynAssociation ou IED/AccessPoint/Services/DynAssociation est déclaré) et
IED/AccessPoint/Server est déclaré; ou
• l’élément LN0/GSEControl existe; ou
• l’élément LN0/SampledValueControl existe
sCnf21 Pour chaque ConnectedAP/Address element:
vérifier qu’exactement un élément "P" avec le type d’attribut ="OSI-PSEL" avec une valeur valide
(non vide, nombre pair de caractères, maximum 16 caractères 0 à 9, A à F);
vérifier qu’exactement un élément "P" avec le type d’attribut ="OSI-SSEL" avec une valeur valide
(non vide, nombre pair de caractères, maximum 16 caractères 0 à 9, A à F);
vérifier qu’exactement un élément "P" avec le type d’attribut ="OSI-TSEL" avec une valeur valide
(non vide, nombre pair de caractères, maximum 8 caractères 0 à 9, A à F)
(noter que si le mécanisme xsi:type est utilisé, le validateur de schéma peut automatiquement vérifier
le type).
Condition: IED/Services/DynAssociation est déclaré
sCnf22 Vérifier qu’il n’existe pas plus d’un élément "P" avec type d’attribut="OSI-AP-Title" et "OSI-AE-
Qualifier et "IP" et "IP-SUBNET", "IP-GATEWAY", OSI-NSAP, OSI-AP-Invoke, OSI-AE-Invoke et
DNSName pour chaque point d’accès. Pour chacun d’entre eux qui existe:
vérifier que la valeur OSI-AP-Title ne contient que des chiffres décimaux et des virgules non
répétitives;
vérifier que la valeur OSI-AE-Qualifier est une représentation décimale de 0 à 65 535;
vérifier que IP, IP-SUBNET et IP-GATEWAY contiennent une "adresse IP normalisée" pour Ipv4;
vérifier que Ipv6 et Ipv6-SUBNET et Ipv6-GATEWAY contiennent une adresse RFC 4291 avec des
zéros de tête pour Ipv6;
vérifier que les valeurs OSI-AP-Invoke et OSI-AE-Invoke sont comprises entre 0 et 65 535
sCnf23 Pour chaque élément GSE:
Address/P[type=MAC-Address] élément numérique de droite du premier octet est impair (1, 3, 5, 7, 9,
B, D, F) (multidiffusion);
Address/P[type=VLAN-ID] est présent;
Address/P[type=PRIORITY] est présent;
Address/P[type=APPID] = 0000-3FFF ou 8000-BFFF.
Condition: lorsque l’élément GSE est présent
Cas Description des cas d’essai
d’essai
sCnf24 Pour chaque élément SMV référençant un SampledValueControl dont l’attribut multicast=true ou
manquant, vérifier que l’Address/P[type=MAC-Address] élément numérique de droite du premier octet
est impair (1, 3, 5, 7, 9, B, D, F) (multidiffusion).
Pour chaque élément SMV référençant un SampledValueControl dont l’attribut multicast=false,
vérifier que l’Address/P[type=MAC-Address] élément numérique de droite du premier octet est paire
(0, 2, 4, 6, 8, A, C, E) (monodiffusion).
Pour chaque élément SMV de l’ICD:
• Address/P[type=VLAN-ID] est présent;
• Address/P[type=PRIORITY] est présent;
• Address/P[type=APPID] = 4000-7FFF.
Condition: lorsque l’élément SMV est présent
sCnf25 Vérifier dans l’ICD que chaque Subnetwork/ConnectedAP@iedName est "TEMPLATE"
sCnf26 Vérifier que chaque Subnetwork/ConnectedAP@apName correspond à un IED/AccessPoint@name
sCnf27 Vérifier pour chaque élément GSE, le GSE@cbName indique un GSEControl dans l’AccessPoint
indiqué par GSE//@apName et GSE@ldInst.
Condition: lorsque l’élément GSE est présent
sCnf28 Vérifier pour chaque élément SMV, le SMV@cbName pointe vers un SampledValueControl dans
l’AccessPoint indiqué par SMV//@apName et SMV@ldInst.
Condition: lorsque l’élément SMV est présent
sCnf29 Vérifier qu’au moins un type de SubNetwork a la valeur "8-MMS" lorsque le type est présent ou le
type est absent
sCnf40 Vérifier que l’ICD a exactement un élément IED et que l’attribut "name" de l’élément est "TEMPLATE"
sCnf41 Vérifier que tous les éléments du FCDA font référence aux données existantes et que doName et
(facultatif) daName contiennent des références correctes (réf. 61850-6:2010, 9.3.7, Tableau 22):
• vérifier que les attributs ldInst, lnClass, doName et fc sont déclarés;
• vérifier que l’attribut lnInst est déclaré si lnClass n’est pas "LLN0";
• vérifier que le premier composant de doName fait référence à un DO@name et que le deuxième
composant (le cas échéant) fait référence à un SDO@name dans le DO référencé par le premier
composant;
• vérifier que le premier composant de daName (si présent) fait référence à un DA@name et que
l’autre composant (s’il existe) fait référence à un BDA@name dans la hiérarchie de structure du
DA référencé par le premier composant;
• vérifier qu’au plus un composant de doName/daName contient un indice et que l’attribut ix est
identique à cet indice (voir 61850-6:2010, Tableau 22). Exemple valable: lnClass="MHAI" lnInst="1" fc="MX" doName="HA.phsAHar(0)" daName="cVal.mag.f" ix="0" />
sCnf42 Vérifier que les structures DOI/SDI/DAI correspondent aux DataTypeTemplates (DOI@name est un
DO valide en LD/LN et DAI@name est une feuille dans cette hiérarchie de formulaires DO et
SDI@name entre DOI et DAI)
sCnf43 Vérifier que l’ICD n’a pas d’IED de référence ExtRef différent de TEMPLATE ou "@".
Condition: lorsque l’attribut ExtRef iedName est présent
sCnf44 Vérifier que l’ICD ne comportant aucun élément ClientLN existe dans le ReportControl et aucun
élément IEDName dans le GSEControl et le SampledValueControl
sCnf45 Vérifier que tous les GSEControl/SampledValueControl/ReportControl ont confRev>0 lorsque datSet
n’est pas vide
sCnf46 Vérifier que les attributs IED@originalSclVersion, IED@originalSclRevision et
IED@originalSclRelease correspondent aux attributs correspondants de l’élément SCL
(SCL@version, SCL@revision et SCL@release)
sCnf47 Vérifier que plusieurs éléments DOI/SDI/DAI ayant un nom identique au même niveau diffèrent par
l’attribut "ix" (l’attribut "ix" différent ou "ix" n’est pas présent).
Condition: lorsque l’attribut DOI/SDI/DAI ix est présent
sCnf48 Vérifier que plusieurs LLN0.SGCB n’apparaissent pas dans la même hiérarchie de dispositif logique
(définie par LLN0.GrRef qui fait référence au dispositif logique parent).
Condition: en présence de plusieurs SGCB
Cas Description des cas d’essai
d’essai
sCnf49 Vérifier que l’élément "Log" existe uniquement dans LLN0.
Condition: lorsque Log est présent
sCnf50 Vérifier que la longueur des noms des IED, des dispositifs logiques, des nœuds logiques, des objets
de données, des attributs de données, des ensembles de données et des blocs de contrôle ne
dépasse pas la longueur maximale telle que spécifiée dans l’IEC 61850-7-2:2010, 22.2 et dans le
SCSM
sCnf51 Vérifier que le LPHD de nœud logique est présent dans chaque dispositif logique racine (IEC 61850-
7-1:2010, 8.2.5)
sCnf52 Vérifier que le DEE/outil peut importer un fichier avec GSEControl dans plusieurs LN0.
Ajouter un GSEControl au premier et au dernier LN0 dans la configuration de l’appareil.
Condition: l’attribut Services/GSESettings cbName n’est pas "fixe" ou absent et plusieurs dispositifs
logiques existent et GOOSE max > 1
sCnf60 Vérifier que l’attribut nameLength="64" existe dans l’élément IED/Services
sCnf61 Vérifier que la section Services ne doit pas contredire les blocs de contrôle et les ensembles de
données existants:
• nombre d’éléments DataSet ≤ ConfDataSet.max (si fourni);
• nombre d’instances ReportControl ≤ ConfReportControl.max (si fourni);
• nombre d’instances ReportControl mises en mémoire tampon ≤ ConfReportControl.maxBuf (si
fourni);
• nombre de GSEControl ≤ GOOSE.max (si fourni);
• nombre de SMVControl ≤ SMVsc.max (si fourni);
• nombre de LogControl ≤ ConfLogControl.max (si fourni);
• nombre d’instances LGOS ≤ SupSubscription.maxGo (si fourni);
• nombre d’instances LSVS ≤ SupSubscription.maxSv (si fourni)
sCnf62 Vérifier que l’élément AccessPoint/Services ne contient pas l’attribut nameLength.
Condition: lorsque l’élément AccessPoint Services est présent
sCnf63 Vérifier que l’élément AccessPoint/Services ne contient aucun des éléments ConfLN et ConfLdName.
Condition: lorsque l’élément AccessPoint Services est présent
sCnf64 Vérifier que dans le cas où SupSubscription est revendiqué être pris en charge, au moins une
instance de LGOS ou LSVS doit être dans l’ICD.
Condition: lorsque l’élément SupSubscription est présent
sCnf65 Vérifier que si serviceType=GOOSE est spécifié pour ExtRef, ClientServices.goose=true ou
ClientServices rGOOSE=true. Pour serviceType=SMV, ClientServices.sv=true ou
ClientServices.rSV=true.
Condition: lorsque serviceType=GOOSE ou serviceType=SMV est présent
sCnf70 Vérifier pour chaque DAType/BDA ou DOType/DA avec l’attribut "bType"=Struct possède l’attribut
"type" dont la valeur correspond à DAType@id; ne déclare pas valKind et ne contient pas d’élément

sCnf71 Vérifier pour chaque DAType/BDA ou DOType/DA avec l’attribut "bType"=Enum possède l’attribut
"type" dont la valeur correspond à EnumType@id
sCnf72 Vérifier que les noms de type ne dépassent pas 255 caractères, ne contiennent pas de caractères
"espace blanc" et ne contiennent que des caractères des jeux latin de base ou latin étendu–1
sCnf73 Vérifier que chaque élément DOType contient au moins un élément SDO ou DA
sCnf74 Vérifier pour chaque DA avec FC="CO" (sauf "SBO") que le DAType associé contient l’élément
IEC 61850-8-1:2003.
Vérifier que chaque nom de DA="SBO" (FC="CO") contient l’élément ProtNS.
NOTE: la valeur par défaut du type est 8-MMS, elle est donc facultative
Cas Description des cas d’essai
d’essai
sCnf75 Vérifier pour chaque (instance de) DOType/DA[name=ctlModel] dont l’EnumType associé contient
direct-with-normal-security a dans le DOType un DA nommé "Oper". Si ctlModel a valKind=RO et
valImport=missing/false, utiliser la valeur ctlModel configurée à la place d’EnumType.
Similaire pour sbo-with-normal-security, Oper, Cancel et SBO.
Similaire pour Direct-with-enhanced-security, Oper.
Similaire pour sbo-with-enhanced-security, Oper, Cancel et SBOw
sCnf76 Déconseillé comme sMdl18
sCnf80 Vérifier que les valeurs de l’élément correspondent bien à une valeur de l’EnumType
correspondant, "ord" ne doit pas être utilisé, mais uniquement les valeurs de l’élément EnumVal. Réf
IEC 61850-6:2010, Tableau 45
sCnf81 Vérifier que les valeurs des éléments correspondent à celles du Tableau "Mise en
correspondance des types de données" de l’IEC 61850-6:2010 (si aucune ligne du tableau n’est alors
pas autorisée)
sCnf82 Vérifier pour chaque LLN0 que si LLN0.NamPlt.lnNs est présent, la valeur IEC 61850-7-4:2007B (et
ldNs est un espace de nom de domaine valide), sinon LLN0.NamPlt.ldNs doit avoir la valeur
IEC 61850-7-4:2007B
sCnf83 Vérifier que chaque ctlModel a un élément associé
sCnf84 Vérifier que les références CDC=ORG utilisent le format ACSI (avec “.”, pas de “$” et pas de
contrainte fonctionnelle) et que la référence existe.
Condition: lorsqu’un objet de données avec CDC=ORG est présent
sCnf85 Vérifier pour chaque dispositif logique dont le LLN0 ne contient pas de GrRef, l’existence de l’objet
de données LLN0.NamPlt.
Vérifier pour chaque LLN0 qui contient le DO NamPlt, l’existence et la valeur non nulle de l’attribut
de données LLN0.NamPlt.configRev
IEC 61869-9 cas d’essai pour le fichier de configuration
sCnf100 Vérifier si les capacités "SMVSettings" du serveur dans la section "services ICD" correspondent aux
capacités des IED:
• sv=true,
• maxSMV = nombre de flux SV pris en charge.
Condition: lorsque SV subscribe IEC 61869 est pris en charge
sCnf120 Vérifier que tous les LDevice avec un MSVCB conforme à l’IEC 61869 ont inst=MUnn, où nn sont des
éléments numériques
sCnf121 Vérifier l’existence d’objets de données d’extension LPHD: NamVariant, NamHzRtg, NamAuxVRtg
(facultatif), NamHoldRtg et NamMaxDlRtg (Tableau 903) et MaxDl (Partie 7-4, Éd2, Amd1)
Vérifier l’existence des attributs de données LPHD.PhyNam: vendor, model, serNum, hwRev, swRev
et d et que ces attributs ont valKind en lecture seule.
L’espace de nom de nœud logique effectif: lnNs = IEC 61869-9:2016[A]
sCnf122 Vérifier l’existence d’objets de données d’extension TCTR: NamAccRtg, NamARtg, NamClipRtg
(Tableau 905) et Clip, HoldTmms (Partie 7-4, Éd2, Amd1).
L’espace de nom de nœud logique effectif: lnNs = IEC 61869-9:2016[A]
sCnf123 Vérifier l’existence d’objets de données d’extension TVTR: NamAccRtg, NamVRtg, NamClipRtg
(Tableau 907) et Clip, HoldTmms (Partie 7-4, Éd2, Amd1).
L’espace de nom de nœud logique effectif: lnNs = IEC 61869-9:2016[A]
sCnf124 Vérifier la désignation TCTR et TVTR des nœuds logiques:
pour la configuration rétrocompatible: InnATCTR1, InnBTCTR2, InnCTCTR3, InnNTCTR4,
UnnATVTR1, UnnBTVTR2, UnnCTVTR3, UnnNTVTR4;
pour les rapports préférentiels: InnpTCTRn et UnnpTVTRn, où nn est un nombre et p est la phase
(IEC 61869-9:2011, 6.903.7 et 6.903.8)
Cas Description des cas d’essai
d’essai
sCnf125 Vérifier le bloc de contrôle de valeurs échantillonnées:
pour une configuration rétrocompatible:
– si name est MSVCB01: smpMod=SmpPerPeriod ou absent, smpRate=80, confRev=1,
nofASDU=1, smvID=xxxxMUnn01;
– si name est MSVCB02: smpMod=SmpPerPeriod ou absent, smpRate=256, confRev=1,
nofASDU=8, smvID=xxxxMUnn02;
– name = MSVCBxx smpMod=SmpPerPeriod ou absent, smpRate = 96 (variante japonaise) où xx
n’est ni 01 ni 02;
pour les rapports préférentiels:
– name = MSVCBxx, smpMod=SmpPerSec où xx n’est ni 01 ni 02.
Vérifier les SmvOpts (IEC 61869:2011, 6.903.1 et IEC 61850-6, Tableau 31)
– SmvOpt: sampleSynchronized="true" ou absent; refreshTime="false" ou absent;
sampleRate="false" ou absent; dataSet="false" ou absent; security="false" ou absent
sCnf126 Vérifier la désignation et les éléments de l’ensemble de données SV:
pour une configuration rétrocompatible:
éléments de l’ensemble de données PhsMeas1 tel que spécifié en 6.903.10;
pour les rapports préférentiels:
PhsMeas2.99 (IEC 61869 6.903.10)
La séquence des éléments de l’ensemble de données doit être i/q/i/q… et le courant produit la
tension si les deux sont présents. Lorsqu’il existe plusieurs éléments de courant ou de tension pour
un point de mesure commun, ils doivent être adjacents et dans l’ordre suivant: A, AB, B, BC, C, CA,
N.
Le nombre d’éléments de courant et de tension doit correspondre au nombre du code de variante
actuellement en essai
sCnf127 Vérifier que les valeurs des attributs AmpSv units, offset et scaleFactor correspondent à l’IEC 61869-
9:2011, Tableau 904, lecture seule et non valImport=T.
Vérifier que les valeurs des attributs VolSv units, offset et scaleFactor correspondent à l’IEC 61869-
9:2011, Tableau 906, lecture seule et non valImport=T
sCnf128 Vérifier que lorsque le dispositif ne fournit pas tous les échantillons pour le ou les débits
rétrocompatibles, il est possible de référencer des attributs de données SAV "factices" dans
l’ensemble de données. Le fichier ICD doit, pour pouvoir détecter la différence entre les échantillons
factices et réels dans le SCL, contenir tous les LN, le mode des LN non pris en charge étant toutefois
préconfiguré sur "Off".
Condition: un canal non pris en charge
sCnf129 Vérifier si les capacités "SMVSettings" du serveur dans la section "services ICD" correspondent:
• SamplesPerSec est présent;
• SmpRate est présent;
• SecPerSamples est absent;
• kdaParticipant / McSecurity est faux ou absent;
• pdcTimeStamp est faux ou absent;
• synchSrcId est absent/false/true (IEC 61850-9-2:2011/AMD1:2020)

6.2.4.5 Cas d’essai des modèles de données
Les cas d’essai énumérés dans le Tableau 3 doivent s’appliquer.
Tableau 3 – Cas d’essai du modèle de données du serveur
Cas d’essai Description des cas d’essai
sMdl1 Vérifier la présence d’objets de données obligatoires pour chaque type LN et d’attributs de
données pour chaque type DO. Essai déclaré comme réussi lorsque tous les objets/attributs
sont présents
sMdl2 Vérifier la présence d’objets à présence conditionnelle vraie pour chaque type LN et
d’attributs de données pour chaque type DO. Essai déclaré comme réussi lorsque tous les
objets/attributs sont présents
sMdl3 Vérifier la non-présence de présence d’objets à présence conditionnelle fausse pour chaque
type LN et les attributs de données pour chaque type DO. Essai déclaré comme réussi
lorsque ces objets/attributs ne sont pas présents
sMdl4 Vérifier la mise en correspondance de modèles de données selon le SCSM applicable
concernant l’extension de longueur de nom et d’objet. Essai déclaré comme réussi lorsque la
mise en correspondance est conforme au SCSM applicable
sMdl5 Vérifier la mise en correspondance de modèles de données selon le SCSM applicable
concernant l’organisation des composants fonctionnels
sMdl6 Vérifier la mise en correspondance de modèles de données selon le SCSM applicable
concernant la désignation des blocs de contrôle et des journaux. Essai déclaré comme réussi
lorsque la mise en correspondance est conforme au SCSM applicable
sMdl7 Vérifier le type de tous les objets de données pour chaque type LN et tous les attributs de
données pour chaque type DO. Essai déclaré comme réussi lorsque le type de tous les
objets/attributs correspond à l’IEC 61850-7-3, l’IEC 61850-7-4 et le SCSM applicable
sMdl8 Vérifier que les types et valeurs enum provenant du SCL et du dispositif se situent dans la
plage spécifiée. Réussi lorsque tous les types et valeurs enum correspondent au 2007B.nsd
sMdl9 Vérifier si les extensions de modèles de données spécifiques au constructeur sont mises en
œuvre selon les règles d’extension définies à l’IEC 61850-7-1:2010, Article 14
sMdl10 Vérifier si l’ordre des attributs de données dans les limites des contraintes de fonctionnement
des types DO correspond à l’IEC 61850-7-3. Essai déclaré comme réussi lorsque tous les
attributs se présentent dans l’ordre de correspondance
sMdl11 Déplacé à sCnf50
sMdl12 Vérifier que les règles applicables à l’instanciation d’objets de données multiples sont
conservées (IEC 61850-7-1:2010,14.6, IEC 61850-7-4)
sMdl13 Déplacé à sCnf82
sMdl14 Vérifier l’utilisation correcte des espaces de nom pour les applications d’automatisation de
systèmes électriques autres que les applications de poste, comme les applications
hydrauliques et DER. Condition: lorsqu’un espace de nom autre que de poste est utilisé
Vérifier si le fichier de configuration SCL utilisé pour configurer le DEE correspond aux
sMdl15
références d’objets de données, aux types de données, aux ensembles de données et aux
valeurs de données préconfigurées (réglages) présentés par le DEE sur le réseau
sMdl16 Modifier un paramètre/réglage avec valImport=True de chaque type de données configurable
et FC (FC peut être DC, CF ou SP) à l’aide du SIMULATEUR SCT.
Modifier un paramètre/réglage si valImport=False ou absent de chaque type de données
configurable et FC (FC peut être DC, CF ou SP) à l’aide de l’outil de configuration IED fourni.
Vérifier que les valeurs de paramètre/réglage en ligne mises à jour correspondent aux
valeurs configurées dans le SCL.
Documenter les paramètres soumis à essai dans le rapport d’essai.
Condition: lorsqu’un paramètre/réglage est configurable
sMdl17 Vérifier la structure de désignation "ldName" lorsqu’elle est prise en charge. Toutes les
références d’objets en ligne (y compris les ensembles de données, les références de blocs
de contrôle et les références d’objets) doivent commencer avec la valeur "LDevice ldName"
au lieu de "IED name" + "LDevice inst".
Condition: lorsque Services ConfLdName est présent
sMdl18 Vérifier que l’option de déclenchement indiquée: est conforme à
l’option de déclenchement normalisée de l’IEC 61850-7-3
Cas d’essai Description des cas d’essai
sMdl19 Configurer le nom d’attribut IED dans le serveur, ce qui donne un nom de domaine MMS de
64 caractères pour la ldInst la plus longue et vérifier que le nom de domaine en ligne
correspond à la configuration
sMdl20 Si le fichier ICD/IID contient une valeur valKind=Conf: vérifier que le modèle de données en
ligne ne contient pas de structures de données vides du fait que tous les attributs contenus
sont valKind=Conf
sMdl21 Modifier certains préfixes LN/numéros d’instance dans le fichier SCD, reconfigurer l’IED et le
charger dans le fichier correspondant. Parcourir le modèle de données IED et vérifier que les
modifications sont bien présentes.
Condition: lorsque les services ConfLNs fixPrefix=false ou fixLnInst=false
sMdl22 Vérifier qu’au moins un dispositif logique a LPHDx.Proxy=false.
Vérifier chaque objet de données de suivi dans LTRK (exemple: SpcTrk) apparaît dans au
plus un nœud logique LTRK de tous les appareils logiques qui ont LPHDx.Proxy=false.
Pour un dispositif logique avec LPHDx.Proxy=true, aucun essai n’est exigé
sMdl23 Modifier valKind de Set à RO dans le fichier SCD, reconfigurer l’IED et le charger dans le
fichier correspondant. Parcourir le modèle de données IED et vérifier que les attributs sont
en lecture seule.
Condition: lorsque Services ValueHandling setToRO=true, SICS-I211
sMdl24 Importer un dispositif d’horloge principale dans le fichier SCD, reconfigurer l’IED et le
charger dans le fichier correspondant. Vérifier que l’IED se synchronise avec l’horloge
principale.
Condition: Il est nécessaire de clarifier SICS-I24 hors du domaine d’application
sMdl25 Instancier 2 nouveaux LGOS dans le fichier SCD (IEC 61850-6:2009, Annexe G), l’un
provenant d’un bloc de contrôle GOOSE provenant d’un dispositif logique avec ldName et
l’autre sans. Reconfigurer l’IED et charger sur l’IED. Parcourir le modèle de données IED et
vérifier la présence du LGOS.
Condition: lorsque Services SupSubscription maxGo>0
sMdl26 Instancier une nouvelle LSVS dans le fichier SCD (IEC TR 61850-6:2016, Annexe G), une
LSVS provenant d’un bloc de contrôle Sampled Value provenant d’un dispositif logique avec
ldName et une LSVS sans. Reconfigurer l’IED et charger sur l’IED. Parcourir le modèle de
données IED et vérifier la présence du LSVS.
Condition: lorsque Services SupSubscription maxSv>0
sMdl27 Vérifier que l’IED peut s’abonner à un GOOSE publié sur le connectedAP de l’accesspoint
ServerAt d’un autre IED.
Condition: lorsque l’abonnement GOOSE est pris en charge

6.2.4.6 Mise en correspondance des modèles ACSI et des cas d’essai applicables
aux services
Les essais doivent être regroupés dans des tableaux. Ces tableaux doivent refléter les modèles
de service ap
...

IEC 61850-10 ®
Edition 2.0 2025-07
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
AMENDMENT 1
AMENDEMENT 1
Communication networks and systems for power utility automation -
Part 10: Conformance testing
Réseaux et systèmes de communication pour l'automatisation des systèmes
électriques -
Partie 10: Essais de conformité
ICS 33.200  ISBN 978-2-8327-0566-7

IEC 61850-10:2012-12/AMD1:2025-07(en-fr)

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.

replaced and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC -  IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
Published détaille les nouvelles publications parues. dans 25 langues additionnelles. Egalement appelé
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.

Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
Communication networks and systems for power utility automation -
Part 10: Conformance testing
AMENDMENT 1
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch [and/or]
www.iso.org/patents. IEC shall not be held responsible for identifying any or all such patent rights.
Amendment 1 to IEC 61850-10 has been prepared by IEC technical committee 57: Power
systems management and associated information exchange.
The major changes in this amendment are as follows:
– server device conformance test procedures have been updated; new test cases are: sAss4,
sAss5, sAssN7, sSrv14, sSrv15, sDs15, sSg11.sSg14, sRp15, sRp16, sRp17, sRp23,
sRpN9, sBr29, sBrN9, sBrN10, sGop12, sGos8.15, sGos20.23, sGosN7, sSBOns8, sTm6,
sTm7, sTmP1, sTmP2, sTmP5, sTmPN1;
– client device conformance test procedures have been updated; new test cases are: cAss10,
cAssN8, cAssN9, cSrv10, cSrvN7.cSrvN9, cSg46, cRp14.22, cRp40.46, cBr14.22,
cBr30.32, cBr46, cLog9, cLog46, cLogN4, cGcb46, cSBOns10, cFt16, cMsvcb1, cMsvcb2,
cMsvcb46;
– sampled values test procedures have been merged into server;
– server IED configuration tool related conformance test procedures have been updated; the
ICD export and SCD import test cases have been merged into server, new test cases are:
tTf4, tTf5;
– System Configuration Tool related conformance test procedures have been updated; new
test cases are: tSieN2, tSce8.10, tSceN2, tDfeN3, tSmo7.9, tSse4.7, tSsi5.6, tSeh7.11;
– GOOSE performance test procedures have been updated; the performance classes have
been updated to align with the performance class definition updates.
The text of this Amendment is based on the following documents:
Draft Report on voting
57/2769/FDIS 57/2797/RVD
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this Amendment is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications/.
A list of all parts of IEC 61850 series, under the general title Communication networks and
systems for power utility automation, can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
• reconfirmed,
• withdrawn, or
• revised.
___________
1 Scope
Add the following new text after the first paragraph of the Scope (before the NOTE):
Cyber security extensions provided by IEC 62351 are conformance tested against the
IEC 62351-100-4 and IEC 62351-100-6.
2 Normative references
Insert the following new normative references:
IEC/IEEE 61850-9-3:2016, Communication networks and systems for power utility automation
– Part 9-3: Precision time protocol profile for power utility
IEC 61869-9:2016, Instrument transformers – Part 9: Digital interface for instrument
transformers
Remove the following existing normative reference:
IEC 62439-3:2012, Industrial communication networks – High availability automation networks
– Part 3: Parallel Redundancy Protocol (PRP) and High Availability Seamless Redundancy
(HSR)
4 Abbreviated terms
Insert the following new abbreviated term:
PTP Precision Time Protocol
6 Device related conformance testing
Replace the existing text, figures (Figures 2 to 6) and tables (Tables 1 to 71) of Clause 6 with
the following new text, figures and tables:
6.1 Test methodology
Communication testing needs at least two devices to communicate with each other.
Comprehensive interoperability testing of all possible products is not feasible. Therefore, the
test concept shall include test devices, test configurations, and test scenarios. The dynamic
behaviour should be tested properly by using well-defined test cases.
Messages are generated to test the communication capabilities. Hardwired stimuli (contacts,
voltages, currents, etc.) and stimuli coming over a serial link if applicable should be used if
applicable.
Special attention shall be given to communication equipment such as star-couplers, switches,
etc. which shall support all requested features of the standard but not introduce additional
contingencies and limitations. The impact of the communication method (client-server, GOOSE,
SV, etc.) used by the DUT shall be considered properly in the test procedures. Verification of
functional applications (use of GOOSE messages) is not part of a conformance test even if
advanced tools may offer such analysis.
6.2 Conformance test procedures
6.2.1 General
This subclause describes the test procedure requirements, test structure, the abstract test
cases (what is to be tested). The format and a few examples of detailed test procedures (how
to perform the test) are given in Annex A.
6.2.2 Test procedure requirements
The test procedure requirements are:
– The abstract test cases describe what shall be tested, the detailed test procedures describe
how a test engineer, or a test system shall perform the test.
– Test cases include a reference to the applicable paragraph(s) in the referenced
document(s).
– The test results shall be reproducible in the same test lab and in other test labs.
– Support automated testing with minimal human intervention, as far as reasonably possible.
– The tests shall focus on situations that cannot easily be tested during, for example, a factory
or site acceptance test, and prevent inter-operability risks, for example:
• check behaviour of the device on delayed, lost, double and out of order packets,
• configuration, implementation, operation risks,
• mismatching names, parameters, settings, or data types,
• exceeding certain limits, ranges or timeouts,
• force situations to test negative responses,
• check all (control) state machine paths, and
• force simultaneous control operations from multiple clients.
– The ACSI tests focus on the application layer (mapping).
– The device under test (DUT) is considered as a black box. The I/O and the communication
interface are used for testing.
– The test includes testing the versions, data model and configuration file, and the use of
applicable ISO/IEC 9646 series terminology.
The test procedures shall be formatted as outlined in Figure 2. With this format, the test
procedures document can also be used as test report. A few test procedure examples are
depicted in Annex A.
Figure 2 – Test procedure format
6.2.3 Test structure
The test cases are structured as follows:
– documentation and version control (IEC 61850-4);
– configuration file (IEC 61850-6);
– data model (IEC 61850-7-3 and IEC 61850-7-4);
– mapping of ACSI models and services (IEC 61850-7-2 and applicable SCSM).
6.2.4 Test cases to test a server device
6.2.4.1 General
This part of the IEC 61850 series specifies the test system architecture and abstract test cases
for server devices. The abstract test cases shall be used for the definition of test procedures to
run in tests.
NOTE The SCSM specific test procedures are provided by test facilities agreed upon by the market participants.
6.2.4.2 Test system architecture to test a server device
In order to be able to perform a server device test, a minimum test set-up is necessary. The
test architecture contains (see Figure 3):
– DUT;
– client simulator to initiate and generate TPAA messages;
– GOOSE simulator to send correct and incorrect GOOSE messages;
– SV simulator to send correct and incorrect SV messages;
– test master to start/stop test cases, start/stop the analyzer and archive test results;
– time master;
– engineering tool to configure the DUT;
– protocol analyzer to store all the network traffic for each test case;
– signal generator to force binary and analogue events, controlled by the test master or test
engineer.
Figure 3 – Test system architecture to test a server device
The test system shall include documentation regarding test system hardware and test system
software.
6.2.4.3 Documentation and version control test procedure overview
The test cases listed in Table 1 shall apply.
Table 1 – Server documentation test cases
Test case Test case description
Check if the major/minor software version in the PICS documentation and the DUT do match
(IEC 61850-4). PICS shall contain:
• ACSI conformance statement according to IEC 61850-7-2:2010, Annex A
sDoc1
• IEC 61850-9-3 PICS (when supported)
• IEC 61869-9 conformance class a, b, c or d (when supported)
Check if the major/minor software version in the PIXIT documentation and software version of the
sDoc2 DUT does match (IEC 61850-4). PIXIT shall indicate the required information as requested in the
test cases
Check if the major/minor software version in the MICS documentation and software version of the
DUT does match (IEC 61850-4). MICS shall indicate the semantics of all non-standard Logical
sDoc3
Nodes, Data Objects, Data Attributes and enumeration. MICS may contain other items in
additional sections of the MICS.
Check if the major/minor software version in the TICS documentation and software version of the
sDoc4 DUT does match (IEC 61850-4). TICS shall indicate that the mandatory and applicable technical
issues are implemented.
Check the ICD if the server capabilities in the IED "services" section(s) do correspond with the
sDoc5
ACSI services specified in the PICS

6.2.4.4 Configuration file test cases
The test cases listed in Table 2 shall apply.
Table 2 – Server configuration file test cases
Test Test case description
case
sCnf1 Verify the SCL version = "2007", revision = "B", release = "4"
sCnf2 Verify the XML encoding is UTF-8 or utf-8;
sCnf3 Verify that the ICD validates according to SCL schema: version 2007, revision B, release 4
sCnf4 Use the ICT tool to export an ICD file. When ICD is not supported export IID file. Use this file for the
remaining tests. It is not allowed to change this SCL file with general purpose tools such as an XML
editor.
Condition: when the ICD is not fixed
sCnf5
Import the ICD or IID file from sCnf4 into SCT SIMULATOR and generate SCD file as follows:
• update IED name
• change IP/MAC address
• change SubNetwork name
• add DataSet's (when supported)
• add ReportControl's (when supported)
• add GSEControl's (when supported)
• add SampledValueControl's (when supported)
• add data flows (ExtRef's) from other IED's (when noIctBinding=F)
Import the SCD file into the ICT tool and select the IED to be handled from IED's named in the SCD
file by IED name
Test Test case description
case
sCnf6 Complete the GOOSE and SV subscribe from sCnf5 and export the IID file. Verify that the ExtRef
intAddr does not change when the external binding changes. The intAddr should not contain external
data.
Condition: when GOOSE and/or SV subscribe is supported
sCnf10 Verify the ICD has at most one Substation or Line or Process exists at SCL level and the attribute
"name" is "TEMPLATE".
Condition: when Substation or Line or Process section is present
sCnf11 Verify the ICD has none of the LNode bound to an IED different from "TEMPLATE" or "none"
Condition: when Substation section is present
sCnf20 Verify that the "Communication" element exists:
• IED/Services/DynAssociation or IED/AccessPoint/Services/DynAssociation is declared) and
IED/AccessPoint/ Server is declared or
• LN0/GSEControl element exist or
• LN0/SampledValueControl element exist
sCnf21 For each ConnectedAP/Address element:
Verify that exactly one "P" element with attribute type="OSI-PSEL" with a valid value (non-empty,
even number of characters, maximum 16 characters 0-9,A-F)
Verify that exactly one "P" element with attribute type="OSI-SSEL" with a valid value (non-empty,
even number of characters, maximum 16 characters 0-9,A-F)
Verify that exactly one "P" element with attribute type="OSI-TSEL" with a valid value (non-empty,
even number of characters, maximum 8 characters 0-9,A-F)
(Note that if xsi:type mechanism is used then schema validator can automatically verify the type)
Condition: IED/Services/DynAssociation is declared
sCnf22 Verify that for each accesspoint no more than one "P" element with attribute type="OSI-AP-Title" and
"OSI-AE-Qualifier and "IP" and "IP-SUBNET", "IP-GATEWAY", OSI-NSAP, OSI-AP-Invoke, OSI-AE-
Invoke and DNSName exists. For each of these that exist:
Verify OSI-AP-Title value contains only decimal digits and non-repeating commas
Verify OSI-AE-Qualifier value is decimal representation from 0-65535
Verify IP and IP-SUBNET and IP-GATEWAY contain a "standard dotted-decimal" for Ipv4
Verify Ipv6 and Ipv6-SUBNET and Ipv6-GATEWAY contain a RFC 4291 address with leading zeros
for Ipv6
Verify OSI-AP-Invoke and OSI-AE-Invoke values are between 0 and 65535.
sCnf23 For each GSE element:
Address/P[type=MAC-Address] right digit of first octet is odd (1,3,5,7,9,B,D,F) (multicast).
Address/P[type=VLAN-ID] present
Address/P[type=PRIORITY] present
Address/P[type=APPID] = 0000-3FFF or 8000-BFFF
Condition: when GSE element is present
sCnf24 For each SMV element referencing a SampledValueControl whose attribute multicast=true or missing,
verify Address/P[type=MAC-Address] right digit of first octet is odd (1,3,5,7,9,B,D,F) (multicast)
For each SMV element referencing a SampledValueControl whose attribute multicast=false, verify
Address/P[type=MAC-Address] right digit of first octet is even (0,2,4,6,8,A,C,E) (unicast)
For each SMV element in the ICD:
• Address/P[type=VLAN-ID] present
• Address/P[type=PRIORITY] = present
• Address/P[type=APPID] = 4000-7FFF
Condition: when SMV element is present
sCnf25 Verify the ICD that each Subnetwork/ConnectedAP@iedName is "TEMPLATE"
sCnf26 Verify each Subnetwork/ConnectedAP@apName matches one of IED/AccessPoint@name
Test Test case description
case
sCnf27 Verify for each GSE element, the GSE@cbName points to a GSEControl within the AccessPoint
pointed to by GSE//@apName and GSE@ldInst.
Condition: when GSE element is present
Verify for each SMV element, the SMV@cbName points to a SampledValueControl within the
sCnf28
AccessPoint pointed to by SMV//@apName and SMV@ldInst.
Condition: when SMV element is present
sCnf29 Verify that at least one SubNetwork type has value "8-MMS" when type is present or type is absent
sCnf40 Verify the ICD has exactly one IED element and that the attribute "name" of the element is
"TEMPLATE"
sCnf41 Verify all FCDA elements reference existing data and that doName and (optional) daName contain
correct references. (ref 61850-6:2010, 9.3.,7 Table 22).
• Verify attributes ldInst, lnClass, doName, and fc are declared.
• Verify attribute lnInst is declared if lnClass is not "LLN0".
• Verify first component of doName references a DO@name and second component (if any)
references a SDO@name within DO referenced by first component
• Verify first component of daName (if present) references a DA@name and other component (if
any) references a BDA@name within structure hierarchy of the DA referenced by first component
• Verify that at most one component of doName/daName contains an index and that ix attribute is
identical to this index (see 61850-6:2010, Table 22). Valid example: lnClass="MHAI" lnInst="1" fc="MX" doName="HA.phsAHar(0)" daName="cVal.mag.f" ix="0" />
sCnf42 Verify DOI/SDI/DAI structures match DataTypeTemplates (DOI@name is valid DO in LD/LN and
DAI@name is a leaf within that DO and SDI@name form hierarchy between DOI and DAI)
sCnf43 Verify that the ICD has none of the ExtRef references IEDs different from TEMPLATE or "@"
Condition: when ExtRef iedName attribute is present
sCnf44 Verify that the ICD has no ClientLN elements exist within ReportControl and no IEDName elements
within GSEControl and SampledValueControl
sCnf45 Verify all GSEControl/SampledValueControl/ReportControl have confRev>0 when datSet is not empty
sCnf46 Verify IED@originalSclVersion, IED@originalSclRevision and IED@originalSclRelease attributes
match corresponding attributes of SCL element (SCL@version, SCL@revision and SCL@release)
sCnf47 Verify multiple identically named DOI/SDI/DAI elements at the same level differ by "ix" attribute
(either different "ix" or "ix" attribute not present).
Condition: when DOI/SDI/DAI ix attribute is present
sCnf48 Verify multiple LLN0.SGCB do not appear in the same logical device hierarchy (defined by
LLN0.GrRef which references the parent logical device)
Condition: when multiple SGCB are present
sCnf49 Verify element "Log" exists only in LLN0
Condition: when Log is present
sCnf50 Verify that the name length of IED, Logical Devices, Logical Nodes, data objects, data attributes,
data sets and control blocks do not exceed the maximum length as specified in IEC 61850-7-2:2010,
22.2 and SCSM
sCnf51 Verify that logical node LPHD is present in each root logical device (IEC 61850-7-1:2010, 8.2.5)
sCnf52 Verify that DUT/tool can import file with GSEControl in multiple LN0
Add one GSEControl to first and last LN0 in the configuration of the device
Condition: Services/GSESettings attribute cbName is not "fix" or absent and multiple Logical Devices
exist and GOOSE max > 1
sCnf60 Verify that the attribute nameLength="64" exists in the IED/Services element
Test Test case description
case
sCnf61 Verify that the Services section must not contradict existing control block and data sets;
• Nr of DataSet elements <= ConfDataSet.max (if provided).
• Nr of ReportControl instances <= ConfReportControl.max (if provided)
• Nr of Buffered ReportControl instances <= ConfReportControl.maxBuf (if provided)
• Nr of GSEControl <= GOOSE.max (if provided)
• Nr of SMVControl <= SMVsc.max (if provided)
• Nr of LogControl <= ConfLogControl.max (if provided)
• Nr of LGOS instances <= SupSubscription.maxGo (if provided)
• Nr of LSVS instances <= SupSubscription.maxSv (if provided)
sCnf62 Verify the AccessPoint/Services element does not contain the attribute nameLength
Condition: when AccessPoint Services element is present
sCnf63 Verify AccessPoint/Services element does not contain any of the elements ConfLNs, and
ConfLdName
Condition: when AccessPoint Services element is present
sCnf64 Verify that in case SupSubscription is claimed to be supported at least one instance of LGOS or
LSVS must be in the ICD.
Condition: when SupSubscription element is present
sCnf65 Verify that if serviceType=GOOSE is specified for ExtRef the ClientServices.goose=true or
ClientServices rGOOSE=true. For serviceType=SMV the ClientServices.sv=true or
ClientServices.rSV=true
Condition: when serviceType=GOOSE or serviceType=SMV is present
sCnf70 Verify for each DAType/BDA or DOType/DA with attribute "bType"=Struct has attribute "type" whose
value matches DAType@id; does not declare valKind and does not contain a element
sCnf71 Verify for each DAType/BDA or DOType/DA with attribute "bType"=Enum has attribute "type" whose
value matches EnumType@id
sCnf72 Verify type names do not exceed 255 characters, contain no "whitespace" characters and contain
only characters from Basic-Latin and Latin-1-Supplement
sCnf73 Verify that each DOType element contains at least one SDO or DA element
sCnf74 Verify for each DA with FC="CO" (except "SBO") that the associated DAType contains the element
IEC 61850-8-1:2003
Verify for each DA name="SBO" (FC="CO") contains the ProtNS element
NOTE type default value is 8-MMS so it's optional
sCnf75 Verify for each (instance of) DOType/DA[name=ctlModel] whose associated EnumType contains
direct-with-normal-security has in the DOType a DA named "Oper". If ctlModel has valKind=RO and
valImport=missing/false then use the configured ctlModel value instead of EnumType.
Similar for sbo-with-normal-security, Oper, Cancel and SBO
Similar for direct-with-enhanced-security, Oper
Similar for sbo-with-enhanced-security, Oper, Cancel and SBOw
sCnf76 Deprecated same as sMdl18
Verify that element values actually match a value in the corresponding EnumType, "ord" shall
sCnf80
not be used, only EnumVal element values. Ref IEC 61850-6:2010, Table 45.
sCnf81 Verify that elements values match IEC 61850-6:2010, Table "Data type mapping" (if no table
rows then Val element is not allowed at all)
sCnf82 Verify for each LLN0 that if LLN0.NamPlt.lnNs is present it shall have value IEC 61850-7-4:2007B
(and ldNs is valid domain name space), otherwise LLN0.NamPlt.ldNs shall have value IEC 61850-7-
4:2007B.
sCnf83 Verify each ctlModel has an associated element
sCnf84 Verify CDC=ORG references use the ACSI format (with ".", no "$" and no functional constraint) and
that the reference does exist
Condition: when a data object with CDC=ORG is present
Test Test case description
case
sCnf85 Verify for each Logical Device whose LLN0 does not contain GrRef, the existence of Data Object
LLN0.NamPlt
Verify for each LLN0 which contains the DO NamPlt, the existence and non-null value for Data
Attribute LLN0.NamPlt.configRev
IEC 61869-9 configuration file test cases
sCnf100 Check if the server "ClientServices" capabilities in the ICD "services" section do match with the IED
capabilities:
• sv=true
• maxSMV = supported number of SV streams
Condition: when IEC 61869 SV subscribe is supported
sCnf120 Verify that all LDevice's with an IEC 61869 MSVCB have inst=MUnn where nn are digits.
sCnf121 Verify the existence of LPHD extension Data Objects: NamVariant, NamHzRtg, NamAuxVRtg
(optional), NamHoldRtg and NamMaxDlRtg (table 903) and MaxDl (part 7-4 Ed2 Amd1)
Verify the existence of LPHD.PhyNam data attributes: vendor, model, serNum, hwRev, swRev and d
and that these attributes have valKind read-only.
The effective logical node namespace: lnNs = IEC 61869-9:2016[A]
sCnf122 Verify the existence of TCTR extension Data Objects: NamAccRtg, NamARtg, NamClipRtg (table
905) and Clip, HoldTmms (part 7-4 Ed2 Amd1)
The effective logical node namespace: lnNs= IEC 61869-9:2016[A]
sCnf123 Verify the existence of TVTR extension Data Objects: NamAccRtg, NamVRtg, NamClipRtg (table 907)
and Clip, HoldTmms (part 7-4 Ed2 Amd1)
The effective logical node namespace: lnNs= IEC 61869-9:2016[A]
sCnf124 Verify for the logical nodes TCTR and TVTR naming;
For the backwards compatible configuration: InnATCTR1, InnBTCTR2, InnCTCTR3, InnNTCTR4,
UnnATVTR1, UnnBTVTR2, UnnCTVTR3, UnnNTVTR4
For the preferred rates: InnpTCTRn and UnnpTVTRn, where nn is a number and p is the phase
(IEC 61869-9:2011, 6.903.7 and 6.903.8)
sCnf125 Verify the sampled value control block:
For backward compatible configuration:
– If name is MSVCB01; smpMod=SmpPerPeriod or absent, smpRate=80, confRev=1, nofASDU=1,
smvID=xxxxMUnn01
– If name is MSVCB02; smpMod=SmpPerPeriod or absent, smpRate=256, confRev=1, nofASDU=8,
smvID=xxxxMUnn02
– Name = MSVCBxx smpMod=SmpPerPeriod or absent, smpRate = 96 (the Japanese variant)
where xx is not 01 nor 02
For preferred rates:
– Name = MSVCBxx, smpMod=SmpPerSec where xx is not 01 nor 02
Verify the SmvOpts (IEC 61869:2011, 6.903.1 and IEC 61850-6: Table 31)
– SmvOpt: sampleSynchronized="true" or absent; refreshTime="false" or absent;
sampleRate="false" or absent; dataSet="false" or absent; security="false" or absent
sCnf126 Verify the SV dataset naming and elements
For backward compatible configuration:
PhsMeas1 Dataset elements as specified in clause 6.903.10
For preferred rates:
PhsMeas2.99 (IEC 61869 6.903.10)
Dataset elements sequence shall be i/q/i/q… and current proceeds voltage if both are present. Where
multiple current or multiple voltage members for a common measurement point exist, they shall be
adjacent and in the sequence: A, AB, B, BC, C, CA, N.
The number of current and voltage elements shall match the number in the variant code currently
under test.
Test Test case description
case
sCnf127 Verify the AmpSv units, offset and scaleFactor attribute values match 61869-9:2011, Table 904, read-
only and not valImport=T
Verify the VolSv units, offset and scaleFactor attribute values match 61869-9:2011, Table 906, read-
only and not valImport=T
sCnf128 Verify that if the device does not supply all samples for the backwards compatible rate(s), 'dummy'
SAV data attributes might be referenced in the data set. To detect the difference between dummy
and real samples in the SCL, the ICD shall have all LN's included but the ones that are not supported
have the LN Mode preconfigured to "Off".
Condition: a not supported channel
sCnf129 Check if the server "SMVSettings" capabilities in the ICD "services" section does match:
• SamplesPerSec is present
• SmpRate is present
• SecPerSamples is absent
• kdaParticipant / McSecurity is false or absent
• pdcTimeStamp is false or absent
• synchSrcId is absent/false/true (IEC 61850-9-2:2011/AMD1:2020)

6.2.4.5 Data model test cases
The test cases listed in Table 3 shall apply.
Table 3 – Server data model test cases
Test case Test case description
sMdl1 Verify presence of mandatory data objects for each LN type and data attributes for each DO
type. Passed when all objects/attributes are present
sMdl2 Verify presence of conditional presence true data objects for each LN type and data
attributes for each DO type. Passed when all objects/attributes are present
sMdl3 Verify non-presence of conditional presence false data objects for each LN type and data
attributes for each DO type. Passed when these objects/attributes are not present
sMdl4 Verify data model mapping according to applicable SCSM concerning name length and object
expansion. Passed when mapping is according to applicable SCSM
sMdl5 Verify data model mapping according to applicable SCSM concerning organisation of
functional components.
sMdl6 Verify data model mapping according to applicable SCSM concerning naming of control
blocks and logs. Passed when mapping is according to applicable SCSM.
sMdl7 Verify type of all data objects for each LN type and all data attributes for each DO type.
Passed when type of all objects/attributes do match with the IEC 61850-7-3, IEC 61850-7-4
and the applicable SCSM
sMdl8 Verify that the enum types and values from the SCL and in the device are in specified range.
Passed when all enum types and values match the 2007B.nsd.
sMdl9 Check if manufacturer specific data model extensions are implemented according to the
extension rules in IEC 61850-7-1:2010, Clause 14.
sMdl10 Check if the order of the data attributes with the same functional constraint of the DO type
match with IEC 61850-7-3. Passed when all attributes are in matching order
sMdl11 Moved to sCnf50
sMdl12 Check that the rules for multiple data object instantiation are kept (IEC 61850-7-1:2010,14.6,
IEC 61850-7-4)
sMdl13 Moved to sCnf82
sMdl14 Check the correct use of name spaces for non-substation power utility applications like for
example Hydro and DER; Condition: when non-substation name space is used
Test case Test case description
sMdl15 Check if the SCL configuration file used to configure the DUT corresponds with the actual
data object references, data types, data sets and pre-configured data values (settings)
exposed by the DUT on the network.
sMdl16 Change one parameter/setting with valImport=True of each configurable data type and FC
(FC can be DC, CF or SP) using the SCT SIMULATOR
Change one parameter/setting when valImport=False or absent of each configurable data
type and FC (FC can be DC, CF or SP) using the supplied IED configuration tool
Check the updated online parameter/setting values correspond with the configured values in
the SCL.
Document the tested parameters in the test report.
Condition when a parameter/setting is configurable
sMdl17 Check the "ldName" naming structure when supported. All online object references (including
data sets, control block references and object references – CDC ORG) shall start with the
"LDevice ldName" value instead of the "IED name" + "LDevice inst"
Condition when Services ConfLdName is present
sMdl18 Verify that the indicated trigger option: is conformant with the
IEC 61850-7-3 standardized Trigger Option.
sMdl19 Configure IED attribute name in server resulting in a 64-character MMS domain name for the
longest ldInst and verify online domain name agrees with configuration.
sMdl20 If ICD/IID file contains any valKind=Conf: Verify that online data model does not contain
empty data structures as a result of all contained attributes being valKind=Conf
sMdl21 Modify some LN prefix / instance number in the SCD file, reconfigure the IED and load onto
the IED. Browse the IED data model and check that changes are in,
Condition: when Services ConfLNs fixPrefix=false or fixLnInst=false
sMdl22 Verify that at least one Logical Device has LPHDx.Proxy=false.
Verify each tracking Data Object in LTRK (example: SpcTrk) appears in at most one LTRK
Logical Node in all Logical Devices which have LPHDx.Proxy=false.
For Logical Device with LPHDx.Proxy=true, no tests are required
sMdl23 Modify valKind from Set to RO in the SCD file, reconfigure the IED and load onto the IED.
Browse the IED data model and check that the attributes are readonly.
Condition: when Services ValueHandling setToRO=true, SICS-I211
sMdl24 Import a master clock device in the SCD file, reconfigure the IED and load onto the IED.
Check that the IED synch to the master clock.
Condition: SICS-I24 out-of-scope need clarification
sMdl25 Instantiate 2 new LGOS in the SCD file (IEC 61850-6:2009, Annex G) one from a GOOSE
control block from a logical device with ldName and one without. Reconfigure the IED and
load onto the IED. Browse the IED data model and check that the LGOS is present.
Condition: when Services SupSubscription maxGo>0
sMdl26 Instantiate a new LSVS in the SCD file (IEC TR 61850-6:2016, Annex G) one from a Sampled
Value control block from a logical device with ldName and one without. Reconfigure the IED
and load onto the IED. Browse the IED data model and check that the LSVS is present.
Condition: when Services SupSubscription maxSv>0
sMdl27 Verify that the IED can subscribe to a GOOSE published at the connectedAP of ServerAt
accesspoint of another IED
Condition: when GOOSE subscribe is supported

6.2.4.6 Mapping of ACSI models and services test cases
Test items shall be grouped together in tables. The tables shall reflect the applicable service
models specified in Figure 3 of IEC 61850-7-2:2010:
– application association (sAss);
– server, Logical device, Logical node, Data, and Data Attribute model (sSrv);
– data set model (sDs);
– service tracking (sTrk);
– substitution model (sSub);
– setting group model (sSg);
– unbuffered report control model (sRp);
– buffered report control model (sBr);
– log control model (sLog);
– generic object oriented substation events (sGop and sGos);
– control model (sCtl);
– time and time synchronisation model (sTm);
– file transfer model (sFt);
– Samples Values publishing (sSvp);
– Samples Values subscribing (sSvs).
Test cases are defined for each ACSI model and services in the following categories:
• positive = verification of normal conditions, typically resulting in response+
• negative = verification of abnormal conditions, typically resulting in response–
A test case is mandatory when the applicable ACSI model and ACSI service is supported by
the DUT. This is specified in the PICS according to IEC 61850-7-2:2010, Annex A. The test
result interpretation (passed/failed) depends on the declared IED capabilities e.g. in the ICD
file as well as on the test result.
6.2.4.7 Application association model
6.2.4.7.1 Positive test cases
The test cases listed in Table 4 shall apply.
Table 4 – Association positive test cases
Test case Test case description
sAss1 Associate and client-release a TPAA association (IEC 61850-7-2:2010, 8.3.2)
sAss2 Associate and client-abort TPAA association (IEC 61850-7-2:2010, 8.3.2)
sAss3 Associate with maximum number of clients simultaneously (PIXIT)
sAss4 Verify the negotiation of MMS initiate parameters
sAss5 Verify the server initiates the Associate

6.2.4.7.2 Negative test cases
The test cases listed in Table 5 shall apply.
Table 5 – Association negative test cases
Test Test case description
case
sAssN1 Check that with incorrect authentication parameters and authentication turned on at server the
association fails, and with authentication turned off the server associates (IEC 61850-7-2:2010, 8.3)
sAssN2 Check that with incorrect association parameters at server or client the association fails (IEC 61850-
7-2:2010, 8.3, PIXIT)
sAssN3 Set up maximum+1 associations, verify the last associate is refused
sAssN4 Disconnect the communication interface, the DUT shall detect association lost within a specified
period
sAssN5 Interrupt and restore the power supply, the DUT shall accept an association request when ready
sAssN6 Verify the re-use of dropped association resources
sAssN7 Server Associate with mismatching association parameters

6.2.4.8 Server, logical device, logical node, and data model
6.2.4.8.1 Positive test cases
The test cases listed in Table 6 shall apply.
Table 6 – Server positive test cases
Test Test case description
case
sSrv1 Request GetServerDirectory(LOGICAL-DEVICE) and check response (IEC 61850-7-2:2010, 7.2.2)
sSrv2 For each GetServerDirectory(LOGICAL-DEVICE) response issue a GetLogicalDeviceDirectory
request and check response (IEC 61850-7-2:2010, 9.2.1)
sSrv3 For each GetLogicalDeviceDirectory response issue a GetLogicalNodeDirectory(DATA) request and
check response (IEC 61850-7-2:2010, 10.2.2)
sSrv4 For each GetLogicalNodeDirectory(DATA) response issue a
– GetDataDirectory request and check response (IEC 61850-7-2:2010, 11.3.4.4)
– GetDataDefinition request and check response (IEC 61850-7-2:2010, 11.43.5)
– GetDataValues request and check response (IEC 61850-7-2:2010, 11.43.2)
sSrv5 Issue one GetDataValues request with different data reference hierarchy
sSrv6 For each write enabled DATA object issue a SetDataValues request and check
...