OPC UA and OPC DA: Choose the Right Standard for Your Factory

Machines in your factory generate data all the time. The PLC knows the current state of the line. SCADA and andon systems show alarms. An operator enters a downtime reason. MES tracks production progress, and ERP waits for updates about orders, material, and batches.

All these systems can work well together, as long as the data is consistent. Very often, it is not.

The OEE report says one thing. The operator says another. ERP is missing the latest production status.

That is usually when OPC UA and OPC DA enter the conversation.

They sound technical, but the choice between them has a direct business meaning. It affects whether machine data is available, readable, secure, and ready for MES, ERP, reporting, or traceability.

After reading this article, you will know when it makes sense to stay with OPC DA, when to choose OPC UA, and when to use both standards together.

OPC UA, or Open Platform Communications Unified Architecture, is an industrial communication standard that helps machines, controllers, and IT systems exchange data in a structured way.

In plain language, OPC UA gives production and IT systems a shared language.

With OPC UA, data from PLCs, sensors, robots, SCADA systems, and machines can be sent to MES, ERP, quality systems, reporting tools, and analytics platforms.

OPC UA does more than send a number. It can also send context:

A raw value like 82 does not tell you much.

But this does:

Furnace 2, heating zone 1, temperature 82°F, timestamp 10:42:18, data quality: good.

That kind of information is useful for production, quality, maintenance, and management reporting.

OPC DA stands for OPC Data Access. It is an older standard from the OPC Classic family.

OPC DA is mainly used to exchange current process data, such as:

OPC DA is based on Microsoft COM/DCOM technology. It worked well for older SCADA systems and local Windows-based installations.

OPC DA is not wrong. In many plants, it still works every day.

The problems usually start when you want to implement MES, connect production data with ERP, collect data from many lines, or reduce manual reporting.

OPC UA usually fits better when a plant wants to connect automation with IT, work across different systems, and share production data in a controlled way.

Let’s say you have 20 machines.

From each machine, you collect 50 signals.

You read each signal once per second.

That gives you:

20 × 50 × 86,400 = 86,400,000 data reads per day

At that volume, “getting the data somehow” is not enough.

You need to know:

For a small local setup, OPC DA may be enough.

For more machines, more lines, and more systems, OPC UA usually gives you a better foundation for production data management.

OPC DA most often becomes difficult when the system grows.

When OPC DA communicates between computers, you have to deal with Windows settings, user accounts, domains, firewall rules, ports, permissions, and updates.

That can create everyday problems.

Data disappears. A report has gaps. The team starts checking the network, SCADA, the OPC server, the Windows server, and access rights.

The issue may not be the machine at all. It may be the communication layer.

In older installations, that may be acceptable.

The problem appears when you want to add:

In those cases, OPC DA often needs gateways or middleware.

That adds cost, maintenance work, and another point where data can break.

OPC DA can tell you the current value.

For example:

But what does Status = 1 mean?

Does the counter show all parts or only good parts?
Is the temperature related to the product, mold, or room?
Was the value read from the PLC, calculated in SCADA, or entered by an operator?

OPC UA helps organize this better because it can describe the data and its meaning.

That matters when you want the same data to feed MES, ERP, quality reports, maintenance dashboards, and traceability.

You may stay with OPC DA if:

Example:

You have one line, local SCADA, simple shift reports, and no plan to expand data integration.

In that case, OPC DA may still be good enough.

Replacing it only because a newer standard exists may not pay off.

OPC UA is worth considering when you plan to:

If production, quality, maintenance, and ERP should all work from the same data, OPC UA is usually the better direction.

It helps you build one organized data layer instead of many disconnected sources.

Yes. This is common in plants with older equipment.

Older machines and SCADA systems can continue using OPC DA, while data is made available to newer systems through OPC UA.

That setup works well when:

In this model, the plant keeps what already works and builds a new data layer for MES, ERP, reporting, quality, and traceability.

A common path looks like this:

You do not always need to replace everything at once.

SCADA shows what is happening on the machine.

MES manages production execution, tracks output, downtime, scrap, and process parameters.

ERP handles planning, materials, costs, inventory, and financial settlement.

OPC UA can be one of the paths that sends machine data to MES and then further to ERP.

Example:

Without this structure, you often end up with three versions of the truth:

That creates arguments, manual checks, and weak trust in reports.

OEE depends on three areas:

Each one needs reliable data.

If downtime reasons are entered manually, counters are copied from SCADA, and scrap is reported later in ERP, your OEE number may be late or inaccurate.

OPC UA can help by giving MES access to machine signals such as:

For example, if a line runs 16 hours a day and loses 45 minutes because of micro-stops, manual reporting may miss most of that loss.

Machine data gives you a clearer view.

You can see whether the issue comes from changeovers, short stops, speed loss, material shortages, or quality problems.

That is where OPC UA becomes more than a communication standard. It becomes part of how you manage production performance.

Traceability needs more than a batch number.

You need to connect product, process, time, material, and machine conditions.

OPC UA can help send process data to MES or quality systems, including:

Example:

A customer reports a quality issue for a specific batch.

If your traceability is built on manual entries, finding the cause may take hours or days.

If machine and process data are linked to the batch in MES, you can check which line produced it, which parameters were active, whether alarms occurred, and whether similar products were affected.

That saves time and reduces the risk of broad, unnecessary recalls.

Changing the standard will not fix poorly named or poorly understood signals.

Before moving to OPC UA, check:

A signal named M_01_STAT_2 may work for automation, but it will not help production or reporting unless the meaning is clear.

Not every machine signal needs to go to MES.

If you collect 500 signals and use 30, the system becomes harder to maintain.

Start with the decisions you want to support.

For example:

Then choose the signals that support those goals.

Maintenance teams often know which signals are reliable, which ones are noisy, and which ones changed meaning after machine modifications.

If they are not involved, you may build reports on weak signals.

That creates mistrust fast.

OPC UA connects two worlds: automation and IT.

You need clear rules for:

Without these rules, even a good technical setup can become difficult to run.

OPC UA moves and organizes data.

It does not decide which production events matter.
It does not clean old tag structures by itself.
It does not define how MES should count output or downtime.

You still need a clear data model, ownership, and business rules.

At explitia, we work with production data from three sides: machines, systems, and people.

An OPC server alone will not solve the full problem.

In projects related to OPC, MES, SCADA, ERP, OEE, reporting, and traceability, we can help you with:

This is useful when your plant has older infrastructure, but you want to:

The goal is simple: make production data reliable enough for daily decisions.

Use these rules as a starting point:

Do not start with the standard.

Start with the reason you need the data.

Ask yourself:

Once you know what the data should support, choosing between OPC DA, OPC UA, or a mixed model becomes much easier.

If you are not sure which path fits your plant, start with a production data audit.

explitia can review your data sources, check your OPC setup, organize machine tags, and prepare an architecture for MES, ERP, reporting, OEE, or traceability.

OPC UA is an industrial communication standard that helps machines, controllers, and IT systems exchange data in a structured way. It is often used for MES, ERP, SCADA, reporting, quality systems, OEE, and traceability.

OPC DA is an older standard from the OPC Classic family. It is used to exchange current process data, such as temperature, part counters, machine status, and fault signals. OPC DA is based on Microsoft COM/DCOM.

Yes. OPC DA is still used in many factories, especially with older SCADA systems. If the system is stable and used locally, it may not need immediate replacement.

In new projects, often yes. In older plants, OPC DA and OPC UA can work together. Older systems can remain on OPC DA, while selected data is made available through OPC UA for MES, ERP, reporting, or traceability.

Not always. Many plants keep existing machines and add a gateway or integration layer that exposes selected data through OPC UA.

Usually, yes. OPC UA gives MES a more structured way to read machine data, including values, timestamps, data quality, events, and context.

ERP usually does not connect directly to machines. Data often goes from PLC or SCADA to MES, and then from MES to ERP. OPC UA helps organize the machine data layer that feeds MES and reporting.

A mixed model works well when older machines and SCADA still run properly, but the plant needs better reporting, MES integration, OEE tracking, or traceability.