In-Depth Analysis of the OPC UA Protocol: From Background, Development, Principles to Configuration Hands-On

Introduction: Why OPC UA Became the "Standard Language" of the Industrial Internet Era

Industry 4.0 and the Industrial Internet of Things connect automation systems that previously exchanged data through separate vendor interfaces. Integration requires more than moving bytes: applications need to agree on data meaning, update behavior and security. OPC UA (Open Platform Communications Unified Architecture) addresses this through a platform-independent architecture with an information model, services and defined communication mappings. Modbus, PROFIBUS and other installed protocols remain useful for their intended tasks; a gateway may be needed to map their device data into an OPC UA model.

OPC UA combines interoperable information models, application security mechanisms and implementations ranging from embedded devices to enterprise systems. Companion specifications can give equipment from different vendors a shared vocabulary. Certificates, security policies, user authorization and operational trust management still need to be configured correctly. A production line can expose PLC measurements to supervisory and maintenance applications through a documented model; the actual benefit depends on the devices, mappings and deployment. Compatibility, installed-base totals, market forecasts and named-factory performance should not be inferred from the architecture.

In short, OPC UA is not just a technical protocol but the "universal grammar" of industrial digitalization, enabling machines to "converse" as efficiently and securely as humans, driving the leap from "automation" to "intelligence."

An industrial router can carry traffic between a PLC network and a supervisory application without understanding the values inside an OPC UA message. A gateway or PLC may host the OPC UA server, while a client elsewhere reads or subscribes to its data. These roles must be identified before anyone claims the router “supports OPC UA.” Transporting packets, exposing an endpoint and translating another protocol into OPC UA are different functions.

OPC UA Background and Development History

The Birth of OPC Classic

OPC Classic emerged to reduce the need for separate Windows drivers and interfaces for each automation vendor. It used Microsoft COM/DCOM to standardize communication between industrial applications. The principal Classic specifications addressed live data, historical data and alarms/events:

• DA (Data Access): Real-time reading/writing of variables, supporting subscription mechanisms.

• HDA (Historical Data Access): Historical data query and aggregation.

• AE (Alarms & Events): Event and alarm notifications.

OPC Classic became established in SCADA and DCS installations. Its dependence on COM/DCOM made deployment across operating systems and network boundaries more difficult. DCOM provides its own authentication and access controls, so Classic should not be described as having no authorization or encryption. OPC UA was designed to remove that Windows dependency and provide a common address space, services and communication security model suited to a wider range of systems.

Table Comparison: OPC Classic vs. Modern Requirements

Aspect	OPC Classic context	OPC Classic constraint	OPC UA distinction
Platform	COM/DCOM interfaces were designed for Windows environments.	Cross-platform deployment can require additional integration work.	The specification is designed for platform-independent implementations; supported profiles vary by product.
Data access	DA, HDA, and AE address variable access, history, and alarms/events.	The Classic specifications do not use the OPC UA AddressSpace information model.	UA services and information models support structured data and relationships; companion models are application-specific.
Security	Security relies on the applicable COM/DCOM, operating-system, and site configuration.	Security behavior depends on deployment and configuration.	UA defines application and communication security mechanisms; endpoints and users must configure and verify them.
Extensibility	Classic interfaces serve their defined data-access use cases.	Connecting to other applications may require gateways or mappings.	UA supports extensible information models and client/server or PubSub patterns where implemented.

From OPC Classic to a cross-platform architecture

OPC Classic used Microsoft COM/DCOM for data access in Windows systems. OPC UA, standardized in the IEC 62541 series, defines an address space, services and communication mappings without depending on that Windows mechanism. Moving to UA is therefore more than opening a port: identify which PLC, gateway or server publishes the data, which client consumes it, and how the older tag names and meanings map into the new address space. A router can carry the connection, but it does not create that mapping by routing alone.

The Proposal and Vision of OPC UA

The OPC Foundation developed OPC UA as the successor to the Classic specifications. The goal was a unified architecture that could represent industrial information and expose services independently of Windows COM/DCOM. Its vision was to expand standardized communication across devices, operating systems and enterprise applications:

• Platform independence: define the address space and services independently of a particular operating system, implementation language or COM/DCOM runtime.

• Semantic exchange: describe values with types, attributes and relationships so consumers can interpret their meaning.

• Unified services: support discovery, current and historical data, methods, events and subscriptions where the server implements the relevant capabilities.

This approach supports integration between control systems and applications such as MES, maintenance and enterprise information systems. Adopting UA still requires a defined information model, compatible application capabilities and tested mappings from existing tags. A protocol choice alone does not establish a particular reduction in integration time.

International Standardization and Ecosystem Development

OPC UA is standardized in the IEC 62541 series. The specifications cover the architecture, security, address space, services, information model, mappings and additional capabilities. The OPC Foundation ecosystem includes automation suppliers, software developers, users and organizations defining domain models. Use the current published specification versions for a project rather than assuming one historical part count or membership total describes the whole ecosystem.

• Companion specifications: industry groups define common models for equipment and applications, such as machinery and automatic identification. Verify the exact model and version supported by both applications.

• Deployment: factories, utilities and other industries use OPC UA for data integration; a country-wide installed-base figure cannot be inferred from the standard.

• Open-source implementations: projects such as open62541 make UA implementation available to developers. Platform support, features and conformance depend on the selected release and build.

Interoperability requires agreement on profiles, services, information models and security settings. Conformance testing and OPC Foundation certification can provide evidence for a defined product scope, but do not replace testing the actual client, server and application requirements together.

Table: Key Milestones

Milestone	What the supplied specification sources establish	Engineering significance
OPC Classic	Windows COM/DCOM-based specifications include DA, HDA, and AE.	Legacy systems may need an explicitly configured gateway or data mapping.
OPC UA	A unified architecture defines services, information models, encodings, and mappings.	Platform support does not remove the need to check profiles and device models.
IEC 62541	OPC UA is published as a multipart IEC specification series.	Use the relevant part and version for the feature being implemented.
Version 1.04	The official Part 1 history lists version 1.04 as published on 2017-11-22.	Feature support must be checked against the applicable specification version and product profile.
Version 1.05.06	The supplied Part 1 history lists version 1.05.06 as published on 2025-10-22.	This is the version recorded in the supplied source snapshot, not a guarantee that every product implements it.
PubSub, TSN, and AI-related models	The supplied PubSub specification defines PubSub models and mappings; the sources do not establish universal product support, performance, or a release date for every integration theme.	Treat these as features or topics to evaluate against the selected specification and implementation.

Overall Architecture of OPC UA

Future-Oriented Cross-Platform Architecture

OPC UA employs a Service-Oriented Architecture (SOA), with the core being an abstraction layer ensuring independence from OS/hardware. Key components:

• Application and information model: implement business logic, nodes, values and the service behavior exposed to other applications.

• Implementation or SDK: provides APIs and platform integration; .NET, Java, C/C++ and other language choices are implementation options rather than mandatory protocol layers.

• Communication mappings: select the encodings, security and transport profiles actually supported by the communicating applications.

UA implementations can run on embedded controllers, edge computers and enterprise or cloud systems when the required resources and profiles are available. Cross-platform support does not by itself create a zero-trust deployment. Compared with a generic HTTP API, UA defines an industrial address space, services and information-model conventions; the implementation must still manage identities, state and access permissions.

OPC UA defines an information model and services for discovering, reading, writing and subscribing to data. The OPC Foundation overview distinguishes the architecture from a particular network appliance. In a common client/server deployment, an OPC UA server exposes an endpoint and a client establishes a session to it. Other OPC UA communication patterns exist, so confirm the actual application profile rather than assuming every deployment uses the same path.

Draw the path from client to server: address and port, DNS or VPN endpoint, router interfaces, firewall, NAT, and any gateway. If a Modbus device sits behind a gateway, the gateway must map registers and meanings into its OPC UA model; the router's IP forwarding alone does not do that. The Modbus guide explains the separate register and transport questions.

Component	Role to verify	Evidence
PLC or gateway	Server endpoint, namespace, NodeIds and update behavior	Client can browse and read the intended values
Industrial router	IP path, segmentation, NAT/VPN and allowed direction	Authorized client reaches only the intended endpoint
OPC UA client	Trust settings, session and subscription behavior	Reads, writes or alarms meet the application requirement
Operations team	Certificates, logs, backups and recovery owner	Trust and application service recover after a planned fault

IP routing can carry OPC UA traffic; it does not automatically create an OPC UA server or convert another protocol.

Communication Stack Structure

OPC UA can be understood through applications and information models, services, data encodings, security mechanisms and transport mappings. These are not a mandatory seven-layer OSI stack. Keep the UA application model separate from the underlying network and physical connections:

1. Application and services: model industrial information and perform operations such as Browse, Read, Write, Call and subscription management.

2. Data representation: use the encodings defined for the chosen mapping and profile; UA Binary, XML and JSON serve different specified purposes.

3. Communication mapping: select a supported Client/Server or PubSub transport and its message/security rules.

4. Underlying network: TCP/IP, UDP/IP, Ethernet and physical or wireless media provide connectivity according to the selected mapping. They are not additional UA service layers.

5. Security: application identity, secure-channel or message protection and user authorization must be considered with the chosen communication pattern.

Latency and real-time behavior depend on the applications, encoding, transport, network engineering, device load and configuration. TSN or a particular transport profile can be part of a designed system, but choosing OPC UA does not guarantee a fixed end-to-end latency.

Table: Communication Stack Layer Details

Concern	OPC UA concept	Example	Validation
Application	Client/server services or PubSub information exchange.	Browse and Read services; publisher DataSet messages.	Confirm the server or PubSub profile implements the required behavior.
Information model	Nodes, Attributes, and References describe data and relationships.	A Variable represents a value with a DataType and other Attributes.	Use the device model and namespace URI; do not infer meaning from a name alone.
Encoding	The selected mapping defines how messages are encoded.	UA Binary or JSON in applicable mappings.	Check the mapping and endpoint; do not assume every encoding is supported.
Transport	Mappings carry OPC UA messages over supported transports.	OPC UA TCP for client/server; specified UDP, Ethernet, or broker mappings for PubSub.	Check the advertised endpoint or PubSub profile and product support.
Security	MessageSecurityMode, SecurityPolicy, user identity, certificates, and network controls serve different purposes.	SecureChannel message protection or supported TLS mapping.	Configure each layer as required; none alone proves end-to-end protection.

Information Model and Data Organization

The information model uses nodes, types, attributes and references to describe industrial information. XML NodeSet files can exchange model definitions; XML is not the only runtime data representation. Core modeling concepts include:

• Object: represents an entity or groups information, such as a device.

• Variable: exposes a typed Value with associated attributes, such as DataType and ValueRank.

• Method: exposes a callable operation with defined input and output arguments.

• Reference: relates nodes using a ReferenceType; relationships may be hierarchical or non-hierarchical.

The AddressSpace is a graph of nodes and typed references. A client often browses a hierarchical view of that graph, but nodes can participate in more than one relationship. BrowseName, DisplayName, Description, types and references help a consumer locate and interpret information; a display label alone is not a stable NodeId.

Core Technical Features of OPC UA

Security Framework (Authentication, Encryption, Authorization)

OPC UA defines its own application security model and communication mappings. For a Client/Server deployment, assess application authentication, message protection and user authorization separately:

• Application authentication: validate the peer application certificate and its identity, trust chain, validity and relevant certificate checks for the selected endpoint.

• Message protection: select a compatible SecurityPolicy and MessageSecurityMode. Algorithms and key sizes are defined by that policy, not by one universal AES/SHA combination.

• User authentication and authorization: choose a supported user token and grant the account only the required node/service permissions. Application-certificate trust is a separate decision.

• Operations: maintain trust lists, certificate renewal and revocation information, logs and audit behavior as supported by the products.

MessageSecurityMode selects None, Sign or SignAndEncrypt. SecurityPolicy specifies the security algorithms and related rules; Basic256Sha256 is a policy name, not a fourth message mode. Choose a mutually supported policy and mode appropriate to the deployment. OPC UA security options do not automatically establish IEC 62443 compliance. MQTT security also depends on its deployment, transport protection and application authorization, so a protocol name alone is not a security rating.

Table: Security Mode Comparison

Setting	What it controls	Protection/behavior	Validation
MessageSecurityMode: None	No SecureChannel message signing or encryption.	Provides no message-level confidentiality or integrity.	Use only where the deployment and endpoint policy permit it.
MessageSecurityMode: Sign	Signs messages.	Provides message integrity/authentication; it does not encrypt message contents.	Verify certificates, SecurityPolicy, and endpoint support.
MessageSecurityMode: SignAndEncrypt	Signs and encrypts messages.	Provides message integrity and confidentiality at the supported SecureChannel.	Verify both endpoints, certificate trust, and selected policy.
SecurityPolicy, e.g. Basic256Sha256	Selects the security algorithms and related requirements; it is not a MessageSecurityMode.	The allowed combinations and current recommendations depend on specification/profile version.	Select from endpoint support and current security guidance; do not combine settings by label alone.

A working TCP connection is not yet a trusted OPC UA session.

Check the server endpoint, supported security policies, application certificates, trust lists and user authentication against the products' current documentation. The OPC UA security model describes these concepts; it does not certify a particular router or gateway. Plan certificate renewal and revocation before a remote site is left unattended.

SecurityPolicy, MessageSecurityMode, application-certificate trust and user permissions are separate settings. Verify all four.

Services Mechanism

OPC UA groups related operations into Service Sets. Clients use supported services for discovery, sessions, data access, methods and subscriptions; the exact capabilities depend on the server profile and configuration:

• Discovery: find servers and query their endpoint descriptions and supported security options.

• SecureChannel and Session: establish protected application communication where configured, create a session and activate it with an allowed user identity.

• Read and Write: access node attributes such as a Variable Value when the server permits it; historical access uses HistoryRead and HistoryUpdate rather than ordinary Read/Write.

• Subscriptions and MonitoredItems: monitor data changes or events with sampling, queueing and publishing behavior; a subscription is not limited to events.

• Call: invoke an exposed Method with the required arguments and permissions.

Services use a request-response model with standardized error codes (BadNodeIdUnknown, etc.).

Information Modeling

OO modeling supports inheritance/composition:

• Type definitions: ObjectType and VariableType Nodes define types for Objects and Variables; DataType Nodes define value types. These NodeClasses are not themselves the names of specific base types.

• Instances: Objects and Variables instantiate the relevant model types; Methods represent operations with defined arguments and permissions.

• Extensions: register application namespaces and use applicable companion specifications, such as models for automatic identification, at versions supported by both applications.

Information models make the structure and meaning of data explicit. Consumers can use supported companion models and metadata to interpret it. This can help analytics or AI applications, but the presence of UA data does not by itself guarantee that a consumer understands an unfamiliar model.

Table: Modeling Element Types

Element Type	Description	Attributes / related properties	Access/relationship example
Object	Represents an entity or grouping.	BrowseName, DisplayName, EventNotifier	Browse and Read its Attributes; it may have component or organization References.
Variable	Represents a value.	Value, DataType, ValueRank, AccessLevel	Read; Write only when writable and authorized; monitor through a MonitoredItem where supported.
Method	Represents a callable operation.	Executable, UserExecutable; InputArguments and OutputArguments are Properties	Call the Method when present and permitted.
ReferenceType	Defines how Nodes are related.	IsAbstract, Symmetric, InverseName	Examples include Organizes, HasComponent, and HasSubtype.
DataType	Defines the type of a Variable value.	IsAbstract, DataTypeDefinition where defined	Read or Browse the relevant Node; it does not use GetEndpoints.
View	Defines a subset or projection of the AddressSpace.	View-specific Attributes	Browse within the View when the server supports it.

Data Transmission Modes (Client/Server, Pub/Sub)

• Client/Server: a client uses services to browse, read, write, invoke methods or establish subscriptions with a server. It supports both configuration and continuous monitoring where the relevant functions are implemented.

• PubSub: publishers produce DataSet messages for subscribers through a supported transport and message mapping. Reader/writer metadata, identifiers, delivery behavior and security require their own configuration. PubSub is specified in Part 14; it is not an RTPS/DDS compatibility claim.

PubSub can distribute selected DataSets to multiple consumers without each consumer maintaining the same Client/Server subscription path. Client/Server subscriptions also avoid repeated application-level polling of every value. Compare fan-out, update requirements, metadata, recovery and security for the actual deployment instead of assuming PubSub always uses less bandwidth.

Table: Transmission Mode Comparison

Mode	Communication pattern	What it can provide	Selection / validation
Client/server	A client invokes services on a server.	Discovery, browsing, on-demand access, methods, subscriptions, and other supported services.	Check endpoint profile, server limits, user permissions, and measured load.
PubSub	Publishers send configured DataSet messages to matching subscribers.	One-to-many distribution over a supported PubSub transport and mapping.	Check metadata, update schedule, transport, reader matching, security, and network behavior.

Choose client/server or PubSub for the actual task

In the usual client/server pattern, a client discovers an endpoint, establishes a secure channel and session, then browses, reads or creates subscriptions for monitored items. OPC UA PubSub is a separate publishing pattern with its own transport, security and subscriber configuration. It does not turn every client/server endpoint into a broker or multicast publisher. Document which pattern the exact server and client support before designing routes, firewall rules or WAN recovery. For a central SCADA client reading a few known nodes, begin with the documented client/server path.

OPC UA Address Space and Node Model

The AddressSpace is a graph with a standard RootFolder (ns=0;i=84). Its standard children include ObjectsFolder (ns=0;i=85), TypesFolder and ViewsFolder. A NodeId combines a namespace index and a numeric, string, GUID or opaque identifier. Namespace 0 is reserved for standard definitions; application namespaces must be registered by the server. Store the namespace URI and resolve its index in that server instead of treating an index such as ns=2 as portable. The NodeClasses are:

• Object: Organization.

• Variable: Data.

• Method: Operation.

• ObjectType/VariableType: Templates.

• DataType/ReferenceType: Definitions.

• View: Sub-views.

Browse and BrowseNext navigate references in the AddressSpace; Read obtains attributes and Call invokes Methods. References such as Organizes, HasComponent, HasProperty and HasSubtype express different relationships. A PLC may be represented by an Object with Variables and Methods, but browsing its representation does not establish that every Value is current or writable.

Table: Node Class Details

NodeClass	Attributes / related properties	Reference examples	Typical service use
Object	BrowseName, DisplayName, EventNotifier	Organizes, HasComponent, HasProperty	Browse and Read supported Attributes.
Variable	Value, DataType, ValueRank, AccessLevel	HasProperty, HasComponent	Read; Write only if supported and permitted; monitor with a MonitoredItem.
Method	Executable, UserExecutable; InputArguments and OutputArguments are Properties	HasComponent, HasProperty	Call when the Method exists and authorization allows it.
ReferenceType	IsAbstract, Symmetric, InverseName	Organizes, HasComponent, HasSubtype	Browse the relationships defined by the model.
DataType	IsAbstract, DataTypeDefinition where defined	HasSubtype	Describes a Variable value type; it is not accessed with GetEndpoints.
View	View-specific Attributes	Organizes and model-defined References	Browse the subset when supported by the server.

Agree on the data model as well as the link. Record namespace URI, NodeIds, engineering units, quality/status, timestamps and whether a value may be written. A successful browse does not prove that a tag is fresh or that a PLC action is safe. Test a known process value against a local reference and define who may issue writes. Use the remote PLC/HMI access guide to keep network access separate from permission to change a machine.

Record namespace, NodeId and value quality

A NodeId identifies a node in a server address space; it includes a namespace and an identifier that may be numeric or a string. A namespace index can differ between server instances, so retain the namespace URI and the tested NodeId rather than copying a number without context. BrowseName and references help locate a variable, while its DataValue includes the value, status and timestamps supplied by the server. Record the expected data type, engineering unit, scaling and whether the variable may be written. A plausible number with bad status or an old timestamp is not a healthy measurement.

RootFolder is ns=0;i=84 and ObjectsFolder is ns=0;i=85. For application nodes, retain the namespace URI and resolve its index at runtime.

OPC UA Configuration and Hands-On Examples

Basic Configuration

Use the configuration interface or API provided by the selected OPC UA server. Tool names, configuration schemas and supported profiles vary by product and SDK. Begin with these common decisions:

1. Set a stable ApplicationUri for the application instance and make it consistent with the application certificate where certificate-based authentication is used.

2. Configure the intended listening endpoint and hostname, for example opc.tcp://server.example:4840, and confirm that clients can use the address advertised by the server. A vendor-specific path suffix is not universal.

3. Select a mutually supported SecurityPolicy, MessageSecurityMode and user-token type, then configure trust and authorization. Treat an unsecured test endpoint as a deliberate isolated test choice, not a production fix.

After the server starts, inspect its advertised endpoint descriptions with GetEndpoints and a suitable UA client. Verify the endpoint hostname, security policy/mode and user-token options before activating a session and reading a known node. If NAT or remote access is involved, the advertised address must remain usable from the client network.

Table: Basic Configuration Steps

Step	Operation	Tool/command	Notes
1	Record endpoint and application identity	Server documentation or supported client	Confirm the endpoint URL, ApplicationUri, certificate identity, and supported profiles.
2	Resolve the information model	Browse or model configuration tool	Register or read the NamespaceUri and resolve its server-specific NamespaceIndex; do not assume ns=1.
3	Select security and test a known value	Supported OPC UA client	Choose a supported MessageSecurityMode and SecurityPolicy separately; validate certificate trust, user permissions, Browse, and a documented Read.

Verify the exact router firmware's routing, VLAN, VPN and firewall behavior. Avoid opening a public OPC UA port merely to make a demonstration work; use a controlled access path suited to the site. The VLAN guide explains why a broadcast-domain boundary is not, by itself, a complete access policy.

During a bounded test, interrupt the WAN, VPN, router power or OPC UA server one at a time. Record when the client detects failure, whether stale values are marked, how subscriptions or sessions reconnect, and when fresh application data returns. The OPC UA Services specification defines service behavior, while the actual client/server settings determine timeout and retry behavior. A router reconnecting does not prove that the client has resumed a valid subscription.

Document the exact PLC or gateway model, router, firmware, client version, endpoint, trust arrangement, routes and test result. If a product page only says “OPC UA compatible,” request the role, profile, supported functions and a demonstration with the actual endpoint before making it a deployment requirement.

Commission the path in a safe order

Write down the server and client products and versions, endpoint URL, DNS name or VPN peer, listening port, router interfaces, VLANs, routes and firewall policy. Test reachability first, then endpoint discovery, certificate trust, user login, a known read-only node and finally the intended subscription. Record the first failure in this sequence instead of treating a reachable TCP socket as complete OPC UA acceptance. If the server is behind NAT, verify that the advertised endpoint address remains usable from the remote client network.

Security Certificate Configuration

Application instance certificates may be self-signed or issued by a certificate authority. A working setup requires the application to possess its own private key and certificate and to validate the peer according to the configured trust rules. A rejected-certificate directory records rejected certificates; it is not the list of trusted peers. A deployment procedure should cover:

1. Generate or provision the application private key and certificate, or create a CSR for the chosen CA workflow. Protect the private key and maintain the expected application identity.

2. Install the application certificate and relevant trusted peer or issuer certificates in the stores required by the selected SDK. Review a rejected certificate before any explicit trust decision.

3. Choose a mutually supported SecurityPolicy and MessageSecurityMode and perform the supported validity, identity, chain and revocation checks. Basic256Sha256 is a policy name; a suffix such as Basic256Sha256_RSA is not a universal standard setting.

4. Test the configured endpoint and user permissions with a known read-only node. Record how renewal, revocation and trust updates will be handled.

Certificate-configuration logic (illustrative pseudocode, not a runnable .NET SDK configuration):

# Illustrative pseudocode; not a version-specific .NET SDK API
application_uri = "urn:example:opcua:server"
certificate = provision_application_certificate(application_uri)
verify_certificate_identity_and_validity(certificate, application_uri)
trust_lists = configure_trust_lists(
    trusted_peers=validated_peer_certificates,
    trusted_issuers=validated_issuer_certificates,
    rejected_store=separate_store_for_rejected_certificates
)
endpoint = select_advertised_endpoint(
    security_policy=supported_policy,
    message_security_mode=supported_mode,
    user_token_policy=supported_user_token
)
# Keep certificate validation enabled; resolve identity, trust, and revocation failures.

Distribute public certificates, trust anchors and revocation information through the approved product-specific workflow or supported management service. Do not copy private keys to peer trust stores. A directory copy or LDAP connection alone does not verify the peer identity or establish a safe trust decision.

Table: Certificate Management Best Practices

Practice	Description	Timing	Tool/record
Provision application certificate	Verify ApplicationUri, certificate identity, key protection, and required endpoint names.	Initial setup and replacement according to PKI/device policy.	Site PKI or supported certificate-management workflow.
Exchange trust	Validate identity, validity, chain, and intended peer before adding it to the appropriate trust list.	Before establishing trust and whenever trust changes.	Documented trust-list or GDS workflow.
Renew and check revocation	Renew/reissue before expiry according to certificate policy; check revocation when supported and required. Expiry and revocation are distinct.	According to validity period, risk, and PKI policy; no universal 90-day or annual interval.	Certificate inventory and supported CRL/OCSP process.
Audit	Record certificate, channel, and application errors using the implementation’s supported diagnostics.	During commissioning and ongoing operations.	Server/client diagnostics and site logging.

Treat certificates and user permissions as separate checks

Inspect the server’s advertised endpoint and supported security policy and message security mode. With certificate-based application authentication, client and server must validate identities and maintain the appropriate trust and rejection stores; user credentials or role permissions are a further layer. Do not solve an untrusted-certificate error by disabling validation or accepting an unknown certificate. Confirm the endpoint hostname, certificate validity, trust decision and the account’s permission for the specific node. Plan certificate renewal and trust-store updates before expiry so a routine replacement does not stop collection.

The rejected certificate store is not a trust list. Verify identity, validity and trust before approving a certificate; do not disable validation to hide an error.

Server and Client Configuration Examples

Server example (illustrative pseudocode, not compilable open62541 C): expose a temperature Variable in a registered application namespace. Use the chosen SDK version for the actual API calls and lifecycle.

# Illustrative server pseudocode; SDK calls and types vary by version
application_uri = "urn:example:opcua:server"
model_namespace_uri = "urn:example:temperature-model"
namespace_index = server.register_namespace(model_namespace_uri)
objects_folder = NodeId(namespace_index=0, identifier=85)  # ObjectsFolder
temperature_node = server.add_variable(
    parent=objects_folder,
    reference_type="Organizes",
    node_id=NodeId(namespace_index, "Temperature", type="String"),
    browse_name=QualifiedName(namespace_index, "Temperature"),
    data_type="Int32",
    value=initial_temperature
)
set_access(temperature_node, read=True, write=False)
start_server(advertised_endpoint, application_uri, application_certificate)
# Enable a write only in a separately approved use case with explicit permissions.

The example registers an application namespace and adds a Variable beneath the standard ObjectsFolder using an appropriate reference. A value, data type and access rights are configured explicitly. The server must still have its endpoint, application certificate, user authentication and permissions configured for the intended deployment.

Client example (illustrative pseudocode, not a runnable Python SDK example): resolve the same namespace URI and read the configured NodeId. A write is deliberately excluded from the initial test.

# Illustrative client pseudocode; not a version-specific Python API
client = connect_to_advertised_endpoint(endpoint_url, supported_security_settings)
subscription = None
try:
    namespace_index = resolve_namespace_index(client, "urn:example:temperature-model")
    node_id = NodeId(namespace_index, "Temperature", type="String")
    data_value = read_value_and_quality(client, node_id)
    verify_value_status_and_timestamps(data_value, expected_process_value)
    subscription = create_subscription(client, publishing_interval=application_setting)
    subscription.add_monitored_item(node_id)
    process_notifications_until_planned_test_completes(subscription)
finally:
    if subscription is not None:
        close_subscription(subscription)
    disconnect(client)
# This initial test is read-only; an approved write requires a separate step.

For a data-change test, create a Subscription with the chosen client SDK, create a MonitoredItem for the tested Variable and process notifications. Check the returned status and any revised sampling/publishing settings. SDK subscription APIs differ; after a controlled interruption, verify reconnect/session/subscription recovery and the first fresh DataValue.

Make the tested value auditable

Choose one read-only node whose physical or controller value can be checked independently. Save its namespace URI, NodeId, data type, unit, status, source timestamp and server timestamp where available. Compare a live value and a deliberately changed value before adding a large subscription list. If a Modbus-to-UA gateway is involved, keep the original register, function, signedness, scale and byte order with the UA mapping. This distinguishes an IP path problem from a tag that is present but interpreted incorrectly.

Observe subscriptions through an interruption

A subscription contains monitored items and publishing settings; a client session and secure channel are also involved. After a WAN or VPN interruption, the client may need to reconnect, restore a session or recreate subscriptions according to product behavior and outage length. Test one controlled interruption at a time. Measure when the client reports loss, whether its UI marks stale values, when the connection returns and when the first fresh value arrives. Do not assume that router failover preserves an existing TCP session or that a reconnected socket restores monitored items.

Diagnose by the layer that failed

No TCP connection points to endpoint naming, carrier path, route, firewall or listener. A connection followed by a certificate or user error points to trust, identity or permissions. A successful session with BadNodeIdUnknown suggests the wrong namespace or NodeId; a good value with an old timestamp suggests server acquisition, gateway mapping or client cache. Keep a capture of the endpoint, status code and tested node, with sensitive credentials excluded. This makes the next repair specific and avoids weakening security to hide a routing or modeling fault.

Pub/Sub Configuration Example

A PubSub configuration connects a PublishedDataSet and DataSetWriter on the publisher to a compatible DataSetReader and target mapping on the subscriber. The following is illustrative pseudocode showing the required agreements; it is not a UANodeSet XML file, a UADP message or an importable product configuration:

# Conceptual PubSub configuration outline; not XML or a runnable configuration file
publisher:
  connection: select_supported_transport_and_address()
  writer_group:
    publishing_interval: configured_for_application
    message_mapping: UADP_or_JSON_as_supported
    security: configure_policy_mode_and_security_group_if_required
    data_set_writer:
      writer_id: configured_unique_identifier
      data_set: select_fields_from_address_space()
      metadata: publish_or_provision_matching_data_set_metadata()
subscriber:
  connection: match_transport_and_address()
  reader_group:
    data_set_reader:
      publisher_id: match_publisher()
      writer_group_id: match_writer_group()
      data_set_writer_id: match_data_set_writer()
      metadata: match_data_set_schema()

For the chosen transport, configure an address or broker/topic accessible to both sides and match the PublisherId, WriterGroupId, DataSetWriterId, field metadata and target mappings used by the reader. UDP multicast requires appropriate network support and is not automatically routed across a WAN or VPN. PubSub message security uses the configured security mode, policy and group keys; a Security Key Service can distribute keys to authorized group members where supported. Transport security and PubSub message security are separate decisions.

Table: Pub/Sub Configuration Elements

Element	Publisher configuration	Subscriber configuration	Validation/security
PublisherId	Identify the publisher in the configured message mapping.	Match the expected PublisherId when filtering.	Type and encoding are mapping-specific; not an encryption-key binding.
WriterGroupId	Identify the WriterGroup in the NetworkMessage.	Match the expected WriterGroupId where required.	Do not substitute this for a DataSetWriterId.
DataSetWriterId	Identify a DataSetWriter.	Match the expected DataSetWriterId.	It is not generically a “stream ID”; check the selected mapping.
DataSet and metadata	Select fields and provide the DataSet metadata/schema.	Configure matching metadata and field interpretation.	Verify namespace URIs, NodeIds, DataTypes, and field order.
Transport mapping	Select a supported UDP, Ethernet, or broker mapping such as MQTT as applicable.	Configure a matching mapping, address/topic, and reader behavior.	AMQP, TSN, and other options depend on the applicable specification/profile and product support.
Security	Configure supported message security, SecurityGroupId, and SecurityKeyServices when required.	Use compatible security settings and obtain keys from the configured key service.	Validate application certificates, authorization, key rotation, and network controls separately.

Industry Application Scenarios and Case Studies

OPC UA can connect operational data to production, maintenance, quality and energy applications when a suitable information model and data path are implemented. The following are engineering scenarios, not verified results from named customer deployments. Benefits and performance must be evaluated in the actual system.

• Manufacturing: expose PLC and machine data to MES or maintenance applications through a documented model, checking identifiers, units, update status and ownership.

• Energy: integrate measurements and equipment status for supervisory monitoring and analysis, with validated timestamps, units and access policy.

• Pharmaceuticals: exchange equipment and batch-related information for traceability. OPC UA does not by itself establish regulatory compliance or validate a production record.

• Automotive: share machine or robot information with production and maintenance systems. Motion-control, safety and real-time requirements require their own engineered solution.

• Oil and gas: provide remote monitoring through an appropriate server/gateway and controlled network path, testing communication loss, stale-data indication and recovery.

Table: Application Scenario Summary

Industry	Illustrative scenario	Possible OPC UA role	Evidence to collect
Manufacturing	Production-line integration	Exchange modeled equipment data between compatible PLC/MES applications.	Supported profiles, model mapping, and measured application results.
Energy	Substation or plant monitoring	Expose selected measurements and status to supervisory clients.	Endpoint support, update behavior, and project energy measurements.
Pharmaceuticals	Batch and equipment traceability	Use an applicable information model to represent equipment parameters.	Companion specification version, audit requirements, and validated records.
Automotive	Assembly automation	Exchange selected production or robot data where profiles align.	Device compatibility, timing tests, and quality metrics from the project.
Oil and gas	Remote monitoring	Expose selected field data through a tested network and access design.	Security, connectivity, and measured detection/response behavior.

Comparison of OPC UA with MQTT, Modbus, Profinet

The protocols solve different parts of an industrial system. OPC UA defines services and a typed information model; MQTT distributes messages through a broker; Modbus provides a function/address-based device interface; PROFINET supports industrial Ethernet I/O and related application profiles. Compare the required data semantics, device support, timing, access control and integration effort. A protocol name alone does not determine bandwidth, latency, security or cost.

Table: Protocol Roles and Engineering Considerations

Feature	OPC UA	MQTT	Modbus	PROFINET
Communication model	Client/server services and PubSub where supported.	Publish/subscribe through a broker.	Function-code request/response.	Industrial Ethernet profiles for automation; details depend on conformance class and product.
Security	UA security mechanisms are configurable; verify mode, policy, identity, trust, and permissions.	TLS and broker authentication/authorization depend on client, broker, and configuration.	Basic Modbus does not provide application authentication or encryption; use a protected design or supported extension.	Security capabilities depend on the applicable PROFINET version, profile, and configuration.
Bandwidth	Depends on selected encoding, fields, metadata, and schedule.	Depends on payload, topic, QoS, and transport.	Depends on function, quantity, and transport.	Depends on cyclic/acyclic data and network configuration.
Interoperability	Services and information models help; compatible profiles and models are still required.	Payload schema and topic conventions must be agreed.	Register maps and data interpretation are device-specific.	Profiles and device descriptions govern interoperability.
Latency	Measure the selected endpoint, service, network, and load.	Measure broker path, QoS, and subscriber behavior.	Measure device response and serial/TCP path.	Measure the configured network and device class.
Scalability/history	Limits depend on server, profile, model, and application; historical access is a separate supported service/model.	Broker and consumer capacity are implementation-specific; history requires a separate storage/application design.	Device and application limits vary; history is not implied by a register read.	Limits and diagnostic features depend on profiles and equipment.
Cost	SDK, licensing, integration, and validation are product/project-specific.	Broker, client, hosting, and operations costs vary.	Existing devices may reduce replacement effort; gateways and integration still cost.	Hardware, engineering, and licensing costs depend on product and project.
Typical use	Structured industrial information exchange and services.	Brokered telemetry and event distribution.	Simple device data exchange and legacy integration.	Industrial automation communication requiring the applicable PROFINET profile.

These protocols can coexist. For example, a capable gateway may map Modbus points into a UA model, and a supported UA PubSub mapping can distribute DataSets through MQTT. Routing alone performs neither conversion. Confirm the exact product profile, information mapping, security and recovery behavior for the combination chosen.

Compare the data role with Modbus and MQTT

Modbus exposes device points through functions and address conventions; an OPC UA server can model those points as named nodes with types, units and relationships, but a capable gateway must perform the mapping. MQTT moves messages through topics and a broker; it does not by itself define the OPC UA address space or services. Select the combination by the reader task: device polling, contextualized industrial data, or event distribution. Keep protocol conversion separate from the industrial router’s IP forwarding and VPN role.

Future Trends and Outlook

Development themes include richer companion models, edge implementations, analytics integration and PubSub transport options. Structured UA data can support digital twins and AI applications when those consumers understand the model. Industrial wireless or TSN may form part of an engineered network, but application timing and interoperability must be validated. These themes are not a confirmed release schedule, a market forecast or evidence for a particular AI specification.

Ongoing challenges include consistent companion-model interpretation, interoperability between supported profiles, certificate and key lifecycle management, and the resources available on smaller devices. Plan upgrades against the actual published standards and supported product releases rather than an assumed count of future specifications or a promised cryptographic roadmap.

Table: Future Trend Predictions

Topic	Possible direction	Qualification
AI-related models	Represent domain data and relationships using defined information models.	Requires a specific companion model and compatible implementations; no predictive-maintenance gain is implied.
Edge deployment	Run supported OPC UA applications or stacks near field devices.	Hardware, SDK profile, memory, and performance limits are product-specific.
5G and TSN	Combine OPC UA applications with suitable wireless or time-sensitive networks.	Interoperability, latency, coverage, and availability require system-level testing.
Environmental data	Model energy or environmental measurements in an application-specific information model.	No green specification, ESG compliance, or energy reduction is automatic.
Digital-twin visualization	Use information models as one input to a digital-twin application.	Visualization and collaboration depend on application software and validated data.

Summary

OPC UA builds on the industrial data-access needs addressed by OPC Classic while providing a cross-platform address space, services, information models and security mechanisms. Its practical value depends on clear application roles, compatible capabilities and correct deployment. Start with one known read-only value, verify identity and permissions, test the intended subscription and recovery, and then expand the model. Use the current SDK documentation, relevant companion models and conformance evidence for the products involved. New analytics and network technologies can extend this architecture, but do not remove the need for application-level acceptance.

FAQ

What is the difference between OPC UA and OPC Classic?

OPC Classic specifications such as DA, HDA, and AE use Windows COM/DCOM interfaces. OPC UA defines a platform-independent AddressSpace, services, information models, communication mappings, and configurable security mechanisms. Migration is not automatically transparent: identify the OPC UA server (which may be a gateway) and verify mappings for tags, types, and permissions.

How should an OPC UA certificate expiration be handled?

Check the certificate validity period, ApplicationUri and endpoint identity, trust chain, revocation status when required and supported, and the server/client trust lists. Renew or reissue through the site PKI or supported certificate-management process, then validate and distribute the replacement certificate. Connect to the intended endpoint and read a known node. Keep user permissions separate from application-certificate trust; do not disable validation. Disabling revocation checks does not renew an expired certificate; there is no universal 90-day exchange interval.

When is PubSub mode better than Client/server?

Consider PubSub when a publisher must distribute selected DataSet messages to multiple subscribers and the products support a compatible transport, mapping, metadata, and security setup. Client/server remains useful for discovery, browsing, on-demand reads and writes, methods, and subscriptions. PubSub may reduce repeated polling, but bandwidth and latency gains depend on message selection, rate, network, and implementation.

Which programming languages can be used with OPC UA?

OPC UA is specified independently of a programming language. SDKs and stacks are available in several languages, including C/C++, .NET, Java, and Python, but their supported profiles, security features, and maintenance differ. Verify the exact library and release against the server features required by the application.

How can OPC UA be used with 5G?

A deployment can carry OPC UA traffic over a supported network path that includes 5G. PubSub or client/server behavior still depends on the selected mapping, endpoint, and network design. 5G, TSN, and URLLC do not by themselves guarantee sub-millisecond latency or wireless real-time control; test the complete system against its requirements.

What are common OPC UA configuration errors and how should they be checked?

Check the advertised endpoint and network path, then verify the selected MessageSecurityMode and SecurityPolicy, certificate identity/validity/trust, user-token policy and permissions, namespace URI and NodeId, and the Variable DataType and status. Use the server/client diagnostic status and logs; a port check or generic tool alone does not prove the application operation works.

Does an industrial router need to decode OPC UA to carry its traffic?

No. An IP router can forward a permitted client/server flow without interpreting the OPC UA data model. Translation or local hosting is a separate capability to verify.

Does a reachable port prove that OPC UA is secure and working?

No. Check endpoint identity, certificates, user permissions, session establishment and a known application value. Network reachability is only one step.

Can a Modbus device become an OPC UA server just through routing?

No. A capable PLC or gateway must provide the OPC UA server and map the Modbus data with correct types, units and meaning.

Will OPC UA subscriptions automatically resume after a WAN failover?

Not necessarily. Client and server settings, session state and path changes matter. Test the original subscription and first fresh value after a controlled interruption.

References

OPC-10000-1 – OPC Unified Architecture - Part 1: Overview and Concepts — Architecture, core concepts and the distinction between Client/Server and PubSub.

OPC-10000-2 – OPC Unified Architecture - Part 2: Security Model — Application and user security, certificate validation, trust and operational responsibilities.

OPC-10000-3 – OPC Unified Architecture - Part 3: Address Space Model — Nodes, references, attributes, NodeIds and namespace concepts.

OPC-10000-4 – OPC Unified Architecture - Part 4: Services — Discovery, sessions, reading, writing, subscriptions and service status codes.

OPC-10000-5 – OPC Unified Architecture - Part 5: Information Model — Standard information model, namespace 0 and standard folder definitions.

OPC-10000-6 – OPC Unified Architecture - Part 6: Mappings — Encodings, security and transport mappings.

OPC-10000-14 – OPC Unified Architecture - Part 14: PubSub — DataSet publishers and subscribers, transport profiles and PubSub security.