1818 Clarification of ExtRef attributes usage
- Created
- 26 Mar 2022
- Status
- In Force (green)Closed: the solution is part of the standard. No further comments are taken. Show the workflow
- Batch
- 57/2673/INFThis tissue went out with this batch, which was closed on 01 Apr 2024.
- Part
- Part 6 (2019; Edition 2.1)
- Links
- None
- 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 |
|---|---|
| Must Implement in force - batch 2 | 01 Apr 25 |
| Solution Accepted solution accepted | 22 Apr 24 |
| Ballot Period Tests proposal accepted | 22 Apr 24 |
| Conformance Test Verification https://redmine.ucaiug.org/issues/6749 | 16 Apr 24 |
| In Force (green) Batch '57/2673/INF' (2) closed | 01 Apr 24 |
|
Conformance Test Preparation
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 |
| Analysis Of Compatibility No objection to the proposed solution | 12 Mar 24 |
| Verify Draft Implementation Agreement on last proposal to be implemented | 19 Feb 24 |
|
Drafting 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 |
|
Discussion (red)
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 |
|
Approval (Editorial)
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 One file is attached to this tissue. Sign in to open it. |
28 Nov 22 |
|
Approval (Editorial)
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 (Editorial) proposal accepted, to be integrated | 05 Oct 22 |
| Accepted need clarification | 01 Jun 22 |