A dependent task online unloading decision method for high-speed driving vehicles

Abstract

The present application relates to the technical field of vehicle-mounted edge computing, and particularly relates to a dependent task online unloading decision method for high-speed driving vehicles, which comprises: an execution information collection work module, which obtains an updated to-be-executed task set and an updated RSU_MEC set; an execution subtask package construction module, which determines a target subtask package set; an execution weighted hypergraph construction module, which obtains a weighted hypergraph corresponding to an unloading decision time period; an execution maximum weight hypermatch set construction module, which determines a maximum weight hypermatch set of the weighted hypergraph; and an execution maximum weight hypermatch set construction module, which obtains each optimal online task unloading strategy in a preset unloading decision time period. The present application improves the timeliness of the dependent task online unloading decision of the high-speed driving vehicle, helps the high-speed driving vehicle to make a real-time task unloading strategy, and is mainly suitable for making a real-time unloading decision for a dependent vehicle-mounted task during high-speed driving of the vehicle.

Description

Technical Field

[0001] This invention relates to the field of vehicle edge computing technology, specifically to an online offloading decision method for dependent tasks in high-speed vehicles. Background Technology

[0002] With the development of intelligent transportation and autonomous driving technologies, a series of new in-vehicle applications involving information interaction and traffic safety services are experiencing explosive growth. Tasks such as blind spot pedestrian detection, path planning, collision detection, and dynamic traffic flow monitoring are mostly computationally intensive or latency-sensitive. Due to their inherent limitations, vehicles can hardly complete these in-vehicle tasks independently. In-vehicle edge computing has emerged to address this need, aiming to "sink" services to the mobile access edge, enabling flexible utilization of network computing and storage resources, thereby meeting the offloading service requirements of in-vehicle tasks for high bandwidth, low latency, and low energy consumption.

[0003] Task offloading decision-making is a key technical challenge in the field of vehicular edge computing, primarily addressing whether a task should be offloaded and where it should be executed. For high-speed vehicles, when they enter the service area of ​​a Road Side Unit (RSU), they selectively offload onboard tasks to edge servers (Multi-Access Edge Computing, MEC) based on their own offloading decision-making methods to obtain corresponding offloading execution gains and ensure successful task completion. Currently, many intelligent vehicular tasks can be divided into smaller tasks, executed separately by the vehicle or different servers. However, due to issues such as data input and execution priority, sub-tasks often have interdependencies. Therefore, these tasks are called dependent tasks. For example, path planning is a typical dependent task, which must consider not only the vehicle's own movement but also the impact of the movement patterns of other vehicles or people on path selection. The detailed process of path planning is as follows: First, through object detection, information such as vehicles, pedestrians, and traffic lights on the road is collected; then, through traffic flow prediction algorithms, based on historical traffic and trajectory data, different driving paths are derived, such as the shortest driving path and the path with the fewest traffic lights, thereby achieving online resource allocation. The above process contains multiple interdependent subtasks.

[0004] As is well known, the benefits of any decision-making scheme are closely related to time; therefore, only decisions that meet time constraints are effective. For high-speed vehicles, the timeliness requirements for task offloading decisions are even higher. First, the equipment providing offloading access services for high-speed vehicles, such as roadside units and base stations, changes frequently, and the offloading communication link may be interrupted at any time. This requires that once a vehicle has an offloading opportunity, it should make an offloading decision immediately; otherwise, it will lose the opportunity forever. Second, dependent onboard tasks can be divided into multiple independently executable subtasks. Because these subtasks are interdependent, they need to be executed sequentially in a specific order; that is, when executing a specific subtask, it must be ensured that all its predecessor subtasks have been completed. Finally, for all tasks, including subtasks, the closer to the execution deadline, the greater the risk of failure to execute; therefore, the stronger the need for offloading execution. In summary, the objective of online offloading decision-making for dependent tasks of high-speed vehicles is: under the constraint of decision timeliness, to obtain a reasonable online onboard task offloading strategy based on the interdependencies of subtasks and to maximize the task offloading execution gain.

[0005] Currently, research on high-speed vehicle-mounted task unloading decision-making is still in its early stages. Existing unloading decision-making methods typically employ heuristics or deep reinforcement learning to obtain task unloading decisions, failing to fully consider the impact of decision-making timeliness on unloading strategies. This results in proposed unloading decision-making methods being large and complex, with high decision-making time, and unable to assist high-speed vehicles in making real-time task unloading strategies. Summary of the Invention

[0006] To address the technical problem of poor timeliness in online offloading decisions for dependent tasks of high-speed vehicles, the present invention aims to provide an online offloading decision-making method for dependent tasks of high-speed vehicles. The specific technical solution adopted is as follows:

[0007] One embodiment of the present invention provides an online offloading decision method for dependent tasks of high-speed vehicles, the method comprising the following steps:

[0008] Obtain the set of tasks to be executed and the historical RSU_MEC set corresponding to the target vehicle within the preset unloading decision time period; wherein, the target vehicle is a high-speed vehicle carrying dependent tasks and continuously generating new tasks; the preset unloading decision time period includes a decision observation period and a decision execution period;

[0009] When the target vehicle passes through the new RSU_MEC, the target vehicle execution information collection module obtains the updated set of tasks to be executed and the updated set of RSU_MEC corresponding to the target vehicle.

[0010] Based on the updated set of tasks to be executed and the new RSU_MEC, the subtask package construction module is executed to determine the target subtask package set; wherein, the target subtask package set is the set of subtask packages carried by the target vehicle that can accept the new RSU_MEC service;

[0011] Based on the target subtask package set and the updated RSU_MEC set, the weighted hypergraph construction module is executed to obtain the weighted hypergraph corresponding to the unloading decision time period.

[0012] Based on the weighted hypergraph, the super-matching set construction module with the maximum weight is executed to determine the super-matching set with the maximum weight of the weighted hypergraph;

[0013] If the super-match set with the highest weight has a target unloading service pair, the target unloading service pair is taken as the optimal online task unloading strategy for the corresponding new RSU_MEC; wherein, the target unloading service pair is the unloading service pair related to the new RSU_MEC;

[0014] The target vehicle continuously passes through new RSU_MECs within the preset unloading decision time period. By repeatedly executing the information collection module, subtask package construction module, and weighted hypergraph construction module, the optimal online task unloading strategy corresponding to each new RSU_MEC is obtained.

[0015] Furthermore, the implementation steps of the information collection module include:

[0016] Detect whether a new task set exists for the target vehicle. If a new task set exists, add the new task set to the set of tasks to be executed, and obtain the updated set of tasks to be executed.

[0017] Obtain the RSU_MEC set corresponding to the new RSU_MEC, and add the RSU_MEC set corresponding to the new RSU_MEC to the historical RSU_MEC set to obtain the updated RSU_MEC set.

[0018] Furthermore, obtain the historical RSU_MEC set corresponding to the target vehicle within the preset unloading decision time period, including:

[0019] Estimate the number of RSU_MECs that the target vehicle will pass through during the preset unloading decision time period, calculate the product of the number of RSU_MECs and the preset probability factor, and use the product as the number of RSU_MECs that the target vehicle will pass through during the decision observation time period.

[0020] Obtain the RSU_MEC set corresponding to each RSU_MEC passed by the target vehicle during the decision observation period, and combine the RSU_MEC sets corresponding to each RSU_MEC passed by during the decision observation period into a historical RSU_MEC set.

[0021] Furthermore, the implementation steps of the subtask package construction module include:

[0022] Based on the order level of each subtask in the updated set of tasks to be executed, the subtasks are topologically sorted to obtain a sorted set of tasks to be executed, and then transformed into a directed acyclic graph.

[0023] For any task to be executed in a directed acyclic graph, select the subtask with the highest order level from the tasks to be executed, add the corresponding subtask to the sorted task set, remove all edges originating from the corresponding subtask from the edge set, and remove the corresponding subtask from the tasks to be executed.

[0024] Based on the order level, determine whether each subtask in the sorted task set satisfies the task type constraints and latency constraints corresponding to the new RSU_MEC, and add the satisfying subtasks to the task subset that can accept the new RSU_MEC service.

[0025] Obtain the probability factor of the number of subtask packages, and count the number of subtasks that can accept the new RSU_MEC service. The product of the probability factor of the number of subtask packages and the number of subtasks that can accept the new RSU_MEC service is determined as the number of subtask packages contained in the target subtask package set.

[0026] Based on the order and level, each subtask in the subset of tasks that can accept the new RSU_MEC service is judged in turn, and each subtask package is assembled. If a subtask in the task subset has no predecessor task or its predecessor task is already in the current subtask package, a coin toss rule is used to determine whether to add the subtask to the current subtask package, thereby obtaining the target subtask package set.

[0027] Furthermore, the task type constraint is that the subtask type belongs to the service task type of the new RSU_MEC; the delay constraint is that the deadline for the subtask to make the unloading decision is later than the time when the target vehicle enters the service range of the new RSU_MEC.

[0028] Furthermore, the implementation steps of the weighted hypergraph construction module include:

[0029] The target subtask set is used as the left vertex set of the weighted hypergraph, and the updated RSU_MEC set is used as the right vertex set of the weighted hypergraph.

[0030] Based on the left vertex set and the right vertex set, calculate the unload execution gain corresponding to each subtask package in the target subtask package set;

[0031] If the unload execution gain corresponding to a certain subtask package meets the unload execution gain constraint, construct the corresponding new RSU_MEC hyperedge and add the new RSU_MEC hyperedge to the hyperedge set, thereby obtaining the hyperedge set corresponding to the weighted hypergraph and constructing the weighted hypergraph.

[0032] Furthermore, the calculation steps for the unloading execution gain corresponding to each subtask package include:

[0033] For any subtask in each subtask package, the absolute unloading execution gain is determined based on the computational load required to complete the subtask, the computing power and data transmission rate of the target vehicle, the amount of data to be transmitted when unloading the subtask, and the computing power of the new RSU_MEC.

[0034] The relative unloading execution gain is determined based on the unloading decision deadline of the subtask and the time when the target vehicle enters the new RSU_MEC service area.

[0035] The unloading execution gain corresponding to the subtask is determined based on the absolute unloading execution gain, the relative unloading execution gain, and the pre-determined trade-off factor.

[0036] For any subtask package, the cumulative value of the unload execution gain corresponding to each subtask in the subtask package is determined as the unload execution gain corresponding to the subtask package.

[0037] Furthermore, the formula for calculating the absolute unloading execution gain is as follows:

[0038]

[0039] Among them, Z abs (s i,x ,r j () represents the absolute unloading execution gain. The computational cost required to complete the subtask, f c The computing power of the target vehicle. To handle the amount of data that needs to be transferred for the subtask, g c The data transmission and reception rate of the target vehicle. For the computing power of the new RSU_MEC, s i,x For subtasks, r j For the new RSU_MEC;

[0040] The formula for calculating the relative unloading execution gain is as follows:

[0041]

[0042] Among them, Z rel (s i,x ,r j() represents the relative unloading execution gain. The deadline for the subtask unloading decision. The time s is the time when target vehicle C enters the new RSU_MEC service area. i,x For subtasks, r j For the new RSU_MEC;

[0043] The formula for calculating the unloading execution gain corresponding to the subtask is:

[0044] Z(s i,x ,r j ) = Z abs (s i,x ,r j )+α×Z rel (s i,x ,r j )

[0045] Wherein Z(s) i,x ,r j Z represents the unloading execution gain corresponding to the subtask. abs (s i,x ,r j Z represents the absolute unloading execution gain. rel (s i,x ,r j ) represents the relative unloading execution gain, α is a predetermined tradeoff factor, and s i,x For subtasks, r j For the new RSU_MEC.

[0046] Furthermore, the unloading execution gain limitation condition is as follows:

[0047] Z(bag j,h ,r j )>0

[0048] Among them, Z(bag j,h ,r j (bag) represents the unload execution gain corresponding to the subtask package. j,h ,r j The bag is an unload service pair consisting of a subtask package and the new RSU_MEC. j,h ={s i,x |s i,x ∈S,},bag j,h For the subtask package to be uninstalled to the new RSU_MEC, S is the updated set of tasks to be uninstalled. i,x For subtasks, r j For the new RSU_MEC.

[0049] Furthermore, the steps for determining the supermatch set construction module with the maximum weight include:

[0050] Based on the weights of each edge in the weighted hypergraph, sort the hyperedge set in descending order to obtain the sorted hyperedge set.

[0051] Sort the set of superedges in descending order, and iterate through them one by one to determine whether the superedges in the weighted supergraph meet the matching conditions. If they do, add the corresponding superedge to the super-matching set with the highest weight.

[0052] The present invention has the following beneficial effects:

[0053] This invention provides an online task unloading decision method for high-speed vehicles. Based on three key decision-making timeliness points, this method improves the timeliness of task unloading decisions for high-speed vehicles to obtain more accurate unloading execution gains. In other words, under the constraint of decision timeliness, it obtains the optimal online task unloading strategies for each on-board task and maximizes the task unloading execution gains. First, the information collection module collects the RSU_MEC set corresponding to the RSU_MECs passed by the target vehicle, and updates the set of tasks to be executed and the historical RSU_MEC set to obtain the updated set of tasks to be executed and the updated set of RSU_MECs, facilitating online unloading of dependent tasks. Second, the subtask package construction module divides subtasks into several subtask packages based on inter-task dependencies, and bundles the subtasks within these packages for parallel unloading, thus addressing the impact of subtask dependencies on the timeliness of unloading decisions. Third, the task unloading decision deadline is considered a key factor influencing task unloading execution gain, addressing the impact of task unloading requirements on the timeliness of unloading decisions. Fourth, the weighted hypergraph construction module models the online task unloading decision problem for high-speed vehicles as a weighted hypergraph online matching problem, addressing the impact of random encounters between vehicles and RSU_MECs on the timeliness of unloading decisions. Finally, the dependent task online unloading decision method of this invention assists vehicles in obtaining real-time online task unloading strategies, thereby achieving task unloading execution gains with significantly better timeliness than random strategies. This invention belongs to the field of vehicle edge computing and is applicable to determining the real-time offloading decision of dependent vehicle tasks during high-speed vehicle operation. Attached Figure Description

[0054] To more clearly illustrate the technical solutions and advantages in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a schematic diagram of a task unloading decision scenario for a high-speed vehicle in an embodiment of the present invention;

[0056] Figure 2 This is a flowchart of an online offloading decision method for dependent tasks for high-speed vehicles according to the present invention;

[0057] Figure 3 This is a flowchart of the DTOODA online task unloading decision algorithm in this embodiment of the invention;

[0058] Figure 4 This is a schematic diagram of the DAG of the set of tasks to be executed S carried by the vehicle in an embodiment of the present invention;

[0059] Figure 5 This is a graph showing the trend of the total offloading gain, absolute offloading gain, and relative offloading gain generated by DTOODA as a function of the trade-off factor α in an embodiment of the present invention.

[0060] Figure 6 This is a graph showing the changing trend of the total unloading gain and the tradeoff factor α generated by DTOODA and the comparison algorithm in the embodiments of the present invention. Detailed Implementation

[0061] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the specific implementation methods, structures, features, and effects of the technical solution proposed according to the present invention are described in detail below with reference to the accompanying drawings and preferred embodiments. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined in any suitable form.

[0062] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0063] A schematic diagram of a task unloading decision scenario for high-speed vehicles is shown below. Figure 1 As shown, in Figure 1 In the scenario, vehicle C travels at high speed along a road, passing multiple heterogeneous roadside units and edge servers (RSU_MEC) deployed along the road. During the vehicle's journey, new onboard tasks are continuously generated based on changes in the scenario and requirements. It is assumed that there are no dependencies between the onboard tasks, and a single task can be considered as composed of subtasks with interdependent relationships. Therefore, a single task can undergo dependent task unloading, provided that: if a subtask is unloaded, all its predecessor subtasks must be completed, meaning the task execution order satisfies the subtask dependencies.

[0064] Assuming the onboard tasks are heterogeneous, meaning the types and execution requirements of each subtask differ, and the offloading services provided by each RSU_MEC also differ (e.g., computing power and service type), then for a specific subtask, only some RSU_MECs can provide offloading services within its offloading decision cycle; and the offloading execution gain obtained when offloading through different RSU_MECs also varies. Therefore, an online task offloading decision method needs to be designed to ensure that when a vehicle enters the service range of a certain RSU_MEC, a real-time task offloading decision can be made, and the task offloading execution gain can be maximized. Specifically, this embodiment provides an online offloading decision method for dependent tasks of high-speed vehicles, the flowchart of which is shown below. Figure 2 As shown, it includes the following steps:

[0065] S1, obtain the set of tasks to be executed and the set of historical RSU_MEC corresponding to the target vehicle within the preset unloading decision time period.

[0066] First, for target vehicles within the preset unloading decision time period, in order to make more accurate unloading decisions, the target vehicles need to possess certain prior knowledge before making actual unloading decisions. Therefore, the DTOODA algorithm divides the entire preset unloading decision time period into a decision observation phase and an actual decision phase. The preset unloading decision time period can be set by the implementer according to the specific actual situation. In this embodiment, it is set to 12 hours. The preset unloading decision time period includes a decision observation period and a decision execution period. During the decision observation period, the target vehicle only performs the RSU_MEC set information collection task. During the decision execution period, the target vehicle not only needs to perform the information collection task, but also needs to perform the online task unloading strategy determination task. The target vehicle is a high-speed vehicle carrying dependent tasks and constantly generating new tasks, which can be denoted by the letter C, let C = (f c ,e c ,g c ,p c ), where f c It refers to the computing power of the target vehicle, which can be obtained through CPU calculation frequency; e c This refers to the unit computational energy consumption of the target vehicle, which can be obtained by multiplying the CPU computing frequency by a coefficient representing the chip architecture; g c It is the data transmission and reception rate of the target vehicle, p c It refers to the data transmission and reception power of the target vehicle.

[0067] It's important to note that the essence of online offloading decisions for dependent tasks is to allocate resources across all RSU_MECs the target vehicle will pass through to obtain a real-time online resource allocation strategy, i.e., a task offloading strategy, while maximizing the overall resource allocation efficiency of the task, i.e., the offloading execution gain. However, since onboard tasks are dynamically generated, and the RSU_MECs the vehicle will pass through are unknown, it's necessary to dynamically assemble sub-task packages based on the current task set. Furthermore, when passing through a specific RSU_MEC, the probability of each sub-task package being offloaded to that RSU_MEC for execution needs to be evaluated, and the achievable offloading execution gain needs to be calculated. In this context, RSU_MEC can be represented as the resource provider, and subtask packages can be represented as resource requisitioners. Assessing the probability of each subtask package being offloaded to RSU_MEC for execution can be represented as the resource allocation probability, and the offloading execution gain can be represented as the allocation benefit. Therefore, the implementation process of online offloading decision-making for dependent tasks is a typical secretary-like problem, which can be transformed into finding the maximum weight matching problem of a weighted hypergraph. To solve this problem, an online offloading decision-making algorithm for dependent tasks based on weighted hypergraph matching is proposed, denoted as the DTOODA algorithm. The flowchart of the DTOODA online task offloading decision-making algorithm is shown below. Figure 3 As shown, the online task unloading decision algorithm DTOODA includes three relatively complex functions: first, dividing the task set into a set of subtask packages; second, constructing a weighted hypergraph; and third, solving for the set of supermatches with the maximum weight in the weighted hypergraph. To achieve more accurate online unloading, a preset unloading decision time period needs to be determined. This allows the target vehicle to restart the DTOODA algorithm at the beginning of each preset unloading decision time period and obtain a feasible optimal set of online task unloading strategies at the end of each unloading decision time period, thus terminating the DTOODA algorithm.

[0068] Then, for the set of tasks to be executed, let S be the set of tasks to be executed for the target vehicle, and let S be the i-th task to be executed in the set of tasks to be executed. i When the target vehicle enters the new RSU_MEC service area, update the set of tasks to be executed, S = S∪S. new-j S new-j It is a newly generated set of tasks. Let S represents the interdependencies of subtasks in the i-th task to be executed, where S i ={s i,x |x=1,…,y},s i,x Let represent the x-th subtask in the i-th task to be executed, and y represent the number of subtasks contained in the i-th task to be executed. This is the amount of computation required to complete the subtask. This is the amount of data that needs to be transferred when unloading the subtask. This is the deadline for the subtask unloading decision. It is the type of subtask; Indicates the dependency relationship between subtasks, e i,x ,s i,x′ > indicates s i,x It is s i,x′ The direct precursor mission, s i,x′ It is s i,x The direct successor task, then s i,x′ Must be in s i,x This command can only be executed after all other steps have been completed. Subtasks s i,x The order of ranks, s i,x The order rank is greater than s i,x′ The order of ranks, denoted as Therefore, the maximum order level of the entry task is the number of subtasks in the i-th task to be executed, and the order level of the exit task is 0. The order level is transitive, meaning that the order levels of subtasks within the same task can be compared, but the order levels of subtasks within different tasks cannot be compared.

[0069] It should be noted that, based on the order and hierarchy of subtasks, subtasks can be divided into several subtask packages. The specific division method is as follows: First, a topological sorting algorithm is used to arrange the subtasks within each task into a sequence of subtasks with descending hierarchy; then, multiple subtask packages are randomly formed based on the subtask sequence. Let bag... j ={bag j,h |h=1,2,…,b} represents the set of subtask packages that the target vehicle can unload to RSU_MEC. In this embodiment, the set of subtask packages that can be unloaded to RSU_MEC is determined as the target subtask package set, where b represents bag. j The number of subtask packages included, bag j,h ={s i,x |s i,x For all subtasks in the subtask package set, subtasks with a higher priority than S are included in the subtask package set, except those that have been successfully uninstalled.

[0070] Finally, for the historical RSU_MEC set, estimate the number of RSU_MECs that the target vehicle will pass through during the preset unloading decision period, calculate the product of the number of RSU_MECs and the preset probability factor, and use the product as the number of RSU_MECs that the target vehicle will pass through during the decision observation period; obtain the RSU_MEC set corresponding to each RSU_MEC that the target vehicle passes through during the decision observation period, and combine the RSU_MEC sets corresponding to each RSU_MEC that passes through during the decision observation period into the historical RSU_MEC set.​

[0071] The dividing point between the decision observation phase and the actual decision phase is when the target vehicle passes through m*p RSU_MECs. The first m*p RSU_MECs constitute the decision observation phase, where m is the estimated number of RSU_MECs the target vehicle will pass through within the preset unloading decision time period, and p is a preset probability factor, where p∈[0,1]. For example, if the estimated number of RSU_MECs the target vehicle will pass through within the preset unloading decision time period is 20, and the preset probability factor is 0.2, then the target vehicle should pass through 4 RSU_MECs during the decision observation period. Then, the RSU_MEC set information corresponding to the 1st to 4th RSU_MECs when the target vehicle starts driving is collected, and the RSU_MEC sets corresponding to these 4 RSU_MECs are combined into a historical RSU_MEC set. It is worth noting that the target vehicle needs to re-acquire the historical RSU_MEC set within each preset unloading decision time period.

[0072] In this embodiment, RSU_MEC is a combination of heterogeneous roadside units and edge servers, let r = (a r ,t r ,f r C r ) represents the service performance of RSU_MEC, where a r This refers to the offloading service capability of the RSU_MEC, which can be represented by the maximum number of subtasks that can be offloaded to this RSU_MEC at one time; t r It is the time when the target vehicle enters the service area of ​​the RSU_MEC, f r It is the computing power of the RSU_MEC, C r This refers to the task types that the RSU_MEC can serve. Thus, this embodiment has obtained the set of tasks to be executed and the historical RSU_MEC set corresponding to the target vehicle within the preset unloading decision time period.

[0073] S2, when the target vehicle passes through the new RSU_MEC, the target vehicle execution information collection module obtains the updated set of tasks to be executed and the updated set of RSU_MEC corresponding to the target vehicle.

[0074] First, obtain the updated set of tasks to be executed corresponding to the target vehicle.

[0075] In this embodiment, it is detected whether there is a new task set for the target vehicle. If there is a new task set, the new task set is added to the task set to be executed, and the updated task set to be executed is obtained. The updated task set to be executed is the vehicle task information that needs to be unloaded.

[0076] When the target vehicle passes through the new RSU_MEC, the new RSU_MEC is recorded as r. j To avoid online task unloading deviations, it is first necessary to determine whether the new RSU_MEC is one of the historical RSU_MEC sets. If the new RSU_MEC is not a historical RSU_MEC, it is necessary to check whether the target vehicle has a new task set S. new-j If a new task set exists and is not empty, then the new task set S is... new-j Add the tasks to the set S to be executed, and obtain the updated set of tasks to be executed, i.e., S = S∪S new-j .

[0077] It's important to note that at the beginning of the preset unloading decision time period, i.e., when the target vehicle starts moving, it is unaware of the sub-task packages it can unload and all the RSU_MECs it will pass through. Only when it passes through a specific RSU_MEC will it learn the relevant information about that RSU_MEC, assemble several corresponding sub-task packages, determine the probability of the existence of the corresponding sub-task package unloading service pair, calculate the unloading execution gain, and then make a task unloading decision based on the unloading execution gain. Therefore, before executing the DTOODA algorithm, the RSU_MEC set, the optimal online task unloading strategy set, and the weighted hypergraph must first be initialized to empty sets. Online task unloading decision-making only begins when the target vehicle passes through a new RSU_MEC.

[0078] Then, obtain the updated RSU_MEC set corresponding to the target vehicle.

[0079] In this embodiment, the RSU_MEC set corresponding to the new RSU_MEC is obtained, and the RSU_MEC set corresponding to the new RSU_MEC is added to the historical RSU_MEC set to obtain the updated RSU_MEC set. The updated RSU_MEC set is the RSU_MEC information that has already been passed.

[0080] After determining that the new RSU_MEC is not a historical RSU_MEC, the set of RSU_MECs corresponding to the new RSU_MEC is obtained. This set includes the new RSU_MEC and a subset of service performance corresponding to a predicted number of RSU_MECs, denoted as k. in, It is the set of RSU_MECs corresponding to the new RSU_MEC, r j It's the new RSU_MEC, r j+kThis is the k-th RSU_MEC that is expected to be visited after the new RSU_MEC. The set of RSU_MECs corresponding to the new RSU_MEC is added to the historical RSU_MEC set to obtain the updated RSU_MEC set. The first R in the formula is the updated RSU_MEC set, and the second R in the formula is the historical RSU_MEC set. It is the set of RSU_MECs corresponding to the new RSU_MEC.

[0081] Regarding the known number of RSU_MECs, generally, vehicles can predict their planned travel path within a short period. That is, once a vehicle enters the service area of ​​a specific RSU_MEC, it can predict the k RSU_MECs it will pass through in the future based on historical travel information about the number of RSU_MECs it has passed. Assuming the target vehicle travels at a constant speed along the road, and the RSU_MECs are evenly distributed along the road, the known number... m′ p This represents the number of RSU_MECs actually traversed by the target vehicle within the estimated preset unloading decision time period. When the predicted number k = m, it means the target vehicle has a definite planned driving route and can predict all the RSU_MECs it will pass through in the future. Therefore, at the beginning of a new unloading decision time period, the target vehicle knows the current set of tasks to be executed, the number of RSU_MECs in the historical RSU_MEC set corresponding to the target vehicle's driving, and the predicted number of RSU_MECs. Regarding the service performance subset, this includes the unloading service capability a of the new RSU_MECs. r The time t when the target vehicle enters the new RSU_MEC service area r The computing power f of the new RSU_MEC r And the task type C that can be served r .

[0082] Thus, this embodiment has obtained the updated set of tasks to be executed and the updated set of RSU_MEC corresponding to the target vehicle.

[0083] S3, based on the updated set of tasks to be executed and the new RSU_MEC, execute the subtask package building module to determine the target subtask package set.

[0084] In this embodiment, after obtaining the updated set of tasks to be executed and the updated set of RSU_MECs, in order to avoid the target vehicle traveling in an incorrect direction and causing the newly obtained RSU_MEC to be an RSU_MEC that the target vehicle has already passed, it is necessary to determine whether the new RSU_MEC is the RSU_MEC corresponding to the unloading decision time period passed by the target vehicle. If the new RSU_MEC is not, then the online task unloading in the subsequent actual decision stage is performed. Based on the updated set of tasks to be executed, the subtask package construction module is executed to determine the target subtask package set. The target subtask package set can be the set of subtask packages carried by the target vehicle that can accept the new RSU_MEC service.

[0085] The subtask package construction module takes as input the updated directed acyclic graph of the task set to be unloaded and the newly traversed RSU_MEC, and outputs the target subtask package set. Its function is to divide the updated task set to be executed into the target subtask package set. Its main purpose is to filter out a subset of tasks in the updated task set that can accept the new RSU_MEC service, dynamically assembling them into multiple subtask packages to form a set of subtask packages that can accept the new RSU_MEC service. The steps may include:

[0086] The first step is to perform a topological sort on the subtasks in the updated set of tasks to be executed, based on their order and hierarchy, and then convert the sorted set of tasks to be executed into a directed acyclic graph.

[0087] In this embodiment, the implementation algorithm of the subtask package construction module initially requires initialization processing, namely... S′ is used to store the sorted task set. Used to store a subset of RSU_MEC service tasks that can accept new ones, bag j This is used to store the set of subtask packets that can accept new RSU_MEC services. Then, based on the rank values ​​of the unordered subtasks in the updated set of tasks to be executed, the subtasks are topologically sorted into an ordered task sequence S′, which is then converted into a directed acyclic graph (DAG). This DAG is denoted as S. DAG Such that any two subtasks s i,x and s i,x′ If side e i,x ,s i,x′ >∈E i Then s in task sequence S′ i,x Located in s i,x′ Previously, this was done to satisfy the data dependencies between subtasks.

[0088] ​The second step is to select the subtask with the highest order level from the tasks to be executed in the directed acyclic graph, add the corresponding subtask to the sorted task set, remove all edges originating from the corresponding subtask from the edge set, and remove the corresponding subtask from the tasks to be executed.

[0089] In this embodiment, in order to handle the dependencies between subtasks, from S DAG From all tasks, select the node with the highest rank value. This node is the subtask s that has no predecessor task. i,x Add it to task set S′ and perform subsequent processing, including: adding subtasks s that do not have a predecessor task. i,x All edges originating from edge set E i Remove from the middle; and remove subtasks s i,x From S i Removed from the middle.

[0090] The third step is to determine, in order of priority, whether each subtask in the sorted task set meets the task type and latency constraints corresponding to the new RSU_MEC, and add the subtasks that meet the requirements to the task subset that can receive the new RSU_MEC service.

[0091] In this embodiment, the subset of tasks that can accept the new RSU_MEC service is selected from the task set S′. Specifically, the subtasks are traversed sequentially according to the sorted ordered task sequence S′. If the subtask s i,x If the task type and latency constraints corresponding to the new RSU_MEC are met, then the subtask is added to... In this context, the task type constraint is that the subtask belongs to the service task type of the new RSU_MEC, and the latency constraint is that the deadline for the subtask's unloading decision is later than the time when the target vehicle enters the service area of ​​the new RSU_MEC.

[0092] The fourth step involves obtaining the probability factor for the number of subtask packages and counting the number of subtasks that can accept the new RSU_MEC service. The product of the probability factor and the number of subtasks that can accept the new RSU_MEC service is used to determine the number of subtask packages included in the target subtask package set. Following the order of priority, each subtask in the subset of tasks that can accept the new RSU_MEC service is evaluated sequentially, and each subtask package is constructed. If a subtask in the subset has no predecessor task or its predecessor task is already in the current subtask package, a coin toss rule is used to determine whether to add the subtask to the current subtask package, thus obtaining the target subtask package set. For example, heads means the subtask is added to the current subtask package; otherwise, it is not added.

[0093] In this embodiment, the subtask package set (bag) is dynamically constructed based on the new RSU_MEC capability. j Specifically: First, determine the bag j ={bag j,h The number of subtask packages contained in |h=1,2,…,b} in, It is the number of subtasks that can accept new RSU_MEC services, p j ∈[0,1] is the probability factor for the number of subtask packages, which can be obtained directly. Then, the subtask package set `bag` is dynamically constructed. j Traverse sequentially in an orderly manner. Subtasks and bags j Subtask packages within a given set, if the subtasks are ordered hierarchically... It is S i The maximum value in s indicates that s i,x All of their precursor missions have been completed, or more than Larger subtasks are all contained within the current subtask bag. j In this case, the number 0 or 1 is randomly generated by flipping a coin. If the random number is 1, then s i,x Add sub-task bag j In order to achieve the purpose of randomly forming subtask packets, a set of subtask packets (bag) that can accept RSU_MEC services carried by vehicle C is formed. j The set of subtask packets that the target vehicle carries and that accept the new RSU_MEC service is determined as the target subtask packet set (bag). j .

[0094] Thus, this embodiment has determined the set of target subtask packages.

[0095] S4. Based on the target subtask package set and the updated RSU_MEC set, execute the weighted hypergraph construction module to obtain the weighted hypergraph corresponding to the unloading decision time period.

[0096] In this embodiment, the function of the weighted hypergraph construction module is to construct the target subtask package set (bag) based on the target subtask package set (bag). j Together with the updated RSU_MEC set, construct a weighted hypergraph, denoted as G = (L∪R, E), where L is the set of left vertices, R is the set of right vertices, and E is the set of hyperedges. Specifically:

[0097] The first step is to create a collection of target subtask packages (bags). j The updated RSU_MEC set is used as the right vertex set R of the weighted hypergraph, with L being the left vertex set of the weighted hypergraph.

[0098] The second step is to calculate the unload execution gain for each subtask package in the target subtask package set based on the left vertex set and the right vertex set.

[0099] It should be noted that, firstly, for each new RSU_MEC, the set of hyperedges E corresponding to the new RSU_MEC needs to be set. rj If the set is empty, then iterate through the set of subtask packages that can accept new RSU_MEC services, and calculate the unloading execution gain for each task package. The steps may include:

[0100] The first sub-step involves determining the absolute unloading execution gain for any subtask within each subtask package, based on the computational load required to complete the subtask, the computing power and data transmission rate of the target vehicle, the amount of data to be transmitted when unloading the subtask, and the computing power of the new RSU_MEC.

[0101] In this embodiment, the offloading execution gain mainly includes two parts: absolute offloading execution gain and relative offloading execution gain. Absolute offloading execution gain refers to the actual benefits that can be obtained by offloading the task, including latency, energy consumption, or any gain recognized by the industry. In this embodiment, latency gain is used to quantify the absolute offloading execution gain. The formula for calculating the absolute offloading execution gain can be:

[0102]

[0103] Among them, Z abs (s i,x ,r j () represents the absolute unloading execution gain. The computational cost required to complete the subtask, f c The computing power of the target vehicle. To handle the amount of data that needs to be transferred for the subtask, g c The data transmission and reception rate of the target vehicle. For the computing power of the new RSU_MEC, s i,x For subtasks, r j For the new RSU_MEC.

[0104] In the formula for calculating the absolute unloading execution gain, This can be characterized as the time required for the sub-task to be performed by the target vehicle. It can characterize the time the target vehicle needs to wait when the task is unloaded by the new RSU_MEC; when the amount of data in the task calculation result is very small, the latency and energy consumption of the vehicle in the backhaul stage can be ignored, and only the two stages of task unloading and execution are calculated.

[0105] The second sub-step determines the relative unloading execution gain based on the unloading decision deadline of the sub-task and the time when the target vehicle C enters the new RSU_MEC service range.

[0106] In this embodiment, the relative unloading execution gain refers to the timeliness gain of the unloading decision. This embodiment incorporates the influence of the unloading decision deadline into the unloading execution gain, and the formula for calculating the relative unloading execution gain can be:

[0107]

[0108] Among them, Z rel (s i,x ,r j () represents the relative unloading execution gain. The deadline for the subtask unloading decision. The time s is the time when target vehicle C enters the new RSU_MEC service area. i,x For subtasks, r j For the new RSU_MEC.

[0109] In the formula for calculating the relative unloading execution gain, It can characterize the difference between the task's unloading decision deadline and the time when vehicle C enters the new RSU_MEC service area. The smaller the value, the closer the subtask's time is to the unload decision deadline when the target vehicle enters the new RSU_MEC service area. At this point, the risk of the subtask failing to unload is greater, the demand for unloading is stronger, and the corresponding relative unload gain is greater. When the target vehicle enters the service range of the new RSU_MEC, it means that the task's unloading decision deadline has arrived, and the relative unloading execution gain is equal to 0, indicating that the unloading of the subtask can no longer generate relative unloading gain.

[0110] The third sub-step involves determining the unloading execution gain corresponding to the subtask based on the absolute unloading execution gain, the relative unloading execution gain, and a pre-determined trade-off factor.

[0111] In this embodiment, the formula for calculating the offload execution gain corresponding to the subtask can be:

[0112] Z(s i,x ,r j ) = Z abs (s i,x ,r j )+α×Z rel (s i,x ,r j )

[0113] Wherein Z(s) i,x,r j Z represents the unloading execution gain corresponding to the subtask. abs (s i,x ,r j Z represents the absolute unloading execution gain. rel (s i,x ,r j ) represents the relative unloading execution gain, α is a predetermined tradeoff factor, and s i,x For subtasks, r j For the new RSU_MEC.

[0114] In the formula for calculating the unloading execution gain, the predetermined trade-off factor α∈(0,1) is the trade-off factor between the absolute unloading execution gain and the relative unloading execution gain. As the value of α increases from 0 to 1, the ratio of the relative unloading gain to the total gain increases continuously, indicating that the target vehicle gradually focuses on the unloading requirements of the sub-task.

[0115] The fourth sub-step involves determining the cumulative value of the unload execution gain corresponding to each subtask in the subtask package as the corresponding unload execution gain for that subtask package.

[0116] In this embodiment, for each subtask bag j,h ={s i,x |s i,x For any subtask in the package ∈S}, its unloading execution gain can be the sum of the unloading gains of all subtasks in the package, and its calculation formula can be:

[0117]

[0118] Among them, Z(bag j,h ,r j Z(s) represents the unloading execution gain corresponding to the subtask package. i,x ,r j ) represents the unloading execution gain corresponding to the subtask, indicating the unloading execution gain that the subtask can obtain by unloading through the new RSU_MEC. i,x For subtasks, r j For the new RSU_MEC.

[0119] It should be noted that the online task offloading decision problem for high-speed vehicles can be described as follows: within a certain offloading decision time period, the target vehicle continuously generates new execution tasks based on changes in the scenario and requirements. After passing through a heterogeneous RSU_MEC set, the online task offloading decision is determined. At this point, the target vehicle's offloading decision objective can be:

[0120]

[0121] Where M = {e(bagj,h ,r j )|bag j,h ∈S,r j ∈R,|bag j,h | rj}, M is the set of unloading strategies for the target vehicle, e(bag j,h ,r j ) is a single uninstallation strategy, compared to (bag) j,h ,r j Correspondingly, (bag) j,h ,r j The bag is an unload service pair consisting of a subtask package and the new RSU_MEC. j,h ={s i,x |s i,x ∈S,},bag j,h For the subtask package to be uninstalled to the new RSU_MEC, S is the updated set of tasks to be uninstalled. i,x For subtasks, r j For the new RSU_MEC, R is the updated set of RSU_MEC, |bag j,h | represents the number of subtasks contained in the subtask package, a rj For the new RSU_MEC offloading service capability, Z(bag j,h ,r j ) represents the unloading execution gain corresponding to the subtask package, MaxSum is the function for finding the maximum sum interval, and max is the function for finding the maximum value.

[0122] For a single unloading strategy e(bag) j,h ,r j The limitations on the possibility of its existence include:

[0123] Task type restriction C1, C1: Subtask type For the new RSU_MEC service task type, C all For the set of all task types, i.e., subtasks s i,x The type belongs to the task types that the new RSU_MEC can serve.

[0124] Decision-making time limit C2, C2: The deadline for the subtask unloading decision. The time when target vehicle C enters the new RSU_MEC service area is T, and the unloading decision time period is T. That is, the deadline for the unloading decision of the subtask should be later than the time when the target vehicle enters the new RSU_MEC service area.

[0125] ​Unload execution gain limit C3, C3:Z(bag) j,h ,r j Z(bag) > 0 j,h ,r j (bag) represents the unload execution gain corresponding to the subtask package. j,h ,r j The bag is an unload service pair consisting of a subtask package and the new RSU_MEC. j,h ={s i,x |s i,x ∈S,},bag j,h For the subtask package to be uninstalled to the new RSU_MEC, S is the updated set of tasks to be uninstalled. i,x For subtasks, r j The effective offload execution gain that can be obtained by executing the new RSU_MEC, i.e., the task package executed by the new RSU_MEC;

[0126] The new RSU_MEC offload service capability limitation C4, C4: |bag j,h | Can represent a subtask bag j,h The number of subtasks included. This can represent the maximum number of subtasks that RSU_MEC can unload, i.e., the subtask bag. j,h The number of subtasks included should be less than the new RSU_MEC offload service capacity.

[0127] The third step is to construct a new hyperedge corresponding to a new RSU_MEC if the unload execution gain of a certain subtask package meets the unload execution gain constraint condition, and add the new RSU_MEC hyperedge to the hyperedge set to obtain the hyperedge set corresponding to the weighted hypergraph, thereby constructing the weighted hypergraph.

[0128] In this embodiment, if the offload execution gain corresponding to a certain subtask package satisfies the offload execution gain constraint condition C3, an effective offload gain can be obtained, and a new RSU_MEC hyperedge e(bag) can be constructed. j,h ,r j ), and the superedge e(bag j,h ,r j Add to the new set of superedges corresponding to RSU_MEC In the middle. Finally, each r constructed j The corresponding set of hyperedges Add it to the set of superedges E of the weighted hypergraph G to obtain the weighted hypergraph G.

[0129] S5, based on the weighted hypergraph, execute the super-matching set construction module with the maximum weight to determine the super-matching set with the maximum weight of the weighted hypergraph.

[0130] In this embodiment, the main function of the supermatch set construction module is to use a greedy strategy to find the maximum weight b-supermatch of the weighted hypergraph G. Its input is the weighted hypergraph, and its output is the set of maximum weight b-supermatches, denoted as […]. The maximum weight b-supermatch set is the set of supermatches with the maximum weight in the weighted hypergraph. Specific implementation steps may include:

[0131] The first step is to sort the set of hyperedges in descending order according to the weight of each edge in the weighted hypergraph, thus obtaining the sorted set of hyperedges.

[0132] The second step involves iterating through the weighted hyperedge set, sorted in descending order, to determine if each hyperedge in the weighted hypergraph meets the matching criteria. If it does, the corresponding hyperedge is added to the hypermatch set with the highest weight.

[0133] S6. If the set of supermatches with the highest weight has a target unloading service pair, then the target unloading service pair is taken as the optimal online task unloading strategy.

[0134] Among them, the target unloading service pair is the unloading service pair associated with the new RSU_MEC.

[0135] S7. The target vehicle continuously passes through new RSU_MECs within the preset unloading decision time period. By repeatedly executing the information collection module, subtask package construction module, and weighted hypergraph construction module, the optimal online task unloading strategy corresponding to each new RSU_MEC is obtained.

[0136] In this embodiment, the target vehicle will continuously encounter new RSU_MECs while driving within the preset unloading decision time period. Each time a new RSU_MEC is encountered, steps 2 to 6 above are executed, and the process is repeated until the optimal online task unloading strategy corresponding to each new RSU_MEC within the preset unloading decision time period is obtained.

[0137] Thus, this embodiment has obtained the online unloading decision for the dependent task of high-speed vehicles within the preset unloading decision time period.

[0138] To verify the implementation effect of this embodiment, a task unloading decision scenario for a high-speed moving vehicle was built using Python. In each unloading decision cycle of the corresponding scenario, the total number of task types to be executed carried by the target vehicle is 10, i.e., |C all |=10. The target vehicle will continuously generate new tasks due to application requirements, and travels at a constant speed of 75km / h along the road, randomly encountering multiple heterogeneous RSU_MECs along the way. The service radius of the RSU_MEC is 500m. The main parameter settings are as follows: (1) Vehicle C: f c=10GCPUcycles / s, e c =0.3J / GCPUcycle, g c =150M / s, p c =10dBM. (2) Task: d s ∈[35,50]GCPUcycles, the DAG diagram of the set of tasks S to be executed carried by the vehicle at a certain moment is shown below. Figure 4 As shown, in Figure 4 In the diagram, task set S contains 5 tasks, each of which may contain multiple interdependent subtasks. Each circle represents a subtask, with the upper half of the circle representing the subtask number and the lower half representing the computational cost d required to complete that subtask. s b s ∈[45,75]MB,t s c is a random time within a time period T that satisfies a dependency relationship. s From C all (3) RSU_MEC: f r ∈[40,60]GCPUcycles / s,a r ∈[1,10],t r C is calculated by comprehensively considering the service range of RSU_MEC, vehicle speed, and the encounter order between vehicles and RSU_MEC. r For C all A randomly selected subset. The specific parameter settings for the 10 RSU_MEC values ​​are shown in Table 1.

[0139] Table 1

[0140] <![CDATA[r1]]> 46 8 {2,3,4,5,6,7,10} <![CDATA[r2]]> 50 4 {1,3,4,10} <![CDATA[r3]]> 58 10 {4,5,7,8} <![CDATA[r4]]> 42 10 {1,3,4,6,7,9} <![CDATA[r5]]> 41 8 {2,3,4,6,8,10} <![CDATA[r6]]> 41 4 {1,2,3} <![CDATA[r7]]> 50 5 {2,6,8} <![CDATA[r8]]> 57 10 {2,5,6,9,10} <![CDATA[r9]]> 43 9 {3,4,5,6,7} <![CDATA[r 10 ]]> 47 4 {1,3,4,7,8,9,10}

[0141] The DTOODA algorithm is compared with the Random_bag and Random_subtask algorithms for random subtask unloading. Random_bag involves creating several subtask packages based on the task set and the RSU_MEC when vehicle C encounters it, and then randomly selecting one subtask package from the set to unload to that RSU_MEC. Random_subtask involves randomly selecting multiple subtasks from the unloadable task subset when vehicle C encounters an RSU_MEC. All data used for the Random_bag and Random_subtask algorithms represents the average results of 100 experiments. The DTOODA algorithm is compared with the Random_bag algorithm to evaluate its performance; the Random_bag algorithm is compared with the Random_subtask algorithm to evaluate its subtask unloading performance. Furthermore, DTOODA_x% indicates that the vehicle uses the DTOODA algorithm, and when the vehicle encounters a new RSU_MEC, the ratio of the number of predictable RSU_MECs k to the total number of RSU_MECs m is x%.

[0142] When the tradeoff factor α = 0.5, the unloading decision results obtained by DTOODA_0% and DTOODA_5% are shown in Table 2:

[0143] Table 2

[0144]

[0145] Table 2 shows the unloading decision results obtained by DTOODA_0% and DTOODA_5% when the tradeoff factor α = 0.5. As shown in the table, when the vehicle reaches RSU_MECr1, the decision result obtained by DTOODA_0% is to move subtask s 1,2 Unload to r1, and the decision obtained by DTOODA_5% is to move subtasks s 1,2 s 1,3 and s 1,4 Uninstall to r1.

[0146] The trends of total offloading gain, absolute offloading gain, and relative offloading gain generated by DTOODA as a function of the tradeoff factor α are shown in the figure below. Figure 5 As shown, offloading_gain is the total offloading gain, offloading_gain_abs is the absolute offloading gain, and offloading_gain_rel is the relative offloading gain. Figure 5In the algorithm, when α = 0, the total unloading gain consists entirely of the absolute unloading gain; when α = 0.5, the total unloading gain is composed of half of the absolute and relative unloading gains, with DTOODA generating a total unloading gain of 117, an absolute unloading gain of 24, and a relative unloading gain of 186; when α = 1, the total unloading gain is the sum of the absolute and relative unloading gains. As the tradeoff factor α increases, the ratio of relative unloading gain to total gain continuously increases, indicating that the vehicle is increasingly emphasizing the impact of subtask unloading decision deadlines on task unloading decisions. Furthermore, as the tradeoff factor α increases, the relative unloading gain gradually increases, stabilizing when α > 0.5. This is because, with the relative unloading gain becoming more important, tasks are unloaded before reaching their unloading decision deadlines, and most tasks have fully acquired the relative unloading gain, which perfectly aligns with the expectations of the DTOODA algorithm.

[0147] The trend graphs of the total offloading gain and tradeoff factor α generated by DTOODA and the comparison algorithm are shown below. Figure 6 .exist Figure 6 In the data, the total unloading gain obtained by each algorithm increases sequentially from Random_subtask, Random_bag, DTOODA_0%, to DTOODA_5%. When α = 0.5, the total unloading gain obtained by DTOODA_0% and DTOODA_5% is 113 and 117, respectively, while the total unloading gain obtained by Random_bag is 51. This indicates that the DTOODA algorithm is superior to the Random_bag algorithm, meaning that weighted hypergraph matching can achieve better unloading gains for task unloading decisions, and the more RSU_MECs the vehicle is known to have, the greater the total unloading gain obtained by the unloading decision. The total unloading gain obtained by Random_subtask is 35, which is lower than that of the Random_bag algorithm, indicating that the Random_bag algorithm is superior to Random_subtask, meaning that the method of first building subtask packets and then making unloading decisions is better than making unloading decisions directly.

[0148] This invention provides an online task unloading decision-making method for high-speed vehicles, focusing on improving the timeliness of task unloading decisions and achieving unloading execution gains by addressing three key decision-making timeliness aspects. Specifically: First, an online unloading decision-making model for dependent sub-task packages of high-speed vehicles is established; then, the online task unloading decision-making problem for high-speed vehicles is transformed into an online resource allocation problem; finally, an online task unloading decision-making algorithm based on weighted hypergraph matching is proposed to obtain an online task unloading strategy. Therefore, the DTOODA method can assist vehicles in obtaining real-time online task unloading strategies and achieve task unloading execution gains far superior to random strategies.

[0149] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for online offloading decision-making of dependent tasks for high-speed vehicles, characterized in that, Includes the following steps: Obtain the set of tasks to be executed and the historical RSU_MEC set corresponding to the target vehicle within the preset unloading decision time period; wherein, the target vehicle is a high-speed vehicle carrying dependent tasks and constantly generating new tasks, and the RSU_MEC set is a combination of multiple heterogeneous roadside units and edge servers; When the target vehicle passes through the new RSU_MEC, the target vehicle execution information collection module obtains the updated set of tasks to be executed and the updated set of RSU_MEC corresponding to the target vehicle. Based on the updated set of tasks to be executed and the new RSU_MEC, the subtask package construction module is executed to determine the target subtask package set; wherein, the target subtask package set is the set of subtask packages carried by the target vehicle that can accept the new RSU_MEC service; Based on the target subtask package set and the updated RSU_MEC set, the weighted hypergraph construction module is executed to obtain the weighted hypergraph corresponding to the unloading decision time period. Based on the weighted hypergraph, the super-matching set construction module with the maximum weight is executed to determine the super-matching set with the maximum weight of the weighted hypergraph; If the super-match set with the highest weight has a target unloading service pair, the target unloading service pair is taken as the optimal online task unloading strategy for the corresponding new RSU_MEC; wherein, the target unloading service pair is the unloading service pair related to the new RSU_MEC; The target vehicle continuously passes through new RSU_MECs within the preset unloading decision time period. By repeatedly executing the information collection module, subtask package construction module, and weighted hypergraph construction module, the optimal online task unloading strategy corresponding to each new RSU_MEC is obtained. The implementation steps of the weighted hypergraph construction module include: The target subtask set is used as the left vertex set of the weighted hypergraph, and the updated RSU_MEC set is used as the right vertex set of the weighted hypergraph. Based on the left vertex set and the right vertex set, calculate the unload execution gain corresponding to each subtask package in the target subtask package set; If the unload execution gain corresponding to a certain subtask package meets the unload execution gain constraint, construct the corresponding new RSU_MEC hyperedge and add the new RSU_MEC hyperedge to the hyperedge set, thereby obtaining the hyperedge set corresponding to the weighted hypergraph and constructing the weighted hypergraph. The calculation steps for the unloading execution gain corresponding to each subtask package include: For any subtask in each subtask package, the absolute unloading execution gain is determined based on the computational load required to complete the subtask, the computing power and data transmission rate of the target vehicle, the amount of data to be transmitted when unloading the subtask, and the computing power of the new RSU_MEC. The relative unloading execution gain is determined based on the unloading decision deadline of the subtask and the time when the target vehicle enters the new RSU_MEC service area; The unloading execution gain corresponding to the subtask is determined based on the absolute unloading execution gain, the relative unloading execution gain, and the pre-determined trade-off factor. For any subtask package, the cumulative value of the unload execution gain corresponding to each subtask in the subtask package is determined as the unload execution gain corresponding to the subtask package.

2. The online offloading decision method for dependent tasks of high-speed vehicles according to claim 1, characterized in that, Obtain the historical RSU_MEC set corresponding to the target vehicle within the preset unloading decision time period, including: Estimate the number of RSU_MECs that the target vehicle will pass through during the preset unloading decision time period, calculate the product of the number of RSU_MECs and the preset probability factor, and use the product as the number of RSU_MECs that the target vehicle will pass through during the decision observation time period. Obtain the RSU_MEC set corresponding to each RSU_MEC passed by the target vehicle during the decision observation period, and combine the RSU_MEC sets corresponding to each RSU_MEC passed by during the decision observation period into a historical RSU_MEC set.

3. The online offloading decision method for dependent tasks of high-speed vehicles according to claim 1, characterized in that, The implementation steps of the information collection module include: Detect whether a new task set exists for the target vehicle. If a new task set exists, add the new task set to the set of tasks to be executed to obtain the updated set of tasks to be executed. Obtain the RSU_MEC set corresponding to the new RSU_MEC, and add the RSU_MEC set corresponding to the new RSU_MEC to the historical RSU_MEC set to obtain the updated RSU_MEC set.

4. The online offloading decision method for dependent tasks of high-speed vehicles according to claim 1, characterized in that, The implementation steps of the sub-task package construction module include: Based on the order level of each subtask in the updated set of tasks to be executed, the subtasks are topologically sorted to obtain a sorted set of tasks to be executed, and then transformed into a directed acyclic graph. For any task to be executed in a directed acyclic graph, select the subtask with the highest order level from the tasks to be executed, add the corresponding subtask to the sorted task set, remove all edges originating from the corresponding subtask from the edge set, and remove the corresponding subtask from the tasks to be executed. Based on the order level, determine whether each subtask in the sorted task set satisfies the task type constraints and latency constraints corresponding to the new RSU_MEC, and add the satisfying subtasks to the task subset that can accept the new RSU_MEC service. Obtain the probability factor of the number of subtask packages, and count the number of subtasks that can accept the new RSU_MEC service. The product of the probability factor of the number of subtask packages and the number of subtasks that can accept the new RSU_MEC service is determined as the number of subtask packages contained in the target subtask package set. Based on the order and level, each subtask in the subset of tasks that can accept the new RSU_MEC service is judged in turn, and each subtask package is assembled. If a subtask in the task subset has no predecessor task or its predecessor task is already in the current subtask package, a coin toss rule is used to determine whether to add the subtask to the current subtask package, thereby obtaining the target subtask package set.

5. The online offloading decision method for dependent tasks of high-speed vehicles according to claim 4, characterized in that, The task type constraint is that the subtask type belongs to the service task type of the new RSU_MEC; the delay constraint is that the deadline for the subtask to make the unloading decision is later than the time when the target vehicle enters the service range of the new RSU_MEC.

6. The online offloading decision method for dependent tasks of high-speed vehicles according to claim 1, characterized in that, The formula for calculating the absolute unloading execution gain is as follows: in, To achieve absolute unloading execution gain, The computational load required to complete the subtask. The computing power of the target vehicle. To account for the amount of data that needs to be transferred to unload the subtask, The data transmission and reception rate of the target vehicle. For the computing power of the new RSU_MEC, As a sub-task, For the new RSU_MEC; The formula for calculating the relative unloading execution gain is: in, To provide relative unloading execution gain, The deadline for the subtask unloading decision. The time it takes for target vehicle C to enter the new RSU_MEC service area. As a sub-task, For the new RSU_MEC; The formula for calculating the unloading execution gain corresponding to the subtask is: in, The unloading execution gain corresponding to the subtask. To achieve absolute unloading execution gain, To provide relative unloading execution gain, For predetermined trade-off factors, As a sub-task, For the new RSU_MEC.

7. The online offloading decision method for dependent tasks of high-speed vehicles according to claim 1, characterized in that, The unloading execution gain limitation condition is: in, This refers to the unload execution gain corresponding to the subtask package. The unload service pair consisting of the subtask package and the new RSU_MEC. , To unload the subtask package to the new RSU_MEC, This is the updated set of tasks to be uninstalled. As a sub-task, For the new RSU_MEC.

8. The online offloading decision method for dependent tasks of high-speed vehicles according to claim 1, characterized in that, The steps for determining the supermatch set construction module with the maximum weight include: Based on the weights of each edge in the weighted hypergraph, sort the hyperedge set in descending order to obtain the sorted hyperedge set. Sort the set of superedges in descending order, and iterate through them one by one to determine whether the superedges in the weighted supergraph meet the matching conditions. If they do, add the corresponding superedge to the super-matching set with the highest weight.

Images