In page 156 it's written:
"The client issues the Operate service which is immediately confirmed by the Operate response."
In page 165 we have an example of SBO with enhanced security (positive and negative case). In each one, we can see the "Oper_resp" is sent immediately.
For each control (DE normal security, SBO normal security, DE enhanced security and SBO enhanced security) we have a sequence diagram. But in each one we have the "Oper_resp+" after the step "WaitForExecution".
According to 20.1, synchrocheck is performed in the state "WaitForExecution".
If this step ("WaitForExecution") is for the dynamic test, in this case we can have the "Oper_resp+" after "TotTmms" (total time of synchronising process) seconds.
If we want to respect the fact that the confirmation of an operate service is sent immediately, we have to modify the location of "Oper_resp+" and move it after the Perform Test.
Moreover, at "WaitForExecution" step, for "Dynamic Test not ok", "Cancel_req" and "Dynamic Test Timeout", it's not more a "Oper_resp-" but a "CmdTerm_req-" we have to put.
Proposal
Move "Oper_resp+" after the Perform Test.
Modify all "Oper_resp-" with "CmdTerm_resp-" for "Dynamic Test not ok", "Cancel_req" and "Dynamic Test Timeout" at "WaitForExecute" step
Discussion
Created
Status
09 Oct 14
Future Improvement
further discussion will occur in the 7-5 TF.
09 Oct 14
Discussion (red)
"The client issues the Operate service which is immediately confirmed by the Operate response." Describes the example of Figure 37 and is not a normative statement.
No change is necessary.
08 Oct 14
Discussion (red)
Yes, a dynamic test can take a long time before coming to a result. 1 h as you mentioned.
But still, a long as there is not a positive dynamic test result, the binary output are not activated.
Oper_resp+ meaning remains binary output have been activated.
Making OR attributes mandatory (which means backward incompatibility) does not help, as a Beh in Blocked will also deliver opRcvd and opOk identically to a Beh on.
The only meaning in 61850 to indicate that the wired outputs have been activated remain oper_resp+.
Client could program a timer including the real TotTmms value, or default TotTmms value.
1)For many customers “TotTmms” (total time of synchronizing process) can be configured up to 1 hour. In this case if we are in the state WaitForExecution and synchrocheck criteria is never fullfilled, client will not receive any “oper_resp” before 1 hour
-> yes, this is correct / intended
2)Data attribute “opRcvd” is optional. So if server doesn’t integrate this data attribute in CDC DPC or SPC, client doesn’t receive any response from server and can consider that an error occurs to the server.
-> why, Client can repreat the oper_req, it will get a neg response: already in execution.
additionally, with a select control model - the attribute stSeld remains true as long as the dynamic test is running.
3) opRcvd is way to know it has been received. Repeating the Oper too.
31 Jul 14
Discussion (red)
In this case we have 3 problems: 1)For many customers “TotTmms” (total time of synchronizing process) can be configured up to 1 hour. In this case if we are in the state WaitForExecution and synchrocheck criteria is never fullfilled, client will not receive any “oper_resp” before 1 hour. 2)Data attribute “opRcvd” is optional. So if server doesn’t integrate this data attribute in CDC DPC or SPC, client doesn’t receive any response from server and can consider that an error occurs to the server. 3)We get no information that the PerformTest has been done.
So to your proposal I would add “set data attribute “opRcvd” as mandatory”.
News proposal: Therefore, I suggest to change the introduction sentence that seem to implicate that a oper_resp is always send immediatly after the reception of the oper_req, as a dynamic test can postpone the oper_resp after the completion of the dynamic test. And set data attribute “opRcvd” as mandatory, to allows “immediate” answer in case of long “WaitForExecution”.
30 Jul 14
Discussion (red)
The definition of the oper_resp + is:
If successful, the control object shall issue a positive response to the requesting client and shall cause the requested action according to the DataObject Beh associated to the parent logical node, for example by changing a state value, activating a binary output, sending
an equivalent signal on a process bus or mirroring the received command without executing it.
Therefore, a oper_resp+ can not be send before the end of the WaitForExecution test.
After an oper_resp + is issued, no cancel can be performed as the operate resquest has been treated.
Therefore, I suggest to change the introduction sentence that seem to implicate that a oper_resp is always send immediatly after the reception of the oper_req, as a dynamic test can postpone the oper_resp after the completion of the dynamic test.