Data from Control System to Cloud - Industry 4.0 Communication Protocols
Communication protocols are a key component for an industry 4.0 compliant facility and are used to enable communication back and forth between cloud servers to transmit data or receive instructions.
Industrial Internet of Things (IIoT) and cloud computing are the major building blocks for an industry 4.0 compliant facility. The IIoT devices need to communicate back and forth with cloud servers to transmit data or receive instructions. Various protocols are used to enable this communication. In this article, we will take a look into the three major communication protocols for IIoT communication, namely HTTP, WebSockets, and MQTT.
Figure 1. HTTP is a viable option for devices without modern protocols. Image use courtesy of Canva
HyperText Transfer Protocol (HTTP)
HTTP is the most popular application layer protocol used on the internet. The protocol is asymmetric and stateless, which means communication is not bidirectional and does not depend on previous requests from clients. The client sends a request to the server and the server satisfies the request if it is possible.
For IIoT applications, HTTP RESTful Application Programming Interfaces (APIs) are commonly used for reading, writing, and updating information on cloud servers. An API provides a communication channel between IIoT devices and the cloud computing server. HTTP APIs use HTTP methods to transfer information. The four primary HTTP methods are GET, POST, DELETE, and PUT.
REST stands for REpresentational State Transfer and is a programming architectural pattern for communication between various components over the web or a network. The APIs that adhere to the principles of REST are considered to be RESTful. RESTful APIs are scalable and are suitable for communication between machines.
When IIoT devices are connected to cloud servers with RESTful HTTP APIs, they can communicate with each other. The IIoT device can send data to the server and also receive data from the server using GET requests and PUT requests.
HTTP was designed to enable communication over a network and the design was not intended for IIoT applications. The frequency and data transmission speeds over HTTP are not adequate for large-scale IIoT applications. The energy consumption with HTTP is also quite high which matters when a large number of IIoT devices have to interact with cloud servers. Despite this, HTTP is a viable option when devices with modern protocols are not available. It is also used when IIoT applications are latched onto legacy systems.
Figure 2. Websocket is a full-duplex communication channel that is faster and uses less bandwidth than uni-directional HTTP. Image used courtesy of Canva
WebSocket is a communication protocol that works over a TCP/IP connection between two systems. WebSocket is a full-duplex communication channel, meaning communication can take place in both directions at the same time. Full-duplex communication can be done over a single TCP/IP connection. Multiple connections are not required for full-duplex communication with WebSocket. This makes it more suited for IIoT communication than HTTP, which is uni-directional in nature.
The client and the server in the WebSocket communication initiate a full-duplex channel for communication. The procedure for establishing an open connection between the client and the server is called a handshake. The handshake is done with a HTTP GET request. Once the handshake is complete, the connection between the client and the server always remains open. The connection is terminated only when the client or the server explicitly closes the connection.
WebSocket is a relatively newer communication protocol compared to HTTP and is much less prevalent. The advantages of this technology, however, prompt developers to build a wide range of IIoT applications with WebSocket. Since the channel is always open between the IIoT devices and the cloud server, a large volume of data can be transferred between the systems consuming a lot less energy and bandwidth. This also makes it a more suitable communication protocol for IIoT applications.
Some of the benefits of using WebSocket over HTTP are:
Information transfer over WebSockets is faster than HTTP requests.
WebSockets use way less bandwidth compared to HTTP.
No delay in communication between IIoT and cloud server as full-duplex channel is used for communication.
Firewalls cannot block WebSockets.
WebSockets can evade proxies.
WebSocket is a standard internet technology. No additional equipment or specialized expertise is needed for WebSocket implementation.
WebSocket should not be used on devices that run on batteries. As the full-duplex connection is always open, it will drain batteries quite fast. It is better to use HTTP in such instances as requests are sent only when required.
Figure 3. MQTT is specifically designed for IIoT devices and relies on publish/subscribe topics to enable machine-to-machine communication. Image used courtesy of Canva
Message Queue Telemetry Transport (MQTT)
MQTT is a communication protocol developed specifically for IIoT devices. The protocol was developed by IBM to enable communication between sensors in the oil industry and remote servers using satellites in a cost-effective manner. The protocol used to be a proprietary one, but now it is an open protocol maintained by OASIS.
MQTT is also an application layer protocol like HTTP. Just like HTTP, the MQTT protocol also works on top of the TCP/IP layer. In WebSocket and HTTP, the IIoT devices connect directly with the cloud server locating the URL or IP address of the cloud infrastructure. MQTT relies on a different model of communication.
With MQTT, the IIoT devices need not know the IP address of the cloud server and the server need not know the IP address of the IIoT devices. The communication between the IIoT devices and the server occurs through a mediator called a broker. The broker can either reside on the local network or it could be over the internet. Regardless, all the communication between clients of the protocol passes through this broker.
Instead of methods in HTTP, MQTT uses the concept of publish/subscribe topics. Topics are segmented data that fall under the same category. For example, the temperature data of a system can be one topic and the humidity data can be a different topic. Clients can publish data to a topic, meaning it can add data to a topic. Clients can also subscribe to topics and they will only receive data from that topic. The routing of all the data is handled by the broker. The MQTT protocol has different standards to determine the depth and frequency of data to be published or subscribed.
Advantages of using MQTT over HTTP or WebSocket are:
MQTT is light weight and uses limited resources compared to other protocols.
The MQTT protocol uses less energy to function.
MQTT is also faster than the HTTP protocol.
MQTT supports persistent connections.
MQTT is specifically designed for machine-to-machine communication.
MQTT is data centric when HTTP is document centric. The data centric approach is suitable for industry 4.0 applications, especially machine learning.
Suitable protocol when there are constraints like, energy constraints, processing constraints, memory limitations, high latency, unreliable networks, etc.
Communication is encrypted and secured using TLS, which is the latest cryptographic protocol to ensure communication security.
Getting Data out of a Device Into the Cloud
We now know a lot about the various communication protocols that can be used. The next step is to use one of these protocols to send data from the PLCs and other devices to the cloud network and the other way. Tag databases and other interfaces also need to be set up for this. The devices, network intermediaries, and the communication protocol to be used are determined by a number of factors. The major among these is the capability and accessories for the devices such as PLCs, HMIs, etc. We will discuss more specifics on how to send data from devices to the cloud in the next article.