IEC 61850 User Feedback Task Force

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 ?