OPC Classic, the predecessor of OPC UA, relies on Microsoft technologies while OPC UA is platform independent. 

OPC Classic does not have built-in security for access control, authentication, and encryption. OPC UA enables data encryption at the data source, ensuring secure transmission without relying on network firewalls at the system’s core. This means security is ensured from the start of the data’s transmission, instead of being confirmed only when it reaches a network’s firewall. OPC UA implements cross-platform security based on the public key infrastructure (PKI) using industry standard x.509 digital certificates.

In contrast to OPC UA, OPC Classic does not support dynamic information modeling, which allows manufacturers to define custom data models depending on the requirements of their industry.

In OPC UA, OPC Classic specifications provide functional modules that can be queried ad hoc. These specifications are OPC DA (Data Access), OPC AE (Alarms and Events), OPC Security, OPC Batch, OPC Command, OPC XML, OPC Data Exchange (DX), and OPC HAD (History Access Data). They are usually referred to collectively as OPC Classic or simply OPC. In OPC UA, they are called profiles. For example, the OPC DA standard is an OPC UA DA profile.

These profiles make up a layer that lies on top of the base layer of OPC UA, which runs common services. All OPC UA profiles use the same common code base whereas, in an OPC Classic setup, each standard has its own code base, which creates duplications in systems where more than one OPC Classic specification is implemented.

Model

Using models, OPC UA specifies basic rules for exposing data to any application or device that wants to consume it. OPC UA itself is an information-centric data model. It comprises a generic object model with an extensible type system with built-in models for data access. These built-in models specify functions such as alarms and events information, information about historic data, data access details, device descriptions, and to execute programs.

Data can also be accessed through custom models, which are referred to as companion models. These are used in different industries like injection molding machine manufacturing or robotics engineering.

Data flow and connections

OPC UA supports communication between components on five levels in industrial organizations: enterprise, management, operations, control, and field (vendor-specific devices).

Devices expose their data through OPC UA, which enables the transport of this information over a network to a consuming application using standard web services. Data is transported using IP-based protocols and SOAP whereby low-end servers may use UA TCP. Using standard SOAP web services over HTTP allows non-OPC UA clients to request data published by an OPC UA server.

Bridging and gateway software known as OPC UA wrappers enable the flow of data on vendor-specific hardware between OPC UA levels. OPC UA wrappers can also be used to migrate from OPC Classic to OPC UA, or when an OPC server supports UA but an OPC client does not.

Service-oriented architecture (SOA)

OPC UA is based on the SOA client-server communication framework. In OPC UA, there are OPC UA servers and OPC UA clients.

An OPC UA server provides an OPC UA client with applications and control systems, for example MES and SCADA, and with secure access to industrial automation data using OPC UA information models that specify the way data is organized, stored, and collected. The term OPC UA server refers to the OPC UA software standard on the machine, not the hardware itself, which could be a virtual server.

An OPC UA client is a client that can support an OPC UA information model. OPC UA clients request data from and write data to components in a system via OPC UA servers.

SOA systems like OPC UA integrate disparate applications over a network and connect devices on different network nodes.

Nodes

A node is the basic unit of data in the OPC UA address space, which provides a standard way for OPC UA servers to represent objects to OPC UA clients. Nodes are pieces of information (for example, a unique temperature) and consist of attributes, the actual data value, and one or more references to other nodes, each in its own address space. A unique temperature will therefore take up multiple addresses in an address space.

Nodes are referenced by a unique node ID: a namespace URI (unique resource identifier), a data type, and the identifier itself. Each node belongs to a specific namespace. The namespace URI is located in a separate namespace table on the OPC UA server. The namespace table stores separate URIs for information models used by individual organizations that have their own requirements for how data should look and behave. This allows OPC UA to extend its services without changing the underlying design of the standard.

In OPC UA, nodes have multiple classes that enable the creation of variants on the basic node. There are eight core node classes in OPC UA, including objects (physical entities), methods (functions that store data when queried), and variables (actual data).

Object node classes in OPC UA are the key to how it can create complex data and distinguish between similar but different entities, for example a temperature sensor for an air conditioner and a temperature sensor for a boiler.

The OPC UA standard itself does not do anything. The standard is a collection of specifications (OPC UA protocols) that define guidelines for communication between servers and clients, including rules for different functions and data structures.

OPC UA has the following specifications: Overview and Concepts, Security Model, Address Space Model, Services, Information Model, Mappings, Profiles, Data Access, Alarms and Conditions, Programs, Historical Access, Discovery and Global Services, Aggregates, PubSub, Safety, and Alias Names. Each specification was designed to address a common problem in industrial systems’ communication networks.

For example, the Alarms and Conditions specification provides a solution to the challenge of standardizing how event and alarm information is pushed from field devices to applications. The Historical Access specification addresses the challenge of standardizing how historical data is accessed in auditing processes. The Programs specification includes information on how developers should handle return codes in their code, among others.

OPC UA is used in industrial systems, for example oil and gas, agriculture, medical and pharmaceutical, critical services like electricity grids and sewerage treatment plants, and IoT systems like smart city applications.

Common OPC UA applications include device diagnostics, asset management, production management, quality control, data acquisition, enterprise reporting, data security, data integration for GUI interfaces, remote worker support, and event monitoring.

Real-world examples include monitoring the uptime of security cameras, sending out alerts for malfunctioning sensors, controlling office temperatures, remotely managing automated machines, estimating workloads, linking embedded devices, and supporting remote workers.

OPC UA also supports the industrial internet of things (IIoT). For example, OPC UA may be used to push data from embedded devices like temperature sensors to the cloud, for example to analyze usage and equipment efficiency.

OPC UA’s use of objects to retrieve data provides an efficient way for systems to retrieve small amounts of context-specific information for remote workers as they need it for a specific task. Alternatively, objects may be queried to view all the data for an entire plant’s operations, for example to create graphical user interfaces for ERP systems, resource allocation applications, and accounting systems.

Where synchronization is needed between devices at remote locations, and resource planning and manufacturing control systems, OPC UA enables vertical data exchange between heterogeneous drivers and high-level applications.

OPC UA strengthens industrial security applications. OPC UA events management protocols may automatically shut down a plant in the event of a cyberattack on field devices, and isolate affected networks or allow limited access to specific networks, enabling business continuity while the attack is investigated.

Decentralization

Historically, the automation pyramid in industrial systems is a hierarchical structure that describes the flow of information from low-level devices like controllers, sensors, or meters to high-level ERP applications. In the opposite direction is a control flow, from high-level ERP applications to low-level devices. Low-level components are connected via MES networks through PLC and HMIs.

OPC UA does away with this pyramid structure by decentralizing system components and facilitating the use of more flexible data modeling structures in a mesh network. OPC UA achieves this by defining consistent data structures that all components use, for example an ERP application and a field sensor can both use the same information model.

OPC UA enables business intelligence applications to source raw data from a wide range of real-time, event, and historical data sources.

Platform independence

Historically, industrial systems ran on Windows-based software. OPC UA is platform agnostic; industrial systems can integrate software from any vendor, using any operating system. OPC UA can be implemented on embedded systems and in the cloud.

Scalability

OPC UA is future proof. It enables organizations to develop scalable SCADA systems so that existing plant equipment can integrate with new software modules without additional configuration. An example of this is in the gas and oil industry, where data from calibration, metering, and flow meter sensors can be gathered remotely, freeing up site inspectors from physically checking the installation.

Discovery

OPC UA has plug-and-play capability. When new remote plants are added to an organization or new suppliers are commissioned, OPC UA can automatically discover their networks, configure them, and integrate them into the company network.

Interoperability

OPC UA interoperability allows end users to build custom industrial systems using devices and software from different vendors.

Device-specific limitations

Some proprietary software manufacturers have reported device-specific limitations, for example between an OPC UA server and General Electric's iFIX, and HMI/SCADA components used in the company's software automation products. These limitations include a lack of support for specific features like Electronic Signature, Enhanced Failover, and historical data sources.

Complicated configuration

In the real world, OPC UA typically manages the exchange of data between MES and SCADA information systems and between low-level devices. It is ideally suited to system monitoring and reporting. Despite being designed to manage interoperability between heterogeneous devices, it has been criticized as being inflexible when handling varied data structures from different vendors, and complicated to implement.

In the sphere of industrial manufacturing, the terms Industry 4.0 and the Fourth Industrial Revolution are used interchangeably to refer to the trend of increased automation, with a focus on device interconnectivity, machine learning, and the Internet of Things among others. 

The primary features of OPC UA, which are built-in security, information modeling capability, automated device discovery, scalability, use of semantic data, and protocol standardization, address the requirements for Industry 4.0 compliance.

One of the main challenges for Industry 4.0 in manufacturing is the collection of real-time data from low-level devices. OPC UA allows an industrial organization to embed an OPC UA server in all its devices. This means that vast amounts of real-time data can be routed to control systems and enterprise-level applications to analyze, sort, and exchange with disparate consuming applications.

Various working groups internationally contribute to making OPC UA the communications standard for Industry 4.0 products and services in specific industries.

One such working group is the ADI (Analyzer Devices) information modeling working group. ADI is sponsored by the OPC Foundation and it is made up of end users and vendors in the chemical and pharmaceutical industries. Another group is the OPC UA Tobacco Machine Communication working group that works to implement interoperable factory equipment for cigarette manufacturing.

To be classified as Industry 4.0 compatible by the OPC Foundation, a product must conform to the OPC UA standard, either by using integrated OPC UA or by using gateway software.