From TF UML:
There are DO for the handling with time synchronization and leap seconds missing.
Proposal
Add DO LTIM.ClkSrcLeap (ENS)(Indicates which kind of time reference the clock source is providing.
New enum type SourceTimeReferenceKind:
1=Unknown
2=UTC
3=TAI
Add LTIM.Leap (ENS)(Indicates whether a clock source has introduced a leap second and if yes, how to interpret the timestamp); values for the enum type LeapSecondKind are so:
1=Unknown
2=Normal Time
3=Leap Second Pending (doc: within some time frame, typically 1 minute – no more than 1 day)
4=Leap Second Active
5=Next Second to be skipped
Both DOs carry condition AllOrNonePerGroup(1).
Discussion
Created
Status
Change to green
25 Sep 15
In Force (green)
Result of UML TF meeting:
In LTIM a new DO will be added:
Leap [CDC]ENS (LeapSecondKind) [Explanantion]Indicates whether a clock source has introduced a leap second and if yes, how to interpret the timestamp. [Presence condition]O / na
LeapSecondKind is defined:
Unknown value=1
Normal Time value=2
Last minute of the day has 61 seconds value=3
Last minute of the day has 59 seconds value=4
Additionally the explanation text of LTMS.TmSrc will be changed:
"Current time source identity. Format will depend on the value in 'TmSrcTyp' as follows:
- For 'TmSrcTyp'=PTP, the format is according to IEC 61588, 8.2.4.9.
- For 'TmSrcTyp'=SNTP, the format is the IP address of the SNTP server as specified in IEC 61850-6.
- For others, the value shall be 'na'."
These changes will be applied in edition 2.1.
18 Aug 15
Ballot Period
The discussion will be continued within next UML TF web meeting.
14 Aug 15
Future Improvement
I disagree with the LTIM.Leap definition. In SNTP the "leap indicator" defines if there is
0 no warning
1 last minute of the day has 61 seconds
2 last minute of the day has 59 seconds
3 unknown (clock unsynchronized)
So this doesn't fit to the defintion above for LTIM.Leap .
13 Aug 15
Future Improvement
The tissue will be applied in amendment 2.1 of part 7-4. Set to final proposal.
11 Aug 15
Ballot Period
ClcSrcLeap: Although the proposal is not perfect (as there is no perfect solution that involve Leap Seconds), it allows the expression if the clock source is taking into account leap seconds. This is an important concept because if the clock source adjust for leap seconds, the IED can't be TAI as it would never know the cumulative total of leap seconds without reconfiguration (since you can't algorithmically program when a leap second is going to be provided).
Leap: Needs to be provided so that interested clients/subscribers can be receive information regarding the pending status of leap seconds. In order to match the capabilities of C37.118, this information needs to be modeled so it can be included in a DataSet.
04 Aug 15
Discussion (red)
The leap second information should be precisely defined, when to set it and reset it.
"Leap Second active" does not exist in SNTP or 1588.
With SNTP, the "LI" flag means that a leap second will be inserted at the end of the day, but there is no prescription that it be set already in the morning. SNTP will only clear the flag when a client requests the time after the leap second.
In 1588, the Leap61 is cleared only in the Sync that follows the leap second.
What means "second to be skipped"? normally, the last second is doubled, not skipped. But if this is the case, then "Second to be skipped" must be set at least in the last minute and preferably at the beginning of the day (corresponds to leap59 in 1588). So it is either Leap=3 then Leap=4 or Leap=5.
If code=4 means that this code applies during the doubled second only, this must be specified.
I question the value of inserting such a time-sensitive parameter as leap second active in a Logical Node that is not read in real-time, time-stamping should not be made over the LTIM LN, but directly from the real-time-clock to the sample-and-hold logic.
Knowing that a leap second will occur at the end of the day is useful in financial stock markets to stop transactions during this second, but what is the use for protection systems which rely on time differences ?
Ceterum censeo: use TAI whenever you can and avoid the problems.