Communications Basics and Use in Electric Utility Systems

INTRODUCTION

With the recent advent of electric utility automation systems and multifunction digital relays
communications issues have taken on a more important role for both vendors and utilities.
Even the most basic Intelligent Electronic Devices (IEDs) are measuring and calculating
dozens of analog and binary values, and settings add hundreds more parameters to the
equation. IED communications capabilities allow all of this data, some of which is crucial to
the safe and efficient operation of electric utility power plants and substations, to be dis-
seminated to the other IEDs where the information can be used in protecting, monitoring
and controlling of the generation, transmission and distribution of electrical power.

This paper will discuss, in tutorial format, communication basics, several protocols that
have been used for protection, control and monitoring and will look at the future and the
standards efforts that currently are underway to develop better means of transporting the
valuable information residing in IEDs. It is hoped that the reader will gain a basic under-
standing of communication protocols, will better understand the trade-offs involved in
selecting protocols, and will be better able to determine which protocols meet the require-
ments of their specific application.

COMMUNICATION PRINCIPLES

Communications is the ability of a device to receive and/or transmit information about its
settings, I/O, metered values, etc. to another entity which has need of the data. The entity
can be either another IED, such as a PLC (Programmable Logic Controller), RTU (Remote
Terminal Unit) or Protective Relay, or a human.

The “human communication interface” is accomplished through the IED’s front panel
keypad, LCD display and targets. The “protocol” used to interact in this manner with a
given device is described in the device’s instruction manual.

In order for two IEDs to effectively communicate they must follow certain rules regarding
when messages can be sent, what the messages contain and how to handle errors. These
rules form a “protocol” that will be covered more thoroughly in another section of the
paper. The communication protocol is typically described in a standards document, and
the IED implementation of the standard, such as ModbusTM, is described in a separate
protocol instruction manual for the device.

This section deals with the basics of communications: interfaces, communication param-
eters and asynchronous communications. Synchronous communications, while not widely
used at the IED level, is covered for comparison purposes.

1
A. Parallel vs. Serial Interfaces

There are two basic digital communication interfaces, parallel and serial. In parallel com-
munications, the bits (typically eight) that make up the device word are sent each on their
own media with media also used for control signals and ground. A good example of paral-
lel communications is the PC parallel port which typically communicates to a dot matrix or
laser printer. The biggest advantage for parallel communications is speed: all eight bits in a
byte, for instance, are delivered at the same time whereas a serial device would send and
receive one bit at a time. The biggest disadvantage of parallel communications is cost - it’s
very expensive to buy and install parallel cabling. Distances for parallel cabling also is
limited to less than a dozen feet (typically).

To overcome the shortcomings of parallel communications between computers the serial

interface was developed. Instead of sending eight bits simultaneously, the bits are sent
over the same media one at a time. Since computers are parallel beasts in nature a device
was needed to take the computer’s parallel information and convert it to a serial data
stream. This device is found in most common desktop and laptop computers as well as
protective relays and is the Universal Asynchronous Receiver/Transmitter (UART).

The main characteristic of the UART is that it takes a parallel data input and clocks it out
serially Least Significant Bit (LSB) first. The UART uses asynchronous frame formatting to
send data, a Universal Synchronous/Asynchronous Receiver/Transmitter (USART) also can
send synchronized data.

B. Synchronous and Asynchronous Serial Communications

Briefly, synchronous communications requires more than transmit data and receive data. It
also needs a synchronizing clock sent with the data. The synchronizing clock can take one
of two forms: either separate receive and transmit clock signals or the clocking can be built
into the data stream by encoding techniques. One encoding scheme uses Manchester
coding where there is always a transition in the middle of a bit period. The transition is
high-to-low for a “one” and low-to-high for a “zero.” This transition is typically input to a
phase lock loop which constructs the clock from the transitions in the data stream.

For asynchronous communications, each communicating device on a network has to have

the same values for each of the following communications parameters: Speed (BPS - Bits
Per Second), Parity, Number of Stop bits, Number of Data bits and transmission mode. The
Speed determines how often the incoming data is sampled while the start bit and stop
bit(s) frame the data. The data is usually eight bits in length (although ASCII uses only
seven of these).

The stop bit is used to test for the end of a data byte, while the parity can be odd, even or
none. Valid stop bit parameter values are 1, 1.5 and 2, but 1.5 is rarely, if ever used.

Parity is an error check that is performed on a single data byte. Even parity is calculated so
that the sum of all the binary “1s” in the data byte plus the parity bit is even; odd parity is
calculated such that the sum of all the binary “1s” in the data byte plus the parity bit is odd.

2
For instance, the ASCII (American Standard Code for Information Interchange)
character “1” is 00110001 in binary, with three binary “1s.” If even parity were used on this
data byte the parity bit would be set to “1,” for odd parity the parity bit would be “0.”

Transmission mode determines when the IED is able to send data. Full Duplex, used for
point-to-point connections, allows data to be sent and received by both connected devices
simultaneously. Half Duplex, on the other hand, is typically used in multi-dropped networks
where a single channel is used for both transmit and receive, and information can be sent
in only one direction at a time. For example, when a master polls a slave or a slave re-
sponds. Finally, there is Simplex, which only allows data transmission in one direction - not
very useful for master/slave polling!

Figure 1 shows a typical asynchronous data frame for the ASCII “1” character with commu-
nication parameters set to one stop bit, even parity.

Figure 1: Asynchronous Data Frame for ASCII “1”

As can be seen for even parity the parity bit is set to one in this instance since the number
of “1” bits in the data word is odd (3). If the receiving UART received the parity bit as “0”,
instead of the calculated “1” in our example, it would have generated a parity error for its
microprocessor to read. Likewise, if the stop bit position (bit 11 in our example) were
received as a “0” the UART would generate a framing error. The UART handles adding
start, stop and parity to outgoing messages, and the stripping of these bits from incoming
messages.

You might ask how the data is sampled if there is no separate clock or clock encoded in
the data stream. For asynchronous communications to work properly all devices on a
given network must be set to the same speed, and they must contain stable clocks from
which the sampling times can be generated. To sample an incoming data stream the UART
uses a sampling clock sixteen times (16x) the baud rate.

Baud rate is often used interchangeably with BPS, when in fact they are, or can be, differ-
ent. Baud rate is the basic signalling rate used to transfer information, while BPS is the
actual number of bits being transferred per second. These two values are identical for
devices that are directly connected, but BPS is higher when a modem is in the picture. The
Plain Old Telephone System -POTS- has a bandwidth that goes up to 3000 Hertz- good
enough for voice communications but not high speed digital communications. Modems
use modulation techniques to overcome POTS limitations and demodulate the received
signal, hence the name modem. For example, the modem could use a baud or signalling
rate of 2400 and, if each signal had four possible amplitudes, each signal period could
represent two bits of information. So, while the baud rate of the modem is 2400 it can
actually transfer 4800 BPS in our example! Don’t be too concerned about making mistakes
when referring to these two values; people who make their living in the communications
world often use the two terms interchangeably!
3
Using a 16x sampling clock on our example in the figure above, the data is continuously
sampled until the leading edge (high-to-low) transition of the start bit is detected. The
UART then checks again halfway through, or 8 sample clock ticks, the start bit to see if it
was indeed a start bit (still low) and not a noise spike. If a valid start bit was received (it
was still low during the second sampling), then the data is sampled every 16 sample clock
ticks or halfway through each successive bit period. Remember, the last check on the start
bit was halfway through its bit time! The start bit is actually used to synchronize the recep-
tion of the data frame, while the stop bit ensures that the line returns to a state where the
next start bit’s leading edge can be detected.

Since the communicating devices all have their own baud rate and sampling clocks there
is the possibility that the clocks aren’t exactly the same and may drift differently over time
and temperature. Because of this, asynchronous serial communications use relatively
short, less than 255 bytes, message lengths to keep the samples as close to the center of
each bit period as possible. At higher baud rates, such as 56K and 112K, the UART sam-
pling decreases to only 2x or 4x the baud rate and thus increases the chance for false
sampling so asynchronous serial communications is typically relegated to 38.4K baud or
less. (There are always exceptions to every generality; Profibus uses asynchronous com-
munications to send short messages, but the baud rate can vary from 9600 all the way to
12M BPS!)

Protocols that make use of asynchronous serial communications include Modbus™, DNP
3.0, IEC 870-5-101 and 870-5-103, MMS/Ethernet, and Profibus. All of these protocols will
be discussed later, but here we’ll briefly talk about the number of bits in a frame because
they directly relate to the use of modems.

DNP uses 10-bit frames (start bit, 8-bit data and stop bit); Modbus™ can use 10-bit or 11-
bit (with optional parity). Several of the European developed protocols such as the IEC
870-series and Profibus use 11-bit data framing only (start, 8 data, parity and stop bits).
Most Hayes-compatible modems will not support 11-bit data and therefore modems need
to be carefully selected when used with these protocols. Several modems from Motorola
and Codex support 11-bit data frames and there may be others, but standard Hayes-
compatible modems will only support parity with seven data bits.

C. Data Encoding

There are two formats in which IED data can be encoded: Binary and ASCII

ASCII stands for American Standard Code for Information Interchange. It consists of a set
of codes used to represent letters, numbers, control characters, and a few symbols. It was
originally designed for teletype systems and is widely used in computers. The seven-bit
binary number set has 128 codes. IBM increased the number of characters to 256 (the IBM
extended-ASCII set) by using eight-bit codes. ASCII data is useful for communicating with
off-the-shelf terminal emulation packages such as ProComm Plus® οr Windows® Terminal.
These programs recognize these standard codes so data to be sent and displayed is
easily viewed in human readable form.

4
With binary coding, the meaning of the data is dependent upon the protocol. Therefore, it
requires “custom” software that has the driver support necessary to communicate using
the protocol, for instance DNP 3.0, implemented in the IED.

Which is the best encoding method for data? Most of the protocols in use today, use
binary encoding. What are some of the reasons ASCII has not become the protocol of
choice throughout the industry?

ASCII encoding is very inefficient in terms of the number of “bits on the wire” needed to
send information, often taking at least twice as many bytes to send the same information
as a binary encoded method. For instance, a relay may contain a value of 36,000 Amps for
Phase A. This could be sent as a 16-bit (two byte) integer using binary with the value 8CA0
hex while the same number using ASCII encoding would take five bytes (one for each
character). Instead of sending the hex number 8CA0, you would have to send the hex
number 3336303030. At 9600 baud every byte takes about one millisecond to transmit, so
if throughput and speed are major concerns in your application you should narrow your
protocol selection candidates to those that are non-ASCII based.

Most ASCII-based protocols also are not very robust, often using parity as the only error
detection. Binary protocols, however, use combinations of parity and checksums or more
sophisticated Cyclic Redundancy Checks (CRCs) for error detection.

As a result, while many US relay vendors provide ASCII based communication for simplic-
ity and convenience to their customers, they are offering more and more SCADA-type
binary protocols such as Modbus™ and DNP 3.0 for applications where customers want
to continuously poll data from a number of IEDs over a multi-dropped network with limited
bandwidth.

D. Error Detection

Most communication protocols offer some form of error detection. There are three com-
mon error detection schemes that are widely used either alone or in combination with
another. These are parity, checksum and CRC.

Parity, as previously mentioned, is used on the individual data frames sent by the UART.
Parity is good at detecting all odd bit errors; referring to Figure 1, if one, three, five or
seven bits became flipped ( a “1” became a “0” or a “0” became a “1” due to noise) the
parity check would fail. However, if an even number of bits became flipped the parity check
would still be valid! For this reason, most protocols that use parity also include a
checksum.

A checksum is typically an eight-bit element that is the “modulo 256” sum of all of the
individual data words (bytes) in the message being transmitted that is appended to the
message by the transmitting IED. (All “modulo 256” means here is that the checksum just
reflects the lower eight bits of the total sum of all the data bytes.) The receiving IED would
then calculate the checksum of all the bytes in the incoming message, excluding the
checksum byte, and compare its result with the received checksum byte. If the calculated

5
and received checksums do not match, the IED will use whatever error condition rules the
protocol in use provides to notify the sender that an error has occurred.

The protocols Modbus RTU, IEC 870-5-101 and 870-5-103, and Profibus all use
checksums in combination with parity. With Modbus™ the parity may be disabled.

Cyclic Redundancy Check (CRC) is the most sophisticated error detecting scheme of the
three and can be quite computational or memory intensive depending on how it is imple-
mented. The usual CRC uses a 16-bit generating polynomial, which is divided into the
message field. The remainder of this operation is appended to the message as the CRC.
The receiving IED would use the generating polynomial to divide the received message,
including CRC field, and the remainder should be zero. The CRC-16 is able to detect 100%
of all burst errors below and including 16 bits in length, and more than 99% of all error
bursts greater that 16 bits in length. Both Ethernet and DNP 3.0 use CRC for error detec-
tion.

E. Physical Interfaces and Connections

There are a number of interface standards being used in today’s IEDs; the two most popu-
lar are RS-232 and RS-485 with fiber optics gaining in popularity. This section will discuss
these standards and also look at the different connectors vendors use.

RS-232

RS-232 is a widely-used standard that defines the electrical signals and connector for a
serial interface. RS-232 drivers provide level shifting and inversion of the UART signals. For
instance, the data format shown in Figure 1 would be seen on the RS-232 transmit data
(TXD) pin as some negative voltage (between -5 and -15 volts) for a logical “1” and some
positive voltage (between +5 and +15 volts) for a logical “0.” The wide ranges in output
voltages at each logical level take into account loading. The threshold of the RS-232 re-
ceivers is -3 volts for a logical “1” and +3 volts for a logical “0.” The differences between
the minimum transmitter outputs and receiver inputs provides a noise margin of two volts
for each logical level. A couple of drawbacks with the RS-232 are the limited distances
(typically 25 ft.) and the reliance on ground as a reference for the signals.

The RS-232 standard calls for a 25-pin D-style connector with signal names assigned to
reflect the flow in and out the Data Terminal Equipment (DTE) connector. For instance,
Transmit Data (TXD) is pin 2 (of the connector) and on the DTE side of an RS-232 intercon-
nection the TXD signal is out of the connector and on the Data Circuit-Terminating Equip-
ment (DCE) side of the interface TXD is into the connector!

Most PC serial ports hooked up to external modems make use of only 9 of the 25 pins of a
RS-232 connector. These signals are : Data Carrier Detect (DCD), Receive Data (RXD),
Transmit Data (TXD), Data Terminal Ready (DTR), Ground (GND), Data Set Ready (DSR),
Request to Send (RTS), Clear to Send (CTS) and Ring Indicator (RI). In the early 1980s
IBM began the era of the 9-pin D-sub connector with its inclusion as a serial port interface
on the IBM PC AT.

6
Not all of these signals are required to establish communications through an RS-232 serial
port. For devices that do not use any form of hardware flow control, only the RXD, TXD, &
GND are required between the two ports being tied together. The flow control signals are
fooled with jumpers connected in the connector. This allows some IEDs to use the unused
pins for other purposes such as powering external devices or for connecting to other
completely unrelated signals.

To determine what type of cable is required to interconnect two RS-232 ports, you need to
know four parameters for each port.

1. Type (DTE or DCE)?

2. Gender (male or female)?
3. Socket (9 pin or 25 pin)?
4. Does it include all nine signals?

A cable that connects a Type DTE (data terminal equipment) to a DCE (data circuit termi-
nating equipment, AKA data communications equipment) requires what is called a
"straight through" cable. A cable that connects a DTE port to another DTE port, or a DCE
port to another DCE port requires what is called a "null modem" cable. The null modem
cable swaps the position of the various complementary signal pairs such as RXD/TXD and
CTS/RTS from one end of the cable to the other. One way to remember which is which is
that a PC is used as a terminal so it has a DTE type port. A modem is used for communica-
tions so it has a DCE type port.

IEDs can have either type port, as well as, either gender or socket. If the port on the IED
includes all nine of the standard signals, a standard, off the shelf straight or null cable with
the correct socket connectors and genders can be used. If it does not, a special cable may
be required. You need to consult the manufacturer’s instruction manual to determine this.

RS-485

Like RS-232, RS-485 defines the electrical interface and signal levels but does not define a
physical connector. RS-485 is a balanced two-wire interface that uses differences between
the two signals to determine if the signal is a logic “1” or a logic “0.” There is no ground
reference involved. RS-485 allows up to 32 transceivers (transmitter/receiver pairs) to be
multi-dropped together on one network, more can be networked together with the use of
repeaters.

RS-485 is typically used in a master/slave or polled network scheme where one master will
poll the slave IEDs on the network. All slaves by default will have their transmitters disabled
and receivers enabled so they can listen to requests from the master. When a slave re-
ceives a request from the master it will formulate a response, turn on its transmitter, send
the response and then disable the transmitter thus returning to the listen mode.

7
 Figure 2: RS-485 Interface

Figure 2 is a representation of two devices on an RS-485 connection, with the single wire
into the Transmitters (T) and out of the Receivers (R) representing the interfaces to our
trusty UART device. When the UART transmits a logical “0” for a start bit, the A wire will be
negative with respect to the B wire. Outputting a logical “1” will result in the A wire being
more positive than the B wire. At the receive end, the A wire being more negative than the
B wire will result in a logical “0” from the receiver.

The RS-485 transmitters are capable of providing a minimum output voltage of 1.5 volts
into a 54 ohm load, while the receiver threshold is 200 millivolts. Network lengths of up to
1,000 feet at 1M BPS is possible, with a maximum recommended length of 4,000 feet at
9,600 BPS.

Unfortunately, because the RS-485 standard does not define a connector standard there is
no industry agreement as to which connector to use. Some vendors will use a 9-pin D-sub
connector, others use screw terminals and still others use a Phoenix connector.

Fiber Optics

Fiber interfaces are fairly immune to noise sources and ground loops that can cause inter-
ference in copper-based networks. The fiber can be either glass or plastic, with plastic
offering cost savings at the expense of overall network length, 40 meters for plastic and
1000 meters for glass.

F. Topologies

Several network topologies, such as point-to-point, star, ring and bus, can be used to
interconnect IEDs.

Star Topology

A star network has the master station or hub at the center and a point-to-point interconnect
to each slave IED radiating outwards. (The point-to-point topology is just a star network

8
with the hub or master connected to only one slave.) The major attraction of the star topol-
ogy is that each communication interface in the hub/master can have its own UART thus
allowing each slave device to be polled individually and simultaneously.

Figure 3: Star Topology

The two biggest drawbacks to this scheme have to do with cost: the extra hardware in the
hub is expensive and separate media has to be installed for each IED - even if the IEDs
are side-by-side! Another disadvantage is that IEDs that may have information to share
with other IEDs must do so through the hub, which delays message delivery. Finally, the
hub/master is a single point of failure whereby if the hub fails all communications is lost.

Two examples of equipment that use the star topology would be the RFL 9660 switch and
the SEL 2020 communication processor. RS-232 interfaces are good choices in these
point-to-point connections when the distances from the hub to the IEDs are relatively short.

Bus Topology

Most LANs in use today use a bus topology where all devices share the same linear me-
dia. IEDs are typically multi-dropped or daisy-chained forming a single bus such that when
an IED sends a message all of the other devices can hear it at the same time. The big
advantage here is cost because a single UART in the master can communicate to all of the
IEDs via one media shared by all. A disadvantage is the fact that the master must poll all of
the IEDs on the bus and the more IEDs the longer it takes to scan all the devices.

Figure 4: Bus Topology

9
Oftentimes when certain time constraints cannot be met by having all IEDs on the same
bus, a master can be configured for multiple buses, sort of a combination star/bus topol-
ogy. Each bus would then have just enough IEDs connected so that the polling time would
meet system requirements.

RS-485 is typically used for the physical interface in the bus topology for protocols such as
Modbus™ and Profibus.

Ring Topology

The ring topology can be envisioned as a large circle or loop, with the circle passing
through each device. This configuration is normally reserved for token-based networks
where the token is passed on to the next device in the loop. If that device has something to
say it grabs or “holds” the token until it has sent its messages, then passes the token to
the next device in the ring.

Figure 5: Ring Toplogy

Since the ring media is not continual but requires the device to route the token, a single
IED failure could bring down the whole ring. Because of this problem a lot of rings are
redundant such that if a device goes bad there is an alternate path.

G. Network Access

Protocols differ in how they control access to the communications network. There are two
basic frameworks: master-slave and peer to peer.

Master-Slave Networks

Most of the common protocols that we are familiar with in the power system industry today
are master-slave. The traffic on the network is controlled by the master and only one is
allowed on the network. The master polls (requests data) from each slave on the network
one at a time. After each slave responds, the next slave is polled. Examples of this are a
SCADA system with a master computer at the system control center; or, a substation LAN
with a data concentrator or smart RTU requesting data from IED’s and collecting it for
forwarding to another system.

10
This has the advantage that it is simple; however, it can be slow and inefficient. Each slave
cannot initiate communication when it has data to send. Therefore, the master must poll at
a fairly regular interval if the information is to be kept current. Much of the information
being sent is redundant.

Some protocols such as IEC 870-5 can mitigate this disadvantage by supporting report by
exception. With report by exception, data is not sent to the master unless the IED has
something new to report. For example, if the master requests report by exception data, the
value of only those analog data points that have changed by a certain percent from the
value that was previously reported are sent. Periodically, the master will request to refresh
all data, but most times the data being sent is much less.

Peer-to-Peer Networks

What are peer-to-peer protocol networks? In a peer-to-peer communications network all

devices have the ability to access the network for transmitting data without having to rely
on another device to grant permission. For a peer-to-peer protocol there is no primary
station controlling access to the network. All devices have equal ability to transmit if they
have the same priority. Peer-to-peer protocols are typically used in LANs with bus, mesh,
and ring topologies.

There are two primary mechanisms used for network access control in peer-based LANs:
Carrier Sense Multiple Access / Collision Detect (CSMA/CD) and Token Passing. (Many
variations of these two methods have evolved over the years, but will not be covered here.)

The CSMA/CD approach is used in several implementations, must notably Ethernet and
IEEE 802.3/ISO 8802. In CSMA/CD a device listens to the network, and if the network is
idle, it begins to transmit its data while continuing to monitor the network. If a collision is
detected, both devices sending data must stop and wait some random time and again
check for an idle network before reattempting transmission.

One drawback of the CSMA/CD mechanism is that collisions occur and must be detected.
There is a collision window based on the propagation delay of the signal and the distance
from the farthest device on the network. A message transmission must have a duration at
least twice the collision window in order for a collision to be successfully detected. For this
reason CSMA/CD networks are usually implemented on short distance LANs; longer LANs
would result in the need for longer messages and the opportunity for more collisions.
Because of this possibility of collisions, CSMA/CD networks are considered
nondeterministic, that is, the timing of data transfers cannot be determined nor guaranteed
and degrades rapidly as the number of devices increases.

Ethernet is an example of a transport layer that uses CSMA/CD to control access to a peer
to peer network. The transport layer is the one that controls access to the physical commu-
nications media. The next section will describe the layers of a protocol stack.

11
Token Passing networks do not suffer from collisions and are said to be deterministic. In
Token Passing schemes, at least for a basic model, a token is sent over the network and a
device with data ready to send will hold the token, send messages, and then send the
token for the next device to use. Variations on this mechanism allow for priority to be as-
signed to the token and devices, and for the token to be passed on to the next device in
the addressing hierarchy so that each device has its turn to broadcast. Token Passing
networks give up some time, called the token rotation time, in sending the token to all
devices and this time cannot be used for message passing. The more devices in a network
that can utilize the token, the higher the amount of time that will be needed to pass the
token.

Modbus Plus, and Profibus are examples of protocols that use token passing for access to
the peer to peer network.

THE OSI REFERENCE MODEL AND PROTOCOLS

As mentioned earlier, a protocol is a set of rules that govern how devices communicate
with each other. Most protocols follow the Open System Interconnect (OSI) Reference
Model, which the Organization for International Standards (ISO) developed primarily as a
description of wide area networking over long distances.

In this section we will describe the OSI Reference Model, what each layer does and also
describe the three levels of conformance that can be achieved between communicating
devices.

A. The OSI Reference Model

The OSI reference model abstracts the communications architecture into seven distinct
layers. Each layer provides services to the layer above and utilizes services of the layer
below. Figure 6 depicts the OSI reference model.

12
 Figure 6: The OSI Reference Model

As can be seen the layers are stacked, one atop the other, and hence a communications
architecture is commonly referred to as a communication stack. Each layer, while providing
services to the layer above and using services of the layer below, also carries on a peer-to-
peer conversation with its counterpart in the other device’s stack. As a message traverses
the protocol stack from the topmost layer down to the next to last layer each layer will add
its own control information that will be utilized by the peer layer at the receiving end. There-
fore, each layer that is defined and included in a protocol standard must be implemented
by all devices using that standard in order for the devices to properly communicate. What
are all seven layers used for?

Starting at the bottom, the Physical layer (layer 1) provides the means to place the data on
the media as well as definitions for electrical characteristics, connectors and wiring. We’ve
already seen examples of this layer: RS-232 and RS-485.

Layer 2 is the Data Link layer, which is basically responsible for packaging the message
into packets or frames for transmission over the wire, error detection and controls access
to the media. Because of its importance and large set of tasks the Data Link layer is often
abstracted into two sub-layers: Link Control and Media Access Control. Some examples
are High-level Data Link Control (HDLC), Logical Link Control (LLC), Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) and Token Bus (IEEE 802.4).
13
The Network layer is next. It routes the message by determining the best route to take
through the network. The Network layer accepts the message from the layer above and
routes it over as many links and intermediate systems as is necessary to reach its destina-
tion. To do this, the Network layer uses knowledge about the network topologies in order
to find the proper route to the destination. The most common Network protocol is Internet
Protocol (the IP in TCP/IP).

The Transport layer (layer 4) is responsible for handling communications between sender
and receiver despite problems that may occur at lower layers. The Transport layer ensures
reliable delivery of messages regardless of the Network layer being used, and maps mes-
sages into several smaller packets should the Data Link not handle messages as large as
those supported by the upper layers. The receiving Transport layer will reassemble the
data packets into the message required by its upper layers. Transmission Control Protocol
(the TCP in TCP/IP) is widely used at the Transport layer.

Next up the stack is the Session layer (layer 5), which functions to establish connections
between communicating partners. It also is concerned with basics such as message
transmission mode (i.e., half-duplex or full-duplex as described earlier). It also continually
checks to see if a connection is still valid pretty much the same way a person listening to
someone on the phone will say “uh-huh” to let the speaker know that there is still a lis-
tener!

The Presentation layer (layer 6) is next. The Presentation layer formats the message infor-
mation so that it is understood by the next layer up by resolving any syntax differences. For
instance Intel processors send 16-bit information differently from the way Motorola proces-
sors do. In order for the Intel-based IED to properly interpret the data, the incoming byte
order must be swapped and the same must take place at the Motorola-based IED. The
Abstract Syntax Notation (ASN.1) is typically used in this layer.

Finally, at the top of the stack we have the Application layer (layer 7), which is responsible
for providing an interface between the user programs and the communications architec-
ture. For users, the Application layer is the key layer in the model - all services and data
formats that can be used directly by the application processes must be provided at this
level. Examples of Application layer implementations include Manufacturing Message
Specification (MMS), Fieldbus Message Specification (FMS) and the File Transfer, Access
and Management specification (FTAM). Figure 7 depicts the OSI model application inter-
face.

14
 Figure 7: OSI Application Interface

Do all devices have to include all seven layers in their communication architecture or
stacks? The short answer is, "No!" Figure 8 compares the OSI reference model with the 3-
layer model developed for use in real-time control applications.

15
 Figure 8: 7-layer and 3-layer OSI reference models

In most real-time applications the communications stack can be shortened to a 3-layer

stack, which is often referred to as an Enhanced Performance Architecture (EPA) stack.
The EPA stack utilizes the services of layers 1, 2 and 7 due to the nature and architecture
of real-time automation systems. Figure 9 shows a typical automation functional architec-
ture where the EPA stack meets the requirements of a real-time automation system. (The
numbers in circles refer to functional communications interfaces that may or may not result
in separate physical interfaces.)

7a,b,c

Station
Unit

1 6 1 6
3 3
P C P C

4 5 4 5
VT Sw. VT Sw.
CT gear CT gear

Figure 9: Typical Automation Functional Architecture

16
Here, all of the IEDs (labeled P for Protection and C for Control) can send data to and
receive requests from the master. Since the master (labeled Station Unit in Figure 9)
handles all communications with the system outside the facility, via the two interfaces on
top, the IEDs have no need of the Network (layer 3) and Transport (layer 4) for internetwork
routing. The session layer functionality is not required because the devices are on a dedi-
cated link to the station unit so connections are always available. Finally, any functionality
required from the Presentation layer can be handled inside the Application layer. As can be
gathered from the EPA acronym, the 3-layer stack is more efficient, performance-wise,
because it cuts out all of the control decisions that would normally take place in the inter-
mediate layers between the Data Link and Application layers.

B. Interconnectivity, Interoperability and Interchangeability

There are three levels of compatibility that may be achieved between communicating
devices: interconnectivity, interoperability and interchangeability. For all of its complexity
the communications stack described above will only provide interconnectivity, that is the
ability to transmit and receive data of known type such as byte, character, float, etc. But
what does the byte, character or float represent?

To share knowledge of what each data element or register means, each device must have
specific application (sometimes referred to as domain) knowledge of the other devices.
When devices have such knowledge they are then able to interoperate. This knowledge
can come from a couple of sources. It can be found in a manual, which means someone
must program the station unit to understand that, for example, a Basler relay with the
Modbus RTU protocol has Phase A, B and C Amps in registers 44001 - 44003 with values
in centiamps. If this information were available in the relay and could be obtained over the
communication stack, then the product would be able to interoperate with other devices
with similar capabilities. It would then be a simple case of querying the device from the
station unit to find out what data and functionality the device was capable of, and mapping
this into the system being developed. The User layer, depicted in Figure 6, supplies the
information necessary to achieve interoperability.

The third, and highest, level of compatibility is interchangeability. For two devices to be
interchangeable they would have to support interoperability plus be functionally equivalent
in the application process functions they supported such as overcurrent relaying and
reclosing.

17
 Figure 10: Detailed block diagram of an IED communicating
to the process and to the station unit

The figure above depicts a block diagram of an IED with its communications and process
interfaces. The device can be viewed as having two distinct systems: Communication and
Application. Interconnectivity can be achieved if all IEDs have the same communication
system. Interoperability is added if all devices make the User layer available with a com-
mon device description language to interpret the information. Finally, if two devices overlap
both in the communication system and the application system then they would be inter-
changeable at the system level.

C. Protocols in Use Today

This section takes a look at some of the more popular IED protocols, all of which use the 3-
layer EPA stack. The first two, DNP 3.0 and IEC 870-5-101 are included in the IEEE P-1379
Trial Use Recommended Practice for Data Exchange between RTUs and IEDs.

18
DNP 3.0

Distributed Network Protocol (DNP) V3.00 is the result of significant effort on the part of
Harris, formerly Westronics, to define a protocol that could be used openly by vendors of
RTUs and IEDs. While defined as IEC 870-5 compliant, this protocol was developed and
completed before all of the IEC 870-5 series of protocol standard documents had been
finalized.

From the frame formats as defined in IEC 870-5-1, Harris selected FT3, but then added start
and stop bits to every octet, thus negating the Hamming Distance of 6 supplied by using
the original, synchronous frame format. For error detection, FT3 uses a 16-bit CRC for every
16-byte block in the frame. (Hamming Distance is the number of bits that must be in error
for the message to look like another valid message.)

For file transfer operations Harris developed a pseudo-transport layer and placed it in the
data link layer. This pseudo-transport layer fragments messages that are too large for the
data link frame upon transmission and concatenates incoming frames that are part of the
same message. This pseudo-transport layer is not part of the IEC 870-5-5, which describes
an application (not application layer) function to handle file transfers. (However, to be fair,
IEC 870-5-5 did not define file transfers when DNP 3.0 was being developed and Harris
added the capability where the functionality made the most sense.)

DNP 3.0 follows the guidelines laid out in IEC 870-5, sections 4 and 5, for defining informa-
tion elements (IEs, called Data Objects in DNP) and Application Service Data Units
(ASDUs) but defines data objects and ASDUs that have additions not in the base docu-
ment.

The DNP 3.0 is defined in a series of four documents, with additional documents describ-
ing subsets of DNP for specific implementations such as RTU to master, or IED.

While a lot of time and effort have been expended on documentation the protocol is still
fairly open to interpretation and non-intuitive in the use of data objects. For instance, if a
voltage regulator controller IED has a 32-bit counter object that represents the total opera-
tions of a voltage regulator, there is a need to be able to set the counter to the present
operations count of the voltage regulator when a new IED is installed. Unfortunately DNP
counters cannot have values written to them and must therefore be implemented as 32-bit
analog outputs!

Also, an IED passing factory acceptance tests at an RTU vendor’s facility may not pass the
same testing at another RTU vendor because each vendor implemented the protocol differ-
ently. In order to eliminate these ambiguities there needs to be a mechanism for conform-
ance testing after the documentation has been rewritten for clarity.

Once DNP 3.0 is implemented properly it accomplishes everything Harris set out to do. It’s
an open, fairly robust protocol available to all vendors and makes an excellent short-term
solution until the current standard efforts are complete and proven.

19
The protocol is being maintained by the DNP Users Group, a nonprofit organization that is
open to utilities and vendors alike for a nominal fee. The Users Group is currently address-
ing the shortcomings mentioned in this section.

IEC 870-5-101

The IEC 870-5-101 (T101) protocol profile was developed after the five IEC 870-5 base
documents were completed, and was defined by the same working group (IEC TC57
WG03), therefore T101 is fully compliant with the international standards.

The T101 frame format is FT1.2 with a guaranteed Hamming Distance of 4 using parity on
each octet and an 8-bit checksum for the frame. Along with the parity bit each octet in-
cludes a start and stop bit for a total of 11-bits transmitted and received for every 8 data
bits. This 11-bit octet is not widely supported by PC modem vendors such as Hayes and,
therefore the utility must use modems from a select list of vendors such as Motorola.

T101 provides the following application functionality within the user layer software (not the
protocol application layer):
• Station initialization
• Data acquisition by polling
• Cyclic data transmission
• Acquisition of events
• General interrogation
• Clock synchronization
• Command transmission
• Transmission of integrated totals
• Parameter loading
• Test procedure

While all of this functionality is provided by the T101 standard, the IED is not required to
implement each function.

There are other protocols that use the same frame format and data link, 870-5-102 for
meters and 870-5-103 for protective relays. In addition, Profibus (to be described later)
uses FT1.2 and data link control as described in 870-5, sections 1 and 2.

IEC 870-5-101 is used primarily for RTU to control center communications, while 870-5-103
is used by ABB, AEG, GEC Alsthom and Siemens as a protective relay informative inter-
face protocol. (In Spain, they have enhanced T103 even further to include relay control
with the data transfer capabilities.

Just as DNP 3.0 has subset specifications, 101-103 are profiles of 870-5 for use in specific
types of IEDs. IEC 870-5-103 is, however, generic enough to be useful for other IEDs
besides relays.

20
Finally, T101 suffers from some of the same afflictions as DNP 3.0. Namely, there is no
mechanism for providing conformance testing in the US, although in Europe KEMA and
other consultants provide testing for T103. Also, there is the likelihood that two vendors
can implement the protocol two different ways.

Even though IEC 870-5-101 is part of Recommended Practice P-1379 it has never gained
acceptance in the US, either with vendors or utilities. If full IEC 870-5 compliance is desired
then T103, with its generic directory and read/write solutions is a better choice with four
major relay manufacturers in Europe supporting it to date.

Modbus™

The Modbus™ protocol was developed by Modicon for use in their line of Programmable
Logic Controllers (PLCs). There is support for one master and 247 slaves, although the
physical media may restrict the number. RS-485, for instance, limits the number of devices
to 32 on a single twisted pair line.

There are two transmission modes in Modbus™: ASCII and RTU. These modes, while
providing the same capabilities, cannot be mixed for a given Modbus™ system.

The ASCII mode requires twice as many characters (octets) as does the RTU mode to
send the same data, however the handling and decoding of data in ASCII mode is much
simpler. RTU mode message frames must be sent as a continuous stream since it relies on
a three character (octet) idle time to signify the start of a new message. ASCII, on the other
hand, can handle gaps in the message as large as one second in duration, allowing for
slower devices to implement the protocol.

ASCII mode uses a simple LRC (checksum) for error detection, while RTU mode utilizes a
16-bit CRC. Both have the option of an even or odd parity bit per octet. (RTU mode with
parity is restricted as far as the modems that will work because of the 11-bit data. See 870-
5-101.)

Both ASCII and RTU modes operate with various types of data and allow ranges of the
same data type to be read or written. In general, they are both easy to implement and are
well documented and have gained a level of popularity for IED implementation such that
they will be around for a while. Because of its higher frame efficiency, at the cost of more
complex error detection, the RTU mode is recommended.

D. Future Protocol Standards

What separates the future protocol standards from the present crop? First, while today's
protocols are master/slave polling types, the future standards will use interoperable, peer-
to-peer communications to enhance systems development and automation system perfor-
mance.

21
Standards Efforts

Several efforts are currently underway to produce protocol standards for integrated substa-
tion protection, control and monitoring. Two of these efforts are covered within this docu-
ment as communication solutions for substation automation systems of the future.

EPRI in the US has a research project, RP-3599, to specify an open system communication
architecture and protocol requirements for substation applications. The IEC TC57 has
three new working groups, established in May of 1995, defining a series of international
standards, IEC 1850, for Communication Networks and Systems in Substations.

An exciting aspect of these developments is the close cooperation between the groups.
EPRI has been informing the IEC of all work being done in the US, and with US member-
ship on the IEC working groups, the EPRI efforts are being input to the three working
groups. Right now, both EPRI RP-3599 (better known as UCA - Utility Communication
Architecture) and IEC 1850 recognize a common application layer based upon services
provided by either the Manufacturing Message Specification (MMS) and/or the Fieldbus
Message Specification (FMS). (For a subset of each, both MMS and FMS are identical.)

Part of the EPRI RP-3599 research project is a set of field trials starting in 1998 developed
by key electric utilities and vendors. These demonstrations will be used to prove the RP-
3599 specification, and the results along with research work and standards-process re-
views will be used to update the specification where necessary.

The following sections briefly describe the efforts within EPRI and IEC TC57 and some
protocols that appear to meet the criteria being established by the two organizations.

EPRI RP-3599

Research Project RP-3599 is an effort to define an open, interoperable communication

protocol for integrating substation protection, control and data acquisition. This project is
unique in that it is known as the Utility Initiative Project because it is being driven by the
users. This development project is proceeding at a rapid pace and involves more than 15
utilities and more than 15 vendors, with more being added all of the time.

Reviews of the documents being developed are taking place in several standards-related
groups in the IEEE Power Engineering Society covering Protection, Substations and Com-
munications. [2] In addition, Working Groups (10, 11, and 12) of IEC TC 57 are using the
documents as part of the basis for a new series of standards covering communication
networks and systems in substations.

The Requirements Specification uses object-oriented methods to model the power system
in order to capture the essential requirements pertaining to data flow and locality. The
standard being developed uses MMS (Manufacturing Message Specification) for the
application layer. The lower layers will use Ethernet. Both 10 megabit and 100 megabit
Ethernet over either copper and fiber optic media are included in the standard being devel-
oped.

22
The IEEE Power Systems Relaying Committee has two working groups that are coordinat-
ing closely with this effort. H4 is working on a new standard PC37.115 “Standard Test
Method for Use in the Evaluation of Message Communications between Intelligent Elec-
tronic Devices in an Integrated Substation Protection, Control and Data Acquisition Sys-
tem”. H5 is developing scenarios for the application of high speed peer to peer networks
for real time substation protection and control.

IEC 1850 Standards

In November 1993, the IEC TC 57 formed an Ad Hoc Working Group to prepare New Work
Item Proposals (NWIPs) in the field of substation control systems and on interfaces of
protection equipment.

These NWIPs were approved at the IEC TC 57 Plenary in May 1995. One NWIP was to
create profile 870-5-103 (T103) based upon the German VDEW standard. The other three
NWIPs called for the creation of three new Working Groups.

Figure 11: Distributed Control-Protection Scheme

Referring to Figure 11, WG10 is responsible for defining the requirements within the Sta-
tion, Bay and Process levels. WG11 will define the communication protocol standard within
and between Station and Bay levels, and WG12 is responsible for the communication
standard between and within the Bay and Process levels.
23
Both WG11 and WG12 are working on high-speed, peer-to-peer networks that will allow
control to be distributed to whereever in the hierarchy it is needed. The control also can be
done redundantly at a number of levels. With a high-speed LAN at the Process level future
IEDs will be able to communicate (via one connection) to any number of CTs, PTs and
switchgear as other IEDs! This process-level LAN can be confined to one bay (feeder) or
extend across several feeders thus allowing the bay-level IED to incorporate control
schemes previously relegated to station- or enterprise-level devices.

Contributions from the US were the EPRI RP-3599 Requirements Specification to all three
working groups, and the RP-3599 Implementation Agreement to WG11. Both documents
were well received and will be used, along with input from other countries, as the basis for
new international communication standards. There were 47 members in attendance at the
first meeting, which indicates the high level of interest in these standards efforts.

Working Group 11 has formed two Subworking Groups (SG): User Layer and Application
Layer. The User Layer is defining Logical Nodes, VMD, Function Blocks, and Device De-
scriptions; while Application Layer and Messaging (UMS, MMS, and use of FMS) are being
defined by the second SG. The primary basis of the work being done by the Application
Layer SG is the EPRI RP-3599 Implementation Agreement.

SUMMARY

Communications has taken on a more important role in electric utility IEDs and automation
systems, because the data within these devices is invaluable in efficiently and reliably
maintaining the electrical system.

Today's protocols, while allowing data to be polled from IEDs, do not lend themselves to
automation schemes such as adaptive relaying or control.

Future systems will allow interoperability over peer-to-peer networks where IEDs will share
information. The sharing of information at the IED level will allow control processes to
occur closer to the physical equipment, such as transformers, switchgear and breakers.

There is no single standard today, so devices with various protocols need to be integrated
together with interposing hardware and software. Even in a "perfect" future, with a single
protocol, utilities will keep the equipment they have, and expand or update using newer
equipment with the "perfect" protocol. Again, integration of legacy equipment will be nec-
essary. Integration of these different protocols can be accomplished by companies such
as Tasnet, with their Network Interface Modules (NIMs), and Basler Electric’s LaGrangeville
Division’s system featuring multiprotocol architecture.

24