1818   Clarification of ExtRef attributes usage

Created: 26 Mar 2022

Status: Solution Accepted

Part: Part 6 (2019; Edition 2.1)

Links:

Page: 108

Clause: 9.3.13

Paragraph: Table 51

Issue

During SCL IOP 2021, the usage of ExtRef attributes for the different use cases was not well understood by different validation tools. Needs to be clarified

Proposal

Improve table 51 to clarify the condition of each attributes

Discussion Created Status
solution accepted 22 Apr 24 Solution Accepted
Tests proposal accepted 22 Apr 24 Ballot Period
https://redmine.ucaiug.org/issues/6749 16 Apr 24 Conformance Test Verification
Updated presence condition of ExtRef attributes based on the context:

- For later binding (in ICD or IID) all attributes related to subscribed data are forbidden: "iedName", "ldInst", "prefix", "lnClass", "lnInst", "doName", "daName", "srcLDInst", "srcPrefix", "srcLNClass", "srcLNInst", "srcCBName"

- for signal mapping, attributes "daName" and "desc" are always optional

12 Mar 24 Conformance Test Preparation
No objection to the proposed solution 12 Mar 24 Analysis Of Compatibility
Agreement on last proposal to be implemented 19 Feb 24 Verify Draft Implementation
As agreed with editors, there is no need to require the split into DA for any tool. This is a capability given to an ICT to express the supported DA by splitting a DO ExtRef into ExtRef per DA.

The last proposal remains valid and will be integrated in amendment 2.

This tissue impact interoperability and needs to be verified by a new conformance test 		24 Oct 23 Drafting Implementation
To complement the current proposal, is it required to have all ExtRef always split down to DA when FCD is defined in the dataset?

As per offline discussion it appears that:
"Explicit configuration description are always better than assumed consumption.
In Annex H, use case 1: the later binding is provided at pDO level, the full binding is done @ ExtRef.daName level, to specify which of the published data attribute have to be subscribed."

So is it required for the SCT to always split an FCD in multiple ExtRef, one for each DA available for the FC in the DO as defined in the FCD? 		06 Jan 23 Discussion (red)
1. ExtRef are representing the subscribed data and shall support all kind of subscription, and the standard allows subscription at DO level (especially for Report, but it's not forbidden for Gooses), so an ExtRef for report (for example) shall define th DO level, bu not necessarily the DA

2. The description is related to SCL files as it describes the content of the files, not what is produced by a tool. The tool related to the file is as per specification of the responsibilities of the files already in part 6 (i.e. an SCD is produced by the SCT and IID by an ICT)

3. The usecases are informative and just give practiical exemple of what is defined in the table. The normative table should not refere to an informative Annex. But in the annex I supply additional information related to the Table and what is implemented accordingly to the table specification

4. Agree, I updated the proposal

Regarding the columns, the third column is to express the mix of binding requested by the system and Later binding already realized, this is between second and last column. The last column represent the final binding when everything has been internally bound by te ICT. And right the ICD has not to have it. It is updated in the proposal 		28 Nov 22 Approval (Editoral)
This table needs additional clarifications:
1. Why is DA binding optional and DO mandatory? Most GOOSE/SV applications will be binding using FCDAs.
2. The header of the columns are not clear. Use cases should be defined in terms of the tools (SST, SCT, ICT) and not the file types. Other words, defining which tools can complete the bindings using later binding via ICT, or specified binding via SST, or integrated binding via SCT. These use cases should be re-defined in this context.
3. The use case numbers (1-4) are not referenced in the table
4. We should be using standard presence conditions. Replace "nd" with "f" if it's forbidden.

I agree that ExtRef needs clarifications, however from a tool perspective and not from a file perspective. 		26 Nov 22 Approval (Editoral)
proposal accepted, to be integrated 05 Oct 22 Approval (Editoral)
need clarification 01 Jun 22 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1