STATE OF THE APPLICATION ART OF THE IEC 61850 STANDARD

Igor Auzokoa Garate

INGETEAM T&D

SUMMARY
This article provides a view of the IEC 61850 standard ("Communication networks and systems in
Substations"), insisting on the challenges when implementing solutions based on this architecture in an
electrical bay.
The IEC 61850 standard is a set of rules ranging from electrical or quality requirements to platforms or
communication profiles, getting through the system and project management or the data and service
model definitions.
The agreement reached by the standard, is not detailed enough to avoid interpretation differences. For
example, the standard allows the model extension, by adding data to the existing logical nodes or even by
creating new logical nodes.
The UCA International Users Group was created to solve all the standard interpretation problems, correct
its possible errors, and, in general, to be in charge of the standard maintenance. Within the technical
Committee of this organization, a TISSUEs (Technical Issues) process has been created. A TISSUE may
be an error, an ambiguity or a proposal that is analyzed within the UCAIug, and the resolution of which
will be incorporated to the following revision of the standard.
Other challenges that must be faced up by both manufacturers and clients during the implementation of
the IEC 61850 systems would be the capacities of the IEDs (Intelligent Electronic Devices) to handle the
necessary information, the adaptation of the engineering processes to the new standard, the availability of
configuration tools, documentation in XML, lack of definition of the IEC 61850 client behavior, as well
as its standardization, etc. these are the aspects to be treated in this article.

1. INTRODUCTION
The IEC 61850standard starts from the concepts derived from the new programming and communication
techniques and its influence in the electrical field will be higher than the one of the integration of
communication protocols. The real benefices of the IEC 61850 get more important when different devices
are combines in one single system. For example, in a system that implements the following functions:
• Interchanging values sampled between CTs and VTs
• Quick I/O data interchange for protection and control
• Control and trip signal
• Engineering and configuration
• Monitorization and supervision
• Communication with control centres
The implementation of these functionalities is simplified with the use of IEC 61850 data model (through
objects and standard services). This allows the client to concentrate in the desired functionality and not in
the details of information interchange between devices, which is already detailed enough in the standard.
It is reflected in the following graphic where the data modelings as well as the possible information
interchanges within the IEC 61850 standard are represented:
At present, INGETEAM T&D, with its solution, implements all the functions here described with the
only exception of the process bus or SV (1), the implementation of which is carried out in the following
phase of unit design.

Practical example of the IEC 61850 standard application in a server device

2. REAL IMPLEMENTATION OF A IEC 61850 SYSTEM

When the complete solution is supplied by a single manufacturer, the interpretation and interoperability
problems are solved univocally and it may happen that they are not solved when applying the standard
strictly. The real interpretation and interoperability problems, as well as the advantages of this protocol,
rise when integrating IEC61850 solutions by different manufacturers in one substation. This article will
focus on this aspect.
There are other challenges that each manufacturer must face up from their perspective, because of the
complexity implied by the standard, such as the IEDs capacities, software tools to make the engineering
and supervision processes easier, etc... They are challenges that do not affect the standard interpretation
directly, but that can make the integration and interoperability of the units easier in a substation oft his
kind.
2.1. Standard interpretation differences
As it has been said in the summary, within the UCA International User Group, all the problems related to
the standard interpretation are managed by means of a TISSUEs procedure. The management procedure
of these TISSUEs, as well as the resolution times are detailed in the following scheme:
A considerable period of time may elapsed until a new revision of the standard is made (no revision has
been released since 2004), so the only reference about the standard interpretation is given by the technical
committee of the UCA users group through the publications of the TISSUEs in the
http://tissues.iec61850.com/parts.mspx page. The decided TISSUEs are also published in the UCA web.
 Process of TISSUEs IEC 61850 in the UCA International Users

Some manufacturers may have implemented some of the ‘green’ TISSUEs and their units and some other
not, so the interoperatibility between the units may be affected. It could be recommended to analyze the
problems associated to the fact of having implementations of the standard previous to the resolution of
many of these TISSUEs.
When integrating servers and clients of different manufacturers in a IEC61850 solution, the TISSUEs
implemented by each manufacturer must be known. The same standard, in its IEC61850-10 section,
indicates that every unit to be certified under this standard should provide the authorized laboratory with
several document, among which the TICS (Technical Issues Implementation Conformance Statement) is,
that is, which TISSUEs will implement the unit. Even in the standardization tests carried out in third
laboratories (for example KEMA), all those TISSUEs implemented by each manufacturer must be
detailed before carrying out the standardization tests.
2.2. Client’s behaviour
At present, there is a lack of definition for the 'standard' operation of a IEC 61850 client. The connection,
enabling and report recalling or GOOSEs subscription procedures are not established. Each IEC 61850
client carries out the initialization of the server units according to his own criteria, which may derive in
the incompatibility between client and IEC 61850 server, and, so in a lack of interoperability. The server
may or may not support, some IEC 61850 behaviours (data sets and control blocks recalling, for
example), generating negative responses to certain services that may make a client to abort the initilizatio
process of such server. Examples: writing attempt of the control block ReportID, write some OptFlds or
EntryID fields in the URCB, write the TrgOpts data which is not supported by the server. Even the client
himself may not support the server’s behaviours, such as excessive sending times for a
CommandTermination message since there is no setting in IEC 61850 that allows configuring this time.
The solution to these incompatibilities usually consists of the previous carrying out of some shared tests.
In fact, some of these incompatibilities could be solved before the tests if information about the client’s
behaviour or server’s ‘extra’ capacities were available. However, there is no specified document
according to the standard to define the client’s behaviour, although there is a document called PIXIT,
“Protocol Implementation eXtra Information for Testing”, that could be used by a client to know
beforehand the possible incompatibilities with the server
On the other hand, it could be important to establish a procedure for the communication failure detection,
at application level, apart from the keepalive mechanism at TCP-IP level, as it is indicated by the standard
in the section 8.1. A possible procedure could be the periodical request of a leader datum (which every
server must have), in such a way that, when the server does not respond to the client, the connection could
be closed; if the server does not receive the client’s request, it could decide to close such connection. The
number of IEDs connections is limited and it would be interesting to have a mechanism, at application
level, to control the open connections and to be able to release those connections that are not used any
more.
2.3. IEDs capacities
Some companies offer communication libraries, simulation software and test or tools to help the
developers to incorporate this protocol in their products. INGETEAM T&D has decided to use the SISCO
library, validation tools and KEMA analysis (single SIM and single Analyzer) as well as different test
clients for the development of the units with con IEC 61850.
The units that integrate the IEC 61850 protocol are units designed to be used with new programming and
communication techniques. Apart from integrating the characteristics of the IEC 61850 protocol, they
also offer other facilities to be used in the new communication architectures.
The IED capacities must contemplate:
• Configuration of the IED through the SCL (Substation Configuration Language) file, loading it
directly in the IED, and not using it only as file of interchange between.
• Flexibility in the mapping of the data of the IED in nodes and IEC 61850 devices.
• Simplicity to incorporate data which are not obliged by the standard. Simplicity for the extension
of nodes and private data.
• ‘Extra’ capacity, not contemplated by the standard, that will be detailed below:
These capacities, not contemplated by the standard, will be decisive when carrying out of the installation
of a substation with the new communication techniques, described by IEC 61850.
The tools used during the implementation and development of this protocol has been the MMS Ethereal
for the analysis of the MMS protocol (between client/server) and GOOSEsmessage in the network, as
well as different MMS clients to communicate with the IEC 61850 servers in the IEDs.
2.3.1. IEC 61850 communication architectures
The basic IEC 61850 communication architecture which can be found in a substation is reflected in the
following figure:
In certain substations, a higher reliability of the IEC 61850 communication network is required and
different types of redundant solutions are set out, such as the one of independent double ring or
interconnecting double ring. In this context, different implementations of the redundancy raise in the
IEDs, because the standard has not clearly specified this type of redundant solutions. The IEDs could only
have one single IPaddress or two different IP addresses. The solution would allow architectures as the one
of the interconnected rings.
So as to achieve a higher reliability, not only the communication system could be redundant but also the
units could, being the most common redundancy the one of the RTU or the one of the Automatism IED.
One of the limitations that the different IEDs may have is that they can have communication or complete
unit redundancy.
2.3.2. GOOSE
So as to save physical wiring between units in a IEC 61850 system (which means a saving in time,
material and space), there are some procedures or IEC 61850 services of quick data interchange through
Ethernet. They are the so-called GOOSE (Generic Object Oriented Substation Event).
The standard establishes some requirements de minimum response time for these services, depending on
the signaling type to be sent and substation type. It also establishes GOOSE times from the 3 ms (1/4
cycle) for trip signaling in transmission units or 10 ms for the same signaling in distribution (section 13 of
the IEC 61850-5 standard). Tests have been carried out in demos and substations with different
manufacturers, reaching 4 ms times for trip signaling and around 10 ms for user’s automation signaling.
These tests have been carried out under ‘normal’ conditions, without avalanches, without failures in the
communication network of the substation etc.
Both the client and the manufacturer must know the new communication network in the substation. The
introduction of the switches, VLANs and units able to prioritize packets (IEE802.1q, IEE802.1p) help to
rely on these GOOSE interchange procedures. Anyway, the security and the substation communication
network restoration time have to be evaluated. When one switch fails, the maximum time that may elapse
until a GOOSE message is received depends on the restoration of the network link. Some switches have
owner protocols to restore the network link quicker than the standardized protocols, such as the ‘Rapid
Spanning Tree’ (IEE802.1w). The IEDs that have packet priorization protocols and that may fulfill the
time requirements of the system to be implemented (IEE802.1p, IEE802.1q). It is another of the
limitations of the IEDs to be taken into account to avoid wiring and to save time in engineering.
2.3.3. Permitted connections and reports
The amount of simultaneous connections allowed by an IED has to be taken into account, both in the
client and servers’s side. It is important to know the number of connections that may be accepted by a
server, because, depending on the type of substation, it may fulfill or not the specified requirements (it
may be normal the access of 2 automatism IEDs, 2 HMI and 2 accesses for
configuration/parameterization, in the case of redundant systems). It is also necessary to know the number
of connections that may be carried out by an automatism IED so as to know how many control and
protection IEDs it will be able to integrate for the substation automatism logics.
Within the capacities of one IED server, it is interesting to know the amount control blocks (buffered or
unbuffered) that it is able to manage, as well as the configuration capacity of these blocks (possibility of
renaming them, by changing the ReportID). This information, contrasted with the behaviour of a client,
will indicate the possibility of integrating units by different manufacturers.
2.3.4. Synchronization
It is important to set the time accuracy necessary in one substation so as to define the type of
synchronization to use. For the event dating a millisecond accuracy may be enough, but not for
syncrophasors, crossing rate marking etc. The IEC 61850 standard (in section 8.1 of mapping to MMS),
recommends the SNTP protocol (Simple Network Time Synchronization) as synchronization service.
This protocol may reach millisecond accuracy.
Other types of synchronization protocols, such as the IRIG-B, may reach microsecond accuracy, but they
need a specific wiring because they do not use the Ethernet communication system, such as SNTP.
At present, we are working in a new IEEE 1588 (2002) synchronization protocol through Ethernet, with
which a microsecond accuracy is pretended. The IEDs must have synchronization capacity both via SNTP
and IRIG-B, and when the IEEE 1588standard for synchronization in Ethernet networks is mature the
IEDs should be recommended to support them.
2.3.5. IED parameterization, settings
Nowadays there are very few units, or no units, that allow configuring the settings or parameters of the
IEDs through the IEC 61850 services, using the setting groups’ service. For the maintenance and
commissioning it is very useful the possibility of parameterization one IED without the need of an own
tool (different for each manufacturer). For that there are several possibilities:
• Use the setting services offered by IEC 61850 and use a MMS browser.
• Sending of the initialized settings in the CID configuration file (Configured IED Description),
using a FTP protocol, the IEC 61850 file service or owner protocol.
• Web server in the IED, which offer access to its settings.
The solution offered by the standard itself is to get access to all the settings of the unit by using the IEC
61850 services (setting group). The other two possibilities are not contemplated by the standard, but they
are very interesting for the final client. Owner tools would not be needed and in the case of web server,
the presentation and the ease to change the settings are offered by the server implemented in the IED.
If choosing the parameterization option using the CID file or setting groups, we have the advantage of
carrying out a management of setting data base in the IEC 61850 client’s side. Each IED will have one or
several of these configuration possibilities, depending on the available hardware and software capacity.
There may be challenges when implementing the possibilities of configuration previously described:
• IEDS memory capacity. Handling of very extense configuration files if setting initialization,
descriptions etc. are included.
 • Processing capacity. The fact of updating the CID file, having a web server, FTP server etc. may
slow down the response time of the unit.
The capacities the IED has for its parameterization are important when choosing them for an IEC 61850
solution. There is a clear increasing in the features asked to a protection and control IED, and each
manufacturer will bet for a solution adapted to a certain market and price.
2.3.6. Flexibility in the IEC 61850 mapping
The standard allows defining nodes and private data for specific functions of each manufacturer and
which are not defined in the standard, according to Annex A of the standard 7.4 section. Due to the meta
data of the IEC 61850 standard, any client could interpret these extended nodes and data. There is also the
possibility of using generic standard nodes, such as GGIO, before extending the model with new nodes,
although, in this case, it is difficult to recognize what wants to be represented in such node. This solution,
which will lead us to more standard models, provokes the loss of the nodes semantic, which is an
important characteristic of the IEC 61850 standard. It is important, within the capacities of one IED, to
have flexibility when mapping data, both if they want to be mapped to existing nodes and if new nodes
and data are defined. Each final client may want to instantiate the data in a certain way.
2.4. Process of engineering and configuration software tools
The lack of standardized configuration between devices by different manufacturers and the number of
private communication protocols to be implemented in a substation have made the engineering process
long and expensive.
The IEC 61850 will help to reduce the costs and the time of the engineering process through its
communication interface, which defines the autodescription of the IEDs and a substation configuration
language (SCL). The final aim would be to automatize, at the maximum, the engineering process, basing
on the autodescription and in the SCL of the IEC 61850.
2.4.1. Description of the engineering process according to the standard

The engineering process according to section 6 of the IEC 61850 standard.

This scheme of the engineering process, defined by the standard, helps each manufacturer to identify the
necessary software tools to make such process easier and quicker. INGETEAM T&D has chosen the
following option, contemplating all the exceptions to the standard:
 Possible the engineering process of a IEC 61850 practical solution

Which simplified, that is removing not-contemplated problems, would result that way:

2.4.2. Automatization of the engineering processes

When systematizing the console or HMI (Human Machine Interface) configurations, there are
some aspects of the system that are not contemplated in the SCL language, such as the alarm
and event configuration. The type of each data (alarm, event...) should be indicated (some
clients do it with private tables in the CID, some others with tables in Microsoft Excel. When
showing these events or alarms in the HMI, it is interesting to use the ‘d’ description of the IEC
61850 data in the CID. The software tool generated by the CID is in charge of filling these
descriptions and the type of each datum.
The access to the unit data (setting/fault/oscillography) is recommended to be carried out
through the commercial tools, such as web explorers, ftp clients, instead of owner tools. That
way, the configuration and the collecting of data of any unit would only need these tools and not
any other specified by the manufacturer. These possibilities are additional to the use of IEC
61850 file services.
Some details, not contemplated in the standard, which must be supplied by the manufacturers
when facing a development of a IEC 61850 substation together with other manufacturers, are
the maximum number of allowed simultaneous connections, number of maximum GOOSE
messages to be transmitted and/or received, number of maximum data sets and of data in each
data set, etc. All these extra data maybe found in the PIXIT document defined by the standard,
in its section 10, and that the manufacturer should supply not only for the unit testing but also
for the integration of this unit in the substation. These data are necessary for the integration of
clients and servers by different manufacturers and they are also necessary to know the unit
capacities that may not appear in the ICD (IED Capability Description) file.
2.4.3. Exceptions to the standard
• The SSD (System Specification Description) file may be used to describe the single-
wired of the position and the functional blocks. Generally, the final client usually
defines the graphic aspect and the dimensions of the elements of a substation, to be
represented in a PC screen or in the graphic display of the IED (if available). The
description language used in this type of SSD file, does not describe graphically each
element of the position (breaker, sectionalizer, recloser...). If both the aspect and the
dimensions of the substation elements want to be defined in the CID, a graphic
description language in XML would have to be used. This language could be based on
the SVG (Scalable Vector Graphics) and it could be a private part of the CID file. The
configuration tool must allow painting the unifilar and move it to the graphic language
chosen in the XML. That way, the interchange and management of single-wired could
be possible, as well as its documentation by using the CID file.
• There is also the need of defining the logics and automations associated to the each of
the positions in a substation; state signaling, locking... the standard does not
contemplate, in any section, how to define these logics or how to include them in the
CID using the Substation Configuration description Language (SCL). So, the
description and implementation of the logics depends on each manufacturer and it
requires an additional engineering process (it is one more input to the configuration
tool).
• These logics/automations may be implemented by using standard programming
languages such as the IEC61131-3. There is an independent organization, called
PLCOpen, which is working to define a XML logic programming language, based in
the IEC61131. Including the IED logics in the CID configuration file, although it is a
private zone, would help to unify the documentation of a system of that type.
Depending on the IED capacity, it could also be possible to configure the IED logics
through this file, making the engineering easier and clearer. By asking the CID file to
the unity, through IEC 61850 or FTP file services, the logics, really implemented by the
unit, could be obtained and represented.
• Other option would be the representation of the logics or automation implemented in
the unit in IEC 61850 nodes. That way, the logic implemented in a unit could be known
from a client or MMS explorer. They would be new IEC 61850 nodes (extensions),
because they are not contemplated by the standard.
 • Control services (orders). The only order control or filter contemplated by the standard
is the one carried out through the “Origin” field; according to the unit state
(local/chart/remote) this accepts some origins or others. The standard does not specify
how to define the permissions to carry out the orders when, in some cases, more control
than the one defined by the standard is required. At present IEC 62351 standard (Data
and communication security in the utility industry) is being worked on. Section 3 is
generic for protocols on TCP-IP, section 4 refers to applications using the
“Manufacturing Message Specification” (MMS) as it is the case of IEC 61850. Section
6 of this standard (IEC 62351-6. IEC61850 Security) refers to IEC61850 messages
which are not TCP-IP and which require a quick response time (SVs, GOOSEs, SNTP).
The implementation of this standard will solve problems of access permission,
autentification etc. by sing digital certifications and some other security systems.
• Other utilities not contemplated by the standard and that the manufacturer implements
in private zones of its units.

2.4.4. Software necessary for the substation configuration

The configuration tools must make the engineering process of an IEC 61850 substation easier
and quicker as well as generate (automatically) the documentation necessary for the exportation
of engineering from one SE to another.
The manually carried out procedures, such as the XML file modification, are being substituted
by the use of software tools aimed at the IEC 61850substation engineering. The aim is not only
offers a complete owner solution, but also, to integrate any unit inside the IEC 61850 system,
using these software tools. The configuration tools should be able to create/import/export
ICD/SCD (Substation Configuration description), as well as define/modify data-sets, control
blocks, subscription to GOOSEs... so as to create a CID and even a SCD file (substation
configuration), without modifying any private part of the CID files. The creation of single-
wired, documentation associated to single-wired and logics in XML, creation of private parts for
the console.... should also be supplied. At first, there may be problems with these configuration
tools, for example when integrating ICDs by different manufacturers. The tools must support
the use of no-mandatory data in the SCL or respect the private parts. In the first integrations of
IEC 61850 units, it is usual to find some integration problem of the different ICD/CID files in
the software tools. They are problems that have been being purified until generating a SCD
substation file and being integrated units by different manufacturers

3. CONCLUSIONS
The IEC 61850 has a well documented methodology for the communication between different
devices. The modeling of standard objects and abstract communication services defined by the
standard makes the interoperability between devices and the autodescription easier, and it also
improves the unit integration times in a IEC 61850 system.
The use of GOOSE messages, horizontal messages, simplifies the wiring without losing the
traditional wiring features. The field of the IEC 61850 standard goes further that the one of any
“traditional” protocol, it specifies themes such as test that the units must go though, validation
tests, communication requirements, data modeling etc.
The standard has tried to cover and model all the and data that maybe present in a substation. So
that, a configuration language, the Substation Configuration Language (SCL), has been defined,
which, when expanding private zones may be used for the documentation and reusing in other
substations, apart from using it for the information interchange between applications by
different manufacturers (for engineering for example).
There are some sections that have not been well defined by the standard and which require one
interpretation. They are tried to be solved together with the “tissues” process. There are
functionalities or services that rise when implementing a substation not contemplated by the
standard and that have to be treated even if we go out of the standard, using the new
programming and communication technologies. The standard does not specify the
communication architecture or the location of functions in a IEC 61850 solution. It is neither
specified in the interfaces with the operator.
However, we can come to the conclusion that the IEC61850 is fulfilling the expectatives but
that it needs expansions and an agreement between manufacturers and users through the
standard working groups. All these proposals carried out by manufacturers or clients, which are
necessary for the commissioning of a substation and which are not contemplated by the
standard, should be transmitted to the Technical Committee 57 (TC57) of IEC 10 (WG10) the
working group, which is responsible for the IEC61850. That way, solutions adopted in
particular working groups, so as to deal with certain themes, may become standardized, making
the interoperability easier. Units are interoperable but they cannot be interchanged, so its is
important to choose a IEC 61850 client according to the chosen solution.

4. REFERENCES
[1] IEC 61850: Communications Networks and Systems in Substations, International
Standard.
[2] UCA International Users Group (TISSUE-process_R1-1.pdf).
http://www.ucausersgroup.org
[3] B5-108 Article (Cigré 2006) – “El SAS de “Ciudad Universitaria”. First Project within
the Iberdrola group for the application of IEC 61850 to complete substation. Final experiences
and future expectatives.
[4] IEC 61850 Technical Issues. http://tissues.iec61850.com/parts.mspx