Protocols

IEC 61850 control models: direct versus select-before-operate, and what gets tested

2026-10-29 · 8 min read

Every control in IEC 61850 is described by a control model, and the model decides what a master must do before the device moves anything. Most integration arguments about control are really arguments about which model the device implements — and most control defects at site acceptance come from implementing the right model with the wrong termination semantics.

The models, in operational terms

Ignore the standard text for a moment and think about what an operator has to do:

• Direct with normal security. One write moves the device. Fast, and unforgiving: a mistyped command executes.
• Direct with enhanced security. One write, but the device validates more strictly and reports termination separately. The safety comes from validation, not from a two-step sequence.
• Select before operate, normal security. The operator selects a specific control, the device reserves it, then the operator executes. A second client cannot interleave a command on the same object.
• Select before operate, enhanced security. The same sequence with stricter validation and separate command termination reporting.
• Time-activated variants. The command is scheduled to occur at a specified time rather than immediately, which is what makes synchronised switching possible.

What the master actually does

A well-behaved master, given a select-before-operate object, will select, check the response, then execute — and will cancel the selection if anything in between fails or the operator abandons it. This means your device must support three operations on one object, and must define what happens to a selection that is never executed.

• Selection must time out. An armed control left indefinitely is a safety problem, not a convenience.
• Selection is per client and per object. Two clients selecting the same object must not both succeed.
• Cancel must be honoured even after a failed execute.

Command termination: the detail that fails acceptance

Writing the value is the start of the operation, not the end. The device must report how it ended: the command completed, the command was terminated by the device, or the command failed. A device that only reports "last applied value" leaves the master unable to distinguish "executed" from "accepted then abandoned".

The typical defect: the write returns success, the operator sees success, and the interlock refuses three seconds later. The device did nothing wrong technically and the operator was misled. Report command termination explicitly, and map interlock refusal onto a termination state the master understands.

Origin and test flags

Origin identifies who issued a command — which client, and whether it was a station-level or remote operation. It exists so that the sequence of events record answers "who did this", which is the first question after any unexpected operation.

The test flag lets a command travel through the system without touching the process. Devices that ignore it will happily trip a breaker during a test, which tends to be remembered.

Choosing a model

A pragmatic default that survives most customer conversations:

• Anything that moves primary equipment: select before operate, with a finite selection timeout.
• Setpoints that a human adjusts: direct with enhanced security is usually enough, and the operator experience is better.
• Internal configuration that no operator touches: direct, normal security, and accept that it is not protected.
• If the customer's specification names a model, implement that one and document the behaviour of the others as unsupported rather than approximating them.

The four defects that show up at site acceptance

• Selection never expires, so a stale selection blocks the next operator.
• Execute accepted without a prior selection (or after an expired one).
• Termination never reported, so the master waits for a timeout it should not need.
• Test flag ignored, producing a real operation during commissioning tests.

Questions that come up

Can one device support several control models?

Yes, and most do — the model is a property of each controllable object, declared in its ctlModel attribute. A device with breaker control and setpoint adjustment will legitimately have different models for the two.

What should happen if two masters select the same object?

The second must be refused. That arbitration is the entire point of selection, and a device that allows both has implemented the message sequence without the semantics.

How long should a selection stay armed?

Long enough for an operator to confirm, short enough that an abandoned sequence does not block the object. Whatever you choose, publish it — the value is part of your device's behaviour that a master may need to know.

Keep reading