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