Project

General

Profile

Support #676

Clarification of addCause

Added by Maud Merley almost 3 years ago. Updated 12 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Standard clarification required
Start date:
05/21/2021
Due date:
11/21/2021 (over 2 years late)
% Done:

0%

Estimated time:
ID:
49
Source:
RTE
TF Unique ID:
49 # RTE
WG10 Proposal:
Estimated Completion:
Discuss in Upcoming Meeting:
No
To discuss in WG10:
No
Short Proposal:
Standard(s):

IEC 61850-7-5

Needs More Information:
No
Assigned TF:

Description

1. The standard identifies addCause, but its use should be explicitly defined by requirements associated to the application. The use and the expected behavior may be different for CB or disconnectors and also depend on other criteria.
example: "invalidPosition": depending on the object, a rejection of the command may be wished for a disconnector, but not for an opening command of a CB.

2. Besides, some cases has to be clarified:
25 "none" : why is this addCause necessary, normally they are associated at a refusal. Clarify use?
23 "abortion by communication loss": this addCause cannot be sent in case of loss of communication. Clarify use. Log?
26 "inconsistent parameter" conform if used for test of parameters of command or for sequence number of command (cybersecurity)
20 "non access authority" -> which are the associated controls?
=> Associated controls need to be explicitly specified for each addCause for interoperability reasons. Specially important for 20 and 26.

3. At least, how to access to addCause for other functions than the client and server concerned. Proposal : creation of attribute ENUM associated to addCause ?


Proposal descriptions

1. The standard identifies addCause, but its use should be explicitly defined by requirements associated to the application. The use and the expected behavior may be different for CB or disconnectors and also depend on other criteria.
example: "invalidPosition": depending on the object, a rejection of the command may be wished for a disconnector, but not for an opening command of a CB.

2. Besides, some cases has to be clarified:
25 "none" : why is this addCause necessary, normally they are associated at a refusal. Clarify use?
23 "abortion by communication loss": this addCause cannot be sent in case of loss of communication. Clarify use. Log?
26 "inconsistent parameter" conform if used for test of parameters of command or for sequence number of command (cybersecurity)
20 "non access authority" -> which are the associated controls?
=> Associated controls need to be explicitly specified for each addCause for interoperability reasons. Specially important for 20 and 26.

Which addCause to use for cb blocked due to low SF6 pressure?
Is it expected to use addCause "Blocked by Process" (9) or "Blocked-by-Command" (24)?
The semantic of 24 implies a user operation, but is attached to CmdBlk. In the description of the use of CmdBlk, one can understand that the command could also be blocked by a signal (not necessarily user). It would be advantageous to clarify this point.
Proposal:
- use of addCause 24 only for blocking by operator and cause 9 for blocking related to signals form process.
- indicate that CmdBlk could also be associated to add cause 9

3. At least, how to access to addCause for other functions than the client and server concerned. Proposal : creation of attribute ENUM associated to addCause ?


Related issues

Copied to 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6408: Clarification of addCauseNew05/21/202111/21/2021

Actions

Also available in: Atom PDF