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

Created: 10 Oct 2022

Status: Discussion (red)

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


Page: Page 131 (Consolidated)

Clause: 6.3.8

Paragraph: Table 50


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
• The consolidated specifies to use the grandmaster identity for
TmSrc value per IEC 61588 clause

This inconsistency may cause an interoperability issue.


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

    Note: To see attachments you have to log-in first.

Discussion Created Status
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 and 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:

"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 and 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, ...".

" 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,, 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 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.