Head unit resource dynamic allocation method based on application weight values, and vehicle and medium

Abstract

Disclosed in the present application are a head unit resource dynamic allocation method based on application weight values, and a vehicle and a medium. The method comprises the following steps: classifying applications in a domain controller (S1); assigning different dynamic weight values to each application in the domain controller (S2), wherein the dynamic weight values specifically comprise a category weight value, a response weight value and a scenario weight value; and on the basis of the dynamic weight values of each application and a target threshold value, dynamically allocating hardware resources of the domain controller (S3).

Description

A method for dynamic allocation of vehicle-mounted system resources based on application weights, vehicles and media

[0001]

[0002] Cross-reference to related applications

[0003] This application is based on and claims priority to Chinese Patent Application No. 202411388249.4, filed on October 8, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0004] This application relates to the field of domain controller resource allocation technology, and in particular to a method for dynamic allocation of vehicle system resources based on application weight values, as well as the vehicle and media. Background Technology

[0005] With the rapid development of the automotive industry, vehicle electronic and electrical systems have become extremely complex. A single vehicle can now contain as many as 70-80 electronic control units (ECUs), totaling approximately 100 million lines of code. Therefore, newly produced vehicles, especially new energy vehicles, will increasingly utilize cockpit domain controllers to achieve centralized control of vehicle functions.

[0006] A cockpit domain controller is an integrated controller used to manage and control multiple ECUs in a vehicle's electronic system. As the central hub of the entire vehicle's electronic system, it processes and distributes data to enable coordination and communication between the various ECUs, thereby achieving comprehensive control and optimization of the entire vehicle system.

[0007] As more and more ECUs are integrated into the cockpit domain controller, the application functions that the cockpit domain controller can perform are also increasing. However, the cockpit domain controller has limited system resources. When a large number of applications frequently call the system interface, it will consume a lot of system resources, which may cause the cockpit domain controller to run slowly or lag, affecting the vehicle's user experience. Therefore, how to effectively manage these resources, especially maintaining the stability and responsiveness of the cockpit domain controller under high load, is a significant technical challenge. Summary of the Invention

[0008] In view of this, embodiments of this application provide a method for dynamic allocation of vehicle system resources based on application weight values, as well as a vehicle and medium.

[0009] The first aspect of this application provides a method for dynamic allocation of vehicle system resources based on application weight values, including the following steps:

[0010] Classify the applications in the domain controller;

[0011] Each application in the domain controller is assigned a different dynamic weight value; the dynamic weight values ​​specifically include category weight values, response weight values, and scenario weight values.

[0012] The hardware resources of the domain controller are dynamically allocated based on the dynamic weight value and target redline value of each application.

[0013] In some examples, the categories applied in the domain controller specifically include vehicle powertrain applications, vehicle transmission applications, driver assistance applications, vehicle body electronics applications, and intelligent information applications;

[0014] The vehicle power system application is used to control the vehicle power system.

[0015] The vehicle transmission application is used to control the vehicle chassis transmission system.

[0016] The driver assistance applications are used to control the vehicle's autonomous driving operations.

[0017] The aforementioned vehicle body electronics applications are used to achieve integrated control of vehicle body electronic components;

[0018] The intelligent information applications are used to provide in-vehicle infotainment services.

[0019] In some examples, in the step of assigning different dynamic weight values ​​to each application in the domain controller:

[0020] The category weight value is determined based on the category to which the application belongs;

[0021] The response weight value is determined based on the last response time applied in the domain controller;

[0022] The scenario weight value is determined based on the vehicle's current working scenario and the application's category.

[0023] In some examples, each category in the domain controller has an application priority set for each application within that category; the category weight value of the application is determined based on the application priority of the application in the category to which the application belongs.

[0024] In some examples, assigning different dynamic weight values ​​to each application in the domain controller specifically includes the following steps:

[0025] Obtain the category of the target application and determine the category weight value of the target application;

[0026] Read the last response time of the target application to determine the response weight value of the target application;

[0027] Update the scenario weight value of the target application based on the current working scenario of the domain controller;

[0028] The dynamic weight value of the target application is obtained by summing the category weight value, response weight value, and scenario weight value.

[0029] In some examples, the target redline value includes the overall redline value for the domain controller and the individual redline value for the application;

[0030] The overall redline value of the domain controller is set according to the hardware resources of the domain controller;

[0031] The individual redline value for each application is determined based on the overall redline value of the domain controller and the dynamic weight value of each application.

[0032] In some examples, the hardware resources of the domain controller specifically include the domain controller's CPU resources, GPU resources, and NPU resources.

[0033] In some examples, the dynamic allocation of hardware resources for the domain controller specifically includes the following steps:

[0034] Allocate domain controller hardware resources, no less than the application's individual redline value, to each application currently running on the domain controller.

[0035] In some examples, when a domain controller's resource usage reaches the domain controller's overall redline value, the domain controller performs the following steps:

[0036] Obtain the dynamic weight values ​​of the applications currently running on the domain controller and sort them accordingly.

[0037] Turn off the application with the lowest dynamic weight value in the sorting;

[0038] Determine if the domain controller's resource usage is below the domain controller's overall red line value; if the domain controller's resource usage is still above the domain controller's overall red line value, return to the step of shutting down the application with the lowest dynamic weight value in the sorting, until the domain controller's resource usage is below the domain controller's overall red line value.

[0039] In some examples, when a target application's resource usage on the domain controller reaches the target application's individual redline value, the domain controller performs the following steps:

[0040] Monitor the resource usage of the target application within a preset time period;

[0041] When the resource usage of a target application exceeds its individual red line value within a preset time period, the dynamic weight value of the target application is reduced.

[0042] A second aspect of this application provides a vehicle equipped with a cockpit domain controller. The cockpit domain controller includes a processor, a memory, and computer program instructions stored in the memory and executable on the processor. When the processor executes the computer program instructions, it implements the aforementioned method for dynamic allocation of vehicle resources based on application weight values.

[0043] A third aspect of this application provides a computer-readable storage medium storing a program that is executed by a processor to implement the aforementioned method for dynamic allocation of vehicle resources based on application weight values.

[0044] This application also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium and execute the computer instructions, causing the computer device to perform the aforementioned method.

[0045] The embodiments of this application have the following beneficial effects: This application provides a method for dynamic allocation of vehicle-mounted resources based on application weight values, and an innovative design for resource allocation in a vehicle and media-containing cockpit domain controller system. When the domain controller resource usage is below the red line, no restrictions are placed on application usage; when the domain controller resource usage is too high, the resources of lower-ranked applications are released. The dynamic allocation of domain controller resources relies on the calculation of application weights, monitoring of domain controller resources, and management of application resource usage. It can perform targeted resource release based on different usage scenarios to meet user needs.

[0046] Additional aspects and advantages of this application will be set forth in the description which follows, in part from the description, or may be learned by practice of this application. Attached Figure Description

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

[0048] Figure 1 is a basic implementation flowchart of a vehicle-mounted system resource dynamic allocation method based on application weight values ​​according to this application.

[0049] Figure 2 is a schematic diagram of the domain controller application categories in this application.

[0050] Figure 3 is a schematic diagram of the composition of the dynamic weight values ​​in this application.

[0051] Figure 4 is a schematic diagram showing the relationship between the category weight value and application priority of this application.

[0052] Figure 5 is a schematic diagram of the process for obtaining the dynamic weight value in this application.

[0053] Figure 6 is a schematic diagram of the composition of the target red line values ​​in this application.

[0054] Figure 7 is a schematic diagram of the hardware resources of the vehicle cockpit domain controller in this application.

[0055] Figure 8 is a schematic diagram of the hardware resource release process of the vehicle cockpit domain controller in this application.

[0056] Figure 9 is a schematic diagram of the structure of an electronic device according to this application.

[0057] Figure 10 is a schematic diagram of a computer-readable storage medium structure according to this application. Embodiments of the present invention

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

[0059] The vehicle cockpit domain controller acts as the central hub of the vehicle's electronic systems, responsible for data processing, communication management, fault diagnosis and handling, and providing safety and intelligent functions to ensure the normal operation of the entire vehicle system and enhance the driving experience. The vehicle cockpit domain controller possesses a high level of intelligence and integration, capable of integrating different vehicle ECU modules, such as body ECUs, chassis ECUs, engine ECUs, multimedia ECUs, and driver assistance ECUs, enabling collaborative work and optimization among these ECUs. As more and more ECUs are integrated into the cockpit domain controller, the application functions it can perform are also increasing. However, the cockpit domain controller has limited system resources. When numerous applications frequently call system interfaces, it consumes significant system resources, potentially causing the cockpit domain controller to become sluggish or lag, impacting the vehicle's user experience. Therefore, effectively managing these resources, especially maintaining the stability and responsiveness of the cockpit domain controller under high load conditions, is a significant technical challenge.

[0060] To address the aforementioned issues, as shown in Figure 1, the first embodiment of this application provides a method for dynamic allocation of vehicle system resources based on application weight values, comprising the following steps:

[0061] S1. Categorize applications in the domain controller;

[0062] S2. Assign different dynamic weight values ​​to each application in the domain controller;

[0063] S3. Dynamically allocate the hardware resources of the domain controller based on the dynamic weight value and target redline value of each application.

[0064] The implementation process of each step in this application is described in detail below:

[0065] S1. Categorize applications in the domain controller.

[0066] In vehicle cockpit domain controllers, various applications are typically categorized based on region or function. Region-based categorization can be further divided into front vehicle body applications, left vehicle body applications, and right vehicle body applications, with each application classified according to the location where its control function is implemented.

[0067] In contrast, the embodiments of this application adopt a function-based division. Specifically, as shown in Figure 2, the applications mounted on the domain controller can be divided into vehicle power applications, vehicle transmission applications, driver assistance applications, body electronics applications, and intelligent information applications.

[0068] Vehicle powertrain applications: These applications control the vehicle's powertrain system, including transmission management, engine management, battery monitoring, and alternator regulation. They primarily calculate and distribute torque across various powertrain units (internal combustion engine, electric motor / generator, battery, transmission), achieve CO2 emission reduction through predictive driving strategies, and function as communication gateways to optimize and control the powertrain. They also include features such as intelligent electrical fault diagnosis, intelligent energy saving, and bus communication.

[0069] Vehicle transmission applications are primarily responsible for specific vehicle driving control, requiring unified control of systems including the transmission, running gear, steering, and braking systems. Vehicle transmission systems can be categorized into mechanical, hydraulic, and electronically controlled systems, each mainly composed of components such as clutches, gearboxes, universal joints, and drive axles. The running gear system includes the frame, suspension, wheels, and axles, connecting all parts of the vehicle and providing overall support. The steering system controls the vehicle's steering operation, such as hydraulic steering and steer-by-wire, ensuring the vehicle travels in a straight line or turns as intended by the driver. The braking system controls braking, deceleration, and parking, applying a degree of forced braking. Common applications within vehicle transmission systems include air spring control, suspension damper control, rear-wheel steering, electronic stabilizer bar functionality, and steering column position control.

[0070] Assisted driving applications: These applications possess capabilities such as multi-sensor fusion, localization, path planning, decision control, wireless communication, and high-speed communication. They typically require external connections to multiple cameras, millimeter-wave radars, lidar, and other devices, performing functions including image recognition and data processing. The functions integrated into assisted driving applications generally do not involve mechanical components and are integrated with vehicle electronics and intelligent information applications. Furthermore, they involve significant data transmission volumes, thus requiring high latency control.

[0071] Body Electronics Applications: Body electronics applications are based on the traditional BCM (Body Control Module) module, integrating body functions and components. Traditional BCM functions mainly include controlling interior / exterior lights, wipers, windows, doors, and electronic steering locks. Body electronics applications integrate the functions and components of various body nodes, further integrating functions such as air conditioning, damper control, tire pressure monitoring, PEPS, and gateways on top of the traditional BCM, centralizing all body-related functions in a single controller. Therefore, multiple functions, including basic drive systems, keys, lights, doors, and windows, can be analyzed and processed uniformly through body electronics applications, achieving centralized control of all body electronics components.

[0072] Intelligent information applications integrate the functions of traditional in-vehicle information systems (instrument panels) and in-vehicle entertainment systems (IVI), while also incorporating driver monitoring systems, 360-degree surround view systems, AR HUDs, dashcams, and air conditioning controllers. These applications primarily connect to system units such as fully digital instrument clusters, large-screen central control systems, in-vehicle infotainment systems, head-up displays, and streaming rearview mirrors. Through wired or wireless communication, they achieve the integration of components like head-up displays, instrument panels, and navigation, further optimizing intelligent driving, vehicle connectivity, and infotainment functions.

[0073] As can be seen from the above description, different types of applications in the domain controller implement different functions, but all applications will uniformly occupy the resources of the vehicle cockpit domain controller when running. Once a large number of applications simultaneously call the domain controller interface, it may cause a significant drain on system resources, resulting in lag in the vehicle cockpit domain controller. Therefore, this embodiment of the application achieves targeted resource release by assigning different dynamic weight values ​​to different applications, ensuring the smooth operation of the domain controller.

[0074] S2. Assign different dynamic weight values ​​to each application in the domain controller.

[0075] As shown in Figure 3, the dynamic weight values ​​in this embodiment of the application specifically include category weight values, response weight values, and scene weight values.

[0076] Category weight value: In this embodiment, the category weight value refers to the weight value determined according to the category to which the application belongs. Specifically, as shown in Figure 4, applications belonging to different categories will have different category weight values. Since the resource consumption of applications in different categories is different, for example, the resource consumption of applications that require data interaction will be greater than that of applications that do not require data interaction. Therefore, in this embodiment, an initial category weight value is set for each type of application, and the weight values ​​of the applications are further differentiated according to the application's activity time and the vehicle's current working scenario.

[0077] In some embodiments, since the priority of each application within the same category may differ based on manual settings or automatic settings by the domain controller—for example, the domain controller can set application priorities based on data transfer volume, assigning higher priorities to applications with larger data transfer volumes and lower priorities to applications that do not require data interaction or have smaller data transfer volumes—this application embodiment does not limit the method of setting application priorities. For applications within the same category, the category weight value will differ according to its own application priority, and applications outside the same category will not have the same application weight value. In some embodiments, application priority calculation and allocation can also be implemented through neural network models or other methods, making the domain controller system more intelligent.

[0078] Response weight value: In this embodiment, the response weight value is determined based on the application's last response time in the domain controller. The last response time of an application in the domain controller represents the time when the application last sent / processed / received a request. For applications whose last response time is recent, it indicates that the application's activity is relatively frequent. Stopping the activity of these applications may affect the normal operation of the entire vehicle system or the user experience. Therefore, these applications are usually assigned a higher response weight value to ensure the normal operation of the application. On the other hand, for applications whose last response time is distant, it can indicate that the application has been inactive for a long time. Stopping the activity of these applications will not have a significant impact on vehicle operation or user experience. Therefore, they are usually assigned a lower response weight value so that when the vehicle domain controller resources are scarce, the resource occupation of these inactive applications is released first, avoiding unnecessary resource waste.

[0079] Scene weight value: In this embodiment, the scene weight value refers to the weight value determined based on the vehicle's current working scene and the application's category. For a vehicle, its working scenes include driving scenes and parking scenes; where driving scene refers to the working state of the vehicle when it is driving on the road, and parking scene refers to the working state of the vehicle when it is parked in a parking lot or on the road. It should be noted that for different vehicles, the vehicle cockpit domain controller may set different working scenes. For example, for a motorhome, its working scenes also include camping scenes where the vehicle's living facilities are deployed; therefore, this embodiment does not limit the selection of vehicle working scenes.

[0080] The importance of different types of applications varies depending on the vehicle's operating scenario, resulting in different scenario weight values ​​for each. For example, in a driving scenario, the scenario weight values ​​for vehicle powertrain applications, vehicle transmission applications, and driver assistance applications will be higher than those for body electronics applications and intelligent information applications to ensure normal vehicle operation. Conversely, in a parking scenario, the scenario weight values ​​for body electronics applications and intelligent information applications will be higher than those for vehicle powertrain applications, vehicle transmission applications, and driver assistance applications to ensure the vehicle's perception of the external environment and the social and entertainment needs of users inside the cabin.

[0081] In this embodiment, since the last response time of the application and the working scenario of the vehicle are constantly changing, the response weight value and scenario weight value of each application are also constantly changing, thus forming the dynamic weight value of the application. In this embodiment, the vehicle cockpit domain controller will periodically (e.g., every 30 seconds) update the category weight value, response weight value, and scenario weight value of each application within the domain controller. As shown in Figure 5, when resource release is required, the following steps are performed to calculate the dynamic weight value of the application:

[0082] S201. Obtain the category of the target application and determine the category weight value of the target application;

[0083] S202. Read the last response time of the target application and determine the response weight value of the target application;

[0084] S203. Update the scenario weight value of the target application based on the current working scenario of the domain controller;

[0085] S204. Sum the category weight value, response weight value, and scenario weight value of the target application to obtain the dynamic weight value of the target application.

[0086] In this embodiment, after obtaining the weight values ​​of the target application, the dynamic weight value of the target application is obtained by adding the weight values ​​together. The weight values ​​are presented in the form of scores. For example, if the category weight value of the target application is 65, the response weight value is 30, and the scene weight value is 45, then the dynamic weight value of the target application is 65 + 30 + 45 = 140. In some embodiments, the score ranges of the category weight value, response weight value, and scene weight value may be different. For example, the score range of the category weight value is [1, 100] to represent the relative priority of different applications, the score range of the response weight value is [1, 50] to represent the activity level of different applications, and the score range of the scene weight value is [30, 70] to represent the importance of different applications in different scenarios.

[0087] S3. Dynamically allocate the hardware resources of the domain controller based on the dynamic weight value and target redline value of each application.

[0088] As shown in Figure 6, in this embodiment, the target redline value refers to the resource carrying capacity threshold of the vehicle cockpit domain controller. Since the computing resources of the vehicle cockpit domain controller are limited, when a large number of applications call the domain controller to compute resources at the same time, the domain controller may lag or crash, affecting the normal operation of the entire vehicle system and the user experience. Therefore, it is necessary to define a target redline value to constrain the resource consumption of applications.

[0089] In this embodiment, the target redline value includes the overall redline value of the domain controller and the individual redline value of each application. The overall redline value of the domain controller is set based on its hardware resources, while the individual redline value of each application is determined based on the overall redline value of the domain controller and the dynamic weight value of each application. As shown in Figure 7, the hardware resources of the domain controller in this embodiment include CPU (Central Processing Unit) resources, GPU (Graphics Processing Unit) resources, and NPU (Neural Processing Unit) resources. In some embodiments, the hardware resources also include ISP (Image Signal Processing), DPU (Data Processing Unit), VPU (Video Processing Unit), etc. The domain controller scans the system hardware parameters to determine the overall redline value of the domain controller.

[0090] Specifically, as shown in Figure 8, when the resource usage of a domain controller reaches the overall red line value for the domain controller, the domain controller performs the following steps:

[0091] S3a-1. Obtain the dynamic weight values ​​of the currently running applications on the domain controller and sort the currently running applications on the domain controller;

[0092] S3a-2. Turn off the application with the lowest dynamic weight value in the sorting;

[0093] S3a-3. Determine if the domain controller's resource usage is below the domain controller's overall red line value; if the domain controller's resource usage is still above the domain controller's overall red line value, return to the step of disabling the application with the lowest dynamic weight value in the sorting, until the domain controller's resource usage is below the domain controller's overall red line value.

[0094] In this embodiment, when the resource usage of the domain controller reaches the overall red line value, it indicates that the application's resource occupation on the domain controller has reached a preset threshold, and resource release is required. At this time, the domain controller will obtain the dynamic weight value of the currently running application and sort the applications according to the dynamic weight value, with applications with higher dynamic weight values ​​ranked first and applications with lower dynamic weight values ​​ranked last. The domain controller will then automatically close the application ranked last and release the resources of the application with the lowest dynamic weight value for use by other applications in the system. After the resource release is completed, the domain controller will monitor whether the current resource usage exceeds the overall red line value again. If the resource usage is lower than the overall red line value, the resource release operation is considered to be over; if the resource usage still exceeds the overall red line value, the application ranked last will continue to be closed to further release memory until the current resource usage is lower than the overall red line value.

[0095] Based on the overall redline value of the domain controller, this embodiment assigns an individual redline value to each application using a dynamic weight value. The individual redline value of an application indicates the system resources that the application is expected to consume. By default, each application currently running on the domain controller will be allocated domain controller hardware resources no less than its individual redline value. When the domain controller hardware resources currently consumed by an application reach its assigned individual redline value, the domain controller will perform the following steps:

[0096] S3b-1. Monitor the resource usage of the target application within a preset time period;

[0097] S3b-2. When the resource usage of the target application exceeds the individual red line value of the target application within a preset time period, reduce the dynamic weight value of the target application.

[0098] When an application's resource usage exceeds its individual redline value for an extended period, it indicates that the application is operating abnormally and requires close monitoring. Defining individual redline values ​​for applications helps the domain controller further pinpoint the abnormally operating applications and proactively reduce their weight. This makes it easier to shut down these abnormal applications when their domain controller resource usage exceeds the overall redline value, ensuring the smooth operation of the vehicle cockpit domain controller system within limited system resources.

[0099] Figure 9 is a schematic diagram of the vehicle structure proposed in the second embodiment of this application. Exemplarily, the vehicle includes a processor and a memory coupled to the processor. Specifically, the vehicle can be a private car, such as a sedan, SUV, MPV, or pickup truck. The vehicle can also be a commercial vehicle, such as a van, bus, small truck, or large trailer. The vehicle can be a gasoline vehicle or a new energy vehicle. When the vehicle is a new energy vehicle, it can be a hybrid vehicle or a pure electric vehicle. In this embodiment, the memory stores program instructions for implementing the vehicle-machine resource dynamic allocation method based on application weight values, the vehicle, and the medium in any of the above embodiments. The processor executes the program instructions stored in the memory to dynamically allocate vehicle cockpit domain controller resources. The processor may be an integrated circuit chip with signal processing capabilities. The processor can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor.

[0100] The methods described in the first embodiment of this application are all applicable to the vehicle embodiment. The functions implemented in the vehicle embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above methods.

[0101] Figure 10 is a schematic diagram of the structure of a computer-readable storage medium according to the third embodiment of this application. The computer-readable storage medium of the fourth embodiment of this application stores program instructions capable of implementing the above-described vehicle-machine resource dynamic allocation method based on application weight values, the vehicle, and the medium. These program instructions can be stored in the storage medium in the form of a software product, including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, or terminal devices such as computers, servers, mobile phones, and tablets.

[0102] The methods described in the first embodiment of this application are all applicable to the computer-readable storage medium embodiment. The specific functions implemented by the computer-readable storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above methods.

[0103] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to realize the vehicle-mounted system resource dynamic allocation method, vehicle, and medium based on application weight values ​​provided in the above embodiment.

[0104] Those skilled in the art will understand that modules in the devices of the embodiments of this application can be adaptively modified and placed in one or more devices different from those embodiments. Modules, units, or components in the embodiments of this application can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the corresponding claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the corresponding claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0105] 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.

[0106] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0107] Furthermore, the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. In particular, for embodiments such as apparatus and devices, since they are basically similar to the method embodiments, the relevant parts can be referred to the description of the method embodiments. The apparatus, devices, and other embodiments described above are merely illustrative, and the modules, units, etc., described as separate components may or may not be physically separate, that is, they may be located in one place or distributed in multiple places, such as nodes in a system network. Specifically, some or all of the modules and units can be selected according to actual needs to achieve the purpose of the above-described embodiment solutions. Those skilled in the art can understand and implement this without creative effort.

[0108] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

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

[0110] Furthermore, the terms "first," "second," etc., used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance, or implicitly specifying the number of technical features indicated in this embodiment. Therefore, features defined with terms such as "first" and "second" in the embodiments of this application can explicitly or implicitly indicate that the embodiment includes at least one of those features. In the description of this application, the word "multiple" means at least two or more, such as two, three, four, etc., unless otherwise explicitly and specifically defined in the embodiments.

[0111] In the embodiments of this application, 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 a process, method, article, or apparatus. Without further limitations, 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 that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0112] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application. Other embodiments of this application will readily conceive of by considering the specification and practicing this application. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed in this application. The specification and embodiments are considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

Claims

1. A method for dynamic allocation of vehicle system resources based on application weight values, comprising the following steps: Classify the applications in the domain controller; Each application in the domain controller is assigned a different dynamic weight value; The dynamic weight values ​​specifically include category weight values, response weight values, and scenario weight values; The hardware resources of the domain controller are dynamically allocated based on the dynamic weight value and target redline value of each application.

2. The method for dynamic allocation of vehicle system resources based on application weight values ​​according to claim 1, wherein, The applications in the domain controller are categorized as follows: vehicle power applications, vehicle transmission applications, driver assistance applications, vehicle body electronics applications, and intelligent information applications. The vehicle power system application is used to control the vehicle power system. The vehicle transmission application is used to control the vehicle chassis transmission system. The driver assistance applications are used to control the vehicle's autonomous driving operations. The aforementioned vehicle body electronics applications are used to achieve integrated control of vehicle body electronic components; The intelligent information applications are used to provide in-vehicle infotainment services.

3. The method for dynamic allocation of vehicle system resources based on application weight values ​​according to claim 1, wherein, In the step of assigning different dynamic weight values ​​to each application in the domain controller: The category weight value is determined based on the category to which the application belongs; The response weight value is determined based on the last response time applied in the domain controller; The scenario weight value is determined based on the vehicle's current working scenario and the application's category.

4. The method for dynamic allocation of vehicle system resources based on application weight values ​​according to claim 3, wherein, Each category in the domain controller has an application priority set for each application within that category; the category weight value of the application is determined based on the application priority of the application in the category to which the application belongs.

5. The method for dynamic allocation of vehicle system resources based on application weight values ​​according to claim 3, wherein, The process of assigning different dynamic weight values ​​to each application in the domain controller includes the following steps: Obtain the category of the target application and determine the category weight value of the target application; Read the last response time of the target application to determine the response weight value of the target application; Update the scenario weight value of the target application based on the current working scenario of the domain controller; The dynamic weight value of the target application is obtained by summing the category weight value, response weight value, and scenario weight value.

6. The method for dynamic allocation of vehicle system resources based on application weight values ​​according to claim 1, wherein, The target redline values ​​include the overall redline values ​​for domain controllers and the individual redline values ​​for applications; The overall redline value of the domain controller is set according to the hardware resources of the domain controller; The individual redline value for each application is determined based on the overall redline value of the domain controller and the dynamic weight value of each application.

7. A method for dynamic allocation of vehicle system resources based on application weight values ​​according to claim 6, wherein, The hardware resources of the domain controller specifically include the domain controller's CPU resources, GPU resources, and NPU resources.

8. A method for dynamic allocation of vehicle system resources based on application weight values ​​according to claim 6, wherein, The dynamic allocation of hardware resources for the domain controller specifically includes the following steps: Allocate domain controller hardware resources, no less than the application's individual redline value, to each application currently running on the domain controller.

9. A method for dynamic allocation of vehicle system resources based on application weight values ​​according to claim 8, wherein, When the resource usage of a domain controller reaches the overall red line value for the domain controller, the domain controller performs the following steps: Obtain the dynamic weight values ​​of the applications currently running on the domain controller and sort them accordingly. Turn off the application with the lowest dynamic weight value in the sorting; Determine if the domain controller's resource usage is below the domain controller's overall red line value; if the domain controller's resource usage is still above the domain controller's overall red line value, return to the step of shutting down the application with the lowest dynamic weight value in the sorting, until the domain controller's resource usage is below the domain controller's overall red line value.

10. A method for dynamic allocation of vehicle system resources based on application weight values ​​according to claim 6, wherein, When a target application's resource usage on the domain controller reaches the target application's individual redline value, the domain controller performs the following steps: Monitor the resource usage of the target application within a preset time period; When the resource usage of a target application exceeds its individual red line value within a preset time period, the dynamic weight value of the target application is reduced.

11. A vehicle equipped with a cockpit domain controller, the cockpit domain controller including a processor, a memory, and computer program instructions stored in the memory and executable on the processor, wherein the processor, when executing the computer program instructions, implements the vehicle-mounted resource dynamic allocation method based on application weight values ​​as described in any one of claims 1 to 10.

12. A computer-readable storage medium storing a program, said program being executed by a processor to implement the vehicle-mounted system resource dynamic allocation method based on application weight values ​​as described in any one of claims 1 to 10.

13. A computer program product comprising a computer program or computer instructions stored in a computer-readable storage medium, wherein a processor of an electronic device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions to cause the electronic device to perform the vehicle-mounted resource dynamic allocation method based on application weight values ​​as described in any one of claims 1 to 10.

Images