Clarification of addCause
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 ?