1656 Meaning of valKind=Conf is not clear
Created: 21 May 2019
Status: Discussion (red)
Part: Part 6 (2009-12; Edition 2)
Clause: Table 46
Category: Issue for edition 2 of this part
Conf: "This value is not visible online at the IED. The IED is engineered such that this value is used" does not prohibit server from exposing the data attribute
Change to "This value SHALL not be visible online at the IED. The IED is engineered such that this value is used"
Also it is recommended that valKind=Conf should not be used except in servers which are significantly resource-constrained because other devices in the system might be able to use the online object value.
In the IEC langage, the expressions:
"This value is not visible online at the IED."
"This value SHALL not be visible online at the IED."
|29 Jul 19
The usage of ValKind="Conf" is decided by the manufacturer. If a manufacturer is not supporting this online filtering, he is not forced to support it.
Then the change of valKind to Conf in DAI is not allowed to be done by SCT. The only modification which could be allowed is from Set to RO, and this capability is defined at services level with service ValueHandling as already defined in ed2 interop tissue 1646 (already fixed in AMD1 of part 6).
So, there is no need to change the principle of valKind="Conf" (at DA or DAI level) and let this responsibility to the manufacturer.
Clarification proposed by Bruce is enough
|29 Jul 19
I don't think the language is the problem here. Replacing "is not visible" with "SHALL not be visible" may be slightly clearer, but the real problem is the complexity of making it "not visible online" (i.e. removing the attribute from the MMS data model). I have seen several SCL files with valKind="Conf" in <DA> elements (especially for "dataNs" and "cdcNs"), so it is probably too late to change the behavior in this case.
But it is much more complex to support valKind="Conf" in a <DAI> element. Removing an attribute AFTER the MMS data type has been completely defined is very awkward and error prone. This could also lead to multiple LN defined with exactly the same LNodeType but their MMS data types are different because certain attributes were removed because of DAIs with valKind="Conf" (confusing). But I have NEVER seen a SCL file with valKind="Conf" in a single DAI.
Since nobody seems to want or need this behavior, it would be safer for everyone if a statement is added to IGNORE valKind="Conf" in a DAI (i.e. leave the attribute visible online). Without this statement, we are all forced to include code to remove the attribute just in case one vendor defines a single DAI with valKind="Conf" (perhaps accidentally). Since nobody has tried such a configuration, it is impossible to know if everyone can correctly handle this.
|26 Jul 19
Privacy | Contact | Disclaimer
Tissue DB v. 184.108.40.206