# Reconfigurable Framework for Data Extraction Using Interoperable Brokers in Manufacturing

Nelson Freitas, Andre Dionisio Rocha, Fábio M-Oliveira, Duarte Alemão, José Barata

► To cite this version:

Nelson Freitas, Andre Dionisio Rocha, Fábio M-Oliveira, Duarte Alemão, José Barata. Reconfigurable Framework for Data Extraction Using Interoperable Brokers in Manufacturing. 14th Doctoral Conference on Computing, Electrical and Industrial Systems (DoCEIS), Jul 2023, Monte Da Caparica, Portugal. pp.122-134, 10.1007/978-3-031-36007-7_9. hal-05473086

HAL Id: hal-05473086

https://inria.hal.science/hal-05473086v1

Submitted on 23 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Reconfigurable Framework for Data Extraction Using Interoperable Brokers in Manufacturing

Nelson Freitas(✉), Andre Dionisio Rocha, Fábio M-Oliveira, Duarte Alemão, and José Barata

School of Science and Technology, UNINOVA – CTS and LASI, Nova University of Lisbon, Campus de Caparica, 2829-516 Monte de Caparica, Portugal

{n.freitas,andre.rocha,fmo,d.alemao,jab}@uninova.pt

**Abstract.** Technology is an integral part of society and has undergone a great deal of evolution in many different areas, like production or recreation, leading to the emergence of heterogeneous systems. These various systems frequently need to communicate and interact with one another to fully utilize their capabilities and resources, aiming to be as efficient as possible. One such method is the message broker, a useful tool for facilitating communication between multiple and heterogeneous systems. However, message brokers often have a complicated initial setup, besides the necessity of accessing several systems to configure parameters and the lack of automation tools to facilitate it. The proposed solution is creating a tool that can be instantiated on different machines and can control the deployment, configuration, and usage of the message broker, regardless of which one. The results are promising, facilitating data collection from industrial robots and the connection between two different message brokers.

**Keywords:** Cyber-Physical System · Data Extraction · Interoperability · Kafka · Message Broker · MQTT · Reconfigurable

## 1 Introduction

In our current day we are surrounded by a multitude of devices that frequently connect to a network, sending several different resources and acting upon the real world through the information received from the network. The fusion of the physical and cyber worlds enables real-time reading and acting upon the physical aspects utilizing the computing and communication power of the cyber aspects. A system capable of using both aspects was given the name of Cyber-Physical Systems (CPS) [1, 2].

However, for some complex infrastructures, a single CPS is insufficient, and a network of CPS is required. This can be true for smart buildings, industry-complex systems, smart cities, among others, where increasingly technological systems are deployed and frequently need to communicate with one another, with CPS being a common example. Being a software-intensive system, the CPS presents dynamic properties that can bring new challenges or exacerbate already existing ones, such as security, safety, and reliability [3].
A common method of communication between several heterogeneous software, that are often present in CPS, are the message brokers. as they provide fundamental char- acteristics, such as scalability, easy communication between heterogenous devices, and availability, just to name a few [4]. However, different message brokers often have dif- ferent characteristics, and some are more suited for certain tasks than others (such as latency, maximum size of message allowed, security protocols, or built-in gateways) [5, 6].

As such the question arrives: “How to create an environment capable of deploying and reconfiguring message brokers for data extraction in an Industrial environment?”.

The hypotheses for answering the research question arises as: “Creating a framework capable of automatically and remotely deploy, connect and reconfigure different message brokers for data extraction in Industrial environments”.

The proposed solution, therefore, creates a framework capable of handling the con- cerns of the CPS through the deployment, reconfiguration, and connection of any kind of message broker capable of communicating with the tools. For the implementation of the framework, a Java programming tool comprised of clients and a server, where the clients are deployed on the same machine as the message broker and the master can be deployed on any computer as long as the communication between the master and the clients exists.

The paper is, therefore, divided in: chapter two where the related work is introduced, focused on the communication of CPS. Chapter three where the framework is presented. Chapter four where the tool developed is explained as well as the demonstration case studies. The results are presented and discussed in chapter five. Finally, chapter six contains a conclusion as well as future work.

## 2 Related Work

As the Internet of Things (IoT) grows in popularity, the CPS is the natural follower as it allows the integration of different physical (such as sensing and actuation) and cyber processes (such as processing and communication). In such a case, a method of communication is required so that IoT devices can communicate with cyberspace [7]. As a result, a CPS can be described by a set of characteristics that allow it to operate and abide by its definition. This set of characteristics is composed of [8]:

* **Autonomy** – CPS are capable of learning on their own and adjusting to their sur- roundings, and it is the autonomy of the system that makes this possible. The capacity of the system to recover from failures or to adapt to given conditions are all examples of the autonomy of a given system and, consequently, of CPS.

* **Decentralization** - The CPS should be a self-contained system that works with autonomy and independence from all the other processes.

* **Heterogeneity** – CPS should be able to integrate multiple systems as well as meet standards for communication and information exchange. This may include different devices, such as robots, sensors, actuators, production cells, among others.

* **Integration** – This is a fundamental component of the CPS, as it by definition, allows the integration between the physical and the cyber worlds, expanding the capabilities of both.
* **Interconnection** – CPS is a synthesis of physical and cyber elements linked by wired and wireless networks with the objective of constructing intelligence. This makes the interconnection of these different elements essential to achieve the goal.

* **Interoperability** – Interoperability consists of the connection, operation, and communication between the different devices of the CPS, allowing the exchange of relevant data between all the components.

* **Modularity** – CPS are composed of modules that collaborate to adapt to changes, be they in consumer needs, product specifications, or supply chain issues, among other things.

The CPS can, therefore, be divided into three layers that together provide the characteristics mentioned above. These layers are: the physical layer, the network layer, and the application layer, which ultimately comprise the physical and cyber space. The Fig. 1 shows the architecture of a CPS making division between the cyber and physical space as well as each layer providing some examples of each one.

<figure><img src="image_3.png" /><figcaption>Fig. 1. Architecture of a cyber-physical system. Adapted from [1]</figcaption></figure>

The physical layer is responsible for all the physical infrastructures as well as all the IoT and machinery, such as sensors and actuators. The network layer is responsible for the communication and can have physical elements such as routers and gateways and cyber
elements such as communication protocols and technologies. Lastly, the application layer is where all the intelligent systems, such as scheduling software, databases, and monitoring software are deployed.

To be able to satisfy all the previously mentioned characteristics, a CPS needs to be able to communicate between all their different devices and applications. There are numerous communication methods that can be used for communicating between heterogeneous devices over the Intranet and Internet. This can be done with the ICE (Internet Communication Engine), REST, AMQP, MQTT, JMS, among others [7, 9].

MQTT, as Message Queue Telemetry Transport is a publish-subscribe protocol able to receive and send data between multiple publishers and subscribers. The MQTT protocol, created by IBM, quickly gained popularity as a many-to-many communication tool, and the necessity for quick and distributed communication is an essential component for IoT systems. As a result, systems that heavily rely on IoT can use MQTT as a useful tool for enabling them, either alone or in conjunction with other technologies, making it ideal for numerous CPS that work with IoT devices [10]. However, the usage of this protocol should not be used exclusively for IoT systems as work was made with agents regarding the usage of this technology for communication [11, 12]. The message broker is also, often chosen for communication in fog computing it highlights their communication and load balance characteristics [13, 14] and can also be integrated with other important communication protocols, such Open Platform Communications Unified Architecture (OPC UA) [15]. In [16] the authors also use the MQTT message broker approach to handle the security of the transmitted data, making it resilient to cyberattacks.

A message broker is often a tool chosen to act as a publish-subscribe enabler, utilizing the MQTT protocol, among others. There are numerous message brokers available, each of which is unique and specialized in a specific area [14, 17]. As demonstrated, this approach has been largely used and has many benefits for the current CPS architectures. However, a study of the usage and deployment of several message brokers in the same CPS in order to harvest the best characteristics of each message broker, or even an infrastructure of message brokers that allows the multiple CPS to utilize the best characteristics of each message broker to communicate between several components on a CPS, has yet to be made.

## 3 Proposed Framework

As previously mentioned, different CPS have different characteristics and requisites based on several factors, such as, how many and what type of devices are meant to communicate, number of data extracted and processed, among others. As such, the usage of different message brokers, that have different characteristics, in a given CPS can be the correct decision in order to save resources and make the process modular. With the deployment of several message broker, their configuration, deployment, and reconfiguration become critical factors that can be an arduous job given the different technologies and methods used for each message broker.

The proposed framework focuses on being able to change automatically and remotely, different aspects of the message brokers used to extract data from the physical elements (Fig. 2).
In the proposed framework, three different message brokers are deployed, this can be seen in practice as different work machines in a given CPS, with different characteristics and requirements that need to be complied with. The message brokers are deployed along with a client tool. This client tool is responsible for all the interactions with the message broker regarding different kinds of actions, such as, configuration, deployment, reconfiguration, and termination. All the client tools regarding each CPS should therefore only be accessible by one master tool, which is responsible for giving orders to each client tool to execute each action. This approach can be interpreted as a master tool dictating what should happen for each message broker, while the client tool runs different methods depending on what the master dictates.

The framework can therefore be useful to different degrees, such as load balancing, interconnection or sharing of different information between message brokers, the remote changing of configurations, or even the automatic redeployment of several instances from a unique point.

Finally, it is important to draw attention to the usage of different message brokers in different contexts, which is essential for the correct use of the framework. A simple example can be the usage of low-resource-intensive message brokers, only focused on data extraction on the shop floor (being Broker A and Broker B of Fig. 2), and a message broker with high throughput and scalability (Broker C of Fig. 2). This represents the flexibility of the framework and allows the usage of the best characteristics of each message broker, while the client tool seamlessly interconnects all the message brokers, creating an automatic and continuous flow of data.

<figure><img src="image_4.png" /><figcaption>Fig. 2. Proposed Framework</figcaption></figure>
# 4 Demonstration Scenarios

In this chapter, a master-client tool proposed in the framework is presented, along with two demonstration scenarios. The two demonstration scenarios have different objectives, the first one exemplifies how this connection can and should be done regarding master-client communication and hierarchy, as well as demonstrating in a real-world scenario how all the systems interact. The second demonstration scenario revolves around a deployment and load test of the MQTT Mosquitto software, to accurately see the impact of such a tool on the message broker.

## 4.1 Master-Client Tool

The master-client tool for the demonstration scenario is made in the Java programming language. The principal reasons for choosing such a language are that Java is one of the most popular languages in the world and can run on most operating systems without the need of changing any code, known as “write once, run anywhere”. Both of these reasons allow for the facilitation of the execution of the proposed framework, as the client can be instantiated on almost any machine and the libraries are written in Java, a common programming language.

The tool is made to allow a certain degree of modularity, this means that the user only needs to install the libraries for the specific message broker that they want to communicate with in both the client and the master. This allows for the saving of resources on less capable machines and allows the user to customize the library and the tool. The libraries have five main methods:

* **Start** – Where the desired message broker, referring to the library in question, is deployed with the previous or predefined configurations.

* **Connect** – Used for automatically connecting both equal and different types of message brokers.

* **Config** – Where the configuration of the given message broker should be passed on.

* **Stop** – This method stops all the processes of the given message broker.

* **Restart** – This is a method simply for more convenience where the **Stop** and **Start** methods are combined, for a more straightforward approach.

As previously stated, the tool is made up of a client and a master (Fig. 3). Even though the client has an interface and can run simple commands, this is not necessary, as all actions are made through the master. The master, however, has different and useful tools. It can deploy the message broker, and create topics for each specific one, view all the tool’s deployed message brokers, and connect two different message brokers.

The tool communicates between the master and the client with HTTP Post and Get. The master communicates with the client by the same IP as the message broker meant to be created. It assumes that if a broker is meant to be deployed by the tool, the client is already operational on the target machine.
<figure><img src="image_5.png" /><figcaption>Fig. 3. Client (left) and Master (right) tool.</figcaption></figure>

<figure><img src="image_6.png" /></figure>

## 4.2 Demonstration Scenario: CPS Example

The first demonstration scenario simulates a system where the position of an ABB IRB 120 robot and the energetic consumption of such robot are sent to two different message brokers that are then able to automatically connect and exchange information (Fig. 4). The position of the robot is processed in the Robot Operating System (ROS) and then published on another machine where a Mosquitto message broker is running. In terms of energy consumption, a sensor is linked to a Raspberry Pi, which publishes the data to a Kafka message broker (Fig. 5). The usage of the Kafka message broker is also to demonstrate that powerful event streaming message broker platforms can be used with this approach, providing a robust and complete integration for data collection corresponding to the necessity of each CPS.

<figure><img src="image_7.png" /><figcaption>Fig. 4. Example of the utilization of the framework in a CPS</figcaption></figure>
<figure><img src="image_8.png" /><figcaption>Fig. 5. Hardware used for demonstration. A) ABB IRB 120 Robot. B) Power monitoring Shelly.</figcaption></figure>

<caption>C) Raspberry PI</caption>

It is important to notice that the tool was able to deploy and correctly configure the message brokers so that the other systems can communicate and pass information to the respective brokers. This configuration is all done remotely, with the introduction of the parameters via the graphical interface. The developed system can be further optimized and automated to meet the needs of the user, the company, or the industrial complex. Finally, both the message brokers were connected by the master tool order in the connection tab. This connection allows Mosquitto to send data about the robot's location directly to the Kafka message broker, bypassing the need for any intermediary software.

In summary, the best characteristics of each message broker were made possible: mosquito for data extraction and Kafka for aggregating and storing the information directly in a database. This was also done without any need to know how to deploy and connect the message brokers, as the client/master tool was used.
## 4.3 Demonstration Scenario: Deployment and Load Tests

For the second demonstration, two tests were made. The first test deploys a Mosquitto message broker without using the tool and tries to publish a small message (<1 Kb), when it succeeds, the time is recorded, and the broker is terminated. This test is made fifty times. After these, two more deployments were made using the tool and using the same test methodology, one via wireless network and the second via cable network (Table 1). This test allows to see how much time both approaches (deploying manually and deploying by the tool) take. Keeping in mind that deploying through the tool has a natural increased delay caused by the network connectivity. Nonetheless, these tests are a reasonable indicator to see if the tool can deploy the message broker remotely in a reasonable time frame.

<table><caption>**Table 1.** Deployment test of Mosquitto message broker</caption><thead><tr><td>Type of test</td><td>Max delay(ms)</td><td>Minimum delay(ms)</td><td>Average (ms)</td><td>Standard Deviation (ms)</td><td>Number of Testes</td></tr></thead><tbody><tr><td>Local</td><td>27</td><td>22</td><td>23,94</td><td>1,06</td><td>50</td></tr><tr><td>Tool + wireless</td><td>417</td><td>67</td><td>89,09</td><td>48,35</td><td>50</td></tr><tr><td>Tool + cable</td><td>88</td><td>78</td><td>80,07</td><td>2,49</td><td>50</td></tr></tbody></table>

Despite the increase of the average deploy time by around three-fold in both tests, this can be explained almost entirely by the internet connection of both the sending of the order by the master tool and the publishing of the first message. Comparing the maximum and minimum values, is possible to see how much a connection can affect the time, especially in wireless communication. For comparison, if 5ms are added in the deployment in the local machine for each communication transaction (send the deploy message, receive acknowledge, send publish message, receive acknowledge) it already increases the time by almost two-fold. Regarding this delay, it is still an acceptable time for the deployment of the message broker considering the remote capability. This can also be further justified, considering that this is a task done only when some configuration or problem emerges and not recurrently. Finally, for an easier visualization of the data three graphs of each test were made (Fig. 6).

The second demonstration test was a load capacity test, in which several messages (100,200,300,400 and 500) with reduced size (<1 Kb), were sent to several Mosquitto brokers (1,5,10,25,50 and 100) running on the same machine. The messages were sent at the same time or as close as it was possible. The ratio of message to broker was always one-to-one, but the total number of messages and the total number of brokers vary. Once again, the tests were made wirelessly and by cable (Fig. 7).
In the load test, it is possible to see the great influence that a wireless system has over the average message time. The messages and time of response are small, and as such, the noise of a wireless network has a great influence on the readings, making the graph at the bottom of Fig. 7 have too much delay due to network connectivity to be able to take the load test information. Nevertheless, it serves as a demonstration as to why these systems should run on cable environment instead of a wireless one.

The top graph of Fig. 7 shows an interesting characteristic, the number of message brokers can have less influence on the average time than the quantity of messages, but as we increase the number of brokers, this impact becomes less and less noticeable, as the difference between one broker and five brokers is almost the same as the difference from fifty brokers to a hundred brokers. Is possible to see that for the lower number of brokers (1 to 5) the average time of message grows with the deployment of more brokers and the sending of more messages. On the other hand, from the range of 10 to 50 message brokers, some particularities occur, as the deployment of 10 message brokers has worse impact than the 25 or even 50 message brokers. This can indicate that in some instances, a larger deployment of message brokers does not always correlate to a linear worsening of performance. This is, however, still too early to say as more tests should be conducted.

<figure><img src="image_9.png" /><figcaption>Fig. 6. Load test of Mosquitto message broker, by cable (top) and wireless (bottom)</figcaption></figure>
<figure><img src="image_10.png" /><figcaption>Fig. 7. Deploy tests in a) local without tool, b) with tool remote by wireless, and c) with tool remote by cable.</figcaption></figure>

## 5 Conclusion

The work presented in this paper proposes a framework that facilitates the deployment, configuration, and connection of message brokers in a CPS, focusing particularly on industrial complex environments. The framework allows for the development of tools capable of incorporating tools either from other users or custom-made tools that facilitate all the configurations needed for the correct utilization of a message broker.

Two demonstration scenarios were presented, the first one regarding an exemplar integration in a CPS industrial environment. A tool programmed in Java was made in
order not only to prove the concept but also to serve as a guideline for how to correctly instantiate the tools that would be responsible for all the actions regarding the message brokers. The demonstration also serves as a guide for how to make the program modular so that different libraries with the same standards from different users can be integrated.

The second demonstration scenario shows that despite the slowdown in the deployment of the message broker, this mostly relates to the delays in the network that now play an important role. Despite this, the time that it took still didn't reach a quarter of a second and was deemed acceptable as the time it took to launch the message broker by the tool. In this second demonstration, there were also some load tests that correlated the number of messages and the number of brokers deployed with the time of sending a message. The wireless results of such a study were deemed not useful because the delays in the network overlapped any attempt to interpret such data. Regarding the cable data, it revealed some intriguing results, as the delay caused by broker deployment does not appear to be linear, implying that more brokers deployed have less impact. If this proves true, it can be a useful conclusion for some particular cases, which would benefit from having more brokers given a particular number of messages. Nevertheless, this needs further study, as the test presented does not have enough validation to make a claim, but it is an interesting subject to be studied in future work.

Overall, a framework is presented, capable of extracting the best of each message broker's technologies. However, this approach always has the limitation of utilizing a message broker and consequently the connection of each, which is limited by the advantages and disadvantages of each message broker. The load tests also show that maybe what the authors thought is the best way to use a message broker is not always true. The deployment of several brokers and load balancing between them could be a useful technique although needs further and more intensive testing.

For future work, it is important to test the framework in a real industrial setting and even other environments, as it can be generalized for other use cases. It is important to also make the load and deployment tests with larger messages to see what impact it has and how it differs from the results gathered in this study. Also, to utilize other message brokers, as it can be interesting to see the impact of for example RabbitMQ, HiveMQ or even an event streaming like Kafka.

**Acknowledgments.** The authors acknowledge the Portuguese FCT program UIDB/00066/2020 and UIDP/00066/2020 for providing financial support for this work.

## References

1. Januário, F., Cardoso, A., Gil, P.: A distributed multi-agent framework for resilience enhancement in cyber-physical systems. IEEE Access 7, 31342–31357 (2019). https://doi.org/10.1109/ACCESS.2019.2903629

2. Hoffmann, M.W., et al.: Developing industrial cps: a multi-disciplinary challenge. Sensors 21(6), 1–28 (2021). https://doi.org/10.3390/s21061991

3. Tsigkanos, C., Kehrer, T., Ghezzi, C.: Modeling and verification of evolving cyber-physical spaces. In: Proceedings of the ACM SIGSOFT Symposium on the Foundations of Software Engineering, Association for Computing Machinery, pp. 38–48 (2017). https://doi.org/10.1145/3106237.3106299
4. Nguyen, C.N., Lee, J., Hwang, S., Kim, J.-S.: On the role of message broker middleware for many-task computing on a big-data platform. Clust. Comput. **22**(1), 2527–2540 (2018). https://doi.org/10.1007/s10586-018-2634-9

5. Mishra, B., Kertesz, A.: The use of MQTT in M2M and IoT systems: a survey. IEEE Access **8**, 201071–201086 (2020). https://doi.org/10.1109/ACCESS.2020.3035849

6. Rocha, A.D., Freitas, N., Alemão, D., Guedes, M., Martins, R., Barata, J.: Event-driven interoperable manufacturing ecosystem for energy consumption monitoring. Energies **14**(12), 3620 (2021). https://doi.org/10.3390/en14123620

7. Pivoto, D.G.S., de Almeida, L.F.F., da Rosa Righi, R., Rodrigues, J.J.P.C., Lugli, A.B., Alberti, A.M.: Cyber-physical systems architectures for industrial internet of things applications in Industry 4.0: a literature review. J. Manufact. Syst. **58**, 176–192 (2021). https://doi.org/10.1016/j.jmsy.2020.11.017

8. Tonelli, F., Demartini, M., Pacella, M., Lala, R.: Cyber-physical systems (CPS) in supply chain management: from foundations to practical implementation. Procedia CIRP **99**, 598–603 (2021). https://doi.org/10.1016/j.procir.2021.03.080

9. García-Valls, M., Baldoni, R.: Adaptive middleware design for CPS: considerations on the OS, resource managers, and the network run-time. In: Proceedings of the 14th Workshop on Adaptive and Reflective Middleware, ARM 2015 - Collocated with ACM/IFIP/USENIX Middleware 2015. Association for Computing Machinery, Inc. (2015). https://doi.org/10.1145/2834965.2834968

10. Parto, M., Saldana, C., Kurfess, T.: A novel three-layer IoT architecture for shared, private, scalable, and real-time machine learning from ubiquitous cyber-physical systems. Procedia Manufact. **48**, 959–967 (2020). https://doi.org/10.1016/j.promfg.2020.05.135

11. Gavriluta, C., Boudinet, C., Kupzog, F., Gomez-Exposito, A., Caire, R.: Cyber-physical framework for emulating distributed control systems in smart grids. Int. J. Electr. Power Energy Syst. **114**, 105375 (2020). https://doi.org/10.1016/j.ijepes.2019.06.033

12. Sakurada, L., Barbosa, J., Leitao, P., Alves, G., Borges, A.P., Botelho, P.: Development of agent-based CPS for smart parking systems. In: IECON 2019 - 45th Annual Conference of the IEEE Industrial Electronics Society, pp. 2964–2969. IEEE (2019). https://doi.org/10.1109/IECON.2019.8926653

13. Naeem, R.Z., Bashir, S., Amjad, M.F., Abbas, H., Afzal, H.: Fog computing in internet of things: practical applications and future directions. Peer Peer Netw. Appl. **12**(5), 1236–1262 (2019). https://doi.org/10.1007/s12083-019-00728-0

14. Bagaskara, A.E., Setyorini, S., Wardana, A.A.: Performance analysis of message broker for communication in fog computing. In: 2020 12th International Conference on Information Technology and Electrical Engineering (ICITEE), pp. 98–103. IEEE (2020). https://doi.org/10.1109/ICITEE49829.2020.9271733

15. Hastbacka, D., Kannisto, P., Katkytniemi, A.: Interoperability of OPC UA PubSub with existing message broker integration architectures. In: IECON Proceedings (Industrial Electronics Conference). IEEE Computer Society (2022). https://doi.org/10.1109/IECON49645.2022.9969039

16. Imran, S.A., Akhtar, S.: Safe and secure communication between two cyber-physical systems: a framework for security. In: Kryvinska, N., Poniszewska-Marańda, A. (eds.) Developments in Information & Knowledge Management for Business Applications. SSDC, vol. 376, pp. 541–558. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-76632-0_19

17. Bertrand-Martinez, E., Dias Feio, P., de Brito Nascimento, V., Kon, F., Abelém, A.: Classification and evaluation of IoT brokers: a methodology. Int. J. Netw. Manag. Wiley (2021). https://doi.org/10.1002/nem.2115