Communications State - Failed (IO Timeout)

[Anonymous user]

📖 Home  Back  
The designers of ClearSCADA realized that in some cases it is advantageous to declare that a channel is failed, well before communications has failed to all the outstations. An example of this is for a channel with 50 outstations attached to it, and communications has been unsuccessful to 25 of them. In this scenario it is likely that there is a technical problem causing this channel to fail as it is unlikely that 25 outstations are out of service. Instead of continuing to check the availability of the other 25 outstations, it is reasonable to declare that the channel has failed and raise an alarm. Why wait for the other 25 outstations to fail before setting the alarm and telling the operator?

This behaviour of ClearSCADA is defined in the server configuration on the Global parameters -> Channel page. The relevant settings are:

• maximum number of consecutive failed reads timeouts

• maximum number of consecutive failed writes timeouts

These settings are set, by default, to 20 and 20 respectively. This typically allows for a small number (1-2 depending on the protocol and channel configurations) of outstations to fail before the channel is failed with the (I/O timeout) alarm.

In systems where there are large numbers of outstations on one channel, these settings will not be suitable. Having the settings too low will cause a channel to be failed with I/O timeout if there is a communication failure to a very small percentage of the outstations on the channel. It is possible that 3 outstations are being serviced at once, for example, and the other 47 outstations are still available. It is recommended that the maximum number of consecutive failed read/writes be increased to a point where a "reasonable" number of outstations that are offline do not cause the channel to be failed.

It is also worth noting the behaviour of a channel with only one outstation. It is unlikely to ever fail due to the server settings for maximum number of consecutive failed reads or writes. What will normally happen is the outstation will be declared as failed, and therefore the channel will stop trying to poll the only outstation, except for the re-establishment polls. What this means is that the outstation will alarm but the channel will not so it is important for the user to understand the importance of both channel and outstation alarms when troubleshooting.

When using switched outstation sets, it is especially important that the channel does not fail due to the max number settings as the switched outstation set will automatically switch to the backup channel when the server settings are reached and the switched outstation set will not follow its own setting for "Switch after X outstations have failed". This may cause confusing behaviour as the channel and the switched outstation set settings work against each other.

It is recommended that the server maximum number settings are increased to a point where the switched outstation set "switch after ..." setting has already acted.

Go: Home Back