OPC UA for OEE: The Protocol That Makes Real-Time OEE Possible

Key takeaways

• OPC UA is the vendor-neutral communication standard that lets OEE platforms read data from any modern PLC, SCADA, or historian.
• It replaces the older OPC DA (Windows-only, fragile, COM-based) with a cross-platform, secure, modeled-data protocol.
• The "UA" stands for Unified Architecture — it standardizes how data, types, and security are exposed across the stack.
• For OEE, OPC UA delivers run-state, cycle counts, and reason codes from PLC to the OEE platform at machine cadence.
• Almost every modern OEE platform speaks OPC UA out of the box. Older platforms often need an OPC UA gateway.

Short answer: OPC UA is the modern communication standard for industrial automation. It lets an OEE platform read PLC data (run state, cycle counts, fault codes) without writing custom drivers for every brand of equipment. It replaces the older Windows-only OPC DA protocol with a vendor-neutral, secure, modeled-data architecture. If you are evaluating an OEE platform in 2026, OPC UA support is table stakes. See also OEE vs Utilization.

What OPC UA is

OPC UA stands for Open Platform Communications Unified Architecture. It is a communication standard maintained by the OPC Foundation. The standard defines how industrial systems exchange data, including security, authentication, data modeling, and discovery.

The "Unified" part is the key: one protocol, one set of conventions, that works across PLCs, SCADA, historians, MES, and cloud systems regardless of vendor.

Why OPC UA replaced OPC DA

The original OPC DA was Windows-only and built on Microsoft COM/DCOM. Three problems:

• Windows-only. Could not run on Linux, edge gateways, or cloud.
• Configuration hell. DCOM configuration was fragile and notoriously hard to firewall.
• No security model. Built before modern industrial security was a concern.

OPC UA fixes all three: cross-platform (any OS, any device), TCP-based (firewall-friendly), and security as a first-class feature (authentication, encryption, signing).

What OPC UA delivers for OEE

An OEE platform needs five things from the line:

1. Machine run state (running, idle, stopped).
2. Cycle counts (parts produced).
3. Cycle time per part.
4. Fault/reason codes when stopped.
5. Quality signals (good/bad part counts where available).

All five are exposed via OPC UA from any modern PLC. The OEE platform subscribes to the relevant OPC UA nodes and ingests the stream at machine cadence.

How OPC UA differs from MQTT

OPC UA and MQTT both show up in industrial data flow but solve different problems:

• OPC UA is a structured, modeled, client-server protocol. Strong typing, discovery, security, and data hierarchy. Best for reliable point-to-point data exchange.
• MQTT is a lightweight pub/sub message broker. Better for high-scale, low-bandwidth telemetry. No data modeling — just topics and payloads.

Modern stacks often combine them: OPC UA at the line for structured data exchange, MQTT for high-volume telemetry to cloud. OPC UA also has a pub/sub mode that competes with MQTT for some use cases.

How to deploy OPC UA for an OEE rollout

1. Check PLC support. Modern PLCs from Rockwell, Siemens, Mitsubishi, and Beckhoff support OPC UA natively. Older PLCs may need a gateway (Kepware, Matrikon, or open source like Open62541).
2. Map the tags. Decide which PLC tags expose run state, cycle counts, and fault codes. Standardize naming across lines.
3. Set up security. Use OPC UA security policies (Basic256Sha256 or better). Disable anonymous access in production.
4. Subscribe from the OEE platform. Configure the OEE platform as an OPC UA client subscribing to the tags. Most modern platforms have a UI for this.
5. Verify latency. Confirm data arrives within the cadence the OEE platform expects (typically 1-5 seconds).

Common mistakes

1. Skipping security. Anonymous OPC UA in production is the equivalent of leaving the door open. Always use signed and encrypted policies.

2. Over-modeling. Exposing every PLC tag via OPC UA creates noise. Expose only what the OEE platform needs.

3. Mixing OPC DA and OPC UA in the same architecture. Pick one. Bridging them via a tunneller works but adds latency and complexity.

4. Using OPC UA on hardware that does not support it natively. Gateways work but add a hop. Native support is the better choice when buying new equipment.

What this means for OEE platform selection

OPC UA is a baseline capability for any 2026 OEE platform. The questions to ask:

• Does it support OPC UA client mode natively?
• Which security policies are supported?
• How does it handle disconnection and reconnection?
• Can it auto-discover available tags or does every tag need manual mapping?

Fabrico's OEE module is a native OPC UA client supporting Basic256Sha256 security policy, with auto-discovery of tags and resilient handling of connection drops.

See how Fabrico captures this automatically — explore OEE for manufacturing or book a demo.

Related reading

• OEE vs Utilization
• OEE and ISO 22400
• OEE for Batch Manufacturing
• OEE vs Availability

Frequently asked questions

Do I need OPC UA if I have SCADA?

If SCADA exposes OPC UA, the OEE platform can read from SCADA. If not, reading directly from PLC via OPC UA bypasses SCADA. Either works; the choice depends on your architecture.

Is OPC UA secure enough for production?

Yes, with security policies enabled. Anonymous OPC UA is not secure; signed and encrypted (Basic256Sha256+) is industrial-grade.

What if my PLCs do not support OPC UA?

Use a gateway (Kepware, Matrikon) that translates from the PLC native protocol to OPC UA. Common solution for older Allen-Bradley and Mitsubishi installations.

Can OPC UA replace MQTT?

OPC UA has a pub/sub mode that overlaps MQTT. For most OEE use cases either works. MQTT is lighter; OPC UA carries more structured data and security.

How much bandwidth does OPC UA use?

Low. Typical OEE tag subscriptions consume a few KB per second per line. Well within plant LAN budgets.