IEC TR 61850-7-5:2021
(Main)Communication networks and systems for power utility automation - Part 7-5: IEC 61850 modelling concepts
Communication networks and systems for power utility automation - Part 7-5: IEC 61850 modelling concepts
IEC TR 61850-7-5:2021, which is a technical report, establishes modelling concepts that help the user to understand how to apply the models defined in IEC 61850-7-4 and IEC 61850-7-3 to implement practical applications.
This document provides the basic concepts that are valid for all application domains using IEC 61850. Domain specific concepts are defined in other technical reports as in the document range of IEC 61850-7-5xx; as an example, IEC 61850-7-500 describes modelling concepts for functions related to substation automation.
On one side the number of potential topics for cross-domain modelling may be very high but on the other side it may be limited by domain specific restrictions often created by the historical evolution of IEC 61850 in the domains.
The first topic selected is the common control of power utility primary objects by means of the power utility automation systems based mainly on the long experience in substation automation systems. Common attributes for reliable power utility automation systems in all domains are quality and health. A special function having a broad application range in power utility automation systems is the scheduling of services as provided by the domain distributed energy resources (DER) used in smart grids, especially also for electric mobility. Not yet so much discussed in the context of IEC 61850 but very important for all IEDs is the impact of restart (power cycle) on the data model parameters. Non-agreed behaviour will raise problems for interoperability in multi-vendor systems.
General Information
Standards Content (Sample)
IEC TR 61850-7-5 ®
Edition 1.0 2021-04
TECHNICAL
REPORT
colour
inside
Communication networks and systems for power utility automation –
Part 7-5: IEC 61850 Modelling concepts
IEC TR 61850-7-5: 2021-04 (en)
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.
IEC Central Office 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 - webstore.iec.ch/advsearchform IEC online collection - oc.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews. With a subscription you will always
committee, …). It also gives information on projects, replaced have access to up to date content tailored to your needs.
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 000 terminological entries in English
details all new publications released. Available online and
and French, with equivalent terms in 18 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.
IEC TR 61850-7-5 ®
Edition 1.0 2021-04
TECHNICAL
REPORT
colour
inside
Communication networks and systems for power utility automation –
Part 7-5: IEC 61850 Modelling concepts
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.200 ISBN 978-2-8322-9647-9
– 2 – IEC TR 61850-7-5:2021 IEC 2021
CONTENTS
CONTENTS . 2
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions and abbreviated terms . 8
3.1 Terms and definitions. 8
3.2 Abbreviated terms . 8
4 Control . 8
4.1 Control authorization . 8
4.1.1 Basics . 8
4.1.2 Validating a control request . 9
4.1.3 Exclusive control authorization for one out of multiple actors of the
same level of control hierarchy . 12
4.1.4 Different control permissions for different actors of the same level of
control hierarchy . 13
4.2 Control authority for process equipment . 13
4.2.1 Control commands for process equipment from automations instead of
HMI . 13
5 Quality and its propagation . 15
5.1 Standard processing principle . 15
5.1.1 General . 15
5.1.2 Respecting behaviour . 15
5.1.3 LN specific calculations . 16
5.1.4 detailQual is not propagated . 16
5.1.5 Configurable propagation of the value of the element ‘source’ . 16
5.1.6 operatorBlocked is not propagated . 16
5.2 Special processing principle for (single phase) XCBR mapping to CSWI . 16
5.2.1 General . 16
5.2.2 Respecting the Behaviour . 18
5.2.3 LN specific calculations . 18
5.2.4 Propagation of detailQual . 18
5.2.5 Substitution of switchgear position signals . 18
5.2.6 operatorBlocked is not propagated . 19
5.3 Conclusion . 19
6 Health and its application . 20
6.1 General . 20
6.2 The use of LPHD.PhyHealth, LLN0.Health, LN.Health and LN.EEHealth . 20
6.3 Health in Proxy-IEDs, in LNs of type Mirror and in a LD hierarchy . 22
7 Special functions . 24
7.1 Use of cross domain schedules and scheduler . 24
7.1.1 Introduction . 24
7.1.2 Example 1 . 25
7.1.3 Example 2 . 28
8 Restoration of functions/communication after IED restart (power cycle) . 31
8.1 Functional description . 31
8.2 Priorities . 31
8.3 Stored and non-stored data. 31
Bibliography . 33
Figure 1 – Communication vs. application layer model for controls . 9
Figure 2 – Different levels of control authority (example) . 12
Figure 3 – Single-phase monitoring of the CB position . 17
Figure 4 – Examples of use of Health and EEHealth in models . 23
Figure 5 – FSCH and FSCC LN class . 24
Figure 6 – State Machine . 25
Figure 7 – Relation between schedule controller, schedules and entity scheduled . 25
Figure 8 – Use case charging architecture . 26
Figure 9 – LN instances and relationships in example 1 . 27
Figure 10 – Timelines associated to the example 1 . 27
Figure 11 – LN instances and relationships in example 2 . 28
Figure 12 – Timelines associated to the example 2 . 30
Table 1 – Dependence of checking Interlocking (IL) conditions on the control command
and on the server configuration . 10
Table 2 – Dependence of checking synchronism (CS) conditions on the control
command and on the server configuration . 11
Table 3 – Use case 1 definition . 14
Table 4 – Example of fixed rules: Boolean OR out of two input signals . 19
Table 5 – Health in IEC 61850-7-4 . 21
Table 6 – Examples for stored and non-stored data for restart . 32
– 4 – IEC TR 61850-7-5:2021 IEC 2021
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
COMMUNICATION NETWORKS AND SYSTEMS
FOR POWER UTILITY AUTOMATION –
Part 7-5: IEC 61850 Modelling concepts
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) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent
rights. IEC shall not be held responsible for identifying any or all such patent rights.
IEC TR 61850-7-5 has been prepared by Working Group 10 of IEC Technical Committee 57:
Power systems management and associated information exchange. It is a Technical Report.
The text of this Technical Report is based on the following documents:
DTR Report on voting
57/2253/DTR 57/2322/RVDTR
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 Technical Report 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/standardsdev/publications.
A list of all parts in the IEC 61850 series, published 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,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.
– 6 – IEC TR 61850-7-5:2021 IEC 2021
INTRODUCTION
The IEC 61850 standard series provides a very broad range of data models covering as much
as possible all application functions in the range of power utility automation. The modelling both
in the domains and between the domains show differences which may impact interoperability.
Therefore, some informative guidelines are helpful to reach a common approach in application
function modelling. A lot of basic functionality is based on the concept of IEC 61850 and is,
therefore, the same for all application domains. As result, a basic cross-domain part in the form
of a Technical Report is useful. Domain specific issues are addressed in the Technical Reports
IEC TR 61850-7-5xx (e.g. IEC TR 61850-7-500 for substation automation).
To cover all domains in a comprehensive way would not come to a result in a reasonable time.
This may be a task for future editions of this document. Therefore, this document describes in
selected examples the use of logical nodes for modelling application functions and related
concepts and guidelines in general independently from any application domain respectively
valid for all application domains in the utility automation (substation automation, distributed
energy resources, hydro power, wind power, etc.). It also includes some tutorial material where
helpful.
The modelling of the use cases given in this document is based on the class model introduced
in IEC 61850-7-1. The logical node and data names used in this document are defined in
IEC 61850-7-4 and IEC 61850-7-3, the services applied in IEC 61850-7-2. If needed for the
understanding of modelling these use cases, the application of services is also described. If
different options cannot be excluded, all options may be mentioned.
If extensions are needed in the use cases, the normative naming rules for multiple instances
and private, compatible extensions of Logical Node (LN) Classes and Data Object (DO) Names
defined in IEC 61850-7-1 are considered.
COMMUNICATION NETWORKS AND SYSTEMS
FOR POWER UTILITY AUTOMATION –
Part 7-5: IEC 61850 Modelling concepts
1 Scope
This part of IEC 61850, which is a technical report, establishes modelling concepts that help
the user to understand how to apply the models defined in IEC 61850-7-4 and IEC 61850-7-3
to implement practical applications.
This document provides the basic concepts that are valid for all application domains using
IEC 61850. Domain specific concepts are defined in other technical reports as in the document
range of IEC 61850-7-5xx; as an example, IEC 61850-7-500 describes modelling concepts for
functions related to substation automation.
On one side the number of potential topics for cross-domain modelling may be very high but on
the other side it may be limited by domain specific restrictions often created by the historical
evolution of IEC 61850 in the domains.
The first topic selected is the common control of power utility primary objects by means of the
power utility automation systems based mainly on the long experience in substation automation
systems. Common attributes for reliable power utility automation systems in all domains are
quality and health. A special function having a broad application range in power utility
automation systems is the scheduling of services as provided by the domain distributed energy
resources (DER) used in smart grids, especially also for electric mobility. Not yet so much
discussed in the context of IEC 61850 but very important for all IEDs is the impact of restart
(power cycle) on the data model parameters. Non-agreed behaviour will raise problems for
interoperability in multi-vendor systems.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC TS 61850-2, Communication networks and systems for power utility automation - Part 2:
Glossary
IEC 61850-7-1, Communication networks and systems for power utility automation - Part 7-1:
Basic communication structure - Principles and models
IEC 61850-7-2:2010, Communication networks and systems for power utility automation - Part
7-2: Basic information and communication structure - Abstract communication service interface
(ACSI)
IEC 61850-7-2:2010/AMD1:2020
IEC 61850-7-4:2010, Communication networks and systems for power utility automation - Part
7-4: Basic communication structure - Compatible logical node classes and data object classes
IEC 61850-7-4:2010/AMD1:2020
– 8 – IEC TR 61850-7-5:2021 IEC 2021
IEC TR 61850-7-500, Communication networks and systems for power utility automation - Part
7-500: Basic information and communication structure - Use of logical nodes for modeling
application functions and related concepts and guidelines for substations
IEC 61850-8-1, Communication networks and systems for power utility automation - Part 8-1:
Specific communication service mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO
9506-2) and to ISO/IEC 8802-3
IEC 61850-8-2, Communication networks and systems for power utility automation - Part 8-2:
Specific communication service mapping (SCSM) - Mapping to Extensible Messaging Presence
Protocol (XMPP)
IEC TR 61850-90-2, Communication networks and systems for power utility automation - Part
90-2: Using IEC 61850 for communication between substations and control centres
IEC TR 61850-90-8, Communication networks and systems for power utility automation - Part
90-8: Object model for E-mobility
IEC 62351, Power systems management and associated information exchange – Data and
communications security (all parts)
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document the terms and definitions given in IEC 61850-2 and
IEC 61850-7-2 apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp/ui
3.2 Abbreviated terms
EV Electric vehicle
IL Checking Interlocking
NCC Network Control Centre
CS Checking Synchronism
4 Control
4.1 Control authorization
4.1.1 Basics
Control (control commands) crosses various layers and may require authentication and
authorization before it arrives at the controllable object. Figure 1 shows the various layers.
Figure 1 – Communication vs. application layer model for controls
• Mapping to protocol
To pass a control command from a client (which issues the control) to a server (which
executes the control command) both located in two different IEDs, the command needs to
be mapped to a protocol. For exchanges within substations and for tunnelling through
external communication systems to other substations and to the NCC a mapping to
Manufacturing Message Specification (MMS) above Ethernet according to IEC 61850-8-1 is
preferred. In addition, also mapping to GOOSE according to IEC 61850-8-1 may be used.
For the usage outside substations beside the message tunnelling and message conversion
for non-IEC 61850 communication networks especially at distribution level a mapping to web
technology protocol as described in IEC 61850-8-2 may be more appropriate.
• Control services
The flexibility of being able to choose a protocol to map to is granted thanks to the fact that
controls are defined in IEC 61850-7-2 as control services of an Abstract Communication
Service Interface (ACSI). These control services are tailored to the applications of the power
utility automation domain.
• Management of multiple control points
Where a control is an exclusive exchange of requests and responses between two peers,
network automation systems need to also allow for applications where more than one control
point may issue controls to a controllable object. The management of parallel accesses is
performed on the basis of user specific rules depending on operational philosophy.
• Authentication and authorization
The means and methods provided by the IEC 62351 series on communication network and
system security will ensure that only authenticated clients may have defined access to given
parts of a power utility automation system. It is furthermore up to the roles and to the
permissions granted to this client whether its control request to a given controllable object
is accepted.
4.1.2 Validating a control request
4.1.2.1 General
Before a control is executed, the command shall pass several steps in approval, reflecting
different aspects of validation.
– 10 – IEC TR 61850-7-5:2021 IEC 2021
4.1.2.2 Validation against the LN behaviour
The control request is forwarded to the function in charge of the controllable data object
addressed in the control service. When reaching a function for control, the LN behaviour (e.g.
represented by the actual value of the DO CSWI.Beh) shall decide whether the control can be
processed or not, following IEC 61850-7-2. Since functions are accessible via communication
in all the five states of their functional behaviour DO LN.Beh, a response has always given.
4.1.2.3 Validation against the control model
Depending on the control model which is set for the controllable object, the IED shall perform
various checks against the command. The explicit order is out of the scope of the standard
IEC 61850. Since the use of SBO control with enhanced security according to IEC 61850-7-2
is the common model for switchgear control, the current clause delves neither into direct
operate, nor into SBO with normal security.
4.1.2.4 Test whether the conditions are met
4.1.2.4.1 General
Two kinds of tests may be performed: ‘operative test’ depending on the operative condition of
the object and its process environment, and ‘dynamic test’, e.g. checking the moment of
allowance for the command to the object. In its control request the client shall specify whether
synchrocheck and interlocking check are to be performed. If the addressed function respectively
the data object does not support these checks (not implemented, not configured), the
appropriate check bits of the control request are ignored and the command is performed
directly, see IEC 61850-7-2:2010, Table 110.
4.1.2.4.2 Operative test
The control hierarchy function has to be configured according to the operations requirement of
the user. The control authority shall be checked by comparing the state (XXXX.Loc) of control
hierarchy active in the function hosting the controllable object against the order category
submitted in the actual command. Plausibility checking shall run to see whether the intended
operation does not contradict to the actual position of the switchgear. To validate the switchgear
control against the conditions of interlocking (IL) with the positions of other switchgear, the
release output of the interlocking function CILO is taken as criteria for approval (see Table 1).
The control of the switchgear shall be validated against the readiness of the equipment for an
operation (consideration of EEHealth, BlkCls, supervisions through SCBR, etc.).
Table 1 – Dependence of checking Interlocking (IL) conditions
on the control command and on the server configuration
LN, DO configuration → No IL check IL check No IL check IL check
↓ Control context
SwModKey = F SwModKey = T
no CheckCondition N N N N
from client
(NCC, station
IL CheckCondition
N Y N N
HMI)
set
from IED level not specified N Y N N
Then, upon SelectWithValue, the object is reserved for this actor, unless associated checks
(1-out-of-n, client reservation e.g.) would lead to a rejection of the control, documented with the
appropriate AddCauses. All other objects are deselected.
4.1.2.4.3 Dynamic test
In a second step, upon receipt of the Operate, the synchrocheck release (RSYN.Rel) shall be
checked (see Table 2). The synchrocheck is only applicable for circuit breakers which may
connect separated parts of the power grid.
Table 2 – Dependence of checking synchronism (CS) conditions
on the control command and on the server configuration
LN, DO configuration → No CS check CS check
↓ Control context
no CheckCondition N N
from client
(NCC, station
CS CheckCondition
N Y
HMI)
set
from IED level not specified N Y
As soon as the control passed the approval for execution on the switch controller level, the
function which is modelling the controllable data object (here: XCBR.Pos, XSWI.Pos) is
triggered. Depending on the device layout and on the functional distribution, similar checks
shall be performed in the new function and on the new object before the control finally leads to
an action of a contact at the device periphery. Figure 2 outlines the individual steps of a
command approval; the sequence of the steps is a local issue.
– 12 – IEC TR 61850-7-5:2021 IEC 2021
Figure 2 – Different levels of control authority (example)
4.1.3 Exclusive control authorization for one out of multiple actors of the same level
of control hierarchy
Operational constraints may restrict the number of active control sources to one control level
(in effect the one which is closer regarding the control circuits with respect to the controllable
object). For this, LLN0.MltLev is set to ‘False’. But still, more than one operator workstation
may exist at the same level of hierarchy, and more than one gateway computer could request
control access to the substation at the same time.
In addition, to ensure that only one control command at a time is executed in a system, the
1-out-of-n control principle shall be applied. The first actor claims for an exclusive right to issue
controls in the system. As soon as it is granted to them, controls from all other instances of
IHMI or ITCI are rejected on all servers in charge of controllable objects. After the control
execution is finished, the system-wide blocking is released. This so-called 1-out-of-n control
principle may be restricted to limited areas (subsystems) where in each of the subsystems one
object out of these different areas may be operated independently at the same time. Regarding
the common use of SBO the first set “selected” attribute is very convenient to be distributed
and block any second control approach.
4.1.4 Different control permissions for different actors of the same level of control
hierarchy
MltLev=’True’ specifies that control from multiple levels is allowed at the same time, some
topologies require different rights for different actors, even on the same level of control
hierarchy.
Example: Assumed a substation automation system is connected to two network control centres
e.g. to a local control centre and to a regional control centre. Both control centres (NCC) receive
the feedback information from the controllable objects of the substation, but their permissions
to control these objects are different:
– The local control centre is not allowed to control the earthing switch of the overhead line,
since this control centre has normally no visibility onto the remote switchgears connected
to the overhead line.
– The regional control centre is not allowed to control the incomer circuit breaker, since the
transformer is owned by the local utility.
– During the night shift, where the local control centre is unmanned, the permission to control
the incomer circuit breaker is granted to the regional control centre.
– In emergency situations the permissions may be given to the other control centre.
The application needs behind the above scenarios are not limited to controls from network
control centres; they are applicable to multiple HMIs at substation level as well.
Since the scheme of control authorities reflects the individual organization of the user and varies
from project to project, no common rule can be proposed. There is today no means in IEC 61850
to configure the control authority to support such scenarios. Therefore, these applications shall
be configured/engineered in proprietary ways to reach reliable controllability.
NOTE Ongoing modelling activities as in IEC TR 61850-90-19 and AoR in IEC 62351-8 may resolve this issue.
4.2 Control authority for process equipment
4.2.1 Control commands for process equipment from automations instead of HMI
4.2.1.1 Use case 1 – Busbar change-over
This use case defined in Table 3 is related to the issuing of switchgear controls (control
commands), especially a sequence of controls, as outputs of logics, i.e. out of the domain
substation automation. Nevertheless, this approach is valid for all domains, when commands
may be issued not only by a client but also by some automatics (logics).
– 14 – IEC TR 61850-7-5:2021 IEC 2021
Table 3 – Use case 1 definition
Use case description An outgoing line is supplied from busbar 1 of a double busbar scheme.
This line shall be changed over to busbar 2 without interrupting the
supply.
Initiator Actor Network operator initiating the change-over
Primary Actors None
Secondary Actors None
Trigger Operational reasons
Assumption list Busbar 2 is connected to incoming line B,
switchgears are available for switching, i.e. no blockings
Precondition list Outgoing bay A1: QB1 closed, QB2 open, QA1 closed
Coupling bay: QB1 open, QB2 open, QA1 open
Postcondition list Outgoing bay A1: QB1 open, QB2 closed, QA1 closed
Coupling bay: QB1 open, QB2 open, QA1 open
Flow Control to close QB1 of the coupling bay
If desired end position is reached, then
Control to close QB2 of the coupling bay
If desired end position is reached, then
Control to close QA1 of the coupling bay
If desired end position is reached, then
Control to close QB2 of the outgoing bay
If desired end position is reached, then
Control to open QB1 of the outgoing bay
If desired end position is reached, then
Control to open QA1 of the coupling bay
If desired end position is reached, then
Control to open QB1 of the coupling bay
If desired end position is reached, then
Control to open QB2 of the coupling bay
If desired end position is reached, then end
Illustration
Additional Requirements list In case of trips or user interactions during run time the sequence has
to be terminated immediately.
Notes & Outstanding Issues The sequence of controls is continued on the conditions
– that the previous step is successfully terminated,
– that the next equipment is not blocked,
– that the next step is permitted checking all conditions
applicable
otherwise the sequence is terminated.
As an option, the opening of the coupling bay may be bypassed, if
another outgoing bay shall be changed-over as well. Then, for the
second run, also the closing of the coupling can me bypassed. For the
last run, the opening of the coupling cannot be bypassed.
4.2.1.2 Solution variant A: Control commands using control services on CSWI.Pos
Since logic outputs are Boolean, each output to control a switchgear must be converted to
trigger control services (typically select-before-operate) using an external function. The
implementation of this function is a local issue. To issue controls via CSWI needs the verification
of the controls against the interlocking conditions, against the uniqueness of control (1-out-of-n)
and against the synchrocheck release as applicable.
4.2.1.3 Solution variant B: Control commands using GOOSE messages to
XSWI/XCBR
When using GOOSE messages to initiate a control directly at XSWI/XCBR, the GAPC instance
will provide a similar output interface which is provided by CSWI: SelOpn, SelCls (SPS) and
OpOpn, OpCls (ACT). Based on Ed.2.1 the LN class GAPC offers only one output of common
data class ACT. Therefore, multiple instances of GAPC are needed. The full control capability
in one instance of GAPC will be addressed in future standardization.
4.2.1.4 Solution variant C: Control commands using GOOSE messages to CSWI
To issue controls via CSWI needs the verification of the controls against the interlocking
conditions, against the uniqueness of control (1-out-of-n) and against the synchrocheck release
if applicable. If the CSWI instance implements the subscription of GOOSE to initiate a control,
then this variant is already possible today.
5 Quality and its propagation
5.1 Standard processing principle
5.1.1 General
Regardless from the further processing of the received information in the receiving LN
(respecting the Beh and LN specific calculations), the following functionality shall be provided:
– output.q.validity shall follow input.q.validity unless specified differently by the function.
– input.q.detailQual is not propagated.
– input.q.source is not propagated.
– output.q.test shall follow the rules laid down in IEC 61850-7-4:2010, Clause A.2.
– input.q.operatorBlocked is not propagated.
5.1.2 Respecting behaviour
The functional behaviour of the receiving LN is expressed by its XXXX.Beh. The data quality of
its outputs is assigned in accordance with the rules laid down in IEC 61850-7-4:2010, Clause
A.2.
– 16 – IEC TR 61850-7-5:2021 IEC 2021
5.1.3 LN specific calculations
The receiving application function uses the received information to perform its function. The
specific need of the application defines how the input status value is consumed and how the
input data quality influences the acceptance of the input status value in that function.
Application dependent rules shall be implemented in the function how to deal with questionable
or invalid inputs to always come to a useful/save result. Then the function output may be of
quality.validity ‘good’, although the input was of a worse validity.
5.1.4 detailQual is not propagated
Since the output data of an application function is based on calculations considering the data
quality of all input data, the detail quality of the input data is not directly transferred into the
output data detail quality. It is the application function itself which defines the detailQual of its
output data.
5.1.5 Configurable propagation of the value of the element ‘source’
If an information is substituted (status value and/or data quality) the element ‘source’ of the
data quality is set to ‘substituted’.
The user may want to bring to the operator’s attention the fact that a signal is being substituted.
For cases where a substituted signal is processed by another function, the input data quality
information ‘source’ must be propagated through that function to show in the resulting data
quality that input data is substituted. Typically, output data which is calculated from substituted
input data is not marked as substituted, for the substitution was not made on the output data.
As an option the propagation may be configured.
5.1.6 operatorBlocked is not propagated
If an input data to a function is operatorBlocked, the function will not receive process updates
from this input, but it continues processing using this input data as a static value. The function
may still receive updates from other inputs, contributing to a change of the output data, therefore
the output data is not ‘operatorBlocked’.
‘operatorBlocked’ is only to be found at the data which was subject to a user intervention.
5.2 Special processing principle for (single phase) XCBR mapping to CSWI
5.2.1 General
The principle is valid for both XCBR and XSWI mapping to CSWI.
Figure 3 – Single-phase monitoring of the CB position
Today, IEC TR 61850-7-500 describes which Logical Node is in charge to combine the three
single phase XCBR.Pos into a consolidated common single three phase XCBR.Pos. CSWI could
directly subscribe to the individual single phase XCBR.Pos, but more often the common XCBR
instance is seen to be used for consolidating the three phase XCBR.Pos, together with creating
the XCBR.Dsc signal if applicable (Figure 3). The single-phase modelling option of CSWI is not
considered here.
Regardless of the processing of the received information in CSWI/common XCBR afterwards
(respecting the Beh and LN specific calculations), the following treatment shall be provided for
both the Pos.stVal and the Pos.q:
a) If the information of the single phase XCBR.Pos are of the same value (closed resp. open),
then the common XCBR.Pos shall be this value.
b) If the information of the single phase XCBR.Pos are of different values, then the common
– XCBR.Pos.stVal shall be ‘bad’
– XCBR.Pos.q.validity shall be
• ‘invalid’ if at least one contributing Pos.q.validity is ‘invalid’
• ‘questionable’ if at least one contributing Pos.q.validity is ‘questionable’ and the
others are ‘good’
• ‘good’ if all contributing Pos.q.validity are ‘good’
– XCBR.Pos.q.detailQual information shall follow detailQual of the dominating validity
information.
– XCBR.Pos.q.source shall be
• ‘substituted’ if at least one contributing Pos.q.source is ‘substituted’
• ‘process’ if all contributing Pos.q.source are ‘process’
– 18 – IEC TR 61850-7-5:2021 IEC 2021
– XCBR.Pos.q.test shall follow the rules laid down in IEC 61850-7-4:2010, Clause A.2.
• If the common XCBR is not in ‘test’ and one or more of the contributing XCBRs are
in ‘test’, the three phase XCBR.Pos.stVal shall be ’bad’.
– XCBR.Pos.q.operatorBlocked is not propagated from the contributing Pos.
5.2.2 Respecting the Behaviour
The functional behaviour of the common XCBR depends on its Beh. The data quality of its
outputs is assigned in accordance with the rules defined in IEC 61850-7-4:2010, Clause A.2.
5.2.3 LN specific calculations
If CSWI/common XCBR do not contribute to the processing of the position output by internal
evaluations, the source stVal and the q shall be forwarded according to the above principle.
Internal evaluations can be:
– Switchgear movement supervision: If the switchgear started to move from one position to
the other – its Pos.stVal is set to ‘intermediate’ – but the final position is not reached,
Pos.stVal ‘bad’ can be set in place of ‘intermediate’ after the expiration of a supervision
time.
– Suppression of the intermediate position information: Some users prefer to suppress the
intermediate position signal (stay with the prior state) until the final position is reached. If
the above movement supervision is used and active, ‘bad’ state is transferred in case of
defects after the expiration of a supervision time.
5.2.4 Propagation of detailQual
The cascading of CSWI, common XCBR and single phase XCBR shall not lead to a deprecation
of the detailed quality information provided by an XCBR. Unless contributed by a specific
functionality, CSWI does not provide an add-on (internal evaluation) to the data validity of
position information. Receiving functions like IHMI or automations might be interested in
receiving the information ‘oscillatory’ of XCBR.Pos to act upon this in a specific way.
5.2.5 Substitution of switchgear position signals
Before coming to forwarding of substituted values, the object of a substitution shall be
discussed.
Once a user inte
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...