489   Input for Logical Nodes: Data Object binding

This tissue has following status: blue

Created: 26 Mar 2007

Links:

Page:

Clause:

Paragraph:

Category: Issue for edition 2 of this part

Issue: FROM TISSUE #488: (Proposer: Antonio Gomez Bruque, SAC)
Binding to external inputs was first discussed in tissue 216. It was agreed to extend the common logical node information with the Data Object "GenIn" (or several instances of it) composed of two optional DataAttributes: "IntAddr" and "ExtRef". This external or internal mapping could be accurate enough for some logical nodes. However, in certain cases, such as MMXU, several input references are needed to bind the logical node to process. This could be resolved with different instances of "GenIn". But, how can we know if "A.phsA" is related with "GenIn1" or "GenIn5"? It would be very useful to have a more specific way which allowed the IED tool to assign external inputs to concrete Data Objects inside the logical node. In fact, the starting point of issue 216 was to make the SCL Inputs section visible over the comunication. It has to be taken into account that "ExtRef" element could specifiy values for the doName and even the daName.

Proposal: Extend all CDC's with two optional attributes with FC "IN" (Inputs): "IntAddr" of type VisibleString32 (for IED internal functions)
"ExtRef" of type ObjectReference (for other IED's objects).

Discussion Created Status
?
Ballot until Editor
In principle, we accept to have this information available. However, if we want to connect in the above example a specific input to A.phsA, then we should not use the generic input data "GenIn", but in that case we should have an input data like "phsAIn". This is a TISSUE for part 7-4. --> TISSUE 488 has been reopened; TISSUE 489 is a non-ISSUE 19 Apr 07 blue
I think this should be a TISSUE under general, since it needs a discussion which way it is best to do it - as poroposed in TISSUE 216 or as proposed in this new TISSUE. 26 Mar 07 white

 

Privacy | Contact | Disclaimer