A stable Kepware setup with 20 channels and more than 6,000 items is serving the current system, while a planned recipe system could triple throughput. The decision is not simply “OPC UA or a third-party vendor”: OPC UA is a communication standard, while Kepware and Ignition are products that implement servers, clients, and device drivers.
Does the operator screen point to a tag fault or a server binding fault?
When a displayed value is bad, stale, or missing, trace its path in order: screen component, subscribed tag, OPC server connection, driver, and PLC. A display problem does not by itself identify which layer failed. First inspect the tag’s quality/status and timestamp, then inspect the server and device diagnostics for the matching tag or item.
| Reading | What it indicates | Next check |
|---|---|---|
| Tag quality is bad or uncertain | The tag is not receiving a valid, current value from its source. | Inspect the OPC connection and item/device diagnostics. |
| Tag quality is good but the screen is wrong | The issue may be in the display binding, formatting, or application logic rather than the driver path. | Compare the tag value and timestamp with the screen component’s binding and expression. |
| Many tags fail for one device | A device connection, channel, or driver issue is more likely than many independent tag errors. | Check device status, communication diagnostics, and trace logs. |
| Values update but lag under load | Polling, subscription load, server processing, or client update handling may be limiting throughput. | Record server, device, and client performance measurements under repeatable load. |
Keep tag faults separate from binding faults. An OPC server can deliver a healthy value while a screen component references the wrong tag; conversely, a correct binding cannot repair a device communication fault. Troubleshooting facilities matter because tracing, device-level status, and useful diagnostics shorten this isolation process.
Is the proposed change a protocol change or a product change?
OPC UA is the standard Ignition’s integrated server implements; it is not itself an Ignition-specific protocol. The OPC layer commonly links an application such as an HMI, logger, or transaction manager to a server whose driver communicates with PLCs. A server may also expose data to other clients. Ignition can use device drivers and provide an OPC UA server, allowing external applications to connect through a published interface rather than requiring a proprietary direct connection to the application.
Compare like with like. A third-party driver product and an OPC UA endpoint are not competing alternatives at the same layer. The real choices may be to retain the existing OPC-DA server, wrap that DA interface for UA clients, migrate to a third-party UA server, or use Ignition’s integrated UA server and drivers. The best path depends on driver coverage, stability, diagnostics, deployment requirements, and measured load—not the protocol label alone.
| Configuration | What changes | Decision effect |
|---|---|---|
| Keep existing OPC-DA server | Retain current server and its drivers; legacy DA communication remains. | Least disruptive when it already meets load, driver, and support needs. |
| Use a DA-to-UA wrapper | A wrapper exposes an existing DA server through a UA interface; the underlying DA server remains in the path. | Can bridge clients to UA without replacing the device drivers, but retains DA/DCOM setup and adds a component to operate. |
| Adopt a third-party UA server | Replace or migrate the server while potentially retaining a specialist vendor’s device drivers. | Evaluate actual UA support, driver range, diagnostic features, and performance for the target devices. |
| Use Ignition’s integrated UA server/drivers | Consolidate the Ignition connection and server functions in one product environment. | May simplify product updates and administration, but confirm required drivers and prove capacity for the workload. |
Will UA improve remote connectivity and security in this architecture?
OPC UA was designed to address limitations of OPC-DA, particularly when the client and server run on different computers. OPC-DA deployments commonly depend on Windows DCOM configuration, which can make remote setup and maintenance cumbersome. A DA-to-UA wrapper can make the client-facing interface easier to consume, but it does not eliminate the underlying DA/DCOM dependency between the wrapper and legacy server.
UA supports security mechanisms including encryption, and its binary encoding can reduce communication overhead in appropriate implementations. These are protocol capabilities, not a guarantee that a migrated installation will be faster or more secure in practice. Performance also depends on server implementation, read/write batching, array operations, polling strategy, caching, stale-data handling, network conditions, and device response. Security depends on how endpoints, certificates, identities, and policies are configured. Verify the selected product’s configuration and measure the actual system rather than treating UA adoption as an automatic performance upgrade.
Which readings establish whether the current server can handle recipe growth?
Before changing products, establish a repeatable baseline on the stable 20-channel, 6,000-plus-item Kepware system. The description also calls the load “6,000 subscriptions”; record the actual server and client counters separately, because item count and UA subscription/monitored-item counts are not interchangeable measures. Capture representative production behavior and the workloads that the recipe system will introduce.
- Record item counts, active subscriptions or monitored items, channel/device count, client count, polling or update rates, and read/write activity from the system’s actual diagnostics.
- Measure value update latency, stale or missed updates, communication errors, server resource use, and device response under normal operating conditions. Use available trace and device diagnostics to identify where delay or failure occurs.
- Repeat the measurements during a controlled load test that represents the planned recipe traffic. If recipe behavior is not yet known, define the expected operations and concurrency with the application team before sizing the trial.
- Set acceptance limits for update latency, stale data, error rate, resource headroom, and recovery before comparing candidate servers. The installation must supply those limits; do not infer them from item count alone.
- Run the same workload against each candidate with equivalent devices, clients, update rates, and diagnostics enabled. Compare measured results and document any feature or driver differences.
There is no defensible capacity conclusion from “6,000 tags” alone. The planned recipe system could increase throughput substantially, but its actual effect depends on whether it increases concurrent subscriptions, request rate, writes, array reads, or some combination. Measure those behaviors explicitly and retain enough headroom for the operating workload.
Does the candidate server have the drivers and diagnostics this plant needs?
Driver coverage and operational visibility can outweigh protocol advantages. A server may comply with an OPC specification yet lack a required PLC/device driver, or expose little useful troubleshooting information. Third-party driver vendors may support a broader device range than an integrated server; confirm the exact models and communication features needed now and on the planned roadmap. Prefer one server to house the required drivers when it simplifies operations, but treat consolidation as a preference rather than a reason to sacrifice required device support.
For each candidate, verify that operators and technicians can identify endpoint status, device/channel state, communication errors, stale values, and tracing information. Check how updates and bug fixes are obtained and how the supported driver set is maintained. A single supplier may simplify support and updates, but interoperability standards exist to let independently supplied clients and servers work together; “single source” alone is not proof of better performance or stability.
How should the OPC UA event requirement affect the migration?
Do not treat “OPC UA supports events” as proof that an application consumes them. The Ignition implementation described here did not use the event portion of UA. If the project depends on OPC Alarms & Events (AE) or UA event data, identify the exact producer, client, product version, and module support in the proposed design. Test the event path separately from ordinary tag reads and writes. If the requirement is only value exchange, event support may not decide the server choice.
What is the resolving procedure and how do you verify the selected path?
Use the following sequence to select and validate the least disruptive configuration that meets measured requirements:
- Trace any existing screen issue from component binding to tag quality, OPC connection, driver/device status, and PLC value. Resolve a binding fault at the application layer; resolve bad or stale tag quality through server/device diagnostics before using migration as a remedy.
- Inventory device models, channels, clients, item counts, actual subscription counters, required writes, recipe workload, event requirements, and needed diagnostics.
- Baseline the current server, then perform equivalent controlled load tests on viable alternatives: retain DA, wrap DA for UA clients, migrate to a third-party UA server, or use the integrated UA server and drivers.
- Select only a candidate that supports the required devices and event behavior, exposes adequate troubleshooting data, meets the pre-agreed load and update criteria, and has an acceptable maintenance path. Keep the existing configuration available during a staged migration.
- Move a representative subset of devices and clients first. Compare tag quality, value correctness, update latency, stale/missed updates, communication errors, resource use, and trace/device diagnostics against the baseline.
- After cutover, repeat the recipe workload and normal operating checks; confirm screen bindings still resolve to the intended tags and that values remain current at the agreed acceptance limits. Complete the final verification by recording the post-cutover readings and confirming that the operator-facing values remain correct under the planned peak recipe load.
OPC UA server selection FAQ
Can I use an OPC-DA wrapper to connect a client to OPC UA?
A DA-to-UA wrapper can expose an existing OPC-DA server through a UA interface. The legacy DA server remains underneath, so its driver coverage and DCOM configuration still matter.
Does OPC UA guarantee faster updates than my current server?
No. UA provides capabilities such as binary encoding, but update performance depends on driver behavior, polling, batching, caching, client load, and device response. Compare latency and errors under the same representative workload.
Can Ignition use OPC UA events for OPC AE?
The described Ignition implementation did not use the UA event portion. Confirm support for the exact product version and client/server path, then test event delivery separately from tag reads and writes.