1
Communication Protocols and Networks
for Power Systems-
Current Status and Future Trends
S. Mohagheghi, Member, IEEE, J. Stoupis, Member, IEEE, and Z. Wang, Member, IEEE
Abstract—Minimizing implementation time and manual
configuration, as well as straightforward upgradability are the
key requirements of efficient substation automation systems. For
larger utilities this often necessitates achieving interoperability
between different devices from multiple vendors. Since the early
1990’s it was noticed that the speed of advances in
communication technology seemed to overpass its power system
counterpart, which called for more adaptability by substation
automation systems and higher independence from the
underlying communication technology. The natural shift in the
industry from proprietary communication protocols to open
access standards was therefore further accelerated and was
directed towards more advanced solutions that provide an
interoperable and future proof environment. In order to be able
to respond to these concerns, IEC 61850 was proposed as a future
proof, adaptable communication protocol, capable of providing
interoperability in a multi-vendor environment and with a highly
advanced object oriented modeling structure. The migration
from legacy protocols and de facto standards such as Modbus,
DNP3, and IEC 60870-5 has already started and it seems likely
that it will continue at a steady pace in the future. In addition to
the efforts to provide an advanced solution for substation
automation systems, there is also a need for extending the
“automation” benefits to beyond the substations either
downstream, at the feeder level or upstream, at a higher level of
network management. The objective of this paper is to provide
an overview of the current status of communication networks for
substations using IEC 61850, and also discuss the possible future
trends for extending the scope of the standard and using its
capabilities for other applications within the distribution system.
Index Terms—Communication networks, distribution system,
communication protocols, IEC 61850, TASE.2, DNP3, Modbus,
interoperability.
I. NOMENCLATURE
ACSE- Application Control Service Element
ACSI- Abstract Communication Service Interface
CID- Configured IED Description
CRC- Cyclic Redundancy Check
GOOSE- Generic Object Oriented Substation Event
GSSE- Generic Substation State Event
HMI- Human Machine Interface
ICCP- Inter Control Center Communications Protocol
ICD- IED Capability Description
IED- Intelligent Electronic Device
The authors are with ABB Inc., US Corporate Research Center, Raleigh,
NC, 27606 USA (email: salman.mohagheghi@us.abb.com, james.stoupis
@us.abb.com, zhenyuan.wang@us.abb.com).
MMS- Manufacturing Message Specification
OSI- Open Systems Interconnection
PDU- Protocol Data Unit
PMU- Phasor Measurement Unit
RBE- Report by Exception
SA- Substation Automation
SCD- Substation Configuration Description
SCL- Substation Configuration Language
SSD- System Specification Description
SV- Sampled Values
TASE- Tele-control Application Service Element
II. INTRODUCTION
C
OMMUNICATION protocols and standards were
introduced to the industry since late 1970’s. These
standard protocols were quickly adopted for power system
applications and gradually replaced their proprietary
counterparts. Designed primarily to ensure interoperability
between multi-vendor systems, these protocols also simplify
integration and commissioning of data communication
networks, reduce the installment costs, and allow for
independent testing and validation, which in turn leads to
more efficient designs. In addition, communication systems
designed in accordance with these standards can be more
easily upgraded or modified in the future. This is especially
important, since the advances and innovations in the field of
communication networks often outpace the frequency of
modifications in the power system infrastructure. Therefore,
the designed communication network must be adjustable to
new power system automation designs with the least amount
of effort possible.
A typical power system is an interconnected network that
connects the distribution system, the transmission system, and
the generation units. Ideally, all sections of such a network
must be able to communicate with one another, and share all
the data. However, in practice, this does not seem practical
due to the sheer volume of the data involved, limitations on
the available communication channels, as well as security
concerns. Therefore, data sharing and communication systems
have often been designed to cover subsystems rather than the
whole power grid. In a typical power system several standard
communication protocols exist, each one covering certain
domains and a specific group of data. Figure 1 illustrates an
example of some communication protocols used in a typical
power system [1].

Distribution substations constitute the heart of the
distribution system and depending on their size, contain tens
to hundreds of different protection and control devices, not
necessarily from the same manufacturer. Various standard
protocols such as IEC 60870-5, DNP3 and IEC 61850 are
used to make coordination and data sharing between these
devices possible. A more concise portion of this data needs to
be sent to the higher level of the hierarchy, which includes the
control centers. In addition to communication with the control
centers, distribution substations often need to monitor the data
from the feeders and load points connected downstream, in
order to improve the protection and control decisions.
Fig. 1. Typical communication protocols used in a power system.
Control centers on the other hand manage the stability,
security and reliability of the power system as a whole, and in
order to achieve this, among other things, they need to have
access to the vital information from the distribution side. In
addition, these control centers communicate with one another,
as well as with the generating units and market participants if
applicable. Various communication protocols exist that can be
used to achieve this.
The purpose of this paper is to present an overview of
some of the most common communication protocols and
standards used inside and outside the distribution substation.
Also, future trends and possible extensions to these protocols
are briefly discussed.
The rest of the paper is organized as follows. Section III of
the paper provides a brief overview to two examples of legacy
protocols used in the power industry: Modbus and DNP3,
where the latter is currently the predominant standard used in
distribution substations in North America. A general
introduction to IEC 61850 as the next generation
communication protocol is presented in section IV of the
paper. Common practices for communication protocols
2
beyond substations appear in section V. In section VI, some
of the future trends and possible extensions to the usage of
IEC 61850 are discussed. Finally, concluding remarks are
provided in section VII of the paper.
III. LEGACY PROTOCOLS
A. Modbus
Modbus transmission protocol was developed by Gould
Modicon (now Schneider) for process control systems, and
has been industry’s serial de facto standard since 1979. It is
an application layer messaging protocol that is positioned at
level 7 of the OSI model [3] and is used for client/server
communication between devices connected to the same
network. Modbus messages are of either query/response type
or broadcast/no response type, which in either case can only
be initiated by the client, in other words RBE is not supported
(except for Modbus TCP). Every type of device (PLC, HMI,
control panel, driver, I/O device) can use Modbus to initiate a
remote operation.
In general, different transmission protocols exist for
implementing Modbus protocol [2]:
• Asynchronous Serial Transmission: for serial connections
(over wire RS-232, 422 or 485, fiber or radio). Two
different transmission modes exist, Modbus RTU, a
compact, binary representation of the data, which is faster
and is used for normal operation (hex); and Modbus
ASCII, which is human readable, and more verbose, and
is used for testing purposes.
• TCP/IP over Ethernet
• Modbus Plus: also referred to as Modbus+ or MB+,
which is currently proprietary to Modicon.
Using gateways these different implementations can
coexist in a single communication network [4] (Fig. 2).
Fig. 2. Modbus implementation on LAN.
Modbus supports four main data types: read only 1-bit
inputs and 2-byte input registers which can be provided by an
I/O system, and 1-bit discrete outputs (coils) and 2-byte

holding registers, which are read/write enabled and can be
altered by an application program.
Modbus protocol defines a simple PDU independent of the
underlying communication layers [4]. A typical Modbus
Application Data Unit (ADU) is shown in Fig. 3 [2]. The
address field contains the address of the server. The function
field includes the code of the function to be performed by the
server. Examples of these functions are coil control
commands, reading the input status of coils, register control
commands, diagnostics tests and reports, and reset
commands. The information that the server might need to
perform the requested function is provided in the data field,
and finally the last 2 bytes contain the CRC bits.
Protocol Data Unit (PDU)
Application Data Unit (ADU)
1 Byte 1 Byte Variable 2 Bytes
Address Error Checking
Function Field Data Field
Field Field
Fig. 3. Typical Modbus ADU.
For asynchronous Modbus and Modbus+ the ADU in Fig.
2 is directly mapped to the physical layer, while in
Modbus/TCP it is first passed through the transport and
network layers (Fig. 4) [3].
Fig. 4. Mapping Modbus onto the OSI model.
B. DNP3
DNP3 is a telecommunications standard that defines
communications between client stations, RTUs and other
IEDs. It was developed by GE based on the early parts of IEC
60870-5. They made it public in 1993, and the ownership was
given to the newly formed DNP Users Group. It was
originally designed for SCADA applications, i.e. acquisition
of information and sending control commands between
physically separate computer devices, however, today DNP3
is widely used in electrical, water infrastructure, oil and gas,
security and other industries in North America, South
America, South Africa, Asia and Australia (cf. IEC 60870-5-
101/104 [5] which is mostly confined to electrical industries
in Europe and more or less provides the same functionalities
as DNP3).
The purpose of DNP3 is to transmit relatively small
packets of data in a reliable manner with the messages
involved arriving in a deterministic sequence. Figure 5 depicts
the overall messaging sequence in DNP3 [2]. Application data
3
may be any size, even zero, for example for a command. This
is broken into multiple Application PDU (APDU), or
Fragments, with a size limit of 2048 bytes. Breaking longer
messages into multiple packets helps optimize error control.
The APDU is further broken down into multiple Transport
PDUs (TPDUs), with a size limit of 250 Bytes to fit into the
Data Link frame. Link layer header and the CRC bytes are
added to the TPDU, and the resultant Link PDU (LPDU or
frame) is passed on to the physical layer, which transmits 8
bits of data plus an additional bit to indicate start/stop of each
sequence.
Fig. 5. Structure of a DNP3 message.
The original physical layer consisted of RS232, for short
distance point-to-point communications, RS 422, which is a
bidirectional extension of RS232 for industrial environments,
or RS485, for multipoint communications. However, today’s
operating environments have changed so that organizations
can operate over larger geographic areas. This has pushed
DNP3 to define a method involving the use of internet
protocol suite for the transport and network layers, and the
Ethernet physical layer. The idea of carrying DNP3 over a
network environment involves encapsulation of the data
frames from the DNP3 data link layer within the transport
layer frames of the internet protocol suite.
As it is shown in Fig. 6 [2], pseudo-transport and data link
layers of DNP3 remain in the stack and act above the
transport/network/data link layers provided by TCP/UDP, IP
and Ethernet LAN. This is because these are essential
elements of the DNP3 layers that are required to operate
together, for instance addressing and error detection in the
data link frame. In such an environment, TCP is strongly

preferred for LANs and is necessary for WANs. UDP, on the
other hand, may be used for highly reliable LANs, or for
broadcast messages [2].
In addition to the traditional client/server communication
mode, DNP3 also supports peer-to-peer, multi-server, multi-
master and hierarchical mode communications (using data
concentrator) [6]. It also provides polled and RBE modes of
operation.
Fig. 6. DNP3 over Ethernet.
IV. COMMUNICATION WITHIN THE SUBSTATION- IEC 61850
IEC 61850 is a standard recommended by IEC for the
design of substation automation systems [8]. It divides inter-
substation communication into three levels: process level
including the I/O devices, intelligent sensors and actuators,
bay/unit level including the protection and control IEDs, and
the substation level, including the substation computer,
operator’s desk and the interfaces with outside the substation.
All the communications within and between these levels are
covered in the standard (Fig. 7). Although in its current
format, the standard does not cover protection data exchange
between the bay and remote protection, nor control data
exchange between substation and remote control center.
Fig. 7. Substation automation topology based on IEC 61850.
4
A. Object Oriented Model
In the IEC 61850 environment, protection and control
functions are broken into smaller units called Logical Nodes
(LN). These virtual units are in fact the objects defined in the
object oriented context of the standard, and present one of the
most important advantages of the standard over legacy
protocols. There are a total of 92 LNs defined in IEC 61850
that correspond to various protection, protection related,
control, metering, and monitoring functions as well as the
physical components such as the transformers and breakers.
Figure 8 illustrates an example where multiple LNs interact
with one another to perform three functions: generic
automatic function, breaker control function and voltage
control function [8].
Fig. 8. Example of logical nodes for generic automatic function, breaker control
function and voltage control function (IHMI: human machine interface, CALH:
alarm handler, CILO: interlocking, GAPC: generic automatic process control,
GGIO: generic input and output, CSWI: circuit breaker controller, XCBR:
circuit breaker, XSWI: isolator, ATCC: automatic tap changer controller,
YLTC: tap changer)
Each LN can have a few or up to 30 data objects, each of
which belonging to a Common Data Class (CDC). Each data
object in turn has a few or more than 20 data attributes. The
LNs can be on any of the three levels defined for substation
automation. It should be noted that each physical device such
as an IED can host several logical nodes depending on its
functionality. These LNs are grouped into logical devices
(LD) which are defined in the context of the physical device,
with each physical device containing at least one logical
device [8] (Fig. 9).
Fig. 9. Data structure in IEC 61850.

IEC 61850 defines an abundance of services that act upon
the data objects of the LNs. These services not only cover the
traditional control/read/write commands, but they also cover
new and expanded services for grouping the data objects,
reporting and logging, as well as transmitting the fast
messages, i.e. GOOSE and GSSE [8] (Fig. 10).
Fig. 10. LN, LD and the communication services.
B. Communication Services
The communication services and data models are defined
in section 61850-7-2 of the standard. The Abstract
Communication Service Interface (ACSI) specifies the models
and services used for access to the elements of the domain
specific object model. ACSI is a network independent
interface that defines the semantic of the service models with
their attributes, and describes what these services provide.
The abstract nature of ACSI is necessary to make the SA
system compatible with the fast advances in the
communication technology. In other words, the SA specific
data model needs to be separate from the communication
technology.
The syntax and encoding of the messages are defined in
Specific Communication Service Mapping (SCSM). For
example, IEC 61850-8-1 is a SCSM for mapping of services
to MMS. Figure 11 illustrates how these communication
stacks and interfaces are related.
Fig. 11. Data model and communication services- mapping to the OSI layered
model
5
In addition to client/server services by mapping to MMS
stack, the standard provides peer-to-peer services for
transmitting Sampled Values (SV) and GOOSE messages
(Fig. 12).
SV represents quantities digitized at the source to be
transmitted to the substation. These quantities come from
modern low energy voltage and current sensors which gather
information from the primary power system. IEC 61850-9-1
and 61850-9-2 define two mappings for SV over serial
unidirectional multi-drop point to point link and SV over
ISO/IEC 8802-3.
GOOSE messages on the other hand are used to model the
transmission of high priority information like trip commands
or interlocking information. The model is based on cyclic and
high-priority transmission of status information. Information
like a trip command is transmitted spontaneously and then
cyclically at increasing intervals. GOOSE uses a multicast
exchange.
Fig. 12. Client/server and peer-to-peer communication modes in IEC 61850.
C. Substation Configuration Language (SCL)
Substation Configuration Language (SCL) is an eXtensible
Markup Language (XML) based language used by IEC 61850
for representation and configuration of the SA system. It
includes data representation for all the devices in the
substation, all the logical nodes along with their data objects
and attributes, as well as communication systems and
capabilities. The representation of the IEDs and the SA
functions as a SCL files is one of the most prominent features
of the standard that enhances the communication capabilities
between different IEDs towards a complete interoperability.
Some of the major benefits of SCL modeling include [9]:
• Enabling automatic configuration of IEDs using offline
development tools, significantly reducing the cost and
effort of IED configuration.
• Enabling the sharing of IED configuration among users
and suppliers.
• Enabling offline configuration of IEC 61850 applications
without requiring a network connection to the IED for
client configuration.

Part IEC 61850-6 of the standard defines four types of
SCL files :
• IED Capability Description (ICD): describes the
capabilities of the IED, and comprises of an IED section,
data type templates, logical node type definitions,
optional communication section and an optional
substation section.
• System Specification Description (SSD): describes the
specifications of the related system, and comprises of a
substation description section, data type templates, and
logical node type definitions.
• Substation Configuration Description (SCD): describes
the detailed power system, and comprises a description
section for each IED, a communication configuration
section and a substation description section.
• Configured IED Description (CID): is used to
communicate data and settings between an IED and its
configuration tool. It includes a communication section
that contains the current address of the IED.
D. Comparison with Legacy Protocols
Although IEC 61850 is often referred to as a more
advanced communication protocol, with its object oriented
modeling capabilities and detailed communication interfaces
defined, it tends to be more than just a protocol in the
traditional sense. Nevertheless, it has major advantages
compared to the legacy protocols, such as DNP3 and IEC
60870-5-101/104. Some of the major advantages of IEC
61850 are listed below [10]:
• Similar to legacy protocols, it allows vendors to create
application specific extensions, but it also provides close
to 100 logical node classes with 2000+ data
objects/attributes.
• It is more easily extendable than legacy protocols.
• It uses hierarchical names (see Fig. 9) instead of indexed
addressing.
• Similar to DNP3 and IEC 60870-5 (and unlike Modbus)
it supports quality attribute, time stamp, and cause of
transmission.
• The data (LNs, data objects and attributes) are more self
descriptive.
• It is more flexible in parameter setting control, and allows
the user to define, change and edit the parameters at any
time. This capability is limited in legacy protocols.
• It provides means to transmit substation events (GOOSE)
and sampled values.
• It allows the user to access the complete information
hierarchy of all objects by obtaining the directory. This
service is limited in 60870-5-103 and does not exist in
DNP3.
• It is more powerful in providing the definitions of
operational objects and communication service related
objects.
• It is more flexible in selecting the data for reporting,
enabling/disabling the communication control objects,
and changing reporting/logging behavior.
6
• Complete description of device configuration is available
in XML format, instead of hardcopy documents (this
feature is under development for DNP3).
• It fully supports vendor independent engineering tools for
development.
• IEC 61850 is also open for future service systems, such
as HTTP, COBRA.
However, it should be noted that although IEC 61850 has
major advantages over Modbus, DNP3 and IEC 60870-5 on
the data side, it also adds a lot of overhead for
implementation. It is more complicated than the legacy
protocols, so it may take some time to be fully adopted by the
industry. Current estimates indicate that the market
penetration of the standard has increased during the past few
years [10], but the authors believe that at least in the North
American market it will not overpass DNP3 in the immediate
future. Recent surveys indicated that DNP3, especially LAN
based DNP3, is the leading protocol for planned usage in the
future within the substation and for communication from the
substation to the external network/host [11].
V. COMMUNICATION OUTSIDE THE SUBSTATION
A. Upstream- ICCP
Traditionally, utilities used to rely on proprietary protocols
to exchange real-time data. Gradually, a need was felt for
migrating towards an open access standard protocol to allow
for better disturbance detection and reconstruction, improved
modeling capabilities and enhanced secure operation. The
result was two standards, referred to as the Tele-control
Application Service Element (TASE), recommended by the
IEC TC-57 WG-07 [12]. A quick implementation called
TASE.1 was developed in 1992 in order to meet the European
Common Market requirements. Later, TASE.2 was developed
as a long term development of a more comprehensive
protocol. TASE.2 is also referred to as Inter-Control Center
Communication Protocol (ICCP) [13].
ICCP sits in the upper sub-layer of layer 7 in the OSI
reference model and uses MMS for the required messaging
services. MMS specifies mechanics of naming, listing and
addressing variables, and mechanics of message control and
interpretation, while ICCP specifies control center object
formats, and methods for data requests and reporting.
ICCP can operate over either an ISO compliant transport
layer or a TCP/IP transport layer; although, TCP/IP over
Ethernet (802.3) seems to be the most common (Fig. 13)
[13],[14].
ICCP is based on client/server models. All data transfers
originate with a request by a control center to another control
center that owns and manages the data. A control center can
be both a client and a server. The types of requests can be
single requests, requests for periodic transfers, or requests for
RBE only. ICCP might operate over a point-to-point link or
over a router based WAN. The common implementation
architecture is that the ICCP is used over Ethernet and that
 7

WAN connectivity for remote access is supplied through the
use of an external router [14].
Using ICCP, applications at different control centers,
written by different vendors but conforming to the protocol,
can interoperate to share data, control utility devices, output
information messages, or execute remote programs. Each
vendor implementing ICCP is free to choose the API most
suitable for their products. This is a local implementation
issue and is not addressed in ICCP.

Fig. 13. ICCP mapping onto the OSI stack.

Multiple associations may be established from a client to
multiple control center servers [13]. It may also be established
to the same control center for the purpose of providing
associations with different Quality of Service (Fig. 14).

Fig. 15. ICCP objects.

In the US, ICCP networks are widely used to tie together
groups of utility companies typically a regional system
operator with transmission utilities, distribution utilities and
generators [14]. Regional operators may also be connected
together to coordinate import and export of power between
regions across major inter-ties. In addition, ICCP can also be
used to exchange information between applications located
within a single control center, for instance between the control
center’s EMS and a historian or SCADA system [14] (Fig.
16).

Fig. 14. Multiple associations for ICCP clients.

The server checks each client request to ensure that the
particular client has access rights to the data or capability
requested. Access control is provided through Bilateral Tables
which are defined for each client/server association and
provide execute, read/write, read only, no access for each
item.
There are two types of object models in ICCP [13] (Fig.
15):
• Server Objects: Defined in IEC 60870-6-503. Can be
either Operations (client-initiated) or Actions (server-
initiated, e.g. due to a change in the status of a breaker).
These are the internal objects that are required to
implement the ICCP protocol.
• Data Objects: Defined in IEC 60870-6-802. Supported Fig. 16. ICCP implementation over WAN and LAN.
data types include control messages, status, analogs,
B. Downstream- DNP3
schedules, text and simple files. New data objects can be
defined as well. These are the external objects and are not DNP3 (or IEC 60870-5 for European implementations) can
required for implementing the protocol. be used for communication between the substation and the

control center. The DNP3 implementation on TCP/IP allows
for transferring the data over WAN.
DNP3 is also the main protocol currently used to
communicate with feeder automation equipment. This could
be communication between the substation and the feeder
devices or between the SCADA system (control center) and
the feeder devices. The RBE feature is extremely useful for
feeder applications, especially when utilities do not want to
continually poll the feeder devices due to cost of data
transmission.
Currently, DNP3 is the leasing protocol for
communications outside the substation, and will remain the
leading protocol for planned usage in the future [11].
VI. FUTURE TRENDS
A. IEC 61850 beyond Substations
Although standard protocols exist that cover
communications beyond substations, it is generally believed
that the capabilities of IEC 61850 can be potentially used to
improve these applications.
1) Feeder Communication
During the recent years, more efficient operation,
reduction in projected costs and improved reliability have
motivated electric utilities to increase the level and scope of
automation of their assets. Although IEC 61850 addresses
issues related to substation automation, the same ideas and
capabilities can be utilized equally well for beyond
substations, such as feeders and distributed generation and
storage units.
Extending the IEC 61850 standard to feeders ensures the
interoperability of all components participating in distribution
automation, from the distribution substation to the point of
interface with the end users. This extension requires including
some or all of the following components in the IEC 61850
framework:
• Switched capacitor banks and static VAR compensators
• Voltage regulation devices
• Network protectors
• Feeder transformers
• Feeder control devices, switches and reclosers
• Power quality enhancement devices, such distribution
FACTS (DFACTS) devices and voltage sag correctors
• Other power electronic based devices used in the
distribution systems
• Protection systems, fuses and relays along the feeders
• Fault detectors, indicators, locaters
• Information exchange with metering devices deployed
along the distribution feeders, e.g. advanced metering
infrastructure (AMI)
Extension of IEC 61850 to the feeder can be in the form of
using the same logical nodes defined in the standard, or
applying the same messaging techniques such as GOOSE
messages for fast exchange of protection and control, and
sampled values for transmitting the measured values from the
8
feeder to the substation.
Obviously, achieving this requires a widespread
communication network and the required infrastructure that
links the feeder devices to the HMI in the substation. This will
necessitate initial investment; however, it will prove to reduce
the overall costs in the long run due to improved reliability
and operation.
2) Communication with Control Centers
IEC 61850 specifies that connection to the remote control
center is beyond its scope [8]. Expanding the standard to
include the link to the control centers is technically possible;
although, it would require having a large amount of additional
logical connections between the substation and the control
center, and possibly defining additional logical nodes. While
defining new logical nodes does not introduce any technical
complications, implementing additional logical connections
might lead to inefficient performance.
It is generally believed in the industry that this integration
can be more efficiently done in two ways:
• Map IEC 61850 data model content to a traditional
SCADA protocol such as DNP3 or IEC 60870-5 [15].
This does not pose a technical difficulty, but might lead
to some loss of information or speed, for instance when
mapping GOOSE messages.
• Provide a proxy server for IEC 61850 data in the
substation. This provides for a gateway in the substation
providing a single point of access for the 61850 data
model content [15]. Section 61850-7-1 of the standard
shows how logical device modeling can be utilized to
map multiple physical devices into a single physical
device to act as a proxy or gateway or multiple devices.
In this case, the proxy/gateway device functions as a data
concentrator and can direct requests/responses between
substation and the control center. This virtual interface to
the outside world can be a telecontrol interface (TCI) to a
remote control center, or a telemonitoring interface
(TMI) to remote engineering workplace for monitoring
and maintenance purposes.
B. Peer-to-Peer Communication
GOOSE messages are one of the unique features provided
by IEC 61850 that allow fast messages between different
IEDs in a peer-to-peer format. While the standard only
considers intra-substation communications as the scope for
GOOSE, it is possible to employ the concept for applications
beyond substations.
One of the examples is using GOOSE messages for fast
transfer of sensitive information between protective relays
(e.g. trip commands or outage detection) or PMUs (e.g.
over/under-voltage or current flows close to stability/thermal
limits) at the transmission level. This information can be
extremely helpful for improving the reliability and security of
the overall power system.
Naturally, such a scheme would require using the current
communication infrastructure or maybe expanding its
bandwidth capabilities in order to ensure that the signals are

sent and received within the required timeframe. In general,
for a large size power system, this means a WAN that covers
the whole geographical area. Possible transmission media are
fiber optics and microwave.
In one possible scheme [16], once the GOOSE message is
generated and sent, it is picked up by a centralized processor,
which can be a high performance computing unit that
interprets the GOOSE message, identifies the contingency,
performs calculations and determines a remedial action,
which is then transmitted to the communication network and
is received by other IEDs. Figure 17 illustrates a schematic
diagram of this approach.
Fig. 17. Structure for peer-to-peer communication between transmission system
devices using GOOSE messages.
Of course, variations to this approach can also exist. For
instance, it is possible for the IEDs to have their local
interpreters that receive the GOOSE message and based on
the information available locally make a decision. This
scheme removes the need for having a centralized processor,
but at the same time places more computational burden and
requires data for local calculations.
VII. SUMMARY
Standard protocols were adopted by the industry to pave
the way for efficient substation automation systems. The need
for more platform-independent and interoperable protocols
led to the introduction of IEC 61850 standard for
communication networks and systems in substations, which
was proposed as a future proof and adaptable communication
protocol, capable of providing interoperability in a multi-
vendor environment and with a highly advanced object
oriented modeling approach. In addition to the efforts to
provide an advanced solution for substation automation
systems, there is also a need for extending the “automation”
benefits to beyond the substations. This paper presented an
overview of the legacy protocols used mostly in the North
American markets, as well as an introduction to the
communication networks for substations using IEC 61850 as
the next generation substations. Also, possible future trends
9
for extending the scope of the standard and using its
capabilities for other applications within the distribution
system were discussed.
VIII. REFERENCES
[1] International Communication Standards with regard to Power Automation,
[Online] available at grouper.ieee.org/groups/1525
/CIGRE34.07/Symbols/symbols.ppt
[2] G. Clarke and D. Reynders, Modern SCADA Protocols- DNP3, IEC
60870-5 and Related Systems, Burlington, MA: Elsevier, 2004.
[3] Modbus Application Protocol Specification V1.1b, Modbus-IDA,
December 2006, pp. 1-51, [Online] available at http://www.modbus-
IDA.org.
[4] Modbus Messaging on TCP/IP Implementation Guide V1.0b, Modbus-
IDA, October 2006, pp. 1-45, [Online] available at http://www.modbus-
IDA.org.
[5] IEC 60870-5- Telecontrol Equipments and Systems- Part 5: Transmission
Protocols, IEC Std. 2002.
[6] K. Curtis, “A DNP3 Protocol Primer,” DNP Users Group, March 2005,
pp. 1-8, [Online] available at http://www.dnp.org.
[7] Technical Report, “Modbus and DNP3 Communication Protocols,”
Triangle Microworks, Inc, [Online] available at
www.TriangleMicroWorks.com.
[8] IEC 61850- Communication Networks and Systems in Substations, IEC
Std. 2003.
[9] R. E. Mackiewicz, “Overview of IEC 61850 and Benefits,” in Proc. IEEE
PSCE, Oct./Nov. 2006, pp. 623-630.
[10] K. Schwarz, “Comparison of IEC 60870-5-101/-103/-104, DNP3, and
IEC 60870-6-TASE.2 with IEC 61850,” February 2002, [Online]
available at www.nettedautomation.com.
[11] “The World Market for Substation Automation and Integration Programs
in Electric Utilities: 2005-2007,” Newton-Evans Research, September
2005.
[12] IEC 60870-6- Telecontrol Equipments and Systems- Part 6: Telecontrol
Protocols Compatible with ISO Standards and ITU-T Recommendations,
IEC Std. 2004.
[13] T. Saxton, D. Ambrose, and F. Kendall, “ICCP User Guide,” October
1996, [Online] available at www.sisconet.com/downloads/usrguid5.doc.
[14] D. Becker, “ICCP (TASE.2) Security Enhancement,” EPRI, October
2003, [Online] available at http://www.epriweb.com/public.
[15] A.C. West, SCADA mailing list communication, August 2008.
[16] P. Arons and H. Falk, “Centralized Remedial Action Scheme (C-RAS)
Using Emerging Telecommunication, Protection Technologies, and OSIsoft
PI,” presented at i-PCGRID workshop, San Francisco, CA, March 2008.
IX. BIOGRAPHIES
Salman Mohagheghi (S’99, M’07) received the B.Eng. from University of
Tehran, Iran and M.Sc. from Sharif University of Technology, Tehran, Iran, both
in Power Electrical Engineering in 1998 and 2001 respectively. In 2006 he
graduated with PhD in Electrical Engineering from Georgia Institute of
Technology, Atlanta, GA, USA, where he later joined as a Postdoctoral Fellow.
He is currently a Senior R&D Engineer at ABB Inc, US Corporate Research
Center, Raleigh, NC, USA. His current research focuses on communication
networks in power systems, Smart Grid applications and distribution
automation.
James Stoupis (M’91) is a Principal Consulting R&D Engineer in the
Power Technologies Department for ABB’s US Corporate Research Center
located in Raleigh, North Carolina. Jim has been employed at USCRC for 12
years, and his research has been focused in the areas of distribution and feeder
automation, wireless communications, power system protection and control, and
event detection and classification. Jim holds a BSEE from the University of
Illinois at Urbana-Champaign and an MSEE from Virginia Tech.
Zhenyuan Wang (M’2000) joined ABB Corporate Research in Raleigh,
North Carolina in 2000, where he is currently a Principal Consulting R&D
Engineer. His research interests include electric power equipment condition
monitoring/assessment/diagnosis, system monitoring, control and automation for
a smart grid. His experiences include asset management IT applications in the
electric power industry, power system transient analysis, substation/distribution
automation, and data integration/warehousing/mining applications.