1606   Definition and use of timeTraceable amd currentUtcOffsetValid

Created: 30 Dec 2017

Status: Future Improvement

Part: Part 9-3 (Precision Time Protocol Profile)

Links:

Page:

Clause: C.7

Paragraph:

Category: Issue for edition 2 of this part

Issue

The definition of timeTraceable has been changed in IEEE 1588:201x to remove the dependency on timePropertiesDS.currentUtcOffset that is duplicated by the timePropertiesDS.UtcOffsetValid flag. This separates the TAI time scale validity from the UTC time scale validity. The timePropertiesDS.timeTraceable object is copied to the timeTraceable flag in the flagField of Announce messages. It indicates that the time scale in effect is PTP.

A master port of a clock in holdover should not clear the timeTraceable flag as long as it can estimate its time error from its reference time source.

timeTraceable is not used in the BMCA, it is not communicated to slave clocks since it is not present in parentDS dataset. Therefore, a clock that has not been synchronized to the time reference could displace a clock that is synchronized.

A time traceable clock deserves a higher priority than a frequency traceable clock. When a clock sets CurrentUtcOffsetValid, it is necessarily time traceable.

Proposal

The object timePropertiesDS.timeTraceable shall be initially FALSE when the device is powered up. It shall be TRUE after the clock has been synchronized within its nominal accuracy to a time source traceable to a primary reference time source. Is shall be FALSE if the clock is unable to estimate its time error from PTP time or is synchronized to an upstream clock that has the timeTraceable flag cleared.

NOTE timeTraceable is not used in the BMCA and not communicated to the application on the slave clock since it is not part of the parentDS dataset.

When currentUtcOffsetValid is TRUE, a master port shall set the most significant bit of Priority1 0, otherwise to 1.

Discussion Created Status
Let's wait for IEEE 1588-20xx to be published. 19 Oct 18 Future Improvement
SC65C WG15 decided not to wait for a future edition since it would require first publication and then field experience.
It is already clear the timeTraceable applies only to TAI, the reference to currentUtcOffsetValid has been deleted from IEEE 1588:202x.
In case timeTraceable is FALSE, Accuracy will be set to FF as suggested by Roman Graf, thereby affecting the BMCA.
If timeTraceable is TRUE but currentUtcOffsetValid is FALSE, this does not prevent the TAI clock from working and therefore a GM with a missing UtcOffset could win over a GM with a valid UtcOffset, but this has to be accepted. There is no fix for it.

Definitive text: The object timePropertiesDS.timeTraceable shall be initially FALSE when the device is powered up. It shall become TRUE after the clock has been synchronized within its nominal accuracy to a time source traceable to a primary reference time source. It shall be FALSE if the clock is unable to estimate its time error from PTP time or if the clock is synchronized to an upstream clock that has the timeTraceable flag cleared.
When timeTraceable is FALSE, a clock shall set its ClockAccuracy to 0xFF (unknown).
NOTE Loss of the time reference signal is not a reason to clear timeTraceable, as the clock enters holdover. 		19 Apr 18 Ballot Period
There is no complete and agreed text available as final proposal. Therefore, this Tissue is reverted to "red".
What is the exact clause of IEC/IEEE 61850-9-3:2016 that should be changed based on this tissue?
IEEE 1588:2008 7.6.2.5 says: "If the information to determine this estimate is not available, then the enumeration specification Unknown shall be used."
There is no evidence why 0x31 was chosen in the Tissue proposal. Moreover, this seems to contradict 1588.
And generally, why is it up to 9-3 to define this? I suggest to wait for 1588:201x being published and then refer that one from 9-3.
15 Feb 18 Discussion (red)
The following text is proposed to avoid changing Priority1:
When the timeTraceable flag is false, the ClockAccuracy shall be set to
0x31 (> 10s). 		31 Jan 18 Ballot Period
So what is your counter-proposal to ensure that a time traceable clock does not lose the BMCA in favor of a non-traceable clock? 30 Jan 18 Ballot Period
We disagree with the proposal to alter the Priority1, because this field is set by the user and is used by the BMC algorithm 30 Jan 18 Ballot Period
19 Jan 18 Ballot Period

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1