| Page 26 of 51 |
|
|
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
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. |
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 email: support@fieldserver.com
