A comprehensive architecture for an IoRT-aware Business Process outsourcing into Fog and Cloud computing Najla Fattoucha , Imen Ben Lahmarb and Khouloud Boukadia a University of Sfax, Mir@cl Laboratory, Sfax, Tunisia b University of Sfax, ReDCAD Laboratory, Sfax, Tunisia Abstract The Internet of Robotic Things (IoRT) is an aggregation of the Internet of Things (IoT) and robotic technologies. Thanks to its benefits, IoRT technology has seen significant growth, and it has swept various fields such as Business Process (BP), where it has given birth to a new business generation known as IoRT-aware Business Process (IoRT-aware BP). These processes necessitate costly execution infrastructures, which encourage their outsourcing. Business Process Outsourcing (BPO) is among the most common and appealing business strategies that aim to reduce enterprise operating costs. In this setting, the business managers seek to outsource their IoRT-aware BPs to the Fog and Cloud paradigms. Enterprises can avail of Fog and Cloud at their infrastructures and services during the execution of their process. Nonetheless, outsourcing an IoRT-aware BP to the Fog and Cloud is not a trivial task due to the diversity of the tasks requirements, the capacities of Fog/ Cloud devices, and the outsourcing techniques. In addition, most of the existing works are limited to outsourcing of classical BPs based on the Virtual Machine (VM) execution despite the proliferation of container technique that empowers the Fog/ Cloud computing through an horizontal scalability. Therefore, we aim through this paper to propose an architecture for optimal outsourcing of an IoRT-aware BP into the Fog and Cloud paradigms. Our architecture considers not only the VM execution but also the container one. Furthermore, our proposal aims to respond better to the process requirements by considering the available resources in Fog and Cloud infrastructures. Keywords IoRT-aware BP, Fog computing, Cloud computing, Business Process Outsourcing 1. Introduction In recent years, IoT technology and robotic are gaining more and more attention. Consequently, sev- eral researchers seek to benefit from both by combining them into one technology called Internet of Robotics Things (IoRT). The IoRT is defined as a mixture of IoT and robot technologies that can im- itate the human intervention where an IoT device and robots achieve human tasks [1]. The IoRT has several benefits, which make it among the proliferated technologies. The ability to bridge the gap between the physical and virtual worlds is among the significant IoRT advantages as it facilitates people’s lives. Besides, it is characterized by its ability to automate tasks via an imitation of human intervention. Moreover, the IoRT technology can sweep different fields (e.g., health, education, etc.). In this setting, many business managers are looking to integrate the IoRT technology into their Busi- ness Processes (BPs) to decrease human intervention, gain productivity, and speed up production. In this regard, [2] defines this incorporation as a merger of the IoRT within the classic process to add Tunisian Algerian Conference on Applied Computing (TACC 2021), December 18–20, 2021, Tabarka, Tunisia $ fattouchnajla@gmail.com (N. Fattouch); imen.benlahmar@isims.usf.tn (I.B. Lahmar); khouloud.boukadi@fsegs.usf.tn (K. Boukadi)  © 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) dimension to a complicated situation. Besides, [3] defines the incorporation as an enterprise digiti- zation via the automation of its process tasks. We get inspired by these definitions to propose the IoRT-aware BP notation to designate integration of the IoT and robots concepts within the traditional BPs. The IoT allows the connection of anything with the internet and provides sensing and actuating methods. However, a robot may represent either a machine that can move and execute tasks gener- ally accomplished by users in a manual manner [4] or a software program (Bot) that can perform a script code [5]. In general, an IoRT-aware BP may necessitate costly execution infrastructures due to the high amount of data to be transferred in network. Towards this issue it is possible to reduce the enterprise operating costs by outsourcing partially or totally to an external provider [6]. This is called a Business Process Outsourcing (BPO). The major benefit of outsourcing is to allow enterprises to get rid of the burden of the whole process’s execution. Thus, they will concentrate on the core process rather than all process parts. Moreover, outsourcing guarantees that a task is accomplished faster and with a better quality thanks to rid the burden of human errors. As well as, it reduces the enterprise’s costs (e.g., operational cost, recruitment cost, etc.). In literature, BPs are usually outsourced to the Cloud infrastructure due to the high availability and capacities of its datacenters [7]. Recently, a new trend came up based on outsourcing to Fog computing [8]. Fog computing is defined as an extension of the Cloud paradigm on its core to the edge of the network [9]. Thus, a Fog infrastructure provide an effective and in- creased assistance through a shift to the edge, or near devices of some Cloud-based applications [10]. Therefore, several researchers seek to avail from Fog and Cloud infrastructures on outsourcing their business process. Our extensive literature exercise revealed that most of the current works deal with the outsourcing of traditional BPs. In [11], authors proposed an architecture to execute a BPs model including IoT and robot concepts on Fog and Cloud computing. However, the authors consider a robot as an IoT device. Nonetheless, a robot as a machine is quite different from a classical IoT device as it can move and execute tasks generally accomplished by users in a manual manner [4], while, the IoT devices (e.g., smartphones, smartwatches, etc.) need human intervention to achieve their movement. Moreover, most of these works are limited to the classic outsourcing solution based on virtual machine (VM) execution. A VM is defined as a computer file that behaves like a real machine computer. However, running a VM into a Fog/ Cloud infrastructure is often expensive rather than a container solution which represents a promising method. Besides, it is hard to manage a VM compared to a container [12]. In addition, most of the existing outsourcing approaches fail to consider the tasks requirements execution. Therefore, this paper deals with outsourcing an IoRT-aware BP on Fog and Cloud computing via a suggestion of an architecture seeking to find optimal outsourcing of an IoRT-aware BP model into Fog and Cloud paradigms. Towards this objective, it considers the resource requirements for each process task. Besides, the proposed architecture attempts to deploy processes by using the virtualization method as well as containers that respond better to the limited capacities of Fog devices. The remainder of this paper is organized as follows: Section 2, depicts the works that deal with the outsourcing of the traditional BP, the BP that incorporates the IoT, and the IoRT-aware BP. Section 3, details our proposed approach. Finally, Section 4 concludes the paper with an overview of our future directions. 2. Related work Several works have considered the outsourcing of a BP into Fog and Cloud computing. In what fol- lows, we overview the recent works that deal with the outsourcing of the traditional BP, the BP that integrates the IoT technology known as an IoT-aware BP and the IoRT-aware BP. However, most of these works concentrate on the outsourcing of the traditional BPs into Fog and Cloud computing. In [13, 14], the authors target the outsourcing of a traditional BP into Cloud in- frastructure based on containers. Towards this objective, they propose an architecture for an optimal deployment of the BPs. The suggested architecture is composed by three main components BP Simu- lator, BP optimizer, and VM Scheduler. However, the authors are limited to the Cloud infrastructures to outsource the process tasks without taking into account the Fog paradigm despite its relevance. In addition, their proposal does not consider the requirements of the process tasks during its execution. Another initiative, in [15], the authors propose an approach that helps the BP designers to find an optimal planning for the execution of the BP on the Cloud. In this regard, the authors propose an extension of the CloudSim which is a Cloud simulator to simulate the Cloud resources to deploy a BP model. However, their approach is limited to the outsourcing to the Cloud computing while the Fog computing represents an attractive paradigm that suit better the latency-sensitive applications. Furthermore, their proposal is limited to the classic outsourcing based on the VMs execution. Among the recent works that deal with the outsourcing of an IoT-aware BP into Fog and/ or Cloud paradigms, we cite [16]. Their proposed architecture supports the distributed communication and the real-time stream in the intention to handle and enhance the IoT data. However, this architecture does not provide an optimal resource allocation solution. Another initiative presented in [17] where the authors propose a framework, named FogBusto to facilitate the end-to-end integration of the IoT on the Fog edge/ Cloud. This framework offers an independent platform to assume the execution and the interaction between IoT applications. It is composed of three main layers: IoT Devices, Fog infras- tructure and Cloud infrastructure. Nonetheless, the proposed framework is limited to the outsourcing of the applications that integrates the IoT devices. Besides, the authors in [18, 19] propose, firstly, an orchestration algorithm based on the decision tree for the offloading of the IoT tasks on the Fog/ Cloud resources. Secondly, they propose an architecture to accomplish the synchronization between the IoT devices and the containers as a deployed application. Nonetheless, these proposals target the outsourcing of applications that incorporate the IoT devices without considering their BPs. Back to the literature, few of the existed works have proposed solutions to execute a BP that incor- porates the IoT and the robot concepts. Among these works, we cite [2] that designs and develops a global architecture to recognize robot actions that are integrated into the traditional process during a rescue attempt in real time. In this regard, the authors are using, on the one hand, a BPMN ad-hoc process model, and, on the other hand, a rescue robot out fitted with IoT sensors. The proposed ar- chitecture can be enhanced through the integration of some outsourcing methods to the Fog or Cloud computing. In addition, in [11] authors proposed an architecture to execute a BPs model including IoT and robot concepts on Fog and Cloud computing. However, the authors consider a robot as an IoT device. Nonetheless, a robot as a machine is quite different from a classical IoT device as it can move and execute tasks generally accomplished by users in a manual manner. 3. Outsourcing Architecture of an IoRT-aware Business Process In this section, we present our proposed architecture for executing an IoRT-aware BP model on both Fog and Cloud paradigms. The goal is to suggest an effective matching of an IoRT-aware BP activ- Figure 1: Overview architecture for an IoRT-aware BP outsourcing on Fog and Cloud. ities with the available Fog/ Cloud resources. Nonetheless, this matching is not a trivial task due to the diverse requirements of the IoRT-aware BP tasks and each Fog/ Cloud resource’s specificities. Therefore, we propose in this paper an architecture for an optimal outsourcing of the process tasks on the Fog/ Cloud computing. As shown in Figure 1, our architecture consists of four layers, namely Customer layer, Mapping layer, Fog layer and Cloud layer. In what follows, we detail the different architecture layers. 3.1. Customer layer The entry point of the suggested architecture, is the customer request for outsourcing its IoRT-aware BP. This request includes: 1. A BP model is made of activities linked by workflow patterns like AND, XOR, etc. The process is modeled in BPMN, the de facto standard for BPs. We used the ISO/IEC 20924: 2018 [20] standard to specify the IoT concepts. To identify robot concepts, we relied on ISO/DIS 8373 : 2020, a pioneer in robotics standards [4]. 2. The specificity and the QoS requirements for each process activity. The specificity presents the activity characteristics such as its complexity, repetitiveness, activity type, and so forth. The QoS requirements denote the resource requirements in terms of CPU, memory, bandwidth, etc. 3.2. Mapping layer The Mapping layer represents the core layer of the proposed architecture. It is composed of a set of steps targeting the optimal process outsourcing. These steps are presented in what follows. 3.2.1. IoRT-aware BP fragmentation This step allows the fragmentation of an IoRT-aware BP to a set of Single-Entry Single-Exit (SESE) blocks that are identified via a well known decomposition technique called Refined Process Structure Tree (RPST). The RPST decomposes a process to a set of blocks called SESE that have a single input and a single output. According to [21], an SESE is a sub-process that has one input and output and should preserve as much as possible the workflows between process and the sub process tasks. We assume in our approach that an SESE is supported by a VM where its tasks are supported by some containers. In our architecture, we considered the set of sub-process activities blocks of three types: 1. Traditional bloc is a bloc that contains traditional tasks used in the IoRT-aware BP process. 2. IoT bloc is a bloc that contains sensing and acted tasks. 3. Script bloc is a bloc that contains script tasks. During the specification of the used blocks, we are limited to the above ones. The robot machines are exempted from the outsourcing as they will remain within the enterprises. 3.2.2. Fragment requirements identification In the previous step, the BP model is fragmented into a set of SESE blocks. Then, there is a crucial need to estimate the cost for executing these SESE either on Fog or on Cloud infrastructure. The SESE requirements should be identified based on the requirements of its related tasks. These requirements may include required CPU, memory, and bandwidth, etc. 3.2.3. Execution environment decision The propounded architecture targets the Fog/ Cloud paradigms where the SESE blocks of an IoRT- aware BP model will be executed. Indeed, among the significant challenges of this step is identifying which environment will support the execution of a SESE bloc. To address this challenge, we define a set of criteria that seems relevant for determining the execution environment of a SESE bloc. Hence, for each SESE, we consider the following criteria: 1. Frequence refers to the number of occurrences of sending data, from a task to the Fog and the Cloud devices, per unit of time. The SESE frequency refers to the higher task frequency among the SESE task’s frequency. This criteria allows to know how many times the task sending data happens within a certain time period. 2. Complexity refers to the complexity of the set of tasks (T) that constitutes a SESE bloc. In the literature, there are several methods to estimate the process complexity value. The com- plexity estimation method cited in [22] is among the most used and attractive method. Hence, we are based on [22] to assess the complexity of a SESE. This method entails adding 10 points to the complexity score for each used application in the process/sub-process. Besides, it awards 2 point for each used screen in the process/sub-process. Finally, the method adds 2 points to the complexity score for each used condition. The authors assume that the complexity is cate- gorized as a Low Complexity if its value is less than 30, as a Medium Complexity if its value is between 30 to 60 else the complexity is classified as a high Complexity. Based on the previously detailed complexity, we designate the SESE complexity by comp_S (see equation 1): 𝐶𝑜𝑚𝑝𝑆 = [∑[(𝑢𝑠𝑒𝑑_𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 ∗ 10) + (𝑢𝑠𝑒𝑑_𝑠𝑐𝑟𝑒𝑒𝑛 ∗ 2) + (𝑢𝑠𝑒𝑑_𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛 ∗ 2)]]/𝑇 (1) 3. Data_Volume presents the amount of data that the SESE tasks produce and transfer to Fog or Cloud. It equals to the sum of the amount of data of the SESE tasks. In our architecture, we assume that if the Data_Volume is huge, it will be sent to a Cloud paradigm rather than to a Fog one where the Cloud computing has a high capability to handle an amount volume of data regarding Fog computing. 4. Repetitiveness presents the number of times of a task execution. The repetitiveness of a SESE refers to the maximum number of repetitions of the tasks that constitute the SESE. We assume that whether SESE has a high repetitiveness value, it’s recommended to be executed on a near devices (Fog) else it executes to a Cloud. Given the variety of decision criteria and decision alternatives, a Multi-Criteria Decision Making (MCDM) technique is required to decide the execution environment of the SESE. An MCMD technique provides meaningful decision-making for selecting the best alternative via a combination of multi- ple and different criteria. In the literature, there are several MCDM techniques such as SAW, AHP, MAUT, etc. In general, each decision-making technique follows three main steps. It starts with the specification of the relevant criteria. Then, it must attach a numerical value to the specified criteria to measure its relevance regarding the other criteria. Finally, it determines the ranking of each criterion [23]. In our work, we opted for using a fuzzy MCDM technique named fuzzy logic to manage the fuzzy nature of the proposed decision criteria like Data_Volume and Repetitiveness. According to [24], the fuzzy logic approach has three main phases which are fuzzification, inference, and defuzzification. The Fuzzification phase converts the value of each input variable to a fuzzy value via a membership function. In the inference phase, a set of fuzzy rules is defined in natural language where these rules define the output value based on the input values. Finally, in the defuzzification phase, converts the output resulting value into a crisp values. In the literature, there are many defuzzification strategies, such as center of gravity (widely used), maximum, and the center average. 3.2.4. Execution optimization After selecting the execution environment for each SESE, we aim in this step to propose an optimal resource allocation for an IoRT-aware BP on Fog and Cloud paradigms using both VM and container technologies. For this purpose, we rely on the Particle Swarm Optimization (PSO) as a meta-heuristic algorithm used in resolving the optimisation problems. PSO was introduced by Kennedy and Eberhart in 1995 [25]. It was inspired from animals behaviors such as flock of bords seeking a food source. The PSO knew an increased use thanks to its advantages such as its simplicity, robustness, and effective- ness. [26]. Moreover, the PSO necessitates less computational effort compared to other meta-heuristic algorithms such as the genetic algorithm. The PSO’s principal idea is to look for an optimal solution by sharing information amongst members of a group generally called population. The population is initialized by a set of solutions generally called Particle (P) that are initialized randomly. It is crucial to denote, that we assume in our proposed architecture to fix the number of both process tasks and Fog/ Cloud devices to form the initial population. In the future work, we aim to deal with scalability of process tasks Fog devices. Each particle, has two main parameters that are the position noted by 𝑥 which is presented in equation 1 and the velocity noted by 𝑣 as it presented in equation 2. Among the main PSO parameters, we note the 𝑝𝑏𝑒𝑠𝑡 that refers to the best position of a particle (Pi), while the best position of the whole population noted by 𝑔𝑏𝑒𝑠𝑡. Besides, during the applying of a PSO algorithm, the fitness function of a particle is specified ac- cording to the studied problem. 𝑥𝑖𝑘+1 = 𝑥𝑖𝑘 + 𝑣𝑖𝑘+1 (2) Figure 2: PSO particle structure for an IoRT-aware BP outsourcing. 𝑣𝑖𝑘+1 = 𝑤𝑣𝑖𝑘 + 𝑐1 𝑟1 (𝑝𝑏𝑒𝑠𝑡𝑖 − 𝑥𝑖𝑘 ) + 𝑐2 𝑟2 (𝑔𝑏𝑒𝑠𝑡𝑖 − 𝑥𝑖𝑘 ) (3) Where, 𝑐1, 𝑐2 present the acceleration coefficients. The 𝑟1 and 𝑟2 are two random numbers within [0, 1]. 𝑊 presents the inertia weight. Finally, 𝑥𝑖 (𝐾 ) and 𝑥𝑖 (𝐾 + 1) denote the current position of a particle 𝑖 at the iteration 𝑘 and 𝑘 + 1. For the optimal allocation of Fog and Cloud resources for executing an IoRT-aware BP, we suggest presenting a particle as a set of SESE bloc tasks, the Fog/ Cloud resource used for each SESE bloc tasks, and the VM used for each SESE. Let’s consider as an example a SESE bloc with three tasks where the first task (T1) is allocated to container 2, the second task (T2) is allocated to container 3, and the third one (T3) to container 1. VM1 supports all these containers. Figure 2 depicts the particle structure for this example. The particle structure presented via a matrix of three lines and the number of columns is as much as the number of the SESE tasks. The first line presents the SESE tasks, the second gives the container identifier used for each task, and the last one determines the VM identifier that supports the SESE. 3.3. Cloud layer The Cloud layer presents the layer that has a vast computing and storage capacities. In our archi- tecture, we interest to the Cloud VMs as well as its containers. Both of them have a set of resources that should fit with the SESE requirements (e.g., CPU, memory, Bandwidth, etc). To respond better to these requirements, we assume that a VM will be used for the execution of SESE blocs, while the SESE tasks are executed by the containers. 3.4. Fog layer The Fog layer is an intermediate layer between customer and Cloud layers. It is constituted by a set of computing nodes such as the smartphone, tablet, etc. These nodes are characterized by their ability to communicate with each other. In our architecture, we assume that each used computing node can support one or more VM. Moreover, each used VM is characterized by its QoS requirements such as the CPU value, the consumed memory, and the needed bandwidth. Furthermore, we assume that each used VM can be a support for one or more containers. The computing nodes of the Fog layer can communicate with the Cloud layer to assure persistent storage of their massive data. 4. Conclusion An IoRT-aware BP merges the IoRT technology within the traditional process. The process has sev- eral advantages, such as assuming the Machine-to-Machine (M2M) communication between devices without human intervention. An IoRT-aware BP may be executed locally or outsourced partially or totally to an external provider known as Business Process Outsourcing (BPO). Therefore, the business managers seek to benefit from the BPO strategy to reduce their processes costs. Besides, the BPO al- lows enterprises to get rid of the burden of executing the whole process. Thus, they will concentrate on the core process rather than all process parts. Nonetheless, outsourcing an IoRT-aware BP should carry about the diversity of resources and requirements of each process task. Towards these issues, we propose in this paper an architecture for the outsourcing of an IoRT-aware BP into Fog and Cloud infrastructures. We aim to profit from both virtualization and creation of containers methods during the execution of the process tasks on Fog and Cloud paradigms during our proposal. As a future endeavor, we aim to apply our architecture in a real case where we aim to use a real Fog and Cloud resources on which we execute the IoRT-aware BP tasks. In addition, the resource alloca- tion based on machine learning is among the attractive area for us to assume an optimal outsourcing of an IoRT-aware BP. References [1] S. N. Krishna, A. Vijayalakshmi, Internet of robotic things: An analysis, IUP Journal of Computer Sciences 15 (2021) 7–11. [2] A. Rebmann, J. Rehse, M. Pinter, M. Schnaubelt, K. Daun, P. Fettke, Iot-based activity recog- nition for process assistance in human-robot disaster response, in: D. Fahland, C. Ghidini, J. Becker, M. Dumas (Eds.), Business Process Management Forum - BPM Forum 2020, Seville, Spain, September 13-18, 2020, Proceedings, volume 392 of Lecture Notes in Business Information Processing, Springer, 2020, pp. 71–87. [3] Y. Masuda, A. Zimmermann, S. Shirasaka, O. Nakamura, Internet of robotic things with digital platforms: Digitization of robotics enterprise, in: Human Centred Intelligent Systems, Springer, 2021, pp. 381–391. [4] T. Haidegger, M. E. Barreto, P. J. S. Gonçalves, M. K. Habib, S. K. V. Ragavan, H. Li, A. Vaccarella, R. Perrone, E. Prestes, Applied ontologies and standards for service robots, Robotics Auton. Syst. 61 (2013) 1215–1223. URL: https://doi.org/10.1016/j.robot.2013.05.008. doi:10.1016/j.robot. 2013.05.008. [5] A. Egger, A. H. ter Hofstede, W. Kratsch, S. J. Leemans, M. Röglinger, M. T. Wynn, Bot log mining: Using logs from robotic process automation for process mining, in: International Conference on Conceptual Modeling, Springer, 2020, pp. 51–61. [6] L. Fadila, Z. Karim, B. Djamel, Modelling business processes for outsourcing into the fog and cloud computing, in: Proceedings of the 8th International Symposium on Data-driven Process Discovery and Analysis (SIMPDA), 2018, pp. 18–31. [7] N. Y. Chong, H. Bakht, An analysis of threats and challenges in the deployment of cloud com- puting, International Journal of Computing and Network Technology 6 (2018). [8] D. Battulga, D. Miorandi, C. Tedeschi, Speck: Composition of stream processing applications over fog environments, in: M. Matos, F. Greve (Eds.), Distributed Applications and Interoper- able Systems - 21st IFIP WG 6.1 International Conference, DAIS 2021, Held as Part of the 16th International Federated Conference on Distributed Computing Techniques, DisCoTec 2021, Val- letta, Malta, June 14-18, 2021, Proceedings, volume 12718 of Lecture Notes in Computer Science, Springer, 2021, pp. 38–54. [9] C. Mouradian, D. Naboulsi, S. Yangui, R. H. Glitho, M. J. Morrow, P. A. Polakos, A comprehen- sive survey on fog computing: State-of-the-art and research challenges, IEEE Commun. Surv. Tutorials 20 (2018) 416–464. URL: https://doi.org/10.1109/COMST.2017.2771153. doi:10.1109/ COMST.2017.2771153. [10] S. S. Gill, R. C. Arya, G. S. Wander, R. Buyya, Fog-based smart healthcare as a big data and cloud service for heart patients using iot, in: International Conference on Intelligent Data Communi- cation Technologies and Internet of Things, Springer, 2018, pp. 1376–1383. [11] O. Bibani, S. Yangui, R. H. Glitho, W. Gaaloul, N. B. Hadj-Alouane, M. J. Morrow, P. A. Polakos, A demo of a paas for iot applications provisioning in hybrid cloud/fog environment, in: IEEE International Symposium on Local and Metropolitan Area Networks, LANMAN 2016, Rome, Italy, June 13-15, 2016, IEEE, 2016, pp. 1–2. [12] A. M. Potdar, D. Narayan, S. Kengond, M. M. Mulla, Performance evaluation of docker container and virtual machine, Procedia Computer Science 171 (2020) 1419–1428. [13] K. Boukadi, R. Grati, M. Rekik, H. B. Abdallah, From vm to container: A linear program for outsourcing a business process to cloud containers, in: OTM Confederated International Con- ferences" On the Move to Meaningful Internet Systems", Springer, 2017, pp. 488–504. [14] K. Boukadi, R. Grati, M. Rekik, H. Ben-Abdallah, Business process outsourcing to cloud contain- ers: How to find the optimal deployment?, Future Gener. Comput. Syst. 97 (2019) 397–408. URL: https://doi.org/10.1016/j.future.2019.02.069. doi:10.1016/j.future.2019.02.069. [15] R. Ben Halima, S. Kallel, M. Ahmed Nacer, W. Gaaloul, Optimal business process deployment cost in cloud resources, The Journal of Supercomputing 77 (2021) 1579–1611. [16] A. Kallel, M. Rekik, M. Khemakhem, Iot-fog-cloud based architecture for smart systems: Proto- types of autism and COVID-19 monitoring systems, Softw. Pract. Exp. 51 (2021) 91–116. URL: https://doi.org/10.1002/spe.2924. doi:10.1002/spe.2924. [17] S. Tuli, M. R. Mahmud, S. Tuli, R. Buyya, Fogbus: A blockchain-based lightweight framework for edge and fog computing, J. Syst. Softw. 154 (2019) 22–36. URL: https://doi.org/10.1016/j.jss. 2019.04.050. doi:10.1016/j.jss.2019.04.050. [18] C. Mechalikh, H. Taktak, F. Moussa, A fuzzy decision tree based tasks orchestration algorithm for edge computing environments, in: L. Barolli, F. Amato, F. Moscato, T. Enokido, M. Takizawa (Eds.), Advanced Information Networking and Applications - Proceedings of the 34th Interna- tional Conference on Advanced Information Networking and Applications, AINA-2020, Caserta, Italy, 15-17 April, volume 1151 of Advances in Intelligent Systems and Computing, Springer, 2020, pp. 193–203. [19] C. Mechalikh, H. Taktak, F. Moussa, Towards a scalable and qos-aware load balancing platform for edge computing environments, in: 17th International Conference on High Performance Computing & Simulation, HPCS 2019, Dublin, Ireland, July 15-19, 2019, IEEE, 2019, pp. 684–691. [20] ISO, Information technology — internet of things (iot) — vocabulary-iso/iec 20924, 2018. [21] J. Munoz-Gama, J. Carmona, W. M. Van Der Aalst, Single-entry single-exit decomposed confor- mance checking, Information Systems 46 (2014) 102–122. [22] D. H. Timbadia, P. J. Shah, S. Sudhanvan, S. Agrawal, Robotic process automation through advance process analysis model, in: 2020 International Conference on Inventive Computation Technologies (ICICT), IEEE, 2020, pp. 953–959. [23] E. Triantaphyllou, Multi-criteria decision making methods, in: Multi-criteria decision making methods: A comparative study, Springer, 2000, pp. 5–21. [24] L. A. Zadeh, Fuzzy sets, in: Fuzzy sets, fuzzy logic, and fuzzy systems: selected papers by Lotfi A Zadeh, 1996, pp. 394–432. [25] J. Kennedy, R. Eberhart, Particle swarm optimization, in: Proceedings of ICNN’95-international conference on neural networks, volume 4, IEEE, 1995, pp. 1942–1948. [26] S. Shabir, R. Singla, A comparative study of genetic algorithm and the particle swarm optimiza- tion, Int. J. Electr. Eng 9 (2016) 215–223.