Ax 1703

Firmware Description

DNPMxx
Distributed Network Protocol

© 2002 by VA TECH SAT GmbH & Co

All rights reserved.

Any kind of disclosure and reproduction

whatsoever of this document or of parts thereof is
permitted only upon prior written consent by
VA TECH SAT.

Technical specifications are used for purposes of

product description only and are no guaranteed
specifications in legal terms. Subject to
modifications - also in terms of technology.
DNPMxx Firmware Description Ax 1703

This document is applicable to the following product(s):

DNPM00 Rev. 01 and higher

Version Revision Date Change

A, 1 00 10.04.02 First edition

Document information:
author / editor: T. Schwarz / E. Josefik
server\service: \\VIE001\ENT_TDOK\
directory: \Ax1703\FW\DNPMxx\
file name(s): DNPMxx.DOC, DNPMxx1.DOC
file format: WORD 2000

created last change released

on by on by on by
10.04.02 SW-AUT/SC SW-AUT/ 10.04.02 PMG/WR

ii DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

Table of Contents

1. Protocol Description ...........................................................................1-1

1.1. PCMBA-Modulation Procedure.............................................................................. 1-1

2. Message Structure ..............................................................................2-1

2.1. Physical Layer........................................................................................................ 2-1
2.2. Data Link Layer ...................................................................................................... 2-1
2.2.1. FT3 Frame...................................................................................................... 2-2
2.2.2. Data Link Function Codes .............................................................................. 2-6
2.2.2.1. Reset ...................................................................................................... 2-6
2.2.2.2. Reset of User Process............................................................................ 2-6
2.2.2.3. Test......................................................................................................... 2-6
2.2.2.4. User Data................................................................................................ 2-6
2.2.2.5. Unconfirmed User Data .......................................................................... 2-6
2.2.2.6. Request Link Status................................................................................ 2-7

3. Transport Function..............................................................................3-1
3.1. Transport Header ................................................................................................... 3-2
3.1.1. Frame Assembling ......................................................................................... 3-3

4. Application Layer ................................................................................4-1

4.1.1. Application Request Format........................................................................... 4-2
4.1.2. Application Response Format ........................................................................ 4-2
4.1.3. Application Header ......................................................................................... 4-3
4.1.3.1. Request Header...................................................................................... 4-3
4.1.3.2. Response Header................................................................................... 4-3
4.1.3.3. Application Control.................................................................................. 4-4
4.1.4. Communication Flow Control ......................................................................... 4-5
4.1.5. Master Request & Unsolicited Response Collision ........................................ 4-7
4.1.6. Function Codes .............................................................................................. 4-9
4.1.6.1. Request Function Codes ........................................................................ 4-9
4.1.6.2. Response Function Codes ................................................................... 4-11
4.1.7. Internal Indications ....................................................................................... 4-12
4.1.8. Object Header .............................................................................................. 4-14
4.1.8.1. Object Field........................................................................................... 4-14
4.1.8.2. Qualifier Field........................................................................................ 4-15
4.1.8.3. Range ................................................................................................... 4-18
4.1.8.3.1. Examples for messages without data objects............................... 4-18
4.1.8.3.2. Examples for messages with data objects.................................... 4-21
4.1.9. Detail Function Code Description................................................................. 4-24
4.1.9.1. CONFIRM (Function Code 0) ............................................................... 4-24
4.1.9.2. READ (Function Code 1)...................................................................... 4-24
4.1.9.3. WRITE (Function Code 2) .................................................................... 4-25
4.1.9.4. SELECT (Function Code 3).................................................................. 4-25
4.1.9.5. OPERATE (Function Code 4)............................................................... 4-25
4.1.9.6. DIRECT OPERATE (Function Code 5) ................................................ 4-25
4.1.9.7. DIRECT OPERATE - No Acknowledgement (Function Code 6).......... 4-25
4.1.9.8. IMMEDIATE FREEZE (Function Code 7)............................................. 4-26
4.1.9.9. IMMEDIATE FREEZE - No Acknowledgement (Function Code 8) ...... 4-26
4.1.9.10. FREEZE AND CLEAR (Function Code 9) ............................................ 4-26
4.1.9.11. FREEZE AND CLEAR - No Acknowledgement (Function Code 10) ... 4-26
4.1.9.12. FREEZE WITH TIME (Function Code 11)............................................ 4-27
4.1.9.13. FREEZE WITH TIME - No Acknowledgement (Function Code 12) ..... 4-27
4.1.9.14. COLD RESTART (Function Code 13) .................................................. 4-27
4.1.9.15. WARM RESTART (Function Code 14)................................................. 4-28

DA0-025-1.00 iii
DNPMxx Firmware Description Ax 1703

4.1.9.16. INITIALIZE DATA (Function Code 15) ................................................. 4-28

4.1.9.17. INITIALIZE APPLICATION (Function Code 16) ................................... 4-28
4.1.9.18. START APPLICATION (Function Code 17) ......................................... 4-28
4.1.9.19. STOP APPLICATION (Function Code 18) ........................................... 4-29
4.1.9.20. SAVE CONFIGURATION (Function Code 19)..................................... 4-29
4.1.9.21. ENABLE UNSOLICITED MESSAGES (Function Code 20)................. 4-29
4.1.9.22. DISABLE UNSOLICITED MESSAGES (Function Code 21)................ 4-29
4.1.9.23. ASSIGN CLASSES (Function Code 22) .............................................. 4-30
4.1.9.24. DELAY MEASUREMENT (Function Code 23)..................................... 4-30
4.1.10. CLASSES..................................................................................................... 4-30
4.1.11. Time Synchronization................................................................................... 4-31
4.1.12. Binary Input with Time Events...................................................................... 4-32

iv DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

1. Protocol Description

1.1. PCMBA-Modulation Procedure

Data is pulse-code modulated in groups of 8 bits each and is transmitted asynchronously. A

USART module in asynchronous mode provides each byte with a byte frame (BR).

This byte frame contains: 1 start bit

5-8 data bits
1/NO parity bit (even, odd parity)
1/1.5/2 stop bits

The frame start and stop bits are used to effect a new synchronisation of the receiving
station with each byte.

FB 5-8 BIT INFORMATION FB

A B C (D) E

LSB MSB

D1 D2 D3 D4

A: Off-circuit state of the line (binary information "1"), between two messages at least
33 bit (in case of error)
B: Start bit ("0")
C: 5-8 bit data (any frame data or message data), LSB (Least Significant Bit)
is transmitted first
D: Parity bit (NO/ODD/EVEN PARITY) (= configurable)
E: 1/1, 5/2 Stop bit(s) ("1") (= configurable)
T: Time for the transmission of a bit (1/transmission rate)
FB: Framing bits of the USART module

The DNP 3.0 protocol uses the following byte frame:

1 start bit
8 data but
No parity
1 stop bit

DA0-025-1.00 1-1
DNPMxx Firmware Description Ax 1703

1-2 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

2. Message Structure

DNP 3.0 is a protocol based on the IEC 60870-5 standards.

2.1. Physical Layer

─ RS-232
─ CCITT V.11, V.24, V.28, ...
─ Asynchronous transmission
─ Character (byte) oriented

2.2. Data Link Layer

The data link layer uses a standard variable length frame format as defined in the
IEC 870-5-1 Transmission Frame Formats document. The FT3 frame format class is well
suited for data transmission between stations that require medium information transfer rates
and low residual error probability.

DA0-025-1.00 2-1
DNPMxx Firmware Description Ax 1703

2.2.1. FT3 Frame

An FT3 frame is defined as a fixed length header block followed by optional data blocks.
Each block has a 16-bit CRC appended to it. The IEC specifies that the header fields consist
of 2 start octets, 1 octet length, 1 octet control, a destination address and an optional fixed
length user data field. In this implementation the fixed length user data field is defined as a
source address.

START 0x05

START 0x64

LENGTH

CONTROL

DESTINATION low fixed length header

block 0 DESTINATION high 10 bytes

SOURCE low

SOURCE high

CRC low

CRC high

USER

DATA

block 1

CRC low

CRC high
: body
:
USER

DATA

block n

CRC low

CRC high

Start

The Start field is 2 octets in length. The first octet is a 05 hexadecimal and the second octet
is a 64 hexadecimal.

Length

The length field is 1 octet in length and specifies the count of user octets in the frame. The
CONTROL, DESTINATION and SOURCE field sizes are included in this count. The
minimum value for this field is 5 and the maximum value is 255.

2-2 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

Control

The control field contains the direction of the frame, type of frame and flow control
information.

1 FCB FCV primary to secondary

DIR PRM -------- -------- FUNCTION CODE
0 RES DFC secondary to primary
Bit 7 6 5 4 3 2 1 0

DIR: The direction bit indicates the physical direction of the frame with relation to the
designated master station. Station A is the master.

DIR = 1 indicates a frame from A to B

DIR = 0 indicates a frame from B to A

PRM: The primary message bit indicates the direction of the frame in relation to the
initiating station.

PRM = 1 indicates a frame from the initiating station

PRM = 0 indicates a frame from the responding station.

FCB: The frame count bit is used for suppressing losses and duplication of frames to the
same secondary station. This bit toggles for each successful SEND-CONFIRM
service that is initiated by the same primary station and directed to the same
secondary station.

Initially before communications with a secondary station or after communication

failure, the primary station (in both the master station and outstation) must reset the
data link for each secondary station data link it wishes to communicate with. This can
be done once at data link start-up for all secondary stations or as needed.

Each secondary station, after data link start-up or transaction failure, must not accept
any primary SEND-CONFIRM messages with FCV set until a RESET command has
been received and a CONFIRM message sent.

FCV: The frame count valid bit enables the functioning of the FCB bit.

FCV = 0 indicates the state of the FCB bit is ignored

FCV = 1 indicates to a secondary station that the state of the FCB bit must be
checked against the state of the FCB bit of the last frame sent with the FCV
bit set.

DFC: The data flow control bit is used to prevent the overflowing of buffers in a secondary
station. The secondary station returns this bit set to a 1 if further SEND of user data
to this secondary station will cause data link buffers to over flow. The primary station
must interrogate the secondary station using REQUEST-RESPOND Request Link
Status until the DFC is returned with a value of 0. At this point the primary station can
continue with the sending of user data.

DA0-025-1.00 2-3
DNPMxx Firmware Description Ax 1703

FUNCTION CODE:

The function code identifies the type of frame. The definition of the values placed in this field
are different between primary and secondary stations. The following tables define the
implemented codes and associated FCV states.

Function Code Field Values of the Control Octet Sent from the Primary Station (PRM = 1).

Function Frame Type Service Function FCV

Code Bit

0 SEND - CONFIRM expected RESET of remote link 0

1 SEND - CONFIRM expected Reset of user process 0
2 SEND - CONFIRM expected TEST function for link 1
3 SEND - CONFIRM expected User Data 1
4 SEND - NO REPLY expected Unconfirmed User Data 0
5 Not Used -
6 Not Used -
7 Not Used -
8 Not Used -
9 REQUEST - RESPOND expected REQUEST LINK STATUS 0
10 Not Used -
11 Not Used -
12 Not Used -
13 Not Used -
14 Not Used -
15 Not Used -

Function Code Field Values of the Control Octet Sent from the Secondary Station (PRM = 0)

Function Frame Type Service Function

Code

0 CONFIRM ACK - positive acknowledgement

1 CONFIRM NACK - Message not accepted, Link busy
2 Not Used
3 Not Used
4 Not Used
5 Not Used
6 Not Used
7 Not Used
8 Not Used
9 Not Used
10 Not Used
11 RESPOND Status of Link (DFC = 0 or DFC = 1)
12 Not Used
13 Not Used
14 Link service not functioning
15 Link service not used or implemented

2-4 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

Destination Address

The Destination address field is 2 octets in size and specifies the address of the station that
the frame is directed to. The first octet of the address is the low order octet and the second
octet is the high order.

The address 0xffff is defined as an all stations address. All stations will accept frames with
the destination address set to this value.

LOW ORDER OCTET (LSB) HIGH ORDER OCTET (MSB)

Source Address

The source address field is 2 octets in size and specifies the address of the station that the
frame originated from. The first octet of the address is the low order octet and the second
octet is the high order.

LOW ORDER OCTET (LSB) HIGH ORDER OCTET (MSB)

User Data

The blocks following the header may contain from 1 to 16 octets of user data. If more than 16
user data octets follow the header (block 0), each block must contain 16 octets of data
except for the last block. The last block will contain the leftover. Each data block has a CRC
appended to it.

The data link layer passes all of the user data and the source address from the header to the
higher layers when a SEND user data frame is received. The data link service primitives
provide a place to put the source address.

CRC Fields

A two octet cyclic redundancy check is appended to each block in a frame. The START,
LENGTH, CONTROL, DESTINATION and SOURCE fields are all included when calculating
the CRC for the header.

The 2 octet CRC check is generated from the following polynomial and then inverted before
being placed in the block for transmission:

X16 + X13 + X12 + X11 + X10 + X8 + X6 + X5 + X2 + 1

Using the FT3 frame format class and CRC, the frame has a Hamming distance of 6.

The diagram below shows the ordering of the 16-bit CRC check word with respect to any
blocks (user data or header).

LSB MSB

BLOCK OCTETS CRC

DA0-025-1.00 2-5
DNPMxx Firmware Description Ax 1703

2.2.2. Data Link Function Codes

2.2.2.1. Reset

This function code is used to synchronize a primary and secondary station for further SEND-
CONFIRM transactions. Upon reception and reply to a RESET command, the secondary
station will begin accepting Primary messages from that Primary station with the FCV bit set.
The RESET command only enables communications in one direction, from the primary to the
secondary station. This is because a successful transaction only guarantees that the primary
station transmitter and the secondary station receiver are communicating. The primary
station must send this function code when it wishes to first communicate with the secondary
station or after a communications failure has been recognized by the primary station. When a
secondary station has re-started or when a communications failure has been recognized by
the secondary, the secondary station will be considered un-reset. In this state, the secondary
station will not accept messages from the primary station until it has received and replied to a
RESET command from that primary station.

The RESET command also synchronizes the FCB bit between primary and secondary
stations. The secondary station after completing the RESET transaction will expect the FCB
bit in the next message (with FCV valid) to be 1 from that primary station. The primary station
after completing the RESET transaction will set the FCB bit to 1 in the next message (with
FCV valid) to that secondary station.

2.2.2.2. Reset of User Process

This function code is used to reset the data link user process. Upon reception by a secondary
station, an INDication should be sent to the data link user. The data link user can use this
indication to reset its internal state. If accepted by the data link user, an ACK confirm frame is
sent in reply otherwise a NACK confirm frame is sent in reply.

2.2.2.3. Test

The TEST command is used to test the state of the secondary data link. Upon reception by a
secondary station, it checks the value of the FCB bit in the primary message and compares it
against the FCB status (expected FCB) for that primary station. If the FCBs do not match,
then the secondary station should send the last secondary confirm frame. Otherwise, an ACK
confirm frame should be sent in reply and the expected FCB status should be toggled. The
secondary station also sets the DFC bit accordingly in the response.

2.2.2.4. User Data

The User Data function is used to send confirmed data to a secondary station. Before
communications can begin, the secondary station must have been RESET according to the
rules above (see RESET). The frame sent contains the user data from the primary data link
user that is to be passed to the data link user of the secondary station.

2.2.2.5. Unconfirmed User Data

This function is used to send user data to the secondary station without needing
confirmation.

2-6 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

2.2.2.6. Request Link Status

This command is used to request the status of the secondary data link. A secondary station
will respond to this request with a LINK STATUS confirm frame with the DFC bit set to 1 if the
data link is busy or the data link user cannot accept any more user data and 0 indicating that
the data link is not busy and the data link user can accept more user data. The transmission
procedures are similar to TEST except that the primary station will typically only use this
command when a NACK frame is received during a User Data transaction.

DA0-025-1.00 2-7
DNPMxx Firmware Description Ax 1703

2-8 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

3. Transport Function

This section describes the Transport layer functions which act as a pseudo-transport layer to
the DNP data link layer. The pseudo-transport layer function is specific only for those
messages that are larger than one Link Protocol Data Unit (LPDU) between primary and
secondary stations.

LSDUs are user data fragments which are small enough to fit into the defined FT3 frame
format. When a primary station transmits a message to a secondary station, the transport
functions break the message into LSDUs. These functions add a Transport layer Header
(TH) octet at the beginning of the user data fragments that contain the information for the
secondary station to reconstruct the complete message. All pseudo-transport layer
messages have a TH.

The TH contains information that can identify the first frame, last frame and give every frame
a six-bit sequence number. This information is required to reconstruct a message and also to
guard against higher layers from receiving misdirected or incomplete messages.

DA0-025-1.00 3-1
DNPMxx Firmware Description Ax 1703

3.1. Transport Header

When an application requests the transmission of a long message, the message is broken
into fragments small enough to fit in a single DNP V3.00 Data Link frame. The maximum size
of a fragment is 249 octets of user data. The TH is added to the head of the fragment and
the maximum number of octets to be framed becomes 250 octets.

Maximum data link data count + 255 octets

Data link header data count -5 octets
Transport header -1 octet
Application user data = 249 octets

FIN FIR SEQUENCE

Bit 7 6 5 4 3 2 1 0

FIN: The final bit indicates that this frame of user data is the last frame of a sequence in a
complete user message.

FIN = 0 indicates more frames follow.

FIN = 1 indicates the final frame of a sequence.

FIR: The first bit indicates that the frame is the first in a sequence of frame(s) which
comprise a complete message. When a secondary station receives a frame with the
FIR bit set, all previously received unterminated frame sequences are discarded. The
first frame of a sequence may have any sequence from 0 to 63.

If a frame is received without the FIR bit set and no message sequence is currently in
progress, then the frame is ignored.

If a complete user message is only one frame in length, both the FIR and FIN bits
are set.

FIR = 1 First frame of a sequence.

FIR = 0 Not the first frame of a sequence.

SEQUENCE: The sequence number of the frame is used to check that each frame is being
received in sequence. It guards against missing or duplicated frames. All
user messages start off with a sequence specified in the first frame which
has the FIR bit set (each message may start with any sequence number
between 0 and 63). After sequence number 63 the next sequence number
will be 0.

The sequence number increments for each frame sent to or received from the same address
belonging to the same message and resets at the beginning of a new message. The
sequence number does not have to increment across message boundaries, i.e. any
sequence number is valid when the FIR bit is set.

3-2 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

3.1.1. Frame Assembling

The following example illustrates the assembling of a three-frame message. The first frame
of the message identified by having the FIR bit set in the TH field. The last frame is identified
by having the FIN bit set in the TH field.

USER DATA FRAMES TRANSPORT DATA BUFFER

FIR = 1
FIN = 0 Note sequence starts with the value in the frame that has the FIR bit = 1
SEQUENCE = 3
USER DATA 0

USER DATA 0

FIR = 0
FIN = 0
SEQUENCE = 4
USER DATA 1

USER DATA 1

USER DATA 0

FIR = 0
FIN = 1
SEQUENCE = 5
USER DATA 2

USER DATA 2

USER DATA 1

USER DATA 0 complete message passed to application

DA0-025-1.00 3-3
DNPMxx Firmware Description Ax 1703

3-4 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4. Application Layer

This section defines the formats of the application layer messages (APDU). The terms APDU
and fragment are interchangeable. In this specification the master station is defined as the
station sending a request message and the Outstation is the slave device, Remote Terminal
Unit (RTU) or Intelligent End Device (IED) to which the requested messages is destined. In
DNP, only designated master stations can send Application Layer request messages and
only Outstations can send Application Layer Response messages.

The following figure shows the sequence of Application Layer messages between one
master and one Outstation.

MASTER OUTSTATION

Send Request Accept request and process

Send optional confirmation

Accept Response Send Response

Send optional confirmation

Important change detected

Accept Response Send unsolicited Response

Send optional confirmation

As shown above, the master station sends an Application Layer Request to the outstation
which returns an Application Layer Response. The outstation can decide to spontaneously
transmit data using an Application Layer Unsolicited Response message. For a master, a
request/response transaction with a particular outstation must be completed before another
requests can be sent to that outstation. A master station may accept unsolicited responses
while the request transaction is in progress. For an outstation, a request/response
transaction must be completed before any other requests are accepted or unsolicited
responses are sent. Unsolicited responses can be sent before or after the request/response
transaction but not during. If an outstation is presently in the middle of an unsolicited
transaction (i.e. waiting for a confirmation), it may conditionally accept one request command
from the master.

DA0-025-1.00 4-1
DNPMxx Firmware Description Ax 1703

4.1.1. Application Request Format

Application request message format (APDU):

DUI IO IO DUI IO

request header object header data object header data

APCI ASDU

The APDU is made up of an APCI block which contains message control information and an
ASDU which contains information to be processed by the receiving station. The APCI is often
called a request header in an application request message. In DNP, the ASDU is optional
and is used when the message meaning is not conveyed completely in the request header.
The request header contains information on how to assemble a multi-fragment message and
on the purpose of the message. The request header is present in all application layer request
APDUs. If the request header implies all the needed information required to carry out the
request, the ASDU is not present.

Each ASDU consists of one or more Data Unit Identifers (DUI) or object headers and
optional associated Information Objects (IO) or data fields.

4.1.2. Application Response Format

Response from a outstation to an application layer request APDU or the unsolicited response
from an outstation have the following format:

DUI IO IO DUI IO

response header object header data object header data

APCI ASDU

The format is identical in form to the request. The APCI is often called a response header in
an application response message. The response header contains the same information as
the request header plus an additional field containing internal indications of the outstation.
The response header is always part of the application response.

4-2 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4.1.3. Application Header

4.1.3.1. Request Header

The request header or APCI has two fields. Each field is one octet in length and is illustrated
below.

0 1 Bytes

Application Control Function Code

AC FC

4.1.3.2. Response Header

The response header has three fields as illustrated below.

0 1 2 3 Bytes

Application Control Function Code Internal Indications

AC FC IIN

DA0-025-1.00 4-3
DNPMxx Firmware Description Ax 1703

4.1.3.3. Application Control

The application control field has a size of one octet. It provides information needed to
construct multi-fragment application messages.

Application messages may be packaged into fragments, with each fragment small enough to
fit into the application's message buffer. The recommended size of the fragment buffer is
adjustable. Each fragment has an application header and appropriate object headers so that
each fragment can be processed as individual messages which can then be discarded
making room for the next fragment.

7 6 5 4 3 2 1 0 bit

FIR FIN CON SEQUENCE

FIR If set to one (1), this bit indicates the message fragment is the first fragment
of a complete application message.

FIN If set to one (1), this bit indicates the message fragment is the final fragment
of a complete application message.

CON If set to one (1) in a received message, indicates the sending application is
expecting a confirmation from the receiving application of the reception of the
fragment. An application function code zero (0) is used in the confirmation
message.

SEQUENCE Indicates the fragment number. Fragment numbers 0 to 15 are reserved for
master station requests and all Outstation responses (NOT Unsolicited
Responses). Fragment numbers 16 to 31 are reserved for unsolicited
responses from Outstations. For unsolicited responses, each consecutive
fragment from an Outstation must have an increasing sequence number (the
number overflows from 31 to 16). For requests to an Outstation and the
Outstation responses (not unsolicited responses), each consecutive
fragment received from or transmitted to the same Outstation must have an
increasing sequence number (the number overflows from 15 to 0).

NOTE: An Unsolicited Response is a message generated by an Outstation, usually

containing event data, which is sent automatically to the master. The master
does not need to poll the Outstation for this data.

NOTE: It is recommended that any changed data that is reported from an Outstation
be sent with a confirmation requested in the response.

4-4 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4.1.4. Communication Flow Control

The flow of requests and responses between the master and the Outstation is controlled by
fields in the response and request headers as well as application timers and parameters. The
fields, timers and parameters controlling message flow are:

1) CON bit field. Setting/clearing this bit enables/disables message CONFIRMation

responses. A CONFIRMation response is an application acknowledgments of the
previous request or response message.

2) FIR and FIN bit fields.

3) Sequence Number field. This number is used to assemble multi-fragment messages and
identify which responses match particular requests.

4) Master station and Outstation application response time-outs. These specify how long an
application must wait for a response or CONFIRMation response before re-transmitting or
aborting the transaction. The application may or may not support re-transmission of
transactions at the application layer.

5) Master station and Outstation application retry count. Applications may or may not support
application level retries. Retry counters specify how many times a request is repeated if a
response fails, or how often responses are re-transmitted if a CONFIRMation response is
not received.

An Outstation must completely process a request and respond to it before beginning to

process a second request. It cannot simultaneously process multiple requests.

The Sequence Number for all requests from the master station to the Outstation is in
the range 0 to 15 inclusive. The sequence number for all Unsolicited Responses from
the Outstation is in the range 16 to 31 inclusive.

The following rules dictate how sequence numbers work:

─ The sequence number rolls over from 15 to 0 or from 31 to 16. Each successive request
fragment from the DNP master station has an incremented sequence number. The
exception is for retries on requests. For single fragment request retries, the sequence
number is NOT incremented. For multi fragment request retries, the sequence number of
the first fragment of the request retry equals the sequence number of the last fragment of
the request which has just failed.

─ A single fragment response to a single fragment request has the same sequence number
as the request.

─ The CONFIRMation response to a request or response has the same sequence number
as the request or response.

─ The first fragment of a multi-fragment response to a single fragment request has the
same sequence number as the request. For successive fragment of the multi-fragment
response, the sequence number is incremented.

─ The first fragment of a multi-fragment response to a multi-fragment request has the same
sequence number as the last fragment of the multi-fragment request.

DA0-025-1.00 4-5
DNPMxx Firmware Description Ax 1703

The use of this sequence number scheme ensures the Outstation and master station can
cope with all occurrences of messages being lost or delayed on a communication network.
The following rules are obeyed by both the Outstation and master station:

─ If the system uses application level retries, when a response is not received before time-
out, the request will be re-transmitted with the same sequence number.

─ If two messages are received with the same sequence number, it usually means that the
response to the message was not received by the other station. In this case, retransmit
the response (re-processing the message is unnecessary).

─ If two CONFIRMation responses are received with the same sequence number, ignore
the second response.

4-6 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4.1.5. Master Request & Unsolicited Response Collision

When Unsolicited Responses are generated by an Outstation there exists the possibility that
the master station sends a request at the same time that the Outstation sends an Unsolicited
Response. The Outstation may receive the request when it expects to receive a
CONFIRMation of its Unsolicited Response. The master receives the Unsolicited Response
when it expects to receive a response to its request.

The processing of the above and similar situation depends on the type of request issued by
the master station.

The master station will always process an Unsolicited Response immediately, ever if it
arrives when the master station is expecting a response to a previously issued request. A
CONFIRMation of the Unsolicited Response is issued immediately if requested by the
Outstation (i.e. if CON bit is set).

The Outstation will generally process a request immediately, even if it is waiting for
CONFIRMation of a previous Unsolicited Response. All requests except READ requests for
system data (e.g. Binary input data, counter event data etc.) are processed in this way. This
mode of operation is referred to as IMMEDIATE_PROCESS mode.

The Outstation will NOT process a master station READ request if it is waiting for
CONFIRMation of a previous Unsolicited Response. It will wait for the CONFIRMation before
processing the request. The reason for the different functionality is to prevent the loss or
duplication of data events. This mode of operation is referred to
PROCESS_AFTER_CONFIRM mode.

Example for IMMEDIATE_PROCESS mode:

Time

Request.
Master
Response CONFIRM CONFIRM
expected. (Seq = 7) (Seq = 24)
(CON = 0)
(Seq = 7)

Out- Unsol. Response

station Response to master
(CON = 1) request
(Seq = 24) (CON = 1)
(Seq = 7)

DA0-025-1.00 4-7
DNPMxx Firmware Description Ax 1703

Example for PROCESS_AFTER_CONFIRM mode:

Time

Request. CONFIRM to
Master
Response Unsol. CONFIRM
expected. Response (Seq = 2)
(CON = 0) (Seq = 18)
(Seq = 2)

Out- Unsol. RTU waits RTU now

station Response for CONFIRM. processes Response
(CON = 1) Do not process master (CON = 1)
(Seq = 18) Request. request. (Seq = 2)

4-8 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4.1.6. Function Codes

The function code identifies the purpose of the message. The size of this field is one octet.
There are two groups of function codes; one for requests and the other for responses.

4.1.6.1. Request Function Codes

CODE FUNCTION DESCRIPTION SUPPORTED

BY DNPM00

Transfer Function Codes

0 confirm Message fragment confirmation used in both

requests and responses. No response to this

message is required.

1 read Request specified objects from outstation;

respond with objects requested that are available.

2 write Store specified objects in outstation; respond with
status of the operation

Control Function Codes

3 select Select or arm output points but do not set or

produce any output action (controls, setpoints,
analog outputs) ; respond with the status of the
control points selected. The operate function code

is required to activate these outputs.

4 operate Set or produce the output actions on the points

previously selected with the select function;

respond with the status of the control points.

5 direct operate Select and set or operate the specified outputs;

respond with the status of the control points.

6 direct operate Select and set or operate the specified outputs
- No Acknowledgment but do not send a response to the request.

DA0-025-1.00 4-9
DNPMxx Firmware Description Ax 1703

CODE FUNCTION DESCRIPTION SUPPORTED

BY DNPM00

Freeze Function Codes

7 immediate freeze Copy the specified objects to a freeze buffer and

respond with status of the operation. X

8 immediate freeze Copy the specified objects to a freeze buffer; do

-No Acknowledgment not respond with a message.

9 freeze and clear Copy the specified objects to a freeze buffer, then
clear the objects; respond with the status of the X
operation.

10 freeze and clear Copy the specified objects to a freeze buffer, then
-No Acknowledgment clear the objects; do not respond with a message.

11 freeze with time Copy the specified objects to a freeze buffer at
the specified time and intervals; respond with the X
status of the operation.

12 freeze with time Copy the specified objects to a freeze buffer at

-No Acknowledgment the specified time and intervals; do not respond X
with a message.

Application Control Function Codes

13 cold restart Perform the desired reset sequence; respond with

a time object indicating time till Outstation X
availability.

14 warm restart Perform the desired partial reset sequence;

respond with a time object indicating time till X
Outstation availability.

15 initialize data to defaults Initialize the specified data to power up initial

values; respond with status of the operation. X

16 initialize application Ready the specified application(s) to run; respond

with status of the operation. X

17 start application Start running the specified application(s); respond

with status of the operation. X

18 stop application Stop the specified application(s); respond with X

status of the operation.

4-10 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

CODE FUNCTION DESCRIPTION SUPPORTED

BY DNPM00

Configuration Function Codes

19 save configuration Save the specified configuration to non-volatile

memory; respond with a time object indicating X
time till Outstation availability.

20 enable unsolicited Enable spontaneous reporting of the specified

messages data object(s); respond with status of the

operation

21 disable unsolicited Disable spontaneous reporting of the specified

messages data object(s); respond with status of the

operation

22 assign class Assigned specified data object(s) to a particular

class X

Time Synchronization Function Codes

23 delay measurement Allows the application to calculate the path delay

(or propagation delay) for a particular outstation.
The value calculated from this function code
should be used to adjust the time of day when

setting the outstation time.

Reserved

24 - 120 Reserved for future use X

121 - 128 Reserved for testing only X

4.1.6.2. Response Function Codes

CODE FUNCTION DESCRIPTION SUPPORTED

BY DNPM00

Response Function Codes

0 confirm Message fragment confirmation used in both

requests and responses. No response to this

message is required.

129 response Response to a request message X

130 unsolicited message Unsolicited response that was not prompted by a

request. X

DA0-025-1.00 4-11
DNPMxx Firmware Description Ax 1703

4.1.7. Internal Indications

The Internal Indications (IIN) field is a two-octet field that follows the function code in all
responses. When a request cannot be processed due to formatting errors or the requested
data is not available, the IIN is always returned with the appropriate bits set.

first octet second octet

7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

Definition of the first octet:

Bit 0 - All stations message received

- Set when a request is received with the destination address of the all stations
address (ffff hexadecimal).
- Cleared after next response (even if response to global request is required)
- Used to let the master station know that a Broadcasted message was received by
this station.

Bit 1 - Class 1 data available

- Set when data that has been configured as Class 1 data is ready to be sent to the
master
- Master station should request this class data from the Outstation when this bit is
set in a response

Bit 2 - Class 2 data available

- Set when data that has been configured as Class 2 data is ready to be sent to the
master
- Master station should request this class data from the Outstation when this bit is
set in a response

Bit 3 - Class 3 data available

- Set when data that has been configured as Class 3 data is ready to be sent to the
master
- Master station should request this class data from the Outstation when this bit is
set in a response

Bit 4 - Time-synchronization required from the master. The master synchronizes the
time by writing the Time and Date object to the Outstation.
- Cleared when the time is set by the master. This bit is also cleared when the
master explicitly writes a 0 into this bit of the Internal Indication object of the
Outstation.

Bit 5 - Set when some or all of the Outstation's digital output points are in the Local
state. That is, the Outstation's control outputs are NOT accessible through the
DNP protocol.
- Clear when the Outstation is in the Remote state. That is, the Outstation's control
outputs are accessible through the DNP protocol.

4-12 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

Bit 6 - Device trouble

- Set when an abnormal condition exists at the Outstation. The device profile for a
given device states the conditions that effect this bit.
- This should only be used when the state can not be described by a combination
of one or more of the other IIN bits.

Bit 7: - Device restart

- Set when the user application at the Outstation restarts.
- Cleared when the master explicitly Writes a 0 into this bit of the Internal
Indications object in the Outstation.

Definition of the second octet:

Bit 0 - Function code not implemented

Bit 1 - Requested object(s) unknown. The Outstation does not have the specified objects
or there are no objects assigned to the requested class.
- This indication should be used for debugging purposes and usually indicates a
mismatch in device profiles or configuration problems.

Bit 2 - Parameters in the qualifier, range or data fields are not valid or out of range. This
is a catch-all for application request formatting errors.
- This indication should be used for debugging purposes and usually indicates
configuration problems.

Bit 3 - Event buffer(s), or other application buffers have overflowed. For example,
COS/SOE buffers have overflowed.
- The master should attempt to recover as much data as possible and indicate to
the user that their may be lost data. The appropriate error recovery procedures
should be initiated by the user.

Bit 4 - Request understood but requested operation is already executing.

Bit 5 - Set to indicate that the current configuration in the Outstation is corrupt and that
the master application layer should inform the user of this exception. The master
may download another configuration to the Outstation. Note that sometimes a
corrupt configuration will disable an Outstation, making it impossible to
communicate this condition to a master station.

Bit 6 - Reserved for use by agreement, currently always returned as zero (0).

Bit 7 - Reserved for use by agreement, currently always returned as zero (0).

DA0-025-1.00 4-13
DNPMxx Firmware Description Ax 1703

4.1.8. Object Header

The object header of a message specifies the data objects (or IOs) that are either contained
in the message or are to be used to respond to this message. The format of the object
header is identical for a request and a response but the interpretation of the header is
dependent on whether it is a request or a response and which function code accompanies
the header.

object qualifier range

object header

Object Specifies the object group and variation of the objects that follow the header. This
is a two-octet field. The object field uniquely identifies the type or class of object
which gives the structure (and hence size) of the data object.

Qualifier Specifies the meaning of the range field. This is a one-octet field. The qualifier
specifies how the range field is to be interpreted.

Range Indicates the quantity of objects, starting and ending index or identifiers for the
objects in question. This field uniquely identifies the objects in question.

The range field may not be present if the qualifier specifies that there is no range
field. The size of this field ranges from zero (0) octets to eight octets.

4.1.8.1. Object Field

The Object field specifies an object group and the variation of the object within the group.
The combined object group plus variation specifies uniquely the object to which the message
refers.

Objects may be assigned to one of four classes. When the Object field specifies a data class
instead of a specific object type, the object field refers indirectly to all the data objects
assigned to that class of data and not to any specific object type.

The object field is two octets in length. The first octet specifies the general type of data (e.g.
analog inputs) and the second octet specifies the variation of the data type (e.g. 16-bit analog
inputs or 32-bit analog inputs). In the request direction, if the object variation is specified as 0,
this indicates all object variations belonging to the same group (i.e. all or any analog inputs
types). In the response direction however, variation 0 cannot be used to specify the objects.
The specific variation has to be specified.

first octet second octet

0 or object variation request direction

object group
object variation response direction

4-14 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4.1.8.2. Qualifier Field

The qualifier field specifies the meaning of the range field.

7 0

R index size 4 bit qualifier code

R: Reserved bit always set to 0

The Range Field is used to index data or as an identifier. The structure and use of the Range
Field is dependent on the value in the Index Size field and the Qualifier Code field. When the
Range Field is used to index data, it often consists of a Start Range value and an Stop
Range value. Together they define a range of objects in the data following the Object
Header. Each of the Start Range and Stop Range sub-fields is termed as index.

Index Size (3-bits)

• In a Request Object Header when Qualifier Code equals 11

The Index Size bits are valid only when the qualifier code is 11. These bits indicate the
size, in octets, of each entry in the Range Field. The Range Field follows the Qualifier
Field. The Range Field consists of indices (to specify a range of objects) or object
identifier lists (see qualifier code 11).

0= not valid with qualifier code 11

1= 1 octet identifier size
2= 2 octet identifier size
3= 4 octet identifier size
4= reserved
5= reserved
6= reserved
7= reserved

• In a Response or Request Object Header that is part of a message containing data

objects.

The 3 bit Index Size field specifies the size of the indices or object size prefixing each
object.

0= objects are packed with no index prefixing them

1= objects are prefixed with a 1 octet index
2= objects are prefixed with a 2 octet index
3= objects are prefixed with a 4 octet index
4= objects are prefixed with a 1 octet object size
5= objects are prefixed with a 2 octet object size
6= objects are prefixed with a 4 octet object size
7= reserved

DA0-025-1.00 4-15
DNPMxx Firmware Description Ax 1703

Qualifier Code (4-bits)

The Qualifier Code is used to specify the meaning of the Range field.

• Start and Stop Sub-Fields in the Range Field

The Range field following the Qualifier field often contains sub-fields (Start Range and
Stop Range) that designate a range of integer values starting numerically from Start
Range (including the number Start Range) to Stop Range (including the number Stop
Range).

For Qualifier Codes 0, 1 and 2, Start Range and Stop Range are interpreted as indices of
data

For Qualifier Codes 3, 4 and 5, Start Range and Stop Range are interpreted as virtual
memory addresses.

The Qualifier Code can be used both in the request and response messages as it can
uniquely identify data objects whether they do or do not exist in the message.

The Index Size field should be 0 in a data-less message to indicate no further indexing.
The Index Size field can be 4, 5 or 6 in a message with data objects to indicate that each
data object (with indices specified by the Range Field) has an object size prefix (with this
size determines by the Index size). A message with data can also use Index size of 0 to
indicate no more indexing. For Qualifier Codes specifying Start ad Stop Indices in the
Range, Index Size values of 1, 2 and 3 cannot be used.

Some Qualifier Code definitions are:

0= 8 bit start and stop indices in the Range Field

1= 16 bit start and stop indices in the Range Field
2= 32 bit start and stop indices in the Range Field
3= 8 bit absolute address identifiers in the Range
4= 16 bit absolute address identifiers in the Range
5= 32 bit absolute address identifiers in the Range

• All objects of the given object type

When the Qualifier Field equals 6, the length of the range field is 0 (i.e. no range field)
because all the data objects of the specified type are being referred to. This qualifier can
be used in messages with object headers only because it cannot uniquely identify data
objects if they are present in the message. The Index size should be set to 0 when this
Qualifier code is used.

Qualifier Code 6 = no range field (implies all the specified objects)

4-16 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

• Single field quantity

Qualifier Codes 7, 8 and 9 are used to indicate that the Range Field consists of a single
count indicating the number of data objects in question. The Range Field that follows
designates the number of objects referenced.

If the Index Size field equals zero, the Range Field specifies the number of objects
referenced starting numerically from 0 (including 0) to the value in the Range Field
minus 1.

If the Index Size is 1, 2 or 3 then the Range Field specifies the number of indices and
objects following the Range Field.

Qualifier Codes 7, 8 and 9 can be used in the request and response messages. In a
message with or without data objects, the value in the Range Field specifies the number
of data objects to be referred to. The Index Size field should be set to the size of the
indices that either pre-fix each data object (for messages with data objects) or that form a
sequential list of identifiers.

The Index Size field should not indicate an object size identifier as this would not uniquely
specify the data objects in question and should be set to 0 if no identifiers or indices are
following. The order of identifiers (and optional data objects) is arbitrary but should not
consist of duplicate indices.

Some Qualifier Code definitions are:

7 = 8 bit single field quantity

8 = 16 bit single field quantity
9 = 32 bit single field quantity

• Free-format Qualifier (Qualifier Code 11)

This Qualifier Code is used to specify objects when other Qualifier Codes are inadequate
or do not provide enough identifying information.

Qualifier 11 is used only when the Range Field (index) cannot uniquely specify the data
objects in question. In this case, the Qualifier Code defines a variable length array of
octets (string) that contains the object identifier.

This identifier has a free-format and will not be interpreted in any way by the application
layer at this time.

The Range Field is always a 1 octet value (Count) which specifies the number of object
identifiers. Following the Range Field are Count object size field/object identifier pairs.
The size of the identifier (in octets) is determined by the object size field which prefixes
each identifier. The size of the object size field is determined by the Index size. Index
sizes 4,5, and 6 should be used to specify the size of the object size field in octets.

DA0-025-1.00 4-17
DNPMxx Firmware Description Ax 1703

• Reserved Qualifier Codes

The following Qualifier Code values are reserved and should not be used:

10 = reserved
12 = reserved
13 = reserved
14 = reserved
15 = reserved

4.1.8.3. Range

The meaning of the Range Field is specified by the Qualifier Field. For Qualifier Codes 0 to 5
the Range field has 2 sub-fields specifying a start and stop index or address. The values in
these fields are inclusive. The Range field is not present for qualifier code 6. The range field
is a single field specifying a quantity for qualifier codes 7, 8, 9 and 11. In the following, the
term 'Q-code' refers to the 4 bit Qualifier Code field and 'I-size' refers to the Index Size field.

4.1.8.3.1. Examples for messages without data objects

The following examples illustrates the using of the range-field for messages without data
objects.

• Q-code = 0 and 3, I-size MUST be 0:

start stop
8 bit 8 bit Points are I1 to I2 inclusive
I1 I2

• Q-code = 1 and 4, I-size MUST be 0:

LSB MSB LSB MSB

16 bit start I1 16 bit stop I2 Points are I1 to I2 inclusive

• Q-code = 2 and 5, I-size MUST be 0:

LSB MSB LSB MSB

32 bit start I1 32 bit stop I2 Points are I1 to I2 inclusive

• Q-code = 6: describing all points of the given data type.

There is no range-field or indices with this qualifier.

4-18 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

• Q-code = 7, I-size = 0

Quan.
8 bit Points are 0 to Q-1 inclusive
Q

• Q-code = 7, I-size = 1

Quan. Index Index ..... Index

8 bit 8 bit 8 bit 8 bit Points are I1, I2...IQ inclusive
Q I1 I2 ..... IQ

• Q-code = 7, I-size = 2

Quan. LSB MSB LSB MSB ..... LSB MSB

8 bit Index 16 bit I1 Index 16 bit I2 Index 16 bit IQ Points are I1, I2...IQ inclusive
Q .....

• Q-code = 7, I-size = 3

Quan. LSB MSB LSB MSB ..... LSB MSB

8 bit Index 32 bit I1 Index 32 bit I2 Index 32 bit IQ
Q .....
Points are I1, I2...IQ inclusive

• Q-code = 8, I-size = 0

LSB MSB
Quan. 16 bit Q Points are 0 to Q-1 inclusive

• Q-code = 8, I-size = 1

LSB MSB Index Index ..... Index

Quan. 16 bit Q 8 bit 8 bit 8 bit Points are I1, I2...IQ inclusive
I1 I2 ..... IQ

• Q-code = 8, I-size = 2

LSB MSB LSB MSB LSB MSB ..... LSB MSB

Quan. 16 bit Q Index 16 bit I1 Index 16 bit I2 Index 16 bit IQ Points are I1, I2...IQ inclusive
.....

DA0-025-1.00 4-19
DNPMxx Firmware Description Ax 1703

• Q-code = 8, I-size = 3

LSB MSB LSB MSB LSB MSB .....

Quan. 16 bit Q Index 32 bit I1 Index 32 bit I2
.....

..... LSB MSB

Index 32 bit IQ Points are I1, I2...IQ inclusive
.....

• Q-code = 9, I-size = 0

LSB MSB
Index 32 bit IQ Points are 0 to Q-1 inclusive

• Q-code = 9, I-size = 1

LSB MSB Index Index ..... Index

Quantity 32 bit Q 8 bit 8 bit 8 bit Points are I1, I2...IQ inclusive
I1 I2 ..... IQ

• Q-code = 9, I-size = 2

LSB MSB LSB MSB LSB MSB ..... MSB

Quantity 32 bit Q Index 16 bit I1 Index 16 bit I2 Index 16 bit IQ
.....
Points are I1, I2...IQ inclusive

• Q-code = 9, I-size = 3

LSB MSB LSB MSB LSB MSB .....

Quantity 32 bit Q Index 32 bit I1 Index 32 bit I2
.....

..... LSB MSB

Index 32 bit IQ Points are I1, I2...IQ inclusive
.....

• Q-code = 11, I-size = 1

Use qualifier 11 when describing points that need to be uniquely identified by an object
identifier such as a File Object Identifier or Configuration Header. The type of identifier is
implied by the object type:

Quan. Size ..... ..... Size .....

8 bit 8 bit 011 012 01N 8 bit 0Q1 0QN
Q N1 ..... ..... NQ .....

4-20 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

• Q-code = 11, I-size = 2

LSB MSB LSB MSB ..... ..... LSB MSB .....

Quan. 16 bit Q Size 16 bit N1 011 012 01N Size 16 bit NQ 0Q1 0QN
..... ..... .....

• Q-code = 11, I-size = 3

LSB MSB LSB MSB ..... .....

Quantity 32 bit Q Size 32 bit N1 011 012 01N
..... .....

..... LSB MSB .....

Size 32 bit NQ 0Q1 0QN
..... .....

4.1.8.3.2. Examples for messages with data objects

The following examples illustrates the using of the range field for messages with data
objects.

• Q-code = 0 and 3, I-size = 0

Start Stop D0 D0 D0 ..... D0

8 bit 8 bit Points/objects are I1 to I2 inclusive
I1 I2 I1 I1 + 1 I1 + 2 ..... I2

• Q-code = 1 and 4, I-size = 0

LSB MSB LSB MSB D0 D0 D0 ..... D0

start 16 bit I1 stop 16 bit I2 Points/objects are I1 to I2 inclusive
I1 I1 + 1 I1 + 2 ..... I2

• Q-code = 2 and 5, I-size = 0

LSB MSB LSB MSB D0 D0 ..... D0

start 32 bit I1 stop 32 bit I2
I1 I1 + 1 ..... I2
Points/objects are I1 to I2 inclusive

• Q-code = 0 and 3, I-size = 4

start stop object D0 with ..... object D0 with

8 bit 8 bit size size S1 size size S2 Points/objects are I1 to I2 inclusive
I1 I2 8 bit S1 I1 ..... 8 bit S2 I2

Note: 16- and 32-bit object sizes can also be used by using I-size = 5 and 6.

DA0-025-1.00 4-21
DNPMxx Firmware Description Ax 1703

• Q-code = 1 and 4, I-size = 5

LSB MSB LSB MSB LSB MSB D0 with ..... LSB MSB D0 with
start 16 bit I1 stop 16 bit I2 object size size S1 object size size S2
16 bit S1 I1 ..... 16 bit S2 I2
Points/objects are I1 to I2 inclusive

Note: 8- and 32-bit object sizes can also be used by using I-size = 4 and 6.

• Q-code = 2 and 5, I-size = 6

LSB MSB LSB MSB LSB MSB D0 with .....

start 32 bit I1 stop 32 bit I2 object size 32 bit S1 size S1
I1 .....

..... LSB MSB D0 with

object size 32 bit S2 size S2 Points/objects are I1 to I2 inclusive
..... I2

Note: 8- and 16-bit object sizes can also be used by using I-size = 4 and 5.

• Q-code = 6: Do NOT use Q-code = 6 for describing a message which contains data
objects as the exact number of points are not known and therefore the
contents of the message cannot be determind.

• Q-code = 7, I-size = 0

Quan. D0 ..... D0
8 bit Points/objects are 0...Q-1 inclusive
Q I(0) ..... I(Q-1)

• Q-code = 7, I-size = 1

Quan. Index D0 ..... Index D0

8 bit 8 bit 8 bit Points/objects are I1, I2...IQ inclusive
Q I1 I1 ..... IQ IQ

• Q-code = 7, I-size = 2

Quan. LSB MSB D0 ..... LSB MSB D0

8 bit Index 16 bit I1 Index 16 bit I2 Points/objects are I1, I2...IQ inclusive
Q I1 ..... I2

• Q-code = 7, I-size = 3

Quan. LSB MSB D0 ..... LSB MSB D0

8 bit Index 32 bit I1 Index 32 bit I2
Q I1 ..... I2
Points/objects are I1, I2...IQ inclusive

4-22 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

• Q-code = 8, I-size = 0

LSB MSB D0 ..... D0

Quan. 16 bit Q Points/objects are 0...Q-1 inclusive
I(0) ..... I(Q-1)

• Q-code = 8, I-size = 1

LSB MSB Index D0 ..... Index D0

Quan. 16 bit Q 8 bit 8 bit Points/objects are I1, I2...IQ inclusive
I1 I1 ..... IQ IQ

• Q-code = 8, I-size = 2

LSB MSB LSB MSB D0 ..... LSB MSB D0

Quan. 16 bit Q Index 16 bit I1 Index 16 bit I2 Points/objects are I1, I2...IQ inclusive
I1 ..... I2

• Q-code = 8, I-size = 3

LSB MSB LSB MSB D0 ..... LSB MSB D0

Quan. 16 bit Q Index 32 bit I1 Index 32 bit I2
I1 ..... I2
Points/objects are I1, I2...IQ inclusive

• Q-code = 9, I-size = 0

LSB MSB D0 ..... D0

Quantity 32 bit Q Points/objects are 0...Q-1 inclusive
I(0) ..... I(Q-1)

• Q-code = 9, I-size = 1

LSB MSB Index D0 ..... Index D0

Quantity 32 bit Q 8 bit 8 bit Points/objects are I1, I2...IQ inclusive
I1 I1 ..... IQ IQ

• Q-code = 9, I-size = 2

LSB MSB LSB MSB D0 ..... LSB MSB D0

Quantity 32 bit Q Index 16 bit I1 Index 16 bit I2
I1 ..... I2
Points/objects are I1, I2...IQ inclusive

• Q-code = 9, I-size = 3

LSB MSB LSB MSB D0 ..... LSB MSB D0

Quantity 32 bit Q Index 32 bit I1 Index 32 bit I2
I1 ..... I2
Points/objects are I1, I2...IQ inclusive

DA0-025-1.00 4-23
DNPMxx Firmware Description Ax 1703

• Q-code = 11, I-size = 1

Use qualifier 11 when describing points that need to be uniquely identified by an object
identifier such as a File Object Identifier or Configuration Header. The type of identifier is
implied by the object type:

Quan. size ..... D0 ..... size ..... D0

8 bit 8 bit 011 012 01N 8 bit 0Q1 0QN
Q N1 ..... ID1 ..... NQ ..... IDQ

• Q-code = 11, I-size = 2

LSB MSB LSB MSB ..... D0 ..... LSB MSB ..... D0

Quan. 16 bit Q size 16 bit N1 011 012 01N size 16 bit NQ 0Q1 0QN
..... ID1 ..... ..... IDQ

• Q-code = 11, I-size = 3

LSB MSB LSB MSB ..... D0 .....

Quantity 32 bit Q size 32 bit N1 011 012 01N
..... ID1 .....

..... LSB MSB ..... D0

size 32 bit NQ 0Q1 0QN
..... ..... IDQ

4.1.9. Detail Function Code Description

This section describes the application layer funktion codes.

4.1.9.1. CONFIRM (Function Code 0)

The confirm function is used to confirm the reception of a message fragment when the
application control field (AC) in the received fragment has the CON bit set. Note the CON bit
in the confirmation message may be set to 0 or 1. This allows the option of having the
confirmation message confirmed. However, any station receiving a message fragment with
the CON bit set MUST respond with a CONFIRMation message BEFORE sending any other
application layer message. In addition, any station that sends a message fragment with the
CON bit set must wait until the CONFIRMation message arrives before continuing with
message fragment transmission or another transaction.

4.1.9.2. READ (Function Code 1)

The read function is the basic code used for requesting data objects from a Outstation. The
object, qualifier and range field are coded in such a way that their size can be calculated
allowing requests for multiple objects or ranges to be sent in a single message.

4-24 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4.1.9.3. WRITE (Function Code 2)

The write function code is used for moving objects from a master station to an Outstation.
The response from the Outstation is always a function code followed by the IIN. Typical uses
of the Write function are to download configuration or files to an Outstation and to set the
time in the Outstation.
The response always uses the Response function code.

4.1.9.4. SELECT (Function Code 3)

The select function code is used to select one or more control points at an Outstation. These
may be control relay outputs, analog outputs or pattern control blocks. This function does not
output or activate the new state or value but makes them ready (arms them) and reports their
status. An additional operate message must be sent to the Outstation to actually activate the
request. The operate message control objects must match the control objects in the
preceding select message before the activation takes place. The select message causes the
Outstation to starts a timer. The operate message must be received correctly before the
timer expires in order for the activation to take place. The response is identical to the request
except that it includes the IIN and modified status bytes (part of the control block objects).
The status bytes state the success or failure of the Select request.

4.1.9.5. OPERATE (Function Code 4)

The operate function code is used to activate one or more control or analog outputs at an
Outstation. A matching message using the select function code must previously have been
received, and the arm timer must still be active before the activation will take place. The
format of this message is the same as a select message except the function code is 4. The
response is identical to the request except that it includes the IIN and modified status bytes
(part of the control block objects). The status bytes state the success or failure of the Select
request.

4.1.9.6. DIRECT OPERATE (Function Code 5)

The direct operate function code is used to activate one or more outputs or setpoints at an
Outstation. A preceding select message is not required. The format of this message is the
same as a select or operate message except the function code is 5. The response is
identical to the request except that it includes the IIN and modified status bytes (part of the
control block objects). The status bytes state the success or failure of the Select request.

4.1.9.7. DIRECT OPERATE - No Acknowledgement (Function Code 6)

The direct operate No Acknowledgement function code is used to activate one or more
outputs or setpoints at a Outstation. A preceding select message is not required. The format
of this message is the same as a select or operate message except the function code is 6
and the Outstation does not respond with a message to the master station.

DA0-025-1.00 4-25
DNPMxx Firmware Description Ax 1703

4.1.9.8. IMMEDIATE FREEZE (Function Code 7)

This function code is used to copy the specified data objects to a freeze buffer. Upon
reception of the message, the Outstation should copy the current values of the specified data
objects to their appropriate freeze buffers. The objects which were frozen can be requested
(in another request) by asking for frozen objects.
The request can contain multiple object headers which specify many objects to freeze.
Typically, however, only counter objects are frozen.
The Outstation response can indicate (in the IIN) that the objects in the request are not
known.

4.1.9.9. IMMEDIATE FREEZE - No Acknowledgement (Function Code 8)

This function code works identically to the previous function code (Immediate Freeze) except
that no Outstation response is needed. Typically, this function code is used to perform a
global freeze on all Outstations belonging to the master. In this case, the SEND-NO REPLY
services of the Data Link Layer may have to be used in certain environments.

4.1.9.10. FREEZE AND CLEAR (Function Code 9)

This function code is used to copy the specified data to a freeze buffer like the freeze
immediate function code but then the Outstation clears ( to 0 ) the specified data objects.
Typically, this function code is used to freeze counters or accumulators and then reset them
to 0.

4.1.9.11. FREEZE AND CLEAR - No Acknowledgement (Function Code 10)

This function code works identically to the previous function code (Freeze and Clear) except
that no Outstation response is needed. Typically, this function code is used to perform a
global freeze and clear on all Outstations belonging to the master.

4-26 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4.1.9.12. FREEZE WITH TIME (Function Code 11)

This function code initiates the periodic freezing of the specified data objects. The Time and
Date with Interval object sent preceding the objects to freeze is described in the table below.
As shown, the object has two components: a time field (absolute) and an interval time field.
The value of these fields determines the behaviour of the Outstation freezing.

TIME INTERVAL DESCRIPTION

non zero zero Freeze once at specified time.

zero zero Freeze Immediately.

zero non zero Freezing is synchronized to the beginning of the

current hour. The first freeze will occur at the
smallest multiple greater than or equal to the
current time. Subsequent freezes will occur at
each interval increment.

non zero non zero Start freezing at the specified time and repeat at
each interval increment thereafter

4.1.9.13. FREEZE WITH TIME - No Acknowledgement (Function Code 12)

This function code works identically to the previous function code (Freeze With Time) except
that no Outstation response is needed. Typically, this function code is used to perform a
global freeze with time on all Outstations belonging to the master. In this case, the SEND-NO
REPLY services of the Data Link Layer may have to be used in certain environments.

4.1.9.14. COLD RESTART (Function Code 13)

The cold restart function code makes the Outstation perform a complete restart of the user
application, as if it has been newly powered up.

The Outstation, upon receiving the Cold Restart request will response with a Time Delay
Object (Time Delay Fine or Time Delay Course) which specifies a time interval until the
Outstation will be ready for further communications. The master should not attempt to
communicate with the Outstation until the interval has elapsed.

DA0-025-1.00 4-27
DNPMxx Firmware Description Ax 1703

4.1.9.15. WARM RESTART (Function Code 14)

This code restart function code specifies that the Outstation perform a restart, but it is not
necessary to run through the entire reset sequence (only certain applications need be
restarted). The DNP application may reset itself without resetting other subsystems or
processes. Typically this function makes an Outstation application initialize its configuration
and clear events stored in its local buffers.

The Outstation response is identical to the response to the Cold Restart function code and
should be interpreted in the same way. The Time Delay Object is actually a Time Delay Fine
or Time Delay Course object.

4.1.9.16. INITIALIZE DATA (Function Code 15)

This function code specifies that configurable data is to be set to the initial or default settings.
For example, this function could be used to clear counters. Note that the initial settings are
NOT contained in the request.

The response only indicates the success or failure of the requested operation.

4.1.9.17. INITIALIZE APPLICATION (Function Code 16)

This function code initializes the specified applications at the Outstation in preparation for
execution.

The Outstation, upon receiving the request, should initialize the specified application(s) and
then respond with either the success or failure of the transaction.

4.1.9.18. START APPLICATION (Function Code 17)

This function code is used to start the specified application(s) at the Outstation.

The Outstation, upon receiving the request, should start the specified application(s) and then
respond with either the success or failure of the transaction.

4-28 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4.1.9.19. STOP APPLICATION (Function Code 18)

This function code informs the Outstation to stop the execution of the specified application.

The Outstation, upon receiving the request, should stop the specified application(s) and then
respond with either the success or failure of the transaction.

4.1.9.20. SAVE CONFIGURATION (Function Code 19)

This function initiates the saving of the specified configuration(s) to nonvolatile storage at the
Outstation station.

The Outstation, upon receiving the request, should save the specified configuration(s) and
then respond with either the success or failure of the transaction and a time object (Time
Delay Fine or Time Delay Course) which indicates the time at which the Outstation will be
available again for communication. The master should not attempt to communicate with the
Outstation until the time specified.

4.1.9.21. ENABLE UNSOLICITED MESSAGES (Function Code 20)

This function code informs the Outstation to enable spontaneous (unsolicited) reporting of
the objects specified in the object header.

The Outstation will enable spontaneous messages for all object (types or points) specified in
the object header. The master could also send an object header specifying class data. This
means that any objects which are configured for the specified class will be enabled for
spontaneous messages.

4.1.9.22. DISABLE UNSOLICITED MESSAGES (Function Code 21)

This function code informs the Outstation to disable spontaneous (unsolicited) reporting of
the objects specified in the object header.

The Outstation will disable spontaneous messages for all object (types or points) specified in
the object header. The master could also send an object header specifying class data. This
means that any objects which are configured for the specified class will be disabled for
spontaneous messages.

DA0-025-1.00 4-29
DNPMxx Firmware Description Ax 1703

4.1.9.23. ASSIGN CLASSES (Function Code 22)

This function is used to assign data objects to classes.

• The class object header must specify the class object group and a variation between 1
and 3 indicating the class assignment to all the data object (specified by the headers)
that follow.

• The data object header(s) identifies the group, variation and range of the objects to be
assigned to the class specified in the class object header preceding the data object
header.

• Multiple sets of Class Object headers followed by one or more Data Object headers
can be sent in one message. Each set must not span multiple fragments, however.

• Static data objects are assigned to Class 0 and cannot be assigned to other classes.
Event data objects are assigned to classes 1, 2 and/or 3 and cannot be assigned to
Class 0.

The Outstation response indicates the success or response of the operation (success or
failure determined by the state of the IIN bits).

4.1.9.24. DELAY MEASUREMENT (Function Code 23)

This function is used to calculate the communication delay for a particular Outstation. It is
generally used in the time synchronization process for the Outstations.

The Outstation responds with the Time Delay Fine object. This object states the number of
milliseconds elapsed between the Outstation receiving the first bit of the first byte of the
request and the time of transmission of the first bit of the first byte of the response.

4.1.10. CLASSES

Objects may be assigned to a class. There are four Classes of data. Class 0 is reserved for
static data objects (static data reflects the current value of data in the Outstation). Classes 1,
2 and 3 are reserved for event data objects (objects created as the result of data changes in
the Outstation or some other stimulant). Each event object can be assigned to Class 1, 2 or 3
by parameters.

Class data is used by a master station to request pre-assigned data objects on a demand or
availability basis from an Outstation. Therefore, a class data object header can be used only
in a request (with no associate data object) to indicate to the Outstation which data objects to
return. The Outstation will return (in the response) object headers for the ACTUAL data
objects and NOT the class object header.

The assignment of classes is implemented by the detail routing of the communication

element.

4-30 DA0-025-1.00
Ax 1703 Firmware Description DNPMxx

4.1.11. Time Synchronization

Time synchronization is handled by the application layer BUT has to make use of special
services of the data link layer. The application must initiate the time synchronization
sequence by sending the appropriate request or response.

To synchronize Master station and Outstation time, the following procedure is used.

1. The Master station sends a Delay Measurement request to the Outstation. The master
records the time of transmission of the first bit of the first byte of the request
(MasterSendTime).

2. The Outstation receives the first bit of the first byte of the Delay Measurement request at
time RtuReceiveTime (this is a local time in the Outstation).

3. The Outstation transmits the first bit of the first byte of the response to the Delay
Measurement request at time RtuSendTime. The response contains the Time Delay
object (Time Delay Fine or Time Delay Course), with the time in this object equal to
RtuTurnAround, where

RtuTurnAround = RtuSendTime - RtuReceiveTime

4. The Master station receives the first bit of the first byte of the Outstation's response at
time MasterReceiveTime.

5. The master station can now calculate the one way propagation delay as

MasterSendTime − MasterReceiveTime − RtuTurnAround

Delay =
2

6. The master now transmits the first bit of the first byte of a Write request at time
MasterSend. The Write request contains the Time and Date object, with the time in the
object representing a time equal to (MasterSend + Delay). This is the time that the Master
station wants the Outstation to be set to.

7. The Outstation receives the first bit of the first byte of the Write request at time
RtuReceive.

8. The Outstation will process the Write request, setting the Outstation clock to time
NewRtuTime. The following algorithm is used:

Adjustment = CurrentRtuTime - RtuReceive

NewRtuTime = (time in the Time and Date object) + Adjustment

9. The Master and Outstation time are now synchronized.

NOTE: The Time Synchronization scheme assumes that the Outstation to master
propagation delay and the master to Outstation propagation delay are equal.

If desired, the master station may send a global request (using the reserved destination
address of FFFF hexadecimal) to simultaneously synchronize all Outstations, only if all path
delays are equal.

DA0-025-1.00 4-31
DNPMxx Firmware Description Ax 1703

4.1.12. Binary Input with Time Events

An Outstation will often transmit Binary Input with Time or Binary Input with Relative Time
objects when digital input points changes state. Binary input event objects are transmitted in
different formats depending on different conditions.

1) Outstation Time Synchronized, one event object to send. The data is transmitted in
the Binary Input with Time object format.

2) Outstation Time Synchronized, several event object to send. The Time and Date
Common Time of Occurrence object is transmitted followed by several Binary Input with
Relative Time objects. The time in the Time and Date Common Time of Occurrence
object is the time of the oldest object. The relative times start at 0 (for the oldest object)
and range upwards relative to the Date and Time object.

3) Outstation Time NOT Synchronized, one or more event object to send. The
Unsynchronized Common Time and Date object is transmitted followed by one or more
Binary Input with Relative Time objects. The time in the Time and Date Common Time of
Occurrence object is the time of the oldest object. The relative times start at 0 (for the
oldest object) and range upwards relative to the Time and Date object.

4-32 DA0-025-1.00