Many outstations support logged data—time stamped data that is stored at the outstation. When ClearSCADA retrieves an outstation’s logged data, it typically retains the outstation’s time stamp with that data (this time stamp indicates the data’s ‘occurrence time’).
On re-establishing communications with an outstation with which it previously lost communications, ClearSCADA will retrieve that outstation’s current data and, if applicable, its logged data. This might include point state and value changes that occurred while the outstation was unable to communicate with ClearSCADA. The server updates the entries in its database as it processes the retrieved data (see Processing Alarm Data for Point States).
For those outstations for which points log a historic value on communication failure, this might result in the historic value that ClearSCADA logs due to communications failure occurring chronologically after other logged point state and value changes. This will occur if the outstation has retained data that it logged before the communications failure occurred, and ClearSCADA was only able to retrieve that logged data once communications were re-established. The time stamps for those entries will show, correctly, that those particular point state or value changes occurred before ClearSCADA logged the historic value that indicated the communications failure. (However, the entries’ ‘Receipt Time’ will indicate that ClearSCADA retrieved the logged data from the outstation after it logged the historic value that indicated the communications failure—that is, once it had re-established communications with the outstation.)
An outstation stores (‘logs’) the following periodic data:
| Time | Value | Quality |
|---|---|---|
| 10:00:00 | 25 | Good |
| 10:15:00 | 30 | Good |
| 10:30:00 | 60 | Good |
| 10:45:00 | 65 | Good |
| 11:00:00 | 55 | Good |
ClearSCADA is to log a historic value for the outstation’s points should it lose communications with the outstation. This is defined by the Outstation’s Form including the following configuration:
- Log Historic Value on Communication Failure: Enabled
- Persistence Timeout: 10M (10 minutes).
ClearSCADA retrieves the outstation’s data at regular intervals.
At 10:30:10, ClearSCADA is unable to obtain a response from the outstation.
It detects the communication failure before it has retrieved the data that the outstation logged at 10:30:00.
After 10 minutes (the ‘Persistence Timeout’ period), ClearSCADA logs a historic value for those outstation points that match the ‘Log Historic Value on Communications Failure’ criteria (see Specify Whether Points Log a Historic Value on Communication Failure).
Communications is restored at 10:50:15. ClearSCADA retrieves the outstation’s data, including the logged values that it had been unable to retrieve earlier, due to the temporary loss in communication. ClearSCADA processes the values that it has retrieved and updates its database accordingly, so that it now includes the following entries:
| Time | Value | Quality | Comment |
Order |
|---|---|---|---|---|
| 10:00:00 | 25 | Good | Periodic | 1 |
| 10:15:00 | 30 | Good | Periodic | 2 |
| 10:30:00 | 60 | Good | Periodic | 5 |
| 10:30:10 | 30 | Bad* | 30 = most recent value at time comms lost | 3 |
| 10:45:00 | 65 | Good | Periodic | 6 |
| 10:50:15 | --- | --- | Comms restored | 4 |
| 11:00:00 | 55 | Good | Periodic | 7 |
* With drivers that support additional OPC Qualities, a more specific ‘Bad’ Quality value might apply.
The historic value that ClearSCADA logs on communication failure is assigned a Quality of ‘Bad’, as can be seen in the example above. Inclusion of such an entry in Historic Views or Trends is typically seen as providing a less accurate historic representation. The value is an ‘extra’ historic value that ClearSCADA has logged as a result of communications loss, rather than due to it being a point value that was retrieved from the outstation. If you have outstations that have the Log Historic Value on Communication Failure feature enabled, we recommend that you exclude ‘Bad’ Quality data from:
- Pre-Configured Historic Trends (see Configure a Trace)
- ‘Custom’ Ad Hoc Trends (see TRACE Optional Values)
- Historic Views (see Create a Historic View).
Further Information
Specify Whether Points Log a Historic Value on Communication Failure.
For more information about ‘receipt time’ and ‘occurrence time’, see Fields by Which you can Filter an Events List.