Project

General

Profile

IEC61850-7-5 #6408

Clarification of addCause

Added by Vladan Cvejic over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Start date:
05/21/2021
Due date:
11/21/2021 (over 3 years late)
% Done:

0%

Source:
Category:
Not yet categorized
TF 7-5 Project document:
Related TISSUE:

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 ?


Related issues

Copied from IEC 61850 User Feedback Task Force - Support #676: Clarification of addCauseResolved05/21/202111/21/2021

Actions
#1

Updated by Vladan Cvejic over 1 year ago

Also available in: Atom PDF