There Is No Industry 4.0 without OPC UA

A central challenge posed by Industrie 4.0 and the Industrial Internet of Things (IIoT) is the secure, standardized exchange of data and information between devices, machines and services across different industries. As early as April 2015, the Reference Architecture Model for Industrie 4.0 (RAMI 4.0) recommended only IEC standard 62541 OPC Unified Architecture (OPC UA) for implementing the communication layer. In November 2016, the Industrie 4.0 Platform published a checklist for classifying and advertising products as Industrie 4.0 “Basic,” “Ready,” or “Full”. To comply with the “Industrie 4.0 communication” criterion, even the lowest category requires the product to be addressable over the network via TCP/UDP or IP and to integrate at least the OPC UA information model. As a result, any product being advertised as “Industrie 4.0-enabled” must be OPC UA-capable (either integrated or via a gateway). The checklist also stresses the information modeling property of OPC UA.

OPC UA is not just protocol – it’s a whole lot more

When it comes to information modeling, many small and medium-sized companies tune out, because they compare OPC UA with other protocols like MQTT and assume that it has limitations. We often hear questions like, “OPC UA can’t communicate directly with the cloud, can it?”

First of all, every equipment and machine manufacturer already provides an implicit information model with data interfaces (via various protocols). Humans have learned to adapt to the computer’s way of ‘thinking’ – documenting what the bits, bytes, and hex codes mean. This new world full of devices capable of a service-oriented architecture (SoA) helps humans understand the “things” more quickly and easily, because they offer “services” and describe their underlying meaning. The subject of SoA is nothing new in the world of IT. Now, however, it extends all the way to the “things” themselves. This is where OPC UA comes to play, providing the framework for industrial interoperability. Machine and device manufacturers describe the object-oriented information of their systems and define the access rights along with integrated security features. Germany’s BSI (Bundesamt für Sicherheit in der Informationstechnik, or Federal Office for Information Security) published the results of its security analysis of OPC UA in April 2016 in highly positive terms. This was because machine builders keep full control of the data, i.e. they can distribute it in a targeted and controlled manner, which enables them to participate monetarily in big data applications and data analytics.

To exchange the data, OPC UA combines two mechanisms to implement various scenarios:

A client-server model, in which OPC UA clients use the dedicated services of the OPC UA server. This peer-to-peer approach provides a secure and confirmed exchange of information, but with limitations regarding the number of connections.

A publisher-subscriber model where an OPC UA server makes configurable subsets of information available to any number of subscribers. This kind of broadcasting mechanism provides an unconfirmed “fire and forget”-style exchange of information.

OPC UA offers both mechanisms, but the more important benefit is that they are decoupled from the actual protocol. TCP and HTTPS are available for the client-server model, while UDP, AMQP, and MQTT are available for the publisher-subscriber model. As a result, the question of “OPC UA or AMQP or MQTT” doesn’t matter from the OPC Foundation’s perspective. Since the smallest microcontrollers may not have enough resources to implement full-fledged OPC UA, the device can offer its data over MQTT or AMQP in an “OPC UA-compliant” manner, making it easier to integrate it on the other end. After all, agreeing on an information model and what the data means is the key to achieving the concepts of Industrie 4.0.

Trend: Information models

OPC UA provides secure transport of data via diverse and expandable protocols. But who defines the data’s meaning? Other associations like AIM for the auto ID industry (RFID readers, scanners, etc.) and VDMA technical groups for injection molding machines, robotics, machine vision, and 35 other VDMA industries already define their information in OPC UA servers in the form of so-called OPC UA companion specifications. For an equipment supplier, meeting this type of industry standard does not automatically mean they become exchangeable, as each manufacturer can offer their own special services on top of the standard. Intelligent devices should definitely be able to support multiple information models simultaneously – for example, the dedicated functionalities of an injection molding machine, in addition to the models for energy data or MES interfaces. To reduce the engineering effort, the importance and availability of such industry-specific and multi-industry information models will increase rapidly in the future. OPC UA may not directly increase an industrial device vendor’s sales, but not supporting the OPC UA standard will definitely decrease them considerably.

Trend: SoA

Most of the industry-specific information models developed so far are no longer based on the exchange of bit/byte properties, but rather on SoA services with complex parameters. An OPC UA client that does not support any methods for this purpose or complex parameters will be increasingly hampered in its communication with OPC UA servers. An RFID reader offers no bits to activate a read/write command, but instead uses methods that can be read by humans: ReadTag, WriteTag, and KillTag, among others. OPC UA is ideal for SoA implementation, which is why the German Commission for Electrical, Electronic & Information Technologies (DKE) lists OPC UA as the only SoA solution.

Trend: Service-to-Service

OPC UA provides consistent scalability from the sensor to the enterprise IT level, making a significant impact on the automation pyramid. While this pyramid will continue to exist for the factory’s organizational structure, OPC UA bypasses the communication pyramid entirely. The devices can deliver data, either directly or in parallel, to the PLC, MES, the ERP system or to the cloud level. This is where suppliers see opportunities for new business models. For example, manufacturers can bill for their barcode or RFID reader on a per scan basis while the data being read or scanned never leaves the factory.

Trend: Chip-based OPC UA

OPC UA will continue to be integrated into ever-smaller devices and sensors. Today’s smallest OPC UA software solutions for industry with limited (but readable) functionality require just 35 KB of RAM and 240 KB of flash memory. Now that the first chips with integrated OPC UA have hit the market, OPC UA can make further in-roads into the world of sensors. As a result, OPC UA applications are already extending from the core area of automation into other areas like industrial kitchen appliances.

Summary

OPC UA has already become the de facto standard for the automation market and Industrie 4.0. In combination with TSN communication, OPC UA will also be real-time-capable. This is not to propagate another fieldbus, but to create a predictable time basis for the exchange of SoA services. Some challenges, such as the configuration of complex TSN networks, have yet to be resolved. This is why the OPC Foundation is not actively promoting OPC UA and TSN at this time. However, OPC UA is covering a growing range of communication scenarios, which makes it increasingly difficult for suppliers to justify proprietary solutions. Products will increasingly differentiate themselves based on the features of the device itself or of external services, not the interface. In the future we will see rapid growth in the information models of additional industries, as OPC UA is the preferred platform of the world’s largest ecosystem for interoperability.

Heads up! On May 22, 2018, we updated our Privacy Policy and Terms of Service to make them clearer and to address some new privacy laws in Europe. If you keep using Automation.com after May 25, 2018, you're letting us know that you're okay with the updates.