OPC stands for Open Platform Communications…
… and is one of the most important communication protocols for Industry 4.0 and the IoT. With OPC, access to machines, devices and other systems in the industrial environment is standardized and enables similar and manufacturer-independent data exchange.
Everything that is important to know for operational use is summarized here to give you the necessary orientation between the many technical terms in your project.
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 means that OPC communication can also be provided for systems for which the manufacturer does not provide its own OPC Server. In addition, the manufacturers of independent OPC Servers offer more functions, sometimes simpler operation and better stability. Manufacturers of independent OPC Servers include Kepware (over 150 drivers available), Softing, INAT and Matrikon.
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.
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).
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.
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:
2. Security Model
3. Address Space Model
5. Information Model
8. Data Access
9. Alarms and Conditions
11. Historical Access
For operational use it is not necessary to know the specifications in detail. The most important for the project business are the following:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.