What is an OPC Server? Role, Architecture & Selection Guide

What is an OPC server?

An OPC server is a software application that translates a device's proprietary communication protocol into a standardized OPC interface, making the device's data accessible to any OPC-compliant client application without custom integration code. It is, in practical terms, a universal translator and data broker for industrial hardware.

Before OPC, connecting a new application to a PLC or DCS required writing a custom driver for that specific combination of software and hardware. OPC changed the equation by establishing a common interface standard. A device vendor writes one OPC server that implements that standard. Any application that supports OPC as a client can then connect to it. The driver problem becomes write-once, use-many.

Every OPC server performs the same fundamental job: it accepts requests from one or more OPC clients, fetches the requested data from the device using the device's native protocol, and returns the data in OPC-standard format with a value, a quality stamp, and a timestamp. What differentiates one OPC server from another is the number of devices and protocols it supports, the performance and reliability of that translation, and the additional capabilities it provides around diagnostics, security, redundancy, and integration.

What an OPC server actually does

The description "protocol converter" is accurate but incomplete. A production-grade OPC server does considerably more than translate one protocol to another. Here is the full set of responsibilities a well-designed OPC server handles:

Protocol translation

Communicates with devices using their native protocol, Modbus RTU, EtherNet/IP, S7, DNP3, Profibus, or hundreds of others, and exposes the resulting data through a standardized OPC interface that any compliant client can consume.

Data caching

Maintains an internal cache of the most recently polled values. When multiple clients request the same tag, the server serves them all from the cache in a single polling cycle rather than generating separate device requests for each client. This is fundamental to protecting device communication from being overloaded by upstream application demands.

Subscription management

Tracks each client's subscriptions, the specific tags they want, at the update rates they specify, and notifies clients when values change. Clients do not have to poll continuously; the server handles the polling and delivers updates only when values change, which is more efficient for both the network and the devices.

Address space management

Maintains a browsable directory of all available tags across every connected device, the address space. Clients can browse this directory to discover what data is available, which eliminates the need for a manual tag import step in every upstream application.

Quality and timestamp stamping

Attaches a quality code (Good, Bad, Uncertain) and a UTC timestamp to every data item. These allow client applications to know whether a value can be trusted and when it was last verified as accurate, which is essential for any application that acts on process data or stores it in a historian.

Write-back to devices

Accepts write requests from authorized clients and forwards them to the device using the device's native write protocol. A SCADA system can change a setpoint or reset a latch via an OPC write, which the server translates into the appropriate Modbus write, EtherNet/IP message, or other device-specific operation.

What is inside an OPC server

Understanding the internal structure of an OPC server helps engineers troubleshoot behavior that can otherwise seem unpredictable, particularly around when devices get polled and where data comes from when a client reads it.

OPC interface

The client-facing layer

Implements the OPC standard (DA, UA, HDA, A&E) and handles all communication with connected client applications: session management, subscription creation, address space browsing, read and write requests, security authentication. This is the layer that makes the server look identical to a client regardless of what hardware is underneath it.

Data cache

The internal data broker

Stores the last known value, quality, and timestamp for every active tag. When a client requests a value, the server checks the cache first. Serving from cache is fast and does not generate device traffic. The cache is refreshed at the polling rate configured for each device or channel. Multiple clients reading the same tag all receive data from the same cache entry, so adding more clients does not proportionally increase device polling load.

Device driver

The device-facing layer

The driver is protocol-specific code that knows how to communicate with a particular type of hardware: how to open the connection, frame a request, parse the response, and map register addresses or memory areas to named tags. Each device type or protocol family requires its own driver. This is why driver breadth is one of the most significant differentiators between OPC server products.

Configuration engine

The server management layer

Stores channel definitions, device connections, tag configurations, polling rates, security settings, and logging rules. A production-grade OPC server provides a management interface for monitoring server health, diagnosing communication errors, reviewing event logs, and adjusting configuration without restarting the server. This layer is what separates a tool adequate for a test bench from one that can be managed 24/7 in a production environment.

How an OPC server polls devices: the behavior engineers need to know

One of the most common misconceptions about OPC servers is that they poll devices continuously as soon as they are configured. In reality, most OPC servers operate on a demand-driven model: they only poll devices when a connected client has subscribed to data from that device.

Key behavior in TOP Server: When a channel and device are defined in TOP Server, the server does not immediately attempt to initiate a connection or request data. Instead, it waits until a connected client specifically requests information from that device before reaching out. Furthermore, TOP Server only requests the tags the client has subscribed to, if 1,000 tags are configured but the client only subscribes to 100, only those 100 are polled.

This is efficient by design: it means configuring many devices and tags upfront does not create unnecessary polling load until something actually needs those values.

Vendor-supplied OPC servers vs third-party OPC servers

When a PLC or device manufacturer says their hardware "supports OPC," they almost always mean they have OPC server software available for that hardware, not that the OPC server is embedded in the device itself. Understanding the distinction between vendor-supplied and third-party OPC servers matters when evaluating connectivity options.

Vendor-supplied OPC server

From the hardware manufacturer

Covers that vendor's hardware only
May require separate licensing fees beyond the hardware cost
Configuration tool tied to that vendor's environment
Support from the hardware vendor's software team
Driver quality and update frequency varies by vendor
Appropriate when a plant uses only one PLC brand and does not need multi-vendor consolidation
Some modern PLCs (Siemens S7-1500, Beckhoff) embed OPC UA servers directly in firmware, removing the need for separate server software entirely

Third-party OPC server

Vendor-neutral connectivity platform

Supports hundreds of devices and protocols from a single installation
Single configuration environment for all connected devices
Single support relationship regardless of which devices are connected
Consistent feature set (redundancy, diagnostics, security, logging) across all drivers
Driver library maintained by a team focused exclusively on connectivity
Usually the right choice in any multi-vendor environment, which describes virtually every real plant
Supports OPC DA, UA, HDA, and A&E simultaneously, regardless of which protocols each device natively supports

The realistic plant floor: Most production facilities have PLCs from two or three different manufacturers, legacy devices from vendors who may no longer exist, flow computers and analyzers with obscure serial protocols, and newer edge devices with OPC UA built in. No single vendor's OPC server covers all of that. TOP Server's 140+ driver library exists specifically to handle this reality from a single managed installation.

OPC server redundancy: hot, warm, and cold

In processes where an OPC server failure would mean loss of visibility into critical equipment, or would cause a historian gap that creates compliance problems, redundancy is a standard requirement. There are three practical redundancy models for OPC servers, each trading off failover speed against the cost of maintaining the redundant state.

Hot redundancy

Both primary and backup servers run simultaneously and poll devices actively
Failover is nearly instantaneous: no reconnect or re-subscription required
Cache is always current on both servers
Cost: both servers generate polling traffic to devices, which increases load on the control network and hardware

Best for: critical processes where any data gap is unacceptable

Warm redundancy

Backup server maintains a connection to the OPC server but items are not actively subscribed
At failover, the backup activates subscriptions immediately without needing to establish a new connection
Short failover bump time: seconds, not minutes
Lower device polling load than hot redundancy

Best for: most production environments as a balance of speed and cost

Cold redundancy

Backup server is configured but idle: no connection to the primary OPC server until failover
At failover, the backup must establish a connection and activate all subscriptions from scratch
Longer failover time: depends on how many tags need to be re-established
No additional polling load during normal operation

Best for: lower-criticality applications or when device polling load is a constraint

Cogent DataHub for OPC redundancy: Cogent DataHub supports hot, warm, and cold redundancy for OPC DA and OPC UA servers. It can monitor which server is active, automatically failover when the primary becomes unavailable, and log every failover event to a database or send an alert to operations staff. It handles redundancy at the middleware layer without requiring modifications to either the OPC servers or the client applications connected to them.

How to choose the right OPC server

For engineers evaluating OPC server options, these are the criteria that matter in practice:

📄
Driver coverage for your specific devices. List every device in scope, including make, model, and firmware version. Verify the OPC server has a specific driver for each, not just generic Modbus or EtherNet/IP support. Generic protocol support often means device-specific register maps, data type handling, or communication quirks are not accounted for. Ask for a trial and test against real hardware before purchasing.
⏰
OPC protocol support: DA, UA, HDA, A&E. Determine which protocols your client applications require. If your SCADA is OPC DA-only today but you plan to move toward OPC UA for IIoT integration, a server that supports both protocols simultaneously from the same driver configuration saves a migration later. TOP Server supports all four OPC specifications on the same installation.
⭐
Diagnostics and operational tooling. A server that connects reliably is necessary. A server that tells you clearly why it is not connecting is what you actually need at 2 AM during a plant outage. Evaluate the event logging, communication diagnostics, tag-level quality visibility, and live monitoring capabilities as rigorously as you evaluate the connectivity itself.
🏠
Performance and tag capacity. Establish the number of tags, devices, and client connections your deployment requires, then add headroom for growth. Ask the vendor for benchmark data at scale. An OPC server that handles 500 tags well may not handle 50,000 with the same update rates. Understand polling architecture: does adding a second client double device polling, or is the server cache shared?
🛡️
Security for OPC UA deployments. If deploying OPC UA, verify that the server's certificate management, endpoint security policy configuration, and user authentication are production-ready, not just present. A server that passes OPC UA Lab Certification from the OPC Foundation has been tested for correct security implementation against an independent compliance test suite.
📊
Support quality and track record. OPC server problems frequently surface in the middle of production issues. Evaluate the vendor's support team: do they have engineers who understand both OPC standards and industrial automation? Is there a knowledge base that covers real-world DCOM configuration, certificate troubleshooting, and driver-specific issues? Software Toolbox has published practical OPC support content publicly for nearly a decade for exactly this reason.

Frequently asked questions

Does an OPC server need to run on the same machine as the device?+−

No. An OPC server runs on a Windows PC (for OPC DA) or any supported platform (for OPC UA), and communicates with the device over a network connection. Most OPC servers communicate with devices over Ethernet using TCP/IP-based protocols like Modbus TCP, EtherNet/IP, or S7 Ethernet, and the server machine and device can be on the same network segment without any requirement for physical co-location.

Some devices with serial interfaces (Modbus RTU, older DCS protocols) require the OPC server machine to have a serial port connection or an Ethernet-to-serial converter in the communication path. In these cases, physical proximity may be a practical consideration but not a technical requirement imposed by OPC itself.

Can one OPC server connect to multiple devices simultaneously?+−

Yes, and this is one of the primary reasons third-party OPC servers like TOP Server exist. A single TOP Server installation can maintain simultaneous connections to dozens or hundreds of devices across many different protocols. Each device is configured as a separate connection (called a channel and device in TOP Server terminology), and the server manages polling, caching, and client subscriptions independently for each.

This consolidation is architecturally valuable: all the devices in your plant appear as a single unified address space to any OPC client, regardless of how many different device types and protocols are involved. A historian client does not need to know or care that tag A comes from a Modbus RTU device and tag B comes from a Siemens S7 PLC; it just subscribes to both through the same OPC connection.

Can multiple clients connect to the same OPC server at the same time?+−

Yes. This is a fundamental design goal of OPC. A single OPC server can serve many concurrent client connections. Each client gets its own session and can maintain independent subscriptions at different update rates from other clients. The server maintains one internal polling cycle to the device and serves all clients from the resulting cache, so additional clients do not proportionally increase device polling load.

Practical limits depend on the server software, hardware resources, and the combined tag and update rate demands of all clients. TOP Server is designed for multi-client production environments and handles dozens of simultaneous client connections under typical plant conditions without performance degradation.

My device vendor says their hardware "supports OPC." Do I still need a separate OPC server?+−

Usually yes, but verify first. When hardware vendors say they "support OPC," they typically mean one of three things:

They have an OPC server software product that runs on a Windows PC and connects to their hardware. This is the most common meaning. You would need to install and license that software separately.
They have embedded OPC UA in the firmware. Some modern controllers (Siemens S7-1500, Beckhoff CX series, and others) embed OPC UA servers directly in the PLC. If your client applications support OPC UA, you may be able to connect directly without a separate server software installation.
They support a generic protocol (like Modbus or EtherNet/IP) that an OPC server with the appropriate driver can connect to. This is technically indirect OPC support, not a native OPC implementation.

In multi-vendor environments, even if each individual vendor has their own OPC server software, consolidating connectivity into a single third-party OPC server typically reduces licensing complexity, support overhead, and configuration management effort.

What is the difference between an OPC server and a device driver?+−

A device driver is a component inside the OPC server, the protocol-specific piece that knows how to communicate with a particular type of hardware. The OPC server is the complete application that houses one or more drivers, manages the data cache, serves the OPC interface to clients, handles security and session management, and provides configuration and diagnostic tooling.

Think of it this way: the OPC server is the building, and the device drivers are the specialized translators who work inside it. Each translator speaks one device language. The building manages everything else, the reception desk (OPC interface), the filing system (cache), the access control (security), and the building management system (diagnostics). You need the whole building to have a functioning OPC deployment, not just the translators.

Does adding more OPC clients increase polling load on my devices?+−

In a well-designed OPC server, no. The server maintains a single polling cycle to each device, stores the results in an internal cache, and serves all connected clients from that cache. A second or tenth client subscribing to the same tags does not generate additional device requests; it receives the same cached values on the same update cycle.

There is a caveat: if different clients request different tags, the server must poll the device for the union of all requested tags. And if different clients request very different update rates for the same tags, the server typically polls at the fastest requested rate and serves slower clients from the resulting cache. The key principle is that the server optimizes device communication on behalf of all clients rather than letting each client independently poll the device.

What is an OPC server?