Vehicle control processing method and device, computer device, readable storage medium and program product

Abstract

The application relates to a vehicle control processing method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: in response to a vehicle control intention triggering event of a target vehicle, acquiring multi-source feature information corresponding to the target vehicle, and determining a plurality of candidate vehicle control intentions matched with the target vehicle; for each candidate vehicle control intention, determining an expected occurrence probability of the candidate vehicle control intention based on the multi-source feature information; for each vehicle control resource used for triggering a vehicle control operation, determining a resource preparation priority of the vehicle control resource based on the expected occurrence probability of the candidate vehicle control intention associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intention; the resource preparation priority is positively correlated with the expected occurrence probability and the association strength; and each vehicle control resource is preloaded according to the resource preparation priority. The method can improve the processing efficiency.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a vehicle control processing method, device, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology and the widespread adoption of smart mobile terminals, remote vehicle control functionality based on V2X apps has become an important part of the user experience for intelligent connected vehicles. Currently, mainstream V2X apps typically integrate multiple remote vehicle control capabilities, such as unlocking, locking, air conditioning control, remote vehicle location, charging control, and vehicle status monitoring. Users expect to be able to quickly access the remote vehicle control homepage and instantly complete the desired vehicle control operation after opening the app.

[0003] However, traditional solutions typically load resources at the page or module level, or preload the entire app at the application level. Their loading strategies cannot be as fine as the specific vehicle control function level. As a result, the resources corresponding to the high-probability vehicle control functions that users are most likely to use in the current session cannot be loaded or prepared first. The first screen area of ​​the vehicle control function often has to wait for a large number of irrelevant resources to be loaded before it can enter the operable state, thus prolonging the user's actual waiting time and resulting in low efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a vehicle control processing method, device, computer equipment, computer-readable storage medium, and computer program product that can improve efficiency in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a vehicle control processing method, including:

[0006] In response to a vehicle control intention trigger event for a target vehicle, multi-source feature information corresponding to the target vehicle is obtained, and multiple candidate vehicle control intentions matching the target vehicle are determined.

[0007] For each candidate vehicle control intention, the expected probability of occurrence of the candidate vehicle control intention is determined based on the multi-source feature information;

[0008] For each vehicle control resource used to trigger a vehicle control operation, the resource preparation priority of the vehicle control resource is determined based on the expected occurrence probability of the candidate vehicle control intent associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intent; the resource preparation priority is positively correlated with both the expected occurrence probability and the association strength.

[0009] According to the resource preparation priority, the vehicle control resources are preloaded.

[0010] In one embodiment, determining the resource preparation priority of the vehicle control resource based on the expected occurrence probability of the candidate vehicle control intention associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intention includes:

[0011] Candidate vehicle control intentions whose expected probability of occurrence meets the probability condition are selected as vehicle control intentions;

[0012] From the various vehicle control resources, select the vehicle control resources that are associated with the selected vehicle control intention;

[0013] The resource preparation priority of the selected vehicle control resources is determined based on the correlation strength between the selected vehicle control resources and the selected vehicle control intention, as well as the expected probability of the selected vehicle control intention occurring.

[0014] The step of preloading each of the vehicle control resources according to the resource preparation priority includes:

[0015] According to the resource preparation priority, preload the selected vehicle control resources as described above.

[0016] In one embodiment, the candidate vehicle control intentions include no vehicle control intention; determining the candidate vehicle control intentions whose expected probability of occurrence satisfies the probability condition as the selected vehicle control intentions includes:

[0017] The candidate vehicle control intention with the highest expected probability of occurrence is identified as the first vehicle control intention;

[0018] If the expected probability of the first vehicle control intention is higher than a first threshold and the expected probability of the no vehicle control intention is lower than a second threshold, a selected vehicle control intention including the first vehicle control intention is determined; the first threshold is greater than the second threshold.

[0019] In one embodiment, determining the resource preparation priority of the selected vehicle control resource based on the correlation strength between the selected vehicle control resource and the selected vehicle control intention, and the expected probability of the selected vehicle control intention occurring, includes:

[0020] For each selected vehicle control resource, the expected reuse benefit of the selected vehicle control resource is determined by calculating the correlation strength between the selected vehicle control resource and the selected vehicle control intention, as well as the expected probability of the selected vehicle control intention occurring.

[0021] Based on the successor-successor relationship between the selected vehicle control resources and other selected vehicle control resources, and the expected reuse benefits, the resource preparation priority of the selected vehicle control resources is determined.

[0022] In one embodiment, the step of preloading each of the vehicle control resources according to the resource preparation priority includes:

[0023] Obtain the resource usage limit of the target vehicle and the resource usage of each vehicle control resource;

[0024] According to the resource preparation priority, the resource usage of each vehicle control resource is added up in sequence. If the total resource usage after addition is less than or equal to the resource usage limit, the vehicle control resource after addition is used as the preloaded vehicle control resource to be preloaded first.

[0025] After any of the preloaded vehicle control resources has been preloaded, other vehicle control resources are preloaded according to the resource preparation priority, under the constraint of the resource usage limit.

[0026] In one embodiment, the multi-source feature information includes vehicle control feature information corresponding to each of multiple vehicle control features; determining the expected occurrence probability of the candidate vehicle control intention based on the multi-source feature information includes:

[0027] Based on the basic bias of the candidate vehicle control intention, each of the vehicle control feature information, and the weight of each of the vehicle control feature information for the candidate vehicle control intention, the intention score of the candidate vehicle control intention is determined.

[0028] Based on the score ratio of each of the aforementioned intentions, the expected probability of occurrence of the candidate vehicle control intention is determined.

[0029] Secondly, this application also provides a vehicle control processing device, including:

[0030] The multi-source feature information acquisition module is used to acquire multi-source feature information corresponding to the target vehicle in response to a vehicle control intention triggering event for the target vehicle, and to determine multiple candidate vehicle control intentions that match the target vehicle.

[0031] The expected occurrence probability determination module is used to determine the expected occurrence probability of each candidate vehicle control intention based on the multi-source feature information.

[0032] The resource preparation priority determination module is used to determine the resource preparation priority of each vehicle control resource used to trigger vehicle control operation based on the expected occurrence probability of the candidate vehicle control intention associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intention; the resource preparation priority is positively correlated with both the expected occurrence probability and the association strength.

[0033] The resource preloading module is used to preload each of the vehicle control resources according to the resource preparation priority.

[0034] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method described above.

[0035] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the method described above.

[0036] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the method described above.

[0037] The aforementioned vehicle control processing method, device, computer equipment, computer-readable storage medium, and computer program product, by acquiring multi-source feature information corresponding to the target vehicle in response to a vehicle control intention trigger event, can proactively perceive the current vehicle control scenario context before the user's actual operation, providing a timely and multi-dimensional data foundation for subsequent intention prediction. Based on acquiring multi-source feature information, by identifying multiple candidate vehicle control intentions matching the target vehicle, and determining the expected probability of each candidate vehicle control intention based on multi-source feature information, it can quantify fuzzy scenario information into a specific expected probability distribution, achieving accurate characterization and quantitative evaluation of the vehicle control action most likely to be performed by the user. After obtaining the expected probability of each candidate vehicle control intention, by targeting each vehicle control resource used to trigger the vehicle control operation, based on the expected probability of the candidate vehicle control intentions associated with that vehicle control resource and the relationship between that vehicle control resource and its associated candidate vehicle control intentions... The correlation strength of the vehicle control intent determines the resource preparation priority of that vehicle control resource. This ensures that the preparation priority of each vehicle control resource reflects both the user's demand intensity for the intent associated with that resource and the resource's importance in completing that intent, thus achieving precise quantification of resource priority. Since the resource preparation priority is positively correlated with both the expected probability of occurrence and the correlation strength, high-probability intents rely on high-correlation-strength resources, which automatically receive a higher loading order. This allows limited loading resources to be allocated to the most urgent and important vehicle control functions. Finally, by preloading each vehicle control resource according to its resource preparation priority, the core resources corresponding to the vehicle control function that the user is most likely to execute can be prepared first. The first screen area of ​​this vehicle control function can become operable in a shorter time, thereby shortening the overall waiting time from opening the app to completing the target vehicle control operation without requiring additional user intervention, and improving processing efficiency. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is an application environment diagram of the vehicle control processing method in one embodiment;

[0040] Figure 2 This is a flowchart illustrating a vehicle control processing method in one embodiment;

[0041] Figure 3 This is a structural diagram of the vehicle control processing system in one embodiment;

[0042] Figure 4 This is a flowchart illustrating the vehicle control processing method in another embodiment;

[0043] Figure 5 This is a structural block diagram of the vehicle control processing device in one embodiment;

[0044] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0046] The vehicle control processing method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on the cloud or other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Specifically, the vehicle control intention trigger event can be triggered in terminal 102. In response to the vehicle control intention trigger event, server 104 obtains multi-source feature information corresponding to the target vehicle and determines multiple candidate vehicle control intentions that match the target vehicle. For each candidate vehicle control intention, the expected occurrence probability of the candidate vehicle control intention is determined based on the multi-source feature information. For each vehicle control resource used to trigger the vehicle control operation, the resource preparation priority of the vehicle control resource is determined based on the expected occurrence probability of the candidate vehicle control intention associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intention. The resource preparation priority is positively correlated with both the expected occurrence probability and the association strength. Each vehicle control resource is preloaded according to its preparation priority.

[0047] In one exemplary embodiment, such as Figure 2 As shown, a vehicle control processing method is provided, which is applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps S202 to S208. Wherein:

[0048] Step S202: In response to the vehicle control intention trigger event for the target vehicle, obtain multi-source feature information corresponding to the target vehicle and determine multiple candidate vehicle control intentions that match the target vehicle.

[0049] Among them, vehicle control intent triggering events refer to various pre-emptive signals or opportunities used to initiate the intent prediction process before the user actually initiates a remote vehicle control command. Their function is to determine when to begin subsequent intent prediction and resource preparation, so as to gain a pre-loading time window before the user actually operates. For example, a trigger detection module can detect whether the vehicle control intent prediction stage has begun at times such as APP launch, switching from the background to the foreground, entering the homepage, entering the vehicle page, vehicle status refresh completion, and exposure of the vehicle control entry point. That is, the prediction process is triggered when at least one of the following events occurs in the connected car APP: APP launch; APP returning to the foreground from the background; entering the homepage or vehicle page; vehicle status refresh completion; exposure of the remote vehicle control entry point; and a pre-judgment window before the user enters the primary remote vehicle control entry point. The target vehicle refers to the specific vehicle that the user has bound or selected to operate through the connected car APP.

[0050] Multi-source feature information refers to various contextual information collected from different data sources that is related to a user's possible vehicle control behavior. It encompasses user behavior features describing user operation patterns, vehicle status features describing the real-time physical and logical state of the vehicle, and operating environment features describing the current device and network environment. User behavior features include, but are not limited to: the type of the most recent N vehicle control operations; the time of the most recent vehicle control operation; the path of the most recently visited page; historically frequently used vehicle control functions; statistics on vehicle control preferences within a specified time period; and the source of the most recent remote vehicle control entry click. Vehicle status features include, but are not limited to: vehicle online status; door lock status; air conditioning status; charging status; battery level or remaining range; the time of the most recent vehicle status update; and the inference results of vehicle location-related status or proximity status. Operating environment features include, but are not limited to: network type; network quality; device performance level; current time period; current region or link environment; APP version or resource cache availability; and external environmental contextual information related to vehicle control needs, such as ambient temperature, weather conditions, or seasonal information.

[0051] Candidate vehicle control intentions refer to one or more specific remote vehicle control actions that a user may perform at the current moment, preliminarily determined by analyzing multi-source features. For example, candidate vehicle control intentions include, but are not limited to: turning on the air conditioning; turning off the air conditioning; unlocking the vehicle; locking the vehicle; checking the charging status; starting charging; stopping charging; remotely locating the vehicle; checking the vehicle status; other vehicle control intentions, serving as a fallback action label when not listed separately by the aforementioned actions; and no vehicle control intentions, serving as a background label when the user does not perform any vehicle control action within the prediction window. "No vehicle control intentions" are not mapped to dedicated vehicle control resources; when their probability is high, only general vehicle control basic resources and necessary lightweight state resources are allowed into the conservative orchestration path. "Other vehicle control intentions" may only be mapped to general vehicle control basic resources, or, after further subdivision of business configuration, to be mapped to corresponding dedicated resources. The rule-based scoring model and the optional machine learning model use the same set of labels to ensure that the two types of probabilities can be fused label by label.

[0052] Specifically, in this step, the server first continuously listens to or detects various signals to determine whether the conditions for entering the vehicle control intention prediction stage are met. These triggering events may include, but are not limited to: the user launching the APP, the APP being switched from the background to the foreground, the user entering the homepage or vehicle homepage in the APP, the vehicle status information being refreshed, the remote vehicle control entrance being exposed on the screen but not yet clicked by the user, or a brief prediction window before the user enters the primary remote vehicle control entrance. After the triggering conditions are met, the server immediately begins to acquire multi-source feature information related to the current target vehicle. This step aims to collect all information that may be valuable for predicting the user's next vehicle control action. After acquiring the above raw features, the server needs to perform a series of preprocessing operations on them to form a standardized feature vector that can be used by the subsequent scoring model. First, the server checks the acquisition time or status update time of each feature and determines whether it is still valid based on its preset validity period. Expired features are removed or marked as invalid. Second, for features that failed to be acquired or are missing, the server sets a missing flag and processes them by using a preset neutral value, the most recent valid value, or by excluding them from the current scoring round, depending on the feature type, to avoid overall prediction failure due to the absence of individual features. Subsequently, the server normalizes continuous features (such as temperature, latency, and historical operation count) according to preset upper and lower bounds, mapping their values ​​to the range of 0 to 1. Discrete features (such as door lock status, air conditioning status, charging status, and network type) are enumerated or one-hot encoded to convert them into a form that can participate in mathematical operations. Furthermore, for the user's historical vehicle control behavior records, the server exponentially decays the behavior based on its proximity to the current moment, reflecting the higher reference value of recent behavior for predicting the current intention. For example, for the nth historical behavior, the decay value h_n = exp(-Δt_n / τ) can be used, where Δt_n is the time difference between the behavior and the current prediction moment, and τ is the time decay parameter; alternatively, time-segmented counting or weighted summation of the most recent N behaviors can be used. Finally, the processed features are concatenated into a complete feature vector X in a preset order, and a corresponding validity vector V is generated to identify whether each feature dimension is valid and usable.

[0053] Based on this, the server also generates an intent availability mask A_i according to the vehicle's current real-time status. This mask is used in subsequent intent scoring processes to mark certain vehicle control intents that conflict with the current physical state of the vehicle as unavailable or to exclude them directly, thereby avoiding the output of unreasonable prediction results. For example, when the vehicle is unlocked, "unlock vehicle" can be marked as unavailable or its score reduced; when the vehicle is not connected to a charging device, "stop charging" can be marked as unavailable. The availability mask is used to avoid outputting candidate intents that conflict with the current state of the vehicle based solely on historical preferences.

[0054] Finally, based on the feature vector and intent availability mask obtained after the above processing, the server determines multiple candidate vehicle control intent types that match the current target vehicle by querying the preset vehicle control intent label system, which serve as the basis for subsequent probability calculation and resource orchestration.

[0055] Step S204: For each candidate vehicle control intention, determine the expected probability of occurrence of the candidate vehicle control intention based on multi-source feature information.

[0056] The expected occurrence probability refers to the quantified value of the likelihood that a user will actually execute a candidate vehicle control intention at the current moment, calculated based on currently acquired multi-source feature information and preset scoring rules or models. This probability reflects the quantified confidence level in the user's behavioral tendencies.

[0057] Specifically, after determining the set of candidate vehicle control intentions, the server further calculates the expected probability of each candidate intention being actually executed by the user in the current scenario, based on the processed feature information obtained in step S202.

[0058] In one possible implementation, the server determines the intent score of a candidate vehicle control intent based on the basic bias of the candidate vehicle control intent, each vehicle control feature information, and the weight of each vehicle control feature information relative to the candidate vehicle control intent. Based on the score ratio of each intent score, the expected probability of occurrence of the candidate vehicle control intent is determined.

[0059] In another possible implementation, the server employs a temporal prediction method based on the user's real-time operation sequence to calculate the expected probability of occurrence. Specifically, after a triggered event occurs, the server retrieves the user's operation behavior records from the cloud within a preset duration window (e.g., the first 30 seconds) before the start of the current session, including the page paths clicked by the user, the duration of dwell time, and the frequency and rhythm of touch or swipe events. The server inputs this temporal behavior data into a pre-trained lightweight recurrent neural network model. This model takes the user's temporal operation sequence as input and outputs the conditional probability of each vehicle control intention. Unlike rule-based scoring models that weight and sum different dimensional features, this temporal model focuses on capturing the user's operational momentum in the current session—for example, when a user quickly and continuously browses the vehicle status page, the model increases the conditional probability of viewing intentions such as "check charging status" and "check vehicle status"; when a user repeatedly enters and exits the settings page of a certain vehicle control function, the model correspondingly increases the probability that the vehicle control function is executed. The server uses the conditional probabilities output by the time-series model as the expected occurrence probabilities of each candidate intent. Before outputting, it introduces the intent availability mask generated in step S202, sets the probability of unavailable intents to zero, and then re-normalizes to obtain the final expected occurrence probability distribution. This implementation does not rely on explicit scoring weights of feature dimensions, but rather predicts based on behavioral trends in the user's current session.

[0060] Step S206: For each vehicle control resource used to trigger the vehicle control operation, the resource preparation priority of the vehicle control resource is determined based on the expected occurrence probability of the candidate vehicle control intention associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intention.

[0061] Among them, the priority of resource preparation is positively correlated with both the expected probability of occurrence and the strength of the correlation.

[0062] Vehicle control resources refer to the various technical components and data that need to be prepared or loaded in advance on the client side in order to present a certain vehicle control function completely and quickly on the remote vehicle control home screen and make it operational. These include core vehicle control component resources, vehicle status interface resources, vehicle control command interface resources, permission verification or identity token related resources, and basic display component resources for vehicle control feedback.

[0063] Association strength is an indicator used to quantify the degree of correlation between a specific vehicle control resource and a candidate vehicle control intent. It ranges from 0 to 1, with higher values ​​indicating that the resource is more important and necessary for achieving the corresponding vehicle control function. Resource preparation priority is a quantitative indicator used to determine the loading order of resources, calculated based on the association between each vehicle control resource and the candidate intent, as well as the predicted probability of the candidate intent.

[0064] In one possible implementation, the server identifies candidate vehicle control intentions whose expected occurrence probability meets the probability condition as selected vehicle control intentions. From all vehicle control resources, it filters selected vehicle control resources that are associated with the selected vehicle control intentions. Based on the association strength between the selected vehicle control resources and the selected vehicle control intentions, as well as the expected occurrence probability of the selected vehicle control intentions, the server determines the resource preparation priority of the selected vehicle control resources.

[0065] In another possible implementation, the server uses a priority calculation method based on global resource popularity and static dependency hierarchy to determine the preparation priority of each vehicle control resource. Specifically, instead of maintaining a fine-grained association strength matrix for each intent, the server pre-configures a global static priority hierarchy for all vehicle control resources. This hierarchy is based on the frequency and coverage of resources being called by various vehicle control functions on the remote vehicle control home screen. For example, the common authentication status interface and vehicle online status interface, which are commonly depended on by all vehicle control functions, are configured as the highest global hierarchy; dedicated components and interfaces called only by a single high-frequency vehicle control function (such as air conditioning control) are configured as the second highest hierarchy; and auxiliary explanatory components and supplementary status components used only for information display enhancement are configured as lower hierarchy. The server uses the expected occurrence probability of each candidate intent calculated in step S204 as a weight, performs a weighted summation of the probabilities of the candidate intents associated with each vehicle control resource, and combines it with its static hierarchy to obtain a composite priority score. Meanwhile, the server constructs a simplified dependency hierarchy graph based on the pre-dependencies of each resource. Instead of performing complex topology sorting and propagation calculations at runtime, it employs a hard constraint that "dependencies have a higher hierarchy than the resources they depend on," ensuring that pre-dependent resources always load before resources that depend on them. Based on this, the server generates simplified budget constraints (e.g., limiting only the maximum number of concurrent loads) according to the current network and device status, and sorts resources by composite priority and dependency hierarchy under these constraints to generate the final loading order.

[0066] Step S208: Preload each vehicle control resource according to the resource preparation priority.

[0067] Preloading refers to a series of resource preparation actions performed by the server and terminal on the terminal side before the user actually enters the remote vehicle control home screen or clicks on a specific vehicle control function. These actions include, but are not limited to, code preloading, data prefetching, cache reading, component preinitialization, and call context pre-establishment.

[0068] After determining the resource preparation priority for each vehicle control resource, the server, in accordance with this priority order, coordinates with the client to actually execute the preloading operations for each vehicle control resource. This process requires intelligent scheduling and execution, taking into account the pre-dependencies between resources, the current network and device resource budget, and dynamic user behavior feedback.

[0069] In one possible implementation, the server obtains the resource usage limit of the target vehicle and the resource usage of each vehicle control resource; according to the resource preparation priority, the resource usage of each vehicle control resource is added up sequentially; if the total resource usage after addition is less than or equal to the resource usage limit, the added vehicle control resource is used as the preloaded vehicle control resource first; after any preloaded vehicle control resource is preloaded, other vehicle control resources are preloaded according to the resource preparation priority under the constraint of the resource usage limit.

[0070] In another possible implementation, the server employs a batch loading method based on static priority grouping and a fixed concurrency window to perform preloading. Specifically, instead of maintaining a dynamic scheduling queue with a fine-grained cumulative consumption budget and a releasable occupancy budget for each resource, the server pre-divides all vehicle control resources to be loaded into several fixed priority batches according to the resource preparation priority calculated in step S206, such as a first priority batch, a second priority batch, and a third priority batch. Each batch contains all resources under that priority level, and the batches are loaded sequentially in descending order of priority, without further distinguishing the loading order of resources within the same batch. The server sets a fixed concurrent loading limit for each batch based on the current network quality and device performance level, for example, 4 concurrent connections when the network is good and 1 concurrent connection when the network is weak. During the loading process, the server sends the resource list and concurrent limit of the current batch to the terminal. The terminal initiates resource loading requests in parallel within the batch according to the concurrent limit. After all resources in the current batch have reached the loaded or ready state, the server starts loading the next batch. For pre-dependencies between resources, the server preprocesses them during the priority allocation phase: if a high-priority resource depends on a low-priority resource, the dependent low-priority resource is forcibly promoted to a high-priority batch and placed before the loaded resource in that batch, ensuring that the dependency is resolved before entering the loading execution phase. The server dynamically adjusts its strategy based on network quality: when network quality is good, the server can merge adjacent priority batches to increase the resource pool for concurrent loading; when network quality is weak, the server lowers the concurrency limit and pauses loading of subsequent batches, prioritizing only the first priority batch (i.e., primary core resources and shared resources). During loading execution, if the server detects that the user's actual click differs from the predicted result, the server immediately stops all loading tasks not yet started in the current batch, clears the loading queue of subsequent batches, and forms a new high-priority batch containing the resources corresponding to the user's actual target intent and their dependent resources, inserting it at the front of the queue for priority execution. This implementation eliminates the need to maintain the in-degree changes of the dependency graph and the budget deduction and release of each resource during the loading and execution process. Instead, it simplifies the complex runtime scheduling into sequential execution between batches and fixed concurrency control within batches by using batch partitioning and dependency boosting preprocessing before loading. This reduces scheduling overhead and implementation complexity while ensuring that core resources are loaded first.

[0071] The aforementioned vehicle control processing method, by responding to a vehicle control intention trigger event for the target vehicle and acquiring multi-source feature information corresponding to the target vehicle, can proactively perceive the current vehicle control scenario context before the user's actual operation, providing a timely and multi-dimensional data foundation for subsequent intention prediction. Based on acquiring multi-source feature information, by identifying multiple candidate vehicle control intentions matching the target vehicle, and determining the expected occurrence probability of each candidate vehicle control intention based on multi-source feature information, it can quantify fuzzy scenario information into a specific expected occurrence probability distribution, achieving accurate characterization and quantitative evaluation of the vehicle control action most likely to be performed by the user. After obtaining the expected occurrence probability of each candidate vehicle control intention, by targeting each vehicle control resource used to trigger the vehicle control operation, based on the expected occurrence probability of the candidate vehicle control intentions associated with that resource and the correlation strength between that resource and the associated candidate vehicle control intentions, it determines... By prioritizing the preparation of each vehicle control resource, the preparation priority of each resource can simultaneously reflect the intensity of the user's demand for the resource's intent and the importance of the resource in completing that intent, thus achieving precise quantification of resource priority. Since the resource preparation priority is positively correlated with both the expected probability of occurrence and the strength of association, resources with high association strength that high-probability intents rely on can automatically receive a higher loading order, thereby tilting limited loading resources toward the most urgent and important vehicle control functions. Finally, by preloading each vehicle control resource according to its preparation priority, the core resources corresponding to the vehicle control function that the user is most likely to execute can be prepared first, and the first screen area of ​​that vehicle control function can become operable in a shorter time, thereby shortening the overall waiting time from opening the APP to completing the target vehicle control operation without requiring additional user intervention.

[0072] In an exemplary embodiment, determining the resource preparation priority of a vehicle control resource based on the expected occurrence probability of the candidate vehicle control intent associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intent includes: identifying candidate vehicle control intents whose expected occurrence probability meets the probability condition as selected vehicle control intents; filtering selected vehicle control resources associated with the selected vehicle control intents from among the vehicle control resources; determining the resource preparation priority of the selected vehicle control resources according to the association strength between the selected vehicle control resources and the selected vehicle control intents and the expected occurrence probability of the selected vehicle control intents; and preloading each vehicle control resource according to each resource preparation priority, including: preloading each selected vehicle control resource according to each resource preparation priority.

[0073] The probabilistic condition refers to the judgment rule used to filter out the intentions that require resource preparation from all candidate vehicle control intentions. This condition filters out candidate intentions with a low probability of occurrence that are not worth preparing resources for in advance, thereby avoiding resource waste caused by ineffective preloading. The selected vehicle control intention refers to the vehicle control intention determined from all candidate vehicle control intentions after filtering by the probabilistic condition, and for which the loading priority of the associated vehicle control resources needs to be configured. The selected vehicle control intention is usually one or more intentions with a high probability of occurrence and a high likelihood of actual user execution. The selected vehicle control resource refers to the vehicle control resources that are associated with the selected vehicle control intention, that is, the various technical components and data on which the selected vehicle control intention depends. For example, when "turn on the air conditioner" is determined to be the selected vehicle control intention, resources such as the air conditioner control component, the air conditioner status interface, and the air conditioner command interface call context are the selected vehicle control resources.

[0074] In this embodiment, the server first determines the expected occurrence probability of each candidate vehicle control intent, and then selects the candidate vehicle control intents that meet preset probability conditions as the selected vehicle control intents. Specifically, these probability conditions can be set as follows: the expected occurrence probability must be higher than a certain preset threshold, or it must be among the top N in probability ranking from high to low, or the cumulative probability coverage must reach a preset proportion. The server considers candidate vehicle control intents that do not meet the probability conditions as low-confidence intents and does not trigger subsequent resource preparation processes for them, thus avoiding invalid resource preloading due to excessive uncertainty in intent prediction.

[0075] After determining the selected vehicle control intent, the server queries a pre-defined "Vehicle Control Intent - Key Resource Set" mapping table. It then selects resources from all vehicle control resources that are associated with the selected intent, designating them as the selected vehicle control resources. For example, when the selected intent is "unlock the vehicle," the server determines the door lock control component, door lock status interface, unlock command interface, permission verification resource, and basic feedback prompt component as the selected vehicle control resources based on the mapping table. When the selected intent is "view charging status," the server determines the charging status component, battery level interface, remaining time interface, and basic charging status display component as the selected vehicle control resources. Vehicle control resources not associated with any selected intent are not scheduled by the server in this round of preloading, thus concentrating limited preloaded resources on the resource set that the high-probability intent depends on.

[0076] Subsequently, for each selected vehicle control resource, the server calculates its resource preparation priority based on the correlation strength between the resource and the selected vehicle control intent, as well as the expected probability of the intent's occurrence. Correlation strength reflects the resource's importance in realizing the selected vehicle control intent, while the expected probability reflects the likelihood of the intent being actually executed by the user. The combination of these two factors ensures that the resource preparation priority reflects both the resource's business importance and the urgency of its actual use in the current scenario. The server sorts the calculated resource preparation priorities from highest to lowest and preloads each selected vehicle control resource sequentially, ensuring that vehicle control resources corresponding to high-probability, high-correlation-strength intents are loaded and initialized first.

[0077] The above method excludes low-confidence candidate intents and their associated resources from the preloading range through a probability-based screening process, thereby reducing invalid preloading and improving the utilization and effectiveness of preloaded resources.

[0078] In an exemplary embodiment, candidate vehicle control intentions include no vehicle control intention; determining candidate vehicle control intentions whose expected occurrence probability meets the probability condition as selected vehicle control intentions includes: determining the candidate vehicle control intention with the highest expected occurrence probability as the first vehicle control intention; when the expected occurrence probability of the first vehicle control intention is higher than a first threshold and the expected occurrence probability of no vehicle control intention is lower than a second threshold, determining the selected vehicle control intention including the first vehicle control intention; the first threshold is greater than the second threshold.

[0079] Among them, "no vehicle control intention" is a special background label among candidate vehicle control intentions, used to indicate the situation where the user may not perform any vehicle control action within the prediction window. This label does not map to any dedicated vehicle control resources, and its probability reflects the likelihood that the user will not perform a vehicle control operation at the current moment, helping the system determine whether to trigger aggressive preloading or adopt a conservative strategy. The first threshold is the lower confidence limit used to determine whether the highest probability executable vehicle control intention reaches the level of "worth aggressive preloading". When the probability of the highest executable action is higher than this threshold, it indicates that there is sufficient confidence in the user's vehicle control intention, and aggressive preloading can be triggered; when it is lower than this threshold, it indicates that the overall confidence is insufficient, and a conservative orchestration strategy should be used. The second threshold is the upper probability limit used to determine whether the "no vehicle control intention" background label is at a high level. When the probability of no vehicle control intention is lower than this threshold, it indicates that the user is more likely to perform a vehicle control action within the current window; when the probability of no vehicle control intention is not lower than this threshold, it indicates that the user is more likely not to perform a vehicle control action, and aggressive preloading should be suppressed to avoid invalid preparation. The first threshold is usually greater than the second threshold.

[0080] In this embodiment, after obtaining the expected occurrence probability distribution of each candidate vehicle control intent, the server first determines the intent with the highest expected occurrence probability from all executable vehicle control intents (i.e., intents excluding the "no vehicle control intent" background label) as the first vehicle control intent, and obtains the expected occurrence probability of the first vehicle control intent and the expected occurrence probability of the "no vehicle control intent" background label. The server then compares the probability of the first vehicle control intent with a first threshold and the probability of the "no vehicle control intent" with a second threshold.

[0081] Specifically, when the expected probability of the first vehicle control intention is higher than a first threshold and the expected probability of "no vehicle control intention" is lower than a second threshold, it indicates a high confidence that the user will perform a certain vehicle control action, and a low probability that the user will not perform the action. In this case, the server determines selected vehicle control intentions, including the first vehicle control intention, and triggers the subsequent resource preloading process. The server can further add other executable intentions with high expected occurrence probabilities according to the actual configuration. Figure 1 And include them in a selected set, for example, multiple intentions with a probability higher than a certain minimum candidate threshold or a cumulative probability reaching a coverage threshold are all selected vehicle control intentions.

[0082] When the expected probability of the first vehicle control intention is not higher than the first threshold, or the expected probability of "no vehicle control intention" is not lower than the second threshold, it indicates that the overall confidence is insufficient or the user is more likely not to perform the vehicle control action. The server does not identify any executable vehicle control intention as the selected vehicle control intention, but instead adopts a conservative orchestration strategy: only preloads general vehicle control basic resources and necessary lightweight vehicle state resources, and does not trigger the active preloading of any dedicated vehicle control resources.

[0083] Through the aforementioned dual threshold determination mechanism, this embodiment ensures that the dedicated vehicle control resources will only be actively preloaded when the system has sufficient confidence in the user's vehicle control intention and the user is indeed inclined to perform vehicle control operations. This achieves a balance between improving the first screen's operability time and avoiding invalid preloading.

[0084] In an exemplary embodiment, determining the resource preparation priority of a selected vehicle control resource based on the correlation strength between the selected vehicle control resource and the selected vehicle control intention, and the expected probability of the selected vehicle control intention occurring, includes: for each selected vehicle control resource, calculating the expected reuse benefit of the selected vehicle control resource based on the correlation strength between the selected vehicle control resource and the selected vehicle control intention, and the expected probability of the selected vehicle control intention occurring; and determining the resource preparation priority of the selected vehicle control resource based on the successor relationship between the selected vehicle control resource and other selected vehicle control resources, and the expected reuse benefit.

[0085] Expected reuse benefit refers to a quantitative indicator of the actual likelihood of a given vehicle control resource being reused across multiple potential intent scenarios, calculated based on the expected occurrence probability and corresponding association strength of each selected vehicle control intent associated with it. A resource with higher expected reuse benefit means it is more dependent on the current high-probability intent, and its value shared among multiple candidate intents is also greater. Successor-successor relationship refers to the loading order constraint relationship between vehicle control resources formed due to functional or data dependencies. If the loading or initialization of resource A is a necessary condition for resource B to function properly or be loaded, then A is the predecessor resource of B, and B is the successor resource of A. For example, the loading of the general authentication status interface is a predecessor condition for the initialization of the air conditioning command interface call context.

[0086] In this embodiment, after determining the selected vehicle control intent and the selected vehicle control resource, the server calculates the expected reuse benefit of each selected vehicle control resource based on the association strength between the resource and each selected vehicle control intent, as well as the expected occurrence probability of each selected vehicle control intent. This calculation method allows resources simultaneously associated with multiple high-probability selected intents (i.e., shared resources) to obtain higher expected reuse benefits. For example, when "turn on the air conditioner" and "check the charging status" are both selected vehicle control intents, the vehicle online status interface is simultaneously depended on by two intents with high association strength. The expected reuse benefit of this interface is the sum of the products of the probabilities of the two intents and their respective association strengths, which is higher than the expected reuse benefit of dedicated resources depended on by only a single intent.

[0087] After obtaining the expected reuse benefits of each selected vehicle control resource, the server further acquires the predecessor-successor relationships between these resources. These relationships are pre-configured in the resource metadata of each resource and recorded in the form of a set of predecessor dependencies. Based on these relationships, the server constructs a directed resource dependency graph, determining which resources must be loaded before other resources.

[0088] The server comprehensively determines the resource preparation priority for each selected vehicle control resource by considering its expected reuse benefits and successor relationships. Specifically, resources with higher expected reuse benefits receive higher basic priority; simultaneously, resources that are prerequisites for high-return successor resources, even if their own expected reuse benefits are low, will receive priority increases due to the dependency propagation mechanism, thus ensuring that high-return resources can obtain their required dependencies in a timely manner. The server generates a loading order according to the comprehensively determined resource preparation priority, ensuring that resources with high reuse value and key positions in the dependency chain are loaded first.

[0089] In one embodiment, the expected occurrence probability P_i represents the mutually exclusive probability that the user's next vehicle control action belongs to the i-th intention, and the expected reuse benefit of resource r is preferably calculated according to the following formula:

[0090] H_r=min(1, Σ_{i∈C}(P_i×M_ir)).

[0091] When M_ir takes only 0 or 1, H_r represents the probability that the next actual vehicle control intention requires resource r; when M_ir takes a continuous value from 0 to 1, H_r represents the resource-related benefits weighted by the expected occurrence probability, and is no longer interpreted as a strict probability. This formula allows resources shared by multiple candidate intentions to obtain higher expected reuse benefits, while retaining the benefits of resources dedicated to a single intention with a high probability.

[0092] In another implementation, if P_i is defined as the non-mutually exclusive probability of each vehicle control intention occurring within a session window, then 1-∏_{i∈C}(1-P_i×M_ir) can be used to calculate the probability of at least one intention using resource r; the non-mutually exclusive probability must not be mixed with the next action Softmax probability, which sums to 1.

[0093] After determining the expected reuse benefits of the selected vehicle control resources, the initial resource priority S_r of the selected vehicle control resources can be determined according to the following formula:

[0094] S_r=αH_r+βK_r+γU_r+μR_r-εC_r-φL_r.

[0095] Where H_r represents the expected reuse benefit of the resource; K_r represents the resource criticality; U_r represents the state update requirement; R_r represents the historical reuse benefit; C_r represents the loading cost; L_r represents the dependency complexity; and α, β, γ, μ, ε, and φ represent non-negative weights. These variables are preferably normalized to 0 to 1.

[0096] The state update requirement U_r indicates whether state-related resources need to be re-fetched. U_r is higher when the remaining validity period of the cached state is short, the data has expired, or the vehicle state has changed; U_r is lower when the cached data still meets freshness requirements and can be directly read from the cache. Loading cost C_r can be obtained by weighting resource size, estimated network latency, CPU consumption, and memory usage. Dependency complexity L_r can be obtained by dependency level, number of preceding resources, or estimated dependency completion time. Historical reuse benefit R_r can be calculated based on the resource's historical hit rate, time saved after a hit, and the proportion of invalid loads.

[0097] S_r is used for fine-grained ordering between resources of the same level and when cross-level adjustments are allowed. Dependencies and network budget are not considered as general factors that can be offset by scoring, but rather as hard constraints for queue generation.

[0098] To avoid delaying high-priority target resources due to their low initial scores of prerequisite dependencies, it is preferable to propagate the priority of target resources forward along dependency edges. For a selected vehicle control resource r, define the resource preparation priority S_r*:

[0099] S_r*=max(S_r,max_{d∈Desc(r)}(S_d×ρ^l(r,d))).

[0100] Here, Desc(r) represents the set of successor resources that directly or indirectly depend on resource r, l(r,d) represents the dependency distance from r to successor resource d, and ρ is a propagation attenuation coefficient greater than 0 and not greater than 1. Therefore, resources that are necessary prerequisites for high-priority resources can receive corresponding scheduling boosts, but dependencies with long distances will not be amplified indefinitely.

[0101] In this embodiment, by introducing the quantitative calculation of expected reuse benefits and combining the successor-successor relationship of resources to comprehensively determine the resource preparation priority, the determination of resource priority reflects the reuse value of each resource in the current candidate intent scenario and ensures that dependency constraints are not violated. Resources shared by multiple high-probability intents are loaded first due to their higher expected reuse benefits, while dedicated resources are sorted according to the probability and association strength of their dependent intents. This achieves the optimal allocation of preloaded resources among different candidate intent scenarios and different resource types, further improving the efficiency of preload benefits and the readiness speed of the core functions on the first screen.

[0102] In an exemplary embodiment, each vehicle control resource is preloaded according to its preparation priority, including: obtaining the resource usage limit of the target vehicle and the resource usage of each vehicle control resource; sequentially adding the resource usage of each vehicle control resource according to its preparation priority; if the total resource usage after addition is less than or equal to the resource usage limit, the added vehicle control resource is used as the first preloaded vehicle control resource; after any preloaded vehicle control resource is preloaded, other vehicle control resources are preloaded according to their preparation priorities under the constraint of the resource usage limit.

[0103] The resource usage limit refers to the maximum amount of system resources that the target vehicle can consume at any given moment to support remote vehicle control resource preloading. This limit includes, but is not limited to, the cumulative consumption budget and the releaseable occupancy budget. Resource usage refers to the cost of each system resource required for each vehicle control resource to perform a preloading operation, including but not limited to the cumulative cost vector and occupancy cost vector of that resource.

[0104] Specifically, the resource usage limit is divided into a cumulative consumption budget and a releaseable occupancy budget. The cumulative consumption budget B_cum includes at least the maximum number of bytes prefetched in this round, B_byte, and the maximum number of interface requests, B_req. Once a resource is actually prefetched or requested, the corresponding cumulative budget is deducted, and it is not replenished within the same round due to task completion. The releaseable occupancy budget B_occ includes at least the maximum number of concurrent slots, B_conc, and the maximum pre-initialized memory usage, B_mem. After a task is completed, canceled, or its occupied resources are released, the corresponding concurrent slots and releaseable memory become available again. For vehicle control resources r, the cumulative cost vector c_r^cum=(c_{r,byte},c_{r,req}) and the occupancy cost vector c_r^occ=(c_{r,conc},c_{r,mem}) are recorded respectively. Based on the current network and device status, generate the current round's cumulative consumption budget B_cum and the releaseable occupancy budget B_occ, and initialize the cumulative consumption and current occupancy. Calculate the in-degree of each resource, and add resources with an in-degree of zero (i.e., all preceding resources have been loaded) and not yet loaded to the schedulable set. In the schedulable set, select vehicle control resources first by resource level, then by S_r* from high to low. Determine whether the sum of the cumulative consumption and c_r^cum exceeds B_cum, and whether the sum of the current occupancy and c_r^occ exceeds B_occ after adding the vehicle control resource r. If both budgets are satisfied, start or add to the current execution batch: the cumulative consumption increases by c_r^cum, and the current occupancy increases by c_r^occ. If the cumulative budget is not satisfied, place the resource in a deferred queue; if the occupancy budget is temporarily unsatisfactory, retain it in the schedulable set waiting for slot release. When multiple resources have the same effective priority, their order is determined sequentially by the shorter expected loading time, higher historical reuse rate, or resource identifier order. When a resource completes loading, is canceled, or its occupied resources are released, the corresponding concurrent slot is released. For pre-initialized objects that do not require continuous residency, their corresponding memory usage is also released. Once a resource reaches a reusable state, its corresponding dependency edges are deleted, and newly emerging successor resources with an in-degree of zero are added to the schedulable set. For resources that need to remain continuously until the first screen reuse time, their memory usage is included in the current usage until reused, evicted, or canceled. This process is repeated until there are no more schedulable resources, the cumulative budget is exhausted, or all remaining resources enter the deferred queue. This results in a topology-constrained dynamic priority queue that satisfies both resource pre-dependencies and distinguishes between cumulative consumption constraints and runtime occupancy constraints.

[0105] When network quality is good, the number of available concurrent slots can be increased and some secondary resources can be loaded in parallel after primary resources; when network quality is average, primary resources and secondary resources with high S_r* should be retained; when the network is weak or equipment resources are scarce, the maximum number of concurrent slots should be reduced to one or a few slots, and only primary resources, shared resources and high-yield resources corresponding to the highest probability intentions should be allowed to enter the current budget, while the remaining resources should be put into the deferred queue.

[0106] When the probability of the highest executable action, P_max^act, is lower than θ_low, or the probability of "no vehicle control intention" is not lower than θ_bg, it is preferable to prepare only lightweight resources such as general vehicle control basic resources and vehicle online status, and wait for further user behavior. When there are multiple candidate intentions, shared resources with higher H_r are prioritized when the resource level is the same and other scoring factors are comparable; otherwise, the actual order is determined according to resource level, S_r*, and dependency constraints. When the expected occurrence probabilities of candidate actions are close, larger and more deeply dependent differential resources are further postponed.

[0107] During queue execution, if the actual user click is detected to be different from the predicted result, the resource corresponding to the user's actual target intent is marked as an emergency resource: the level 3 resources that have not yet been started and the low-yield level 2 resources are suspended, and the emergency resources and their unfinished prerequisites are promoted to the front of the schedulable set; the completed general resources continue to be reused, thereby avoiding a complete rollback to normal loading.

[0108] In this embodiment, by obtaining the resource usage limit of the target vehicle and the resource usage of each vehicle control resource, and dynamically judging whether the cumulative resource usage exceeds the limit during the loading process, the preloading process is controlled under resource budget constraints. At the same time, by continuously attempting to load the delayed resources after resource release, in scenarios with weak networks or low-performance devices, core high-priority resources can occupy limited resources to complete the loading first, while non-critical resources are automatically delayed. This effectively suppresses resource contention between non-critical resources and critical resources, ensuring the rapid readiness of the core vehicle control functions on the first screen.

[0109] In an exemplary embodiment, the multi-source feature information includes vehicle control feature information corresponding to each of the multiple vehicle control features; based on the multi-source feature information, the expected occurrence probability of the candidate vehicle control intention is determined, including: determining the intention score of the candidate vehicle control intention based on the basic bias of the candidate vehicle control intention, each vehicle control feature information, and the weight of each vehicle control feature information for the candidate vehicle control intention; and determining the expected occurrence probability of the candidate vehicle control intention based on the score ratio of each intention score.

[0110] Among them, vehicle control features refer to the specific feature items of each dimension in the multi-source feature information, including user behavior features (such as the types of the most recent N vehicle control operations, historically high-frequency vehicle control functions), vehicle status features (such as door lock status, air conditioning status, charging status, vehicle online status), and operating environment features (such as network type, network quality, current time period). Each vehicle control feature corresponds to a specific feature value. The base bias refers to a fixed score base preset for each vehicle control intent, reflecting the prior tendency of that intent to occur without considering any feature information. The base bias can be preset based on business experience or historical statistical data. The intent score refers to the original quantitative score value of each candidate vehicle control intent, calculated through weighted summation based on its base bias, the current values ​​of each vehicle control feature, and the weight of each feature for that intent. The intent score is the prerequisite for subsequent probability normalization calculations. The score percentage refers to the proportion of the intent score of each vehicle control intent in the sum of the intent scores of all candidate vehicle control intents. By performing Softmax normalization on the scores of each intent, the score of each intent is converted into a probability value between 0 and 1 with a sum of 1. This probability value is the expected probability of the intent occurring.

[0111] Specifically, for the i-th candidate vehicle control intention, the rule-based scoring model calculates the intention score according to the following formula:

[0112] Z_i=b_i+Σ_j(w_ij×x_j×v_j)+Σ_k(g_ik×c_k).

[0113] Where b_i is the basic bias of the i-th candidate vehicle control intention; x_j is the j-th normalized feature in the feature vector X; v_j is the validity value corresponding to x_j in the validity vector V; w_ij is the weight of feature x_j on the i-th candidate vehicle control intention; c_k is the scene condition obtained by combining at least two features; and g_ik is the weight of scene condition c_k on the i-th candidate vehicle control intention. For example, "the air conditioner is off and the ambient temperature is higher than the threshold", "the door lock is locked and the user is close to the vehicle", and "the vehicle is charging and the charging status has been checked multiple times recently" can all constitute scene conditions.

[0114] When the intent availability mask A_i indicates that the i-th executable vehicle control intent is unavailable, the original score of that intent is set to the preset minimum value or excluded from the candidate set; when it indicates availability, Z_i is retained. "No vehicle control intent" is used as a background label and is not excluded by the vehicle action availability mask. Subsequently, the expected probability of occurrence can be obtained using the following normalization method:

[0115] P_i=exp(Z_i) / Σ_qexp(Z_q).

[0116] The summation range includes all executable vehicle control intentions in the current available state and the background label of "no vehicle control intention," with the sum of each P_i being 1. Besides the rule-based scoring method described above, the feature vector X can be input into logistic regression, gradient boosting trees, lightweight neural networks, or other lightweight machine learning models to obtain the model probability P_i^m, which is then fused with the rule probability P_i^r according to P_i'=λP_i^r+(1-λ)P_i^m, where λ is a fusion weight between 0 and 1. The model output can be converted into a comparable probability through temperature scaling or equivalent calibration. After fusion, the P_i' of unavailable executable vehicle control intentions is set to 0 again according to the intention availability mask A_i, and the remaining executable vehicle control intentions and "no vehicle control intentions" are renormalized according to P_i=P_i' / Σ_qP_q'; this avoids the model output causing intentions conflicting with the current vehicle state to re-enter the candidate set. The rule-based scoring method itself can independently complete the expected occurrence probability calculation; the fusion model is an optional enhancement method.

[0117] In this embodiment, the intent score is calculated by weighted summation of the basic bias and each vehicle control feature, and the scores of each intent are normalized to the expected occurrence probability by the score ratio. This establishes an interpretable and executable computation link from multi-source feature information to the expected occurrence probability. The differentiated configuration of feature weights allows for fine adjustment of the contribution of different vehicle control features to different intents, while the basic bias introduces prior information. The combination of the two makes the calculation of the expected occurrence probability both business interpretable and adaptable to the differentiated prediction needs of different users and different scenarios. At the same time, the introduction of the intent availability mask avoids intentions that conflict with the current physical state of the vehicle from obtaining an unreasonably high probability, further improving the rationality and accuracy of the prediction results.

[0118] In a specific embodiment, such as Figure 3As shown, a vehicle control processing system is also provided, which divides this application into a feature input layer, a resource object layer, and an orchestration execution layer to clearly reflect the closed-loop relationship of "multi-source feature input—vehicle control intent recognition—key resource determination—strategy execution—feedback optimization". Compared with simply listing module names, this expression is more conducive to highlighting the hierarchical structure, coupling boundaries, and the reverse optimization effect of the feedback update module on the intent prediction module, resource mapping module, and priority orchestration module in this invention. Specifically, it includes: a trigger detection module, used to detect whether the vehicle control intent prediction stage has been entered at times such as when the APP starts, switches from the background to the foreground, enters the homepage, enters the vehicle page, the vehicle status is refreshed, and the vehicle control entry is exposed. This module is required to work before the user initiates a remote vehicle control command. A feature acquisition module is used to collect multi-source features related to the vehicle control intent, including user behavior features, vehicle status features, and operating environment features, and to perform timeliness filtering and standardization processing on the features. The intent prediction module sequentially performs time-sensitive filtering, missing data handling, encoding, normalization, and time decay on multi-source features. Based on the processed features, it calculates the original score of each vehicle control intent, and outputs at least one candidate vehicle control intent and its corresponding probability after probability normalization and candidate filtering. A rule-based scoring model is preferably used as the basic implementation method for complete execution, and a lightweight machine learning model can also be used, or the rule-based scoring results can be fused with the output of the lightweight machine learning model; the machine learning model is not a necessary condition for realizing the resource orchestration closed loop of this invention. The resource mapping module maintains the mapping relationship between "vehicle control intent and key resource set". Different vehicle control intents correspond to different core vehicle control components, status interfaces, command interfaces, and basic feedback display components. The priority orchestration module calculates the expected reuse benefit of each resource based on the expected probability of candidate vehicle control and the intent-resource association relationship, and forms a resource priority score by combining resource criticality, status update requirements, historical reuse benefits, and loading costs; then, using a resource dependency graph as a hard constraint, it uses a dynamic priority queue to generate a loading sequence that satisfies the dependency order, and performs pruning, rate limiting, or degradation based on network quality, device capabilities, and a preset budget. The resource loading execution module is used to perform preloading, prefetching, cache reading, pre-initialization, lazy loading, or interruption degradation processing on target resources. The first-screen reuse module reuses prepared resources when a user enters the remote vehicle control first screen or clicks on a target vehicle control entry point, directly displaying the operable vehicle control area or shortening its waiting time. The feedback update module records the user's actual vehicle control behavior, hit rate, loading time, and first-screen operability time, and updates the data based on a feedback update intent scoring strategy and a resource priority strategy.

[0119] In a specific embodiment, a vehicle control processing method is also provided, specifically including: triggering a prediction process when the vehicle networking APP experiences at least one of the following events: APP launch; APP returns to the foreground from the background; enters the homepage or vehicle homepage; vehicle status refresh is completed; remote vehicle control entry is exposed; a prediction window appears before the user enters the primary remote vehicle control entry. After triggering, multi-source feature information is collected. This covers user behavior features describing user operation patterns, vehicle status features describing the real-time physical and logical states of the vehicle, and operating environment features describing the current device and network environment. Among them, user behavior features include, but are not limited to: the type of the most recent N vehicle control operations; the time of the most recent vehicle control operation; the path of the most recently visited page; historically frequently used vehicle control functions; vehicle control preference statistics within a specified time period; and the source of the most recent click on the remote vehicle control entry. Vehicle status features include, but are not limited to: vehicle online status; door lock status; air conditioning status; charging status; battery level or range status; the time of the most recent vehicle status update; and the inference result of the vehicle's location-related status or proximity status. Operating environment characteristics include, but are not limited to: network type; network quality; device performance level; current time period; current region or link environment; APP version or resource cache availability; external environmental context information related to vehicle control requirements, such as ambient temperature, weather conditions, or seasonal information.

[0120] Among them, external environment context information is an optional enhancement feature used to improve the prediction accuracy in specific vehicle control intention scenarios; even without this type of information, vehicle control intention can still be predicted based on user behavior features, vehicle status features and other operating environment features.

[0121] After collecting multi-source feature information, the feature vector that can be used for intent scoring is preferably formed in the following order: record the collection time or status update time for each feature, and remove or mark expired features according to the corresponding validity period; set missing indicators for missing features, and process them according to the feature type by using a preset neutral value, the most recent valid value, or not participating in the current round of scoring, so as to avoid misjudging "not acquired" as a specific vehicle status; normalize continuous features such as temperature, latency, and number of historical operations to 0 to 1 according to preset upper and lower bounds; enumerate or one-hot encode discrete features such as door lock status, air conditioning status, charging status, and network type; and decay historical vehicle control behaviors according to the time of occurrence of the behavior. For the nth historical action, a decay value h_n = exp(-Δt_n / τ) can be used, where Δt_n is the time difference between the action and the current prediction time, and τ is the time decay parameter. Alternatively, time-segmented counting or weighting of the most recent N actions can be used. The processed user behavior features, vehicle status features, and operating environment features are concatenated according to a preset field order to obtain the feature vector X for this round, and a validity vector V is generated to indicate whether the features are valid. An intent availability mask A_i is generated based on the current vehicle status. For example, if the vehicle is unlocked, "Unlock Vehicle" can be marked as unavailable or its score reduced; if the vehicle is not connected to a charging device, "Stop Charging" can be marked as unavailable. The availability mask is used to avoid outputting candidate intents that conflict with the current vehicle status based solely on historical preferences.

[0122] The above processing order can be adjusted according to the terminal implementation, but at least each feature entering the intent scoring process should have a clear meaning of value, validity and timeliness.

[0123] For features that may involve personal information, such as user behavior, vehicle location, or proximity status, data should preferably be collected only within the scope of appropriate permissions and business necessity. If statistics can be performed on the terminal side, derived features such as frequency, time period, or distance interval should be generated on the terminal side first, without uploading the original precise trajectory. Data used for offline model training or statistical updates can be de-identified, have limited retention periods, and be subject to access control. Even without available environmental or location features, the system can still complete rule scoring based on vehicle status, network status, and non-sensitive historical statistics, without making sensitive features mandatory inputs.

[0124] The aforementioned features are then input into the vehicle control intent scoring model, which outputs at least one candidate vehicle control intent and its probability. Candidate vehicle control intents include, but are not limited to: turning on the air conditioning; turning off the air conditioning; unlocking the vehicle; locking the vehicle; checking the charging status; starting charging; stopping charging; remotely locating the vehicle; checking the vehicle status; other vehicle control intents, serving as a fallback action label when not listed separately by the aforementioned actions; and no vehicle control intent, serving as a background label when the user does not perform any vehicle control action within the prediction window.

[0125] Specifically, "no vehicle control intent" is not mapped to dedicated vehicle control resources; when its probability is high, only general vehicle control basic resources and necessary lightweight state resources are allowed to enter the conservative orchestration path. "Other vehicle control intents" may only be mapped to general vehicle control basic resources, or they may be mapped to corresponding dedicated resources after further subdivision of the business configuration. The rule scoring model and the optional machine learning model use the same set of labels to ensure that the two types of probabilities can be fused label by label.

[0126] As a basic implementation method that can be fully executed, for the i-th candidate vehicle control intention, the rule scoring model calculates the intention score according to the following formula:

[0127] Z_i=b_i+Σ_j(w_ij×x_j×v_j)+Σ_k(g_ik×c_k).

[0128] Where b_i is the basic bias of the i-th candidate vehicle control intention; x_j is the j-th normalized feature in the feature vector X; v_j is the validity value corresponding to x_j in the validity vector V; w_ij is the weight of feature x_j on the i-th candidate vehicle control intention; c_k is the scene condition obtained by combining at least two features; and g_ik is the weight of scene condition c_k on the i-th candidate vehicle control intention. For example, "the air conditioner is off and the ambient temperature is higher than the threshold", "the door lock is locked and the user is close to the vehicle", and "the vehicle is charging and the charging status has been checked multiple times recently" can all constitute scene conditions.

[0129] When the intent availability mask A_i indicates that the i-th executable vehicle control intent is unavailable, the original score of that intent is set to the preset minimum value or excluded from the candidate set; when it indicates availability, Z_i is retained. "No vehicle control intent" is used as a background label and is not excluded by the vehicle action availability mask. Subsequently, the expected probability of occurrence can be obtained using the following normalization method:

[0130] P_i=exp(Z_i) / Σ_qexp(Z_q).

[0131] The summation range includes all executable vehicle control intentions in the current available state and the background label of "no vehicle control intention," with the sum of each P_i being 1. Besides the rule-based scoring method described above, the feature vector X can be input into logistic regression, gradient boosting trees, lightweight neural networks, or other lightweight machine learning models to obtain the model probability P_i^m, which is then fused with the rule probability P_i^r according to P_i'=λP_i^r+(1-λ)P_i^m, where λ is a fusion weight between 0 and 1. The model output can be converted into a comparable probability through temperature scaling or equivalent calibration. After fusion, the P_i' of unavailable executable vehicle control intentions is set to 0 again according to the intention availability mask A_i, and the remaining executable vehicle control intentions and "no vehicle control intentions" are renormalized according to P_i=P_i' / Σ_qP_q'; this avoids the model output causing intentions conflicting with the current vehicle state to re-enter the candidate set. The rule-based scoring method itself can independently complete the expected occurrence probability calculation; the fusion model is an optional enhancement method.

[0132] After obtaining the expected probability distribution, the background label "no vehicle control intention" is excluded, and the highest probability among the remaining executable vehicle control intentions is taken as P_max^act. Then, a candidate vehicle control intention set C is formed in the following order: sorted from highest to lowest by the executable vehicle control intention P_i, and the highest executable action probability P_max^act is obtained. When P_max^act is lower than the low confidence threshold (first threshold) θ_low, or the expected probability of "no vehicle control intention" is not lower than the preset background threshold (second threshold) θ_bg, the aggressive preloading of dedicated intention resources is not performed, and a conservative orchestration strategy is directly enabled. The process is as follows: Only general vehicle control basic resources and necessary lightweight state resources are selected. When P_max^act is not lower than θ_low and the probability of "no vehicle control intention" is lower than θ_bg, executable vehicle control intentions with P_i lower than the minimum candidate probability threshold θ_min are excluded, and they are added to the candidate set sequentially from the first position in the sorting until the number of candidates reaches K, the cumulative candidate probability value reaches the cumulative coverage threshold η, or there are no other intentions that satisfy θ_min. After the candidate set is formed, when the probability difference between any two adjacent candidate intentions is not greater than the parallel threshold δ, the corresponding intention is marked as an approximately parallel intention, and its shared resources are prepared first.

[0133] The above thresholds satisfy 0≤θ_min≤θ_low≤1, 0≤θ_bg≤1, and 0≤δ≤1. Background label judgment and low confidence judgment are performed before candidate cumulative judgment. The candidate cumulative probability is only used to control the candidate coverage in non-low confidence scenarios.

[0134] For example, the probabilities of turning on the air conditioner, checking the charging status, unlocking the vehicle, other vehicle control intentions, and no vehicle control intention are approximately 0.50, 0.20, 0.15, 0.10, and 0.05, respectively. When θ_low=0.35, θ_bg=0.50, K=3, θ_min=0.14, and η=0.70, the probability of the highest executable action is not considered low confidence, and the background label probability is lower than θ_bg. The candidate set primarily includes turning on the air conditioner and checking the charging status, with a cumulative probability of 0.70. In this case, even if the two intentions are not approximately parallel, they can be considered simultaneously based on the cumulative coverage rule. "Similar probabilities" and "multiple candidate vehicle control intentions" are different judgment conditions.

[0135] Therefore, this application establishes an intrinsic relationship between input multi-source features and output candidate vehicle control intentions through executable feature processing, intent scoring, probability normalization, and candidate selection processes. Specific weights can be obtained through business rule configuration, historical statistical fitting, or model training, and the method of obtaining these weights does not alter the subsequent resource orchestration process.

[0136] When using an optional machine learning model, the feature vector X of a predicted trigger moment can be used as a training sample, and the first vehicle control action actually performed by the user within a preset labeling window after that trigger moment can be used as the sample label; samples without vehicle control action are uniformly labeled as "no vehicle control intention". The training and validation sets are preferably divided according to time order or user dimension to avoid data leakage within the same session; cross-entropy loss or equivalent multi-class loss can be used to train the model, and probability calibration can be performed based on the validation set. After model updates, release control should be implemented through version identification, offline validation metrics, and rollback conditions. The above training process is only used to enhance the accuracy of the expected occurrence probability and is not a necessary condition for implementing the resource orchestration method of this invention.

[0137] As a specific structural example of an optional machine learning model, it can be configured with an input layer of dimension d, a first fully connected layer containing 32 nodes and a ReLU activation function, a second fully connected layer containing 16 nodes and a ReLU activation function, and a Softmax output layer with the number of nodes equal to the number of labels m; training is performed using multi-class cross-entropy loss, and early stopping is used when the loss on the validation set no longer decreases. d equals the number of fields in the feature vector for this round, and m equals the number of uniform labels including "uncontrolled vehicle intent". This structure is only an executable example and does not restrict the use of logistic regression, gradient boosting trees, or other models that can output probabilities of the same label.

[0138] Then, based on the candidate vehicle control intent, the mapping table between the candidate vehicle control intent and the key resources is queried to determine the corresponding set of key resources.

[0139] For example, when the candidate vehicle control intent is "turn on the air conditioning," the key resource set may include air conditioning control components, air conditioning status interface, vehicle interior temperature interface, air conditioning command interface, and execution prompt components. When the candidate vehicle control intent is "unlock the vehicle," the key resource set may include door lock control components, door lock status interface, unlock command interface, permission verification resources, and basic feedback prompt components. When the candidate vehicle control intent is "check charging status," the key resource set may include charging status components, battery level interface, remaining time interface, and basic charging status display components.

[0140] Furthermore, when multiple candidate vehicle control intentions share some basic capabilities, the key resource set can also include general vehicle control basic resources, such as general vehicle control container components, general status carrier components, basic feedback prompt components, basic interfaces for vehicle online status, or general permission verification resources. These general vehicle control basic resources can be prioritized as the intersection resources of multiple candidate vehicle control intentions to maintain a high level of resource reuse benefits before the user explicitly clicks on a specific vehicle control entry point.

[0141] Preferably, resource metadata is configured for each resource r. This resource metadata includes at least: resource identifier, resource type, resource criticality K_r, applicable vehicle control intent, intent-resource association strength M_ir, set of prerequisite dependencies D_r, resource size, estimated loading time, supported loading methods, cache status, freshness threshold, and historical reuse rate. M_ir can be 0 to 1, where M_ir=0 indicates that resource r is unrelated to intent i, and M_ir=1 indicates that resource r is a directly necessary resource for intent i.

[0142] The expected occurrence probability P_i represents the mutually exclusive probability that the user's next vehicle control action belongs to the i-th intention. The expected reuse benefit of resource r is preferably calculated according to the following formula:

[0143] H_r=min(1, Σ_{i∈C}(P_i×M_ir)).

[0144] When M_ir takes only 0 or 1, H_r represents the probability that the next actual vehicle control intention requires resource r; when M_ir takes a continuous value from 0 to 1, H_r represents the resource-related benefits weighted by the expected occurrence probability, and is no longer interpreted as a strict probability. This formula allows resources shared by multiple candidate intentions to obtain higher expected reuse benefits, while retaining the benefits of resources dedicated to a single intention with a high probability.

[0145] In another implementation, if P_i is defined as the non-mutually exclusive probability of each vehicle control intention occurring within a session window, then 1-∏_{i∈C}(1-P_i×M_ir) can be used to calculate the probability of at least one intention using resource r; the non-mutually exclusive probability must not be mixed with the next action Softmax probability, which sums to 1.

[0146] After determining the expected reuse benefits of the selected vehicle control resources, the initial resource priority S_r of the selected vehicle control resources can be determined according to the following formula:

[0147] S_r=αH_r+βK_r+γU_r+μR_r-εC_r-φL_r.

[0148] Where H_r represents the expected reuse benefit of the resource; K_r represents the resource criticality; U_r represents the state update requirement; R_r represents the historical reuse benefit; C_r represents the loading cost; L_r represents the dependency complexity; and α, β, γ, μ, ε, and φ represent non-negative weights. These variables are preferably normalized to 0 to 1.

[0149] The state update requirement U_r indicates whether state-related resources need to be re-fetched. U_r is higher when the remaining validity period of the cached state is short, the data has expired, or the vehicle state has changed; U_r is lower when the cached data still meets freshness requirements and can be directly read from the cache. Loading cost C_r can be obtained by weighting resource size, estimated network latency, CPU consumption, and memory usage. Dependency complexity L_r can be obtained by dependency level, number of preceding resources, or estimated dependency completion time. Historical reuse benefit R_r can be calculated based on the resource's historical hit rate, time saved after a hit, and the proportion of invalid loads.

[0150] S_r is used for fine-grained ordering between resources of the same level and when cross-level adjustments are allowed. Dependencies and network budget are not considered as general factors that can be offset by scoring, but rather as hard constraints for queue generation.

[0151] To avoid delaying high-priority target resources due to their low initial scores of prerequisite dependencies, it is preferable to propagate the priority of target resources forward along dependency edges. For a selected vehicle control resource r, define the resource preparation priority S_r*:

[0152] S_r*=max(S_r,max_{d∈Desc(r)}(S_d×ρ^l(r,d))).

[0153] Here, Desc(r) represents the set of successor resources that directly or indirectly depend on resource r, l(r,d) represents the dependency distance from r to successor resource d, and ρ is a propagation attenuation coefficient greater than 0 and not greater than 1. Therefore, resources that are necessary prerequisites for high-priority resources can receive corresponding scheduling boosts, but dependencies with long distances will not be amplified indefinitely.

[0154] For ease of understanding, the structured mapping between vehicle control intentions and key resources is shown in the table below:

[0155]

[0156] Table 1

[0157] Preferably, the resources are divided into at least three levels:

[0158] 1. Level 1 resources directly determine whether the remote vehicle control screen is operable, including core vehicle control components, necessary state interfaces, vehicle control command interface call context, and basic feedback components;

[0159] 2. Secondary resources, which affect information integrity but do not block core vehicle control actions, include auxiliary instructions, non-essential graphical components, and supplementary status blocks;

[0160] 3. Level 3 resources do not affect key vehicle control operations on the first screen, including marketing cards, recommended service entrances, unnecessary animations, and decorative images.

[0161] Resource tiers are used to determine the minimum guarantee order, and S_r is used for fine-grained ordering among resources of the same tier and when cross-tier adjustments are allowed. Dependencies and network budgets are not considered general factors that can be offset by scoring, but rather as hard constraints on queue generation.

[0162] Preferably, the resource usage limit is divided into a cumulative consumption budget and a releaseable occupancy budget. The cumulative consumption budget B_cum includes at least the maximum number of bytes prefetched in this round, B_byte, and the maximum number of interface requests, B_req. Once a resource is actually prefetched or requested, the corresponding cumulative budget is deducted, and it is not replenished within the same round due to task completion. The releaseable occupancy budget B_occ includes at least the maximum number of concurrent slots, B_conc, and the maximum pre-initialized memory usage, B_mem. After a task is completed, canceled, or its occupied resources are released, the corresponding concurrent slots and releaseable memory quota become available again. For vehicle control resource r, the cumulative cost vector c_r^cum=(c_{r,byte},c_{r,req}) and the occupancy cost vector c_r^occ=(c_{r,conc},c_{r,mem}) are recorded respectively. Based on the current network and device status, generate the current round's cumulative consumption budget B_cum and the releaseable occupancy budget B_occ, and initialize the cumulative consumption and current occupancy. Calculate the in-degree of each resource, and add resources with an in-degree of zero (i.e., all preceding resources have been loaded) and not yet loaded to the schedulable set. In the schedulable set, select vehicle control resources first by resource level, then by S_r* from high to low. Determine whether the sum of the cumulative consumption and c_r^cum exceeds B_cum, and whether the sum of the current occupancy and c_r^occ exceeds B_occ after adding the vehicle control resource r. If both budgets are satisfied, start or add to the current execution batch: the cumulative consumption increases by c_r^cum, and the current occupancy increases by c_r^occ. If the cumulative budget is not satisfied, place the resource in a deferred queue; if the occupancy budget is temporarily unsatisfactory, retain it in the schedulable set waiting for slot release. When multiple resources have the same effective priority, their order is determined sequentially by the shorter expected loading time, higher historical reuse rate, or resource identifier order. When a resource completes loading, is canceled, or its occupied resources are released, the corresponding concurrent slot is released. For pre-initialized objects that do not require continuous residency, their corresponding memory usage is also released. Once a resource reaches a reusable state, its corresponding dependency edges are deleted, and newly emerging successor resources with an in-degree of zero are added to the schedulable set. For resources that need to remain continuously until the first screen reuse time, their memory usage is included in the current usage until reused, evicted, or canceled. This process is repeated until there are no more schedulable resources, the cumulative budget is exhausted, or all remaining resources enter the deferred queue. This results in a topology-constrained dynamic priority queue that satisfies both resource pre-dependencies and distinguishes between cumulative consumption constraints and runtime occupancy constraints.

[0163] When network quality is good, the number of available concurrent slots can be increased and some secondary resources can be loaded in parallel after primary resources; when network quality is average, primary resources and secondary resources with high S_r* should be retained; when the network is weak or equipment resources are scarce, the maximum number of concurrent slots should be reduced to one or a few slots, and only primary resources, shared resources and high-yield resources corresponding to the highest probability intentions should be allowed to enter the current budget, while the remaining resources should be put into the deferred queue.

[0164] When the probability of the highest executable action, P_max^act, is lower than θ_low, or the probability of "no vehicle control intention" is not lower than θ_bg, it is preferable to prepare only lightweight resources such as general vehicle control basic resources and vehicle online status, and wait for further user behavior. When there are multiple candidate intentions, shared resources with higher H_r are prioritized when the resource level is the same and other scoring factors are comparable; otherwise, the actual order is determined according to resource level, S_r*, and dependency constraints. When the expected occurrence probabilities of candidate actions are close, larger and more deeply dependent differential resources are further postponed.

[0165] During queue execution, if the actual user click is detected to be different from the predicted result, the resource corresponding to the user's actual target intent is marked as an emergency resource: the level 3 resources that have not yet been started and the low-yield level 2 resources are suspended, and the emergency resources and their unfinished prerequisites are promoted to the front of the schedulable set; the completed general resources continue to be reused, thereby avoiding a complete rollback to normal loading.

[0166] The resource loading execution methods include: preloading the front-end vehicle control component code; pre-fetching vehicle status interface data; reading status data that is still within the freshness threshold from the local cache; pre-initializing vehicle control component instances or feedback component instances; pre-establishing the command interface call context; and delaying the loading of non-critical display resources. Pre-establishing the command interface call context refers to preparing the interface description, serializer, connection configuration, general authentication status, or call object, but does not include sending the actual vehicle control command before user confirmation. For information with security or time-sensitive requirements, such as identity tokens and door lock status, even if pre-fetching or cache reading has been performed, the necessary permission checks, token validity checks, and vehicle status checks should still be re-executed according to existing security policies before actually sending the vehicle control command. The preloading results are used to shorten resource preparation time and do not replace security checks during the vehicle control command execution phase.

[0167] When a user is detected to enter the target remote vehicle control home screen, click on the target vehicle control entry, or enter the target vehicle control process corresponding to the candidate vehicle control intent, the prepared resources are reused first to shorten the time for the target vehicle control area to reach an operable state.

[0168] Preferably, for vehicle status data, this application first determines whether the cached data meets the status freshness threshold; if it does, the cached data is reused first to support fast initial display; if it does not meet the threshold, the corresponding status interface request is initiated first, and a placeholder display of "status updating" is used when necessary to avoid blocking the initialization of the core vehicle control components. "Operable" on the initial screen indicates that the vehicle control components have completed initialization and can receive user input, but does not mean that vehicle control commands can be directly issued based on the cached status.

[0169] If the prediction fails, the missing resources are added according to the normal loading process, and the deviation is recorded for subsequent feedback updates. Furthermore, the following rollback handling paths can be adopted when a prediction fails: immediately suspend low-priority resource loading tasks that have not yet started; increase the priority of the resources corresponding to the function actually accessed by the user; reuse already loaded general basic resources to avoid repeated initialization; record the triggering time, feature combination, expected probability of candidate occurrence, and final actual behavior of this failure for subsequent parameter adjustments.

[0170] Finally, the feedback update module records at least one of the following data: whether the predicted candidate vehicle control intent matches the user's actual vehicle control intent; whether pre-loaded resources are actually reused; the operable time of the first screen of remote vehicle control; the interactive time of the vehicle control buttons; the loading time of each key resource; the response time of the status interface; and the proportion of invalid pre-loaded bytes. Based on the feedback, the vehicle control intent scoring model parameters, rule weights, resource mapping tables, or resource loading priority strategies are updated to improve subsequent hit rates and loading benefits.

[0171] Preferably, the feedback update can be executed at two levels: "real-time policy update" and "offline statistical update". The real-time policy update is used to quickly adjust the resource orchestration weights based on the current network status, current device capabilities, or current session behavior. The offline statistical update is used to perform batch optimization of intent model parameters, mapping relationships, and thresholds based on intent hit rate, critical resource coverage, preloaded resource utilization, invalid preloaded byte ratio, and performance indicators over a period of time.

[0172] Furthermore, the following key technical parameters may be adopted in this application, and the following parameters are only preferred examples:

[0173] 1. The number of candidate intentions K can be set to 1 to 3;

[0174] 2. The trigger prediction window can be set to a prediction window within 0.5 to 10 seconds before entering the remote vehicle control home screen;

[0175] 3. The vehicle status freshness threshold can be set from 3 seconds to 300 seconds according to the status type;

[0176] 4. The completion threshold for Level 1 resources can be set from 70% to 100% to determine whether the first screen can be entered into an operable state in advance;

[0177] 5. The criteria for determining a weak network can be comprehensively determined based on network type, packet loss rate, latency, or historical response time of the interface;

[0178] 6. The historical behavior time decay parameter τ can be set from 1 hour to 30 days according to the behavior type;

[0179] 7. The minimum candidate probability threshold θ_min can be set to 0.10 to 0.30;

[0180] 8. The candidate cumulative coverage threshold η can be set to 0.60 to 0.90;

[0181] 9. The intentional low confidence threshold θ_low can be set to 0.35 to 0.60 to trigger a conservative orchestration strategy;

[0182] 10. The background threshold θ_bg for uncontrolled vehicle intent can be set to 0.40 to 0.70 to trigger a conservative orchestration strategy when the background label probability is high.

[0183] 11. The threshold δ for determining multiple candidate intentions can be set to 0.02 to 0.10;

[0184] The above thresholds satisfy 0≤θ_min≤θ_low≤1 and 0≤θ_bg≤1; η is not less than θ_low and η≤1.

[0185] 12. The fusion weight λ between rule probability and model probability can be set to 0 to 1; when only rule scoring is used, λ=1;

[0186] 13. The priority-dependent propagation attenuation coefficient ρ can be set to 0.50 to 1;

[0187] 14. The maximum number of concurrent slots in the releasable occupancy budget can be set from 1 to 6 according to network quality and device level; the maximum pre-initialized memory usage can be configured according to terminal capabilities; the maximum number of prefetched bytes and the maximum number of interface requests in the cumulative consumption budget can be configured according to the current prediction window, network quality, and service throttling requirements.

[0188] In this application, the intent score, expected occurrence probability, expected reuse benefit, and resource priority score are related as follows:

[0189] Z_i=b_i+Σ_j(w_ij×x_j×v_j)+Σ_k(g_ik×c_k);

[0190] When scoring by rules, P_i = exp(Z_i) / Σ_qexp(Z_q);

[0191] When merging scores, P_i'=λP_i^r+(1-λ)P_i^m, and after applying the availability mask, it is renormalized according to P_i=P_i' / Σ_qP_q';

[0192] For the set of executable vehicle control intentions I_act, P_max^act = max_{i∈I_act}(P_i); the background label "no vehicle control intention" does not belong to I_act;

[0193] H_r=min(1, Σ_{i∈C}(P_i×M_ir));

[0194] S_r=αH_r+βK_r+γU_r+μR_r-εC_r-φL_r.

[0195] When propagating based on priority, S_r*=max(S_r, max_{d∈Desc(r)}(S_d×ρ^l(r,d))).

[0196] When making budget judgments, the sum of the cumulative consumption and c_r^cum does not exceed B_cum, and the sum of the current occupancy and c_r^occ does not exceed B_occ; after the task is completed, only the releasable occupancy corresponding to c_r^occ is released, and c_r^cum that has already occurred is not replenished.

[0197] The meanings of the symbols remain consistent with those in sections 3.4.1 to 3.4.4. α, β, γ, μ, ε, and φ are non-negative weights, which can be configured based on business objectives such as first-screen latency, the proportion of invalid preloaded bytes, and device resource usage, or adjusted based on historical data. The above formula represents a preferred implementation and does not restrict the use of equivalent probability normalization, resource benefit aggregation, or sorting calculation methods.

[0198] The following are several specific embodiments of the above method:

[0199] Example 1: Air conditioning operation in a high-temperature environment

[0200] When a user opens the app on a weekday evening, the system detects the following conditions:

[0201] 1. I have turned on the air conditioner multiple times during similar time periods recently;

[0202] 2. The vehicle's air conditioning is currently off;

[0203] 3. The current external ambient temperature is high, or the current season and time of day indicate that the user is likely to use the air conditioner.

[0204] 4. Vehicles are online;

[0205] 5. The network quality is good.

[0206] The system first checks the update time of each state, sets an expiration flag for states that exceed the corresponding freshness threshold, decays the most recent vehicle control behavior according to the time difference, and normalizes the air conditioning frequency x_1, ambient temperature x_2, air conditioning off status x_3, and vehicle online status x_4 for similar time periods. As an example, the feature vector is X = (0.8, 0.9, 1, 1), with each validity value being 1. To demonstrate the reproducible calculation process of the rule scoring, the exemplary parameters in the table below can be used; "Scenario Item" represents the current round's total value of Σ_k(g_ik × c_k):

[0207]

[0208] Table 2

[0209] For example, the original score for turning on the air conditioner is 0.10 + 0.80 × 0.8 + 0.80 × 0.9 + 0.40 × 1 + 0.20 × 1 + 0.24 = 2.30. Normalizing the five original scores in the table above using Softmax, the probabilities of turning on the air conditioner, checking the charging status, unlocking the vehicle, other vehicle control intentions, and no vehicle control intention are approximately 0.5015, 0.1999, 0.1496, 0.0993, and 0.0498, respectively.

[0210] When θ_low=0.35, θ_bg=0.50, K=3, θ_min=0.14, and η=0.70, the probability of the highest executable action is approximately 0.5015, which is not considered low confidence, and the probability of the expected occurrence of no vehicle control is lower than the background threshold. The system selects "turn on the air conditioner" and "check the charging status" as candidate intents, with a cumulative probability of approximately 0.7014. After querying the mapping table, the system identifies the vehicle online status interface, the general vehicle control container, and the general authentication status as shared resources, and identifies the air conditioner control component, the air conditioner status interface, and the air conditioner command interface call context as dedicated first-level resources for turning on the air conditioner, and the charging status component and the power interface as dedicated resources for checking the charging status.

[0211] For a common resource that simultaneously links turning on the air conditioner and checking the charging status, when the corresponding association strength is 1 for both, its expected reuse benefit H_r = min(1, 0.5015 + 0.1999) is approximately 0.7014. Further using α = 0.35, β = 0.25, γ = 0.15, μ = 0.10, ε = 0.10, φ = 0.05, and ρ = 0.80, the following exemplary resource attributes and scores can be obtained:

[0212]

[0213] Table 3

[0214] In this example, R5 depends on R2. Since R5's S_r is 0.650, and R2's propagation candidate value is 0.650 × 0.80 = 0.520, which is higher than R2's base score of 0.440, R2's S_r* is updated to 0.520. Other resources do not receive higher successor propagation values ​​in this example, so their S_r* remains unchanged.

[0215] Assume the cumulative budget consumed in this round, B_cum, is "maximum prefetch 700KB, maximum interface requests 3," and the available budget, B_occ, is "maximum concurrent slots 2, maximum pre-initialized memory 32MB." The initial schedulable set does not include R5, which has not yet satisfied the prerequisite dependency of R2; the system first starts R1 and R4. After any task completes, the concurrent slot is released, and then R2, which has been boosted by dependency propagation, is started; after R2 reaches a reusable state, R5 enters the schedulable set and starts with an effective priority of 0.650, preceding R3, followed by R3 and R6 in sequence. This results in the example startup order R1, R4, R2, R5, R3, R6; the cumulative prefetch is 600KB, and the number of interface requests is 3, neither exceeding B_cum; at any given time, the concurrent slots and memory usage do not exceed B_occ. Shared resources are not absolutely prioritized without considering the overall score, but rather their order is determined by the combined effects of resource level, benefit, cost, and dependency propagation.

[0216] After a user enters the remote vehicle control home screen, the air conditioning control area is prioritized to become operable. If the user's goal is confirmed to be turning on the air conditioning before R6 is started, the R6 that has not yet been started can be canceled, and the prepared shared resources can be retained. The above values ​​are used to illustrate the complete processing from multi-source features, expected probability of occurrence, candidate set, resource aggregation to budget and dependency constraint queue, without limiting specific weights and thresholds.

[0217] Example 2: Status monitoring during charging

[0218] The user's vehicle is charging, and the user checked the charging page first on each of their last three app openings. Based on this, the system predicts a high probability of the user checking the charging status and prioritizes loading the charging status component, battery level interface, estimated remaining charging time interface, and basic feedback display component. Upon entering the homepage, the user can quickly view key charging information without waiting for the full remote vehicle control page to load.

[0219] Example 3: Unlocking Scenario in a Weak Network Environment

[0220] When a user approaches the vehicle and opens the app, the current network quality is poor, and the vehicle door lock status is locked. The system predicts that "unlock the vehicle" is a high-probability intent and reduces the maximum concurrent slot bits for this round to 1, excluding Level 3 resources from the current prefetch budget. According to the dependency graph, the system first prepares the general authentication status and door lock status interfaces, then prepares the door lock control component, unlock command interface call context, and basic feedback component, while placing marketing cards, unnecessary images, and auxiliary instructions into a deferred queue. The unlock command interface call context does not contain the actual unlock command; after the user clicks unlock, the system re-executes token, permission, and necessary vehicle status verifications, and then sends the command according to the normal security link. This allows limited bandwidth to be prioritized for unlocking critical links without compromising vehicle control security requirements.

[0221] Example 4: Multiple Candidates, Approximate Parallelism, and Low Confidence Scenarios

[0222] In the example configuration with θ_low=0.35, θ_bg=0.50, θ_min=0.15, η=0.70, and δ=0.05, when the probability of "no vehicle control intention" is lower than θ_bg, and the probabilities of "turn on the air conditioner" and "check the charging status" are 0.50 and 0.20 respectively, the probability of the highest executable action is not lower than θ_low. The difference between the two probabilities is greater than δ, but the cumulative probability reaches η. The system will treat both as candidate intentions. At this time, H_r will be included in the comprehensive score. When the resource level and other scoring factors are comparable, shared resources with higher benefits will be prepared first, and then dedicated resources will be prepared according to their respective probabilities and resource costs.

[0223] When the expected probability of an uncontrolled vehicle is lower than θ_bg, and the probabilities of "checking charging status" and "unlocking the vehicle" are 0.38 and 0.34 respectively, the probability of the highest executable action is not lower than θ_low, and the probability difference between the two is 0.04 and not greater than δ. The system marks the two as approximately parallel intentions, prioritizes preparing shared resources such as the vehicle online status interface, general authentication status, basic feedback prompt components, and general vehicle control container, and delays loading the larger, differentiated dedicated components.

[0224] When the probability of the highest executable action is, for example, 0.30, lower than θ_low=0.35, or the expected probability of no-control vehicle occurrence is not lower than θ_bg=0.50, the system first adopts a conservative strategy, no longer actively preloading dedicated candidate resources, but only preparing general vehicle control basic resources and necessary lightweight vehicle state resources, waiting for further user clicks. The above three paths correspond to "multiple candidate intentions", "candidate probabilities are close", and "insufficient background or overall confidence", respectively, and are executed in the order of background and low confidence judgment, candidate set formation, and parallel judgment to avoid branch overlap.

[0225] After implementation, the technical effectiveness can be verified through the following indicators: the time when the remote vehicle control first screen is operable; the time when the vehicle control command is ready; the time when the vehicle control button is interactive; the coverage rate of key resources; the utilization rate of preloaded resources; the proportion of invalid preloaded bytes; the availability rate of key areas on the first screen in weak network scenarios; and the average waiting time of the vehicle status interface.

[0226] The above metrics are preferably calculated using a unified standard: The first screen operable time for remote vehicle control is the duration from the start of the remote vehicle control page navigation to the moment when the core vehicle control components on the first screen complete initialization and are able to receive user input; the lead time for predicted triggering before the page navigation is recorded separately as the prediction lead time and is not used interchangeably with the first screen operable time; the vehicle control command readiness time is the duration from the start of the remote vehicle control page navigation to the moment when the components, necessary states, and calling context required for the target vehicle control function are all ready, but the actual vehicle control command has not yet been sent; the interactive time of the vehicle control button is the duration from the start of the page navigation to the moment when the target button can respond to clicks and enter the subsequent security verification process; critical resource coverage refers to the critical resources required for the actual target vehicle control process that have reached a reusable state before being requested for the first time. The ratio of resource quantity to the total number of critical resources actually required by the target process; the preloaded resource utilization rate, which is the ratio of the number of resources prepared in advance and reused by the actual target process within the preset statistical window to the total number of resources prepared in advance in this round; the invalid preloaded byte ratio, which is the ratio of the number of resource bytes preloaded in advance but not actually reused within the preset statistical window to the total number of preloaded resource bytes in this round; the availability rate of the key area of ​​the first screen in weak network scenarios, which is the ratio of the number of sessions in which the core vehicle control components of the first screen reach an operable state within the target time threshold to the total number of weak network sessions in the sessions that meet the weak network judgment conditions; the average waiting time of the vehicle status interface, which is the time from the time the target vehicle status interface request is initiated to the time when a valid response that passes the freshness check is obtained or the timeout condition is reached, and the average value is calculated according to the corresponding interface requests within the statistical window.

[0227] In a typical implementation, this invention can enable high-frequency remote vehicle control functions to reach an operational state earlier without significantly increasing user-perceived costs, and reduce performance losses caused by non-critical resources preempting critical links. Preferably, the effect can be verified from the following perspectives through comparative experiments or online A / B experiments: under the same network conditions, compare the difference in first-screen operability time between the traditional page-level fixed preloading scheme and the scheme of this invention; in weak network scenarios, compare the difference in the interactive time of the key vehicle control buttons of the two schemes; compare the critical resource coverage, preloading resource utilization, and proportion of invalid preloading bytes of the two schemes; compare the status interface waiting time and user operation completion time in high-frequency vehicle control action scenarios.

[0228] In a specific embodiment, such as Figure 4As shown, a vehicle control processing method is also provided, including:

[0229] Step S401: In response to the vehicle control intention trigger event for the target vehicle, obtain multi-source feature information corresponding to the target vehicle and determine multiple candidate vehicle control intentions that match the target vehicle.

[0230] Step S402: For each candidate vehicle control intention, determine the intention score of the candidate vehicle control intention based on the basic bias of the candidate vehicle control intention, each vehicle control feature information, and the weight of each vehicle control feature information for the candidate vehicle control intention.

[0231] Step S403: Based on the score ratio of each intent, determine the expected probability of occurrence of the candidate vehicle control intent;

[0232] Step S404: For each vehicle control resource used to trigger the vehicle control operation, the candidate vehicle control intent with the highest expected probability of occurrence is determined as the first vehicle control intent.

[0233] Step S405: If the expected probability of the first vehicle control intention is higher than the first threshold and the expected probability of no vehicle control intention is lower than the second threshold, then select the vehicle control intention that includes the first vehicle control intention.

[0234] Among them, the first threshold is greater than the second threshold;

[0235] Step S406: From the various vehicle control resources, filter the selected vehicle control resources that are associated with the selected vehicle control intent;

[0236] Step S407: For each selected vehicle control resource, calculate the expected reuse benefit of the selected vehicle control resource based on the correlation strength between the selected vehicle control resource and the selected vehicle control intention, as well as the expected probability of the selected vehicle control intention.

[0237] Step S408: Based on the successive relationship between the selected vehicle control resources and other selected vehicle control resources, as well as the expected reuse benefits, determine the resource preparation priority of the selected vehicle control resources;

[0238] Among them, the priority of resource preparation is positively correlated with both the expected probability of occurrence and the strength of the correlation.

[0239] Step S409: Obtain the resource usage limit of the target vehicle and the resource usage of each vehicle control resource;

[0240] Step S410: According to the priority of each resource preparation, the resource usage of each vehicle control resource is stacked in sequence. If the total resource usage after stacking is less than or equal to the upper limit of resource usage, the stacked vehicle control resource is used as the preloaded vehicle control resource to be preloaded first.

[0241] Step S411: After any preloaded vehicle control resource is preloaded, other vehicle control resources are preloaded according to the resource preparation priority under the constraint of the resource usage limit.

[0242] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0243] Based on the same inventive concept, this application also provides a vehicle control processing device for implementing the vehicle control processing method described above. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more vehicle control processing device embodiments provided below can be found in the limitations of the vehicle control processing method above, and will not be repeated here.

[0244] In one exemplary embodiment, such as Figure 5 As shown, a vehicle control processing device 500 is provided, including: a multi-source feature information acquisition module 502, an expected occurrence probability determination module 504, a resource preparation priority determination module 506, and a resource preloading module 508, wherein:

[0245] The multi-source feature information acquisition module 502 is used to acquire multi-source feature information corresponding to the target vehicle in response to a vehicle control intention triggering event for the target vehicle, and to determine multiple candidate vehicle control intentions that match the target vehicle.

[0246] The expected occurrence probability determination module 504 is used to determine the expected occurrence probability of each candidate vehicle control intention based on multi-source feature information.

[0247] The resource preparation priority determination module 506 is used to determine the resource preparation priority of each vehicle control resource used to trigger the vehicle control operation based on the expected occurrence probability of the candidate vehicle control intention associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intention; the resource preparation priority is positively correlated with both the expected occurrence probability and the association strength.

[0248] The resource preloading module 508 is used to preload each vehicle control resource according to the resource preparation priority.

[0249] In one exemplary embodiment, the resource preparation priority determination module 506 includes:

[0250] The vehicle control intent determination unit is used to determine the candidate vehicle control intents whose expected probability of occurrence meets the probability condition as the selected vehicle control intents.

[0251] The vehicle control resource selection unit is used to select the vehicle control resources that are associated with the selected vehicle control intention from among the various vehicle control resources.

[0252] The resource preparation priority determination unit is used to determine the resource preparation priority of the selected vehicle control resources according to the correlation strength between the selected vehicle control resources and the selected vehicle control intention, as well as the expected probability of the selected vehicle control intention occurring.

[0253] Resource preloading module 508 is used for:

[0254] According to the priority of each resource preparation, preload the resources of each selected control vehicle.

[0255] In an exemplary embodiment, candidate vehicle control intentions include no vehicle control intention. In this embodiment, the vehicle control intention determination unit is specifically used for:

[0256] The candidate vehicle control intention with the highest expected probability of occurrence is identified as the first vehicle control intention;

[0257] If the expected probability of the first vehicle control intention is higher than a first threshold and the expected probability of no vehicle control intention is lower than a second threshold, then the selected vehicle control intention containing the first vehicle control intention is determined; the first threshold is greater than the second threshold.

[0258] In an exemplary embodiment, the resource preparation priority determination unit is specifically used for:

[0259] For each selected vehicle control resource, the expected reuse benefit of the selected vehicle control resource is determined by calculating the correlation strength between the selected vehicle control resource and the selected vehicle control intention, as well as the expected probability of the selected vehicle control intention occurring.

[0260] Based on the successor-successor relationship between the selected vehicle control resources and other selected vehicle control resources, as well as the expected reuse benefits, the resource preparation priority of the selected vehicle control resources is determined.

[0261] In one exemplary embodiment, the resource preloading module 508 is further configured to:

[0262] Obtain the resource usage limit of the target vehicle and the resource usage of each vehicle control resource;

[0263] According to the priority of each resource preparation, the resource usage of each vehicle control resource is added up in sequence. If the total resource usage after addition is less than or equal to the resource usage limit, the vehicle control resource after addition will be used as the preloaded vehicle control resource first.

[0264] After any preloaded vehicle control resource is preloaded, other vehicle control resources are preloaded according to the resource preparation priority, subject to the resource usage limit.

[0265] In an exemplary embodiment, the multi-source feature information includes vehicle control feature information corresponding to each of multiple vehicle control features. In this embodiment, the expected occurrence probability determination module 504 is specifically used for:

[0266] Based on the basic bias of the candidate vehicle control intention, each vehicle control feature information, and the weight of each vehicle control feature information for the candidate vehicle control intention, the intention score of the candidate vehicle control intention is determined.

[0267] Based on the score percentage of each intent, the expected probability of occurrence of the candidate vehicle control intent is determined.

[0268] Each module in the aforementioned vehicle control processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0269] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a vehicle control processing method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0270] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0271] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0272] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0273] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0274] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0275] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0276] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0277] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A vehicle control processing method, characterized in that, The method includes: In response to a vehicle control intention trigger event for a target vehicle, multi-source feature information corresponding to the target vehicle is obtained, and multiple candidate vehicle control intentions matching the target vehicle are determined. For each candidate vehicle control intention, the expected probability of occurrence of the candidate vehicle control intention is determined based on the multi-source feature information; For each vehicle control resource used to trigger a vehicle control operation, the resource preparation priority of the vehicle control resource is determined based on the expected occurrence probability of the candidate vehicle control intent associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intent; the resource preparation priority is positively correlated with both the expected occurrence probability and the association strength. According to the resource preparation priority, the vehicle control resources are preloaded.

2. The method according to claim 1, characterized in that, The step of determining the resource preparation priority of the vehicle control resource based on the expected occurrence probability of the candidate vehicle control intentions associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intentions includes: Candidate vehicle control intentions whose expected probability of occurrence meets the probability condition are selected as vehicle control intentions; From the various vehicle control resources, select the vehicle control resources that are associated with the selected vehicle control intention; The resource preparation priority of the selected vehicle control resources is determined based on the correlation strength between the selected vehicle control resources and the selected vehicle control intention, as well as the expected probability of the selected vehicle control intention occurring. The step of preloading each of the vehicle control resources according to the resource preparation priority includes: According to the resource preparation priority, preload the selected vehicle control resources as described above.

3. The method according to claim 2, characterized in that, The candidate vehicle control intentions include no vehicle control intention; the step of determining the candidate vehicle control intentions whose expected probability of occurrence satisfies the probability condition as the selected vehicle control intentions includes: The candidate vehicle control intention with the highest expected probability of occurrence is identified as the first vehicle control intention; If the expected probability of the first vehicle control intention is higher than a first threshold and the expected probability of the no vehicle control intention is lower than a second threshold, a selected vehicle control intention including the first vehicle control intention is determined; the first threshold is greater than the second threshold.

4. The method according to claim 2, characterized in that, The step of determining the resource preparation priority of the selected vehicle control resource based on the correlation strength between the selected vehicle control resource and the selected vehicle control intention, and the expected probability of the selected vehicle control intention occurring, includes: For each selected vehicle control resource, the expected reuse benefit of the selected vehicle control resource is determined by calculating the correlation strength between the selected vehicle control resource and the selected vehicle control intention, as well as the expected probability of the selected vehicle control intention occurring. Based on the successor-successor relationship between the selected vehicle control resources and other selected vehicle control resources, and the expected reuse benefits, the resource preparation priority of the selected vehicle control resources is determined.

5. The method according to claim 1, characterized in that, The step of preloading each of the vehicle control resources according to the resource preparation priority includes: Obtain the resource usage limit of the target vehicle and the resource usage of each vehicle control resource; According to the resource preparation priority, the resource usage of each vehicle control resource is added up in sequence. If the total resource usage after addition is less than or equal to the resource usage limit, the vehicle control resource after addition is used as the preloaded vehicle control resource to be preloaded first. After any of the preloaded vehicle control resources has been preloaded, other vehicle control resources are preloaded according to the resource preparation priority, under the constraint of the resource usage limit.

6. The method according to claim 1, characterized in that, The multi-source feature information includes vehicle control feature information corresponding to each of the multiple vehicle control features; determining the expected occurrence probability of the candidate vehicle control intention based on the multi-source feature information includes: Based on the basic bias of the candidate vehicle control intention, each of the vehicle control feature information, and the weight of each of the vehicle control feature information for the candidate vehicle control intention, the intention score of the candidate vehicle control intention is determined. Based on the score ratio of each of the aforementioned intentions, the expected probability of occurrence of the candidate vehicle control intention is determined.

7. A vehicle control processing device, characterized in that, The device includes: The multi-source feature information acquisition module is used to acquire multi-source feature information corresponding to the target vehicle in response to a vehicle control intention triggering event for the target vehicle, and to determine multiple candidate vehicle control intentions that match the target vehicle. The expected occurrence probability determination module is used to determine the expected occurrence probability of each candidate vehicle control intention based on the multi-source feature information. The resource preparation priority determination module is used to determine the resource preparation priority of each vehicle control resource used to trigger vehicle control operation based on the expected occurrence probability of the candidate vehicle control intention associated with the vehicle control resource and the association strength between the vehicle control resource and the associated candidate vehicle control intention; the resource preparation priority is positively correlated with both the expected occurrence probability and the association strength. The resource preloading module is used to preload each of the vehicle control resources according to the resource preparation priority.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images