Test Procedure Working Groups » IEC 61850 TPWG » Test Procedure Issues » Server

I agree with Richard conclusions: the test is not practical. Remove the test from Rev1.1.

Thierry Dufaure wrote in #note-1:

I agree with Richard conclusions: the test is not practical. Remove the test from Rev1.1.

Agree.

WIKIPedia article actually says:
Although BIPM announces a leap second 6 months in advance, most time distribution systems (SNTP, IRIG-B, PTP) announce leap seconds at most 12 hours in advance.

https://www.ietf.org/rfc/rfc5905.txt (SNTP referenced by 61850-8-1:2020 consolidated) does not specify how far in advance of a leap second that LI (Leap indicator) flag need to be set by a time server.
The only relevant statement in RFC 5905 is:
LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9 .

Reference to PTP is irrelevant because sTm7 is only testing SNTP.

Therefore sTm7 remains relevant and no changes are needed to the test procedure.

Bruce Muschlitz wrote in #note-3:

WIKIPedia article actually says:
Although BIPM announces a leap second 6 months in advance, most time distribution systems (SNTP, IRIG-B, PTP) announce leap seconds at most 12 hours in advance.

https://www.ietf.org/rfc/rfc5905.txt (SNTP referenced by 61850-8-1:2020 consolidated) does not specify how far in advance of a leap second that LI (Leap indicator) flag need to be set by a time server.
The only relevant statement in RFC 5905 is:
LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9 .

Reference to PTP is irrelevant because sTm7 is only testing SNTP.

Therefore sTm7 remains relevant and no changes are needed to the test procedure.

I believe that the issue here is that the device will indicate Clock Not Synchronized long before the possibility of approaching an unexpected leap second, regardless of the sync protocol. Therefore, the condition is untestable.

Responding to Joel: 61850-7-2 specifies now that Clock-Not-Synchronized is set only when estimated error is greater than 1 second from UTC.
For a (bad) 100 PPM oscillator, this would take about 10000 seconds (3 hours). There is no requirement in SNTP to announce an upcoming leap second 3 hours ahead of midnight.

This is a system requirement that the annoucement has to be done long enough before it occurs, otherwise you go in the unreliable time stamps in case the snychronization is lost before midnight.
If user, on purpose set an hold over time interval, they want to have it working, even around midnight. The time is still valid during the HoldTms - therefore device can assume that LI annoucement are present at midnight - LPHD.HoldTms.

7-2 state "if the device is unable to determine if a leap second is occuring at midnight".
An implementation is allowed take the decision that LI fields have to be correctly set 5 min before midnight (LI fields seen before the loss of communication with the time server), and that they can relie on the annoucement 5 min before midnight in case the synchronization is lost 4 min before midnight.
sTm7 has been made mandatory is with redmine 635. To increase the reliabilty of time stamp, user shall proramme their clock server so that annoucement have to be trustfull a meaningfull time before they occur, to avoid that loss of synchronization shortly before midnight lead to a meaningless time stamping in the substation.