18   Functional naming and LDevice

Created: 30 Jan 2005

Status: In Force (green)

Part: Part 6 (2004)

Links:

Page:

Clause: 9.3.4

Paragraph: Table 14

Category: Issue for edition 2 of this part

Issue

According the explanation in the table, inst is the identification of the LDevice in the IED. According to Restrictions, it shall be unique within the IED. However, in the case of functional naming, inst needs to be unique within the bay as well; e.g. a main 1 and main 2 protection function might have the same LD inst name within the IED. In that case, with functional naming, it would not be possible, to differentiate them.
This is indirectly specified as well with the second restriction (“The LDName built from inst and other parts as described in 8.4 shall be unique within each SCL file”). But it would be more clear to directly say, that inst needs to be unique within the bay in case of functional naming. In addition, I am not sure, if the specification “within each SCL file” is good enough

Proposal

Add restriction “When using functional naming, inst shall be unique within the bay.”

Discussion Created Status
Juan Torres withdraw the negative vote on May 18 -- Tisue made green 18 Aug 05 In Force (green)
NEGATIVE vote by Juan Torres: Needs more explanation and discussion in WG10 12 May 05 Future Improvement
Final proposal:
LDName makes the use of functional naming obsolete. If a "FunctionNaming-like" naming, then, the hierarchie can be added by the user within the LDName attribute of each LDevice.
For backward compatibility, inst remains in the schema. As long as no LDName is specified, LDName = IEDName+inst.
For backward compatibility also, nameStructure element remains in the scheme.
01 Apr 05 Ballot Period
The proposal is backward compatible with the current SCL files, as long as only IED
related naming has been used. If functional naming had been used, then the functional name now must be explicitly written into the LDevice name attribute.

With this proposal the FuncName tag of the header becomes superfluous, except if the option shall exist to use IED related naming, although an LD name has been specified. On the other side it may be that IED CID files demand that the LD name is always in the name attribute, even for IED related names – which could then automatically be generated. These options should be discussed and decided.

If there is now a unique functional LD name at the IED, it seems natural to introduce this also as a reference at the Substation part LNode tags. This allows a customer to define functionally already all LDs he needs within an SSD file. In case that this LNode is later allocated to an IED, the choosen IED LD can take over the LD name. This might however lead to problems if the IEDs LD structure does not match that foreseen in the SSD file, which might lead to interpretation problems. Therefore, this option shall be clearly restricted to SSD files, with ldName reference removed (and may be taken over to IED LDevice name – this is then a local issue of the engineering tool) after allocation of LNode to a ‘real’ IED. This means that the ldName attribute instead of the ldInst attribute of the LNode element in the Substation section is only allowed as long as iedName=None.
31 Mar 05 Ballot Period

 

Privacy | Contact | Disclaimer

Tissue DB v. 24.12.6.1