Project

General

Profile

Support #624

Clarification of using of ValKind, ValImport.

Added by Carlos Rodriguez del Castillo over 3 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Category:
Standard clarification required
Start date:
11/24/2020
Due date:
11/24/2022 (about 19 months late)
% Done:

0%

Estimated time:
ID:
21
Source:
RTE
TF Unique ID:
21 # RTE
WG10 Proposal:
Estimated Completion:
Discuss in Upcoming Meeting:
No
To discuss in WG10:
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.

Standard(s):

IEC 61850-6

Needs More Information:
No
Assigned TF:

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.


Related issues

Copied to IEC TC57 WG10 Future Work - WG10 Future Work #6316: Clarification of using of ValKind, ValImport.NewCarlos Rodriguez del Castillo11/24/2020

Actions
#1

Updated by Carlos Rodriguez del Castillo over 3 years ago

  • 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

#2

Updated by Carlos Rodriguez del Castillo over 3 years ago

  • Status changed from Feedback to Triage
#3

Updated by Carlos Rodriguez del Castillo over 3 years ago

  • 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.

#4

Updated by Maud Merley almost 2 years ago

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.

#5

Updated by Vladan Cvejic over 1 year ago

  • 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.

#6

Updated by Vladan Cvejic over 1 year ago

  • Discuss in Upcoming Meeting changed from No to Yes
#7

Updated by Carlos Rodriguez del Castillo over 1 year ago

  • Needs More Information set to Yes
#8

Updated by Maud Merley over 1 year ago

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.

#9

Updated by Carlos Rodriguez del Castillo over 1 year ago

  • 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.

#10

Updated by Carlos Rodriguez del Castillo over 1 year ago

  • Discuss in Upcoming Meeting changed from Yes to No
#11

Updated by Carlos Rodriguez del Castillo over 1 year ago

  • Discuss in Upcoming Meeting changed from No to Yes
#12

Updated by Vladan Cvejic over 1 year ago

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.

#13

Updated by Carlos Rodriguez del Castillo about 1 year ago

  • 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.

#14

Updated by Vladan Cvejic about 1 year ago

Also available in: Atom PDF