• Author / Uploaded
• Felipe Monteiro

Citation preview

TO:

All DNP3 User Group Members

RE:

DNP3 Documentation Library

DATE: March 15, 2002

Thank you for your membership in the DNP3 Users Group and for your support of the DNP3 protocol! This file includes all DNP3-related documents available as of March 13, 2002 and will be updated on an as-needed basis. The purpose of this file is to provide a single source document in a universal format for the convenience of all DNP3 User Group Members. Therefore, this file has been created in Adobe Portable Document Format (.pdf). If you do not have access to Adobe Acrobat, you may download a free Acrobat Reader directly from the Adobe website (www.Adobe.com). The bookmarks in this document will enable quick navigation through all of the existing DNP3 documentation. Simple character string searches are also allowed (i.e., Object 10) using the standard Windows key sequence (Ctrl-F). Please let us know if you have any comments or questions regarding this document. Sincerely, The DNP3 Executive Committee

A DNP3 Protocol Primer This is a primer for people who want a quick understanding of DNP3 without having to comb through the tedious details of a complex specification. So let us start with what it is. Protocols define the rules by which devices talk with each other, and DNP3 is a protocol for transmission of data from point A to point B using serial communications. It has been used primarily by utilities like the electric companies, but it operates suitably in other areas. A typical electric company may have a centralized operations center that monitors the state of all the equipment in each of its substations. In the operations center, a powerful computer stores all of the incoming data and displays the system for the human operators. Substations have many devices that need monitoring (are circuit breakers opened or closed?), current sensors (how much current is flowing?) and voltage transducers (what is the line potential?). That only scratches the surface; a utility is interested in monitoring many parameters, too numerous to discuss here. The operations personnel often need to switch sections of the power grid into or out of service. One or more computers are situated in the substation to collect the data for transmission to the master station in the operations center. The substation computers are also called upon to energize or de-energize the breakers and voltage regulators. DNP3 provides the rules for substation computers and master station computers to communicate data and control commands. DNP3 is a non-proprietary protocol that is available to anyone. Only a nominal fee is charged for documentation, but otherwise it is available worldwide with no restrictions. This means a utility can purchase master station and substation computing equipment from any manufacturer and be assured that they will reliably talk to each other. Vendors compete based upon their computer equipment’s features, costs and quality factors instead of who has the best protocol. Utilities are not stuck with one manufacturer after the initial sale. What do the computers talk about? The substation computer gathers data for transmission to the master as 1. 2. 3. 4.

Binary input data that is useful to monitor two-state devices. For example a circuit breaker is closed or tripped or a pipeline pressure alarm shows normal or excessive. Analog input data that conveys voltages, currents, power, reservoir water levels and temperatures. Count input data that reports kilowatt hours of energy. Files that contain configuration data.

The master station issues control commands that take the form of 1. 2.

Close or trip a circuit breaker, raise or lower a gate, and open or close a valve. Analog output values to set a regulated pressure or set a desired voltage level.

Other things the computers talk to each other about are synchronizing the time and date, sending historical or logged data, waveform data, and on and on. DNP3 was designed to optimize the transmission of data acquisition information and control commands from one computer to another. It is not a general purpose protocol for transmitting hypertext, multimedia or huge files. The terms server and client are applicable to DNP3 systems. For our purposes, the definition of a server is a device or software process that has data or information that someone else wants. Substation computers are servers. A client is a device or software process that requests data from a server. A master station is a client.

1 June 2000

1

Copyright, DNP Users Group, 2000

Master (Client)

Binary Input 8 7 6 5 4 3 2 1 0

Control Output Analog Input Counter Input 4 3 3 2 2 1 1 0 0

6 5 4 3 2 1 0

Slave (Server)

Binary Input 8 7 6 5 4 3 2 1 0

Analog Output 4 3 2 1 0

Control Output Analog Input Counter Input 4 3 3 2 2 1 1 0 0

6 5 4 3 2 1 0

DNP3 User's Code

DNP3 User's Code

DNP3 Software

DNP3 Software

Analog Output 4 3 2 1 0

Physical Media User Requests User Responses

Figure 1 Figure 1 shows the client-server relationship and gives a simplistic view of the databases and software processes involved. The master or client is on the left side of figure 1, and the slave or server is on the right side. A series of square blocks at the top of the server depicts its databases and output devices. The various data types are conceptually organized as arrays. An array of binary input values represents states of physical or logical boolean devices. Values in the analog input array represent input quantities that the server measured or computed. An array of counters represents count values, such as kilowatt hours, that are ever increasing (until they reach a maximum and then roll over to zero and start counting again.) Control outputs are organized into an array representing physical or logical on-off, raise-lower and trip-close points. Lastly, the array of analog outputs represents physical or logical analog quantities such as those used for setpoints. The elements of the arrays are labeled 0 through N - 1 where N is the number of blocks shown for the respective data type. In DNP3 terminology, the element numbers are called the point indexes. Indexes are zero-based in DNP3, that is, the lowest element is always identified as zero. Some protocols use 1-based indexing. Notice that the DNP3 client, or master, also has a similar database for the input data types (binary, analog and counter.) The master, or client, uses values in its database for the specific purposes of displaying system states, closed-loop control, alarm notification, billing, and much, much more. An objective of the client is to keep its database updated. It accomplishes this by sending requests to the server (slave) asking it to return the values in the server’s database. This is termed polling. The server responds to the client’s request by transmitting the contents of its database. Arrows are drawn at the bottom of figure 1 showing the direction of the requests (toward the server) and the direction of the responses (toward the client.) Later we will discuss systems whereby the slaves transmit responses without being asked.

1 June 2000

2

Copyright, DNP Users Group, 2000

The client and the server shown in figure 1 each have two software layers. The top layer is the DNP3 user layer. In the client, it is the software that interacts between the database and initiates the requests for the server’s data. In the server, it is the software that fetches the requested data from the server’s database for responding to client requests. It is interesting to note, that if no physical separation of the client and server existed, eliminating the DNP3 might be possible by connecting these two upper layers together. However, since physical, or possibly logical separation of the client and server exists, DNP3 software is placed at a lower level. The DNP3 user’s code uses the DNP3 software for transmission of requests or responses to the matching DNP3 user’s code at the other end. More will be said about data types and software layers later, but first we want to examine a few typical system architectures where DNP3 is used.

DNP3 Client (Master)

DNP3 Server (Slave)

One-on-One

DNP3 Client (Master)

DNP3 Server (Slave)

DNP3 Server (Slave)

DNP3 Server (Slave)

Multidrop

DNP3 Client (Master)

DNP3 Server Client (Slave) (Master)

DNP3 Server (Slave)

Hierarchical

DNP3 Client (Master)

DNP3 Server (Slave)

XYZ Client (Master)

XYZ Server (Slave)

XYZ Server (Slave)

DNP3 Server (Slave)

DNP3 Server (Slave)

Data Concentrator

XYZ Client (Master)

XYZ Server (Slave)

DNP3 Client (Master)

Data Concentrator

Figure 2 Figure 2 shows common system architectures in use today. At the top is a simple one-on-one system having one master station and one slave. The physical connection between the two is typically a dedicated or dial-up telephone line. The second type of system is known as a multidrop design. One master station communicates with multiple slave devices. Conversations are typically between the client and one server at a time. The master requests data from the first slave, then moves onto the next slave for its data, and continually interrogates each slave in a round robin order. The communication media is a multi-dropped telephone line, fiber optic cable, or radio. Each slave can hear messages from the master and is only permitted to respond to messages addressed to itself. Slaves may or may not be able to hear each other. In some multidrop forms, communications are peer-to-peer. A station may operate as a client for gathering information or sending commands to the server in another station. And then, it may change roles to become a server to another station.

1 June 2000

3

Copyright, DNP Users Group, 2000

The middle row in figure 2 shows a hierarchical type system where the device in the middle is a server to the client at the left and is a client with respect to the server on the right. The middle device is often termed a sub-master. Both lines at the bottom of figure 2 show data concentrator applications and protocol converters. A device may gather data from multiple servers on the right side of the figure and store this data in its database where it is retrievable by a master station client on the left side of the figure. This design is often seen in substations where the data concentrator collects information from local intelligent devices for transmission to the master station. In recent years, several vendors have used TCP/IP to transport DNP3 messages in lieu of the media discussed above. Link layer frames, which we have not talked about yet, are embedded into TCP/IP packets. This approach has enabled DNP3 to take advantage of Internet technology and permitted economical data collection and control between widely separated devices. Many communication circuits between the devices are imperfect. They are susceptible to noise and signal distortion. The DNP3 software is layered to provide reliable data transmission and to effect an organized approach to the transmission of data and commands. Figure 3 shows the layering that was not shown in figure 1.

Master (Client)

Binary Input 8 7 6 5 4 3 2 1 0

8 7 6 5 4 3 2 1 0

Analog Counter 4 3 2 1 0

Slave (Server)

Binary Input

3 2 1 0

Control Output Analog Counter 4 3 2 1 0

3 2 1 0

6 5 4 3 2 1 0

DNP3 User's Code

DNP3 User's Code

DNP3 Application Layer

DNP3 Application Layer

Pseudo Transport Layer

Pseudo Transport Layer

DNP3 Link Layer

DNP3 Link Layer

Analog Output 4 3 2 1 0

Physical Media User Requests User Responses

Figure 3

The link layer has the responsibility of making the physical link reliable. It does this by providing error detection and duplicate frame detection. The link layer sends and receives packets, which in DNP3 terminology, are called frames.

1 June 2000

4

Copyright, DNP Users Group, 2000

Sometimes transmission of more than one frame is necessary to transport all of the information from one device to another. A DNP3 frame consists of a header and data section. The header specifies the frame size, which DNP3 station should receive the frame, which DNP3 device sent the frame and data link control information. The data section is commonly called the payload and contains the data passed down from the layers above. DNP3 Frame Header

Data

Header Sync

Length

Link Control

Destination Address

Source Address

CRC

Every frame begins with two sync bytes that help the receivers determine where the frame begins. The length specifies the number of octets in the remainder of the frame, not including CRC check octets. The link control octet is used between sending and receiving link layers to coordinate their activities. A destination address specifies which DNP3 device should process the data, and the source address identifies which DNP3 device sent the message. Having both destination and source addresses satisfies at least one requirement for peer-to-peer communications because the receiver knows where to direct its responses. 65520 individual addresses are available. Every DNP3 device must have a unique address within the collection of devices sending and receiving messages to and from each other. Three destination addresses are reserved by DNP3 to denote an all-call message; that is, the frame should be processed by all DNP3 devices. Thirteen addresses are reserved for special needs in the future. The data payload in the link frame contains a pair of CRC octets for every 16 data octets. This provides a high degree of assurance that communication errors can be detected. The maximum number of octets in the data payload is 250, not including CRC octets. (The longest link layer frame is 292 octets if all the CRC and header octets are counted.) One often hears the term “link layer confirmation” when DNP3 is discussed. A feature of DNP3's link layer is the ability for the transmitter of the frame to request the receiver to confirm that the frame arrived. Using this feature is optional, and it is often not employed. It provides an extra degree of assurance of reliable communications. If a confirmation is not received, the link layer may retry the transmission. Some disadvantages are the extra time required for confirmation messages and waiting for multiple timeouts when retries are configured. It is the responsibility of the transport layer to break long messages into smaller frames sized for the link layer to transmit, or when receiving, to reassemble frames into the longer messages. In DNP3 the transport layer is incorporated into the application layer. The transport layer requires only a single octet within the message to do its work. Therefore, since the link layer can handle only 250 data octets, and one of those is used for the transport function, then each link layer frame can hold as many as 249 application layer octets. Application layer messages are broken into fragments. Fragment size is determined by the size of the receiving device’s buffer. It normally falls between 2048 and 4096 bytes. A message that is larger than a one fragment requires multiple fragments. Fragmenting messages is the responsibility of the application layer. Note that an application layer fragment of size 2048 must be broken into 9 frames by the transport layer, and a fragment size of 4096 needs 17 frames. Interestingly, it has been learned by experience that communications are sometimes more successful for systems operating in high noise environments if the fragment size is significantly reduced.

1 June 2000

5

Copyright, DNP Users Group, 2000

The application layer works together with the transport and link layers to enable reliable communications. It provides standardized functions and data formatting with which the user layer above can interact. Before functions, data objects and variations can be discussed, the terms static, events and classes need to be covered. In DNP3, the term static is used with data and refers to the current value. Thus static binary input data refers to the present on or off state of a bi-state device. Static analog input data contains the value of an analog at the instant it is transmitted. One possibility DNP3 allows is requesting some or all of the static data in a slave device.

DNP3 events are associated with something significant happening. Examples are state changes, values exceeding some threshold, snapshots of varying data, transient data and newly available information. An event occurs when a binary input changes from an on to an off state or when an analog value changes by more than its configured deadband limit. DNP3 provides the ability to report events with and without time stamps so that the client can generate a time sequence report. The user layer can direct DNP3 to request events. Usually, a client is updated more rapidly if it mostly polls for events from the server and only occasionally asks for static data as an integrity measure. The reason updates are faster is because the number of events generated between server interrogations is small and, therefore, less data must be returned to the client. DNP3 goes a step further by classifying events into three classes. When DNP3 was conceived, class 1 events were considered as having higher priority than class 2 events, and class 2 were higher than class 3 events. While that scheme can be still be configured, some DNP3 users have developed other strategies more favorable to their operation for assigning events into the classes. The user layer can request the application layer to poll for class 1, 2 or 3 events or any combination of them. DNP3 has provisions for representing data in different formats. Examination of analog data formats is helpful to understand the flexibility of DNP3. Static, current value, analog data can be represented by variation numbers as follows: 1. 2. 3. 4. 5. 6.

A 32-bit integer value with flag, A 16-bit integer value with flag, A 32-bit integer value, A 16-bit integer value, A 32-bit floating point value with flag and A 64-bit floating point value with flag. The flag referred to is a single octet with bit fields indicating whether the source is on-line, value contains a restart value, communications are lost with the source, the data is forced and the value is over range.

Not all DNP3 devices can transmit or interpret all six variations. Later, DNP3 levels are discussed, but for now, suffice it to say that DNP3 devices must be able to transmit the simplest variations so that any receiver can interpret the contents. Event analog data can be represented by these variations: 1. 2. 3. 4. 5. 6. 7. 8.

A 32-bit integer value with flag, A 16-bit integer value with flag, A 32-bit integer value with flag and event time, A 16-bit integer value with flag and event time, A 32-bit floating point value with flag, A 64-bit floating point value with flag, A 32-bit floating point value with flag and event time and A 32-bit floating point value with flag and event time. The flag has the same bit fields as for the static variations.

1 June 2000

6

Copyright, DNP Users Group, 2000

It looks like a variation one or two analog event cannot be differentiated from a variation one or two static analog value. DNP3 solves this predicament by assigning object numbers. Static analog values are assigned as object 30, and event analog values are assigned as object 32. Static analog values, object 30, can be formatted in one of 6 variations, and event analog values, object 32, can be formatted in one of 8 variations. When a DNP3 server transmits a message containing response data, the message identifies the object number and variation of every value within the message. Object and variation numbers are also assigned for counters, binary inputs, controls and analog outputs. In fact, all valid data types and formats in DNP3 are identified by object and variation numbers. Defining the allowable objects and variations helps DNP3 assure interoperability between devices. DNP3's basic documentation contains a library of valid objects and their variations. The client’s user layer formulates its request for data from the server by telling the application layer what function to perform, like reading, and specifying which objects it wants from the server. The request can specify how many objects it wants or it can specify specific objects or a range of objects from index number X through index number Y. The application layer then passes the request down through the transport layer to the link layer that, in turn, sends the message to the server. The link layer at the server checks the frames for errors and passes them up to the transport layer where the complete message is assembled in the server’s application layer. The application layer then tells the user layer which objects and variations were requested. Responses work similarly, in that, the server’s user layer fetches the desired data and presents it to the application layer that formats the data into objects and variations. Data is then passed downward, across the communication channel and upward to the client’s application layer. Here the data objects are presented to the user layer in a form that is native to the client’s database. Reading data was mentioned in the above two paragraphs, but DNP3 software is designed to handle other functions. For one the client can set the time in the server. The client can transmit freeze accumulator requests, and it can transmit requests for control operations and setting of analog output values using select-before-operate or directoperate sequences. One area that has not been covered yet is transmission of unsolicited messages. This is a mode of operating where the server spontaneously transmits a response, possibly containing data, without having received a specific request for the data. Not all servers have this capability, but those that do must be configured to operate in this mode. This mode is useful when the system has many slaves and the master requires notification as soon as possible after a change occurs. Rather than waiting for a master station polling cycle to get around to it, the slave simply transmits the change. To configure a system for unsolicited messages, a few basics need to be considered. First, spontaneous transmissions should generally occur infrequently, otherwise, too much contention can occur, and controlling media access via master station polling would be better. The second basic issue is that the server should have some way of knowing whether it can transmit without stepping on someone else’s message in progress. DNP3 leaves specification of algorithms to the system implementor. One last area of discussion involves implementation levels. The DNP3 organization recognizes that supporting every feature of DNP3 is not necessary for every device. Some devices are limited in memory and speed and do not need specific features, while other devices must have the more advanced features to accomplish their task. DNP3 organizes complexity into three levels. At the lowest level, level 1, only very basic functions must be provided and all others are optional. Level 2 handles more functions, objects and variations, and level 3 is even more sophisticated. Within each level only certain combinations of request formats and response formats are required. This was done to limit software code in clients and servers while still assuring interoperability. It should be apparent by now that DNP3 is a protocol that fits well into the data acquisition world. It transports data as generic values, it has a rich set of functions, and it was designed to work in a wide area communications network. The standardized approach of objects and variations, and link, transport and application layers, plus public availability makes DNP3 a protocol to be regarded.

1 June 2000

7

Copyright, DNP Users Group, 2000

Author: Ken Curtis from Woodland Engineering wrote this paper to help the many people who are just getting into or considering DNP3 for their operation. Ken is a consulting engineer that has been contracted to write software for DAQ Electronics who also sponsors his participation in the DNP Technical Committee. Valuable editing assistance was provided by Mike Thesing of Advanced Control Systems.

DNP Users Group: Mail Address:

DNP Users Group PO Box 43075, DVPO Calgary, AB T2J 7A7 Canada

Fax:

403-271-1319

Email:

[email protected]

Website:

www.dnp.org

1 June 2000

8

Copyright, DNP Users Group, 2000

DOCUMENT REVISION HISTORY Name of Document: DNP V3.00 Data Link Layer Protocol Description Network File Name: P009-0PD.DL Original Author: Malcolm Smith/Jim McFadyen Date and Version of Preliminary Release: September 1991 Version 0.00 Associated Software Release(s): DNP V3.00 Revisions Since Preliminary Release Date

Version

By Whom:

Sept. 30/91 0.00A

N. Male

Pages Affected: All

Nov. 11/91 Nov. 18/91 Jul. 24/92

0.00B 0.00C 0.00D

J.McFadyen J. McFadyen MCH

2-11

Aug. 17/92 Oct. 22/92

0.01A 0.01B

MS MS

Oct. 27/92

0.01C

MS

Nov. 8/92

0.01D

MS

All

Nov. 24/92 Jan. 22/93 July. 20/93

0.02 0.02 0.02

LA MS MS

All vi,1-1,2-2 i,ii

All

1-1 2-1

Reason for Changes: Renamed and relocated from O:\DOCUMENT\OTHER\DOC0361.wp to N:\APPL\P009 0FS.DL Reformatted to WINC standards. Corrected errors Minor corrections Reversed MSB and LSB in Figure 2-15 and accompanying text, as per J. McFadyen. Changed to meet IEC conventions Re-added time-sync functionality to Data Link and fixed a problem with data frame duplication. Added time-sync accuracy to TIME OF DAY messages Adopted fully-balanced transmission procedures in order to become more IEC compliant. Removed timesynchronization functions. Removed Transport Functions section. Reformatted to WI standards. Added marketing comments Removed IEC conformance section from Chapter 2 and created new Chapter 2. Renamed old chapter 2 to Chapter 3. Changed 'polling' to 'polled' in last paragraph Channel failover section changed 'was intended to communicate' to 'communicates'

Date

Version

By Whom:

Pages Affected: 2-2

2-3 2-5

2-7

2-9,2-10 2-11,2-12 2-14 2-15 2-20 2-21 2-23 3-1,3-2

4-4

G-1,G-2 Aug.30/93

0.02

Sept. 01/93 0.02 May 30/97 0.02

J.Bhat

All

AV S. Tessari

All All

Reason for Changes: 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. Paragraph 3, explained better. USER DATA section explained that there are 16 octets per block except the last block (previously it was unclear) FCB, removed 'properly' from last paragraph as it is meaningless. FCV changed 'frame count bit valid bit' to 'frame count valid bit' Simplified greatly Simplified greatly Defined CRC algorithm Corrected error in diagram Corrected spelling error Removed misplaced graphic from page and corrected error Removed 'or will not' from line 4 as it is misleading Removed all references to "configurable" parameters as this is implementation specific. End of 3-2, removed last sentence as it is implementation specific. 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. Removed some unneeded and incorrect definitions Checked for Grammar, Spelling, Structure and Formatting Revisions as per C. Heune. Converted to MSWord 6.0.

DNP Users Group DNP PRODUCT DOCUMENTATION

DNP V3.00 DATA LINK LAYER

Document Version: 0.02 Internal 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 DOCUMENT PURPOSE OF THIS SPECIFICATION WHO SHOULD USE THIS SPECIFICATION HELP AND ADDITIONAL DOCUMENTATION HOW THIS SPECIFICATION IS ORGANIZED CONVENTIONS USED IN THIS SPECIFICATION

v v v v vi vi

1. OVERVIEW

1-1

2. IEC CONFORMANCE 2.1 CHANNEL FAILOVER 2.2 FRAME FORMAT AND PROCEDURES 2.3 LENGTH, CONTROL AND ADDRESS FIELDS

2-1 2-1 2-1 2-2

3. DNP DATA LINK DESCRIPTION 3.1 PURPOSE OF THE DATA LINK LAYER 3.2 FT3 FRAME FORMAT 3.3 DATA LINK HEADER FRAME FIELDS 3.4 USER DATA 3.5 CRC FIELDS 3.6 DATA LINK FUNCTION CODES 3.7 TRANSMISSION PROCEDURES

3-1 3-1 3-1 3-2 3-6 3-6 3-7 3-10

4. DATA LINK SERVICES AND RESPONSIBILITIES 4.1 DATA LINK FUNCTIONS 4.2 INTERFACE DESCRIPTION

4-1 4-1 4-2

5. PHYSICAL LAYER INTERFACE 5.1 PHYSICAL LAYER DESCRIPTION

5-1 5-1

6. PHYSICAL LAYER CHARACTERISTICS 6.1 LINE CONFIGURATIONS 6.2 MODES OF TRANSMISSION 6.3 LOCAL LOOP

6-1 6-1 6-1 6-2

DNP V3.00 Data Link Layer (Version 0.02)

i

7. PHYSICAL LAYER PROCEDURES 7.1 GENERAL CONSIDERATIONS 7.2 HALF-DUPLEX PROCEDURES 7.3 FULL-DUPLEX PROCEDURES

7-1 7-1 7-1 7-2

LIST OF ABBREVIATIONS AND ACRONYMS

ii

DNP Users Group

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-5 FIGURE 3-4 DESTINATION ADDRESS FORMAT 3-5 FIGURE 3-5 SOURCE ADDRESS FORMAT 3-5 FIGURE 3-6 CRC ORDERING 3-7 FIGURE 3-7 RESET OF SECONDARY LINK 3-10 FIGURE 3-8 RESET OF USER PROCESS 3-11 FIGURE 3-9 SEND FROM STATION A/CONFIRM FROM STATION B 3-11 FIGURE 3-10 SEND FROM STATION B/CONFIRM FROM STATION A 3-11 FIGURE 3-11 SEND MULTIPLE FRAMES FROM STATION A/CONFIRM FROM STATION B 3-12 FIGURE 3-12 FRAME COUNT BIT OPERATION 3-12 FIGURE 3-13 FRAME COUNT BIT OPERATION 3-13 FIGURE 3-14 SEND-NO-REPLY EXPECTED FROM STATION A 3-13 FIGURE 3-15 SEND FROM STATION B/NACK FROM STATION A 3-14 FIGURE 3-16 REQUEST/RESPOND FRAME AND DFC BIT USAGE 3-15

DNP V3.00 Data Link Layer (Version 0.02)

iii

iv

DNP Users Group

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

vi

DNP Users Group

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

2. IEC CONFORMANCE This chapter describes the difference between the DNP protocol and the IEC TC-57 (8705) 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.

DNP V3.00 Data Link Layer (Version 0.02)

2-1

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

2-2

DNP Users Group

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. DNP V3.00 Data Link Layer (Version 0.02)

3-1

••• ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • START • START • LENGTH • CONTROL • DESTINATION • SOURCE • CRC • USER • CRC • ... • 0x05 • 0x64 • • • • • • DATA • • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• ••|

2 starting octets of the header (0x0564). 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. Frame control octet. 2 octet destination address. The first octet is the LSB and the second octet is the MSB. 2 octet source address. The first octet is the LSB and the second octet is the MSB. 2 octet Cyclic Redundancy Check. 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. 3-2 DNP Users Group

••••••••••••••••••••••••••••••••••••••••••••••••• • • 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 direction 1 = station A to station B 0 = 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.

DNP V3.00 Data Link Layer (Version 0.02)

3-3

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

The frame count valid bit enables the functioning of the FCB bit. FCV =0 indicates the state of the FCB bit is ignored FCV =1 indicates to a secondary station that the state of the FCB bit must be checked against the state of the FCB bit of the last frame sent with the FCV bit set.

DFC

The data flow control bit is used to prevent the overflowing of buffers in a secondary station. The secondary station returns this bit set to a 1 if further SEND of user data to this secondary station will cause data link buffers to over flow. The primary station must interrogate the secondary station using REQUESTRESPOND 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 316 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 • - • • • • • • • • • • • •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

3-4

DNP Users Group

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 DNP V3.00 Data Link Layer (Version 0.02)

3-5

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').

3-6

DNP Users Group

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=x Wait the pre-determined time-out period for an ACK frame from the secondary station. DNP V3.00 Data Link Layer (Version 0.02)

3-7

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-try End 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 3-8

DNP Users Group

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: 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: 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: 3.6.5.1 Primary Transaction DNP V3.00 Data Link Layer (Version 0.02)

3-9

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)

(IND) Positive

••••••••••• • • • SEND • • FCB=0 • ••••••••••••••••••••••> ••••••••••••••• Expected FCB=x • CONFIRM • ••••••••••••••• • CONFIRM • ••••••••••••••• • CONFIRM • • • ••••••••••••• • CONFIRM • • • (IND) Positive

••••••••••••• • CONFIRM • • • (IND) Positive

••••••••••••• • CONFIRM • • • (IND) Positive ••••••••••••• • t DBA • CONFIRM • • • • • garbled ••••••••••••••••••••••••••• • or not received retry delay > t DAB + t DBA + t CONFIRM duration • ••• ••••••••••• • • (same data)• SEND • • FCB=1 • ••••••••••••••••••••••> ••••••••••••• • • • CONFIRM • • • ••••••••••••• • CONFIRM • tBA • • (IND) Positive••••••••••• (lost or garbled) (REQ)

retry delay > tBA + tAB + CONFIRM time + CONFIRM processing time at Station B ••••••••••• • SEND • • FCB=1 • Expected FCB=1 ••••••••••••••••••••••> ••••••••••••• • CONFIRM • • • (IND) Positive ••••••••• (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 DNP V3.00 Data Link Layer (Version 0.02)

3-13

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. ••••••••••• • SEND • • FCB=1 • ••••••••••••• ••••••••••• • SEND • • FCB=0 • ••••••••••••••••••••••••••••••••••••• • NACK • ••••••••••••••••••••••••> (IND) Negative

(REQ 1)

Expected FCB=1

(IND) Positive (REQ 2)

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

3-14

DNP Users Group

(REQ 1)

(IND) Positive Receipt of CONFIRM frame with DFC = 0 is the condition for transmission of the next SEND user data frame. (IND) Positive

(REQ 3) Receipt of CONFIRM frame with DFC = 0 is the condition for transmission of the next SEND user data frame.

••••••••••••• • • • SEND • • FCB=0 • ••••••••••••••••••••••••> ••••••••••••• • CONFIRM • • DFC=0 • ••••••••••••• ••••••••••••• • CONFIRM • • DFC=1 • ••••••••••••• ••••••••••••• • CONFIRM • • DFC=1 • ••••••••••••• ••••••••••••• • CONFIRM • • DFC=0 • ••••••••••••••••••••••••••••••••••••••• • SEND • • • • FCB=0 • ••••••••••••••••••••••••> ••••••••••••• • CONFIRM • • DFC=0 •