OPC UA

OPC UA is a standard developed to facilitate communication between different brands and technologies in industrial systems.

A PLC from one manufacturer, a SCADA system from another manufacturer, and data acquisition or analysis software from a third manufacturer can exchange data with each other using a common communication model over OPC UA.

One of the important features of OPC UA is that it is platform-independent. Applications running on Windows, Linux, embedded systems, and different hardware platforms can use OPC UA.

OPC UA is the modern architecture of the OPC standards family developed and maintained by the OPC Foundation. OPC UA was introduced in 2008 and brought together the functions of previous OPC Classic technologies under an extensible architecture. :contentReference[oaicite:1]{index=1}

Industrial facilities may contain numerous devices and software from different manufacturers. PLC, RTU, inverter, power analyzer, protection relay, SCADA, historian, MES, and ERP systems may need to operate in the same environment.

Since each of these systems may use different communication methods, data exchange between them can create a significant integration problem.

OPC UA aims to reduce this problem by providing a common and standardized communication layer between these different systems.

• Communication between devices from different manufacturers
• Data transfer to SCADA and HMI systems
• Transfer of industrial data to higher-level systems
• Integration with MES, ERP, and data analysis systems
• Data exchange with IIoT and cloud systems
• Use of standardized information models

One of the most important concepts in OPC UA is the Address Space. The Address Space is the structure in which the information provided by the OPC UA Server to the outside world is organized.

In traditional protocols, a data item is often represented only by an address or register number, whereas in OPC UA, data can be represented using a much richer structure.

For example, a generator in a power plant can be represented within a structure such as the following:

Plant
 └── Generator01
      ├── Status
      ├── ActivePower
      ├── ReactivePower
      ├── Voltage
      ├── Current
      ├── Temperature
      └── Start

In this way, the Client does not merely read a value; it can also understand which equipment the value belongs to, what type of value it is, and its relationships with other objects.

The OPC UA Address Space and information modeling approach are among the fundamental architectural features of the standard. :contentReference[oaicite:2]{index=2}

In OPC UA, every piece of information within the Address Space can be represented as a Node.

A Node can represent a variable, object, method, data type, or another type of information.

For example, the temperature information of a motor can be represented as a Variable Node, while the motor itself can be represented as an Object Node.

OPC UA Nodes have unique identifiers. These identifiers are called NodeId.

In addition, information such as BrowseName and DisplayName can be used so that users and software can identify Nodes in a more understandable way.

In OPC UA, the concept of Namespace is used to prevent information models created by different manufacturers or applications from becoming mixed with each other.

The identity of a Node is generally evaluated together with its Namespace. Therefore, in OPC UA applications, it is important to evaluate the NodeId and Namespace information together rather than looking only at the displayed names.

For example, an OPC UA Server may contain NodeIds such as the following:

ns=2;s=Plant.Generator01.ActivePower
ns=2;s=Plant.Generator01.Voltage
ns=2;s=Plant.Generator01.Temperature

The structure shown here is for illustrative purposes. The actual NodeId formats depend on the design of the OPC UA Server being used.

An OPC UA Client can read or write the values of Nodes in the Server's Address Space for which it has appropriate authorization.

For example, in a power plant, a Client can read the following values:

• Active power
• Reactive power
• Voltage
• Current
• Frequency
• Temperature
• Pressure
• Flow rate
• Equipment operating status
• Alarm and status information

In systems that support writing, Clients with appropriate permissions can write values or control commands to the Server.

One of the important features of OPC UA is the Subscription mechanism.

Instead of a Client repeatedly asking the Server "has the value changed?", the Client can create a Subscription and monitor the Nodes it is interested in.

When a value changes or specified conditions occur, the Server can send a notification to the Client.

Each data point monitored within a Subscription can be defined as a MonitoredItem.

This structure can provide significant advantages, especially in SCADA, data acquisition, and historian applications where a large number of data points are involved. The OPC UA specification defines Subscription and MonitoredItem structures among its fundamental services. :contentReference[oaicite:3]{index=3}

One of the important features that distinguishes OPC UA from traditional data communication protocols is its Information Model approach.

It is possible to model not only the values of a device, but also what the device is, what properties it has, which values belong to it, and its relationships with other objects.

For example, for a pump:

• Pump operating status
• Flow rate
• Pressure
• Motor speed
• Temperature
• Start and stop commands
• Alarm information

can be defined together within the information model of the same object.

OPC Foundation also develops specialized information models called Companion Specifications for different industries and device types. These can provide standardized models for energy, manufacturing, process, machinery, and different industrial applications. :contentReference[oaicite:5]{index=5}

Secure communication is of great importance in industrial systems. OPC UA treats security as one of the fundamental parts of its architecture.

The OPC UA security architecture covers the Publish-Subscribe communication model in addition to Client/Server communication. :contentReference[oaicite:6]{index=6}

In addition to the classic Client/Server communication model, OPC UA also provides the Publish-Subscribe (PubSub) communication model.

In the Client/Server model, the Client connects to a specific Server and uses its services, whereas in the PubSub model, data can be published by a Publisher and received by Subscriber applications interested in that data.

This approach can be particularly useful in large industrial and IIoT applications where many systems need to use the same data.

OPC UA PubSub can be used with different transport methods. In addition to UDP, the OPC UA specification also defines transport options such as MQTT and AMQP. :contentReference[oaicite:7]{index=7}

OPC UA can be used in a wide variety of applications where data exchange is required between different levels of automation.

OPC UA is designed so that its scope can be extended from the device level to enterprise and corporate systems. :contentReference[oaicite:8]{index=8}

Although OPC DA and OPC UA serve the same purpose, namely standardized data exchange between different systems, their architectures are quite different from each other.

OPC Foundation defines OPC UA as a technology that combines the functionality of OPC Classic technologies within a broader and platform-independent architecture. :contentReference[oaicite:9]{index=9}

For those new to OPC UA, learning the following concepts greatly facilitates understanding Client and Server applications.

• OPC UA Server: An application that provides data and information through OPC UA.
• OPC UA Client: An application that connects to a Server and uses its data.
• Address Space: The information space provided by the Server.
• Node: An information unit within the Address Space.
• NodeId: The unique identifier of a Node.
• BrowseName: The name used when browsing the Node in the address space.
• Namespace: A structure used to distinguish information models from one another.
• MonitoredItem: Data or an event added to a Subscription for monitoring.
• Subscription: A structure used to manage change and event notifications.
• Information Model: The modeling of data and objects in a meaningful structure.
• PubSub: A Publisher- and Subscriber-based communication model.

This section will provide auxiliary software, test tools, Client and Server applications, sample projects, and developer tools that can be used when working with OPC UA.

The tools can be used for purposes such as discovering OPC UA Servers, inspecting the Address Space, viewing NodeIds, reading and writing data, performing Subscription tests, and analyzing OPC UA communication.

OPC UA is a comprehensive communication technology developed to provide standardized and secure information exchange between industrial systems.

It would not be correct to think of OPC UA merely as a "data reading protocol." In addition to Client/Server communication, it brings together many different capabilities such as Address Space, information modeling, Subscription, Events, Alarms, Historical Access, security, and PubSub.

Thanks to these features, OPC UA has a wide range of applications, from SCADA and HMI applications to data collection systems, from production systems to power generation facilities, and IIoT applications.

The fundamental architecture and standardized information models of OPC UA are designed to facilitate the interoperability of systems from different manufacturers within the same industrial data infrastructure. :contentReference[oaicite:10]{index=10}

You can contact us regarding EOS software, technical documentation, or industrial data communication.

• benanbasoglu@gmail.com
• WhatsApp Technical Support Group
• ANKARA