DAItemIdTemplate: Server Pattern, Not a Universal OPC Rule

Erik Lindqvist6 min read
OPC / OPC UAOther ManufacturerTechnical Reference
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Live mapping becomes slow when node resolution performs more browse work than the address space and update cycle can tolerate. The number that matters is the lookup cost per mapped member: direct Item ID access is efficient, while browse-path resolution can require retrieving the child nodes beneath a parent and matching the requested name. DAItemIdTemplateAttribute can remove that repeated browse work when the server’s Item IDs follow a verified parent-child naming rule.

Common fixes that fail

Hard-coding an Item ID for every mapped member appears efficient because each node can be addressed directly. It fails as a reusable mapping strategy: a member receives one concrete Item ID, so the same mapped class cannot represent equivalent structures under different branches without separate identifiers for every instance.

Applying a template before checking the server’s namespace fails differently. OPC DA does not define a universal relationship between a parent Item ID and its children’s Item IDs. They may be arbitrary strings. A syntactically plausible template can therefore generate valid-looking identifiers that refer to the wrong item or no item at all.

Rooting a mapping at an Item ID and then expecting browse paths to continue below it also has a compatibility limit. Some old OPC DA 1.0 servers cannot support that mixed resolution method in the general case. The deciding test is an actual browse and read through the intended root, not the appearance of the namespace in a client display.

Replacing all browse paths with templates is unnecessary when browse performance already meets the application’s timing requirement. Browse paths are the general solution because they describe hierarchy without assuming how the server encodes Item IDs.

Lookup cost and timing

This is lookup work, not mapping logic. QuickOPC identifies a node through a DANodeDescriptor using an Item ID, a browse path, or both. An Item ID can go directly to a known node because browsing returns Item IDs that clients can store and reuse. A browse path resolves each child from its position in the hierarchy.

To find a named child through a browse path, the client may need to obtain the subnodes under the parent and compare their browse names. The resulting delay grows with the number of parents resolved, the number of children exposed by each parent, server response time, and how often resolution repeats. Measure the mapping initialization or remapping interval at the client; update rate alone does not identify address-resolution overhead.

Quantity or limit Engineering significance Where to read or measure it
One concrete Item ID per mapped member Prevents one hard-coded member definition from being reused under different branches Mapping attributes or mapping-context configuration
Children examined per parent Drives browse-path lookup work Server address-space browser and client diagnostics
Mapping initialization time Shows whether browsing is causing a meaningful delay Timestamp before and after mapping activation
Parent-child Item ID pattern Determines whether a template can generate correct child IDs Item IDs returned by browsing several representative branches
OPC DA 1.0 compatibility boundary May prevent an Item-ID root followed by browse-path navigation Server documentation and an end-to-end browse/read test

Template composition

DAItemIdTemplateAttribute supplies server-specific knowledge that OPC DA itself does not provide. Live mapping substitutes fragments into the template to calculate a child Item ID:

Fragment Substituted value Constraint
$(ParentItemID) OPC Item ID of the parent node The parent must already have a usable Item ID
$(ParentNodePath) OPC node path of the parent node Available only with OPC XML-DA
$(BrowseName) Browse name of the current node The browse name must match the segment used by the server’s Item ID convention

For a Kepware namespace in which a child Item ID consists of the parent Item ID, a period, and the child browse name, use:

$(ParentItemID).$(BrowseName)

This pattern applies to the described Kepware nodes except those immediately below the root. That exception matters: a single global template can misaddress the first namespace level even when it works below that level. Define the template only at a context where every covered descendant follows the same composition rule.

The attribute is associated with DAMappingContex and MappingContextTemplate in the referenced documentation. Place it at the mapping context or template scope that owns the repeatable branch structure, rather than attaching guessed concrete IDs to every mapped member.

Selection decision

Start with browse paths. They allow a child path to be formed by appending the child’s short browse name to the parent path and remain valid when Item IDs are opaque. Move to DAItemIdTemplateAttribute only after measurement shows that browse resolution contributes unacceptable mapping latency.

  1. Browse several instances of the structure that the same mapped class will represent.
  2. Record each parent Item ID, each child browse name, and the returned child Item ID.
  3. Test whether one expression reproduces every recorded child Item ID exactly.
  4. Include boundary nodes: the root, nodes directly below the root, nested branches, and repeated class instances.
  5. If one rule does not cover the entire scope, narrow the mapping context or retain browse paths for the exceptions.

A template is appropriate when the relationship is deterministic across the selected scope and the reduced browse work matters. Hard-coded IDs fit a fixed, non-reusable mapping. Browse paths fit reusable mappings on servers with arbitrary Item IDs or acceptable browse performance.

Configuration procedure

  1. Build the mapping with browse paths and prove that every member reaches the intended node. This establishes a functional baseline independent of Item ID composition.
  2. Measure mapping activation time and capture client or server diagnostics that separate address resolution from subsequent reads.
  3. Browse representative parent-child pairs and derive the smallest exact template from returned identifiers. For the documented Kepware pattern below the first level, use $(ParentItemID).$(BrowseName).
  4. Apply DAItemIdTemplateAttribute through the applicable DAMappingContex or MappingContextTemplate scope.
  5. Exclude nodes immediately under the root from the Kepware pattern unless their returned Item IDs independently prove the same rule.
  6. Activate multiple instances of the mapped class under different branches. Confirm that substitution starts with each instance’s actual parent Item ID.
  7. Compare activation timing against the browse-path baseline. Keep the template only when it produces identical node selection with a useful timing improvement.

Verification and recurring pitfalls

Verify identity before performance. For every mapped member, compare the generated Item ID with the Item ID returned by an independent hierarchical browse, then read a value whose source can be distinguished from neighboring nodes. A successful read alone is insufficient if an incorrect generated ID happens to name another valid item.

Test more than one branch. A pattern derived from a single example can hide root-level exceptions, delimiters that change by namespace level, or browse names that differ from the corresponding Item ID segment. Repeat the test after server configuration changes because the template encodes a server convention rather than an OPC rule.

For an older OPC DA 1.0 server, test the complete resolution chain when the mapping begins from an Item ID in the middle of the tree and continues with browse paths. If navigation fails, use direct Item IDs for the affected fixed nodes, root the mapping differently, or use a verified Item ID template within a compatible scope.

FAQ

What happens if the Item ID template is wrong?

Live mapping generates an incorrect or nonexistent child Item ID. Compare the generated identifier with the Item ID returned by browsing and verify the read against a distinguishable source value.

What happens if I use $(ParentNodePath) with OPC DA?

$(ParentNodePath) is specified only for OPC XML-DA. For other OPC DA connections, base the decision on $(ParentItemID), $(BrowseName), direct Item IDs, or browse paths.

What happens if Kepware nodes are directly under the root?

The example $(ParentItemID).$(BrowseName) excludes nodes immediately below the root. Browse those nodes separately and use their returned Item IDs or a separately verified mapping rule.

When should I stop troubleshooting DAItemIdTemplate mapping?

Stop changing templates when browsed Item IDs do not form one repeatable rule, when an OPC DA 1.0 server cannot traverse the chosen mixed root and browse path, or when generated IDs differ from browse results. Capture the endpoint configuration, mapping scope, returned parent and child identifiers, browse names, and client diagnostics, then escalate through the product manufacturer’s official support channel.

Back to blog