What is OPC UA? A practical introduction

1. OPC Server

The OPC Server is the basis of OPC communication. It is a software that implements the OPC standard and thus provides the standardized OPC interfaces to the outside world. Inside, the proprietary communication protocol for controlling the manufacturer is implemented. OPC Servers are provided by different parties.

OPC Server from hardware vendor

The basic idea of OPC is that the manufacturer of the hardware provides an OPC Server for his system and therefore allows standardized access. The OPC Server from the manufacturer can be supplied as stand-alone software or as an embedded OPC Server on the device or the machine controller.

Independent OPC Servers

In addition to OPC Servers from the manufacturers themselves, there are providers who develop independent OPC Servers. These servers differ by a broader support of communication protocols. This way, it is possible to provide OPC communication even to those systems for which the manufacturer does not offer an OPC server of its own. In addition, the manufacturers of independent OPC servers offer more functions, in some cases more simple operation and better stability. Manufacturers of independent OPC Servers include Kepware (over 150 drivers available), Softing, INAT and Matrikon. The OPC Router can also use the OPC UA Server Plug-in to provide data as an OPC server.

2. OPC Client

The OPC Client is the logical counterpart to the OPC Server. The OPC Server can be connected to the OPC Client and read out the data provided by the Server. Since the OPC Servers implement the predefined interfaces of the OPC standard, each client can access any OPC Server and exchange data with the server in the same way.

Applications acting as OPC Clients

Typical OPC clients are applications that depend on data exchange with industrial systems. What happens to the data in the client is very application-specific. Common applications are visualization and SCADA systems (WinCC, InTouch, FAS inMOVE) or MES systems. The OPC Router with its OPC UA Client Plug-in is also a client with a gateway function.

OPC Test Client

There are many free OPC test clients on the market, with which the function and configuration of a server can be tested very easily and clearly. The existing data points can be searched, connected and the current values can be viewed in a very short time.
In operational use it is very important to test the function of the data source “OPC” via an independent application and thus abstract it from higher-level applications. A popular test client is the Test-Client from Unified Automation.

What question do you have about the OPC Server or OPC Client?

3. OPC Classic vs. OPC UA

The current standard of the OPC specification is OPC UA (OPC Unified Architecture). It is the successor of the old OPC standard, which is called OPC Classic. Many installations of OPC servers are Classic OPC Servers until today.  The old standard already very successfully solved the task of realizing data exchange in automation independent of the manufacturer and defined the basic interfaces. The disadvantage of OPC Classic was the lack of platform independence. OPC Classic is based on the Microsoft technologies COM and DCOM and therefore OPC Server and OPC Client installations were limited to Microsoft Windows operating systems and networks. With the increasing success of other platforms (Linux, Web architectures, Cloud, IoT Devices, CPS, …) the distribution of OPC was limited.
The OPC Foundation recognized this and created the successor OPC UA. OPC UA has platform independence and interoperability as its primary goal. Technically, the standard was built on the basis of basic web technologies (TCP/IP, http/SOAP). The basic concepts for data exchange were adopted, combined and supplemented by further concepts (see specifications).

4. OPC UA Pub/Sub

The communication participants in OPC UA Pub/Sub are divided into Publisher and Subscriber. Devices and software can communicate with each other via a Broker without having to rely on the 1-to-1 relations of a client/server communication. Therefore, communication within the system can be accelerated and processor capacity can be saved. 

5. OPC Foundation

The OPC Foundation is the organization behind the standard and with 678 members it has a very broad base. Its members include global players in the automation industry. For example: Siemens, Honeywell, Microsoft, Beckhoff, SAP, Yokogawa, ABB, Rockwell, Schneider Electric, Wago, Iconics. All members of the Foundation can be found in the OPC Foundation member list. The association was founded in 1994 and released the first version of OPC in 1996. Since then, it has been working very successfully and actively on the further development and dissemination of the OPC standard

6. OPC Specifications

The standard OPC UA consists of individual specifications. Each specification describes a partial function and specifies which server and client interfaces must be implemented for this function in order to support it. OPC servers and clients do not have to support all specifications. Depending on the application, often only individual specifications are programmed. When using an OPC server and clients, it is therefore important to consider which specifications are required and which are implemented by the server and client.

OPC UA consists of these specifications:

1. Concepts
2. Security Model
3. Address Space Model
4. Services
5. Information Model
6. Mappings
7. Profiles
8. Data Access
9. Alarms and Conditions
10. Programs
11. Historical Access
12. Discovery
13. Aggregates
14. PubSub

For operational use it is not necessary to know the specifications in detail. The most important for the project business are the following:

Data Access

The Data Access specification describes the classic exchange of current data. The OPC Classic Standard already specifies that the data exchange is data point-oriented. A value can be read and written for each data point. A data point value is described by the actual value, the time stamp at which the value was current and by the quality, which describes whether the value is valid or whether, for example, the connection to the controller was interrupted and the value is therefore not valid. This specification alone makes it possible to obtain and process data independently of the underlying system.
In the current standard, the possibilities have been extended with complex data types (structures) and functions in order to meet the new requirements.

Historical Access

Using the Historical Access specification, it is possible not only to read data with the current value, but also to query historical values. An OPC server that implements this specification must have an internal data memory in order to provide the values of the data points for possible historical accesses. A client that reads historical data points via Historical Access also transfers the desired time span to the server in addition to the data point information.

Alarms and Conditions

The Alarms and Conditions specification defines a standardized model for alarm messages and alarm logic as part of OPC UA. For OPC client applications this simplifies the task of generating alarms from data point values because the logic can be implemented by the OPC server and not by the manufacturer of the client software.

What question do you have about the OPC UA Specifications?

7. Companion Specifications

The Companion Specifications are information models built by industry groups on the basis of the OPC UA Standard Model. They define defined data point structures for industry-specific applications and objects. Examples are models for injection moulding machines (Euromap 77), machine tools/CNC (umati), robots, RFID and AutoID systems (AutoID) and many others.
The already adopted Companion Specifications are listed by the OPC Foundation on its website. Many more are currently being developed by working groups and are about to be adopted.
The OPC UA standardizes the simple data exchange with machines and systems, the Companion Specifications also standardizes the data models for similar machines and systems in which it is specified which data is to be exchanged. This leads to a significant simplification in networking according to the industry 4.0 idea, since machines from different manufacturers supply and receive the same data structures.

8. Security in OPC UA

During the development of the OPC UA standard, the highest degree of safety was taken into account from the very beginning. In contrast to OPC Classic, OPC UA was developed “firewall-fiendly”, i.e. it can be controlled and steered via standard network techniques.
Several protocols have been made available on the transport layer. Thus, a binary protocol can be used directly on TCP/IP for fast applications or the cross-platform SOAP with HTTPS.
Encryptions of 128 or 256 bits are used to secure the data during transmission, as well as message signing, packet sequencing and user authentication.
OPC UA uses a certificate exchange for further security, so that each client has to authenticate with a certificate. In this way it can be controlled which client is allowed to connect to the server.
The BSI has investigated the security of OPC UA and found no systemic security gaps.

All about the practical implementation in the tutorial “OPC Router as UA/DA Client and OPC UA Server”

9. Tunneling

Tunneling refers to the transfer of OPC data from one network segment to another. The term originates from the time of OPC Classic, because due to the DCOM technology used, cross-network communication via OPC Classic is very difficult or almost impossible. Some software manufacturers have created a solution for this by encapsulating the data traffic and converting it into simple TCP/IP so that the data traffic could take its way through the firewall. In the target network, the data traffic was unpacked again and made available in an OPC Classic Server.
With the OPC UA technology, tunneling is no longer necessary. If only one OPC Classic Server has already been installed and yet communication is to take place across networks, an OPC wrapper is required. For this an OPC UA Server is used, e.g. the KEPServerEX, to get the data as a client from the OPC Classic Server and to make this data available via OPC UA firewall friendly.

10. OPC UA over TSN

OPC UA over TSN was designed for real-time communication at the field level between control systems. The TSN stands for Time Sensitive Network and describes the requirements of machine networks with deterministic response times. In contrast to the client-server operation of OPC UA, OPC UA over TSN communicates according to the Publisher-Subscriber method. For the use of OPC UA in normal Ethernet-based, non-real-time environments, OPC UA over TSN currently plays no role

11. OPC UA Pub/Sub over MQTT

The principle of Pub/Sub is not only used by the OPC UA Pub/Sub Plug-in, but also by the common message protocol MQTT. Both Plug-ins enable the OPC Router to be operated as a Publisher and Subscriber. However, the OPC UA Pub/Sub Plug-in differs from the MQTT Plug-in in that the structure of OPC UA data is already available in the OPC UA Pub/Sub Plug-in. That allows the OPC Router to publish OPC UA data to other devices or systems for further processing, or to subscribe OPC UA data from others. Implementing OPC UA data via MQTT would be much more difficult, since most of the message content in MQTT is described in XML or JSON.  

What question do you have about OPC UA Pub/Sub over MQTT?

12. OPC XML

The OPC XML specification was the OPC Foundation’s first attempt to achieve platform independence and to break the link to Microsoft technology. The XML format, which was emerging at that time, was used in connection with web technologies. In 2003, the OPC XML specification was released. Three years later, in 2006, however, the first version of OPC UA was already available, making OPC XML obsolete.

13. DCOM

The Microsoft technology DCOM is the network version of the COM technology. COM stands for Component Object Model and is the object-oriented technology in the background of the Microsoft operating system. It is used to let different applications work together intelligently. Since it was the leading technology at the time of the development of the OPC standard, it was used as a basis. The OPC Classic Server is a COM component and is connected as such by the client. If an OPC Classic Server is connected via the network, the Distributed COM (DCOM) protocol must be used, which is deeply anchored in the Windows operating system. DCOM has a complex authentication logic and uses multiple and dynamic TCP/IP connections, making it uncontrollable for a firewall and categorically blocked. In practice, therefore, DCOM connections were usually not established.

14. Platform independence and interoperability

OPC UA has become completely platform-independent through TCP/IP and web protocols for communication. An OPC server, which makes its data available in the network, can be addressed via these protocols. It is irrelevant whether the OPC Server runs on a Windows operating system, a Linux, UNIX or Mac. Even completely own platforms with TCP/IP stack can implement an OPC server. So typical embedded systems, devices and controls can serve as servers. The goal of platform independence has been achieved and leads to a fast distribution of OPC UA. Interoperability is the logical consequence of the infrastructure with various OPC UA participants in the network.

How to implement your digitalization strategy with OPC UA – we will be happy to help you!

15. OPC UA and Industry 4.0

In 2011, the term Industry 4.0 was used for the first time in a working group. OPC UA had already been defined as a standard long before. Nevertheless, OPC UA is one of the leading communication protocols for industry 4.0. Intelligent networking of factories requires a common language. This is exactly what OPC UA delivers and is therefore an important instrument for the implementation of Industry 4.0.

16. OPC Foundation Video

17. Security in REST

Since HTTP is used to call REST endpoints, the authentications available in the standard system can also be used, such as HttpBasic, Jwt, Ntml, OAuth1, OAuth2.
In addition, https is of course used instead of http in order to use a tap-proof connection.
Besides the standard authentication options, a so-called AppKey is often exchanged. This key is a secret code created for the client, which is transferred with every call to get the authorization for the call. The so-called Bearer Token is also supported by the OPC Router.
REST is considered secure due to the use of widely used methods.