The “Browse Path” Myth in OPC UA

OPC UA Does Not Define Any Browse Path

Let’s be explicit.
OPC UA does not define any of the following:

• OPC UA Node Path
• OPC UA Full Path
• Absolute Browse Path
• Hierarchical Path
• Textual Path

These are vendor-invented terms.
They are not part of the standard.
They are not interoperable.
They are not reliable.
Treating them as OPC UA concepts is a category error.

What OPC UA BrowsePath Really Is

OPC UA does define something called a BrowsePath.
But it is not what vendors present.
A BrowsePath is:

• a sequence of RelativePathElements
• defined by:
  • ReferenceTypeId
  • IsInverse
  • IncludeSubtypes
  • TargetName (QualifiedName)

It is used by the service:
TranslateBrowsePathsToNodeIds
A real BrowsePath is:

• not a string
• not human-readable
• not a filesystem path

It is a typed graph traversal instruction.
Reducing it to a string is model corruption.

Why OPC UA Path Strings Are Wrong

Many tools present OPC UA as a tree:
Objects → Plant → Area → Unit → Measurement
From this, they derive a string:
/Objects/Plant1/AreaA/Unit1/Measurement
This is:

• easy to display
• easy to script
• easy to understand

But it is incorrect.
OPC UA is not a tree.
It is a reference graph.

Why OPC UA Path Strings Break Industrial Systems

It breaks interoperability

A node may have multiple parents or none.
A single path cannot represent that.

It creates false uniqueness

Only NodeIds are guaranteed unique.
String paths are ambiguous and unstable.

It contradicts the information model

OPC UA is based on references and semantics.
Paths assume hierarchy.
This is incompatible.

It introduces vendor lock-in

String-based access makes systems:

• non-portable
• tool-dependent

It destroys maintainability

When models evolve:

• paths break
• scripts fail
• systems degrade

Correct OPC UA Modeling Approach

A correct OPC UA implementation follows these principles:

• Use NodeIds for identification
• Use BrowsePaths for resolution
• Use QualifiedNames properly
• Use TranslateBrowsePathsToNodeIds
• Treat string paths as UI-only

Anything else is non-standard engineering.

What Vendors Should Stop Doing

• exposing string paths as OPC UA concepts
• calling them “Browse Paths”
• using them in APIs
• suggesting they are standard

Call them what they are:

• Display Paths
• Navigation Paths
• UI Paths

The OpenOpcUa Position

At OpenOpcUa, the position is simple:

• no pseudo-standards
• no shortcuts that break the model
• strict compliance with OPC Foundation specifications

In real industrial systems, this requires a proper OPC UA architecture aligned with model-driven principles. This approach is fully implemented in the industrial OPC UA middleware platform developed within OpenOpcUa.

We promote:

• correct use of NodeIds
• correct use of BrowsePaths
• model-driven architecture
• interoperability-first design

This is exactly why OOUAMiddleware is designed as a model-driven OPC UA middleware:

• no string-based navigation
• full NodeSet-based modeling
• runtime graph traversal aligned with the standard

Stop Calling It a Browse Path

The so-called “OPC UA Browse Path” as a string:

• does not exist in the standard
• misrepresents the model
• creates interoperability issues

OPC UA already provides:

• NodeIds for identity
• References for structure
• BrowsePaths for traversal

Everything else is vendor-specific.
OPC UA is a graph-based information model.
Not a filesystem.

The OPC UA specifications published by the OPC Foundation clearly define BrowsePath as a structured concept.

The TranslateBrowsePathsToNodeIds service is defined in OPC UA Part 4.

Want to see a correct OPC UA implementation?

→ Explore OOUAMiddleware Architecture
→ Download the ProductionCell demo