In general, distributed scheduling is not necessarily reasonable for individuals; it sacrifices local optimization to obtain a conflict-free global suboptimal solution while limiting the number of assigned tasks. Moreover, the exchange strategy is prone to deadlock, which is intolerable for the swarm and must be resolved. Below, we propose solutions to the above two aspects. In this section, we apply two rescheduling strategies to improve these problems: (1) One is the cost-dependent rescheduling strategy, which simply adds a local task reordering strategy in the recursive inclusion phase of PI-MinAvg to include unassigned tasks or new tasks directly; (2) the other is the cost-independent rescheduling strategy, that is, the improved deadlock-free PI-MaxAss method, which relies on the task exchange strategy without cost to create free time slots to contain unassigned tasks or new tasks indirectly. Finally, we incorporate the task reordering mechanism of strategy 1 into the recursive inclusion phase of strategy 2 to form a hybrid task rescheduling method.
3.1. A Novel Local Task Reordering Strategy
For search and rescue missions, PI-MinAvg prioritizes minimizing the average start time of all tasks, and then considers the number of tasks that can be accommodated, which makes it difficult to further increase the total number of allocated tasks and is not the most desirable for rescue. In order to achieve a consistent schedule, there is a mutual compromize among agents, although each adopts a heuristic greedy strategy. This may lead to the local scheduler possibly not being reasonable for individuals; either there is a task to look far away, or there is a necessity to wait. In other words, on the individual level, there is room for improvement in the local scheduler. Moreover, exchange-based methods, such as CBBA and PI-MinAvg, have a common feature that once included tasks that are not removed from the swarm in subsequent bidding rounds; they will only be exchanged within the swarm and obtained by other UAVs at a lower price. Actually, it is possible for the UAVs to form new slots to contain unassigned tasks or new tasks simply by rearranging their respective tasks without violating time constraints. To this end, we propose a novel distributed rescheduling method (denoted as PI-Reorder), which simply adds the local task reordering strategy to the recursive inclusion phase of PI-MinAvg, so that unassigned tasks or new tasks can be included as soon as possible without relying on the task exchange strategy (such as PI-MaxAss). The following is an example where the heuristic greedy strategy leads to non-ideal individual scheduling, and PI-MaxAss is unable to further improve the scheduling results through cost-independent task exchange.
Example 1. An illustrative example of two mobile UAVs and five tasks distributed in a common partitioned workspace is depicted in Figure 1a. Driven by the greedy strategy of PI-MinAvg running on , the UAV will firstly select due to its lower IPI-MinAvg and then . Similarly, will choose to undertake and subsequently. However, the remaining task will not be selected by any UAV because neither nor can contain task without abandoning the existing task. Figure 1b depicts the timeline corresponding to the scheduling result in the left figure. Intuitively, it is not possible to create a feasible slot containing with a task exchange mechanism such as PI-MaxAss. For example: tries to pass to by raising ’s significance, thereby creating a slot that can contain ; however, is currently unable to take on additional tasks, and cannot be inserted into ’s task list. That is, there is no way to obtain a boost in the number of tasks by swapping methods. The following describes the basic principles of the task reordering strategy, and the specific procedure is shown in Algorithm 1.
First, the UAV
tries to sort its local scheduler in ascending order, according to the deadlines of tasks in the scheduler (Algorithm 1, line 2).
Second, the UAV updates the time costs of tasks in (Algorithm 1, line 2). By adding to , will perform its remaining task assignments later. The time cost of tasks in the task list earlier than is not affected by increasing .
Next, following PI-MinAvg, mentioned in
Section 2.2, the UAV
selects a task at a time to include in its updated task lists
until no more tasks can be added (Algorithm 1, lines 4–8).
Once tasks are recursively included, subsequent work follows the same method as PI-MinAvg, which is not described here.
Algorithm 1 Task Inclusion Procedure with Reordering running on . |
- 1:
whiledo - 2:
Reorder according to tasks’ deadlines: . - 3:
Update the time costs for the tasks in . - 4:
Compute the marginal significance list . - 5:
if then - 6:
Insert the task into at position . - 7:
Update . - 8:
end if - 9:
. - 10:
end while - 11:
Update significance list .
|
Continuing on Example 1, it is explained how the task reordering strategy achieves the further incorporation of while keeping the existing tasks unchanged when PI-MinAvg and PI-MaxAss are incapable.
Example 2. Based on the schedulers generated by PI-MinAvg, the UAV reorders its local scheduler according to tasks’ deadlines as shown in Figure 2a and it can create a new feasible slot for . Thus, is able to add into its scheduler, increasing the allocation numbers further. The task timelines corresponding to Example 1 (continued) are illustrated in Figure 2b. Intuitively, utilizing the task reordering strategy, reorders its local scheduler from to , despite increasing time cost. The change can create a feasible slot for unassigned tasks, so that adds a task into its scheduler as . The above example shows that without a swapping task, it is possible for each UAV to further increase the allocation number by exploiting its local schedule potential.
3.2. A Deadlock-Free Task Exchange Strategy
The effect of simply using the task reordering strategy is limited, and the task exchange strategy is still needed to obtain better schedules. Starting from a suboptimal assignment in which additional tasks cannot be directly included without violating time constraints, PI-MaxAss presented in [
22] is able to reschedule tasks to increase the allocation number simply through the cost-independent allocation. The idea is to attribute a high cost (RPI-MaxAss) to an assigned task when the release of this task can permit an additional task to be inserted within the free time created, to further increase the total allocation number. However, PI-MaxAss occasionally falls into an infinite cycle of shifting the same task, i.e., the deadlock problem. In this section, we first analyze the deadlock phenomenon, and then propose a deadlock-free task exchange strategy.
(1) Deadlock Analysis for PI-MaxAss. To explain the deadlock problem for PI-MaxAss intuitively here an example of deadlock is exhibited in
Table 1 and a similar situation remains problematic.
Example 3. A representative example of three mobile UAVs suffering from the deadlock problem when bidding for six tasks with PI-MaxAss is depicted in Table 1, wherein each bidding round task consensus (abbreviated as TC), task removal (abbreviated as TR), task’s RPI-MaxAss update (abbreviated as RU) and task inclusion (abbreviated as TI) work in turn, but the stage in which the intermediate results do not change is omitted here for simplification. With PI, obtains two tasks , also obtains two tasks , obtains the task and the remaining task cannot be executed by any UAV. Next, the rescheduling process of PI-MaxAss is shown in Table 1, where the symbol in the form of indicates that is rescheduled to a UAV with its RPI-MaxAss equal to c. For an unassigned task (abbreviated as Un task), such as , its RPI-MaxAss is set to a high value , where r is a decay factor; that is, each time a task is rescheduled, its RPI value is subtracted by r. A task is regarded as an unassigned task if its RPI is larger than a preset value such as ; that is, rescheduling is allowed for at most three times. According to the schedules of PI-MinAvg given in the first row of
Table 1, the rescheduling process of three UAVs bidding for six tasks is described in detail, which leads to an infinite deadlock loop.
In round 1, since and can add the unassigned task to their local scheduler on the premise that their tasks and are removed, respectively, they both actively increase ’s RPI-MaxAss to , so that may be bid by other UAVs in the next round. The RPI-MaxAss of the remaining tasks in the individual UAV schedulers remain the same because even if they intend to remove any tasks from their schedulers, they cannot add any unassigned tasks.
In round 2, after communicating with each other, will find that the RPI-MaxAss of tasks and belonging to and , respectively, have increased. At this point, has the opportunity to bid by removing or , while is not considered because it cannot satisfy ’s time constraints. Similar to round 1, the RPI-MaxAss of and need to be raised to , so that they can be outbid by other UAVs.
In round 3, after communication and consistency, finds that increases the RPI of , so it can add to its scheduler without removing any tasks. In the RPI-MaxAss update stage, finds that can be added on the premise of removing , so ’s RPI-MaxAss is updated to .
In round 4, has to remove which was outbid by . After removing , selects the task with the lowest cost among the current candidate tasks, which happens to be still here. Then, when updates the RPI-MaxAss, it can still obtain by increasing the RPI-MaxAss of or as in round 2, but at this time, since ’ RPI-MaxAss for has reached the threshold value , for this reason cannot obtain with a lower RPI-MaxAss.
In round 5, has to remove which was outbid by . After removing , finds that there is a time margin to include , so it updates ’s RPI-MaxAss to , which goes back to round 2 (abbreviated as G2) and gets stuck in an endless loop.
Preliminary experiments running PI-MaxAss show that two or more UAVs occasionally get caught in an infinite cycle shifting the same tasks. For a swarm system, this phenomenon is intolerable and will cause the system to stagnate. For example, in a search and rescue mission, when multiple UAVs perform distributed task scheduling, in the absence of algorithm truncation, they will not be able to get out of the algorithm’s infinite loop, resulting in the inability to obtain schedules in time to carry out actions, and ultimately causing survivors to be unable to obtain rescue. Therefore, it is necessary to find a way to avoid this deadlock problem.
(2) A Deadlock-free Task Exchange Strategy. Ref. [
22] proposed a solution to limit the number of times that a UAV can remove the same task from its list before it no longer attempts to include it. A removal task set
is created to record removed tasks, and a counter vector
is used to store the times each task has been removed from a UAV
’s task list. The precaution
can prevent those tasks that are being repeatedly swapped from being scheduled optimally, but it ensures that the system can converge. However, this method relies heavily on the reasonableness of the maximum number
of removals, with a lower limit causing premature truncation of the algorithm, and a higher limit causing multiple invalid bids. Here, based on the exchange mechanism of PI-MaxAss, we introduce a removed task set
, an included task set
, a task removed counter
, a task included counter
and a collection of task included counters
to achieve deadlock-free task exchange. The specific process is as follows:
As with PI-MaxAss, unallocated tasks are set initially to have a fixed highest RPI-MaxAss, a constant defined as U, such that if is unassigned then . The RPI-MaxAss of assigned tasks are initially set to 0, such that .
In the task inclusion phase as shown in Algorithm 2, UAVs select tasks to include in their schedulers until no more tasks can be added. The candidate task
is the one compatible with the functionality of
and not already in
, and with an RPI-MaxAss greater than 0. In addition,
either does not belong to the removed task set
, or it belongs to
but
(Algorithm 2, line 4). This condition indicates that
has never been removed in the previous iteration, or the task removed counter
is less than the set threshold
. The candidate tasks for inclusion in
are formally defined as
If the condition in Algorithm 2, line 6, returns true for at least one position
l, the IPI-MaxAss
of
in
is recorded such that,
Next,
selects for inclusion the task whose IPI-MaxAss can improve upon the task’s current RPI-MaxAss the most as shown in the following formula. An IPI-MaxAss of
in
lower than
’s RPI-MaxAss in another UAV’s task list
indicates that the global cost can be reduced if
is reallocated to
.
After the most appropriate task
is included (Algorithm 2, line 11),
needs to be added to the included task set
if
, the corresponding task which included counter
is instantiated with its initial value to be 1; otherwise, only the task which included count needs to be incremented by one (Algorithm 2, line 13).
Before the end of the task inclusion procedure, the RPI-MaxAss list, which keeps track of which UAV is assigned to which task, needs to be updated; this differs from PI-MaxAss in that additional conditions need to be met (Algorithm 2, line 15). Refer to Algorithm 3 for the specific process.
Algorithm 2 Task Inclusion Procedure running on . |
- 1:
whiledo - 2:
← highest permissible cost, . - 3:
Identify candidate tasks satisfying according to (11). - 4:
for each task in do - 5:
if is feasible then - 6:
Record the IPI-MaxAss of in according to ( 10). - 7:
end if - 8:
end for - 9:
if then - 10:
Insert task into at position . - 11:
Update . - 12:
and if , else . - 13:
end if - 14:
end while - 15:
Update significance with Algorithm 3 satisfying or , .
|
In this paper, task
’s RPI-MaxAss
is the maximum significance change brought by the insertion of a candidate task
shifted from other UAVs in local scheduler
after
is removed, where
is the candidate tasks set consisting of unassigned tasks, and tasks that would be released from other UAVs’ schedulers.
where
is a list of the candidate tasks defined as follows:
The candidate tasks follow the same constraints as the candidates in (11) with the added constraint that the candidate task’s RPI-MaxAss is greater than . This constraint is used to limit the number of reassignments permissible to allocate an additional task. In addition, tasks that do not belong to the removed task set or with a task included counter greater than the threshold can only be updated with the RPI-MaxAss. That is, if a task has never been removed, it can be freely updated with the RPI-MaxAss; if a task has a removed record and the task included counter exceeds the threshold after being included in , then the task can be updated with the RPI-MaxAss.
If a task
in
can be replaced by two or more candidate tasks
with different RPI-MaxAss, the highest RPI-MaxAss is recorded. The RPI-MaxAss of
in
is formally defined as
where the decay factor
r subtracted is used for limiting the number of reschedules.
Algorithm 3 Significance Update Procedure running on . |
- 1:
Maintain tasks in with the lowest RPI-MaxAss to 0: . - 2:
Identify Candidate Tasks satisfying or according to ( 14). - 3:
for each task in do - 4:
Create a temporary scheduler . - 5:
Update for tasks after . - 6:
Identify the list of candidate tasks according to ( 13). - 7:
Compute ’s RPI-MaxAss according to ( 15). - 8:
end for
|
In the communication and conflict resolution phase as shown in Algorithm 4, except for the following differences, this paper follows the same task removal process for PI-MinAvg introduced in
Section 2.2. When a task
has been removed from the UAV
’s scheduler
for the first time, it will be added to
, and
is initialized to 1; otherwise, only the removal count needs to be incremented by one.
Once the current round of removal while-cycle ends, the tasks just removed need to be immediately deleted from the inclusion set
.
The corresponding task included counter
also needs to be cleared.
For the detailed removal process of PI-MinAvg, please refer to [
7].
Algorithm 4 Task Removal Procedure running on . |
- 1:
UAV forms its conflict tasks set . - 2:
while and do - 3:
Remove task from and . - 4:
Update costs and significance for the rest of the tasks in and . - 5:
and if , else . - 6:
end while - 7:
Remove task from the included task set for any . - 8:
Remove the task included counter from satisfying . - 9:
Update the local list belongs to UAV .
|