ICCP Device Control: SBO Select and Operate Explained

Device control is where ICCP stops being a data feed and becomes an operational tool — and a liability if misunderstood. Conformance block 5 lets one control center trip breakers, raise taps, and write setpoints in another organization’s network. The protocol wraps that power in the select-before-operate pattern every operations engineer knows from local SCADA, adapted for the peculiar situation of two companies sharing a device.

This article walks the complete control cycle as it actually executes — every check the server runs, every error code it can return, and the one piece of the design that the current standards quietly broke. Verified against IEC 60870-6-503 and IEC 60870-6-802.

Two device classes, one write

Every controllable point is a Device object wrapping a ControlPoint — a command (16-bit, with fixed semantics: trip/close, open/close, off/on, lower/raise) or a setpoint (real or discrete). The device is either non-SBO, operated directly with a single write, or SBO, requiring the two-step arm-then-fire cycle.

Non-SBO has its place: setpoints that get adjusted continuously, devices where the consequence of error is low. For switching primary plant across an organizational boundary, SBO is the norm, and the bilateral agreement typically mandates it. The rest of this article follows the SBO cycle; a non-SBO operate is simply its second half.

The cycle, step by step

An SBO device lives in one of two states: IDLE or ARMED. Here’s what happens between them.

Step 1 — Select

The client selects by issuing an MMS Read of a dedicated variable named <Device_Name>_SBO. Yes, a read arms the device — the wire-level surprise covered in the Wireshark guide. Before answering, the server runs four checks in sequence, each with its own error code:

Does the device exist? If not: OBJECT-NON-EXISTENT. Is Select granted to this client in the bilateral table? If not: OBJECT-ACCESS-DENIED. Is the device actually available? The standard explicitly allows this check to reach through to the local system — the server may have to query an RTU to find out. Unavailable or inoperable: HARDWARE-FAULT. Is the device already ARMED, busy with another operation, or tagged OPEN-AND-CLOSE-INHIBIT? TEMPORARILY-UNAVAILABLE.

All four failures come back as a positive MMS Read response carrying a FAILURE access result — the request worked, the selection didn’t. Distinguish those in client code and in captures.

If everything passes, two things happen at once. The device transitions to ARMED and its timer starts, loaded with the Timeout attribute value. And the response delivers the CheckBackID — the value fixed in the bilateral table for this device (6-802 calls the attribute CheckBackName; same 16-bit value). What the client does with it is formally a local matter; what it should do is compare it against the expected value for the device the operator thinks they’re arming, and refuse to proceed on mismatch. That comparison is the entire point of the mechanism: it catches point-mapping errors — the wrong breaker armed because two configurations disagree — before anything moves.

Step 2 — Operate, inside the window

The client operates by writing the Command (or setpoint) value to the device variable. The write cancels the selection timer. The server verifies the device exists, the client has Operate permission, and — the check that matters in multi-client reality — that the device is ARMED and was selected by this requesting client. A device armed by a different control center returns TEMPORARILY-UNAVAILABLE, same as not-armed or busy. One center cannot fire another center’s selection.

Tag rules are enforced here too, with precise semantics: NO-TAG never blocks, OPEN-AND-CLOSE-INHIBIT always blocks, and CLOSE-ONLY-INHIBIT blocks close and raise commands while allowing open and lower. That asymmetry is deliberate — a tagged device can still be opened to make things safer, never closed onto a working crew.

If the client waits too long, the timer expires first: the device drops back to IDLE, the Timeout action fires, and the eventual write fails. The window is the Timeout attribute agreed per device — long enough for a deliberate operator confirmation, short enough that a stale selection can’t linger.

Step 3 — What the write response actually means

Here the standard is unusually careful, and worth quoting in spirit: the server forwards the command to whatever actually controls the real device, waits for the outcome, and then responds — but a positive write response indicates only that the device received the command, not that it executed successfully. If the device fails to complete the command, the response carries a FAILURE access result with HARDWARE-FAULT, and the server performs the Failure action; on success, the Success action. And at any point in the whole cycle, an emergency pre-emption by the server or any intermediate system triggers the Local Reset action, dumping the device back to IDLE.

Which raises the obvious question: where do those actions — Success, Failure, Timeout, Local Reset — actually go?

The feedback gap

The standard’s answer is MMS event conditions. Each action maps to a named event condition — <device_name>_success, <device_name>_fail, <device_name>_time, <device_name>_reset — whose transitions generate MMS event notifications to enrolled clients.

The problem: the current functional profile excludes the entire MMS event management service set, and the conformance blocks that carried event enrollment were removed from scope. A conforming modern implementation cannot send the event notifications the device model’s actions are mapped to. The standardized feedback channel for command outcome is, in the current editions, a dead letter — one of the loose threads left by the block removals discussed in the conformance blocks article.

Practice routed around it long ago, and the workaround is better than the original design anyway: feedback flows through the associated indication point. Every controlled device has a status point; the commanded breaker’s new position arrives in the next transfer report, quality flags and timestamp included. The CIM bilateral table model even formalizes the linkage — each control point carries an association to the indication point expected to change when it operates.

So the complete, observable control sequence is: Read (CheckBackID) → Write (command) → transfer report (new state). Client applications and operator displays should be built on that third packet, not on the write response — and commissioning tests should verify the control-to-indication mapping explicitly, because it’s exactly the kind of cross-reference two independently maintained configurations get wrong.

Tagging: inter-center work protection

The tag operations complete the model. Set Tag Value writes one of three levels — NO-TAG, OPEN-AND-CLOSE-INHIBIT, CLOSE-ONLY-INHIBIT — together with a free-text Reason up to 255 characters (“close inhibited — line crew on section 12”). Get Tag Value reads it back, and the tag can also travel continuously by including the device’s Tag_Value object in a data set, which is how a remote center’s wallboard stays current without polling.

Three enforcement rules worth knowing. Setting a tag on a device that’s ARMED or mid-operation fails with TEMPORARILY-UNAVAILABLE — you can’t tag around an in-flight command. A device with no tag attribute rejects the operation outright (OBJECT-NON-EXISTENT). And for VCC-scope devices, ownership applies: once a client sets any tag other than NO-TAG, only that client may modify it. The center that placed the protection removes it — the same discipline as physical tags on a panel, encoded in the protocol.

Designing block 5 into an agreement

Block 5 is where bilateral agreements deserve their most conservative drafting, and the model gives you the levers.

Grant Operate on the minimum device set. Grant Select, Operate, and Set Tag independently per device — the access list distinguishes them, so use that granularity.

Fix a CheckBackID per device, and put the verify-on-select behavior in the client’s acceptance tests, not just in the agreement text. Choose timeouts deliberately per device class.

Decide the tagging policy up front: who may tag what, and whether the remote center’s tags are advisory or enforced.

Finally, specify the feedback contract explicitly — which indication point confirms each device, and how long after Operate the client waits before declaring the command failed. That last number exists in every control room’s procedures anyway; writing it into the agreement makes both ends implement the same one.

FAQ