NOJA-7507-00
NOJA Power
Application Note
Introduction to DNP3
www.nojapower.com.au
NOJA-7507-00
Revision History
Rev Author Date Comment
0 OA 29/11/2017 Initial Release
0 ON 21/09/2020 Document Approval
NOJA Power® and OSM® are registered trademarks of NOJA Power Switchgear Pty Ltd. This document
is copyright and is intended for users and distributors of NOJA Power Switchgear product. It contains information
that is the intellectual property of NOJA Power Switchgear and the document, or any part thereof, should not be
copied or reproduced in any form without written permission from NOJA Power Switchgear.
NOJA Power® and OSM® are registered trademarks of NOJA Power Switchgear and should not be
reproduced or used in any way without written authorisation.
NOJA Power Switchgear applies a policy of ongoing development and reserves the right to change product
without notice. NOJA Power Switchgear does not accept any responsibility for loss or damage incurred as a
result of acting or refraining from action based on information in this User Manual.
© NOJA Power Switchgear Pty Ltd 2002 - 2020
www.nojapower.com.au
NOJA-7507-00
Table of Contents
1. Introduction ........................................................................................................................................... 1
2. DNP3 Architecture .................................................................................................................................. 1
3. DNP3 Frame Format ............................................................................................................................... 2
4. Report by Exception ............................................................................................................................... 2
5. Static and Event Data ............................................................................................................................. 3
5.1. Static Analog Data ........................................................................................................................... 3
5.2. Event Analog Data ........................................................................................................................... 3
5.3. Groups ............................................................................................................................................ 3
5.4. Objects ........................................................................................................................................... 4
6. Communication between Master Station and Device ................................................................................. 4
6.1. Unsolicited Response Configurable Parameters .................................................................................. 5
7. DNP3-Secure Authentication (SA) ............................................................................................................ 6
7.1. Challenge/Response Mechanism ....................................................................................................... 6
7.2. Aggressive Mode ............................................................................................................................. 7
8. Configuration in CMS .............................................................................................................................. 8
8.1. DNP3 Settings ................................................................................................................................. 8
8.2. Enabling Data Points ........................................................................................................................ 9
NOJA-7507-00
1. INTRODUCTION
The Distributed Network Protocol (DNP3) is a protocol for transmission of data using serial and IP, intended for
Supervisory Control and Data Acquisition (SCADA) applications.
It defines the rules for data and control commands between a master, typically a control centre and outstations
in the field.
This document is an introduction to the DNP3 protocol and its implementation in the NOJA Power Recloser
Controller (RC) which conforms to the IEEE Standard 1815TM-2012.
It provides some basic information on the following:
✓ DNP3 architecture
✓ DNP3 Frame Format
✓ Report By Exception
✓ Static and Event Data
✓ Communication between Master Station and Device
✓ DNP3-Secure Authentication
✓ Configuration in CMS.
Please refer to NOJA-522 DNP Device Profile and NOJA-5056 RC20 DNP3 Device Profile for more detailed
implementation information.
2. DNP3 ARCHITECTURE
DNP3 is a layered protocol based on the Open System Interconnection (OSI) model.
Object Library
Binary Inputs, Binary Outputs, Analog Inputs etc. that reside in the
master or outstation.
Application Layer
Application tasks for sending solicited requests from the master to the
outstation and unsolicited responses from the outstations.
Transport Layer
Assemble/Disassemble messages into smaller packets that can be
handled by the data link layer i.e. frames
Data Link Layer
Manage sending and receiving frames
(Error and duplicate frame detection)
Physical Layer
Physical media e.g. Serial or Ethernet
Introduction to DNP3 Application Note 1
NOJA-7507-00
3. DNP3 FRAME FORMAT
The DNP3 frame consists of a header and data section.
DNP3 Frame
Header Data
Header
Sync Length Link Control Destination Address Source Address CRC
The header provides the following:
▪ 2 sync bytes which help the receiver determine where the frame begins
▪ Link Control element which controls the sending and receiving of messages
▪ Destination and Source Address (devices must have unique address)
▪ Cyclic Redundancy Checking (CRC) provides a high degree of assurance that communication errors can
be detected.
4. REPORT BY EXCEPTION
DNP3 is a SCADA protocol based on an event-reporting model known as “report by exception” (RBE). The RBE
model minimises communication channel bandwidth usage by only transmitting data that has changed in
accordance with a pre-set condition e.g. reporting a binary input or alarm signal that has changed state or an
analogue measurement that has changed by an amount greater than a minimum threshold called a “deadband”.
There are three levels of classes which can be assigned to each event to determine their priority: Class 1 - Highest
Priority, Class 2 - Middle Priority and, Class 3 - Lowest Priority.
The RBE model relies on event data buffers in the field device to store data that is to be reported and a handshake
mechanism where data is cleared from the field device event buffer only after it is sent to the master and the
master confirms that it has been received.
At start-up, the “current state” of all data in the system is collected from the device and the event buffer is cleared
(this is known as an integrity poll). After the integrity poll is complete, only subsequent changes are logged in the
event buffer and reported.
Master Station Field Device
Communication Communication Communication
process Network process
Event buffer
Database
Database
Figure 1 RBE communication system components
Reporting to the master station can occur spontaneously or if the master station requests it. When the master
station acknowledges that the data has been received it is cleared from device’s event buffer. If the
acknowledgement is not received, the events will be reported again later. This process guarantees that the event
data remains buffered until it has been received by the master.
Introduction to DNP3 Application Note 2
NOJA-7507-00
5. STATIC AND EVENT DATA
Static data is the “current state” of the field device’s data. Events are associated with a change of state for
particular data e.g., 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 deadband limit.
5.1. STATIC ANALOG DATA
Static data can be represented by 6 variations:
1. 32 bit integer with flag
2. 16 bit integer with flag
3. 32 bit integer
4. 16 bit integer
5. 32 bit floating point with flag
6. 64 bit floating point with flag
The flag has bit fields representing whether the source is online, or restarted, or lost communication, or data out
of range.
5.2. EVENT ANALOG DATA
Event analog data can be represented by 8 variations:
1. 32 bit integer with flag
2. 16 bit integer with flag
3. 32 bit integer with flag and event time
4. 16 bit integer with flag and event time
5. 32 bit floating point with flag
6. 64 bit floating point with flag
7. 32 bit floating point with flag and event time
8. 64 bit floating point with flag and event time
The flag has the same bit fields as for static variations.
5.3. GROUPS
Group numbers are assigned to allow distinction between variations that would otherwise appear the same. (e.g.
Variations 1 and 2 in both static and analog data)
▪ Static analog values are assigned group 30.
▪ Event analog values are assigned group 32.
A message identifies the group and variation of each value in the message.
DNP3 documentation provides a library of valid groups and their variations.
Introduction to DNP3 Application Note 3
NOJA-7507-00
5.4. OBJECTS
Objects in a message are the encoded representation of a data point or other structure.
The object format depends upon the group and variation number chosen.
Classification Examples
Binary Inputs Close Request Blocked, Pickup, Open, Lockout
Binary Outputs Request Trip/Close, Set I/O Outputs, Erase Fault counters
Binary Counters Trips, Mechanical Wear (%)
Analog Inputs Trip currents, Battery Voltage
Strings Serial Numbers, Hardware and software versions.
6. COMMUNICATION BETWEEN MASTER STATION AND DEVICE
Any change in the field device database is logged in the event buffer for reporting to the master station. This is
sent when the master requests it, or, it can be sent spontaneously (if unsolicited response is enabled). Whenever
events are sent to the master, the master will acknowledge that they have been received. This acknowledgement
allows the data that has been reported to be cleared from the event buffer.
Control Centre RC
Request
Standard protocol response
Confirmation
Figure 2: Solicited Response Mechanism
If support for unsolicited response is permitted, the Outstation will send a null Unsolicited Response after it
restarts, then waits for an “Enable Unsolicited Response” command from the master before sending additional
Unsolicited Responses containing event data.
Control Centre RC
Null Unsolicited Response
Enable Unsolicited Response
Event Data
Confirmation
Figure 3: Unsolicited Response
Introduction to DNP3 Application Note 4
NOJA-7507-00
6.1. UNSOLICITED RESPONSE CONFIGURABLE PARAMETERS
Unsolicited Response Parameters can be configured via CMS. Table 1 below provides a description of the
parameters. Please refer to DNP3 protocol document for more information.
Figure 4: Configuring Unsolicited Response Parameters in CMS
Table 1: Unsolicited Response Parameters
Name Description
Unsolicited Response If permitted, the device will transmit an initial null
unsolicited response, and will continue to send it until
the DNP3 master issues an ‘Enable Unsolicited
Response’ request message for one or more of the
event classes (class 1, 2 or 3).
Unsolicited Response Confirmation Timeout This is the amount of time that the outstation will wait
for an Application Layer confirmation back from the
“Unsolicited Response Confirmation Timeout” uses master indicating that the master received the
the value configured for the Application Layer unsolicited response message.
Confirmation Parameter.
Retry Delay This parameter specifies the minimum amount of time
between unsuccessfully confirmed unsolicited
responses.
Retries This is the number of retries that an outstation
transmits in each unsolicited response series if it does
not receive confirmation back from the master.
Offline Interval If a confirmation from the master is not received after
the total number of retries then this parameter defines
the time interval between unsolicited retries from that
point forward. It allows the interval between retries to
be increased if no confirmation is being received while
still allowing an infinite number of unsolicited retries.
Class 1/2/3 Check boxes Only used for legacy master stations that do not
generate the ‘Enable Unsolicited Response’ request
message. Otherwise leave un-checked.
Events Number of events from a particular class used to
trigger unsolicited responses.
Delay For each class, if the amount of time since an event
has occurred for that class meets or exceeds this
value, then an unsolicited response will be generated.
Introduction to DNP3 Application Note 5
NOJA-7507-00
7. DNP3-SECURE AUTHENTICATION (SA)
DNP3-Secure Authentication (SA) allows two methods of authentication: Challenge/Response Mechanism and
Aggressive Mode. Both methods use a session key which is created using the pre-shared update key and is
changed periodically. For more details refer to DNP3-SA Application Guide.
7.1. CHALLENGE/RESPONSE MECHANISM
For Challenge/Response Mechanism when a master station issues a critical request, the outstation will issue an
authentication challenge that includes random data. The master station responds to the challenge with a Hash-
based Message Authentication Code (HMAC) which includes the random data and the session key. The outstation
also has the session key and can verify that the HMAC is correct.
In the example below, the RC responds to a non-critical request without asking for authentication. For a critical
request it issues an authentication challenge and it does not respond to the request until the HMAC has been
verified.
Control Centre RC
Non-Critical request
Standard protocol response
Critical request
Authentication
Challenge
Authentication
Response
Standard protocol response
Figure 5: Challenge/Response Mechanism
Note: DNP defines which requests are considered critical which include requests such as write, select, operate,
stop and restart.
Introduction to DNP3 Application Note 6
NOJA-7507-00
7.2. AGGRESSIVE MODE
In aggressive mode the sender of the critical message includes the HMAC at the end of the critical message
without having to be challenged.
Control Centre RC
Non-Critical request
Standard protocol response
Critical request with
Authentication Response
Standard protocol response
Figure 6: Aggressive Mode
Introduction to DNP3 Application Note 7
NOJA-7507-00
8. CONFIGURATION IN CMS
8.1. DNP3 SETTINGS
DNP3 can be configured via CMS. Please refer to DNP3 protocol document for more information.
Figure 7: DNP3 Configuration in CMS
Introduction to DNP3 Application Note 8
NOJA-7507-00
8.2. ENABLING DATA POINTS
Data points required can be enabled via CMS in the corresponding tabs as shown below. You will need to enter a
unique DNPID for each data point selected.
Figure 8: Binary Outputs
The following limitations apply for the number of data points that can be enabled in each group:
Object Group Limit
Binary Inputs 255 points
Binary Outputs 96 points
Binary Counters 96 points
Analog Inputs 128 points
Octet Strings 32 points
Security Statistics 32 points
Introduction to DNP3 Application Note 9
