BadNotExecutable

BadExecutable attribute

What you actually see

The same call succeeds when the machine is idle in local mode and fails whenever it is running, or succeeds for one login and fails for another.

Why it happens

• UserExecutable is false for your identityExecutable is the general capability; UserExecutable is that capability evaluated for the current session's user. Anonymous sessions and read-only roles routinely have Executable true and UserExecutable false, which is why the method looks callable in a browse but is not.
• The machine state forbids itServers set Executable false dynamically. A reset method is not executable outside a fault state, a job start is not executable while a job runs, a maintenance method is not executable in production mode. The attribute is the machine telling you the precondition is unmet.
• Key switch or local/remote mode blocks remote commandsMany machines gate all write and call access behind a physical local/remote selector or an operator enable. In remote-disabled state the server exposes the methods and reports them as not executable, which is correct and cannot be fixed from the client.
• Role or RolePermissions not granted the Call permissionPart 18 role-based security carries a distinct Call permission separate from Read and Write. A role with full read access and no Call permission produces this code on every method regardless of arguments.
• Client cached a stale Executable valueExecutable changes with machine state. A client that read it once at startup and cached it can either skip a method that is now callable or call one that is not. Neither is a server fault.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Read Executable and UserExecutable on the method nodeThese are two distinct attributes on the Method NodeClass. Executable false means a state precondition; Executable true with UserExecutable false means an authorisation problem. This one read splits the diagnosis cleanly and should be your first step.
2. Re-authenticate with an identity that has Call rightsIf UserExecutable is false, switch from anonymous to a named user with the appropriate role and re-read the attribute. Do not attempt the call again on the same session; activating a session with a different user changes the evaluation.
3. Read the object's state machine before callingBrowse the parent object for a CurrentState variable and read it. Match it against the method's documented precondition. For companion-spec machines this is usually a state machine node such as a production or operation mode state.
4. Check the physical enableConfirm the machine is in remote or automatic mode and that any operator enable or key switch permits external commands. This is a walk-to-the-panel step and it resolves a large share of cases on real plant equipment.
5. Re-read Executable immediately before each callOr subscribe to the attribute. Treat it as live state, gate your call on it, and surface a meaningful message to the operator when it is false rather than firing the call and reporting a status code.

Where it shows up, by tool and stack

What it looks like in the log

Call ns=4;i=7112 -> BadNotExecutable (Executable=true, UserExecutable=false, session user=Anonymous)
method 'Reset' not executable: CurrentState=Executing

Confirm the fix

Read Executable and UserExecutable as true on the same session that will make the call, then confirm the call returns Good and the machine performs the action. Re-test in each machine state your application will encounter.

Stop it happening again

Gate every method call on a fresh read of Executable and UserExecutable, document the required role and state precondition per method, and make the operator-facing message explain which of the two is blocking rather than showing a status code.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.