Data Link

DOCUMENT REVISION HISTORY

Name of Document: DNP V3.00 Data Link Layer Protocol DescriptionNetwork File Name: P009-0PD.DL

Original Author: Malcolm Smith/Jim McFadyenDate and Version of Preliminary Release: September 1991 Version 0.00Associated Software Release(s): DNP V3.00

Revisions Since Preliminary Release

Date Version By Whom: Pages Affected:

Reason for Changes:

Sept. 30/91 0.00A N. Male All Renamed and relocated from O:\DOCUMENT\OTHER\DOC0361.wp to N:\APPL\P009 0FS.DL Reformatted to WINC standards.

Nov. 11/91 0.00B J.McFadyen Corrected errorsNov. 18/91 0.00C J. McFadyen Minor correctionsJul. 24/92 0.00D MCH 2-11 Reversed MSB and LSB in Figure 2-15

and accompanying text, as per J. McFadyen.

Aug. 17/92 0.01A MS All Changed to meet IEC conventionsOct. 22/92 0.01B MS Re-added time-sync functionality to

Data Link and fixed a problem with data frame duplication.

Oct. 27/92 0.01C MS Added time-sync accuracy to TIME OF DAY messages

Nov. 8/92 0.01D MS All Adopted fully-balanced transmission procedures in order to become more IEC compliant. Removed time-synchronization functions. Removed Transport Functions section.

Nov. 24/92 0.02 LA All Reformatted to WI standards.Jan. 22/93 0.02 MS vi,1-1,2-2 Added marketing commentsJuly. 20/93 0.02 MS i,ii Removed IEC conformance section

from Chapter 2 and created new Chapter 2. Renamed old chapter 2 to Chapter 3.

1-1 Changed 'polling' to 'polled' in last paragraph

2-1 Channel failover section changed 'was intended to communicate' to 'communicates'

Date Version By Whom: Pages Affected:

Reason for Changes:

2-2 Paragraph 1 removed 'Chapter 2' of line 2 to clarify sentence. Removed paragraph 2 as it is confusing. Paragraph 3, changed 'spontaneous' to 'unsolicited' and removed 'sub-master station' references to make it easier to follow. Paragraph, changed wording to suggest 'compatible' schemes.

2-3 Paragraph 3, explained better.2-5 USER DATA section explained that

there are 16 octets per block except the last block (previously it was unclear)

2-7 FCB, removed 'properly' from last paragraph as it is meaningless. FCV changed 'frame count bit valid bit' to 'frame count valid bit'

2-9,2-10 Simplified greatly2-11,2-12 Simplified greatly2-14 Defined CRC algorithm2-15 Corrected error in diagram2-20 Corrected spelling error2-21 Removed misplaced graphic from page

and corrected error2-23 Removed 'or will not' from line 4 as it is

misleading3-1,3-2 Removed all references to

"configurable" parameters as this is implementation specific. End of 3-2, removed last sentence as it is implementation specific.

4-4 Added 'DNP Data Link to Physical Layer Implementation Issues document' as a section of the Physical Layer section in order to explain some of the physical layer issues and usage of the physical layer in the DNP data link layer.

G-1,G-2 Removed some unneeded and incorrect definitions

Aug.30/93 0.02 J.Bhat All Checked for Grammar, Spelling, Structure and Formatting

Sept. 01/93 0.02 AV All Revisions as per C. Heune.May 30/97 0.02 S. Tessari All Converted to MSWord 6.0.

DNP Users Group

DNP PRODUCT DOCUMENTATION

DNP V3.00DATA LINK LAYER

Document Version: 0.02Internal File: P009-0PD.DL

Associated Software Release: DNP V3.00

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 Harris Corporation 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.

TABLE OF CONTENTS

ABOUT THIS DOCUMENTPURPOSE OF THIS SPECIFICATIONWHO SHOULD USE THIS SPECIFICATIONHELP AND ADDITIONAL DOCUMENTATIONHOW THIS SPECIFICATION IS ORGANIZEDCONVENTIONS USED IN THIS SPECIFICATION

1. OVERVIEW

2. IEC CONFORMANCE2.1 CHANNEL FAILOVER2.2 FRAME FORMAT AND PROCEDURES2.3 LENGTH, CONTROL AND ADDRESS FIELDS

3. DNP DATA LINK DESCRIPTION3.1 PURPOSE OF THE DATA LINK LAYER3.2 FT3 FRAME FORMAT3.3 DATA LINK HEADER FRAME FIELDS3.4 USER DATA3.5 CRC FIELDS3.6 DATA LINK FUNCTION CODES3.7 TRANSMISSION PROCEDURES

4. DATA LINK SERVICES AND RESPONSIBILITIES4.1 DATA LINK FUNCTIONS4.2 INTERFACE DESCRIPTION

5. PHYSICAL LAYER INTERFACE5.1 PHYSICAL LAYER DESCRIPTION

6. PHYSICAL LAYER CHARACTERISTICS6.1 LINE CONFIGURATIONS6.2 MODES OF TRANSMISSION6.3 LOCAL LOOP

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

7. PHYSICAL LAYER PROCEDURES7.1 GENERAL CONSIDERATIONS7.2 HALF-DUPLEX PROCEDURES7.3 FULL-DUPLEX PROCEDURES

LIST OF ABBREVIATIONS AND ACRONYMS

DNP Users Groupii

TABLE OF FIGURES

FIGURE 3-1 FT3 FRAME FORMATFIGURE 3-2 CONTROL OCTET BIT DEFINITIONSFIGURE 3-3 TABLE OF PRIMARY AND SECONDARY FUNCTION CODESFIGURE 3-4 DESTINATION ADDRESS FORMATFIGURE 3-5 SOURCE ADDRESS FORMATFIGURE 3-6 CRC ORDERINGFIGURE 3-7 RESET OF SECONDARY LINKFIGURE 3-8 RESET OF USER PROCESSFIGURE 3-9 SEND FROM STATION A/CONFIRM FROM STATION BFIGURE 3-10 SEND FROM STATION B/CONFIRM FROM STATION AFIGURE 3-11 SEND MULTIPLE FRAMES FROM STATION A/CONFIRM FROM

STATION BFIGURE 3-12 FRAME COUNT BIT OPERATIONFIGURE 3-13 FRAME COUNT BIT OPERATIONFIGURE 3-14 SEND-NO-REPLY EXPECTED FROM STATION AFIGURE 3-15 SEND FROM STATION B/NACK FROM STATION AFIGURE 3-16 REQUEST/RESPOND FRAME AND DFC BIT USAGE

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

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-1 and IEC 870-5-2 standards (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).

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 CONFORMANCEDetails the differences between DNP and the IEC TC-57 standards.

3. DNP DATA LINK DESCRIPTIONDescribes the DNP data link frame format, function codes and procedures.

4. DATA LINK SERVICES AND RESPONSIBILITIESDescribes the services that the data link provides to higher layers.

5. PHYSICAL LAYER INTERFACEDescribes the service interface provided by the physical layer to the data link.

6. PHYSICAL LAYER CHARACTERISTICSDescribes the physical layer used with the DNP data link.

7. PHYSICAL LAYER PROCEDURESDescribes how the DNP data link uses the physical layer.


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.

DNP Users Groupvi

1. OVERVIEW

This document defines the Distributed Network Protocol (DNP) V3.00 Data Link layer, Link Protocol Data Unit (LPDU), as well as data link layer services and transmission procedures. Master stations, submaster stations, outstations and intelligent electronic devices (IEDs) can use this data link to pass messages between primary (originating) stations and secondary (receiving) stations. In this protocol, master stations, submaster stations, outstations and IEDs are both originators (primary stations) and receivers (secondary stations).

The IEC 870-5-1 and IEC 870-5-2 standards set out by the International Electrotechnical Commission (IEC), Technical Committee No. 57 for data transmission in telecontrol systems were used as a basis for developing the DNP V3.00 Data Link layer.

The DNP V3.00 Data Link layer supports polled and quiescent telecontrol systems and is designed to operate with connection and connection-less orientated, asynchronous or synchronous bit-serial physical layers such as RS-232C, RS-485 and fibre transceivers. Fully-balanced transmission procedures were adopted to support spontaneous transmissions from outstations, IEDs or submaster stations not designated as master stations.

The ISO OSI based model supported by this protocol specifies physical, data link and application layers only. This is termed the Enhanced Performance Architecture (EPA). However, to support advanced RTU functions and messages larger than the maximum frame length as defined by the IEC document 870-5-1, the DNP Version 3 Data Link is intended to be used with a pseudo-transport layer which implements as a minimum message assembly and disassembly.

This pseudo-transport layer is described in the document, DNP V3.00 Transport Functions (P009-0PD.TF). It is stressed, however, that these transport functions are not a part of the data link but are needed to support advanced RTU functions.

DNP V3.00 Data Link Layer (Version 0.02) 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 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. 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 followed with the note that the Address field is 2 octets in length and specifies the destination station address and the Link User Data field is used as a 2 octet source station address.

Fully-balanced transmission procedures as specified by IEC 870-5-2 were 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).

DNP Users Group2

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 for connecting 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.


│<──────────────────────────── Block 0 ────────────────────────>│<- Block 1 ->│ |<- Block n ->|├───────┬───────┬────────┬─────────┬─────────────┬────────┬─────┼───────┬─────┤ -------------│ START │ START │ LENGTH │ CONTROL │ DESTINATION │ SOURCE │ CRC │ USER │ CRC │ ... | USER | CRC |│ 0x05 │ 0x64 │ │ │ │ │ │ DATA │ │ | DATA | |├───────┴───────┴────────┴─────────┴─────────────┴────────┴─────┼───────┴─────┘ -------------│<─────────────────── Fixed Length Header ─────────────────────>│<──────────── Body ------------->| 10 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.

DNP Users Group2

┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐ │ │ 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 Physical transmission direction1 = station A to station B0 = station B to station A

PRM Primary Message1 = frame from primary (initiating station)0 = frame from secondary (responding station)

FCB Frame count bit

FCV Frame count bit valid1 = Frame count bit is valid0 = 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 BDIR = 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 stationPRM =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 ignoredFCV =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.

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 │ - ││ │ │ │ ││ │ │ │ │└──────────┴─────────────────────────────┴──────────────────────────┴─────┘

DNP Users Group4

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 │└──────────┴─────────────┴──────────────────────────────────────────┘

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 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) │ │ │ │ └────────────────────────────┴──────────────────────────┘

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 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 + X6 + X5 + X2 + 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' = 216M + F' and T' will be transmitted (additionally we define T = 216M + 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 216M/P is used as F in the block so that 216M/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=216M + R then, T/P = (216M + 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:(1) Take the user data block M with k data bits.(2) Multiply M by 216 to obtain 216M.(3) Divide this number (module-2) by P (17-bits) to get R (16-bits).(4) Invert R bit-wise to get R'.(5) Append R' to 216M and transmit as a block (T').

DNP Users Group6

To receive a block:(1) Receive a block (T') (k+16 bits).(2) Invert R'(16-bits) in T'(k+16 bits) to get T (k+16 bits).(3) Divide T (module-2) by P (17-bits) to get the remainder.(4) If the remainder is not 0 then there is an error in the block else

the block is good.

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 ││ │ │

Figure 3-6 CRC Ordering

3.6 DATA LINK FUNCTION CODES

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

3.6.1.1 Primary Transaction

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

Send RESET frame with FCV=0, FCB=x, PRM=1, DIR=xWait the pre-determined time-out period for an ACK frame from the secondary station.


If ACK frame is received, set FCB status to 1 (i.e. next frame sent to secondary with FCV valid should have FCB=1) and exit loop.If frame is not received then go to top of loop and re-tryEnd do loop

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, the secondary station should be considered off-line and a negative INDication should be sent to the data link user.

3.6.1.2 Secondary Transaction

After start-up or after transaction failure do:Wait for reception of RESET command with FCV=0, FCB=x, PRM=1, DIR=x.

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 link user).

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

DNP Users Group8

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. The transmission procedures are described below:


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.


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:

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 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:



Send Unconfirmed User Data frame with PRM=1, DIR=x, FCV=0, FCB=x.Announce positive INDication to data link user.


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) <─────────────┴─────────────┘ (IND)Positive Reset

Next FCB=1 Expected FCB=1

Figure 3-7 Reset of Secondary Link

3.7.2 Reset of User Process

In Figure 3-8, a primary station sends a SEND-CONFIRM Reset User Process frame to a secondary station. The secondary station receives the message and responds with an ACK confirm frame.

DNP Users Group10

Reset User ┌─────────┐(REQ) │ │ │ SEND │ │ │ └─────────┴───────────> ┌─────────────┐ │ CONFIRM │(IND) <─────────────┴─────────────┘ (IND)Positive Reset User

Figure 3-8 Reset of User Process

3.7.3 Send/Confirm User Data

In Figure 3-9, the designated master station acting as a primary station sends a SEND-CONFIRM frame to a non-master station acting as a secondary station. This is the first frame with FCV valid after the secondary link was reset (above) so FCB = 1 in the SEND frame. The secondary station expects FCB to be 1 since this is the first frame (with FCV valid) after the link was reset (above) and sends a CONFIRM frame. The master station upon receiving the CONFIRM assumes the message was correctly received and INDicates success to the master station data link user.

STATION A STATION B

┌───────────┐(REQ) │ │ Expected FCB=1 │ SEND │ │ FCB=1 │ └───────────┴───────────> ┌─────────────┐ │ CONFIRM │ │ │ <─────────────┴─────────────┘(IND) (IND)Positive Data

Figure 3-9 SEND From Station A/CONFIRM From Station B

In Figure 3-10, a non-master station acting as a primary station sends a SEND-CONFIRM frame to a designated master station acting as a secondary station. Since this is the second frame after the secondary link has been reset the FCB = 0 in the SEND frame. The secondary expects FCB to be 0 since this is the second frame received after the link was reset. A CONFIRM frame is sent in response. The non-master station upon receiving the CONFIRM INDicates success to the non-master station data link user.

┌──────────┐ │ │ │ SEND │(REQ)Expected FCB=0 │ FCB=0 │ ┌─────────────┐<────────────┴──────────┘ │ CONFIRM │ │ │ └─────────────┴───────────> (IND) Positive(IND) User Data

Figure 3-10 SEND From Station B/CONFIRM From Station A

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


(REQ 1) ┌─────────┐ │ SEND │ │ FCB=1 │ └─────────┴───────────> ┌───────────┐ Expected FCB=1 │ CONFIRM │ │ │(IND) Positive <────────────┴───────────┘ (IND) User Data(REQ 2) ┌─────────┐ │ SEND │ │ FCB=0 │ Expected FCB=0 └─────────┴─────────────> ┌───────────┐ │ CONFIRM │ │ │(IND) Positive <────────────┴───────────┘ (IND) User Data(REQ 3) ┌─────────┐ │ SEND │ │ FCB=1 │ Expected FCB=1 └─────────┴─────────────> ┌───────────┐ │ CONFIRM │ │ │(IND) Positive <────────────┴───────────┘ (IND) User Data

Figure 3-11 SEND Multiple Frames From Station A/CONFIRM From Station B

In Figure 3-12, the designated master acting as primary sends a one frame message to the secondary non-master. This example illustrates what happens when the CONFIRM from the secondary station is lost.

┌─────────┐(REQ) │ │ │ SEND │ Expected FCB=1 │ FCB=1 │ t DAB ─┬─ └─────────┴───────────> ┌───────────┐ │ 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=1 │ └─────────┴───────────> ┌───────────┐ send data is ignored, unexpected FCB │ │ but another confirm is sent │ CONFIRM │ │ │ <────────────┴───────────┘(IND) Positive

Figure 3-12 Frame Count Bit Operation

In Figure 3-13, the designated master acting as primary sends a two frame message to the secondary non-master. This example illustrates what happens when the SEND frame from the primary station is lost.

DNP Users Group12

┌─────────┐(REQ) │ │ │ SEND │ Expected FCB = 0 │ FCB=0 │ └─────────┴───────────> ┌───────────┐ │ CONFIRM │ tBA │ │(IND) Positive┌─────────┐<────────────┴───────────┘ (IND) User Data │ SEND │ │ FCB=1 │ tAB └─────────┴──> (lost or garbled)

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

┌─────────┐ │ SEND │ │ FCB=1 │ Expected FCB=1 └─────────┴───────────> ┌───────────┐ │ CONFIRM │ │ │(IND) Positive ───────── <────────────┴───────────┘ (IND) User Data

Figure 3-13 Frame Count Bit Operation

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 1) │ SEND │Expected FCB=1 │ FCB=1 │ ┌───────────┐<────────────┴─────────┘ │ CONFIRM │ │ │(IND) Positive └───────────┴───────────> (IND) Positive ┌─────────┐ (REQ 2) │ SEND │ │ FCB=0 │ ┌───────────┐─────────────┴─────────┘ │ NACK │ └───────────┴───────────> (IND) Negative(IND) Negative

Figure 3-15 SEND From Station B/NACK From Station A

3.7.6 Request/Respond

In Figure 3-16, a primary station SENDs consecutive frames to a secondary station. When the secondary station cannot receive any more frames, the CONFIRM message contains the DFC bit set. The primary station will, upon reception of the CONFIRM, stop SENDing data frames to the secondary station but will instead periodically REQUEST the status of the secondary by sending a REQUEST-RESPOND frame. The secondary will RESPOND to the REQUEST frame with the current state of the DFC. If the secondary is ready to receive more data, the DFC returned will be 0 otherwise the DFC returned will be 1. When the primary station recognizes DFC = 0 in the RESPOND frame, the transmission of SEND frames will continue.

DNP Users Group14

┌───────────┐(REQ 1) │ │ │ SEND │ │ FCB=0 │ └───────────┴───────────> ┌───────────┐ │ CONFIRM │(IND) Positive │ DFC=0 │Receipt of CONFIRM frame ┌───────────┐<────────────┴───────────┘ (IND) User Datawith DFC = 0 is the │ SEND │condition for │ │transmission of the next │ FCB=1 │SEND user data frame. └───────────┴───────────> ┌───────────┐ │ CONFIRM │ │ DFC=1 │(IND) Positive ┌───────────┐<────────────┴───────────┘ (IND) User Data │ REQUEST │ but buffers full now │ RESPOND │ │ │ └───────────┴───────────> ┌───────────┐ │ CONFIRM │ │ DFC=1 │ ┌───────────┐<────────────┴───────────┘ │ REQUEST │ │ RESPOND │ │ │ └───────────┴───────────> ┌───────────┐(REQ 3) │ CONFIRM │ │ DFC=0 │Receipt of CONFIRM frame ┌───────────┐─────────────┴───────────┘with DFC = 0 is the │ SEND │condition for │ │transmission of the next │ FCB=0 │ (IND)SEND user data frame. └───────────┴───────────> ┌───────────┐ │ CONFIRM │ │ DFC=0 │ <────────────┴───────────┘ (IND) User Data

Figure 3-16 REQUEST/RESPOND Frame and DFC Bit Usage


4. DATA LINK SERVICES AND RESPONSIBILITIES

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 layer service 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.

confirm = request_data_link_service( SERVICE,TIME_SERVICE,destination,source,send_data_buffer,send_count,retry_flag,time_of_transmission

)

Input:SERVICE Service to performTIME_SERVICE Guaranteed time service to performsource Source address to use in sent messagedestination Destination address to use in sent messagesend_data_buffer Data to send in messagesend_count Number of octets in messageretry_flag Instructs data link layer to retry unacknowledged frames or nottime_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

DNP Users Group2

Confirm = 0 Requested service was successful1 Requested service has failed2 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 implemented4 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

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 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 messagedestination_address Destination address of received addressreceived_data_buffer Received messagereceived_data_count Number of octets in messagetime_of_reception Time at which first bit of first octet of message was received


Indications = 0 No indications to report1 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.

DNP Users Group4

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 of the 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 senddata_count Number of octets to sendmodem_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 successful1 Requested service has failed2 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

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

1 Initialize DCE using string specified in modem_string2 Connect to PSN using string specified in modem_string3 Disconnect from PSN4 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 messagereceived_data_count Number of octets in messagetime_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.

DNP Users Group2

6. PHYSICAL LAYER CHARACTERISTICS

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 unit transferred 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.

DNP Users Group2

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 on the 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 the transmission 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 allows the master to take control of the circuit (if needed at that time) and shuts out the other station (because the carrier indication is caused by the masters transmission).

7.2.1 Point-to-Point

In a point-to-point configuration this time delay only needs to be as long as the time needed for the master to detect the loss of data carrier and begin the transmission of the message (plus any propagation delays in the system) (Master_min time).

7.2.2 Multi-Point

In a multi-drop configuration, this time delay needs to be different for each slave station. One possibility is to configure each slave station to wait a steadily increasing amount of time (no duplicate times and all greater than Master_Min time) hence assigning priorities to the stations. In this way, stations which are important in the system can be given higher priority and collisions will rarely happen (only if device timing is bad or the system is poorly configured). However, if the high priority slave stations have nothing to transmit, then there is a lot of time (and hence bandwidth) wasted.

Another scheme is to configure each slave station to wait a random time between Master_Min and Max. This Max is a function of the number of slave stations in the system. In this way, each station can be configured in the same way and the average time wasted is about (Max - Master_Min) / 2. However, a collision is still possible if two stations decide to wait for the same amount of time. The smaller the Max value the greater the chance of this happening.

7.3 FULL-DUPLEX PROCEDURES

When full-duplex procedures are used in a four-wire direct connection circuit, there is no chance of collision because there exists two independent channels for both the reception and transmission of messages. In this case, both the master and slave stations can

DNP Users Group2

transmit data at any time when needed. The master still has control of the circuit because there is only one station to talk to, hence no need to block out other stations.

When full-duplex procedures are used in a four-wire multi-drop system the problem of collision avoidance increases in complexity. The reason for this lies in the fact that a physical communication circuit that has two independent channels usually can only detect traffic in the receive direction. In a two-wire system, any traffic in the receive or transmit direction can be detected because they are both on the same circuit but in a four-wire system the transmitted and received messages travel on different circuits.

7.3.1 Point-to-Point

In a point-to-point, full-duplex system both master and slave can transmit at the same time without collision so there is no need for collision detection/avoidance or access mechanisms in this case.

7.3.2 Multi-Point

In a full-duplex, multi-drop system, the master station can transmit messages at any time without collision but may not receive the data link confirmation immediately because another station (acting as a primary station) may have taken control of the master's receive circuit before the secondary station or a collision occurred.

The slave station's messages will collide at random because there is no way for the station to know if another station has control of the master's receive circuit. The solution is to make use of a control circuit (RTS in the case of RS-232) to signal the slave stations when another slave station has taken control of the master's receive circuit. This signal must be an input to the slave stations which indicates a request to take control of the master's receive circuit.

One simple solution is to allow slave messages to collide. In this way, the master can still send out high priority messages but there may be a collision which will cause a secondary station to time-out.

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 not necessarily 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.


DNP Users Group4


CRC cyclic redundancy check

DFC data flow controlDIR direction of physical transmissionDNP Distributed Network Protocol

EPA enhanced protocol architecture

FCB frame control bitFCV frame count valid

IEC International Electrotechnical CommissionIED intelligent electronic deviceISO International Organization for Standardization

LPDU link protocol data unitLSDU link service data unit

octet 8-bit data object (byte)OSI Open System Interconnection

PRM primary


Data Link

Documents

dnp data link layer

dnp data link description

data link functions

data link services

dnp documents

physical layer section

physical layer description

user data section