Skip to main content

Browse Paths & $anchor

To connect nodes, set initial values, or define components, OPC UA Modeler uses Browse Paths. For complex hierarchies, the DSL provides $anchor—a highly convenient, compile-time modeling aid to easily reference nested nodes without typing repetitive paths.

1. Browse Path Syntax​

Browse paths are strings used to traverse your address space tree. They use standard separators to distinguish between child nodes and properties:

  • Forward Slash (/): Navigates to aggregate children (Objects and Variables).
    • Example: MyDevice/InletSensor
  • Dot (.): Navigates to properties (Variables containing metadata or configuration).
    • Example: Temperature.EURange

Namespace Qualification​

Each segment in a browse path must be qualified with its namespace prefix (e.g., di:, ua:, or custom companion spec aliases) to match the strict resolution rules of the OPC UA compiler:

initializers:
  - variable: Tank1/di:ParameterSet/Temperature.ua:EngineeringUnits
    value: "°C"

2. The Problem: Deep Nesting & Path Repetition​

When building large companion spec models, referencing deeply nested parent nodes (e.g., placing a component under a deep folder or specifying a sub-component relation) can lead to long, repetitive paths:

instances:
  - browseName: InletFlowSensor
    typeDefinition: FlowSensorType
    componentOf: /ua:Objects/di:DeviceSet/Line1/StationA/di:ParameterSet/Manifold

Writing out these long browse paths is tedious, prone to typing errors, and breaks easily if nodes are rearranged in the hierarchy.

3. The Solution: $anchor​

To deliver an elegant developer experience, OPC UA Modeler supports the $anchor keyword. You can declare a unique symbolic alias on any instance.

instances:
  - browseName: Manifold
    $anchor: primary-manifold
    typeDefinition: ManifoldType
    componentOf: StationA/di:ParameterSet

Once defined, you can reference the anchor directly as a symbolic link prefixed with $ in placement or relationship fields across your model!

# Clean, robust reference using the $ prefix!
instances:
  - browseName: InletFlowSensor
    typeDefinition: FlowSensorType
    componentOf: $primary-manifold

Implicit Anchors​

Under the hood, if an instance has a globally unique browseName within your model file, the compiler implicitly maps the browseName as an anchor. This means you can omit $anchor entirely and simply use $BrowseName to link your nodes!

# Implicit anchor reference
instances:
  - browseName: InletFlowSensor
    typeDefinition: FlowSensorType
    componentOf: $StationA

4. Anchor Disambiguation​

Anchors are exceptionally powerful when multiple child nodes share the exact same browseName under different parents.

For example, two identical nested Sensor instances placed under different pipes:

instances:
  - browseName: Sensor
    $anchor: sensor-inlet
    typeDefinition: TemperatureSensorType
    componentOf: InletPipe

  - browseName: Sensor
    $anchor: sensor-outlet
    typeDefinition: TemperatureSensorType
    componentOf: OutletPipe

Without $anchor, you would not be able to uniquely target the inlet sensor or outlet sensor for initializations. With anchors, you can configure them separately and clearly:

initializers:
  - variable: $sensor-inlet/Temperature
    value: 22.5
  - variable: $sensor-outlet/Temperature
    value: 45.0

5. Architectural Cleanliness​

[!IMPORTANT] Anchors are a compile-time modeling aid only. They do not appear in the generated NodeSet2.xml output. This keeps your production XML files perfectly standard-compliant, lightweight, and clean, while offering a fluid, low-code development environment.