Method for monitoring performance of vehicle control software and vehicle

Abstract

This application discloses a performance monitoring method for vehicle control software and a vehicle. The vehicle control software is deployed on the vehicle's central domain controller and is used to execute multiple vehicle control tasks. The method includes: collecting operational characteristic data of various vehicle control tasks in parallel based on acquisition modules deployed on each operating system kernel in the central domain controller; determining resource load data of the central domain controller based on the operational characteristic data of the various vehicle control tasks, the resource load data reflecting the resource occupancy of the central domain controller; and reporting the resource load data to a cloud service to monitor the performance of the vehicle control software through the cloud service. The technical solution provided by this application can improve the accuracy of vehicle control software performance monitoring.

Description

Technical Field

[0001] This application belongs to the field of vehicle control software performance monitoring technology, and particularly relates to a vehicle control software performance monitoring method and a vehicle. Background Technology

[0002] As automotive electronic and electrical architecture evolves towards a domain-centralized or even central domain controller architecture, various functions such as vehicle control, body management, power adjustment, and chassis control are gradually integrated into the central domain controller. Vehicle control software needs to execute multiple complex vehicle control tasks simultaneously and also needs to achieve interactive processing of massive amounts of data from multiple domains such as the cockpit and autonomous driving. This significantly improves the integration and intelligence level of vehicle control, laying a technical foundation for the safe and efficient operation of vehicles.

[0003] However, the heterogeneous multi-core software environment of the central domain controller is extremely complex, and its resource occupancy status directly determines the performance of the vehicle control software. Currently, the performance monitoring of vehicle control software is mostly carried out in laboratory simulation environments, simulating the vehicle's operating status and detecting relevant data through simulation platforms. This method differs significantly from the actual driving environment of the vehicle, and the resource load data obtained cannot accurately reflect the actual resource occupancy of the central domain controller. This results in insufficient accuracy in monitoring the performance of the vehicle control software, making it difficult to effectively predict potential software failures and posing a potential threat to the stable operation of the vehicle.

[0004] Therefore, improving the accuracy of vehicle control software performance monitoring has become an urgent technical problem to be solved. Summary of the Invention

[0005] The embodiments of this application provide a method, apparatus, computer program product, computer-readable storage medium, and vehicle for monitoring the performance of vehicle control software, thereby improving the accuracy of vehicle control software performance monitoring to at least a certain extent.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to a first aspect of the present application, a performance monitoring method for vehicle control software is provided. The vehicle control software is deployed on a central domain controller of a vehicle and is used to execute multiple vehicle control tasks. The method includes: collecting operational characteristic data of each vehicle control task in parallel based on acquisition modules deployed on each operating system kernel in the central domain controller; determining resource load data of the central domain controller based on the operational characteristic data of each vehicle control task, the resource load data reflecting the resource occupancy of the central domain controller; and reporting the resource load data to a cloud service to monitor the performance of the vehicle control software through the cloud service.

[0008] In some embodiments of this application, based on the aforementioned scheme, the operational characteristic data of each vehicle control task is collected, including: calling the first acquisition function in the acquisition module to record the first moment when the smallest task unit in each vehicle control task starts; calling the second acquisition function in the acquisition module to record the second moment when the smallest task unit in each vehicle control task exits; and determining the first moment and the second moment as the operational characteristic data of each vehicle control task.

[0009] In some embodiments of this application, based on the foregoing scheme, determining the resource load data of the central domain controller based on the operational characteristic data of each vehicle control task includes: calculating the difference between the second time moment and the first time moment as the execution duration of the minimum working unit; calculating the difference between two adjacent first time moments as the scheduling cycle of the minimum working unit; and determining the execution duration and the scheduling cycle as the resource load data of the central domain controller.

[0010] In some embodiments of this application, based on the aforementioned scheme, the collection of operational characteristic data for each vehicle control task includes: calling the third acquisition function in the acquisition module to record the third moment when each vehicle control task starts running; calling the fourth acquisition function in the acquisition module to record the fourth moment when each vehicle control task stops running; calculating the difference between the fourth moment and the third moment as the single running length of each vehicle control task, and determining the single running length as the operational characteristic data of each vehicle control task.

[0011] In some embodiments of this application, based on the foregoing scheme, determining the resource load data of the central domain controller based on the operational characteristic data of each vehicle control task includes: obtaining a pre-set load statistics period, and calculating the sum of the single running durations of each vehicle control task within the load statistics period to obtain the cumulative total running time; calculating the ratio of the cumulative total running time to the load statistics period as the load rate, and determining the load rate as the resource load data of the central domain controller.

[0012] In some embodiments of this application, based on the aforementioned scheme, the collection of operational characteristic data for each vehicle control task includes: determining a stack space allocated for each vehicle control task in the central domain controller, and initializing the stacks in the stack space to preset characteristic values; obtaining a preset load statistics period, and counting the number of stacks in the stack space whose characteristic values ​​are not preset characteristic values ​​within the load statistics period to obtain the stack occupancy count; and determining the stack occupancy count corresponding to each vehicle control task as the operational characteristic data of each vehicle control task.

[0013] In some embodiments of this application, based on the foregoing scheme, determining the resource load data of the central domain controller based on the operational characteristic data of each vehicle control task includes: obtaining the total number of stacks in the stack space; calculating the ratio of the number of stacks occupied to the total number of stacks as the stack utilization rate, and determining the stack utilization rate as the resource load data of the central domain controller.

[0014] In some embodiments of this application, based on the foregoing scheme, the monitoring of the performance of the vehicle control software through the cloud service includes: setting a load rate threshold and a stack utilization threshold in the cloud service; comparing the load rate in the resource load data with the load rate threshold, and comparing the stack utilization in the resource load data with the stack utilization threshold; if the load rate is greater than the load rate threshold or the stack utilization is greater than the stack utilization threshold, then the vehicle control software is determined to have abnormal performance.

[0015] In some embodiments of this application, based on the foregoing scheme, the method further includes: if it is determined that the vehicle control software performance is abnormal, generating abnormal warning information through the cloud service; and sending the abnormal warning information to a preset terminal to remind software maintenance personnel to optimize the software.

[0016] According to a second aspect of the embodiments of this application, a performance monitoring device for vehicle control software is provided. The vehicle control software is deployed on a central domain controller of a vehicle and is used to execute multiple vehicle control tasks. The device includes: a data acquisition unit, used to acquire, in parallel, operational characteristic data of each vehicle control task based on acquisition modules deployed on each operating system kernel in the central domain controller; a determination unit, used to determine resource load data of the central domain controller based on the operational characteristic data of each vehicle control task, the resource load data reflecting the resource occupancy of the central domain controller; and a reporting unit, used to report the resource load data to a cloud service so as to monitor the performance of the vehicle control software through the cloud service.

[0017] According to a third aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor to cause a computer device having the processor to perform an operation as described in any of the first aspects above.

[0018] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by a processor to perform the operation as described in any of the first aspects above.

[0019] According to a fifth aspect of the embodiments of this application, a vehicle is provided, the vehicle including one or more processors and one or more memories, the one or more memories storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the one or more processors to perform the operation as described in any of the first aspects above.

[0020] Based on the technical solution proposed in this application, by deploying acquisition modules in the core of each operating system of the central domain controller and collecting operational characteristic data of various vehicle control tasks in parallel, data acquisition can be completed in the actual driving environment of the vehicle. This allows the collected operational characteristic data to closely match the actual operating conditions of the central domain controller, rather than simulated data from a laboratory simulation environment. The resource load data determined based on this realistic operational characteristic data can accurately reflect the actual resource occupancy of the central domain controller. Consequently, cloud services can perform performance monitoring of the vehicle control software based on this real resource load data, effectively improving the accuracy of vehicle control software performance monitoring. This allows maintenance personnel of the vehicle control software to accurately grasp the actual operating status of the central domain controller through cloud services, thereby effectively predicting potential faults in the operation of the vehicle control software and reducing potential risks to stable vehicle operation. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0022] Figure 1 A schematic diagram illustrating a scenario for performance monitoring methods of vehicle control software in existing solutions is shown. Figure 2 A flowchart of a performance monitoring method for vehicle control software in an embodiment of this application is shown; Figure 3 A system architecture diagram is shown for implementing the performance monitoring method of the vehicle control software in the embodiments of this application; Figure 4 A schematic diagram illustrating the measurement of the minimum work unit call cycle and execution time in the vehicle control task in an embodiment of this application is shown; Figure 5 A schematic diagram illustrating the measurement of vehicle control task load rate in an embodiment of this application is shown; Figure 6 A schematic diagram illustrating the measurement of vehicle control task stack utilization in an embodiment of this application is shown; Figure 7 A block diagram of a performance monitoring device for vehicle control software in an embodiment of this application is shown; Figure 8 A schematic diagram of the vehicle structure in an embodiment of this application is shown. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0025] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices. It should also be noted that, for the sake of simplicity, certain components in the drawings that do not affect the interpretation of the technical solution of this application have been appropriately omitted.

[0026] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined. Therefore, the actual execution order may change depending on the actual situation.

[0027] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0028] As automotive electronic and electrical architecture evolves towards a domain-centralized or even central domain controller architecture, various functions such as vehicle control, body management, power adjustment, and chassis control are gradually integrated into the central domain controller. Vehicle control software needs to execute multiple complex vehicle control tasks simultaneously and also needs to achieve interactive processing of massive amounts of data from multiple domains such as the cockpit and autonomous driving. This significantly improves the integration and intelligence level of vehicle control, laying a technical foundation for the safe and efficient operation of vehicles.

[0029] However, the heterogeneous multi-core software environment of the central domain controller is extremely complex, and its resource occupancy status directly determines the running performance of the vehicle control software. Currently, the performance monitoring of vehicle control software is mostly carried out in laboratory simulation environments, simulating the vehicle's operating status and detecting relevant data through simulation platforms.

[0030] Reference Figure 1 This diagram illustrates a scenario of performance monitoring methods for vehicle control software in existing solutions.

[0031] like Figure 1 As shown, in the existing solution, the Canoe simulation platform generates CAN bus data simulating vehicle operation and sends it to the ECU under test (i.e., the central domain controller). After receiving the simulation data, the ECU under test runs the internal vehicle control software tasks to simulate the working state under real working conditions. Developers establish a connection with the ECU under test on the PC through Lauderbach (i.e., debugger) and JTAG debug port to collect relevant data on the operation of the ECU software (i.e., vehicle control software) in real time.

[0032] However, the above testing methods differ significantly from the actual driving environment of vehicles. The resource load data obtained from the monitoring cannot accurately reflect the actual resource occupancy of the central domain controller, resulting in insufficient accuracy in monitoring the performance of vehicle control software. This makes it difficult to effectively predict potential software malfunctions and poses a potential threat to the stable operation of the vehicle.

[0033] In this context, this application proposes a performance monitoring scheme for vehicle control software, aiming to improve the accuracy of vehicle control software performance monitoring, overcome the shortcomings of existing technologies, and ensure the stable operation of vehicle control software.

[0034] It should be noted that, in this application, the vehicle control software is deployed on the vehicle's central domain controller to execute multiple vehicle control tasks. As the core control unit of the vehicle, the central domain controller typically integrates the execution functions of multiple vehicle control tasks, including vehicle control, body management, powertrain adjustment, chassis control, and air conditioning control. The central domain controller contains multiple operating system kernels, each capable of processing different vehicle control tasks in parallel.

[0035] Next, this application will elaborate on the proposed performance monitoring scheme for vehicle control software. (Refer to...) Figure 2 The diagram illustrates a flowchart of a performance monitoring method for vehicle control software according to an embodiment of this application. This method can be executed by a device with computational processing capabilities, such as... Figure 2 As shown, the method includes at least steps 210 to 230, which are described in detail below: Step 210: Based on the acquisition modules deployed on each operating system core in the central domain controller, the operational characteristic data of each vehicle control task are acquired in parallel.

[0036] Step 220: Based on the operational characteristic data of each vehicle control task, determine the resource load data of the central domain controller. The resource load data is used to reflect the resource occupancy of the central domain controller.

[0037] Step 230: The resource load data is reported to the cloud service so that the performance of the vehicle control software can be monitored through the cloud service.

[0038] In this application, a data acquisition module is deployed on each operating system kernel of the central domain controller. This data acquisition module is adapted to the operation of the operating system kernel and can carry out data acquisition work synchronously during the operation of the vehicle control software and the processing of various vehicle control tasks by the central domain controller. Moreover, the data acquisition modules on each operating system kernel can work simultaneously to realize the parallel acquisition of the operational characteristic data of various vehicle control tasks.

[0039] In this application, the operational characteristic data refers to various types of time data and resource usage data that can reflect the operational status of vehicle control tasks, and is the basis for subsequent calculation of central domain controller resource load data.

[0040] After collecting operational characteristic data, resource load data reflecting the resource occupancy of the central domain controller can be determined through corresponding calculation and statistical methods based on the collected operational characteristic data of various vehicle control tasks. This resource load data can intuitively reflect the degree of occupancy of the central domain controller's computing and storage resources by various vehicle control tasks. Finally, all the calculated resource load data is reported to the cloud service through the vehicle's remote communication module. After receiving the resource load data, the cloud service can perform performance monitoring of the vehicle control software based on the data, thereby realizing remote real-time monitoring of the central domain controller's resource occupancy status.

[0041] See Figure 3 The diagram illustrates the system architecture for implementing the performance monitoring method of the vehicle control software in the embodiments of this application.

[0042] For example, in a specific embodiment, according to Figure 3 The system architecture shown assumes that the vehicle's central domain controller contains four operating system kernels, each responsible for handling four types of vehicle control tasks: body control, powertrain adjustment, chassis control, and media control. With a data acquisition module deployed on each operating system kernel, these four modules can operate simultaneously during vehicle operation, collecting operational characteristic data for each of the four tasks: body control, powertrain adjustment, chassis control, and media control. Based on this operational characteristic data, resource load data, such as the resource utilization ratio and storage resource utilization of each operating system kernel for each of the four tasks, are calculated. Finally, this resource load data is uploaded to a cloud service via the vehicle's remote communication module. The cloud service can then monitor the resource utilization status of the vehicle's central domain controller in real time, thus completing the performance monitoring of the vehicle control software.

[0043] Based on the above solution, by deploying acquisition modules in the core of each operating system of the central domain controller and collecting operational characteristic data of various vehicle control tasks in parallel, data acquisition can be completed in the actual driving environment of the vehicle. This ensures that the collected operational characteristic data closely matches the actual operating conditions of the central domain controller, rather than simulated data from a laboratory simulation environment. The resource load data determined based on this realistic operational characteristic data can accurately reflect the actual resource occupancy of the central domain controller. Consequently, cloud services can use this real resource load data to perform performance monitoring of the vehicle control software, effectively improving the accuracy of vehicle control software performance monitoring. This allows maintenance personnel of the vehicle control software to accurately grasp the actual operating status of the central domain controller through cloud services, thereby effectively predicting potential faults in the operation of the vehicle control software and reducing potential risks to stable vehicle operation.

[0044] Next, this application will address the following: Figure 1 Each step in the illustrated scheme is explained in detail.

[0045] In such Figure 1 In step 210, the operational characteristic data for each vehicle control task are collected, which can be performed according to steps 211 to 213 as follows: Step 211: Call the first acquisition function in the acquisition module to record the first moment of startup of the smallest task unit in each vehicle control task.

[0046] Step 212: Call the second acquisition function in the acquisition module to record the second moment when the smallest task unit in each vehicle control task exits.

[0047] Step 213: Determine the first time point and the second time point as the operational characteristic data for each vehicle control task.

[0048] In this application, it should first be clarified that each vehicle control task is composed of multiple minimum task units. The minimum task unit is the smallest indivisible execution unit in the vehicle control task and is the basic unit for the vehicle control software to complete specific control functions. The acquisition module has a first acquisition function and a second acquisition function preset. Both types of acquisition functions can be automatically triggered and complete time recording during the operation of the vehicle control task.

[0049] Specifically, when the smallest task unit in each vehicle control task starts running, the first acquisition function in the acquisition module is automatically called. The first acquisition function accurately records the first moment when the smallest task unit starts. When the smallest task unit finishes running and exits, the second acquisition function in the acquisition module is automatically called. The second acquisition function accurately records the second moment when the smallest task unit exits. After the above time recording is completed, the recorded first moment and second moment are directly determined as the running characteristic data of the vehicle control task, providing a basic time basis for the determination of subsequent resource load data.

[0050] Reference Figure 4 The diagram illustrates the measurement of the minimum work unit call cycle and execution time in the vehicle control task in this embodiment of the application.

[0051] like Figure 4 As shown, both the first and second acquisition functions can be hook functions, which can be deployed in the time recording tool within the central domain controller's acquisition module. Specifically, the first acquisition function, "Runnable Enter Hook()", is triggered the instant the smallest task unit (Runnable) starts, thus recording the first moment (startup moment). Similarly, the second acquisition function, "Runnable Exit Hook()", is triggered the instant the smallest task unit (Runnable) exits (completes a single task execution), thus recording the second moment (exit moment).

[0052] For example, in a specific embodiment, the vehicle's power adjustment task may include multiple minimum task units such as engine speed adjustment, throttle response adjustment, and fuel injection control. When the engine speed adjustment minimum task unit starts running, the first acquisition function is automatically invoked, recording the first time as 10:00:00.000. When the minimum task unit completes speed adjustment and exits running, the second acquisition function is automatically invoked, recording the second time as 10:00:00.005. These two time data are used as the operational characteristic data of the power adjustment task. Similarly, the first time recorded when the throttle response adjustment minimum task unit starts is 10:00:00.006, and the second time recorded when it exits is 10:00:00.010. This set of time data is also used as the operational characteristic data of the power adjustment task.

[0053] Based on the above scheme, by calling the dedicated first and second acquisition functions in the acquisition module, the start and exit times of the smallest task unit in the vehicle control task can be accurately recorded. This data acquisition process is automatically completed during the actual operation of the smallest task unit without manual intervention. The acquisition process has strong real-time performance, and the accuracy of the acquired time data is high, which can truly reflect the actual running time nodes of the smallest task unit. Using this accurate time data as the operating characteristic data of the vehicle control task can provide reliable basic data support for the subsequent accurate determination of the resource load data of the central domain controller, avoiding deviations in the calculation of subsequent resource load data due to errors in the basic data, and further improving the fit between the resource load data and the actual operating status of the central domain controller.

[0054] In such Figure 1 In step 220, determining the resource load data of the central domain controller based on the operational characteristic data of each vehicle control task can be performed according to steps 221 to 223 as follows: Step 221: Calculate the difference between the second time point and the first time point, and use it as the execution time of the smallest working unit.

[0055] Step 222: Calculate the difference between two adjacent first moments as the scheduling period of the minimum working unit.

[0056] Step 223: The execution duration and the scheduling cycle are determined as the resource load data of the central domain controller.

[0057] In this application, the difference between the first and second moments of the same minimum task unit can be calculated first. The time difference obtained by subtracting the first moment from the second moment is the execution duration of a single run of the minimum task unit. This execution duration directly reflects the time resources consumed by the minimum task unit in a single run. Subsequently, the difference between the first moments recorded when the same minimum task unit is started twice consecutively can be calculated. The time difference obtained by subtracting the first moment of the previous start from the first moment of the later start is the scheduling cycle of the minimum task unit. This scheduling cycle reflects the running frequency of the minimum task unit. After completing the above two calculations, the execution duration and scheduling cycle of the minimum task unit are directly determined as the resource load data of the central domain controller. After being uploaded to the cloud service, the cloud service can use this data to grasp the running rhythm of the minimum task unit.

[0058] Continue to refer to Figure 4 As shown, by subtracting the first moment (0ms) from the second moment (3ms) recorded in the first instance, a difference of 3ms can be obtained. This difference is the execution time of the smallest task unit. Figure 4 The runtime of the Runnable state. When the smallest task unit starts for the second time, Runnable Enter Hook() is triggered again, recording a new first moment (e.g., 10ms). By subtracting the first moment (0ms) from the second first moment (10ms), the difference of 10ms can be obtained, which is the scheduling cycle of the smallest task unit.

[0059] Similarly, the above process will be repeated each time a task is started and exited, continuously collecting time data and calculating execution duration and scheduling cycle, ultimately forming resource load data that reflects the resource occupancy of the central domain controller.

[0060] Based on the above scheme, by performing a simple difference calculation on the first and second moments collected, the execution duration and scheduling cycle of the smallest task unit in the vehicle control task can be quickly obtained. This calculation method is simple and efficient, does not require excessive computing resources from the central domain controller, and can complete data processing in real time during the operation of the vehicle control software. Moreover, the calculated execution duration and scheduling cycle can intuitively reflect the actual operating rhythm of the smallest task unit. By identifying this data as the resource load data of the central domain controller, the cloud service can grasp the operating status of the vehicle control task from a micro perspective, enriching the monitoring dimensions of resource load data. This allows the cloud service to monitor the performance of the vehicle control software more meticulously and comprehensively, enabling timely detection of abnormal operating rhythm issues such as excessively long execution duration of the smallest task unit and excessively short scheduling cycle, thereby improving the ability to predict abnormal performance of the vehicle control software.

[0061] In such Figure 1In step 210, the operational characteristic data for each vehicle control task are collected, which can be performed according to steps 214 to 216 below: Step 214: Call the third acquisition function in the acquisition module to record the third moment when each vehicle control task starts running.

[0062] Step 215: Call the fourth acquisition function in the acquisition module to record the fourth moment of each vehicle control task during the pause operation.

[0063] Step 216: Calculate the difference between the fourth time point and the third time point as the single runtime of each vehicle control task, and determine the single runtime as the operating characteristic data of each vehicle control task.

[0064] In this application, the acquisition module may also have a third acquisition function and a fourth acquisition function preset. Both types of acquisition functions are set for the overall operation status of the vehicle control task and can be automatically triggered and complete time recording at key nodes in the overall operation of the task. When each vehicle control task starts running, the third acquisition function in the acquisition module is automatically called, and the third acquisition function accurately records the third moment when the vehicle control task starts running. When the vehicle control task is paused due to interruption of resources, completion of a phase, or other reasons, the fourth acquisition function in the acquisition module is automatically called, and the fourth acquisition function accurately records the fourth moment when the vehicle control task is paused. After the time recording is completed, the difference between the third moment and the fourth moment is calculated. The time difference obtained by subtracting the third moment from the fourth moment is the single running length of the vehicle control task. This single running length is directly determined as the operation characteristic data of the vehicle control task.

[0065] Reference Figure 5 The diagram illustrates the measurement of vehicle control task load rate in an embodiment of this application.

[0066] like Figure 5 As shown, both the third and fourth acquisition functions are hook functions, which can also be deployed in the time recording tool of the central domain controller acquisition module. Specifically, the third acquisition function "PreTask Hook()" can be triggered when the task starts running, thus recording the third moment (task start time); the fourth acquisition function "PostTask Hook()" can be triggered when the task is paused, thus recording the fourth moment (task exit time). By subtracting the third moment recorded by PreTask Hook, the single runtime of the task can be calculated.

[0067] For example, in a specific embodiment, the vehicle chassis control task is a complete vehicle control task. When the task starts running, the third acquisition function automatically records the third time as 10:00:00.000. If a braking interruption signal is received during vehicle operation, the chassis control task is paused. At this time, the fourth acquisition function automatically records the fourth time as 10:00:00.020. The difference between the fourth time and the third time is calculated to be 20 milliseconds. This 20 milliseconds is the single runtime of the chassis control task, and this data is used as the running characteristic data of the chassis control task. After the braking interruption signal is processed, the chassis control task restarts, and the third acquisition function is called again to record a new third time. During subsequent pauses, the fourth time is recorded and a new single runtime is calculated.

[0068] Based on the above scheme, by setting dedicated third and fourth acquisition functions for the overall operation status of the vehicle control task, the start and stop times of the overall task can be accurately recorded and the duration of a single run can be calculated. This acquisition method closely matches the actual operating conditions of the vehicle control task, which may be interrupted or paused during actual operation. The acquired single run duration data can truly reflect the actual operating status of the vehicle control task under uninterrupted conditions, avoiding the problem that only collecting data from the smallest task unit cannot reflect the overall operating status of the task. Using this single run duration as operating characteristic data can provide accurate basic data for subsequent calculations of the load rate, which reflects the overall resource utilization of the central domain controller, making the subsequent resource load data more consistent with the actual operating conditions of the central domain controller.

[0069] In such Figure 1 In step 220, determining the resource load data of the central domain controller based on the operational characteristic data of each vehicle control task can be performed according to steps 224 to 225 as follows: Step 224: Obtain the preset load statistics cycle, and calculate the sum of the single running time of each vehicle control task within the load statistics cycle to obtain the cumulative total running time.

[0070] Step 224: Calculate the ratio of the cumulative total running time to the load statistics period as the load rate, and determine the load rate as the resource load data of the central domain controller.

[0071] In this application, a fixed load statistics period can first be set in advance based on the hardware performance of the central domain controller and the operational requirements of the vehicle control software. This load statistics period is the time range for statistically analyzing the runtime of vehicle control tasks and can be adjusted according to actual needs. Within this load statistics period, the runtime of all individual runs of the vehicle control task collected is summed, and the sum is the cumulative total runtime of the vehicle control task within the load statistics period. This cumulative total runtime reflects the actual running time of the task within a fixed time frame. Subsequently, the ratio of the cumulative total runtime to the load statistics period is calculated. The value obtained by dividing the cumulative total runtime by the load statistics period is the load rate of the vehicle control task. After the calculation is completed, this load rate is directly determined as the resource load data of the central domain controller.

[0072] Continue to refer to Figure 5 As shown, task 0 did not restart before the end of the 200ms measurement period. Therefore, the sum of all its individual runtimes can be calculated, i.e., total cumulative runtime = 30ms (cumulative time 1) + 40ms (cumulative time 2) = 70ms. Next, the load rate can be calculated using the formula: Load rate of task 0 = 70ms ÷ 200ms = 35%. This result represents the resource load data of the central domain controller and can be reported to the cloud service for performance monitoring.

[0073] Based on the above scheme, by pre-setting a fixed load statistics period and calculating the cumulative total running time of vehicle control tasks within that period to determine the load rate, the degree of occupancy of vehicle control tasks on the central domain controller's computing resources within a fixed time period can be quantitatively reflected. This calculation method, by summing the duration of multiple single runs, can eliminate the randomness of single task running time, making the obtained load rate data more representative and objective. Using the load rate as the core resource load data of the central domain controller allows cloud services to intuitively and clearly grasp the proportion of central domain controller resources occupied by various vehicle control tasks, accurately determine whether a certain vehicle control task has excessive resource consumption, effectively solve the problem that existing monitoring methods cannot truly reflect the actual resource consumption of the central domain controller, and improve the targeting of vehicle control software performance monitoring.

[0074] In such Figure 1 In step 210, the operational characteristic data for each vehicle control task are collected, which can be performed according to steps 217 to 219 below: Step 217: Determine the stack space allocated for each vehicle control task in the central domain controller, and initialize the stack in the stack space to preset characteristic values.

[0075] Step 218: Obtain a preset load statistics period, and within the load statistics period, count the number of stacks in the stack space whose characteristic value is not a preset characteristic value, to obtain the number of stacks occupied.

[0076] Step 219: Determine the number of stack occupancy corresponding to each vehicle control task as the running characteristic data of each vehicle control task.

[0077] In this application, the central domain controller allocates an independent stack space for each vehicle control task. This stack space serves as a temporary storage resource during the operation of the vehicle control task. The stack is the basic storage unit of the stack space, and each vehicle control task's stack space contains a fixed number of stacks. First, after the central domain controller allocates stack space for each vehicle control task, all stacks in the stack space are initialized to a preset characteristic value. This preset characteristic value is a unified identifier used to distinguish unused stacks in the stack space. Then, a pre-set load statistics period is obtained. Within this load statistics period, data is read and statistically analyzed from the stack space corresponding to the vehicle control task. The number of stacks with characteristic values ​​other than the preset characteristic value is counted. These stacks with non-preset characteristic values ​​are the stacks occupied by the vehicle control task. The counted number of occupied stacks is directly determined as the operational characteristic data of the vehicle control task.

[0078] Reference Figure 6 The diagram illustrates a measurement of the vehicle control task stack usage in an embodiment of this application.

[0079] like Figure 6 As shown, the bottom of the stack can be the starting position of the stack space and also the core area for data operations. Temporary data generated during the vehicle control task (such as variables and function call parameters) is stored upwards from the bottom of the stack, overwriting unused stack space. The character "0xAA" is a pre-defined identifier for unused stack space (i.e., a preset characteristic value). Before the vehicle control task starts, the central domain controller initializes all unused stack space allocated to the task to 0xAA (a hexadecimal number, a commonly used meaningless padding value in the industry to avoid conflicts with the actual task data). When the task generates temporary data, it overwrites 0xAA from the bottom of the stack; the overwritten area is the used stack space.

[0080] For example, in a specific embodiment, the central domain controller allocates a stack space containing 1000 stacks for the vehicle's air conditioning control task. All stacks in this stack space are initialized to hexadecimal 0xAA as a preset characteristic value. The preset load statistics period is 200 milliseconds. Within these 200 milliseconds, the stack space of the air conditioning control task is counted, and the number of stacks with a characteristic value other than 0xAA is found to be 300. These 300 stacks are the number of stacks occupied by the air conditioning control task, and are determined as the running characteristic data of the task.

[0081] Based on the above scheme, by initializing the unused stacks in the central domain controller stack space to preset characteristic values, the used and unused stacks in the stack space can be clearly distinguished. Subsequently, only the number of stacks with non-preset characteristic values ​​needs to be counted to quickly obtain the actual stack space occupancy. This collection method does not require a complex calculation process and can efficiently complete the collection of stack space-related operational characteristic data. Moreover, the collection process only involves data reading and statistics, with extremely low resource consumption on the central domain controller and will not affect the normal operation of the vehicle control software. At the same time, the number of stack occupancy can truly and accurately reflect the actual occupancy of the central domain controller stack space by vehicle control tasks, providing accurate basic data for subsequent calculation of stack utilization, and making the stack space-related resource load data more consistent with the actual operating status of the central domain controller.

[0082] In such Figure 1 In step 220, determining the resource load data of the central domain controller based on the operational characteristic data of each vehicle control task can be performed according to steps 226 to 227 as follows: Step 226: Obtain the total number of stacks in the stack space.

[0083] Step 227: Calculate the ratio of the number of stacks occupied to the total number of stacks as the stack utilization rate, and determine the stack utilization rate as the resource load data of the central domain controller.

[0084] In this application, the total number of stacks in the stack space allocated by the central domain controller for the vehicle control task can first be obtained. This total number of stacks is a fixed value and is a basic parameter of the stack space. Then, the ratio of the statistically obtained stack occupancy number to the total number of stacks is calculated. The value obtained by dividing the stack occupancy number by the total number of stacks is the stack utilization rate of the vehicle control task. After the calculation is completed, the stack utilization rate is directly determined as the resource load data of the central domain controller.

[0085] For example, in a specific embodiment, the central domain controller allocates a total of 1000 stacks for the air conditioning control task. If the number of stacks occupied during the load statistics period is 300, dividing 300 by 1000 yields a value of 0.3, indicating that the stack utilization rate for this air conditioning control task is 30%. This 30% stack utilization rate is determined as the resource load data for the central domain controller. If the number of stacks occupied is 850, the corresponding stack utilization rate is 85%.

[0086] Based on the above scheme, the stack utilization rate is calculated by the ratio of the number of stacks occupied to the total number of stacks. This quantitatively reflects the proportion of stack space storage resources occupied by vehicle control tasks. The calculation method is simple and intuitive, requiring no complex algorithm support, and can be completed in real time during the operation of vehicle control software. Using the stack utilization rate as resource load data of the central domain controller allows cloud services to accurately grasp the actual stack space occupation of various vehicle control tasks, and promptly detect stack overflow problems that may be caused by excessive stack utilization. Stack overflow is an important cause of vehicle control software malfunctions and even central domain controller system crashes. Therefore, obtaining this data can effectively predict major potential faults in the operation of vehicle control software, improve the stability of vehicle control software operation, and ensure safe vehicle operation.

[0087] In this application, the monitoring of the performance of the vehicle control software via the cloud service can be performed according to the following steps 231 to 233: Step 231: The cloud service presets a load rate threshold and a stack utilization threshold.

[0088] Step 232: Compare the load rate in the resource load data with the load rate threshold, and compare the stack utilization rate in the resource load data with the stack utilization threshold.

[0089] Step 233: If the load rate is greater than the load rate threshold or the stack utilization rate is greater than the stack utilization rate threshold, then the vehicle control software is determined to be abnormal.

[0090] In this application, firstly, load rate thresholds and stack utilization thresholds can be pre-set in the cloud service based on the hardware resource capabilities of the central domain controller, the operational requirements of the vehicle control software, and the safety standards for vehicle operation. These two thresholds serve as critical values ​​for determining whether the vehicle control software performance is abnormal. If the actual resource load data exceeds these thresholds, it indicates that the vehicle control software's operating status is abnormal. After receiving the reported resource load data, the cloud service compares the load rate with the preset load rate threshold and the stack utilization with the preset stack utilization threshold. If the comparison results show that the actual load rate is greater than the preset load rate threshold, or the actual stack utilization is greater than the preset stack utilization threshold, satisfying either condition, the vehicle's control software performance can be directly determined to be abnormal.

[0091] For example, in a specific embodiment, the cloud service presets a load rate threshold of 80% and a stack utilization threshold of 90%. If a vehicle's power control task reports a load rate of 85% and a stack utilization of 80%, the 85% load rate exceeds the 80% threshold, thus indicating abnormal performance of the vehicle's control software. Similarly, if another vehicle's body control task reports a load rate of 75% and a stack utilization of 95%, the 95% stack utilization also exceeds the 90% stack utilization threshold, again indicating abnormal performance of the vehicle's control software. However, if a vehicle's air conditioning control task has a load rate of 70% and a stack utilization of 85%, both within the thresholds, its performance is considered normal.

[0092] Based on the above solution, by presetting reasonable load rate thresholds and stack utilization thresholds in the cloud service, and automatically comparing the actual collected and calculated resource load data with the thresholds, it is possible to quickly and objectively determine whether the performance of the vehicle control software is abnormal. This determination method does not require manual analysis and judgment of resource load data, and can realize the automation of vehicle control software performance monitoring. The determination results are accurate and efficient, and problems can be detected as soon as abnormalities occur in the vehicle control software. This solves the problem that existing monitoring methods rely on manual analysis and cannot accurately determine performance abnormalities in real time, thus improving the efficiency and timeliness of vehicle control software performance monitoring.

[0093] In this application, steps 234 to 235 may also be performed as follows: Step 234: If the vehicle control software is determined to be malfunctioning, an abnormal warning message is generated through the cloud service.

[0094] Step 235: Send the abnormal warning information to a preset terminal to remind software maintenance personnel to optimize the software.

[0095] In this application, once the cloud service determines that the vehicle control software is experiencing performance anomalies through data comparison, it can immediately generate an anomaly warning message based on the anomaly. This warning message includes key information such as the name of the vehicle control task experiencing the performance anomaly, the actual load rate or stack utilization data, the specific time the anomaly occurred, and the corresponding vehicle identifier, allowing maintenance personnel to quickly grasp the details of the anomaly. Subsequently, the cloud service sends the generated anomaly warning message to a preset terminal via a preset communication method. This preset terminal is a smart terminal such as a work computer, mobile phone, or tablet belonging to the software maintenance personnel. After receiving the warning message, the maintenance personnel can promptly carry out software optimization, resource adjustment, and other tasks, reminding them to optimize the vehicle control software.

[0096] In this application, after determining that the vehicle control software is experiencing performance abnormalities, an anomaly warning message is promptly generated and sent to a preset terminal. This allows software maintenance personnel to grasp the abnormal operation of the vehicle control software immediately, eliminating the need for them to continuously check monitoring data from the cloud service, thus effectively improving the efficiency of problem handling. Maintenance personnel can quickly locate the root cause of the anomaly based on the specific content of the warning message, optimize the software and split tasks with excessively high load rates, expand the stack space for tasks with excessively high stack usage, and take timely countermeasures. This prevents vehicle control software malfunctions or even central domain controller system crashes caused by untimely handling of performance abnormalities, effectively ensuring the continuous and stable operation of the vehicle control software and further improving the safety and reliability of vehicle operation.

[0097] The following describes an embodiment of the apparatus described in this application, which can be used to execute the performance monitoring method for vehicle control software in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the performance monitoring method for vehicle control software described above in this application.

[0098] See Figure 7 The diagram shows a block diagram of a performance monitoring device for vehicle control software according to an embodiment of this application. The vehicle control software is deployed on the central domain controller of the vehicle and is used to perform multiple vehicle control tasks.

[0099] like Figure 7 As shown, the vehicle control software performance monitoring device 700 according to an embodiment of this application includes: a data acquisition unit 701, a determination unit 702, and a reporting unit 703.

[0100] The acquisition unit 701 is used to collect operational characteristic data of various vehicle control tasks in parallel based on the acquisition modules deployed on each operating system core in the central domain controller; the determination unit 702 is used to determine the resource load data of the central domain controller based on the operational characteristic data of the various vehicle control tasks, the resource load data being used to reflect the resource occupancy of the central domain controller; and the reporting unit 703 is used to report the resource load data to a cloud service so as to monitor the performance of the vehicle control software through the cloud service.

[0101] In some embodiments of this application, based on the foregoing scheme, the acquisition unit 701 is configured to: call the first acquisition function in the acquisition module to record the first moment when the smallest task unit in each vehicle control task starts; call the second acquisition function in the acquisition module to record the second moment when the smallest task unit in each vehicle control task exits; and determine the first moment and the second moment as the operating characteristic data of each vehicle control task.

[0102] In some embodiments of this application, based on the foregoing scheme, the determining unit 702 is configured to: calculate the difference between the second time and the first time as the execution duration of the minimum working unit; calculate the difference between two adjacent first times as the scheduling period of the minimum working unit; and determine the execution duration and the scheduling period as the resource load data of the central domain controller.

[0103] In some embodiments of this application, based on the foregoing scheme, the acquisition unit 701 is configured to: call the third acquisition function in the acquisition module to record the third moment when each vehicle control task starts running; call the fourth acquisition function in the acquisition module to record the fourth moment when each vehicle control task stops running; calculate the difference between the fourth moment and the third moment as the single running length of each vehicle control task, and determine the single running length as the running characteristic data of each vehicle control task.

[0104] In some embodiments of this application, based on the foregoing scheme, the determining unit 702 is configured to: obtain a pre-set load statistics period, and calculate the sum of the single running durations of each vehicle control task within the load statistics period to obtain the cumulative total running time; calculate the ratio of the cumulative total running time to the load statistics period as the load rate, and determine the load rate as the resource load data of the central domain controller.

[0105] In some embodiments of this application, based on the foregoing scheme, the acquisition unit 701 is configured to: determine the stack space allocated for each vehicle control task in the central domain controller, and initialize the stacks in the stack space to preset characteristic values; obtain a preset load statistics period, and count the number of stacks in the stack space whose characteristic values ​​are not preset characteristic values ​​within the load statistics period, thereby obtaining the stack occupancy count; and determine the stack occupancy count corresponding to each vehicle control task as the running characteristic data of each vehicle control task.

[0106] In some embodiments of this application, based on the foregoing scheme, the determining unit 702 is configured to: obtain the total number of stacks in the stack space; calculate the ratio of the number of stacks occupied to the total number of stacks as the stack utilization rate, and determine the stack utilization rate as the resource load data of the central domain controller.

[0107] In some embodiments of this application, based on the foregoing scheme, the monitoring of the performance of the vehicle control software through the cloud service includes: setting a load rate threshold and a stack utilization threshold in the cloud service; comparing the load rate in the resource load data with the load rate threshold, and comparing the stack utilization in the resource load data with the stack utilization threshold; if the load rate is greater than the load rate threshold or the stack utilization is greater than the stack utilization threshold, then the vehicle control software is determined to have abnormal performance.

[0108] In some embodiments of this application, based on the foregoing solution, the method further includes: if the vehicle control software is determined to be malfunctioning, generating an abnormal warning message through the cloud service; and sending the abnormal warning message to a preset terminal to remind software maintenance personnel to optimize the software.

[0109] Based on the same inventive concept, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor, so as to cause a computer device having the processor to perform the operations performed by the performance monitoring method of the vehicle control software as described above.

[0110] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing at least one computer program instruction, which is loaded and executed by a processor to implement the operations performed by the performance monitoring method of the vehicle control software as described above.

[0111] Based on the same inventive concept, this application also provides a vehicle, see reference. Figure 8The diagram shows a structural schematic of a vehicle according to an embodiment of this application. The vehicle includes one or more memories 804, one or more processors 802, and at least one computer program (computer program instruction) stored in the memory 804 and executable on the processor 802. When the processor 802 executes the computer program, it implements the performance monitoring method of the vehicle control software as described above.

[0112] Among them, Figure 8 In this document, a bus architecture (represented by bus 800) is used. Bus 800 may include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 802 and memory represented by memory 804. Bus 800 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 805 provides an interface between bus 800 and receiver 801 and transmitter 803. Receiver 801 and transmitter 803 may be the same element, i.e., a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 802 is responsible for managing bus 800 and general processing, while memory 804 can be used to store data used by processor 802 during operation.

[0113] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, the functions can be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For example, due to the nature of software, the functions described above can be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units can be integrated into a single processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

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

[0115] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0116] When the integrated 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, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program instructions, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0117] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for monitoring the performance of vehicle control software, characterized in that, The vehicle control software is deployed on the vehicle's central domain controller and is used to perform multiple vehicle control tasks. The method includes: Based on the acquisition modules deployed on each operating system core in the central domain controller, the operational characteristic data of various vehicle control tasks are collected in parallel. Based on the operational characteristic data of each vehicle control task, the resource load data of the central domain controller is determined, and the resource load data is used to reflect the resource occupancy of the central domain controller. The resource load data is reported to the cloud service so that the performance of the vehicle control software can be monitored through the cloud service.

2. The method according to claim 1, characterized in that, Collect operational characteristic data for each vehicle control task, including: The first acquisition function in the acquisition module is called to record the first moment of startup of the smallest task unit in each vehicle control task; The second acquisition function in the acquisition module is called to record the second moment when the smallest task unit in each vehicle control task exits; The first time point and the second time point are determined as the operational characteristic data for each vehicle control task.

3. The method according to claim 2, characterized in that, The determination of the resource load data of the central domain controller based on the operational characteristic data of each vehicle control task includes: Calculate the difference between the second time point and the first time point, and use it as the execution time of the smallest working unit; Calculate the difference between two adjacent first time points, and use it as the scheduling period of the minimum working unit; The execution duration and the scheduling period are determined as the resource load data of the central domain controller.

4. The method according to claim 1, characterized in that, Collect operational characteristic data for each vehicle control task, including: The third acquisition function in the acquisition module is called to record the third moment at the start of each vehicle control task; The fourth acquisition function in the acquisition module is called to record the fourth moment of each vehicle control task during the pause operation; The difference between the fourth time point and the third time point is calculated as the single runtime of each vehicle control task, and the single runtime is determined as the operational characteristic data of each vehicle control task.

5. The method according to claim 4, characterized in that, The determination of the resource load data of the central domain controller based on the operational characteristic data of each vehicle control task includes: Obtain a pre-set load statistics cycle, and calculate the sum of the single running time of each vehicle control task within the load statistics cycle to obtain the cumulative total running time; The ratio of the cumulative total running time to the load statistics period is calculated as the load rate, and the load rate is determined as the resource load data of the central domain controller.

6. The method according to claim 1, characterized in that, Collect operational characteristic data for each vehicle control task, including: In the central domain controller, a stack space is allocated for each vehicle control task, and the stack in the stack space is initialized to a preset characteristic value. Obtain a preset load statistics period, and within the load statistics period, count the number of stacks in the stack space whose characteristic value is not a preset characteristic value, to obtain the number of stacks occupied; The number of stack occupancy items corresponding to each vehicle control task is determined as the operational characteristic data of each vehicle control task.

7. The method according to claim 6, characterized in that, The determination of the resource load data of the central domain controller based on the operational characteristic data of each vehicle control task includes: Obtain the total number of stacks in the stack space; The ratio of the number of stacks occupied to the total number of stacks is calculated as the stack utilization rate, and the stack utilization rate is determined as the resource load data of the central domain controller.

8. The method according to claim 1, characterized in that, The monitoring of the vehicle control software performance via the cloud service includes: The cloud service has preset load rate thresholds and stack utilization thresholds. The load rate in the resource load data is compared with the load rate threshold, and the stack utilization rate in the resource load data is compared with the stack utilization threshold. If the load rate is greater than the load rate threshold or the stack utilization rate is greater than the stack utilization rate threshold, then the vehicle control software is determined to be malfunctioning.

9. The method according to claim 8, characterized in that, The method further includes: If the vehicle control software is determined to be malfunctioning, an abnormal warning message is generated through the cloud service. The abnormal warning information is sent to a preset terminal to remind software maintenance personnel to optimize the software.

10. A vehicle, characterized in that, The vehicle includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to implement the method as described in any one of claims 1 to 9.

Images