Project

General

Profile

Feature #526

Definition of a data set must contain a data object name but SCL does not require the doName attribute in the <FCDA/> element

Added by Herbert Falk over 3 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Standard clarification required
Start date:
Due date:
% Done:

0%

Estimated time:
ID:
7
Source:
IOP_2017/9
TF Unique ID:
7 # IOP_2017/9
WG10 Proposal:

short proposal implemented -> OK: Specified in 6 Ed2.1. In Ed.3 XSD will include the restriction (now it is not possible for backward compatibility)

Estimated Completion:
(2019-06) No target date was set.
Discuss in Upcoming Meeting:
No
To discuss in WG10:
Short Proposal:

Forward to WG10: Recommend to update such that doName is mandatory. Clarify in -7-2, -6, maybe -7-1.In table at 3030 (INF of 2.1) it states: ThedoName attribute is optional only if the data set is assigned to a GSSE control blockProposed revision to remove the confusion about GSSE as a GOOSE Control block is GSEControl. Proposed the revised text to read “doName attribute is mandatory if the FCDA is for any other service other than the deprecated GSSE services.”.

Standard(s):

IEC 61850-6

Needs More Information:
Assigned TF:

Description

Definition of a data set must contain a data object name but SCL does not require the doName attribute in the <FCDA/> element.

There was an FCDA declaration for a dataset that contained a single entry:

&lt;FCDA ldInst="LD1" lnClass="MMXU" fc="MX" lnInst="1" /&gt;

This file would pass validation and was interoperable at previous interoperability tests.

However, 7-2 clause 12.3.3.2.2 defines an FCD as an attribute of a data object. The FCD definition above contains no attribute specification (just FC and MMXU).

Given the reference in 7-2 to data object it seems that the doName for the <FCDA/> should be mandatory. It is currently only mandatory for GSSE. Recommendation is that the doName attribute should be made mandatory in IEC 61850-6 Table 23 and the schema be updated accordingly.

The FCDA statement for the data set above should now be:

&lt;FCDA ldInst="LD1" lnClass="MMXU" fc="MX" lnInst="1" doName="Hz" /&gt;
&lt;FCDA ldInst="LD1" lnClass="MMXU" fc="MX" lnInst="1" doName="PhV " /&gt;
&lt;FCDA ldInst="LD1" lnClass="MMXU" fc="MX" lnInst="1" doName="A " /&gt;
#1

Updated by Vladan Cvejic about 3 years ago

  • Subject changed from Definition of a data set must contain a data object name but SCL does not require the doName attribute in the <FCDA/> element. to Definition of a data set must contain a data object name but SCL does not require the doName attribute in the <FCDA/> element
  • Status changed from New to In Progress
  • Short Proposal changed from Forward to WG10: Recommend to update such that doName is mandatory. Clarify in -7-2, -6, maybe -7-1. In table at 3030 (INF of 2.1) it states: The doName attribute is optional only if the data set is assigned to a GSSE control block Proposed revision to remove the confusion about GSSE as a GOOSE Control block is GSEControl. Proposed the revised text to read “doName attribute is mandatory if the FCDA is for any other service other than the deprecated GSSE services.”. to Forward to WG10: Recommend to update such that doName is mandatory. Clarify in -7-2, -6, maybe -7-1.In table at 3030 (INF of 2.1) it states: ThedoName attribute is optional only if the data set is assigned to a GSSE control blockProposed revision to remove the confusion about GSSE as a GOOSE Control block is GSEControl. Proposed the revised text to read “doName attribute is mandatory if the FCDA is for any other service other than the deprecated GSSE services.”.
  • Standard(s) changed from 6 to IEC 61850-6
  • WG10 Proposal changed from short proposal implemented -> OK (2019-06): Specified in 6 Ed2.1. In Ed.3 XSD will include the restriction (now it is not possible for backward compatibility) to short proposal implemented -> OK(2019-06): Specified in 6 Ed2.1. In Ed.3 XSD will include the restriction (now it is not possible for backward compatibility)
  • Discuss in Upcoming Meeting set to No

Checking done.

#2

Updated by Carlos Rodriguez del Castillo almost 2 years ago

  • Status changed from In Progress to Closed

Confirm to IEC 61850-6 editor that this issue has been accounted for.

Also available in: Atom PDF