DNP3 Direct Operate vs Select-Before-Operate

Back to Blog

One-Pass Versus Two-Pass Control

Direct operate is the simple path. The master sends a single direct-operate request carrying the control object - a CROB for a binary output or an analog output block for a setpoint - and the outstation acts on it and replies. One request, one response, minimum latency. It is the efficient choice when the command is low-risk and the cost of an occasional misfire is small.

Select-before-operate splits the command into two. First the master sends a select naming the point and action; the outstation validates it, arms that point, and echoes the exact request back. The master compares the echo to what it sent, and only if they match does it send an operate to fire the armed point. The full mechanics of this handshake are covered under select-before-operate. The echo is the safety feature: if the outstation understood a different point or action, the mismatch stops the master before anything moves.

What the Extra Step Buys, and When to Use It

The value of the select step is a chance to catch an error before an output actuates. If a command is corrupted in a way that survives the CRC, or if addressing sends it to the wrong point, the select echo lets the master notice the discrepancy and abort. There is also a select timeout: the armed point disarms itself if the operate does not arrive promptly, so a stale select cannot fire much later. For a control that opens a breaker or a large valve, that verification is worth the extra round-trip.

The rule that falls out is straightforward and shown in the table below: use select-before-operate for consequential controls where a wrong actuation is dangerous or expensive, and direct operate where speed matters and the risk is low. Many systems mix the two, choosing per point. The choice is recorded in the point map and, on the outstation side, constrained by what its device profile supports.

Choosing Between Them

This table pairs each method with the situation it fits.

Aspect	Direct operate	Select-before-operate
Round-trips	One request	Select, then operate
Verification	None before actuation	Outstation echoes select for the master to check
Guards against	Little beyond CRC	Misdirected or corrupted command, stale command via timeout
Latency	Lowest	Higher, by one round-trip
Best for	Low-risk, speed-sensitive outputs	Breakers, large valves, consequential controls

The Third Variant: Direct Operate, No Acknowledge

The comparison is usually framed as two methods, but the standard actually defines a third. Alongside select (function code 3), operate (4), and direct operate (5), there is direct operate with no acknowledge (function code 6), which commands the output without even an application-layer response coming back. It exists for cases where a reply is impractical - broadcast commands sent to many outstations at once, or a setpoint repeated on a schedule where the next transmission supersedes the last. The full list of request types is covered in the DNP3 function code reference.

The no-acknowledge variant gives up the last shred of confirmation: the master does not learn whether the command was even received. That is only tolerable when the commanded value is refreshed continuously and a monitored feedback point closes the loop. In fact, command-then-verify is good practice for every method on this page - even a fully confirmed select-before-operate sequence proves only that the outstation accepted the command, not that the breaker or valve physically moved, so the master should watch the mapped status point after any operate and alarm if it does not change.

Reading the Status Byte in the Response

Every select and operate response carries a status value for each control object, and it is the first thing to read when a command misbehaves. The standard defines the meanings: success means the request was accepted; a timeout status on an operate means the select had already expired; a no-select status means the operate arrived with nothing armed; other defined values indicate a format error between select and operate, a point that does not support the requested method, a control already in progress, a hardware fault, or a point switched to local control. The same status mechanism applies whether the object is a CROB or an analog output block.

Two of these deserve interpretation. A no-select status says the sequencing is broken - the select never arrived, was rejected, or the outstation restarted between the two passes. A timeout status says the pair was correct but too slow, which points at the link latency or at the outstation's configured select timeout. That timeout is an outstation setting documented in its device profile and is site-specific; when it expires, the right recovery is to start over with a fresh select, never to blindly resend the operate.

Proving the Control Path at Commissioning

Control points deserve a deliberate test pass before anyone trusts them from a control room. A sequence that catches most surprises:

1. Confirm in the outstation's documentation which methods each point supports, and record the chosen method per point in the point map.
2. With the process isolated under the site's permit and isolation procedures, exercise each consequential point end to end and watch the physical device respond.
3. Force a select timeout by delaying the operate, and confirm the point disarms and returns the timeout status rather than actuating.
4. Send an operate with no preceding select and confirm it is rejected with a no-select status.
5. Verify the feedback point for every command changes state, and that the master alarms when the feedback does not arrive.

Repeat the relevant parts of this pass after outstation firmware changes or point map edits, since both can silently change control behavior. And keep the boundary clear: trip and interlock functions that protect people or equipment belong to the safety system, not the SCADA command path, and their validation is the domain of qualified personnel following site procedures.

Frequently Asked Questions