DNPBasic4

8/12/2019 DNPBasic4

1/291

DNP Users Group

DNP PRODUCT DOCUMENTATION

DNP V3.00DATA LINK LAYER

Document Version: 0.02

Internal File: P009-0PD.DL

Associated Software Release: DNP V3.00

8/12/2019 DNPBasic4

2/291

NOTICE OF RIGHTS - DNP USERS GROUP

The contents of this manual are the property of the DNP Users

Group. Revisions or additions to the definition and functionality of

the Distributed Network Protocol cannot be made without express

written agreement from the DNP Users Group or its duly authorized

party. In addition, no part of this document may be altered or

revised or added to in any form or by any means, except as permitted

by written agreement with the DNP Users Group or a Party duly

authorized by the DNP Users Group.

As a Party, duly authorized by the DNP Users Group, Harris

Corporation has made every reasonable attempt to ensure the

completeness and accuracy of this document, however, the

information contained in this manual is subject to change without

notice, and does not represent a commitment on the part of HarrisCorporation or the DNP Users Group. An update program for DNP

documents is provided upon request by Harris Corporation on

behalf of the DNP Users Group.

TRADEMARK NOTICES

Brand and product names mentioned in this document are

trademarks or registered trademarks of their respective companies.

8/12/2019 DNPBasic4

3/291

DNP V3.00 Data Link Layer (Version 0.02) i

TABLE OF CONTENTS

ABOUT THIS DOCUMENT IV

PURPOSE OF THIS SPECIFICATION iv

WHO SHOULD USE THIS SPECIFICATION iv

HELP AND ADDITIONAL DOCUMENTATION iv

HOW THIS SPECIFICATION IS ORGANIZED v

CONVENTIONS USED IN THIS SPECIFICATION v

1. OVERVIEW 1-1

2. IEC CONFORMANCE 2-1

2.1 CHANNEL FAILOVER 2-1

2.2 FRAME FORMAT AND PROCEDURES 2-1

2.3 LENGTH, CONTROL AND ADDRESS FIELDS 2-1

3. DNP DATA LINK DESCRIPTION 3-1

3.1 PURPOSE OF THE DATA LINK LAYER 3-1

3.2 FT3 FRAME FORMAT 3-1

3.3 DATA LINK HEADER FRAME FIELDS 3-23.4 USER DATA 3-5

3.5 CRC FIELDS 3-5

3.6 DATA LINK FUNCTION CODES 3-6

3.7 TRANSMISSION PROCEDURES 3-8

4. DATA LINK SERVICES AND RESPONSIBILITIES 4-1

4.1 DATA LINK FUNCTIONS 4-1

4.2 INTERFACE DESCRIPTION 4-1

5. PHYSICAL LAYER INTERFACE 5-1

5.1 PHYSICAL LAYER DESCRIPTION 5-1

6. PHYSICAL LAYER CHARACTERISTICS 6-1

6.1 LINE CONFIGURATIONS 6-1

6.2 MODES OF TRANSMISSION 6-1

6.3 LOCAL LOOP 6-1

7. PHYSICAL LAYER PROCEDURES 7-1

7.1 GENERAL CONSIDERATIONS 7-1

7.2 HALF-DUPLEX PROCEDURES 7-1

7.3 FULL-DUPLEX PROCEDURES 7-2

LIST OF ABBREVIATIONS AND ACRONYMS 1

8/12/2019 DNPBasic4

4/291

DNP Users Groupii

TABLE OF FIGURES

FIGURE 3-1 FT3 FRAME FORMAT 3-2

FIGURE 3-2 CONTROL OCTET BIT DEFINITIONS 3-3

FIGURE 3-3 TABLE OF PRIMARY AND SECONDARY FUNCTION CODES 3-4

FIGURE 3-4 DESTINATION ADDRESS FORMAT 3-4

FIGURE 3-5 SOURCE ADDRESS FORMAT 3-5

FIGURE 3-6 CRC ORDERING 3-6

FIGURE 3-7 RESET OF SECONDARY LINK 3-8

FIGURE 3-8 RESET OF USER PROCESS 3-9

FIGURE 3-9 SEND FROM STATION A/CONFIRM FROM STATION B 3-9

FIGURE 3-10 SEND FROM STATION B/CONFIRM FROM STATION A 3-9

FIGURE 3-11 SEND MULTIPLE FRAMES FROM STATION A/CONFIRM FROM STATION B 3-10

FIGURE 3-12 FRAME COUNT BIT OPERATION 3-10

FIGURE 3-13 FRAME COUNT BIT OPERATION 3-10

FIGURE 3-14 SEND-NO-REPLY EXPECTED FROM STATION A 3-11

FIGURE 3-15 SEND FROM STATION B/NACK FROM STATION A 3-11

FIGURE 3-16 REQUEST/RESPOND FRAME AND DFC BIT USAGE 3-12

8/12/2019 DNPBasic4

5/291

DNP V3.00 Data Link Layer (Version 0.02) iii

8/12/2019 DNPBasic4

6/291

DNP Users Groupiv

ABOUT THIS DOCUMENT

PURPOSE OF THIS SPECIFICATION

This document specifies the Distributed Network Protocol (DNP) Data Link layer services,

transmission procedures and Link Protocol Data Unit.

WHO SHOULD USE THIS SPECIFICATION

This specification is intended for communication engineers and programmers interested in knowing the

function and message format of the DNP data link layer. This includes programmers implementing and

designing DNP data link layer software/hardware and quality assurance personnel testing and verifying

implementations of the DNP data link layer. Application programmers may find this specification

useful in determining how to interface with and make use of the DNP data link layer. Familiarity with

the ISO-OSI 7-layer model, IEC 3-layer EPA and IEC TC-57 standards is helpful.

HELP AND ADDITIONAL DOCUMENTATION

The following documentation may be helpful. IEC 870-5-1andIEC 870-5-2standards (or drafts), Technical Committee No. 57 for data

transmission in telecontrol systems

DNP V3.00 Data Object Library(P009-0BL)

DNP V3.00 Application Layer(P009-0PD.APP)

DNP V3.00 Transport Functions(P009-0PD.TF).

8/12/2019 DNPBasic4

7/291

DNP V3.00 Data Link Layer (Version 0.02) v

HOW THIS SPECIFICATION IS ORGANIZED

1. OVERVIEW

A general overview of the data link layer.

2. IEC CONFORMANCE

Details the differences between DNP and the IEC TC-57 standards.

3. DNP DATA LINK DESCRIPTION

Describes the DNP data link frame format, function codes and procedures.

4. DATA LINK SERVICES AND RESPONSIBILITIES

Describes the services that the data link provides to higher layers.

5. PHYSICAL LAYER INTERFACE

Describes the service interface provided by the physical layer to the data link.

6. PHYSICAL LAYER CHARACTERISTICS

Describes the physical layer used with the DNP data link.

7. PHYSICAL LAYER PROCEDURES

Describes how the DNP data link uses the physical layer.

LIST OF ABBREVIATIONS AND ACRONYMS

CONVENTIONS USED IN THIS SPECIFICATION

In this document, the octet is a term used to refer to an eight bit data object and is synonymous with the

term byte. The low order bit of an octet is referred to as bit 0 and the high order bit as bit 7.

Irregular capitalization is used in referencing technical terms which have an associated verb or noun.

For example, data link indications commonly referred to as IND, can also be described using the word

INDication.

8/12/2019 DNPBasic4

8/291

8/12/2019 DNPBasic4

9/291

8/12/2019 DNPBasic4

10/291

8/12/2019 DNPBasic4

11/291

DNP V3.00 Data Link Layer (Version 0.02) 2-1

2. IEC CONFORMANCE

This chapter describes the difference between the DNP protocol and the IEC TC-57 (870-5) telecontrol

data link layer protocol specification.

2.1 CHANNEL FAILOVER

The DNP link layer communicates with only one physical layer (or channel). In the OSI model, the

Session layer is responsible for maintaining channel connections. In DNP, the layer above the data link

is responsible for providing channel failover based on communications failure at the Data Link. This

layer could be a Network/Transport Layer or the Application Layer. Thus, the IEC requirement, 870-5-

1, item 13, for channel failover is met at the Application Layer.

2.2 FRAME FORMAT AND PROCEDURES

The data link layer uses a standard variable length frame format as defined in theIEC 870-5-1

Transmission Frame Formatsdocument. The FT3 frame format class is well suited for data

transmission between stations that require medium information transfer rates and low residual error

probability. The basic frame format is used and transmission rules R1, R2, R3 and R4 are followed.

Rules R5 and R6 are followed in principle, although the exact time values suggested are not used but

are configurable in each implementation. The frame definitions outlined in IEC 870-5-2 are followedwith the note that !"# %&&'#(( )*#+& *( , -.!#!( */ +#/0!" 1/& (2#.*)*#( !"# (!*/1!*-/ (!1!*-/ 1&&'#((

1/& !"# 3*/4 5(#' 61!1 )*#+& *( 7(#& 1( 1 , -.!#! (-7'.# (!1!*-/ 1&&'#((8

Fully-balanced transmission procedures as specified byIEC 870-5-2were adopted to handle unsolicited

transmissions from stations not designated as masters in a half-duplex or full-duplex system. Fully-

balanced means that each station can act as a primary station (sending) and a secondary station

(receiving) at the same time. This configuration requires a full-duplex channel to operate properly. In a

half-duplex environment, the same procedures will be used except that a station cannot be both a

primary and secondary station at the same time. That is, an entire data link layer transaction between the

master station and outstation will have to be completed at both stations before any further transactions

can be started from either station. In both half-duplex and full-duplex configurations, it is the

responsibility of each device to implement a compatible collision avoidance scheme.

2.3 LENGTH, CONTROL AND ADDRESS FIELDS

The DNP data link uses the same LENGTH field as defined in IEC 870-5-1 clause 6.2.4. (Refer to

Section 3 for more information on this field).

The CONTROL field used is the IEC CONTROL field used for balanced transmission as defined in

IEC 870-5-2 clause 6.1.2. All the function codes specified in IEC 870-5-3 clause 6.1.2 Table III are

supported.

The ADDRESS field is a 16-bit (2 octet) field. The DNP data link frame header has two IEC

ADDRESS fields. The first field is the A (Address) field where it is used to represent the destination

station address and the second is in the Link User Data field where it is used to represent the source

station address. (Refer to Section 3 for more information on these fields).

8/12/2019 DNPBasic4

12/291

8/12/2019 DNPBasic4

13/291


3. DNP DATA LINK DESCRIPTION

The Data Link Layer is the second layer in the Open System Interconnection (OSI) model. The data

link layer accepts, performs and controls transmission service functions required by the higher layers.

3.1 PURPOSE OF THE DATA LINK LAYER

The main purpose of the DNP data link layer is twofold. First, the data link layer must provide transfer

of information or Link Service Data Unit (LSDU) across the physical link as described by the ISO-OSI

standard. This means that user data supplied by higher layers (LSDU) must be converted into one frame

(or LPDU as described in Section 2) and sent to the physical layer for transmission. Conversely,

individual LPDUs received by the data link layer must be assembled into one LSDU and passed to

higher layers. The layer provides for frame synchronization and link control.

Secondly, in DNP V3.00, the data link provides indications of other events such as link status.

The OSI reference model enforces either a connection-less or a connection oriented system. However,

the EPA model implies neither a connection-less system nor a connection oriented system. The DNP

Version 3 implementation of the IEC data link handles both connection-less and connection oriented

systems (that is, physical networks that require dialing or logging in before data can be transmitted to

the destination device) but has no need to provide connection services. The actual physical network is

transparent to the application using the data link because the data link layer is responsible forconnecting and disconnecting from any physical network without higher level interaction (i.e.

application layer). That is, the data link (given the station destination address) will connect to the right

physical circuit without control supplied from higher layers. In this way, the physical medium is totally

transparent to the link layer service user.

3.2 FT3 FRAME FORMAT

This section describes the LPDU format. 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.

8/12/2019 DNPBasic4

14/291

DNP Users Group3-2

!!! ||

$"""""""%"""""""%""""""""%"""""""""%"""""""""""""%""""""""%"""""&"""""""%"""""' -------------!START !START !LENGTH !CONTROL !DESTINATION !SOURCE !CRC !USER !CRC !... | USER | CRC|

!0x05 !0x64 ! ! ! ! ! !DATA ! ! | DATA ||

$"""""""("""""""(""""""""("""""""""("""""""""""""(""""""""("""""&"""""""(""""") -------------!!|

#0 octets

START 2 starting octets of the header (0x0564).

LENGTH 1 octet count of USER DATA in the header and body. This count includes

the CONTROL, DESTINATION and SOURCE fields in the header. The

CRC fields are not included in the count. The minimum value for LENGTH

is 5 indicating only the header is present and the maximum value is 255.

CONTROL Frame control octet.

DESTINATION 2 octet destination address. The first octet is the LSB and the second octet is the

MSB.

SOURCE 2 octet source address. The first octet is the LSB and the second octet is the

MSB.

CRC 2 octet Cyclic Redundancy Check.

USER DATA Each block following the header has 16 octets of User defined data except

the last block of a frame which contains 1 to 16 octets of User defined data

as needed.

Figure 3-1 FT3 Frame Format

3.3 DATA LINK HEADER FRAME FIELDS

This section describes block 0 (or header) of a data link frame.

3.3.1 Start

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

hexadecimal.

3.3.2 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.

3.3.3 Control

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

Figure 3-2 defines the fields of the control octet. Station A is defined as the designated master station.

Station B is not a master station. The primary station is the originator of the message, the source of the

message. The secondary station is the destination station.

8/12/2019 DNPBasic4

15/291


*"""""%"""""%"""""%"""""%"""""%"""""%"""""%"""""+ ! ! # !FCB !FCV ! ! ! ! !Primary to Secondary !DIR !PRM $"""""$"""""' FUNCTION CODE ! ! ! 0 !RES !DFC ! ! ! ! !Secondary to Primary ,"""""("""""("""""("""""("""""("""""("""""(""""")Bit 7 6 5 4 3 2 # 0

DIR Physical transmission direction

1 = station A to station B0 = station B to station A

PRM Primary Message

1 = frame from primary (initiating station)

0 = frame from secondary (responding station)

FCB Frame count bit

FCV Frame count bit valid

1 = Frame count bit is valid

0 = ignore frame count bit

DFC Data flow control bit

RES Reserved = 0

FUNCTION CODE Defines the frame type, how the data link will handle the frame

Figure 3-2 Control Octet Bit Definitions

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 anyprimary 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.Figure 3-16 illustrates the DFC bit usage.

8/12/2019 DNPBasic4

16/291

DNP Users Group3-4

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 !! # !SEND - CONFIRM expected !Reset of user process ! 0 !! 2 !SEND - CONFIRM expected !TEST function for link ! # !! 3 !SEND - CONFIRM expected !User Data ! # !! 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 !! #0 ! !Not Used ! - !! ## ! !Not Used ! - !! #2 ! !Not Used ! - !! #3 ! !Not Used ! - !! #4 ! !Not Used ! - !! #5 ! !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 !! # !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 !! #0 ! !Not Used !! ## !RESPOND !Status of Link (DFC = 0 or DFC = #) !! #2 ! !Not Used !! #3 ! !Not Used !! #4 ! !Link service not functioning !! #5 ! !Link service not used or implemented !,""""""""""("""""""""""""("""""""""""""""""""""""""""""""""""""""""")

Figure 3-3 Table of Primary and Secondary Function Codes

3.3.4 Destination Address

The Destination address field is 2 octets in size and specifies the address of the station that the frame isdirected 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) ! ! ! ! ,""""""""""""""""""""""""""""("""""""""""""""""""""""""")

Figure 3-4 Destination Address Format

3.3.5 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

8/12/2019 DNPBasic4

17/291


order. Note that this field is not included as USER DATA but must be passed as a return value to the

higher layers by the data link service primitives.

*""""""""""""""""""""""""""""%""""""""""""""""""""""""""+! ! !! LOW ORDER OCTET (LSB) ! HIGH ORDER OCTET (MSB) !! ! !,""""""""""""""""""""""""""""("""""""""""""""""""""""""")

Figure 3-5 Source Address Format

3.4 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.

3.5 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+ X

6+ X

5+ X

2+ 1

The CRC algorithm used will now be described. In the following discussion, modulo-2 arithmetic

(addition and division) is assumed. A message block (M) of k-bits is to be transmitted (along with other

blocks) (k is 64 for the header, 128 for all user data blocks but the last block where k is 8 to 128). A 16-

bit CRC check word (F) is bit-wise inverted (F') and appended to M. Together M and F' are appended

together so that T' = 216

M + F' and T' will be transmitted (additionally we define T = 216

M + F). The

CRC check sequence is a pattern (P) of 17 bits as defined above in polynomial form. The CRC

algorithm requires that when T is divided by P at the receiver the remainder is 0. If the remainder is not

0 then the block is in error. In addition, the remainder (R) of 216

M/P is used as F in the block so that

216

M/P = Q + R/P (Equation. 1) (Q is the quotient). This can be proven to provide a remainder of 0 as

follows. If we assume that T=216

M + R then, T/P = (216

M + R)/P. If we substitute equation 1 then T/P =

Q + (R + R)/P = Q since R added to itself modulo-2 results in zero.

The transmission and reception procedure is described below:

To transmit a block:

9:;7+!*2+@ > =@ ,:A!- -=!1*/ ,:A>8

9B;6*C* !"*( /7D=#' 9D-&7+#E,; =@ F 9:GE=*!(; !- 0#! H 9:AE=*!(;8

9I;J/C#'! H =*!E?*(# !- 0#! HK8

9L;%22#/& HK !- ,:A> 1/& !'1/(D*! 1( 1 =+-.4 9

8/12/2019 DNPBasic4

18/291

DNP Users Group3-6

To receive a block:

9:;H#.#*C# 1 =+-.4 9

8/12/2019 DNPBasic4

19/291


Respond with an ACK confirm frame (DFC=x, PRM=0, DIR=x). The FCB status (expected value of

FCB in next received frame with FCV valid) should be set to 1. A positive INDication can be sent to

the data link user.

During normal operation, if a RESET command with FCV=0, FCB=x, PRM=1 and DIR=x is received,

then the current transaction (if any) can be aborted (possibly with negative INDication sent to data linkuser).

In such case, respond with an ACK confirm frame (DFC=x, PRM=0, DIR=x). The FCB status

(expected value of FCB in next received frame with FCV valid) should be set to 1. A positive

INDication can be sent to the data link user.

3.6.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.

3.6.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.

3.6.4 User Data

The User Data function is used to send confirmed data to a secondary station. Before communicationscan 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. The transmission procedures are described below:

3.6.4.1 Primary Transaction

Do number of configurable tries: (i.e. retries + 1)

Send User Data frame with FCV=1, PRM=1, DIR=x and FCB set to FCB status for the secondary

station (next expected FCB status).

Wait the pre-determined time-out period for a ACK or NACK frame from the secondary station.

If frame is NACK then wait a pre-determined amount of time until secondary link is NOT busy or use

REQUEST LINK STATUS (below) and go to top of loop to retry.If correct ACK frame is received, toggle FCB status (i.e. next frame sent to secondary with FCV valid

should have opposite FCB) and exit loop.

If correct frame is not received then go to top of loop and re-try.

If ACK was received then the transaction is considered successful and the secondary station can be

considered on-line. A positive INDication can be returned to the data link user.

Otherwise, a negative INDication should be sent to the data link user and the secondary station can be

considered off-line or on-line depending on the data link user's interpretation of the failure.

3.6.4.2 Secondary Transaction

Upon reception of a User Data frame with FCV=1, PRM=1, DIR=x and FCB set to FCB status

(expected FCB state) do the following:

8/12/2019 DNPBasic4

20/291

DNP Users Group3-8

If the data link user is ready to accept user data then respond with an ACK confirm frame (DFC=x,

PRM=0, DIR=x) else respond with a NACK frame (same bit settings as ACK) and exit this loop.

3.6.5 Unconfirmed User Data

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

way, the bandwidth of the system can be more fully utilized if the user data is low priority. The framesent contains the user data from the primary data link user that is to be passed to the data link user of

the secondary station. The transmission procedures are described below:

3.6.5.1 Primary Transaction

Send Unconfirmed User Data frame with PRM=1, DIR=x, FCV=0, FCB=x.

Announce positive INDication to data link user.

3.6.5.2 Secondary Transaction

Receive Unconfirmed User Data frame as above and send positive INDications with the data to the data

link user.

3.6.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.

3.7 TRANSMISSION PROCEDURES

This section illustrates the usage of the defined frame types.

3.7.1 Reset of Secondary Link

In Figure 3-7, a primary station sends a SEND-CONFIRM RESET frame to a secondary station. The

secondary station receives the message and responds with an ACK confirm frame.

Reset *"""""""""+(REQ) ! ! ! SEND ! ! FCB=0 ! ,"""""""""("""""""""""> *"""""""""""""+Expected FCB=x ! CONFIRM !(IND)

8/12/2019 DNPBasic4

21/291


Reset User *"""""""""+(REQ) ! ! ! SEND ! ! ! ,"""""""""("""""""""""> *"""""""""""""+ ! CONFIRM !(IND)

8/12/2019 DNPBasic4

22/291

DNP Users Group3-10

In Figure 3-11, a designated master station sends 3 consecutive frames to the same non-master station.

(REQ #) *"""""""""+ ! SEND ! ! FCB=# ! ,"""""""""("""""""""""> *"""""""""""+Expected FCB=# ! CONFIRM ! ! !(IND) Positive *"""""""""""+ ! CONFIRM ! ! !(IND) Positive *"""""""""""+ ! CONFIRM ! ! !(IND) Positive *"""""""""""+ ! t DBA ! CONFIRM ! ! ! ! ! garbled """"""""""""""(""""""""""")(IND) User Data ! or not receivedretry delay > t DAB + t DBA + t CONFIRM duration + t SEND message processing time at station B

! "(" *"""""""""+

!

!(same data)! SEND ! Expected FCB = 0 ! FCB=# ! ,"""""""""("""""""""""> *"""""""""""+send data is ignored, unexpected FCB ! !but another confirm is sent ! CONFIRM ! ! ! *"""""""""""+ ! CONFIRM ! tBA ! !(IND) Positive*"""""""""+ (lost or garbled)

retry delay > tBA + tAB + CONFIRM time + CONFIRM processing time at Station B

*"""""""""+ !SEND ! !FCB=# ! Expected FCB=# ,"""""""""("""""""""""> *"""""""""""+ ! CONFIRM ! ! !(IND) Positive """""""""

8/12/2019 DNPBasic4

23/291


NOTE: Both a master station and non-master station acting as primary stations can re-try SEND

frames.

3.7.4 Send/No Reply Expected

In Figure 3-14, the master or non-master primary station sends 3 frames to the secondary master or non-

master. Upon successfully transmitting the SEND frame, the primary station INDicates success to the

data link user. The secondary station, upon reception of a valid frame INDicates data availability to the

data link user.

*"""""""""""+(REQ) ! SEND ! !NO REPLY ! ! ! "%" ,"""""""""""("""""""""""> (IND) Positive with user data ! delay before next frame = t SEND message processing at station B

! "(" *"""""""""""+(REQ 2) !SEND ! !NO REPLY ! ! ! ,"""""""""""("""""""""""> (IND) Positive with user data "%" ! delay

! "(" *"""""""""""+(REQ 3) !SEND ! !NO REPLY ! ! ! ,"""""""""""("""""""""""> (IND) Positive with user data

Figure 3-14 SEND-NO-REPLY Expected From Station A

3.7.5 Send/NACK

In Figure 3-15, a non-master primary station sends a frame to the master secondary. Upon reception of

the first CONFIRM, the primary INDicates success to the data link user. The primary sends a second

frame to the secondary. The secondary master decides that it cannot accept any frames at this time and

sends a NACK frame back. The primary, after receiving this NACK, will fail the transaction and send a

negative INDication to the data link user.

*"""""""""+(REQ #) ! SEND !Expected FCB=# ! FCB=# ! *"""""""""""+

8/12/2019 DNPBasic4

24/291

DNP Users Group3-12

*"""""""""""+(REQ #) ! ! ! SEND ! ! FCB=0 ! ,"""""""""""("""""""""""> *"""""""""""+ ! CONFIRM !(IND) Positive ! DFC=0 !Receipt of CONFIRM frame *"""""""""""+ *"""""""""""+ ! CONFIRM ! ! DFC=# ! *"""""""""""+

8/12/2019 DNPBasic4

25/291


4. DATA LINK SERVICES ANDRESPONSIBILITIES

4.1 DATA LINK FUNCTIONS

This section describes the services offered by the data link and its functions. The communication

requirements of the network layer and the pseudo-transport layer are satisfied by the data link layerservice primitives.

The data link is responsible for performing the following functions:

Performing message retries

Synchronizing and handling of the FCB bit in the control word

Setting and clearing the DFC bit based on buffer availability

Automatically establishing a connection based on the destination parameter in a dial up environment

when a directed service is requested by the user

Disconnection in a dial-up environment

Packing user data into the defined frame format and transmitting the data to the physical layer

Unpacking the frames that are received from the physical layer into user data

Controlling all aspects of the physical layer Performing collision avoidance/detection procedures to ensure the reliable transfer of data across

the physical link

Responding to all valid frames (function codes) received from the physical layer.

The data link is responsible for providing the following services:

Exchange of SDUs between peer DNP data links

Error notification to data link user

Sequencing of SDUs

Prioritized SDU delivery

Quality SDU delivery.

SDUs will only be exchanged between peer DNP data links.

Priority delivery can be EXPEDITED or NORMAL to indicate a high or low priority request.

Quality delivery can be SEND-NO-REPLY or SEND-CONFIRM to indicate whether or not message

acknowledgment is required.

Error notification will be given to the data link user when a response to a request has not been received.

4.2 INTERFACE DESCRIPTION

The data link service primitives are illustrated in pseudo code to illustrate the requirements and

behavior in a real implementation and are not intended as an exact interface definition.

Data link request (REQ) services can be used at any time after the data link has been initialized and

configured by the system.

8/12/2019 DNPBasic4

26/291

DNP Users Group4-2

confirm = request_data_link_service(

SERVICE,

TIME_SERVICE,

destination,

source,

send_data_buffer,send_count,

retry_flag,

time_of_transmission

)

Input:

SERVICE Service to perform

TIME_SERVICEGuaranteed time service to perform

source Source address to use in sent message

destination Destination address to use in sent message

send_data_buffer Data to send in message

send_count Number of octets in message

retry_flag Instructs data link layer to retry unacknowledged frames or not

time_of_transmission Time that first bit of first octet of message is to be sent

Output:

time_of_transmission Time that first bit of first octet of message was sent

Confirm = 0 Requested service was successful

1 Requested service has failed

2 Requested SEND data service was terminated by the current primary station.

(reception of a NACK frame from the secondary station)

3 Service code is not implemented

4 Requested service cannot proceed at this time because the data link is busy

either with a previous requested transaction, current unrequested transactionor waiting for physical layer availability

Service = 0 Send a message specified in parameters using SEND-CONFIRM frames.

Fails if the data link is busy

1 Send a message specified in parameters using SEND-NO- REPLY frames.

Fails if the data link is busy

2 Expedited send a message specified in parameters using SEND-CONFIRM

frames. May necessitate cancelling the current secondary transaction if a

half-duplex system is used (i.e. forces the data link to send a NACK frame

instead of a CONFIRM frame in the next secondary transaction). This action

only takes place if the primary station is using SEND-CONFIRM frames.

3 Expedited send a message specified in parameters using SEND-NO-REPLY

expected frames. In a half-duplex system, this may mean cancelling thecurrent secondary transaction (as above).

4 Return link status. Return successful if the data link is not busy.

Time_service 0 Send message at time specified in time_of_transmission. This service should

have the highest priority.

1 Send message at any time with priority specified.

8/12/2019 DNPBasic4

27/291


Data link indications (IND) can be requested at any time by the service user but should be checked as

often as possible in order to obtain received data.

indications = request_data_link_indications(

source_address,

destination_address,

received_data_buffer,received_data_count,

time_of_reception)

Output:

source_address Source address of received message

destination_address Destination address of received address

received_data_buffer Received message

received_data_count Number of octets in message

time_of_reception Time at which first bit of first octet of message was received

Indications = 0 No indications to report

1 Data link has received a valid message that has been placed in

received_data_buffer and the number of octets received has been placed in

received_data_count. The source address of the received message has been

placed in source_address. If the data link is configured as a master station

then the time that the first bit of the first octet of the message was received

has been placed in time_of_reception. If the data link is configured as an

outstation then the time_of_reception will still be returned but the service

user has to be aware of the possibility of inaccurate times received before the

outstation has been time-synchronized.

2 Data link has detected a transaction failure.

8/12/2019 DNPBasic4

28/291

8/12/2019 DNPBasic4

29/291


5. PHYSICAL LAYER INTERFACE

This section describes the DNP Version 3 Data Link to physical layer interface. The interface describes

the necessary services that ANY physical layer must provide in order to accommodate the DNP V3.00

Data Link.

5.1 PHYSICAL LAYER DESCRIPTION

The physical layer that is recommended for the data link is a bit-serial oriented asynchronous physical

layer supporting 8 bit data, 1 start bit, 1 stop bit, no parity and RS-232C voltage levels and control

signals. The CCITT V.24 standard describes the DTE (Data Terminal Equipment) which is used for

communication with a DCE (Data Communication Equipment) and is usually a frequency-switched

modem (FSK). This type of circuit connection to a PSN (Public Switching Network) or to private

leased lines can be used. In each case, the appropriate modem must be used and must conform

(minimally) to the V.24 standard DCE definition.

The physical layer must provide 5 basic services: Send, Receive, Connect, Disconnect, and Status. The

Send service converts data octets into bit-serial data for transmission between the DTE and DCE. It

must provide the proper signal control in order to communicate with the given DCE. The Receive

service must be able to accept data from the DCE and therefore provide the correct signaling to the

DCE in order to receive data and not noise. The Connect and Disconnect services provide connection

and disconnection from the PSN (if applicable). The Status service must be able to return the state ofthe physical medium. As a minimum, the service must indicate whether or not the medium is busy.

The physical link service primitives are illustrated in pseudo code to illustrate the requirements and

behavior in a real implementation and are not intended as an exact interface definition.

Physical layer requests can be sent at any time after the physical layer has been started and configured

with all relevant parameters.

confirm = request ( SERVICE,

data_buffer,

data_count,

modem_string,

time_of_transmission)

Input:

data_buffer Data to send

data_count Number of octets to send

modem_string Command string for DCE

Output:

time_of_transmission Time that first bit of first octet of message was transmitted

Confirm = 0 Requested service was successful

1 Requested service has failed

2 Service code is not implemented3 Requested service cannot proceed at this time because the physical link is

busy either with a previous requested transaction, current unrequested

transaction or waiting for DCE availability

8/12/2019 DNPBasic4

30/291

DNP Users Group5-2

Service = 0 Send a message specified in data_buffer of size specified in data_count

1 Initialize DCE using string specified in modem_string

2 Connect to PSN using string specified in modem_string

3 Disconnect from PSN

4 Request physical link status, returns 0 if busy and 1 if not busy

Physical layer indications (IND) can be requested at any time by the service user but should be checked

as often as possible in order to obtain received data.

indications = indicate(received_data_buffer,

received_data_count,

time_of_reception)

Output:

received_data_buffer Received message

received_data_count Number of octets in message

time_of_reception Time at which first bit of first octet of message was received

Indications = 0 No indications to report.

1 Physical layer has received a message that has been placed in

received_data_buffer and the number of octets received has been

placed in received_data_count.

2 DCE has connected to PSN (incoming call).

3 DCE has disconnected from PSN (hang up).

4 Physical layer has detected problems with the link or DCE that

makes communication inadvisable or impossible until some later

time. Re-initialization of the DCE may be required.

8/12/2019 DNPBasic4

31/291


6. PHYSICAL LAYERCHARACTERISTICS

6.1 LINE CONFIGURATIONS

Regardless of the physical layer used, there are two physical topologies used to construct a SCADA

communications network. These are direct and serial bus topologies.

The direct topology has two physical nodes with each physical node connected directly to the other.

This is often referred to as point-to-point and can be a direct physical cable from point-to-point, a two

node radio or modem network or a dial-up connection through a PSN (Public Switched Network).

The serial bus topology has more than two physical nodes with each node connected to the same

channel or communication line as every other node in the serial bus network. This is often referred to as

a multi-drop configuration and is commonly made up of many Bell 202 modems with their

outputs/input tied together. In this configuration, there is one node which is deemed to be in control of

the physical network. This is often the SCADA master. This node transmits to multiple-nodes and

receives from multiple nodes. All other nodes in the bus receive from the master node and transmit to

the master node.

The DNP data link supports multiple-master, multiple-slave and peer-to-peer communications.

In peer-to-peer communications, all devices act as slave data links and collision avoidance should be

turned on as no one device has a higher priority and all can transmit spontaneously.

In a multiple-master configuration, the master devices are higher priority than the slave devices.

However, priority has to be assigned amongst the masters.

6.2 MODES OF TRANSMISSION

The physical layer supported by DNP must transmit/receive data in serial mode. Generally, the data unittransferred will be 8 bits in length. The transmission can be asynchronous, synchronous or isochronous

allowing for higher throughput with a synchronous modem. The actual mechanism used has no affect on

the operation of the data link.

6.3 LOCAL LOOP

The termination of the data communications circuit at the communication node (i.e. NOT at the

modem) can be accomplished using a two-wire or four-wire circuit (i.e. TX/RX pair or independent TX

and RX pairs).

The DNP data link can use half-duplex procedures with a 2-wire circuit and full-duplex or half-duplex

procedures with a 4-wire circuit.

The DNP data link can support both full-duplex and half-duplex procedures at the local loop. Both

cases, however will be handled quite differently.

8/12/2019 DNPBasic4

32/291

8/12/2019 DNPBasic4

33/291


7. PHYSICAL LAYER PROCEDURES

7.1 GENERAL CONSIDERATIONS

The purpose of the data link to physical layer interface is to allow the data link to send or receive a

message to or from another data link. To accomplish this, the data link must be able to control when the

transmission of data takes place, detect the presence of data on the physical communication circuit and

use control line signaling for control of the physical circuit. In addition, the master station (or highest

priority device) needs to be able to take control of the communication circuit and block other stations

from transmitting.

In a direct connection type topology, the primary station (initiating station) can only communicate with

one station. If this circuit is four-wire then full-duplex procedures will be used and there will be no

chance of message collisions on the circuit. However, if the circuit is two-wire then half-duplex

procedures will be used. In this case, a collision can occur if both stations attempt to transmit data at the

same time. A direct connect to a dial-up PSN is typically 2-wire but the circuit from the station to the

modem is a 4-wire full-duplex circuit and should be used in a full-duplex fashion. The dial-up modem

must use CTS to hold off the transmitter after RTS is asserted.

In a multi-drop topology, the designated master station can act as a primary station to many secondary

stations. In this case there is a chance of collision in a two-wire or four wire circuit.

In a two-wire circuit, the designated master station messages can collide with any other stations

message and the slave station messages can collide with each other at any time.

In a four wire circuit, the master station messages cannot collide with the slave station messages but the

slave station messages can collide with each other.

7.2 HALF-DUPLEX PROCEDURES

When half duplex procedures are used in a two-wire system, there are several ways to avoid or recover

from a collision on the communication circuit. Regardless of the physical layer used, all physical layers

should be able to return a data carrier detection indication (DCD) which indicates if there is traffic onthe circuit. In a two-wire system, the indication appears when the master or slave is transmitting on the

circuit. When this indication is present, a station is transmitting on the circuit. During this time, no other

station should attempt to transmit on the circuit. When the indication disappears, the circuit is free for

someone to use. The question now is, which station is allowed to transmit on the circuit.

In the point-to-point configuration, either the master or slave station could transmit. In the multi-drop

configuration, either the master or any of many slave stations could transmit. The DNP data link

protocol does not assign priority to either the master or slave message but it is generally accepted in

SCADA that the master should have control of the communication circuit and therefore should transmit

the message (if one is to be sent). Any slave station, if allowed to transmit at this point, could possibly

cause a collision so the slave station must wait some time after detecting the loss of a data carrier before

attempting to send. Before sending, the indication is checked again and if the circuit is still idle then thetransmission can take place. If the circuit is busy then the station must wait again until the indication

disappears and perform the procedure again. The insertion of the time delay after the loss of data carrier

8/12/2019 DNPBasic4

34/291

8/12/2019 DNPBasic4

35/291


7.3.3 Dial-Up Modem

A dial-up modem uses a four-wire full-duplex circuit that typically requires several control signals

(other than DCD) in order to operate. The dial-up circuit is a point-to-point circuit. However, the

meaning of the data carrier signal is quite different than with a direct circuit. The data carrier (DCD)

indicates that the modem is electrically connected to another modem across the PSN. It does notnecessarily mean that data is being transmitted on the circuit. The CTS (Clear To Send) line indicates to

the data link when it is safe to transmit. The DNP data link will assert the RTS (Request To Send) line

before transmitting each frame and wait for the CTS line to go high before transmitting the data. The

RTS line will then be de-asserted. If the DCD line goes low, the data link will assume that a connection

has been lost and attempt to re-dial if needed.

8/12/2019 DNPBasic4

36/291

DNP Users Group7-4

8/12/2019 DNPBasic4

37/291

DNP V3.00 Data Link Layer (Version 0.02) 1

LIST OF ABBREVIATIONS ANDACRONYMS

CRC cyclic redundancy check

DFC data flow control

DIR direction of physical transmission

DNP Distributed Network Protocol

EPA enhanced protocol architecture

FCB frame control bit

FCV frame count valid

IEC International Electrotechnical Commission

IED intelligent electronic device

ISO International Organization for Standardization

LPDU link protocol data unit

LSDU link service data unit

octet 8-bit data object (byte)

OSI Open System Interconnection

PRM primary

8/12/2019 DNPBasic4

38/291

DNP Users Group


DNP V3.00

TRANSPORT FUNCTIONS

Document Version: 0.01Internal File: P009-0PD.TF


8/12/2019 DNPBasic4

39/291

















TRADEMARK NOTICES



8/12/2019 DNPBasic4

40/291

DNP V3.00 Transport Functions (Version 0.01) i

TABLE OF CONTENTS

ABOUT THIS DOCUMENT iii

PURPOSE OF THIS SPECIFICATION iii

WHO SHOULD USE THIS SPECIFICATION iii

HELP AND ADDITIONAL DOCUMENTATION iii

HOW THIS SPECIFICATION IS ORGANIZED iv

CONVENTIONS USED IN THIS SPECIFICATION iv

1. OVERVIEW 1-1

2. TRANSPORT FUNCTIONS 2-1

2.1 TRANSPORT HEADER 2-1

2.2 TRANSPORT HEADER FIELD DEFINITIONS 2-2

2.3 FRAME ASSEMBLING 2-3

2.4 TRANSMISSION OF MESSAGES 2-3

3. TRANSPORT SERVICES AND RESPONSIBILITIES 3-1

3.1 TRANSPORT FUNCTIONS 3-1

3.2 INTERFACE DESCRIPTION 3-2


8/12/2019 DNPBasic4

41/291

DNP Users Groupii

TABLE OF FIGURES

FIGURE 2-1 TRANSPORT LAYER MESSAGE LAYOUT 2-2

FIGURE 2-2 TH BIT DEFINITIONS 2-2

FIGURE 2-3 ASSEMBLING OF DATA FROM THREE DATA FRAMES 2-3

FIGURE 2-4 TRANSMISSION OF A SINGLE FRAME MESSAGE 2-4

FIGURE 2-5 FRAGMENTING OF A MULTI-FRAME APPLICATION MESSAGE 2-4

8/12/2019 DNPBasic4

42/291

DNP V3.00 Transport Functions (Version 0.01) iii

ABOUT THIS DOCUMENT


This document specifies the Distributed Network Protocol (DNP) V3.00 Transport

Functions, transmission procedures and Transport Protocol Data Unit.


This specification is intended for communication engineers and programmers

interested in knowing the function and message format of the DNP V3.00 Transport

Functions. This includes programmers implementing and designing DNP V3.00

Transport Functions software/hardware and quality assurance personnel testing and

verifying implementations of the DNP V3.00 Transport Functions. Application

programmers may find this specification useful in determining how to interface with

and make use of the DNP V3.00 Transport Functions. Familiarity with the ISO-OSI 7-

layer model, IEC 3-layer EPA and IEC TC-57 standards is helpful.


The following documentation may be helpful.

IEC 870-5-1andIEC 870-5-2standards (or drafts), Technical Committee No. 57for data transmission in telecontrol systems

DNP V3.00 Data Object Library(P009-0BL)

DNP V3.00 Application Layer(P009-0PD.APP)

DNP V3.00 Data Link Layer(P009-0PD.DL).

8/12/2019 DNPBasic4

43/291

DNP Users Groupiv


1. OVERVIEW

A general overview of the transport functions.

2. TRANSPORT FUNCTIONS

A detailed description of the packet formats and transmission procedures.

3. TRANSPORT SERVICES AND RESPONSIBILITIES

Services provided by an interface to the transport functions.



In this document, the octet is a term used to refer to an eight bit-data object and is

synonymous with the term byte. The low order bit of an octet is referred to as bit 0 and

the high order bit as bit 7.

Irregular capitalization is used in referencing technical terms which have an associated

verb or noun. For example, data link indications commonly referred to as IND, can

also be described using the word INDication.

8/12/2019 DNPBasic4

44/291

8/12/2019 DNPBasic4

45/291

8/12/2019 DNPBasic4

46/291

DNP V3.00 Transport Functions (Version 0.01) 2-1

2. TRANSPORT FUNCTIONS

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. This pseudo-transport layer acts as the DNP data link

user in a protocol stack consisting of only the DNP Data Link and DNP Application

Layer. This functionality allows the pseudo-transport layer to disassemble one

Transport Service Data Unit (TSDU) into multiple (more than one) Transport ProtocolData Units (TPDUs), or frames, and assemble multiple (more than one) TPDUs into

one TSDU.

This process works as follows:

The pseudo-transport layer takes one TSDU (user data) and breaks it into several

sequenced TPDUs (each with Transport Protocol Control Information (TPCI)). Each

TPDU is sent to the data link layer as Link Service Data Unit (LSDU) for

transmission.

It also works in the reverse fashion. The pseudo-transport layer receives multiple

TPDUs from the data link layer and assembles them into one TSDU.

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 secondary station checks the TH octet on reception of each LSDU for the correct

sequence and builds a TSDU message for higher layers.

The TH contains information that can identify the first frame, last frame and giveevery 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.

2.1 TRANSPORT HEADER

After the data link receives a complete frame, the data is presented to the transport

functions in a format illustrated below. The TH field is stripped out before the frame

is combined with other frames belonging to the same message. Figure 2-1 shows the

structure of a TPDU.

8/12/2019 DNPBasic4

47/291

DNP Users Group2-2

-----------------

| | |

| TH | USER DATA |

| | |

-----------------

Figure 2-1 Transport Layer Message Layout

TH Transport control octet. One octet in length.

USER DATA 1 to 249 octets in length.

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 octetsData link header data count - 5 octets

Transport header - 1 octet

Application user data = 249 octets

2.2 TRANSPORT HEADER FIELD DEFINITIONS

-----------------------------------------------

| | | | | | | | |

| FIN | FIR | | | SEQUENCE | | |

| | | | | | | | |

-----------------------------------------------

BIT 7 6 5 4 3 2 1 0

Figure 2-2 TH Bit Definitions

FIN The final bit indicates that this frame of user data is the last frame of a

sequence which compromises a complete user message.

FIN = 0 More frames follow.

1 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 secondarystation 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.

0 Not the first frame of a sequence.

SEQUENCE The sequence number of the frame is used to check that each frame isbeing received in sequence. It guards against missing or duplicated

frames. All user messages start off with a sequence specified in the

8/12/2019 DNPBasic4

48/291


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 toincrement across message boundaries, i.e. any sequence number is

valid when the FIR bit is set.

2.3 FRAME ASSEMBLING

Figure 2-3 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

--------------

| SOURCE = n |

--------------

--------------

| FIR = 1 |

| FIN = 0 |

| SEQUENCE = 3| Note sequence starts with the value in the frame that has the FIR bit = 1

| USER DATA 0 |

-------------- -----------> -------------

| USER DATA 0 |

-------------

--------------

| SOURCE = n |

--------------

--------------

| FIR = 0 |

| FIN = 0 |

| SEQUENCE = 4|

| USER DATA 1 |

-------------- -----------> -------------

| USER DATA 1 |

-------------

| USER DATA 0 |

-------------

--------------

| SOURCE = n |----------------------------------->

-------------- SOURCE ADDRESS passed to application

--------------

| FIR = 0 |

| FIN = 1 | FIN indicates last frame

| SEQUENCE = 5|

| USER DATA 2 |

-------------- -----------> -------------

| USER DATA 2 | FIN indicated this is the last frame of message

-------------

| USER DATA 1 |

-------------

| USER DATA 0 | complete message passed to application

------------- ----------->

Figure 2-3 Assembling of Data From Three Data Frames

2.4 TRANSMISSION OF MESSAGES

Figure 2-4 illustrates the transmission of a single frame message using the SEND -

CONFIRM frame service. Figure 2-5 illustrates the transmission of a multi-frame

message using the SEND - CONFIRM frame service.

8/12/2019 DNPBasic4

50/291


3. TRANSPORT SERVICES ANDRESPONSIBILITIES

3.1 TRANSPORT FUNCTIONS

This section describes the services offered by the pseudo-transport layer and its

function. The communication requirements of the network layer and the applicationlayer are satisfied by the pseudo-transport layer service primitives.

The pseudo-transport layer is responsible for performing the following functions:

Packing user data into multiple frames (more than one) of the defined DNP V3.00

Data Link frame format and using the services of the DNP V3.00 Data Link for

transmitting the data

Unpacking multiple frames that are received from the data link into user data

Controlling all aspects of the data link excluding data link configuration.

The pseudo-transport layer is responsible for providing the following services: Exchange of SDUs between peer DNP V3.00 pseudo-transport layers

Error notification to transport user

Sequencing of SDUs

Prioritized SDU delivery

Quality SDU delivery.

SDUs will only be exchanged between peer DNP V3.00 pseudo-transport layers.

Error notification is given to the transport user when a response to a request has not

been received.

Priority delivery can be set to EXPEDITED or NORMAL to indicate a high or low

priority request.

Quality delivery can be set to SEND-NO-REPLY or SEND-CONFIRM to indicate

whether or not message acknowledgment is required.

8/12/2019 DNPBasic4

51/291

DNP Users Group3-2

3.2 INTERFACE DESCRIPTION

The pseudo-transport layer service primitives are illustrated in pseudo code to

illustrate the requirements and behavior in a real implementation and are not intended

as an exact interface definition.

Transport request (REQ) services can be used at any time after the transport functions

have been initialized and configured by the system.

confirm = request_transport_service(

SERVICE,

TIME_SERVICE,

destination,

source,

send_data_buffer,send_count,

retry_flag,

time_of_transmission)

Input:

SERVICE Service to perform.

TIME_SERVICE Guaranteed time service to perform.

source Source address to use in sent message.

destination Destination address to use in sent message.

send_data_buffer Data to send in message.

send_count Number of octets in message.

retry_flag Instructs data link layer to retry unacknowledged frames or not.

time_of_transmission Time that first bit of first octet of message is to be sent.

Output:

time_of_transmission Time that first bit of first octet of message was sent

confirm = 0 Requested service is successful.

1 Requested service has failed.

2 Requested SEND data service is terminated by the current

primary station. (reception of a NACK frame from thesecondary station).

3 Service code is not implemented.

4 Requested service cannot proceed at this time because the data

link is busy either with a previous requested transaction, current

unrequested transaction or waiting for physical layer

availability.

8/12/2019 DNPBasic4

52/291


service = 0 Send a message specified in parameters using SEND-

CONFIRM frames. Fails if the data link is busy.

1 Send a message specified in parameters using SEND-NO-

REPLY frames. Fails if the data link is busy.

2 Expedited send a message specified in parameters using SEND-CONFIRM frames. May necessitate canceling the current

secondary transaction if a half-duplex system is used.(i.e. forces

the data link to send a NACK frame instead of a CONFIRM

frame in the next secondary transaction). This action only takes

place if the primary station is using SEND-CONFIRM frames.

3 Expedited send a message specified in parameters using SEND-

NO-REPLY expected frames. In a half-duplex system, this may

mean canceling the current secondary transaction. (as above).

4 Return link status. Return successful if the data link is not busy.

time_service =0 Send message at time specified in time_of_transmission. This

service should have the highest priority.

1 Send message at any time with priority specified.

Data link indications (IND) can be requested at any time by the service user but

should be checked as often as possible in order to obtain received data.

indications = request_data_link_indications(

source_address,

destination_address,

received_data_buffer,received_data_count,

time_of_reception)

Output:

source_address Source address of received message.

destination_address Destination address of received address.

received_data_buffer Received message.

received_data_count Number of octets in message.

time_of_reception Time at which first bit of first octet of message was received.

8/12/2019 DNPBasic4

53/291

DNP Users Group3-4

Indications = 0 No indications to report.

1 Data link has received a valid message that has been placed in

received_data_buffer and the number of octets received has

been placed in received_data_count. The source address of the

received message has been placed in source_address. If the datalink is configured as a master station then the time that the first

bit of the first octet of the message was received has been

placed in time_of_reception. If the data link is configured as an

outstation then the time_of_reception will still be returned but

the service user has to be aware of the possibility of inaccurate

times received before the outstation has been time-

synchronized.

2 Pseudo-transport layer has detected a transaction failure.

8/12/2019 DNPBasic4

54/291

DNP V3.00 Transport Functions (Version 0.01) 1

LIST OF ABBREVIATIONS ANDACRONYMS

CRC cyclic redundancy check

DNP Distributed Network Protocol

EPA enhanced protocol architecture

IEC International Electrotechnical Commission

ISO International Organization for Standardization

octet 8-bit data object (byte)

OSI Open System Interconnection

RTU remote terminal unit

8/12/2019 DNPBasic4

55/291

DNP Users Group


DNP V3.00

APPLICATION LAYER

Document Version: 0.03Internal File: P009-0PD.APP


8/12/2019 DNPBasic4

56/291

















TRADEMARK NOTICES



8/12/2019 DNPBasic4

57/291

DNP V3.00 Application Layer (Version 0.03) v

TABLE OF CONTENTS

ABOUT THIS DOCUMENT IXPURPOSE OF THIS SPECIFICATION ix

WHO SHOULD USE THIS SPECIFICATION ix

HELP AND ADDITIONAL DOCUMENTATION ix

HOW THIS SPECIFICATION IS ORGANIZED x

CONVENTIONS USED IN THIS SPECIFICATION x

1. OVERVIEW 1-11.1 DESCRIPTION AND IEC RELATIONSHIP 1-2

2. MESSAGE FORMATS 2-12.1 APPLICATION REQUEST FORMAT 2-2

2.2 APPLICATION RESPONSE FORMAT 2-2

3. DEFINITION OF DNP MESSAGE FIELDS 3-13.1 APPLICATION HEADERS 3-1

3.2 COMMUNICATION FLOW CONTROL 3-2

3.3 MASTER REQUEST & UNSOLICITED RESPONSE COLLISIONS 3-8

3.4 ERROR RECOVERY 3-11

3.5 FUNCTION CODES 3-12

3.6 INTERNAL INDICATIONS 3-14

3.7 OBJECT HEADER 3-16

4. DETAILED FUNCTION CODE DESCRIPTIONS 4-14.1 CONFIRM (FUNCTION CODE 0) 4-1

4.2 READ (FUNCTION CODE 1) 4-24.3 WRITE (FUNCTION CODE 2) 4-13

4.4 SELECT (FUNCTION CODE 3) 4-15

4.5 OPERATE (FUNCTION CODE 4) 4-17

4.6 DIRECT OPERATE (FUNCTION CODE 5) 4-17

4.7 DIRECT OPERATE - NO ACKNOWLEDGEMENT (FUNCTION CODE 6)4-18

4.8 IMMEDIATE FREEZE (FUNCTION CODE 7) 4-18

4.9 IMMEDIATE FREEZE - NO ACKNOWLEDGEMENT (FUNCTION CODE

8) 4-19

4.10 FREEZE AND CLEAR (FUNCTION CODE 9) 4-19

4.11 FREEZE AND CLEAR - NO ACKNOWLEDGEMENT (FUNCTION CODE10) 4-19

4.12 FREEZE WITH TIME (FUNCTION CODE 11) 4-20

8/12/2019 DNPBasic4

58/291

DNP Users Groupvi

4.13 FREEZE WITH TIME - NO ACKNOWLEDGEMENT (FUNCTION CODE

12) 4-21

4.14 COLD RESTART (FUNCTION CODE 13) 4-21

4.15 WARM RESTART (FUNCTION CODE 14) 4-21

4.16 INITIALIZE DATA (FUNCTION CODE 15) 4-22

4.17 INITIALIZE APPLICATION (FUNCTION CODE 16) 4-224.18 START APPLICATION (FUNCTION CODE 17) 4-23

4.19 STOP APPLICATION (FUNCTION CODE 18) 4-23

4.20 SAVE CONFIGURATION (FUNCTION CODE 19) 4-24

4.21 ENABLE SPONTANEOUS MESSAGES (FUNCTION CODE 20) 4-25

4.22 DISABLE SPONTANEOUS MESSAGES (FUNCTION CODE 21) 4-25

4.23 ASSIGN CLASSES (FUNCTION CODE 22) 4-25

4.24 DELAY MEASUREMENT (FUNCTION CODE 23) 4-26

5. CLASSES 5-1

6. TIME SYNCHRONIZATION 6-1

7. BINARY INPUT WITH TIME EVENTS 7-1

8. FILE TRANSFER 8-18.1 FILE IDENTIFIER OBJECTS PERFORMING WRITE FUNCTIONS 8-1

8.2 FILE IDENTIFIER OBJECT PERFORMING READ FUNCTIONS 8-5

LIST OF ABBREVIATIONS AND ACRONYMS 1

8/12/2019 DNPBasic4

59/291

8/12/2019 DNPBasic4

60/291

DNP Users Groupviii

FIGURE 4-14 MASTER SELECTION OF TWO OUTPUTS OR SETPOINTS 4-18

FIGURE 4-15 MASTER IMMEDIATE FREEZE CONTROL MESSAGE 4-18

FIGURE 4-16 OUTSTATION RESPONSE TO IMMEDIATE FREEZE 4-18

FIGURE 4-17 MASTER IMMEDIATE FREEZE NO-ACK CONTROL MESSAGE4-19

FIGURE 4-18 MASTER FREEZE AND CLEAR CONTROL MESSAGE 4-19

FIGURE 4-19 OUTSTATION RESPONSE TO FREEZE AND CLEAR REQUEST 4-19FIGURE 4-20 MASTER FREEZE AND CLEAR NO-ACK CONTROL MESSAGE4-20

FIGURE 4-21 MASTER FREEZE WITH TIME MESSAGE 4-20

FIGURE 4-22 OUTSTATION RESPONSE TO FREEZE WITH TIME 4-20

FIGURE 4-23 MASTER FREEZE WITH TIME NO-ACK MESSAGE 4-21

FIGURE 4-24 MASTER COLD RESTART CONTROL MESSAGE 4-21

FIGURE 4-25 OUTSTATION RESPONSE TO COLD RESTART REQUEST 4-21

FIGURE 4-26 MASTER WARM RESTART CONTROL MESSAGE 4-22

FIGURE 4-27 OUTSTATION RESPONSE TO WARM RESTART REQUEST 4-22

FIGURE 4-28 MASTER INITIALIZE DATA CONTROL MESSAGE 4-22

FIGURE 4-29 OUTSTATION RESPONSE TO INITIALIZE DATA REQUEST 4-22FIGURE 4-30 MASTER INITIALIZE APPLICATION CONTROL MESSAGE 4-22

FIGURE 4-31 OUTSTATION RESPONSE AFTER INITIALIZING

APPLICATION(S) 4-23

FIGURE 4-32 MASTER START APPLICATION CONTROL MESSAGE 4-23

FIGURE 4-33 OUTSTATION RESPONSE AFTER STARTING

APPLICATION(S) 4-23

FIGURE 4-34 MASTER STOP APPLICATION CONTROL MESSAGE 4-24

FIGURE 4-35 OUTSTATION RESPONSE AFTER STOPPING

APPLICATION(S) 4-24

FIGURE 4-36 MASTER SAVE CONFIGURATION CONTROL MESSAGE 4-24

FIGURE 4-37 OUTSTATION RESPONSE AFTER SAVINGCONFIGURATION(S) 4-24

FIGURE 4-38 MASTER REQUEST TO ENABLE SPONTANEOUS MESSAGES 4-25

FIGURE 4-39 OUTSTATION RESPONSE 4-25

FIGURE 4-40 MASTER REQUEST TO DISABLE SPONTANEOUS MESSAGES 4-25

FIGURE 4-41 OUTSTATION RESPONSE TO DISABLE SPONTANEOUS

MESSAGE 4-25

FIGURE 4-42 MASTER REQUEST TO ASSIGN CLASSES TO DATA 4-26

FIGURE 4-43 OUTSTATION RESPONSE TO ASSIGN CLASSES 4-26

FIGURE 4-44 MASTER REQUEST TO INITIATE DELAY MEASUREMENT 4-26

FIGURE 4-45 OUTSTATION REPONSE TO DELAY MEASUREMENTREQUEST 4-26

FIGURE 8-1 PASSING A FILE IDENTIFIER OBJECT VIA DATA

CONCENTRATORS 8-4

8/12/2019 DNPBasic4

61/291

DNP V3.00 Application Layer (Version 0.03) ix

ABOUT THIS DOCUMENT


This document specifies the Distributed Network Protocol (DNP) application layer

services and message format. This document specifies the Application Protocol Data

Unit (APDU), application data flow control and any specific information pertaining to

DNP application layer services.


This specification is for people who need to know the structure and meaning of the

fields that make up the application layer message.

This includes programmers implementing and designing an application and Quality

Assurance personnel testing and verifying implementations of the application layer.


The following documentation may be helpful.

DNP V3.00 Data Object Library (P009-0BL).

8/12/2019 DNPBasic4

62/291

DNP Users Groupx


1. OVERVIEW

A general overview of the application layer.

2. MESSAGE FORMATS

A definition of the request and response formats.

3. DEFINITION OF THE DNP MESSAGE FIELDS

A detailed explanation of the message field.

4. DETAILED FUNCTION CODE DESCRIPTION

A description of the function codes.

5. CLASSESA description of the classes.

6. TIME SYNCHRONIZATION

A description of time synchronizing.

7. BINARY INPUT WITH TIME EVENTS

A description of binary input with time events.

8. FILE TRANSFER

A description of file transfer.



The term octet used in this document refers to an eight-bit data object and is

synonymous with the term byte. The low order bit of an octet is numbered as bit zero

(0) and the high order is bit seven (7). Data octets illustrated in this document are

received and transmitted from left to right.

8/12/2019 DNPBasic4

63/291

DNP V3.00 Application Layer (Version 0.03) 1-1

1. OVERVIEW

This document defines the Harris Distributed Network Protocol (DNP) application

layer APDU format and services.

The ISO OSI (International Standards Organization Open System Interconnection)

model specifies seven layers. The International Electrotechnical Commission (IEC)

specifies a simplified model consisting of the physical, data link and application layers

only. This is termed the Enhanced Performance Architecture (EPA). This documentdefines the third layer of this EPA or the Application Layer. The data link layer is

defined in:

Distributed Network Protocol Version 3.00:Data Link Layer

(P009-0PD.DL).

Harris Canada Inc. has developed the DNP for application in both SCADA and

distributed automation (DA) systems. Primary focus has been on the current and

future needs of these areas. The DNP is suitable for use in highly secure, moderate

speed and moderate throughput applications. The protocol is highly flexible and

open-ended without any target hardware specific constructs.

Figure 1-1 on the following page shows the EPA structure and how it fits into the

entire communication system. As shown, the User Layer interfaces to the Application

Layer in one place only implying that the user has no need to know of the other

elements of the communication system except the Application Layer interface. The

User Layer makes use of the Application Layer to send/receive complete SCADA/DA

messages to/from a master station or outstation.

Figure 1-1 Context of EPA

User Layer

Application Layer

Data Link Layer

Physical Layer

Communication Medium

8/12/2019 DNPBasic4

64/291

DNP Users Group1-2

1.1 DESCRIPTION AND IEC RELATIONSHIP

The DNP Application Layer APDU is based in principle on the IEC 870-5-3 and 870-

5-4 draft documents as prepared by TC-57 WG 03. Structurally, the Application

Layer PDU (Protocol data Unit) fits the IEC description of an APDU. The user sends

Application User Data to the Application Layer where it is converted to ASDU(Application Service Data Unit). In DNP, the Application User Data is converted into

multiple ASDUs. Each ASDU is then prefixed by APCI (Application Protocol

Control Information) which is then packaged as an APDU. In DNP, each APDU that

is part of the larger multi-APDU is referred to as a fragment and there is a restriction

that each fragment contains complete data objects only and that the function code

portion of the APCI (Application Protocol Control Information) is identical in each

fragment of the same message or multi-APDU. That is, there will be no fragmentation

of information objects between APDUs and the same operation must be requested of

each object in the message. This is to ensure that each fragment on its own can be

processed and also implies that each ASDU contains only complete data objects. Inreverse, the Application Layer receives multiple APDU (one at a time) where it

removes the APCI to obtain the ASDU and assembles the ASDUs into Application

User Data.

8/12/2019 DNPBasic4

65/291


2. MESSAGE FORMATS

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.

Figure 2-1 below shows the sequence of Application Layer messages between one

master and one Outstation.

Master Outstation

Send Request --------------------> Accept request and process

8/12/2019 DNPBasic4

66/291

DNP Users Group2-2

fragment. This is to ensure that devices can process a request and build and more

importantly send a response before the next request is received. Otherwise, multi-

fragment messages may require multi-fragment responses which may require more

message storage than the device has available.

2.1 APPLICATION REQUEST FORMAT

The application request message format (APDU) is illustrated in Figure 2-2. 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 Identifiers (DUI) or object headers and

optional associated Information Objects (IO) or data fields. The object header can

specify 0 or more en that returned by the receiving station or that follow the header in

the message.

! DUI ! IO .. IO ! DUI ! IO !"################$################$######%....##############$######'!Request Header !Object Header !data ! !Object Header !data !! ! ! ! ! ! !###############$################(######).....*###############(######'

! APCI ! ASDU !

Figure 2-2 Application Request Format

Request Header The request header identifies the purpose of the message and

consists of APCI (Application Protocol Control Information).

Object Header This header identifies the data objects that follow.

Data Data object(s) of the type specified in the object header.

2.2 APPLICATION RESPONSE FORMAT

The response from an Outstation to an application layer request APDU or the

unsolicited response from an outstation have the format illustrated in Figure 2-3. 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. The response ASDU has the same format of the request message with one

notable exception (explained in Section 3).

8/12/2019 DNPBasic4

67/291


! DUI ! IO .. IO ! DUI ! IO !"################$################$######%....##############$######'!Response Header!Object Header !data ! !Object Header !data !! ! ! ! ! ! !###############$################(######).... *###############(######'! APCI ! ASDU !

Figure 2-3 Application Response Format

Response Header The response header identifies the purpose of the message and

consists of APCI (Application Protocol Control Information).

Object Header This header identifies the data objects that follow.

Data Data object(s) of the type specified in the object header.

8/12/2019 DNPBasic4

68/291

8/12/2019 DNPBasic4

69/291

DNP V3.00 Applicatio

DNPBasic4

Documents