OPC UA – what exactly is that?

To enable communication between different systems (e.g. a plastics processing machine / injection moulding machine / extruder) and a PC application (e.g. a virtual assistance system) or higher-level organisational systems (e.g. product control systems, MES, etc.) it is necessary to know in which data model the signals are sent by the respective system.

To illustrate the background of such a communication task, the OSI layer model of data communication is first explained in a short and easily understandable way.

Background to the realization of digital data communication

The basic model for almost every form of current data communication is the OSI model. The OSI model was already introduced in 1984 and divides the machine communication into 7 hierarchical levels. For each of these levels (different) standards are defined. The OSI model is the still valid standard for data communication in IT systems. When sending digital information, the data passes through all levels of the OSI model from level 1 to level 7 or vice versa.

To understand how data communication works, the tasks of each of these 7 OSI layers are explained using a simple example – easy to understand and clear.
The example of data communication used here is that a PC user makes an entry with the keyboard and generates a short text which is then sent over the Internet and displayed on a remote PC – in other words, an identical task compared to the communication of a sensor value from one machine to another.

The human enters his input on his PC. For this purpose he uses an application, e.g. an e-mail program. This application is part of layer 7 – so we start the explanation at the end of the OSI model.

Layer 7: Application layer – e.g. e-mail client software
The application layer is what the user sees, the application he has opened on his PC (or mobile device) and with which he interacts. Here, interactions can be carried out, inputs can be made or outputs can be queried. The program code of the application converts the input into various other data formats, but this is hidden from the user.

The human input in the application is stored in a data format which is useful for this application, but this does not have to be a standard format. To enable communication with other systems, it is therefore necessary to convert this individual coding into a standard coding. This is done in the 6th layer.

Layer 6 – Presentation Layer – e.g. ISO 8822 / X.216
The data presentation layer converts the data from the display format (e.g. ASCII) into an independent form and thus enables syntactically correct data exchange between different systems, regardless of their display format. It thus serves as a translator between different data formats.

Now that the user’s entries are available in a standardized data format, the data transport can begin. However, software systems are structured in such a way that not every software system generates its own individual communication solution. Instead, software systems access other applications (called services) and use their capabilities. In a software program such as an e-mail program, for example, there are therefore no functions for data communication whatsoever, but only the necessary services that provide this function are addressed. Such services are usually standard components of the operating system, for example Windows, Linux, Android, MacOS, etc. In a figurative sense, such a service is a resource on which the application is built, just as the power supply is a resource of a production company that is simply used instead of generating the power itself.
The user input in the application (layer 7), which was then standardized in a service from layer 6, is now passed on to another service (layer 5), which establishes a session for data transport.

For this service the realization of the communication is something like a small project. This project is broken down into sub-projects and executed. This service also makes sure that in case of problems (e.g. data transport was interrupted), the overall task of data communication can be completed successfully at the end.

 

Layer 5 – Session Layer – e.g. ISO 8326
The session layer or communication control layer ensures that different processes or systems communicate with each other. For this purpose, services for an organized and synchronized data exchange are provided. An exemplary function of such a service is the use of check points at which a communication interrupted on the transport layer can be seamlessly resumed and synchronized.

After the overall task of the data communication has been split up into subtasks by this service (layer 5), the individual subtasks are sent to the dispatch department, and thus supplied to a service of layer 4 (transport layer). There, the individual data are divided again, so that small self-contained elements can be transmitted.

Layer 4 – Transport Layer e.g. TCP, UDP
At this level, the data is transported between the higher levels and the levels below. Within the transport layer, the data is segmented and organizationally coordinated and, for example, the creation of traffic jams is avoided. In the transport layer, the data generated by the upper layers is divided into individual segments (data packets), so that even huge data finds its way through the network in small, encapsulated elements. Transport layers commonly used today are, for example, TCP/IP or UDP.

These small data blocks, which are broken down in the transport layer, are now prepared for transmission. For this purpose, the recipient of the data is read out and a route is identified on which the data packets can be transmitted from the starting point to the destination. For example, the data packets can be transferred from a PC in Germany via a server in Frankfurt to a server in Amsterdam and from there to a PC in London. This route is the route planned in the network layer (routing) that the individual data packages will take.

 

Layer 3 – Network Layer – e.g. IP
On level 3 the connection between transmitter and receiver is established, disconnected and monitored. A frequently used standard is the IP standard. This level serves as the switching layer. Tasks such as searching for routes and forwarding data are performed here. Data is rarely transmitted directly from the sender to the destination receiver, usually the data is transmitted via intermediate stations (nodes). The nodes receive the data and forward it to the next node along the correct path (routing) until the data has reached its destination. Typical formats at this level are IP, IPsec, etc.

Once the route has been determined, the data is transferred to the security layer, where the individual small data blocks are prepared in such a way that secure and error-free data transmission can be ensured. The data is segmented in such a way that each data packet contains information about how the data looks like at the beginning and at the end, and what total amount of data (checksum) is contained in this data. This information is added to each individual data packet and checked at each node on the route of the data. If this check information, the beginning or the end is missing for a data element, or if the checksum does not match the transmitted checksum, this data is transmitted again until the data has been transmitted correctly.

 

Layer 2 – Security layer / Data Link Layer – e.g. MAC
The task of the data link layer is to ensure reliable and error-free transmission. This layer therefore describes the way in which the data flow is set up and separated, how errors are handled and how the data stream is handled. Regulations belonging to this layer include MAC (Media Access Control) or LLC as well as IEEE. The bit data stream is divided into blocks (frames) and checksums are added so that faulty blocks can be detected.
Hardware on this layer: e.g. switch

For physical data transmission, all data segments are then broken down into digital data (bits) and these signals are transmitted in the form of ones and zeros (digital signals) from endpoint to endpoint.

 

Layer 1 – Bit transmission layer / physical layer – e.g. Ethernet
The physical layer describes the physical structure of the data communication. An example for the physical layer would be the IEEE 802.3 standard or also known as Ethernet (Lan cable and RJ45 connector). Bits, i.e. ones and zeros, are transmitted on this layer.
Hardware on this layer: network cables, connectors, etc.

When the data has passed through all these steps and arrived at the destination, it travels through all layers from layer 1 – layer 7 again, so that the recipient of the sent text message can see it in his individual application (e.g. another e-mail program) and in a different font and language (e.g. in the Cyrillic alphabet).

Note: There are several different options/services available for fulfilling the tasks within each layer. For example, TCP can be used as transport protocol or UDP or Profibus, Modbus, Profinet (or others). As transmission layer Ethernet or WLAN can be used, or, or, or. Each service has its own special features.
In addition, different standards have been established for different systems in the past. PC systems, for example, work with TCP/IP (Ethernet) communication as standard, while older machine controls are often based on Profibus (e.g. RS485) communication. This is exactly where OPC UA comes in.

 

And what benefits does this OSI layer architecture bring?

The benefit of the OSI architecture is that, depending on the purpose and environment, ready-made services can be used for a wide variety of scenarios. For example, it is possible to establish TCP/IP communication both via wired network types (Ethernet) and wireless networks such as (WLAN 802.11). The particular advantage is therefore that the application layer can be completely independent of whether communication takes place via a WLAN or a LAN. The software (e.g. the e-mail program) works without any problems without changing any communication paths or logic in the software.

 

And which task should OPC UA actually solve?

The use of OPC UA should ensure that secure, simple and robust communication between different systems can be realized.
The communication standard OPC UA does not replace established communication protocols (e.g. TCP/IP, Profibus, etc.) but it defines a framework how different systems can communicate with each other, independent of their communication protocols.
The goal of OPC UA is to establish communication to any system, regardless of which protocol is used.

Example:
A software communicates with different systems and visualizes in a graph information from all systems simultaneously (e.g. Vipra® Graphs):

 

• User interface of the software
  • Software acts as OPC client (integrated or external)
    • OPC client communicates with OPC server (integrated or external)
      • OPC UA Server communicates via
        • Profibus with SPS machine control
        • Profinet with SPS machine control
        • Canbus with SPS machine control
        • TCP/IP with another system (PLC, PC)
        • RS232 with another system (PLC, PC)
        • RS485 with another system (PLC, PC)

Thus OPC UA does not replace RS232, Profibus, RS485 or TCP/IP but OPC UA determines WHAT has to be transmitted via the respective interface HOW in order to be able to access this component in the usual and identical way independent of the transport level.

What are the core functions defined in the OPC UA communication standard?

The following functions are defined in the OPC UA communication standard:

• Basic functions
  • Findability: Systems that are OPC UA communication enabled should be easily findable in the network for other systems
  • Structures: All data structures should be uniform, so that e.g. file and folder structures are preserved and no unstructured lists are created
  • Access: It should be possible to control access to the structures through access authorizations
  • Subscriptions: Data should be able to be subscribed to so that they are permanently communicated automatically and do not always have to be queried
  • Events: Possibilities to define which events are to be reported automatically
  • Methods: it is possible to start different functions remotely
  • Platform Independence
  • Compatible with PC systems, cloud-based servers, any SPS controls, microcontrollers
  • Compatible with all operating systems: Windows, Apple OSX, Android, Linux, etc.
•  Security
  • Firewall-friendly design
  • Control options
• Transport
  • Definition of a variety of protocols from binary transport to JSON
  • Session encryption, encrypted data transmission
  • Message signatures, checking the origin and integrity of data
  • Authentication, certification of access permissions
  • User control, access right definitions
  • Logging: Accesses are logged
• Extensibility:
  • Open and growing platform in which new communication possibilities are continuously integrated

What is the advantage over the classic OPC versions?

OPC UA is the latest OPC standard and replaces previous OPC versions. However, the basic interfaces have already been defined here and manufacturer-independent data exchange is now possible.
However, the classic versions are bound to a Windows operating system. Direct communication via different platforms (Linux, Mac, Android etc.) is therefore not possible. Additionally, dynamic TCP/IP protocols are used for cross-network communication. This often leads to firewall problems. Avoiding these problems is only possible via detours and involves considerable effort. A common solution is tunneling. Here, the data traffic is encapsulated in a simple TCP/IP protocol, transported through the firewall and unpacked in the target network.
Important OPC components such as OPC DA (data point oriented data exchange), or OPC HDA (historical data points) are integrated as specifications in OPC UA. These specifications can be used independently, depending on the application.
OPC UA now combines all classic functions and additionally enables platform-independent, cross-network communication.

 

How are tasks distributed in the OPC network?

OPC uses a server-client model. Here the OPC server is the basis of communication. The OPC standard, the OPC interface and a communication protocol for the control system are implemented here. The OPC clients are the logical counterpart. Due to the implemented OPC standard, these can be connected to any server and read out the data in an application-specific way. Vipra® can, for example, take on the role of an OPC server as well as that of an OPC client. It can therefore receive data from all OPC UA-enabled systems and send data to all OPC UA-enabled systems.

 

OPC UA – summarized again:

OPC UA is a description of a structure for open platform communication with a uniform architecture (OPC UA – Open Platform Communication Unified Architecture) developed by the OPC Foundation, an independent institution.
Behind this communication standard is a description of how the communication has to take place and which special features have to be considered. Anyone who uses this standard is compatible with all other systems that also use these standards. However, the description of these standards is completely “open” and accessible to everyone – there are therefore no manufacturer-specific features or secrets, as with a so-called proprietary communication interface.
Anyone who has mastered OPC UA communication can thus communicate with another OPC UA communication system.
However, the OPC UA communication standard is not a service or a software, nor is it a protocol description like TCP, IP, etc. The communication standard only describes how the data is to be structured and which formats and services are used and how they can be combined.

 

What concept does the data structure follow?

The most basic element of the OPC UA data structure is a data point, the so-called node. A node can preferably be equated with an object from object-oriented programming. Every node has attributes. These can be useful data or metadata. All nodes are in a corresponding relation to each other. They are organized via namespaces in a tree structure. Within each namespace, each node is uniquely identified. However, the designation is available again in another namespace. This ensures great flexibility and dynamic code, but also creates complex data models. A solution here can be the implementation of application-specific Companion Specifications Plug-ins (e.g. EUROMAP).

Simplified examples for illustration
Data access to a proprietary interface:
“HT1, 210.5, HT2, 211.5, HT3, 222.3, HT4, 221.0, UM, 75.9, STR, 55, NB, 33, SE, 1278936756123”

Data can be read from such an interface, but the structures are missing and it is often not clear what kind of information is involved. The manufacturer can of course read this information easily, since he knows the structure of his data. He knows that behind the abbreviation “HT3” the value of the “temperature of heating zone 3” is hidden in the unit “°C” and can query this. Someone who does not have this information must first “decipher” it at great expense.

Data access via OPC UA – tree structure:

• Extr:
  • Extr_Zyl_Temp
    • Extr_Zyl_Temp_1: 210.5
    • Extr_Cyl_Temp_2: 205.3
    • Extr_Cyl_Temp_3: 207.4
  • Extr_Antr_Data
    • Extr_Antr_Data_Drehz: 75.9
    • Extr_Antr_Data_Str: 55

The OPC UA structure (especially with an companion specification such as EUROMAP) defines exactly which value is transmitted how and with which designation and structure – communication with such a system is thus considerably facilitated.

If this topic is of interest to you, you might also be interested in our following article on “EUROMAP – What is it?

 

Register here (free of charge) as a premium member and get access to our download area. There you will find various tools and checklists. In addition, as a premium user you will always be informed about new contributions.