When an IED rejects a command, the negative response can carry an additional cause (AddCause) that says why: blocked by interlocking, by synchrocheck, by mode or by device health, invalid or already-reached position, command in progress, time limit exceeded, cancellation or trip. In MMS the cause arrives in a separate message with the object, the error, the originator and the command's sequence number.
How a command is rejected in IEC 61850
Short answer. A command is rejected when the controlled object does not pass its checks. The negative response can carry an additional cause, AddCause, which is a value from a list in the standard. That list guides the diagnosis: it says whether the selection, an interlock, the synchrocheck, the device mode, the position or the timing failed.
Part 7-2 defines the control model with selection services (Select or SelectWithValue), cancel (Cancel), operate (Operate or TimeActivatedOperate) and termination (CommandTermination). Depending on the object, the model can be direct control or select-before-operate, with normal or enhanced security. The guide on select before operate (SBO) explains the models; here the negative responses are explained.
At selection, the object checks that the client has authority, that no other client has selected it, that the device is operable and that it is not tagged to restrict operation. If everything is fine, it goes to “ready” and a deselect timer starts. At operation it validates again. If it cannot execute, it responds negatively. With enhanced security, it also monitors the change of state and always closes with command termination, positive or negative.
- Selection. The object validates authority, selection by another client, operable state and tags; if it fails, negative response
- Operation. Validates again; if it fails, negative response with additional cause
- Execution. The output is activated and the position change is monitored
- Report. The new state is reported through the reporting model
- Termination. Positive if the position was reached in time; negative if it did not change or exceeded the time
How the cause reaches the client
In the MMS mapping (part 8-1), the additional cause does not travel in the write response. The server issues an information report on a variable called LastApplError, which exists only at that moment. Besides the cause, it contains:
- the control object the command referred to;
- an application error: no error, unknown, test-time not correct or operator-test not correct;
- the originator and the sequence number of the command, which let the client associate the notice with the command that caused it.
The variable is volatile and takes default values when an association is opened. A negative termination is transmitted with that same error plus the controlled object. If your SCADA shows “rejected” with no reason, it may not be reading this message; check the HMI or capture the traffic with Wireshark.
The causes and what to check
| Value | Cause | What the standard says | What to check |
|---|---|---|---|
| 0 | Unknown | Mapping value; part 7-2 groups it with the general service errors | Device event log |
| 1 | Not-supported | Mapping value; part 7-2 groups it with the general service errors | Configured control model and what the device implements |
| 2 | Blocked-by-switching-hierarchy | Some local switch downstream, such as that of a control node, is true | Local/remote selectors at each level; see command levels |
| 3 | Select-failed | Cancelled by an unsuccessful selection | The response to the previous selection |
| 4 | Invalid-position | Aborted due to invalid position of the breaker or disconnector | Position status: intermediate or invalid |
| 5 | Position-reached | The device is already in the requested position | Actual state compared with what the client showed |
| 6 | Parameter-change-in-execution | The command is blocked because a parameter change is in progress | Whether a parameter change is under way in the device |
| 7 | Step-limit | The tap changer reached its limit | End position of the tap changer |
| 8 | Blocked-by-Mode | The node is in a mode that does not allow operation | Mode of the control logical node or of the primary equipment |
| 9 | Blocked-by-process | An external process event prevents operation | Blocking indication from the primary equipment |
| 10 | Blocked-by-interlocking | The open or close permission of the interlocking is false | Interlocking logic and signals from other bays |
| 11 | Blocked-by-synchrocheck | The time expired without the synchrocheck condition being met | Voltages, angle and frequency on both sides |
| 12 | Command-already-in-execution | A command or cancel is already in progress | Simultaneous commands |
| 13 | Blocked-by-health | An internal event of the device prevents operation | Health status of the node |
| 14 | 1-of-n-control | Another command of a domain, such as the substation, is in progress | Active selection on another device in the same domain |
| 15 | Abortion-by-cancel | Aborted by a cancel | Whether any client cancelled |
| 16 | Time-limit-over | Terminated by exceeding a time limit | Selection and execution times |
| 17 | Abortion-by-trip | Aborted by a trip | Whether a protection operated during the command |
| 18 | Object-not-selected | No detailed definition in part 7-2 (edition 1) | Whether the operation was sent without prior selection or after the selection expired |
Values 0, 1 and 18 appear in the table of part 8-1; in part 7-2 (edition 1) the first two fall under the general service errors and 18 has no definition. The definitions of the rest are in part 7-2. In edition 1, the definition of blocked by interlocking ties it to the open or close permission of the interlocking logical node, and that of invalid position to the position status of the breaker or disconnector.
A tree to start the diagnosis
- Did the client receive an additional cause (AddCause)?
- No: First check the application error message in the traffic, then the client's authority, the control model and the connection
- Yes: Is the cause a block (mode, health, process, local hierarchy, interlocking or synchrocheck)?
- Yes: Is it interlocking or synchrocheck?
- Yes: Check the interlocking enable conditions and the synchrocheck condition with its time limit
- No: Check mode, health, process block and the local/remote selectors of the lower levels
- No: Is it a sequence cause (select failed, command in progress, 1-of-n, time, cancel or trip)?
- Yes: Check the select and operate sequence, the times, and whether another command or a trip occurred during execution
- No: Invalid position, position reached, step limit or parameter change: compare the actual position with the requested one
- Yes: Is it interlocking or synchrocheck?
What to do with this in the project
- In design. Define what the operator will see for each cause. A “rejected” message with no cause forces you to call the protection staff for every operation.
- In testing. Provoke each relevant cause and verify that the HMI shows it. See interlocking tests and command rejected from SCADA.
- In operation. Log the cause with the timestamp and the originator. For interlocks, the interlocking table tool helps you see which condition blocks it.
IEC 61850 commands and interlocking with Tiza Group
Are your commands being rejected without it being clear why? At Tiza Group we review the control and interlocking configuration with our IEC 61850 engineering and test every rejection cause during commissioning, in medium, high and extra-high voltage substations and industrial plants.
Related guides
- Command rejected from SCADA
- Select before operate (SBO)
- Bay and station interlocking
- Command levels and local/remote selector
- Interlocking tests
- IEC 61850 MMS: reports, SBO commands and files
References
- IEC 61850-7-2 (edition 1, 2003): clause 17, control model; 17.5.2.6, additional cause diagnosis.
- IEC 61850-8-1 (edition 1, 2004): clause 20, mapping of the control services; 20.8, additional cause in negative responses; 20.9, command termination.
- IEC 61850-7-3 (edition 1, 2003): controllable data classes.
Frequently asked questions
What is the difference between Blocked-by-interlocking and Blocked-by-process?
The first indicates that the device's interlocking does not enable the operation, that is, the open or close permission of the interlocking node is false. The second indicates that an external process event prevents operation, such as a blocking indication from the primary equipment. In practice, different places are checked.
Does a rejected command always carry the additional cause?
No. It is additional application information and only some control services return it in their negative response. If the client does not display it, it may be in the application error message, which not all clients show to the operator.
Why can a breaker command be rejected with Position-reached?
Because the device is already in the requested position. The standard defines this cause as: the circuit breaker or disconnector is already in the desired position, according to the position status of its logical node. It can happen when SCADA shows a state that is no longer the real state of the device.