Figure 1 Various Functions of Industrial IoT (Source: IEB website)
MQTT and OPC UA
Undefined Interoperability of Data Access
One of the many goals of smart manufacturing utilizing industrial IoT is to incorporate new information producers and/or information users into enterprises without incurring integration costs. Simplified integration is primarily achieved through products that implement some well-known standards at the communication and information layers, such as OPC UA and MQTT. However, are these two standards sufficient to achieve interoperability of data access?
Currently, MQTT has become an architecture for achieving “provide data once; distribute everywhere”..The OPC Foundation released the first OPC UA specification in 2006, which includes data access functionality among many other connection capabilities. Its advantages include enabling non-Windows devices, having a browsable address space with standard data type definitions, and a long polling mechanism with deadband filtering conditions. OPC UA has become popular among manufacturers because, in addition to the existing client-server paradigm, it introduced a publish-subscribe protocol in 2018, adding Pub/Sub connections to the specification, including broker-less protocols like Ethernet and UDP, and brokered protocols like AMQP and MQTT. The OPC Foundation continues to pursue interoperability by defining standard object types through complementary specifications, each utilizing core data definitions to construct standard object definitions.
Regarding interoperability of data access, neither OPC UA nor MQTT clearly defines it. As shown in Figure 2, MQTT only defines the basic communication protocol, while all other stacks are undefined, marked in red in the figure. This creates a heavy burden for the information users when integrating applications using MQTT. Integration barriers faced by information users include: familiarity with the topic paths implemented by information producers, and determining whether applications can monitor the health of information producers through last will functionality. Other challenges include: choosing which QoS level to use, whether the information producer publishes at fixed intervals or only on changed data, and so on. Even more daunting for integrators is that MQTT does not define data transmission, so applications of information users must adapt to the encoding schemes, data types, and object definitions chosen by the devices. In summary, MQTT only defines the communication protocol layer in the data access model; the absence of definitions at all higher levels means that choosing MQTT is far from meeting the interoperability goals of data access.
OPC UA achieves standardization at every level of the data access model. Although the definitions at each level are superior to other technologies, the problem lies in the fact that the combination of specifications at each level of the model contains many choices (see Figure 2). Given the excessive communication protocols, encoding schemes, data types, and object definitions, simply connecting an information user to an OPC UA information producer does not guarantee interoperability of data access, as each application may choose different options on the stack. Integrators must carefully assess what options are implemented by the information producer’s devices at each level and ensure compatibility with the functionality of the information user applications. Alternatively, integrators will need to understand the capabilities of the information user applications and limit the range of OPC UA products that can be utilized. Thus, it is clear that if the goal is interoperability, specifying OPC UA alone is insufficient.
Figure 2 Protocol Stacks of MQTT and OPC UA (Source: IEB website)
OPC UA over MQTT
Paving New Paths
Perhaps the OPC Foundation has begun to realize that while having multiple technical specifications at every level can increase flexibility, it also raises integration costs and complicates promotion. Thus, in February 2022, it announced that six cloud service providers, including Amazon AWS, Google Cloud, IBM, Microsoft, SAP, and Siemens, either currently support OPC UA over MQTT in their products or will include it in their development roadmaps. This declaration marks that these six significant companies will be compatible with the OPC UA over MQTT combination. More impressively, this declaration signifies the potential for multi-cloud architectures within enterprises, allowing users to seamlessly transfer data from one cloud provider to another, achieving cloud-to-cloud interoperability. The OPC Foundation noted at the OPC International Day in April 2022 that there are thousands of implementations of OPC UA over MQTT.
For end-users and integrators needing to identify applications of OPC UA Pub/Sub technology, the OPC Foundation created a marketplace in June 2022, as a publicly accessible webpage that allows filtering based on functionality, transport, application profiles, and many other standards. The issue, however, is that while universal market support has been assured, no timeline has been announced for any OPC UA over MQTT products to hit the OPC market, including products from the six cloud service providers. For end-users and integrators needing commercial products, understanding what is available in the market remains a challenge.
Meanwhile, the OPC Foundation is making efforts to build data connectivity with semantic context. The OPC UA FLC (Field Level Communication) initiative aims to create open standard semantic context data connectivity solutions between sensors, actuators, controllers, enterprises, and clouds, meeting all requirements of industrial automation, factory automation, and process automation. OPC UA FX continues to make rapid progress in modernizing fundamental industrial communication and pushing mainstream computing data concepts to the industrial edge. The OPC UA Field Level Communication (FLC) initiative’s goals include building secure and reliable communication across vendors, platforms, and currently unknown domains, achieving interoperability from sensors to enterprises and beyond. The OPC Foundation ecosystem is unified, consisting of industrial, IT, IoT, and cloud organizations, with over 65 joint working groups involved in defining and implementing standard contexts and semantic data models from industrial field devices (including sensors/actuators) to enterprise and cloud systems.
The global available UA Cloud Library, co-developed by the OPC Foundation and the Clean Energy and Smart Manufacturing Innovation Institute (CESMII), makes OPC UA information models available globally in the cloud, providing users with an effective way to find and utilize OPC models. This simplifies the application engineering for providing trusted sources for semantic data models.
There is also a problem of scalability combined with interoperability. Many applications in the IoT space leverage MQTT as a lightweight method to publish data to an arbitrary number of information users. However, despite MQTT’s support for scalability, it does not itself promote interoperability. On the other hand, the OPC Foundation better understands that the challenges of integration go beyond just standardizing the communication layer; hence, they have standardized the complete technology stack from the communication layer to the information layer. Moreover, the OPC Foundation places greater emphasis on the information layer, as its primary value propositions unfold through that layer; OPC UA has dedicated over 4000 pages to information definitions, while communication definitions occupy less than 300 pages, highlighting the disparity.
MQTT/Sparkplug
Also a Solution
To address the lack of information interoperability on MQTT, Arcom/Eurotech created the Sparkplug standard in 2015 to clearly define protocol mappings, encoding schemes, common data types, and methods for custom object structures. Initially, it was an obscure proprietary definition aimed at assisting internal integration via MQTT. Within a year, Cirrus Link used this technology to develop various third-party modules for Inductive Automation’s Ignition (a popular SCADA/MES platform). The MQTT engine module of Ignition establishes a simple and obvious use case for data access interoperability. Information producers from any number of vendors publish information to a standard MQTT broker. This information is then immediately available and enumerated as tags and User Defined Types (UDT) within Ignition’s internal tag structure. The most impressive feature is that newly connected Sparkplug devices automatically appear without any input from end-users or integrators. In 2019, the Eclipse Foundation, an open-source organization, acquired ownership of the Sparkplug specification. As Ignition allows anyone to evaluate its platform through a free and fully functional trial download, including a free Maker Edition accessible to hobbyists, its popularity continues to grow.
Sparkplug builds the stack from the bottom up, defining information via MQTT to achieve interoperability, while the OPC Foundation specifies publish-subscribe functionality from the top down to achieve scalability. The OPC UA working group began developing standards to extend its existing information definitions through other use cases, such as firewall traversal, controller-to-controller communication, controller-to-cloud communication, or connecting information producers and information users at scale via message brokers. Subsequently, in 2018, the OPC Foundation released Part 14: the Pub/Sub specification, with MQTT becoming the most popular of its four communication protocols, primarily due to the market’s prior familiarity with MQTT in Raspberry Pi applications, home automation projects, or other IoT applications. Furthermore, the UA-IIoT-Starterkit released in May 2021 exclusively supports MQTT, leading to recent OPC webinars primarily discussing OPC UA over MQTT when mentioning Pub/Sub architectures. Figure 3 illustrates the protocol stacks of Sparkplug and OPC UA over MQTT, indicating that the OPC Foundation is only supporting MQTT within the realm of industrial IoT, excluding other protocols.
Figure 3 Protocol Stacks of Sparkplug and OPC UA over MQTT (Source: IEB website)
W3C Developing IoT Standards WoT
Recently, Microsoft’s Chief Architect for Industrial IoT revealed to the media that they are utilizing the WoT TD (Thing Description) as an architectural pattern, with OPC UA as the interface, to create a reference implementation demonstrated in the form of the UA Edge Translator application. This application runs in a Docker container, making it easy to deploy on industrial edge gateways that support Docker or Kubernetes. By extending the UI of the UA Cloud Publisher, configuration of the UA Edge Translator is completed with just a single click. Currently, the UA Edge Translator only handles Modbus devices, but adding other devices is also straightforward. The demonstration provided a sample WoT configuration file for the SIEMENS SENTRON PAC energy meter, which already includes the information required to map the energy meter to the standardized OPC UA PROFI Energy Companion specification. The OPC UA PROFI Energy Companion specification is loaded directly from the UA Cloud Library. This demonstration indicates that WoT is starting to enter the battlefield of industrial IoT data access interoperability.
The World Wide Web Consortium (W3C) has a good track record in delivering globally recognized standards, including HTML and CSS, which built the web. Under its umbrella, the W3C IoT (WoT) working group was established in 2020, tasked with combating the fragmentation of the IoT by building modular specifications to facilitate easy integration of IoT devices and services across IoT platforms and application domains. As a complement and enhancement to existing standards, W3C WoT provides standardized metadata and other reusable technical building blocks, aiming to simplify the development of IoT applications, increase flexibility and interoperability, especially for cross-domain applications; while supporting the reuse of established standards and tools.
Typically, in existing IoT projects, developers face the following challenges: they must understand the heterogeneous technological environment composed of different IoT systems and services from various vendors and manufacturers (see Figure 4). This diversity includes variations in communication protocols, payload data exchange data models, and security requirements. IoT applications are often developed for a narrow and specific use case, making them difficult to scale, maintain, or reuse over their lifecycle.
Figure 4 Heterogeneous Technological Environment Composed of Different IoT Systems and Services (Source: WoT website)
The WoT specification provides a set of standardized technical building blocks, introducing a simple interaction abstraction based on properties, events, and actions. Properties include sensor measurements (read-only), configuration parameters (read/write), states (read-only or write-only), or computed results (read-only), etc.; actions include machine start/stop, fade in/fade out, long-lasting processes (printing files, changing properties over time, etc.), etc.; events include field alarms, doors opened, data flowing, etc. Any IoT network interface can be described with this abstraction (see Figure 5). By using this abstraction, applications can have a common anchor to retrieve metadata of IoT services, understand what data and functionalities of IoT services are accessible, and how to access those data and functionalities. The metadata of IoT devices, including all information necessary to implement this common abstraction, is recorded in what is known as the WoT TD (Thing Description). TD is a core building block in W3C IoT and can be seen as the entry point for IoT instances (much like a website’s index.html). It provides the following information: relevant data and functionality, which protocol is used, how data is encoded and structured, security mechanisms controlling access, and further machine-readable and human-readable metadata. TD is represented in JSON-LD and can be provided by the IoT device itself or hosted in an external repository, such as a TD directory.
Figure 5 Conceptual Diagram of TD (Source: WoT website)
Overall, WoT is a protocol-agnostic approach and provides a common mechanism to define how specific protocols (such as MQTT, HTTP, CoAP, or Modbus) map to the WoT interaction properties-actions-events abstraction (see Figure 6). This mapping and protocol-specific metadata are provided by WoT binding templates. The binding templates for specific protocols guide clients on how to activate each WoT interaction abstraction through the corresponding network-facing protocol interfaces.
Figure 6 WoT Script API Inferred from WoT Thing Description TD (Source: WoT website)
The optional WoT Script API building block defines an ECMAScript (JavaScript) API that can be inferred from the WoT Thing Description specification and supports WoT interaction abstractions. It defines the interface between behavior implementations and the script-based WoT runtime. However, note that WoT implementations are not limited to script environments. APIs in programming languages like Java or C/C++ can also be derived from WoT’s Script API.
Data Access Models Adapted for Industrial IoT Applications
From an application perspective, industrial systems require real-time, synchronized, and collaborative business processing and manufacturing processes, with a crucial foundation being global data sharing rather than mere data exchange. This necessitates a data access model established from the perspective of data access architecture, capable of decoupling data/information users from data/information producers, similar to how the TCP/IP model in the internet decouples data/information access from specific device addresses. A data access model has been proposed (see Figure 7).
Figure 7 Proposed Data Access Model (Source: IEB website)
To decouple data/information users from data/information producers, a crucial prerequisite is to achieve communication connections at the point-to-infrastructure level, rather than point-to-point connections. In a “point-to-point” architecture, the number of connections that information users must initiate is directly related to the number of information producers in the system. The number of information producers also dictates the number of different protocols and custom syntax parsing functionalities that must be designed on the information user’s side. Therefore, as the number of information producers and the number of implemented protocols increase, the point-to-point model becomes unsustainable.
When collecting information from all factory devices, enterprise systems face challenges from the number of required communication protocols. For applications, the burden of communicating across all devices and with any protocol is overwhelming. Efforts have been made to eliminate this burden by generalizing excessive communication protocols, but once product adoption is involved, it becomes a different matter. Industrial automation manufacturers do not prioritize standardized protocols; they continue to innovate on native fieldbus technologies such as EtherCAT, PROFINET, and EtherNet/IP. Almost all devices continue to support Modbus/TCP for data exchange, with some adding IO-Link. Some devices have evolved to include OPC UA servers, but even industrial automation manufacturers who are members of the OPC Foundation still omit OPC UA servers. Some integrators and end-users are waiting for the latest device specification OPC UA FX, hoping it will lead to greater market adoption. In contrast, others are seriously skeptical about the feasibility of adopting standardized protocols at this level of industrial devices. Given various demands and complexities, adopting the W3C WoT solution is a viable approach.
To this day, we still cannot see a clear pattern of data access interoperability suitable for the global industrial internet and industrial IoT. We hope to accelerate progress in this direction, allowing enterprises to incorporate new data/information producers or data/information users without incurring significant integration costs.
Follow the “Digital Enterprise” video account for frontline industry insights
Enterprise-level BOM Management Methods and Practical Training Course
April 26-27 · Guangzhou
Long press the QR code for details
Or clickRead the original text for quick online registration
