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
The intention of this tissue is to address the issue faced by IED product lines that already manage internal addressing (sAddr and intAddr) at the Data Attribute level.
If InRef is strictly limited to pointing to the Data Object (e.g., CSWI.OpOpn), and we have four ExtRefs incoming for CSWI.OpOpn.general (with intAddr_1), CSWI.OpOpn.phsA (with intAddr_2), CSWI.OpOpn.phsB (with intAddr_3), and CSWI.OpOpn.phsC (with intAddr_4), all pointing to the same InRef at the Data Object level, there is no clear standard mechanism to indicate which of those ExtRefs (and their corresponding intAddr) should bind to general, phsA, phsB, and phsC respectively, within the IED's single InRef to CSWI.OpOpn.
The only way to handle this today is to create multiple InRef instances (e.g., InRef1, InRef2, etc.) for the same Data Object, keeping their object references at the Data Object level to align with the standard, and then configure different intAddr values for each InRef to indicate the specific Data Attribute and match the ExtRef configuration.
23 Jun 25
Discussion (red)
Since Edition 2.1, SCL offer the pLN, pDO, pDA to the ExtRef to allow the SCT to discriminate the conductor (DA) at the subscriber.
Therefore, the intAddr does not need to be different for stVal and q, or other attribute, because the {intAddr, pLN, pDO, pDA} allow to uniquelly qualified the conductor (DA).
The tissue is about bridging the InRef to the intAddr. Assuming that the intAddr is representing a DO with qualified conductor (pDA) then there is no need to have InfRef pointing to DA.
25 Apr 25
Discussion (red)
It is not a question of DAs bound to the same intAddr. The concern is having a DO (multiple different DA's with different FC's) being bound to a single intAddr. The analogy is a cable with multiple conductors. Each conductor (DA) can only be wired (bound) to a single terminal (intAddr).
21 Mar 25
Discussion (red)
Usecase for DAs bound to same intAddr is already described in part 6 Annex H, by differentiating them using pDA.
Both usage are possible, depending on how the IED implementation.
The intAddr usage is the responsibility of the ICT/IED and the standard is not intended to force a specific implementation but to allow expressing expected binding. This is the purpose of Annex H to give different usecases.
InRef are restricted to DO binding, not DA, as per definition in 7-4
19 Mar 25
Discussion (red)
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.