Abstract
The rapid development of Internet of Things (IoT) attracts growing attention from both industry and academia. IoT seamlessly connects the real world and cyberspace via various business process applications hosted on the IoT devices, especially on smart sensors. Due to the discrete distribution and complex sensing environment, multiple coordination patterns exist in the heterogeneous sensor networks, making modeling and analysis particularly difficult. In addition, massive sensing events need to be routed, forwarded and processed in the distributed execution environment. Therefore, the corresponding sensing event scheduling algorithm is highly desired. In this paper, we propose a novel modeling methodology and optimization algorithm for collaborative business process towards IoT applications. We initially extend the traditional Petri nets with sensing event factor. Then, the formal modeling specification is investigated and the existing coordination patterns, including event unicasting pattern, event broadcasting pattern, and service collaboration pattern, are defined. Next, we propose an optimization algorithm based on Dynamic Priority First Response (DPFR) to solve the problem of sensing event scheduling. Finally, the approach presented in this paper has been validated to be valid and implemented through an actual development system.
1. Introduction
IoT brings together physical sensors which have never been connected before. These sensors are the fundamental building blocks for the creation of smart applications and communicate via device-to-device connections [1, 2]. As we know, the IoT-aware business process applications are event-driven by nature [3]. Therefore, the business processes hosted on the wide-spread geographical distribution sensors should respond to different sensing events gathered in the dynamic IoT environment as fast as they could. The real-time event handling not only makes the cooperation among cross-sensor business processes more efficient, but also makes it possible to invoke corrective processes before emergencies snowball into disasters (e.g., traffic congestion, fire hazard, power emergency, etc) [4]. It is worth mentioning that a typical cross-sensor business process application, especially in large-scale application scenarios, is usually dispersed in different monitoring areas. Due to the discrete distribution of sensors and the complexity of execution environment, they need to collaborate to accomplish specific tasks [5–8]. Therefore, different kinds of coordination patterns exist in the heterogeneous smart sensor networks, which make modeling more difficult. In general, the common coordination patterns in the IoT environment include event unicasting pattern, event broadcasting pattern, and service collaboration pattern.
In order to comprehensively respond to external sensing events, massive data gathered by the smart sensors are routed, forwarded, and processed among IoT-aware business process applications in the heterogeneous sensor networks. However, the available resource, especially the computing resource, is often limited in a particular scene [9–12]. For example, in the modern forest-protection, numerous smart sensors are discretely deployed in multiple monitoring areas. These sensors communicate via sensing events and share the same remote computing resource. These sensing events not only have a huge number, but also have complex data formats, including text, image, and video. Furthermore, different kinds of sensing events are assigned different priorities. But, all of them tend to get response from the IoT system as fast as possible. Thus, it is particularly important to reasonably schedule all kinds of sensing events based on certain principles with limited computing resource.
As a tool to model discrete event systems, Petri nets [13–18] have been widely used to model the business process applications, which have shown great power in dealing with concurrences and conflicts. Therefore, in this paper, the modeling methodology for collaborative business process towards IoT applications is investigated on the basis of Petri nets. Although Petri nets could provide theoretical supports for the modeling and analysis, challenges still remain to be solved. First of all, the business processes towards IoT applications are event-driven by nature. But Petri nets only concern about the control structures, including sequence structure, AND-Split/Join structure, XOR-Split/Join structure, and Loop structure, without taking into account the sensing event factor involved in the process interactions. Thus, we need to extend Petri nets with this factor. Furthermore, due to the discrete distribution and complex sensing environment, multiple coordination patterns exist in the heterogeneous sensor networks. However, to our best knowledge, most of the current work pays little attention to the systematic description and formal definition for coordination patterns in the business process modeling phase. Finally, massive sensing events need to be routed, forwarded, and processed in the resource-constrained IoT environment. All of them tend to be scheduled as fast as possible. Most of the sensing event scheduling algorithms [9, 19, 20, 21] only focus on the technical implementation details, lacking a qualitative and quantitative analysis that combines the specific IoT application scenario.
The main contributions of our work contain the following:(i)We extend the traditional Petri nets with sensing event factor, making it support the direct modeling of collaborative business process towards IoT applications.(ii)The formal modeling specification of IoT sensor tasks is investigated, and its coordination patterns, including event unicasting pattern, event broadcasting pattern, and service collaboration pattern, are defined.(iii)We propose a novel optimization algorithm based on Dynamic Priority First Response (DPFR) to solve the problem of sensing event scheduling.(iv)We qualitatively and quantitatively evaluate our proposed algorithm. In addition, the work presented in this paper has been implemented through an actual system.
The rest of this paper is organized as follows: We discuss the related work in Section 2. Section 3 describes a scenario of collaborative business process towards IoT application in forest-protection. In Section 4, the formal modeling specification of sensor tasks is investigated and its coordination patterns are defined. We propose a novel algorithm to optimize sensing event scheduling and consider both qualitative and quantitative aspects for the performance evaluation in Section 5. Based on our proposed approach, we design a real development system and give the implementation details in Section 6. Concluding remarks are made in Section 7.
2. Related Work
In this section, we mainly compare our proposed approach with other existing approaches. We will clearly point out the similarities and differences with their works.
2.1. Modeling of IoT-Aware Business Processes
Tan et al. [13] proposed an approach for modeling an e-commerce system with a third-party payment platform from the view point of a business process. This approach integrated both data and control flows based on Petri nets. Rationality and transaction consistency were defined and validated to guarantee the transaction properties of an e-commerce business process. van der Aalst [22] considered that business process applications were deployed over a lot of organizations. He addressed two valuable questions in his work. The first was how to decide the minimal requirements for the in-organization business process and the second was how to judge an in-organization business process modeled with Petri nets was consistent based on an interaction structure specified through an event sequence. In [23], Zeng et al. proposed a method extended with message and resource factors to model the cross-department collaborative business process. Based on a cross-department medical diagnosis scenario, different coordination patterns were described and integrated modeling approach was illustrated.
2.2. Optimization Algorithms
Munir et al. [24] proposed an opportunistic, reliable, and realistic QoS mechanism for bulk data transfers in grids, which maximized acceptance rate and network resource utilization by using an event-based priority queue. The metrics that had been studied in the evaluation of elastic scheduling heuristics were the acceptance percentage and the mean flow time of requests. Li et al. [25] proposed a scheduling algorithm of events with uncertain timestamps, which could support effective scheduling of reading events and writing events in CPS. The experiments verified that the scheduling algorithm could guarantee providing correct feedback of the event sequences to CPS. In [20], Aziz et al. proposed a local search heuristic which handled an event selection namely Event Selection based on Soft Constraint Violation (ESSCV) applied in a modified PSO algorithm to solve class scheduling problems. Erbas et al. [21] studied static priority scheduling of recurring real-time tasks. They focused on the nonpreemptive uniprocessor case and obtained schedule-theoretic results for this case.
2.3. Summary of Related Work
The above-mentioned approaches are generally still in their infancies. The work [13] and [22] only focus the discrete business processes without considering coordination patterns among different process tasks. Our approach takes full account of the complexity of IoT sensing environment. We give the formal modeling specification of sensor tasks and define different coordination patterns. The work [23] also extends Petri nets with message and resource factors. But the premise of this extension is not to consider resource conflicts. However, the available computing resource is often limited in a particular scene. Therefore, we propose the corresponding algorithm to optimize sensing event scheduling. Although the studies [20, 21, 24–26] have presented some sensing event scheduling algorithms, most of their approaches are based on software simulation, which lacks theory basic that combines the specific IoT application scenario. Different to them, we initially verify the feasibility and effectiveness of our proposed optimization algorithm at the theoretical level. Then, we consider both qualitative and quantitative aspects for the performance evaluation of the algorithm.
3. Running Example
A large area of forest is widely distributed in North China. The work of forest-protection used to be done by the way of human mountaineering in the past. However, this way not only costs a lot of resources, but also could not deal with emergencies in real-time. Using our proposed approach, numerous smart sensors are discretely deployed in multiple monitoring areas. These sensors are in charge of collecting their surrounding information and sending the corresponding sensing events to gateways regularly. Owing to inconsistency of the raw data, event manager will initially do some basic filtering or aggregation operations. Then, encapsulated events are routed, forwarded, and computed among business process applications hosted on the distributed servers. Finally, valuable information would be submitted to officers for further processing and analyzing. In general, a typical scenario of modern forest-protection usually involves the following sensors: smoke sensor, infrared thermal imaging sensor, tracking camera sensor, light sensor, and sound sensor. Furthermore, the common physical resources include the fire-fighters, fire-engines, and fire-airplanes. Officers would allocate these resources according to the need. Figure 1 illustrates the whole business process application of this case.
In general, this scenario includes the following steps:(1)The smoke sensor collects its surrounding information and regularly sends these raw data to the smart gateway for further filtering, classifying, and aggregating.(2)When the fire emergency occurs in a monitoring area, the smoke sensor will publish a smoke event.(3)Event manager sets the event-priority according to the smoke concentration information.(4)Distributed servers route this processed event and publish the corresponding command event to the infrared thermal imaging sensor, making it detect whether there are moving targets (e.g., explorers, campers, etc.).(5)If the moving targets are detected, the infrared thermal imaging sensor will publish a detected event in time.(6)Distributed servers subscribe this event and publish a command event to the tracking camera sensor.(7)The tracking camera sensor keeps tracking of the targets, transmits the actual information, and requires entity resources to the remote dispatch center.(8)The officer allocates a certain amount of fire-fighters, fire-engines, or fire-airplanes according to the need. Meanwhile, an alarm event is automatically published to the light sensor and sound sensor.(9)Once the light and sound sensor have subscribed the alarm event, they will send light and sound warning to guide the moving targets to escape the hazardous area.
The interaction interface between the discrete business processes is event-based loosely coupled. When emergencies occur, the appropriate business processes could be invoked to handle the corresponding events timely. According to this specific description, we could summarize the following characteristics of these business processes.(1)The whole IoT-aware application involves smoke sensor, infrared thermal imaging sensor, tracking camera sensor, light sensor, and sound sensor. Each sensor has its respective business process and tasks.(2)The execution of this IoT-aware cross-sensor business process application is driven by different kinds of priority-based sensing events. These sensors need to collaborate with each other to complete the rescue.(3)Generally speaking, a smart sensor task is usually composed of sensor name, task item, subscribed event, and published event. Taking this collaborative IoT-aware business process application in the forest-protection scenario as an instance, sensor tasks and their corresponding elements are illustrated in Table 1.
4. Modeling for the Business Processes
To better analyze and optimize the collaborative business process towards IoT applications, we should first have a complete modeling method. In this section, we initially introduce the formal modeling specification for single-sensing sensor node. Then, different kinds of coordination patterns are investigated and formally defined. Finally, we model the above-mentioned forest-protection business process application based on our proposed approach.
4.1. Formal Modeling Specification for Single Sensor Node
In the traditional Petri nets-based business process modeling, a task is usually composed of task name and task attribute. Considering that the business processes usually involve all kinds of sensing events in the dynamic IoT environment, we extend the traditional Petri nets with this factor.
4.1.1. Petri Nets
A Petri net is a model that could be represented by a graph.
Definition 1: is a net if and only(1) is a finite set of places(2) is a finite set of transitions(3) is a finite set of directed arcs(4) and
Definition 2: Let denote any element of a net N. Given , is called the input set or preset of x, and is the output set or postset of x. is called a pure net if it satisfies .
Definition 3: A 4-tuple is a Petri net if and only if(1) is a pure net(2) is a marking function and is the initial marking(3) has the following transition firing rules:(a) is enabled in M, denoted as M if (b)If M , then t may fire in M, and its firing generates a new marking , denoted as M , where
4.1.2. Extended Petri Nets
In the traditional Petri nets-based modeling, the transition T is used to represent the tasks. Considering that the IoT-aware business processes usually involve sensing events, we extend the traditional Petri nets with this factor.
Definition 4: A 5-tuple is an extended Petri net if the following conditions hold.(1)There is one input source and one output source , such that and (2) is on a path from i to o(3) satisfies Equation (1)(4); represents the common places, represents sensing event places(5); represents the common control structure, represents the published or subscribed sensing events(6) is the resource waiting time. , with the arrival time of the first resource-token in the preplaces of transition t as the start time
Compared with the traditional Petri nets, the main differences defined in Definition 4 are as follows:(i)We separate sensing events from the traditional places . Based on this, we could more clearly understand their roles in the whole processes.(ii)We define a variable representing the waiting time for resources. An embedded timer starts counting when the token fires from the source place i.(iii)All resources are in the ready state when they are allocated. In addition, sensing events are generated during the execution phase of business processes.
4.1.3. Modeling for Single Sensor Node
As mentioned above, a sensor task is usually composed of sensor name, task item, subscribed event, and published event. Thus, the specification of a single sensor node is formally defined as follows.
Definition 5: A Sensor task is a four-tuple =, , , . Then, each item of the sensor task is interpreted as follows.(1)Name is the name of a smart sensor task, representing the content of the task(2)Item represents the specific task of a smart sensor to be performed, which is usually an atomic operation(3)SubEvent is the sensing event that is needed to drive the smart sensor node to work(4)PubEvent is the sensing event that is published when the task of a smart sensor node has been finished
Using our extended Petri nets model, a sensor task is described by a transition which has one input place and one output place, representing the start and end of the sensor task, respectively. Due to the importance of sensing events, their corresponding places are added in this model. Thus, a formal model for single sensor node is illustrated in Figure 2. is the start place and is the end place. is the sensing event place which represents the subscribed sensing event when a sensor task starts. Similarly, is the sensing event place which represents the published sensing event when a task of the smart sensor has been finished. It is worth to note that each sensing event has its own priority, which is defined as a constant in the sensing event place and could be modified by the event manager.
To distinguish the common place and sensing event place, they are drawn as normal circle and double circle with dashed border. Moreover, directed arc drawn with full border represents the control flow and while directed arc drawn with dashed border represents the data flow. Taking the scenario we mentioned above as an instance, the tracking camera sensor is denoted as = , , , . Its corresponding model is illustrated in Figure 3.
4.2. Coordination Patterns among the IoT-Aware Collaborative Business Processes
Due to the discrete distribution of sensors and the complexity of IoT sensing environment, they need to collaborate to accomplish specific tasks. Therefore, different kinds of coordination patterns exist among business processes, including event unicasting pattern, event broadcasting pattern, and service collaboration pattern. In this section, we define these coordination patterns based on extended Petri nets.
4.2.1. Event Unicasting Pattern
If two tasks affiliate to the different smart sensors, one sensor publishes an event, and the other one just needs to subscribe this event during execution phase. Then, we say that event unicasting pattern exists between them. Definition 6 describes this coordination pattern.
Definition 6: Let and be two different smart sensor nodes. Then , , , and , , , are two different four-tuples. Event unicasting pattern exists between these two smart sensors if the following conditions hold.(1)(2)(3)
We take above-mentioned scenario of collaborative business processes in forest-protection as an example. Task infrared thermal imaging sensor is denoted as = , , , , and the task smoke sensor is formalized as = , , ϕ, . Obviously, these two business processes belong to different kinds of sensors; therefore, conditions (1) and (2) in Definition 6 are satisfied. In addition, the smoke event published by smoke senor is subscribed by infrared thermal imaging sensor; therefore, condition (3) in Definition 6 is also satisfied. In this way, according to Definition 6, event unicasting pattern exists between them. Figure 4 illustrates this coordination pattern.
4.2.2. Event Broadcasting Pattern
If tasks affiliate to the different sensors, one sensor task publishes a sensing event, which needs to be subscribed by two or more sensor tasks. Then, we claim that event broadcasting pattern exists between them. Definition 7 describes this coordination pattern.
Definition 7: Let , , …, and be different smart sensor nodes. Then , , , and , , , are different four-tuples. Event broadcasting pattern exists between these smart sensors if the following conditions hold.(1)(2)(3)
We take above-mentioned scenario of collaborative business processes in forest-protection as an example. Task tracking camera sensor is denoted as = , , , , task light sensor is formalized = , , , ϕ, and task sound sensor is formalized = , , , ϕ. Obviously, these three sensors belong to different monitoring areas; therefore, conditions (1) and (2) in Definition 7 are satisfied. In addition, the light sensor and sound sensor both subscribe the alarm event published by tracking camera sensor; therefore, condition (3) in Definition 7 is also satisfied. In this way, according to Definition 7, event broadcasting pattern exists among them. Figure 5 illustrates this coordination pattern.
4.2.3. Service Collaborative Pattern
If one specific task requires multiple sensor tasks to collaborate with each other, then we claim that service collaboration pattern exists between them. Definition 8 describes this coordination pattern.
Definition 8: Let and be two different smart sensor nodes. Then , , , , and , , , , are two different four-tuples. Service collaboration pattern exists between these two smart sensors if the following conditions hold.(1)(2)(3)(4)
We take above-mentioned scenario of collaborative business processes in forest-protection as an example. Task light sensor is formalized as = , , , ϕ, and the task sound sensor is formalized as = , , , ϕ. Obviously, the task item, subscribed event, and published event are same, but the task of alarm target is executed by light sensor and sound sensor together. Therefore, according to Definition 8, service collaboration pattern exists between them. The collaboration service is drawn as a rectangle with dashed borders. Figure 6 illustrates this coordination pattern.
4.3. Modeling the Whole Business Processes
In general, the modeling for collaborative business processes towards IoT applications in the forest-protection scenario includes the following steps:(1)According to Table 1, the whole business processes include five kinds of sensors: smoke sensor, infrared thermal imaging sensor, tracking camera sensor, light sensor, and sound sensor. Modeling all these sensor nodes using the formal specification.(2)Modeling the common control structures, including start/end structure, And-Split/Join structure, and Xor-Split/Join structure. Their corresponding Business Process Model and Notation (BPMN) objects and Petri nets-based models are given in Figure 7.(3)Modeling the existing coordination patterns, including event unicasting pattern, event broadcasting pattern, and service collaboration pattern.
So far, the complete modeling approach of this collaborative business process towards IoT applications in the forest-protection scenario has been obtained and depicted in Figure 8. Based on this model, we could further analyze and optimize this collaborative business process towards IoT application.
5. Optimization Algorithms
In the previous section, we have introduced the formal modeling method for collaborative business process towards IoT applications in the forest-protection scenario using extended Petri nets. Based on this extended Petri nets model, its corresponding sequence diagram could be easily obtained, which is illustrated in Figure 9. As we see, the response sequence for tracking camera senor, light sensor, and sound sensor is uncertain. Furthermore, besides the fire-related sensors, other sensors (e.g., temperature sensor, humidity sensor, carbon dioxide sensor, etc) are also deployed in the forest and send sensing events to the event manager. All these sensing events tend to get response from the IoT system as fast as possible.
However, the available computing resources, usually memory and CPU, are often limited in this particular scene. It is particularly important to reasonably schedule computing resources in a resource-constrained IoT execution environment. The performance (e.g., response time, throughout, event loss ratio, etc) of the entire system is directly determined by the sensing event scheduling algorithm of choice. Thus, we propose a DPFR-based optimization algorithm to solve the problem of sensing event scheduling. Furthermore, we consider both qualitative and quantitative aspects for the evaluation of our proposed optimization algorithm.
5.1. Sensing Events Scheduling
5.1.1. Sensing Event Format
Multiple types of smart sensors are widely deployed in the forest, which are in charge of collecting the environmental information regularly. The gathered raw data not only has a huge number, but also has complex data formats. We take this forest-protection application as an instance, the smoke sensor collects data in text format, the infrared thermal imaging sensor collects data in image format, and the tracking camera sensor collects data in video format. In addition, different sensing events require different response time. For example, the smoke and fire events tend to get a quicker response than the temperature or humidity events. Thus, sensing events need to be assigned corresponding priorities according to certain rules. The sensing events with higher priorities could be first responded and allocated the computing resources.
To better schedule sensing events, we encapsulate them before they are submitted to the event manager. The formal format of encapsulated sensing event is illustrated in Figure 10. Then, each item is interpreted as follows:(i)Topic: it is a hierarchical string that could be filtered based on a finite number of expressions. The client could get all the interesting messages from the Broker based on the subscribed event topic.(ii)DataType: the storage form of information gathered by smart sensors. In this forest-protection scenario, it mainly includes text, image, and video.(iii)Content: the details of sensing events. It is usually compressed before transmission. The event size varies from a few kilobytes to several megabytes.(iv)Priority: it is an integer that is used to indicate the urgency of the sensing event. The higher the priority, the faster the event gets response. Its value can be modified by the event manager according to certain rules.(v): we have introduced it in Section 6. It is a variable that indicates the waiting time for computing resource. An embedded timer starts timing when the business process application begins.(vi)Timeout: a constant that represents the threshold of waiting time for every sensing event. Once this constant is exceeded, the sensing event will be abandoned and its corresponding storage resources will be released immediately. The value of timeout could be set by users.
5.1.2. Event Manager
The first purpose of event manager is to act as the communication substrate supporting event-based interaction among the collaborative business process towards IoT applications. This kind of interaction is commonly referred to as publish-subscribe messaging networks [27]. The publish-subscribe messaging networks are frameworks where publishers publish structured messages (events) to an event service agent (event manager) and subscribers express interest in different events to the event service agent through Lightweight Directory Access Protocol (LDAP) topic tree which is responsible for managing the event topics. e.g., the business process in tracking camera sensor could subscribe a detected event from the event manager, which is published by the business process in infrared thermal imaging sensor. A main property of the publish-subscribe messaging networks is that they are space-decoupled, meaning that the publisher does not need to know the identity of the subscribers. This allows highly flexible and dynamic architecture.
Besides being the basis of communication, event manager is also the core of event scheduling. Due to the huge number of sensing events and limited computing resources, usually CPU and memory, there is no guarantee that each sensing event could be responded immediately. Thus, we design a scheduling mechanism based on memory and secondary storage. When a new event arrives, it first enters the buffer queue of the secondary storage. Then, event manager schedules sensing events between memory and secondary storage based on certain scheduling algorithms. Only the sensing events that are in the ready queue of the memory could get the computing resource and be responded immediately. However, once the waiting time exceeds the threshold, the sensing event will be abandoned and its corresponding storage resources will be released immediately. Figure 11 illustrates the role of event manager in the event scheduling.
5.2. The Goal and Evaluation Standard for Sensing Event Scheduling Algorithm
The limited computing resource is the most important resource in the modern IoT system. Sensing event scheduling is mainly to allocate computing resource to each sensing event based on some scheduling algorithms. The throughput and response time of the IoT system are directly affected by the selected scheduling algorithm.
5.2.1. The Goal for Sensing Event Scheduling
The goal for sensing event scheduling is the final result that needs to be achieved. In general, the common goals are represented as follows:(i)Fairness: to ensure that each sensing event could obtain a reasonable computing resource. We could not make some of the sensing events unavailable for a long time. We should maximize fairness on the basis of priority.(ii)Low Response Time: to ensure that the sensing events could be responded timely. For the high-priority sensing event, it should get response within the specified time. It is an important guarantee for solving emergencies.(iii)High Throughput: to ensure that the IoT system could respond to as many sensing events as possible within a unit time. It is an important measure of efficiency.
5.2.2. The Evaluation Standard for Sensing Event Scheduling
There are a variety of sensing event scheduling algorithms that could be chosen in the phase of design. In order to allow users to select the appropriate algorithm based on demand, we should clearly give some evaluation standards.(i)Turnaround Time: it is the total time taken between the submission of a sensing event for response and the return of the complete output to the user. It usually consists of three parts: the waiting time in the buffer queue of the secondary storage, the waiting time in the ready queue of the memory, and the execution time in the computing resources. To more comprehensively evaluate the sensing event scheduling algorithms, we propose the concept of Average Turnaround Time .(ii)Furthermore, we define the Weighted Turnaround Time equals the ratio of ATT to Execution Time . Thus, the Average Weighted Turnaround Time is defined as follows:(iii)Response Time: response time is the total amount of time it takes to respond to a request for execution. Ignoring transmission time for a moment, the response time is the sum of the execution time and waiting time.(iv)Throughput: throughput is the total numbers of sensing events that have been responded by the IoT system within a unit time. When dealing with large sensing events, such as image and video format events, throughput might be only one per minute. On the contrary, throughput might be more than a thousand per second when the IoT system deals with text format events.(v)Loss Tolerance: as mentioned above, we introduce the concept of timeout to ensure that the storage resources could not be occupied by the unavailable sensing events for a long time. Then, we define Event Loss Rate (ELR) to evaluate the fairness of the sensing event scheduling algorithm. The ELR vaule equals to the ratio of abandoned sensing events to total sensing events.
5.3. The Sensing Event Scheduling Algorithm
5.3.1. First Come First Response (FCFR)
The approaches mentioned in the work [28–30] could be summarized as a First Come First Response (FCFR) algorithm that schedules sensing events based on the sequence. The sensing event entering the buffer queue in the secondary storage earlier will be first responded.
The data structure in the secondary storage is queue by nature. This data structure has the natural characteristics of “First In First Out.” Thus, FCFR algorithm could be realized easily. However, this algorithm is conducive to the long sensing events, but not conducive to the short ones. The short sensing events behind the long sensing events have to wait a long time for scheduling, resulting in poor performances in turnaround time and throughput. Furthermore, FCFR algorithm does not consider the priority of the sensing event, which is an important factor in the IoT environment.
Then, we consider an example to quantitatively analyze the performance of FCFR algorithm. We suppose that there are five different kinds of sensing events in the buffer queue of the secondary storage. These sensing events have different arrival time, execution time, and priorities. The detailed information is illustrated in Table 2.
We could obtain the corresponding sequence diagram of these sensing events based on FCFR algorithm, which is illustrated in Figure 12. The final turnaround time and weighted turnaround time are depicted in Table 3.
5.3.2. Static Priority First Response (SPFR)
The approaches mentioned in the work [21, 31, 32] could be summarized as a Static Priority First Response (SPFR) algorithm that schedules sensing events based on the static priority. The sensing event with higher priority will be first responded. Each sensing event is assigned an integer when it enters the buffer queue in the secondary storage. This integer could not be changed during the execution period.
As mentioned above, there are a variety of sensing events that tend to get response from the IoT system as fast as possible. We initially assign static priority according to the urgency of the sensing event. We take this collaborative IoT-aware business process application in the forest-protection scene as an instance, the fire-related sensing events should have higher priorities than the temperature or humidity sensing events. SPFR algorithm could ensure that the sensing event with higher priority could be first responded. As we know, priority-based sensing event scheduling algorithm is often nonpreemptive, meaning that even if the low-priority sensing event enters the buffer queue earlier than the high-priority sensing event, it has to wait a long time for the execution of the latter one. However, SPFR algorithm is conducive to the sensing event that could be assigned a high priority at the beginning of the IoT system, but not conducive to the sensing event that is assigned a low priority. This is not only contrary to the principle of fairness but also results in poor performances in turnaround time and throughput.
Then, we also consider the example in FCFR algorithm to quantitatively analyze the performance of SPFR algorithm. The corresponding sequence diagram of these sensing events based on SPFR algorithm is illustrated in Figure 13. The final turnaround time and weighted turnaround time for each sensing event are depicted in Table 4.
5.3.3. Dynamic Priority First Response (DPFR)
In this paper, we propose a Dynamic Priority First Response (DPFR) algorithm that schedules sensing events based on the dynamic priority. The sensing event with higher priority will be first responded. Different to SPFR algorithm, the priority could be modified by the event manager according to certain rules during the execution period of IoT system.
In order to maximize fairness on the basis of priority, we propose this dynamic priority-based sensing event scheduling algorithm. The core of DPFR algorithm is the principle to be followed for priority modification. We should ensure that every sensing event could obtain a reasonable computing resource from the IoT system. Thus, the concept of Response Ratio is proposed and defined as follows:
As we know, the response time equals the sum of waiting time and execution time. Thus, Equation (4) could be presented in the following format:
Based on DPFR algorithm, the event manager regularly calculates and modifies the values of all the sensing event priorities. The sensing event whose RR is largest will be first responded. We could draw the following conclusions through analyzing Equation (5).(i)If the waiting time is the same, the shorter of the execution time, the larger of the RR. This ensures that IoT system could respond to as many sensing events as possible within a unit time.(ii)If the execution time is the same, the longer of the waiting time, the larger of the RR. This ensures that the low-priority sensing event, which has waited a long time in the buffer queue of the secondary storage, could also get the response from the IoT system.
Then, we consider the example discussed earlier to quantitatively analyze the performance of DPFR algorithm. We assume that none of the sensing events have timed out. With Algorithm 1, we could get the priority sequence for each scheduling unit. At the time 3.0, the sensing event has been responded and the sensing event has not entered the buffer queue. According to DPFR algorithm, the RR of sensing event is 1 + (3 – 1)/6 = 1.33, the RR of sensing event is 1 + (3 – 2)/1 = 2, and the RR of sensing event is 1. Thus, the sensing event should be responded. We could calculate the RRs of the remaining sensing events at the time 4.0 using the same method. The RR of sensing event is 1 + (4 – 1)/6 = 1.5, the RR of sensing event is 1 + (4 – 3)/4 = 1.25, and the RR of sensing event is 1. Thus, the sensing event should be responded. At the time 10.0, the RR of sensing event is 1 + (10 – 3)/4 = 2.75, and the RR of sensing event is 1 + (10 – 4)/2 = 4. Thus, the sensing event should be responded. The corresponding sequence diagram of these sensing events based on DPFR algorithm is illustrated in Figure 14. The final turnaround time and weighted turnaround time for each sensing event are depicted in Table 5.
|
5.4. Further Simulation Experiments
By comparing the results of turnaround time and weight turnaround time among these three algorithms, we could find that DPFR algorithm has the better performance. To further evaluate our proposed optimization algorithm, we conduct simulation experiments on the basis of larger data sets.
The simulation experiments were conducted on a PC, which had 6 G of RAM, 3.07 GHz of CPUs, and 500 G of disk space. We allocated 1 G of RAM and 2 G of disk space for the following experiments. To simulate the sensors to collect data in the IoT environment, we sent ten data packets to the buffer queue in the secondary storage every 1 millisecond. In addition, we randomly specified the data size and initial priority of the data packet. The data size ranged from 1k to 100k, and the initial priority ranged from 1 to 5. We repeatedly conducted the experiments in the condition that the values of timeout were set to 5 milliseconds and 10 milliseconds, respectively. The sampling time was 1000 milliseconds, and the final results were illustrated as follows:
Throughput is the total numbers of sensing events that have been responded by the IoT system within a unit time. The value of throughout is directly affected by the average response time. Due to the different scheduling principles, the response time of sensing events in DPFR algorithm was the shortest. Thus, it could respond to more sensing events than FCFR and SPFR algorithms within a unit time. Figure 15 illustrated the results of throughput based on three different sensing event scheduling algorithms. In FCFR algorithm, the sensing events at the end of the buffer queue had to wait a long time for scheduling the sensing events before them. Similar to FCFR algorithm, the sensing events with low-initial priority had to wait a long time for scheduling the high-priority sensing events in SPFR algorithm. However, both algorithms considered only a single factor and were not conducive to the certain parts of the sensing events in the buffer queue. Thus, the waiting time and execution time of these sensing events were significantly increased. Different to them, in our proposed DPFR algorithm, sensing events were scheduled based on their RR values. According to the definition of RR, we could know that the priority was determined by the waiting time and execution time together. If the waiting time was the same, the shorter of the execution time, the larger of the RR value. If the execution time was the same, the longer of the waiting time, the larger of the RR value. This algorithm took into account both factors of the sensing events, which ensured that each sensing event could be responded as soon as possible. Thus, the average response time of sensing events in DPFR algorithm was shortest and the value of throughput in DPFR was largest. Figure 16 showed the average response time based on three sensing event scheduling algorithms.
In order to improve the system utilization, we should try our best to keep the CPU busy and reduce the waiting time. Figure 17 illustrated CPU utilization of the system with different sensing event scheduling algorithms. The results showed that DPFR algorithm performed better than FCFR and SPFR algorithms at lower traffic intensity. As CPU was considered to be a limited resource, DPFR algorithm could better adapt to the resource-constricted IoT environment.
As mentioned above, timeout was set to ensure the buffer queue in the secondary storage to be fully utilized. As the sampling time increased, the waiting time of sensing events, especially the later arrival and lower initial priority sensing events, was significantly increased, resulting in the increase of abandoned sensing events. Figures 18 and 19 illustrated the amount of abandoned sensing events when the timeout was set to 10 milliseconds and 5 milliseconds. We could see that the abandoned sensing events in DPFR algorithm were less than in FCFR and SPFR algorithms. Moreover, the curve increased more gently for DPFR algorithm than the other algorithms with increasing sampling time. Furthermore, the shorter of the timeout threshold, the more obvious of the difference among these three different algorithms.
Fairness was used to evaluate whether the IoT system could reasonably allocate limited resources. We should try our best to ensure that all kinds of sensing events could get response form the IoT system. In order to further compare the performances of three sensing event scheduling algorithms, we defined that the sensing events, whose data size were larger than 50k, as long events and the rest as short events. In addition, we defined that the sensing events, whose initial priority were larger than 2, as high-priority events and the rest as low-priority events. Figure 20 illustrated the number of IoT system responses to various sensing events based on different scheduling algorithms. We could see that the number of responded long events was much larger than short events in the FCFR algorithm. Similarly, the number of responded high-initial priority events was much larger than low-initial priority events in the SPFR algorithm. On the contrary, the number of all kinds of sensing events that get response from the IoT system was approximately the same in our proposed DPFR algorithm, ensuring that all sensing events could obtain the reasonable computing resources. Thus, DPFR algorithm could better reflect the fairness of IoT system.
6. Implementation and Screenshots
In order to automate the approach presented in this paper, we developed an actual development system for developers to manage the full lifecycle of the collaborative IoT-aware business process applications. Figure 21 illustrates the comprehensive GUI of the system. It consists of 5 major parts and provides all essential tools for developers. Each part is responsible for a different function. Part 1 is a basic graphic element library, which provides developers draggable process elements. Part 2 is a workspace panel where developers could model the specific business processes, create the corresponding Petri net models, and bind the sensing events to send or receive tasks. Part 3 is a configuration panel where developers configure the properties of process elements, including sensing event topic, timeout value, and the types of interfaces by which they would like to access the raw data. Part 4 is a menu bar where developers could decouple the business processes into fine-grained process fragments, package the IoT application into a war file, and deploy process fragments to distributed servers with custom buttons. Part 5 is a package explorer where developers could open or browse the element hierarchy of the collaborative IoT-aware business process applications. More information about our work could be found at this YouTube video.
Figure 22 illustrates the screenshots of our proposed system to manage and monitor the collaborative business process towards IoT applications. Figure 22(a) shows the collaborative business processes, where developers could graphically add or remove process elements, dynamically define the process interaction interfaces, and logically validate the logic errors of process model (A demonstrative video could be found at this https://youtu.be/T5HN0AboJ2AYouTube video). Figure 22(b) shows the way to package a designed IoT-aware business process application. Developers could package the application into a war file through this step. Similarly, Figure 22(c) shows the way to deploy a packaged war file to distributed servers. It is worth noting that unavailable servers have been automatically filtered off by the system. Namely, developers only need to choose the war file which they want to deploy. Figure 22(d) shows the way to monitor the information of a deployed IoT application, including the name, created time, and execution status.
(a)
(b)
(c)
(d)
7. Conclusion
In this paper, we have presented a novel modeling and optimization approach for the collaborative business process towards IoT applications, making it fit in the dynamic IoT sensing environment. In order to reach this goal, we initial extend the traditional Petri nets with sensing event factor. Based on a real collaborative business process towards IoT application in the forest-protection scenario, the formal modeling specification of senor nodes is investigated and their coordination patterns are formally defined. Then we could easily deduce its corresponding sequence diagram from the extended Petri net model. Next, we propose a DPFR-based optimization algorithm to solve the problem of sensing event scheduling. Moreover, we qualitatively and quantitatively analyze each algorithm and conduct a series simulation experiment to compare different algorithms. Finally, the approach presented in this paper has been validated to be valid and implemented through an actual system.
However, our work is still in its infancy and requires more actual applications to prove its applicability. Thus, we plan to leverage our proposed approach to implement advanced collaborative business process towards IoT applications in a larger and more complicated IoT sensing environment.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work has been supported by National Natural Science Foundation of China (Grant nos. 61501048, U1536111, and U1536112), Beijing Natural Science Foundation (Grant no. 4182042), and Fundamental Research Funds for the Central Universities (Grant no. 2017RC12).