-
A Sierra Monitor Company
Driver Manual
(Supplement to the FieldServer Instruction Manual)
FS-8700-47 DNP 3.0
APPLICABILITY & EFFECTIVITY
Effective for all systems manufactured after December 2008
Driver Version:
1.03
Document Revision: 14
FS-8700-47 DNP 3.0 Driver Manual
Table of Contents
Appendix A.16. Controlling DA Offsets................................................................................................39
Appendix A.17. dnpIndexStyle.............................................................................................................39
Appendix A.18. Real Time Clock Synchronization...............................................................................40
Appendix A.19. Select and Operate.....................................................................................................42
Appendix A.20. Multiple requests in a single poll.................................................................................45
Appendix B.
Driver Error Messages.......................................................................................................46
FS-8700-47 DNP 3.0 Driver Manual
Page 4 of 51
1.
DNP 3.0 Driver Description
The DNP 3.0 Driver allows the FieldServer to transfer data to and from devices over RS-232 or RS-485
using DNP 3.0 Driver protocol. The FieldServer can emulate either a Server or Client.
The following description of DNP is from the DNP User Group internet site.∗
“The development of DNP was a comprehensive effort to achieve open, standards-based interoperability
between substation computers, RTUs, IEDs (Intelligent Electronic Devices) and master stations (except
inter-master station communications) for the electric utility industry. Also important was the time frame
and the need for a solution to meet today's requirements. As ambitious an undertaking as this was, we
are reaching this objective.
DNP is based on the standards of the International Electrotechnical Commission (IEC) Technical
Committee 57, Working Group 03 who have been working on an OSI 3 layer "Enhanced Performance
Architecture" (EPA) protocol standard for telecontrol applications. DNP has been designed to be as close
to compliant as possible to the standards as they existed at time of development with the addition of
functionality not identified in Europe but needed for current and future North American applications (e.g.
limited transport layer functions to support 2K descriptor transfers for IEDs, RF and fiber support).
Recently DNP 3.0 was selected as a Recommended Practice by the IEEE C.2 Task Force; RTU to IED
Communications Protocol.
Feature Rich
DNP offers flexibility and functionality that go far beyond conventional communications protocols. Among
its robust and flexible features DNP 3.0 includes:
•
•
•
•
•
•
Output options
Secure configuration/file transfers
Addressing for over 65,000 devices on a single link
Time synchronization and time-stamped events
Broadcast messages
Data link and application layer confirmation
DNP 3.0 was originally designed based on three layers of the OSI seven-layer model: application layer,
data link layer and physical layer. The application layer is object-based with objects provided for most
generic data formats. The data link layer provides for several methods of retrieving data such as polling
for classes and object variations. The physical layer defines most commonly a simple RS-232 or RS-485
interface.
DNP 3.0 is very efficient for a layered protocol while ensuring high data integrity.
Suits Any SCADA/EMS Environment
Because DNP 3.0 is based on the IEC 870-5 requirements, DNP is suitable for application in the entire
SCADA/EMS environment. This includes RTU to IED communications, master to remote
communications, and even peer-to-peer instances and network applications.
Being an object-based application layer protocol, DNP 3.0 has the flexibility to support multiple operating
modes such as poll-response, polled report-by-exception, unsolicited responses and peer-to-peer. It
permits multiple masters and encourages distributed intelligence.
Users can expect many benefits from using DNP. In the short term:
•
•
•
•
Interoperability between multi-vendor devices
Fewer protocols to support in the field
reduced software costs
No protocol translators needed
∗ DNP Users Group, PO Box 43075 DVPO, Calgary, AB, Canada T2J 7A7
FS-8700-47 DNP 3.0 Driver Manual
Page 5 of 51
•
•
•
•
•
Shorter delivery schedules
Less testing, maintenance and training
Improved documentation
Independent conformance testing
Support by independent users group and third-party sources (e.g. test sets, source code).
FS-8700-47 DNP 3.0 Driver Manual
Page 6 of 51
2.
Driver Scope of Supply
2.1. Supplied by FieldServer Technologies for this driver.
FieldServer Technologies Part# Description
FS-8915-10
FS-8917-04
FS-8700-47
UTP cable (7 foot) for RS-232 use
RJ45 to DB25M connection adapter
Driver Manual.
FS-8700-47 DNP 3.0 Driver Manual
Page 7 of 51
3.
Hardware Connections
The FieldServer is connected to the DNP-3.0 device as shown below.
Configure the DNP-3.0 device according to manufacturer’s instructions
DNP Device
DB25F
8917-04
Connect to one of the RS-232
Ports on the FieldServer
RJ45
8
1
P1
FieldServer
FieldServer Function From
Default
Color
Rx
RJ45-01 DB25F-02 White
RJ45-02 DB25F-04 Brown
CTS
DSR
GND
GND
DTR
RTS
Tx
RJ45-03
Yellow
RJ45-04 DB25F-07 Green
RJ45-05
RJ45-06
Red
Black
RJ45-07 DB25F-05 Orange
RJ45-08 DB25F-03 Blue
3.1.
Connection Notes
Pinouts and adapters may vary according to the device being connected to. Refer to DNP installation
manual for pin connection reference.
FS-8700-47 DNP 3.0 Driver Manual
Page 8 of 51
4.
Configuring the FieldServer as a DNP 3.0 Driver Client
For a detailed discussion on FieldServer configuration, please refer to the FieldServer Configuration
Manual. The information that follows describes how to expand upon the factory defaults provided in the
configuration files included with the FieldServer (See “.csv” files supplied with the FieldServer).
This section documents and describes the parameters necessary for configuring the FieldServer to
communicate with a DNP 3.0 Driver Server.
The configuration file tells the FieldServer about its interfaces, and the routing of data required. In order to
enable the FieldServer for DNP 3.0 Driver communications, the driver independent FieldServer buffers
need to be declared in the “Data Arrays” section, the destination device addresses need to be declared in
the “Client Side Nodes” section, and the data required from the Servers needs to be mapped in the
“Client Side Map Descriptors” section. Details on how to do this can be found below.
Note that in the tables, * indicates an optional parameter, with the bold legal value being the default.
4.1.
Data Arrays
Section Title
Data_Arrays
Column Title
Function
Legal Values
Data_Array_Name Provide name for Data Array
Up to 15 alphanumeric characters
FLOAT, BIT, UInt16, SInt16,
Packed_Bit, Byte, Packed_Byte,
Swapped_Byte
Provide data format. Each data array can
Data_Format
only take on one format.
Number of Data Objects. Must be larger
Data_Array_Length than the data storage area required for 1-10,000
the data being placed in this array.
Example
// Data Arrays
//
Data_Arrays
Data_Array_Name
DA_AI_01
DA_AO_01
DA_DI_01
,Data_Format
,UInt16
,UInt16
,Bit
,Data_Array_Length
,200
,200
,200
,200
DA_DO_01
,Bit
FS-8700-47 DNP 3.0 Driver Manual
Page 9 of 51
4.2.
Client Side Connection Descriptors
Section Title
Connections
Column Title Function
Legal Values
Specify which port the device is connected to the
FieldServer
Port
P1-P8, R1-R21
110 – 115200, standard
baud rates only
Even, Odd, None, Mark,
Space
Baud*
Parity*
Specify baud rate
Specify parity
Data_Bits*
Stop_Bits*
Protocol
Specify data bits
Specify stop bits
7, 8
1
Specify protocol used
DNP
Handshaking* Specify hardware handshaking
None
0-32000 seconds, 1
second.
Poll Delay*
Time between internal polls
Versions of the driver prior to 1.02a used a different
method to calculate DA offset. Refer to Appendix A.16. OriginalStyle,
NoLink,
Application*
It is also possible to use this parameter to control if link
resets are used/required. Refer to Appendix A.15.
OrigStyle-NoLink
Example
// Client Side Connections
Connections
Port
R1
,Baud ,Parity ,Protocol ,Handshaking ,Poll_Delay
,9600 ,None ,DNP ,None ,0.100s
4.3.
Client Side Node Descriptors
Section Title
Nodes
Column Title
Function
Provide name for node
Legal Values
Up
to
32
alphanumeric
Node_Name
characters
DNP 3.0 station address of physical Server
node
Specify protocol used
Specify which port the device is connected to
the FieldServer
Node_ID
Protocol
Port
0-65535
DNP
P1-P8, R1-R21
Example
// Client Side Nodes
Nodes
Node_Name ,Node_ID ,Protocol ,Port
PLC 1
,1
,DNP
,P1
1
Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction
manual for details of the ports available on specific hardware.
FS-8700-47 DNP 3.0 Driver Manual
Page 10 of 51
4.4.
4.4.1.
Client Side Map Descriptors
FieldServer Specific Map Descriptor Parameters
Column Title
Function
Legal Values
Up to 32 alphanumeric
characters
Map_Descriptor_Name
Name of this Map Descriptor
Name of Data Array where
data is to be stored in the
FieldServer
One of the Data Array names
from “Data Array” section
above
Data_Array_Name
0 to maximum specified in
“Data Array” section above
Data_Array_Offset
Function
Starting location in Data Array
Function of Client Map
Descriptor
Rdbc, Wrbc, Wrbx
4.4.2.
Driver Specific Map Descriptor Parameters
Function
Column Title
Legal Values
The following parameters are used by a number of drivers.
A Node Name specified in
“Client Node Descriptor”.
Special Map Descriptors are
Node_Name
Name of Node to fetch data from
discussed
Reference
found..
in
Error!
not
source
Length of Map Descriptor. If a request length
is too large the DNP 3.0 driver will produce a
Length
message and a panic. The maximum length 1 – 1000
is a function of the data object and data
variation.
Address
Starting address of data element to be read
0, 1 , 2 etc
The following parameters apply only to the DNP 3.0 Driver
Corresponds to the Data Object Types defined 1, 2, 10, 12, 30, 31, 32, 33,
DnpDataType in the DNP data object Library. Additional 40, 41, 20, 22, 23, 50, 51, 52,
information is provided in Appendix A.9
Corresponds to the Data Object Variant
defined in the DNP data object Library. Enter
as decimal number. Additional information is
provided in Appendix A.9
60, 80 - decimal numbers
0, 1,2,3 etc
Legal values are determined
by the value of dnpDataType.
DnpDataVari
Used to tell driver which Suffield of the object
to map to/from the FieldServer Data Array.
Additional information is provided in Appendix combo
A.10
Not Used.
Value, flags, time1, time2,
DnpSubType*
DnpFlagBit*
Zero, 1, 6, 7, 8, 17h -
hexadecimal values. For
This parameter is only required if you need to qualifier 17h specify the
over-ride the default qualifier used by the DNP value of dnpQualifier as 17 in
DnpQualifier*
DnpFunction*
3.0 driver. Refer to Appendix A.11
the Map Descriptor.
For
Qualifier zero use the string
“zero”
Legal DNP function codes.
Correspond to the function
code required on vendor’s
implementation table.
This parameter is only required if you need to
over-ride the default function used by the DNP
3.0 driver. Refer to Appendix A.10
FS-8700-47 DNP 3.0 Driver Manual
Column Title
Page 11 of 51
Function
Legal Values
When class data is requested the DNP device
responds with data of multiple types and
variations in one message.
One Map
DnpAssociate*
Non-zero positive integers.
Descriptor is used per data type - this
parameter is used to link these Map
Descriptors.
This parameter is used to produce a single
message with a request for multiple object
types. Assign positive whole numbers to 0, positive whole numbers.
associate Map Descriptors for this purpose. All By default Map Descriptors
DnpMultiMsg* Map Descriptors whose dnpMultiMsg values are not associated with each
are equal will be requested in a single poll. other. The default value of
Ensure only one is active (rdbc for example) zero ensures no association.
and all the others have the function set to
'Server'. Refer also to Appendix A.20
4.4.3.
Timing Parameters
Column Title
Scan_Interval
Function
Rate at which data is polled
Legal Values
>0.1s
FS-8700-47 DNP 3.0 Driver Manual
Page 16 of 51
5.
Configuring the FieldServer as a DNP 3.0 Driver Server
For a detailed discussion on FieldServer configuration, please refer to the FieldServer Configuration
Manual. The information that follows describes how to expand upon the factory defaults provided in the
configuration files included with the FieldServer (See “.csv” files provided with the FieldServer.)
This section documents and describes the parameters necessary for configuring the FieldServer to
communicate with a DNP 3.0 Driver Client.
The configuration file tells the FieldServer about its interfaces, and the routing of data required. In order
to enable the FieldServer for DNP 3.0 Driver communications, the driver independent FieldServer buffers
need to be declared in the “Data Arrays” section, the FieldServer virtual node(s) needs to be declared in
the “Server Side Nodes” section, and the data to be provided to the Clients needs to be mapped in the
“Server Side Map Descriptors” section. Details on how to do this can be found below.
Note that in the tables, * indicates an optional parameter, with the bold legal value being the default.
5.1.
Server Side Connection Descriptors
Section Title
Connections
Column Title
Function
Specify which port the device is connected to the
FieldServer
Legal Values
P1-P8, R1-R22
Port
110 – 115200, standard baud
rates only
Baud*
Specify baud rate
Parity*
Specify parity
Even, Odd, None, Mark, Space
Data_Bits*
Specify data bits
7, 8
Stop_Bits*
Protocol
Specify stop bits
1
Specify protocol used
DNP
Handshaking* Specify hardware handshaking
None
Example
// Server Side Connections
Connections
Port
P8
,Baud ,Parity ,Protocol ,Handshaking
,9600 ,None ,DNP ,None
2
Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction
manual for details of the ports available on specific hardware.
FS-8700-47 DNP 3.0 Driver Manual
Page 17 of 51
Legal Values
5.2.
Server Side Node Descriptors
Section Title
Nodes
Column Title
Function
Provide name for node
Up
to
32
Node_Name
alphanumeric
characters
Node_ID
DNP 3.0 station address of physical Server node 0-65535
Specify protocol used DNP
This parameter can be specified to configure the Class0;
Class_Data_Serving_Ctr*l Server to serve changed data only. Refer to Class2;
Protocol
Class1;
Class3;
Example 5.3.8 for more information.
Static
The name of a Data Array that has previously
been defined in the configuration in the Data
Server_II_Array
Max 15 characters
Arrays section.
Refer to Error! Reference
source not found..
Example
// Server Side Nodes
Nodes
Node_Name ,Node_ID ,Protocol
FieldServer ,11 ,DNP
5.3.
5.3.1.
Server Side Map Descriptors
FieldServer Specific Map Descriptor Parameters
Column Title
Function
Legal Values
Name of this Map
Descriptor
Name of Data Array
where data is to be
stored in the
Map_Descriptor_Name
Data_Array_Name
Data_Array_Offset
Function
Up to 32 alphanumeric characters
One of the Data Array names from “Data
Array” section above
FieldServer
Starting location in Data 0 to maximum specified in “Data Array”
Array
section above
Generally for Server side nodes you will
use the PASSIVE function. The WRBX
function may be used to generate
unsolicited messages.
Function of Client Map
Descriptor
FS-8700-47 DNP 3.0 Driver Manual
Page 18 of 51
5.3.2.
Driver Specific Map Descriptor Parameters
Column Title
Function
Legal Values
A Node Name specified in
“Client
Special
Node
Map
Descriptor”.
Descriptor’s
Node_Name
Name of Node to fetch data from
used by the DNP 3.0 Driver
are discussed in Error!
Reference
source
not
found..
Length of Map Descriptor. If a request length
is too large the DNP 3.0 driver will produce a
Length
message and a panic. The maximum length 1 – 1000
is a function of the data object and data
variation being processed.
Address
Starting address of data element to be read
0, 1 , 2 etc
The following parameters apply only to the DNP 3.0 Driver
Corresponds to the Data Object Types defined 1, 2, 10, 12, 30, 31, 32, 33,
DnpDataType in the DNP data object Library. Enter as
decimal number. Refer to Appendix A.9
Corresponds to the Data Object Variant
defined in the DNP data object Library. Enter
as decimal number.
40, 41, 20, 22, 23, 50,51, 52,
60, 80
When configured as a Server the driver can
respond to requests for the so called ‘Default’
variation. These are polls where the variation
0,1,2,3 etc
Legal values are determined
by the value of dnpDataType.
is zero.
DnpDataVari
To configure the driver to be able to respond
to requests for the default variation then you
must create a MapDesc where the
DNPDataVari=0.
Additional information is
provided in Appendix A.9
Note that the driver considers variation=1 as
the default in most case.
This parameter is ignored by the driver acting
as a Server. The qualifier of the incoming poll
is used to form the response. If the poll
qualifier is not supported by the driver’s
response function then the driver responds
DnpQualifier*
with Qualifier 1. The response function
supports the following qualifiers;
0,1,6,7,8,17,28,
Simply ensure that that there is a Server MD
for each object requested. No special actions
DnpMultiMsg are required to configure the Server to
respond to requests for multiple object types.
Refer to Appendix A.20 for more information.
5.3.3.
Timing Parameters
Legal
Values
Column Title
Function
Time Server side waits before notifying Client that node is
offline on FieldServer Client side.
Scada_Hold_Timeout
>1.0s
FS-8700-47 DNP 3.0 Driver Manual
Page 25 of 51
5.4.
Server Side Limitations
The DNP 3.0 Server can only parse a single poll per message. This means that a single message
cannot contain more than one read request - You cannot read two different objects types/variations in
a single read request. The same limitation applies to write commands sent the Server.
FS-8700-47 DNP 3.0 Driver Manual
Appendix A. Advanced Topics
Page 26 of 51
Appendix A.1.
DNP 3.0 Protocol.
The DNP 3.0 protocol is complex and not all the features are implemented by this driver.
•
The application layer performs a large set of potential functions, each of which can request its
own app layer confirmation transaction and many of which include a separate response
transaction.
•
The app layer messages are wrapped and unwrapped by the data link layer which can ask for
DLL layer ack's and confirmations.
•
•
•
The protocol provides for unsolicited messages.
The protocol defines and allows a huge set of data object & variations to be handled.
Not all DNP devices (slaves) provide all functions, data objects....
Appendix A.2.
DNP Driver Functionality
The DNP master driver has been developed to provide the functionality a FieldServer Technologies
Client requires in communicating with a DNP slave device as well as additional functionality and data
object handling. The DNP master driver is to be considered as DNP Subset Level 1 implementation
as defined in DNP V3.00 Subset Definitions Doc Number P009-0IG.SUB
The DNP slave driver has been developed to test the master driver and may NOT be considered a
DNP slave driver as defined in the DNP subset definitions.
Appendix A.3.
DNP Objects mapped to FieldServer Data Arrays
DNP objects consist of values and additional information such as quality, control and status bits as
well as time information.
The DNP driver allows this additional data to be extracted and mapped into the indicated data array.
For example, the DNP master driver can read 10 analog inputs with status flags and put the 10
values in consecutive order in one data array and the 10 status bytes in another data array.
Control of this functionality is achieved by setting up the CSV file correctly. If not specified the DNP
driver extracts data values and discards the additional data.
Appendix A.4.
Channel Idle, Master & Slave Idle.
The following notes describe the internal architecture of the driver and do not affect the way that the
driver is used or configured.
The Driver is implemented using the channel idle. The channel idle function is called in the master
mux but must be regarded as processing the channel (independently of the master or slave).
Chan Idle
•
•
•
•
•
•
•
processes all incoming bytes,
looks for complete messages,
From a DLL layer point of view parses the message and responds
Signals the master or slave app layer that there is an coming message
Signals master if there is an app layer response
Signals slave if there is an app layer request(read/write) or unsolicited message.
Looks for master or slave app layer signals to process an outgoing message
Maintains a list of nodes & node status (in terms of link reset)
Slave Idle
•
•
Looks for signals from chan idle that a message has been received
Parses message from an app layer point of view.
FS-8700-47 DNP 3.0 Driver Manual
Page 27 of 51
•
•
•
•
•
•
•
•
If required sets flags for
Map Descriptor matching,
fetch/store function calls
and/or response function call
Signals Chan idle the outgoing app layer message needs to be processed.
Looks for signals from chan idle that a message has been received
Processes Map Descriptors and forms read/write messages
Master Idle
Signals Chan idle the outgoing app layer message needs to be processed.
Appendix A.5.
DLL Layer Functionality in the Master
The DNP Primer provided by dnp.org describes the DLL layer requests for confirmation as optional
and suggests that it is not often employed. Our driver never asks for DLL layer confirmations. Thus
the DLL layer functions as a mere wrapper/unwrapper layer. It wraps user data with a header and
CRC's but does not perform node-node confirmations.
The only DLL layer functions which have been implemented are send and respond with user data and
link reset. The slave DNP driver will not respond until a link reset has been performed. The DNP
master driver sends a Link Reset request when a Map Descriptor requests data from an un-reset
node. The link resetting is performed on a node-node link.
Appendix A.6.
App Layer Functionality in the Master
The App layer provides over 40 app layer functions, confirmations and responses and allows for
handling of a huge number of data objects.
1. Read
2. Write
3. Select
App
Layer 4. Operate
Functions
6. Direct Operate with no Ack (limited)
8. Direct Freeze with no Ack (limited)
129. Response
130. Unsolicited. (Slave Driver can parse these messages.)
The Slave indicates its internal state by appending internal indication bytes to the
app layer header of each response. Thus it can report that it is faulty, corrupted or
unable to process the request. If it can’t find a matching Map Descriptor it sets the
internal indication bit used to indicate that the data object parameters specified
cannot be parsed.
Internal
Indications
You can configure a Server node to respond with the internal indications bytes that
are extracted from a Data Array allowing you to control them. For more
information, refer to Error! Reference source not found..
The app layer contains a Qualifier Byte used to control indexing for data objects.
The DNP 3.0 Driver only handles Qualifiers 00, 01, 07, 08, 17, 28. Qualifier 6 is
supported with limitations.
App
Qualifier
Layer
The DNP 3.0 (master) Driver never asks for an App Layer Confirmation. The DNP
3.0 Slave Driver is capable of responding to an app layer request for confirmation
(to allow it to process an unsolicited message which may ask for confirmation.)
App
Confirmation
Layer
FS-8700-47 DNP 3.0 Driver Manual
Page 28 of 51
Appendix A.7.
Internal Indications, Object 80 and DNP_II
The driver can store the Internal Indications Bits found in incoming messages and it is possible to
control the values of the internal indication bytes sent in responses. In addition, the driver can be
configured to respond to the Poll for Object 80 (Internal Indications)
A.7.1.
Incoming Internal Indications Bytes
This driver can expose data from the most recently consumed message and additional diagnostic
information using a special Map Descriptor called “DNP_ii” (DNP Internal Indications)
The following example shows the configuration of this Map Descriptor. Only one of these Map
Descriptors may be configured per FieldServer.
Nodes
Node_Name
Null_Node
,Protocol
,DNP
Data_Arrays
Data_Array_Name
DNP_DIAG
,Data_Format
,UINT32
,Data_Array_Length
,100
Map_Descriptors
Map_Descriptor_Name
dnp-ii
,Data_Array_Name,
,Node_Name
,Null_Node
,DNP_DIAG
,
The following data is stored in the Data Array DNP_DIAG.
Array
Element
Contents
The first byte of the Internal indication reported by a DNP device as found in the most
recently received message.
Only messages complete enough to warrant parsing will cause this item to be
updated.
0
1
DNP devices only contain internal indication bytes when the message is an application
layer response type message. Typically this includes all responses to data
queries/writes as well as unsolicited messages.
The 2nd byte of the response internal indication.
Bit zero is the least significant bit.
A one (1) in the bit position indicates the described state.
Bit
#
Explanation
First Byte
All stations message received
Set when a request is received with the destination address of the all stations address (ffff
hexadecimal).
Cleared after next response (even if response to global request is required)
Bit
0
Used to let the master station know that a Broadcasted message was received by this station.
Class 1 data available
Bit
1
Set when data that has been configured as Class 1 data is ready to be sent to the master
Master station should request this class data from the Outstation when this bit is set in a
FS-8700-47 DNP 3.0 Driver Manual
Page 29 of 51
Bit
#
Explanation
response
Class 2 data available
Bit Set when data that has been configured as Class 2 data is ready to be sent to the master
2
Master station should request this class data from the Outstation when this bit is set in a
response
Class 3 data available
Bit Set when data that has been configured as Class 3 data is ready to be sent to the master
3
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
Bit the Time and Date object to the Outstation.
4
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,
Bit the Outstation's control outputs are NOT accessible through the DNP protocol.
5
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 affect this bit.
This should only be used when the state can not be described by a combination of one or
more of the other IIN bits.
Bit
6
Device restart
Bit Set when the user application at the Outstation restarts.
7
Cleared when the master explicitly Writes a 0 into this bit of the Internal Indications object in
the Outstation.
Second Byte
Bit
0
Function code not implemented
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.
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
1
Bit
2
Event buffer(s), or other application buffers have overflowed. For example, COS/SOE buffers
Bit have overflowed. The master should attempt to recover as much data as possible and
3
indicate to the user that their may be lost data. The appropriate error recovery procedures
should be initiated by the user.
Bit
4
Request understood but requested operation is already executing.
Set to indicate that the current configuration in the Outstation is corrupt and that the master
Bit application layer should inform the user of this exception. The master may download another
5
configuration to the Outstation. Note that sometimes a corrupt configuration will disable an
Outstation, making it impossible to communicate this condition to a master station.
Bit
6
Bit
7
Reserved for use by agreement, currently always returned as zero (0).
Reserved for use by agreement, currently always returned as zero (0).
FS-8700-47 DNP 3.0 Driver Manual
Page 30 of 51
A.7.2.
Internal Indications reported in Responses
The Internal Indications (IIN) field is a two-octet field that follows the function code in all
responses. When a request cannot be processed due to formatting errors or unavailable data,
the IIN is always returned with the appropriate bits set.
A.7.3.
Server_II_Array
This parameter only applies to Server/responding nodes.
If specified the driver validates that the Data Array exists. If it doesn’t then Error 78 is printed.
The driver uses the 1st two elements to form the Internal Indications bytes of all normal responses
(responses where the driver is able to respond to the poll). The driver does not modify these
bytes when building the response but sends the values exactly as found in the Data Array.
If a poll for unknown and/or unsupported objects/devices is received, the driver builds the internal
indications bytes itself. They cannot be controlled using this parameter.
FS-8700-47 DNP 3.0 Driver Manual
Page 32 of 51
Appendix A.8.
DNP_Stats
In addition to the standard FieldServer communication statistics described in the FieldServer
Configuration Manual the DNP 3.0 Driver can expose some driver statistics by writing to a data array
called “DNP_STATS”
The following example shows how this special Map Descriptor can be configured. Only one of these
Map Descriptors may be specified per FieldServer.
Nodes
Node_Name
Null_Node
,Protocol
,DNP
,Node_ID
,100
Data_Arrays
Data_Array_Name
DNP_STATS
,Data_Format
,UINT32
,Data_Array_Length
,100
Map_Descriptors,
Map_Descriptor_Name
dnp-stats
,Data_Array_Name,
,DNP_STATS,
,Node_Name
,Null_Node
The driver stores the following data in the data array EGD_STATS.
Array
Contents
Element
1
2
3
4
5
6
7
8
DRV_DLL_CLIENT_SENDS_MSG
DRV_DLL_CLIENT_SENDS_BYTES
DRV_DLL_SERVER_SENDS_MSG
DRV_DLL_SERVER_SENDS_BYTES
DRV_DLL_CLIENT_RCVS_MSG
DRV_DLL_CLIENT_RCVS_BYTES
DRV_DLL_SERVER_RCVS_MSG
DRV_DLL_SERVER_RCVS_BYTES
DNP_UPD_TMO
9
10
11
12
12
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
DNP_UPD_PROTO
DNP_UPD_NOISE
DNP_UPD_CHECK
DNP_UPD_STATION
DNP_UPD_LENGTH
DNP_UPD_EXCEPT
DNP_UPD_STREAMING
DNP_UPD_FUNCTION
DNP_UPD_PREMATURE
DNP_UPD_IC_TIMEOUT
DNP_UPD_NAK
DNP_UPD_OVERRUN
DNP_UPD_HOLD_TIMEOUTS
DNP_UPD_NODE_OFFLINE
DNP_UPD_NO_SLAVE
DNP_UPD_NO_START
DNP_UPD_SCADA_BYTES_RECD
DNP_UPD_SCADA_BYTES_SENT
DNP_UPD_SCADA_MSG_SENT
DNP_UPD_SCADA_MSG_RECD
FS-8700-47 DNP 3.0 Driver Manual
Page 33 of 51
Array
Element
Contents
30
31
32
33
34
35
36
37
38
39
40
41
DNP_NOT_OK
DNP_UPD_RESET_RQD
DNP_UPD_CANT_RESET
DNP_UPD_NO_NODES
DNP_UPD_RESET_FAILED
DNP_UPD_MAST_DEBUG_MSG
DNP_UPD_MAST_PARSE_ERR
DNP_UPD_SLAVE_PARSE_ERR
DNP_UPD_MAPD_TOO_SHORT
DNP_UPD_TOO_MANY_BYTES3
DNP_DIAGNOTIC_GENERATOR
DNP_UPD_LINK_RESET_DONE
DNP_UPD_LINK_RESET_DONE_BY_MST
Increments once each time a link reset ack is sent by a master
DNP_UPD_LINK_RESET_DONE_BY_SRV
Increments once each time a link reset ack is sent by a slave.
DNP_UPD_LINK_STATUS_STATE
42
43
44
Result of most recent link status poll are stored here. 1=Busy, 2=Available, 0=Not
Update
Appendix A.9.
DNP 3.0 Data Objects
The DNP 3.0 Driver acting as a Client will produce a single message fragment. A message fragment
may contain a maximum of 249 bytes, some of which constitute overhead. The DNP 3.0 driver will
panic if the message fragment is too long. Reduce the length and add another Map Descriptor to poll
additional items. This limitation does not apply when the DNP 3.0 driver processes a response from
a query as the driver can process multi fragment responses.
The list of data objects supported and the functions used to access the objects is defined on the
Driver Fact Sheet which may be obtained from FieldServer Technologies. The table is known as a
DNP 3.0 Implementation Table.
The table below lists the objects and variations that be used in the Map Descriptors. The DNP 3.0
Driver supports all the objects with some exceptions. The exceptions are noted by indicating the
revision number of the driver prior to them being supported or by indicating that the object is not
supported with the NS annotation.
Default Variations are designated with a *. Not all Data Types have a default variation. The default
variation will be returned when a Client polls for variation zero (default). Server configurations require
a Map Descriptor with variation zero to be defined in the CSV file before the driver can respond with
the default variation data.
Object
Variation.
Ex
Description
1
1
1
2
2
2
2
0
1*
2
0
1*
2
Binary Input - All Variations
Binary Input
Binary Input with Status
Binary Input Change - All Variations
Binary Input Change without Time
Binary Input Change with Time
3
Binary Input Change with Relative Time
3
Increments by one each time a response message isn’t sent because the number of elements to
respond with requires too many bytes to fit in a message.
Tel: (408) 262 2299 Fax: (408) 262 2269 Toll Free |