Open Platform Communications (OPC) is an open, vendor-neutral industrial communication standard that enables reliable data exchange between industrial automation devices, control systems, software applications, and enterprise systems. Originally known as OLE for Process Control, OPC was created to solve the proprietary driver problem that plagued early industrial automation — where every HMI, SCADA, or historian required a separate, vendor-specific interface to each PLC or device.
OPC defines a standardised interface between servers (which expose plant data) and clients (which consume that data). This allows applications from different manufacturers to communicate with field devices without custom integration for every vendor combination.
The OPC family has evolved significantly. OPC Classic specifications rely on Microsoft COM/DCOM technology and are tightly coupled to Windows platforms. OPC UA (Unified Architecture), released in 2006 and continuously developed by the OPC Foundation, is the modern, platform-independent successor. OPC UA provides a unified information model, built-in security, and support for embedded devices, cloud services, and non-Windows operating systems.
The primary purpose of OPC is to provide a standardised middleware layer between industrial automation hardware and supervisory or enterprise software. Rather than each application vendor writing custom drivers for every PLC, drive, or instrument, a single OPC server exposes device data through a common interface that any OPC client can access.
OPC enables:
OPC does not replace fieldbus or industrial Ethernet protocols such as Modbus, Profibus, or EtherNet/IP. Instead, it sits above them — translating proprietary or protocol-specific data into a common format that applications can consume uniformly.
In the 1990s, industrial automation systems suffered from a fundamental integration problem. Each PLC manufacturer provided proprietary communication interfaces. An HMI vendor had to develop and maintain separate drivers for Siemens, Allen-Bradley, Schneider, and dozens of other platforms. When a device firmware update changed the interface, every dependent application required modification.
OPC was developed to address these challenges:
The OPC Foundation was established to maintain and publish OPC specifications, certify compliance, and promote interoperability across the industrial automation industry. Today, OPC is one of the most widely deployed integration standards in manufacturing, utilities, oil and gas, water treatment, and building automation.
OPC uses a client/server architecture. The OPC server acts as a data broker between field devices and client applications. Clients never communicate directly with PLCs or instruments — they connect to the OPC server, which handles protocol translation, data caching, and subscription management.
Field Devices OPC Server OPC Clients
───────────── ────────── ───────────
PLC ┌─────────────┐ SCADA / HMI
Drives ────────►│ Protocol │────────►Historian
Instruments │ Translation│ MES / ERP
Remote I/O │ Data Cache │ Engineering
Sensors │ Subscriptions Analytics
└─────────────┘ Cloud Services
A single OPC server may aggregate data from multiple underlying devices and protocols. For example, one OPC server might simultaneously expose data from a Modbus RTU energy meter, an EtherNet/IP PLC, and a BACnet building controller — presenting all values through one unified OPC interface.
In OPC Classic, servers and clients communicate using COM/DCOM on Windows. In OPC UA, communication uses service-oriented architecture over TCP/IP (and optionally HTTPS), with a binary or JSON encoding and a rich information model.
The OPC server is responsible for connecting to underlying devices or data sources and exposing their information to clients. Server responsibilities include:
Typical OPC servers include:
The OPC client consumes data from one or more OPC servers. Clients initiate connections, browse the server's address space, read and write values, and subscribe to data changes.
Client responsibilities include:
Typical OPC clients include:
The OPC Foundation publishes multiple specifications, each addressing a specific data exchange requirement. OPC Classic specifications are widely deployed in legacy systems. OPC UA consolidates and extends these capabilities into a single, future-proof architecture.
| Specification | Full Name | Purpose |
|---|---|---|
| OPC DA | OPC Data Access | Real-time read/write access to current process values (tags/items). |
| OPC HDA | OPC Historical Data Access | Retrieval of time-stamped historical process data from archives. |
| OPC A&E | OPC Alarms and Events | Subscription to alarm conditions and event notifications. |
| OPC UA | OPC Unified Architecture | Platform-independent unified model covering real-time data, history, alarms, methods, and security. |
Additional OPC Classic specifications include:
OPC UA also defines companion specifications for vertical industries, including OPC UA for Machinery, OPC UA for PackML, and OPC UA for Auto ID, extending the base information model with domain-specific object types.
OPC Data Access (DA) is the most commonly used OPC Classic specification. It provides real-time access to process variables exposed by an OPC server as items organised into groups.
An item represents a single data point — such as a temperature, pressure, motor speed, or valve status. Each item has a value, a quality indicator, and a timestamp. Items are grouped together for efficient polling or subscription.
Quality indicates data validity:
| Quality | Meaning |
|---|---|
| Good | The value is valid and current. |
| Bad | The value is invalid — communication failure, device fault, or out-of-range. |
| Uncertain | The value may be stale, substituted, or of reduced confidence. |
OPC DA supports two primary data delivery mechanisms:
Example OPC DA interaction:
Client OPC Server │ │ │ Browse Items │ │─────────────────────────────────►│ │◄─────────────────────────────────│ Tank_Level, Pump_Status, ... │ │ │ Subscribe (Tank_Level) │ │─────────────────────────────────►│ │◄─────────────────────────────────│ Tank_Level = 67.2% (Good) │◄─────────────────────────────────│ Tank_Level = 67.5% (Good) │ │ │ Write (Pump_Start = TRUE) │ │─────────────────────────────────►│ │◄─────────────────────────────────│ Write Confirmed
In OPC UA, the equivalent concept uses nodes in an address space rather than items and groups, but the fundamental read/subscribe/write pattern remains the same.
OPC UA defines a rich, object-oriented information model that goes far beyond simple tag lists. Every piece of data in an OPC UA server is represented as a node in a hierarchical address space.
| Node Class | Description |
|---|---|
| Object | Represents a physical or logical entity (e.g. a pump, tank, or production line). |
| Variable | Contains a data value (e.g. temperature, setpoint, counter). |
| Method | Represents an executable operation (e.g. start, stop, reset, calibrate). |
| ObjectType | Defines a template for creating objects with standardised structure. |
| VariableType | Defines a template for variables with standardised data types and semantics. |
| ReferenceType | Defines relationships between nodes (e.g. HasComponent, HasProperty). |
| DataType | Defines structured data types used by variables. |
This model allows OPC UA servers to expose not just raw values but also metadata, engineering units, alarm limits, device descriptions, and callable methods — enabling true semantic interoperability between systems.
Objects
└── ProductionLine1
├── Tank1 (Object)
│ ├── Level (Variable) = 67.2 %
│ ├── Temperature (Variable) = 42.5 °C
│ └── HighLevelAlarm (Variable) = FALSE
└── Pump1 (Object)
├── Running (Variable) = TRUE
├── Speed (Variable) = 1450 RPM
└── Start (Method)
OPC UA companion specifications define standard object types for common equipment, reducing the engineering effort required to integrate devices from different vendors with consistent semantics.
Unlike OPC Classic, which relies on Windows DCOM security (often difficult to configure correctly), OPC UA incorporates comprehensive, application-layer security designed for industrial environments.
| Security Feature | Description |
|---|---|
| Authentication | X.509 certificates, username/password, or issued tokens verify client and server identity. |
| Authorisation | Role-based access control restricts which nodes a client can read, write, or call. |
| Encryption | Symmetric and asymmetric encryption (AES, RSA) protect data confidentiality in transit. |
| Integrity | Message signing (HMAC, RSA-PSS) detects tampering and replay attacks. |
| Secure Channels | Security policies negotiate encryption algorithms and key lengths per connection. |
| Audit Logging | Security-relevant events (connections, rejected requests) can be logged for forensic analysis. |
OPC UA defines multiple security policies ranging from none (for trusted, isolated networks) to strong encryption with 256-bit keys. Security modes include Sign (integrity only) and SignAndEncrypt (integrity and confidentiality). The appropriate policy depends on the risk assessment and security zone in which the OPC UA communication operates.
OPC Classic, by contrast, has no native encryption or authentication beyond Windows DCOM permissions, which are notoriously difficult to configure across domains and firewalls. This is a primary driver for migration to OPC UA in security-conscious environments.
| Feature | OPC Classic | OPC UA |
|---|---|---|
| Platform | Windows only (COM/DCOM) | Platform-independent (Windows, Linux, embedded, cloud) |
| Transport | DCOM (RPC over TCP) | TCP/IP, HTTPS, WebSockets |
| Data Model | Flat tag/item lists | Rich object-oriented address space |
| Security | Windows DCOM permissions only | Built-in authentication, encryption, signing, and authorisation |
| Firewall Friendly | No — DCOM uses dynamic RPC ports | Yes — configurable TCP port (default 4840) |
| Specifications | Separate specs (DA, HDA, A&E, XML-DA) | Single unified specification |
| Discovery | Windows registry / OPC enumeration | Local Discovery Server (LDS) and GDS (Global Discovery Server) |
| Methods | Not supported | Supported — clients can invoke server methods |
| Embedded Devices | Impractical — requires Windows COM stack | Designed for resource-constrained embedded targets |
| Industry Direction | Maintenance mode — legacy deployments | Active development — recommended for new systems |
OPC UA and Modbus serve different roles in industrial automation. Modbus is a field-level protocol for direct device communication. OPC UA is typically an integration and middleware protocol that may use Modbus (via an OPC server) as one of its underlying data sources.
| Feature | OPC UA | Modbus |
|---|---|---|
| OSI Layer | Application layer (Layer 7) | Application layer (Layer 7) |
| Primary Role | Integration middleware between devices and applications | Direct device-to-controller communication |
| Data Model | Object-oriented nodes with metadata, methods, and types | Flat register/coil memory map |
| Security | Built-in authentication, encryption, and signing | No native security features |
| Platform | Cross-platform (Windows, Linux, embedded) | Platform-independent but typically embedded in devices |
| Transport | TCP/IP (port 4840), HTTPS | Serial (RTU/ASCII) or TCP/IP (port 502) |
| Addressing | Hierarchical address space with browseable nodes | Numeric register addresses (e.g. 40001–49999) |
| Subscriptions | Native publish/subscribe with configurable reporting | Polling only — master/client initiates every request |
| Methods | Supported — callable operations on objects | Not supported — read/write registers only |
| Typical Use | SCADA-to-PLC integration, MES connectivity, cloud analytics | PLC-to-sensor/drive/RTU communication |
| Bandwidth | Higher overhead — rich metadata and security | Lightweight — minimal message overhead |
In practice, these protocols are complementary. A Modbus OPC server reads holding registers from field devices via Modbus and exposes the values as OPC UA nodes — allowing SCADA, historians, and cloud platforms to access Modbus device data through a secure, standardised OPC interface.
A common OPC deployment in an Industrial Automation and Control System (IACS) connects field devices through protocol-specific drivers to OPC servers, which in turn serve multiple client applications.
Enterprise Layer
MES / ERP / Analytics
│
│ OPC UA
▼
Supervisory Layer
SCADA Server ◄──── OPC Client
Historian ◄──── OPC Client
│
│ OPC UA / OPC DA
▼
Integration Layer
OPC Server (aggregates multiple protocols)
│
┌────┼────┬──────────┐
│ │ │ │
Modbus EtherNet/IP BACnet SQL Database
│ │ │ │
Field Devices & Control Systems
Modern PLCs and intelligent field devices increasingly include embedded OPC UA servers, allowing clients to connect directly without a separate gateway or middleware server.
ISA/IEC 62443 provides cybersecurity requirements for Industrial Automation and Control Systems (IACS). OPC — particularly OPC UA — aligns with several IEC 62443 principles, while OPC Classic requires compensating controls.
| IEC 62443 Requirement | OPC Classic | OPC UA |
|---|---|---|
| Identification and Authentication (SR 1.1–1.7) | Relies on Windows DCOM — difficult to manage centrally | Certificate-based and username authentication built into the protocol |
| Use Control / Authorisation (SR 2.1) | Limited — DCOM launch/access permissions only | Role-based access control per node and operation |
| System Integrity (SR 3.1–3.6) | No message integrity protection | Message signing detects tampering and replay |
| Data Confidentiality (SR 4.1–4.3) | No encryption — data transmitted in clear text | AES and RSA encryption with configurable security policies |
| Restricted Data Flow (SR 5.1–5.3) | DCOM uses dynamic ports — difficult to firewall | Single configurable TCP port — supports zone/conduit architecture |
| Timely Response to Events (SR 6.1–6.2) | No native audit logging | Security audit events for connections and access violations |
| Resource Availability (SR 7.1–7.6) | DCOM failures can cause widespread connectivity loss | Session management with configurable timeouts and redundancy |
IEC 62443 does not certify OPC itself but defines how systems using OPC should be secured. For OPC Classic deployments, compensating controls are essential:
For new deployments, OPC UA with SignAndEncrypt security mode and certificate-based authentication directly supports the security level requirements defined in IEC 62443-3-3.
OPC specifications are published and maintained by the OPC Foundation. Secure deployment within an IACS is addressed through ISA/IEC 62443 system-level requirements: