What is OPC UA? Industrial Communication Explained

OPC UA (Open Platform Communications Unified Architecture) is the IEC 62541 international standard for secure, platform-independent machine-to-machine communication in industrial systems. It replaced OPC Classic (DA) by combining a self-describing information model, certificate-based security, and modern transports such as OPC.TCP, HTTPS, and MQTT, which is why it has become the default protocol for SCADA systems, MES, IIoT, and cloud platforms. This guide is written by TT PSC, a Velotic Authorised Partner and certified Kepware system integrator with hands-on industrial deployments.

What is OPC UA?

OPC UA is an open, platform-independent industrial communication standard, registered as IEC 62541 and maintained by the OPC Foundation, that lets industrial devices, controllers, and IT systems exchange data securely across vendors, operating systems, and networks.

In a single sentence, that is what OPC UA is. The name itself describes the design intent. „Open Platform Communications” places OPC UA in a lineage of open, vendor-neutral interfaces for industrial automation. „Unified Architecture” signals that this generation of OPC consolidates what used to be separate specifications (Data Access, Historical Data Access, Alarms and Events) into one coherent stack. The result is the modern OPC UA standard: an extensible framework rather than a single protocol.

The problem OPC UA solves is concrete. A typical plant runs programmable logic controllers from several vendors, a SCADA system from a fourth, a historian from a fifth, and an MES integration that needs to pull process data and machine data from all of them. Without a common interface, every connection is a custom integration, every vendor change is a new project, and every cybersecurity audit raises the same questions about who can read what, signed by which certificate, over which port. OPC UA is used as the common interface across that estate. An OPC UA server, on a controller or on a connectivity platform, exposes data structures from the underlying system. An OPC UA client (in a SCADA, MES, historian, monitoring application, or AWS cloud ingestion service) reads those data points through a single, standardised OPC UA interface.

That single interface is the article’s subject. The sections that follow walk through how OPC UA defines the address space, what services it exposes, how it transports data over TCP/IP and other bindings, and how its security model protects secure data exchange in operational environments. The Kepware section explains how all of this is implemented in practice, and the glossary and FAQ at the end answer the questions OT engineers and plant managers ask before signing a procurement document.

Why „Unified Architecture”: the name decoded

The acronym is denser than it looks. „OPC” no longer stands for „OLE for Process Control”, which is what the original 1996 specification meant by it. The OPC Foundation rebranded the acronym to „Open Platform Communications” once the architecture moved beyond Microsoft’s OLE/COM. „Unified Architecture” is the part that distinguishes OPC UA from OPC Classic, and it has two meanings.

The first is feature unification. OPC Classic was three separate specifications: OPC Data Access for real-time tag values, OPC Historical Data Access for time-series queries, and OPC Alarms and Events for event-driven notifications. Each had its own COM interfaces, its own client software, and its own configuration story. OPC UA collapses all three into one stack. Read, Write, Subscribe, Browse, Method, Historical Access, and Alarms and Conditions are all services on the same address space, exposed by the same OPC UA server, consumed by the same OPC UA client.

The second meaning is layered architecture. OPC UA is not a single wire protocol. It is a layered specification: an information model on top, a service layer in the middle, transport mappings at the bottom (OPC.TCP, HTTPS, WebSocket, MQTT-based PubSub), and a security model that cuts across all layers. New transports and new domain models are added as companion specifications without breaking older OPC UA applications. This is what „extensible framework” means in OPC Foundation documentation.

Who owns and maintains OPC UA: the OPC Foundation and IEC 62541

The OPC Foundation is a vendor-neutral non-profit, founded in 1994, with around 900 member organisations covering controls vendors, software vendors, end users, and academic institutions. The Foundation owns the OPC UA specification, runs certification programmes, and publishes companion specifications jointly with industry working groups (machine tools, process automation, robotics, weighing, and many more).

OPC UA is also formally an international standard. IEC 62541, ratified by the International Electrotechnical Commission in 2010, codifies the OPC UA specification as a multi-part standard. IEC 62541 is structured into parts that match the architecture: Part 1 (overview and concepts), Part 2 (security), Part 3 (address space model), Part 4 (services), Part 5 (information model), Part 6 (mappings), Part 7 (profiles), Part 8 (data access), Part 9 (alarms and conditions), Part 10 (programs), Part 11 (historical access), Part 12 (discovery), Part 13 (aggregates), Part 14 (PubSub), and Part 100 (devices). Each part can be referenced independently in audit and procurement documents, which matters when an internal review wants to know what exactly is being procured.

OPC Foundation specifications are free to download from opcfoundation.org. That is distinct from „free to deploy”. A commercial OPC UA server such as the Kepware product line still requires a commercial licence, and open-source stacks (open62541, Eclipse Milo) ship under their respective licences. The specification is open, the implementation is a separate engineering decision.

A brief history of OPC: from OPC Classic to OPC UA

OPC began in 1996 as a Microsoft-COM-based interface (OPC Classic / DA), but Windows-only design and DCOM security pain forced a complete rewrite, released as OPC UA 1.0 in 2008, standardised as IEC 62541 in 2010, and now positioned as the default industrial communication protocol for Industry 4.0.

The history matters because it explains why the OPC UA architecture looks the way it does. Each design choice in OPC UA is, in part, an answer to a specific problem in OPC Classic.

OPC Classic (DA, HDA, A&E): why it reached end of life

OPC Classic shipped in 1996 as OPC Data Access (OPC DA), and it solved an urgent problem. Before OPC, every HMI or SCADA package needed a custom driver per PLC family. Tens of vendors, hundreds of controller types, an explosion of point-to-point integrations. OPC DA standardised the interface between control systems and data consumers on Windows. OPC Historical Data Access (HDA) followed for time-series, and OPC Alarms and Events (A&E) for event-driven scenarios.

All three depended on Microsoft COM and DCOM. That choice made sense in 1996: COM was Microsoft’s native component model, DCOM extended it across machines, and Windows was the dominant operating system on plant engineering workstations. Two decades later the same choice was a problem. DCOM is hostile to firewalls (dynamic ports, callback connections, peculiar authentication semantics). It is tied to Windows. It is awkward to secure beyond domain authentication and registry tweaks. None of that aligned with the way plants now mix Windows engineering stations, Linux edge devices, embedded RTOS controllers, AWS cloud ingest, and remote access from vendor support teams.

The end-of-life signal arrived in 2022, when Microsoft enforced DCOM hardening to mitigate CVE-2021-26414. Plants that ran legacy OPC DA with default DCOM settings discovered, often during a Patch Tuesday, that previously working integrations had stopped speaking to each other. Tooling existed to update both ends, but for many sites the hardening event accelerated a migration discussion that had been deferred for years. OPC DA still runs in millions of installed positions, though without the active development trajectory that OPC UA enjoys.

The birth of OPC UA (2008) and its standardisation as IEC 62541

The OPC Foundation published OPC UA 1.0 in 2008 after several years of design work that explicitly targeted DCOM independence. The IEC ratified the specification as IEC 62541 in 2010, which gave OPC UA the international standing that procurement and regulatory frameworks demand. Subsequent releases have refined the data model, added the PubSub extension (Part 14), introduced JSON encoding for cloud platforms, and extended the security profiles as cryptographic best practice has evolved.

The breakdown of IEC 62541 into independent parts is not academic. It allowed OPC UA implementations to certify against the parts they actually support. A small embedded server might implement Parts 1, 2, 3, 4, 5, 6, 7, and 8 (enough for Data Access). A historian might add Part 11. A cloud-aggregating platform might add Part 14 for PubSub. The OPC Foundation’s profile mechanism describes which combinations are conformant, which is what auditors look for.

By 2015, OPC UA had reached a critical mass of vendor support, and by 2018 most major SCADA, MES, and historian products had native OPC UA support either in core or as a first-party extension.

How OPC UA works: architecture in plain language

OPC UA uses a client-server architecture in which an OPC UA server exposes its data through a structured address space of nodes (variables, objects, methods), and OPC UA clients discover, read, subscribe, and call methods over an authenticated session, all through a small set of standardised services.

The OPC UA architecture, in operational terms, is simpler than the spec table of contents suggests. A server has data. The server organises that data as an address space. A client finds the server (discovery), opens a secure transport tunnel (SecureChannel), authenticates a session, and then exchanges data through services. That is the entire core flow.

Client-server: the core pattern

OPC UA’s primary interaction pattern is client and server. A server publishes an address space of nodes. One or many clients connect to read, write, subscribe, browse, or call methods. The pattern is bi-directional in the sense that clients can write as well as read, but the connection is always initiated by the client.

A single OPC UA server can be a client of other OPC UA servers. This is called aggregation, and it is the basis of how connectivity platforms such as Kepware consolidate data from many upstream systems into one downstream OPC UA endpoint. A consuming SCADA system or MES sees a single address space and a single set of OPC servers, not the underlying patchwork of native protocols.

The publish-subscribe extension (PubSub, IEC 62541 Part 14) inverts the pattern for one-to-many scenarios where the request-response client server architecture is too restrictive. PubSub uses MQTT, UDP, or AMQP underneath and decouples publishers from subscribers. A line-side controller publishes telemetry without knowing who consumes it; a cloud platform, an analytics service, and an OEE dashboard all subscribe to the same broker.

The address space and nodes

The address space is the structured catalogue of everything the server exposes. It is built from nodes, where each node has a unique NodeId and one of eight node classes (Variable, Object, Method, ObjectType, VariableType, ReferenceType, DataType, View). The address space model uses references to express relationships between nodes: HasComponent, Organizes, HasTypeDefinition, HasProperty, and dozens more.

The mental model that fits best is a typed, navigable filesystem. Where a filesystem has folders and files, an OPC UA address space has objects and variables. Where a filesystem has paths, OPC UA has BrowsePaths. The difference is that every node carries type metadata and is linked into a directed graph of references, which is what makes OPC UA self-describing in a way that flat-tag protocols are not.

Variables, objects, methods, and references

A Variable is a node that carries a typed value, plus a status code, plus source and server timestamps. Example: a Variable named Temperature_T1 with data type Float, value 23.5, units °C, status Good, and timestamp.

An Object is a logical grouping of variables and methods. Example: an Object Pump_P1 with Variables Pressure, FlowRate, MotorCurrent, and Methods StartPump, StopPump, Reset. Objects exist to give shape to the address space and to attach semantics that the information model can describe.

A Method is a callable function, an RPC-style entry point on an object. Methods take typed input arguments and return typed output arguments. Examples: LoadRecipe(recipeId: String) -> StatusCode, MoveToPosition(x: Float, y: Float) -> StatusCode.

A Reference is a typed link between two nodes. HasComponent links an Object to its sub-Objects and Variables. HasTypeDefinition links an instance to its type. Organizes links a folder-like Object to its children. The reference type itself is a node, which means even the relationship vocabulary is part of the addressable, browsable model.

Sessions, SecureChannels, and endpoints

The connection between client and server is built in three layers. An Endpoint is the externally visible address: a URL plus a security policy plus a transport binding. A typical endpoint URL looks like opc.tcp://server.example.com:4840 for OPC.TCP on the default port, or opc.tcp://server.example.com:49320 for a Kepware OPC UA server which uses port 49320 by default.

A SecureChannel is the encrypted and signed transport tunnel established between client and server through the endpoint. SecureChannels are bound to certificates, configured by security policy and security mode (covered in the Security section), and reissued periodically through a key-renewal process.

A Session is the authenticated logical connection that runs on top of the SecureChannel. Sessions carry the user identity (anonymous, username and password, X.509 user certificate, or JWT) and the context for service requests. Multiple sessions can share a SecureChannel; sessions can be activated, deactivated, and migrated to a different SecureChannel if the underlying transport drops.

Discovery: how a client finds a server (GetEndpoints, FindServers)

OPC UA discovery answers two questions: „what servers are reachable on this network?” and „what endpoints does this server offer?” The first is answered by a Local Discovery Server (LDS), an optional component running on port 4840, which maintains a registry of OPC UA servers on a network segment. The FindServers service returns the list.

The second is answered by GetEndpoints, a service that any OPC UA server exposes without requiring authentication. A client calls GetEndpoints to learn which security policies, security modes, and transport bindings the server supports, and then chooses the strongest combination available before opening a SecureChannel. This is also the diagnostic call most useful when a connection fails, since it tells the engineer whether the issue is at the network layer, the transport layer, or the security layer.

The OPC UA information model: how data becomes self-describing

Unlike Modbus or OPC DA, where a tag is just an address and a value, every OPC UA node carries metadata about its type, units, ranges, and relationships, so a client can browse a server it has never seen before and immediately understand what each value means.

The OPC UA data model is the differentiator that makes everything else worth the effort. Without it, OPC UA would just be another tag protocol with TLS bolted on. With it, OPC UA becomes the layer where industrial systems become legible to software applications that did not write them.

Standard object types (BaseObjectType, FolderType, ServerType)

The OPC UA specification defines a small set of base ObjectTypes that every conformant server exposes. BaseObjectType is the root. FolderType provides filesystem-style grouping. ServerType describes the server itself: its diagnostics, its capabilities, the namespaces it knows about, the certificates in use. ServerStatusType describes operational state (running, failed, no configuration, etc.). BuildInfoType describes the build (vendor, product name, software version).

These standard types matter because they give every OPC UA application a common starting point. A monitoring tool that has never seen the address space of a particular server can still discover server diagnostics, software version, and uptime by walking the standard nodes under the Server object. This is also where security audit tools find what they need: which security policies are configured, what user tokens are accepted, which certificates are trusted.

Custom type definitions and companion specifications

Beyond the standard types, vendors and industry working groups extend the model. A vendor can define a BeckhoffPLCType that captures their controller’s specific structure. An industry working group can publish a companion specification that defines, say, MachineToolType so that every CNC, regardless of vendor, exposes spindle speed, axis positions, and tool offsets the same way.

The major companion specifications today include:

• UMATI (Universal Machine Tool Interface) for machine tools and CNC equipment
• PA-DIM (Process Automation Device Information Model) for sensors and actuators in process industries
• AutoID for RFID readers and barcode scanners
• OPC UA for Robotics for industrial robots
• OPC UA for Weighing for industrial scales
• OPC UA for Pumps, OPC UA for Cranes, OPC UA for Plastics, and many more

This is what people mean when they describe OPC UA as the language of Industry 4.0. The combination of a generic information model and growing companion specifications gives industrial systems a path to semantic interoperability at scale.

NodeId, BrowseName, and DisplayName: how things are identified

Every node has three different identifiers, used for different purposes. The NodeId is the stable machine identifier: a namespace index and an identifier value. A typical NodeId looks like ns=2;s=Channel1.PLC1.Temperature, where ns=2 is the namespace index (each vendor or companion specification gets its own namespace) and s=Channel1.PLC1.Temperature is a string identifier. Numeric (i=1234), GUID (g=…), and ByteString (b=…) identifiers also exist; the byte string form is occasionally used for binary or hash-based identifiers.

The BrowseName is a type-style identifier used for path navigation. A path like /Objects/Server/ServerStatus/CurrentTime is a sequence of BrowseNames. BrowseNames are not localised.

The DisplayName is the human-readable, localisable name shown in HMI tag browsers. The same node can have different DisplayNames in English, German, and Polish. NodeIds and BrowseNames stay stable while DisplayNames are translated.

Why self-description matters for IT/OT convergence

The practical consequence of self-description is that an MES, ERP, or analytics platform can consume plant data without per-tag mapping projects. When a new line is commissioned, its address space is browsable from day one. When an OEM ships a piece of equipment with its own embedded OPC UA server, that server already exposes a typed model. When the data finally reaches a cloud platform analytics service, the metadata travels with the values, so dashboards can be built once and populated automatically as new sources are added.

This is the technical foundation of the Unified Namespace pattern, where a single broker (typically MQTT) serves as a single source of truth for plant data, fed by edge OPC UA servers that publish standardised data models into a normalised topic hierarchy. Without self-description, UNS would be just another tag broker. With self-description, it becomes a contract between OT and IT.

OPC UA services: Read, Write, Subscribe, Browse, Call

OPC UA defines a fixed set of services, grouped into Discovery, SecureChannel, Session, NodeManagement, View, Attribute, Method, MonitoredItem, Subscription, and Query, that every conformant OPC UA server and OPC UA client must speak, making OPC UA the only industrial communication protocol that standardises both what you can do and how you describe what you are doing it to.

The service set is the verb list of OPC UA. It is small and deliberately so. Every conformant implementation handles the same calls in the same way, and the address space tells the client what those calls can be aimed at.

Read and Write services

Read is the simplest service. The client sends a list of NodeIds and attribute identifiers. The server returns, for each, a value (when applicable), a status code, a source timestamp, and a server timestamp. Reads are synchronous: a request gets a response, and there is no implicit subscription.

Write is the symmetric service for changing values. The client sends NodeId, attribute, and the new value. The server returns a status code per write. Writes are subject to access rights: each node carries AccessLevel and UserAccessLevel attributes, and the user identity established in the session determines whether the write succeeds.

Read and Write are the day-one services every engineer learns. They are also the services that map most directly to OPC DA semantics, which is why migration tooling tends to start with Read/Write parity before tackling Subscriptions.

Subscriptions and MonitoredItems (data-change driven)

Most production OPC UA traffic is not Read but Subscribe. A Subscription is a server-side container with publishing parameters (publishing interval, lifetime, max keep-alive count). Inside the Subscription, the client creates MonitoredItems, each of which is a node plus sampling parameters (sampling interval, queue size, deadband, filter).

Operationally, the server reads the underlying data sources at the sampling interval, queues changes, and delivers them to the client at the publishing interval. If the value has not changed (or has not crossed the configured deadband), nothing is published. This is dramatically more efficient than polling: a thousand tags with a one-second sampling interval and a 250 ms publishing interval generate exactly as much network traffic as the changes warrant, not as much as a thousand polls would.

For predictive maintenance use cases, MonitoredItems are how vibration, temperature, current, and operating-time data flow from edge devices to monitoring applications without saturating the network. The sampling-versus-publishing distinction also gives engineers a tuning knob: increase the sampling rate for high-frequency signal capture without paying the network cost of a similarly fast publishing rate.

Browse and BrowsePath (walking the address space)

Browse lists the children of a given node. BrowsePath translates a sequence of BrowseNames into NodeIds. Both are how HMI tag browsers, OPC UA test tools, and discovery agents walk an unfamiliar server. Browse can also be filtered by reference type (only HasComponent references, for example) and by node class (only Variables), which is what OPC UA test clients use to render the address space tree.

Methods and Programs (RPC-style calls)

Method is the RPC service. A Method call specifies the object NodeId, the method NodeId, and the input arguments. The server invokes the method and returns output arguments and a status code. Methods are how machine commands are exposed: StartProduction, LoadRecipe, ResetCounter, AcknowledgeAlarm. Argument types are defined in the address space, so a client can call a method it has never seen by inspecting the type definition first.

Programs are a state-machine extension to Methods, defined in IEC 62541 Part 10. They are rarely implemented in practice; most vendors expose state machines through Object types and explicit transitions rather than the formal Programs profile.

Historical Access and Alarms & Conditions profiles

Historical Access (HA, IEC 62541 Part 11) lets clients query historical values: raw values, processed aggregates (min, max, average, time-weighted average), and at-time queries. HA is how a historian or analytics platform retrieves time-series data over the same OPC UA interface used for real-time data, instead of opening a separate ODBC connection.

Alarms and Conditions (A&C, IEC 62541 Part 9) standardises the model for industrial alarms: severity, area, source, condition state, acknowledgment, comments, and history. Many but not all OPC UA servers expose the full A&C profile; some expose a subset. A&C is what allows a SCADA system to consume alarms from a controller without per-vendor mapping logic.

OPC UA transports: OPC.TCP, HTTPS, WebSocket, and PubSub

OPC UA separates what you say (services and information model) from how you transport it, supporting an efficient binary protocol over TCP (OPC.TCP, default port 4840), HTTPS for cloud and web clients, WebSocket for browser-based HMIs, and a publish-subscribe extension (PubSub) that runs over MQTT, UDP, or AMQP for one-to-many IIoT scenarios.

Transport bindings are described in IEC 62541 Part 6. The choice between them is operational, not theoretical: each binding has a set of properties that fit a particular deployment context, and most non-trivial architectures use more than one.

OPC.TCP binary on port 4840 (the default workhorse)

OPC.TCP is the native protocol of OPC UA. UA-Binary encoding, persistent TCP connection, lowest latency. The default port is port 4840, registered with IANA. Most server-to-server, server-to-HMI, and server-to-historian traffic uses OPC.TCP, because it is the most efficient binding both in CPU and in bandwidth.

The trade-off is that OPC.TCP is a non-HTTP protocol on a non-standard port. Corporate and OT firewalls have to be configured to permit it. Within a plant network this is rarely a problem; across an enterprise WAN or to a cloud platform, it sometimes is.

HTTPS and WebSocket bindings (cloud and web friendly)

HTTPS and WebSocket bindings carry OPC UA messages over standard web protocols. UA-Binary or UA-JSON encoding can be used over either binding. The advantages are obvious: corporate proxies, load balancers, and cloud platforms understand HTTPS, and a browser-based HMI can speak OPC UA directly through WebSocket without a native client. The cost is moderate overhead (TLS handshake, HTTP framing) compared to the binary protocol on raw TCP.

The HTTPS binding usually runs on port 443, the standard TLS port; the WebSocket binding upgrades from HTTPS, so the same port applies. For client software running in cloud platforms or behind corporate web filters, HTTPS is often the only practical choice.

OPC UA PubSub: MQTT, UDP, and AMQP

PubSub (IEC 62541 Part 14) is the publish-subscribe extension. It decouples publishers from subscribers: a publisher sends data to a broker (MQTT or AMQP) or to a multicast address (UDP), and zero or more subscribers consume from the broker or the multicast group. There is no client/server session, no discovery handshake, and no per-subscriber configuration on the publisher side.

PubSub is designed for two scenarios. The first is many-to-many IIoT, where dozens or hundreds of edge devices feed many cloud platforms and analytics services without N×M point-to-point connections. The second is time-sensitive control, where the UDP binding (often combined with TSN) carries deterministic data between controllers. Sparkplug B, which is not part of OPC UA but is widely used alongside it, defines an MQTT topic structure and payload encoding that complements the OPC UA PubSub spec for plant-wide data buses.

For Kepware-based architectures, the IoT Gateway component publishes data via MQTT (including Sparkplug B), AWS IoT, Azure IoT, and REST endpoints, and the OPC UA PubSub support enables many-to-many topologies inside the plant. A deeper look at how IoT Gateway works in production is available in the Kepware IoT Gateway overview.

Unified Namespace (UNS) with OPC UA and MQTT/Sparkplug B

The Unified Namespace pattern uses one MQTT broker as the single source of truth for all plant data. Edge OPC UA servers publish into the broker via PubSub or via Sparkplug B. Any IT or OT consumer subscribes from the same broker. The pattern is increasingly popular because it inverts the integration model: instead of every consumer connecting to every source, every source publishes once and every consumer subscribes once.

OPC UA and MQTT are complementary in this pattern, not competing. OPC UA brings the typed information model and standardised data models; MQTT brings the lightweight transport and decoupled fan-out. Sparkplug B provides the topic and payload conventions that turn raw MQTT into a structured industrial bus.

OPC UA security architecture: certificates, policies, and tokens

OPC UA was designed with security as a first-class concern: every connection is authenticated by X.509 certificates, optionally signed and encrypted using one of several security policies (such as Basic256Sha256), and every user is independently authenticated by username/password, certificate, or JWT, replacing the bolted-on DCOM hardening that made OPC Classic deployments fragile.

The OPC UA security model is what makes the protocol acceptable in environments subject to IEC 62443, NIS2, and the various national OT cybersecurity frameworks. It is also the part of OPC UA most often misconfigured, because the security primitives interact in non-obvious ways.

The three pillars: authentication, authorisation, and encryption

Every OPC UA connection has to satisfy three independent security questions.

Authentication asks who is connecting. OPC UA authenticates twice: once at the application layer (the X.509 certificate of the client application against the trust list of the server, and vice versa), and once at the user layer (the user token associated with the session). Both checks have to pass.

Authorisation asks what the authenticated user is allowed to do. Each node in the address space carries AccessLevel and UserAccessLevel attributes, plus WriteMask and UserWriteMask for attribute-level write permissions. Role-based access control extensions allow these to be driven by user roles rather than per-user lists.

Encryption asks whether the messages are protected on the wire. The combination of security policy and security mode determines whether messages are signed, encrypted, or both, and which cryptographic algorithms are used.

X.509 certificates and the trust store

Every OPC UA application, both server and client, has its own X.509 certificate. Certificates can be self-signed (common for small deployments) or issued by an internal certificate authority (preferred for multi-site estates). On first connection, the certificates have to be exchanged and explicitly trusted: the server’s trust list has to contain the client’s certificate, and vice versa. Some servers offer a „trust on first use” mode to ease initial pairing; production deployments should disable that and provision certificates explicitly.

The trust list also contains issuer certificates (for CA-signed deployments) and a certificate revocation list. Trust list management is the part of OPC UA security that consumes the most operational time, especially across hundreds of devices and thousands of certificates with overlapping renewal schedules. Automated certificate lifecycle management is what separates a security model that survives audit from one that does not.

Security policies (None, Basic256Sha256, Aes256_Sha256_RsaPss)

A security policy is a named cryptographic suite covering key sizes, hash algorithms, and padding schemes. The currently relevant policies are:

• None disables cryptography entirely. It is appropriate only for laboratory environments and is never appropriate for production use.
• Basic256Sha256 is the current minimum recommendation: RSA-2048, SHA-256, AES-256. It is what most production OPC UA deployments target.
• Aes256_Sha256_RsaPss is a newer policy with stronger padding (RSA-PSS) and is appropriate for new deployments where both ends support it.

Older policies (Basic128Rsa15, Basic256) have been deprecated by the OPC Foundation and should be removed from production endpoints. Some legacy clients still require them; the appropriate response is to upgrade the client, not to keep weak policies enabled on the server.

Message security modes (None, Sign, SignAndEncrypt)

The security mode determines what protection is applied to each OPC UA message.

• None means messages are sent in cleartext with no integrity protection. Lab use only.
• Sign means messages are signed for integrity but not encrypted. Confidentiality is not protected, but no one can tamper with the messages in transit.
• SignAndEncrypt means messages are both signed and encrypted. This is the only appropriate mode for production OT/IT data flows.

Sign-only modes have niche use cases: high-throughput scenarios where confidentiality is not required and the cryptographic load of encryption is undesirable. In practice, modern hardware handles SignAndEncrypt without strain, and the operational simplicity of one mode across the estate is usually worth more than the marginal performance gain of Sign-only on selected channels.

User authentication: anonymous, username/password, X.509, JWT

User authentication is independent of the SecureChannel certificate. Once the SecureChannel is established and the application-level trust is verified, the client offers a user token to activate the session. Four token types are defined:

• Anonymous authentication requires no credentials. It should be disabled in production except for very specific read-only diagnostic endpoints.
• Username and password is the most common production token. Passwords should follow corporate policy and should be transmitted only over SignAndEncrypt channels.
• X.509 user certificate uses a separate certificate to identify the user (not the application). Useful for high-security environments and for service accounts where password rotation is impractical.
• JWT (JSON Web Token) integrates with modern identity providers (Azure AD, Okta, Keycloak) for single sign-on across the OT estate. JWT support is relatively recent in OPC UA stacks and is the direction federated OT/IT identity is moving.

Reverse Connect for firewall-friendly deployments

Reverse Connect inverts the normal connection direction. Instead of the client opening a TCP connection inbound to the server, the server initiates the connection outbound to the client. This is essential when the OT zone has no inbound firewall openings and security policy forbids creating any. The client publishes its endpoint; the server connects out to it; the OPC UA session runs over the established connection in the same way as a normal session.

Reverse Connect is widely supported in modern OPC UA stacks, including Kepware. It is the cleanest way to bring data out of an air-gapped or strictly-segmented OT zone without compromising the segmentation model.

Practical security checklist for OT/IT teams

The eight-point checklist that experience suggests should be applied before going to production:

1. Set the minimum security policy to Basic256Sha256, ideally to Aes256_Sha256_RsaPss if both ends support it. Remove None, Basic128Rsa15, and Basic256 from the endpoint configuration.
2. Set the security mode to SignAndEncrypt on every production endpoint. No exceptions for „internal-only” links.
3. Disable Anonymous user authentication on all production endpoints. If diagnostic anonymous access is genuinely required, expose it on a separate restricted endpoint.
4. Provision X.509 application certificates explicitly. Disable trust-on-first-use, and document the certificate exchange procedure.
5. Set a password policy that matches corporate IT requirements (length, complexity, rotation). Apply it through whatever credential store the OPC UA application uses.
6. Plan certificate rotation. Certificates expire; expired certificates break sessions; broken sessions cause production incidents. A rotation schedule and an automation pipeline are the answer.
7. Allowlist client certificates explicitly. Auto-accept of any client certificate is an anti-pattern.
8. Enable the OPC UA audit log on the server and forward audit events to the SIEM. Audit events include session creation, certificate failures, write operations, and method calls; they are exactly what an OT cybersecurity programme needs as evidence.

A deeper Kepware-specific security walkthrough, including the exact configuration steps for each item above, is available in the Kepware OPC UA security guide.

OPC UA vs OPC DA: a side-by-side comparison

OPC UA replaces OPC DA across every dimension that matters: it runs on any operating system (not just Windows), encrypts and authenticates by default (no DCOM headaches), describes data with rich metadata (not just a flat tag list), and remains under active standardisation. OPC DA still exists in millions of deployed plants because migration takes effort.

The comparison is worth making explicit because OPC DA is still common in brownfield environments, and the migration question is one most plants face within the next few years.

Dimension	OPC DA (Classic)	OPC UA
Platform	Windows only (COM/DCOM)	Cross-platform (Windows, Linux, macOS, embedded RTOS)
Networking	DCOM (hostile to firewalls)	TCP, HTTPS, WebSocket (firewall friendly)
Security	Bolted-on DCOM hardening	Built-in: X.509, encryption, signing, user tokens
Data model	Flat tag list (Item ID, value, quality, timestamp)	Rich address space: typed nodes, objects, methods, references
Discovery	OPCEnum (LAN only)	Local Discovery Server, GetEndpoints (LAN and WAN)
Subscriptions	Group-based polling	MonitoredItems with sampling and publishing intervals
Methods (RPC)	Not supported	Supported (Method service)
History	Separate spec (HDA)	Integrated (HistoryRead)
Alarms / Events	Separate spec (A&E)	Integrated (Alarms and Conditions profile)
Standardisation	Microsoft COM	IEC 62541
Future	End of life (DCOM hardening 2022)	Active (companion specs, FX, PubSub)

Platform independence (no more COM/DCOM pain)

DCOM made cross-machine OPC DA notoriously fragile. Domain authentication, identity impersonation, registry tweaks, callback ports, and Windows-only operation. Engineers who ran multi-vendor plants in the 2000s remember the troubleshooting playbook: DCOMcnfg, the Anonymous Logon group, Endpoint Mapper port 135, the firewall callbacks. None of it scaled cleanly.

OPC UA stacks exist for Windows, Linux, macOS, embedded RTOS, .NET, Java, C/C++, Python, Node.js, and Go. The same OPC UA client software can run on a Windows engineering station today and migrate to a Linux container tomorrow without changing the protocol layer. That platform independent property is what makes OPC UA a fit for the heterogeneous hardware platforms that modern industrial automation actually runs on.

Information model vs flat tag lists

OPC DA: Channel1.PLC1.Tank1_Temperature = 75.3. The integrator has to know that the units are degrees Celsius, that the sensor is a Pt100 with a 0–150 °C range, and that the PLC scales raw counts to engineering units in ladder logic.

OPC UA: an Object Tank1 with a Variable Temperature of data type Float, with EngineeringUnits set to °C (per the UNECE Recommendation 20 codes), with EURange set to [0, 150], and with a reference HasTypeDefinition pointing at a tank type from a companion specification. The same value, with full self-describing metadata, consumable by any OPC UA client without per-tag mapping.

When you still see OPC DA in the wild

OPC DA persists in three categories of deployment. Legacy SCADA installations on systems older than around 2015. Equipment OEMs that have not yet shipped OPC UA-capable firmware (especially in machine-tool, weighing, and small-batch process equipment). DCS environments with very long replacement cycles where the OPC DA bridge is the path of least resistance.

For these cases, the bridge strategy is to expose the legacy OPC DA server as an OPC UA endpoint through an OPC DA Client driver in a connectivity platform such as Kepware. The downstream consumers see an OPC UA endpoint; the upstream legacy server keeps running OPC DA until it is replaced. This pattern, applied carefully, decouples the migration timeline of the consumers from the timeline of the legacy sources.

OPC UA vs other industrial protocols (MQTT, Modbus, EtherNet/IP)

OPC UA is not the only industrial protocol. Modbus and EtherNet/IP still dominate the device-to-controller layer, and MQTT often handles IIoT-to-cloud telemetry. OPC UA uniquely operates at the contextualised data layer between them, which is why most modern architectures use a combination.

The comparison is operational, not ideological. Each protocol has a layer where it fits naturally; the architecture conversation is about which layer needs which protocol, not about choosing a single winner.

OPC UA vs MQTT (and the OPC UA over MQTT hybrid)

MQTT is a lightweight publish-subscribe message transport. It does one thing well: deliver small messages to many subscribers through a central broker, with quality-of-service guarantees and reasonable bandwidth efficiency. MQTT does not define payloads, does not standardise data models, and does not carry semantic metadata.

OPC UA is a full architecture: information model, services, security, plus its own transports including the binary protocol and a PubSub extension that uses MQTT underneath. OPC UA defines what data means; MQTT defines how messages move.

The pragmatic combination is OPC UA over MQTT, formalised in IEC 62541 Part 14 (PubSub). The OPC UA payload encoding rides on MQTT topics, giving you OPC UA’s information model with MQTT’s broker-mediated fan-out. Sparkplug B is an alternative that defines an MQTT topic structure and payload encoding for industrial use; it is widely used alongside OPC UA in UNS architectures.

OPC UA vs Modbus TCP/RTU

Modbus is the lingua franca of the device-to-controller layer. Sensors, drives, low-cost PLCs, and a long tail of industrial devices speak Modbus. The protocol is ubiquitous, inexpensive to implement, and well understood. It also has no native security, no metadata, and a fundamentally limited address model (numbered registers).

OPC UA does not replace Modbus at the device layer. Modbus stays where it fits, and OPC UA aggregates Modbus data through a connectivity platform that exposes the consolidated tag space with full OPC UA semantics. Engineers familiar with Modbus from controller integration will recognise the pattern: the proprietary protocols stay close to the device, and OPC UA exposes the consolidated picture upwards.

OPC UA vs EtherNet/IP, PROFINET, and other fieldbuses

EtherNet/IP, PROFINET, EtherCAT, POWERLINK, SERCOS III, and the rest of the industrial Ethernet family are fieldbus-level protocols. Vendor ecosystems, deterministic I/O, cyclic communication. They live in the controller-to-device and controller-to-IO layers, and they are tied to specific vendor stacks (EtherNet/IP for Rockwell, PROFINET for Siemens).

OPC UA traditionally sits above these fieldbuses, normalising data from heterogeneous vendor stacks for SCADA, MES, and cloud platforms. With OPC UA FX, OPC UA also enters the controller-to-controller layer where these fieldbuses currently dominate, often combined with TSN for deterministic timing. Whether OPC UA FX displaces incumbent fieldbuses or coexists with them is one of the open questions of the next five years.

Decision framework: when to choose each protocol

A four-row decision table covers most architecture choices.

Layer	Recommended protocols	Why
Device to controller	Modbus, EtherNet/IP, PROFINET	Mature fieldbus ecosystems, low cost, deterministic I/O
Controller to controller	OPC UA FX, EtherNet/IP, PROFINET	OPC UA FX brings OPC UA into this layer where standardisation is desirable
Controller to IT	OPC UA	Rich information model, security, broad consumer support
Edge to cloud	MQTT, OPC UA over MQTT, Sparkplug B	Decoupled fan-out, broker-mediated topology, cloud-native ingest

Most real architectures combine all four. The integration work is at the boundaries: Modbus to OPC UA at the connectivity layer, OPC UA to MQTT at the edge, MQTT to cloud platform native ingest at the gateway.

OPC UA in Industry 4.0 and IIoT

OPC UA is the communication backbone of Industry 4.0 and the foundation that most digital manufacturing initiatives build on. The German RAMI 4.0 reference architecture explicitly mandates it. Major IIoT cloud platforms (Azure, AWS, Google Cloud) provide native OPC UA ingest. Emerging extensions like OPC UA FX (Field eXchange) and Asset Administration Shell are positioning OPC UA as the data layer for digital twins.

The Industry 4.0 framing is not marketing language imposed retroactively. The reference architectures of the German Industry 4.0 initiative were drafted around OPC UA from the start, and the OPC Foundation has worked closely with Plattform Industrie 4.0 to align on the technical layer.

OPC UA as the common language of the smart factory

RAMI 4.0 (Reference Architectural Model Industrie 4.0) defines a three-dimensional model of life cycle, hierarchy, and architecture layers. The communication layer in RAMI 4.0 is OPC UA. This is not a recommendation; it is the model’s normative communication choice. When German automotive OEMs publish smart factory blueprints, OPC UA appears as the assumed communication protocol.

The same alignment shows up in industry consortia outside Germany. The Industrial Internet Consortium (now Industry IoT Consortium) reference architectures position OPC UA as the connectivity standard for industrial systems. Cloud platforms documentation from Microsoft, AWS, and Google all assume OPC UA as the preferred plant-side data source.

OPC UA FX (Field eXchange) for controller-to-controller communication

OPC UA FX, introduced in 2022, is the extension that brings OPC UA into the controller-to-controller layer historically dominated by EtherNet/IP and PROFINET. FX combines OPC UA semantics (typed information model, security model) with the deterministic timing requirements of cyclic industrial communication, often using TSN (Time-Sensitive Networking, IEEE 802.1) as the underlying transport.

The participation of major controls vendors (Siemens, Rockwell, Beckhoff, Schneider, B&R, Mitsubishi, and others) gives FX commercial momentum that earlier multi-vendor controller protocols lacked. Whether FX achieves wide adoption in greenfield installations over the next several years, or coexists indefinitely with the incumbent fieldbuses, depends on procurement decisions in the German automotive sector and a few large process customers.

OPC UA, digital twins, and the Asset Administration Shell (AAS)

The Asset Administration Shell is the Industry 4.0 standardised digital twin model. An AAS is a structured representation of a physical asset (machine, line, plant) covering its identity, properties, sub-models for various aspects (energy, maintenance, quality), and runtime data. AAS specifications align with OPC UA, and the most common AAS implementations expose the runtime portion of the AAS through OPC UA endpoints.

The combination matters because it gives digital twin platforms a defined contract. Instead of every twin platform inventing its own way to talk to the underlying OT systems, AAS plus OPC UA defines the model and the protocol. This is what allows simulation, visualisation, and analytics tools to consume plant data without per-vendor adapters.

OPC UA in the cloud (Azure, AWS, Google Cloud)

All three major cloud platforms support OPC UA natively. Azure IoT Edge ships an OPC Publisher module that ingests OPC UA data into Azure IoT Hub. AWS IoT SiteWise has native OPC UA ingest as a first-class data source, with AWS cloud connectors handling protocol translation, retention, and analytics integration. Google Cloud’s Manufacturing Data Engine supports OPC UA as an ingestion source.

The reference architectures are similar across the three clouds: an OPC UA server (such as Kepware) at the edge consolidates plant data, an edge agent (Azure IoT Edge, AWS Greengrass, Google Cloud equivalent) forwards data securely to the cloud, and the cloud platforms handle storage, analytics, and downstream integration. The HTTPS and PubSub bindings of OPC UA make this integration straightforward; the binary protocol still wins for plant-internal traffic.

Migrating from OPC DA to OPC UA: a practical path

Migrating from OPC DA to OPC UA does not require a „big bang” rewrite. Most plants use a wrapper or gateway (such as Kepware) that exposes legacy OPC DA servers as OPC UA endpoints, then incrementally retires DA endpoints as connected clients are upgraded.

The migration question is in front of every plant that runs OPC DA today. The answer is rarely „rip and replace overnight” and is almost always „phase it in through a connectivity layer”.

Why migrate (and why many plants haven’t yet)

The drivers for migration come from multiple directions. The 2022 DCOM hardening event made OPC DA more brittle. NIS2 and IEC 62443 frameworks demand security postures that OPC DA cannot easily provide. Vendor end-of-life signals on OPC DA libraries continue to accumulate. New equipment ships with OPC UA servers and increasingly without OPC DA support.

The reasons plants have not yet migrated are equally concrete. Working systems are working. ROI is uncertain when the goal is „future readiness”. Internal expertise on OPC UA is thin in many plants. The migration touches multiple stakeholders: OT, IT, security, and the equipment OEMs whose firmware feeds the system. A migration that is done badly produces more downtime and more audit findings than the legacy system it replaced.

The pragmatic middle ground is to migrate through a wrapper, take the win on the consumer side first (modern OPC UA clients), and let the legacy OPC DA sources be replaced on their own equipment lifecycle. Most successful migrations follow this shape.

Wrappers and bridges (DA-to-UA gateways)

A DA-to-UA wrapper is a connectivity component that consumes OPC DA on one side and exposes OPC UA on the other. Kepware’s OPC DA Client driver does exactly this: it connects to a legacy OPC DA server, pulls the tag space, and exposes the same data through the Kepware OPC UA server endpoint. The downstream OPC UA clients see a modern endpoint. The legacy OPC DA server sees a single, well-behaved client.

The wrapper pattern is used in roughly 80% of brownfield migrations, because it is the lowest-risk way to decouple the consumer-side migration from the source-side replacement. It also gives the integration team a single place to apply security, logging, and access control, which is itself a step up from the DCOM-based original.

Step-by-step migration plan: audit, pilot, cutover

The migration plan we apply across our engagements follows six steps.

1. Audit the existing OPC DA inventory. Identify every OPC DA server, its host, its tag count, its consumers, and its DCOM configuration. Spreadsheet output. This step usually surfaces consumers and dependencies the original engineers no longer remember.
2. Stand up the OPC UA gateway in parallel. Install Kepware (or the chosen connectivity platform), configure the OPC DA Client driver, and replicate the tag space behind a Kepware OPC UA server endpoint. No production traffic yet.
3. Pilot with one client. Pick one HMI, one MES, or one historian and migrate it to consume from the new OPC UA endpoint. Measure performance, validate data quality, validate security configuration. Two-week pilot is usually enough to find issues.
4. Provision certificates and document the trust process. This is where most migrations under-invest. Write down how certificates are generated, how they are exchanged, how they are renewed, and who owns each step.
5. Migrate clients one by one. Each client cutover is a small project: validate the tag mapping, switch the endpoint, watch the data, confirm the alarms. Roll back is trivial because the OPC DA endpoint is still running.
6. Decommission OPC DA. Once every client is on OPC UA, the DA endpoints can be retired as their host equipment is replaced. The wrapper stays in place until the last DA source is gone.

In a recent deployment for a European food and beverage manufacturer, we completed steps 1–5 across a fleet of OPC DA tags in six weeks – including certificate provisioning and MES cutover – with zero unplanned downtime.

Common pitfalls and how to avoid them

The pitfalls are repeatable. NodeId stability is the most common failure: the wrapper assigns NodeIds based on the OPC DA Item IDs, and a tag rename in the legacy source breaks every downstream consumer. The fix is to fix the NodeId mapping explicitly and refuse to let it drift.

Certificate expiry is the second most common failure. Certificates that worked at commissioning time expire eighteen months later, sessions stop establishing, and operations team have a Friday afternoon problem. The fix is a rotation calendar and an alerting rule on certificate validity windows.

Mismatched security policies between client and server are the third most common failure. The client supports up to Basic256Sha256, the server has been hardened to Aes256_Sha256_RsaPss only, and the connection silently drops. The fix is to standardise the policy across the estate and to verify endpoints with GetEndpoints before going live.

Firewall ports are the fourth. Port 4840 for OPC.TCP, port 49320 for Kepware, plus any custom ports used by specific deployments. Forgetting to open these in the OT firewall is a Day 1 issue that wastes hours.

Anonymous user accidentally enabled is the fifth, and the most embarrassing in audit. The default configuration of some OPC UA stacks permits Anonymous; a security checklist that explicitly verifies this is the only reliable defence.

Planning a DA-to-UA migration? Our engineers have run this playbook across multi-site European deployments. Scope your Kepware migration with our implementation team – we scope it as a fixed-delivery engagement, not an open-ended consultancy.

How Kepware implements OPC UA

Kepware (now part of Velotic, following TPG Capital’s acquisition of PTC’s IoT portfolio) implements OPC UA both as a server (default port 49320), exposing data from more than 150 industrial protocol drivers as a single self-describing OPC UA address space, and as a client driver, letting it aggregate data from external OPC UA servers. TT PSC, as a Velotic Authorised Partner and certified Kepware integrator, deploys this combination as the foundation of most OT/IT integration projects.

This section is the operational answer to „we have decided OPC UA is the right standard. Now what?” Kepware is not the only OPC UA implementation, but it is the connectivity backbone that most multi-vendor industrial estates end up using, because the connectivity coverage and the operational tooling are what makes the difference at scale.

One note on the current market context: TPG Capital completed its acquisition of the Kepware product line from PTC in March 2026. For organisations that have relied on PTC’s support and roadmap, this change raises practical questions about how subscription and perpetual licensing compare over a five-year TCO, long-term support, and product direction. Working with a certified Velotic Authorised Partner rather than procuring direct is, in this environment, a lower-risk path – the integrator absorbs the vendor transition risk and maintains continuity of delivery regardless of the upstream ownership structure.

Kepware is also not the only OPC UA connectivity platform we deploy. For environments where Ignition or a different platform is a better architectural fit, the same design principles apply – the choice of connectivity layer does not change the data architecture. We recommend based on the client’s environment, not on product preference.

Kepware as an OPC UA server (default port 49320)

KEPServerEX, the flagship Kepware product, runs as a native OPC UA server on port 49320 by default (configurable to any port, often changed to 4840 in greenfield deployments to align with the IANA-registered default). The endpoint URL takes the form opc.tcp://<server>:49320. Security policy, security mode, and user token configuration are set per endpoint, and multiple endpoints can run in parallel to support clients with different security capabilities.

The address space is built automatically from the configured Channels, Devices, and Tags. Each Channel maps to a specific protocol driver (Allen-Bradley ControlLogix, Siemens TIA Portal, Modbus TCP, Beckhoff TwinCAT, and so on). Each Device under a Channel maps to a specific controller. Each Tag maps to a memory address or symbolic identifier on the device. The OPC UA address space mirrors this hierarchy as Objects (Channels, Devices) and Variables (Tags), with consistent NodeId formatting (ns=2;s=Channel1.Device1.Tag1) that downstream consumers can rely on.

For an exhaustive list of the native protocols Kepware supports, including the OPC UA Client driver covered next, the full list of 150+ Kepware protocol drivers gives the current catalogue.

Kepware as an OPC UA client (aggregating external servers)

The OPC UA Client driver lets Kepware consume external OPC UA servers as upstream data sources. This is the aggregation pattern: many OPC UA servers (embedded controller servers, vendor-supplied servers, edge gateways) feed into a single Kepware instance, which re-exposes the consolidated tag space through its own OPC UA server endpoint to the consuming SCADA, MES, or cloud platform.

Aggregation matters because controllers increasingly ship with native OPC UA support, but each controller’s address space is shaped by the vendor. Without aggregation, the downstream consumer has to know the schemas of every controller. With aggregation, one Kepware instance presents a unified, normalised view, with consistent naming, consistent units, and consistent security applied across the estate.

Kepware OPC UA PubSub and IoT Gateway

The Kepware IoT Gateway agent publishes data to multiple targets simultaneously: MQTT (including Sparkplug B), AWS IoT, Azure IoT, REST endpoints, and OPC UA PubSub (IEC 62541 Part 14) for many-to-many IIoT scenarios. The same Kepware instance can act as a traditional client-server OPC UA endpoint and as a publisher into a PubSub broker, often into a Unified Namespace MQTT broker that other OT and IT consumers subscribe from.

This dual role is what makes Kepware the practical backbone of UNS deployments. The OPC UA server endpoint serves traditional consumers (HMIs, historians, MES) that want a session-oriented connection. The PubSub publisher feeds the broker that newer cloud-native and event-driven consumers prefer. Both come from the same configured tag space, with the same security model.

TT PSC’s field experience: patterns that work

Across the projects TT PSC has delivered as a Velotic Authorised Partner and Kepware certified integrator, four deployment patterns repeat themselves.

Pattern 1: Single Kepware server in the OT zone. A single KEPServerEX instance hosted in the OT network, with an OPC UA endpoint exposed inward to the MES through a firewall pinhole. Smallest pattern, lowest cost, fits sites with one production line and one consuming system. Used as the starting pattern for most pilots before scaling to other patterns.

Pattern 2: Redundant Kepware pair for high availability. Two Kepware instances configured in primary/secondary redundancy, with Kepware’s built-in redundancy management handling failover. Used where downtime cost is high enough to justify the licensing and the operational complexity. Typical in continuous process industries (pharma, food and beverage, utilities).

Pattern 3: Edge Kepware plus central Kepware aggregation. Kepware Edge instances on each line or cell, connecting locally to controllers and exposing OPC UA to a central Kepware instance that aggregates across the site or across multiple sites. Used where the network between edge and centre is unreliable, or where latency from edge to centre is too high for direct controller connectivity.

Pattern 4: UNS bridge with MQTT broker. Kepware as the OPC UA-to-MQTT bridge, publishing standardised data into a central MQTT broker (often with Sparkplug B), with downstream OT and IT consumers subscribing from the broker rather than connecting to Kepware directly. Used for multi-site, multi-consumer deployments where the broker-mediated Unified Namespace pattern reduces integration effort across the estate.

For organisations evaluating which of these patterns fits their environment, or wanting a production-grade OPC UA server architecture designed and deployed to a delivery contract, our OPC UA server industrial deployment service covers the full scope from assessment to handover.

---

FAQ: OPC UA questions answered

1. What does OPC UA stand for? OPC UA is short for Open Platform Communications Unified Architecture. It is an open machine-to-machine communication protocol for industrial systems, standardised internationally as IEC 62541 and maintained by the OPC Foundation.

2. Is OPC UA free? The OPC UA specification is free to download from the OPC Foundation. Commercial OPC UA implementations such as Kepware require a commercial licence; open-source stacks (open62541, Eclipse Milo) are also available under their own licences. „Free specification” and „free deployment” are different things.

3. Is OPC UA secure? Yes. OPC UA was designed with security as a core requirement. Certificate-based mutual authentication, encrypted and signed messages (SignAndEncrypt mode), and configurable security policies such as Basic256Sha256 and Aes256_Sha256_RsaPss are all part of the standard.

4. What port does OPC UA use? The default port for OPC.TCP is port 4840, IANA-registered. HTTPS uses port 443. The Kepware OPC UA server uses port 49320 by default, configurable. Always confirm the exact port in the specific server documentation before opening firewalls.

5. What is the difference between OPC UA and OPC DA? OPC DA is Windows-only, based on COM and DCOM, with no native security and a flat tag list data model. OPC UA is cross-platform, encrypted by default, and exposes a self-describing typed information model. OPC UA is the actively maintained replacement for OPC DA.

6. Is OPC UA replacing Modbus? No. Modbus operates at the device-to-controller layer, OPC UA at the controller-to-IT layer. Modern architectures use both: Modbus stays close to the device, and OPC UA aggregates Modbus data and exposes it semantically through a connectivity platform such as Kepware.

7. What is OPC UA PubSub? OPC UA PubSub (IEC 62541 Part 14) is the publish-subscribe extension to OPC UA. It supports MQTT, UDP, and AMQP transports. It is designed for many-to-many IIoT scenarios where the request/response client-server model is too restrictive.

8. Can OPC UA run in the cloud? Yes. Azure IoT Edge OPC Publisher, AWS IoT SiteWise, and Google Cloud Manufacturing Data Engine all natively ingest OPC UA. The HTTPS and PubSub bindings make OPC UA cloud-friendly. AWS cloud reference architectures position OPC UA as the preferred plant-side data source.

9. What is an OPC UA companion specification? An industry-specific extension to the OPC UA information model. UMATI for machine tools, PA-DIM for process automation, AutoID for RFID readers, OPC UA for Robotics, and dozens more. Companion specifications ensure that vendors expose the same concepts the same way.

10. Is OPC UA the same as IEC 62541? Yes. IEC 62541 is the international standardisation of the OPC UA specification originally maintained by the OPC Foundation. The two terms refer to the same technology, often used interchangeably in procurement and audit documents.

11. What is OPC UA FX? OPC UA FX (Field eXchange), released in 2022, extends OPC UA to controller-to-controller communication with deterministic timing, often combined with TSN (Time-Sensitive Networking). It brings OPC UA into territory historically dominated by EtherNet/IP and PROFINET.

12. What is the OPC UA information model? The information model is the typed, structured catalogue of nodes that an OPC UA server exposes: Variables, Objects, Methods, References. The information model makes the data self-describing, so clients understand semantics, not just numerical values.

13. Does OPC UA require certificates? Every OPC UA application has an X.509 certificate. Connections can run with security policy None and security mode None for laboratory use. Production deployments should always use Basic256Sha256 (or stronger) and SignAndEncrypt.

14. What is Reverse Connect in OPC UA? Reverse Connect is a connection pattern where the OPC UA server initiates the TCP connection outbound to the client, instead of the client connecting inbound. It is essential when the OT network has no inbound firewall openings.

15. What is OPC UA over MQTT? OPC UA over MQTT is a PubSub binding (IEC 62541 Part 14) that carries OPC UA-encoded data through an MQTT broker. It combines the OPC UA information model with MQTT’s lightweight publish-subscribe transport.

16. What is the Unified Namespace (UNS)? UNS is an architectural pattern where one MQTT broker serves as the single source of truth for all plant data. OPC UA edge servers publish into the broker (via PubSub or Sparkplug B), and any OT or IT consumer subscribes from the same broker.

17. Does Kepware support OPC UA? Yes. Kepware Server runs as a native OPC UA server on port 49320 by default and can also act as an OPC UA client to aggregate external OPC UA servers. TT PSC, as a Velotic Authorised Partner and certified Kepware system integrator, deploys Kepware-based OPC UA architectures across European and global plants. See how we deploy Kepware in production.

18. How do I migrate from OPC DA to OPC UA? The most common path is to install an OPC DA-to-UA gateway (such as Kepware with the OPC DA Client driver) that exposes the legacy DA server as a UA endpoint, then migrate clients incrementally and decommission the DA endpoint last.

19. Is OPC UA an alternative to MQTT? Not directly. MQTT is a lightweight transport (a publish-subscribe message broker protocol). OPC UA is a full architecture (information model plus security plus services plus transports). They are increasingly used together via OPC UA PubSub over MQTT or via Sparkplug B in UNS architectures.

20. What is OPC UA TSN? TSN (Time-Sensitive Networking) is a set of IEEE 802.1 standards for deterministic Ethernet. OPC UA over TSN, typically combined with OPC UA FX, enables deterministic controller-to-controller communication. TSN itself is not part of OPC UA; the two specifications cooperate at the network layer.

---

Implement OPC UA with TT PSC

Choosing OPC UA as the standard is the easy decision. Designing the security model, planning the migration, deploying redundant endpoints across multiple sites, and operating the certificate lifecycle – that is where the engineering work concentrates, and where an experienced integrator changes the outcome.

TT PSC is a Velotic Authorised Partner and certified Kepware system integrator operating across Europe and the Middle East. We design, deploy, and harden OPC UA architectures: from single-server pilots through redundant pairs to multi-site Unified Namespace rollouts. Our engineers have delivered these architectures into production at manufacturers, utilities, and process industries under fixed-delivery contracts.

Where are you starting from?

• OT security pressure – NIS2, IEC 62443, upcoming audit → OT Security & Data Assessment – we map your OT network exposure and compliance gaps without stopping the line.
• Digital transformation initiative blocked by inconsistent or unavailable machine data → Industrial Data Backbone – we build the connectivity and data architecture layer that makes MES, cloud, and AI initiatives scale beyond a single site.
• OEE problem, no budget for a large IT project → Smart Factory Quick-Win – we physically connect to your critical machines in six weeks and deliver automated, objective production data. No manual entry, no large IT risk.

For a delivery-contract scope around a specific OPC UA deployment, the OPC UA server industrial deployment service describes the assessment, design, and handover phases in full.