Professional Documents
Culture Documents
RE:
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 25, 2004 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
Binary input data that is useful to monitor two-state devices. For example a circuit breaker is closed or
tripped or a pipeline pressure alarm shows normal or excessive.
Analog input data that conveys voltages, currents, power, reservoir water levels and temperatures.
Count input data that reports kilowatt hours of energy.
Files that contain configuration data.
The master station issues control commands that take the form of
1.
2.
Close or trip a circuit breaker, raise or lower a gate, and open or close a valve.
Analog output values to set a regulated pressure or set a desired voltage level.
Other things the computers talk to each other about are synchronizing the time and date, sending historical or logged
data, waveform data, and on and on.
DNP3 was designed to optimize the transmission of data acquisition information and control commands from one
computer to another. It is not a general purpose protocol for transmitting hypertext, multimedia or huge files.
The terms server and client are applicable to DNP3 systems. For our purposes, the definition of a server is a device
or software process that has data or information that someone else wants. Substation computers are servers. A
client is a device or software process that requests data from a server. A master station is a client.
1 June 2000
Master (Client)
Binary
Input
8
7
6
5
4
3
2
1
0
Control
Output
Analog
Input Counter
Input
4
3
3
2
2
1
1
0
0
6
5
4
3
2
1
0
Slave (Server)
Binary
Input
8
7
6
5
4
3
2
1
0
Analog
Output
4
3
2
1
0
Control
Output
Analog
Input Counter
Input
4
3
3
2
2
1
1
0
0
6
5
4
3
2
1
0
DNP3
Software
DNP3
Software
Analog
Output
4
3
2
1
0
Physical Media
User Requests
User Responses
Figure 1
Figure 1 shows the client-server relationship and gives a simplistic view of the databases and software processes
involved. The master or client is on the left side of figure 1, and the slave or server is on the right side.
A series of square blocks at the top of the server depicts its databases and output devices. The various data types
are conceptually organized as arrays. An array of binary input values represents states of physical or logical boolean
devices. Values in the analog input array represent input quantities that the server measured or computed. An array
of counters represents count values, such as kilowatt hours, that are ever increasing (until they reach a maximum
and then roll over to zero and start counting again.) Control outputs are organized into an array representing
physical or logical on-off, raise-lower and trip-close points. Lastly, the array of analog outputs represents physical or
logical analog quantities such as those used for setpoints.
The elements of the arrays are labeled 0 through N - 1 where N is the number of blocks shown for the respective
data type. In DNP3 terminology, the element numbers are called the point indexes. Indexes are zero-based in
DNP3, that is, the lowest element is always identified as zero. Some protocols use 1-based indexing.
Notice that the DNP3 client, or master, also has a similar database for the input data types (binary, analog and
counter.) The master, or client, uses values in its database for the specific purposes of displaying system states,
closed-loop control, alarm notification, billing, and much, much more. An objective of the client is to keep its
database updated. It accomplishes this by sending requests to the server (slave) asking it to return the values in the
servers database. This is termed polling. The server responds to the clients request by transmitting the contents of
its database. Arrows are drawn at the bottom of figure 1 showing the direction of the requests (toward the server)
and the direction of the responses (toward the client.) Later we will discuss systems whereby the slaves transmit
responses without being asked.
1 June 2000
The client and the server shown in figure 1 each have two software layers. The top layer is the DNP3 user layer. In
the client, it is the software that interacts between the database and initiates the requests for the servers data. In
the server, it is the software that fetches the requested data from the servers database for responding to client
requests. It is interesting to note, that if no physical separation of the client and server existed, eliminating the DNP3
might be possible by connecting these two upper layers together. However, since physical, or possibly logical
separation of the client and server exists, DNP3 software is placed at a lower level. The DNP3 users code uses the
DNP3 software for transmission of requests or responses to the matching DNP3 users code at the other end.
More will be said about data types and software layers later, but first we want to examine a few typical system
architectures where DNP3 is used.
DNP3
Client
(Master)
DNP3
Server
(Slave)
One-on-One
DNP3
Client
(Master)
DNP3
Server
(Slave)
DNP3
Server
(Slave)
DNP3
Server
(Slave)
Multidrop
DNP3
Client
(Master)
DNP3
Server
Client
(Slave)
(Master)
DNP3
Server
(Slave)
Hierarchical
DNP3
Client
(Master)
DNP3
Server
(Slave)
XYZ
Client
(Master)
XYZ
Server
(Slave)
XYZ
Server
(Slave)
DNP3
Server
(Slave)
DNP3
Server
(Slave)
Data Concentrator
XYZ
Client
(Master)
XYZ
Server
(Slave)
DNP3
Client
(Master)
Data Concentrator
Figure 2
Figure 2 shows common system architectures in use today. At the top is a simple one-on-one system having one
master station and one slave. The physical connection between the two is typically a dedicated or dial-up telephone
line.
The second type of system is known as a multidrop design. One master station communicates with multiple slave
devices. Conversations are typically between the client and one server at a time. The master requests data from
the first slave, then moves onto the next slave for its data, and continually interrogates each slave in a round robin
order. The communication media is a multi-dropped telephone line, fiber optic cable, or radio. Each slave can hear
messages from the master and is only permitted to respond to messages addressed to itself. Slaves may or may
not be able to hear each other.
In some multidrop forms, communications are peer-to-peer. A station may operate as a client for gathering
information or sending commands to the server in another station. And then, it may change roles to become a
server to another station.
1 June 2000
The middle row in figure 2 shows a hierarchical type system where the device in the middle is a server to the client at
the left and is a client with respect to the server on the right. The middle device is often termed a sub-master.
Both lines at the bottom of figure 2 show data concentrator applications and protocol converters. A device may
gather data from multiple servers on the right side of the figure and store this data in its database where it is
retrievable by a master station client on the left side of the figure. This design is often seen in substations where the
data concentrator collects information from local intelligent devices for transmission to the master station.
In recent years, several vendors have used TCP/IP to transport DNP3 messages in lieu of the media discussed
above. Link layer frames, which we have not talked about yet, are embedded into TCP/IP packets. This approach
has enabled DNP3 to take advantage of Internet technology and permitted economical data collection and control
between widely separated devices.
Many communication circuits between the devices are imperfect. They are susceptible to noise and signal distortion.
The DNP3 software is layered to provide reliable data transmission and to effect an organized approach to the
transmission of data and commands. Figure 3 shows the layering that was not shown in figure 1.
Master (Client)
Binary
Input
8
7
6
5
4
3
2
1
0
8
7
6
5
4
3
2
1
0
Analog
Counter
4
3
2
1
0
Slave (Server)
Binary
Input
3
2
1
0
Control
Output
Analog
Counter
4
3
2
1
0
3
2
1
0
6
5
4
3
2
1
0
DNP3
Application Layer
DNP3
Application Layer
DNP3
Link Layer
DNP3
Link Layer
Analog
Output
4
3
2
1
0
Physical Media
User Requests
User Responses
Figure 3
The link layer has the responsibility of making the physical link reliable. It does this by providing error detection and
duplicate frame detection. The link layer sends and receives packets, which in DNP3 terminology, are called frames.
1 June 2000
Sometimes transmission of more than one frame is necessary to transport all of the information from one device to
another.
A DNP3 frame consists of a header and data section. The header specifies the frame size, which DNP3 station
should receive the frame, which DNP3 device sent the frame and data link control information. The data section is
commonly called the payload and contains the data passed down from the layers above.
DNP3 Frame
Header
Data
Header
Sync
Length
Link Control
Destination
Address
Source Address
CRC
Every frame begins with two sync bytes that help the receivers determine where the frame begins. The length
specifies the number of octets in the remainder of the frame, not including CRC check octets. The link control octet
is used between sending and receiving link layers to coordinate their activities.
A destination address specifies which DNP3 device should process the data, and the source address identifies
which DNP3 device sent the message. Having both destination and source addresses satisfies at least one
requirement for peer-to-peer communications because the receiver knows where to direct its responses. 65520
individual addresses are available. Every DNP3 device must have a unique address within the collection of devices
sending and receiving messages to and from each other. Three destination addresses are reserved by DNP3 to
denote an all-call message; that is, the frame should be processed by all DNP3 devices. Thirteen addresses are
reserved for special needs in the future.
The data payload in the link frame contains a pair of CRC octets for every 16 data octets. This provides a high
degree of assurance that communication errors can be detected. The maximum number of octets in the data
payload is 250, not including CRC octets. (The longest link layer frame is 292 octets if all the CRC and header
octets are counted.)
One often hears the term link layer confirmation when DNP3 is discussed. A feature of DNP3's link layer is the
ability for the transmitter of the frame to request the receiver to confirm that the frame arrived. Using this feature is
optional, and it is often not employed. It provides an extra degree of assurance of reliable communications. If a
confirmation is not received, the link layer may retry the transmission. Some disadvantages are the extra time
required for confirmation messages and waiting for multiple timeouts when retries are configured.
It is the responsibility of the transport layer to break long messages into smaller frames sized for the link layer to
transmit, or when receiving, to reassemble frames into the longer messages. In DNP3 the transport layer is
incorporated into the application layer. The transport layer requires only a single octet within the message to do its
work. Therefore, since the link layer can handle only 250 data octets, and one of those is used for the transport
function, then each link layer frame can hold as many as 249 application layer octets.
Application layer messages are broken into fragments. Fragment size is determined by the size of the receiving
devices buffer. It normally falls between 2048 and 4096 bytes. A message that is larger than a one fragment
requires multiple fragments. Fragmenting messages is the responsibility of the application layer.
Note that an application layer fragment of size 2048 must be broken into 9 frames by the transport layer, and a
fragment size of 4096 needs 17 frames. Interestingly, it has been learned by experience that communications are
sometimes more successful for systems operating in high noise environments if the fragment size is significantly
reduced.
1 June 2000
The application layer works together with the transport and link layers to enable reliable communications. It provides
standardized functions and data formatting with which the user layer above can interact. Before functions, data
objects and variations can be discussed, the terms static, events and classes need to be covered.
In DNP3, the term static is used with data and refers to the current value. Thus static binary input data refers to the
present on or off state of a bi-state device. Static analog input data contains the value of an analog at the instant it is
transmitted. One possibility DNP3 allows is requesting some or all of the static data in a slave device.
DNP3 events are associated with something significant happening. Examples are state changes, values exceeding
some threshold, snapshots of varying data, transient data and newly available information. An event occurs when a
binary input changes from an on to an off state or when an analog value changes by more than its configured
deadband limit. DNP3 provides the ability to report events with and without time stamps so that the client can
generate a time sequence report.
The user layer can direct DNP3 to request events. Usually, a client is updated more rapidly if it mostly polls for
events from the server and only occasionally asks for static data as an integrity measure. The reason updates are
faster is because the number of events generated between server interrogations is small and, therefore, less data
must be returned to the client.
DNP3 goes a step further by classifying events into three classes. When DNP3 was conceived, class 1 events were
considered as having higher priority than class 2 events, and class 2 were higher than class 3 events. While that
scheme can be still be configured, some DNP3 users have developed other strategies more favorable to their
operation for assigning events into the classes. The user layer can request the application layer to poll for class 1, 2
or 3 events or any combination of them.
DNP3 has provisions for representing data in different formats. Examination of analog data formats is helpful to
understand the flexibility of DNP3. Static, current value, analog data can be represented by variation numbers as
follows:
1.
2.
3.
4.
5.
6.
Not all DNP3 devices can transmit or interpret all six variations. Later, DNP3 levels are discussed, but for now,
suffice it to say that DNP3 devices must be able to transmit the simplest variations so that any receiver can interpret
the contents.
Event analog data can be represented by these variations:
1.
2.
3.
4.
5.
6.
7.
8.
1 June 2000
It looks like a variation one or two analog event cannot be differentiated from a variation one or two static analog
value. DNP3 solves this predicament by assigning object numbers. Static analog values are assigned as object 30,
and event analog values are assigned as object 32. Static analog values, object 30, can be formatted in one of 6
variations, and event analog values, object 32, can be formatted in one of 8 variations.
When a DNP3 server transmits a message containing response data, the message identifies the object number and
variation of every value within the message. Object and variation numbers are also assigned for counters, binary
inputs, controls and analog outputs. In fact, all valid data types and formats in DNP3 are identified by object and
variation numbers. Defining the allowable objects and variations helps DNP3 assure interoperability between
devices. DNP3's basic documentation contains a library of valid objects and their variations.
The clients user layer formulates its request for data from the server by telling the application layer what function to
perform, like reading, and specifying which objects it wants from the server. The request can specify how many
objects it wants or it can specify specific objects or a range of objects from index number X through index number Y.
The application layer then passes the request down through the transport layer to the link layer that, in turn, sends
the message to the server. The link layer at the server checks the frames for errors and passes them up to the
transport layer where the complete message is assembled in the servers application layer. The application layer
then tells the user layer which objects and variations were requested.
Responses work similarly, in that, the servers user layer fetches the desired data and presents it to the application
layer that formats the data into objects and variations. Data is then passed downward, across the communication
channel and upward to the clients application layer. Here the data objects are presented to the user layer in a form
that is native to the clients database.
Reading data was mentioned in the above two paragraphs, but DNP3 software is designed to handle other functions.
For one the client can set the time in the server. The client can transmit freeze accumulator requests, and it can
transmit requests for control operations and setting of analog output values using select-before-operate or directoperate sequences.
One area that has not been covered yet is transmission of unsolicited messages. This is a mode of operating where
the server spontaneously transmits a response, possibly containing data, without having received a specific request
for the data. Not all servers have this capability, but those that do must be configured to operate in this mode. This
mode is useful when the system has many slaves and the master requires notification as soon as possible after a
change occurs. Rather than waiting for a master station polling cycle to get around to it, the slave simply transmits
the change.
To configure a system for unsolicited messages, a few basics need to be considered. First, spontaneous
transmissions should generally occur infrequently, otherwise, too much contention can occur, and controlling media
access via master station polling would be better. The second basic issue is that the server should have some way
of knowing whether it can transmit without stepping on someone elses message in progress. DNP3 leaves
specification of algorithms to the system implementor.
One last area of discussion involves implementation levels. The DNP3 organization recognizes that supporting
every feature of DNP3 is not necessary for every device. Some devices are limited in memory and speed and do not
need specific features, while other devices must have the more advanced features to accomplish their task. DNP3
organizes complexity into three levels. At the lowest level, level 1, only very basic functions must be provided and all
others are optional. Level 2 handles more functions, objects and variations, and level 3 is even more sophisticated.
Within each level only certain combinations of request formats and response formats are required. This was done to
limit software code in clients and servers while still assuring interoperability.
It should be apparent by now that DNP3 is a protocol that fits well into the data acquisition world. It transports data
as generic values, it has a rich set of functions, and it was designed to work in a wide area communications network.
The standardized approach of objects and variations, and link, transport and application layers, plus public
availability makes DNP3 a protocol to be regarded.
1 June 2000
Author:
Ken Curtis from Woodland Engineering wrote this paper to help the many people who are just getting into or
considering DNP3 for their operation. Ken is a consulting engineer that has been contracted to write software for
DAQ Electronics who also sponsors his participation in the DNP Technical Committee. Valuable editing assistance
was provided by Mike Thesing of Advanced Control Systems.
Fax:
403-271-1319
Email:
dnp@home.com
Website:
www.dnp.org
1 June 2000
Version
By Whom:
N. Male
Pages
Affected:
All
Nov. 11/91
Nov. 18/91
Jul. 24/92
0.00B
0.00C
0.00D
J.McFadyen
J. McFadyen
MCH
2-11
Aug. 17/92
Oct. 22/92
0.01A
0.01B
MS
MS
Oct. 27/92
0.01C
MS
Nov. 8/92
0.01D
MS
All
Nov. 24/92
Jan. 22/93
July. 20/93
0.02
0.02
0.02
LA
MS
MS
All
vi,1-1,2-2
i,ii
All
1-1
2-1
Date
Version
By Whom:
Pages
Affected:
2-2
2-3
2-5
2-7
2-9,2-10
2-11,2-12
2-14
2-15
2-20
2-21
2-23
3-1,3-2
4-4
G-1,G-2
Aug.30/93
0.02
J.Bhat
All
AV
S. Tessari
All
All
DNP V3.00
DATA LINK LAYER
TRADEMARK NOTICES
Brand and product names mentioned in this document are trademarks or
registered trademarks of their respective companies.
TABLE OF CONTENTS
ABOUT THIS DOCUMENT
PURPOSE OF THIS SPECIFICATION
WHO SHOULD USE THIS SPECIFICATION
HELP AND ADDITIONAL DOCUMENTATION
HOW THIS SPECIFICATION IS ORGANIZED
CONVENTIONS USED IN THIS SPECIFICATION
v
v
v
v
vi
vi
1. OVERVIEW
1-1
2. IEC CONFORMANCE
2.1 CHANNEL FAILOVER
2.2 FRAME FORMAT AND PROCEDURES
2.3 LENGTH, CONTROL AND ADDRESS FIELDS
2-1
2-1
2-1
2-2
3-1
3-1
3-1
3-2
3-6
3-6
3-7
3-10
4-1
4-1
4-2
5-1
5-1
6-1
6-1
6-1
6-2
7-1
7-1
7-1
7-2
ii
TABLE OF FIGURES
FIGURE 3-1 FT3 FRAME FORMAT
3-2
FIGURE 3-2 CONTROL OCTET BIT DEFINITIONS
3-3
FIGURE 3-3 TABLE OF PRIMARY AND SECONDARY FUNCTION CODES
3-5
FIGURE 3-4 DESTINATION ADDRESS FORMAT
3-5
FIGURE 3-5 SOURCE ADDRESS FORMAT
3-5
FIGURE 3-6 CRC ORDERING
3-7
FIGURE 3-7 RESET OF SECONDARY LINK
3-10
FIGURE 3-8 RESET OF USER PROCESS
3-11
FIGURE 3-9 SEND FROM STATION A/CONFIRM FROM STATION B
3-11
FIGURE 3-10 SEND FROM STATION B/CONFIRM FROM STATION A
3-11
FIGURE 3-11 SEND MULTIPLE FRAMES FROM STATION A/CONFIRM FROM
STATION B
3-12
FIGURE 3-12 FRAME COUNT BIT OPERATION
3-12
FIGURE 3-13 FRAME COUNT BIT OPERATION
3-13
FIGURE 3-14 SEND-NO-REPLY EXPECTED FROM STATION A
3-13
FIGURE 3-15 SEND FROM STATION B/NACK FROM STATION A
3-14
FIGURE 3-16 REQUEST/RESPOND FRAME AND DFC BIT USAGE
3-15
iii
iv
vi
1. OVERVIEW
This document defines the Distributed Network Protocol (DNP) V3.00 Data Link layer,
Link Protocol Data Unit (LPDU), as well as data link layer services and transmission
procedures. Master stations, submaster stations, outstations and intelligent electronic
devices (IEDs) can use this data link to pass messages between primary (originating)
stations and secondary (receiving) stations. In this protocol, master stations, submaster
stations, outstations and IEDs are both originators (primary stations) and receivers
(secondary stations).
The IEC 870-5-1 and IEC 870-5-2 standards set out by the International Electrotechnical
Commission (IEC), Technical Committee No. 57 for data transmission in telecontrol
systems were used as a basis for developing the DNP V3.00 Data Link layer.
The DNP V3.00 Data Link layer supports polled and quiescent telecontrol systems and is
designed to operate with connection and connection-less orientated, asynchronous or
synchronous bit-serial physical layers such as RS-232C, RS-485 and fibre transceivers.
Fully-balanced transmission procedures were adopted to support spontaneous
transmissions from outstations, IEDs or submaster stations not designated as master
stations.
The ISO OSI based model supported by this protocol specifies physical, data link and
application layers only. This is termed the Enhanced Performance Architecture (EPA).
However, to support advanced RTU functions and messages larger than the maximum
frame length as defined by the IEC document 870-5-1, the DNP Version 3 Data Link is
intended to be used with a pseudo-transport layer which implements as a minimum
message assembly and disassembly.
This pseudo-transport layer is described in the document, DNP V3.00 Transport
Functions (P009-0PD.TF). It is stressed, however, that these transport functions are not a
part of the data link but are needed to support advanced RTU functions.
1-1
2. IEC CONFORMANCE
This chapter describes the difference between the DNP protocol and the IEC TC-57 (8705) telecontrol data link layer protocol specification.
2-1
2-2
3-1
START START LENGTH CONTROL DESTINATION SOURCE CRC USER CRC ...
0x05 0x64
DATA
START
LENGTH
CONTROL
DESTINATION
SOURCE
CRC
USER DATA
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
FCV
DFC
RES
Reserved = 0
FUNCTION CODE
Defines the frame type, how the data link will handle the frame
The direction bit indicates the physical direction of the frame with relation to the
designated master station. Station A is the master.
DIR = 1 indicates a frame from A to B
DIR = 0 indicates a frame from B to A
PRM The primary message bit indicates the direction of the frame in relation to the
initiating station.
PRM =1 indicates a frame from the initiating station
PRM =0 indicates a frame from the responding station.
FCB
The frame count bit is used for suppressing losses and duplication of frames to the
same secondary station. This bit toggles for each successful SEND-CONFIRM
service that is initiated by the same primary station and directed to the same
secondary station.
Initially before communications with a secondary station or after communication
failure, the primary station (in both the master station and outstation) must reset
the data link for each secondary station data link it wishes to communicate with.
This can be done once at data link start-up for all secondary stations or as needed.
3-3
Each secondary station, after data link start-up or transaction failure, must not
accept any primary SEND-CONFIRM messages with FCV set until a RESET
command has been received and a CONFIRM message sent.
FCV
The frame count valid bit enables the functioning of the FCB bit.
FCV =0 indicates the state of the FCB bit is ignored
FCV =1 indicates to a secondary station that the state of the FCB bit must be
checked against the state of the FCB bit of the last frame sent with the FCV bit
set.
DFC
The data flow control bit is used to prevent the overflowing of buffers in a
secondary station. The secondary station returns this bit set to a 1 if further SEND
of user data to this secondary station will cause data link buffers to over flow. The
primary station must interrogate the secondary station using REQUESTRESPOND Request Link Status until the DFC is returned with a value of 0. At
this point the primary station can continue with the sending of user data. Figure 316 illustrates the DFC bit usage.
FUNCTION CODE
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
Not Used
-
Not used
-
Not Used
-
Not Used
-
9
REQUEST - RESPOND expected REQUEST LINK STATUS
0
10
Not Used
-
11
Not Used
-
12
Not Used
-
13
Not Used
-
14
Not Used
-
15
Not Used
-
3-4
Function Code Field Values of the Control Octet Sent from the Secondary Station (PRM
= 0)
Code
0
CONFIRM
ACK - positive acknowledgement
1
CONFIRM
NACK - Message not accepted, Link busy
Not Used
Not Used
Not Used
Not Used
Not Used
Not Used
Not Used
Not Used
10
Not Used
11
RESPOND
Status of Link (DFC = 0 or DFC = 1)
12
Not Used
13
Not Used
14
15
3-5
3-6
To receive a block:
(1)Receive a block (T') (k+16 bits).
(2)Invert R'(16-bits) in T'(k+16 bits) to get T (k+16 bits).
(3)Divide T (module-2) by P (17-bits) to get the remainder.
(4)If the remainder is not 0 then there is an error in the block else the block is good.
Using the FT3 frame format class and CRC, the frame has a Hamming distance of 6.
The diagram below shows the ordering of the 16-bit CRC check word with respect to any
blocks (user data or header).
LSB MSB
Block Octets
CRC
3-7
If ACK frame is received, set FCB status to 1 (i.e. next frame sent to secondary with FCV
valid should have FCB=1) and exit loop.
If frame is not received then go to top of loop and re-try
End do loop
If ACK was received then the transaction is considered successful and the secondary
station can be considered on-line. A positive INDication can be returned to the data link
user.
Otherwise, the secondary station should be considered off-line and a negative INDication
should be sent to the data link user.
3.6.1.2 Secondary Transaction
After start-up or after transaction failure do:
Wait for reception of RESET command with FCV=0, FCB=x, PRM=1, DIR=x.
Respond with an ACK confirm frame (DFC=x, PRM=0, DIR=x). The FCB status
(expected value of FCB in next received frame with FCV valid) should be set to 1. A
positive INDication can be sent to the data link user.
During normal operation, if a RESET command with FCV=0, FCB=x, PRM=1 and
DIR=x is received, then the current transaction (if any) can be aborted (possibly with
negative INDication sent to data link user).
In such case, respond with an ACK confirm frame (DFC=x, PRM=0, DIR=x). The FCB
status (expected value of FCB in next received frame with FCV valid) should be set to 1.
A positive INDication can be sent to the data link user.
3.6.2 Reset of User Process
This function code is used to reset the data link user process. Upon reception by a
secondary station, an INDication should be sent to the data link user. The data link user
can use this indication to reset its internal state. If accepted by the data link user, an ACK
confirm frame is sent in reply otherwise a NACK confirm frame is sent in reply.
3.6.3 Test
The TEST command is used to test the state of the secondary data link. Upon reception
by a secondary station, it checks the value of the FCB bit in the primary message and
compares it against the FCB status (expected FCB) for that primary station. If the FCBs
do not match, then the secondary station should send the last secondary confirm frame.
Otherwise, an ACK confirm frame should be sent in reply and the expected FCB status
should be toggled. The secondary station also sets the DFC bit accordingly in the
response.
3.6.4 User Data
3-8
The User Data function is used to send confirmed data to a secondary station. Before
communications can begin, the secondary station must have been RESET according to
the rules above (see RESET). The frame sent contains the user data from the primary data
link user that is to be passed to the data link user of the secondary station. The
transmission procedures are described below:
3.6.4.1 Primary Transaction
Do number of configurable tries: (i.e. retries + 1)
Send User Data frame with FCV=1, PRM=1, DIR=x and FCB set to FCB status for the
secondary station (next expected FCB status).
Wait the pre-determined time-out period for a ACK or NACK frame from the secondary
station.
If frame is NACK then wait a pre-determined amount of time until secondary link is NOT
busy or use REQUEST LINK STATUS (below) and go to top of loop to retry.
If correct ACK frame is received, toggle FCB status (i.e. next frame sent to secondary
with FCV valid should have opposite FCB) and exit loop.
If correct frame is not received then go to top of loop and re-try.
If ACK was received then the transaction is considered successful and the secondary
station can be considered on-line. A positive INDication can be returned to the data link
user.
Otherwise, a negative INDication should be sent to the data link user and the secondary
station can be considered off-line or on-line depending on the data link user's
interpretation of the failure.
3.6.4.2 Secondary Transaction
Upon reception of a User Data frame with FCV=1, PRM=1, DIR=x and FCB set to FCB
status (expected FCB state) do the following:
If the data link user is ready to accept user data then respond with an ACK confirm frame
(DFC=x, PRM=0, DIR=x) else respond with a NACK frame (same bit settings as ACK)
and exit this loop.
3.6.5 Unconfirmed User Data
This function is used to send user data to the secondary station without needing
confirmation. In this way, the bandwidth of the system can be more fully utilized if the
user data is low priority. The frame sent contains the user data from the primary data link
user that is to be passed to the data link user of the secondary station. The transmission
procedures are described below:
3.6.5.1 Primary Transaction
DNP V3.00 Data Link Layer (Version 0.02)
3-9
Send Unconfirmed User Data frame with PRM=1, DIR=x, FCV=0, FCB=x.
Announce positive INDication to data link user.
3.6.5.2 Secondary Transaction
Receive Unconfirmed User Data frame as above and send positive INDications with the
data to the data link user.
3.6.6 Request Link Status
This command is used to request the status of the secondary data link. A secondary
station will respond to this request with a LINK STATUS confirm frame with the DFC
bit set to 1 if the data link is busy or the data link user cannot accept any more user data
and 0 indicating that the data link is not busy and the data link user can accept more user
data. The transmission procedures are similar to TEST except that the primary station will
typically only use this command when a NACK frame is received during a User Data
transaction.
(IND)
Positive
SEND
FCB=0
> Expected FCB=x
CONFIRM
< (IND)
Reset
Next FCB=1
Expected FCB=1
3-10
Reset User
(REQ)
(IND)
Positive
SEND
>
CONFIRM
< (IND)
Reset User
STATION B
SEND
FCB=1
>
CONFIRM
<
(IND)
Positive
Expected FCB=1
(IND)
Data
SEND
(REQ)
Expected FCB=0
FCB=0
<
CONFIRM
>
(IND) Positive
(IND) User Data
3-11
In Figure 3-11, a designated master station sends 3 consecutive frames to the same nonmaster station.
(REQ 1)
SEND
FCB=1
>
CONFIRM
(IND) Positive
<
(REQ 2)
SEND
FCB=0
>
CONFIRM
(IND) Positive
<
(REQ 3)
SEND
FCB=1
>
CONFIRM
(IND) Positive
<
Expected FCB=1
(IND) User Data
Expected FCB=0
Figure 3-11 SEND Multiple Frames From Station A/CONFIRM From Station B
In Figure 3-12, the designated master acting as primary sends a one frame message to the
secondary non-master. This example illustrates what happens when the CONFIRM from
the secondary station is lost.
SEND
FCB=1 t DAB
>
t DBA
CONFIRM
garbled
or not received
retry delay > t DAB + t DBA + t CONFIRM duration
FCB=1
>
CONFIRM
<
(IND) Positive
(REQ)
Expected FCB=1
Expected FCB = 0
send data is ignored, unexpected FCB
but another confirm is sent
3-12
SEND
Expected FCB = 0
FCB=0
>
CONFIRM
tBA
FCB=1 tAB
> (lost or garbled)
(REQ)
retry delay > tBA + tAB + CONFIRM time + CONFIRM processing time at Station B
SEND
FCB=1
Expected FCB=1
>
CONFIRM
Both a master station and non-master station acting as primary stations can
re-try SEND frames.
SEND
NO REPLY
(REQ 2)
SEND
NO REPLY
delay
(REQ 3)
SEND
NO REPLY
3-13
primary sends a second frame to the secondary. The secondary master decides that it
cannot accept any frames at this time and sends a NACK frame back. The primary, after
receiving this NACK, will fail the transaction and send a negative INDication to the data
link user.
SEND
FCB=1
<
CONFIRM
SEND
FCB=0
NACK
>
(IND) Negative
(REQ 1)
Expected FCB=1
(IND) Positive
(REQ 2)
(IND) Negative
3-14
(REQ 1)
(IND) Positive
Receipt of CONFIRM frame
with DFC = 0 is the
condition for
transmission of the next
SEND user data frame.
(IND) Positive
(REQ 3)
Receipt of CONFIRM frame
with DFC = 0 is the
condition for
transmission of the next
SEND user data frame.
SEND
FCB=0
>
CONFIRM
DFC=0
<
SEND
FCB=1
>
CONFIRM
DFC=1
<
REQUEST
RESPOND
>
CONFIRM
DFC=1
<
REQUEST
RESPOND
>
CONFIRM
DFC=0
SEND
FCB=0
>
CONFIRM
DFC=0
<
(IND)
3-15
4-1
4-2
Confirm =
0
1
2
3
4
Service =
0
1
2
3
4
Time_service 0
1
Data link indications (IND) can be requested at any time by the service user but should be
checked as often as possible in order to obtain received data.
indications = request_data_link_indications(
source_address,
destination_address,
received_data_buffer,
received_data_count,
time_of_reception)
Output:
source_address
destination_address
received_data_buffer
received_data_count
time_of_reception
4-3
Indications = 0
1
4-4
No indications to report
Data link has received a valid message that has been placed in
received_data_buffer and the number of octets received has been
placed in received_data_count. The source address of the received
message has been placed in source_address. If the data link is
configured as a master station then the time that the first bit of the
first octet of the message was received has been placed in
time_of_reception. If the data link is configured as an outstation
then the time_of_reception will still be returned but the service
user has to be aware of the possibility of inaccurate times received
before the outstation has been time-synchronized.
Data link has detected a transaction failure.
5-1
Input:
data_buffer Data to send
data_count
Number of octets to send
modem_string Command string for DCE
Output:
time_of_transmission Time that first bit of first octet of message was transmitted
Confirm =
0
1
2
3
Service =
1
2
3
4
Physical layer indications (IND) can be requested at any time by the service user but
should be checked as often as possible in order to obtain received data.
indications = indicate(received_data_buffer,
received_data_count,
time_of_reception)
Output:
received_data_buffer Received message
received_data_count Number of octets in message
time_of_reception
Time at which first bit of first octet of message was received
Indications =
0
1
2
3
4
5-2
No indications to report.
Physical layer has received a message that has been placed
in received_data_buffer and the number of octets received
has been placed in received_data_count.
DCE has connected to PSN (incoming call).
DCE has disconnected from PSN (hang up).
Physical layer has detected problems with the link or DCE
that makes communication inadvisable or impossible until
some later time. Re-initialization of the DCE may be
required.
6. PHYSICAL LAYER
CHARACTERISTICS
6.1 LINE CONFIGURATIONS
Regardless of the physical layer used, there are two physical topologies used to construct
a SCADA communications network. These are direct and serial bus topologies.
The direct topology has two physical nodes with each physical node connected directly to
the other. This is often referred to as point-to-point and can be a direct physical cable
from point-to-point, a two node radio or modem network or a dial-up connection through
a PSN (Public Switched Network).
The serial bus topology has more than two physical nodes with each node connected to
the same channel or communication line as every other node in the serial bus network.
This is often referred to as a multi-drop configuration and is commonly made up of many
Bell 202 modems with their outputs/input tied together. In this configuration, there is one
node which is deemed to be in control of the physical network. This is often the SCADA
master. This node transmits to multiple-nodes and receives from multiple nodes. All other
nodes in the bus receive from the master node and transmit to the master node.
The DNP data link supports multiple-master, multiple-slave and peer-to-peer
communications.
In peer-to-peer communications, all devices act as slave data links and collision
avoidance should be turned on as no one device has a higher priority and all can transmit
spontaneously.
In a multiple-master configuration, the master devices are higher priority than the slave
devices. However, priority has to be assigned amongst the masters.
6-1
synchronous modem. The actual mechanism used has no affect on the operation of the
data link.
6-2
7-1
indication is present, a station is transmitting on the circuit. During this time, no other
station should attempt to transmit on the circuit. When the indication disappears, the
circuit is free for someone to use. The question now is, which station is allowed to
transmit on the circuit.
In the point-to-point configuration, either the master or slave station could transmit. In the
multi-drop configuration, either the master or any of many slave stations could transmit.
The DNP data link protocol does not assign priority to either the master or slave message
but it is generally accepted in SCADA that the master should have control of the
communication circuit and therefore should transmit the message (if one is to be sent).
Any slave station, if allowed to transmit at this point, could possibly cause a collision so
the slave station must wait some time after detecting the loss of a data carrier before
attempting to send. Before sending, the indication is checked again and if the circuit is
still idle then the transmission can take place. If the circuit is busy then the station must
wait again until the indication disappears and perform the procedure again. The insertion
of the time delay after the loss of data carrier allows the master to take control of the
circuit (if needed at that time) and shuts out the other station (because the carrier
indication is caused by the masters transmission).
7.2.1 Point-to-Point
In a point-to-point configuration this time delay only needs to be as long as the time
needed for the master to detect the loss of data carrier and begin the transmission of the
message (plus any propagation delays in the system) (Master_min time).
7.2.2 Multi-Point
In a multi-drop configuration, this time delay needs to be different for each slave station.
One possibility is to configure each slave station to wait a steadily increasing amount of
time (no duplicate times and all greater than Master_Min time) hence assigning priorities
to the stations. In this way, stations which are important in the system can be given higher
priority and collisions will rarely happen (only if device timing is bad or the system is
poorly configured). However, if the high priority slave stations have nothing to transmit,
then there is a lot of time (and hence bandwidth) wasted.
Another scheme is to configure each slave station to wait a random time between
Master_Min and Max. This Max is a function of the number of slave stations in the
system. In this way, each station can be configured in the same way and the average time
wasted is about (Max - Master_Min) / 2. However, a collision is still possible if two
stations decide to wait for the same amount of time. The smaller the Max value the
greater the chance of this happening.
and transmission of messages. In this case, both the master and slave stations can transmit
data at any time when needed. The master still has control of the circuit because there is
only one station to talk to, hence no need to block out other stations.
When full-duplex procedures are used in a four-wire multi-drop system the problem of
collision avoidance increases in complexity. The reason for this lies in the fact that a
physical communication circuit that has two independent channels usually can only detect
traffic in the receive direction. In a two-wire system, any traffic in the receive or transmit
direction can be detected because they are both on the same circuit but in a four-wire
system the transmitted and received messages travel on different circuits.
7.3.1 Point-to-Point
In a point-to-point, full-duplex system both master and slave can transmit at the same
time without collision so there is no need for collision detection/avoidance or access
mechanisms in this case.
7.3.2 Multi-Point
In a full-duplex, multi-drop system, the master station can transmit messages at any time
without collision but may not receive the data link confirmation immediately because
another station (acting as a primary station) may have taken control of the master's
receive circuit before the secondary station or a collision occurred.
The slave station's messages will collide at random because there is no way for the station
to know if another station has control of the master's receive circuit. The solution is to
make use of a control circuit (RTS in the case of RS-232) to signal the slave stations
when another slave station has taken control of the master's receive circuit. This signal
must be an input to the slave stations which indicates a request to take control of the
master's receive circuit.
One simple solution is to allow slave messages to collide. In this way, the master can still
send out high priority messages but there may be a collision which will cause a secondary
station to time-out.
7.3.3 Dial-Up Modem
A dial-up modem uses a four-wire full-duplex circuit that typically requires several
control signals (other than DCD) in order to operate. The dial-up circuit is a point-topoint circuit. However, the meaning of the data carrier signal is quite different than with a
direct circuit. The data carrier (DCD) indicates that the modem is electrically connected
to another modem across the PSN. It does not necessarily mean that data is being
transmitted on the circuit. The CTS (Clear To Send) line indicates to the data link when it
is safe to transmit. The DNP data link will assert the RTS (Request To Send) line before
transmitting each frame and wait for the CTS line to go high before transmitting the data.
The RTS line will then be de-asserted. If the DCD line goes low, the data link will
assume that a connection has been lost and attempt to re-dial if needed.
7-3
DNP V3.00 Data Link Layer (Version 0.02)
7-4
DFC
DIR
DNP
EPA
FCB
FCV
IEC
IED
ISO
LPDU
LSDU
octet
OSI
PRM
primary
Version
By Whom
Nov. 08/92
Aug. 20/93
Sep 01/93
May 30/97
0.00A
0.01
0.01
0.01
M. Smith
J. Bhat
AV
S. Tessari
Pages
Affected
All
All
All
All
DNP V3.00
TRANSPORT FUNCTIONS
TRADEMARK NOTICES
Brand and product names mentioned in this document are trademarks or
registered trademarks of their respective companies.
TABLE OF CONTENTS
ABOUT THIS DOCUMENT
PURPOSE OF THIS SPECIFICATION
WHO SHOULD USE THIS SPECIFICATION
HELP AND ADDITIONAL DOCUMENTATION
HOW THIS SPECIFICATION IS ORGANIZED
CONVENTIONS USED IN THIS SPECIFICATION
iii
iii
iii
iii
iv
iv
1. OVERVIEW
1-1
2. TRANSPORT FUNCTIONS
2.1 TRANSPORT HEADER
2.2 TRANSPORT HEADER FIELD DEFINITIONS
2.3 FRAME ASSEMBLING
2.4 TRANSMISSION OF MESSAGES
2-1
2-1
2-2
2-3
2-4
3-1
3-1
3-2
TABLE OF FIGURES
FIGURE 2-1
FIGURE 2-2
FIGURE 2-3
FIGURE 2-4
FIGURE 2-5
ii
2-2
2-2
2-3
2-4
2-4
iii
iv
1. OVERVIEW
This document defines the Distributed Network Protocol (DNP) V3.00 Transport
Functions, Transport Protocol Data Unit (TPDU), as well as transport services and
transmission procedures. Master stations, submaster stations and outstations or intelligent
electronic devices (IEDs) can use these transport functions to pass messages between
primary (originating) stations and secondary (receiving) stations. In this protocol, master
stations, submaster stations and outstations are both originators (primary stations) and
receivers (secondary stations).
The ISO (International Organization for Standardization) OSI (Open System
Interconnection) model supported by this protocol specifies physical, data link and
application layers only. This is termed the Enhanced Protocol Architecture (EPA).
However, to support advanced RTU functions and messages larger than the maximum
frame length as defined by the IEC (International Electrotechnical Committee) document
870-5-1, the DNP V3.00 Data Link is intended to be used with this pseudo-transport layer
which implements message assembly and disassembly.
This pseudo-transport layer is actually a super-data link transport protocol which is
normally found as part of some OSI data links. However, because the IEC data link (DNP
V3.00 Data Link Layer) does not support these functions in the data link, it is necessary
to move them out of the data link in order to maintain compliance.
1-1
2. TRANSPORT FUNCTIONS
This section describes the Transport layer functions which act as a pseudo-transport layer
to the DNP data link layer. The pseudo-transport layer function is specific only for those
messages that are larger than one Link Protocol Data Unit (LPDU) between primary and
secondary stations. This pseudo-transport layer acts as the DNP data link user in a
protocol stack consisting of only the DNP Data Link and DNP Application Layer. This
functionality allows the pseudo-transport layer to disassemble one Transport Service Data
Unit (TSDU) into multiple (more than one) Transport Protocol Data Units (TPDUs), or
frames, and assemble multiple (more than one) TPDUs into one TSDU.
This process works as follows:
The pseudo-transport layer takes one TSDU (user data) and breaks it into several
sequenced TPDUs (each with Transport Protocol Control Information (TPCI)). Each
TPDU is sent to the data link layer as Link Service Data Unit (LSDU) for transmission.
It also works in the reverse fashion. The pseudo-transport layer receives multiple TPDUs
from the data link layer and assembles them into one TSDU.
LSDUs are user data fragments which are small enough to fit into the defined FT3 frame
format. When a primary station transmits a message to a secondary station, the transport
functions break the message into LSDUs. These functions add a Transport layer Header
(TH) octet at the beginning of the user data fragments that contain the information for the
secondary station to reconstruct the complete message. All pseudo-transport layer
messages have a TH.
The secondary station checks the TH octet on reception of each LSDU for the correct
sequence and builds a TSDU message for higher layers.
The TH contains information that can identify the first frame, last frame and give every
frame a six-bit sequence number. This information is required to reconstruct a message
and also to guard against higher layers from receiving misdirected or incomplete
messages.
2-1
----------------|
|
|
| TH | USER DATA |
|
|
|
-----------------
+ 255
-5
-1
= 249
octets
octets
octet
octets
BIT
----------------------------------------------|
|
|
|
|
|
|
|
|
| FIN | FIR |
|
| SEQUENCE |
|
|
|
|
|
|
|
|
|
|
|
----------------------------------------------7
6
5
4
3
2
1
0
The final bit indicates that this frame of user data is the last frame of a
sequence which compromises a complete user message.
FIN = 0
More frames follow.
1
Final frame of a sequence.
FIR
The first bit indicates that the frame is the first in a sequence of frame(s)
which comprise a complete message. When a secondary station receives a
frame with the FIR bit set, all previously received unterminated frame
sequences are discarded. The first frame of a sequence may have any
sequence from 0 to 63.
If a frame is received without the FIR bit set and no message sequence is
currently in progress, then the frame is ignored.
If a complete user message is only one frame in length, both the FIR and
FIN bits are set.
FIR = 1
First frame of a sequence.
0
Not the first frame of a sequence.
2-2
SEQUENCE The sequence number of the frame is used to check that each frame is
being received in sequence. It guards against missing or duplicated frames.
All user messages start off with a sequence specified in the first frame
which has the FIR bit set (each message may start with any sequence
number between 0 and 63). After sequence number 63 the next sequence
number will be 0.
The sequence number increments for each frame sent to or received from
the same address belonging to the same message and resets at the
beginning of a new message. The sequence number does not have to
increment across message boundaries, i.e. any sequence number is valid
when the FIR bit is set.
-------------| 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
------------- ----------->
2-3
|
|
|
--------------USER DATA
|
|
30 octets
|
---------------
|
|
|
-------------USER DATA
|
|
598 octets |
--------------
2-4
3-1
request_transport_service(
SERVICE,
TIME_SERVICE,
destination,
source,
send_data_buffer,
send_count,
retry_flag,
time_of_transmission)
Input:
SERVICE
TIME_SERVICE
source
destination
send_data_buffer
send_count
retry_flag
time_of_transmission
Service to perform.
Guaranteed time service to perform.
Source address to use in sent message.
Destination address to use in sent message.
Data to send in message.
Number of octets in message.
Instructs data link layer to retry unacknowledged frames or not.
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
1
2
3
4
3-2
service =
0
1
2
3
4
time_service =0
1
Data link indications (IND) can be requested at any time by the service user but should be
checked as often as possible in order to obtain received data.
indications = request_data_link_indications(
source_address,
destination_address,
received_data_buffer,
received_data_count,
time_of_reception)
Output:
source_address
destination_address
received_data_buffer
received_data_count
time_of_reception
3-3
Indications = 0
1
3-4
No indications to report.
Data link has received a valid message that has been placed in
received_data_buffer and the number of octets received has been
placed in received_data_count. The source address of the received
message has been placed in source_address. If the data link is
configured as a master station then the time that the first bit of the
first octet of the message was received has been placed in
time_of_reception. If the data link is configured as an outstation
then the time_of_reception will still be returned but the service
user has to be aware of the possibility of inaccurate times received
before the outstation has been time-synchronized.
Pseudo-transport layer has detected a transaction failure.
DNP
EPA
IEC
ISO
octet
OSI
RTU
Version
By Whom:
NFM
Pages
Affected:
All
Nov. 11/91
Nov. 18/91
Jan. 13/92
Apr. 30/92
Jul. 24/92
0.00B
0.00C
0.01A
0.01B
0.01C
J. McFadyen
J. McFadyen
J. McFadyen
NFM
MCH
Section 3
All
3-11
Sep. 8/92
0.02A
M. Smith
ALL
Oct. 22/92
0.02B
M.Smith
Timesync
Oct. 27/92
0.02C
M.Smith
Section 3
Nov.8/92
0.02D
MS
Nov.25/92
July 7/93
Jul.21/93
Aug.20/93
Aug.30/93
Sept.01/93
0.03
0.03
0.03
0.03
0.03
0.03
LA
P. Morton
J. Bhat
J. Bhat
J. Bhat
AV
Sections
3, 4
All
All
All
All
All
All
Date
Version
By Whom:
May 28/97
0.03
S. Tessari
Pages
Affected:
All
DNP V3.00
APPLICATION LAYER
TRADEMARK NOTICES
Brand and product names mentioned in this document are trademarks or
registered trademarks of their respective companies.
TABLE OF CONTENTS
ABOUT THIS DOCUMENT
PURPOSE OF THIS SPECIFICATION
WHO SHOULD USE THIS SPECIFICATION
HELP AND ADDITIONAL DOCUMENTATION
HOW THIS SPECIFICATION IS ORGANIZED
CONVENTIONS USED IN THIS SPECIFICATION
ix
ix
ix
ix
x
x
1. OVERVIEW
1.1 DESCRIPTION AND IEC RELATIONSHIP
1-1
1-2
2. MESSAGE FORMATS
2.1 APPLICATION REQUEST FORMAT
2.2 APPLICATION RESPONSE FORMAT
2-1
2-2
2-2
3-1
3-1
3-3
3-8
3-11
3-12
3-14
3-16
5-1
6. TIME SYNCHRONIZATION
6-1
7-1
8. FILE TRANSFER
8.1 FILE IDENTIFIER OBJECTS PERFORMING WRITE FUNCTIONS
8.2 FILE IDENTIFIER OBJECT PERFORMING READ FUNCTIONS
8-1
8-1
8-5
vi
TABLE OF FIGURES
FIGURE 1-1 CONTEXT OF EPA
1-2
FIGURE 2-1 MESSAGE SEQUENCE
2-1
FIGURE 2-2 APPLICATION REQUEST FORMAT
2-2
FIGURE 2-3 APPLICATION RESPONSE FORMAT
2-3
FIGURE 3-1 REQUEST HEADER
3-1
FIGURE 3-2 RESPONSE HEADER
3-1
FIGURE 3-3 APPLICATION CONTROL FIELD
3-2
FIGURE 3-4 TYPICAL MESSAGE TRANSACTION FLOW
3-4
FIGURE 3-5 MULTI-FRAGMENT RESPONSE & RTU CONFIRMATION
TIMEOUT
3-5
FIGURE 3-6 MESSAGE TRANSACTIONS WITH RESPONSE TIMEOUTS
3-6
FIGURE 3-7 MESSAGE FLOW WHEN RESPONSE DELAYED ON A
NETWORK
3-7
FIGURE 3-8 RESENDING UNSOLICITED RESPONSES DUE TO NETWORK
DELAYS
3-7
FIGURE 3-9 SIMULTANEOUS TRANSMISSIONS, IMMEDIATE_PROCESS
MODE
3-9
FIGURE 3-10 SIMULTANEOUS TRANSMISSIONS, IMMEDIATE_PROCESS
MODE
3-10
FIGURE 3-11 SIMULTANEOUS TRANSMISSIONS, PROCESS_AFTER_CONFIRM
MODE
3-11
FIGURE 3-12 OBJECT HEADER
3-16
FIGURE 3-13 OBJECT FIELD
3-17
FIGURE 3-14 QUALIFIER FIELD
3-18
FIGURE 3-15 MESSAGES WITHOUT DATA OBJECTS
3-23
FIGURE 3-16 MESSAGES WITH DATA OBJECTS
3-26
FIGURE 4-1 CONFIRMATION MESSAGE
4-1
FIGURE 4-2 SINGLE OBJECT REQUEST
4-3
FIGURE 4-3 MULTIPLE OBJECTS OR RANGES
4-3
FIGURE 4-4 SINGLE OBJECT RANGE WRITE
4-15
FIGURE 4-5 MULTIPLE OBJECT OR MULTIPLE RANGES
4-15
FIGURE 4-6 MASTER SELECTION OF TWO CONTROL OR ANALOG
OUTPUTS
4-17
FIGURE 4-7 OUTSTATION RESPONSE
4-17
FIGURE 4-8 MASTER SELECTION OF A PATTERN OUTPUT
4-17
FIGURE 4-9 OUTSTATION RESPONSE TO THE PATTERN SELECT
MESSAGE
4-18
DNP V3.00 Application Layer (Version 0.03)
vii
viii
ix
1. OVERVIEW
This document defines the Harris Distributed Network Protocol (DNP) application layer
APDU format and services.
The ISO OSI (International Standards Organization Open System Interconnection) model
specifies seven layers. The International Electrotechnical Commission (IEC) specifies a
simplified model consisting of the physical, data link and application layers only. This is
termed the Enhanced Performance Architecture (EPA). This document defines the third
layer of this EPA or the Application Layer. The data link layer is defined in:
Distributed Network Protocol Version 3.00: Data Link Layer (P009-0PD.DL).
Harris Canada Inc. has developed the DNP for application in both SCADA and
distributed automation (DA) systems. Primary focus has been on the current and future
needs of these areas. The DNP is suitable for use in highly secure, moderate speed and
moderate throughput applications. The protocol is highly flexible and open-ended
without any target hardware specific constructs.
Figure 1-1 on the following page shows the EPA structure and how it fits into the entire
communication system. As shown, the User Layer interfaces to the Application Layer in
one place only implying that the user has no need to know of the other elements of the
communication system except the Application Layer interface. The User Layer makes
use of the Application Layer to send/receive complete SCADA/DA messages to/from a
master station or outstation.
1-1
User Layer
Application Layer
Data Link Layer
Physical Layer
Communication Medium
1-2
2. MESSAGE FORMATS
This section defines the formats of the application layer messages (APDU). The terms
APDU and fragment are interchangeable. In this specification the master station is
defined as the station sending a request message and the Outstation is the slave device,
Remote Terminal Unit (RTU) or Intelligent End Device (IED) to which the requested
messages is destined. In DNP, only designated master stations can send Application
Layer request messages and only Outstations can send Application Layer Response
messages.
Figure 2-1 below shows the sequence of Application Layer messages between one master
and one Outstation.
Master
Outstation
Send Request
-------------------->
<--------------------
Accept response
<-----------------
Optional confirmation
--------------------------------->
Important change detected
Accept response
<-----------------
Optional confirmation
--------------------------------->
2-1
the function code is part of every fragment). It is advised that devices with limited
message storage capabilities should only be sent single fragment message requests when
the expected response (from all fragments sent) is larger than one fragment. This is to
ensure that devices can process a request and build and more importantly send a response
before the next request is received. Otherwise, multi-fragment messages may require
multi-fragment responses which may require more message storage than the device has
available.
DUI
IO .. IO
DUI
IO
....
Request Header Object Header data
Object Header data
.....
APCI
ASDU
the same format of the request message with one notable exception (explained in Section
3).
DUI
IO .. IO
DUI
IO
....
Response Header Object Header data
Object Header data
....
APCI
ASDU
2-3
2-4
AC
FC
AC
FC
IIN
3-1
Application messages may be packaged into fragments, with each fragment small enough
to fit into the application's message buffer. The recommended size of the fragment buffer
is 2048 bytes in order to maintain compatibility with current DNP devices. Each fragment
has an application header and appropriate object headers so that each fragment can be
processed as individual messages which can then be discarded making room for the next
fragment.
7
6
5
4
3
2
1
0 bit
SEQUENCE
If set to one (1), this bit indicates the message fragment is the first fragment of a
complete application message.
FIN
If set to one (1), this bit indicates the message fragment is the final fragment of a
complete application message.
CON If set to one (1) in a received message, indicates the sending application is
expecting a confirmation from the receiving application of the reception of the
fragment. An application function code zero (0) is used in the confirmation
message.
SEQUENCE Indicates the fragment number. Fragment numbers 0 to 15 are reserved for
master station requests and all Outstation responses (NOT Unsolicited
Responses). Fragment numbers 16 to 31 are reserved for unsolicited
responses from Outstations. For unsolicited responses, each consecutive
fragment from an Outstation must have an increasing sequence number
(the number overflows from 31 to 16). For requests to an Outstation and
the Outstation responses (not unsolicited responses), each consecutive
fragment received from or transmitted to the same Outstation must have an
increasing sequence number (the number overflows from 15 to 0).
NOTE:
NOTE:
3-2
5)
3-3
The use of this sequence number scheme ensures the Outstation and master station can
cope with all occurrences of messages being lost or delayed on a communication network.
The following rules are obeyed by both the Outstation and master station:
If the system uses application level retries, when a response is not received before
time-out, the request will be re-transmitted with the same sequence number.
If two messages are received with the same sequence number, it usually means that the
response to the message was not received by the other station. In this case, retransmit
the response (re-processing the message is unnecessary).
If two CONFIRMation responses are received with the same sequence number, ignore
the second response.
The following figures illustrate some cases of message transactions and how the
Sequence Numbers prevent problems. In the examples, SEQ is the Sequence Number
and CON is the Confirmation Requested bit in the message. Time progresses from left to
right in the diagrams. The vertical arrows represent the flow of messages between the
Outstation and the master station.
Case One illustrates typical message transactions. The master sends a request, the
Outstation responds and the master CONFIRMs the response. Later on, the Outstation
sends an Unsolicited Response to the master station. When the Outstation transmits the
response, it starts a CONFIRMation response timer. If this timer had expired before the
CONFIRMation was received, the Outstation would have re-transmitted the response.
Case Two shows a similar situation to Case One except the master request requires a
CONFIRMation 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)
NOTE:
In Figure 3-4 and some of the following figures, the CON bit is set in the
Outstation 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 due
to communication loss is often not critical. The Outstation assumes that
the response was successful.
Case Three illustrates a multi-fragment response from the Outstation. The sequence
number in successive fragments is incremented. Note that the next request from the
master station used sequence number equals 4.
In Case Four, the response from the Outstation is not received by the master station. The
Outstation waits for a CONFIRMation, and when its CONFIRMation time-out expires it
re-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.
3-5
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)
3-6
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)
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)
3-7
3-8
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)
3-9
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.
3-10
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)
3-11
FUNCTION
DESCRIPTION
Confirm
Read
Write
Select
Operate
Direct Operate
Direct Operate
- No
Acknowledgment
Immediate Freeze
Immediate Freeze
-No Acknowledgment
3-12
CODE
FUNCTION
DESCRIPTION
10
11
12
Cold Restart
14
Warm Restart
15
Initialize Data to
Defaults
16
Initialize Application
17
Start Application
18
Stop Application
Save Configuration
Save the specified configuration to nonvolatile memory; respond with a time object
indicating time till Outstation availability.
20
Enable Unsolicited
Messages
21
Disable Unsolicited
Messages
22
Assign Class
Delay Measurement
3-13
CODE
FUNCTION
DESCRIPTION
Reserved
24 - 120
121 - 128
Confirm
129
Response
130
Unsolicited Message
First Octet
Second Octet
First Octet
7 6 5 4 3 2 1 0 Bit number
Bit 1
Bit 2
3-14
Bit 3
Bit 4
Bit 5
Bit 6
Bit 7: -
Set when data that has been configured as Class 2 data is ready to be sent
to the master
Master station should request this class data from the Outstation when this
bit is set in a response
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
Time-synchronization required from the master. The master synchronizes
the time by writing the Time and Date object to the Outstation.
Cleared when the time is set by the master. This bit is also cleared when
the master explicitly writes a 0 into this bit of the Internal Indication object
of the Outstation.
Set when some or all of the Outstation's digital output points are in the
Local state. That is, the Outstation's control outputs are NOT accessible
through the DNP protocol.
Clear when the Outstation is in the Remote state. That is, the Outstation's
control outputs are accessible through the DNP protocol.
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.
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
Bit 1
Requested object(s) unknown. The Outstation does not have the specified
objects or there are no objects assigned to the requested class.
This indication should be used for debugging purposes and usually
indicates a mismatch in device profiles or configuration problems.
3-15
Bit 2
Bit 3
Parameters in the qualifier, range or data fields are not valid or out of
range. This is a catch-all for application request formatting errors.
This indication should be used for debugging purposes and usually
indicates configuration problems.
Bit 4
Bit 5
Bit 6
Bit 7
Specifies the object group and variation of the objects that follow the
header as described in section 3. OBJECT. This is a two-octet field. The
object field uniquely identifies the type or class of object which gives the
structure (and hence size) of the data object.
Qualifier
3-16
Range
NOTE:
The range field may not be present if the qualifier specifies that there is no
range field. The size of this field ranges from zero (0) octets to eight
octets.
0 or Object variation
Object Group
Object variation
3-17
R
Index Size
4 bit Qualifier Code
The Range Field is used to index data or as an identifier. The structure and use of the
Range Field is dependent on the value in the Index Size field and the Qualifier Code field.
When the Range Field is used to index data, it often consists of a Start Range value and
an Stop Range value. Together they define a range of objects in the data following the
Object Header. Each of the Start Range and Stop Range sub-fields is termed as index.
Index Size (3-bits)
In a Request Object Header when Qualifier Code equals 11
The Index Size bits are valid only when the qualifier code is 11. These bits
indicate the size, in octets, of each entry in the Range Field. The Range Field
follows the Qualifier Field. The Range Field consists of indices (to specify a
range of objects) or object identifier lists (see qualifier code 11).
0=
1=
2=
3=
4=
5=
6=
7=
5=
6=
7=
3-19
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 are used to indicate that the Range Field consists of a
single count indicating the number of data objects in question. The Range Field
that follows designates the number of objects referenced.
If the Index Size field equals zero, the Range Field specifies the number of objects
referenced starting numerically from 0 (including 0) to the value in the Range
Field minus 1.
If the Index Size is 1, 2 or 3 then the Range Field specifies the number of indices
and objects following the Range Field.
Qualifier Codes 7, 8 and 9 can be used in the request and response messages. In a
message with or without data objects, the value in the Range Field specifies the
number of data objects to be referred to. The Index Size field should be set to the
size of the indices that either pre-fix each data object (for messages with data
objects) or that form a sequential list of identifiers.
The Index Size field should not indicate an object size identifier as this would not
uniquely specify the data objects in question and should be set to 0 if no
identifiers or indices are following. The order of identifiers (and optional data
objects) is arbitrary but should not consist of duplicate indices.
Some Qualifier Code definitions are:
7=
8=
9=
The Range Field is always a 1 octet value (Count) which specifies the number of
object identifiers. Following the Range Field are Count object size field/object
identifier pairs. The size of the identifier (in octets) is determined by the object
size field which prefixes each identifier. The size of the object size field is
determined by the Index size. Index sizes 4,5, and 6 should be used to specify the
size of the object size field in octets.
Reserved Qualifier Codes
The following Qualifier Code values are reserved and should not be used:
10 =
12 =
13 =
14 =
15 =
reserved
reserved
reserved
reserved
reserved
3.7.3 Range
The meaning of the Range Field is specified by the Qualifier Field. For Qualifier Codes 0
to 5 the Range field has 2 sub-fields specifying a start and stop index or address. The
values in these fields are inclusive. The Range field is not present for qualifier code 6.
The range field is a single field specifying a quantity for qualifier codes 7, 8, 9 and 11. In
the following, the term 'Q-code' refers to the 4 bit Qualifier Code field and 'I-size' refers
to the Index Size field.
The following figure defines all the valid qualifier/range/index combinations for a request
or response which do NOT contain any IO or data objects and simply specifies the objects
in question. The bytes described appear after the qualifier octet of the object header and
before 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
8 bit 8 bit
I1
I2
LSB
MSB
LSB
MSB
16 bit Start
16 bit Stop
I1
I2
3-21
LSB
MSB
LSB
MSB
32 bit Start
32 bit Stop
I1
I2
Quantity
8 bit
Quantity Index
Index
8 bit
I1
LSB
.......
IQ
LSB
Quantity
Index
8 bit
I1
LSB MSB
Index
Q-code 7; I-size MUST be 2
LSB MSB
Quantity
Index
8 bit
I1
LSB
MSB
LSB
MSB
16 bit Quantity
.......
Index
IQ
LSB MSB
LSB
MSB
|
LSB ......
Q
I1
Index
LSB
IQ
LSB
MSB
16 bit Quantity
Index
Index
I1
IQ
LSB
MSB
16 bit Quantity
Index
Index
I1
IQ
3-22
LSB
MSB
32 bit Quantity
IQ
LSB
MSB
32 bit Quantity
Index
Index
|
|
|
LSB
.... LSB
I1
IQ
LSB
MSB
32 bit Quantity
Index
Index
|
|
|
LSB | MSB .... LSB | MSB
I1
IQ
LSB
MSB
32 bit Quantity
Index
Index
|
|
|
LSB | | | MSB .... LSB | | | MSB
I1
IQ
Use qualifier 11 when describing points that need to be uniquely identified by an object identifier such as a
File Object Identifier or Configuration Header. The type of identifier is implied by the object type:
8-bit 8-bit
8-bit
Q
Size N1
Size NQ
16-bit
16-bit
Q
Size N
As for the previous case, there could be many identifiers each one following the other.
32-bit
32-bit
Size N
As for the previous case, there could be many identifiers each one following the other.
3-23
The following figure defines all the valid qualifier/range/index combinations for a request
or response which contain IO or data objects and specifies that the objects in question
either follow the qualifier/range fields (for qualifier without pre-fixing indices) or follow
each individual identifying index. The bytes described appear after the qualifier octet of
the 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
8 bit 8 bit
I1
I2
DO
I2
LSB
MSB
LSB
MSB
16 bit Start
16 bit Stop
DO
I1
.... I2
I1
I2
LSB
MSB
LSB
MSB
32 bit Start
32 bit Stop
DO
DO
|
|
|
|
|
|
I1 .... I2
I1
I2
Start Stop
Object DO-I1
8 bit 8 bit Size
with
I1
I2
S1
S1
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
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
3-24
Quantity DO
8 bit
I0 ....
DO
Q-code 7; I-size MUST be 0
Quantity Index DO
Index DO
8 bit
I1
I1 ..
IQ
IQ
LSB
LSB
Quantity
Index
DO
Index
DO
8 bit
inclusive
I1
I1 ....
IQ
IQ
LSB | MSB
LSB | MSB
Quantity
Index
DO
Index
DO
3
8 bit
I1
I1 .....
IQ
I1
LSB |
| | MSB
LSB | | | MSB
LSB
MSB
16 bit Quantity DO
...
|
I0
DO
I(Q-1)
LSB
MSB
|
LSB
I1
Q
I1
Index DO
LSB
IQ
IQ
LSB
MSB
16 bit Quantity
Index DO
Index
DO
|
LSB | MSB
...... LSB | MSB
inclusive
I1
IQ
I1
IQ
LSB
MSB
16 bit Quantity
Index
DO
Index
DO
3
|
LSB | | | MSB
..... LSB | | | MSB
.. IQ
I1
IQ
I1
IQ
LSB
MSB
32 bit Quantity
DO
|
|
|
....
IQ
I1
DO
IQ
LSB
MSB
32 bit Quantity
Index DO
Index DO
1
|
|
|
LSB
.... LSB
I1
I1
I2
I2
3-25
LSB
MSB
32 bit Quantity
Index
DO
Index
2
|
|
|
LSB | MSB
... LSB | MSB
I1
I1
I2
LSB
MSB
32 bit Quantity
Index
Index
MUST be 3
|
|
|
LSB | | | MSB .... LSB | | | MSB
.. IQ
I1
I2
Q-code 9; I-size
Points are I1, I2
Use qualifier 11 when describing points that need to be uniquely identified by an object identifier
such as a File Object Identifier or Configuration Header. The type of identifier is implied by the
object type:
8-bit 8-bit
DO
8-bit
DO
Q
Size N1
ID1
Size NQ
IDQ
16-bit
16-bit
DO
LSB | MSB LSB | MSB O1 O2 .... ON
Q
Size N
ID1
As for the previous case, there could be many identifiers each one following the other.
32-bit
32-bit
DO
LSB | | | MSB LSB | | | MSB O1 O2 .... ON
Size N
ID1
As for the previous case, there could be many identifiers each one following the other.
3-26
Application Control
Function
FIR = 1, FIN = 1, CON = ? Code = 0
Request Header
CON = 0
4-1
Response Header
ASDU of first fragment of the response
FIR = 1, FIN = 0
CON = 1
Request Header
Function
FIR = 1, FIN = 1, CON = 0 Code = 0
Response Header
ASDU of second fragment
FIR = 0, FIN = 0
of response
CON = 1
Request Header
Function
FIR = 1, FIN = 1, CON = 0 Code = 0
Response Header
CON = 1
Request Header
Function
FIR = 1, FIN = 1, CON = 0 Code = 0
The number of multiple requests allowed in a single message is defined in the device
profile of each device DNP is implemented on.
The read request for a single range of objects is illustrated in Figure 4-2. Figure 4-3
illustrates the request for 2 object types or possibly 2 ranges of the same object type.
AC | FC = 1
Object gv
Qualifier
AC FC = 1 g = n
v = 0 0000 0110
0
6
Object gv
Qualifier
Range
AC FC = 1 g = n
v = x 0000 | 0000 Start
Stop
0
0
7
|
9
4-3
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
object gv
Qualifier
Range
AC FC = 1 g = n
v = x 0000 0001
Start
Stop
0
1
700
702
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
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
Read object group n, variation x. In this case n and x would specify a generic octet
object
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:
4-4
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 octet
object.
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
requesting specific bytes from the memory of some remote application.
NOTE:
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 octet
object.
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
requesting specific bytes from the memory of some remote application.
NOTE:
octet 1
2
3
4
5
6
Object gv
Qualifier Range
AC FC = 1 g = n
v = p 0000 0111 Quantity
0
7
4-5
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 entire
data 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
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
|
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
4-6
NOTE:
The range field is always the same size as an entry in the index list. This
format would normally be used when the indices have values between 0
and 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
NOTE:
The range field is always the same size as an entry in the index list. This
format would normally be used when some or all of the indices have
values 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
70000
76000
90000
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 the
object identifier).
4-7
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 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.
This method is useful for reading configurations from a remote device (if the File
Object Identifier is used). This method is however the only way in which to request a
data 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 a
response to a read request.
octet 1
2
3
4
5
Object gv
Qualifier
Range
group = n
0000 0000 Start
Stop
variation = v
0
0
....
.....
group = n
0000 0001 Start
Stop
variation = v
0
1
300
302
....
group = n
0000 0010
Start
Stop
variation = v
0
2
70000
70002
....
The range field specifies 3 objects starting at index 70000 to index 70002 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
.....
Object gv
Qualifier
Range
group = n
0000 0011 Start
Stop
variation = v
0
3
.....
group = n
0000 0100 Start
Stop
variation = v
0
4
300
302
....
group = n
0000 0101
Start
Stop
variation = v
0
5
70000
70002
....
4-9
octet 1
2
3
4
....
Object gv
Qualifier Range
group = n
0000 0111
3
variation = v
0
7
....
octet 1
2
3
4
....
Object gv
Qualifier Range
group = n
0001 0111
3
variation = v
1
7
....
octet 1
2
3
4
....
Object gv
Qualifier Range
group = n
0010 0111
3
variation = v
2
7
....
octet 1
2
3
4
....
Object gv
Qualifier Range
group = n
0011 0111
3
variation = v
3
7
....
4-10
octet 1
2
3
4
....
Object gv
Qualifier
Range
group = n
0100 0111
Quantity
variation = v
4
7
....
octet 1
2
3
4
5
....
Object gv
Qualifier Range
group = n
0000 1000
3
variation = v
0
8
....
variation = v
1
8
....
octet 1
2
3
4
5
....
Object gv
Qualifier Range
group = n
0010 1000
300
variation = v
2
8
....
4-11
The index size specifies the objects are prefixed with a 2 octet index identifier.
octet 1
2
3
4
5
....
Object gv
Qualifier Range
group = n
0011 1000
300
variation = v
3
8
....
octet 1
2
3
4
5
....
Object gv
Qualifier
Range
group = n
0101 1000
Quantity
variation = v
5
8
....
octet 1
2
3
4 5 6 7
....
Object gv
Qualifier Range
group = n
0000 1001
3
variation = v
0
9
....
octet 1
2
3
4 5 6 7
....
Object gv
Qualifier Range
group = n
0001 1001
3
variation = v
1
9
....
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
0010 1001
3
variation = v
2
9
....
octet 1
2
3
4 5 6 7
....
Object gv
Qualifier Range
group = n
0010 1001
3
variation = v
3
9
....
octet 1
2
3
4
5
6
7
....
Object gv
Qualifier
Range
group = n
0100 1001
Quantity
variation = v
4
9
....
4-13
The read response can also consist of a multi-fragment message with each object
identifier 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
Fragment #2: FC=129, CON=? FIR=0 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 2 piece 2
Size octets
Fragment #3: FC=129, CON=? FIR=0 FIN=1
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 3 piece 3
Size octets
Read object group n variation v (in this case the group and variation identify the object
identifier).
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 following the identifier 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.
This method is useful for reading configurations from a remote device (if the File
Identifier Object is used). This method is however the only way in which to request a
data object that is larger than one fragment in size.
Note that each fragment is digestible by the requesting station because each object
identifier specifies a unique portion of the object.
4-14
...........
Object Header
AC FC = 2
...........
Object Header
Object Header
AC FC = 2
Object(s)
Objects(s)
......... .........
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
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=0
1
11
1
Size Object Identifier for piece 2 piece 2
Size octets
octet 1
2
3
4
5
6
7 .....
AC
Object gv
Qualifier
Range
Identifier
Data
FIN=1 FC = 2 g = n
v = v 0001 1011 Quantity
for
FIR=0
1
11
1
Size Object Identifier for piece 3 piece 3
Size octets
Write object group n variation v (in this case the group and variation identify the
object identifier).
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 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 V3.00 Application Layer (Version 0.03)
4-15
application layer. This method is however the only way in which to send a data object
that 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 the
Object 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) that
indicates the success of the Write operation and so there is no ASDU portion of a Write
response. The response always uses the Response function code.
4-16
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
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
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 5object 6object 7object 8
4-17
The above message constitutes one pattern control request. Multiple requests (Pattern
Control Block followed by multiple Pattern Mask Objects) can be sent in one message
as 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 5object 6object 7object 8
Object gv
Qualifier
Range
control control
AC FC = 4 group = n
0000 0111
Quantity block 1 block 2
variation = v
0
7
Object gv
Qualifier Range
control control
AC FC IIN group = n
0000 0111 Quantity block 1 block 2
variation = v
0
7
Pattern Mask object, the status is part of the Pattern Control Block object preceding
the mask.
Object gv
Qualifier
Range
control control
AC FC = 5 group = n
0000 0111
Quantity block 1 block 2
variation = v
0
7
2
Object gv
Qualifier Range
control control
AC FC IIN group = n
0000 0111 Quantity block 1 block 2
variation = v
0
7
Object gv
Qualifier
Range
control control
AC FC = 6 group = n
0000 0111
Quantity block 1 block 2
variation = v
0
7
4-19
Object Header
Object Header
AC FC = 7
...
AC FC
IIN
Object Header
Object Header
AC FC = 8
...
Typically, this function code is used to freeze counters or accumulators and then reset
them to 0.
Object Header
Object Header
AC FC = 9
...
AC FC
IIN
Object Header
Object Header
AC FC= 10
...
INTERVAL
zero
zero
non zero
non zero
non zero
DESCRIPTION
Freeze once at specified time.
Freeze Immediately.
Freezing is synchronized to the
beginning of the current hour. The first
freeze will occur at the smallest
multiple greater than or equal to the
current time. Subsequent freezes will
occur at each interval increment.
Start freezing at the specified time and
repeat at each interval increment
thereafter
4-21
Object Header
Time Object
Object Header(s)
AC FC = 11 for time object Time and Date Interval for data objects
to freeze
AC FC
IIN
Object Header
Time Object
Object Header(s)
AC FC = 12 for time object Time and Date Interval for data objects
to freeze
AC FC = 13
4-22
AC FC
IIN
Header
Object
for time
AC FC = 14
Header
Object
for time
4-23
This function code specifies that configurable data is to be set to the initial or default
settings. For example, this function could be used to clear counters. Note that the initial
settings are NOT contained in the request.
Object Header
to initialize
AC FC
IIN
Object gv
Qualifier
Range
Application Application
AC FC = 16 Group = n
0001 1011
Quantity Identifier Object
Variation = v
1
11
1
Size
Identifier
AC FC
IIN
4-24
Object gv
Qualifier
Range
Application Application
AC FC = 17 Group = n
0001 1011
Quantity Identifier Object
Variation = v
1
11
1
Size
Identifier
Header
Object
for time
Object gv
Qualifier
Range
Application Application
AC FC = 18 Group = n
0001 1011
Quantity Identifier Object
Variation = v
1
11
1
Size
Identifier
4-25
AC FC
IIN
Object gv
Qualifier
Range
File
File
AC FC = 19 Group = n
0001 1011
Quantity Identifier
Identifier
Variation = v
1
11
1
Object Size Object
Object
Time
AC FC
IIN
Header
Object
Object Header(s)
AC FC= 20
AC FC
IIN
Object Header
AC FC = 21
AC FC
IIN
4-27
..
Header 1
Header n
..
AC FC IIN
AC FC = 23
4-28
4-29
4-30
5. CLASSES
Objects may be assigned to a class. There are four Classes of data. Class 0 is reserved for
static data objects (static data reflects the current value of data in the Outstation). Classes
1, 2 and 3 are reserved for event data objects (objects created as the result of data changes
in the Outstation or some other stimulant). Each event object can be assigned to Class 1,
2 or 3. Objects may be grouped in Classes by priority (the priority is determined by the
user) and the data classes polled at varying rates.
The ability to assign data to Classes and the degree of configurability is described in the
Outstation's device profile. It is not required that an Outstation have data assigned to
Classes 1, 2 or 3.
Class data is used by a master station to request pre-assigned data objects on a demand or
availability basis from an Outstation. Therefore, a class data object header can be used
only in a request (with no associate data object) to indicate to the Outstation which data
objects to return. The Outstation will return (in the response) object headers for the
ACTUAL data objects and NOT the class object header.
5-1
5-2
6. TIME SYNCHRONIZATION
Time synchronization is handled by the application layer BUT has to make use of special
services of the data link layer. The application must initiate the time synchronization
sequence by sending the appropriate request or response.
To synchronize Master station and Outstation time, the following procedure is used.
1. The Master station sends a Delay Measurement request to the Outstation. The master
records the time of transmission of the first bit of the first byte of the request
(MasterSendTime).
2. The Outstation receives the first bit of the first byte of the Delay Measurement
request at time RtuReceiveTime (this is a local time in the Outstation).
3. The Outstation transmits the first bit of the first byte of the response to the Delay
Measurement request at time RtuSendTime. The response contains the Time Delay
object (Time Delay Fine or Time Delay Course), with the time in this object equal to
RtuTurnAround, where
RtuTurnAround = RtuSendTime - RtuReceiveTime
4. The Master station receives the first bit of the first byte of the Outstation's response at
time MasterReceiveTime.
5. The master station can now calculate the one way propagation delay as
Delay =
6. The master now transmits the first bit of the first byte of a Write request at time
MasterSend. The Write request contains the Time and Date object, with the time in
the object representing a time equal to (MasterSend + Delay). This is the time that the
Master station wants the Outstation to be set to.
7. The Outstation receives the first bit of the first byte of the Write request at time
RtuReceive.
6-1
8. The Outstation will process the Write request, setting the Outstation clock to time
NewRtuTime. The following algorithm is used:
Adjustment = CurrentRtuTime - RtuReceive
NewRtuTime = (time in the Time and Date object) + Adjustment
If desired, the master station may send a global request (using the reserved destination
address of FFFF hexadecimal) to simultaneously synchronize all Outstations, only if all
path delays are equal.
6-2
7-1
7-2
8. FILE TRANSFER
The File Identifier Object (FIO) may be used to transfer data files between
Outstations and master stations. This is commonly used to write configurations
from a master to an Outstation or read configurations from an Outstation to a
master.
The functionality of the File Identifier Object allows configuration information to
be routed to Outstations via intermediate Data Concentrators. A data
concentrator is located between a master station and an Outstation - it is
effectively an Outstation to the master station and a master station to the
Outstation. Note that a Data Concentrator is not just a communication node - it
does 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 the
WRITE function code. The action to be done (reading, writing or otherwise) is
specified by the File_Function field within the object. The response always uses
the RESPONSE function code. However, an outstation can send an unsolicited
message 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, through
any number of intermediate Data Concentrators, to the Outstation.
The interpretation of the File_Name field is dependent on the Data Concentrator
through which the object is being routed.
8-1
The response to the request uses the RESPONSE Function Code. It contains the
File Identifier Object, which contains the status of the operation requested in the
File_Function field, with no data records. If the Outstation Application receives a
response from the Master Application, this response contains a File Identifier
Object. The Outstation Application does not need to change this response. If the
Outstation Application receives a negative acknowledgement from the Master
Application, it will modify and set the following fields in the response File
Identifier Object:
START_RECORD = END_RECORD = 0
FILE_SIZE = 0
FILE_FUNCTION = RESPONSE
PERMISSION = 0
Master Application was unable to pass the File Identifier
STATUS = 2
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 containing
configurations can be downloaded to an Outstation via any number of
intermediate data concentrators.
Figure 8-1 is a simplistic example illustrating how the File Identifier Object is
passed through the system from a master station to an Outstation via two data
concentrators.
8-3
FILE_NAME = /DNPDCA03/DNPDCA10/config1
--------------------------------
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
FILE_NAME = /DNPDCA10/config1
--------------------------------
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
FILE_NAME = /config1
End Device
Address 8
8-4
The master station WRITEs the File Identifier Object to the first data
concentrator (DC). The File_Name field specifies that the object is to be
sent to device number 3 in the first DC.
The Outstation Application in the first DC removes the first nine
characters of the File_Name. It then routes the object to the Master
Application specified as device number 3.
The Master Application configuration specifies device number 3 has DNP
destination address 22. The Master Application in the first DC WRITEs
the File Identifier Object to the second DC.
The second DC receives the WRITE request. The File_Name field
specifies that the object is to be sent to device number 10 in the second
DC.
The Outstation Application in the second DC removes the first nine
characters of the File_Name. It then routes the object to the Master
Application specified as device number 10.
The Master Application configuration specifies device number 10 has
DNP destination address 8. The Master Application in the second DC
WRITEs the File Identifier Object to the Outstation.
DNP Users Group
7)
8)
9)
10)
11)
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 a
larger response timeout than the Outstation Application in the second DC.
The DNP master station must have detailed configuration and routing
information in order to construct the File_Name field.
AN Outstation Application will not receive while it waits for a response from a
down stream device. It is "locked out" to master requests.
The File_Name field contains an ASCII character string. The length and
contents of the string is dependant on the DC. The HARRIS
implementation uses a string, the first 9 character of which are
"/DNPDCAxx", where xx (2 ASCII characters) contains the Master
Application number of the destination for this File Identifier Object. This
information routes the object through the DC to the Master Application
which 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).
8-5
DNP V3.00 Application Layer (Version 0.03)
2)
3)
5)
6)
7)
8)
Some error conditions can occur in the above sequence. In the cases where the
Outstation Application cannot pass the request to the Master Application or a
negative acknowledgement is received from the Master Application, the
Outstation Application returns the File Identifier Object received as part of the
request to the master station.
The Outstation Application will modify and set the following fields in the
response File Identifier Object;
START_RECORD = END_RECORD = 0
FILE_SIZE = 0
FILE_FUNCTION = RESPONSE
PERMISSION = 0
Outstation Application was unable to pass the File
STATUS = 2
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.
8-6
application control
application protocol control information
application protocol data unit
application service data unit
COS
change of state
DA
DC
DNP
DUI
distribution automation
data concentrator
distributed network protocol
data unit identifiers
EPA
IEC
IIN
IO
ISO
OSI
PDU
RTU
SCADA
SEQ
Version
By Whom
Oct. 08/92
Nov. 09/92
Nov. 23/92
Jun. 27/93
Jul. 01/93
Aug. 20/93
Sep. 01/93
Sep. 01/93
July. 08/97
0.00A
0.00B
0.01
0.02
0.02
0.02
0.02
0.02
0.02
MS
MS
LA
MS
JB
JB
JB
MCH
S. Tessari
Pages
Affected
All
All
All
All
All
All
All
All
All
DNP V3.00
DATA OBJECT LIBRARY
TRADEMARK NOTICES
Brand and product names mentioned in this document are trademarks or
registered trademarks of their respective companies.
TABLE OF CONTENTS
ABOUT THIS DOCUMENT
PURPOSE OF THIS SPECIFICATION
WHO SHOULD USE THIS SPECIFICATION
HELP AND ADDITIONAL DOCUMENTATION
HOW THIS SPECIFICATION IS ORGANIZED
CONVENTIONS USED IN THIS SPECIFICATION
vi
vi
vi
vi
vii
vii
1. OVERVIEW
1-1
2-1
2-1
3. GENERAL RULES
3.1 LIBRARY STRUCTURE
3.2 POINT NUMBERING
3-1
3-1
3-4
4-1
4-1
4-3
4-4
4-6
4-8
5-1
5-1
5-2
5-3
5-7
5-8
6-1
6-1
6-3
6-5
6-6
6-7
6-8
6-9
6-10
6-11
6-12
6-13
6-14
6-15
6-17
6-19
6-21
6-23
6-24
6-25
6-26
6-27
6-28
6-29
6-30
6-31
6-33
6-35
6-37
6-39
6-40
6-41
6-42
6-43
6-45
6-47
6-49
7-1
7-1
7-3
7-5
7-6
7-7
7-8
7-9
7-11
7-13
7-14
7-15
7-17
7-19
7-21
7-23
7-25
7-27
7-29
8-1
8-1
8-3
8-4
8-5
9-1
9-1
9-2
9-4
9-5
9-6
9-7
10-1
10-1
10-2
10-3
10-4
11-1
11-1
12-1
12-1
12-2
12-4
12-7
12-8
13-1
13-1
14-1
14-1
14-4
14-6
iii
14-8
14-9
14-10
iv
LIST OF TABLES
TABLE 2-1 DATA TYPES
TABLE 2-2 BIT POSITIONS
2-1
2-2
vi
vii
viii
1. OVERVIEW
The intelligent devices which use the DNP Application Layer protocol are capable of
monitoring, controlling and/or producing a large number of different pieces of data both
at 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 as
information objects and these can be packaged for transmission as application data units.
All devices provide stored information elements as information objects in the same
format. These formats are described within this document.
This document will be revised and new information elements or objects will be added as
necessary, and as authorized by the DNP User's Group.
1-1
1-2
Symbol
Meaning
1. UNSIGNED INTEGER
UI
2. INTEGER
UF
4. FIXED POINT
5. REAL
6. BITSTRING
BS
7. OCTETSTRING
OS
Assembly of octets
2-1
OCTETS
Data Size i
15
14
13
12
11
10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8j-1
8j-2
8j-3
8j-4
8j-5
8j-6
8j-7
8j-8
2-3
2-4
3. GENERAL RULES
This section will describe the general rules that apply to the DNP data objects. These
rules apply to all the current objects (except where noted) and all future objects.
Static Objects: The objects which reflect the current value of the field point or
software point.
Event Objects: The objects which are generated as a result of data changing or
some other stimulant. These are historical objects reflecting the value of data at
some time in the past.
Frozen Static Objects: The objects which reflect the current frozen value of the
field 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 data
changing or some other stimulant. These are historical objects reflecting the value
of changed data at some time in the past.
Each category should be represented with a different object. All the classes of a different
data type should also be organized in the same range of object numbers. So far, the
following groupings have been created for all traditional SCADA/DA data types and
several 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.
3-1
3-2
3-3
Point i in the static object is the same physical point as point i in the event
object.
Point i in the frozen object is the same physical point as point i in the
frozen event object.
For example: For binary inputs, point i in obj 1 var 1 and 2 is the same point as point i in
obj 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 event
correlation). In addition, point i in obj 21 var 1, 2, 3, 4, 5, 6, 7, and 8 is the same point as
point i in obj 23 var 1, 2, 3, 4, 5, 6, 7, and 8 (frozen and frozen static correlation).
NOTE:
3-4
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.
DNP Users Group
Rule 4:
Object groupings which can by definition or due to device limitation have only one point
per object or where the point number is not needed should use the range number 0 or
quantity equals to 1, when using a message format that requires a point number.
3-5
3-6
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 a
packed format. Transmission of the data object is always performed in complete octets
with unoccupied bit positions set to zero. The following example illustrates the packing
of n of these data objects.
7
15
14
13
12
11
10
n-1
n-2
n-3
n-4
4-1
NOTE:
4-2
Type: Static
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. If
this 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 is
currently restarting. This device may be the device reporting this data object.
The communication lost bit indicates that the device reporting this data object has
lost communication with the originator of the data object.
The remote forced data bit indicates that the state of the binary input has been
forced 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 been
forced to its current state at the end device.
The chatter filter bit indicates that the binary input point has been filtered in order
to remove unneeded transitions in the state of the point.
The state bit indicates the current state of the binary input point.
Object Coding:
7
BS8 [0..7]
On-line
Restart
Communication lost
Remote forced data
Local forced data
Chatter filter
Reserved
State
=
=
=
=
=
=
=
=
4-3
Type: Event
Description:
The binary input change without time object is used to represent the changed 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. If
this 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 has
been re-started. This device may be the device reporting this data object.
The communication lost bit indicates that the device reporting this data object has
lost communication with the originator of the data object.
The remote forced data bit indicates that the state of the binary input has been
forced to its current state at the originating device.
The local forced data bit indicates that the state of the binary input has been
forced to its current state at the device reporting this data object.
The chatter filter bit indicates that the binary input point has been filtered in order
to remove unneeded transitions in the state of the point.
The state bit indicates the current changed state of the binary input point.
4-4
Object Coding:
7
BS8 [0..7]
On-line
Restart
Communication lost
Remote forced data
Local forced data
Chatter filter
Reserved
State
=
=
=
=
=
=
=
=
Narrative:
This object is only reported when the current value is different than the last recorded or
measured value. If the chatter filter is on, this object may only be reported when the new
state has remained constant for a certain period of time.
4-5
Type: Event
Description:
The binary input change with time object is used to represent the changed state of a
digital input point (hardware or software) and the time at which the state changed. It also
indicates the status of the point as follows:
The on-line bit indicates that the binary input point has been read successfully. If
this 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 has
been re-started. This device may be the device reporting this data object.
The communication lost bit indicates that the device reporting this data object has
lost communication with the originator of the data object.
The remote forced data bit indicates that the state of the binary input has been
forced to its current state at the originating device.
The local forced data bit indicates that the state of the binary input has been
forced to its current state at the device reporting this data object.
The chatter filter bit indicates that the binary input point has been filtered in order
to remove unneeded transitions in the state of the point.
The state bit indicates the current changed state of the binary input point.
The Time of Occurrence indicates the absolute time at which the telecontrol device
detected the change of state. The accuracy of this time will depend on the accuracy of the
individual device.
4-6
Object Coding:
FLAG
7
TIME OF OCCURRENCE
SQ2
15
14
13
12
11
10
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
{FLAG
=
Time of Occurrence =
}
BS8 [0..7]
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Chatter filter
Reserved
State
}
BS8 [0..7]
BS1 [0] <0, off-line; 1, on-line>
BS1 [1] <0, normal; 1, restart>
BS1 [2] <0, normal; 1, lost>
BS1 [3] <0, normal; 1, forced>
BS1 [4] <0, normal; 1, forced>
BS1 [5] <0, normal; 1, filter on>
BS1 [6] <0>
BS1 [7] <0,1 BIN>
={
=
=
=
=
=
=
=
=
Narrative:
Time of occurrence is recorded as milliseconds since midnight, January 1st, 1970, at zero
hours, zero minutes, seconds, and milliseconds.
4-7
Type: Event
Description:
The binary input change with relative time object is used to represent the changed state of
a digital input point (hardware or software), and the relative time at which the state
changed. It also indicates the status of the point as follows:
The on-line bit indicates that the binary input point has been read successfully. If
this 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 has
been re-started. This device may be the device reporting this data object.
The communication lost bit indicates that the device reporting this data object has
lost communication with the originator of the data object.
The remote forced data bit indicates that the state of the binary input has been
forced to its current state at the originating device.
The local forced data bit indicates that the state of the binary input has been
forced to its current state at the device reporting this data object.
The chatter filter bit indicates that the binary input point has been filtered in order
to remove unneeded transitions in the state of the point.
The state bit indicates the current changed state of the binary input point.
The MSEC field indicates the relative time at which the telecontrol device detected the
change of state. The accuracy of this time will depend on the accuracy of the individual
device.
4-8
Object Coding:
FLAG
7
MSEC
SQ2
15
14
13
12
11
10
{FLAG
MSEC
}
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Chatter filter
Reserved
State
}
={
=
=
=
=
=
=
=
=
BS8 [0..7]
BS1 [0] <0, off-line; 1, on-line>
BS1 [1] <0, normal; 1, restart>
BS1 [2] <0, normal; 1, lost>
BS1 [3] <0, normal; 1, forced>
BS1 [4] <0, normal; 1, forced>
BS1 [5] <0, normal; 1, filter on>
BS1 [6] <0>
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 as
an 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 give
the absolute time at which the binary input change was detected by the device.
4-9
4-10
Type: Static
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 unoccupied
bit positions set to zero. The following example illustrates the packing of n of these data
objects:
7
15
14
13
12
11
10
n-1
n-2
n-3
n-4
5-1
Type: Static
Description:
The binary output status object is used to indicate the current state of a controlled digital
point and the status of that point as follows:
The on-line bit indicates that the device controlling the binary output point is
operating 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 be
unsuccessful.
The restart bit indicates that the field device that originated the data object has
been re-started. This device may be the device reporting this data object.
The communication lost bit indicates that the digital output point could not be
controlled because communications have been lost with the controlled device.
The remote forced data bit indicates that the digital output point has been
controlled 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 controlled
at 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
BS8 [0..7]
On-line
Restart
Communication lost
Remote forced data
Local forced data
Reserved
Reserved
State
5-2
=
=
=
=
=
=
=
=
Type: Static
Description:
The control relay output Block information object contains digital output control
parameters. These parameters define the type and duration of the digital output.
The control code field indicates the control function to perform. The applicability
of 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 be
performed 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).
5-3
Object Coding:
Control Code
7
Count
7
On Time
31
0
Off Time
31
0
Status
SQ4
{Control code
Count
On-time
Off-time
Status
Reserved
}
Control code
Code
Queue
Clear
Trip/Close
}
Narrative:
Trip/Close:
5-4
=
=
=
=
=
=
={
=
=
=
=
BS8 [0..7]
UI8 [0..7] <0..255>
UI32 [0..31] <0..232-1, ms>
UI32 [0..31] <0..232-1, ms>
UI7 [0..6] <0..127>
[0..0] <0..1>
Count:
The Count field determines how many times the control is executed. If the
count is 0, do not execute the control. When the count reaches 0, the
control is complete.
Code:
The control block can be used with devices which support control queuing
on a point per point basis or devices which have other control
mechanisms. In the former, any control command should be queued for the
particular point in question. In the latter, each control is performed until
completion before the next control is accepted for that point.
Queue:
If the control code is NUL then no control operation is queued, and the
queue is cleared of all controls including the presently running control if
the clear attribute is set.
When the control function is executed and completed, it is removed from
the queue. If the control block for that operation had the queue attribute
set, the control operation is re-queued (to the back of the queue) for that
point.
Clear:
If the control operation has the clear attribute set, all control operations are
removed from the queue including the presently running control and this
control operation is performed.
The meaning of the code field and the operation to perform is determined by the
following:
0:
1:
Pulse On - The point(s) is turned on for the specified on-time, turned off
for 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 turned
on for the specified on-time and left in the on state.
3:
4:
5 - 15:
Undefined.
Queue:
Clear:
5-5
The reserved bit of the control point after the operation can be determined
if the control output is on.
The success or failure of the requested control operation is returned in the
status field. The meaning of this field is determined as follows:
0:
1:
Request not accepted as 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:
3:
4:
5:
6:
7 - 127:Undefined.
5-6
Type: Static
Description:
The pattern control block (PCB) object contains digital output control parameters for
pattern type controls. These parameters define the type and duration of the digital output
for each of the affected points. The PCB object defines all the parameters for the
subsequent pattern mask objects which follow this object in the message. These
parameters contained in the PCB influence all the pattern mask object(s) that immediately
follow the PCB object, until the next PCB in the message.
The combination of this object and the pattern mask objects that follow will specify a
number (0 or more) of control operations to perform (i.e. the same operation on different
points). 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 the
queuing attributes are not valid. This is, the pattern control is not meant to be re-queued.
Object Coding:
Control Code
7
Count
7
On Time
31
0
Off Time
31
0
Status
5-7
Type: Static
Description:
The pattern mask object is used to select from a range of possible control points that have to
be executed in parallel.
This object is used in conjunction with the PCB object to specify both the control points to
operate and the parameters that determine the control operation.
If the mask bit is set to active, then the parameters specified in the preceding PCB are
applied to a specified point for each pattern mask object and a control operation is generated
for 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 is
always performed in complete octets with unoccupied bit positions set to zero. The
following example illustrates the packing of n of these data objects.
5-8
15
14
13
12
11
10
n-1
n-2
n-3
n-4
Type: Static
Description:
The 32-bit binary counter represents an accumulated value. 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 last
reported value from the originating device. This value increments indefinitely until a
counter 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 last
reported recordable value (232-1). The counter value has been reset to 0 upon the rollover and counting has resumed as normal. This bit is cleared when the counter value
(plus the roll-over state) is reported.
6-1
Object Coding:
FLAG
7
Value
31
SQ2
6-2
{FLAG
Value
}
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Type: Static
Description:
The 16-bit binary counter represents an accumulated value. 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 last
reported value from the originating device. This value increments indefinitely until a
counter 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
maximum possible recordable value (216-1). The counter value has been reset to 0 upon
roll-over, and counting has resumed as normal. This bit is cleared when the counter value
(plus the roll-over state) is reported.
6-3
Object Coding:
FLAG
7
Value
15
SQ2
6-4
{FLAG
Value
}
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Type: Static
Description:
The 32-bit delta counter represents a value that has accumulated since the last value was
reported. 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 last
reported value from the originating device. This value increments until it is reported at
which point it 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
maximum possible recordable value (232-1). The counter value has been reset to 0 upon
roll-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
Value
31
SQ2
{FLAG
Value
}
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
6-5
Type: Static
Description:
The 16-bit delta counter represents a value that has accumulated since the last value was
reported. 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 last
reported value from the originating device. This value increments until it is reported at
which point it 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
maximum possible recordable value (216-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.
Object Coding:
FLAG
7
Value
15
SQ2
6-6
{FLAG
Value
}
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Type: Static
Description:
The 32-bit binary counter represents an accumulated value. 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 last
reported value from the originating device. This value increments indefinitely until a
counter clear operation is performed in which case the value is reset to 0.
Object Coding:
Value
31
SQ2
{Value =
}
NOTE:
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
6-7
Type: Static
Description:
The 16-bit binary counter represents an accumulated value. 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 last
reported value from the originating device. This value increments indefinitely until a
counter clear operation is performed in which case the value is reset to 0.
Object Coding:
Value
15
SQ2
{Value =
}
NOTE:
6-8
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
Type: Static
Description:
The 32-bit delta counter represents a value that has accumulated since the last value was
reported. 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 last
reported value from the originating device. This value increments until it is reported at
which point it is reset to 0.
Object Coding:
Value
31
SQ2
{Value =
}
NOTE:
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
6-9
Type: Static
Description:
The 16-bit delta counter represents a value that has accumulated since the last value was
reported. 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 last
reported value from the originating device. This value increments until it is reported at
which point it is reset to 0.
Object Coding:
Value
15
SQ2
{Value =
}
NOTE:
6-10
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
Description:
The 32-bit frozen counter is a compound information object which contains information
about a counter which was previously frozen.
The frozen value shows the value of the counter when the last counter freeze was performed
at the originating device.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Frozen Value
31
SQ2
{FLAG
Frozen Value
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
6-11
Description:
The 16-bit frozen counter is a compound information object that contains information about
a counter that was previously frozen. The counter accumulates pulses or transitions from a
hardware or software point.
The frozen value shows the value of the counter when the last counter freeze was performed
at the originating device.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Frozen Value
15
SQ2
6-12
{FLAG
Frozen Value
}
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Description:
The 32-bit frozen delta counter represents a frozen value that has accumulated since the last
value was reported. This can be accumulated pulses or transitions from a hardware or
software point.
The frozen value shows the value of the counter when the last counter freeze was performed
at the originating device.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Frozen Value
31
SQ2
{FLAG
Frozen Value
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
6-13
Description:
The 16-bit frozen delta counter represents a frozen value that has accumulated since the last
value was reported. This can be accumulated pulses or transitions from a hardware or
software point.
The frozen value shows the value of the counter when the last counter freeze was performed
at the originating device.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Frozen Value
15
SQ2
6-14
{FLAG
Frozen Value
}
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Description:
The 32-bit frozen counter with time of freeze is a compound information object which
contains information about a counter which was previously frozen. The counter
accumulates 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 to
the frozen value so that the current value of this object at time of freeze is frozen value.
The flag field has the same meaning as in previous objects.
6-15
Object Coding:
FLAG
7
Frozen Value
31
0
Time of Freeze
47
SQ4
{FLAG
Frozen value
Time of Freeze
}
=
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time of freeze is recorded as milliseconds since midnight, January 1st, 1970, at zero hours,
zero minutes, seconds, and milliseconds.
6-16
Description:
The 16-bit frozen counter with time of freeze is a compound information object which
contains information about a counter which was previously frozen. The counter
accumulates 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 to
the frozen value so that the current value of this object at time of freeze is frozen value.
The flag field has the same meaning as in previous objects.
6-17
Object Coding:
FLAG
7
Frozen Value
15
0
Time of Freeze
47
SQ4
{FLAG
Frozen value
Time of Freeze
}
=
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time of freeze is recorded as milliseconds since midnight, January 1st, 1970, at zero hours,
zero minutes, seconds, and milliseconds.
6-18
Description:
The 32-bit frozen delta counter with time of freeze represents a frozen value that has
accumulated since the last value was reported. This can be accumulated 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 to
the frozen value so that the current value of this object at time of freeze is frozen value.
The flag field has the same meaning as in previous objects.
6-19
Object Coding:
FLAG
7
Frozen value
31
0
Time of Freeze
47
SQ4
{FLAG
Frozen value
Time of Freeze
}
=
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time of freeze is recorded as milliseconds since midnight, January 1st, 1970, at zero hours,
zero minutes, seconds, and milliseconds.
6-20
Description:
The 16-bit frozen delta counter with time of freeze represents a frozen value that has
accumulated since the last value was reported. This can be accumulated 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 to
the frozen value so that the current value of this object at time of freeze is frozen value.
The flag field has the same meaning as in previous objects.
6-21
Object Coding:
FLAG
7
Frozen value
15
0
Time of Freeze
47
SQ4
{FLAG
Frozen value
Time of Freeze
}
=
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time of freeze is recorded as milliseconds since midnight, January 1st, 1970, at zero hours,
zero minutes, seconds, and milliseconds.
6-22
Description:
The 32-bit frozen counter is a compound information object which contains information
about a counter which was previously frozen.
The frozen value shows the value of the counter when the last counter freeze was performed
at the originating device.
Object Coding:
Frozen Value
31
SQ2
{Frozen Value =
}
NOTE:
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
6-23
Description:
The 16-bit frozen counter is a compound information object which contains information
about a counter which was previously frozen. The counter accumulates pulses or transitions
from a hardware or software point.
The frozen value shows the value of the counter when the last counter freeze was performed
at the originating device.
Object Coding:
Frozen Value
15
SQ2
NOTE:
6-24
{Frozen Value
}
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
Description:
The 32-bit frozen delta counter represents a frozen value that has accumulated since the last
value was reported. This can be accumulated pulses or transitions from a hardware or
software point.
The frozen value shows the value of the counter when the last counter freeze was performed
at the originating device.
Object Coding:
Frozen Value
31
SQ2
{Frozen Value =
}
NOTE:
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
6-25
Description:
The 16-bit frozen delta counter represents a frozen value that has accumulated since the last
value was reported. This can be accumulated pulses or transitions from a hardware or
software point.
The frozen value shows the value of the counter when the last counter freeze was performed
at the originating device.
Object Coding:
Frozen Value
15
SQ2
{Frozen Value =
}
NOTE:
6-26
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
Type: Event
Description:
The 32-bit counter change event without time represents a counter value that, since last
reported, has exceeded a configured count. This can be accumulated pulses or transitions
from a hardware or software point.
The current value field shows the value of the counter which generated the event.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Current value
31
SQ4
{FLAG
Current value
}
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
6-27
Type: Event
Description:
The 16-bit counter change event without time represents a counter value that has exceeded a
configured deadband. This can be accumulated pulses or transitions from a hardware or
software point.
The current value field shows the value of the counter which generated the event.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Current value
15
SQ4
6-28
{FLAG
Current value
}
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Type: Event
Description:
The 32-bit delta counter change event without time represents a delta counter value that has
exceeded a configured deadband. This can be accumulated pulses or transitions from a
hardware or software point.
The delta value field shows the change of the counter which generated the event.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Delta value
31
SQ4
{FLAG
Current value
}
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
6-29
Type: Event
Description:
The 16-bit delta counter change event without time represents a delta counter value that has
exceeded a configured deadband. This can be accumulated pulses or transitions from a
hardware or software point.
The delta value field shows the change of the counter which generated the event.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Delta value
15
SQ4
6-30
{FLAG
Current value
=
=
BS8 [0..7]
UI32 [0..16] <0..216-1>}
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Type: Event
Description:
The 32-bit counter change event with time represents a counter value that has exceeded a
configured deadband. This can be accumulated pulses or transitions from a hardware or
software 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.
The flag field has the same meaning as in previous objects.
6-31
Object Coding:
FLAG
7
Value
31
0
Time
47
SQ4
{FLAG
Value
Time
}
=
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time is recorded as milliseconds since midnight, January 1st, 1970, at zero hours, zero
minutes, seconds, and milliseconds.
6-32
Type: Event
Description:
The 16-bit counter change event with time represents a counter value that has exceeded a
configured deadband. This can be accumulated pulses or transitions from a hardware or
software 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.
The flag field has the same meaning as in previous objects.
6-33
Object Coding:
FLAG
7
Value
15
0
Time
47
SQ4
{FLAG
Value
Time
}
=
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time is recorded as milliseconds since midnight, January 1st, 1970, at zero hours, zero
minutes, seconds, and milliseconds.
6-34
Type: Event
Description:
The 32-bit delta counter change event with time represents a delta counter value that has
exceeded a configured deadband. This can be accumulated pulses or transitions from a
hardware 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.
The flag field has the same meaning as in previous objects.
6-35
Object Coding:
FLAG
7
Value
31
0
Time
47
SQ4
{FLAG
Value
Time
}
=
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time is recorded as milliseconds since midnight, January 1st, 1970, at zero hours, zero
minutes, seconds, and milliseconds.
6-36
Type: Event
Description:
The 16-bit delta counter change event with time represents a delta counter value that has
exceeded a configured deadband. This can be accumulated pulses or transitions from a
hardware 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.
The flag field has the same meaning as in previous objects.
6-37
Object Coding:
FLAG
7
Value
15
0
Time
47
SQ4
{FLAG
Value
Time
}
=
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time is recorded as milliseconds since midnight, January 1st, 1970, at zero hours, zero
minutes, seconds, and milliseconds.
6-38
Description:
The 32-bit frozen counter event without time object represents a frozen counter value that is
reported as an event. This can be accumulated pulses or transitions from a hardware or
software point.
The frozen value field shows the value at the time of freezing.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Frozen value
31
SQ4
{FLAG
Frozen value
}
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
6-39
Description:
The 16-bit frozen counter event without time represents a frozen counter value that is
reported as an event. This can be accumulated pulses or transitions from a hardware or
software point.
The frozen value field shows the value at the time of freezing.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
Frozen value
15
SQ4
6-40
{FLAG
Frozen value
}
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Description:
The 32-bit frozen delta counter event without time represents a frozen delta counter value
that is reported as an event. This can be accumulated pulses or transitions from a hardware
or software point.
The frozen delta value field shows the change in counter value at the time of freezing.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
SQ4
{FLAG
Frozen delta value
}
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
6-41
Description:
The 16-bit frozen delta counter event without time represents a frozen delta counter value
that is reported as an event. This can be accumulated pulses or transitions from a hardware
or software point.
The frozen delta value field shows the change in counter value at the time of freezing.
The flag field has the same meaning as in previous objects.
Object Coding:
FLAG
7
SQ4
6-42
{FLAG
Frozen delta value
}
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Description:
The 32-bit frozen counter event with time represents a frozen counter value that is reported
as an event. This can be accumulated pulses or transitions from a hardware or software
point.
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.
The flag field has the same meaning as in previous objects.
6-43
Object Coding:
FLAG
7
Frozen Value
31
0
Time of Freeze
47
SQ4
{FLAG
Frozen Value
Time of Freeze
}
=
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time is recorded as milliseconds since midnight, January 1st, 1970, at zero hours, zero
minutes, seconds, and milliseconds.
6-44
Description:
The 16-bit frozen counter event with time represents a frozen counter value that is reported
as an event. This can be accumulated pulses or transitions from a hardware or software
point.
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.
The flag field has the same meaning as in previous objects.
6-45
Object Coding:
FLAG
7
Frozen Value
15
0
Time of Freeze
47
SQ4
{FLAG
Frozen Value
Time of Freeze
}
=
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time is recorded as milliseconds since midnight, January 1st, 1970 at zero hours, zero
minutes, seconds and milliseconds.
6-46
Description:
The 32-bit frozen delta counter event with time represents a frozen delta counter value that
is reported as an event. This can be accumulated pulses or transitions from a hardware or
software point.
The frozen value shows the change in the counter at time of freeze.
The time of freeze contains the time that the object was frozen.
The flag field has the same meaning as in previous objects.
6-47
Object Coding:
FLAG
7
Frozen Value
31
0
Time of Freeze
47
SQ4
{FLAG
Frozen Value
Time of Freeze
}
=
=
=
BS8 [0..7]
UI32 [0..31] <0..232-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time is recorded as milliseconds since midnight, January 1st, 1970 at zero hours, zero
minutes, seconds and milliseconds.
6-48
Description:
The 16-bit frozen delta counter event with time represents a frozen delta counter value that
is reported as an event. This can be accumulated pulses or transitions from a hardware or
software point.
The frozen value shows the change in the counter at time of freeze.
The time of freeze contains the time that the object was frozen.
The flag field has the same meaning as in previous objects.
6-49
Object Coding:
FLAG
7
Frozen Value
15
0
Time of Freeze
47
SQ4
{FLAG
Frozen Value
Time of Freeze
}
=
=
=
BS8 [0..7]
UI16 [0..15] <0..216-1>
UI48 [0..47] <248 -1 ms>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Roll-over
Roll-over
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
=
Narrative:
Time is recorded as milliseconds since midnight, January 1st, 1970, at zero hours, zero
minutes, seconds, and milliseconds.
6-50
Type: Static
Description:
The 32-bit Analog Input is an information object used to represent a hardware or software
analog 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 the
last 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 overrange 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.
7-1
Object Coding:
FLAG
7
0
Current value
31
SQ2
7-2
{FLAG
Current value
}
=
=
BS8 [0..7]
I32 [0..31] <231-1..-231>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Type: Static
Description:
The 16-bit analog input is an information object used to represent a hardware or software
analog 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 the
last reported value from the originating device.
The flag field has the same meaning as previous objects, with these additions:
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 not
defined.
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.
7-3
Object Coding:
FLAG
7
0
Current value
15
SQ2
7-4
{FLAG
Current value
}
=
=
BS8 [0..7]
I16 [0..15] <215-1..-215>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Type: Static
Description:
The 32-bit analog input is an information object used to represent a hardware or software
analog 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 the
last reported value from the originating device.
Object Coding:
Current value
31
SQ2
{Current value =
}
NOTE:
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
7-5
Type: Static
Description:
The 16-bit analog input is an information object used to represent a hardware or software
analog point. The 16-bit signed value could represent a digitized signal or calculated value.
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
SQ2
{Current value =
}
NOTE:
7-6
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
Description:
The 32-bit frozen analog input is an information object used to represent a frozen hardware
or software analog point. The 32-bit signed value could represent a digitized signal or
calculated value.
The frozen value shows the value of the analog input at the time the last freeze command
was performed on this point.
The flag field has the same meaning as previous objects, with these additions:
The over-range field indicates that the digitized signal or calculation has exceeded +231 1 positively, or -231 negatively. The actual value field can be ignored as its value is not
defined.
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
Frozen value
31
SQ2
{FLAG
Current value
}
=
=
BS8 [0..7]
I32 [0..31] <231-1..-231>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
7-7
Description:
The 16-bit frozen analog input is an information object used to represent a frozen hardware
or software analog point. The 16-bit signed value could represent a digitized signal or
calculated value.
The frozen value shows the value of the analog input at the time the last freeze command
was performed on this point.
The flag field has the same meaning as previous objects, with these additions:
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 not
defined.
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
Frozen value
15
SQ2
7-8
{FLAG
Current value
}
=
=
BS8 [0..7]
I16 [0..15] <215-1..-215>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Description:
The 32-bit frozen analog input with time of freeze is an information object used to represent
a frozen hardware or software analog point. The 32-bit signed value could represent a
digitized 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 current
value of the analog input. These values are equated on reception of a freeze analog
command.
The flag field has the same meaning as previous objects, with these additions:
The over-range field indicates that the digitized signal or calculation has exceeded +231 1 positively, or -231 negatively. The actual value field can be ignored as its value is not
defined.
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.
7-9
Object Coding:
FLAG
7
0
Frozen value
31
Time of Freeze
47
SQ2
7-10
{FLAG
Current value
Time of Freeze
}
=
=
=
BS8 [0..7]
I32 [0..31] <231-1..-231>
UI48[0..47] <0 .. 2 48 >
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Description:
The 16-bit frozen analog input with time of freeze is an information object used to
represent a frozen hardware or software analog point. The 16-bit signed value could
represent a digitized 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 current
value of the analog input. These values are equated on reception of a freeze analog
command.
The flag field has the same meaning as previous objects, with these additions:
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 not defined.
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.
7-11
Object Coding:
FLAG
7
0
Frozen value
15
Time of Freeze
47
SQ2
7-12
{FLAG
Time of freeze
Current value
}
=
=
=
BS8 [0..7]
UI48[0..47] <0 .. 2 48 -1>
I16 [0..15] <215-1..-215>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Description:
The 32-bit frozen analog input is an information object used to represent a frozen
hardware or software analog point. The 32-bit signed value could represent a digitized
signal or calculated value.
The frozen value shows the value of the analog input at the time the last freeze command
was performed on this point.
Object Coding:
Frozen value
31
SQ2
{Current value=
}
NOTE:
The use of this variation implies that the input point is on-line and that all
other flag bits are normal (i.e. this variation implies that flag = 1).
7-13
Description:
The 16-bit frozen analog input is an information object used to represent a frozen
hardware or software analog point. The 16-bit signed value could represent a digitized
signal or calculated value.
The frozen value shows the value of the analog input at the time the last freeze command
was performed on this point.
Object Coding:
Frozen value
15
SQ2
7-14
{Current value=
}
Type: Event
Description:
The 32-bit analog change event without time is an information object used to represent a
changed hardware or software analog point. The 32-bit signed value could represent a
digitized signal or calculated value.
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. This object will only be
reported if the current value and the last reported value differ by a configurable deadband
value. This filtering is commonly known as deadbanding.
The flag field has the same meaning as previous objects, with these additions:
The over-range field indicates that the digitized signal or calculation has exceeded
+231 -1 positively, or -231 negatively. The actual value field can be ignored as its value
is not defined.
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.
7-15
Object Coding:
FLAG
7
0
Current value
31
SQ2
7-16
{FLAG
Current value
}
=
=
BS8 [0..7]
I32 [0..31] <231-1..-231>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Type: Event
Description:
The 16-bit analog change event without time is an information object used to represent a
changed hardware or software analog point. The 16-bit signed value could represent a
digitized signal or calculated value.
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. This object will only be
reported if the current value and the last reported value differ by a configurable deadband
value. This filtering is commonly known as deadbanding.
The flag field has the same meaning as previous objects, with these additions:
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 not defined.
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.
7-17
Object Coding:
FLAG
7
0
Current value
15
SQ2
7-18
{FLAG
Current value
}
=
=
BS8 [0..7]
I16 [0..15] <215-1..-215>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Type: Event
Description:
The 32-bit analog change event with time is an information object used to represent a
changed hardware or software analog point. The 32-bit signed value could represent a
digitized 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.
The flag field has the same meaning as previous objects, with these additions:
The over-range field indicates that the digitized signal or calculation has exceeded
+231 -1 positively, or -231 negatively. The actual value field can be ignored as its value
is not defined.
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.
7-19
Object Coding:
FLAG
7
0
Value
31
0
Time
47
SQ2
7-20
{FLAG
Time
Value
}
=
=
=
BS8 [0..7]
UI48[0..47] <0 .. 2 48 -1>
I32[0..31] <231-1..-231>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Type: Event
Description:
The 16-bit analog change event with time is an information object used to represent a
changed hardware or software analog point. The 16-bit signed value could represent a
digitized 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.
The flag field has the same meaning as previous objects, with these additions:
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 not defined.
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.
7-21
Object Coding:
FLAG
7
0
Value
15
0
Time
47
SQ2
7-22
{FLAG
Time
Value
}
=
=
=
BS8 [0..7]
UI48 [0..47] <0 .. 2 48 -1>
I16 [0..15] <215-1..-215>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Description:
The 32-bit frozen analog event without time is an information object used to represent a
frozen hardware or software analog point that is reported as an event. The 32-bit signed
value could represent a digitized signal or calculated value.
The frozen value field shows the value of the analog input at the time of freeze.
The flag field has the same meaning as previous objects, with these additions:
The over-range field indicates that the digitized signal or calculation has exceeded
+231 -1 positively, or -231 negatively. The actual value field can be ignored as its value
is not defined.
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.
7-23
Object Coding:
FLAG
7
0
Frozen value
31
SQ2
7-24
{FLAG
Frozen value
}
=
=
BS8 [0..7]
I32 [0..31] <231-1..-231>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Description:
The 16-bit frozen analog event without time is an information object used to represent a
frozen hardware or software analog point that is reported as an event. The 16-bit signed
value could represent a digitized signal or calculated value.
The frozen value field shows the value of the analog input at the time of freeze.
The flag field has the same meaning as previous objects, with these additions:
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 not defined.
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.
7-25
Object Coding:
FLAG
7
0
Frozen value
15
SQ2
7-26
{FLAG
Frozen value
}
=
=
BS8 [0..7]
I16 [0..15] <215-1..-215>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Description:
The 32-bit frozen analog event with time is an information object used to represent a
frozen hardware or software analog point that is reported as an event. The 32-bit signed
value 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:
The over-range field indicates that the digitized signal or calculation has exceeded
+231 -1 positively, or -231 negatively. The actual value field can be ignored as its value
is not defined.
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.
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 freeze
analog command.
7-27
Object Coding:
FLAG
7
0
Frozen value
31
Time of Freeze
47
SQ2
7-28
{FLAG
Frozen value
Time of Freeze
}
=
=
=
BS8 [0..7]
I32 [0..31] <231-1..-231>
UI48[0..47] <0 .. 2 48 -1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Description:
The 16-bit frozen analog event with time is an information object used to represent a
frozen hardware or software analog point that is reported as an event. The 16-bit signed
value 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:
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 not defined.
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.
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 freeze
analog command.
7-29
Object Coding:
FLAG
7
0
Frozen value
15
Time of Freeze
47
SQ2
7-30
{FLAG
Frozen value
Time of Freeze
}
=
=
=
BS8 [0..7]
I16 [0..15] <215-1..-215>
UI48[0..47] <0 .. 2 48 -1>
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Type: Static
Description:
The 32-bit analog output status information object represents the actual value of an
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.
8-1
Object Coding:
FLAG
7
Current value
31
SQ3
{FLAG
Current value
}
=
=
BS8 [0..7]
I32 [0..31] <231-1..-231>
FLAG
On-line
Restart
Communication lost
Remote forced data
Reserved
Reserved
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
Narrative:
This object can be returned after an analog output operation is performed in order to
determine the success of the operation.
8-2
Type: Static
Description:
The 16-bit analog output status information object represents the actual value of a
hardware 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
Current value
15
SQ3
{FLAG
Current value
}
=
=
BS8 [0..7]
I16 [0..15] <215-1..-215>
FLAG
On-line
Restart
Communication lost
Remote forced data
Reserved
Reserved
Reserved
Reserved
}
={
=
=
=
=
=
=
=
=
Narrative:
This object can be returned after an analog output operation is performed in order to
determine the success of the operation.
8-3
Type: Static
Description:
The 32-bit analog output information object represents the desired value of a hardware
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 actual
value 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 same
way that the control delay output block does. The definition of this field is the same as the
control relay output block.
Object Coding:
Requested value
31
0
Control Status
8-4
Type: Static
Description:
The 16-bit analog output block information object represents the desired value of a
hardware 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 actual
value 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 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
15
0
Control Status
I16
I8
Requested value
Status
=
=
8-5
8-6
Absolute Time=
15
14
13
12
11
10
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
Narrative:
Absolute Time is recorded as milliseconds since midnight, January 1st, 1970, at zero
hours, zero minutes, zero seconds, and milliseconds.
9-1
9-2
Object Coding:
Absolute time
7
15
14
13
12
11
10
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
SQ2
{Absolute time
Interval
}
15
14
13
12
11
10
23
22
21
20
19
18
17
16
31
30
29
28
27
26
25
24
=
=
Narrative:
Absolute time is recorded as milliseconds since midnight, January 1st, 1970, at zero
hours, zero minutes, zero seconds, and milliseconds.
9-3
Absolute time =
15
14
13
12
11
10
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
Narrative:
Absolute time is recorded as milliseconds since midnight, January 1st, 1970, at zero
hours, zero minutes, zero seconds, and milliseconds.
9-4
Relative-absolute time
15
14
13
12
11
10
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
Narrative:
Relative-absolute time is recorded as milliseconds since midnight, January 1st, 1970, at
zero hours, zero minutes, zero seconds, and milliseconds.
9-5
Seconds =
9-6
15
14
13
12
11
10
Milliseconds =
15
14
13
12
11
10
9-7
9-8
10-1
10-2
10-3
10-4
11-1
The File_Name field will be modified so that the root of the remote device is specified
by the File_Name field. This means stripping off any paths that were used to actually
derive the name of the remote device.
For example, an IED configuration is sent from a host through two data concentrators
DC1 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 and
config1 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 the
object is sent in a request.
31
24 23
Attributes
16 15
File_Type
End_Record
87
Name_Size
Start_Record
File_Size
Time_Of_Creation
Permission
File_ID
Owner_ID
Group_ID
Status
X
11-2
File_Name
File_Function
0
Name_Size:
File_Function:
0 = APPEND:
1 = DELETE:
11-3
2 = INSERT:
3 = WRITE:
Data
x
Record_Size
0
15
Where:
4 = ERASE:
11-4
x = Record_Size * 8
Record_Size = 0 .. 65535
5 = INFO:
6 = CWD:
7 = PWD:
8 = EXEC:
11-5
9 = READ:
255 = RESP:
Permission:
File_Type:
11-6
Attributes:
0:
1:
2:
3:
Status:
1:
Doesn't_exist indicates that the file name is not contained in the file
system.
2:
Out_of_Space indicates that the file operation caused the file to exceed its
maximum size as determined by the User ID, Group ID, and Permission.
3:
No_Permission indicates that the file owner does not have enough
privileges for the operation requested.
4:
File_Busy indicates that the file could not be delivered to the destination.
File_Size:
Start_Record:
End_Record:
Record_Size:
Time_of_Creation:
Time that the file was created or last modified. This field has the
same format as Object 50 Variation 1.
11-7
Owner_ID:
Group_ID:
File_ID:
Unique integer identifier for the file. This field can also be used to
hold the error check (typically 16-bit CRC) for the file. In this case,
the File_ID is only unique when concatenated with the File_Name
and the Time_Of_Creation.
Data:
Actual data bytes that make up the file record. These 8-bit objects
are interpreted according to the File_Type field. The contents of
the Data field will not be interpreted by the DNP Application
Layer.
11-8
BS1
[0..0]
State = BS1 [0] <0,1>
Narrative:
Transmission of the data object is always performed in complete octets, with unoccupied
bit positions set to zero. The following example illustrates the packing of n of these data
objects.
7
15
14
13
12
11
10
n-1
n-2
n-3
n-4
12-1
12-2
Object Coding:
STATUS
7
GROUP
7
0
VARIATION
Storage Object
Status
={
Status
Group
Variation
}
=
=
=
BS8 [0..7]
UI8 [0..7] <0..255>
UI8 [0..7] <0..255>
={
Percent
Overflow
}
=
=
Narrative:
The storage object is used to indicate the status of buffer, queues, or other storage areas
within the sending device. The object is generated by the device as configured in the
device and described in the particular device profile.
12-3
Object Coding:
Functions
63
0
NumObjects (n)
15
0
ObjectHeader 1
Quantity
7
Qualifier
0
Variation
0
Object
0
ObjectHeader 2
Quantity
7
Qualifier
0
Variation
0
Object
0
ObjectHeader n
Quantity
7
SQ2
Qualifier
0
{Functions
=
NumObjects =
}
Variation
0
Object
0
BS64 [0..63]
UI16 [0.15] <0..65535>
Each object header that follows has a variable format determined by the rules for
constructing Application Layer object headers.
Some sample headers are:
Object Header =
SQ4
{
Object
Variation
Qualifier
Quantity
}
=
=
=
=
12-5
Object Header =
SQ5
{
Object
Variation
Qualifier
Start
Stop
}
Object Header =
SQ5
{
Object
Variation
Qualifier
Start
Stop
}
12-6
=
=
=
=
=
=
=
=
=
=
Description:
This private registration object (PRO) object type is reserved for vendor-specific
definition. 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 contents
is 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 described
by the PROD object.
Object Coding:
VENDOR
31
0
PRN
15
LEN
15
0
DATA OBJECTS
0
SQx
{Vendor
PRN
LEN
SQn
}
=
=
=
=
U132 [0..232-1]
U116[0..216-1]
U116 [0..216-1] Length of objects in <octets>
sequence of n basic DNP objects
12-7
Type: Static
Description:
This object type is reserved for vendor private registration object description. The object
is matched one-to-one with its PRO object. 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 contents is entirely at the discretion of the vendor.
The private registration object description (PROD) object maintains a one-to-one
relationship with the PRO object, and can be used to parse the PRO into basic DNP
Objects for processing. The PROD consists of one element for each corresponding
element of the PRO. Each element consists in turn of a set of DNP object and variation
numbers.
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. Each
object definition consists of the three fields: quantity, object and variation.
The Quantity field specifies the number of objects, specified by the object and variation
fields, which will be found in the PRO object.
12-8
Object Coding:
VENDOR
31
0
PRN
15
0
COUNT
15
0
QUANTITY
15
0
OBJECT
0
VARIATION
0
QUANTITY
15
0
OBJECT
0
VARIATION
0
QUANTITY
15
0
OBJECT
0
VARIATION
SQx
{Vendor
PRN
COUNT
SQn
=
=
=
=
{
UI32 [0..232-1]
UI16 [0..216-1]
UI16 [0..216-1]
Sequence of n basic DNP object definitions
U18 [0..28-1]
Object
=
U18 [0..28-1]
Variation
=
U18 [0..216-1]
Quantity
=
}
}
12-9
16
3
2
1
2
2
21
2
5
30
1
12-10
16
33
binary input
1
binary input
2
Counter 1
Counter 2
Analog 1
Analog 2
Analog 3
Analog 4
Analog 5
12-11
12-12
13-1
13-2
14-1
Object Coding:
Units
Flag
Value
Sign
0
Exponent
0
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
={
=
=
=
=
=
=
=
=
Significant
22
0
Narrative:
The absolute value can be derived from the value field as follows:
14-2
Absolute_Value
where:
si
Sign:
Exponent:
Significant:
14-3
Flag
Value
Sign
0
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
14-4
Exponent
10
0
={
=
=
=
=
=
=
=
=
Significant
51
0
Narrative:
The absolute value can be derived from the value field as follows:
Absolute_Value
where:
si
Sign:
Exponent:
Significant:
14-5
Flag
Value
Sign
0
FLAG
On-line
Restart
Communication lost
Remote forced data
Local forced data
Over-range
Reference check
Reserved
}
14-6
Exponent
14
0
={
=
=
=
=
=
=
=
=
Significant
63
0
Narrative:
The absolute value can be derived from the value field as follows:
Absolute_Value
where:
si
Sign:
Exponent:
Significant:
14-7
SPBCD
14-8
Digit 3
0
= SQ4 {
Digit1
Digit2
Digit3
Digit4
}
=
=
=
=
Digit 2
0
Digit 1
0
Digit 3
0
Digit 8
3
MPBCD =
Digit 2
0
Digit 7
SQ8 {
Digit1
Digit2
Digit3
Digit4
Digit5
Digit6
Digit7
Digit8
}
=
=
=
=
=
=
=
=
Digit 1
0
Digit 6
Digit 5
0
14-9
Digit 3
0
Digit 8
3
LPBCD
14-10
Digit 5
Digit 10
Digit 15
SQ16 {
Digit1=
Digit2=
Digit3=
Digit4=
Digit5=
Digit6=
Digit7=
Digit8=
Digit9=
Digit10=
Digit11=
Digit12=
Digit13=
Digit14=
Digit15=
}
Digit 1
0
Digit 6
Digit 11
Digit 16
3
Digit 7
Digit 12
3
Digit 2
0
Digit 9
Digit 14
Digit 13
0
BCD
BIN
BS
CRC
CTO
CTO
CWD
DA
DAC
DNP
distributed automation
data acquisition and control
Distributed Network Protocol
EBCDIC
EXEC
F
FIFO
fixed point
first-in-first-out
I
ID
IEC
IEEE
integer
identification
International Electrotechnical Commission
Institute of Electrical and Electronics Engineers
LEN
LPBCD
length
large-packed binary coded decimal
MPBCD
MSEC
OS
octet string
bit string
PCB
PRN
PRO
PROD
PWD
R
RESP
RMS
real
response
root mean squared
SCADA
SPBCD
UF
UI
DNP V3.00
SUBSET DEFINITIONS
Document Number: P009-0IG.SUB
Version: 2.00
Date: November, 1995
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
ii
VERSION
DATE
INITIALS
COMMENT
0.01
94.09.20
GG/PM
0.02
95.06.08
GG
1.00
95.07.12
GG
2.00
95.11.29
ST
TABLE 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
iii
iv
LIST OF TABLES
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:
-
vi
Chapter 2:
Chapter 3:
Chapter 4:
Chapter 5:
vii
viii
OVERVIEW
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.
ix
Slave
parse
report
support
REQUEST
Qual Codes
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
Qual Codes
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.
xi
OBJECT
REQUEST
RESPONSE
(master must
parse)
Obj
Va
r
Description
Func
Codes
Qual
Codes
(hex)
Func
Codes
Qual
Codes
(hex)
30
00, 01, 06
129,
130
01
......
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.
The Master need not use the data supplied by the Slave for any
purpose, but can discard it after sending any necessary
confirmation.
xii
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
Static objects
06
All points
Not valid
07, 08
xiii
NOTE:
If such objects do not exist, the Slave is
allowed to respond OBJECT UNKNOWN (see 4.1
Error Responses).
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.
Var
Description
REQUEST
RESPONSE
Func
Codes
(dec)
Qual
Codes
(hex)
Func
Codes
(dec)
Qual
Codes
(hex)
Binary Input
129
00, 01
129
00, 01
129, 130
17, 28
129, 130
17, 28
129, 130
17, 28
10
10
Binary Output
10
129
00, 01
12
12
129
echo of
request
12
12
Pattern Mask
20
20
129
00, 01
20
129
00, 01
20
129
00, 01
20
129
00, 01
20
129
00, 01
20
129
00, 01
20
129
00 ,01
20
129
00, 01
21
3, 4, 5,
6
06
17, 28
21
21
21
21
21
21
OBJECT
Description
REQUEST
RESPONSE
Obj
Var
Func
Codes
(dec)
21
21
21
10
21
11
21
12
22
22
129, 130
17, 28
22
129, 130
17, 28
22
129, 130
17, 28
22
129, 130
17, 28
22
22
22
22
23
23
23
23
23
23
23
23
23
30
30
129
00, 01
30
129
00, 01
30
129
00, 01
30
129
00, 01
31
31
31
31
31
Qual
Codes
(hex)
Func
Codes
(dec)
Qual
Codes
(hex)
OBJECT
Description
REQUEST
RESPONSE
Obj
Var
31
31
32
32
129, 130
17,28
32
129, 130
17,28
32
32
33
33
33
33
33
40
40
40
129
00, 01
41
41
41
129
echo of
request
50
50
129, 130
07,
50
51
51
Func
Codes
(dec)
Qual
Codes
(hex)
Func
Codes
(dec)
Qual
Codes
(hex)
06
3, 4, 5,
6
17, 28
2 (see
4.14)
07,
quantity=1
quantity=1
51
129, 130
07,
quantity=1
52
52
129
07,
quantity=1
52
129
07,
quantity=1
60
60
Class 0 Data
06
60
Class 1 Data
06,07,08
REQUEST
RESPONSE
OBJECT
Obj
Var
Description
Func
Codes
(dec)
60
Class 2 Data
06,07,08
60
Class 3 Data
06,07,08
70
File Identifier
80
Internal Indications
00,
Qual
Codes
(hex)
Func
Codes
(dec)
index=7
81
Storage Object
82
Device Profile
83
83
90
Application Identifier
100
100
100
101
101
101
13
No object
23
(see
4.14)
Qual
Codes
(hex)
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.
Table 2.3-1 Level 2 Implementation (DNP-L2)
OBJECT
RESPONSE
(master must parse)
Obj
Var
Binary Input
129, 130
00, 01
129, 130
00, 01
06,07,08
06,07,08
129, 130
17, 28
06,07,08
129, 130
17, 28
06,07,08
129, 130
17, 28
10
06
10
Binary Output
10
129, 130
00, 01
12
12
129
echo of
request
12
12
Pattern Mask
20
20
129, 130
00, 01
20
129, 130
00, 01
20
129, 130
00, 01
20
129, 130
00, 01
20
129, 130
00, 01
20
129, 130
00, 01
20
129, 130
00 ,01
20
129, 130
00 ,01
21
21
129, 130
00, 01
21
129, 130
00, 01
Description
REQUEST
(slave must parse)
Func
Codes
(dec)
1
Qual
Codes
(hex)
Qual
Codes
(hex)
06
3, 4, 5,
6
17, 28
1, 7, 8,
9, 10
06
Func
Codes
06
OBJECT
Description
REQUEST
RESPONSE
Obj
Var
21
21
21
21
21
21
21
129, 130
00, 01
21
10
129, 130
00, 01
21
11
21
12
22
22
129, 130
17, 28
22
129, 130
17, 28
22
22
22
22
22
22
23
23
23
23
23
23
23
23
23
30
30
129, 130
00, 01
30
129, 130
00, 01
30
129, 130
00, 01
30
129, 130
00, 01
Func
Codes
(dec)
Qual
Codes
(hex)
Func
Codes
Qual
Codes
(hex)
06,07,08
06
OBJECT
Description
REQUEST
RESPONSE
Obj
Var
31
31
31
31
31
31
31
32
32
129, 130
17,28
32
129, 130
17,28
32
32
33
33
33
33
33
40
40
40
129, 130
00, 01
41
41
41
129
echo of
request
50
50
129, 130
07,
50
51
51
Func
Codes
(dec)
Qual
Codes
(hex)
Func
Codes
Qual
Codes
(hex)
06,07,08
06
3, 4, 5,
6
17, 28
2 (see
4.14)
07,
quantity=1
quantity=1
51
129, 130
07,
quantity=1
52
52
129
07,
quantity=1
REQUEST
RESPONSE
OBJECT
Obj
Var
52
Description
Func
Codes
(dec)
Qual
Codes
(hex)
Func
Codes
129
Qual
Codes
(hex)
07,
quantity=1
60
60
Class 0 Data
06
60
Class 1 Data
06,07,08
60
Class 2 Data
06,07,08
60
Class 3 Data
06,07,08
70
File Identifier
80
Internal Indications
00,
index=7
81
Storage Object
82
Device Profile
83
83
90
Application Identifier
100
100
100
101
101
101
13
No Object
23
(see
4.14)
RESPONSE
OBJECT
Obj
Var
1, 22
00, 01, 06
Binary Input
00, 01, 06
129, 130
00, 01
00, 01 06
129, 130
00, 01
06,07,08
06,07,08
129, 130
17, 28
06,07,08
129, 130
17, 28
06,07,08
129, 130
17, 28
10
00, 01, 06
10
Binary Output
10
00, 01, 06
129, 130
00, 01
12
12
3, 4, 5,
6
17, 28
129
echo of
request
12
5, 6
17, 28
129
echo of
request
12
Pattern Mask
5, 6
00, 01
129
echo of
request
20
1, 7, 8,
9, 10,
22
00, 01, 06
20
00, 01, 06
129, 130
00, 01
20
00, 01, 06
129, 130
00, 01
20
00, 01, 06
129, 130
00, 01
20
00, 01, 06
129, 130
00, 01
Description
Func
Codes
(dec)
Qual
Codes
(hex)
Func
Codes
Qual
Codes
(hex)
REQUEST
RESPONSE
OBJECT
Obj
Var
Description
20
20
20
Func
Codes
(dec)
Qual
Codes
(hex)
Func
Codes
00, 01, 06
129, 130
00, 01
00, 01, 06
129, 130
00, 01
00, 01, 06
129, 130
00, 01
20
00, 01, 06
129, 130
00, 01
21
1, 22
00, 01, 06
21
00, 01, 06
129, 130
00, 01
21
00, 01, 06
129, 130
00, 01
21
00, 01, 06
129, 130
00, 01
21
00, 01, 06
129, 130
00, 01
21
21
21
21
21
00, 01, 06
129, 130
00, 01
21
10
00, 01, 06
129, 130
00, 01
21
11
21
12
22
06,07,08
22
06,07,08
129, 130
17, 28
22
06,07,08
129, 130
17, 28
22
06,07,08
129, 130
17, 28
22
06,07,08
129, 130
17, 28
22
22
22
22
23
06,07,08
23
06,07,08
129, 130
17, 28
23
06,07,08
129, 130
17,28
23
06,07,08
129, 130
17, 28
23
06,07,08
129, 130
17, 28
23
23
Qual
Codes
(hex)
REQUEST
RESPONSE
OBJECT
Obj
Var
Description
Func
Codes
(dec)
23
23
30
1, 22
00, 01, 06
30
00, 01, 06
129, 130
00, 01
30
00, 01, 06
129, 130
00, 01
30
00, 01, 06
129, 130
00, 01
30
00, 01, 06
129, 130
00, 01
31
31
31
31
31
31
31
32
06,07,08
32
06,07,08
129, 130
17, 28
32
06,07,08
129, 130
17, 28
32
32
33
33
33
33
33
40
00, 01, 06
40
00, 01, 06
129, 130
00, 01
40
00, 01, 06
129, 130
00, 01
41
3, 4, 5,
6
17, 28
129
echo of
request
41
3, 4, 5,
6
17, 28
129
echo of
request
50
50
2 (see
4.14)
07,
07,
129
07,
Qual
Codes
(hex)
Qual
Codes
(hex)
quantity = 1
tit
Func
Codes
tit
OBJECT
Obj
Var
Description
REQUEST
RESPONSE
Func
Codes
(dec)
Qual
Codes
(hex)
Func
Codes
quantity = 1
50
51
51
Qual
Codes
(hex)
quantity=1
129, 130
07,
quantity=1
51
129, 130
07,
quantity=1
52
52
129
07,
quantity=1
52
129
07,
quantity=1
60
Not Defined
60
Class 0 Data
06
60
Class 1 Data
06,07,08
20, 21,
22
06
06,07,08
20, 21
22
06
06,07,08
20, 21
22
06
00, 01
60
60
Class 2 Data
Class 3 Data
70
File Identifier
80
Internal Indications
00,
index=7
81
Storage Object
82
Device Profile
83
83
90
Application Identifier
100
100
100
101
101
REQUEST
RESPONSE
OBJECT
Obj
Var
101
Description
Func
Codes
(dec)
Qual
Codes
(hex)
Func
Codes
Qual
Codes
(hex)
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.1 Rules
A Slave device may respond to Master requests as described in Table 4.11 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
OBJECT
UNKNOWN
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
Null Response
(no IIN bits set,
but no objects
of the
specified type
returned)
n/a
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.
2
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.
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:
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 Slaves 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).
4
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-byException 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.
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
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).
Slave devices implementing Level 2 or greater may report static data objects
in unsolicited responses. They may do so only under the following
conditions:
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.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.
NOTE:
Control Relay Output Block object index x and
Binary Output object index x both refer to the same physical
binary output point.
4.6.2 Recommendations
It is recommended that the maximum size of a fragment be configurable in
both Slave devices and Master devices.
Class 0 data
Class 1 data
Binary Counter - All Variations
Binary Input Change With Time, quantity 20
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.
10
when a particular IIN or status flag must be acted upon by the Master,
e.g. Roll-Over or Buffer Overflow.
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.
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.
11
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: WithFlag and Without-Flag Variations. However, the chosen
variation must be the size the Master requested.
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.
12
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 OverRange 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)
8 bits
12 bits
16 bits
32 bits
Measured Value
Response to a
Request for 16-bit
Analog Inputs
Response to a
Request for 32-bit
Analog Inputs
> +127
007F
0000007F
< -128
FF80
FFFFFF80
> +2047
07FF
000007FF
< -2048
F800
FFFFF800
> +32767
7FFF
00007FFF
< -32768
8000
FFFF8000
> +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.
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.
13
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.
2.
The Device Profile Document for a Slave device must identify the
point at which the Slave devices 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.
14
only a time-tagged event object, i.e. either Binary Input Change With
Time or Binary Input Change With Relative Time.
both a Binary Input Change Without Time object and one of the timetagged 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.
15
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.
16
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.
The Slave device must be able to parse all Master requests defined
for Level X.
The Slave device must obey all of the implementation rules defined
in Chapter 4.
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.
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:
This appendix describes the minimum information that a vendor must include
in the Device Profile Document.
Implementation
Table
Obj
Var
30
REQUEST
Description
RESPONSE
Func
Codes
Qual
Codes
(hex)
Func
Codes
Qual
Codes
(hex)
00, 01, 06
129, 130
01
......
Description
Obj
Var
Desc
O
b
j
Var
Class
Point Name
Desc
Binary Input
No Status
Without
Time
Analog Input
30
32-bit
3
2
32-Bit
Without
Time
Phase 1 VARs
Vendor Name
Device Name
Device Function
Notable Additions
The largest size of Data Link Frame the device transmits, in octets.
Maximum Fragment
Size
Re-tries
Maximum
Application Re-tries
Requires Application Whether the device ever sends application layer messages with the
Confirmation
CONFIRM bit set in the APPLICATION CONTROL field.
Timeouts
Control Operations
Reports Binary Input A description of what variation of objects a Slave device reports
Change Events
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 static data
(Class 0) as unsolicited responses.
Default Counter
Object/Variation
Counters Rollover
At
The value at which a Slave devices counters roll over. See subset
document section 4.11.3.
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:
Device Function:
# Master
For Requests
# Slave
For Responses
Notable objects, functions, and/or qualifiers supported in addition to the Highest DNP Levels Supported
(the complete list is described in the attached table):
(must be 292)
Received
# None
# None
# None
# None
# Fixed at _________
# Fixed at _________
# Fixed at _________
# Fixed at _________
# Variable
# Variable
# Variable
# Variable
# Configurable
# Configurable
# Configurable
# 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
Pulse On
Pulse Off
Latch On
Latch Off
# Never
# Never
# Never
# Never
# Never
# Always
# Always
# Always
# Always
# Always
# Sometimes
# Sometimes
# Sometimes
# Sometimes
# Sometimes
# Configurable
# Configurable
# Configurable
# Configurable
# Configurable
Queue
Clear Queue
# Never
# Never
# Always
# Always
# Sometimes
# Sometimes
# Configurable
# Configurable
# ENABLE/DISABLE UNSOLICITED
Function codes supported
Default Counter Object/Variation:
# No Counters Reported
# Configurable (attach explanation)
# Default Object ______________
Default Variation
______________
# Point-by-point list attached
GLOSSARY OF TERMS
application
Binary
Bit
Master
Non-volatile
random-access memory
Random-access memory
Sequence of events
LIST OF ACRONYMS
AND ABBREVIATIONS
DNP
IED
NVRAM
OSI
RAM
random-access memory
RTU
SOE
sequence of events
10
Version 1.0
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
ii
Contents
1
2
3
5
6
Overview...............................................................................................................................................................1
1.1
Purpose ..........................................................................................................................................................1
1.2
Notes..............................................................................................................................................................1
1.3
Protocol Stack................................................................................................................................................1
1.4
Conclusions ...................................................................................................................................................2
Physical, Link, and Network layers ...................................................................................................................3
2.1
Physical and Link layers................................................................................................................................3
2.2
Network layer ................................................................................................................................................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
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
Security...............................................................................................................................................................11
Time Sync ...........................................................................................................................................................11
6.1
Desired Behavior .........................................................................................................................................12
6.2
Procedure.....................................................................................................................................................12
6.3
Driver requirement ......................................................................................................................................13
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
References ..........................................................................................................................................................18
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. RS232) 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.).
Station 1
Station 2
DNP Application
APDU
APDU
DNP Transport
TPDU
TPDU
LPDU
LPDU
TCP,UDP
Transport
Transport
IP
Network
Network
Link
Link
device driver/link
DNP Protocol
TCP/IP Protocol
Suite
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.
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.
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.
Network A
Control
Center LAN
Master station
Master station
Server
Serial Link:
Dedicated
Radio
Dial-up
etc.
RTU/Data
Concentrator
Substation
LAN
Ethernet
Relays
Meters
Other
IEDs
Control
Center LAN
Master station
Master station
Master station
Server
Server
Serial Link:
Dedicated
Radio
Dial-up
etc.
RTU/Data
Concentrator
Substation
LAN
Ethernet
Relays
Meters
Other
IEDs
Network B
To other parts of
enterprise network
Enterprise
WAN
Gateways
PCs/Workstations
Control
Center LAN
Router
Master stations
Servers
PPP
Remote workstation
Fiber
PPP
Digital
etc.
Substation
LAN
Router
RTU/Data
Concentrator
Ethernet
Relays
Other
IEDs
Meters
Enterprise
WAN
Gateways
PCs/Workstations
Control
Center LAN
Router
Master stations
Servers
PPP
Remote workstation
Fiber
PPP
Digital
etc.
Substation
LAN
Router
RTU/Data
Concentrator
Ethernet
Relays
Other
IEDs
Meters
Network C
To other parts of
enterprise network
Enterprise
WAN
Gateways
PCs/Workstations
Control
Center LAN
Master stations
Router
Servers
PPP
Data
Acquisition
Unit
Remote workstation
Router
Serial Link:
Dedicated
Radio
Dial-up
etc.
Router
Remote
LAN
Ethernet
Relays
Other
IEDs
Meters
Enterprise
WAN
Gateways
PCs/Workstations
Control
Center LAN
Router
Master stations
Servers
PPP
Data
Acquisition
Unit
Remote workstation
Router
Serial Link:
Dedicated
Radio
Dial-up
etc.
Router
Remote
LAN
Ethernet
Relays
Other
IEDs
Meters
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.
TCP
Most situations
requiring point to point
communications
Mesh topology WAN
UDP
Broadcast on a LAN
Equivalent to TCP on high-reliability
single-segment LAN
More economical for pay-per-byte, nonmesh WAN, e.g. Cellular Digital Packet
Data (CDPD).
Low priority data, e.g. data monitor or
configuration
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].
10
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
6.2 Procedure
1.
2.
3.
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).
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.
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
Master Station
Outstation
Time
LAN Media
MS_Time_DNP
OS_Time
DNP
Null Response
OS_Time_DNP
internet stack
Record Current
Time (FC 24)
internet stack
DNP
MS_Time
Calculate offset
offset = value in Time & Date Obj minus time when Record Current
Time Obj received
Desired case
offset = MS_Time - OS_Time
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
RTU/IED
Logical
RTU(s)
Logical
RTU(s)
Master Station A
DNP
Communication
Object
DNP
Communication
Object
DNP
Communication
Object
RS232
RS232
RS232
Dedicated line
Radio
Dial-up
etc.
Master Station B
DNP
Communication
Object
Serial Port Driver
RS232
Dedicated line
Radio
Dial-up
etc.
14
Master Station A
Logical
RTU(s)
DNP
Communication
Object
DNP
Communication
Object
Socket A
Socket B
DNP
Communication
Object
IP/Ethernet driver
Socket A
IP/Ethernet driver
Ethernet
Ethernet
Master Station B
Hub
DNP
Communication
Object
Socket B
IP/Ethernet driver
Ethernet
15
16
Internet Protocol
Physical and
Link Layers
Ethernet
Connection requests
TCP Data
Server-side
socket driver
DNP
communication
object
Logical
RTU(s)
TCP Data
Server-side
socket driver
DNP
communication
object
Logical
RTU(s)
Client-side socket
driver
DNP
communication
object
Logical
RTU(s)
DNP
communication
object
Logical
RTU(s)
Connection request
TCP Data
UDP Router
- to all ports
UDP Datagrams
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
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.
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
20
Delay Measurement
24
Reserved
25-120
FC = 24
21
Absolute Time
15
14
13
12
11
10
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
Narrative:
Absolute Time is recorded as milliseconds since midnight, January 1st, 1970, at zero hours, zero minutes, zero
seconds, and milliseconds.
22
Discussion:
There are two common time bases used by master stations when transmitting time synchronization
messages to remote devices: UTC and local time. Local time refers to time at the master and/or outstation
sites. In some systems this may span multiple time zones. Whichever time base is used, all devices
controlled by a single master are typically synchronized to, or adjusted for the same time, allowing system
wide correlation of event time tags.
UTC has an advantage in that it provides a constant time base, not modified by summer (daylights saving)
time adjustment, and the same time would be reported for common events occurring simultaneously at
outstations located in multiple time zones. This may or may not be true of the corresponding local time
base. UTC is widely used and could be converted to local time by software in field devices; or master
stations could convert from local time to UTC in a manner similar to the way multiple time zones are
handled.
Sending UTC to a device which does not support converting to local time for local displays and
applications may be a problem for the equipment users. This is because locally generated reports and time
displayed data will be in UTC instead of local time. Displayed data may not be meaningful to the user. It
may be confusing to field operation people when the time information presented on an intelligent electronic
devices (IEDs) LCD is not local time. Also there may be application programs which are time-of-day
dependent. These applications will not operate correctly unless allowance is made for the UTC to local time
offset. Local time may be a better choice for devices which do not support converting UTC to local time.
Because devices may have been designed to use different time base standards, the system implementer
must take care in matching the master station with outstation equipment. Master stations may need to
support both UTC and local time bases for the foreseeable future. It is anticipated the UTC will become the
preferred time base and it is recommended that new devices should support a UTC time base.
Resolution:
The time base used in synchronization requests remains an application decision to be based upon system
issues. At this time, DNP3 does not make a recommendation regarding time base selection.
Device vendors should design for the usage of a UTC time base in future products. Universal support of the
UTC time base will ease integration issues for the system implementer.
Affected Documentation:
The following text is to be inserted into the Application Layer documentation.
Time Base
DNP3 does not specify which time base to use in a system or a device: Coordinated Universal Time (UTC)
or local time, with or without daylight savings (summer) time. However, the system architect should keep
in mind several DNP3-related considerations when selecting the time base.
DNP3 requires transmission of events in the order in which they occurred. Therefore, it is
15 January 2004
Page 1 of 2
TB2004-001 Synchronization Time Base
desirable to use a time base that is constant throughout the system, or at least permits easy
reconciliation of dissimilar time bases. This is especially important when a data concentrator or a
master station needs to time sequence events from various sources, some of which may
communicate using a non-DNP3 protocol.
It is desirable to choose a time base that does not shift with daylight savings (summer) time
because events that occur immediately after the bi-annual time change, but before the device is
time synchronized, will be erroneously sequenced with other events that are properly time tagged.
Consideration should be given before forcing an IED or data concentrator to compensate for the
exact time when daylight savings (summer) time starts and ends as this can put an undue burden
on the device.
It is often desirable and/or necessary to provide a local time source (e.g. IRIG-B or GPS) at a
device. A device may or may not be able to shift the time by a fixed hourly amount if required to
coordinate time stamping of DNP events with a different time base.
Outstation devices that execute application programs requiring actions to occur at specific times of
the day can increase software complexity when the application time base is different from that
used to report events to the master station. Similarly, a local display may need to show adjusted
time values from the time stamps in buffered events.
Device vendors should design for a UTC time base in new products. At some unspecified future
time, it is anticipated that a UTC time base will be preferred.
Tip
Last Updated:
15 January 2004
Status:
Initial submittal
15 January 2004
Page 2 of 2
TB2004-001 Synchronization Time Base
Resolution:
Remove the incorrect error code in 8.2.1.2.13, Step 8. Flag update for next revision of procedures.
Affected Documentation:
DNP3-2003, Intelligent Electronic Device (IED) Certification Procedure, Subset Level 1
DNP3-2003, Intelligent Electronic Device (IED) Certification Procedure, Subset Level 2
Changes to the Subset Level 1 and 2 Certification Procedures:
Current procedure in version 2.3:
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 with a status code value of 2 (NO
MATCHING SELECT).
9. Verify that the DUT does not operate the binary output.
Corrected procedure (same as version 2.2):
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.
Last Updated:
February 5, 2004
Status:
Approved by Technical Committee.
Issue:
There is a need, using the DNP3 Protocol, to electronically read various outstation features and attributes
in order to simplify the burden of configuring master stations. Ideally, when either a master or outstation
starts up, the master can ask for information from the outstation and then perform self-configuration.
Another goal is to negotiate fragment sizes without the need for configuration.
2 Resolution:
All vendors are encouraged to implement device attributes functionality as described herein. While not
mandatory at this time, it is possible that in the future, all devices will be required to support this feature.
Attributes characterizing an outstations features are conveyed using DNP3 objects as described below.
2.1
Group 0, Point 0
DNP3 object group 0 is assigned to the outstation device. Initially, only a single index, 0, is permitted.
2.2
Variations
Variation 255 is used to request a list of the attribute variation numbers supported by an outstation.
Variation 254 is used to request all of the attribute objects from an outstation in a single response.
Variations 1 through 253 are pre-assigned or reserved for assignment by the DNP Users Group. In the
future, a set of variation numbers may be set aside for private, vendor or user-specific attributes, but not at
this time.
Every attribute object, except variations 254 and 255, has a data type code, length and value. The data
type code and length provide keys for master and outstation devices to interpret the value. The value is
self-explanatory.
2.3
Function codes
All attribute variations are readable from a master by using a read request, function code 1 (READ).
Variations 254, 255, and many others cannot be written, but some variations may optionally be writable
depending upon the outstation capabilities. Function code 2 (WRITE) is used for the write requests.
8 April 2003
Device Attributes
2.4
All attribute objects, except variations 254 and 255, are read or written (function codes READ and
WRITE) using a type, length and value format.
2.4.1
Pictorial
octet transmission order
bit position
2.4.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code as described in paragraph 2.4.3.
UINT8: Length.
Specifies the number of octets, n, required to convey the attribute value that follows.
Variation specific: Attribute value
Encoding of the attribute value is dependent upon the variations data type code. If more
than one octet is required for a numeric formatted attribute, the least significant octet is
transmitted first. The number of octets in this field is specified by the length field.
2.4.3
Every attribute value is constructed according to one of the following attribute data type codes.
Table 2.41 Attribute Data Type Codes
Code
1.
2.
3.
4.
5.
6.
Code Name
VSTR
UINT
INT
FLT
OSTR
BSTR
Description
Visible characters suitable for print and display.
Unsigned integer.
Signed integer.
Floating-point.
Octet string.
Bit string.
Attribute data type codes do not specify the number of octets required to convey the attribute value. The
second octet in a DNP3 attribute object always specifies the number of octets. For example, an outstation
would most likely report an unsigned integer with 1, 2 or 4 octets.
Floating-point types are limited to 4 bytes and 8 bytes for transporting 32-bit and 64-bit floating point
values. No other sizes are acceptable.
The bit alignment in bit string types requires the first bit to appear in bit 0 of the first byte of the attribute
value.
8 April 2003
Device Attributes
2.5
Reading attributes
This example shows a request to read the maximum receive fragment size in the
outstation.
Request Message
C3
AC
01
FC
00
Grp
F2
Var
00
Qual
00
00
0
Grp
F2
Var
Range
81
FC
00
IIN1
00
IIN2
00
Qual
00
00
Range
02
02
05
The response contains a single object. Observe that the first octet specifies the data type (2, unsigned
integer); the second octet specifies the number of octets (2) in the actual attribute value (0x05DC)
reported by the next two octets. The receive fragment size was reported as being 1500 octets.
2.6
2.6.1
Variation 255
Variation 255 has special meaning. It is used to retrieve a list of all of the attribute variation numbers, and
the properties of those attribute variations, supported by the outstation. This object has a variable length
that depends upon the count of attribute variations supported by the outstation. The list does not include
variations 254 and 255.
2.6.2
The master issues a read request, using the READ function code for object group 0, variation
255, from index 0. Note: Qualifier 0x06 may be used instead of specifying an index of 0
because only a single index is permitted at this time.
2.
The outstation responds with a list of the device attribute variations, and the properties of those
attribute variations, that it supports. The response uses qualifier code 0x5B and the 1-octet range
field holds a count of 1.
2.6.3
Example
E
8 April 2003
This example shows a request to read a list of attribute variations from the outstation.
The outstation in this example supports 26 different device attribute variations: 217 to
233, 237 to 241, 248 to 250 and 252.
3
Device Attributes
Request Message
C3
AC
01
FC
00
Grp
FF
Var
00
Qual
00
00
00
Grp
FF
Var
Range
81
FC
00
IIN1
00
IIN2
5B
Qual
01
Range
34
00
D9
Prefix
DA
00
DB
00
DC
00
DD
Attribute variation numbers list
00
DE
00
E3
00
E4
00
E9
00
F1
00
F8
00
E0
00
E1
00
E2
00
Attribute variation numbers list
E5
00
E6
00
E7
00
E8
Attribute variation numbers list
00
EE
00
EF
00
F0
01
Attribute variation numbers list
F9
00
FA
00
FC
00
Note that variations 254 (0xFE) and 255 (0xFF) are not included in the list. Also notice that attribute 240
(0xF0), Maximum Transmit Fragment Size, is writable and all others are not.
2.7
There are two methods to read all of the attributes associated with a single point.
2.7.1
The specific variation approach requires the master to know which attributes are available first. To find
out, the master sends a request for a list of attributes using variation 255 in the request as described in
paragraph 2.6.
The second step requires the master to construct a request containing one object header in the request for
each attribute it desires in the response. This method can cause a lengthy request message but does not
affect the response length.
As an example, suppose an outstation supports variations 221, 224, 229, 233 and 239. The request would
include 5 object headers:
1. Group 0, variation 0xDD, qualifier 0x00 and range 0x00, 0x00.
8 April 2003
Device Attributes
The non-specific variation approach requires the master to construct a request containing a single object
header having variation 254:
1. Group 0, variation 0xFE, qualifier 0x00 and range 0x00, 0x00.
The master can then choose from the attribute objects returned in the response any, or all of those
attributes for which it has an interest.
2.8
Writing attributes
Those attributes in an outstation that are writable can be set from the master station.
To determine which of the attributes are writable, the master must first send a request for a list of
attributes using variation 255 in the request as described in paragraph 2.6. Only those attributes in the
returned list with the writable property bit set can be written; all others cannot.
The objects in a write message are formatted according to paragraph 2.4.
The allowed values that may be written to numeric-valued attributes are not specified unless limits appear
in the descriptions in the DNP3 Data Object Library. Vendors may limit the range to values suitable for
their device. If a master writes a value that is unacceptable to the outstation, the outstation must not
change its existing attribute value, and the internal indications bit IIN2.2 [PARAMETER_ERROR] must
be set in the response.
Vendors are not required to store attribute values in non-volatile memory. Therefore, attributes that were
written by the master are not guaranteed to retain their values after a reset of any kind and for any reason.
1. Affected Documentation:
The Application Layer document is updated to include a description of attributes.
The following insert sheets are added to the DNP3 Object Library. Copies are attached to this Technical
Bulletin.
8 April 2003
Device Attributes
Object
Group Variation
0
1
0
0
216
0
217
0
218
0
219
0
220
0
221
0
222
0
223
0
224
0
225
0
226
0
227
0
228
0
229
0
230
0
231
0
232
0
233
0
234
0
235
0
236
0
237
0
238
0
239
0
240
0
241
0
242
0
243
0
244
0
245
0
246
0
247
0
248
0
249
0
250
0
251
0
252
0
253
0
254
0
255
Description
Reserved
Reserved
Max number of binary outputs from object group 12 per request.
Local timing accuracy.
Duration of time accuracy (followin a time synchronization).
Analog output events supported.
Maximum analog output index.
Number of analog output points.
Binary output events supported.
Maximum binary output index.
Number of binary output points.
Frozen counter events supported.
Frozen counts supported.
Counter events supported.
Maximum counter index.
Number of counter points.
Frozen analog inputs supported.
Analog input events supported.
Maximum analog input index.
Number of analog input points.
Double-bit binary input events supported.
Maximum number of double-bit binary input index.
Number of double-bit binary input points.
Binary input events supported.
Maximum binary input index.
Number of binary input points.
Maximum transmit fragment size.
Maximum receive fragment size.
Device manufacturers software version string.
Device manufacturers hardware version string.
Reserved.
User-assigned location name or code string.
User-assigned ID code/number string.
User-assigned name string for the outstation.
Device serial number string.
DNP subset level and conformance.
Device manufacturers product name and model.
Reserved for device manufacturers registered DNP device code.
Device manufacturers name string.
Reserved for retrieval of attribute names.
Special variation for requesting return of all attributes.
Special variation for requesting list of attributes.
DNPObjLibIns_G00_V216
DNPObjLibIns_G00_V217
DNPObjLibIns_G00_V218
DNPObjLibIns_G00_V219
DNPObjLibIns_G00_V220
DNPObjLibIns_G00_V221
DNPObjLibIns_G00_V222
DNPObjLibIns_G00_V223
DNPObjLibIns_G00_V224
DNPObjLibIns_G00_V225
DNPObjLibIns_G00_V226
DNPObjLibIns_G00_V227
DNPObjLibIns_G00_V228
DNPObjLibIns_G00_V229
DNPObjLibIns_G00_V230
DNPObjLibIns_G00_V231
DNPObjLibIns_G00_V232
DNPObjLibIns_G00_V233
DNPObjLibIns_G00_V234
DNPObjLibIns_G00_V235
DNPObjLibIns_G00_V236
DNPObjLibIns_G00_V237
DNPObjLibIns_G00_V238
DNPObjLibIns_G00_V239
DNPObjLibIns_G00_V240
DNPObjLibIns_G00_V241
DNPObjLibIns_G00_V242
DNPObjLibIns_G00_V243
DNPObjLibIns_G00_V245
DNPObjLibIns_G00_V246
DNPObjLibIns_G00_V247
DNPObjLibIns_G00_V248
DNPObjLibIns_G00_V249
DNPObjLibIns_G00_V250
DNPObjLibIns_G00_V252
DNPObjLibIns_G00_V254
DNPObjLibIns_G00_V255
3. Last Updated:
8 April 2003.
8 April 2003
Device Attributes
4. Status:
Pending General Membership Approval (circa February, 2004).
8 April 2003
Device Attributes
Device Attributes
Maximum Number of Binary Output Objects Per Request
Group: 0
Variation: 216
Type: Attrib
Description:
This attribute is the maximum number of binary output objects from object group 12 that the master may
include in control messages.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the number of binary output objects field.
UINTn: Maximum number of binary output objects.
The maximum number of binary output objects from object group 12 that the master may
include in control messages.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V216
Sheet 1
Group: 0
Variation: 217
Type: Attrib
Device Attributes
Local Timing Accuracy
Description:
This attribute is the rated timing accuracy of an outstation stated in microseconds. This value applies to
the maximum error in the detection and time stamping of events when the time for those events is
determined by the outstation. It does not apply to events that are retrieved, and passed on from other
devices when the event time is determined by those other devices.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the timing accuracy microseconds field.
UINTn: Timing accuracy microseconds.
This value is defined as the maximum difference in time, stated as a positive number of
microseconds, between the time that would be given to an event by a hypothetical device
having a perfect clock with infinitesimal resolution and no detection delays and the worst
case time that the outstation could give.
Notes:
Do not confuse this attribute with timing resolution. Resolution is the smallest interval of time between
data sampling or computations or reported times. DNP3 events are reported with a time resolution of one
millisecond. An outstation, for example, might be able to detect the existence of an event every 100
microseconds, but that does not necessarily mean that its timing accuracy is 100 microseconds. This
hypothetical outstations timing accuracy could be much worse, say 20,000 microseconds.
When reporting this value, the calculations must take into consideration the drift in the devices local
clock source, the period between time synchronizations, sampling resolution and other factors.
If an outstation requires time synchronization from a master and asserts the internal indications bit IIN1.4
[NEED_TIME], the calculation shall assume that the time reported by the master is perfect. The timing
accuracy then depends upon
Version: 1.00
DNPObjLibIns_G00_V217
Sheet 1
Device Attributes
Local Timing Accuracy
Group: 0
Variation: 217
Type: Attrib
The drift in the outstations local oscillator and the period between assertions of bit IIN1.4.
How well the outstation can determine the time delay when a delay measurement (function code
23 [DELAY_MEASURE] is requested from the master.
Interrupt latency.
Filter delays.
Other factors.
If an outstation is synchronized from a local source, such as a GPS receiver, the time accuracy reported
must include the error in that product and other possible error sources such as those listed in the previous
paragraph.
Version: 1.00
DNPObjLibIns_G00_V217
Sheet 2
Group: 0
Variation: 218
Type: Attrib
Device Attributes
Duration of Time Accuracy
Description:
This attribute is the number of seconds that the device maintains its rated time accuracy following a time
synchronization from the master.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the number of seconds field.
UINTn: Number of seconds.
The number of seconds that the device maintains its rated time accuracy following a time
synchronization from the master.
If time synchronization is not required from the master, this value must be zero. This
includes devices that do not time tag events and devices that receive time from other
sources such as a GPS receiver.
If time in the device is dependent upon periodic receipt of time from the master, then this
value must be non-zero. This value must not exceed 0xFFFFFFFF.
Notes:
Rated accuracy is not defined by DNP3 as this is a vendor and application specific parameter.
Version: 1.00
DNPObjLibIns_G00_V218
Sheet 1
Group: 0
Variation: 219
Type: Attrib
Device Attributes
Support for Analog Output Events
Description:
This attribute is Boolean that indicates whether the device supports analog output events.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, INT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the analog output events field.
INTn: Analog output events.
This is a Boolean having a value of
1 if the device supports analog output events and
0 if the device does not support analog output events.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V219
Sheet 1
Group: 0
Variation: 220
Type: Attrib
Device Attributes
Maximum Analog Output Index
Description:
This attribute is maximum analog output point index controllable from the master.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the maximum analog output point index field.
UINTn: Maximum analog output point index.
The maximum analog output point index controllable from the master.
Notes:
If there are gaps in the point indexes, the number of points controllable by the master in variation 221
might not equal one more than the maximum point index.
Version: 1.00
DNPObjLibIns_G00_V220
Sheet 1
Group: 0
Variation: 221
Type: Attrib
Device Attributes
Number of Analog Outputs
Description:
This attribute is number of analog output points controllable from the master.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the number of analog output points field.
UINTn: Number of analog output points.
The number of analog output points controllable from the master.
Notes:
If there are gaps in the point indexes, the number of points controllable by the master might not equal one
more than the maximum point index in variation 220.
Version: 1.00
DNPObjLibIns_G00_V221
Sheet 1
Group: 0
Variation: 222
Type: Attrib
Device Attributes
Support for Binary Output Events
Description:
This attribute is Boolean that indicates whether the device supports binary output events.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, INT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the binary output events field.
INTn: Binary output events.
This is a Boolean having a value of
1 if the device supports binary output events and
0 if the device does not support binary output events.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V222
Sheet 1
Group: 0
Variation: 223
Type: Attrib
Device Attributes
Maximum Binary Output Index
Description:
This attribute is maximum binary output point index controllable from the master.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the maximum binary output point index field.
UINTn: Maximum binary output point index.
The maximum binary output point index controllable from the master.
Notes:
If there are gaps in the point indexes, the number of points controllable from the master in variation 224
might not equal one more than the maximum point index.
Version: 1.00
DNPObjLibIns_G00_V223
Sheet 1
Group: 0
Variation: 224
Type: Attrib
Device Attributes
Number of Binary Outputs
Description:
This attribute is number of binary output points controllable from the master.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the number of binary output points field.
UINTn: Number of binary output points.
The number of binary output points controllable from the master.
Notes:
If there are gaps in the point indexes, the number of points controllable from the master might not equal
one more than the maximum point index in variation 223.
Version: 1.00
DNPObjLibIns_G00_V224
Sheet 1
Group: 0
Variation: 225
Type: Attrib
Device Attributes
Support for Frozen Counter Events
Description:
This attribute is Boolean that indicates whether the device supports frozen counter events.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, INT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the frozen counter events field.
INTn: Frozen counter events.
This is a Boolean having a value of
1 if the device supports frozen counter events and
0 if the device does not support frozen counter events.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V225
Sheet 1
Group: 0
Variation: 226
Type: Attrib
Device Attributes
Support for Frozen Counters
Description:
This attribute is Boolean that indicates whether the device supports frozen counters.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, INT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the frozen counters field.
INTn: Frozen counters.
This is a Boolean having a value of
1 if the device supports frozen counters and
0 if the device does not support frozen counters.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V226
Sheet 1
Group: 0
Variation: 227
Type: Attrib
Device Attributes
Support for Counter Events
Description:
This attribute is Boolean that indicates whether the device supports counter events.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, INT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the counter events field.
INTn: Counter events.
This is a Boolean having a value of
1 if the device supports counter events and
0 if the device does not support counter events.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V227
Sheet 1
Group: 0
Variation: 228
Type: Attrib
Device Attributes
Maximum Counter Index
Description:
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the maximum counter point index field.
UINTn: Maximum counter point index.
The maximum counter point index reported by the device.
Notes:
If there are gaps in the point indexes, the number of points reported in variation 229 might not equal one
more than the maximum point index.
Version: 1.00
DNPObjLibIns_G00_V228
Sheet 1
Group: 0
Variation: 229
Type: Attrib
Device Attributes
Number of Counter Points
Description:
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the number of counter points field.
UINTn: Number of counter points.
The number of counter points reported by the device.
Notes:
If there are gaps in the point indexes, the number of points reported might not equal one more than the
maximum point index reported in variation 228.
Version: 1.00
DNPObjLibIns_G00_V229
Sheet 1
Group: 0
Variation: 230
Type: Attrib
Device Attributes
Support for Frozen Analog Inputs
Description:
This attribute is Boolean that indicates whether the device supports frozen analog inputs.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, INT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the frozen analog inputs field.
INTn: Frozen analog inputs.
This is a Boolean having a value of
1 if the device supports frozen analog inputs and
0 if the device does not support frozen analog inputs.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V230
Sheet 1
Group: 0
Variation: 231
Type: Attrib
Device Attributes
Support for Analog Input Events
Description:
This attribute is Boolean that indicates whether the device supports analog input events.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, INT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the analog input events field.
INTn: Analog input events.
This is a Boolean having a value of
1 if the device supports analog input events and
0 if the device does not support analog input events.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V231
Sheet 1
Group: 0
Variation: 232
Type: Attrib
Device Attributes
Maximum Analog Input Index
Description:
This attribute is maximum analog input point index reported by the device.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the maximum analog input point index field.
UINTn: Maximum analog input point index.
The maximum analog input point index reported by the device.
Notes:
If there are gaps in the point indexes, the number of points reported in variation 233 might not equal one
more than the maximum point index.
Version: 1.00
DNPObjLibIns_G00_V232
Sheet 1
Group: 0
Variation: 233
Type: Attrib
Device Attributes
Number of Analog Input Points
Description:
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the number of analog input points field.
UINTn: Number of analog input points.
The number of analog input points reported by the device.
Notes:
If there are gaps in the point indexes, the number of points reported might not equal one more than the
maximum point index reported in variation 232.
Version: 1.00
DNPObjLibIns_G00_V233
Sheet 1
Group: 0
Variation: 234
Type: Attrib
Device Attributes
Support for Double-bit Binary Input Events
Description:
This attribute is Boolean that indicates whether the device supports double-bit binary input events.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, INT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the double-bit binary input events field.
INTn: Double-bit binary input events.
This is a Boolean having a value of
1 if the device supports double-bit binary input events and
0 if the device does not support double-bit binary input events.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V234
Sheet 1
Group: 0
Variation: 235
Type: Attrib
Device Attributes
Maximum Double-bit Binary Input Index
Description:
This attribute is maximum double-bit binary input point index reported by the device.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the maximum double-bit binary input point index field.
UINTn: Maximum double-bit binary input point index.
The maximum double-bit binary input point index reported by the device.
Notes:
If there are gaps in the point indexes, the number of points reported in variation 236 might not equal one
more than the maximum point index.
Version: 1.00
DNPObjLibIns_G00_V235
Sheet 1
Group: 0
Variation: 236
Type: Attrib
Device Attributes
Number of Double-bit Binary Input Points
Description:
This attribute is number of double-bit binary input points reported by the device.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the number of double-bit binary input points field.
UINTn: Number of double-bit binary input points.
The number of double-bit binary input points reported by the device.
Notes:
If there are gaps in the point indexes, the number of points reported might not equal one more than the
maximum point index reported in variation 235.
Version: 1.00
DNPObjLibIns_G00_V236
Sheet 1
Group: 0
Variation: 237
Type: Attrib
Device Attributes
Support for Binary Input Events
Description:
This attribute is Boolean that indicates whether the device supports binary input events.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, INT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the binary input events field.
INTn: Binary input events.
This is a Boolean having a value of
1 if the device supports binary input events and
0 if the device does not support binary input events.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V237
Sheet 1
Group: 0
Variation: 238
Type: Attrib
Device Attributes
Maximum Binary Input Index
Description:
This attribute is maximum binary input point index reported by the device.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the maximum binary input point index field.
UINTn: Maximum binary input point index.
The maximum binary input point index reported by the device.
Notes:
If there are gaps in the point indexes, the number of points reported in variation 239 might not equal one
more than the maximum point index.
Version: 1.00
DNPObjLibIns_G00_V238
Sheet 1
Group: 0
Variation: 239
Type: Attrib
Device Attributes
Number of Binary Input Points
Description:
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the number of binary input points field.
UINTn: Number of binary input points.
The number of binary input points reported by the device.
Notes:
If there are gaps in the point indexes, the number of points reported might not equal one more than the
maximum point index reported in variation 238.
Version: 1.00
DNPObjLibIns_G00_V239
Sheet 1
Group: 0
Variation: 240
Type: Attrib
Device Attributes
Maximum Transmit Fragment Size
Description:
This attribute is maximum number of octets the device will transmit in an Application Layer fragment.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the maximum transmit fragment size field.
UINTn: Maximum transmit fragment size.
The maximum number of octets the device will transmit in an Application Layer
fragment.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V240
Sheet 1
Group: 0
Variation: 241
Type: Attrib
Device Attributes
Maximum Receive Fragment Size
Description:
This attribute is maximum number of octets the device will accept in a received Application Layer
fragment.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, UINT. (Refer to section 1 of the DNP3 Data Object
Library.)
UINT8: Length.
Specifies the number of octets in the maximum receive fragment size field.
UINTn: Maximum receive fragment size.
The maximum number of octets the device will accept in a received Application Layer
fragment.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V241
Sheet 1
Group: 0
Variation: 242
Type: Attrib
Device Attributes
Device Manufacturers Software Version
Description:
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, VSTR. (Refer to section 1 of the DNP3 Data
Object Library.)
UINT8: Length.
Specifies the number of octets in the manufacturers software version string.
VSTRn: Manufacturers software version string.
Code assigned by the manufacturer for the installed version of the devices software.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V242
Sheet 1
Group: 0
Variation: 243
Type: Attrib
Device Attributes
Device Manufacturers Hardware Version
Description:
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, VSTR. (Refer to section 1 of the DNP3 Data
Object Library.)
UINT8: Length.
Specifies the number of octets in the manufacturers hardware version string.
VSTRn: Manufacturers hardware version string.
Code assigned by the manufacturer for the installed version of the devices hardware.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V243
Sheet 1
Group: 0
Variation: 245
Type: Attrib
Device Attributes
User-assigned Location Name
Description:
This attribute is a name or code given to the location where the device is installed by the end user.
The contents of this attribute is a free form string that is formatted according to the users normal practice.
Three examples are
1954 Broad Street, Toora Wind Farm and Soho:Piccadilly Circus.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, VSTR. (Refer to section 1 of the DNP3 Data
Object Library.)
UINT8: Length.
Specifies the number of octets in the user-assigned location name or code.
VSTRn: User-assigned location name or code string.
Name or code for location where the device is installed. It is assigned by end user.
Notes:
It is recommended that device manufacturers provide a configurable means for the end user to locally
store a text location name or code.
If a user has a location naming convention consisting of sub-fields (like major and minor), it is
recommended that he/she choose a delimiting character (:, ~, +, etc) as a standard method to
separate the fields.
Version: 1.00
DNPObjLibIns_G00_V245
Sheet 1
Group: 0
Variation: 246
Type: Attrib
Device Attributes
User-assigned ID code/number
Description:
This attribute is a code or number given to the device by the end user.
The contents of this attribute is a free form string that is formatted according to the users normal practice.
Two examples are
4075 and 25-DS.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, VSTR. (Refer to section 1 of the DNP3 Data
Object Library.)
UINT8: Length.
Specifies the number of octets in the user-assigned device code or number.
VSTRn: User-assigned device code or number string.
Code or number of device assigned by end user.
Notes:
It is recommended that device manufacturers provide a configurable means for the end user to locally
store a text device code/number.
Version: 1.00
DNPObjLibIns_G00_V246
Sheet 1
Group: 0
Variation: 247
Type: Attrib
Device Attributes
User-assigned Device Name
Description:
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, VSTR. (Refer to section 1 of the DNP3 Data
Object Library.)
UINT8: Length.
Specifies the number of octets in the user-assigned device name.
VSTRn: User-assigned device name string.
Name of device assigned by end user.
Notes:
It is recommended that device manufacturers provide a configurable means for the end user to locally
store a text device name.
Version: 1.00
DNPObjLibIns_G00_V247
Sheet 1
Group: 0
Variation: 248
Type: Attrib
Device Attributes
Device Serial Number
Description:
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, VSTR. (Refer to section 1 of the DNP3 Data
Object Library.)
UINT8: Length.
Specifies the number of octets in the manufacturers serial number.
VSTRn: Manufacturers serial number string.
Manufactures serial number.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V248
Sheet 1
Group: 0
Variation: 249
Type: Attrib
Device Attributes
DNP Subset and Conformance
Description:
This attribute has three fields that identify the DNP subset level, a separator and the DNP3 Test Procedure
version for which the device was certified to conform to by an independent testing facility.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, VSTR. (Refer to section 1 of the DNP3 Data
Object Library.)
UINT8: Length.
Specifies the number of octets in the subset level, colon and test procedure versions.
VSTR1: Subset level.
There are 4 subset level values permitted:
ASCII 0 indicates unknown, not determined or none claimed.
ASCII 1 indicates subset level 1.
ASCII 2 indicates subset level 2.
ASCII 3 indicates subset level 3.
VSTR1: Colon.
An ASCII colon, : (binary value 0x3A). This separator is mandatory and must appear
in the attribute string.
VSTRn: Test procedure version.
DNP3 Test Procedure version for which the device was certified to conform to by an
independent testing facility. This is usually a calendar year number such as 2003.
If the device has not been tested, this field must be omitted from the object.
Version: 1.00
DNPObjLibIns_G00_V249
Sheet 1
Group: 0
Variation: 249
Type: Attrib
Device Attributes
DNP Subset and Conformance
In the future, this field may contain more characters if conformance levels are coded
differently.
Notes:
Version: 1.00
DNPObjLibIns_G00_V249
Sheet 2
Group: 0
Variation: 250
Type: Attrib
Device Attributes
Device Manufacturers Product Name and Model
Description:
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, VSTR. (Refer to section 1 of the DNP3 Data
Object Library.)
UINT8: Length.
Specifies the number of octets in the manufacturers product name and model.
VSTRn: Manufacturers product name and model string.
Manufactures product name and model.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V250
Sheet 1
Group: 0
Variation: 252
Type: Attrib
Device Attributes
Device Manufacturers Name
Description:
This attribute is the name of the device manufacturer. An example is 123 SCADA, Ltd.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
UINT8: Attribute data type code.
Specifies the attribute data type code, VSTR. (Refer to section 1 of the DNP3 Data
Object Library.)
UINT8: Length.
Specifies the number of octets in the manufacturers name.
VSTRn: Manufacturers name string.
Manufactures name.
Notes:
None.
Version: 1.00
DNPObjLibIns_G00_V252
Sheet 1
Group: 0
Variation: 254
Type: Attrib
Device Attributes
Non-Specific All Attributes Request
Description:
This attribute is used as a shorthand to request an outstation to return all of its attributes in a single
response. The master sends a single object header with this variation in lieu of including a possibly length
list of object headers in the request.
Coding:
Notes:
This variation may only appear in a master request. It must not be used in responses from outstations.
Requests from a master use group 0, variation 254, qualifier code
0x06.
Version: 1.00
DNPObjLibIns_G00_V254
Sheet 1
Group: 0
Variation: 255
Type: Attrib
Device Attributes
List of Attribute Variations
Description:
This is a special attribute number that is used to retrieve a list of all of the device attribute variation
numbers, and the properties of those attributes, supported by the outstation. This object has a variable
length that depends upon the count of attribute variations supported by the outstation.
Coding:
2.1
Pictorial
octet transmission order
bit position
2.2
Formal structure
SET of n
{
UINT8: Attribute variation number.
The number of an attribute variation that is supported in the device.
BSTR8: Attribute Properties.
Bit 0 indicates whether the device attribute is writable by the master. If the bit is set, the
master can change the respective attribute by sending a request message having function
code [WRITE].
Bits 1 through 7 are reserved.
}
where n is the number of device attribute variations supported by the outstation.
Notes:
0x06.
Responses from an outstation use group 0, variation 255, qualifier code 0x5B and a range field with a
count of 1 object.
Version: 1.00
DNPObjLibIns_G00_V255
Sheet 1
Group: 0
Variation: 255
Type: Attrib
Device Attributes
List of Attribute Variations
Version: 1.00
DNPObjLibIns_G00_V255
Sheet 2
Background:
Resolution:
The purposes and meanings of DNP3 Object Flags are defined below.
In the following descriptions:
An originating device is one that gathers field data directly (for inputs) or issues controls directly to the
field (for outputs).
A non-originating device is one that obtains data (for inputs) via a communications link to another device
or issues control commands (for outputs) via a communications link to another device.
A reporting device is a device that acts as a DNP3 outstation, sending DNP3 messages to a master device.
Data from an originating device may arrive at the master via one or more data concentrator devices. In this
case each device in the communications chain other than the master is a reporting device. This identification of
various devices is illustrated below in Figure 1. The terms upstream and downstream used to identify device
hierarchy are also shown in this diagram.
Reporting
devices
Communication
Link
Master
NonOriginating
Device
NonOriginating
Device
Upstream devices
Originating
Device
Field I/O
Downstream devices
Figure 1
The flag bits for each object group are described in Table 1 below. The ONLINE, RESTART, COMM_LOST,
REMOTE_FORCED and LOCAL_FORCED flags are common to all object group types that contain flags. The
other flags are specific to particular object groups as identified below.
Non-originating devices always pass flags through unchanged unless indicated below.
Each flag is set (has the value 1) when active and is clear (has the value 0) when inactive.
Page 1 of 8
11 June 2003
Description
ONLINE
RESTART
The RESTART flag indicates that the data has not been updated
from the field since device reset.
Originating devices shall set this bit immediately upon resetting and
keep the bit set until they place a non-default value into their
database.
Non-originating devices shall set this bit immediately upon restart
and keep the bit set until it is overwritten by collecting data from a
reporting device.
For input data objects:
If set, the object is in the initialization state, having a value that has
never been updated from the field since restart. The bit is cleared
when the object is first updated. In an originating device this is
when the field value is first written. In a non-originating device the
bit remains set until it is overwritten by collecting data from a
reporting device.
For output status objects:
The RESTART flag shall only be set while a device is restarting. In
an originating device the flag shall be cleared after the device is
available to accept commands, irrespective of whether or not an
output value (control) has been sent to the output object. In a nonoriginating device the bit remains set until it is overwritten by
collecting output status information from a reporting device.
Page 2 of 8
11 June 2003
Flag Function
Description
COMM_LOST
REMOTE_FORCED
Nonoriginating
Device
See Note 2.
LOCAL_FORCED
If set, the data value is overridden in the device that is reporting this
flag as set. This may be due to the device operating in a diagnostic
or temporary mode or due to human intervention.
Reported Value Y with
LOCAL_FORCED set
Device in
which value is
overridden to Y
Input
Value
X
Device in
which value is
overridden to Y
See Note 2.
Page 3 of 8
11 June 2003
Flag Function
Description
CHATTER_FILTER
ROLLOVER
OVER_RANGE
DISCONTINUITY
Page 4 of 8
11 June 2003
Flag Function
Description
REFERENCE_ERR
STATE
Note 1:
Note 2:
Note 3:
Page 5 of 8
11 June 2003
FFFF hex), then the outstation reports the value as either 2147483648 or
2147483647. The outstation sets the OVER_RANGE flag of the object.
4. If an input exceeds the range measurable by the hardware on the outstation,
the outstation sets the OVER_RANGE flag of the object. It does not alter
the value reported by its hardware. For example, an outstation with a 12-bit
A/D converter must set OVER_RANGE when the measured value exceeds
2047. The outstation must still report the value as 2047 in the analog input
object.
These rules are illustrated in Table 2 below. The Slave sets the OVER_RANGE
flag in each case in Table 2, except the example of 33000 requested as a 32-Bit
Analog Input. This is a case of Rule #2 applying, but not Rule #3.
Table 2 Setting of OVER_RANGE Flag
Size Stored Internally
by the Device (size of
A/D convertor)
8 bits signed
8 bits unsigned
12 bits signed
16 bits signed
32 bits signed
Response to a
Request for 16-bit
Analog Inputs
Response to a
Request for 32-bit
Analog Inputs
> +127
007F
0000007F
< -128
FF80
FFFFFF80
> +255
00FF
000000FF
Measured Value
<0
0000
00000000
> +2047
07FF
000007FF
< -2048
F800
FFFFF800
> +32767
7FFF
00007FFF
< -32768
8000
FFFF8000
> +2147483647
7FFF
7FFFFFFF
33000 (example)
7FFF
00080E8 *
< -2147483648
8000
80000000
* OVER_RANGE is not set in this case. OVER_RANGE is set in all other cases.
Notes: In some devices, native analog ranges of less than 16-bits are normalized to fit into a 16-bit range and
the measured value is scaled prior to being reported. For example: a 12-bit A/D convertor could be
scaled by multiplying the output value by 16 to report values in the range 32768 to 32752 (8000
7FF0) with steps of 16 between adjacent contiguous values.
In such cases, the scaling used will provide some particular values for the full-scale or maximum
positive and negative readings. If the converted input quantity exceeds the full-scale value, the full-scale
value is reported and the OVER_RANGE flag is set.
Interaction or Combinations of Flags:
Each flag indicates a separate condition. The setting or clearing of a flag does not necessarily cause other
flags to set or clear. In particular: Clearing of the ONLINE flag shall not require that any other flag needs to
be set.
The COMM_LOST flag indicates that communication has failed somewhere in the downstream path. This
flag can only be set by a non-originating device. The reporting device shall not alter the object value or any
other flag received from a downstream device if the communication is lost, except that the ONLINE flag
may optionally be cleared. Thus the value and other flags indicate the state of the input or output point when
data was last collected prior to communication failure. A data object with the COMM_LOST flag set can be
used as an indication of the last known value of the input or output if the other exception condition flags are
not set.
Page 6 of 8
11 June 2003
The REMOTE_FORCED and LOCAL_FORCED flags indicate an override state of the data. The state of
these flags shall not affect or alter the state of any other flag. In particular, the setting of these flags shall not
clear the ONLINE flag or set the RESTART flag unless that is what the reporting device actually does to the
data object.
If a device is capable of reporting data (communicating with an upstream device) prior to the clearing of the
RESTART flag in the reported objects, then the ONLINE flag shall be cleared at initialization and the
following conditions shall hold:
If the ONLINE flag is reported set while the RESTART flag is set, the object is operating and reporting
its default start-up value, but has not yet had its data updated from the field.
If the ONLINE flag is clear, the object has not completed its startup process, and is still off-line.
Implementation Rules:
If the value and flags of an object are preserved through a cold start or restart, the RESTART flag of that object
may optionally remain unchanged.
When the data object is first updated with field data, the RESTART flag shall be cleared.
If a device overrides the initial value of objects, then during the period between initialization and the time that
the data object is first updated with field data, the objects may optionally set their LOCAL_FORCED flag to
indicate that the value has been overridden.
Considerations for Data Concentrators (Non-originating devices)
Data Concentrators are devices that act as reporting devices that collect data from originating devices or
other reporting devices. A data concentrator accepts data and flags values sent to it from a reporting device and
passes these on to a master device. The data concentrator may alter some of the flags as follows:
When the data concentrator undergoes a cold start, it shall set the RESTART flag and clear all other flags
for all database points. These flags shall stay in this state until the first data update from the lower level
reporting device, at which time the value and flags shall be set to the state reported from that downstream
device. The data objects may optionally be initialized with the ONLINE and LOCAL_FORCED flags set as
outlined above. Alternatively, the data concentrator may choose to not respond until the first data update
from the reporting device.
If a downstream reporting device fails to communicate with the data concentrator, the data concentrator may
set the COMM_LOST flag for all data objects from that reporting device. It may optionally also clear the
ONLINE flag, but shall not alter any other flag. When communication with the lower level device is
established or restored, the data concentrator updates all flags to the state reported by the downstream
device when data is received (subject to the following rule for handling the forced data flags).
If the LOCAL_FORCED or REMOTE_FORCED flags are set for an object from a downstream reporting
device, the REMOTE_FORCED flag shall be set and passed through to the master. If the data concentrator
overrides a data points value, it shall set the LOCAL_FORCED flag; otherwise this flag shall be cleared.
Page 7 of 8
11 June 2003
Note that the sending device may determine if flags should or should not be sent for objects having variations
with or without flags. Even if the master device requests a specific variation of an object, the outstation may
respond with a different variation (with or without flags) as appropriate according to the condition stated above.
Other attributes of a specific variation requested by a master (for example: 16-bit or 32-bit data) must be
observed by the outstation when responding.
Specific Object Changes
The Analog Output Status Object (Object 40, Variations 1 and 2) as shown in the Data Object Library should
include the LOCAL_FORCED flag, which was omitted from the original definitions.
Affected Documentation:
DNP V3.00 Data Object Library
Chapter 3 Binary Input Object Definitions
Chapter 4 Binary Output Object Definitions
Chapter 5 Counter Object Definitions
Chapter 6 Analog Input Object Definitions
Chapter 7 Analog Output Object Definitions
Chapter 13 Alternate Numeric Object Definitions
Last Updated:
11 June 2003
Status:
Protocol clarification: For immediate release.
Page 8 of 8
11 June 2003
11 November 2003
1 of 2
TB2003-003, Self-Address
Affected Documentation:
Basic Four Document Set, Device Profile Document, Level 1 and Level 2
Certification Procedures
Changes to the Subset Level 1 and 2 Certification Procedures
Insert additional Procedure:
11 November 2003
2 of 2
TB2003-003, Self-Address
Background:
The DNP3 Protocol identifies individual data objects by the combination of Device Address, Object Group
and Point Index.
The Device Address appears as the Source Address of all data responses. This identifies the device
reporting the data.
Within a device, DNP3 models data objects as being members of Object Groups, each containing a
single type of data object (e.g.: binary inputs, binary outputs, analog inputs, etc.).
Each Object Group is modeled as a separate one-dimensional array of objects. Each individual data
point is an element of this array, and is identified by its index in the array, called the Point Index.
The Point Index range for accessing each array is an unsigned integer starting at zero for the first
element of the array. The Point Index value has no purpose other than to identify an array element. For
example: the Point Index does not imply any application-specific ordering or prioritization of objects.
DNP3 message transmission efficiency (particularly in static data responses) is maximized if the data
objects in the Object Group are assigned a single contiguous range of Point Index values beginning at
zero.
In some devices, storage and access mechanisms are simplified or optimized if all array elements are
assigned the contiguous range of Point Indices from zero to one less than the number of objects in the
array.
Resolution:
The assignment of Point Indices to objects should be performed in accordance with the following
recommendations:
The objects of each Object Group should be assigned a contiguous range of Point Index values
beginning at zero.
Gaps in the Point Index range are permissible, but should be avoided wherever possible. An example
of an acceptable gap might be where an object is optional (i.e. where it may be installed or uninstalled
without altering the Point Index values of the remainder of the objects in that Object Group). The
design aim is to assume that all objects in the Point Index range (from zero to the maximum installed
Point Index) always exist in the device, but some may be absent. Consider assigning the optional
objects to the largest Point Index values, so that if they are not installed, the remaining objects still
form a group having a contiguous Point Index range with zero being the lowest Point Index value.
Assume that memory and database resources are required for each object in the Point Index range from
zero to the highest installed Point Index, irrespective of whether all these Point Indices are actually
transmitted.
Page 1 of 2
It is not acceptable to assign Point Indices in a sparse manner (e.g.: 0, 1, 2, 100, 101, 102, 200, 201,
202). Point Indices are not intended (and should not be used) for grouping data or implying some
relationship between data points.
Consider assigning sets of optional objects to one or more virtual devices, each having a different
device address. If the objects are installed, that virtual device exists, if the objects are not installed,
the virtual device does not exist. This removes the possibility of introducing gaps in the Point Index
ranges when optional objects are installed or uninstalled.
Affected Documentation:
None
Last Updated:
December 17, 2003
Status:
Protocol clarification: For immediate release.
Page 2 of 2
DNP3 Technical Bulletin 2003-004
Point Index Ranges
18-September-2002
TB-2002-001:Counter Objects
Overview
This technical bulletin clarifies definition of and processing related to Binary and Frozen Counter objects.
Counter objects include:
Counter Definitions
A Counter is an input point type whose value represents an accumulated value. Counts can be hardware
generated by external transitions or pulses, or incremented under software control. Counters are also
referred to, in other protocols, as pulse accumulators. Accumulated counts cause the value of the
corresponding Counter point to increase. After the maximum value that can be encoded for reporting is
reached, the value resets to zero and continues counting.
DNP3 protocol defines four objects for reporting values associated with physical Counter points: Binary
Counters, Frozen Counters, Binary Counter Events, and Frozen Counter Events. Devices may elect which
objects to support. Rules applying to devices that support more than one Counter object are discussed
later.
Binary Counter values reflect the current (instantaneous) accumulated value of the Counter point. A read
request for a Binary Counter returns the value of the underlying accumulation at the instance in time
when the read is received. Binary Counter values are returned using DNP3 object 20.
Frozen Counter values reflect the accumulated value of the Counter point at a given instant of time.
Frozen Counter values are recorded when a device processes a Freeze or Freeze-and-Clear operation. This
operation can be requested via DNP3 protocol communications, or by other software or hardware. Frozen
Counter values remain unchanged until the next Freeze or Freeze-and-Clear operation. Frozen Counter
values are returned using DNP3 object 21.
A Binary Counter Event is generated when the total number of accumulated counts has reached an
interesting value. For example, an event might be declared when the value has exceeded a threshold, as
compared against the most recent Binary Counter value successfully reported to the host. However, the
actual cause of a Binary Counter Event is a local implementation matter and not defined by DNP3. A
Binary Counter Event value is the accumulated amount in the respective Binary Counter at the instant
when the event is generated. Binary Counter Event values are returned using DNP3 object 22.
A Frozen Counter Event is generated at every freeze operation, for all supported points, whether or not
the frozen value has changed. The Frozen Counter Event value is the same value as that stored into the
18-September-2002
TB-2002-001:Counter Objects
Frozen Counter when the device processes a Freeze or Freeze-and-Clear operation. Frozen Counter Event
values are returned using DNP3 object 22.
As a side note, device hardware or software may maintain other internal Counter-related values to
facilitate calculation and reporting of Binary and Frozen Counter values, and to support Counter Freeze
operations. The presence and meanings of any such auxiliary values is not a DNP3 protocol issue and is
not discussed in this document.
Notes:
In the event of non-contiguous point ranges, reporting must use qualifier codes allowed by
the subset definition.
The intention is that it be possible to report either the Binary Counter value or the Frozen
Counter value for each index in response to a Class 0 poll. It is optionally permissible to
report both running and frozen values, but if this is available it must be possible to force the
outstation to only report one or the other.
A base DNP3 requirement is that events for a particular object may only be reported if the
corresponding object appears in response to a Class 0 poll. Thus:
Binary Counter events may be reported for a particular index only if the corresponding
Binary Counter is reported in response to a Class 0 poll.
Frozen Counter events may be reported for a particular index only if the corresponding
Frozen Counter is reported in response to a Class 0 poll.
If Binary Counter events and Frozen Counter events are to be reported for the same index,
then both Binary Counter and Frozen Counter for that index MUST appear in response to a
Class 0 response.
It is permissible for only Binary Counters or only Frozen Counters to be reported in response
to a Class 0 poll.
Freeze Operations
Frozen Counter values are recorded whenever a Freeze or Freeze-and-Clear operation occurs. When a
device restarts, Frozen Counter values may be undefined prior to processing the first freeze operation.
Devices that maintain Frozen Counter values in non-volatile memory and that continue accumulation
during a loss-of-power condition may possibly maintain valid Frozen Counter values across a device
restart operation.
18-September-2002
TB-2002-001:Counter Objects
A Freeze or Freeze-and-Clear operation causes the current Binary Counter value to be copied and
recorded as the current Frozen Counter value. If supported, Frozen Counter events are generated at this
time. Events should be generated for all points during the first freeze following a system restart. For a
Freeze-and-Clear operation, the underlying Binary Counter value is reset to zero immediately after the
frozen value is recorded. It is important that no counts are lost between recording the frozen value and
resetting the Binary Counter value to zero.
Freeze and Freeze-and-Clear commands must be directed to the static Binary Counter object, object 20,
variation 0, even for devices that do not provide point data in response to a read for this object. A Freeze
to object 20 creates Frozen Counter values in Object 21 and Frozen Counter events in object 23. Freeze
operations directed to any other Counter object are not defined and are non-interoperable. For Subset
Level 1 and 2 devices, freeze operations must use the all points qualifier, code 6, to simultaneously
freeze all Counters. Subset level 3 devices allow freeze operations to specific point ranges using a
start/stop qualifier, code 0 or 1. Use of any other qualifier is not defined.
A Binary Counter value read after a Freeze-and-Clear operation must return a value representing the
number of counts occurring subsequent to the Freeze-and-Clear. A Frozen Counter value re-frozen after
an initial Freeze-and-Clear operation must return a value representing the number of counts occurring
between the two freeze operations. Devices that cannot conform to this rule must respond to a Freezeand-Clear request with a Null response setting the Function Code Not Implemented Internal Indication.
Note that counts may be lost if a second Freeze-and-Clear command is issued before values from a prior
Freeze-and-Clear command are read.
DNP defines six freeze related function codes:
The only difference between normal/acknowledge and no acknowledgment cases is whether or not a
device transmits a response after performing or queuing the requested action. A normal/acknowledge
function sent to a global destination address (0xFFF0 to 0xFFFF) should be processed as if a
corresponding no acknowledgement function was received.
The null response is always sent in cases where a response message is warranted. A null response
includes all octets up to and including the two IIN octets. A device that does not support Frozen Counters
should respond after setting the Function Code Not Implemented indication. Devices that support
Frozen Counters must support both Immediate Freeze and Freeze and Clear commands. The two Freeze
with Time functions are defined in the protocol but not required by any of the DNP subset levels. They
are not discussed further in this document.
TB-2002-001:Counter Objects
a 32-bit Counter is 4,294,967,295 (232 1). It is strongly recommended that counters wrap at one of these
maximum values.
DNP3 also supports both 16-bit and 32-bit variations for reporting Counter object values. A device that
maintains 32-bit Counters may select, as a default, either a 16-bit or 32-bit variation. If a 16-bit default is
used, only the low 16-bits of the 32-bit value are reported. Regardless of the default variation selected,
devices that support 32-bit Counter values must respond to an explicit request for a 16-bit variation with
data for all requested points. A null-response is not valid for any explicit request for a 16-bit variation if a
null-response is not also transmitted in response to an explicit request for the corresponding 32-bit
variation. If a device is asked for a 32-bit variation but maintains 16 bits or less, it is recommended that
the device respond by setting bit 1 of Internal Indication octet 2 (requested object unknown).
DNP3 defines two forms for reporting Counter values: Binary and Frozen. Binary values are defined for
Binary Counter and Binary Counter Event objects. Frozen values are defined for Frozen Counter and
Frozen Counter Event objects.
DNP3 previously defined a third reporting form, Delta Counters, but because of many underlying
problems they were declared obsolete as of 12-October-2001.A Delta Counter value, simply stated, refers
to a point value calculated as the difference between underlying values obtained at two separate times.
The DNP3 Users Group recommends that Delta Counters not be implemented within a device. The
variation numbers used for reporting Delta Counters remain as placeholders so that all of the other
variation numbers stay the same. Devices may continue to support Delta Counters variations, but may not
configure one as the default reporting variation. Devices that support only Delta Counter variations are
not compliant with any DNP3 subset. DNP3 documentation does not define how Delta Counters are
maintained or how they should be reported.
Variation Structures
A detailed description of each variation used to report Counter values can be found in the DNP3 Data
Object Library section of the Basic 4. A summary is presented in this document.
Counter variations include the following components, although not all are present in every case.
Only the value is present in all variations. Within each communication message, the flag octet, if present,
is transmitted first. The value is transmitted after the flag octet, or, if the flag octet is missing, is
transmitted first. The time stamp, if present, follows the value. For variations with no time stamp, the
value is the last component transmitted.
18-September-2002
TB-2002-001:Counter Objects
The basic format of all variations for all Counter objects can be diagrammed as follows:
7
0
6
DC
5
RL
4
LF
3
RF
2
CL
1
RS
0
OL
bit position
b15
Value, 16 or 32 bits
or
b31
b0
The next table lists variations for each Counter object, indicating which contain flag and time stamp
components, and describing the form of the value component.
Binary Counter Object Variations
Value
Obj
Var
Flag Time
Size
Type
20
1
32
Binary
Static
2
16
Yes
3
32
Delta
4
16
No
5
32
Binary
6
16
No
7
32
Delta
8
16
22
Event
23
Event
1
2
3
4
5
6
7
8
32
16
32
16
32
16
32
16
Binary
No
Delta
Yes
Binary
Yes
Delta
1
2
3
4
5
6
7
8
32
16
32
16
32
16
32
16
Frozen
No
Delta
Yes
Frozen
Yes
Delta
TB-2002-001:Counter Objects
apply based on the source of the Counter value. One of two possible sources is indicated by the terms
originating device and non-originating device.
An originating device is one that gathers or calculates the Counter data directly, either under
software control or using hardware.
A non-originating device is a one that gathers Counter data from communication to a lowerlevel device.
SCADA Master
Originating point
Non-originating point
Counter object
Counter object
Calculate
Hardware Input
detection
Input terminal
Communication channel(s)
Counter object
Calculate
Originating device
Hardware Input
detection
Input terminal
Non-originating devices may be several levels deep. That is, a single Counter may be transmitted from its
physical input location through several devices before arriving at the final destination. All devices except
the one in direct control of the physical input are considered non-originating devices. A non-originating
18-September-2002
TB-2002-001:Counter Objects
device calculates abnormal flag state conditions based on the best information available, including
analysis of flag information received from the lower device.
Normal
State
(Set:1,
Reset:0)
Flag
Name
OL
RS
CL
RL
On-line
Restart
Communication Lost
Local Forced
Data
Remote
Forced Data
Rollover
Reset
DC
Discontinuity
Reset
LF
RF
Description
Please refer to the DNP3 Basic 4 Documentation Set, Data Object Library, for
an explanation of these flags
Definition: Counter value has exceeded its maximum and rolled over to zero.
Originating Device: Set on first successful transmission to host after physical
rollover occurs. Reset otherwise.
Non-originating device: There is no general mechanism within DNP3 for a
outstation device to report the value at which Counter rollover occurs. Hence it
is highly recommended that slave devices do not set the Rollover flag and
that host devices ignore the Rollover flag.
Definition: Current value cannot be compared against prior value to obtain total
counts
Originating device: Set when Counter value is reinitialized. Reset after a new
value has been acquired and transmitted to the host.
Non-originating device: Set when DC flag is set in the lower device. Reset after
a new value has been acquired and transmitted to the host.
Changes
Affected Documentation: DNP3 Basic 4 Documentation Set, Data Object Library, Section 6.
Last Updated: 18-September-2002
18-September-2002
TB-2002-001:Counter Objects
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 pointspossibly just a single pointand may not be able to process a request
containing a greater number of objects. DNP3s 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
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
0
Identifier
Name
SUCCESS
HARDWARE_ERROR
LOCAL
TOO_MANY_OPS
NOT_AUTHORIZED
RESERVED
UNDEFINED
TIMEOUT
NO_SELECT
FORMAT_ERROR
NOT_SUPPORTED
ALREADY_ACTIVE
6
7
8
9
10 to
126
127
Description
2.2
Master Requirements
2.2.1
Select-Operate
Page 1 of 1
15-December-2000
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 slaves 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 usedandthe 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 requestselect, operate or direct operateand one or more of the
objects are unsuccessful, its response shall include one of these
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
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:
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
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.
DNP Technical Bulletin TB2001-001
Multiple Control Objects and Status Codes
Page 2 of 2
15-December-2000
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
Conditions in slave
when Request is received
No errors are detected, all objects successful.
The function code is not supported regardless of
which indexes the objects have.
The slave does not support the specific variation code
in the request.
Indexes for objects C and D are beyond the
maximum number of points installed in the slave.
Object B is already executing when this request
arrives.
The slave can only control one object at a time.
Object C is tagged or blocked to prevent its control.
The Remote/Local Switch is in the Local position.
A control output is requested and the Control Relay
Output Block in Object Ds request contains an
illegal control code.
An analog output is requested and the value in Object
Ds request exceeds the permitted level.
Obj
A
0
Status Codes
Obj
Obj
B
C
0
0
Obj
D
0
1.
5
0
IIN Bits
2. 2. 2.
0
1
2
0
0
0
2.
4
0
NR
NR
NR
NR
NR
NR
NR
NR
0
0
0
0
0
0
0
0
7
7
0
0
5
5
8
8
0
0
0
NR
4
4
0
NR
8
NR
9
9
7
NR
4
NR
0
NR
8
NR
0
NR
7
NR
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.
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.
DNP Technical Bulletin TB2001-001
Multiple Control Objects and Status Codes
Page 3 of 3
15-December-2000
5.2
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
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.4
Change to read, Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of
4.
5.5
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
Review the devices 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
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.
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
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.
Page 4 of 4
15-December-2000
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
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.8
Change to read, Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of
4.
5.9
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.10
Change to read, Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of
4.
5.11
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
Review the devices 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
Page 5 of 5
15-December-2000
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.
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
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.
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 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.
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.
6 Status:
Approval Technical Committee (Feb-2001).
Page 6 of 6
15-December-2000
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.
Notes
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.
Additional application layer function codes are added to support authentication and file specific
operations. They are defined as follows.
Function
Code
25
26
27
28
29
30
Table 1
Description
Open a File
Close a File
Delete a File
Get File Info
Authenticate
Abort
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.
b7
Table 2
Object Header
Object 70
Variation 2
b7
Qualifier 0x5B
b0
b7
b0
b15
b0
b15
b0
b15
b0
b15
Password Offset
b0
b15
Password Size
b0
b31
Authentication Key
b0
bn
b0
bn
Password Octets
b0
b7
b0
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.
Sequential File Transfer Objects
26 January 2000
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.
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
The File Command Object (obj 70 var 3) is used to facilitate file opens and deletes. It is defined
as follows.
b7
Table 3
Object Header
Object 70
Variation 3
B7
Qualifier 0x5B
b0
b7
b0
b15
b0
b15
b0
b15
b0
b47
Time of Creation
b0
b15
Permissions
b0
b31
Authentication Key
b0
b31
File Size
b0
b15
Operational Mode
b0
b15
b0
b15
Request ID
b0
bn
b0
b7
b0
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
Sequential File Transfer Objects
26 January 2000
Bit Fields
DNP Technical Bulletin 2000-001
Page 4
0x0100
0x0080
0x0040
0x0020
0x0010
0x0008
0x0004
0x0002
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 devices 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.
Mode Value
0x00
0x01
0x02
0x03
Table 5
Description
Null
Read
Write
Append
(Not required to be supported in a minimum
implementation)
DNP Technical Bulletin 2000-001
Page 5
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
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.
b7
Table 6
Object Header
Object 70
Variation 4
b7
Qualifier 0x5B
b0
b7
b0
b15
b0
b31
b0
b31
File Size
b0
b15
b0
b15
Request ID
b0
b7
Status
b0
bx
b0
b7
b0
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
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
Name
Usage
0x08
0x09
Cant Abort
Reserved
Other
0x0A 0x0F
0xFF
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
0xC0 25 70 03 0x5B 01 nn nn (object data)
Sequential File Transfer Objects
26 January 2000
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.
Sequential File Transfer Objects
DNP Technical Bulletin 2000-001
26 January 2000
Page 8
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
0xC0 27 70 03 0x5B 01 nn nn (object data)
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
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, cant 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 Cant 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
Sequential File Transfer Objects
26 January 2000
an unusable file the device must return a Cant Abort status code in a File Command Status
Object (obj 70 var 4).
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
b7
Table 8
Object Header
Object 70
Variation 5
b7
Qualifier 0x5B
b0
b7
b0
b15
b0
b31
b0
b7
b31
b30
LAST
Bn
Block Number
Data Octets
b0
b0
b0
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
b7
Table 9
Object Header
Object 70
Variation 6
b7
Qualifier 0x5B
b0
b7
b0
b15
b0
b31
b0
b7
b31
b30
LAST
Block Number
b0
b0
b0
b7
Status Code
b0
Bx
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
Name
Usage
Status Field
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.
Sequential File Transfer Objects
26 January 2000
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.
Open
Open Response
Confirm
0xC0 00
Null Response
N Polls
Confirm
0xC2 00
Null Response
N Polls
Confirm
0xC4 00
Null Response
N Polls
Confirm
0xC6 00
Close
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
Open
Open Response
Confirm
0xC0 00
Null Response
N Polls
N+1 Poll
Confirm
0xC3 00
Null Response
N Polls
N+1 Poll
Confirm
0xC6 00
Null Response
N Polls
N+1 Poll
Confirm
0xC9 00
Close
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.
The File Descriptor Object (obj 70 var 7) is used to get information about a file. It is defined as
follows:
Table 13
Object Header
b7
b0
Object 70
b7
b0
Variation 7
B7
Qualifier 0x5B
b0
b7
b0
b15
b0
b15
b0
b15
b0
b15
File Type
b0
b31
File Size
b0
b47
Time of Creation
b0
b16
Permissions
b0
b15
Request ID
b0
bn
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.
Sequential File Transfer Objects
26 January 2000
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
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 (ObjectRequestIDPath\FileNameData)
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 (ObjectRequestIDPath\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
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 Objects 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 subdirectory 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
0x14 00
04 00
04 00
00 00
00 00
03 00 00 00
01 00 00 00
nn nn nn nn nn nn
nn nn nn nn nn nn
00 00
00 00
nn nn
nn nn
dir1
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
0x14 00
0x14 00
05 00
05 00
04 00
01 00
01 00
00 00
nn nn nn nn
nn nn nn nn
01 00 00 00
nn nn nn nn nn nn
nn nn nn nn nn nn
nn nn nn nn nn nn
00 00
00 00
00 00
nn nn
nn nn
nn nn
file1
file2
dir2
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
Obj
Var
70
70
70
70
70
70
2
3
4
5
6
7
Description
REQUEST
RESPONSE
Func
Codes
(dec)
Authentication Object
File Command Object
File Command Status Object
File Transport Object
File Transport Status Object
File Descriptor Object
Qual
Codes
(hex)
25,27
26,30
1,2
0x5B
0x5B
0x5B
28
0x5B
Func
Codes
(dec)
129,130
129,130
129,130
129,130
Qual
Codes
(hex)
0x5B
0x5B
0x5B
0x5B
Affected Documentation:
DNP V3.00 Data Object Library
Chapter 10 File Object Definitions
Last Updated:
January 26, 2000
Status:
Pending General Membership Approval (Feb 2000)
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 protocols
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.
WAN
Host
Outstation
Figure 1
It is possible for messages to get lost in the communications medium as shown in Figure 2
Page 1 of 12
January 24, 2000
WAN
Host
Outstation
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-tooperate 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 Outstations 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.
Page 2 of 12
January 24, 2000
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.
Host
Outstation
Time To
SEQ N
Time Tn
Figure 3
Page 3 of 12
January 24, 2000
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.
Host
Outstation
Time To
SEQ N+1
SEQ N+1
Host Receives Echo N+1
Time Tn
Figure 4
Page 4 of 12
January 24, 2000
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.
Host
Outstation
Time To
SEQ N
SEQ N
SEQ N
Time Tn
Figure 5
Page 5 of 12
January 24, 2000
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.
Host
Outstation
Time To
SEQ N
SEQ N+1
SEQ N+1
Time Tn
Figure 6
Page 6 of 12
January 24, 2000
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.
Host
Outstation
Time To
SEQ N
SEQ N+1
SEQ N+2
Time Tn
Figure 7
Page 7 of 12
January 24, 2000
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.
Host
Outstation
Time To
SEQ N
SEQ N
SEQ N
Outstation is Restarting
SEQ N
SEQ N
Outstation Receives Operate
Oustation Operates Control a second time
Oustation Echos Operate
SEQ N
Time Tn
Figure 8
Page 8 of 12
January 24, 2000
Affected Documentation:
This document supersedes Technical Bulletin 9804-001 Item 7.
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.
If the DUT does not have installed binary output points skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
If the DUT does not have installed binary output points skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again incrementing the application layer sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
If the DUT does not have installed binary output points skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
Issue the operate again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the operate byte for byte.
Page 9 of 12
January 24, 2000
9.
Verify that the DUT does not operate the binary output.
If the DUT does not have installed binary output points skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
Issue the operate again, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2
(NO MATCHING SELECT).
Verify that the DUT does not operate the binary output.
If the DUT does not have installed binary output points skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2
(NO MATCHING SELECT).
Verify that the DUT does not operate the binary output.
Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the
mismatched operate cleared the previous select.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2
(NO MATCHING SELECT).
Verify that the DUT does not operate the binary output.
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.
If the DUT does not have installed analog output points skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Page 10 of 12
January 24, 2000
8.
If the DUT does not have installed analog output points skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again incrementing the application layer sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
If the DUT does not have installed analog output points skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
Issue the operate again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT does not operate the analog output.
If the DUT does not have installed analog output points skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
Issue the operate again, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2
(NO MATCHING SELECT).
Verify that the DUT does not operate the analog output.
If the DUT does not have installed analog output points skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2
(NO MATCHING SELECT).
Verify that the DUT does not operate the analog output.
Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the
mismatched operate cleared the previous select.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2
(NO MATCHING SELECT).
Verify that the DUT does not operate the analog output.
Page 11 of 12
January 24, 2000
Last Updated:
January 24, 2000
Status:
Pending General Membership Approval (Feb-2000).
Page 12 of 12
January 24, 2000
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
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.
2.
3.
4.
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
Change Management
Page 1 of 22
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
Last Updated:
January 26, 2000
Status:
Pending General Membership Approval (Feb 2000).
Page 2 of 22
January 26, 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 noncompliance 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
Page 1 of 1
17-August-2000
Last Updated
31 May 2001
Status
Awaiting User Group Comments
14-March-2001
TD-Counters-JV-1.doc
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).
Last Updated:
November 13, 2000
Page 1 of 2
November 13, 2000
Status:
Pending General Membership Approval (Feb-2001).
Page 2 of 2
November 13, 2000
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
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:
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:
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
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.
If the DUT does not have installed binary output points skip this section.
If the DUT does not have installed complementary function binary output points skip this section.
If the DUT does not support the 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) pair skip to step 8
Issue a valid control sequence to the first installed complementary function binary output point using control
code 0x03 (Latch On/NUL).
Verify the control operation completes successfully.
Issue a valid control sequence to an installed complementary function binary output point using control code
0x04 (Latch Off/NUL).
Verify the complementary control operation completes successfully.
If the DUT does not support the 0x41(Pulse On/Close) and 0x81 (Pulse On/Trip) pair skip to step 13
Issue a valid control sequence to an installed complementary function binary output point using control code
0x41(Pulse On/Close).
Verify the control operation completes successfully.
Issue a valid control sequence to an installed complementary function binary output point using control code
0x81 (Pulse On/Trip).
Verify the complementary control operation completes successfully.
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.
Issue a valid control sequence to an installed complementary function binary output point using control code
0x03 (Latch On/NUL).
Verify the control operation completes successfully.
Issue a valid control sequence to the same installed complementary function binary output point using control
0x81 (Pulse On/Trip).
Verify that the complementary control operation completes successfully.
Issue a valid control sequence to the same installed complementary function binary output point using control
code 0x41(Pulse On/Close).
Verify the complementary control operation completes successfully.
Issue a valid control sequence to the same installed complementary function binary output point using control
0x04 (Latch Off/NUL).
Verify the complementary control operation completes successfully.
If the DUT does not have installed binary output points skip this section.
If the DUT does not have installed single function binary output points skip this section.
For any point that is tested below, determine what action should happen when the control executes.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x01
(Pulse On/NUL).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x03
(Latch On/NUL).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x04
(Latch Off/NUL).
Verify the control operation in step 3 completes successfully.
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
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
20-June-2001
TB2000-006
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.
9905-001
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 objects 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.
9905-001
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
May 31, 1999
9905-001
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 nonconformant (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.
Page 4 of 6 plus Replacement Section 3.7.2
9905-001
Affected Documentation:
Application Layer Section 3.7.3.
Figures 3-16 and 3-17:
Alter the diagrams for Qualifier Code 11:
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.
9905-001
9905-001
3.7.2
Qualifier Field
The qualifier field specifies the meaning of the following Range Field.
bit:
7
R
Index Size
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
Range Field contains 8 bit start and stop indices
Range Field contains 16 bit start and stop indices
Range Field is omitted, entire range is specified
Range Field contains an 8 bit object count
Range Field contains a 16 bit object count
Free Format Qualifier
Qualifier Field
(hexadecimal)
00
01
06
07, 17
08, 28
5B
Range Size
(octets)
2
4
0
1
2
1
3-24
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
Start and Stop Sub-Fields in the Range Field (Qualifier Codes 05)
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.
3-25
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)
3-26
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, 1215)
Qualifier Codes 10 and 1215 are reserved and should not be used.
3-27
3-28
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.
Affected Documentation:
Level 1 and 2 Subset Definitions and Certification Procedures
Modifications to Certification Procedure
December 8, 1999
1 of 2
9912-002.doc
December 8, 1999
2 of 2
9912-002.doc
1 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 IIN10 set should be suppressed, but that the confirmation may be requested if
required by the details of the response being issued.
FFF0C These addresses are now reserved for future use.
Affected Documentation:
Basic Four Document Set, Level 1 and Level 2 Certification Procedures
Changes to the Subset Level 1 and 2 Certification Procedures
Insert additional Procedure:
2 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.
December 8, 1999
3 of 3
9912-003.doc
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 the
original 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 devices
RESTART IIN. (This need not be a special case, since the RESTART bit will necessarily
make the unsolicited response at least one bit different that the previous one.) It continues
checking 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 DIRECT
OPERATE function codes.
Affected Documentation:
DNP V3.00 Application Layer
Chapter 3: Definition of DNP Message Fields
Section 3.2:
Communication Flow Control
Section 3.3:
Master Request & Unsolicited Response Collisions
1 of 1
9804-001.doc
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
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
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
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).
1 of 6
9804-002.doc
2.4
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
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
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
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
2 of 6
9804-002.doc
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
3 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.2
Noisy Environments
4 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.
And
4.3
4.4
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,
5 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
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.
6 of 6
9804-002.doc
Common
DNP
Name
Fragment
Consists
of...
OSI
Term
Application
Header,
Object
Headers,
Object Data
APDU,
TSDU
Transport
Function
Segment
Transport
Header +
part of an
APDU
TPDU,
LSDU
Data Link
Layer
Frame
Data Link
Header +
CRCs +
complete
TPDU
LPDU
Application
Layer
Affected Documentation:
1 of 1
9804-003.doc
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).
1 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:
2. Slave:
3. Master:
4. Slave:
Master)
5. Master:
6. Slave:
7. Master:
8. Master:
9. Master:
10.Slave:
(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.
2 of 3
9804-004.doc
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.
3 of 3
9804-004.doc
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
1 of 2
9804-005.doc
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
2 of 2
9804-005.doc
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.
Affected Documentation:
DNP V3.00 Data Object Library
Chapter 6 Analog Input Object Definitions
Chapter 7 Analog Output Object Definitions
Chapter 13 Alternate Numeric Object Definitions
1 of 199
9804-006.doc
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
0 7
0
Mantissa
22
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R32 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..7] <0..255>
Mantissa = UI23 [0..22] <0..223-1>
}
2 of 199
9804-006.doc
Narrative:
The absolute value can be derived from the value field as follows:
Absolute_Value
where:
and
si
Exp
=
=
Mantissa[0..22]
Exponent[0..7]
Sign:
Exponent:
Mantissa:
3 of 199
9804-006.doc
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 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 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
S Exponent
0 10
0
Mantissa
51
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R64 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..10] <0..2047>
Mantissa = UI23 [0..51] <0..252-1>
}
4 of 199
9804-006.doc
Narrative:
The absolute value can be derived from the value field as follows:
Absolute_Value
where:
si
Exp
=
=
Mantissa[0..51] and
Exponent[0..10]
Sign:
Exponent:
Mantissa:
5 of 199
9804-006.doc
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.
The flag field has the same meaning as the flag field of Object 30
Variation 5.
Object Coding:
Flag
7
S Exponent
0 7
0
Frozen Value
Mantissa
22
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R32 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..7] <0..255>
Mantissa = UI23 [0..22] <0..223-1>
}
6 of 199
9804-006.doc
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 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 long real as specified by the IEEE-754 standard.
This field is as described for the value field of Object 30 Variation 6.
The flag field has the same meaning as the flag field of Object 30
Variation 5.
Object Coding:
Flag
7
S Exponent
0 10
0
Frozen Value
Mantissa
51
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R64 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..10] <0..2047>
Mantissa = UI23 [0..51] <0..252-1>
}
7 of 199
9804-006.doc
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 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. 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 flag field has the same meaning as the flag field of Object 30
Variation 5.
Object Coding:
Flag
7
0
Value
S Exponent
0 7
0
Mantissa
22
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R32 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..7] <0..255>
Mantissa = UI23 [0..22] <0..223-1>}
8 of 199
9804-006.doc
Type: Event
Description:
The Long 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 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 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.
The flag field has the same meaning as the flag field of Object 30
Variation 5.
Object Coding:
Flag
7
0
Value
S Exponent
0 10
0
Mantissa
51
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R64 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..10] <0..2047>
Mantissa = UI23 [0..51] <0..252-1>}
9 of 199
9804-006.doc
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 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. 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
Variation 5.
Object Coding:
Flag
7
0
Value
S Exponent
0 7
0
Mantissa
22
Time
48
0
0
*S = Sign
SQ3 { Flag
Value
=
=
Time
BS8 [0..7]
R32 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..7] <0..255>
Mantissa = UI23 [0..22] <0..223-1>}
UI48 [0.47] <0.. 248-1>
10 of 199
9804-006.doc
Type: Event
Description:
The Long 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 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 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.
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
Variation 5.
Object Coding:
Flag
7
0
Value
S Exponent
0 10
0
Mantissa
51
Time
48
0
0
*S = Sign
SQ3 { Flag
Value
=
=
Time
BS8 [0..7]
R64 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..10] <0..2047>
Mantissa = UI23 [0..51] <0..252-1>}
UI48 [0.47] <0.. 248-1>
11 of 199
9804-006.doc
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.
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.
The flag field has the same meaning as the flag field of Object 30
Variation 5.
Object Coding:
Flag
7
S Exponent
0 7
0
Frozen Value
Mantissa
22
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R32 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..7] <0..255>
Mantissa = UI23 [0..22] <0..223-1>}
12 of 199
9804-006.doc
Description:
The Long 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.
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 long real as specified by the IEEE-754 standard.
This field is as described for the value field of Object 30 Variation 6.
The flag field has the same meaning as the flag field of Object 30
Variation 5.
Object Coding:
Flag
7
S Exponent
0 10
0
Frozen Value
Mantissa
51
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R64 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..10] <0..2047>
Mantissa = UI23 [0..51] <0..252-1>}
13 of 199
9804-006.doc
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.
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.
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
Variation 5.
Object Coding:
Flag
7
S Exponent
0 7
0
Frozen Value
Mantissa
22
Time
48
0
0
*S = Sign
SQ3 { Flag
Value
=
=
Time
BS8 [0..7]
R32 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..7] <0..255>
Mantissa = UI23 [0..22] <0..223-1>}
UI48 [0.47] <0.. 248-1>
14 of 199
9804-006.doc
Description:
The Long 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.
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 long real as specified by the IEEE-754 standard.
This field is as described for the value field of Object 30 Variation 6.
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
Variation 5.
Object Coding:
Flag
7
S Exponent
0 10
0
Frozen Value
Mantissa
51
Time
48
0
0
*S = Sign
SQ3 { Flag
Value
=
=
Time
BS8 [0..7]
R64 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..10] <0..2047>
Mantissa = UI23 [0..51] <0..252-1>}
UI48 [0.47] <0.. 248-1>
15 of 199
9804-006.doc
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.
The flag field holds information about the point and has the same meaning
as previous objects.
Object Coding:
Flag
7
0
Value
S Exponent
0 7
0
Mantissa
22
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R32 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..7] <0..255>
Mantissa = UI23 [0..22] <0..223-1>}
}
Narrative:
This object can be returned after an analog output block operation is
performed to determine the success of the operation.
16 of 199
9804-006.doc
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.
The flag field holds information about the point and has the same meaning
as previous objects.
Object Coding:
Flag
7
0
Value
S Exponent
0 10
0
Mantissa
51
*S = Sign
SQ2 { Flag
Value
=
=
BS8 [0..7]
R64 { Sign = BS1 [0] <0, positive; 1, negative>
Exponent = UI8 [0..10] <0..2047>
Mantissa = UI23 [0..51] <0..252-1>}
}
Narrative:
This object can be returned after an analog output block operation is
performed to determine the success of the operation.
17 of 199
9804-006.doc
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
Control
Status
7
0
*S = Sign
SQ2 { Value
Ctrl Stat =
18 of 199
9804-006.doc
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
Control
Status
7
0
*S = Sign
SQ2 { Value
Ctrl Stat =
19 of 199
9804-006.doc
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).
Affected Documentation:
DNP V3.00 Data Link Layer
Chapter 7: Physical Procedures
1 of 1
9804-007.doc
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 Groups 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.
Affected Documentation:
Nil.
1 of 1
9804-008.doc
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 inputs 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 14) 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 58) 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
1 of 6
9809-001.doc
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 floatingpoint 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 -128127, 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 devices 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
2 of 6
9809-001.doc
Affected Documentation:
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
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 masters
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
SQ1 { Deadband Value
}
0
= 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.
3 of 6
9809-001.doc
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 masters
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
31
SQ1 { Deadband Value
}
0
= UI32 [0..31] <0..4294967295 >
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.
4 of 6
9809-001.doc
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 masters
Read command).
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
corresponding Analog Input Object (Object 30).
Object Coding:
Deadband Value
S Exponent
Mantissa
0 7
0
22
SQ1 { Value
}
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 engineering unit value. For analog inputs using integrating
deadbands, the Deadband Value is the integrated deadband in engineering
unit-seconds.
5 of 6
9809-001.doc
6 of 6
9809-001.doc
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:
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
1 of 1
9701-001.doc
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:
Trip/Close
Clear
Queue
Code
Count
On-Time
Off-Time
Status
MINIMUM IMPLEMENTATION:
See following table. Invalid with Code values of Latch On or Latch Off.
Set to 0. Only used for continuously repeating commands.
Set to 0. Only used for continuously repeating commands.
See following table. Must be Pulse On if Trip/Close is not NULL.
Set to 1. Only used if the command is to be performed multiple times.
Set to 0 unless Code value is Pulse On. See following table.
Set to 0. Only used for Pulse Off values of Code or Count greater than 1.
Set to 0 in the output request.
Function Desired
Trip/Close
Code
On-Time
Latching Relay ON
NULL (0)
Latch On (3)
Zero (ignored)
NULL (0)
Zero (ignored)
NULL (0)
Pulse On (1)
Non-zero
Trip (2)
Pulse On (1)
Non-zero
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.
1 of 2
9701-002.doc
Affected Documentation:
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
2 of 2
9701-002.doc
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)
1 of 1
9701-003.doc
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
1 of 3
9701-004.doc
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 [0]
7
2 of 3
9701-004.doc
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 [0]
7
3 of 3
9701-004.doc
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
Frozen Analog Input
Data Object 31 Variations
Analog Change Event
Data Object 32 Variations
Frozen Analog Event
Data Object 33 Variations
Chapter 7 Analog Output Object Definitions
Analog Output Status
Data Object 40 Variations
Analog Output Block
Data Object 41 Variations
Chapter 13 Alternate Numeric Object Definitions
Floating Point
Data Object 100 Variations
(object 100 is no longer recommended)
1 of 1
5 to 7
7 to 9
5 to 7
5 to 7
3 to 5
3 to 5
1 to 3
9701-006.doc
Resolution:
Affected Documentation:
DNP V3.00 Data Link Layer
Chapter 3: DNP Data Link Description
Data Link Function Codes
1 of 1
9704-007.doc
Preface:
Users often have a requirement that their system should not lose information that may be used as part of a
post disturbance fault review or system behavior audit. The user may also want to manage and control the
behavior of the communications process in his system.
These requirements are often overlooked during the early stages of a project and may be costly to
implement at a latter stage of the project.
If the user has these requirements, then systems designers, especially when building systems of a
hierarchical nature with devices that may be provisioned from multiple vendors, need to provide a solution.
Implementing pseudo points and communicating their data using standard DNP3 data objects for these
system management functions provides a solution that is inter-operable between different vendor devices.
The following parts of this Application Note describe a solution using system management data points that
may benefit users when these are designed into the outstation and sub-master devices.
Details:
When building a system such as shown in Figure 1 below it is necessary that the master have enough
information to enable the user to perform system reviews and audits at any time after a network disturbance
has occurred.
DNP3 RTU
(device B)
DNP3
Master
DNP3 SubMaster
(device A)
Comms
Network
DNP3 RTU
(device C)
DNP3 RTU
(device D)
end devices
Figure 1 Typical system with hierarchical communications
These reviews and audits are often performed using the telemetry event log held at the master. Information
pertaining to the network disturbance will be present in the event log whilst the system is behaving as
normal, but there are situations where information could be lost, for example:
Also the users communications network may be based on dial-up devices and it is useful to collect
information pertaining to the performance of the dial-up network:
Page 1
19 February 2004
Even when the user has permanent communications circuits, he often wants details about the performance
of these circuits (number of time-outs, number of messages with bad crc, etc).
Users frequently desire the ability to stop a sub-master device from polling one of its end devices, as well
as wanting to know (at any instant in time) the communications status with an end device (i.e. disabled
from polling, communications failed).
Implementation:
The system management data points can be described under a number of different functional requirements:
1.
2.
In Figure 1 above when any of the end devices B, C or D undergo a restart, they report this to the
sub-master (device A) using the internal indication IIN1.7. The sub-master, in turn reports this
restart to its master by mapping the state of the end device IIN1.7 indications to (pseudo) binary
inputs in the sub-masters database. The actual method of mapping of these IIN1.7 indications to
binary input points is a local configuration issue.
Similarly, if the sub-master experiences communications problems with its end devices, B, C or D,
there is the potential for the event buffers to overflow in those end devices, resulting in lost events.
An overflowed buffer condition is reported to the sub-master using the internal indication IIN2.3.
The sub-master reports the possible loss of events to its master by mapping the state of end device
IIN2.3 indications to (pseudo) binary inputs in the sub-masters database. The actual method of
mapping of these IIN2.3 indications to binary input points is a local configuration issue.
A (pseudo) binary output point in the sub-masters database manages enabling and disabling
communications to an end device. The master performs standard DNP3 pulse or latch ON/OFF
control requests, using object group 12, to control the sub-master scanning algorithm. If the submaster polls the end device, then setting this point to the OFF state will stop the sub-master from
issuing data read requests to that end device. Similarly, if the sub-master is using unsolicited
report by exception mode, then setting this point to OFF should stop the sub-master from issuing
integrity scans requests (class 0 read requests for example) to the end device, and it should cause
the sub-master to disable unsolicited reporting by issuing a function code 21 request to that end
device.
A number of (pseudo) binary input points in the sub-masters database manage the monitoring of
the communications enabled status between sub-master and each end device. Binary input points
Page 2
19 February 2004
should be mapped in the sub-master database (for each end device) to show:
Communications are enabled / disabled (this point reflecting the state of the binary output
object detailed above)
Communications with the end device is OK / failed. This point is used to show the outcome of
the last DNP3 request to the end device. If the end device fails to respond to the sub-master's
request then the point is set to the "failed" state, otherwise it is set to the "OK" state. For end
devices connected to the sub-master via dial-up communications circuits then this point is also
set to the "failed" state if the sub-master's attempt at establishing the communications circuit
fails (for example the end-device fails to answer an incoming call request).
DNP3 communications with the end device is currently connected / not connected. This point
is specific to end devices connected to the sub-master via dial-up communications circuits.
The point is set to the "connected" state when there is a current connection between the submaster and the end device and a DNP3 message exchange has been successful (i.e. the submaster is actively communicating with the end device). When the connection is terminated
this point is set to the "not connected" state. The point can be used to give additional
information about the quality of the end device's data points that are present in the submaster's database:
If "not connected" then the values of the end-device's points in the sub-master database
may not be up to date (i.e. the data values may be old and hence unreliable, but the values
do reflect the values from the end-device at the time of the last communications
exchange).
If "connected" and not failed then the values of the end-device's points in the sub-master
database are reliable (i.e. the sub-master database either has the current values as seen by
the end-device or the sub-master is in the process of updating its database).
The actual method of mapping these control and monitoring functions to binary output points and to
binary input points is a local configuration issue.
3.
The number of messages where an acknowledgement has timed-out (not been received)
Page 3
19 February 2004
This maintenance of the communications statistics can be implemented using pseudo points
recording the information into counter data points. These points can then be read by interested
masters, and can be configured to generate counter change events when certain thresholds are reached
(for example more than 10 unanswered dial-up requests).
The actual method of mapping these communications statistics to counter points is a local
configuration issue.
4.
Final words
The examples above are by no means an exhaustive list, and IEDs and sub-masters may have other
information that may be important for managing these nodes. This information can be mapped to
conventional data points (one example of this is making information about software revisions
available to higher level masters).
Disclaimer
Application Notes contain information developed by users and are provided for the benefit of other
users. They illustrate how the features of DNP3 were used to meet specific user requirements. While
this Application Note has been reviewed by the DNP Technical Committee, it may not contain all of
the details that are necessary for a complete DNP3 implementation. The DNP Technical Committee
does not warrant the completeness of the information contained within this document, nor does it
warrant that the approach taken is the most appropriate in all situations. Other users must make their
own determination as to the suitability of this information for their specific application.
Page 4
19 February 2004
Preface:
SCADA systems in the UK water industry have traditionally been implemented with a communications
protocol that is proprietary to the system vendor. These proprietary protocols have evolved over the years
to meet specific requirements of the end-users. A number of UK users are now collaborating in an initiative
to move to an open protocol in order to gain some independence from specific vendor solutions.
If open protocols such as DNP3 are to be used then they must meet the base requirements of the users.
The following parts of this Application Note describe how one UK user incorporated DNP3-based
outstations into his SCADA system as his choice for applying an open protocol.
Details:
Some of the user requirements were easily identified:
The ability of an outstation to sample measured values at periodic intervals, store these (with a timestamp) for a reasonable amount of time, and then either report all of the values to the SCADA master
at a later time or wait until the SCADA master solicits their values. This requirement is referred to as
trending.
The ability of an outstation to maintain a list of critical events that cause immediate unsolicited
reporting from the outstation. This requirement is referred to as alarming.
The ability of an outstation to maintain a list of non-critical events that do not cause immediate
unsolicited reporting from the outstation. This requirement is referred to as eventing. It is a
requirement that eventing co-reside with normal unsolicited alarm reporting by the outstation.
The ability of an outstation to perform local computations and logic functions. These are user defined,
preferably using outstation features that are compatible with the IEC 61131-3 standard (Programmable
Controllers Part 3, Programming Languages). Although this does not immediately impact the
communications protocol there are user requirements to:
Change the user programs from a remote location (usually the SCADA master)
Allow the SCADA master to change operational values employed by the user programmable logic
The ability of the SCADA master to send configuration parameters to the outstation
Implementation:
The end-user installed outstations at sites where he had special, advanced requirements:
To compute the flow of water from a measurement of the head of water at a weir. This computation
needs a number of configuration values that are dependent on the characteristics of the specific weir
site. The user requires downloading these values from the SCADA master.
To trend the computed flow value, and other analogue measurements, at 15 minute intervals
Page 1
30 December 2003
The outstations may be used in the future at sites where the trend values are taken at a different interval.
Under circumstances where the communications are lost for a period of time, the outstation is required to
hold up to 5000 trended values. Similarly, at these future sites the user requires eventing for up to 1000
events.
These advanced user requirements were implemented into the SCADA system using standard DNP3
protocol features:
Event classes. The protocol implements three event classes, referred to as class 1, class 2 and class
3. Data points in an outstation may be configured to generate events when the data points change
value, these events being configurable such that they are assigned to any of the three classes. The
protocol gives the master station the ability to read events from individual classes, or to read
events from any combination of classes with a single read request.
Unsolicited report by exception (RBE) mode of operation. Outstations can operate in a number of
different modes, one being the unsolicited RBE mode. In this mode the master station does not
need to continually request the outstation to report events the outstation reports the events to
the master station as and when they occur.
This unsolicited RBE mode is additionally controlled with enable and disable commands from the
master station. The master station can individually select which of the three event classes are
enabled for unsolicited reporting.
Data object variations. DNP3 permits data from various data types, known as Object Groups, to be
reported in various formats, known as Variations. For example: The change of an analog
measurement can be sent with 16-bit or 32-bit integer resolution or as a floating-point value. These
values can be reported with or without the time of measurement.
Some variations are commonly used and are specified as required variations for conformance to
the DNP3 implementation subset levels. Some of the variations described in this case study are not
required in the subset specifications, therefore, not all DNP3 devices support them. Any utility
planning to use this case study as an implementation guideline should verify that the equipment
that they propose to use does implement these optional variations. This is readily verified by
reference to the relevant devices DNP3 standard implementation documentation, known as the
DNP Device Profile.
In the following sections details are given of meeting the user requirements using the event class
feature of the protocol. The choice of which specific event classes are used was an arbitrary decision,
the requirements could be met with any choice of event classes. However, an important aspect of this
is that the specific requirement being satisfied is the only one to be assigned to that class.
2. Trending
Trending was achieved using a software application in the outstation that periodically generates
"Analogue Input Change Events" using variations with time. The user locally configures which
outstation database analogue inputs are to be trended and the event generation interval. These are
configured as class 3 events.
Although these event variations are not mandatory in the subset definitions, experience has shown that
all commonly used DNP3 Test Sets and SCADA systems parse and process these events.
The user requires several modes for accessing these trend events, which is controlled by the timing of
the actual flow of the trend events into a class queue and by the enabling and disabling of unsolicited
reporting of this class of events. These modes are detailed below:
Page 2
30 December 2003
unsolicited
response to
SCADA master
unsolicited
reporting is
enabled
at the configured
time of day
Class 3
event queue
(see note 1)
Analogue change events with time
Notes:
1. The choice of class 3 is arbitrary, using class 1 or class 2
can also achieve the required functionality.
at 00:00:00 and
repeated every
15 minutes
solicited
response to
SCADA master
Class 3
event queue
(see note 1)
unsolicited
reporting is
disabled
Notes:
1. The choice of class 3 is arbitrary, using class 1 or class 2
can also achieve the required functionality.
3. Eventing
Eventing was achieved by configuring the events generated from binary inputs associated with noncritical status conditions (either real inputs or pseudo inputs derived from the IEC 61131-3 user
program) to class 2.
The SCADA master ensures that unsolicited reporting is disabled for class 2, and thus the events are
not reported until solicited by the SCADA master (typically once per day, or on-demand if the SCADA
master sees a system event that triggers a solicited read).
Page 3
30 December 2003
4. Alarming
Alarming was achieved by the user configuring the events generated from binary inputs associated
with critical alarm conditions (either real inputs or soft inputs derived from IEC 61131-3 user program)
to class 1.
The SCADA master ensures that unsolicited reporting is enabled for class 1. Thus alarm events are
reported in unsolicited responses to the SCADA master as soon as they occur.
5. Remote configuring
Remote configuring was only partially defined for the initial application. The user had no requirement
to remotely load the IEC 61131-3 user program. This is a desired future requirement, to be provided
once the general scope of remote loading is analyzed across the complete group of UK water users. It
is expected that this requirement can be satisfied by using file control objects (DNP Object Group 70).
However, the UK user required sending a limited set of configuration values to the outstation from the
SCADA master. These values are used at the outstation by the locally defined IEC 61131-3 program.
This requirement was satisfied by the outstation analogue output pseudo points that are locally
configured with default values. The master writes values to output points at RTU restart time. The IEC
61131-3 program uses the values stored in these pseudo analogue outputs for its computations. At any
time the SCADA master can set new values by issuing a command to the respective point using an
analogue output block object (DNP Object Group 41) and the select and operate function codes.
Future work:
This application note is the first in what is expected to be a series of application notes describing the
use of DNP3 in the UK water industry. Further notes will be written when:
The industry decides that it wants to use DNP3 as its "open" protocol
The industry clearly defines its requirements
Disclaimer
Application Notes contain application information developed by users and are provided for the benefit
of other users. This note illustrates how the features of DNP3 were used to meet specific user
requirements. This Application Note has been reviewed by the DNP Technical Committee. It does not
contain all of the details that are mandatory for a complete DNP3 implementation, and the Committee
does not warrant that the approach taken is the only way to use DNP3 to meet the user requirements.
Page 4
30 December 2003
DNP3-2003
Intelligent Electronic Device (IED)
Certification Procedure
Subset Level 1
Version 2.3
29-Sept-03
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.
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.
Revision History
Date
18-Jan-99
15-Dec-99
Version
1.00
1.01
Sections affected
ALL
see errata sheet for 1.00
10-July-00
2.00
5-July-01
2.1
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
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
8.6.5.4, step 5
8.6.6.2.1-8.6.6.2.3, steps
9 and 12
8.2.1.2.13, step 8
21-July-02
2.2
29-Sept-03
2.3
Page i
Rev 2.3 29-Sept-03
Contents
1
2
3
4
5
6
7
8
Overview.............................................................................................................................................................................. 1
1.1
Protocol specification .................................................................................................................................................. 1
Notes.................................................................................................................................................................................... 1
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
Reference Documents .......................................................................................................................................................... 5
Pretest Review ..................................................................................................................................................................... 5
5.1
Device Profile Review ................................................................................................................................................. 5
5.2
Equipment Review....................................................................................................................................................... 5
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
Transport Layer ................................................................................................................................................................. 13
7.1
Desired Behavior ....................................................................................................................................................... 13
7.2
Test Procedure ........................................................................................................................................................... 13
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
Page ii
Rev 2.3 29-Sept-03
Page iii
Rev 2.3 29-Sept-03
Page iv
Rev 2.3 29-Sept-03
Page v
Rev 2.3 29-Sept-03
Page vi
Rev 2.3 29-Sept-03
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 IEDs compliance to level 1 of the Subset Definitions. A device must pass all of the tests to be
considered compliant to this procedure.
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.
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.
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.
Page 1
Rev 2.3 29-Sept-03
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
Rev 2.3 29-Sept-03
3 Definitions
3.1 General
Master
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:
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.
IIN1-1
IIN1-2
IIN1-3
IIN1-4
IIN1-5
IIN1-7
IIN2-0
IIN2-1
IIN2-2
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.
Class 1 event data available. Can be set at any time and does not indicate an error condition.
Class 2 event data available. Can be set at any time and does not indicate an error condition.
Class 3 event data available. Can be set at any time and does not indicate an error condition.
Time synchronization required. Can be set at any time and does not indicate an error condition.
Local mode. Set if some points are uncontrollable via DNP.
Device restart. Set only under specific conditions. Does not indicate an error condition.
Function Unknown. Generally means that the function code (octet 2 of the request header) cannot be processed.
Object Unknown. Generally means that the function code could be processed but the object group / variation
could not be processed.
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.
Page 3
Rev 2.3 29-Sept-03
Name
Object
Binary Input
22
Counter
20
23
Frozen Counter
21
32
Analog Input
30
33
31
Table 3-1
1.
2.
3.
The term significant change refers to any of the synonymous terms: event or change event.
Change Objects and Static Objects are related in that a significant change in a points static value results in the creation
of a corresponding Change Object entry
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 points 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.
2.
3.
4.
Change processing must be supported for all points in the corresponding Static Object.
The determination that a point has undergone a significant change can be determined only by using information from that
points current or past value. Decisions based on information about any other point, directly or indirectly, are explicitly
forbidden.
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.
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.
Page 4
Rev 2.3 29-Sept-03
4 Reference Documents
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
If a device generates any response requiring a higher level master to parse it, the following actions should be taken:
Page 5
Rev 2.3 29-Sept-03
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.
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.
Page 6
Rev 2.3 29-Sept-03
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.
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.
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.
Page 7
Rev 2.3 29-Sept-03
If the DUT does not support link layer confirms or link layer retries on primary transmissions, continue testing in the
next section.
Configure the device to enable link layer confirms on primary transmissions and if retries are configurable, set them to a
reasonable value.
Cycle power to the DUT.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify that the DUT sends a RESET LINK frame. Do not send a data link CONFIRM frame.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Verify that it repeats this exactly LINK RETRYCOUNT times.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify that the DUT responds with a RESET LINK frame. Send a data link CONFIRM.
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.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Verify that it repeats this exactly LINK RETRYCOUNT times.
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.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify that the DUT responds with a RESET LINK frame. Send a data link CONFIRM.
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.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Send a data link CONFIRM.
Verify that no further retries are sent.
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.
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.
If the DUT is capable of requesting data link confirmations, configure it to NOT request data link confirmations.
Page 8
Rev 2.3 29-Sept-03
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Page 9
Rev 2.3 29-Sept-03
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.
Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block of
0xD3.
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.
Send the request.
Wait several seconds.
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).
Verify that the DUT does not send an application layer response.
Repeat this test once with a different invalid function code.
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.
Wait several seconds.
Verify that the DUT does not send a link layer confirm or application layer response.
Repeat this test once with a different destination address.
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.
Page 10
Rev 2.3 29-Sept-03
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).
Send the request.
Wait several seconds.
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.
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).
Send the request.
Wait several seconds.
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.
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
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify the DUT responds with application layer data, requesting data link confirmation.
Send a CONFIRM ACK frame modified so its start octet is invalid (e.g. 0x09).
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify the DUT responds with application layer data, requesting data link confirmation.
Send a CONFIRM ACK frame modified so the start octet is correct (0x05), but the second octet is incorrect (e.g.
0xff).
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Repeat this test once with different start octet values.
Page 11
Rev 2.3 29-Sept-03
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify the DUT responds with application layer data, requesting data link confirmation.
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. 0x83). Ensure that the CRC is correct for the invalid function code value.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Repeat this test once with a different function code value.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify the DUT responds with application layer data, requesting data link confirmation.
Send a CONFIRM ACK frame modified such that the CRC is incorrect.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Repeat this test once with a different CRC value.
Page 12
Rev 2.3 29-Sept-03
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.
bit 7
FIN
Transport Header
bit 6
bits 5-0
FIR
Sequence number
Table 7-1
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 LPDUs
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.
Page 13
Rev 2.3 29-Sept-03
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
0
1
2
3
4
5
6
7
Value
ONLINE - 0=off-line, 1= on-line
RESTART - 0=normal, 1= restart
COMMUNICATION LOST - 0=normal, 1=lost
REMOTE FORCED DATA - 0=normal, 1=forced
LOCAL FORCED DATA - 0=normal, 1=forced
0
0
STATE - 0, 1
Table 8-1
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.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
If the device supports Binary Outputs verify that the DUT responds with a Binary Output Status object (Object 10
Variation 2).
Verify that the data is reported using either 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing
(qualifier 0x01).
If the device does not support Binary Outputs verify that the DUT responds with a Null Response. The device can
optionally set IIN2-1.
Verify that flag behavior complies with Section 2, Note #5.
Page 14
Rev 2.3 29-Sept-03
Page 15
Rev 2.3 29-Sept-03
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.
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.
Verify that the DUT responds by echoing the select message exactly.
Immediately issue a matching execute.
Verify that the DUT echoes the execute.
Verify that the selected control operates.
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.
If the device does support control outputs, verify that the DUT responds by echoing the select message exactly.
Immediately issue a matching execute.
Verify that the DUT echoes the execute.
Verify that the selected control operates.
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.
Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of 4.
Verify that no control point operates.
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.
Verify that the DUT responds by echoing the select message exactly.
Wait 1 second past the configured maximum select to execute delay time.
Issue a matching execute and verify that the DUT echoes the execute with the control status field set to 1[Execute
received after timeout].
Verify that no control point operates.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
8.2.1.2.6 Binary Output, SBO, Execute On Time does not match Select On Time
1.
2.
3.
4.
5.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
Page 16
Rev 2.3 29-Sept-03
8.2.1.2.7 Binary Output, SBO, Execute Off Time does not match Select Off Time
1.
2.
3.
4.
5.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
8.2.1.2.8 Binary Output, SBO, Select with supported Code, Execute with different Code
1.
2.
3.
4.
5.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
If the device is not configurable in a manner such that control points can be uninstalled or disabled, skip this section.
Configure the DUT such that all Binary Output points are uninstalled or disabled.
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.
Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set.
Verify that no control point operates.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again incrementing the application layer sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Page 17
Rev 2.3 29-Sept-03
7.
8.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
Issue the operate again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the binary output.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
Issue the operate again, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the binary output.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the binary output.
Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the mismatched operate
cleared the previous select.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the binary output.
Page 18
Rev 2.3 29-Sept-03
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.
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.
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.
If the device does support control outputs verify that the DUT responds by echoing the direct operate message exactly
with status field of 0.
Verify that the specified control operates.
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.
Verify that the DUT responds by returning an Error response with IIN2-2 set and a status code of 4.
Verify that no control operates.
8.2.2.2.3
1.
2.
3.
4.
5.
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.
Configure the DUT such that all Binary Output points are uninstalled or disabled.
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.
Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set.
Verify that no control operates.
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.
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.
Verify that the DUT does not respond.
If the device does not support control outputs, end testing of this section.
If the device does support control outputs, verify that the proper control point operates.
Page 19
Rev 2.3 29-Sept-03
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.
Verify that the DUT does not respond.
Verify that no control operates.
8.2.3.2.3
1.
2.
3.
4.
5.
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.
Configure the DUT such that all Binary Output points are uninstalled or disabled.
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.
Verify that the DUT does not respond.
Verify that no control operates.
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 TB2001001 (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.
3.
4.
5.
6.
7.
8.
9.
Review the devices profile document to understand how many control points are supported in a single request. If this
number is one, skip to step 7.
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.
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.
Immediately issue a matching execute.
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.
Verify that each of the selected controls operated. Note that controls may execute simultaneously or sequentially one
after the other.
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.
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.
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.
Page 20
Rev 2.3 29-Sept-03
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.
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.
If the DUT does not have installed binary output points skip this section.
If the DUT does not have installed complementary function binary output points skip this section.
If the DUT does not support the 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) pair skip to step 8.
Issue a valid control sequence to the first installed complementary function binary output point using control code 0x03
(Latch On/NUL).
Verify the control operation completes successfully.
Issue a valid control sequence to an installed complementary function binary output point using control code 0x04 (Latch
Off/NUL).
Verify the complementary control operation completes successfully.
If the DUT does not support the 0x41(Pulse On/Close) and 0x81 (Pulse On/Trip) pair skip to step 13.
Issue a valid control sequence to an installed complementary function binary output point using control code 0x41(Pulse
On/Close).
Page 21
Rev 2.3 29-Sept-03
If the DUT does not have installed binary output points skip this section.
If the DUT does not have installed single function binary output points skip this section.
For any point that is tested below, determine what action should happen when the control executes.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x01 (Pulse
On/NUL).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x03 (Latch
On/NUL).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x04 (Latch
Off/NUL).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x41 (Pulse
On/Close).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x81 (Pulse
On/Trip).
Verify the control operation in step 3 completes successfully.
Page 22
Rev 2.3 29-Sept-03
Value
ONLINE - 0=off-line, 1= on-line
RESTART - 0=normal, 1= restart
COMMUNCATION LOST - 0=normal, 1=lost
REMOTE FORCED DATA - 0=normal, 1=forced
LOCAL FORCED DATA - 0=normal, 1=forced
0
0
0
Table 8-2
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.
Issue a Direct Operate to Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an
appropriate value.
Issue a request for Object 40 Variation 0 using the all data qualifier 0x06.
If the device supports Analog Outputs verify that the DUT responds with an Analog Output Status object (object 40
Variation 2).
Verify that the data is reported using either 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing
(qualifier 0x01).
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.
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.
Page 23
Rev 2.3 29-Sept-03
Page 24
Rev 2.3 29-Sept-03
Issue a select using Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an appropriate
value.
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 Output SBO.
Verify that the DUT responds by echoing the select message exactly.
Immediately issue a matching execute.
Verify that the DUT echoes the execute.
Verify that the selected analog output operates.
Issue a select using Object 41 Variation 2 to a different point using 8 bit indexing (qualifier 0x17) and an appropriate
value.
If the device does support analog outputs, verify that the DUT responds by echoing the select message exactly.
Immediately issue a matching execute.
Verify that the DUT echoes the execute.
Verify that the selected analog output operates.
Issue a select using Object 41 Variation 2 to an uninstalled point using 16 bit indexing (qualifier 0x28) and an
appropriate value.
Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of 4.
If an analog output is observed to operate, the test fails.
Issue a select using Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an appropriate
value.
Verify that the DUT responds by echoing the select message exactly.
Wait 1 second past the configured maximum select to execute delay time.
Issue a matching execute and verify that the DUT echoes the execute with the status field set to 1 [Execute received after
timeout].
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.
2.
3.
4.
5.
Issue a select using Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an appropriate
value.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the status field set to 2 [No previous matching select].
If an analog output is observed to operate, the test fails.
Issue a select using Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an appropriate
value.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
If an analog output is observed to operate, the test fails.
Page 25
Rev 2.3 29-Sept-03
If the device is not configurable in a manner such that analog output points can be uninstalled or disabled, skip this
section.
Configure the DUT such that all Analog Output points are uninstalled or disabled.
Issue a select using Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier 0x28) and an appropriate value.
Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set.
If an analog output is observed to operate, the test fails.
If the DUT does not have installed analog output points, skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
If the DUT does not have installed analog output points, skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again incrementing the application layer sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
If the DUT does not have installed analog output points, skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
Issue the operate again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT does not operate the analog output.
If the DUT does not have installed analog output points, skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
Issue the operate again, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the analog output.
If the DUT does not have installed analog output points, skip this section.
Page 26
Rev 2.3 29-Sept-03
2.
3.
4.
5.
6.
7.
8.
9.
Issue a Direct Operate to Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an
appropriate value.
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.
If the device does support analog outputs verify that the DUT responds by echoing the direct operate message exactly
with status field of 0.
Verify that the specified analog output operates.
Issue a Direct Operate to Object 41 Variation 2 to an uninstalled point using 16 bit indexing (qualifier 0x28) and an
appropriate value.
Verify that the DUT responds by return an Error Response with IIN2-2 set and a status code of 4.
If an analog output is observed to operate, the test fails.
8.4.2.2.3
1.
2.
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.
Configure the DUT such that all Analog Output points are uninstalled or disabled.
Page 27
Rev 2.3 29-Sept-03
3.
4.
5.
Issue a direct operate to Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier 0x28) and an appropriate value.
Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set.
If an analog output is observed to operate, the test fails.
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.
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.
Verify that the DUT does not respond.
If the device does not support analog outputs, end testing of this section.
If the device does support analog outputs, verify that the proper analog output point operates.
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.
Verify that the DUT does not respond.
If an analog output is observed to operate, the test fails.
8.4.3.2.3
1.
2.
3.
4.
5.
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.
Configure the DUT such that all Analog Output points are uninstalled or disabled.
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.
Verify that the DUT does not respond.
If an analog output is observed to operate, the test fails.
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 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 analog output point by returning an error response with IIN2-2 set
and a status code of 4.
Review the devices profile document to understand how many analog output points are supported in a single request. If
this number is one, skip to step 7.
Page 28
Rev 2.3 29-Sept-03
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
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
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.
Immediately issue a matching execute.
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.
Verify that each of the selected analog outputs occurred. . Note outputs may occur simultaneously or sequentially one
after the other.
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.
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.
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.
If the DUT does not support direct operate, skip to step 13.
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.
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).
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.
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.
Page 29
Rev 2.3 29-Sept-03
Object
1
1
10
20
20
20
20
30
30
30
30
40
Variation
1
2
2
1
2
5
6
1
2
3
4
2
Qualifier
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
Device responds to a Class 0 poll with the current state of all data.
Issue a request for Object 60 Variation 1 using the all data qualifier 0x06.
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.
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.
Page 30
Rev 2.3 29-Sept-03
Object
2
2
2
22
22
32
32
51
51
Variation
1
2
3
1
2
1
2
1
2
Qualifier
0x17,0x28
0x17,0x28
0x17,0x28
0x17,0x28
0x17,0x28
0x17,0x28
0x17,0x28
0x07
0x07
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 objects
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.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
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.
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.
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.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 1 event data.
Issue another request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with all the Class 1 event data generated in a single response.
Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first).
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Page 31
Rev 2.3 29-Sept-03
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 1 events.
Issue a request for Object 60 Variation 2 using the limit data qualifier 0x07 requesting some changes.
Verify that the device responds with the requested Class 1 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 2 using the limit data qualifier 0x07 requesting the remaining changes.
Verify that device responds with the remaining Class 1 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 1 events.
Issue a request for Object 60 Variation 2 using the limit data qualifier 0x08 requesting some changes.
Verify that the device responds with the requested Class 1 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 2 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that device responds with the remaining Class 1 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 1 event data.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with all the Class 1 event data.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Do not issue an application layer confirm to the device.
Wait for a period of time exceeding several of the Application Layer retry delays, if one exists.
Verify that the device has not retransmitted the previous Application Layer fragment.
Generate additional Class 1 event data.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with the same Class 1 event data and the additional data generated in step 14.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Page 32
Rev 2.3 29-Sept-03
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.
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.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
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.
If the DUT does not support Class 2 events, verify that it responds with a Null Response. No further testing is required in
this section.
If the DUT does support Class 2 events, verify that the device responds with all the event data in its event buffers or
responds with a Null Response.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 2 event data.
Issue another request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with all the Class 2 event data generated in a single response.
Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first).
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 2 events.
Page 33
Rev 2.3 29-Sept-03
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Issue a request for Object 60 Variation 3 using the limit data qualifier 0x07 requesting some changes.
Verify that the device responds with the requested Class 2 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 3 using the limit data qualifier 0x07 requesting the remaining changes.
Verify that device responds with the remaining Class 2 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 2 events.
Issue a request for Object 60 Variation 3 using the limit data qualifier 0x08 requesting some changes.
Verify that the device responds with the requested Class 2 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 3 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that device responds with the remaining Class 2 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 2 event data.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with all the Class 2 event data.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Do not issue an application layer confirm to the device.
Wait for a period of time exceeding several of the Application Layer retry delays, if one exists.
Verify that the device has not retransmitted the previous Application Layer fragment.
Generate additional Class 2 event data.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with the same Class 2 event data and the additional data generated in step 14.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Page 34
Rev 2.3 29-Sept-03
8.5.4 Class 3
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.
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.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
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.
If the DUT does not support Class 3 events, verify that it responds with a Null Response. No further testing is required in
this section.
If the DUT does support Class 3 events, verify that the device responds with all the event data in its event buffers or
responds with a Null Response.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 3 event data.
Issue another request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with all the Class 3 event data generated in a single response.
Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first).
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 3 events.
Page 35
Rev 2.3 29-Sept-03
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Issue a request for Object 60 Variation 4 using the limit data qualifier 0x07 requesting some changes.
Verify that the device responds with the requested Class 3 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 4 using the limit data qualifier 0x07 requesting the remaining changes.
Verify that device responds with the remaining Class 3 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 3 events.
Issue a request for Object 60 Variation 4 using the limit data qualifier 0x08 requesting some changes.
Verify that the device responds with the requested Class 3 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 4 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that device responds with the remaining Class 3 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 3 event data.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with all the Class 1 event data.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Do not issue an application layer confirm to the device.
Wait for a period of time exceeding several of the Application Layer retry delays, if one exists.
Verify that the device has not retransmitted the previous Application Layer fragment.
Generate additional Class 3 event data.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with the same Class 1 event data and the additional data generated in step 14.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Page 36
Rev 2.3 29-Sept-03
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known event data that includes events from all three classes.
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06.
Verify that the device responds with all the event data as described in the Desired Behavior.
Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first).
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known event data that includes events from classes 1, 2, and 3.
Issue a request for Object 60 Variations 2,3,4, and 1 using the all data qualifier 0x06.
Verify that the device responds with all the event data as described in the Desired Behavior.
Verify that all static data is returned after all event data in the same response.
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.
Verify that only objects in tables 8-3 and 8-4 are returned.
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.
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
The device must respond to a request for Class 1 events with only Class 1 events.
Page 37
Rev 2.3 29-Sept-03
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.
Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending events.
Verify that only objects in table 8-4 are returned.
If the response is not Null, verify that the device requests an application layer confirm.
Generate some Class 1 events.
Generate some Class 2 events.
Generate some Class 3 events.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with only Class 1 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with only Class 2 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with only Class 3 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06.
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.
Page 38
Rev 2.3 29-Sept-03
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.
Issue a request for Object 60 Variation 1, Qualifier 0x06, using a Function Code of 0x70.
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.
Issue a request for Object 60 Variation 1, Qualifier 0x06, using a Function Code of 0x01.
Verify that the device responds with none of the Error IIN bits set.
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.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.
If the device supports individual control point supervisory control, each object must set the Local Forced Data bit when
the corresponding point is in the Local or Disabled state.
8.6.4.2 Test Procedure for Devices with Global Remote Supervisory Control
1.
2.
3.
4.
5.
6.
7.
If the DUT does not support placing its binary outputs in a local state no further testing is required in this section.
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.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a valid message and that IIN1-5 is cleared.
Change the DUTs global switch to the Disabled or Local mode.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
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.
2.
3.
4.
If the DUT does not support placing its binary outputs in a local state, no further testing is required in this section.
If the device allows for individual control point remote supervisory control, all points should be set to the Enabled or
Remote mode.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with Object 10 Variation 2 and that IIN1-5 is cleared.
Page 39
Rev 2.3 29-Sept-03
5.
6.
7.
8.
9.
Verify that each object has the "On-line" bit is set, the "State" bit either set or cleared, and all the remaining bits clear.
Change a single remote supervisory control switch or setting to the Disabled or Local mode.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with Object 10 Variation 2 and that IIN1-5 is set.
Verify that the appropriate object has the "On-line" bit is set, the "State" bit either set or cleared, the "Local forced data"
bit set, and all the remaining bits clear.
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.
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.
Verify the requested output operation was executed.
Wait a reasonable application layer timeout, for example, 2 seconds.
Verify that the device does not respond.
Issue a request for Object 60 Variation 2.
Verify the DUT responds with IIN1-0 (all stations message received) set.
Send an application layer confirmation if requested.
Issue a request for Object 60 Variation 2.
Verify the DUT responds with a Null Response with IIN1-0 cleared.
Page 40
Rev 2.3 29-Sept-03
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.
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 an application layer confirmation.
10. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change.
11. Verify that the device returns a single Binary Input Change Event and IIN2-3 is not set.
12. Issue an application layer confirmation.
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.
Page 41
Rev 2.3 29-Sept-03
2.
3.
Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending events.
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 an application layer confirmation.
10. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change.
11. Verify that the device returns a single Analog Input Change Event and IIN2-3 is not set.
12. Issue an application layer confirmation.
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 an application layer confirmation.
10. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change.
11. Verify that the device returns a single Binary Counter Change Event and IIN2-3 is no longer set.
12. Issue an application layer confirmation.
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.
The device must respond to a Delay Measurement request with a Time Delay Fine response.
Issue a request for Delay Measurement using Function Code 23, to the DUT.
Page 42
Rev 2.3 29-Sept-03
2.
3.
4.
Verify that the device replies with Object 52 Variation 2 Qualifier 0x07 Quantity 1 and a millisecond time stamp of the
measured delay.
Verify that the accuracy of the delay reported is within the maximum error specified in the Device Profile Document.
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).
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.
The device must respond to a Cold Restart request by sending a Time Delay response, restarting, and setting IIN1-7.
Issue a request for Cold Restart using Function Code 13, to the DUT.
Verify the response is a Time Delay Fine or Coarse (Object 52 Variation 1 or Variation 2).
If the DUT requests an Application Layer Confirm send it before starting the wait period.
Wait for a period of time longer than the time returned in step 2.
Issue a request for Object 60 Variation 1.
Verify that the device responds with IIN1-7 set indicating that the device has been restarted.
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.
Verify that the device responds with a Null Response and that IIN1-7 is cleared.
Page 43
Rev 2.3 29-Sept-03
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.
If the DUT has a configurable fragment size, configure it to be no more than 2048 octets.
Cycle power to the DUT.
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 DUTs 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 DUTs 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 DUTs 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.
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).
Page 44
Rev 2.3 29-Sept-03
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.
Verify that the DUT responds with valid data.
Verify that the CON bit is set in the first fragment.
Verify the sequence number matches the request.
Wait the application confirmation timeout for the DUT. Do not send an application confirmation.
Verify the DUT does not send the next fragment because it did not receive confirmation of the first fragment.
Send the valid application layer confirmation.
Verify the DUT does not send the next fragment because it has timed out.
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.
Verify that the CON bit is set in the first fragment.
Wait a time period less than the application confirmation timeout. Verify the DUT does not send the second fragment
yet.
Send the valid application layer confirmation before the application confirmation timeout.
Verify that the DUT sends the second fragment (with FIR, FIN and sequence number set correctly).
Verify that the CON bit is set in the second fragment if a third fragment is expected.
If a third fragment is expected, skip to step 16. If not, first send a valid application layer confirmation and then a request
for multi-fragment data as in steps 1-3.
Send an application layer confirmation with an incorrect sequence number.
Wait the application layer confirmation timeout for the DUT. Do not send an application confirmation.
Verify the DUT does not send the next fragment because the confirmation it received was invalid.
Send the valid application layer confirmation.
Verify the DUT does not send the next fragment because it has timed out.
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.
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.
Connect the DUT and at least two additional DNP devices to the same communications drop.
Connect an oscilloscope and/or protocol analyzer to the DUT communications signals.
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.
Verify that the DUT does not respond in any way, including raising carrier or asserting RTS.
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to the broadcast address.
Verify that the DUT does not respond in any way, including raising carrier or asserting RTS.
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to the DUT.
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.
Page 45
Rev 2.3 29-Sept-03
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
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
At all times:
Application layer sequence numbers (the value of bits 04 of the application layer control field) must be in the correct
range for all messages sent: 015 for polled responses and 1631 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.
Page 46
Rev 2.3 29-Sept-03
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 events, 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
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.1
1.
2.
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.
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.
Page 47
Rev 2.3 29-Sept-03
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
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.)
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.
Cycle power to the DUT.
Verify that the DUT transmits an initial unsolicited response to the configured Master destination address.
Use the off-line configuration capability to configure the destination address to a different destination address.
Cycle power to the DUT.
Verify that an initial unsolicited response is transmitted by the DUT.
Verify that the unsolicited response contains the restart bit (IIN1-7) set.
Verify that the unsolicited response is null (contains no data).
Verify that the unsolicited response requests an application layer confirmation.
Verify that the application sequence number is in the correct range.
Verify that it has been transmitted to the configured Master destination address.
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.
Verify that the restart bit (IIN1-7) remains set in these unsolicited responses.
Verify that the unsolicited responses are null (contains no data).
Verify that the unsolicited responses request application layer confirmations.
Issue a request to clear the restart bit (IIN1-7).
Verify that the DUT responds with a null response that has the restart bit (IIN1-7) cleared.
Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT.
Verify that the restart bit (IIN1-7) is clear in the unsolicited responses.
Issue a READ request (function code 0x01) for Object 60 Variation 1 (class 0) using the all data qualifier 0x06.
Verify that the DUT responds to the READ request with class 0 data.
Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT.
Issue an application layer confirmation of the unsolicited response, but use an incorrect application-layer sequence
number.
Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT.
Issue an application-layer confirmation of the unsolicited response, and use the correct application-layer sequence
number.
Generate known events.
Verify that no further unsolicited responses are transmitted by waiting for such responses for at least 5 seconds.
8.11.2.2
1.
2.
3.
4.
5.
6.
7.
8.
9.
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
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.
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.
Issue a request to enable unsolicited responses for Class 1 data by using function code 0x14, object 60, Variation 2.
Verify that the DUT responds with a null response indicating the request was processed without error.
If it is not possible to generate Class 1 data that would generate unsolicited responses, steps 8 through 14 are not
applicable.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Verify that the unsolicited response requests an application layer confirmation.
Page 48
Rev 2.3 29-Sept-03
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.
8.11.2.3
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
If the DUT has Class 2 data, generate such data. For example, if there is a binary input change event that is (or can be
assigned to) Class 2, then ensure that it is assigned to Class 2, and generate one such event.
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.
Issue a request to enable unsolicited responses for Class 2 data by using function code 0x14, Object 60, Variation 3.
Verify that the DUT responds with a null response indicating the request was processed without error.
If it is not possible to generate Class 2 data that would generate unsolicited responses, steps 8 through 14 are not
applicable.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Verify that the unsolicited response requests an application layer confirmation.
Verify that the application sequence number is in the correct range.
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.
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.)
Issue an application layer confirmation of the unsolicited response, but use an incorrect application-layer sequence
number.
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.
Issue an application-layer confirmation of the unsolicited response, and use the correct application-layer sequence
number.
If the DUT has Class 1 data, then generate such data. If the DUT has Class 3 data, then also generate Class 3 data.
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.
8.11.2.4
1.
2.
3.
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
If the DUT has Class 3 data, generate such data. For example, if there is a binary input change event that is (or can be
assigned to) Class 3, then ensure that it is assigned to Class 3, and generate one such event.
Page 49
Rev 2.3 29-Sept-03
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
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.
Issue a request to enable unsolicited responses for Class 3 data by using function code 0x14, Object 60, Variation 4.
Verify that the DUT responds with a null response indicating the request was processed without error.
If it is not possible to generate Class 2 data that would generate unsolicited responses, steps 8 through 14 are not
applicable.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Verify that the unsolicited response requests an application layer confirmation.
Verify that the application sequence number is in the correct range.
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.
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.)
Issue an application layer confirmation of the unsolicited response, but use an incorrect application-layer sequence
number.
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.
Issue an application-layer confirmation of the unsolicited response, and use the correct application-layer sequence
number.
If the DUT has Class 1 data, then generate such data. If the DUT has Class 2 data, then also generate Class 2 data.
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.
8.11.2.5
This is a complicated test procedure. The test has been divided into sections for clarity.
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
Generate class 1, 2, or 3 event data.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Verify that the unsolicited response requests an application layer confirmation.
Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited
response to be sent.
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).
Verify that the DUT immediately responds without error.
Wait for the unsolicited confirmation timeout to expire, and verify that another unsolicited response is transmitted by the
DUT.
Page 50
Rev 2.3 29-Sept-03
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.
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.
Wait for an amount of time less than the unsolicited confirmation timeout and verify that the DUT does not respond.
Issue an application-layer confirmation of the unsolicited response before the unsolicited confirmation timeout occurs.
Verify that the device immediately transmits a response to the READ request.
Verify that none of the event data transmitted by the unsolicited response is contained in the polled response.
If the polled response requested an application layer confirmation, then issue an application-layer confirmation of the
polled response.
Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited
response to be sent.
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.
Verify that the DUT does not respond within the unsolicited confirmation timeout.
After the unsolicited confirmation timeout, verify that the device responds with a polled response to the READ request
(and not an unsolicited response).
Verify that the polled response contains at least the same event data that was in the unsolicited response that was not
confirmed.
Verify that the polled response requests an application layer confirmation.
Issue an application-layer confirmation of the polled response to clear the device of event data.
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.
Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited
response to be sent.
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.
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).
Verify that the DUT immediately responds without error.
Wait for the unsolicited confirmation timeout to expire, and then verify that another unsolicited response is transmitted
by the DUT.
Verify that the event data in this unsolicited response includes the events reported in the previous unsolicited response
that was not confirmed.
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.
Before the unsolicited confirmation timeout, issue a READ request for Object 60, Variations 2, 3, and 4, using the all
data qualifier 0x06.
Verify that the DUT does not respond within the unsolicited confirmation timeout.
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).
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.
Page 51
Rev 2.3 29-Sept-03
6.
7.
8.
9.
Verify that the polled response contains at least the same event data that was in the unsolicited response that was not
confirmed.
Verify that the polled response requests an application layer confirmation.
Issue an application-layer confirmation of the polled response to clear the device of event data.
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.
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.
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.
Cycle power to the DUT.
Issue an application-layer confirmation of the initial unsolicited response.
Issue a request to clear the restart bit (IIN1-7).
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
Generate class 1, 2, or 3 event data.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Do not issue an application layer confirm.
Verify that DUT retries the response 5 times.
Cycle power to the DUT.
Issue an application-layer confirmation of the initial unsolicited response.
Issue a request to clear the restart bit (IIN1-7).
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
Generate class 1, 2, or 3 event data.
Verify that an unsolicited response is transmitted.
Issue an application layer confirm after at least one retry. Verify that retries are terminated when confirmation is
received.
Configure the maximum number of retries to indefinite.
Page 52
Rev 2.3 29-Sept-03
20.
21.
22.
23.
24.
25.
26.
27.
28.
8.11.2.6
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Page 53
Rev 2.3 29-Sept-03
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 masters priority, the
master would not have a random delay.
Request Class 1 data (Object 60 Variation 2) using Qualifier Code 0x06 and link control block 0xC4.
Verify the device responds with data. Measure the turnaround delay between receipt of the request and the response.
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.
Page 54
Rev 2.3 29-Sept-03
LSB
1
DIR
FCB
FCV
Primary
PRM
FUNCTION CODE
DIR
PRM
FCB
FCV
DFC
DFC
Secondary
3
1 = Master, 0 = Remote
1 = Data Link Request, 0 = Data Link Response
Frame Count Bit, alternates 1 and 0
Frame Count Valid; 1 = valid, 0 = invalid
Data Flow Control; 1 = no buffers left
Function Codes:
Primary Frames (PRM=1)
Fn Code
Function
Frame Type
FCV
RESET link
SEND/CONFIRM
SEND/CONFIRM
TEST link
SEND/CONFIRM
User Data
SEND/CONFIRM
User Data
SEND/NO REPLY
REQUEST/RESPOND
Function
Frame Type
ACK
CONFIRM
NACK
CONFIRM
11
Link Status
RESPOND
Page 55
Rev 2.3 29-Sept-03
From
Remote
From
Master
Function
00
80
ACK
01
81
NACK
Failed transaction
0B
8B
No flow Control
10
90
ACK
11
91
NACK
1B
9B
No buffers available
40
C0
RESET LINK
41
C1
44
C4
49
C9
52
D2
Test Link
FCB = 0
53
D3
FCB = 0
60
E0
RESET LINK
FCB = 1 ignored
61
E1
FCB = 1 ignored
64
E4
FCB = 1 ignored
69
E9
FCB = 1 ignored
72
F2
Test Link
FCB = 1
73
F3
FCB = 1
Other
Frame Header:
Byte
Name
05
64
LEN
CTRL
DEST
SOURCE
9
CRC
10
11
TH
Page 56
Rev 2.3 29-Sept-03
DNP
APDU
APCI
DUI
Message Header
Request Header
Appl.
Ctrl
IO
DUI
Object Header
Data
IO
Object Header
Data
Response Header
Func
Code
Appl.
Ctrl
Func
Code
Internal
Indication
Object
Group
Object
Variation
Qualifier
Range
APCI
Application
Protocol
Control
Information
DUI
Data Unit
Identifier
IO
Information
Object
CLASS 1
4 3
Depends on
Qualifier
Code
ALL STATIONS
CLASS 2
CLASS 3
NEED TIME
LOCAL
SECOND OCTET
7
BAD FUNCTION
Application
Protocol Data
Unit
OUT OF RANGE
OBJECT UNKNOWN
APDU
ALREADY EXEC
Distributed
Network
Protocol
BUFFER OVERFLOW
FIRST OCTET
BAD CONFIG
DNP
0x00 Confirm
0x00 Confirm
0x01 Read
0x81 Response
0x02 Write
0x82 Unsolicited
Response
0x03 Select
0x04 Operate
0x05 Direct Operate
0x06 Direct Op, No Ack
0x07 Immediate Freeze
0x08 Immediate Freeze No Ack
0x09 Freeze and Clear
0x0A Freeze and Clear No Ack
0x0B Freeze with Time
0x0C Freeze with Time No Ack
0x0D Cold Restart
0x0E Warm Restart
0x0F Init Data to Defaults
0x10 Initialize Application
0x11 Start Application
0x12 Stop Application
0x13 Save Configuration
0x14 Enable Unsolicited Msgs
0x15 Disable Unsolicited Msgs
0x16 Assign Class
0x17 Delay Measurement
0x18 Record Current Time
RESTART
DEV. TROUBLE
RESERVED
RESERVED
SEQUENCE
UNSOLICITED
FINAL
CONFIRM
FIRST
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
Page 57
Rev 2.3 29-Sept-03
DNP3-2003
Intelligent Electronic Device (IED)
Certification Procedure
Subset Level 2
Version 2.3
29-Sept-03
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.
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.
Revision History
Date
Version
Sections affected
18-Jan-99
15-Dec-99
1.00
1.01
ALL
see errata sheet for 1.00
10-July-00
2.00
5-July-01
2.1
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
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
8.5.1, Table 8-3
8.6.5.4, step 5
8.6.6.2.1-8.6.6.2.3, steps 9
and 12
8.14.2.10-8.14.2.11, step 4
8.14.2.13-8.14.2.14, step 4
8.14.2.15, steps 4 and 6
8.16.2.2.5, step 9
Initial Release
Fixes inconsistencies and errors
Designates protocol as DNP3-1999 (formerly DNP V3.00 with
extensions)
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
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
21-July-02
8-Sept-03
2.2
2.3
8.2.1.2.13, step 8
8.14.2.9, step 2 (plus others
in same section)
8.14 (several subsections)
8.16.1.2,Tables 8-3,8-4
8.16.1.2.2 and 8.16.2.2.2
6.6.3.2, step 3
8.15
8.4.1.2.1, step 2
8.4.3.2.1, step 3
8.5.5.2.2, step 9
8.19.2.1, step 14
8.9.2.2, steps 14 and 15
8.11.2.6, step 7
8.12.2, step 1
8.6.4
Page ii
Rev 2.3 29-Sept-03
Contents
1
2
3
4
5
6
7
8
Overview
1.1
Protocol specification
Notes
Definitions
3.1
General
3.2
Internal Indications
3.3
Error Responses
3.4
Changes or Events
3.4.1
Rules
Reference Documents
Pretest Review
5.1
Device Profile Review
5.2
Equipment Review
Link Layer
6.1
Reset Link and Passive Confirm support
6.1.1
Desired Behavior
6.1.2
Test Procedure
6.2
Test Link
6.2.1
Desired Behavior
6.2.2
Test Procedure
6.3
Request Link Status
6.3.1
Desired Behavior
6.3.2
Test Procedure
6.4
Test Retries
6.4.1
Desired Behavior
6.4.2
Test Procedure
6.5
DIR and FCV Bits
6.5.1
Desired Behavior
6.5.2
Test Procedure
6.6
Data Link Rejects Invalid Frames
6.6.1
Desired Behavior
6.6.2
Test Procedure Primary Frames
6.6.2.1 Invalid Start Octets
6.6.2.2 Invalid Primary Function Code
6.6.2.3 Invalid Destination Address
6.6.2.4 Invalid CRC
6.6.2.5 Invalid FCV
6.6.3
Test Procedure Secondary Frames
6.6.3.1 Invalid Start Octets
6.6.3.2 Invalid Secondary Function Code
6.6.3.3 Invalid Destination Address
6.6.3.4 Invalid CRC
Transport Layer
7.1
Desired Behavior
7.2
Test Procedure
Application Layer
8.1
Binary Output Status
8.1.1
Desired Behavior
8.1.2
Test Procedure
8.2
Binary Outputs
8.2.1
Select Before Operate
8.2.1.1 Desired Behavior
1
1
1
3
3
3
3
4
4
5
5
5
5
6
6
6
6
7
7
7
7
7
7
8
8
8
8
8
8
9
9
9
10
10
10
10
11
11
11
12
12
12
13
13
13
14
14
14
14
14
15
15
Page iii
Rev 2.3 29-Sept-03
16
16
16
16
16
16
16
17
17
17
17
17
17
18
18
18
18
18
19
19
19
19
19
19
19
19
20
20
20
20
20
21
21
21
21
22
23
23
23
23
24
24
25
25
25
25
25
25
25
26
26
26
26
26
26
Page iv
Rev 2.3 29-Sept-03
27
27
27
27
27
27
28
28
28
28
28
28
28
28
28
29
29
30
30
30
31
31
31
31
32
32
33
33
33
33
33
34
34
35
35
35
35
35
36
36
37
37
37
37
37
37
37
38
38
38
38
38
39
39
39
Page v
Rev 2.3 29-Sept-03
Object Unknown
8.6.3
8.6.3.1 Desired Behavior
8.6.3.2 Test Procedure
8.6.4
Local
8.6.4.1 Desired Behavior
8.6.4.2 Test Procedure for Devices with Global Remote Supervisory Control
8.6.4.3 Test Procedure for Devices with Individual Remote Supervisory Control
8.6.5
Broadcast Address and All Stations Indication
8.6.5.1 Desired Behavior
8.6.5.2 Test Procedure
8.6.5.3 Test Procedure
8.6.5.4 Test Procedure, Confirmed Response Options
8.6.6
Buffer Overflow
8.6.6.1 Desired Behavior
8.6.6.2 Test Procedure
8.6.6.2.1
Buffer Overflow, Binary Input Change Event Buffers
8.6.6.2.2
Buffer Overflow, Analog Input Change Event Buffers
8.6.6.2.3
Buffer Overflow, Binary Counter Change Event Buffers
8.7
Time
8.7.1
Delay Measurement
8.7.1.1 Desired Behavior
8.7.1.2 Test Procedure
8.7.2
Synchronization
8.7.2.1 Desired Behavior
8.7.2.2 Test Procedure
8.8
Cold Restart
8.8.1
Desired Behavior
8.8.2
Test Procedure
8.9
Application Layer Fragmentation
8.9.1
Use of FIR, FIN and SEQUENCE in Fragmentation
8.9.1.1 Desired Behavior
8.9.1.2 Test Procedure
8.9.2
Use of Confirmation in Fragmentation
8.9.2.1 Desired Behavior
8.9.2.2 Test Procedure
8.10 Multi-Drop Support
8.10.1 Desired Behavior
8.10.2 Test Procedure
8.11 Unsolicited Responses
8.11.1 Desired Behavior
8.11.1.1 Configuration
8.11.1.2 Sequence Numbers and Confirmation
8.11.1.3 Restart Behavior
8.11.1.4 Runtime Behavior
8.11.1.5 Unsolicited and Polled Responses
8.11.2 Test Procedure
8.11.2.1 Unsolicited Response Configuration/Startup
8.11.2.2 Unsolicited Response - Class 1 Data
8.11.2.3 Unsolicited Response - Class 2 Data
8.11.2.4 Unsolicited Response - Class 3 Data
8.11.2.5 Unsolicited and Polled Responses
8.11.2.5.1
Transmits data-filled unsolicited responses
8.11.2.5.2
Clears transmitted data upon confirmation
8.11.2.5.3
Processes non-READ requests immediately
8.11.2.5.4
Defers READ requests until after confirmation received
DNP3-2003 IED Certification Procedure
Subset Level 2
39
39
39
39
39
39
39
40
40
40
40
41
41
41
41
41
41
42
42
42
42
42
43
43
43
43
43
43
44
44
44
44
44
44
45
45
45
45
46
46
46
46
46
47
47
47
47
48
49
49
50
50
50
50
51
Page vi
Rev 2.3 29-Sept-03
51
51
51
52
52
53
53
54
54
55
55
55
55
55
55
55
56
56
56
56
56
57
57
57
58
58
58
59
59
59
60
60
61
61
61
62
63
63
63
63
63
64
64
64
64
64
64
65
65
65
66
66
66
66
66
Page vii
Rev 2.3 29-Sept-03
66
67
67
67
68
68
68
68
68
68
69
69
69
69
70
70
70
71
Page viii
Rev 2.3 29-Sept-03
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 IEDs compliance to Level 2 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-2003.
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.
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.
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.
Page 1
Rev 2.3 29-Sept-03
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
Rev 2.3 29-Sept-03
3 Definitions
3.1
General
Master
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:
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
IIN
IIN1-1
IIN1-2
IIN1-3
IIN1-4
IIN1-5
IIN1-7
IIN2-0
IIN2-1
IIN2-2
3.3
Internal Indications
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.
Class 1 event data available. Can be set at any time and does not indicate an error condition.
Class 2 event data available. Can be set at any time and does not indicate an error condition.
Class 3 event data available. Can be set at any time and does not indicate an error condition.
Time synchronization required. Can be set at any time and does not indicate an error condition.
Local mode. Set if some points are uncontrollable via DNP.
Device restart. Set only under specific conditions. Does not indicate an error condition.
Function Unknown. Generally means that the function code (octet 2 of the request header) cannot be processed.
Object Unknown. Generally means that the function code could be processed but the object group / variation
could not be processed.
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.
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.
Page 3
Rev 2.3 29-Sept-03
3.4
Changes or Events
Name
Object
Binary Input
22
Counter
20
23
Frozen Counter
21
32
Analog Input
30
33
31
Table 3-1
1.
2.
3.
The term significant change refers to any of the synonymous terms: event or change event.
Change Objects and Static Objects are related in that a significant change in a points static value results in the creation
of a corresponding Change Object entry
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 points 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.
2.
3.
4.
Change processing must be supported for all points in the corresponding Static Object.
The determination that a point has undergone a significant change can be determined only by using information from that
points current or past value. Decisions based on information about any other point, directly or indirectly, are explicitly
forbidden.
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.
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.
Page 4
Rev 2.3 29-Sept-03
4 Reference Documents
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
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:
If a device generates any response requiring a higher level master to parse it, the following actions should be taken:
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 manufacturers representative should be available by phone to answer questions during the testing of the device.
Page 5
Rev 2.3 29-Sept-03
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
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.
Page 6
Rev 2.3 29-Sept-03
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
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.3
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.
Page 7
Rev 2.3 29-Sept-03
6.4
Test Retries
If the DUT does not support link layer confirms or link layer retries on primary transmissions, continue testing in the
next section.
Configure the device to enable link layer confirms on primary transmissions and if retries are configurable, set them to a
reasonable value.
Cycle power to the DUT.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify that the DUT sends a RESET LINK frame. Do not send a data link CONFIRM frame.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Verify that it repeats this exactly LINK RETRYCOUNT times.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify that the DUT responds with a RESET LINK frame. Send a data link CONFIRM.
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.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Verify that it repeats this exactly LINK RETRYCOUNT times.
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.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify that the DUT responds with a RESET LINK frame. Send a data link CONFIRM.
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.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Send a data link CONFIRM.
Verify that no further retries are sent.
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
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.
If the DUT is capable of requesting data link confirmations, configure it to NOT request data link confirmations.
Page 8
Rev 2.3 29-Sept-03
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
6.6
Page 9
Rev 2.3 29-Sept-03
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.
Prepare a READ request for Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and a link control block of
0xD3.
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.
Send the request.
Wait several seconds.
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).
Verify that the DUT does not send an application layer response.
Repeat this test once with a different invalid function code.
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.
Wait several seconds.
Verify that the DUT does not send a link layer confirm or application layer response.
Repeat this test once with a different destination address.
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.
Page 10
Rev 2.3 29-Sept-03
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).
Send the request.
Wait several seconds.
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.
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).
Send the request.
Wait several seconds.
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.
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
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify the DUT responds with application layer data, requesting data link confirmation.
Send a CONFIRM ACK frame modified so its start octet is invalid (e.g. 0x09).
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify the DUT responds with application layer data, requesting data link confirmation.
Send a CONFIRM ACK frame modified so the start octet is correct (0x05), but the second octet is incorrect (e.g.
0xff).
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Repeat this test once with different start octet values.
Page 11
Rev 2.3 29-Sept-03
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify the DUT responds with application layer data, requesting data link confirmation.
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. 0x83). Ensure that the CRC is correct for the invalid function code value.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Repeat this test once with a different function code value.
Request Class 0 data (Object 60 Variation 1) using Qualifier Code 0x06 and link control block 0xC4.
Verify the DUT responds with application layer data, requesting data link confirmation.
Send a CONFIRM ACK frame modified such that the CRC is incorrect.
Verify that the DUT waits LINK TIMEOUT and then retransmits the link frame.
Repeat this test once with a different CRC value.
Page 12
Rev 2.3 29-Sept-03
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.
bit 7
FIN
7.1
5.
6.
7.
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 LPDUs
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
1.
2.
3.
4.
Transport Header
bit 6
bits 5-0
FIR
Sequence number
Table 7-1
Test Procedure
Page 13
Rev 2.3 29-Sept-03
8 Application Layer
8.1
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
0
1
2
3
4
5
6
7
Value
ONLINE - 0=off-line, 1= on-line
RESTART - 0=normal, 1= restart
COMMUNICATION LOST - 0=normal, 1=lost
REMOTE FORCED DATA - 0=normal, 1=forced
LOCAL FORCED DATA - 0=normal, 1=forced
0
0
STATE - 0, 1
Table 8-1
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.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
If the device supports Binary Outputs verify that the DUT responds with a Binary Output Status object (Object 10
Variation 2).
Verify that the data is reported using either 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing
(qualifier 0x01).
If the device does not support Binary Outputs verify that the DUT responds with a Null Response. The device can
optionally set IIN2-1.
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.
Page 14
Rev 2.3 29-Sept-03
Page 15
Rev 2.3 29-Sept-03
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.
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.
Verify that the DUT responds by echoing the select message exactly.
Immediately issue a matching execute.
Verify that the DUT echoes the execute.
Verify that the selected control operates.
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.
If the device does support control outputs, verify that the DUT responds by echoing the select message exactly.
Immediately issue a matching execute.
Verify that the DUT echoes the execute.
Verify that the selected control operates.
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.
Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of 4.
Verify that no control point operates.
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.
Verify that the DUT responds by echoing the select message exactly.
Wait 1 second past the configured maximum select to execute delay time.
Issue a matching execute and verify that the DUT echoes the execute with the control status field set to 1[Execute
received after timeout].
Verify that no control point operates.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
8.2.1.2.6 Binary Output, SBO, Execute On Time does not match Select On Time
1.
2.
3.
4.
5.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
Page 16
Rev 2.3 29-Sept-03
8.2.1.2.7 Binary Output, SBO, Execute Off Time does not match Select Off Time
1.
2.
3.
4.
5.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
8.2.1.2.8 Binary Output, SBO, Select with supported Code, Execute with different Code
1.
2.
3.
4.
5.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
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.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
Verify that no control point operates.
If the device is not configurable in a manner such that control points can be uninstalled or disabled, skip this section.
Configure the DUT such that all Binary Output points are uninstalled or disabled.
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.
Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set.
Verify that no control point operates.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again incrementing the application layer sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Page 17
Rev 2.3 29-Sept-03
7.
8.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
Issue the operate again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the binary output.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the binary output.
Issue the operate again, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the binary output.
If the DUT does not have installed binary output points, skip this section.
Issue a valid select to an installed binary output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by anything but 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the binary output.
Issue a valid operate, incrementing the select sequence number by 1 modulo 16 to make sure the mismatched operate
cleared the previous select.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the binary output.
Page 18
Rev 2.3 29-Sept-03
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.
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.
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.
If the device does support control outputs verify that the DUT responds by echoing the direct operate message exactly
with status field of 0.
Verify that the specified control operates.
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.
Verify that the DUT responds by returning an Error response with IIN2-2 set and a status code of 4.
Verify that no control operates.
8.2.2.2.3
1.
2.
3.
4.
5.
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.
Configure the DUT such that all Binary Output points are uninstalled or disabled.
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.
Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set.
Verify that no control operates.
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.
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.
Verify that the DUT does not respond.
If the device does not support control outputs, end testing of this section.
If the device does support control outputs, verify that the proper control point operates.
Page 19
Rev 2.3 29-Sept-03
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.
Verify that the DUT does not respond.
Verify that no control operates.
8.2.3.2.3
1.
2.
3.
4.
5.
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.
Configure the DUT such that all Binary Output points are uninstalled or disabled.
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.
Verify that the DUT does not respond.
Verify that no control operates.
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 TB2001001 (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.
3.
4.
5.
6.
7.
8.
9.
Review the devices profile document to understand how many control points are supported in a single request. If this
number is one, skip to step 7.
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.
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.
Immediately issue a matching execute.
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.
Verify that each of the selected controls operated. Note that controls may execute simultaneously or sequentially one
after the other.
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.
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.
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.
Page 20
Rev 2.3 29-Sept-03
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.
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.
If the DUT does not have installed binary output points skip this section.
If the DUT does not have installed complementary function binary output points skip this section.
If the DUT does not support the 0x03 (Latch On/NUL) and 0x04 (Latch Off/NUL) pair skip to step 8.
Issue a valid control sequence to the first installed complementary function binary output point using control code 0x03
(Latch On/NUL).
Verify the control operation completes successfully.
Issue a valid control sequence to an installed complementary function binary output point using control code 0x04 (Latch
Off/NUL).
Verify the complementary control operation completes successfully.
If the DUT does not support the 0x41(Pulse On/Close) and 0x81 (Pulse On/Trip) pair skip to step 13.
Issue a valid control sequence to an installed complementary function binary output point using control code 0x41(Pulse
On/Close).
Page 21
Rev 2.3 29-Sept-03
If the DUT does not have installed binary output points skip this section.
If the DUT does not have installed single function binary output points skip this section.
For any point that is tested below, determine what action should happen when the control executes.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x01 (Pulse
On/NUL).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x03 (Latch
On/NUL).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x04 (Latch
Off/NUL).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x41 (Pulse
On/Close).
Verify the control operation in step 3 completes successfully.
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.
Issue a valid control sequence to the first installed single function binary output point using control code 0x81 (Pulse
On/Trip).
Verify the control operation in step 3 completes successfully.
Page 22
Rev 2.3 29-Sept-03
8.3
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
0
1
2
3
4
5
6
7
Value
ONLINE - 0=off-line, 1= on-line
RESTART - 0=normal, 1= restart
COMMUNCATION LOST - 0=normal, 1=lost
REMOTE FORCED DATA - 0=normal, 1=forced
LOCAL FORCED DATA - 0=normal, 1=forced
0
0
0
Table 8-2
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.
Issue a Direct Operate to Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an
appropriate value.
Issue a request for Object 40 Variation 0 using the all data qualifier 0x06.
If the device supports Analog Outputs verify that the DUT responds with an Analog Output Status object (object 40
Variation 2).
Verify that the data is reported using either 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing
(qualifier 0x01).
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.
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.
DNP3-2003 IED Certification Procedure
Subset Level 2
Page 23
Rev 2.3 29-Sept-03
Page 24
Rev 2.3 29-Sept-03
Issue a select using Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an appropriate
value.
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 Output SBO.
Verify that the DUT responds by echoing the select message exactly.
Immediately issue a matching execute.
Verify that the DUT echoes the execute.
Verify that the selected analog output operates.
Issue a select using Object 41 Variation 2 to a different point using 8 bit indexing (qualifier 0x17) and an appropriate
value.
If the device does support analog outputs, verify that the DUT responds by echoing the select message exactly.
Immediately issue a matching execute.
Verify that the DUT echoes the execute.
Verify that the selected analog output operates.
Issue a select using Object 41 Variation 2 to an uninstalled point using 16 bit indexing (qualifier 0x28) and an
appropriate value.
Verify that the DUT responds by returning an error response with IIN2-2 set and a status code of 4.
If an analog output is observed to operate, the test fails.
Issue a select using Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an appropriate
value.
Verify that the DUT responds by echoing the select message exactly.
Wait 1 second past the configured maximum select to execute delay time.
Issue a matching execute and verify that the DUT echoes the execute with the status field set to 1 [Execute received after
timeout].
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.
2.
3.
4.
5.
Issue a select using Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an appropriate
value.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the status field set to 2 [No previous matching select].
If an analog output is observed to operate, the test fails.
Issue a select using Object 41 Variation 2 to an installed point using 16 bit indexing (qualifier 0x28) and an appropriate
value.
Verify that the DUT responds by echoing the select message exactly.
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.
Verify that the DUT echoes the execute with the control status field set to 2 [No previous matching select].
If an analog output is observed to operate, the test fails.
Page 25
Rev 2.3 29-Sept-03
If the device is not configurable in a manner such that analog output points can be uninstalled or disabled, skip this
section.
Configure the DUT such that all Analog Output points are uninstalled or disabled.
Issue a select using Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier 0x28) and an appropriate value.
Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set.
If an analog output is observed to operate, the test fails.
If the DUT does not have installed analog output points, skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
If the DUT does not have installed analog output points, skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue the select again incrementing the application layer sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
If the DUT does not have installed analog output points, skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
Issue the operate again using the same application layer sequence number.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT does not operate the analog output.
If the DUT does not have installed analog output points, skip this section.
Issue a valid select to an installed analog output point.
Verify that the DUT echoes the object portion of the select byte for byte.
Issue a valid operate, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte.
Verify that the DUT operates the analog output.
Issue the operate again, incrementing the sequence number by 1 modulo 16.
Verify that the DUT echoes the object portion of the operate byte for byte with a status code value of 2 (NO
MATCHING SELECT).
Verify that the DUT does not operate the analog output.
If the DUT does not have installed analog output points, skip this section.
Page 26
Rev 2.3 29-Sept-03
2.
3.
4.
5.
6.
7.
8.
9.
Issue a Direct Operate to Object 41 Variation 2 to an installed point using 8 bit indexing (qualifier 0x17) and an
appropriate value.
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.
If the device does support analog outputs verify that the DUT responds by echoing the direct operate message exactly
with status field of 0.
Verify that the specified analog output operates.
Issue a Direct Operate to Object 41 Variation 2 to an uninstalled point using 16 bit indexing (qualifier 0x28) and an
appropriate value.
Verify that the DUT responds by return an Error Response with IIN2-2 set and a status code of 4.
If an analog output is observed to operate, the test fails.
8.4.2.2.3
1.
2.
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.
Configure the DUT such that all Analog Output points are uninstalled or disabled.
Page 27
Rev 2.3 29-Sept-03
3.
4.
5.
Issue a direct operate to Object 41 Variation 2 to point 0 using 16 bit indexing (qualifier 0x28) and an appropriate value.
Verify that the DUT responds by returning an error response with IIN2-1 or IIN2-2 set.
If an analog output is observed to operate, the test fails.
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.
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.
Verify that the DUT does not respond.
If the device does not support analog outputs, end testing of this section.
If the device does support analog outputs, verify that the proper analog output point operates.
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.
Verify that the DUT does not respond.
If an analog output is observed to operate, the test fails.
8.4.3.2.3
1.
2.
3.
4.
5.
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.
Configure the DUT such that all Analog Output points are uninstalled or disabled.
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.
Verify that the DUT does not respond.
If an analog output is observed to operate, the test fails.
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 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 analog output point by returning an error response with IIN2-2 set
and a status code of 4.
Review the devices profile document to understand how many analog output points are supported in a single request. If
this number is one, skip to step 7.
Page 28
Rev 2.3 29-Sept-03
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
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
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.
Immediately issue a matching execute.
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.
Verify that each of the selected analog outputs occurred. . Note outputs may occur simultaneously or sequentially one
after the other.
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.
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.
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.
If the DUT does not support direct operate, skip to step 13.
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.
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).
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.
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.
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.
Page 29
Rev 2.3 29-Sept-03
Object
1
1
10
20
20
20
20
21
21
21
21
30
30
30
30
40
Variation
1
2
2
1
2
5
6
1
2
9
10
1
2
3
4
2
Qualifier
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
Device responds to a Class 0 poll with the current state of all data.
Issue a request for Object 60 Variation 1 using the all data qualifier 0x06.
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.
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.
Page 30
Rev 2.3 29-Sept-03
Object
2
2
2
22
22
32
32
51
51
Variation
1
2
3
1
2
1
2
1
2
Qualifier
0x17,0x28
0x17,0x28
0x17,0x28
0x17,0x28
0x17,0x28
0x17,0x28
0x17,0x28
0x07
0x07
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 objects
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.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
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.
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.
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.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 1 event data.
Issue another request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with all the Class 1 event data generated in a single response.
Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first).
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
8.5.2.2.2
1.
2.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Page 31
Rev 2.3 29-Sept-03
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 1 events.
Issue a request for Object 60 Variation 2 using the limit data qualifier 0x07 requesting some changes.
Verify that the device responds with the requested Class 1 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 2 using the limit data qualifier 0x07 requesting the remaining changes.
Verify that device responds with the remaining Class 1 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
8.5.2.2.3
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 1 events.
Issue a request for Object 60 Variation 2 using the limit data qualifier 0x08 requesting some changes.
Verify that the device responds with the requested Class 1 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 2 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that device responds with the remaining Class 1 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
8.5.2.2.4
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 1 event data.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with all the Class 1 event data.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Do not issue an application layer confirm to the device.
Wait for a period of time exceeding several of the Application Layer retry delays, if one exists.
Verify that the device has not retransmitted the previous Application Layer fragment.
Generate additional Class 1 event data.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with the same Class 1 event data and the additional data generated in step 14.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Page 32
Rev 2.3 29-Sept-03
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.
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.3.2.2
1.
2.
3.
4.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
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.
If the DUT does not support Class 2 events, verify that it responds with a Null Response. No further testing is required in
this section.
If the DUT does support Class 2 events, verify that the device responds with all the event data in its event buffers or
responds with a Null Response.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 2 event data.
Issue another request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with all the Class 2 event data generated in a single response.
Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first).
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 2 events.
Page 33
Rev 2.3 29-Sept-03
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Issue a request for Object 60 Variation 3 using the limit data qualifier 0x07 requesting some changes.
Verify that the device responds with the requested Class 2 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 3 using the limit data qualifier 0x07 requesting the remaining changes.
Verify that device responds with the remaining Class 2 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
8.5.3.2.3
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
8.5.3.2.4
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 2 events.
Issue a request for Object 60 Variation 3 using the limit data qualifier 0x08 requesting some changes.
Verify that the device responds with the requested Class 2 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 3 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that device responds with the remaining Class 2 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 2 event data.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with all the Class 2 event data.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Do not issue an application layer confirm to the device.
Wait for a period of time exceeding several of the Application Layer retry delays, if one exists.
Verify that the device has not retransmitted the previous Application Layer fragment.
Generate additional Class 2 event data.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with the same Class 2 event data and the additional data generated in step 14.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Page 34
Rev 2.3 29-Sept-03
8.5.4 Class 3
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.
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.4.2.2
1.
2.
3.
4.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
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.
If the DUT does not support Class 3 events, verify that it responds with a Null Response. No further testing is required in
this section.
If the DUT does support Class 3 events, verify that the device responds with all the event data in its event buffers or
responds with a Null Response.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 3 event data.
Issue another request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with all the Class 3 event data generated in a single response.
Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first).
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 3 events.
Page 35
Rev 2.3 29-Sept-03
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Issue a request for Object 60 Variation 4 using the limit data qualifier 0x07 requesting some changes.
Verify that the device responds with the requested Class 3 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 4 using the limit data qualifier 0x07 requesting the remaining changes.
Verify that device responds with the remaining Class 3 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
8.5.4.2.3
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
8.5.4.2.4
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate several Class 3 events.
Issue a request for Object 60 Variation 4 using the limit data qualifier 0x08 requesting some changes.
Verify that the device responds with the requested Class 3 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 4 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that device responds with the remaining Class 3 events.
Verify that the device requests an application layer confirm.
Issue another request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known Class 3 event data.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with all the Class 1 event data.
Verify that only objects in table 8-4 are returned.
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Do not issue an application layer confirm to the device.
Wait for a period of time exceeding several of the Application Layer retry delays, if one exists.
Verify that the device has not retransmitted the previous Application Layer fragment.
Generate additional Class 3 event data.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with the same Class 1 event data and the additional data generated in step 14.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Page 36
Rev 2.3 29-Sept-03
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known event data that includes events from all three classes.
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06.
Verify that the device responds with all the event data as described in the Desired Behavior.
Verify that only objects in table 8-4 are returned and that the events are in time order (oldest first).
Verify that the data is reported using either 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
8.5.5.2.2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
If requested, issue an application layer confirm to empty the device of pending events.
Generate known event data that includes events from classes 1, 2, and 3.
Issue a request for Object 60 Variations 2,3,4, and 1 using the all data qualifier 0x06.
Verify that the device responds with all the event data as described in the Desired Behavior.
Verify that all static data is returned after all event data in the same response.
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.
Verify that only objects in tables 8-3 and 8-4 are returned.
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.
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
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.
Page 37
Rev 2.3 29-Sept-03
The device must respond to a request for Class 3 events with only Class 3 events.
Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending events.
Verify that only objects in table 8-4 are returned.
If the response is not Null, verify that the device requests an application layer confirm.
Generate some Class 1 events.
Generate some Class 2 events.
Generate some Class 3 events.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with only Class 1 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 2 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with only Class 2 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 3 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with only Class 3 events in a single response.
Verify that only objects in table 8-4 are returned.
Verify that the device requests an application layer confirm.
Issue a request for Object 60 Variation 4 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06.
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.
Page 38
Rev 2.3 29-Sept-03
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.
Issue a request for Object 60 Variation 1, Qualifier 0x06, using a Function Code of 0x70.
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.
Issue a request for Object 60 Variation 1, Qualifier 0x06, using a Function Code of 0x01.
Verify that the device responds with none of the Error IIN bits set.
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.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.
If the device supports individual control point supervisory control, each object must set the Local Forced Data bit when
the corresponding point is in the Local or Disabled state.
8.6.4.2 Test Procedure for Devices with Global Remote Supervisory Control
1.
2.
3.
4.
5.
6.
7.
If the DUT does not support placing its binary outputs in a local state no further testing is required in this section.
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.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a valid message and that IIN1-5 is cleared.
Change the DUTs global switch to the Disabled or Local mode.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
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.
2.
3.
4.
If the DUT does not support placing its binary outputs in a local state, no further testing is required in this section.
If the device allows for individual control point remote supervisory control, all points should be set to the Enabled or
Remote mode.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with Object 10 Variation 2 and that IIN1-5 is cleared.
Page 39
Rev 2.3 29-Sept-03
5.
6.
7.
8.
9.
Verify that each object has the "On-line" bit is set, the "State" bit either set or cleared, and all the remaining bits clear.
Change a single remote supervisory control switch or setting to the Disabled or Local mode.
Issue a request for Object 10 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with Object 10 Variation 2 and that IIN1-5 is set.
Verify that the appropriate object has the "On-line" bit is set, the "State" bit either set or cleared, the "Local forced data"
bit set, and all the remaining bits clear.
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.
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.
Verify the requested output operation was executed.
Wait a reasonable application layer timeout, for example, 2 seconds.
Verify that the device does not respond.
Issue a request for Object 60 Variation 2.
Verify the DUT responds with IIN1-0 (all stations message received) set.
Send an application layer confirmation if requested.
Issue a request for Object 60 Variation 2.
Verify the DUT responds with a Null Response with IIN1-0 cleared.
Page 40
Rev 2.3 29-Sept-03
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.
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 an application layer confirmation.
10. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change.
11. Verify that the device returns a single Binary Input Change Event and IIN2-3 is not set.
12. Issue an application layer confirmation.
8.6.6.2.2
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.
Page 41
Rev 2.3 29-Sept-03
2.
3.
Issue a request for Object 60 Variations 2,3 and 4 using the all data qualifier 0x06 to empty the device of pending events.
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 an application layer confirmation.
10. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change.
11. Verify that the device returns a single Analog Input Change Event and IIN2-3 is not set.
12. Issue an application layer confirmation.
8.6.6.2.3
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 an application layer confirmation.
10. Issue a request for Object 60 Variation x using the limit data qualifier 0x07 requesting a single change.
11. Verify that the device returns a single Binary Counter Change Event and IIN2-3 is no longer set.
12. Issue an application layer confirmation.
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.
The device must respond to a Delay Measurement request with a Time Delay Fine response.
Issue a request for Delay Measurement using Function Code 23, to the DUT.
Page 42
Rev 2.3 29-Sept-03
2.
3.
4.
Verify that the device replies with Object 52 Variation 2 Qualifier 0x07 Quantity 1 and a millisecond time stamp of the
measured delay.
Verify that the accuracy of the delay reported is within the maximum error specified in the Device Profile Document.
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).
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.8
Cold Restart
The device must respond to a Cold Restart request by sending a Time Delay response, restarting, and setting IIN1-7.
Issue a request for Cold Restart using Function Code 13, to the DUT.
Verify the response is a Time Delay Fine or Coarse (Object 52 Variation 1 or Variation 2).
If the DUT requests an Application Layer Confirm send it before starting the wait period.
Wait for a period of time longer than the time returned in step 2.
Issue a request for Object 60 Variation 1.
Verify that the device responds with IIN1-7 set indicating that the device has been restarted.
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.
Verify that the device responds with a Null Response and that IIN1-7 is cleared.
Page 43
Rev 2.3 29-Sept-03
8.9
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.
If the DUT has a configurable fragment size, configure it to be no more than 2048 octets.
Cycle power to the DUT.
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 DUTs 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 DUTs 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 DUTs 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.
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).
Page 44
Rev 2.3 29-Sept-03
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.
Verify that the DUT responds with valid data.
Verify that the CON bit is set in the first fragment.
Verify the sequence number matches the request.
Wait the application confirmation timeout for the DUT. Do not send an application confirmation.
Verify the DUT does not send the next fragment because it did not receive confirmation of the first fragment.
Send the valid application layer confirmation.
Verify the DUT does not send the next fragment because it has timed out.
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.
Verify that the CON bit is set in the first fragment.
Wait a time period less than the application confirmation timeout. Verify the DUT does not send the second fragment
yet.
Send the valid application layer confirmation before the application confirmation timeout.
Verify that the DUT sends the second fragment (with FIR, FIN and sequence number set correctly).
Verify that the CON bit is set in the second fragment if a third fragment is expected.
If a third fragment is expected, skip to step 16. If not, first send a valid application layer confirmation and then a request
for multi-fragment data as in steps 1-3.
Send an application layer confirmation with an incorrect sequence number.
Wait the application layer confirmation timeout for the DUT. Do not send an application confirmation.
Verify the DUT does not send the next fragment because the confirmation it received was invalid.
Send the valid application layer confirmation.
Verify the DUT does not send the next fragment because it has timed out.
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.
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.
Connect the DUT and at least two additional DNP devices to the same communications drop.
Connect an oscilloscope and/or protocol analyzer to the DUT communications signals.
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.
Verify that the DUT does not respond in any way, including raising carrier or asserting RTS.
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to the broadcast address.
Verify that the DUT does not respond in any way, including raising carrier or asserting RTS.
Issue a request for Object 60 Variations 2,3, and 4 using the all data qualifier 0x06 to the DUT.
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.
Page 45
Rev 2.3 29-Sept-03
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
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
At all times:
Application layer sequence numbers (the value of bits 04 of the application layer control field) must be in the correct
range for all messages sent: 015 for polled responses and 1631 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.
Page 46
Rev 2.3 29-Sept-03
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 events, 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
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.1
1.
2.
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.
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.
Page 47
Rev 2.3 29-Sept-03
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
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.)
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.
Cycle power to the DUT.
Verify that the DUT transmits an initial unsolicited response to the configured Master destination address.
Use the off-line configuration capability to configure the destination address to a different destination address.
Cycle power to the DUT.
Verify that an initial unsolicited response is transmitted by the DUT.
Verify that the unsolicited response contains the restart bit (IIN1-7) set.
Verify that the unsolicited response is null (contains no data).
Verify that the unsolicited response requests an application layer confirmation.
Verify that the application sequence number is in the correct range.
Verify that it has been transmitted to the configured Master destination address.
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.
Verify that the restart bit (IIN1-7) remains set in these unsolicited responses.
Verify that the unsolicited responses are null (contains no data).
Verify that the unsolicited responses request application layer confirmations.
Issue a request to clear the restart bit (IIN1-7).
Verify that the DUT responds with a null response that has the restart bit (IIN1-7) cleared.
Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT.
Verify that the restart bit (IIN1-7) is clear in the unsolicited responses.
Issue a READ request (function code 0x01) for Object 60 Variation 1 (class 0) using the all data qualifier 0x06.
Verify that the DUT responds to the READ request with class 0 data.
Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT.
Issue an application layer confirmation of the unsolicited response, but use an incorrect application-layer sequence
number.
Wait at least 5 seconds, and verify that another unsolicited response is transmitted by the DUT.
Issue an application-layer confirmation of the unsolicited response, and use the correct application-layer sequence
number.
Generate known events.
Verify that no further unsolicited responses are transmitted by waiting for such responses for at least 5 seconds.
8.11.2.2
1.
2.
3.
4.
5.
6.
7.
8.
9.
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
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.
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.
Issue a request to enable unsolicited responses for Class 1 data by using function code 0x14, object 60, Variation 2.
Verify that the DUT responds with a null response indicating the request was processed without error.
If it is not possible to generate Class 1 data that would generate unsolicited responses, steps 8 through 14 are not
applicable.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Verify that the unsolicited response requests an application layer confirmation.
Page 48
Rev 2.3 29-Sept-03
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.
8.11.2.3
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
If the DUT has Class 2 data, generate such data. For example, if there is a binary input change event that is (or can be
assigned to) Class 2, then ensure that it is assigned to Class 2, and generate one such event.
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.
Issue a request to enable unsolicited responses for Class 2 data by using function code 0x14, Object 60, Variation 3.
Verify that the DUT responds with a null response indicating the request was processed without error.
If it is not possible to generate Class 2 data that would generate unsolicited responses, steps 8 through 14 are not
applicable.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Verify that the unsolicited response requests an application layer confirmation.
Verify that the application sequence number is in the correct range.
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.
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.)
Issue an application layer confirmation of the unsolicited response, but use an incorrect application-layer sequence
number.
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.
Issue an application-layer confirmation of the unsolicited response, and use the correct application-layer sequence
number.
If the DUT has Class 1 data, then generate such data. If the DUT has Class 3 data, then also generate Class 3 data.
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.
8.11.2.4
1.
2.
3.
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
If the DUT has Class 3 data, generate such data. For example, if there is a binary input change event that is (or can be
assigned to) Class 3, then ensure that it is assigned to Class 3, and generate one such event.
Page 49
Rev 2.3 29-Sept-03
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
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.
Issue a request to enable unsolicited responses for Class 3 data by using function code 0x14, Object 60, Variation 4.
Verify that the DUT responds with a null response indicating the request was processed without error.
If it is not possible to generate Class 2 data that would generate unsolicited responses, steps 8 through 14 are not
applicable.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Verify that the unsolicited response requests an application layer confirmation.
Verify that the application sequence number is in the correct range.
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.
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.)
Issue an application layer confirmation of the unsolicited response, but use an incorrect application-layer sequence
number.
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.
Issue an application-layer confirmation of the unsolicited response, and use the correct application-layer sequence
number.
If the DUT has Class 1 data, then generate such data. If the DUT has Class 2 data, then also generate Class 2 data.
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.
8.11.2.5
This is a complicated test procedure. The test has been divided into sections for clarity.
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
Generate class 1, 2, or 3 event data.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Verify that the unsolicited response requests an application layer confirmation.
Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited
response to be sent.
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).
Verify that the DUT immediately responds without error.
Wait for the unsolicited confirmation timeout to expire, and verify that another unsolicited response is transmitted by the
DUT.
Page 50
Rev 2.3 29-Sept-03
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.
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.
Wait for an amount of time less than the unsolicited confirmation timeout and verify that the DUT does not respond.
Issue an application-layer confirmation of the unsolicited response before the unsolicited confirmation timeout occurs.
Verify that the device immediately transmits a response to the READ request.
Verify that none of the event data transmitted by the unsolicited response is contained in the polled response.
If the polled response requested an application layer confirmation, then issue an application-layer confirmation of the
polled response.
Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited
response to be sent.
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.
Verify that the DUT does not respond within the unsolicited confirmation timeout.
After the unsolicited confirmation timeout, verify that the device responds with a polled response to the READ request
(and not an unsolicited response).
Verify that the polled response contains at least the same event data that was in the unsolicited response that was not
confirmed.
Verify that the polled response requests an application layer confirmation.
Issue an application-layer confirmation of the polled response to clear the device of event data.
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.
Generate class 1, 2, or 3 event data to trigger the transmission of an unsolicited response. Wait for this unsolicited
response to be sent.
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.
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).
Verify that the DUT immediately responds without error.
Wait for the unsolicited confirmation timeout to expire, and then verify that another unsolicited response is transmitted
by the DUT.
Verify that the event data in this unsolicited response includes the events reported in the previous unsolicited response
that was not confirmed.
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.
Before the unsolicited confirmation timeout, issue a READ request for Object 60, Variations 2, 3, and 4, using the all
data qualifier 0x06.
Verify that the DUT does not respond within the unsolicited confirmation timeout.
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).
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.
Page 51
Rev 2.3 29-Sept-03
6.
7.
8.
9.
Verify that the polled response contains at least the same event data that was in the unsolicited response that was not
confirmed.
Verify that the polled response requests an application layer confirmation.
Issue an application-layer confirmation of the polled response to clear the device of event data.
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.
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.
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.
Cycle power to the DUT.
Issue an application-layer confirmation of the initial unsolicited response.
Issue a request to clear the restart bit (IIN1-7).
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
Generate class 1, 2, or 3 event data.
Verify that an unsolicited response is transmitted. This may involve waiting for an amount of time, dictated by the DUT
and specified by the DUTs Device Profile Document, within which the DUT may wait for a minimum number of events
to be collected before transmission of an unsolicited message.
Do not issue an application layer confirm.
Verify that DUT retries the response 5 times.
Cycle power to the DUT.
Issue an application-layer confirmation of the initial unsolicited response.
Issue a request to clear the restart bit (IIN1-7).
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.
Verify that the DUT responds with a null response indicating the request was processed without error.
Generate class 1, 2, or 3 event data.
Verify that an unsolicited response is transmitted.
Issue an application layer confirm after at least one retry. Verify that retries are terminated when confirmation is
received.
Configure the maximum number of retries to indefinite.
Page 52
Rev 2.3 29-Sept-03
20.
21.
22.
23.
24.
25.
26.
27.
28.
8.11.2.6
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Page 53
Rev 2.3 29-Sept-03
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 masters priority, the
master would not have a random delay.
Request Class 1 data (Object 60 Variation 2) using Qualifier Code 0x06 and link control block 0xC4.
Verify the device responds with data. Measure the turnaround delay between receipt of the request and the response.
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.
Page 54
Rev 2.3 29-Sept-03
Issue a request for Object 1 Variation 0 using the all data qualifier of 0x06.
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
1.
2.
3.
4.
5.
6.
7.
8.
9.
2.
3.
4.
8.13.2.3
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.
Configure the DUT such that all Binary Input points are uninstalled or disabled.
Issue a request for Object 1 Variation 0 using the all data qualifier of 0x06.
Verify that the DUT responds with a Null Response. The device can optionally set IIN2-1.
Page 55
Rev 2.3 29-Sept-03
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.
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.2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
Issue an application layer confirm if requested to empty the device of pending events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Generate several Binary Input Change Events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with all generated events in a single response.
Verify that the device requests an application layer confirm.
Verify that the response contains only Object 2, Variation 1, 2, and/or 3.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.14.2.3
1.
2.
3.
4.
5.
6.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
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.
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.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change Events.
Issue a request for Object 2 Variation 0 using the limit data qualifier 0x07 requesting some of the changes.
Verify that the device responds with the correct number of generated events in a single response.
Page 56
Rev 2.3 29-Sept-03
7.
8.
9.
10.
11.
12.
13.
8.14.2.4
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change Events.
Issue a request for Object 2 Variation 0 using the limit data qualifier 0x08 requesting some of the changes.
Verify that the device responds with the correct number of Binary Input Change Events in a single response.
Verify that the device requests an application layer confirm.
Verify that only Object 2, Variation 1, 2, and/or 3 are returned.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Issue a request for Object 2 Variation 0 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that the device responds with the remaining events.
Verify that the device requests an application layer confirm.
8.14.2.5
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate Binary Input Change Events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with all the event data generated in a single response.
Verify that the device requests an application layer confirm.
Verify only Object 2, Variation 1, 2, and/or 3 are returned.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Do not issue an application layer confirm to the device.
Wait for a period of time exceeding several of the Application Layer retry delays, if one exists.
Verify that the device has not retransmitted the previous Application Layer fragment.
Generate additional Binary Input Change Events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with the same event data generated in step 4 and that the additional data generated in step
14 is in time order (oldest first) in a single response.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.14.2.6
1.
2.
3.
4.
5.
6.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change Events.
Issue a request for Object 2 Variation 1 using the all data qualifier 0x06.
Verify that the device responds with all of the events in a single response.
Page 57
Rev 2.3 29-Sept-03
7.
8.
9.
10.
11.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.14.2.7
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
8.14.2.8
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
7.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change Events.
Issue a request for Object 2 Variation 1 using the limit data qualifier 0x08 requesting some of the changes.
Verify that the device responds with the requested events in a single response.
Verify that the device requests an application layer confirm.
Verify that the device responds with data using either qualifier 0x17 or 0x28.
Verify that flag behavior complies with Section 2, Note #5.
Verify that only Object 2, Variation 1 is returned.
Issue a request for Object 2 Variation 1 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that the device responds with the remaining events.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.14.2.9
1.
2.
3.
4.
5.
6.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change Events.
Issue a request for Object 2 Variation 1 using the limit data qualifier 0x07 requesting some of the changes.
Verify that the device responds with the requested events in a single response.
Verify that the device requests an application layer confirm.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that only Object 2, Variation 1 is returned.
Issue a request for Object 2 Variation 1 using the limit data qualifier 0x07 requesting the remaining changes.
Verify that the device responds with the remaining events.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change with Time Events.
Issue a request for Object 2 Variation 2 (binary change with time) using the all data qualifier 0x06.
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.
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.
Page 58
Rev 2.3 29-Sept-03
8.
9.
10.
11.
12.
8.14.2.10
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change with Time Events.
Issue a request for Object 2 Variation 2 using the limit data qualifier 0x07 requesting some changes.
Verify that the device responds with the requested number of events in a single response.
Verify that the device requests an application layer confirm.
Verify that only Object 2, Variation 2 is returned.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
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).
Issue a request for Object 2 Variation 2 using the limit data qualifier 0x07 requesting the remaining changes.
Verify that the device responds with the remaining events.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.14.2.11
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change with Time Events.
Issue a request for Object 2 Variation 2 using the limit data qualifier 0x08 requesting some changes.
Verify that the device responds with the requested number of events in a single response.
Verify that the device requests an application layer confirm.
Verify that only Object 2, Variation 2 is returned.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
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).
Issue a request for Object 2 Variation 2 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that the device responds with the remaining events.
Verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.14.2.12
1.
2.
3.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Page 59
Rev 2.3 29-Sept-03
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
8.14.2.13
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change with Relative Time Events.
Issue a request for Object 2 Variation 3 using the limit data qualifier 0x07 requesting some changes.
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.
Verify that the device requests an application layer confirm.
Verify that only the Common Time of Occurrence Object (Object 51, Variation 1 or 2) and Object 2, Variation 3 are
returned.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
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).
Issue a request for Object 2 Variation 3 using the limit data qualifier 0x07 requesting the remaining changes.
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.
Verify that the device requests an application layer confirm.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.14.2.14
1.
2.
3.
4.
5.
6.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change with Relative Time Events.
Issue a request for Object 2 Variation 3 using the limit data qualifier 0x08 requesting some changes.
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.
Page 60
Rev 2.3 29-Sept-03
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
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.
Verify that the device requests an application layer confirm.
Verify that only the Common Time of Occurrence Object (Object 51, Variation 1 or 2) and Object 2, Variation 3 are
returned.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
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).
Issue a request for Object 2 Variation 3 using the limit data qualifier 0x08 requesting the remaining changes.
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.
Verify that the device requests an application layer confirm.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.14.2.15
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Issue a request for Object 2 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Input Change with Relative Time Events.
Wait longer than 0xffff milliseconds.
Generate several Binary Input Change with Relative Time Events.
Issue a request for Object 2 Variation 3 (binary change with relative time) using the all data qualifier 0x06.
Verify that the device responds with the requested events in a single response.
Verify that the device requests an application layer confirm.
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.
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.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
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).
Issue a request for Object 2 Variation 3 using the limit data qualifier 0x06 requesting all changes.
Verify that the device responds with a Null Response.
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 or if the DUT does not set IIN1-4:
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:
DNP3-2003 IED Certification Procedure
Subset Level 2
Page 61
Rev 2.3 29-Sept-03
1.
2.
3.
4.
5.
6.
The Synchronized/Unsynchronized Common Time of Occurrence Object precedes the Binary Input Change with
Relative Time Objects in each fragment of the response.
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.
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.
The data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Flag behavior complies with Section 2, Note #5.
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).
If the DUT does not support Binary Input Change with Relative Time events no further testing is required in this section.
Cause the DUT to restart.
Clear the Restart IIN.
Generate several Binary Input Change with Relative Time events.
Issue a request for Object 2 Variation 3 using the all data qualifier 0x06.
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.
Verify that the objects returned are formatted correctly.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
If the DUT does not set IIN1-4, skip the rest of this section.
If the DUT does set IIN1-4, wait the specified maximum time from reset to IIN1-4 assertion.
Perform a time delay measurement.
Verify that the device responds with a valid message and that IIN1-4 is set indicating that the device is requesting time
synchronization.
Set the time and date using Object 50 Variation 1 with Qualifier 0x07.
Verify that the device responds with a Null Response and that IIN1-4 is cleared indicating the device no longer needs
time.
Generate several Binary Input Change with Relative Time events.
Issue a request for Object 2 Variation 3 using the all data qualifier 0x06.
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.
Verify that the objects returned are formatted correctly.
Verify that the device requests an application layer confirm.
Issue an application layer confirm, to empty the device of pending events.
Generate several Binary Input Change with Relative Time events.
Wait the specified maximum time between time synchronization requests.
Perform a time delay measurement.
Verify that the device responds with a valid message and that IIN1-4 is set indicating that the device is requesting time
synchronization.
Issue a request for Object 2 Variation 3 using the all data qualifier 0x06.
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.
Verify that the objects returned are formatted correctly.
Verify that the device requests an application layer confirm.
Do Not issue the application layer confirm.
Set the time and date using Object 50 Variation 1 with Qualifier 0x07.
Verify that the device responds with a Null Response and that IIN1-4 is cleared indicating the device no longer needs
time.
Issue a request for Object 2 Variation 3 using the all data qualifier 0x06.
Page 62
Rev 2.3 29-Sept-03
34.
35.
36.
37.
38.
8.16.1.1
Variation
1
2
5
6
Qualifier
Description
0x00,0x01
32-Bit Binary Counter
0x00,0x01
16-Bit Binary Counter
0x00,0x01
32-Bit Binary Counter Without Flag
0x00,0x01
16-Bit Binary Counter Without Flag
Table 8-5
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 (see table 8-5) 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
Test Procedure
Issue a request for Object 20 Variation 0 using the all data qualifier 0x06.
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.
Page 63
Rev 2.3 29-Sept-03
Issue a request for Object 20 Variation 0 using the all data qualifier 0x06.
Verify that the DUT responds with binary counter objects (object 20 Variation 1-8).
Record the values for future reference.
Generate binary counter input data.
Issue a request for Object 20 Variation 0 using the all data qualifier 0x06.
Verify that the reported values match the values recorded previously plus the counts generated in step 4.
Verify any points reported with Object 20, Variations 1, 2, 5, or 6 are reported with qualifiers 0x00 or 0x01.
Verify that flag behavior complies with Section 2, Note #5 if variations 1 or 2 reported.
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.
Configure the DUT such that all Binary Counter points are uninstalled or disabled.
Issue a request for Object 20 Variation 0 using the all data qualifier 0x06.
Verify that the DUT responds with a null response. The device can optionally return an Error Response with IIN2-1 set.
8.16.2.1
Variation
1
2
9
10
Qualifier
0x00,0x01
0x00,0x01
0x00,0x01
0x00,0x01
Description
32-Bit Frozen Counter
16-Bit Frozen Counter
32-Bit Frozen Counter Without Flag
16-Bit Frozen Counter Without Flag
Table 8-6
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
Test Procedure
Issue a read request for Object 21, variation 0, using the all data qualifier 0x06.
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.
Page 64
Rev 2.3 29-Sept-03
Issue a freeze to Object 20 Variation 0 using function code 0x07 and the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a read request for Object 21, variation 0, using the all data qualifier 0x06.
Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10.
Record the values for future reference.
Generate counter data.
Issue a read request for Object 21 Variation 0, using the all data qualifier 0x06.
Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10.
Verify that the data is reported using 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing (qualifier
0x01)
Verify that flag behavior complies with Section 2, Note #5 if variations 1 or 2 are reported.
Verify that the reported values match the values recorded previously.
Issue a freeze counter command to Object 20 Variation 0 using function code 0x07 and the all data qualifier 0x06.
Verify that the DUT responds with a Null Response.
Issue a read request for object 21 Variation 0, using the all data qualifier 0x06.
Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10.
Verify that the reported values match the values recorded previously plus the counts generated in step 6.
Issue a freeze to Object 20 Variation 0 using function code 0x08 and the all data qualifier 0x06.
Verify that the DUT does not respond.
Issue a read request for Object 21, variation 0, using the all data qualifier 0x06.
Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10.
Record the values for future reference.
Generate counter data.
Issue a read request for Object 21 Variation 0, using the all data qualifier 0x06.
Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10.
Verify that the reported values match the values recorded previously.
Verify that the data is reported using 8 bit start/stop indexing (qualifier 0x00) or 16 bit start/stop indexing (qualifier
0x01)
Verify that flag behavior complies with Section 2, Note #5.
Issue a freeze counter command to Object 20 Variation 0 using function code 0x08 using the all data qualifier 0x06.
Verify that the DUT does not respond.
Issue a read request for object 21 Variation 0, using the all data qualifier 0x06.
Verify that the DUT responds with a Frozen Binary Counter Object 21 Variation 1, 2, 9, or 10.
Verify that the reported values match the values recorded previously plus the counts generated in step 6.
Page 65
Rev 2.3 29-Sept-03
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.2
1.
2.
3.
4.
5.
6.
7.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
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.
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.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm if requested to empty the device of pending events.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
Generate some Counter Change Events.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
Page 66
Rev 2.3 29-Sept-03
8.
9.
10.
11.
12.
13.
14.
15.
16.
Verify that the device responds with all of the events in a single response.
Verify that the device requests an application layer confirm.
Verify that only Object 22, Variations 1 and/or 2 are returned.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28)
Verify that flag behavior complies with Section 2, Note #5.
Record the values for future reference.
Generate additional Counter Change Events.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
Verify that the reported values match the values recorded previously plus the counts generated in step 14.
8.17.2.3
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Counter Change Events.
Issue a request for Object 22 Variation 0 using the limit data qualifier 0x07 requesting some changes.
Verify that the device responds with the requested Binary Counter Change Events in a single response.
Verify that the device requests an application layer confirm.
Verify that only Object 22, Variations 1 and/or 2 are returned.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Issue a request for Object 22 Variation 0 using the limit data qualifier 0x07 requesting the remaining changes.
Verify that the device responds with the remaining Binary Counter Change Events.
Verify that the device requests an application layer confirm.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.17.2.4
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06 to empty the device of pending events.
If the response is not Null, verify that the device requests an application layer confirm
Issue an application layer confirm if requested to empty the device of pending events.
Generate several Binary Counter Change Events.
Issue a request for Object 22 Variation 0 using the limit data qualifier 0x08 requesting some changes.
Verify that the device responds with the requested Binary Counter Change Events in a single response.
Verify that the device requests an application layer confirm.
Verify that only Object 22, Variations 1 and/or 2 are returned.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Issue a request for Object 22 Variation 0 using the limit data qualifier 0x08 requesting the remaining changes.
Verify that the device responds with the remaining Binary Counter Change Events.
Verify that the device requests an application layer confirm.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
8.17.2.5
1.
2.
3.
4.
5.
6.
7.
8.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
If the response is not Null, verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Generate Binary Counter Change Events.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with all the event data generated in a single response.
Verify that the device requests an application layer confirm.
Do not issue an application layer confirm to the device.
Page 67
Rev 2.3 29-Sept-03
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Wait for a period of time exceeding several of the Application Layer retry delays, if one exists.
Verify that the device has not retransmitted the previous Application Layer fragment.
Generate additional Binary Counter Change Events including some on points not previously stimulated if possible.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
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.
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.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue an application layer confirm to empty the device of pending events.
Issue a request for Object 22 Variation 0 using the all data qualifier 0x06.
Verify that the device responds with a Null Response.
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.
Issue a request for Object 30 Variation 0 using the all data qualifier 0x06.
Verify that it responds with a null response.
Optionally, the device can set IIN2-1. No further testing is required in this section.
8.18.2.2
1.
2.
3.
4.
Page 68
Rev 2.3 29-Sept-03
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.
Issue a request for Object 32 Variation 0, using the all data qualifier 0x06.
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.
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.
Generate a stable analog input to the device.
Issue a request for Object 32 Variation 0, using the all data qualifier 0x06.
Verify that the device responds with Object 32 Variation 1 or 2, with the value representing the input applied in step 4.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Issue a request for Object 32 Variation 0, using the all data qualifier 0x06.
Verify that the device responds with a null response.
Increase or decrease the analog input applied in step 4 greater than the configured deadband.
Issue a request for Object 32 Variation 0, using the all data qualifier 0x06.
Verify that the device responds with Object 32 Variation 1 or 2, with the value representing the new input from step 12.
8.19.2.2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
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).
Issue a request for Object 32 Variation 0, using the all data qualifier.
Verify that the device responds with Object 32 Variation 1 or 2, with the value representing the input applied in step 1.
Verify that the data is reported using 8 bit indexing (qualifier 0x17) or 16 bit indexing (qualifier 0x28).
Verify that flag behavior complies with Section 2, Note #5.
Verify that the device requests an application layer confirm.
Wait for a period of time exceeding several of the Application Layer retry delays, if one exists.
Verify that the device has not retransmitted the previous Application Layer fragment.
Increase or decrease the analog input applied in step 1.
Issue a request for Object 32 Variation 0, using the all data qualifier 0x06.
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.
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.
Verify that the device requests an application layer confirm.
Issue an application layer confirm.
Issue a request for Object 32 Variation 0, using the all data qualifier 0x06.
Verify that the device responds with a null response.
Page 69
Rev 2.3 29-Sept-03
The DUT must respond to read requests for multiple object types
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.
Verify that the DUT response has none of IIN2-x set.
Verify the validity of the returned object type data. Note that the DUT may not return event objects if they are not
present.
Verify data objects are returned in the order requested.
Page 70
Rev 2.3 29-Sept-03
LSB
1
DIR
FCB
FCV
Primary
PRM
FUNCTION CODE
DIR
PRM
FCB
FCV
DFC
DFC
Secondary
3
1 = Master, 0 = Remote
1 = Data Link Request, 0 = Data Link Response
Frame Count Bit, alternates 1 and 0
Frame Count Valid; 1 = valid, 0 = invalid
Data Flow Control; 1 = no buffers left
Function Codes:
Primary Frames (PRM=1)
Fn Code
Function
Frame Type
FCV
RESET link
SEND/CONFIRM
SEND/CONFIRM
TEST link
SEND/CONFIRM
User Data
SEND/CONFIRM
User Data
SEND/NO REPLY
REQUEST/RESPOND
Function
Frame Type
ACK
CONFIRM
NACK
CONFIRM
11
Link Status
RESPOND
Page 71
Rev 2.3 29-Sept-03
From
Remote
From
Master
Function
00
80
ACK
01
81
NACK
Failed transaction
0B
8B
No flow Control
10
90
ACK
11
91
NACK
1B
9B
No buffers available
40
C0
RESET LINK
41
C1
44
C4
49
C9
52
D2
Test Link
FCB = 0
53
D3
FCB = 0
60
E0
RESET LINK
FCB = 1 ignored
61
E1
FCB = 1 ignored
64
E4
FCB = 1 ignored
69
E9
FCB = 1 ignored
72
F2
Test Link
FCB = 1
73
F3
FCB = 1
Other
Frame Header:
Byte
Name
05
64
LEN
CTRL
DEST
SOURCE
9
CRC
10
11
TH
Page 72
Rev 2.3 29-Sept-03
DNP
APDU
APCI
DUI
Message Header
Request Header
Appl.
Ctrl
IO
DUI
Object Header
Data
IO
Object Header
Data
Response Header
Func
Code
Appl.
Ctrl
Func
Code
Internal
Indication
Object
Group
Object
Variation
Qualifier
Range
APCI
Application
Protocol
Control
Information
DUI
Data Unit
Identifier
IO
Information
Object
CLASS 1
4 3
Depends on
Qualifier
Code
ALL STATIONS
CLASS 2
CLASS 3
NEED TIME
LOCAL
SECOND OCTET
7
BAD FUNCTION
Application
Protocol Data
Unit
OUT OF RANGE
OBJECT UNKNOWN
APDU
ALREADY EXEC
Distributed
Network
Protocol
FIRST OCTET
BUFFER OVERFLOW
Confirm
Response
Unsolicited
Response
BAD CONFIG
DNP
0x00 Confirm
0x00
0x01 Read
0x81
0x02 Write
0x82
0x03 Select
0x04 Operate
0x05 Direct Operate
0x06 Direct Op, No Ack
0x07 Immediate Freeze
0x08 Immediate Freeze No Ack
0x09 Freeze and Clear
0x0A Freeze and Clear No Ack
0x0B Freeze with Time
0x0C Freeze with Time No Ack
0x0D Cold Restart
0x0E Warm Restart
0x0F Init Data to Defaults
0x10 Initialize Application
0x11 Start Application
0x12 Stop Application
0x13 Save Configuration
0x14 Enable Unsolicited Msgs
0x15 Disable Unsolicited Msgs
0x16 Assign Class
0x17 Delay Measurement
0x18 Record Current Time
RESTART
DEV. TROUBLE
RESERVED
RESERVED
SEQUENCE
UNSOLICITED
FINAL
CONFIRM
FIRST
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
Page 73
Rev 2.3 29-Sept-03
DNP
APDU
APCI
DUI
Message Header
Request Header
Appl.
Ctrl
IO
DUI
Object Header
Data
IO
Object Header
Data
Response Header
Func
Code
Appl.
Ctrl
Func
Code
Internal
Indication
Object
Group
Object
Variation
Qualifier
Range
APCI
Application
Protocol
Control
Information
DUI
Data Unit
Identifier
IO
Information
Object
Page 74
Rev 2.1 5-July-01
4 3
Depends on
Qualifier
Code
CLASS 1
ALL STATIONS
CLASS 2
CLASS 3
NEED TIME
LOCAL
SECOND OCTET
7
BAD FUNCTION
Application
Protocol Data
Unit
OUT OF RANGE
OBJECT UNKNOWN
APDU
ALREADY EXEC
Distributed
Network
Protocol
FIRST OCTET
BUFFER OVERFLOW
Confirm
Response
Unsolicited
Response
BAD CONFIG
DNP
0x00 Confirm
0x00
0x01 Read
0x81
0x02 Write
0x82
0x03 Select
0x04 Operate
0x05 Direct Operate
0x06 Direct Op, No Ack
0x07 Immediate Freeze
0x08 Immediate Freeze No Ack
0x09 Freeze and Clear
0x0A Freeze and Clear No Ack
0x0B Freeze with Time
0x0C Freeze with Time No Ack
0x0D Cold Restart
0x0E Warm Restart
0x0F Init Data to Defaults
0x10 Initialize Application
0x11 Start Application
0x12 Stop Application
0x13 Save Configuration
0x14 Enable Unsolicited Msgs
0x15 Disable Unsolicited Msgs
0x16 Assign Class
0x17 Delay Measurement
RESTART
DEV. TROUBLE
RESERVED
RESERVED
SEQUENCE
UNSOLICITED
FINAL
CONFIRM
FIRST
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