User manual
IEC61131 User and Reference Manual 
April 22, 2008     
481 
Note:  For proper operation of the router, there must be two routing entries in the routing 
table for each outstation; An entry specifying how the communication path from this 
router to the outstation and another communication path from the router to the 
SCADA DNP Master. 
Design Considerations 
The strength of DNP lies in its ability to offer time-stamped data, scheduled polling of data from 
multiple outstations and time synchronization, event data buffering and reporting by exception. 
DNP was originally design to be used over a serial point-to-point (RS-232) link. As such, the 
protocol implements certain measures against data corruption and data loss in its Application and 
Data Link layers. Such measures include timeouts, retries, and checksums. 
These data recovery mechanisms provided by the protocol, can be counter productive when not 
properly configured over an underlying communication medium, such as Ethernet, that already 
provides robust measures. In almost all of such cases, the recovery mechanisms offered by DNP 
need to be turned off. Such considerations together with good engineering judgment, therefore, must 
be practiced before one embarks on the design of a large DNP network. 
This chapter outlines special considerations of the DNP protocol and implications within the 
SCADAPack DNP driver that should be considered when designing large networks. We also list 
common malpractices and a list of Frequently Asked Questions (FAQs) that arise during the course 
of network design. 
Considerations of DNP3 Protocol and SCADAPack DNP Driver 
To ensure consistent network performance, even under worse case scenarios, the following DNP 
specification rules should be considered when designing a DNP network using SCADAPack as the 
main nodes. 
Unsolicited Messages always request for a Confirmation 
An outstation will always request for an Application Layer confirmation when it sends an unsolicited 
message, even if the Application Layer confirmation field is not enabled. If no response is received 
within an Application Layer timeout, the outstation will retry the message a number of times as 
determined by the Application Layer Retry parameter. 
Master shall never request for Application Layer Confirmation 
A Master request is always accompanied by a response message from an outstation. Hence, the 
Application Layer confirmation on the master RTU should never be enabled. 










