See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/310358195

IEC 61850 Edition 2 and Engineering

Article · December 2014

CITATIONS READS

2 3,657

1 author:

Wolfgang Wimmer
ABB, Baden, Switzerland
41 PUBLICATIONS   146 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Topology based interlocking View project

System Engineering View project

All content following this page was uploaded by Wolfgang Wimmer on 16 November 2016.

The user has requested enhancement of the downloaded file.

 by Wolfgang Wimmer, ABB Switzerland

28
One of the big differences be-

IEC 61850
tween IEC 61850 and other
IEC 61850

communication protocols is that

Edition 2
from its very beginning it consid-
ered the engineering of automa-

and
tion systems. Edition 1 already
described roles and phases of
Edition 2 and
Engineering

Engineering the engineering process in part

4. The SCL language of part 6
provided a vendor independent
Wolfgang
Wimmer works means to describe IED functions
for ABB Switzerland in
Baden. He is Principal and IED engineering capabilities as well as complete systems as a means to transfer the syntax
Engineer in the devel-
opment of substation and semantic of project specific messages between communicating IEDs possibly of different
automation systems.
Wolfgang has a Master vendors in an interoperable way at least between the IED engineering tools, if not directly to an
of Science degree
as well as a Ph.D. in IED. For sure Edition 2 fixes errors, inconsistencies and unclarities of Edition 1. Further, there are
Computer Science
from the University of additions to partially overcome problems experienced with Edition 1, due to new functionality
Hamburg. After some
years of developing needed for other application areas. For backwards compatibility all additions are optional.
Computer networks at
the German Electron
Synchroton DESY in

1
Hamburg Wolfgang
Wimmer made a Substation-substation communications configuration description
change. He went
to work for ABB for
the development of Substation AA1 Substation AA2
train control systems,
later Network Control
Systems. Wolfgang
has more than 20
years of experience 61850 Bus, Subnet AA1WA1
with development of SW1 SW1/2
substation automation
systems. Wolfgang is
a member of IEC TC57 AA1F AA1F AA2F AA2F
WG 19 and WG 10.
He is also an editor
of IEC 61850-6. He
SCD1 SCD2
has written many
papers at conferences
worldwide. SED

PAC.DECEMBER.2014

Thus, if the new features shall
be used, it should be checked if the
envisioned Edition 2 IED has really
implemented it.
In practice the first actual us-
age of the SCL language at system
level was the functional and nam-
ing related specification of projects,
leading to some unintended error
prone usage of IED related SCL files
during the engineering process.
Thus one of the biggest issues for
edition 2 was to better clarify the
usage of SCL files and the respon-
sibilities of system level and IED
level tools for certain parts of an
SCL file at different phases of the
engineering process. This started
in IEC61850-4 Edition 2 by tak-
ing up the basic engineering related
concepts of part 6 and integrated
these into the engineering process
definition. It is continued in part 6
itself in the context of the SCL lan-
guage. Below we will take the part
4 engineering process as a guide
through this process and explain
the basic new engineering related
features of Edition 2 for these phas-
es. As a start an overview across the
whole process according to part
4 with additional consideration
Beneath fixing problems detected
of corrective actions in individual
phases is given in Figure 2.
System Requirement
Specification
The customer (project require-
the Edition 2 streamlines the
ment engineer in part 4) defines
the requirements for his system.
Edition 1 already provided the SCL
based SSD file (System Specifica-
tion Description) as a formal means
for defining the process related
functional names of all switchgear,
and define at IEC 61850 logical
node and data object level which
functions respective functional in-
terfaces are expected for which part
of the primary equipment. Edition
2 allows some more previously
forgotten primary equipment to
be modelled, however also broad-
ens this to hierarchical modeling of
arbitrary functions, e.g. bay protec-
tion / distance protection / protec-
tion zone / impedance protection
with appropriate customer desig-
nations. Further it supports addi-
tional customer function types as
well as types standardized by other
29
during the usage of
IEC 61850 Edition 1,
engineering process.
application areas, thus opening up SCL for Figure 2
modeling other primary processes and not presents an
just substation automation, as long as the
function designations are hierarchically overview
built according to IEC 81346. This formal across the
system functional specification allows al-
whole process
ready automated consistency checks e.g.
on signal names or missing function parts. according to
This enhancement of the SCL sub- part 4 with
station structure additionally allows to
additional
have unique, mainly customer defined
functional names for each logical node, consideration
and thus for each data object. This is an of corrective
important feature to have higher level re-
spective application level engineering in- actions in
dependent from the physical allocation of individual
logical nodes to IEDs respective indepen-
phases.
dent from the IED related names given by
manufacturers, thus supporting functional
application testing and simulation before

2 Overall engineering process according to part 4

Customer Requirements
IEC 61850-4 phase
Eng. Tools
Consisyency Input
Process description
System Requirement
Checks Function specification specification
Simulation System configuration
Output
Specification
Model

Specification Approval
System Design
Project specification
Data Base
Eng. Tools
Input
Consisyency
Specification
Model
System Configuration
Facilitated Checks Detail specification
Output
by Documentation
Corrective
Load files
IEC 61850 Modifications IED Configuration
Factory
Acceptance Tests
Archive Factory Acceptance
Test

Adaptive
Site Acceptance Tests Maintenance
As Built
Site Acceptance Test
Operation &
Operation Maintenance

PAC.DECEMBER.2014
 by Wolfgang Wimmer, ABB Switzerland

30
any physical application architec- available client services, limits of In addition,
ture is decided. For more details data flow engineering etc. allow-
Edition 2 clarifies
IEC 61850

see also PACWorld from spring ing a more fitting IED selection as
2008, Designing IEC 61850 sys-
tems for maintenance, retrofit and
well as a more secure IED system
engineering by a system tool. One how future versions of
expansion.
Specification of the System
should observe however that a
performance check still has to be
the standard are kept
Design done. If IED performance limits are interoperable.
The system design specifica- known, this can be automated to a
tion is the response of the system certain extent, otherwise manual
integrator (project design engineer work or even IED (type) testing is system integrator with the sys-
in part 4) to the system require- needed. Edition 2 allows to model tem configuration tool. For this
ment specification of the customer. the communication system itself the algorithms of all applications
Edition 2 and
Engineering

Based on the requirement specifi- by introducing switches as IEDs in terms of needed input signals
cation (e.g. including an SSD file) and cables connecting the switches need to be known, so that the data
IEDs fulfilling the needed func- as well as the IEDs to the switches, flow between the logical nodes on
tionality are selected, the commu- even with redundant links. Thus the physical IEDs can be config-
nication in between engineered, a formal description of the com- ured in the system configuration
and the communication system munication system exists, offering tool by once again using the IED
designed to support the needed a base for checking its consistency capabilities to assure that the sys-
Figure 3: An functionality and quality proper- and redundancy as well as how it tem engineering time a working
overview ties. The selection of IEDs can be fits into the physical geography system. Subsequently, or in paral-
built on the formal SCL description of the project. The result of this in lel, the detailed engineering of the
about all the of an IED called ICD file provided terms of part 6 is the SCD file (Sys- IEDs (IED configuration) respec-
SCL file types typically by the IED manufacturer, tem Configuration Description), tive IED types will happen, accord-
describing the IED functionality in even if the detailed data flow be- ing to part 4 as performed by the
mentioned
terms of logical node instances and tween the IEDs is still missing. IED parametrizing engineer with
above and its engineering and communica- System Configuration the IED configuration tool. This
between which tion capabilities. Here Edition 2 After customer approval of the as well as modified specifications
has added more details and more system design specification the may lead to changes of function-
tools they shall
options for the available commu- detailed system configuration can ality or function interfaces on an
be used. nication redundancy protocols, start, according to part 4 by the IED. To be able to bring this back to
the system configuration without
having to re-engineer all applica-
3 IEC 61850 Ed2 enhanced engineering tool data exchange tions in which the IED is involved,
Edition 2 introduces the concept of
System specialization an SCL based IID file (Instantiated
.SSD (Single line, LN, ... ) IED Description) together with
IED Capabilities
(LN, DO, ... ) well-defined rules what is allowed
IED System .SED System to be changed on an IED already
DB .ICD Configurator Part system Configurator integrated into a system, and how
Associations, this changed description is merged
Relation to single line, .SCD .IID .SCD back into the system configuration.
preconfigured reports, ...
This Edition 2 concept streamlines
IED Other IEC 61850 project the ‘Corrective Modification’ ac-
Configurator with interfaces between
Engineering projects tion shown in Figure 2. Note that
Engineering Workplace IID files can also be used for IEDs
environment File transfer SED: System exchange specifically adapted to a certain role
.CID remote IID: Instalation IED inside a certain project. This is typi-
File transfer
File transfer and cally the case for station level func-
Substation Parametrization with tions specifically adapted to the
Local gateway IEC 61850 servicea
project single line, like gateways
or the transformer autoclose func-
IED IED IED
tion as described in paper OP010
of the PACworld conference 2011
in Dublin (Figure 1).

PAC.DECEMBER.2014

Further it broadens the application
space of the base standard to further
application areas.
Additionally Edition 2 in-
troduces the usage of IEC61850
between several substation auto-
mation systems due to the need of
teleprotection functions. The thus
needed exchange of interface in-
formation between system tools is
supported by definition of the SED
file (System Exchange Descrip-
tion) including some rules speci-
fying how engineering rights for
interfaces are exchanged between
the system tools. This SED file can
naturally be used to exchange sys-
tem interface definitions between
all types of communicating (part)
systems, not just for teleprotection.
For a deeper discussion of this topic
see the paper P043 of the PAC-
World conference 2010 in Dub-
lin about ‘Engineering a system of
systems’.
At the end an SCD file can de-
scribe the physical architecture of
a system in terms of communi-
cating IEDs and switches as well as
the signal flow related architecture
between logical nodes in a formal-
ized way. Additionally to deliver-
ing a formal documentation of the
engineered system this is the base
for a lot of system checking func-
tions, from system performance
via system availability to system
function simulation, and can serve
as base for a translation between
func-tional names, IED and com-
munication related names as well
as communication addresses.
IED Configuration
The detailed engineering of an
IED and its functions respective
project related function input is
performed with the IED configu-
ration tool, according to part 4 by
the IED parametrization engi-neer
role. Edition 2 tries to clarify dif-
ferent use cases for this tool depen-
dent on the engineering flexibility
31
trol block definitions and for data model Additionally
definitions the Edition 2 additionally pro-
vides revision information on configura- Edition 2
tion data values and parameter setting
values.
introduces
Edition 2 also introduces port redun- the usage
dancy for communication. As redundancy
and configurability of the IED types only enhances the availability if it is super- of IEC61850
to be handled. One of the big issues vised to facilitate fast repair of failed parts,
between several
with Edition 1 was that the division Edition 2 introduces communication port
of work between IED tool and sys- supervision for both ports by means of the substation
tem tool was not clearly understood. LCCH logical node. Naturally this logical
This is clarified in more details in node can also be used for error statistics if automation
Edition 2. Its SCL Implementation only a single port is used. Additionally the
Conformance Statement (SICS) LGOS and LSVS logical nodes allow super- systems due
specifies mandatory functions of vision of GOOSE and Sampled Value (SV) to the need of
IED tool and system tool as well as streams per sender control block instance
additional meaningful engi-neering at a receiver. They can distinguish between teleprotection
functions, allowing to judge in ad- ‘nothing received’ and ‘received message
vance if the functionality of system has wrong configuration’, thus detect- functions.
tool and IED tool fit together. For ing not just reasons for restricted func-
IED tools the SICS is mandatory and tionality due to missing inputs, but also
will also be tested together with the configuration mismatches of senders and
IED in conformance tests according receivers. Finally the LTRK logical node
to IEC 61850-10 Edition 2.
Some small SCL additions at data
object value level support the usage 4 IED type description to system
of SCL as a medium to bring configu- configurator
ration and setting parameter values
down to an IED – either by direct IED1
file transfer, if the IED can interpret ure ICD Insta
onfig ntiat
Prec
the SCL, or by a manufacturer inde- with name
Template
e
pendent tool using IEC 61850 com- System
Template
mu-nication services to write these Configurator
IED
values onto the IED – if the IED sup- Configurator IED1 IEDn
ports these optional services and the Final exchange with each IED
appropriate part of the data model. Configurator
In any case a SCL file can be used as IED1
a standard medium to archive these IEDn
values and later on compare them
SCD
with the actual values on the IEDs.
Figure 3 gives an overview about
all the SCL file types mentioned 5 IED instance description to system
above and between which tools they configurator
shall be used. Red circles mark the IED1
new file types of Edition 2. r Merg
ify o IID
Commissioning and Testing Mod figure e or
Add
on with name
Prec
A good start for commissioning IED1
or testing is to compare all version System
IED1
Configurator
and revision information contained IED
in a final SCD file against the version Configurator IED1 IEDn
and revision information accessible Export for modifying of an IED
with IEC61850 read services on the
IED1
IEDs. Beneath the already introduced
IED hardware and software version SCD
tags as well as revision tags for con-
PAC.DECEMBER.2014
 by Wolfgang Wimmer, ABB Switzerland
32
allows to track all MMS based com-
munication services as well as the
IEC 61850
responses, thus allowing to track
also unsuccessful commands.
During commissioning of a
system it is expected that every-
thing can be tested without any un-
wanted influence on the process.
Nevertheless it may be that in this
state especially analog data is not
available for all needed tests. For
this purpose Edition 2 concretizes
the usage of GOOSE and SV simu-
Edition 2 and
Engineering
lation messages by its simulation
concept. An IED can be switched
to receive simulation messages in-
stead of the real ones. The LGOS
/ LSVS logical nodes then show
if any simulation messages are re-
ceived and are used or not. This is
illustrated in Figure 6. The LPHD.
Edition 2 also Sim data object of the IED is set to
TRUE, thus allowing the process-
allows to keep ing of simulation messages by the
IED. The LGOS / LSVS.SimSt data
the names of object shows that for the config-
ured control block simulation mes-
the incoming
sages are received and processed.
signals online
If any influence on the process
shall be blocked, the logical node
readable behavior blocked can be used, as
shown for the XCBR.Mod. As
in special Figure 6 shows, Edition 2 has also
introduced additional data object
reference data attributes which allow to check
if an action would have been per-
objects at each formed even if the LN mode is
blocked. The attribute opRcvd
logical node. indicates that a trigger for an op-
6 Simulation messages
GOOSE / SV with Test Client
simulation flag
IED
LGOS / LSVS
SimSt = TRUE PTRC
Mod = ON
LPHD
Sim = TRUE InRef Op
PTOC
Mod = ON Op
PAC.DECEMBER.2014
eration respective a command has
been received, and opOk shows
that it has been executed or would
have been executed in case the
mode would not be blocked.
Another feature of Edition 2
which can support commissioning
is that it allows to keep the names
of the incoming signals online
readable in special reference data
objects at each logical node. InRef
data objects are for incoming sig-
nals in general, while BlkRef indi-
cates signals leading to blocking of
the LN function. However for this
purpose mostly the SCL level Input
section is sufficient.
Maintenance and Testing
If during maintenance new
setting values or enhanced func-
tionality needs to be tested, this
needs to be done in the running
system without influencing the
unchanged functions, sometimes
even without influencing the
process. In classical automation
systems special input and output
HW terminals can be used for this
purpose, allowing to separate the
process from the IED hardware
outputs and inserting test input
signals. For an IEC61850 system
with distributed functions and es-
pecially a process bus, where the
process near IEDs are integrated
into the switchgear, this is not so
easily done. The elaborated test
concept of Edition 2 therefore al-
lows virtual disconnecting ter-
Receive XCBR action
XCBR
Mod = Test/blocked
OpRcvd,
OpOK
output
Blocked prohibits
CBR open
The promise of
IEC61850 is long term
stability of systems
even if hardware and
software technology is
changing.
minal blocks. One cornerstone of this is the
clarified and mandatory definition how test
mode and incoming signals with test quality
from another logical node are working togeth-
er. This and the above mentioned additional
attributes opRcvd and opOk realize a virtual
separation at the inputs and at the outputs with
a back indication if a command would have
been executed or not. To provide test inputs,
the InRef and BlkRef data objects mentioned
above allow to switch in test mode from the
real input signal to some test input signal. This
is illustrated in Figure 7.
In the shown situation the InRef1 input of
the PTRC, which is currently in test mode, is
switched from the operational signal PTOC.
Op.general to the test input TstGGIO.SPC-
SO1.stVal by setting InRef1.tstEna to TRUE.
This test input can then be set from a test client
to any value needed for the test with standard
IEC61850 services. The actual operation of the
circuit breaker by the XCBR is prohibited by
the blocked mode as described above.
Life Cycle Issues
The promise of IEC61850 is long term sta-
bility of systems even if hardware and software
technology is changing. Now we have already a
second edition of the standard itself, and more
will follow. Thus Edition 2 also attacks in more
detail how this problem shall be solved.
For this it details the concept of name spaces
with versions and revisions for data model and
application functions as well as for the SCL lan-
guage (see IEC61850-7-1).
Identical name spaces are meant to be in-
teroperable. To assure this, inside a name space
the mayIgnore / mustUnderstand concept is
introduced. Anything which a tool or IED does
not understand, it can safely ignore. Some-
times, especially in the SCL language, it might
happen that a tool can use a (seemingly known)
feature only if it also understands all lower level
details. In this case these details are marked as

‘mustUnderstand’, indicating that
if you do not understand this, you
must also ignore the higher level.
To keep backwards operability,
the semantics of existing parts is
not allowed to be changed, and a re-
moval must be done very carefully.
Normally changed features are just
‘deprecated’ so that they may van-
ish after some new versions. Nev-
ertheless new versions like Edition
2 add new stuff. In order to be able
to do this, all new matters are op-
tional from a standard point of
view, or have a reasonable default
value if they are missing. Thus any
user of the option must be prepared
in the event that in a certain appli-
cation the addition does not exist.
Still. the standard is done by
humans who are not perfect, thus
sometimes corrections are needed,
which might lead to interoperabili-
ty problems. These corrections lead
to revisions of a certain version, and
need to be implemented as fast as
possible even between editions to
keep the amount of any possible
interoperability problems as small
as possible. More on this issue may
be found in paper P084 of the PAC-
World conference from 2013. Al-
though the details of this concept
have been clarified in Edition 2, it
can be expected that any Edition 1
IED having fixed all technical issues
known before Edition 2 was pub-
lished is interoperable with Edi-
tion 2 IEDs and tools. The goal for
the future is to have full interoper-
ability between editions (versions)
and as less revisions of a version as
possible.
Interoperability problems may
appear at different levels: commu-
nication service, application mod-
eling, application implementation,
SCL data exchange. Application
implementation issues are depen-
dent on the algorithmic imple-
mentation of functions, especially
their needed input signals. Thus
this must be assured by the system
integrator by understanding these
implementations on the selected
IED types.
View publication stats
33
Edition 2 also introduces redundant
communication at communication port level as
well as a lot of features supporting maintenance,
commissioning and testing.
SCL data exchange backwards be used by all data models of all application Figure 7: To
from Edition 2 to Edition 1 might areas. This means that especially private com-
be a problem, if the Edition 1 tools mon data classes are no longer allowed. provide test
do not implement the mayIgnore / Due to the introduced mayIgnore / mus-
mustUnderstand feature. However, tUnderstand concept it can be expected that
a tool from Edition 2 or later should future editions of IEC61850 across all of its' inputs, the
always be able to handle Edition 1 application areas will be even better interoper-
SCL. Application modeling is an able than Edition 1 and Edition 2. The intro- InRef and BlkRef
issue for tools automating the en- duced SCL service and engineering capabilities
gineering. However, as there are especially for ICD files together with the im-
data objects
not that many tools on the market plementation conformance statements for
related to this subject, it is more protocol services, application functions and
of a future problem and thus will data model and the engineering features of mentioned here
hopefully be solved with Edition tools will further support system integrators
2. In order to get the probability of in the selection of tools and IEDs which fit to-
allow to switch
revisions low, the working groups gether, before they are really used in a project.
around IEC61850 have started to And this applies not just to new projects, but
check all of their models by model- also to maintenance and extensions of already in test mode
ing them in UML. existing systems.
Finally, for the communication Conclusion from the real
level interoperability, only very few Beneath fixing problems detected during
changes have been done in Edition the usage of IEC 61850 Edition 1, the Edition
2. The add-ons are optional, i.e. 2 streamlines the engineering process, clari- input signal to
Edition 2 clients must be prepared fies how future versions of the standard are
that they are missing and must han- kept interoperable, and introduces redundant some test input
dle this. To avoid further interop- communication at communication port level
erability problems here, Edition 2 as well as a lot of features supporting main-
also restricts the definition of the tenance, commissioning and testing. Further signal.
service related common data class- it broadens the application space of the base
es to IEC61850-7-3, which must standard to further application areas.
7 Functional testing
Test Client Receive XCBR action
Trigger trip
LGOS / LSVS
SimSt = TRUE
SPCSO1 PTRC XCBR
Mod = Test Mod = Test/blocked
tstEna = true / false OpRcvd,
InRef1 OpOK
Op output
InRef2
PTOC
Mod = ON
Op
Blocked prohibits
CBR open
PAC.DECEMBER.2014