OPC UA asset discovery modes

The connector for OPC UA can automatically discover assets connected to an OPC UA server and add their configurations to Azure Device Registry. To handle the different ways that OPC UA servers describe their address space, the connector supports three discovery modes: DI-based, type-based, and segmented. The mode you choose determines which server nodes become assets and data points, so matching the mode to how your server exposes its type model matters. The wrong choice can produce no assets, incomplete assets, or many small chunked assets.

This article explains how each discovery mode works, how the modes interact when you configure more than one, and how start-node and periodic discovery affect the results. To enable and configure discovery, see Discover and configure OPC UA assets. For an overview of the connector for OPC UA and the Akri services, see What are Akri services.

Discovery modes and precedence

The connector for OPC UA supports three discovery modes. Only one mode runs per endpoint. The following precedence determines which mode runs:

If you configure both assetTypes and segmentedDiscovery, type-based discovery takes precedence and the connector logs a warning.

To use the device integration (DI-based) discovery mode, the assets must comply with the OPC 10000-100: Devices companion specification. The connector for OPC UA and Akri services follow the process in OPC 10000-110: Asset Management Basics to discover OPC UA assets and onboard them into Azure Device Registry.

Comparison of discovery modes

Segmented discovery

By default, asset discovery uses the DI-based mode, which detects assets by matching OPC UA DeviceType/ComponentType patterns from the DI companion specification. This mode works well for servers that implement standard DI information models, but many OPC UA servers expose flat lists of Variable nodes without DI types.

Segmented discovery browses the OPC UA server's address space and automatically creates discovered assets by chunking Variable nodes into fixed-size datasets.

Segmented discovery is an alternative discovery mode that:

1. Browses the address space and collects all Variable nodes, excluding PropertyType variables.
2. Chunks the Variable nodes into discovered assets.
3. Automatically creates multiple discovered assets when the number of variables exceeds the per-asset limit.
4. Names assets by using the pattern {endpointName}-{index}. For example, opcua-endpoint-0 and opcua-endpoint-1.

Segmented discovery is useful when:

• The OPC UA server doesn't implement DI companion specification types.
• You want to discover all Variable nodes without type filtering.
• The server has a large flat address space with thousands of Variable nodes.

Segmented discovery asset chunking limits

Segmented discovery chunks Variable nodes into discovered assets with the following limits:

Segmented discovery node filtering

Segmented discovery applies the following filtering when browsing the OPC UA address space:

Segmented discovery example: 11,000 Variable nodes

For a server with 11,000 Variable nodes, segmented discovery creates:

Segmented discovery example: 25,000 Variable nodes

For a server with 25,000 Variable nodes, segmented discovery creates:

Start-node discovery

By default, asset discovery browses the entire OPC UA address space starting from the root folder. For large servers with thousands of nodes, this process can be slow and return many irrelevant results.

Start-node discovery lets you specify a starting node so that discovery only browses the subtree under that node. This feature is useful when:

• The OPC UA server has a large address space and you only care about a specific section.
• You want faster discovery by limiting the scope.
• You need to target a specific production line, machine, or device subtree.

You can combine start-node discovery with any of the discovery modes: DI-based, type-based, or segmented.

Start-node formats

The discoveryStartNode property accepts two formats:

• Use a standard OPC UA ExpandedNodeId string to point directly to a node. For example: nsu=http://microsoft.com/Opc/OpcPlc/Boiler;i=5

• Use a browse path with namespace-index-qualified segments. The objects folder of the OPC UA address space serves as the start instance. For example: /4:Boiler/4:BoilerStatus

  Each segment uses the format <namespaceIndex>:<browseName>, separated by /. The OPC UA TranslateBrowsePathsToNodeIds service resolves the path. The browse path syntax follows the OPC UA specification.

  Warning

  Namespace indexes might change when the server restarts. Use the browse path format only when you're certain the indexes are stable.

Start-node error handling

If the endpoint can't resolve the start node (for example, because of an invalid NodeId, unknown namespace, or missing node), it skips asset discovery and logs an error such as:

Periodic discovery

Asset discovery browses the OPC UA server's address space to detect assets. On large servers, this process takes a long time. By default, discovery runs only once.

Two properties control periodic discovery:

• runAssetDiscovery (boolean, default false) enables asset discovery.
• assetDiscoveryInterval (integer minutes, default 0) sets how often discovery repeats.

The following table summarizes the behavior of periodic discovery based on these two properties:

Periodic discovery behavior details

Periodic asset discovery in the connector for OPC UA works as follows:

• The first discovery run starts a few seconds after you apply the endpoint configuration.
• When multiple endpoint profiles enable periodic discovery with different intervals, a single timer ticks at the smallest configured interval, and each profile runs at its own configured interval.
• Choose larger intervals for servers with large address spaces to avoid overlapping or long-running discovery cycles.

Related content

• Discover and configure OPC UA assets
• What are Akri services?
• Understand the connector for OPC UA