The DNP protocol was developed for communication with telecontrol
substations and other intelligent electronic devices (IEDs). Designed with current and
future telecontrol applications for the North American power industry in mind, it
is still widely used to this day. Although the Harris company originally
initiated its development, responsibility for further upgrades and maintenance
then passed to the DNP User Group, a user and
vendor association for the protocol.
Originally, the protocol's main use was for slow serial communication, its
present-day version also supports TCP/IP-based operation.
Unlike related protocols such as IEC 60870-5-101, DNP 3.0 commands a very
powerful application layer, which allows the decoding of data without the use of
implicit parameters. DNP 3.0 supports a variety of representation modes for
information objects, offering a high degree of interoperability on the
application layer. This was achieved at the cost of greater complexity, which
makes implementation more difficult and demands much more time for
implementation and testing.
Compared with IEC 60870-5-101, the protocol's transport layer allows fragmented
data transmission of higher volumes. This has a positive effect on communication
via TCP/IP, as the whole network bandwidth can be fully utilized.
A further advantage compared with IEC 60870-5-101 is provided by the additional
feature of requesting receive acknowledgement from the remote terminal. A
substation can remove data from its buffer after it has actually arrived at its
destination and has been acknowledged. This feature facilitates the use of
simple routers.
As is true for the IEC 60870-5-101, its link layer is based on the IEC 60870-5-1
and IEC 60870-5-2 standards. But only balanced transmission mode is used, which
was exclusively intended for full-duplex point-to-point connections. As DNP 3.0
is also used for half duplex party-line operation, a mechanism to prevent
collisions was added. As this mechanism requires specific functionalities in the DCEs - which might not always be present - and accurate configuration of the
timing, in practice its use often involves some difficulties. In many cases this
drawback results in ignoring the link layer functionality, so that only the
unacknowledged (SEND/NO REPLY) service with poll-initiated data transmission on
the application layer is used instead. The problem can be avoided in TCP/IP
operation, as collisions cannot occur or are averted by the network.
Two forms which have to be completed by every manufacturer help ensure
maximum interoperability between devices:
- DNP Device Profile
which defines the basic protocol functionalities supported by the device
- DNP Implementation Table
which defines the information objects and their representation supported by
the device.
In addition subsets of the full function range are defined and divided into
three levels:
- DNP Level 1
is the smallest subset and defines only the simplest functions and information
objects. This level is best suited for IEDs.
- DNP Level 2
is intended for larger devices such as RTUs.
- DNP Level 3
suits larger RTUs and offers practically the complete range of
DNP 3.0 functionalities.
These levels are downward compatible, for instance a master of level 2
supports levels 1 and 2. .
For each device there is a "device profile" that shows which levels are
supported. Compatibility tests were developed in 2000 (Certification Procedure)
with detailed descriptions of device behavior to ensure maximum compatibility,
but until now only for levels 1 and 2.
