In this section, we explain how ClearSCADA uses the Maximum Number of Consecutive Read Timeouts and the Maximum Number of Write Timeouts settings that are available on the Server Configuration Tool’s Channels settings:
The Maximum Number of Consecutive Read Timeouts and Maximum Number of Consecutive Write Timeouts settings are shown in the COM Ports/TCPIP Connections section of the Channels settings.
You need to understand how ClearSCADA uses these settings in order to apply suitable limits for your system. (You will also need to be aware of the Considerations when Setting the Maximum Consecutive Read/Write Timeouts).
Usually, when a driver in ClearSCADA sends a message to a remote outstation, it expects a reply from the outstation within a specific amount of time. To calculate the time period in which an outstation should respond, the driver performs a calculation that uses:
- The time at which the message was sent.
- The Standard Reply Delay setting of the channel (defined in the channel's configuration).
The DNP3 driver does not use this setting. Instead, it uses Data Link and Application Fragment settings which you can define on the Form for a DNP3 Channel.
- The transmission time of the message. The transmission time is a calculated estimate of the amount of time it should take to transmit the message to the outstation. The calculation to determine the transmission time is:
The driver also calculates an estimate of the amount of time it will take to send the reply. This calculation is based on the expected size of the response to the request.
Normally, the outstation will reply within the calculated time. However, if the outstation does not respond within the defined time, it could indicate a problem. Typically, the main reason for a reply time out is that the Standard Reply Delay (or DNP3 equivalent settings) is inappropriate. This is especially true during commissioning of a system.
To check if the delay setting(s) is suitable, you can view the I/O log files and see if the replies to the messages are being returned too late. If they are, you can adjust the delay settings as required. If the replies are not being sent too late, and then you will need to investigate the cause of the problem, which could be related to the outstation hardware, the communications connection between the outstation and the server, or could be a local fault at the server (unlikely, but possible). Also, you will need to determine whether the fault is a permanent problem that needs to be addressed or is a temporary problem that will resolve itself, for example, an intermittent network failure.
If a message is sent from ClearSCADA but the operating system does not confirm that the message has been sent, there is a problem. ClearSCADA will timeout the message and this will count as a write timeout. Similarly, if a message is sent as expected but there is no reply from the outstation within the expected time, the message is timed out (this counts as a read timeout).
When a read fault occurs, ClearSCADA increases the internal consecutive read timeout count by 1. For each consecutive read timeout, ClearSCADA will increase the internal count by 1 until the Maximum Number of Consecutive Read Timeouts limits is reached. If the limit is reached, ClearSCADA will take the following action:
- For channels with a Type setting of Network or TCPIP Listen, ClearSCADA deems the socket that is used by the outstation(s) to have failed and raises an I/O Timeout alarm. Only the socket and the outstation(s) that use that socket are failed, not the channel. ClearSCADA may still be able to communicate with other outstations via the channel.
- For channels with a Type setting other than Network or TCP/IP Listen (Serial, TCP/IP etc.), ClearSCADA deems the channel to have failed. At this point, ClearSCADA raises an I/O Timeout alarm. It also de-assigns the channel then re-assigns it in case the fault was local to the server and can be solved by reassigning the port (that is associated with the channel). If the re-assign is successful, ClearSCADA will continue to use the channel; if it is unsuccessful, the channel is failed and will remain failed until the underlying network or hardware problem is resolved.
Similarly, when a write timeout occurs, ClearSCADA increases the internal consecutive write timeout count by 1. For each consecutive write timeout, ClearSCADA will increase the internal count by 1 until the Maximum Number of Write Timeouts limit is reached. Again, if the limit is reached, ClearSCADA will fail the socket or the channel, depending on the configuration of the channel (as described above).
If a read or write fault is detected but the internal count has not reached the Maximum Number of Consecutive Read Timeouts/Maximum Number of Write Timeouts limit, ClearSCADA continues to use the channel. This is because the fault that caused the read/write timeout failure may be an intermittent problem that could quickly resolve itself, and so the channel may be healthy. If subsequent, consecutive read or write messages timeout, and then it is likely that there is a serious fault with the channel, the outstation(s), or a local fault at the server.
When you understand how ClearSCADA uses the consecutive timeout settings, you can proceed to set the Maximum Consecutive Read / Write Timeouts.
Or if you are already familiar with the considerations you need to make, you can go ahead and change Maximum Number of Consecutive Read / Write Timeouts.
For more information, see the topics that are listed in the gray footer section at the bottom of this topic. Select the relevant entry to display the topic that you require.