Open Systems Interconnection (OSI) model

A brief summary of the seven layers is as follows:

Application
The provision of network services to the user’s application programs.
Note: the actual application programs do NOT reside here
Presentation
Primarily takes care of data representation (including encryption)
Session
Control of the communications (sessions) between the users
Transport
The management of the communications between the two end systems
Network
Primarily responsible for the routing of messages
Data link
Responsible for assembling and sending a frame of data from one system to
another
Physical
Defines the electrical signals and mechanical connections at the physical level

Application layer
The application layer is the topmost layer in the OSI reference model. This layer is
responsible for giving applications access to the network. Examples of application-layer tasks
include file transfer, electronic mail (e-mail) services, and network management.
Application-layer services are much more varied than the services in lower layers, because
the entire range of application possibilities is available here. Application programs can get
access to the application-layer services in software through application service elements
(ASEs). There is a variety of such application service elements; each designed for a class of
tasks. To accomplish its tasks, the application layer passes program requests and data to the
presentation layer, which is responsible for encoding the application layer’s data in the
appropriate form.
Presentation layer
The presentation layer is responsible for presenting information in a manner suitable for the
applications or users dealing with the information. Functions such as data conversion from
EBCDIC to ASCII (or vice versa), use of special graphics or character sets, data compression
or expansion, and data encryption or decryption are carried out at this layer.
The presentation layer provides services for the application layer above it, and uses the
session layer below it. In practice, the presentation layer rarely appears in pure form, and it is
the least well defined of the OSI layers. Application- or session-layer programs will often
encompass some or all of the presentation layer functions.
Session layer
The session layer is responsible for synchronizing and sequencing the dialogue and packets in
a network connection. This layer is also responsible for making sure that the connection is
maintained until the transmission is complete, and ensuring that appropriate security
measures are taken during a ‘session’ (that is, a connection). The session layer is used by the
presentation layer above it, and uses the transport layer below it.

Transport layer
In the OSI reference model, the transport layer is responsible for providing data transfer at an
agreed-upon level of quality, such as at specified transmission speeds and error rates. To
ensure delivery, outgoing packets are sometimes assigned numbers in sequence. These
numbers are then included in the packets that are transmitted by lower layers. The transport
layer at the receiving end subsequently checks the packet numbers to make sure all have been
delivered and to put the packet contents into the proper sequence for the recipient. The
transport layer provides services for the session layer above it, and uses the network layer
below it to find a route between source and destination. The transport layer is crucial in many
ways, because it sits between the upper layers (which are strongly application-dependent) and
the lower ones (which are network-based).

Network layer
The network layer is the third lowest layer, or the uppermost subnet layer. It is responsible for
the following tasks:
• Determining addresses or translating from hardware to network addresses. These addresses
may be on a local network or they may refer to networks located elsewhere on an
internetwork. One of the functions of the network layer is, in fact, to provide capabilities
needed to communicate on an internetwork
• Finding a route between a source and a destination node or between two intermediate
devices
• Fragmentation of large packets of data into frames which are small enough to be transmitted
by the underlying data link layer (fragmentation). The corresponding network layer at the
receiving node undertakes re-assembly of the packet
Physical layer
The physical layer is the lowest layer in the OSI reference model. This layer gets data packets
from the data link layer above it, and converts the contents of these packets into a series of
electrical signals that represent 0 and 1 values in a digital transmission. These signals are sent
across a transmission medium to the physical layer at the receiving end. At the destination,
the physical layer converts the electrical signals into a series of bit values. These values are
grouped into packets and passed up to the data link layer.

Protocols
As previously mentioned, the OSI model provides a framework within which a
specific protocol may be defined. A protocol, in turn, defines a frame format that
might be made up of various fields as follows.

TCP/IP
A child of the Internet, the transmission control protocol (TCP)/Internet protocol (IP) is also
becoming popular when used in conjunction with Ethernet. It really defines three layers.
• Process/application layer
(equivalent to upper three layers in the OSI model)
• Services layer (host-to-host) layer
(equivalent to the transport layer in the OSI model)
• Internetwork layer
(equivalent to the network layer of the OSI model)
It is a very low cost protocol with wide support due its use on the Internet. Arguably it is an
overkill for some industrial communications applications. However, its low cost and wide
support make it very attractive.
SCADA Protocols
In a SCADA system, the RTU accepts commands to operate control points,
sets analog output levels, and responds to requests. It provides status,
analog and accumulated data to the SCADA master station. The data
representations sent are not identified in any fashion other than by unique
addressing. The addressing is designed to correlate with the SCADA
master station database. The RTU has no knowledge of which unique
parameters it is monitoring in the real world. It simply monitors certain
points and stores the information in a local addressing scheme.
The SCADA master station is the part of the system that should “know”
that the first status point of RTU number 27 is the status of a certain
circuit breaker of a given substation. This represents the predominant
SCADA systems and protocols in use in the utility industry today.
Each protocol consists of two message sets or pairs. One set forms the
master protocol, containing the valid statements for master station
initiation or response, and the other set is the RTU protocol, containing
the valid statements an RTU can initiate and respond to. In most but not
all cases, these pairs can be considered a poll or request for information
or action and a confirming response.
The SCADA protocol between master and RTU forms a viable model for
RTU-to-Intelligent Electronic Device (IED) communications. Currently, in
industry, there are several different protocols in use. The most popular are
International Electrotechnical Commission (IEC) 60870-5 series,
specifically IEC 60870-5-101 (commonly referred to as 101) and
Distributed Network Protocol version 3 (DNP3).

Interoperability and open standards

Immediate benefits
• Interoperability between multi-vendor devices
• Fewer protocols to support in the field
• Reduced software costs
• No protocol translators needed
• Shorter delivery schedules
• Less testing, maintenance and training
• Improved documentation
• Independent conformance testing may be provided

Long-term benefits
• Easy system expansion
• Long product life
• More value-added products from vendors
• Faster adoption of new technology
• Major operations savings

IEC 60870-5-101
IEC 60870-5 specifies a number of frame formats and services that may
be provided at different layers. IEC 60870-5 is based on a three-layer
Enhanced Performance Architecture (EPA) reference model (see Figure
4.1) for efficient implementation within RTUs, meters, relays, and other
Intelligent Electronic Devices (IEDs). Additionally, IEC 60870-5 defines
basic application functionality for a user layer, which is situated between
the Open System Interconnection (OSI) application layer and the
application program. This user layer adds interoperability for such
functions as clock synchronization and file transfers. The following
descriptions provide the basic scope of each of the five documents in the
base IEC 60870-5 telecontrol transmission protocol specification set.
Standard profiles are necessary for uniform application of the IEC 60870-5
standards. A profile is a set of parameters defining the way a device acts.
Such profiles have been and are being created. The 101 profile is
described in detail following the description of the applicable standards.
• IEC 60870-5-1 (1990-02) specifies the basic requirements for services to
be provided by the data link and physical layers for telecontrol
applications. In particular, it specifies standards on coding, formatting,
and synchronizing data frames of variable and fixed lengths that meet
specified data integrity requirements.
• IEC-60870-5-2 (1992-04) offers a selection of link transmission
procedures using a control field and optional address field; the address
field is optional because some point-to-point topologies do not require
either source or destination addressing.
• IEC 60870-5-3 (1992-09) specifies rules for structuring application data
units in transmission frames of telecontrol systems. These rules are
presented as generic standards that may be used to support a great
variety of present and future telecontrol applications. This section of IEC
60870-5 describes the general structure of details about information fields
and their contents.
• IEC 60870-5-4 (1993-08) provides rules for defining information data
elements and a common set of information elements, particularly digital
and analog process variables that are frequently used in telecontrol
applications.
• IEC 60870-5-5 (1995-06) defines basic application functions that
perform standard procedures for telecontrol systems, which are
procedures that reside beyond layer 7 (application layer) of the ISO
reference model. These utilize standard services of the application layer.
The specifications in IEC 60870-5-5 (1995-06) serve as basic standards for
application profiles that are then created in detail for specific telecontrol
tasks. The Standard 101 Profile utilizes the following basic application
functions, defined in IEC 60870-5-5 (1995-06), within the user layer:
a) Station initialization
b) Cyclic data transmission
c) General interrogation
d) Command transmission
e) Data acquisition by polling
f) Acquisition of events
g) Parameter loading
h) File transfer
i) Clock synchronization
j) Transmission of integrated totals
k) Test procedure

What is DNP3?
DNP3 or Distributed Network Protocol Version 3.3 is a telecommunications
standard that defines communications between master stations, remote
telemetry units (RTUs) and other intelligent electronic devices (IEDs). It was
developed to achieve interoperability among systems in the electric utility, oil &
gas, water/waste water and security industries.
DNP3 was created as a proprietary protocol by Harris Controls Division initially
for use in the electrical utility industry. In November 1993 the protocol was made
available for use by third parties by transferring its ownership to the DNP3 User
Group. Through the DNP3 User Group, which may be joined for a nominal fee, the
full specification of the protocol may be obtained by any person or company.
DNP3 was designed specifically for SCADA (supervisory control and data
acquisition) applications. These involve acquisition of information and sending of
control commands between physically separate computer devices. It is designed
to transmit relatively small packets of data in a reliable manner with the
messages involved arriving in a deterministic sequence. In this respect it is
different from more general purpose protocols, such as FTP which is part of
TCP/IP, which can send quite large files, but in a way that is generally not as
suitable for SCADA control.
From its creation for the electrical distribution industry in America, DNP3 has
gained significant acceptance in both geographic and industry terms. DNP3 is
supported by a large number of vendors and users in electrical, water
infrastructure, and other industries in North America, South America, South
Africa, Asia and Australia. In Europe DNP3 competes with the IEC 60870-5-101
protocol which is widely used in that region, and which shares a common origin
with DNP3. However, the IEC protocol is confined to the electrical distribution
industry, whereas DNP3 has found wider industry applications in the oil & gas,
water/waste water and security industries.

Benefits of DNP3
The following list presents features of DNP3 that provide benefits to the user:
Open standard
Supported by an active DNP3 User Group
A protocol that is supported by a large and increasing number of equipment
manufacturers
Layered architecture conforming to IEC enhanced performance architecture
model
Optimized for reliable and efficient SCADA communications
Supported by comprehensive implementation testing standards
Has defined protocol subsets for particular applications
The ability to select from multiple vendors for future system expansion and
Modification

Features of DNP3
DNP3 offers substantial features as well as flexibility and security. These are
summarized in the following list:
Supports time stamped messages for sequence of event (SOE) recording
Breaks messages into multiple frames to provide optimum error control and
rapid communication sequences
Allows peer–peer topology as well as master–slave
Allows multiple master topology
Provides user definable objects
Provides for reporting by exception/event without polling by master
Provides for ‘changed data’ only responses
Broadcast messages
Secure configuration/file transfers
Addressing for over 65 000 devices on a single link
Provides time synchronization and time-stamped events
Data link and application layer confirmation

System topology
System topologies include:
Master–slave
Multidrop from one master
Hierarchical with intermediate data concentrators
Multiple master
DNP3 supports multiple-slave, peer-to-peer and multiple-master
communications. It supports the operational modes of polled, and
quiescent operation. The latter is also referred to as reporting by
exception. Quiescent operation is so called because polls to check for
changes are not required. This is because the master station can rely on
the outstation to send an ‘unsolicited response’ when it has a change that
needs to be reported. Thus, in the absence of change the system remains
quiescent, or in a quiet state, with neither polls from the master station,
nor responses from the outstations. This mode of operation provides for
better use of the communications system capacity. In a quiescent system,
generally a periodic background poll is still used, perhaps at hourly
intervals, to guard against undetected communications failure. If this was
not done, the master station would have no way of detecting the failure of
communications with the outstation should it occur. It would just assume
that nothing had changed.

The capability to support peer–peer and quiescent operation requires that

stations which are not designated as master stations can initiate
communications. This is sometimes referred to as ‘balanced’
communications, which means that any station can act as a primary (or
sending) and as a secondary (responding) station at the same time.
Despite the ability for non-master stations to initiate communications
within DNP3, only master stations can initiate requests for data, or issue
commands, to other stations. Thus, although the term balanced is applied
to the communications system, the differentiation between master and
slave stations remains necessary. Sometimes the terms master and
outstation are used to more appropriately reflect the capabilities of the
system.
Architectures may also involve the use of protocol converters to interface
to one or more devices using a different communications protocol. A
protocol converter might be used in the case of a hierarchical topology,
where the outstation devices only use DNP3, and the SCADA master might
use a different communications system.
In the case of DNP3 devices with a network port, DNP3 is encapsulated
within TCP/IP Ethernet packets. Although this does add the overhead
associated with these packets, it provides an effective means of using
local or wide area networks to cater for SCADA communications. In some
cases, this may allow the efficient extension of a SCADA system by
making use of an existing corporate network.

DNP3
Protocols define the rules by which devices talk with each other, and DNP3
is a protocol for transmission of data from point A to point B using serial
communications. It has been used primarily by utilities like the electric
companies, but it operates suitably in other areas. The DNP3 is specifically
developed for inter-device communication involving SCADA RTUs, and
provides for both RTU-to-IED and master-to-RTU/IED. It is based on the
three-layer enhanced performance architecture (EPA) model contained in
the IEC 60870-5 standards, with some alterations to meet additional
requirements of a variety of users in the electric utility industry.
DNP3 was developed with the following goals:
• High data integrity. The DNP3 data link layer uses a variation of the IEC
60870-5-1 (1990-02) frame format FT3. Both data link layer frames and
application layer messages may be transmitted using confirmed service.
• Flexible structure. The DNP3 application layer is object-based, with a
structure that allows a range of implementations while retaining
interoperability.
• Multiple applications. DNP3 can be used in several modes, including:
1. Polled only
2. Polled report-by-exception
3. Unsolicited report-by-exception (quiescent mode)
4. Mixture of modes 1 through 3.
It can also be used with several physical layers, and as a layered protocol
is suitable for operation over local and some wide area networks. •
Minimized overhead. DNP3 was designed for existing wire-pair data links
with operating bit rates as low as 1200 bit/s and attempts to use a
minimum of overhead
While retaining flexibility. Selection of a data reporting method, such as
report-by exception, further reduces overhead.
• Open standard. DNP3 is a non-proprietary, evolving standard controlled
by a users group whose members include RTU, IED, and master station
vendors, and representatives of the electric utility and system consulting
community.
DNP3 provides the rules for substation computers and master station
computers to communicate data and control commands. DNP3 is a non-
proprietary protocol that is available to anyone. Only a nominal fee is
charged for documentation, but otherwise it is available worldwide with no
restrictions. This means a utility can purchase master station and
substation computing equipment from any manufacturer and be assured
that they will reliably talk to each other. Vendors compete based upon
their computer equipment’s features, costs and quality factors instead of
who has the best protocol. Utilities are not stuck with one manufacturer
after the initial sale. The substation computer gathers data for
transmission to the master such as:
• Binary input data that is useful to monitor two-state devices. For
example, a circuit breaker is closed or tripped, or a pipeline pressure
alarm shows normal or excessive.
• Analog input data that conveys voltages, currents, power, reservoir
water levels and temperatures
• Count input data that reports kilowatt hours of energy
• Files that contain configuration data
The master station issues control commands that take the form of:
• Close or trip a circuit breaker, raise or lower a gate, and open or close a
valve
•

Analog output values to set a regulated pressure or set a desired voltage

level Other things the computers talk to each other about are
synchronizing the time and date, sending historical or logged data,
waveform data, etc. control commands from one computer to another. It
is not a general purpose protocol for transmitting hypertext, multimedia
or huge files. Figure 4.3 shows the client-server relationship and gives a
simplistic view of the databases and software processes involved. The
master or client is on the left side of Figure 4.3, and the slave or server is
on the right side.
A series of square blocks at the top of the server depicts its databases and
output devices. The various data types are conceptually organized as
arrays. An array of binary input values represents states of physical or
logical Boolean devices. Values in the analog input array represent input
quantities that the server measured or computed. An array of counters
represents count values, such as kilowatt hours, that are ever increasing
(until they reach a maximum and then roll over to zero and start counting
again). Control outputs are organized into an array representing physical
or logical on-off, raise-lower and trip-close points. Lastly, the array of
analog outputs represents physical or logical analog quantities such as
those used for setpoints.
The elements of the arrays are labeled 0 through N - 1 where N is the
number of blocks shown for the respective data type. In DNP3
terminology, the element numbers are called the point indexes. Indexes
are zero-based in DNP3, that is, the lowest element is always identified as
zero (some protocols use 1-based indexing). Notice that the DNP3 client,
or master, also has a similar database for the input data types (binary,
analog and counter). The master, or client, uses values in its database for
the specific purposes of displaying system states, closed-loop control,
alarm notification, this by sending requests to the server (slave) asking it
to return the values in the server’s database. This is termed polling. The
server responds to the client’s request by transmitting the contents of its
database. Arrows are drawn at the bottom of Figure 4.1 showing the
direction of the requests (toward the server) and the direction of the
responses (toward the client). Later we will discuss systems whereby the
slaves transmit responses without being asked.
The client and the server shown in Figure 4.3 each have two software
layers. The top layer is the DNP3 user layer. In the client, it is the software
that interacts between the database and initiates the requests for the
server’s data. In the server, it is the software that fetches the requested
data from the server’s database for responding to client requests. It is
interesting to note that if no physical separation of the client and server
existed, eliminating the DNP3 might be possible by connecting these two
upper layers together. However, since physical or possibly logical
separation of the client and server exists, DNP3 software is placed at a
lower level. The DNP3 user’s code uses the DNP3 software for
transmission of requests or responses to the matching DNP3 user’s code
at the other end.
Data types and software layers will be discussed later in the report.
However, it is important to first examine a few typical system
architectures where DNP3 is used. Figure 4.4 shows common system
architectures in use today. At the top is a simple one-on-one system
having one master station and one slave. The physical connection
between the two is typically a dedicated or dial-up telephone line.

Why use DNP3?

DNP3 is an open protocol that is gaining widespread acceptance and usage
across a number of industries and countries. It is optimized for SCADA
communications, and provides secure and efficient communications for the types
of messages transferred by these systems.
The reasons for the adoption of DNP3 by users are primarily:
It is an open protocol
It is optimized for SCADA communications
It provides interoperability between different vendor’s equipment
It is supported by a substantial number of SCADA equipment manufacturers
It will provide immediate and long-term benefits to users

Enhance performance architecture

The enhanced performance architecture model developed by IEC Technical Committee 57 is
a 3 layer sub-set of the OSI 7 layer model. The layers used in this model are the two hardware
layers and the top software layer, the application layer.
As for the OSI 7 layer model, during transmission high level data is passed
from the user application to the application level, and from there down
through the hierarchy to produce a stream of data over the physical
communications medium. In the process, the data may be converted from
a single user application data unit into smaller chunks and ultimately to a
bit stream. On reception at its destination the reverse process is applied,
and leading to regeneration of the original application level data unit.
DNP3 uses these three layers, but adds some transport functions. These
are often referred to as the pseudo-transport layers, and are sometimes
depicted as corresponding to the transport and network layers in a limited
manner. This relationship is shown in the following drawing.
This drawing shows the relationship between the 3 layer Enhanced
performance architecture (EPA), as implemented by DNP3, and the OSI
reference model. In the following section the message structure will be
analyzed in terms of the EPA model. Before looking at that, a brief review
of the general functions of each of the layers will be made .

Functions of the model layers

The functions of each layer of the EPA model are described briefly in the following
paragraphs. The network and transport layer functions have included as the pseudo-transport
layer, as limited transport and network functions are supported by the DNP3 protocol.

Physical layer
The physical layer is the physical media over which the protocol is transmitted. The
definition of this the physical interface characteristics in terms of electrical specifications,
timing, pin-outs and so on. The data element at this level is essentially the bit, i.e it is
concerned with how to pass one bit of data at a time across the physical media. Definition of
the physical layer also includes the functions for controlling the media, such as details
required to establish and maintain the physical link, and to control data flow. The actual
specification of this layer is normally a separate standard such as ITU-T X.21 or V.24, EIA
RS-232 or others.
The physical layer specification for DNP3 is covered in greater detail later
in this text, but it is noted here that EIA RS-232C was originally specified
for voltage levels and control signals, and ITU-T (formerly CCITT) V.24 for
DTE-DCE signaling. Other communications media such as over Ethernet
are in the process of being defined for use by the DNP3 User Group
Technical Committee.

Data link layer

The data link layer provides for reliable transmission of data across the physical medium.
While the physical layer is concerned with the passage of a signal, or a bit of data, the data
link layer is concerned with the passage of groups of data. These groups may be referred to as
a frame. Functions provided by the data link layer include flow control and error detection.
The pseudo-transport layer
This layer is included in DNP3 to allow for the transmission of larger blocks of data than
could otherwise be handled. Some writers have described this in terms of both network and
transport services, although these are usually simply referred to as pseudo-transport services.
Network functions are concerned with routing and flow control of data packets over
networks. Transport functions provide network transparent end-to-end delivery of whole
messages, including disassembly and reassembly, and error correction.
Application layer
The application layer is the level where the data is generated for sending, or requested to be
sent. It is the layer that interfaces to the lower levels to achieve the result of end-end
transmission of required information. In turn, the DNP3 application layer provides its
services to the user application programs, such as an HMI system, an RTU, or other system.

Topologies
As previously described, DNP3 supports either master-slave or peer-to-peer communications,
with either one-on-one or multidrop topologies.
• Point-to-point
• Multidrop from one master
• Hierarchical with intermediate data concentrators
• Multiple master
Point-to-point, or direct topology refers to the case of two DNP3 devices connected together,
either directly with a cable, or via modems and a communications path. This could be via a
leased line, via radios, or via the public switched telephone network (PSTN). A serial bus
topology is the alternative to a direct topology. This may also be referred to as multidrop. In
this case multiple devices are connected to the same communications path.

Physical layer procedures

Procedures must be provided to support both half-duplex and full-duplex communications.
The specific procedures used will depend on the topology as well as whether half- or
fullduplex transmission is available. One particular role of the procedures is to manage the
event of message collision, where it can occur. Because DNP3 supports peer–peer
communications, any station can act as a primary, or message initiator. Because of this,
messages can be sent from two stations simultaneously, causing a collision. Before discussing
the physical layer procedures, a brief review of the terminology is given in the following
table.

Figure 4.4 shows common system architectures in use today. At the top is
a simple one-on-one system having one master station and one slave. The
physical connection between the two is typically a dedicated or dial-up
telephone line.
The second type of system is known as a multidrop design. One master
station communicates with multiple slave devices. Conversations are
typically between the client and one server at a time. The master requests
data from the first slave, then moves onto the next slave for its data, and
continually interrogates each slave in a round robin order. The
communication media is a multi-dropped telephone line, fiber optic cable,
or radio. Each slave can hear messages from the master and is only
permitted to respond to messages addressed to itself. Slaves may or may
not be able to hear each other.
In some multidrop forms, communications are peer-to-peer. A station may
operate as a client for gathering information or sending commands to the
server in another station. Then, it may change roles to become a server to
another station. The middle row in Figure 4.4 shows a hierarchical type
system where the device in the middle is a server to the client at the left
and is a client with respect to the server on the right. The middle device is
often termed a sub-master.
Both lines at the bottom of Figure 4.4 show data concentrator applications
and protocol converters. A device may gather data from multiple servers
on the right side of the figure and store this data in its database where it
is retrievable by a master station client on the left side of the figure. This
design is often seen in substations where the data concentrator collects
information from local intelligent devices for transmission to the master
station.
In recent years, several vendors have used Transport Control
Protocol/Internet Protocol (TCP/IP) to transport DNP3 messages in lieu of
the media discussed above. Link layer frames, which have not been
discussed yet, are embedded into TCP/IP packets. This approach has
enabled DNP3 to take advantage of Internet technology and permitted
economical data collection and control between widely separated devices.
Many communication circuits between the devices are susceptible to
noise and signal distortion. The DNP3 software is layered to provide
reliable data transmission and to affect an organized approach to the
transmission of data and commands. Figure 4.5 shows the DNP3
architecture layers.

The link layer has the responsibility of making the physical link reliable. It
does this by providing error detection and duplicate frame detection. The
link layer sends and receives packets, which in DNP3 terminology are
called frames. Sometimes transmission of more than one frame is
necessary to transport all of the information from one device to another. A
DNP3 frame consists of a header and data section. The header specifies
the frame size, which DNP3 station should receive the frame, which DNP3
device sent the frame, and data link control information. The data section
is commonly called the payload and contains the data passed down from
the layers above.
Every frame begins with two sync bytes that help the receivers determine
where the frame begins. The length specifies the number of octets in the
remainder of the frame, not including Cyclical Redundancy Check (CRC)
octets. The link control octet is used between sending and receiving link
layers to coordinate their activities. A destination address specifies which
DNP3 device should process the data, and the source address identifies
which DNP3 device sent the message. Having both destination
and source addresses satisfies at least one requirement for peer-to-peer
communications because the receiver knows where to direct its
responses. Every DNP3 device must have a unique address within the
collection of devices sending and receiving messages to and from each
other. Three destination addresses are reserved by DNP3 to denote an all-
call message; that is, all DNP3 devices should process the frame. Thirteen
addresses are reserved for special needs in the future. Confirmation is not
received, the link layer may retry the transmission. Some disadvantages
are the extra time required for confirmation messages and waiting for
multiple timeouts when retries are configured. It is the responsibility of
the transport layer to break long messages into smaller frames sized for
the link layer to transmit, or when receiving, to reassemble frames into
the longer messages. In DNP3 the transport layer is incorporated into the
application layer. The transport layer requires only a single octet within
the message to do its work. Therefore, since the link layer can handle only
250 data octets, and one of those is used for the transport function, then
each link layer frame can hold as many as 249 application layer octets.
Application layer messages are broken into fragments. Fragment size is
determined by the size of the receiving device’s buffer. It normally falls
between 2048 and 4096 bytes. A message that is larger than one
fragment requires multiple fragments. Fragmenting messages is the
responsibility of the application layer. Note that an application layer
fragment of size 2048 must be broken into 9 frames by the transport
layer, and a fragment size of 4096 needs 17 frames. Interestingly, it has
been learned by experience that communications are sometimes more
successful for systems operating in high noise environments if the
fragment size is significantly reduced.
The application layer works together with the transport and link layers to
enable reliable communications. It provides standardized functions and
data formatting with which the user layer above can interact. Before
functions, data objects and variations can be discussed, the terms static,
events and classes need to be covered. In DNP3, the term static is used
with data and refers to the current value. Thus static binary input data
refers to the present on or off state of a bi-state device. Static analog
input data contains the value of an analog value at the instant it is
transmitted. DNP3 allows a request for some or all of the static data
stored in a slave device. DNP3 events are associated with something
significant happening. Examples are state changes, values exceeding
some threshold, snapshots of varying data, transient data and newly
available information. An event occurs when a binary input changes from
an “on”
to an “off” state or when an analog value changes by more than its
configured dead band limit. DNP3 provides the ability to report events
with and without time stamps so that the client can generate a time
sequence report.
The user layer can direct DNP3 to request events. Usually, a client is
updated more rapidly if it mostly polls for events from the server and only
occasionally asks for static data as an integrity measure. The reason
updates are faster is because the number of events generated between
server interrogations is small and, therefore, less data must be returned
to the client.

Modbus
Modbus Messaging protocol is an Application layer (OSI layer 7) protocol that
provides client/server communication between devices connected to different
types of buses or networks. The Modbus Messaging protocol is only a protocol
and does not imply any specific hardware implementation. Also note that the
Modbus Messaging protocol used with Modbus Serial is the same one used with
Modbus Plus and Modbus TCP. Modbus messaging is based on a client/server
model and employs the following messages:
• Modbus requests, i.e. the messages sent on the network by the clients to
initiate transactions. These serve as indications of the requested services on the
server side
• Modbus responses, i.e. the response messages sent by the servers. These
serve as confirmations on the client side the interaction between clients and
sever (controller and target device) can be depicted as follows. The parameters
exchanged by the client and server consist of the Function Code (‘what to do’),
the Data Request (‘with which input or output’) and the Data response (‘result’).
The Application Data Unit (ADU) structure of the Modbus protocol is shown in the
Figure

Modbus functions
All functions supported by the Modbus protocol are identified by an index
number. They are designed as control commands for field instrumentation
and actuators and are as follows:
Coil control commands for reading and setting a single coil or a group of
coils
Input control commands for reading input status of a group of inputs
Register control commands for reading and setting one or more holding
registers
Diagnostics test and report functions
Program functions
Polling control functions
Reset

Protocol specifics

Message format
Synchronization
Memory location
Function codes
Exception responses

TCP/IP
TCP/IP is the de facto global standard for the Internet (network) and host–to–host
(transport) layer implementation of internet work applications because of the
popularity of the Internet. The Internet (known as ARPANet in its early years),
was part of a military project commissioned by the Advanced Research Projects
Agency (ARPA), later known as the Defense Advanced Research Agency or
DARPA. The communications model used to construct the system is known as the
ARPA model.
Whereas the OSI model was developed in Europe by the International
Standards Organization (ISO), the ARPA model (also known as the DoD model)
was developed in the USA by ARPA. Although they were developed by different
bodies and at different points in time, both serve as models for a
communications infrastructure and hence provide ‘abstractions’ of the same
reality. The remarkable degree of similarity is therefore not surprising. Whereas
the OSI model has 7 layers, the ARPA model has 4 layers. The OSI layers map
onto the ARPA model as follows.
• The OSI session, presentation and applications layers are contained in the
ARPA process and application layer.
• The OSI transport layer maps onto the ARPA host–to–host layer (sometimes
referred to as the service layer).
• The OSI network layer maps onto the ARPA Internet layer.
• The OSI physical and data link layers map onto the ARPA network interface
layer.
The relationship between the two models is depicted in Figure

OSI vs. ARPA models

TCP/IP, or rather the TCP/IP protocol suite is not limited to the TCP and IP
protocols, but consists of a multitude of interrelated protocols that occupy the
upper three layers of the ARPA model. TCP/IP does NOT include the bottom
network interface layer, but depends on it for access to the medium.
As depicted in Figure 5. 14, an Internet transmission frame originating on a
specific host (computer) would contain the local network (for example, Ethernet)
header and trailer applicable to that host. As the message proceeds along the
Internet, this header and trailer could be replaced depending on the type of
network on which the packet finds itself - be that X.25, frame relay or ATM. The
IP datagram itself would remain untouched, unless it has to be fragmented and
reassembled along the way.

Internet frame

The Internet layer: This layer is primarily responsible for the routing of packets
from one host to another.
The host–to–host layer: This layer is primarily responsible for data integrity
between the sender host and receiver host regardless of the path or distance
used to convey the message.
The process/application layer: This layer provides the user or application
programs with interfaces to the TCP/IP stack.
Internet layer protocols (packet transport): Protocols like internet protocol
(IP), the internet control message protocol (ICMP) and the address resolution
protocol (ARP) are responsible for the delivery of packets (datagrams) between
hosts.
Routing: Unlike the host–to–host layer protocols (for example, TCP), which
control end–to–end communications, IP is rather ‘shortsighted.’ Any given IP
node (host or router) is only concerned with routing (switching) the datagram to
the next node, where the process is repeated.

Communication architectures

Point-to-point (two stations)

This is the simplest configuration where data is exchanged between two stations. One station can be
setup as the master and one as the slave. It is possible for both stations to communicate in full duplex
mode (transmitting and receiving on two separate frequencies) or simplex with only one frequency.

Multipoint (or multiple stations)

In this configuration, there is generally one master and multiple slaves. Generally data points are
efficiently passed between the master and each of the slaves. If two slaves need to transfer data
between each other they would do so through the master who would act as arbitrator or moderator.
Alternatively, it is possible for all the stations to act in a peer-to-peer communications manner with
each other. This is a more complex arrangement requiring sophisticated protocols to handle collisions
between two different stations wanting to transmit at the same time.

Communication philosophies
There are two main communication philosophies possible. These are; polled (or masterslave) and
carrier sense multiple access/collision detection (CSMA/CD). The one notable method for reducing
the amount of data that needs to be transferred from one point to another (and to improve the overall
system response times) is to use exception reporting which is discussed later. With radio systems,
exception reporting is normally associated with the CSMA/CD philosophy but there is no theoretical
reason why it cannot be applied to RTUs where there is a significant amount of data to be transferred
to the master station. This discussion concentrates on the radio communication aspects. It is difficult
to use token bus or CSMA/CD on cable systems other than in a LAN context (with consequent short
distances). For longer distances, cable systems would use a polled philosophy.
• For heavily loaded systems with each node having constant data transfer requirements, as this gives
a predictable and efficient system.
The disadvantages are:
• Variations in the data transfer requirements of each slave cannot be handled.
• Interrupt type requests from a slave requesting urgent action cannot be handled (as the master may
be processing some other slave).
• Systems, which are lightly loaded with minimum data changes from a slave, are quite inefficient
and unnecessarily slow.
• Slaves needing to communicate with each other have to do so through the master with added
complexity in the design of the master station.
s
Typical considerations in configuring a master station
Before commencing with a detailed discussion, a few factors to bear in mind when designing the
system are:
• Simplicity (the ‘KISS’ principle)
• Minimum response time
• Deterministic type operation (especially for critical signals from RTUs)
• Minimum cost
• Optimum efficiency of operation
• Data format and communication speed (baud rate/stop bits/parity)
While it is difficult to generalize all master stations/RTUs and communication systems forming part
of a SCADA system, a few considerations are discussed below:
• Hardware handshaking
If a modem is not being used, select ‘no handshaking’. If a modem is being used a full or half-duplex
one should be considered.
• Station address
Every station (and RTU) must have a unique address.
• Error detection
Block check (BCC) or cyclic redundancy check (CRC). Preferably select CRC as this gives the best
error checking capability.
• Protocol message retries
How many retries or messages transmitted before the master station flags this RTU as unavailable?
(Typically three retries are standard. It must be noted however that certain sensitive units may require
just one retry before the master station flags it as unavailable.)
• RTS send delay
This typically goes with the clear to send signal from the modem. This defines the amount of time that
elapses before the message is transmitted. The clear to send line (from the modem) must also be
asserted before transmission can occur.
• RTS off delay
This is the time that elapses between the end of the message and the inhibiting of the RTS signal. It is
important not to intermit the message prematurely by setting this RTS off delay, too short.
• Timeout delay
The timeout delay for a message received from an RTU device.
• Size of messages from RTU
This defines the maximum size of messages allowable from the RTU during a poll by the master
station.
• Priority message transmit
This defines when an immediate message is required to be transmitted by the master station, at the
conclusion of a poll of an RTU station or when the master station appears in the poll sequence.
• Poll sequence
Define the station addresses in the poll sequence for both priority and normal message transfers.
• Addressing considerations
Each station on a network should have a unique address. One address (normally FF 16 or 1111 1111) is
reserved for broadcast address. Some protocols also reserve certain of the upper addresses for
diagnostic purposes and they should also not be used.

Introduction to protocols
The transmission of information (both directions) between the master station and RTUs using time
division multiplexing techniques requires the use of serial digital messages. These messages must be
efficient, secure, flexible, and easily implemented in hardware and software. Efficiency is defined as:
Information bits transmitted ÷ Total bits transmitted Security is the ability to detect errors in the
original information transmitted, caused by noise on the communication channel. Flexibility allows
different amounts and types of information to be transmitted upon command by the master station.
Implementation in hardware and software requires the minimum in complicated logic, memory
storage, and speed of operation. All messages are divided into three basic parts as follows:
• Message establishment: This provides the signals to synchronize the receiver and transmitter.
• Information: This provides the data in a coded form to allow the receiver to decode the information
and properly utilize it.
• Message termination: This provides the message security checks and a means of denoting the end
of the message. Message security checks consist of logical operations on the data, which result in a
predefined number of check bits transmitted with the message. At the receiver the same operations are
performed on the data and compared with the received check bits. If they are identical, the message is
accepted; otherwise, a retransmission of the original message is requested.
A typical example of commonly used asynchronous message format is shown below:

The message establishment field has three components:

• An 8 millisecond (minimum) pre-transmission mark to condition the modem receiver for the
synchronization bits.
• Synchronization: This consists of two bits: a space followed by a mark. The asynchronous interface
is designed to start decoding bits after a mark-to-space transition. Therefore the change from the pre-
transmission mark to the space provides this transition.
• RTU address: This allows a receiver to select the message addressed to it from the messages to all
RTUs on a party line. To avoid any possible mix-ups on addressing the wrong RTU, it is
recommended that each RTU in the system has a unique address.
Protocol operation
A typical sequence of operations is given below.
• In a multidrop link, the primary node sends a normal response mode frame with the P/F bit set to 1
together with the address of the secondary.
• The secondary responds with an unnumbered acknowledgment with the P/F bit set to 1.
Alternatively if the receiving node is unable to accept the setup command a disconnected mode frame
is returned.
• Data is then transferred with the information frames.
• The primary node then sends an unnumbered frame containing a disconnect in the control field.
• The secondary then responds with an unnumbered acknowledgment.
A similar approach is followed for a point to point link using asynchronous balanced mode except that
both nodes can initiate the setting up of the link and the transfer of information frames, and the
clearing of the point to point link.
• When the secondary transfers the data, it transmits the data as a sequence of information frames
with the F bit set to 1 in the final frame of the sequence.
• In NRM mode if the secondary has no further data to transfer, it responds with a receiver not ready
frame with the P/F bit set to 1.

PLC with SCADA Diagrams