© DIGITAL VISION

I
IEC 61850 IS BECOMING A POPULAR COMMUNICATION
standard for the Substation Automation business. Several hundreds of
projects at different stages of realization have been reported during
the last summer CIGRE session leading to a rapid maturation of the
associated technologies. Experiences reported in CIGRE papers also
reveal some improvements that still need to be made. The aim of this
paper is to discuss the benefits as well as the necessary changes
linked to this technology.
More specifically, this paper addresses the evolutions to be done dur-
ing system engineering (design, configuration and tests) in order to prop-
erly use the capabilities of the IEC 61850 toolbox. As per any tool there
is a need to know how to properly use it and to fully understand its limits.

may/june 2007 1540-7977/07/$25.00©2007 IEEE IEEE power & energy magazine 45

 Benefits of IEC 61850
Base Benefits
IEC 61850 capabilities clearly exceed what former IEC 60870-
5-103, DNP3, and most proprietary protocols had to offer:
✔ speed of exchanges: 100 Mb/s instead of a few 10 kb/s,
enabling more data to be exchanged for a better opera-
tion or maintenance of the system
✔ peer-to-peer links, replacing conventional wires with
no extra hardware and also opening the design of inno-
vative automation schemes
✔ client-server relations offering flexible and easy to
upgrade solutions compared to master slave communi-
cations; for instance, having a dedicated client for a
customer-specific function
✔ XML configuration files enabling formal exchanges
between engineering tools thus avoiding duplicate data
entry, optimizing the data consistency and reducing the
engineering costs
✔ communication conformance tests that help in reducing
the variety of interpretations found in many legacy pro-
tocols and leading to long integration tests and tuning.
The Big Picture
Looking at the big picture is even more exciting, here are
some examples:
✔ The paper by Norberg et al. (see the “For Further
Reading” section) suggests the replacement of tradi-
tional intelligent electronic devices (IEDs) by basic
field sensors and actuators, with all protections and
control functions running on an industrial PC. The
expectations are savings on the secondary equipment
and process wiring as well as increased flexibility.
✔ Simplification of the primary equipment could be
achieved by re-engineering the synchro-check func-
tion. The synchro-check compares the busbar and
line voltage phases; thus, the busbar voltages are tra-
ditionally distributed to the various bays. Capability
Benefits
GOOSE New Applications
Standard Clients (Local, Network)
Network Data Integration
Traditional
Technology
Learning
Curve
Copy Quick Deep
Hits Changes
figure 1. New technology adoption benefit versus time.
46 IEEE power & energy magazine
to centralize the instantaneous digital voltage values
could eliminate both primary busbar voltage instru-
ment transformers and their physical distribution
within the substation.
✔ Application standardization is another direction, which
would further improve the total cost of ownership. The
December 2003 article by Hossenlopp (see “For Fur-
ther Reading”) shows how to use the IEC 61850
vocabulary as a basis for standardizing bay schemes
standardization. ONS in Brazil has standardized the
use of a graphical user interface (GUI) client.
✔ Tight coordination with the control center level could
simplify the substation automation system configura-
tion by receiving automatically generated XML files
containing the substation topology and the informa-
tion addresses.
✔ Innovative grid-wide applications could be facilitated
thanks to the naming conventions. This includes asset
management, protection setting coordination, etc.
Need to Define a Roadmap
Benefits will be achieved progressively for several reasons:
✔ When using a new technology, the first step is usually
to copy what was done before. The use of GOOSE (for
distributed automation) and standard clients are the
next step. Major changes require rethinking the appli-
cations thus taking more time. The IEC 61850 is just a
tool for seamless data addressing and communication.
It only facilitates the development of generic applica-
tions and interface specifications based on the data
semantic. This is illustrated in Figure 1.
✔ The maturity of the standard. There is a revision 2 of
the IEC 61850 in preparation that will fix some issues.
Work is also in progress to facilitate the exchange of
configuration files between control centers and substa-
tions, in liaison with the common information model
(CIM). Cyber-security and redundancy management
are other examples of solutions that must become avail-
able to implement the big picture.
✔ A change in the way to execute
projects. This is discussed in the
following sections.
System Design
Why Is It Becoming Important?
Communication is not new in a substa-
tion. A major difference between the for-
mer (de facto) standard (IEC
60890-5-103, DNP3, MODBUS, etc.)
protocols and IEC 61850 is its expected
Investment functional use. The former technology
Phase was a master-slave protocol that was
mostly retrieving information for super-
vision purposes. It was sending controls
may/june 2007
as well but typically triggered by an operator. Limitations were devices on the serial links was not exceeding a certain limit and
the speed to the communication link (rarely above 64 kb/s), the eventually developing a redundant master were other aspects to
necessary centric communication (one master communicating consider. IEC 61850 is removing most of these constraints. All
with each slave), and the availability of the master (failure of the devices are on Ethernet, the network bandwidth limitation is
master resulted in the election of a new one and took several negligible in most applications, and the central master is
seconds). A direct consequence was to restrict the performance replaced by clients that can run in parallel.
of the distributed functions that could be accomplished. The new important description is the logical architecture,
IEC 61850 introduces peer-to-peer links in order to permit where all the data flows are identified. The 2006 paper by
fast distributed automation but leaves open several aspects. Hossenlopp (see “For Further Reading”) provides a compre-
✔ Enabling distributed functions is a major objective, hensive description of an IEC 61850 project made for Algeria
however, functions are not defined in IEC 61850, thus and shows the differences between the physical architecture
a document must be created on a project basis. This (Figure 2, where the red ellipse is the Ethernet network inter-
shall describe the expected behavior of each IED par- connecting PC, gateway, and bay computers) and the logical
ticipating to the distributed functions and allocate the one (Figure 3, where number refers to types of data flows).
performance between the IEDs (e.g., response time). The next section explains the reasons for the apparent com-
The document shall also define how to test the function plexity of the logical architecture in a more general frame.
in order to prepare the interoperability tests.
✔ It shall then be checked if each device is capable of Logical Architecture Definition
implementing the function. For instance, it shall be The logical architecture definition is an essential part of the
verified whether the device programming logic can system design, and this section discusses some of the tasks to
handle the quality information associated to any opera- be performed at this stage.
tional data, if it has enough virtual inputs/outputs to
process all data exchanged with the network, etc.
✔ The next step is to insure that the performance will be
met. Performance is not only a question of network
(100 Mb/s Ethernet and associated software stack) but
and end-to-end performance; i.e., what the user can
observe (see Figure 5 discussed later in this article).
The continuous IED hardware integration increase (for
cost reduction) and blooming ideas for distributed
functions (for improved substation operation) are likely
to strengthen the assessment of system performance.
The Metcalf law states that the benefit of a communication
network increases with the square of its users. Opening the
communication is likely to amplify the cross-devices commu-
nications, thus reinforcing the need for a robust design. figure 2. Example of a physical architecture.
The system design is thus becom-
ing an important milestone in a substa-
tion automation project. A GOOSE is GUI GUI
only one of the data flows that shall be Client Client
considered in this exercise. Other data Gateway T104/T101
5 Main
flows (client-server and non-IEC
61850) and additional constraints shall GUI Server Main GUI Server Backup
be integrated as well, and this is devel- IEC 61850 Client 6 IEC 61850 Client 2
oped in the next section. Gateway T104/T101 Backup
1 IEC 61850 Client
Engineering
From Physical Station Bay Bay Bay
to Logical Architecture 7 Computer Computer Computer
A traditional high-level description of a
system based on legacy protocols was Legacy 3
its physical architecture. The main chal- IED 4
lenge was to develop the right protocol Legacy
drivers, possibly with specific hardware, IED
or add a gateway to make the system
work. Insuring that the number of figure 3. Underlying logical architecture of Figure 2 (simplified).

may/june 2007 IEEE power & energy magazine 47

 Communication is not new in a substation.
A major difference between the former standard (or de facto
standard) protocols and IEC 61850 is its expected functional use.
Data Flow Identification
The logical architecture shall first consider the multiple flows
that will circulate in the communication network based on the
distributed functions specification. The multiplicity looks
complex but helps in the modularity of the system for the
reuse of proven schemes, in the solution scalability, and in the
independent evolution of the various clients’ software. Typi-
cal categories are discussed below.
✔ Client-server operational data flow linking servers
(IEDs) to the local GUI and substation gateway. The
capability to segregate the flow directed toward the local
GUI from the flow going to the substation gateway
avoids a common mode of failure. It also creates two
clients per server and thus additional constraints for the
servers. This type of flow is primarily using the IEC
61850 protocol (flows 1 and 2 of Figure 3), but OLE
(object linking and embedding) for Process Control
(OPC) is another popular protocol between client and
server of the GUI (flows 5 and 6 of Figure 3).
✔ GOOSE data flows (flow 3 of Figure 3). Selective mul-
ticast shall be preferred to broadcast in order to
improve performance and is dependent on the function
distribution. Optimization might be done between the
number of GOOSE messages emitted by a device and
the performance of the subscribers.
✔ Maintenance and system management data flows.
Examples client tasks include downloading database
files, starting/stopping devices, GOOSE, or reports,
retrieving disturbance record files, accessing the
device’s Web services, changing the setting, etc. These
flows are all using the Ethernet network, are generally
not all active at the same time, and are mixing IEC
61850 protocols, Web services, simple network man-
agement protocol (SNMP), and private messages.
Capability Checks
Once these ideal flows are identified, the device capabilities shall
be checked: number of clients supported, number of GOOSE
messages possibly subscribed, configurability of the GOOSE
message, flexibility of their configuration language to program
the functions, reaction time to process the GOOSE in avalanche
conditions, overall load in reaction to the various data flows, etc.
Eventually, some compromise shall be made in terms of func-
tions, performance, or device choice. Today, such data are rarely
available from the device documentation, thus, preliminary tests
must be made to guarantee the overall system performance.
48 IEEE power & energy magazine
The choice of the Ethernet infrastructure is essential as
well for functions that have both dependability and real-time
constraints; e.g., load shedding, where it must be a redundant
system offering a low reconfiguration time. The reconfigura-
tion time, i.e., the ability to retransmit data after a failure of
one Ethernet link shall typically be less than 1 ms in case of
any communication network failure.
Robustness
An architecture is the fundamental organization of a system
embodied in its components, their relationships to each other, and
to the environment, and the principles guiding its design and evo-
lution (ANSI IEEE 1471-2000). The capability to integrate future
changes (i.e., substation evolution, new distributed functions,
device software version evolution, etc.) shall thus be assessed.
The use of distributed functions will typically increase the
sensitivity of the system to these changes. It might affect its
availability due to devices reboot and the time to test the evolu-
tion. One reason for devices reboot is that the devices need a
new database (if, e.g., a new GOOSE subscription is required)
and have to restart their application in this case. The time to
test the evolution is typically the case where equations taking
into account the topology are affected; e.g., for interlocking
purpose. In such a case the number of tests may rise exponen-
tially with the number of variables. Testing should be simpli-
fied if the architecture development includes testing at the
inception of the application. The paper by Brand et al. (see For
Further Reading) gives some examples of this sensitivity in
terms of database reconfiguration constraints versus the type of
algorithm. General good practices include the following tasks.
✔ The decoupling of the IED critical functions (protec-
tions using local information) from the distributed
functions in order not to be affected (i.e., continue to
be executed) by a system database reconfiguration.
✔ The capability for the IED to store two configuration
databases, using one database when loading a new one.
This reduces the downtime and permits a return to the
original database if ever the second one does not lead
to the expected result.
✔ The identification of a hierarchy of building blocks
(bay, voltage level, etc) to insure independence
between different parts of the system.
✔ The use of topological-based algorithms where proof
of the change is limited to the verification that the new
topology is correctly computed (linear increase of the
tests instead of exponential increase).
may/june 2007
 ✔ The use of system management tools able to automat-
ically update several IEDs and check their version
consistency.
✔ The reuse of proven schemes. This looks obvious,
and frustrating for the engineer’s creativity, but works
and justifies some of the data flow independence
explained previously.
Other Design Tasks
When mapping the distributed functions onto the IEC 61850
objects and services, some gaps might be revealed. The paper
by Carrapatoso et al. (see “For Further Reading”) has added
some logical nodes and attributes to existing logical nodes
and common data classes. The paper by Laderach et al. (see
“For Further Reading”) mentions the limitation of the select-
before-execute service compared to the customer habits and
the need to align the design to customer wishes.
Decisions shall be made to use generic inputs/outputs logi-
cal node (GGIO) to complement existing logical nodes or to
create new ones. The use of GGIO is easy and sufficient
unless an engineering tool is capable of using the semantic of
the new or modified logical nodes. While this may certainly
come in the future, this is hardly a priority today.
The select before execute service issue is, on the contrary,
not negotiable since this has an impact on the substation
operation. In order to address both issues (data modeling and
service) it is essential to have devices flexible enough to
accommodate changes in the logical nodes (naming and
model extensions) or services.
i.e., automation, graphical, or tests sets. This represents about
80% of the project configuration effort. Since these concepts
are absent from the substation configuration language (SCL)
this is derived from the specification and a manual link
between the communication data and these domains is need-
ed. It is strongly suggested to progressively incorporate into
the SCL these additional aspects and to have a single engi-
neering tool to facilitate the user.
SCL Files
SCL is defined in Part 6 of the standard. With regard to the
pure communication description, the SCL schemes still require
adjustments. Besides the pure bugs or interpretation issues,
there is, for instance, a lack of the overall logical flow descrip-
tion. This is valid both for GOOSE and client-server relations.
While this is offering freedom for the engineer, this is not suffi-
cient to formally assess the compatibility of IED capabilities
(in terms of number of clients connected to servers, for exam-
ple) or to automatically document the logical architecture.
The SSL is one optional file that can be used as an input
for the engineering. This file contains basically two parts:
the logical node list and the substation topology. As seen
above, the logical node list might be an input for the logical
architecture definition. The substation topology can be creat-
ed manually but is a nontrivial task for real substations (i.e.,
lots of data) and is very difficult to test as such. The true
benefit of this file is expected to come once the control cen-
ter will be able to directly create it by an extraction from its
CIM-oriented database.

System Configuration
This section relates some of the find- Specification System Specification Tool
ing made with the existing projects
and extrapolates some requirements.
SSL Subset

Configuration Process
The configuration process of the sys- IED IED IED
tem is a superset of the one presented Tool Tool Tool
Communication
on IEC 61850-6 (see Figure 4): Configuration
When there is possibly more than a ICD ICD ICD
single IED configuration description
(ICD) for an IED (which happens Described
Automation and System Configuration Tool by
where logical nodes can be created
Graphical IEC61850-6
using the IED configuration capabili- Configuration
ties—a trivial example is an IED Setting SCD
playing a proxy role), there is a need
for a “preconfiguration” of this IED IED IED IED
to create the ICD template used by Tool Tool Tool
the system configuration. This can
typically be done by importing a sub-
IED IED IED
set of the substation specification
description (SSL) file containing the
Test Scenario
logical nodes needed for the project. System Testing Tool
Another issue is when there is a need
to configure noncommunication data; figure 4. Full engineering process versus IEC 61850-6 description.

may/june 2007 IEEE power & energy magazine 49


Input Ethernet
Appli- Com. Com.
cation Stack Stack
Device A Communication
Inter-Operability
figure 5. Interoperability goes far beyond the pure communication between devices.
Interoperability
Why Shall It Be Revisited?
Interoperability tests are not trivial for at least three reasons:
✔ they are no longer limited to the set of few addresses to
check that the master and slave communicate correctly,
as with previous protocols
✔ they go beyond the pure communication and embrace
the full application [i.e., they include the process
interface (see Figure 5)], and since the functions are
not described by IEC 61850, such tests cannot be
described in the standard
✔ they shall be played in the context of the project; i.e.,
with a logical architecture that brings specific stress
to the devices and might alter the overall function
performance.
Practical experiences have in addition identified the fol-
lowing issues:
✔ “vague definitions” (see Amantegui et al.); i.e., prone
to interpretation
✔ missing specifications; i.e., for redundancy
management
✔ implementation profiles: differences between
suppliers.
This applies to the services, modeling, and configuration and
is expected to be progressively fixed through the tissue process
(the process to resolve errors or ambiguities in the IEC 61850
standard at UCA International) and revision of the standard.
Process Aspects
Testing interoperability of legacy protocols was a pretty
obvious process: bring the different devices on the same
table, configure the addresses, and check the master-slave
relation. Interoperability testing in IEC 61850 must be dif-
ferent in order to be efficient, and a four-step preparation
phase is recommended.
✔ System specification and design documentation.
Detailed description of the distributed functions is fun-
damental to be able to define the associated tests.
✔ Test plan and test scenario definition. The test plan
shall list the test objectives, identify the testing tools,
define the role of the actors, etc.
50 IEEE power & energy magazine
✔ Susbtation configuration descrip-
tion (SCD) configuration files
Output creation.
Appli-
cation ✔ Capability of each device to sup-
port the right profile, to import
Device B the SCD file, and to manage the
distributed function shall be
checked.
Conclusions
IEC 61850 offers several opportunities
to improve grid operation and control
as well as the total cost of ownership. This technology has now
passed the initial stage of implementation, with a significant
number of projects being done worldwide.
The current projects are first a copy of what was done with
the previous technology. In order to catch the full benefits of
the standard there is a need to change the traditional project
engineering and to define a road map for the various changes.
Like for most information technology projects, it is likely
that the system architect role will progressively emerge, in
addition to the system integrator: designing a robust system
and identifying the necessary interoperability tests that shall
be performed prior to the final project implementation are
some examples of this new role.
For Further Reading
A. Carrapatoso et al., “Integra project—Applying IEC 61850
technology,” in Proc. CIGRE 2006 [CD-ROM].
J. Amantegui, A. Cerezo, J. Torres, A. Rivas, and F.
Cobelo, “The university city SAS, first project within Iber-
drola group using IEC 61850 for a complete substation,” in
Proc. CIGRE 2006 [CD-ROM].
S. Laderach, W. Baas, K.P. Brandt, and P. Reinhardt “Expe-
rience with IEC 61850 in the refurbishment of an important
380 kV substation,” in Proc. CIGRE 2006 [CD-ROM].
P. Norberg, A. Fogelberg, and A. Johnsson, “Field experi-
ences from using PC software for protection and control of
AC substations,” in Proc. CIGRE 2006 [CD-ROM].
L. Hossenlopp and E. Guimond, “IEC 61850: Impact on
substation automation products and architectures,” in Proc.
CIGRE 2006 [CD-ROM].
L. Hossenlopp, “Substation automation: Beyond commu-
nication standardization,” Electra, vol. 211, Dec. 2003.
K.P. Brandt, P. Rietmann, T. Maeda, and W. Wimme,
“Requirements of interoperable distributed functions and
architectures in IEC 61850 based SA systems,” in Proc.
CIGRE 2006 [CD-ROM].
Biography
Luc Hossenlopp joined Alstom (which became Areva) in 1987.
He is currently the product line manager for substation automa-
tion there. He is member of the IEC and CIGRE committees and
was awarded CIGRE distinguished member status in 2004. p&e
may/june 2007