IEC 61850 User Feedback Task Force

More details on the use case :
- Clarification needed only for ValImport (not for ValKind)
- It seems necessary to have a mechanism which allows to block the modification of a value or parameter defined by the SCT in the SCD by another tool (e.g. IED configuration tool), necessary for top-down engineering. If valImport is not appropriate for this, it needs to be clarified which parameter or mechanism can be used. The unauthorized automatic update by ICT has to be prevented.

Here is an example of the requested mechanism in a top down engineering.
The disconnector switch locking information is represented in our data model by a CSWI0.Pos of a specific LD (LDCMDSA1). In some cases, the disconnector locking can be controlled, and in other cases, it is not controllable.
We use the ctlModel to express the two use cases : 3::direct-with-enhanced-security when the disconnector locking can be controlled, and 0::status-only if not.
LDCMDSA1 CSWI0 Pos DPC ctlModel CtlModelKind03 Enum 0::status-only|3::direct-with-enhanced-security

At the ICD level, valImport should be true, to allow SCT to choose ctlModel = 0 or 3.
The SCT will select and put the appropriate value in the SCD, depending on the instantiated project.
We require to have a mechanism that allow the SCT to prevent further modification of the ctlModel in the ICT after importing the SCD for configuration of the IED.
As discussed, valImport is not appropriate for this need, that’s why we requested a new mechanism (equivalent to setToRO service for valKind).

This use case can be extended to all configuration datas modified in the SCT and which should not be modified in the ICT.

Conclusion of today's meeting is that we have to discuss with Part 6 Editor on how to handle the issue.
TF leader of 80-7 is not sure if this is in scope of System management work thus, we need additional evaluation and discussion.