The 5 Architectural Mistakes When Choosing an OPC UA Server

OPC UA has become the standard industrial interoperability platform.
Today, dozens of products are marketed as OPC UA servers, and selecting one may appear straightforward.
However, a frequent mistake is to assume that all OPC UA servers solve the same architectural problem.
In reality, OPC UA servers available on the market fall into very different categories, each designed for a specific role within industrial architectures.
Choosing the wrong category can introduce long-term limitations in scalability, maintainability, and information modeling.
This article highlights five common architectural mistakes when selecting an OPC UA server.

Mistake 1 — Confusing Connectivity with Architecture

Many OPC UA servers are primarily connectivity platforms.
Their core objective is to:

• connect industrial devices
• collect data from PLCs and equipment
• expose variables through OPC UA

Examples include:

• Kepware KEPServerEX
• Software Toolbox TOP Server
• Softing dataFEED

These solutions are excellent industrial data gateways.
However, their configuration model typically remains tag-based.
The architectural limitation
Tag-based approaches do not naturally scale to complex industrial information models involving:

• equipment hierarchies
• structured assets
• reusable domain models
• companion specifications

Connectivity is essential, but architecture requires more than connectivity.

Mistake 2 — Using Migration Gateways as Core Infrastructure

Some OPC UA servers are designed primarily for OPC Classic migration.
Typical example:

• Unified Automation UaGateway

Their role is to translate legacy protocols such as:

• OPC DA
• OPC AE
• OPC HDA

into OPC UA.
This is extremely useful for modernizing existing infrastructures.
The architectural limitation
Migration gateways are protocol bridges, not industrial middleware.
They are optimized for compatibility, not for structuring new information architectures.
Using them as the central OPC UA infrastructure may limit long-term evolution.

Mistake 3 — Relying on Embedded OPC UA Servers

Many automation platforms embed an OPC UA server.
Examples include:

• Ignition OPC UA Server
• CODESYS OPC UA Server
• PLC-integrated OPC UA implementations

These servers are tightly integrated with:

• SCADA environments
• PLC runtimes
• automation platforms

The architectural limitation
Embedded servers are optimized for their host environment.
They may not be designed to act as independent industrial middleware layers capable of structuring complex cross-system architectures.

Mistake 4 — Treating OPC UA as a Simple Data Protocol

One of the most common misunderstandings is treating OPC UA as merely a modern communication protocol.
While OPC UA server indeed provides secure data exchange, its real power lies in:

• structured information modeling
• semantic interoperability
• companion specifications
• extensible address spaces

Using OPC UA only as a variable transport layer prevents organizations from leveraging its full architectural potential.

Mistake 5 — Ignoring Information Model Architecture

Large-scale industrial systems require structured modeling of:

• assets
• processes
• equipment
• production systems

Without a coherent information model architecture, OPC UA address spaces quickly become:

• inconsistent
• difficult to maintain
• hard to evolve

The challenge is not only exposing variables but organizing industrial knowledge in a structured address space.

A Different Approach: OPC UA Middleware

A new architectural category is emerging in the OPC UA ecosystem: