5  OPC UA: Models, Services, and Trust

Address Spaces, Secure Channels, Sessions, Subscriptions, Pub/Sub, Companion Models, and Gateway Boundaries

industrial-protocols
opc-ua
protocol-integration
security
information-models
Keywords

OPC UA, industrial interoperability, address space, secure channel, subscriptions, PubSub

5.1 Start With the Tag Someone Must Trust

Imagine an operator screen showing a motor temperature that will decide whether a line keeps running. A flat tag value is not enough. The reviewer needs to know which machine object owns the value, which unit and quality state came with it, which certificate protected the session, and which role was allowed to read or change related nodes.

OPC UA is useful when that trust story matters. Start with the value someone must act on, then make the model, service path, session, and authorization evidence visible before the integration becomes a pile of NodeIds.

5.2 Overview: OPC UA Is a Model, Service, and Trust Architecture

OPC UA is not just a replacement wire format for industrial tags. Its core value is that an industrial system can expose a typed address space, let clients discover that model through services, and protect access through certificates, secure channels, sessions, user identity, and authorization.

For example, a packaging line can publish a flat temperature value through many protocols, but OPC UA can also show where that value lives in the equipment model, which unit and engineering range it uses, which machine object owns it, which method can reset an alarm, and which role may call that method. A useful review therefore asks more than “Can the client read the number?” It asks whether the Browse path, namespace record, DataValue quality, timestamp source, endpoint policy, server certificate, user identity, and authorization rule all support the same operational story.

That is why OPC UA is often chosen when semantic interoperability matters. It costs more design effort than a simple register map, but it can reduce fragile custom mapping if the team treats the address space and trust configuration as release artifacts rather than as default server output. The same record also gives operations a stable checklist when a server certificate, namespace, companion model, or gateway mapping changes later.

OPC UA Client-Server Architecture: Unified Architecture for Industrial Communication, OPC UA Server, Address Space, Object, Node, Variable, Node, Method, Node
OPC UA Client-Server Architecture

Information Model

The server exposes Objects, Variables, Methods, Types, References, namespaces, and data types in an address space that clients can browse.

Application Services

Clients use services such as Browse, Read, Write, Method, Subscription, MonitoredItem, Event, and Pub/Sub according to the workload.

Trust Record

Production readiness depends on endpoint policy, certificates, trust lists, user authentication, authorization, and renewal ownership.

OPC UA address-space evidence record showing objects, variables, methods, types, references, namespace records, and review questions.
The address space is where OPC UA carries industrial meaning, not just values.

5.3 Practitioner: Record the Session Path Before Release

A normal OPC UA client-server path includes endpoint discovery, secure-channel setup, session creation, session activation, and application services. Each stage can fail for a different reason, so the release record should name the stage and the evidence captured there.

A practical acceptance test should walk the whole path with the identity that production will use. Record the endpoint selected from discovery, the chosen security mode and policy, the server certificate that was trusted, the client certificate or user credential presented, the Browse paths used to find nodes, and a small set of Read, Write, Method, Subscription, and Event operations. Include at least one denied operation on purpose. That failed call is valuable because it proves the session is not simply connected; it is constrained by the intended role and node permissions. The same packet should name who renews certificates and who approves model changes.

OPC UA workflow from endpoint discovery to secure channel, session activation, Browse or Read or Write or Method calls, subscriptions, monitored items, and close session.
The OPC UA service path is a workflow, not a single socket connection.
Review Area
Evidence To Store
Why It Matters
Endpoint And Channel
Endpoint URL, selected security policy, mode, server certificate, and trust-list result.
Proves the client selected an approved server endpoint instead of accepting whatever was reachable.
Session And Identity
User identity method, session activation result, role mapping, and denied-access evidence.
Separates transport reachability from authorized application access.
Services
Browse paths, Read/Write scope, Method call rules, Subscription and MonitoredItem behavior.
Shows how the integration uses OPC UA services rather than hard-coded private assumptions.
Lifecycle
Certificate renewal owner, namespace/version record, rejected-certificate review, and model-change process.
Keeps the integration maintainable after the first successful connection.
OPC UA security trust record connecting certificate authority, server certificate, client certificate, trust lists, user identity, roles, policy, and renewal operations.
A security mode without a trust-list and lifecycle record is incomplete production evidence.

Gate before production: unsecured or lab-only endpoints need explicit exception records and compensating controls. Network placement alone is not a security design.

5.4 Under the Hood: Pub/Sub, Gateways, and Companion Models Preserve or Lose Semantics

OPC UA can expose client-server services, Pub/Sub datasets, and gateway translations into MQTT, AMQP, HTTP, storage APIs, or analytics systems. Those boundaries are useful only when the integration records what semantic context survives the transfer.

Suppose a gateway republishes OPC UA machine state into a broker topic for analytics. The downstream message may carry the numeric value, but lose the node’s namespace, Browse path, engineering unit, status code, source timestamp, role restriction, or companion-model type unless the mapping records them deliberately. A boundary review should therefore name the exported nodes, dataset fields, schema owner, quality mapping, timestamp choice, command path, and interruption behavior. It should also say what is intentionally not exported, such as write methods or maintenance-only events, so subscribers do not infer controls that the gateway never preserved. This matters during audits and incident response: teams need to know whether a surprising value is stale, translated, denied, disconnected, or genuinely measured at the machine. Without that evidence, a clean broker message can hide a broken source model just as easily as a failed sensor. The record should be reviewed with both OT owners and downstream data owners.

OPC UA Pub/Sub and gateway boundary map showing publishers, datasets, message mapping, brokers, subscribers, and gateway translation records.
Gateway and Pub/Sub boundaries need explicit records for exported nodes, datasets, status, timestamps, units, and command behavior.

Pub/Sub Boundary

Record datasets, message mapping, publisher identity, subscriber expectations, and interruption behavior.

Gateway Boundary

When translating into another protocol, preserve quality, timestamps, units, source identity, and schema ownership deliberately.

Companion Model Boundary

Companion specifications and local extensions define domain semantics beyond the base OPC UA modeling framework.

OPC UA companion model review showing base address space, domain companion model, local extension, conformance evidence, and client contract.
Base OPC UA gives the modeling framework; companion models and local rules give domain meaning.
OPC UA review risk record showing risks: tag list only, security exception, hard-coded NodeIds, gateway context loss, companion model skipped, and lifecycle owner missing.
The common failure mode is treating OPC UA as proof of interoperability while skipping the evidence that makes it durable.

5.5 Summary

OPC UA is strongest when the design treats it as a model, service, and trust architecture. The review should prove the address-space structure, service-set use, secure-channel and session setup, certificate and authorization operations, Pub/Sub or gateway boundary behavior, companion-model semantics, and lifecycle evidence.

If those records are missing, the integration may still move values, but it has not yet proven durable industrial interoperability.

5.6 Key Takeaway

OPC UA integration should preserve industrial meaning, not just move bytes. Production evidence must connect the address space, service path, trust record, gateway boundary, and lifecycle owner.

5.7 See Also