Industry 4.0 is not only innovating and those sectors of industry which were not automized until now. Along with the development of the concept of Industry 4.0 new potential dangers arise which were marginalized or skipped entirely during the analysis regarding automating workstations. Modern factories more often follow the trend of integrating almost every device with the PLC using an open TCP/IP communication protocol. An upside of such solution is its flexibility – using a few previously defined messages exchanged between the PLC and an external device, effective exchange of data regarding the state of a device is achievable, even if the devices are not from the same producer. Additionally, the system allows for error recognition and their processing directly on the PLC, so that the operators can react quickly instead through the SCADA visualization system.
It is also worth mentioning that many SCADA solutions allow direct communication with PLCs using the TCP/IP protocol, which makes integrating the automation systems easier.
At first glance, this solution seems to be perfect for easy and flexible communication with external devices. There is, however, one very serious danger, which is often overlooked in discourse about this type of communication, which is the lack of encryption during the exchange of data between clients in the basic version of the TCP/IP protocol, which is the most commonly used in industry. It’s a very serious threat in the days of developing cybernetic dangers, because data transferred via an unsecured communication protocol can be easily intercepted. This problem is also magnified by the fact that one of the areas of Industry 4.0 is extending remote access to the factory in order to help with maintenance and optimization of the process or downloading data.
The image above illustrates how unsecure TCP/IP traffic is being exchanged. A listening function on the port on which data transmit is active has been activated using WireShark app. The results show that third parties, who have access to such network, can in a very easy way start intercepting the communication and read the data that was being transferred. In realistic conditions, network traffic is directed through a switch, which means that the headers arrive only at the ports to which the end client is connected. Such architecture increases safety, because it makes easy listening in to the communication traffic by third parties impossible. However, for experienced attackers, this is not much of an obstacle, they can use techniques like for example MAC flooding, which overfills the MAC table of the switch with a large number of false MAC addresses, which in effect causes a so-called “fail-open”. In that case, the switch will start directing traffic to all ports, allowing listening in by any network user.
MQTT Protocol (Message Queuing Telemetry Trasport) is an efficient and light communication protocol, which has been designed primarily for devices with limited resources – causing it to be very popular in the environment of Internet of Things). Thanks to low hardware requirements, it allows reliable data exchange, even with a bad network connection.
In order to make the implementation of communications relying on the MQTT protocol, ready-made solutions are widely used and offered by various producers. Choosing an adequate broker depends on the specifications of the project, the scale of the implementation and the requirements regarding costs and available functions.
When it comes to costs, integrators can choose between brokers available both for free for commercial use as well as in a paid subscription model. Commercial solutions usually offer more advanced configuration, better security measures and technical support.
The choice of an adequate broker should be dictated by both technical requirements and the planned cost of implementation and maintenance of the system.
The MQTT protocol relies on a broker running on a device which functions as a “server” for the whole communication between all devices (clients) in the network. In practice, data exchange happens through precisely defined topics. The clients publish messages in chosen topics, and those who subscribe to particular topics automatically get every new message that appears on that channel. That is the “publish-subscribe” model, allowing for easy system scaling and flexibility with adding new devices, without building new dedicated connections between them. Adding a new device requires only connecting with the broker and optionally configuring safety certificates and setting which topics the device is to be subscribed to and in which topics it should publish.
MQTT offers a QoS (Quality of Service) mechanism, which allows for determination of reliability of delivering messages between devices.
QoS level is being set by the sender and applies to all subscribers of a given topic. Choosing the right QoS level depends on the needs of the application – required reliability, speed and available resources.
In order to test MQTT in an industrial environment, we conducted a trial of connecting a PC to a PLC. To do this, Python programming language was used, and it was acting as client no. 1, along with a PLC from the S7-1500 family working as client no. 2. The broker was Mosquitto running in a Docker container.
In order to create a container in the Docker environment, a configurations file in a YAML format needs to be prepared. It will be the basis on which the container is created. In the trails conducted by us, we focused on testing an application with a basic configuration, additionally secured with an SSL certificate.
To easily verify if the docker environment was configured correctly, the MQTTX app was sued, which offers a clear GUI to connect to MQTT brokers. Approperiate certificates, which need to be applied on the client’s side were also generated.
After the broker was turned on in the Docker environment and the client was connected, data exchange and message publishing to topics was possible.
To conduct genuine tests, two additional clients were turned on. On of them has been implemented in the Python programming language suing the Paho library. Python is characterized by an exceptionally easy way to make prototype apps, which is why it was chosen for this task.
A simple app works by creating an MQTT client, which communicates with the broker using port 8883 – a port by default reserved for communication secured with SSL/TLS protocol.
After launch, the client subscribes the topic “Test1” and then opens a new thread, which allows sending messages from the IDE in which the app was created.
The third client was launched on a PLC. For test purposes a PLC was simulated with S7-PLCSIM Advanced V6.0 Upd1 software. To program the PLC, TIA Portal V19 programming environment was used.
To connect with the MQTT broker, an LMQTT_Client function was used, which was prepared by Siemens and shared via Libraries_Comm_Controller library. This function allows for implementation of an MQTT client directly on the PLC, which allows for integration of industrial automation systems with the MQTT protocol.
To establish MQTT communication through port 8883, additional certificates had to be added to the project in TIA Portal. The whole process takes place in the Security settings tab.
The first step is securing the project – a login requirement must be set using a username and a password fulfilling Siemens’ security standards. Only after those security measures have been implemented is it possible to go to the Certificate manager tab, where appropriate certificates can be added.
Next, the Trusted certificates and root certification authorities tab must be opened where certificates and keys necessary to connect to the broker can be imported. Importing correct certificates allows verifying the brokers identity and secure data exchange with MQTT using SSL/TLS.
Next, a certificate, which the device will be using must be set in the PLC settings. To do that, in one of the configuration tabs, a previously imported certificate needs to be chosen, which will be used to authenticate and guarantee safe communication with the MQTT broker. Choosing the right certificate is key to establishing an encrypted connection as well as fulfilling the safety requirements of the project.
In the end, connection settings need to be correctly configured in an appropriate block in the PLC. After configuration, communication with the MQTT broker can be initialized.
After correctly configuring the connection and putting in the right username and password, communication with the system will be established and the messages will be processed.
As can be observed, messages transmitted via encrypted communication cannot be read without the use of appropriate authentication certificates.
MQTT stands out compared to traditional TCP/IP communication primarily due to its simplicity of implementation and flexibility in terms of security. Standard TCP/IP connections do not provide encryption by default, making the transmitted data vulnerable to eavesdropping and unauthorized interference. In practice, this means that adding security measures to traditional network solutions can be complex and time-consuming.
With MQTT, the situation is quite different — the protocol is designed to simplify both the configuration and expansion of communication systems as much as possible. Thanks to native support for encryption (e.g., via TLS), it is very easy to enhance the security of transmissions without the need for complex architectural modifications. Adding encryption in MQTT usually involves only a few simple settings on the broker and client sides.
This ease of deployment, flexibility, and availability of security mechanisms make MQTT an ideal choice for projects requiring quick startup while also being ready for easy adaptation as data protection demands increase.
