dnp3 doc library

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

1 June 2000 1 Copyright, DNP Users Group, 2000

A DNP3 Protocol PrimerThis is a primer for people who want a quick understanding of DNP3 without having to comb through the tediousdetails 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 aprotocol for transmission of data from point A to point B using serial communications. It has been used primarily byutilities 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 ineach of its substations. In the operations center, a powerful computer stores all of the incoming data and displaysthe system for the human operators. Substations have many devices that need monitoring (are circuit breakersopened or closed?), current sensors (how much current is flowing?) and voltage transducers (what is the linepotential?). That only scratches the surface; a utility is interested in monitoring many parameters, too numerous todiscuss here. The operations personnel often need to switch sections of the power grid into or out of service. Oneor more computers are situated in the substation to collect the data for transmission to the master station in theoperations center. The substation computers are also called upon to energize or de-energize the breakers andvoltage regulators.

DNP3 provides the rules for substation computers and master station computers to communicate data and controlcommands. DNP3 is a non-proprietary protocol that is available to anyone. Only a nominal fee is charged fordocumentation, but otherwise it is available worldwide with no restrictions. This means a utility can purchase masterstation and substation computing equipment from any manufacturer and be assured that they will reliably talk to eachother. Vendors compete based upon their computer equipment’s features, costs and quality factors instead of whohas 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. Binary input data that is useful to monitor two-state devices. For example a circuit breaker is closed ortripped or a pipeline pressure alarm shows normal or excessive.

2. Analog input data that conveys voltages, currents, power, reservoir water levels and temperatures.3. Count input data that reports kilowatt hours of energy.4. Files that contain configuration data.

The master station issues control commands that take the form of

1. Close or trip a circuit breaker, raise or lower a gate, and open or close a valve.2. 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 loggeddata, waveform data, and on and on.

DNP3 was designed to optimize the transmission of data acquisition information and control commands from onecomputer 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 deviceor software process that has data or information that someone else wants. Substation computers are servers. Aclient is a device or software process that requests data from a server. A master station is a client.


ControlOutput

AnalogOutput

DNP3 User's CodeDNP3 User's Code

012345678

01234

0123

012345678

01234

0123

0 0

BinaryInput

BinaryInput

Master (Client) Slave (Server)

DNP3Software

DNP3Software

Physical Media

User Responses

User Requests

123456

1234

0 0123456

1234

ControlOutput

AnalogOutputAnalog

Input CounterInput

AnalogInput Counter

Input

Figure 1

Figure 1 shows the client-server relationship and gives a simplistic view of the databases and software processesinvolved. 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 typesare conceptually organized as arrays. An array of binary input values represents states of physical or logical booleandevices. Values in the analog input array represent input quantities that the server measured or computed. An arrayof counters represents count values, such as kilowatt hours, that are ever increasing (until they reach a maximumand then roll over to zero and start counting again.) Control outputs are organized into an array representingphysical or logical on-off, raise-lower and trip-close points. Lastly, the array of analog outputs represents physical orlogical 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 respectivedata type. In DNP3 terminology, the element numbers are called the point indexes. Indexes are zero-based inDNP3, 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 andcounter.) 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 itsdatabase updated. It accomplishes this by sending requests to the server (slave) asking it to return the values in theserver’s database. This is termed polling. The server responds to the client’s request by transmitting the contents ofits 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 transmitresponses without being asked.


DNP3Server(Slave)

DNP3Server(Slave)

DNP3Server(Slave)

DNP3Server(Slave)

DNP3Server(Slave)

DNP3Server(Slave)

XYZServer(Slave)

XYZServer(Slave)

DNP3Server(Slave)

One-on-One

Multidrop

Hierarchical

Data Concentrator

Data Concentrator

DNP3Client

(Master)

DNP3Client

(Master)

DNP3Client

(Master)

DNP3Client

(Master)

XYZClient

(Master)

DNP3Server Client

(Slave) (Master)

DNP3 XYZServer Client

(Slave) (Master)

XYZ DNP3Server Client

(Slave) (Master)

Figure 2

The client and the server shown in figure 1 each have two software layers. The top layer is the DNP3 user layer. Inthe client, it is the software that interacts between the database and initiates the requests for the server’s data. Inthe server, it is the software that fetches the requested data from the server’s database for responding to clientrequests. It is interesting to note, that if no physical separation of the client and server existed, eliminating the DNP3might be possible by connecting these two upper layers together. However, since physical, or possibly logicalseparation of the client and server exists, DNP3 software is placed at a lower level. The DNP3 user’s code uses theDNP3 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 systemarchitectures where DNP3 is used.

Figure 2 shows common system architectures in use today. At the top is a simple one-on-one system having onemaster station and one slave. The physical connection between the two is typically a dedicated or dial-up telephoneline.

The second type of system is known as a multidrop design. One master station communicates with multiple slavedevices. Conversations are typically between the client and one server at a time. The master requests data fromthe first slave, then moves onto the next slave for its data, and continually interrogates each slave in a round robinorder. The communication media is a multi-dropped telephone line, fiber optic cable, or radio. Each slave can hearmessages from the master and is only permitted to respond to messages addressed to itself. Slaves may or maynot be able to hear each other.

In some multidrop forms, communications are peer-to-peer. A station may operate as a client for gatheringinformation or sending commands to the server in another station. And then, it may change roles to become aserver to another station.


AnalogCounter

ControlOutput

AnalogOutput

DNP3 User's Code

AnalogCounter

DNP3 User's Code

012345678

01234

0123

012345678

01234

0123

0123456

01234

BinaryInput

BinaryInput

Master (Client) Slave (Server)

Physical Media

User Responses

User Requests

DNP3Link Layer

DNP3 Application Layer

DNP3 Application Layer

DNP3Link Layer

Pseudo Transport Layer Pseudo Transport Layer

Figure 3

The middle row in figure 2 shows a hierarchical type system where the device in the middle is a server to the client atthe 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 maygather data from multiple servers on the right side of the figure and store this data in its database where it isretrievable by a master station client on the left side of the figure. This design is often seen in substations where thedata 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 discussedabove. Link layer frames, which we have not talked about yet, are embedded into TCP/IP packets. This approachhas enabled DNP3 to take advantage of Internet technology and permitted economical data collection and controlbetween 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 thetransmission of data and commands. Figure 3 shows the layering that was not shown in figure 1.

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


Sometimes transmission of more than one frame is necessary to transport all of the information from one device toanother.

A DNP3 frame consists of a header and data section. The header specifies the frame size, which DNP3 stationshould receive the frame, which DNP3 device sent the frame and data link control information. The data section iscommonly called the payload and contains the data passed down from the layers above.

DNP3 Frame

Header Data

Header

Sync Length Link Control DestinationAddress Source Address CRC

Every frame begins with two sync bytes that help the receivers determine where the frame begins. The lengthspecifies the number of octets in the remainder of the frame, not including CRC check octets. The link control octetis 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 identifieswhich DNP3 device sent the message. Having both destination and source addresses satisfies at least onerequirement for peer-to-peer communications because the receiver knows where to direct its responses. 65520individual addresses are available. Every DNP3 device must have a unique address within the collection of devicessending and receiving messages to and from each other. Three destination addresses are reserved by DNP3 todenote an all-call message; that is, the frame should be processed by all DNP3 devices. Thirteen addresses arereserved 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 highdegree of assurance that communication errors can be detected. The maximum number of octets in the datapayload is 250, not including CRC octets. (The longest link layer frame is 292 octets if all the CRC and headeroctets are counted.)

One often hears the term “link layer confirmation” when DNP3 is discussed. A feature of DNP3's link layer is theability for the transmitter of the frame to request the receiver to confirm that the frame arrived. Using this feature isoptional, and it is often not employed. It provides an extra degree of assurance of reliable communications. If aconfirmation is not received, the link layer may retry the transmission. Some disadvantages are the extra timerequired 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 totransmit, or when receiving, to reassemble frames into the longer messages. In DNP3 the transport layer isincorporated into the application layer. The transport layer requires only a single octet within the message to do itswork. Therefore, since the link layer can handle only 250 data octets, and one of those is used for the transportfunction, 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 receivingdevice’s buffer. It normally falls between 2048 and 4096 bytes. A message that is larger than a one fragmentrequires 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 afragment size of 4096 needs 17 frames. Interestingly, it has been learned by experience that communications aresometimes more successful for systems operating in high noise environments if the fragment size is significantlyreduced.


The application layer works together with the transport and link layers to enable reliable communications. It providesstandardized functions and data formatting with which the user layer above can interact. Before functions, dataobjects 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 thepresent on or off state of a bi-state device. Static analog input data contains the value of an analog at the instant it istransmitted. 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 exceedingsome threshold, snapshots of varying data, transient data and newly available information. An event occurs when abinary input changes from an on to an off state or when an analog value changes by more than its configureddeadband limit. DNP3 provides the ability to report events with and without time stamps so that the client cangenerate a time sequence report.

The user layer can direct DNP3 to request events. Usually, a client is updated more rapidly if it mostly polls forevents from the server and only occasionally asks for static data as an integrity measure. The reason updates arefaster is because the number of events generated between server interrogations is small and, therefore, less datamust be returned to the client.

DNP3 goes a step further by classifying events into three classes. When DNP3 was conceived, class 1 events wereconsidered as having higher priority than class 2 events, and class 2 were higher than class 3 events. While thatscheme can be still be configured, some DNP3 users have developed other strategies more favorable to theiroperation for assigning events into the classes. The user layer can request the application layer to poll for class 1, 2or 3 events or any combination of them.

DNP3 has provisions for representing data in different formats. Examination of analog data formats is helpful tounderstand the flexibility of DNP3. Static, current value, analog data can be represented by variation numbers asfollows:

1. A 32-bit integer value with flag,2. A 16-bit integer value with flag,3. A 32-bit integer value,4. A 16-bit integer value,5. A 32-bit floating point value with flag and6. 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 arestart 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 interpretthe contents.

Event analog data can be represented by these variations:

1. A 32-bit integer value with flag,2. A 16-bit integer value with flag,3. A 32-bit integer value with flag and event time,4. A 16-bit integer value with flag and event time,5. A 32-bit floating point value with flag,6. A 64-bit floating point value with flag,7. A 32-bit floating point value with flag and event time and8. A 32-bit floating point value with flag and event time.

The flag has the same bit fields as for the static variations.


It looks like a variation one or two analog event cannot be differentiated from a variation one or two static analogvalue. 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 6variations, 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 andvariation of every value within the message. Object and variation numbers are also assigned for counters, binaryinputs, controls and analog outputs. In fact, all valid data types and formats in DNP3 are identified by object andvariation numbers. Defining the allowable objects and variations helps DNP3 assure interoperability betweendevices. 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 toperform, like reading, and specifying which objects it wants from the server. The request can specify how manyobjects 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, sendsthe message to the server. The link layer at the server checks the frames for errors and passes them up to thetransport layer where the complete message is assembled in the server’s application layer. The application layerthen 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 applicationlayer that formats the data into objects and variations. Data is then passed downward, across the communicationchannel and upward to the client’s application layer. Here the data objects are presented to the user layer in a formthat 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 cantransmit requests for control operations and setting of analog output values using select-before-operate or direct-operate sequences.

One area that has not been covered yet is transmission of unsolicited messages. This is a mode of operating wherethe server spontaneously transmits a response, possibly containing data, without having received a specific requestfor the data. Not all servers have this capability, but those that do must be configured to operate in this mode. Thismode is useful when the system has many slaves and the master requires notification as soon as possible after achange occurs. Rather than waiting for a master station polling cycle to get around to it, the slave simply transmitsthe change.

To configure a system for unsolicited messages, a few basics need to be considered. First, spontaneoustransmissions should generally occur infrequently, otherwise, too much contention can occur, and controlling mediaaccess via master station polling would be better. The second basic issue is that the server should have some wayof knowing whether it can transmit without stepping on someone else’s message in progress. DNP3 leavesspecification of algorithms to the system implementor.

One last area of discussion involves implementation levels. The DNP3 organization recognizes that supportingevery feature of DNP3 is not necessary for every device. Some devices are limited in memory and speed and do notneed specific features, while other devices must have the more advanced features to accomplish their task. DNP3organizes complexity into three levels. At the lowest level, level 1, only very basic functions must be provided and allothers 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 tolimit 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 dataas 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 publicavailability makes DNP3 a protocol to be regarded.


Author:

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

DNP Users Group:

Mail Address: DNP Users GroupPO Box 43075, DVPOCalgary, AB T2J 7A7Canada

Fax: 403-271-1319

Email: [email protected]

Website: www.dnp.org

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

Reason for Changes:

Sept. 30/91 0.00A N. Male All Renamed and relocated fromO:\DOCUMENT\OTHER\DOC0361.wpto N:\APPL\P009 0FS.DL Reformattedto 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 withdata frame duplication.

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

Nov. 8/92 0.01D MS All Adopted fully-balanced transmissionprocedures in order to become moreIEC compliant. Removed time-synchronization functions. RemovedTransport 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 newChapter 2. Renamed old chapter 2 toChapter 3.

1-1 Changed 'polling' to 'polled' in lastparagraph

2-1 Channel failover section changed 'wasintended to communicate' to'communicates'


Reason for Changes:

2-2 Paragraph 1 removed 'Chapter 2' ofline 2 to clarify sentence. Removedparagraph 2 as it is confusing.Paragraph 3, changed 'spontaneous' to'unsolicited' and removed 'sub-masterstation' references to make it easier tofollow. Paragraph, changed wording tosuggest 'compatible' schemes.

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

there are 16 octets per block exceptthe last block (previously it wasunclear)

2-7 FCB, removed 'properly' from lastparagraph as it is meaningless. FCVchanged '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 isimplementation specific. End of 3-2,removed last sentence as it isimplementation specific.

4-4 Added 'DNP Data Link to PhysicalLayer Implementation Issuesdocument' as a section of the PhysicalLayer section in order to explain someof the physical layer issues and usageof the physical layer in the DNP datalink layer.

G-1,G-2 Removed some unneeded andincorrect 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 theDistributed Network Protocol cannot be made without express writtenagreement from the DNP Users Group or its duly authorized party. Inaddition, no part of this document may be altered or revised or added toin any form or by any means, except as permitted by written agreementwith the DNP Users Group or a Party duly authorized by the DNP UsersGroup.

As a Party, duly authorized by the DNP Users Group, HarrisCorporation has made every reasonable attempt to ensure thecompleteness and accuracy of this document, however, the informationcontained in this manual is subject to change without notice, and doesnot represent a commitment on the part of Harris Corporation or theDNP Users Group. An update program for DNP documents is providedupon request by Harris Corporation on behalf of the DNP Users Group.

TRADEMARK NOTICES

Brand and product names mentioned in this document are trademarks orregistered trademarks of their respective companies.

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

TABLE OF CONTENTS

ABOUT THIS DOCUMENT vPURPOSE OF THIS SPECIFICATION vWHO SHOULD USE THIS SPECIFICATION vHELP AND ADDITIONAL DOCUMENTATION vHOW THIS SPECIFICATION IS ORGANIZED viCONVENTIONS USED IN THIS SPECIFICATION vi

1. OVERVIEW 1-1

2. IEC CONFORMANCE 2-12.1 CHANNEL FAILOVER 2-12.2 FRAME FORMAT AND PROCEDURES 2-12.3 LENGTH, CONTROL AND ADDRESS FIELDS 2-2

3. DNP DATA LINK DESCRIPTION 3-13.1 PURPOSE OF THE DATA LINK LAYER 3-13.2 FT3 FRAME FORMAT 3-13.3 DATA LINK HEADER FRAME FIELDS 3-23.4 USER DATA 3-63.5 CRC FIELDS 3-63.6 DATA LINK FUNCTION CODES 3-73.7 TRANSMISSION PROCEDURES 3-10

4. DATA LINK SERVICES AND RESPONSIBILITIES 4-14.1 DATA LINK FUNCTIONS 4-14.2 INTERFACE DESCRIPTION 4-2

5. PHYSICAL LAYER INTERFACE 5-15.1 PHYSICAL LAYER DESCRIPTION 5-1

6. PHYSICAL LAYER CHARACTERISTICS 6-16.1 LINE CONFIGURATIONS 6-16.2 MODES OF TRANSMISSION 6-16.3 LOCAL LOOP 6-2

DNP Users Groupii

7. PHYSICAL LAYER PROCEDURES 7-17.1 GENERAL CONSIDERATIONS 7-17.2 HALF-DUPLEX PROCEDURES 7-17.3 FULL-DUPLEX PROCEDURES 7-2

LIST OF ABBREVIATIONS AND ACRONYMS

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

TABLE OF FIGURES

FIGURE 3-1 FT3 FRAME FORMAT 3-2FIGURE 3-2 CONTROL OCTET BIT DEFINITIONS 3-3FIGURE 3-3 TABLE OF PRIMARY AND SECONDARY FUNCTION CODES 3-5FIGURE 3-4 DESTINATION ADDRESS FORMAT 3-5FIGURE 3-5 SOURCE ADDRESS FORMAT 3-5FIGURE 3-6 CRC ORDERING 3-7FIGURE 3-7 RESET OF SECONDARY LINK 3-10FIGURE 3-8 RESET OF USER PROCESS 3-11FIGURE 3-9 SEND FROM STATION A/CONFIRM FROM STATION B 3-11FIGURE 3-10 SEND FROM STATION B/CONFIRM FROM STATION A 3-11FIGURE 3-11 SEND MULTIPLE FRAMES FROM STATION A/CONFIRM FROM

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

DNP Users Groupiv

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

ABOUT THIS DOCUMENT

PURPOSE OF THIS SPECIFICATION

This document specifies the Distributed Network Protocol (DNP) Data Link layerservices, transmission procedures and Link Protocol Data Unit.

WHO SHOULD USE THIS SPECIFICATION

This specification is intended for communication engineers and programmers interestedin knowing the function and message format of the DNP data link layer. This includesprogrammers implementing and designing DNP data link layer software/hardware andquality assurance personnel testing and verifying implementations of the DNP data linklayer. Application programmers may find this specification useful in determining how tointerface 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 Users Groupvi

HOW THIS SPECIFICATION IS ORGANIZED

1. OVERVIEWA 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 issynonymous with the term byte. The low order bit of an octet is referred to as bit 0 andthe high order bit as bit 7.

Irregular capitalization is used in referencing technical terms which have an associatedverb or noun. For example, data link indications commonly referred to as IND, can alsobe described using the word INDication.

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

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 transmissionprocedures. Master stations, submaster stations, outstations and intelligent electronicdevices (IEDs) can use this data link to pass messages between primary (originating)stations and secondary (receiving) stations. In this protocol, master stations, submasterstations, 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 ElectrotechnicalCommission (IEC), Technical Committee No. 57 for data transmission in telecontrolsystems 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 isdesigned to operate with connection and connection-less orientated, asynchronous orsynchronous bit-serial physical layers such as RS-232C, RS-485 and fibre transceivers.Fully-balanced transmission procedures were adopted to support spontaneoustransmissions from outstations, IEDs or submaster stations not designated as masterstations.

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

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


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 OSImodel, the Session layer is responsible for maintaining channel connections. In DNP, thelayer above the data link is responsible for providing channel failover based oncommunications failure at the Data Link. This layer could be a Network/Transport Layeror the Application Layer. Thus, the IEC requirement, 870-5-1, item 13, for channelfailover 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 IEC870-5-1 Transmission Frame Formats document. The FT3 frame format class is wellsuited for data transmission between stations that require medium information transferrates and low residual error probability. The basic frame format is used and transmissionrules 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 eachimplementation. The frame definitions outlined in IEC 870-5-2 are followed with the notethat the Address field is 2 octets in length and specifies the destination station address andthe 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 tohandle unsolicited transmissions from stations not designated as masters in a half-duplexor 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 configurationrequires a full-duplex channel to operate properly. In a half-duplex environment, the sameprocedures will be used except that a station cannot be both a primary and secondarystation at the same time. That is, an entire data link layer transaction between the masterstation and outstation will have to be completed at both stations before any furthertransactions can be started from either station. In both half-duplex and full-duplexconfigurations, it is the responsibility of each device to implement a compatible collisionavoidance scheme.

DNP Users Group2-2

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 asdefined in IEC 870-5-2 clause 6.1.2. All the function codes specified in IEC 870-5-3clause 6.1.2 Table III are supported.

The ADDRESS field is a 16-bit (2 octet) field. The DNP data link frame header has twoIEC ADDRESS fields. The first field is the A (Address) field where it is used to representthe destination station address and the second is in the Link User Data field where it isused to represent the source station address. (Refer to Section 3 for more information onthese fields).


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 functionsrequired 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 mustprovide transfer of information or Link Service Data Unit (LSDU) across the physicallink as described by the ISO-OSI standard. This means that user data supplied by higherlayers (LSDU) must be converted into one frame (or LPDU as described in Section 2) andsent to the physical layer for transmission. Conversely, individual LPDUs received by thedata link layer must be assembled into one LSDU and passed to higher layers. The layerprovides for frame synchronization and link control.

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

The OSI reference model enforces either a connection-less or a connection orientedsystem. However, the EPA model implies neither a connection-less system nor aconnection oriented system. The DNP Version 3 implementation of the IEC data linkhandles both connection-less and connection oriented systems (that is, physical networksthat 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 istransparent to the application using the data link because the data link layer is responsiblefor connecting and disconnecting from any physical network without higher levelinteraction (i.e. application layer). That is, the data link (given the station destinationaddress) will connect to the right physical circuit without control supplied from higherlayers. In this way, the physical medium is totally transparent to the link layer serviceuser.

3.2 FT3 FRAME FORMAT

This section describes the LPDU format. An FT3 frame is defined as a fixed lengthheader block followed by optional data blocks. Each block has a 16-bit CRC appended toit. The IEC specifies that the header fields consist of 2 start octets, 1 octet length, 1 octetcontrol, a destination address and an optional fixed length user data field. In thisimplementation the fixed length user data field is defined as a source address.

DNP Users Group3-2

•<•••••••••••••••••••••••••••• 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 inthe header. The CRC fields are not included in the count. Theminimum value for LENGTH is 5 indicating only the header ispresent 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 ofUser 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 secondoctet 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 controlinformation.

Figure 3-2 defines the fields of the control octet. Station A is defined as the designatedmaster station. Station B is not a master station. The primary station is the originator ofthe message, the source of the message. The secondary station is the destination station.


••••••••••••••••••••••••••••••••••••••••••••••••• • • 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 thedesignated 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 theinitiating 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 thesame secondary station. This bit toggles for each successful SEND-CONFIRMservice that is initiated by the same primary station and directed to the samesecondary station.Initially before communications with a secondary station or after communicationfailure, the primary station (in both the master station and outstation) must resetthe 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 Users Group3-4

Each secondary station, after data link start-up or transaction failure, must notaccept any primary SEND-CONFIRM messages with FCV set until a RESETcommand 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 bechecked against the state of the FCB bit of the last frame sent with the FCV bitset.

DFC The data flow control bit is used to prevent the overflowing of buffers in asecondary station. The secondary station returns this bit set to a 1 if further SENDof user data to this secondary station will cause data link buffers to over flow. Theprimary station must interrogate the secondary station using REQUEST-RESPOND Request Link Status until the DFC is returned with a value of 0. Atthis 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 ofthe values placed in this field are different between primary andsecondary stations. The following tables define the implementedcodes and associated FCV states.

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

•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Function • Frame Type • Service Function • FCV •• Code • • • Bit ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 0 • SEND - CONFIRM expected • RESET of remote link • 0 •• 1 • SEND - CONFIRM expected • Reset of user process • 0 •• 2 • SEND - CONFIRM expected • TEST function for link • 1 •• 3 • SEND - CONFIRM expected • User Data • 1 •• 4 • SEND - NO REPLY expected • Unconfirmed User Data • 0 •• 5 • • Not Used • - •• 6 • • Not used • - •• 7 • • Not Used • - •• 8 • • Not Used • - •• 9 • REQUEST - RESPOND expected • REQUEST LINK STATUS • 0 •• 10 • • Not Used • - •• 11 • • Not Used • - •• 12 • • Not Used • - •• 13 • • Not Used • - •• 14 • • Not Used • - •• 15 • • Not Used • - •• • • • •• • • • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••


Function Code Field Values of the Control Octet Sent from the Secondary Station (PRM= 0)•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Function • Frame Type • Service Function •• Code • • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 0 • CONFIRM • ACK - positive acknowledgement •• 1 • CONFIRM • NACK - Message not accepted, Link busy •• 2 • • Not Used •• 3 • • Not Used •• 4 • • Not Used •• 5 • • Not Used •• 6 • • Not Used •• 7 • • Not Used •• 8 • • Not Used •• 9 • • Not Used •• 10 • • Not Used •• 11 • RESPOND • Status of Link (DFC = 0 or DFC = 1) •• 12 • • Not Used •• 13 • • Not Used •• 14 • • Link service not functioning •• 15 • • Link service not used or implemented ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

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 stationthat the frame is directed to. The first octet of the address is the low order octet and thesecond octet is the high order.

The address 0xffff is defined as an all stations address. All stations will accept frameswith 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 theframe originated from. The first octet of the address is the low order octet and the secondoctet is the high order. Note that this field is not included as USER DATA but must bepassed 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 Users Group3-6

3.4 USER DATA

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

The data link layer passes all of the user data and the source address from the header tothe higher layers when a SEND user data frame is received. The data link serviceprimitives 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 whencalculating the CRC for the header.

The 2 octet CRC check is generated from the following polynomial and then invertedbefore 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-2arithmetic (addition and division) is assumed. A message block (M) of k-bits is to betransmitted (along with other blocks) (k is 64 for the header, 128 for all user data blocksbut 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 checksequence is a pattern (P) of 17 bits as defined above in polynomial form. The CRCalgorithm requires that when T is divided by P at the receiver the remainder is 0. If theremainder is not 0 then the block is in error. In addition, the remainder (R) of 216M/P isused as F in the block so that 216M/P = Q + R/P (Equation. 1) (Q is the quotient). Thiscan 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 Radded 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').


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 anyblocks (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 furtherSEND-CONFIRM transactions. Upon reception and reply to a RESET command, thesecondary station will begin accepting Primary messages from that Primary station withthe 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 onlyguarantees that the primary station transmitter and the secondary station receiver arecommunicating. The primary station must send this function code when it wishes to firstcommunicate with the secondary station or after a communications failure has beenrecognized by the primary station. When a secondary station has re-started or when acommunications failure has been recognized by the secondary, the secondary station willbe considered un-reset. In this state, the secondary station will not accept messages fromthe primary station until it has received and replied to a RESET command from thatprimary station.

The RESET command also synchronizes the FCB bit between primary and secondarystations. The secondary station after completing the RESET transaction will expect theFCB bit in the next message (with FCV valid) to be 1 from that primary station. Theprimary station after completing the RESET transaction will set the FCB bit to 1 in thenext 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.

DNP Users Group3-8

If ACK frame is received, set FCB status to 1 (i.e. next frame sent to secondary with FCVvalid 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 secondarystation can be considered on-line. A positive INDication can be returned to the data linkuser.

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

During normal operation, if a RESET command with FCV=0, FCB=x, PRM=1 andDIR=x is received, then the current transaction (if any) can be aborted (possibly withnegative INDication sent to data link user).

In such case, respond with an ACK confirm frame (DFC=x, PRM=0, DIR=x). The FCBstatus (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 asecondary station, an INDication should be sent to the data link user. The data link usercan use this indication to reset its internal state. If accepted by the data link user, an ACKconfirm 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 receptionby a secondary station, it checks the value of the FCB bit in the primary message andcompares it against the FCB status (expected FCB) for that primary station. If the FCBsdo 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 statusshould be toggled. The secondary station also sets the DFC bit accordingly in theresponse.

3.6.4 User Data


The User Data function is used to send confirmed data to a secondary station. Beforecommunications can begin, the secondary station must have been RESET according tothe rules above (see RESET). The frame sent contains the user data from the primary datalink user that is to be passed to the data link user of the secondary station. Thetransmission 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 thesecondary station (next expected FCB status).Wait the pre-determined time-out period for a ACK or NACK frame from the secondarystation.If frame is NACK then wait a pre-determined amount of time until secondary link is NOTbusy 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 secondarywith 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 secondarystation can be considered on-line. A positive INDication can be returned to the data linkuser.

Otherwise, a negative INDication should be sent to the data link user and the secondarystation can be considered off-line or on-line depending on the data link user'sinterpretation of the failure.


Upon reception of a User Data frame with FCV=1, PRM=1, DIR=x and FCB set to FCBstatus (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 needingconfirmation. In this way, the bandwidth of the system can be more fully utilized if theuser data is low priority. The frame sent contains the user data from the primary data linkuser that is to be passed to the data link user of the secondary station. The transmissionprocedures are described below:


DNP Users Group3-10

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 thedata 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 secondarystation will respond to this request with a LINK STATUS confirm frame with the DFCbit set to 1 if the data link is busy or the data link user cannot accept any more user dataand 0 indicating that the data link is not busy and the data link user can accept more userdata. The transmission procedures are similar to TEST except that the primary station willtypically only use this command when a NACK frame is received during a User Datatransaction.

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 secondarystation. The secondary station receives the message and responds with an ACK confirmframe.

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 asecondary station. The secondary station receives the message and responds with an ACKconfirm frame.


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 firstframe with FCV valid after the secondary link was reset (above) so FCB = 1 in the SENDframe. The secondary station expects FCB to be 1 since this is the first frame (with FCVvalid) after the link was reset (above) and sends a CONFIRM frame. The master stationupon receiving the CONFIRM assumes the message was correctly received andINDicates 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-CONFIRMframe to a designated master station acting as a secondary station. Since this is the secondframe after the secondary link has been reset the FCB = 0 in the SEND frame. Thesecondary expects FCB to be 0 since this is the second frame received after the link wasreset. A CONFIRM frame is sent in response. The non-master station upon receiving theCONFIRM 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

DNP Users Group3-12

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 thesecondary non-master. This example illustrates what happens when the CONFIRM fromthe 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 thesecondary non-master. This example illustrates what happens when the SEND framefrom the primary station is lost.


•••••••••••(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 canre-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 secondarymaster or non-master. Upon successfully transmitting the SEND frame, the primarystation INDicates success to the data link user. The secondary station, upon reception of avalid 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. Uponreception of the first CONFIRM, the primary INDicates success to the data link user. The

DNP Users Group3-14

primary sends a second frame to the secondary. The secondary master decides that itcannot accept any frames at this time and sends a NACK frame back. The primary, afterreceiving this NACK, will fail the transaction and send a negative INDication to the datalink 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. Whenthe secondary station cannot receive any more frames, the CONFIRM message containsthe DFC bit set. The primary station will, upon reception of the CONFIRM, stopSENDing data frames to the secondary station but will instead periodically REQUESTthe status of the secondary by sending a REQUEST-RESPOND frame. The secondarywill RESPOND to the REQUEST frame with the current state of the DFC. If thesecondary is ready to receive more data, the DFC returned will be 0 otherwise the DFCreturned will be 1. When the primary station recognizes DFC = 0 in the RESPONDframe, the transmission of SEND frames will continue.


•••••••••••••(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 ANDRESPONSIBILITIES

4.1 DATA LINK FUNCTIONS

This section describes the services offered by the data link and its functions. Thecommunication requirements of the network layer and the pseudo-transport layer aresatisfied 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 priorityrequest.

DNP Users Group4-2

Quality delivery can be SEND-NO-REPLY or SEND-CONFIRM to indicate whether ornot message acknowledgment is required.

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

4.2 INTERFACE DESCRIPTION

The data link service primitives are illustrated in pseudo code to illustrate therequirements and behavior in a real implementation and are not intended as an exactinterface definition.

Data link request (REQ) services can be used at any time after the data link has beeninitialized 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


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

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, currentunrequested transaction or waiting for physical layer availability

Service = 0 Send a message specified in parameters using SEND-CONFIRMframes. Fails if the data link is busy

1 Send a message specified in parameters using SEND-NO- REPLYframes. Fails if the data link is busy

2 Expedited send a message specified in parameters using SEND-CONFIRM frames. May necessitate cancelling the currentsecondary transaction if a half-duplex system is used (i.e. forces thedata link to send a NACK frame instead of a CONFIRM frame inthe next secondary transaction). This action only takes place if theprimary 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 maymean 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. Thisservice 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 bechecked 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

DNP Users Group4-4

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 beenplaced in received_data_count. The source address of the receivedmessage has been placed in source_address. If the data link isconfigured as a master station then the time that the first bit of thefirst octet of the message was received has been placed intime_of_reception. If the data link is configured as an outstationthen the time_of_reception will still be returned but the serviceuser has to be aware of the possibility of inaccurate times receivedbefore the outstation has been time-synchronized.

2 Data link has detected a transaction failure.


5. PHYSICAL LAYER INTERFACE

This section describes the DNP Version 3 Data Link to physical layer interface. Theinterface describes the necessary services that ANY physical layer must provide in orderto 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 orientedasynchronous 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 (DataCommunication Equipment) and is usually a frequency-switched modem (FSK). Thistype of circuit connection to a PSN (Public Switching Network) or to private leased linescan 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 transmissionbetween the DTE and DCE. It must provide the proper signal control in order tocommunicate with the given DCE. The Receive service must be able to accept data fromthe DCE and therefore provide the correct signaling to the DCE in order to receive dataand not noise. The Connect and Disconnect services provide connection anddisconnection from the PSN (if applicable). The Status service must be able to return thestate of the physical medium. As a minimum, the service must indicate whether or not themedium is busy.

The physical link service primitives are illustrated in pseudo code to illustrate therequirements and behavior in a real implementation and are not intended as an exactinterface definition.

Physical layer requests can be sent at any time after the physical layer has been startedand configured with all relevant parameters.

confirm = request ( SERVICE,data_buffer,data_count,modem_string,time_of_transmission)

DNP Users Group5-2

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, currentunrequested transaction or waiting for DCE availability

Service = 0 Send a message specified in data_buffer of size specified indata_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 butshould 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 receivedhas 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 untilsome later time. Re-initialization of the DCE may berequired.


6. PHYSICAL LAYERCHARACTERISTICS

6.1 LINE CONFIGURATIONS

Regardless of the physical layer used, there are two physical topologies used to constructa SCADA communications network. These are direct and serial bus topologies.

The direct topology has two physical nodes with each physical node connected directly tothe other. This is often referred to as point-to-point and can be a direct physical cablefrom point-to-point, a two node radio or modem network or a dial-up connection througha PSN (Public Switched Network).

The serial bus topology has more than two physical nodes with each node connected tothe 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 manyBell 202 modems with their outputs/input tied together. In this configuration, there is onenode which is deemed to be in control of the physical network. This is often the SCADAmaster. This node transmits to multiple-nodes and receives from multiple nodes. All othernodes 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-peercommunications.

In peer-to-peer communications, all devices act as slave data links and collisionavoidance should be turned on as no one device has a higher priority and all can transmitspontaneously.

In a multiple-master configuration, the master devices are higher priority than the slavedevices. 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 beasynchronous, synchronous or isochronous allowing for higher throughput with a

DNP Users Group6-2

synchronous modem. The actual mechanism used has no affect on the operation of thedata link.

6.3 LOCAL LOOP

The termination of the data communications circuit at the communication node (i.e. NOTat the modem) can be accomplished using a two-wire or four-wire circuit (i.e. TX/RXpair or independent TX and RX pairs).

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

The DNP data link can support both full-duplex and half-duplex procedures at the localloop. Both cases, however will be handled quite differently.


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 orreceive a message to or from another data link. To accomplish this, the data link must beable to control when the transmission of data takes place, detect the presence of data onthe physical communication circuit and use control line signaling for control of thephysical circuit. In addition, the master station (or highest priority device) needs to beable to take control of the communication circuit and block other stations fromtransmitting.

In a direct connection type topology, the primary station (initiating station) can onlycommunicate with one station. If this circuit is four-wire then full-duplex procedures willbe used and there will be no chance of message collisions on the circuit. However, if thecircuit is two-wire then half-duplex procedures will be used. In this case, a collision canoccur 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 useCTS to hold off the transmitter after RTS is asserted.

In a multi-drop topology, the designated master station can act as a primary station tomany secondary stations. In this case there is a chance of collision in a two-wire or fourwire circuit.

In a two-wire circuit, the designated master station messages can collide with any otherstations 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 stationmessages 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 toavoid or recover from a collision on the communication circuit. Regardless of thephysical layer used, all physical layers should be able to return a data carrier detectionindication (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

DNP Users Group7-2

indication is present, a station is transmitting on the circuit. During this time, no otherstation should attempt to transmit on the circuit. When the indication disappears, thecircuit is free for someone to use. The question now is, which station is allowed totransmit on the circuit.

In the point-to-point configuration, either the master or slave station could transmit. In themulti-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 messagebut it is generally accepted in SCADA that the master should have control of thecommunication 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 sothe slave station must wait some time after detecting the loss of a data carrier beforeattempting to send. Before sending, the indication is checked again and if the circuit isstill idle then the transmission can take place. If the circuit is busy then the station mustwait again until the indication disappears and perform the procedure again. The insertionof the time delay after the loss of data carrier allows the master to take control of thecircuit (if needed at that time) and shuts out the other station (because the carrierindication 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 timeneeded for the master to detect the loss of data carrier and begin the transmission of themessage (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 oftime (no duplicate times and all greater than Master_Min time) hence assigning prioritiesto the stations. In this way, stations which are important in the system can be given higherpriority and collisions will rarely happen (only if device timing is bad or the system ispoorly 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 betweenMaster_Min and Max. This Max is a function of the number of slave stations in thesystem. In this way, each station can be configured in the same way and the average timewasted is about (Max - Master_Min) / 2. However, a collision is still possible if twostations decide to wait for the same amount of time. The smaller the Max value thegreater 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 nochance 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 transmitdata at any time when needed. The master still has control of the circuit because there isonly 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 ofcollision avoidance increases in complexity. The reason for this lies in the fact that aphysical communication circuit that has two independent channels usually can only detecttraffic in the receive direction. In a two-wire system, any traffic in the receive or transmitdirection can be detected because they are both on the same circuit but in a four-wiresystem 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 sametime without collision so there is no need for collision detection/avoidance or accessmechanisms in this case.

7.3.2 Multi-Point

In a full-duplex, multi-drop system, the master station can transmit messages at any timewithout collision but may not receive the data link confirmation immediately becauseanother station (acting as a primary station) may have taken control of the master'sreceive 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 stationto know if another station has control of the master's receive circuit. The solution is tomake use of a control circuit (RTS in the case of RS-232) to signal the slave stationswhen another slave station has taken control of the master's receive circuit. This signalmust be an input to the slave stations which indicates a request to take control of themaster's receive circuit.

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

7.3.3 Dial-Up Modem

A dial-up modem uses a four-wire full-duplex circuit that typically requires severalcontrol 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 adirect circuit. The data carrier (DCD) indicates that the modem is electrically connectedto another modem across the PSN. It does not necessarily mean that data is beingtransmitted on the circuit. The CTS (Clear To Send) line indicates to the data link when itis safe to transmit. The DNP data link will assert the RTS (Request To Send) line beforetransmitting 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 willassume that a connection has been lost and attempt to re-dial if needed.

DNP Users Group7-4

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

LIST OF ABBREVIATIONS ANDACRONYMS

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


Name of Document: DNP V3:00 Transport FunctionsNetwork File Name: P009-0PD.TF

Original Author: Malcolm SmithDate and Version of Preliminary Release: November 8, 1992 Version 0.00AAssociated Software Release(s): DNP V3.00


Date Version By Whom PagesAffected

Reason for Changes

Nov. 08/92 0.00A M. Smith All CreatedAug. 20/93 0.01 J. Bhat All Revised after reviewSep 01/93 0.01 AV All Corrections as per C. HueneMay 30/97 0.01 S. Tessari All Converted to MSWord 6.0

DNP Users Group


DNP V3.00TRANSPORT FUNCTIONS

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





TRADEMARK NOTICES


DNP V3.00 Transport Functions (Version 0.01) i

TABLE OF CONTENTS

ABOUT THIS DOCUMENT iiiPURPOSE OF THIS SPECIFICATION iiiWHO SHOULD USE THIS SPECIFICATION iiiHELP AND ADDITIONAL DOCUMENTATION iiiHOW THIS SPECIFICATION IS ORGANIZED ivCONVENTIONS USED IN THIS SPECIFICATION iv

1. OVERVIEW 1-1

2. TRANSPORT FUNCTIONS 2-12.1 TRANSPORT HEADER 2-12.2 TRANSPORT HEADER FIELD DEFINITIONS 2-22.3 FRAME ASSEMBLING 2-32.4 TRANSMISSION OF MESSAGES 2-4

3. TRANSPORT SERVICES AND RESPONSIBILITIES 3-13.1 TRANSPORT FUNCTIONS 3-13.2 INTERFACE DESCRIPTION 3-2


DNP Users Groupii

TABLE OF FIGURES

FIGURE 2-1 TRANSPORT LAYER MESSAGE LAYOUT 2-2FIGURE 2-2 TH BIT DEFINITIONS 2-2FIGURE 2-3 ASSEMBLING OF DATA FROM THREE DATA FRAMES 2-3FIGURE 2-4 TRANSMISSION OF A SINGLE FRAME MESSAGE 2-4FIGURE 2-5 FRAGMENTING OF A MULTI-FRAME APPLICATION MESSAGE 2-4

DNP V3.00 Transport Functions (Version 0.01) iii

ABOUT THIS DOCUMENT


This document specifies the Distributed Network Protocol (DNP) V3.00 TransportFunctions, transmission procedures and Transport Protocol Data Unit.


This specification is intended for communication engineers and programmers interestedin knowing the function and message format of the DNP V3.00 Transport Functions. Thisincludes programmers implementing and designing DNP V3.00 Transport Functionssoftware/hardware and quality assurance personnel testing and verifying implementationsof the DNP V3.00 Transport Functions. Application programmers may find thisspecification useful in determining how to interface with and make use of the DNP V3.00Transport Functions. Familiarity with the ISO-OSI 7-layer model, IEC 3-layer EPA andIEC TC-57 standards is helpful.


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 Data Link Layer (P009-0PD.DL).

DNP Users Groupiv


1. OVERVIEWA general overview of the transport functions.

2. TRANSPORT FUNCTIONSA detailed description of the packet formats and transmission procedures.

3. TRANSPORT SERVICES AND RESPONSIBILITIESServices provided by an interface to the transport functions.



In this document, the octet is a term used to refer to an eight bit-data object and issynonymous with the term byte. The low order bit of an octet is referred to as bit 0 andthe high order bit as bit 7.

Irregular capitalization is used in referencing technical terms which have an associatedverb or noun. For example, data link indications commonly referred to as IND, can alsobe described using the word INDication.

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

1. OVERVIEW

This document defines the Distributed Network Protocol (DNP) V3.00 TransportFunctions, Transport Protocol Data Unit (TPDU), as well as transport services andtransmission procedures. Master stations, submaster stations and outstations or intelligentelectronic devices (IEDs) can use these transport functions to pass messages betweenprimary (originating) stations and secondary (receiving) stations. In this protocol, masterstations, submaster stations and outstations are both originators (primary stations) andreceivers (secondary stations).

The ISO (International Organization for Standardization) OSI (Open SystemInterconnection) model supported by this protocol specifies physical, data link andapplication layers only. This is termed the Enhanced Protocol Architecture (EPA).However, to support advanced RTU functions and messages larger than the maximumframe length as defined by the IEC (International Electrotechnical Committee) document870-5-1, the DNP V3.00 Data Link is intended to be used with this pseudo-transport layerwhich implements message assembly and disassembly.

This pseudo-transport layer is actually a super-data link transport protocol which isnormally found as part of some OSI data links. However, because the IEC data link (DNPV3.00 Data Link Layer) does not support these functions in the data link, it is necessaryto move them out of the data link in order to maintain compliance.


2. TRANSPORT FUNCTIONS

This section describes the Transport layer functions which act as a pseudo-transport layerto the DNP data link layer. The pseudo-transport layer function is specific only for thosemessages that are larger than one Link Protocol Data Unit (LPDU) between primary andsecondary stations. This pseudo-transport layer acts as the DNP data link user in aprotocol stack consisting of only the DNP Data Link and DNP Application Layer. Thisfunctionality allows the pseudo-transport layer to disassemble one Transport Service DataUnit (TSDU) into multiple (more than one) Transport Protocol Data Units (TPDUs), orframes, and assemble multiple (more than one) TPDUs into one TSDU.

This process works as follows:The pseudo-transport layer takes one TSDU (user data) and breaks it into severalsequenced TPDUs (each with Transport Protocol Control Information (TPCI)). EachTPDU is sent to the data link layer as Link Service Data Unit (LSDU) for transmission.It also works in the reverse fashion. The pseudo-transport layer receives multiple TPDUsfrom the data link layer and assembles them into one TSDU.LSDUs are user data fragments which are small enough to fit into the defined FT3 frameformat. When a primary station transmits a message to a secondary station, the transportfunctions break the message into LSDUs. These functions add a Transport layer Header(TH) octet at the beginning of the user data fragments that contain the information for thesecondary station to reconstruct the complete message. All pseudo-transport layermessages have a TH.

The secondary station checks the TH octet on reception of each LSDU for the correctsequence and builds a TSDU message for higher layers.

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

2.1 TRANSPORT HEADER

After the data link receives a complete frame, the data is presented to the transportfunctions in a format illustrated below. The TH field is stripped out before the frame iscombined with other frames belonging to the same message. Figure 2-1 shows thestructure of a TPDU.

DNP Users Group2-2

----------------- | | | | TH | USER DATA | | | | -----------------

Figure 2-1 Transport Layer Message Layout

TH Transport control octet. One octet in length.USER DATA 1 to 249 octets in length.

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

Maximum data link data count + 255 octetsData link header data count - 5 octetsTransport header - 1 octetApplication user data = 249 octets

2.2 TRANSPORT HEADER FIELD DEFINITIONS ----------------------------------------------- | | | | | | | | | | FIN | FIR | | | SEQUENCE | | | | | | | | | | | | -----------------------------------------------BIT 7 6 5 4 3 2 1 0

Figure 2-2 TH Bit Definitions

FIN The final bit indicates that this frame of user data is the last frame of asequence which compromises a complete user message.FIN = 0 More frames follow.

1 Final frame of a sequence.

FIR The first bit indicates that the frame is the first in a sequence of frame(s)which comprise a complete message. When a secondary station receives aframe with the FIR bit set, all previously received unterminated framesequences are discarded. The first frame of a sequence may have anysequence from 0 to 63.If a frame is received without the FIR bit set and no message sequence iscurrently in progress, then the frame is ignored.If a complete user message is only one frame in length, both the FIR andFIN bits are set.FIR = 1 First frame of a sequence.

0 Not the first frame of a sequence.


SEQUENCE The sequence number of the frame is used to check that each frame isbeing received in sequence. It guards against missing or duplicated frames.All user messages start off with a sequence specified in the first framewhich has the FIR bit set (each message may start with any sequencenumber between 0 and 63). After sequence number 63 the next sequencenumber will be 0.The sequence number increments for each frame sent to or received fromthe same address belonging to the same message and resets at thebeginning of a new message. The sequence number does not have toincrement across message boundaries, i.e. any sequence number is validwhen the FIR bit is set.

2.3 FRAME ASSEMBLING

Figure 2-3 illustrates the assembling of a three-frame message. The first frame of themessage identified by having the FIR bit set in the TH field. The last frame is identifiedby having the FIN bit set in the TH field.

USER DATA FRAMES TRANSPORT DATA BUFFER --------------| SOURCE = n | -------------- --------------| FIR = 1 || FIN = 0 || SEQUENCE = 3| Note sequence starts with the value in the frame that has the FIR bit = 1| USER DATA 0 | -------------- -----------> ------------- | USER DATA 0 | ------------- --------------| SOURCE = n | -------------- --------------| FIR = 0 || FIN = 0 || SEQUENCE = 4|| USER DATA 1 | -------------- -----------> ------------- | USER DATA 1 | ------------- | USER DATA 0 | ------------- --------------| SOURCE = n |-----------------------------------> -------------- SOURCE ADDRESS passed to application --------------| FIR = 0 || FIN = 1 | FIN indicates last frame| SEQUENCE = 5|| USER DATA 2 | -------------- -----------> ------------- | USER DATA 2 | FIN indicated this is the last frame of message ------------- | USER DATA 1 | ------------- | USER DATA 0 | complete message passed to application ------------- ----------->

Figure 2-3 Assembling of Data From Three Data Frames

DNP Users Group2-4

2.4 TRANSMISSION OF MESSAGES

Figure 2-4 illustrates the transmission of a single frame message using the SEND -CONFIRM frame service. Figure 2-5 illustrates the transmission of a multi-framemessage using the SEND - CONFIRM frame service.

FRAMES SENT FROM DATA LINK COMPLETE MESSAGE FROM APPLICATIONCONFIRM FRAMES RECEIVED --------------- | DESTINATION | parameter from application ---------------

--------------- | USER DATA | | | | 30 octets | --------------- -------------- | DESTINATION | parameter to data link -------------- -------------- | FIR = 1 | | FIN = 1 | 1 TH octet | SEQUENCE = 1 | | USER DATA 0 | send 30 user octets plus 1 TH = 31 octets SEND <----- -------------- CONFIRM -------> --------------------> SUCCESS to application layer

Figure 2-4 Transmission of a Single Frame Message

-------------- | DESTINATION | parameter from application --------------

-------------- | USER DATA | | | | 598 octets | -------------- -------------- | DESTINATION | parameter to data link -------------- -------------- | FIR = 1 | | FIN = 0 | 1 TH octet | SEQUENCE = 2 | | USER DATA 0 | send 249 octets (1 to 249 is the valid range for this count) SEND <------- -------------- CONFIRM --------> -------------- | DESTINATION | parameter to data link -------------- -------------- | FIR = 0 | | FIN = 0 | | SEQUENCE = 3 | | USER DATA 1 | send 249 octets SEND <------- -------------- CONFIRM --------> -------------- | DESTINATION | parameter to data link -------------- -------------- | FIR = 0 | | FIN = 1 | | SEQUENCE = 4 | | USER DATA 2 | send last 100 octets (249 + 249 + 100 = 598) SEND <------- -------------- CONFIRM --------> --------------------> SUCCESS to application layer

Figure 2-5 Fragmenting of a Multi-Frame Application Message


3. TRANSPORT SERVICES ANDRESPONSIBILITIES

3.1 TRANSPORT FUNCTIONS

This section describes the services offered by the pseudo-transport layer and its function.The communication requirements of the network layer and the application layer aresatisfied by the pseudo-transport layer service primitives.

The pseudo-transport layer is responsible for performing the following functions:• Packing user data into multiple frames (more than one) of the defined DNP V3.00

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

• Unpacking multiple frames that are received from the data link into user data• Controlling all aspects of the data link excluding data link configuration.

The pseudo-transport layer is responsible for providing the following services:• Exchange of SDUs between peer DNP V3.00 pseudo-transport layers• Error notification to transport user• Sequencing of SDUs• Prioritized SDU delivery• Quality SDU delivery.

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

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

Priority delivery can be set to EXPEDITED or NORMAL to indicate a high or lowpriority request.

Quality delivery can be set to SEND-NO-REPLY or SEND-CONFIRM to indicatewhether or not message acknowledgment is required.

DNP Users Group3-2

3.2 INTERFACE DESCRIPTION

The pseudo-transport layer service primitives are illustrated in pseudo code to illustratethe requirements and behavior in a real implementation and are not intended as an exactinterface definition.

Transport request (REQ) services can be used at any time after the transport functionshave been initialized and configured by the system.

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

Input:SERVICE Service to perform.TIME_SERVICE Guaranteed time service to perform.source Source address to use in sent message.destination Destination address to use in sent message.send_data_buffer Data to send in message.send_count Number of octets in message.retry_flag Instructs data link layer to retry unacknowledged frames or not.time_of_transmission Time that first bit of first octet of message is to be sent.

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

confirm = 0 Requested service is successful.1 Requested service has failed.2 Requested SEND data service is terminated by the current primary

station. (reception of a NACK frame from the secondary station).3 Service code is not implemented.4 Requested service cannot proceed at this time because the data link

is busy either with a previous requested transaction, currentunrequested transaction or waiting for physical layer availability.


service = 0 Send a message specified in parameters using SEND-CONFIRMframes. Fails if the data link is busy.

1 Send a message specified in parameters using SEND-NO- REPLYframes. Fails if the data link is busy.

2 Expedited send a message specified in parameters using SEND-CONFIRM frames. May necessitate canceling the currentsecondary transaction if a half-duplex system is used.(i.e. forces thedata link to send a NACK frame instead of a CONFIRM frame inthe next secondary transaction). This action only takes place if theprimary 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 maymean canceling the current secondary transaction. (as above).

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

time_service =0 Send message at time specified in time_of_transmission. Thisservice 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 bechecked as often as possible in order to obtain received data.

indications = request_data_link_indications(source_address,destination_address,received_data_buffer,received_data_count,time_of_reception)

Output:source_address Source address of received message.destination_address Destination address of received address.received_data_buffer Received message.received_data_count Number of octets in message.time_of_reception Time at which first bit of first octet of message was received.

DNP Users Group3-4

Indications = 0 No indications to report.1 Data link has received a valid message that has been placed in

received_data_buffer and the number of octets received has beenplaced in received_data_count. The source address of the receivedmessage has been placed in source_address. If the data link isconfigured as a master station then the time that the first bit of thefirst octet of the message was received has been placed intime_of_reception. If the data link is configured as an outstationthen the time_of_reception will still be returned but the serviceuser has to be aware of the possibility of inaccurate times receivedbefore the outstation has been time-synchronized.

2 Pseudo-transport layer has detected a transaction failure.

DNP V3.00 Transport Functions (Version 0.01) 1


CRC cyclic redundancy check

DNP Distributed Network Protocol


IEC International Electrotechnical CommissionISO International Organization for Standardization

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

RTU remote terminal unit


Name of Document: DNP V3.00 Application Layer Protocol DescriptionNetwork File Name: P009-0PD.APP

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



Reason for Changes:

Sept. 30/91 0.00A NFM All Document renamed and relocated fromO:\Document\Other\DOC0362.wp toP009-0FS.APP Reformatted to WIstandards

Nov. 11/91 0.00B J. McFadyen CorrectionsNov. 18/91 0.00C J. McFadyen Minor correctionsJan. 13/92 0.01A J. McFadyen Section 3 Addition of Application Control fieldsApr. 30/92 0.01B NFM All Minor fixes per J. McFadyen.Jul. 24/92 0.01C MCH 3-11 Reversed MSB and LSB in Figure 3-7

as per J. McFadyen.Sep. 8/92 0.02A M. Smith ALL Re-design of qualifier, clarification of

function code usage, added support ofmulti-fragment objects, changedterminology to match IEC definitions.

Oct. 22/92 0.02B M.Smith Time-sync

Removed all references to TIME-SYNCHRONIZATION in theApplication Layer as this is a Data Linkfunction.

Oct. 27/92 0.02C M.Smith Section 3 Re-defined Application Control (AC)octet to handle sequencing offragments and added diagrams toillustrate this. Changed name ofdocument.

Nov.8/92 0.02D MS Sections3, 4

Re-added TIME-SYNC and madesome technical corrections.

Nov.25/92 0.03 LA All Reformatted to WI standards.July 7/93 0.03 P. Morton All Reformatted, added chapters.Jul.21/93 0.03 J. Bhat All Removed Section 9, Reformatted.Aug.20/93 0.03 J. Bhat All Re-edited and reformatted.Aug.30/93 0.03 J. Bhat All Re-edited and reformatted.Sept.01/93 0.03 AV All Format check, glossary, footers.


Reason for Changes:

May 28/97 0.03 S. Tessari All Converted to MS Word 6.0

DNP Users Group


DNP V3.00APPLICATION LAYER

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





TRADEMARK NOTICES


DNP V3.00 Application Layer (Version 0.03) v

TABLE OF CONTENTS

ABOUT THIS DOCUMENT ixPURPOSE OF THIS SPECIFICATION ixWHO SHOULD USE THIS SPECIFICATION ixHELP AND ADDITIONAL DOCUMENTATION ixHOW THIS SPECIFICATION IS ORGANIZED xCONVENTIONS USED IN THIS SPECIFICATION x

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

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

3. DEFINITION OF DNP MESSAGE FIELDS 3-13.1 APPLICATION HEADERS 3-13.2 COMMUNICATION FLOW CONTROL 3-33.3 MASTER REQUEST & UNSOLICITED RESPONSE COLLISIONS 3-83.4 ERROR RECOVERY 3-113.5 FUNCTION CODES 3-123.6 INTERNAL INDICATIONS 3-143.7 OBJECT HEADER 3-16

4. DETAILED FUNCTION CODE DESCRIPTIONS 4-14.1 CONFIRM (FUNCTION CODE 0) 4-14.2 READ (FUNCTION CODE 1) 4-24.3 WRITE (FUNCTION CODE 2) 4-144.4 SELECT (FUNCTION CODE 3) 4-164.5 OPERATE (FUNCTION CODE 4) 4-184.6 DIRECT OPERATE (FUNCTION CODE 5) 4-194.7 DIRECT OPERATE - NO ACKNOWLEDGEMENT (FUNCTION CODE 6) 4-194.8 IMMEDIATE FREEZE (FUNCTION CODE 7) 4-204.9 IMMEDIATE FREEZE - NO ACKNOWLEDGEMENT (FUNCTION CODE 8)4-204.10 FREEZE AND CLEAR (FUNCTION CODE 9) 4-204.11 FREEZE AND CLEAR - NO ACKNOWLEDGEMENT (FUNCTION CODE 10)4-21

DNP Users Groupvi

4.12 FREEZE WITH TIME (FUNCTION CODE 11) 4-214.13 FREEZE WITH TIME - NO ACKNOWLEDGEMENT (FUNCTION CODE 12)4-224.14 COLD RESTART (FUNCTION CODE 13) 4-224.15 WARM RESTART (FUNCTION CODE 14) 4-234.16 INITIALIZE DATA (FUNCTION CODE 15) 4-234.17 INITIALIZE APPLICATION (FUNCTION CODE 16) 4-244.18 START APPLICATION (FUNCTION CODE 17) 4-254.19 STOP APPLICATION (FUNCTION CODE 18) 4-254.20 SAVE CONFIGURATION (FUNCTION CODE 19) 4-264.21 ENABLE SPONTANEOUS MESSAGES (FUNCTION CODE 20) 4-264.22 DISABLE SPONTANEOUS MESSAGES (FUNCTION CODE 21) 4-274.23 ASSIGN CLASSES (FUNCTION CODE 22) 4-274.24 DELAY MEASUREMENT (FUNCTION CODE 23) 4-28

5. CLASSES 5-1

6. TIME SYNCHRONIZATION 6-1

7. BINARY INPUT WITH TIME EVENTS 7-1

8. FILE TRANSFER 8-18.1 FILE IDENTIFIER OBJECTS PERFORMING WRITE FUNCTIONS 8-18.2 FILE IDENTIFIER OBJECT PERFORMING READ FUNCTIONS 8-5


DNP V3.00 Application Layer (Version 0.03) vii

TABLE OF FIGURES

FIGURE 1-1 CONTEXT OF EPA 1-2FIGURE 2-1 MESSAGE SEQUENCE 2-1FIGURE 2-2 APPLICATION REQUEST FORMAT 2-2FIGURE 2-3 APPLICATION RESPONSE FORMAT 2-3FIGURE 3-1 REQUEST HEADER 3-1FIGURE 3-2 RESPONSE HEADER 3-1FIGURE 3-3 APPLICATION CONTROL FIELD 3-2FIGURE 3-4 TYPICAL MESSAGE TRANSACTION FLOW 3-4FIGURE 3-5 MULTI-FRAGMENT RESPONSE & RTU CONFIRMATION

TIMEOUT 3-5FIGURE 3-6 MESSAGE TRANSACTIONS WITH RESPONSE TIMEOUTS 3-6FIGURE 3-7 MESSAGE FLOW WHEN RESPONSE DELAYED ON A

NETWORK 3-7FIGURE 3-8 RESENDING UNSOLICITED RESPONSES DUE TO NETWORK

DELAYS 3-7FIGURE 3-9 SIMULTANEOUS TRANSMISSIONS, IMMEDIATE_PROCESS

MODE 3-9FIGURE 3-10 SIMULTANEOUS TRANSMISSIONS, IMMEDIATE_PROCESS

MODE 3-10FIGURE 3-11 SIMULTANEOUS TRANSMISSIONS, PROCESS_AFTER_CONFIRM

MODE 3-11FIGURE 3-12 OBJECT HEADER 3-16FIGURE 3-13 OBJECT FIELD 3-17FIGURE 3-14 QUALIFIER FIELD 3-18FIGURE 3-15 MESSAGES WITHOUT DATA OBJECTS 3-23FIGURE 3-16 MESSAGES WITH DATA OBJECTS 3-26FIGURE 4-1 CONFIRMATION MESSAGE 4-1FIGURE 4-2 SINGLE OBJECT REQUEST 4-3FIGURE 4-3 MULTIPLE OBJECTS OR RANGES 4-3FIGURE 4-4 SINGLE OBJECT RANGE WRITE 4-15FIGURE 4-5 MULTIPLE OBJECT OR MULTIPLE RANGES 4-15FIGURE 4-6 MASTER SELECTION OF TWO CONTROL OR ANALOG

OUTPUTS 4-17FIGURE 4-7 OUTSTATION RESPONSE 4-17FIGURE 4-8 MASTER SELECTION OF A PATTERN OUTPUT 4-17FIGURE 4-9 OUTSTATION RESPONSE TO THE PATTERN SELECT

MESSAGE 4-18

DNP Users Groupviii

FIGURE 4-10 MASTER SELECTION OF TWO OUTPUTS OR SETPOINTS 4-18FIGURE 4-11 OUTSTATION RESPONSE 4-18FIGURE 4-12 MASTER SELECTION OF TWO OUTPUTS OR SETPOINTS 4-19FIGURE 4-13 OUTSTATION RESPONSE 4-19FIGURE 4-14 MASTER SELECTION OF TWO OUTPUTS OR SETPOINTS 4-19FIGURE 4-15 MASTER IMMEDIATE FREEZE CONTROL MESSAGE 4-20FIGURE 4-16 OUTSTATION RESPONSE TO IMMEDIATE FREEZE 4-20FIGURE 4-17 MASTER IMMEDIATE FREEZE NO-ACK CONTROL MESSAGE 4-20FIGURE 4-18 MASTER FREEZE AND CLEAR CONTROL MESSAGE 4-21FIGURE 4-19 OUTSTATION RESPONSE TO FREEZE AND CLEAR REQUEST 4-21FIGURE 4-20 MASTER FREEZE AND CLEAR NO-ACK CONTROL MESSAGE 4-21FIGURE 4-21 MASTER FREEZE WITH TIME MESSAGE 4-22FIGURE 4-22 OUTSTATION RESPONSE TO FREEZE WITH TIME 4-22FIGURE 4-23 MASTER FREEZE WITH TIME NO-ACK MESSAGE 4-22FIGURE 4-24 MASTER COLD RESTART CONTROL MESSAGE 4-23FIGURE 4-25 OUTSTATION RESPONSE TO COLD RESTART REQUEST 4-23FIGURE 4-26 MASTER WARM RESTART CONTROL MESSAGE 4-23FIGURE 4-27 OUTSTATION RESPONSE TO WARM RESTART REQUEST 4-23FIGURE 4-28 MASTER INITIALIZE DATA CONTROL MESSAGE 4-24FIGURE 4-29 OUTSTATION RESPONSE TO INITIALIZE DATA REQUEST 4-24FIGURE 4-30 MASTER INITIALIZE APPLICATION CONTROL MESSAGE 4-24FIGURE 4-31 OUTSTATION RESPONSE AFTER INITIALIZING

APPLICATION(S) 4-24FIGURE 4-32 MASTER START APPLICATION CONTROL MESSAGE 4-25FIGURE 4-33 OUTSTATION RESPONSE AFTER STARTING

APPLICATION(S) 4-25FIGURE 4-34 MASTER STOP APPLICATION CONTROL MESSAGE 4-25FIGURE 4-35 OUTSTATION RESPONSE AFTER STOPPING

APPLICATION(S) 4-26FIGURE 4-36 MASTER SAVE CONFIGURATION CONTROL MESSAGE 4-26FIGURE 4-37 OUTSTATION RESPONSE AFTER SAVING

CONFIGURATION(S) 4-26FIGURE 4-38 MASTER REQUEST TO ENABLE SPONTANEOUS MESSAGES 4-27FIGURE 4-39 OUTSTATION RESPONSE 4-27FIGURE 4-40 MASTER REQUEST TO DISABLE SPONTANEOUS MESSAGES 4-27FIGURE 4-41 OUTSTATION RESPONSE TO DISABLE SPONTANEOUS

MESSAGE 4-27FIGURE 4-42 MASTER REQUEST TO ASSIGN CLASSES TO DATA 4-28FIGURE 4-43 OUTSTATION RESPONSE TO ASSIGN CLASSES 4-28FIGURE 4-44 MASTER REQUEST TO INITIATE DELAY MEASUREMENT 4-28FIGURE 4-45 OUTSTATION REPONSE TO DELAY MEASUREMENT

REQUEST 4-29FIGURE 8-1 PASSING A FILE IDENTIFIER OBJECT VIA DATA

CONCENTRATORS 8-4

DNP V3.00 Application Layer (Version 0.03) ix

ABOUT THIS DOCUMENT


This document specifies the Distributed Network Protocol (DNP) application layerservices and message format. This document specifies the Application Protocol Data Unit(APDU), application data flow control and any specific information pertaining to DNPapplication layer services.


This specification is for people who need to know the structure and meaning of the fieldsthat make up the application layer message.

This includes programmers implementing and designing an application and QualityAssurance personnel testing and verifying implementations of the application layer.


The following documentation may be helpful.• DNP V3.00 Data Object Library (P009-0BL).

DNP Users Groupx


1. OVERVIEWA general overview of the application layer.

2. MESSAGE FORMATSA definition of the request and response formats.

3. DEFINITION OF THE DNP MESSAGE FIELDSA detailed explanation of the message field.

4. DETAILED FUNCTION CODE DESCRIPTIONA description of the function codes.

5. CLASSESA description of the classes.

6. TIME SYNCHRONIZATIONA description of time synchronizing.

7. BINARY INPUT WITH TIME EVENTSA description of binary input with time events.

8. FILE TRANSFERA description of file transfer.



The term octet used in this document refers to an eight-bit data object and is synonymouswith the term byte. The low order bit of an octet is numbered as bit zero (0) and the highorder is bit seven (7). Data octets illustrated in this document are received and transmittedfrom left to right.

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

1. OVERVIEW

This document defines the Harris Distributed Network Protocol (DNP) application layerAPDU format and services.

The ISO OSI (International Standards Organization Open System Interconnection) modelspecifies seven layers. The International Electrotechnical Commission (IEC) specifies asimplified model consisting of the physical, data link and application layers only. This istermed the Enhanced Performance Architecture (EPA). This document defines the thirdlayer of this EPA or the Application Layer. The data link layer is defined in:

Distributed Network Protocol Version 3.00: Data Link Layer (P009-0PD.DL).

Harris Canada Inc. has developed the DNP for application in both SCADA anddistributed automation (DA) systems. Primary focus has been on the current and futureneeds of these areas. The DNP is suitable for use in highly secure, moderate speed andmoderate throughput applications. The protocol is highly flexible and open-endedwithout any target hardware specific constructs.

Figure 1-1 on the following page shows the EPA structure and how it fits into the entirecommunication system. As shown, the User Layer interfaces to the Application Layer inone place only implying that the user has no need to know of the other elements of thecommunication system except the Application Layer interface. The User Layer makesuse of the Application Layer to send/receive complete SCADA/DA messages to/from amaster station or outstation.

DNP Users Group1-2

Figure 1-1 Context of EPA

1.1 DESCRIPTION AND IEC RELATIONSHIP

The DNP Application Layer APDU is based in principle on the IEC 870-5-3 and 870-5-4draft documents as prepared by TC-57 WG 03. Structurally, the Application Layer PDU(Protocol data Unit) fits the IEC description of an APDU. The user sends ApplicationUser Data to the Application Layer where it is converted to ASDU (Application ServiceData Unit). In DNP, the Application User Data is converted into multiple ASDUs. EachASDU is then prefixed by APCI (Application Protocol Control Information) which isthen packaged as an APDU. In DNP, each APDU that is part of the larger multi-APDU isreferred to as a fragment and there is a restriction that each fragment contains completedata objects only and that the function code portion of the APCI (Application ProtocolControl Information) is identical in each fragment of the same message or multi-APDU.That is, there will be no fragmentation of information objects between APDUs and thesame operation must be requested of each object in the message. This is to ensure thateach fragment on its own can be processed and also implies that each ASDU containsonly complete data objects. In reverse, the Application Layer receives multiple APDU(one at a time) where it removes the APCI to obtain the ASDU and assembles the ASDUsinto Application User Data.

User Layer

Application Layer

Data Link Layer

Physical Layer

Communication Medium


2. MESSAGE FORMATS

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

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

Master Outstation

Send Request --------------------> Accept request and process<-------------------- Optional confirmation

Accept response <----------------- Send Response

Optional confirmation --------------------------------->

Important change detected

Accept response <----------------- Send Unsolicited Response

Optional confirmation --------------------------------->

Figure 2-1 Message Sequence

As shown above, the master station sends an Application Layer Request to the outstationwhich returns an Application Layer Response. The outstation can decide tospontaneously transmit data using an Application Layer Unsolicited Response message.For a master, a request/response transaction with a particular outstation must becompleted before another requests can be sent to that outstation. A master station mayaccept unsolicited responses while the request transaction is in progress. For anoutstation, a request/response transaction must be completed before any other requests areaccepted or unsolicited responses are sent. Unsolicited responses can be sent before orafter the request/response transaction but not during. If an outstation is presently in themiddle of an unsolicited transaction (i.e. waiting for a confirmation), it may conditionallyaccept one request command from the master. (For detailed information, see Section 3.3 -Master Request and Unsolicited Response Collisions).

In addition, each response or request can consist of 1 or more individual fragments.Each fragment however should be digestible (parsable) and therefore executable (because

DNP Users Group2-2

the function code is part of every fragment). It is advised that devices with limitedmessage storage capabilities should only be sent single fragment message requests whenthe expected response (from all fragments sent) is larger than one fragment. This is toensure that devices can process a request and build and more importantly send a responsebefore the next request is received. Otherwise, multi-fragment messages may requiremulti-fragment responses which may require more message storage than the device hasavailable.

2.1 APPLICATION REQUEST FORMAT

The application request message format (APDU) is illustrated in Figure 2-2. The APDUis made up of an APCI block which contains message control information and an ASDUwhich contains information to be processed by the receiving station. The APCI is oftencalled a request header in an application request message. In DNP, the ASDU is optionaland is used when the message meaning is not conveyed completely in the request header.The request header contains information on how to assemble a multi-fragment messageand on the purpose of the message. The request header is present in all application layerrequest APDUs. If the request header implies all the needed information required to carryout the request, the ASDU is not present.

Each ASDU consists of one or more Data Unit Identifiers (DUI) or object headers andoptional associated Information Objects (IO) or data fields. The object header can specify0 or more en that returned by the receiving station or that follow the header in themessage.

• DUI • IO .. IO • DUI • IO ••••••••••••••••••••••••••••••••••••••••••• ....••••••••••••••••••••••••• Request Header • Object Header • data • • Object Header • data •• • • • • • •••••••••••••••••••••••••••••••••••••••••••.....••••••••••••••••••••••••• APCI • ASDU •

Figure 2-2 Application Request Format

Request Header The request header identifies the purpose of the message andconsists of APCI (Application Protocol Control Information).

Object Header This header identifies the data objects that follow.Data Data object(s) of the type specified in the object header.

2.2 APPLICATION RESPONSE FORMAT

The response from an Outstation to an application layer request APDU or the unsolicitedresponse from an outstation have the format illustrated in Figure 2-3. The format isidentical in form to the request. The APCI is often called a response header in anapplication response message. The response header contains the same information as therequest header plus an additional field containing internal indications of the outstation.The response header is always part of the application response. The response ASDU has


the same format of the request message with one notable exception (explained in Section3).

• DUI • IO .. IO • DUI • IO ••••••••••••••••••••••••••••••••••••••••••• ....••••••••••••••••••••••••• Response Header• Object Header • data • • Object Header • data •• • • • • • •••••••••••••••••••••••••••••••••••••••••••.... ••••••••••••••••••••••••• APCI • ASDU •

Figure 2-3 Application Response Format

Response Header The response header identifies the purpose of the message andconsists of APCI (Application Protocol Control Information).

Object Header This header identifies the data objects that follow.Data Data object(s) of the type specified in the object header.

DNP Users Group2-4


3. DEFINITION OF DNP MESSAGEFIELDS

This section describes the request and response headers (APCIs) which control thesequence and flow of application messages between a master station and an Outstation,and the ASDU which include DUI or data object headers. The headers are used toassemble multi-fragment (multi-APDU) messages into Application User Data. Theobject headers are used to identify uniquely the information object(s) that optionallyfollow the header.

3.1 APPLICATION HEADERS

3.1.1 Request Header

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

•••••••••••••••••••••••••••••••••••••••• Application Control • Function Code •• AC • FC ••••••••••••••••••••••••••••••••••••••••

Figure 3-1 Request Header

3.1.2 Response Header

The response header has three fields as illustrated below.

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Application Control • Function Code • Internal Indications •• AC • FC • IIN •• • • •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 3-2 Response Header

3.1.3 Application Control

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

DNP Users Group3-2

Application messages may be packaged into fragments, with each fragment small enoughto fit into the application's message buffer. The recommended size of the fragment bufferis 2048 bytes in order to maintain compatibility with current DNP devices. Each fragmenthas an application header and appropriate object headers so that each fragment can beprocessed as individual messages which can then be discarded making room for the nextfragment.

7 6 5 4 3 2 1 0 bit••••••••••••••••••••••••••••••••••••••••••••••••••• FIR • FIN • CON • SEQUENCE •• • • • •••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 3-3 Application Control Field

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

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

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

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

NOTE: An Unsolicited Response is a message generated by an Outstation,usually containing event data, which is sent automatically to the master.The master does not need to poll the Outstation for this data.

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


3.2 COMMUNICATION FLOW CONTROL

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

1) CON bit field. Setting/clearing this bit enables/disables message CONFIRMationresponses. A CONFIRMation response is an application acknowledgments of theprevious request or response message.

2) FIR and FIN bit fields.3) Sequence Number field. This number is used to assemble multi-fragment

messages and identify which responses match particular requests.4) Master station and Outstation application response time-outs. These specify how

long an application must wait for a response or CONFIRMation response beforere-transmitting or aborting the transaction. The application may or may notsupport re-transmission of transactions at the application layer.

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

An Outstation must completely process a request and respond to it before beginning toprocess a second request. It cannot simultaneously process multiple requests.

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

The following rules dictate how sequence numbers work:• The sequence number rolls over from 15 to 0 or from 31 to 16. Each successive

request fragment from the DNP master station has an incremented sequence number.The exception is for retries on requests. For single fragment request retries, thesequence number is NOT incremented. For multi fragment request retries, thesequence number of the first fragment of the request retry equals the sequence numberof the last fragment of the request which has just failed.

• A single fragment response to a single fragment request has the same sequence numberas the request.

• The CONFIRMation response to a request or response has the same sequence numberas the request or response.

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

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

DNP Users Group3-4

The use of this sequence number scheme ensures the Outstation and master station cancope with all occurrences of messages being lost or delayed on a communication network.The following rules are obeyed by both the Outstation and master station:• If the system uses application level retries, when a response is not received before

time-out, the request will be re-transmitted with the same sequence number.• If two messages are received with the same sequence number, it usually means that the

response to the message was not received by the other station. In this case, retransmitthe response (re-processing the message is unnecessary).

• If two CONFIRMation responses are received with the same sequence number, ignorethe second response.

The following figures illustrate some cases of message transactions and how theSequence Numbers prevent problems. In the examples, SEQ is the Sequence Numberand CON is the Confirmation Requested bit in the message. Time progresses from left toright in the diagrams. The vertical arrows represent the flow of messages between theOutstation and the master station.

Case One illustrates typical message transactions. The master sends a request, theOutstation responds and the master CONFIRMs the response. Later on, the Outstationsends an Unsolicited Response to the master station. When the Outstation transmits theresponse, it starts a CONFIRMation response timer. If this timer had expired before theCONFIRMation was received, the Outstation would have re-transmitted the response.

Case Two shows a similar situation to Case One except the master request requires aCONFIRMation response as well as a normal response.

CASE 1 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. • • • Response • CONFIRM • CONFIRM • expected. • (SEQ=7) • (SEQ=24) • (CON=0) • • • (SEQ=7) • • � � � --------------------------------------------------------------------Outstation � � • Response • Unsol. • to master • Response • (CON=1) • (CON=1) • (SEQ=7) • (SEQ=24) • •

CASE 2 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. • • Response • CONFIRM • expected. • (SEQ=2) • (CON=0) • • (SEQ=2) • � � --------------------------------------------------------------------Outstation � � • CONFIRM • Response • (SEQ=2) • to master • • request • • (CON=1) • • (SEQ=2)

Figure 3-4 Typical Message Transaction Flow


NOTE: In Figure 3-4 and some of the following figures, the CON bit is set in theOutstation responses. The CON bit may be clear in some transaction (e.g.when the response does not contain event data). In this case, data loss dueto communication loss is often not critical. The Outstation assumes thatthe response was successful.

Case Three illustrates a multi-fragment response from the Outstation. The sequencenumber in successive fragments is incremented. Note that the next request from themaster station used sequence number equals 4.

In Case Four, the response from the Outstation is not received by the master station. TheOutstation waits for a CONFIRMation, and when its CONFIRMation time-out expires itre-transmits the response.

CASE 3 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. • • • Request. • Response • CONFIRM • CONFIRM • (SEQ=4) • expected. • (SEQ=2) • (SEQ=24) • • (CON=0) • • • • (SEQ=2) • • • � � � � --------------------------------------------------------------------Outstation � � • Response • Response • Frag. 1 • Frag. 2 • (CON=1) • (CON=1) • (SEQ=2) • (SEQ=3) • •

CASE 4 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. • • Response Response • CONFIRM • expected. not • (SEQ=3) • (CON=0) received. • • (SEQ=3) • � � --------------------------------------------------------------------Outstation � � • Response CONFIRM not • Response • (CON=1) received. RTU • (CON=1) • (SEQ=3) time-out. Resend • (SEQ=3) • response. • • •

Figure 3-5 Multi-Fragment Response & RTU Confirmation Time-out

From the Outstation side, Case Five is identical to Case Four. In Case Five unlike CaseFour, the master does CONFIRM the first Outstation response. This CONFIRMation isnot received by the Outstation. When the Outstation resends the response, the master willrepeat the CONFIRMation. The master will not re-process the second response.

Case Six illustrates the case where the master request is not received by the Outstation.The master repeats the request after a response time-out occurs.

DNP Users Group3-6

CASE 5 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. • • • Response • CONFIRM • CONFIRM • expected. • (SEQ=10) • (SEQ=10) • (CON=0) • • • (SEQ=10) • • � � � --------------------------------------------------------------------Outstation � � • Response CONFIRM not • Response • (CON=1) received. RTU • (CON=1) • (SEQ=10) time-out. Resend • (SEQ=10) • response. • • •

CASE 6 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. Time-out on • Request. • • Response response. • Response • CONFIRM • expected. Resend • expected. • (SEQ=5) • (CON=0) Request. • (CON=0) • • (SEQ=5 ) • (SEQ=5) • � � � --------------------------------------------------------------------Outstation � Request not • Response received. • (CON=1) • (SEQ=5) • •

Figure 3-6 Message Transactions With Response Time-outs

Case Seven is similar to Case Four. In both cases, the Outstation response to the masterrequest is not received. In Case Four the Outstation timed out waiting for theCONFIRMation and repeated the response. In Case Seven however, the master times outfirst and repeats the request. The Outstation automatically stops waiting for theCONFIRMation and repeats its previous response. Case Seven also illustrates anotherpossible condition. The original response that the master did not receive is delayed in thecommunication network. The master re-sends the request, the Outstation replies and themaster finishes the transaction sequence with a CONFIRMation. The original responsefrom the Outstation then arrives at the master station. The master station assumes that thefirst CONFIRMation was not received by the Outstation. It therefore re-transmits theCONFIRMation. The Outstation receives and discards this second CONFIRMation.

Case Eight is similar to Case Seven. In this case, the first CONFIRMation from theOutstation is delayed in the communication network. When this CONFIRMationeventually arrives at the master station, it is ignored.


CASE 7 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. Response • Request. • • • Response not received. • Response • CONFIRM • CONFIRM • expected. Resend • expected. • (SEQ=8) • (SEQ=8) • (CON=0) request. • (CON=0) • • • (SEQ=8) • (SEQ=8) • • � � � � --------------------------------------------------------------------Outstation � � • Response • Response RTU ignores • (CON=1) • (CON=1) second • (SEQ=8) • (SEQ=8) CONFIRM • • • •

CASE 8 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. CONFIRM delayed • Request. Master receives • No response in network. • No response first delayed • expected. Time-out. Master • expected. CONFIRM and • (CON=0) resends request. • (CON=1) ignores it. • (SEQ=5 ) • (SEQ=12) � � --------------------------------------------------------------------Outstation � � • CONFIRM • CONFIRM • (SEQ=12) • (SEQ=12) • • • • • •

Figure 3-7 Message Flow When Response Delayed on a Network

In Case Nine, the Unsolicited Response is re-transmitted by the Outstation when a time-out on the CONFIRMation occurs. The master eventually receives it twice. It does notprocess it the second time, but does respond to it in the same way as the first time. TheOutstation discards the second CONFIRMation. This illustrates a situation wherenetwork delays, and not message losses, cause time-outs to occur.

CASE 9 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master Unsol. response • Master • delayed in • CONFIRM receives the • CONFIRM network. • (SEQ=30) delayed unsol. • (SEQ=30) Not received. • response. • • Resend CONFIRM. • � � --------------------------------------------------------------------Outstation � � • Unsol. Time-out on • Unsol. RTU discards • response. CONFIRM • Response. second • (CON=1) Resend. • (CON=1) CONFIRM. • (SEQ=30) • (SEQ=30) • •

Figure 3-8 Resending Unsolicited Responses Due to Network Delays

DNP Users Group3-8

3.3 MASTER REQUEST & UNSOLICITED RESPONSECOLLISIONS

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

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

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

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

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

3.3.1 IMMEDIATE_PROCESS Mode

Figures 3-9 and 3-10 illustrate the normal functionality when a master station request andan Outstation Unsolicited Response are transmitted simultaneously and the Outstation isin the IMMEDIATE_PROCESS mode (i.e. request is not a READ request).

In Case Ten, the master immediately responds to the Unsolicited Response. TheOutstation immediately processes and responds to the master station request. Note thatthe two CONFIRMation responses could be sent from the master in the opposite order tothe order shown in Case Ten. This would not confuse the Outstation.

Case Eleven illustrates a basic message flow where the Unsolicited Response does notrequire a CONFIRMation.


CASE 10 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. • • • Response • CONFIRM • CONFIRM • expected. • (SEQ=7) • (SEQ=24) • (CON=0) • • • (SEQ=7) • • � � � --------------------------------------------------------------------Outstation � � • Unsol. • Response • Response • to master • (CON=1) • request • (SEQ=24) • (CON=1) • • (SEQ=7)

CASE11 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. Store and • • Response process the • CONFIRM • expected. unsol. response. • (SEQ=2) • (CON=1) • • (SEQ=2) • � � --------------------------------------------------------------------Outstation � � � • Unsol. • CONFIRM • Response • response • (SEQ=2) • to master • (CON=0) • • request • (SEQ=22) • • (CON=1) • • • (SEQ=2)

Figure 3-9 Simultaneous Transmissions, IMMEDIATE_PROCESS Mode

In Case Twelve, the Unsolicited Response is CONFIRMed in between CONFIRMationsto two fragments of a multi-fragment response to the master request.

Case Thirteen illustrates the situation where the Unsolicited Response is not received bythe master station. The Outstation responds to the master request, then after theCONFIRMation time-out for the Unsolicited Response, the Outstation re-transmits theUnsolicited Response. The master then CONFIRMs the Unsolicited Response. Note thatit is possible that the first Unsolicited Response later arrives at the master station (it wasdelayed in the network). The master would not re-process the response, but would replyto it again. The Outstation would discard the reply.

DNP Users Group3-10

CASE 12 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. • • • • Response • CONFIRM • CONFIRM • CONFIRM • expected. • (SEQ=2) • (SEQ=18) • (SEQ=3) • (CON=0) • • • • (SEQ=2) • • • � � � � --------------------------------------------------------------------Outstation � � � • Unsol. • Response • Response • Response • Frag. 1 • Frag. 2 • (CON=1) • (CON=1) • (CON=1) • (SEQ=18) • (SEQ=2) • (SEQ=3) • • •

CASE 13 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. Master does • • • Response not receive • CONFIRM • CONFIRM to • expected. unsol. response. • (SEQ=3) • unsol. • (CON=0) • • response • (SEQ=3) • • (SEQ=28) � � � --------------------------------------------------------------------Outstation � � � • Unsol. • Response RTU time-out for • Unsol. • response • (CON=1) CONFIRM to unsol. • response • (CON=1) • (SEQ=3) response. Resend • (CON=1) • (SEQ=28) • request. • • • •

Figure 3-10 Simultaneous Transmissions, IMMEDIATE_PROCESS Mode

3.3.2 PROCESS_AFTER_CONFIRM Mode

When a READ request for system data is received by the Outstation and a previousUnsolicited Response has not yet been CONFIRMed, the Outstation will not process theREAD request until it receives the CONFIRMation to the Unsolicited Response. If theOutstation was to respond to the READ request immediately, there is a risk of data beinglost or duplicated. This is due to the possibility that the READ request requests dataobjects which are already in the unCONFIRMed Unsolicited Response.

Case Fourteen illustrates the situation where the READ request is received while theOutstation is waiting for a CONFIRMation. The Outstation will not process the READrequest until the CONFIRMation is received.

Case Fifteen is similar to Case Fourteen except the Unsolicited Response is notCONFIRMed. The Outstation must re-transmit the Unsolicited Response until it isCONFIRMed or its configured re-transmission limit is reached. If this limit is everreached, the Outstation will internally re-buffer the data in the Unsolicited Response,respond to any outstanding master station requests then try to send the UnsolicitedResponse again.


CASE 14 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. • • • Response • CONFIRM • CONFIRM • expected. • to unsol. • (SEQ=2) • (CON=0) • response • • (SEQ=2) • (SEQ=18) • � � � --------------------------------------------------------------------Outstation � RTU waits RTU now � • Unsol. for confirm processes • Response • Response Do not process master • (CON=1) • (CON=1) request. request. • (SEQ=2) • (SEQ=18) • • •

CASE 15 Time ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••→Master • Request. Master does • • • Response not receive • CONFIRM to • CONFIRM • expected. unsol. response. • unsol. • (SEQ=3) • (CON=0) • response • • (SEQ=3) • (SEQ=28) • � � � --------------------------------------------------------------------Outstation � � � • Unsol. RTU time-out for • Unsol. • Response • response CONFIRM to unsol. • response • (CON=1) • (CON=1) response. Resend • (CON=1) • (SEQ=3) • (SEQ=28) unsol. response. • (SEQ=28) • • • •

Figure 3-11 Simultaneous Transmissions, PROCESS_AFTER_CONFIRM Mode

3.4 ERROR RECOVERY

The DNP application layer relies on the data link layer for all message transmission,reception and error checking. The application layer is NOT responsible for recoveringfrom communication problems. When and if a transaction failure is reported by the datalink layer, the application layer should fail the application layer transaction and report theerror to the user. In addition, the master application layer should indicate the value of theInternal Indications in all Outstation responses. The user layer is responsible for initiatingany kind of error recovery procedure. In particular, the user layer should make use of theIIN or Internal Indications that are returned in any Outstation response.

DNP Users Group3-12

3.5 FUNCTION CODES

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

CODE FUNCTION DESCRIPTION

Transfer Function Codes

0 Confirm Message fragment confirmation used inboth requests and responses. Noresponse to this message is required.

1 Read Request specified objects from Outstation;respond with objects requested that areavailable.

2 Write Store specified objects in Outstation;respond with status of the operation

Control Function Codes

3 Select Select or arm output points but do not setor produce any output action (controls,setpoints, analog outputs) ; respond withthe status of the control points selected.The Operate function code is required toactivate these outputs.

4 Operate Set or produce the output actions on thepoints previously selected with the Selectfunction; respond with the status of thecontrol points.

5 Direct Operate Select and set or operate the specifiedoutputs; respond with the status of thecontrol points.

6 Direct Operate- NoAcknowledgment

Select and set or operate the specifiedoutputs but do not send a response to therequest.

Freeze Function Codes

7 Immediate Freeze Copy the specified objects to a freezebuffer and respond with status of theoperation.

8 Immediate Freeze-No Acknowledgment

Copy the specified objects to a freezebuffer; do not respond with a message.

Transfer Function Codes

9 Freeze and Clear Copy the specified objects to a freezebuffer, then clear the objects; respond withthe status of the operation.



10 Freeze and Clear-No Acknowledgment

Copy the specified objects to a freezebuffer, then clear the objects; do notrespond with a message.

11 Freeze with Time Copy the specified objects to a freezebuffer at the specified time and intervals;respond with the status of the operation.

12 Freeze with Time-No Acknowledgment

Copy the specified objects to a freezebuffer at the specified time and intervals;do not respond with a message.

Application Control Function Codes

13 Cold Restart Perform the desired reset sequence;respond with a time object indicating timetill Outstation availability.

14 Warm Restart Perform the desired partial reset sequence;respond with a time object indicating timetill Outstation availability.

15 Initialize Data toDefaults

Initialize the specified data to power upinitial values; respond with status of theoperation.

16 Initialize Application Ready the specified application(s) to run;respond with status of the operation.

17 Start Application Start running the specified application(s);respond with status of the operation.

18 Stop Application Stop the specified application(s); respondwith status of the operation.

Configuration Function Codes

19 Save Configuration Save the specified configuration to non-volatile memory; respond with a time objectindicating time till Outstation availability.

20 Enable UnsolicitedMessages

Enable spontaneous reporting of thespecified data object(s); respond withstatus of the operation

21 Disable UnsolicitedMessages

Disable spontaneous reporting of thespecified data object(s); respond withstatus of the operation

22 Assign Class Assigned specified data object(s) to aparticular class

Time Synchronization Function Codes

23 Delay Measurement Allows the application to calculate the pathdelay (or propagation delay) for a particularOutstation. The value calculated from thisfunction code should be used to adjust thetime of day when setting the Outstationtime.

DNP Users Group3-14


Reserved

24 - 120 Reserved for future use

121 - 128 Reserved for testing only

Response Function Codes

0 Confirm Message fragment confirmation used inboth requests and responses. No responseto this message is required.

129 Response Response to a request message

130 Unsolicited Message Unsolicited response that was notprompted by a request.

Table 3-1 Function Codes

3.6 INTERNAL INDICATIONS

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

••••••••••••••••••••••••••••••• First Octet Second Octet •• | •••••••••••••••••••••••••••••••

First Octet•••••••••••••••••••••••••••••••••••••••••••••••••• 7 • 6 • 5 • 4 • 3 • 2 • 1 • 0 • Bit number• • • • • • • • ••••••••••••••••••••••••••••••••••••••••••••••••••

A one (1) in the bit position indicates the described state.

Bit 0 - All stations message received- Set when a request is received with the destination address of the

all stations address (ffff hexadecimal).- Cleared after next response (even if response to global request is

required)- Used to let the master station know that a Broadcasted message

was received by this station.

Bit 1 - Class 1 data available- Set when data that has been configured as Class 1 data is ready to be sent

to the master- Master station should request this class data from the Outstation when this

bit is set in a response

Bit 2 - Class 2 data available


- Set when data that has been configured as Class 2 data is ready to be sentto the master

- Master station should request this class data from the Outstation when thisbit is set in a response

Bit 3 - Class 3 data available- Set when data that has been configured as Class 3 data is ready to be sent

to the master- Master station should request this class data from the Outstation when this

bit is set in a response

Bit 4 - Time-synchronization required from the master. The master synchronizesthe time by writing the Time and Date object to the Outstation.

- Cleared when the time is set by the master. This bit is also cleared whenthe master explicitly writes a 0 into this bit of the Internal Indication objectof the Outstation.

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

- Clear when the Outstation is in the Remote state. That is, the Outstation'scontrol outputs are accessible through the DNP protocol.

Bit 6 - Device trouble- Set when an abnormal condition exists at the Outstation. The device

profile for a given device states the conditions that effect this bit.- This should only be used when the state can not be described by a

combination of one or more of the other IIN bits.

Bit 7: - Device restart- Set when the user application at the Outstation restarts.- Cleared when the master explicitly Writes a 0 into this bit of the Internal

Indications object in the Outstation.

Second Octet

•••••••••••••••••••••••••••••••••••••••••••••••••• 7 • 6 • 5 • 4 • 3 • 2 • 1 • 0 • Bit number• • • • • • • • ••••••••••••••••••••••••••••••••••••••••••••••••••

Bit 0 - Function code not implemented

Bit 1 - Requested object(s) unknown. The Outstation does not have the specifiedobjects or there are no objects assigned to the requested class.

- This indication should be used for debugging purposes and usuallyindicates a mismatch in device profiles or configuration problems.

DNP Users Group3-16

Bit 2 - Parameters in the qualifier, range or data fields are not valid or out ofrange. This is a catch-all for application request formatting errors.

- This indication should be used for debugging purposes and usuallyindicates configuration problems.

Bit 3 - Event buffer(s), or other application buffers have overflowed. Forexample, COS/SOE buffers have overflowed.

- The master should attempt to recover as much data as possible andindicate to the user that their may be lost data. The appropriate errorrecovery procedures should be initiated by the user.

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

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

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

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

3.7 OBJECT HEADER

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

••••••••••••••••••••••••••••••• Object • Qualifier • Range •• • • •••••••••••••••••••••••••••••••

Figure 3-12 Object Header

Object Specifies the object group and variation of the objects that follow theheader as described in section 3. OBJECT. This is a two-octet field. Theobject field uniquely identifies the type or class of object which gives thestructure (and hence size) of the data object.

Qualifier Specifies the meaning of the range field as described in section 3.QUALIFIER. This is a one-octet field. The qualifier specifies how therange field is to be interpreted.


Range Indicates the quantity of objects, starting and ending index or identifiersfor the objects in question as described in section 3. This field uniquelyidentifies the objects in question.

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

3.7.1 Object Field

The Object field specifies an object group and the variation of the object within thegroup. The combined object group plus variation specifies uniquely the object to whichthe message refers. The currently defined object structures are described in DNP-V3.00Data Object Library (P009-0BL).

Objects may be assigned to one of four classes. When the Object field specifies a dataclass instead of a specific object type, the object field refers indirectly to all the dataobjects assigned to that class of data and not to any specific object type. See Section 5:CLASSES for more detail.

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

Consider the example where the request message specifies counter objects in the firstoctet and the variation is 0. Given that the Outstation supports only 16 bit counters, itwill respond with an object header with the variation field set to indicate that the counterobjects are 16 bit counters.

With the same request message directed to another station, the returned object header mayindicate a 32 bit count field in the counter objects it returns. By requesting data with thevariation set to 0, it is not necessary for the master to know what variations the Outstationsupports. The master must however be able to interpret the object headers and have someknowledge of the structure of each variation.

first octet second octet•••••••••••••••••••••••••••••••••••••••••• • 0 or Object variation• Application request direction• Object Group ••••••••••••••••••••••••• • Object variation • Application response direction•••••••••••••••••••••••••••••••••••••••••

Figure 3-13 Object Field

DNP Users Group3-18

3.7.2 Qualifier Field

The qualifier field specifies the meaning of the range field.

7 6 5 4 3 2 1 0 bit••••••••••••••••••••••••••••••••••••••••••••••••••• R • Index Size • 4 bit Qualifier Code •• • • •••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 3-14 Qualifier Field

R Reserved bit always set to 0

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

Index Size (3-bits)

• In a Request Object Header when Qualifier Code equals 11

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

0 = not valid with qualifier code 111 = 1 octet identifier size2 = 2 octet identifier size3 = 4 octet identifier size4 = reserved5 = reserved6 = reserved7 = reserved

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

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

0 = objects are packed with no index prefixing them1 = objects are prefixed with a 1 octet index2 = objects are prefixed with a 2 octet index3 = objects are prefixed with a 4 octet index4 = objects are prefixed with a 1 octet object size


5 = objects are prefixed with a 2 octet object size6 = objects are prefixed with a 4 octet object size7 = reserved

Qualifier Code (4-bits)

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

• Start and Stop Sub-Fields in the Range Field

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

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

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

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

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

Some Qualifier Code definitions are:

0 = 8 bit start and stop indices in the Range Field1 = 16 bit start and stop indices in the Range Field2 = 32 bit start and stop indices in the Range Field3 = 8 bit absolute address identifiers in the Range4 = 16 bit absolute address identifiers in the Range5 = 32 bit absolute address identifiers in the Range

• All objects of the given object type

When the Qualifier Field equals 6, the length of the range field is 0 (i.e. no rangefield) because all the data objects of the specified type are being referred to. Thisqualifier can be used in messages with object headers only because it cannot

DNP Users Group3-20

uniquely identify data objects if they are present in the message. The Index sizeshould be set to 0 when this Qualifier code is used.

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

• Single field quantity

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

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

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

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

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

Some Qualifier Code definitions are:

7 = 8 bit single field quantity8 = 16 bit single field quantity9 = 32 bit single field quantity

• Free-format Qualifier (Qualifier Code 11)

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

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

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


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

• Reserved Qualifier Codes

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

10 = reserved12 = reserved13 = reserved14 = reserved15 = reserved

3.7.3 Range

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

The following figure defines all the valid qualifier/range/index combinations for a requestor response which do NOT contain any IO or data objects and simply specifies the objectsin question. The bytes described appear after the qualifier octet of the object header andbefore the next object header or end of message.

Request for known points specified with a Range of indices.

Use Q-code 0-5 for describing points related in sequence:

•••••••••••••••••••••• Start • Stop • Q-code 0 and 3; I-size MUST be 0• 8 bit • 8 bit • Definition of Range Field.• • • Points are I1 to I2 inclusive• I1 • I2 ••••••••••••••••••••••

LSB MSB LSB MSB•••••••••••••••••••••••••••••••••••••••••• 16 bit Start • 16 bit Stop • Q-code 1 and 4; I-size MUST be 0• • • • • Points are I1 to I2 inclusive• • • • •• I1 • I2 •• • ••••••••••••••••••••••••••••••••••••••••••

DNP Users Group3-22

LSB MSB LSB MSB•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 32 bit Start • 32 bit Stop •• • • • • • • • •• • • • • • • • •• I1 • I2 •• • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Q-code 2 and 5; I-size MUST be 0Points are I1 to I2 inclusive

Use Q-code 6 for describing ALL points of the given data type:

(There is no range field or indices with this qualifier

Use Q-code 7-9 for describing a number of unrelated points:

••••••••••••Quantity • Q-code 7; I-size MUST be 0• 8 bit • Points are 0 .. Q-1 inclusive• •• Q •• ••••••••••••

•••••••••••••••••••• •••••••••••Quantity • Index • • •• • Index • • • Q-code 7; I-size MUST be 1• 8 bit • • • • Points are I1, I2 .. IQ inclusive• • I1 • ....... • IQ •• Q • • • •• • LSB • • LSB ••••••••••••••••••••• ••••••••••

•••••••••••••••••••••••••• ••••••••••••••••Quantity • Index • • Index • Q-code 7; I-size MUST be 2• 8 bit • • • • Points are I1, I2 .. IQ inclusive• • I1 • .......• IQ •• Q • • • •• • LSB • MSB • • LSB • MSB ••••••••••••••••••••••••••• •••••••••••••••

••••••••••••••••••••••••••••••••• •••••••••••••••••••••Quantity • Index • • Index • Q-code 7; I-size MUST be 3• 8 bit • • • • Points are I1, I2 .. IQ inclusive• • I1 • ....... • IQ •• Q • • • •• • LSB • • • MSB • • LSB • • • MSB •••••••••••••••••••••••••••••••••• ••••••••••••••••••••

LSB MSB•••••••••••••••••••••• 16 bit Quantity • Q-code 8; I-size MUST be 0• Q • Points are 0 to Q-1 inclusive• • ••••••••••••••••••••••

LSB MSB•••••••••••••••••••••••••••• •••••••••• 16 bit Quantity • Index• • Index • Q-code 8; I-size MUST be 1• | • LSB •...... • LSB • Points are I1,I2 .. IQ inclusive• • • • •• Q • I1 • • IQ ••••••••••••••••••••••••••••• •••••••••

LSB MSB••••••••••••••••••••••••••••••••• ••••••••••••••• 16 bit Quantity • Index • • Index • Q-code 8; I-size MUST be 2• • • LSB • MSB•......• LSB • MSB• Points are I1,I2 .. IQ inclusive• • • • • • •• Q • I1 • • IQ •••••••••••••••••••••••••••••••••• ••••••••••••••

LSB MSB••••••••••••••••••••••••••••••••••••••• ••••••••••••••••••••• 16 bit Quantity • Index • • Index • Q-code 8; I-size MUST be 3• • • LSB • • • MSB•......• LSB • • • MSB• Points are I1,I2 .. IQ inclusive• • • • • • • • • • • •• Q • I1 • • IQ •••••••••••••••••••••••••••••••••••••••• ••••••••••••••••••••


LSB MSB•••••••••••••••••••••••••••••••••••••••••• 32 bit Quantity • Q-code 9; I-size MUST be 0• • | • • Points are 0 .. IQ-1• • IQ • ••••••••••••••••••••••••••••••••••••••••••

LSB MSB•••••••••••••••••••••••••••••••••••••••••••••••••• ••••••••••• 32 bit Quantity • Index • • Index • Q-code 9; I-size MUST be 1• | | | • LSB •....• LSB • Points are I1, I2 .. IQ• Q • I1 • • IQ ••••••••••••••••••••••••••••••••••••••••••••••••••• ••••••••••

LSB MSB•••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••• 32 bit Quantity • Index • • Index • Q-code 9; I-size MUST be 2• | | | • LSB | MSB •....• LSB | MSB • Points are I1, I2 .. IQ• Q • I1 • • IQ ••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••

LSB MSB•••••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••••••••• 32 bit Quantity • Index • • Index • Q-code 9; I-size MUST be 3• | | | • LSB | | | MSB •....• LSB | | | MSB • Points are I1, I2 .. IQ• Q • I1 • • IQ ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••••••••

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

•••••••••••••••••••••••••••••• •••••• •••••••••••••• ••••••• 8-bit • 8-bit • • • • • • 8-bit • • • •• • • O11 • O12• .... • O1N•...• • OQ1•...• OQN•• Q •Size N1• • • • • •Size NQ• • • ••••••••••••••••••••••••••••••• •••••• •••••••••••••• ••••••

Q-code 11; Index size MUST be 1Octets Oi1 .. OiN form the object identifier for Object i where 0<=i<Q (quantity)

•••••••••••••••••••••••••••••••••••• ••••••• 16-bit • 16-bit • • • • • Q-code 11; I-size MUST be 2• LSB | MSB • LSB | MSB • O1 • O2 • .... • ON • Octets 1 to N are the object identifier• Q • Size N • • • • ••••••••••••••••••••••••••••••••••••• ••••••

As for the previous case, there could be many identifiers each one following the other.

•••••••••••••••••••••••••••••••••••••••••••••••• ••••••• 32-bit • 32-bit • • • • • Q-code 11; I-size MUST be 3• LSB | | | MSB • LSB | | | MSB • O1 • O2 • .... • ON • Octets 1 to N are the object identifier• Q • Size N • • • • ••••••••••••••••••••••••••••••••••••••••••••••••• ••••••


Figure 3-15 Messages Without Data Objects

DNP Users Group3-24

The following figure defines all the valid qualifier/range/index combinations for a requestor response which contain IO or data objects and specifies that the objects in questioneither follow the qualifier/range fields (for qualifier without pre-fixing indices) or followeach individual identifying index. The bytes described appear after the qualifier octet ofthe object header and before the next object header or end of message.

Request/response with known points specified with a Range of indices.

Use Q-code 0-5 for describing points related in sequence:

•••••••••••••••••••••••••••••••••••••••• ••••••••• Start • Stop • DO • DO • DO • • DO • Q-code 0 and 3; I-size MUST be 0• 8 bit • 8 bit • • • • • • Points/Objects are I1 .. I2 inclusive• • • I1 • I1+1 • I1+2 •.... • I2 •• I1 • I2 • • • • • ••••••••••••••••••••••••••••••••••••••••• ••••••••

LSB MSB LSB MSB•••••••••••••••••••••••••••••••••••••••••••••••• •••••••• 16 bit Start • 16 bit Stop • DO • • DO • Q-code 1 and 4; I-size MUST be 0• | • | • • • • Points/Objects are I1 .. I2 inclusive• • • I1 •....• I2 •• I1 • I2 • • • •• • • • • ••••••••••••••••••••••••••••••••••••••••••••••••• •••••••

LSB MSB LSB MSB•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••• 32 bit Start • 32 bit Stop • DO • • DO •• | | | • | | | • • • •• • • I1 •....• I2 •• I1 • I2 • • • •• • • • • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••

Q-code 2 and 5; I-size MUST be 0Points/Objects are I1 .. I2 inclusive

••••••••••••••••••••••••••••••••••••• ••••••••••••••••• Start • Stop • Object •DO-I1 • • Object •DO-I2• Q-code 0 and 3; I-size MUST be 4• 8 bit • 8 bit • Size • with • • Size • with• Points/Objects are I1 .. I2 inclusive• • • 8-bit • size •..... • 8-bit • size•• I1 • I2 • S1 • S1 • • S2 • S2 •••••••••••••••••••••••••••••••••••••• ••••••••••••••••

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

LSB MSB LSB MSB•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• ••••••••••••••••••••• 16 bit Start • 16 bit Stop • Object •DO-I1 • • Object •DO-I2 •• | • | • Size • with • • Size • with •• • • 16-bit • size • •.16-bit • size •• I1 • I2 • S1 • S1 •....• S2 • S2 •• • • LSB | MSB • • • LSB | MSB • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• ••••••••••••••••••••



LSB MSB LSB MSB••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • • • ••••••••••••••••••••••••• • • • • • • •• 32 bit Start • 32 bit Stop • Object • DO-I1• • Object •DO-I2 •• | | | • | | | • Size • with • • Size • with •• • • 32-bit • size • • 32-bit • size •• I1 • I2 • S1 • S1 •...• S2 • S2 •• • • LSB | | | MSB • • • LSB | | | MSB • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• ••••••••••••••••••••••••



Important Note !!!

Do NOT use Q-code 6 for describing a message which contains data objects as the exact number of pointsare not known and therefore the contents of the message cannot be determined.


Use Q-code 7-9 for describing a number of unrelated points:

••••••••••••••••• ••••••••••••Quantity • DO • • DO • Q-code 7; I-size MUST be 0• 8 bit • • • • Points/Objects are 0 .. Q-1 inclusive• • I0 •.... • I(Q-1) •• Q • • • •• • • • •••••••••••••••••• •••••••••••

•••••••••••••••••••••••••• ••••••••••••••••••Quantity • Index • DO • • Index • DO • Q-code 7; I-size MUST be 1• 8 bit • • • • • • Points/Objects are I1, I2 .. IQ inclusive• • I1 • I1 • ..• IQ • IQ •• Q • • • • • •• • LSB • • • LSB • ••••••••••••••••••••••••••• •••••••••••••••••

•••••••••••••••••••••••••••••••• ••••••••••••••••••••••Quantity • Index • DO • • Index • DO • Q-code 7; I-size MUST be 2• 8 bit • • • • • • Points/Objects are I1, I2 .. IQinclusive• • I1 • I1 •....• IQ • IQ •• Q • • • • • •• • LSB | MSB • • • LSB | MSB • ••••••••••••••••••••••••••••••••• •••••••••••••••••••••

•••••••••••••••••••••••••••••••••••••• •••••••••••••••••••••••••••Quantity • Index • DO • • Index • DO • Q-code 7; I-size MUST be3• • • • • • • Points/Objects are• 8 bit • • • • • • I1, I2 .. IQ inclusive• • I1 • I1 • .....• IQ • I1 •• • • • • • •• Q • • • • • •• • LSB | | | MSB • • • LSB | | | MSB • ••••••••••••••••••••••••••••••••••••••• ••••••••••••••••••••••••••

LSB MSB•••••••••••••••••••••••••• ••••••••• 16 bit Quantity • DO • • DO • Q-code 8; I-size MUST be 0• Q • •... • • Points/Objects are 0 .. Q-1 inclusive• | • I0 • •I(Q-1)••••••••••••••••••••••••••• ••••••••

LSB MSB••••••••••••••••••••••••••••••••••• •••••••••••••••• 16 bit Quantity • Index • DO • • Index • DO • Q-code 8; I-size MUST be 1• | • LSB • • • LSB • • Points/Objects are I1,I2 .. IQ inclusive• • • I1 • • •IQ •• Q • I1 • • • IQ • •••••••••••••••••••••••••••••••••••• •••••••••••••••

LSB MSB•••••••••••••••••••••••••••••••••••••• •••••••••••••••••••• 16 bit Quantity • Index • DO • • Index • DO • Q-code 8; I-size MUST be 2• | • LSB | MSB• •......• LSB | MSB• • Points/Objects are I1,I2 .. IQinclusive• | • • I1 • • • IQ •• Q • I1 • • • IQ • ••••••••••••••••••••••••••••••••••••••• •••••••••••••••••••

LSB MSB•••••••••••••••••••••••••••••••••••••••••••• •••••••••••••••••••••••••• 16 bit Quantity • Index • DO • • Index • DO • Q-code 8; I-size MUST be3• | • LSB | | | MSB• •.....• LSB | | | MSB• • Points/Objects are I1,I2.. IQ• • • I1 • • • IQ • inclusive• Q • I1 • • • IQ • ••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••••••••••••••

LSB MSB•••••••••••••••••••••••••••••••••••••••••••••• ••••••• 32 bit Quantity • DO • • DO • Q-code 9; I-size MUST be 0• | | | • •.... • • Points are I1, I2 .. IQ inclusive• IQ • I1 • • IQ ••••••••••••••••••••••••••••••••••••••••••••••• ••••••

LSB MSB••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••••• 32 bit Quantity • Index • DO • • Index • DO • Q-code 9; I-size MUST be1• | | | • LSB • •....• LSB • • Points are I1, I2 .. IQ• Q • I1 • I1 • • I2 • I2 •

DNP Users Group3-26

••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••••

LSB MSB••••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••• 32 bit Quantity • Index • DO • • Index • Q-code 9; I-size MUST be2• | | | • LSB | MSB • •...• LSB | MSB • Points are I1, I2 .. IQ• Q • I1 • I1 • • I2 •••••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••

LSB MSB•••••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••••••••• 32 bit Quantity • Index • • Index • Q-code 9; I-sizeMUST be 3• | | | • LSB | | | MSB •....• LSB | | | MSB • Points are I1, I2.. IQ• Q • I1 • • I2 ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• •••••••••••••••••••

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

•••••••••••••••••••••••••••••• •••••••••••• •••••••••••••• •••••••••••• 8-bit • 8-bit • • • • • DO • • 8-bit • • • • DO •• • • O11 • O11• .... • O1N• •...• • OQ1•...• OQN• •• Q •Size N1• • • • • ID1 • •Size NQ• • • • IDQ••••••••••••••••••••••••••••••• •••••••••••• •••••••••••••• •••••••••••

Q-code 11; Index size MUST be 1

Octets Oi1 .. OiN form the object identifier for Object i where 0<=i<Q (quantity) which is followed bythe object identified. The size of the object is contained in the Object Identifier so the ApplicationLayer must be able to interpret some fields of the Object Identifier in order to process a message.

•••••••••••••••••••••••••••••••••••• ••••••••••••• 16-bit • 16-bit • • • • • DO • Q-code 11; I-size MUST be 2• LSB | MSB • LSB | MSB • O1 • O2 • .... • ON • • Octets 1 to N are the object identifier• Q • Size N • • • • • ID1 ••••••••••••••••••••••••••••••••••••• ••••••••••••


•••••••••••••••••••••••••••••••••••••••••••••••• ••••••••••••• 32-bit • 32-bit • • • • • DO • Q-code 11; I-size MUST be 3• LSB | | | MSB • LSB | | | MSB • O1 • O2 • .... • ON • • Octets 1 to N are the object• Q • Size N • • • • • ID1 • identifier• • • • • • • ••••••••••••••••••••••••••••••••••••••••••••••••• ••••••••••••


Figure 3-16 Messages With Data Objects


4. DETAILED FUNCTION CODEDESCRIPTIONS

This section describes the application layer function codes with examples. Theapplication headers containing the application control, function code and internalindication have been omitted from most of the examples but are always present in reality.The requests and responses are assumed to consist of one fragment each. An example of amultiple fragment message is illustrated in the description of function code 0.

4.1 CONFIRM (FUNCTION CODE 0)

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

The confirmation response for a single fragment message is illustrated in Figure 4-1.

•••••••••••••••••••••••••••••••••••••••••••• Application Control • Function •• FIR = 1, FIN = 1, CON = ? • Code = 0 •• • ••••••••••••••••••••••••••••••••••••••••••••

Figure 4-1 Confirmation Message

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Request Header • Read request that will result in •• FIR = 1, FIN = 1, • a multiple fragment response •• CON = 0 • •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read request, CON = 0 indicates no application confirmation expected for request.

DNP Users Group4-2

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Response Header • ASDU of first fragment of the response •• FIR = 1, FIN = 0 • •• CON = 1 • •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• First fragment of response. CON = 1 indicates the Outstation is expecting anapplication confirmation of the reception of this fragment.

•••••••••••••••••••••••••••••••••••••••••••• Request Header • Function •• FIR = 1, FIN = 1, CON = 0 • Code = 0 •• • ••••••••••••••••••••••••••••••••••••••••••••

• Confirmation sent by the requesting station

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Response Header • ASDU of second fragment •• FIR = 0, FIN = 0 • of response •• CON = 1 • •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• The second fragment of the response

•••••••••••••••••••••••••••••••••••••••••• Request Header • Function •• FIR = 1, FIN = 1, CON = 0 • Code = 0 •• • ••••••••••••••••••••••••••••••••••••••••••

• Confirmation of the second fragment

•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Response Header • ASDU of last fragment of the response •• FIR = 0, FIN = 1 • •• CON = 1 • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• The last fragment of the response

•••••••••••••••••••••••••••••••••••••••••••• Request Header • Function •• FIR = 1, FIN = 1, CON = 0 • Code = 0 •• • ••••••••••••••••••••••••••••••••••••••••••••

• Confirmation of the last fragment of the response

4.2 READ (FUNCTION CODE 1)

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


The number of multiple requests allowed in a single message is defined in the deviceprofile of each device DNP is implemented on.

The read request for a single range of objects is illustrated in Figure 4-2. Figure 4-3illustrates the request for 2 object types or possibly 2 ranges of the same object type.

••••••••••••••••••••••••••••••••••••••••••••••••••• Request Header • Object • Qualifier • Range •• AC • FC = 1 • • • •• • • • • •••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-2 Single Object Request

• first Read request • second Read request ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Request Header • Object • Qualifier • Range • Object • Qualifier • Range •• AC | FC = 1 • • • • • • •• • • • • • • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-3 Multiple Objects or Ranges

4.2.1 Read Requests

The following examples illustrate some legal qualifier and range combinations for theread function code.

octet 1 2 3 4 5••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier •• AC • FC = 1 • g = n v = 0 • 0000 0110 •• • • | • 0 6 •••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n.• The qualifier code specifies all the defined objects of the group defined at the

Outstation. This qualifier code also indicates the range field is not present.• The index size has no meaning and is set to 0.• The Outstation may respond with any or all objects of the defined group. This method

is useful for requesting event data because the requesting station does not know inadvance which points have generated events.

octet 1 2 3 4 5 6 7••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range •• AC • FC = 1 • g = n v = x • 0000 | 0000 • Start Stop •• • • | • 0 0 • 7 | 9 •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n variation x.• The qualifier code specifies a range field with a 1 octet start and stop sub-field.• The range field specifies 3 objects starting at index 7 to index 9 inclusive.• The index size has no meaning and is set to 0.

DNP Users Group4-4

• The Outstation may respond within the range specified. This method is useful forrequesting specific data that is known to be valid at the time of the request.

octet 1 2 3 4 5 6 7 8 9••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • object gv • Qualifier • Range • •• AC • FC = 1 • g = n v = x • 0000 0001 • Start • Stop •• • • | • 0 1 • 700 • 702 •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n, variation x.• The qualifier code specifies a range field with a 2 octet start and stop sub-field.• The range field specifies 3 objects starting at index 700 to index 702 inclusive.• The index size has no meaning and is set to 0.• The Outstation may respond within the range specified. This method is useful for

requesting specific data that is known to be valid at the time of the request.

octet 1 2 3 4 5 6 7 8 9 10 11 12 13••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • • • •• • • Object gv • Qualifier • | | | Range | | | •• AC • FC = 1 • g = n v = x • 0000 0010 • Start • Stop •• • • | • 0 2 • 70000 • 70002 •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n, variation x.• The qualifier code specifies a range field with a 4 octet start and stop sub-field.• The range field specifies 3 objects starting at index 70000 to index 70002 inclusive.• The Index Size field has no meaning and is set to 0.• The Outstation may respond within the range specified. This method is useful for

requesting specific data that is known to be valid at the time of the request.

octet 1 2 3 4 5 6 7••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range •• AC • FC = 1 • g = n v = x • 0000 0011 • Start • Stop •• • • | • 0 3 • 7 • 9 •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n, variation x. In this case n and x would specify a generic octetobject

• The qualifier code specifies a range field with a 1 octet start and stop sub-field.• The range field specifies a starting virtual address of 7 and a virtual ending address of

9.• The Index Size field has no meaning and is set to 0.• The Outstation may respond within the range specified. This method is useful for

requesting specific bytes from the memory of some remote application.

NOTE: Virtual addressing is normally used only for diagnostic or manufacturingtests as intimate knowledge of the Outstation is needed to interpret theresponse.


octet 1 2 3 4 5 6 7 8 9••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • | Range | •• AC • FC = 1 • g = n v = x • 0000 0100 • Start • Stop •• • • | • 0 4 • 700 • 702 •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n, variation x. In this case n and x would specify a generic octetobject.

• The qualifier code specifies a range field with a 2 octet start and stop sub-field.• The range field specifies a starting virtual address of 700 and a virtual ending address

of 702.• The Index Size field has no meaning and is set to 0.• The Outstation may respond within the range specified. This method is useful for



octet 1 2 3 4 5 6 7 8 9 10 11 12 13•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • | | | Range | | | •• AC • FC = 1 • g = n v = x • 0000 0101 • Start • Stop •• • • | • 0 5 • 70000 • 70002 ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n, variation x. In this case n and x would specify a generic octetobject.

• The qualifier code specifies a range field with a 4 octet start and stop sub-field.• The range field specifies a starting virtual address of 70000 and a virtual ending

address of 70002.• The index size has no meaning and is set to 0.• The Outstation may respond within the range specified. This method is useful for



octet 1 2 3 4 5 6••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range •• AC • FC = 1 • g = n v = p • 0000 0111 • Quantity •• • • | • 0 7 • 3 •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n variation p.• The qualifier code specifies a 1 octet quantity.• The range field specifies 3 objects.• The index size has no meaning and is set to 0.

DNP Users Group4-6

• This method is useful for requesting a limited amount of data of a particular variation(e.g. analog change events) as the receiving station may not be able to handle the entiredata base of the Outstation.

octet 1 2 3 4 5 6 7•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range •• AC • FC = 1 • g = n v = p • 0000 1000 • Quantity •• • • | • 0 8 • 400 ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n variation p.• The qualifier code specifies a 2 octet quantity.• The range field specifies 400 objects.• The index size has no meaning and is set to 0.• This method is useful for requesting a limited amount of data of a particular variation

(e.g. binary input with time objects) as the receiving station may not be able to handlethe entire data base (i.e. analog) of the Outstation.

octet 1 2 3 4 5 6 7 8 9•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range •• AC • FC = 1 • g = n v = p • 0000 1001 • Quantity •• • • | • 0 9 • | 70000 | ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n variation p.• The qualifier code specifies a 4 octet quantity.• The range field specifies 70000 objects.• The index size has no meaning and is set to 0.• This method is useful for requesting a limited amount of data of a particular variation

as the receiving station may not be able to handle the entire data base (i.e. analog) ofthe Outstation.

octet 1 2 3 4 5 6 7 8 9••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range • Indices •• AC • FC = 1 • g = n v = x • 0001 0111 • Quantity • 11 • 22 • 108 •• • • • 1 7 • 3 • • • •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n, variation x.• The qualifier code specifies a list of objects in the index field.• The range field specifies that the list contains 3 entries.• The index size specifies each entry in the list is a 1 octet index.• This method is useful for requesting some specific points from the remote device. For

example, some critical status points may be requested for analysis or reportingpurposes.


NOTE: The range field is always the same size as an entry in the index list. Thisformat would normally be used when the indices have values between 0and 255.

octet 1 2 3 4 5 6 7 8 9 10 11 12 13•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range • Indices •• AC • FC = 1 • g = n v = x • 0010 0111 • Quantity • 311 • 422 • 108 •• • • | • 2 7 • 3 • | • | • | ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n, variation x.• The qualifier code specifies a list of objects in the index field.• The range field specifies the list contains 3 entries.• The index size specifies each entry in the list is a 2 octet index.• This method is useful for requesting some specific points from the remote device. For


NOTE: The range field is always the same size as an entry in the index list. Thisformat would normally be used when some or all of the indices havevalues greater than what will fit in 1 octet.

octet 1 2 3 4 5 6 7 8 9 18 19 20 21•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range • Indices •• AC • FC = 1 • g = n v = x • 0011 0111 • Quantity • • • •• • • | • 3 7 • 3 • 70000 • 76000 • 90000 ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• Read object group n, variation x.• The qualifier code specifies a list of objects in the index field.• The range field specifies the list contains 3 entries.• The index size specifies each entry in the list is a 4 octet index.• This method is useful for requesting some specific points from the remote device. For


NOTE: The range field is always the same size as an entry in the index list.

octet 1 2 3 4 5 6 7 .....••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range • Identifier •• AC • FC = 1 • g = n v = v • 0001 1011 • Quantity • •• • • | • 1 11 • 1 • Size | Object Identifier ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • Size octets •

• Read object group n variation v (in this case the group and variation identify theobject identifier).

DNP Users Group4-8

• The qualifier code specifies a list of object identifiers in the identifier field and therange field is an 8 bit quantity. The size field is also an 8-bit quantity specifying thatthe object identifier is 'size' octets in length.

• The range field specifies the list contains 1 entry. The index size specifies that thequantity field and Size field are 8-bit in length.

• This method is useful for reading configurations from a remote device (if the FileObject Identifier is used). This method is however the only way in which to request adata object that is larger than one fragment in size.

4.2.2 Read Responses

This section defines some of the legal forms of an object header prefixing the objects in aresponse to a read request.

octet 1 2 3 4 5••••••••••••••••••••••••••••••••••••••••••••••••••• ....• Object gv • Qualifier • Range •• group = n • 0000 0000 • Start • Stop •• variation = v • 0 0 • 7 • 9 •••••••••••••••••••••••••••••••••••••••••••••••••••• .....

• Objects following this header are group n, variation v.• The qualifier code specifies a range field with a 1 octet start and stop sub-fields.• The range field specifies 3 objects starting at index 7 to index 9 inclusive follow this

header• The index size has no meaning and is set to 0 as the start and stop field identify the

index of each object.

octet 1 2 3 4 5 6 7•••••••••••••••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0000 0001 • Start • Stop •• variation = v • 0 1 • 300 • 302 ••••••••••••••••••••••••••••••••••••••••••••••••••••••....

• Objects following this header are group n, variation v.• The qualifier code specifies a range field with 2 octet start and stop sub-fields.• The range field specifies 3 objects starting at index 300 to index 302 inclusive follow

this header.• The index size has no meaning and is set to 0 as the start and stop field identify the


octet 1 2 3 4 5 6 7 8 9 10 11•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0000 0010 • Start • Stop •• variation = v • 0 2 • 70000 • 70002 ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••....

• Objects following this header are group n, variation v.• The qualifier code specifies a range field with 4 octet start and stop sub-fields.


• The range field specifies 3 objects starting at index 70000 to index 70002 inclusivefollow this header.

• The index size has no meaning and is set to 0 as the start and stop field identify theindex of each object.

octet 1 2 3 4 5••••••••••••••••••••••••••••••••••••••••••••••••••• .....• Object gv • Qualifier • Range •• group = n • 0000 0011 • Start • Stop •• variation = v • 0 3 • 7 • 9 •••••••••••••••••••••••••••••••••••••••••••••••••••• .....

• Objects following this header are group n, variation v.• The qualifier code specifies a range field with a 1 octet start and stop sub-fields.• The range field specifies the contents of virtual addresses 7 to 9 inclusive following

this header.• The index size has no meaning and is set to 0 as the start and stop field identify the


octet 1 2 3 4 5 6 7•••••••••••••••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0000 0100 • Start • Stop •• variation = v • 0 4 • 300 • 302 ••••••••••••••••••••••••••••••••••••••••••••••••••••••....

• Objects following this header are group n, variation v.• The qualifier code specifies a range field with 2 octet start and stop sub-fields.• The range field specifies the contents of virtual addresses 300 to 302 inclusive

following this header.• The index size has no meaning and is set to 0 as the start and stop field identify the


octet 1 2 3 4 5 6 7 8 9 10 11•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0000 0101 • Start • Stop •• variation = v • 0 5 • 70000 • 70002 ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••....

• Objects following this header are group n, variation v.• The qualifier code specifies a range field with 4 octet start and stop sub-fields.• The range field specifies the contents of virtual addresses 70000 to 70002 inclusive

following this header.• The index size has no meaning and is set to 0 as the start and stop field identify the


DNP Users Group4-10

octet 1 2 3 4••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0000 0111 • 3 •• variation = v • 0 7 • •••••••••••••••••••••••••••••••••••••••••....

• Objects following this header are group n, variation v.• The qualifier code specifies a range field with a 1 octet quantity.• The range field specifies 3 objects.• The index size specifies the objects are packed with no indices prefixing them. This

implies the first object in the message has an index of 0 and the last object in thisexample will have an index of 2.


• Objects following this header are group n, variation v.• The qualifier code specifies a range field with a 1 octet quantity.• The range field specifies 3 objects.• The index size specifies the objects are prefixed with 1 octet index identifiers.






octet 1 2 3 4•••••••••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0100 0111 • Quantity •• variation = v • 4 7 • 1 ••••••••••••••••••••••••••••••••••••••••••••••••....

• Objects following this header are group n, variation v.• The qualifier code specifies the range field is an 8 bit quantity.• The range field specifies the number of the objects in the data field.• The index size specifies the objects are prefixed with 1 octet object sizes.• Note that since the object indices are not specified (and the response and request do

not have to match), the data object itself must contain some unique identification (suchas a time-stamp).

octet 1 2 3 4 5••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0000 1000 • 3 •• variation = v • 0 8 • •••••••••••••••••••••••••••••••••••••••••....



• Note that since the object indices are not specified (and the response and request donot have to match), the data object itself must contain some unique identification (suchas a time-stamp).


• Objects following this header are group n, variation v.• The qualifier code specifies a range field with a 2 octet quantity.• The range field specifies 3 objects.• The index size specifies the objects are prefixed with a 1 octet index identifier.


• Objects following this header are group n, variation v.• The qualifier code specifies a range field with a 2 octet quantity.• The range field specifies 300 objects.

DNP Users Group4-12

• The index size specifies the objects are prefixed with a 2 octet index identifier.


• Objects following this header are group n, variation v.• The qualifier code specifies a range field with a 2 octet quantity.• The range field specifies 300 objects.• The index size specifies the objects are prefixed with a 4 octet index identifier.

octet 1 2 3 4 5•••••••••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0101 1000 • Quantity •• variation = v • 5 8 • ••••••••••••••••••••••••••••••••••••••••••••••••....

• Objects following this header are group n, variation v.• The qualifier code specifies the range field is a 16 bit quantity.• The range field specifies the number of objects in the data field.• The index size specifies the objects are prefixed with 2 octet object sizes.• Note that since the object indices are not specified (and the response and request do


octet 1 2 3 4 5 6 7••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0000 1001 • 3 •• variation = v • 0 9 • •••••••••••••••••••••••••••••••••••••••••....




• Objects following this header are group n, variation v.• The qualifier code specifies a range field with a 4 octet quantity.• The range field specifies 3 objects.


• The index size specifies the objects are prefixed with a 1 octet index identifier.





octet 1 2 3 4 5 6 7•••••••••••••••••••••••••••••••••••••••••••••••....• Object gv • Qualifier • Range •• group = n • 0100 1001 • Quantity •• variation = v • 4 9 • ••••••••••••••••••••••••••••••••••••••••••••••••....

• Objects following this header are group n, variation v.• The qualifier code specifies the range field is a 32 bit quantity.• The range field specifies the number of the objects in the data field.• The index size specifies the objects are prefixed with 1 octet object sizes.• Note that since the object indices are not specified (and the response and request do


DNP Users Group4-14

The read response can also consist of a multi-fragment message with each objectidentifier specifying different portions (pages) of the entire object:

Fragment #1: FC=129, CON=? FIR=1 FIN=0

octet 1 2 3 4 5 6 7 .....•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Object gv • Qualifier • Range • Identifier • Data •• g = n v = v • 0001 1011 • Quantity • • for •• | • 1 11 • 1 • Size • Object Identifier for piece 1• piece 1 •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Size octets





• Read object group n variation v (in this case the group and variation identify the objectidentifier).

• The qualifier code specifies a list of object identifiers in the identifier field and therange field is an 8 bit quantity. The size field is also an 8-bit quantity specifying thatthe object identifier plus data following the identifier is 'size' octets in length.

• The range field specifies the list contains 1 entry. The index size specifies that thequantity field and Size field are 8-bit in length.

• This method is useful for reading configurations from a remote device (if the FileIdentifier Object is used). This method is however the only way in which to request adata object that is larger than one fragment in size.

• Note that each fragment is digestible by the requesting station because each objectidentifier specifies a unique portion of the object.

4.3 WRITE (FUNCTION CODE 2)

The write function code is used for moving objects from a master station to an Outstation.Figure 4-4 illustrates the general format of a message writing single object type or range.Figure 4-5 illustrates the writing of multiple objects or ranges. The object header isdefined the same as in a read request. Figure 4-6 is an example of the writing of aconfiguration to an Outstation. The response from the Outstation is always a functioncode followed by the IIN. Typical uses of the Write function are to downloadconfiguration or files to an Outstation and to set the time in the Outstation.


••••••••••••••••••••••••••••••••• ...........• • • Object Header •• AC • FC = 2 • • Object(s) and prefixing indices or identifiers• • • •••••••••••••••••••••••••••••••••• ...........

Figure 4-4 Single Object Range Write

•••••••••••••••••••••••••••••••••...........••••••••••••••••• ........• • • Object Header • • Object Header •• AC • FC = 2 • • Object(s) • • Objects(s)• • • • • ••••••••••••••••••••••••••••••••••......... •••••••••••••••••.........

Figure 4-5 Multiple Object or Multiple Ranges

4.3.1 Write Requests

The Write request transfers a multi-fragment object to a remote device. The WriteRequest is typically used for writing objects such as the Internal Indication Object, FileIdentifier Objects and the Time and Date Object.

Each fragment contains identifying information for each portion of the entire object.

octet 1 2 3 4 5 6 7 .....•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• AC • • Object gv • Qualifier • Range • Identifier • Data •• FIN=0• FC = 2 • g = n v = v • 0001 1011 • Quantity • • for •• FIR=1• • | • 1 11 • 1 • Size • Object Identifier for piece 1• piece 1 •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Size octets



• Write object group n variation v (in this case the group and variation identify theobject identifier).

• The qualifier code specifies a list of object identifiers in the identifier field and therange field is an 8 bit quantity. The size field is also an 8-bit quantity specifying thatthe object identifier plus data is 'size' octets in length

• The range field specifies the list contains 1 entry.• The Data field contains the data (of size specified in the identifier) belonging to the

identified object.• This method is useful for downloading configurations to a remote device (if the File

Object Identifier is used) as the contents of the Data filed is not interpreted by the

DNP Users Group4-16

application layer. This method is however the only way in which to send a data objectthat is larger than one fragment in size.

The Write request below sets the time of day in the Outstation.

octet 1 2 3 4 5 6 7 .....•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• AC • • Object gv • Qualifier • Range • Time Object •• FIN=1• FC = 2 • g = n v = v • 0000 0000 • Quantity • •• FIR=1• • | • 0 00 • 1 • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• The qualifier specifies a 1 octet quantity; the quantity field specifies 1 object and theObject field identifies the object as a Time and Date Object.

4.3.2 Write Responses

The response to a Write request can only consist of the IIN (Internal Indications) thatindicates the success of the Write operation and so there is no ASDU portion of a Writeresponse. The response always uses the Response function code.

4.4 SELECT (FUNCTION CODE 3)

The select function code is used to select one or more control points at an Outstation.These may be control relay outputs, analog outputs or pattern control blocks. Thisfunction does not output or activate the new state or value but makes them ready (armsthem) and reports their status. An additional operate message must be sent to theOutstation to actually activate the request. The operate message control objects mustmatch the control objects in the preceding select message before the activation takesplace. The select message causes the Outstation to starts a timer. The operate messagemust be received correctly before the timer expires in order for the activation to takeplace.

There are two forms to the control messages. The first form is for control blocks with afixed size and the second form is for a control block of variable size. The variable sizedcontrol block is for pattern outputs.

Figure 4-6 illustrates a select message (fixed size control blocks) sent from a masterstation to an Outstation.

The Outstation responds to a select message by arming the specified points (specified bythe index preceding the control blocks) and returning the request in the response asillustrated in Figure 4-7 (fixed size control blocks). The response is identical to therequest except that it includes the IIN and modified status bytes (part of the control blockobjects). The status bytes state the success or failure of the Select request.


•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range • • control • • control •• AC • FC = 3 • group = n • 0001 0111 • Quantity • index • block • index • block •• • • variation = v • 1 7 • 2 • • object 1• • object 2••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-6 Master Selection of Two Control or Analog Outputs

• Object following this header is group n (must be a control block object relating tooutputs or setpoints), variation v.

• The qualifier code specifies a range field with a 1 octet quantity of control blocks.• The index size specifies 1 octet indices prefixing each control block.

•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • • Object gv • Qualifier • Range • • control • • control •• AC • FC • IIN • group = n • 0001 0111 • Quantity • index • block • index • block •• • • • variation = v • 1 7 • • • object 1• • object 2••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-7 Outstation Response

The Outstation response control objects must match the control objects (byte for byte) inthe request or the operate message will not be sent.

4.4.1 Pattern Control

Figure 4-8 illustrates a master station select message for a pattern andFigure 4-9 an Outstation response.

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier •Quantity• pattern •• AC • FC = 3 • group = a • 0000 0111 • • control •• • • variation = b • 0 7 • 1 • block •... (continued)••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Object gv • Qualifier • Range •pattern •pattern •pattern •pattern •• group = c •0000 0000 • Start | Stop • mask • mask • mask • mask •• variation = d • 0 0 • 5 8 •object 5•object 6•object 7•object 8••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-8 Master Selection of a Pattern Output

• The first object, Object a, Variation b, specified is a Pattern Control Block whichdescribes all the parameters that are common to the control points specified in thePattern Mask Objects. Following this object are a number of Pattern Mask objects,Object c, Variation d, which describe whether or not the point should be activated.

• The first qualifier code specifies a 8-bit range (quantity) field which specifies one (1)Pattern Control Block.

• The second qualifier code specifies a range field with a 1 octet start and stop sub-field.This range specifies the Pattern Mask Objects which are to be considered for thepattern control.

DNP Users Group4-18

• The above message constitutes one pattern control request. Multiple requests (PatternControl Block followed by multiple Pattern Mask Objects) can be sent in one messageas long as the total size of the requests can fit into one application layer fragment.

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier •Quantity• pattern •• AC • FC=128 • group = a • 0000 0111 • • control •• • • variation = b • 0 7 • 1 • block •... (continued)••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Object gv • Qualifier • Range •pattern •pattern •pattern •pattern •• group = c •0000 0000 • Start | Stop • mask • mask • mask • mask •• variation = d • 0 0 • 5 8 •object 5•object 6•object 7•object 8••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-9 Outstation Response to the Pattern Select Message

• Notice that the format of the response is identical to the request message (except theapplication response header). The objects returned will be used by the master to verifythe success of the select operation.

4.5 OPERATE (FUNCTION CODE 4)

The operate function code is used to activate one or more control or analog outputs at anOutstation. A matching message using the select function code must previously havebeen received, and the arm timer must still be active before the activation will take place.The format of this message is the same as a select message except the function code is 4.

•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range • control • control •• AC • FC = 4 • group = n • 0000 0111 • Quantity • block 1 • block 2 •• • • variation = v • 0 7 • 2 • • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-10 Master Selection of Two Outputs or Setpoints


• The qualifier code specifies a range field with a 1 octet quantity of control blocks.

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • • Object gv • Qualifier • Range • control • control •• AC • FC • IIN • group = n • 0000 0111 • Quantity • block 1 • block 2 •• • • • variation = v • 0 7 • 2 • • •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••



• The qualifier code specifies a range field with a 1 octet quantity of control blocks.• Indication of the success or failure of the operations is returned in the Output Status

bytes, one of which is built into each of the control block objects. In the case of a


Pattern Mask object, the status is part of the Pattern Control Block object precedingthe mask.

4.6 DIRECT OPERATE (FUNCTION CODE 5)

The direct operate function code is used to activate one or more outputs or setpoints at anOutstation. A preceding select message is not required. The format of this message is thesame as a select or operate message except the function code is 5.





•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • • Object gv • Qualifier • Range • control • control •• AC • FC • IIN • group = n • 0000 0111 • Quantity • block 1 • block 2 •• • • • variation = v • 0 7 • 2 • • ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••




4.7 DIRECT OPERATE - NO ACKNOWLEDGEMENT (FUNCTIONCODE 6)

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





DNP Users Group4-20

4.8 IMMEDIATE FREEZE (FUNCTION CODE 7)

This function code is used to copy the specified data objects to a freeze buffer. Uponreception of the message, the Outstation should copy the current values of the specifieddata objects to their appropriate freeze buffers. The objects which were frozen can berequested (in another request) by asking for frozen objects.

••••••••••••••••••••••••••••••• •••••••••••••••••• • • Object Header • • Object Header •• AC • FC = 7 • •...• •• • • • • •••••••••••••••••••••••••••••••• •••••••••••••••••

Figure 4-15 Master Immediate Freeze Control Message

The request can contain multiple object headers which specify many objects to freeze.Typically, however, only counter objects are frozen.

••••••••••••••••••••••••• • • •• AC • FC • IIN •• • • •••••••••••••••••••••••••

Figure 4-16 Outstation Response to Immediate Freeze

The Outstation response can indicate (in the IIN) that the objects in the request are notknown.

4.9 IMMEDIATE FREEZE - NO ACKNOWLEDGEMENT(FUNCTION CODE 8)

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


Figure 4-17 Master Immediate Freeze No-Ack Control Message

4.10 FREEZE AND CLEAR (FUNCTION CODE 9)

This function code is used to copy the specified data to a freeze buffer like the freezeimmediate function code but then the Outstation clears ( to 0 ) the specified data objects.


Typically, this function code is used to freeze counters or accumulators and then resetthem to 0.


Figure 4-18 Master Freeze and Clear Control Message

••••••••••••••••••••••••• • • •• AC • FC • IIN •• • • •••••••••••••••••••••••••

Figure 4-19 Outstation Response to Freeze and Clear Request

4.11 FREEZE AND CLEAR - NO ACKNOWLEDGEMENT(FUNCTION CODE 10)

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

••••••••••••••••••••••••••••••• •••••••••••••••••• • • Object Header • • Object Header •• AC • FC= 10 • •...• •• • • • • •••••••••••••••••••••••••••••••• •••••••••••••••••

Figure 4-20 Master Freeze and Clear No-Ack Control Message

4.12 FREEZE WITH TIME (FUNCTION CODE 11)

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

TIME INTERVAL DESCRIPTIONnon zero zero Freeze once at specified time.zero zero Freeze Immediately.zero non zero Freezing is synchronized to the

beginning of the current hour. The firstfreeze will occur at the smallestmultiple greater than or equal to thecurrent time. Subsequent freezes willoccur at each interval increment.

non zero non zero Start freezing at the specified time andrepeat at each interval incrementthereafter

DNP Users Group4-22

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object Header • Time Object • Object Header(s) •• AC • FC = 11 • for time object • Time and Date • Interval • for data objects •• • • • • • to freeze •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-21 Master Freeze With Time Message

••••••••••••••••••••••••• • • •• AC • FC • IIN •• • • •••••••••••••••••••••••••

Figure 4-22 Outstation Response to Freeze With Time

The time object must contain the time and interval. These objects are defined in the DNPData Object Library (P009-0BL).

Example: A time object specifies the time of day as 2:32 pm and an interval of 10minutes. The first freeze will occur at 2:32 pm and subsequent freezes every 10 minutesstarting from 2:42 pm.

4.13 FREEZE WITH TIME - NO ACKNOWLEDGEMENT(FUNCTION CODE 12)

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

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object Header • Time Object • Object Header(s) •• AC • FC = 12 • for time object • Time and Date • Interval • for data objects •• • • • • • to freeze •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-23 Master Freeze With Time No-Ack Message

4.14 COLD RESTART (FUNCTION CODE 13)The cold restart functioncode makes the Outstation perform a complete restart of the user application , as if it hasbeen newly powered up.

•••••••••••••••• • •• AC • FC = 13•• • ••••••••••••••••


Figure 4-24 Master Cold Restart Control Message

••••••••••••••••••••••••••••••••••••••••••••••••••••• • • • Object • Time Delay •• AC • FC • IIN • Header • Object •• • • • for time • •••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-25 Outstation Response to Cold Restart Request

The Outstation, upon receiving the Cold Restart request will response with a Time DelayObject (Time Delay Fine or Time Delay Course) which specifies a time interval until theOutstation will be ready for further communications. The master should not attempt tocommunicate with the Outstation until the interval has elapsed. The interval allows theOutstation to perform a restart sequence and enable DNP communications again. Afterthe response is sent (and transaction was successful) the Outstation should perform therestart procedure. The Time Delay Fine object is defined in the DNP Data Object Library(P009-0BL).

4.15 WARM RESTART (FUNCTION CODE 14)

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

••••••••••••••••• • •• AC • FC = 14 •• • •••••••••••••••••

Figure 4-26 Master Warm Restart Control Message

•••••••••••••••••••••••••••••••••••••••••••••••••••• • • • Object • Time Delay •• AC • FC • IIN • Header • Object •• • • • for time • ••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-27 Outstation Response to Warm Restart Request

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

4.16 INITIALIZE DATA (FUNCTION CODE 15)

DNP Users Group4-24

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

•••••••••••••••••••••••••••••••••••• • • Object Header •• AC • FC = 15 • for data objects •• • • to initialize ••••••••••••••••••••••••••••••••••••

Figure 4-28 Master Initialize Data Control Message

••••••••••••••••••••••••• • • •• AC • FC • IIN •• • • •••••••••••••••••••••••••

Figure 4-29 Outstation Response to Initialize Data Request

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

4.17 INITIALIZE APPLICATION (FUNCTION CODE 16)

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

octet 1 2 3 4 5 6 7...••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range • Application •Application •• AC • FC = 16 • Group = n • 0001 1011 • Quantity • Identifier •Object •• • • Variation = v • 1 11 • 1 • Size •Identifier •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-30 Master Initialize Application Control Message

• The object group and variation must specify an application identifier object.• The qualifier indicates the range field is an 8 bit quantity specifying the number of

object identifiers that follow.• The application identifier size field indicates the size of the Application Object

Identifier that follows.

••••••••••••••••••••••••• • • •• AC • FC • IIN •• • • •••••••••••••••••••••••••

Figure 4-31 Outstation Response After Initializing Application(s)

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


4.18 START APPLICATION (FUNCTION CODE 17)

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


Figure 4-32 Master Start Application Control Message




•••••••••••••••••••••••••••••••••••••••••••••••••••• • • • Object • Time Delay •• AC • FC • IIN • Header • Object •• • • • for time • ••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-33 Outstation Response After Starting Application(s)

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

4.19 STOP APPLICATION (FUNCTION CODE 18)

This function code informs the Outstation to stop the execution of the specifiedapplication.


Figure 4-34 Master Stop Application Control Message




DNP Users Group4-26

••••••••••••••••••••••••• • • •• AC • FC • IIN •• • • •••••••••••••••••••••••••

Figure 4-35 Outstation Response After Stopping Application(s)

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

4.20 SAVE CONFIGURATION (FUNCTION CODE 19)

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

octet 1 2 3 4 5 6 7...•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • • Object gv • Qualifier • Range • File •File •• AC • FC = 19 • Group = n • 0001 1011 • Quantity • Identifier •Identifier •• • • Variation = v • 1 11 • 1 • Object Size •Object ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-36 Master Save Configuration Control Message

• The object group and variation must specify a configuration or file identifier object.• The qualifier indicates the range field is an 8 bit quantity specifying the number of

object identifiers that follow.• The configuration identifier size field indicates the size of the configuration Object


•••••••••••••••••••••••••••••••••••••••••••••••••• • • • Object • Time •• AC • FC • IIN • Header • Object •• • • • • ••••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-37 Outstation Response After Saving Configuration(s)

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

4.21 ENABLE SPONTANEOUS MESSAGES (FUNCTION CODE20)

This function code informs the Outstation to enable spontaneous reporting of the objectsspecified in the object header.


••••••••••••••••••••••••••••••••••• • • Object Header(s) •• AC • FC= 20 • •• • • •••••••••••••••••••••••••••••••••••

Figure 4-38 Master Request to Enable Spontaneous Messages

••••••••••••••••••••••••• • • •• AC • FC • IIN •• • • •••••••••••••••••••••••••


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

4.22 DISABLE SPONTANEOUS MESSAGES (FUNCTION CODE21)

This function code informs the Outstation to disable spontaneous reporting of the objectsspecified in the object header.

••••••••••••••••••••••••••••••••• • • Object Header •• AC • FC = 21 • •• • • •••••••••••••••••••••••••••••••••

Figure 4-40 Master Request to Disable Spontaneous Messages

••••••••••••••••••••••••• • • •• AC • FC • IIN •• • • •••••••••••••••••••••••••

Figure 4-41 Outstation Response to Disable Spontaneous Message

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

4.23 ASSIGN CLASSES (FUNCTION CODE 22)

This function is used to assign data objects to classes.

DNP Users Group4-28

•••••••••••••••••••••••••••••••••••••••••••••••..•••••••••••••••••• • • Class Object • Data Object • • Data Object •• AC • FC = 22 • Header • Header 1 • • Header n •• • • • • • ••••••••••••••••••••••••••••••••••••••••••••••••..•••••••••••••••••

Figure 4-42 Master Request to Assign Classes to Data

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

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

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

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

•••••••••••••••••• • • •• AC • FC • IIN •• • • ••••••••••••••••••

Figure 4-43 Outstation Response to Assign Classes

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

4.24 DELAY MEASUREMENT (FUNCTION CODE 23)

This function is used to calculate the communication delay for a particular Outstation. Itis generally used in the time synchronization process for the Outstations (see section 6.Time Synchronization for a detailed description of the process).

••••••••••••••••• • •• AC • FC = 23 •• • •••••••••••••••••

Figure 4-44 Master Request to Initiate Delay Measurement

• Only one time object can be sent in any one separate request.


•••••••••••••••••••••••••••••••••••••••••••••••• • • • Time Delay • Time Delay •• AC • FC • IIN • Fine Header • Fine object •• • • • • ••••••••••••••••••••••••••••••••••••••••••••••••

Figure 4-45 Outstation Reponse to Delay Measurement Request

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

DNP Users Group4-30


5. CLASSES

Objects may be assigned to a class. There are four Classes of data. Class 0 is reserved forstatic data objects (static data reflects the current value of data in the Outstation). Classes1, 2 and 3 are reserved for event data objects (objects created as the result of data changesin the Outstation or some other stimulant). Each event object can be assigned to Class 1,2 or 3. Objects may be grouped in Classes by priority (the priority is determined by theuser) and the data classes polled at varying rates.

The ability to assign data to Classes and the degree of configurability is described in theOutstation's device profile. It is not required that an Outstation have data assigned toClasses 1, 2 or 3.

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

DNP Users Group5-2


6. TIME SYNCHRONIZATION

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

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

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

2. The Outstation receives the first bit of the first byte of the Delay Measurement

request at time RtuReceiveTime (this is a local time in the Outstation). 3. The Outstation transmits the first bit of the first byte of the response to the Delay

Measurement request at time RtuSendTime. The response contains the Time Delayobject (Time Delay Fine or Time Delay Course), with the time in this object equal toRtuTurnAround, where

RtuTurnAround = RtuSendTime - RtuReceiveTime

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

time MasterReceiveTime. 5. The master station can now calculate the one way propagation delay as MasterSendTime - MasterReceiveTime - RtuTurnAround Delay = ---------------------------------------------------- 2

6. The master now transmits the first bit of the first byte of a Write request at time

MasterSend. The Write request contains the Time and Date object, with the time inthe object representing a time equal to (MasterSend + Delay). This is the time that theMaster station wants the Outstation to be set to.

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

RtuReceive.

DNP Users Group6-2

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

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

9. The Master and Outstation time are now synchronized.

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

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


7. BINARY INPUT WITH TIMEEVENTS

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

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

2) Outstation Time Synchronized, several event object to send. The Time and Date

Common Time of Occurrence object is transmitted followed by several Binary Inputwith Relative Time objects. The time in the Time and Date Common Time ofOccurrence object is the time of the oldest object. The relative times start at 0 (for theoldest object) and range upwards relative to the Date and Time object.

3) Outstation Time NOT Synchronized, one or more event object to send. The

Unsynchronized Common Time and Date object is transmitted followed by one ormore Binary Input with Relative Time objects. The time in the Time and DateCommon Time of Occurrence object is the time of the oldest object. The relative timesstart at 0 (for the oldest object) and range upwards relative to the Time and Dateobject.

DNP Users Group7-2


8. FILE TRANSFER

The File Identifier Object (FIO) may be used to transfer data files betweenOutstations and master stations. This is commonly used to write configurationsfrom a master to an Outstation or read configurations from an Outstation to amaster.

The functionality of the File Identifier Object allows configuration information tobe routed to Outstations via intermediate Data Concentrators. A dataconcentrator is located between a master station and an Outstation - it iseffectively an Outstation to the master station and a master station to theOutstation. Note that a Data Concentrator is not just a communication node - itdoes not directly route messages between a master station and an Outstation.

The File Identifier Object is always passed to an Outstation in a request using theWRITE function code. The action to be done (reading, writing or otherwise) isspecified by the File_Function field within the object. The response always usesthe RESPONSE function code. However, an outstation can send an unsolicitedmessage containing a FIO.

The File Identifier Object contains routing information in its File_Name field.This field describes how the object is to be routed from the master station, throughany number of intermediate Data Concentrators, to the Outstation.

The interpretation of the File_Name field is dependent on the Data Concentratorthrough which the object is being routed.

8.1 FILE IDENTIFIER OBJECTS PERFORMING WRITEFUNCTIONS

This section describes how a File Identifier Object is passed from a master stationthrough a Data Concentrator to an Outstation. The Outstation may be another DataConcentrator. Note that the request message is using the WRITE function code.The File_Function field in the object will be WRITE, APPEND, INSERT,DELETE or ERASE. The object may or may not contain data (no data forDELETE or ERASE).

DNP Users Group8-2

The following Nomenclature is used:• Outstation Application - This is the software application in the Data

Concentrator that communicates to the master station. It is an Outstation withrespect to the master station.

• Master Application - This is the software application in the Data Concentratorthat communicates to the Outstation. It is a master with respect to theOutstation.

The master station send the request (WRITE function code) with the FileIdentifier Object to the Outstation Application. For the request, the followingconditions must be satisfied;• DNP WRITE Function Code is used in the request.• File_Function field in the object is set to WRITE, APPEND, INSERT,

DELETE or ERASE.• File_Name field contains an ASCII character string. The length and contents of

the string is dependant on the Data Concentrator. The Harris implementationuses a string, the first 9 character of which are "/DNPDCAxx", where xx (2ASCII characters) contains the Master Application number to which this FileIdentifier Object must be routed. This information routes the object from theOutstation Application to the Master Application within the Data Concentrator,which will send it on to the Outstation.

If the above conditions are met, the following sequence occurs:1) Outstation Application sends a CONFIRMation response to the master

station (if the CON bit in the Request Header is set).2) Outstation Application removes the first 9 characters (for HARRIS

implementation) from the FILE_NAME field, modifying other FileIdentifier Object fields if necessary.

3) Outstation Application sends the File Identifier Object to the MasterApplication.

4) Master Application sends a request (WRITE function code) containing theFile Identifier Object to the appropriate Outstation.

5) If a CONFIRMation Response is required, the Master Application waitsfor this response.

6) Master Application now waits for the response containing the FileIdentifier Object. The object in the response contains the status of thecommand specified in the File_Function field. When this object isreceived, the Master Application sends it to the Outstation Application. Ifthe Master Application does not receive the object, a negativeacknowledgement is sent to the Outstation Application.

7) Upon receipt of a response File Identifier Object or negativeacknowledgement (from the Master Application), the OutstationApplication sends a response to the master. The transaction is complete.


The response to the request uses the RESPONSE Function Code. It contains theFile Identifier Object, which contains the status of the operation requested in theFile_Function field, with no data records. If the Outstation Application receives aresponse from the Master Application, this response contains a File IdentifierObject. The Outstation Application does not need to change this response. If theOutstation Application receives a negative acknowledgement from the MasterApplication, it will modify and set the following fields in the response FileIdentifier Object:

START_RECORD = END_RECORD = 0FILE_SIZE = 0FILE_FUNCTION = RESPONSEPERMISSION = 0STATUS = 2 Master Application was unable to pass the File Identifier

Object to the Master Application.4 Operation unsuccessful because the device addressed by

FILE_ID is offline.4 Operation unsuccessful because a negative

acknowledgement received from the Master Application.

The File_Name field is designed so that File Identifier Objects containingconfigurations can be downloaded to an Outstation via any number ofintermediate data concentrators.

Figure 8-1 is a simplistic example illustrating how the File Identifier Object ispassed through the system from a master station to an Outstation via two dataconcentrators.

DNP Users Group8-4

• • ↓ FILE_NAME = /DNPDCA03/DNPDCA10/config1••••••••••••••••••••••••••••••••••• Outstation application removes•• 1st 9 chars of FILE_NAME ••--------------------------------•• sends object to internal • First Data Concentrator• device number 03 • Outstation Application•--------------------------------• has Address DST=1• Master applic. configuration •• maps device 03 to DST=22 •• Master applic. addresses •• the object to DST=22 ••••••••••••••••••••••••••••••••••• • • ↓ FILE_NAME = /DNPDCA10/config1••••••••••••••••••••••••••••••••••• Outstation application removes•• 1st 9 chars of FILE_NAME ••--------------------------------•• sends object to internal • Second Data Concentrator• device number 10 • Outstation Application•--------------------------------• has Address DST=22• Master applic. configuration •• maps device 10 to DST=8 •• Master applic. addresses •• the object to DST=8 ••••••••••••••••••••••••••••••••••• • • ↓ FILE_NAME = /config1••••••••••••••••••••• •• End Device •• Address 8 •• •••••••••••••••••••••

Figure 8-1 Passing a File Identifier Object Via Data Concentrators

In Figure 8-1:

1) The master station WRITEs the File Identifier Object to the first dataconcentrator (DC). The File_Name field specifies that the object is to besent to device number 3 in the first DC.

2) The Outstation Application in the first DC removes the first ninecharacters of the File_Name. It then routes the object to the MasterApplication specified as device number 3.

3) The Master Application configuration specifies device number 3 has DNPdestination address 22. The Master Application in the first DC WRITEsthe File Identifier Object to the second DC.

4) The second DC receives the WRITE request. The File_Name fieldspecifies that the object is to be sent to device number 10 in the secondDC.

5) The Outstation Application in the second DC removes the first ninecharacters of the File_Name. It then routes the object to the MasterApplication specified as device number 10.

6) The Master Application configuration specifies device number 10 hasDNP destination address 8. The Master Application in the second DCWRITEs the File Identifier Object to the Outstation.


7) The Outstation receives the WRITE request. It responds with aRESPONSE containing the modified File Identifier Object. This objectcontains the status of the operation. It is transmitted to the MasterApplication in the second DC.

8) The Master Application in the second DC transfers the response FileIdentifier Object to the Outstation Application.

9) The Outstation Application sends a RESPONSE containing the FileIdentifier Object to the first DC.

10) The Master Application in the first DC transfers the response FileIdentifier Object to the Outstation Application.

11) The Outstation Application in the first DC sends a RESPONSE containingthe File Identifier Object to the DNP master station.

NOTES:• This functionality requires the DNP master station to have a larger response

timeout than the Outstation Application in the first DC, which in turn has alarger response timeout than the Outstation Application in the second DC.

• The DNP master station must have detailed configuration and routinginformation in order to construct the File_Name field.

• AN Outstation Application will not receive while it waits for a response from adown stream device. It is "locked out" to master requests.

8.2 FILE IDENTIFIER OBJECT PERFORMING READFUNCTIONS

This section describes how a File Identifier Object is used to perform readfunctions. Note that the object is passed to applications via a request using theWRITE function code. The File_Function field is set to READ.

The master station can read the File Identifier Object when the followingconditions are met:• The DNP WRITE Function Code is used in the request.• The File_Function field in the File Identifier Object received in the

request is set to READ.• The File_Name field contains an ASCII character string. The length and

contents of the string is dependant on the DC. The HARRISimplementation uses a string, the first 9 character of which are"/DNPDCAxx", where xx (2 ASCII characters) contains the MasterApplication number of the destination for this File Identifier Object. Thisinformation routes the object through the DC to the Master Applicationwhich will send it on from the DC to the Outstation.

If the above conditions are met, the following sequence occurs;1) The Outstation Application sends a CONFIRMation response to the DNP

master station (if required).

DNP Users Group8-6

2) The Outstation Application removes the first 9 characters from theFile_Name field( for HARRIS implementation), modifying the FileIdentifier Object as required.

3) The Outstation Application sends a READ command with the FileIdentifier Object to the Master Application.

5) The Master Application sends a READ command with the File IdentifierObject to the appropriate Outstation.

6) If a CONFIRMation Response is required, the Master Application waitsfor this response.

7) The Master Application now waits for the response containing therequested File Identifier Object. When this object is received, the MasterApplication sends the response to the Outstation Application. If the MasterApplication does not receive the object, a negative acknowledgement issent to the Outstation Application.

8) Upon receipt of an response File Identifier Object or negativeacknowledgement, the Outstation Application sends a response to themaster. The transaction is complete.

Some error conditions can occur in the above sequence. In the cases where theOutstation Application cannot pass the request to the Master Application or anegative acknowledgement is received from the Master Application, theOutstation Application returns the File Identifier Object received as part of therequest to the master station.

The Outstation Application will modify and set the following fields in theresponse File Identifier Object;

START_RECORD = END_RECORD = 0FILE_SIZE = 0FILE_FUNCTION = RESPONSEPERMISSION = 0STATUS = 2 Outstation Application was unable to pass the File

Identifier Object to the Master Application.4 Operation unsuccessful because the device addressed by

FILE_ID is offline.4 Operation unsuccessful because a negative

acknowledgement received from the Master Application.

DNP V3.00 Application Layer (Version 0.03) 1


AC application controlAPCI application protocol control informationAPDU application protocol data unitASDU application service data unit

COS change of state

DA distribution automationDC data concentratorDNP distributed network protocolDUI data unit identifiers


IEC International Electrotechnical CommissionIIN internal indicationsIO information objectsISO International Standards Organization

OSI Open System InterconnectionPDU protocol data unit

RTU remote terminal unit

SCADA supervisory control and data acquisitionSEQ sequence number


Name of Document: DNP V3:00 Data Object LibraryNetwork File Name: P009-OBL

Original Author: Malcolm Smith/Michael CoppsDate and Version of Preliminary Release: October 8, 1992 Version 0.00AAssociated Software Release(s): DNP V3.00


Date Version By Whom PagesAffected

Reason for Changes

Oct. 08/92 0.00A MS All Created using P020-0BLNov. 09/92 0.00B MS All Revised after review and editorials.Nov. 23/92 0.01 LA All Reformatted to WI standards.Jun. 27/93 0.02 MS All Re-structure, addition of objects.Jul. 01/93 0.02 JB All Update and edit as per the review.Aug. 20/93 0.02 JB All Update and addition of new objects.Sep. 01/93 0.02 JB All Update and reformat.Sep. 01/93 0.02 MCH All Check and revise format.July. 08/97 0.02 S. Tessari All Converted to MSWord 6.0

DNP Users Group


DNP V3.00DATA OBJECT LIBRARY

Document Version: 0.02Internal File: P009-OBL





TRADEMARK NOTICES


DNP V3.00 Data Object Library (Version 0.02) i

TABLE OF CONTENTS

ABOUT THIS DOCUMENT viPURPOSE OF THIS SPECIFICATION viWHO SHOULD USE THIS SPECIFICATION viHELP AND ADDITIONAL DOCUMENTATION viHOW THIS SPECIFICATION IS ORGANIZED viiCONVENTIONS USED IN THIS SPECIFICATION vii

1. OVERVIEW 1-1

2. DECLARATION RULES FOR INFORMATION ELEMENTS 2-12.1 GENERAL 2-1

3. GENERAL RULES 3-13.1 LIBRARY STRUCTURE 3-13.2 POINT NUMBERING 3-4

4. BINARY INPUT OBJECT DEFINITIONS 4-14.1 SINGLE-BIT BINARY INPUT 4-14.2 BINARY INPUT WITH STATUS 4-34.3 BINARY INPUT CHANGE WITHOUT TIME 4-44.4 BINARY INPUT CHANGE WITH TIME 4-64.5 BINARY INPUT CHANGE WITH RELATIVE TIME 4-8

5. BINARY OUTPUT OBJECT DEFINITIONS 5-15.1 BINARY OUTPUT 5-15.2 BINARY OUTPUT STATUS 5-25.3 CONTROL RELAY OUTPUT BLOCK 5-35.4 PATTERN CONTROL BLOCK 5-75.5 PATTERN MASK 5-8

6. COUNTER OBJECT DEFINITIONS 6-16.1 32-BIT BINARY COUNTER 6-16.2 16-BIT BINARY COUNTER 6-36.3 32-BIT DELTA COUNTER 6-5

DNP Users Groupii

6.4 16-BIT DELTA COUNTER 6-66.5 32-BIT COUNTER WITHOUT FLAG 6-76.6 16-BIT COUNTER WITHOUT FLAG 6-86.7 32-BIT DELTA COUNTER WITHOUT FLAG 6-96.8 16-BIT DELTA COUNTER WITHOUT FLAG 6-106.9 32-BIT FROZEN COUNTER 6-116.10 16-BIT FROZEN COUNTER 6-126.11 32-BIT FROZEN DELTA COUNTER 6-136.12 16-BIT FROZEN DELTA COUNTER 6-146.13 32-BIT FROZEN COUNTER WITH TIME OF FREEZE 6-156.14 16-BIT FROZEN COUNTER WITH TIME OF FREEZE 6-176.15 32-BIT FROZEN DELTA COUNTER WITH TIME OF FREEZE 6-196.16 16-BIT FROZEN DELTA COUNTER WITH TIME OF FREEZE 6-216.17 32-BIT FROZEN COUNTER WITHOUT FLAG 6-236.18 16-BIT FROZEN COUNTER WITHOUT FLAG 6-246.19 32-BIT FROZEN DELTA COUNTER WITHOUT FLAG 6-256.20 16-BIT FROZEN DELTA COUNTER WITHOUT FLAG 6-266.21 32-BIT COUNTER CHANGE EVENT WITHOUT TIME 6-276.22 16-BIT COUNTER CHANGE EVENT WITHOUT TIME 6-286.23 32-BIT DELTA COUNTER CHANGE EVENT WITHOUT TIME 6-296.24 16-BIT DELTA COUNTER CHANGE EVENT WITHOUT TIME 6-306.25 32-BIT COUNTER CHANGE EVENT WITH TIME 6-316.26 16-BIT COUNTER CHANGE EVENT WITH TIME 6-336.27 32-BIT DELTA COUNTER CHANGE EVENT WITH TIME 6-356.28 16-BIT DELTA COUNTER CHANGE EVENT WITH TIME 6-376.29 32-BIT COUNTER CHANGE EVENT WITHOUT TIME 6-396.30 16-BIT FROZEN COUNTER EVENT WITHOUT TIME 6-406.31 32-BIT FROZEN DELTA COUNTER EVENT WITHOUT TIME 6-416.32 16-BIT FROZEN DELTA COUNTER WITHOUT TIME 6-426.33 32-BIT FROZEN COUNTER EVENT WITH TIME 6-436.34 16-BIT FROZEN COUNTER EVENT WITH TIME 6-456.35 32-BIT FROZEN DELTA COUNTER EVENT WITH TIME 6-476.36 16-BIT FROZEN DELTA COUNTER EVENT WITH TIME 6-49

7. ANALOG INPUT OBJECT DEFINITIONS 7-17.1 32-BIT ANALOG INPUT 7-17.2 16-BIT ANALOG INPUT 7-37.3 32-BIT ANALOG INPUT WITHOUT FLAG 7-57.4 16-BIT ANALOG INPUT WITHOUT FLAG 7-67.5 32-BIT FROZEN ANALOG INPUT 7-77.6 16-BIT FROZEN ANALOG INPUT 7-87.7 32-BIT FROZEN ANALOG INPUT WITH TIME OF FREEZE 7-97.8 16-BIT FROZEN ANALOG INPUT WITH TIME OF FREEZE 7-117.9 32-BIT FROZEN ANALOG INPUT WITHOUT FLAG 7-137.10 16-BIT FROZEN ANALOG INPUT WITHOUT FLAG 7-147.11 32-BIT ANALOG CHANGE EVENT WITHOUT TIME 7-15

DNP V3.00 Data Object Library (Version 0.02) iii

7.12 16-BIT CHANGE EVENT WITHOUT TIME 7-177.13 32-BIT ANALOG CHANGE EVENT WITH TIME 7-197.14 16-BIT ANALOG CHANGE EVENT WITH TIME 7-217.15 32-BIT FROZEN ANALOG EVENT WITHOUT TIME 7-237.16 16-BIT FROZEN ANALOG EVENT WITHOUT TIME 7-257.17 32-BIT FROZEN ANALOG EVENT WITH TIME 7-277.18 16-BIT FROZEN ANALOG EVENT WITH TIME 7-29

8. ANALOG OUTPUT OBJECT DEFINITIONS 8-18.1 32-BIT ANALOG OUTPUT STATUS 8-18.2 16-BIT ANALOG OUTPUT STATUS 8-38.3 32-BIT ANALOG OUTPUT BLOCK 8-48.4 16-BIT ANALOG OUTPUT BLOCK 8-5

9. TIME OBJECT DEFINITIONS 9-19.1 TIME AND DATE 9-19.2 TIME AND DATE WITH INTERVAL 9-29.3 TIME AND DATE CTO 9-49.4 UN-SYNCHRONIZED TIME AND DATE CTO 9-59.5 TIME DELAY COARSE 9-69.6 TIME DELAY FINE 9-7

10. CLASS OBJECT DEFINITIONS 10-110.1 CLASS 0 DATA 10-110.2 CLASS 1 DATA 10-210.3 CLASS 2 DATA 10-310.4 CLASS 3 DATA 10-4

11. FILE OBJECT DEFINITIONS 11-111.1 FILE IDENTIFIER 11-1

12. DEVICE OBJECT DEFINITIONS 12-112.1 INTERNAL INDICATIONS 12-112.2 STORAGE OBJECT 12-212.3 DEVICE PROFILE 12-412.4 PRIVATE REGISTRATION OBJECT 12-712.5 PRIVATE REGISTRATION OBJECT DESCRIPTOR 12-8

13. APPLICATION OBJECT DEFINITIONS 13-113.1 APPLICATION IDENTIFIER 13-1

14. ALTERNATE NUMERIC OBJECT DEFINITIONS 14-114.1 SHORT FLOATING POINT 14-114.2 LONG FLOATING POINT 14-414.3 EXTENDED FLOATING POINT 14-6

DNP Users Groupiv

14.4 SMALL-PACKED BINARY CODED DECIMAL 14-814.5 MEDIUM-PACKED BINARY CODED DECIMAL 14-914.6 LARGE-PACKED BINARY CODED DECIMAL 14-10


DNP V3.00 Data Object Library (Version 0.02) v

LIST OF TABLES

TABLE 2-1 DATA TYPES 2-1TABLE 2-2 BIT POSITIONS 2-2

DNP Users Groupvi

ABOUT THIS DOCUMENT


This document defines coding specifications of Distributed Network Protocol (DNP)information elements or data objects used in the DNP Application Layer. The objectsyntax is specified as well as the semantics of each object. In the case of compoundobjects, the semantics of each component is described.


All programmers, implementers or engineers interested in the structure of applicationinformation objects used in the DNP Application Layer.


The following documentation may be helpful.• DNP V3.00 Data Link Layer (P009-0PD.DL).• DNP V3.00 Application Layer (P009-0PD.APP)• DNP V3.00 Transport Functions (P009-0PD.TF)

DNP V3.00 Data Object Library (Version 0.02) vii


This document is organized into 13 sections as outlined below.

1. OVERVIEW

2. DECLARATION RULES FOR INFORMATION ELEMENTSCovers the rules for construction and interpretation of the data objects.

3. GENERAL RULESDescribes the rules governing each of the currently defined objects.

The rest of the sections provide detailed definitions of each type of object.

4. BINARY INPUT OBJECT DEFINITIONS

5. BINARY OUTPUT OBJECT DEFINITIONS

6. COUNTER OBJECT DEFINITIONS

7. ANALOG INPUT OBJECT DEFINITIONS

8. ANALOG OUTPUT OBJECT DEFINITIONS

9. TIME OBJECT DEFINITIONS

10. CLASS OBJECT DEFINITIONS

11. FILE OBJECT DEFINITIONS

12. DEVICE OBJECT DEFINITIONS

13. APPLICATION OBJECT DEFINITIONS

14. ALTERNATE NUMERIC OBJECT DEFINITIONS



This document deviates from the IEC conventions for bit position numbering. Bitpositions are numbered from 0 through n, with 0 to the top right and n to the bottom left.

DNP Users Groupviii

DNP V3.00 Data Object Library (Version 0.02) 1-1

1. OVERVIEW

The intelligent devices which use the DNP Application Layer protocol are capable ofmonitoring, controlling and/or producing a large number of different pieces of data bothat the hardware and software levels. These pieces of data, called information elements(IEC 870-5-3: General Structure of Application Data), are processed and stored asinformation objects and these can be packaged for transmission as application data units.All devices provide stored information elements as information objects in the sameformat. These formats are described within this document.

This document will be revised and new information elements or objects will be added asnecessary, and as authorized by the DNP User's Group.

DNP Users Group1-2


2. DECLARATION RULES FORINFORMATION ELEMENTS

2.1 GENERAL

This section describes the basic rules for the declaration of information elements. Theserules have been derived from the IEC TC57 870 series of standards or drafts. These rulesprovide an unambiguous means of describing and representing data irrespective of itsorigin. Device profile documents are used to indicate the exact origin and meaning of thedata object for each telecontrol device.

2.1.1 Data Types

All data can be described in its most elemental form as a data type. Data types arerecognized as standard constructs used in most language compilers. DNP informationelements use constructs, as supported by the IEC 870-5-4, as the basis of its descriptions.Table 2-1 lists the available data types and their meaning.

Data Type Symbol Meaning

1. UNSIGNED INTEGER UI Positive whole number

2. INTEGER I Positive or negative whole number

3. UNSIGNED FIXED POINT UF Positive fixed point number

4. FIXED POINT F Positive or negative fixed pointnumber

5. REAL R Positive or negative floating-pointnumber

6. BITSTRING BS Assembly of independent bits1

7. OCTETSTRING OS Assembly of octets

Table 2-1 Data Types

1BOOLEAN is a BITSTRING of size 1.

DNP Users Group2-2

2.1.2 Data Size

Each information element is composed of a data type and a size. Data size i, is noted afterthe data type symbol notation, and is a cardinal number that specifies the length of thedata field in bits or octets as appropriate. An example is:

BS12 specifies a BITSTRING of 12 bits.

2.1.3 Bit Position

In defining information objects, which are a combination of information elements, theposition of individual bits can be significant. The bit position of a specified field of datasize i is denoted in square brackets [p1..pn], where p1 and pn denote the first and the lastbits of the field. The order of bits is shown in Table 2-2, below.

BITS 7 6 5 4 3 2 1 0

OCTETS Data Size i

1 7 6 5 4 3 2 1 0

2 15 14 13 12 11 10 9 8

.

...

.

...

.

...

.

...

.

.

j 8j-1 8j-2 8j-3 8j-4 8j-5 8j-6 8j-7 8j-8

Table 2-2 Bit Positions

2.1.4 Element Value

If applicable, a selected range and a selected code of values of the declared data field isdenoted within angle brackets: <v1..vn code>. In general this is declared by the range ofadmitted values and by a term that identifies the used code. Terms that identify codes are:binary code (BIN), binary coded decimal (BCD), ASCII (ASCII), etc. The default codedeclaration is binary if no term is used.

2.1.5 Compound Elements

Compound data fields are information elements composed of different data fields withsuccessive bit allocations. Compound data fields are declared by listing individual datafields separated by commas or listed in a column, within curly brackets. A following listdeclares the data types, the sizes, the bit allocations and the functional purpose of theindividual data fields. The first declared data field begins with bit position 0, the otherfields use successive bit allocations:


'Information Element = CPi {data field 1, data field 2,...}or{data field 1 = data type 1 size i1[0..i-1] = function 1data field 2 = data type 2 size i2[i1..i1+i2-1] = function 2etc.}

2.1.6 Sequence Elements

Sequence data fields are information elements composed of different data fields.Sequences of data fields are declared as compound data fields, however each field beginsbit allocation 0:

'Information Element = SQi {data field 1, data field 2, ...}or{data field 1 size i1[1..i1] = function 1data field 2 size i2[1..i2] = function 2etc.}

DNP Users Group2-4


3. GENERAL RULES

This section will describe the general rules that apply to the DNP data objects. Theserules apply to all the current objects (except where noted) and all future objects.

3.1 LIBRARY STRUCTURE

The DNP application layer has an 8-bit object and an 8-bit variation field used to denotethe data object. The 8-bit object denotes a general type of data such as static binary data.The variation of this object gives a different representation of the same data point, such asthe size of the object or whether or not the object has flag information.

There are generally four different categories of data within each data type, as outlinedbelow:

• Static Objects: The objects which reflect the current value of the field point orsoftware point.

• Event Objects: The objects which are generated as a result of data changing orsome other stimulant. These are historical objects reflecting the value of data atsome time in the past.

• Frozen Static Objects: The objects which reflect the current frozen value of thefield point or software point. Data is frozen as a result of the data freeze requests.(Refer to the DNP V3.00 Application Layer, P009-0PD.APP.)

• Frozen Event Objects: The objects which are generated as a result of frozen datachanging or some other stimulant. These are historical objects reflecting the valueof changed data at some time in the past.

Each category should be represented with a different object. All the classes of a differentdata type should also be organized in the same range of object numbers. So far, thefollowing groupings have been created for all traditional SCADA/DA data types andseveral non-traditional data types. These are as follows:

3.1.1 Binary Input

The binary input grouping contains all objects that represent binary (status or Boolean)input information. The objects 1 - 9 are reserved for these objects.

DNP Users Group3-2

3.1.2 Binary Output

The binary output grouping contains all objects that represent binary output or relaycontrol information. The objects 10 - 19 are reserved for these objects.

3.1.3 Counters

The counter grouping contains all objects that represent counters. The objects 20 - 29 arereserved for these objects.

3.1.4 Analog Input

The analog input grouping contains all objects that represent analog input information.The objects 30 - 39 are reserved for these objects.

3.1.5 Analog Output

The analog output grouping contains all objects that represent analog output information.The objects 40 - 49 are reserved for these objects.

3.1.6 Time

The time grouping contains all objects that represent time in absolute or relative form inany resolution. The objects 50 - 59 are reserved for these objects.

3.1.7 Class

The class grouping contains all objects that represent data classes or data priority. Theobjects 60 - 69 are reserved for these objects.

3.1.8 Files

The files grouping contains all objects that represent files or a file system. The objects 70- 79 are reserved for these objects.

3.1.9 Devices

The devices grouping contains all objects that represent device (rather than point)information. The objects 80 - 89 are reserved for these objects.

3.1.10 Applications

The applications grouping contains all objects that represent software applications oroperating system processes. The objects 90 - 99 are reserved for these objects.


3.1.11 Alternate Numeric

The alternate numeric grouping contains all objects that represent alternate or customnumeric representations. The objects 100 - 109 are reserved for these objects.

3.1.12 Future Expansion

The future expansion grouping is reserved for future or custom expansion of the DNPprotocol. The objects 110 - 254 are reserved for these objects.

3.1.13 Reserved

The objects 0 and 255 are permanently reserved and should not be used to denote anyDNP object. Applications which use these object numbers may not be compatible withfuture versions of DNP.

DNP Users Group3-4

3.2 POINT NUMBERING

The following rules apply to the interpretation of the object point number (DNPApplication Layer range field) in conjunction with objects and variations.

Rule 1:Point i of object x, variation y represents the same physical point as point i, object x,variation z, where y and z are variations of object x.

For example: A device has 16 running counters (object 20) numbered 0 to 15. Point 5can be asked for in four different ways:

• Obj 20, var 1, range 5 returns the running value of counter 5 in 32-bit format.• Obj 20, var 2, range 5 reports the same information, only in 16-bit format.• Obj 20, var 3, range 5 returns the number of counts accumulated in counter 5 since the

last time it was reported, again in 32-bit format.• Obj 20, var 4, range 5 reports the same information, only in 16-bit format.

RULE 2:Point i of object x can be reported in one of many variations (i.e. it can be a 16-bit or 32-bit counter). When reported as an event, point i can be returned in either one of thevariations for that object. The exact variation to return is an application specific decision,however an application should report only ONE event object in any one variation for eachevent. When responding to a request for Class data or variation 0 of object x, there shouldbe only one variation of the object returned.

RULE 3:Point i within different objects of the same grouping are not necessarily unique, however,within each of the binary input, binary output, analog input, analog output and countergroupings the following rules apply.

(a) Point i in the static object is the same physical point as point i in the eventobject.

(b) Point i in the frozen object is the same physical point as point i in thefrozen event object.

For example: For binary inputs, point i in obj 1 var 1 and 2 is the same point as point i inobj 2 var 1, 2 and 3 (static and event correlation). For counters, point i in obj 20 var 1, 2,3, and 4 is the same point as point i in obj 22 var 1, 2, 3, 4, 5, 6, 7, and 8 (static and eventcorrelation). In addition, point i in obj 21 var 1, 2, 3, 4, 5, 6, 7, and 8 is the same point aspoint i in obj 23 var 1, 2, 3, 4, 5, 6, 7, and 8 (frozen and frozen static correlation).

NOTE: Point i in obj 20 and point i in obj 21 are NOT necessarily the same point.There is no direct correlation between frozen and non-frozen objects.


Rule 4:Object groupings which can by definition or due to device limitation have only one pointper object or where the point number is not needed should use the range number 0 orquantity equals to 1, when using a message format that requires a point number.

DNP Users Group3-6


4. BINARY INPUT OBJECTDEFINITIONS

This section defines the binary input data objects using the rules established in section 2.DECLARATION RULES FOR INFORMATION ELEMENTS.

4.1 SINGLE-BIT BINARY INPUT

Data Object 01 - Variation: 01 Type: Static

Description:The single-bit binary input object is used to represent the state of a digital input point(hardware or software).

Object Coding:

0

BS1 [0..0]State = BS1 [0] <0,1 BIN>

Narrative:This single-bit binary input representation is used to transmit binary input states in apacked format. Transmission of the data object is always performed in complete octetswith unoccupied bit positions set to zero. The following example illustrates the packingof n of these data objects.

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

0 0 0 n n-1 n-2 n-3 n-4

DNP Users Group4-2

NOTE: This variation contains no point status information. For example, on-line,restart, etc. bits which are part of the binary input with status variation,are not part of this variation. The use of the single-bit binary inputvariation implies that the point is on-line and all other status bits are clear.(i.e. restart, communication lost, etc. bits are cleared).


4.2 BINARY INPUT WITH STATUS


Description:The binary input with status object is used to represent the state of a digital input point(hardware or software), and also indicates the status of the point as follows:

The on-line bit indicates that the binary input point has been read successfully. Ifthis field is set to off-line, the state of the digital point may not be correct.

The restart bit indicates that the field device that originated the data object iscurrently restarting. This device may be the device reporting this data object.

The communication lost bit indicates that the device reporting this data object haslost communication with the originator of the data object.

The remote forced data bit indicates that the state of the binary input has beenforced to its current state at a device other than the end device.

The local forced data bit indicates that the state of the binary input has beenforced to its current state at the end device.

The chatter filter bit indicates that the binary input point has been filtered in orderto remove unneeded transitions in the state of the point.

The state bit indicates the current state of the binary input point.

Object Coding:

7 6 5 4 3 2 1 0

BS8 [0..7]On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0, normal; 1, forced>Chatter filter = BS1 [5] <0, normal; 1, filter on>Reserved = BS1 [6] <0>State = BS1 [7] <0, 1 BIN>

DNP Users Group4-4

4.3 BINARY INPUT CHANGE WITHOUT TIME

Data Object 02 - Variation: 01 Type: Event

Description:The binary input change without time object is used to represent the changed state of adigital input point (hardware or software) and also indicates the status of the point asfollows:


The restart bit indicates that the field device that originated the data object hasbeen re-started. This device may be the device reporting this data object.


The remote forced data bit indicates that the state of the binary input has beenforced to its current state at the originating device.

The local forced data bit indicates that the state of the binary input has beenforced to its current state at the device reporting this data object.


The state bit indicates the current changed state of the binary input point.


Object Coding:

7 6 5 4 3 2 1 0

BS8 [0..7]On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0, normal; 1, forced>Chatter filter = BS1 [5] <0, normal; 1, filter on>Reserved = BS1 [6] <0>State = BS1 [7] <0,1 BIN>

Narrative:This object is only reported when the current value is different than the last recorded ormeasured value. If the chatter filter is on, this object may only be reported when the newstate has remained constant for a certain period of time.

DNP Users Group4-6

4.4 BINARY INPUT CHANGE WITH TIME


Description:The binary input change with time object is used to represent the changed state of adigital input point (hardware or software) and the time at which the state changed. It alsoindicates the status of the point as follows:








The Time of Occurrence indicates the absolute time at which the telecontrol devicedetected the change of state. The accuracy of this time will depend on the accuracy of theindividual device.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

TIME OF OCCURRENCE

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

23 22 21 20 19 18 17 16

31 30 29 28 27 26 25 24

39 38 37 36 35 34 33 32

47 46 45 44 43 42 41 40

SQ2 {FLAG = BS8 [0..7]Time of Occurrence = UI48 [0..47] <248 -1 ms>}

FLAG ={ BS8 [0..7]On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0, normal; 1, forced>Chatter filter = BS1 [5] <0, normal; 1, filter on>Reserved = BS1 [6] <0>State = BS1 [7] <0,1 BIN>}

Narrative:Time of occurrence is recorded as milliseconds since midnight, January 1st, 1970, at zerohours, zero minutes, seconds, and milliseconds.

DNP Users Group4-8

4.5 BINARY INPUT CHANGE WITH RELATIVE TIME


Description:The binary input change with relative time object is used to represent the changed state ofa digital input point (hardware or software), and the relative time at which the statechanged. It also indicates the status of the point as follows:








The MSEC field indicates the relative time at which the telecontrol device detected thechange of state. The accuracy of this time will depend on the accuracy of the individualdevice.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

MSEC

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

SQ2 {FLAG = BS8 [0..7]MSEC = UI16 [0..15] <0..216-1>

}

FLAG ={ BS8 [0..7]On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0, normal; 1, forced>Chatter filter = BS1 [5] <0, normal; 1, filter on>Reserved = BS1 [6] <0>State = BS1 [7] <0,1 BIN>}

Narrative:This object MUST be preceded by an absolute time object (common time object or CTO)or an unsynchronized CTO in the DNP Application Layer message. The CTO is used asan absolute time base for all following binary input change with relative time objects.The relative time in each binary input object is added to the CTO absolute time to givethe absolute time at which the binary input change was detected by the device.

DNP Users Group4-10


5. BINARY OUTPUT OBJECTDEFINITIONS

This section defines the binary output data objects using the rules established in section 2.DECLARATION RULES FOR INFORMATION ELEMENTS.

5.1 BINARY OUTPUT


Description:The binary output object is used to control a digital output point (hardware or software).The state bit indicates the desired logic state of the digital output point.

Object Coding:

0

BS1 [0..0]State = BS1 [0] <0,1 BIN>

Narrative:Transmission of the data object is always pre-formed in complete octets, with unoccupiedbit positions set to zero. The following example illustrates the packing of n of these dataobjects:

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

0 0 0 n n-1 n-2 n-3 n-4

DNP Users Group5-2

5.2 BINARY OUTPUT STATUS


Description:The binary output status object is used to indicate the current state of a controlled digitalpoint and the status of that point as follows:

The on-line bit indicates that the device controlling the binary output point isoperating correctly. A binary output command to this point should work correctly.If this field is set to off-line, a binary output command to this point would beunsuccessful.


The communication lost bit indicates that the digital output point could not becontrolled because communications have been lost with the controlled device.

The remote forced data bit indicates that the digital output point has beencontrolled at the originating device and the current state is in the state bit.

The local forced data bit indicates that the digital output point has been controlledat this device and the current state is in the state bit.

The state bit indicates the current state of the binary output point.

Object Coding:

7 6 5 4 3 2 1 0

BS8 [0..7]On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0, normal; 1, forced>Reserved = BS1 [5] <0>Reserved = BS1 [6] <0>State = BS1 [7] <0,1 BIN>


5.3 CONTROL RELAY OUTPUT BLOCK


Description:The control relay output Block information object contains digital output controlparameters. These parameters define the type and duration of the digital output.

The control code field indicates the control function to perform. The applicabilityof this code will depend on the type of hardware used in the end device.

The count field indicates the number of times that the control operation should beperformed in succession.

The on-time field specifies the amount of time the digital output is to be turned on(may not apply to all control types).

The off-time field specifies the amount of time the digital output is to be turned off(may not apply to all control types).

DNP Users Group5-4

Object Coding:

Control Code

7 6 5 4 3 2 1 0

Count

7 6 5 4 3 2 1 0

On Time

31 0

Off Time

31 0

Status

7 6 5 4 3 2 1 0

SQ4 {Control code = BS8 [0..7]Count = UI8 [0..7] <0..255>On-time = UI32 [0..31] <0..232-1, ms>Off-time = UI32 [0..31] <0..232-1, ms>Status = UI7 [0..6] <0..127>Reserved = [0..0] <0..1>}

Control code ={Code = BS4 [0..3] <0..15>Queue = BS1 [4] <0, normal; 1, requeued>Clear = BS1 [5] <0, normal; 1, clear>Trip/Close = BS2 [6..7] <00, NUL; 01, Close; 10, Trip>}

Narrative:Trip/Close: This field determines which control relay to activate in a system where a

trip and close relay pair is used to energize and de-energize the fieldpoints. The NUL value in this field can be used to activate the field pointselect relay only without activating the trip or close relays. In a systemwithout field point select relays, the NUL value would not perform anycontrol operation. In a system without trip/close relays, this field shouldalways be NUL to indicate a normal digital control operation where theexact control point is inherently known. This field does not support havingboth the trip and close attributes simultaneously, as this is an illegaloperation for the system.


Count: The Count field determines how many times the control is executed. If thecount is 0, do not execute the control. When the count reaches 0, thecontrol is complete.

Code: The control block can be used with devices which support control queuingon a point per point basis or devices which have other controlmechanisms. In the former, any control command should be queued for theparticular point in question. In the latter, each control is performed untilcompletion before the next control is accepted for that point.

Queue: If the control code is NUL then no control operation is queued, and thequeue is cleared of all controls including the presently running control ifthe clear attribute is set.

When the control function is executed and completed, it is removed fromthe queue. If the control block for that operation had the queue attributeset, the control operation is re-queued (to the back of the queue) for thatpoint.

Clear: If the control operation has the clear attribute set, all control operations areremoved from the queue including the presently running control and thiscontrol operation is performed.

The meaning of the code field and the operation to perform is determined by thefollowing:

0: NUL operation. No operation specified. Only the R attribute is processed.

1: Pulse On - The point(s) is turned on for the specified on-time, turned offfor the specified off-time and left in the off state.

2: Pulse Off - The point(s) is turned off for the specified off-time, then turnedon for the specified on-time and left in the on state.

3: Latch On - This latches the point(s) on.

4: Latch Off - This latches the point(s) off.

5 - 15: Undefined.

Queue: Place operation at the back of the control queue when complete.

Clear: Cancel currently running operation and remove queued operations onaffected points immediately before activating this new operation (if notNUL).

DNP Users Group5-6

The reserved bit of the control point after the operation can be determinedif the control output is on.

The success or failure of the requested control operation is returned in thestatus field. The meaning of this field is determined as follows:

0: Request accepted, initiated, or queued.

1: Request not accepted as the operate message was received after thearm timer timed out. The arm timer was started when the selectoperation for the same point was received.

2: No previous matching select message (i.e. an operate message wassent to activate a control point that was not previously armed withthe select message.

3: Request not accepted as there were formatting errors in the controlrequest (either select, operate, or direct operate).

4: Control operation not supported for this point.

5: Request not accepted, as the control queue is full or the point isalready active.

6: Request not accepted because of control hardware problems.

7 - 127:Undefined.


5.4 PATTERN CONTROL BLOCK


Description:The pattern control block (PCB) object contains digital output control parameters forpattern type controls. These parameters define the type and duration of the digital outputfor each of the affected points. The PCB object defines all the parameters for thesubsequent pattern mask objects which follow this object in the message. Theseparameters contained in the PCB influence all the pattern mask object(s) that immediatelyfollow the PCB object, until the next PCB in the message.

The combination of this object and the pattern mask objects that follow will specify anumber (0 or more) of control operations to perform (i.e. the same operation on differentpoints). All these controls must be performed in parallel. The meaning of all fields,attributes, and parameters are identical to the control relay output block except that thequeuing attributes are not valid. This is, the pattern control is not meant to be re-queued.

Object Coding:

Control Code

7 6 5 4 3 2 1 0

Count

7 6 5 4 3 2 1 0

On Time

31 0

Off Time

31 0

Status

7 6 5 4 3 2 1 0

DNP Users Group5-8

5.5 PATTERN MASK


Description:The pattern mask object is used to select from a range of possible control points that have tobe executed in parallel.

This object is used in conjunction with the PCB object to specify both the control points tooperate and the parameters that determine the control operation.

If the mask bit is set to active, then the parameters specified in the preceding PCB areapplied to a specified point for each pattern mask object and a control operation is generatedfor the point.

Object Coding:

M

BS1 [0..0]Mask = BS1 [0] <0, inactive; 1, active>

Narrative:This single-bit pattern mask is typically sent in groups. Transmission of the data object isalways performed in complete octets with unoccupied bit positions set to zero. Thefollowing example illustrates the packing of n of these data objects.

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

0 0 0 n n-1 n-2 n-3 n-4


6. COUNTER OBJECT DEFINITIONS

This section defines the counter data objects using the rules established in section 2..DECLARATION RULES FOR INFORMATION ELEMENTS.

6.1 32-BIT BINARY COUNTER


Description:The 32-bit binary counter represents an accumulated value. This can be accumulated pulsesor transitions from a hardware or software point.

The value field shows the current value of the counter at the time of reporting or lastreported value from the originating device. This value increments indefinitely until acounter clear operation is performed in which case the value is reset to 0.

The flag field has the same meaning as in previous objects, with the following inclusion:

• When set, the roll-over bit indicates that the accumulated value has exceeded the lastreported recordable value (232-1). The counter value has been reset to 0 upon the roll-over and counting has resumed as normal. This bit is cleared when the counter value(plus the roll-over state) is reported.

DNP Users Group6-2

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Value

31 0

SQ2 {FLAG = BS8 [0..7]Value = UI32 [0..31] <0..232-1>}

FLAG ={On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0, normal; 1, forced>Roll-over = BS1 [4] <0, normal; 1, roll-over>Roll-over = BS1 [5] <0, normal; 1, roll-over>Reserved = BS1 [6] <0>Reserved = BS1 [7] <0>}


6.2 16-BIT BINARY COUNTER





• When set, the roll-over bit indicates that the accumulated value has exceeded themaximum possible recordable value (216-1). The counter value has been reset to 0 uponroll-over, and counting has resumed as normal. This bit is cleared when the counter value(plus the roll-over state) is reported.

DNP Users Group6-4

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Value

15 0




6.3 32-BIT DELTA COUNTER


Description:The 32-bit delta counter represents a value that has accumulated since the last value wasreported. This can be accumulated pulses or transitions from a hardware or software point.

The value field shows the current value of the counter at the time of reporting or lastreported value from the originating device. This value increments until it is reported atwhich point it is reset to 0.


• When set, the roll-over bit indicates that the accumulated value has exceeded themaximum possible recordable value (232-1). The counter value has been reset to 0 uponroll-over, and counting has resumed as normal. This bit is cleared when the counter value(plus the roll-over state) is reported.

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Value

31 0



DNP Users Group6-6

6.4 16-BIT DELTA COUNTER





• When set, the roll-over bit indicates that the accumulated value has exceeded themaximum possible recordable value (216-1). The counter value has been reset to 0 uponthe roll-over and counting has resumed as normal. This bit is cleared when the countervalue (plus the roll-over state) is reported.

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Value

15 0




6.5 32-BIT COUNTER WITHOUT FLAG




Object Coding:

Value

31 0

SQ2 {Value = UI32 [0..31] <0..232-1>}

NOTE: The use of this variation implies that the input point is on-line and that allother flag bits are normal (i.e. this variation implies that flag = 1).

DNP Users Group6-8

6.6 16-BIT COUNTER WITHOUT FLAG




Object Coding:

Value

15 0

SQ2 {Value = UI16 [0..15] <0..216-1>}



6.7 32-BIT DELTA COUNTER WITHOUT FLAG




Object Coding:

Value

31 0

SQ2 {Value = UI32 [0..31] <0..232-1>}


DNP Users Group6-10

6.8 16-BIT DELTA COUNTER WITHOUT FLAG




Object Coding:

Value

15 0

SQ2 {Value = UI16 [0..15] <0..216-1>}



6.9 32-BIT FROZEN COUNTER

Data Object 21 - Variation: 01 Type: Frozen Static

Description:The 32-bit frozen counter is a compound information object which contains informationabout a counter which was previously frozen.

The frozen value shows the value of the counter when the last counter freeze was performedat the originating device.

The flag field has the same meaning as in previous objects.

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

31 0

SQ2 {FLAG = BS8 [0..7]Frozen Value = UI32 [0..31] <0..232-1>


DNP Users Group6-12

6.10 16-BIT FROZEN COUNTER


Description:The 16-bit frozen counter is a compound information object that contains information abouta counter that was previously frozen. The counter accumulates pulses or transitions from ahardware or software point.



Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

15 0

SQ2 {FLAG = BS8 [0..7]Frozen Value = UI16 [0..15] <0..216-1>}



6.11 32-BIT FROZEN DELTA COUNTER


Description:The 32-bit frozen delta counter represents a frozen value that has accumulated since the lastvalue was reported. This can be accumulated pulses or transitions from a hardware orsoftware point.



Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

31 0

SQ2 {FLAG = BS8 [0..7]Frozen Value = UI32 [0..31] <0..232-1>


DNP Users Group6-14

6.12 16-BIT FROZEN DELTA COUNTER


Description:

The 16-bit frozen delta counter represents a frozen value that has accumulated since the lastvalue was reported. This can be accumulated pulses or transitions from a hardware orsoftware point.



Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

15 0

SQ2 {FLAG = BS8 [0..7]Frozen Value = UI16 [0..15] <0..216-1>}



6.13 32-BIT FROZEN COUNTER WITH TIME OF FREEZE


Description:The 32-bit frozen counter with time of freeze is a compound information object whichcontains information about a counter which was previously frozen. The counteraccumulates pulses or transitions from a hardware or software point.

The frozen value shows the value of the counter when the time was time of freeze.

The time of freeze field contains a time that this object was frozen. This time corresponds tothe frozen value so that the current value of this object at time of freeze is frozen value.


DNP Users Group6-16

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

31 0

Time of Freeze

47 0

SQ4 {FLAG = BS8 [0..7]Frozen value = UI32 [0..31] <0..232-1>Time of Freeze = UI48 [0..47] <248 -1 ms>}

FLAG ={On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0, normal; 1, forced>Roll-over = BS1[4] <0, normal; 1, roll-over>Roll-over = BS1 [5] <0, normal; 1, roll-over>Reserved = BS1 [6] <0>Reserved = BS1 [7] <0>}

Narrative:Time of freeze is recorded as milliseconds since midnight, January 1st, 1970, at zero hours,zero minutes, seconds, and milliseconds.


6.14 16-BIT FROZEN COUNTER WITH TIME OF FREEZE


Description:The 16-bit frozen counter with time of freeze is a compound information object whichcontains information about a counter which was previously frozen. The counteraccumulates pulses or transitions from a hardware or software point.




DNP Users Group6-18

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

15 0

Time of Freeze

47 0


FLAG ={On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0, normal; 1, forced>Roll-over = BS1[4] <0, normal; 1, roll-over>Roll-over = BS1 [5] <0, normal; 1, roll-over>Reserved = BS1 [6] <0>Reserved = BS1 [7] <0>}



6.15 32-BIT FROZEN DELTA COUNTER WITH TIME OF FREEZE


Description:The 32-bit frozen delta counter with time of freeze represents a frozen value that hasaccumulated since the last value was reported. This can be accumulated pulses or transitionsfrom a hardware or software point.




DNP Users Group6-20

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen value

31 0

Time of Freeze

47 0





6.16 16-BIT FROZEN DELTA COUNTER WITH TIME OF FREEZE


Description:The 16-bit frozen delta counter with time of freeze represents a frozen value that hasaccumulated since the last value was reported. This can be accumulated pulses or transitionsfrom a hardware or software point.




DNP Users Group6-22

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen value

15 0

Time of Freeze

47 0





6.17 32-BIT FROZEN COUNTER WITHOUT FLAG


Description:The 32-bit frozen counter is a compound information object which contains informationabout a counter which was previously frozen.


Object Coding:

Frozen Value

31 0

SQ2 {Frozen Value = UI32 [0..31] <0..232-1>}


DNP Users Group6-24

6.18 16-BIT FROZEN COUNTER WITHOUT FLAG


Description:The 16-bit frozen counter is a compound information object which contains informationabout a counter which was previously frozen. The counter accumulates pulses or transitionsfrom a hardware or software point.


Object Coding:

Frozen Value

15 0




6.19 32-BIT FROZEN DELTA COUNTER WITHOUT FLAG




Object Coding:

Frozen Value

31 0



DNP Users Group6-26

6.20 16-BIT FROZEN DELTA COUNTER WITHOUT FLAG




Object Coding:

Frozen Value

15 0




6.21 32-BIT COUNTER CHANGE EVENT WITHOUT TIME


Description:The 32-bit counter change event without time represents a counter value that, since lastreported, has exceeded a configured count. This can be accumulated pulses or transitionsfrom a hardware or software point.

The current value field shows the value of the counter which generated the event.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

Current value

31 0

SQ4 {FLAG = BS8 [0..7]Current value = UI32 [0..31] <0..232-1>}


DNP Users Group6-28



Description:The 16-bit counter change event without time represents a counter value that has exceeded aconfigured deadband. This can be accumulated pulses or transitions from a hardware orsoftware point.

The current value field shows the value of the counter which generated the event.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

Current value

15 0




6.23 32-BIT DELTA COUNTER CHANGE EVENT WITHOUT TIME


Description:The 32-bit delta counter change event without time represents a delta counter value that hasexceeded a configured deadband. This can be accumulated pulses or transitions from ahardware or software point.

The delta value field shows the change of the counter which generated the event.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

Delta value

31 0



DNP Users Group6-30

6.24 16-BIT DELTA COUNTER CHANGE EVENT WITHOUT TIME


Description:The 16-bit delta counter change event without time represents a delta counter value that hasexceeded a configured deadband. This can be accumulated pulses or transitions from ahardware or software point.

The delta value field shows the change of the counter which generated the event.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

Delta value

15 0




6.25 32-BIT COUNTER CHANGE EVENT WITH TIME


Description:The 32-bit counter change event with time represents a counter value that has exceeded aconfigured deadband. This can be accumulated pulses or transitions from a hardware orsoftware point.

The value field shows the value of the counter which generated the event.

The Time field contains the time that processing generated the event.


DNP Users Group6-32

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Value

31 0

Time

47 0

SQ4 {FLAG = BS8 [0..7]Value = UI32 [0..31] <0..232-1>Time = UI48 [0..47] <248 -1 ms>}


Narrative:Time is recorded as milliseconds since midnight, January 1st, 1970, at zero hours, zerominutes, seconds, and milliseconds.


6.26 16-BIT COUNTER CHANGE EVENT WITH TIME


Description:The 16-bit counter change event with time represents a counter value that has exceeded aconfigured deadband. This can be accumulated pulses or transitions from a hardware orsoftware point.

The value field shows the value of the counter which generated the event.

The time field contains the time that processing generated the event.


DNP Users Group6-34

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Value

15 0

Time

47 0





6.27 32-BIT DELTA COUNTER CHANGE EVENT WITH TIME


Description:The 32-bit delta counter change event with time represents a delta counter value that hasexceeded a configured deadband. This can be accumulated pulses or transitions from ahardware or software point.

The value field shows the value of the change which generated the event.

The time contains the time that processing generated the event.


DNP Users Group6-36

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Value

31 0

Time

47 0





6.28 16-BIT DELTA COUNTER CHANGE EVENT WITH TIME


Description:The 16-bit delta counter change event with time represents a delta counter value that hasexceeded a configured deadband. This can be accumulated pulses or transitions from ahardware or software point.

The value field shows the value of the change which generated the event.

The time field contains the time that processing generated the event.


DNP Users Group6-38

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Value

15 0

Time

47 0






Data Object 23 - Variation: 01 Type: Frozen Event

Description:The 32-bit frozen counter event without time object represents a frozen counter value that isreported as an event. This can be accumulated pulses or transitions from a hardware orsoftware point.

The frozen value field shows the value at the time of freezing.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen value

31 0

SQ4 {FLAG = BS8 [0..7]Frozen value = UI32 [0..31] <0..232-1>}


DNP Users Group6-40

6.30 16-BIT FROZEN COUNTER EVENT WITHOUT TIME


Description:The 16-bit frozen counter event without time represents a frozen counter value that isreported as an event. This can be accumulated pulses or transitions from a hardware orsoftware point.

The frozen value field shows the value at the time of freezing.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen value

15 0

SQ4 {FLAG = BS8 [0..7]Frozen value = UI16 [0..15] <0..216-1>}



6.31 32-BIT FROZEN DELTA COUNTER EVENT WITHOUT TIME


Description:The 32-bit frozen delta counter event without time represents a frozen delta counter valuethat is reported as an event. This can be accumulated pulses or transitions from a hardwareor software point.

The frozen delta value field shows the change in counter value at the time of freezing.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen delta value

31 0

SQ4 {FLAG = BS8 [0..7]Frozen delta value = UI32 [0..31] <0..232-1>}


DNP Users Group6-42

6.32 16-BIT FROZEN DELTA COUNTER WITHOUT TIME


Description:The 16-bit frozen delta counter event without time represents a frozen delta counter valuethat is reported as an event. This can be accumulated pulses or transitions from a hardwareor software point.

The frozen delta value field shows the change in counter value at the time of freezing.


Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen delta value

15 0

SQ4 {FLAG = BS8 [0..7]Frozen delta value = UI16 [0..15] <0..216-1>}



6.33 32-BIT FROZEN COUNTER EVENT WITH TIME


Description:The 32-bit frozen counter event with time represents a frozen counter value that is reportedas an event. This can be accumulated pulses or transitions from a hardware or softwarepoint.

The frozen value shows the value of the counter at time of freeze.

The time of freeze contains the time that the object was frozen.


DNP Users Group6-44

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

31 0

Time of Freeze

47 0

SQ4 {FLAG = BS8 [0..7]Frozen Value = UI32 [0..31] <0..232-1>Time of Freeze = UI48 [0..47] <248 -1 ms>}




6.34 16-BIT FROZEN COUNTER EVENT WITH TIME


Description:The 16-bit frozen counter event with time represents a frozen counter value that is reportedas an event. This can be accumulated pulses or transitions from a hardware or softwarepoint.

The frozen value shows the value of the counter at time of freeze.



DNP Users Group6-46

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

15 0

Time of Freeze

47 0



Narrative:Time is recorded as milliseconds since midnight, January 1st, 1970 at zero hours, zerominutes, seconds and milliseconds.


6.35 32-BIT FROZEN DELTA COUNTER EVENT WITH TIME


Description:The 32-bit frozen delta counter event with time represents a frozen delta counter value thatis reported as an event. This can be accumulated pulses or transitions from a hardware orsoftware point.

The frozen value shows the change in the counter at time of freeze.



DNP Users Group6-48

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

31 0

Time of Freeze

47 0



Narrative:Time is recorded as milliseconds since midnight, January 1st, 1970 at zero hours, zerominutes, seconds and milliseconds.


6.36 16-BIT FROZEN DELTA COUNTER EVENT WITH TIME


Description:The 16-bit frozen delta counter event with time represents a frozen delta counter value thatis reported as an event. This can be accumulated pulses or transitions from a hardware orsoftware point.

The frozen value shows the change in the counter at time of freeze.



DNP Users Group6-50

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Frozen Value

15 0

Time of Freeze

47 0





7. ANALOG INPUT OBJECTDEFINITIONS

This section defines the analog input data objects using the rules established in section 2.DECLARATION RULES FOR INFORMATION ELEMENTS.

7.1 32-BIT ANALOG INPUT


Description:The 32-bit Analog Input is an information object used to represent a hardware or softwareanalog point. The 32-bit signed value could represent a digitized signal or calculated value.

The Value field shows the current value of the analog input at the time of reporting or thelast reported value from the originating device.

The flag field has the same meaning as previous objects, with these additions:

• The out of range field indicates that the digitized signal or calculation has exceeded +231

-1 positively, or -231 negatively. The actual value will be +231 -1 or -231 if it is over-range or under-range.

• The reference check field indicates that the reference signal used to digitize the analog

input is not stable and the resulting digitized value may not be correct.

DNP Users Group7-2

Object Coding:

FLAG

7 0

Current value

31 0

SQ2 {FLAG = BS8 [0..7]Current value = I32 [0..31] <231-1..-231>}

FLAG ={On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0, normal; 1, forced>Over-range = BS1 [5] <0, normal; 1, over-range>Reference check = BS1 [6] <0, normal; 1, error>Reserved = BS1 [7] <0>}


7.2 16-BIT ANALOG INPUT


Description:The 16-bit analog input is an information object used to represent a hardware or softwareanalog point. The 16-bit signed value could represent a digitized signal or calculated value.

The value field shows the current value of the analog input at the time of reporting, or thelast reported value from the originating device.


• The over-range field indicates that the digitized signal or calculation has exceeded +215 -1 positively, or -215 negatively. The actual value field can be ignored as its value is notdefined.



DNP Users Group7-4

Object Coding:

FLAG

7 0

Current value

15 0




7.3 32-BIT ANALOG INPUT WITHOUT FLAG



The value field shows the current value of the analog input at the time of reporting, or thelast reported value from the originating device.

Object Coding:

Current value

31 0

SQ2 {Current value = I32 [0..31] <231-1..-231>}


DNP Users Group7-6

7.4 16-BIT ANALOG INPUT WITHOUT FLAG



The current value field shows the current value of the analog input at the time of reporting,or the last reported value from the originating device.

Object Coding:

Current value

15 0

SQ2 {Current value = I16 [0..15] <215-1..-215>}



7.5 32-BIT FROZEN ANALOG INPUT


Description:The 32-bit frozen analog input is an information object used to represent a frozen hardwareor software analog point. The 32-bit signed value could represent a digitized signal orcalculated value.

The frozen value shows the value of the analog input at the time the last freeze commandwas performed on this point.




input is not stable, and the resulting digitized value may not be correct.

Object Coding:

FLAG

7 0

Frozen value

31 0



DNP Users Group7-8

7.6 16-BIT FROZEN ANALOG INPUT


Description:The 16-bit frozen analog input is an information object used to represent a frozen hardwareor software analog point. The 16-bit signed value could represent a digitized signal orcalculated value.






Object Coding:

FLAG

7 0

Frozen value

15 0




7.7 32-BIT FROZEN ANALOG INPUT WITH TIME OF FREEZE


Description:The 32-bit frozen analog input with time of freeze is an information object used to representa frozen hardware or software analog point. The 32-bit signed value could represent adigitized signal or calculated value.

The frozen value shows the value of the analog input at the time specified in time of freeze.

The time of freeze field shows the time at which the frozen value was equal to the currentvalue of the analog input. These values are equated on reception of a freeze analogcommand.





DNP Users Group7-10

Object Coding:

FLAG

7 0

Frozen value

31 0

Time of Freeze

47 0

SQ2 {FLAG = BS8 [0..7]Current value = I32 [0..31] <231-1..-231>Time of Freeze = UI48[0..47] <0 .. 2 48 >}



7.8 16-BIT FROZEN ANALOG INPUT WITH TIME OF FREEZE


Description:The 16-bit frozen analog input with time of freeze is an information object used torepresent a frozen hardware or software analog point. The 16-bit signed value couldrepresent a digitized signal or calculated value.

The frozen value shows the value of the analog input at the time specified in time offreeze.

The time of freeze field shows the time at which the frozen value was equal to the currentvalue of the analog input. These values are equated on reception of a freeze analogcommand.


• The over-range field indicates that the digitized signal or calculation has exceeded+215 -1 positively, or -215 negatively. The actual value field can be ignored as its valueis not defined.



DNP Users Group7-12

Object Coding:

FLAG

7 0

Frozen value

15 0

Time of Freeze

47 0

SQ2 {FLAG = BS8 [0..7]Time of freeze = UI48[0..47] <0 .. 2 48 -1>Current value = I16 [0..15] <215-1..-215>}



7.9 32-BIT FROZEN ANALOG INPUT WITHOUT FLAG


Description:The 32-bit frozen analog input is an information object used to represent a frozenhardware or software analog point. The 32-bit signed value could represent a digitizedsignal or calculated value.


Object Coding:

Frozen value

31 0

SQ2 {Current value= I32 [0..31] <231-1..-231>}


DNP Users Group7-14

7.10 16-BIT FROZEN ANALOG INPUT WITHOUT FLAG


Description:The 16-bit frozen analog input is an information object used to represent a frozenhardware or software analog point. The 16-bit signed value could represent a digitizedsignal or calculated value.


Object Coding:

Frozen value

15 0

SQ2 {Current value= I16 [0..15] <215-1..-215>}


7.11 32-BIT ANALOG CHANGE EVENT WITHOUT TIME


Description:The 32-bit analog change event without time is an information object used to represent achanged hardware or software analog point. The 32-bit signed value could represent adigitized signal or calculated value.

The current value field shows the current value of the analog input at the time ofreporting, or the last reported value from the originating device. This object will only bereported if the current value and the last reported value differ by a configurable deadbandvalue. This filtering is commonly known as deadbanding.





DNP Users Group7-16

Object Coding:

FLAG

7 0

Current value

31 0




7.12 16-BIT CHANGE EVENT WITHOUT TIME


Description:The 16-bit analog change event without time is an information object used to represent achanged hardware or software analog point. The 16-bit signed value could represent adigitized signal or calculated value.

The current value field shows the current value of the analog input at the time ofreporting, or the last reported value from the originating device. This object will only bereported if the current value and the last reported value differ by a configurable deadbandvalue. This filtering is commonly known as deadbanding.





DNP Users Group7-18

Object Coding:

FLAG

7 0

Current value

15 0




7.13 32-BIT ANALOG CHANGE EVENT WITH TIME


Description:The 32-bit analog change event with time is an information object used to represent achanged hardware or software analog point. The 32-bit signed value could represent adigitized signal or calculated value.

The current value shows the value of the analog input at the time specified in time.

The time field shows the time at which the processing caused the event.





DNP Users Group7-20

Object Coding:

FLAG

7 0

Value

31 0

Time

47 0

SQ2 {FLAG = BS8 [0..7]Time = UI48[0..47] <0 .. 2 48 -1>Value = I32[0..31] <231-1..-231>}



7.14 16-BIT ANALOG CHANGE EVENT WITH TIME


Description:The 16-bit analog change event with time is an information object used to represent achanged hardware or software analog point. The 16-bit signed value could represent adigitized signal or calculated value.

The current value shows the value of the analog input at the time specified in time.

The time field shows the time at which the processing caused the event.





DNP Users Group7-22

Object Coding:

FLAG

7 0

Value

15 0

Time

47 0

SQ2 {FLAG = BS8 [0..7]Time = UI48 [0..47] <0 .. 2 48 -1>Value = I16 [0..15] <215-1..-215>}



7.15 32-BIT FROZEN ANALOG EVENT WITHOUT TIME


Description:The 32-bit frozen analog event without time is an information object used to represent afrozen hardware or software analog point that is reported as an event. The 32-bit signedvalue could represent a digitized signal or calculated value.

The frozen value field shows the value of the analog input at the time of freeze.





DNP Users Group7-24

Object Coding:

FLAG

7 0

Frozen value

31 0

SQ2 {FLAG = BS8 [0..7]Frozen value = I32 [0..31] <231-1..-231>}



7.16 16-BIT FROZEN ANALOG EVENT WITHOUT TIME


Description:The 16-bit frozen analog event without time is an information object used to represent afrozen hardware or software analog point that is reported as an event. The 16-bit signedvalue could represent a digitized signal or calculated value.

The frozen value field shows the value of the analog input at the time of freeze.





DNP Users Group7-26

Object Coding:

FLAG

7 0

Frozen value

15 0

SQ2 {FLAG = BS8 [0..7]Frozen value = I16 [0..15] <215-1..-215>}



7.17 32-BIT FROZEN ANALOG EVENT WITH TIME


Description:The 32-bit frozen analog event with time is an information object used to represent afrozen hardware or software analog point that is reported as an event. The 32-bit signedvalue could represent a digitized signal or calculated value.

The frozen value field shows the value of the analog input at the time of a freeze.




input is not stable, and the resulting digitized value may not be correct. • The time of freeze field shows the time at which the frozen value was equal to the

current value of the analog input. These values are equated on reception of a freezeanalog command.

DNP Users Group7-28

Object Coding:

FLAG

7 0

Frozen value

31 0

Time of Freeze

47 0

SQ2 {FLAG = BS8 [0..7]Frozen value = I32 [0..31] <231-1..-231>Time of Freeze = UI48[0..47] <0 .. 2 48 -1>}



7.18 16-BIT FROZEN ANALOG EVENT WITH TIME


Description:The 16-bit frozen analog event with time is an information object used to represent afrozen hardware or software analog point that is reported as an event. The 16-bit signedvalue could represent a digitized signal or calculated value.

The frozen value field shows the value of the analog input at the time of a freeze.

The Flag field has the same meaning as previous objects with these additions:



input is not stable, and the resulting digitized value may not be correct. • The time of freeze field shows the time at which the frozen value was equal to the

current value of the analog input. These values are equated on reception of a freezeanalog command.

DNP Users Group7-30

Object Coding:

FLAG

7 0

Frozen value

15 0

Time of Freeze

47 0

SQ2 {FLAG = BS8 [0..7]Frozen value = I16 [0..15] <215-1..-215>Time of Freeze = UI48[0..47] <0 .. 2 48 -1>}



8. ANALOG OUTPUT OBJECTDEFINITIONS

This section defines the analog output data objects using the rules established in section2. DECLARATION RULES FOR INFORMATION ELEMENTS.

8.1 32-BIT ANALOG OUTPUT STATUS


Description:The 32-bit analog output status information object represents the actual value of ananalog output or software point and associated status.

The actual value field contains the current value of the analog output.

The flag field has the same meaning as previous objects.

DNP Users Group8-2

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Current value

31 0


FLAG ={On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, unlock; 1, forced>Reserved = BS1 [4] <0>Reserved = BS1 [5] <0>Reserved = BS1 [6] <0>Reserved = BS1 [7] <0>}

Narrative:This object can be returned after an analog output operation is performed in order todetermine the success of the operation.


8.2 16-BIT ANALOG OUTPUT STATUS


Description:The 16-bit analog output status information object represents the actual value of ahardware DAC analog output or software point and associated status.

The actual value field contains the current value of the analog output.

The flag field has the same meaning as previous objects.

Object Coding:

FLAG

7 6 5 4 3 2 1 0

Current value

15 0


FLAG ={On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, unlock; 1, forced>Reserved = BS1 [4] <0>Reserved = BS1 [5] <0>Reserved = BS1 [6] <0>Reserved = BS1 [7] <0>}

Narrative:This object can be returned after an analog output operation is performed in order todetermine the success of the operation.

DNP Users Group8-4

8.3 32-BIT ANALOG OUTPUT BLOCK


Description:The 32-bit analog output information object represents the desired value of a hardwareDAC analog output or software point. The value represented is merely logical, as thevalue may be scaled and/or manipulated before any output level is set.

The requested value field contains the desired value of the analog output. The actualvalue of the analog output is returned in the analog output status object.

The control status field indicates the status of the analog control operation, in the sameway that the control delay output block does. The definition of this field is the same as thecontrol relay output block.

Object Coding:

Requested value

31 0

Control Status

7 0

Requested value = I32 [0..31] <231-1..-231>Status = I8 [0..7] <0..255>

This is used in a control request/response.


8.4 16-BIT ANALOG OUTPUT BLOCK


Description:The 16-bit analog output block information object represents the desired value of ahardware DAC analog output or software point. The value represented is merely logical,as the value may be scaled and/or manipulated before any output level is set.

The requested value field contains the desired value of the analog output. The actualvalue of the analog output is returned in the analog output status object.

The control status field indicates the status of the analog control operation in the sameway as the control relay output block. The definition of this field is the same as thecontrol relay output block.

Object Coding:

Requested value

15 0

Control Status

7 0

I16 Requested value = I16 [0..15] <215-1..-215>I8 Status = I8 [0..7] <0..255>

DNP Users Group8-6


9. TIME OBJECT DEFINITIONS

This section defines the time data objects using the rules established in section 2.DECLARATION RULES FOR INFORMATION ELEMENTS.

9.1 TIME AND DATE

Data Object 50 - Variation: 01

Description:The time and date object is an information object that represents the absolute time of dayand date. This object should be used for time-synchronization.

Object Coding:

Absolute Time

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

23 22 21 20 19 18 17 16

31 30 29 28 27 26 25 24

39 38 37 36 35 34 33 32

47 46 45 44 43 42 41 40

Absolute Time= UI48 [0..47] <0..248-1, msec>

Narrative:Absolute Time is recorded as milliseconds since midnight, January 1st, 1970, at zerohours, zero minutes, zero seconds, and milliseconds.

DNP Users Group9-2

9.2 TIME AND DATE WITH INTERVAL


Description:The time and date with interval represents both an absolute time and an interval time. Theabsolute time represents a starting time (or base time), and the interval time is a positiveoffset from the base time. The interval could be applied several times to the base time inorder to specify a sequence of periodic times.

For example, this can be used to specify a sequence of times for periodic freezing ofobjects.

The absolute time field specifies the base time. This time is the real time-of-day.

The interval field specifies the periodic interval or offset from the base time.


Object Coding:

Absolute time

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

23 22 21 20 19 18 17 16

31 30 29 28 27 26 25 24

39 38 37 36 35 34 33 32

47 46 45 44 43 42 41 40

Interval

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

23 22 21 20 19 18 17 16

31 30 29 28 27 26 25 24

SQ2 {Absolute time = UI48 [0..47] <0..248 -1, msec>Interval = UI32 [0..31] <0..232-1, msec>}

Narrative:Absolute time is recorded as milliseconds since midnight, January 1st, 1970, at zerohours, zero minutes, zero seconds, and milliseconds.

DNP Users Group9-4

9.3 TIME AND DATE CTO


Description:The time and date CTO (common time of occurrence) object is an information object thatrepresents the absolute time of day. This object should be used in conjunction with otherobjects that contain time references. This object is a base time to which a relative(incremental) time can be added, or from which it can be subtracted, in order to obtainanother absolute time reference.

Object Coding:

Absolute Time

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

23 22 21 20 19 18 17 16

31 30 29 28 27 26 25 24

39 38 37 36 35 34 33 32

47 46 45 44 43 42 41 40

Absolute time = UI48 [0..47] <0..248-1, msec>

Narrative:Absolute time is recorded as milliseconds since midnight, January 1st, 1970, at zerohours, zero minutes, zero seconds, and milliseconds.


9.4 UN-SYNCHRONIZED TIME AND DATE CTO


Description:The un-synchronized time and date CTO object is an information object that representsthe relative-absolute time of day. This object should be used in conjunction with otherobjects that contain time references. This object is a relative base time to which a relative(incremental) time can be added, or from which it can be subtracted, in order to obtainanother relative-absolute time reference. The real absolute time can be calculated by themessage receiver, based on the reception time of the message containing this object. Anyobjects that follow this object, and come before the next common-time object thatcontains relative time, must be corrected using this relative-absolute time value.

Relative-absolute time is the un-synchronized time-of-day at the station sending thisobject (i.e. the responding station).

Object Coding:

Relative Absolute Time

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

23 22 21 20 19 18 17 16

31 30 29 28 27 26 25 24

39 38 37 36 35 34 33 32

47 46 45 44 43 42 41 40

Relative-absolute time = UI48 [0..47] <0..248-1, msec>

Narrative:Relative-absolute time is recorded as milliseconds since midnight, January 1st, 1970, atzero hours, zero minutes, zero seconds, and milliseconds.

DNP Users Group9-6

9.5 TIME DELAY COARSE


Description:The time delay coarse information object represents a relative time that indicates a timeperiod starting from the time of message reception.

Object Coding:

Seconds

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

Seconds = UI16 [0..15] <0..65,535, seconds>


9.6 TIME DELAY FINE


Description:The time delay fine information object represents a relative time that indicates a timeperiod starting from the time of message reception. This object can be used in time-synchronization to perform path delay measurement calculations or other functions thatrequire time-based calibration.

Object Coding:

Milliseconds

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

Milliseconds = UI16 [0..15] <0..65,535, milliseconds>

DNP Users Group9-8


10. CLASS OBJECT DEFINITIONS

This section defines the class data objects using the rules established in section 2.DECLARATION RULES FOR INFORMATION ELEMENTS.

10.1 CLASS 0 DATA


Description:The class 0 data object is an object place-holder that specifies a class of zero or moreinformation elements. These elements can be entire object types, a specific variation,certain points of the variation, or any combination of these. The data specified by thisobject type is configurable within the responding station.

Class 0 data is potentially any information object not assigned to class 1, 2, or 3. That is,class 0 data is non-priority data.

Object Coding:None.

Narrative:The class 0 data object does not carry any information in itself, and therefore does nothave an object coding. Class 0 is a null class to which all data objects not assigned toother classes can belong by default.

DNP Users Group10-2

10.2 CLASS 1 DATA



The responding station does not send the class 1 data object, as it does not contain anyactual information, but is simply an identifier for other objects.

Object Coding:None.

Narrative:The class 1 data object is used to request a configured group, usually changes, ofinformation objects from a responding station. This data object does not carry anyinformation in itself, and therefore does not have an object coding.

Typically, class 1 data has higher priority than class 2, class 3, and class 0 data.


10.3 CLASS 2 DATA




Object Coding:None.

Narrative:The class 2 data object is used to request a configured group, usually changes, ofinformation objects from a responding station. This data object does not carry anyinformation in itself, and therefore does not have an object coding.

DNP Users Group10-4

10.4 CLASS 3 DATA




Object Coding:None.

Narrative:The class 3 data object is used to request a configured group, usually an event, ofinformation objects from a responding station. The data object does not carry anyinformation in itself, and therefore does not have an object coding.


11. FILE OBJECT DEFINITIONS

This section defines the file data objects using the rules established in section 2.DECLARATION RULES FOR INFORMATION ELEMENTS.

11.1 FILE IDENTIFIER


Description:The file identifier object is an information object that represents information about a filein a network file system. This object is intended to be used for transferring large blocks ofdata that do not follow the format of an existing data object. In particular, this object issuitable for uploading and downloading configuration files to remote devices or dataconcentrators.

File operations are defined for this object to allow copying, deleting, etc. of a file. Thecontents of the file object and the exact procedure to perform on the file will not beinterpreted by the Application Layer, and so must be performed by the user of theApplication Layer.

Networking Capability:The File_Name field defines a logical name of a file or device. The receiving applicationshould interpret this name as a network file name. The root (or /) represents the root ofthe host file system or receiving node. Sub-directories off of the root are interpreted asbranches off of the root. A branch can be a new directory, or more importantly, thedirectory can be a remote file system which resides in a remote device that is accessiblefrom the current node.

When an application receives a file that specifies a directory or file that does not reside inthe current file system, the application must do whatever is necessary to obtain the filefrom the specified device.

If the remote device is a DNP 3 device, then the following rules apply:

• On reception of a non-local file request, the application shall forward the request (in itsentirety) to the appropriate DNP 3 device.

DNP Users Group11-2

• The File_Name field will be modified so that the root of the remote device is specifiedby the File_Name field. This means stripping off any paths that were used to actuallyderive the name of the remote device.

For example, an IED configuration is sent from a host through two data concentratorsDC1 and DC2. The name from the Host to DC1 is:

\DC2\IED\config1

The name from the DC1 to DC2 is:

\IED\config1

The name from the DC2 to IED is:

\config1

In this case DC2 and IED were logical directories which specified remote devices andconfig1 was the name of a physical file.

Object Coding:This is not a fixed format object, but it is a variable format/sized object. This part of theobject is sent in a request.

31 24 23 16 15 8 7 0

Attributes File_Type Name_Size

End_Record Start_Record

File_Size

Time_Of_Creation

Permission

File_ID

Owner_ID

Group_ID

Status File_Function

X File_Name 0


The File_Name field consists of 0 .. x bits where x = Name_Size * 8 and Name_Size = 0 ..65535.

The file identifier object is sent in a DNP application request message to a remote deviceusing the Application Layer WRITE request function code. A device responds to a request(or spontaneously reports) the file identifier object with an Application Layer RESPONSEor UNSOLICITED RESPONSE function code (where appropriate).

File_Name: Name of file to perform operation on. Consists of 1 or more of thecharacters A .. Z, a..z, 0 .. 9, ".", "_", "\" and "-" ONLY, where " isa delimiter, and where the hyphen cannot be used as the firstcharacter of the file name. The size of this field is determined bythe Name_Size field below. The name can contain all pathinformation starting from the root (i.e. "\" of the file system. Thename can contain spaces ONLY to separate the file path/namefrom program arguments.

Name_Size: Number of characters in File_Name above.

File_Function: Function to perform on specified records of file or on file system atuser layer. Includes the following: APPEND, DELETE, INSERT,WRITE, ERASE, INFO, CWD, PWD, EXECUTE and READ. Thefollowing values are defined:

0 = APPEND: Add data records specified at END of file. TheStart_Record field indicates the number of records toappend to the file and also the number of data recordsfollowing the file identifier header in the message. The datarecords that follow the header are described in the WRITEfunction code (below). The device should respond with thefile identifier object with all available fields filled in, theFile_Function field set to RESPONSE, and the status fieldset to the status of the requested operation.

1 = DELETE: Remove the specified records from the file (i.e. fileshrinks). The Start_Record indicates the first record todelete and the End_Record indicates the last record todelete. There are no data records with this request. Thedevice should respond with the file identifier object with allavailable fields filled in, the File_Function field set toRESPONSE, and the status field set to the status of therequested operation.

DNP Users Group11-4

2 = INSERT: Insert these records at the place specified by theStart_Record field and continuing to End_Record field (i.e.the file grows in size). The number of data recordsfollowing the file identifier header in the message isEnd_Record - Start_Record + 1. The data records thatfollow the header are described in the WRITE function code(below). The device should respond with the file identifierobject with all available fields filled in, the File_Functionfield set to RESPONSE, and the status field set to the statusof the requested operation.

3 = WRITE: Place these records at the place specified by Start_Recordfield and continuing to End_Record field (i.e. the file canpotentially grow, and previous data is replaced by theserecords). The number of data records following the fileidentifier header in the message is End_Record -Start_Record + 1. The data records that follow the headerare described below. The device should respond with thefile identifier object with all available fields filled in, theFile_Function field set to RESPONSE, and the status fieldset to the status of the requested operation.

Datax 0

Record_Size15 0

Where: x = Record_Size * 8Record_Size = 0 .. 65535

4 = ERASE: Clear (to NUL) or ERASE all records specified in Start andEnd record fields (i.e. the file stays same size, BUT data iscleared). There are no data records in this message. Thedevice should respond with the file identifier object with allavailable fields filled in, the File_Function field set toRESPONSE, and the status field set to the status of therequested operation.


5 = INFO: This request is used to obtain INFORMATION on thespecified file. The device should respond with the fileidentifier object header with all fields filled in, theFile_Function set to RESPONSE and the status field set tothe status of the requested operation. The File_Name fieldcan be set to the special name "/" which indicates ALLfiles. The device should respond with file identifier objectheaders for each file in the device's file system. If thedevice has only one file (and no directories) then this onefile's file identifier object header should be returned.

6 = CWD: Change working directory (CWD) to path specified inFile_Name. The device should respond with the fileidentifier object with all available fields filled in, theFile_Function field set to RESPONSE, the File_Name fieldset to the new working directory, and the status field set tothe status of the requested operation.

7 = PWD: Return the present working directory (PWD) in File_Name.The device should respond with the file identifier objectwith all available fields filled in, the File_Function field setto RESPONSE, the File_Name field set to the currentworking directory, and the status field set to the status ofthe requested operation.

8 = EXEC: Start or EXECUTE the application specified by File_Nameand pass it parameters that follow the file name portion ofFile_Name (separated by spaces). The device shouldrespond with the file identifier object with all availablefields filled in, the File_Function field set to RESPONSEand the status field set to the status of the requestedoperation.

DNP Users Group11-6

9 = READ: Read the specified records of file. The Start_Recordspecifies the first record to READ, and the End_Recordspecifies the last record to READ. If the Start_Record fieldis 0, and the End_Record field is 65535, then the deviceshould respond with all available records. The File_Sizefield in the response should indicate the total size of thefile. The device should respond with the file identifierobject with all available fields filled in, and all requesteddata records (if possible), the File_Function field set toRESPONSE, the Start_Record and End_Record should beset to the beginning and end data records returned in theresponse, and the status field set to the status of therequested operation. The number of data records followingthe file identifier header in the message is End_Record -Start_Record + 1. The data records that follow the headerare described above under the WRITE function code.

255 = RESP: This function code is used to indicate a response to arequest. The contents of this message are defined by thefunction code in the request message.

Permission: The permission field specifies the READ, WRITE, and EXECUTEprivileges for the file owner, the file owner's group and the world(all others). The READ privilege gives the user the right to read thefile (READ, PWD, CWD, INFO request). The WRITE privilegegives the user the right to change the file (APPEND, DELETE,INSERT, WRITE, ERASE). The EXECUTE privilege gives the userthe right to run the specified application (EXEC request).

File_Type: Indicates to a receiving application how to interpret the contents ofthe file object. Valid types are: 8-bit binary, 8-bit ASCII, 7-bitASCII, EBCDIC, BCD, Baudot, International Baudot. Thefollowing values are associated:

0 = 8-bit binary (un-coded octets of binary)1 = 8-bit ASCII (extended ASCII characters)2 = 7-bit ASCII (ASCII characters)3 = EBCDIC (extended binary coded decimal)4 = BCD (binary coded decimal)5 = Baudot (5-bit Baudot)6 = International Baudot (6-bit Baudot)


Attributes: File attributes consisting of: regular, temporary, directory, orFIFO. The following values are associated:

0: Regular file is a real PERMANENT file.

1: Temporary file is TEMPORARY and MUST be saved if changes are to bekept.

2: Directory is a file of files (cannot be read).

3: FIFO is a first-in-first-out queue and can be used for inter-processcommunication (analogous to a socket or pipe).

Status: The status of the requested operation, consisting of: OK,Doesn't_exist, Out_of_Space, No_Permission and File_Busy. Thefollowing values are associated:

0: OK indicates that the requested operation was successful.

1: Doesn't_exist indicates that the file name is not contained in the filesystem.

2: Out_of_Space indicates that the file operation caused the file to exceed itsmaximum size as determined by the User ID, Group ID, and Permission.

3: No_Permission indicates that the file owner does not have enoughprivileges for the operation requested.

4: File_Busy indicates that the file could not be delivered to the destination.

File_Size: Number of total bytes in file specified by File_Name.

Start_Record: The start record number of file. A start record of 0 indicates thestart of the file, and a start record of 65535 indicates the lastrecord.

End_Record: The end record number of file, similar to the Start_record. An endrecord of 65535 combined with a start record of 0 in a READrequest indicates the entire file.

Record_Size: Size in bytes of each individual data record excluding Record_Sizefield.

Time_of_Creation: Time that the file was created or last modified. This field has thesame format as Object 50 Variation 1.

DNP Users Group11-8

Owner_ID: Unique identifier for the owner of the file.

Group_ID: Unique identifier for the owner's group.

File_ID: Unique integer identifier for the file. This field can also be used tohold the error check (typically 16-bit CRC) for the file. In this case,the File_ID is only unique when concatenated with the File_Nameand the Time_Of_Creation.

Data: Actual data bytes that make up the file record. These 8-bit objectsare interpreted according to the File_Type field. The contents ofthe Data field will not be interpreted by the DNP ApplicationLayer.


12. DEVICE OBJECT DEFINITIONS

This section defines the device data objects using the rules established in section 2.DECLARATION RULES FOR INFORMATION ELEMENTS.

12.1 INTERNAL INDICATIONS


Description:The internal indications is an information element used to convey internal states anddiagnostic results of a responding station. This information can be used by a receivingstation to perform error recovery or other functions.

The number of internal indications objects sent in a message is device-dependent.

Object Coding:

0

BS1 [0..0]State = BS1 [0] <0,1>

Narrative:Transmission of the data object is always performed in complete octets, with unoccupiedbit positions set to zero. The following example illustrates the packing of n of these dataobjects.

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

0 0 0 n n-1 n-2 n-3 n-4

DNP Users Group12-2

12.2 STORAGE OBJECT


Description:The storage object is an information element used to convey the status of internal buffersand storage areas for specific data types.

The group field indicates the group (or data type) that the status field corresponds to.

The variation field indicates the variation of the object that the status field correspondsto.

The group and variation fields together specify the exact data type.

The status field shows what percentage of the buffer space allocated for this data type iscurrently used up. The overflow bit indicates that the buffer space for the specified datatype has been over-utilized, and data objects have been lost.


Object Coding:

STATUS

7 6 5 4 3 2 1 0

GROUP

7 0

VARIATION

7 0

Storage Object ={Status = BS8 [0..7]Group = UI8 [0..7] <0..255>Variation = UI8 [0..7] <0..255>}

Status ={Percent = BS7 [0..6] <0..100>Overflow = BS1 [7] <0, 1; Overflow>}

Narrative:The storage object is used to indicate the status of buffer, queues, or other storage areaswithin the sending device. The object is generated by the device as configured in thedevice and described in the particular device profile.

DNP Users Group12-4

12.3 DEVICE PROFILE


Description:The device profile object provides for inter-operability between different DNP deviceswhich use only a sub-set of the DNP Application Layer function codes and data objects.This object describes the station acting as a DNP master, and the valid function codes andobjects that the slave device supports. In addition, the range of indices for eachobject/variation is also given so that configuration can be done on a dynamic basis.

Principle of operation:The device profile object is intended to be sent by a slave device ONLY when the requestsent by the master is not recognizable, un-parsable, or objects referenced in the requestare not supported. Coincident with this message would be internal indications indicatinga problem with parsing.

Alternately, if the slave is configured in a quiescent environment, the slave could report(spontaneously) the device profile object upon start-up.

The master, upon reception of this object, can change its polling scheme, poll requestmessage, limit or expand the assumed functionality of the slave, or re-configure themaster database with objects specified in this object.

If the master station is less sophisticated, the slave station can be marked off-line, andmanual re-configuration would be necessary to obtain proper communications again.

The device profile object consists of two sections. The first section, functions, specifiesthe supported DNP Application Layer function codes. The second section, objects,specifies the range of indices valid for each object/variation combination. Essentially, theobjects section is a sample master poll object header for each object/variation. It isimplied by the type of object what type of operation (function) can be performed on it sothere is no need to map each function code to a set of objects.

The functions field is an array of bits indicating support or non-support for each functioncode. The bit positions 0 .. 63 correspond to DNP Application Layer function codes 0 to63. For request function codes beyond 63, another functions field can follow theObjectHeaders.

The NumObjects field specifies how many sample object headers follow.

The ObjectHeader fields have the same form as a DNP Application Layer object header.As a minimum, the header consists of the object, variation, qualifier, and 8-bit quantity.This means that to describe most object variations, only four bytes are needed.


Object Coding:

Functions63 0

NumObjects (n)15 0

ObjectHeader 1

Quantity7 0

Qualifier7 0

Variation7 0

Object7 0

ObjectHeader 2

Quantity7 0

Qualifier7 0

Variation7 0

Object7 0

ObjectHeader n

Quantity7 0

Qualifier7 0

Variation7 0

Object7 0

SQ2 {Functions = BS64 [0..63]NumObjects = UI16 [0.15] <0..65535>}

Each object header that follows has a variable format determined by the rules forconstructing Application Layer object headers.

Some sample headers are:

Object Header =SQ4 {

Object = UI8 [0..7] <0..255>Variation = UI8 [0..7] <0..255>Qualifier = UI8 [0..7] <0..255>Quantity = UI8 [0..7] <0..255>}

DNP Users Group12-6


Object = UI8 [0..7] <0..255>Variation = UI8 [0..7] <0..255>Qualifier = UI8 [0..7] <0..255>Start = UI8 [0..7] <0..255>Stop = UI8 [0..7] <0..255>}


Object = UI8 [0..7] <0..255>Variation = UI8 [0..7] <0..255>Qualifier = UI8 [0..7] <0..255>Start = UI16 [0..15] <0..65535>Stop = UI16 [0..15] <0..65535>}


12.4 PRIVATE REGISTRATION OBJECT

Data Object 83 - Variation: 01 Type: Static\Event\Frozen Static\Frozen Event

Description:This private registration object (PRO) object type is reserved for vendor-specificdefinition. The object consists of a fixed header to provide for transparent data transfer,and a unique registration number of the following object. The description of the contentsis entirely at the discretion of the vendor.

The Vendor field is a four-byte ASCII vendor name.

The Private Registration Number (PRN) field is a vendor designated object I.D.

The Len field contains the length of the Data Objects field in octets.

The Data Objects field contains the vendor's data (variable size and format) as describedby the PROD object.

Object Coding:

VENDOR

31 0

PRN 0

15

LEN

15 0

DATA OBJECTS

0

SQx {Vendor = U132 [0..232-1]PRN = U116[0..216-1]LEN = U116 [0..216-1] Length of objects in <octets>SQn = sequence of n basic DNP objects}

DNP Users Group12-8

12.5 PRIVATE REGISTRATION OBJECT DESCRIPTOR


Description:This object type is reserved for vendor private registration object description. The objectis matched one-to-one with its PRO object. The object consists of a fixed header toprovide for transparent data transfer, and a unique registration number of the followingobject. The description of the contents is entirely at the discretion of the vendor.

The private registration object description (PROD) object maintains a one-to-onerelationship with the PRO object, and can be used to parse the PRO into basic DNPObjects for processing. The PROD consists of one element for each correspondingelement of the PRO. Each element consists in turn of a set of DNP object and variationnumbers.

The Vendor field is a four-byte ASCII vendor name.

The Private Registration Number (PRN) field is a vendor designated object I.D.

The Count field specifies the number of object definitions that follow this field. Eachobject definition consists of the three fields: quantity, object and variation.

The Quantity field specifies the number of objects, specified by the object and variationfields, which will be found in the PRO object.


Object Coding:

VENDOR31 0

PRN15 0

COUNT15 0

QUANTITY15 0

OBJECT7 0

VARIATION7 0

QUANTITY15 0

OBJECT7 0

VARIATION7 0

QUANTITY15 0

OBJECT7 0

VARIATION7 0

SQx {Vendor = UI32 [0..232-1]PRN = UI16 [0..216-1]COUNT = UI16 [0..216-1]SQn = Sequence of n basic DNP object definitions

{ Object = U18 [0..28-1]Variation = U18 [0..28-1]Quantity = U18 [0..216-1]

}}

DNP Users Group12-10

The following illustrations serve as examples for more clarification:

PROD:

(blank) B B A

0 16

0 3

2

1

2

2

21

2

5

30

1

In the above example:• B, B, and A, represent the vendor name.• PRN is private object #16 for vendor A B B.• Count specifies that three definitions follow, with each definition consisting of

quantity, object, and variation.


The corresponding PRO object is:

(blank) B B A

0 16

0 33

binary input1

binary input2

Counter 1

Counter 2

Analog 1

Analog 2

Analog 3

Analog 4

Analog 5


13. APPLICATION OBJECTDEFINITIONS

This section defines the application data objects using the rules established in section 2.DECLARATION RULES FOR INFORMATION ELEMENTS.

13.1 APPLICATION IDENTIFIER


Description:The application identifier object is an information object used to represent an applicationor operating system process within a device. This object is used in conjunction with theapplication functions of the application layer to control software applications.

This object has no defined format and is simply used as a place holder. The free-formatqualifier of the application layer should be used to identify the application in question, orif the application is unknown, the ALL qualifier should be used to specify all relevantapplications.

DNP Users Group13-2


14. ALTERNATE NUMERIC OBJECTDEFINITIONS

This section defines the alternate or custom numeric representation data objects using therules established in section 2. DECLARATION RULES FOR INFORMATIONELEMENTS.

14.1 SHORT FLOATING POINT


Description:The short floating point information object represents a calculated or measured scientificvalue. The format of this object complies with the IEEE-754 standard for floating-pointnumber representation.

The value field holds the actual floating point number and follows the format for a shortreal as specified by the IEEE-754 standard.

The flag field holds information about the point and has the same meaning as previousobjects.

The units field determines the units of the value field. This is the scientific or engineeringunits associated with the measured or calculated quantity.

DNP Users Group14-2

Object Coding:

Units7 0

Flag7 0

Value

Sign0 0

Exponent7 0

Significant22 0

FLAG ={On-line = BS1 [0] <0, off-line; 1, on-line>Restart = BS1 [1] <0, normal; 1, restart>Communication lost = BS1 [2] <0, normal; 1, lost>Remote forced data = BS1 [3] <0, normal; 1, forced>Local forced data = BS1 [4] <0>Over-range = BS1 [5] <0, normal; 1, over-range>Reference check = BS1 [6] <0, normal; 1, error>Reserved = BS1 [7] <0>}

Narrative:The absolute value can be derived from the value field as follows:

Absolute_Value = 1.s0 s1 s2 s3 s4 .. s22 x 2 (Exp -127)

where: si = Significant[i..i] and Exp= Exponent[0..7]

Sign: 0 if number is positive, and 1 if the number is negative.Exponent: Power of 2 applied to 1. Significant.Significant: Significant binary digits in value.


The units field has the following defined values:0: Volts p-p (peak-to-peak voltage)1: Amperes p-p (peak-to-peak current)2: Volts RMS3: Amperes RMS4: KW or kilowatts (real power or volt-amps resistive)5: KVA or kilo volt-amps (volt-amps total)6: KVAR or kilovars (imaginary power or volt-amps reactive)7: KwH (kilowatt hours)8: KVARH (kiloVAR hours)9: PF (power factor)10: Hz (frequency in cycles per second)11: w (frequency in radians)12: C (degrees Celsius)13: F (degrees Fahrenheit)14: K (degrees Kelvin)15: N (force in Newtons)16: kg (mass in kilograms)17: m/s2 (acceleration)18: N/m2 (pressure in Newtons per square meter)19: N*m (torque in Newton-meters)

DNP Users Group14-4

14.2 LONG FLOATING POINT


Description:The long floating point information object represents a calculated or measured scientificvalue. The format of this object complies with the IEEE-754 standard for floating-pointnumber representation.

The value field holds the actual floating point number and follows the format for a longreal as specified by the IEEE-754 standard.



Object Coding:

Units7 0

Flag7 0

Value

Sign0 0

Exponent10 0

Significant51 0


DNP Users Group14-6

14.3 EXTENDED FLOATING POINT


Description:The extended floating point information object represents a calculated or measuredscientific value. The format of this object complies with the IEEE-754 standard forfloating-point number representation.

The value field holds the actual floating point number and follows the format for a tempreal as specified by the IEEE-754 standard.



Object Coding:

Units7 0

Flag7 0

Value

Sign0 0

Exponent14 0

Significant63 0


DNP Users Group14-8

14.4 SMALL-PACKED BINARY CODED DECIMAL


Description:The small-packed binary coded decimal information object represents a sequence of BCDdigits. Each BCD digit can represent a variety of information from control outputs toanalog inputs.

Object Coding:

Digit 43 0

Digit 33 0

Digit 23 0

Digit 13 0

SPBCD = SQ4 {Digit1 = UI4 [0..3] <0..10>Digit2 = UI4 [0..3] <0..10>Digit3 = UI4 [0..3] <0..10>Digit4 = UI4 [0..3] <0..10>}


14.5 MEDIUM-PACKED BINARY CODED DECIMAL


Description:The medium-packed binary coded decimal information object represents a sequence ofBCD digits. Each BCD digit can represent a variety of information from control outputsto analog inputs.

Object Coding:

Digit 43 0

Digit 33 0

Digit 23 0

Digit 13 0

Digit 83 0

Digit 73 0

Digit 63 0

Digit 53 0

MPBCD = SQ8 {Digit1 = UI4 [0..3] <0..10>Digit2 = UI4 [0..3] <0..10>Digit3 = UI4 [0..3] <0..10>Digit4 = UI4 [0..3] <0..10>Digit5 = UI4 [0..3] <0..10>Digit6 = UI4 [0..3] <0..10>Digit7 = UI4 [0..3] <0..10>Digit8 = UI4 [0..3] <0..10>}


14.6 LARGE-PACKED BINARY CODED DECIMAL


Description:The large-packed binary coded decimal information object represents a sequence of BCDdigits. Each BCD digit can represent a variety of information from control outputs toanalog inputs.

Object Coding:

Digit 43 0

Digit 33 0

Digit 23 0

Digit 13 0

Digit 83 0

Digit 73 0

Digit 63 0

Digit 53 0

Digit 123 0

Digit 113 0

Digit 103 0

Digit 93 0

Digit 163 0

Digit 153 0

Digit 143 0

Digit 133 0

LPBCD = SQ16 {Digit1= UI4 [0..3] <0..10>Digit2= UI4 [0..3] <0..10>Digit3= UI4 [0..3] <0..10>Digit4= UI4 [0..3] <0..10>Digit5= UI4 [0..3] <0..10>Digit6= UI4 [0..3] <0..10>Digit7= UI4 [0..3] <0..10>Digit8= UI4 [0..3] <0..10>Digit9= UI4 [0..3] <0..10>Digit10= UI4 [0..3] <0..10>Digit11= UI4 [0..3] <0..10>Digit12= UI4 [0..3] <0..10>Digit13= UI4 [0..3] <0..10>Digit14= UI4 [0..3] <0..10>Digit15= UI4 [0..3] <0..10>}

DNP V3.00 Data Object Library (Version 0.02) 1


ASCII American Standard Code for Information Interchange

BCD binary coded decimalBINBS bit string

CRC cyclic redundancy checkCTO common time objectCTO common time of occurrenceCWD change working directory

DA distributed automationDAC data acquisition and controlDNP Distributed Network Protocol

EBCDIC extended binary coded decimalEXEC execute

F fixed pointFIFO first-in-first-out

I integerID identificationIEC International Electrotechnical CommissionIEEE Institute of Electrical and Electronics Engineers

LEN lengthLPBCD large-packed binary coded decimal

MPBCD medium-packed binary coded decimalMSEC millisecond

OS octet string

DNP Users Group2

PCB pattern control blockPRN private registration numberPRO private registration objectPROD private registration object descriptionPWD (return to) present working directory

R realRESP responseRMS root mean squared

SCADA supervisory control and data acquisitionSPBCD small-packed binary coded decimal

UF unsigned fixed pointUI unsigned integer

DNP V3.00

SUBSET DEFINITIONS

Document Number: P009-0IG.SUB

Version: 2.00 Date: November, 1995

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

The DNP Users Group 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 the DNP Users Group. An update program for DNP documents is provided upon request by the DNP Users Group.

TRADEMARK NOTICES DNP is a trademark of the DNP Users Group. Any brand and product names mentioned in this document are trademarks or registered trademarks of their respective companies.

MODIFICATION RECORD VERSION

DATE

INITIALS

COMMENT

0.01

94.09.20

GG/PM

Changes from Aug 19 review.

0.02

95.06.08

GG

Changes from Jan 1995 DNP Users Group meeting and May 30 review.

1.00

95.07.12

GG

Changes due to comments from the DNP Users Group Technical Committee.

2.00

95.11.29

ST

Changes to delete Harris references.

DNP Users Group P009-0IG.SUB, Version 2.00 ii

T ABLE OF CONTENTS

ABOUT THIS GUIDE ...........................................................................vi PURPOSE OF THIS GUIDE .............................................................vi WHO SHOULD USE THIS GUIDE.................................................vi ADDITIONAL DOCUMENTATION...............................................vi HOW THIS GUIDE IS ORGANIZED ............................................ vii CONVENTIONS USED IN THIS GUIDE.................................... viii

OVERVIEW ........................................................................................... ix TERMINOLOGY............................................................................... ix READING THE SUBSET TABLES ....................................................x GOALS AND ASSUMPTIONS........................................................ xii

Chapter 1: LEVEL 1 DNP V3.00 IMPLEMENTATION (DNP - L1)..... 1 1.1 INTENDED USE........................................................................ 1 1.2 GENERAL DESCRIPTION ....................................................... 1 1.3 IMPLEMENTATION TABLE .................................................... 2

Chapter 2: LEVEL 2 DNP V3.00 IMPLEMENTATION (DNP-L2)....... 1 2.1 INTENDED USE........................................................................ 1 2.2 GENERAL DESCRIPTION ....................................................... 1 2.3 IMPLEMENTATION TABLE .................................................... 1

Chapter 3: LEVEL 3 DNP V3.00 IMPLEMENTATION (DNP - L3)..... 1 3.1 INTENDED USE........................................................................ 1 3.2 GENERAL DESCRIPTION ....................................................... 1 3.3 IMPLEMENTATION TABLE .................................................... 2

Chapter 4: IMPLEMENTATION RULES AND RECOMMENDATIONS.................................................................................................................. 1

4.1 ERROR RESPONSES................................................................. 1 4.1.1 Rules ..................................................................................... 1

4.2 DATA CLASSES AND EVENTS ............................................... 2 4.2.1 Rules ..................................................................................... 2 4.2.2 Recommendations................................................................ 4

4.3 SLAVE DEVICE START-UP...................................................... 5 4.3.1 Rules ..................................................................................... 5 4.3.2 Recommendations................................................................ 6

4.4 UNSOLICITED RESPONSES ................................................... 6 4.4.1 Rules ..................................................................................... 6

4.5 OPERATING BINARY OUTPUTS........................................... 7 4.5.1 Rules ..................................................................................... 7 4.5.2 Recommendations................................................................ 7

DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00 iii

4.6 FRAGMENTS AND FRAMES ................................................... 8 4.6.1 Rules ..................................................................................... 8 4.6.2 Recommendations ................................................................ 8

4.7 MULTIPLE OBJECTS IN A SINGLE REQUEST..................... 9 4.7.1 Rules ..................................................................................... 9

4.8 MULTIPLE OBJECTS IN A SINGLE RESPONSE ................... 9 4.8.1 Rules ..................................................................................... 9

4.9 CONFIRMATION AND RETRIES ........................................... 9 4.9.1 Rules ..................................................................................... 9 4.9.2 Recommendations .............................................................. 10

4.10 WITH-FLAG AND WITHOUT-FLAG VARIATIONS......... 11 4.10.1 Rules ................................................................................. 11

4.11 16-BIT AND 32-BIT VARIATIONS ....................................... 12 4.11.1 Rules ................................................................................. 12 4.11.2 Rules for Analog Inputs and the OVER-RANGE Flag ....12 4.11.3 Rules for Counter Objects and the ROLL-OVER Flag....14 4.11.4 Recommendations Regarding the ROLL-OVER Flag...... 14

4.12 TIME TAGGED BINARY INPUT EVENTS ......................... 15 4.12.1 Rules ................................................................................. 15 4.12.2 Recommendations ............................................................ 15

4.13 FREEZE OPERATIONS ......................................................... 15 4.13.1 Rules ................................................................................. 16 4.14.1 Rules ................................................................................. 16

Chapter 5: CONFORMANCE................................................................ 1 5.1 SLAVE DEVICES........................................................................ 1 5.2 MASTER DEVICES.................................................................... 2

Appendix A: DEVICE PROFILE DOCUMENT FORMAT.................. 1 GLOSSARY OF TERMS......................................................................... 8 LIST OF ACRONYMS AND ABBREVIATIONS ............................... 10

DNP Users Group P009-0IG.SUB, Version 2.00 iv

LIST OF TABLES

Table 1 Qualifiers Used in the Subset Definitions ............................ xiii Table 1.3-1 Level 1 Implementation (DNP-L1) ...................................3 Table 2.3-1 Level 2 Implementation (DNP-L2) ...................................2 Table 3.3-1 Level 3 Implementation (DNP-L3) ...................................2 Table 4.1-1 Valid Error Responses ......................................................2 Table 4.11-1 Examples of Over-Range Conditions and Values........... 13

DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00 v

ABOUT THIS GUIDE

PURPOSE OF THIS GUIDE

This document defines the implementation subsets, or levels, defined for the Distributed Network Protocol (DNP) V3.00 Application Layer. It is intended to be used as a reference for determining compatibility between implementations of the DNP V3.00 Application Layer. It also briefly discusses some compatibility issues with respect to the DNP V3.00 Data Link Layer and Transport Function.

This document describes several subsets of the protocol, for the purpose of giving vendors and customers a common set of terms for describing what they have implemented and what they require, respectively.

WHO SHOULD USE THIS GUIDE

This guide is intended to be used by the following people, although its audience is not necessarily limited to those listed here:

• Designers responsible for determining what portion of the protocol to implement.

• Systems engineers responsible for determining compatibility between components of a network.

• Purchasing agents or certification agencies responsible for determining whether a vendor's product meets customers' standards.

ADDITIONAL DOCUMENTATION

If you require more detail than this document provides, several supporting texts are available. These include:

• Distributed Network Protocol 3.0 Basic 4-Document Set including:

- DNP V3.00 Data Link Layer (P009-0PD.DL) Version 0.02 - DNP V3.00 Transport Functions (P009-0PD.TF) Version 0.01

DNP Users Group P009-0IG.SUB, Version 2.00 vi

- DNP V3.00 Application Layer (P009-0PD.APP) Version 0.03 - DNP V3.00 Data Object Library (P000-0BL) Version 0.02

HOW THIS GUIDE IS ORGANIZED

The organization of this guide is described below. Each chapter of the guide describes one subset of the DNP V3.00 Application Layer protocol.

OVERVIEW describes basic concepts concerning DNP subsets: basic terminology, how to interpret the implementation tables, and the duties of devices implementing the subsets. It briefly discusses the goals used to develop the subsets.

Chapter 1: LEVEL 1 DNP V3.00 IMPLEMENTATION (DNP-L1) describes the minimum subset of the protocol that can be implemented, typically between a master station and an Intelligent Electronic Device (IED).

Chapter 2: LEVEL 2 DNP V3.00 IMPLEMENTATION (DNP-L2) describes a subset of the protocol, slightly larger than Level 1. It is typically implemented between a master station and a large IED or small Remote Terminal Unit (RTU).

Chapter 3: LEVEL 3 DNP V3.00 IMPLEMENTATION (DNP-L3) describes a subset of the protocol, larger than Level 2, that can be implemented between a master station and a more advanced RTU.

Chapter 4: IMPLEMENTATION RULES AND RECOMMENDATIONS describes rules and recommendations applying to all levels of DNP V3.00 implementation.

Chapter 5: CONFORMANCE describes the conditions under which a device is said to conform to a given DNP subset.

Appendix A: DEVICE PROFILE DOCUMENT FORMAT describes the information a device vendor must include in a document describing a device's implementation of DNP V3.00

DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00 vii

CONVENTIONS USED IN THIS GUIDE

There are a few formatting conventions used in this guide to make it easier to read and understand. They are listed below.

• New or special terms are highlighted in bold text.

• Chapter references are highlighted in bold text, with the chapter title in CAPITAL LETTERS (for example, Chapter 2: SPECIAL REQUIREMENTS). Table names are also bold (e.g. AXXX_CFG).

• References to main section titles are highlighted using italics, as are book and document titles, and words used with special emphasis.

• Lists of procedural instructions are numbered in the order they are to be performed. Other lists of information are bulleted, like this list.

• Specific function and field names are in CAPITAL LETTERS, but not bold (e.g. TRIP function, GROUP ADDRESS field).

DNP Users Group P009-0IG.SUB, Version 2.00 viii

OVERVIEW

This section describes various concepts concerning DNP V3.00 protocol subsets in general.

TERMINOLOGY

This section defines some of the terms used throughout this document.

When a Master or Slave satisfies all the requirements of a particular DNP V3.00 subset, it is said to implement a particular level of the protocol. The term "Level" is chosen so as to not conflict with DNP data classes or the Open Systems Interconnect (OSI) concept of layers. The abbreviation for a DNP subset implementation consists of "DNP", a dash, and "L" followed by the level number.

For example, a vendor may be able to say, "This device implements the DNP V3.00 Application Layer protocol Level 1", or just "This device implements DNP - L1". ! NOTE: This document specifies only the minimum

requirements for a particular implementation level. A device may implement extra features in addition to these requirements and still conform. Refer to CHAPTER 5: CONFORMANCE for more details.

The following terms are used throughout this document:

configure To initialize a device so it operates in a particular way. For instance, a customer may configure a device so the device never requests data link confirmations. A vendor or customer may configure a device using a variety of mechanisms (e.g. parameters in NVRAM, parameters in ROM, dip switches or hardware jumpers).

DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00 ix

Master A device that initiates requests to gather data or perform controls using DNP.

Slave A device that gathers data or performs control operations in response to DNP requests from the Master, and sends response messages in return. A Slave device may also generate DNP Unsolicited Responses.

parse To resolve a request or response into component parts. In the context of DNP V3.00 messages, to parse a message means a device can break the message into pieces, each of which consists of a header and sometimes some corresponding data. If a device is able to parse a message, it can recognize each piece of a message. It does not necessarily make use of the data found in that message. However, it must make any confirmation responses or other responses that the message requires.

report To actually send to a Master device a particular object variation. Used only in connection with Slave devices. A Slave device may parse requests for a larger subset of objects than it actually reports.

support To be able to send or parse a particular set of DNP objects, variations, function codes and/or qualifiers.

READING THE SUBSET TABLES

The subsets of the DNP V3.00 protocol discussed in this document are described in a common format. Each chapter of this document describing an implementation level contains a table having the following fields:

OBJECT These fields describe a DNP application layer object:

Obj The object group Var The object variation Description The text name of the object

DNP Users Group P009-0IG.SUB, Version 2.00 x

REQUEST These fields describe the set of DNP V3.00 objects, function codes, and qualifiers a Slave device must be able to parse as a part of an incoming request in order to have implemented the subset.

Func Codes A list of the request function codes that the Slave must accept as operators on this object.

Qual Codes A list of the qualifier codes the Slave must parse in association with this object.

If these fields are blank, it means the Slave need not be able to parse the specified object in order to implement the subset.

RESPONSE These fields describe the set of DNP V3.00 objects, function codes, and qualifiers a Master device must be able to parse from an incoming response or unsolicited response in order to have implemented the subset. These fields also define the minimum subset of responses a Slave device may make.

Func Codes A list of the response function codes the Master must accept as operators on this object.

Qual Codes A list of the qualifier codes the Master must parse in association with this object.

If these fields are blank, it means the Master need not be able to parse the specified object in order to implement the subset.

There are three levels of implementation of DNP V3.00 defined within this document. Each level builds upon the level preceding it. The additions to a level from the preceding level are highlighted by shading in the table. ! NOTE: The subset describes the minimum set of objects,

function codes, and qualifiers the devices must parse in order to implement the subset. If an object is supported, it must be used with the function and qualifier codes in order to implement the subset. It does not specify that a Slave device must actually report inputs, outputs and data for all of the objects in the subset.

DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00 xi

For example, suppose a subset table contains the following line:

OBJECT

REQUEST

(slave must parse)

RESPONSE (master must

parse) Obj Va

r Description Func

Codes Qual Codes (hex)

Func Codes

Qual Codes (hex)

30 4 16-Bit Analog Input without Flag 1 00, 01, 06 129, 130

01

. . . . . .

This entry indicates the following:

• A Slave device must accept and respond to any READ request (Function Code 1) of 16-Bit Analog Input Without Flag objects. The READ request may use either 8-bit start and stop indices (Qualifier Code 0x00), 16-bit start and stop indices (Qualifier Code 0x01), or no range field (Qualifier Code 0x06). The Slave device need not parse READ requests for 16-Bit Analog Input Without Flag objects using any other Qualifier Codes. The Master device cannot include a 16-Bit Analog Input Without Flag object in any request containing a function code other than READ.

• The Slave need not actually report any analog inputs. It may set an Internal Indication bit in its response, or return a null response, as discussed in section 4.1 Error Responses.

• A Master device must be able to parse either RESPONSEs (Function Code 129) or UNSOLICITED RESPONSEs (Function Code 130) from the Slave containing 16-Bit Analog Input Without Flag objects. The response must use Qualifier Code 0x01. The Master device need not parse responses or unsolicited responses containing 16-Bit Analog Input Without Flag objects using any other Qualifier Codes.

• The Master need not use the data supplied by the Slave for any purpose, but can discard it after sending any necessary confirmation.

GOALS AND ASSUMPTIONS These subset definitions were prepared with the following goals:

DNP Users Group P009-0IG.SUB, Version 2.00 xii

• Minimize the complexity of implementation. Where complexity must be added, it was added at the Master rather than the Slave.

• Minimize the bandwidth used. • Allow all data provided by a Slave to be retrieved at any Level. • Allow flexibility for a variety of different, but interoperable

implementations.

It was assumed that the simpler the Slave device, the fewer points it would provide. Therefore, there would be less need for the more complex point range specifications available in DNP.

As a result of these goals and assumptions, the lower level subset definitions are based around polls of Class Data Objects. In a typical minimum implementation, it is expected that a Master device will poll frequently for Class 1, 2 or 3 Data, interspersed with infrequent Class 0 Data polls. More advanced implementations may take advantage of Unsolicited Responses and the more complex polling features available in DNP. See 4.2 Data Classes and Events for more discussion regarding the use of data classes.

Qualifiers are a complex part of DNP, so the number of qualifiers required to be supported by either a Master or a Slave devices was limited. Table 1 illustrates the subset of qualifiers chosen and the intended use of each qualifier. There may be a few exceptions to these rules.

Qualifier (hex)

Use in a Request

Use in a Response

00, 01 A range of static points, or a single point with a point number

Static objects

06 All points Not valid

07, 08 A limited quantity of events

A single point with no number (e.g. Time and Date)

A single point with no number (e.g. Time and Date)

17, 28 Controls (usually one or more unrelated points)

Event objects (usually one or more unrelated points)

Table 1 Qualifiers Used in the Subset Definitions

DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00 xiii

Chapter 1: LEVEL 1 DNP V3.00 IMPLEMENTATION (DNP - L1)

This chapter describes the minimum subset of the DNP V3.00 Application Layer that can be supported and still be said to implement the protocol. This implementation level is called Level 1 (L1).

1.1 INTENDED USE

This level of implementation is intended to represent the simplest implementation of DNP V3.00 for communicating between a Master and a typical Intelligent Electronic Device (IED). It would typically be used between a master station or data concentrator and a small end device (eg. meter, relay, auto-recloser or capacitor bank controller). It is intended for use with Slave devices whose input and output points are local to the device.

1.2 GENERAL DESCRIPTION

The Level 1 subset is based around Class Data polling, as described in the Goals and Assumptions section of the OVERVIEW. A Level 1 Slave must accept requests for:

• READs of Class Data Objects • READs of Binary Output and Analog Output objects, if such

outputs exist on the Slave.

! NOTE: If such objects do not exist, the Slave is allowed to respond OBJECT UNKNOWN (see 4.1 Error Responses).

DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00 1

• Control operations to Binary Output or Analog Outputs, if they exist on the Slave. If such objects do not exist, the Slave is allowed to respond OBJECT UNKNOWN.

• WRITEs to the RESTART Internal Indication • COLD RESTARTs • DELAY MEASUREMENTs and WRITEs to Time and Date, if the

Slave sets the TIME SYNCHRONIZATION REQUIRED Internal Indication (See 4.13 Time Synchronization)

A Level 1 Master must accept a subset of object variations that is about one-third of the total number defined in DNP, but includes most basic data types:

• Binary Inputs and Events • Counters and Counter Events • Analog Inputs and Events • Binary and Analog Output Status

The following are specifically NOT included:

• Frozen objects • Time-stamped objects, with the exception of Binary Inputs, because

Sequence of Events (SOE) information is a common industry requirement

! NOTE: Although a Level 1 Master must be able to

parse many objects, a Level 1 Slave is not required to generate them. For example, a Slave need not provide Binary Output Status or Analog Output Status objects if it does not control any of these outputs. The Slave may also choose to report Binary Input Without Time objects instead of Binary Input Change With Relative Time objects.

A Level 1 Slave may send Unsolicited Responses of some objects, but this capability must be configurable. See 4.4 Unsolicited Responses.

1.3 IMPLEMENTATION TABLE

Table 1.3-1 describes the objects, function codes, and qualifiers used in a Level 1 DNP V3.00 implementation.

DNP Users Group P009-0IG.SUB, Version 2.00 2

Table 1.3-1 Level 1 Implementation (DNP-L1)

OBJECT

REQUEST (slave must parse)

RESPONSE

(master must parse) Obj Var Description Func

Codes (dec)

Qual Codes (hex)

Func Codes (dec)

Qual Codes (hex)

1 0 Binary Input - All Variations

1 1 Binary Input 129 00, 01

1 2 Binary Input with Status 129 00, 01

2 0 Binary Input Change - All Variations

2 1 Binary Input Change without Time 129, 130 17, 28

2 2 Binary Input Change with Time 129, 130 17, 28

2 3 Binary Input Change with Relative Time 129, 130 17, 28

10 0 Binary Output - All Variations 1 06

10 1 Binary Output

10 2 Binary Output Status 129 00, 01

12 0 Control Block - All Variations

12 1 Control Relay Output Block 3, 4, 5, 6

17, 28 129 echo of request

12 2 Pattern Control Block

12 3 Pattern Mask

20 0 Binary Counter - All Variations

20 1 32-Bit Binary Counter 129 00, 01

20 2 16-Bit Binary Counter 129 00, 01

20 3 32-Bit Delta Counter 129 00, 01

20 4 16-Bit Delta Counter 129 00, 01

20 5 32-Bit Binary Counter without Flag 129 00, 01

20 6 16-Bit Binary Counter without Flag 129 00, 01

20 7 32-Bit Delta Counter without Flag 129 00 ,01

20 8 16-Bit Delta Counter without Flag 129 00, 01

21 0

Frozen Counter - All Variations

21 1 32-Bit Frozen Counter

21 2 16-Bit Frozen Counter

21 3 32-Bit Frozen Delta Counter


21 5 32-Bit Frozen Counter with Time of Freeze


21 7 32-Bit Frozen Delta Counter with Time of Freeze


OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes (dec)

Qual Codes (hex)


21 9 32-Bit Frozen Counter without Flag

21 10 16-Bit Frozen Counter without Flag

21 11 32-Bit Frozen Delta Counter without Flag


22 0 Counter Change Event - All Variations

22 1 32-Bit Counter Change Event without Time 129, 130 17, 28


22 3 32-Bit Delta Counter Change Event without Time 129, 130 17, 28

22 4 16-Bit Delta Counter Change Event without Time 129, 130 17, 28

22 5 32-Bit Counter Change Event with Time


22 7 32-Bit Delta Counter Change Event with Time


23 0 Frozen Counter Event - All Variations

23 1 32-Bit Frozen Counter Event without Time


23 3 32-Bit Frozen Delta Counter Event without Time


23 5 32-Bit Frozen Counter Event with Time


23 7 32-Bit Frozen Delta Counter Event with Time


30 0 Analog Input - All Variations

30 1 32-Bit Analog Input 129 00, 01

30 2 16-Bit Analog Input 129 00, 01

30 3 32-Bit Analog Input without Flag 129 00, 01

30 4 16-Bit Analog Input without Flag 129 00, 01

31 0 Frozen Analog Input - All Variations

31 1 32-Bit Frozen Analog Input


31 3 32-Bit Frozen Analog Input with Time of Freeze



OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes (dec)

Qual Codes (hex)

31 5 32-Bit Frozen Analog Input without Flag


32 0 Analog Change Event - All Variations

32 1 32-Bit Analog Change Event without Time 129, 130 17,28


32 3 32-Bit Analog Change Event with Time


33 0 Frozen Analog Event - All Variations

33 1 32-Bit Frozen Analog Event without Time


33 3 32-Bit Frozen Analog Event with Time


40 0 Analog Output Status - All Variations 1 06

40 1 32-Bit Analog Output Status

40 2 16-Bit Analog Output Status 129 00, 01

41 0 Analog Output Block - All Variations

41 1 32-Bit Analog Output Block

41 2 16-Bit Analog Output Block 3, 4, 5, 6


50 0 Time and Date - All Variations

50 1 Time and Date 2 (see 4.14)

07, quantity=1

50 2 Time and Date with Interval

51 0 Time and Date CTO - All Variations

51 1 Time and Date CTO 129, 130 07, quantity=1

51 2 Unsynchronized Time and Date CTO 129, 130 07, quantity=1

52 0 Time Delay - All Variations

52 1 Time Delay Coarse 129 07, quantity=1

52 2 Time Delay Fine 129 07, quantity=1

60 0

60 1 Class 0 Data 1 06

60 2 Class 1 Data 1 06,07,08


OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes (dec)

Qual Codes (hex)

60 3 Class 2 Data 1 06,07,08

60 4 Class 3 Data 1 06,07,08

70 1 File Identifier

80 1 Internal Indications 2 00, index=7

81 1 Storage Object

82 1 Device Profile

83 1 Private Registration Object

83 2 Private Registration Object Descriptor

90 1 Application Identifier

100 1 Short Floating Point

100 2 Long Floating Point

100 3 Extended Floating Point

101 1 Small Packed Binary-Coded Decimal

101 2 Medium Packed Binary-Coded Decimal

101 3 Large Packed Binary-Coded Decimal

No object 13

No object 23 (see 4.14)


Chapter 2: LEVEL 2 DNP V3.00 IMPLEMENTATION (DNP-L2)

This chapter describes the second smallest subset of the DNP V3.00 Application Layer. This implementation level is called Level 2 (L2).

2.1 INTENDED USE

This level contains a few more features than the Level 1 implementation. It is intended for communications between a master station or data concentrator and a device that could be called either a large Intelligent Electronic Device (IED) or a small Remote Terminal Unit (RTU). Typically, the input and output points of such a device would be local to the device.


A Level 2 Slave implementation is the same as a Level 1 Slave implementation with the following additions:

• A Level 2 Slave accepts FREEZE requests on Binary Counter objects (not Analog Input objects or Frozen Counters). See 4.13 Freeze Operations.

• A Level 2 Slave parses READ requests for variation 0 of specific objects.

• A Level 2 Slave parses READ requests for variations 1, 2 and 3 of Binary Input Change objects.

• A Level 2 Slave parses READ requests for Frozen Counter objects and may report Frozen Counter objects (but not Frozen Delta Counters)

• A Level 2 Slave may send unsolicited responses containing static data, within the constraints described in CHAPTER 4: IMPLEMENTATION RULES AND RECOMMENDATIONS.



Table 2.3-1 Describes the objects, function codes, and qualifiers used in a Level 2 DNP V3.00 implementation. Note that additions and modifications from implementation Level 1 are shaded.


OBJECT


RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes

Qual Codes (hex)

1 0 Binary Input - All Variations 1 06

1 1 Binary Input

129, 130 00, 01

1 2 Binary Input with Status

129, 130 00, 01

2 0 Binary Input Change - All Variations 1 06,07,08

2 1 Binary Input Change without Time 1 06,07,08 129, 130 17, 28

2 2 Binary Input Change with Time 1 06,07,08 129, 130 17, 28

2 3 Binary Input Change with Relative Time 1 06,07,08 129, 130 17, 28

10 0 Binary Output - All Variations 1 06

10 1 Binary Output

10 2 Binary Output Status 129, 130 00, 01




12 2 Pattern Control Block

12 3 Pattern Mask

20 0 Binary Counter - All Variations 1, 7, 8, 9, 10

06

20 1 32-Bit Binary Counter 129, 130 00, 01


20 3 32-Bit Delta Counter 129, 130 00, 01


20 5 32-Bit Binary Counter without Flag 129, 130 00, 01

20 6 16-Bit Binary Counter without Flag 129, 130 00, 01

20 7 32-Bit Delta Counter without Flag 129, 130 00 ,01

20 8 16-Bit Delta Counter without Flag 129, 130 00 ,01

21 0 Frozen Counter - All Variations 1 06

21 1 32-Bit Frozen Counter 129, 130 00, 01

21 2 16-Bit Frozen Counter 129, 130 00, 01


OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes

Qual Codes (hex)







21 9 32-Bit Frozen Counter without Flag 129, 130 00, 01

21 10 16-Bit Frozen Counter without Flag 129, 130 00, 01



22 0 Counter Change Event - All Variations 1 06,07,08



22 3 32-Bit Delta Counter Change Event without Time

22 4 16-Bit Delta Counter Change Event without Time





23 0 Frozen Counter Event - All Variations









30 0 Analog Input - All Variations 1 06

30 1 32-Bit Analog Input 129, 130 00, 01

30 2 16-Bit Analog Input 129, 130 00, 01

30 3 32-Bit Analog Input without Flag 129, 130 00, 01

30 4 16-Bit Analog Input without Flag 129, 130 00, 01


OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes

Qual Codes (hex)








32 0 Analog Change Event - All Variations 1 06,07,08










40 0 Analog Output Status - All Variations 1 06

40 1 32-Bit Analog Output Status

40 2 16-Bit Analog Output Status 129, 130 00, 01

41 0 Analog Output Block - All Variations

41 1 32-Bit Analog Output Block





07, quantity=1








OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes

Qual Codes (hex)


60 0


60 2 Class 1 Data 1 06,07,08

60 3 Class 2 Data 1 06,07,08

60 4 Class 3 Data 1 06,07,08


80 1 Internal Indications 2 00, index=7

81 1 Storage Object

82 1 Device Profile










No Object 13

No Object 23 (see 4.14)


Chapter 3: LEVEL 3 DNP V3.00 IMPLEMENTATION (DNP - L3)

This chapter describes a subset of the DNP V3.00 Application Layer which contains more functionality than the Level 2 subset.

3.1 INTENDED USE

This level of implementation of DNP V3.00 is for communicating between a Master and a medium size slave device (e.g. RTU, Data Concentrator).


A Level 3 implementation uses a larger range of objects, variations, function and qualifier codes than a Level 2 implementation.

A Level 3 Slave implementation is the same as a Level 2 implementation with the following additions:

• a Level 3 Slave will process read requests for many specific objects and variations.

• a Level 3 Slave will process a larger range of requests with a larger range of function codes.

• A Level 3 implementation supports enabling and disabling unsolicited responses on a Class-by-Class basis. A Master can enable or disable unsolicited responses for Class 1, Class 2, and Class 3 objects only. The request fragment may contain one or more of the following object headers only (refer to Section 4.2 Data Classes and Events and Section 4.4 Unsolicited Responses ):

- Class 1 (Obj. 60, VAR. 2, Qual. 06) - Class 2 (Obj. 60, VAR. 3, Qual. 06) - Class 3 (Obj. 60, VAR. 4, Qual. 06)

• A Level 3 implementation supports the assigning and re-assigning of

data objects to classes dynamically (i.e. during run-time). An ASSIGN DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00 1

CLASSES (Function Code 22) request will contain a Class 1, 2 or 3 object header followed by one or more static data object headers. Several sets of Class and data object headers may be contained in a single request fragment (refer to Section 4.2 Data Classes and Events).


Table 3.3-1 Describes the objects, function codes, and qualifiers used in a Level 3 DNP V3.00 implementation. Note that additions and modifications from implementation Level 2 are shaded.


OBJECT


RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes

Qual Codes (hex)

1 0 Binary Input - All Variations 1, 22 00, 01, 06

1 1 Binary Input 1 00, 01, 06 129, 130 00, 01

1 2 Binary Input with Status 1 00, 01 06 129, 130 00, 01

2 0 Binary Input Change - All Variations 1 06,07,08

2 1 Binary Input Change without Time 1 06,07,08 129, 130 17, 28

2 2 Binary Input Change with Time 1 06,07,08 129, 130 17, 28

2 3 Binary Input Change with Relative Time 1 06,07,08 129, 130 17, 28

10 0 Binary Output - All Variations 1 00, 01, 06

10 1 Binary Output

10 2 Binary Output Status 1 00, 01, 06 129, 130 00, 01




12 2 Pattern Control Block 5, 6 17, 28 129 echo of request

12 3 Pattern Mask 5, 6 00, 01 129 echo of request

20 0 Binary Counter - All Variations 1, 7, 8, 9, 10, 22

00, 01, 06

20 1 32-Bit Binary Counter 1 00, 01, 06 129, 130 00, 01

20 2 16-Bit Binary Counter 1 00, 01, 06 129, 130 00, 01

20 3 32-Bit Delta Counter 1 00, 01, 06 129, 130 00, 01

20 4 16-Bit Delta Counter 1 00, 01, 06 129, 130 00, 01


OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes

Qual Codes (hex)

20 5 32-Bit Binary Counter without Flag 1 00, 01, 06 129, 130 00, 01

20 6 16-Bit Binary Counter without Flag 1 00, 01, 06 129, 130 00, 01

20 7 32-Bit Delta Counter without Flag 1 00, 01, 06 129, 130 00, 01

20 8 16-Bit Delta Counter without Flag 1 00, 01, 06 129, 130 00, 01

21 0 Frozen Counters - All Variations 1, 22 00, 01, 06

21 1 32-Bit Frozen Counter 1 00, 01, 06 129, 130 00, 01

21 2 16-Bit Frozen Counter 1 00, 01, 06 129, 130 00, 01

21 3 32-Bit Frozen Delta Counter 1 00, 01, 06 129, 130 00, 01

21 4 16-Bit Frozen Delta Counter 1 00, 01, 06 129, 130 00, 01





21 9 32-Bit Frozen Counter without Flag 1 00, 01, 06 129, 130 00, 01

21 10 16-Bit Frozen Counter without Flag 1 00, 01, 06 129, 130 00, 01



22 0 Counter Change Event - All Variations 1 06,07,08

22 1 32-Bit Counter Change Event without Time 1 06,07,08 129, 130 17, 28

22 2 16-Bit Counter Change Event without Time 1 06,07,08 129, 130 17, 28

22 3 32-Bit Delta Counter Change Event without Time 1 06,07,08 129, 130 17, 28

22 4 16-Bit Delta Counter Change Event without Time 1 06,07,08 129, 130 17, 28





23 0 Frozen Counter Events - All Variations 1 06,07,08

23 1 32-Bit Frozen Counter Event without Time 1 06,07,08 129, 130 17, 28

23 2 16-Bit Frozen Counter Event without Time 1 06,07,08 129, 130 17,28

23 3 32-Bit Frozen Delta Counter Event without Time 1 06,07,08 129, 130 17, 28

23 4 16-Bit Frozen Delta Counter Event without Time 1 06,07,08 129, 130 17, 28




OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes

Qual Codes (hex)




30 0 Analog Input - All Variations 1, 22 00, 01, 06

30 1 32-Bit Analog Input 1 00, 01, 06 129, 130 00, 01

30 2 16-Bit Analog Input 1 00, 01, 06 129, 130 00, 01

30 3 32-Bit Analog Input without flag 1 00, 01, 06 129, 130 00, 01

30 4 16-Bit Analog Input without flag 1 00, 01, 06 129, 130 00, 01








32 0 Analog Change Event - All Variations 1 06,07,08

32 1 32-Bit Analog Change Event without Time 1 06,07,08 129, 130 17, 28

32 2 16-Bit Analog Change Event without Time 1 06,07,08 129, 130 17, 28








40 0 Analog Output Status - All Variations 1 00, 01, 06

40 1 32-Bit Analog Output Status 1 00, 01, 06 129, 130 00, 01

40 2 16-Bit Analog Output Status 1 00, 01, 06 129, 130 00, 01







07, quantity = 1

1 07, tit 1

129 07, tit 1

OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes

Qual Codes (hex)

quantity = 1 quantity=1








60 0 Not Defined


60 2 Class 1 Data 1 06,07,08

20, 21, 22

06

60 3 Class 2 Data 1 06,07,08

20, 21 22

06

60 4 Class 3 Data 1 06,07,08

20, 21 22

06


80 1 Internal Indications 1 00, 01

2 00, index=7

81 1 Storage Object

82 1 Device Profile










OBJECT

REQUEST

(slave must parse)

RESPONSE


Codes (dec)

Qual Codes (hex)

Func Codes

Qual Codes (hex)


No Object 13

No Object 23 (see 4.14)


Chapter 4: IMPLEMENTATION RULES AND RECOMMENDATIONS

This chapter describes several constraints on the implementation of DNP V3.00 in addition to those described in the DNP V3.00 Basic 4 Document Set. It defines rules regarding those parts of the protocol that devices must satisfy in order to conform to any DNP implementation level. It also makes some recommendations regarding further behaviour that a device may choose to implement. The purpose of these additional rules and recommendations is to limit the possible variations of implementation and encourage standardization.

4.1 ERROR RESPONSES

As a result of the definition of implementation levels, it is necessary to define the valid responses to a request that either:

• Is not a valid request for the given level, or • Is valid for the given level, but is not applicable to the

particular device.

This section discusses those responses.

4.1.1 Rules A Slave device may respond to Master requests as described in Table 4.1-1 if there is an error in the request. The Internal Indication bit numbers listed are in the second octet.

Response

IIN bit

Meaning

FUNCTION UNKNOWN

0 means “My implementation level does not support this function on objects of this group and variation”.

OBJECT UNKNOWN

1 means either “My implementation level does not support this group and variation of object”, or for static objects, “I have no

DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00

1

DNP Users Group P009-0IG.SUB, Version 2.00

2

Response

IIN bit

Meaning

objects with this group and variation”. Cannot be used as a response for event objects if the request is defined for the level. In that case, the Slave must send a Null Response (see below).

PARAMETER ERROR

2 means “I have objects of this group and variation, but not within the range of points specified”. This IIN bit must be set even if some of the points specified are available. In such a case, the Slave may choose to include in the response those objects that are available, but this behaviour is not mandatory. Not permitted if no range was specified.

Null Response (no IIN bits set, but no objects of the specified type returned)

n/a means “No point range was specified, and I have no objects of this type”. Primarily used in response to event data polls. Can be used instead of OBJECT UNKNOWN for static objects if no range was specified.

Table 4.1-1 Valid Error Responses

Event objects are treated differently than static objects because they are not tied to physical hardware. They may not exist on a device at any given moment, even though the device is able to report them.

4.2 DATA CLASSES AND EVENTS

Many static data points (eg. binary input, analog input) within a Slave device can generate DNP event objects (eg. Binary Input Change With Time, Analog Input Change Event). This section describes the interaction between data points, event objects and DNP data classes.

4.2.1 Rules If a Slave device reports event objects, it must designate each of its data points as generating either Class 1, Class 2 or Class 3 event objects by default. (This designation may be configurable). The Class of event data is therefore an attribute of the data point and the event objects the data point reports. Every event object reported by the Slave device therefore belongs to Class 1, Class 2 or Class 3. Every static object reported by the Slave device belongs to Class 0.


3

Level 3 Slave devices must permit a Master to enable or disable the reporting of event objects by making ASSIGN CLASS (function code 22) requests.

To enable the reporting of event objects for a particular data point, the Master specifies in its ASSIGN CLASS request a Class 1, 2 or 3 object header and the header of a static object for the appropriate data point.

For example, to enable the generation of Class 2 events from DNP analog input point 4, the Master device sends an ASSIGN CLASS request containing the following object headers:

• Class 2 (Obj. 60 , Var. 3) • Analog Input (Obj. 30, Var. 0, Index 4)

Such a request does not mean the static object now belongs to Class 2; static objects belong to Class 0 by definition. Instead, the static object represents the data point itself, and the request means all event objects generated by the data point will belong to the specified Class.

A Master device tells a Slave device to stop reporting event objects for a particular data point by assigning event objects from the data point to Class 0. Since Class 0 is the class of static data and event objects cannot be Class 0, the Slave will not produce any further event objects for the data point.

The actual event object the Slave device reports after the Master device enables event object reporting will vary depending on the request of the Master.

The Master may request event objects by sending:

• a READ request for specific objects (eg. a READ request for Binary Input Change With Time objects, or a READ request for 16-Bit Analog Input Change Event Without Time objects).

• a READ request for a class of objects (eg. a READ request for Class 2 data). The Slave device returns all event objects assigned to the Class.

• a READ request for a quantity of Class objects (eg. a READ request of Class 2 data, specifying a quantity of 20 objects. The Slave returns the first 20 event objects it collected that were assigned to Class 2).

• a READ request for several Classes of data (eg. a READ request containing both Class 1 and Class 2 object headers).

A particular implementation level may support only certain methods of reading data. Refer to the appropriate chapters to determine whether a particular method is valid for a given implementation level.

If a Master does not specify a particular variation of object (i.e. when requesting a Class of data or requesting variation 0 of any object), the Slave


4

reports the default variation of object for the data point. This default variation may be configured.

If a Master READs several Classes of data in the same request, the Slave must not group the event objects by Data Class in its response. In particular, the Slave must report Binary Change events within a response in the order the events occurred. For example, consider a Slave device that detects the following events, in the order listed:

• Binary Input Change Without Time point 3 - Class 3 • Binary Input Change Without Time point 1 - Class 3 • Binary Input Change Without Time point 6 - Class 1 • Binary Input Change Without Time point 2 - Class 3

If the Master device sends a single READ request asking for Class 3, Class 2 and Class 1 data, the Slave must return the events in the order listed above. The Slave must NOT send all the Class 3 events together before sending the Class 1 event.

4.2.2 Recommendations It is highly recommended that all Slave devices report event data and that all Masters provide a report-by-exception mode of operation. This is only a recommendation because although DNP-L1 specifies Masters must be able to parse certain event objects, it does not specify that the Master necessarily uses them or that the Slave necessarily reports them. A particular combination of Master and Slave implementations will be interoperable even if event data are not supported. However, the combination may not be efficient or useful, as discussed below.

DNP is a relatively high-overhead set of protocols compared to its predecessors; however, the bandwidth available to most utility companies is still quite limited. Therefore, efficient bandwidth usage is vital to market acceptance of a particular DNP implementation. DNP provides several different means of retrieving data. They are listed here from most to least efficient:

1. Quiescent Operation, in which the Master never polls any Slave, and all communication is unsolicited report-by-exception. The Master still sends application layer confirmations to the Slave.

2. Unsolicited Report-by-Exception Operation, in which most communication is unsolicited, but the Master occasionally sends integrity polls for Class 0 Data to verify its database is up to date.

3. Polled Report-by-Exception Operation, in which the Master polls frequently for event data and occasionally for Class 0 Data. Most often the Slave’s response to the event polls will contain few objects, so polling can be very quick. The response size can be further limited if the Master requests a maximum number of events (qualifiers 0x07, 0x08).


5

4. Polled Static Operation, in which the Master polls only for Class 0 data or the specific data it requires. This method is the simplest to implement, but can be very inefficient if the number of points that need to be retrieved is high and changes are infrequent.

Some systems may also choose to mix Polled and Unsolicited Report-by-Exception operation.

Given that unsolicited responses are not always possible using some physical layers, the recommended minimum implementation for a Slave is Polled Report-by-Exception Operation. The Subset Definitions have been written with this in mind.

They have also been written with the goal that all data from a Slave be accessible using the least bandwidth and the least parsing required by the Slave. Therefore frequent polls of Class 1, 2, and or 3 Data, interspersed with occasional integrity polls of Class 0 Data, is the recommended minimum implementation.

4.3 SLAVE DEVICE START-UP

4.3.1 Rules Upon start-up of a Slave device, the Slave device must set true(1) the DEVICE RESTART Internal Indication bit within the Internal Indication field of each subsequent response and unsolicited response. This bit must remain set until a Master device clears it with a WRITE request.

If the Slave device is configured to send unsolicited responses, it must immediately send an unsolicited response upon start-up. This initial unsolicited response must contain either:

• the response header only, containing the Access Control, Function Code and IIN fields.

• the response header plus the current state of ALL of its static data points (eg. binary inputs, analog inputs).

The initial unsolicited response may also contain any events objects the Slave device had generated while running previously, but had not yet reported to the Master. If such objects exist, the Slave must report them before the static data. This rule allows the Master to report data changes in chronological order by simply parsing the message from beginning to end (i.e. the most recent value of any point will be the last one reported in the message).

The vendor of the device must specify in a Device Profile Document whether the device sends unsolicited responses, and if so, whether it


6

includes static data in the initial unsolicited response. Refer to APPENDIX A: DEVICE PROFILE DOCUMENT FORMAT for more details regarding the Device Profile Document.

Upon receiving this initial unsolicited response, the Master device must send a WRITE request to clear the DEVICE RESTARTED Internal Indication object reported by the Slave.

4.3.2 Recommendations If a Slave device does not automatically report all of its static data in an initial unsolicited response, the Master device should immediately poll for all of the device's event data and static data (ie. send a READ request for Class 1, Class 2, Class 3 and Class 0 data).

4.4 UNSOLICITED RESPONSES

4.4.1 Rules A Slave device may optionally send unsolicited responses to a Master device. The vendor of a Slave device must specify in a Device Profile Document whether the device can send unsolicited responses. This document must also specify which objects, variations, qualifiers and function codes the Slave device may include in those unsolicited responses. Refer to APPENDIX A: DEVICE PROFILE DOCUMENT FORMAT for more details regarding the Device Profile Document.

All Slave devices must provide a mode of operation in which the Slave never sends unsolicited responses. This mode of operation must be configurable.

The ability to configure unsolicited responses for the entire device is separate from the ability of the Master to disable unsolicited responses using requests. The following rules apply:

1. If a Slave device is configured to send unsolicited responses, a Master device may disable unsolicited responses by sending a DISABLE UNSOLICITED request (function code 22).

2. If a Slave device is configured to send unsolicited responses, it must send an initial unsolicited response upon start-up regardless of whether the Master sent any DISABLE UNSOLICITED requests (See Section 4.3: Slave Device Start-up for details). This rule ensures the Master device is notified immediately if the device restarts. The rule applies even if the Master has disabled unsolicited responses from all points on the Slave device.


7

Slave devices implementing Level 2 or greater may report static data objects in unsolicited responses. They may do so only under the following conditions:

• upon start up of the Slave device. • when the status flags of points (within the flag octet) change state. For

example, if a range of analog inputs go off-line, then 16-Bit Analog Input objects may be reported in an unsolicited response.

All other events or exceptions must be reported using event data objects.

The destination address of the Master device to which the unsolicited responses are sent must be configurable in the Slave device.

All levels of Master devices must support unsolicited responses.

4.5 OPERATING BINARY OUTPUTS

4.5.1 Rules All Slave devices must be able to parse operations on Control Relay Output Block objects (Obj.12, Var.1) for operating binary outputs. If a Slave device does not actually have any binary output points, it may respond with the PARAMETER ERROR or OBJECT UNKNOWN Internal Indications set. The FUNCTION UNKNOWN Internal Indication is not a valid response in this case.

Similarly, a Slave device must parse all output function codes (e.g. SELECT/OPERATE) and control types (e.g. PULSE ON). If the Slave does not choose to implement a particular function code or control type, it must not respond with FUNCTION UNKNOWN. It must respond with the value operation not supported in the STATUS field of the Control Relay Output Block.

The control operations supported by a Slave device must be described in the Device Profile Document for the device. Refer to APPENDIX A: DEVICE PROFILE DOCUMENT FORMAT for more details.

4.5.2 Recommendations The use of WRITEs to Binary Output objects (Obj. 10, VAR. 1) as a means of operating binary outputs is not recommended because the response to a WRITE request cannot give an indication of whether the operation was successful.

If a Slave device implements WRITEs to Binary Outputs in addition to operations on Control Relay Output Blocks, it is recommended that the device “loop back” the state of each output to a Binary Input object. This will provide some feedback to the Master.


8

! NOTE: Control Relay Output Block object index x and Binary Output object index x both refer to the same physical binary output point.

It is recommended that whenever possible, Slave devices behave in a “don’t care” manner regarding which output operations they support. In other words, if security is not a major issue and the device’s hardware does not require specific instructions, the Slave device should accept as many control types (LATCH, PULSE, TRIP/CLOSE etc.) as possible.

It is recommended that if possible, all output points on a particular Slave device support the same output function codes, to reduce the complexity of configuration for Masters.

4.6 FRAGMENTS AND FRAMES

4.6.1 Rules Devices must not transmit application layer fragments larger than 2048 bytes, unless the fragment size is configurable and can be limited to 2048 bytes.

All devices must accept application layer fragments of 249 bytes or fewer.

All devices must accept maximum size data link layer frames (292 bytes).

A Master device must not send multi-fragment requests.

A Master device must accept multi-fragment responses.

A Slave device must be able to return all of its data (static and event) within a single response. In other words, a response to a READ request for Class 1, Class 2, Class 3 and Class 0 data must fit into a single response. A single response may consist of one or more fragments.

The maximum frame size transmitted, the maximum fragment size transmitted, and whether or not a Slave device sends multi-fragment responses must be documented in the Device Profile Document for the Slave device. Refer to APPENDIX A: DEVICE PROFILE DOCUMENT FORMAT for more information regarding Device Profile Documents.

4.6.2 Recommendations It is recommended that the maximum size of a fragment be configurable in both Slave devices and Master devices.


9

It is recommended that Master devices choose the qualifiers and objects in their requests so as to minimize the amount of bandwidth required.

4.7 MULTIPLE OBJECTS IN A SINGLE REQUEST

4.7.1 Rules All Slave devices of all levels must be able to parse a single Master request containing any subset of all of the objects the Slave device supports. For example, a Level 2 Slave implementation must be able to parse a single READ request containing one or more of the following objects:

• Class 0 data • Class 1 data • Binary Counter - All Variations • Binary Input Change With Time, quantity 20

4.8 MULTIPLE OBJECTS IN A SINGLE RESPONSE

4.8.1 Rules All Master devices must be able to parse a single Slave response or unsolicited response containing any subset of the objects the Master device supports. For example, it must be able to parse a single response containing Binary Input, Analog Input, Counter Input and Binary Output Status objects.

4.9 CONFIRMATION AND RETRIES

4.9.1 Rules All levels of Slave and Master devices may choose when they request confirmation of outgoing data link frames. Whether a device always, never or sometimes (e.g. only when configured, only for certain messages) requests data link CONFIRM frames must be documented in the Device Profile Document for the device. Refer to APPENDIX A: DEVICE PROFILE DOCUMENT FORMAT for more information regarding Device Profile Documents.

A Slave or Master device must transmit a data link CONFIRM frame if it is requested to do so by a SEND/CONFIRM EXPECTED function code an incoming frame.

A Slave or Master device must transmit an Application Layer Confirmation Response if it is requested by the CONFIRM bit in an incoming fragment.

If a Slave is waiting for an application layer confirmation to a Response (function code 129) and receives a new request instead, it must:


10

1. Assume the confirmation will not be forthcoming and therefore retain any event data for the next request.

2. If the new request asks for some of the unconfirmed event data, include this data in the response.

3. Process and respond to the new request.

This rule ensures controls and other vital operations will receive priority over any operation pending at the Slave, such as a response to a READ request.

It also ensures the Master retains control over any polling sequence. This rule is implied in the DNP V3.00 Application Layer specification, but not explicitly stated.

As described in section 3.3 of the DNP V3.00 Application Layer, this rule also applies to Unsolicited Responses (function code 130), with one exception. For READ requests, PROCESS_AFTER_CONFIRM mode applies: the Slave does not respond to the READ until it has received confirmation for its Unsolicited Response. This rule remains unchanged from the DNP V3.00 Application Layer, because it prevents the same event data from being sent to the master twice, once in the Unsolicited Response, once in the READ Response.

If a Slave device supports application layer retries, the number of retries performed must be configurable and be disabled by default. This provision allows Master devices to choose application response timeouts as needed by the overall network, without needing to account for retries by any particular Slave.

4.9.2 Recommendations It is recommended that enabling or disabling Data Link Confirms be configurable in both Slave devices and Master devices. This practice is recommended because the use of data link CONFIRM frames, across a highly reliable point to point physical media, can effectively halve communication throughput.

It is recommended that a Slave device only requests Application Layer Confirmation Responses:

• on outgoing fragments that contain event data. This allows the Slave device to be sure the Master has received the event objects, and the Slave can therefore remove them from its internal buffers if it chooses.

• on large outgoing multi-fragment messages, in particular File Identifier Objects. This permits the Master to perform application-layer flow control, since the Master may take a significant amount of time to process large messages.


11

• when a particular IIN or status flag must be acted upon by the Master, e.g. Roll-Over or Buffer Overflow.

It is recommended that if a Slave device implements application layer retries, it only does so for unsolicited responses. Application layer retries are not especially useful for ensuring reliability in solicited responses because:

• The data link layer may already have performed several retries. • Data link layer retries are more efficient because they only re-transmit

part of the application layer message. • If the Master does not receive the data, it can retry the request. • If the Slave performs application layer retries, the Master must account

for this in its application response timeout, which may affect system performance.

However, using application retries for unsolicited responses is more useful because:

• The Master was not expecting the data, so it will not need to account for the retry in any timeout.

• Because the Master was not expecting the data, it cannot cause the Slave to resend the data as with solicited responses.

Conformance or otherwise to these recommendations must be documented in the Device Profile Document for the Slave device.

It is recommended that a Master device does not request Application Layer Confirms on outgoing fragments. Application Layer Confirmation Responses are not usually needed for requests because most requests require a response from the Slave device. The Application Layer Confirmation Response is redundant.

Conformance or otherwise to this recommendation must be documented in a Device Profile Document for the Master device.

4.10 WITH-FLAG AND WITHOUT-FLAG VARIATIONS

4.10.1 Rules A Slave device may choose to return an object containing a flag (e.g. 16-Bit Analog Input) when the Master has requested a without flag object variation (e.g.. 16-Bit Analog Input Without Flag). Similarly, a Slave may choose to return an object variation without a flag when the Master has requested an object variation with a flag. Whether or not the Slave device responds with an object containing a flag is the Slave's decision. The lack of a flag in an object implicitly implies that the flag = 1 (i.e. the point is on-line and no other exceptions are occurring).


12

A Master device must be able to process responses containing object variations both with flags and without flags.

4.11 16-BIT AND 32-BIT VARIATIONS

4.11.1 Rules A Slave device chooses a default object variation to report in response to a READ request for a Class of data, or for variation 0 of a particular object. For example, a Slave may choose to report a counter input as either a 16-bit or 32-bit variation, depending on an internal default or on the Slave device's configuration. If, however, a Master device explicitly requests a particular variation, the Slave device must respond with a particular variation. ! NOTE: There is one exception to this rule. The choice of

whether or not to use a with flag or without flag variation is nonetheless up to the Slave device. See Section 4.9.2: With-Flag and Without-Flag Variations. However, the chosen variation must be the size the Master requested.

4.11.2 Rules for Analog Inputs and the OVER-RANGE Flag Some analog input data gathered by a Slave device may be inherently a certain size (e.g. if the Slave's A/D convertors provide only 12 bits of resolution). However, a Master device may request this data in any size, either 16-bit or 32-bit. The following rules govern how to report this type of data:

1. If a Master requests a particular object variation (e.g. 16-bit Analog Input), and the measured value of the data point within the Slave device is within the range for the DNP variation (e.g. within 32767 to -32767), then the Slave reports the value without modification within the requested variation.

! NOTE: For a data value stored within the device as (for

example) a 12-bit two's complement number, this procedure will simply involve sign extending the value to its 16-bit or 32-bit two's complement representation. Since DNP analog values are signed, sign extension is not considered a modification of the value.

2. If a Master requests a 16-bit variation and the value of the data point is

outside of the range 32767 (7FFF hex) to -32768 (8000 hex), then the Slave reports the value as either 32767 or -32768. The Slave device sets the Over-Range bit within the flag field of the object.


13

3. If a Master requests a 32-bit variation and the value of the data point is outside of the range 2147483647 (7FFF FFFF hex) to -2147483648 (8000 0000 hex), then the Slave device reports the value as either 2147483647 or -2147483648. The Slave device sets the Over-Range bit within the flag field of an object.

4. If an input exceeds the range measurable by the hardware on the Slave device, the Slave device sets the Over-Range bit within the flag field of the object. It does not alter the value reported by its hardware. For example, a Slave device with a 12-bit A/D converter must set the Over-Range bit when the measured value exceeds 2047. The Slave device must still report the value as 2047 in the analog input object.

Table 4.11-1 illustrates these rules. The Slave sets the Over-Range flag in each case described in the table, except the example of 33000 requested as a 32-Bit Analog Input. This is a case of Rule #2 applying, but not Rule #3.

Size Stored Internally by the Device (size of

A/D convertor)

Measured Value

Response to a

Request for 16-bit Analog Inputs

Response to a

Request for 32-bit Analog Inputs

8 bits

> +127

007F

0000007F

< -128

FF80

FFFFFF80

12 bits

> +2047

07FF

000007FF

< -2048

F800

FFFFF800

16 bits

> +32767

7FFF

00007FFF

< -32768

8000

FFFF8000

32 bits

> +2147483647

7FFF

7FFFFFFF

33000 (example)

7FFF

00080E8 *

< -2147483648

8000

80000000

* Over-Range flag is not set in this case. Over-Range is set in all other cases.

Table 4.11-1 Examples of Over-Range Conditions and Values

! NOTE: The DNP V3.00 Object Library makes certain statements that may appear to contradict these rules. There is no contradiction, as explained below.

• When a Slave returns a 16-bit Analog Input object and the Over-Range bit is set, the DNP V3.00 Data Object Library states, "The actual value field can be ignored [by the Master device] as its value is not defined." This rule holds; therefore, the "rules" listed in this section for 16-bit Analog Inputs are actually recommendations, since a Master may ignore the value of the object.


14

• When a Slave returns a 32-bit Analog Input object, the DNP V3.00 Data Object Library states, "The actual value will be +231-1 or -231 if it is over-range or under-range." This rule also holds, but only describes the cases in which the Slave represents the object in 32 bits internally.

4.11.3 Rules for Counter Objects and the ROLL-OVER Flag The Roll-Over flag in counter objects is not a useful flag because of DNP’s flexibility in reporting object variations. A Master device has no way of determining whether the counter rolled over at 16-bits, 32-bits, or some internal value. Unlike the case of the Over-Range flag for Analog Inputs, a Binary Counter object cannot be reported at its maximum value to indicate the device’s internal maximum range. The counter must continue incrementing after being set to zero, or information will be lost. Therefore the following rules apply:

1. Slave devices may choose not to set the Roll-Over flag.

2. The Device Profile Document for a Slave device must identify the point at which the Slave device’s counters roll over. Refer to APPENDIX A: DEVICE PROFILE DOCUMENT FORMAT for more information regarding Device Profile Documents.

3. The Device Profile Document for a Slave device must identify the default size of counter the Slave reports when asked for Class Data or Variation 0. This default size does not change unless the Slave device is re-configured.

4. If a Slave responds to both 16-bit and 32-bit requests, the Slave must respond with the lower 16 bits of a 32-bit counter when asked for 16 bits.

5. If a polled mode of data reporting is used, it is the responsibility of the Master to poll often enough to capture any roll-over condition that occurs.

4.11.4 Recommendations Regarding the ROLL-OVER Flag It is highly recommended that Slave devices do not set the Roll-Over flag, for the reasons discussed in the previous section.

It is highly recommended that Master devices ignore the Roll-Over flag.


15

4.12 TIME TAGGED BINARY INPUT EVENTS

4.12.1 Rules Slave devices must preserve the sequence of occurrence of binary input event objects within responses. For instance, Binary Input Without Time objects (Obj. 2, VAR. 2) must be returned in the sequence in which they occur.

If a Master device does not specify a particular variation of binary input event object in a READ request, a Slave may choose what variation to report. If a Master requests a particular Class of data, or a request for Binary Input Change Events with variation 0, a Slave may choose to report, for a given event:

• only a time-tagged event object, i.e. either Binary Input Change With Time or Binary Input Change With Relative Time.

• only a Binary Input Change Without Time event object.

• both a Binary Input Change Without Time object and one of the time-tagged binary event objects from the same event. If the Slave device implements this option, it must be configurable so the user can disable the reporting of one variation or the other.

The manner in which a Slave device reports binary input event objects must be described in the Device Profile Document for the Slave device. The manner in which a Master device expects binary input event objects to be reported must be described in its Device Profile Document. Refer to APPENDIX A: DEVICE PROFILE DOCUMENT FORMAT for details.

If a Master device requests a specific variation of binary input event object, the device must report that variation. For instance, if the Slave receives a READ request for Binary Input Change With Relative Time (Obj.2, VAR. 3), it must respond with data in the requested variation.

4.12.2 Recommendations Whenever a Slave responds with Binary Input Change With Relative Time objects (Obj.2, VAR.3), the objects are preceded by either a Time and Date CTO (Obj.51, VAR.1) or an Unsynchronized Time and Date CTO (Obj.51, VAR.2) object. It is recommended that the Unsynchronized Time and Date CTO object be used if the Slave's Time and Date have not been set.

4.13 FREEZE OPERATIONS This section clarifies the use of the various FREEZE function codes. Upon receiving a FREEZE request, a Slave device must copy the appropriate Binary Counter values ("running" counters) into a "freeze" buffer. The


16

Master may read these frozen values as Frozen Counter Input objects (Obj. 21). If a FREEZE AND CLEAR request is being processed, the Slave must clear the “running” values immediately after performing the FREEZE. A READ request of Binary Counter Input objects (Obj. 20) always return the values of the "running" counters.

4.13.1 Rules A Master device must perform FREEZE operations on Binary Counter objects (Obj. 20) only, NOT on Frozen Counter objects (Obj. 21).

If a Level 2 or Level 3 Slave device supports Binary Counter objects, it must support FREEZE operations (it cannot return an error response). However, it need not support READs of Frozen Counter objects if it chooses not to. This is allowed because the DNP V3.00 Data Object Library states “Point i in obj 20 and point i in obj 21 are NOT necessarily the same point”. Therefore, not all Binary Counters must have corresponding Frozen Counters.

4.14 TIME SYNCHRONIZATION

4.14.1 Rules A Slave device need not support WRITE operations on Time and Date objects or support DELAY MEASUREMENT requests if it never sets the TIME SYNCHRONIZATION REQUIRED Internal Indication bit in its responses or unsolicited responses.

Chapter 5: CONFORMANCE

This Chapter specifies the functions a Master or Slave device must support in order to conform to a defined implementation level.

The subset definitions deal primarily with the application layer of the DNP V3.00 protocol. It is nevertheless a requirement that in order for a device to conform to an implementation level, it must have implemented on it services of the Data Link Layer and Transport Functions (as defined in the DNP V3.00 Basic 4 Document Set) sufficient to support the implementation level. For instance, all subsets require a Slave device support Class 0 Data polls; if the response to such a poll would exceed 249 octets, segmentation by the Transport Function must be supported.

5.1 SLAVE DEVICES In order for a Slave device to implement a particular Level “X” of DNP V3.00, the device must conform to the following:

• The Slave device must be able to parse all Master requests defined for Level “X”.

• The Slave device must be configurable to not transmit anything other than Level “X” responses to Level “X” requests.

• The Slave device must obey all of the implementation rules defined in Chapter 4.

• The vendor must describe the device's DNP implementation in a Device Profile Document and make this document available to users of the device.

The Device Profile Document consists of a form, an implementation table similar to those found in this document, and some optional accompanying text. See APPENDIX A : DEVICE PROFILE DOCUMENT FORMAT for details.

A Slave device may accept and respond to additional requests not defined in Level “X” and still conform to that level. It may respond to such requests with data not defined in Level “X”.

Any additional functions the Slave provides must not prevent a Master device from communicating with a Slave device on the defined level. For instance, a DNP-L1 Slave may choose to accept WRITE requests of File DNP V3.00 Subset Definitions P009-0IG.SUB, Version 2.00

1


2

Identifier Objects. However, it must not require a Master to send such a request in order to operate.

5.2 MASTER DEVICES In order for a Master device to implement a particular level “X” of DNP V3.00, the device must conform to the following:

• The Master device must be able to parse all Slave responses defined for Level “X”.

• The Master device must be configurable to limit the requests it sends to Slave devices with implementation levels lower than “X”. For instance, a Level 3 Master must be configurable so it does not send any requests to either a Level 1 Slave or a Level 2 Slave that they could not parse. This does not prevent the Master from sending Level 3 requests to a Level 3 Slave.

• The Master device must obey all of the implementation rules defined in Chapter 4.

• The vendor of the Master device must describe the device's DNP implementation in a Device Profile Document and make this document available to users of the device.

The Device Profile Document consists of a form, an implementation table similar to those found in this document, and some optional accompanying text. See APPENDIX A : DEVICE PROFILE DOCUMENT FORMAT for details.

Appendix A: DEVICE PROFILE DOCUMENT FORMAT

Vendors must produce a Device Profile Document for each device they manufacture implementing DNP V3.00. The Device Profile Document clearly identifies any deviations from the implementation subsets described in this document and any other issues that may arise when determining the device's compatibility with another device. The Device Profile Document addresses Application Layer and Data Link Layer issues only; the Physical Layer is not addressed because of the multitude of different layers and configurations possible.

! NOTE: Do not confuse the Device Profile Document with the Device Profile Object defined in the DNP V3.00 documentation. The Device Profile Object does not at present contain sufficient information to establish compatibility between two devices. It must be modified in the future to include some of the information found in the Device Profile Document.

This appendix describes the minimum information that a vendor must include in the Device Profile Document.

Implementation Table

A table similar to those found in this document, identifying which object variations, function codes and qualifiers the device supports in both requests and responses, e.g.

OBJECT REQUEST RESPONSE

Obj Var Description Func Codes

Qual Codes (hex)

Func Codes

Qual Codes (hex)

30 4 16-Bit Analog Input without Flag 1 00, 01, 06 129, 130 01

. . . . . .

The Request columns identify all requests sent by a Master device, or all requests parsed by a Slave device. The Response columns


identify all responses parsed by a Master device, or all responses sent by a Slave device. If the device does not actually use all the requests or responses that it can parse, attach notes (or add columns) to the Implementation Table identifying which are not used.

Point List This is an optional part of the Device Profile Document. Some vendors of Slave devices may wish to include a list of the data points provided by the device. The format of this list is optional, but the following is suggested:

Description Index Default Static Variation Default Event Variation Point Name

Obj Var Desc Obj

Var Class Desc

Binary Input 7 1 1 No Status 2 1 2 Without Time

Breaker 'A' Tripped

Analog Input 3 30 1 32-bit 32

3 1 32-Bit Without Time

Phase 1 VARs

Vendor Name The name of the organization producing the device.

Device Name The model and name of the device, sufficient to distinguish it from any other device from the same organization.

Highest DNP Level Supported

The highest-numbered DNP implementation subset to which the device completely conforms.

Device Function Either Master or Slave. Masters send DNP requests, while Slaves send DNP responses. If a single physical device can perform both functions, supply a separate Device Profile Document for each function.

Notable Additions A brief description intended to quickly identify for the reader the most obvious features the device supports in addition to the Highest DNP Level. The complete list of features is described in the Implementation Table.

Maximum Data Link Frame Size

The largest size of Data Link Frame the device transmits, in octets.

Maximum Fragment Size

The largest size of Application Layer fragment the device transmits, in octets.

Maximum Data Link The number of times the device will re-transmit a confirmed data


Re-tries link frame before aborting the transaction.

Maximum Application Re-tries

The number of times the device will re-transmit a confirmed application request or response before aborting the transaction.

Requires Data Link Confirmation

Whether the device ever transmits SEND/CONFIRM EXPECTED - USER DATA frames.

Requires Application Confirmation

Whether the device ever sends application layer messages with the CONFIRM bit set in the APPLICATION CONTROL field.

Timeouts The time conditions under which the device will discard an incoming frame, fragment, request or response.

Control Operations The control operations permitted by the device. A device may support an Analog Output or Control Relay Output Block, but not necessarily support all operations on that object.

Reports Binary Input Change Events

A description of what variation of objects a Slave device reports when asked for Binary Input Change events with variation 0 or when asked for Class data. Refer to subset document section 4.12 Time-Tagged Binary Input Events.

Sends Unsolicited Responses

A list of the conditions under which a Slave device sends unsolicited responses.

Sends Static Data Unsolicited

A list of the conditions under which a Slave device sends static data (Class 0) as unsolicited responses.

Default Counter Object/Variation

The object and variation a Slave Device uses to report counter objects when asked for Variation 0 or for Class data. See subset document section 4.11.3.

Counters Rollover At

The value at which a Slave device’s counters roll over. See subset document section 4.11.3.

Sends Multi- Fragment Responses

Yes or No; whether a slave device sends multi-fragment responses (Master devices do not send multi-fragment requests)

A blank device profile form follows. The form must be accompanied by an Implementation Table and may optionally be accompanied by a Point List. A vendor may check multiple boxes within a section. Vendors of Master devices may optionally include text explaining under what conditions the Master device sends each type of request, e.g.: polling rates and methods, etc. This information is optional but may aid vendors of Slave devices in being compatible with the Master device.

In general, if a vendor checks a box marked "Configurable", the vendor must


attach an explanation of how an item can be configured. The format of such an explanation is optional, but might answer some of the following questions:

" At the factory, or in the field? " Using what equipment? " Over what range is the item configurable? " Under what conditions?

Similarly, if the vendor checks a box marked "Variable" or "Sometimes", the vendor must attach more details explaining under what conditions the specified item will occur.


DNP V3.00

DEVICE PROFILE DOCUMENT This document must be accompanied by a table having the following headings: Object Group Request Function Codes Response Function Codes Object Variation Request Qualifiers Response Qualifiers Object Name (optional)

Vendor Name:

Device Name:

Highest DNP Level Supported: For Requests For Responses

Device Function: # Master # Slave

Notable objects, functions, and/or qualifiers supported in addition to the Highest DNP Levels Supported (the complete list is described in the attached table): Maximum Data Link Frame Size (octets): Transmitted __________________ Received (must be 292)

Maximum Application Fragment Size (octets): Transmitted ________ (if >2048, must be configurable) Received ________ (must be > 249)

Maximum Data Link Re-tries: # None # Fixed at _______________________

Maximum Application Layer Re-tries: # None # Configurable, range ____ to _______


# Configurable, range ____ to _______ (Fixed is not permitted)

Requires Data Link Layer Confirmation: # Never # Always # Sometimes If 'Sometimes', when? __________________________________________ # Configurable If 'Configurable', how? ______________________________________________

Requires Application Layer Confirmation: # Never # Always (not recommended) # When reporting Event Data (Slave devices only) # When sending multi-fragment responses (Slave devices only) # Sometimes If 'Sometimes', when? ___________________________________________ # Configurable If 'Configurable', how? ______________________________________________

Timeouts while waiting for: Data Link Confirm # None # Fixed at _________ # Variable # Configurable Complete Appl. Fragment # None # Fixed at _________ # Variable # Configurable Application Confirm # None # Fixed at _________ # Variable # Configurable Complete Appl. Response # None # Fixed at _________ # Variable # Configurable Others __________________________________________________________________________ Attach explanation if 'Variable' or 'Configurable' was checked for any timeout

Sends/Executes Control Operations: WRITE Binary Outputs # Never # Always # Sometimes # Configurable SELECT/OPERATE # Never # Always # Sometimes # Configurable DIRECT OPERATE # Never # Always # Sometimes # Configurable DIRECT OPERATE - NO ACK # Never # Always # Sometimes # Configurable Count > 1 # Never # Always # Sometimes # Configurable Pulse On # Never # Always # Sometimes # Configurable Pulse Off # Never # Always # Sometimes # Configurable Latch On # Never # Always # Sometimes # Configurable Latch Off # Never # Always # Sometimes # Configurable Queue # Never # Always # Sometimes # Configurable Clear Queue # Never # Always # Sometimes # Configurable Attach explanation if 'Sometimes' or 'Configurable' was checked for any operation.


FILL OUT THE FOLLOWING ITEM FOR MASTER DEVICES ONLY:

Expects Binary Input Change Events: # Either time-tagged or non-time-tagged for a single event # Both time-tagged and non-time-tagged for a single event # Configurable (attach explanation)

FILL OUT THE FOLLOWING ITEMS FOR SLAVE DEVICES ONLY:

Reports Binary Input Change Events when no specific variation requested: # Never # Only time-tagged # Only non-time-tagged # Configurable to send both, one or the other (attach explanation)

Reports time-tagged Binary Input Change Events when no specific variation requested: # Never # Binary Input Change With Time # Binary Input Change With Relative Time # Configurable (attach explanation)

Sends Unsolicited Responses: # Never # Configurable (attach explanation) # Only certain objects # Sometimes (attach explanation) # ENABLE/DISABLE UNSOLICITED Function codes supported

Sends Static Data in Unsolicited Responses: # Never # When Device Restarts # When Status Flags Change No other options are permitted.

Default Counter Object/Variation: # No Counters Reported # Configurable (attach explanation) # Default Object ______________ Default Variation ______________ # Point-by-point list attached

Counters Roll Over at: # No Counters Reported # Configurable (attach explanation) # 16 Bits # 32 Bits # Other Value _____________ # Point-by-point list attached

Sends Multi-Fragment Responses: # Yes # No


GLOSSARY OF TERMS

application A piece of software (a program) consisting of one or more processes and supporting functions.

Binary A number system having only two symbols (1 and

0), and where values are expressed in the base two number system.

Bit Abbreviation of binary digit. The smallest

unit of information in a binary system. Has a value of either one (1) or zero (0).

Master The client or host station or computer,

with which the RTU equipment communicates. Also referred to as a host or host computer.

Non-volatile A semi-permanent type of data storage random-access memory (memory) that is backed up by batteries to

maintain stored data even if system power is lost. Can be both read and changed by the system. Abbreviated as NVRAM.

Random-access memory A type of temporary data storage

(memory) that can be read and changed while the computer is in use. Data stored in random-access memory is lost if the system loses power. Abbreviated as RAM.

Remote terminal unit A piece of equipment located at a

distance from a master station to monitor and control the status of outlying equipment, and to communicate the information back to the master station or host. Abbreviated as RTU.


Sequence of events A time-tagged change of state, logged

as part of a chronological record of significant changes in the condition of a particular point or points being monitored. Abbreviated as SOE.


LIST OF ACRONYMS AND ABBREVIATIONS

DNP distributed network protocol IED intelligent electronic device NVRAM non-volatile random-access memory OSI open systems interconnect RAM random-access memory RTU remote terminal unit SOE sequence of events


Distributed Network Protocol (DNP) V3.00

Transporting DNP V3.00 over Local and Wide Area Networks

Version 1.0

December 15, 1998

Prepared by:

Michael Thesing Advanced Control Systems, Inc. Norcross, GA USA

Acknowledgements:

The author wishes to thank Parker McCauley and Ken Murphy for their advice, expertise, and review of this document.

Other contributors: John Phillips Foxboro Australia Pty Limited Grant Gilchrist GE/Harris Energy Control Systems DNP is a trademark of the DNP Users Group.

Transporting DNP over LAN/WAN December 15, 1998

Copyright © 1998 DNP Users Group. All rights reserved.

ii


Contents

1 Overview...............................................................................................................................................................1 1.1 Purpose ..........................................................................................................................................................1 1.2 Notes..............................................................................................................................................................1 1.3 Protocol Stack................................................................................................................................................1 1.4 Conclusions ...................................................................................................................................................2

2 Physical, Link, and Network layers ...................................................................................................................3 2.1 Physical and Link layers................................................................................................................................3 2.2 Network layer ................................................................................................................................................3

3 Transport layer....................................................................................................................................................3 3.1 Protocol characteristics..................................................................................................................................3

3.1.1 UDP .......................................................................................................................................................3 3.1.2 TCP........................................................................................................................................................3

3.2 Network Topologies ......................................................................................................................................3 3.2.1 Network A .............................................................................................................................................4 3.2.2 Network B..............................................................................................................................................6 3.2.3 Network C..............................................................................................................................................8

3.3 Summary........................................................................................................................................................9 4 DNP Layers ........................................................................................................................................................10

4.1 Confirmations ..............................................................................................................................................10 4.2 Keep-alive timer ..........................................................................................................................................10 4.3 Multiple frames in UDP...............................................................................................................................11 4.4 Broadcast Address .......................................................................................................................................11

5 Security...............................................................................................................................................................11 6 Time Sync ...........................................................................................................................................................11

6.1 Desired Behavior .........................................................................................................................................12 6.2 Procedure.....................................................................................................................................................12 6.3 Driver requirement ......................................................................................................................................13

7 Socket requirements ..........................................................................................................................................13 7.1 Background..................................................................................................................................................13 7.2 TCP/UDP Port Number for DNP ................................................................................................................14 7.3 Making TCP connections ............................................................................................................................14 7.4 Broken connections .....................................................................................................................................16 7.5 Typical architecture .....................................................................................................................................16

8 References ..........................................................................................................................................................18 ANNEX A (informative) TCP vs. UDP in a Wide Area Network .........................................................................19 ANNEX B (normative) Additions to Existing documents......................................................................................21

New Function Code (24) .........................................................................................................................................21 B.1.1 Changes to Table 3-1 in the Application Layer document.........................................................................21 B.1.2 Addition to Chapter 4 in the Application Layer document........................................................................21

New Object (Obj 50, Var 03) ..................................................................................................................................21 B.2.1 Addition to Data Object Library document ...............................................................................................21

iii


1 Overview

1.1 Purpose

DNP V3.00 (hereafter referred to simply as DNP) was designed for serial point-to-point communication (e.g. RS-232) with limited support for half duplex serial networks (e.g. RS-485). In order for devices to exchange DNP messages in a local (LAN) and/or wide area network (WAN), one must either augment the protocol to support a network environment or use an existing network transport mechanism. This document takes the latter approach; specifically, to define how to transport DNP traffic on the internet protocol suite.

1.2 Notes

The internet protocol suite is sometimes referred to as the TCP/IP protocol. For this document, the internet protocol suite is defined to include both transport layers, TCP and UDP, as well as the IP network layer. The individual layers are summarized in sections 2 and 3.

Throughout this document the term “device” as it applies to a DNP device may be interpreted to be either a physical unit (i.e. a standalone product, RTU, IED, etc.) or a logical entity within a physical unit (i.e. logical RTU, virtual IED, etc.).

1.3 Protocol Stack

The most attractive reasons for choosing the internet protocol suite as a transport mechanism for DNP are: • Seamless integration of the substation LAN to the corporate WAN of the utility • Leverage existing equipment and standards

The internet protocol suite is designed to be platform independent and is supported on virtually every computer system in the world. It is highly scalable (LAN to WAN) and many quality implementations exist for both embedded and workstation operating systems. The recent growth of the Internet has fueled the large availability of equipment and has proved that the internet protocol suite is capable of transporting tremendous quantities and types of data.

The internet protocol suite and DNP use the OSI layering paradigm; each piece of the protocol stack in one station logically communicates with the corresponding piece in the other station(s). It is therefore easy to build DNP "on top of" the internet protocol suite since the internet layers appear transparent to the DNP layers (see Figure 1-1).

1


Link Linkdevice driver/link

Network NetworkIP

Transport TransportTCP,UDP

LPDU LPDUDNP Link Protocol

TPDU TPDUDNP Transport

APDU APDUDNP Application

Logical Communications

Station 1 Station 2

TCP/IP ProtocolSuite

DNP Protocol

Figure 1-1 Protocol Stack.

1.4 Conclusions All DNP devices, be they physical or logical, that are to communicate in the DNP V3.00 Protocol over a LAN/WAN shall be subject to the following basic requirements: • DNP shall use the internet protocol suite to transport messages over the LAN/WAN. The recommended

physical/link layer is Ethernet, but the internet protocol suite has been implemented over a wide variety of networks.

• All devices shall support connection-oriented (TCP) and connection-less sockets (UDP). TCP is required for wide-area networks and is strongly recommended for local-area networks. UDP is appropriate for non-critical messages such as data monitoring or configuration. UDP may be used on high-reliability single-segment LANs and must be used if broadcast delivery is required.

• The DNP Enhanced Protocol Architecture (EPA) of DNP shall be retained so that the protocol requirements contained in each layer do not need to be reinvented.

• Link Layer confirmations shall be disabled. Application Layer confirmations shall be used per the subset definitions and technical bulletin [Ref. 13].

• A mechanism for verifying the on-line status of an Outstation must be implemented. A periodic keep-alive message is recommended.

• All devices should be configured with the IP address of the communicating host. This address must be set in a secure manner and verified at the server-end before a connection is made.

• The method for time synchronization on a LAN is defined; the WAN case is not addressed in this document. • General recommendations for making socket connections between devices are outlined. Data providers such as

IEDs, Meters, and devices that are "downstream" in the SCADA system shall be the server-end of the connection. Data users such as RTUs, Master Stations, and devices that require access to the data shall be the client-end of the connection.

2


2 Physical, Link, and Network layers

2.1 Physical and Link layers

Although there is nothing in the internet protocol suite that precludes operation on other types of networks; e.g. ARCnet, Token-Ring, AppleTalk, etc., Ethernet/IEEE 802.3 is clearly the dominant computer network technology. This document recommends using Ethernet for the Link and Physical layers because of this ubiquity, but also because Ethernet provides the necessary bandwidth and physical media for substation and control center LANs. 10 and 100 Mbit/second is supported for twisted-pair copper, coaxial cable, and fiber optic cable with existing work to standardize 1000 Mbit/second networks ongoing. The installation of Ethernet wiring and equipment is well understood and standardized.

2.2 Network layer

Internet Protocol (IP) forms the basis for the internet Protocol suite and therefore is the recommended Network layer protocol. IP provides a connectionless, best effort datagram delivery service to the transport layer protocols. Connectionless means that IP does not maintain any state information about the link so each datagram is routed independently of all others. Best effort delivery means that the protocol has mechanisms for routing the datagram and simple error reporting, but that delivery is not guaranteed. Reliability is left up to the transport layer protocol.

3 Transport layer

The Transport layer of the internet protocol suite consists of two distinct services, User Datagram Protocol (UDP) and Transmission Control Protocol (TCP). TCP shall be the primary transport service for DNP messages because of its reliably; UDP can be used on a high-reliability single-segment LAN and in specific cases where small pieces of non-critical data need to be sent or when broadcasting is required. UDP can also be used in specific cases as listed in table 3-1. Annex A describes why UDP cannot be used if the DNP messages must be routed over the utility enterprise or wide area network.

3.1 Protocol characteristics

3.1.1 UDP

UDP provides a connectionless service for sending datagrams between hosts. Sending one UDP datagram causes exactly one IP datagram to be sent. All that it adds beyond IP is the ability to exchange datagrams between multiple processes on a host and rudimentary error detection. UDP supports all the addressing modes of IP – unicast, multicast, and broadcast.

3.1.2 TCP

TCP provides a connection-oriented service for sending a stream of bytes between hosts. The protocol determines how to break the stream into IP datagrams based on the characteristics of the network. TCP insures that the same stream of bytes sent to the transmitting side of the connection will be available on the receive side. It accomplishes this using acknowledgements, sequencing of the data, and dynamic timer mechanisms. Lost or corrupted packets are retransmitted transparently to the higher layers. The only addressing mode supported by TCP is unicast. Multicast and broadcast are not applicable in a connection-oriented protocol.

3.2 Network Topologies

Following are the 3 possible network topologies in terms of IP routability from the perspective of a substation or remote LAN. Each topology diagram uses typical equipment on the various networks to illustrate basic

3


functionality. Clearly, many other types of devices can exist on enterprise wide area networks as well as on the substation LANs.

3.2.1 Network A

RTU/DataConcentrator

Ethernet

Master station Master station

Serial Link: Dedicated Radio Dial-up etc.

Server

Relays Meters OtherIEDs

ControlCenter LAN

SubstationLAN

Figure 3-1 Network Topology A

This is the most basic implementation of a substation LAN in that it doesn't provide for the ability to access substation components outside of the LAN. It does provide for IED-to-IED communication in addition to the normal RTU-to-IED communication. Figure 3-2 shows a typical data transfer path from an IED.

4



Ethernet

Master stationMaster station Master station


ServerServer


ControlCenter LAN

SubstationLAN

Figure 3-2 Network A IED Communication

DNP traffic could be transported in a couple of ways in this topology. The first method is to use TCP to establish a connection between the RTU/Data Concentrator (RTU/DC) and each IED. IEDs may also establish connections to share data. TCP provides a reliable connection between all devices.

The second method is to use UDP to transport all DNP frames since the messages do not need to be routed and, assuming a fairly high reliability LAN construction, the packet loss would be very low. DNP link layer confirmations shall be disabled. Application layer confirmations shall be used as recommended in the technical bulletin [Ref. 13]. If broadcast messages are required, UDP must be used since TCP is strictly a point-to-point protocol. Unsolicited responses are recommended for both TCP and UDP to improve efficiency.

An alternate method, mentioned here because of its simplistic client implementation, would be to use UDP to broadcast all DNP Link Layer frames to the network and let each device determine its messages based on the DNP destination address. This method is equivalent in functionality to a RS-485 network with the addition of defined media access and higher baud rate. The advantage of this method is that it is very easy to implement in code and has the lowest possible RAM requirements. The disadvantages are: • An IED designed exclusively for this network cannot be used in networks requiring that the IP datagrams be

routed. • Since all the frames would have the destination address set to the subnet broadcast address, all hosts would

have to process all messages up through the transport layer and all DNP hosts would have to process the message through the DNP Link layer. This is a tremendously inefficient use of the network bandwidth and processing on all network hosts.

For these reasons, this method must not be used.

5


3.2.2 Network B


Ethernet

Master stations

EnterpriseWAN


Router

FiberPPPDigitaletc.

SubstationLAN

Router

PCs/Workstations

Servers

Remote workstation

PPP

Gateways

To other parts ofenterprise network

ControlCenter LAN

Figure 3-3 Network Topology B

This implementation of a substation LAN provides access to substation components through the utility enterprise. Figure 3-3 represents a typical example given by most substation LAN standards currently under development. IED-to-IED, RTU-to-IED, and enterprise-to-IED communications are supported. Figure 3-4 shows a typical data transfer path from an IED.

6



Ethernet

Master stations

EnterpriseWAN


Router

FiberPPPDigitaletc.

SubstationLAN

Router

PCs/Workstations

Servers

Remote workstation

PPP

Gateways


ControlCenter LAN

Figure 3-4 Network B IED Communication

All devices on the substation LAN must support TCP connections since the IP datagrams are routed (see Annex A). UDP can be used for non-critical data such as Virtual Terminal objects or device monitoring outside of the normal SCADA command and control loops. As in topology A, UDP provides the ability to broadcast frames so that a device can share data with other LAN devices efficiently.

7


3.2.3 Network C

DataAcquisition

Unit

Ethernet

Master stations

EnterpriseWAN


Router

RemoteLAN

Router

PCs/Workstations

Servers

Remote workstation

PPP

Gateways


ControlCenter LAN

Router


Figure 3-5 Network Topology C

This implementation of a remote LAN provides access to devices only through a routed communication link. For example, imagine a remote station requiring periodic monitoring but not full RTU functionality. The Data Acquisition Unit (DAU) could potentially handle multiple remote stations. The Master Stations would then access the remote data via the DAU. Figure 3-6 shows a typical data transfer path from an IED.

8


DataAcquisition

Unit

Ethernet

Master stations

EnterpriseWAN


Router

RemoteLAN

Router

PCs/Workstations

Servers

Remote workstation

PPP

Gateways


ControlCenter LAN

Router


Figure 3-6 Network C IED Communication

All devices in this topology must support TCP. UDP cannot be used between an IED and the Data Acquisition Unit and only makes sense if an IED wishes to communicate with another IED on the remote LAN.

3.3 Summary

All devices shall support both TCP because of its reliable delivery characteristic over all network topologies and UDP because of the potential uses of broadcasting, its efficiency when small pieces of non-critical data need to be transported, and when operating over a high reliability, single segment LAN. For example, UDP would be appropriate when many computational nodes require a common IED value but the stability of the system is not compromised if a few values are lost. Table 3-1 shows which transport layer to use in the various cases.

9


Protocol TCP UDP Use in the case… • Most situations

requiring point to point communications

• Mesh topology WAN

• Broadcast on a LAN • Equivalent to TCP on high-reliability

single-segment LAN • More economical for pay-per-byte, non-

mesh WAN, e.g. Cellular Digital Packet Data (CDPD).

• Low priority data, e.g. data monitor or configuration

Table 3-1 Appropriate use of transport layer

4 DNP Layers

The three protocol layers of DNP are integrated together to form what the Basic 4 documents call the Enhanced Performance Architecture (EPA). Essentially, the functionality called out in the OSI 7-Layer model is either not needed in DNP or has been combined to simplify the design of DNP compatible devices. The three layers of DNP work together and cannot be separated without adding capabilities to a layer that are already contained within another layer.

For example, one might consider extracting the DNP Application layer and transporting it directly over the internet protocol suite. But, the Application layer doesn't have any addressing mechanism; this is contained in the Link Frame. Using only the IP addresses precludes having more than one DNP entity (i.e. virtual RTUs) per IP address. TCP doesn't have error detection that is adequate for the critical nature of SCADA data; this is also in the Link Frame. The Application Layer has no means for determining the start of a new message in the serial stream; the start characters and length field in the Link Frame provides this. Therefore, since the protocol requirements of DNP are present in all three layers, there is no need to break them apart.

This architecture provides an additional benefit for vendors in that they can share most of the DNP code with existing serial channel implementations. The only difference comes in the interface to the internet protocol suite which is very similar to a serial port in that TCP also provides a stream of data with no packet or frame demarcations.

4.1 Confirmations

Link layer confirmation shall be explicitly disabled when communicating via the internet protocols. TCP has its own very robust mechanisms for insuring data delivery. UDP does not have such a mechanism, but its uses are limited to cases where the reliability of the communications medium is very high or the transported data is not critical.

Application layer confirmations may still be used in accordance with subset and technical bulletin recommendations [Ref. 13].

4.2 Keep-alive timer

If the server-side of a TCP connection goes down and comes back up, the client-side has no way of knowing until it sends a message to the server and receives the RST flag in the TCP header. If an outstation is operating in an unsolicited mode, this could be minutes depending on the scheduling of integrity polls. Therefore, it is necessary to add some type of keep-alive timer to allow clients to periodically determine the on-line status of servers or peers.

Note: If the client-side of a TCP connection goes down, it will presumably try to reconnect when it comes back up. The server will process this request, close the existing connection, and reconnect.

10


TCP offers such a timer, but a typical implementation is 2 hours, which is not sufficient for the critical nature of the data carried by DNP. Note: some internet protocol implementations allow this timeout to be changed, but this capability is not universal.

The recommended message to use for such a timer is the Link Layer Request Status message (0xC9). It is very low overhead for the devices and is already supported at all subset levels. A suitable time would be once every 10 seconds (although it should be configurable) after there has been no other activity from that device. To facilitate interoperability, the keep-alive timer shall be supported by all devices. However, it must be possible to disable via configuration for cases where the normal application layer traffic (e.g. polling) provides on-line status detection.

4.3 Multiple frames in UDP

If UDP is used in one of the cases specified in section 3.3, a receiver must be capable of parsing multiple DNP Link Layer frames from a UDP fragment.

4.4 Broadcast Address

If UDP is used to broadcast a datagram to multiple devices on a LAN, the DNP address must be set to 0xFFFF and all logical DNP devices at all IP addresses within the domain of the broadcast must receive the encapsulated DNP frame.

5 Security

In a point-to-point serial channel, DNP devices are protected from inadvertent or hostile access by the physical nature of the connection. If DNP is going to be transported over an enterprise wide network, a method for controlling access needs to be defined by the vendor of each device. Each device needs to be configured such that only the intended connections are made. This requires setting the IP address of the server host at the client side and setting the IP address of the client host (or list of clients) at the server side. Servers then must use the IP address to validate client requests and make the appropriate logical port connections. This feature shall be supported by all devices, however it must be possible to disable via configuration.

A server may wish to enable only one connected client at a time or provide for a failover capability, e.g. if a client fails then another client can connect with the server and continue the service that was provided by the failed client. [Ref. 12]

The valid host IP addresses can only be set in a secure manner. Some possibilities for doing this include, but are not limited to: • A local interface using a proprietary program. • A simple HTTP server with password accesses to the configuration information. Using HTTP in this manner

avoids having to invent new DNP objects to carry both the configuration info and the security info. • A terminal-like interface using Virtual Terminal objects over UDP (see Technical Bulletin 9804-004).

Each equipment vendor will have to determine an appropriate method.

6 Time Sync

All time synchronization shall be done at the local network only. It is not practical to do time sync over IP routers as their delays are typically not consistent and vary based on network loads. The Network Time Protocol (NTP) is too large and requires too many resources to be appropriate for DNP. The source of the time at the local network shall be chosen as required by the system.

11


The time synchronization method defined in Chapter 6 of the Application Layer document is not appropriate for a high-speed (relative to RS-232) LAN because: • The propagation delay measurement is negligible [Ref. 2]. • The internet protocol stack causes a variable delay between DNP and the network. • Recording the time at the first bit of the first byte does not account for network collisions.

In the following procedure, the Master station is defined as the host on the LAN with the accurate time source. See Annex B for a complete description of the new function code and object.

6.1 Desired Behavior

Since the propagation delay on an Ethernet LAN is very small, the offset time between the Master Station and the Outstation can be measured directly. The following procedure outlines a method for both hosts to record their time at the same instant, namely, when the last character of a message is transmitted from Master Station and received at the Outstation. The difference in these times represents the offset between the two hosts and can be used as a correction factor in the Outstations.

6.2 Procedure 1. The Master station sends a Record Current Time (FC 24) request to the outstation. The Master records the

time of transmission of the last octet sent to the network (denote this as MS_Time). 2. The Outstation receives the message and records the time of reception of the last octet (denote this as

OS_Time). It returns a Null Response. 3. The Master Station issues a Write request with a Time And Date at Last Recorded Time object (obj 50, var

3) containing the value MS_Time. The Outstation calculates the offset (MS_Time – OS_Time). The Outstation can set its clock accordingly or apply the offset when event times are reported.

This procedure can also use broadcast messages to synchronize multiple Outstations simultaneously since the Record Current Time request is received at all hosts on the LAN at the same instant. The Master would utilize UDP to send the broadcast datagram, and all Outstations that need synchronization must be capable of accepting this datagram.

12


Ethe

rnet

driv

er a

nd h

ardw

are

inte

rnet

sta

ck

DN

P

DN

P

Ethe

rnet

driv

er a

nd h

ardw

are

inte

rnet

sta

ck

LAN Media

Tim

e

Record CurrentTime (FC 24)

Time & Date atLast Recorded Time

(Obj 50, Var 03)

Master Station Outstation

Null Response

MS_TimeOS_Time

MS_Time_DNP

OS_Time_DNP

Calculate offset

offset = value in Time & Date Obj minus time when Record CurrentTime Obj received

Desired caseoffset = MS_Time - OS_Time

Figure 6-1 Time line for synchronization

6.3 Driver requirement

As in the serial channel time synchronization, the procedure is handled with application layer messages. However, this procedure requires that the Ethernet driver provide the ability to record the last octet time on transmission and receive. The time sync process is greatly influenced (and varied) by processor speed, interrupt latencies, internet protocol stack design, etc. Time resolution to the millisecond level cannot be accomplished without this capability.

If a device (Master or Outstation) cannot record time at the Ethernet driver, it should do so as close as possible to the internet stack interface (shown in Figure 6-1 as MS_Time_DNP and OS_Time_DNP). As noted, this introduces an error factor in the synchronization process. A device may wish to minimize this error by adding (at the Master end) or subtracting (at the Outstation end) a predetermined value that reflects an average delay through the internet stack and Ethernet driver. This "fudge factor" does not take into account the delay caused by Ethernet collisions and retransmission. However, it may reduce the average error to a level that can be tolerated in the system.

7 Socket requirements

The following discussion assumes the use of some variation of the sockets API, either Berkeley or Winsock derived, in order to implement DNP over the internet protocol suite. For information on the sockets API, see [Ref. 5].

7.1 Background

TCP client The side of the link that calls the connect() function to initiate the connection on a socket.

TCP server The side of the link that calls the listen() function to wait for a connection request on a socket.

13


For a TCP connection to take place, one side must be the server and one side must be the client. The client requests a connection by specifying the IP address and port number of the server. Once the connection is made, data is transferred without either side having to specify the IP address and port number. For UDP (connection-less) communications, each side includes the address and port number with each transmission. Each host that receives a UDP datagram is then provided with the sending host address.

7.2 TCP/UDP Port Number for DNP

All devices shall support TCP and UDP communications on port number 20000. This number has been registered with the IANA (Internet Assigned Numbers Authority) for use with DNP. All connection requests and all UDP data are sent to this common port number.

7.3 Making TCP connections

Making a TCP connection between two devices can be viewed conceptually as replacing the traditional serial port communication link with a sockets interface over the network. For example, figure 7-1 shows the typical communication links between two Master Stations and an IED.

Master Station A

DNPCommunication

Object

Serial Port Driver

RS232

RTU/IED

DNPCommunication

Object

Serial Port Driver

RS232

Master Station B

DNPCommunication

Object

Serial Port Driver

RS232

DNPCommunication

Object

Serial Port Driver

RS232

LogicalRTU(s)

LogicalRTU(s)

Dedicated lineRadioDial-up

etc.

Dedicated lineRadioDial-up

etc.

Figure 7-1 Serial port communications

Now, replace the serial communication with an Ethernet network, internet protocol stack, and sockets interface.

14


Master Station A

DNPCommunication

Object

Socket A

Ethernet

RTU/IED

DNPCommunication

Object

Socket A

Master Station B

DNPCommunication

Object

Ethernet

DNPCommunication

Object

Socket B

LogicalRTU(s)

LogicalRTU(s)

Hub

Ethernet

IP/Ethernet driver

Socket B

IP/Ethernet driver

IP/Ethernet driver

Figure 7-2 Network communications

All of the DNP components stay the same; the only part that changes is the lowest level communications drivers. In fact, since TCP accepts a stream of data just like a serial port, the interface between the DNP Communication Object and the lower level driver can also remain virtually the same.

For a network in which all devices are continually present and available, it is recommended that:

If the device is a data provider (e.g. IED, meter, RTU, etc.), it should be the server end of the connection-oriented (TCP) socket. It may be capable of supporting multiple logical ports on a device.

Each data user (e.g. Master Station, RTU/Data Concentrator, peer IED, etc.) should initiate the connection as the client end of the connection-oriented (TCP) socket.

For a network in which some devices need to establish a communication link before joining the network (e.g. SLIP/PPP dial-up):

The data provider may initiate the connection as the client and the data user will have the listening socket.

Requirements

Data providers shall, at minimum, support the server end of a TCP connection (i.e. be capable of accepting connection requests on a listening socket). If a data provider has the capability to join a network but not be continuously accessible (e.g. dial-up), it shall support the client end of a TCP connection (i.e. be capable of initiating connection requests). Data users shall be configurable to support both ends (client and server) of the socket connection to insure universal support for all data providers and all system architectures. All devices shall be capable of simultaneously accepting messages via the connectionless (UDP) port and the connection oriented

15


(TCP) port. If there are multiple DNP logical entities within the device, the messages must be routed to the correct entity (e.g. virtual device, logical RTU, etc.).

7.4 Broken connections

If a DNP/TCP connection is made and one of the devices losses power or inadvertently resets, there must be mechanisms to inform the other device so that the connection can be reestablished.

If the server-side goes down:

When the next message is sent (see section 4.2 regarding DNP keep-alive messages), the server will send a TCP packet with the RST flag set. This will cause subsequent calls to recv() or select() to return an error if the socket is non-blocking or the send() call will fail if the socket is blocking. The client must close the current connection and reconnect.

If the client-side goes down:

When the client-side restarts and attempts a new connection, the server will process this request, close the existing connection, and reconnect.

7.5 Typical architecture

Figure 7-3 illustrates the architecture of a device that supports TCP client, TCP server, and UDP connections. Two TCP server connections are shown to illustrate how connection requests are controlled by the TCP Manager object. It is recommended that each DNP Port be configured with the peer IP address. This allows for each connection request to be validated in a secure manner (by the TCP Manager in this example) and each UDP datagram to be routed to the correct DNP Port. If a device supports multiple logical entities (i.e. logical RTUs), it must be able to configure these entities to use a single DNP Port.

16


Phys

ical

and

Link

Lay

ers

Ethe

rnet

Connection requests

Client-side socketdriver

Connection request

sockets API

Inte

rnet

Pro

toco

l

LogicalRTU(s)

LogicalRTU(s)

LogicalRTU(s)

Server-sidesocket driver

LogicalRTU(s)

TCP Data Server-sidesocket driver

TCP Data

TCP Data

UDP Datagrams

DNPcommunication

object

UDP Router- to all ports

UDP Only driver

DNPcommunication

object

DNPcommunication

object

DNPcommunication

object

TCP Manager- TCP Listening socket- validate connections

Figure 7-3 Example sockets architecture

17


8 References [1] DNP V3.00, Basic 4 Document Set [2] Gilchrist, Grant. "Proposal for Use of Distributed Network Protocol in Substation LANs." Harris Distributed

Automation Products, version 0.2. Dec. 11, 1996. [3] Falk, Herbert. "Comments on 'Proposal for Use of Distributed Network Protocol in Substation LANs'."

SISCO. Jan. 14, 1997. [4] Stevens, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. Addison Wesley Longman, Reading, MA.

1994. [5] Stevens, W. Richard. UNIX Network Programming, Volume 1, 2nd Edition. Prentice Hall, Upper Saddle River,

NJ. 1998. [6] Miklovic, Daniel T. Real-time Control Networks. Instrumentation Society of America, Research Triangle

Park, NC. 1993. [7] Postel, J., Ed. "Internet Protocol." SRI International, Menlo Park, CA, Sept. 1981. RFC-791. [8] Postel, J., Ed. "Transmission Control Protocol Specification." SRI International, Menlo Park, CA, Sept. 1981.

RFC-793. [9] Postel, J., Ed. "User Datagram Protocol." USC/Information Sciences Institute, September 1981. RFC-768. [10] Mogul, J. and Deering, S., "Path MTU Discovery." Nov. 1990. RFC-1191. [11] Kent, C.A., and Mogul, J.C., "Fragmentation Considered Harmful." Computer Communications Review, vol.

17, No. 5, pp.390-401. Aug. 1987. [12] Phillips, John. "Transporting DNP 3.0 over Local and Wide Area Networks." Foxboro Australia Pty Limited,

version 0.1, September 23, 1998. [13] DNP V3.00 Technical Bulletin 9804-002. DNP Confirmation and Retry Guidelines.

18


ANNEX A (informative) TCP vs. UDP in a Wide Area Network

It has been proposed that User Datagram Protocol (UDP) be used for transporting DNP in a network. The only features that UDP adds to the underlying IP protocol is port addressing and a 16-bit checksum. All of the other requirements for transporting the sensitive, time critical SCADA information would have to be handled by DNP. DNP includes a number of transport layer capabilities. But since DNP was designed for RS-232 and RS-485 type serial communications, it does not contain all of the necessary mechanisms for an enterprise wide internet. For example:

• Reordering of packets received out of order and detecting duplicate packets – the DNP transport layer only has a 6-bit sequence number. In a large internet, packets can arrive out of order since each packet is routed independently and may traverse totally different paths (different speeds). 64 sequence numbers is not enough if, for example, an internet contains a combination of slow serial links (PPP or SLIP connections) and LFNs (Long Fat Networks = networks with high bandwidth-delay products). [Ref. 3].

• Timeout and retransmission – Clearly, the requirements for a local serial network versus an internet are different. In a local network, the route and round-trip time (RTT) for IP packets remains relatively constant. On an internet, the RTT can change from packet to packet due to such factors as increased congestion on individual routes, equipment failures, etc. Timeouts must be adaptive to account for these cases.

• Fragmentation – IP has no timeout or retransmit capabilities as well as no capabilities for transmitting individual fragments. So, if the datagram is fragmented in IP and one of the fragments is lost, the entire datagram (1 or more DNP Link Layer frames) must be retransmitted. DNP can handle this by either confirming all Link Layer packets or by throwing away the entire Application Layer fragment and letting the sending station timeout and retransmit. Both cases have real performance issues [Ref. 2].

The maximum size of a datagram using the DNP Link Layer on UDP/IP is 320 octets (maximum DNP link frame size (292 octets) + 28 octets for the UDP/IP headers). For most networks, the minimum datagram size is 576 octets with two notable exceptions. First, the IP specification states that the minimum datagram size that a module must handle is 68 octets (RFC-791 IP). Modules that have this limitation are rare. Second, if the Point-to-Point Protocol (PPP) is employed in the network, the MTU (Maximum Transmission Unit)decreases to 296 octets for a low delay link (RFC-1191). Clearly, the frame "packing" proposed in [Ref. 2] will exasperate the problem. See Ref. 11 for further arguments as to why fragmentation should be avoided.

Transmission Control Protocol (TCP) is a much better choice for transporting DNP data over a WAN. TCP insures that the same stream of bytes sent to the transmitting side of the connection will be available on the receive side. It accomplishes this using acknowledgements, sequencing of the data, and dynamic timer mechanisms. Lost or corrupted packets are retransmitted transparently to the higher layers. TCP addresses the above internet deficiencies of DNP in the following manner:

• TCP uses a 32-bit sequence number and a 32-bit acknowledge number to insure that data is received in order.

• TCP manages 4 timers for each connection – a retransmission timer for expected acknowledgements, a persist timer to keep window size information flowing, a keepalive timer for detecting if one end of the connection goes down without warning, and a maximum segment lifetime timer for completing a disconnection operation. TCP adapts its retransmission timer to the conditions of the connection.

• TCP tries to avoid fragmentation by allowing both sides of a connection to optionally specify the maximum segment size (MSS). If the destination IP address is "nonlocal", the MSS normally defaults to 536.[Ref. 4 p. 237] Furthermore, RFC1191 outlines a way for hosts to determine the path MTU for paths that may include lower MTU connections. Since fragmentation is handled by TCP, DNP Link Layer confirms are not needed and performance is only limited by the characteristics of the connection, not by DNP.

19


In addition, TCP includes such features as packet reduction using the Nagle algorithm, sliding data windows to allow multiple packets before acknowledgements, congestion avoidance for links with slow segments, and repacketization to increase performance. Obviously, all of these features come at a price, albeit a fairly reasonable one. For one popular embedded implementation, the ROM requirement for the full internet protocol stack is 115K; RAM is 25K + 4K/socket. Considering that most devices on a DNP network will have to maintain only 1 connection to a data concentrator of some sort, this is very small. At 4K/socket, this is reasonable and scalable. If devices wish to establish IED-to-IED communications (i.e. to share data points), the number of sockets is still low since this would typically be required in only a few devices on the network.

20


ANNEX B (normative) Additions to Existing documents

New Function Code (24)

B.1.1 Changes to Table 3-1 in the Application Layer document

Time Synchronization Function Codes 23 Delay Measurement …

24 Record Current Time Used in a network application to allow the Master Station and the Outstation to record their time at the same instant.

Reserved 25-120 Reserved for future use

B.1.2 Addition to Chapter 4 in the Application Layer document 4.25 RECORD CURRENT TIME (FUNCTION CODE 24) This function is used to in a network application to allow the Master Station and the Outstation to record their time at the same instant. It is the first step in the network time synchronization process. Time is recorded by the Master Station when the last character of a message is transmitted. Time is recorded at the Outstation when the last character of the message is received. The difference in these times represents the offset between the two hosts and can be used as a correction factor in the Outstation.

AC FC = 24 Figure 4-45 Master Request to Record Current Time The Outstation responds with a Null Response

New Object (Obj 50, Var 03)

B.2.1 Addition to Data Object Library document TIME AND DATE AT LAST RECORDED TIME Data Object 50 - Variation: 03 Description: The time and date at last recorded time object is an information object that represents the absolute time of day and date when the last Record Current Time function code was send. This object should be used for time-synchronization in networked applications.

21


Object Coding:

Absolute Time

7 6 5 4 3 2 1 0

15 14 13 12 11 10 9 8

23 22 21 20 19 18 17 16

31 30 29 28 27 26 25 24

39 38 37 36 35 34 33 32

47 46 45 44 43 42 41 40 Absolute Time = UI48 [0..47] <0..248-1, msec> Narrative: Absolute Time is recorded as milliseconds since midnight, January 1st, 1970, at zero hours, zero minutes, zero seconds, and milliseconds.

22

DNP3 TRANSPORT FUNCTIONS

Version 0.02

01-August-2000

DISCLAIMER STATEMENT DNP User Group documents and publications are not consensus documents. Information contained in this and other works has been obtained from sources believed to be reliable, and reviewed by credible members of the DNP User Group and/or the DNP User Group Technical Committee. Neither the DNP Users Group nor any authors/developers of DNP documentation guarantee, and each such person expressly disclaims responsibility for ensuring, the accuracy or completeness of any information published herein, and neither the DNP Users Group nor its authors/developers shall be responsible for any errors, omissions, or damages arising out of use of this document.

Likewise, while the author/developer and publisher believe that the information and guidance given in this work serves as an enhancement to users, all parties must rely upon their own skill and judgment when making use of it. Neither the author nor the publisher assumes any liability to anyone for any loss or damage caused by any error or omission in the work, whether such error or omission is the result of negligence or any other cause. Any and all such liability is disclaimed.

This statement was developed by the DNP User Group Technical Committee and represents the considered judgment of a group of software developers with expertise in the subject field. The DNP User Group is a global forum for users and implementers of the protocol and promotes implementers and developer information and interaction exchange. This work is published with the understanding that the DNP User Group and its authors/developers are supplying information through this publication, not attempting to render engineering or other professional services. If such services are required, the assistance of an appropriate professional should be sought. The DNP User Group is not responsible for any statements and/or opinions advanced in this publication.

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 DNP Protocol cannot be made without express written agreement from the DNP Users Group or its duly authorised 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 authorised by the DNP Users Group.



Copyright 2000 DNP Users Group. All rights reserved.

DNP3 Transport Functions - Version 0.02 Page i

REVISION HISTORY

Version Date Revision Description

0.00A 8-Nov-1992 Preliminary release by Malcom Smith.

0.01 20-Aug-1993 Revised after review by J. Bhat.

0.01 01-Sep-1993 Corrections by C. Huene.

0.01 30-May-1997 Converted to MS Word 6.0

0.02 10-July-2000 Rewritten with additional clarification. References to Harris Corporation removed. Removed transport services and responsibilities because transport is function not layer. Removed glossary of terms and abbreviation sections.

DNP3 Transport Functions - Version 0.02 Page ii

CONTENTS 1 OVERVIEW .......................................................................................................................................... 1 2 TRANSPORT FUNCTION DESCRIPTION......................................................................................... 1

2.1 Transport Header .............................................................................................................................. 1 2.1.1 FIN field................................................................................................................................ 1 2.1.2 FIR field ................................................................................................................................ 1 2.1.3 SEQUENCE field.................................................................................................................. 2 2.1.4 Rules ..................................................................................................................................... 2

2.2 Application Layer Data .................................................................................................................... 2 2.2.1 Rules ..................................................................................................................................... 2

2.3 Reception State Table....................................................................................................................... 3 2.4 Reception State Diagram .................................................................................................................. 4 2.5 Segmenting Example........................................................................................................................ 5

DNP3 Transport Functions - Version 0.02 Page 1

1 OVERVIEW The size of a DNP3 application layer message fragment may be larger than the number of octets permitted in a single data link layer frame. The transport function disassembles application layer fragments into data link layer-sized data units for transmission and reassembles these pieces into the original application fragment on reception.

At the transmission site, an application layer fragment is broken into smaller pieces, and a header is added containing sequencing information for each piece. The header and application data form a transport layer segment that is passed to the link layer. Segments are always passed one-at-a-time, in sequence, from the first to the last. The link layer throttles or paces the acceptance of segments by returning an indication of success or failure to send each segment.

Transport segment Header Application Layer Data

← 1 octet → ← from 1 to 249 octets →

At the receiving site, segments passed from the link layer are checked for sequencing by examining the header. Any segments that are received out of order are discarded. Only when a complete application fragment is assembled does the transport function notify the application layer that it is available.

2 TRANSPORT FUNCTION DESCRIPTION

2.1 Transport Header The transport header consists of a single octet. The header is the first octet in a segment. A header is prepended to each piece of application layer data before submission to the link layer for transmission, and upon receipt of a segment from the link layer, the header is stripped away before assembly of an application fragment.

The transport header is composed of three fields as follows:

Header Bit Definitions Bit # 7 6 5 4 3 2 1 0 Fields FIN FIR SEQUENCE

2.1.1 FIN field The FIN field is a single bit, which when set, indicates that this is the final or last segment in the fragment.

FIN = 0 indicates more segments follow.

FIN = 1 indicates the final segment in a series of segments.

2.1.2 FIR field The FIR field is a single bit, which when set, indicates that this is the first segment in the fragment.

FIR = 0 indicates this is not the first segment in a series of segments.

FIR = 1 indicates this is the first segment in a series of segments.


2.1.3 SEQUENCE field The SEQUENCE field is 6 bits wide. It is used to verify that segments are received in the correct order and guards against duplicated or missing segments. It has a range of 0 to 63. Sequence numbers increment by one count, modulo 64, for each segment in a series of segments that hold an application layer fragment. After sequence number 63, the next value is 0.

Definition: The term “segment-series” is used to describe a series of transport segments where each segment after the first has a sequence number incremented by one from the preceding segment.

2.1.4 Rules 1. A segment-series may only begin with a segment having the FIR bit set.

2. A segment-series ends with a segment having the FIN bit set.

3. When a segment is received with the FIR bit set, any previously received, unterminated segment-series shall be discarded and a new segment-series shall be started with the newly received segment as its first member.

4. When no segment-series is in progress, any segment received without the FIR bit set shall be discarded.

5. A segment with the FIR bit set may have any sequence number from 0 to 63 without regard to prior history. Nevertheless, it is recommended that a transmitter increment the sequence number by one count (modulo 64), for segments with the FIR bit set, above the sequence number it placed in the previously transmitted segment.

6. After a segment-series has been started: Each subsequent segment received must have a sequence number which is incremented by one (modulo 64) from the preceding segment. A segment received that meets this requirement becomes the next member of the segment-series. A segment received having the FIN bit cleared and the identical sequence number as the preceeding segment shall be ignored. A segment received having the FIN bit set and the identical sequence number as the preceeding segment, or a segment received containing any sequence number other than the expected incremental number, shall be discarded and shall also cause the entire in-progress, segment-series to be terminated and discarded.

7. A segment-series may consist of a single segment having both FIR and FIN bits set.

8. When a complete segment-series is assembled, only then may its application data be passed to the application layer.

2.2 Application Layer Data Each segment contains between 1 and 249 octets of application layer data.

2.2.1 Rules 1. Customarily, every segment, except the last in a segment-series contains exactly 249 octets of application

layer data. The last segment only needs to be large enough to hold the remainder of the application data. However, this is not a requirement. Any segment may contain between 1 and 249 octets. The transport function in a receiving station must accept any sized segment and be able to properly reassemble the application layer data.

2. The application layer presents a buffer containing an application layer fragment to the transport function for segmenting. The octets in the fragment buffer are numbered starting from 0 as illustrated in section 2.5. The application data piece having octet number 0 is transported by the first segment, that is the segment with its header’s FIR bit set and sequence number N. The next application data piece, if there is one, is then placed into a segment having sequence number (N + 1) modulo 64. This pattern, where application data pieces with lower octet numbers are placed into transport segments before pieces with higher octet numbers, continues until the last piece is sent. At the receiving end, application layer fragments are reassembled in the same order.


3. Each segment transports a unique set of octets from an application layer fragment. The application data is positioned within the segment immediately after the transport header. The application data octet with the lowest octet number appears first, adjacent to the header, and is followed by the remainder of the application data piece in octet order.

2.3 Reception State Table Assume the transport function software has a fragment buffer where application data from the received segments are stored before presenting the fragment to the application layer.

The software requires two states for proper operation.

1. Idle state: The software is idle waiting for a segment to arrive with the FIR bit set.

2. Assembly state: The fragment buffer holds application data from at least one segment. While in this state, the software is awaiting additional segments to complete a fragment.

Keys for understanding the table:

• X means don’t care.

• SAME means the sequence number is identical to the sequence number in the segment immediately preceeding this segment.

• +1 means the sequence number is incremented by one count, modulo 64, from the sequence number in the segment immediately preceeding this segment.

• +M, 1 < M < 64 means the sequence number is incremented by more than one count and less than 64 counts from the sequence number in the segment immediately preceeding this segment.

And the transport header in the receive segment is

If the software state is FIR FIN SEQ

then perform this action and go to this state

0 X X Discard segment. Idle

1 1 X Dump contents of fragment buffer, add segment’s data to fragment buffer and pass fragment buffer to application layer.

Idle Idle

1 0 X Dump contents of fragment buffer and add segment’s data to fragment buffer. Assembly

0 0 SAME Ignore segment. Assembly 0 1 SAME Discard segment. Idle

0 0 +1 Append segment’s data to contents of fragment buffer. Assembly

0 1 +1 Append segment’s data to contents of fragment buffer and pass fragment buffer to application layer. Idle

0 X +M 1 < M < 64 Discard segment. Idle

1 0 X Dump contents of fragment buffer and add segment’s data to fragment buffer. Assembly

Assembly

1 1 X Dump contents of fragment buffer, add segment’s data to fragment buffer and pass fragment buffer to application layer.

Idle


2.4 Reception State Diagram See text at beginning of section 2.3. The same applies to this diagram.

IdleState

AssemblyState

Pass fragmentbuffer to application

layer

Discardsegment

Discardsegment

Pass fragmentbuffer to application

layer

FIR=1,FIN=1,SEQ=X

FIR=0,FIN=X,

SEQ=+M,1<M<64

FIR=1,FIN=0,SEQ=X

Append segmentto fragment buffer

Add segmentto fragment buffer

Dump contentsof fragment buffer

Dump contentsof fragment buffer

Add segmentto fragment buffer

Append segmentto fragment buffer

Ignore segment FIR=0,FIN=0,

SEQ=SAME

FIR=0,FIN=0,

SEQ=+1

FIR=0,FIN=1,

SEQ=SAME

FIR=1,FIN=0,SEQ=X

FIR=1,FIN=1,SEQ=X

FIR=0,FIN=1,

SEQ=+1

FIR=0,FIN=X,SEQ=X


2.5 Segmenting Example The following example illustrates the transport function. Application layer octet numbers are shown inside the elements. The letters “TH” stand for Transport Header. Octets are transmitted in left-to-right order.

Example Application layer fragment: 600 octets transported in 3 pieces 0 1 … 247 248 249 250 … 496 497 498 499 … 598 599 ← 1st piece → ← 2nd piece → ← 3rd piece →

First transport segment: 0 1 … 247 248 TH ← 1st application data piece →

Transport header: FIR = 1, FIN = 0, SEQUENCE = n (any number 0–63, e.g.: 25).

Second transport segment: 249 250 … 496 497 TH ← 2nd application data piece →

Transport header: FIR = 0, FIN = 0, SEQUENCE = (n+1) modulo 64 (e.g.: 26).

Last transport segment: 498 499 … 598 599 TH ← 3rd application data piece →

Transport header: FIR = 0, FIN = 1, SEQUENCE = (n+2) modulo 64 (e.g.: 27).

DNP 3 Counter Objects Proposed Change for “Delta Counter” Variations

May 31, 2001 Issue The DNP Technical Committee has determined that Delta Counter variations for Counter Objects

• Are not well defined, • Create a potential for unrecoverable loss of data, and • Provide no functionality not available through other Counter Object variations

Therefore, the Technical Committee is proposing to remove Delta Counter variations from DNP3 protocol. Discussion The DNP Technical Committee has received several inquiries regarding operations and definitions related to Binary and Frozen Counters, objects 20, 21, 22, and 23. These have led to an internal review of counter objects with the goal of producing a technical bulletin clarifying the issues presented. DNP allows Counters to be reported as either Current or Delta values. The Current value of a Binary Counter or Binary Counter Event point is the value of an underlying Counter at the time a read request is processed. The Current value of a Frozen Counter or Frozen Counter Event point is the value of an underlying Counter at the time that the most recent freeze request was processed. The Delta value of a Counter point is the difference between the Current value at the time of read, and the Current value when the Counter was last successfully reported to the master. The Technical Committee has uncovered serious concerns regarding the use of “Delta Counters”. These concerns are based on the following two facts: 1. A RTU cannot always determine that a master has received its most recently transmitted message. In

such a case, a retransmission is required to insure delivery. 2. A master cannot always determine if a message containing counter information has been previously

received. The above example case occurs when RTU data is sent with application confirm services. The master receives the message and transmits a confirm, but the confirm is not received at the RTU. Data contained in the initial message is not identified by the RTU as having been delivered, and will eventually be retransmitted. In systems that use Delta Counter variations, the master will receive two reports with the same Delta value and incorrectly calculate the associated accumulation. An error of this type cannot occur when Current value variations are used. Summary and Resolution The DNP Technical Committee would appreciate comments from any DNP User Group Member regarding the proposal to remove Delta Counter variations from all Counter Objects. They are especially interested in comments from companies, if any, that are using Delta Counters in an active system. If accepted, this change has the potential of making existing implementations non-compliant with DNP-2002. Members should send their comments via Email to [email protected]. Please respond no later than June 30, 2001. Barring significant objections, a technical bulletin as proposed will be issued.

DNP Technical Bulletin TB2001-001 Page 1 of 1 Multiple Control Objects and Status Codes 15-December-2000

DNP Technical Bulletin TB2001-001

Multiple Control Objects and Status Codes 1 Issues: The DNP3 protocol permits a master to transmit a request containing multiple control objects, of type object 12 and variation 1, in the same message to a slave. Likewise, provision exists for sending messages with multiple analog output objects, of type object 41 and any variation, in the same request.

Many DNP3 slaves are able to queue or simultaneously output these objects. However, other devices can only output to a limited number of points—possibly just a single point—and may not be able to process a request containing a greater number of objects. DNP3’s Basic 4 documentation does not clearly explain how a device should behave or respond to a request containing more output objects than the device permits.

The DNP3 Level 3 Implementation table, paragraph 3.3, specifies an incorrect qualifier code for object 12, variation 2. Qualifier codes 17 and 28 should be replaced with code 07.

When a DNP3 outstation detects an error in a control or analog output request, it must return a non-zero status code. The existing status codes, 1 through 6, do not adequately describe all the error conditions, and additional codes are needed.

2 Resolution:

2.1 Response Status Codes New status codes 7, 8, 9 and 127 are defined and all status codes now have short identifier names. The complete list of codes appears in the following table.

Code Number

Identifier Name Description

0 SUCCESS Request accepted, initiated, or queued.

1 TIMEOUT Request not accepted because the operate message was received after the arm timer timed out. The arm timer was started when the select operation for the same point was received.

2 NO_SELECT Request not accepted because no previous matching select request exists. (An operate message was sent to activate an output that was not previously armed with a matching select message.)

3 FORMAT_ERROR Request not accepted because there were formatting errors in the control request (either select, operate, or direct operate).

4 NOT_SUPPORTED Request not accepted because a control operation is not supported for this point.

5 ALREADY_ACTIVE Request not accepted, because the control queue is full or the point is already active.

6 HARDWARE_ERROR Request not accepted because of control hardware problems. 7 LOCAL Request not accepted because Local/Remote Switch is in Local position. 8 TOO_MANY_OPS Request not accepted because too many operations requested. 9 NOT_AUTHORIZED Request not accepted because of insufficient authorization.

10 to 126 RESERVED Reserved for future use.

127 UNDEFINED Request not accepted because of some other undefined reason.

2.2 Master Requirements

2.2.1 Select-Operate

If a master receives a response to a select request, function code 3, and


• any of the objects contains a non-zero status,

• any of the objects are missing from the response or

• any of the IIN bits 2-0, 2-1, 2-2 or 2-4 are set,

then it shall not issue the subsequent operate command, function code 4. The slave’s behavior is not guaranteed when a master violates this rule.

2.2.2 Configurable

If a master has the capability to send multiple objects (binary or analog) in a single control output request, it must be configurable to send only one object per message.

2.2.3 Pattern Mask

If the master desires simultaneous execution of controls, it shall use a pattern control block and a pattern mask, object 12 variations 2 and 3, respectively. There is no guarantee that multiple controls will execute simultaneously unless a pattern control block and mask are used—and—the slave supports this type of operation.

2.3 Slave Requirements

2.3.1 Responses

The slave has the option to stop parsing the remainder of a request upon detection of the first error or continuing to the end of the request.

When a slave receives a control or analog output request—select, operate or direct operate—and one or more of the objects are unsuccessful, its response shall include one of these

• No objects if the request contains an unsupported function code or object variation.

• All of the objects.

• All of the objects up to and including the first unsuccessful object. This is a truncated response.

Each object returned in the response shall contain the appropriate status code indication. The IIN bits 2-0, 2-1, 2-2 and 2-4 shall be set or cleared as applicable. Note that the IIN bits only need to reflect the state of the first error detected.

Examples are presented in section 3.

2.3.2 Illegal Master Requests

If the master violates the rule in section 2.2.1 and issues an illegal operate command, the slave may take one of the following actions:

• Ignore the request and not operate any of the points.

• Execute those objects for which it returned a zero status code.

2.3.3 Pattern Mask

Slave devices are not required to implement Pattern Control Blocks (object 12, variation 2) or Pattern Masks (object 12, variation 3); nevertheless, level 3 slave devices must be able to parse messages containing these.

2.4 Pattern Control Block The correct qualifier code in the DNP3 Level 3 Implementation table, paragraph 3.3, for object 12, variation 2 is 07.

2.5 Device Profile The Device Profile Document of each slave device shall contain a statement specifying the maximum number of objects supported in a single request for objects 12 and 41. It shall also include a statement indicating whether it supports pattern control block - pattern control mask operations, and if so, what restrictions exist.


3 Examples The following table shows example responses from control or analog output requests containing four objects. These objects are identified as A, B, C and D. The responses are identical regardless of whether the requests are select, function code 3; operate, function code 4 or direct operate, function code 5.

Key: NR means Not Reported.

Response Status Codes IIN Bits Conditions in slave

when Request is received Obj A

Obj B

Obj C

Obj D

1.5

2.0

2.1

2.2

2.4

No errors are detected, all objects successful. 0 0 0 0 0 0 0 0 0 The function code is not supported regardless of which indexes the objects have. NR NR NR NR 0 1 0 0 0

The slave does not support the specific variation code in the request. NR NR NR NR 0 0 1 0 0

0 0 4 4 Indexes for objects C and D are beyond the maximum number of points installed in the slave. 0 0 4 NR 0 0 0 1 0

0 5 0 0 Object B is already executing when this request arrives. 0 5 NR NR 0 0 0 0 1

0 8 8 8 The slave can only control one object at a time. 0 8 NR NR 0 0 0 0 0

0 0 9 0 Object C is tagged or blocked to prevent its control. 0 0 9 NR 0 0 0 0 0

7 0 7 7 The Remote/Local Switch is in the Local position. 7 NR NR NR 1 0 0 0 0

A control output is requested and the Control Relay Output Block in Object D’s request contains an illegal control code.

0 0 0 3 0 0 0 0 0

An analog output is requested and the value in Object D’s request exceeds the permitted level. 0 0 0 3 0 0 0 0 0

4 Affected Documentation: Basic 4 Object Library, Object 12, Variation 1: Add sections 2.3 and 2.2 from above to the “Narrative”. Replace the listing of error codes with the table in section 2.1.

Basic 4 Object Library, Object 41, all variations: Add sections 2.3 and 2.2 from above to the “Description”.

Basic 4 Subset Definitions, Appendix A, Device Profile Document: In the section that begins with “Sends/Executes Control Operations: Add three lines beneath DIRECT OPERATE – ACK as follows:

• Maximum number of CROB (object 12, variation 1) objects supported in a single message ________.

• Maximum number of analog output (object 41, any variation) objects supported in a single message ________.

• Pattern Control Block and Pattern Mask (object 12, variations 2 and 3, respectively) supported. If so, describe any restrictions.

• CROB (object 12) and analog output (object 41) permitted together in a single message.

Basic 4 Subsets Definitions, Level 3 Implementation: The qualifier codes are replaced by a single code of 07 in the implementation table, paragraph 3.3, for object 12, variation 2.

5 Changes to the Subset Level 1 and 2 Certification Procedures:

5.1 Paragraph 8.2.1.1 – Desired Behavior in both certification procedures Change third bullet under device supports control operations to read, “The DUT responds to selecting an uninstalled control point by returning an error response with IIN2-2 set and a status code of 4.”


5.2 Paragraph 8.2.1.2.3, step 2 – Test Procedure in both certification procedures Change to read, “Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of 4.”

5.3 Paragraph 8.2.2.1 – Desired Behavior in both certification procedures Change first bullet under device supports control operations to read, “The DUT responds to a direct operate to an uninstalled control point by returning an error response with IIN2-2 set and a status code of 4.”


5.5 Paragraph 8.2.4.1 – Desired Behavior in both certification procedures After the second bullet, add a statement that says, “The following behavior assumes that the device supports control operations:”

Add a bullet below the new statement that says, “The DUT responds to requests having more points than are supported in a single message with a status code of 8 for at least the first point that is beyond the point count limit.”

Add a second bullet below the new statement that says, “The DUT responds to a select to an uninstalled control point by returning an error response with IIN2-2 set and a status code of 4.”

5.6 Paragraph 8.2.4.2 – Test Procedure in both certification procedures Replace items 1 through 6 as follows:

1. Review the device’s profile document to understand how many control points are supported in a single request. If this number is one, skip to step 7.

2. Determine the number of installed points that can be successfully controlled in a single request. This number shall be the smaller of

• The number of controls supported in a single request

• The number of installed control points

• Sixteen

In a single request, issue a select to the above number of points using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time.

3. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set and that each object returns a status code of 0.

4. Immediately issue a matching execute.


6. Verify that each of the selected controls operated. Note that controls may execute simultaneously or sequentially one after the other.

7. If the number of control objects supported in a single request is greater than or equal to either

• The number of control objects that fit into a single frame or

• The number of installed control points,

skip to step 13.

8. In a single request, issue a select to at least one more point than is supported in a single request, each point having a different index but otherwise able to be controlled, using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time.


9. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set, that each object except the last returns a status code of 0, and the last object returns a status code of 8.

10. If the DUT does not support direct operate, skip to step 13.

11. In a single request, issue a direct operate command to at least one more point than is supported in a single request, each point having a different index but otherwise able to be controlled, using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time.

12. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set, that each object except the last returns a status code of 0 and the last object returns a status code of 8. Verify that all except the last control point operated.

13. In a single request, issue a select to one installed control point and to one point that is not installed using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time. The installed point should be the first object in the request.

14. Verify that the DUT response has IIN2-2 bit set, that the status code returned for the installed point is 0 and the status code returned for the non-installed point is 4.

5.7 Paragraph 8.4.1.1 - Desired Behavior in both certification procedures Change third bullet under device supports analog output operations to read, “The DUT responds to selecting an uninstalled analog output point by returning an error response with IIN2-2 set and a status code of 4.”


5.9 Paragraph 8.4.2.1 – Desired Behavior in both certification procedures Change second bullet under device supports analog output operations to read, “The DUT responds to a direct operate to an uninstalled analog output point by returning an error response with IIN2-2 set and a status code of 4.”


5.11 Paragraph 8.4.4.1 – Desired Behavior in both certification procedures After the second bullet, add a statement that says, “The following behavior assumes that the device supports analog output operations:”

Add a bullet below the new statement that says, “The DUT responds to requests having more points than are supported in a single message with a status code of 8 for at least the first point that is beyond the point count limit.”

Add a second bullet below the new statement that says, “The DUT responds to a select to an uninstalled analog output point by returning an error response with IIN2-2 set and a status code of 4.”

5.12 Paragraph 8.4.4.2 – Test Procedure in both certification procedures Replace items 1 through 5 as follows:

1. Review the device’s profile document to understand how many analog output points are supported in a single request. If this number is one, skip to step 7.

2. Determine the number of installed points that can be successfully controlled in a single request. This number shall be the smaller of

• The number of controls supported in a single request

• The number of installed control points


• Sixteen

In a single request, issue a select to the above number of points using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and a value supported by the device


4. Immediately issue a matching execute.


6. Verify that each of the selected analog outputs occurred. . Note outputs may occur simultaneously or sequentially one after the other.

7. If the number of control objects supported in a single request is greater than or equal to either

• The number of control objects that fit into a single frame or

• The number of installed control points,

skip to step 13.

8. In a single request, issue a select to at least one more point than is supported in a single request, each point having a different index but otherwise able to be outputted, using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28) and an appropriate value.


10. If the DUT does not support direct operate, skip to step 13.

11. In a single request, issue a direct operate command to at least one more point than is supported in a single request, each point having a different index but otherwise able to be outputted, using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28) and an appropriate value.

12. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set, that each object except the last returns a status code of 0 and the last object returns a status code of 8. Verify that all except the last analog output point outputted the new value(s).

13. In a single request, issue a select to one installed analog output point and to one point that is not installed using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28) and an appropriate value. The installed point should be the first object in the request.


6 Status: Approval Technical Committee (Feb-2001).

Sequential File Transfer Objects DNP Technical Bulletin 2000-001 26 January 2000 Page 1

DNP Technical Bulletin 2000-001 Sequential File Transfer Objects

1 Introduction The following document provides a replacement implementation for DNP File Transfer as described in the Basic 4 document set. This bulletin is intended to address sequential file transfer only, not random file access. The following functionality is provided: • Simple reliable transfer of bulk data either up or down the communications chain. • Straightforward implementation. • Graduated features/complexity (by implementing additional objects). • Bandwidth management by limiting block sizes and allowing requested objects to be treated

as events that can appear an arbitrary period after they were originally requested. Legacy implementations of Object 70 Variation 1 cannot be relied upon to provide consistent implementation or interoperable file transfer capability.

This bulletin describes replacement objects and methods that should be used instead of the existing Object 70 Variation 1.

FIFO and other types of dynamic files may be transferred using the sequential file transfer mechanisms described in this bulletin. However, a dynamic file must be treated as a static file during the time between opening the file and the corresponding file Close or Abort. After the file is closed, the dynamic file may be modified as the device so chooses.

While this bulletin addresses sequential file transfer only, random access file support, and other file access techniques, will be supported in the future through the specification of additional objects.

2 Notes The following notes apply to all sections of the document • All String offsets are relative to the start of the object; i.e. the first octet following the object

header. • All data shown in examples is expressed in Decimal unless preceded by 0x indicating

Hexadecimal. • All Status objects defined herein are treated as events when sent from an outstation in a

response, and may be returned an arbitrary period after requested. • As is the case when any DNP event is sent from an outstation, it is a requirement that an

application confirm be requested by the outstation when sending file status events. • Some of the following descriptions refer to timeout mechanisms used when handling file

operations. It should be noted that file handling timeouts and the generation of file status events is independent of communication handling timeouts. As is the case for generation of any DNP event, the communication processing that is responsible for the delivery of the events (eg. through polling or unsolicited reporting) and collection of confirms is independent of the generation of the event.


3 Application Layer Function Codes Additional application layer function codes are added to support authentication and file specific operations. They are defined as follows.

Table 1

Function Code

Description

25 Open a File 26 Close a File 27 Delete a File 28 Get File Info 29 Authenticate 30 Abort

4 Authentication Devices that do not support authentication must not support this object. Before proceeding with secure transactions the application must obtain an Authentication Key from the end device. An Authentication Key is required to perform an Open or Delete command as described in the next section. It expires as soon as it is used. A new object is defined to support the process as follows.

Table 2 Object Header b7 Object 70 b0 b7 Variation 2 b0

b7 Qualifier 0x5B b0

b7 Range Field (=1) b0

b15 Number of Octets in object b0

Authentication Object Format b15 User Name Offset b0

b15 User Name Size b0

b15 Password Offset b0

b15 Password Size b0

b31 Authentication Key b0

bn User Name Octets b0

bn Password Octets b0

The User Name Offset field is a 16 bit parameter which specifies the zero-based start of the name octets relative to the start of the object excluding the header. The User Name Size field is a 16 bit parameter which specifies the number of name octets. The Password Offset field is a 16 bit parameter which specifies the zero-based start of the password octets relative to the start of the object excluding the header.


The Password Size field is a 16 bit parameter which specifies the number of Password octets. Using the Offset and Size technique effectively provides a jump-table to the strings included in the object definition. The Authentication Key field is a 32 bit number that is maintained by the outstation and uniquely specifies the permissions granted by the authentication process. User Name Octets are the octets of the user name. Password Octets are the octets of the password. Issuing an authentication request to the Authentication Object (obj 70 var 2) generates an Authentication Key. A user name and password are passed to the outstation in the request. The outstation responds with a pseudo random Authentication Key. The application can then use this key for exactly one secure transaction. The outstation maintains the relationship between the key and the permitted transactions. It is possible for there to be a set of user names and passwords that have different permissions. A unique Authentication Key may be obtained for each username via a separate authentication request. If authentication fails, the response will contain a zero value for the Authentication Key, which implies world (or guest) permissions. An application can issue secure transaction requests using a zero value Authentication Key. It is up to the end device to interpret how to handle this. For example, if the end device provides user authentication it could permit reading of some files but exclude writing and deleting files. This technique also allows a mechanism for using secure dialogs without performing the authentication step. This is acceptable if and only if the end device is permissive and allows it. To retrieve an Authentication Key the host issues an authentication request to the authentication object as follows

0xC0 29 70 02 0x5B 01 nn nn … (object data)

The object data includes the user name and password to be authenticated. The Authentication Key field is not used in the request and must be zero. The outstation responds with

0xC0 129 IINs 70 02 0x5B 01 nn nn … (object data)

The response contains the newly generated Authentication Key in the Authentication Key field and for security purposes the user name and password fields are null.

5 Open, Close, Delete and Abort. Open and Delete are secure transactions. A valid Authentication Key is required to successfully perform these transactions and expires as soon as it is used. A zero value for the Authentication Key implies world (or guest) permissions. To support the Open, Close, Delete and Abort functionality two objects are defined: The File Command Object (obj 70 var 3), and the File Command Status Object (obj 70 var 4). The File Command Object is used to initiate Open or Delete operations.


The File Command Status Object is used to indicate the success of Open, Close, Delete and Abort commands and to return a file handle during opens. It is also used to initiate a file close or abort using a previously acquired file handle. The details of these objects are described in subsequent sections.

5.1 File Command Object The File Command Object (obj 70 var 3) is used to facilitate file opens and deletes. It is defined as follows.

Table 3

Object Header b7 Object 70 b0 b7 Variation 3 b0

B7 Qualifier 0x5B b0



File Command Object Format b15 File Name Offset b0

b15 File Name Size b0

b47 Time of Creation b0

b15 Permissions b0

b31 Authentication Key b0

b31 File Size b0

b15 Operational Mode b0

b15 Maximum Block Size b0

b15 Request ID b0

bn File Name Octets b0

The File Name Offset field is a 16 bit parameter which specifies the zero-based start of the file name octets relative to the start of the object excluding the header. The File Name Size field is a 16 bit parameter which specifies the number of file name octets. The file name offset and file name size fields form a jump-table allowing direct access to the file name string at the end of the object. Offset is relative to the beginning of the object (zero based) excluding the header. The Time of Creation field is a 48 bit parameter that represents the DNP time of creation of the file represented as the number of milliseconds since midnight January 1, 1970. A value of zero in this field indicates that the time of creation of the file is unknown. The Permissions field is a 16 bit parameter whose value is defined in Table 4.

Table 4 Permission Bit Fields


Owner Read Allowed: 0x0100 Owner Write Allowed: 0x0080 Owner Execute Allowed: 0x0040 Group Read Allowed: 0x0020 Group Write Allowed: 0x0010 Group Execute Allowed: 0x0008 World Read Allowed: 0x0004 World Write Allowed: 0x0002 World Execute Allowed: 0x0001

The Permissions field contains a UNIX-style file access permission bit field. The use of this field is optional. Devices may update any of these fields in response to Read or Info requests if they can provide correct values for these fields. The relevant action is permitted if the bit is set, and inhibited if the bit is clear (e.g.: set Permission to 0x1FF to indicate no restrictions).

If the file is opened for writing, the Time of Creation and Permissions fields of the File Command Object (obj 70 var 3) shall be used as attributes for the new file. Otherwise the Time of Creation and Permissions fields must be zero when using this object. The Authentication Key field is a 32 bit parameter that facilitates secure transaction authentication. The key is obtained by issuing an Authentication Request (Function code 29) to the Authentication Object (obj 70 var 2) (see section 4). A value of 0 in this field indicates a permissive access level analogous to anonymous, guest or world permissions in various file systems. Devices that do not support authentication must ignore this field. The File Size field is a 32 bit parameter representing the number of octets contained in the file. This is particularly important when opening a file so that both ends have the opportunity to allocate adequate buffers. During an open for write the outstation may prepare its buffers appropriately. During an open for read the file size must be zero and is ignored by the outstation. If end of file is indicated to a device receiving a file, before the expected File Size is satisfied (by receiving the Last Flag in the File Transport Object – see Section 6.2), the receiving device shall treat the file as completely received and shall not consider this to be an error condition. However, if the received file exceeds the expected File Size, the receiving device may treat this an error and reject the transfer. A file size of 0xffffffff is allowed and indicates that the actual file size is unknown. Its use is allowable only when the value is truly not known. Devices are not required to accept an unknown file size. Devices may reject any request that exceeds the device’s resource limits. In such a case the two devices will not inter-operate. The Operational Mode field is a 16 bit parameter denoting the mode a file should be opened in. It is not used with the delete function, nor with function codes not requiring a file open (and must be zero in those cases). Values for this field are defined as shown in the following table.

Table 5 Mode Value Description

0x00 Null 0x01 Read 0x02 Write 0x03 Append

(Not required to be supported in a minimum implementation)


The Maximum Block Size field is a 16 bit parameter. For Read Operations it specifies the maximum number of octets an outstation is allowed to return in a file block, in response to a read request. For Write Operations it specifies the maximum number of octets that will be sent in a write request block. The Request ID field is a 16-bit parameter whose value is arbitrarily assigned by the host and sent in a request. The outstation device must remember this value and copy it into the Request ID field of the corresponding response. This permits the host to correlate responses with their requests when multiple files are simultaneously opened in the same device. File Name Octets are the octets of the file name. They fully reference the file (including path within the device).

5.2 File Command Status Object The File Command Status Object (obj 70 var 4) is used as a response to Open, Close, Delete and Abort commands, to facilitate closing a previously opened file, and to abort a file transfer in progress. It can also be used as an Error response for a Get File Info command. When files are opened they are assigned a unique file handle that is used to reference the file during future operations. To Close a previously opened file, issue a Close command (function code 26) using the File Command Status Object (obj 70 var 4) with the appropriate file handle.





File Command Status Object Format b31 File Handle b0

b31 File Size b0

b15 Maximum Block Size b0

b15 Request ID b0

b7 Status b0

bx Optional ASCII Characters b0

The File Handle field is a 32 bit parameter that provides a numeric identifier of the file opened. Its value is arbitrary and provided by the end device but must be unique to the outstation DNP address. It can be reused after a corresponding close is issued. Other operations will reference this identifier. The File Size field is a 32 bit parameter that is used to return the file size when a file has been opened for read, i.e. when Operational Mode 0x01 is used in the File Command Object (obj 70 var 3). The value of this field is undefined in all other cases and must be zero.


The Maximum Block Size field is a 16 bit parameter that is used to return the maximum block size that the outstation will return. This value should be less than or equal to the value set in the Maximum Block Size field of the File Command Object. For Read Operations it specifies the maximum number of octets that the outstation will return in a file block, in response to a read request. For Write Operations it specifies the maximum number of octets that will be accepted by the outstation in a write request block. The Request ID field is a 16 bit parameter. It must be returned in each File Command Status Object as the value of the Request ID field specified in the File Command Object or File Descriptor Object for the corresponding file request. The Status field is a 8 bit parameter that is used to return the status of the operation and must be set to zero by the initiating station. The responding station reports any error conditions in this field. The values for this field are defined in Table 7. Optional ASCII Characters may be appended to the object after the status code, and are a printable ASCII string that may be used to provide additional error information for any error condition.

Table 7 Value of

Status Field Name Usage

0x00 Operation Completed Successfully • Requested operation successful 0x01 Permission Denied • Authenticated user not allowed to access file 0x02 Invalid Mode • Unsupported or unknown Operational Mode 0x03 File not found • Requested file does not exist 0x04 File locked by another user • Requested file already in use 0x05 Open File Count Exceeded • Too many files open 0x06 File Handle Invalid • Attempting to close a file that is not open 0x07 Requested block size not

supported for writes • Outstation cannot write blocks of requested

size 0x08 Lost Communications • Intermediate device lost communications with

end device 0x09 Can’t Abort • File transaction Abort was not successful. File

is closed and unusable. 0x0A – 0x0F Reserved

0xFF Other • Any error not listed above (optional ASCII string may provide additional information)

Note: A minimal implementation may restrict the number of open files to one. Note: The File Command Status Object (obj 70 var 4) is treated as an event when it is generated after an Open, Close, Abort or Delete command, so that it can be either polled for specifically or assigned to class 1, 2, or 3. It is also acceptable to return it in the response to a request if the results are immediately known.

5.3 Opening a File To open a file issue an Open command (function code 25) to the File Command Object (obj 70 var 3) passing the correct file name, size, block size, permissions and Authentication Key as follows



To open the file for read, set the Operation Mode to read (0x01), and File Size to zero.

To open the file for write, set the Operation Mode to write (0x02). If the file is opened for writing it shall be truncated to zero length and the Time of Creation and Permissions fields of the File Command Object shall be used as attributes for the new file. Otherwise the Time of Creation and Permissions fields must be zero. Note: the file must be fully described as in

Path\FileName The outstation responds with a File Command Status Object (obj 70 var 4) with the assigned file handle and status code as follows

0xE0 129 IINs 70 04 0x5B 01 nn nn … (object data)

A status code of zero indicates that the file was successfully opened. The application should use the returned file handle in future references to the file until it is closed. A non zero status code indicates that the file was not successfully opened, and the file handle value is invalid. If the file was opened for read, the File Size field indicates the size of the file. If the file was opened for write the File Size field reports zero. The outstation has requested the host Confirm the response containing an event, so the host responds as follows

0xC0 00

5.4 Closing a File To Close a file, issue a Close command (function code 26) to the File Command Status Object (obj 70 var 4) as follows

0xC0 26 70 04 0x5B 01 nn nn … (object data) The File handle field should be set to the value assigned in the previous open. Status must be set to zero. The outstation responds with

0xE0 129 IINs 70 04 0x5B 01 nn nn … (object data) The object data shall be an echo of the request with the status field set to the appropriate value (e.g. file does not exist, permission denied, etc.) A status code of zero indicates that the file was successfully closed. The outstation has requested the host Confirm the response containing an event, so the host responds as follows

0xC0 00 Note: If there is no activity referencing a file handle for a configurable length of time the outstation must do an automatic close on the file. The timeout value must be configurable up to 1 hour. When this condition occurs the outstation will send a File Transport Status Object (obj 70 var 6) using a status code value of file handle expired (0x02). The final state of the file closed under this condition is undefined. Note: The final state of a file that is closed after receiving a File Transport Status Object (obj 70 var 6) with a non-zero status code value is also undefined.


Note: If the host chooses to end the operation for any reason including a timeout it must send a close to the outstation to release the file for further use.

5.5 Deleting a File To delete a file, issue a Delete command (function code 0x1B) to the File Command Object (obj 70 var 3) as follows


Operation mode in the File Command Object must be set to zero. The outstation shall respond with a File Command Status Object (obj 70 var 4) with the file handle value of zero and the status code set to the appropriate status value (e.g. file does not exist, permission denied, etc.) as follows

0xE0 129 IINs 70 04 0x5B 01 nn nn … (object data) A status code of zero indicates that the file was successfully deleted. For more information on status codes see Table 7. The outstation has requested the host Confirm the response containing an event, so the host responds as follows

0xC0 00 Note: If a file is open while issuing a delete command a File Command Status Object (obj 70 var 4) shall be returned with a status code of “File locked by another user” (0x04).

5.6 Aborting a File Transfer To Abort a file transfer, issue an Abort command (function code 30) to the File Command Status Object (obj 70 var 4) as follows

0xC0 30 70 04 0x5B 01 nn nn … (object data) The File handle field should be set to the value assigned in the previous open. Status must be set to zero. The outstation responds with

0xE0 129 IINs 70 04 0x5B 01 nn nn … (object data) The object data shall be an echo of the request with the status field set to the appropriate value (e.g. file does not exist, can’t abort, etc.) A status code of zero indicates that the file transfer was successfully aborted. The outstation has requested the host Confirm the response containing an event, so the host responds as follows

0xC0 00 Note: If Abort is supported by a device, then upon receiving an Abort command the device must terminate the file transfer indicated by the File Command Status Object and close the file. If a device does not support Abort, the device must return a “Can’t Abort” status code in a File Command Status Object (obj 70 var 4). Note: To completely recover a file after an Abort, in all circumstances, it may be necessary for the device to double-buffer the file during file transfer operations. If a file transfer Abort results in


an unusable file the device must return a “Can’t Abort” status code in a File Command Status Object (obj 70 var 4).

6 Data Transfer Two objects are defined to support data transfer. The first is a File Transport Object (obj 70 var 5). The second is the File Transport Status Object (obj 70 var 6).

6.1 File Transport Object The File Transport Object (obj 70 var 5) is defined as follows.





File Transport Object Format b31 File Handle b0

b31 LAST

b30 Block Number b0

Bn Data Octets b0

The File Handle field is a 32 bit parameter that provides a numeric identifier of the file opened. It is obtained by opening the file using the File Command Object (obj 70 var 3) (see sections 4-5). The Block Number field is a 31 bit parameter plus a 1 bit Last Flag. The block number starts at zero and increments by one for each block read or written. The size of the data portion is not relevant and need not be the same from block to block. It is limited by the maximum block size field passed in the File Command Object (obj 70 var 3) during the open process. The Last Flag is set to denote the indicated block number is the last block, and cleared to denote the indicated block number is not the last block. The Data Octets represent the information to be transferred. Note: Using file handle qualification and block number allows multiple read/write operations to different files on the same device, concurrently. Note: The File Transport Object (Obj 70 var 5) is treated as an event for file read responses so that it can be polled for specifically, assigned to class 1, 2, or 3, or sent in an unsolicited response. It is also acceptable to return it in the response to a request if the results are immediately known.


6.2 File Transport Status Object The File Transport Status Object (obj 70 var 6) is defined as follows.





File Transport Status Format b31 File Handle b0

b31 LAST

b30 Block Number b0

b7 Status Code b0

Bx Optional ASCII Characters b0

The File Handle field is a 32 bit parameter that provides a numeric identifier of the file opened. It is the value originally obtained by opening the file using the File Command Object (obj 70 var 3) (see sections 4-5). The Block Number field is a 31 bit parameter plus 1 bit Last Flag, corresponding to the Block Number and Last Flag in a File Transport Object for which this object is reporting status. The block number sent by the initiating station starts at zero and increments by one for each block read or written. The Last Flag is set to denote the indicated block number is the last block, and cleared to denote the indicated block number is not the last block. The Status field is an 8 bit parameter that is used to return the status of a corresponding File Transport Object operation. The responding station reports any error conditions in this field. The values for this field are defined as follows:

Table 10 Value of

Status Field Name Usage

0x00 Operation Completed Successfully • File Transport Object successfully written 0x08 Lost Communications • Intermediate device lost communications with

end device 0x10 No Previous Matching Open • File handle does not reference an open file 0x11 Handle has Expired. • File previously closed due to inactivity timeout 0x12 Buffer Overrun. • Too much file data received to process 0x13 Fatal Error, File Unusable • File system error 0x14 Block Number Out Of Sequence • Already received data with this block number

• Missing (skipped) block number in sequence 0x15 – 0x1F Reserved

0xFF Other • Any error not listed above (optional ASCII string may provide additional information)

Note: The File Transport Status Object (obj 70 var 6) is treated as an event and can be polled for directly or assigned to class 1,2, or 3. Alternatively it can be reported via unsolicited response or in response to the request if the results are immediately known.


Note: Any optional data appended to the object after the status code is a printable ASCII string that is used to provide additional error information. When any file status changes it is reported using a File Transport Status Object (obj 70 var 6) as an event. For example, when a file inactivity timer expires, the outstation shall generate an event using the File Transport Status Object with status code 0x11 “Handle has Expired”. This event will then be returned on the next poll or may be sent as an unsolicited response. After the event is generated, the outstation is no longer required to retain information about the file being opened. Any subsequent access to the file results in a File Transport Status Object with status code 0x10 “No Previous Open”. The File Transport Status Object provides flow control and bandwidth management when performing file write operations because

• It is required/guaranteed that the end device sends it. • Normal polling continues while waiting for it. • A configurable timeout limits how long to wait.

6.3 Writing Data • To write a file: Open the file in Write mode, providing authentication information (see

section 4). • Perform write to the File Transport Object (obj 70 var 5). • Wait for a File Transport Status Object (obj 70 var 6) Event with the matching file handle

and block number. • Assuming the operation was successful increment the block number and write the next

block. • When writing the last block set the Last Flag. • Close the file using the File Operation Status Object (obj 70 var 4) and file handle

returned in the open command. A typical sequence is:

Table 11 Operation Sequence Application Layer Octets

Open 0xC0 25 70 03 0x5B….(object data)

Open Response 0xE0 129 IINs 70 04 0x5B….(object data)

Confirm 0xC0 00

Write (Block 0x00000000) 0xC1 02 70 05 0x5B….(object data)

Null Response 0xC1 129 IINs

N Polls 0xC2 01 Class poll

Get Status Event (Block (0x00000000) 0xE2 129 IINs (data) Object 70 var 06

Confirm 0xC2 00


Write (Block 0x00000001) 0xC3 02 70 05 0x5B….(object data)



Get Status Event (Block 0x00000001) 0xE4 129 IINs (data) Object 70 var 06

Confirm 0xC4 00

Write (Last Block 0x80000002) 0xC5 02 70 05 0x5B….(object data)



Get Status Event (Last Block 0x80000002)

0xE6 129 IINs (data) Object 70 var 06

Confirm 0xC6 00

Close 0xC7 26 70 04 0x5B….(object data)

Returns Status In Status Object 0xE7 129 IINs 70 04 0x5B….(object data)

Confirm 0xC7 00

Note: If there is an error during the above operations including a file operation timeout, the device shall return the appropriate status object with status code. . Under error conditions the file must be implicitly closed by the outstation and the file contents must be considered indeterminate. Upon receiving a File Transport Status Object (obj 70 var 6) with a non-zero status code, the referenced file handle becomes invalid.

6.4 Reading Data To Read a file

• Open the file in Read mode, providing authentication information, as described in section 4.

• Perform a read to the File Transport Object (obj 70 var 5). • Wait for the response. • Assuming the operation was successful increment the block number and read the next

block. • When the Last Flag is set in the response, close the file using the File Operation Status

Object (obj 70 var 4) and file handle returned in the open command. A typical sequence is:


Table 12 Operation Sequence Application Layer Octets

Open 0xC0 25 70 03 0x5B….(object data)

Open Response 0xE0 129 IINs 70 04 0x5B….(object data)

Confirm 0xC0 00

Read (Block 0x00000000) 0xC1 01 70 05 0x5B….(object data)



N+1 Poll 0xC3 01 Class poll

Poll response (File Data returned as event)

0xE3 129 70 05 0x5B….(object data)

Confirm 0xC3 00





Poll response (File Data returned as event)


Confirm 0xC6 00





Poll response:File Data returned as event with Last Flag set


Confirm 0xC9 00

Close 0xCA 26 70 04 0x5B….(object data)

Returns Status In Status Object 0xEA 129 IINs 70 04 0x5B....(object data)

Confirm 0xCA 00


Note: in read requests there are no data octets included in the File Transport Object (obj 70 var 5).

Note: If there is an error during the above operations, including a file operation timeout, the device shall return the appropriate status object with status code. Note that a File Transport Status Object (obj 70 var 6) should be returned on error, instead of a File Transport Object (obj 70 var 5). Under error conditions, the file must be implicitly closed by the outstation and the host, and file contents at the host must be considered indeterminate. Upon receiving a File Transport Status Object (obj 70 var 6) with a non-zero status code the referenced file handle becomes invalid.

7 Retrieving File Information The File Descriptor Object (obj 70 var 7) is used to get information about a file. It is defined as follows:


B7 Qualifier 0x5B b0



File Descriptor Object Format b15 File Name Offset b0

b15 File Name Size b0

b15 File Type b0

b31 File Size b0

b47 Time of Creation b0

b16 Permissions b0

b15 Request ID b0

bn File Name Octets b0

The File Name Offset field is a 16 bit parameter which specifies the zero-based start of the file name octets relative to the start of the object excluding the header. The File Name Size field is a 16 bit parameter which specifies the number of file name octets. The file name offset and file name size fields form a jump-table allowing direct access to the file name string at the end of the object. Offset is relative to the beginning of the object (zero based) excluding the header. The File Type field is a 16 bit parameter used to differentiate between simple files and directories. A zero value indicates a directory. A value of 1 indicates a simple file. The File Size field is a 32 bit parameter. For a simple file type it represents the number of octets contained in the file. For a directory file type it indicates the number of entries in the sub-directory, excluding any links to itself or its parent directory.


The Time of Creation field is a 48 bit parameter that represents the DNP time of creation of the file represented as the number of milliseconds since midnight January 1, 1970. The Permissions field is a 16 bit parameter whose values are defined in Table 4 (see section 5.1) The Request ID field is a 16-bit parameter whose value is arbitrarily assigned by the host. The outstation device must remember this value and copy it into the Request ID field of the corresponding response. This permits the host to correlate responses with their requests when information on multiple files is requested in the same device. File Name Octets are the octets of the file name. They fully reference the file (including path within the device). Note: The File Descriptor Object (obj 70 var 7) is treated as an event when it is generated after a Get File Info command, so that it can be either polled for specifically or assigned to class 1, 2, or 3. It is also acceptable to return it in the response to a request if the results are immediately known.

7.1 Retrieving Individual File Information To get information on a single file, issue a Get File Info Command (function code 28) to the File Descriptor Object (obj 70 var 7) specifying a Request ID and the full path file name in the File Name field as follows 0xC0 28 70 07 0x5B 01 nn nn …(Object…RequestID…”Path\FileName”…Data) The File Type, File Size, Time of Creation and Permissions fields of the File Descriptor Object in a request must be ignored by the outstation and must be set to zero by the initiating station. The device responds with a File Descriptor Object (obj 70 var 7) consisting of the requested information as follows 0xE0 129 IINs 70 07 0x5B 01 nn nn …(Object…”RequestID…Path\FileName” …Data) The outstation has requested the host Confirm the response containing an event, so the host responds as follows 0xC0 00 The end application could display this information in a browser or another appropriate application. Note: the file shall be fully described, as in:

Path\FileName If the file referenced does not exist then the outstation should return a File Command Status Object (obj 70 var 4) with the status field set to File Not Found (0x02). If the file referenced is a directory file, the File Type field shall be zero to indicate a directory file and the File Size field shall indicate the number of entries in the sub-directory. To retrieve file information on all files in a directory, issue a file read on the directory file, as described in section 7.2.


7.2 Retrieving Directory Information Information can be retrieved for all the files in a directory or sub-directory of a device by performing a file transfer of the directory file. The directory file shall be read in the manner described in section 6.4 for sequential file reads. ie. Authenticate (if necessary), Open, Read blocks up until the end of file, and Close the file.

The outstation responds in the same manner as for any other file read. The format of the “directory file” transferred from the outstation consists of one or more data objects, one for each file in the directory, in same format as the File Descriptor Object (obj 70 var 7) i.e. the details supplied for each file in the directory are: File Name Offset, File Name Size, File Type, File Size, Time Of Creation, Permissions, Request ID, File Name

The end application may display this information in a browser or another appropriate application. The file descriptor object data transferred in the directory file read does not include object header information.

The path to the directory is not contained in each of the individual File Descriptor Object’s File Name fields. Only the name of the file is included. (The path was specified in the File Command object used to Open the directory file for read).

The directory file can only be opened for Read. Retrieving directory information retrieves data for one directory level only. Sub-directories below the read directory are indicated as files with File Type zero (Directory file), and with the File Size field indicating the number of entries in the sub-directory. A host wishing to retrieve file information for all files in a device may perform additional directory file transfers for each sub-directory file.

If the directory referenced does not exist then the outstation should return a File Command Status Object (obj 70 var 4) with the status field set to File Not Found (0x02). If the directory exists but contains no files, then the outstation should return a file of zero length i.e. File Transport Object (obj 70 var 5) is returned with no Data Octets.

7.2.1 Example Assume that an outstation has the following directory structure \file0 \dir1

\file1 \file2 \dir2

\file3 \dir3

\file4

If the host reads the root directory file (“\”), it would receive a file with information as follows:

Filename offset

Filename size

File type

File size Time of creation Permissions Request Id File name octets

0x14 00 05 00 01 00 nn nn nn nn nn nn nn nn nn nn 00 00 nn nn file0


0x14 00 04 00 00 00 03 00 00 00 nn nn nn nn nn nn 00 00 nn nn dir1 0x14 00 04 00 00 00 01 00 00 00 nn nn nn nn nn nn 00 00 nn nn dir3 If the host reads the directory file “\dir1”, it would receive a file with information as follows:

Filename offset

Filename size

File type

File size Time of creation Permissions Request Id File name octets

0x14 00 05 00 01 00 nn nn nn nn nn nn nn nn nn nn 00 00 nn nn file1 0x14 00 05 00 01 00 nn nn nn nn nn nn nn nn nn nn 00 00 nn nn file2 0x14 00 04 00 00 00 01 00 00 00 nn nn nn nn nn nn 00 00 nn nn dir2

8 Minimum Implementation When a device supports Sequential File Transfer, the following implementation is required as a minimum. Authentication and Unsolicited Responses are considered optional features of Sequential File Transfer.

Table 14

Object Variation and Qualifier Codes Required

OBJECT

REQUEST

(slave must parse)

RESPONSE

(master must parse) Obj

Var

Description

Func

Codes (dec)

Qual

Codes (hex)

Func

Codes (dec)

Qual

Codes (hex)

70 2 Authentication Object 70 3 File Command Object 25,27 0x5B 70 4 File Command Status Object 26,30 0x5B 129,130 0x5B 70 5 File Transport Object 1,2 0x5B 129,130 0x5B 70 6 File Transport Status Object 129,130 0x5B 70 7 File Descriptor Object 28 0x5B 129,130 0x5B

Affected Documentation: DNP V3.00 Data Object Library

Chapter 10 File Object Definitions

Changes to the Subset Level 1 and 2 Certification Procedures: None

Last Updated: January 26, 2000 Status: Pending General Membership Approval (Feb 2000)

DNP 3 Technical Bulletin 2000-002 Page 1 of 12 Control Retries January 24, 2000

DNP Technical Bulletin 2000-002 Control Retries

Issue: This bulletin describes a method of operating controls reliably in the presence of a poor quality communications network, and adds a new restriction on devices when performing select before operate controls. This bulletin supercedes Technical Bulletin 9804-001 dated 4/22/98 Item 7 which states "A Host must never perform application layer retries of output operations, i.e. never send two output messages with the same sequence number for SELECT, OPERATE, or DIRECT OPERATE function codes." The requirement as stated above was intended to insure that duplicate controls would not be issued. As stated the requirement can be misinterpreted to mean that control operations should never be reissued without operator intervention. It is possible for the Host to safely issue more than one control attempt without risking duplicate operation. This is desirable in high noise environments to allow the system to make a “Best Effort Attempt” to operate the control “Exactly Once” without operator intervention. It is the purpose of this document to describe how more than one control attempt may be performed safely without risking duplicate control operation while making a “Best Effort Attempt” to operate the control “Exactly Once” without operator intervention. This is technically not a retry from the protocol’s perspective, however, it appears as a retry from the operators perspective. Therefore, the remainder of this document will refer to the Host making more than one control attempt to be a “Control Retry”. Background: In a SCADA communications environment all transmissions and receptions are received through the communications medium, which is often represented as a cloud as shown in Figure 1.

Figure 1

It is possible for messages to get lost in the communications medium as shown in Figure 2

Host Outstation

WAN


Figure 2

In this case the Host transmitted a message, the Outstation received it and responded, but the message is lost in the communications medium. The Host must assume that the Outstation never received the message, and act accordingly. Technical Bulletin 9804-001 addresses how a Host and Outstation should handle the various failure scenarios. Technical Bulletin 2000-002 addresses the processing of analog and binary operations in the various failure scenarios. Notes: The following notes apply to the text that follows: • The term control is used generically to refer to analog and binary outputs. When the type of output is

important, the proper name is used. • When sequence number is included in the following text it refers to the application sequence number

unless otherwise noted. • When the term “Retry” appears in the following text it refers to application layer retries unless

otherwise noted. • When application sequence numbers are incremented they are always incremented modulo 16. Rules: 1) Technical Bulletin 9804-001 fully applies with the exception of Item 7. 2) The Host may issue multiple retries on the “select” portion of the control dialog. 3) Incrementing the sequence number between retries of the select is at the discretion of the Host.

a) If the Host increments the sequence number between retries, the Outstation will respond to the select and re-arm the designated point. This also causes the Outstation to re-arm its select-to-operate timers.

b) If the Host retries without incrementing the sequence number, the Outstation will respond to the select. The original selection will remain unchanged intact., and the Outstation’s select-to-operate timers will continue running without being reset.

4) The Host must increment the sequence number by exactly one (modulo 16) between the select and operate command.

5) The Outstation must reject any operate that does not a) contain a sequence number that is exactly one greater (modulo 16) than the previously accepted

select. b) match the object portion of the select message byte for byte, excluding the application header.

6) The Host may only issue an operate after successful reception of a select echo from the Outstation. 7) The Host may issue multiple retries on the “operate” portion of control dialog as long as the sequence

number does not change between retries. 8) At no time should the Host retry the select operate sequence in its entirety. Once the select portion has

been satisfied, if the operate portion fails the Host may not retry the select. This can result in duplicate controls.

9) The Host must never retry direct operate controls. This can result in duplicate controls.

Host Outstation

WAN


Scenarios: The following section presents several scenarios that illustrate the rules stated above. Scenario 1: Figure 3 shows a timeline representation of a successful select before operate sequence.

Figure 3

Host OutstationTime To

Host Issues SelectSEQ N

SEQ N

Oustation Receives Select

Oustation Echoes Select

Host Receives Echo

SEQ N+1

SEQ N+1

Host Sends Operate

Outstation Receives OperateOustation Operates ControlOustation Echos Operate

Host Receives EchoControl Dialog Complete

Time Tn


Scenario 2: Figure 4 shows a timeline representation of a successful select before operate sequence, where the echo of the first select is lost and the Host increments the sequence number and retries the select.

Figure 4


Host Issues Select NSEQ N

SEQ N

Oustation Receives Select N


Host Misses Echo N

SEQ N+2

SEQ N+2

Host Sends Operate N+2

Outstation Receives Operate N+2Oustation Operates ControlOustation Echos Operate N+2

Host Receives Echo N+2Control Dialog Complete

Time Tn

SEQ N+1Host increments sequencenumber and retries Select

Oustation Receives Select N+1and resets its operate timer

Oustation Echoes Select N+1SEQ N+1

Host Receives Echo N+1


Scenario 3: Figure 5 shows a timeline representation of a successful select before operate sequence where the echo of the first several selects are lost. The Host does not increment the sequence number when retrying the select. Note: This can cause the operate to be rejected if the select-to-operate timer of the Outstation is configured to be less than the time it takes to retry the selects.

Figure 5


Host Issues SelectSEQ N

SEQ N



Host Receives Echo N

SEQ N+1

SEQ N+1



Host Receives Echo N+1Control Dialog Complete Time Tn

SEQ NHost Misses Echo N

Host Retries Select NSEQ N

Oustation Detects Duplicate Sequence Number ThatMatches Byte for Byte last message. It Echoesprevious select without processing. Timer is notreset.SEQ N

Host Misses Echo N


Oustation Detects Duplicate Sequence Number ThatMatches Byte for Byte last message. It Echoesprevious select without processing. Timer is notreset.SEQ N

Host Misses Echo N


Oustation Detects Duplicate Sequence Number ThatMatches Byte for Byte last message. It Echoesprevious select without processing. Timer is notreset.


Scenario 4: Figure 6 shows a timeline representation of a successful select before operate sequence where the echo of the operate is lost. The Host does not increment the sequence number when retrying the operate.

Figure 6






Host Receives Echo N+1Control Dialog Complete

Time Tn

SEQ NHost Receives Echo N

SEQ N+1

SEQ N+1Host Misses Echo N+1

Host Retries Operate N+1SEQ N+1

SEQ N+1

Oustation Detects Duplicate Sequence Number ThatMatches Byte for Byte last message. It Echoesprevious operate without processing.



Scenario 5: Figure 7 shows a timeline representation of an invalid select before operate sequence. The echo of the operate is lost. The Host increments the sequence number when retrying the operate. This results in a false error.

Figure 7






Host Receives Echo N+2and believes the control didnot operate when in fact itdid. Control Dialog Error Time Tn

SEQ NHost Receives Echo N

SEQ N+1

SEQ N+1Host Misses Echo N+1

Host Retries Operate N+1SEQ N+2

SEQ N+2

Outstation Detects Operate.Since the sequence number is not the same as theprevious operate it processes the operate. There wasno select with sequence number N+1 so it echoesthe operate, setting the status field to NOMATCHING SELECT(status = 2).



Scenario 6: Figure 8 shows a timeline representation that illustrates why direct operate controls cannot be retried. In this example the echo of the direct operate is lost. The Outstation restarts after sending it. The Host retries the direct operate and the control is eventually operated twice. This cannot occur using select before operate controls.

Figure 8


Host Issues Direct Operate NSEQ N

SEQ N

Outstation Receives OperateOustation Operates ControlOustation Echos OperateOutstation Restarts

Host Receives Echo N withthe restart bit set. The controlhas already operated asecond time at this point.This result is unacceptable.

Time Tn


Host Retries Direct Operate NSEQ N

SEQ N

Host Misses Echo N

Host Retries Direct Operate NSEQ N


Host Retries Direct Operate N SEQ N

Outstation is Restarting

Outstation is Restarting

Outstation Receives OperateOustation Operates Control a second timeOustation Echos Operate

Outstation becomes operational


Affected Documentation: This document supersedes Technical Bulletin 9804-001 Item 7. Changes to the Subset Level 1 and 2 Certification Procedures: Insert additional procedures in binary output section:

Desired Behavior • The Outstation must accept retries on the select portion of the control dialog that increment the

application sequence number between retries. In this case the select-to-operate timer must be restarted after reception of each select.

• The Outstation must accept retries on the select portion of the control dialog that do not increment the application sequence number between retries. In this case the select-to-operate timer must remain unaltered by the reception of each additional select.

• The Outstation must reject any operate that does not • contain a application layer sequence number that is exactly one greater (modulo 16) than the

previously accepted select. • match the object portion of the select message byte for byte, excluding the application header.

• The Outstation must accept retries on the operate portion of the control dialog that does not increment the application sequence number between retries. The Outstation must echo the operate command but must not operate the control more than once.

(Section # TBD) Same Sequence Number Binary Output Select Retries

1. If the DUT does not have installed binary output points skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again using the same application layer sequence number. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the binary output. (Section # TBD) Incrementing Sequence Number Binary Output Select Retries

1. If the DUT does not have installed binary output points skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again incrementing the application layer sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the binary output. (Section # TBD) Same Sequence Number Binary Output Operate Retries

1. If the DUT does not have installed binary output points skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the binary output. 7. Issue the operate again using the same application layer sequence number. 8. Verify that the DUT echoes the object portion of the operate byte for byte.


9. Verify that the DUT does not operate the binary output. (Section # TBD) Incrementing Sequence Number Binary Output Operate Retries

1. If the DUT does not have installed binary output points skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the binary output. 7. Issue the operate again, incrementing the sequence number by 1 modulo 16. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2

(NO MATCHING SELECT). 9. Verify that the DUT does not operate the binary output. (Section # TBD) Select/Operate Binary Output Sequence number checking

1. If the DUT does not have installed binary output points skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2

(NO MATCHING SELECT). 6. Verify that the DUT does not operate the binary output. 7. Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the

mismatched operate cleared the previous select. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2

(NO MATCHING SELECT). 9. Verify that the DUT does not operate the binary output. Insert additional procedures in analog output section: Desired Behavior • The Outstation must accept retries on the select portion of the control dialog that increment the

application sequence number between retries. In this case the select-to-operate timer must be restarted after reception of each select.

• The Outstation must accept retries on the select portion of the control dialog that do not increment the application sequence number between retries. In this case the select-to-operate timer must remain unaltered by the reception of each additional select.

• The Outstation must reject any operate that does not • contain a application layer sequence number that is exactly one greater (modulo 16) than the

previously accepted select. • match the object portion of the select message byte for byte, excluding the application header.

• The Outstation must accept retries on the operate portion of the control dialog that does not increment the application sequence number between retries. The Outstation must echo the operate command but must not operate the control more than once.

(Section # TBD) Same Sequence Number Analog Output Select Retries

1. If the DUT does not have installed analog output points skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again using the same application layer sequence number. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte.


8. Verify that the DUT operates the analog output. (Section # TBD) Incrementing Sequence Number Analog Output Select Retries

1. If the DUT does not have installed analog output points skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again incrementing the application layer sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the analog output. (Section # TBD) Same Sequence Number Analog Output Operate Retries

1. If the DUT does not have installed analog output points skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the analog output. 7. Issue the operate again using the same application layer sequence number. 8. Verify that the DUT echoes the object portion of the operate byte for byte. 9. Verify that the DUT does not operate the analog output. (Section # TBD) Incrementing Sequence Number Analog Output Operate Retries

1. If the DUT does not have installed analog output points skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the analog output. 7. Issue the operate again, incrementing the sequence number by 1 modulo 16. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2

(NO MATCHING SELECT). 9. Verify that the DUT does not operate the analog output. (Section # TBD) Select/Operate Analog Output Sequence number checking

1. If the DUT does not have installed analog output points skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2

(NO MATCHING SELECT). 6. Verify that the DUT does not operate the analog output. 7. Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the

mismatched operate cleared the previous select. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2

(NO MATCHING SELECT). 9. Verify that the DUT does not operate the analog output.


Last Updated: January 24, 2000 Status: Pending General Membership Approval (Feb-2000).

DNP 3 Technical Bulletin 2000-003 Page 1 of 22 Change Management January 26, 2000

DNP Technical Bulletin 2000-003 Change Management

Issue: The use of DNP3 in a wide variety of application areas and communication technologies has led to a need for periodic revisions and improvements. In an effort to satisfy the desire for stability yet recognize the need for change, this document outlines the mechanism that will be employed to manage changes, as they become necessary. Background: The DNP Protocol is defined by an extensive documentation set. However, there are areas in the original documentation, and in subsequent documentation and Technical Bulletins that have

• failed to address areas of inter-operability • provided ambiguous specifications • provided conflicting requirements • provided no guidance • not provided suitable functions, objects or methods for desired commands and data transferal.

It is the responsibility of the technical committee as maintainers of the protocol to address these issues in a timely manner while providing customers and implementers sufficient time to incorporate changes into their products and specifications.

Resolution: When needed the technical committee will issue Technical Bulletins that resolve identified problems and specify new features. Bulletins fall into four categories

1. Enhancements or additions to the protocol that no one has implemented before. 2. Recommendations that are not required for inter-operability and will not be tested for in the

certification procedures. 3. Rules that are required for inter-operability and will be tested for in the certification

procedures. 4. Procedural and Organizational rules and requirements (e.g. charter, membership requirements,

certification, etc). Category 1 and 2 issues do not directly effect existing implementations and may be issued by the technical committee without requiring General Membership Approval. Category 3 and 4 issues can potentially affect existing implementations. The Technical Committee will issue these bulletins with a status indicating “Pending General Membership Approval (Month and Year of Next Meeting)”. Each bulletin that specifies desired behavior must also include a certification test section to be included in the certification test procedures. Each version of the certification procedures will be denoted by the year the contents were approved by the General Membership. As an example, the original certification procedures were approved by the General Membership in February 1999. Devices that passed the tests in those procedures are said to be DNP3-1999 compliant.

DNP 3 Technical Bulletin 2000-003 Page 2 of 22 Change Management January 26, 2000

Technical Bulletins may be published at any time between General Membership Meetings, however those that require approval of the General Membership must be published for review not later than thirty days prior to the General Membership Meeting in which the General Membership will be asked to approve them. Certification test procedures included in the Technical Bulletins that are approved in a General Membership Meeting will be incorporated into the certification procedures six months following the meeting. Technical Bulletins that are rejected in a General Membership Meeting may be revisited or edited and resubmitted at the next General Membership meeting. Six months after the General Membership meeting all previously certified devices must be tested against, and pass the revised certification procedures in order to be DNP3-xxxx compliant, where xxxx is the year in which the Technical Bulletins were approved by the general membership. For example, the certification procedures included in the Technical Bulletins approved in February 2000 would be called DNP3- 2000. Devices tested during the 6 month grace period between General Membership Approval and the Effective Date can choose which version of the procedures they wish to be tested against. In the example given above, devices certified between Feb 2000 and July 2000 could choose to be certified against either the DNP3-1999 procedures or the DNP3-2000 procedures. Devices certified after July 2000 would be required to use the DNP3-2000 procedures. It is recommended that DNP3 users specify which level of compliance they require by specifying which version of the procedures a device must pass to be purchased. The Technical Committee will maintain a document on the web site that summarizes the inter-operability issues and enhanced features added for each version of the certification procedures. While every attempt is made to insure that two devices that pass the certification procedures inter-operate, there may be instances in which a behavior has not been specified. In these cases the vendors involved in the dispute can request arbitration from the technical committee. The Technical Committee will review the details of the issue and publish a technical bulletin that specifies the correct behavior. This bulletin will by definition be a category 3 bulletin, and when approved, will be incorporated into the certification procedures in normal course. Implementers can use the technical bulletin as an advanced notification of additional requirements that resulted from the arbitration. A fee may be assessed for the arbitration process at the discretion of the Steering Committee. Master devices are expected to reliably communicate and inter-operate with certified slave stations. When they do not, and a compromise solution cannot be reached between the master and slave vendors, the issue may be submitted to the DNP Technical Committee for arbitration. Affected Documentation: None Changes to the Subset Level 1 and 2 Certification Procedures: None. Last Updated: January 26, 2000 Status: Pending General Membership Approval (Feb 2000).

DNP Technical Bulletin 2000-nnn Page 1 of 1 Multiple Control Objects 17-August-2000

DNP Technical Bulletin

Application Layer Confirmation Messages August 30, 2000

1 Issue DNP3 protocol defines an application layer message-confirmation service. When used, the receiving application is required to confirm reception of an application message from the sending application. Confirmation is accomplished by transmission of a message with the application layer “Confirm” function code, code 0. The Basic IV is unclear whether or not IIN octets are to be included in application confirm messages sent by the slave. Section 3.6 of the Application Layer document states that the IIN “… follows the function code in all responses.” Section 4 contradicts this by explicitly diagramming a Confirmation Response without the IIN. DNP3 Certification Procedures for Subset Level 1 and Level 2 do not contain any tests for application confirm messages sent by a slave device in response to a master request. The DNP Technical Committee has been asked to clarify application confirm requests transmitted by the master and corresponding application confirm responses transmitted by the slave.

2 Resolution Since: • A slave device may pass certification without supporting master application confirm requests, and • The Basic IV does not clearly define the application confirmation message structure when transmitted by the

slave, It has been determined that any definition of the structure of a slave application confirm message may result in non-compliance and non-interoperability by some currently certified devices. Furthermore, since there are no meaningful uses of the application confirmation service when requested by the master, it has been resolved that: • The master must not transmit any message that requests an application layer confirmation by the slave, and • The slave response to any such request by a non-compliant master is undefined.

3 Last Updated: 30 August 2000

4 Status: Pending Technical Committee Approval

14-March-2001 2 TD-Counters-JV-1.doc

Last Updated 31 May 2001 Status Awaiting User Group Comments

DNP3 Technical Bulletin 2000-005 Page 1 of 2 Reset of User Process Function Code November 13, 2000

DNP Technical Bulletin 2000-005 Reset of User Process Function Code

Issue: The "Reset of User Process" service function (FC = 1) in the link layer control octet is not defined in the Basic 4 completely enough to guarantee interoperability. The Data Link Layer document does not define what action the secondary station should take when it receives the command. Furthermore, the document does not define what the "user process" of the link layer is or what should be involved in resetting it. Discussion: It is undesirable to have the link layer independently "reset" other layers. If the primary station transport function wants the secondary station transport function to throw away the current fragment it is building and start a new one, it can simply send a frame having the FIR bit set. Any "restart" or "abort" type functionality that affects the application layer should be handled by the application layer. This function code was adopted from the IEC870-5-2 standard, but has not been found to map appropriately to the DNP3 environment. Resolution: DNP3 does not define any action associated with the Data Link Layer Reset User Process request function code. Support of this function is not required. Function code 1 is now obsolete. This function shall not be used because there is no definition of the action to be performed by devices that receive this request and interoperability of devices that use it cannot be guaranteed. Affected Documentation: DNP V3.00 Data Link Layer, sections 3.3.3, 3.6.2, 3.7.2

Note: At the time of this bulletin, the Data Link Layer document is undergoing significant revision. The above resolution will be incorporated into the new version.

DNP3-1999 IED Certification Procedure, Subset Level 1, sections 6, 6.6.2.5 DNP3-1999 IED Certification Procedure, Subset Level 2, sections 6, 6.6.2.5 Changes to the Subset Level 1 and 2 Certification Procedures (v1.00 and v1.01):

6 Link Layer Replace (i.e. function codes 0, 1, 4, 9) with (i.e. function codes 0, 4, 9).

6.6.2.5 Invalid FCV

Remove 3rd row of table (Code = D1).

Note: These changes have been incorporated into the DNP3-2000 IED Certification Procedures, Version 2.00.

Last Updated: November 13, 2000

DNP3 Technical Bulletin 2000-005 Page 2 of 2 Reset of User Process Function Code November 13, 2000

Status: Pending General Membership Approval (Feb-2001).

20-June-2001 1 TB2000-006

DNP3 Technical Bulletin TB2000-006

Control Relay Output Block (CROB) Control Codes

Issue: The Control Relay Output Block object provides a great variety of options for performing a control output. The Technical Bulletin 9701-002 limited the permissible set of functions, but many interoperability problems continue to arise. While 9701-002 attempted to provide guidance on this issue, it left too much room for misinterpretation. Without making 9701-002 obsolete, this bulletin clarifies which control codes a device may support on a given DNP3 index (point), and provides rules that both the master and slave can follow that will guarantee that their use of the CROB object will interoperate.

Discussion: The CROB in its current form exposes the details of device hardware to the protocol stack. This is unnecessary and creates interoperability issues: not all devices support all control codes, and various vendors have chosen incompatible subsets of control codes to support. Many master vendors have attempted to achieve interoperability by configuring the control code on a point-by-point basis. While this works in most cases, some IED vendors have implemented pseudo-points that do different things based on the control code that is sent. This perverts the original intent of the CROB and makes it impossible for masters that statically configure control codes to be interoperable with such devices. This type of implementation is also not transportable across legacy protocol boundaries. Finally, it makes little sense to support all of the possible combinations of control codes in any case, as most devices can only support one of two types of control operations on any give DNP3 index:

1. Complementary function (trip/close) 2. Single function (activate)

Resolution: CROB Index Types: Each DNP3 Control Relay Output Block index may only support either: A complementary control function. Examples of complementary control functions are:

• Trip and Close • Raise and Lower • On and Off

A single control function. Examples of single-function controls are:

• Trip • Raise • Run Battery Test • Activate

NOTE: Two single-function indices may provide complementary functions. For instance, one index provides the Trip function while the other provides the Close function. Some indices, such as “Battery Test” may have no complementary function.

A device may provide some indices that support complementary control functions as well as others that support only single control functions. An index cannot support both methods of operation.

Control Codes to be Used: Complementary control function indices may permit one of the complementary control code pairs:

• 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) • 0x41(Pulse On/Close) and 0x81 (Pulse On/Trip)

20-June-2001 2 TB2000-006

Complementary control function indices may permit either or both of these pairs. If an index permits both pairs of codes, then:

• 0x03 (Latch On/NUL) and 0x41 (Pulse On/Close) must perform the same function • 0x04 (Latch Off/NUL) and 0x81 (Pulse On/Trip) must perform the same function

Single-function indices may permit one of the following control codes:

• 0x01 (Pulse On/NUL) • 0x03 (Latch On/NUL) • 0x04 (Latch Off/NUL) • 0x41 (Pulse On/Close) • 0x81 (Pulse On/Trip)

More than one of these codes may be accepted on a given index. However, each of the permitted codes must perform the same function on that index.

Vendors of slave devices are responsible for assigning control codes that are appropriate to their device. For example, a manufacturer might assign 0x41 to a breaker and 0x03 to a pseudo point. In DNP3 there is no significance to these codes providing the above restrictions are met.

A Master device must be configurable to choose, for each index:

• Either one of the complementary control code pairs, or • Any one of the single control codes.

A vendor must document the control codes its Slave devices support as follows:

• If all indices support the same control codes, the Device Profile Document shall note them. • If a fixed configuration of differing control codes is used for some or all of the indices, the vendor shall

supply a points list with the Device Profile Document enumerating the codes. • If the device is configurable per index to support a set of control codes, the Device Profile Document shall

note what the set is.

Affected Documentation: • Basic 4 - Additional Rule • Subset definitions - Additional Rule • Conformance Procedures - Additional Tests

Changes to the Subset Level 1 and 2 Conformance Procedures: Insert additional procedures in binary output section:

Desired Behavior • For complementary function indices, the Outstation must accept at least one of the following control code pairs

• 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) • 0x41 (Pulse On/Close) and 0x81 (Pulse On/Trip).

• The outstation may optionally accept both forms of complementary control code pairs. If it does: • control codes 0x03 (Latch On/NUL) and 0x41 (Pulse On/Close) must perform the same function • control codes 0x04 (Latch Off/NUL) and 0x81 (Pulse On/Trip) must perform the same function

• For single function indices, the outstation must accept at least one of the following control codes • 0x01 (Pulse On/NUL) • 0x03 (Latch On/NUL) • 0x04 (Latch Off/NUL) • 0x41 (Pulse On/Close) • 0x81 (Pulse On/Trip)

20-June-2001 3 TB2000-006

• If the outstation accepts more than one control code for a single function index, it must perform the same function for each control code it accepts.

Complementary Function Support

1. If the DUT does not have installed binary output points skip this section. 2. If the DUT does not have installed complementary function binary output points skip this section. 3. If the DUT does not support the 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) pair skip to step 8 4. Issue a valid control sequence to the first installed complementary function binary output point using control

code 0x03 (Latch On/NUL). 5. Verify the control operation completes successfully. 6. Issue a valid control sequence to an installed complementary function binary output point using control code

0x04 (Latch Off/NUL). 7. Verify the complementary control operation completes successfully. 8. If the DUT does not support the 0x41(Pulse On/Close) and 0x81 (Pulse On/Trip) pair skip to step 13 9. Issue a valid control sequence to an installed complementary function binary output point using control code

0x41(Pulse On/Close). 10. Verify the control operation completes successfully. 11. Issue a valid control sequence to an installed complementary function binary output point using control code

0x81 (Pulse On/Trip). 12. Verify the complementary control operation completes successfully. 13. If the DUT does not support both the 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) control code pair and

the 0x41(Pulse On/Close) and 0x81 (Pulse On/Trip) control code pair skip to step the next section. 14. Issue a valid control sequence to an installed complementary function binary output point using control code

0x03 (Latch On/NUL). 15. Verify the control operation completes successfully. 16. Issue a valid control sequence to the same installed complementary function binary output point using control

0x81 (Pulse On/Trip). 17. Verify that the complementary control operation completes successfully. 18. Issue a valid control sequence to the same installed complementary function binary output point using control

code 0x41(Pulse On/Close). 19. Verify the complementary control operation completes successfully. 20. Issue a valid control sequence to the same installed complementary function binary output point using control

0x04 (Latch Off/NUL). 21. Verify the complementary control operation completes successfully.

Single Function Support

1. If the DUT does not have installed binary output points skip this section. 2. If the DUT does not have installed single function binary output points skip this section. 3. For any point that is tested below, determine what action should happen when the control executes. 4. If the DUT does not support the 0x01 (Pulse On/NUL) control code for single function binary output points at

this index skip to step 7. 5. Issue a valid control sequence to the first installed single function binary output point using control code 0x01

(Pulse On/NUL). 6. Verify the control operation in step 3 completes successfully. 7. If the DUT does not support the 0x03 (Latch On/NUL) control code for single function binary output points at


(Latch On/NUL). 9. Verify the control operation in step 3 completes successfully. 10. If the DUT does not support the 0x04 (Latch Off/NUL) control code for single function binary output points at


(Latch Off/NUL). 12. Verify the control operation in step 3 completes successfully. 13. If the DUT does not support the 0x41 (Pulse On/Close) control code for single function binary output points at

this index skip to step 16.

20-June-2001 4 TB2000-006

14. Issue a valid control sequence to the first installed single function binary output point using control code 0x41 (Pulse On/Close).

15. Verify the control operation in step 3 completes successfully. 16. If the DUT does not support the 0x81 (Pulse On/Trip) control code for single function binary output points at

this index skip to the next section. 17. Issue a valid control sequence to the first installed single function binary output point using control code 0x81

(Pulse On/Trip). 18. Verify the control operation in step 3 completes successfully. Last Updated: 20-June-2001

Status: Approved February 5, 2001 by General Membership

May 31, 1999 Page 1 of 6 plus Replacement Section 3.7.2 9905-001

DNP Technical Bulletin 9905-001 Qualifier Code 11 (0x0B)

Issue:

The Basic 4 Application Layer document includes contradictory interpretations of fields associated with Qualifier Code 11.

The use of Qualifier Code 11 must be clarified to permit consistent implementation of this feature. It is expected that the use of this qualifier will become more widespread with objects such as the File Identifier Object (Object 70).

It is also desirable to be able to determine that Qualifier 11 usage correctly follows the interpretation indicated by this bulletin.

Resolution:

1. Range Field

The Range Field shall always be one octet when using Qualifier Code 11. The content of this octet specifies the number of objects that follow.

2. Object Size

For each object (as indicated by the count value in the Range Field), the Object Size shall indicate the number of octets in the following Object Identifier and any following associated Object Data. By skipping forward this many octets, another Object Size field (as indicated by the count value in the Range Field), another Object Header or the end of fragment will be reached.

This allows messages containing objects specified by Qualifier Code 11 to be parsed and the unrecognized objects ignored if the device does not support these objects.

3. Index Size Codes

Qualifier Code 11 shall use the same definitions of Index Size code as used by all other Qualifier Codes. Index Size code 5 shall be used to specify the size of the object size prefix for each object that follows an Object Header using Qualifier Code 11.

The obsolete Index Size codes (those defined for requests using Qualifier Code 11 that contain no data) shall be removed, leaving a single table of Index Size codes that are applicable in all situations.

The use of Index Size code 5 with Qualifier Code 11 shall indicate that the Range Field and Object Size field are to be interpreted as defined by this bulletin.


Discussion:

This section explains the basis for the analysis and resolution of Qualifier Code 11 issues.

1. Range Field

The size of the Range Field (holding the Count of following objects) is described in separate places as being:

• Always one octet

• Sized according to the value of the Index Size field

Only one of these interpretations is permissible.

The following sections of the Basic 4 Application Layer document define the use and structure of object headers that include Qualifier Code 11.

• Section 3.7.2 describes the Qualifier Codes. In the description of the “Free Format Qualifier” (Qualifier Code 11) this section states: “The Range Field is always a 1 octet value (Count) which specifies the number of object identifiers.”

• Section 3.7.3, figures 3-16 and 3-17 show examples for Qualifier Code 11 where the Range Field (Count of objects) is the same size as the object size field (i.e.: the Range Field is 1, 2 or 4 octets, for Index Size codes 1, 2 and 3 respectively).

• Sections 4.2.1, 4.2.2 and 4.3.1 show examples with Qualifier Code 11, Index Size 1 (Index/Qualifier octet value 0x1B). No examples are shown using Index Size codes 2 or 3 (specifying 2- or 4-octet Object Size fields). The associated text could be interpreted as suggesting either that the Object Count size is always one octet or that the Index Size sets both Object Count and Object Size to 1 octet.

Currently, for all Qualifier Codes (other than 11), the selection of Qualifier Code value (alone) determines the form and size of the Range Field (i.e.: the Index Size code does not affect the form or size of the Range Field). To maintain consistency for all defined Qualifier Codes (0-9 and 11), the statement in Section 3.7.2 that the Range Field is always one octet must be observed. Therefore, figures 3-16 and 3-17 are rendered incorrect by this Technical Bulletin.

For all Qualifier Codes (other than 11), the selection of the Qualifier Code value explicitly determines the form of the Range Field. If the statement in Section 3.7.2 (Range Field is always one octet) is observed, then the Qualifier Code alone will determine the size of the Range Field for all defined Qualifier Codes (0-9 and 11). In this case, the Index Size code only affects the size of each object’s index or object size fields, and never affects the size of the Range Field. This is a more consistent interpretation than to assume that figures 3-16 and 3-17 are correct and that the Index Size code also affects the size of the Range Field.


2. Object Size

The Object Size field (holding the size in octets of the following object) is described in separate places as being the size of:

• The object identifier but not the object data

• The object identifier and the object data

Only one of these interpretations is permissible.

The following sections of the Basic 4 Application Layer document the use of the Object Size field specified in association with Qualifier Code 11.

• Section 3.7.2 describes the Object Size field as being the size of the object identifier. It does not make explicit mention of object data: the description only mentions each object entry as consisting of a size and object identifier pairing.

• Section 3.7.3, figure 3-16 shows examples for Qualifier Code 11 with the Object Size being the number of octets in the object identifier. This figure does not include object data.

• Section 3.7.3, figure 3-17 shows examples for Qualifier Code 11 where the objects include data. Here the description explicitly states that the Object Size field is the count of octets in the object identifier only, and does not include the object data.

• Section 4.2.1 shows an example for Qualifier Code 11 with the Object Size being the number of octets in the object identifier. This example does not include object data.

• Section 4.2.2 shows an example for Qualifier Code 11 where the objects include data. Here the description explicitly states that the Object Size field is the count of octets in the object identifier and the object data.

• Section 4.3.1 shows an example for Qualifier Code 11 where the objects include data. Here the description explicitly states that the Object Size field is the count of octets in the object identifier and the object data.

The format of objects specified when using Qualifier Code 11 is a number of consecutive objects, each of which is preceded by a Size field indicating the size of that object. The size of each object may be variable, and the inclusion of the size permits each object to be parsed to its end. Thus a device parsing the object need not provide explicit support for the object in order to be able to parse to the end of the object(s) and process the remainder of the message.

If the Object Size field includes the size of the object identifier and any following object data, it would not be necessary to interpret any part of the object identifier in order to be able to skip to the next field. It appears that this is the logical purpose for this construct. Therefore the Size field should include the number of octets in both the object identifier and the object data.

3. Index Size Codes

The interpretation of Index Size codes for Qualifier Code 11 differ from the interpretation of Index Size codes for other Qualifier Code values, and the definition of these codes is


not consistently applied in various sections of the documents. A consistent interpretation of Index Size values for Qualifier Code 11 is required.

The following sections of the Basic 4 Application Layer document the use of the Index Size codes (specifically with relation to Qualifier Code 11).

• Section 3.7.2 defines the Index Size codes. This contains a description specifying a table of Index Size code values to be used in a Request (with no object data) using Qualifier Code 11 (codes 1, 2 and 3 only), and a table of values to use in all other cases.

• Section 3.7.2 defines Qualifier Code 11. Here it states that Qualifier Code 11 should be used with Index Size codes 4, 5 or 6 to define the object size.

• Section 3.7.3, figure 3-16 shows examples of requests or responses without data for Qualifier Code 11. These examples use Index Size codes 1, 2, and 3.

• Section 3.7.3, figure 3-17 shows examples of requests or responses with data for Qualifier Code 11. These examples use Index Size codes 1, 2, and 3.

• Section 4.2.1 shows an example of a request without data for Qualifier Code 11. This example uses Index Size code 1.

• Section 4.2.2 shows an example of a response with data for Qualifier Code 11. This example uses Index Size Code 1.

• Section 4.3.1 shows an example of a request with data for Qualifier Code 11. This example uses Index Size Code 1.

All examples (sections 3.7.3 to 4.3.1) use Index Size codes 1, 2 or 3. This is only consistent with the Index Size code definition in Section 3.7.2 when used for requests without data. The definition of Qualifier Code 11 in Section 3.7.2 suggests the use of Index Size codes 4, 5 and 6 to specify the object size, and does not suggest codes 1, 2 or 3. This is consistent for use of Qualifier Code 11 in responses or in requests that contain data.

The purpose of Index Size codes 4, 5 and 6 is to specify an object size. This is the same purpose achieved by Index Size codes 1, 2 and 3 for requests without data using Qualifier Code 11. Thus the special cases of Index Size codes for requests without data using Qualifier Code 11 are degenerate forms of codes 4, 5 and 6. The special cases may be eliminated completely by using Index Size codes 4, 5 and 6 for all cases to specify Object Sizes.

It is likely that existing implementations using Qualifier Code 11 will have followed the examples from Sections 3.7.3 to 4.3.1, using Index Size codes 1, 2 or 3, and may have made either interpretation for size of the Range Field and the content of the Object Size field. Enforcing the adoption of Index Size codes 4, 5 and 6 in line with their usage for all other Qualifier Codes will differentiate conformant implementations from non-conformant (or possibly non-conformant) implementations.

Note: To further simplify processing, only Index Size code 5 (specifying a 2-octet size field) shall be permitted with Qualifier Code 11.


Affected Documentation:

Application Layer Section 3.7.3.

Figures 3-16 and 3-17:

Alter the diagrams for Qualifier Code 11:

• Remove 2nd and 3rd examples

• Change “Size N1” and “Size NQ” fields to be 16-bit

• Change “Index Size MUST be 1” to “Index Size code MUST be 5”

Figure 3-17:

Replace the description after “Q-code 11; Index size MUST be 5” with:

Octets Oi1 .. OiN form the object identifier for object i where 0<=i<Q (quantity) which is followed by the object identified (IDi). The size field Ni contains a count of the octets in the object identifier (Oi1 .. OiN) and the object identified (IDi). Note that the Size N+1 field is located Size N octets after the Size N field. Note also that it is not necessary to be able to interpret the object identifiers or data in order to be able to process the remainder of the message.

Application Layer Sections 4.2.1, 4.2.2 and 4.3.1:

In all diagrams showing Qualifier Code 11:

Replacing Index Size code 1 with code 5.

In the descriptions that follow diagrams showing Qualifier Code 11:

Replace:

• The qualifier code specifies a list of object identifiers in the identifier field and the range field is an 8 bit quantity. The size field is also an 8 bit quantity specifying that the object identifier plus data is ‘size’ octets in length.

• The range field specifies the list contains 1 entry. The index size specifies that the quantity field and Size field are 8-bit in length.

With:

• The qualifier code 11 specifies a list of object identifiers in the identifier field.

• The index size code of 5 specifies that a 16-bit object size field precedes each object.

• The range field is an 8-bit quantity specifying the number of object identifiers that follow.


Application Layer Sections 4.17, 4.18 and 4.19:

Figures 4-30, 4-32 and 4-34:

In the Qualifier field, replace Index Size code 1 with code 5.

Replace:

• The qualifier indicates the range field is an 8 bit quantity specifying the number of object identifiers that follow

With:

• The qualifier indicates that the application identifier size field is a 16-bit quantity.


Application Layer Section 4.20:

Figure 4-36:

In the Qualifier field, replace Index Size code 1 with code 5.

Replace:

• The qualifier indicates the range field is an 8 bit quantity specifying the number of object identifiers that follow

With:

• The qualifier indicates that the configuration identifier size field is a 16-bit quantity.


Application Layer Section 3.7.2:

Replace this section in its entirety with the reworded section appended below:

3-24 May 31, 1999 9905-001 DNP User Group

3.7.2 Qualifier Field

The qualifier field specifies the meaning of the following Range Field.

bit: 7 6 5 4 3 2 1 0

R Index Size 4-bit Qualifier Code

Figure 3-15 Qualifier Field

R Reserved bit always set to 0

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

The Range Field may also be a single value, or may be absent if so specified by the Qualifier Code. A single value may be a count of the objects following the Object Header, or may specify the index range zero to (range field value – 1).

Table 3-1 lists the commonly-used combinations of Qualifier Code and Index Size Code (Qualifier Field values), showing the size of the Range Field (in octets).

DNP permits combinations of Qualifier Code and Index Size Code that are not shown in Table 3-1. These combinations are explained in Figures 3-16 and 3-17. Note that combinations that do not appear in Table 3-1 are rarely used in DNP implementations, and only where special conditions warrant their inclusion. It is recommended that only combinations appearing in Table 3-1 should be used.

Explanations of the purpose of each Qualifier Code and Index Size Code appear following the tables.

Description Qualifier Field (hexadecimal)

Range Size (octets)

Range Field contains 8 bit start and stop indices 00 2 Range Field contains 16 bit start and stop indices 01 4 Range Field is omitted, entire range is specified 06 0 Range Field contains an 8 bit object count 07, 17 1 Range Field contains a 16 bit object count 08, 28 2 Free Format Qualifier 5B 1

Table 3-1 Commonly-Used Qualifier & Index Codes


Index Size (3-bits)

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

0 = objects are packed with no index prefixing them 1 = objects are prefixed with a 1 octet index 2 = objects are prefixed with a 2 octet index 3 = objects are prefixed with a 4 octet index 4 = objects are prefixed with a 1 octet object size 5 = objects are prefixed with a 2 octet object size 6 = objects are prefixed with a 4 octet object size 7 = Reserved

Qualifier Code (4-bits)

The Qualifier Code is used to specify the meaning of the Range Field. Qualifier Code values are:

0 = 8 bit start and stop indices in the Range Field 1 = 16 bit start and stop indices in the Range Field 2 = 32 bit start and stop indices in the Range Field 3 = 8 bit absolute address identifiers in the Range 4 = 16 bit absolute address identifiers in the Range 5 = 32 bit absolute address identifiers in the Range 6 = no Range Field (implies all the specified objects) 7 = 8 bit single field quantity 8 = 16 bit single field quantity 9 = 32 bit single field quantity

10 = Reserved 11 = free format qualifier 12 = Reserved 13 = Reserved 14 = Reserved 15 = Reserved

• Start and Stop Sub-Fields in the Range Field (Qualifier Codes 0–5)

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

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

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


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

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

• All objects of the given object type (Qualifier Code 6)

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

Qualifier Code 6 = no Range Field (implies all the specified objects)

• Single field quantity (Qualifier Codes 7, 8 and 9)

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

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

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

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

The Index Size field should not indicate an object size identifier as this would not uniquely specify the data objects in question and should be set to 0 if no identifiers or indices are following. The order of identifiers (and optional data objects) is arbitrary but should not consist of duplicate indices unless specifying distinct data instances for the same object (e.g.: multiple binary events for a single binary input).

• Free-format Qualifier (Qualifier Code 11)


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

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

This object has a free-format and need not be interpreted in any way by the application layer.

The Range Field is always a 1-octet value (Count) which specifies the number of objects. Following the Range Field are Count object size field/object pairs. The object size field that prefixes each object determines the size of the object (in octets).

The size of the object size field is determined by the Index Size code. To simplify processing, only Index Size code 5 is permitted, specifying the size of the object size field to be 16-bits.

• Reserved Qualifier Codes (Qualifier Codes 10, 12–15)

Qualifier Codes 10 and 12–15 are reserved and should not be used.


This page intentionally blank

December 8, 1999 1 of 2 9912-002.doc

DNP Technical Bulletin 9912-002 Unsolicited Event Reporting: Retry Configuration

Note:

This Bulletin identifies a protocol revision approved by the DNP Technical Committee on December 8, 1999, subject to ratification by

the DNP Users Group.

Issue:

Although DNP provides a method for reporting events through unsolicited reporting by exception (URBE), successful system deployment requires tuning of the reporting parameters on a system-by-system basis. This is due to variations in the performance of communication systems that cannot be universally predicted during design of a reporting device. For this reason, the Subset Level 2 Certification Procedure requires that a configurable timeout be included in devices supporting URBE.

Due to the variations in communication system reliability, varying numbers of retries may be necessary before the URBE is successfully confirmed. In addition, experience has shown that in systems dictating a very low frequency of integrity polls, it can take an excessive amount of time to resume normal operation after a communication interruption. Thus, it is essential to also be able to configure the retry count such that retries continue on an indefinite basis until communication of the exception report is successful.

Resolution:

This Bulletin further extends the requirements for configuration of URBE in slave devices. Devices must support the ability of the end user or system integrator to choose the maximum number of URBE retry attempts during configuration. One of the choices must provide for an indefinite (and potentially infinite) number of retries.


Level 1 and 2 Subset Definitions and Certification Procedures

Modifications to Certification Procedure

Insert additional Procedure:

December 8, 1999 2 of 2 9912-002.doc

(Section # TBD) Retries unsolicited responses configurable number of times 1. Configure DUT for a predefined number of retries. 2. Issue a request to enable unsolicited responses for all classes of data by using

function code 0x14 with three object data headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4.

3. Verify that the DUT responds with a null response indicating the request was processed without error.

4. Disconnect the communication cable so that confirmations cannot be received in the slave.

5. Generate class 1, 2, or 3 event data. 6. Verify that an unsolicited response is transmitted. This may involve waiting

for an amount of time, dictated by the DUT and specified by the DUT’s Device Profile Document, within which the DUT may wait for a minimum number of events to be collected before transmission of an unsolicited message.

7. Verify that the unsolicited response requests an application layer confirmation. 8. Verify that DUT retries reporting until number of retries exceeds predefined

number set in (1) above. 9. Repeat procedure, reconnecting communication cable after at least one retry.

Verify that retries are terminated when confirmation is received. 10. Repeat procedure with indefinite retry count configured in DUT. 11. Verify that retries continue for an extended period of time.

December 8, 1999 1 of 3 9912-003.doc

DNP Technical Bulletin 9912-003 Broadcast Message Confirmation and Address Reservation

Note:

This Bulletin identifies a protocol revision approved by the DNP Technical Committee on December 8, 1999, subject to ratification by the

DNP Users Group.

Issue:

Broadcast messages serve diverse needs for application functionality as well as for communication bandwidth optimization. However, these diverse requirements dictate different processing in response to the broadcast request.

For example, in systems requiring simultaneous freezing of accumulated values (meter reading, load monitoring, etc.), writing the accumulator freeze application request to the broadcast address allows this function to be performed in parallel to multiple devices over communications. Because the delivery of messages to the broadcast address is not guaranteed, in this application it is essential for the master to reliably interrogate the IIN1-0 bit (All Stations Message Received) to know which slaves received the freeze request. The only way to do this is for the slave to inhibit clearing of IIN1-0 until it knows that the master has received the message. This is accomplished in DNP by having the slave’s next response include a confirmation request, and to suppress clearing of the IIN bit until the confirmation has been received.

In contrast to the first example, consider the case where the message being broadcast is “Disable Unsolicited Messages” being sent to reduce communication traffic caused by a major system event. It may not be desirable to generate the additional communication traffic for subsequent requests particularly when the receipt of the original broadcast message was intended to reduce bandwidth usage.

Both of the applications above may coexist in a single network. Thus it is desired that the confirmation of the receipt of the broadcast message be dynamically controlled by the master depending upon its requirements.

The DNP specification does not explicitly require or preclude the use of application layer confirmations to confirm receipt of broadcast messages. Thus there is a need to further refine the specification to enhance interoperability.

Resolution:

Additional broadcast addresses will be assigned for the purpose of signaling the slave to request or suppress confirmation of receipt of the broadcast message. The

December 8, 1999 2 of 3 9912-003.doc

following device addresses are now reserved (Note: All addresses are in hexadecimal):

FFFF Presently assigned broadcast address. When a message is received on this address, the slave must set IIN1-0 in the next message it transmits to the master that sent the broadcast message. The use of this address signifies that the slave implementation may determine whether or not to request confirmation of messages sent with IIN1-0 set (that would not otherwise require confirmation), and whether or not to require the receipt of that confirmation before clearing IIN1-0 in subsequent messages. This provides compatibility with existing implementations, and will provide the same behavior as either one or other of the addresses FFFD and FFFE.

FFFE Messages sent to this address require that the IIN1-0 bit must be returned with the application layer request for confirmation bit (Application Control, bit 5) set. IIN1-0 may not be cleared in the slave until the confirmation is received. Note: If unsolicited event reporting is enabled, since IIN1-0 may be reported in conjunction with an unsolicited event report, this response (which requires confirmation) will serve as the notification that the All Stations message was received.

FFFD Messages sent to this address request the IIN1-0 bit to be returned with the application layer request for confirmation bit (Application Control, bit 5) suppressed. IIN1-0 will be cleared in the slave upon transmitting the first response from the slave. Note: IIN1-0 may be reported in conjunction with responses to requests that otherwise require confirmation, or with an unsolicited event report, and since these requests/responses otherwise require confirmation, the confirmation will not be suppressed even though the message is sent with IIN1-0 set. Thus the use of the FFFD broadcast address implies that confirmation requests in responses sent with the IIN1-0 set should be suppressed, but that the confirmation may be requested if required by the details of the response being issued.

FFF0–C These addresses are now reserved for future use.


Basic Four Document Set, Level 1 and Level 2 Certification Procedures

Changes to the Subset Level 1 and 2 Certification Procedures

Insert additional Procedure: (Section # TBD) Broadcast Address Specifying Confirmed Response Options

1. Cycle the power to the DUT. 2. Issue a request for Object 60 Variation 2.

December 8, 1999 3 of 3 9912-003.doc

3. Verify that the device responds with IIN1-7 set indicating the device has been restarted.

4. Issue a Write to Object 80 Variation 1 using the qualifier 0x00. Use a start index of 7 and a stop index of 7, followed by the value 0. Specify broadcast address FFFE. Request a data link layer confirmation.

5. Wait a reasonable application layer timeout, for example, 2 seconds. 6. Verify that the device does not respond, with either a data link layer

confirmation or a response to the Write operation. 7. Issue a request for Object 60 Variation 2. 8. Verify the DUT responds with a Null Response with IIN1-7 (restart) cleared

and IIN1-0 (all stations message received) set, and an application layer confirmation requested.

9. Before sending the requested confirmation, repeat the request for Object 60 Variation 2, and verify that IIN1-0 is still set in the response.

10. Send the application layer confirmation. 11. Issue a request for Object 60 Variation 2. 12. Verify the DUT responds with a Null Response with both IIN1-7 and IIN1-1

cleared. 13. Repeat steps 1-12 using address FFFD as the broadcast address. In step 8,

verify that an application layer confirmation is NOT requested. In step 9, verify that IIN1-0 is not set in the response. Note: Step 10 will not be necessary.

April 22, 1998 1 of 1 9804-001.doc

DNP V3.00 Technical Bulletin 9804-001Rules for Synchronizing Application Sequence Numbers

Issue: The DNP V3.00 Application Layer specification discusses how to use and incrementapplication layer sequence numbers to detect duplicate messages. However, it does notspecify how these sequence numbers should be initialized or synchronized between twodevices. Because of this, it is possible for a device to erroneously believe it has received aduplicate message if it or its peer device has recently restarted.

Furthermore, the specification does not discuss how a device receiving a broadcast messageshould interpret the sequence number. This is a problem because each device on a broadcastlink may be expecting a different sequence number.

Resolution:1. The receiver (master or slave) of a broadcast message does not check the sequence number.

Multi-fragment broadcast messages are not permitted. 2. The receiver (master or slave) of a non-broadcast fragment always checks the sequence

number against that of the previous fragment received, except as noted in (5) and (6) below. 3. If the sequence number matches the previous fragment, the receiver compares the incoming

fragment and the previous fragment byte-by-byte. This comparison was not specified in theoriginal DNP Application Layer description.

4. If both messages match byte-for-byte, then the receiver responds with the same data it sent as

its previous response but does not perform any further action. 5. If a Master is receiving an unsolicited response and the RESTART IIN bit is set, the master

accepts and executes the message regardless of sequence number, then clears the device’sRESTART IIN. (This need not be a special case, since the RESTART bit will necessarilymake the unsolicited response at least one bit different that the previous one.) It continueschecking sequence numbers thereafter.

6. A device that has just restarted always accepts and executes the first message it receives,

regardless of sequence number. It begins checking sequence numbers thereafter. 7. A Master must never perform application layer retries of output operations, i.e. never send

two output messages with the same sequence number for SELECT, OPERATE, or DIRECTOPERATE function codes.

Affected Documentation:DNP V3.00 Application Layer

Chapter 3: Definition of DNP Message FieldsSection 3.2: Communication Flow ControlSection 3.3: Master Request & Unsolicited Response Collisions

DNP Technical Committee Technical Bulletin 9804-002

DNP Confirmation and Retry Guidelines

April 22, 1998 1 of 6 9804-002.doc

DNP V3.00 Technical Bulletin 9804-002 DNP Confirmation and Retry Guidelines

1. Introduction There has been significant confusion about the usage of Link layer confirmations vs. Application layer confirmations and when neither, one or both should be used. The general users group membership has requested that the Technical Committee provide a guideline on this subject. It is the purpose of this document to review what we are trying to accomplish by the confirmation mechanisms and present a general guideline for how to use these services effectively. This guideline supersedes the recommendations presented in the Subset Definitions Revision 2.00 Dated November 1995.

2. Background

2.1 Why are confirmations necessary Certain operations a SCADA (Supervisory Control and Data Acquisition) Remote Electronic Device must perform require a mechanism to verify that the recipient of a transmission received that transmission correctly. A classic example is the processing of Status (or Binary Data) changes that have been queued in the remote device. This data is sometimes referred to as Sequence of Events (SOE) data. The remote station must insure that the data transmitted to the host remains in order so that a recreation of the real world “scenario” of status changes can be accomplished by the end user. It must also guarantee that no data is lost in the transmission process. In the above example a remote device may have 100 binary changes queued to report to its host. The host may, however, request that only 20 changes be returned in the current request. The remote device must have a mechanism for determining when and if the host received the 20 changes so that it can

1. Remove those changes from its change queue 2. Know what to return in the next request

2.2 What are Application Layer Fragments Each DNP message can consist of one or more application layer “fragments”. Each fragment contains a whole number of DNP objects, qualifiers, and point indices and is “Parsable” without any additional assembling of partial messages (otherwise referred to as fragments or packets). In other words, a DNP application layer is a “Understandable and Fully Digestible” piece of SCADA information.

2.3 What are Application Layer confirmations A remote device can request that the receiving station (host) send an application layer message in response to its’ transmission indicating that it received and understood the fragment. Furthermore, the host only responds to the confirmation request if it can process the message (e.g. it has room in its database for the information).



April 22, 1998 2 of 6 9804-002.doc

2.4 How the Application Layer Confirmation mechanism works When a remote station transmits vital information (usually event data) that must not be lost and can not be reproduced (e.g. static data is easily reproduced so it is usually not confirmed) It requests that the host station send a confirmation message. This confirmation message indicates that the message was received, understood, and processed (or will be processed) by the host. The remote device has therefore transferred responsibility for transmission of this data to any subsequent destinations to the host. It can confidently delete these items from its change buffers.

2.5 What are Link Layer Frames Each application layer fragment is made up of one or more link layer “frames”. For small messages there will be one link layer frame for each application fragment. For large messages there will be several link layer frames for each application layer fragment. Link frames are not necessarily parsable by themselves. For example, it may take 5 link layer frames combined together to form a large DNP object that can be parsed by the application Layer.

2.6 What are Link Layer confirmations When a remote device transmits a link layer frame it can request a link layer confirmation from the host station. When requested, the host station will transmit a link layer confirm frame to the remote station indicating that it received that frame and that it was properly formatted.

2.7 How the Link Layer Confirmation mechanism works In theory a remote station can guarantee delivery of each frame sent to the host station by requesting a link layer confirmation for each frame. If it receives a confirmation for each and every frame in a transmission it can be assured that the host accepted the formatting of the frames and that they arrived without any CRC errors. It cannot, however, determine whether the frames were assembled correctly, or whether the host understood the objects contained within the assembled application fragment. Only the application layer confirmation can guarantee this.

2.8 Retransmissions When the remote device requests either an application layer or a link layer confirmation it waits a specified period of time before proceeding on to its next task. If the confirmation is not received within this period of time the request is deemed to have “timed out” and the remote device can either give up for this transmission or try again, retransmitting the exact same message again. The number of times a device will try again is set to a relatively low number (usually 3). Retransmissions can cause synchronization errors in the dialog between the remote device and the host if one party retransmits and the other was not expecting it. In particular, this can cause collisions in a Frequently Polled environment. Retries can be used in some cases, but require careful consideration

• In half-duplex systems, it is possible to configure polling intervals and timeouts large enough to allow for all possible retries from a device. However this practice sometimes makes polling intervals larger than desired.

• The use of collision avoidance in the data link and/or physical layers makes retries possible. • Retries are recommended in the case of unsolicited responses, since collision avoidance is required

as a matter of course. If retries were not employed the master will not be expecting the unsolicited



April 22, 1998 3 of 6 9804-002.doc

data and therefore will not know that it is missing. It should also be noted that the successful application of retries using collision avoidance techniques depends on several factors. Among the most important factors include the robustness of the collision avoidance mechanism employed and the load on the communications channel. If the mechanism is unable to avoid a collision, retries may aggravate the situation and further reduce effective bandwidth of the communications channel. As with any communications system, careful attention must be paid to bandwidth allocation and management for a successful system design. In particular, overloading communications circuits will have undesirable effects on system performance. In a frequently polled configuration overloaded circuits will elongate polling cycles (e.g. scans per second). In an unsolicited response configuration overloaded circuits will render response times non-deterministic during periods of peak activity.

3. Summary • It is recommended that Application layer confirmation be used for binary event data and data link

confirmations be disabled for all data for the following reasons.

1) For most messages Link Layer confirmations are redundant. 2) Link layer confirmations do not insure that the host understands the data sent therefore…

a) Application confirms are required for event data anyway. 1) It only costs 5 bytes of additional overhead to use a more robust confirmation mechanism. 2) There is less ambiguity associated with the sequencing of fragments.

• It is recommended that Application Fragment size be reduced as necessary in extremely noisy environments which will provide similar performance to link layer confirms. This parameter should be selectable. NOTE: Due to the requirement that each application fragment be independently parsable, DNP developers should consider that the application layer fragment cannot be reduced to smaller than the largest object to be transferred, plus headers and overhead.

• It is recommended that retries be disabled in frequently polled environments. • Retries are recommended in unsolicited response configurations, but careful consideration must be

given to communications circuit loading. • These recommendations do not eliminate the requirement for devices to respond correctly to frames

requiring data link confirmation. Devices must respond with CONFIRM - ACK or CONFIRM - NACK frames (as specified in the protocol documentation) to any SEND/CONFIRM frames they receive.

4. Discussion

4.1 Why Application Layer Confirms are preferred

4.1.1 Link Layer Confirms are Redundant For most remote station responses that amount of data returned will fit in one link layer frame. This results in there being one link layer frame for each application layer message. Since we can not determine from a link layer confirmation whether the host understood our message we need to request an application layer confirmation for critical data anyway. This makes the link layer confirmation redundant.



April 22, 1998 4 of 6 9804-002.doc

It should be noted that almost every Level 1 device (IEDs) returns its’ entire static data set in one application fragment using only one link layer frame. In fact, at 9600 baud a full link layer message takes approximately 1/3 of a second to transmit. In a typical Multi-dropped environment where the host will poll each device for data in a round robin fashion, IEDs returning one full link frame per response would limit the channel to 6 IEDs per port to maintain the typical 2 second update requirement of most SCADA systems. This estimate does not include the time required by the host to transmit the request or the latency in the turn around time of the remote device or the key-on time of the communications circuit. In the “Real World” a 2 second update can be guaranteed for 3-4 IEDs that return full link layer frames assuming normal latencies. If you add a link layer confirm to every packet you add at least 10 mS to each exchange between the host and the remote device, not including device latency or communications latency. Devices capable of report-by-exception greatly alleviate this problem by transmitting only the data that has changed since the last request. In the steady state most responses indicate nothing has changed since the last poll and consume only 17 mS per response. A host can manage (or limit) how much event data the remote device returns by specifying a maximum number of events to return in the request, thereby guaranteeing worst case turn around time.

4.1.3 Assures understanding not just reception Application layer confirmations guarantee that the data transmitted by the remote was assembled and understood. Link layer confirmations guarantee that the frame arrived with no bit errors. For critical data, arrival without bit error is not sufficient cause to delete the information from the remote’s change buffers. Confirmation of proper assembly and understanding of the message are required before a remote can transfer responsibility of data deliver to the host. Application layer confirmations alone can provide this information.

4.1.4 Marginal performance penalty A link layer confirmation requires 10 bytes to transmit. An application layer confirmation requires 17 bytes to transmit. That is approximately 7 mS at 9600 Baud. It can argued that the latency of device (time required to begin transmitting) is less for link layer confirms than for application layer confirms. While this is highly implementation specific and may in some cases be true, the actual latency is often dwarfed by the turn on time of the transmitter (e.g. radio). In any case, we have shown previously, that for critical data a link layer confirmation is redundant because an application layer confirmation is required anyway.

4.1.5 Application sequencing is more robust Link layer frames are much more susceptible to synchronization errors that are Application layer fragments. Link layer services provide a single bit that toggles for detecting packet ordering. Application layer services provide an incrementing sequence number for detecting packet ordering. Sequence numbers are significantly more robust, and less susceptible to synchronization errors.

4.2 Noisy Environments

4.2.1 Smaller packet sizes at higher bit error rates In high bit error rate (noisy) environments, the probability of an error being introduced into a transmitted packet increases with the length of the packet. Therefore, the smaller the packet the lower the probability there will be an error in that packet. When large application layer messages are made up of several link frames it was intended that each link frame be confirmed individually to minimize the risk of having to re-send the entire application layer fragment because one link layer frame was corrupted. Since the



April 22, 1998 5 of 6 9804-002.doc

performance penalty for application layer confirms is not significant the same thing can be accomplished by reducing the application layer fragment size. This has the added benefit of intelligently requesting confirms as well.

4.2.2 Only Application layer fragment size sets reliability Typically link layer frame size is not selectable while application layer fragment size is. Since the link layer frame size is fixed, the probability of error cannot be reduced below Plinkerror where:

Plinkerror = (1 – Pnbitscorrect) Plinkerror = (1 –(Ponebitcorrect )n ) Plinkerror = (1 - (1 - BER)n )

And BER = Bit Error Rate n = 296

Reducing application layer fragments sizewill correspondingly reduce the transmitted link layer frame size (e.g. reducing n) and realize a reduction of error probability beyond that provided by link services (e.g. Perror = (1 - (1 - BER)n )). It should be noted that by reducing application size below link layer size:

• the probability that any one piece of data will make it successfully in high noise environments is increased.

• the number of turn arounds necessary for large amounts of critical (event) data is increased. • a practical minimum is no smaller than the largest application object that must be transmitted

plus overhead.

4.3 Retries and Polling

4.3.1 Stepping on your neighbors toes Application or Link layer retries are not recommended for use in frequently polling environments. If a remote device requests a confirmation from the host and it does not receive it, the remote device should wait for the next request to send the information again. If the remote device were to retry it is highly likely that the host has moved on the next remote device in the polling loop. According to Murphy, that device will be transmitting its response to the host request when the first device retries and causes a collision. Even in cases when there is only one device on a line, the device may retry while the host is sending the next request and cause a collision.

4.3.2 No real benefit In a polling environment each request can be viewed as an invitation for the remote device to place data on the share communications circuit. The host acts to manage the bandwidth on the link so the collisions DO NOT occur, and that the response is predictable under all situations. If any on response is lost, the host will ask again allowing the remote device to re-send its data. This is effectively a managed retry anyway, but has eliminated the possibility of collisions.

4.4 Retries and Unsolicited Responses In a system using unsolicited responses, the physical layers and data link layers of the devices together manage the bandwidth on the link and avoid collisions. Retries are therefore not a liability in this situation,



April 22, 1998 6 of 6 9804-002.doc

because (e.g.collisions) rarely occur. In fact, retries are a requirement when unsolicited responses are used. Unsolicited data is by definition not expected by the master, and therefore it does not know to request the data it is missing. The burden is therefore on the remote device to ensure it gets through.

4.5 Unconfirmed User Data Only

Since we are not recommending the use of link layer confirmations, the Frame Control Bit (FCB) and its associated logic and problems become unnecessary. If you plan never to request a link layer confirm then there is not need to reset the link, or incorporate the added complexity in the device implementation. Note however, that all devices must nevertheless respond to RESET LINK and confirmed user data frames with the appropriate ACK or NACK frames. This is required for interoperability.

5. Conclusion. It is the recommendation of the technical committee that link layer confirmation services not be used, but that unconfirmed user data services be used at the link layer, and that application layer confirmation services be used exclusively. It is further recommended that in high bit error rate environments (noisy) that the application fragment size be reduced accordingly. Finally, Application layer or link layer retries should never be used by a slave device in a frequently polled environment but are acceptable in a unsolicited response environment assuming adequate collision recovery techniques are used. Note: Despite the above recommendations certain devices may not be able to receive unconfirmed data link frames back to back. If a device is capable of generating multiple link layer frames in a single response it is recommended that it also be able to enable, via configuration, data link confirm requests for flow control.

April 22, 1998 1 of 1 9804-003.doc

DNP V3.00 Technical Bulletin 9804-003 Recommended Layer Terminology

Issue: Some User’s Group members have had difficulty discussing protocol issues because the DNP documentation does not distinguish well between the sections of DNP messages defined at the Data Link Layer, Transport Function, and Application Layer. Resolution: This bulletin formally distiguishes between an Application Layer fragment, a Transport Function segment, and a Data Link Layer frame, and clarifies how these terms relate to the Open Systems Interconnect (OSI) terminology used in much of the Basic 4 documentation. OSI terminology refers to a Service Data Unit (SDU) and a Protocol Data Unit (PDU). The SDU is the data presented to the service (upper) interface of a protocol layer by the layer above. The PDU is the data actually formatted by the layer and passed to the layer below. In the DNP 3-layer model, “PDU” or “SDU” may be preceded by “Application”, “Transport” or “Link”. Therefore, an APDU is the data transferred from the application layer to the transport function, and may also be called a TSDU. The following table defines fragment, segment, and frame and their corresponding OSI terms. Function Common

DNP Name

Consists of...

OSI Term

Function and Use

Application Layer

Fragment Application Header, Object Headers, Object Data

APDU, TSDU

A response to a request may consist of multiple fragments. Each fragment must be separately parseable. Fragmentation at the application layer permits the setting of an upper limit on the parsing buffer required by the receiving side. The recommended maximum fragment size is 2K, per the DNP V3.00 Subset Definitions.

Transport Function

Segment Transport Header + part of an APDU

TPDU, LSDU

Segmentation breaks up a fragment into pieces that will fit in a Data Link Layer frame. A segment need not be parseable. Each segment contains a Transport Header, but only the first segment of any fragment contains an application header. A segment consists of up to 250 octets, 249 of which are application layer data.

Data Link Layer

Frame Data Link Header + CRCs + complete TPDU

LPDU The data link layer uses a small frame size relative to the application data to ensure excellent error detection and recovery. A frame may be up to 292 octets including all headers and CRCs.

Affected Documentation: DNP V3.00 Transport Functions Chapter 2

April 22, 1998 1 of 3 9804-004.doc

DNP V3.00 Technical Bulletin 9804-004 Virtual Terminal Objects 112 and 113

Issue DNP 3.0 does not define a protocol suitable for arbitrary, unstructured data flow between Master and Slave sides of a link. Many IEDs (Intelligent Electronic Devices) have a separate serial interface used for configuration and diagnostic purposes and directly interfaces with either dumb terminals or portable computers. The intent of this Virtual Terminal (VT) Protocol is to allow data transfers which previously required a separate physical connection to a non-DNP port to proceed over the existing DNP port. Support for VT is optional at the discretion of the IED vendor.

Resolution The VT protocol is defined to be the emulation of one or more independent communication links between the Master and Slave devices which can exchange data. Each Slave communication channel is assigned a Virtual Port number. These communication links transport proprietary protocols and are typically used during initial testing and commissioning of a complete system. The VT proposal is modeled after the TELNET portion of the Internet Protocol Suite. This Technical Bulletin defines the VT protocol which can be used with DNP 3.0 devices. Two new DNP objects are defined, along with the procedures for accessing these objects. Both polled and report-by-exception (RBE) environments are supported. A number of observations are made regarding this protocol along with recommendations to vendors and integrators concerning tradeoffs. Finally, rules are defined for VT devices. Two new objects are defined. Object 112 is named the “Virtual Terminal Output Block” which is a static object structured identically to object 110 (Octet String Object). This object is used only with the Function code WRITE (FC=2) to send data from the Master side to the Slave side of the link. Object 113 is named the “Virtual Terminal Event Data” which is an event structured identically to object 111 (Octet String Event Object). This object is used to send data from the Slave side to the Master side of the link. Master devices may use only Function codes READ (FC=1) or ENABLE UNSOLICITED MESSAGE (FC=20) or DISABLE UNSOLICIED MESSAGES (FC=21) or ASSIGN CLASS (FC=22) with this object whereas Slave use only Function codes RESPONSE (FC=129) or UNSOLICITED MESSAGE (FC=130). These objects obey the usual DNP rules for static and event objects except that object 112 is NEVER returned in a Class 0 poll. In particular, object 113 can be assigned to Classes 1-3, optionally support the assign class function code, and optionally be sent in an unsolicited response. The procedure for accessing these objects is as follows. Master devices transmit data to slave devices by WRITEing one or more of object 112 to a Slave using the Virtual Port number as the DNP point number. Slaves send information to the Master using the Virtual Port number either by responding to a Master READ (FC=1) request of object 113 or using an Unsolicited Response message (FC=130). Messages can flow in either direction at any time. There are no explicit procedures for the initiation or conclusion of a VT session (i.e. implicit connections exist by the mere presence of a VT compatible Slave IED).

April 22, 1998 2 of 3 9804-004.doc

In the following (hypothetical) example of a VT session, xx/yy is the object number and variation and all message use point 0: 1. Master: Write 112/1, data=13 decimal= <CR> (our wakeup command) 2. Slave: respond only IIN (FC=129, two IIN bytes) 3. Master: Read 113/0 4. Slave: respond with IIN only (Slave has no data to send to Master) 5. Master: Read 113/0 6. Slave: respond with 113/3, data= "OK"<CR> 7. Master: Write 112/6, data= "CLEAR"<CR> (clear slave command) 8. Master: Write 112/7, data= "LOGOFF"<CR> (end the IED session) 9. Master: Read 113/0 10.Slave: respond with 113/7, data = "OK"<CR>"BYE"<CR> (at this point, the Master somehow knows that the Slave will not send additional messages and therefore it can cease polling the Slave VT port 0) The above example illustrates a few important points: Line 4 shows how Slaves respond when no data is available for transmission to the Master Line 7 and 8 show how a Master could send any number of messages without polling for responses Line 10 shows that Slaves MAY accumulate responses (they could also respond with two separate Messages). Not shown is that Masters could poll for Slave responses without sending data. Responsibility for VT maintenance is split between the Master and Slave. The Master is responsible for maintaining an environment that allows Slaves responses to be sent in a timely manner. In a polled system, the Master must periodically poll for Slave responses whenever a response is possible. In an unsolicited response environment, the Master must ensure that the background data traffic is at a low enough level to ensure that Slave responses can be sent without impacting more important event data. Slaves are responsible for generation of VT messages either in response data sent by the Master or spontaneously.

Observations • The VT definition allows users to interactively “log onto” an IED without requiring another

serial communication channel beyond the required DNP port. No structure has been defined for the data passing in either direction. There are two implications of this: • any octet oriented protocol (including both binary and ASCII) can be sent over VT • there is no pre-defined "end-of-transmission" indicator.

• The lack of an "end-of-transmission" indicator implies that Masters must continuously poll every possible Slave VT port unless responses will never be generated. Three conditions allow Master to cease polling: • Slave device is not VT capable • the system is pre-configured for only unsolicited responses • (somehow) the Master knows that responses cannot be sent from a VT-capable Slave

• Since DNP requires point numbers to begin at zero, every VT-capable Slave must support Virtual Port 0

• VT traffic will use some DNP bandwidth. There is an implicit assumption made that excess DNP bandwidth is to be traded for access to other communication channels within the IED.

April 22, 1998 3 of 3 9804-004.doc

If there is no excess bandwidth, using VT to support high-priority IED communications is pointless.

Recommendations • Masters should have some method to attempt retries of data transfer. If a human issues

commands, then this may be as simple as asking the human to repeat the command. • Masters should have some means to determine the "end-of-transmission". Again, if a human

issues commands, this could be as simple as forcing the user to "disconnect" from the IED when finished.

• If a Slave device has multiple communication ports with different capabilities, Virtual Ports

should also be provided. This allows a one-to-one mapping of physical ports to virtual ports. Note that additional virtual ports could provide flexibility which does not exist at the physical connection level.

• IEDs with large amounts of data transportable over VT should make provisions for limiting

the usage of the DNP link by VT. Possibilities include the ability to disable unsolicited reporting and allowing configuration of object 113 to Class 1 or Class 2 or Class 3 polls.

• Limiting the length of the message strings both ensures maximum compatibility with

memory-limited devices and allows other higher priority messages to be interspersed with VT messages. Note that a single data link fame accommodates up to a 240 octets VT message.

Rules • Object 112 is used only with the WRITE function code from the Master. Reads are not

allowed. • The point number(s) to be used for VT must appear in the Device Profile Document. • Slaves which support VT must support the Response function code (FC=129). They may

optionally support Unsolicited Response and Assign Class functions.

Affected Documents DNP 3.0 Data Object Library

Chapter 14: New chapter name to be determined.

April 22, 1998 1 of 2 9804-005.doc

DNP Technical Bulletin 9804-005 8-Bit Unsigned Integer Object 102

Issue: Some devices require the capability to read and write single-byte values, for which the

existing analog input and output values are insufficient. Resolution: A new object, Object 102, is defined as an 8-bit Unsigned Integer Object Reading and Writing of 8 bit memory locations could be implemented using this object

together with absolute addressing qualifiers. Please refer to the following Object Definition for Details. Affected Documentation: DNP V3.00 Object Library Chapter 13: Alternate Numeric Object Definitions

April 22, 1998 2 of 2 9804-005.doc

8-Bit Unsigned Integer Object Data Object 102 Variation 1 Type: Static Description: The 8-Bit Unsigned Integer Object represents a value from 0 to 255. This object is not

included in Class 0 poll response. For this object only read, write and response function codes are permitted.

Object Coding:

Current Value [0] 7 0

UI1 = SQ1 { Current Value = UI [0..7] <0..255>}

April 22, 1998 1 of 199 9804-006.doc

DNP Technical Bulletin 9804-006 Analog Object Floating Point Variations

Issue: The DNP User’s Group required a definition for a standard implementation of Floating

Point Objects and Floating Point Event Objects. These are required for representation of analog quantities in floating point format.

Resolution: Floating Point Object reporting is defined as follows:

• The existing object group 100 is not designated “Static”. To read a group 100 value, it is necessary to specifically request that group.

• It is recommended that existing group 100 objects not be used in the future. • Short and Long Floating point variations have been added to object groups

30, 31, 32, 33, 40 and 41. Note that this includes floating point outputs as well as static, frozen and event floating point inputs. Events can be reported with or without timestamps. Attached Object Definitions specify details.

• These variations shall not be part of any current subset definition. • If a device supports these floating point variations, it must provide a

configuration mechanism that will force these points to be reported as integers when polled for Class Data or variation zero (0). It is appropriate for the device to set the over-range flag if necessary due to conversion problems.

• When not configured to force reporting as integer, a remote device may default to responding to a request for Class Data or variation zero (0) by reporting some data as integer and some data as floating point.

Note:

• The extended format used in Object 100 Variation 3 has not included. • The floating point variations of objects 30, 31, 32, 33, 40 and 41 do not

include the Units field used in Object 100. An alternate mechanism for providing this information may be provided in the future.


DNP V3.00 Data Object Library Chapter 6 Analog Input Object Definitions Chapter 7 Analog Output Object Definitions Chapter 13 Alternate Numeric Object Definitions

April 22, 1998 2 of 199 9804-006.doc

SHORT FLOATING POINT ANALOG INPUT

Data Object 30 - Variation: 05 Type: Static Description: The Short Floating Point Analog Input information object represents a

hardware or software analog point. The format of this object complies with the IEEE-754 standard for floating-point number representation.

The value field holds the current floating point value of the analog input at

the time of reporting or the last reported value from the originating device, and follows the format for a short real as specified by the IEEE-754 standard.

The flag field holds information about the point and has the same meaning

as previous objects with the following additions: The over-range field indicates that the analog signal is out of range for the

A to D converter to process. The reference check field indicates that the reference signal used to

digitize the analog input is not stable and the resulting digitized value may not be correct.

Object Coding:

Flag

7 0 Value

S Exponent Mantissa 0 7 0 22 0

*S = Sign SQ2 { Flag = BS8 [0..7] Value = R32 { Sign = BS1 [0] <0, positive; 1, negative> Exponent = UI8 [0..7] <0..255> Mantissa = UI23 [0..22] <0..223-1> } }

April 22, 1998 3 of 199 9804-006.doc

Narrative:

The absolute value can be derived from the value field as follows: Absolute_Value = 1.s22 s21 s20 s19 s18 .. s0 x 2 (Exp -127)

where: si = Mantissa[0..22] and Exp = Exponent[0..7] Sign: 0 if number is positive, and 1 if the number is negative. Exponent: Power of 2 applied to (1.Mantissa). Mantissa: Binary digits in value following the binary point.

April 22, 1998 4 of 199 9804-006.doc

LONG FLOATING POINT ANALOG INPUT

Data Object 30 - Variation: 06 Type: Static Description: The Long Floating Point Analog Input information object represents a

hardware or software analog point. The format of this object complies with the IEEE-754 standard for floating-point number representation.


the time of reporting or the last reported value from the originating device, and follows the format for a long real as specified by the IEEE-754 standard.

The flag field has the same meaning as the flag field of Object 30

Variation 5. Object Coding:

Flag

7 0 Value



April 22, 1998 5 of 199 9804-006.doc

Narrative: The absolute value can be derived from the value field as follows: Absolute_Value = 1.s51 s50 s49 s48 s47 .. s0 x 2 (Exp -1023) where: si = Mantissa[0..51] and Exp = Exponent[0..10] Sign: 0 if number is positive, and 1 if the number is negative. Exponent: Power of 2 applied to (1.Mantissa). Mantissa: Binary digits in value following the binary point.

April 22, 1998 6 of 199 9804-006.doc

SHORT FLOATING POINT FROZEN ANALOG INPUT

Data Object 31 - Variation: 07 Type: Frozen Static Description: The Short Floating Point Frozen Analog Input information object

represents a frozen hardware or software analog point. The format of this object complies with the IEEE-754 standard for floating-point number representation.

The frozen value field holds the floating point value of the analog input at

the time of the last Freeze command was completed on this point, and follows the format for a short real as specified by the IEEE-754 standard. This field is as described for the value field of Object 30 Variation 5.



Flag

7 0 Frozen Value



April 22, 1998 7 of 199 9804-006.doc

LONG FLOATING POINT FROZEN ANALOG INPUT

Data Object 31 - Variation: 08 Type: Frozen Static Description: The Long Floating Point Frozen Analog Input information object

represents a frozen hardware or software analog point. The format of this object complies with the IEEE-754 standard for floating-point number representation.


the time of the last Freeze command was completed on this point, and follows the format for a long real as specified by the IEEE-754 standard. This field is as described for the value field of Object 30 Variation 6.



Flag

7 0 Frozen Value



April 22, 1998 8 of 199 9804-006.doc

SHORT FLOATING POINT ANALOG CHANGE EVENT

Data Object 32 - Variation: 05 Type: Event Description: The Short Floating Point Analog Change Event information object

represents a changed hardware or software analog point. The format of this object complies with the IEEE-754 standard for floating-point number representation.


the time of reporting or the last reported value from the originating device, and follows the format for a short real as specified by the IEEE-754 standard. This object is only reported when an event occurs such as a deadband excursion. This field is as described for the value field of Object 30 Variation 5.



Flag

7 0 Value


*S = Sign SQ2 { Flag = BS8 [0..7] Value = R32 { Sign = BS1 [0] <0, positive; 1, negative> Exponent = UI8 [0..7] <0..255> Mantissa = UI23 [0..22] <0..223-1>} }

April 22, 1998 9 of 199 9804-006.doc

LONG FLOATING POINT ANALOG CHANGE EVENT

Data Object 32 - Variation: 06 Type: Event Description: The Long Floating Point Analog Change Event information object



the time of reporting or the last reported value from the originating device, and follows the format for a long real as specified by the IEEE-754 standard. This object is only reported when an event occurs such as a deadband excursion. This field is as described for the value field of Object 30 Variation 6.



Flag

7 0 Value



April 22, 1998 10 of 199 9804-006.doc

SHORT FLOATING POINT ANALOG CHANGE EVENT WITH TIME

Data Object 32 - Variation: 07 Type: Event Description: The Short Floating Point Analog Change Event information object



the time of reporting or the last reported value from the originating device, and follows the format for a short real as specified by the IEEE-754 standard. This object is only reported when an event occurs such as a deadband excursion. This field is as described for the value field of Object 30 Variation 5.

The time field shows the time at which the processing caused the event. The flag field has the same meaning as the flag field of Object 30


Flag

7 0 Value


Time

48 0 *S = Sign SQ3 { Flag = BS8 [0..7] Value = R32 { Sign = BS1 [0] <0, positive; 1, negative> Exponent = UI8 [0..7] <0..255> Mantissa = UI23 [0..22] <0..223-1>} Time = UI48 [0.47] <0.. 248-1>

}

April 22, 1998 11 of 199 9804-006.doc

LONG FLOATING POINT ANALOG CHANGE EVENT WITH TIME

Data Object 32 - Variation: 08 Type: Event Description: The Long Floating Point Analog Change Event information object



the time of reporting or the last reported value from the originating device, and follows the format for a long real as specified by the IEEE-754 standard. This object is only reported when an event occurs such as a deadband excursion. This field is as described for the value field of Object 30 Variation 6.



Flag

7 0 Value


Time


}

April 22, 1998 12 of 199 9804-006.doc

SHORT FLOATING POINT FROZEN ANALOG EVENT

Data Object 33 - Variation: 05 Type: Frozen Event Description: The Short Floating Point Frozen Analog Event information object

represents a frozen hardware or software analog point that is reported as an event. The format of this object complies with the IEEE-754 standard for floating-point number representation.





Flag

7 0 Frozen Value



April 22, 1998 13 of 199 9804-006.doc

LONG FLOATING POINT FROZEN ANALOG EVENT

Data Object 33 - Variation: 06 Type: Frozen Event Description: The Long Floating Point Frozen Analog Event information object






Flag

7 0 Frozen Value



April 22, 1998 14 of 199 9804-006.doc

SHORT FLOATING POINT FROZEN ANALOG EVENT WITH TIME

Data Object 33 - Variation: 07 Type: Frozen Event Description: The Short Floating Point Frozen Analog Event information object






Flag

7 0 Frozen Value


Time

48 0 *S = Sign SQ3 { Flag = BS8 [0..7] Value = R32 { Sign = BS1 [0] <0, positive; 1, negative> Exponent = UI8 [0..7] <0..255> Mantissa = UI23 [0..22] <0..223-1>} Time = UI48 [0.47] <0.. 248-1> }

April 22, 1998 15 of 199 9804-006.doc

LONG FLOATING POINT FROZEN ANALOG EVENT WITH TIME

Data Object 33 - Variation: 08 Type: Frozen Event Description: The Long Floating Point Frozen Analog Event information object






Flag

7 0 Frozen Value


Time


}

April 22, 1998 16 of 199 9804-006.doc

SHORT FLOATING POINT ANALOG OUTPUT STATUS

Data Object 40 - Variation: 03 Type: Static Description: The Short Floating Point Analog Output Status information object

represents the actual value of an analog output or software point and associated status. The format of this object complies with the IEEE-754 standard for floating-point number representation.

The value field holds the current floating point value of the analog output,

and follows the format for a short real as specified by the IEEE-754 standard. This field is as described for the value field of Object 30 Variation 5.


as previous objects. Object Coding:

Flag

7 0 Value



Narrative: This object can be returned after an analog output block operation is performed to determine the success of the operation.

April 22, 1998 17 of 199 9804-006.doc

LONG FLOATING POINT ANALOG OUTPUT STATUS

Data Object 40 - Variation: 04 Type: Static Description: The Long Floating Point Analog Output Status information object

represents the actual value of a hardware or software analog output point. The format of this object complies with the IEEE-754 standard for floating-point number representation.

The value field holds the current floating point value of the analog output,

and follows the format for a long real as specified by the IEEE-754 standard. This field is as described for the value field of Object 30 Variation 6.


as previous objects. Object Coding:

Flag

7 0 Value



Narrative: This object can be returned after an analog output block operation is performed to determine the success of the operation.

April 22, 1998 18 of 199 9804-006.doc

SHORT FLOATING POINT ANALOG OUTPUT BLOCK

Data Object 41 - Variation: 03 Type: Static Description: The Short Floating Point Analog Output Block information object

represents the desired value of a hardware or software analog output point. The format of this object complies with the IEEE-754 standard for floating-point number representation.

The requested value field holds the desired floating point value of the

analog output, and follows the format for a short real as specified by the IEEE-754 standard. The actual value is returned in the analog output status object. This field is as described for the value field of Object 30 Variation 5.

The control status field indicates the status of the analog control operation

in the same way as the control relay output block. The definition of this field is the same as the control relay output block.

Object Coding:

Requested Value S Exponent Mantissa 0 7 0 22 0 Control Status

7 0 *S = Sign SQ2 { Value = R32 { Sign = BS1 [0] <0, positive; 1, negative> Exponent = UI8 [0..7] <0..255> Mantissa = UI23 [0..22] <0..223-1>} Ctrl Stat = BS8 [0..7]

}

April 22, 1998 19 of 199 9804-006.doc

LONG FLOATING POINT ANALOG OUTPUT BLOCK

Data Object 41 - Variation: 04 Type: Static Description: The Long Floating Point Analog Output Block information object

represents the desired value of a hardware or software analog output point. The format of this object complies with the IEEE-754 standard for floating-point number representation.

The requested value field holds the desired floating point value of the

analog output, and follows the format for a long real as specified by the IEEE-754 standard. The actual value is returned in the analog output status object. This field is as described for the value field of Object 30 Variation 6.

The status field indicates the status of the analog control operation in the

same way as the control relay output block. The definition of this field is the same as the control relay output block.

Object Coding:

Requested Value S Exponent Mantissa 0 10 0 51 0 Control Status

7 0 *S = Sign SQ2 { Value = R64 { Sign = BS1 [0] <0, positive; 1, negative> Exponent = UI8 [0..10] <0..2047> Mantissa = UI23 [0..51] <0..252-1>} Ctrl Stat = BS8 [0..7]

}

April 22, 1998 1 of 1 9804-007.doc

DNP V3.00 Technical Bulletin 9804-007 Clarification of Collision Avoidance Procedures

Issue:

The DNP V3.00 Data Link Layer specification, Chapter 7: Physical Procedures, discusses many different issues and configurations of physical connections in a general manner. Unfortunately, it does not clearly describe how to avoid collisions between messages, especially unsolicited messages, sent by several devices sharing a half-duplex, multi-drop link. This bulletin is intended to provide that description.

Resolution:

The physical layer must provide an indication to the data link layer of when the link is in use, e.g. using the DCD (Data Carrier Detect) signal. If a device prepares to transmit and finds the link busy, it waits until it is no longer busy, then waits a backoff_time as follows: backoff_time = fixed_delay + random( max_random_delay ) After the backoff_time, the device tries again, either indefinitely, or up to a configurable maximum number of retries. If a maximum is used, the protocol behaves as if a link failure occurred, i.e. data is returned to buffers at the application layer and application layer retries take place if desired. The fixed_delay can be adjusted per device to provide priority of access. For instance, it could be zero (0) for masters and non-zero for all the slave devices. This provides a minimum "window" of access time for the master(s).


DNP V3.00 Data Link Layer Chapter 7: Physical Procedures

April 22, 1998 1 of 1 9804-008.doc

DNP Technical Bulletin 9804-008 Unissued Object and Variation Numbers

Issue:

It has been noted that some vendors have assigned as-yet-unallocated DNP Object and Variation numbers to private objects. This allocation can lead to incompatible extensions to the protocol. Guidelines regarding this practice are required.

Resolution:

The DNP User Group advises that: • DNP must not be used to transport objects other than those already published by the

DNP User Group in the DNP Protocol Specification documents or in DNP Technical Bulletins.

• Proposals for extensions to the protocol can be presented for consideration by the

User Group’s Technical Committee, and will be included in the protocol if considered appropriate. The Technical Committee may alter any proposed object or variation numbering in accordance with established guidelines, and may also revise other details of the proposal to ensure compatibility with other aspects of the protocol. Proposals should be submitted to the Secretary of the DNP User Group, together with relevant supporting documentation describing the proposed new object or variation and its purpose.

• Note that it is extremely rare for the Technical Committee to introduce new features

to the protocol that are not completely backward-compatible with the existing published protocol definition. From time to time the Technical Committee may issue advisory bulletins that clarify the protocol definition, or make recommendations on aspects of protocol implementation.

• Implementors should note that the Private Registration Object (Object 83) permits the

definition of vendor-specific data objects. This object may be used for adding proprietary features to devices that communicate using DNP.


Nil.

September 10, 1998 1 of 6 9809-001.doc

DNP Technical Bulletin 9809-001 Analog Input Reporting Deadband

Issue:

There is perceived to be a need for a mechanism to permit the master station to retrieve and set the reporting deadband parameter for analog inputs.

Explanatory Notes:

The analog input reporting deadband is normally used in one of two ways depending on the capabilities and configuration of the reporting equipment:

• Fixed Deadband. If the absolute value of the difference between the last-reported value of an analog input object and the current value of that object exceeds the deadband value, then an event is generated for that object with the current value sent as the value for the event.

• Integrating Deadband. While the value of an analog input object differs from the last-reported value for that object, the difference is integrated over time. When the integral of the difference exceeds the deadband, then an event is generated for that object with the current value sent as the value for the event.

It is assumed that only one of these two mechanisms is being used. This means that a single deadband value is assigned for each analog input point, not two separate values (a fixed deadband value and an integrating deadband value) assigned for each point.

Resolution:

The DNP Technical Committee has allocated Object 34 as the means of reporting or setting the reporting deadband value of an Analog Input. This object will support the Read and Write functions. It will not be reported in response to Read requests for Class 0 Data (that is: It will only be returned in response to a Read command that specifically requests Object 34). The master may alter the value of an analog input’s deadband by issuing a Write command containing the Analog Input Reporting Deadband Object.

Object 34 has no flags. The indices assigned to Object 34 parallel those assigned to Object 30. This means that the reporting deadband for Object 30 Index n is Object 34 Index n, events on this point are reported as Object 32 index n.

Three variations of Object 34 are defined: 16-bit and 32-bit integer formats and a floating-point format. Systems that only report analog events using integer formats (Object 32 Variations 1–4) should use the integer variations of Object 34 (Variations 1 and 2). Systems that can report analog events using floating-point formats (Object 32 Variation 5–8) may use either the floating-point variation of Object 34 (Variation 3) or the integer variations (Variations 1 and 2), and must perform conversion between integer and floating-point formats as required by DNP Technical Bulletin 9804-006. It is recommended that for each individual point, the same format (integer or floating-point as required) be used with Objects 30, 32 and 34.

Object 34 may be used for setting or reporting either a Fixed Deadband value or an Integrating Deadband value. For a fixed deadband, the value set will be the absolute

September 10, 1998 2 of 6 9809-001.doc

difference value in Counts (Variations 1 and 2) or floating-point Engineering Units (Variation 3). For an Integrating Deadband, the value set will be the difference value in Count Seconds (Variations 1 and 2) or Engineering Unit Seconds (Variation 3) (i.e.: The integral over time of the difference between the last reported value and the current value).

Object 34 Variation 1 uses a 16-bit unsigned integer data representation. Deadbands are positive values, the range of deadbands that can be represented is 0–65535 (0x0–0xFFFF).

Object 34 Variation 2 uses a 32-bit unsigned integer data representation. Deadbands are positive values, the range of deadbands that can be represented is 0–4294967295 (0x0–0xFFFFFFFF).

Object 34 Variation 3 uses the short real (32-bit) floating-point format specified in the IEEE 754 standard. While this format permits negative values, deadbands should only be set to positive values (0.0–+INF).

Implementation notes:

A deadband of zero will permit any change to generate an event and a deadband of the full range of the variable will prevent events from ever being generated. Hence selecting a deadband of 4294967295 prevents event generation from any integer analog input, and selecting a value of +INF (positive infinity) prevents event generation from any floating-point analog input object.

Any negative floating-point deadband value is equivalent to a zero deadband, as any change in the input will be larger than the deadband. A device receiving a negative floating-point deadband value should convert (or report) this to be a zero deadband value.

In systems that use fixed deadbands, setting the deadband value to the maximum range of the analog input will inhibit event generation for that input. For example: An 8-bit analog input may have a range of -128–127, setting the reporting deadband for this point to 255 (or more) will prevent all event reporting for that point.

If a Read request for Object 34 Variation 1 is issued, any point deadband value greater than 65535 will be reported in the response as the value 65535 (the largest value that can be reported in a 16-bit unsigned integer). A Read request for Object 34 Variation 2 should be issued if integer deadband values greater than 65535 must be reported correctly.

The response to a Read request for Object 34 Variation 0 may include any variation of Object 34, in accordance with the slave device’s capabilities and configuration. Note that if the device is capable of reporting Object 34 Variation 3 (floating-point), then the device must be configurable to only report data using Variations 1 and 2, in accordance with the requirements stated in DNP Technical Bulletin 9804-006.

A slave device that supports Object 34 is not required to maintain deadband values through reset (when it sets IIN Bit 7), and may revert to configured (or default) deadband values on reset. If the slave device preserves updated deadband values through reset, then this should be noted in the device profile.

Any deadband values altered by the use of Object 34 prior to the slave reset may be lost. The DNP Master is responsible for re-sending any updated deadband values to the slave after a slave reset if this is deemed necessary.

September 10, 1998 3 of 6 9809-001.doc


DNP V3.00 Object Library Chapter 6: Analog Input Object Definitions

Updated Device Profile Document

Details: 16-Bit Analog Input Reporting Deadband Object Data Object 34 Variation 1 Type: Static, Not in Class 0 Description: The Analog Deadband Object is an information object used to allow a DNP

device to report the magnitude of the deadband of an Analog Input Object, or to permit the master station to alter the deadband of an Analog Input Object. This object may be specified with the Read command (master requests slave to return the deadband value), Write command (master alters the deadband value) or Response command (when the slave supplies the data in response to the master’s Read command).

The deadband value field contains the value of the deadband. This object is NOT returned in response to a Read request of Class 0 data. The index number identifying a deadband object is the index number of the

corresponding Analog Input Object (Object 30). Object Coding:

Deadband Value 15 0

SQ1 { Deadband Value = UI16 [0..15] <0..65535> }

NOTES: • This object is valid with the Application Layer function codes Read, Write

and Response. The object will only be included in a Response message if specifically requested in a Read message.

• For analog inputs having fixed deadbands, the Deadband Value is the

deadband count value. For analog inputs using integrating deadbands, the Deadband Value is the integrated deadband in count-seconds.

• The response to a Read request using Variation 1 will report the value 65535

for any deadband value that is greater than 65535.

September 10, 1998 4 of 6 9809-001.doc

32-Bit Analog Input Reporting Deadband Object Data Object 34 Variation 2 Type: Static, Not in Class 0 Description: The Analog Deadband Object is an information object used to allow a DNP


The deadband value field contains the value of the deadband. This object is NOT returned in response to a Read request of Class 0 data. The index number identifying a deadband object is the index number of the


Deadband Value 31 0

SQ1 { Deadband Value = UI32 [0..31] <0..4294967295 > }




deadband count value. For analog inputs using integrating deadbands, the Deadband Value is the integrated deadband in count-seconds.

September 10, 1998 5 of 6 9809-001.doc

Floating Point Analog Input Reporting Deadband Object Data Object 34 Variation 3 Type: Static, Not in Class 0 Description: The Analog Deadband Object is an information object used to allow a DNP


The deadband value field contains the value of the deadband in the 32-bit short

real format specified in the IEEE 754 Standard. This is as described for the value field of Object 30 Variation 5 (Refer to DNP Technical Bulletin 9804-006).

This object is NOT returned in response to a Read request of Class 0 data. The index number identifying a deadband object is the index number of the


Deadband Value


*S = Sign, should only be zero (positive value) SQ1 { Value = R32 { Sign = BS1 [0] <0, positive; 1, negative> Exponent = UI8 [0..7] <0..255> Mantissa = UI23 [0..22] <0..223-1> } }




deadband engineering unit value. For analog inputs using integrating deadbands, the Deadband Value is the integrated deadband in engineering unit-seconds.

• If a negative value is received (Sign bit set), this should be interpreted as a

zero value.

September 10, 1998 6 of 6 9809-001.doc

• The +INF (positive infinity) value is represented by a Sign bit of zero, an

Exponent of 255 and a Mantissa of 0 (i.e.: the deadband value of 0x7F800000).

January 15, 1996 1 of 1 9701-001.doc

DNP Technical Bulletin 9701-001 Data Link Restart Recovery

Issue: The data link had a problem when one station or the other is powered down and up

without the other stations knowledge. The first poll to a remote device failed because the remote has not yet received a LINK RESET frame. Without application retries, communications may not be recovered for the polling interval, perhaps hours or days.

Resolution: Following a restart or power-up, prior to receiving a Reset Link frame both Master and

Slave devices must respond with a data link layer CONFIRM NACK having DFC=0 when they receive a frame having FCV=1 (SEND/CONFIRM), rather than just discarding the frame. A power up failure will now be detected quickly by not having to wait for retries to be completed.

Upon receipt of the NACK , the Data Link layer will make the indication to the

application layer to determine the course of action. It is further recommended that upon receiving an indication of a transaction failure due to

a NACK: • A Master Device performs an immediate application layer retry, if appropriate. • A Slave device always perform an immediate application layer retry.

This will prevent the first transaction after power up from failing. Affected Documents: DNP 3.0 Data Link Layer Protocol Description Chapter 3 DNP Data Link Description Data Link Function Codes Reset

January 15, 1996 1 of 2 9701-002.doc

DNP Technical Bulletin 9701-002 Control Relay Output Block Minimum Implementation

Issue:

The DNP User’s Group required the Subset Definition be amended to include a list of minimum subset options in the Control Relay Output Block.

Resolution:

The following is a minimum implementation, given that appropriate hardware exists. If a particular function is not supported by the hardware, the Slave device must return value 4 (operation not supported) in the Status field.

FIELD: MINIMUM IMPLEMENTATION: Trip/Close See following table. Invalid with Code values of Latch On or Latch Off. Clear Set to 0. Only used for continuously repeating commands. Queue Set to 0. Only used for continuously repeating commands. Code See following table. Must be Pulse On if Trip/Close is not NULL. Count Set to 1. Only used if the command is to be performed multiple times. On-Time Set to 0 unless Code value is Pulse On. See following table. Off-Time Set to 0. Only used for Pulse Off values of Code or Count greater than 1. Status Set to 0 in the output request.

Function Desired

Trip/Close

Code

On-Time

Latching Relay ON

NULL (0)

Latch On (3)

Zero (ignored)

Latching Relay OFF

NULL (0)

Latch Off (4)

Zero (ignored)

Unpaired Momentary Relay (e.g Pushbutton, Alarm)

NULL (0)

Pulse On (1)

Non-zero

Trip Breaker/Relay or Raise Transformer Tap

Trip (2)

Pulse On (1)

Non-zero

Close Breaker/Relay or Lower Transformer Tap

Close (1)

Pulse On (1)

Non-zero

Addressing Issues There are two possible ways to provide access to Trip/Close or Raise/Lower relays: 2 Points Per Address - Both operations are performed specifying the same DNP point number. The value of the Trip/Close field selects the appropriate one of a pair of relays.

1 Point Per Address - The Trip or Raise operation is performed on a different DNP point number than the Close or Lower operation. The remote device may return a Status of 4 (operation not supported) if an inappropriate operation is performed.

The “2 Points Per Address” method is not recommended for new designs.

January 15, 1996 2 of 2 9701-002.doc

DNP Technical Bulletin 9701-002 Control Relay Output Block Minimum Implementation

(Continued)

The next version of the DNP V3.00 Data Object Library shall be updated to redefine the Trip/Close field as:

Paired Operation = BS2[ 6..7] <00, NULL; 01, Close|Lower; 10, Trip| Raise>

On-Time It is recommended that if a device’s hardware only supports one pulse width (specified by On-Time), it does not reject other values but simply ignores the specified width. This will help with interoperability. Documentation The addressing method for Trip/Close or Raise/Lower operations and any features supported in addition to the minimum specified above must be described in the Device Profile Document. In particular, the method used for variable Raise/Lower operations (variable On-Time, or variable Count, or neither) must be documented. Any features not supported because of lack of hardware must also be documented.


DNP 3.0 Data Object Library Chapter 4 Binary Output Object Definitions DNP 3.0 Subset Definitions Chapter 4 Implementation Rules and Recommendations Operating Binary Outputs Updated Device Profile Document

January 15, 1996 1 of 1 9701-003.doc

DNP Technical Bulletin 9701-003 Cold/Warm Restart Sequence

Issue: The DNP User’s Group required a definition for a standard implementation for

Cold/Warm Restart implementation sequence. It was previously unclear when a remote should actually perform a restart after receiving a restart request: • immediately after transmitting the response • after receiving a data link confirm to the response • after receiving an application confirm

Resolution: It is recommended that neither data link layer nor application layer confirmation be

requested when sending a response to a Cold Restart or Warm Restart request. This implies that restart should begin immediately after sending the response. Devices

that cannot be sure exactly when the response will be completely sent can wait a suitably large time and “pad” that time into the master wait time returned in the response.

Affected Documentation: DNP V3.00 Application Layer Protocol Description Chapter 4 Detailed Function Code Descriptions Cold Restart (Function Code 13) Warm Restart (Function Code 14)

August 21, 1996 1 of 3 9701-004.doc

DNP Technical Bulletin 9701-004 Octet (Character) Strings Objects 110 and 111

Issue: The DNP User’s Group required a definition for a standard object for Octet (Character)

strings. The need arose to transport ASCII or other data of varying lengths. Initial uses considered were for Passwords or other character strings, but other uses have arisen as well.

Resolution: A new object, Object 110, is defined as an Octet String Object. The variation within the

object represents the length for the Octet string. Devices are not required to support any particular length of string. The event object associated for the Octet String Object is Object 111.

NOTE: Reading and Writing of 8 bit memory locations could be implemented using this object

together with absolute addressing qualifiers. Please refer to the following Data Link Object Definitions for Details. Affected Documentation: DNP V3.00 Object Library Chapter to be determined

August 21, 1996 2 of 3 9701-004.doc

Octet String Object Data Object 110 - Variation = Octet string length Type: Static Description: The Octet String Object represents a value from 0 to 255. Each 8 bit data element may

contain a variety of information from ASCII passwords to configuration details. This object is not included in Class 0 poll response. The variation within the object represents the length. For this object only read, write and response function codes are permitted.

Object Coding:


Current Value [N-1] 7 0

OSN = SQ1 { Current Value = UI [0..7] <0..255>} where N = variation which is the length of the octet string

August 21, 1996 3 of 3 9701-004.doc

Octet String Event Object Data Object 111 - Variation = Octet string Length Type: Event Description: The Octet String Event Object represents an event value from 0 to 255. Each 8 bit data

element may contain a variety of information from ASCII passwords to configuration details. The variation within the object represents the length. For this object only read, response and unsolicited response function codes are permitted.

Object Coding:


Current Value [N-1] 7 0

OSN = SQ1 { Current Value = UI [0..7] <0..255>} where N = variation which is the length of the octet string

August 21, 1996 1 of 1 9701-006.doc

DNP 3.0 Technical Bulletin 9701-006 Extended Engineering Units for Floating Point Objects

Issue: The DNP User’s Group required new engineering unit definitions for Floating Point

Objects. Resolution: The following “Units” codes have been added to all floating point objects defined within

DNP: 20 quantity having no unit of measurement 21 m3 /s (volumetric flow in cubic meters per second) 22 kPa (pressure in kilopascals) 255 units unknown or undefined 23 to 254 remain available for future assignment

Affected Documentation: DNP V3.00 Data Object Library Chapter 6 Analog Input Object Definitions Analog Input Data Object 30 Variations 5 to 7 Frozen Analog Input Data Object 31 Variations 7 to 9 Analog Change Event Data Object 32 Variations 5 to 7 Frozen Analog Event Data Object 33 Variations 5 to 7 Chapter 7 Analog Output Object Definitions Analog Output Status Data Object 40 Variations 3 to 5 Analog Output Block Data Object 41 Variations 3 to 5 Chapter 13 Alternate Numeric Object Definitions Floating Point Data Object 100 Variations 1 to 3 (object 100 is no longer recommended)

April 16, 1997 1 of 1 9704-007.doc

DNP 3.0 Technical Bulletin 9704-007 Implementation Rules for Reset Link Frames

Issue: The implementation of Reset Link Frames has recently caused some controversy with

different vendors providing differing subsets. To avoid possible incompatibilities, the following resolutions were adopted.

Resolution:

• A device is not required to transmit a RESET LINK frame if that device transmits only SEND/NO REPLY EXPECTED frames.

• A device must not require the reception of a RESET LINK frame before accepting SEND/NO REPLY EXPECTED frames.

• Any device receiving a RESET LINK frame must respond with a CONFIRM - ACK. Any other response or no response at all indicates that the receiver is unable to perform the link reset.


DNP V3.00 Data Link Layer Chapter 3: DNP Data Link Description Data Link Function Codes

Distributed Network Protocol (DNP3-2001)

DNP3-2001 Intelligent Electronic Device (IED)

Certification Procedure Subset Level 1

Version 2.1

5-July-01

Disclaimer Statement

DNP User Group documents and publications are not consensus documents. Information contained in this and other works has been obtained from sources believed to be reliable, and reviewed by credible members of the DNP User Group and/or the DNP User Group Technical Committee. Neither the DNP Users Group nor any authors/developers of DNP documentation guarantee, and each such person expressly disclaims responsibility for ensuring, the accuracy or completeness of any information published herein, and neither the DNP Users Group nor its authors/developers shall be responsible for any errors, omissions, or damages arising out of use of this document. Likewise, while the author/developer and publisher believe that the information and guidance given in this work serves as an enhancement to users, all parties must rely upon their own skill and judgment when making use of it. Neither the author nor the publisher assumes any liability to anyone for any loss or damage caused by any error or omission in the work, whether such error or omission is the result of negligence or any other cause. Any and all such liability is disclaimed. This statement was developed by the DNP User Group Technical Committee and represents the considered judgment of a group of software developers with expertise in the subject field. The DNP User Group is a global forum for users and implementers of the protocol and promotes implementers and developer information and interaction exchange. This work is published with the understanding that the DNP User Group and its authors/developers are supplying information through this publication, not attempting to render engineering or other professional services. If such services are required, the assistance of an appropriate professional should be sought. The DNP User Group is not responsible for any statements and/or opinions advanced in this publication.





Revision History Date Version Sections affected Reason for change 18-Jan-99 1.00 ALL Initial Release 15-Dec-99 1.01 see errata sheet for 1.00 Fixes inconsistencies and errors

Designates protocol as DNP3-1999 (formerly DNP V3.00 with extensions)

10-July-00 2.00 8.11.1.1 8.11.2.5.9 8.6.5.1 8.6.5.4 8.2.1.1 8.2.1.2.11 - 15 8.4.1.1 8.4.1.2.8 - 12 6 6.6.2.5

Added required parameter - maximum number of unsolicited retries Added test procedure from TB9912-002 Added desired response to addresses 0xFFFE and 0xFFFD Added test procedure from TB9912-003 Added requirements for Control SBO retries Added test procedures from TB2000-002 Added requirements for Analog Output SBO retries Added test procedures from TB2000-002 Removed reference to function code 1 Removed function code 0xD1 from table

5-July-01 2.1 8.2.1.2.10, step 1 8.4.1.2.7, step 1 8.6.5.4 8.2.5 8.2.1.1, 8.2.1.2.3, 8.2.2.1, 8.2.2.2.2, 8.4.1.1, 8.4.1.2.3, 8.4.2.1, 8.4.2.2.2 8.2.4.1 - 8.2.4.2, 8.4.4.1 - 8.4.4.2 Section 9, Appendices A and B

Replace "end testing of Binary Output, SBO" with "skip this section" Replace "end testing of Analog Output, SBO" with "skip this section" Added step 2 - "Issue a link reset using link control block 0xC0" Added test procedure from TB2000-006 Added status code in error response as required in TB2001-01 Added test procedures from TB2001-001 Removed; the information required for these sections is not available and may not be for some time.

DNP3-2001 IED Certification Procedure Page i Subset Level 1 Rev 2.1 – 5-July-01

Contents

1 Overview..............................................................................................................................................................................1 1.1 Protocol specification ..................................................................................................................................................1

2 Notes....................................................................................................................................................................................1 3 Definitions ...........................................................................................................................................................................3

3.1 General.........................................................................................................................................................................3 3.2 Internal Indications ......................................................................................................................................................3 3.3 Error Responses ...........................................................................................................................................................3 3.4 Changes or Events .......................................................................................................................................................4

3.4.1 § Rules .................................................................................................................................................................4 4 Reference Documents ..........................................................................................................................................................5 5 Pretest Review .....................................................................................................................................................................5

5.1 Device Profile Review .................................................................................................................................................5 5.2 Equipment Review.......................................................................................................................................................5

6 Link Layer ...........................................................................................................................................................................6 6.1 Reset Link and Passive Confirm support .....................................................................................................................6

6.1.1 Desired Behavior .................................................................................................................................................6 6.1.2 Test Procedure .....................................................................................................................................................6

6.2 Test Link......................................................................................................................................................................7 6.2.1 Desired Behavior .................................................................................................................................................7 6.2.2 Test Procedure .....................................................................................................................................................7

6.3 Request Link Status .....................................................................................................................................................7 6.3.1 Desired Behavior .................................................................................................................................................7 6.3.2 Test Procedure .....................................................................................................................................................7

6.4 Test Retries ..................................................................................................................................................................8 6.4.1 Desired Behavior .................................................................................................................................................8 6.4.2 Test Procedure .....................................................................................................................................................8

6.5 § DIR and FCV Bits.....................................................................................................................................................8 6.5.1 Desired Behavior .................................................................................................................................................8 6.5.2 Test Procedure .....................................................................................................................................................8

6.6 Data Link Rejects Invalid Frames................................................................................................................................9 6.6.1 Desired Behavior .................................................................................................................................................9 6.6.2 Test Procedure – Primary Frames ........................................................................................................................9

6.6.2.1 Invalid Start Octets ........................................................................................................................................10 6.6.2.2 Invalid Primary Function Code......................................................................................................................10 6.6.2.3 Invalid Destination Address...........................................................................................................................10 6.6.2.4 Invalid CRC ...................................................................................................................................................10 6.6.2.5 § Invalid FCV ................................................................................................................................................11

6.6.3 Test Procedure – Secondary Frames ..................................................................................................................11 6.6.3.1 Invalid Start Octets ........................................................................................................................................11 6.6.3.2 Invalid Secondary Function Code..................................................................................................................12 6.6.3.3 Invalid Destination Address...........................................................................................................................12 6.6.3.4 Invalid CRC ...................................................................................................................................................12

7 Transport Layer .................................................................................................................................................................13 7.1 Desired Behavior .......................................................................................................................................................13 7.2 Test Procedure ...........................................................................................................................................................13

8 Application Layer ..............................................................................................................................................................14 8.1 Binary Output Status..................................................................................................................................................14

8.1.1 Desired Behavior ...............................................................................................................................................14 8.1.2 Test Procedure ...................................................................................................................................................14

8.2 Binary Outputs...........................................................................................................................................................14 8.2.1 Select Before Operate ........................................................................................................................................15

8.2.1.1 Desired Behavior ...........................................................................................................................................15

DNP3-2001 IED Certification Procedure Page ii Subset Level 1 Rev 2.1 – 5-July-01

8.2.1.2 Test Procedure ...............................................................................................................................................16 8.2.1.2.1 Binary Output, SBO, 0x28.......................................................................................................................16 8.2.1.2.2 Binary Output, SBO, 0x17.......................................................................................................................16 8.2.1.2.3 Binary Output, SBO, To Uninstalled Point..............................................................................................16 8.2.1.2.4 Binary Output, SBO, Execute Issued After Timeout ...............................................................................16 8.2.1.2.5 Binary Output, SBO, Execute to Different Point Than Select .................................................................16 8.2.1.2.6 Binary Output, SBO, Execute On Time does not match Select On Time................................................16 8.2.1.2.7 Binary Output, SBO, Execute Off Time does not match Select Off Time...............................................17 8.2.1.2.8 Binary Output, SBO, Select using a supported Control Code, Execute using a different Control Code .17 8.2.1.2.9 Binary Output, SBO, Select 0x28, Execute 0x17 ....................................................................................17 8.2.1.2.10 Binary Output, SBO, Configurable Device............................................................................................17 8.2.1.2.11 Binary Output, SBO, Same Sequence Number Select Retries...............................................................17 8.2.1.2.12 Binary Output, SBO, Incrementing Sequence Number Select Retries ..................................................17 8.2.1.2.13 Binary Output, SBO, Same Sequence Number Operate Retries ............................................................18 8.2.1.2.14 Binary Output, SBO, Incrementing Sequence Number Operate Retries................................................18 8.2.1.2.15 Binary Output, SBO, Sequence number checking .................................................................................18

8.2.2 Direct Operate with Acknowledge.....................................................................................................................18 8.2.2.1 Desired Behavior ...........................................................................................................................................18 8.2.2.2 Test Procedure ...............................................................................................................................................19

8.2.2.2.1 Binary Output, Direct Operate .................................................................................................................19 8.2.2.2.2 Binary Output, Direct Operate to Uninstalled Point ................................................................................19 8.2.2.2.3 Binary Output, Direct Operate, Configurable Device..............................................................................19

8.2.3 Direct Operate, No Acknowledge......................................................................................................................19 8.2.3.1 Desired Behavior ...........................................................................................................................................19 8.2.3.2 Test Procedure ...............................................................................................................................................19

8.2.3.2.1 Binary Output, Direct Operate, No Acknowledge ...................................................................................19 8.2.3.2.2 Binary Output, Direct Operate, No Acknowledge, to an Uninstalled Point.............................................20 8.2.3.2.3 Binary Output, Direct Operate, No Acknowledge, Configurable Device ................................................20

8.2.4 Multiple Object Requests...................................................................................................................................20 8.2.4.1 Desired Behavior ...........................................................................................................................................20 8.2.4.2 Test Procedure ...............................................................................................................................................20

8.2.5 Control Code Support ........................................................................................................................................21 8.2.5.1 Desired Behavior ...........................................................................................................................................21 8.2.5.2 Test Procedure ...............................................................................................................................................21

8.2.5.2.1 Binary Output, Complementary Function Support ..................................................................................21 8.2.5.2.2 Binary Output, Single Function Support..................................................................................................22

8.3 Analog Output Status.................................................................................................................................................22 8.3.1 Desired Behavior ...............................................................................................................................................23 8.3.2 Test Procedure ...................................................................................................................................................23

8.4 Analog Outputs ..........................................................................................................................................................23 8.4.1 Select Before Operate ........................................................................................................................................23

8.4.1.1 Desired Behavior ...........................................................................................................................................24 8.4.1.2 Test Procedure ...............................................................................................................................................24

8.4.1.2.1 Analog Output, SBO, 0x28......................................................................................................................24 8.4.1.2.2 Analog Output, SBO, 0x17......................................................................................................................25 8.4.1.2.3 Analog Output, SBO, to Uninstalled Point ..............................................................................................25 8.4.1.2.4 Analog Output, SBO, Execute Issued After Time-out.............................................................................25 8.4.1.2.5 Analog Output, SBO, Execute Value does not match Select Value ........................................................25 8.4.1.2.6 Analog Output, SBO, Select 0x28, Execute 0x17....................................................................................25 8.4.1.2.7 Analog Output, SBO, Configurable Device.............................................................................................25 8.4.1.2.8 Analog Output, SBO, Same Sequence Number Select Retries ................................................................26 8.4.1.2.9 Analog Output, SBO, Incrementing Sequence Number Select Retries....................................................26 8.4.1.2.10 Analog Output, SBO, Same Sequence Number Operate Retries ...........................................................26 8.4.1.2.11 Analog Output, SBO, Incrementing Sequence Number Operate Retries...............................................26 8.4.1.2.12 Analog Output, SBO, Sequence number checking ................................................................................26

DNP3-2001 IED Certification Procedure Page iii Subset Level 1 Rev 2.1 – 5-July-01

8.4.2 Direct Operate with Acknowledge.....................................................................................................................27 8.4.2.1 Desired Behavior ...........................................................................................................................................27 8.4.2.2 Test Procedure ...............................................................................................................................................27

8.4.2.2.1 Analog Output, Direct Operate ................................................................................................................27 8.4.2.2.2 Analog Output, Direct Operate, to Uninstalled Point ..............................................................................27 8.4.2.2.3 Analog Output, Direct Operate, Configurable Device .............................................................................27

8.4.3 Direct Operate, No Acknowledge......................................................................................................................28 8.4.3.1 Desired Behavior ...........................................................................................................................................28 8.4.3.2 Test Procedure ...............................................................................................................................................28

8.4.3.2.1 Analog Output, Direct Operate, No Acknowledge ..................................................................................28 8.4.3.2.2 Analog Output, Direct Operate, No Acknowledge, to an Uninstalled Point............................................28 8.4.3.2.3 Analog Output, Direct Operate, No Acknowledge, Configurable Device ...............................................28

8.4.4 Multiple Object Requests...................................................................................................................................28 8.4.4.1 Desired Behavior ...........................................................................................................................................28 8.4.4.2 Test Procedure ...............................................................................................................................................28

8.5 Class Data ..................................................................................................................................................................29 8.5.1 Class 0................................................................................................................................................................29


8.5.2 Class 1................................................................................................................................................................30 8.5.2.1 Desired Behavior ...........................................................................................................................................31 8.5.2.2 Test Procedure ...............................................................................................................................................31

8.5.2.2.1 Class 1 Data, 0x06 ...................................................................................................................................31 8.5.2.2.2 Class 1 Data, 0x07 ...................................................................................................................................32 8.5.2.2.3 Class 1 Data, 0x08 ...................................................................................................................................32 8.5.2.2.4 § Class 1 Data Without Confirm..............................................................................................................32





8.5.5 Multiple Object Request ....................................................................................................................................37 8.5.5.1 Desired Behavior ...........................................................................................................................................37 8.5.5.2 Test Procedure ...............................................................................................................................................37

8.5.5.2.1 Multiple Object Request, Class 1, 2, and 3 ..............................................................................................37 8.5.5.2.2 Multiple Object Request, Class 1, 2, 3, and 0 ..........................................................................................37

8.5.6 Class Assignment Verification...........................................................................................................................38 8.5.6.1 Desired Behavior ...........................................................................................................................................38 8.5.6.2 Test Procedure ...............................................................................................................................................38

8.6 Indications..................................................................................................................................................................38 8.6.1 Restart ................................................................................................................................................................38


8.6.2 Bad Function......................................................................................................................................................39 8.6.2.1 Desired Behavior ...........................................................................................................................................39 8.6.2.2 Test Procedure ...............................................................................................................................................39

DNP3-2001 IED Certification Procedure Page iv Subset Level 1 Rev 2.1 – 5-July-01

8.6.3 Object Unknown ................................................................................................................................................39 8.6.3.1 Desired Behavior ...........................................................................................................................................39 8.6.3.2 Test Procedure ...............................................................................................................................................39

8.6.4 Local ..................................................................................................................................................................39 8.6.4.1 Desired Behavior ...........................................................................................................................................39 8.6.4.2 Test Procedure for Devices with Global Remote Supervisory Control..........................................................39 8.6.4.3 Test Procedure for Devices with Individual Remote Supervisory Control ....................................................39

8.6.5 Broadcast Address and All Stations Indication..................................................................................................40 8.6.5.1 Desired Behavior ...........................................................................................................................................40 8.6.5.2 § Test Procedure ............................................................................................................................................40 8.6.5.3 Test Procedure ...............................................................................................................................................40 8.6.5.4 § Test Procedure, Confirmed Response Options ...........................................................................................41

8.6.6 Buffer Overflow.................................................................................................................................................41 8.6.6.1 Desired Behavior ...........................................................................................................................................41 8.6.6.2 Test Procedure ...............................................................................................................................................41

8.6.6.2.1 Buffer Overflow, Binary Input Change Event Buffers ............................................................................41 8.6.6.2.2 Buffer Overflow, Analog Input Change Event Buffers ...........................................................................41 8.6.6.2.3 Buffer Overflow, Binary Counter Change Event Buffers........................................................................42

8.7 Time...........................................................................................................................................................................42 8.7.1 Delay Measurement ...........................................................................................................................................42


8.7.2 Synchronization .................................................................................................................................................43 8.7.2.1 Desired Behavior ...........................................................................................................................................43 8.7.2.2 Test Procedure ...............................................................................................................................................43

8.8 Cold Restart ...............................................................................................................................................................43 8.8.1 Desired Behavior ...............................................................................................................................................43 8.8.2 Test Procedure ...................................................................................................................................................43

8.9 Application Layer Fragmentation ..............................................................................................................................43 8.9.1 Use of FIR, FIN and SEQUENCE in Fragmentation.........................................................................................43


8.9.2 § Use of Confirmation in Fragmentation ...........................................................................................................44 8.9.2.1 § Desired Behavior ........................................................................................................................................44 8.9.2.2 § Test Procedure ............................................................................................................................................44

8.10 Multi-Drop Support ...................................................................................................................................................45 8.10.1 Desired Behavior ...............................................................................................................................................45 8.10.2 Test Procedure ...................................................................................................................................................45

8.11 Unsolicited Responses ...............................................................................................................................................45 8.11.1 Desired Behavior ...............................................................................................................................................46

8.11.1.1 Configuration .................................................................................................................................................46 8.11.1.2 Sequence Numbers and Confirmation ...........................................................................................................46 8.11.1.3 Restart Behavior.............................................................................................................................................46 8.11.1.4 Runtime Behavior ..........................................................................................................................................46 8.11.1.5 Unsolicited and Polled Responses .................................................................................................................47

8.11.2 Test Procedure ...................................................................................................................................................47 8.11.2.1 Unsolicited Response Configuration/Startup .................................................................................................47 8.11.2.2 Unsolicited Response - Class 1 Data .............................................................................................................48 8.11.2.3 Unsolicited Response - Class 2 Data .............................................................................................................49 8.11.2.4 Unsolicited Response - Class 3 Data .............................................................................................................49 8.11.2.5 Unsolicited and Polled Responses .................................................................................................................50

8.11.2.5.1 Transmits data-filled unsolicited responses ...........................................................................................50 8.11.2.5.2 Clears transmitted data upon confirmation ............................................................................................50 8.11.2.5.3 Processes non-READ requests immediately ..........................................................................................50 8.11.2.5.4 Defers READ requests until after confirmation received ......................................................................50

DNP3-2001 IED Certification Procedure Page v Subset Level 1 Rev 2.1 – 5-July-01

8.11.2.5.5 Defers READ requests until after confirmation timeout........................................................................51 8.11.2.5.6 Abandons READ requests upon subsequent non-READ requests.........................................................51 8.11.2.5.7 Abandons READ requests upon subsequent READ requests ................................................................51 8.11.2.5.8 Inhibits Unsolicited responses until after polled confirmation...............................................................51 8.11.2.5.9 Retries unsolicited responses configurable number of times .................................................................52

8.11.2.6 Unsolicited Responses Off.............................................................................................................................52 8.12 § Collision Avoidance ...............................................................................................................................................53

8.12.1 Desired Behavior ...............................................................................................................................................54 8.12.2 Test Procedure ...................................................................................................................................................54

9 Appendix A – DNP3 Reference Sheet...............................................................................................................................55

DNP3-2001 IED Certification Procedure Page vi Subset Level 1 Rev 2.1 – 5-July-01

1 Overview It is the purpose of this document to describe a set of tests that will determine an Intelligent Electronic Devices’ (IED) compliance with the Distributed Network Protocol (formly known as DNP V3.00). This certification procedure is designed specifically to determine an IED’s compliance to level 1 of the Subset Definitions. A device must pass all of the tests to be considered compliant to this procedure.

1.1 Protocol specification The protocol is defined by the Basic 4 Document set (Link Layer, Transport Layer, Application Layer, and Subset Definitions), Technical Notes published by the Technical Committee, and this Certification Procedure. The protocol defined by these documents shall be denoted DNP3-2001. Sections in this document marked with the symbol "§" constitute new requirements or clarifications beyond the Basic 4 Document set. These sections may create interoperability problems with implementations done prior to the publication of this test procedure. However, the DNP Users' Group approved these changes at the annual 1999 meeting based on strong recommendation from the Technical Committee. These requirements and clarifications will greatly improve interoperability and extensive efforts have been made to minimize the impact on existing implementations.

2 Notes 1. This procedure is an attempt to produce interoperability between Master and IED devices, although such interoperability

can NOT be guaranteed. However, it does gives reasonable assurance that Masters which can be configured to match items in the IED Device Profile Document will interoperate.

2. Wherever the following procedures generate a specific number of events, it is acceptable to use an alternate number

supported by the device provided that the intent of the test is still satisfied. 3. This is not a factory acceptance test, but a protocol test. Therefore only selected outputs will be tested to verify protocol

operation. 4. Unless otherwise specified, all Application Layer retries are disabled. 5. If not explicitly stated all tests imply verification that all points in a normal operating state are reported with all flag bits

except the ONLINE bit clear and the ONLINE bit is set. Alternatively, verification that the object is reported with the “without flags” variation is also implied.

6. Sections marked with three asterisks (***) extend the requirements of the device beyond DNP3-2000. 7. Record the point numbers used in all tests in the log. 8. All application layer tests use unconfirmed link services using a request link control block of 0xC4 unless specified

otherwise. 9. When time tagged events are reported the certification procedures do not measure the absolute accuracy of the reported

times. They do however verify that the reported times are updated in a reasonable manner. The Device Profile Document specifies the accuracy with which the device measures the event. This accuracy is guaranteed by the vendor, not the certification procedures.

10. If not explicitly stated all tests imply verification that a response to a request has the same application sequence number

as the request. If the request generates multiple application fragments also verify that the application sequence number of each subsequent fragment increments by 1 modulo 16.

11. These tests assume that the device will only generate events as controlled by the tester, as specified in the procedure. DNP3-2001 IED Certification Procedure Page 1 Subset Level 1 Rev 2.1 – 5-July-01

12. It is strongly recommended that the tester run the device for a least 24 hours at some point during the testing to insure that it does not exhibit any unusual or unexpected behavior. This is not a requirement for compliance to this procedure.

13. Responses to all properly formed requests, must result in either the specific action or behavior described in the protocol

or in a correctly-formed, appropriate protocol error response. In addition, devices must continue to operate without interruption or anomalous behavior in response to properly or improperly formed requests.

DNP3-2001 IED Certification Procedure Page 2 Subset Level 1 Rev 2.1 – 5-July-01

3 Definitions

3.1 General Master Device that sends DNP application function codes 0-23. Slave Device that sends DNP application function code 0,128,129 (also known as “IED”). Operate This is an action taken by the Slave in response to a Master DNP request. This action does not include

transmission of a response. Examples of an operation are an audible relay click, change in an LED status, or change in the internal state of the Slave. Note that some operations are difficult to observe without intimate knowledge of the Slave device. The inability to observe an operation does not mean that an operation failed to take place.

Request Any message from a Master to a Slave where a response from the Slave is expected. Response Message from Slave caused by a Master Request. Responses are classified as follows:

No response: No octets are sent by Slave • • •

•

• •

Link only response: 10 octet message consisting of only a link layer message Null Response: Message containing a 17-octet link/transport/application response with no error IIN bits set and no application objects. Normal Response: Message containing an application response which has no error IIN bits set, and has no objects which indicate errors All responses must begin with the same application sequence number as the corresponding request. For Multi-fragment responses the first fragment must have the same sequence number as the request and each subsequent fragment must increment the sequence number by 1 modulo 16.

3.2 Internal Indications IIN Octets 3 and 4 of the application response header. Bits are named IINx-y. x=1 for first transmitted octet and 2 for

second transmitted octet. y=bit number where 0=least significant bit. Refer to the Basic Four Application Layer section 3.6 and the Subset Definitions section 4.1.1 for detailed explanations of the IIN bits. The following is a summary of the definitions.

IIN1-1 Class 1 event data available. Can be set at any time and does not indicate an error condition. IIN1-2 Class 2 event data available. Can be set at any time and does not indicate an error condition. IIN1-3 Class 3 event data available. Can be set at any time and does not indicate an error condition. IIN1-4 Time synchronization required. Can be set at any time and does not indicate an error condition. IIN1-5 Local mode. Set if some points are uncontrollable via DNP. IIN1-7 Device restart. Set only under specific conditions. Does not indicate an error condition. IIN2-0 Function Unknown. Generally means that the function code (octet 2 of the request header) cannot be processed. IIN2-1 Object Unknown. Generally means that the function code could be processed but the object group / variation

could not be processed. IIN2-2 Parameter Error. Generally indicates that both the function code and object group / variation could be processed

but that the qualifier / range field is in error.

3.3 Error Responses Error IIN bits IIN bits that indicate a request error (i.e., IIN2-0 or IIN2-1 or IIN2-2). Error Response A response that has any or all of the Error IIN bits set which may also contain data.


Unexpected Error Response Slaves may generate responses with any or all of the following:

• unexpected bits in the IIN set • unexpected bits in any returned flags set • unexpected status code errors

Any unexpected responses must be noted by the tester and “explained” in the test log.

3.4 Changes or Events This section clarifies processing rules related to the following objects.

Change Object Corresponding Static Object

Name Object Name Object

Binary Input Change 2 Binary Input 1

Counter Change Events 22 Counter 20

Frozen Counter Change Events 23 Frozen Counter 21

Analog Change Events 32 Analog Input 30

Frozen Analog Change Events 33 Frozen Analog Input 31 Table 3-1

1. The term “significant change” refers to any of the synonymous terms: “event” or “change event”. 2. Change Objects and Static Objects are related in that a significant change in a point’s static value results in the creation

of a corresponding Change Object entry 3. A significant change for a point is defined to occur:

• for a binary point, on any change in state, and • for a numeric point, on any change in value greater than the point’s threshold

3.4.1 § Rules A device may claim that it supports a specific Change Object if and only if processing for that Change Object can be configured to adhere to the following rules. 1. Change processing must be supported for all points in the corresponding Static Object. 2. The determination that a point has undergone a significant change can be determined only by using information from that

point’s current or past value. Decisions based on information about any other point, directly or indirectly, are explicitly forbidden.

3. For numeric Change Objects, the Device Profile must clearly specify the algorithm used for each point or set of points that specifies how the deadband(s) for those points are determined.

4. All changes must be returned to a host that issues a request for any specific Change Object, limited only by qualifier and range codes in the request.

Some devices may decide to limit the set of points included in Change Object processing (in violation of rule 1), or to invoke a more complicated algorithm for determining a significant change (in violation of rule 2). While these implementations may be useful in specific instances, such devices may not check compliance with the corresponding Change Object in their Device Profile Documentation unless the device is configurable to conform to the rules above.


4 Reference Documents • DNP Version 3.00 Data Link Layer • DNP Version 3.00 Transport Functions • DNP Version 3.00 Application Layer • DNP Version 3.00 Data Object Library Layer • DNP Version 3.00 Subset Definitions Version 2.00 (§ Version 3.00)

5 Pretest Review Before testing proceeds it is necessary to review documentation and equipment supplied by the vendor for completeness and appropriateness to the application. In particular the vendor must have provided the test facility with the following items. • Device Profile Document • Device to be tested • Wiring Diagrams for

• Power • Communications (e.g. RS232, RS485, Bell 202, IEEE 802.3) • Input connections

5.1 Device Profile Review Before connecting any equipment the Device Profile should be carefully reviewed. This document describes the vendors’ specification of the behavior of the device. This behavior should be compared to Level 1 requirements and any discrepancies resolved before testing proceeds. Specifically the Device Profile should indicate that the device: • Responds to all Level 1 requests that a slave device is required to parse. • Responds to Level 1 requests only with Objects/Variations and Qualifiers that a Level 1 master is required to parse. If a device generates any response requiring a higher level master to parse it, the following actions should be taken: • Testing can continue. • It must be noted in the test results that the device is Level 1 compliant for requests only. • The required Master Level must be noted in the test results.

5.2 Equipment Review Before testing proceeds, the device will be examined to insure the proper equipment is available for the following: • Physical interfaces present and compatible. • Wiring diagrams and equipment necessary for Input stimulation. • Input power specifications. • If it is not readily apparent whether an output point has operated, the vendor must supply to the tester a point number and

method to determine whether or not a binary control and/or analog output has operated. A manufacturer’s representative should be available by phone to answer questions during the testing of the device.


6 Link Layer Any DNP device is required to passively implement all link layer services. Specifically, this means that a device need not request link layer service but must support any services requested by another device. For example: • A device can choose not to request link layer confirms but MUST respond with a link layer confirm if requested to do

so. • A device can choose not to request link layer reset if it is using unconfirmed link services but MUST respond with a link

layer confirm if a link layer reset is requested. • § A device must respond to all unconfirmed link requests (i.e. function codes 0, 4, 9) without a preceding link reset. The following tests are designed to verify this functionality.

6.1 Reset Link and Passive Confirm support

6.1.1 Desired Behavior • The Device under test (DUT) must respond to a link reset with a link confirm. • DUT must respond to application layer data requests using unconfirmed link services without requiring a link reset. • DUT must not respond to application layer data requests using confirmed link services without a preceding link reset. • DUT must respond to application layer data requests using confirmed link services after a link reset has been issued. • DUT must acknowledge but not otherwise respond to requests with the wrong FCB. • DUT must issue a data link reset if transmitting requests that require a data link confirm.

6.1.2 Test Procedure 1. Cycle power to the DUT. 2. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 3. Verify that the DUT responds with a valid message. 4. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 5. Verify that the DUT either sends a NACK with the DFC bit clear or does not respond. 6. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xD3. 7. Verify that the DUT either sends a NACK with the DFC bit clear or does not respond. 8. Issue a link reset using link control block 0xC0. 9. Verify that the DUT responds with a link layer confirm (link control block 0x00). 10. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 11. Verify that the DUT responds with a link layer confirm and a valid application layer response. 12. Perform repeated requests of Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and alternating link control

blocks 0xD3 and 0xF3. 13. Verify that the DUT responds with a link layer confirm and a valid application layer response for each request. 14. Issue a link reset using link control block 0xC0. 15. Verify that the DUT responds with a link layer confirm (link control block 0x00). 16. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xD3. 17. Verify that the DUT responds with a link layer confirm (link control block 0x00) and no application response. 18. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 19. Verify that the DUT responds with a link layer confirm and a valid application layer response. 20. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 21. Verify that the DUT responds with a link layer confirm (link control block 0x00) and no application response. 22. If the DUT cannot be configured to request data link confirms when transmitting, continue testing at section 6.2. 23. Configure the DUT to request data link confirm when transmitting. 24. Cycle power to the DUT. 25. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 26. Verify that the DUT responds by sending a data link reset (control block 0x40). 27. Send a data link acknowledge (control block 0x80).


28. Verify that the DUT responds with a valid message having control block 0x73. This is the response to the Class 0 data request, including a request for data link confirm.

29. Issue a data link NACK with DFC clear (control block 0x81). 30. If the DUT then issues a data link reset (control block 0x40), respond by sending an acknowledge control block 0x80). If

the DUT then repeats the Class 0 response message (control block 0x73), it has functioned correctly, and this test is complete, continue testing at section 6.2.

31. If the DUT did not issue a link reset at step 30, steps 25 through 28 should be repeated as shown above. DUT responses other than those of steps 26 and 28 indicate incorrect operation.

6.2 Test Link

6.2.1 Desired Behavior • The DUT must respond with a Link Confirm - ACK if the FCB bits are correct in the test request. • Otherwise, the DUT must respond with the last secondary confirm frame. This behavior is not tested since it was deemed

by the Technical Committee as too difficult to test in a reliable manner. • If the DUT receives a test link frame without a previous link reset, the DUT must either not respond or respond with a

NACK with DFC = 0.

6.2.2 Test Procedure 1. Cycle power to the DUT. 2. Request a Link Test Frame using link control block 0xF2. 3. Verify that the DUT responds with a Confirm - NACK with DFC=0 (link control code 0x01) or does not respond. 4. Issue a Link Reset using link control block 0xC0. 5. Request a Link Test Frame using link control block 0xF2. 6. Verify that the DUT responds with a Confirm - ACK (link control code 0x00). 7. Request a Link Test Frame using link control block 0xD2. 8. Verify that the DUT responds with a Confirm - ACK (link control code 0x00). 9. Cycle power to the DUT. 10. Request a Link Test Frame using link control block 0xD2. 11. Verify that the DUT responds with a Confirm - NACK with DFC=0 (link control code 0x01) or does not respond. 12. Issue a Link Reset using link control block 0xC0. 13. Request a Link Test Frame using link control block 0xF2. 14. Verify that the DUT responds with a Confirm - ACK (link control code 0x00). 15. Request a Link Test Frame using link control block 0xD2. 16. Verify that the DUT responds with a Confirm - ACK (link control code 0x00).

6.3 Request Link Status

6.3.1 Desired Behavior • When issued a Request Link Status message, the DUT must respond with a valid Status of Link message. • The DUT must ignore FCB when FCV = 0.

6.3.2 Test Procedure 1. Cycle power to the DUT. 2. Request a Link Status Frame using link control block 0xC9. 3. Verify that the DUT responds with a valid link status message with link control block 0x0B or 0x1B. 4. Request a Link Status Frame using link control block 0xE9. 5. Verify that the DUT responds with a valid link status message with link control block 0x0B or 0x1B.


6.4 Test Retries

6.4.1 Desired Behavior • DUTs are not required to support link layer retries. • The rest of these behaviors apply only to DUTs that support link layer retries. • § The DUT must be able to disable retries through configuration. • If the device requests a link layer confirm and does not receive it within a specified period of time (LINK TIMEOUT), it

shall retransmit the link frame. It shall do this n times where n is a specified number of retries before aborting transmission (LINK RETRYCOUNT).

• If configured to enable link layer confirms on primary transmissions, the DUT must perform retries on all SEND/CONFIRM and REQUEST/RESPOND frames.

• Both LINK TIMEOUT and LINK RETRYCOUNT must be specified in the Device Profile Document or they can optionally be configurable parameters.

6.4.2 Test Procedure 1. If the DUT does not support link layer confirms or link layer retries on primary transmissions, continue testing in the

next section. 2. Configure the device to enable link layer confirms on primary transmissions and if retries are configurable, set them to a

reasonable value. 3. Cycle power to the DUT. 4. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 5. Verify that the DUT sends a RESET LINK frame. Do not send a data link CONFIRM frame. 6. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 7. Verify that it repeats this exactly LINK RETRYCOUNT times. 8. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 9. Verify that the DUT responds with a RESET LINK frame. Send a data link CONFIRM. 10. Verify that the DUT sends a valid application layer response in a SEND/CONFIRM USER DATA frame. Do not send a

data link CONFIRM frame. 11. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 12. Verify that it repeats this exactly LINK RETRYCOUNT times. 13. If it is possible to cause the DUT to send TEST LINK, RESET USER PROCESS, or REQUEST LINK STATUS, cause

it to do so, but do not respond in each case. Repeat steps 11 and 12 for each of these frames that can be generated. 14. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 15. Verify that the DUT responds with a RESET LINK frame. Send a data link CONFIRM. 16. Verify that the DUT sends a valid application layer response in a SEND/CONFIRM USER DATA frame. Do not send a

data link CONFIRM frame. 17. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 18. Send a data link CONFIRM. 19. Verify that no further retries are sent. 20. If it is possible to cause the DUT to send TEST LINK, RESET USER PROCESS, or REQUEST LINK STATUS, cause

it to do so, but do not respond in each case. Repeat steps 18 and 19 for each of these frames that can be generated.

6.5 § DIR and FCV Bits

6.5.1 Desired Behavior The DUT must clear (set to zero) the DIR bit in each data link frame it transmits. •

• The DUT must set the FCV bit to zero in all frames except SEND/CONFIRM User Data and SEND/CONFIRM Test Link. These frames are tested elsewhere.

6.5.2 Test Procedure 1. If the DUT is capable of requesting data link confirmations, configure it to NOT request data link confirmations.


2. Cycle power to the DUT. 3. Prepare and send a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control

block 0xC4. 4. Verify the response from the DUT uses data link control block 0x44 i.e. Unconfirmed User Data with the DIR bit not set

and the FCV bit not set. 5. If the DUT can generate RESET USER PROCESS or REQUEST LINK STATUS, cause it to do so and verify none of

these frames have the DIR or FCV bit set. 6. If the DUT can generate TEST LINK, cause it to do so and verify that these frames have the DIR bit clear and FCV bit

set. 7. If the DUT is not capable of requesting data link confirmations, no further testing is required in this section. If the DUT

is capable of requesting data link confirmations, configure it to do so. 8. Cycle power to the DUT. 9. Prepare and send a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control

block 0xC4. 10. Verify the DUT first sends a frame with data link control block 0x40, i.e. RESET LINK with DIR=0 and FCV=0. 11. Reply with a data link CONFIRM - ACK. 12. Verify the DUT sends a frame with data link control block 0x73 i.e. SEND/CONFIRM USER DATA with FCV=1 and

FCB = 1. 13. Configure DUT to NOT request data link confirmations.

6.6 Data Link Rejects Invalid Frames

6.6.1 Desired Behavior The DUT must detect errors due to transmission line errors or the incorrect functioning of other devices. It must therefore not respond, either at a data link layer or application layer, to frames that are otherwise valid but have one of the following errors:

Incorrect start sequence • • • • •

•

•

Incorrect destination address Incorrect CRC Invalid function code Invalid FCV (Frame Count Valid) bit

For an invalid function code or invalid FCV, the DUT may also respond with LINK SERVICE NOT IMPLEMENTED. NOTES:

These procedures do not test whether the DUT rejects frames having the DIR bit set incorrectly. Implementers of Slave IEDs must, however, clear this bit (0) in all their transmissions to aid monitoring their device’s output on protocol analyzers. This is tested in section “DIR and FCV Bits”. It is optional whether devices choose to filter frames based on source address, and is therefore not tested here. The Device Profile Document indicates whether or not filtering is performed based on the source address.

6.6.2 Test Procedure – Primary Frames Before performing the remainder of these tests: 1. Cycle power to the DUT. 2. Issue a link reset using link control block 0xC0. 3. Verify that the DUT responds with a link layer confirm (link control block 0x00). 4. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 5. Verify that the DUT responds with a link layer confirm (link control block 0x00). 6. Verify that the DUT responds with application layer data. To perform the remainder of this test, a general-purpose protocol analyzer capable of generating any sequence of data is necessary. If a DNP-specific protocol analyzer is being used for testing, it should be used to monitor the exchange between the general-purpose analyzer and the DUT.


6.6.2.1 Invalid Start Octets 1. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block

0xD3. 2. Modify the frame so it begins with an invalid initial start octet (e.g. 0x09) instead of 0x05. 3. Modify the CRC of the data link layer header so the CRC is correct for the invalid start octet. 4. Send the request. 5. Wait several seconds. 6. Verify that the DUT does not send a link layer confirm or application layer response. 7. Modify the frame so it begins with 0x05, but the second start octet is invalid (e.g. 0xff). 8. Modify the CRC of the data link layer header so the CRC is correct for the invalid start octet. 9. Send the request. 10. Wait several seconds. 11. Verify that the DUT does not send a link layer confirm or application layer response. 12. Repeat this test once using different start octet values.

6.6.2.2 Invalid Primary Function Code 1. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block of

0xD3. 2. Modify the frame so the control field contains the correct settings of the DIR, PRM, FCB and FCV fields, but has an

invalid function code, e.g. 0xD5. Alter the CRC of the data link layer header so the CRC is correct for the invalid control field.

3. Send the request. 4. Wait several seconds. 5. Verify that the DUT either does not send a link layer confirm, or responds with a valid LINK SERVICE NOT

IMPLEMENTED frame (control field 0x0F). 6. Verify that the DUT does not send an application layer response. 7. Repeat this test once with a different invalid function code.

6.6.2.3 Invalid Destination Address 1. Send a READ request to different address. Note: For devices that can be configured to represent multiple logical devices

(i.e. can respond to requests directed to more than one address), ensure that the selected address is not one of the other valid addresses configured for the device.

2. Wait several seconds. 3. Verify that the DUT does not send a link layer confirm or application layer response. 4. Repeat this test once with a different destination address.

6.6.2.4 Invalid CRC 1. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block

0xD3. 2. Modify the frame so the CRC of the data link layer header is incorrect. 3. Send the request. 4. Wait several seconds. 5. Verify that the DUT does not send a link layer confirm or application layer response. 6. Modify the frame so the CRC of the data link layer header is correct but the CRC of the application layer request is

incorrect. 7. Send the request. 8. Wait several seconds. 9. Verify that the DUT does not send a link layer confirm or application layer response. 10. Repeat this test once with different incorrect CRC values.


6.6.2.5 § Invalid FCV 1. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block

0xC3, i.e. SEND/CONFIRM USER DATA, but with FCV=0 (incorrect). 2. Send the request. 3. Wait several seconds. 4. Verify that the DUT does not send a link layer confirm or application layer response. The DUT may respond with a link

layer frame with function code LINK SERVICE NOT IMPLEMENTED. 5. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block

0xD4, i.e. SEND/NO CONFIRM USER DATA, but with FCV=1 (incorrect). 6. Send the request. 7. Wait several seconds. 8. Verify that the DUT does not send a link layer confirm or application layer response. The DUT may respond with a link

layer frame with function code LINK SERVICE NOT IMPLEMENTED. 9. Repeat steps 5-8 using the control blocks in the following table:

Code Description Notes C2

Test Link

FCV = 0 incorrect

D0

RESET LINK

FCV=1 incorrect, FCB = 0 ignored

D9

Link Status Request


6.6.3 Test Procedure – Secondary Frames The tests in this section are optional, and must pass only if the DUT requests data link confirmations and performs retries. The retries are used to detect whether the device processed the data link layer confirmation. Before performing these tests: 1. Configure the device to enable link layer confirms on primary transmissions and if retries are configurable set them to a

reasonable value. 2. Cycle power to the DUT. 3. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 4. Verify that before responding with application layer data, the DUT sends a RESET LINK frame. Send a data link

CONFIRM – ACK frame in reply. 5. Verify the DUT responds with application layer data, requesting data link confirmation. 6. Send a valid CONFIRM – ACK frame in reply. To perform the remainder of this test, a general-purpose protocol analyzer capable of generating any sequence of data is necessary. If a DNP-specific protocol analyzer is being used for testing, it should be used to monitor the exchange between the general-purpose analyzer and the DUT.

6.6.3.1 Invalid Start Octets 1. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 2. Verify the DUT responds with application layer data, requesting data link confirmation. 3. Send a CONFIRM – ACK frame modified so its start octet is invalid (e.g. 0x09). 4. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 5. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 6. Verify the DUT responds with application layer data, requesting data link confirmation. 7. Send a CONFIRM – ACK frame modified so the start octet is correct (0x05), but the second octet is incorrect (e.g.

0xff). 8. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 9. Repeat this test once with different start octet values.


6.6.3.2 Invalid Secondary Function Code 1. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 2. Verify the DUT responds with application layer data, requesting data link confirmation. 3. Send a CONFIRM – ACK frame modified so the DIR, PRM and DFC bits of the control field are correct, but the

function code is invalid (e.g. 0x03). Ensure that the CRC is correct for the invalid function code value. 4. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 5. Repeat this test once with a different function code value.

6.6.3.3 Invalid Destination Address 1. This test may be performed with a DNP-specific test set. 2. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 3. Verify the DUT responds with application layer data, requesting data link confirmation. 4. Send a CONFIRM – ACK frame to a destination address that is not that of the DUT. 5. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 6. Repeat this test once with a different destination address.

6.6.3.4 Invalid CRC 1. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 2. Verify the DUT responds with application layer data, requesting data link confirmation. 3. Send a CONFIRM – ACK frame modified such that the CRC is incorrect. 4. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 5. Repeat this test once with a different CRC value.


7 Transport Layer Whenever FIR, FIN and sequence numbers are referenced in this section they refer to the definitions present in the transport header which is reproduced here for convenience.

Transport Header bit 7 bit 6 bits 5-0 FIN FIR Sequence number

Table 7-1

7.1 Desired Behavior • If the DUT contains enough data to cause the reply to an application request to be larger than one Link Protocol Data

Unit, it is required to, a) Set the proper FIR and FIN bits. b) Set the correct sequence information. c) Distribute the data correctly. d) Signify to the initiating station that the reply contains multiple LPDU’s e) Provide the appropriate information for assembly at the receiving station.

• If the device does not contain enough data, then the FIR and FIN bits must signify that there is only one LPDU in the reply.

7.2 Test Procedure 1. Cycle power to the DUT. 2. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06. 3. Verify that the DUT responds with a valid message. 4. If the DUT’s reply contains more than 249 octets then verify that the first response message sets the FIR bit to a one, the

FIN bit is set to zero. 5. Verify subsequent messages to assure that the FIR bit is zero, the FIN bit is zero, and the sequence number increments

by one. 6. Verify that the last message has the FIR bit is zero and the FIN bit is one, signifying the last data fragment, and the SEQ

value increments by one. 7. If the DUT’s reply contains less than 250 octets in the Data Link Frame then the FIR bit is set to one and the FIN bit is

also set to one.


8 Application Layer

8.1 Binary Output Status The binary output status object represents the current state and status of the associated binary output. The status is an 8-bit flag field (repeated here for your convenience):

Flag Bit Value 0 ONLINE - 0=off-line, 1= on-line 1 RESTART - 0=normal, 1= restart 2 COMMUNICATION LOST - 0=normal, 1=lost 3 REMOTE FORCED DATA - 0=normal, 1=forced 4 LOCAL FORCED DATA - 0=normal, 1=forced 5 0 6 0 7 STATE - 0, 1

Table 8-1

8.1.1 Desired Behavior • If the device supports binary outputs the device must respond to a Binary Output read request with a binary output status

object (object 10 Variation 2) using qualifiers 0x00 or 0x01. • If the device does not support binary outputs the device must respond to a Binary Output read request with a Null

Response. • Optionally, the device can return an error response with IIN2-1.

8.1.2 Test Procedure 1. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 2. If the device supports Binary Outputs verify that the DUT responds with a Binary Output Status object (Object 10

Variation 2). 3. Verify that the data is reported using either 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing

(qualifier 0x01). 4. If the device does not support Binary Outputs verify that the DUT responds with a Null Response. The device can

optionally set IIN2-1. 5. Verify that flag behavior complies with Section 2, Note #5.

8.2 Binary Outputs § If a device supports control outputs, it is required to be configurable to support all three modes of operation of control, namely Select Before Operate, Direct Operate, and Direct Operate No Acknowledgment. A device may be configurable to disable any subset of the modes. If a device has been configured to reject a particular mode, it must return a control status value of 4 (control operation not supported for this point). It is the hosts’ responsibility to determine the appropriate control mechanism. It is also the hosts’ responsibility to perform select before operate control when it is unacceptable to have the control point operated more than once. This is typically a configuration item in the host and is the responsibility of the end user to configure properly. It is the outstations’ responsibility to perform the control operation if a correct control dialog has been issued from the host. If the DUT is configurable in a manner such that points can be uninstalled or disabled, the device must be configured with at least one Binary Output point installed or enabled before proceeding with the test procedure.


8.2.1 Select Before Operate Select before operate control is used under circumstances when it is absolutely imperative that the control point operate only once. An example of this is a recloser. The host first initiates the select portion of the dialog. The outstation then echoes the exact control request byte for byte to the host. Note that the encapsulation information need not match, but that the object, variation, qualifier, and all object data must match exactly. The host then sends the execute portion of the dialog. The object, variation, qualifier, and all object data must match exactly byte for byte the data sent in the select message. If this message matches the select message byte for byte and it is received within the configured acceptable delay between select and execute the outstation must operate the control point.

8.2.1.1 Desired Behavior The following assumes that the device does not support control operations:

• If the device does not support control outputs, it must respond to a select with an Error Response setting IIN2-1. • An Error Response with IIN2-2 set is an invalid response. • No further testing in this section is necessary.

The following assumes that the device supports control operations:

• The maximum select to execute delay time must be specified in the Device Profile Document. • The DUT responds to matching select and execute requests by echoing each request with the status field set to 0.

The specified control operates. • The DUT responds to selecting an uninstalled control point by returning an error response with IIN2-2 set and a

status code of 4. The control point does not operate. • The DUT responds to executing an installed control point after the configured acceptable select to execute delay by

echoing the execute and setting the status field to 1 [Execute received after timeout]. The control point does not operate

• The DUT responds to a non-matching execute with a status field of 2 [No previous matching select] and does not operate the control under the following conditions:

• No prior select issued • On time mismatch • Off time mismatch • Control code mismatch • The DUT operates various selected control points. • The DUT supports 8 and 16 bit point indexing.

The following assumes that the device supports control operations and were added as a result of Technical Bulletin TB2000-002 (Control Retries):

• The DUT must accept retries on the select portion of the control dialog that increment the application sequence number between retries. In this case the select-to-operate timer must be restarted after reception of each select.

• The DUT must accept retries on the select portion of the control dialog that do not increment the application sequence number between retries. In this case the select-to-operate timer must remain unaltered by the reception of each additional select.

• The DUT must reject any operate that does not: $ contain a application layer sequence number that is exactly one greater (modulo 16) than the previously

accepted select. $ match the object portion of the select message byte for byte, excluding the application header.

• The DUT must accept retries on the operate portion of the control dialog that does not increment the application sequence number between retries. The DUT must echo the operate command but must not operate the control more than once.

The following assumes that the device does support control operations, however there are no control points installed/enabled:

• If the device does not have any control outputs installed, it must respond to a select with an Error Response setting IIN2-1 or IIN2-2.


8.2.1.2 Test Procedure

8.2.1.2.1 Binary Output, SBO, 0x28 1. Issue a select using Object 12 Variation 1 to an installed point using 16 bit indexing (qualifier 0x28), a control code

supported by the device and an appropriate on time/off time. 2. If the device does not support control outputs, verify that the DUT responds with a Error Response with IIN2-1 set. End

testing of Binary Output SBO. 3. Verify that the DUT responds by echoing the select message exactly. 4. Immediately issue a matching execute. 5. Verify that the DUT echoes the execute. 6. Verify that the selected control operates.

8.2.1.2.2 Binary Output, SBO, 0x17 1. Issue a select using Object 12 Variation 1 to a different installed point using 8 bit indexing (qualifier 0x17), a control

code supported by the device and an appropriate on time/off time. 2. If the device does support control outputs, verify that the DUT responds by echoing the select message exactly. 3. Immediately issue a matching execute. 4. Verify that the DUT echoes the execute. 5. Verify that the selected control operates.

8.2.1.2.3 Binary Output, SBO, To Uninstalled Point 1. Issue a select using Object 12 Variation 1 to an uninstalled point using 16 bit indexing (qualifier 0x28) using a control

code supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of 4. 3. Verify that no control point operates.

8.2.1.2.4 Binary Output, SBO, Execute Issued After Timeout 1. Issue a select using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code

supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Wait 1 second past the configured maximum select to execute delay time. 4. Issue a matching execute and verify that the DUT echoes the execute with the control status field set to 1[Execute

received after timeout]. 5. Verify that no control point operates.

8.2.1.2.5 Binary Output, SBO, Execute to Different Point Than Select 1. Issue a select to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code supported

by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 12 Variation 1 to a different installed point using 8 bit indexing (qualifier 0x17),

the same control code as the select, and the same on time/off time as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.

8.2.1.2.6 Binary Output, SBO, Execute On Time does not match Select On Time 1. Issue a select using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code

supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue a execute to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), the same

control code as the select, the on time incremented by 1 and the same off time as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.


8.2.1.2.7 Binary Output, SBO, Execute Off Time does not match Select Off Time 1. Issue a select using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code

supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), the

same control code as the select, same on time as the previous select and the off time incremented by 1. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.

8.2.1.2.8 Binary Output, SBO, Select using a supported Control Code, Execute using a different Control Code

1. Issue a select using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code supported by the device and an appropriate on time/off time.

2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a

control code different from the previous select, and the same on time/off time as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.

8.2.1.2.9 Binary Output, SBO, Select 0x28, Execute 0x17 1. Issue a select using Object 12 Variation 1 to an installed point using 16 bit indexing (qualifier 0x28), a control code

supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a

control code supported by the device and the same on time/off time as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.

8.2.1.2.10 Binary Output, SBO, Configurable Device 1. If the device is not configurable in a manner such that control points can be uninstalled or disabled, skip this section. 2. Configure the DUT such that all Binary Output points are uninstalled or disabled. 3. Issue a select using Object 12 Variation 1 to point 0 using 16 bit indexing (qualifier 0x28), a control code supported by

the device and an appropriate on time/off time. 4. Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set. 5. Verify that no control point operates.

8.2.1.2.11 Binary Output, SBO, Same Sequence Number Select Retries 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again using the same application layer sequence number. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the binary output.

8.2.1.2.12 Binary Output, SBO, Incrementing Sequence Number Select Retries 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again incrementing the application layer sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the select byte for byte.


6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the binary output.

8.2.1.2.13 Binary Output, SBO, Same Sequence Number Operate Retries 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the binary output. 7. Issue the operate again using the same application layer sequence number. 8. Verify that the DUT echoes the object portion of the operate byte for byte. 9. Verify that the DUT does not operate the binary output.

8.2.1.2.14 Binary Output, SBO, Incrementing Sequence Number Operate Retries 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the binary output. 7. Issue the operate again, incrementing the sequence number by 1 modulo 16. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO

MATCHING SELECT). 9. Verify that the DUT does not operate the binary output.

8.2.1.2.15 Binary Output, SBO, Sequence number checking 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO

MATCHING SELECT). 6. Verify that the DUT does not operate the binary output. 7. Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the mismatched operate

cleared the previous select. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO


8.2.2 Direct Operate with Acknowledge

8.2.2.1 Desired Behavior The following behavior assumes that the device does not support control operation: • If the device does not support control outputs, it must respond to a direct operate with an Error Response setting IIN2-1. • An Error Response with IIN2-2 set is an invalid response. • No further testing in this section is necessary.

The following behavior assumes that the device supports control operations: • The DUT responds to a direct operate to an uninstalled data point by returning an Error response with IIN2-2 set and a

status code of 4. The control does not operate.


• The DUT responds to a direct operate to an installed data point by echoing the direct operate and setting the status field to 0. The specified control operates.

The following behavior assumes that the device does support control operations, however there are no control points installed/enabled: • If the device does not have any control outputs installed, it must respond to a direct operate with an Error Response

setting IIN2-1 or IIN2-2.


8.2.2.2.1 Binary Output, Direct Operate 1. Issue a direct operate using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control

code supported by the device and an appropriate on time/off time. 2. If the device does not support control outputs verify that the DUT responds with an Error Response with IIN2-1 set and

end testing of this section. 3. If the device does support control outputs verify that the DUT responds by echoing the direct operate message exactly

with status field of 0. 4. Verify that the specified control operates.

8.2.2.2.2 Binary Output, Direct Operate to Uninstalled Point 1. Issue a direct operate using Object 12 Variation 1 to an uninstalled point using 16 bit indexing (qualifier 0x28) using a

control code supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by returning an Error response with IIN2-2 set and a status code of 4. 3. Verify that no control operates.

8.2.2.2.3 Binary Output, Direct Operate, Configurable Device 1. If the device is not configurable in a manner such that control points can be uninstalled or disabled, end testing of Binary

Output, Direct Operate. 2. Configure the DUT such that all Binary Output points are uninstalled or disabled. 3. Issue a direct operate using Object 12 Variation 1 to point 0 using 16 bit indexing (qualifier 0x28) using a control code

supported by the device and an appropriate on time/off time. 4. Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set. 5. Verify that no control operates.

8.2.3 Direct Operate, No Acknowledge

8.2.3.1 Desired Behavior • The DUT must not respond to in any way to the direct operate no acknowledge. • If the device supports binary outputs and the operate message is correct then the binary output point must operate.


8.2.3.2.1 Binary Output, Direct Operate, No Acknowledge 1. Issue a Direct Operate, No Acknowledge using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier

0x17), a control code supported by the device and an appropriate on time/off time. 2. Verify that the DUT does not respond. 3. If the device does not support control outputs, end testing of this section. 4. If the device does support control outputs, verify that the proper control point operates.


8.2.3.2.2 Binary Output, Direct Operate, No Acknowledge, to an Uninstalled Point 1. Issue a Direct Operate, No Acknowledge using Object 12 Variation 1 to an uninstalled point using 16 bit indexing

(qualifier 0x28) using a control code supported by the device and an appropriate on time/off time. 2. Verify that the DUT does not respond. 3. Verify that no control operates.

8.2.3.2.3 Binary Output, Direct Operate, No Acknowledge, Configurable Device 1. If the device is not configurable in a manner such that control points can be uninstalled or disabled, end testing of Binary

Output, Direct Operate, No Acknowledge. 2. Configure the DUT such that all Binary Output points are uninstalled or disabled. 3. Issue a Direct Operate, No Acknowledge using Object 12 Variation 1 to point 0 using 16 bit indexing (qualifier 0x28)

using a control code supported by the device and an appropriate on time/off time. 4. Verify that the DUT does not respond. 5. Verify that no control operates.

8.2.4 Multiple Object Requests

8.2.4.1 Desired Behavior • The DUT must parse requests for all control operations within a single frame. • Up to a full frame of request operations must be supported. The following assumes that the device supports control operations and were added as a result of Technical Bulletin TB2001-001 (Multiple Control Object and Status Codes):

• The DUT responds to requests having more points than are supported in a single message with a status code of 8 for at least the first point that is beyond the point count limit.

• The DUT responds to a select to an uninstalled control point by returning an error response with IIN2-2 set and a status code of 4.

8.2.4.2 Test Procedure 1. Review the device’s profile document to understand how many control points are supported in a single request. If this

number is one, skip to step 7. 2. Determine the number of installed points that can be successfully controlled in a single request. This number shall be the

smaller of: • The number of controls supported in a single request • The number of installed control points • Sixteen In a single request, issue a select to the above number of points using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time.

3. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set and that each object returns a status code of 0. 4. Immediately issue a matching execute. 5. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set and that each object returns a status code of 0. 6. Verify that each of the selected controls operated. Note that controls may execute simultaneously or sequentially one

after the other. 7. If the number of control objects supported in a single request is greater than or equal to either

• The number of control objects that fit into a single frame or • The number of installed control points,

skip to step 13. 8. In a single request, issue a select to at least one more point than is supported in a single request, each point having a

different index but otherwise able to be controlled, using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time.



10. If the DUT does not support direct operate, skip to step 13. 11. In a single request, issue a direct operate command to at least one more point than is supported in a single request, each

point having a different index but otherwise able to be controlled, using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time.




8.2.5 Control Code Support

8.2.5.1 Desired Behavior The following assumes that the device supports control operations and were added as a result of Technical Bulletin TB2000-006 (CROB Control Codes):

• For complementary function indices, the Outstation must accept at least one of the following control code pairs: $ 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) $ 0x41 (Pulse On/Close) and 0x81 (Pulse On/Trip)

• The outstation may optionally accept both forms of complementary control code pairs. If it does:

$ control codes 0x03 (Latch On/NUL) and 0x41 (Pulse On/Close) must perform the same function $ control codes 0x04 (Latch Off/NUL) and 0x81 (Pulse On/Trip) must perform the same function

• For single function indices, the outstation must accept at least one of the following control codes:

$ 0x01 (Pulse On/NUL) $ 0x03 (Latch On/NUL) $ 0x04 (Latch Off/NUL) $ 0x41 (Pulse On/Close) $ 0x81 (Pulse On/Trip)

• If the outstation accepts more than one control code for a single function index, it must perform the same function

for each control code it accepts.


8.2.5.2.1 Binary Output, Complementary Function Support 1. If the DUT does not have installed binary output points skip this section. 2. If the DUT does not have installed complementary function binary output points skip this section. 3. If the DUT does not support the 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) pair skip to step 8. 4. Issue a valid control sequence to the first installed complementary function binary output point using control code 0x03

(Latch On/NUL). 5. Verify the control operation completes successfully. 6. Issue a valid control sequence to an installed complementary function binary output point using control code 0x04 (Latch

Off/NUL). 7. Verify the complementary control operation completes successfully. 8. If the DUT does not support the 0x41(Pulse On/Close) and 0x81 (Pulse On/Trip) pair skip to step 13. 9. Issue a valid control sequence to an installed complementary function binary output point using control code 0x41(Pulse

On/Close). 10. Verify the control operation completes successfully.


11. Issue a valid control sequence to an installed complementary function binary output point using control code 0x81 (Pulse On/Trip).

12. Verify the complementary control operation completes successfully. 13. If the DUT does not support both the 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) control code pair and the

0x41(Pulse On/Close) and 0x81 (Pulse On/Trip) control code pair skip to step the next section. 14. Issue a valid control sequence to an installed complementary function binary output point using control code 0x03 (Latch

On/NUL). 15. Verify the control operation completes successfully. 16. Issue a valid control sequence to the same installed complementary function binary output point using control 0x81

(Pulse On/Trip). 17. Verify that the complementary control operation completes successfully. 18. Issue a valid control sequence to the same installed complementary function binary output point using control code

0x41(Pulse On/Close). 19. Verify the complementary control operation completes successfully. 20. Issue a valid control sequence to the same installed complementary function binary output point using control 0x04

(Latch Off/NUL). 21. Verify the complementary control operation completes successfully.

8.2.5.2.2 Binary Output, Single Function Support 1. If the DUT does not have installed binary output points skip this section. 2. If the DUT does not have installed single function binary output points skip this section. 3. For any point that is tested below, determine what action should happen when the control executes. 4. If the DUT does not support the 0x01 (Pulse On/NUL) control code for single function binary output points at this index

skip to step 7. 5. Issue a valid control sequence to the first installed single function binary output point using control code 0x01 (Pulse

On/NUL). 6. Verify the control operation in step 3 completes successfully. 7. If the DUT does not support the 0x03 (Latch On/NUL) control code for single function binary output points at this index

skip to step 10. 8. Issue a valid control sequence to the first installed single function binary output point using control code 0x03 (Latch

On/NUL). 9. Verify the control operation in step 3 completes successfully. 10. If the DUT does not support the 0x04 (Latch Off/NUL) control code for single function binary output points at this index

skip to step 13. 11. Issue a valid control sequence to the first installed single function binary output point using control code 0x04 (Latch

Off/NUL). 12. Verify the control operation in step 3 completes successfully. 13. If the DUT does not support the 0x41 (Pulse On/Close) control code for single function binary output points at this index

skip to step 16. 14. Issue a valid control sequence to the first installed single function binary output point using control code 0x41 (Pulse

On/Close). 15. Verify the control operation in step 3 completes successfully. 16. If the DUT does not support the 0x81 (Pulse On/Trip) control code for single function binary output points at this index

skip to the next section. 17. Issue a valid control sequence to the first installed single function binary output point using control code 0x81 (Pulse

On/Trip). 18. Verify the control operation in step 3 completes successfully.

8.3 Analog Output Status The Analog Output Status object represents the actual value of an analog output or software point and the associated status reported by an 8-bit flag field (repeated here for convenience):


Flag Bit Value 0 ONLINE - 0=off-line, 1= on-line 1 RESTART - 0=normal, 1= restart 2 COMMUNCATION LOST - 0=normal, 1=lost 3 REMOTE FORCED DATA - 0=normal, 1=forced 4 LOCAL FORCED DATA - 0=normal, 1=forced 5 0 6 0 7 0

Table 8-2

8.3.1 Desired Behavior • If the device supports analog outputs the device must respond to an analog output read request with an analog output

object (object 40 variation 2) using qualifier 0x00 or 0x01. • If the device does not support analog outputs the device must respond to an analog output read request with a Null

Response or an Error Response with IIN2-1 or IIN2-2 set. • The value returned in the Analog Output Status must reflect the value written to the corresponding Analog Output point

within the tolerances specified by the manufacturer.

8.3.2 Test Procedure 1. Issue a Direct Operate to Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an

appropriate value. 2. Issue a request for Object 40 Variation 0 using the all data qualifier 0x06. 3. If the device supports Analog Outputs verify that the DUT responds with an Analog Output Status object (object 40


(qualifier 0x01). 5. If the device does not support Analog Outputs verify that the DUT responds with a Null Response. The device can

optionally return an Error Response with IIN2-1or IIN2-2 set. 6. Verify that the value returned in the Analog Output Status object reflects the value sent in step 1 within the tolerances

specified by the manufacturer.

8.4 Analog Outputs § If a device supports analog outputs, it is required to be configurable to support all three modes of operation, namely Select Before Operate, Direct Operate, and Direct Operate no Acknowledgment. A device may be configurable to disable any subset of the modes. If a device has been configured to reject a particular mode, it must return a control status value of 4 (control operation not supported for this point). It is the hosts’ responsibility to determine the appropriate analog output mechanism. It is also the hosts’ responsibility to perform select before operate control when it is unacceptable to have the analog output point operate more than once. This is typically a configuration item in the host and is the responsibility of the end user to configure properly. It is the outstations’ responsibility to perform the analog output operation if a correct control dialog has been issued from the host. If the DUT is configurable in a manner such that points can be uninstalled or disabled, the device must be configured with at least one Analog Output point installed or enabled before proceeding with the test procedure.

8.4.1 Select Before Operate The host first initiates the select portion of the dialog. The outstation then echoes the exact analog output request byte for byte to the host. Note that the encapsulation information need not match, but that the object, variation, qualifier, and all object data must match exactly. The host then sends the execute portion of the dialog. The object, variation, qualifier, and all object DNP3-2001 IED Certification Procedure Page 23 Subset Level 1 Rev 2.1 – 5-July-01

data must match exactly byte for byte the data sent in the select message. If the execute message matches the select message byte for byte and it is received within the configured acceptable delay between select and execute, the outstation operates the analog output point.

8.4.1.1 Desired Behavior The following behavior assumes that the device does not support analog output operations: • If the device does not support analog outputs it must respond to a select with an Error Response setting IIN2-1. • An Error Response with IIN2-2 set is an invalid response. • No further testing in this section is necessary. The following behavior assumes that the device supports analog output operations: • The maximum select to execute delay time must be specified in the Device Profile Document. • The DUT responds to matching select and execute requests by echoing each request with the status field set to 0. The

specified analog output operates. • The DUT responds to selecting an uninstalled analog output point by returning an error response with IIN2-2 set and a

status code of 4. The analog output point does not operate. • The DUT responds to executing an installed analog output point after the configured acceptable select to execute delay

by echoing the execute and setting the status field to 1[Execute received after timeout]. The analog output does not operate.

• The DUT responds to a non-matching execute with a status field of 2 [No previous matching select] and does not operate the analog output under the following conditions: • No prior select issued. • Value does not match. • The DUT operates various selected analog output points. • The DUT supports 8 and 16 bit point indexing.

The following assumes that the device supports analog output operations and were added as a result of Technical Bulletin TB2000-002 (Control Retries): • The DUT must accept retries on the select portion of the analog output dialog that increment the application sequence

number between retries. In this case the select-to-operate timer must be restarted after reception of each select. • The DUT must accept retries on the select portion of the analog output dialog that do not increment the application

sequence number between retries. In this case the select-to-operate timer must remain unaltered by the reception of each additional select.

• The DUT must reject any operate that does not • contain a application layer sequence number that is exactly one greater (modulo 16) than the previously accepted

select. • match the object portion of the select message byte for byte, excluding the application header.

• The DUT must accept retries on the operate portion of the analog output dialog that does not increment the application sequence number between retries. The DUT must echo the operate command but must not operate the analog output more than once.

The following behavior assumes that the device does support analog output operations, however there are no analog output points installed/enabled: • If the device does not have any analog outputs installed, it must respond to a select with an Error Response setting IIN2-

1 or IIN2-2.


8.4.1.2.1 Analog Output, SBO, 0x28 1. Issue a select using Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an appropriate

value.


2. If the device does not support analog outputs verify that the DUT responds with an Error Response with IIN2-1 set. End testing of Analog Outputs.

3. Verify that the DUT responds by echoing the select message exactly. 4. Immediately issue a matching execute. 5. Verify that the DUT echoes the execute. 6. Verify that the selected analog output operates.

8.4.1.2.2 Analog Output, SBO, 0x17 1. Issue a select using Object 41 Variation 2 to a different point using 8 bit indexing (qualifier 0x17) and an appropriate

value. 2. If the device does support analog outputs, verify that the DUT responds by echoing the select message exactly. 3. Immediately issue a matching execute. 4. Verify that the DUT echoes the execute. 5. Verify that the selected analog output operates.

8.4.1.2.3 Analog Output, SBO, to Uninstalled Point 1. Issue a select using Object 41 Variation 2 to an uninstalled point using 16 bit indexing (qualifier 0x28) and an

appropriate value. 2. Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of 4. 3. If an analog output is observed to operate, the test fails.

8.4.1.2.4 Analog Output, SBO, Execute Issued After Time-out 1. Issue a select using Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an appropriate

value. 2. Verify that the DUT responds by echoing the select message exactly. 3. Wait 1 second past the configured maximum select to execute delay time. 4. Issue a matching execute and verify that the DUT echoes the execute with the status field set to 1 [Execute received after

timeout]. 5. If an analog output is observed to operate, the test fails.

8.4.1.2.5 Analog Output, SBO, Execute Value does not match Select Value 1. Issue a select using Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an appropriate

value. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and the

same value incremented by 1. 4. Verify that the DUT echoes the execute with the status field set to 2 [No previous matching select]. 5. If an analog output is observed to operate, the test fails.

8.4.1.2.6 Analog Output, SBO, Select 0x28, Execute 0x17 1. Issue a select using Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an appropriate

value. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and the

same value as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. If an analog output is observed to operate, the test fails.

8.4.1.2.7 Analog Output, SBO, Configurable Device 1. If the device is not configurable in a manner such that analog output points can be uninstalled or disabled, skip this

section. 2. Configure the DUT such that all Analog Output points are uninstalled or disabled.


3. Issue a select using Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier 0x28) and an appropriate value.

4. Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set. 5. If an analog output is observed to operate, the test fails.

8.4.1.2.8 Analog Output, SBO, Same Sequence Number Select Retries 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again using the same application layer sequence number. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the analog output.

8.4.1.2.9 Analog Output, SBO, Incrementing Sequence Number Select Retries 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again incrementing the application layer sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the analog output.

8.4.1.2.10 Analog Output, SBO, Same Sequence Number Operate Retries 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the analog output. 7. Issue the operate again using the same application layer sequence number. 8. Verify that the DUT echoes the object portion of the operate byte for byte. 9. Verify that the DUT does not operate the analog output.

8.4.1.2.11 Analog Output, SBO, Incrementing Sequence Number Operate Retries 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the analog output. 7. Issue the operate again, incrementing the sequence number by 1 modulo 16. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO

MATCHING SELECT). 9. Verify that the DUT does not operate the analog output.

8.4.1.2.12 Analog Output, SBO, Sequence number checking 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO

MATCHING SELECT).


6. Verify that the DUT does not operate the analog output. 7. Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the mismatched operate

cleared the previous select. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO



8.4.2.1 Desired Behavior The following assumes that the device does not support analog output operations: • If the device does not support analog outputs, it must respond to a direct operate with an Error Response setting IIN2-1. • No further testing in this section is necessary.

The following assumes that the device supports analog output operations: • The DUT responds to a Direct Operate to an installed analog output point echoing the direct operate and setting the

status field to 0. The specified analog output operates. • The DUT responds to a Direct Operate to an uninstalled analog output point by returning an Error Response with IIN2-2

set and a status code of 4. No analog outputs shall be observed to operate. • The DUT operates various analog output points. The following assumes that the device does support analog output operations, however there are no analog output points installed/enabled: • If the device does not have any analog outputs installed, it must respond to a direct operate with an Error Response



8.4.2.2.1 Analog Output, Direct Operate 1. Issue a Direct Operate to Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an

appropriate value. 2. If the device does not support analog output verify that the DUT responds with an Error Response with IIN2-1 set and

end testing of this section. 3. If the device does support analog outputs verify that the DUT responds by echoing the direct operate message exactly

with status field of 0. 4. Verify that the specified analog output operates.

8.4.2.2.2 Analog Output, Direct Operate, to Uninstalled Point 1. Issue a Direct Operate to Object 41 Variation 2 to an uninstalled point using 16 bit indexing (qualifier 0x28) and an

appropriate value. 2. Verify that the DUT responds by return an Error Response with IIN2-2 set and a status code of 4. 3. If an analog output is observed to operate, the test fails.

8.4.2.2.3 Analog Output, Direct Operate, Configurable Device 1. If the device is not configurable in a manner such that analog output points can be uninstalled or disabled, end testing of

Analog Output, Direct Operate. 2. Configure the DUT such that all Analog Output points are uninstalled or disabled. 3. Issue a direct operate to Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier 0x28) and an appropriate value. 4. Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set. 5. If an analog output is observed to operate, the test fails.



8.4.3.1 Desired Behavior • The DUT must not respond in any way to the direct operate no acknowledge. • If the device supports analog outputs and the operate message is correct then the analog output point must operate.


8.4.3.2.1 Analog Output, Direct Operate, No Acknowledge 1. Issue a Direct Operate No Acknowledge using Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier

0x17) and an appropriate value. 2. Verify that the DUT does not respond. 3. If the device does support analog outputs, end testing of this section. 4. If the device does support analog outputs, verify that the proper analog output point operates.

8.4.3.2.2 Analog Output, Direct Operate, No Acknowledge, to an Uninstalled Point 1. Issue a Direct Operate No Acknowledge using Object 41 Variation 2 to an uninstalled point using 16 bit indexing

(qualifier 0x28) and an appropriate value. 2. Verify that the DUT does not respond. 3. If an analog output is observed to operate, the test fails.

8.4.3.2.3 Analog Output, Direct Operate, No Acknowledge, Configurable Device 1. If the device is not configurable in a manner such that control points can be uninstalled or disabled, end testing of Analog

Output, Direct Operate, No Acknowledge. 2. Configure the DUT such that all Analog Output points are uninstalled or disabled. 3. Issue a Direct Operate No Acknowledge using Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier 0x28)

using a control code supported by the device and an appropriate on time/off time. 4. Verify that the DUT does not respond. 5. If an analog output is observed to operate, the test fails.


8.4.4.1 Desired Behavior • The DUT must parse requests for all writes within a single frame • Up to a full frame of request operations must be supported The following assumes that the device supports analog output operations and were added as a result of Technical Bulletin TB2001-001 (Multiple Control Object and Status Codes):


• The DUT responds to a select to an uninstalled analog output point by returning an error response with IIN2-2 set and a status code of 4.

8.4.4.2 Test Procedure 1. Review the device’s profile document to understand how many analog output points are supported in a single request. If

this number is one, skip to step 7. 2. Determine the number of installed points that can be successfully controlled in a single request. This number shall be the

smaller of: • The number of controls supported in a single request • The number of installed control points


• Sixteen In a single request, issue a select to the above number of points using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and a value supported by the device

3. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set and that each object returns a status code of 0. 4. Immediately issue a matching execute. 5. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set and that each object returns a status code of 0. 6. Verify that each of the selected analog outputs occurred. . Note outputs may occur simultaneously or sequentially one

after the other. 7. If the number of control objects supported in a single request is greater than or equal to either:

• The number of control objects that fit into a single frame or • The number of installed control points


different index but otherwise able to be outputted, using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28) and an appropriate value.


10. If the DUT does not support direct operate, skip to step 13. 11. In a single request, issue a direct operate command to at least one more point than is supported in a single request, each

point having a different index but otherwise able to be outputted, using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28) and an appropriate value.




8.5 Class Data

8.5.1 Class 0 This request is used to read all static data from a device. The device must respond with the current state of its data when this object is requested. § Any device that generates more than one link layer frame in response to a Class 0 Poll must support report-by-exception on all points. It is highly recommended that devices perform report by exception processing internally and respond to class polls with event data as defined in section 3.4. This allows efficient use of bandwidth. When no events are pending the device responds with the Null Response. Acceptable object variations and qualifier combinations included in a device response are specified in the following table. Numbers preceded by 0x are in hex.


Object Variation Qualifier Single-Bit Binary Input 1 1 0x00,0x01 Binary Input with Status 1 2 0x00,0x01

Binary Output Status 10 2 0x00,0x01 32-Bit Binary Counter 20 1 0x00,0x01 16-Bit Binary Counter 20 2 0x00,0x01 32-Bit Delta Counter 20 3 0x00,0x01 16-Bit Delta Counter 20 4 0x00,0x01

32-Bit Binary Counter w/o Flag 20 5 0x00,0x01 16-Bit Binary Counter w/o Flag 20 6 0x00,0x01 32-Bit Delta Counter w/o Flag 20 7 0x00,0x01 16-Bit Delta Counter w/o Flag 20 8 0x00,0x01

32-Bit Analog Input 30 1 0x00,0x01 16-Bit Analog Input 30 2 0x00,0x01

32-Bit Analog Input w/o Flag 30 3 0x00,0x01 16-Bit Analog Input w/o Flag 30 4 0x00,0x01 16-Bit Analog Output Status 40 2 0x00,0x01

Table 8-3

8.5.1.1 Desired Behavior • Device responds to a Class 0 poll with the current state of all data.

8.5.1.2 Test Procedure 1. Issue a request for Object 60 Variation 1 using the all data qualifier 0x06. 2. Verify that the device responds with the current state of its inputs using only the object, variation and qualifier variations

specified in table 8-3. 3. Verify that flag behavior complies with Section 2, Note #5.

8.5.2 Class 1 This request is used to read change or event data from a device. The device must respond with events that have occurred since the last poll/confirm sequence. If the response is not null, verify that the device requests an application layer confirm. If the response is null, the request for the application layer confirm is optional and may be eliminated to reduce bandwidth. Points can be assigned to a class by configuration and through the protocol. Neither is required for compliance. The minimum level of compliance is for the device to respond with a Null Response. § Any device that generates more than one link layer frame in response to a Class 0 Poll must support report-by-exception on all points. It is highly recommended that devices perform report by exception processing internally and respond to class polls with event data as defined in section 3.4. This allows efficient use of bandwidth. When no events are pending the device responds with the Null Response. If a device can be configured to generate Application Layer retries, this feature must be disabled for all tests in this section unless otherwise specified. Acceptable object variations and qualifier combinations included in a device response are specified in the following table. Numbers preceded by 0x are in hex.


Object Variation Qualifier Binary Input Change w/o Time 2 1 0x17,0x28 Binary Input Change with Time 2 2 0x17,0x28

Binary Input Change with Relative Time 2 3 † 0x17,0x28 32-Bit Counter Change Event w/o Time 22 1 0x17,0x28 16-Bit Counter Change Event w/o Time 22 2 0x17,0x28

32-Bit Delta Counter Change Event w/o Time 22 3 0x17,0x28 16-Bit Delta Counter Change Event w/o Time 22 4 0x17,0x28

32-Bit Analog Change Event w/o Time 32 1 0x17,0x28 16-Bit Analog Change Event w/o Time 32 2 0x17,0x28

Time and Date CTO* 51 1 0x07 Unsynchronized Time and Date CTO* 51 2 0x07

Table 8-4 † Note: Use of the Binary Change with Relative Time Object (Object 2, Variation3) requires that a Common Time of Occurrence Object (Object 51, Variation01 or 02) precede it in the same APDU. This behavior must be verified in any response that contains a Binary Change with Relative Time Object. Binary Input changes more than 0xFFFF milliseconds apart must have a second CTO Object. * Note: Common Time of Occurrence

8.5.2.1 Desired Behavior • § The device must respond with all of its change events when polled with the all data qualifier (0x06). • When polled with the limit data qualifiers (0x07 and 0x08), the device must respond with a quantity of its change events

no greater than specified in the request. • The device must request an application layer confirm for all responses that contain event data. Note: Application layer

confirms are always sent by the Master upon request from the Slave unless otherwise noted in this section. • The response point ordering shall be prioritized by time (oldest first). Note: A device is not required to return event data in any particular class.


8.5.2.2.1 Class 1 Data, 0x06 1. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 2. § Verify that if the DUT responds to a class 0 poll with more than one link layer frame it also performs report-by

exception processing. 3. If the DUT does not support Class 1 events, verify that it responds with a Null Response. No further testing is required in

this section. 4. If the DUT does support Class 1 events, verify that the device responds with all the event data in its event buffers or

responds with a Null Response. 5. If requested, issue an application layer confirm to empty the device of pending events. 6. Generate known Class 1 event data. 7. Issue another request for Object 60 Variation 2 using the all data qualifier 0x06. 8. Verify that the device responds with all the Class 1 event data generated in a single response. 9. Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first). 10. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 11. Verify that flag behavior complies with Section 2, Note #5. 12. § Verify that the device requests an application layer confirm. 13. Issue another request for Object 60 Variation 2 using the all data qualifier 0x06. 14. Verify that the DUT responds with a Null Response.


8.5.2.2.2 Class 1 Data, 0x07 1. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06 to empty the device of pending events. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events. 4. Generate several Class 1 events. 5. Issue a request for Object 60 Variation 2 using the limit data qualifier 0x07 requesting some changes. 6. Verify that the device responds with the requested Class 1 events in a single response. 7. Verify that only objects in table 8-4 are returned. 8. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 9. Verify that flag behavior complies with Section 2, Note #5. 10. § Verify that the device requests an application layer confirm. 11. Issue a request for Object 60 Variation 2 using the limit data qualifier 0x07 requesting the remaining changes. 12. Verify that device responds with the remaining Class 1 events. 13. § Verify that the device requests an application layer confirm. 14. Issue another request for Object 60 Variation 2 using the all data qualifier 0x06. 15. Verify that the DUT responds with a Null Response.


8.5.2.2.4 § Class 1 Data Without Confirm 1. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events. 4. Generate known Class 1 event data. 5. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 6. Verify that the device responds with all the Class 1 event data. 7. Verify that only objects in table 8-4 are returned. 8. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 9. Verify that flag behavior complies with Section 2, Note #5. 10. § Verify that the device requests an application layer confirm. 11. Do not issue an application layer confirm to the device. 12. Wait for a period of time exceeding several of the Application Layer retry delays, if one exists. 13. Verify that the device has not retransmitted the previous Application Layer fragment. 14. Generate additional Class 1 event data. 15. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 16. Verify that the device responds with the same Class 1 event data and the additional data generated in step 14. 17. § Verify that the device requests an application layer confirm.


18. Issue an application layer confirm to empty the device of pending events. 19. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 20. Verify that the device responds with a Null Response.

8.5.3 Class 2 This request is used to read change or event data from a device. The device must respond with events that have occurred since the last poll/confirm sequence. If the response is not null, verify that the device requests an application layer confirm. If the response is null, the request for the application layer confirm is optional and may be eliminated to reduce bandwidth. Points can be assigned to a class by configuration and through the protocol. Neither is required for compliance. The minimum level of compliance is for the device to respond with a Null Response. If a device can be configured to generate Application Layer retries, this feature must be disabled for all tests in this section unless otherwise specified. § Any device that generates more than one link layer frame in response to a Class 0 Poll must support report-by-exception on all points. It is highly recommended that devices perform report by exception processing internally and respond to class polls with event data as defined in section 3.4. This allows efficient use of bandwidth. When no events are pending the device responds with the Null Response.











8.5.5 Multiple Object Request This test verifies that the device can parse multiple object requests. Note: If Binary Inputs can be configured in more than one class, they must be configured for at least one of each class for these tests.

8.5.5.1 Desired Behavior • The device must respond to a multiple object request in a single response. • For binary points, all events reported within a single application fragment will be sent in the chronological order of

occurrence of those events (oldest first). • § When a device generates multiple analog or counter events for the same point, all events for the same point will be sent

in the chronological order of occurrence of those events (oldest first).


8.5.5.2.1 Multiple Object Request, Class 1, 2, and 3 1. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events. 4. Generate known event data that includes events from all three classes. 5. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06. 6. Verify that the device responds with all the event data as described in the Desired Behavior. 7. Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first). 8. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 9. Verify that flag behavior complies with Section 2, Note #5. 10. § Verify that the device requests an application layer confirm. 11. Issue an application layer confirm to empty the device of pending events.

8.5.5.2.2 Multiple Object Request, Class 1, 2, 3, and 0 1. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events. 4. Generate known event data that includes events from classes 1, 2, and 3. 5. Issue a request for Object 60 Variations 2,3,4, and 1 using the all data qualifier 0x06. 6. Verify that the device responds with all the event data as described in the Desired Behavior. 7. Verify that all static data is returned after all event data in the same response. 8. Verify that the response has the same application sequence number as the request. If the request generates multiple

application fragments verify that the application sequence number of each subsequent fragment increments by 1 modulo 16.

9. Verify that only objects in table 8-4 are returned. 10. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28) for event

data and 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing (qualifier 0x01) for static data. 11. Verify that flag behavior complies with Section 2, Note #5. 12. § Verify that the device requests an application layer confirm. 13. Issue an application layer confirm to empty the device of pending events.


8.5.6 Class Assignment Verification

8.5.6.1 Desired Behavior • The device must respond to a request for Class 1 events with only Class 1 events. • The device must respond to a request for Class 2 events with only Class 2 events. • The device must respond to a request for Class 3 events with only Class 3 events.

8.5.6.2 Test Procedure 1. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending events. 2. Verify that only objects in table 8-4 are returned. 3. § If the response is not Null, verify that the device requests an application layer confirm. 4. Generate some Class 1 events. 5. Generate some Class 2 events. 6. Generate some Class 3 events. 7. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 8. Verify that the device responds with only Class 1 events in a single response. 9. Verify that only objects in table 8-4 are returned. 10. § Verify that the device requests an application layer confirm. 11. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 12. Verify that the device responds with a Null Response. 13. Issue a request for Object 60 Variation 3 using the all data qualifier 0x06. 14. Verify that the device responds with only Class 2 events in a single response. 15. Verify that only objects in table 8-4 are returned. 16. § Verify that the device requests an application layer confirm. 17. Issue a request for Object 60 Variation 3 using the all data qualifier 0x06. 18. Verify that the device responds with a Null Response. 19. Issue a request for Object 60 Variation 4 using the all data qualifier 0x06. 20. Verify that the device responds with only Class 3 events in a single response. 21. Verify that only objects in table 8-4 are returned. 22. § Verify that the device requests an application layer confirm. 23. Issue a request for Object 60 Variation 4 using the all data qualifier 0x06. 24. Verify that the device responds with a Null Response. 25. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06. 26. Verify that the device responds with a Null Response.

8.6 Indications The Internal Indications is an information element used to convey internal states and diagnostic results of a device. If a specific indication is not supported it must be reported as de-asserted (0) in all cases.

8.6.1 Restart The Restart Bit of the Internal Indications field is set to 1 when the user application at the device restarts, i.e. a device's input power is cycled. This bit is cleared when the master station writes a 0 into this location.

8.6.1.1 Desired Behavior • The DUT, after a power cycle, must set IIN1-7. • The host can clear this bit by writing to the Internal Indications Object (Object 80, Variation 01).

8.6.1.2 Test Procedure 1. Cycle the power to the DUT. 2. Issue a request for Object 60 Variation 2. 3. Verify that the device responds with IIN1-7 set indicating that the device has been restarted.


4. Issue a Write to Object 80 Variation 1 using the qualifier 0x00. Use a start index of 7 and a stop index of 7, followed by the value 0.

5. Verify that the device responds with a Null Response and that IIN1-7 is cleared.

8.6.2 Bad Function

8.6.2.1 Desired Behavior • If a device receives a message containing an unsupported function code it must return an Error Response with IIN2-0 set. • After a device has issued a message containing a valid function code, the response shall have no Error IIN bits set.

8.6.2.2 Test Procedure 1. Issue a request for Object 60 Variation 1, Qualifier 0x06, using a Function Code of 0x70. 2. Verify that the device responds with an Error Response with IIN2-0 set indicating that the device has received a message

containing a bad function code. 3. Issue a request for Object 60 Variation 1, Qualifier 0x06, using a Function Code of 0x01. 4. Verify that the device responds with none of the Error IIN bits set.

8.6.3 Object Unknown

8.6.3.1 Desired Behavior • If a device receives a message containing an unknown object, it must return an Error Response with IIN2-1 set. • After a device has issued a message containing a valid function code, the response shall have no Error IIN bits set.

8.6.3.2 Test Procedure 1. Issue a request for Object 0 Variation 0, Function Code 0x01. 2. Verify that the device responds with an Error Response with IIN2-1 set indicating that the device has received a message

containing an unknown Object code. 3. Issue a request for Object 60 Variation 1. 4. Verify that the device responds with none of the Error IIN bits set.

8.6.4 Local

8.6.4.1 Desired Behavior • If the device supports control outputs and supports placing them in a local or disabled stated then it must set IIN1-5

whenever some or all of the control outputs are in the Local or Disabled state.

8.6.4.2 Test Procedure for Devices with Global Remote Supervisory Control 1. If the DUT does not support placing its binary outputs in a local state no further testing is required in this section. 2. If the DUT supports a global feature for enabling or disabling remote supervisory control, ensure that this is set to the

“Enabled” or “Remote” mode. 3. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 4. Verify that the device responds with a valid message and that IIN1-5 is cleared. 5. Change the DUT’s global switch to the “Disabled” or “Local” mode. 6. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 7. Verify that the device responds with a valid message and that IIN1-5 is set.

8.6.4.3 Test Procedure for Devices with Individual Remote Supervisory Control 1. If the DUT does not support placing its binary outputs in a local state, no further testing is required in this section.


2. If the device allows for individual control point remote supervisory control, all points should be set to the “Enabled” or “Remote” mode.

3. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 4. Verify that the device responds with a valid message. No binary output status bits should be set. 5. Change a single remote supervisory control switch to the “Disabled” or “Local” mode. 6. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 7. Verify that the device responds with a valid message and that the appropriate binary output status bit is set.

8.6.5 Broadcast Address and All Stations Indication

8.6.5.1 Desired Behavior The DUT must execute any request sent to the broadcast address •

• • • •

•

§ The DUT must not respond in any way to any request sent to the broadcast address The DUT must set the All Stations Internal Indication (IIN1-0) in the next response it transmits The DUT must clear the All Stations Internal Indication on the next response following the one in which it was set. § Messages sent to address 0xFFFE require that the IIN1-0 bit must be returned with the application layer request for confirmation bit (Application Control, bit 5) set. IIN1-0 may not be cleared in the slave until the confirmation is received. § Messages sent to address 0xFFFD request the IIN1-0 bit to be returned with the application layer request for confirmation bit (Application Control, bit 5) suppressed. IIN1-0 will be cleared in the slave upon transmitting the first response from the slave. Note: IIN1-0 may be reported in conjunction with responses to requests that otherwise require confirmation, or with an unsolicited event report, and since these requests/responses otherwise require confirmation, the confirmation will not be suppressed even though the message is sent with IIN1-0 set. Thus the use of the FFFD broadcast address implies that confirmation requests in responses sent with the IIN1-0 set should be suppressed, but that the confirmation may be requested if required by the details of the response being issued.

8.6.5.2 § Test Procedure 1. Cycle the power to the DUT. 2. Issue a link reset using link control block 0xC0. 3. Issue a request for Object 60 Variation 2. 4. Verify that the device responds with IIN1-7 set indicating the device has been restarted. 5. Issue a Write to Object 80 Variation 1 using the qualifier 0x00. Use a start index of 7 and a stop index of 7, followed by

the value 0 using the broadcast address (0xFFFF). Request a data link layer confirmation. 6. Wait a reasonable application layer timeout, for example, 2 seconds. 7. Verify that the device does not respond, with either a data link layer confirmation or a response to the Write operation. 8. Issue a request for Object 60 Variation 2. 9. Verify the DUT responds with a valid response with IIN1-7 (restart) cleared and IIN1-0 (all stations message received)

set. 10. Send an application layer confirmation if requested. 11. Issue a request for Object 60 Variation 2. 12. Verify the DUT responds with a Null Response with both IIN1-7 and IIN1-0 cleared.

8.6.5.3 Test Procedure 1. Issue a Direct Operate No Acknowledgement using Object 12 Variation 1 to an installed point using 8-bit indexing

(qualifier 0x17), a control code supported by the device and an appropriate on/off-time using the broadcast address (0xFFFF). If the device does not support control outputs, perform this operation using Object 41 Variation 2.

2. Verify the requested output operation was executed. 3. Wait a reasonable application layer timeout, for example, 2 seconds. 4. Verify that the device does not respond. 5. Issue a request for Object 60 Variation 2. 6. Verify the DUT responds with IIN1-0 (all stations message received) set. 7. Send an application layer confirmation if requested. 8. Issue a request for Object 60 Variation 2. 9. Verify the DUT responds with a Null Response with IIN1-0 cleared.


8.6.5.4 § Test Procedure, Confirmed Response Options 1. Cycle the power to the DUT. 2. Issue a link reset using link control block 0xC0. 3. Issue a request for Object 60 Variation 2. 4. Verify that the device responds with IIN1-7 set indicating the device has been restarted. 5. Issue a Write to Object 80 Variation 1 using the qualifier 0x00. Use a start index of 7 and a stop index of 7, followed by

the value 0. Specify broadcast address FFFE. Request a data link layer confirmation. 6. Wait a reasonable application layer timeout, for example, 2 seconds. 7. Verify that the device does not respond, with either a data link layer confirmation or a response to the Write operation. 8. Issue a request for Object 60 Variation 2. 9. Verify the DUT responds with a Null Response with IIN1-7 (restart) cleared and IIN1-0 (all stations message received)

set, and an application layer confirmation requested. 10. Before sending the requested confirmation, repeat the request for Object 60 Variation 2, and verify that IIN1-0 is still set

in the response. 11. Send the application layer confirmation. 12. Issue a request for Object 60 Variation 2. 13. Verify the DUT responds with a Null Response with both IIN1-7 and IIN1-1 cleared. 14. Repeat steps 1-13 using address FFFD as the broadcast address. In step 9, verify that an application layer confirmation is

NOT requested. In step 10, verify that IIN1-0 is not set in the response. Note: Step 11 will not be necessary.

8.6.6 Buffer Overflow The Buffer Overflow Bit of the Internal Indications field is set to 1 when any event buffers overflow such that change event data is subsequently being lost. This bit is cleared when the master station confirms change event data from the DUT, hence making event buffer space available.

8.6.6.1 Desired Behavior • The DUT must set IIN2-3 after a given event buffer overflows such that change events are being lost. • The DUT must clear IIN2-3 after a master confirms a change event(s) from the DUT such that event buffer space is

made available.


8.6.6.2.1 Buffer Overflow, Binary Input Change Event Buffers 1. If the device does not support Binary Input Change Events, end testing of Buffer Overflow, Binary Input Change Event

Buffers. 2. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending events. 3. Obtain the maximum Binary Input Change Event buffer size from the device documentation and generate this number of

corresponding events on the DUT. 4. Issue a request for Object 60 Variation x (appropriate Class) using the all data qualifier 0x06, but DO NOT issue an

application confirm to the device. 5. Verify that IIN2-3 is NOT set. 6. Generate 1 additional change event of this type on the DUT. 7. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 8. Verify that the device returns a single Binary Input Change Event and IIN2-3 is set. 9. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 10. Verify that the device returns a single Binary Input Change Event and IIN2-3 is not set.

8.6.6.2.2 Buffer Overflow, Analog Input Change Event Buffers 1. If the device does not support Analog Input Change Events, or does not queue multiple events for the same point, end

testing of Buffer Overflow, Analog Input Change Event Buffers. 2. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending events.


3. Obtain the maximum Analog Input Change Event buffer size from the device documentation and generate this number of corresponding events on the DUT.

4. Issue a request for Object 60 Variation x (appropriate Class) using the all data qualifier 0x06, but DO NOT issue an application confirm to the device.

5. Verify that IIN2-3 is NOT set. 6. Generate 1 additional change event of this type on the DUT. 7. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 8. Verify that the device returns a single Analog Input Change Event and IIN2-3 is set. 9. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 10. Verify that the device returns a single Analog Input Change Event and IIN2-3 is not set.

8.6.6.2.3 Buffer Overflow, Binary Counter Change Event Buffers 1. If the device does not support Binary Counter Change Events, or does not queue multiple events for the same point, end

testing of Buffer Overflow, Binary Counter Change Event Buffers. 2. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending events. 3. Obtain the maximum Binary Counter Change Event buffer size from the device documentation and generate this number

of corresponding events. 4. Issue a request for Object 60 Variation x (appropriate Class) using the all data qualifier 0x06, but DO NOT issue an

application confirm to the device. 5. Verify that IIN2-3 is NOT set. 6. Generate 1 additional change event of this type. 7. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 8. Verify that the device returns a single Binary Counter Change Event and has set IIN2-3. 9. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 10. Verify that the device returns a single Binary Counter Change Event and IIN2-3 is no longer set.

8.7 Time § If the device sets IIN1-4, the Device Profile must state the worst case values for the following parameters for the full operating temperature and support all of the tests in this section. • Time base drift over a 10-minute interval. • Maximum delay measurement error. • Maximum internal time reference error when set from the protocol. • Maximum response time. If a device does not set IIN1-4 it need not support any of the tests in this section.

8.7.1 Delay Measurement This function is used to calculate the communication delay for a particular device. The device will respond to a Time Delay Measurement request with the number of milliseconds elapsed between the device receiving the first bit of the first byte of the request and the time of transmission of the first bit of the first byte of the response.

8.7.1.1 Desired Behavior • § The device must respond to a Delay Measurement request with a Time Delay Fine response.

8.7.1.2 Test Procedure 1. Issue a request for Delay Measurement using Function Code 23, to the DUT. 2. Verify that the device replies with Object 52 Variation 2 Qualifier 0x07 Quantity 1 and a millisecond time stamp of the

measured delay. 3. Verify that the accuracy of the delay reported is within the maximum error specified in the Device Profile Document. 4. Perform the test two more times to guarantee repeatability.


8.7.2 Synchronization The Time and Date Object (Object 50 Variation 01) is an information object that represents the absolute time of day and date, recorded as milliseconds since midnight, January 1, 1970, at zero minutes, zero seconds, and zero milliseconds. This object is usually used for time-synchronization. Note that the following procedures verify the mechanics of time synchronization, verify that the time format is correct, and that synchronization appears to have occurred. The actual accuracy of time synchronization is dependent on device accuracy and system configuration and should be tested separately (factory and/or site acceptance tests).

8.7.2.1 Desired Behavior • The device must respond to a Time and Date object by null response with IIN1-4 cleared. • § The Device Profile must specify the maximum time from startup to IIN1-4 assertion.

8.7.2.2 Test Procedure 1. Reset the DUT. 2. Wait the specified maximum time from reset to IIN1-4 assertion. 3. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 4. Verify that the device responds with a valid message and that IIN1-4 is set indicating that the device is requesting time

synchronization. 5. Set the time and date using a WRITE request and Object 50 Variation 1 with Qualifier 0x07 taking into account the

delay measured in the previous section. 6. Verify that the device responds with a Null Response and that IIN1-4 is cleared indicating the device no longer needs

time. 7. Generate a supported time tagged event at a known time. 8. Issue a request for Object 60 Variation 2, 3, or 4 as appropriate, using the all data qualifier 0x06. 9. Verify that the device responds with a valid time tagged event and that the time reported is within the maximum error

specified in the Device Profile Document.

8.8 Cold Restart

8.8.1 Desired Behavior • The device must respond to a Cold Restart request by sending a Time Delay response, restarting, and setting IIN1-7.

8.8.2 Test Procedure 1. Issue a request for Cold Restart using Function Code 13, to the DUT. 2. Verify the response is a Time Delay Fine or Coarse (Object 52 Variation 1 or Variation 2). 3. If the DUT requests an Application Layer Confirm send it before starting the wait period. 4. Wait for a period of time longer than the time returned in step 2. 5. Issue a request for Object 60 Variation 1. 6. Verify that the device responds with IIN1-7 set indicating that the device has been restarted. 7. Issue a Write using Object 80 Variation 1 with the qualifier 0x00. Use a start index of 7 and a stop index of 7, followed

by the value 0. 8. Verify that the device responds with a Null Response and that IIN1-7 is cleared.

8.9 Application Layer Fragmentation

8.9.1 Use of FIR, FIN and SEQUENCE in Fragmentation

8.9.1.1 Desired Behavior If the DUT can generate enough data to create multiple application layer fragments, it must meet the following criteria: DNP3-2001 IED Certification Procedure Page 43 Subset Level 1 Rev 2.1 – 5-July-01

The application layer FIR bit must be set in the first fragment (only). •

• • • • • • •

• •

•

The application layer FIN bit must be set in the final fragment (only). The application layer sequence number of the first fragment must match that of the request. The application layer sequence number must increment between fragments. Transport layer segmentation must operate correctly within each fragment. The fragment size must be able to be configured to be no larger than 2048 octets. If the fragment size is configurable, it must behave accordingly. If the device cannot generate more than one fragment, the FIR and FIN bits in the application layer header must signify that there is only one APDU in the reply.

8.9.1.2 Test Procedure 1. If the DUT has a configurable fragment size, configure it to be no more than 2048 octets. 2. Cycle power to the DUT. 3. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06, if this will generate a multi-fragment response.

Alternately, generate enough event data to fill more than one fragment and request the appropriate class of data with Qualifier Code 0x06.

4. Verify that the DUT responds with valid data. 5. Verify that the sequence number of the first fragment matches the request. 6. Verify that each fragment of the response contains no more than the configured fragment size. 7. If the DUT’s reply contains only a single fragment then verify the FIR bit is set to one and the FIN bit is also set to one.

If there is no way to cause the DUT to generate multiple fragments, i.e. its Class 0 response is less than a fragment and it does not support event data, no further testing is required in the Application Layer Fragmentation section.

8. If the DUT’s reply contains more than one fragment then verify that the first response message sets the FIR bit to a one, the FIN bit is set to zero.

9. Verify subsequent fragments to assure that the FIR bit is zero, the FIN bit is zero, and the sequence number increments by one.

10. Verify that the last fragment has the FIR bit cleared and the FIN bit set, signifying the last data fragment. 11. Verify each fragment is properly segmented by the transport layer as described in that section of this document. 12. If the DUT’s fragment size is configurable, repeat this test with a different fragment size and verify the data for each

fragment does not exceed the configured size.

8.9.2 § Use of Confirmation in Fragmentation

8.9.2.1 § Desired Behavior The DUT must request an application layer confirmation between fragments. The DUT must not send subsequent fragments until it receives confirmation of the previous fragment, with a correct sequence number. The DUT must not send subsequent fragments if it does not receive a valid confirmation within a timeout.

NOTE: The DUT is not required to request application layer confirmation on the last fragment of a response (unless required for other reasons tested elsewhere in this document).

8.9.2.2 § Test Procedure 1. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06, if this will generate a multi-fragment response.


2. Verify that the DUT responds with valid data. 3. Verify that the CON bit is set in the first fragment. 4. Verify the sequence number matches the request. 5. Wait the application confirmation timeout for the DUT. Do not send an application confirmation. 6. Verify the DUT does not send the next fragment because it did not receive confirmation of the first fragment.


7. Send the valid application layer confirmation. 8. Verify the DUT does not send the next fragment because it has timed out. 9. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06, if this will generate a multi-fragment response.


10. Verify that the CON bit is set in the first fragment. 11. Wait a time period less than the application confirmation timeout. Verify the DUT does not send the second fragment

yet. 12. Send the valid application layer confirmation before the application confirmation timeout. 13. Verify that the DUT sends the second fragment (with FIR, FIN and sequence number set correctly). 14. Verify that the CON bit is set in the second fragment. 15. If a third fragment is expected, continue. If not, first send a valid application layer confirmation and then a request for

multi-fragment data as in steps 1-3. 16. Send an application layer confirmation with an incorrect sequence number. 17. Wait the application layer confirmation timeout for the DUT. Do not send an application confirmation. 18. Verify the DUT does not send the next fragment because the confirmation it received was invalid. 19. Send the valid application layer confirmation. 20. Verify the DUT does not send the next fragment because it has timed out.

8.10 Multi-Drop Support

8.10.1 Desired Behavior • The DUT must only respond to requests when the destination address field of the link layer portion of the request

matches its assigned DNP address. • The DUT must remain silent in all other cases. This includes not raising carrier (e.g. asserting RTS) during periods in

which it is not responding.

8.10.2 Test Procedure 1. If the DUT does not support multi-drop physical layers, this must be noted on the Implementation Conformance

Statement and in the Device Profile Document. No further testing is required in this section. 2. Connect the DUT and at least two additional DNP devices to the same communications drop. 3. Connect an oscilloscope and/or protocol analyzer to the DUT communications signals. 4. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to each of the other devices on the

communications channel. 5. Verify that the DUT does not respond in any way, including raising carrier or asserting RTS. 6. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to the broadcast address. 7. Verify that the DUT does not respond in any way, including raising carrier or asserting RTS. 8. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to the DUT. 9. Repeat as necessary to verify that the DUT responds in an appropriate manner for the physical layer which may include:

a) Raising carrier (or asserting RTS) an appropriate period of time before transmitting the first bit of data. b) Dropping carrier (or de-asserting RTS) an appropriate period of time after transmitting the last bit of data. c) If the pre and post RTS to transmit delay parameters are configurable, repeat this test for the lower of the two

following cases. i) the total number of selections or ii) the minimum, maximum, and two intermediate values

8.11 Unsolicited Responses Support for unsolicited responses is optional. If a device does not support unsolicited responses, this section may be skipped in its entirety.


Although unsolicited responses may be used with collision avoidance, the two features are independent. For instance, a device might not support collision avoidance, but support unsolicited responses in a dial-up environment. Therefore, all that is needed to test unsolicited responses is a full-duplex serial connection to the DUT.

8.11.1 Desired Behavior

8.11.1.1 Configuration Devices that support unsolicited responses must support end-user configuration of the following parameters (e.g.: by front-panel user interface or off-line configuration):

The destination address of the Master device to which the unsolicited responses are to be sent. • •

•

•

•

The unsolicited response mode (either “on” or “off”). When the unsolicited response mode is configured “off”, the device is to behave exactly like an equivalent device that has no support for unsolicited responses.

• § The unsolicited confirmation timeout. This is the amount of time between transmissions of unconfirmed unsolicited responses. The range of configurable values must include 1 second to 1 minute, but may be extended in either direction (slower or faster) to take advantage of, or to compensate for, faster or slower devices or communications media. This may be either the normal application confirmation timeout, or another parameter that performs the same purpose only for unsolicited responses.

• § Maximum number of unsolicited retry attempts. One of the choices must provide for an indefinite (and potentially infinite) number of retries.

8.11.1.2 Sequence Numbers and Confirmation At all times:

Application layer sequence numbers (the value of bits 0–4 of the application layer control field) must be in the correct range for all messages sent: 0–15 for polled responses and 16–31 for unsolicited responses.

• Ignore Master device application layer confirmations of unsolicited responses if their sequence numbers do not match those of the corresponding unsolicited responses.

• § All unsolicited response messages must request application layer confirmation, regardless of whether they are null (no data) or contain data.

8.11.1.3 Restart Behavior If the unsolicited response mode is configured “on,” then upon device restart: • The device must transmit an initial unsolicited response message. • The initial unsolicited response message must have the restart bit (IIN1-7) set if the Master has not already sent a

command to clear it. • § The initial unsolicited response message must be null; i.e., it must not contain static or event data objects. • § The initial unsolicited response message must request an application layer confirmation, regardless of whether the

message has the restart bit (IIN1-7) set. • § The device must continue to transmit initial null unsolicited responses at the rate set by the unsolicited confirmation

timeout, until that initial unsolicited response message is confirmed. • § The device must respond to all function requests to which it would normally respond, including READ function

requests, while waiting for the confirmation of the initial unsolicited response. • § The device must not send any more unsolicited responses after the initial null unsolicited response message has been

confirmed, until a function code 0x14 (enable data-filled unsolicited messages) request has been received.

8.11.1.4 Runtime Behavior Once an initial unsolicited response message has been confirmed, then the device must:

§ Process function code 0x14 requests (to enable data-filled unsolicited messages). This enabled status must not be retained through a device restart; i.e. data-filled unsolicited messages are always disabled on restart. § Process function code 0x15 requests (to disable data-filled unsolicited messages). This disabled status does not apply to initial null unsolicited responses; i.e., if function code 0x15 is requested, and if no off-line configuration is altered, then after restart, an initial unsolicited response message must again be transmitted.


§ At a minimum, support the enabling and disabling of unsolicited responses for Class 1, 2, and 3 data. Even if the device does not have Class 1, Class 2, or Class 3 data, it must respond to function codes 0x14 and 0x15, object 60, and variations 2, 3 and 4 without error responses.

•

• •

Only send unsolicited responses for those classes of data that have been enabled. Unsolicited response messages must contain only the following kinds of data: ! event data, or ! static data for which no event object types exist: binary output status (Object 10 Variation 2) and analog output

status (Object 40 Variation 2). Note, when static data is returned in unsolicited responses, the rules for event processing still apply as specified in section 3.4.

8.11.1.5 Unsolicited and Polled Responses • If an unsolicited response message containing event data is not confirmed, the device must timeout, retain the event data,

and re-transmit the event data either in subsequent unsolicited response messages or in polled response messages. The event data does not have to be re-transmitted exactly (new change events may have occurred, or, for example, analog input change events may be updated to reflect new current values of analog inputs).

• Once an unsolicited response message containing event data is confirmed, the event data must be cleared from the device and no longer transmitted in subsequent unsolicited or polled responses.

• The device cannot generate unsolicited responses if it is waiting for an application confirmation to a previous polled or unsolicited response.

• If a non-READ function code request is received while waiting for a confirmation of an unsolicited response, the device must immediately process it.

• § If a READ function code request is received while waiting for a confirmation of an unsolicited response, the device must defer responding to the READ request (the READ request is therefore “pending”) until after either the unsolicited confirmation timeout occurs, or the confirmation of the unsolicited response is received.

• § The device cannot generate an additional unsolicited response until it has responded to a pending READ request. • § If a READ function code request is pending while waiting for a confirmation of an unsolicited response, and another

(new) function code request is received, the original READ function code request must be abandoned (with no response transmitted), and the new function code should be processed according the desired behavior rules of this section.

8.11.2 Test Procedure Unless explicitly specified by the tests in these sections, do not issue any requests to the DUT, including: requests to clear the restart bit (IIN1-7); READ requests for data; application layer confirmations and requests to enable or disable unsolicited responses. Similarly, do not allow the Master being used to test the device to issue any of these requests automatically.

8.11.2.1 Unsolicited Response Configuration/Startup 1. Verify that the DUT has off-line capability to configure the unsolicited response mode (either “on” or “off”). Use this

capability to configure the unsolicited response mode to “on.” 2. § Verify the DUT has off-line capability to configure the unsolicited confirmation timeout. Verify that it can be set to at

least as small as 1 second, and to at least as large as 1 minute. 3. For the remainder of Section 8.11.2.1, set this time to be 5 seconds. (The value of 5 seconds is arbitrary, and is used to

simplify the description and execution of this test. As a further simplification for the purposes of this test, when the test steps below exercise and rely upon this value, measurement accuracy can be within 0.5 seconds. It is not the purpose of this test to verify the full range of this parameter, nor is it the purpose of this test to verify the accuracy of the time keeping capability of the DUT. It is the purpose of this test, however, to verify that the parameter has been implemented.)

4. Verify the DUT has off-line capability to configure the destination address of the Master device to which unsolicited responses are to be sent. Use this capability to configure a specific destination address.

5. Cycle power to the DUT. 6. Verify that the DUT transmits an initial unsolicited response to the configured Master destination address. 7. Use the off-line configuration capability to configure the destination address to a different destination address. 8. Cycle power to the DUT. 9. Verify that an initial unsolicited response is transmitted by the DUT. 10. Verify that the unsolicited response contains the restart bit (IIN1-7) set. DNP3-2001 IED Certification Procedure Page 47 Subset Level 1 Rev 2.1 – 5-July-01

11. § Verify that the unsolicited response is null (contains no data). 12. § Verify that the unsolicited response requests an application layer confirmation. 13. Verify that the application sequence number is in the correct range. 14. Verify that it has been transmitted to the configured Master destination address. 15. Wait at least 10 seconds, and verify that two or more unsolicited responses are transmitted by the DUT. Verify that these

new unsolicited responses are transmitted no more often, and no less often, than once every 5 seconds. 16. Verify that the restart bit (IIN1-7) remains set in these unsolicited responses. 17. § Verify that the unsolicited responses are null (contains no data). 18. § Verify that the unsolicited responses request application layer confirmations. 19. Issue a request to clear the restart bit (IIN1-7). 20. Verify that the DUT responds with a null response that has the restart bit (IIN1-7) cleared. 21. Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT. 22. Verify that the restart bit (IIN1-7) is clear in the unsolicited responses. 23. Issue a READ request (function code 0x01) for Object 60 Variation 1 (class 0) using the all data qualifier 0x06. 24. § Verify that the DUT responds to the READ request with class 0 data. 25. Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT. 26. Issue an application layer confirmation of the unsolicited response, but use an incorrect application-layer sequence

number. 27. Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT. 28. Issue an application-layer confirmation of the unsolicited response, and use the correct application-layer sequence

number. 29. Generate known events. 30. § Verify that no further unsolicited responses are transmitted by waiting for such responses for at least 5 seconds.

8.11.2.2 Unsolicited Response - Class 1 Data 1. Issue a request to disable unsolicited responses for all classes of data by using function code 0x15 with three object data

headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 2. Verify that the DUT responds with a null response indicating the request was processed without error. 3. If the DUT has Class 1 data, generate such data. For example, if there is a binary input change event that is (or can be

assigned to) Class 1, then ensure that it is assigned to Class 1, and generate one such event. 4. Verify that no unsolicited responses are transmitted by waiting for such responses for a length of time at least as great as

what would be necessary for the DUT to otherwise generate an unsolicited response. 5. Issue a request to enable unsolicited responses for Class 1 data by using function code 0x14, object 60, Variation 2. 6. Verify that the DUT responds with a null response indicating the request was processed without error. 7. If it is not possible to generate Class 1 data that would generate unsolicited responses, steps 8 through 14 are not

applicable. 8. Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT

and specified by the DUT’s Device Profile Document, within which the DUT may wait for a minimum number of events to be collected before transmission of an unsolicited message.

9. Verify that the unsolicited response requests an application layer confirmation. 10. Verify that the application sequence number is in the correct range. 11. Without issuing an application layer confirmation, wait for the unsolicited confirmation timeout to expire, and verify that

another unsolicited response is transmitted by the DUT. 12. Verify that at least the same event data is present in the unsolicited response. (It is not required that the unsolicited

responses be identical. For data such as analog input change events, the data may be updated to reflect current values. It is also possible for new event data to have been generated.)

13. Issue an application layer confirmation of the unsolicited response, but use an incorrect application-layer sequence number.

14. Wait for the unsolicited confirmation timeout to expire, and verify that another unsolicited response is transmitted by the DUT, still containing the same event data.

15. Issue an application-layer confirmation of the unsolicited response, and use the correct application-layer sequence number.

16. If the DUT has Class 2 data, then generate such data. If the DUT has Class 3 data, then also generate Class 3 data.


17. Verify that no further unsolicited responses are transmitted by waiting for such responses for a length of time at least as great as what would be necessary for the DUT to otherwise generate an unsolicited response.




what would be necessary for the DUT to otherwise generate an unsolicited response. 5. Issue a request to enable unsolicited responses for Class 2 data by using function code 0x14, Object 60, Variation 3. 6. Verify that the DUT responds with a null response indicating the request was processed without error. 7. If it is not possible to generate Class 2 data that would generate unsolicited responses, steps 8 through 14 are not




another unsolicited response is transmitted by the DUT. 12. Verify that at least the same event data is present in the unsolicited response. (It is not required that the unsolicited





16. If the DUT has Class 1 data, then generate such data. If the DUT has Class 3 data, then also generate Class 3 data. 17. Verify that no further unsolicited responses are transmitted by waiting for such responses for a length of time at least as

great as what would be necessary for the DUT to otherwise generate an unsolicited response.




what would be necessary for the DUT to otherwise generate an unsolicited response. 5. Issue a request to enable unsolicited responses for Class 3 data by using function code 0x14, Object 60, Variation 4. 6. Verify that the DUT responds with a null response indicating the request was processed without error. 7. If it is not possible to generate Class 2 data that would generate unsolicited responses, steps 8 through 14 are not




another unsolicited response is transmitted by the DUT.


12. Verify that at least the same event data is present in the unsolicited response. (It is not required that the unsolicited responses be identical. For data such as analog input change events, the data may be updated to reflect current values. It is also possible for new event data to have been generated.)




16. If the DUT has Class 1 data, then generate such data. If the DUT has Class 2 data, then also generate Class 2 data. 17. Verify that no further unsolicited responses are transmitted by waiting for such responses for a length of time at least as


8.11.2.5 Unsolicited and Polled Responses This is a complicated test procedure. The test has been divided into sections for clarity.

8.11.2.5.1 Transmits data-filled unsolicited responses 1. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object data

headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 2. Verify that the DUT responds with a null response indicating the request was processed without error. 3. Generate class 1, 2, or 3 event data. 4. Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT


5. Verify that the unsolicited response requests an application layer confirmation.

8.11.2.5.2 Clears transmitted data upon confirmation 1. Issue an application-layer confirmation of the unsolicited or polled response. 2. Issue a READ request (function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06. 3. Verify that none of the event data transmitted by the unsolicited response is contained in the polled response.

8.11.2.5.3 Processes non-READ requests immediately 1. Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited

response to be sent. 2. Without issuing an application layer confirmation, issue a function code request other than READ (for example, function

code 0x02 – WRITE to clear the restart flag IIN1-7). 3. Verify that the DUT immediately responds without error. 4. Wait for the unsolicited confirmation timeout to expire, and verify that another unsolicited response is transmitted by the

DUT. 5. Verify that the event data in this unsolicited response includes the events reported in the previous unsolicited response

that was not confirmed. It is not required that the unsolicited responses be identical. For data such as analog input change events, the data may be updated to reflect current values. It is also possible for new event data to be generated.

8.11.2.5.4 Defers READ requests until after confirmation received 1. Immediately after the unsolicited response, and without issuing an application layer confirmation, issue a READ request

(function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06. 2. Wait for an amount of time less than the unsolicited confirmation timeout and verify that the DUT does not respond. 3. Issue an application-layer confirmation of the unsolicited response before the unsolicited confirmation timeout occurs. 4. Verify that the device immediately transmits a response to the READ request. 5. Verify that none of the event data transmitted by the unsolicited response is contained in the polled response. 6. If the polled response requested an application layer confirmation, then issue an application-layer confirmation of the

polled response.


8.11.2.5.5 Defers READ requests until after confirmation timeout 1. Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited

response to be sent. 2. Immediately after the unsolicited response, and without issuing an application layer confirmation, issue a READ request

(function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06. 3. Verify that the DUT does not respond within the unsolicited confirmation timeout. 4. After the unsolicited confirmation timeout, verify that the device responds with a polled response to the READ request

(and not an unsolicited response). 5. Verify that the polled response contains at least the same event data that was in the unsolicited response that was not

confirmed. 6. Verify that the polled response requests an application layer confirmation. 7. Issue an application-layer confirmation of the polled response to clear the device of event data. 8. Verify that no further unsolicited responses are transmitted by waiting for such responses for a length of time at least as


8.11.2.5.6 Abandons READ requests upon subsequent non-READ requests 1. Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited

response to be sent. 2. Immediately after the unsolicited response, and without issuing an application layer confirmation, issue a READ request

(function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06. 3. Before the unsolicited confirmation timeout, issue a function code request other than READ (for example, function code

0x02 – WRITE to clear the restart flag IIN1-7). 4. Verify that the DUT immediately responds without error. 5. Wait for the unsolicited confirmation timeout to expire, and then verify that another unsolicited response is transmitted

by the DUT. 6. Verify that the event data in this unsolicited response includes the events reported in the previous unsolicited response

that was not confirmed.

8.11.2.5.7 Abandons READ requests upon subsequent READ requests 1. Immediately after the unsolicited response, and without issuing an application layer confirmation, issue a READ request

(function code 0x01) for Object 60 Variation 1 using the all data qualifier 0x06. 2. Before the unsolicited confirmation timeout, issue a READ request for Object 60, Variations 2, 3, and 4, using the all

data qualifier 0x06. 3. Verify that the DUT does not respond within the unsolicited confirmation timeout. 4. After the unsolicited confirmation timeout, verify that the device responds with a polled response to the Object 60,

Variation 2, 3, and 4 READ request (and not an unsolicited response). 5. Verify that the polled response is a response to the request for Object 60, Variations 2, 3, and 4 – not Variation 1; in

other words, verify that it contains class 1, 2, or 3 data and not class 0 data. 6. Verify that the polled response contains at least the same event data that was in the unsolicited response that was not

confirmed. 7. Verify that the polled response requests an application layer confirmation. 8. Issue an application-layer confirmation of the polled response to clear the device of event data. 9. Verify that no further unsolicited responses are transmitted by waiting for such responses for a length of time at least as


8.11.2.5.8 Inhibits Unsolicited responses until after polled confirmation 1. If the device has a minimum amount of event data that will cause the immediate transmission of an unsolicited response,

then generate at least some, but less than this amount of class 1, 2, or 3 event data. Or, if there is a window of time between the generation of event data and the subsequent transmission of an unsolicited response, then generate event data and perform the next test procedure step before this time elapses. If neither of these procedures are possible, then the remaining steps in this procedure are not applicable.

2. Before an unsolicited response is transmitted, issue a READ request (function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06.


3. Verify that events are reported in the response to the READ request 4. Verify that the polled response requests an application layer confirmation. 5. Do not send an application layer confirmation. 6. If necessary, generate more event data that would otherwise cause the transmission of an unsolicited response. 7. Verify that the DUT does not transmit an unsolicited response within the application confirmation timeout, nor before

any application layer retries are attempted. 8. After the application confirmation timeout, and after any application layer retries, verify that the device responds with an

unsolicited response. 9. Verify that the unsolicited response contains at least the same event data that was in the polled response that was not

confirmed. 10. Verify that the unsolicited response requests an application layer confirmation. 11. Issue an application-layer confirmation of the unsolicited response to clear the device of event data.

8.11.2.5.9 Retries unsolicited responses configurable number of times 1. Verify the DUT has off-line capability to configure the maximum number of unsolicited retries and that one of the

choices causes the DUT to retry indefinitely. Use this capability to configure the maximum number of retries to 5. 2. Cycle power to the DUT. 3. Issue an application-layer confirmation of the initial unsolicited response. 4. Issue a request to clear the restart bit (IIN1-7). 5. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object data

headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 6. Verify that the DUT responds with a null response indicating the request was processed without error. 7. Generate class 1, 2, or 3 event data. 8. Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT


9. Do not issue an application layer confirm. 10. Verify that DUT retries the response 5 times. 11. Cycle power to the DUT. 12. Issue an application-layer confirmation of the initial unsolicited response. 13. Issue a request to clear the restart bit (IIN1-7). 14. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object data

headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 15. Verify that the DUT responds with a null response indicating the request was processed without error. 16. Generate class 1, 2, or 3 event data. 17. Verify that an unsolicited response is transmitted. 18. Issue an application layer confirm after at least one retry. Verify that retries are terminated when confirmation is

received. 19. Configure the maximum number of retries to indefinite. 20. Cycle power to the DUT. 21. Issue an application-layer confirmation of the initial unsolicited response. 22. Issue a request to clear the restart bit (IIN1-7). 23. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object data

headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 24. Verify that the DUT responds with a null response indicating the request was processed without error. 25. Generate class 1, 2, or 3 event data. 26. Verify that an unsolicited response is transmitted. 27. Do not issue an application layer confirm. 28. Verify that retries continue for an extended period of time.

8.11.2.6 Unsolicited Responses Off 1. Configure the unsolicited response mode to “off”. 2. Cycle power to the DUT.


3. Verify that no initial unsolicited responses are transmitted by waiting for such responses for a length of time at least as great as what would be necessary for the DUT to otherwise generate an unsolicited response.

4. Issue a request to clear the restart bit (IIN1-7). 5. Verify that the DUT responds with a null response that has the restart bit (IIN1-7) cleared. 6. Verify that no initial unsolicited responses are transmitted by waiting for such responses for a length of time at least as

great as what would be necessary for the DUT to otherwise generate an unsolicited response. 7. Issue a request for Object 60 Variations 3, 2, 1, and 0 using the all data qualifier 0x06 to cause the DUT to report (and

clear) all pending events. 8. If requested, issue an application layer confirm. 9. Generate several change events or other data, which would otherwise cause an unsolicited response. 10. Verify that no unsolicited responses are transmitted by waiting for such responses for a length of time at least as great as

what would be necessary for the DUT to otherwise generate an unsolicited response. 11. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object data

headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 12. Verify that the DUT responds with an Error Response with IIN2-0 set indicating that the DUT has received a message

containing a bad function code. 13. Verify that no unsolicited responses are transmitted by waiting for such responses for a length of time at least as great as

what would be necessary for the DUT to otherwise generate an unsolicited response. 14. Issue a request to disable unsolicited responses for all classes of data by using function code 0x15 with three object data

headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 15. Verify that the DUT responds with an Error Response with IIN2-0 set indicating that the DUT has received a message

containing a bad function code.

8.12 § Collision Avoidance The functions tested in this section are optional. However, if a device claims in its Device Profile Document that it implements collision avoidance, it must pass the tests in this section to be compliant. A device may be certified as supporting collision avoidance in one of the following ways:

Detecting out-of-band carrier (e.g. DCD) •

•

1. with the aid of an external device 2. without the aid of an external device Detecting transmitted data (e.g. TX/RX line).

For these tests, the supplier of the DUT must specify which method the DUT uses to detect other devices are transmitting. If necessary, the supplier must supply hardware (modems etc.) and test equipment suitable for testing this feature. The test equipment must be capable of measuring time between two characters transmitted on the link. Although unsolicited responses may be used with collision avoidance, the two features are independent. For instance, a device might not support collision avoidance, but support unsolicited responses in a dial-up environment. However, unsolicited responses in a multi-drop environment require collision avoidance. The operation of collision avoidance is as follows:

The physical layer must provide an indication to the data link layer of when the link is in use, e.g. using the DCD (Data Carrier Detect) signal or simply monitoring all data on the link. If a device prepares to transmit and finds the link busy, it waits until it is no longer busy, then waits a backoff_time as follows:

backoff_time = fixed_delay + random( max_random_delay ) After the backoff_time, the device tries again, either indefinitely, or up to a configurable maximum number of retries. If a maximum is used, the protocol behaves as if a link failure occurred, i.e. data is returned to buffers at the application layer and application layer retries take place if desired.


The fixed_delay can be adjusted per device to provide priority of access. For instance, it could be zero (0) for masters and non-zero for all the slave devices. The fixed_delay for the slaves must be greater than the max_random_delay for the master. This provides a minimum "window" of access time for the master(s). To absolutely guarantee the master’s priority, the master would not have a random delay.

8.12.1 Desired Behavior When implementing collision avoidance, the DUT must meet the following requirements: • The fixed_delay and the max_random_delay must be configurable. • The DUT must transmit as quickly as possible if no other device is transmitting. • The DUT must wait the backoff_time when it tries to transmit and another device is already transmitting. • The backoff_time must start at the moment when the other device stops transmitting. • The backoff_time must be greater than the fixed_delay. • The backoff_time must not exceed the fixed_delay plus the max_random_delay. • If another device is still transmitting when the backoff_delay expires, the DUT must wait until the line becomes free and

then restart the backoff timer.

8.12.2 Test Procedure 1. Request Class 1 data (Object 60 Variation 2) using Qualifier Code 0x06 and link control block 0xF4. 2. Verify the device responds with data. Measure the turnaround delay between receipt of the request and the response. 3. Prepare a request for Class 1 data as above, followed immediately by “noise” data sufficient to exceed the measured

turnaround delay and the fixed_delay but less than the turnaround delay plus the maximum backoff_delay. The noise data may consist of a poll to a nonexistent device.

4. Send the request. 5. Verify the DUT sends a response AFTER the noise data has finished transmitting. Verify the noise and the response do

not overlap. 6. Verify the delay between the end of the noise data and the start of the response is less than the maximum back_off delay

and more than the fixed_delay plus the max_random_delay. 7. Repeat steps 4 through 6 at least 10 times. Verify the measured backoff_delay is different in each case although it

remains less than the maximum backoff_delay and the length of the noise data remains constant. 8. Add more noise data to the prepared request so that the noise data now exceeds several times the fixed_delay plus the

max_random_delay, then a gap in the noise less than the fixed_delay, followed by noise several times longer than fixed_delay plus the max_random_delay.

9. Repeat steps 4 through 6 to verify the DUT will back off more than once. 10. Reconfigure the device with a different fixed_delay and maximum_random_delay. 11. Repeat steps 1 through 10.


9 Appendix A – DNP3 Reference Sheets QUICK REFERENCE FOR DNP DATA LINK CONTROL FIELD D finitionse :

MSB

LSB

DIR

1

PRM

0

FCB

FCV

FUNCTION CODE

Primary

0

DFC

Secondary

7

6

5

4

3

2

1

0

DIR 1 = Master, 0 = Remote PRM 1 = Data Link Request, 0 = Data Link Response FCB Frame Count Bit, alternates 1 and 0 FCV Frame Count Valid; 1 = valid, 0 = invalid DFC Data Flow Control; 1 = no buffers left Function Codes:

Primary Frames (PRM=1) Fn Code

Function

Frame Type

FCV

0

RESET link

SEND/CONFIRM

0

1

Reset User Process

SEND/CONFIRM

2

TEST link

SEND/CONFIRM

1

3

User Data

SEND/CONFIRM

1

4

User Data

SEND/NO REPLY

0

9

Request Link Status

REQUEST/RESPOND

0

Secondary Frames (PRM = 0)

Fn Code

Function

Frame Type

0

ACK

CONFIRM

1

NACK

CONFIRM

11

Link Status

RESPOND

0


QUICK REFERENCE FOR DNP DATA LINK CONTROL FIELD List of Valid Control Field values by hex value; most common in bold: From Remote

From Master

Function

Other

00

80

ACK

01

81

NACK

Failed transaction

0B

8B

Link Status Reply

No flow Control

10

90

ACK

Frame accepted, no more buffers left

11

91

NACK

Frame not accepted, no buffers available

1B

9B

Link Status Reply

No buffers available

40

C0

RESET LINK

41

C1

Reset User Process

44

C4

Unconfirmed User Data

49

C9

Link Status Request

52

D2

Test Link

FCB = 0

53

D3

Confirmed User Data

FCB = 0

60

E0

RESET LINK

FCB = 1 ignored

61

E1

Reset User Process

FCB = 1 ignored

64

E4


FCB = 1 ignored

69

E9

Link Status Request

FCB = 1 ignored

72

F2

Test Link

FCB = 1

73

F3

Confirmed User Data

FCB = 1

Frame Header: Byte

1

2

3

4

5

6

7

8

9

10

11

Name

05

64

LEN

CTRL

DEST

SOURCE

CRC

TH

Transport Header(TH): Bit 7 = FINAL, Bit 6 = FIRST


DDNNPP AAPPDDUU

Message Header Object Header Object Header Data

Appl. Ctrl

Func Code

equest Header Response Header

Internal Indication

T

2 1

RES

TAR

T U

BLE

CAL

TI

ME

SS 3

SS

2

SS 1

AL

L ST

ATIO

NS

SEC 7 6 0��

��

� �

�

RES

ERVE

D

RES

ERVE

D

BAD

CO

NFI

G

ALR

EAD

Y EX

EC

BUFF

ER O

VER

FLO

W

OU

T O

F R

ANG

E O

BJEC

T U

NKN

OW

N

BAD

FU

NC

TIO

N

��

��

0x00 Confirm 0x01 Read 0x02 Write 0x03 Select 0x04 Operate 0x05 Direct Operate 0x06 Direct Op, No Ack 0x07 Immediate Freeze 0x08 Immediate Freeze No Ack 0x09 Freeze and0x0A Freeze and0x0B Freeze with0x0C Freeze with0x0D Cold Resta0x0E Warm Rest0x0F Init Data to 0x10 Initialize Ap0x11 Start Applic0x12 Stop Applic0x13 Save Config0x14 Enable Uns0x15 Disable Unsolicited Msgs 0x16 Assign Class 0x17 Delay Measurement

0x00 C0x81 R0x82

Object Variation

Qualifier Range

INDEX SIZE 0 – No Index, Packed 1 – 1 Octet Index 2 – 2 Octet Index 3 – 4 Octet Index 4 – 1 Octet Object Size 5 – 2 Octet Object Size 6 – 4 Octet Object Size

QUALIFIER CODE 0 – 8-Bit Start and Stop Indices 1 – 16-Bit Start and Stop Indices 2 – 32-Bit Start and Stop Indices 3 – 8-Bit Absolute Address Identifers 4 – 16-Bit Absolute Address Identifiers 5 – 32-Bit Absolute Address Identifers 6 – No Range Field (all) 7 – 8-Bit Quantity 8 – 16-Bit Quantity 9 – 32-Bit Quantity 11 – (0xB) Variable Array

INDEX SIZE (QUAL CODE = 11) 0 – Dataless Object; No Further Indexing 1 – 1 Octet Index or Identifier Size 2 – 2 Octet Index or Identifier Size 3 – 4 Octet Index or Identifier Size

APCI DUI DUIIO

P = Distrib dNetwProtocol

APDU = ApplicationProtocol Data Unit

APCI = ApplicationProtocolControl Informat

I = Data UnIdentifier

= InformationObject

uteork

6

5

4

3

2 1 0

FIN

AL

CO

NFI

RM

U

NSO

LIC

ITED

SEQ

UEN

CE

IO

t Library Depends on Qualifier Code

7 6 5 4 3 2 1 0

��

��

��

Func Code

Appl. Ctrl

Data

NP3-2001 IED Certification Procedure Page 57 ubset Level 1 Rev 2.1 – 5-July-01

DS

DU

IO

7

FIR

ST

R

DN

ion

it

Clear Clear No Ack Time Time No Ack rt art Defaults plication ation ation uration olicited Msgs

DEV

. TR

O LON

EED

C

LAC

LAC

LA

OND OCTET 5 4 3 2 1

��

FIRST OCTE7

6

5

4

3

onfirm esponse

Unsolicited Response

0

Object Group

See Data Objec

Distributed Network Protocol (DNP3-2001)

DNP3-2001 Intelligent Electronic Device (IED)

Certification Procedure Subset Level 2

Version 2.1

5-July-01

Disclaimer Statement

DNP User Group documents and publications are not consensus documents. Information contained in this and other works has been obtained from sources believed to be reliable, and reviewed by credible members of the DNP User Group and/or the DNP User Group Technical Committee. Neither the DNP Users Group nor any authors/developers of DNP documentation guarantee, and each such person expressly disclaims responsibility for ensuring, the accuracy or completeness of any information published herein, and neither the DNP Users Group nor its authors/developers shall be responsible for any errors, omissions, or damages arising out of use of this document. Likewise, while the author/developer and publisher believe that the information and guidance given in this work serves as an enhancement to users, all parties must rely upon their own skill and judgment when making use of it. Neither the author nor the publisher assumes any liability to anyone for any loss or damage caused by any error or omission in the work, whether such error or omission is the result of negligence or any other cause. Any and all such liability is disclaimed. This statement was developed by the DNP User Group Technical Committee and represents the considered judgment of a group of software developers with expertise in the subject field. The DNP User Group is a global forum for users and implementers of the protocol and promotes implementers and developer information and interaction exchange. This work is published with the understanding that the DNP User Group and its authors/developers are supplying information through this publication, not attempting to render engineering or other professional services. If such services are required, the assistance of an appropriate professional should be sought. The DNP User Group is not responsible for any statements and/or opinions advanced in this publication.





Page ii DNP3-2001 IED Certification Procedure Rev 2.1 – 5-July-01 Subset Level 2

Revision History Date Version Sections affected Reason for change 18-Jan-99 1.00 ALL Initial Release 15-Dec-99 1.01 see errata sheet for 1.00 Fixes inconsistencies and errors

Designates protocol as DNP3-1999 (formerly DNP V3.00 with extensions)

10-July-00 2.00 8.11.1.1 8.11.2.5.9 8.6.5.1 8.6.5.4 8.2.1.1 8.2.1.2.11 - 15 8.4.1.1 8.4.1.2.8 - 12 6 6.6.2.5

Added required parameter - maximum number of unsolicited retries Added test procedure from TB9912-002 Added desired response to addresses 0xFFFE and 0xFFFD Added test procedure from TB9912-003 Added requirements for Control SBO retries Added test procedures from TB2000-002 Added requirements for Analog Output SBO retries Added test procedures from TB2000-002 Removed reference to function code 1 Removed function code 0xD1 from table

5-July-01 2.1 8.2.1.2.10, step 1 8.4.1.2.7, step 1 8.6.5.4 8.2.5 8.2.1.1, 8.2.1.2.3, 8.2.2.1, 8.2.2.2.2, 8.4.1.1, 8.4.1.2.3, 8.4.2.1, 8.4.2.2.2 8.2.4.1 - 8.2.4.2, 8.4.4.1 - 8.4.4.2 Section 9, Appendices A and B

Replace "end testing of Binary Output, SBO" with "skip this section" Replace "end testing of Analog Output, SBO" with "skip this section" Added step 2 - "Issue a link reset using link control block 0xC0" Added test procedure from TB2000-006 Added status code in error response as required in TB2001-01 Added test procedures from TB2001-001 Removed; the information required for these sections is not available and may not be for some time.

DNP3-2001 IED Certification Procedure Page iii Subset Level 2 Rev 2.1 – 5-July-01

Contents

1 Overview 1 1.1 Protocol specification 1

2 Notes 1 3 Definitions 3

3.1 General 3 3.2 Internal Indications 3 3.3 Error Responses 3 3.4 Changes or Events 4

3.4.1 § Rules 4 4 Reference Documents 5 5 Pretest Review 5

5.1 Device Profile Review 5 5.2 Equipment Review 5

6 Link Layer 6 6.1 Reset Link and Passive Confirm support 6

6.1.1 Desired Behavior 6 6.1.2 Test Procedure 6

6.2 Test Link 7 6.2.1 Desired Behavior 7 6.2.2 Test Procedure 7

6.3 Request Link Status 7 6.3.1 Desired Behavior 7 6.3.2 Test Procedure 7

6.4 Test Retries 8 6.4.1 Desired Behavior 8 6.4.2 Test Procedure 8

6.5 § DIR and FCV Bits 8 6.5.1 Desired Behavior 8 6.5.2 Test Procedure 9

6.6 Data Link Rejects Invalid Frames 9 6.6.1 Desired Behavior 9 6.6.2 Test Procedure – Primary Frames 9

6.6.2.1 Invalid Start Octets 10 6.6.2.2 Invalid Primary Function Code 10 6.6.2.3 Invalid Destination Address 10 6.6.2.4 Invalid CRC 10 6.6.2.5 § Invalid FCV 11

6.6.3 Test Procedure – Secondary Frames 11 6.6.3.1 Invalid Start Octets 11 6.6.3.2 Invalid Secondary Function Code 12 6.6.3.3 Invalid Destination Address 12 6.6.3.4 Invalid CRC 12

7 Transport Layer 13 7.1 Desired Behavior 13 7.2 Test Procedure 13

8 Application Layer 14 8.1 Binary Output Status 14


8.2 Binary Outputs 14 8.2.1 Select Before Operate 15

8.2.1.1 Desired Behavior 15

DNP3-2001 IED Certification Procedure Page v Subset Level 2 Rev 2.1 – 5-July-01

8.2.1.2 Test Procedure 16 8.2.1.2.1 Binary Output, SBO, 0x28 16 8.2.1.2.2 Binary Output, SBO, 0x17 16 8.2.1.2.3 Binary Output, SBO, To Uninstalled Point 16 8.2.1.2.4 Binary Output, SBO, Execute Issued After Timeout 16 8.2.1.2.5 Binary Output, SBO, Execute to Different Point Than Select 16 8.2.1.2.6 Binary Output, SBO, Execute On Time does not match Select On Time 16 8.2.1.2.7 Binary Output, SBO, Execute Off Time does not match Select Off Time 17 8.2.1.2.8 Binary Output, SBO, Select using a supported Control Code, Execute using a different Control Code 17 8.2.1.2.9 Binary Output, SBO, Select 0x28, Execute 0x17 17 8.2.1.2.10 Binary Output, SBO, Configurable Device 17 8.2.1.2.11 Binary Output, SBO, Same Sequence Number Select Retries 17 8.2.1.2.12 Binary Output, SBO, Incrementing Sequence Number Select Retries 17 8.2.1.2.13 Binary Output, SBO, Same Sequence Number Operate Retries 18 8.2.1.2.14 Binary Output, SBO, Incrementing Sequence Number Operate Retries 18 8.2.1.2.15 Binary Output, SBO, Sequence number checking 18

8.2.2 Direct Operate with Acknowledge 18 8.2.2.1 Desired Behavior 18 8.2.2.2 Test Procedure 19

8.2.2.2.1 Binary Output, Direct Operate 19 8.2.2.2.2 Binary Output, Direct Operate to Uninstalled Point 19 8.2.2.2.3 Binary Output, Direct Operate, Configurable Device 19

8.2.3 Direct Operate, No Acknowledge 19 8.2.3.1 Desired Behavior 19 8.2.3.2 Test Procedure 19

8.2.3.2.1 Binary Output, Direct Operate, No Acknowledge 19 8.2.3.2.2 Binary Output, Direct Operate, No Acknowledge, to an Uninstalled Point 20 8.2.3.2.3 Binary Output, Direct Operate, No Acknowledge, Configurable Device 20

8.2.4 Multiple Object Requests 20 8.2.4.1 Desired Behavior 20 8.2.4.2 Test Procedure 20

8.2.5 Control Code Support 21 8.2.5.1 Desired Behavior 21 8.2.5.2 Test Procedure 21

8.2.5.2.1 Binary Output, Complementary Function Support 21 8.2.5.2.2 Binary Output, Single Function Support 22

8.3 Analog Output Status 22 8.3.1 Desired Behavior 23 8.3.2 Test Procedure 23

8.4 Analog Outputs 23 8.4.1 Select Before Operate 23

8.4.1.1 Desired Behavior 24 8.4.1.2 Test Procedure 24

8.4.1.2.1 Analog Output, SBO, 0x28 24 8.4.1.2.2 Analog Output, SBO, 0x17 25 8.4.1.2.3 Analog Output, SBO, to Uninstalled Point 25 8.4.1.2.4 Analog Output, SBO, Execute Issued After Time-out 25 8.4.1.2.5 Analog Output, SBO, Execute Value does not match Select Value 25 8.4.1.2.6 Analog Output, SBO, Select 0x28, Execute 0x17 25 8.4.1.2.7 Analog Output, SBO, Configurable Device 25 8.4.1.2.8 Analog Output, SBO, Same Sequence Number Select Retries 26 8.4.1.2.9 Analog Output, SBO, Incrementing Sequence Number Select Retries 26 8.4.1.2.10 Analog Output, SBO, Same Sequence Number Operate Retries 26 8.4.1.2.11 Analog Output, SBO, Incrementing Sequence Number Operate Retries 26 8.4.1.2.12 Analog Output, SBO, Sequence number checking 26

Page vi DNP3-2001 IED CerRev 2.1 – 5-July-01

8.4.2 Direct Operate with Acknowledge 27 8.4.2.1 Desired Behavior 27 8.4.2.2 Test Procedure 27

8.4.2.2.1 Analog Output, Direct Operate 27 8.4.2.2.2 Analog Output, Direct Operate, to Uninstalled Point 27 8.4.2.2.3 Analog Output, Direct Operate, Configurable Device 27

8.4.3 Direct Operate, No Acknowledge 28 8.4.3.1 Desired Behavior 28 8.4.3.2 Test Procedure 28

8.4.3.2.1 Analog Output, Direct Operate, No Acknowledge 28 8.4.3.2.2 Analog Output, Direct Operate, No Acknowledge, to an Uninstalled Point 28 8.4.3.2.3 Analog Output, Direct Operate, No Acknowledge, Configurable Device 28

8.4.4 Multiple Object Requests 28 8.4.4.1 Desired Behavior 28 8.4.4.2 Test Procedure 28

8.5 Class Data 29 8.5.1 Class 0 29


8.5.2 Class 1 30 8.5.2.1 Desired Behavior 31 8.5.2.2 Test Procedure 31

8.5.2.2.1 Class 1 Data, 0x06 31 8.5.2.2.2 Class 1 Data, 0x07 32 8.5.2.2.3 Class 1 Data, 0x08 32 8.5.2.2.4 § Class 1 Data Without Confirm 32





8.5.5 Multiple Object Request 36 8.5.5.1 Desired Behavior 37 8.5.5.2 Test Procedure 37

8.5.5.2.1 Multiple Object Request, Class 1, 2, and 3 37 8.5.5.2.2 Multiple Object Request, Class 1, 2, 3, and 0 37

8.5.6 Class Assignment Verification 37 8.5.6.1 Desired Behavior 37 8.5.6.2 Test Procedure 38

8.6 Indications 38 8.6.1 Restart 38


8.6.2 Bad Function 39 8.6.2.1 Desired Behavior 39 8.6.2.2 Test Procedure 39

DNP3-2001 IED Certification Procedure Page vii Subset Level 2 Rev 2.1 – 5-July-01

8.6.3 Object Unknown 39 8.6.3.1 Desired Behavior 39 8.6.3.2 Test Procedure 39

8.6.4 Local 39 8.6.4.1 Desired Behavior 39 8.6.4.2 Test Procedure for Devices with Global Remote Supervisory Control 39 8.6.4.3 Test Procedure for Devices with Individual Remote Supervisory Control 39

8.6.5 Broadcast Address and All Stations Indication 40 8.6.5.1 Desired Behavior 40 8.6.5.2 § Test Procedure 40 8.6.5.3 Test Procedure 40 8.6.5.4 § Test Procedure, Confirmed Response Options 40

8.6.6 Buffer Overflow 41 8.6.6.1 Desired Behavior 41 8.6.6.2 Test Procedure 41

8.6.6.2.1 Buffer Overflow, Binary Input Change Event Buffers 41 8.6.6.2.2 Buffer Overflow, Analog Input Change Event Buffers 41 8.6.6.2.3 Buffer Overflow, Binary Counter Change Event Buffers 42

8.7 Time 42 8.7.1 Delay Measurement 42


8.7.2 Synchronization 43 8.7.2.1 Desired Behavior 43 8.7.2.2 Test Procedure 43

8.8 Cold Restart 43 8.8.1 Desired Behavior 43 8.8.2 Test Procedure 43

8.9 Application Layer Fragmentation 43 8.9.1 Use of FIR, FIN and SEQUENCE in Fragmentation 43


8.9.2 § Use of Confirmation in Fragmentation 44 8.9.2.1 § Desired Behavior 44 8.9.2.2 § Test Procedure 44

8.10 Multi-Drop Support 45 8.10.1 Desired Behavior 45 8.10.2 Test Procedure 45

8.11 Unsolicited Responses 45 8.11.1 Desired Behavior 46

8.11.1.1 Configuration 46 8.11.1.2 Sequence Numbers and Confirmation 46 8.11.1.3 Restart Behavior 46 8.11.1.4 Runtime Behavior 46 8.11.1.5 Unsolicited and Polled Responses 47

8.11.2 Test Procedure 47 8.11.2.1 Unsolicited Response Configuration/Startup 47 8.11.2.2 Unsolicited Response - Class 1 Data 48 8.11.2.3 Unsolicited Response - Class 2 Data 49 8.11.2.4 Unsolicited Response - Class 3 Data 49 8.11.2.5 Unsolicited and Polled Responses 50

8.11.2.5.1 Transmits data-filled unsolicited responses 50 8.11.2.5.2 Clears transmitted data upon confirmation 50 8.11.2.5.3 Processes non-READ requests immediately 50 8.11.2.5.4 Defers READ requests until after confirmation received 50 8.11.2.5.5 Defers READ requests until after confirmation timeout 51

Page viii DNP3-2001 IED CerRev 2.1 – 5-July-01

8.11.2.5.6 Abandons READ requests upon subsequent non-READ requests 51 8.11.2.5.7 Abandons READ requests upon subsequent READ requests 51 8.11.2.5.8 Inhibits Unsolicited responses until after polled confirmation 51 8.11.2.5.9 Retries unsolicited responses configurable number of times 52

8.11.2.6 Unsolicited Responses Off 53 8.12 § Collision Avoidance 53


8.13 Binary Inputs 54 8.13.1 Desired Behavior 54 8.13.2 Test Procedure 55

8.13.2.1 Device does not have Binary Inputs 55 8.13.2.2 Device has Binary Inputs 55 8.13.2.3 Device supports Binary Inputs, Configurable Device 55

8.14 Binary Input Change 55 8.14.1 Desired Behavior 55 8.14.2 Test Procedure 56

8.14.2.1 Device does not support Binary Input Changes 56 8.14.2.2 Binary Input Change, 0x06 56 8.14.2.3 Binary Input Change, 0x07 56 8.14.2.4 Binary Input Change, 0x08 56 8.14.2.5 § Binary Input Change Without Confirm 57 8.14.2.6 Binary Input Change Without Time, 0x06 57 8.14.2.7 Binary Input Change Without Time, 0x07 57 8.14.2.8 Binary Input Change Without Time, 0x08 58 8.14.2.9 Binary Input Change With Time, 0x06 58 8.14.2.10 Binary Input Change With Time, 0x07 59 8.14.2.11 Binary Input Change With Time, 0x08 59 8.14.2.12 Binary Input Change With Relative Time, 0x06 59 8.14.2.13 Binary Input Change With Relative Time, 0x07 60 8.14.2.14 Binary Input Change With Relative Time, 0x08 60 8.14.2.15 Binary Input Change with Relative Time, Long Interval 61

8.15 Common Time of Occurrence 61 8.15.1 Desired Behavior 61 8.15.2 Test Procedure 62

8.16 Binary Counters 63 8.16.1 Binary Counters, Running 63


8.16.1.2.1 Device does not have Binary Counters 63 8.16.1.2.2 Device responds with Binary Counters 64 8.16.1.2.3 Device responds with Delta Counters 64 8.16.1.2.4 § Device Responds with Delta Counters, No Confirm 64 8.16.1.2.5 Device supports Binary Counters, Configurable Device 65

8.16.2 Binary Counters, Frozen 65 8.16.2.1 Desired Behavior 65 8.16.2.2 Test Procedure 65

8.16.2.2.1 Device does not have Frozen Counters. 65 8.16.2.2.2 Binary Counter, Freeze 65 8.16.2.2.3 Binary Counter, Freeze And Clear 66 8.16.2.2.4 Binary Counter, Freeze, No Acknowledge 66 8.16.2.2.5 Binary Counter, Freeze And Clear, No Acknowledge 66

8.17 Binary Counters, Event 67 8.17.1 Desired Behavior 67 8.17.2 Test Procedure 67

DNP3-2001 IED Certification Procedure Page ix Subset Level 2 Rev 2.1 – 5-July-01

8.17.2.1 Device does not support Binary Counter Events 67 8.17.2.2 Binary Counters, Event, 0x06 67 8.17.2.3 Binary Counters, Event, 0x07 68 8.17.2.4 Binary Counters, Event, 0x08 68 8.17.2.5 § Binary Counters, Event Without Confirm 68

8.18 Analog Input 69 8.18.1 Desired Behavior 69 8.18.2 Test Procedure 69

8.18.2.1 Device does not have Analog Inputs 69 8.18.2.2 Device has Analog Inputs 69

8.19 Analog Change Event 69 8.19.1 Desired Behavior 69 8.19.2 Test Procedure 70

8.19.2.1 Analog Input Change 70 8.19.2.2 § Analog Input Change, Without Confirm 70

8.20 Multiple Read Requests 70 8.20.1 Desired Behavior 70 8.20.2 Test Procedure 71

9 Appendix A – DNP Reference Sheets 72

Page x DNP3-2001 IED CerRev 2.1 – 5-July-01

1 Overview It is the purpose of this document to describe a set of tests that will determine an Intelligent Electronic Devices’ (IED) compliance with the Distributed Network Protocol (formly known as DNP V3.00). This certification procedure is designed specifically to determine an IED’s compliance to Level 2 of the Subset Definitions.

1.1 Protocol specification The protocol is defined by the Basic 4 Document set (Link Layer, Transport Layer, Application Layer, and Subset Definitions), Technical Notes published by the Technical Committee, and this Certification Procedure. The protocol defined by these documents shall be denoted DNP3-2001. Sections in this document marked with the symbol "§" constitute new requirements or clarifications beyond the Basic 4 Document set. These sections may create interoperability problems with implementations done prior to the publication of this test procedure. However, the DNP Users' Group approved these changes at the annual 1999 meeting based on strong recommendation from the Technical Committee. These requirements and clarifications will greatly improve interoperability and extensive efforts have been made to minimize the impact on existing implementations.

2 Notes 1. This procedure is an attempt to produce interoperability between Master and IED devices, although such

interoperability can NOT be guaranteed. However, it does gives reasonable assurance that Masters which can be configured to match items in the IED Device Profile Document will interoperate.

2. Wherever the following procedures generate a specific number of events, it is acceptable to use an alternate number

supported by the device provided that the intent of the test is still satisfied. 3. This is not a factory acceptance test, but a protocol test. Therefore only selected outputs will be tested to verify

protocol operation. 4. Unless otherwise specified, all Application Layer retries are disabled. 5. If not explicitly stated all tests imply verification that all points in a normal operating state are reported with all flag

bits except the ONLINE bit clear and the ONLINE bit is set. Alternatively, verification that the object is reported with the “without flags” variation is also implied.

6. Sections marked with three asterisks (***) extend the requirements of the device beyond DNP3-2000. 7. Record the point numbers used in all tests in the log. 8. All application layer tests use unconfirmed link services using a request link control block of 0xC4 unless specified

otherwise. 9. When time tagged events are reported the certification procedures do not measure the absolute accuracy of the

reported times. They do however verify that the reported times are updated in a reasonable manner. The Device Profile Document specifies the accuracy with which the device measures the event. This accuracy is guaranteed by the vendor, not the certification procedures.

10. If not explicitly stated all tests imply verification that a response to a request has the same application sequence

number as the request. If the request generates multiple application fragments also verify that the application sequence number of each subsequent fragment increments by 1 modulo 16.

11. These tests assume that the device will only generate events as controlled by the tester, as specified in the procedure.


12. It is strongly recommended that the tester run the device for a least 24 hours at some point during the testing to insure that it does not exhibit any unusual or unexpected behavior. This is not a requirement for compliance to this procedure.

13. Responses to all properly formed requests, must result in either the specific action or behavior described in the

protocol or in a correctly-formed, appropriate protocol error response. In addition, devices must continue to operate without interruption or anomalous behavior in response to properly or improperly formed requests.

Page 2 DNP3-2001 IED CerRev 2.1 – 5-July-01

3 Definitions

3.1 General Master Device that sends DNP application function codes 0-23. Slave Device that sends DNP application function code 0,128,129 (also known as “IED”). Operate This is an action taken by the Slave in response to a Master DNP request. This action does not include

transmission of a response. Examples of an operation are an audible relay click, change in an LED status, or change in the internal state of the Slave. Note that some operations are difficult to observe without intimate knowledge of the Slave device. The inability to observe an operation does not mean that an operation failed to take place.

Request Any message from a Master to a Slave where a response from the Slave is expected. Response Message from Slave caused by a Master Request. Responses are classified as follows:

No response: No octets are sent by Slave • • •

•

• •

Link only response: 10 octet message consisting of only a link layer message Null Response: Message containing a 17-octet link/transport/application response with no error IIN bits set and no application objects. Normal Response: Message containing an application response which has no error IIN bits set, and has no objects which indicate errors All responses must begin with the same application sequence number as the corresponding request. For Multi-fragment responses the first fragment must have the same sequence number as the request and each subsequent fragment must increment the sequence number by 1 modulo 16.

3.2 Internal Indications IIN Octets 3 and 4 of the application response header. Bits are named IINx-y. x=1 for first transmitted octet and 2

for second transmitted octet. y=bit number where 0=least significant bit. Refer to the Basic Four Application Layer section 3.6 and the Subset Definitions section 4.1.1 for detailed explanations of the IIN bits. The following is a summary of the definitions.

IIN1-1 Class 1 event data available. Can be set at any time and does not indicate an error condition. IIN1-2 Class 2 event data available. Can be set at any time and does not indicate an error condition. IIN1-3 Class 3 event data available. Can be set at any time and does not indicate an error condition. IIN1-4 Time synchronization required. Can be set at any time and does not indicate an error condition. IIN1-5 Local mode. Set if some points are uncontrollable via DNP. IIN1-7 Device restart. Set only under specific conditions. Does not indicate an error condition. IIN2-0 Function Unknown. Generally means that the function code (octet 2 of the request header) cannot be

processed. IIN2-1 Object Unknown. Generally means that the function code could be processed but the object group / variation

could not be processed. IIN2-2 Parameter Error. Generally indicates that both the function code and object group / variation could be

processed but that the qualifier / range field is in error.

3.3 Error Responses Error IIN bits IIN bits that indicate a request error (i.e., IIN2-0 or IIN2-1 or IIN2-2). Error Response A response that has any or all of the Error IIN bits set which may also contain data.


Unexpected Error Response Slaves may generate responses with any or all of the following:

• unexpected bits in the IIN set • unexpected bits in any returned flags set • unexpected status code errors

Any unexpected responses must be noted by the tester and “explained” in the test log.

3.4 Changes or Events This section clarifies processing rules related to the following objects.

Change Object Corresponding Static Object

Name Object Name Object

Binary Input Change 2 Binary Input 1

Counter Change Events 22 Counter 20

Frozen Counter Change Events 23 Frozen Counter 21

Analog Change Events 32 Analog Input 30

Frozen Analog Change Events 33 Frozen Analog Input 31 Table 3-1

1. The term “significant change” refers to any of the synonymous terms: “event” or “change event”. 2. Change Objects and Static Objects are related in that a significant change in a point’s static value results in the

creation of a corresponding Change Object entry 3. A significant change for a point is defined to occur:

• for a binary point, on any change in state, and • for a numeric point, on any change in value greater than the point’s threshold

3.4.1 § Rules A device may claim that it supports a specific Change Object if and only if processing for that Change Object can be configured to adhere to the following rules. 1. Change processing must be supported for all points in the corresponding Static Object. 2. The determination that a point has undergone a significant change can be determined only by using information

from that point’s current or past value. Decisions based on information about any other point, directly or indirectly, are explicitly forbidden.

3. For numeric Change Objects, the Device Profile must clearly specify the algorithm used for each point or set of points that specifies how the deadband(s) for those points are determined.

4. All changes must be returned to a host that issues a request for any specific Change Object, limited only by qualifier and range codes in the request.

Some devices may decide to limit the set of points included in Change Object processing (in violation of rule 1), or to invoke a more complicated algorithm for determining a significant change (in violation of rule 2). While these implementations may be useful in specific instances, such devices may not check compliance with the corresponding Change Object in their Device Profile Documentation unless the device is configurable to conform to the rules above.


4 Reference Documents • DNP Version 3.00 Data Link Layer • DNP Version 3.00 Transport Functions • DNP Version 3.00 Application Layer • DNP Version 3.00 Data Object Library Layer • DNP Version 3.00 Subset Definitions Version 2.00 (§ Version 3.00)

5 Pretest Review Before testing proceeds it is necessary to review documentation and equipment supplied by the vendor for completeness and appropriateness to the application. In particular the vendor must have provided the test facility with the following items. • Device Profile Document • Device to be tested • Wiring Diagrams for

• Power • Communications (e.g. RS232, RS485, Bell 202, IEEE 802.3) • Input connections

5.1 Device Profile Review Before connecting any equipment the Device Profile should be carefully reviewed. This document describes the vendors’ specification of the behavior of the device. This behavior should be compared to Level 2 requirements and any discrepancies resolved before testing proceeds. Specifically the Device Profile should indicate that the device: • Responds to all Level 2 requests that a slave device is required to parse. • Responds to Level 2 requests only with Objects/Variations and Qualifiers that a Level 2 master is required to parse. If a device generates any response requiring a higher level master to parse it, the following actions should be taken: • Testing can continue. • It must be noted in the test results that the device is Level 2 compliant for requests only. • The required Master Level must be noted in the test results.

5.2 Equipment Review Before testing proceeds, the device will be examined to insure the proper equipment is available for the following: • Physical interfaces present and compatible. • Wiring diagrams and equipment necessary for Input stimulation. • Input power specifications. • If it is not readily apparent whether an output point has operated, the vendor must supply to the tester a point number

and method to determine whether or not a binary control and/or analog output has operated. A manufacturer’s representative should be available by phone to answer questions during the testing of the device.


6 Link Layer Any DNP device is required to passively implement all link layer services. Specifically, this means that a device need not request link layer service but must support any services requested by another device. For example: • A device can choose not to request link layer confirms but MUST respond with a link layer confirm if requested to

do so. • A device can choose not to request link layer reset if it is using unconfirmed link services but MUST respond with a

link layer confirm if a link layer reset is requested. • § A device must respond to all unconfirmed link requests (i.e. function codes 0, 4, 9) without a preceding link reset. The following tests are designed to verify this functionality.

6.1 Reset Link and Passive Confirm support

6.1.1 Desired Behavior • The Device under test (DUT) must respond to a link reset with a link confirm. • DUT must respond to application layer data requests using unconfirmed link services without requiring a link reset. • DUT must not respond to application layer data requests using confirmed link services without a preceding link

reset. • DUT must respond to application layer data requests using confirmed link services after a link reset has been issued. • DUT must acknowledge but not otherwise respond to requests with the wrong FCB. • DUT must issue a data link reset if transmitting requests that require a data link confirm.

6.1.2 Test Procedure 1. Cycle power to the DUT. 2. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 3. Verify that the DUT responds with a valid message. 4. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 5. Verify that the DUT either sends a NACK with the DFC bit clear or does not respond. 6. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xD3. 7. Verify that the DUT either sends a NACK with the DFC bit clear or does not respond. 8. Issue a link reset using link control block 0xC0. 9. Verify that the DUT responds with a link layer confirm (link control block 0x00). 10. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 11. Verify that the DUT responds with a link layer confirm and a valid application layer response. 12. Perform repeated requests of Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and alternating link

control blocks 0xD3 and 0xF3. 13. Verify that the DUT responds with a link layer confirm and a valid application layer response for each request. 14. Issue a link reset using link control block 0xC0. 15. Verify that the DUT responds with a link layer confirm (link control block 0x00). 16. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xD3. 17. Verify that the DUT responds with a link layer confirm (link control block 0x00) and no application response. 18. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 19. Verify that the DUT responds with a link layer confirm and a valid application layer response. 20. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 21. Verify that the DUT responds with a link layer confirm (link control block 0x00) and no application response. 22. If the DUT cannot be configured to request data link confirms when transmitting, continue testing at section 6.2. 23. Configure the DUT to request data link confirm when transmitting. 24. Cycle power to the DUT. 25. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 26. Verify that the DUT responds by sending a data link reset (control block 0x40). 27. Send a data link acknowledge (control block 0x80).


28. Verify that the DUT responds with a valid message having control block 0x73. This is the response to the Class 0 data request, including a request for data link confirm.

29. Issue a data link NACK with DFC clear (control block 0x81). 30. If the DUT then issues a data link reset (control block 0x40), respond by sending an acknowledge control block

0x80). If the DUT then repeats the Class 0 response message (control block 0x73), it has functioned correctly, and this test is complete, continue testing at section 6.2.

31. If the DUT did not issue a link reset at step 30, steps 25 through 28 should be repeated as shown above. DUT responses other than those of steps 26 and 28 indicate incorrect operation.

6.2 Test Link

6.2.1 Desired Behavior • The DUT must respond with a Link Confirm - ACK if the FCB bits are correct in the test request. • Otherwise, the DUT must respond with the last secondary confirm frame. This behavior is not tested since it was

deemed by the Technical Committee as too difficult to test in a reliable manner. • If the DUT receives a test link frame without a previous link reset, the DUT must either not respond or respond with

a NACK with DFC = 0.

6.2.2 Test Procedure 1. Cycle power to the DUT. 2. Request a Link Test Frame using link control block 0xF2. 3. Verify that the DUT responds with a Confirm - NACK with DFC=0 (link control code 0x01) or does not respond. 4. Issue a Link Reset using link control block 0xC0. 5. Request a Link Test Frame using link control block 0xF2. 6. Verify that the DUT responds with a Confirm - ACK (link control code 0x00). 7. Request a Link Test Frame using link control block 0xD2. 8. Verify that the DUT responds with a Confirm - ACK (link control code 0x00). 9. Cycle power to the DUT. 10. Request a Link Test Frame using link control block 0xD2. 11. Verify that the DUT responds with a Confirm - NACK with DFC=0 (link control code 0x01) or does not respond. 12. Issue a Link Reset using link control block 0xC0. 13. Request a Link Test Frame using link control block 0xF2. 14. Verify that the DUT responds with a Confirm - ACK (link control code 0x00). 15. Request a Link Test Frame using link control block 0xD2. 16. Verify that the DUT responds with a Confirm - ACK (link control code 0x00).

6.3 Request Link Status

6.3.1 Desired Behavior • When issued a Request Link Status message, the DUT must respond with a valid Status of Link message. • The DUT must ignore FCB when FCV = 0.

6.3.2 Test Procedure 1. Cycle power to the DUT. 2. Request a Link Status Frame using link control block 0xC9. 3. Verify that the DUT responds with a valid link status message with link control block 0x0B or 0x1B. 4. Request a Link Status Frame using link control block 0xE9. 5. Verify that the DUT responds with a valid link status message with link control block 0x0B or 0x1B.


6.4 Test Retries

6.4.1 Desired Behavior • DUTs are not required to support link layer retries. • The rest of these behaviors apply only to DUTs that support link layer retries. • § The DUT must be able to disable retries through configuration. • If the device requests a link layer confirm and does not receive it within a specified period of time (LINK

TIMEOUT), it shall retransmit the link frame. It shall do this n times where n is a specified number of retries before aborting transmission (LINK RETRYCOUNT).

• If configured to enable link layer confirms on primary transmissions, the DUT must perform retries on all SEND/CONFIRM and REQUEST/RESPOND frames.

• Both LINK TIMEOUT and LINK RETRYCOUNT must be specified in the Device Profile Document or they can optionally be configurable parameters.

6.4.2 Test Procedure 1. If the DUT does not support link layer confirms or link layer retries on primary transmissions, continue testing in the

next section. 2. Configure the device to enable link layer confirms on primary transmissions and if retries are configurable, set them

to a reasonable value. 3. Cycle power to the DUT. 4. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 5. Verify that the DUT sends a RESET LINK frame. Do not send a data link CONFIRM frame. 6. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 7. Verify that it repeats this exactly LINK RETRYCOUNT times. 8. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 9. Verify that the DUT responds with a RESET LINK frame. Send a data link CONFIRM. 10. Verify that the DUT sends a valid application layer response in a SEND/CONFIRM USER DATA frame. Do not

send a data link CONFIRM frame. 11. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 12. Verify that it repeats this exactly LINK RETRYCOUNT times. 13. If it is possible to cause the DUT to send TEST LINK, RESET USER PROCESS, or REQUEST LINK STATUS,

cause it to do so, but do not respond in each case. Repeat steps 11 and 12 for each of these frames that can be generated.

14. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 15. Verify that the DUT responds with a RESET LINK frame. Send a data link CONFIRM. 16. Verify that the DUT sends a valid application layer response in a SEND/CONFIRM USER DATA frame. Do not

send a data link CONFIRM frame. 17. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 18. Send a data link CONFIRM. 19. Verify that no further retries are sent. 20. If it is possible to cause the DUT to send TEST LINK, RESET USER PROCESS, or REQUEST LINK STATUS,

cause it to do so, but do not respond in each case. Repeat steps 18 and 19 for each of these frames that can be generated.

6.5 § DIR and FCV Bits

6.5.1 Desired Behavior The DUT must clear (set to zero) the DIR bit in each data link frame it transmits. •

• The DUT must set the FCV bit to zero in all frames except SEND/CONFIRM User Data and SEND/CONFIRM Test Link. These frames are tested elsewhere.


6.5.2 Test Procedure 1. If the DUT is capable of requesting data link confirmations, configure it to NOT request data link confirmations. 2. Cycle power to the DUT. 3. Prepare and send a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link

control block 0xC4. 4. Verify the response from the DUT uses data link control block 0x44 i.e. Unconfirmed User Data with the DIR bit

not set and the FCV bit not set. 5. If the DUT can generate RESET USER PROCESS or REQUEST LINK STATUS, cause it to do so and verify none

of these frames have the DIR or FCV bit set. 6. If the DUT can generate TEST LINK, cause it to do so and verify that these frames have the DIR bit clear and FCV

bit set. 7. If the DUT is not capable of requesting data link confirmations, no further testing is required in this section. If the

DUT is capable of requesting data link confirmations, configure it to do so. 8. Cycle power to the DUT. 9. Prepare and send a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link

control block 0xC4. 10. Verify the DUT first sends a frame with data link control block 0x40, i.e. RESET LINK with DIR=0 and FCV=0. 11. Reply with a data link CONFIRM - ACK. 12. Verify the DUT sends a frame with data link control block 0x73 i.e. SEND/CONFIRM USER DATA with FCV=1

and FCB = 1. 13. Configure DUT to NOT request data link confirmations.

6.6 Data Link Rejects Invalid Frames

6.6.1 Desired Behavior The DUT must detect errors due to transmission line errors or the incorrect functioning of other devices. It must therefore not respond, either at a data link layer or application layer, to frames that are otherwise valid but have one of the following errors:

Incorrect start sequence • • • • •

•

•

Incorrect destination address Incorrect CRC Invalid function code Invalid FCV (Frame Count Valid) bit

For an invalid function code or invalid FCV, the DUT may also respond with LINK SERVICE NOT IMPLEMENTED. NOTES:

These procedures do not test whether the DUT rejects frames having the DIR bit set incorrectly. Implementers of Slave IEDs must, however, clear this bit (0) in all their transmissions to aid monitoring their device’s output on protocol analyzers. This is tested in section “DIR and FCV Bits”. It is optional whether devices choose to filter frames based on source address, and is therefore not tested here. The Device Profile Document indicates whether or not filtering is performed based on the source address.

6.6.2 Test Procedure – Primary Frames Before performing the remainder of these tests: 1. Cycle power to the DUT. 2. Issue a link reset using link control block 0xC0. 3. Verify that the DUT responds with a link layer confirm (link control block 0x00). 4. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xF3. 5. Verify that the DUT responds with a link layer confirm (link control block 0x00). 6. Verify that the DUT responds with application layer data.


To perform the remainder of this test, a general-purpose protocol analyzer capable of generating any sequence of data is necessary. If a DNP-specific protocol analyzer is being used for testing, it should be used to monitor the exchange between the general-purpose analyzer and the DUT.

6.6.2.1 Invalid Start Octets 1. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block

0xD3. 2. Modify the frame so it begins with an invalid initial start octet (e.g. 0x09) instead of 0x05. 3. Modify the CRC of the data link layer header so the CRC is correct for the invalid start octet. 4. Send the request. 5. Wait several seconds. 6. Verify that the DUT does not send a link layer confirm or application layer response. 7. Modify the frame so it begins with 0x05, but the second start octet is invalid (e.g. 0xff). 8. Modify the CRC of the data link layer header so the CRC is correct for the invalid start octet. 9. Send the request. 10. Wait several seconds. 11. Verify that the DUT does not send a link layer confirm or application layer response. 12. Repeat this test once using different start octet values.

6.6.2.2 Invalid Primary Function Code 1. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block

of 0xD3. 2. Modify the frame so the control field contains the correct settings of the DIR, PRM, FCB and FCV fields, but has an

invalid function code, e.g. 0xD5. Alter the CRC of the data link layer header so the CRC is correct for the invalid control field.

3. Send the request. 4. Wait several seconds. 5. Verify that the DUT either does not send a link layer confirm, or responds with a valid LINK SERVICE NOT

IMPLEMENTED frame (control field 0x0F). 6. Verify that the DUT does not send an application layer response. 7. Repeat this test once with a different invalid function code.

6.6.2.3 Invalid Destination Address 1. Send a READ request to different address. Note: For devices that can be configured to represent multiple logical

devices (i.e. can respond to requests directed to more than one address), ensure that the selected address is not one of the other valid addresses configured for the device.

2. Wait several seconds. 3. Verify that the DUT does not send a link layer confirm or application layer response. 4. Repeat this test once with a different destination address.

6.6.2.4 Invalid CRC 1. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block

0xD3. 2. Modify the frame so the CRC of the data link layer header is incorrect. 3. Send the request. 4. Wait several seconds. 5. Verify that the DUT does not send a link layer confirm or application layer response. 6. Modify the frame so the CRC of the data link layer header is correct but the CRC of the application layer request

is incorrect. 7. Send the request. 8. Wait several seconds. 9. Verify that the DUT does not send a link layer confirm or application layer response. 10. Repeat this test once with different incorrect CRC values.


6.6.2.5 § Invalid FCV 1. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block

0xC3, i.e. SEND/CONFIRM USER DATA, but with FCV=0 (incorrect). 2. Send the request. 3. Wait several seconds. 4. Verify that the DUT does not send a link layer confirm or application layer response. The DUT may respond with a

link layer frame with function code LINK SERVICE NOT IMPLEMENTED. 5. Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block

0xD4, i.e. SEND/NO CONFIRM USER DATA, but with FCV=1 (incorrect). 6. Send the request. 7. Wait several seconds. 8. Verify that the DUT does not send a link layer confirm or application layer response. The DUT may respond with a

link layer frame with function code LINK SERVICE NOT IMPLEMENTED. 9. Repeat steps 5-8 using the control blocks in the following table:

Code Description Notes C2

Test Link

FCV = 0 incorrect

D0

RESET LINK


D9

Link Status Request


6.6.3 Test Procedure – Secondary Frames The tests in this section are optional, and must pass only if the DUT requests data link confirmations and performs retries. The retries are used to detect whether the device processed the data link layer confirmation. Before performing these tests: 1. Configure the device to enable link layer confirms on primary transmissions and if retries are configurable set them

to a reasonable value. 2. Cycle power to the DUT. 3. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 4. Verify that before responding with application layer data, the DUT sends a RESET LINK frame. Send a data link

CONFIRM – ACK frame in reply. 5. Verify the DUT responds with application layer data, requesting data link confirmation. 6. Send a valid CONFIRM – ACK frame in reply. To perform the remainder of this test, a general-purpose protocol analyzer capable of generating any sequence of data is necessary. If a DNP-specific protocol analyzer is being used for testing, it should be used to monitor the exchange between the general-purpose analyzer and the DUT.

6.6.3.1 Invalid Start Octets 1. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 2. Verify the DUT responds with application layer data, requesting data link confirmation. 3. Send a CONFIRM – ACK frame modified so its start octet is invalid (e.g. 0x09). 4. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 5. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 6. Verify the DUT responds with application layer data, requesting data link confirmation. 7. Send a CONFIRM – ACK frame modified so the start octet is correct (0x05), but the second octet is incorrect

(e.g. 0xff). 8. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 9. Repeat this test once with different start octet values.


6.6.3.2 Invalid Secondary Function Code 1. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 2. Verify the DUT responds with application layer data, requesting data link confirmation. 3. Send a CONFIRM – ACK frame modified so the DIR, PRM and DFC bits of the control field are correct, but

the function code is invalid (e.g. 0x03). Ensure that the CRC is correct for the invalid function code value. 4. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 5. Repeat this test once with a different function code value.

6.6.3.3 Invalid Destination Address 1. This test may be performed with a DNP-specific test set. 2. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 3. Verify the DUT responds with application layer data, requesting data link confirmation. 4. Send a CONFIRM – ACK frame to a destination address that is not that of the DUT. 5. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 6. Repeat this test once with a different destination address.

6.6.3.4 Invalid CRC 1. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4. 2. Verify the DUT responds with application layer data, requesting data link confirmation. 3. Send a CONFIRM – ACK frame modified such that the CRC is incorrect. 4. Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame. 5. Repeat this test once with a different CRC value.


7 Transport Layer Whenever FIR, FIN and sequence numbers are referenced in this section they refer to the definitions present in the transport header which is reproduced here for convenience.

Transport Header bit 7 bit 6 bits 5-0 FIN FIR Sequence number

Table 7-1

7.1 Desired Behavior • If the DUT contains enough data to cause the reply to an application request to be larger than one Link Protocol

Data Unit, it is required to, a) Set the proper FIR and FIN bits. b) Set the correct sequence information. c) Distribute the data correctly. d) Signify to the initiating station that the reply contains multiple LPDU’s e) Provide the appropriate information for assembly at the receiving station.

• If the device does not contain enough data, then the FIR and FIN bits must signify that there is only one LPDU in the reply.

7.2 Test Procedure 1. Cycle power to the DUT. 2. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06. 3. Verify that the DUT responds with a valid message. 4. If the DUT’s reply contains more than 249 octets then verify that the first response message sets the FIR bit to a one,

the FIN bit is set to zero. 5. Verify subsequent messages to assure that the FIR bit is zero, the FIN bit is zero, and the sequence number

increments by one. 6. Verify that the last message has the FIR bit is zero and the FIN bit is one, signifying the last data fragment, and the

SEQ value increments by one. 7. If the DUT’s reply contains less than 250 octets in the Data Link Frame then the FIR bit is set to one and the FIN bit

is also set to one.


8 Application Layer

8.1 Binary Output Status The binary output status object represents the current state and status of the associated binary output. The status is an 8-bit flag field (repeated here for your convenience):

Flag Bit Value 0 ONLINE - 0=off-line, 1= on-line 1 RESTART - 0=normal, 1= restart 2 COMMUNICATION LOST - 0=normal, 1=lost 3 REMOTE FORCED DATA - 0=normal, 1=forced 4 LOCAL FORCED DATA - 0=normal, 1=forced 5 0 6 0 7 STATE - 0, 1

Table 8-1

8.1.1 Desired Behavior • If the device supports binary outputs the device must respond to a Binary Output read request with a binary output

status object (object 10 Variation 2) using qualifiers 0x00 or 0x01. • If the device does not support binary outputs the device must respond to a Binary Output read request with a Null

Response. • Optionally, the device can return an error response with IIN2-1.

8.1.2 Test Procedure 1. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 2. If the device supports Binary Outputs verify that the DUT responds with a Binary Output Status object (Object 10


(qualifier 0x01). 4. If the device does not support Binary Outputs verify that the DUT responds with a Null Response. The device can

optionally set IIN2-1. 5. Verify that flag behavior complies with Section 2, Note #5.

8.2 Binary Outputs § If a device supports control outputs, it is required to be configurable to support all three modes of operation of control, namely Select Before Operate, Direct Operate, and Direct Operate No Acknowledgment. A device may be configurable to disable any subset of the modes. If a device has been configured to reject a particular mode, it must return a control status value of 4 (control operation not supported for this point). It is the hosts’ responsibility to determine the appropriate control mechanism. It is also the hosts’ responsibility to perform select before operate control when it is unacceptable to have the control point operated more than once. This is typically a configuration item in the host and is the responsibility of the end user to configure properly. It is the outstations’ responsibility to perform the control operation if a correct control dialog has been issued from the host. If the DUT is configurable in a manner such that points can be uninstalled or disabled, the device must be configured with at least one Binary Output point installed or enabled before proceeding with the test procedure.


8.2.1 Select Before Operate Select before operate control is used under circumstances when it is absolutely imperative that the control point operate only once. An example of this is a recloser. The host first initiates the select portion of the dialog. The outstation then echoes the exact control request byte for byte to the host. Note that the encapsulation information need not match, but that the object, variation, qualifier, and all object data must match exactly. The host then sends the execute portion of the dialog. The object, variation, qualifier, and all object data must match exactly byte for byte the data sent in the select message. If this message matches the select message byte for byte and it is received within the configured acceptable delay between select and execute the outstation must operate the control point.

8.2.1.1 Desired Behavior The following assumes that the device does not support control operations:

• If the device does not support control outputs, it must respond to a select with an Error Response setting IIN2-1. • An Error Response with IIN2-2 set is an invalid response. • No further testing in this section is necessary.

The following assumes that the device supports control operations:

• The maximum select to execute delay time must be specified in the Device Profile Document. • The DUT responds to matching select and execute requests by echoing each request with the status field set to

0. The specified control operates. • The DUT responds to selecting an uninstalled control point by returning an error response with IIN2-2 set and a

status code of 4. The control point does not operate. • The DUT responds to executing an installed control point after the configured acceptable select to execute delay

by echoing the execute and setting the status field to 1 [Execute received after timeout]. The control point does not operate

• The DUT responds to a non-matching execute with a status field of 2 [No previous matching select] and does not operate the control under the following conditions:

• No prior select issued • On time mismatch • Off time mismatch • Control code mismatch • The DUT operates various selected control points. • The DUT supports 8 and 16 bit point indexing.

The following assumes that the device supports control operations and were added as a result of Technical Bulletin TB2000-002 (Control Retries):

• The DUT must accept retries on the select portion of the control dialog that increment the application sequence number between retries. In this case the select-to-operate timer must be restarted after reception of each select.

• The DUT must accept retries on the select portion of the control dialog that do not increment the application sequence number between retries. In this case the select-to-operate timer must remain unaltered by the reception of each additional select.

• The DUT must reject any operate that does not: $ contain a application layer sequence number that is exactly one greater (modulo 16) than the previously

accepted select. $ match the object portion of the select message byte for byte, excluding the application header.

• The DUT must accept retries on the operate portion of the control dialog that does not increment the application sequence number between retries. The DUT must echo the operate command but must not operate the control more than once.

The following assumes that the device does support control operations, however there are no control points installed/enabled:

• If the device does not have any control outputs installed, it must respond to a select with an Error Response setting IIN2-1 or IIN2-2.



8.2.1.2.1 Binary Output, SBO, 0x28 1. Issue a select using Object 12 Variation 1 to an installed point using 16 bit indexing (qualifier 0x28), a control code

supported by the device and an appropriate on time/off time. 2. If the device does not support control outputs, verify that the DUT responds with a Error Response with IIN2-1 set.

End testing of Binary Output SBO. 3. Verify that the DUT responds by echoing the select message exactly. 4. Immediately issue a matching execute. 5. Verify that the DUT echoes the execute. 6. Verify that the selected control operates.

8.2.1.2.2 Binary Output, SBO, 0x17 1. Issue a select using Object 12 Variation 1 to a different installed point using 8 bit indexing (qualifier 0x17), a control

code supported by the device and an appropriate on time/off time. 2. If the device does support control outputs, verify that the DUT responds by echoing the select message exactly. 3. Immediately issue a matching execute. 4. Verify that the DUT echoes the execute. 5. Verify that the selected control operates.

8.2.1.2.3 Binary Output, SBO, To Uninstalled Point 1. Issue a select using Object 12 Variation 1 to an uninstalled point using 16 bit indexing (qualifier 0x28) using a

control code supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of 4. 3. Verify that no control point operates.

8.2.1.2.4 Binary Output, SBO, Execute Issued After Timeout 1. Issue a select using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code

supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Wait 1 second past the configured maximum select to execute delay time. 4. Issue a matching execute and verify that the DUT echoes the execute with the control status field set to 1[Execute

received after timeout]. 5. Verify that no control point operates.

8.2.1.2.5 Binary Output, SBO, Execute to Different Point Than Select 1. Issue a select to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code

supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 12 Variation 1 to a different installed point using 8 bit indexing (qualifier

0x17), the same control code as the select, and the same on time/off time as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.

8.2.1.2.6 Binary Output, SBO, Execute On Time does not match Select On Time 1. Issue a select using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code

supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue a execute to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), the

same control code as the select, the on time incremented by 1 and the same off time as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.


8.2.1.2.7 Binary Output, SBO, Execute Off Time does not match Select Off Time 1. Issue a select using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code

supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), the

same control code as the select, same on time as the previous select and the off time incremented by 1. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.

8.2.1.2.8 Binary Output, SBO, Select using a supported Control Code, Execute using a different Control Code

1. Issue a select using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control code supported by the device and an appropriate on time/off time.

2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a

control code different from the previous select, and the same on time/off time as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.

8.2.1.2.9 Binary Output, SBO, Select 0x28, Execute 0x17 1. Issue a select using Object 12 Variation 1 to an installed point using 16 bit indexing (qualifier 0x28), a control code

supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a

control code supported by the device and the same on time/off time as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. Verify that no control point operates.

8.2.1.2.10 Binary Output, SBO, Configurable Device 1. If the device is not configurable in a manner such that control points can be uninstalled or disabled, skip this section. 2. Configure the DUT such that all Binary Output points are uninstalled or disabled. 3. Issue a select using Object 12 Variation 1 to point 0 using 16 bit indexing (qualifier 0x28), a control code supported

by the device and an appropriate on time/off time. 4. Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set. 5. Verify that no control point operates.

8.2.1.2.11 Binary Output, SBO, Same Sequence Number Select Retries 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again using the same application layer sequence number. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the binary output.

8.2.1.2.12 Binary Output, SBO, Incrementing Sequence Number Select Retries 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again incrementing the application layer sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the select byte for byte.


6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the binary output.

8.2.1.2.13 Binary Output, SBO, Same Sequence Number Operate Retries 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the binary output. 7. Issue the operate again using the same application layer sequence number. 8. Verify that the DUT echoes the object portion of the operate byte for byte. 9. Verify that the DUT does not operate the binary output.

8.2.1.2.14 Binary Output, SBO, Incrementing Sequence Number Operate Retries 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the binary output. 7. Issue the operate again, incrementing the sequence number by 1 modulo 16. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO


8.2.1.2.15 Binary Output, SBO, Sequence number checking 1. If the DUT does not have installed binary output points, skip this section. 2. Issue a valid select to an installed binary output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO

MATCHING SELECT). 6. Verify that the DUT does not operate the binary output. 7. Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the mismatched

operate cleared the previous select. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO



8.2.2.1 Desired Behavior The following behavior assumes that the device does not support control operation: • If the device does not support control outputs, it must respond to a direct operate with an Error Response setting

IIN2-1. • An Error Response with IIN2-2 set is an invalid response. • No further testing in this section is necessary.

The following behavior assumes that the device supports control operations: • The DUT responds to a direct operate to an uninstalled data point by returning an Error response with IIN2-2 set and

a status code of 4. The control does not operate.


• The DUT responds to a direct operate to an installed data point by echoing the direct operate and setting the status field to 0. The specified control operates.

The following behavior assumes that the device does support control operations, however there are no control points installed/enabled: • If the device does not have any control outputs installed, it must respond to a direct operate with an Error Response



8.2.2.2.1 Binary Output, Direct Operate 1. Issue a direct operate using Object 12 Variation 1 to an installed point using 8 bit indexing (qualifier 0x17), a control

code supported by the device and an appropriate on time/off time. 2. If the device does not support control outputs verify that the DUT responds with an Error Response with IIN2-1 set

and end testing of this section. 3. If the device does support control outputs verify that the DUT responds by echoing the direct operate message

exactly with status field of 0. 4. Verify that the specified control operates.

8.2.2.2.2 Binary Output, Direct Operate to Uninstalled Point 1. Issue a direct operate using Object 12 Variation 1 to an uninstalled point using 16 bit indexing (qualifier 0x28) using

a control code supported by the device and an appropriate on time/off time. 2. Verify that the DUT responds by returning an Error response with IIN2-2 set and a status code of 4. 3. Verify that no control operates.

8.2.2.2.3 Binary Output, Direct Operate, Configurable Device 1. If the device is not configurable in a manner such that control points can be uninstalled or disabled, end testing of

Binary Output, Direct Operate. 2. Configure the DUT such that all Binary Output points are uninstalled or disabled. 3. Issue a direct operate using Object 12 Variation 1 to point 0 using 16 bit indexing (qualifier 0x28) using a control

code supported by the device and an appropriate on time/off time. 4. Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set. 5. Verify that no control operates.


8.2.3.1 Desired Behavior • The DUT must not respond to in any way to the direct operate no acknowledge. • If the device supports binary outputs and the operate message is correct then the binary output point must operate.


8.2.3.2.1 Binary Output, Direct Operate, No Acknowledge 1. Issue a Direct Operate, No Acknowledge using Object 12 Variation 1 to an installed point using 8 bit indexing

(qualifier 0x17), a control code supported by the device and an appropriate on time/off time. 2. Verify that the DUT does not respond. 3. If the device does not support control outputs, end testing of this section. 4. If the device does support control outputs, verify that the proper control point operates.


8.2.3.2.2 Binary Output, Direct Operate, No Acknowledge, to an Uninstalled Point 1. Issue a Direct Operate, No Acknowledge using Object 12 Variation 1 to an uninstalled point using 16 bit indexing

(qualifier 0x28) using a control code supported by the device and an appropriate on time/off time. 2. Verify that the DUT does not respond. 3. Verify that no control operates.

8.2.3.2.3 Binary Output, Direct Operate, No Acknowledge, Configurable Device 1. If the device is not configurable in a manner such that control points can be uninstalled or disabled, end testing of

Binary Output, Direct Operate, No Acknowledge. 2. Configure the DUT such that all Binary Output points are uninstalled or disabled. 3. Issue a Direct Operate, No Acknowledge using Object 12 Variation 1 to point 0 using 16 bit indexing (qualifier

0x28) using a control code supported by the device and an appropriate on time/off time. 4. Verify that the DUT does not respond. 5. Verify that no control operates.


8.2.4.1 Desired Behavior • The DUT must parse requests for all control operations within a single frame. • Up to a full frame of request operations must be supported. The following assumes that the device supports control operations and were added as a result of Technical Bulletin TB2001-001 (Multiple Control Object and Status Codes):


• The DUT responds to a select to an uninstalled control point by returning an error response with IIN2-2 set and a status code of 4.

8.2.4.2 Test Procedure 1. Review the device’s profile document to understand how many control points are supported in a single request. If

this number is one, skip to step 7. 2. Determine the number of installed points that can be successfully controlled in a single request. This number shall

be the smaller of: • The number of controls supported in a single request • The number of installed control points • Sixteen In a single request, issue a select to the above number of points using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time.


4. Immediately issue a matching execute. 5. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set and that each object returns a status code of

0. 6. Verify that each of the selected controls operated. Note that controls may execute simultaneously or sequentially one

after the other. 7. If the number of control objects supported in a single request is greater than or equal to either

• The number of control objects that fit into a single frame or • The number of installed control points,


different index but otherwise able to be controlled, using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time.



10. If the DUT does not support direct operate, skip to step 13. 11. In a single request, issue a direct operate command to at least one more point than is supported in a single request,

each point having a different index but otherwise able to be controlled, using Object 12, Variation 1 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and an appropriate on time/off time.




8.2.5 Control Code Support

8.2.5.1 Desired Behavior The following assumes that the device supports control operations and were added as a result of Technical Bulletin TB2000-006 (CROB Control Codes):

• For complementary function indices, the Outstation must accept at least one of the following control code pairs: $ 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) $ 0x41 (Pulse On/Close) and 0x81 (Pulse On/Trip)

• The outstation may optionally accept both forms of complementary control code pairs. If it does:

$ control codes 0x03 (Latch On/NUL) and 0x41 (Pulse On/Close) must perform the same function $ control codes 0x04 (Latch Off/NUL) and 0x81 (Pulse On/Trip) must perform the same function

• For single function indices, the outstation must accept at least one of the following control codes:

$ 0x01 (Pulse On/NUL) $ 0x03 (Latch On/NUL) $ 0x04 (Latch Off/NUL) $ 0x41 (Pulse On/Close) $ 0x81 (Pulse On/Trip)

• If the outstation accepts more than one control code for a single function index, it must perform the same

function for each control code it accepts.


8.2.5.2.1 Binary Output, Complementary Function Support 1. If the DUT does not have installed binary output points skip this section. 2. If the DUT does not have installed complementary function binary output points skip this section. 3. If the DUT does not support the 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) pair skip to step 8. 4. Issue a valid control sequence to the first installed complementary function binary output point using control code

0x03 (Latch On/NUL). 5. Verify the control operation completes successfully. 6. Issue a valid control sequence to an installed complementary function binary output point using control code 0x04

(Latch Off/NUL). 7. Verify the complementary control operation completes successfully. 8. If the DUT does not support the 0x41(Pulse On/Close) and 0x81 (Pulse On/Trip) pair skip to step 13.


9. Issue a valid control sequence to an installed complementary function binary output point using control code 0x41(Pulse On/Close).

10. Verify the control operation completes successfully. 11. Issue a valid control sequence to an installed complementary function binary output point using control code 0x81

(Pulse On/Trip). 12. Verify the complementary control operation completes successfully. 13. If the DUT does not support both the 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) control code pair and the

0x41(Pulse On/Close) and 0x81 (Pulse On/Trip) control code pair skip to step the next section. 14. Issue a valid control sequence to an installed complementary function binary output point using control code 0x03

(Latch On/NUL). 15. Verify the control operation completes successfully. 16. Issue a valid control sequence to the same installed complementary function binary output point using control 0x81

(Pulse On/Trip). 17. Verify that the complementary control operation completes successfully. 18. Issue a valid control sequence to the same installed complementary function binary output point using control code

0x41(Pulse On/Close). 19. Verify the complementary control operation completes successfully. 20. Issue a valid control sequence to the same installed complementary function binary output point using control 0x04

(Latch Off/NUL). 21. Verify the complementary control operation completes successfully.

8.2.5.2.2 Binary Output, Single Function Support 1. If the DUT does not have installed binary output points skip this section. 2. If the DUT does not have installed single function binary output points skip this section. 3. For any point that is tested below, determine what action should happen when the control executes. 4. If the DUT does not support the 0x01 (Pulse On/NUL) control code for single function binary output points at this

index skip to step 7. 5. Issue a valid control sequence to the first installed single function binary output point using control code 0x01 (Pulse

On/NUL). 6. Verify the control operation in step 3 completes successfully. 7. If the DUT does not support the 0x03 (Latch On/NUL) control code for single function binary output points at this

index skip to step 10. 8. Issue a valid control sequence to the first installed single function binary output point using control code 0x03

(Latch On/NUL). 9. Verify the control operation in step 3 completes successfully. 10. If the DUT does not support the 0x04 (Latch Off/NUL) control code for single function binary output points at this

index skip to step 13. 11. Issue a valid control sequence to the first installed single function binary output point using control code 0x04

(Latch Off/NUL). 12. Verify the control operation in step 3 completes successfully. 13. If the DUT does not support the 0x41 (Pulse On/Close) control code for single function binary output points at this

index skip to step 16. 14. Issue a valid control sequence to the first installed single function binary output point using control code 0x41 (Pulse

On/Close). 15. Verify the control operation in step 3 completes successfully. 16. If the DUT does not support the 0x81 (Pulse On/Trip) control code for single function binary output points at this

index skip to the next section. 17. Issue a valid control sequence to the first installed single function binary output point using control code 0x81 (Pulse

On/Trip). 18. Verify the control operation in step 3 completes successfully.

8.3 Analog Output Status The Analog Output Status object represents the actual value of an analog output or software point and the associated status reported by an 8-bit flag field (repeated here for convenience): Page 22 DNP3-2001 IED CerRev 2.1 – 5-July-01

Flag Bit Value 0 ONLINE - 0=off-line, 1= on-line 1 RESTART - 0=normal, 1= restart 2 COMMUNCATION LOST - 0=normal, 1=lost 3 REMOTE FORCED DATA - 0=normal, 1=forced 4 LOCAL FORCED DATA - 0=normal, 1=forced 5 0 6 0 7 0

Table 8-2

8.3.1 Desired Behavior • If the device supports analog outputs the device must respond to an analog output read request with an analog output

object (object 40 variation 2) using qualifier 0x00 or 0x01. • If the device does not support analog outputs the device must respond to an analog output read request with a Null

Response or an Error Response with IIN2-1 or IIN2-2 set. • The value returned in the Analog Output Status must reflect the value written to the corresponding Analog Output

point within the tolerances specified by the manufacturer.

8.3.2 Test Procedure 1. Issue a Direct Operate to Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an

appropriate value. 2. Issue a request for Object 40 Variation 0 using the all data qualifier 0x06. 3. If the device supports Analog Outputs verify that the DUT responds with an Analog Output Status object (object 40


(qualifier 0x01). 5. If the device does not support Analog Outputs verify that the DUT responds with a Null Response. The device can

optionally return an Error Response with IIN2-1or IIN2-2 set. 6. Verify that the value returned in the Analog Output Status object reflects the value sent in step 1 within the

tolerances specified by the manufacturer.

8.4 Analog Outputs § If a device supports analog outputs, it is required to be configurable to support all three modes of operation, namely Select Before Operate, Direct Operate, and Direct Operate no Acknowledgment. A device may be configurable to disable any subset of the modes. If a device has been configured to reject a particular mode, it must return a control status value of 4 (control operation not supported for this point). It is the hosts’ responsibility to determine the appropriate analog output mechanism. It is also the hosts’ responsibility to perform select before operate control when it is unacceptable to have the analog output point operate more than once. This is typically a configuration item in the host and is the responsibility of the end user to configure properly. It is the outstations’ responsibility to perform the analog output operation if a correct control dialog has been issued from the host. If the DUT is configurable in a manner such that points can be uninstalled or disabled, the device must be configured with at least one Analog Output point installed or enabled before proceeding with the test procedure.

8.4.1 Select Before Operate The host first initiates the select portion of the dialog. The outstation then echoes the exact analog output request byte for byte to the host. Note that the encapsulation information need not match, but that the object, variation, qualifier, and all object data must match exactly. The host then sends the execute portion of the dialog. The object, variation, qualifier, DNP3-2001 IED Certification Procedure Page 23 Subset Level 2 Rev 2.1 – 5-July-01

and all object data must match exactly byte for byte the data sent in the select message. If the execute message matches the select message byte for byte and it is received within the configured acceptable delay between select and execute, the outstation operates the analog output point.

8.4.1.1 Desired Behavior The following behavior assumes that the device does not support analog output operations: • If the device does not support analog outputs it must respond to a select with an Error Response setting IIN2-1. • An Error Response with IIN2-2 set is an invalid response. • No further testing in this section is necessary. The following behavior assumes that the device supports analog output operations: • The maximum select to execute delay time must be specified in the Device Profile Document. • The DUT responds to matching select and execute requests by echoing each request with the status field set to 0.

The specified analog output operates. • The DUT responds to selecting an uninstalled analog output point by returning an error response with IIN2-2 set and

a status code of 4. The analog output point does not operate. • The DUT responds to executing an installed analog output point after the configured acceptable select to execute

delay by echoing the execute and setting the status field to 1[Execute received after timeout]. The analog output does not operate.

• The DUT responds to a non-matching execute with a status field of 2 [No previous matching select] and does not operate the analog output under the following conditions: • No prior select issued. • Value does not match. • The DUT operates various selected analog output points. • The DUT supports 8 and 16 bit point indexing.

The following assumes that the device supports analog output operations and were added as a result of Technical Bulletin TB2000-002 (Control Retries): • The DUT must accept retries on the select portion of the analog output dialog that increment the application

sequence number between retries. In this case the select-to-operate timer must be restarted after reception of each select.

• The DUT must accept retries on the select portion of the analog output dialog that do not increment the application sequence number between retries. In this case the select-to-operate timer must remain unaltered by the reception of each additional select.

• The DUT must reject any operate that does not • contain a application layer sequence number that is exactly one greater (modulo 16) than the previously

accepted select. • match the object portion of the select message byte for byte, excluding the application header.

• The DUT must accept retries on the operate portion of the analog output dialog that does not increment the application sequence number between retries. The DUT must echo the operate command but must not operate the analog output more than once.

The following behavior assumes that the device does support analog output operations, however there are no analog output points installed/enabled: • If the device does not have any analog outputs installed, it must respond to a select with an Error Response setting

IIN2-1 or IIN2-2.


8.4.1.2.1 Analog Output, SBO, 0x28 1. Issue a select using Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an

appropriate value.


2. If the device does not support analog outputs verify that the DUT responds with an Error Response with IIN2-1 set. End testing of Analog Outputs.

3. Verify that the DUT responds by echoing the select message exactly. 4. Immediately issue a matching execute. 5. Verify that the DUT echoes the execute. 6. Verify that the selected analog output operates.

8.4.1.2.2 Analog Output, SBO, 0x17 1. Issue a select using Object 41 Variation 2 to a different point using 8 bit indexing (qualifier 0x17) and an

appropriate value. 2. If the device does support analog outputs, verify that the DUT responds by echoing the select message exactly. 3. Immediately issue a matching execute. 4. Verify that the DUT echoes the execute. 5. Verify that the selected analog output operates.

8.4.1.2.3 Analog Output, SBO, to Uninstalled Point 1. Issue a select using Object 41 Variation 2 to an uninstalled point using 16 bit indexing (qualifier 0x28) and an

appropriate value. 2. Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of 4. 3. If an analog output is observed to operate, the test fails.

8.4.1.2.4 Analog Output, SBO, Execute Issued After Time-out 1. Issue a select using Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an

appropriate value. 2. Verify that the DUT responds by echoing the select message exactly. 3. Wait 1 second past the configured maximum select to execute delay time. 4. Issue a matching execute and verify that the DUT echoes the execute with the status field set to 1 [Execute received

after timeout]. 5. If an analog output is observed to operate, the test fails.

8.4.1.2.5 Analog Output, SBO, Execute Value does not match Select Value 1. Issue a select using Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an

appropriate value. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and

the same value incremented by 1. 4. Verify that the DUT echoes the execute with the status field set to 2 [No previous matching select]. 5. If an analog output is observed to operate, the test fails.

8.4.1.2.6 Analog Output, SBO, Select 0x28, Execute 0x17 1. Issue a select using Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an

appropriate value. 2. Verify that the DUT responds by echoing the select message exactly. 3. Immediately issue an execute to Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and

the same value as the previous select. 4. Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select]. 5. If an analog output is observed to operate, the test fails.

8.4.1.2.7 Analog Output, SBO, Configurable Device 1. If the device is not configurable in a manner such that analog output points can be uninstalled or disabled, skip this

section. 2. Configure the DUT such that all Analog Output points are uninstalled or disabled.


3. Issue a select using Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier 0x28) and an appropriate value.

4. Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set. 5. If an analog output is observed to operate, the test fails.

8.4.1.2.8 Analog Output, SBO, Same Sequence Number Select Retries 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again using the same application layer sequence number. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the analog output.

8.4.1.2.9 Analog Output, SBO, Incrementing Sequence Number Select Retries 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue the select again incrementing the application layer sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the select byte for byte. 6. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 7. Verify that the DUT echoes the object portion of the operate byte for byte. 8. Verify that the DUT operates the analog output.

8.4.1.2.10 Analog Output, SBO, Same Sequence Number Operate Retries 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the analog output. 7. Issue the operate again using the same application layer sequence number. 8. Verify that the DUT echoes the object portion of the operate byte for byte. 9. Verify that the DUT does not operate the analog output.

8.4.1.2.11 Analog Output, SBO, Incrementing Sequence Number Operate Retries 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte. 6. Verify that the DUT operates the analog output. 7. Issue the operate again, incrementing the sequence number by 1 modulo 16. 8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO


8.4.1.2.12 Analog Output, SBO, Sequence number checking 1. If the DUT does not have installed analog output points, skip this section. 2. Issue a valid select to an installed analog output point. 3. Verify that the DUT echoes the object portion of the select byte for byte. 4. Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16. 5. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO

MATCHING SELECT). 6. Verify that the DUT does not operate the analog output. Page 26 DNP3-2001 IED CerRev 2.1 – 5-July-01

7. Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the mismatched operate cleared the previous select.

8. Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO MATCHING SELECT).

9. Verify that the DUT does not operate the analog output.


8.4.2.1 Desired Behavior The following assumes that the device does not support analog output operations: • If the device does not support analog outputs, it must respond to a direct operate with an Error Response setting

IIN2-1. • No further testing in this section is necessary.

The following assumes that the device supports analog output operations: • The DUT responds to a Direct Operate to an installed analog output point echoing the direct operate and setting the

status field to 0. The specified analog output operates. • The DUT responds to a Direct Operate to an uninstalled analog output point by returning an Error Response with

IIN2-2 set and a status code of 4. No analog outputs shall be observed to operate. • The DUT operates various analog output points. The following assumes that the device does support analog output operations, however there are no analog output points installed/enabled: • If the device does not have any analog outputs installed, it must respond to a direct operate with an Error Response



8.4.2.2.1 Analog Output, Direct Operate 1. Issue a Direct Operate to Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an

appropriate value. 2. If the device does not support analog output verify that the DUT responds with an Error Response with IIN2-1 set

and end testing of this section. 3. If the device does support analog outputs verify that the DUT responds by echoing the direct operate message

exactly with status field of 0. 4. Verify that the specified analog output operates.

8.4.2.2.2 Analog Output, Direct Operate, to Uninstalled Point 1. Issue a Direct Operate to Object 41 Variation 2 to an uninstalled point using 16 bit indexing (qualifier 0x28) and an

appropriate value. 2. Verify that the DUT responds by return an Error Response with IIN2-2 set and a status code of 4. 3. If an analog output is observed to operate, the test fails.

8.4.2.2.3 Analog Output, Direct Operate, Configurable Device 1. If the device is not configurable in a manner such that analog output points can be uninstalled or disabled, end

testing of Analog Output, Direct Operate. 2. Configure the DUT such that all Analog Output points are uninstalled or disabled. 3. Issue a direct operate to Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier 0x28) and an appropriate

value. 4. Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set. 5. If an analog output is observed to operate, the test fails.



8.4.3.1 Desired Behavior • The DUT must not respond in any way to the direct operate no acknowledge. • If the device supports analog outputs and the operate message is correct then the analog output point must operate.


8.4.3.2.1 Analog Output, Direct Operate, No Acknowledge 1. Issue a Direct Operate No Acknowledge using Object 41 Variation 2 to an installed point using 8 bit indexing

(qualifier 0x17) and an appropriate value. 2. Verify that the DUT does not respond. 3. If the device does support analog outputs, end testing of this section. 4. If the device does support analog outputs, verify that the proper analog output point operates.

8.4.3.2.2 Analog Output, Direct Operate, No Acknowledge, to an Uninstalled Point 1. Issue a Direct Operate No Acknowledge using Object 41 Variation 2 to an uninstalled point using 16 bit indexing

(qualifier 0x28) and an appropriate value. 2. Verify that the DUT does not respond. 3. If an analog output is observed to operate, the test fails.

8.4.3.2.3 Analog Output, Direct Operate, No Acknowledge, Configurable Device 1. If the device is not configurable in a manner such that control points can be uninstalled or disabled, end testing of

Analog Output, Direct Operate, No Acknowledge. 2. Configure the DUT such that all Analog Output points are uninstalled or disabled. 3. Issue a Direct Operate No Acknowledge using Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier

0x28) using a control code supported by the device and an appropriate on time/off time. 4. Verify that the DUT does not respond. 5. If an analog output is observed to operate, the test fails.


8.4.4.1 Desired Behavior • The DUT must parse requests for all writes within a single frame • Up to a full frame of request operations must be supported The following assumes that the device supports analog output operations and were added as a result of Technical Bulletin TB2001-001 (Multiple Control Object and Status Codes):


• The DUT responds to a select to an uninstalled analog output point by returning an error response with IIN2-2 set and a status code of 4.

8.4.4.2 Test Procedure 1. Review the device’s profile document to understand how many analog output points are supported in a single

request. If this number is one, skip to step 7. 2. Determine the number of installed points that can be successfully controlled in a single request. This number shall

be the smaller of: • The number of controls supported in a single request • The number of installed control points • Sixteen


In a single request, issue a select to the above number of points using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28), a control code supported by the device, and a value supported by the device


4. Immediately issue a matching execute. 5. Verify that the DUT response has none of IIN2-0, IIN2-1, or IIN2-2 set and that each object returns a status code of

0. 6. Verify that each of the selected analog outputs occurred. . Note outputs may occur simultaneously or sequentially

one after the other. 7. If the number of control objects supported in a single request is greater than or equal to either:

• The number of control objects that fit into a single frame or • The number of installed control points


different index but otherwise able to be outputted, using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28) and an appropriate value.


10. If the DUT does not support direct operate, skip to step 13. 11. In a single request, issue a direct operate command to at least one more point than is supported in a single request,

each point having a different index but otherwise able to be outputted, using Object 41, Variation 2 and 16-bit indexing (qualifier 0x28) and an appropriate value.




8.5 Class Data

8.5.1 Class 0 This request is used to read all static data from a device. The device must respond with the current state of its data when this object is requested. § Any device that generates more than one link layer frame in response to a Class 0 Poll must support report-by-exception on all points. It is highly recommended that devices perform report by exception processing internally and respond to class polls with event data as defined in section 3.4. This allows efficient use of bandwidth. When no events are pending the device responds with the Null Response. Acceptable object variations and qualifier combinations included in a device response are specified in the following table. Numbers preceded by 0x are in hex.


Object Variation Qualifier Single-Bit Binary Input 1 1 0x00,0x01 Binary Input with Status 1 2 0x00,0x01

Binary Output Status 10 2 0x00,0x01 32-Bit Binary Counter 20 1 0x00,0x01 16-Bit Binary Counter 20 2 0x00,0x01 32-Bit Delta Counter 20 3 0x00,0x01 16-Bit Delta Counter 20 4 0x00,0x01

32-Bit Binary Counter w/o Flag 20 5 0x00,0x01 16-Bit Binary Counter w/o Flag 20 6 0x00,0x01 32-Bit Delta Counter w/o Flag 20 7 0x00,0x01 16-Bit Delta Counter w/o Flag 20 8 0x00,0x01

32-Bit Analog Input 30 1 0x00,0x01 16-Bit Analog Input 30 2 0x00,0x01

32-Bit Analog Input w/o Flag 30 3 0x00,0x01 16-Bit Analog Input w/o Flag 30 4 0x00,0x01 16-Bit Analog Output Status 40 2 0x00,0x01

Table 8-3

8.5.1.1 Desired Behavior • Device responds to a Class 0 poll with the current state of all data.

8.5.1.2 Test Procedure 1. Issue a request for Object 60 Variation 1 using the all data qualifier 0x06. 2. Verify that the device responds with the current state of its inputs using only the object, variation and qualifier

variations specified in table 8-3. 3. Verify that flag behavior complies with Section 2, Note #5.

8.5.2 Class 1 This request is used to read change or event data from a device. The device must respond with events that have occurred since the last poll/confirm sequence. If the response is not null, verify that the device requests an application layer confirm. If the response is null, the request for the application layer confirm is optional and may be eliminated to reduce bandwidth. Points can be assigned to a class by configuration and through the protocol. Neither is required for compliance. The minimum level of compliance is for the device to respond with a Null Response. § Any device that generates more than one link layer frame in response to a Class 0 Poll must support report-by-exception on all points. It is highly recommended that devices perform report by exception processing internally and respond to class polls with event data as defined in section 3.4. This allows efficient use of bandwidth. When no events are pending the device responds with the Null Response. If a device can be configured to generate Application Layer retries, this feature must be disabled for all tests in this section unless otherwise specified. Acceptable object variations and qualifier combinations included in a device response are specified in the following table. Numbers preceded by 0x are in hex.


Object Variation Qualifier Binary Input Change w/o Time 2 1 0x17,0x28 Binary Input Change with Time 2 2 0x17,0x28

Binary Input Change with Relative Time 2 3 † 0x17,0x28 32-Bit Counter Change Event w/o Time 22 1 0x17,0x28 16-Bit Counter Change Event w/o Time 22 2 0x17,0x28

32-Bit Delta Counter Change Event w/o Time 22 3 ** 0x17,0x28 16-Bit Delta Counter Change Event w/o Time 22 4 ** 0x17,0x28

32-Bit Analog Change Event w/o Time 32 1 0x17,0x28 16-Bit Analog Change Event w/o Time 32 2 0x17,0x28

Time and Date CTO* 51 1 0x07 Unsynchronized Time and Date CTO* 51 2 0x07

Table 8-4 † Note: Use of the Binary Change with Relative Time Object (Object 2, Variation3) requires that a Common Time of Occurrence Object (Object 51, Variation01 or 02) precede it in the same APDU. This behavior must be verified in any response that contains a Binary Change with Relative Time Object. Binary Input changes more than 0xFFFF milliseconds apart must have a second CTO Object. * Note: Common Time of Occurrence ** Document error note: These objects are not listed in Table 2.3-1 (Level 2 Implementation) of the Subset Definitions Version 2.00 Document. However, these objects are included in Table 1.3-1 (Level 1 Implementation). The Subset document is in error – these objects are also valid for Level 2 devices.

8.5.2.1 Desired Behavior • § The device must respond with all of its change events when polled with the all data qualifier (0x06). • When polled with the limit data qualifiers (0x07 and 0x08), the device must respond with a quantity of its change

events no greater than specified in the request. • The device must request an application layer confirm for all responses that contain event data. Note: Application

layer confirms are always sent by the Master upon request from the Slave unless otherwise noted in this section. • The response point ordering shall be prioritized by time (oldest first). Note: A device is not required to return event data in any particular class.



exception processing. 3. If the DUT does not support Class 1 events, verify that it responds with a Null Response. No further testing is

required in this section. 4. If the DUT does support Class 1 events, verify that the device responds with all the event data in its event buffers or

responds with a Null Response. 5. If requested, issue an application layer confirm to empty the device of pending events. 6. Generate known Class 1 event data. 7. Issue another request for Object 60 Variation 2 using the all data qualifier 0x06. 8. Verify that the device responds with all the Class 1 event data generated in a single response. 9. Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first). 10. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 11. Verify that flag behavior complies with Section 2, Note #5.


12. § Verify that the device requests an application layer confirm. 13. Issue another request for Object 60 Variation 2 using the all data qualifier 0x06. 14. Verify that the DUT responds with a Null Response.



8.5.2.2.4 § Class 1 Data Without Confirm 1. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events. 4. Generate known Class 1 event data. 5. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 6. Verify that the device responds with all the Class 1 event data. 7. Verify that only objects in table 8-4 are returned. 8. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 9. Verify that flag behavior complies with Section 2, Note #5. 10. § Verify that the device requests an application layer confirm. 11. Do not issue an application layer confirm to the device. 12. Wait for a period of time exceeding several of the Application Layer retry delays, if one exists. 13. Verify that the device has not retransmitted the previous Application Layer fragment. 14. Generate additional Class 1 event data. 15. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 16. Verify that the device responds with the same Class 1 event data and the additional data generated in step 14. Page 32 DNP3-2001 IED CerRev 2.1 – 5-July-01

17. § Verify that the device requests an application layer confirm. 18. Issue an application layer confirm to empty the device of pending events. 19. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 20. Verify that the device responds with a Null Response.













8.5.3.2.4 § Class 2 Data Without Confirm 1. Issue a request for Object 60 Variation 3 using the all data qualifier 0x06. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events. 4. Generate known Class 2 event data. 5. Issue a request for Object 60 Variation 3 using the all data qualifier 0x06. 6. Verify that the device responds with all the Class 2 event data. 7. Verify that only objects in table 8-4 are returned. 8. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 9. Verify that flag behavior complies with Section 2, Note #5. 10. § Verify that the device requests an application layer confirm. 11. Do not issue an application layer confirm to the device. 12. Wait for a period of time exceeding several of the Application Layer retry delays, if one exists. 13. Verify that the device has not retransmitted the previous Application Layer fragment. 14. Generate additional Class 2 event data. 15. Issue a request for Object 60 Variation 3 using the all data qualifier 0x06. 16. Verify that the device responds with the same Class 2 event data and the additional data generated in step 14. 17. § Verify that the device requests an application layer confirm. 18. Issue an application layer confirm to empty the device of pending events. 19. Issue a request for Object 60 Variation 3 using the all data qualifier 0x06. 20. Verify that the device responds with a Null Response. Page 34 DNP3-2001 IED CerRev 2.1 – 5-July-01










8.5.4.2.2 Class 3 Data, 0x07 1. Issue a request for Object 60 Variation 4 using the all data qualifier 0x06 to empty the device of pending events. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events.


4. Generate several Class 3 events. 5. Issue a request for Object 60 Variation 4 using the limit data qualifier 0x07 requesting some changes. 6. Verify that the device responds with the requested Class 3 events in a single response. 7. Verify that only objects in table 8-4 are returned. 8. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 9. Verify that flag behavior complies with Section 2, Note #5. 10. § Verify that the device requests an application layer confirm. 11. Issue a request for Object 60 Variation 4 using the limit data qualifier 0x07 requesting the remaining changes. 12. Verify that device responds with the remaining Class 3 events. 13. § Verify that the device requests an application layer confirm. 14. Issue another request for Object 60 Variation 4 using the all data qualifier 0x06. 15. Verify that the DUT responds with a Null Response.


8.5.4.2.4 § Class 3 Data Without Confirm 1. Issue a request for Object 60 Variation 4 using the all data qualifier 0x06. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events. 4. Generate known Class 3 event data. 5. Issue a request for Object 60 Variation 4 using the all data qualifier 0x06. 6. Verify that the device responds with all the Class 1 event data. 7. Verify that only objects in table 8-4 are returned. 8. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 9. Verify that flag behavior complies with Section 2, Note #5. 10. § Verify that the device requests an application layer confirm. 11. Do not issue an application layer confirm to the device. 12. Wait for a period of time exceeding several of the Application Layer retry delays, if one exists. 13. Verify that the device has not retransmitted the previous Application Layer fragment. 14. Generate additional Class 3 event data. 15. Issue a request for Object 60 Variation 4 using the all data qualifier 0x06. 16. Verify that the device responds with the same Class 1 event data and the additional data generated in step 14. 17. § Verify that the device requests an application layer confirm. 18. Issue an application layer confirm to empty the device of pending events. 19. Issue a request for Object 60 Variation 4 using the all data qualifier 0x06. 20. Verify that the device responds with a Null Response.

8.5.5 Multiple Object Request This test verifies that the device can parse multiple object requests.


Note: If Binary Inputs can be configured in more than one class, they must be configured for at least one of each class for these tests.

8.5.5.1 Desired Behavior • The device must respond to a multiple object request in a single response. • For binary points, all events reported within a single application fragment will be sent in the chronological order of

occurrence of those events (oldest first). • § When a device generates multiple analog or counter events for the same point, all events for the same point will be

sent in the chronological order of occurrence of those events (oldest first).


8.5.5.2.1 Multiple Object Request, Class 1, 2, and 3 1. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events. 4. Generate known event data that includes events from all three classes. 5. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06. 6. Verify that the device responds with all the event data as described in the Desired Behavior. 7. Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first). 8. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 9. Verify that flag behavior complies with Section 2, Note #5. 10. § Verify that the device requests an application layer confirm. 11. Issue an application layer confirm to empty the device of pending events.

8.5.5.2.2 Multiple Object Request, Class 1, 2, 3, and 0 1. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06. 2. § If the response is not Null, verify that the device requests an application layer confirm. 3. If requested, issue an application layer confirm to empty the device of pending events. 4. Generate known event data that includes events from classes 1, 2, and 3. 5. Issue a request for Object 60 Variations 2,3,4, and 1 using the all data qualifier 0x06. 6. Verify that the device responds with all the event data as described in the Desired Behavior. 7. Verify that all static data is returned after all event data in the same response. 8. Verify that the response has the same application sequence number as the request. If the request generates multiple

application fragments verify that the application sequence number of each subsequent fragment increments by 1 modulo 16.

9. Verify that only objects in table 8-4 are returned. 10. Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28) for

event data and 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing (qualifier 0x01) for static data. 11. Verify that flag behavior complies with Section 2, Note #5. 12. § Verify that the device requests an application layer confirm. 13. Issue an application layer confirm to empty the device of pending events.

8.5.6 Class Assignment Verification

8.5.6.1 Desired Behavior • The device must respond to a request for Class 1 events with only Class 1 events. • The device must respond to a request for Class 2 events with only Class 2 events. • The device must respond to a request for Class 3 events with only Class 3 events.


8.5.6.2 Test Procedure 1. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending

events. 2. Verify that only objects in table 8-4 are returned. 3. § If the response is not Null, verify that the device requests an application layer confirm. 4. Generate some Class 1 events. 5. Generate some Class 2 events. 6. Generate some Class 3 events. 7. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 8. Verify that the device responds with only Class 1 events in a single response. 9. Verify that only objects in table 8-4 are returned. 10. § Verify that the device requests an application layer confirm. 11. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 12. Verify that the device responds with a Null Response. 13. Issue a request for Object 60 Variation 3 using the all data qualifier 0x06. 14. Verify that the device responds with only Class 2 events in a single response. 15. Verify that only objects in table 8-4 are returned. 16. § Verify that the device requests an application layer confirm. 17. Issue a request for Object 60 Variation 3 using the all data qualifier 0x06. 18. Verify that the device responds with a Null Response. 19. Issue a request for Object 60 Variation 4 using the all data qualifier 0x06. 20. Verify that the device responds with only Class 3 events in a single response. 21. Verify that only objects in table 8-4 are returned. 22. § Verify that the device requests an application layer confirm. 23. Issue a request for Object 60 Variation 4 using the all data qualifier 0x06. 24. Verify that the device responds with a Null Response. 25. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06. 26. Verify that the device responds with a Null Response.

8.6 Indications The Internal Indications is an information element used to convey internal states and diagnostic results of a device. If a specific indication is not supported it must be reported as de-asserted (0) in all cases.

8.6.1 Restart The Restart Bit of the Internal Indications field is set to 1 when the user application at the device restarts, i.e. a device's input power is cycled. This bit is cleared when the master station writes a 0 into this location.

8.6.1.1 Desired Behavior • The DUT, after a power cycle, must set IIN1-7. • The host can clear this bit by writing to the Internal Indications Object (Object 80, Variation 01).

8.6.1.2 Test Procedure 1. Cycle the power to the DUT. 2. Issue a request for Object 60 Variation 2. 3. Verify that the device responds with IIN1-7 set indicating that the device has been restarted. 4. Issue a Write to Object 80 Variation 1 using the qualifier 0x00. Use a start index of 7 and a stop index of 7, followed

by the value 0. 5. Verify that the device responds with a Null Response and that IIN1-7 is cleared.


8.6.2 Bad Function

8.6.2.1 Desired Behavior • If a device receives a message containing an unsupported function code it must return an Error Response with IIN2-

0 set. • After a device has issued a message containing a valid function code, the response shall have no Error IIN bits set.

8.6.2.2 Test Procedure 1. Issue a request for Object 60 Variation 1, Qualifier 0x06, using a Function Code of 0x70. 2. Verify that the device responds with an Error Response with IIN2-0 set indicating that the device has received a

message containing a bad function code. 3. Issue a request for Object 60 Variation 1, Qualifier 0x06, using a Function Code of 0x01. 4. Verify that the device responds with none of the Error IIN bits set.

8.6.3 Object Unknown

8.6.3.1 Desired Behavior • If a device receives a message containing an unknown object, it must return an Error Response with IIN2-1 set. • After a device has issued a message containing a valid function code, the response shall have no Error IIN bits set.

8.6.3.2 Test Procedure 1. Issue a request for Object 0 Variation 0, Function Code 0x01. 2. Verify that the device responds with an Error Response with IIN2-1 set indicating that the device has received a

message containing an unknown Object code. 3. Issue a request for Object 60 Variation 1. 4. Verify that the device responds with none of the Error IIN bits set.

8.6.4 Local

8.6.4.1 Desired Behavior • If the device supports control outputs and supports placing them in a local or disabled stated then it must set IIN1-5

whenever some or all of the control outputs are in the Local or Disabled state.

8.6.4.2 Test Procedure for Devices with Global Remote Supervisory Control 1. If the DUT does not support placing its binary outputs in a local state no further testing is required in this section. 2. If the DUT supports a global feature for enabling or disabling remote supervisory control, ensure that this is set to

the “Enabled” or “Remote” mode. 3. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 4. Verify that the device responds with a valid message and that IIN1-5 is cleared. 5. Change the DUT’s global switch to the “Disabled” or “Local” mode. 6. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 7. Verify that the device responds with a valid message and that IIN1-5 is set.

8.6.4.3 Test Procedure for Devices with Individual Remote Supervisory Control 1. If the DUT does not support placing its binary outputs in a local state, no further testing is required in this section. 2. If the device allows for individual control point remote supervisory control, all points should be set to the “Enabled”

or “Remote” mode. 3. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 4. Verify that the device responds with a valid message. No binary output status bits should be set.


5. Change a single remote supervisory control switch to the “Disabled” or “Local” mode.

6. Issue a request for Object 10 Variation 0 using the all data qualifier 0x06. 7. Verify that the device responds with a valid message and that the appropriate binary output status bit is set.

8.6.5 Broadcast Address and All Stations Indication

8.6.5.1 Desired Behavior The DUT must execute any request sent to the broadcast address •

• • • •

•

§ The DUT must not respond in any way to any request sent to the broadcast address The DUT must set the All Stations Internal Indication (IIN1-0) in the next response it transmits The DUT must clear the All Stations Internal Indication on the next response following the one in which it was set. § Messages sent to address 0xFFFE require that the IIN1-0 bit must be returned with the application layer request for confirmation bit (Application Control, bit 5) set. IIN1-0 may not be cleared in the slave until the confirmation is received. § Messages sent to address 0xFFFD request the IIN1-0 bit to be returned with the application layer request for confirmation bit (Application Control, bit 5) suppressed. IIN1-0 will be cleared in the slave upon transmitting the first response from the slave. Note: IIN1-0 may be reported in conjunction with responses to requests that otherwise require confirmation, or with an unsolicited event report, and since these requests/responses otherwise require confirmation, the confirmation will not be suppressed even though the message is sent with IIN1-0 set. Thus the use of the FFFD broadcast address implies that confirmation requests in responses sent with the IIN1-0 set should be suppressed, but that the confirmation may be requested if required by the details of the response being issued.

8.6.5.2 § Test Procedure 1. Cycle the power to the DUT. 2. Issue a link reset using link control block 0xC0. 3. Issue a request for Object 60 Variation 2. 4. Verify that the device responds with IIN1-7 set indicating the device has been restarted. 5. Issue a Write to Object 80 Variation 1 using the qualifier 0x00. Use a start index of 7 and a stop index of 7, followed

by the value 0 using the broadcast address (0xFFFF). Request a data link layer confirmation. 6. Wait a reasonable application layer timeout, for example, 2 seconds. 7. Verify that the device does not respond, with either a data link layer confirmation or a response to the Write

operation. 8. Issue a request for Object 60 Variation 2. 9. Verify the DUT responds with a valid response with IIN1-7 (restart) cleared and IIN1-0 (all stations message

received) set. 10. Send an application layer confirmation if requested. 11. Issue a request for Object 60 Variation 2. 12. Verify the DUT responds with a Null Response with both IIN1-7 and IIN1-0 cleared.

8.6.5.3 Test Procedure 1. Issue a Direct Operate No Acknowledgement using Object 12 Variation 1 to an installed point using 8-bit indexing

(qualifier 0x17), a control code supported by the device and an appropriate on/off-time using the broadcast address (0xFFFF). If the device does not support control outputs, perform this operation using Object 41 Variation 2.

2. Verify the requested output operation was executed. 3. Wait a reasonable application layer timeout, for example, 2 seconds. 4. Verify that the device does not respond. 5. Issue a request for Object 60 Variation 2. 6. Verify the DUT responds with IIN1-0 (all stations message received) set. 7. Send an application layer confirmation if requested. 8. Issue a request for Object 60 Variation 2. 9. Verify the DUT responds with a Null Response with IIN1-0 cleared.

8.6.5.4 § Test Procedure, Confirmed Response Options 1. Cycle the power to the DUT.


2. Issue a link reset using link control block 0xC0. 3. Issue a request for Object 60 Variation 2. 4. Verify that the device responds with IIN1-7 set indicating the device has been restarted. 5. Issue a Write to Object 80 Variation 1 using the qualifier 0x00. Use a start index of 7 and a stop index of 7, followed

by the value 0. Specify broadcast address FFFE. Request a data link layer confirmation. 6. Wait a reasonable application layer timeout, for example, 2 seconds. 7. Verify that the device does not respond, with either a data link layer confirmation or a response to the Write

operation. 8. Issue a request for Object 60 Variation 2. 9. Verify the DUT responds with a Null Response with IIN1-7 (restart) cleared and IIN1-0 (all stations message

received) set, and an application layer confirmation requested. 10. Before sending the requested confirmation, repeat the request for Object 60 Variation 2, and verify that IIN1-0 is

still set in the response. 11. Send the application layer confirmation. 12. Issue a request for Object 60 Variation 2. 13. Verify the DUT responds with a Null Response with both IIN1-7 and IIN1-1 cleared. 14. Repeat steps 1-13 using address FFFD as the broadcast address. In step 9, verify that an application layer

confirmation is NOT requested. In step 10, verify that IIN1-0 is not set in the response. Note: Step 11 will not be necessary.

8.6.6 Buffer Overflow The Buffer Overflow Bit of the Internal Indications field is set to 1 when any event buffers overflow such that change event data is subsequently being lost. This bit is cleared when the master station confirms change event data from the DUT, hence making event buffer space available.

8.6.6.1 Desired Behavior • The DUT must set IIN2-3 after a given event buffer overflows such that change events are being lost. • The DUT must clear IIN2-3 after a master confirms a change event(s) from the DUT such that event buffer space is

made available.


8.6.6.2.1 Buffer Overflow, Binary Input Change Event Buffers 1. If the device does not support Binary Input Change Events, end testing of Buffer Overflow, Binary Input Change

Event Buffers. 2. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending

events. 3. Obtain the maximum Binary Input Change Event buffer size from the device documentation and generate this

number of corresponding events on the DUT. 4. Issue a request for Object 60 Variation x (appropriate Class) using the all data qualifier 0x06, but DO NOT issue an

application confirm to the device. 5. Verify that IIN2-3 is NOT set. 6. Generate 1 additional change event of this type on the DUT. 7. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 8. Verify that the device returns a single Binary Input Change Event and IIN2-3 is set. 9. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 10. Verify that the device returns a single Binary Input Change Event and IIN2-3 is not set.

8.6.6.2.2 Buffer Overflow, Analog Input Change Event Buffers 1. If the device does not support Analog Input Change Events, or does not queue multiple events for the same point,

end testing of Buffer Overflow, Analog Input Change Event Buffers.


2. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending events.

3. Obtain the maximum Analog Input Change Event buffer size from the device documentation and generate this number of corresponding events on the DUT.

4. Issue a request for Object 60 Variation x (appropriate Class) using the all data qualifier 0x06, but DO NOT issue an application confirm to the device.

5. Verify that IIN2-3 is NOT set. 6. Generate 1 additional change event of this type on the DUT. 7. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 8. Verify that the device returns a single Analog Input Change Event and IIN2-3 is set. 9. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 10. Verify that the device returns a single Analog Input Change Event and IIN2-3 is not set.

8.6.6.2.3 Buffer Overflow, Binary Counter Change Event Buffers 1. If the device does not support Binary Counter Change Events, or does not queue multiple events for the same point,

end testing of Buffer Overflow, Binary Counter Change Event Buffers. 2. Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending

events. 3. Obtain the maximum Binary Counter Change Event buffer size from the device documentation and generate this

number of corresponding events. 4. Issue a request for Object 60 Variation x (appropriate Class) using the all data qualifier 0x06, but DO NOT issue an

application confirm to the device. 5. Verify that IIN2-3 is NOT set. 6. Generate 1 additional change event of this type. 7. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 8. Verify that the device returns a single Binary Counter Change Event and has set IIN2-3. 9. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change. 10. Verify that the device returns a single Binary Counter Change Event and IIN2-3 is no longer set.

8.7 Time § If the device sets IIN1-4, the Device Profile must state the worst case values for the following parameters for the full operating temperature and support all of the tests in this section. • Time base drift over a 10-minute interval. • Maximum delay measurement error. • Maximum internal time reference error when set from the protocol. • Maximum response time. If a device does not set IIN1-4 it need not support any of the tests in this section.

8.7.1 Delay Measurement This function is used to calculate the communication delay for a particular device. The device will respond to a Time Delay Measurement request with the number of milliseconds elapsed between the device receiving the first bit of the first byte of the request and the time of transmission of the first bit of the first byte of the response.

8.7.1.1 Desired Behavior • § The device must respond to a Delay Measurement request with a Time Delay Fine response.

8.7.1.2 Test Procedure 1. Issue a request for Delay Measurement using Function Code 23, to the DUT. 2. Verify that the device replies with Object 52 Variation 2 Qualifier 0x07 Quantity 1 and a millisecond time stamp of

the measured delay. 3. Verify that the accuracy of the delay reported is within the maximum error specified in the Device Profile

Document. 4. Perform the test two more times to guarantee repeatability.


8.7.2 Synchronization The Time and Date Object (Object 50 Variation 01) is an information object that represents the absolute time of day and date, recorded as milliseconds since midnight, January 1, 1970, at zero minutes, zero seconds, and zero milliseconds. This object is usually used for time-synchronization. Note that the following procedures verify the mechanics of time synchronization, verify that the time format is correct, and that synchronization appears to have occurred. The actual accuracy of time synchronization is dependent on device accuracy and system configuration and should be tested separately (factory and/or site acceptance tests).

8.7.2.1 Desired Behavior • The device must respond to a Time and Date object by null response with IIN1-4 cleared. • § The Device Profile must specify the maximum time from startup to IIN1-4 assertion.

8.7.2.2 Test Procedure 1. Reset the DUT. 2. Wait the specified maximum time from reset to IIN1-4 assertion. 3. Issue a request for Object 60 Variation 2 using the all data qualifier 0x06. 4. Verify that the device responds with a valid message and that IIN1-4 is set indicating that the device is requesting

time synchronization. 5. Set the time and date using a WRITE request and Object 50 Variation 1 with Qualifier 0x07 taking into account the

delay measured in the previous section. 6. Verify that the device responds with a Null Response and that IIN1-4 is cleared indicating the device no longer

needs time. 7. Generate a supported time tagged event at a known time. 8. Issue a request for Object 60 Variation 2, 3, or 4 as appropriate, using the all data qualifier 0x06. 9. Verify that the device responds with a valid time tagged event and that the time reported is within the maximum

error specified in the Device Profile Document.

8.8 Cold Restart

8.8.1 Desired Behavior • The device must respond to a Cold Restart request by sending a Time Delay response, restarting, and setting IIN1-7.

8.8.2 Test Procedure 1. Issue a request for Cold Restart using Function Code 13, to the DUT. 2. Verify the response is a Time Delay Fine or Coarse (Object 52 Variation 1 or Variation 2). 3. If the DUT requests an Application Layer Confirm send it before starting the wait period. 4. Wait for a period of time longer than the time returned in step 2. 5. Issue a request for Object 60 Variation 1. 6. Verify that the device responds with IIN1-7 set indicating that the device has been restarted. 7. Issue a Write using Object 80 Variation 1 with the qualifier 0x00. Use a start index of 7 and a stop index of 7,

followed by the value 0. 8. Verify that the device responds with a Null Response and that IIN1-7 is cleared.

8.9 Application Layer Fragmentation

8.9.1 Use of FIR, FIN and SEQUENCE in Fragmentation

8.9.1.1 Desired Behavior If the DUT can generate enough data to create multiple application layer fragments, it must meet the following criteria: DNP3-2001 IED Certification Procedure Page 43 Subset Level 2 Rev 2.1 – 5-July-01

The application layer FIR bit must be set in the first fragment (only). •

• • • • • • •

• •

•

The application layer FIN bit must be set in the final fragment (only). The application layer sequence number of the first fragment must match that of the request. The application layer sequence number must increment between fragments. Transport layer segmentation must operate correctly within each fragment. The fragment size must be able to be configured to be no larger than 2048 octets. If the fragment size is configurable, it must behave accordingly. If the device cannot generate more than one fragment, the FIR and FIN bits in the application layer header must signify that there is only one APDU in the reply.

8.9.1.2 Test Procedure 1. If the DUT has a configurable fragment size, configure it to be no more than 2048 octets. 2. Cycle power to the DUT. 3. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06, if this will generate a multi-fragment

response. Alternately, generate enough event data to fill more than one fragment and request the appropriate class of data with Qualifier Code 0x06.

4. Verify that the DUT responds with valid data. 5. Verify that the sequence number of the first fragment matches the request. 6. Verify that each fragment of the response contains no more than the configured fragment size. 7. If the DUT’s reply contains only a single fragment then verify the FIR bit is set to one and the FIN bit is also set to

one. If there is no way to cause the DUT to generate multiple fragments, i.e. its Class 0 response is less than a fragment and it does not support event data, no further testing is required in the Application Layer Fragmentation section.

8. If the DUT’s reply contains more than one fragment then verify that the first response message sets the FIR bit to a one, the FIN bit is set to zero.

9. Verify subsequent fragments to assure that the FIR bit is zero, the FIN bit is zero, and the sequence number increments by one.

10. Verify that the last fragment has the FIR bit cleared and the FIN bit set, signifying the last data fragment. 11. Verify each fragment is properly segmented by the transport layer as described in that section of this document. 12. If the DUT’s fragment size is configurable, repeat this test with a different fragment size and verify the data for each

fragment does not exceed the configured size.

8.9.2 § Use of Confirmation in Fragmentation

8.9.2.1 § Desired Behavior The DUT must request an application layer confirmation between fragments. The DUT must not send subsequent fragments until it receives confirmation of the previous fragment, with a correct sequence number. The DUT must not send subsequent fragments if it does not receive a valid confirmation within a timeout.

NOTE: The DUT is not required to request application layer confirmation on the last fragment of a response (unless required for other reasons tested elsewhere in this document).

8.9.2.2 § Test Procedure 1. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06, if this will generate a multi-fragment


2. Verify that the DUT responds with valid data. 3. Verify that the CON bit is set in the first fragment. 4. Verify the sequence number matches the request. 5. Wait the application confirmation timeout for the DUT. Do not send an application confirmation. 6. Verify the DUT does not send the next fragment because it did not receive confirmation of the first fragment.


7. Send the valid application layer confirmation. 8. Verify the DUT does not send the next fragment because it has timed out. 9. Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06, if this will generate a multi-fragment


10. Verify that the CON bit is set in the first fragment. 11. Wait a time period less than the application confirmation timeout. Verify the DUT does not send the second

fragment yet. 12. Send the valid application layer confirmation before the application confirmation timeout. 13. Verify that the DUT sends the second fragment (with FIR, FIN and sequence number set correctly). 14. Verify that the CON bit is set in the second fragment. 15. If a third fragment is expected, continue. If not, first send a valid application layer confirmation and then a request

for multi-fragment data as in steps 1-3. 16. Send an application layer confirmation with an incorrect sequence number. 17. Wait the application layer confirmation timeout for the DUT. Do not send an application confirmation. 18. Verify the DUT does not send the next fragment because the confirmation it received was invalid. 19. Send the valid application layer confirmation. 20. Verify the DUT does not send the next fragment because it has timed out.

8.10 Multi-Drop Support

8.10.1 Desired Behavior • The DUT must only respond to requests when the destination address field of the link layer portion of the request

matches its assigned DNP address. • The DUT must remain silent in all other cases. This includes not raising carrier (e.g. asserting RTS) during periods

in which it is not responding.

8.10.2 Test Procedure 1. If the DUT does not support multi-drop physical layers, this must be noted on the Implementation Conformance

Statement and in the Device Profile Document. No further testing is required in this section. 2. Connect the DUT and at least two additional DNP devices to the same communications drop. 3. Connect an oscilloscope and/or protocol analyzer to the DUT communications signals. 4. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to each of the other devices on

the communications channel. 5. Verify that the DUT does not respond in any way, including raising carrier or asserting RTS. 6. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to the broadcast address. 7. Verify that the DUT does not respond in any way, including raising carrier or asserting RTS. 8. Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to the DUT. 9. Repeat as necessary to verify that the DUT responds in an appropriate manner for the physical layer which may

include: a) Raising carrier (or asserting RTS) an appropriate period of time before transmitting the first bit of data. b) Dropping carrier (or de-asserting RTS) an appropriate period of time after transmitting the last bit of data. c) If the pre and post RTS to transmit delay parameters are configurable, repeat this test for the lower of the two

following cases. i) the total number of selections or ii) the minimum, maximum, and two intermediate values

8.11 Unsolicited Responses Support for unsolicited responses is optional. If a device does not support unsolicited responses, this section may be skipped in its entirety.


Although unsolicited responses may be used with collision avoidance, the two features are independent. For instance, a device might not support collision avoidance, but support unsolicited responses in a dial-up environment. Therefore, all that is needed to test unsolicited responses is a full-duplex serial connection to the DUT.

8.11.1 Desired Behavior

8.11.1.1 Configuration Devices that support unsolicited responses must support end-user configuration of the following parameters (e.g.: by front-panel user interface or off-line configuration):

The destination address of the Master device to which the unsolicited responses are to be sent. • •

•

•

The unsolicited response mode (either “on” or “off”). When the unsolicited response mode is configured “off”, the device is to behave exactly like an equivalent device that has no support for unsolicited responses.

• § The unsolicited confirmation timeout. This is the amount of time between transmissions of unconfirmed unsolicited responses. The range of configurable values must include 1 second to 1 minute, but may be extended in either direction (slower or faster) to take advantage of, or to compensate for, faster or slower devices or communications media. This may be either the normal application confirmation timeout, or another parameter that performs the same purpose only for unsolicited responses.

• § Maximum number of unsolicited retry attempts. One of the choices must provide for an indefinite (and potentially infinite) number of retries.

8.11.1.2 Sequence Numbers and Confirmation At all times:

Application layer sequence numbers (the value of bits 0–4 of the application layer control field) must be in the correct range for all messages sent: 0–15 for polled responses and 16–31 for unsolicited responses.

• Ignore Master device application layer confirmations of unsolicited responses if their sequence numbers do not match those of the corresponding unsolicited responses.

• § All unsolicited response messages must request application layer confirmation, regardless of whether they are null (no data) or contain data.

8.11.1.3 Restart Behavior If the unsolicited response mode is configured “on,” then upon device restart: • The device must transmit an initial unsolicited response message. • The initial unsolicited response message must have the restart bit (IIN1-7) set if the Master has not already sent a

command to clear it. • § The initial unsolicited response message must be null; i.e., it must not contain static or event data objects. • § The initial unsolicited response message must request an application layer confirmation, regardless of whether the

message has the restart bit (IIN1-7) set. • § The device must continue to transmit initial null unsolicited responses forever at the rate set by the unsolicited

confirmation timeout, until that initial unsolicited response message is confirmed. • § The device must respond to all function requests to which it would normally respond, including READ function

requests, while waiting for the confirmation of the initial unsolicited response. • § The device must not send any more unsolicited responses after the initial null unsolicited response message has

been confirmed, until a function code 0x14 (enable data-filled unsolicited messages) request has been received. Note: Enabling and disabling exception reporting does not enable/disable the storage of the reports, just the reporting.

8.11.1.4 Runtime Behavior Once an initial unsolicited response message has been confirmed, then the device must:

§ Process function code 0x14 requests (to enable data-filled unsolicited messages). This enabled status must not be retained through a device restart; i.e. data-filled unsolicited messages are always disabled on restart.


§ Process function code 0x15 requests (to disable data-filled unsolicited messages). This disabled status does not apply to initial null unsolicited responses; i.e., if function code 0x15 is requested, and if no off-line configuration is altered, then after restart, an initial unsolicited response message must again be transmitted.

•

•

• •

§ At a minimum, support the enabling and disabling of unsolicited responses for Class 1, 2, and 3 data. Even if the device does not have Class 1, Class 2, or Class 3 data, it must respond to function codes 0x14 and 0x15, object 60, and variations 2, 3 and 4 without error responses. Only send unsolicited responses for those classes of data that have been enabled. Unsolicited response messages must contain only the following kinds of data: ! event data, or ! static data for which no event object types exist: binary output status (Object 10 Variation 2) and analog output

status (Object 40 Variation 2). Note, when static data is returned in unsolicited responses, the rules for event processing still apply as specified in section 3.4.

8.11.1.5 Unsolicited and Polled Responses • If an unsolicited response message containing event data is not confirmed, the device must timeout, retain the event

data, and re-transmit the event data either in subsequent unsolicited response messages or in polled response messages. The event data does not have to be re-transmitted exactly (new change events may have occurred, or, for example, analog input change events may be updated to reflect new current values of analog inputs).

• Once an unsolicited response message containing event data is confirmed, the event data must be cleared from the device and no longer transmitted in subsequent unsolicited or polled responses.

• The device cannot generate unsolicited responses if it is waiting for an application confirmation to a previous polled or unsolicited response.

• If a non-READ function code request is received while waiting for a confirmation of an unsolicited response, the device must immediately process it.

• § If a READ function code request is received while waiting for a confirmation of an unsolicited response, the device must defer responding to the READ request (the READ request is therefore “pending”) until after either the unsolicited confirmation timeout occurs, or the confirmation of the unsolicited response is received.

• § The device cannot generate an additional unsolicited response until it has responded to a pending READ request. • § If a READ function code request is pending while waiting for a confirmation of an unsolicited response, and

another (new) function code request is received, the original READ function code request must be abandoned (with no response transmitted), and the new function code should be processed according the desired behavior rules of this section.

8.11.2 Test Procedure Unless explicitly specified by the tests in these sections, do not issue any requests to the DUT, including: requests to clear the restart bit (IIN1-7); READ requests for data; application layer confirmations and requests to enable or disable unsolicited responses. Similarly, do not allow the Master being used to test the device to issue any of these requests automatically.

8.11.2.1 Unsolicited Response Configuration/Startup 1. Verify that the DUT has off-line capability to configure the unsolicited response mode (either “on” or “off”). Use

this capability to configure the unsolicited response mode to “on.” 2. § Verify the DUT has off-line capability to configure the unsolicited confirmation timeout. Verify that it can be set

to at least as small as 1 second, and to at least as large as 1 minute. 3. For the remainder of Section 8.11.2.1, set this time to be 5 seconds. (The value of 5 seconds is arbitrary, and is used

to simplify the description and execution of this test. As a further simplification for the purposes of this test, when the test steps below exercise and rely upon this value, measurement accuracy can be within 0.5 seconds. It is not the purpose of this test to verify the full range of this parameter, nor is it the purpose of this test to verify the accuracy of the time keeping capability of the DUT. It is the purpose of this test, however, to verify that the parameter has been implemented.)

4. Verify the DUT has off-line capability to configure the destination address of the Master device to which unsolicited responses are to be sent. Use this capability to configure a specific destination address.

5. Cycle power to the DUT. DNP3-2001 IED Certification Procedure Page 47 Subset Level 2 Rev 2.1 – 5-July-01

6. Verify that the DUT transmits an initial unsolicited response to the configured Master destination address. 7. Use the off-line configuration capability to configure the destination address to a different destination address. 8. Cycle power to the DUT. 9. Verify that an initial unsolicited response is transmitted by the DUT. 10. Verify that the unsolicited response contains the restart bit (IIN1-7) set. 11. § Verify that the unsolicited response is null (contains no data). 12. § Verify that the unsolicited response requests an application layer confirmation. 13. Verify that the application sequence number is in the correct range. 14. Verify that it has been transmitted to the configured Master destination address. 15. Wait at least 10 seconds, and verify that two or more unsolicited responses are transmitted by the DUT. Verify that

these new unsolicited responses are transmitted no more often, and no less often, than once every 5 seconds. 16. Verify that the restart bit (IIN1-7) remains set in these unsolicited responses. 17. § Verify that the unsolicited responses are null (contains no data). 18. § Verify that the unsolicited responses request application layer confirmations. 19. Issue a request to clear the restart bit (IIN1-7). 20. Verify that the DUT responds with a null response that has the restart bit (IIN1-7) cleared. 21. Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT. 22. Verify that the restart bit (IIN1-7) is clear in the unsolicited responses. 23. Issue a READ request (function code 0x01) for Object 60 Variation 1 (class 0) using the all data qualifier 0x06. 24. § Verify that the DUT responds to the READ request with class 0 data. 25. Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT. 26. Issue an application layer confirmation of the unsolicited response, but use an incorrect application-layer sequence

number. 27. Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT. 28. Issue an application-layer confirmation of the unsolicited response, and use the correct application-layer sequence

number. 29. Generate known events. 30. § Verify that no further unsolicited responses are transmitted by waiting for such responses for at least 5 seconds.

8.11.2.2 Unsolicited Response - Class 1 Data 1. Issue a request to disable unsolicited responses for all classes of data by using function code 0x15 with three object

data headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 2. Verify that the DUT responds with a null response indicating the request was processed without error. 3. If the DUT has Class 1 data, generate such data. For example, if there is a binary input change event that is (or can

be assigned to) Class 1, then ensure that it is assigned to Class 1, and generate one such event. 4. Verify that no unsolicited responses are transmitted by waiting for such responses for a length of time at least as

great as what would be necessary for the DUT to otherwise generate an unsolicited response. 5. Issue a request to enable unsolicited responses for Class 1 data by using function code 0x14, object 60, Variation 2. 6. Verify that the DUT responds with a null response indicating the request was processed without error. 7. If it is not possible to generate Class 1 data that would generate unsolicited responses, steps 8 through 14 are not

applicable. 8. Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the

DUT and specified by the DUT’s Device Profile Document, within which the DUT may wait for a minimum number of events to be collected before transmission of an unsolicited message.

9. Verify that the unsolicited response requests an application layer confirmation. 10. Verify that the application sequence number is in the correct range. 11. Without issuing an application layer confirmation, wait for the unsolicited confirmation timeout to expire, and verify

that another unsolicited response is transmitted by the DUT. 12. Verify that at least the same event data is present in the unsolicited response. (It is not required that the unsolicited






16. If the DUT has Class 2 data, then generate such data. If the DUT has Class 3 data, then also generate Class 3 data. 17. Verify that no further unsolicited responses are transmitted by waiting for such responses for a length of time at least

as great as what would be necessary for the DUT to otherwise generate an unsolicited response.




great as what would be necessary for the DUT to otherwise generate an unsolicited response. 5. Issue a request to enable unsolicited responses for Class 2 data by using function code 0x14, Object 60, Variation 3. 6. Verify that the DUT responds with a null response indicating the request was processed without error. 7. If it is not possible to generate Class 2 data that would generate unsolicited responses, steps 8 through 14 are not



9. Verify that the unsolicited response requests an application layer confirmation. 10. Verify that the application sequence number is in the correct range. 11. Without issuing an application layer confirmation, wait for the unsolicited confirmation timeout to expire, and verify











great as what would be necessary for the DUT to otherwise generate an unsolicited response. 5. Issue a request to enable unsolicited responses for Class 3 data by using function code 0x14, Object 60, Variation 4. 6. Verify that the DUT responds with a null response indicating the request was processed without error. 7. If it is not possible to generate Class 2 data that would generate unsolicited responses, steps 8 through 14 are not





10. Verify that the application sequence number is in the correct range. 11. Without issuing an application layer confirmation, wait for the unsolicited confirmation timeout to expire, and verify








8.11.2.5 Unsolicited and Polled Responses This is a complicated test procedure. The test has been divided into sections for clarity.

8.11.2.5.1 Transmits data-filled unsolicited responses 1. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object

data headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 2. Verify that the DUT responds with a null response indicating the request was processed without error. 3. Generate class 1, 2, or 3 event data. 4. Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the



8.11.2.5.2 Clears transmitted data upon confirmation 1. Issue an application-layer confirmation of the unsolicited or polled response. 2. Issue a READ request (function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06. 3. Verify that none of the event data transmitted by the unsolicited response is contained in the polled response.

8.11.2.5.3 Processes non-READ requests immediately 1. Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited

response to be sent. 2. Without issuing an application layer confirmation, issue a function code request other than READ (for example,

function code 0x02 – WRITE to clear the restart flag IIN1-7). 3. Verify that the DUT immediately responds without error. 4. Wait for the unsolicited confirmation timeout to expire, and verify that another unsolicited response is transmitted

by the DUT. 5. Verify that the event data in this unsolicited response includes the events reported in the previous unsolicited

response that was not confirmed. It is not required that the unsolicited responses be identical. For data such as analog input change events, the data may be updated to reflect current values. It is also possible for new event data to be generated.

8.11.2.5.4 Defers READ requests until after confirmation received 1. Immediately after the unsolicited response, and without issuing an application layer confirmation, issue a READ

request (function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06. 2. Wait for an amount of time less than the unsolicited confirmation timeout and verify that the DUT does not respond. 3. Issue an application-layer confirmation of the unsolicited response before the unsolicited confirmation timeout

occurs. 4. Verify that the device immediately transmits a response to the READ request. Page 50 DNP3-2001 IED CerRev 2.1 – 5-July-01

5. Verify that none of the event data transmitted by the unsolicited response is contained in the polled response. 6. If the polled response requested an application layer confirmation, then issue an application-layer confirmation of

the polled response.

8.11.2.5.5 Defers READ requests until after confirmation timeout 1. Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited

response to be sent. 2. Immediately after the unsolicited response, and without issuing an application layer confirmation, issue a READ

request (function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06. 3. Verify that the DUT does not respond within the unsolicited confirmation timeout. 4. After the unsolicited confirmation timeout, verify that the device responds with a polled response to the READ

request (and not an unsolicited response). 5. Verify that the polled response contains at least the same event data that was in the unsolicited response that was not

confirmed. 6. Verify that the polled response requests an application layer confirmation. 7. Issue an application-layer confirmation of the polled response to clear the device of event data. 8. Verify that no further unsolicited responses are transmitted by waiting for such responses for a length of time at least


8.11.2.5.6 Abandons READ requests upon subsequent non-READ requests 1. Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited

response to be sent. 2. Immediately after the unsolicited response, and without issuing an application layer confirmation, issue a READ

request (function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06. 3. Before the unsolicited confirmation timeout, issue a function code request other than READ (for example, function

code 0x02 – WRITE to clear the restart flag IIN1-7). 4. Verify that the DUT immediately responds without error. 5. Wait for the unsolicited confirmation timeout to expire, and then verify that another unsolicited response is

transmitted by the DUT. 6. Verify that the event data in this unsolicited response includes the events reported in the previous unsolicited

response that was not confirmed.

8.11.2.5.7 Abandons READ requests upon subsequent READ requests 1. Immediately after the unsolicited response, and without issuing an application layer confirmation, issue a READ

request (function code 0x01) for Object 60 Variation 1 using the all data qualifier 0x06. 2. Before the unsolicited confirmation timeout, issue a READ request for Object 60, Variations 2, 3, and 4, using the

all data qualifier 0x06. 3. Verify that the DUT does not respond within the unsolicited confirmation timeout. 4. After the unsolicited confirmation timeout, verify that the device responds with a polled response to the Object 60,

Variation 2, 3, and 4 READ request (and not an unsolicited response). 5. Verify that the polled response is a response to the request for Object 60, Variations 2, 3, and 4 – not Variation 1; in

other words, verify that it contains class 1, 2, or 3 data and not class 0 data. 6. Verify that the polled response contains at least the same event data that was in the unsolicited response that was not

confirmed. 7. Verify that the polled response requests an application layer confirmation. 8. Issue an application-layer confirmation of the polled response to clear the device of event data. 9. Verify that no further unsolicited responses are transmitted by waiting for such responses for a length of time at least


8.11.2.5.8 Inhibits Unsolicited responses until after polled confirmation 1. If the device has a minimum amount of event data that will cause the immediate transmission of an unsolicited

response, then generate at least some, but less than this amount of class 1, 2, or 3 event data. Or, if there is a window of time between the generation of event data and the subsequent transmission of an unsolicited response, then


generate event data and perform the next test procedure step before this time elapses. If neither of these procedures are possible, then the remaining steps in this procedure are not applicable.

2. Before an unsolicited response is transmitted, issue a READ request (function code 0x01) for Object 60 Variations 2, 3, and 4 using the all data qualifier 0x06.

3. Verify that events are reported in the response to the READ request 4. Verify that the polled response requests an application layer confirmation. 5. Do not send an application layer confirmation. 6. If necessary, generate more event data that would otherwise cause the transmission of an unsolicited response. 7. Verify that the DUT does not transmit an unsolicited response within the application confirmation timeout, nor

before any application layer retries are attempted. 8. After the application confirmation timeout, and after any application layer retries, verify that the device responds

with an unsolicited response. 9. Verify that the unsolicited response contains at least the same event data that was in the polled response that was not

confirmed. 10. Verify that the unsolicited response requests an application layer confirmation. 11. Issue an application-layer confirmation of the unsolicited response to clear the device of event data.

8.11.2.5.9 Retries unsolicited responses configurable number of times 1. Verify the DUT has off-line capability to configure the maximum number of unsolicited retries and that one of the

choices causes the DUT to retry indefinitely. Use this capability to configure the maximum number of retries to 5. 2. Cycle power to the DUT. 3. Issue an application-layer confirmation of the initial unsolicited response. 4. Issue a request to clear the restart bit (IIN1-7). 5. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object

data headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 6. Verify that the DUT responds with a null response indicating the request was processed without error. 7. Generate class 1, 2, or 3 event data. 8. Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the


9. Do not issue an application layer confirm. 10. Verify that DUT retries the response 5 times. 11. Cycle power to the DUT. 12. Issue an application-layer confirmation of the initial unsolicited response. 13. Issue a request to clear the restart bit (IIN1-7). 14. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object

data headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 15. Verify that the DUT responds with a null response indicating the request was processed without error. 16. Generate class 1, 2, or 3 event data. 17. Verify that an unsolicited response is transmitted. 18. Issue an application layer confirm after at least one retry. Verify that retries are terminated when confirmation is

received. 19. Configure the maximum number of retries to indefinite. 20. Cycle power to the DUT. 21. Issue an application-layer confirmation of the initial unsolicited response. 22. Issue a request to clear the restart bit (IIN1-7). 23. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object

data headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 24. Verify that the DUT responds with a null response indicating the request was processed without error. 25. Generate class 1, 2, or 3 event data. 26. Verify that an unsolicited response is transmitted. 27. Do not issue an application layer confirm. 28. Verify that retries continue for an extended period of time.


8.11.2.6 Unsolicited Responses Off 1. Configure the unsolicited response mode to “off”. 2. Cycle power to the DUT. 3. Verify that no initial unsolicited responses are transmitted by waiting for such responses for a length of time at least

as great as what would be necessary for the DUT to otherwise generate an unsolicited response. 4. Issue a request to clear the restart bit (IIN1-7). 5. Verify that the DUT responds with a null response that has the restart bit (IIN1-7) cleared. 6. Verify that no initial unsolicited responses are transmitted by waiting for such responses for a length of time at least

as great as what would be necessary for the DUT to otherwise generate an unsolicited response. 7. Issue a request for Object 60 Variations 3, 2, 1, and 0 using the all data qualifier 0x06 to cause the DUT to report

(and clear) all pending events. 8. If requested, issue an application layer confirm. 9. Generate several change events or other data, which would otherwise cause an unsolicited response. 10. Verify that no unsolicited responses are transmitted by waiting for such responses for a length of time at least as

great as what would be necessary for the DUT to otherwise generate an unsolicited response. 11. Issue a request to enable unsolicited responses for all classes of data by using function code 0x14 with three object

data headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 12. Verify that the DUT responds with an Error Response with IIN2-0 set indicating that the DUT has received a

message containing a bad function code. 13. Verify that no unsolicited responses are transmitted by waiting for such responses for a length of time at least as

great as what would be necessary for the DUT to otherwise generate an unsolicited response. 14. Issue a request to disable unsolicited responses for all classes of data by using function code 0x15 with three object

data headers: Object 60, Variation 2; Object 60, Variation 3; and Object 60, Variation 4. 15. Verify that the DUT responds with an Error Response with IIN2-0 set indicating that the DUT has received a

message containing a bad function code.

8.12 § Collision Avoidance The functions tested in this section are optional. However, if a device claims in its Device Profile Document that it implements collision avoidance, it must pass the tests in this section to be compliant. A device may be certified as supporting collision avoidance in one of the following ways:

Detecting out-of-band carrier (e.g. DCD) •

•

1. with the aid of an external device 2. without the aid of an external device Detecting transmitted data (e.g. TX/RX line).

For these tests, the supplier of the DUT must specify which method the DUT uses to detect other devices are transmitting. If necessary, the supplier must supply hardware (modems etc.) and test equipment suitable for testing this feature. The test equipment must be capable of measuring time between two characters transmitted on the link. Although unsolicited responses may be used with collision avoidance, the two features are independent. For instance, a device might not support collision avoidance, but support unsolicited responses in a dial-up environment. However, unsolicited responses in a multi-drop environment require collision avoidance. The operation of collision avoidance is as follows:

The physical layer must provide an indication to the data link layer of when the link is in use, e.g. using the DCD (Data Carrier Detect) signal or simply monitoring all data on the link. If a device prepares to transmit and finds the link busy, it waits until it is no longer busy, then waits a backoff_time as follows:


backoff_time = fixed_delay + random( max_random_delay )

After the backoff_time, the device tries again, either indefinitely, or up to a configurable maximum number of retries. If a maximum is used, the protocol behaves as if a link failure occurred, i.e. data is returned to buffers at the application layer and application layer retries take place if desired. The fixed_delay can be adjusted per device to provide priority of access. For instance, it could be zero (0) for masters and non-zero for all the slave devices. The fixed_delay for the slaves must be greater than the max_random_delay for the master. This provides a minimum "window" of access time for the master(s). To absolutely guarantee the master’s priority, the master would not have a random delay.

8.12.1 Desired Behavior When implementing collision avoidance, the DUT must meet the following requirements: • The fixed_delay and the max_random_delay must be configurable. • The DUT must transmit as quickly as possible if no other device is transmitting. • The DUT must wait the backoff_time when it tries to transmit and another device is already transmitting. • The backoff_time must start at the moment when the other device stops transmitting. • The backoff_time must be greater than the fixed_delay. • The backoff_time must not exceed the fixed_delay plus the max_random_delay. • If another device is still transmitting when the backoff_delay expires, the DUT must wait until the line becomes free

and then restart the backoff timer.

8.12.2 Test Procedure 1. Request Class 1 data (Object 60 Variation 2) using Qualifier Code 0x06 and link control block 0xF4. 2. Verify the device responds with data. Measure the turnaround delay between receipt of the request and the response. 3. Prepare a request for Class 1 data as above, followed immediately by “noise” data sufficient to exceed the measured

turnaround delay and the fixed_delay but less than the turnaround delay plus the maximum backoff_delay. The noise data may consist of a poll to a nonexistent device.

4. Send the request. 5. Verify the DUT sends a response AFTER the noise data has finished transmitting. Verify the noise and the response

do not overlap. 6. Verify the delay between the end of the noise data and the start of the response is less than the maximum back_off

delay and more than the fixed_delay plus the max_random_delay. 7. Repeat steps 4 through 6 at least 10 times. Verify the measured backoff_delay is different in each case although it

remains less than the maximum backoff_delay and the length of the noise data remains constant. 8. Add more noise data to the prepared request so that the noise data now exceeds several times the fixed_delay plus

the max_random_delay, then a gap in the noise less than the fixed_delay, followed by noise several times longer than fixed_delay plus the max_random_delay.

9. Repeat steps 4 through 6 to verify the DUT will back off more than once. 10. Reconfigure the device with a different fixed_delay and maximum_random_delay. 11. Repeat steps 1 through 10.

8.13 Binary Inputs If the DUT is configurable in a manner such that points can be uninstalled or disabled, the device must be configured with at least one Binary Input point installed or enabled before proceeding with the test procedure.

8.13.1 Desired Behavior The following behavior assumes that the device does not support binary inputs: • If the device does not support Binary Inputs, it must respond to a request with a null response and no further testing

in this section is necessary. • Optionally, the device can return an Error Response with IIN2-1 set. The following behavior assumes that the device supports binary inputs:


• If the device supports Binary Inputs the device must respond to an Any Variation Binary Input read request (Object 1, Variation 0) with either Object 1 Variation 1 or Object 1 Variation 2.

The following behavior assumes that the device does support binary inputs, however there are no binary input points installed: • If the device supports Binary Inputs, it must respond to a request with a Null Response or an Error Response setting

IIN2-1.

8.13.2 Test Procedure

8.13.2.1 Device does not have Binary Inputs 1. Issue a request for Object 1 Variation 0 using the all data qualifier of 0x06. 2. Verify that the DUT responds with a Null Response. The device can optionally set IIN2-1. No further testing in this

section is necessary.

8.13.2.2 Device has Binary Inputs 1. Generate a known binary input pattern. 2. Issue a request for Object 1 Variation 0 using the all data qualifier of 0x06. 3. Verify that the DUT responds with Object 1 Variation 1 or 2 using either 8 bit start/stop indexing (qualifier 0x00) or

16 bit start/stop indexing (qualifier 0x01). 4. If the response contains Object 1 Variation 1 verify that the response contains the proper indication of binary inputs

from step 1. 5. If the response contains Object 1 Variation 2 verify that the response contains the proper indication of binary inputs

from step 1 with an 8-bit flag field. 6. Generate binary data to various installed points. 7. Issue a request for Object 1 Variation 0 and the all data qualifier 0x06. 8. Verify that the device responds with Object 1 Variation 1 or 2 and the proper binary data is returned. 9. Verify that flag behavior complies with Section 2, Note #5.

8.13.2.3 Device supports Binary Inputs, Configurable Device 1. If the device is not configurable in a manner such that Binary Input points can be uninstalled or disabled, no further

testing in this section is necessary. 2. Configure the DUT such that all Binary Input points are uninstalled or disabled. 3. Issue a request for Object 1 Variation 0 using the all data qualifier of 0x06. 4. Verify that the DUT responds with a Null Response. The device can optionally set IIN2-1.

8.14 Binary Input Change This request is used to read binary change or event data from a device. The device must respond with events that have occurred and have not yet been read from the device with a poll/confirm sequence. If the device does not support Binary Input Change Events, it must return a null response. Points can be assigned to a class by configuration and through the protocol. Neither is required for level 2 compliance. § Any device that generates more than one link layer frame in response to a Class 0 Poll must support report-by-exception on all points. It is highly recommended that devices perform report by exception processing internally and respond to class polls with event data as defined in section 3.4. This allows efficient use of bandwidth. When no events are pending the device responds with the Null Response.

8.14.1 Desired Behavior • If a device does not support report by exception on binary inputs it must respond with a Null Response. • The device must respond with all of its binary change events when polled with the all data qualifier (0x06).


• When polled with the limit data qualifier (0x07), the device must respond with a quantity of its binary change events no greater than specified in the request.

• When polled with the limit data qualifier (0x08), the device must respond with a quantity of its binary change events no greater than specified in the request.

• The DUT uses only qualifier codes 0x17 or 0x28 when building its’ response. • § The device must request an application layer confirm for all responses that contain event data. Note: Application

layer confirms are always sent upon request unless stated otherwise in this section. • § The device must clear all of the binary change events reported in the last response upon receipt of an application

layer confirm with a matching sequence number.


8.14.2.1 Device does not support Binary Input Changes 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 2. § If the DUT has binary inputs and it responds to a Class 0 poll with more than one link layer frame, verify that it

also performs report-by exception processing. 3. If the DUT does not support report by exception processing, verify that it responds with a Null Response. No further

testing is required in this section.

8.14.2.2 Binary Input Change, 0x06 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. Issue an application layer confirm if requested to empty the device of pending events. 3. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 4. Verify that the device responds with a Null Response. 5. Generate several Binary Input Change Events. 6. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 7. Verify that the device responds with all generated events in a single response. 8. § Verify that the device requests an application layer confirm. 9. Verify that the response contains only Object 2, Variation 1, 2, and/or 3. 10. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 11. Verify that flag behavior complies with Section 2, Note #5. 12. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 13. Verify that the device responds with a Null Response.

8.14.2.3 Binary Input Change, 0x07 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change Events. 5. Issue a request for Object 2 Variation 0 using the limit data qualifier 0x07 requesting some of the changes. 6. Verify that the device responds with the correct number of generated events in a single response. 7. § Verify that the device requests an application layer confirm. 8. Verify that only Object 2, Variation 1, 2, and/or 3 are returned. 9. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 10. Verify that flag behavior complies with Section 2, Note #5. 11. Issue a request for Object 2 Variation 0 using the limit data qualifier 0x07 requesting the remaining changes. 12. Verify that the device responds with the remaining Binary Input Change Events. 13. § Verify that the device requests an application layer confirm.

8.14.2.4 Binary Input Change, 0x08 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events.


4. Generate several Binary Input Change Events. 5. Issue a request for Object 2 Variation 0 using the limit data qualifier 0x08 some of the changes. 6. Verify that the device responds with the correct number of Binary Input Change Events in a single response. 7. Verify that the device requests an application layer confirm. 8. Verify that only Object 2, Variation 1, 2, and/or 3 are returned. 9. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 10. Verify that flag behavior complies with Section 2, Note #5. 11. Issue a request for Object 2 Variation 0 using the limit data qualifier 0x08 requesting the remaining changes. 12. Verify that the device responds with the remaining events. 13. § Verify that the device requests an application layer confirm.

8.14.2.5 § Binary Input Change Without Confirm 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate Binary Input Change Events. 5. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 6. Verify that the device responds with all the event data generated in a single response. 7. § Verify that the device requests an application layer confirm. 8. Verify only Object 2, Variation 1, 2, and/or 3 are returned. 9. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 10. Verify that flag behavior complies with Section 2, Note #5. 11. Verify that the device responds with the remaining events. 12. Do not issue an application layer confirm to the device. 13. Wait for a period of time exceeding several of the Application Layer retry delays, if one exists. 14. Verify that the device has not retransmitted the previous Application Layer fragment. 15. Generate additional Binary Input Change Events. 16. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 17. Verify that the device responds with the same event data generated in step 4 and that the additional data generated in

step 15 is in time order (oldest first) in a single response. 18. § Verify that the device requests an application layer confirm. 19. Issue an application layer confirm to empty the device of pending events. 20. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 21. Verify that the device responds with a Null Response.

8.14.2.6 Binary Input Change Without Time, 0x06 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change Events. 5. Issue a request for Object 2 Variation 1 using the all data qualifier 0x06. 6. Verify that the device responds with all of the events in a single response. 7. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 8. § Verify that the device requests an application layer confirm. 9. Issue an application layer confirm to empty the device of pending events. 10. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 11. Verify that the device responds with a Null Response.

8.14.2.7 Binary Input Change Without Time, 0x07 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change Events.


5. Issue a request for Object 2 Variation 1 using the limit data qualifier 0x07 requesting some of the changes. 6. Verify that the device responds with the requested events in a single response. 7. § Verify that the device requests an application layer confirm. 8. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 9. Verify that flag behavior complies with Section 2, Note #5. 10. Verify that only Object 2, Variation 1 is returned. 11. Issue a request for Object 2 Variation 1 using the limit data qualifier 0x07 requesting the remaining changes. 12. Verify that the device responds with the remaining events. 13. § Verify that the device requests an application layer confirm. 12. Issue an application layer confirm to empty the device of pending events. 13. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 14. Verify that the device responds with a Null Response.

8.14.2.8 Binary Input Change Without Time, 0x08 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change Events. 5. Issue a request for Object 2 Variation 1 using the limit data qualifier 0x08 requesting some of the changes. 6. Verify that the device responds with the requested events in a single response. 7. § Verify that the device requests an application layer confirm. 8. Verify that the device responds with data using either qualifier 0x17 or 0x28. 9. Verify that flag behavior complies with Section 2, Note #5. 10. Verify that only Object 2, Variation 1 is returned. 11. Issue a request for Object 2 Variation 1 using the limit data qualifier 0x08 requesting the remaining changes. 12. Verify that the device responds with the remaining events. 13. § Verify that the device requests an application layer confirm. 15. Issue an application layer confirm to empty the device of pending events. 16. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 17. Verify that the device responds with a Null Response.

8.14.2.9 Binary Input Change With Time, 0x06 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change with Time Events. 5. Issue a request for Object 2 Variation 2 (binary change with time) using the all data qualifier 0x06. 6. If the device does not support Binary Input Change with Time Events, verify that the device replies with a null

response and skip all binary input change with time tests. 7. If the device does support Binary Input Change with Time Events, verify that the device responds with all the event

data generated in a single response. 8. § Verify that the device requests an application layer confirm. 9. Verify that only Object 2, Variation 2 is returned. 10. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 11. Verify that flag behavior complies with Section 2, Note #5. 12. Verify that the timestamps returned are reasonable (i.e. that they are incrementing by approximately the intervals in

which the events were generated within the resolution specified in the Device Profile). 13. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 14. Verify that the device responds with a Null Response.


8.14.2.10 Binary Input Change With Time, 0x07 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change Events. 5. Issue a request for Object 2 Variation 2 using the limit data qualifier 0x07 requesting some changes. 6. Verify that the device responds with the requested number of events in a single response. 7. § Verify that the device requests an application layer confirm. 8. Verify that only Object 2, Variation 2 is returned. 9. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 10. Verify that flag behavior complies with Section 2, Note #5. 11. Verify that the timestamps returned are reasonable (i.e. that they are incrementing by approximately the intervals in

which the events were generated within the resolution specified in the Device Profile). 12. Issue a request for Object 2 Variation 2 using the limit data qualifier 0x07 requesting the remaining changes. 13. Verify that the device responds with the remaining events. 14. § Verify that the device requests an application layer confirm. 15. Issue an application layer confirm if requested to empty the device of pending events. 15. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 16. Verify that the device responds with a Null Response.

8.14.2.11 Binary Input Change With Time, 0x08 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change Events. 5. Issue a request for Object 2 Variation 2 using the limit data qualifier 0x08 requesting some changes. 6. Verify that the device responds with the requested number of events in a single response. 7. § Verify that the device requests an application layer confirm. 8. Verify that only Object 2, Variation 2 is returned. 9. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 10. Verify that flag behavior complies with Section 2, Note #5. 11. Verify that the timestamps returned are reasonable (i.e. that they are incrementing by approximately the intervals in

which the events were generated within the resolution specified in the Device Profile). 12. Issue a request for Object 2 Variation 2 using the limit data qualifier 0x08 requesting the remaining changes. 13. Verify that the device responds with the remaining events. 14. § Verify that the device requests an application layer confirm. 15. Issue an application layer confirm if requested to empty the device of pending events. 17. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 18. Verify that the device responds with a Null Response.

8.14.2.12 Binary Input Change With Relative Time, 0x06 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change with Relative Time events. 5. Issue a request for Object 2 Variation 3 (binary change with relative time) using the all data qualifier 0x06. 6. If the device does not support Binary Input Change with Relative Time events verify that the device replies with a

null response and skip all Binary Input Change with Relative Time tests. 7. If the device does support Binary Input Changes with Relative Time, verify that the device responds with all the

event data generated in a single response preceded by the Common Time of Occurrence Object (Object 51, Variation 1 or 2) in the same APDU.


Note: If any subsequent event occurs more than 0xffff milliseconds after the first change a new Common Time of Occurrence Object (CTO Object 51, Variation 1 or 2) must be inserted into the response before the data for that event. This CTO can then be used for all additional changes that occur within 0xffff milliseconds.

8. § Verify that the device requests an application layer confirm. 9. Verify that the timestamps returned are reasonable (i.e. that they are incrementing by approximately the intervals in

which the events were generated within the resolution specified in the Device Profile). 10. Verify that only the Common Time of Occurrence Object (Object 51, Variation 1 or 2) and Object 2, Variation 3 are

returned. 11. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 12. Verify that flag behavior complies with Section 2, Note #5. 13. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 14. Verify that the device responds with a Null Response.

8.14.2.13 Binary Input Change With Relative Time, 0x07 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change Events. 5. Issue a request for Object 2 Variation 3 using the limit data qualifier 0x07 requesting some changes. 6. Verify that the device responds with requested events in a single response preceded by the Common Time of

Occurrence Object (Object 51, Variation 1 or 2) in the same APDU. Note: If any subsequent event occurs more than 0xffff milliseconds after the first change a new Common Time of Occurrence Object (CTO Object 51, Variation 1 or 2) must be inserted into the response before the data for that event. This CTO can then be used for all additional changes that occur within 0xffff milliseconds.

7. § Verify that the device requests an application layer confirm. 8. Verify that only the Common Time of Occurrence Object (Object 51, Variation 1 or 2) and Object 2, Variation 3 are

returned. 9. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 10. Verify that flag behavior complies with Section 2, Note #5. 11. Verify that the timestamps returned are reasonable (i.e. that they are incrementing by approximately the intervals in

which the events were generated within the resolution specified in the Device Profile). 12. Issue a request for Object 2 Variation 3 using the limit data qualifier 0x07 requesting the remaining changes. 13. Verify that the device responds with the remaining events preceded by the Common Time of Occurrence Object

(Object 51, Variation 1 or 2) in the same APDU. 14. § Verify that the device requests an application layer confirm. 15. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 16. Verify that the device responds with a Null Response.

8.14.2.14 Binary Input Change With Relative Time, 0x08 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change Events. 5. Issue a request for Object 2 Variation 3 using the limit data qualifier 0x08 requesting some changes. 6. Verify that the device responds with requested events in a single response preceded by the Common Time of

Occurrence Object (Object 51, Variation 1 or 2) in the same APDU. Note: If any subsequent event occurs more than 0xffff milliseconds after the first change a new Common Time of Occurrence Object (CTO Object 51, Variation 1 or 2) must be inserted into the response before the data for that event. This CTO can then be used for all additional changes that occur within 0xffff milliseconds.

7. § Verify that the device requests an application layer confirm. 8. Verify that only the Common Time of Occurrence Object (Object 51, Variation 1 or 2) and Object 2, Variation 3 are

returned. 9. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 10. Verify that flag behavior complies with Section 2, Note #5.


11. Verify that the timestamps returned are reasonable (i.e. that they are incrementing by approximately the intervals in which the events were generated within the resolution specified in the Device Profile).

12. Issue a request for Object 2 Variation 3 using the limit data qualifier 0x08 requesting the remaining changes. 13. Verify that the device responds with the remaining events preceded by the Common Time of Occurrence Object

(Object 51, Variation 1 or 2) in the same APDU. 14. § Verify that the device requests an application layer confirm. 15. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06. 16. Verify that the device responds with a Null Response.

8.14.2.15 Binary Input Change with Relative Time, Long Interval 1. Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Input Change Events. 5. Wait longer than 0xffff milliseconds. 6. Generate several Binary Input Change Events. 7. Issue a request for Object 2 Variation 3 using the limit data qualifier 0x06 requesting all changes. 8. Verify that the device responds with the requested events in a single response. 9. § Verify that the device requests an application layer confirm. 10. Verify that each group of events that occurred more than 0xffff milliseconds apart are preceded by a new Common

Time of Occurrence Object (Object 51, Variation 1 or 2) in the same APDU. 11. Verify that only the Common Time of Occurrence Objects (Object 51, Variation 1 or 2) and Binary Input Change

with Relative Time Objects (Object 2, Variation 3) are returned. 12. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 13. Verify that flag behavior complies with Section 2, Note #5. 14. Verify that the timestamps returned are reasonable (i.e. that they are incrementing by approximately the intervals in

which the events were generated within the resolution specified in the Device Profile Document). 15. Issue a request for Object 2 Variation 3 using the limit data qualifier 0x06 requesting all changes. 16. Verify that the device responds with a Null Response.

8.15 Common Time of Occurrence

8.15.1 Desired Behavior • If the DUT does not support Binary Input Change with Relative Time Events testing in this section is not required. • When responding to a request for binary input events BEFORE the time and date are set for the first time after the

DUT restarts: The DUT must send an Unsynchronized Common Time of Occurrence Object in each application fragment prior to any Binary Input Change with Relative Time Objects contained in that fragment.

• When responding to a request for binary input events AFTER the time and date are set for the first time after the DUT restarts:

The DUT must send a Synchronized Common Time of Occurrence Object in each application fragment prior to any Binary Input Change with Relative Time Objects contained in that fragment.

NOTE: When the following procedures require the test to “Verify that the objects returned are formatted correctly” interpret that to specifically mean the following:

1. The Synchronized/Unsynchronized Common Time of Occurrence Object precedes the Binary Input Change with Relative Time Objects in each fragment of the response.

2. If the response consists of multiple fragments each fragment must have a Synchronized/ Unsynchronized Common Time of Occurrence Object preceding any Binary Input Change with Relative Time Objects.

3. If any subsequent event occurs more than 0xffff milliseconds after the first change, a new Synchronized/Unsynchronized Common Time of Occurrence Object must be inserted into the response before


the data for that event. This CTO can then be used for all additional changes that occur within 0xffff milliseconds.

4. The data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 5. Flag behavior complies with Section 2, Note #5. 6. The timestamps returned are reasonable (i.e. that they are incrementing by approximately the intervals in which

the events were generated within the resolution specified in the Device Profile Document).

8.15.2 Test Procedure 1. If the DUT does not support Binary Input Change with Relative Time events no further testing is required in this

section. 2. Cause the DUT to restart. 3. Clear the Restart IIN. 4. Generate several Binary Input Change with Relative Time events. 5. Issue a request for Object 2 Variation 3 using the all data qualifier 0x06. 6. Verify that only the Unsynchronized Common Time of Occurrence Object (Object 51, Variation 2) and Binary Input

Change with Relative Time Objects (Object 2, Variation 3) are returned. 7. Verify that the objects returned are formatted correctly. 8. § Verify that the device requests an application layer confirm. 9. Issue an application layer confirm to empty the device of pending events. 10. Wait the specified maximum time from reset to IIN1-4 assertion. 11. Perform a time delay measurement. 12. § Verify that the device responds with a valid message and that IIN1-4 is set indicating that the device is requesting

time synchronization. 13. Set the time and date using Object 50 Variation 1 with Qualifier 0x07. 14. Verify that the device responds with a Null Response and that IIN1-4 is cleared indicating the device no longer

needs time. 15. Generate several Binary Input Change with Relative Time events. 16. Issue a request for Object 2 Variation 3 using the all data qualifier 0x06. 17. Verify that only the Synchronized Common Time of Occurrence Object (Object 51, Variation 1) and Binary Input

Change with Relative Time Objects (Object 2, Variation 3) are returned. 18. Verify that the objects returned are formatted correctly. 19. § Verify that the device requests an application layer confirm. 20. Issue an application layer confirm, to empty the device of pending events. 21. Generate several Binary Input Change with Relative Time events. 22. Wait the specified maximum time between time synchronization requests. 23. Perform a time delay measurement. 24. § Verify that the device responds with a valid message and that IIN1-4 is set indicating that the device is requesting

time synchronization. 25. Issue a request for Object 2 Variation 3 using the all data qualifier 0x06. 26. Verify that only the Synchronized Common Time of Occurrence Object (Object 51, Variation 1) and Binary Input

Change with Relative Time Objects (Object 2, Variation 3) are returned. 27. Verify that the objects returned are formatted correctly. 28. § Verify that the device requests an application layer confirm. 29. Do Not issue the application layer confirm. 30. Set the time and date using Object 50 Variation 1 with Qualifier 0x07. 31. Verify that the device responds with a Null Response and that IIN1-4 is cleared indicating the device no longer

needs time. 32. Issue a request for Object 2 Variation 3 using the all data qualifier 0x06. 33. Verify that the objects returned are formatted correctly. 34. § Verify that the device requests an application layer confirm. 35. Issue an application layer confirm, to empty the device of pending events. 36. Issue a request for Object 2 Variation 3 using the limit data qualifier 0x06 requesting all changes. 37. Verify that the device responds with a Null Response.


8.16 Binary Counters A binary counter represents an accumulated value. This can be accumulated pulses or transitions from a hardware or software point. There are two primary types of binary counters, running counters and frozen counters. Running binary counters report the current value of the counter at the time of reporting or the last reported value from the device. These values increment indefinitely until a counter clear operation is received, or the counter rolls over, then the values are cleared to 0. Frozen binary counters report values that were previously frozen by a command from the originating station. If the DUT is configurable in a manner such that points can be uninstalled or disabled, the device must be configured with at least one Binary Counter point installed or enabled before proceeding with the test procedure.

8.16.1 Binary Counters, Running Acceptable object variations and qualifier combinations included in a device response are specified in the following table.

Object Variation Qualifier Description 20 1 0x00,0x01 32-Bit Binary Counter 20 2 0x00,0x01 16-Bit Binary Counter 20 3 0x00,0x01 32-Bit Delta Counter 20 4 0x00,0x01 16-Bit Delta Counter 20 5 0x00,0x01 32-Bit Binary Counter Without Flag 20 6 0x00,0x01 16-Bit Binary Counter Without Flag 20 7 0x00,0x01 32-Bit Delta Counter Without Flag 20 8 0x00,0x01 16-Bit Delta Counter Without Flag

Table 8-5

8.16.1.1 Desired Behavior The following behavior assumes that the device does not support binary counters: • If the device does not support binary counters the device must respond to a binary counter read request with a null

response and no further testing in this section is necessary. • Optionally, the device can return an Error Response with IIN2-1 set. The following behavior assumes that the device supports binary counters: • If the device supports running binary counters the device must respond to a binary counter read request with a binary

counter read object (object 20 variation 1-8) using qualifiers 0x00 or 0x01. • Frozen binary counters will be tested in the next section. The following behavior assumes that the device does support binary counters, however there are no binary counter points installed: • If the device supports binary counters, the device must respond to a binary counter read request with a null response

and no further testing in this section is necessary. • Optionally, the device can return an Error Response with IIN2-1.


8.16.1.2.1 Device does not have Binary Counters 1. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 2. Verify that the DUT responds with a null response. The device can optionally return an Error Response with IIN2-1

set. No further testing in this section is necessary.


8.16.1.2.2 Device responds with Binary Counters 1. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 2. Verify that the DUT responds with binary counter objects (object 20 Variation 1-8). 3. Record the values for future reference. 4. Generate binary counter input data. 5. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 6. Verify that the reported values match the values recorded previously plus the counts generated in step 4. 7. Verify any points reported with Object 20, Variations 1, 2, 5, or 6 are reported with qualifiers 0x00 or 0x01. 8. Verify that flag behavior complies with Section 2, Note #5.

8.16.1.2.3 Device responds with Delta Counters 1. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 2. Issue an application layer confirm if requested. 3. If the device does not respond with Object 20 Variations 3, 4, 7, or 8, no further testing is necessary in this section. 4. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 5. § Verify the DUT requests an application layer confirm. 6. Issue the application layer confirm. 7. Verify the DUT reports all delta counter objects with a value of zero. 8. Generate new counts on some of the points reporting delta counters. 9. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 10. § Verify the DUT requests an application layer confirm. 11. Issue the application layer confirm. 12. Verify any points reported with Object 20, Variations 3, 4, 7, or 8 are reported with qualifiers 0x00 or 0x01. 13. Verify that flag behavior complies with Section 2, Note #5. 14. Verify the delta counter points that had no data generated are reported as zero. 15. Verify the delta counter points that had data generated have the exact same number of counts generated in step 8. 16. Generate new counts on some of the points reporting delta counters. Include some of the points incremented in step

8, and some different points. 17. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 18. § Verify the DUT requests an application layer confirm. 19. Issue the application layer confirm. 20. Verify any points reported with Object 20, Variations 3, 4, 7, or 8 are reported with qualifiers 0x00 or 0x01. 21. Verify the delta counter points that had no data generated are reported as zero. 22. Verify the delta counter points that had data generated have the exact same number of counts generated in step 16.

8.16.1.2.4 § Device Responds with Delta Counters, No Confirm 1. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 2. Issue an application layer confirm if requested. 3. If the device does not respond with Object 20 Variations 3, 4, 7, or 8, no further testing is necessary in this section. 4. Generate new counts on some of the points reporting delta counters. 5. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 6. Verify the DUT requests an application layer confirm. 7. DO NOT Issue the application layer confirm. 8. Wait several multiples of the application layer confirmation timeout for the DUT. 9. Verify the device does not perform an application layer retry. 10. Generate new counts on some of the points reporting delta counters. Include some of the points incremented in step

8, and some different points. 11. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 12. Verify the DUT requests an application layer confirm. 13. Issue the application layer confirm. 14. Verify the delta counter points that had no data generated are reported as zero. 15. Verify the delta counter points that had data generated report the sum of the counts generated in steps 4 and 10.


8.16.1.2.5 Device supports Binary Counters, Configurable Device 1. If the device is not configurable in a manner such that Binary Counter points can be uninstalled or disabled, no

further testing in this section is necessary. 2. Configure the DUT such that all Binary Counter points are uninstalled or disabled. 3. Issue a request for Object 20 Variation 0 using the all data qualifier 0x06. 4. Verify that the DUT responds with a null response. The device can optionally return an Error Response with IIN2-1

set.

8.16.2 Binary Counters, Frozen Acceptable object variations and qualifier combinations included in a device response are specified in the following table.

Object Variation Qualifier Description 21 1 0x00,0x01 32-Bit Frozen Counter 21 2 0x00,0x01 16-Bit Frozen Counter 21 9 0x00,0x01 32-Bit Frozen Counter Without Flag 21 10 0x00,0x01 16-Bit Frozen Counter Without Flag

Table 8-6

8.16.2.1 Desired Behavior The following behavior assumes that the device does not support frozen binary counters: • If the device does not support frozen binary counters the device must respond to a frozen binary counter read request

with a null response and no further testing in this section is necessary. • Optionally, the device can return an Error Response with IIN2-1 set. The following behavior assumes that the device supports frozen binary counters: • If the device supports frozen binary counters the device must respond to a frozen binary counter read request with a

frozen binary counter object (object 21 variation 1-8) using qualifiers 0x00 or 0x01. • Frozen binary counter data must only be updated after a freeze request is issued to object 20 Variation 0 (function

codes 0x07, 0x08, 0x09, or 0x0A). The following behavior assumes that the device does support frozen binary counters, however there are no frozen binary counter points installed: • If the device supports frozen binary counters the device must respond to a frozen binary counter read request with a

null response and no further testing in this section is necessary. • Optionally, the device can return an Error Response with IIN2-1 set.


8.16.2.2.1 Device does not have Frozen Counters. 1. Issue a read request for Object 21, variation 0, using the all data qualifier 0x06. 2. Verify that the DUT responds with a null response. The device can optionally return an Error Response with IIN2-1

set. No further testing in this section is necessary.

8.16.2.2.2 Binary Counter, Freeze 1. Issue a freeze to Object 20 Variation 0 using function code 0x07 and the all data qualifier 0x06. 2. Verify that the DUT responds with a Null Response. 3. Issue a read request for Object 21, variation 0, using the all data qualifier 0x06. 4. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10. 5. Record the values for future reference. 6. Generate counter data.


7. Issue a read request for Object 21 Variation 0, using the all data qualifier 0x06. 8. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10. 9. Verify that the data is reported using 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing (qualifier

0x01) 10. Verify that flag behavior complies with Section 2, Note #5. 11. Verify that the reported values match the values recorded previously. 12. Issue a freeze counter command to Object 20 Variation 0 using function code 0x07 and the all data qualifier 0x06. 13. Verify that the DUT responds with a Null Response. 14. Issue a read request for object 21 Variation 0, using the all data qualifier 0x06. 15. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10. 16. Verify that the reported values match the values recorded previously plus the counts generated in step 6.

8.16.2.2.3 Binary Counter, Freeze And Clear 1. Generate counter data. 2. Issue a freeze and clear to Object 20 Variation 0 using function code 0x09 and the all data qualifier 0x06. 3. Verify that the DUT responds with a Null Response. 4. Issue a read request for Object 21, variation 0, using the all data qualifier 0x06. 5. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10. 6. Verify that the values returned are non zero. 7. Verify that the data is reported using 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing (qualifier

0x01) 8. Verify that flag behavior complies with Section 2, Note #5. 9. Issue a freeze and clear counter command to Object 20 Variation 0 using function code 0x09 using the all data

qualifier 0x06. 10. Verify that the DUT responds with a Null Response. 11. Issue a read request for object 21 Variation 0, using the all data qualifier 0x06. 12. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10. 13. Verify that the reported values are all zero.

8.16.2.2.4 Binary Counter, Freeze, No Acknowledge 1. Issue a freeze to Object 20 Variation 0 using function code 0x08 and the all data qualifier 0x06. 2. Verify that the DUT does not respond. 3. Issue a read request for Object 21, variation 0, using the all data qualifier 0x06. 4. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10. 5. Record the values for future reference. 6. Generate counter data. 7. Issue a read request for Object 21 Variation 0, using the all data qualifier 0x06. 8. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10. 9. Verify that the reported values match the values recorded previously. 10. Verify that the data is reported using 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing (qualifier

0x01) 11. Verify that flag behavior complies with Section 2, Note #5. 12. Issue a freeze counter command to Object 20 Variation 0 using function code 0x08 using the all data qualifier 0x06. 13. Verify that the DUT does not respond. 14. Issue a read request for object 21 Variation 0, using the all data qualifier 0x06. 15. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10. 16. Verify that the reported values match the values recorded previously plus the counts generated in step 6.

8.16.2.2.5 Binary Counter, Freeze And Clear, No Acknowledge 1. Generate counter data. 2. Issue a freeze and clear to Object 20 Variation 0 using function code 0x0A and the all data qualifier 0x06. 3. Verify that the DUT does not respond. 4. Issue a read request for Object 21, variation 0, using the all data qualifier 0x06. 5. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10.


6. Verify that the data is reported using 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing (qualifier 0x01)

7. Verify that flag behavior complies with Section 2, Note #5. 8. Verify that the values returned are non zero. 9. Issue a freeze counter command to Object 20 Variation 0 using function code 0x08 and the all data qualifier 0x06. 10. Verify that the DUT does not respond. 11. Issue a read request for object 21 Variation 0, using the all data qualifier 0x06. 12. Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10. 13. Verify that the reported values are all zero.

8.17 Binary Counters, Event Binary Counter Change Event represents a counter value that has changed since it was last reported. This value can be accumulated transitions from a hardware or software point. § Any device that generates more than one link layer frame in response to a Class 0 Poll must support report-by-exception on all points. It is highly recommended that devices perform report by exception processing internally and respond to class polls with event data as defined in section 3.4. This allows efficient use of bandwidth. When no events are pending the device responds with the Null Response.

8.17.1 Desired Behavior • The device must respond with all of its Binary Counter Change Events when polled with the all data qualifier 0x06. • If the device does not support Binary Counter Events it must respond to a request with a null response and no further

testing in this section is necessary. • When polled with the limit data qualifier 0x07 or 0x08, the device must respond with a quantity of its binary counter

change events no greater than specified in the request. • The device must clear all of its Binary Counter Change Events only when an application confirm is received from

the master. • All event requests in this section are to be followed by a confirm message to the device unless otherwise indicated.


8.17.2.1 Device does not support Binary Counter Events 1. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 2. § Verify that if the DUT does have binary counter inputs and it responds to a Class 0 poll with more than one link

layer frame it also performs report-by exception processing. 3. If the DUT does not support Binary Counter Events, verify that it responds with a Null Response. No further testing

is required in this section.

8.17.2.2 Binary Counters, Event, 0x06 1. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm. 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 5. Verify that the device responds with a Null Response. 6. Generate some Counter Change Events. 7. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 8. Verify that the device responds with all of the events in a single response. 9. § Verify that the device requests an application layer confirm. 10. Verify that only Object 22, Variations 1 and/or 2 are returned. 11. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28) 12. Verify that flag behavior complies with Section 2, Note #5. 13. Record the values for future reference. DNP3-2001 IED Certification Procedure Page 67 Subset Level 2 Rev 2.1 – 5-July-01

14. Generate additional Counter Change Events. 15. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 16. Verify that the reported values match the values recorded previously plus the counts generated in step 14.

8.17.2.3 Binary Counters, Event, 0x07 1. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Counter Change Events. 5. Issue a request for Object 22 Variation 0 using the limit data qualifier 0x07 requesting some changes. 6. Verify that the device responds with the requested Binary Counter Change Events in a single response. 7. § Verify that the device requests an application layer confirm. 8. Verify that only Object 22, Variations 1 and/or 2 are returned. 9. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 10. Verify that flag behavior complies with Section 2, Note #5. 11. Issue a request for Object 22 Variation 0 using the limit data qualifier 0x07 requesting the remaining changes. 12. Verify that the device responds with the remaining Binary Counter Change Events. 13. § Verify that the device requests an application layer confirm. 14. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 15. Verify that the device responds with a Null Response.

8.17.2.4 Binary Counters, Event, 0x08 1. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06 to empty the device of pending events. 2. § Verify that the device requests an application layer confirm 3. Issue an application layer confirm if requested to empty the device of pending events. 4. Generate several Binary Counter Change Events. 5. Issue a request for Object 22 Variation 0 using the limit data qualifier 0x08 requesting some changes. 6. Verify that the device responds with the requested Binary Counter Change Events in a single response. 7. § Verify that the device requests an application layer confirm. 8. Verify that only Object 22, Variations 1 and/or 2 are returned. 9. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 10. Verify that flag behavior complies with Section 2, Note #5. 11. Issue a request for Object 22 Variation 0 using the limit data qualifier 0x08 requesting the remaining changes. 12. Verify that the device responds with the remaining Binary Counter Change Events. 13. § Verify that the device requests an application layer confirm. 14. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 15. Verify that the device responds with a Null Response.

8.17.2.5 § Binary Counters, Event Without Confirm 1. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 2. Verify that the device requests an application layer confirm. 3. Issue an application layer confirm to empty the device of pending events. 4. Generate Binary Counter Change Events. 5. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 6. Verify that the device responds with all the event data generated in a single response. 7. § Verify that the device requests an application layer confirm. 8. Do not issue an application layer confirm to the device. 9. Wait for a period of time exceeding several of the Application Layer retry delays, if one exists. 10. Verify that the device has not retransmitted the previous Application Layer fragment. 11. Generate additional Binary Counter Change Events including some on points not previously stimulated if possible. 12. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 13. Verify that the device responds with Object 22 Variation 1 or 2, with a value representing the current state of the

input(s) applied in step 11.


14. Optionally, the device can report the previous state of the input applied in step 4 followed by a value representing the current state of the input applied in step 11.

15. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 16. Verify that flag behavior complies with Section 2, Note #5. 17. § Verify that the device requests an application layer confirm. 18. Issue an application layer confirm to empty the device of pending events. 19. Issue a request for Object 22 Variation 0 using the all data qualifier 0x06. 20. Verify that the device responds with a Null Response.

8.18 Analog Input This is an object used to represent a hardware or software analog input. It can be a 16-bit or 32-bit value. The response could contain Object 30 Variations 1, 2, 3 or 4.

8.18.1 Desired Behavior • The device must respond with all of its analog input data when polled with Object 30 Variation 0 and the all data

qualifier 0x06. • If the device does not support analog inputs it must respond with a null response and no further testing in this section

is necessary. • Optionally, the device can respond with an Error Response with IIN2-1 set.


8.18.2.1 Device does not have Analog Inputs 1. Issue a request for Object 30 Variation 0 using the all data qualifier 0x06. 2. Verify that it responds with a null response. 3. Optionally, the device can set IIN2-1. No further testing is required in this section.

8.18.2.2 Device has Analog Inputs 1. Input analog data. 2. Issue a request for Object 30 Variation 0 using the all data qualifier 0x06. 3. Verify that the device responds with Object 30 Variation 1-4, Qualifier 0x00, or 0x01 along with a value

representing the analog input applied in step 1. 4. Verify that the device correctly reports that value for various analog inputs.

8.19 Analog Change Event The analog input change object is used to represent a hardware or software analog point. It will only be reported if the current value and the last reported value differ by a deadband value, which is usually configurable. For all the tests in this section the analog deadband shall be set to a reasonable value. § Any device that generates more than one link layer frame in response to a Class 0 Poll must support report-by-exception on all points. It is highly recommended that devices perform report by exception processing internally and respond to class polls with event data as defined in section 3.4. This allows efficient use of bandwidth. When no events are pending the device responds with the Null Response.

8.19.1 Desired Behavior • The device must respond with all of its Analog Input Change Events when polled with the all data qualifier 0x06. • If the device does not support Analog Input Change Events it must respond to a request with a null response. • The device must respond with Object 32 Variation 1 or 2 only if an event has occurred. • If the current and previous reported values do not differ within the defined deadband, the device must respond with a

null response.


• The device must clear all of its analog change events only when an application confirm is received from the master.

• All event requests in this section are to be followed by a confirm message to the device unless otherwise indicated.


8.19.2.1 Analog Input Change 1. Issue a request for Object 32 Variation 0, using the all data qualifier 0x06. 2. § Verify that if the DUT does have analog inputs and it responds to a Class 0 poll with more than one link layer

frame it also performs report-by exception processing. 3. If the device does not support analog inputs verify that the device responds with a null response. No further testing is

required in this section. 4. Generate a stable analog input to the device. 5. Issue a request for Object 32 Variation 0, using the all data qualifier 0x06. 6. Verify that the device responds with Object 32 Variation 1 or 2, with the value representing the input applied in step

4. 7. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 8. Verify that flag behavior complies with Section 2, Note #5. 9. § Verify that the device requests an application layer confirm. 10. Issue a request for Object 32 Variation 0, using the all data qualifier 0x06. 11. Verify that the device responds with a null response. 12. Increase or decrease the analog input applied in step 3 greater than the configured deadband. 13. Issue a request for Object 32 Variation 0, using the all data qualifier 0x06. 14. Verify that the device responds with Object 32 Variation 1 or 2, with the value representing the new input from step

11.

8.19.2.2 § Analog Input Change, Without Confirm 1. Generate a stable analog input to the device that exceeds the current input value by the configured deadband value

(e.g. cause an event to be generated). 2. Issue a request for Object 32 Variation 0, using the all data qualifier. 3. Verify that the device responds with Object 32 Variation 1 or 2, with the value representing the input applied in step

1. 4. Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28). 5. Verify that flag behavior complies with Section 2, Note #5. 6. § Verify that the device requests an application layer confirm. 7. Wait for a period of time exceeding several of the Application Layer retry delays, if one exists. 8. Verify that the device has not retransmitted the previous Application Layer fragment. 9. Increase or decrease the analog input applied in step 1. 10. Issue a request for Object 32 Variation 0, using the all data qualifier 0x06. 11. Verify that the device responds with Object 32 Variation 1 or 2, with a value representing the current state of the

input applied in step 9. 12. Optionally, the device can report the previous state of the input applied in step 1 followed by a value representing

the current state of the input applied in step 9. 13. Verify that the device requests an application layer confirm. 14. Issue an application layer confirm. 15. Issue a request for Object 32 Variation 0, using the all data qualifier 0x06. 16. Verify that the device responds with a null response.

8.20 Multiple Read Requests

8.20.1 Desired Behavior • The DUT must respond to read requests for multiple object types


8.20.2 Test Procedure 1. Issue a request containing one of each supported object type listed in the implementation table within a single frame.

Issue the event requests before the requests for static objects. 2. Verify that the DUT response has none of IIN2-x set. 3. Verify the validity of the returned object type data. Note that the DUT may not return event objects if they are not

present. 4. Verify data objects are returned in the order requested.


9 Appendix A – DNP Reference Sheets QUICK REFERENCE FOR DNP DATA LINK CONTROL FIELD D finitionse :

MSB

LSB

DIR

1

PRM

0

FCB

FCV

FUNCTION CODE

Primary

0

DFC

Secondary

7

6

5

4

3

2

1

0

DIR 1 = Master, 0 = Remote PRM 1 = Data Link Request, 0 = Data Link Response FCB Frame Count Bit, alternates 1 and 0 FCV Frame Count Valid; 1 = valid, 0 = invalid DFC Data Flow Control; 1 = no buffers left Function Codes:

Primary Frames (PRM=1) Fn Code

Function

Frame Type

FCV

0

RESET link

SEND/CONFIRM

0

1

Reset User Process

SEND/CONFIRM

0

2

TEST link

SEND/CONFIRM

1

3

User Data

SEND/CONFIRM

1

4

User Data

SEND/NO REPLY

0

9

Request Link Status

REQUEST/RESPOND

0

Secondary Frames (PRM = 0)

Fn Code

Function

Frame Type

0

ACK

CONFIRM

1

NACK

CONFIRM

11

Link Status

RESPOND


QUICK REFERENCE FOR DNP DATA LINK CONTROL FIELD List of Valid Control Field values by hex value; most common in bold: From Remote

From Master

Function

Other

00

80

ACK

01

81

NACK

Failed transaction

0B

8B

Link Status Reply

No flow Control

10

90

ACK

Frame accepted, no more buffers left

11

91

NACK

Frame not accepted, no buffers available

1B

9B

Link Status Reply

No buffers available

40

C0

RESET LINK

41

C1

Reset User Process

44

C4


49

C9

Link Status Request

52

D2

Test Link

FCB = 0

53

D3

Confirmed User Data

FCB = 0

60

E0

RESET LINK

FCB = 1 ignored

61

E1

Reset User Process

FCB = 1 ignored

64

E4


FCB = 1 ignored

69

E9

Link Status Request

FCB = 1 ignored

72

F2

Test Link

FCB = 1

73

F3

Confirmed User Data

FCB = 1

Frame Header: Byte

1

2

3

4

5

6

7

8

9

10

11

Name

05

64

LEN

CTRL

DEST

SOURCE

CRC

TH

Transport Header(TH): Bit 7 = FINAL, Bit 6 = FIRST


Message Header Object Header Object Header Data

Appl. Ctrl

Func Code

equest Header Response Header

Internal Indication

T

2 1

RES

TAR

T U

BLE

CAL

TI

ME

SS 3

SS

2

SS 1

AL

L ST

ATIO

NS

SEC 7 6 0��

��

� �

�

RES

ERVE

D

RES

ERVE

D

BAD

CO

NFI

G

ALR

EAD

Y EX

EC

BUFF

ER O

VER

FLO

W

OU

T O

F R

ANG

E O

BJEC

T U

NKN

OW

N

BAD

FU

NC

TIO

N

��

��

0x00 Confirm 0x01 Read 0x02 Write 0x03 Select 0x04 Operate 0x05 Direct Operate 0x06 Direct Op, No Ack 0x07 Immediate Freeze 0x08 Immediate Freeze No Ack 0x09 Freeze and0x0A Freeze and0x0B Freeze with0x0C Freeze with0x0D Cold Resta0x0E Warm Rest0x0F Init Data to 0x10 Initialize Ap0x11 Start Applic0x12 Stop Applic0x13 Save Config0x14 Enable Uns0x15 Disable Unsolicited Msgs 0x16 Assign Class 0x17 Delay Measurement

0x00 C0x81 R0x82

Object Variation

Qualifier Range

INDEX SIZE 0 – No Index, Packed 1 – 1 Octet Index 2 – 2 Octet Index 3 – 4 Octet Index 4 – 1 Octet Object Size 5 – 2 Octet Object Size 6 – 4 Octet Object Size

QUALIFIER CODE 0 – 8-Bit Start and Stop Indices 1 – 16-Bit Start and Stop Indices 2 – 32-Bit Start and Stop Indices 3 – 8-Bit Absolute Address Identifers 4 – 16-Bit Absolute Address Identifiers 5 – 32-Bit Absolute Address Identifers 6 – No Range Field (all) 7 – 8-Bit Quantity 8 – 16-Bit Quantity 9 – 32-Bit Quantity 11 – (0xB) Variable Array

INDEX SIZE (QUAL CODE = 11) 0 – Dataless Object; No Further Indexing 1 – 1 Octet Index or Identifier Size 2 – 2 Octet Index or Identifier Size 3 – 4 Octet Index or Identifier Size

APCI DUI DUIIO

P = Distrib dNetwProtocol

APDU = ApplicationProtocol Data Unit

APCI = ApplicationProtocolControl Informat

I = Data UnIdentifier

= InformationObject

uteork

6

5

4

3

2 1 0

FIN

AL

CO

NFI

RM

U

NSO

LIC

ITED

SEQ

UEN

CE

IO DDNNPP AAPPDDUU

t Library Depends on Qualifier Code

7 6 5 4 3 2 1 0

��

��

��

Func Code

Appl. Ctrl

Data

age 74 DNP3-2001 IED Certification Procedure ev 2.1 – 5-July-01 Subset Level 2

PR

DU

IO

7

FIR

ST

R

DN

ion

it

Clear Clear No Ack Time Time No Ack rt art Defaults plication ation ation uration olicited Msgs

DEV

. TR

O LON

EED

C

LAC

LAC

LA

OND OCTET 5 4 3 2 1

��

FIRST OCTE7

6

5

4

3

onfirm esponse

Unsolicited Response

0

Object Group

See Data Objec

dnp3 doc library

Documents

dnp users group

distributed network protocol

bit floating point

data link services

data link user

analog output values

dnp data link

low order octet