Vehicle machine control method and vehicle

Abstract

The invention provides a vehicle machine control method and a vehicle, and relates to the technical field of vehicle machine systems. The method comprises the following steps: acquiring running data of a target application program and use data of a user application program; the target application program is a current running application program of the in-vehicle infotainment device; determining a first resource scheduling strategy based on the operation data of the target application program and the use data of the user application program; and determining a resource allocation parameter of each target application program based on the first resource scheduling strategy. According to the control method, the operation data of the target application program and the application program serve as the two-dimensional input information for generating the resource scheduling strategy to obtain the first resource scheduling strategy, then resource allocation parameter adjustment is conducted, and flexible and effective vehicle resource allocation is achieved.

Description

Technical Field

[0001] This application relates to the field of vehicle infotainment system technology, and in particular to a vehicle infotainment control method and a vehicle. Background Technology

[0002] As in-vehicle infotainment systems (V2X) become increasingly feature-rich, power consumption management during operation has become a critical factor affecting user experience and vehicle range. Currently, mainstream solutions mainly employ fixed rule strategies, such as globally reducing brightness when battery is low, or scenario-based static strategies, such as disabling video applications in navigation mode.

[0003] Existing power consumption control schemes lack dynamic adaptability and cannot meet the complex needs of in-vehicle infotainment systems with numerous applications and rapidly changing scenarios. Furthermore, their poor policy adaptability and overly coarse resource arbitration fail to guarantee a good user experience. In addition, the inflexible adjustment logic of in-vehicle applications during power consumption control can easily cause users to lose control over their applications, disrupting the continuity of user operations and further degrading the user experience. Summary of the Invention

[0004] In view of the above problems, this application provides a vehicle control method and vehicle to overcome the problem that the power consumption control of existing vehicle systems is not flexible enough, making it difficult to meet the user's scenario-based needs and ensure the user experience.

[0005] On one hand, embodiments of this application provide a vehicle infotainment system control method, the method comprising: Obtain the running data of the target application and the user application usage data; the target application is the application currently running on the vehicle system. Based on the target application's runtime data and the user application's usage data, a first resource scheduling strategy is determined; Based on the first resource scheduling strategy, resource allocation parameters for each target application are determined.

[0006] When the vehicle meets the in-vehicle infotainment system's energy-saving adjustment conditions, in-vehicle control is executed. The target application's runtime data and the application itself serve as dual-dimensional input information for generating a resource scheduling strategy. This results in a dynamic first resource scheduling strategy, related to power consumption and user habits, used for adaptively adjusting resource allocation. This first resource scheduling strategy adjusts the in-vehicle system's internal resource allocation parameters, integrating power-consuming runtime data and user-experience-related habits. It fully considers the conflicting needs of vehicle range and user experience, achieving effective resource allocation. This overcomes the technical challenges of existing in-vehicle infotainment systems' inflexible power consumption control, difficulty in meeting user scenario-based needs, and in ensuring a good user experience.

[0007] In one implementation of this application, a first resource scheduling strategy is determined based on the runtime data of the target application and the usage data of the user application, specifically including: Based on the running data of the target application, the resource usage information of the target application is determined in order to obtain the predicted power consumption vector within a preset time period in the future; Based on the user application usage data, a user behavior vector is obtained within a preset future time period; The vehicle's current battery level, the predicted power consumption vector, and the user behavior vector are input into a pre-trained strategy generation model to determine the first resource scheduling strategy; wherein the first resource scheduling strategy includes at least the resource usage limit for each target application within a preset time period in the future.

[0008] By introducing the aforementioned dual-dimensional input strategy of predictive power consumption vector and user behavior vector to generate a model, the resource limit can be dynamically fine-tuned according to battery level, power consumption, and user intent. This ensures that high-frequency applications conform to user habits while controlling the vehicle system and extending battery life, providing a smooth user experience.

[0009] In one implementation of this application, the resource occupancy information includes at least one of: CPU utilization, GPU call frequency, and network traffic; the step of determining the resource occupancy information of the target application based on its runtime data to obtain a predicted power consumption vector over a future preset time period specifically includes: The resource usage information is input into a preset multi-task learning model to determine the predicted power consumption vector for each target application within a preset time period based on the model output.

[0010] By leveraging a multi-task learning model to process and analyze resource usage information, the accuracy of the predicted power consumption vector is ensured. Furthermore, multi-task learning outputs the predicted power consumption for each application simultaneously, reducing the computational overhead of processing and analyzing each application separately, while also ensuring the portability efficiency of this vehicle control method across different vehicle models.

[0011] In one implementation of this application, before obtaining user application usage data, the method further includes: The historical operation data of the installed applications on the vehicle is serialized to obtain the corresponding historical operation behavior sequence, and the historical operation behavior sequence is used as the user application usage data; wherein, the historical operation behavior sequence includes at least timestamp, geographical location and application launch event; Based on the user application usage data, a user behavior vector is obtained within a preset future time period, specifically including: Based on the user application usage data and the vehicle's current battery level, determine the application launch probability distribution of each application within a preset future time period; Based on the application launch probability distribution, construct the user behavior vector for a future preset time period.

[0012] By serializing the timestamps, geographical locations, and application launch events related to application usage from users' historical vehicle usage data, the launch probability is predicted. The resulting historical running behavior sequence is sorted to better match real driving scenarios, improving the accuracy of the user behavior vectors constructed subsequently.

[0013] In one implementation of this application, after determining the resource allocation parameters for each target application based on the first resource scheduling strategy, the method further includes: According to the resource allocation parameters of each target application, the target applications are added to the first application sequence in descending order of resource allocation amount; Obtain the current vehicle infotainment system usage association conditions, and generate a second application sequence corresponding to the first application sequence based on the vehicle infotainment system usage association conditions; wherein, the first application sequence and the second application sequence include the same set of applications; Based on the application order in the second application sequence, the application order in the first application sequence is corrected, so that the first resource scheduling strategy is adjusted and the resource allocation parameters of each target application are adjusted based on the corrected third application sequence.

[0014] This application first sorts each target application according to the resource allocation amount in the resource allocation parameters, and then sorts them again according to the vehicle system usage association conditions. By integrating the vehicle system usage association conditions for application sorting, the conflict between pure power consumption sorting that depends on resource allocation amount and the actual usage scenario of the vehicle system can be resolved, and the scenario adaptability of application resource allocation parameters can be improved.

[0015] In one implementation of this application, the vehicle-mounted system usage association conditions include at least environmental parameters, inter-application resource dependencies, and the number of occupants; the inter-application resource dependencies are determined through a preset application association graph; the construction of the preset application association graph specifically includes: Using the target application as nodes and resource dependencies as directed edges, a preset application association graph is constructed; wherein, the resource dependencies include at least resource sharing relationships and resource competition relationships; the weight values ​​of the directed edges represent the dependency levels of two nodes on resources of the same application.

[0016] For resource dependencies between applications, a directed weighted graph is used to quantify the relationship of shared / competitive resources between applications, so that the weights can be directly involved in the sorting during subsequent sequence generation, thereby improving the efficiency of sequence generation.

[0017] In one implementation of this application, generating a second application sequence corresponding to the first application sequence based on the vehicle system usage association conditions specifically includes: Based on the vehicle infotainment system usage association conditions and the preset application weight list, a scene weight matrix corresponding to the application set is determined. Based on the scene weight matrix, the applications in the application set are prioritized and sorted to generate the second application sequence.

[0018] By using a scenario weight matrix, environmental parameters, resource dependencies, and the number of occupants are quantified. This makes the rules for reordering the first application sequence transparent and provides a basis for obtaining the second application sequence associated with the scenario.

[0019] In one implementation of this application, the method further includes: Based on the first resource scheduling strategy, one or more applications to be scheduled are determined. Based on the vehicle operation information, determine whether each application to be scheduled meets its corresponding state maintenance condition; When the application to be scheduled meets its corresponding state preservation condition, the current resource allocation parameters corresponding to the application to be scheduled are maintained.

[0020] By setting state retention thresholds, the system prevents applications from being mistakenly downgraded during certain critical driving phases, thereby improving driving safety and the user experience of the vehicle's infotainment system.

[0021] In one implementation of this application, the method further includes: When the application to be scheduled is a preset multimedia application and the corresponding resource allocation parameters correspond to resource degradation, the resource allocation parameters of the preset multimedia application are degraded according to a preset multi-stage degradation strategy.

[0022] By downgrading the resources of preset multimedia applications in multiple stages, a smooth and imperceptible resource downgrade is achieved, resulting in minimal visual discrepancy for users and improving their experience of using the preset multimedia applications in the vehicle system.

[0023] Secondly, embodiments of this application also provide a vehicle, the vehicle comprising: a memory for storing executable program code; and a processor for calling and running the executable program code from the memory, causing the vehicle to perform: Obtain the running data of the target application and the user application usage data; the target application is the application currently running on the vehicle system. Based on the target application's runtime data and the user application's usage data, a first resource scheduling strategy is determined; Based on the first resource scheduling strategy, resource allocation parameters for each target application are determined. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic flowchart of a vehicle control method according to an embodiment of this application; Figure 2 This is another schematic flowchart of a vehicle control method according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a vehicle according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a vehicle control device according to an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] Current vehicle infotainment system control solutions lack dynamic adaptability and cannot meet the complex needs of numerous applications and rapidly changing scenarios. Furthermore, their poor policy adaptability and overly rudimentary resource arbitration methods fail to guarantee a positive user experience. In addition, the inflexible application adjustment logic during power consumption control can cause users to lose control over applications, disrupting continuous operation and further degrading the user experience.

[0027] Based on this, this application provides a vehicle control method and a vehicle to overcome the problems of insufficient power consumption control in existing vehicle systems, which makes it difficult to meet user scenario-based needs and ensure user experience.

[0028] The various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0029] This application provides a vehicle infotainment system control method, such as... Figure 1 As shown, the method may include steps S101-S103: S101, Obtain the running data of the target application and the user application usage data; the target application is the application currently running on the vehicle's infotainment system; S102, Based on the target application's runtime data and the user application's usage data, determine the first resource scheduling strategy; S103, based on the first resource scheduling strategy, determine the resource allocation parameters for each target application.

[0030] Prior to performing step S101, this application further includes: obtaining vehicle operation information and determining whether the vehicle's energy-saving adjustment conditions are met based on the vehicle operation information.

[0031] It should be noted that the executing entity of the vehicle control method of this application can be the vehicle's control module, such as the vehicle computer, or the central processing unit (CPU) of the in-vehicle infotainment system, the vehicle controller, etc., or other computing computers or terminal devices electrically connected to the vehicle. This application does not make any specific limitations in this regard.

[0032] Vehicle operation information can include the vehicle's current remaining battery power (State of Charge, SOC), or other data such as remaining navigation range, vehicle speed, gear position, etc., which can reflect the vehicle's energy consumption status. The specific types of data included in the vehicle operation information can be set by the developers based on expert experience according to the actual usage scenario of the vehicle, and no specific restrictions are made here.

[0033] In some embodiments, determining whether the vehicle's energy-saving adjustment conditions are met based on vehicle operating information includes: Analyze the vehicle operation information to obtain the current driving scenario of the vehicle, and determine whether the energy consumption status of the vehicle operation meets the conditions for energy-saving adjustment. If it meets the conditions, proceed with steps S101-S103.

[0034] For example, taking vehicle infotainment system operating information including State of Charge (SOC) and remaining navigation range as an example, if the vehicle driving scenario is identified as a highway driving scenario, scenario identification can be based on either the vehicle's location or a comprehensive judgment considering factors such as vehicle speed; no specific limitation is made here. When the vehicle is running at a certain moment, if the SOC is less than a first SOC threshold and the remaining navigation range is greater than a first navigation remaining range threshold, then the vehicle infotainment system's energy-saving adjustment conditions are considered met. Similarly, if the vehicle driving scenario is identified as an idling rest scenario, in which case the SOC is less than a second SOC threshold, the vehicle infotainment system's energy-saving adjustment conditions are also considered met. Here, the first SOC threshold is greater than the second SOC threshold. The aforementioned first SOC threshold, second SOC threshold, and first navigation remaining range threshold can be set based on expert experience; no specific limitation is made here.

[0035] Users can also set energy-saving adjustment conditions for the vehicle system according to their actual vehicle usage. During vehicle operation, the system continuously acquires vehicle operation information and judges whether the energy-saving adjustment conditions are met, thereby flexibly controlling the vehicle system.

[0036] By following the steps above, it is possible to flexibly determine whether the vehicle's energy-saving adjustment conditions are met during vehicle operation, so as to execute vehicle control and avoid excessive involvement in the vehicle control process when the user does not need to perform vehicle control, which would affect the user's operating experience. Furthermore, it is possible to dynamically execute vehicle control based on the actual vehicle operation, further improving the flexibility of vehicle control.

[0037] Once this application determines that the vehicle currently meets the conditions for energy-saving adjustment of the vehicle system, it will proceed through the following steps to enter the vehicle system control and schedule the application running on the vehicle system.

[0038] S101, Obtain the running data of the target application and the usage data of the user application. The target application is the application currently running on the vehicle's infotainment system.

[0039] The user application usage data refers to historical data representing users' usage habits of in-vehicle infotainment applications. This application uses the application currently running on the in-vehicle infotainment system during vehicle operation as the target application. This target application can be in the foreground or background of the infotainment system and consumes system resources, including but not limited to navigation, multimedia, voice assistant, dashcam, OTA upgrade service, WeChat in-vehicle, and games. Subsequently, the running data of the target application and related user application usage data of the vehicle are collected. The running data of the target application may include CPU utilization, GPU call frequency, or network traffic. The specific type of running data can be set according to the characteristics of the application. For example, some applications do not require GPU usage, so their running data may only include CPU utilization and network traffic, while some applications may rely on GPU, so their running data may include GPU call frequency. The specific content of the target application's running data is not specifically limited here.

[0040] The user application usage data for the vehicle is obtained by analyzing the historical usage data of the applications installed on the vehicle's infotainment system. Specifically, before obtaining the user application usage data, the following steps are taken: The historical operation data of the vehicle's installed applications is serialized to obtain the corresponding historical operation behavior sequence, and the historical operation behavior sequence is used as user application usage data; wherein, the historical operation behavior sequence includes at least timestamps, geographical locations, and application launch events.

[0041] Specifically, historical operation data can be pre-stored in the vehicle's storage unit for memory storage. Historical operation data can be stored as a user operation log. It can be data related to application usage from historical driving records over a period of time or a preset number of times, such as historical operation data within one month, or historical operation data corresponding to 10 historical driving records. It can also include information such as application (App) usage frequency and duration. The specific selection rules for historical operation data can be set by the developer or user and are not specifically limited here. For example, the vehicle's behavior record for the past 7 days: Monday 18:30: Location: Work, Navigation opened; Tuesday 18:35: Location: Work, Navigation opened, Listening to music; Wednesday 18:28: Location: Work, Navigation opened. This data constitutes historical operation data.

[0042] Among them, a certain running behavior data in the historical running behavior sequence can be: (t_start, t_duration, loc_type, app_type), where t_start represents the timestamp corresponding to the application start time, t_duration represents the running time after start, loc_type represents the geographical location such as the user's commuting route, and app_type represents the specific application corresponding to the application start event.

[0043] The aforementioned historical operational behavior sequence may include application launch events where users initiate applications at various times and geographical locations. This historical operational behavior sequence can reflect vehicle users' habits of using vehicle applications and can therefore be used for analysis as user application usage data. Application launch events refer to events where users launch or exit applications.

[0044] It is understandable that the target application's operational data refers to real-time data from when the application is operated during vehicle operation, while the user application usage data refers to historical data from the vehicle's past usage, reflecting the user's personalized application operation habits. Combining these two dimensions of data from the above steps for vehicle system control leverages user operating habits, thereby rationally executing subsequent vehicle system controls and ensuring a positive user experience.

[0045] S102, Based on the target application's runtime data and the user application's usage data, determine the first resource scheduling strategy.

[0046] In this embodiment of the application, determining the first resource scheduling strategy based on the target application's runtime data and the user application's usage data specifically includes: Based on the target application's runtime data, resource usage information for the target application is determined to obtain a predicted power consumption vector over a preset future time period. Based on user application usage data, a user behavior vector over the preset future time period is obtained. The pre-acquired vehicle current battery level, predicted power consumption vector, and user behavior vector are input into a pre-trained strategy generation model to determine a first resource scheduling strategy. The first resource scheduling strategy includes at least the resource usage limit for each target application over the preset future time period.

[0047] In other words, this application analyzes the runtime data of the target application to obtain information on the resource consumption of the vehicle's infotainment system by the target application, and simultaneously predicts and constructs a predicted power consumption vector for the target application within a preset future timeframe. This predicted power consumption vector includes at least the target application's power consumption rating, the mapping relationship between resource consumption and actual power consumption, resource optimization dimensions, and a user experience impact score. The user experience impact score represents the predicted impact of limiting a certain vehicle's infotainment system resource (such as CPU, GPU, or network traffic) on the user experience. The power consumption rating can be obtained by pre-learning a set of weighted coefficients, including CPU weight, GPU weight, and network traffic weight, and then weighting and summing the resource consumption information of the target application to obtain a unique power consumption rating for the target application. The resource optimization dimension can be determined by setting a rule for determining the optimization dimension. This is done by comparing the resource consumption amounts in the resource consumption information. For example, if the target application's power consumption rating is high, and GPU resource consumption is high, then the target application's resolution will be optimized; if the target application's network traffic consumption is high, then network traffic will be limited. The specific determination of the resource optimization dimension can be set by the developer or user in the actual usage scenario, and is not specifically limited here. The user experience impact score can be determined by the rules for judging the degree of impact. It determines the score of the impact of resource optimization on the user experience. For example, if the resolution of the foreground navigation application is reduced while the user is viewing the navigation, it will be given a high user experience impact score. If the network is restricted for background music, it will be given a medium user experience impact score. If the resolution of the background video is reduced, it will have a small impact on the user experience. Resource optimization for video applications will be given a low user experience impact score, so as to be used for the generation of resource scheduling strategies.

[0048] To illustrate the determination of power consumption rating, consider the following example: Resource usage information is (CPU: 75%, GPU: 800MHz, Network: 50KB / s). In the weighted coefficient group, CPU weight is α=0.4, GPU weight is β=0.4, and network traffic weight is γ=0.2. Therefore, the power consumption rating is 0.4×75 + 0.4×80 + 0.2×5. When calculating the power consumption rating, the resource usage information can be normalized to ensure consistent dimensions before weighted summation using the weighted coefficient group to obtain the power consumption rating. The specific power consumption rating calculation method can be set by the developer or user in the actual use case and is not specifically limited here.

[0049] Furthermore, this application will combine user application usage data to predict user behavior vectors within a preset future time period, and these user behavior vectors may include the launch probability of each application within the preset future time period.

[0050] Furthermore, the vehicle's current battery level can be collected in real time via sensors, and combined with the predicted power consumption vector and user behavior vector to construct the model input. A first resource scheduling policy is then generated through a pre-trained policy generation model. This first resource scheduling policy includes at least the resource usage limit for each target application within a preset future timeframe. In addition to the resource usage limit, the policy also includes operations to be performed on each target application to control resource allocation parameters. A resource usage limit of 0 can be understood as shutting down the corresponding target application. The policy generation model can be a Deep Reinforcement Learning (DRL) model, capable of achieving relatively stable and continuous control. Alternatively, other machine learning models can also be used, without specific limitations. The training dataset for the DRL model can be a real-world driving dataset, such as a user's 1000-hour driving dataset. The specific training dataset can be set based on the actual scenario, without specific limitations.

[0051] The first resource scheduling strategy is illustrated with an example: when the vehicle's current battery level is 30%-50%, the GPU call frequency is limited to 80% of the baseline value; when the vehicle's current battery level is 15%-30%, the resolution is reduced to 720p and the refresh rate is 30fps (frames transmitted per second). The first resource scheduling strategy generates model output through the above strategy. The specific content of the generated scheduling strategy depends on the model training samples selected by the developer or user. This application does not specifically limit the content of the first resource scheduling strategy.

[0052] By introducing the above-mentioned dual-dimensional input strategy of predicting power consumption vector and user behavior vector to generate the model, the resource limit can be dynamically fine-tuned according to the power consumption, power consumption and user intent, so as to ensure smooth high-frequency applications while controlling the vehicle system and extending the driving range.

[0053] In some embodiments, the resource usage information includes at least one of: CPU utilization, GPU call frequency, and network traffic. Determining the resource usage information of the target application based on its runtime data to obtain a predicted power consumption vector over a preset future time period specifically includes: Resource usage information is input into a preset multi-task learning model to determine the predicted power consumption vectors for each target application within a preset time period based on the model output.

[0054] In other words, this application processes resource occupancy information through a pre-defined multi-task learning (MTL) model. By using the MTL model to process and analyze the resource occupancy information, the accuracy of the predicted power consumption vector is ensured. Moreover, multi-task learning outputs the predicted power consumption of each application at once, reducing the computational overhead of processing and analyzing each application separately, while also ensuring the efficiency of porting the vehicle control method to different vehicle models.

[0055] In some embodiments of this application, the above-mentioned method of obtaining user behavior vectors within a preset future time period based on user application usage data specifically includes: Based on user application usage data and the vehicle's current battery level, determine the application launch probability distribution for each application within a preset future time period. Then, construct a user behavior vector for the preset future time period based on the application launch probability distribution.

[0056] In other words, the user behavior vector contains at least the probability of launching various applications on the vehicle's infotainment system within a preset future timeframe. The user behavior vector can also be predicted using a lightweight temporal convolutional network (TCN). Taking the perceived historical behavior sequence as input, it predicts the applications the user will use at a specific time and location, and their expected usage duration. The preset future timeframe can be 15-30 minutes in the future, and can be set by the user or developer; no specific limitation is made here. For example, by analyzing the above scenario using TCN: Monday 18:30 - location: office - navigation opened - music played; Tuesday 18:35 - location: office - navigation opened; Wednesday 18:28 - location: office - navigation opened, the pattern of historical data can be identified, predicting that on Thursday after 18:00, there is an 85% probability of using navigation, a 10% probability of using music, and a 5% probability of doing something else.

[0057] This application serializes the timestamps, geographical locations, and application launch events related to application usage in the user's historical vehicle usage data to predict the launch probability. The resulting historical running behavior sequence is more closely aligned with real driving scenarios, improving the accuracy of the subsequently constructed user behavior vectors.

[0058] S103, based on the first resource scheduling strategy, determine the resource allocation parameters for each target application.

[0059] Among them, the resource allocation parameters are used to ensure that the actual power consumption of each target application in the next cycle does not exceed the resource occupation limit, thereby realizing vehicle control and reducing the energy consumption of applications that have a small impact on users under the corresponding vehicle power level.

[0060] For example, the resource allocation parameters of the target application A include: reducing the resolution to 720p, limiting the maximum CPU frequency, and freezing the network for 15 seconds.

[0061] The resource allocation parameters obtained through the above steps rely on the application's runtime data and user application usage data. However, in actual usage scenarios, vehicle applications are also affected by other factors. Combining these factors with real-world scenario considerations will further improve the flexibility of vehicle control and the user experience. Specifically, in this embodiment, after determining the resource allocation parameters for each target application based on the first resource scheduling strategy, the process further includes: Based on the resource allocation parameters of each target application, and in descending order of resource allocation, the target applications are added to the first application sequence. The current vehicle infotainment system usage association conditions are obtained, and a second application sequence corresponding to the first application sequence is generated based on these conditions. The first and second application sequences contain the same set of applications. The application order in the first application sequence is corrected based on the application order in the second application sequence. Based on the corrected third application sequence, the first resource scheduling strategy is adjusted, and the resource allocation parameters for each target application are adjusted.

[0062] In other words, this application first sorts each target application according to the resource allocation amount in the resource allocation parameters. The resource allocation amount may include the amount of CPU, GPU and / or network traffic resources that affect the power consumption of the application. Then, it sorts the applications again according to the vehicle system usage association conditions. By integrating the vehicle system usage association conditions (real-time scenario) to sort the applications, it can solve the conflict between pure power consumption sorting that depends on the resource allocation amount and the actual usage scenario of the vehicle system, and improve the scenario adaptability of the application resource allocation parameters.

[0063] More specifically, the aforementioned vehicle-mounted system usage association conditions include at least environmental parameters, inter-application resource dependencies, and the number of occupants. These conditions may also include other information, which is not specifically limited here. Environmental parameters may include light intensity, weather, etc. Inter-application resource dependencies are determined through a preset application association graph. The construction of the preset application association graph specifically includes: using the target application as nodes and resource dependencies as directed edges, constructing the preset application association graph. Resource dependencies include at least resource sharing relationships and resource competition relationships. The weight values ​​of directed edges represent the dependency levels of two nodes on the same application resource. Inter-application resource dependencies are used to clarify the dependency relationship between two applications on the same resource, thereby preventing non-critical applications from preempting resources during policy generation, which could affect the user's normal use of core applications. For example, in high-speed driving scenarios, it's important to avoid route delays caused by video applications preempting navigation CPU. Another example is when navigation and music apps share audio channels; in some scenarios, they compete for the right to use these audio channels. Therefore, the edge weights of the resource dependencies between the two applications are not fixed; rather, under certain conditions, the dependency levels between the two nodes can be multiple, corresponding to the scenario. No specific limitations are made here. The number of occupants can be determined by seat pressure sensors or by in-vehicle cameras; no specific limitations are made here.

[0064] For resource dependencies between applications, a directed weighted graph is used to quantify the relationship of shared / competitive resources between applications, so that the weights can be directly involved in the sorting during subsequent sequence generation, thereby improving the efficiency of sequence generation.

[0065] The resource allocation required for the first application sequence can be calculated as Total = CPU + GPU + Net, where Total represents the total resource allocation for the target application, CPU represents the allocated CPU resources, GPU represents the allocated GPU resources, and Net represents the allocated network traffic. The target applications are then sorted in descending order based on their resource allocation to obtain the first application sequence.

[0066] In some embodiments of this application, a second application sequence corresponding to the first application sequence is generated based on the vehicle-mounted system usage association conditions, specifically including: Based on the vehicle-mounted system's usage association conditions and a preset application weight list, a scene weight matrix corresponding to the application set is determined. According to the scene weight matrix, the applications in the application set are prioritized and sorted to generate a second application sequence.

[0067] The system includes a preset application weight list stored in a default weight table locally in the vehicle and / or updated online based on the user's historical driving data. This list contains application weights for each application corresponding to different environmental parameters, resource dependencies between applications, and different numbers of occupants. Application weight tuples are matched to each application based on the vehicle's infotainment system usage association conditions (an application may contain different application weights corresponding to environmental parameters, resource dependencies between applications, and the number of occupants). Then, based on the application weight tuples, a scenario weight matrix corresponding to the application set is constructed, with the vehicle's infotainment system usage association conditions as columns and the applications as rows. For each application, a weight value (representing application priority) can be obtained by weighted summing or averaging the application sub-weights in its corresponding application weight tuple. The specific calculation method for the weight value can be set by the user or developer based on expert experience and is not specifically limited here. Finally, the weight values ​​of each application are sorted in descending order to generate a second application sequence.

[0068] By using the aforementioned scenario weight matrix, environmental parameters, resource dependencies, and the number of occupants are quantified. This makes the rules for reordering the first application sequence transparent and provides a basis for obtaining the second application sequence associated with the scenario.

[0069] In this embodiment of the application, the above-mentioned modification of the application order in the first application sequence based on the application order in the second application sequence can be achieved by pre-setting a reordering rule for generating a third application sequence by combining the two application sequences, so as to realize an efficient reordering process.

[0070] For example, the first application sequence contains four applications a, b, c, and d, ordered as [a, b, c, d], with priority 1 for a, priority 2 for b, priority 3 for c, and priority 4 for d. The second application sequence is [b, c, a, d], where priority 1 for b, priority 2 for c, priority 3 for a, and priority 4 for d. This application averages the priorities of the same application in the two sequences, such as averaging priority 1.5 for b, 2.5 for c, 2 for a, and 8 for d. Therefore, the third application sequence can be [b, a, c, d].

[0071] It should be noted that the modification of the application order in the first application sequence in this application is not limited to the modification methods of the above examples. In another embodiment of this application, the modification can be carried out through the following embodiments, specifically including: Calculate the priority difference between the same application in the first application sequence and the second application sequence. When the absolute value of the priority difference is greater than a preset priority threshold, priority adjustment is performed. If the corresponding application has a higher priority in the second application sequence, its priority ranking position in the first application sequence will be adjusted upwards. If the corresponding application has a lower priority in the second application sequence, its priority ranking in the first application sequence will be adjusted downwards.

[0072] In other words, this application can identify the priorities of applications in two application sequences and calculate the priority difference between them. The absolute value of the priority difference is compared with a preset priority threshold, and the result is used to determine whether a priority correction condition is met. For example, if application a meets the priority correction condition, and its priority in the second application sequence is higher than its priority in the first application sequence, then its priority in the first application sequence is increased by a preset step size, for example, from 3 to 2. Similarly, if application b meets the priority correction condition, and its priority in the second application sequence is lower than its priority in the first application sequence, then its priority in the first application sequence is decreased by a preset step size, for example, from 1 to 3. The preset priority threshold and preset step size can be set based on the actual usage scenario and are not specifically limited here.

[0073] In one embodiment of this application, under certain vehicle operating conditions, the application resource allocation performed by the above method may not adapt to the changing user needs, affecting the user's in-vehicle infotainment experience. Based on this, this application also provides the following embodiments, including: Based on the first resource scheduling strategy, one or more applications to be scheduled are identified. Based on vehicle operation information, it is determined whether each application meets its corresponding state preservation condition. When an application meets its corresponding state preservation condition, the current resource allocation parameters for that application are maintained.

[0074] In other words, when adjusting resource allocation parameters based on the aforementioned first resource scheduling strategy or a modified first resource scheduling strategy, this application will determine the state preservation condition of the application to be scheduled, which is targeted by the resource allocation parameters. The state preservation condition can be pre-stored in the vehicle's storage unit, and its specific content can be set by the user or developer; no specific limitation is made here. When an application to be scheduled meets the state preservation condition, the resource allocation parameters of the application to be scheduled will not be adjusted further based on the first resource scheduling strategy; instead, the current resource allocation parameters of the application to be scheduled will be maintained.

[0075] For example, if the application to be scheduled is a navigation application, its state maintenance condition might be that the vehicle is at a road fork or traveling on a complex road section. In this case, the vehicle's operation information is used to determine whether the current vehicle meets the state maintenance condition. If the vehicle is currently traveling at a road fork and the navigation application is currently in the foreground or in the background, and if the navigation needs to adjust resource allocation parameters according to the first resource scheduling strategy, such as reducing resolution or limiting CPU frequency, then the resource allocation parameters will not be adjusted. Instead, the requirements of the state maintenance condition must be met first, and the current resource allocation parameters will be maintained until the state maintenance condition is no longer met.

[0076] To illustrate further, suppose the application to be scheduled is a video application. Its state preservation condition is that there are more than three occupants and the application is currently watching a movie. In this case, the first resource scheduling strategy might need to lower the resource allocation parameters for the video application. Since the current use of the video application meets the state preservation condition, the vehicle's infotainment system should first maintain the current resource allocation parameters for the video application, rather than directly adjusting them, thereby ensuring the user's infotainment system experience.

[0077] By setting state retention thresholds, the system prevents applications from being mistakenly downgraded during critical driving phases (such as cruise control or navigation), thereby improving driving safety and the user experience of the in-vehicle infotainment system.

[0078] Currently, most applications use overly coarse resource allocation parameters, often resulting in noticeable limitations that users perceive, negatively impacting the user experience of the in-vehicle infotainment system. To achieve seamless in-vehicle infotainment control for users, in another embodiment of this application, the following is also included: Based on the first resource scheduling strategy, the corresponding application to be scheduled is determined. If the application to be scheduled is a preset multimedia application and the corresponding resource allocation parameters correspond to resource degradation, the resource allocation parameters of the preset multimedia application are degraded according to the preset multi-stage degradation strategy.

[0079] The preset multimedia applications can be manually added by users, set by developers based on expert experience, or updated to preset multimedia applications based on their power consumption and resource usage. This application does not impose specific limitations on this. Preset multimedia applications can be generally understood as multimedia applications with high resource consumption, such as those whose CPU, CPU, and bandwidth usage exceeds resource consumption thresholds. Preset multimedia applications can include, but are not limited to, video applications, live streaming applications, and game applications.

[0080] In other words, if a user is using a video application, and the first resource scheduling strategy requires resource degradation of the video application (including reducing resolution, frame rate, and color depth), then the resource allocation parameters of the video application are degraded in multiple stages through a pre-stored multi-stage degradation strategy. Specifically, the first stage reduces the resolution to a certain level; after a certain time, such as 10 minutes, the second stage reduces the video frame rate; after another certain time, such as 15 minutes, the third stage reduces the video color depth, until the resource allocation parameters meet the requirements of the first resource scheduling strategy. Other types of pre-set multimedia applications can refer to the execution method of the pre-set multi-stage degradation strategy for video applications for degradation control, which will not be elaborated here.

[0081] By downgrading the resources of preset multimedia applications in multiple stages, a smooth and imperceptible resource downgrade is achieved, with minimal visual difference for users, thus improving the user experience of using in-vehicle multimedia applications.

[0082] In summary, when the vehicle meets the in-vehicle infotainment system's energy-saving adjustment conditions, vehicle control is executed. The target application's operational data and the application itself serve as dual-dimensional input information for generating a resource scheduling strategy. This results in a dynamic first resource scheduling strategy that is related to power consumption and user habits, used for adaptively adjusting resource allocation. By adjusting the in-vehicle system's internal resource allocation parameters through this first resource scheduling strategy, the system integrates power consumption-related operational data and user experience-related user habits, fully considering the conflicting needs of vehicle range and user experience, thus achieving effective resource allocation. This overcomes the technical problems of existing in-vehicle infotainment systems' inflexible power consumption control, difficulty in meeting user scenario-based needs, and inability to guarantee user experience.

[0083] In some embodiments of this application, determining the first resource scheduling strategy also includes referencing the current battery health.

[0084] Specifically, the acquired vehicle battery health, current vehicle charge level, predicted power consumption vector, and user behavior vector are input into a pre-trained strategy generation model to generate a first resource scheduling strategy under the current vehicle battery health. The first resource scheduling strategy generated without considering vehicle battery health is triggered at a base trigger charge level, such as when the vehicle's current charge level is 20%. If the current battery health is considered, the effective trigger charge level is calculated based on the base trigger charge level. For example, if the base trigger charge level is 20%, k = 0.5, and SOH = 0.8 (80%), where k is a preset step size coefficient used to adjust the influence of SOH, the effective trigger charge level is calculated using the formula: Effective trigger charge level = Base trigger charge level * (1 + k * (1 - SOH)). Therefore, the effective trigger charge level is 20% * (1 + 0.5 * (1 - 0.8)) = 20% * (1 + 0.1) = 22%. This means that the first resource scheduling strategy generated when the vehicle's current charge level is 20% will generate the same strategy when the vehicle's current charge level is 22%.

[0085] Furthermore, as the health of the vehicle's battery changes, a resource scheduling strategy that matches the degree of battery aging can be adaptively generated to ensure that aging batteries can still maintain a reasonable driving range.

[0086] Corresponding to the above scheme, Figure 2 A schematic diagram of the structure of a vehicle infotainment system corresponding to a vehicle infotainment control method is provided, such as... Figure 2 As shown, the vehicle infotainment system comprises a perception layer, a decision-making layer, and an execution layer. The perception layer senses real-time sensor data (including battery level and network status), user operation logs (App usage frequency and duration), and application behavior data (CPU / GPU utilization). The decision-making layer predicts user behavior vectors using a user habit prediction model (time-series prediction model), generates real-time application power consumption profiles (i.e., predicted power consumption vectors) using an application power consumption profile module (multi-task learning model), and generates dynamic resource scheduling strategies (the first resource scheduling strategy) by combining the predicted user behavior vectors and the application power consumption profiles using a policy generator (deep reinforcement learning DRL model). The execution layer controls the resolution adjuster, CPU frequency modulation module, and network bandwidth allocation to adjust resource allocation parameters. Furthermore, the vehicle infotainment system enables smooth degradation of applications to extend battery life.

[0087] Corresponding to the above scheme is a type of vehicle, such as Figure 3 As shown.

[0088] Figure 3 This application provides a schematic diagram of the structure of a vehicle, as shown in the embodiment of the present application. Figure 3As shown, the vehicle includes: a memory 301 for storing executable program code; and a processor 302 for calling and running the executable program code from the memory 301, causing the vehicle to perform: Obtain the runtime data of the target application and the usage data of the user application. The target application is the application currently running on the vehicle's infotainment system. Based on the runtime data of the target application and the usage data of the user application, determine a first resource scheduling strategy. Based on the first resource scheduling strategy, determine the resource allocation parameters for each target application.

[0089] Corresponding to the above solution is a non-volatile computer storage medium that stores computer-executable instructions, which, when executed by a computer, can achieve the following: Obtain the runtime data of the target application and the usage data of the user application. The target application is the application currently running on the vehicle's infotainment system. Based on the runtime data of the target application and the usage data of the user application, determine a first resource scheduling strategy. Based on the first resource scheduling strategy, determine the resource allocation parameters for each target application.

[0090] Corresponding to the above scheme, Figure 4 A schematic diagram of the structure of a vehicle control device, including: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: Obtain the runtime data of the target application and the corresponding user application usage data for the vehicle. The target application is the application currently running on the vehicle's infotainment system. Based on the runtime data of the target application and the user application usage data, determine a first resource scheduling strategy. Based on the first resource scheduling strategy, determine the resource allocation parameters for each target application.

[0091] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the embodiments for vehicles, equipment, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0092] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0093] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0094] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0095] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The aforementioned units can be implemented in hardware or software.

[0096] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0097] The beneficial effects of the above embodiments can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0098] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0099] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0100] In the description of this disclosure, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this disclosure.

[0101] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0102] The above are merely embodiments of this disclosure and are not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A head unit control method characterized by comprising: The method comprises: obtaining running data of target applications and user application usage data; the target applications are applications currently running by a vehicle machine; determining a first resource scheduling strategy based on the running data of the target applications and the user application usage data; determining resource allocation parameters of each of the target applications based on the first resource scheduling strategy.

2. The method according to claim 1, wherein Determining a first resource scheduling strategy based on the running data of the target applications and the user application usage data specifically comprises: determining resource occupation information of the target applications based on the running data of the target applications to obtain a predicted power consumption vector within a future preset time; obtaining a user behavior vector within a future preset time based on the user application usage data; inputting the current vehicle power, the predicted power consumption vector and the user behavior vector obtained in advance into a pre-trained strategy generation model to determine the first resource scheduling strategy; wherein the first resource scheduling strategy at least includes an upper limit of resource occupation of each of the target applications within a future preset time.

3. The method of claim 2, wherein the vehicle control method is characterized by: The resource occupation information includes at least one of central processor utilization, graphics processor call frequency and network traffic; determining the resource occupation information of the target applications based on the running data of the target applications to obtain a predicted power consumption vector within a future preset time specifically comprises: inputting the resource occupation information into a preset multi-task learning model to determine the corresponding predicted power consumption vector of each of the target applications within a future preset time according to the model output result.

4. The method of claim 2, wherein the vehicle control method is characterized by: Before obtaining the user application usage data, the method further comprises: serializing historical running data of installed applications of a vehicle to obtain corresponding historical running behavior sequences, and taking the historical running behavior sequences as the user application usage data; wherein the historical running behavior sequences at least include a timestamp, a geographic location and an application startup event; obtaining a user behavior vector within a future preset time based on the user application usage data specifically comprises: determining application startup probability distribution of each application within a future preset time based on the user application usage data and the current vehicle power; constructing the user behavior vector within a future preset time according to the application startup probability distribution of each application.

5. The method of claim 1, wherein the vehicle control method is characterized by: After determining the resource allocation parameters of each of the target applications based on the first resource scheduling strategy, the method further comprises: adding each of the target applications to a first application sequence in order of resource allocation amount from large to small according to the resource allocation parameters of each of the target applications; obtaining current vehicle machine use correlation conditions, and generating a second application sequence corresponding to the first application sequence according to the vehicle machine use correlation conditions; wherein the first application sequence and the second application sequence include the same set of applications; According to the application sequence in the second application sequence, the application sequence in the first application sequence is corrected to adjust the first resource scheduling strategy and adjust the resource allocation parameter of each target application based on the corrected third application sequence.

6. The method of claim 5, wherein the control command is a command for controlling a function of the vehicle. The vehicle machine use association condition at least includes environmental parameters, application inter-resource dependency relationship and passenger number; the application inter-resource dependency relationship is determined by a preset application association graph; the construction of the preset application association graph specifically includes: Taking the target application program as a node and the resource dependency relationship as a directed edge, the preset application association graph is constructed; wherein the resource dependency relationship at least includes resource sharing relationship and resource competition relationship; the weight value of the directed edge represents the dependency level of two nodes on the same application inter-resource.

7. The vehicle control method according to claim 5, characterized in that, The second application sequence corresponding to the first application sequence is generated according to the vehicle machine use association condition, specifically including: Based on the vehicle machine use association condition and the preset application weight list, a scene weight matrix corresponding to the application program set is determined; According to the scene weight matrix, the priority of each application program in the application program set is sorted to generate the second application sequence.

8. The method according to any one of claims 1-7, wherein, The method further includes: According to the first resource scheduling strategy, one or more to-be-scheduled applications are determined; Based on the vehicle operation information, it is judged whether each to-be-scheduled application meets its corresponding state maintenance condition; When the to-be-scheduled application meets its corresponding state maintenance condition, the current resource allocation parameter corresponding to the to-be-scheduled application is maintained.

9. A vehicle control method according to claim 8, characterized in that, The method further includes: In the case that the to-be-scheduled application is a preset multimedia application and the corresponding resource allocation parameter corresponds to resource degradation, the resource allocation parameter of the preset multimedia application is controlled according to a preset multi-stage degradation strategy.

10. A vehicle characterized by comprising: The vehicle includes a memory for storing executable program code; a processor for calling and running the executable program code from the memory, so that the vehicle executes the vehicle control method of any one of claims 1 to 9.

Images