This work proposes a flexible method for data communication between a film extrusion system and monitoring devices based on a message protocol called Message Queuing Telemetry Transport (MQTT).
This work aims at building a flexible data communication structure for a polymer processing machine by employing a publisher-subscriber based protocol called Message Queuing Telemetry Transport (MQTT), which is operated over TCP/IP. Even when using conventional equipment, processing data can be measured and recorded by various devices anywhere through an Internet communication. A message-based protocol allows flexible communication that overcomes the shortcomings of the existing server-client protocol. Multiple devices can subscribe to the processing data published by source devices. The proposed method facilitates data communication between multiple publishers and subscribers. This work has implemented a system that publishes data from the equipment and additional sensors to a message broker. The subscribers can monitor and store the process data relayed by the broker. The system has been deployed and run for a film extrusion line to demonstrate the effectiveness.
In the wave of the 4th industrial revolution, the acquisition and monitoring of various processing data have become important tasks1. In particular, improving the manufacturing process using process data and establishing efficient operation plans will be an important goal of all manufacturing facilities2,3. Downtime can be greatly reduced if an alarm can be sent out of the factory or if predictive maintenance can be performed in time4. Recently, many efforts have been made for data analyses in polymer processes5,6. However, it is not easy to conduct these tasks due to the difficulties in acquiring such data from the existing systems7. The hierarchical structure of the control and instrumentation makes the data acquisition and communication difficult.
First of all, it is not possible to obtain data from different machines with different manufacturing dates. It is difficult to realize communication between different machines since this requires interoperability between different fieldbuses in proprietary formats. In this way, communication methods and data formats are kept private. This helps one easily maintain data security but keeps users dependent on the machine builder for the services and future developments. The recent control computers including human-machine interface (HMI) attached to polymer processing machines are mostly Windows-based these days but are loaded with software created in a proprietary development environment. It is possible to use programmable logic controllers (PLCs) from different companies to communicate with the sensors or actuators, but in many cases, the upper supervisory control and data acquisition (SCADA) system is dependent on the control computers8. This practice has caused numerous protocols, fieldbuses, and control systems to compete in the market. Although this complexity has been alleviated little by little over time, many types of fieldbuses and protocols are still in active use.
On the other hand, communication between control devices and SCADA has been standardized by the Open Platform Communications United Architecture (OPCUA)9. Moreover, communication between SCADA and the Manufacturing Execution System (MES) has also been mainly made through OPCUA. In such a tight hierarchical structure, it is not easy to freely extract data for process monitoring and analysis. Usually, data has to be extracted out of the SCADA or MES10. As mentioned earlier, these systems are vendor-specific, and the data formats are rarely open. As a result, the data extraction requires substantial support from the original information technology/operational technology (IT/OT) solution vendors. This can hinder data acquisition for monitoring and analysis.
In a film extrusion line, the control PC is supervised by a SCADA system11. The SCADA system is operated by a computer program that cannot be easily modified. The computer program might be editable, but the editing is quite expensive and time-consuming. To easily monitor and analyze the processing data, the data should be accessible from any location. To monitor the processing data away from the site, the computer program should be capable of streaming the processing data to the Internet12. Moreover, an open free method reduces the expenses for the data acquisition13. This approach allows data analysis to be performed even in small factories that cannot afford to invest in commercial IT solutions14.
In this study, a message protocol based on the publisher-subscriber model is employed. The Message Queuing Telemetry Transport (MQTT) is an open and standard protocol that enables messaging between multiple data providers and consumers15. Here, we propose a system that acquires, transmits, and monitors data using MQTT for existing manufacturing facilities. The system is tested in a film extrusion line to verify the performance. The data from the original controller are transmitted to an edge device via the Modbus protocol. Then, the data is published to the broker. In the meantime, two Raspberry Pis publish the measured temperatures and illuminance to the same broker. Then, any device on the Internet can subscribe to the data, followed by monitoring and recording it as shown in Figure 1. The protocol in this work shows how the whole procedure can be done.
1. Broker installation
NOTE: To monitor and record processing data via the Internet, a computer system that relays the data should be prepared. The system should be accessible from both the publishers and the subscribers as shown in Figure 2. Thus, it needs to have a public IP address that is known prior to any communication. An open MQTT broker called Eclipse Mosquitto is installed on the system13.
2. Main publisher preparation
NOTE: This computer publishes the machine data via MQTT over TCP to the broker. Legacy data should be interpreted and repackaged to be sent out.This can be usually done by RS485 or Ethernet. The connection at the hardware level should be verified depending on the bus type. The extrusion machine sends out the data via Modbus through an Ethernet port.
3. Additional publisher preparation
NOTE: This computer also publishes the machine data via MQTT over TCP to the broker. Sometimes, additional measurement that cannot be done on the main publisher is required. Internet of Things (IoT) devices such as Raspberry Pi and Arduino can take the role. In this work, Raspberry Pi was employed for temperature data and illuminance data. The procedure is similar to protocol section 2.
4. Subscriber's setup
NOTE: Any devices on Internet may receive the processing data via the broker. The data is processed and visualized also by a Python code. In case the development is difficult, available applications such as MQTT Client in Google Play and MQT Tool in the App Store can be employed. Since the implementation of the user interface is quite lengthy, the details are not described here. Also note that existing applications such as MQT Tool in App Store can receive the data.
5. Data logging
NOTE: The processing data can be written in a database while monitoring. In this work, a lab-scale database was chosen. The data are connected onto a Microsoft Access file to easily write and retrieve from a user computer. In addition, a table can be instantly built by a query to analyze data in a spreadsheet such as Microsoft Excel.
6. Deployment
NOTE: If all the devices can be connected to the Internet, the setup is simple. However, to secure the machine side data, the publishers can be in the intranet only. In this case, the broker can be a gateway to the Internet. To be so, the broker should be equipped with two ethernet adaptors, one of which must have a public IP address. After all the items are developed, the codes should be deployed onto each device as shown in Figure 4. The mode of connection, wired or wireless, is not important, but it has to be secured so that each device should be able to access the broker. This means the broker can act as a gateway on the border between the intranet and the Internet for security purposes. Of course, even if all the devices are exposed to the Internet, there is no problem from a communication point of view.
7. Execution
NOTE: To test the whole system, we started the extrusion line and ran all the Python codes and Mosquitto.
It has been found that the data shown in the HMI and measured by the Raspberry Pis were monitored and recorded in the subscribers as shown in Figure 5. As presented in the video, the processing data are logged into the database.
Figure 1: Outline of the data transmission using the MQTT protocol. The broker relays the message from the publishers to the subscribers. The publishers in this diagram are the main publisher and the additional publisher (Raspberry Pi). The main publisher is directly connected to the extrusion machine to receive the data. The number of subscribers is not limited as long as the network capacity allows. The subscribers can republish the data to other subscribers to record it in a database such as Microsoft Access. Please click here to view a larger version of this figure.
Figure 2: Data flow by publication, brokerage, and subscription in a film extrusion line. The processing data is published by the physical systems represented in the upper left box. For the subscriber, a Python code creating a graphic user interface is written based on PyQt5 to display the received data on the screen. Please click here to view a larger version of this figure.
Figure 3: Recording the subscribed data to an MS Access file via ODBC. To establish a connection to Microsoft Access, the ODBC was employed. The Python code using the pyodbc is written for the connection, which allows logging and analysis by transmitting queries generated by users. Please click here to view a larger version of this figure.
Figure 4: Deployment of the whole system. The broker device in building 2 requires two ethernet ports, one to the intranet and the other to the Internet. For security, the publishers are connected to the intranet, while the subscribers are connected to the Internet. The broker requires a public IP address to be accessed outside the campus. As a result, any devices on the Internet can subscribe to the published data. Please click here to view a larger version of this figure.
Figure 5: Running the data monitoring system while operating the film extrusion line. The processing data can be monitored during the extrusion operation (lower right) once the entire system has been deployed. The data shown in the HMI (upper right) are published outside. After the broker has been started, the codes in the publisher and subscriber devices should be executed. Then, the data flows begin as planned in the system. Using the incoming data, the filmed extrusion line can be monitored and displayed (lower left). Please click here to view a larger version of this figure.
Supplementary Data. Please click here to download this File.
By following the protocol presented, the processing data can be monitored and recorded without expensive IT solutions such as the MES. The IoT technologies can make it easier to acquire and deliver data from conventional machines. It has been shown that the message-based protocol, MQTT, successfully serves as a platform for data communication for polymer processing lines. Moreover, additional data can be flexibly measured and transmitted together. The additional publishers employed in this work were the Raspberry Pis. Notably, they can be further protected by housing them in industrial Raspberry Pi enclosures to ensure robust operation under harsh conditions. The subscribers can be any device anywhere with any operating system. The subscriber device can receive only the necessary data by selecting the topic to subscribe. This work has shown that the MQTT together with the IoT devices enables data monitoring for a polymer processing line without great difficulty. Modern industrial communication architectures tend to deviate from pyramid architectures such as the Purdue model, and the proposed method also shows that this trend is justified.
By implementing the software using Python, the code could be reused for various platforms19. Consequently, the devices with different platforms could take part in publishing and subscribing the processing data. Moreover, a lot of coding load could be reduced by importing several prebuilt codes such as PyModbus, pyodbc, paho.mqtt, and PyQT5. Since the development regarding MQTT was simple and straightforward, there was not much difficulty in debugging. However, it took considerable effort to bring the processing data from the legacy controller to the publisher device. If the data format and protocol are not clearly known, the data packet should be analyzed carefully. Also, the cyber security issue should be examined to prevent unwanted data leakage.
A large factory with many machines still might need the conventional MES-based data acquisition, probably using OPCUA communication. In such cases, investment in the IT system can be made without too much risk. However, for small factories with tight budgets, the proposed model is a promising alternative20. Thus, the MES and IoT are expected to coexist and develop for a considerable period of time. In addition to the polymer processes such as injection molding and extrusion, this approach can be applied to any manufacturing processes that require data communication.
The authors have nothing to disclose.
This study was supported by the Research Program funded by the SeoulTech (Seoul National University of Science and Technology).
Edge Device | Adavantech | UNO 420 | Intel Atom E3815 Fanless |
Film Extrusion Machine | EM Korea | Not Available | For production of 450 mm film |
Pydroid | IIEC | Not Available | Android Devices |
Python3 | Python Software Foundataion | Not Available | Windows, Linux |
Raspberry Pi 4 | CanaKit | Not Available | Standard Kit |