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.
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.