Various status attributes indicate whether ClearSCADA is communicating with an outstation as expected (see Status Attributes Associated with Outstations on Advanced Drivers, and see Status Attributes Associated with Channels on Advanced Drivers).
ClearSCADA typically raises an alarm per affected database item should its attempts to communicate with an outstation be unsuccessful.
ClearSCADA can also optionally log an entry historically for those points:
- That are on an outstation with which ClearSCADA has attempted, but is unable, to establish communications
- That are on an outstation with which ClearSCADA was communicating, but then loses communications
- For which the outstation’s Log Historic Value on Communication Failure feature is enabled and the Persistence Timeout has expired providing that those points fulfil the following criteria:
- Have valid configuration
- Are In Service
- Are active (rather than new points for which ClearSCADA has not yet retrieved the initial value from the outstation)
- Are configured to store data historically (see Defining Historic Details for a Point).
- Have valid configuration
- Are In Service
- Are active (rather than new points for which ClearSCADA has not yet retrieved the initial value from the outstation)
- Are configured to store data historically (see Defining Historic Details for a Point).
The historic value that ClearSCADA stores (‘logs’) on communication failure comprises the last known value of the point (the latest value that ClearSCADA retrieved for the point before communications were lost). The entry is assigned a Quality of ‘Bad’ (see Quality). (With drivers that support additional OPC Qualities, a more specific ‘Bad’ Quality value might apply.)
You specify whether ClearSCADA is to Log a Historic Value on Communication Failure using the relevant section of the outstation’s Outstation tab.
Enabled
Select this check box if the outstation’s points are to log a value historically should ClearSCADA lose communications with the outstation. To log a value historically, the points has to adhere to the criteria mentioned above.
ATTENTION: We recommend that you avoid enabling this feature on outstations that have poor communications. If you do use this feature on outstations that have poor communications, ensure that you specify a suitable Persistence Timeout value. This will help to prevent ClearSCADA from logging too many values due to transient communications failures.
If an outstation’s points do log a historic value on communications failure, ensure that you are aware of The Effects of Logging a Value Historically on Communication Failure.
Clear the check box if the outstation’s points are not to log a value historically specifically due to ClearSCADA losing communications with the outstation. ClearSCADA will still log entries in the Event Journal and Alarms List for the outstation to indicate when such a change in communications status occurs.
Persistence Timeout
Use this field to specify the amount of time that has to elapse between:
- ClearSCADA first detecting that it is no longer able to communicate successfully with the outstation
and:
- ClearSCADA logging a value historically on the outstation's points as a result of that detection.
If ClearSCADA has not re-established communications with the outstation by the time that this Persistence Timeout has expired, the points that match the above mentioned criteria will log a value historically.
Enter the required persistence time in the OPC Time Format. We recommend that you specify an interval that is greater than the channel's Reestablishment Interval (see Establish Communications with Failed Outstations).
Specify a value of 0 if ClearSCADA is to log a historic value as soon as it is no longer able to communicate successfully with the outstation. You should only specify a value of 0 for outstations with which communications are normally very reliable.
The Persistence Timeout field is ‘grayed out’ and unavailable for use if the Enabled check box is clear.
Further Information
Recommended maximum sustained rate of historic updates per point: see Operational Limitations - Server.