Support #624
Clarification of using of ValKind, ValImport.
Added by Carlos Rodriguez del Castillo almost 4 years ago.
Updated over 1 year ago.
Category:
Standard clarification required
Due date:
11/24/2022 (over 2 years late)
Discuss in Upcoming Meeting:
No
Short Proposal:
valImport is being used today for exactly the opposite one, to prevent RTE provide more detailed information and we will take a look on itICT to accept modified values from outside tools.
Needs More Information:
No
Description
Clarification of using of ValKind, ValImport.
Details: In order to do top-down engineering, we propose to add the possibility, in SCT, to modifiy ValImport from true to false, and that ValImport can't be modified by ICT after.
Arguments: The objective is to be able to manage engineering from the SCT.
Proposal descriptions
Create a new attribute to indicate when the ICT is forbidden to modify a specific data attribute.
Move the issue to FutureImprovement database.
- Status changed from New to Feedback
- Short Proposal set to valImport is being used today for exactly the opposite one, to prevent RTE provide more detailed information and we will take a look on itICT to accept modified values from outside tools.
During meeting:
valImport is being used today for exactly the opposite one
RTE provide more detailed information and we will take a look on it
- Status changed from Feedback to Triage
- Due date set to 05/24/2021
- Assignee set to Carlos Rodriguez del Castillo
- Discuss in Upcoming Meeting changed from Yes to No
- To discuss in WG10 set to No
2021-03-02: RTE to provide the explanation or close the issue.
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.
- Due date changed from 05/24/2021 to 11/24/2022
Clarification for the request needed:
For which parameter is this used? Real life use-case is needed.
- Discuss in Upcoming Meeting changed from No to Yes
- Needs More Information set to Yes
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.
- Status changed from Triage to In Progress
This issue to be discussed by TF System Management (61850-80-7) to create appropiate input to IEC 61850-6 Ed3.
- Discuss in Upcoming Meeting changed from Yes to No
- Discuss in Upcoming Meeting changed from No to Yes
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.
- Status changed from In Progress to Resolved
- Discuss in Upcoming Meeting changed from Yes to No
- Proposal descriptions updated (diff)
- Needs More Information changed from Yes to No
We need another attribute to indicate the ICT is forbidden to modify an attribute, because valImport is not valid for the use case.
It is not only data objects, it could also be other objects:
- Dataset name
- Dataset content
- Trigger options
- Option Fields
- Control Block Name
(...)
So a generic solution is needed for the SCT to tell the ICT not to modify certains SCL objects.
To be address by IEC 61850-6 future edition.
Move the issue to FutureImprovement database.
Also available in: Atom
PDF