The DNP3 protocol defines two layers for which timing has to be configured:
- Data Link Layer—This layer handles the transmission of frames over physical communication links between the DNP3 devices. The Data Link layer helps to provide reliable transmission by implementing error and duplicate frame detection.
- Application Layer—This layer manages large messages, such as file and event buffer transfers. The Application layer splits large messages into fragments. which consist of one or more frames and data formatting.
Use the fields within the Communications Parameters section of the Scan Parameters tab to specify:
- Whether some of the properties within the Scan Parameters section (see Configure the Scan Parameters) are overridden by the Communications Parameters properties.
- The DNP3 timing for the Data Link and Application Layers.
NOTE: A channel’s Communications Parameters properties can be overridden on a per outstation basis (see Specify Different Comsmunications Parameters for an Individual Outstation). The Communications Parameters that you define on the Channel Form are usually appropriate for communications between the master station and outstations, as long as the outstations all use the same communications path. However, if there are outstations that use a different communications path, for example, outstations that communicate via a gateway, you may need to override the channel Communications Parameters in the outstations’ configuration. This will allow the outstations that use a different communications path to apply different communications parameters.
- Enabled—Select this check box to override several properties within the Scan Parameters section (see Configure the Scan Parameters) with the properties in this section.
Clear the check box if the properties in the Scan Parameters section are to apply to this channel. The rest of the fields within the Communications Parameters section are ‘grayed out’ and unavailable for use.
- Request Data Link Confirmation—Use this combo box to specify when ClearSCADA requests confirmation of Data Link frames from an outstation.
Choose from:
- Never—The ClearSCADA DNP3 driver does not request confirmation of Data Link frames.
- Sometimes—The ClearSCADA DNP3 driver requests confirmation of Data Link frames, but only if the Application Layer fragment consists of more than one frame.
This is the recommended option.
- Always—The ClearSCADA DNP3 driver always requests confirmation of Data Link frames.
Select this option if the DNP3 devices that are using this channel are operating in a environment with a high level of interference that affects communications.
- Data Link Retries—Use this field to specify the number of times that the ClearSCADA DNP3 driver is to re-send Data Link frames for which it has requested a confirm, and does not receive the confirm within the Data Link Timeout.
If the ClearSCADA DNP3 driver does not receive the confirmation within the Data Link Timeout, the Data Link frame is re-sent. If the frame is not confirmed before the timeout of the last retry, the transmission of the frame is deemed to have failed.
- Data Link Timeout—Use to specify how long the ClearSCADA DNP3 driver is to wait for a Data Link confirmation from the outstation, before re-sending the frame.
NOTE: The Data Link Retries and Data Link Timeout fields are not available if Request Data Link Confirmation is set to Never.
- Application Fragment Attempts—Use to specify the number of times that the ClearSCADA DNP3 driver is to attempt to send an Application Layer request. If this parameter is set to a value greater than one, ClearSCADA makes further attempt(s) to send a request, if it does not receive a response within the Application Fragment Timeout.
NOTE: This field specifies the number of attempts, not the number of retries. This field has to be set to a value of at least 1.
- Application Fragment Timeout—Use to specify how long the ClearSCADA DNP3 driver is to wait for an Application Layer response from the outstation, before re-sending the request. Be aware that:
- When the ClearSCADA DNP3 driver sends a request, the Application Fragment Timeout timer is not started until the last Data Link frame is sent
- Whenever the ClearSCADA DNP3 driver receives a Data Link frame associated with an Application Layer request, the Application Fragment Timeout timer is restarted.
For these reasons, it is unnecessary to set the Application Fragment Timeout to large values to account for multi-frame requests.
Set the Application Fragment Timeout so that it is large enough to allow for any Data Link retries. It should be set to at least:
((Data Link Retries + 1) * Data Link Timeout) + 1000For example, if you have Data Link Retries set to 2 and Data Link Timeout set to 3000 milliseconds, you should set Application Fragment Timeout to at least 10000 milliseconds (as (2 + 1) * 3000 + 1000 = 10000).
Example:
Consider a radio channel with the following configuration:
Request Data Link Confirmation = Sometimes
Data Link Retries = 2
Data Link Timeout = 1000 milliseconds
Application Fragment Attempts = 2
Application Fragment Timeout = 10000 milliseconds
ClearSCADA issues a DNP3 Integrity Poll request to a DNP3 outstation that has a large number of events stored in its event buffer(s).
The request from ClearSCADA is a single DNP3 Data Link frame, therefore ClearSCADA does not request a Data Link confirm from the outstation.
After the request has been sent by the ClearSCADA DNP3 driver, its Application Fragment Timeout timer starts.
While the ClearSCADA DNP3 driver is receiving frames from the outstation every 10 seconds or less, the Application Fragment Timeout timer does not expire, even though it might take the outstation more than 10 seconds to send the events to ClearSCADA.