Project

General

Profile

Issues #6633

sRp15, sBr15 test description contains doName="MMXU...", while MMXU is lnClass, not doName

Added by Ursula Kramarczyk 12 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Richard Schimmel
Due date:
01/09/2024
Discuss in Upcoming Meeting:
No
Clause Reference:
IEC 61850-6 AMD1: Table 22 - Attributes of the FCDA element
61850 Standard:
6
Triggering Tissue:
Final Decision:
Initial Test Document:
UCATestProceduresServer61850-8-1Ed2Am...
Updated Test Document:
TP1.3
Test Case ID:
sRp15
Closed Reason:
--Not Set---
Triggering Tissue 2:
Triggering Tissue 3:

Description

The test case sRp15 and sBr15 description gives in point 1 the SCL examples of following FCDA elements of a dataset:
- doName=”MMXU.PhV”
- doName=”MMXU.A” daName=”phsA”
- doName=”MMXU.A” daName=”phsB.cVal”
- doName=”MMXU.A” daName=”phsC.cVal.mag”
- doName=”MMXU.A” daName=”neut.cVal.mag.f“

But in SCL, in the the dataset elements, a Logical Node (and MMXU is a Logical Node) are defined by lnClass and lnInst, not in doName, e.g.:
<DataSet name="dataMX">
<FCDA ldInst="ON" lnClass="MMXU" lnInst="1" doName="PhV" fc="MX" />
<FCDA ldInst="ON" lnClass="MMXU" lnInst="1" doName="A" fc="MX" />
</DataSet>

And, complex Data Objects like PhV and A (class WYE) have sub-elements (e.g. phsA) which are Data Object, not Attributes - of class CMV. The FC is defined by DA elements of CMV, not by elements of WYE. Is then daName=”phsA” wrong as "phsA" belongs into doName?

Files

Solution to redmine 6633 sRp15.docx Solution to redmine 6633 sRp15.docx 23.2 KB Richard Schimmel, 12/19/2023 06:18 AM

Also available in: Atom PDF