Click the above MES Encyclopedia to follow us
e-works encourages original content; for submissions, please refer to the homepage “Original Submission” instructions.
The manufacturing industry seeks integration of automated devices and applications, with the best example being a plug-and-play web browsing experience, completely eliminating the need for manual connection of “things”—it’s plug-and-play. To achieve this ideal state, many experts and practitioners in industrial automation are engaged in this complex challenge. However, after years of effort, anyone involved in smart manufacturing and Industry 4.0 knows that the vast majority of practices remain fragmented and limited to narrow fields, let alone the interoperability of data access across domains.
The author of this article, Peng Yu, graduated from the Department of Thermal Engineering at Tsinghua University, is a professor-level senior engineer, honorary chairman of the PLCopen China organization, honorary executive committee member of the Instrumentation and Devices Committee of the China Automation Society, and a recipient of the State Council Special Allowance. He has long been engaged in the design of industrial production process control systems and the application research of fieldbus and industrial communication in control systems.
In summary, there is currently no institution or organization worldwide that can provide a verified standardized method, and there is no way to select a recognized target technology among the industrial IoT products on the market. In other words, the standardization of this fundamental issue is still a work in progress.
Fortunately, there are many who express dissatisfaction and concern about this situation, and many people and organizations are seeking breakthroughs. Recently, there has been encouraging news that Microsoft’s Chief Architect for Standards, Consortia & Industrial IoT revealed to the ISA professional website that Microsoft, in collaboration with Siemens, has taken the lead in using discoverable data models (such as OPC UA and W3C IoT WoT standards) to simplify and realize the automatic transformation of industrial field device data tags. This reform addresses the most time-consuming and error-prone task in industrial IoT and industrial internet projects: the manual transformation of data tags from industrial devices that lack standardized or discoverable data models into standardized data like OPC UA, thereby paving the way for plug-and-play capabilities for further processing at the edge or in the cloud.
Learning from the Internet
Successful solutions for interoperability already exist, as seen in the familiar web browsing where modems serve as gateways to the internet. After purchasing a PC and bringing it home, the benefits of standardization become immediately apparent. First, plug-and-play personal computers typically come with an Ethernet port. After connecting the PC to the network modem, it obtains an IP address via DHCP (Dynamic Host Configuration Protocol) and discovers its network gateway. It then identifies its Domain Name System (DNS) server and begins accessing a wealth of information from around the globe. All these mechanisms are automatically activated through a gateway; for most users, it is a technology akin to magic. Historical experience shows that this global network is only possible when the market integrates around specific standards. So, as people long for similar magical technologies in the application of Industrial IoT (IIoT), should they also consider what type of standardized solutions and paths might lead to success? We can predict that a network like IIoT, which needs to form globally, is only possible when the market integrates around specific standards; otherwise, it remains an unfulfilled “promise.”
As indicated in Figure 1, among the many services and functions of IIoT (such as historical data access, alarms and notifications, issuing commands and controls, data manipulation, data analysis, and prediction), real-time data access is the most fundamental and is often referred to as remote data acquisition for devices or processes. This type of data is usually classified as time-series data, non-transactional, existing in boolean, numeric, or textual forms. Visualizing or measuring what is happening at the factory level is often the first step in digital transformation. Especially the importance of integrating various devices from different regions into IIoT on a large scale, crossing the chasm of data interoperability becomes increasingly apparent. If we have a standardized solution for the most direct use case of IIoT, which is data access, then the huge challenges posed by industrial IoT to manufacturers will have a successful foundation, and we will not encounter issues that often become roadblocks to some digital transformation plans, leading to their failure due to the inability to access data from the factory site.
Figure 1 Various Functions of Industrial IoT (Source: IEB website)
MQTT and OPC UA
Undefined Interoperability for Data Access
One of the many goals of smart manufacturing utilizing industrial IoT is to incorporate new information producers and/or information users into the enterprise without incurring integration costs. Simplified integration is mainly achieved through implementing some well-known standard products at the communication and information layers, such as OPC UA and MQTT. However, are these two standards sufficient to achieve interoperability for data access?
Currently, MQTT has become the 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 connectivity features. 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, as well as brokered protocols like AMQP and MQTT. The OPC Foundation continues to pursue the goal of interoperability by defining standard object types through supporting specifications, where each specification constructs standard object definitions using core data definitions.
Regarding interoperability for data access, OPC UA and MQTT have not clearly defined 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 information users integrating applications when selecting 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 the Last Will feature. Additional challenges include: Choosing which QoS levels to use, whether the information producer publishes at fixed intervals or only when data changes, etc. Even more daunting for integrators is that MQTT does not define how data is transmitted, so applications from information users must adapt to the encoding schemes, data types, and object definitions chosen by devices. In summary, MQTT only defines the communication protocol layer in the data access model, and the fact that all higher layers are undefined means that selecting MQTT is far from sufficient to meet the goals of interoperability for data access.
OPC UA achieves standardization at every level of the data access model. Although the definitions at each layer are superior to other technologies, the issue lies in the fact that each level of the model contains many choices in its specifications (see Figure 2). Given the plethora of communication protocols, encoding schemes, data types, and object definitions, simply connecting an information user to an information producer via OPC UA does not guarantee interoperability for data access because each application may choose different options on the stack. Integrators must carefully evaluate what options the information producer’s devices have implemented at each layer and ensure they match the capabilities of the information user’s application. Alternatively, integrators will understand the capabilities of the information user’s application and have to limit the range of OPC UA products it can utilize. Thus, it is clear that specifying OPC UA alone is insufficient if the goal is interoperability.
Figure 2 Protocol Stacks of MQTT and OPC UA (Source: IEB website)
OPC UA over MQTT
Opening New Paths
Perhaps the OPC Foundation has begun to realize that while having multiple technical specifications at each level can increase flexibility, the negative impact is that it raises integration costs and complicates promotion. Thus, in February 2022, it was announced that six cloud service providers, including Amazon AWS, Google Cloud, IBM, Microsoft, SAP, and Siemens, support OPC UA over MQTT in some of their current products, while others will include it in their development roadmaps. This announcement marks a significant compatibility between these six major companies and OPC UA over MQTT. More impressively, this announcement signifies the potential for multi-cloud architecture 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 that utilize OPC UA Pub/Sub technology, the OPC Foundation created a market in June 2022, as a publicly accessible webpage allowing filtering based on functionality, transport, application profiles, and many other standards. The problem 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 on the market remains a challenge.
Meanwhile, the OPC Foundation is making efforts to build semantic context data connectivity. The OPC UA FLC (Field Level Communication) initiative aims to create open standard semantic context data connection communication solutions between sensors, actuators, controllers, enterprises, and the cloud, meeting all requirements for industrial automation, factory automation, and process automation. OPC UA FX continues to make rapid progress, modernizing the most fundamental industrial communication and pushing mainstream computing data concepts to the industrial edge. The goals of the OPC UA Field Level Communication (FLC) initiative 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, comprised of industrial, IT, IoT, and cloud organizations, with over 65 joint working groups involved, focusing on defining and implementing standard contexts and semantic data models from industrial field devices (including sensors/actuators) to enterprise and cloud systems.
The globally 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 effective ways to find and utilize OPC models. This simplifies the application engineering for providing trusted sources for semantic data models.
There is also an issue of scalability combined with interoperability. Many applications in the IoT domain utilize MQTT as a lightweight method to publish data to any number of information users. However, while MQTT supports scalability, it does not inherently promote interoperability. On the other hand, the OPC Foundation better understands that integration challenges extend beyond just standardizing the communication layer; thus, 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, with its main value propositions being developed through the information layer. OPC UA has dedicated over 4000 pages to information definitions, while communication definitions occupy less than 300 pages, highlighting this focus.
MQTT/Sparkplug
Also a Solution
To address the lack of information interoperability issues 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 designed to assist with internal integration via MQTT. Within a year, Cirrus Link used this technology to develop various third-party modules for the Ignition platform (a popular SCADA/MES platform) from Inductive Automation. 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 requiring input from the end user or integrator. In 2019, the Eclipse Foundation, an open-source organization, acquired ownership of the Sparkplug specification. Due to Ignition allowing 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 through 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 large-scale connections between information producers and information users via message brokers. Subsequently, in 2018, the OPC Foundation released Part 14: Pub/Sub specification, with MQTT becoming the most popular of its four communication protocols, primarily due to prior market familiarity with MQTT from Raspberry Pi applications, home automation projects, or other IoT applications. Additionally, the UA-IIoT-Starterkit released in May 2021 only supports MQTT, leading to recent OPC webinars primarily discussing OPC UA over MQTT when mentioning Pub/Sub architecture. Figure 3 illustrates the protocol stacks of Sparkplug and OPC UA over MQTT, indicating that the OPC Foundation is currently supporting only MQTT within the realm of industrial IoT, not other protocols.
Figure 3 Protocol Stacks of Sparkplug and OPC UA over MQTT (Source: IEB website)
W3C Developing IoT Standard WoT
Recently, Microsoft’s Chief Architect for Industrial IoT revealed to the media that they are utilizing the WoT’s 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, facilitating deployment on industrial edge gateways that support Docker or Kubernetes. By extending the UI of the UA Cloud Publisher, configuration of the UA Edge Translator can be completed with just one click. Currently, the UA Edge Translator only handles Modbus devices, but adding other devices is also convenient. The demonstration provides a sample WoT configuration file for the SIEMENS SENTRON PAC energy meter, which already contains the information required to map the energy meter to the standardized OPC UA PROFI Energy Companion Specification. The OPC UA PROFI Energy Companion Specification loads directly from the UA Cloud Library. This demonstration indicates that WoT is beginning to enter the arena of data access interoperability for industrial IoT.
The World Wide Web Consortium (W3C) has a good track record in delivering globally recognized standards, including HTML and CSS, which built the web. In 2020, the W3C IoT (WoT) working group was established to combat the fragmentation of IoT by building modular specifications, facilitating 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 integration across IoT platforms and application domains. Their approach follows the well-known and successful web paradigm, providing a set of standardized technical building blocks to help simplify IoT application development, increasing 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 technical 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 throughout their lifecycle.
Figure 4 Heterogeneous Technical Environment Composed of Different IoT Systems and Services (Source: WoT website)
The WoT specifications provide a set of standardized technical building blocks and introduce a simple interaction abstraction based on attributes, events, and actions. Attributes 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/out, long-running processes (printing files, changing attributes over time, etc.), etc.; events include field alarms, doors opened, data flowing, etc. Any IoT network interface can be described using 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 IoT service functionalities are accessible, and how to access these data and service functionalities. The metadata of IoT devices, including all the information required to implement this common abstraction, is recorded in what is known as WoT’s TD (Thing Description). TD is a core building block in W3C IoT, serving as an entry point for IoT instances (similar to a website’s index.html). It provides the following information: relevant data and functionalities, which protocol to use, how the data is encoded and structured, security mechanisms to control 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 external repositories, such as TD directories.
Figure 5 Concept 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 WoT’s interaction attributes-actions-events abstraction (see Figure 6). This mapping and protocol-specific metadata are provided by WoT binding templates. Specific protocol binding templates guide how clients can activate each WoT interaction abstraction through the corresponding network-facing protocol interface.
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 implementation and script-based WoT runtime. However, note that the implementation of WoT is not limited to script environments. Programming language APIs in Java or C/C++ can also be derived from WoT’s script API.
Data Access Model Adapted for Industrial IoT Applications
From an application perspective, industrial systems require real-time, synchronous, and collaborative business processing and manufacturing processes, with the 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 achieves decoupling of data/information access from specific device addresses. Such a data access model has been envisioned (see Figure 7).
Figure 7 Envisioned Data Access Model (Source: IEB website)
To decouple data/information users from data/information producers, an important prerequisite is to achieve communication connections based on infrastructure 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 increases and the number of protocols implemented increases, the point-to-point model becomes unsustainable.
When collecting information from all factory equipment, enterprise systems face challenges related to the number of required communication protocols. For applications, achieving communication across all devices and with any protocol becomes a significant burden. Efforts have been made to eliminate this burden by generalizing the excessive number of communication protocols, but once product adoption is involved, it becomes another matter. Industrial automation manufacturers do not prioritize standard protocols, but continue to innovate on native fieldbus technologies like EtherCAT, PROFINET, and EtherNet/IP. Almost all devices continue to support Modbus/TCP for data exchange, and some have also added 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 awaiting the latest device specification OPC UA FX, hoping it will lead to greater market adoption. In contrast, others seriously doubt whether standardized protocols can be adopted at the level of industrial devices. Considering various demands and complexities, adopting the W3C WoT solution presents a feasible 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, enabling enterprises to incorporate new data/information producers or data/information users with minimal or no integration costs.
