SYSTEM AND METHOD FOR OUTPATIENT DRIVING TASKS

Abstract

A system and procedure for offloading autonomous driving tasks is provided. The system comprises: The multiple compute nodes include one or more compute nodes on the vehicle, one or more compute nodes in edge devices, and one or more compute nodes in cloud devices. The system also includes a creation module designed to create a system model that includes the communication delay between all pairs of compute nodes within the multiple compute nodes. The system further includes an allocation module configured, based on the system model, to allocate the multiple autonomous driving tasks of the autonomous driving service to offload each autonomous driving task to one of the multiple compute nodes, with the allocation minimizing the end-to-end delay of the autonomous driving service.

Description

FIELD OF THE INVENTION

[0001] The present invention relates to a system and method for outsourcing autonomous driving tasks. STATE OF THE ART

[0002] With the rapid development of the digital economy, intelligent connected vehicles (ICVs) have become a key trend for innovative development in the automotive industry. As one of the key technical pathways for intelligent connected vehicles, the Vehicle-Road-Cloud collaborative ecosystem has received considerable attention in recent years.

[0003] Autonomous driving services (autonomous driving functions) encompass a range of data processing tasks such as sensing, prediction, decision-making, and control. These tasks often include computationally intensive tasks that require high consumption of computing resources. If these tasks are performed solely on-board, the vehicle must be equipped with powerful sensors and computing chips, which significantly increases the vehicle's cost.

[0004] The current state of the art involves offloading computing tasks from vehicles to the edge or the cloud, thereby transforming the intelligence of a single vehicle into a collaborative effort between the vehicle, the road, or between the edge and the cloud in autonomous driving services. Literature already exists on the use of mathematical models or deep reinforcement learning to make decisions about task offloading. However, previous research has primarily focused on scenarios supporting edge applications, such as IoT applications, smart city applications, etc. Currently, there is no better solution within existing technologies for offloading autonomous driving tasks across three layers (i.e., the intelligent vehicle layer, the edge computing layer, and the cloud computing layer). REVELATION OF THE INVENTION

[0005] In view of the aforementioned problems according to the prior art, one aspect of the present invention is to provide a system for offloading autonomous driving tasks, comprising: multiple compute nodes, including one or more compute nodes in the vehicle, one or more compute nodes in edge devices, and one or more compute nodes in cloud devices; a creation module designed to create a system model, comprising communication delays between all pairs of compute nodes of the multiple compute nodes; and an allocation module configured, based on the system model, to allocate the multiple autonomous driving tasks of the autonomous driving service in order to offload each autonomous driving task to one of the multiple compute nodes, wherein the allocation minimizes the end-to-end delay of the autonomous driving service;

[0006] Another aspect of the present invention provides a method for offloading autonomous driving tasks, comprising: creating a system model that includes the communication delays between each pair of compute nodes of the multiple compute nodes. The multiple compute nodes include one or more compute nodes in the vehicle, one or more compute nodes in edge devices, and one or more compute nodes in cloud devices; and assigning multiple autonomous driving tasks of an autonomous driving service based on the system model to offload the respective autonomous driving task to one of the multiple compute nodes, wherein the assignment minimizes the end-to-end delay time of the autonomous driving service.

[0007] According to another aspect of the present invention, a machine-readable storage medium is provided which stores executable instructions which, when executed, carry out the method by one or more processors.

[0008] It should be noted that the preceding brief summary of the main aspects of the present invention was given to provide a basic understanding of these aspects. This summary is not intended to describe central or important elements of all aspects or to define the scope of some or all aspects. This summary is meant to present some embodiments of these aspects in simplified form and to serve as an introduction to the subsequent detailed description. DESCRIPTION OF THE FIGURES

[0009] The aspects revealed are described below in conjunction with the figures provided for illustration, but not to limit, the aspects revealed. Fig. 1 is a schematic block diagram of a system for outsourcing autonomous driving tasks according to an embodiment of the present invention; Fig. 2 shows an example of the system of Fig. 1. Fig. Figure 3 shows a flowchart of a method for outsourcing autonomous driving tasks according to an embodiment of the present invention. Fig. Figure 4 shows an example of the service dependency model. Fig. Figure 5 shows an example of a computing resource model. Fig. Figure 6 shows an example of outsourcing autonomous driving tasks based on the model in the Fig. 4 and Fig. 5. DETAILED DESCRIPTION OF THE EXECUTION FORM SUMMARY

[0010] Embodiments of the present invention relate to methods and systems for offloading autonomous driving tasks that offload multiple tasks (AD tasks) of autonomous driving services to multiple computing nodes under an on-vehicle cloud architecture.

[0011] According to one embodiment of the present invention, resource constraints and factors related to the heterogeneity of safety level requirements for different AD tasks are taken into account when determining the allocation strategy. Therefore, the system and method for outsourcing tasks according to the embodiments of the present invention can meet the safety requirements of autonomous driving applications.

[0012] According to one embodiment of the present invention, the service dependency model represents the dependencies of several AD tasks of the autonomous driving service and has multiple root nodes, meaning that the autonomous driving service has multiple data sources. These multiple data sources can be data sources from the vehicle, data sources from the roadside, and data sources from the cloud. The multiple data sources can also be multiple sensor data sources from multimodal sensors. This is particularly attractive for collaborative ecosystem applications of intelligent connected vehicles.

[0013] Even if there are secure and insecure hardware devices under the vehicle-side cloud architecture in embodiments of the present invention, important AD tasks can be offloaded to hardware devices with a high level of security, thereby ensuring the security of autonomous driving services.

[0014] While simultaneously meeting the software security requirements, the AD task offloading scheme according to embodiments of the present invention is able to consider the heterogeneity between the hardware devices and the software as well as the dependencies between AD tasks and minimize the end-to-end delay of the autonomous driving service.

[0015] For example, the offloading solution according to the embodiment of the present invention can be implemented online based on real-time measurement results without relying on previous data. Example system

[0016] The specific embodiments of the present invention are presented below in conjunction with the accompanying figures.

[0017] Fig. Figure 1 shows a system 100 (hereinafter referred to as system 100) for outsourcing autonomous driving tasks (AD tasks) according to an embodiment of the present invention. In the embodiment of the present invention, the system 100 can be understood as a collaborative intelligent vehicle ecosystem based on the architecture of a vehicle-side cloud (sometimes also called a vehicle-road cloud).

[0018] As in Fig. As shown in Figure 1, the system 100 includes a plurality of compute nodes 11-16, a creation module 20, and an allocation module 30. These compute nodes 11-16 are capable of communicating with each other. The compute nodes 11-16 include one or more vehicle nodes located in the vehicle, one or more edge nodes located in edge devices, and one or more cloud nodes located in cloud devices. The creation module 20 creates a system model based on the properties of the software and hardware. The system model includes, for example, a service dependency model representing AD task dependencies and a compute resource model representing the available compute resources of compute nodes.The allocation module 30 assigns one or more AD tasks to one or more of these compute nodes 11-16 using the created system model, thus minimizing the end-to-end latency of the autonomous driving service associated with the one or more AD tasks; furthermore, the required security level of each AD task is adapted to the security level of the compute node to which it is offloaded, for example, the security level of the offloaded compute node is not lower than the security level required by the AD task; in addition, AD tasks are offloaded to compute nodes that are adjacent to upstream or downstream compute nodes on which they are highly dependent.

[0019] In one embodiment, the creation module 20 can be located on one of the multiple compute nodes 11-16. The creation module 20 can also be located on a platform workspace independent of the system 100 and communicatively connected to the system 100 (e.g., a central controller in a centralized system architecture). Similarly, the allocation module 30 can be located on one of the multiple compute nodes. The allocation module 30 can also be located on a platform workspace independent of the system 100 and communicatively connected to the system 100 (e.g., a central controller in a centralized system architecture).

[0020] The creation module 20 and the assignment module 30 can be implemented using hardware or software, or a combination of software and hardware. The hardware implementation can be in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, control units, microcontrollers, microprocessors, electronic units for performing their functions, or a combination thereof. Parts implemented in software can be executed using microcode, program code, or code segments and can also be stored in a machine-readable storage medium, e.g., a memory component.

[0021] The naming of the creation module 20 and the allocation module 30 should be understood as a logical (functional) description and not as a restriction of the physical form or arrangement. They can be further subdivided into several submodules depending on their functionality. The creation module 20 and the allocation module 30 can be implemented on the same chip or circuit, or they can be implemented on different chips or circuits.

[0022] The term "autonomous driving service" can refer to an autonomous driving function that may include one or more AD tasks. For example, lane keeping assist is an autonomous driving function that can include three AD tasks: lane detection, route monitoring, and route correction. "The end-to-end delay of the autonomous driving service is minimal" means the shortest time to complete the autonomous driving service. This means that the time from the signal flow in the input source nodes to the signal flow to the final computing node is minimal. In one embodiment, destination detection is performed on the roadside, the destination detection results are processed in the cloud, and the processing results are finally sent to the vehicle.In this example, “minimal end-to-end delay of the autonomous driving service” refers to the time it takes for the signal to travel from the first computing node (the device that performs the destination recognition on the road side) to the last computing node (the vehicle).

[0023] Fig. Figure 2 shows an embodiment of system 100 in Fig. 1 under the vehicle-side cloud architecture. As in Fig. As shown in Figure 2, the multiple compute nodes in the intelligent vehicle layer comprise compute nodes distributed across the intelligent vehicle layer (IV: Intelligent vehicles, hereinafter sometimes referred to as the vehicle layer), compute nodes located in the edge computing layer (ECL: Edged computing layer, hereinafter sometimes also referred to as the edge layer), and compute nodes located in the cloud computing layer (CCL: Cloud computing layer, hereinafter sometimes also referred to as the cloud). For example, compute nodes N1 and N2 are located on intelligent vehicles in the intelligent vehicle layer, compute nodes N3-N5 are located on edge computing devices in the edge computing layer, and compute node N6 is located on a cloud server in the cloud computing layer. The create module 20 and the assign module 30 are located on the same edge computing device in the edge computing layer.

[0024] It goes without saying that Fig. Figure 2 shows only one example of the arrangement of the compute nodes, the creation modules and the allocation modules of System 100, and that they can also be arranged in other ways. Vehicle-side cloud architecture

[0025] The following describes the characteristics of each of the three levels of the vehicle-side cloud architecture. The characteristics of each level also apply to the compute nodes placed at that level.

[0026] The intelligent vehicle level comprises multiple intelligent vehicles. Computing nodes located within intelligent vehicles can include embedded high-performance systems and onboard sensing systems (e.g., lidar, webcams, and high-precision maps). Intelligent vehicles can communicate with other vehicles via V2V (vehicle-to-vehicle) and also with roadside infrastructure or cloud servers via V2X (vehicle-to-everything).

[0027] The edge computing layer comprises multiple edge computing devices. Edge computing devices can include roadside computing units, base stations, mobile edge computing (MEC), and edge servers. These edge devices can have different architectures and resource capacities and be geographically dispersed. In one embodiment, the edge computing device and the intelligent vehicle are located on the same intranet (intranet), ensuring sufficient bandwidth resources between them. The edge server can have a predetermined computing power and storage capacity, allowing it to handle specific AD tasks offloaded from the intelligent vehicle.

[0028] The cloud computing layer comprises multiple cloud servers (e.g., remote servers in a data center). Cloud servers offer high computing power and scalable storage capacity, allowing computationally intensive tasks to be offloaded to cloud servers and executed there with high performance. The cloud server can exchange information with the vehicle via the edge server. Due to the greater distance between the cloud server and the vehicle, the communication latency between the cloud server and the edge server is higher than the communication latency between the edge server and the vehicle.

[0029] According to one embodiment of the present invention, under the aforementioned vehicle-side cloud architecture, an allocation scheme for offloading AD tasks between vehicles, edge computing devices, and cloud servers is defined. This scheme can achieve an offloading strategy with minimal end-to-end latency for autonomous driving services, based on fulfilling the heterogeneity constraints of hardware devices, the limitations of resource requirement heterogeneity, new security requirements, and taking into account the dependencies between AD tasks. The corresponding limitations and considerations are presented below. Heterogeneity between the compute nodes

[0030] Computing nodes at different levels differ in terms of system architecture, resource capacity, and security level. For example, the system architecture of the infrastructure at the edge computing layer might be ARM, x86, or FPGA to meet the specific requirements of different applications (such as low weight or low power consumption). Secondly, computing devices at different levels have varying resource capacities; for instance, cloud computing devices have the largest, smart vehicles the smallest, while edge computing devices fall somewhere in between. At the edge computing layer, resource capacity varies significantly depending on the device type of the computing node. Thirdly, some Active Directory tasks impose stringent security requirements on the hardware on which they are executed, necessitating their execution on computing nodes with a high security level.For example, data collection tasks are performed on hardware devices with a high security level and low error rate to ensure data collection accuracy. Since the cost of the hardware devices increases with the security level, the hardware under the vehicle-side cloud architecture includes both secure and insecure (different security levels) devices.

[0031] It is understood that the terms “safety” and “safety level” in the present invention refer to the safety levels A to D (Automotive Safety Integrity Level ASIL: Automotive Safety Integrity Level) which are defined by the ISO26262 standard for the components of the system according to the degree of safety risk, with level D being the highest level and requiring the strictest safety requirements. Heterogeneity between the AD tasks

[0032] Different Active Directory (AD) tasks may use different programming languages, and therefore their resource requirements can vary. For example, deep learning-based object detection tasks require GPU resources, while Kalman filter-based object tracking tasks require CPU resources instead of GPU resources. Furthermore, some AD tasks are highly dependent on input sources and must be offloaded to compute nodes located near those input source nodes. Dependencies between AD tasks

[0033] Autonomous driving services comprise interdependent perception, prediction, planning, and control tasks. For example, information is exchanged between these tasks via a lightweight communication protocol (ROS2). The dependencies between these tasks include both linear and graphical dependencies (e.g., a directed acyclic graph is used to express the dependencies between multiple AD tasks). Perception fusion tasks, for instance, rely on sensory results from camera trackers, radar trackers, lidar trackers, and visibility grids. Communication delay between computing nodes

[0034] Autonomous driving services have strict time delay requirements; for example, completion must be achieved within ten or one hundred milliseconds. The time delay of an autonomous driving service includes the execution time of each AD task as well as the delay of communication between different compute nodes. In one embodiment of the present invention, the end-to-end delay of an autonomous driving task includes only the communication delay, and the AD task itself is ignored. This end-to-end delay can include communication delays between different layers or communication delays between different compute nodes within the same layer. Example procedure

[0035] Fig. Figure 3 shows a method 300 for outsourcing autonomous driving tasks according to an embodiment of the present invention. The method 300 can be implemented using the aforementioned system 100, so the description of the system 100 applies equally here.

[0036] The creation module 20 creates a system model at field 310. The system model includes communication delays between all compute node pairs of the multiple compute nodes. This system model can also include dependencies and heterogeneity between multiple AD tasks, heterogeneity between multiple compute nodes, and resource attributes of all compute nodes.

[0037] In one embodiment, the creation module 20 creates a service dependency model using a directed acyclic graph (DAG) (box 3101) and a compute resource model using a bidirectional graph (bidirectional graph) (box 3102).

[0038] For field 3101, the creation module 20 creates a directed acyclic graph with multiple nodes and multiple edges. Each node represents an AD task. Each edge represents the data dependency between the two AD tasks it connects. The arrows on each edge indicate the data flow. Each AD task has attribute parameters that include requirements for computational resources and security levels, as well as dependencies on other AD tasks (e.g., upstream or downstream AD tasks). These attribute parameters can be represented by a series of numerical values.

[0039] In embodiments of the present invention, the directed acyclic graph can have multiple root nodes, meaning that the autonomous driving service expressed by the directed acyclic graph has multiple data input sources. These multiple data input sources can include data input sources located at different levels, such as two or more cloud-side data input sources, one edge-side data input source, and one vehicle-side data input source. The multiple data input sources can also include data input sources from sensors of different modalities, such as LiDAR sensor data, camera sensor data, and high-precision map data.Instances with multiple root nodes are particularly suitable for autonomous driving service applications, as multiple data input sources can significantly improve the efficiency of autonomous driving services (e.g., driving decisions are more accurate, training converges faster, etc.).

[0040] Fig. Figure 4 shows an example of the service dependency model using a directed acyclic graph. As in Fig. As shown in Figure 4, the service dependency model comprises 6 nodes (S1-S6), meaning that the autonomous driving service expressed by this model includes 6 AD tasks. This autonomous driving service has multiple data input sources, namely nodes S1 and S2 in Figure 4. Fig. 4. Furthermore, the [document / section] in Fig. Four gray filled nodes S4 indicate that this node requires a higher security level than other nodes (unfilled nodes).

[0041] At box 3102, the creation module 20 creates a bidirectional graph with multiple nodes and multiple edges. Each of these nodes represents a compute node, with the node having attribute parameters, including resource type and compute resources. Each edge represents a communication link between the two nodes it connects and has a transmission bandwidth. Data can be transmitted in both directions between two nodes connected by each edge (e.g., a node and another node), i.e., data can be transmitted from one node to another node and from another node to another node.

[0042] In embodiments of the present invention, the computing resource model remains unchanged during each execution of the task offloading process. That is, the computing resource model remains unchanged because data for an autonomous driving service flows from the first node to the last node. After this task offloading is complete, the creation module 20 can adjust the computing resource model to express the current status of the computing resources of the system 100. For example, after this task offloading is complete, the available computing resources of each node may change, and the security level of each node may also change.

[0043] Fig. Figure 5 shows an example of representing a computing resource model using a bidirectional diagram, illustrating the computing resource model under the vehicle-side cloud architecture. As shown in Fig. As shown in Figure 5, the model comprises 5 compute nodes, of which: one compute node H1 on the vehicle side, three compute nodes H2 to H4 on the edge side (the three nodes include, for example, compute nodes on signal masts, underground compute nodes, and compute nodes on base stations), and one compute node in the cloud data center. Among these compute nodes, the security level of the gray shaded node H2 is higher than the security level of the other nodes (unshaded nodes).

[0044] Back to Fig. 3. The allocation module 320 assigns several AD tasks of the autonomous driving service based on the created model, in order to offload each AD task to one of the multiple compute nodes. This allocation strategy minimizes the end-to-end latency of the autonomous driving service. In Fig. Figure 6 shows, for example, that the data flow from nodes S1 and S2 to node S5 is fastest. This allocation strategy achieves the offloading of tasks with high security requirements to compute nodes with a high security level. Fig. Figure 6 shows, for example, that task S4, which requires a higher security level, is offloaded to node H2, which has a higher security level. This allocation strategy also causes AD tasks that are strongly associated with a particular compute node to be offloaded to compute nodes adjacent to that specific compute node. For example, with reference to Fig.6. If task S2 is offloaded as the input source to node H3 (i.e., the compute node in the edge layer), task S3 has a strong dependency on the input source. In this case, task S3 should be offloaded to a node adjacent to node H3 to reduce the communication delay between the two; for example, task S3 could be offloaded to the compute node H4 in the edge layer.

[0045] In one embodiment, the assignment module 30 offloads two interdependent autonomous driving tasks to a pair of compute nodes whose communication delay is less than the delay threshold. In this embodiment, the distance between the offloading node pair is limited by a delay threshold. The delay threshold is preset and can be adjusted as needed depending on the application scenario.

[0046] In one embodiment, the assignment module 30 assigns one or more AD tasks to one or more computation nodes by calculating the optimal solution of the objective function. The specific embodiment of the present invention is described below.

[0047] First, the number of AD tasks is defined as N, and the total number of compute nodes in the vehicle, at the edge, and in the cloud is defined as M. The dependency relationship of N AD tasks is defined as the N*N AD task dependency matrix D. N×N The elements of the matrix D N×N are represented as {0,1}, where D i×j =1 means that task S i from task S j depends and vice versa. In the computing resource model, the communication delay between compute nodes is represented by the computing resource matrix L. M×MThe values ​​of the elements in this matrix represent the communication delay between two compute nodes. For two unconnected compute nodes, the communication delay between them is infinite (i.e., the value of the corresponding matrix element is infinite). The matrix L M×M is a symmetric matrix. At this time, the allocation module 30 determines an allocation strategy for offloading N AD tasks to M compute nodes, represented by an N*M offloading matrix A N×M The elements of the outsourcing matrix A N×N are represented as {0,1}, where A i×j =1 means that task S i on the compute node H j The predetermined allocation can be represented in the paging matrix, for example, by some elements in the paging matrix A N×M be pre-filled to express the predetermined assignment.

[0048] Next, it is determined that N AD tasks are offloaded simultaneously. The computing resource requirements for each task are S i as R i designated R i can be a vector representing the demand for resource type and computing power. For each compute node Hj, its available resources are denoted as C j expressed C j can also be a vector, where C j with R i the task assigned to the compute node should be identical.

[0049] The above settings can be expressed as follows: - N AD tasks are expressed as: S={S1, S2, S3,..., S N}, and the dependency between them is defined by the AD task dependency matrix D N×N , D ij expressed ∈{0,1}. For each AD task S i Their resource requirements are considered R i expressed; and - The M nodes in the three planes are defined by H={h1, h2, h3,..., h M} represented, the communication delay between each pair of nodes is denoted as L M×M ∈ℝ. expressed, and for each node h i His available resources are considered C j shown.

[0050] The target function is displayed as follows based on the above settings: Min (U)=I×L I=D×A

[0051] Where A is the target offloading matrix, D is the AD task dependency matrix mentioned above, I is an intermediate variable, and I = D × A represents multiple AD tasks expressed by matrix D according to the target offloading matrix. L is the aforementioned matrix of computational resources, and Min(U) = I × L means that the total delay of executing all tasks in the task matrix (i.e., the end-to-end delay of the autonomous driving service) is minimal.

[0052] The process of calculating the optimal solution of the objective function is the process of minimizing the total delay U by adjusting the offloading matrix A. When the optimal solution is achieved, the offloading matrix A is the target offloading matrix.

[0053] Furthermore, the following conditions must also be met when calculating the optimal solution of the aforementioned objective function: - Σ j R j A ji ≤C j , where j=1,...,N. These conditions mean: The on the node h i The resources required for the task being performed do not exceed the available resources. j , - Σ i A ji =1, where i=1,...,M. These conditions mean that the task S j The process is only outsourced to one node and only executed on that one node.

[0054] According to another aspect of the present invention, there is also provided a machine-readable storage medium storing executable instructions that, when executed, cause one or more processors to perform the AD task offloading method.

[0055] It is understood that the processor may be implemented using electronic hardware, computer software, or any combination thereof. Whether these processors are embodied in hardware or software depends on the specific application and the overall design constraints imposed on the system. By way of example, the processor, any portion of the processor, or any combination of the processor may be embodied within the scope of the present invention as a microprocessor, microcontroller, digital signal processor (DSP), field-programmable gate array (FPGA), programmable logic device (PLD), state machine, gate logic, discrete hardware circuitry, and other suitable processing components configured to perform the various functions described in the present disclosure.The functions of the processor, each part of the processor, or each combination of the processors provided by the present invention can be implemented as software executed by a microprocessor, a microcontroller, a DSP, or other suitable platforms.

[0056] It is understood that software in the broadest sense means instructions, instruction sets, code, code segments, program code, program, subroutine, software module, application, software application, software package, routine, subroutine, object, running thread, process, function. The software may reside on a computer-readable medium. A machine-readable medium may, for example, include memory, where the memory may be, for example, a magnetic storage device (e.g., hard disk, floppy disk, magnetic stripe), optical memory, a smart card, flash memory, random-access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), a register, or a removable storage medium. Although the memory is presented as separate from the processor in several aspects of this disclosure, the memory may also be located within the processor (e.g.,cache or register).

[0057] Although some embodiments have been described, these serve only as examples and are not intended to limit the scope of the present invention. The appended claims and their equivalents are intended to cover all modifications, substitutions, and alterations made within the scope and spirit of the present invention.

Claims

[1] A system for outsourcing autonomous driving tasks, comprising: Multiple compute nodes, one or more compute nodes in the vehicle, one or more compute nodes in edge devices, and one or more compute nodes in cloud devices; a creation module configured to create a system model, including communication delays between all compute node pairs of the plurality of compute nodes; and an allocation module configured to allocate a plurality of autonomous driving tasks of the autonomous driving service based on the system model to offload each autonomous driving task to one of the plurality of compute nodes, wherein the allocation minimizes the end-to-end delay of the autonomous driving service. [2] The system of claim 1, wherein the system model comprises a service dependency model and a computing resource model, the service dependency model includes the dependencies and heterogeneity between the multiple autonomous driving tasks and the ASIL safety level required for each autonomous driving task, and the compute resource model, which includes heterogeneity between the multiple compute nodes, communication delays between all compute node pairs, and resource types and available compute resources of all compute nodes. [3] The system of claim 2, wherein the allocation module is configured to allocate the plurality of autonomous driving tasks based on the service dependency model and the compute resource model, whereby each autonomous driving task can be offloaded to a compute node whose ASIL safety level is higher than or equal to the ASIL safety level required for the autonomous driving task. [4] The system according to claim 2 or 3, wherein the allocation module is configured to allocate the plurality of autonomous driving tasks based on the service dependency model and the computing resource model, whereby two interdependent autonomous driving tasks can be offloaded to a pair of computing nodes whose communication delay is less than the delay threshold. [5] The system of any one of claims 2-4, wherein the allocation module is configured to allocate the plurality of autonomous driving tasks based on the service dependency model and the computational resource model, whereby the resource type required by each autonomous driving task matches the resource type of the compute node to which it is offloaded, and further each autonomous driving task is offloaded to a compute node whose available compute resources are greater than or equal to the compute resources required for the autonomous driving task. [6] The system of claims 2-5, wherein the service dependency model comprises a directed acyclic graph with a plurality of service nodes and a plurality of edges, each service node representing an autonomous driving task, having the ASIL safety level required for the autonomous driving service, and further each edge representing the connecting dependency between the two autonomous driving tasks, and each edge having an arrow representing the data flow direction of the autonomous driving service. [7] The system of claim 6, wherein the directed acyclic graph has a plurality of root nodes representing a plurality of data input sources of the autonomous driving service. [8] The system of claim 7, wherein the plurality of data input sources include data input sources from cloud devices and two or more include data input sources from edge devices and data input sources from vehicles. [9] The system of claim 7, wherein the multiple data input sources comprise multiple data sources from multimodal sensors. [10] The system of any of claims 2-9, wherein the compute resource model comprises a bidirectional graph with multiple compute nodes and multiple edges, each compute node having an ASIL security level, available compute resources and a resource type, and further each edge representing the communication link between the two compute nodes it connects and having a transmission bandwidth and communication delay, wherein the two compute nodes connected by each edge can transmit data in both directions. [11] The system of claims 2-10, wherein the plurality of autonomous driving tasks are offloaded simultaneously and the computational resource model remains unchanged during the offloading process. [12] The system of any of claims 1-11, wherein the creation module is located in a compute node of the plurality of compute nodes; the allocation module is arranged in a computing node of the plurality of computing nodes; and further the creation module and the allocation module are located in the same compute node or in different compute nodes. [13] The system of claim 1, wherein the allocation module is configured to: to define an objective function using the system model; and to obtain a target offloading matrix using the optimal solutions for the target matrix, and to offload each autonomous driving task to one of the several computing nodes according to the target offloading matrix, - minimize the end-to-end delay of the autonomous driving task; - to outsource each autonomous driving task to a computing node whose ASIL safety level is higher than or equal to the ASIL safety level required for the autonomous driving task; - to outsource two interdependent autonomous driving tasks to a pair of computing nodes whose communication delay is smaller than the delay threshold; - the resource type required for each autonomous driving task matches the resource type of the compute node to which the task is offloaded; and - to outsource each autonomous driving task to a computing node whose ASIL safety level is higher than or equal to the ASIL safety level required for the autonomous driving task; [14] Method for outsourcing autonomous driving tasks, comprising: Creating a system model that includes communication delays between all compute node pairs of the multiple compute nodes, including one or multiple computing nodes on the vehicle, one or more computing nodes in the edge device, and one or more computing nodes in the cloud device; and to allocate multiple autonomous driving tasks of the autonomous driving service based on the system model to offload each autonomous driving task to one of the multiple compute nodes, wherein the allocation minimizes the end-to-end delay of the autonomous driving service. [15] A method according to claim 14, wherein the method is performed by a system according to any one of claims 1-13. [16] A machine-readable storage medium storing executable instructions which, when executed, carry out the method of any one of claims 14-15 by one or more processors.

Images