1883 Added more precise qualifications to TmSrcTyp
- Created
- 31 Jul 2023
- Status
- In Force (green)Closed: the solution is part of the standard. No further comments are taken. Show the workflow
- Batch
- 57/2673/INFThis tissue went out with this batch, which was closed on 01 Apr 2024.
- Part
- Part 7-4 (2020; Edition 2.1)
- Links
- #1859 Description discrepancy LTMS between Source and Channels, #1846 The definition of LTMS.TmSrc is different in the actual AMD1 and Consolidated Version, #1775 IREG-B should be IRIG-B
- Page
- 135
- Clause
- 6.3.8
- Paragraph
- Table50
Issue
In the standard, the description of TmSrcType is "Type of the clock source", and the description of TmSyn is "Actual time synchronisation applied (see IEC 61850-9-2)". I think the description of TmSrcTyp is not accurate enough, for example, if the user has configured 1588 as a clock source, but there is currently no valid 1588 clock source, should TmSrcTyp be displayed as Unknown or PTP? As I understand it, TmSyn is used to display the actual time source for the device, while TmSrcTyp is only used to display the user's currently configured clock source. For example, in the case mentioned above, TmSyn should be Unknown, and TmSrcTyp should be PTP.
Proposal
Suggest to give more accurate description to TmSrcTyp, such as "Type of the configured clock source".
| Discussion | Created |
|---|---|
| Must Implement published with 2nd tissue batch | 28 Aug 24 |
| In Force (green) Batch '57/2673/INF' (2) closed | 01 Apr 24 |
|
Solution Accepted
Ballot period expired without comment.
Move to solution accepted. |
21 Dec 23 |
| Ballot Period Starting ballot period | 15 Nov 23 |
| Conformance Test Verification No impact on test procedures, this is already tested. | 14 Nov 23 |
| Conformance Test Preparation Change to state: Conformance Test Preparation | 17 Oct 23 |
|
Analysis Of Compatibility
The technical error does not address any of the use cases of Part 7-1, Annex K.
It is an improvement of the description text. In summary: no compatibility issue. |
10 Oct 23 |
|
Verify Draft Implementation
Change to verify draft implementation together with #1775, #1846, #1859
One file is attached to this tissue. Sign in to open it. |
26 Sep 23 |
| Drafting Implementation Change to draft implementation | 26 Sep 23 |
| Discussion (red) Change to Discussion state. | 22 Sep 23 |
|
Accepted
Suggested new description for TmSrcTyp:
Type of the actual clock source. The actual clock source is the preferred one of the configured sources acc. TmSrcSet and considering the redundancy mechanism. |
22 Sep 23 |
|
Triage
TmSrcTyp is an enumerated value (see Table 218). Therefore, its values are well defined for standardized time sync mechanisms, and could be extended with negative ordinals.
The value of TmSrcTyp impacts the value of TmSrc in Table 50. I agree that these values should remain in the lastknown state. I believe if TmChSt is implemented, its value would change. |
02 Aug 23 |
|
Triage
Your proposal ("Type of the configured clock source") would only work if only one time source is configured and therefore selected as actual.
The description could be: Type of the actual clock source. The actual clock source is the preferred one of the configured sources acc. TmSrcSet and considering the redundancy mechanism. |
02 Aug 23 |
|
Triage
This is my understanding too, if the configured signal is lost, TmSrcTyp should stay as it is, and TmSrc, as the current working time source identity, should be set to empty.
|
02 Aug 23 |
|
Triage
The DO TmSrcTyp doesn't give the format information of the configured time source.
TmSrcTyp is the information for the to-be-applied format of the actual time source. If the configured source is lost or not valid, TmSrc (VSS) should be NULL. But the TmSrcTyp should stay as it is. |
01 Aug 23 |