OPC UA is an abbreviation for OPC Unified Architecture. It is a platform-independent, extendable standard that permits the secure exchange of information in industrial systems. The Open Platform Communications (OPC) Foundation, which oversees and maintains the interoperability standard, protocols, and specifications for data exchange, mostly in industrial automation operations, published OPC UA in 2008.
OPC UA is supported by Windows, macOS, Android, and Linux. It can also be utilized in embedded and bare-metal systems that lack an operating system. OPC UA is compatible with PCs, cloud infrastructures, PLCs, microcontrollers, and cyber-physical systems (CPS).
By offering a platform for industrial organisations to integrate heterogeneous technologies, OPC UA aims to improve interoperability between hardware devices and enterprise planning and automation applications.
Where is OPC UA used?
OPC UA is used in industrial systems such as oil and gas, agriculture, medical and pharmaceutical, vital services such as electricity grids and wastewater treatment plants, and Internet of Things (IoT) systems such as smart city applications.
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 are all common OPC UA uses.
Monitoring the uptime of security cameras, giving alerts for failing sensors, controlling office temperatures, remotely managing automated machinery, forecasting workloads, linking embedded devices, and assisting remote employees are some real-world examples.
OPC UA is also compatible with the industrial internet of things (IIoT). OPC UA, for example, can be used to transmit data from embedded devices such as temperature sensors to the cloud in order to monitor consumption and equipment efficiency.
The usage of objects to access data in OPC UA allows systems to retrieve small quantities of context-specific information for remote workers as needed for a specific job. Alternatively, objects can be searched to examine all data for a complete plant’s operations, such as when developing graphical user interfaces for ERP systems, resource allocation programs, and accounting systems.
OPC UA facilitates vertical data transmission between heterogeneous drivers and high-level applications where synchronisation is required between devices in remote locations and resource planning and factory control systems.
The OPC UA standard improves industrial security applications. In the event of a cyberattack on field devices, OPC UA events management protocols may automatically shut down a plant and isolate affected networks or enable limited access to specified networks, allowing business continuity while the incident is investigated.
How does OPC UA function?
Models
OPC UA offers basic criteria for exposing data to any application or device that wishes to consume it using models. OPC UA is a data model that focuses on information. It consists of a generic object model with an extendable type system and built-in data access models. These built-in models define functions such as alerts and events information, historical data information, data access details, device descriptions, and program execution.
Data can also be accessible through custom models known as companion models. These are employed in a variety of industries, including the manufacture of injection molding machines and robotics engineering.
Connections and data flow
OPC UA enables the communication between components in industrial organisations at five levels: enterprise, management, operations, control, and field (vendor-specific devices).
Devices disclose their data via OPC UA, which allows this information to be transported over a network to a consuming application via normal web services. Data is transmitted over IP-based protocols and SOAP, with low-end servers employing UA TCP. Non-OPC UA clients can request data from an OPC UA server by using normal SOAP web services over HTTP.
OPC UA wrappers, bridging, and gateway software, allow data to travel between OPC UA levels on vendor-specific hardware. OPC UA wrappers are especially useful when migrating from OPC Classic to OPC UA or when an OPC server supports UA but an OPC client does not.
Architecture based on services (SOA)
The SOA client-server communication framework serves as the foundation for OPC UA. There are OPC UA servers and OPC UA clients in OPC UA.
An OPC UA server connects an OPC UA client to applications and control systems, such as MES and SCADA, as well as secure access to industrial automation data through the use of OPC UA information models, which define how data is organised, stored, and collected. The name OPC UA server refers to the machine’s OPC UA software standard, not the hardware, which could be a virtual server.
A client that can support an OPC UA information model is known as an OPC UA client. OPC UA clients use OPC UA servers to obtain data from and write data to system components.
SOA systems, such as OPC UA, connect devices on multiple network nodes and integrate diverse applications via a network.
Nodes
A node is the fundamental data unit in the OPC UA address space, providing a consistent mechanism for OPC UA servers to represent objects to OPC UA clients. Nodes are information bits (for example, a unique temperature) that include attributes, the actual data value, and one or more references to other nodes, each in its own address space. As a result, a single temperature will occupy several addresses in an address space.
A node is identified by a unique node ID, which includes a namespace URI (unique resource identification), a data type, and the identifier itself. Each node is associated with a distinct namespace. On the OPC UA server, the namespace URI is stored in a separate namespace table. The namespace table stores distinct URIs for information models used by individual businesses, each with its own set of rules for how data should look and behave. This allows OPC UA to expand its services without modifying the standard’s fundamental design.
Nodes in OPC UA contain numerous classes that allow for the building of variants on the basic node. Objects (physical entities), methods (functions that save data when queried), and variables are among the eight main node types in OPC UA (actual data).
In OPC UA, object node classes are essential for creating complicated data and distinguishing between comparable but distinct entities, such as a temperature sensor for an air conditioner and a temperature sensor for a boiler.
Advantages and Disadvantages of ODC UA
Advantages of ODC UA
-
Self Service: - Because no scripting is necessary, operational teams can connect to any OPC UA server with ease. They may also use device auto-discovery to fully automate device identification and integration with Cumulocity IoT.
-
Generic device types are supported: - Each device just needs to be defined once. The device type specification specifies the mapping from a machine to the relevant IoT asset as well as the configuration, such as which data to synchronise at what frequency.
-
Configuration in the cloud: - Through cloud-based remote configuration, we offer zero-touch installation of the OPC UA IoT gateway by a field engineer. So, regardless of where engineers are, they may connect to various devices without having to be in the same room.
Disadvantages of ODC UA
-
Device-specific constraints: - Some proprietary software vendors have noted device-specific constraints, such as those that exist between an OPC UA server and General Electric’s iFIX and HMI/SCADA components used in the company’s software automation products. Specific features such as Electronic Signature, Enhanced Failover, and historical data sources are among the limits.
-
Configuration that is complicated: - In practise, OPC UA often manages data interchange between MES and SCADA information systems, as well as between low-level devices. It’s perfect for system monitoring and reporting. Despite being meant to manage interoperability between diverse devices, it has been criticised for being inflexible when dealing with different data structures from different suppliers, as well as difficult to install.