OPC UA Structured Values: Decide When an Unknown ExtensionObject Can Be Forwarded
An unknown ExtensionObject can be retained as an identified opaque payload, but that does not make arbitrary forwarding safe. The bridge must preserve its encoding identity and bounded body, establish that the destination understands that encoding, and prove that namespace-sensitive content remains valid in the destination context. If the operation requires field interpretation or encoding conversion, an unknown schema is a compatibility failure.
This guide pins OPC UA Part 6, Mappings, version 1.05.07, sections 5.2.2.15 and 5.2.6. The scope is ExtensionObject representation within OPC UA Binary encoding. An original post-header admission fixture was executed locally. It is not a complete UA decoder, XML parser, SDK or live bridge.
Identify the encoding node, not just the datatype name
In the binary representation, TypeId identifies a DataTypeEncoding node. It does not simply name the abstract DataType. The decoder uses that encoding identity to select the syntax of the body.
Store a registry key that preserves the encoding node’s namespace URI, identifier type and identifier, together with the accepted encoding and schema version evidence. Resolve namespace indexes through the appropriate server context rather than treating a numeric index as a portable namespace identity.
A display name such as “PumpRecord” is insufficient. Two encodings of one datatype can require different decoding, and two unrelated models can reuse the same display text. Record the exact vendor model revision and the SDK support that establishes compatibility.
Validate the envelope before retaining bytes
Part 6 defines encoding zero for no body, one for a ByteString body using UA Binary, and two for an XmlElement body. When a body is encoded, the representation includes an Int32 length followed by its bytes. The canonical null ExtensionObject has TypeId i=0 and encoding zero.
A decoder that does not recognize the DataTypeEncoding can use the encoding field to process the body representation or treat it as opaque and skip it. Unknown semantic type is therefore different from an invalid outer envelope.
Before copying or retaining a body, enforce the SDK’s supported wire contract and local size limit. Validate that the body span fits the enclosing message. Avoid signed-to-unsigned conversion mistakes and addition overflow when calculating its end.
Do not scan for a guessed field terminator inside an unknown binary structure. Use the declared, validated body boundary. XML-looking bytes still need the declared encoding and a suitable parser if the application intends to interpret them.
Use a forwarding decision matrix
| Required operation | Unknown-schema decision |
|---|---|
| Store an opaque diagnostic artifact | Retain bounded bytes with identity and provenance |
| Forward unchanged in a proven compatible context | Permit only with destination encoding support and normal authorization |
| Map a named field to a scalar output | Reject until a matching schema decoder exists |
| Convert Binary body to XML or another representation | Require supported schema-aware conversion |
| Move between servers with different namespace mappings | Reject opaque forwarding unless all context dependencies are proven compatible |
“Destination support” must come from its documented model and qualified behavior, not merely from a successful transport connection. A bridge should report a structured compatibility error instead of substituting zero fields or dropping the unknown value silently.
Do not remap only the outer TypeId
Structures can contain typed fields whose representations include NodeIds or other namespace-sensitive information. If the bridge cannot decode the body, it generally cannot locate and rewrite every nested reference.
Consequently, resolving the outer encoding node into a destination namespace table is not enough to prove the opaque body is portable. This is an engineering consequence of typed nested encoding, not a universal prohibition on every pass-through deployment.
A same-context tunnel can have a documented compatibility contract. A cross-server semantic bridge usually needs schema-aware decoding, transformation and re-encoding, or an explicit vendor guarantee covering the complete structure. Treat such evidence as part of the integration rather than assuming all bytes are namespace-independent numbers.
Handle schema changes without guessing offsets
Ordinary structures encode fields in their defined order. Reordering or changing field types can change meaning even when total body length is unchanged. A size check protects the buffer boundary; it cannot prove the schema matches.
Keep decoder selection tied to the documented encoding/model contract. If a vendor changes a model incompatibly, require an explicit compatibility decision and new test fixtures. Do not infer a field layout from one observed payload and present it as an official schema.
Optional fields, unions, arrays and nested structures need their own supported rules. A decoder for one fixed record is not automatically a decoder for every ExtensionObject associated with that vendor namespace.
An original bounded-body fixture
The hypothetical local utility receives an already decoded TypeId, encoding, declared length and remaining bytes. A four-byte binary body followed by a four-byte tail returns the body and leaves the tail untouched. The XML-body case does the same, while the no-body case consumes no body bytes.
The fixture rejects an unsupported encoding, a negative length under its deliberately restrictive local policy, an oversized body and a truncated body. It does not claim to implement all legal null encodings or wire-level NodeId and Int32 parsing.
A policy function permits opaque forwarding only when supplied compatibility evidence identifies the same context and a supporting destination. It rejects field extraction, conversion and unproved cross-context forwarding. Two different four-byte payloads pass the same size check, demonstrating that equal length is not semantic validation.
Qualification evidence
- Capture exact model and encoding-node identity using public test data.
- Exercise known and unknown encodings, maximum accepted bodies and truncated envelopes.
- Verify opaque retention preserves every body byte and its provenance without claiming decoded fields.
- Test schema revisions with equal and unequal body sizes.
- Test nested namespace references before enabling any cross-server forwarding.
- Confirm destination rejection is surfaced and cannot trigger a silent scalar fallback.
The acceptance decision should name which values are decoded, which are retained opaquely and which operations are blocked. A bridge remains interoperable by being precise about what it preserves and understands, rather than treating an unknown structured payload as interchangeable bytes.
