I would like to confirm how the client knows the reason why device selection is failed. With regard of Part 7-2 sheet 145, Figure 35 is described successful case of control. But there is no explanation for failed case.
My understanding is that SelVal_rsp(-) with addCause will be replied when selection is failed. In this case, addCause will be set “Select-failed”, “Blocked by switching hierarchy” or “Block by Interlock” etc. But they might need to be retrieved from Operated device (outside of Control Object). It means that they need long time to be retrieved. I think that the delayed SelVal_rsp(+/-) is not preferable for client. If Control Object would reply soon without such addCauses, the client cannot know the reason why the selection is failed. (The client can know the success with “stSeld”)
Proposal
My proposal is that the new variable, for example “errorCode”, should be defined at Control Object, which is symmetry of“stSeld” and includes fail reason. When Control Object receives SelVal_req,
1) the server send SelVal_rsp(+) soon. After that, Control Object starts to select Operated Devices.
2.1) When the select is success, a report including “stSeld” may be sent to the client.
2.2) When the select is failed, a report including “errorCode” may be sent to the client.
Discussion
Created
Status
17 Feb 07
In Force (green)
Editor meeting December 2006 - Livonia.
There is no need to change the way it has been defined since the model is already working properly. The proposed model does not offer any new feature.