1846   The definition of LTMS.TmSrc is different in the actual AMD1 and Consolidated Version

Created: 10 Oct 2022

Status: Solution Accepted

Part: Part 7-4 (2020; Edition 2.1)

Links: #1883 Added more precise qualifications to TmSrcTyp , #1859 Description discrepancy LTMS between Source and Channels , #1775 IREG-B should be IRIG-B

Page: Page 131 (Consolidated)

Clause: 6.3.8

Paragraph: Table 50

Issue

There is an inconsistency between the actual AMD1 and the consolidated version of AMD1 for IEC 61850-7-4.
• The actual AMD specifies to use an enumerated value for the
TmSrc value per clause IEC 61588 8.2.4.9.
• The consolidated specifies to use the grandmaster identity for
TmSrc value per IEC 61588 clause 13.5.2.6.

This inconsistency may cause an interoperability issue.

Proposal

Both documents appear to have the intent that the actual identity value of the clock be used as the VSS. Therefore, it is suggested to update the actual AMD to align with the consolidated version (e.g. reference IEC 61588 clause 13.5.2.6.

Discussion Created Status
Ballot period expired without comment.
Move to solution accepted. 		21 Dec 23 Solution Accepted
Starting ballot period 15 Nov 23 Ballot Period
No change to test procedures. 14 Nov 23 Conformance Test Verification
Change to state: Conformance Test Preparation 17 Oct 23 Conformance Test Preparation
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 issues. 		10 Oct 23 Analysis Of Compatibility
Change to verify draft implementation together with #1775, #1846, #1859
26 Sep 23 Verify Draft Implementation
TmSrc is a data object to be included in a message (reporting, Goose etc.). It is not intended to be human-readable in first place, but to be transmitted with efficiency. In an HMI platform, the DO TmSrc could be easily converted into a human-readable format.

We have to consider more than one use case:
PTP - (this is the discussion) - I recommend like others: Hexadecimal without hyphen.
SNTP- already specified dotted IP-address
TmSrc from other types of time sources- local issue.

To be interoperable between different vendors, we should decide one format. We should take what the majority recommends.

Next step will be : drafting implementation. 		08 Dec 22 Drafting Implementation
TmSrc is supposed to be a human-readable string, which is why my comment on 25 Oct recommends to follow the IEEE document, separating each octet with a hyphen. If we want to deviate from the human-readable form presented in this IEEE document, we should have a proper reason.

The justification used in Henry/Joel's comments against delimiters is not based in fact. Per my comment on 25 Oct, IEEE 1588 does NOT represent clockIdentity as a string of an un-delimited string of hex characters.

The "50% more storage" argument is inconsequential.

As M.Hacker noted, IPv6 addresses will be delimited. 		08 Dec 22 Discussion (red)
Agree with 28_Nov-2022 recommendation except only upper case should be allowed to be consistent with value-to-string conversions in 61850-6 (see complexType@name=tP_VLAN-ID for example) 28 Nov 22 Discussion (red)
I recommend to present in TmSrc the clock identity

- For 'TmSrcTyp'=PTP as the value of the Grandmaster Identity as a string of non-case-sensitive hexadecimals without hyphen
(the 17 Nov example would look like '95b8c5fffe7d6ae0' or '95B8C5FFFE7D6AE0')

- For 'TmSrcTyp'=SNTP as dotted IP-address like specified for 'TmSrcSet'

- The format of TmSrc of other types of time sources (e.g. IREG-B) is a local issue.


Side note: Once we are going to allow IPv6, the IP separation character will be colon ":"
28 Nov 22 Discussion (red)
Agree, 50% more storage adds no value.

And, as Henry says, no reason to deviate from the IEEE doc. 		21 Nov 22 Discussion (red)
I recommend also having the simple hexadecimal representation converted to the VSS without hyphen. The hyphen does not give any additional value. 21 Nov 22 Discussion (red)
You are correct Michael. The ISO646String restriction for MMS Visible String does not allow to use the representation specified in 9-2: the Octet[8] for the clock identity in TmSrc.
Nevertheless, there is no technical need to specify a representation using hyphen as octet separation. 		21 Nov 22 Discussion (red)
This Tissue is about how a GM Identity Octet[8] shall be converted to a Visible string within a VSS CDC. According to 8-1, Visible string is represented in MMS with character set constrained to ISO646String, which only allows the lower 7 bits of each octet to be set.

For example, an Octet[8] GM Identity: [0x94, 0xb8, 0xc5, 0xff, 0xfe, 0x7d, 0x6a, 0xe0] must be converted to a different format before it can be used as a 61850 Visible string, because 6 of its octets have the 8th bit set, and therefore are invalid in a 61850 Visible string.

The comment at 08:54 today appears to miss this point. The other comments in this Tissue discussion should also be made public again until discussion is complete. 		17 Nov 22 Discussion (red)
To avoid multiplication of format for the identity of the clock master in 61850, I recommend to use in 7-4 the representation specified in 9-2: the Octet[8]. 17 Nov 22 Discussion (red)
IEEE 1588:2008 sections 7.5.2.2.2 and 7.5.2.2.3 include base-16 numerical examples of clockIdentity such as ACDE48FFFE234567_16 (subscript 16), and do not specify the string formatting of these EUI-64 or non-EUI-64 values. Therefore, I suggest the formatting as per my below comment, as per the IEEE document:
https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf

"EUI Structure and Representation", paragraph above Table 7:
"EUI-64 is ... shown in Table 7, using the example EUI-64 with base-16 form 'ACDE48234567019F' and the hex representation 'AC-DE-48-23-45-67-01-9F'."

The hex string representation should be hyphen delimetered (as opposed to the numerical base-16 form).
25 Oct 22 Discussion (red)
I don't want to specify more than in IEEE 1588. In section 7.5.2.2.2 and 7.5.2.2.3 of IEEE1588 (2008), there are described the EUI-64 or Non-IEEE EUI-64 clockIdentity values. There are no separators between octects.
I don't know if there other formats in version 2019 of IEEE1588.

Uppercase hex encoded string - I support. 		25 Oct 22 Discussion (red)
Both references are incorrect.

LTMS.TmSrc Explanation: "... For 'TmSrcTyp'=PTP, the format is according to IEC 61588, 13.5.2.6 ...".

"13.5.2.6 grandmasterIdentity (ClockIdentity)
The value of grandmasterIdentity shall be the value of the parentDS.grandmasterIdentity member of the data set."

This does not include a "format" that is compatible with VSS. grandmasterIdentity is an 8-octet array.

Proposed update to explanation:
"... For 'TmSrcTyp'=PTP, the value is according to IEC 61588:2009, 13.5.2.6, formatted as upper-case hexadecimal encoded string, with each octet separated by '-'. For example, 'AC-DE-48-23-45-67-AB-CD'.". 		18 Oct 22 Discussion (red)
1588-2019 Clause 5.3.4 defines the type of "ClockIdentity" as "Octet[8]" which is incompatible with the type VSS specified for TmSrc unless some conversion is declared. Note that 61850-6 format conversion for OCTET STRING is "base64Binary" which results in values such as "QQ==". It might be more useful to break from this encoding and instead use XML type "hexBinary" which is consecutive pairs of hexadecimal digits without whitespace characters (i.e. always an even number of characters).

I also note that for TmSrcTyoe=SNTP, there is no unique conversion specified for IP address but merely vague reference somewhere to 61850-6 (perhaps to clause 9.4.3) but even that references only tp_IP which references tp_IPbase which declares that each dotted component whose value is between 0 and 9 can optionally contain a leading zero. This issue can be addressed in part 7-4 by prohibiting leading zeroes in the format conversion of TmSrcTyp=SNTP values for TmSrc. It could also be addressed in 61850-6 but this would be a breaking change. 		10 Oct 22 Discussion (red)
Next stage: Discussion 10 Oct 22 Discussion (red)
Agree, IEC 61588 clause 13.5.2.6. shall be referenced in the IEC 61850-7-4:2010/AMD1:2020 document. The references in the consolidated version and in the NSD are correct. 10 Oct 22 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1