OPC UA Information Model, Services & Security Boundaries

OPC Unified Architecture is not just a replacement wire format for reading tags. It defines a graph-shaped information model, a set of services that operate on that graph, mappings to encodings and transports, and security relationships between applications and users. A connection can be syntactically valid while still lacking semantic interoperability: both sides must also agree on types, references, units, states, capabilities, and companion specifications.

The address space is a typed graph #

Every exposed entity is a Node with attributes and a NodeId. Typed References connect nodes. This graph can state that a pump has a discharge-pressure variable, that the variable has engineering units, that the pump is an instance of a particular equipment type, and that a reset method belongs to that object.

The principal NodeClasses are:

Properties are variables connected with a specific property relationship; they are not an unrelated key/value store. A variable's Value is one attribute among others such as DataType, ValueRank, and access levels.

Identity and names #

A NodeId combines a namespace index with an identifier. The numeric namespace index is assigned for a particular server session/configuration; portable clients should resolve the namespace URI and then construct or translate NodeIds appropriately. A BrowseName helps navigate within a naming context, but is not guaranteed to be a globally stable identity. A DisplayName is human-facing and may be localized.

This yields three different client strategies:

1. configured identity: store server-specific NodeIds together with namespace URI and configuration version;
2. browse-path discovery: begin at known objects and follow expected references and BrowseNames;
3. type-driven discovery: locate nodes by standard or companion-model types and semantic relationships.

The third is the strongest route to reusable integration, but only when the server faithfully implements the shared model.

Services operate on the graph #

UA service sets cover discovery and secure communication as well as address-space operations. Common application operations include:

• Browse / TranslateBrowsePaths: discover nodes and relationships;
• Read / Write: access attributes, most visibly variable values;
• Call: invoke a method on an object;
• CreateMonitoredItems / CreateSubscription: configure change detection and delivery;
• HistoryRead / HistoryUpdate: access historical data where supported;
• RegisterNodes: allow a server to optimize repeated access without changing node identity.

A service result and per-operation status codes must both be checked. A network-successful response can contain bad results for individual nodes. Clients should preserve StatusCode instead of coercing every bad or uncertain value into a default numeric value.

DataValue: value plus evidence #

Reading a variable normally yields a DataValue that can contain:

• the value;
• a status code describing quality or uncertainty;
• a source timestamp assigned close to the data source;
• a server timestamp describing when the server received or knew the value.

Those timestamps answer different questions. Source time is the best available estimate of when the process value was acquired; server time describes the server's processing context. Arrival time at the client is a third time and should not silently replace either one. Clock synchronization and timestamp capability still need to be engineered.

Monitored items and subscriptions #

A MonitoredItem defines what to observe, how often to sample, what filter to apply, queue size, discard policy, and monitoring mode. A Subscription groups monitored items and controls publishing, keep-alives, lifetime, and notification delivery.

Sampling interval and publishing interval are therefore not synonyms. A server may sample a value more often than it publishes notifications. A data-change filter can suppress changes below a deadband. The monitored-item queue determines whether multiple changes between publish cycles are retained or overwritten; its discard policy decides which end of a full queue is lost.

Sequence numbers, acknowledgements, retransmission queues, and republish support help a client detect and recover notification gaps within the server's retained window. They do not turn an undersized queue, expired subscription, or disconnected server into lossless history. Durable historical requirements belong in a historian or another explicitly persistent mechanism.

Secure channel, session, and user are separate #

A server certificate identifies an application instance, not the human operator. A trusted application must still present an authorized user identity where required. Conversely, a valid username sent through an untrusted or unprotected endpoint does not establish a secure system.

Security mode None provides no message signing or encryption. A deployment that requires authenticity, integrity, or confidentiality must choose compatible secure policies/modes, validate certificates and endpoint identity, manage trust lists and private keys, and remove insecure endpoints or explicitly isolate their use. Copying every discovered certificate into a trust store is not certificate validation.

Profiles and companion models #

The specification is deliberately modular. Profiles declare supported features and services; clients should select required capabilities rather than assume every server implements every optional behavior. Companion specifications define reusable domain types and semantics. They are what let two systems agree that an object is a pump with a standardized structure instead of merely agreeing that node ns=4;i=1712 contains a number.

When no shared companion model exists, write an integration contract covering namespace URIs, types, units, status handling, method semantics, event fields, permissions, and versioning. Browsing a tag tree is discovery, not semantic agreement.

Diagnostic workflow #

1. Record the endpoint URL, selected transport profile, security policy/mode, server certificate identity, and authenticated user.
2. Resolve namespace URIs; do not assume namespace indexes are stable across servers or restores.
3. Browse from a known node and inspect NodeClass, type definition, data type, value rank, and references.
4. Read a DataValue including status and both timestamps, not value alone.
5. For subscriptions, log revised sampling/publishing values, queue parameters, sequence gaps, and keep-alive/lifetime behavior.
6. Check per-operation status codes and diagnostic information.
7. Verify the required profile and companion-model conformance with representative objects and failure cases.