1831   ldInst reference should concretized

Created: 12 Jul 2022

Status: Approval (Editoral)

Part: Part 6 (2019; Edition 2.1)

Links:

Page: 97

Clause: 9.3.7 Data set definition

Paragraph: Table 23

Issue

The ldInst of a FCDA refers to the data model of an IED without any restrictions-

In case of multiple accesspoint/servers you can refer from a dataset (FCDA element) inside server@AP1 to the LDevice.inst of server@AP2.

Proposal

add a restriction that only accessable/visible data references are allowed.

Discussion Created Status
for approval 16 Dec 22 Approval (Editoral)
updated the "fc" constraint in V3 proposal 08 Dec 22 Discussion (red)
The proposed changes in "tissue 1831_v2.zip" do not adequately cover that an FCDA that references "PTRC.Tr" with fc=MX is not permitted, per C.Brunner's first point on 29 Nov. 08 Dec 22 Discussion (red)
To clarify latest comment
1/ add restriction to Server instead of IED
-> the proposal is to clarify that an FCDA defined shall contains a data of the server where it is defined, as an IED may contains multiple server. Datasets cannot be created between different servers of the same IED. Add clarification on this point

2/ add constraint on the fc attribute related to daName
-> the restriction is not contradictory to the 7-2 and just remind that the definition coming from a CDC shall be respected in FCDA. But this may be removed as it shall follow 7-2 definition

3/ add restriction for FCDA to not allow referencing of data not available online
-> agreed 		01 Dec 22 Discussion (red)
While I basically agree to the conclusions, I think we need to take a step back and think about what rules belong to part 6 and what rules belong to part 7-2.

The rules of what is allowed in a dataset is purely the responsibility of part 7-2. Part 6 only tells us, how in SCL such a dataset is described.

So conclusion:
- constraints of a fc attribute related to da name is part 7-2 - a rule basically saying that a valid FCD may only contain a FC where there is at least one DA with that FC in the CDC (and that is not even related to datasets!)
- the restriction, that a dataset can only contain data that is visible - by 7-2 is a non-issue - as non-visible data does not exist in a 7-2 model, and as datasets are defined in 7-2, that is obvious. I agree that here we may add a note somewhere in part 6, that data witch valKind=conf is not available over the server (and hence does not exist for all consistency checks we do on the model)
- The issue about data from the IED versus data from the server is something that may require some discussion where that belongs. part 7-2 introduces the server. But it may not be clear in part 7-2 that there may be multiple servers exposing different data but those may be sourced from the same information base. Nevertheless, I think that as well is a clarification to be made in part 7-2, because it is out of the scope pf part 6.

So that is the beauty of the OCL approach. We will have OCL rules that are coming from other parts. But we then need to be careful, not to duplicate them (or worse: change them) with additional rules in part 6 		29 Nov 22 Discussion (red)
add proposal, considering the 3 points:
- add restriction to Server instead of IED
- add constraint on the fc attribute related to daName
- add restriction for FCDA to not allow referencing of data not available online 		28 Nov 22 Discussion (red)
Camille, all of these are coherency checks. None can be checked in the XSD schema, so if we want to check them it will need to be using OCL. However, OCL checks must be based on rules or requirements defined in some part of the standard.

It seems logical that the SCL FCDA element must correspond with a valid -7-2 FCD or FCDA, but I cannot find any explicit requirement for this in -6. Am I missing something?

Where in -7-2 is it required that an FCDA must refer to one or more data attributes available in the online data model? 		13 Oct 22 Discussion (red)
I disagree with your valKind=conf use case Camille.
DataSet are created in the online model, and therefore, all configured dataSetMember are to be visible online as well.
So valKind=conf would create serious issues in the creation of the online dataSet. 		13 Oct 22 Discussion (red)
Agree on the clarification for server reference.

Regarding any restriction of FCDA to be put into a dataset, this restriction is already stated in 7-2 FC description. Why to put another restriction in part 6?

The issue of a PTRC.Tr added in dataset with FC=MX is more a coherency check, and not a restriction in part 6, as Tr has no MX DA. This will be more an OCL rule which need to be created

Finally regarding the usage of FCDA with valKind=Conf, we can imagine one usecase which could be used to allow a remote device to read all configuration parameters by reading a dataset, even if all CF DAs are only set during configuration. So I see no need to add a specific requirement on that. 		05 Oct 22 Discussion (red)
Agree with proposed wording.

Regarding "Do we need to consider that the FCDAs cannot be solely composed of data attribute of valKind = Conf?" -- This seems like a special case of whether an FCDA can reference zero available data attributes? Similarly, is an FCDA that references "PTRC.Tr" with fc=MX permitted? There is a special rule if daName contains a non empty value. 		02 Aug 22 Triage
It makes sense to update the sentence above Table 22: from
"The FCDA ... of this IED to be contained in the data set." to
"The FCDA ... of this Server to be contained in the data set."

Do we need to consider that the FCDAs cannot be solely composed of data attribute of valKind = Conf?
02 Aug 22 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.3.6.1