Browse paths and access levels

BrowsePaths over NodeIds

NodeIds in ns=1 use string identifiers — those are stable across restarts:

ns=1;s=TestServer/DataTypes/Scalar/BooleanValue

But many tests are more readable using BrowsePaths:

[
  { ReferenceTypeId: HierarchicalReferences, TargetName: "TestServer" },
  { ReferenceTypeId: HierarchicalReferences, TargetName: "DataTypes" },
  { ReferenceTypeId: HierarchicalReferences, TargetName: "Scalar" },
  { ReferenceTypeId: HierarchicalReferences, TargetName: "BooleanValue" },
]

The TranslateBrowsePathsToNodeIds service converts these to NodeIds at runtime. Both work; pick the style your library expresses cleanly.

For the rest of the docs, paths are shown in shorthand:

TestServer/DataTypes/Scalar/BooleanValue

…meaning the BrowsePath starting from Objects, going through each named child. Translating that to a NodeId in ns=1 adds the ns=1;s= prefix.

Reference types used

For deep-nested structures (Structures/DeepNesting), the Organizes reference is used between levels.

Access-level legend

OPC UA's accessLevel attribute (id 17) is a byte bitmask:

userAccessLevel (id 18) is the same byte but scoped to the calling user — may be more restrictive than accessLevel.

Shorthand used in the docs

These are used throughout the Data features and Runtime features sections.

How to read the access-level attribute

Two attributes, two reads:

read(node, AttributeId.AccessLevel)     → byte bitmask
read(node, AttributeId.UserAccessLevel) → byte bitmask

Comparing them tells you whether the user has the same access as the node affords. Useful when writing role-aware client logic.

For systematic verification, see Access control — the suite has 50 variables that cover every combination, ready to exercise this attribute pair.

Browse depth

The deepest natural path is in Structures/DeepNesting, where each level recursively contains the next:

TestServer / Structures / DeepNesting /
  Level_1 / Level_2 / Level_3 / Level_4 / Level_5 /
  Level_6 / Level_7 / Level_8 / Level_9 / Level_10

That's 13 hops from Objects. Useful to test browse-depth limits in your client.

Hierarchical vs aggregating browses

A "hierarchical" reference is Organizes, HasComponent, or HasChild. Most browses use BrowseDirection.Forward with ReferenceTypeId = HierarchicalReferences and IncludeSubtypes = true.

For type-aware browses (e.g., "find all BaseDataVariableType instances"), you'd use ReferenceTypeId = HasTypeDefinition and BrowseDirection.Inverse. The suite's test surface doesn't require this — most tests stick with the default hierarchical forward browse.

ContinuationPoints

For very wide browses (large collections), some servers return results in chunks with a ContinuationPoint. The suite's largest collections are:

None of these are large enough to trigger continuation in UA-.NETStandard's default config. For continuation-handling tests, set MaxBrowseReferencesPerNode low (via config), or test against the largest known collection.

Where to read next

• The per-feature pages under Data features and Runtime features for what's inside each top-level folder.