OPC UA – an overview over the central Industry 4.0 standard
- Automation
- Digitalization
- 20.2.2023
- Reading Time: {{readingTime}} min
- Share Article
Contents
Early on in the course of industrialization, the major market players realized that ultimately, everybody benefits if there is cooperation instead of confrontation in certain areas. Already in the late 19th century, the first standardization committees were formed in Europe. The first German industrial standard—“Deutsche Industrie-Norm” (DIN1)—was issued in 1918.
But conflicting interests have never quite disappeared, even within the various standardization committees. These conflicts mean that frequently, only minimal agreements can be reached. While this does create uniform rules for basic properties and processes, different manufacturers can still implement further functions and options beyond the standard.
What this means is that in the end, devices and technical components made by different manufacturers are again only partially compatible. Customers who do not source everything from a single supplier are thus forced to do without parts of the functionality, or must invest the effort of creating it themselves.
Babylonian confusion in industrial communication
But the limitation to minimal agreements is not the only obstacle for cooperation. Sometimes, even minimal agreements are missing and instead, competing standards exist. In the industrial sector, this is true in particular for communication. Numerous manufacturers have created their own “standards”—such as AS-i, CANopen, CC-Link, ControlNet, DeviceNet, Interbus and Profibus and many more so-called field buses—for the transmission of data and control commands between sensors, actuators and controllers.
The advancement of the IP networking standard had the potential to overcome this Babylonian confusion of languages. But standard Ethernet is inadequate for the requirements of the industrial sector—and when adapting it to their specific needs, each driver of innovation in industrial networking reverted to backing their own horse: Mitsubishi Electric went with CC-Link IE, Beckhoff with Ethercat, Rockwell with EtherNet/IP, Schneider Electric with Modbus TCP, B&R with Powerlink, Siemens with Profinet, and Bosch Rexroth with Sercos.
And yet again, customers were forced to either enter the closed universe of a single manufacturer, or pay a hefty price for openness. They need gateways in order to connect the various network strings with different protocols.
From Industry 3.0 to Industry 4.0
The transmission of sensor measurements and simple control commands had thus become possible. However, the next innovation leap exposed new problems. The goal of Industry 4.0 is to network numerous components. This has fractured the vertical orientation of the “automation pyramid”. There are now horizontal connections within the pyramid as well as lateral connections between different machines, systems and even production facilities scattered across the globe.
Within this framework, a meaningful data exchange must be based on consistent data standards. The absence of such conventions was one of the greatest obstacles in the development of Industry 4.0, because combining data from different sources—a process called “homogenization”—required an enormous programming effort. Data formats, variable names, type and scope of metadata—the number of possible combinations is mind-boggling as soon as the worlds of different providers collide.
Another problem: how to interpret the data? After all, just because items have the same name (e.g., the same variable name) and look the same (in terms of data format, value range, etc.), it does not necessarily follow that they mean the same thing. However, the development of data-based services and business models, the cross-machine control of production and manufacturing processes, or data analysis through artificial intelligence cannot succeed without the correct understanding of the data to be processed. Data needs its proper context in order to become actual information.
IoT platforms with extensive mapping services provide an initial solution. The providers have analyzed a wide variety of different formats and developed corresponding interfaces that allow the mapping of data onto a common target format.
The alternative is to adapt the cross-machine data communication in-house, requiring enormous manual effort. Each time a new machine is added or a component is replaced, there is the risk that programs need to be tweaked again. Consequently, only the most important data is covered in such scenarios, in order to keep the effort manageable. But this in turns means losing out on some of the opportunities offered by Industry 4.0.
Centralized standard: OPC UA
The Open Platform Communications Unified Architecture (OPC UA) provides a solution for these problems. It is not a communication standard in the strict sense, because essential parts of OPC UA sit on top of layer 7 of the OSI layer model.
Rather, it is a standard for data exchange as a platform-independent, service-oriented architecture (SOA) that permits not only conveying machine data—such as control values, measured values, parameters, etc.—but also describing this data using machine-readable semantics. It considers not only operating data but also the specifications and capabilities of a machine.
This approach makes the communication between different network nodes simpler and more efficient, because in addition to smart devices, simple sensors and actuators can also be networked with each other. Furthermore, it does not only handle “things” in the framework of the (Industrial) Internet of Things (IIoT / IoT), but also services.
The OPC Foundation, which maintains and develops the standard, emphasizes the following major benefit realized in in OPC UA:
- Platform independence: OPC UA can be used by an embedded micro-controller as well as by a cloud-based infrastructure. Likewise, OPC UA is independent of any operating system.
- Safety and reliability: Encryption, authentication and auditing are included. The entire development is based on the “secure by design” approach.
- Expandability:The ability to add new functionality without interfering with existing applications. This has allowed a rapid development of the standard in recent years.
- Robust, comprehensive information modeling: Options for defining complex information.
The development is progressing continuously, with the involvement of manufacturers as well as users, research institutes and various consortiums such as industry associations and standardization committees.
Double recognition as IEC standard
Prior to OPC UA there was its predecessor OPC Classic, which was not platform-independent. Being tied to COM/DCOM helped significantly with the spread of OPC, but this design also had certain crucial disadvantages. For this reason, the decision was made to develop a dedicated communication stack for OPC UA, replacing COM/DCOM. The first draft of OPC UA was published in 2006; in 2009, numerous sections were updated. In 2016, the specification became the IEC 62541 standard. Since then, OPC UA has established itself as a de facto standard for machine communication.
The close tie with Industry 4.0 is based among other things on the concept of the Reference Architecture Model Industry 4.0 (RAMI 4.0). This description of the Industry 4.0 concept as a three-dimensional functional model is documented in IEC PAS 63088. The functions contained therein in turn refer to the corresponding IEC standards. The only communication standard that meets the requirements of RAMI 4.0 is specified there as IEC 62541 OPC UA .
OPC UA: Not one standard among many, but a central component of digitization
Essential properties of OPC UA
OPC UA is independent of the transport method. Different protocol connectors are available for different application scenarios such as high-performance applications or web browser access. IP-based communication, wireless or via Industrial Ethernet cables, WAN and cloud connections and even field bus protocols—OPC UA can make use of all of these transport layers. A dedicated TCP-based binary protocol via the IANA-registered port 4840 has been implemented for client-server connections.
For the cloud, OPC UA relies on common protocols such as MQTT and AMQP; in the field, UDP, RAW Ethernet and protocols such as TSN or 5G for deterministic communication are also supported. Additional protocols such as UDP-based QUIC can be added on; on the client side, web sockets are also supported.
The OPC standard as service-oriented architecture also includes a server/client model based on access to information models via services. The object-oriented server address space provides metadata and object descriptors. Object structures are formed by referencing object instances and their underlying type definitions. These are also object-oriented and can be expanded through inheritance.
Because OPC UA servers carry both their object instances and the associated type objects, OPC UA clients can navigate the address space of any OPC UA server in order to obtain all necessary instance and type information. This is also true for types that were previously unknown, permitting the use of plug&produce without any need for the prior configuration of devices.
In addition, a pub/sub model for data distribution in the network has been in existence for a few years. The basis of the “fire-and-forget” model is that one instance (typically the OPC UA server) publishes data, and the other side (typically the OPC UA clients) subscribes to it. The connection is provided by an intermediate instance, the message-oriented middleware. It uncouples the publishers from the subscribers so that these do not need to know each other. This permits efficient many-to-many communication.
The high level of security is an essential element of the OPC UA communication. The OPC Foundation has had this confirmed by the German Federal Office for Information Security. OPC UA incorporates recognized security concepts and standards that are also used for secure internet communications, such as SSL, TLS and AES, user and application authentication as well as the signing of messages and data encryption.
Industry-specific extensions
Within different branches in the industrial sector—plastics manufacturing, textile industry, wood processing, etc.—certain overlaps and conventions are typical of the information models that describe machines, their capabilities and the data that is generated. Building these right into OPC UA increases the added value of the standard because firstly, it makes industry-specific functionality available for use, and secondly, it increases the pressure to adopt the standard.
Such industry-specific extensions are made possible in the framework of “companion specifications”. More than a dozen of such specifications have already been issued, and many more are in progress. In the German-speaking world, for example, numerous working groups in the VDMA have been entrusted with developing industry-specific standards. Like all other information models, these will be defined, packaged and documented according to the OPC UA specifications, so they can be made available to the OPC UA servers and clients in the network very easily.
OPC UA: Not one standard among many, but a central component of digitization.
It is a long way from the formerly isolated shop floor to networked global production that provides central monitoring and standardized control through cloud applications. The majority of companies in the industrial sector are at a development stage somewhere in-between these two extremes. However, the problems that arise when combining data, developing cross-functional services, and using intelligent functions are always the same.
The machine manufacturing sector is currently in a difficult transition phase. On the one hand, customers have ever higher expectations. They ask for more flexible and smarter machines and systems that are easy to reconfigure and that can be monitored and even controlled via centralized applications. Closer networking entails greater programming efforts, but the reusability and scalability of the code are not guaranteed.
On the other hand, there is OPC UA as a universal solution that can solve all the problems, at least in principle. But here, too, great effort must be invested, at least initially, until the required competencies have been acquired, tools and libraries have been set up, and the first projects have been successfully completed. In view of the forcefulness with which industry representatives, industry associations and standardization committees drive the development and expansion of OPC UA forward, the investment in the relevant know-how is certainly justified.
OPC UA is not a standard among many whose future-proofness is in doubt. It is a central component of the increasing networking and digitization in the industrial sector, and at some point will be a must-have for every machine.
