A Vehicular Edge Computing-Based Architecture and Task Scheduling Scheme for Cooperative Perception in Autonomous Driving

Abstract

Cooperative perception is an important domain of autonomous driving that helps to improve road safety and traffic efficiency. Nevertheless, the large amount of sensed data and complicated algorithms make storage and computation for autonomous vehicles (AVs) challenging. Furthermore, not every AV needs to individually process all sensed data from other AVs because the environmental information is the same in a small region. Inspired by vehicular edge computing (VEC), where AVs are interconnected with the help of roadside units (RSUs) for better storage and computation capabilities, we propose a VEC-based architecture for cooperative perception and design a key task scheduling algorithm for the above challenges. Specifically, a time slot-based VEC architecture with the help of an RSU is designed, and the task scheduling problem in the proposed architecture is formulated as a multitask multitarget scheduling problem with assignment restrictions. A two-stage heuristic scheme (TSHS) is designed for the problem. Finally, extensive simulations indicate that the proposed architecture with the TSHS can enable cooperative perception, with a fast running speed and advanced performance, that is superior to that of the benchmarks, especially when most AVs face limitations in terms of storage and computation.

1. Introduction

Cooperative perception is a promising and important domain of autonomous driving that has received more and more attention from academia and industry. In cooperative perception, autonomous vehicles (AVs) are interconnected via communication sensors, and individual information is shared among connected and autonomous vehicles (CAVs), which extends the line of sight and field of view of each CAV. Communication sensors include dedicated short-range communication (DSRC) and 5G cellular networks, which could help to establish vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication [1]. In addition, there are several different V2V communication technologies, e.g., millimeter wave and visible light communication, but these technologies are under research and are not widely deployed in autonomous driving [2]. In contrast, DSRC is widely used, and many studies related to cooperative perception are based on DSRC. DSRC is based on 802.11p, which is amended according to 802.11 for supporting mobility and the IEEE 1609 family of standards [3]; it allows short-range communication over hundreds of meters via the dedicatedly allocated spectrum in the 5.9 GHz band. In this way, each CAV can improve its safety over a short range and increase traffic flow efficiency over a long range. For example, a vehicle can receive detected perception data of preceding vehicles via DSRC, and then the vehicle can build a map of the surrounding environment over a larger range. The map can help to know obstacles in front of the preceding vehicle or accidents on another road to help to make decisions to avoid obstacles and change routes.

A typical architecture for cooperative perception is illustrated in Figure 1, which is constructed from the perspective of communication and computation. There are mainly two participants in the architecture, including roadside units (RSUs) and AVs. An RSU can be regarded as an edge node with computing and communication capabilities that can serve AVs within its communication range. Meanwhile, every AV is equipped with computing devices, onboard sensors and communication sensors. Onboard sensors include LiDAR, radar, camera, etc. [4], and each AV can perceive its surrounding environment using a different sensor. After that, an AV can transmit detected information to other AVs and RSUs via wireless communication technologies. The advantages of the architecture are twofold [5]: (1) AVs can obtain road information that is out of sight, which can help to make better decisions. (2) The RSU can collect different perception results to broadcast to other vehicles; meanwhile, the RSU can also evaluate the “global” optimization of vehicle trajectories for improved traffic efficiency.

From previous studies [6,7,8], there are three basic tasks in cooperative perception, i.e., location, detection and tracking, and mapping. All these tasks are computation-intensive, especially when deep learning-based algorithms are involved. Furthermore, detected sensing data can rapidly exhaust the storage of AVs. These facts will pose a major challenge to AVs because of the individual execution of tasks on the ego vehicle. However, sensing data are typically high spatial and of temporal locality, i.e., the sensed data are the same in a section and are only important to AVs in that section during a particular period, which indicates that not every AV needs to individually process all sensed data received from other AVs. In this paper, we consider the inherent spatial and temporal locality and propose a VEC-based infrastructure for the storage and computation challenges of AVs in cooperative perception. For the effective utilization of resources from AVs in the architecture, we investigate the key task scheduling problem among participating AVs. The main contributions are listed below.

• We propose a hybrid time slot-based VEC architecture consisting of AVs and RSUs for cooperative perception, in which some real conditions of AVs are considered, e.g., the involvement of multiple types of resources, heterogeneity of tasks and AV resources and transmission constraint of every participating AV.
• We formulate the task scheduling problem in the proposed architecture as a multitask multitarget scheduling problem with assignment restrictions. We show that the problem is a multidimensional multiple knapsack problem with assignment restrictions, and its NP-hardness is proven in the paper.
• We design a two-stage heuristic scheme (TSHS) for the formulated scheduling problem, which aims at better utilization of the resources of AVs for a better cooperative perception. We compare the result of TSHS with optimum results and the results of some basic benchmarks, and its effectiveness is validated after extensive simulations.

The remainder of this paper is organized as follows. In Section 2, we detail related works. In Section 3, we first illustrate the VEC-based architecture for cooperative perception and present the model formulation. Then, we analyze the optimal solution of the formulated problem. In Section 4, we provide insight into the TSHS. In Section 5, we present our experiment and results. Finally, in Section 6, we conclude the paper by discussing some important topics that need further research. We summarize the used acronyms in

Table 1. Summary of Acronyms.

Acronym	Phrase
AV	autonomous vehicle
VEC	vehicular edge computing
RSU	roadside unit
TSHS	two-stage heuristic scheme
CAVs	connected and autonomous vehicles
DSRC	dedicated short-range communication
V2V	vehicle-to-vehicle
V2I	vehicle-to-infrastructure
EC	edge computing
NoN	number of neighbors
BDR	balance degree of resources
RRAT	resource requirements of all tasks
RSD	satisfaction degree

for better reading.

2. Related Works

2.1. Vehicular Edge Computing and Cooperative Perception

Research on the combination of edge computing (EC) and AVs has recently attracted considerable attention because vehicle-based applications’ characteristics are naturally consistent with those of EC. EC can provide ultralow latency and enable location awareness by deploying edge servers near end users [9]. Vehicle applications, especially autonomous driving services, e.g., real-time traffic information and parking guidance, are location dependent, delay-constrained and computation-intensive [10]. Therefore, the combination of EC and AVs can fulfill the requirements of vehicle applications and can alleviate the pressure of the backbone network. In addition to AVs serviced by edge nodes, i.e., vehicles utilize the resources provided by edge nodes to execute their applications, vehicles can be regarded as edge nodes to provide services to other users. This kind of architecture is called vehicular edge computing (VEC) [11], which can help to facilitate some vehicle-based applications, e.g., vehicle-based crowdsourcing and cooperative perception.

Vehicle-based crowdsourcing is a novel resource sharing technology in which vehicles with the capability of sensing, computing and communicating are recruited to execute tasks of interest, e.g., environment sensing. After completing tasks, vehicles will be paid. Different aspects of this domain have been researched. Zhu et al. [12] proposed a deep Q-network-based algorithm for improving the quality of information and processing latency in vehicle-based visual crowdsourcing. Lai et al. [13] solved the maximal weighted sensing paths problem in vehicular crowdsourcing by a heuristic method, in which the selection of participating vehicles and path computing are the main concerns and the aim is to better benefit from vehicular crowdsourcing. Hui et al. [14] considered the privacy of AVs and security of edge computing devices and proposed a coalition game algorithm based on blockchain to minimize the task execution cost. We do not thoroughly review the related researches because it is not the main concern of this paper. One difference between vehicle-based crowdsourcing and cooperative perception is that an incentive mechanism is needed in vehicle-based crowdsourcing to encourage more participating vehicles, but this is not needed in cooperative perception. This is because every participating vehicle can benefit from cooperative perception.

Cooperative perception refers to vehicles mutually sharing individual perception information for a better line of sight and field of view, and consequently improving road safety over a short range and increasing traffic flow efficiency over a long range [1]. The safety of AVs is critical for AV computing system design [15]. In [7], Kim et al. proposed a creative system for cooperative perception, in which a multimodal cooperative perception system for all-around views of drivers is built in reality and cooperative driving is realized by see-through forward collision warning, overtaking/lane-changing assistance and automated hidden obstacle avoidance. In paper [16], the authors proposed a cooperative-based method for bottleneck detection on motorways. In paper [17], Shan et al. addressed the handling of cooperative perception messages and demonstrated in experiments that CAVs can perceive pedestrians around the corner. Because the realization of cooperative perception is based on vehicle-to-everything communication, in which valuable exchange information about the surrounding environment is transmitted, the message format and generation rules for cooperative perception have been standardized by some standardization bodies, e.g., the European Telecommunications Standards Institute (ETSI) [17]. Meanwhile, what contents should be included in the exchanged messages has been researched by many researchers. In [18], after evaluating the performances of different congestion and content control schemes, Gani et al. determined that message content that is farther away from the sensor is more valuable and should be concentrated on mapped objects but not near the edge of the local sensor range. In addition to the exchanged messages, the condition of communication in cooperative perception is critical because heavy channel loads can degrade the performance of cooperative perception. In [19], the authors considered the value of detected objects, and these can be included in the message only if they are valuable for receivers. In this way, channel loads can be reduced because fewer messages are transmitted. In [20], the authors evaluated the impact of sensor characteristics, the market penetration rate and congestion control schemes on the operation and the performance of cooperative perception. They proposed that the combination of congestion control functions at the access and facility layers can improve the cooperative perception. Although communication is a very important domain, the main focus of the paper is the pressure of computation induced by tasks in cooperative perception

The main three tasks of cooperative perception, i.e., localization, detection and tracking, and mapping, are researched from many perspectives. For localization, the acquisition of a vehicle’s position in the environment is the main concern, and GPS-based multilateration [21] with errors ranging from 3.3 m to 6.75 m or an advanced refining method based on the Extended Kalman Filter (EKF) [22] with a standard deviation of 0.02 m are used. For detection and tracking, the detection of obstacles in the scene and tracking them are the main concerns, and most related methods are neural network-based, e.g., YOLOv3 [23]. For mapping, the goal is to build a map by aggregating data from the previous two stages and to optimize routes and adapt vehicle navigation [2]. All these tasks, especially neural network-related tasks, put large pressure on vehicle resources, which needs to be solved. Furthermore, we note that most of these tasks are executed locally, and a cooperative perception with more collaboration among AVs is a promising approach in the future.

2.2. Task Scheduling among CAVs

Task scheduling, or resource allocation, is a critical issue in traditional cloud computing (CC) and VEC because it determines the profit of the service provider and the efficiency of resource utilization. In CC, Liu et al. [24] proposed an efficient approximation algorithm to perform task scheduling in a multimapping manner under a heterogeneous physical machine environment that aimed to improve social welfare and allocation efficiency. Zhang et al. studied different scheduling scenarios in cloud computing. In [25], focusing on the challenges of multidimensional resources in clouds, they proposed an online truthful mechanism for time-varying resource allocation in an interprogramming model. In [26], a dynamic priority-based online strategy-proof mechanism was proposed that allows jobs to be scheduled in a preemptive-restart mode, which can improve the social welfare and resource utilization of clouds. In [27], a dominant-resource-based allocation algorithm was proposed for batch virtual machine allocation in clouds, which has high social welfare and a high served user ratio. In [28], they proposed a truthful online auction mechanism based on user evaluation and cost for a multirequirement, single-minded scenario in which a user can submit multiple requirements but only one can be satisfied. They also investigated machine learning-based allocation algorithms in [29] and extended the above methodology to collaboration between clouds and edges. In [30], an online strategy-proof allocation mechanism for live video webcast services, which includes individual rationality and truthfulness and has high social welfare, was proposed. In [31], considering the combination of the Internet of Vehicles and blockchain, an auction mechanism was proposed to encourage users to undertake mining computing.

In VEC, task scheduling has been researched considering specific vehicular features. Liwang et al. [32] presented a game theory-based method to conduct opportunistic computation allocation to achieve efficient utilization of vehicles’ resources. Chen et al. [33] proposed a hybrid dynamic scheduling scheme that combines queue-based dynamic scheduling and time-based dynamic scheduling to realize adaptive scheduling. Wan et al. [34] considered EC scheduling for CAVs in 5G networks and proposed a computation offloading algorithm to solve the multiobjective optimization problem for appropriate allocation decisions. Liu et al. [35] proposed a deep Q-learning-based algorithm that considers allocation target servers and vehicle data transmission modes to realize optimal allocation. Zhou et al. [36] proposed an alternating direction method of a multiplier-based distributed algorithm with low complexity to realize energy-efficient workload allocation. Xu et al. [37] considered the privacy protection of task scheduling to EC devices among CAVs and proposed a multiobjective optimization algorithm to reduce energy consumption and prevent privacy conflicts. The above studies conducted scheduling among CAVs to satisfy the requirements of computation-intensive and response-constrained applications. However, the formulated problems do not consider multiple types of resources and the differences in connectivity of each vehicle in the network, which are included in our formulated problem. Furthermore, the vehicles in these studies can only be service providers or requestors, whereas vehicles can be both in our model.

In our paper, we comprehensively consider the design of the VEC-based architecture for cooperative perception and propose a task scheduling algorithm to realize the efficient utilization of AV resources to process more detected sensing data, thereby improving road safety.

3. System Model and Problem Formulation

In this section, we first present a VEC-based architecture for cooperative perception. Then, the formulation of task scheduling in the architecture is presented in detail. Finally, we discuss the optimal solution of the formulated problem and prove its NP-hardness.

3.1. Hybrid VEC-Based Architecture for Cooperative Perception

Figure 2 shows a hybrid VEC-based architecture for cooperative perception. In our research, urban areas are divided into several small regions, and there is one RSU located in the center of the region. The region size is determined by the communication capability of the RSU, and a wide region size implies that more AVs could participate in cooperative perception. Therefore, the number of participating AVs is a key parameter behind the region size. We focus on one of these regions, and the research results of the region can be applied to the others. The RSU is equipped with communication devices and connected to edge servers; it acts as a scheduler to provide services to AVs in the region. In a region, assuming that there are $M$ AVs that are participating in cooperative perception, we use $ℳ=\{1, 2, \cdot \cdot \cdot , M\}$ to denote the AV set. AVs can connect to the RSU via V2I links and can connect to each other via V2V links. We assume that an AV or RSU can communicate with several AVs simultaneously, and there is no interference in these communication links.

AVs are equipped with communication and computation devices and can be regarded as small servers with radio ability. There are $R$ types of resources, denoted as $ℛ=\{1, 2, \cdot \cdot \cdot , R\}$, e.g., CPU, RAM and disk size. AVs can possess different amounts of different types of resources due to many factors, e.g., the price of vehicles and software carried on vehicles. We use ${\mathit{c}}_i={(c_i^1,c_i^2,\cdot \cdot \cdot ,c_i^R)}^T$ to denote the amount of different resources possessed by AV $i,i\in ℳ$ and use $\mathit{C}=(c_1, \cdot \cdot \cdot , c_M)$ to denote the resource matrix of all AVs in the region. AVs can not only execute tasks on themselves but also tasks from other connected vehicles in a virtualized manner, e.g., virtual machines.

The role of the RSU is as a scheduler in the region, and the role of AVs that form the VEC is undertaking the computation of tasks. In reference [5], there were two architectures for communication and computation in CAVs, i.e., centralized and decentralized architectures. Centralized architectures refer to the RSU acting as a scheduler to provide service to CAVs. Its advantages are twofold: (1) The communication coverage of the RSU is larger, and different communication technologies can coexist. (2) The necessary information of all CAVs can be acquired, and “global” optimization can be performed. However, its disadvantages are that it is costly, and the connection between the RSU and CAVs can be unstable because of the distance and mobility of vehicles. Decentralized architectures refer to vehicles mutually transmitting necessary information and complete computational tasks by themselves. Its advantages are less of a transmission delay and more stable V2V communication. Its disadvantage is that the negotiation between vehicles is not “global”. A hybrid architecture is promising; for cooperative maneuvers, such an architecture would mean that vehicles can coordinate among themselves, and centralized entities (such as mobile edge computing (MEC) servers) are also capable of sending proposals to (groups of) vehicles [5]. Inspired by these ideas, we propose a hybrid VEC-based architecture for cooperative perception. Tasks of cooperative perception are time constrained and of high spatial and temporal locality, and these tasks are offloaded among CAVs. The scheduling of tasks, in which information of all participating vehicles is needed, is global, and RSUs with wide coverage act as schedulers to schedule tasks.

In cooperative perception, environmental information is derived from processing data of different types of sensors, e.g., camera, LiDAR and radar. Different sensors have different data production rates, e.g., 10–70 MB per second for LiDAR and 10–100 KB per second for radar. Each type of sensor corresponds to a type of task, and we assume that there are $K$ types of tasks denoted as $\mathcal{K}=\{1, 2, \cdot \cdot \cdot , K\}$. A specific task can be represented by a vector ${\mathit{\omega }}_k={({\omega }_k^1, {\omega }_k^2, \cdot \cdot \cdot , {\omega }_k^R)}^T$, where ${\omega }_k^R$ denotes the amount of $R$ type resources needed by a task of type $K$. We use $\mathit{W}=({\mathit{\omega }}_1,{\mathit{\omega }}_2,\cdot \cdot \cdot ,{\mathit{\omega }}_K)$ to denote the resource requirement matrix of all task types. Vehicles can produce different numbers of tasks of different types, and these tasks can be executed on ego AVs or offloaded to connected AVs for partial or full execution via V2V links. We assume that tasks can only be transmitted in a one-hop manner, i.e., tasks cannot be transmitted to other AVs by a multihop relay.

Task scheduling and offloading are based on time slots, as shown in Figure 2. The block diagram shows the implementation procedure of the central RSU and an AV in time slot $t$. Vehicles synchronize their time slots and report necessary information with the RSU after entering the region. When a vehicle establishes a connection with the RSU during the RSU’s time slot $t$, the vehicle will attend the next scheduling decision at the RSU’s time slot $t+1$, which means that the reported information will be utilized for task scheduling in the next time slot. Here, the length of the RSU’s time slot should be the same as every vehicle’s time slot. The whole cooperative perception procedure can be divided into three steps:

• First, vehicles conduct neighbor detection via V2V links. A vehicle sends detection packets to other vehicles, and vehicles without packet loss and with low round-trip time are regarded as neighbors. We assume that the neighbors detected in a time slot will not change because of the short length of the time slot, but neighbors in different time slots can change because of vehicle mobility. For vehicle $i\in M, j\in M\backslash \left\{i\right\}$; ${\delta }_{ij}={\delta }_{ji}=1$ means that vehicles are mutual neighbors; otherwise, ${\delta }_{ij}={\delta }_{ji}=0$. We use ${\mathit{\delta }}_i={({\delta }_{i1}, \cdot \cdot \cdot ,{\delta }_{iM})}^T$ to denote the neighbor vector of AV $i$ and $\mathbf{\Delta }=({\mathit{\delta }}_1, \cdot \cdot \cdot , {\mathit{\delta }}_M)$ to denote the neighbor matrix of all vehicles in the region in a time slot. In addition to the neighbor vector, the available resources ${\mathit{c}}_i$ possessed by AVs and the task vector ${\mathit{s}}_i$ produced by vehicles need to be reported to the RSU in every time slot. Here, ${\mathit{s}}_i={(s_{i1},\cdot \cdot \cdot ,s_{iK})}^T$; $s_{iK}$ denotes the number of $K$-type tasks produced by AV $i$, and $\mathit{S}=({\mathit{s}}_1,\cdot \cdot \cdot ,{\mathit{s}}_M)$ denotes the task matrix of all vehicles in the region. These correspond to procedures 1–2 in the block diagram.
• Second, the RSU makes scheduling decisions according to the collected information $(\mathit{S}, \mathit{C}, \mathsf{\Delta })$ in a time slot and sends the results back to vehicles in the region. These correspond to procedures 3–5 in the block diagram.
• Finally, AVs conduct task offloading according to the decision result and report the task results to the RSU after completion for further acquisition of other vehicles. These correspond to procedures 6–8 in the block diagram.

Table 2. Main annotations used in the paper.

Term	Description
$M,ℳ$	Number and set of AVs in cooperative perception
$K, \mathcal{K}$	Number and set of task types
$R, ℛ$	Number and set of resource types
${\mathit{s}}_i, \mathit{S}$	Task request vector of vehicle $i$ and task request matrix of all AVs in a time slot
${\mathit{\omega }}_i, \mathit{W}$	Resource requirement vector of task type $i$, and the resource requirement matrix of all types of tasks
${\mathit{c}}_i, \mathit{C}$	Available resources of AV $i$ used in cooperative perception and those resources of all vehicles in a time slot
${\mathit{\delta }}_i, \mathsf{\Delta }$	Neighbor vector of AV $i$ and those of all vehicles
$x_i$	Decision variable of AV $i$, which indicates whether its tasks are completed with assistance from other vehicles. $x_i\in \{0,1\}$.
$y_{ijk}$	Latent decision variable of $k$-type tasks that are transmitted to AV $i$ from AV $j$ for execution.$y_{ijk}\in Z^{+}\cup \left\{0\right\}$.

summarizes the main annotations used in the paper.

3.2. Problem Formulation

Under the context of better resource utilization and achieving road safety improvement in our model, the more vehicles that accomplish sensing data processing tasks in a time slot, the more environmental information is acquired, and road safety is improved. However, because of the high spatial and temporal locality of environmental information, if most AVs can accomplish their tasks, the remaining AVs can still perceive the environment by the accomplished tasks in the proposed architecture. Therefore, we use the number of AVs that accomplish their tasks in a time slot to represent the degree of sensed environment information that can be obtained, and our aim is to maximize the number.

In a given time slot, for decision variable $x_i, i\in ℳ$ is used to denote whether tasks of AV $i$ can complete, $x_i=1$ represents that tasks of the AV $i$ are accomplished with assistance from neighbor vehicles or by itself. The latent variable $y_{ijk}$ denotes the number of $k$-type tasks that need to be offloaded by AV $j$ for execution on AV $i$.

The scheduling problem in a particular time slot is represented as follows.

$$\max {\displaystyle \sum _{i:i\in ℳ}{x}_i}$$

(1a)

$$s.t. s_{ik}\cdot x_i={\displaystyle \sum _{j:j\in ℳ}{y}_{jik}\cdot {\delta }_{ij}, \forall i\in ℳ,\forall k\in \mathcal{K}}$$

(1b)

$${\displaystyle \sum _{j:j\in ℳ}\sum _{j:j\in \mathcal{K}}{\delta }_{ij}\cdot y_{ijk}\cdot {\omega }_k^r\le c_i^r, \forall r\in \mathcal{R},\forall i\in \mathcal{M}}$$

(1c)

$$x_i\in \{0,1\}, y_{ijk}\in Z^{+}\cup \left\{0\right\}$$

(1d)

Formula (1b) represents the number of each type of task of AV $i, i\in ℳ$, whose tasks can be successfully accomplished with the assistance of other vehicles, and is equal to the number of tasks actually executed by its corresponding neighbors. Formula (1c) indicates that the resources’ occupation of all tasks executed on every AV cannot exceed the AV’s capacity for any type of resource. Formula (1d) indicates that the value of $x_i$ is 0 or 1 and that $y_{ijk}$ is a nonnegative integer.

Here, we give an example of task scheduling in the proposed model to illustrate the effectiveness induced by task offloading in the architecture, as shown in Figure 3. There are three participating AVs, and the resources possessed by the three are ${\mathit{c}}_1={(8, 11, 16)}^T$, ${\mathit{c}}_2={(2, 3, 4)}^T$ and ${\mathit{c}}_3={(2, 4, 5)}^T$. There are two types of tasks, and the resource requirements of each type of task are ${\mathit{\omega }}_1={(2, 3, 4)}^T$ and ${\mathit{\omega }}_2={(3, 4, 5)}^T$. The numbers of the two types of tasks produced by the three vehicles are ${\mathit{s}}_1={(1, 0)}^T$, ${\mathit{s}}_2={(1, 1)}^T$ and ${\mathit{s}}_3={(1, 1)}^T$. If no task scheduling is performed, the number of AVs whose produced tasks can be completed is one, i.e., AV 1. Data sensed by other vehicles cannot be processed in a timely manner, so valuable environmental information cannot be obtained by AV 1 from other AVs, which decreases road safety. With task scheduling in cooperative perception, task 2 of vehicles 2 and 3 can be assigned to vehicle 1 to execute so that all vehicles’ tasks can be accomplished in a timely manner; thus, road safety is improved.

3.3. Optimal Solution

Here, we give a brief discussion about the optimal solution. In fact, when there is only one type of resource and we ignore the difference in connectivity, the scheduling problem can be considered a multiple knapsack problem. It is strongly NP-hard according to paper [38]. We prove that the problem presented in Formula (1a) is NP-hard.

Proposition 1.

The multidimensional multitask multitarget task scheduling problem listed in Formula (1a) is NP-hard.

Proof. 

When there is only one type of resource in the architecture, the problem in Formula (1a) can be regarded as a multiple knapsack problem with assignment restriction (MKAS), i.e., participating AVs can be regarded as knapsacks in which resources possessed by AVs are the capacity of the knapsack; tasks produced by AVs are the items in which tasks produced by the same vehicle have the same assignment restriction and not for diverse vehicles. In the paper [38] by M. Dawande et al., the NP-hardness of MKAS was proven. In our research, we consider multidimensional resources, and MKAS can be reduced to our problem in Formula (1a). If there is a polynomial algorithm for our problem, MKAS can be solved in polynomial time. Therefore, the problem in Formula (1a) is NP-hard. □

It is very difficult to acquire an optimal result in an acceptable time, especially in the autonomous driving domain, because of its strict response time constraint when the number of participating AVs becomes large. Therefore, we design a heuristic algorithm to conduct task scheduling decisions. However, for small-scale simulation experiments, e.g., the number of AVs is relatively small, we can use some optimization tools, e.g., ILOG-CPLEX [39], to obtain the optimal result of the task scheduling decision with the purpose of maximizing the total number of vehicles whose tasks can be accomplished. ILOG-CPLEX is a tool to solve problems such as linear programming and constraint programming.

4. Two-Stage Heuristic Scheme (TSHS)

For the NP-hardness of the problem in Formula (1a), i.e., there has not yet been a polynomial algorithm, we instead propose a TSHS, which will be detailed in this section.

Two stages are included in the TSHS:

• Determination of the priority of participating AVs in cooperative perception. In this stage, the priority of AVs that need task scheduling is determined based on the status of the vehicles, e.g., produced tasks, available resources and neighbors.
• Determination of execution target vehicles of tasks produced by participating AVs. In this stage, target vehicles of tasks are determined, i.e., which neighbors hold that task is confirmed.

We introduce the highlighted ideas in the algorithm, detail the algorithm and finally present the proof of the algorithm approximation ratio and time complexity.

4.1. Highlighted Ideas

In the scheduling problem of Formula (1a), whether the vehicle accomplishes its tasks via other AVs should be determined. In addition, the target vehicle of each task should be determined. We design the TSHS as a two-stage algorithm based on the two goals. We introduce the highlighted ideas of the two stages in the TSHS.

4.1.1. Stage of Determination of AV Priorities

In this stage, the sequence of AVs to be scheduled is considered, i.e., the priority. In the problem in Formula (1a), the goal is maximizing the number of AVs that can complete their tasks. We start by analyzing the status of AVs and construct the criteria for determining the scheduling priority of AVs. We introduce the number of neighbors, the balance degree of the task and their impacts on the vehicle’s priority and then construct the formula of priority determination.

The number of neighbors (NoN): As mentioned above, the definition of a vehicle’s neighbors is a set of AVs with stable connections detected by vehicles at the beginning of a certain time slot. For AV $i, i\in ℳ$, we denote $h_i={\displaystyle \sum _{j\in ℳ\backslash \left\{i\right\}}} {\delta }_{ij}$ as its number of neighbors. The number is a property of a certain AV in a time slot, and it can determine the priority to a certain degree. Specifically, for two AVs $i, j\in ℳ, i\ne j$ with the same task requests, i.e., ${\mathit{s}}_i={\mathit{s}}_j$ if $h_i<h_j$, vehicle i should have higher priority than j because the selectivity of neighbors of vehicle i is small.

Here, we give an example to explain this. The tasks’ target vehicle is determined according to the fitness resource proposed in stage two. There are three Avs, 1, 2 and 3, and their resources are ${\mathit{c}}_1={(2, 3, 4)}^T$, ${\mathit{c}}_2={(3, 4, 5)}^T$ and ${\mathit{c}}_3={(5, 7, 9)}^T$, respectively. AVs generate two types of tasks. The resource requirements of the tasks are ${\mathit{\omega }}_1={(2, 3, 4)}^T$ and ${\mathit{\omega }}_2={(3, 4, 5)}^T$, and the task requests of the three are ${\mathit{s}}_1={(1, 1)}^T$, ${\mathit{s}}_2={(1, 1)}^T$ and ${\mathit{s}}_3={(0, 0)}^T$. Vehicles 1 and 3 only possess one neighbor, i.e., vehicle 2, and vehicle 2 possesses two neighbors, i.e., vehicles 1 and 3. If vehicle 2 offloads its tasks first, as shown in Figure 4a, the tasks of vehicle 2 will be partly offloaded to vehicle 1; finally, only vehicle 2 can complete its tasks. If vehicle 1, which possesses fewer neighbors, offloads its tasks first, as shown in Figure 4b, the tasks of vehicle 1 are partly offloaded to vehicle 2, and the tasks of vehicle 2 can be offloaded to vehicle 3. The number of vehicles whose tasks can be completed is two. Obviously, vehicles that possess fewer neighbors should have higher priority, and it is beneficial to improve the number of vehicles whose tasks can be completed.

Balance degree of resources (BDR): Different sensors in AVs generate diverse data, and the resource requirements of different data processing tasks are different. The resource requirements of tasks also impact the goal in Formula (1a). For a task of type $k,\forall k\in \mathcal{K}$, BDR is denoted as

$$B\left(k\right)=\left(\underset{r\in \mathcal{R}}{\max }{\mathit{\omega }}_k^r-\underset{r\in \mathcal{R}}{\min }{\omega }_k^r\right)/\underset{r\in \mathcal{R}}{\min }{\omega }_k^r$$

(2)

It is the maximal difference in dimensional resource requirements for a k-type task after normalization; a larger value indicates a greater imbalance. If there are many unbalanced tasks generated by a vehicle, the successful offloading of these tasks results in rapid exhaustion of a particular type of resource in the target vehicle. Finally, no more tasks can be completed, and the number of vehicles whose tasks can be completed declines.

We now provide an example to explain this. There are three AVs, AVs 1, 2 and 3. The resources they possess are ${\mathit{c}}_1={(2, 2, 2)}^T$, ${\mathit{c}}_2={(2, 3, 5)}^T$ and ${\mathit{c}}_3={(2, 3, 5)}^T$, and they are connected to each other. There are two types of tasks produced by the vehicle, i.e., ${\mathit{\omega }}_1={(1, 1, 1)}^T$ and ${\mathit{\omega }}_2={(1, 1, 5)}^T$, and the task requests of the three vehicles are ${\mathit{s}}_1={(0, 2)}^T$, ${\mathit{s}}_2={(2, 0)}^T$ and ${\mathit{s}}_3={(2, 0)}^T$. If vehicle 1 has higher $B(k)$ offloading first, its two tasks will execute on vehicles 2 and 3, which will exhaust the resources of type 3 possessed by vehicles 2 and 3, so the tasks of vehicles 2 and 3 cannot be completed. Then, the number of vehicles whose tasks can be completed is one. If vehicles 2 or 3, which possess relatively balanced tasks, offload first, their tasks can be completed. Then, the final number of vehicles whose tasks can be completed is two, which helps to improve road safety.

Vehicle priority determination: In addition to the above two factors, the total resource requirements of all tasks (RRAT) generated by an AV are also an important factor that influences the number of vehicles whose tasks can be completed. Under the condition that the total amount of resources owned by AVs in the region remains unchanged, the fewer the resources required by the task, the greater the number of completed tasks.

We design a formula of priority determination based on RRAT and BDR of the task and NoN, as shown in Formula (3),

$$d_i=\frac{1}{q(h_i)\cdot {\displaystyle \sum _{k\in \mathcal{K}}(g(B(k))\cdot s_{ik}{\displaystyle \sum _{r\in ℛ}{\omega }_k^r})}},\forall i\in ℳ$$

(3)

where $q(h_i)$ is the contribution function of the NoN, and $h_i$ is the number of neighbors of AV $i$. $g(B(k))$ is the contribution function of the BDR, and $B(k)$ is the BDR of the $k$-type task. The two functions are defined in Section 5, and they are both monotonically increasing functions. Formula (3) is a method of vehicle priority determination based on BDR, NoN and RRAT; the smaller $d_i$ is, the lower the priority.

4.1.2. Determination of the Target Vehicle of Tasks

We use resource fitness between tasks and vehicles for target vehicle determination. In the proposed model, an AV possesses $R$ types of resources and generates $K$ types of tasks that represent data processing from different sensors. Different task types $k, \forall k\in \mathcal{K}$ require different amounts of $R$-type resources, denoted by ${\mathit{\omega }}_k={({\omega }_k^1, {\omega }_k^2, \cdot \cdot \cdot , {\omega }_k^R)}^T$. An AV $i, i\in ℳ$ that needs task offloading, similar to paper [24], determines the target vehicle for its tasks based on the resource fitness of the task and vehicle. For a task of type $k\in \mathcal{K}$ and candidate of the target vehicle $j\in \left\{s\right|s\in ℳ, {\delta }_{ij}=1\}$, resource fitness $f(k,j)$ is denoted as

$$\begin{array}{ll}f(k,j)& ={\Vert {\mathit{c}}_j/c_j^1-{\mathit{\omega }}_k/{\omega }_k^1\Vert }_1 \\ & ={\displaystyle \sum _{r\in ℛ}\left|{\mathit{c}}_j^r/c_j^1-{\mathit{\omega }}_k^r/{\omega }_k^1\right|}\end{array}$$

(4)

A task of type $k$ will choose a vehicle with the smallest $f(k,j)$ from its neighbor set. The smaller $f(k,j)$ is, the higher the degree of consistency between the resource requirements of the task to be offloaded and the resources currently available on the target vehicle. This helps to reduce the resource fraction and waste.

4.2. Algorithm

In the proposed TSHS, there are two stages, as shown in Algorithm 1. (a) Determination of the priority of the vehicles that need task scheduling and formation of a priority list that will be used in stage two. (b) According to the input vehicles’ priority list, assess whether the vehicle can offload all its tasks to neighbors in turn. If so, the task selects the target vehicle according to the resource fitness based on the remaining resources of vehicles in the neighbor set, and the result is returned when all the vehicles are tested.

Algorithm 1$\mathrm{TSHS} (\mathit{S},\mathit{W},\mathbf{\Delta },\mathit{C})$
1:	$\mathit{x},\mathit{y},\mathbf{list}\leftarrow$$\mathrm{Vehicle}\_\mathrm{determination} ((\mathit{S},\mathit{W},\mathbf{\Delta },\mathit{C})$)
2:	$\mathit{x},\mathit{y}\leftarrow$$\mathrm{Task}\_\mathrm{schedule} ((\mathit{S},\mathit{W},\mathbf{\Delta },\mathit{C},\mathit{x},\mathit{y},\mathbf{list})$)
3:	/* schedule tasks from origin vehicle to target vehicle for execution */
4:	/* integrate results and transmit them to RSU */

Finally, every participating vehicle conducts offloading according to the decision result and sends the acquired environment information to the RSU for the acquisition of other vehicles after task completion. We detail the two algorithms in this section.

Vehicle_determination in TSHS is shown in Algorithm 2. There are four inputs, i.e., the task matrix of all vehicles $\mathit{S}$, resource requirement matrix of all task types $\mathit{W}$, neighbor matrix of all vehicles $\mathbf{\Delta }$ and available resource matrix $\mathit{C}$, and three outputs, i.e., decision variables $\mathit{x},\mathit{y}$ and the sorted list of vehicles that need task offloading based on priority. First, decision variables $\mathit{x},\mathit{y}$ are initialized: vehicles whose tasks can be completed by themselves directly execute their tasks, and vehicles whose tasks cannot be completed by themselves are stored in set ${ℳ}_{mid}$ (lines 1–7). Then, the algorithm sorts vehicles in ${ℳ}_{mid}$ in ascending order based on priority, which is calculated by Formula (3). A vehicle at the front of ${ℳ}_{mid}$ is higher in $d_i$, which means the vehicle has higher priority considering NoN, BDR and RRAT, and it will offload its tasks prior to other vehicles with lower priority in the Task_schedule algorithm. Finally, the algorithm returns the decision vector $\mathit{x},\mathit{y}$, which is a partly modified and sorted list of AVs that need task scheduling.

Algorithm 2$\mathrm{Vehicle}\_\mathrm{determination} ((\mathit{S},\mathit{W},\mathbf{\Delta },\mathit{C})$)
1:	$\mathit{x}\leftarrow 0,\mathit{y}\leftarrow 0$
2:	$\mathrm{for} \mathrm{each} i\in ℳ$:
3:	$\mathrm{if} {\displaystyle \sum _{k\in \mathcal{K}}{s}_{ki}{\omega }_k^r\le c_i^r,\forall r\in ℛ}$:
4:	$c_i^r\leftarrow c_i^r-{\displaystyle \sum _{k\in \mathcal{K}}{s}_{ik}{\omega }_k^r,\forall r\in ℛ}$
5:	$x_i\leftarrow 1$
6:	$y_{\mathit{ijk}}\leftarrow s_{\mathit{ik}}$
7:	${\mathcal{M}}_{\mathit{mid}}\leftarrow \mathcal{M}\backslash \left\{i\right\}$
8:	$\mathrm{for} \mathrm{each} i\in {ℳ}_{mid}$:
9:	$d_i=\frac{1}{q(h_i)\cdot {\displaystyle \sum _{k\in \mathcal{K}}(g(B(k))\cdot s_{ik}{\displaystyle \sum _{r\in ℛ}{\omega }_k^r})}}$
10:	sort ${\mathcal{M}}_{\mathit{mid}}$ in decreasing order of di
11:	return $\mathit{x},\mathit{y},{\mathcal{M}}_{\mathit{mid}}$

Task_schedule is shown in Algorithm 3. In addition to inputs S, W, Δ, C, which are the same as those for Vehicle_determination, the outputs of Vehicle_determination are input into Task_schedule. The outputs of the algorithm are a list of AVs and whether their tasks can be completed, i.e., decision vector x, and the target vehicles of tasks, i.e., latent decision vector y. First, the algorithm selects vehicles from list one by one, sets a success_flag and backs up the decision vector y and available resource matrix C, which are utilized for restoration when offloading fails (lines 1–4). For tasks of type k, the algorithm calculates the resource fitness of other AVs and sorts the AVs in ascending order of resource fitness. Then, for every task of the same type, the algorithm chooses the vehicle with the lowest resource fitness and checks whether the available resources of the vehicle are sufficient for the task and whether the vehicles are mutual neighbors. If these conditions are satisfied, the latent decision vector y and available resource matrix C of the target vehicle are modified, the resource fitness between the type and target vehicle is recalculated, and the vehicle is inserted into the vehicle list according to the new resource fitness. This process is iterated until all tasks are scheduled (lines 5–16). If there is a task that cannot be assigned to any vehicle, y and C are restored using backups (lines 17–19). In the algorithm, we set success_flag to examine the failure of any task scheduling decision: it is set as False when a task is starting, which denotes that no target vehicle is appropriate for the task. If an appropriate target vehicle is available, success_flag is set to True. All decision loops are aborted for a vehicle if any task cannot be offloaded to another vehicle (line 5, lines 17–22). Finally, decision variable $\mathit{x}$ is also modified according to the value of success_flag, and decision variable $\mathit{x}$ corresponding to a vehicle is set to 1 if success_flag is True; otherwise, it is set to 0.

Algorithm 3$\mathrm{Task}\_\mathrm{schedule} ((\mathit{S},\mathit{W},\mathbf{\Delta },\mathit{C},\mathit{x},\mathit{y},\mathbf{list})$)
1:	$\mathrm{for} \mathrm{each} i\in \mathbf{list}$:
2:	$\mathrm{success}\_\mathrm{flag} \leftarrow$ True
3:	$\mathit{y}\prime \leftarrow \mathit{y}$
4:	$\mathit{C}\prime \leftarrow \mathit{C}$
5:	$\mathrm{for} \mathrm{each} k\in \mathcal{K}$:
6:	$\mathrm{sort} j\in ℳ$$\mathrm{in} \mathrm{increasing} \mathrm{order} \mathrm{of} f\left(k,j\right)$
7:	for each $m\in 1,\cdot \cdot \cdot ,s_{ik}$:
8:	$\mathrm{success}\_\mathrm{flag} \leftarrow$ False
9:	for each $j\in ℳ$:
10:	$\mathrm{if}{c}_j^r\ge {\omega }_k^r$$\mathrm{and} {\delta }_{ij}=1,\forall r\in ℛ$ :
11:	$y_{jik}\leftarrow y_{jik}+1$
12:	$c_j^r\leftarrow c_j^r-{\omega }_k^r,\forall r\in ℛ$
13:	$\mathrm{recalculate} f(k,j)$
14:	$\mathrm{resort} ℳ \mathrm{in} \mathrm{increasing} \mathrm{order} \mathrm{of} \mathrm{recalculate} f(k,j)$
15:	success_flag ← True
16:	break
17:	if success_flag = False:
18:	$\mathit{y}\leftarrow \mathit{y}\prime$
19:	$\mathit{C}\leftarrow \mathit{C}\prime$
20:	break
21:	if success_flag = False:
22:	break
23:	if success_flag = True:
24:	$x_i=1$
25:	else:
26:	$x_i=0$
27:	$\mathrm{return}\mathit{x},\mathit{y}$

4.3. Properties

We now detail some properties of the TSHS.

Theorem 1.

The TSHS algorithm is a $p_{\min }/(p_{\max }M)$approximate algorithm, in which $p_{\min }={\min }_{i\in ℳ}{p}_i$, $p_{\max }={\max }_{i\in ℳ}{p}_i$and$M$is the number of participating vehicles in cooperative perception. $p_i=q\left(h_i\right)·{\displaystyle \sum _{k\in \mathcal{K}}}\left(g\left(B\left(k\right)\right)·s_{\mathit{ik}}{\displaystyle \sum _{r\in \mathcal{R}}}{\omega }_k^r\right)$.

Proof. 

Let ${\mathcal{W}}_{opt}$ be the set of AVs whose tasks can be completely generated by the optimal algorithm; let $OPT$ denote the number of vehicles in the set, $OPT={\displaystyle \sum _{i\in {\mathcal{W}}_{OPT}}1}$. Let ${\mathcal{W}}_{TSHS}$ be the set of AVs whose tasks can be completely generated by the TSHS algorithm, and let $TS$ denote the number of vehicles in the set, $TS={\displaystyle \sum _{i\in {\mathcal{W}}_{TSHS}}1}$. We need to prove $\alpha \cdot OPT\le TS$, where $\alpha$ is the approximate ratio of TSHS. If the same vehicles are in sets ${\mathcal{W}}_{opt}$ and ${\mathcal{W}}_{TSHS}$, we can remove these vehicles from both sets, and the proof of the approximate ratio of the TSHS is not affected.

First, we consider $TS$,

$$\begin{array}{ll}TS& ={\displaystyle \sum _{i\in {\mathcal{W}}_{TSHS}}1}\\ & ={\displaystyle \sum _{i\in {\mathcal{W}}_{TSHS}}{p}_i{d}_i}\\ & \ge p_{\min }{\displaystyle \sum _{i\in {\mathcal{W}}_{TSHS}}{}_i{d}_i}\end{array}$$

(5)

where the second equality follows from vehicle priority Formula (3), and it is obvious that the third inequality holds.

Second, for $OPT$,

$$\begin{array}{ll}OPT& ={\displaystyle \sum _{i\in {\mathcal{W}}_{OPT}}1}\\ & ={\displaystyle \sum _{i\in {\mathcal{W}}_{OPT}}{p}_i{d}_i}\\ & \le p_{\max }{\displaystyle \sum _{i\in {\mathcal{W}}_{OPT}}{d}_i}\end{array}$$

(6)

where, similar to Formula (5), the second equality follows from vehicle priority Formula (3), and it is also obvious that the third inequality holds.

Notably, there are no common vehicles in the sets ${\mathcal{W}}_{opt}$ and ${\mathcal{W}}_{TSHS}$. Thus, for any vehicle $i,i\in {\mathcal{W}}_{OPT}$ that acquires resources from its neighbors, some parts of the resources are allocated to vehicle $j,j\in {\mathcal{W}}_{TSHS}$, and we have $d_j\ge d_i$ in the TSHS; otherwise, vehicle should be in ${\mathcal{W}}_{TSHS}$.

Let ${\mathcal{OP}}_j$ be a subset of ${\mathcal{W}}_{opt}$ that includes vehicles whose requested resources are partly assigned to vehicle $j,j\in {\mathcal{W}}_{TSHS}$, and $d_j\ge d_i$, $\forall i\in {\mathcal{OP}}_j$. ${\mathcal{OP}}_j$ is a subset of ${\mathcal{W}}_{opt}$ relating to vehicle $j$, in which the requested resources of these vehicles can be assigned to at most $M$ other vehicles. Therefore:

$${\displaystyle \sum _{i\in {\mathcal{OP}}_j}}{d}_i\le {\displaystyle \sum _{i\in {\mathcal{OP}}_j}}{d}_j\le d_j\left|{\mathcal{OP}}_j\right|\le {\mathit{Md}}_j$$

(7)

Because ${\mathcal{OP}}_j$ is a part of ${\mathcal{W}}_{opt}$ and ${\mathcal{W}}_{opt}={\cup }_{j\in W_{TSHS}}{\mathcal{OP}}_j$, we have:

$${\displaystyle \sum _{i\in {\mathcal{W}}_{OPT}}}{d}_i\le {\displaystyle \sum _{j\in {\mathcal{W}}_{TSHS}}}{\displaystyle \sum _{i\in {\mathcal{OP}}_j}}{d}_i\le M{\displaystyle \sum _{i\in {\mathcal{W}}_{TSHS}}}{d}_j$$

(8)

Thus, we have

$$\begin{array}{ll}OPT& \le p_{\max }{\displaystyle \sum _{i\in {\mathcal{W}}_{OPT}}{d}_i}\\ & \le p_{\max }M{\displaystyle \sum _{j\in {\mathcal{W}}_{TSHS}}{d}_j}\\ & \le TS(p_{\max }/p_{\min })M\\ & TS\ge (p_{\min }/p_{\max }M)OPT\end{array}$$

where the first inequality follows from Formula (6), the second formula follows from Formula (8) and the third follows from Formula (5). Therefore, TSHS is a $(p_{\min }/p_{\max }M)$ algorithm. □

Theorem 2.

The time complexity of TSHS is polynomial.

Proof. 

The TSHS algorithm consists of Vehicle_determination and Task_schedule. In our analysis, we regard the number of task types $K$ and resource types $R$ as constants whose values are unknown, and we analyze the impact of the number of participating vehicles on the time complexity. For the Vehicle_determination algorithm, the process of excluding vehicles whose tasks can be completed by themselves involves search and delete operations; it consumes $O(\log M)$ by binary search, and the whole process consumes $O(M\log M)$. The calculation of vehicle priority and sorting consumes at least $O(M\log M)$; therefore, the time complexity of Vehicle_determination is $O(M\log M)$. For Task_schedule, although there are four-layer loops, only two of the four loops involve the number of vehicles (innermost and outermost loops). In the innermost loop, insertion consumes $O(\log M)$ (binary insertion algorithm), and all four loops consume $O(M^2\log M)$, which is the same as the time complexity $O(M^2\log M)$ of sorting in line 6; therefore, the time complexity of Task_schedule is $O(M^2\log M)$. Thus, the TSHS consumes $O(M^2\log M)$, and the time complexity of the TSHS is polynomial. □

5. Experiment and Discussion

In this section, we use a generated dataset to simulate task scheduling in the proposed architecture for cooperative perception and compare the results with FirstMatch and the optimal algorithm. The optimal algorithm is designed with CPLEX tools, which can be used to solve the constraint optimization problem. The simulation platform environment uses Python in PyCharm. The code is run on a machine with a 2.90 GHz Intel (R) Core (TM) i5-9400 CPU and 16 GB RAM.

5.1. Experimental Setup

Due to the lack of a standard dataset for task scheduling in cooperative perception, we generate a dataset for simulation. According to the proposed model in Section 3 and the proposed architecture in Section 4, four types of data need to be generated, i.e., the task request matrix of all AVs $\mathit{S}$, the resource requirement matrix of all types of tasks $\mathit{W}$, the available resources of all AVs $\mathit{C}$ and the neighbor vector of all vehicles $\mathbf{\Delta }$. Because the proposed architecture is time slot-based, we need to generate the data used for task scheduling in a time slot. We can regard the participating AVs as a cluster. For simplicity, we refer to the number of participating AVs as the cluster scale, and we use these two terms interchangeably.

To make the generated dataset more convincing, we analyze some real conditions in cooperative perception and VEC and set rules to generate the dataset according to the analysis. Because AVs need to process tasks related to cooperative perception, there are three types of resources possessed by participating AVs. We can assign different units for these resources, i.e., 1 core for CPU, 128 MB for RAM and 256 MB for DISK capability, which are used to quantify the number of generated resources. This is only one of the possible assignments of the unit.

• For all participating AVs, three types of resources are needed. Although some mainstream AVs can possess 30 CPU cores or more, utilizing parts of cores to conduct cooperative perception is more rational because of the unreliability of communication and the demands of other users’ and AV applications. The available resources of different vehicles should be diverse because of price differences. We can divide participating vehicles into high-level vehicles and medium-level vehicles. Furthermore, the available number of CPU cores of AVs at the same level could be slightly different due to different users’ habits. We set the resource domains of the three types of resources to (7–10, 37–43, 58–64) for high-level vehicles and (4–6, 18–23, 28–32) for medium-level vehicles: an AVs’ possessed available resources are randomly generated from the domain’s scope based on its level. The randomness reflects the fact that the available resources of different vehicles of the same level can still be slightly different. Meanwhile, the fact that the number of high-level vehicles is less than the number of medium-level vehicles needs to be considered, and the ratio is set to 30%.
• As stated in Section 1, cameras, LiDAR and radar can be installed on AVs for environmental perception, and the resource requirements corresponding to the LiDAR, camera and radar data processing tasks are different. We can regard them as different tasks. For a more realistic scenario, we consider three types of tasks that can be profiled by a triple tuple. The needed CPU cores of a task are determined according to its corresponding sensors’ data production rate in our paper, i.e., the larger the data production rate is, the more CPU cores used to process those data are needed. The resource requirements corresponding to the LiDAR, camera and radar data processing tasks are ${\mathit{\omega }}_1={(3, 16, 10)}^T$, ${\mathit{\omega }}_2={(2, 10, 8)}^T$ and ${\mathit{\omega }}_3={(1, 3, 4)}^T$, respectively. The settings of the three types of profiles mainly consider the relationship of the resource requirements among the tasks from LiDAR, cameras and radar and the maximum number of CPU cores of an AV. The absolute resource requirement of each task is related to the specific machine and the length of the time slot, which are not considered in this paper. There are indeed more specific and scientific descriptions for tasks’ computation intensity, e.g., the amount of computation, latency/energy consumption for finishing a workload or needed instruction cycles of CPU. For simplicity and ease of calculation, we define the resource requirement of tasks (computationally intensive) as a triple tuple that includes the number of CPU cores. We assume that every CPU core needed by a task runs with full loads in our model.
• Neighbors are determined by sending detection packets by V2V links (DSRC). The results of neighbor detection can be represented by a neighbor vector. We can generate these neighbor vectors. Two facts should be considered. First, a vehicle cannot connect to too many other vehicles. Second, the distribution of AV numbers of neighbors is almost normal distribution. We set the generating rules as follows: An AV should have at least two neighbors. The number of participating vehicles is referred to as the cluster scale, and the two terms are used interchangeably. When the scale is 5–10, an AV can have up to five neighbors; when the scale is 10–20, the maximum number of neighbors of the AV is half of the scale; and when the scale exceeds 20, the maximum number of neighbors is 10. The number of neighbors of each vehicle is randomly chosen between the maximum and minimum values according to a normal distribution.
• Determining the number of every vehicle’s generated tasks is slightly complex. For participating vehicles, the distribution of the proportion of the number of AVs whose available resources cannot meet the requirement of tasks generated by themselves to the total number of participating vehicles is unknown. We assume that the probability of every proportion is the same. We use the resource satisfaction degree (RSD), i.e., the proportion of vehicles whose tasks can be completed by themselves, in the cluster to denote the distribution in a discrete manner. The value of RSD ranges from 90% to 10%. For a particular value of RSD, we randomly generate task requests of each AV, which guarantees that the proportion of vehicles whose tasks can be completed by itself in the cluster is equal to the value of RSD. Each RSD value of each cluster scale generates 25 groups of data, and each group contains the task requests of each participating vehicle in cooperative perception.

Based on the above rules, we generate a dataset that contains the needed data of task scheduling determination in the cluster scale from 5 to 50. Theoretically, in a particular region, the minimum number of participating vehicles is 0, and the maximum number of participating vehicles depends on many factors, e.g., the size of vehicles and the capability of communication devices. The size of vehicles determines the maximum number of vehicles existing in the physical space of the region. The capability of communication devices determines how many existing vehicles in the region can be serviced by communication devices to participate in cooperative perception. We use $M_{\max }$ to denote the maximum number of participating vehicles. In reality, the actual number of participating vehicles is between 0 and $M_{\max }$, and it could obey some kind of probability distribution, e.g., normal distribution. Investigating the relation between region size and the number of participating vehicles (which probability distribution) is indeed an interesting and important topic, but it is not our main concern of this paper. Therefore, we generate a dataset from 5–50 to simulate these possible cluster scales. We use the generated dataset to simulate the task scheduling of a time slot at different scales and analyze the performance of TSHS by comparison with FirstMatch and Optimal. Function $q(h_i)=\lg (h_i+9)$ in Formula (3) denotes the degree of contribution of vehicle neighbors; $g(B(k))={1.2}^{B(k)}$ denotes the degree of contribution of the balance degree. We choose one from many other choices, and the chosen two functions have shown good performance in simulation. This paper did not conduct additional research on the selection of the two functions, which will be included in our future work.

For a better understanding, the structure and content of the dataset are illustrated in Figure 5. For example, there are vehicle connectivity, available resources and task requests in nine RSDs when the cluster scale is 5. We can use the neighbor vector, available resources and 25 groups of task requests in different RSDs to synthesize 255 groups of data, which can denote task requests under different vehicle loads in a time slot. The data of other cluster scales can be synthesized in the same way.

Based on the generated dataset, we compare the TSHS with two other algorithms:

• Optimal: optimal tasks scheduling scheme, which is solved by CPLEX.
• FirstMatch (FM): Vehicles are numbered starting from 0, and FM selects vehicles in order from small to large for task scheduling determination. For the selected vehicle, a neighbor is also selected from the neighbor set according to the number from small to large, and as many tasks as possible are scheduled. If the vehicle cannot schedule its tasks in this way, it fails; otherwise, it succeeds.

5.2. Results and Discussion

5.2.1. Performance over Time

Before comparing the time performance of different scheduling algorithms, we first analyze the ratio of successful computations of the three algorithms in the simulation. A task scheduling decision is regarded as successful when it can be determined in an hour, and a long determination time is not sufficient because of the real-time and mobility requirements in the autonomous driving domain. Figure 6 illustrates the successful computation ratio of all simulations (a total of 255 in a scale) for three different algorithms under various cluster scales. The successful computation ratio of TSHS and FM is always 100% with the increasing cluster scale, but it declines with the increasing cluster scale for the optimal algorithm. When the cluster scale is 11, only 80% of the simulations can be completed within a fixed time. To detail the impact of RSD on the successful computation ratio, Figure 7 illustrates the successful computation ratio of the optimal algorithm along with the decrease in RSD under different cluster scales. The ratio of successful computation decreases rapidly with the increase in RSD when the cluster scale is large. Thus, the optimal offloading result cannot be acquired within a short period when the cluster scale is large, especially for vehicles in clusters with heavy loads. On the other hand, the TSHS can still acquire a good scheduling scheme within a short period.

Figure 8 illustrates the mean time consumption for acquiring results with different algorithms when the cluster scale changes, in which blue denotes optimal, red denotes the TSHS and green denotes FM. The mean time of each cluster scale is the mean value of the times of all RSDs, which denotes the average performance of the algorithm under different cluster loads. The time of each RSD is calculated by averaging the values of its 25 simulations to reduce the influence of randomness on the analysis. The optimal time increases rapidly with increasing cluster scale. Because of the long running time of the optimal algorithm, we conduct simulations using the optimal algorithm when the cluster scale is less than 12. The optimal algorithm is aborted because of memory overflow or cannot finish because of a very long execution time. Therefore, the blue bars are missing when there is a large number of participating vehicles. On the other hand, the running time of the TSHS is much less than optimal and does not increase significantly with increasing cluster scale. The TSHS is also better than FM in the simulation. Therefore, the proposed TSHS has good time performance and can be used when the cluster scale is large.

5.2.2. Improvement in Road Safety in the VEC-Based Architecture with Scheduling

First, we compare the average number of vehicles whose tasks can be completed in cooperative perception using the TSHS, FM and optimal when the cluster scale changes between 5 and 11, as shown in Figure 9. As above, the number of vehicles whose tasks can be completed in each cluster scale is derived by averaging the numbers of all RSDs of the scale, which denotes the mean performance of the algorithms under different cluster loads. The number of each RSD is calculated by averaging the numbers of its 25 simulations, which reduces the influence of randomness on the analysis. In Figure 9, red denotes the TSHS algorithm, green denotes FM and blue denotes the optimal algorithm. The difference between the TSHS and the optimal algorithm does not increase significantly as the scale increases, and the TSHS outperforms FM.

Figure 10 illustrates the average number of vehicles whose tasks can be completed under different RSDs, where green, red and blue indicate cooperative perception using FM, the TSHS and without offloading, respectively. The number decreases linearly with the decrease in the RSD without offloading, and a few vehicles can still complete their tasks by scheduling in the architecture with the TSHS, even under a larger cluster scale and heavy cluster load. At least 55% of vehicles in a cluster can complete their tasks with the TSHS, even when the RSD of a cluster is 10%. Although there is no significant difference between FM and the TSHS when the RSD is large, the TSHS is much better than FM when the RSD is lower because the property of neighbors is considered in TSHS. Therefore, the proposed TSHS can improve the number of vehicles whose tasks can be completed in cooperative perception, especially under heavy cluster loads, which means that road safety is improved by utilizing the resources of connected vehicles in a better way.

5.2.3. Resource Utilization

Finally, we compare the average resource utilization of the TSHS, FM and the optimal algorithm under different cluster scales. The CPU utilization is the proportion of the number of used CPU cores to the number of total CPU cores. Similarly, the average resource utilization is calculated by averaging the value of all RSDs of a cluster scale. As shown in Figure 11, although there is a gap between the TSHS and optimal, it is not large, and the TSHS outperforms FM. Considering the time consumed for acquiring g results, the TSHS is still a good algorithm.

6. Conclusions

In this paper, we propose a hybrid VEC-based architecture to improve the utilization of AVs for better cooperative perception and investigate the key task scheduling problem. It is modeled as a multidimensional multitask multitarget task scheduling problem with assignment restrictions. We prove its NP-hardness and propose a heuristic scheme (TSHS) to solve the problem. Substantial experiments show that the proposed TSHS is close to optimal, and at least 55% of vehicles in a cluster can complete their tasks based on our dataset, even under heavy cluster loads. Moreover, the fast running time of the TSHS is suitable for the autonomous domain. However, only one-hop offloading and a single RSU are considered in our paper, and multihop and multi-RSU collaboration will be considered in future papers. Second, designing a fair scheduling policy according to the contributions of participating AVs is also a promising direction. Third, our proposed architecture for cooperative perception does not consider the impact of communication, which is very important for cooperative perception in reality. Communication is the basis for realizing a cooperative, and its reliability directly impacts AV safety on the road, especially when high channel loads and packet collisions occur. Furthermore, the sync overhead is considerable and critical for driving safety, which means the tradeoff of gains and loss of sync should be concerned. These questions should receive deeper research.