Resolving OPC UA CurrentState in Nested State Machines

The client shows Cleared or Running while the machine is executing. The usual reaction is to force every ancestor’s CurrentState to Execute, change client mapping, or add effective identifiers immediately. Those changes confuse two separate signals: the local state of each state machine and the effective human-readable state of the nested hierarchy.

Why do the usual fixes fail?

Writing Execute into every parent CurrentState destroys the hierarchy. Each state machine reports its own active state, not the deepest active state anywhere below it. In the stated PackML hierarchy, the base machine remains in Cleared while its nested machine is in Running and the next nested machine is in Execute.

Changing the client to treat the parent’s ordinary CurrentState as the leaf state fails for the same reason. The client is reading a valid local state and assigning it the wrong meaning. Tuning display refresh rates or transition logic will not correct a semantic mapping error.

Adding custom EffectiveId, EffectiveName, or EffectiveNumber properties before confirming the existing nodes also creates unnecessary client dependencies. Such properties can provide a machine-processable effective state, but their definitions, data types, and selection rules must be part of the server’s information-model contract.

What should each CurrentState report?

CurrentState describes the current state of the state machine that owns that variable. It does not automatically flatten its descendants. For the hierarchy described—Execute below Running, and Running below Cleared—the expected local values are:

Therefore, BaseStateMachine.CurrentState should report Cleared, and BaseStateMachine.MachineState.CurrentState should report Running. The nested execute state reports Execute. These values are simultaneously correct because they describe different levels of the model.

How does EffectiveDisplayName change the result?

The StateVariableType property EffectiveDisplayName supplies a human-readable name after accounting for active substate machines. For this hierarchy, the effective display name on both BaseStateMachine.CurrentState and BaseStateMachine.MachineState.CurrentState can be Execute, even though their local states remain Cleared and Running.

Part 16 does not prescribe which active state or substate the server must select for this text. The server chooses according to the semantics of its StateMachineType. A deepest-leaf policy is useful here, but a client cannot treat that policy as universal across unrelated server types.

This distinction matters at the final consumer. An HMI operator may need one effective label, while sequence logic, diagnostics, or analytics may need the separate local states. EffectiveDisplayName is display-oriented text. It is not automatically an effective ID, name token, or number for deterministic control decisions.

Why does the client show the wrong process state?

The measured signals may all be correct while the presentation is wrong. The server evaluates each state machine and exposes its local CurrentState. The client then selects one node, translates it into a process label, and sends that label to an HMI, historian, alarm rule, or application. Selecting an ancestor’s local state when the display requires the deepest active state produces the apparent mismatch.

Look at the trend first. Capture the three local CurrentState values and the available EffectiveDisplayName values through the same transition. This separates a server-state error from a client-selection error. If the hierarchy advances from Cleared through Running to Execute at the expected levels, changing state-machine logic is the wrong repair.

Also inspect the server type definition rather than inferring hierarchy from display text. The decision point is whether the consumer needs the owning machine’s local state, a selected effective label, or a custom machine-readable leaf value.

What procedure produces the correct mapping?

1. Draw the active hierarchy. List each state machine instance and its immediate active state. For the stated model, map base to Cleared, nested machine to Running, and execute-level machine to Execute.
2. Read every local state separately. Browse and monitor BaseStateMachine.CurrentState, BaseStateMachine.MachineState.CurrentState, and BaseStateMachine.MachineState.ExecuteState.CurrentState. Do not alter server logic during this measurement.
3. Read the effective text. Check EffectiveDisplayName on the ancestor state variables. Confirm whether the server selects Execute for this type and transition.
4. Classify the consumer. Bind an HMI summary label to EffectiveDisplayName when human-readable effective status is required. Bind diagnostic or sequence consumers to the local CurrentState at the level they control.
5. Define machine-readable effective data only when required. If an application needs one effective identifier rather than text, add or use a modeled property only under a documented server-client contract. Do not derive control identity by parsing the display name.
6. Test every transition path. Record parent, intermediate, leaf, and effective values together. Include entry to and exit from nested states so stale effective text is visible.

How do you verify the correction?

Verification passes when each local node continues to describe only its owning state machine, while the effective display follows the server’s documented selection policy. During execution, the expected snapshot is Cleared at the base, Running at the intermediate machine, and Execute at the leaf, with Execute available as the effective display text on the applicable ancestors.

Repeat the test while leaving Execute. Confirm that each nested state changes at the correct level and that EffectiveDisplayName no longer presents the departed leaf. Test the client independently by displaying the node path beside its value; this catches accidental binding to an ancestor with a similar browse name.

Recurring pitfalls include flattening the hierarchy into every CurrentState, using display text as a control identifier, assuming all servers choose the deepest leaf, and testing only the steady executing condition. Preserve the hierarchy and make the client’s selection rule explicit.

FAQ