Subscribing is a smart move!
You can subscribe to this forum after you log in or create your free account.
Understanding DNP3 Timing Parameters
Geo SCADA Knowledge Base
Access vast amounts of technical know-how and pro tips from our community of Geo SCADA experts.
Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we?ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
📖 Home Back
The best reference for this information is the DNP3 Driver Guide available in the online help. A summary of this information is presented below as an overview to what settings can be configured. For detailed information on the exact behavior of any of these settings, refer to the online help.
DNP3 is a protocol that allows for fine tuning of attempts and retries to cope with different types of communications, including poor communications paths. DNP3 is a multi layer protocol. The two major layers are the Application layer (AL) and the Data Link Layer (Link layer or LL). The AL message is the top level message that requests a high level function from the outstation or indicates a high level response from the outstation to the master station or another outstation. Each of these layers can be controlled individually from within ClearSCADA.
Control of communications to DNP3 outstations is handled by both the DNP3 channel object and the outstation object itself. In many systems, outstation specific timing parameters need not be set, and all timing is handled by the channel. Thus any outstation connected to that channel will behave in the same way.
The use of these settings on the channel varies depending on whether the Communications Parameters have been enabled (further down the form and shown below). It is recommended that for reliable outstation communications, these settings are ALWAYS enabled (they are enabled by default).
DNP3 Communications Parameters.JPG
These settings on the channel apply to all outstations on that channel. It is possible to modify this such that each outstation can have its own unique settings. To setup an outstation independent of the channel, simply enable the Communications Parameters on the outstation object and configure timing parameters as required. Note that any outstation that has its own Communications Parameters disabled, will inherit the properties from the channel to which it is connected.
It is important that when these timing parameters are configured, they are done so sensibly to ensure appropriate system operation. To configure these parameters, consider the following:
How often should the communications on this outstation indicate a failure. For example, if the integrity poll interval is set to 1 hour, you may want to set the Transaction Attempts to two. This would then mean that a single failure to poll the device would not cause a communications failure. After the second hours attempt, if comms was still unavailable, the outstation would be marked with comms failure.
Typically this setting would be configured in the order of 500-1000ms. Based on most DNP3 networks, this small delay allows for traffic on the network to be sent and received without ClearSCADA flooding the network with instantaneous responses.
How long do you want to wait for healthy sites to come back online? On many systems, this setting seems to have been set at something as small as 30s, however something in the order of 300s is more appropriate. The key to remember here is that each time the reestablishment interval expires, a physical transmission on the network takes place. If you have many outstations which have failing communications and need to be reestablished, then many messages will be transmitted each interval to attempt to bring them all back online. Given that poll periods will often be in the order of an hour or more, a five minute reestablishment interval is not inappropriate.
This should always be set to Sometimes. If only a single LL frame message is sent, and Never mode is selected, then the message will time out on the AL response timeout. If it is a multi frame message, then if one frame fails, the entire (much larger) message will fail and need to be retransmitted. Never mode would only ever be used on a highly reliable network such as ethernet. If set to Always mode and no LL response is received from the outstation, the single frame message will timeout and then retry on the link layer. There is no real benefit here as an AL confirm to a single frame tells us the same thing as the LL confirm, only it has required two messages from the outstation instead of one. For a multi frame message, always mode allows individual LL frames that fail to be retried. This is much more efficient than timing out on the AL.
For Sometimes mode (recommended), a data link confirmation is only requested if more than one frame will be sent. This means that for single frame messages, you do not require two confirms (LL and then AL), where multi-frame messages will be more efficient as only the failed frame will be retried rather than the whole message on the AL.
Given that ClearSCADA very rarely sends multi-frame messages (file or configuration downloads), Sometimes mode is by far the best option.
This is a setting that should be configured to match the network and the outstation. Good practice in these settings is to try and match the ClearSCADA settings with those in the outstation. A figure of 2 retries will suffice in most instances.
This setting depends entirely on the speed of the DNP3 connection to the outstation. Once again, it is suggested that this setting match the settings in the outstation.
How many attempts (including the initial attempt) should be made for this message to the outstation? Note that one AL sequence including all the retries defined by this parameter, make up one transaction for the purposes of the comms failure Transaction Attempts.
This setting determines how long ClearSCADA should wait after sending an AL message for a valid AL response. When ClearSCADA sends a LL response to a LL frame received from the outstation, it resets the Application Fragment Timeout (AFT). This means that the AFT should therefore be greater than the sum of the LL timeouts (including retries) so that a single LL frame being lost will not result in an AL timeout. So as an example, a LL timeout may be set to 10s and be configured for two retries. A valid AL timeout would be something in the order of 35s ie. a LL timeout of 10s + 2 LL retries of 10s, plus some leeway to handle the retry overhead.
Again, this setting in ClearSCADA should match the setting in the outstation for optimal performance.
Go: Home Back
The best reference for this information is the DNP3 Driver Guide available in the online help. A summary of this information is presented below as an overview to what settings can be configured. For detailed information on the exact behavior of any of these settings, refer to the online help.
DNP3 is a protocol that allows for fine tuning of attempts and retries to cope with different types of communications, including poor communications paths. DNP3 is a multi layer protocol. The two major layers are the Application layer (AL) and the Data Link Layer (Link layer or LL). The AL message is the top level message that requests a high level function from the outstation or indicates a high level response from the outstation to the master station or another outstation. Each of these layers can be controlled individually from within ClearSCADA.
Control of communications to DNP3 outstations is handled by both the DNP3 channel object and the outstation object itself. In many systems, outstation specific timing parameters need not be set, and all timing is handled by the channel. Thus any outstation connected to that channel will behave in the same way.
The use of these settings on the channel varies depending on whether the Communications Parameters have been enabled (further down the form and shown below). It is recommended that for reliable outstation communications, these settings are ALWAYS enabled (they are enabled by default).
DNP3 Communications Parameters.JPG
Common Configuration Options
| Section | Name | Description | |
| Scan Parameters | Transaction Attempts | The number of AL attempts before failing the communications to this outstation. This is independent of the Application Fragment Attempts and allows ClearSCADA to maintain communications as healthy even if one message to the outstation was unsuccessful. | |
| | Inter Message Delay | The delay between messages to the same outstation. So if a message is received by ClearSCADA and the delay is 10ms, ClearSCADA will wait 10ms before sending the response. Useful for throttling network utilization. | |
| | Reestablishment Interval | Once an outstation has failed, this time determines how often ClearSCADA tries to reestablish communications to the outstation. Between each failure, this time period will elapse before the next attempt. | |
| Communications Parameters | Enabled | Determines whether DNP3 timeout settings are used or the generic Advanced Driver timing behavior. This should ALWAYS be set to true. | |
| | Request Data Link Confirmation | This setting controls whether ClearSCADA requires a LL confirmation when sending messages. The LL confirm allows the failed link layer frame (which is much smaller) to be retried, rather than failing the whole AL message and retransmitting all data. There are three settings: Never, Sometimes and Always. Never means never request a confirmation from the outstation to each link layer frame, Always means always request one. Sometimes means only request a LL confirm message from the outstation if ClearSCADA will be sending more than one LL frame. | |
| | Data Link Retries | Determines how many retries ClearSCADA will perform on a single LL frame. | |
| | Data Link Timeout | Determines how long ClearSCADA should wait after sending a LL frame for the confirm from the outstation. | |
| | Application Fragment Attempts | Determines how may AL message attempts ClearSCADA should perform. Each AL message could contain multiple LL failures, with the message being successfully retried at the LL level. This does not impact the AL message as long as all data is received successfully by the AL. | |
| | Application Fragment Timeout | Determines how long ClearSCADA should wait for a valid AL response before timing out the AL message and retrying. | |
These settings on the channel apply to all outstations on that channel. It is possible to modify this such that each outstation can have its own unique settings. To setup an outstation independent of the channel, simply enable the Communications Parameters on the outstation object and configure timing parameters as required. Note that any outstation that has its own Communications Parameters disabled, will inherit the properties from the channel to which it is connected.
It is important that when these timing parameters are configured, they are done so sensibly to ensure appropriate system operation. To configure these parameters, consider the following:
Transaction Attempts
How often should the communications on this outstation indicate a failure. For example, if the integrity poll interval is set to 1 hour, you may want to set the Transaction Attempts to two. This would then mean that a single failure to poll the device would not cause a communications failure. After the second hours attempt, if comms was still unavailable, the outstation would be marked with comms failure.
Inter Message Delay
Typically this setting would be configured in the order of 500-1000ms. Based on most DNP3 networks, this small delay allows for traffic on the network to be sent and received without ClearSCADA flooding the network with instantaneous responses.
Reestablishment Interval
How long do you want to wait for healthy sites to come back online? On many systems, this setting seems to have been set at something as small as 30s, however something in the order of 300s is more appropriate. The key to remember here is that each time the reestablishment interval expires, a physical transmission on the network takes place. If you have many outstations which have failing communications and need to be reestablished, then many messages will be transmitted each interval to attempt to bring them all back online. Given that poll periods will often be in the order of an hour or more, a five minute reestablishment interval is not inappropriate.
Request Data Link Confirmation
This should always be set to Sometimes. If only a single LL frame message is sent, and Never mode is selected, then the message will time out on the AL response timeout. If it is a multi frame message, then if one frame fails, the entire (much larger) message will fail and need to be retransmitted. Never mode would only ever be used on a highly reliable network such as ethernet. If set to Always mode and no LL response is received from the outstation, the single frame message will timeout and then retry on the link layer. There is no real benefit here as an AL confirm to a single frame tells us the same thing as the LL confirm, only it has required two messages from the outstation instead of one. For a multi frame message, always mode allows individual LL frames that fail to be retried. This is much more efficient than timing out on the AL.
For Sometimes mode (recommended), a data link confirmation is only requested if more than one frame will be sent. This means that for single frame messages, you do not require two confirms (LL and then AL), where multi-frame messages will be more efficient as only the failed frame will be retried rather than the whole message on the AL.
Given that ClearSCADA very rarely sends multi-frame messages (file or configuration downloads), Sometimes mode is by far the best option.
Data Link Retries
This is a setting that should be configured to match the network and the outstation. Good practice in these settings is to try and match the ClearSCADA settings with those in the outstation. A figure of 2 retries will suffice in most instances.
Data Link Timeout
This setting depends entirely on the speed of the DNP3 connection to the outstation. Once again, it is suggested that this setting match the settings in the outstation.
Application Fragment Attempts
How many attempts (including the initial attempt) should be made for this message to the outstation? Note that one AL sequence including all the retries defined by this parameter, make up one transaction for the purposes of the comms failure Transaction Attempts.
Application Fragment Timeout
This setting determines how long ClearSCADA should wait after sending an AL message for a valid AL response. When ClearSCADA sends a LL response to a LL frame received from the outstation, it resets the Application Fragment Timeout (AFT). This means that the AFT should therefore be greater than the sum of the LL timeouts (including retries) so that a single LL frame being lost will not result in an AL timeout. So as an example, a LL timeout may be set to 10s and be configured for two retries. A valid AL timeout would be something in the order of 35s ie. a LL timeout of 10s + 2 LL retries of 10s, plus some leeway to handle the retry overhead.
Again, this setting in ClearSCADA should match the setting in the outstation for optimal performance.
Go: Home Back
Author
Create your free account or log in to subscribe to the forum - and gain access to more than 10,000+ support articles along with insights from experts and peers.