Vehicle control method and device, medium and product

Abstract

The invention provides a vehicle control method and device, a medium and a product. The method comprises the following steps: acquiring operation information and load information of a target vehicle in a current scene; determining service information of the target vehicle in the next scene based on the operation information; the service information comprises a plurality of scene services corresponding to the next scene; and controlling resource scheduling of the plurality of scene services based on the load information.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a vehicle control method, device, medium, and product. Background Technology

[0002] With the rapid development of in-vehicle infotainment applications, the load rate of in-vehicle infotainment systems is getting higher and higher. In related technologies, in-vehicle infotainment systems mainly adopt static resource allocation during use, which cannot dynamically respond to different scenarios. Summary of the Invention

[0003] This application provides a vehicle control method, device, equipment, medium, and product that can solve the problem that resource allocation methods in related technologies cannot dynamically respond to different scenarios.

[0004] This application provides a vehicle control method, the method comprising: Obtain the target vehicle's operating and load information in the current scenario; Based on the operational information, the service information of the target vehicle in the next scenario is determined; the service information includes multiple scenario services corresponding to the next scenario. Based on the load information, resource scheduling for multiple scenario services is controlled.

[0005] In the above scheme, the operational information includes user behavior information and vehicle status information; determining the service information of the target vehicle in the next scenario based on the operational information includes: The user behavior information is input into the behavior time series model to obtain the behavior prediction information for the next scenario; Based on the behavior prediction information and the vehicle status information, multiple scenario services and the service priority of each scenario service are determined; the service information also includes the service priority.

[0006] The method in the above scheme further includes: Obtain historical user behavior information for the target vehicle; Generate a user behavior sequence for the target vehicle based on the historical user behavior information; Feature extraction is performed on the user behavior sequence to obtain the user behavior feature vector of the target vehicle; The behavior time series model is obtained based on the user behavior feature vector.

[0007] In the above scheme, the step of controlling resource scheduling of multiple scenario services based on the load information includes: Determine the resource information of multiple scenario services; Based on the resource information and the load information, a preloading strategy is determined for multiple scenario services; Based on the preloading strategy, multiple scenario services are preloaded into the memory of the target vehicle.

[0008] In the above scheme, controlling resource scheduling of multiple scenario services based on the load information includes: The trigger parameters of the first process and the quota parameters of the control group are determined based on the load information; the first process includes a low memory killer daemon. Based on the triggering parameters and the quota parameters, a load reduction strategy for multiple scenario services is determined. The load reduction strategy reduces the load rate of the target vehicle to a preset threshold.

[0009] In the above scheme, controlling resource scheduling of multiple scenario services based on the load information includes: Obtain the historical file access information of the target vehicle; Feature extraction is performed on the historical file access information to obtain the file usage pattern features of the target vehicle; A file prediction model is obtained based on the file usage pattern characteristics; Based on the file prediction model and the load information, file cleanup strategies are determined for multiple scenario services; Clean up the file memory of the target vehicle based on the file cleanup strategy.

[0010] In the above scheme, controlling resource scheduling of multiple scenario services based on the load information includes: The load information is input into the fault prediction model to obtain the fault prediction information of the target vehicle in the next scenario; Based on the fault prediction information, fault preprocessing strategies are determined for multiple scenario services. During the operation of multiple scenario services, the memory of the target vehicle is reclaimed based on the fault preprocessing strategy.

[0011] A vehicle control device, the device comprising: The acquisition unit is used to acquire the target vehicle's operating information and load information in the current scenario; The processing unit is configured to determine the service information of the target vehicle in the next scenario based on the operational information; the service information includes multiple scenario services corresponding to the next scenario; The processing unit is also used to control the resource scheduling of multiple scenario services based on the load information.

[0012] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the vehicle control method provided in this application when executed by a processor.

[0013] This application provides a computer program product, including a computer program or computer-executable instructions. When the computer program or computer-executable instructions are executed by a processor, they implement the vehicle control method provided in this application.

[0014] The embodiments of this application have the following beneficial effects: by obtaining the operating information and load information of the target vehicle in the current scenario; determining the service information of the target vehicle in the next scenario based on the operating information; the service information includes multiple scenario services corresponding to the next scenario; and controlling the resource scheduling of multiple scenario services based on the load information, the resource scheduling of the vehicle is dynamically adjusted according to different scenarios to respond to the scenario services corresponding to different scenarios, thus solving the problem that the resource allocation method in related technologies cannot dynamically respond to different scenarios. Attached Figure Description

[0015] Figure 1 A schematic flowchart of a vehicle control method provided in an embodiment of this application; Figure 2 A schematic diagram of the framework of an in-vehicle operating system provided in an embodiment of this application; Figure 3 A schematic diagram of a performance monitoring process provided in an embodiment of this application; Figure 4 A flowchart illustrating the fault management process provided in this application embodiment; Figure 5 A schematic flowchart illustrating another vehicle control method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a vehicle control device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0018] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0019] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0020] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0021] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0022] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0023] In related technologies, as the life cycle of intelligent vehicles extends (generally reaching 8-10 years), the long-term operation of vehicle infotainment systems faces the following three problems: Software redundancy and fragmentation: Frequent (Over-The-Air, OTA) remote upgrades result in redundant files remaining in the system, occupying storage space and reducing read and write efficiency.

[0024] Cache backlog: Long-term accumulation of user behavior data, log files, etc., consumes memory resources and causes interface lag.

[0025] Dynamic load imbalance: High-concurrency scenarios (such as multiple applications calling sensors, navigation, and entertainment systems at the same time) can cause a surge in controller load, which in extreme cases can trigger a reset of the vehicle control unit (VCU), affecting driving safety.

[0026] Figure 1 This is an optional flowchart illustrating the vehicle control method provided in this application embodiment. The following will be combined with... Figure 1 The steps shown are explained as follows: Figure 1 As shown, the method includes steps 101 to 103: Step S101: Obtain the target vehicle's operating information and load information in the current scenario.

[0027] Understandably, operational information can represent a set of dynamic information generated by the vehicle in the current usage scenario, including but not limited to user behavior information (such as starting navigation and playing music) and vehicle status information (such as battery level, vehicle speed, geographical location, and network connection status). Load information represents the current resource usage of the system, including but not limited to the utilization rate of the Central Processing Unit (CPU), memory usage, and the number of processes.

[0028] In practical applications, vehicles may encounter different scenarios during operation, such as highway driving, parking, and commuting. The onboard operating system can predict the next scenario the vehicle may enter based on operational and load information, and determine the necessary services for that scenario.

[0029] refer to Figure 2 As shown, the vehicle operating system can include a multi-layer structure. The vehicle terminal can integrate a multi-dimensional perception engine, including sensors, application logs, and user interaction records, to update operating and load information in real time, enabling more accurate perception and providing a reliable basis for subsequent scenario prediction and resource allocation.

[0030] The agent layer serves as the hub for interaction and decision-making, and includes: Multimodal interaction: Integrating voice assistants (such as "Hello, XX"), gesture recognition, eye tracking, and emotion computing to provide the most natural and intuitive interactive experience.

[0031] Context awareness and personalization: Based on user habits, real-time location, schedule, vehicle status, and other information, proactively provide intelligent suggestions. For example, automatically navigate to the company during commuting time, or recommend nearby gas stations when low on fuel is detected.

[0032] Task orchestration and automation: It understands and executes complex instructions, such as "I'm cold and want to listen to some light music," and can automatically adjust the air conditioner temperature and play the corresponding playlist.

[0033] In-vehicle application ecosystem platform: As the carrier of in-vehicle application stores and services, it manages the operation, lifecycle and resource scheduling of applications.

[0034] Neural network layers can include: Perception Model: Responsible for processing raw data from sensors such as cameras, LiDAR, and millimeter-wave radar to achieve obstacle detection, lane line recognition, traffic sign recognition, pedestrian detection, and free space segmentation.

[0035] Cognitive and decision-making models: These models handle more advanced tasks, such as behavior prediction (predicting the intentions of other vehicles and pedestrians), path planning, and driving strategy generation, and are key to achieving high-level autonomous driving.

[0036] Speech and Natural Language Processing Model: Supports speech interaction in the agent layer, enabling accurate speech recognition, semantic understanding, and natural and fluent speech synthesis.

[0037] The AI ​​runtime layer ensures that various neural network models can run efficiently and with low latency on in-vehicle computing hardware.

[0038] The hardware layer is the material foundation of the entire operating system, providing computing, sensing, and execution capabilities for all functions in the upper layers. Step S102: Determine the service information of the target vehicle in the next scenario based on the operation information; the service information includes multiple scenario services corresponding to the next scenario.

[0039] Understandably, scenario services may include a set of functional modules or applications that need to be executed, such as navigation services, voice interaction services, entertainment services, etc.

[0040] In practical applications, common commuting scenarios include navigation and voice assistant services. Each service has different priorities and dependencies. Therefore, when predicting the services needed for the next scenario, the services can be predicted based on the user's historical behavior information. For example, a behavioral time-series model can be trained based on the user's historical behavior information to predict user behavior in different scenarios. The in-vehicle operating system can predict user behavior in advance based on historical behavior, combine it with vehicle status information, dynamically predict the service combinations needed for different scenarios, and preload them according to priority to improve user experience. For example, if a user starts navigation and plays music at 8:00 AM every morning and arrives at the company around 9:00 AM, the in-vehicle operating system can automatically run the navigation and music applications between 8:00 and 9:00 AM. When the vehicle approaches the company, the operating system can preload the parking space finding application and prepare to close the navigation application. If the parking space is underground, it can also prepare to turn on the vehicle's headlights.

[0041] Step S103: Control resource scheduling for multiple scenario services based on load information.

[0042] Understandably, resource scheduling refers to the resource allocation rules of an in-vehicle operating system. Resource scheduling can determine the execution order, resource quotas, and priority adjustments of multiple scenario services, aiming to optimize the performance and stability of the in-vehicle operating system. For example, under low load conditions, the in-vehicle operating system can allow all scenario services to execute concurrently; while under high load conditions, the system may restrict resource allocation for non-critical services, or even delay the execution time of non-critical services.

[0043] In practical applications, in order to achieve flexible resource management, it can also automatically clean up unimportant processes or cached data when the system memory is insufficient, so as to prevent system crashes.

[0044] As can be seen from the above, this application embodiment obtains the target vehicle's operating information and load information in the current scenario; determines the target vehicle's service information in the next scenario based on the operating information; the service information includes multiple scenario services corresponding to the next scenario; and controls the resource scheduling of multiple scenario services based on the load information. This realizes the dynamic adjustment of vehicle resource scheduling according to different scenarios to respond to the scenario services corresponding to different scenarios, thus solving the problem that the resource allocation method in related technologies cannot dynamically respond to different scenarios.

[0045] In some embodiments of this application, the operational information includes user behavior information and vehicle status information; determining the service information of the target vehicle in the next scenario based on the operational information includes: Input user behavior information into the behavior time series model to obtain behavior prediction information for the next scenario; Based on behavior prediction information and vehicle status information, multiple scenario services and the service priority of each scenario service are determined; the service information also includes service priority.

[0046] In practical applications, user behavior information can reflect users' service usage habits in different scenarios. It can include operation records and interaction data generated by drivers or passengers during vehicle operation, such as navigation usage time, music playback time, and air conditioning temperature settings.

[0047] Behavioral time-series models can capture trends in user behavior across different time periods. For example, users frequently use navigation during commutes and tend to use entertainment systems during rest periods. These models can predict potential user needs in the next scenario, allowing for the preparation of relevant services in advance. (Reference) Figure 2 As shown, the behavioral timing model can be deployed on intelligent devices on the vehicle side, such as the central control screen.

[0048] Service priority is a service response order determined by a comprehensive evaluation of behavioral prediction information and vehicle status information. Services with higher service priority typically have higher real-time requirements or a greater impact on user experience; for example, in low-battery situations, the system prioritizes loading applications with higher service priority. By introducing a service priority mechanism, the system can optimize resource allocation and improve the overall response efficiency and stability of the vehicle.

[0049] User behavior information is used as input to the behavior time series model to obtain behavior prediction information. The behavior prediction information is combined with vehicle status information to determine multiple scenario services for the next scenario and the service priority of each scenario service. This enables intelligent scheduling, improves the intelligence and adaptability of the vehicle system, and reduces the probability of latency and lag.

[0050] In some embodiments of this application, the method further includes: Obtain historical user behavior information for the target vehicle; Generate user behavior sequences for the target vehicle based on historical user behavior information; Feature extraction is performed on the user behavior sequence to obtain the user behavior feature vector of the target vehicle; A behavioral time series model is obtained based on user behavior feature vectors.

[0051] In practical applications, historical user behavior information refers to a series of operations performed by a user on the in-vehicle system, such as navigation startup time, music playback preferences, voice interaction frequency, and application usage duration. Historical user behavior information is typically stored in a time-series format and can be collected through log files, sensor data collection, and other methods. The in-vehicle system can upload historical user behavior information to a local database or edge computing unit for processing. For example, the system can identify the frequent navigation activation patterns during peak morning and evening hours and use this pattern as an important basis for predicting future user behavior. By acquiring historical user behavior information, the in-vehicle operating system can build behavior models that more closely resemble real driving habits, improving prediction accuracy.

[0052] User behavior sequences can be understood as structured sequence data organized chronologically based on historical user behavior information. This typically includes fields such as event type, occurrence time, duration, and context state. For example, a user might start navigation and search for their company destination around 8 AM every Monday, then turn on the radio; this series of actions constitutes a typical behavior sequence. This sequence can be further developed by sorting and encoding these behaviors chronologically.

[0053] User behavior feature vectors can be understood as representative numerical features abstracted from user behavior sequences, such as behavior frequency, behavior intervals, behavior combination patterns, and activity levels within specific time periods. For example, if a user frequently switches radio channels during their commute, features such as the user's channel switching frequency and switching intervals will be extracted by the system and stored and analyzed as part of the feature vector. Through feature extraction, the system can extract key patterns from the original behavior sequences, reducing the complexity of model training while improving prediction accuracy and generalization ability.

[0054] Behavioral temporal models can include recurrent neural networks (RNNs), long short-term memory networks (LSTMs), and others. These models use user behavior feature vectors as input and output predictions of behavior at the next time step or in the next scenario. For example, a system can predict whether a user will perform actions such as opening a parking app or adjusting their seat position after entering a shopping mall parking lot based on their current behavior feature vectors. This allows the vehicle to preload resources related to these actions, thereby improving response speed and user experience.

[0055] As can be seen from the above, the embodiments of this application can achieve accurate prediction of user behavior by acquiring historical user behavior information, generating user behavior sequences, extracting behavior feature vectors, and constructing behavior time series models, thereby effectively improving system response speed, dynamically optimizing resource allocation, and improving the operating efficiency and long-term stability of the vehicle system.

[0056] In some embodiments of this application, resource scheduling for multiple scenario services is controlled based on load information, including: Determine resource information for multiple scenario services; Based on resource information and load information, determine the preloading strategy corresponding to multiple scenario services; Based on the preloading strategy, multiple scenario services are preloaded into the memory of the target vehicle.

[0057] In practical applications, resource information may include, but is not limited to, memory usage, CPU utilization, disk space requirements, and network bandwidth consumption. For example, when a target vehicle is about to enter a high-concurrency scenario (such as autonomous driving and entertainment systems running simultaneously), the system will assess the maximum memory capacity, number of processor cores, and network connection strength required by the target vehicle in the high-concurrency scenario, thereby generating resource information.

[0058] By using a user behavior time-series model and real-time vehicle status (location, battery level, network signal), the resource information of the target vehicle in the next scenario can be determined. Based on the resource information of the target vehicle in the next scenario and the current load information, a preloading strategy corresponding to multiple scenario services can be determined.

[0059] Before a target vehicle enters a specific scenario, it can preload the code, data, and configuration files required for the relevant scenario services into memory according to a preloading strategy. Preloaded objects can include application modules, system service components, or third-party functional plugins. Preloading can be dynamically adjusted in conjunction with reinforcement learning models to adapt to constantly changing driving environments and user needs.

[0060] As can be seen from the above, by preloading multiple scenario services with resource and load information, the function startup delay during scenario switching can be reduced, and the smoothness and response efficiency of the vehicle system can be improved.

[0061] In some embodiments of this application, resource scheduling for multiple scenario services is controlled based on load information, including: The trigger parameters of the first process and the quota parameters of the control group are determined based on the load information; the first process includes the low memory killer daemon. Determine the load reduction strategy for multiple service scenarios based on trigger parameters and quota parameters; The load reduction strategy aims to lower the load rate of the target vehicle to a preset threshold.

[0062] Understandably, the Low Memory Killer Daemon (LMKD) is a system process running at the operating system level. Its core function is to proactively terminate non-critical applications or services that consume a lot of memory when the system's available memory is insufficient, thereby freeing up memory resources and maintaining stable system operation. The triggering parameters can be understood as the conditions under which the Low Memory Killer Daemon starts when the system load reaches a certain threshold. For example, activating the Low Memory Killer Daemon when memory usage exceeds 90% can prevent system lag or crashes due to insufficient memory.

[0063] Control groups (Cgroups) are a resource management mechanism provided by the Linux kernel. They are used to limit, record, and isolate the use of system resources (such as CPU and memory) by process groups. Cgroups allow services of different priorities to be assigned to different control groups, and resource quotas can be set for each control group, such as the maximum available CPU time slice percentage and maximum memory capacity. The quota parameters are the resource limits set for each control group; for example, a control group might be limited to using a maximum of 20% of CPU resources. This ensures that high-priority services receive sufficient resource support, while low-priority services are reasonably restricted, avoiding performance degradation caused by resource contention.

[0064] In practical applications, refer to Figure 3 As shown, the Service Operation Center is a full-stack monitoring and automated operation and maintenance platform for the vehicle operating system. Through real-time insights into underlying hardware, middleware, AI models, and upper-layer applications, it achieves a leap from passive response to proactive prevention and then to intelligent optimization, serving as the cornerstone for ensuring the stability of the intelligent cockpit experience and autonomous driving functions. Dynamic priority scheduling ensures that processes and services related to vehicle safety (such as braking, steering, and collision warning) have the highest priority in CPU, network, and memory resources. When the system load is too high, resources for non-critical applications (such as video players) are dynamically limited to ensure the absolute smoothness of safety functions. Predictive resource scheduling allows the system to anticipate complex intersections or highways approaching after the user sets the navigation route, pre-loading high-precision map data and corresponding perception models into memory, and even pre-allocating computing power to ensure the responsiveness of intelligent driving functions at critical moments. Elastic scaling and fault self-healing allow the Service Operation Center to automatically create new service instances within its containers to share the load if scenario services experience increased latency due to excessive concurrent requests, and then automatically reclaim resources after the peak.

[0065] During vehicle operation, performance data from the onboard operating system can be continuously collected to generate load information. Load reduction strategies can be understood as the system's determination of service operation or shutdown plans based on the current load status, resource quotas for each control group, and service priorities.

[0066] The process of generating a load reduction strategy includes the following aspects: Assess load status: The system monitors the overall load in real time, including indicators such as CPU utilization, memory usage, and network bandwidth, to determine whether it is under high load.

[0067] Matching service priorities: Based on service priorities, identify which services are critical (such as driving control systems) and which are non-critical (such as entertainment systems).

[0068] Based on quota parameters, the system limits the maximum amount of resources that each service can use, according to the quota parameters of each control group.

[0069] The system generates a resource allocation scheme: The system ultimately forms a set of resource scheduling instructions to determine which services can continue to run and which services need to be suspended or deloaded.

[0070] As can be seen from the above, the system can dynamically optimize resource allocation in complex and ever-changing operating environments, achieve intelligent load reduction, avoid resource waste or excessive competition, and thus improve the overall efficiency and stability of the system.

[0071] In some embodiments of this application, the method further includes: Obtain historical file access information for the target vehicle; Feature extraction is performed on historical file access information to obtain the file usage pattern features of the target vehicle; A file prediction model is derived based on file usage pattern features; Based on the file prediction model and load information, determine the file cleanup strategies corresponding to multiple service scenarios; Clean up the target vehicle's file memory based on file cleanup strategies.

[0072] In practical applications, historical file access information refers to the access records of various files (such as log files, cache files, configuration files, application data, etc.) by the vehicle's infotainment system during operation. This includes, but is not limited to, metadata such as file name, access time, access frequency, access type (read / write), access size, and accessing user. A file usage pattern feature vector for the target vehicle can be constructed by statistically analyzing access frequency, calculating file lifespan, determining whether the access time distribution exhibits periodicity, and analyzing the correlation between file type and access behavior. This file usage pattern feature vector can then be used as input to a machine learning model to train a prediction model.

[0073] File prediction models can be used to predict whether a specific file will be accessed again within a future time period, or to assess the importance and necessity of a specific file. These models can include logistic regression, decision trees, random forests, support vector machines, and deep learning models; this application does not impose specific limitations on these models. Supervised learning can be used during model training, employing historical file access records as training samples, and the model can be validated and optimized based on actual file cleaning results. The choice of file prediction model should be adjusted according to the specific application scenario. For example, in resource-constrained embedded systems, lightweight models (such as logistic regression or decision trees) are more suitable for deployment; in computationally powerful in-vehicle systems, more complex models (such as deep neural networks) can be used to achieve higher prediction accuracy.

[0074] The file cleanup strategy can be generated based on the output of the file prediction model and the current load status of the vehicle's infotainment system. It can be understood as a set of dynamic cleanup rules. For example, when the system is under high load, it prioritizes cleaning up low-value and long-unused files; while under low load, the system can perform more detailed cleanup operations, such as merging fragments and archiving old logs. Depending on different application scenarios (such as navigation, entertainment, and autonomous driving), the system adjusts the file cleanup strategy accordingly to prevent critical files from being mistakenly deleted.

[0075] As shown above, combining file prediction models and load information to formulate file cleanup strategies can achieve a dynamic, flexible, and intelligent system maintenance mechanism. By combining file prediction models and load information to formulate file cleanup strategies, the relationship between system performance and storage resources can be balanced, thereby preventing system lag caused by redundant file accumulation, extending the lifespan of the vehicle infotainment system, and improving user satisfaction.

[0076] In some embodiments of this application, the method further includes: By inputting the load information into the fault prediction model, fault prediction information for the target vehicle in the next scenario can be obtained. Based on fault prediction information, determine the fault preprocessing strategies for multiple scenario services. During the operation of multiple scenario services, the memory of the target vehicle is reclaimed based on the fault preprocessing strategy.

[0077] In practical applications, refer to Figure 4 As shown, a monitoring module can be configured in the vehicle operating system to monitor VCU load rate, communication load, and task queue status. When the load exceeds a specific threshold, an alarm is triggered and a compression strategy is initiated. For example, a tiered alarm is executed, and a series of intelligent compression strategies are automatically triggered to ensure that the VCU is always in a stable and efficient working state, guaranteeing the safety and real-time performance of the vehicle's core control functions.

[0078] The in-vehicle operating system may also include a fault handling module that predicts vehicle faults based on load information. The fault prediction model can identify potential faults by training on historical data and output fault prediction information. Fault types may include memory leaks, stack overflows, service crashes, etc. When the system detects an abnormal increase in load at a certain moment, it automatically calls the fault prediction model for analysis. For example, when the vehicle navigation system and entertainment system are running simultaneously, if the VCU's load rate exceeds a threshold, the system will input the load information into the fault prediction model for prediction.

[0079] Probability thresholds are used to determine whether to initiate a fault isolation process. These thresholds can be configured for different vehicle models and application scenarios. In real-world scenarios, when the system predicts a high-risk fault, isolation can be implemented immediately based on the fault type. For example, if the fault probability is 80% (high) and the fault type is memory leak, garbage collection or restarting related services can be triggered immediately; if the fault type is stack overflow, the number of concurrent threads can be limited or the execution of non-critical tasks can be suspended. Fault isolation prevents further spread of faults, ensuring the safety and stability of the system's continued operation.

[0080] When the predicted probability of a fault does not reach the preset high-risk threshold, the system will not immediately perform isolation operations, but will instead generate a fault warning message. The fault warning message includes the fault type, the predicted probability, and suggested maintenance strategies, such as checking for memory fragmentation issues during the next maintenance or optimizing the resource usage of the navigation module. The fault warning message can also be recorded in the system log for subsequent data analysis and model iteration optimization. The fault warning message can be conveyed to the user through in-vehicle screen display, voice announcements, and application push notifications. For example, when the system predicts that a specific module may experience a slight performance degradation in the next few hours, the system can display a prompt on the in-vehicle interface: "Slow performance detected in the navigation module; it is recommended to avoid multitasking to ensure a smooth experience."

[0081] As can be seen from the above, by inputting load information into the fault prediction model, the fault prediction information of the target vehicle in the next scenario can be obtained. Based on the prediction results, corresponding isolation or early warning measures can be taken during the service operation in multiple scenarios. This can effectively identify potential fault risks, thereby enabling timely intervention, improving the stability and reliability of the vehicle system, extending the system life cycle, and reducing maintenance costs.

[0082] In a feasible scenario, refer to Figure 5 As shown, the vehicle control method of this application can be implemented in the following ways: Data Acquisition: Collect user operation history and real-time Global Positioning System (GPS) data.

[0083] Behavioral analytics: AI models analyze user behavior patterns and their correlation with application usage.

[0084] Application prediction: Predicting the applications a user will use and their priority.

[0085] Preload execution: Load the predicted application into the memory protection area.

[0086] Fast response: User operations are directly invoked from memory, with a response time of less than 50ms.

[0087] Performance monitoring: Continuously monitor system performance and optimize predictive models.

[0088] Based on the same inventive concept as described above, Figure 6 This is a schematic diagram of a control device provided in an embodiment of the present invention. The device 600 includes: The acquisition unit 601 is used to acquire the target vehicle's operating information and load information in the current scenario; Processing unit 602 is used to determine the service information of the target vehicle in the next scenario based on the operation information; the service information includes multiple scenario services corresponding to the next scenario; The processing unit 602 is also used to control resource scheduling of multiple scenario services based on load information.

[0089] In some embodiments of this application, the processing unit 602 is used to input user behavior information into a behavior time series model to obtain behavior prediction information for the next scenario; Based on behavior prediction information and vehicle status information, multiple scenario services and the service priority of each scenario service are determined; the service information also includes service priority.

[0090] In some embodiments of this application, the acquisition unit 601 is used to acquire historical user behavior information of the target vehicle; Processing unit 602 is used to generate a user behavior sequence of the target vehicle based on historical user behavior information; Feature extraction is performed on the user behavior sequence to obtain the user behavior feature vector of the target vehicle; A behavioral time series model is obtained based on user behavior feature vectors.

[0091] In some embodiments of this application, the processing unit 602 is used to determine resource information of multiple scenario services; Based on resource and load information, determine the preloading strategy for services in multiple scenarios; Based on the preloading strategy, multiple scenario services are preloaded into the target vehicle's memory.

[0092] In some embodiments of this application, the processing unit 602 is used to determine the trigger parameters of the first process and the quota parameters of the control group based on load information; the first process includes a low memory killer daemon process; Determine the load reduction strategy for multiple service scenarios based on trigger parameters and quota parameters; The load reduction strategy aims to lower the load rate of the target vehicle to a preset threshold.

[0093] In some embodiments of this application, the acquisition unit 601 is used to acquire historical file access information of the target vehicle; Processing unit 602 is used to extract features from historical file access information to obtain file usage pattern features of the target vehicle; A file prediction model is derived based on file usage pattern features; Based on the file prediction model and load information, determine the file cleanup strategies corresponding to multiple service scenarios; Clean up the target vehicle's file memory based on file cleanup strategies.

[0094] In some embodiments of this application, the processing unit 602 is used to input load information into the fault prediction model to obtain fault prediction information of the target vehicle in the next scenario; and to determine fault preprocessing strategies corresponding to multiple scenario services based on the fault prediction information. During the operation of multiple scenario services, the memory of the target vehicle is reclaimed based on the fault preprocessing strategy.

[0095] Based on the foregoing embodiments, embodiments of this application provide an electronic device. Figure 7 This is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present invention. The electronic device 700 includes at least one processor 701 and a memory 702. Optionally, the electronic device 700 may further include at least one communication interface 703. The various components in the electronic device 700 are coupled together through a bus system 704. It can be understood that the bus system 704 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 704 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 7 The general designated all buses as Bus System 704.

[0096] Based on the hardware implementation of the above program modules, the communication interface 703 is able to interact with other communication devices. The processor 701 is connected to the communication interface 703 to enable information exchange with other communication devices and to execute the methods provided by one or more of the above-mentioned technical solutions when running a computer program; Memory 702, computer programs are stored in memory 702.

[0097] Specifically, processor 701 is used to acquire the target vehicle's operating information and load information in the current scenario; Based on operational information, determine the service information of the target vehicle in the next scenario; the service information includes multiple scenario services corresponding to the next scenario. Resource scheduling for multiple scenario services is controlled based on load information.

[0098] In some embodiments of this application, processor 701 is used to input user behavior information into a behavior time series model to obtain behavior prediction information for the next scene; Based on behavior prediction information and vehicle status information, multiple scenario services and the service priority of each scenario service are determined; the service information also includes service priority.

[0099] In some embodiments of this application, processor 701 is used to acquire historical user behavior information of the target vehicle; Generate user behavior sequences for the target vehicle based on historical user behavior information; Feature extraction is performed on the user behavior sequence to obtain the user behavior feature vector of the target vehicle; A behavioral time series model is obtained based on user behavior feature vectors.

[0100] In some embodiments of this application, processor 701 is used to determine resource information for multiple scenario services; Based on resource and load information, determine the preloading strategy for services in multiple scenarios; Based on the preloading strategy, multiple scenario services are preloaded into the target vehicle's memory.

[0101] In some embodiments of this application, processor 701 is used to determine the trigger parameters of a first process and the quota parameters of a control group based on load information; the first process includes a low memory killer daemon. Determine the load reduction strategy for multiple service scenarios based on trigger parameters and quota parameters; The load reduction strategy aims to lower the load rate of the target vehicle to a preset threshold.

[0102] In some embodiments of this application, processor 701 is used to obtain historical file access information of the target vehicle; Feature extraction is performed on historical file access information to obtain the file usage pattern features of the target vehicle; A file prediction model is derived based on file usage pattern features; Based on the file prediction model and load information, determine the file cleanup strategies corresponding to multiple service scenarios; Clean up the target vehicle's file memory based on file cleanup strategies.

[0103] In some embodiments of this application, processor 701 is used to input load information into a fault prediction model to obtain fault prediction information of the target vehicle in the next scenario. Based on fault prediction information, determine the fault preprocessing strategies for multiple scenario services. During the operation of multiple scenario services, the memory of the target vehicle is reclaimed based on the fault preprocessing strategy.

[0104] It is understood that memory 702 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Sync Link Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 702 described in this embodiment of the invention is intended to include, but is not limited to, these and any other suitable types of memory.

[0105] The memory 702 in this embodiment of the invention is used to store various types of data to support the operation of the electronic device 700. Examples of such data include any computer program for operation on the electronic device 700, and programs implementing the methods of this embodiment of the invention may be included in the memory 702.

[0106] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 701. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of the present invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory. The processor reads information from the memory and, in conjunction with its hardware, completes the steps of the aforementioned method.

[0107] In an exemplary embodiment, the electronic device 700 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the methods described above.

[0108] This application provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the vehicle control method described above in this application.

[0109] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the control method provided in this application. For example, ... Figure 1 The vehicle control method shown.

[0110] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0111] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0112] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0113] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0114] In summary, this application embodiment obtains the target vehicle's operating information and load information in the current scenario; determines the target vehicle's service information in the next scenario based on the operating information; the service information includes multiple scenario services corresponding to the next scenario; determines the resource strategy for the next scenario based on the load information; and the resource strategy is used to control the execution of multiple scenario services. This realizes the dynamic adjustment of the vehicle's resource strategy according to different scenarios to respond to the scenario services corresponding to different scenarios, thus solving the problem that the resource allocation method in related technologies cannot dynamically respond to different scenarios.

[0115] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A vehicle control method, characterized in that, The method includes: Obtain the target vehicle's operating and load information in the current scenario; Based on the operational information, the service information of the target vehicle in the next scenario is determined; the service information includes multiple scenario services corresponding to the next scenario. Based on the load information, control the resource scheduling of multiple scenario services.

2. The method according to claim 1, characterized in that, The operational information includes user behavior information and vehicle status information; determining the service information of the target vehicle in the next scenario based on the operational information includes: The user behavior information is input into the behavior time series model to obtain the behavior prediction information for the next scenario; Based on the behavior prediction information and the vehicle status information, multiple scenario services and the service priority of each scenario service are determined; the service information also includes the service priority.

3. The method according to claim 2, characterized in that, The method further includes: Obtain historical user behavior information for the target vehicle; Generate a user behavior sequence for the target vehicle based on the historical user behavior information; Feature extraction is performed on the user behavior sequence to obtain the user behavior feature vector of the target vehicle; The behavior time series model is obtained based on the user behavior feature vector.

4. The method according to claim 1, characterized in that, The method of controlling resource scheduling of multiple scenario services based on the load information includes: Determine resource information for multiple scenario services; determine preloading strategies corresponding to multiple scenario services based on the resource information and the load information; Based on the preloading strategy, multiple scenario services are preloaded into the memory of the target vehicle.

5. The method according to claim 1, characterized in that, The method of controlling resource scheduling of multiple scenario services based on the load information includes: The trigger parameters of the first process and the quota parameters of the control group are determined based on the load information; the first process includes a low memory killer daemon. Based on the triggering parameters and the quota parameters, a load reduction strategy for multiple scenario services is determined. The load reduction strategy reduces the load rate of the target vehicle to a preset threshold.

6. The method according to claim 2, characterized in that, The method of controlling resource scheduling of multiple scenario services based on the load information includes: Obtain the historical file access information of the target vehicle; Feature extraction is performed on the historical file access information to obtain the file usage pattern features of the target vehicle; A file prediction model is obtained based on the file usage pattern characteristics; Based on the file prediction model and the load information, file cleanup strategies are determined for multiple scenario services; Clean up the file memory of the target vehicle based on the file cleanup strategy.

7. The method according to claim 1, characterized in that, The method of controlling resource scheduling of multiple scenario services based on the load information includes: The load information is input into the fault prediction model to obtain the fault prediction information of the target vehicle in the next scenario; Based on the fault prediction information, fault preprocessing strategies are determined for multiple scenario services. During the operation of multiple scenario services, the memory of the target vehicle is reclaimed based on the fault preprocessing strategy.

8. A vehicle control device, characterized in that, The device includes: The acquisition unit is used to acquire the target vehicle's operating information and load information in the current scenario; The processing unit is configured to determine the service information of the target vehicle in the next scenario based on the operational information; the service information includes multiple scenario services corresponding to the next scenario; The processing unit is also used to control the resource scheduling of multiple scenario services based on the load information.

9. A 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 7.

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 7.

Images