7
2. DNP3 Protocol Primer
PXM 4/6/8K DNP3 Ethernet Communications User Manual
MN150005EN January 2017 www.eaton.com
2.3.4 Reading Data
The master’s user layer formulates its request for data from
the outstation by telling the application layer what function
to perform, such as reading, and by specifying the data
types it wants from the outstation. The request can specify
how many objects it wants or it can specify specific objects
or a range of objects from index number X through index
number Y. The application layer then passes the request
down through the transport layer to the link layer that, in
turn, sends the message to the outstation. The link layer
at the outstation checks the frames for errors and passes
them up to the transport layer where the complete mes-
sage is assembled in the outstation’s application layer. The
application layer then tells its user layer which groups and
variations were requested.
Responses work similarly, in that the outstation’s user layer
fetches the desired data and presents it to the application
layer that, in turn, uses the group and variation numbers to
format user layer data into objects. Data is then passed
downward, across the communication channel and upward
to the master’s application layer. Here the data objects are
then presented to the master’s user layer.
2.3.5 Other Functions
Reading data was briefly described in Section 2.3.4, but
DNP3 software is designed to handle other functions. For
one, the master can set the time in the outstation. The
master can transmit freeze accumulator requests, and it
can transmit requests for control operations and setting of
analog output values using select-before-operate or direct-
operate sequences.
2.4 Unsolicited Responses
One area that has not been covered yet is transmission of
unsolicited messages. This is a mode of operating where
the outstation spontaneously transmits a response without
having received a specific request for the data. Not all out-
stations have this capability. This mode is useful when the
system has many outstations and the master requires noti-
fication as soon as possible after a change occurs. Rather
than waiting for a master station polling cycle to get around
to it, the outstation simply transmits the change.
Before configuring a system for unsolicited messages,
a few basics need to be considered. First, spontaneous
transmissions should generally occur infrequently, other-
wise, too much contention can occur, and controlling media
access via master station polling would be better. The sec-
ond basic issue is that the outstation should have some way
of knowing whether it can transmit without stepping on
another outstation’s message. DNP3 leaves specification of
algorithms to the system implementer.
2.5 Implementation Levels
One last area of discussion involves implementation levels.
The DNP3 organization recognizes that supporting every
feature of DNP3 is not necessary for every device. Some
devices are limited in memory and speed and do not need
specific features, while other devices must have the more
advanced features to accomplish their task. DNP3 orga-
nizes complexity into three levels. At the lowest level, level
1, only very basic functions must be provided and all others
are optional. Level 2 handles more functions, groups, and
variations, and level 3 is even more sophisticated. Within
each level, only certain combinations of request formats and
response formats are required. This was done to limit soft-
ware code in masters and outstations while still assuring
interoperability.
2.6 Summary
It should be apparent by now that DNP3 is a protocol that
fits well into the data acquisition world. It transports data
as generic values, it has a rich set of functions, and it was
designed to work in a wide area communications network.
The standardized approach of groups and variations, and
link, transport and application layers, plus public availability
makes DNP3 a protocol to be regarded.