by Dr. Wolfgang Wimmer, ABB, Switzerland
Designing IEC 61850 systems
for maintenance, retrofit and extension
The goal of IEC 61850 is to support arbitrary system configurations with
centralized or decentralized architecture. The choice of a specific system architecture
is beneath pure technical aspects determined by the existing products and proven
solutions. As technology advances, other kinds of architectures may become usable
and cost optimal, which lead to a different amount of IEDs and a different internal
structure of them, which is reflected in the IED related identification of data. On the
other hand, low effort long term maintenance needs identical names for identical
objects. But even at the replacement of an IED by a functional equivalent IED from
another manufacturer a different internal structuring and naming is most likely.
Engineering
IEC 61850
46
Usage of names
Names are used at system
engineering time to establish
relations between the different parts
of the system: Relations between
the switch yard (primary system)
and the IED signals (secondary
system), and data flow between IEDs
for communication engineering
respective online communication
association establishment. A name
change at a data source therefore
leads to reengineering of all IEDs
connected to the changed one
respective replaced one. In former
master slave architectures all data
flowed between the bay level IEDs
and one single central place, only
the IED to be replaced and the
central IED were concerned. For
IEC 61850 however already for
availability reasons several station
level IEDs might be connected to
the same bay level IEDs, and the new
Wolfgang Wimmer works for ABB Switzerland in Baden. He
is principle engineer in the development of substation automation systems. He has a M. Sc. degree as well as a Ph.D. in
Computer Science from the University of Hamburg. After some
years developing Computer networks at the German Electron
Synchroton DESY in Hamburg he changed to ABB (former BBC)
for development of train control systems, later Network Control Systems. He has more than 20 years experience with development of substation automation systems. He is a member of
IEC TC57 WG 19 and WG 10, and editor of IEC 61850-6.
PAC.SPRING.2008
communication services GOOSE
and SMV (Sampled Values) allow
new substation functionality or
existing functionality with less
engineering effort and higher
reliability, however introduce
multiple sinks for certain signals,
which might be concerned by
a change at the signal source, as
illustrated in Figure 1.
IEC 61850 object types and
data identification
IEC 61850-7 introduces IED and
communication modelling concepts,
and standardized data semantics
by standardized names. However,
the concrete instance names are
additionally dependent on the
physical and logical structuring of the
data and therefore not a priori stable
when replacing IEDs or changing
the architecture. What is long term
stable (as least as long as the switch
yard itself), is the functional meaning
of the data in relation to the switch
yard respective the power delivery
process. Further the substation
automation functionality related
to the switchyard is normally long
term stable, although extensions
are not excluded. Therefore IEC
61850-6 introduces a second way of
identifying the same data, namely by
functional designations as defined in
IEC 61346.
IED related objects and
their identifications
IEC 61850 as a communication
standard in first line addresses data
identification at communication
level, i.e. at interface level between a
server or publisher IED and the data
receivers (clients, subscribers). To
make this naming independent from
the physical structure, the concept of
a logical device (LD) is introduced as
a management unit for functional
parts. Figure 2 shows the resulting
internal structure of an IED. The communication function
uses IED access points to connect
clients with servers. In principle
each logical node can be a client to
other logical nodes on some server.
IEDs which only receive data, like
the OPC server AA1KA1 in Figure
1, can also be pure clients without a
server.
To reach the goal of having
standardized semantics, the DATA
names as well as the names of
DATA attributes are completely
standardized. Also the semantic of
the logical nodes is standardized by
means of a logical node class, which
is part of the logical node instance
name. A real system needs instances
of logical node classes, which are
associated to different parts of the
switch gear; therefore the LN instance
47
identification has non standardized
parts. The logical device name as
a manufacturer / organisation
related structuring is completely
free within some syntactical limits.
This is illustrated in table 1 with an
example designation for a switch
position value within the switch
control function:
MyControl LD1/Q0CSWI3.Pos.
stVal
A product manufacturer typically
provides IEDs as products with
some predefined functionality,
however with no context to the
project specific usage. Therefore the
LD relative name and some parts of
the LN instance identification need
to be given by the manufacturer
independent of the unknown
project, and might be needed after
project engineering to associate the
project specific data to the project
independent preconfiguration of
the IED. Therefore it is manufacturer
dependent, which parts of the
LN instance identification can be
adapted specifically for a project.
Although this designation is
mainly used for communication
establishment, we might call it a
‘product related’ designation in the
sense of IEC 61346-1, especially if
the IED designation is used as part of
the LD name.
From this discussion we see
how the physical architecture
influences the communication
level naming. Table 2 illustrates
this with two logical nodes for
the control function: the CSWI
handling control commands
from the operators and the XCBR
executing these commands at the
circuit breaker. The architectures
referenced in the table are illustrated
in Figure 5.
Consequence: different physical
architectures by grouping on IEDs
as well as different organisational
structures by means of logical
devices lead to different names, even
if an IED and its tool supports free
naming for the non standardized
parts. And the free naming is not
mandatory according to IEC 61850,
and naturally introduces additional
engineering and testing effort –
especially at LN instance level.
Function related objects
and identifications
According to IEC 61346 the
functional designation is at least as
important for operation of a process
as the product related naming for
maintenance. IEC 61850-6 therefore
introduces application related
names of data by typically following
the functions of the switch yard,
however allowing additionally (with
Usage of application
oriented functional
names in parallel to
maintenance
related IED names
with automatic
translation via
SCL files, enhances
long term system
maintainability
Edition 2 practically at all places)
functions which are not directly
switch yard related, like protection,
control and automation functions,
but also supervision functions
outside the substation function itself
like fire supervision, or functions
belonging to power generation. The
functional names are completely
project / customer specific within
the structural restrictions given by
IEC 61346-1. The transition object,
i.e. the place where product related
name and function / application
related name matches the same
Figure 1
of a small
StatUrg
StatUrgC1
Color code:
GOOSE
interlocking
system
reasons, the
controllers
exchange
GOOSE
messages.
The
replacement
1 Data
flow between IEDs in the substation
Example of a small system with an OPC server & a gateway as station level IEDs
AA1KA1
OPC Server
P2WA1
For
an example
of IED P2KA1,
Unbuffered
influences
3 other IEDs.
P2Y1
COM581
***GW***
StatUrgC1 P2KA1
REC 670
StatUrgM1 P2WA1
MeasFlt
The four
Interlock
P2KA2
C264
P2WA1
controllers in
different bays
are sending
P2KA3
Siprotec-7SJ6xx
P2WA1
StatUrg
Positions
Positions
reports to the
P2FA1
REL 670
P2WA1
StatUrg
Interlock
Interlock
Interlock
station level
P2KA4
RED 670
P2WA1
IEDs.
PAC.SPRING.2008
Engineering
IEC 61850
48
IEC 61850
object, is the logical node instance.
From here on all DATA and attribute
names are completely semantically
defined in IEC 61850. If we look
into the functional names of figure
3 for the same control function
handled by the IED related names of
table 2, these are:
AA1E1Q3QA1CSWI.Pos
AA1E1Q3QA1XCBR.Pos
The protection related name of
the operation of distance protection
for Zone 1 is:
AA1E1Q3F1Z1PDIS.Op
All these names are completely
independent from the distribution
of logical nodes and logical devices
to IEDs, and also from the LD and
LN instance names.
A complete SCL file for a
substation automation system,
called an SCD file, includes the
functional name, the IED related
name, the communication related
(LD) name, and the relations
between them – thus serving as a
data base for translation between
the different designations for the
same LN respective DATA object.
This is shown in Figure 4 for the
above example, illustrating the
independence of the functional name
from the IED related name up to the
point where IEC 61850 provides
complete semantic standardization.
Communication engineering
IEC 61850 MMS based services
allow an interactive browsing of
the IED data model to retrieve all
communication related names. Due
to the unique LD name these can be
translated into IED related names as
well as functional names by means
of the SCD file. However, normally
operational traffic is based on
preconfigured data flow for services
allowing spontaneous sending.
These are typically:
Reporting service for status
update and time stamped events to
station level IEDs like HMI, or
gateways to network control
centres.
GOOSE real time service for
real time functions typically between
bay level IEDs, or down to process
level IEDs, e.g. interlocking related
data or protection trips and
blockings.
SMV services, if analogue
samples are needed directly from the
process, e.g. for protect ion,
synchrocheck and measurement
functions.
To evaluate the importance of
the DATA names for these services,
we have to look a bit into their
definition:
All services are configured by
means of a data set, defining the
hierarchy
Substation AA1
Voltage level E1 at 110kV



Bay Q3
Equipment QB1 : DIS
XSWI, Name /XSWI of Type m_XSWI
CSWI, Name /CSWI of Type E3_CSWI
CILO, Name /CILO of Type m_CILO
Equipment QA1 : CBR
XCBR, Name /XCBR of Type E_XCBR
CSWI, Name Q3QA1/CSWI of Type E3_CSWI
CILO, Name Q3QA1/CILO of Type m_CILO
Equipment BE5 : VTR
Function F1 : Protection
PTRC, Name /PTRC of Type E3_PTRC
PSCH, Name /PSCH of Type E3_PSCH
PTEF, Name /PTEF of Type m_PTEF
Subfunction Z1 : Distance zone 1
PDIS, Name /PDIS1 of Type E3_PDIS
Subfunction Z2 : Distance zone 2
PDIS, Name /PDIS2 of Type E3_PDIS
Subfunction Z3 : Distance zone 3
PDIS, Name /PDIS3 of Type E3_PDIS
Subfunction Z1B :
PDIS, Name /BPDIS1 of Type E3_PDIS
Function R1 : ProtRelated
RREC, Name /RREC of Type E3_RREC
RFLO, Name /RFLO of Type E_RFLO
Function M1 : Measurement
MMXU, Name /MMXU of Type E3_MMXU
2 IED related object model structure
Client association
Inter bay bus Access point
1 logical, several physical
MMS based
services allow
3 Example of a function
The server access point allows
access to data structured as
IED
interactive
follows: logical devices contain
Server
Logical Device
LN
browsing of
DO DO
the IED data
LN
DO
Logical Device
LN
DO
LN
DO
logical nodes (LN) containing
DATA respective data objects
(DO). Logical nodes on other IEDs
model.
Client associations
I/O
Process bus access point (can be same as above)
PAC.SPRING.2008
can access the data as clients
49
data to be spontaneously sent, and
a control block, defining when and
how it shall be sent, as illustrated in
Figure 6.
The reporting service only
sends the changed data values. A bit
pattern in each report identifies the
place of the data set to which the sent
data values belong.
For GOOSE and SMV services
always all values of the whole data
set are sent. The order of values in the
message corresponds to the order of
the data items in the data set
definition.
This means, that essentially
the values sent on the wire do not
contain any of the names considered
earlier, just the relation between the
sent values and their place in the data
set definition. For correct message
interpretation the receivers only
have to know, to which data set the
message belongs, and how this data
set looks like. For reports this can be
established dynamically by means
of the browsing services or data set
creation services, however also by
static configuration with a common
SCD file as base. The relation
between the online message and the
data set definition then is established
as follows:
Reports are MMS based and
MMS a ssociat ions must be
dynamically established. A report
client either builds its own data sets
dynamically (if the servers support
this), or uses preconfigured data sets.
If he relies on preconfigured data
sets, he can check at start-up the
control block revision number on
any discrepancies between static
definition and actual definition on
the IED.
GOOSE and SMV messages
work according to the subscription
principle and are permanently sent.
The message contains Ethernet level
identifications like Multicast address
and application identification
(AP P ID), and the d at a set
identification in the form <LD
name>/<LN Name>.<Data set
name>, which allows the subscribers
to identify and filter the correct
message fitting to the DATA they
want to use from their static
configuration based on the SCD file.
A control block revision number,
always sent in the message, allows
receivers to detect any discrepancies
in data set layout configuration
between sender and receivers.
This interpretation of messages
relative to a data set definition allows
to replace e.g. a GOOSE publisher
by any other IED without having to
reconfigure the receivers, as long as
the new IED.
Different physical
structures enforce
different IED related
data identifications at
IED/LD/LN level
Contains the data of the old
GOOSE message with same data
types and same semantics (functional
equivalence).
Contains or allows configuring
a data set with the same type of data
values in the same order and same
semantics related to the project as
the old IED.
Uses the same Ethernet level
addressing (Multicast address,
APPID, VLAN).
Has the same full data set name:
same LD name (if freely configurable
on the IED), same LN name (LLN0
for all GOOSE and SMV messages),
the same data set name (mostly
configurable at the IED for GOOSE
and SMV data sets), and the same
configuration revision number
(needs free setting by the tool
creating the data set, or some tool
support for the replacement).
4 Connection of functional and product related naming–example
Substation: AA1
IED: Ctrl9
Voltage level: E1
LD: LD1
Bay: Q3
Switch: QA1
of the functional identifi-
LN (class) : CSWI
LN: QA1CSWI 1
cation (left) down to the
LN class are completely
DATA: Pos
independent from the IED
Attribute: stVal
Functional name:
AA1E1Q3QA1CSWI.Pos.stVal
The structuring and naming
IED related name:
Ctrl9LD1/QA1CSWI 1.Pos.stVal
related name (right)
PAC.SPRING.2008
IEC 61850
50
Table 1 Degree of name standardization
IED structure
level
Degree of standardization
Example
designation
Stan- Predefined nadardized me semantic
Logical device LD
Syntactical (61850-7-2)
MyControlLD1
---
---
100 Kb/S
Partly: LN class (61850-7-4)
Q0CSWI3
CSWI
Switch control
200 Kb/S
Full: DATA name (61850-7-4)
Pos
Pos
Switch position
Attribute
Full: Attribute name (61850-7-3)
stVal
stVal
Status value
Engineering
For maintenance it is recommended to choose an IED related logical device name,
structured as IED name - LD relative name
Table 2
Name differences caused by architecture
Architecture
LD Name
DATA
LN Name Name
Single bay
controller
Process bus from
bay controller to
circuit breaker
interface
Central controller
with process bus
to circuit breaker
interface
Ctr19LD1
Ctr19LD1
Q0CSWI1
Q0XCBR1
Pos
Pos
LNs located in same LD
Ctr19LD1
SWg8LD1
Q0CSWI1
QA1XCBR4
Pos
Pos
LD (IED) name at switch interface IED must
be different to name in bay controller; LN
instance names are manufacturer specific.
Ctrl11LD9 Q0CSWI1
SWg8LD1 QA1XCBR4
Pos
Pos
Free LD naming would allow using centrally
the same LD names as de-centrally – if the
central LD structure is the same.
This means that the replacing IED has
beneath the requirements on compatible
semantics and data types to fulfil some
engineering related requirements, which
are not mandatory according to IEC 61850.
Further it should be considered that errors
at the reconfiguration of the data set when
keeping the old revision number and data
set identification can be safety critical,
because the receivers do not demand to be
newly configured. So, a good tool support
or testing in a simulated environment is
recommended.
Remark
The problem of binding GOOSE or
SMV receivers to the data set layout does
not appear for reporting clients, because
they can perform this binding dynamically.
However, if the names have changed,
the binding to the functional semantics,
especially binding of LN instances to
instances of switch yard equipment and
functions, is still a problem. One means
to solve this binding to the application
function is to re-establishing the link
between functional names and IED related
names also for the new IED(s). This is
Use functional
names as a key
between old
and new
configurations
supported in IEC 61850 better than
in other protocols in so far, as this
binding is done on the level of logical
nodes instead of signals, and will in
all cases, where application specific
LNs are used (e.g. no GAPC and no
GGIO), reduce to a selection of LN
instances with the same LN class,
thus minimizing the amount of
work as well as that of errors.
For good implementations of
station level clients, which internally
work with the functional names as
defined above, it is then sufficient
to reload them at driver level with
the SCD file resulting from this
re-mapping of LN instances.
Even better client
implementations allow to do
this reload per IED e.g. when
communication with the (new)
IED is (re-) established. In any case,
the probability of errors is restricted
to the remapped IED, and this
5 Different architectures
IEC 61850 offers solutions to
Ctrl 1
Ctrl 9
Station level
minimize the influence of maintenance activities at application
Ctrl 9
Bay level
level, by introducing in parallel
to the IED related identification
Swg 8
Bay controller
PAC.SPRING.2008
SWg 9
Bay controller
+ Process bus
Swg 8
SWg 9
Central controller
+ Process bus
Process level
a function oriented identification of data according to the
concepts of IEC 61346.
51
probability is quite low, because
the remapping is performed on the
relatively high level of LN instances,
supported in most cases by the
needed LN class. It should however
be considered that the new IED
should contain at least the same
DATA per remapped LN instance as
needed by the application.
Impact on engineering and
used products
The follow ing point s are
important to minimize the efforts in
case of SA system retrofit:
Use functional naming for
system engineering and the IED
related names, so that the SCD file
provides a translation between them
in a standardized format.
Use functional naming at
application level, i.e. within
application functions. Let the (MMS
based) communication drivers
translate the IED names into
functional names by means of SCD
file(s). In case of (station level) clients
which do not support this, use a tool
to create the new configuration from
the SCD file, by using the functional
name as common key between old
and new configuration.
The safety of this approach can
be supported by a system tool which
supports the IED replacement at the
functional structure on LN level,
with a check of the same respective
correct LN classes.
As we have seen, the replacement
of GOOSE servers without having
to reconfigure all GOOSE receivers
needs some optional features from
the IED respective its tool:
Support free LD naming
Support free data set naming, at
least for GOOSE and SMV data sets
Support free (guided) setting of
GOOSE confRev
To make this procedure safer,
the tool should support remapping
the new IED to the functional
names and, after this remapping,
automatically (re-)create the GOOSE
/ SMV data sets with identical layout
and name, set the LD name property
identical and take over all ‘old’
addresses.
Unfortunately, all these features
do not help for the GOOSE / SMV
case, if a changed architecture leads
to another logical device structure,
so that the requirement on
uniqueness of the LD name forbids
the proposed LD renaming, or if
due to a new physical structure the
GOOSE messages have to be split
onto different IEDs.
Some impact on system
modelling principles
A relatively safe tool-supported
binding of the LN instances of the
new IED to the functional names
by using the old IED’s binding as
template is only assured, if GGIO
and GAPC LN classes are avoided
as far as possible. This is also in the
sense of IEC 61850, which demands
using a fitting LN class wherever
one is defined. Here also some
improvements of manufacturer
IED tools might help, which
allow replacing a GGIO by a more
appropriate LN class at IED (pre-)
engineering time.
However, if the old structuring
into logical devices does not fit
to the new structuring, this does
not help. Therefore, already at the
initial system design, the logical
device structure in relation to the
used GOOSE and SMV messages
should be set up to support the
most distributed structure which
is intended to be used during the
switch yard life time. Further,
GOOSE and SMV data sets should
not reference data outside the LD in
which they are defined – else these
may later reside on different IEDs,
and therefore force a redefinition
of the data sets with appropriate
re-engineering of the receivers.
The general concept of a maximal
distributed system, even if it is
implemented centrally, also helps
in having a common behaviour of
distributed and central systems
concerning functionally connected
logical nodes, because it makes the
functional behaviour independent
from the fact if internal functional
connections between the LN
implementation are used or external
Designing systems
for the maximal
ever intended
physical distribution,
eases future
retrofit
explicit communication connections.
This has also been considered at the
more detailed definitions of IEC
61850 Edition 2 for the influence
of the test and block quality of
incoming signals, and should also be
used when implementing test and
block modes on internally connected
logical nodes.
If these additional system
structuring rules are considered,
then the consequent usage of
functional naming for application
related functions in parallel to the
usage of product related naming for
automation system maintenance, as
foreseen in IEC61850-6, supports
easy retrofit and system extension
with minimum engineering,
modification and (re-)testing effort
even if the underlying physical
architecture is changed or IEDs
of a different type or a different
manufacturer are used.
6 Communication model
GOOSE or Report messages
defined by data sets and control blocks (CB)
IED
Communi-
s
ger
trig
CB
Data
Set
Logical Device
LN
cation model
with data sets
and control
Logical Device
LN
LN
DO
DO
DO
PAC.SPRING.2008
blocks