1196   Extensions to standardized LN classes made by third parties

Created: 10 Dec 2013

Status: In Force (green)

Part: Part 7-1 (2011; Edition 2)

Links: #1468 Re-use DO from other LN

Page:

Clause: 14.3.2

Paragraph:

Category: Issue for edition 2 of this part

Issue

Clause 14.3.2 is not clear regarding to extension of standardized LN with standardized objects.
It seems that it only allows to extend standardized LN Class with data object of the 7-4 common ln. Data Object of Common LN (Mod, Beh, NamPlt, ...) are not extension of LN CLass but already belong to LN Class.

Proposal

The definition needs to be clarified and with examples of use of dataNs attribute depending of the name space of the LN and of the DataObject (re)used in the extension

Discussion Created Status
For Ed. 2.1 only. Also see tisuue 1468. 15 Jan 16 In Force (green)
16 Jul 15 In Force (green)
to respond to David points:
1) If GAPC is extended with the data object OpDlTmms, and OpDlTmms.dataNs references a private namespace, can the semantic of OpDlTmms in the private namespace then be different from the standard?

-> the standard does not define an OpDlTmms within the scope of GAPC, therefore OpDltmms in GAPC (as long as ING) is to be defined in a private namespace, and could theorically mean anything. If it is not a ING, it can not be named OpDlTmms.


2) Would it be compliant to extend GAPC with a standard data object name like Str but with private dataNs and number extension, thereby circumventing Tissue 742?
e.g. GAPC.Str1.dataNs = "my private namespace name"

Str is defined by the standard. As an interop - so it is defined already today.
Str1 within GAPC is a private extension of the GAPC and shall be place in a private namespace.
07 Jul 15 Ballot Period
1) If GAPC is extended with the data object OpDlTmms, and OpDlTmms.dataNs references a private namespace, can the semantic of OpDlTmms in the private namespace then be different from the standard?

2) Would it be compliant to extend GAPC with a standard data object name like Str but with private dataNs and number extension, thereby circumventing Tissue 742?
e.g. GAPC.Str1.dataNs = "my private namespace name"


15 Jun 15 Ballot Period
As agreed at the WG10 meeting in Regina, the resolution of this tissue will cover the two following use cases.

Extension of a standardized lnClass with a standardized DO:

-->dataNs is mandatory and shall be a private namespace, whatever the edition of the ldNs: IEC 61850-7-4:2003, IEC 61850-7-4:2007 or IEC 61850-7-4:2007B
-->E.g. GAPC is extended with the data object OpDITmms

Private LN using standardized DOs:

-->dataNs is optional and can be:
1)a private name space if the DO is present without the inheritance from an abstractClass. Applicable to ldNs edition IEC 61850-7-4:2003 and IEC 61850-7-4:2007
2)a standardized name space if the DO is present due to the inheritance from an abstractClass. . Applicable to ldNs edition IEC 61850-7-4:2007B. E.g. the data object Str is used in a private LN and Str is part of abstract LNs like PowerProtectionLN, FrequencyProtectionLN, etc.
15 Jun 15 Ballot Period
As long as there is no future standardized version of the LNClass that includes the DO extension in the context of the LNClass, the name space of the DO remains the private name space.
As soon as there is a future standardized version of the LNClass that includes the DO extension, the lnNs shall be the one of that future standardized version of the LNClass (except for LLN0, as LLN0.lnNs indicates the core version of 7-2, 7-3 and 7-4 used for the implementation of the logical device). Using the foreward declaration of the LNClass allows:
- to avoid the use of dataNs, as the forward declaration includes the DO extension
- to have foreward compatibility with future extension
- to use the presence condition that applies in the future standardized version of the LNClass, thus impacting presence condition of other DOs when the DO extension is implemented.

06 Feb 15 Discussion (red)
A standardized LN can either be extended by a new data object that must then contain the dataNs attribute or by standardized data objects in which case, I agree, the 7-1 rule should be enhanced.

With Ed. 2.1 and the UML model, there will be no more common LN.
Furthermore, by using inheritance, the UML model clarifies the rule for the extension of standardized LN with standardized objects. I propose that 7-1 refers to the model in 7-4 for this rule. 		10 Dec 13 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1