Overview of The IEC 61850 Standards

Overview of the IEC 61850 Standards
SYS403_Overview_IEC61850_r3 1
These services will be implemented by the class to collect, concentrate, and serve substation data to a
SEL-3530 Real-Time Automation Controller (RTAC) HMI client application.
Introduction to IEC 61850
In the early 1990s, the Electric Power Research Institute (EPRI) and the Institute of Electrical and
Electronics Engineers (IEEE) began to define the Utility Communication Architecture (UCA). They
initially focused on inter-control center and substation-to-control center communications and
produced the Inter-Control Center Communications Protocol (ICCP) specification. The ICCP
specification was adopted by the International Electrotechnical Commission (IEC) as IEC 60870-6
TASE.2 and became the standard protocol for the real-time exchange of data between databases.
In 1994, EPRI and IEEE began work on UCA 2.0 (simply referred to as UCA2) for field devices
with the scope being communications within the substation and to leverage the new LAN
technologies that were available. In 1997, they combined efforts with IEC Technical Committee 57
to create a common international standard. Their joint efforts led to creation of the present IEC 61850
standard.
The IEC 61850 standard, a superset of UCA2, contains most of the UCA2 specification plus
additional functionality. The IEC 61850 substation reference model is shown on this slide. The
station bus and process bus are both Ethernet based. As process bus is still being rolled out by many
vendors, this section of the course will focus on the IEC 61850 station bus.
The objective of the IEC 61850 standard is to provide a framework to ensure interoperability through
the standardization of the following:
• Information models
• Information exchange methods
 GOOSE (peer to peer)
 Read/write
 Reports
 Logs
• Protocol maps
• Substation Configuration Language (SCL)
Through this process of standardization the data that exist within IEC 61850-compliant power system
devices or entities (such as transmission lines, breakers, transformers) have been modeled or
normalized to a set of standards with respect to naming, organization, type, and format of the data
such that the device is said to be “self describing” with respect to its data. In addition, the IEC 61850
device communicates the data strictly according to the communication protocol map described within
the standard. After a brief overview of the IEC 61850 suite of standards, we will examine how the
data are organized and the communications services that are available.
IEC 61850 Standard provides solutions:
• Dictionary of power and communications terms: each vendor uses the same dialect
• Object-oriented database structures
• Combination of protocols for different needs
 Client/server replaces traditional master/slave
 Publish/subscribe methods are added
• Substations are networked using Ethernet
 Familiar tools and processes
 Widely used hardware is becoming more affordable
IEC 61850 Main Sections
The present suite of IEC 61850 standard is composed of the ten main sections shown on this and the
following slide. The primary parts are as follows:
• Parts 3, 4, and 5 identify functional communications, which are then used to aid in the
identification of the services and data models, application protocols, and the underlying
transport, network, data link, and physical layers
• Part 6-1: SCL, The Substation Configuration Language, which is XML based to allow files
to be exchanged between vendors during the configuration process
• Part 7 has 4 subsections:
 Part 7-2: Abstract Communication Service Interface (ACSI) defines a set of services and
the responses to those services that enable all IEDs to behave in an identical manner
from the network behavior perspective
IEC 61850 Main Sections (continued)
 Part 7-3: Common data classes (CDCs)
 Part 7-4: Logical nodes
• Part 8-1: Specific Communication Service Mappings (SCSM) with manufacturing message
specification (MMS) and Ethernet
• Part 9-2: SCSM with Sampled Values over Ethernet
• Part 10-1: Conformance testing
Information Models: The Approach
Traditional protocols typically define how bytes are transmitted on the wire but do not specify how
data should be organized in devices in terms of the application. For power applications, the integrator
must manually configure objects and map them to power system variables, I/O modules, etc., within
the devices that comprise the application solution.
IEC 61850 takes a new approach to address this tedious, labor-intensive, and error-prone effort.
IEC 61850 information modeling is an abstract method to model the status and history of real-world
power system entities. Substation transformers, transmission lines, and breakers are examples of
power system entities that have been modeled within this standard. In addition to the specification of
how bytes are transmitted on the wire, IEC 61850 provides a detailed model for how power system
devices should organize data in a manner that is consistent across all types and brands of devices,
eliminating much of the configuration effort as the devices can describe themselves. For example, the
CT/VT inputs of an IEC 61850 relay are automatically assigned an IEC 61850 measurement unit
(MMXU) with the correct data organization.
Let’s look at some examples to better understand how IEC 61850 is typically implemented within
protective relays. The implementation of IEC 61850 varies from one relay manufacturer to the next,
but many relay implementations of IEC 61850 have the following similarities:
• Within the physical IED exists one or more logical devices or models of the power system
entity it is to control, monitor, and/or protect from a data perspective.
• Related real-world inputs, outputs, and settings of functions or equipment of the power
system entity are grouped within the logical device into what are referred to as logical nodes.
A logical node is a named grouping of data and associated services that is logically related to
some power system function. The abstraction of the data objects (referred to as logical
nodes) is found in IEC 61850 Part 7-4. Examples include protection elements as shown on
this slide.
Many of the data objects within different logical nodes are made up of common pieces (such as
status, controls, measurements, and settings). As a result, the concept of CDC (Common Data Class)
templates were developed to define the common building blocks for creating the larger data objects.
The CDC elements are defined in IEC 61850 Part 7-3. The CDC templates are used to ensure that all
mandatory and conditionally mandatory data are present within the logical node.
• IEC 61850 not only uses the idea of abstracting the definition of the data items but also the
services, that is, creating data items or objects and services that are independent of
underlying protocols.
• The abstract definitions then allow the mapping of the data objects and services to any other
protocol that can meet the data and service requirements. The definition of the abstract
services is found in Part 7-2 of the standard.
Example: XCBER Logical Node
As stated previously, the term logical node is a reference to an object of the model that represents
real-world inputs, outputs, and settings of functions or the equipment of the power system entity. The
diagram above depicts a circuit breaker. This is the classic example described in the IEC 61850
standard. The proper name for the circuit breaker logical node is defined in 7-4 of the standard as
XCBER (with an instance number, which in this case is 1).
Logical Node Naming Convention
A group indicator is used to classify the different types of logical nodes into one of the categories
shown on this and the following slide. There are logical nodes for automatic control, the names of
which all begin with the letter A. There are logical nodes for metering and measurement, the names
of which all begin with the letter M. There are also logical nodes for Supervisory Control (C),
Generic Functions (G), System logical nodes (L), Protection (P), Protection Related, Switchgear (X),
etc. Each logical node has a Logical Node Instance-ID as a suffix to the logical node name to
distinguish between two otherwise identically named nodes.
This slide provides some examples of protection logical nodes.
This slide provides some examples of protection logical nodes.
This slide provides some examples of protection-related logical nodes.
This slide provides some examples of control, breaker, and switch logical nodes.
The Logical Node Prefix
According to the standard, each logical node can also have up to three letters as a prefix to provide an
intuitive description.
The logical node typically contains many data objects that have specific names and attributes.
Functional constraints define what and how the data will be grouped. Examples of data functional
constraints are:
• Status
• Settings
• Measured values
• Controls
This diagram shows the IEC 61850 logical node XCBR and the data objects.
The column on the right indicates if a particular data object is mandatory, optional, or conditionally
mandatory. The data object Pos (switch position) is one of the many data objects within the logical
node XCBR1. We can see that the position (Pos) data object is mandatory as position of the circuit
breaker is likely to be required by other components in the substation. The T indicates Transient
Data: the status of data with this designation is momentary and must be logged or reported to provide
evidence of their momentary state.
The Common Data Class
Each element of data within the logical node conforms to the specification of a CDC per IEC 61850-
7-3. Each CDC describes the type and structure of the data within the logical node. For instance,
there are CDCs for status information, measured information, controllable status information,
controllable analogue set point information, status settings, and analog settings. Each CDC has a
defined name and a set of CDC attributes, each with a defined name, defined type, and specific
purpose.
Functional Constraints (FC)
Each individual attribute of a CDC belongs to a set of functional constraints (FC) that groups the
attributes into categories. As an example, the Single Point Control (SPC) CDC shown above has
functional constraints for status (ST) attributes; we can see that the breaker position can be
represented by False or True or a count from 0 to 255. Also included is a time stamp of the last state
change and quality of the data: is the data forced, startup data, etc.
IEC 61850 Data Organization
In the process of mapping the IEC 61850 objects to MMS (Manufacturing Message Specification),
IEC 61850-8-1 specifies a method of transforming the model information into a named MMS
variable object that results in a unique and unambiguous reference for each element of data in the
model. For instance, suppose that you have a physical device named SEL_751 consisting of logical
device named SEL_751_PRO for protection, having a single circuit breaker logical node XCBR1 for
which you want to determine if the breaker position is open or closed. To determine this, you would
read the object shown above.
The logical device exists within the physical device, logical nodes exist within the logical device, and
the data objects exist within the logical nodes.
Information Exchange Methods
IEC 61850 has a broad scope of communications services to exchange data, which can be generally
classified as either a Client/Server or Publisher/Subscriber service. The IEC 61850 standard relies on
the Abstract Communication Service Interface (ACSI) models to define the services for the exchange
of the information contained within a logical node. Part 7-2 of the IEC 61850 standard defines the
information exchange methods. The application requirements will determine which service is used.
The XCBR breaker position information could be sent to another IEC 61850-compliant device via
one or more of these services.
• IEC 61850 Client and/or Server Communications services:
 Poll and/or response: fast reading (polling) of specific data within devices for changes.
This is a connection-based service requiring more communications layers than GOOSE;
hence, it is not as fast and requires more CPU time.
 Reports: the reports can serve as indications to the client with the ability to maintain the
sequence of events. Sending the events only when required (controlled but the reports
control block) in addition to low-frequency client-initiated general interrogation ensures
database integrity. Reports also support the ability to be polled for specific data objects at
any time.
 Logging: the major difference between a reporting and a logging is that logging of events
is associated with retrieval at a later date rather than serving as a real-time indication.
• IEC 61850 Publisher/Subscriber Communications services:
 GOOSE messaging: When a data set is assigned this service, the data set is published at
power up, anytime there is a digital state change, or when an analog exceeds its dead
band. This is analogous to a magazine publisher publishing magazines. The subscribers
see the messages on the Ethernet port and subscribe to only the messages of interest.
This service is intended for low-latency applications.
IEC 61850 Protocol Map
As stated previously, the IEC 61850 has a broad scope of communications services. Each service has
a variety of protocols that can be employed. This diagram illustrates the protocol map for different
communications services. Some services, such as GOOSE, are optimized for speed while others,
such as MMS services, are focused on confirmable messaging. The data and service chosen is based
on the application requirements.
Basic MMS services:
• Initiate/conclude/abort: Make or break connections between a client and a server
• Read/write: Variables and labels
• InformationReport: Send an unsolicited read response to a client
• ReadJournal: Query a historical log of variable data
• GetNameList/GetObjectAttributes: Retrieve the definition of an object
This slide shows an example of how an MMS client would display an SEL-751 IEC 61850 data
structure.
Reports:
In contrast to high bandwidth and CPU consuming fast reading (polling) devices for extraordinary
event occurrences, reports can be used:
• Sequence-of-events: reports have a sequence number, and so they can act as a sequence of
events
• Change-of-state notification of clients: immediate reports
• Polling specific data objects within the report at any time: GetDataValues and
GetDataSetValues
Buffered-report-control-block (BRCB) provides the sequence-of-events (SOE) functionality. If

communication to the client is lost for a short period of time, the reports are buffered. If there is no
overflow, once communication to the client is re-established, all reports are sent. If an overflow
condition occurs, the server continues to store events in a FIFO. Once communication is re-
established, the server indicates the overflow to the client, and the client can signal the server to flush
the reports or send all available reports.
Unbuffered-report-control-block (URCB)—Internal events (caused by trigger options data-

change, quality-change, and data-update) issue immediate sending of reports on a “best efforts” basis.
If no association exists, or if the transport data flow is not fast enough to support it, events may be
lost.
GOOSE Messaging
The first IEC 61850 communication service to be used to exchange information between vendors
was the “original GOOSE,” which is now called GSSE. In addition to digital values, the “New
GOOSE” support of VLANs, priority, and analog values has led to its success. Today, GOOSE and
Reports are the most commonly used services within typical IEC 61850 substation automation
applications. GOOSE is a high-speed, peer-to-peer data communications service with an IEC 61850
requirement for less than 3 milliseconds latency from application layer to application layer. An
example of a protective relaying application for which GOOSE is suitable is the bus blocking scheme
for a radial system shown on this slide.
GOOSE Messaging
If a fault occurs downstream of Feeder A, both Feeder A relay’s directional overcurrent elements and
the bus overcurrent protection elements detect the fault. The bus protection elements are time-
coordinated with the feeder protection elements. The delay on the bus protection elements allow time
for Feeder Relay A to publish a GOOSE message announcing that Feeder A will attempt to isolate
the fault. This is referred to as a blocking message, but in reality the presence of the GOOSE would
introduce a delay within the bus protective elements to allow the feeder to clear the fault. If no
blocking GOOSE message is received by the bus protection within this delay time, the fault was not
seen by Feeder A’s directional overcurrent elements, so the fault is assumed to be on the bus, and the
protection elements of the bus will then attempt to clear the fault.
An IEC 61850 station bus system is shown in the figure on this slide. Rather than opt for station bus
standard CTs, VTs, and digital I/O breaker status, signals are hard-wired to the protection equipment.
Introduction to IEC 61850 9-2
Process bus communication is based on an Ethernet bus. Merging units connected to traditional CTs,
VTs, and breaker I/O publish sampled values on an Ethernet LAN to make it available for protection
and control equipment. The station-wide communication bus is based on Ethernet LAN technology
that uses switches or routers to provide data communications connectivity for each bay segment to
transmit the required data streams. Modern switchgear, CTs, and VTs may have the ability to publish
these data directly. Time stamping the LAN structure can be arranged in different ways as described
in IEC 61850-1. Time synchronization could be accomplished via IEEE 1588, but this is outside the
scope of the standard.
With a Sampled Values approach, analog data are sampled and digitized by a merging unit, which
can be located in a yard kiosk or equipment cabinet. The relays in the control house subscribe to data
streams from the merging unit and make protection decisions based on those data.
IEC 61850-9-2-compliant instrument transformers can also be used to output the Sampled Value data
streams that relays subscribe to. However, digitizing, publishing, communicating, and time-
synchronizing devices add extra complexity and modes of failure to protection systems.
This slide shows a basic networking diagram for using IEC 61850-9-2 Sampled Values (SV). Some
users prefer fully redundant process bus networking, which greatly increases costs and complexity.
The station bus has typical SCADA traffic, such as DNP3, Internet Protocol (IP), GOOSE, and
MMS. The process bus only has IEC 61850-9-2, GOOSE, and PTP traffic.
A Sampled Values system faces many challenges. Extra networking equipment is needed to support
an IEC 61850-9-2 system. Also, networking cables that extend outside of the control house can pose
a cybersecurity risk.
Another challenge is finding design, testing, and troubleshooting expertise for the network systems
required for IEC 61850-9-2. These competencies may not be available with current staff. Hiring
outside contractors for these services can add a significant cost.
Interoperability is a perceived advantage of Sampled Values, but most of these systems are actually
single-manufacturer systems. For example, the Metropolitan Electricity Authority of Thailand has
implemented 62 IEC 61850-9-2 projects, and none of them use multiple manufacturers. Most users
prefer not to mix-and-match manufacturers in a protection system.
Another challenge is obtaining thorough knowledge and acceptance of IEC 61850-9-2 systems.
This slide shows an example SEL Time-Domain Link (TiDL™) application. TiDL refers to the
communications link.
This scenario has two SEL-2240 Axions® : one provides three-phase currents and three-phase
voltages, and the other provides three-phase currents. Both of these Axion nodes control their
associated circuit breaker.
EtherCAT® is registered trademark and patented technology, licensed by Beckhoff Automation

GmbH, Germany.
In response to the challenges presented by IEC 61850-9-2 and to assist customers with their copper
reduction strategies, SEL has released SEL TiDL technology. No time connection (either IRIG-B or
PTP) is needed at the Axion node because the EtherCAT network maintains time relative to the relay.
TiDL node scans are synchronized to within ±100 ns across all nodes.
Substation Configuration Language
From the perspective of the entire substation integration process, there is a significant amount of
configuration required in order to ensure that all communications links have been configured
correctly, especially if this involves communications between multiple devices. In order to eliminate
human error and improve efficiencies, an XML (or Extended Markup Language) based Substation
Configuration Language (SCL) was defined in Part 6. XML is the file format that has been specified
to ensure interoperability during file exchange between vendors or between products within a
vendor’s product line. It is used to describe IED configurations and communications systems
according to IEC 61850-5 and IEC 61850-7-x.
The SCL Process
The configuration and exchange process is described in detail within the standard to ensure
interoperability. ACSELERATOR Architect® SEL-5032 Software is SEL’s version of the Substation
Configuration Language software. Current vendor implementations of SCL, at a minimum, produce a
Configured IED description file (CID file). It is common to have ACSELERATOR Architect import
CID files form other vendors. The information contained within these CID files allows
ACSELERATOR Architect to configure SEL relays and other devices to subscribe to the third-party
GOOSE messages.
In Labs 6 and 7, we will use ACSELERATOR Architect to set up GOOSE between two SEL-751
Relays, while in Lab 14, the SEL-751 will be configured with a custom Buffered Report containing
both digital and analog measurement data for an RTAC client.

Overview of The IEC 61850 Standards

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Overview of The IEC 61850 Standards

Uploaded by

Copyright:

Available Formats

Overview of the IEC 61850 Standards

Introduction to IEC 61850

• Information exchange methods

 GOOSE (peer to peer)

• Substation Configuration Language (SCL)

IEC 61850 Standard provides solutions:

• Object-oriented database structures

• Combination of protocols for different needs

 Client/server replaces traditional master/slave

 Publish/subscribe methods are added

• Substations are networked using Ethernet

 Familiar tools and processes

 Widely used hardware is becoming more affordable

IEC 61850 Main Sections

• Part 7 has 4 subsections:

IEC 61850 Main Sections (continued)

 Part 7-3: Common data classes (CDCs)

 Part 7-4: Logical nodes

• Part 9-2: SCSM with Sampled Values over Ethernet

• Part 10-1: Conformance testing

Information Models: The Approach

Example: XCBER Logical Node

Logical Node Naming Convention

This slide provides some examples of protection logical nodes.

This slide provides some examples of protection logical nodes.

This slide provides some examples of protection-related logical nodes.

The Logical Node Prefix

The Common Data Class

Functional Constraints (FC)

IEC 61850 Data Organization

Information Exchange Methods

• IEC 61850 Client and/or Server Communications services:

• IEC 61850 Publisher/Subscriber Communications services:

IEC 61850 Protocol Map

Basic MMS services:

• Initiate/conclude/abort: Make or break connections between a client and a server

• Read/write: Variables and labels

• InformationReport: Send an unsolicited read response to a client

• ReadJournal: Query a historical log of variable data

• GetNameList/GetObjectAttributes: Retrieve the definition of an object

• Change-of-state notification of clients: immediate reports

Buffered-report-control-block (BRCB) provides the sequence-of-events (SOE) functionality. If

Unbuffered-report-control-block (URCB)—Internal events (caused by trigger options data-

Introduction to IEC 61850 9-2

EtherCAT® is registered trademark and patented technology, licensed by Beckhoff Automation

Substation Configuration Language

The SCL Process

You might also like