Why Should I Set my Outstation Clocks to use UTC time`

[Anonymous user]

📖 Home  Back  
UTC is fast becoming the industry standard time zone. In fact, the DNP3 protocol Technical Committee have announced that from 1st January 2008, all reported timestamps and time synchronization will use UTC.

UTC provides a constant time base that is not modified by daylight saving time adjustments. This means that it will report the same time for events occurring simultaneously in different time zones (this is not always the case with a local time base). Some outstations can convert UTC into local time, so that local time can be shown on the outstation's display and used in the outstation's applications. However, some models of outstation may not support this.

There can be problems with all three of the possible time bases (UTC, Local Time, and Local Time with DST), but there are far fewer complications with UTC. The possible problems include:

Unreliable data and the misinterpretation of timestamps

This only applies to Local Time and Local Time with DST. Misinterpretation of timestamps cannot occur with UTC as there is a single fixed time base.

The misinterpretation of timestamps can occur when Local Time is used, but it is more likely to cause problems when Local Time with DST is used. The problem is that anybody viewing the timestamps of the data from the outstation needs to know which time zone the outstation is using (so that they can subtract time from or add time to the timestamps accordingly). The same issue affects any applications that are running in the outstation; they may need to know which time zone is being used.

With Local Time without DST, as long as everything is configured correctly (channels etc.), the misinterpretation of timestamps is not a real problem, but it becomes a larger issue when Local Time with DST is being used. As outstations do not tag the data timestamps as DST, it is difficult to determine whether DST was being used by the at the time of the timestamp.

It is unlikely that your outstations will be polled at the time of the DST adjustment. In many cases, outstations are polled only once or twice a day. This means that when ClearSCADA polls an outstation, it needs to apply the correct adjustment to each timestamp to account for whether it is before or after the DST change. As we have already discussed, it can be difficult to determine whether a timestamped value was reported before or after the DST change and so this can result in unreliable data.

Even though some drivers do allow for DST adjustments, there are always problems around the time that the clock actually changed.

Incorrect timed activities

Timed activities may occur at incorrect times if all three of the following points apply:

• The outstation clock is set to UTC

• The outstation does not support UTC to Local Time conversions

• The outstation has applications that are Local Time dependent

As the outstation clock uses UTC and the UTC time cannot be converted into Local Time, the applications in the outstation cannot determine the Local Time from the only time that is available: the time in UTC. This means that the outstation applications will perform any timed activities at incorrect times. This is not a problem if the outstations support some form of UTC to Local Time conversion.

The problem of timed activities occurring at incorrect times also applies to outstations that have their clocks set to use Local Time without DST and also have applications that are dependent on Local Time with DST. As the outstation clock does not allow for DST adjustments, the applications that rely on DST times will be unable to determine the correct local time and so any timed activities will occur at incorrect times.

Two sets of data for the same time

This occurs when the outstation clock uses Local Time with DST. When the clock goes back an hour, time is effectively repeated. For example, if the outstation clock goes back an hour at 02.00, the outstation will have data with timestamps for 01.00-02.00 and then at 02.00, the clock will change back to 01.00 and so the next hour's worth of data will also be time-stamped with 01.00 - 02.00.

A gap in the data

When the outstation clock goes forward an hour, there will be no data for the 'missing hour'. For example, if the outstation clock goes forward an hour at 01.00, the outstation will have data with timestamps for 12.00-01.00 and 02.00-03.00 but not for 01.00-02.00 as at 01.00, the clock 'jumped' forward to 02.00.

Recommendation

We recommend that your outstation clocks are set to UTC and that all outstation applications are designed to work in UTC. If you need the timestamps to be displayed using Local Time at the outstation, the outstation may provide a way to convert the UTC timestamps into Local Time timestamps. Where possible, we recommend that you always program your outstation applications to convert from UTC time into Local Time (in most cases, this simply involves designing the program to add time to or subtract time from the UTC timestamps).

Do not use outstation applications to set the outstation clocks as this can cause time discrepancies in the data at the master station. Your outstation clocks should only be set by the ClearSCADA drivers or external time sources such as G.P.S.

Go: Home Back