All articles
All articles

IEC 61850 Control Models: Direct, SBO, and Enhanced Security

IEC 61850 control models explained: all five ctlModel values, what enhanced security really means, the Select-Operate flow, and what happens after Operate.

7 min · 1,444 words

Key takeaways

  • IEC 61850 control models explained: all five ctlModel values, what enhanced security really means, the Select-Operate flow, and what happens after Operate.
  • Focus protocol: IEC-61850 — see the reference page for frame format, OSI layer, and port/ethertype details.
  • Related topics: IEC 61850, Control Models, SBO, Direct Operate.
  • Read time: 7 · 1,444 words · published .

IEC 61850 doesn't treat a control command as a plain write. It defines control models that set three things: how a command is issued, who is allowed to issue it, and how the result is confirmed. Choose the wrong model and you either give up safety or give up the confirmation you actually needed.

This guide covers the models that matter in practice — Direct Operate, Select-Before-Operate (SBO), and the enhanced-security variants — and clears up the two things most write-ups get wrong: what "enhanced security" really means, and what happens to a selection after a successful Operate.

What the control model applies to

The control model only works on controllable data objects. Those are instances of a controllable common data class (CDC) whose ctlModel attribute is set to something other than status-only. If ctlModel is status-only, the object can be read but not commanded.

ctlModel lives inside the data object and tells the server which model to run. Typical control points:

  • CSWI.Pos — switch controller (the point an operator usually commands)
  • XCBR.Pos — circuit breaker position
  • ATCC.TapChg — tap changer control

The model uses a small set of services: Select and SelectWithValue, Cancel, Operate (plus TimeActivatedOperate for timed commands), and CommandTermination.

The five values of ctlModel

There aren't three control models — there are four that can command, plus status-only. And the two design choices are independent:

  • Direct vs SBO — is there a select step before the operate?
  • Normal vs enhanced security — is the result confirmed with a CommandTermination?
ctlModel valueModelSelect stepCommandTermination
status-onlyno control
direct-with-normal-securityDirect Operatenoneno
sbo-with-normal-securitySBOSelectno
direct-with-enhanced-securityDirect Operatenoneyes
sbo-with-enhanced-securitySBOSelectWithValueyes

The key point people miss: enhanced security is not tied to SBO. You can run Direct Operate with enhanced security — a one-step command that still ends with a CommandTermination.

Normal vs enhanced security — the real difference

This is where most explanations go wrong, so it's worth being exact.

Enhanced security is not a cybersecurity feature. It does nothing against replay, spoofing, or an attacker on the wire. That job belongs to IEC 62351 (and TLS for the MMS mapping). In the control model, enhanced security means one thing: the control object adds supervision of the status value, and it ends every command sequence with a CommandTermination.

With normal security, the Operate response is the end of the exchange. The server replies "accepted," acts, and you learn the new position from an ordinary report or by reading the status. Nothing tells you the physical action itself finished.

With enhanced security, after the positive Operate response the object watches the real status. When it reaches the commanded state, it sends CommandTermination(+). If the action fails or times out, it sends CommandTermination(−) with an AddCause code that tells you why. So you get end-to-end confirmation that the breaker actually moved — not just that the command was accepted.

Two timers, and they are not the same:

  • sboTimeout — how long a selection is held. It's the window between Select and Operate.
  • operTimeout — how long the object waits for the physical action to complete before it declares failure. This is what drives the negative CommandTermination in enhanced security.

Direct Operate

One step. The client sends Operate, the object runs its checks — interlocks, mode, blocking — and if they pass, it acts and returns a positive response. No selection, no reservation.

It's fast and light, which is why it fits local or low-risk points: a lamp test, a heater, non-interlocked auxiliary control. It's the wrong choice for breakers or interlocked switching, where you want a deliberate two-step action. With enhanced security added, Direct Operate still gives you a CommandTermination, so you know the action completed.

Select-Before-Operate (SBO)

Two steps, and this is the workhorse for switching.

First the Select (normal security) or SelectWithValue (enhanced security). The object checks whether control is allowed, whether the point is free, and whether interlocks are satisfied. If everything passes, it moves to Ready and reserves itself for that one client.

Then the Operate. The object confirms it's the same client, that the selection hasn't timed out, runs its operative and dynamic tests (interlock, synchrocheck), and acts.

While the point is selected, no other client can select or operate it. That exclusivity is the whole reason SBO exists.

Select-Before-Operate (SBO)
Select-Before-Operate (SBO)

What happens after a successful Operate

Here's the detail that trips people up — and the answer to the common "does the IED deselect itself?" question. It depends on the sboClass setting:

  • operate-once — after the Operate completes, the object returns to Unselected on its own. The selection is consumed. To command again, you send a new Select.
  • operate-many — the object goes back to Ready, still selected by the same client. You can Operate again without re-selecting, until sboTimeout expires or you send Cancel.

Either way, the client sends nothing to "deselect." There is no Deselect service in IEC 61850. The only explicit release is Cancel, and Cancel is for abandoning a selection before you operate. After a successful operate-once, there's nothing left to cancel.

SBO with two clients

Exclusivity is automatic — there's no special HMI setting for it. The first client to receive a positive Select owns the point. While that client holds the selection, any Select or Operate from a second client gets a negative response (locked-by-other-client).

The lock clears in exactly three ways: the first client operates (with operate-once), sends a Cancel, or lets the selection expire on sboTimeout. Only then can the second client select.

Where each model fits

  • Direct, normal security — local tests and non-critical auxiliaries.
  • SBO, normal security — routine switching where you want the deliberate select step but don't need execution confirmation.
  • Enhanced security (direct or SBO) — anywhere you need to know the action actually completed: critical breakers, protection-related control, automated device-to-device control.

Vendor support for enhanced security varies. Confirm it in the IED's PICS/PIXIT before you design around it.

ctlModel and the logical nodes

Control models sit inside the logical nodes that own the controllable object. CSWI handles switch control, XCBR and XSWI are the physical breaker and switch, and CILO carries the interlocking logic that the operative test checks against.

ctlModel is a configuration attribute (functional constraint CF). It's usually fixed in the SCL and read at runtime, though some stacks allow online reconfiguration. A full reference looks like CSWI1.Pos.ctlModel.

New in the 2020 amendment

The current release is IEC 61850-7-2:2010+AMD1:2020 (Edition 2.1). The control models themselves didn't change. The amendment added service tracking for control blocks — the ability to monitor control-service invocations, so you can see which client selected or operated which point. It's useful for auditing and troubleshooting a sequence after the fact.

Common engineering mistakes

  • Using Direct Operate on breakers or interlocked switching.
  • Treating enhanced security as a security control. It's outcome supervision, not protection against an attacker.
  • Ignoring sboClass and assuming the point deselects (or stays selected) when it does the opposite.
  • Confusing sboTimeout with operTimeout.
  • Not matching the client/HMI behavior to the point's ctlModel.
  • Assuming every vendor behaves identically — test the full sequence at commissioning.

FAQ

Does the IED deselect itself after a successful Operate?

With operate-once, yes — it returns to Unselected automatically. With operate-many, it stays in Ready so the same client can operate again, until sboTimeout expires or a Cancel is sent.

Is there a Deselect command in IEC 61850?

No. The only explicit way a client releases a selection is the Cancel service, and that's for abandoning a selection before the Operate.

What's the difference between SBOns and SBOes?

Normal security (SBOns) ends at the Operate response. Enhanced security (SBOes) adds status supervision and a CommandTermination — positive when the action completes, negative with an AddCause when it fails.

Does enhanced security protect against cyberattacks?

No. Authentication, integrity, and replay protection come from IEC 62351 and TLS. Enhanced security only confirms the physical result of a command.

How does one client get exclusive control of a breaker?

By being the first to receive a positive Select. The object locks to that client; every other client gets locked-by-other-client until the lock clears.

What does sboTimeout control?

The maximum time a selection is held between Select and Operate. Miss that window and the object drops back to Unselected, and you have to select again.

Related articles