Control command rejected from SCADA: causes and diagnosis

Short answer

A command that SCADA sends and the device rejects is almost always blocked by a condition in the substation itself: the local/remote selector, an interlock, the synchronism check or the IED mode. If the command works from the local HMI but not from the control center, the problem is in the communications chain: the gateway mapping, the command type or the select-before-operate timing between protocols.

Symptom

The operator sends an open or close command from SCADA and gets a rejection, a timeout, or simply nothing happens. The device is in service, the link seems active and the signals arrive. Sometimes the same command works from the substation HMI or from the front of the bay controller, which makes it even more confusing.

A remote command travels a long chain: control center, telecontrol link, gateway, substation network, bay controller or relay, interlocking logic and, finally, the closing or trip circuit of the device. In the substation SCADA and HMI system each link can reject the order for a legitimate reason. Diagnosis consists of finding which link rejected it and for what cause.

Possible causes, from most to least likely

Cause	Why it happens	What gives it away
Command hierarchy	Bay selector in local, or station level active when commanding from the control center	Rejection for hierarchy; the command works from the enabled level
Interlock	Disconnectors, earthing switch or neighboring breakers in a position that does not allow the operation	Rejection for interlock; false condition in the logic
Synchronism	Voltage, angle or frequency difference outside the setting when closing between two sources	Rejection for synchronism; affects only closing commands
Expired or failed select	The operate arrives after the time limit, or the device was already selected by another client	Select accepted and operate rejected; timeout
IED mode	Device in test mode, blocked or out of service after maintenance	Rejection for mode; other IED functions also in test
Gateway mapping	Object, address or command type different from the control center’s; wrong pulse or latched	Works from the local HMI and not from the control center
Device condition	Lockout relay 86 not reset, discharged springs or SF6 low-density lockout	The IED accepts the order and the device does not move, or the command is rejected by the process

If the rejection arrives at selection and not at operation, the problem is in the select-before-operate (SBO) step. The conditions the controller requires before closing are detailed in breaker closing permissives, and a forgotten interlock bypass explains the opposite case: a command that passes when it should not.

What to check first

Response of the link that rejected. In IEC 61850 MMS, the negative response carries an additional cause (AddCause). In IEC 60870-5-104, the command confirmation carries a positive or negative confirmation bit in the cause of transmission. In DNP3, the response to the command carries a status code. That response usually gives the cause without further searching.
Does it work from the local HMI or from the controller? If it works, the problem is between the control center and the gateway. If not, it is in the bay.
Position of the local/remote selector in the bay and of the station command level.
Interlock signals of the bay at the moment of the command: position of each disconnector, the earthing switch and the associated breakers.
Device alarms: 86, springs, gas. See the breaker does not close.
Gateway logs: object received, conversion to the bay protocol and times between select and operate.

Which link rejected the command

Does the command work from the local HMI or the bay controller?
- No: Does the IED return a rejection cause?
  - Yes: Address the cause: command hierarchy, interlock, synchronism or IED mode
  - No: Check the command model, the select and the device condition
- Yes: Does the control center command reach the gateway?
  - No: Check the link, the object address and the remote operator permissions
  - Yes: Check the gateway mapping: command type, select and operate, and their timing

How to confirm it

Traffic capture on the substation network or on the telecontrol link, with a protocol analyzer: it shows the order that left, the one that arrived and the response.
Command test from each level: IED front panel, bay controller, station HMI, gateway with a master simulator and, last, the control center.
Reading the interlocking logic with the real states at the moment of the rejection.
Comparing the gateway mapping with the signal list agreed with the control center: address, data type, command type and qualifier.

How to keep it from happening again

Define the signal and command list with the control center before configuring, and test it point to point at commissioning.
Align the select timing across the whole chain: the IED time limit must cover the delay of the link and the gateway.
Log the rejection causes in the HMI in clear text, so the operator knows why the command was not executed.
Check the mode of the IEDs after each maintenance job: a device left in test mode rejects commands and may not report.
Document the interlocking logic and test it with all the relevant combinations.

What not to do

Do not force the interlock from the HMI or with jumpers to execute the command. Interlocks prevent disconnector operations under load and closing onto earth.
Do not resend the order many times: each attempt can leave the device selected and block the next one.
Do not change the command model of an IED without coordinating with the gateway and the control center.
Do not leave the selector in local after work in the bay.

How IEC 61850 rejects a command and where the cause shows

In IEC 61850 the control of a device depends on the control model configured in the object, and the way it is rejected depends on that model. The WinCC OA documentation summarizes the four: direct control with normal security, select before operate with normal security, and the two variants with enhanced security. Direct control with normal security supports the Operate, TimeActivatedOperate and Cancel services; select before operate with normal security adds the Select service. In the enhanced variants, the server waits for a confirmation from the client to consider the command finished, and a timeout without that confirmation ends as a failure.

When a command fails, the server can report a last application error (LastApplError) with an additional cause value (AddCause). That table of values is in IEC 61850-7-2 and manufacturers reproduce it in the help of their controllers; Schneider Electric, for example, publishes it in the help of the IEC 61850 driver of its supervision software, and it includes values such as “object already selected”. That cause is the most valuable piece of data for diagnosis, because it tells apart an interlock block, a select held by another client, a local mode or a failed synchronism check, causes that from SCADA all look like “command rejected”. Many SCADA systems do not show the code and only log the rejection, so sometimes you have to look at the MMS client message log. See also IEDScout and IEC 61850 testing.

The decision points before the command:

Device mode: if the device is in local mode or out of service, the server does not accept remote commands, and that is correct.
Interlocks: the device evaluates its own interlocking logic before executing. An interlock because of a disconnector position, a block from another bay or a missing synchronism condition produces a legitimate rejection.
Select held: a select made by another client, or not released after a failure, blocks new commands until its timer expires.
Control model: if SCADA sends a direct command to an object configured for select before operate, the server rejects it.
IEC 60870-5-104 or DNP3 gateways: the device may accept the command over IEC 61850 and the gateway may fail it when translating; the cause is then sought in the gateway mapping and the command type (single or double).

Separating the layers is the key: first confirm whether the command reached the device, then whether the device accepted it and finally whether the actuator responded. The message log in the gateway and in the device makes that separation possible without touching the field.

When to call us

If the rejection is in the controller logic, in the command model or in the gateway mapping, our team reviews the configuration of the IEDs and the gateway remotely, worldwide, and tells you which link fails. See remote relay configuration and our SCADA and gateway integration. Write to us.

References

IEC 61850-7-2, Abstract communication service interface (ACSI): direct and select-before-operate control models.
IEC 61850-8-1, Specific communication service mapping (SCSM) – Mappings to MMS.
IEC 60870-5-104, Network access for IEC 60870-5-101 using standard transport profiles.
IEEE 1815, Standard for Electric Power Systems Communications – Distributed Network Protocol (DNP3).

Frequently asked questions

Why does the command work from the substation HMI but not from the control center?

Because the remote command passes through more links: the link to the control center, the gateway and its protocol conversion, and the allowed command level. Common causes are a selector at station level, an object mapped wrongly in the gateway, a command type different from the expected one, or a select that expires before the operate arrives.

What is select before operate (SBO)?

It is a two-step command model: first the device is selected and then the operation is ordered within a time limit. It prevents operations by mistake and reserves the device for a single client. If the operate arrives late or another client has already selected it, the command is rejected.

How do I know why an IEC 61850 IED rejected the command?

The IED's negative response carries an additional cause (AddCause) that indicates, for example, a block by command hierarchy, by interlock, by synchronism or by device mode, or a failed selection. The HMI or the engineering software shows it if they are configured to log it.