Using OPC UA as an Open Protocol for SCADA and HMI Communication

Why the move to structured, secure, vendor-neutral communication is one of the most important architectural decisions a plant can make.

The Shift Toward Open Industrial Communication

Industrial automation is in the middle of a quiet but fundamental shift. For decades, SCADA and HMI communication relied heavily on vendor-specific drivers, memory mapping, and tightly coupled architectures. These systems worked. Plants ran on them for years, sometimes decades, without anyone questioning the approach. But they created technical debt that many organisations are still paying for today.

OPC UA changes that model completely. Instead of building communication around fixed memory addresses or proprietary protocols, OPC UA introduces a structured, secure, and vendor-neutral way to exchange data between controllers, SCADA systems, and enterprise platforms. The impact of this goes well beyond the communication layer itself. It directly affects maintainability, cybersecurity posture, scalability, and long-term project cost.

Many organisations already have PLCs capable of running OPC UA servers, especially modern Siemens S7-1500s, Rockwell CompactLogix and ControlLogix controllers, and CODESYS-based platforms. The barrier is rarely hardware capability. The real challenge is architecture design and implementation strategy. Getting OPC UA running is straightforward. Getting it running well, in a way that delivers the long-term benefits, requires deliberate planning.

In this article we’ll explore why OPC UA is rapidly becoming the default for SCADA and HMI communication, where traditional approaches fall short as plants grow, and how organisations can adopt OPC UA safely and effectively without creating new categories of technical debt in the process.

Why Traditional SCADA Communication Architectures Struggle at Scale

Most legacy SCADA communication architectures share common characteristics. They use direct memory address mapping between PLC and HMI. They depend on vendor-specific communication drivers. They have limited or nonexistent security models. And they create tight coupling between the PLC program structure and the SCADA system design.

These limitations might not be obvious in small systems. A single PLC connected to a single HMI panel on one machine can work perfectly well with direct memory addressing. The problems emerge when systems grow. When you add more PLCs, more HMI stations, more production lines, more sites. That’s when the architecture either scales gracefully or starts falling apart.

Memory Address Dependency. Traditional SCADA systems often reference PLC data using absolute addresses. In Siemens systems, that might be DB100.DBW0. In Allen-Bradley, it could be N7:20. In CODESYS, something like %MW200. These addresses are tied directly to the internal memory layout of the PLC program.

This creates fragility. Any PLC modification that shifts memory layout risks breaking the SCADA communication. Reorganise a data block in TIA Portal, and suddenly every HMI tag pointing into that DB needs updating. Engineers become afraid to refactor code because they know it may break downstream systems. Over time, this fear of modification leads to the same kind of copy-paste culture that affects poorly documented projects. People duplicate rather than improve because improvement carries risk.

I’ve worked on projects where a simple data block restructuring cascaded into three days of HMI reconfiguration, testing, and validation across multiple operator stations. The PLC change itself took twenty minutes. Everything else was downstream cleanup because the communication architecture created unnecessary coupling.

Vendor Lock-In. Many legacy SCADA implementations rely on vendor-specific drivers. WinCC talks to Siemens PLCs using MPI or PROFINET natively. FactoryTalk talks to Rockwell controllers using EtherNet/IP. These connections work well within their own ecosystems, but cross-vendor integration becomes expensive and time-consuming.

The practical impact is that organisations end up making major platform decisions based on communication compatibility rather than technical merit. If your plant runs Siemens PLCs and you want to evaluate an alternative SCADA platform, the first question is always “does it have a Siemens driver?” rather than “is it the best platform for our needs?” That’s not a technology decision. That’s a lock-in tax.

Weak Security Models. Older protocols like Modbus TCP and the original OPC DA (DCOM-based) were never designed for modern network environments. They assumed trusted, isolated plant networks where every device on the network was legitimate. That assumption was reasonable in 1995. Today, plants are connected to corporate networks, cloud analytics platforms, remote support environments, and sometimes the public internet. The security expectations are dramatically higher, and legacy protocols simply cannot meet them without extensive workarounds.

Wrapping an insecure protocol in VPNs and firewalls helps, but it adds complexity and creates a brittle security model. Every additional layer of network protection is another thing that can fail, misconfigure, or create latency problems.

Limited Metadata. Traditional protocols move values and nothing else. A tag value of 74.3 arrives at the SCADA system with no built-in context. Is that degrees Celsius or Fahrenheit? Is it within the expected range? What equipment does it belong to? What engineering units apply? All of that context has to be manually configured on the SCADA side, creating parallel maintenance burdens. Change the scaling on a PLC analogue input and you need to remember to change the corresponding configuration in the SCADA system. Forget, and you have a silent data integrity problem that might not surface for months.

What Makes OPC UA Fundamentally Different

OPC UA addresses each of these limitations, but understanding how it does so matters more than knowing that it does. The real value of OPC UA comes from its architecture, and that architecture needs to be understood properly for implementations to deliver on the promise.

Symbolic Tag Resolution. Instead of referencing memory addresses, OPC UA exposes variables by name and structure. A SCADA system connecting to a PLC via OPC UA references a tag called something like Pump_401.RunFeedback rather than DB100.DBX4.0. If the PLC memory layout changes internally, if the data block gets reorganised, if the program gets refactored, OPC UA clients do not need to change as long as the symbol names remain consistent.

This single feature removes a huge amount of long-term maintenance risk. Engineers can refactor their PLC code without worrying about breaking every downstream system that reads from it. That freedom to improve without fear is worth more than most people realise. Over a ten or twenty year plant lifecycle, the ability to continuously improve your PLC code without cascading integration breakage saves hundreds of engineering hours.

In TIA Portal specifically, this works because the OPC UA server exposes the symbolic names defined in the program. If you name your variables clearly and maintain a consistent naming convention, the OPC UA interface effectively becomes self-documenting. A client browsing the server can see exactly what data is available, how it’s structured, and what it’s called, without needing a separate tag mapping document.

Structured Data Models. OPC UA allows data to be exposed in logical hierarchies rather than flat tag lists. A well-designed OPC UA server presents data the way engineers think about systems: organised by plant area, by system, by asset, by parameter group. A typical hierarchy might look like Plant, then Area, then System, then Asset, then Parameters.

This mirrors the physical and logical structure of the plant itself. When someone browses the OPC UA server to find a particular data point, they navigate through a tree that makes intuitive sense. They don’t scroll through a flat list of ten thousand tags trying to find the right one.

For organisations using asset-oriented programming approaches in their PLC design, OPC UA is a natural fit. The data model in the PLC can be reflected directly in the OPC UA namespace. The structure the engineer creates in TIA Portal or CODESYS becomes the structure that SCADA systems, historians, and analytics platforms see. There’s one logical model, shared across the entire system, rather than parallel structures that need to be kept in sync manually.

Built-In Security. OPC UA includes encryption, authentication, and certificate-based trust models as core features of the protocol. Security is part of the specification, defined alongside the data exchange mechanisms, tested as part of conformance certification, and expected by every compliant implementation.

This matters because it means security decisions happen at design time rather than being retrofitted later. When you configure an OPC UA server, you choose a security policy. When a client connects, both sides negotiate encryption and authenticate using certificates. There’s no ambiguity about whether the connection is secure. The protocol enforces it.

Compare that to Modbus TCP, where every byte travels in plain text with no authentication whatsoever. Or to OPC DA, which relied on DCOM security, a model that was widely acknowledged as painful to configure and unreliable across network boundaries. OPC UA’s security model isn’t perfect (nothing is), but it’s designed for purpose in a way that legacy protocols simply were not.

Platform Independence. Any OPC UA client can connect to any OPC UA server if certificates and permissions are configured correctly. This is true regardless of the hardware vendor, the operating system, or the programming environment. A Siemens PLC can serve data to a Rockwell HMI. A CODESYS controller can feed data into an open-source analytics platform. A Linux-based edge gateway can aggregate data from controllers made by five different manufacturers.

This enables real vendor independence. Not theoretical independence. Practical, tested, deployed independence. Organisations can evaluate platforms on their merits because the communication layer is no longer a constraint.

Real-World Advantages in SCADA and HMI Systems

The architectural benefits of OPC UA translate into specific, measurable advantages in everyday engineering work. These aren’t future promises. They’re outcomes that organisations experience as soon as implementations are running.

Easier HMI Platform Changes. With OPC UA, SCADA systems become loosely coupled from the PLC implementation. The interface between them is defined by the OPC UA namespace, which is a logical data model rather than a memory map. If an organisation wants to change HMI vendors, whether that’s moving from WinCC to Ignition, from FactoryTalk to AVEVA, or from any platform to any other platform, the PLC interface layer can remain largely unchanged.

This is extremely valuable for long-lifecycle plants. A plant that was built with a 25-year operational horizon will almost certainly outlive its original HMI platform. If the communication architecture allows the HMI to be replaced without touching the PLC programs, that replacement becomes a manageable project rather than a wholesale system redesign.

I’ve been involved in HMI migration projects where the communication architecture was the single biggest factor in determining project scope. When the original system used proprietary drivers with memory-mapped tags, the migration required re-engineering every tag connection from scratch. When OPC UA was already in place, the new SCADA system could browse the same server, connect to the same symbolic tags, and the migration focused on screen design rather than data plumbing.

Faster Commissioning. Because OPC UA supports browsing, SCADA configuration can be partially automated. Engineers can discover available data points directly from the PLC rather than working from a manually maintained tag export spreadsheet that may or may not reflect the current state of the PLC program.

In practice, this means commissioning engineers can connect a client to the PLC, browse the available data, and configure SCADA tags with confidence that they’re connecting to the right variables. There’s no manual cross-referencing between a tag list and the PLC program. The OPC UA server is the tag list, and it’s always up to date because it’s generated directly from the PLC program.

Better Support for Asset-Oriented Architectures. OPC UA naturally supports asset-based structures. This aligns perfectly with modern automation design philosophies where code is organised around physical assets rather than arbitrary program structures. If your PLC program models a pump as a UDT with run commands, feedback signals, alarm parameters, and diagnostic data, OPC UA can expose that entire structure as a single browsable node. The SCADA system sees the pump as a coherent object, not as a collection of unrelated tags scattered across different data blocks.

This alignment between PLC architecture and communication interface reinforces good programming practices. Engineers who design their PLC programs well get better OPC UA interfaces automatically. The incentive structure works in the right direction.

Simplified Integration With IT Systems. OPC UA is designed for interoperability beyond the plant floor. MES systems, cloud analytics platforms, data historians, predictive maintenance tools, and digital twin environments can all interact with PLC data using the same interface. There’s no need for separate middleware, gateway applications, or custom integration code for each consumer of the data.

This is increasingly important as organisations pursue Industry 4.0 initiatives. The factories that struggle with digital transformation are almost always the ones where getting data out of the control layer requires custom engineering for every new consumer. OPC UA creates a single, standard interface that can serve all of them.

Common Pitfalls When Implementing OPC UA

OPC UA is powerful, but poor implementation can negate many of its advantages. I’ve seen projects where OPC UA was adopted enthusiastically but implemented in ways that recreated the same problems the old architecture had, with extra complexity on top.

Treating OPC UA Like a Tag Pipe. The most common mistake is exposing thousands of flat variables with no structure, no grouping, and no logical hierarchy. Someone configures the PLC’s OPC UA server to expose every tag in the program, drops them all into a flat namespace, and calls it done.

This technically works. Clients can connect and read values. But it wastes the modelling capabilities of OPC UA entirely. You end up with a system that’s functionally equivalent to an OPC DA server with symbolic names instead of memory addresses. The browsing capability becomes useless because there’s no meaningful structure to browse. The information model that makes OPC UA valuable is simply not there.

Good OPC UA implementations require deliberate namespace design. That means thinking about how data should be organised, what groupings make sense for the consumers of the data, and how the structure will scale as the system grows. This is architecture work. It takes planning. It pays for itself many times over.

Ignoring Certificate Management. Certificate management must be treated as part of system design, not an afterthought. OPC UA uses X.509 certificates for authentication and encryption. Every server has a certificate. Every client has a certificate. Trust relationships must be established between them.

In small systems with one PLC and one SCADA server, this is manageable manually. In large plants with dozens of controllers and multiple client applications, manual certificate management becomes a support nightmare. Certificates expire. New devices get added. Old devices get replaced. If there’s no process for managing this, eventually a certificate expires at two in the morning and communication stops until someone figures out why.

The time to design your certificate management process is before the first OPC UA connection goes live. Not six months later when something breaks.

Overloading PLC CPU Resources. OPC UA servers consume controller resources. The server runs inside the PLC alongside the control program, sharing CPU time and memory. Poorly configured subscription rates, excessively large data sets, or too many concurrent client connections can impact PLC scan time and control performance.

This is particularly important on controllers where the OPC UA server shares the same CPU as the real-time control tasks. On a Siemens S7-1500, for example, the OPC UA server runs in the operating system alongside the user program. If twenty clients each subscribe to a thousand tags with a 100ms update rate, the communication overhead can measurably affect cycle time.

The solution is thoughtful configuration. Limit the number of exposed tags to what’s actually needed. Set appropriate subscription intervals based on how quickly data actually changes. Use OPC UA aggregation gateways when many clients need access to the same data, rather than having each client connect directly to the PLC. And test. Always test under realistic load conditions before going live.

Mixing Legacy and OPC UA Without Strategy. Hybrid architectures are common during migration. Most plants can’t switch to OPC UA overnight. Some PLCs may not support it. Some SCADA systems may need driver-based connections for certain features. The result is a period where both legacy and OPC UA communication coexist.

Without a clear strategy, this creates confusion. Which tags come from the OPC UA server? Which come from the legacy driver? Are they the same data? Is one a backup for the other? When discrepancies appear, which source is authoritative?

Hybrid periods need clear documentation of which systems use which communication path, why that choice was made, and when the legacy path will be retired. Without that roadmap, “temporary” hybrid architectures have a tendency to become permanent.

Migration Strategies From Legacy Communication Architectures

Most plants cannot migrate to OPC UA in a single project. The installed base is too large, the risk of disruption too high, and the investment too significant to do everything at once. Successful migrations are staged, with each phase delivering measurable value while reducing risk for the next phase.

Phase 1: Assessment. Before any OPC UA implementation begins, you need a clear picture of where you’re starting from. This means evaluating the existing SCADA communication methods across every system in scope, understanding which PLCs support OPC UA natively and which would need firmware upgrades or hardware replacement, reviewing network segmentation and security zones to understand where OPC UA traffic will flow, and quantifying data volumes and update rate requirements.

This assessment often reveals surprises. Controllers that were assumed to be too old might already have OPC UA capability that was never enabled. Communication architectures that were thought to be consistent across the plant might vary significantly between production lines installed in different years. Network infrastructure that seems adequate might not have the bandwidth headroom for additional OPC UA traffic.

The output of this phase is a clear, documented understanding of the current state, the target state, and the gaps between them. Without this, migration planning is guesswork.

Phase 2: Pilot Implementation. Select a low-risk system and implement OPC UA alongside the existing communication. The pilot should be representative enough to validate the approach but small enough that problems don’t affect production.

During the pilot, validate performance under realistic conditions, not just basic connectivity. Can the OPC UA server handle the required number of clients and tags without impacting PLC cycle time? Does the security configuration work reliably with the chosen SCADA platform? Can the engineering team configure and maintain the OPC UA connections without excessive effort?

Equally important is validating the operational support model. When a certificate expires during the pilot, how quickly does the team identify the cause? When a new device needs to be added to the trust store, who does it and how long does it take? These operational questions are best answered during a pilot, not during a plant-wide rollout.

Phase 3: Gradual Expansion. Expand OPC UA coverage system by system, line by line, or site by site. Each expansion should apply the lessons learned from previous phases. Common patterns include prioritising systems where HMI upgrades are already planned (since the HMI migration is happening anyway, switching to OPC UA at the same time adds minimal incremental work), starting with the newest controllers that have the best OPC UA support, and targeting areas where the legacy communication architecture is causing the most maintenance problems.

Maintain legacy communication paths only where genuinely required. Every legacy connection that persists is a maintenance burden that the team will carry forward.

Phase 4: Standardisation. Once OPC UA is established across a significant portion of the plant, the focus shifts from migration to governance. This means defining and enforcing corporate standards for namespace structure (how data is organised and named in the OPC UA server), security certificate lifecycle (how certificates are issued, renewed, and revoked), naming conventions (ensuring consistency across different controllers and sites), and data modelling patterns (how assets, parameters, and hierarchies are represented).

These standards are what prevent the OPC UA implementation from degrading over time. Without them, each new system gets implemented slightly differently, and within a few years the “standard” architecture is as inconsistent as the legacy system it replaced.

Security Configuration and Certificate Management Best Practices

Security is where OPC UA can deliver massive value, but only if implemented correctly. A poorly secured OPC UA deployment can create a false sense of confidence that’s worse than no security at all, because people assume the connection is protected when it may not be.

Central Certificate Authority. Large organisations should use an internal certificate authority (CA) rather than manual certificate exchange between individual devices. A central CA simplifies trust management enormously. New devices get certificates issued by the CA. All devices trust the CA. The result is a scalable trust model rather than an n-squared problem where every device needs to individually trust every other device.

For smaller installations, manual certificate exchange is workable. But the crossover point comes sooner than most people expect. Once you have more than about ten OPC UA endpoints, the management overhead of individual certificate trust starts to become significant.

Environment Separation. Development, test, and production environments should use separate trust stores and separate certificate hierarchies. A development machine should not be able to connect to a production OPC UA server simply because someone once trusted its certificate during testing. Environment separation prevents accidental cross-contamination and limits the blast radius of security incidents.

Automated Certificate Renewal. Certificates expire. That’s by design, because expired certificates force periodic re-validation of trust relationships. But if renewal is a manual process, it’s only a matter of time before someone forgets and a certificate expires during production, killing communication until it gets resolved.

Automation doesn’t have to be complex. Even a simple monitoring system that alerts when certificates are approaching expiry gives the team time to act before an outage occurs. More mature organisations implement fully automated renewal using protocols like EST (Enrolment over Secure Transport) or ACME adapted for OPC UA environments.

Role-Based Access. OPC UA supports role-based security. Different clients can have different permissions. A SCADA system might have read and write access to process data. An analytics platform might have read-only access. A maintenance laptop might have access to diagnostic data but not to control commands.

Too many implementations give every client full access because it’s easier to configure. This works until someone connects a tool that shouldn’t have write access and accidentally modifies a setpoint, or until an auditor asks why your data historian has write access to safety-critical parameters. Configuring appropriate access levels takes a small amount of additional effort during setup but eliminates an entire category of risk.

Real-World Deployment Patterns

Different plant architectures and operational requirements call for different OPC UA deployment patterns. Understanding which pattern fits which situation prevents over-engineering simple systems and under-engineering complex ones.

Pattern 1: PLC Direct to SCADA. The simplest architecture. The PLC runs an OPC UA server. The SCADA system connects directly to it as a client. There are no intermediate gateways, no middleware, no additional infrastructure.

This pattern works well for small to medium plants with a limited number of PLCs and one or two SCADA stations. The communication is straightforward, the failure modes are simple, and troubleshooting is easy because there’s only one connection to examine.

The limitation is scalability. If ten different applications all need data from the same PLC, ten direct client connections consume PLC resources. Each additional client adds load. For small numbers of clients this is fine. For large numbers, it becomes a performance concern.

Pattern 2: PLC to OPC UA Gateway to SCADA. An intermediate OPC UA aggregation server sits between the PLCs and the SCADA system. The gateway connects to each PLC as a client, aggregates the data, and serves it to downstream consumers.

This pattern is useful when aggregating data from multiple PLC vendors (the gateway handles the protocol differences), when you need to isolate the control network from the SCADA network (the gateway sits at the boundary and controls what data crosses it), or when many clients need access to the same PLC data (the gateway absorbs the client load, and the PLC only serves one connection).

The trade-off is added complexity and an additional point of failure. If the gateway goes down, all downstream communication stops. Redundancy planning is essential for this pattern.

Pattern 3: PLC to OPC UA to Enterprise Data Platform. Increasingly common in Industry 4.0 environments. PLC data is served via OPC UA to an enterprise data platform that feeds analytics, machine learning models, digital twins, and business intelligence dashboards.

This pattern typically uses OPC UA Pub/Sub rather than the traditional client-server model, pushing data to message brokers like MQTT or Kafka for consumption by multiple enterprise applications. The PLC doesn’t need to know or care how many consumers eventually use the data. It publishes to the broker, and the broker distributes.

Getting this pattern right requires collaboration between OT and IT teams. The data modelling, the network architecture, the security boundaries, and the operational support model all need input from both sides. In my experience, the projects that struggle with this pattern are almost always the ones where the OT and IT teams designed their parts independently and tried to connect them afterward.

How OPC UA Supports Long-Term Maintainability and Cost Reduction

The biggest OPC UA benefits are long-term, not day-one. On day one, you’ve added complexity. You have certificates to manage, a namespace to design, and a new technology for your team to learn. The payback comes over the following years and decades as the plant evolves.

Reduced engineering change risk is the most immediately felt benefit. Every time a PLC program gets modified, the risk of breaking downstream systems is dramatically lower with OPC UA than with memory-mapped communication. That reduced risk translates directly into engineering time saved, because change management processes can be simpler and validation efforts can be smaller.

Lower SCADA migration cost follows naturally. When the time comes to upgrade or replace the SCADA platform (and that time always comes), the OPC UA interface layer carries forward. The new platform connects to the same servers, browses the same namespaces, and reads the same symbolic tags. The migration scope is the SCADA application itself, not the entire communication infrastructure.

Improved cybersecurity posture is increasingly important as regulatory requirements tighten. Standards like IEC 62443 for industrial cybersecurity expect defence-in-depth approaches that include secure communication protocols. OPC UA’s built-in security model provides a strong foundation that auditors and regulators recognise. Legacy protocols require extensive compensating controls to achieve the same level of assurance.

Better integration with analytics and AI systems becomes relevant as organisations pursue data-driven operational improvements. The same OPC UA interface that serves the SCADA system can also serve a predictive maintenance model, a production optimisation algorithm, or a digital twin. The incremental cost of adding a new data consumer is minimal because the interface already exists.

Simplified training for new engineers is an often-overlooked benefit. OPC UA provides a consistent, standardised communication model. An engineer who understands OPC UA on one system can apply that knowledge to any other OPC UA system. Compare that to legacy architectures where every vendor, every protocol, and every custom driver has its own configuration approach. Reducing the variety of communication technologies your team needs to understand reduces training time and increases the team’s effective capacity.

Over a plant lifecycle of twenty years, these benefits compound significantly. The organisations that adopt OPC UA strategically and early in a plant’s life capture the most value. Those that wait until legacy architectures become unsupportable still get the benefits, but they also pay the migration cost that early adopters avoid.

When Organisations Should Consider External Expertise

OPC UA implementation projects benefit enormously from experience. The technology itself is well-documented, and any competent engineer can get a basic OPC UA connection working. The challenge is designing an architecture that works well at scale, that remains maintainable over the long term, and that addresses security requirements properly from the start.

External expertise is particularly valuable when migrating multi-site architectures where consistency across sites matters, when integrating multiple vendor PLC platforms into a unified communication layer, when designing enterprise-wide namespace standards that need to work for both operational and analytical use cases, and when implementing secure remote access models that satisfy both operational requirements and cybersecurity policies.

Small mistakes made early in an OPC UA implementation can create years of technical debt. A poorly designed namespace structure that works fine with fifty tags becomes unmanageable with five thousand. A certificate management approach that works for five PLCs collapses at fifty. A security configuration that passes initial review but doesn’t account for certificate rotation creates time-bomb outages.

The value of experience is knowing where these pitfalls are before encountering them. Someone who has designed OPC UA architectures for multiple plants can identify the decisions that matter most and guide the implementation away from common mistakes. That guidance is most effective at the beginning of a project, when architectural decisions are being made, rather than at the end, when problems have already been built in.

OPC UA Is Becoming the Default Standard

The trend is clear. Every major PLC vendor now supports OPC UA. Every major SCADA platform supports OPC UA. Enterprise data platforms, cloud providers, and analytics tool vendors all support OPC UA. The IEC has adopted OPC UA as a key standard for industrial communication. Industry-specific organisations like OMAC, EUROMAP, and the VDMA are defining companion specifications that standardise how OPC UA is used in specific sectors.

Organisations that adopt OPC UA strategically gain long-term flexibility, reduced lifecycle cost, and stronger cybersecurity posture. Those that delay often find themselves locked into legacy architectures that become harder and more expensive to support each year as vendor support diminishes and the pool of engineers familiar with legacy protocols shrinks.

The key is adopting OPC UA with strong architecture and governance from the beginning. The protocol provides the capability. The architecture determines whether that capability translates into real-world value. Getting the architecture right is where the real engineering challenge lies, and where the investment in proper design pays the biggest dividends over the life of the plant.