1966   InRef / ExtRef Mapping at Data Attribute level

Created: 25 Feb 2025

Status: Discussion (red)

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

Links:

Page: 66

Clause: 6.2.2.2

Paragraph: Table 5 – Data objects of DomainLN

Issue

InRef Definition in IEC 61850-7-4 states, “Object reference of data object bound to the input n.”

InRef has an intAddr, which is intended to match the intAddr configured in ExtRef. Now, for product lines that manage internal addressing at the Data Attribute level, when they have multiple Data Attributes of the same Data Object with separate intAddr configured in the ExtRef configuration, there is no way to configure multiple InRef instances as its same DO, to match the DA level ExtRef configuration.

At the moment, I cannot find any clear explanation about this anywhere in the  standard. This shouldnt be seen as a vendor implementation issue as i believe its arising because of lack of clarity in standard on the various use cases of InRef.

Proposal

Configuration granularity level of InRef should match the ExtRef.

Therefore, either the text of the definition needs to be changed to, “Object reference of data object or data attribute bound to the input n,”

Or,

If InRef is restricted to the Data Object level (for whatever reason), clear guidelines or examples on InRef/ExtRef linking and use cases need to be updated in Annex H section of IEC 61850-6.

Discussion Created Status
Currently the ExtRef allows binding at the DO and/or DA level. Problem with DO's bindings is that we're trying to bind multiple DA's to a single internal word bit (intAddr). The use case for DO's bindings is typically for MMS reports/logs anyhow.

I propose ExtRef/Inref's only support binding at the DA level with a single intAddr. This would support the proposal to use different intAddr's (and ExtRefs) for 2 (or more) DA's.
14 Mar 25 Discussion (red)
open for discussion 28 Feb 25 Discussion (red)
changed state to accepted 28 Feb 25 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 25.2.18.2