Intelligent computing resource scheduling terminal of vehicle-cloud cooperation

Abstract

The application provides a kind of intelligent computing resource scheduling terminal of vehicle cloud cooperation, is deployed in edge cloud node, including full source data sensing and interactive interface, cognitive front-end processing, strategy reasoning decision, computing resource arrangement instruction distribution and performance monitoring and reward calculation module, can realize with scheduling task description generation and receive candidate computing node's node state report and maintain the resource index table of node, node matching feature extraction, target node decision, instruction issuing and execution feedback whole process operation.The application faces intelligent transportation, autonomous driving and other cross-domain collaborative tasks, and for the decision-making uncertainty area formed by the lack of priori discriminability of the execution side selection executed by the vehicle end / cloud end, through the priori matching evaluation of cognitive front-end and strategy reasoning cooperation, the decision-making computing burden of high-dimensional multi-source state can be reduced, and the risk of improper execution side selection can be reduced, so as to improve the computing real-time performance, success rate and system operation safety of vehicle cloud cooperation task.

Description

Technical Field

[0001] This invention belongs to the field of intelligent transportation infrastructure and mobile edge computing technology, and specifically relates to an intelligent computing resource scheduling terminal deployed on edge cloud nodes (such as MEC servers or roadside intelligent units) for realizing vehicle-cloud collaborative resource orchestration. Background Technology

[0002] In vehicle-road-cloud integrated systems, the edge cloud faces massive, high-concurrency heterogeneous computing task requests (such as collaborative perception, path planning, trajectory prediction, and traffic negotiation at intersections without signal control). To achieve optimal resource utilization and system performance, the industry generally adopts intelligent scheduling schemes based on deep reinforcement learning (DRL) or heuristic strategies.

[0003] However, existing dispatch terminals still suffer from the following technical bottlenecks:

[0004] The "curse of dimensionality" leads to delayed response: Traditional DRL terminals directly stitch together high-dimensional original environmental states (such as the location and speed of multiple vehicles, channel state, full perception and map information, etc.) and input them into the model, resulting in an expansion of the state space, high training and online inference overhead, and difficulty in meeting the real-time decision-making needs of the edge side.

[0005] Lack of task-related semantic filtering mechanism: Existing schedulers have difficulty distinguishing between data conditions that are "critical" to the current task (such as the data type required by the task, data freshness and completeness) and "irrelevant noise", which leads to trial and error in a large amount of invalid information and makes it difficult to achieve coupled scheduling of data conditions and computing power conditions.

[0006] Resource mismatch and insufficient prior prediction: Scheduling decisions often focus on computing power or network status, ignoring the constraint that "computation effectiveness is based on data availability." This can easily lead to tasks being scheduled to nodes with sufficient computing power but missing critical data, resulting in failure or a sharp drop in performance.

[0007] Unclear project output interfaces: Some solutions only provide abstract "actions" and lack orchestration instruction structures (such as target execution nodes, data indexes, authorization parameters, and rollback strategies) that can be directly connected to executors / execution platforms, which is not conducive to project deployment and closed-loop monitoring.

[0008] Therefore, there is an urgent need for an intelligent computing resource scheduling terminal deployed on edge cloud nodes. Through a hierarchical structure of "cognitive front-end + decision back-end", it can perform task-related quantitative evaluation of candidate nodes and output executable orchestration instructions to achieve efficient and reliable vehicle-cloud collaborative resource scheduling. Summary of the Invention

[0009] The present invention aims to at least partially solve one of the technical problems existing in the prior art.

[0010] To address this, the present invention provides an intelligent computing resource scheduling terminal for vehicle-cloud collaboration, deployed on edge cloud nodes, used to jointly quantify and evaluate the data status and computing / communication status of candidate computing nodes in a vehicle-cloud collaboration environment, determine the target execution node of the task and generate orchestration instructions, thereby reducing the risk of resource mismatch and improving scheduling reliability and efficiency.

[0011] To achieve the above objectives, the present invention adopts the following technical solution:

[0012] This invention provides an intelligent computing resource scheduling terminal for vehicle-cloud collaboration, deployed on an edge cloud node. The intelligent computing resource scheduling terminal includes:

[0013] The full-source data perception and interaction interface module is used to receive task requests from computing tasks to be scheduled and generate task descriptors, as well as to receive node status reports from candidate computing nodes and maintain the resource index table of candidate computing nodes.

[0014] The cognitive front-end processing module is used to generate salient features that characterize the matching quality between candidate computing nodes and tasks based on the task descriptor and the candidate computing node status in the resource index table.

[0015] The strategy reasoning and decision-making module is used to determine the target execution node based on the salient features;

[0016] The computing resource orchestration instruction distribution module is used to generate orchestration instruction packages and distribute the orchestration instruction packages to the executors of the target execution node;

[0017] The performance monitoring and reward calculation module is used to collect task execution results and generate performance feedback.

[0018] In some embodiments, the task descriptor includes at least: task identifier task_id, task type type, deadline, set of data types required by the task K_T, and minimum data completeness threshold required by the task comp_req, and preferably includes at least one of: maximum acceptable information age or freshness threshold AoI_max, computational demand intensity or complexity index workload, network QoS requirement net_req, and computational architecture preference arch_pref;

[0019] The node status report NodeStatusReport(j,t) includes at least: candidate compute node identifier node_id, candidate compute node type node_type, compute availability information comp_avail, network metric net_metric, and data availability field data_metric; wherein, the compute availability information comp_avail is used to characterize the current state of candidate compute node j. The available computing power level; the network metric net_metric includes at least one of the following: candidate computing nodes At the present moment Available bandwidth at the task initiator Round-trip delay and packet loss rate The node status reporting further includes at least two of the following: candidate computing nodes. At the present moment Available data types Candidate computing nodes For data types Latest update timestamp and candidate computing nodes At the present moment The set of holding data covers Or merge coverage set .

[0020] In some embodiments, the full-source data perception and interaction interface module is further configured to set a status timeout threshold for the resource index table. When a candidate computing node times out or network probe fails, the corresponding candidate computing node will be marked as unavailable or its salient features will be downgraded.

[0021] In some embodiments, generating salient features to characterize the matching quality between candidate computing nodes and tasks based on the task descriptor and the candidate computing node status in the resource index table includes:

[0022] A task requirement profile vector is generated based on the task descriptor, and then split into a data requirement sub-vector and a computation and communication requirement sub-vector.

[0023] Read the candidate computing node status from the node resource index table to form a candidate computing node status vector, and then split it into a data status sub-vector and a computing and communication status sub-vector.

[0024] The data potential value of the candidate computing node is generated based on the data requirement sub-vector and the data state sub-vector. The computation potential value of the candidate computing node is generated based on the computation and communication requirement sub-vector and the computation and communication state sub-vector. The two are coupled to obtain the decision saliency score of the candidate computing node. The saliency feature includes a feature vector composed of the decision saliency scores of multiple candidate nodes in the candidate computing node set.

[0025] In some embodiments, the coupling is multiplicative coupling, such that when either the data potential value or the computational potential value is close to zero, the decision significance score is close to zero.

[0026] In some embodiments, when generating data potential values ​​and calculating potential values, the cognitive front-end processing module performs element-wise modulation operations on the demand sub-vectors and state sub-vectors of candidate computing nodes of the same dimension; the element-wise modulation operation is preferably a Hadamard product element-wise multiplication operation.

[0027] In some embodiments, determining the target execution node based on the saliency feature includes: selecting the candidate computation node with the highest decision saliency score from the candidate node set as the target execution node.

[0028] In some embodiments, determining the target execution node based on the saliency feature includes: dividing the candidate computing node set into a vehicle-side candidate subset and an edge-side candidate subset according to node type; first performing a binary selection between the two subsets; and then selecting the target execution node from the selected subsets.

[0029] In some embodiments, the orchestration instruction package includes at least: task_id, target_node_id, validity_until, and fallback_policy;

[0030] The orchestration instruction package further includes at least one of the following: trace_id, retry_limit, data_index or cache hint, auth_token, reserve_params, and target_type;

[0031] The fallback policy includes at least one of the following: reselecting the target execution node after timeout or failure, retrying on the same target execution node under the constraint of the maximum number of retries (retry_limit), or degrading execution.

[0032] In some embodiments, the performance monitoring and reward calculation module is configured to generate a reward signal based on at least two of the following: latency utility, quality utility, energy consumption cost, resource utilization penalty, data scheduling cost, and violation penalty.

[0033] The strategy reasoning and decision-making module selects a learning strategy module, which is implemented using a deep reinforcement learning algorithm, including at least one of PPO, DQN, SAC, and DDPG; or, the strategy reasoning and decision-making module determines the target execution node based on deterministic selection rules.

[0034] The intelligent computing resource scheduling terminal for vehicle-cloud collaboration provided by this invention has the following features and beneficial effects:

[0035] 1. Improved reasoning efficiency: The cognitive front-end processing module quantifies, purifies, and pre-screens task-related features, compressing the high-dimensional original state into low-dimensional salient feature input, significantly reducing the decision computation load and improving real-time response capabilities in high-concurrency scenarios.

[0036] 2. Improved scheduling accuracy: The terminal is deployed on the edge cloud side, which can use regional status fusion and resource index information to jointly evaluate the data availability and computing / communication availability of candidate computing nodes, thereby reducing the risk of resource mismatch such as "sufficient computing power but insufficient data".

[0037] 3. Decoupling and Scalability of Architecture: The cognitive front-end processing module is responsible for deterministic quantitative evaluation and feature generation, while the strategy reasoning and decision-making module is responsible for strategy reasoning and uncertainty handling. The decoupling of the two enables the terminal to have both interpretability and adaptability, and supports binary vehicle / cloud optimization and multi-node expansion.

[0038] 4. Strong engineering feasibility: The output includes an orchestration instruction structure containing target execution nodes, validity periods, and rollback strategies, and forms a closed-loop feedback with performance monitoring, which facilitates system integration, operation and maintenance, and reliable operation. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the deployment location of the intelligent computing resource scheduling terminal provided in the vehicle-cloud collaborative general system architecture. The diagram shows the hierarchical structure and interaction relationship of physical space, network space, and information space.

[0040] Figure 2 This invention relates to the internal module composition and closed-loop data flow of an intelligent computing resource scheduling terminal provided in an embodiment of the invention. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the application will be described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0042] Conversely, this application covers any alternatives, modifications, equivalent methods, and schemes made within the spirit and scope of this application as defined by the claims. Furthermore, to provide the public with a better understanding of this application, certain specific details are described in detail below. However, this application can be fully understood by those skilled in the art even without these detailed descriptions.

[0043] The first aspect of this invention provides an intelligent computing resource scheduling terminal for vehicle-cloud collaboration, which is logically defined as a Computation Orchestration Agent (COA). This intelligent computing resource scheduling terminal is applied to applications such as... Figure 1 The autonomous driving vehicle-road-cloud collaborative system shown includes a regional cloud / central cloud application platform and a multi-access edge computing platform (MEC Platform) deployed in the information space, and N intelligent connected vehicles (Veh1, Veh2, ..., VehN) deployed in the physical space. Each intelligent connected vehicle acts as a core perception unit, collecting road traffic and environmental information in real time and interacting with the MEC Platform via a V2X wireless network with low latency. The MEC Platform runs downstream tasks crucial to autonomous driving, such as high-precision digital twin updates and collaborative perception fusion, and can interact with the higher-level regional cloud / central cloud application platform. The regional cloud / central cloud application platform issues macro-level driving tasks or strategies. Optionally, the autonomous driving vehicle-road-cloud collaborative system also includes a roadside unit (RSU) as a supplementary perception and communication node to enhance coverage in key areas. The data intelligent synchronization terminal provided in this embodiment is deployed on a corresponding intelligent connected vehicle and works collaboratively with the RSU, the MEC Platform, and the regional / central cloud application platform. The intelligent computing resource scheduling terminal (hereinafter referred to as "this terminal") provided in the first aspect of the present invention is typically deployed on edge cloud (MEC) nodes as a decision-making hub connecting physical space and information space. It is used to perform resource orchestration and scheduling decisions for computing tasks in a vehicle-cloud collaborative environment and to issue executable instructions to the executor.

[0044] Before describing the intelligent computing resource scheduling terminal for vehicle-cloud collaboration provided in the embodiments of the present invention, its deployment and external interaction, as well as the fields designed in the present invention, will be explained first.

[0045] I. Deployment and External Interaction

[0046] like Figure 1 As shown, this terminal is deployed on an edge cloud node and interacts with the vehicle-side actuator and the edge cloud actuator, including:

[0047] Vehicle-side uplink: Task requests and node status reporting (including data availability and computing power / network availability);

[0048] Local edge-side information: Edge cloud executor running status, (optional) regional fusion information summary / resource index information;

[0049] Terminal downlink: orchestrating instruction packets and rollback control instructions; and (optionally) reporting statistical and alarm information to the platform.

[0050] The decision output of this terminal preferably includes the target execution node identifier target_node_id, and optionally includes the target node type identifier target_type (e.g., vehicle side / edge side) for engineering compatibility.

[0051] II. The fields designed in this invention are as follows:

[0052] 1. TaskDescriptor(T): Task descriptor

[0053] It should include at least: task identifier (task_id), task type (type), deadline or time constraint information, set / index of data types required by the task (K_T), and minimum data completeness threshold (comp_req) required by the task.

[0054] Preferred criteria include: maximum acceptable information age or freshness threshold (AoI_max), computational demand intensity or complexity index (workload), network QoS requirement (net_req), and computational architecture preference (arch_pref).

[0055] Optional parameters include: priority / weight, input data index (data_index_in), and output data index (data_index_out).

[0056] 2. NodeStatusReport(j,t): Node status report

[0057] In this embodiment, NodeStatusReport(j,t) is used to characterize candidate computing nodes. At any moment The data availability and computing / communication availability status are used to enable the edge cloud-side scheduling terminal to evaluate candidate nodes and make orchestration decisions.

[0058] At least include (required fields):

[0059] node_id: Candidate compute node identifier, corresponding to j.

[0060] node_type: Candidate compute node type, used to distinguish at least vehicle-side nodes from edge-side nodes.

[0061] `comp_metric`: Computing availability information, used to characterize the available computing power level of candidate computing nodes. `comp_metric` must include at least one of the following: candidate computing nodes. Maximum computing power And the computing power occupied by candidate computing node j at the current time t. or candidate computing nodes At any moment Available computing power information comp_avail(j,t) (e.g., available computing power ratio or score), if reported simultaneously and This terminal can deduce available computing power; this invention does not limit the form of expression used.

[0062] net_metric: A network metric that includes at least one of the following: candidate compute nodes At the present moment Available bandwidth between the task initiator and the task initiator Candidate computing nodes At the present moment Round-trip latency between the task initiator and the task initiator The packet loss rate (or link packet loss statistics) of candidate computing node j at the current time t. .

[0063] data_metric: A data availability field, which must include at least one of the following: the availability of candidate compute node j at the current time. Available data types (Data type / data source type, such as radar point cloud, camera image, vehicle network message, map tile, etc. type index, used to characterize the types of data currently held or available to the node), candidate computing nodes For data types Latest update timestamp And the task-related data coverage set held by candidate computing node j at the current time t. (This can be represented in the form of a grid ID set, road segment ID set, object ID set, etc., and the present invention does not limit the expression form of the set elements) or the fusion result covering the set obtained by the candidate computing node j through multi-source fusion at the current time t. (This represents the area or set of objects covered by the merge trajectory / merge-occupied raster / merge target list). It should be noted that... Emphasis is placed on "holding original or unintegrated data coverage"; It emphasizes the coverage of "integrated and directly usable for task computing".

[0064] Preferred features include (enhanced fields):

[0065] NodeStatusReport(j,t) further includes at least two of the following fields: , , or ;

[0066] The network metric net_metric also includes and This is to improve the stability of network reachability assessment.

[0067] Optional fields include (engineering maintenance fields):

[0068] The NodeStatusReport(j,t) can optionally include at least one of the following fields: candidate compute node compute queue length or queue length (queue_len(j,t)), candidate compute node compute resource utilization. (Used to characterize the computational load level, preferably defined as) , where ε>0 is the zero-prevention constant; equivalent indicators such as CPU / GPU / NPU utilization can also be used, which are not limited in this invention), applicable to the vehicle-side energy / electrical state energy_state(j,t) of the vehicle-side node; data confidence or consistency score confidence(j,t) (applicable to systems with confidence assessment).

[0069] 3. OrchestrationCommand(T,t): Orchestration command package

[0070] It should include at least: task identifier (task_id), target execution node identifier (target_node_id), instruction validity deadline timestamp or instruction validity duration (valid_until), and fallback policy (fallback_policy). The instruction validity deadline timestamp or instruction validity duration (valid_until) is used to prevent risks caused by delayed execution of older instructions. valid_until is the deadline at which an instruction is considered valid on the executor side; if execution has not started by this time, it is discarded and the fallback policy is triggered. valid_until ensures that instructions do not expire in dynamic traffic / network environments, improving security and consistency.

[0071] Preferred values ​​include: trace_id (trace identifier) ​​and retry_limit (maximum number of retries).

[0072] Optional features include: target_type (selecting vehicle-side / edge-side), data_index (data index / caching hint), auth_token (execution authorization), and reserve_params (resource reservation parameters).

[0073] 4. fallback_policy: Fallback policy identifier

[0074] Preferred options include any one or a combination of the following: RESELECT (timeout / failure reselection), RETRY (retry within the same node under retry_limit constraints), and DEGRADE (degraded execution / conservative strategy).

[0075] See Figure 2 This terminal includes at least the following modules:

[0076] The full-source data perception and interaction interface module is used to receive task requests from computing tasks to be scheduled and generate task descriptors, as well as to receive node status reports from candidate computing nodes and maintain the resource index table of candidate computing nodes.

[0077] The cognitive front-end processing module is used to generate salient features that characterize the matching quality between candidate computing nodes and tasks, based on the task descriptors and the candidate computing node status in the resource index table.

[0078] The strategy reasoning and decision-making module is used to determine the target execution node identifier target_node_id based on the above salient features and strategy learning;

[0079] The computing resource orchestration instruction distribution module is used to generate an orchestration instruction package that includes at least a task identifier (task_id), a target execution node identifier (target_node_id), an validity period (valid_until), and a fallback policy (fallback_policy), and distribute the orchestration instruction package to the vehicle-side actuator or the edge cloud actuator.

[0080] The performance monitoring and reward calculation module is used to collect task execution results and generate performance feedback; when a learning strategy is adopted, it is used to further generate reward signals and feed them back to the strategy reasoning and decision-making module to update the strategy.

[0081] This terminal achieves a closed-loop process of "access—quantitative evaluation—decision-distribution—monitoring / feedback" through the above modules. The following section describes the inputs, outputs, data structures, and calculation processes of each module in the order that the project can be implemented.

[0082] In some embodiments, the full-source data perception and interaction interface module, such as Figure 2 As shown in the input layer on the left, this module is used to receive two types of input:

[0083] Task Request: The received task request Parsed as a task descriptor (T); the computing task to be scheduled is a micro-computation task generated by the vehicle based on perceived environmental information; or a macro-management computing task issued by the regional cloud or central cloud application platform, such as task type, priority, quality of service (QoS) requirements, etc.

[0084] Node status reporting: The received node status reports of each candidate compute node are parsed into node status reports NodeStatusReport(j,t), and a node resource index table ResourceIndexTable(j,t) is maintained. This refers to the current moment.

[0085] Furthermore, the full-source data perception and interaction interface module is used for each candidate computing node. The maintained resource index table ResourceIndexTable(j,t) is used to cache the latest status of candidate compute node j and provide it for subsequent modules to read. This resource index table is updated by the node status report NodeStatusReport(j,t). The full-source data awareness and interaction interface module sets the status timeout threshold. When candidate computing nodes are If a critical status is not reported within the time window or network probe fails, the candidate computing node is marked as unavailable or its significant features are downgraded to avoid using expired status.

[0086] Furthermore, the full-source data perception and interaction interface module maintains the candidate computing node set based on the received node status reports. ,in Indicates the candidate node identifier. The set of candidate compute nodes. It can be established and updated through registration, heartbeat, node status reporting, or platform distribution.

[0087] Furthermore, the full-source data perception and interaction interface module can optionally access regional fusion information summaries (such as coverage / freshness statistics of roadside fusion perception) and fuse them into ResourceIndexTable(j,t), thereby improving the data completeness and / or freshness evaluation quality of candidate computing nodes on the edge side.

[0088] In some embodiments, the cognitive front-end processing module, such as Figure 2 As shown in the middle section, this module, driven by the Goal-Directed Selective Attention Paradigm (GDSAP), purifies the "high-dimensional original input field" into "low-dimensional salient features." Let the current computational task be... The current time is The candidate node set is The computational process of the cognitive front-end processing module includes:

[0089] 1) Generate a task requirement profile vector from the task descriptor.

[0090] The cognitive front-end processing module extracts the task's data, computation, and communication requirements from the task descriptor (T) and generates a task requirement profile vector. And split into data requirement sub-vectors Subvectors for computation and communication requirements ,Right now Each component can be mapped from the task field and normalized to the [0,1] interval. This invention does not limit the mapping method, but requires that the profile vector can represent the relative strength of the task's constraints on data type, freshness and completeness, as well as on computing power and network service quality.

[0091] Furthermore, data requirement sub-vector Used for quantization calculation tasks The degree of dependence on data resources, Used for quantization calculation tasks The critical need for computing and communication resources. Preferred... and Set it to the following format:

[0092]

[0093] in: For data type demand intensity, The requirement for data freshness is strong; The required strength for data completeness;

[0094]

[0095] in: The strength of preference for computing architectures (such as CPUs, GPUs, and TPUs); The computational complexity metric for the computational task (normalized); The intensity of network service quality requirements (normalized).

[0096] Furthermore, the aforementioned dimensions can be obtained from task metadata through mapping and normalization. For example, suppose:

[0097] The set of data types required for computational tasks;

[0098] : The maximum acceptable age of information (AoI) for the calculation task, i.e., the upper limit of AoI;

[0099] The minimum data completeness requirement for a computation task can be directly given by the computation task, such as... =0.9 indicates that the task requires at least 90% of the relevant data to be executed;

[0100] : Estimate the floating-point computational load for the computational task;

[0101] : Calculate the network service quality thresholds or targets for the task, such as minimum rate / maximum latency / packet loss rate thresholds, etc.

[0102] The following mapping may be preferred (this is just an example and does not constitute a limitation):

[0103] Data type demand intensity :

[0104]

[0105] in, The number of parameter types is used for normalization.

[0106] Data freshness requirements intensity :

[0107]

[0108] in, For reference scale, It is the first zero constant.

[0109] Computational task computational complexity index :

[0110]

[0111] in, This is for reference calculation purposes.

[0112] Network service quality requirements intensity The value can be mapped to [0,1] based on the rate or latency requirements of the computation task, for example:

[0113]

[0114] in, This is the minimum rate requirement for the computation task. For reference rate.

[0115] It should be understood that the above mapping function can be replaced by any monotonic mapping and normalization method (such as exponential mapping, piecewise linear, Softmax, etc.), as long as the computational task's resource requirements for each dimension are quantified into a comparable standardized numerical vector.

[0116] 2) Generate node state vectors from node state reports.

[0117] The cognitive front-end processing module reads the candidate computing node states from the node resource index table ResourceIndexTable(j,t) to form a node state vector. :

[0118]

[0119] in:

[0120] Candidate computing nodes At the present moment The data state sub-vector, composed of data type coverage, freshness (e.g., mapped from the information age AoI calculated from timestamps), and data completeness or coverage, is used to describe the candidate computing nodes. Current data resource endowment;

[0121] Candidate computing nodes At the present moment The computational and communication state sub-vectors, formed by available computing power (e.g., calculated from maximum computing power and occupied computing power) and network quality (e.g., mapped from bandwidth, RTT, etc.), are used to describe the candidate computing node. Current computing and communication resource endowment.

[0122] Furthermore, to ensure feasibility, the preferred example calculation includes:

[0123]

[0124] in:

[0125] Indicates candidate computing nodes At the present moment The available data types are used to characterize the degree of matching between the types required for the computational task;

[0126] Indicates candidate computing nodes At the present moment The freshness of available data;

[0127] Indicates candidate computing nodes At any moment Data completeness, for example, if a computing task requires the fusion of data from intelligent physical entities A and B, but the candidate computing node only possesses data from intelligent physical entity A, then... .

[0128] And preferably set as follows:

[0129]

[0130] in:

[0131] Indicates candidate computing nodes At the present moment The physical architecture type capability is used to measure the degree of matching with computing task architecture preferences;

[0132] Indicates candidate computing nodes At the present moment Available computing power (normalized);

[0133] Indicates candidate computing nodes At the present moment Network service quality capabilities (normalized).

[0134] It should be noted that in this embodiment, network reachability is intrinsically considered as part of the node's computing state: if a node has extremely poor network connectivity, then the node's "effective computing power" for offloading tasks approaches zero.

[0135] Furthermore, the above dimensions can be calculated as follows (this is just an example and does not constitute a limitation):

[0136] Candidate computing nodes At the present moment The available data types are The data types required for the task are: ,but:

[0137]

[0138] in, This is the second zero-constant;

[0139] Candidate computing nodes For data types The latest update timestamp is Candidate computing nodes At the present moment For data types Information age is Then the preferred option is:

[0140]

[0141]

[0142] in, This is the freshness decay coefficient. It is the third zero constant.

[0143] The data set related to the design calculation task is as follows: Candidate computing nodes At the present moment The data coverage set is Then the preferred option is:

[0144]

[0145] in, It is the fourth zero constant.

[0146] Candidate computing nodes The maximum computing power is At the current moment computing power consumption ,but:

[0147]

[0148] in, It is the fifth zero constant.

[0149] set up Candidate computing nodes exist The available bandwidth at the time of task initiation is The reference bandwidth is ,but:

[0150]

[0151] in, It is the sixth zero constant.

[0152] Candidate computing nodes exist Physical architecture type capability at any moment It can be preferably defined as a binary or hierarchical matching score, for example, taking 1 when the candidate computing node has a computing architecture with task preference, and otherwise taking 0 or a lower hierarchical value.

[0153] 3) Calculate potential and significance scores.

[0154] The cognitive front-end processing module processes each candidate computing node At the present moment Each generates and computes a separate task. Related data potential value And calculate potential value In a preferred embodiment of the present invention, the potential calculation adopts the method of "element-wise modulation + weighted aggregation + mapping to [0,1]", wherein " "Indicates element-wise modulation (preferably element-wise multiplication)," "Indicates weighted summation, The data potential weight vector represents the function (preferably Sigmoid) mapping to [0,1]. Calculate the potential weight vector This can be achieved through presets or learning:

[0155]

[0156]

[0157] Candidate computation nodes are generated through multiplication coupling. At the present moment For computational tasks decision significance score :

[0158]

[0159] It is understandable that multiplicative coupling causes the data potential value to... Or calculate potential value When any value is close to zero, the decision significance score is... The near-zero value indicates that the multiplicative coupling embodies the principle of "neither can be missing": when either the data potential or the computational potential is insufficient, the overall score decreases significantly, thereby suppressing resource mismatch nodes.

[0160] The cognitive front-end processing module assembles the decision significance scores of all candidate computation nodes into a low-dimensional feature vector, denoted as the significant feature vector: The result is then output to the strategy reasoning and decision-making module.

[0161] In some embodiments, see Figure 2 The strategy reasoning and decision-making module receives the salient feature vector output by the cognitive front-end processing module. Output the target execution node identifier target_node_id= .

[0162] Furthermore, in a general implementation, the strategy reasoning decision module can directly select the optimal option:

[0163]

[0164] In a preferred embodiment, to ensure a clear engineering interface, candidate computing nodes can be first grouped according to node type. The candidate subsets are divided into vehicle-side candidate subsets and edge-side candidate subsets. After binary grouping, the best candidate is selected within each group. .

[0165] In a preferred embodiment, this strategy reasoning and decision-making module may be a learning strategy module (preferably employing, for example...). Figure 2 The PPO / Actor-Critic structure shown can optionally employ DQN, SAC, or DDPG. As the current state input, through forward reasoning, the current computational orchestration and scheduling actions are obtained. The output is the result of selecting the target execution node, i.e. And iterative optimization is carried out in conjunction with feedback from the performance monitoring and reward calculation modules;

[0166] It should be noted that this invention does not limit the use of a learning-based strategy module; deterministic rules are also an implementation method.

[0167] In some embodiments, the computing resource orchestration instruction distribution module is used to distribute the target execution node identifier target_node_id output by the strategy reasoning and decision-making module. This is encapsulated as an orchestration command package, `OrchestrationCommand(T,t)`, and then sent to the corresponding executor. This is a task identifier to be executed. For the current moment, For at any time The identified target execution node identifier. The orchestration instruction package must include at least: task identifier (task_id), target execution node identifier (target_node_id), instruction validity period (valid_until), and fallback policy (fallback_policy).

[0168] valid_until is used to characterize the valid deadline (or valid duration) of the orchestration instruction. If the executor has not started executing the corresponding task after valid_until, it is preferable to discard the instruction and trigger a rollback process to avoid the risk of expired instructions being delayed in dynamic environments.

[0169] Furthermore, the orchestration instruction package preferably includes the trace_id identifier and the retry_limit maximum number of retries to support cross-end tracing and retry control; the orchestration instruction package may also optionally include the target_type identifier (vehicle-side / edge-side) for engineering compatibility and fast route verification, but target_type is not a required field.

[0170] When a task times out or fails, this module performs a fallback operation based on the fallback policy. This fallback operation preferably includes one of the following: RESELECT (reselecting the target execution node), triggered by the computational resource orchestration instruction distribution module, with the policy reasoning and decision-making module regenerating the target execution node identifier (target_node_id) based on the updated environment state; RETRY (retrying on the same target_node_id under the retry_limit constraint); or DEGRADE (switching to a preset conservative execution policy, such as forcing execution on the vehicle side or using the default policy). Simultaneously, this module records event logs and link tracing information related to this fallback process for subsequent evidence collection and operational analysis.

[0171] In some embodiments, such as Figure 2 As shown on the right, the performance monitoring and reward calculation module collects task execution results and generates feedback. Preferably, the reward can be written as:

[0172]

[0173] in, For the reward function; For time delay effect, For quality and utility, For energy consumption costs, Punishment for resource utilization For data scheduling costs, Penalties for violations (e.g., data conditions not being met or latency exceeding constraints).

[0174] In the learning-based strategy implementation, this performance monitoring and reward calculation module forms experience tuples. This is used for policy updates in the policy reasoning and decision-making module; in the deterministic policy implementation, the experience tuple... Used for monitoring, alarms, and parameter tuning.

[0175] The operation process of the intelligent computing resource scheduling terminal provided in this embodiment of the invention includes the following steps:

[0176] Downlink data stream: N vehicle terminals in the physical space upload sensing information summaries or task requests via 4G / 5G networks.

[0177] Upstream data stream: The regional cloud platform distributes macro-level traffic status or integrated data indexes.

[0178] Orchestration decision: Based on the above information, the intelligent computing resource scheduling terminal performs GDSAP calculation and DRL inference, and the generated orchestration instruction packets are sent to the vehicle executor or directly to the edge executor via wireless network.

[0179] Validity verification of the embodiments of the present invention:

[0180] The technical solution of this application was logically verified in a vehicle-cloud collaborative high-fidelity simulation environment (SUMO and Carla joint simulation). Compared with traditional terminals without a cognitive front end, this terminal, through a two-layer architecture design, significantly improves the task execution success rate in heterogeneous resource environments and effectively optimizes the overall utilization efficiency of computing resources.

[0181] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0182] Although embodiments of this disclosure have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this disclosure, the scope of which is defined by the claims and their equivalents.

Claims

1. A vehicle-cloud collaborative intelligent computing resource scheduling terminal, characterized in that, Deployed on edge cloud nodes, the intelligent computing resource scheduling terminal includes: The full-source data perception and interaction interface module is used to receive task requests from computing tasks to be scheduled and generate task descriptors, as well as to receive node status reports from candidate computing nodes and maintain the resource index table of candidate computing nodes. The cognitive front-end processing module is used to generate salient features that characterize the matching quality between candidate computing nodes and tasks based on the task descriptor and the candidate computing node status in the resource index table. The strategy reasoning and decision-making module is used to determine the target execution node based on the salient features; The computing resource orchestration instruction distribution module is used to generate orchestration instruction packages and distribute the orchestration instruction packages to the executors of the target execution node; The performance monitoring and reward calculation module is used to collect task execution results and generate performance feedback.

2. The terminal according to claim 1, characterized in that, The task descriptor includes at least: task identifier task_id, task type type, deadline, set of data types required by the task K_T, and minimum data completeness threshold comp_req required by the task, and preferably includes at least one of: maximum acceptable information age or freshness threshold AoI_max, computational demand intensity or complexity index workload, network QoS requirement net_req, and computational architecture preference arch_pref. The node status report NodeStatusReport(j,t) includes at least: candidate compute node identifier node_id, candidate compute node type node_type, compute availability information comp_avail, network metric net_metric, and data availability field data_metric; wherein, the compute availability information comp_avail is used to characterize the current state of candidate compute node j. The available computing power level; the network metric net_metric includes at least one of the following: candidate computing nodes At the present moment Available bandwidth at the task initiator Round-trip delay and packet loss rate The node status reporting further includes at least two of the following: candidate computing nodes. At the present moment Available data types Candidate computing nodes For data types Latest update timestamp and candidate computing nodes At the present moment The set of holding data covers Or merge coverage set .

3. The terminal according to claim 1, characterized in that, The full-source data perception and interaction interface module is also used to set a status timeout threshold for the resource index table. When a candidate computing node times out or network probe fails, the corresponding candidate computing node will be marked as unavailable or its salient features will be downgraded.

4. The terminal according to claim 1, characterized in that, The step of generating salient features to characterize the matching quality between candidate computing nodes and tasks based on the task descriptor and the candidate computing node status in the resource index table includes: A task requirement profile vector is generated based on the task descriptor, and then split into a data requirement sub-vector and a computation and communication requirement sub-vector. Read the candidate computing node status from the node resource index table to form a candidate computing node status vector, and then split it into a data status sub-vector and a computing and communication status sub-vector. The data potential value of the candidate computing node is generated based on the data requirement sub-vector and the data state sub-vector. The computation potential value of the candidate computing node is generated based on the computation and communication requirement sub-vector and the computation and communication state sub-vector. The two are coupled to obtain the decision saliency score of the candidate computing node. The saliency feature includes a feature vector composed of the decision saliency scores of multiple candidate nodes in the candidate computing node set.

5. The terminal according to claim 4, characterized in that, The coupling is a multiplicative coupling, such that when either the data potential value or the computational potential value is close to zero, the decision significance score is close to zero.

6. The terminal according to claim 4 or 5, characterized in that, When generating data potential values ​​and calculating potential values, the cognitive front-end processing module performs element-wise modulation operations on the demand sub-vectors and state sub-vectors of candidate computing nodes of the same dimension; the element-wise modulation operation is preferably the Hadamard product element-wise multiplication operation.

7. The terminal according to claim 1, characterized in that, The step of determining the target execution node based on the saliency feature includes: selecting the candidate computation node with the largest decision saliency score from the candidate node set as the target execution node.

8. The terminal according to claim 1, characterized in that, Determining the target execution node based on the saliency features includes: dividing the candidate computing node set into a vehicle-side candidate subset and an edge-side candidate subset according to node type; first performing a binary selection between the two subsets; and then selecting the optimal target execution node within the selected subset.

9. The terminal according to claim 1, characterized in that, The orchestration instruction package includes at least: task identifier task_id, target execution node identifier target_node_id, validity period valid_until, and fallback policy fallback_policy; The orchestration instruction package further includes at least one of the following: trace_id, retry_limit, data_index or cache hint, auth_token, reserve_params, and target_type; The fallback policy includes at least one of the following: reselecting the target execution node after timeout or failure, retrying on the same target execution node under the constraint of the maximum number of retries (retry_limit), or degrading execution.

10. The terminal according to claim 1, characterized in that, The performance monitoring and reward calculation module is configured to generate a reward signal based on at least two of the following: latency utility, quality utility, energy consumption cost, resource utilization penalty, data scheduling cost, and violation penalty. The strategy reasoning and decision-making module selects a learning strategy module, which is implemented using a deep reinforcement learning algorithm, including at least one of PPO, DQN, SAC, and DDPG; or, the strategy reasoning and decision-making module determines the target execution node based on deterministic selection rules.

Images