With select before operate (SBO), the client first selects the device and waits for confirmation, then sends the execute command within a time limit. It prevents a corrupted message or a command to the wrong object from operating a device. IEC 61850 offers it with normal or enhanced security, IEC 60870-5-104 with its select/execute qualifier, and DNP3 with the Select and Operate function codes.
Why a command is given in two steps
A close command that reaches the wrong breaker, or that is generated by a corrupted message, can energize a section with people working on it. Select before operate (SBO) reduces that risk by splitting the command in two steps: first the client selects the device and the server confirms it has reserved it for that client; then the client sends the execute, which is accepted only if it matches the selection and arrives within a time limit.
Direct operate does the same in a single message. It is faster and simpler, and it is used for lower-risk objects or on links where message integrity is guaranteed by other means.
How it works in IEC 61850
IEC 61850-7-2 defines four control models, configured per object:
| Model | Steps | Result supervision |
|---|---|---|
| Direct with normal security | Operate | No |
| SBO with normal security | Select and operate | No |
| Direct with enhanced security | Operate | Yes, with a final message |
| SBO with enhanced security | Select with value and operate | Yes, with a final message |
In the enhanced variant, the selection is made with SelectWithValue, which already carries the requested value (close or open). While the object is selected, only the client that selected it can execute or cancel it. After the execute, the server supervises the change of state of the device and sends CommandTermination with the result: positive if the device reached the requested position, negative with its cause if not.
- 01SelectThe client sends SelectWithValue with the requested value
- 02CheckThe controller checks control authority and, if the command asks for it, interlocking and synchronism
- 03Select responsePositive, or negative with the additional cause
- 04OperateThe client sends Operate within the select timeout
- 05Response and operationThe controller accepts the command and the device operates
- 06TerminationCommandTermination reports whether the device reached the requested position
The command also carries the Check parameter, which tells the controller whether to evaluate the interlock (CILO) and the synchronism check (RSYN) before executing. If it is configured without those checks, the controller executes even if the interlock is not satisfied. Each negative response carries an additional cause (AddCause) that says what failed: selection timed out, object already selected, blocked by interlocking, control authority at another level, among others.
How it works in IEC 60870-5-104 and DNP3
IEC 60870-5-104. Commands (single, double, regulating step) carry a qualifier that indicates whether the message is a select or an execute. The control center sends the select with cause “activation”, receives the activation confirmation and then sends the execute. The cycle is closed in the cause of transmission: activation, activation confirmation and activation termination.
DNP3 (IEEE 1815). The select uses function code 3 (Select) and the execute function code 4 (Operate), with a maximum time between them. Direct operate uses function code 5, and function code 6 is direct operate without acknowledgment.
Select timeout and cancel
Every selection has a lifetime. If the execute does not arrive within that time, the server releases the object and a later execute is rejected. The client can also cancel the selection. When the command goes through a gateway that translates protocols, each leg has its own timer, and they must be consistent: if the control center waits longer than the controller holds the selection, the command is lost even though each leg works correctly on its own.
Relation with interlocking and synchronism
SBO does not replace interlocking: it brings it forward. In many controllers, the interlock and control authority checks already take place at the select, so the operator gets the rejection before executing. The synchronism check, on the other hand, is usually evaluated at the execute, because angle and frequency conditions change within seconds. A close with synchronism check 25 can be accepted at the select and rejected, or put on hold, at the execute.
- Was the select rejected?
- YesCheck control authority, interlocking, object already selected by another client, or a control model different from the one expected
- NoWas the execute rejected?
- YesCheck for selection timeout, a value different from the one selected, and conditions that changed between the two steps, such as synchronism
- NoDid a negative termination arrive, or none at all?
- YesThe device did not reach the position: check the mechanism, the drive and the reported position
- NoCommand completed
What goes wrong in practice
- Different control model between client and server: the client sends a direct operate to an object configured for SBO.
- Inconsistent select timeouts between control center, gateway and controller.
- Gateway that does not pass on the termination, so the control center does not know whether the operation finished.
- Check parameter without interlocking in the client configuration.
- Two clients (local HMI and control center) trying to select the same object.
How it is verified
During integration, each control object is tested from each client with its control model: select, execute, cancel, select timeout, and rejection by interlocking, by control authority and by synchronism. The test confirms that each rejection reaches the operator with its cause and that the termination reaches the control center.
Are your remote commands rejected, or does the gateway translate select before operate incorrectly? At Tiza Group we configure the commands between controllers, gateways and control centers with IEC 61850, IEC 60870-5-104 and DNP3 remotely through our remote relay configuration service, and we test them on site in Colombia, or elsewhere on request. Contact us with your project details.
Related guides
- Synchronism check 25 (RSYN): what it is and how it works
- Breaker closing permissives: what blocks the close
- Substation interlocking: types, levels and logic
- Mapping IEC 61850 to IEC 104 and DNP3 in the gateway
- IEC 61850 to the control center: TR 61850-90-2
References
- IEC 61850-7-2, Abstract communication service interface (ACSI) (control models, SelectWithValue, Operate, Cancel, CommandTermination).
- IEC 61850-8-1, Specific communication service mapping (SCSM) – Mappings to MMS.
- IEC 60870-5-104, Transmission protocols – Network access for IEC 60870-5-101 using standard transport profiles.
- IEEE 1815, Standard for Electric Power Systems Communications – Distributed Network Protocol (DNP3).
Frequently asked questions
Why is the execute rejected after an accepted select?
The usual causes are that the selection timed out before the execute, that the execute does not match what was selected (another object or another value), that another client already had the device selected, or that a condition changed between the two steps, for example an interlock or the local/remote switch.
What does enhanced security add in IEC 61850?
The server also supervises that the device really changes state and sends the client a final message, CommandTermination, with the result. The client then knows whether the operation completed or failed, not just whether the command was accepted.
Can SBO and direct operate be mixed in the same substation?
Yes, the control model is configured per object. What matters is that the control center, the gateway and the controller expect the same model; if the gateway receives SBO and translates it into a direct operate, or the other way round, rejections or timeouts appear.