For the last two years there has been increasing discussion about OPC UA over TSN (Time-Sensitive Networking) providing a common Ethernet network from the sensor to the cloud. Until autumn of 2018, this scenario seemed unrealistic since the OPC Foundation had been largely focused on machine-to-machine (M2M) and machine-to-cloud (M2C) applications (rather than field-level communications). But some 17 well-known IT and automation suppliers, loosely affiliated as “Shaper Group,” kept up pressure for harmonized communication from the sensor up to the cloud.
On Nov. 5, 2018, the OPC Foundation announced the launch of a new initiative to provide vendor-independent, end-to-end interoperability into field-level devices. Working groups started up immediately and, on April 2, 2019, Peter Lutz was nominated director of the OPC Field Level Communication (FLC) initiative.
The vision here is for a new open, unified, standards-based Ethernet based network protocol that will include the fieldbus between machine controllers and sensors/actuators and thus have the potential to reduce the current costly fragmentation of industrial Ethernet-based fieldbuses. Ultimately, this new vendor-independent Ethernet network based upon OPC UA and TSN will reach from the field level to the cloud. This ARC Advisory Group Strategy Report will take a closer look at the impact of OPC UA over TSN at the field level between controllers (such as PLCs or CNCs) and sensors and actuators. Our focus here will be on machinery and discrete manufacturing, rather than process manufacturing.
Today, machine builders and suppliers of smart field devices must support six to eight different fieldbus protocols to cover the market. The cost advantages (for suppliers, SIs, and end users alike) of having one standard, real-time-capable network protocol would be significant. A truly vendor-independent fieldbus protocol would also allow machine builders and process equipment suppliers to select the best automation devices for their needs and thus increase their flexibility tremendously. But will this remain a vision or become reality? And, if so, how soon?
Some key terms used in this report include:
- OPC UA - Open Platform Communication with Unified Architecture
- OPC FLC -the Field-Level Communication initiative and working groups of the OPC Foundation
- OPC UA Companion Specifications - the semantic standards that smart devices and smart machines use to communicate with each other
- Pub/Sub – the Publish/Subscribe alternative to client/server enables “many-to- many” communications
- TSN – Time-Sensitive Networking provides deterministic, real-time communications
Today, one finds different networks between the IT assets and machine controls (e.g., PLCs), between machine controls of multi-machine production lines, and between the machine controls and the field-level smart sensors and actuators. Gateways usually connect these different networks.
A common vision across all Industry 4.0 (I4.0) and Industrial IoT (Internet of Things) activities is to replace the many different networks between and IT and OT equipment with a common industrial network with gigabit bandwidth. This would eliminate the need for protocol converters and software modifications for every application. This would also allow digital information to flow between sensors and actuators, controllers, and the cloud; providing end users with the flexibility to choose the best automation products for their respective applications. In this scenario, we would be able to connect a servo drive from “Supplier A,” to a PLC from “Supplier B” without needing a gateway or software modifications. The same applies at the machine level.
While the OPC UA protocol defines the standards for an information model for such a network, TSN enables real-time performance; a typical requirement at the field level in applications such as multi-axis motion control. The vision is for an open, unified, standards-based Industrial IoT communication solution between sensors, actuators, controllers, and the cloud that can address the full range of requirements of industrial automation.
As we’ll see, open, unified, standards-based, and vendor-independent interoperability are all key terms and concepts here.
An open I4.0/Industrial IoT communication solution means that the solution has public specifications and is not exclusive to or dominated by any one company.
A unified I4.0/Industrial IoT communication solution means that communication profiles for smart sensors and actuators (called companion specifications), are identical for each device type, regardless of the supplier. The working groups of the OPC FLC initiative will have to agree on a common set of profiles. Since each automation supplier already has its own profile, this will be a major challenge. Companion Specifications must also be agreed upon at the machinery or process equipment level, which will require the engagement of other organizations.
A standards-based I4.0/Industrial IoT communication solution means that a worldwide standards development organization (SDO), such as the IEEE and/or the IEC, would set forth all relevant technical details. IEC 62541 defines the Information Model of the OPC Unified Architecture, whereas TSN (Time-Sensitive Networking) is a set of IEEE 802.1 standards defined by the IEEE 802 TSN task group. Currently, a dual IEC/IEEE 60802 standard is being prepared to define TSN profiles for industrial automation.
Vendor-independent interoperability provides machine builders, systems integrators, and end users with significant flexibility, such as the freedom to connect Supplier A’s PLC to Supplier B’s servo drives, rather than being limited to having to use servo drives from Supplier A (or possibly one of its technology partners). This would represent a revolution within industrial automation, providing all participants with much more flexibility. Like other initiatives, it would also force automation suppliers to develop new unique selling propositions, rather than relying on their existing technology ecosystems. Conceivably, vendor-independent interoperability could also extend into the level of production machines and process equipment. Clearly, this will be an ongoing process.
Some Fundamental Misunderstandings
ARC has encountered some fundamental misunderstandings in discussions about OPC UA over TSN. These can be cleared up easily.
The term “OPC UA over TSN” suggests this is one initiative. In fact, OPC UA is managed by the OPC Foundation, while TSN falls under the IEEE’s umbrella. Both organizations address different aspects of communication and have different and independent implementation schedules.
- OPC UA (Open Platform Communications with Unified Architecture), a set of standards representing an information model, is used for client-server communication in layers 5 to 7 of the ISO/OSI communication model (Session, Presentation, and Application) and for OPC UA PubSub communication from layers 2 to 7.
- TSN (Time-Sensitive Networking), in turn, is a set of standards published by a working group within IEEE 802.1. TSN mechanisms reside on layer 2 of the ISO/OSI model (the data link layer).
TSN is often understood as one IEEE 802.1 standard. In fact, it is a set of several standards that can be combined in different ways depending on the application.
One often hears suppliers argue that “TSN is not ready yet” to explain why they don’t have products with TSN available. This is only partly true. IEEE 802.1 standards have been around for many years as “Audio Video Bridging” (AVB). The TSN working group is enhancing these standards to allow Ethernet communication with gigabit bandwidth. These standards are being improved continuously, so one must be careful to check which standards are needed for a given application. Technical standards will always be updated and adjusted as new technology and related capabilities become available.
While vendor-independent interoperability based upon OPC UA is plug-and-run (like one expects from USB), this only applies if different prerequisites are fulfilled. These will depend on the specific application. For example:
- If you need to communicate large amounts of data from a controller to the cloud independently from the automation functionality of the machine or process, OPC UA Pub Sub can make interoperability between IT and OT systems much easier. But you may still have to select the transport protocol, such as MQTT or AMQP. The most common protocols are part of the OPC UA information model.
- If you want to communicate among automation devices, regardless if on the controller-to-controller or controller-to-sensor/actuator levels, you may need to adjust/set OPC UA PubSub message classes for the subscribers in the network. You also need to employ the same companion specifications for all smart devices connected to the network.
Given the high cost of the current fragmented Ethernet fieldbus environment across industry, many end users (and others) have high expectations for a new unified, open, vendor-independent, standards-based Industrial IoT network to become the dominant Ethernet “fieldbus.” But, in fact, the new network based upon OPC UA PubSub and TSN is much more than a traditional fieldbus.
OPC UA defines both an information model and the companion specifications for the connected devices to provide a standard semantic at all levels: field, controller, and cloud. So, while the new network based upon OPC UA and TSN is not a new “fieldbus,” it will include the communication to the field level. Over the long run, it has the potential to gradually reduce the fragmentation of traditional Ethernet fieldbuses. Of course, this would require enough different suppliers to offer products that support this new protocol. For brownfield installations and established OEM designs, the existing industrial Ethernet fieldbuses will continue to be used and will need ongoing support for a long time.
The importance of Companion Specifications
The importance of OPC UA companion specifications for interoperability is often an under-represented aspect in related discussions. To achieve harmonized communications, these companion specifications should establish a common semantic for industrial communication to avoid the need to adjust the semantic used between two devices.
For example, when communicating the serial number of a device from one device to another, do you refer to the device serial number as “SN,” “Serial-No,” “Serial-Number,” “Serial Number,” or “SN#”? And what data type is it? Numeric? Alpha-numeric? Integer? Boolean? Character? The figure below illustrates some aspects of what must be standardized in a companion specification so the communication software in each device doesn’t require customization.
OPC UA companion specifications must be established for all devices in an industrial application. These include:
- Smart sensors (e.g., flow meters)
- Smart actuators (e.g., servo drives)
- Automation controls (e.g., PLC, PC, DCS)
- Machines (e.g., injection molding machines, robots)
- Process modules/units (e.g., filtration equipment, compressor unit)
- IT assets (e.g., servers, ERP)
Having said that, it becomes evident that competitors in each of these segments must agree on a standard set of semantic terms and do so on a worldwide basis. This is not a trivial undertaking. Each competitor in a certain product segment already has a dedicated and typically well-proven device profile that its customers rely on. Also, competitors may run into antitrust issues when coordinating to draft and publish companion specifications.
Quite often, industry associations (such as the VDMA association for machine builders in Germany) assume this coordination role as a neutral partner. VDMA’s various machinery segment groups are connected to partner associations around the world.
The benefit is clear. The figure illustrates the case of a manufacturing site with many injection molding machines and with robots to grip the molded parts and place them onto the next production station. If a robot from Supplier A must be replaced by a robot from Supplier B and both suppliers have agreed upon the same OPC UA semantics, nothing needs to be changed in the communication software of either the injection molding machine or the new robot. This interoperability would make it easy to modify a production line or quickly swap out a malfunctioning robot with another company’s robot, if needed, to minimize production downtime.
This degree of interoperability will require aggressive work on companion specifications. Clearly, many different stakeholders must establish companion specifications. This not only applies to automation suppliers, but also to machine builders and process equipment suppliers. We anticipate that this will be a long and potentially drawn-out process over the next several years, and possibly over the next decade.
As shown in the figure below, there are different ways to implement OPC UA and TSN together with fieldbuses.
Option 1: OPC UA PubSub and OPC UA PubSub TSN with Traditional Fieldbus Protocol
The first step within Option 1 would be to implement OPC UA Pub Sub in addition to the current fieldbus protocol. The upside for users here is seamless Industrial IoT/I4.0 data information exchange from the sensor to the cloud.
The next step within Option 1 would be to implement TSN in the data link layer, providing a deterministic network with gigabit bandwidth. This would allow high-performance data flow from smart devices on the field level to the cloud.
For both steps in Option 1, the traditional fieldbus protocol mechanisms are still required for the machinery automation application. We should soon see implementations with OPC UA Pub Sub and TSN in parallel with the existing fieldbus protocol.
In the existing industrial Ethernet fieldbuses, specific mechanisms ensure real-time performance, but this may require dedicated hardware in the communication equipment and controllers.
A further step would be for automation suppliers to replace their specific real-time hardware in the data link layer with TSN. This would reduce costs for automation suppliers, since TSN-enabled semiconductor products are typically mass produced. The traditional fieldbus protocol mechanisms required by the machinery automation application remain in place, but TSN would ensure deterministic network behavior.
Table of Contents
- Executive Overview
- The Vision
- The Importance of Companion Specifications
- Implementing OPC UA and TSN
- The Reality - Where We Stand Right Now
- Appendix: OPC UA and TSN Supplier Overview
ARC Advisory Group clients can view the complete report at ARC Client Portal
If you would like to buy this report or obtain information about how to become a client, please Contact Us