Since Industry 4.0 is the connectivity of industrial operations through the Internet, the means of communication matters a lot. Security and performance were built into proprietary systems of the Industry 3.0 era, but in Industry 4.0 there are no guarantees and these concerns need to be addressed through careful network design.
This article will not be a comprehensive tutorial on data communications, but the intent is to list the technologies that are being discussed and used in Industry 4.0 for connectivity and bring appropriate context to better understand what they are and what they do.
At the field level, which we call Level 0, we have instrumentation. These devices measure process variable such as flow, pressure, temperature, and others that can be used as inputs to a process control system. We also had final control elements, such as valves and motors, that could receive output signals. Beginning in Industry 3.0, we could connect these devices with point to point wiring to transmit an analog electrical signal, which the controller converted into digital form inside the control system.
Of course, in the paper industry we have some special sensors such as basis weight, moisture, and others that have special processing in a QCS. The digital representation of this could be transmitted through a serial link to the DCS (distributed control system) in Industry 3.0.
This analog era progressed into a fuller application of digital technology with smart field devices. These devices could digitize internally and communicate with controllers in a digital format. One of the earliest digital protocols for Level 0 was HART, followed by bus protocols such as Fieldbus and Profibus. Bus protocols allowed a single cable to connect multiple field devices. I remember the first demo of Fieldbus that I saw in which a valve was connected to an orange cable and on the screen the system automatically recognized the device with its manufacturer, model, serial number, and configuration data. Amazing!
With these smart devices and digital Level 0 protocols came configuration (device description) files. These files are used to identify what configuration data is in the device, and to communicate with the device the system has to have the compatible file. Since different devices from different manufacturers could have different configuration, management of these files become challenging. To help, Asset Management Systems were developed to maintain an inventory of devices and configuration files and match them up.
At the same time, standardization of these configuration files was in development. Electronic Device Description Language (EDDL) was developed as a result of this effort, but further work incorporated EDDL into a more comprehensive approach called Field Device Integration (FDI). With FDI we have a common approach for managing smart Level 0 devices for configuration, commissioning, and diagnostics.
At this point we have brought technology up to the present day for Level 0 communications. Today we have all previously mentioned means to connectivity still in operation. There are lots of analog point-to-point connections along with a mix of digital protocols being used with their associated means of maintenance. It should be noted all of this technology applies to Industry 3.0 era systems. None of this technology has anything to do with Internet connectivity, and therefore has nothing to do with IIoT.
When we consider the connectivity between controllers/data acquisition devices/PLCs and the control system above them, we are now at Level 1. Industry 3.0 began with proprietary connections. Along the way, Modbus was developed as a means for devices like PLCs to send data back and forth over a serial link. Modbus is a standard that is still heavily used today, but it requires careful layout of registers and identification of what is going where. It is primarily intended for Boolean and 16-bit integers, so when floating point values are involved there needs to be creative use of the registers and bit packing/unpacking to make it work. I had to develop a floating-point Modbus conversion on a project last year, which shows we still rely heavily on legacy standards.
Along came OPC. This allowed easy connectivity to tags in controllers/data acquisition devices/PLCs by just browsing to them. All you had to do is know the name of the tag or parameter you were looking for and select it, and now you have the data. Easy! The problem was it was originally based on Microsoft DCOM, which provided a widely used security mechanism but could result in a vexing situation when things didn't work. My article "The Myth and Magic of OPC" (http://www.dpas-inc.com/publications.html) describes the frustrations that many had with the original OPC. That lead to the evolution into OPC-UA, which removed the DCOM dependency.
Today, Modbus is still in wide use both in serial and Ethernet forms, but OPC is the way most Level 1 communication works. Again, it should be noted that this connectivity has nothing to do with Internet connectivity. Therefore, Industry 4.0 (and therefore IIoT) are not in the discussion of Level 1 communication.
This brings us to Level 2, at which point we connect our control system to the rest of the facility or higher levels outside of the facility. This is where the edge begins. The Level 3 network could have onsite historians, domain controllers, and file servers and can also have Internet connected (cloud based) connections to corporate resources or vendors. This is where the performance and security that were not a concern in Industry 3.0 are now major issues. I had an experience 2 years ago at a facility that lost view to the process because tags were added to a Level 3 historian that sucked up the bandwidth at Level 2. Careful network design and system administration is a new component of process control in Industry 4.0.
All of this is leadup to the subject of MQTT (Message Queuing Telemetry Transport). Though originally developed in 1999, it is the hottest buzzword in Industry 4.0 Level 2 communication. MQTT is an OSI Application Layer (Layer 7) like HTTP and hence like other web-based protocols requires tagging such as HTML or XML for web pages to represent the data but specifically applicable to use in Industry 4.0. It features a lightweight protocol with report by exception to reduce bandwidth usage. It incorporates security. It also pairs with Sparkplug, which provides context to data. With Sparkplug, a tag defined in a Level 1 device carries all of its configuration data all the way up through Level 3, so you only have to configure in one place. Much like the magical demo of Fieldbus I saw years ago, you can pull up a tag from a remote location and gets its description, ranges, units, and everything else you need without additional configuration. Wow!
This was a long way of describing the Industry 4.0 buzzword of MQTT, but it is difficult to understand without the context of history and the levels of communication below it. MQTT, along with Sparkplug, is a sweet solution to the performance and security concerns of Industry 4.0.
---
More background information on MQTT and Sparkplug can be found at "Sparkplug MQTT Topic & Payload Definition Version 2.1" Cirrus Link Solutions, https://s3.amazonaws.com/cirrus-link-com/Sparkplug+Topic+Namespace+and+State+ManagementV2.1+Apendix++Payload+B+format.pdf, April 2019 and "MQTT Version 3.1.1 Committee Specification" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.pdf
