FS-8700-47 DNP 3.0 Driver Manual
Page 26 of 51
FieldServer Technologies
1991 Tarob Court Milpitas, California 95035 USA
Web
: www.fieldserver.com
Tel
: (408) 262 2299
Fax
: (408) 262 2269
Toll Free
: (888) 509 1970
Appendix A. Advanced Topics
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.
