← All Posts

DNP3 Select-Before-Operate (SBO): Safe Control Outputs

DNP3 carries commands that trip breakers, start pumps, and drive analog setpoints across hundreds of remote sites over noisy links. A single corrupted, duplicated, or misrouted command message could energize the wrong feeder or overflow the wrong tank. Select-Before-Operate (SBO) is DNP3's structural defense against that: a two-step handshake that makes a critical control much harder to fire by accident.

This guide explains how SBO works, when to use it instead of Direct Operate, and how the select timeout protects against stale commands. For where controls fit in the wider DNP3 model, see class polling.

The Two-Step Handshake

  1. Select. The master sends a Select message naming the control point and the intended value (e.g. Binary Output 3 → LATCH_ON). The outstation acknowledges the Select but performs no action. The point is now "armed" for a short window.
  2. Operate. The master sends an Operate message for the same point with the same value, within the select timeout. The outstation verifies the match and only then executes the control.
Why two steps? A stray Operate on its own does nothing. There is no matching armed Select. A duplicated or delayed Operate arriving after the select timeout is rejected. The operator (or master logic) effectively confirms the command twice, in two separate messages.

Direct Operate: the One-Shot Alternative

DNP3 also defines Direct Operate, where select and operate happen in a single message. It is faster and simpler but offers none of SBO's guards. Use Direct Operate only for non-critical points where an erroneous command has no safety consequence: an indicator lamp, a logging enable. Anything that moves a breaker, a valve, or a drive gets SBO.

The Select Timeout

Each armed Select has a configurable select timeout (commonly a few seconds). If the matching Operate does not arrive within the window, the outstation cancels the Select and any subsequent Operate is rejected. This is the anti-replay mechanism: a delayed Operate cannot act on a stale, forgotten Select.

Binary vs Analog Controls

SBO applies to both control object types:

Confirmation and Status

After an Operate executes, the resulting point-state change generates an event in the normal class event stream (see class polling). The master therefore sees confirmation of the control through the same mechanism it sees every other change: the point value moves, an event is queued, and the next class poll returns it.

Testing Controls Safely

Never exercise SBO against a live device until you have run it against a simulator. The pattern to validate: Select returns success, an Operate with a mismatched value is rejected, an Operate after the select timeout is rejected, and a correct Operate within the window changes the point. MacTools DNP3 Explorer issues Direct Operate and SBO on macOS, with a method switch in its control dialog, and pairs with the built-in outstation simulator so you can prove all four cases safely before pointing controls at real equipment.

Run DNP3 Controls on macOS

MacTools DNP3 Explorer: Direct Operate and Select-Before-Operate on BO/AO points, with a built-in outstation simulator for safe testing. Native macOS app.

Get MacTools DNP3 Explorer

Related: Utility SCADA

Voltrus SCADA runs DNP3 controls in production with operator confirmation, audit logging, and role-based permissions. Free open source core.

Further Reading