OPC UA Method Calls: Keep Object Context and Argument Validation in the Gateway Contract
An OPC UA Call identifies both the Object or ObjectType context and the Method. Validate that relationship and the ordered argument signature before submitting the request. Knowing a Method NodeId is insufficient: the same method definition can belong to different instance contexts, while a valid-looking argument list can still violate datatype, rank or application constraints.
This guide pins OPC UA Part 4, version 1.05.07, section 5.12.2, and Part 3, version 1.05.06, sections 5.7 and 8.6. The executable fixture covers a reduced Object-instance relationship and argument validator. It performs no real Method call, device command or SDK operation.
Bind the Method to its intended context
For an Object instance, Part 4 allows the relevant HasComponent relationship, or a subtype of that reference, from the Object, its ObjectType or a supertype of that ObjectType to the Method. The request may identify the instance’s Method or the Method defined in its ObjectType as specified by the service.
Do not search for a Method display name globally and invoke the first match. Preserve typed Object and Method identities, resolve their namespaces in the correct server context and validate the documented relationship.
Calling on an ObjectType has a different boundary: the ObjectType must be the source of the component reference and the Method must not have a ModellingRule. Do not generalize an instance-only validator into complete ObjectType-call support.
Read the signature as typed metadata
InputArguments and OutputArguments are ordered arrays of Argument structures. Each Argument includes a name, DataType NodeId, ValueRank, ArrayDimensions and description. The request’s input array follows that order; names are metadata, not named-argument routing keys on the wire.
ValueRank distinguishes scalar, one-dimensional, multidimensional and permitted combinations. A scalar Double and a one-element Double array are not interchangeable simply because both can be displayed as one number.
ArrayDimensions describes maximum supported dimension lengths, with zero representing an unknown maximum under the defined contract. Do not mistake every nonzero maximum for a requirement that all arrays have exactly that length. Additional fixed-size or cross-field requirements must come from the Method’s documented application contract.
If InputArguments is absent or empty, the Method has no input arguments. Do not infer missing metadata from a failed browse without first establishing whether the Property is truly absent or inaccessible.
Omit arguments only when they are declared optional
Part 3 defines HasOptionalInputArgumentDescription for optional inputs. Optional inputs follow all non-optional inputs in InputArguments. Part 4 permits fewer supplied arguments when these optional arguments are defined.
A gateway should not guess optionality from a default-looking value or a UI field left blank. Preserve the declared minimum and maximum argument counts and use the selected SDK’s supported omission behavior.
For a hypothetical Preview Method, the application contract requires UInt32 Count and a one-dimensional Double array Values, followed by an optional String Label. The test model accepts either two arguments or all three. It rejects a missing required argument and an extra fourth argument before evaluating values.
Keep local validation narrower than authorization
Executable indicates general executability; UserExecutable also accounts for user access rights. Part 3 explicitly warns that clients cannot assume execution will succeed from UserExecutable alone. Server state and permissions can change after the Attribute is read.
Use those Attributes for capability and user-interface guidance while retaining the server’s actual Call result as authoritative. The service also defines RolePermissions checking against the Method associated with the requested Object context. Local validation cannot grant rights or bypass that check.
Validate complete input snapshots before sending. A mutable application object must not change between argument checking and encoding, particularly when a background worker handles submission.
Interpret three diagnostic layers
| Layer | Example | Meaning |
|---|---|---|
| Service result | Bad_TooManyOperations | The Call service request was rejected at service level |
| Method result | Bad_MethodInvalid | The Method is not valid for the specified context |
| Input-argument result | Bad_TypeMismatch at slot one | A supplied argument violates its contract |
When an input breaks a constraint, the Method result is Bad_InvalidArgument and inputArgumentResults supplies positional details. That list is otherwise empty; if populated, its length matches the supplied inputArguments list. Missing and excessive argument counts have their own operation-level statuses.
The fixture replaces the expected UInt32 with a String and receives a local Bad_InvalidArgument classification with Bad_TypeMismatch in the first slot and Good in the second. Another case exceeds the array’s application limit and preserves the second-slot association. These are validator results, not captured server responses.
Validate outputs according to the operation status
Output arguments follow the Method’s OutputArguments order. If the operation StatusCode has Bad severity, the output list must be empty. The service recommends Uncertain severity when Method execution fails but output arguments provide additional application error information.
Do not drop all outputs solely because the status is not exactly Good, and do not consume outputs attached to a Bad result as normal successful data. Interpret Uncertain outputs through the specific Method contract and preserve the status alongside them.
Batching several Methods does not establish their execution order. Use separate calls when sequential processing is required. Also, termination of the Session can discard returned results independently of the work performed by the server; a missing response does not establish that the Method never ran.
Qualification evidence
- Verify direct and inherited Object/Method relationships and reject an unrelated Object.
- Test required and optional counts, exact scalar/array types, dimension bounds and application ranges.
- Inspect operation-level and argument-level errors without losing request-slot association.
- Exercise denied execution even after an earlier UserExecutable observation.
- Validate Good, Bad and contract-defined Uncertain output handling.
- Use harmless preview or simulator Methods for timeout and Session-loss tests.
The reduced fixture passed eight relationship and argument cases. It omits full subtype compatibility, the ByteString-versus-byte-array exception, security enforcement and output execution. The final gateway contract should make those supported boundaries explicit rather than claiming that successful argument serialization proves a correct or authorized command.
