251   Synchro back in time

Created: 07 Nov 2005

Status: Not Applicable

Part: Part 7-2 (2003)

Links:

Page: 024

Clause: 05.5.3.7.3.3

Paragraph:

Category: Issue for edition 2 of this part

Issue

There is a critical situation that requires special care with time stamps on each data change: when the synchronization (i.e. 06/10/2005 10:00:00.000) sent by the synchronization source forces the clock of the IED to go back in time (i.e. the time of the IED was 06/10/2005 10:00:00.989), it is possible that the time stamp of new data changes is prior to the time stamp of the data changes stored in the IED.

Another equipment (i.e. a RTU which sends the data changes to a Telecontrol) may need to distinguish that these last data changes are later than the previous ones, in spite of these previous ones have later time stamp (when some Telecontrols send a synchronization to a RTU, they need to receive the data changes occurred before the synchronization separated from the other ones occurred after the synchronization by the synchronization confirmation).

Proposal

A solution to this problem could be marking these data changes occurred between the moment of the synchronization (i.e. 06/10/2005 10:00:00.000) and the time (advanced) that had the IED in the moment of the synchronization (i.e. 06/10/2005 10:00:00.989), in order to point out this special situation. This mark could be a bit into the TIMESTAMP Common Data Type, for example, within TimeQuality definition.

Discussion Created Status
I agree with Wolfgang that this issue is out of scope of IEC 61850. It should be noted in the PIXIT that there are multiple time sources which may be used for time synchronization, and that the situation could happen that the IED's clock is set back in time through time synchronization.

I propose to keep the tissue blue. 		06 Jan 07 Not Applicable
We have found this problem when you have several synchronization sources and switch from to another (i.e. from GPS to telecontrol unit). In this cause, it is possible that IED syncronize back in time. We think that it is necessary mark those event generated between the moment of the synchronization and the time that had the IED in the moment of the synchronization. Otherwise, it could be a problem if we would have to analyze events which have suffered this shyncroback and we have not information about it. 22 Nov 06 Not Applicable
The handling of this problem is a local issue. The general requirement on time stamping just is that no jumps back in time are allowed. This can be solved by several means: very accurate clocks, very often time synch from master clock, clocks which only go 'slower', keeping the same time steady until in synchronisation again. At the end this adds to the time stamping inaccuracy to be stated in the PIXIT. 20 Dec 05 Not Applicable

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1