OPC UA PubSub Metadata: Reject a Dataset Layout That No Longer Matches the Subscriber

Bind each incoming PubSub DataSetMessage to the correct publisher/writer context and a validated DataSetMetaData snapshot before interpreting its fields. A plausible field count or a familiar datatype is not enough: reordered fields can decode successfully while acquiring the wrong engineering meaning. Configuration-version checks belong ahead of cache updates.

This guide pins OPC UA Part 14, PubSub, version 1.05.06, published 22 October 2025. It focuses on cyclic UADP DataSets with configured major and minor version header fields. An original post-decoding metadata-admission model was executed. It did not implement UADP encoding, a PubSub SDK, network transport or message security.

Inventory the complete decoding contract

For each DataSetReader, record PublisherId, applicable group and DataSetWriter identification, transport/message mapping, field encoding, expected header layout and metadata source. Where a header omits identification, the configured layout must supply the necessary association; do not infer it from a convenient payload shape.

Retain the ordered FieldMetaData array, DataType and BuiltInType, ValueRank, size constraints, field identifiers and semantic properties. Part 14 requires metadata field order to match the order of fields included in DataSetMessages.

DataSetFieldId identifies a field independently of its position: moving a field does not change that identifier. This helps a configuration tool explain a reorder, but it does not make the old positional decoding layout valid.

Use the actual major/minor change rules

Configuration change	Required version effect in the pinned specification	Subscriber consequence
Remove or reorder fields; insert between existing fields	Update major version	Old positional contract cannot be assumed compatible
Change a field datatype	Update major version	Rebuild decoding and target checks
Change a field Property value or schema namespace array	Update major version	Revalidate semantic and type interpretation
Append fields at the end	Update only minor version	Consider supported extension behavior and local capacity
Update major version	Set minor version to the same value	Install the corresponding configuration pair

Section 6.2.3.2.6 defines these fields as VersionTime values reflecting changes. Do not treat them as an arbitrary incrementing software release number or assume numeric magnitude alone proves that one received metadata object is authoritative.

The normative compatibility requirement is matching major versions for decoding. A minor-only extension is different from a reorder. A constrained subscriber may deliberately require an exact major/minor pair until it has validated the appended fields; label that as a stricter local admission policy, not a universal OPC UA rejection rule.

Check that the required version evidence is present

The UADP DataSetMessage content mask controls whether major version, minor version and sequence number appear in its header. Do not quote the conceptual metadata contract as proof that every permitted wire layout includes all three.

This procedure requires both version fields in the configured layout. If the selected deployment omits them, establish another explicit configuration-synchronization contract and test it separately. An absent field must not silently become a matching version merely because a local structure was initialized to zero.

The valid flag also matters: a DataSetMessage marked invalid must not be processed. A version match does not override malformed encoding, failed message security or an invalid DataSetMessage flag.

Stage metadata before changing active decoding

1. Associate the candidate metadata with the intended publisher and writer through the approved configuration mechanism.
2. Validate supported field types, ranks, identifiers, counts and application semantics.
3. Check target capacity against array dimensions, string bounds and nested structure requirements.
4. Prepare an immutable decoding description and its target mapping together.
5. Install the complete snapshot under one serialized owner or a qualified synchronization mechanism.
6. Admit data only against that active snapshot; invalidate dependent reconstructed state when its layout changes.

Section 6.2.9.4 recommends checking whether target Variables can handle declared array and string sizes at startup and metadata update. A zero size bound means unknown in the relevant metadata fields; it is not evidence that the value requires no storage.

For RawData encoding, the metadata has an especially direct role in decoding and fixed-size padding. A generic “skip unknown appended bytes” strategy is not a substitute for the selected mapping’s complete rules.

Executed reordered-field example

The hypothetical old metadata has Float fields temperature then pressure, with stable field identifiers T and P. Values twenty and five produce the expected mapping. New metadata reverses the fields and changes the major version; its positional values are five and twenty.

The fixture demonstrates the old-schema counterexample: blindly pairing those new values with the old names produces temperature five and pressure twenty. Its admission gate instead rejects the version mismatch without changing the last accepted cache.

After installing the new immutable metadata snapshot, the same values map to pressure five and temperature twenty. The cache is cleared on installation so previously decoded values are not presented as a complete sample under the new layout.

A minor-only appended humidity field is also held until the fixture’s strict exact-pair policy installs matching metadata. Wrong source context and an oversized candidate metadata layout are rejected. A rejected installation leaves the prior metadata object intact.

Bound the missing-metadata state

Part 14 describes several metadata distribution mechanisms, including configuration models, metadata messages and product-specific configuration. Choose the mechanism the actual product supports; a reader cannot assume it can always fetch a new layout synchronously from a publisher.

When a publisher changes the major version, section 6.2.9.4 requires an update for further operation. If that update cannot be obtained within MessageReceiveTimeout, the DataSetReader changes to Error. Expose the pending mismatch and avoid treating undecoded messages as valid process values while waiting.

The local fixture did not run that timer, verify authenticity or exercise concurrent installation. Deployment acceptance should delay metadata, deliver data before metadata, reorder same-type fields, change semantic properties, exceed target bounds and restart with stale configuration. Success is a documented refusal or correct new interpretation, never a plausible value assigned to the wrong field.